Rails Developers Meetup #6 大阪会場に参加しました

Rails Developers Meetup #6 大阪会場 に参加しました。

会場

前回までと同じ場所なので、スムーズに到着することができました。

オープニング

• プログラムの紹介
• ハッシュタグは #railsdm

Railsエンジニアの交換型インターンシップについて

• 自己紹介と会社紹介
• インターンシップを始めた同機
• 開発者不足
• 交換型インターンシップとは何か
• プログラミングスクール的な学習週とインターン的な作業週を交互にやる
• 学習週は 平均3ヶ月 (交互なので6ヶ月) で終わるぐらいのボリューム
• 作業週
• pull request の練習にもなるということで好評
• ローカル (学生が多い) とリモート (社会人が多い) がある
• シニアインターン: バイトリーダー的な存在
• インターンの成果: アルバイトとしての成果とスクールとしての成果 (就職先) がある
• モチベーションがもたない
• 対策としては見てますよというメッセージを送り続ける
• いいね！ がんばれ！ 大丈夫！
• 不安に対してはメッセージを送り続けるしかない
• 所属感がない
• 対策: ミートアップや忘年会を開催
• ニートやひきこもりが社会復帰した
• 就職先の会社からとても喜ばれる
• 仕事が増えた
• 有名じゃない会社のインターン戦略
• 出入りしやすくして単純に人数が多いため、確率的に優秀な人も多くなる
• 来るもの拒まず、去る者追わず
• 社会人が7割
• 無料なのでいろいろなところから紹介される
• RubyKaigi のスタッフをやったら就職できる
• 求人への応用
• 採用はしていない
• 探すんじゃなくて育てる
• 組んでくれる会社
• 質疑応答
• id的には183名
• 7割ぐらい去っている?
• 社会人は求職中の人もいれば仕事をしながらの人もいる
• 課金サービスはない

発表資料

Railsコントリビューション

• 自己紹介
• http://contributors.rubyonrails.org/ で24位
• http://contributors.rubyonrails.org/releases の v5.0.0 が 9999 Commits というコネタ
• コミットログを読むブログを続けている http://y-yagi.hatenablog.com/
• わからないことも多かったが動かして確認した
• テストがちゃんと書かれるようになったころだったのでテストでなんとなくわかった
• 2,3ヶ月で Rails のコードに慣れて、いろいろとミスに気づくようになった
• 問題がある状態をそのままにしておくのはよくないということでコントリビュートし始めた
• どんな時にコントリビュートするか? 期待通りに動かない時、機能追加したい時
• 期待通りに動かないというのはまあまあある
• よく使う道具なので期待通り動いて欲しい
• Issue をつくる or PR を作る
• Issue をつくるのも大事なコントリビュート
• 英語が苦手なので PR を投げてしまうことの方が多い
• 機能を追加したい時
• よく使う道具なので機能が足りてて欲しい
• https://github.com/rails/rails のみを対象 (https://github.com/rails の他のレポジトリは方針などが違うことがある)
• http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html
• Issue はバグ管理のみ
• 新機能提案などの issue は即 close されたりする
• 新機能についての議論は rails-core ML
• PR 投げて、そこで議論をするのでも大丈夫 (その方が多そう)
• https://github.com/rails/rails/tree/master/guides/bug_report_templates を参考にして再現手順が作れると良い
• master ブランチでも再現するか確認
• サポート対象外の古い Rails での Issue は無視されるか即 close
• サポート対象: http://guides.rubyonrails.org/maintenance_policy.html
• 似たような PR がもうないか検索してみる (open だけではなく close されているものも)
• close されていたら理由を確認して、それでも PR を出すなら、そのことも書く
• やりとりが止まっている場合は確認して引き継いでしまう
• Rails 本体にいるかどうか gem じゃだめなのか考える
• foreigner や migration_comments のように本体に取り込まれることもある
• フォーマットに従う https://github.com/rails/rails/blob/master/.github/pull_request_template.md
• テストは大体は bundle exec rake test で動く
• CI の結果も確認する
• doc やコメントのみの修正は [ci skip] を入れる
• パフォーマンス改善はベンチマークスクリプトと結果もコミットログに入れる
• PR の description に書くようなことはコミットログに入れれば良い
• 後から参照しやすい
• 使われてないはずのものを消す場合は使われなくなった場所の確認の他に gem に切り出されたものが使っている可能性も考える必要がある
• public API の挙動を変えない
• http://api.rubyonrails.org/ にのっているものが public API
• 挙動を変えたい場合は deprecate から
• squash
• 何から始めたらいいか
• doc
• http://api.rubyonrails.org/ と http://guides.rubyonrails.org/ がリリースされているものに対応
• master ブランチは http://edgeapi.rubyonrails.org/ と http://edgeguides.rubyonrails.org/
• 新しいバージョンを触る
• rc をまたずに beta1 が出たら試す
• 新しい機能はバグっていることが多い
• 既存の機能が壊れていることもある
• 新しい Ruby で触る
• Issue をみる: コードをみるとっかかりになる, 意外と簡単に直せるバグもある
• 英語ができない: コミットログや PR を参考にする
• 何か怖い: 慣れるしかない, https://oss-gate.github.io/ もおすすめ
• 質疑応答

発表資料

休憩

Railsでつくる ファイルアップロード 2017

• 会社紹介

• 自己紹介

• きっかけ
• サービスを Perl の独自フレームワークから Rails に移行中に画像アップロードを作り直したことがなかったことに気づいた
• Active Storage の登場

• スマホ時代のファイルアップロード

• 画像アップロードで考えるポイント
• 画像アップロード自体
• 画像の参照

• 画像ファイルの置き場所

• UI から考える 2017 年の画像アップロード
• 例: クックパッド, esa

• 非同期

• form_with

• Headless browser

• Step 1: public に画像アップロード
• ActionDispatch::Http::UploadedFile
• validate が画像ファイル自体と画像と紐づく情報の2軸になる
• フォームオブジェクトで処理すると良さそう
• Step 2: S3 に画像アップロード
• 認証、アクセス制御、モック
• 問題発生? ファイルアップロードに時間がかかる気がする
• サーバー経由ではなくダイレクトにアップロードに
• Step 3: ダイレクトアップロード (S3)
• Step 4: 複数ファイルのアップロード
• multiple では非同期が必要だった
• Step 5: ECMAScript 6 や File API など
• 新しい画像フォーマット (Live Photos?)
• 技術の積み重ねとユーザー体験

• ユーザー体験を向上させようとすると rails から離れた技術も必要になってくる

• 質疑応答

発表資料

How, Why, What がわからないコードの調べ方

• ネタバレ: 最終的には負けた
• ベストは、「知っている人に聞く」
• 誰もいないなら調べるしかない
• git blame は -L で範囲を絞り込める
• git blame -L "/regex",+20 file
• git blame rev file
• https://github.com/akr/vcs-ann
• tig blame file
• "," でカーソル行の親コミットの blame に移動
• 歴史をみてもわからなかった
• ログを出す
• Kernel.#caller
• logger.tagged("hoge") do ... end
• 歴史を見ても、動きを見ても、よくわからない
• それは、作り直して良いというフラグでは?
• 結論: 強く生きよう

How to improve OSS Rails application

• 自己紹介
• GitLab
• 時間がおしているので質疑応答はなし

クロージング

• 次回予告: #7 は 2017.11.16
• 月1開催は次回で最終回
• 募集は 2017.10.30 10:00から