関西Ruby会議2017に参加しました #kanrk2017

関西Ruby会議2017に参加しました。

以下、メモです。

オープニング

• スポンサーの紹介
• 会場のトイレの場所などの説明

オープニングでは何も言っていませんでしたが、ハッシュタグは #kanrk2017 のようでした。(doorkeeper のイベントページからツイートしようとするとつく)

スポンサーセッション

最初はアジャイルウェアさんのスポンサーセッションでした。

基調講演: 株式会社クリアコード

• 「株式会社クリアコード」というタイトルの発表
• テーマ: コミュニティーとビジネス
• twitter 連携が下に出ていた。たぶん Rabbiter (Rabbitter ではない) です。
• 大事にしていること: フリーソフトウェアの推進と稼ぐことの両立
• 学んだこと1: 問題は upstream で直す
• フリーソフトウェアが大事にしていることの1つは「直せること」！
• デバッグ力: よく知らないプログラムの直し方 - ククログ(2011-12-06)
• 学んだこと2: 開発を続けられるコードを書く
• 継続的に開発とビジネス
• 長期間一緒にやれる仕事を優先
• フリーソフトウェア開発の世界
• ユースケースを確認する
• 学んだこと3: 相手が想像しなくてもわかるように説明する
• 学んだこと4: 楽しく開発する
• 学んだこと5: 非難するよりも手を動かす
• 学んだこと6: 回避策よりも根本解決
• 受託開発の優先度
• a: フリーソフトウェアを直接的に推進できる仕事
• b: フリーソフトウェアを間接的に推進できる仕事
• c: いずれ推進につながりそうな仕事
• FLOSSサポート: 導入支援と障害調査
• 事例：Firefox/Thunderbirdの企業導入
• 公開することで宣伝にもなるので次の仕事に繋がることがある
• OSS開発支援
• どうして仕事になるか
• OSSのエコシステムに参加
• 自分たちのソフトウェアとOSSを同じように扱う
• 問題があれば直す
• 気になるところがあれば共有
• 仕事の作り方: お客さんに見つけてもらう
• お客さん探しを頑張らない
• 諦めることは大事
• 決断
• 決断する基準があると楽しめる (自分の中で基準がはっきりしていないうちは大変だった)
• クリアコードの基準: フリーソフトウェアの推進と稼ぐことの両立
• お客さん探しと稼ぐこと
• 推進と稼ぐことの両取り
• 推進→見つけてもらった例: milter manager
• 最近の推進兼営業活動: Apache Arrow
• 【5/28大阪】データ分析用次世代データフォーマットApache Arrow勉強会 - connpass
• 採用
• マッチする人は少なそう
• 業務内容ではなくポリシーでマッチ
• フリーソフトウェアの推進 → 見つけてもらう
• RubyKaigiにスポンサー: Rubyを応援したいので始めた, 採用は期待していなかった
• 株式会社クリアコード - Kouhei Sutou - Rabbit Slide Show
• 質疑応答
• かくたにさんを指名
• とてもいい会社説明会でした
• joker1007 さん: upstream に取り込まれなかった場合は?
• 一言で言うとケースバイケース
• ユースケースに合わせた形で再検討
• ?: フリーソフトウェアと OSS という言葉の使い分け
• 本質が大事だと思うときはフリーソフトウェア
• お客さん視点のときは OSS
• クリアコード視点だとフリーソフトウェア
• 外からは OSS
• あとで個別に説明します
• むりょういさん: 使っているソフトウェアについて(?) (ちゃんと聞き取れなかった)
• Firefox / Thunderbird: すでにノウハウがあった(?) (ちゃんと聞き取れなかった)
• Apache Arrow: いけると思って推進している
• https://slide.rabbit-shocker.org/authors/kou/kansai-rubykaigi-2017

休憩

スポンサーブースとどら焼きの案内があった。

Rubyでデータサイエンスを行うための取り組み

