Sapporo RubyKaigi 2012 スペシャルレポート

札幌Ruby会議2012,2日目レポート[更新終了]

この記事を読むのに必要な時間:およそ 18.5 分

Shota Fukumori (sora_h)さん「Social Coding をはじめよう」

元「中学生」Rubyコミッターとして知られるsora_hは実践的なGitHubの活用法について発表しました(スライド等はこちら)⁠現在はアルバイトとしてCookpad社に勤め,⁠中卒フリーター」を名乗っています。

GitHubはどこがソーシャルなのか

はじめに「GitHubの回し者ではない」と断った上で,今回のセッションではGitHubを使ったソーシャルコーディングについて解説を行いました。⁠GitHubのアカウントを持っている人は?」と会場に挙手を求めると,会場のほとんどの人が手を挙げていました。また「GitHubに積極的にコードを置いている人」⁠Pull requestをしたことがある人」⁠プライベートリポジトリを使用している人」などにも少なくない数の人が手を挙げました。

GitHubではTwitterのように人をフォローしてダッシュボードにコミットが流れてくる,プロジェクトに"star"(お気に入り)をつける,"watch"して議論を追う,コミットにコメントを残せる,などの機能があります。しかしGitHubを「ソーシャルコーディング」たらしめるのは"Fork"と"Pull Request"ではないでしょうか。

"Fork"とは,他の人のリポジトリをフォーク(分岐)して,自分のリポジトリにコピーする機能です。このリポジトリは自分専用にカスタマイズしたり,パッチを書くために活用することができます。そして"Pull Request"です。これはパッチをFork元のリポジトリに送るための機能です。"Pull Request"の"Pull"とは,`git pull`の"pull"です。ただし,後述しますが,Pull Requestは同一リポジトリの別ブランチにも送ることができます。

GitHubではパッチを送る手順は「forkする」⁠コミットする」⁠pushする」⁠そして「Pull Requestする」です。この方法を一度覚えておけば,あとはどのリポジトリに対してでもスムーズにパッチを送ることができるようになります。

Pull Requestのベストプラクティス

ここからが本題で実際にPull Requestを送るためのベストプラクティスを紹介しました。

まず,使用しているライブラリなどに不満を抱いたとします。例えばバグがあった,ほしい機能がないなどの理由です。GitHubでリポジトリのページを開き「fork」ボタンを押します。押したら自分のリポジトリを`git clone`しましょう。コードを編集する前にトピックブランチを切ることを忘れないようにしましょう。`git checkout -b foo master`でmasterから新しくfooリポジトリを作成することができます。

コードが完成したらコミットしてGitHubにpushします。そしてブラウザでGitHubに戻り,ブランチを選びます。このときに'wキー'を押すとマウスを使わずにブランチを選ぶことができます。変更を加えたリポジトリに切り替えたらPull Requestボタンを押し,タイトルと概要を書いて送ります。

Pull Requestのタイトルはパッチの内容を簡潔にまとめます。バグならば,概要にはバグを再現する最小手順を書きます。確認する方にも再現コストがかかるので,可能な限り単一のbug.rbなど小さなスクリプトにまとめると良いでしょう。また,⁠何が起きたのか」⁠何を想定していたのか」説明することも必須です。

機能追加した場合は,その機能が何に使えるのか,どう使うのかを説明できると良いと言います。プロジェクトによってはテストコードが必須の場合があります。Pull Requestを提出したあとでも追加コミットをpushすれば反映されますので,指摘されたら直しましょう。時間がかかりそうなら「テストはいま書いてます」などと書けばよく,指摘されても怖がらずに対応しましょう。また,GitHubではMarkdownという形式が使用できるので,項目ごとに「Use case」⁠Usage」など見出しと読みやすくなるとしました。

