関西Ruby会議2017に参加した
参加してきたので復習。 資料がアップされていているものを中心に記します。
基調講演
株式会社クリアコード
slide.rabbit-shocker.org ビジネスとコミュニティを両立する話。 その両立の中で学んだことなどを発表されていた。
問題をupstreamで直す
あるライブラリの修正は公開元に対して行うというもの。 修正したコードを手元に保持していると、それだけ管理コストが増大する。
OSSを仕事につなげる
OSSで稼ぐ企業が増えた。 その結果、OSS活動を通して営業を行えるようになった。 コミュニティ活動がビジネスへとつながることもある。
Rubygem開発の流儀
gemを作成する過程で考えていることについて発表されていました。
gemを作る時の考え方
gemの作成自体は簡単にできる。 しかし、gemで何を実現するかということを考えるには相応のコストがかかる。
gem作成に必要なもの
解決したい問題に対して、アイデアを出す。 設定したゴールに向かって工程や解決策を具体化し、多様な環境で動かせるように調整する。
こういった工程は普段の仕事でやっていることと変わらない。
不満を大事にする
日々感じる不満を言語化することが大事。 言語化できないとそれを快活する道筋を立てることもできない。 そのために、日々感じる不満を大事にすべき。
実際に解決するまでに必要なこと
感じた不満を実際に解決するまでにはやはり知識の引き出しが必要となる。 るりまを読んでおいて使える道具の知識はアップデートしておかないといけない。 また、適切な抽象化、汎用化にはデザインパターンの知識が必要となる。 さらに、世の中にある色んなgemを読んで、応用例をストックしておく。
Rubyistと技術記事 ～なぜ書くの？どう書くの？何が起きるの？～
技術記事を書くことについて
技術記事を書くことは、自分の知見をオープンソースとすること。 執筆した記事は「困る、ググって、解決する」のサイクルの中で活用される。
OSSのライブラリも、実装時に参考にされたりするので、それに似ている。
自分が過去に困ったりしたことについて書くことによって、似たようなことで困る人を助けることができる。
そういった行動が巡り巡って自分の評価を上げたり、信頼を上げることに繋がる。
記事の書き方
タイトルには抽象的にせず、完結で適切なものにする。 公開前に何度も校正する。 徹底的に読者ファーストで考える。 目の前に困っている人がいることを想定し、その人が困っているであろう箇所を解決するように書く。
文章のうまさ
技術記事の執筆を継続していると、次第に文章を書くのがうまくなる。 ただし、とにかく継続が必要。
感想
大阪に来てカンファレンスに参加したのは初めての経験でしたが、非常に楽しめました。
発表の中には、自分が悩んでいることやかつて悩んでいたことに答えを明示してくれるものもあり、その点も非常に良かったです。
例えば、基調講演の中で出た、ライブラリへの修正をupstreamに適用する話はかなりしっくり来た話でした。 ビジネスでの成果がコミュニティに還元されている好例と思えます。
また、日々の不満を大事にするというのも、ライブラリやgemの作成のみならず、アプリやサービスの着想に応用できる話と感じました。
懇親会で飛び入りのLTも行いました。 こういった場で即興で作った資料でLTをするのは初めてでしたが、まぁなんとかなったと思えます。
