MoneyForward Meetup vol.6 に行ってきました。Rubyコミッターの卜部さんや松田さん、金子さんの話が聞けておもしろかったです。
以下メモと感想。
オープンソース開発者として働くということ 卜部さん
なんで自分に給料が振り込まれるのか？ 運が良かった
オープンソースはソースがオープンなことではない
競争力の源泉はオープンソースにしてない
OSSにコントリビュートなんてしてる場合じゃない
"OSSにコントリビュート" なんてしてる場合じゃない！ // Speaker Deck
タイトルに反してOSSに貢献する話
コミュニティに還元するのがミッション
オープンソース会社として働くということ
１. コミットしよう
オープンソース開発者として働きたければオープンソース開発者になることからはじめる プログラミングだけが貢献ではない
２. 発表しよう
アピールなしに勝手に事態が好転することは考えづらい
- プルリクエスト
- 勉強会
- 雑誌記事 書籍
Ruby会議で発表とか チャンスがあれば書籍
セルフブランディングも時には必要
３. 仕事をオープンにしていく
フルタイムでオープンソース出来るポジションは少ないので作る
- 自社製品をオープンソース バックエンドはクローズで クライアント向けはオープン
- 顧客に配るやつをオープンにする
- プリンタドライバ開発とか
まとめ
業務中にオープンソースについて考えること 金子さん
MFはOSSいっぱい使ってる会社 仕事中に仕事をしているふりをしてパッチを作っている RHGに影響を受けている
OSSのコードを読むこと
- リファレンスに載ってないことを調べるために読む
- バグを踏んだときに切り分けのために読む
- 機能を追加するときに読む
- 実装するた時のヒントを得るために読む
プロダクトへ還元されやすい むしろ開発上必須
ソースコードの読み方
show-sourceを使う
内部実装が見れる 手軽に実行できる エンドポイントやコンテキストが明確 ただしコードの全体像がわからない 調査するときのとっかかり
git cloneしたコードを開いて読む
全部読める 便利そうなclassやメソッドを探すことがおおい
issueやMLを購読する
hotな話題がわかる プロジェクトの雰囲気がわかる 自分の興味がわかる
どうしてパッチを書くか
- 業務上必要だから
- 将来困らないため
読むことに比べて中期的な時間軸でのリターン
業務上必要な機能 本体に入ればずっとメンテナンスされる
自分以外のメンバーも踏みそうなものにパッチを送る 下手にドキュメント共有するよりパッチを当てたほうが速い
直感に反するものにパッチを当てる 直感に反しない実装に変える
ライブラリの足固め
testをfixする CIの設定を見直す いざPR欠かざる終えないときに最短で進めるように
forkしてCIを回す
OSSのコードで遊んでみる
楽しいから 当たれば儲け こっそりひっそり取り組む patchを作りながら言語を学ぶ 実際の課題があるので取り組みやすい 中ー大規模のコードの書き方を理解できる 最低限のドキュメントを読んでから参加する
pandasのパッチを投げてる
将来的な投資 Rubyで扱えるとうれしいものがある daru ruby
まとめ
- 業務とOSSは地続き
- うまくいけば世界がコストを負担してくれる
- 自分たちの力で改善したり安定させることが出来る
仕事とOSS 松田さん
コミッターは趣味 以前はJavaとか.Netとかやってた いろいろ大変だったけど自分で何とかしようという発想はなかった ブラックボックス感
Railsへ ちょっと使うとすぐバグにぶち当たる 自分でいろいろ改善出来る余地がある
Railsの強み
- 徹底的な現場指向
- リアルな現場でそのまま使える
- とどまらずに変化し続ける
- 他人の力を借りてアプリケーション開発をブーストできる
エコシステム（＝地続き感
- コード読みたければ読める
- 作ってる人達の顔が見える
- 開発に参加したければ気軽に出来る
- ブラックボックスじゃない感
地続き感の源泉
世界中でカンファレンスが週1か2ぐらいでやってる
Railsは巨人の肩の上に載っている
現代のプログラマのお仕事
- 目の前の機能が上手に実装できれば良いという時代ではない
- 巨人の肩にうまく乗る能力が求められている
- 自分で書くアプリケーションのコードは氷山の一角
- 氷山の下の部分まで含めた全体を自分でコントロールできるか
コントリビューターになる方法
なろうと思わない 仕事でアプリを開発するついでに普通に不具合を見つけて普通にパッチ書く
アプリの開発のついでにRailsも開発すれば良いじゃない
仕事 VS OSS
- OSSはアプリケーションの一部
- むしろ大部分
仕事でOSSするこつ
OSS開発と同じ道具を使って仕事をする
- 日常的に英語で読む英語で書く
- コミットメントが日本語は論外
使ってるソースコードは手元に
- バグを踏んだら次の瞬間パッチがかける
- gem-src
他人が書いたコードを信用しない
- 使うけど信用しない
- 信用できる人間と出来ない人間を見極める
- 信用できるコードを書く人間が信用できる
- いろいろ読んでいろいろな人に会う
なるべく友達のプロダクトしか使わないようにする
- 書いた人間の人となりがわかるとコードの傾向もある程度わかる
- 知らない人が書いたgemがbundleされてると不安
コミュニティ大事
- カンファレンスに行って友達を作ろう
- コード書いてる人に話しかけよう
- 予習必須
- コード読む
- るびまのインタビュー
Rubyist hotline
ちゃんとコード書いてる人しか出てこない
勉強会じゃない地域コミュニティに顔をだしてみるのもオススメ
コミュニティで発信する難しさ
- 公用語は英語
- カンファレンス行けばいいってもんじゃない
だからコードを書く
- コードはコミュニティに参加するためのプロトコル
- 共存共栄を目指す
- 開発者・コミュニティ・企業
- 三者にとって良い関係を結ぶ
企業とコミュニティの間が不明瞭
- コミュニティは企業に何を返せるか
- 場の提供
- Ruby kaigiとか
- 人材プールとしての役割
企業はコミュニティに何を返せるか
- あまり議論されていない分野
- 開発者＝コミュニティのラインとの地続き感を演出
- コミュニティとの距離の近さこそがRUbyの楽しみ、強み
- 企業とコミュニティの距離がとても重要
- コミッタいる
- Rubykaigiにスポンサーしてる
- カンファレンス参加費用を出してくれる
会社として開発者の皆さんにOSS活動をケアしているというアピール
つまり金
- OSSを使ってる分浮いたお金を活用してはいかが？
- Rubykaigiのスポンサーシップ
- 直接的なスポンサーメリットは提供していない
- 広告打つ金だと思ったら？
- 転職エージェントに支払うお金だと思ったら？
やっぱりコード
- コミュニティからコードを享受した恩恵はコードで返したい
- 良いコードを書くだけじゃ駄目誰が書いたコード化が重要
- 使う時ちゃんと読むよね？
- コードを公開する前に自分が何者なのかを表すブランディングが必要
- コミュニティへの投資
企業がコミュニティに対して何が出来るか？何をしてくれるか
感想
勉強会で得たこととしてはやはりコミュニティに貢献していかないとなと思いました。そのためにはいろいろな形があって、プルリク送ることだったりテスト書くことだったりドキュメント書くことだったりするのだなと。あとOSSを使うというのも一つの貢献だということでした。これに関しては仕事でも趣味でも使っているので一応貢献できているのかも知れない。
大事なのはバグを踏んだときに自分のコードにとどめるのではなくプルリクを送るということ。普段自分が使っているときにあまりバグに遭遇するということは意識できていないので、やはり使い込まないと気づかないのかも知れない。気づいたときにプルリクを送るチャンスだと思って積極的に関わっていきたい。
あと英語。コミュニティに貢献するにはやはり英語は大事でOSS界隈を渡り歩くのには英語は不可欠なんだなと。いろいろ特別なことをしているわけではないとおっしゃってましたけど、英語が出来るだけでだいぶ特別だと思いました。でもここは最低限なんとかしないと行けない領域ですね。
最後になんといってもコードを書いて読むことが一番大事っぽい。自分が使っているgemのコードをちゃんと読まないといけないなと思いました。
懇親会ではいろいろお話が出来て楽しかったです。MoneyFowardさんは会場は小さめだけどいろいろと密で話をしやすい空気作りがされていると思いました。
