give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

Rails 6リリース記念!?Qiitaにいろいろ記事を書きました

先日、Rails 6が正式にリリースされました。

だから、というわけでもないのですが、Rails関連の記事をいくつか書いてQiitaにアップしています。

Railsアプリのアップグレードの手順

1つ目はRailsアプリのアップグレード(バージョンアップ)の手順です。

永久保存版!?伊藤さん式・Railsアプリのアップグレード手順 - Qiita
qiita.com

これまでに何度もRailsアプリのアップグレード作業を繰り返してきた僕が編み出したベストプラクティス、いわば「秘伝のタレ」的なノウハウが詰め込まれております。
記事としてはやや長文です。

config.load_defaultsとnew_framework_defaults_x_x.rbの解説記事

2つ目はこれまたRailsアップグレード時に登場するconfig.load_defaultsとnew_framework_defaults_x_x.rbの解説記事です。

config.load_defaultsとnew_framework_defaults_x_x.rbの関係を詳しく調べてみた - Qiita
qiita.com

ぶっちゃけ、このあたりの設定はしっかり把握しておらず「なんとなく雰囲気で」使ってきてた感があったので、じっくり調べてその調査結果をまとめてみました。
Railsガイドを読んでもここまで詳しく説明されていないので、以前の僕みたいに「なんかようわからん」と思っている人は一読の価値があると思います。

Rails 6.0.0で発生する警告文に関する情報

3つ目はRails 6へアップグレードしている最中に発生した警告文に関する情報です。

Rails 6に上げると”DEPRECATION WARNING: Initialization autoloaded the constants ActionText::ContentHelper, and ActionText::TagHelper.”のような警告が出る - Qiita
qiita.com

Rails本体のissueなのでそのうち修正されるとは思いますが、僕がググったときは「これ!」という日本語記事が見つからなかったので、同じように困ってる人がすぐに見つけられるようにQiitaに書いておきました。


ためしに手持ちのRailsアプリをRails 6に上げてみました

Rails 6がリリースされたので、ためしに手持ちのRailsアプリをRails 6に上げてみました。
アップグレードしたのは妻のパン屋のWebサイトです。

coupe-baguette.com

外から見てもよくわからないと思いますが、いちおうRails 6 + Ruby 2.6 + Herokuで動作しています。

アップグレード時に発生したその他のトラブル

詳細な原因は追えていませんが、アップグレード時にはいくつかのトラブルが発生しました。
Rails 6になったせいなのか、Rails以外のgemを上げたせいなのか、はたまたHerokuのスタックをheroku-18に上げたせいなのか、どれが引き金になっているのかは僕もよくわかりません。

トラブル1:サーバーが起動しない

デプロイ直後に以下のエラーが出てサーバーが起動しなくなりました。

Errno::ENOENT: No such file or directory @ rb_sysopen - tmp/pids/server.pid 

Procfileにtmp/pidsディレクトリを作成するコマンドを追加したら動きました。

 release: bundle exec rake db:migrate
-web: bundle exec puma -C config/puma.rb 
+web: mkdir -p tmp/pids && bundle exec puma -C config/puma.rb
トラブル2:jsやcssが404エラーになる

サーバーは起動するようになりましたが、今度はjsやcssが軒並み404エラーになって「素のHTMLを表示しているだけ」の状態になってしまいました。

この件はRAILS_SERVE_STATIC_FILES=1という環境変数をHerokuに追加することで直りました。
(これでいいのか確信はありません・・・)

トラブル3:hamlの文字参照が文字にならない

全角チルダ(〜)をきれいに表示するために、~という文字参照をところどころで使っています。
ですが、この文字参照がそのまま~で表示される画面が出てきました。

ふつうに文字が表示されるよう、一度.html_safeしているのですが、ここではさらにもう一度.html_safeすることで修正できました。

 - menu_items.each do |img, name|
   - name = name.html_safe
   %figure
     = image_tag "menus/#{img}.jpg", alt: name
     %figcaption
-      %h2.text-shadow= name
+      %h2.text-shadow= name.html_safe

2019.8.20追記
この件はRails側の不具合だったようです。以下のpull requestで修正済みです。
(Rails 6.0.1のタイミングでリリースされるかな?)

