それでもRailsを選択する3つの理由

スタートアップ界隈でのRuby on Rails利用率は割と高く感じる。
みんなが使っているから使う？それだけではないはず。なぜ使うのだろう。

railsの特徴を考える。

• 規約縛りの哲学
• 周辺gemのエコシステム
• webの進化への追従の速さ

規約縛りの哲学

Convention over Configurationてやつ。規約を決めて、それに沿えば、フレームワークに乗って素早く開発できるようになる。規約で縛ることでRailsに流れる哲学に従うことを強制化している。

外れると痛い目を見る。Railsに乗るということは電車に乗って簡単に遠くまで行けるということ。Railsから降りるということは電車からも降りるようなものだ。中途半端な理解で突き進むと線路からすぐに降りて歩くことになる。

スタートアップでRailsが採用される一番の理由は、 簡単に遠くまで行ける だと思う。ただ、そんなにうまい話はないのだ。簡単に遠くまで行くには、それなりの覚悟が必要だ。規約を守るにはRailsの哲学を理解する必要がある。取っ掛かりとしては、

• パーフェクトRuby on Railsを読む
• Ruby on Rails チュートリアルをやる
• Ruby on Rails Guidesを読む
• Railsアプリケーションを自身で作る
• Railsアプリケーションを本気で扱う（業務や、自身のサービスとして運用する）
• rails/railsのコードを読む
• gemを作る
• 地域コミュニティに参加して、RubyやRailsに詳しいエンジニアとコミュニケーションを取るのも手だ

あたりだろうか。体系だった書籍や公式のチュートリアルは哲学に触れる第一歩としてよい。実際作ることにより規約があるからこその手軽さを体験し、運用からその思想の深さが理解できる。

規約縛りのさらなる魅力はなにか、Railsというレールがあることにより、チームの共通認識として Rails way に沿っているかという基準が出来ることは大きな魅力だ。チーム開発を加速するためにコードレビューの重要性が高まっているが、このコードレビューにおいても Rails way であるか？という観点がレビューの観点となるので、コードレビューを導入しやすいと感じる。Rails wayをベースにして、コードレビューの観点を育てて行けるのは魅力の一つだ。

地域コミュニティは、Sendagaya.rb | Doorkeeperが初心者におすすめ、もうすでにRailsで何かを作っているなら、ゆるふわ Development Club #yurudevもよい。

周辺のエコシステム

Railsがgithub上で開発されている事も大きいが、その流れで周辺のライブラリ群(gem)も同じgithub上にて開発されていることが多い。

githubにおけるpull requestの仕組みがこのエコシステムを広める根源となっている。

• 議論に透明性がある
• 誰にでもチャンスがあり当事者意識をもてる
• エコシステムに貢献できる

逆に言うと、エコシステムには貢献する義務もある。gemに不都合や要望があるとき、 自身がエコシステムの一部であることを認識していれば、自然とそのgemにpull requestを送ることになる だろう。

Railsに乗るということは自身がエコシステムに入るということだ。Railsに乗り、OSSに貢献する気持ちを育てよう。pull requestはコミュニケーションだ。自律的行動でしか成り立たない。

pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーションはそういう事例を書いた記事。

webの進化への追従の速さ

#12 Rails sideshow | mozaic.fm で語られているように、Railsの進化はWebの進化である。

Railsはバージョンアップがつらいという話をよく聞く。フレームワークのAPIは驚くほど早い周期で廃れ、入れ替わっていく。それの影響もありエコシステムを形成するgemもその影響を受ける。つまり、バージョンアップへの追従のために対処しないといけない箇所は非常に多い。

なぜ、それほどまで変わるのか。

進化のために過去を切り捨てることが、Railsが今も進化し続け、多くの人に利用されていて、エコシステムが形成されることの鍵である。過去の互換性を残せば残すほど進化は鈍化し、身動きがとれなくなってくる。その為に良いもののためには捨てる。

追従するために必要なことはなにか。

