RegionalRubyKaigi レポート (33) 東京 Ruby 会議 10

初稿：2013-02-24

RegionalRubyKaigi レポート東京 Ruby 会議 10

開催概要

開催日: 2013/01/13(日)〜14(祝・月) 2日間
開催場所: 千葉市美浜文化ホール
主催: 東京Ruby会議10実行委員会
公式ページ: http://tokyo10.rubykaigi.info
公式ハッシュタグ: #tkrk10

はじめに

東京で 10 回目の開催となる地域 Ruby 会議「東京 Ruby 会議10」が2013 年 1 月 13 日、14 日に開催されました。東京 Ruby 会議 10 は、「話そう、集まろう、いつもの Ruby、日常の Ruby」のテーマをもとに、Rubyist の日常にまつわる発表が数多く集まりました。また、給電所ではごろごろしながらコードゴルフに取り組む Rubyist の姿を見ることができました。なかなか見ることができない自分以外の Rubyist の日常を垣間見ることができたのではないでしょうか。 1 日目は無事開催されたものの、2 日目には東京地方の降雪により交通機関の乱れがあり、 1 月 14 日の 14 時時点で 8 セッションを残し中断することになりました。今回のレポートでは、中断されるまでの東京 Ruby 会議 10 の様子をお伝えしたいと思います。

一般講演 (1 日目)

Ruby と過ごした半年間

井原正博 (@ihara2525)

3 年前にクックパッド株式会社に入社した井原正博さんは最近 4 ヶ月でやったことの紹介をされました。

国内最大のレシピサイトクックパッドには現在コミュニティというものがないので、「みんなのカフェ」という掲示板のようなサービスを作られました。全ての投稿を井原さんが承認されており、24 時間自分一人でやってらっしゃるそうでこの発表中もコミュニティに投稿がきててはやく承認しないととおっしゃる姿に開場内から笑いもあがっていました。

基本的企画・開発・運用は全て井原さんにひとりでされたそうです。技術的には Ruby1.9.3/Rails3.2.11/CentOS/nginx+Unicorn/MySQL を使っています。クックパッド本体とは完全に別アプリケーションです。

サービスを作るためにまず復習の意味も込めて、言語 (Rails のガイド/チュートリアル/コードスクール) や Web サービスを作るのに標準的な技術 (git/RailsCasts のビデオを見る/各種書籍) の勉強をしたとのことです。

その結果作成したアプリケーションのソースコードは約 3000 行。期間は3週間くらい。アプリケーションを作成する上であってよかったものとして、 Rails をはじめとするフレームワークや RubyGems また GitHub などのソーシャルコーディングのツール、そして Stack Overflow を挙げました。これらのサービスは今や落ちると仕事進まないくらい助けになっているそうです。一からサービスをつくってみて、ユーザーひとり一人がとても大事というの改めて感じられたそうです。

最後に。やりたいことをやりましょう。今作りたいものがあるなら作ってみましょう。僕らはコードを書いて形にすることができる人間であり、 Ruby をはじめとする仕組みは自分たちの背中を押してくれる助けとなるのだからと纏められていました。

やさしい Rails 勉強会 @ 東京のつづけかた

takkanm (@takkanm)

株式会社永和システムマネジメントの takkanm さんが、Rails 勉強会 @ 東京を続けていくために考えていることや、改善のために行ったことを発表しました。

開催するときには、参加者に何か話して帰ってもらいたいという点に気をつけていると言いました。話を聞いているだけでは、参加者のモチベーションにつながらないので、休み時間を長めにとって、コミュニケーションを活発にする工夫を紹介しました。

勉強会を続けている理由を、「長く続いてきたものを繋げてく」ことと、知らない面白い人に出会えるからと紹介しました。しかし、勉強会を続けていくとやめたいなと思う時がくるとも言いました。理由としては、開催することが目的化してしまうことや、開催するための形態がスケールしないことを挙げました。どのように勉強会を続けていくかを考えると、勉強会をホストする意識が高まって、参加者の満足のために動いていたことに気が付きました。自分が勉強したいことを扱うことで、もっと自分が楽しめる会にしていきたいと話しました。

最後に、会場の皆さんへのメッセージを送りました。

勉強会を続けていくと何で続けるのか疑問に感じることがあるかもしれませんが、なんで始めたのかを思い出してふりかえるのがいいと思います。楽しめないなら、やめてしまうのがよいと思います。楽しんでやりましょう。

Rails 勉強会 @ 東京の続け方というタイトルの発表でしたが、発表された内容は勉強会やコミュニティ全般で活かすことができるはずです。

趣味と Ruby と私

生井智司 (@ainame)

株式会社ミクシィの生井智司さんは、趣味として Ruby を勉強してきて感じたことを話しました。

生井さんは大学の学部生時代の研究で Ruby と出会い、Ruby 会議 2011 に参加した際に Ruby とコミュニティに魅力を感じ、勉強会で発表がしたいと思うようになりました。しかし仕事では Perl を使っているため、仕事以外の時間、つまり趣味として Ruby を愛用していこうと決めます。

生井さんは Ruby で不満駆動開発 (FDD) をしています。自分が不便だと感じた事を、Ruby で解決しようというものです。例えば、会社のスケジュール管理ツールの問題です。会社のスケジュール管理ツールが非常に使いづらく、複数案件の締め切りが重なると口頭で締め切りを確認し合うなど、コミュニケーションのコストが高くなっていました。生井さんはこの問題に対し、Ruby on Rails で新しいスケジュール管理ツールを作成しました。この管理ツールは chatroid.gem で IRC に繋ぎ込んでおり、IRC で毎朝 10 時にスケジュールをリマインドをするなど、自動的にスケジュールが把握できるような仕組みも備えています。このツールが完成しなければ死んでしまう…！と思い込んで開発するという追い込み方が非常にユニークです。