Prevent TagBuilder modify options by tsuka · Pull Request #36981 · rails/rails · GitHub

情報提供してくれた、tkawaさん、tsukaさん、どうもありがとうございます!


その他、最近書いたQiita記事

ついでに、最近書いたその他のQiita記事も紹介しておきます。

統合テストはリクエストスペックに移行させよう、という話

【動画付き】Railsチュートリアルの統合テスト(integration test)は、RSpecのリクエストスペックに置き換えるのがラクです - Qiita
qiita.com

Rails標準の統合テスト(integration test)をRSpecに書き換えるなら、リクエストスペックがいいですよ〜、という解説記事です。
解説動画も作りました。


Railsチュートリアルの統合テスト(integration test)は、RSpecのリクエストスペックに置き換えるのがラクです

Cloud9上でフィーチャスペックを動かす方法

【2019年7月版・動画付き】Cloud9上でEveryday Railsの`js: true`付きのフィーチャスペックを実行する手順 - Qiita
qiita.com

Cloud9上でEveryday Railsのフィーチャスペックを動かす方法を解説した記事です。
こちらも動画付きです。


【2019年7月版】Cloud9上でEveryday Railsの`js: true`付きのフィーチャスペックを実行する手順

Cloud9、Chrome、ChromeDriverは、いずれもRubyから見ると外部リソースになるので情報をきれいに同期させるのが難しいですね。

strftimeじゃなくてlメソッドを使おう、という話

【初心者向け・動画付き】Railsで日時をフォーマットするときはstrftimeよりも、lメソッドを使おう - Qiita
qiita.com

最後に紹介するのは「お前ら、すぐにstrftimeに頼らず、l(える)メソッドを使っていこうぜ」という啓蒙記事です。
lメソッドはググラビリティが悪いせいか、どうもstrftimeの方がよく使われている気がします。
でも僕は使っていません。みなさん、日時フォーマットはDRYに書きましょう。

こちらもやはり動画付きです。

【初心者向け】Railsで日時をフォーマットするときはstrftimeよりも、lメソッドを使おう

別にYouTuberを目指しているわけではないのですが、「文章で書くより、画面を見せながら口で話した方が早くてわかりやすい」と思ったときは、先に動画を作って、その内容をQiitaとかに簡単にまとめるようにしています。

宣伝:何はともあれテスト!テスト!!Everyday Railsでお勉強しましょう

Railsのアップグレードには自動テストが必要不可欠です。
テストが苦手な人は「Everyday Rails - RSpecによるRailsテスト入門」を読んで、テストの自動化をマスターしましょう!
まだ読んだことがない方はぜひチェックしてみてください😄

Everyday Rails - RSpecによるRailsテスト入門
leanpub.com

Rubyプログラマが中学校で情報モラル講演会をしてきたよ

講演を依頼されたいきさつ

去年の情報モラル講演会は本当にひどかった

僕の地元の中学校では毎年、生徒向けの情報モラルの講演会を開催しています。
保護者も参加できるので去年は僕も出席したのですが、なかなかに ひどい内容 で、学校側に「あんな講演をする講師は来年から呼ばないでほしい」と申し入れをしました。
そのときのいきさつは以下のエントリにまとめてあります。

blog.jnito.com

今年は誰かな〜? → えっ、僕!?

で、「今年はいったい誰が講演するのかな〜?」と思っていたところ、中学校から突然電話が入り「今年は伊藤さんにお願いできないでしょうか?」とお願いされました。(しかも講演会予定日のわずか1か月前に!)

「えーっ、そんなの無理むりムリ!」と言いたいところだったのですが、去年書いた前述のエントリでも「エンジニアが情報教育を提供する側に回る」という改善案を僕は提示していました。

5. エンジニアが情報教育を提供する側に回る
 
ここまでは「他の講師に頼む」という前提で議論してきましたが、我々エンジニアが講師になったり、教材を作ったりする側に回る、という案も考えられなくはありません。
「文句を言うなら、お前がやれ」を自ら買って出るということも、やろうと思えばできるはずです。
 

【問題提起】篠原嘉一氏に情報教育の講演を依頼する前に考えていただきたいこと ~ITエンジニアから見た、情報教育のあり方について~ - give IT a try

ですので、「えーい、有言実行だ!」と腹をくくって引き受けることにしたのでした(うひゃー😅)。