• レールに乗る
• テストを書く
• Rails本体を含めたエコシステムの動向をウォッチする

どれも必要であり、これらは生半可な気持ちでは実践できない。

それでもRailsを選択する理由

それでもRailsを使うのは、 規約縛り、 周辺のエコシステム、 webの進化への追従 と言った点に魅力を感じるからであろう。

企業の活動において、railsを選択することはエンジニアリングにおけるただのフレームワークの選択ではなく、重要な経営判断である。 バージョンアップへ追従やテストを書くことを経営陣が意味ある活動であると理解することが大事 だ。

パーフェクトRuby on Rails

転職時に考えておくべきこと

何かしら失敗経験を踏まえて今度は成功するぞって気持ちや今までとは違う理想を描いて転職ってすると思うんですよ。

なので、失敗経験はちゃんと振り返る。どうすれば改善出来るか、どんなアプローチが適切かを分析しないと同じ失敗を繰り返すと思うんです。そして同じ理由で転職を繰り返す。 アプローチは圧倒的に変えないと劇的な変化は訪れないんですよ 。真逆の自分になることも必要かもしれません。また過去の失敗や後悔に論理的な理由付けをしておかないと過去に引きづられ続けます。

理想にどうたどり着くかというアプローチは圧倒的に変えないと以前と同じ失敗をする。理想にはたどり着けない。

理想を語るのは簡単。理想に向かうためのプロセスを見せるべきだし、行動で示すべき。人は議論では動かない、議論の前に行動を。よりよい仕事をしたいなら、不満を口にする前によりよい改善的行動を。

そりゃ入ってみたら思ってたのと違う、よろしくない部分もあるでしょう。文句も言いたくなるでしょう。そういうことに対してのアプローチ、問題提起するか、課題として解決していくか、どういったアプローチが適切なのでしょうか。

会社はチームであることを認識すると経営に知らん顔出来ないし、客人ではいられなくなります。この会社の経営者だったらどう行動するか？そう考えれば他人ごとではなくなるし当事者意識が芽生えると思います。会社は誰かがよくするんじゃなくて一人一人の行動でしかよくならないのです。

はるか昔、新人研修で学んだこと

割りと大きな会社に2003年の新卒で入った。研修はとても充実していて、本配属される前に3ヶ月間、広尾のNTTか何かの研修センターに通って研修を受けていた。その研修の昼休み、マクドナルドに入ろうとしたらL'Arc～en～Cielのkenがシェイク飲みながら出てきたのがハイライト（私はラルクの大ファンです）

こんなことをやってた（レジュメに書いてあったやつからコピペ）

• 導入としてレゴを使った仕様把握設計体験
• VB.NETを用いたアプリケーション開発の基礎
• Oracleを用いたデータベースの構築の基礎
• RedHatLinux OSを用いたLinuxインストール方法と基本操作。
• DNSサーバ、Webサーバの構築方法。
• TCP／IPの基礎から、Ciscoルータを用いたネットワーク構築方法。
• 総合演習として，前述の知識を生かしたシステム構築

導入としてレゴを使った仕様把握設計体験

完成形のレゴを外から見て、その仕様を把握し設計する。

設計から実装まで。パーツを組み合わせて、議論しながらみなでレゴを正確に組み立てる。

完成イメージから忠実に設計し、実装するまでの工程をレゴの組み立てという一件遊びのような題材で学ぶことが出来、楽しい研修であった。

VB.NETを用いたアプリケーション開発の基礎

ナニカ、業務アプリケーションを開発。余り覚えてないけどVB.NETって、まあまあ面白かった。

Oracleを用いたデータベースの構築の基礎

前述のアプリケーションから接続するためのDB設計と構築。DB設計で第三正規形まで叩きこまれた。その辺は大学時代勉強してこなかったことなので未だに役に立ってる。

RedHatLinux OSを用いたLinuxインストール方法と基本操作

（当時はCD-ROMから）インストールして、コマンドでゴニョゴニョするあたりをやった。大学時代Linux OSを要らないPCに入れたりしてたけど、だいたい同じようなこと。