しかし、Ruby を使った開発は趣味で行っているため、モチベーションの維持は重要な問題です。生井さんは、仕事では Perl、趣味では Ruby というようにプログラミング言語を使い分け、家では一切 Perl を書かないというスタンスでモチベーションを維持しています。他には地域 Ruby コミュニティに参加したり、情報発信のしやすい Twitter で思っている事をつぶやいたりしています。検索する前につぶやいてしまう、というスタンスで、思いがけない情報が得られる事もあるそうです。

特に Twitter では、勉強会ネタをつぶやくと賛同者が現れ、それをもとに勉強会を開催することがあるそうです。勉強会を開催することで生まれる人との繋がりを生井さんは大切にしています。また GitHub のプルリクエストを通じて人と知り合い、この繋がりで WEB+DB PRESS に執筆することが出来たことを報告しました。

直近では、「会社によらないコードレビュー会を開いたらどうか」と Twitter 上でつぶやいたところ、賛同者が何人も現れたそうです。勉強会の開き方やモチベーション維持の方法など、Ruby を学ぶ際には皆さんもぜひ生井さんの方法を参考にしてください。

プログラミング未経験なんて怖くない

田垣亜季 (@akiinyo)

株式会社永和システムマネジメントの田垣亜季さんが、プログラミング未経験でも恐れずに仕事としてのプログラミングを進めていく 3 つの方法について発表しました。

仕事を始めて 1 点目に取りかかったことは「真似する」ことだと話しました。やりたいことに似ているコードを信用できるマスターブランチから探して使っているうちに自然とソースコードを読むようになり、次第にコードの書き方がわかりレパートリーが増えたことを紹介しました。

2 点目が「形から入る」ことだと言いました。社内の「意識の高い人」が実践している「テストを先に書くこと」をわからないながらも自分でもやり続けてみると、良さがわかった時にはやり方にも慣れていて仕事がやりやすかったと話しました。

3 点目は「途中経過を見せること」だと話しました。Pull Request が大きくなりそうな場合は Cucumber でのエンドツーエンドのテストを書いた段階で Pull Request を投げることで、早期に勘違いや誤りに気付けることが大事だと話しました。

これらの方法を実践し続けていくうちに、 Pull Request のレビュー結果にエビフライの絵文字がもらえるようになってきたと話しました。エビフライの絵文字は多分 OK という意味らしいです。

プログラミングの経験が無くても信用できるコードや先輩にならうことでプログラミングの世界に恐れず前向きに接していくことができたこのお話は、ビギナーやベテランを問わずとても励みになるでしょう。

周囲の助けを得ながら楽しく開発するためのアレコレ

蓮尾高志 (@thso83)

2012 年 7 月にメーカーエンジニアから株式会社万葉に転職し、 Ruby on Rails での開発やインフラエンジニアの仕事を始められた蓮尾高志さんは入社直後は Web 開発を始めたばかりなこともありわからない事が多く、人の助けを得ないと何も進まない状況だったそうです。
しかし人に助けてもらうことはその協力者にも負担を強いることになってしまうという悩みをもたれたそうです。そこで楽しい開発ができるよう負担を軽減すべく色々工夫をした経験を発表されました。

ペア作業時の互いの開発環境の違いや不慣れな作業の説明を克服する工夫
- wemax を活用し、相手にリモートからログインしてもらい、慣れたマシンを使いつつ相手に自分の状態を見てもらえるようにした。
一時的にメンバーをアサインしたいときなどに手軽に開発環境構築を簡単にする工夫
- 手軽に VM をコピー出来るツールを Sinatra をベースに作成。ブラウザでアクセスしたらインポート用のスクリプトが生成され、実行すると手軽に開発環境ができるようにした。
状況に応じて、適切なメンバーに助けを求められるようメンバー特性の客観的に可視化
- 社内 twitter (Leafy ) のログを Ruby による形態素解析で名詞抽出し、 LDA によるトピック解析しメンバーのプロファイルを作成。関連度をグラフで表示するようにした。
ペア作業時に自分の緊張状態をさりげなくアピールする工夫
- フリスクケースに内蔵したデバイスを使い、赤外線センサーで血液中のヘモグロビン変化を計測。脈拍に合わせて Caps Lock の LED を点滅させ伝える。更にリモートの場合でも状態を知ってもらえるようプロンプトにも表示するようにした。

この赤外線センサーまで使った工夫には会場のみなさんも驚いたようで、会場内から拍手がおきていました。

このように、日々のちょっとした工夫によって楽しく開発ができたり、色々な案件を抱えている会社での助け合いが活発になり、本来備えた柔軟な組織力を100％発揮できると感じたそうです。このような工夫はそれぞれの環境でためしてほしい。そしてシェアしましょう。そうしたら楽しいコミュニティになるのではとおっしゃっていました。

「co-meeting の作り方。」

吉田雄哉 (@yuya_lush)

吉田パクえさんこと吉田雄哉さんが、普通の会社員4人が起業を決意してから今日までの奮闘記を発表しました。

吉田さんは株式会社 co-meeting の取締役 CTO で、最高喋り責任者 (Chief Talk Officer) として各地を飛び回り活躍されています。co-meeting ではグループコラボレーションサービス「co-meeting」やソーシャルコミュニケーションサービス「CROWY」を提供しています。

サービスを立ち上げて起業する場合、まず、技術力とのバランスを取ってくれる経験のあるメンターがいた方がよいと言います。仲間が真剣であればあるほど、外部から冷静にアドバイスをしてもらえる人が必要とのことです。深くコミットをしてくれる人とのコネクションを用意するべきと述べました。

次に、ツールの積極的な活用を提案します。これが最も重要なポイントと言います。コスト削減や最適化、時間の有効活用、コミュニケーションを取るためにはツールの使用が必要不可欠と言います。また、意思統一のためにビジネスモデリングの手法を取り入れることの重要性にも言及します。開発手法だけでなく別の思考を取り入れることも重要とのことです。

3 つ目として、自分たちの価値を最大化するために、クラウドを活かした方が良いと言います。自分たちがやるべきことに注力するために、自分たちのスキルセットを把握したうえで、それから外れた作業は取捨選択するべきだと強調しました。