おもに日本人向けのベストプラクティスとして,日本人が相手でも英語で書くことを挙げます。日本語を併記しても良いですが,英語でも書きましょう。できないなら勉強が必要ですが,コードで語ることがとても有効ですので,拙い英語でもコードで伝えることはできるでしょう。また"I want this method!!!!!!!!!!!!!!!!"で取り込まれた例もあり,人と場合によっては熱意で通ることもあるそうです。ここまで来れば,あとは「send」ボタンを押すだけです。反応を待って,修正や質問などのフィードバックがあれば真摯に対応しましょう。

GitHubの活用について

冒頭でプライベートリポジトリの使用について会場への質問がありましたが,有料のプランにすると外部から見ることのできない非公開のリポジトリを持つことができるようになります。学生の場合は無料で使用することができるとのことで羨ましいと言っていました。 また,企業のイントラ内でGitHubを利用したい場合は,値段は張りますがGitHub:Enterpriseを利用するなどのプランが用意されています。これらのプランすべてで,もちろんPullRequestの機能を使用することができます。

また,hubというコマンドラインツールがあり,これを使用することでブラウザを開かずにシェルからgithubの機能を使うことができるようになります。例えば「既存のissueにパッチを添付してPull Requestを送る」という操作を行うことができ,便利とのことでした。

画像

画像

辻本和樹さん「Pattern Matching in Ruby」

Rubyには無いパターンマッチについて,Rubyコミッタの辻本和樹さんが発表しました(スライド等はこちら)⁠

Ruby2.0のリリースが2013年2月24日に予定されています。Ruby2.0というのは,長らくRuby開発者にとって遠くにある目標,言わば人参のようなものでした。

2.0のリリースがされると,その遠くにある目標がなくなってしまいます。そこで,次なる目標としてパターンマッチを入れるのはどうかと提案しました。辻本さんはこの発表,この提案が新機能の議論の下地になることを期待しています。

パターンマッチとは

パターンマッチについて,Rubyの多重代入のコードを例示して説明しました。そして次の3点を多重代入の問題点として挙げました。

  • Arrayに限定されること
  • 個数の確認ができないこと
  • 途中の式を拾えないこと

多重代入の問題点は,次のように言い換えることができます。

  • 分解機能が弱い
  • 照合機能がない
  • 代入機能が弱い

パターンマッチによってこれらの問題点を解決することができるそうです。

Rubyにおけるパターンマッチ(本題)

辻本さんは,自作のライブラリであるpattern-matchの基本的な使い方とともにテキスト処理の利用例を紹介しました。また,パターンマッチがある場合とない場合のソースコードをユースケース別に複数提示しました。例えばCSVや木構造の処理を比較的簡単に書くことができます。パターンマッチがある場合は,処理すべきテキストのパターンに集中すればよいため,よりシンプルにプログラムを書くことができます。

新機能としてRubyのコアに取り込みたい理由

パターンマッチを実装することで,Rubyのプログラムをよりわかりやすく書くことができるため,Rubyのコアに取り込みたいと考えています。しかしながら,現状の実装ではmethod_missingを多く利用しているので,実行が遅かったり問題があるかもしれないと考えています。

まとめ

パターンマッチはとても強力なので,辻本さんが発表で例示したユースケースだけでなく,実際にユーザーがライブラリを利用して得られるパターンマッチのユースケースを共有して,コアへ取り込んでもらう際の説得材料としたい。そのために皆さんでパターンマッチをたくさん使ってもらいたいと締めくくりました。

画像

画像

Aaron Pattersonさん

@tenderlove,たこやき仮面(ruby-list メーリングリスト)などでも知られる,著名なRubyist Aaronさんによる「サラミ」の発表です。

It my turn

Aaronさんは,⁠ruby conf」で日本人が英語で発表しているのをみて,自分もいつかは日本語で発表したいと思っていたそうです。6年間日本語を勉強してきて,ついに今日,それが達成されました。

「ゆっくり喋りますので,もし間違えても恥ずかしいので翻訳しないでください」の一言で会場が爆笑の渦に巻き込まれていました。実際,彼の日本語はとても丁寧で分かりやすいものでした。

