WEB+DB PRESS #wdpress で Ruby の連載をしていました
WEB+DB PRESS で Ruby の連載をしています。 で書いたとおり、WEB+DB PRESS で @june29 と Ruby の連載をしていました。
最終回の載っている Vol.68 が発売されたので、最終回だし、けっこうがんばったのでブログにして宣伝します。
- 作者: 名村卓,三宅陽一郎,小野修司,中島聡,森田創,小飼弾,田籠聡,天野祐介,cho45,大和田純,白土慧,勝間亮,石田忠司,牧本慎平,A-Listers,近藤宇智朗,はまちや2,mala,じゅんいち☆かとう,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2012/04/24
- メディア: 大型本
- クリック: 108回
- この商品を含むブログ (4件) を見る
これまでの連載記事は
- Vol.63 Ruby 1.9組み込みライブラリをとことん活用！ (主に @june29 が執筆)
- Vol.64 Railsでサクサク作るTwitter／Facebookアプリケーション (主にわたくしが執筆)
- Vol.65 Rails 3.1の魅力に迫る！……“Web開発の巨人”に愛された新機能の強力な連携 (主に @june29 が執筆)
- Vol.66 Bundlerを使いこなす！……ライブラリの追加・更新・使い分けでもう迷わない (主にわたくしが執筆)
- Vol.67 厳選! 用途別Ruby/Railsライブラリ・ツール……機能実装，テスト，開発効率アップ，運用 (分担して執筆)
各回ごとに順番に担当していましたが、第5回の執筆開始あたりからふたりとも忙しくなり、第5回は分担して担当しました*1。連載のお話をいただいたころから、「最終回はなんか独自のものをやりたいっすなー」と話していたものの忙しさでちょっとやばいかなとなっていましたが、せっかくの機会だからと第5回の原稿を提出した直後から最終回に着手したのでした。
最終回にあたって何を書こうかなと考えてみて、「Ruby にまつわる人たちのはなし」を書きたいなとおもいました。
Ruby にまつわる「人たち」のはなし
ここからちょっと回想モード。今回の Ruby 連載のお話をいただいたきっかけは、WEB+DB PRESS 発行元であるところの技術評論社のWeb サイトgihyo.jp での、RubyKaigi 2009, 2010 当日レポートを担当したことでした。RubyKaigi2009 の当日レポートでは、それまでどんな媒体にも執筆したことがなく RubyKaigi スタッフ自体も初めてで、@june29 と試行錯誤しながらどうにかこなしました。いま振り返るとどうやって収めたかわからん、再現できない。RubyKaigi2010 の当日レポートは前年からの学びを踏まえ、@sugamasao、@takkanm、@ukstudio の三人に参加してもらいチームの体制にしました。るびまで直前特集号を出すこともできました。その甲斐あってか RubyKaigi2011 ではめでたくレポート班をクビになり、作ってきた「レポート班」を手渡すことができました。
レポート班のだいじな準備のひとつに「予習」があります。当日はトークを聞きながらレポートを書くわけですが、事前にどんな内容のトークなのか発表概要(CFPにきた応募)を読んでおいたりスピーカーがどんな人なのかを知っておかないと、話の要点がつかめずメモを取るのさえ大変になります(というのを 2009 で学んだ)。特に海外からのスピーカーの場合は名前を見ただけでは誰だかわからなくても、その人が作ったツールを知っていたり、例えば海外のカンファレンスを主催しているのを知っていたりするだけで、理解ががぜん進むし、なによりトーク前のワクワク感が全然違います。たのしい。
Ruby にまつわる人たちを知ることで、Ruby に触れている時間がもっと楽しくなる。その実感から、Ruby にまつわる「人たち」のことを書きたいとおもったのでした。
データで見るRubyGemsの世界
じゃあ Ruby 界の有名人を紹介する記事を書くのがいいかというと、そのままでは自信をもって出せる記事にできないような気がしました。もっと詳しい人はいるし(RubyKaigi のCFP選考中の @takahashim さんとか @kakutani さんとかちょうたのしそうなんですよ)、そのままでは自分たちだからこそできるものにならなそうな。じゃあどうしようか。大学の研究室のときからやってた「データをクローリングして解析しておもしろい結果をだす」というのをやれば、データから客観的に Ruby にまつわるおもしろいものを出せるんじゃないか。データはなにがあるだろ。RubyGems.org って API 公開してるな。作者とか依存関係とか取れる。ダウンロードランキングとか作者のランキングは簡単に出せるし、依存関係のグラフとかだれも見たことないんじゃないの。いけんじゃね。いけそう。よし。
有名人紹介でなく RubyGems.org のデータ解析にしたことで、有名人だけでなく「Ruby をふつうに使っている人たち」も記事のなかに入り込ませることができました。例えば、多くの gem に依存される gem がどうして多く依存されるかというと、出来がよいのはもちろんのこと、たくさんの人が使っているから、という理由もあるとおもいます。もっと例えると、Ruby on Rails を使うのは、Rails がよくできているから(DHH がすごいから)というのもあるかもしれませんが、みんなが使っているから、という理由も無視できないはずです。gem を「作っている人たち」だけでなく「使っている人たち」の存在によって「RubyGems の世界」が形作られていることを示す。それもまた Ruby にまつわる「人たち」の一つの語り口にできそうだなとおもいました。
試行のサイクルを早くまわす
ここでは記事に載らない、記事を書くプロセス、「データを取ってきてなにかおもしろい結果をだす」という問題にどう立ち向かったかというお話を。
締め切りが決まったおしごと*2で、「なにかおもしろい結果」を出すというのは不確実極まりないものです。やってみないとわからない。ではどうやって「やってみないとわからない」をわかるようにするのかというと、はやくやる、というのが答えじゃないかと思います。「試行のサイクルを早くまわす」。どんな結果になるかわからないものは結果を見るまでの時間を短くして、もしイマイチな結果の場合、どうしてイマイチな結果になったのかを考えて次の手を出すための残り時間を確保する。次の手の精度をあげるためにも、イマイチな結果でも結果をだしてそこから学ぶ。リーンなんちゃらとかでもよく聴くはなしですね。そこにプログラミングが入る場合は、次の手を試す自分のためにも、できるだけ丁寧なコードを書きたいものです*3。
早くやるために、丁寧に
今回の記事のために書いたコード(クローリング、データ解析、グラフ描画)は wdpress11rb/rubygems-world-analysis で公開してます。試行錯誤のなかでツギハギしてきたコードなので、正直キレイな設計にはなっていません。どんなふうに進めたのかや、細かい Tips なんかを見てもらえればとおもいます。
今回のコードでもいくつか Tips 的なものがあって。
ひとつは「クローリングデータは生のままとっておけ」というもの。今回 RubyGems.org の API からクローリングしてきたデータは JSON なのですが、これをパースさえせず一度 SQLite の String 型のカラムに保存しています*4。クローリングの段階では、そのあとどのような解析をするか決めていませんし、決めないほうが得策です。やろうとしていた解析だけでいい結果がでるとは限らず、最初の想定にない解析手法を選択しなければいけないかもしれません。その際ヘタに構造化してしまったおかげで解析がやりずらくなってしまうことも。必要なデータをとり逃しててもう一度クローリング、というのが一番避けるべき状況です(過去に何度もやりました)。今回は、クローリングしたデータをそのまま格納するのに Sequel を、そこから依存関係などを構造化して解析しやすいようにしたものは ActiveRecord を使っています(wdpress11rb/rubygems-world-analysis の lib/ 以下にあります)。
もうひとつは、「解析結果の出力手順はできるだけ短くする」。解析手法の試行錯誤はいい結果を出すために最も重要で時間のかかる作業ですが、試行錯誤の果てにようやく出した解析結果のグラフや図の出力は、試行錯誤のせいでえらくめんどくさい手順になってしまうことがあります。そして、めんどくさい手順のままにして放置されちゃうことが多い、なぜならいい結果がでて終わりが見えてくるから(これも過去の経験から)。本当はそこで終わりじゃなくて、結果を見やすく整理する作業が残っているものです。ここで解析結果の出力方法をリファクタリングしておくと、その後の作業がとてもラクになります。クソ細かいはなしなのですが、今回初めて使ってえらく便利だったのが rdp/ruby_gnuplot。Gnuplot を使ってグラフを eps に出力する部分は共通的に gnuplot.rb - wdpress11rb/rubygems-world-analysis に定義しておいて、各種解析結果の出力は generate_author_rank_graph.rb - wdpress11rb/rubygems-world-analysis のように、タイトルやラベルだけ変えられるようにしました。
見えなかったのものが見える瞬間は、たのしい
今回ひさしぶりに「データを取ってきてなにかおもしろい結果をだす」のをやったのですが、やっぱり、おもしろい結果が見えてきた瞬間はたのしいですね。記事にもありますが(詳しくは記事を読んでいただきたいのですが!!!)、「RubyGems.org での gem の増え方の推移」は、自分の予想を裏切られて、なおかつ考察の末、潜んでいた原因が明らかになって、そういうものこそ記事にまとめていてやりがいを感じました。gem の増え方の推移を調べてたのは ガローア会議02 で日光で温泉合宿中だったんだけど、温泉入って眠い頭で考えてて原因に辿りついた瞬間、
やっぱりこういうのやるのはたのしいなー、と再確認しました。
グダグダ書いてたら
ここまで書いてたら*5、@june29 さんが WEB+DB PRESSの連載が無事におわりました - 準二級.jp を publish してて、連載を受けた経緯なんかを書いてて、だいぶグッとくるので読んでみてください。
謝辞
編集担当の池田さん。
池田さんが「どうすれば読者に伝わるか、読者はなにを求めているか」と投げかけてくれたことで、ただの文章から「記事」にできたのだとおもいます。お打ち合わせにて、池田さん自身が興味を持つポイントと読者が知りたいだろうポイントをまとめて記事の方向性を作っていく力に、安心してのっからせてもらいました。@june29 さんも書いてたけど、「執筆: 〇〇」だけでなく「編集: 〇〇」も、一緒に作ってきたチームとして並べたいです。
@june29 さん。
無事に終わってよかったですね。最終回の「やってやったぜ感」は、だいぶよかったっすね。いやはやおつかれさまでした。ありがとう。
連載を読んでいただき、声をかけてくださったみなさま。
イベントなどで会った際に「読んだよー」「次回はなに書くの？」と言ってもらったり、Twitter などで「記事のコレ役に立った！」「よくまとまってる」などと反響をいただけて、とても嬉しかったです。
なにより、記事を読んでいただいたみなさま。
あなたが Ruby やプログラミングに触れる時間がすこしでもワクワクするものになっていれば、これ以上うれしいことはありません。ありがとうございました。
次号からの Ruby 連載もたのしみにしています！