最後に吉田さんは参加者に、自分たちの学びを活かして価値の転換を図り、その学びを他へ活かして欲しいと、メッセージを送ります。「一緒にやりましょう」と力強く締めくくりました。

初心者エンジニアのスタートアップにおけるシステム構築の失敗

春山誠 (@Spring_MT)

株式会社 10xlab の春山誠さんは、前職でエンジニアに転向。転向前まではコードは書いた事がなく、営業などをされていたそうです。

以前の職場での開発環境は言語は perl、フレームワークは独自のものがありましたが、それに対して今の現場では、なにもない 0 からのスタートでした。そこでフレームワークを選定する際にテスト周りの環境が揃っており、新しくチームに加わる人の学習コストが低い Rails を選定しました。本音としては、Rails を使って開発をしてみたかった部分が大きかったようです。

Rails でアプリを作り始めようとした際に、様々な問題を想起して解決に取り組みました。例えば複数の DB 対応、master/slave の振り分け、belongs_to の扱いなどです。手間も大きく、いきなり大きな事を考えすぎたと反省しているそうですが、一つずつ方針を立てて解決に取り組みました。

しかし想定外の個所で、いくつも課題が発生しました。その中でも大きなものは Validation をどうするかというもの。ユーザーが直接入力した値をチェックするものと、DB に格納する前のデータをチェックするものそれぞれをどのようにするかです。

この対策として、DB に格納する前のデータのチェックは今まで通りの ActiveRecord の Validate を使い、ユーザーが入力した値のチェックはリクエストを受け取った直後が望ましいと考え、 controller の before_filter で行うことに決定。モデル以外で Validation するために data_validator という gem を作りました。こちらは GitHub でも公開しています。他にもいくつかの gem を作り、様々な問題解決に利用しています。

質疑応答時の Rails をやめようと思った事はあるかという質問に対し、何回もあるけれど、それでもモチベーションを保てたのは、テストをちゃんとかいていたので他のフレームワークに移すくらいなら Rails をうまくつかっていった方がいい。そして DB まわりの処理や ActiveRecord が便利だったので使い続けることにしたと答えていました。

Rails向けモバイルアプリ開発フレームワーク kanna (旧名：Pera) をリリース！

松村章弘 (@mat_aki)

「DRY じゃないコードは嫌い」な株式会社ソニックガーデンの松村章弘さんが、Rails 向けモバイルアプリ開発フレームワークである kanna (旧名： Pera) についての紹介と、kanna を使ったサンプルアプリ実装例について発表しました。

kanna を作ることになったきっかけについて、Rubyist のモバイルアプリ開発事情の現状を交えて話しました。Ruby で実装できる方法は増えてきたものの Ruby on Rails を活用した方法が無いこととネイティブコードでの実装はノウハウ学習が困難なことが主な理由だと言いました。

kanna はコンセプトが「Rails の中にあるかのようにアプリ開発」で、Rails でアプリを開発しているのと同じ感覚でモバイルアプリを作れることを目指しています。Rails と PhoneGap (Cordova) をつなぎ、rake での雛形作成や iOS アプリのビルドができ、開発環境のブラウザでアプリデバッグが可能な点が特徴です。

kanna を使った実装例として「Photostock」という iPhone にたまった膨大な量の写真を Amazon S3 に一括アップロードするアプリについて紹介しました。PhoneGap のプラグインの仕組みの良さや画面の作成が楽だという利点が大きく、開発期間は一週間の実働 25 時間程という短期間で行えたと話しました。

Rails を採用しているプロジェクトでモバイルアプリを作る方や Rails でのアプリ開発に慣れ親しんでいる方は、kanna の検討・導入を考えてみてはいかがでしょうか。

The Everything Machine

中村涼 (@r7kamura)

クックパッド株式会社の中村涼さんが、Ruby を Web フレームワークだけではなく、もっと日常生活で役立てたい！という思いから、中村さん自身が作成した様々な gem を紹介しました。

プログラミング初心者によくある問題として、プログラミングを学んだ後、いったい何を作ったらよいのかが分からない・思いつかないという問題があります。これに対して中村さんは、日常生活には色々な問題があり、それらの多くは Ruby で解決できると言います。

中村さんは、些細だけれど自分にとって重要な問題を、Ruby の gem を使って解決しています。モチベーション維持のため、一週間以内で作れる規模のものを作成されているそうです。

紹介された gem は、ユニークなものが多くありました。例えば中村さん自身が「朝起きられない」という問題を抱えているのに対し、起床時間に Ruby のプログラムで照明・暖房・テレビ・カーテンなどの家中の家電を操作する iremocon.gem を作成しました。カーテンについては、モーターを操作してカーテンレールを引っ張るという手の入れ込みようです。

また、「夜帰宅したら寒い」という問題に対し、Ruby から自宅の家電を操作して家の暖房が勝手に付く chatroid.gem を作成しました。 chatroid.gem は twitter bot フレームワークで、「帰宅なう」などの呟きから位置情報を取得し、家電を操作する事が可能です。この仕組みを使えば逆に家電をオフにする事も可能なので、家を出た際に家の電気を消灯することもできます。chatroid.gem はこのように活用用途が広く、中村さんの一番のお気に入りです。

その他にも、アニメに特化したカレンダーの wiki 情報を取得する syoboi_calendar.gem や、綺麗なコーディングをサポートするための guideline.gem、code_hunter.gem などの gem を紹介しました。特にアニメ情報を取得するための syoboi_calendar.gem では、その発想の面白さから会場から笑いが起こりました。

様々な問題を Ruby で解決してしまう中村さん。みなさんも、「プログラムで何を作ったら良いのか分からない」と思ったときは、自分の身の回りの問題に着目してみてはいかがでしょうか。

本当はこわいエンコーディングの話

とみたまさひろ (@tmtms)

NSEG (長野ソフトウェア技術者グループ) で活動するとみたまさひろさんが、Ruby におけるエンコーディングの注意点について発表しました。