DNSサーバ、Webサーバの構築方法

プライマリ、セカンダリを隣の席の人のサーバーと連携して構築。隣の席に名前解決するの、なかなかよい体験であった。

TCP／IPの基礎から、Ciscoルータを用いたネットワーク構築方法

OSI参照モデルってやつ。アプセトネデブ。Ciscoルータのコマンドとかお覚えたけど忘れた。TCP/IPは大学時代なぜかやたらハマってて勉強してたので割と得意だった。インフラやネットワークの仕事に就きたかったぐらいである。

総合演習として，前述の知識を生かしたシステム構築

なぜかLANケーブル作るところから始まった。ストレートケーブルとクロスケーブルの違いがどうのとか。

このシステム構築の時、完成した後の最後の日かナニカに「今日システムトラブルが起きました。現在の状況を今まで研修で学んだ知識を活かして復旧させて下さい」という課題が出た。

この時学んだのは、ネットワークトラブルはアプセトネデブのブからチェックする！ということ。

物理層のLANケーブルがルーターから抜けており、それを指しても復旧する気配がない。なぜならLANケーブルがクロスケーブルに変わっていたり、ルーターの設定が壊れていたり、とにかく物理層から直していかないと正解にたどり着かないという内容だった。実際にそんなことが起きるかどうかは別として、そういった物理層から疑うという癖はこの時ついた。

で

今思うと、ものすごい充実した研修だったし、割と今でも当時の学びは活きているかもとか思った。新卒研修、割と良い思い出である。

新卒研修後の配属先発表で、Webアプリケーションエンジニアとなる夢は絶たれた。サーバーやネットワークの運用・保守をやる部署に配属されたのだ。社会人ってそんなにうまく行かないんだなってことを痛感した出来事であった。

あわせて読みたい

• 初期衝動の話 - pblog

何故やるのか

と聞かれた時、聞かれているのはそれの潜在的なニーズとか客観的なナニカじゃなくて、 やると言っている相手の中に何があるんだっていう気持ちの話をしているんだと思う。

何が衝動で何故掻き立てるのか、それを聞いてる。

何故やるのか。

掻き立てられるような衝動がなければ情熱には成り得ないし。 情熱なき行動はそもそも続かないしなにより誰にも響かない。

何故やるのか。

一番最初に出てくる言葉はなにか。

FactoryGirlで用意されたデータに望むこと

FactoryGirl というテストデータを用意するためのgemがあります。

読んだ人に、どんなデータが入ることを想定しているか、それが伝わるデータを用意していきたいですね。'MyString'じゃなくて、例えばどんなデータなのかを教えて欲しいのです。

伝わりづらい例

FactoryGirl.define do
  factory :post do
    title  "MyString"
    content "MyString"
  end
end

具体的な例

FactoryGirl.define do
  factory :post do
    title  "pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーション"
    content "pplogの過去のポエムを複数単語で絞込できるようになりました。"
  end
end

FactoryGirl.define do
  factory :user do
    name 'Koshikawa Naoto' 
    twitter '@ppworks' # あー@付きなのだな、というのが伝わる
  end
end

postの例は、具体的過ぎてかえって分かりづらい可能性があります。

こんなときは、Fakerというgemを使ってダミーデーターに意味を持たせるのもひとつの手です。

FactoryGirl.define do
  factory :post do
    title  { Faker::Name.title } # blockで遅延評価することで毎回ランダムとなる
    content { Faker::Lorem.paragraph }
  end
end

実際このデータを使うと、例えば以下の様なデータが得られます。

post.title # "Direct Marketing Coordinator"
post.content # "Quia reprehenderit autem libero neque doloribus. Aut laboriosam aliquid praesentium quas facilis est. Id quasi quae eveniet reiciendis eum. Omnis corporis qui. Quia et quos soluta vitae ut recusandae."

具体的なデータと、Fakerを使うようなデータを上手く使い分けていきたいです。