f:id:JunichiIto:20190729055348j:plain
学校から配られたプリントに僕の名前がっ!

ちなみに僕はいちおう「e-ネットキャラバン認定講師」の資格は持っているので、「完全なド素人」というわけではありません。
(ですが去年資格を取ったばかりなので、まだ実際に講演したことはありません)

参考 ↓
blog.jnito.com

当日使用したスライド

というわけで、当日の講演会で使ったスライドがこちらです。
タイトルは『「怖い!危ない!」で終わらせない、 スマホ・インターネットとの付き合い方 』です。

スライドはこんな構成になっています。

  • 序論として「リスクとは何か」について語る
  • だまされるリスクを語る(偽のウイルス警告など)
  • SNSや動画投稿サイトのリスクを語る(炎上やSNSいじめなど)
  • スマホゲームのリスクを語る(高額課金など)
  • スマホ依存のリスクを語る
  • その他のリスクを語る(パスワード管理、有害サイト、利用規約等に関する話)
  • まとめ

ここから下では、この講演で僕が伝えたかった主なポイントを説明していきます。

この講演で伝えたかったこと

「スマホやSNSは怖い」だけでは終わらせない

去年の講演会がまさにそうだったのですが、世間ではむやみやたらに「スマホやSNSの怖さやリスク」を強調する講師がいます。
しかし、それでは根本的な解決にはならないと僕は考えています。

そもそも「リスク」とは何なのでしょうか?
「リスクがある = 危ない、怖い = 使うのをやめよう」と考えるのは必ずしも得策ではありません。

そこで僕は最初に「リスクとは何か」について語ることにしました。
僕が講演の中でしゃべった内容は以下のとおりです。

  • 「リスク = 必ず起きる = 怖い!」ではない
  • リスクは起きるかもしれないし、起きないかもしれない(世間では後者の性質が無視されがち)
  • リスクにはそれと引き換えに得られるメリットが必ずある
  • リスクを避けることは、メリットも一緒に捨てることになる
  • だから、リスクは避けるのではなく、うまく付き合うことが大事

f:id:JunichiIto:20190725091156j:plain
f:id:JunichiIto:20190725091206j:plain

トラブルに遭遇したら大人に頼る(一人で解決しようとしない)

「リスクを避けるのではなく、リスクとうまく付き合え」と語ることはすなわち、「トラブルの発生をゼロにすることを諦める」と語ることに等しいです。
そこで、僕の講演では「小さな失敗は仕方がない。でも大きな失敗に発展する前に解決しよう」というスタンスを取っています。

小さな失敗を一人で解決しようとすると、傷口がどんどん広がって大きな失敗に発展しかねません。
ですので、生徒たちに対しては「何かトラブルに遭遇したら、一人で悩まずに保護者や先生に相談してほしい」と語りました。

また、子どもたちが安心して相談できるように、会場にいた保護者の方や先生方には「子どもの失敗を叱ったり、責めたりしないでほしい」と語りました。

f:id:JunichiIto:20190725092113j:plain
f:id:JunichiIto:20190725092127j:plain

そうは言っても、「保護者や先生に相談するのは怖い、恥ずかしい」というケースもあると思います。
そういうときのために、公的な相談窓口があることも伝えました。

f:id:JunichiIto:20190725092350j:plain

リスクを語るときは、必ず予防策と対処法をセットで伝える

この講演ではさまざまなリスクを紹介しましたが、そのときに心がけたのは予防策と対処法をセットで伝えることです。

リスクは確率の問題です。
完全にゼロにすることはできなくても、事前に何かしらの対策をしておくことでその確率を下げることができます。

また、運悪くトラブルに遭遇してしまったときに「大変だ〜!どうしたらいいの??」と右往左往するのではなく、「次に取るべき行動」を予め知っておくことも重要です。

世間の情報モラル講演では「ほらほら、怖いよ、危ないよ!」と、生徒たちを脅すことに終始するものもあります。
しかし、子どもたちのことを本当に考えるのであれば、「その問題が発生する確率を下げるにはどうしたらいいか」「問題が起きたらどうしたらいいか」といったことも必ず伝える必要があると僕は考えます。

f:id:JunichiIto:20190725093758j:plain
f:id:JunichiIto:20190725093958j:plain