とみたさんの日常の Ruby はエンコーディングに悩む日々だと述べ、そこから得られた注意点として以下の 3 点を挙げました。

まず1点目として、プログラム内部のエンコーディングは UTF-8 に統一した方がいいと述べました。UTF-8 に統一すれば変換の必要な場面が少なくなり、あまり問題は発生しないと言います。

2点目として、IO 読み込みではメソッドによってエンコーディングが ASCII-8BIT 固定になるものがあるので注意して欲しいと言いました。

3点目として、ファイルなど外部から読み込んだデータは不正な文字が含まれていることがあるので、エンコーディングの事前判定や文字の変換処理を行った方がいいと言いました。ただし現在では、不正な文字を変換する簡単な方法がなく、Ruby2.0 での対応を期待していると述べました。

最後にとみたさんは、エンコーディングは気をつければそんなにこわくない！と発表を締めくくりました。

「Rails アプリケーションと継続的インテグレーション」

西川茂伸 (@shishi4tw)

株式会社 Aiming の西川さんが、継続的インテグレーションと Jenkins による分散ビルドについて話しました。

継続的インテグレーションというのは CI (Continuous Integration) と同義ですが、CI が何かということは継続的インテグレーション入門にも特に言及がなかったと西川さんは話しました。継続的インテグレーションとは、

継続的コミット
継続的ビルド
継続的レポート

のことであり、下記理由のためにあるものだと述べました。

コードのクオリティ
素早い開発
手戻りを防止する

Jenkins を使った CI は難しそうに思えるかもしれませんが難しくありません、と、分散ビルドの作り方を動画で説明しました。ビデオでは、GitHub のリポジトリからソースコードを clone し、rbenv の環境下でテストを実行するというジョブを作成するまでに 2 分もかかりませんでした。

Jenkins でのビルドは簡単ですが、単一サーバで複数ビルドを行うと生じてくる問題について話しました。ビルドごとにリソースを食い合うことでビルドが遅くなってしまうことや、同じ DB を使うことで DB が壊れてしまうことを挙げました。特に、ビルドに時間がかかってしまうと、開発者が通知を待たなくなってしまい、まずいコミットがどんどん積まれることになります。そのため、ビルドには速度が求められると説明しました。

ビルドを高速に行うために、分散ビルドという機能があります。これは、Jenkins に組み込まれた機能です。会場では、並列実行するビルドを作るところを動画で説明しました。2 分程度で並列ビルドするジョブを作成することができ、とても簡単そうでした。

最後に西川さんは、少ない労力で速度を 2 倍にできるので、みなさんも Jenkins を使いましょう！と発表を締めくくりました。

レシピ検索開発のレシピ

牧本慎平 (@makimoto)

クックパット株式会社の検索チームでお仕事をされている牧本慎平さんは、いつも検索チームがどのようなことをやってるかについて話しました。

約 2000 万人の利用ユーザーの存在するクックパッドのレシピ検索は、人気順検索/カテゴリ/関連キーワードなど様々な検索ができ、レシピを載せる人と探す人を繋ぐクックパッドの主要機能の一つで、その主要機能をほぼ 2 人の技術者で開発から運用まで担当されているとのことです。

例えば検索時のサジェスト機能を追加したり、ユーザーからは直接見えませんが用語統一のための「辞書」を作り、自社でメンテ、そしてそのメンテナンスツールも自社で作って開発を進めています。

レシピ検索は主要機能なだけでなく昔からある機能であり、それはつまり古いロジックが多いということで、積極的に古いものを新しいものに置き換える取り組みもされています。

例えば、Senna/Tritonn を Solr に、MySQL based logging を Fluentd/TreasureDate に、(Tritonn/)MySQL5.0 を MySQL5.5 に変更することをされました。

また、リファクタリングも積極的にされたそうです。特に大きな効果があったものとしては、バッチをリファクタリングをしたところ処理時間に 140 時間かかっていた箇所が 4 時間になったそうです。これには会場からも驚きの声が上がっていました。

検索チームは言語処理のノウハウが溜まるのでほかの部署へのアイデアやライブラリ提供をするといったこともし、例えばユーザーが質問を投稿する際、似たような質問を検索し、あった場合投稿前にそれを表示して、質問数を減らすような機能も作成されたそうです。

そうすることによって他部署の業務を軽減し、部署を越えた連携がしやすい立場を構築してるとのことでした。日々このように様々なことに取り組みながら多くのユーザーを抱えるシステムの主要機能を担っています。

Ruby によるお手軽分散処理

前橋孝広 (@tmeb4)

株式会社インターネットイニシアティブ (IIJ) の前橋孝広さんが、Ruby で Hadoop の MapReduce のような分散処理を実現する、pmux というソフトウェアを開発したことを発表しました。

分散処理とは、複数のコンピュータを利用し、同時並行で処理を実行してスループットを上げることをいいます。この分野では Hadoop が有名ですが、今回は GlusterFS というオープンソースのファイルシステムを利用し、pmux を開発しました。これに際し、ユーザの利便性を考えて既存のソフトウェアや概念を利用して開発することを心がけたそうです。例えばパイプラインの技術により、grep、cut、uniq、sort などのお馴染みのコマンドを利用して、Mapper や Reducer を非常に直感的に書くことができます。

pmux という名前は pipeline multiplexer に由来しており、標準入出力を介して MapReduce 処理を実現するためのツールです。GlusterFS はファイルごとに保存するノードを分散させるファイルシステムですが、これを利用して、pmux に指定されたファイルに対してノードごとに処理を分散させることができます。ノードを分散させる処理は dispatcher が担当しますが、dispatcher と各ノード間は MessagePack-RPC over SSH 方式で通信が行われます。ここでも既存の技術が利用されていますが、Net::SSH と MessagePack-RPC のイベントループを同時に2つ回すために、Ruby の Fiber を利用しています。

使用例として Apache ログから特定のパターンを抜き出し、ステータスコードを集計する例や、Hadoop でお馴染みの word count の例が紹介しました。