We Eat

「食べることは楽しい」⁠友達と作った料理を食べるのはもっと楽しい」⁠危ない料理はおいしい」⁠おいしい(=食中毒になりそうな)サラミを作るのが好きなAaronさんですが,自分が作ったサラミで友達を殺したくはありません。衛生管理について十分な予習をした後実際のサラミ作りを行なったそうで,そのことについてアツく語ってくれました。

「良いバクテリア」は酸性の環境をつくり,悪いバクテリアを育たなくすること。良いバクテリアがサラミの味を形成すること。そのために肉に対して重量比で0.012%のバクテリアを投入しなければいけないこと。塩を入れて悪いバクテリアの繁殖を抑えること。0.0143%の亜硝酸塩を入れることでボツリヌス菌を発生させないこと。水分を蒸発させることで悪いバクテリアを退治させること。温度ははじめの3日は良いバクテリアを培養するため21度,その後30日は15度に設定すること。

それぞれをあまりにもマジメに,しかも日本語で語るもので,会場は大爆笑です。

サラミ作りでは冷蔵庫の温度管理がとても重要です。サラミ作り専用の冷蔵庫を用意し,モニタリングするデバイスまで作成してしまいました。

ここまで,まだRubyのRの字も出てきていません。

We Play

食べることは楽しいです。でも,サラミ作りのデータを解析したら,もっと楽しいとAaronさんは考えます。データはデジタル信号で送られてくるので,それを解析します。

そして,解析したデータを紹介されました。室温の推移状態で,Rを用いて算術平均を求めることで正規化した情報を求めます。室温は12度から15度に推移していることを説明されていました。高速フーリエ変換を用いてスペクトル密度を求めていたり,上限実数の位置を求めたりもされていました。

良く分かりませんが,すごいことをやっていたようです。やっとRが出てきましたが,RubyのRではありませんでした。

We Code

ここで「集まったサラミ用データをシェアしましょう。Rails4で」と言い出したAaronさん。

リアルタイムシステムは,入出力のオブジェクトで簡単にリアルタイム処理ができるとのことです。AaronさんはPipeとThreadを使って実装されていました。1秒ごとにパイプにデータを送るようなスレッドを作り,スレッド内では送られたデータを即座に読み取ります。Aaronさんは,これが一番簡単なリアルタイムシステムの実装だと考えているそうです。

アメリカでは「The Cloud is a series of Tubes.」という言葉がありますが,Aaronさんは「The Cloud is a series of Pipes.」と思うとのことです。なぜなら,RailsにPipesと同じように機能してほしいと思っているからだと仰っていました。⁠ActionController::Live」を使うことでRailsにIO.pipeと同じようなことをさせることが可能のようです。

HTML5の機能であるSSE(Server Sent Events)を使うことでサーバーのイベントをブラウザに送ることが可能で,クライアントはJavaScriptで実装されていました。ただしIEでは動かなかったようです。コード上では,IOオブジェクトのように記述していますが,実際のサーバーとクライアントとのやり取りではオブジェクトとレスポンスをSSEに書き込んでいます。

まずサラミを収めた冷蔵庫(Publisher)のデータをcreateアクションでBusに知らせます。Busはイベントを複数のSubscriberへ知らせることができ,Thread内では共有される仕組みになっています。

ブラウザ(Subscriber)はあらかじめBusに対してイベントを登録しておくことで,サラミを収めた冷蔵庫がデータをBusに知らせたら,すぐにそのデータを受け取ることができます。データは,サーバからSSEの形式でブラウザへ送られてきます。

最後にサーバからクライアントへ送った値を分かりやすくするために,GChartを使うことでグラフにされていました。

終わりに

このスライドは今回の札幌Ruby会議のテーマである「We Code」を表したものであり,このスライドが共有されることが目的であるとのことです。今回発表したサラミのデータを共有する話からも,みんなでデータを共有したいからこそできたものだと感じているそうです。

