第88回 Ruby関西 勉強会は会場の予約をしたりイベントを公開したりして、 運営側の作業も色々やっていました。
会場
今所属しているRuby開発という会社が NLC のビルにテナントとして入っていて、 その関係で NLC の貸し会議室が安く借りられるので、 NLC 心斎橋での開催でした。
イベント中に前で話をした時には公開可能な情報かどうか確認していなかったので、 安く借りられる、と行っておきましたが、 NLC心斎橋 のサイトに書いてあるように実際にはテナントとして入っていれば無料で借りられる場所でした。 この場所はテナントじゃないと借りられない場所のようでした。
NLC貸会議室の方はテナント以外でも借りられて、 テナントだと安く借りられたり、場所によっては無料だったりするようです。
会場自体に無線LANはあったのですが、 開始前に繋いでみたときは繋がっていたのに、 始まってからは繋がるのに DNS が引けずに外に繋がらないという状態になってしまい、 結局使えませんでした。
プロジェクターは HDMI はなく VGA のみでした。
他の準備に手間取っていたら、結局今回はライブ配信はできませんでした。
最初の発表 (前説＋鹿児島Ruby会議の話)
他のイベントで何度かみたことがあった directpoll.com というサイトを使ってアンケートをとってみました。 結果は ruby-jp Slack の #rubykansai チャンネルに公開しています。
最後に懇親会の参加予定を入れてみたのは良い感じになったと思っています。 他の質問については他に一緒にツッコミをしてくれる人がいないと話を広げるのが難しくてつらいかんじでした。
鹿児島の話はイベントがどんな感じだったかとか、日曜の桜島観光の話でもしようかと思っていたのですが、 まとまっていなかったのと、確保した時間で残っていた時間が鹿児島での発表時間と同じぐらいだったので、 発表内容の再演をしていました。
発表資料を再度貼り付けておくと以下の通りです。
スライドはいつも通り Rabbit Slide Show (RubyGems), SlideShare, Speaker Deck にあげています。(ソースは github にあげています。)
みんなのQuine
Quine の作成過程を実演する話でした。
こういうものは最終結果だけみてもよくわからないので、 失敗などの途中過程も含めてみられるのは良い感じでした。
Rails4.1から6.0へ
以前も Rails のバージョンアップの話があったつじたさんによる別のバージョンアップの話でした。
5 を経由して段階的にあげたのではなく、 rails new し直してコピペしつつあげたようでした。
どういうところで困ったかなどが参考になりそうでした。
以下、メモです。
- asset_path → image_tag など
- before_filter → before_action
- webpacker (ほぼ) 必須
- javascript_include_tag → javascript_pack_tag
- coffee → js にも使える http://js2.coffee/
- yarn add して config/webpack/environment.js に追加
- jquery-datetimepicker は environment.js だとうまくいかなかったので yarn add して import した
- 内部の js は packs で require
- assets と違って気軽に可変値を渡せなかった
- strong parameters が厳しくなった
- turbolinks:load ?
- create! が関係ないカラムを無視してくれなくなった
- Rails 5.2 で config/secrets.yml → config/credentials.yml.enc
- サーバー構築時にインストールするものが増えた (webpacker 関係など)
Zeitwerk integration in Rails 6.0
Zeitwerk をおすすめする話でした。
アプリケーションを作る時に非常に便利そうで欠点も特になさそうで良さそうでした。
gem を作成する時に使えるようにもなっているようなので、 そのうち zeitwerk に依存した gem が出てくるようになるのかもしれません。
inotify の話
メール処理を postfix からのプログラム起動から Maildir/new の inotify での監視に変えた話でした。
以前 rails アプリで postfix でメールを受ける処理を書いたときは、 postfix からは rails アプリに POST するだけにするのも検討した気がしますが、 inotify の方が起動のオーバーヘッドは確実に減らせるし、 Maildir の rename(2) を使うというやり方にそっていれば、 メールを処理するプログラムのバグでのメールのロストの可能性も減らせて良さそうでした。
以下、メモです。
- Re:lation で inotify を使った話
- Guard gem でも内部的に使われている
- listen 経由で OS ごとに対応している
-
rb-inotify, rb-fsevent, wdm
- 従来のやり方: postfix で1通ごとにプログラムを起動
- データベース接続・切断などのコストが大きい
-
~/Maildir/newの監視に変更 -
デモ
- 監視プログラム自体の監視は monit
- TERM シグナルの trap が重要
Ruby初級者向けレッスン 72回 ─文字列─
いつものようにRuby初級者向けレッスンで終わりました。
クロージング
会場スポンサーとしてRuby開発の紹介をちょっとしましたが、 会社紹介用の情報を用意していなかったので、うまく説明できずに簡単な紹介で終わってしまいました。