ベンチマークテストとしては tcpdump のlog に対し、各ファイルで一番多かった IP アドレスを抽出する処理を実行しました。 pmux を通さず、1 台のサーバでで実行した場合は 9 時間近く掛かっていた処理が、ノードを 60 台に増やして pmux で実行したところ、1 分 45 秒に短縮することができました。1 台あたり 8 コアの CPU を使っているため、ノード数以上の高速化に成功したとのことです。しかし、そのうちの 20 秒がファイルが実際にどのノードにあるのかを探す処理だそうで、このオーバーヘッドを改善する事が今後の課題ということです。

できる！一人で作る Web サービス開発

瀬宮新 (@shin_semiya)

「ハイパーレガシークリエイター」の瀬宮新さんが、一人で Web サービスを開発するためにやってきたことを、所々に画像ネタを挟みつつ軽快なテンポで発表しました。

所有している大量の技術書を管理するアプリを Ruby on Rails で作りたいと思い立ち、自分なりにアプリ構成を考え様々な開発プラクティスを取り入れながら 3 ヶ月間かけて一人で開発を進めたと話しました。その後にソースコードを公開してみたところ、「コードが汚い」「コードが Rails っぽくない」などのレビューがあったもののどう解決してよいかがわからず”ぼっち”での開発の限界を感じたと話しました。

そこで「きれいなコード」「Rails っぽい書き方」を求めコミュニティでヒアリングしたと言いました。コードの公開前に前もってテストコードを書いてリファクタリングをした上で「コミュニティで人にコードを見せる」「レビューをもらう」「コードをカイゼンする」というサイクルを回していくうちに、コードの質が向上し今度は「ネーミングセンスが無い」「REST への理解が足りない」などの別の課題が見えてくるようになりました。

コミュニティでのヒアリングを続けるうちに友達ができて”ぼっち”ではなくなったと話しました。また開発していた技術書管理アプリも技術書の貸し借りへ対応し「意識本棚管理アプリ」にするという開発の新たな方向性が見えてきました。また知識の消化が進んだことで大きなスキルアップにつながった上に、社内勉強会を開いてみようと思ったり勉強会での発表をしてみたりと意識の高まりにもつながったと話しました。

よいことの多い Web アプリ開発ですが、Web アプリを一人で作り続けるためにはバグに遭遇しても心が折れないように興味のあるシステムを作るとよいと話し発表を締めくくりました。

Heroku でつくる 50 人のための Rails アプリ

鳥井雪 (@yotii23)

株式会社万葉の鳥井雪さんは、Rails を使って小さなコミュニティのためのアプリを作った経験を話しました。

鳥井さんが作ったのは、句会アプリです。句会とは俳句の遊びで、特定のお題にそって参加者が無記名で俳句を作ります。その後、各自が好きな句・悪い句を投票し、総合得点と作者を明かすというものです。これを実現する Web サービスが、句会アプリです。鳥井さんは友人と句会を始めてみたいという思いから Twitter を経由して句会を行っており、それが今回の句会アプリ開発のきっかけとなったそうです。

この句会アプリの開発経験を通じて鳥井さんは、小さなコミュニティのためのアプリケーション開発を奨めています。その理由として開発の楽しさを改めて感じた事、機能追加を繰り返していって、一つのサービスが次第に便利になってゆく手応えが味わえる事、アジャイル開発などの様々な技術も、どんな場面で必要なのかを実際に体験して理解する事ができる、などを挙げました。

楽しく作り続けるために鳥井さんが大切にしている事として、作るものに愛着・興味があることや、Web サービスの感想や意見をくれる人や場所を大切にすること、すべて 1 人でやるのではなく、人がやってくれる事は Web サービスとしてまで実装しない、などを挙げました。鳥井さんが作った句会アプリでは、最後に総合得点と作者を発表するのは、とあるユーザが Twitter で行ってくれるので、Web サービスとしては実装しません。このユーザは Twitter での発表を盛り上げてくれるそうで、このコミュニティの親密さが伺えます。

更に、この句会アプリは Heroku 上で動作しています。簡単にデプロイでき、運用・保守の手間を省けるため、鳥井さんの負荷の軽減に大きく貢献しています。Heroku はターミナルと Toolbelt という Heroku のツールキットさえあれば利用でき、アドオンやコミュニティも充実しています。多くの情報は英語ですが、一部で Heroku の Dev-Center の情報を日本語化するための動きもありますので、これから日本語の情報も増え、日本での利用も増えてくるでしょう。

鳥居さんは最後に、ユーザと一緒に楽しくコミュニティ形成をし、開発を楽しんでほしい。その環境が今はとてもゆたかです、と最後に伝えてくれました。

日本酒評価サイトと xDD

河野誠 (@ginkouno)

Tokyu.rb 幹事をされている河野誠さんは、日本酒評価サイトと、いくつかの○○駆動開発について発表しました。

まず最初に、Ruby on Rails で開発した日本酒評価サイト http://japanni-shu.com/ を紹介しました。好きな日本酒を評価できるサイトをと、フィーリングで気軽に日本酒の評価ができることをコンセプトに開発されたそうです。

続いて、開発を続けるためのモチベーション維持や時間確保の方法について、いくつかのxDD (○○駆動開発) を紹介しました。

「aDD = Alcohol Drive Development」「wDD = Wine Drive Development」「nDD = Neko Drive Development」などを挙げます。このなかで河野さんがもっともお薦めする方法として強調したのが「cDD = Community Drive Development」(コミュニティ駆動開発) です。コミュニティを形成することで継続可能なものとなり、継続から自分にあったやり方が見つかり、やがて気の合う仲間ができると言います。コミュニティの存在が開発のモチベーションに繋がると話しました。

最後に河野さんは「コミュニティに感謝！」という言葉で締め括られました。

みなさんも提案された xDD を参考にしつつ、自分なりの xDD を考えてみたらいかがでしょうか。

Padrino in production

塩谷啓 (@kwappa)

kwappa さんこと塩谷さんが Padrino を本番環境で使ってみた体験談と、Padrino のサブアプリケーションの便利さについて発表しました。