また,Rails4はまだ開発途中ですが,リアルタイム処理が強化されそうなことが良くわかることから期待が膨らみます。

画像

画像

著者プロフィール

KaigiFreaks レポート班

KaigiFreaksとは,会場に来れなかった人にも雰囲気や内容を楽しんでもらえることをミッションとする特別編成チーム。配信班とレポート班の2班で構成される。レポート班の作業はエクストリームスポーツとして知られていたが,今回はその評判を覆すべく史上最大規模の編成で臨む。


前鼻毅(まえはなつよし)

Ruby札幌,アジャイル札幌,CLR/Hなど札幌のコミュニティで活動中。RICOH IT SOLUTIONSにてRubyやObjective-Cのコードを書いている。

twitter:http://twitter.com/sandinist


にく

北海道出身で沖縄や東京に住んだ後,今は札幌在住のプログラマ。コンサドーレ札幌が好き。Ruby,Emacsが心のメインツール。最近はHaskellを試している。

twitter:https://twitter.com/niku_name
blog:http://niku.name/


小野寺大地(おのでらだいち)

北海道大学大学院,一般社団法人LOCAL,Ruby札幌あたりで活動中。普段は複雑ネットワークの研究をしていて,肉チャーと二郎系ラーメンをこよなく愛している。

twitter:http://twitter.com/onodes
facebook:https://facebook.com/onodes


H.Hiro

北海道大学大学院在籍。Ruby札幌,札幌C++勉強会などで活動中。コレクションの要素数を数えるのに便利なライブラリ「multiset」などを作っている。Rubyで好きなものは「ブロック付きメソッド呼び出し」「Domain-Specific Languageの文化」。

twitter:http://twitter.com/h_hiro_


小玉直樹(こだまなおき)

生まれも育ちも札幌のプログラマ。RubyにハマってからはWebアプリを作るのが楽しくて日課になっている。1年ほど前からコミュニティ活動にも参加を開始し,素敵な技術者と出会える日々に感謝。

twitter:https://twitter.com/volpe_hd28v
blog:http://d.hatena.ne.jp/koda_hd28v/


うさみけんた

いまをときめく自宅警備員…だったのですが,Ruby会議の半月前に退職して東京に移住しました。Python札幌などでも活動。セキュリティ&プログラミングキャンプ2011言語クラスチューター。函数型言語の浅瀬で溺れる。

twitter:http://twitter.com/zonu_exe
blog:http://d.hatena.ne.jp/zonu_exe


すずきゆうすけ

札幌市に隣接する風の街・江別市で働く自営業。Ruby札幌にときどき顔を出す。Garage Labsにもときどき出没。プリキュアと朝ドラをこよなく愛し,日々変動する体重に怯えるごくごく普通のアラフォー。

twitter:https://twitter.com/yuskesuzki


みぃお

一般社団法人LOCALで主に活動中。お家でRubyをちょくちょく書いている。男の娘。お仕事はPHPでソーシャルゲームを作っている。

twitter:https://twitter.com/ayako119
homepage:http://miio.info/


永沼智比呂(ながぬまちひろ)

首の長いプログラマー。達人プログラマー読書会を主催したりしていた。Ruby札幌やSapporo.js,アジャイル札幌に参加。Ruby界隈の文化って面白い!

twitter:https://twitter.com/onjiro_mohyahya
blog:http://onjiro.blogspot.jp/


わたなべしゅうじ

札幌在住のプログラマ。札幌Javaコミュニティ代表。Java,Ruby,Python,JavaScriptなどを扱い,ユニットテストが好物。

twitter:https://twitter.com/shuji_w6e/
blog:http://d.hatena.ne.jp/shuji_w6e/


菅井祐太朗(すがいゆうたろう)

北海道から上京して一年。ようやく仕事でRubyを使えそう。Ruby札幌,Asakusa.rb,Yokohama.rbなどに顔を出している。

twitter:https://twitter.com/hokkai7go
blog:http://d.hatena.ne.jp/lncr_ct9a