2019.7.29 18:30追記
上記スライドの「対面で話合う」は、「テキストのみのやりとりで発生した友人とのいざこざや勘違いは、対面で話合えば解決するかもしれませんよ」という文脈で説明したものです。
見知らぬ人に会いに行って対面で話合いましょう、という説明ではないので念のため。

テクニカルな解決策(設定の変更等)は重視しない

情報モラル講演によっては「このアプリのここの設定を変えておけば、もう安心です!」と、「設定万能論」もしくは「設定免罪符説」のような話をする講師もいます。

もちろん、設定変更によってある程度リスクを避けられることもあります。
ですが、その方法も決して万能とは言えません。それは以下のような理由からです。

  • アプリの画面デザインは頻繁に変わるので、知識が陳腐化しやすい
  • 設定項目が追加されたり、新しいアプリが流行りだしたりしたら、その都度「その設定は有効にすべきかどうか」を指示する必要が出てくる。しかし、項目やアプリが増えるたびに同じ講師が指示を出しに来ることはまず不可能
  • 設定を変更すると、(避けられるリスクだけでなく)失われるメリットも絶対にあるはずだが、その点について語られることはほとんどない。講師の言うとおりに設定を変更した人は、本来得られるはずだったメリットを知らず知らずのうちに捨てていることになる

僕の講演ではトラブルの原因はテクノロジー(ネット関連の技術やアプリの設定等)にあるのではなく、それを使う人間によるものが大きいというスタンスを取っています。
なので、「SNSは鍵アカウントで使いましょう(いじめ写真を載せたりすると炎上するので)」と語るのではなく、「そもそも、いじめ自体がNGです」と語るようにしました。

f:id:JunichiIto:20190725100152j:plain

大人だって失敗したり、ちゃんとできてなかったりすることを伝える

こういう講演をすると、もしかすると中学生のみなさんにとっては変に「上から目線」に聞こえてしまう話も出てくるかもしれません。
しかし、「上から目線でむかつく」とか「大人だから、専門家だからできるんでしょ」とか思われるのは、教育上あまり効果的ではありません。

そこで僕はときどき、「いや、大人だってできないんですよ。僕も完璧じゃないんです」という話をいくつか盛り込むようにしました。

f:id:JunichiIto:20190729074056j:plain
講師の人(注:僕です)もスマホ依存気味・・・!?

また、スライドには書いていませんが、僕が数年前に詐欺サイトに引っかかりそうになったエピソードも、口頭で話したりしています。

blog.jnito.com

生徒さんたちの感想

講演後に中学校の生徒さんたち(対象者は中1〜中3の全校生徒)から感想文が届いたので、いくつかピックアップして紹介します。

今日講演会を聞いてインターネットのサイトを見たりするのはメリットやデメリットどちらもあることを知れました。私はデメリットだけを考えてとても気を付けて使っていました。でも、デメリットだけではなく、メリットがあることにも気づきました。なので、そのメリットを有効活用できるようにしたいです。(中1女子)

今日自分にとって、とても勉強になった講演会だった。実は最近ワンクリック詐欺にはまってしまったのだ。急に「会員登録できました」と変な画面になり、パニックになったけど、やっぱり一人でかかえこまず、相談できる人(家族など)に言うと助けてもらえた。そういうのは無視するのがいいと教えてもらったのが、この講演会と親の言葉が一緒だったので安心した。(中3男子)

今日はお忙しい中、情報教育講演会を行ってくださり、ありがとうございました。難しい話ではありましたが、危ない、怖いで終わらせず、そのようなことにあわないのが一番ですが、もしあった場合、そこで終わらせず、誰かに相談していこうと思います。(中3女子)

多くの生徒さんたちが「僕の伝えたかったこと」を感想文に書いてくれましたし、講演中も最後まで僕の話を熱心に聞いてくれていたように思います。
ですので、今回の講演は成功だったんじゃないかなと思います。

その他の裏話等

「経験がない&時間がない」で、かなり準備が大変だった

冒頭の「いきさつ」でも書いたとおり、今回は講演を依頼されてから講演の当日まで1ヶ月ぐらいしかありませんでした。
また、プログラミング系の登壇であれば数をこなしているのでそれなりに経験がありますが、こういった中学生向けの情報モラル講演は初めてでした。
そのため、講演内容を考えるのに非常に苦労しました。