ご存知の方も多いと思いますが、Padrino は Sinatra をもとにして作られています。 Padrino は Sinatra に generator や console などの必要なモジュールを必要なときに使うことができるという形態から、Padrino を使った開発をビュッフェスタイル開発と呼ばれています。

今回のセッションでは、サブアプリケーションの紹介が主な内容でした。 Padrino では、1 つのプロジェクトの中に複数のサブアプリケーションを作成することができます。また、サブアプリケーションたちをそれぞれ異なる URL にマウントすることもできます。

本番環境に使ってみた例として、3 種類のサブアプリケーションを Padrino が受け、バックエンドにあるシステムたちからデータを受け取るという、サブアプリケーションの仕組みを効果的に利用した構築例を紹介しました。

最後に、Padrino を使うことの利点を以下のようにまとめました。

シンプルで拡張性に富んでいる
サブアプリケーション素敵
適材適所で Padrino を使おう

Padrino のエンジニアや情報が足りないと紹介がありました。みなさんも Padrino を使ってみて、情報を発信するとよいのではないでしょうか。

Inside Tripclip

ダニー (@f96q)

株式会社クレイのダニーさんは、自社サービスの Tripclip について、実装上の苦労や工夫した点を話しました。

2012年12月にリリースされた Tripclip という Web サービスは、旅行や散歩中に撮ったスナップ写真を手軽にアルバム化できるサービスです。ブラウザ上でドラッグ & ドロップするだけで、手軽にスナップ写真をアルバムにすることができ、簡単に旅行記を作成することができます。

このシステムを構成する主要技術については Ruby on Rails の他、CoffeeScript, MongoDB, Nginx, Unicorn, Amazon EC2, Amazon S3 など様々な技術が用いられています。

特にサービスの特性から、写真のアップロード処理は重要になります。Tripclip では動的にアルバム編集をする必要があるため、写真のアップロード方法についていくつかの方法を検討していますが、現在では Nginx の画像サイズを変換するモジュールを用いて Amazon S3 上で保存しています。Nginx で画像サイズを変換することで、Rails 側での負担が軽減されます。

開発を進めるにあたり苦労した点として、Git を用いた開発体制を挙げました。以前はコミットするときは master にコミットを行っていたため、メンバー同士のコミュニケーションが取りづらいという問題がありました。この問題に対し、ブランチを分けて開発を行いました。適切にプルリクエストを行ったり、機能実装した人以外が merge を行うことで、メンバー同士のコミュニケーションが活性化したそうです。

2012年12月にリリースされたばかりの Tripclip ですが、サービスに使われている技術や開発方法を知ることで、より身近なサービスに感じられるのではないでしょうか。

PHP と Ruby の架け橋

do_aki (@do_aki)

株式会社もしもの do_aki さんが、PHP 上で Ruby を動かすこと、Ruby 上で PHP を動かすことを通じてわかったことを発表しました。

まず、PHP 上で Ruby を動かすための PHP 拡張と、Ruby 上で PHP コードを実行するための gem「php_embed」の紹介をサンプルコードを交えて行いました。シンプルなプログラムでは問題なく利用できるようですが、PHP では言語として SAPI (Server API) が組み込まれていることもあり、Sinatra などの Web アプリで利用すると「突然の死 (Segmentation fault) 」に見舞われるなどまだ安定した利用には至っていないと話しました。

続いて PHP 拡張と「php_embed」の実装を通じてわかった PHP と Ruby の C 言語レベルでの実装の違いについて比較を交えながら解説しました。C 言語とやりとりするデータ型の扱い方、ガベージコレクション、eval について比較し、C 言語レベルでも PHP と Ruby で特徴・アプローチの違いが色濃く反映されていることを話しました。

処理系・拡張のコードリーディングを進める上では「GNU Global (htags) 」、curses を使った gdb インターフェイスの「cgdb」、ソースコードのコミットログ、ソースコードあるいは拡張開発向けのリファレンスマニュアルを使うとよいと言いました。リファレンスマニュアルは Ruby では「Ruby ソースコード完全解説」、PHP では 2009 年に発表された「PHP Extension Writing」という発表資料がよいと言いました。

最後に、処理系・拡張をいじることは大変面白いことなので、会場の皆さんもぜひやってみてほしいとのメッセージを送りました。Ruby 以外の言語と比較をすること、C 言語レベルでの実装をよりよく知ることは、多くの Rubyist に多くの気づきや深い洞察を得る手助けになるでしょう。

招待講演 (2日目)

How to change the world

まつもとゆきひろ (@yukihiro_matz)

Ruby の生みの親である Matz こと、まつもとゆきひろさんは、Ruby が世界を変えた理由から、世界の変え方について発表しました。Skype を用いたセッションで、冒頭に「みなさんの心に直接語りかけています」と笑いを誘い、和やかな雰囲気で始まりました。

Ruby が世界を変える事ができた理由は2つあると、まつもとさんは考えています。一つ目はタイミングです。インターネットブームが起きる前に Ruby をつくれた事は非常に良かったと振り返ります。二つ目はモチベーションです。20 年間続けられた事は、Ruby が世界を変えることができた大きな要因だとおっしゃいました。

まずは小さな世界、自分の周りからはじめることが良いとまつもとさんは言います。未来を予測できない中でできることはリスクを下げること、そして何よりも大事なのは、過程を楽しむことだそうです。モチベーションを高めることにより、みなさんも世界を変えられるのではないか、と語りかけました。テクノロジーを信じ、コミュニティをつくるなどコラボレーションをし、オープンソース化するのが「世界を変える鍵」だと言います。

最後に、ハッピーになろう！とメッセージを投げかけ、発表を締めくくりました。

一般講演 (2日目)

軽量 Ruby で実現する柔軟なルータ -SEIL への軽量 Ruby の組み込み -

曽我部崇 (@rev4t)

株式会社インターネットイニシアティブ (IIJ) で企業向けのインターネットルータの開発などに従事している曽我部崇さんは現在会社で作っている企業向けアクセスルータ SEIL (ザイル) とそこで利用している mruby (軽量ruby) について発表しました。

