さめたコーヒー

kbaba1001のブログ

「Rails Developers Meetup #6 東京会場」に参加した

techplay.jp

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

フィヨルドの駒形さんの話。インターン生用の次のサイトを作っている。

256interns.com

内容は「学習 + 仕事の手伝い」で、参加費は無料。その代わりバイト代もでない。

リモートインターンも受け入れていて、まったく対面せずにインターンすることもある。 7割くらいは社会人インターンとのこと。昼間働いて、夜間にインターンする人もいるらしい。

「くるものを拒まず、さるものを追わず」の精神で、たくさん受け入れているらしい。

↓詳しくは駒形さんのブログで。

docs.komagata.org

無料でやっていることに関しては、なんとか有償化したいらしいが、どのようにやるかのいい案を出せていないとのこと。 「無料だから人が来る、紹介しやすい。一方、参加者も向いてないと感じたらやめやすい」というのが強いという発表だったので、 たしかに有償化は難しいのかもしれない。

それにしても、結構手間はかかってそうなので、やっぱり収益を出せたほうがいいんじゃなかろうか。

感想

  • プラットフォームあるとやっぱり指導しやすそうだなと思った
  • インターン生にやらせる仕事は受託じゃなくて社内サービスというのも良いと思った
  • リモートインターンのほうが「教室作り」的なことに苦労しなくていいのかもしれない (反面「所属感がない」のスライドみたいなことはあるっぽい)
  • ニート、ひきこもりの社会復帰を助けられてるのはいいなと思う

疑問

  • インターン生の書いたコードはクオリティが低いと思うけど、それを指導する労力を考えると自分で書いたほうが速いんじゃなかろうか？
    • シニアインターン（バイトリーダー的な人）がいるからその人が指導すれば、めっちゃだめってことはないのかな？
    • このへんの指導する側のモチベーション維持はやや気になる。「やっててよかったこと」のスライドがモチベーションだとは思うが。
  • アスペルガー障害とか発達障害とかも含めて、他の人とうまくやっていけない人もくるとおもうけど、どう対処しているんだろう。そういう生々しい話も聞きたかった。

Railsコントリビューション

y-yagi さんの発表。

  • Rails のコミットログを３年位ずっと読んでる
  • Rails Contributors ( http://contributors.rubyonrails.org )
    • Rails の Contributors のランキングが見れるサイト
  • Rails 本体のコードでも意外とミスが多い
    • document と食い違う
    • そもそも動かないなど

コントリビュートのモチベーション

  • 期待通りに動かないことを直したい
    • SNSで文句を言ってもなおらない
    • issue or PR を作る
      • 英語が苦手なので PR をいきなり投げているらしい
  • 機能が足りないので追加したい

具体的なアプローチ

コントリビューションのガイドラインがある（若干古め） http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html

  • Issue

    • Rails の issue はバグ管理のみで使っている
      • こういうプロジェクトの方針には従う
    • 新機能追加への議論は rails-core mailing list でやってる。
      • でも新機能の提案を Pull Request で出してもいい
    • issue のバグ報告用のテンプレートがある
      • 再現ケースを書く
      • 再現用のリポジトリを作るとか、単体で動くようにするケースを用意するとか
    • 古いRailsのissueは無視される

  • Pull Reuqest

    • 似たような PR がないか検索する
      • Open されているものだけでなく Close されたものも見る
    • 同じような PR がやり取りがとまっていることになる
      • 作者に ping して「まだやる気があるか」確認する
      • 引き継ぐこともできる
    • 本当に Rails 本体に入れる必要があるかどうか考える
      • gem じゃダメなのか？
      • gem で作った後 Rails 本体に取り込まれるものもある
    • Pull Request もフォーマットが決まっている
      • でもフォーマットは雑なのでサマリがちゃんとしてればいい
      • CI の結果を確認する
        • ActionCalbe とかが無関係だけどたまに落ちる。そういうのは無視していい。
    • 性能アップ
      • コミットログにパフォーマンスチェックのスクリプトを書く。
        • これがあると、後から「当時は大丈夫だった」みたいなことがわかる
      • Pull Request の description に書くようなことは、全てコミットログに入れてしまった方が良い
        • Pull Request を見るのは大変
        • 将来的に github が消える可能性もある
    • 使われていないように見える機能でも、過去に切り出した gem で使われている可能性がある
    • レビュアーの負担を減らせるように、必要そうな情報はすべて書くようにする
    • Public API (rails doc にのっているもの) の挙動を変えないようにする
    • Public API の挙動を変えたい場合は DEPRICATION にしてから消す。
    • rails は commit をスカッシュする

コントリビュートを始めたい人はどうするか？

  • 公式の document を見る
  • ドキュメントが間違っているのを発見したら pull request を投げればいい
  • 新しいバージョンを触る (beta とか rc とか)
    • 新しい機能は壊れている
  • Ruby の新しいバージョンで触る
  • Issue をみる。
    • 適当な Issue をみて、なおそうとしてみる。
    • 2行くらい直せばうまく動くことも結構ある
  • コミットログやPRを参考にする
  • なんか怖い

感想

  • 割りとすぐに Pull Request 出していいものなのだな (issueで話してからの方がいいのかと思っていた)
  • プロジェクトごとの運営ルールがあるからそういうのは確認してからのほうが良さそう
  • コミットログ3年読み続けてるのスゴイなぁ…。僕はそういうモチベーションは続かなそう。

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

株式会社みんなのウェディング 松久 浩伸 さんの発表。

スマフォでの画像アップロード

  • 2〜3MBくらい。結構容量が大きい
  • 画質を保つならpixcel数もおおきい

サーバーにアップせずにJSで直接AWSにアップする

  • AWS に JS で直接アップロードする方法がある。
    • これは自分のサーバーにアップロードしないので速い
  • HTML 5 の File API を使うとサムネを簡単に出せる
  • Live Photos (iphone) などの新しい画像フォーマットの存在も対応する必要がある

感想

  • 割と普段よく画像アップロード作ってるけど、ここまで考えて作ってないなぁ。エンタープライズっぽいサービスを作りすぎているのかもしれない。
  • JS で AWS に直接アップしたほうが何かと良いならそれでいいのかな。URLだけ取得してDBに格納しておけばサーバーサイドも困らないだろうし。
    • JS の処理が増えるけど、今更大したことない気もする。

まとめ

ここで帰ったので、残りの発表は聞けてない。 なんかもう最近は勉強会いってもあんまり他の人と話す気分になれなくて、発表聞いたらさっさと帰ってしまっている。 懇親会とかでもうちょっと発表の話を掘り下げたりすれば面白いのはわかっているんだけど、なんかだるくてそういうのやらなくなってしまった。 自分が書きたいコード書いて一人で「フヒヒッ」って言ってる方が楽しくなってきている。 なんかこう、説明したり聞いたりが最近だるい。嫌いなわけじゃないんだけど。