最初はCSR(Corporate Social Responsibility = 企業の社会的責任)活動の一環として、有志の企業がネットで公開している資料を利用させてもらうことも検討しました。
ですが、やはり自分の頭で考えた内容でないと、説明に熱が入らないし、説得力も弱くなるなと思い、今回は自分でゼロからスライドを作成することにしました。

ただし、そのぶん急ピッチでスライドを作成することになり、「もしかして、これは自分の登壇経験上、過去最大のピンチでは?」と思うぐらいスケジュールに余裕がない登壇となりました。
いやー、危なかった〜💦

信頼が置ける専門家の方たちにレビューしてもらった

今回の講演は子どもたちの「教育」の側面があるため、僕の独断で変な内容を教えてしまうと、かえって子どもたちに良くない知識を与えてしまうことになりかねません。
そこで、スライドが8割方できた段階で、以前からお付き合いがあって信頼の置ける専門家の方々に内容をレビューしてもらいました。

すると、「伊藤さん、ここはちょっと・・・」という指摘事項がたくさん上がり、講演の数日前に大急ぎでまたスライドを修正しなければなりませんでした😅
いや、でもどれも的確かつ有益なフィードバックだったので大変ありがたかったです。

スライドをレビューしてくださった、@hanazukinさんと@ohesotoriさん、どうもありがとうございました!

生まれて初めて「いらすとや」さんを利用させてもらった

上記のレビューで一番インパクトが大きかったのが、「中学生は文字が多いと話が頭に入りにくいので、イラストを利用して情報を可視化した方がいいですよ」というフィードバックです。

このフィードバックを受けて、僕はたとえばこんなふうにスライドを修正しました。

修正前
f:id:JunichiIto:20190725111349j:plain

修正後
f:id:JunichiIto:20190725111422j:plain

そこで活躍したのが「いらすとや」さんのイラストです。

僕は今まで「みんな使ってて似たようなスライドになるからイヤ!」という理由で、「いらすとや」さんを避けてきました。
ですが、さすがに今回は登壇まで時間がなく、「いらすとや」さん以外で無料で利用できるイラスト素材を探してくるのは無理そうだったので、生まれて初めて「いらすとや」さんを解禁しました。

いやあ、「いらすとや」さんのサイトでキーワード検索したら、求めていたイラストがすぐ出てきますね。すごい!すばらしい!
「いらすとや」さん、このたびはどうもお世話になりました🙏

参考文献

この講演ではスライドや講演内容の作成にあたり、以下の書籍や資料を参考にさせていただきました。

書籍

熊とワルツを - リスクを愉しむプロジェクト管理

熊とワルツを - リスクを愉しむプロジェクト管理

スライド等

まとめ:ITエンジニアのみなさんに考えていただきたいこと

というわけで、今回は先日僕が地元の中学校で実施した情報モラル講演会の話を書いてみました。
情報モラル講演の講師もピンキリで、僕らのようなIT技術者から見て「うんうん、そのとおり」と思う話をする人と、「おいおい、ちょっと待て!!」と思うような話をする人がいます。

去年のブログにも書きましたが、「専門家って名乗ってるぐらいだから、きっと大丈夫だろう」と高をくくっていると、自分の子どもがトンデモな内容を教えられているかもしれません。

ITエンジニアのみなさんは、情報モラル講演を学校任せにせず、機会があればぜひご自身も講演会に足を運んで講演内容をチェックしてみてください。
そして可能であれば、ぜひみなさん自身も子どもたちの前で講演する側に回ってみてください。

あわせて読んで考えていただきたい

このブログの冒頭でも書いたとおり、去年、息子の中学校にやってきたNIT情報技術推進ネットワーク株式会社の篠原嘉一(しのはらかいち)氏の講演は、僕のようなITエンジニアから見ると、とてもひどい内容になっていました。
具体的な内容は以下のエントリに詳しく書いています。
長文ですが、まだ読まれていない方は一度ご覧になってみてください。

blog.jnito.com

2005年製のGibson ES-335を買いました #ギターの話です

別に「よし、買うぞ!」と思って楽器屋さんに行ったわけじゃないんですが、なぜか買ってしまいました。
はい、GibsonのES-335というギターです。