曽我部さんと mruby の出会いは 2011 年 8 月頃。それ以前に社内のプロジェクトで、cruby で使わない機能を削除して SEIL に無理矢理組み込んで使っていたそうです。もう少し小さい ruby があればいいのにと思っていたところ、社内の先輩から mruby の存在を教えてもらい、この頃はまだオープンになってなかったので関係者に直接コンタクトを取ってソースコードを入手し、動かしてみたところ、SEIL 上でも mruby が問題なく動いたそうです。

今まで組み込みの機械は C 言語かアセンブラでコーディングすることが多かったのですが、開発効率が悪く、文字列処理など書くことが多かったり、テストを回すのが大変でした。その点をを mruby はカバーできる可能性があるとのことです。

また、組み込みの世界は結構レガシーな開発をしているので、Ruby のエンジニアのみなさんの先進的なノウハウがあるのでぜひそれを展開してほしい。ぜひ組み込みの世界へチャレンジしてみませんかと誘いました。

次に、mrbgem の紹介をしました。これは mruby 版の gem であり、2012 年 12 月本家にコミットされました。mruby 本体はすごく小さいものになっており、拡張ライブラリなどはほぼなく非常にコンパクト。mrbgem で必要な物を選択してビルド時に組み込むことができるそうです。

mruby は組み込み機器以外にも適用できます。アプリへの組み込みにも向いていて、アプリ動作ホストの ruby 環境に依存しせず、ruby バージョン、gem 依存を気にしなくて良い利点があります。

現時点では mruby の基本部分ができただけで、ドキュメントや mrbgems など未整備のものが多数あり、今ならコントリビュートできることが沢山あります。それはつまりまだまだ沢山のエンジニアの方の協力が必要な状態だということで、最後に軽量 ruby フォーラムの紹介もしました。

Fluentd: The ruby-based middleware across the world

田籠聡 (@tagomoris)

NHN Japan 株式会社の田籠さんが、ご自身もコミット権を持つ、Fluentd の便利さについて発表しました。まず、インストールが簡単であることや、容易にプラグインを書けること、安定した動作、スループットの高さといった Fluentd の特徴を紹介しました。プラグインが容易に書けるため、集計処理を行うプラグインや、出力フィルタのプラグインなど、90 を超えるプラグインが公開されていると話しました。

Fluentd のプラグイン導入と設定だけで、簡単に GrowthForecast に表示する例を紹介しました。Web サーバが返したステータスコードの割合を表示する例でした。書くのは設定ファイルのみで、コードを一行も書かずに実現できる例なので、みなさんもやってみることをおすすめしますと話しました。

Fluentd は、Webサーバやロガー経由でアプリケーションのログを MongoDB などのデータベース、Amazon S3 などのクラウドストレージなどに保存することができますし、保存する対象も増やすことができます。 Flume や Kafka など、同様のログ収集システムに処理を委譲することもできます。 Zabbix や IRC など、多くのツールと共に使うことができるので、みなさんが普段使っているツールと連携させることができるでしょう。

Fluentd のプラグイン開発には多くの人が携わっていますが、必ずしも Ruby をよく知る開発者ではないかもしれません。中には Ruby らしくないコードがあるかもしれませんが、ぜひ Rubyist から、こうしたらいいというアドバイスをいただいて、みなさんで一緒によいソフトウェアにしていきたいと思います。と述べ、発表を締めくくりました。

Ruby、RoR でのオフショア開発をハノイで行ってみたら・・・

本間紀史 (@norifumi777)

株式会社フランジア・ジャパン CTO の本間紀史さんが、Ruby 経験者がほぼ居ないベトナム・ハノイで 1 年間オフショア開発の拠点づくりに邁進した経験談を発表しました。

フランジアは、日本向け受託システムのオフショア開発の拠点としてハノイを選択しています。その理由として、政府が IT の発展を支援している、若い人が多く教育水準が高い、人件費が安いといった点を挙げました。

その一方で、ハノイに Ruby 経験者が少ないことは、採用や教育で苦労した点だと言います。それを「Ruby 推し」で解決していると述べました。

採用戦略において、Ruby を「geek 探知機」と呼び、優秀なエンジニアの発掘、採用に繋げていると言います。また、実装に集中できることやコミュニティの存在、楽しさといった Ruby の効果を強調します。

現在ではベトナム語ブログで Ruby の情報発信をし、コミュニティへ情報を還元をする活動も進められているそうです。最後に本間さんは「Rubyを選択したことは正解だった。ベトナムから早く恩返ししたい」と述べられました。その日も遠くないように思えます。

短期間でオフショア開発を軌道に乗せた事例は興味深いものでした。この事例はオフショア開発のみならず、開発チームをゼロから立ち上げる事例としても参考になる発表だったと思います。

東京にきて僕が作ったものについて

Jun Fukaya (@fukajun)

Sendagaya.rb の主催者の一人である @fukajun さんが、Sendagaya.rb を作った経緯をなぞりつつ、勉強会の作り方について発表しました。

Sendagaya.rb は「毎週の勉強会を楽しみにすることで、毎日の仕事やプライベートを楽しくする」をコンセプトに毎週月曜日に開催されています。勉強会の内容としては、Ruby や Rails を中心に javascript や、iOS など多岐に渡る内容となっています。

@fukajun さんは、Sendagaya.rb を立ち上げた経験から、勉強会を作る際に大事なこととして以下を紹介しました。

一緒にやる人を見つけよう
開催する内容について検討しよう
場所を見つけよう
開催日を決めよう
イベント告知サイトに掲載しよう

また、勉強会を作ろうとした理由として、東京には勉強会がいっぱいあるけれど、勉強会に行きすぎて疲れたことや、自分が楽な勉強会を作りたかったと話しました。 Sendagaya.rb を月曜日に開催する理由も、他の勉強会の開催日との兼ね合いを考えた結果からだと紹介しました。