• ko1 さんと mrkn さんが始めた活動
• データサイエンスは技術的にどうおもしろいか
• データサイエンスとは
• データソース (Excel, RDB, …) - 前処理 (文字列整形, 欠損値処理, …) - 分析 (機械学習, 統計) - 可視化 (散布図, 棒, 箱ひげ, …) - 多次元データの理解, モデルに基づいた予測
• データサイエンスは、9割を前処理に費す
• 具体例
• 近年の状況
• データが増えている
• データ分析環境が進歩している
• データサイエンスの民主化が進んでいる
• Ruby のデータサイエンスの現状
• ウェブブラウザからのRubyの実行
• データサイエンスに関わるRubyのgem群
• docker で試す
• https://hub.docker.com/r/sciruby/ https://hub.docker.com/r/rubynumo/ のあたり?
• PyCall について
• Arrow を介した Ruby 外言語との連携
• Python と R が二大言語
• Python でできるけど R だと簡単にできないとか R だとできるけど Python だと簡単にできないとかいうときにも Arrow で簡単に連携できるようになったらしい
• コミュニティの重要性
• (red-)arrow の出現に伴う変化?
• 複数言語の連携が容易になる
• 他言語にはない優位性を持つ gem や独自機能を持つ gem が求められる?
• http://sciruby-slack.herokuapp.com/
• https://gitter.im/red-data-tools/
• 質疑応答
• 発表者: データサイエンスに興味がある人が少ない?
• joker1007 さん: Ruby でやれると嬉しいが、目の前の問題を解決するには他の手段を使ってしまう。 Ruby は分散処理のコンポーネントが少ない? Ruby は好きなので長期的には Ruby でできると嬉しい。
• arrow があっても独自性がないと厳しい?
• すぐには難しい
• 可視化あたり?
• https://github.com/sciruby-jp/ruby-datascience-examples/blob/master/Ruby%E3%81%A7%E3%83%87%E3%83%BC%E3%82%BF%E3%82%B5%E3%82%A4%E3%82%A8%E3%83%B3%E3%82%B9%E3%82%92%E8%A1%8C%E3%81%86%E3%81%9F%E3%82%81%E3%81%AE%E5%8F%96%E3%82%8A%E7%B5%84%E3%81%BF.pdf

昼休憩

11:56 から 12:50 まで。

エンタープライズRubyOnRails エンプラでぶち当たった2つの壁と突破法

• 自己紹介
• 会社紹介
• エンタープライズに Ruby on Rails は不向きと言われている
• 1: 高すぎる柔軟性
• 2: Rails による規約の縛り
• 本日お伝えしたいこと: 具体的な壁と突破方法
• プロジェクト概要: 写真は https://twitter.com/ujm/status/868315623561977856
• ソース管理: GitLab (ギットラボとよんでいた)
• 経験者が少ない (10人に1人)
• 2つの壁にあたった
• コードのメンテナンス性低下
• 経験者が不足するとどうなるか
• 一貫性のないコードが量産される
• レビュアーが困る
• コンフリクトの多発
• merge request でモデルのコンフリクトが多発
• レビュアーの負担が激増
• 壁は想像以上に高かった
• 突破法を考えてみた
• コードメンテナンス性の壁 → 強力な IDE レベルの仕組み → 開発統制
• コンフリクトの壁 → 人が編集するファイルの極少化 → 自動生成
• RuboCop SubimeText3 独自チェッカー Drone
• rb ファイルと erb ファイルをチェック
• RuboCop でチェック
• erb は注釈宣言を警告して erb のコメントアウトを使うように
• CI がパスしなかったら merge request をマージできない
• Excel の設計書から自動生成
• 権限やルーティングを自動生成
• routing ファイルを分割
• 一部は手動変更可能 (gem 関連とか)
• ER 図からも自動生成
• マイグレーション、RSpec、Model を生成
• モデルファイルをモジュールに分割して自動生成
• 画面設計から view も自動生成
• ロジックが必要ない部分は基本的に自動生成にした
• 結果
• レビュアーの負担が減少
• 64.9% (約31000行) が自動生成
• コンフリクト発生率 25% → 5%
• 質疑応答
• ?: コンフリクト解決の責任はレビュアー?
• そうです。
• ?: ? (メモ取れず)
• 決めるにあたって色々葛藤があったが詳細は懇親会で
• https://www.slideshare.net/kakko1003/ruby-on-rails-2