新品ではなく2005年製の中古です

いや、前からES-335は欲しかったんですよ。
Twitterでも欲しい、欲しいと言い続けてましたし。

なんで買ったのかというと、連休中にこんなことがあったからです……。

ラブストーリーは突然に

先日妻と神戸三宮に買い物に行きまして。
妻は自分の服を見てくるというので、僕は一人で時間つぶしに楽器屋さんに行ったんです。

そこで最初に試奏したES-335が結構いい感じだったので、「じゃあ今日はES-335をいろいろ弾き比べる日にしよう」と思い、三宮の楽器屋をいくつか回って同じ価格帯のES-335を5〜6本試奏しました。
その結果、一番最初に弾いたES-335が一番弾きやすくて、一番いい音が出ている気がしました。

僕の背中を押した妻の一言

とはいえ、1本ウン十万円もするギターです。
いきなりそんな高い買い物ができるはずもなく、この時点では別にこのギターを買うつもりはありませんでした。

ですが、妻に「いいギターがあったんだよね〜」と話したところ、

「じゃあ、今持ってるギターを1本売って買ったら?」

と言われました。

妻にそう言われたときは「えー、そんな!今持ってるギターは手放したくない!!」と思ったんですが、やっぱり最初に試奏したES-335が気になります。

そこで、もう一度楽器屋さんに足を運んで、一番気に入っていたES-335を弾かせてもらうこと数十分。

「やっぱりこのES-335はいいなあ。・・・よし、買おう!!(今持ってるギターを手放して)」

と決意し、ギターを買い換えることにしました。

差額で見れば現実的な購入価格に

お店の人に僕が持っているギターの写真を見せて、ざっくり下取り価格を見積もってもらったところ、差額を2万ちょっと支払えばこのES-335が手に入ることが判明。

「じゃあ明日ギター持ってくるんで、このES-335はキープでお願いします!」

とお店の人に伝えて、その日は楽器屋さんを後にしました。

ラブストーリーは突然に(再)

翌日、下取りしてもらうギターを持って、僕は再び三宮に向かいました。
で、昨日キープしておいたES-335を買うために楽器屋さんに入り、何気なくギター売り場を見ていたところ、

「ん?こんなES-335、昨日あったっけ?」

と思いました。
見覚えがあるような、ないようなES-335が売り場に並んでいます。

店員さんいわく、「それねー、ちょうど昨日入ってきたES-335なんですよー」とのこと。
見た目も価格も僕がキープしていたES-335とほぼ同じだったので、「これもちょっと試奏させてください」とお願いして、新しく入ってきたES-335を試奏させてもらいました。

(♪♪ 試奏中)

「あれっ?もしかして僕が買おうとしているES-335よりも音がいいのでは!?」

(♪♪ 2本のギターを弾き比べる)

「やっぱり、新しく入ってきたES-335の方が音がいい・・・。よし、昨日のはキャンセルして、こっちにしよう!!」

と、急転直下で前日入ってきたばかりのES-335を購入することになりました。

楽器屋さんで2本のES-335を弾き比べる僕

ES-335は最高オブ最高😍

いやー、このES-335は非常に良いです!
楽器屋さんでもいい音がしていましたが、我が家の'64 CUSTOM DELUXE REVERB(ギターアンプ)と組み合わせて鳴らすとめちゃくちゃいい音がします。

イメージ的に近いサウンドはこちらの動画です。
(同じES-335ですが、こちらは1967年製のビンテージギター)


なんての?ホンマにエエ音や / ビンテージ67年製ギブソンES335 / TFGD#29

さらに音が良いだけではなく、とっても弾きやすい!
いい音 + 弾きやすいギターは最高です。
最近ちょっと下がり気味だったギター熱が、これでまた再燃しそうです🔥

参考:下取りに出されたのは、この子です

ちなみに今回ES-335と引き換えに下取りに出されたのは、こちらのレスポールカスタムです。

見た目も美しく、いろんな思い入れがあったのですが、泣く泣く手放すことにしました😢
いい人に拾ってもらうんだよ〜、レスポールちゃん。

まとめ

というわけで、今回のエントリでは新しく買ったES-335を紹介しました。
宝の持ち腐れにならないよう、練習がんばります〜。