もう一つ、東京に来てから @fukajun さんが作ったものに DeckNotes というプレゼンツールがあります。今回のセッションももちろん、DeckNotes を使ったプレゼンテーションでした。

Sendagaya.rb のコンセプトは、勉強会を開催し続けていくことと、日常の間をうまくつなぎ合わせることができるとてもよいものだと筆者は思います。 takkanm さんの発表にもあったように、開催者が苦しくならないように楽しみながら続けていく仕組みが大事なのではないでしょうか。

Sole Rubyist’s Fight

yaotti (@yaotti)

Increments 株式会社の yaotti さんは会社で唯一のエンジニアで、Qiita や Kobito などのサービスを開発しました。この経験をふまえ、一人で解決することの問題点や、その解決方法を話しました。

一人で開発することの問題点を yaotti さんはいくつか挙げました。例えば、エンジニアが他にいないため、技術情報が普段の仕事では入ってこないこと、技術に関するディスカッションが出来ないこと、コードレビューの機会がないこと、自分が書いているプログラムの質が不安であることなどです。

一般的にこれらの不安は「やる気」があれば解決するかもしれませんが、「やる気」は信頼ならないもので、今日意識が高くても、明日も意識を高く保てるかは分からない、と yaotti さんは言います。そこでエンジニアらしく、怠惰であっても意識を高く保てる仕組み作りをしています。

オンライン上の取り組みとしては、Codetriage.com や Starseeker.so、そして自社サービスである Qiita を利用して、技術情報を定期的に送ってくれるサービスを利用しています。

オフラインでの取り組みは勉強会やセミナー、そしてハッカソンへの参加を、意識が高い時にまとめて登録してしまうというものです。一度申し込んでしまえばキャンセルはしづらいので、必然的にイベントに参加することができます。特におすすめなのはハッカソンへの参加で、普段話せない技術の話をすることができ、モチベーションが向上するとのことです。ハッカソンは Github と協賛で、Qiita でも実施予定があるそうです。

一人で開発することの問題点を紹介しましたが、職場に複数のエンジニアがいても、同じ悩みを抱えている人はいるのではないでしょうか。yaotti さんのように、エンジニアらしく意識を高く保つ仕組み作りをしてみてはいかがでしょうか。

ブログのススメ

前島真一 (@netwillnet)

Ruby on Rails で開発をするフリーランスのエンジニア、前島真一さんは、自身のブログ netwill.in の運営経験から、技術系ブログを書くメリットを話しました。

「みなさん、ブログ書いてますか？」と会場に問いかける前島さん。会場ではブログを持っている人も、最近更新した人も多く挙手をしていました。しかしインターネットで日本語で技術的な言葉を検索しても、まだまだ日本人の技術系ブログが少ないと伝えます。それならまだしも、2009 年〜2010 年で技術系ブログの数が減少しているのではないかと懸念しています。この時期に日本では Twitter が普及したため、この影響かもしれません。英語圏と日本語圏ではエンジニアの数が違うため、日本人の技術系ブログが少ないのは仕方がない面もあります。しかし前島さんは、技術系ブログを書くことには多くのメリットがあることを伝えます。

まず第一に、知識的に「もう一歩」を踏み出せると言います。文章にすることで自分の理解が曖昧だった所が明瞭になり、知識が深まること、更に人の目に触れることで、他人からのアドバイスが貰える場合もあります。ブックマークや反応があり、純粋に嬉しいという側面もあります。

第二に、勉強会などのコミュニティで孤独になることを回避できると言います。勉強会の懇親会などで、自分が書いているブログの読者が入れば、話しかけてくれるかもしれません。前島さんはこのようなきっかけで人とつながることが、最近よくあるそうです。

以上がブログを書くメリットです。しかし、モチベーションを維持しなければブログは続けられません。前島さんはモチベーション維持のため、途中のエントリでも公開してしまうことを奨めています。完全な状態で配信しようとすると気力が尽きてしまい、せっかくのエントリがお蔵入りになってしまうことを避けるのと、ブログを書いて公開する癖を途絶えさせないためです。自分のブログに中途半端な状態のエントリが載るのが嫌であれば、メモ用のブログを利用することも奨めています。

また、Google Analytics などでブログの統計情報をこまめにチェックすることも有用です。前島さんは iPhone のホーム画面に StatsWidget というアプリで、気軽にブログの統計情報を見ることが出来るようにしています。記事を書いた翌日にアクセス数が増えていると、非常にやる気が出るとのこと。

前島さんは、ブログを書けば書いた人も読んだ人も幸せになると言い、ブログを持っていない人はまず東京 Ruby 会議 10 に行った感想を書いてみよう、と最後に会場に伝えてくれました。

写真の提供

スタッフが撮影した写真の他に、Rubyist 撮影の写真を使わせていただきました。

@igaiga555 さん撮影 http://www.flickr.com/photos/igaiga/sets/72157632520166224/

@sora_h さん撮影 http://www.flickr.com/photos/sora_h/sets/72157632516311027/

書いた人たち

津田均 (@tendon0)

株式会社ブレインパッド所属。レポート班はもとより、Ruby コミュニティへの参加も初めてで緊張しましたが、メンバーのお陰で楽しく取り組めました！

小澤昌樹 (@ozamasa)

アヴァシス株式会社所属。長野県で Ruby を広める活動中。”非日常の”レポート業、とても楽しみました。

牧野裕之 (@kuromatu)

一応の #tkrk10 実行委員。株式会社 VOYAGE GROUP 所属。仕事で Ruby を失ってはじめて気付く大切さを日々実感中。

小芝美由紀 (@chobishiba)

株式会社万葉所属。初レポート業楽しかったです。素敵な機会ありがとうございました。

田中洸一

株式会社万葉所属。Rails な毎日。初めてのレポート業はメンバーにも恵まれ楽しくできました。

菅井祐太朗 (@hokkai7go)

株式会社万葉所属。初めてのレポート班長、はじめての実行委員でした。仕事で Ruby を使えるようになって本当によかった。

バックナンバー