Rubygem開発の流儀

• プロジェクター接続トラブル
• awesome なのでサイズ調整ができない
• 表示がおかしい (上の一部が下に出ている)
• 自己紹介
• 会社紹介
• 本題の Rubygem 開発について
• Rubygem についておさらい
• bundler 便利
• パーフェクト Ruby 第二版
• 著者献本を持ってきたのでブログに書いてくれる人にプレゼントしたい
• 作り始めが簡単でも gem を作ってリリースするには別のハードルがある
• gem をざっくり分類
• 開発支援系: ほとんどの gem
• クライアント系
• フレームワーク/ミドルウェア系
• プラグイン系
• 既存 gem 改造系
• 業務特化系
• 便利ツール系
• パフォーマンス向上系
• 既存gem の改造やプラグイン系が作りやすいし、ゴールがわかりやすい
• 色々な gem を参考にネタを探す
• とにかく日々のイライラや不満を言語化し、色々な gem のパターンと突き合わせる。
• gem を作り始める前にやること
• gem 開発のコストとは
• activerecord-cause の場合
• gem を作るときに考えておくこと
• 行儀の良さとは
• gem の外の世界を壊さないなど
• rspec-storage の場合
• よくない例
• 非公開な API 使いまくり
• 汎用化の暗部
• たとえば devise や rails_admin のコードが簡単に読めますか?
• 作った後の OSS 活動
• 昨日追加要求について
• 基本的に「Welcome your PR」で良いと思っている。
• Welcome PR なんだけど…
• 機能追加系の対応にはポリシーが必要
• 実装せずに済ます強い心の例
• まとめ
• kozo2 さん: embulk の gem には jar が同梱されていると言う話があったがファイルサイズの上限はあるのか?
• あった気がするが引っかかったことがないのでわからない。
• kozo2 さん: データを大量に入れたい。
• 日本の祝日の gem のようにデータのみの gem の例はある。
• パーフェクト Ruby 第二版のプレゼントのじゃんけん大会
• https://twitter.com/9gmotonari/status/868332186025443328
• Rubygem開発の流儀 // Speaker Deck

休憩

• RubyKaigi 2017 の受付が始まっている

コミュニティ文化の取り込みとその機会で得た知見

• 会社のスポンサー表示
• Contents
• Community?
• 社内のコミュニティ感
• 個人的成果の紹介
• webpacker を使っている人: 1桁ぐらいしかいない
• 自己紹介
• https://github.com/muryoimpl/buoys
• Community とは?
• この場もコミュニティ
• 一緒に仕事をする人たちもコミュニティと言える
• コミュニティとの接点
• (同じタイトルで違うスライドがしばらく続いていたのでメモを取り損ねたので、諦めて聞いていた)
• https://github.com/muryoimpl/slippr
• https://github.com/muryoimpl/talker-signupper
• 時間がおしているので質疑応答はなし
• https://speakerdeck.com/muryoimpl/kansai-ruby-kaigi-2017

Rubyistと技術記事 ～なぜ書くの？どう書くの？何が起きるの？～

• 自己紹介
• Rubyist と技術記事
• 技術記事を書く = 知見のオープンソース化
• 一般論から個人の話へ
• これまでの活動内容
• 知っている人挙手 → 写真とらせて
• なぜ書くの?
• 困る、ググる、助かった！のギブアンドテイク
• 助かった、ありがとうの声が1つでもあると嬉しい
• 何を書くの?
• 困る、ググる、助かった！の流れをイメージする
• いつ、どう書くの?
• 朝型なので、起床してから仕事を始めるまでの時間で書く
• 公開前に何度も読み直して校正する
• 公開後でも校正する
• わかりやすい記事を書くためには
• 読者ファースト: 困っている人を想定して書く
• その技術のおいしさを引き出せる、実践的な例を出す
• 文章とコードをバランスよく配分する
• タイトルは超重要！
• Qiita とブログの使い分け
• Qiita は技術が主役
• ブログは自分が主役
• Twitter と YouTube の使い分け
• 参考: 初期のブログ
• 何が起きるの?
• お金の話
• 技術記事とお金の話
• お金より、信頼やレピュテーション
• 技術記事Q&A
• Q3: 執筆時間を短くするコツは?
• A: 時間を気にしたことがない。それよりもわかりやすさ重視
• 描き続ければ基本的な速さは身につく
• Q4: 反響がなくてよくヘコみます。これを克服するには?
• A: 狙ってもどうせ当たらない。1件でも反響があれば成功と考える
• Q5: 描きたいけどかけない。時間もない。どうすれば?
• A: タスク管理をしっかり。
• まとめ
• まとめ (ふたたび一般論)
• 最後に追加アナウンス: 「プロを目指す人のためのRuby入門」という本が2017年11月発売予定
• Rubyistと技術記事 // #kanrk2017 // Speaker Deck

子どものためのプログラミング道場「CoderDojo」を支えるRails CMSの活用事例

• 上の5階でやっていた様子を取材してきた
• 子供同士も含めたコミュニティ
• 全国各地でやっている (85 以上、今年中に 100 を超えそう)
• 世界中でやっている (1200 以上)
• 本日の話
• CoderDojo とは (済)
• なぜ Rails + CMS?
• Scrivito の活用事例
• なぜ Rails?
• 初期は GitHub Pages で生成
• デザイン改善 + Parse 利用
• Parse 終了のお知らせ
• 要望や状況を整理するよい機会だった
• コミットしているのが2人 (実際は1人) だけだった
• 状況の変化に対応しやすい Rails
• ドキュメントも多い
• Rails Tutorial, Rails ガイド
• 翻訳をやっているのは弊社
• ただ Rails の学習コストは高い (と思う)
• CMS?
• 様々なコントリビュータ
• 「エンジニア」じゃなくても貢献できる
• Scrivito: Cloud-Based Rails CMS
• Rails に Scrivito gem を足す
• ブラウザーで編集できる機能を追加できる
• コントリビューターが以前2人が今は15人
• Scrivito の活用事例
• CoderDojo Japan 公式本
• 大枠を Rails 側の view で作って、各章の担当者が該当する部分の文言を直接編集
• https://coderdojo.jp/kata の「2017年1月には全国で70ヶ所以上」を「2017年5月には全国で84ヶ所以上」に更新するデモ
• https://github.com/coderdojo-japan/coderdojo.jp
• https://speakerdeck.com/yasulab/coderdojo-wozhi-eru-rails-cms-falsehuo-yong-shi-li

スポンサーセッション

Ruby開発さんのスポンサーセッションでした。

基調講演: 18年でRubyから学んだこと

• 自己紹介
• 風呂グラマー
• IT芸人
• Ruby歴 18年ぐらい
• 一番好きなメソッド: method_missing
• 次は define_method, その次は eval
• 局所的に綺麗にかけるものが好き
• dRuby
• ずーっとユーザ
• gem も 1 個だけ pr_geohash
• mruby
• 1999年: i-mode など
• Ruby本が立て続けに出た時期があった
• オブジェクト指向
• Ruby に教わったこと
• 2000年代前半: PHPでPukiWiki作ってた など
• 伽藍(がらん)とバザールだけでも良いので読むのをおすすめ
• 元の作者から引き継いでコミュニティを作って、年末には別のコミッターに渡した
• Windows でも頑張ってた
• wxWindows とか QT 使って GUI アプリ作り
• exerb 使ってパッケージング
• ActiveScript Ruby
• Ruby on Rails
• 2004/07 - DHH が公開
• 2005年頭ぐらいに発見
• すごい! Ruby で Web アプリがキレイに作れる
• 2005年から Ruby 漬け: Rails を試して, ブログ書いて, 雑誌に記事を書く
• OSC Hokkaido 2005
• たぶん初めて Matz を見たのはこのとき
• 英語で質疑応答していた
• 10分で作る Rails アプリ for Windows
• 編集ソフトがなかったので無編集
• 本当に10分でできるというのを示す意味もあった
• typo とかで何度もとりなおした
• pingking.jp
• @nifty の about me
• RailsConf 2006
• 初めての海外
• 英語力ゼロ
• リアル Ruby 友達もほぼゼロ
• 初の海外カンファレンス
• スライドのキーワードでなんとなくわかる
• 内容はRails勉強会@東京の方がすごいのでは?
• Ruby歴なら絶対自分の方が長い
• なら渡米しよう
• 色々あって2008年渡米
• 結局英語は喋れるようにはならなかった
• Seattle.rb
• 英語わからないけどなんとなく参加して覚えた
• 英語はブロークンな20代の若者の英語が身についた
• Appcelerator へ転職
• 知り合いのいないコミュニティーで活動したい
• Node.js と Titanium Mobile
• Titanium Mobile にパッチ送ったりチャットで話ししたりしているうちに中の人に
• GitHub のスターが多かったからだとあとで聞いた
• 影響を受けた人: matz さん, hyuki さん (スライドではアイコンだけ)
• どちらもキリスト教の人
• テクノロジーに愛を謳う
• ロジカルじゃない
• MINSWAN = Matz Is Nice So We Are Nice
• 心理的安全性
• Matz はストーリーを語るのが上手い
• DHHも
• こういうのがうまい人は抽象化がうまい
• 初めてのRuby本体への貢献
• mruby
• RubyConf 2010 で聞いた
• そっから進捗を全然聞かない
• 2012年のリリース前時点の private repo のアクセス権をもらった
• やること多数
• GitHub 以後の開発コミュニティ
• MobiRuby
• MobiRuby のもくろみ
• Matz にはなれない
• あきやすいので無理だった
• 手離れよく作ることを考えるようになった
• Ruby から得たもの
• 一番大きいのは「軸」
• https://speakerdeck.com/masuidrive/18nian-derubykaraxue-ndakoto-guan-xi-rubyhui-yi-2017

クロージング

時間がなかったので、Ruby 関西の宣伝などはなく、前に集まって写真撮影のみでした。

懇親会

事前に予告されていた通り LT がありました。 本編でスポンサーセッションがなかったスポンサーの LT もありました。

前にどこかで聞いたことあるような内容もありましたが、いろいろな話があって楽しめました。

特に何も準備していなかったのと MacBook Pro の電池が残り少なかったこともあり、特に LT はしませんでした。

全体的な感想

RubyKaigi 2015 の T シャツを着て行ったのですが、上にもう一枚着ていたので、知らない人にはただの寿司の T シャツにしか見えないような気がしていました。 一部の人には背中の Committer と書かれている部分を見せたりできたので、着て行った意味はあったと思いました。

会場は9時にならないと鍵が借りられなかったり、撤収完了の時間が決まっていたり (ロビーに残っているのは OK だったらしい)、プロジェクターでトラブルがあったり (ミラーリングかどうかが影響したらしい?)、電源が不十分だったり (これは各自できるだけタップを持ってきてくださいとアナウンスがあればよかったのかも)、などの問題点はありましたが、迷わずたどり着けたり (途中でひがきさんにあったので入り口を自分で探さなくてよかったのも幸いした)、マイクなどの設備も整っていたり、撤収時に椅子やテーブルは特に気にしなくてよかったりしたのはよかったと思いました。

全体の進行は時間がおしてしまって、それを取り戻すために減らす休憩時間の余裕もなくて、最後まで時間が足りないままでした。

発表の内容はどれも面白く、twitter でもハッシュタグがトレンド入りしていたらしいというぐらい盛り上がっていたようです。

@nifty の about me は使っていたので懐かしいと思いました。 @nifty で Rails を使っていると前面に打ち出していたのは、他に @nifty TimeLine があったのも思い出しました。