パーフェクトなRailsの本を書きました

どうもAmazonがフライングでパブリック状態にしてしまったのが補足されてしまったので、想定してないタイミングで世の中に通知されてしまいましたが、Railsの本を書かせていただきました。
パーフェクト Ruby on Rails: すが まさお, 前島 真一, 近藤 宇智朗, 橋立 友宏

元々はパーフェクトRubyを書いた後にスペースの都合で削ったRailsの章があって勿体無いという話から出てきた本です。
タイトルは最初決まってなかったんですが、最終的にパーフェクトシリーズの一つということになりました。

タイトルこそパーフェクトって付いてますが、この本は他の言語解説系の本とはちょっと雰囲気が違う感じになっています。
まあ、執筆スケジュールとかページ数によるスペースの限界という理由もありますが(Rails本の中ではかなり薄い方)、網羅性というより仕事でRails使ってる人達の知識とか考えに重点を置いた内容になってます。
分かりやすい例で言うと、scaffoldの解説とかほとんどしてないし、Railsの基本機能の中でも省略していることもあります。
しかし、本当の所、著者陣の趣味がかなり入ってるというか、RailsのAPIリファレンスとRails Guidesに書いてあることを単純に本にしてもしょうがないだろうと思う所があります。
特にRailsは移り変わりが激しいので、書く側にとっても苦労の割にメリットが薄いように思えます。

というわけで、この本に興味を持ってくれた方に言いたいのは、始めてRailsに触る場合にはこの本は恐らく不向きだということです。
二冊目とか、研修やハンズオンで一通り触った後なんかに、手に取ってもらうのが良いんじゃないかと思います。

じゃあ、この本のウリは何なのか、一応著者の一人としていくつか書いておきます。

まずSprocketsの動作についてある程度ちゃんと書いてます。流石にソースコードレベルまでは踏み込んでないですが、単体でRackアプリとして動作させる方法なんかを説明しています。

そして、より実践的なRailsアプリケーションにおいてモデルをどう扱っていくか、という事について相当ページを割いています。
例えば、ActiveSupport::Concernをこんなにちゃんと解説してる本は、恐らく日本初です。Rails 4.1で追加されたconcerningについても解説してあります。(Rails 4.1対応です)
ついでに、ActiveModelについても、やたらと丁寧に解説しています。この辺の網羅性は無駄に高いです。

他にも、テストの解説やRack、Railtieの動作についてもかなりのページを割いています。
サンプルアプリケーションはwillnetさんが書いてくれたのですが、とても読み易いソースになっているので、シンプルなRailsアプリを行儀良く書く方法が良く分かると思います。

後は、できる限り最新の動向に追従しようとしてる点です。
Rails 4.1に対応した解説もしていますし、サンプルコードも4と4.1どちらでも動くようになっています(いるはず……)。
現時点で、ubuntu 14.04でRubyのビルドをしようとするとコンパイルが失敗する問題についても、多分発売までに修正できるはず……。
(コミッタ筋からの情報によると、もうすぐ対応版が出るらしい)

とまあ、こんな感じでRailsの基本機能を紹介するというより、Railsで開発をする際に何を考えているか、開発や運用に活用するツール、Railsを拡張する方法なんかに力を入れています。
機能紹介は、おさらい的な箇所を除けば、恐らく他の本では解説されないだろうという点にフォーカスしています。
ある意味で、偏った内容の本になっているので、それでもいいよーという方は、是非手に取っていただけると幸いです。

メインで担当した所については、色々と思う所もあるので、それについてはまた後日。

ymsr送別会を終えて

年末のjava-ja忘年会に出た時にyamashiroさんの訃報を聞いて、訳の分からないまま飲み明かした日から1ヶ月半、今日はyamashiroさんの送別会に参加してきました。
その送別会でyamashiroさんを送るための花火が上がりました。
自分がいきなりこの世から居なくなった時に、花火を上げてまで馬鹿騒ぎしてくれる友人が居る彼を心から尊敬します。

今日LTしていた皆さんほどyamashiroさんと付き合いがあったわけではなく、ちゃんと話をする機会があったのは2013年になってからでした。何度か勉強会の懇親会で喋って、やっと顔見知りぐらいになったぐらいです。
多分、最後に会ったのはこわいscala勉強会の受付の時だったかな。
あの時、体調が良くなかったので、本編が終わった後にすぐ帰ってしまったのが悔やまれます。

java-jaの忘年会の日、訃報を聞いて何が何だか良く分かりませんでした。
人の死に触れたことが無いわけじゃないけど、自分より少し年上ぐらいの人間が死ぬなんて事はまだまだ遠い話だと思っていました。今でも良く分からない。
ただその日は忘年会で、自分よりももっと親しかった人達が、とにかく楽しく飲むのが供養だと言っていたので、ひたすら酒を飲んで楽しく過ごそうとしていました。
朝方まで飲んで、一人で帰る時、通勤のためのサラリーマンが溢れる銀座線の中で号泣してました。
友人と言える程の関係性も無かったけど、尊敬してるエンジニアが急に居なくなった事が、とにかく悲しかった。

ところで、先日自分は逆襲のシャアを肴に酒を飲んで語りあう会というイベントを立てました。開催はちょうど明々後日です。
そして今日、ymsr送別会で遺品を巡るゲーム大会で貰ったものに入っていたものが逆襲のシャアのブルーレイディスクでした。
こんな出来過ぎた事があるのかと。
これは確実に、どっかで見てるなと思いました。yamashiroさん本当にすげえわ。
ありがとうございます、本当に嬉しいプレゼントでした、大事にします！
後、自分もカラオケが好きなので生きてる間に一度、一緒にカラオケに行きたかった所ですが叶いませんでした。
とても残念なので、来世かあの世的な所で是非一緒に歌い明かしましょう！

世界を変えたいとか思わない俺と、ヒーローになりたい俺

この記事は闇 Advent Calendar 2013 - Adventarの19日目です。

なんか前回の記事を書いたjugyoさんが非常にインパクトの強い話をぶち込んできたおかげで、次の俺どうしようかって感じで困ってますが、私は普通に鬱屈してる感情を書くだけなんで、そんな面白い話は無いです。自分語りのオナニーをして終わりです。
変な期待をしてる人が居るかもしれませんが、私はマジで何も関わってないのでコメントのしようが無いし。

俺の経緯

私は大学生になるぐらいまで、ただPCでゲームして、エロ動画を見て2chを眺めているだけだった。
貧乏だったので、バイトして金溜めてPCを新調した時、古いPCを活用する方法を考えて、Linuxでルーターを作る事にした。
そこからLAMP構成ってやつでプログラミングの真似事をやりだした。

実際の所、私はエロ動画及び画像の収集と管理を楽にするためにプログラミングやHTTPの仕組みを覚えた。
Refererやcookieを偽装したり正規表現やスクレイピングライブラリで頑張ってHTMLからURLを切り出した。
ファイルからサムネイルを作ったりファイル名とパスをDBに突っ込んでブラウザから検索できるようにした。

今でも新しい言語で何かする時には、とりあえずエロ動画を整理するためのアプリケーションを書く。
作り慣れてるし、自分の役に立つからモチベーションが続きやすい。

その後、自作のカラオケ動画やニコ動に上がっているカラオケ動画を使ってPCでカラオケをする、という行為を効率化するシステムを作り始めた。
実は、これもエロ動画の管理の応用で作り始めたものだ。
要は動画を検索し、それを変換しキューイングし自動で再生するという処理を作れば良かった。
エロで蓄えた知識を趣味のカラオケに適用しただけだ。

このシステムをRailsで何回か作り直してたら、Railsである程度のアプリケーションが作れるようになった。

法律家になるつもりで入った法学部に全然向いてなかった事が分かったので、なんとなくやれそうなIT系に向きを変えて適当に就活をし、でかいSIerに入った。
そして余りのつまらなさに絶望した。
仕事の大半はメールで誰かをせっつくか、机上の空論に無理やり理屈を付けることだった。

とにかく社外に出ないと話にならんと思い、社外の勉強会に参加しまくるようになった。
Rubyコミュニティで何とか居場所を見つけられたので、継続的に参加するようになった。

そうこうしている内に辞めたさが限界に達して、もう駄目だって時に今の会社に声をかけられたので、渡りに船な感じで転職した。
まあ、そんなに悪い会社ではない。俺はそれなりに楽しく開発できてるし待遇も悪くはないと思う。
Twitterなんかに対する露出の仕方については、個人的には余り好きじゃないし、しばしば良く分からんと思うことはあるけど。

世界なんて変えられない

さて、何とか大手エンプラの世界から転職したのだが、要は嫌なことから逃げたのだ。
このつまらん会社を変えようなんて端から考えていなかった。
どうせ俺が何を言っても周りには伝わらないし、あのでかい組織で権限を獲得するころには自分自身が腐ってそして年老いていることは間違いないと思っていた。
だからさっさと逃げた。

最終的に自分が雇ってもらえて何とか自分の好きなRubyで開発が出来てるので、今はそれなりに何とかなっている。
Rubyと触れ、コミュニティと関わっていたおかげで、Rubyの本を書かせてもらえたりもした。
しかし、未来に対する不安感というのは余り消えてくれないものだ。
根本的に自分は働くのに向いていない。
朝は起きれないし、良く体調を崩す。正直、週に5日も働いていると月に1,2回は限界が来る。
そもそも仕事なんて、できればしたくないのだ。

いつまで経っても自分がしょうもない人間なのは、やりたくない事は沢山あるがやりたい事はさして無いからだ。
今もってなお、自分が作ろうと思えるものは、エロ動画の管理とカラオケを効率化するためのシステムぐらいだ。
世の中を変えたいなんて全然思ってないし、誰にも負けない程開発が好きというわけでもない。
結局の所中途半端なのだ。
エクセル方眼紙とそびえ立つクソを売って金に変えるような世界に嫌気がさして逃げてきた割に、じゃあ俺は何がしたいんだ？って考えると特に何も持っていない。

実際他の人がどうか分からないが、外から見てると皆熱意溢れる人に見える。
人生のリソースを開発者として生きることにちゃんと費しているように見える。
そんなに熱意を持って仕事しなきゃならんのか。
皆、意識が高過ぎるんだよ。開発による自己表現って何だよ。
そういうのが全然分からん。表現したい意思とか特にねえよ。
現場を変えるとか価値の提供とか、本当の所良く分からん。
無駄なことばっかやってたらつまらんってだけじゃないのか。
つまらないことで時間を無駄にしたくないだけなんだよ。

どうも俺は他人の幸せに対する想像力が無いらしい。
何に困っているかということに対する想像力が無いらしい。
見知らぬ他人を幸せにするために頑張ったりできない。
自分とタイプが異なる人間のために何かする気にはなれない。

厨二病としての俺

基本的に私は自堕落に生きていきたいただの駄目人間なのだが、一方でこじらせた厨二病患者でもある。
厨二というのはそう悪いものではないと思う。
エンジニアなんてものは、厨二でないと駄目だとさえ言える。
自分の中で厨二であることが一つの良心として働いている。

私にとって、カッコよさというものの基準は少年マンガや特撮ヒーローなのだ。それは今も変わっていない。
普段ギャグキャラだがやる時はビシっと決める男がカッコいいと思う。
誰からも省みられることもなく、己の正義のために孤独に戦うヒーローの姿に憧れる。
突然学校にやってきたテロリストを咄嗟の機転で冷静に撃退したいと思っている。

ダラダラと過ごしていきたい自堕落な自分が居る一方で、そんなことでグダグダやってるのは漢のやる事じゃねえ！と思う自分も居る。
正義の味方になりたい。誰よりも自分に対してカッコつけたい。
お前は、いつもジョジョを好きだと言いながら、誇り高き人間の魂に背を向けていられるのかと。

人間、自分の心の中には闇の自分と光の自分が居るものだと思う。
常にどちらが主導権を握るかで争いあっている。大体、闇側が優勢なんだけど。
でも、ギリギリのラインで自分の中の正義が発動して、何とか人間で居られているような気がする。

厨二病気質の人の中には、何かしらその当人にしか分からない憧れや正義があるんじゃないかと私は思っている。
だから、正しいことをやれる人は多分厨二病の一種なんだ。

今の所プログラミングをして何かを開発するという行為は楽しいと思っている。
見知らぬ他人のことは分からんが、近くの誰かの役に立てることは嬉しいと思う。
いつどうなるか分からんけど、出来るだけ楽しいと思えることで食っていきたい。
そして、普段腐ってても何かの拍子に自分の中の正義が発動した時に、それが阻まれないような環境が欲しい。
なので、零細企業でプログラマーをやっている。
別に大層な事はやってない。数百万の人が楽しめるサービスを作ってるわけじゃないし、生活の価値観が一変するような新しいサービスを生み出しているわけでもない。
近くにいるやりたい事がある人の手助けをしているだけだ。
それでも、前よりは楽しく生きている気がする。

後は、自分がコードを書いて開発するということに対して飽きないことを祈るのみ。
そうなったら、もう死ぬしかないような気がする。
自分の興味が続くかどうか、それがもっとも怖い問題だ。
他にも文系コンプレックスとか、数学が分からんとか、英語が喋れんとか、もうすぐ30だけどどうすんだとか、色々怖い問題あるけど…。

さて、プログラマーになっていよいよ3年目に突入する。
色々考えてしまったが、来年も程々にゆるく生きていこうと思う。

webapi-vimとBufWriteCmdでWeb上のリソースをVimで編集する

この記事はVim Advent Calendar 2013の14日目です。
前の記事はVim on Android | 高級粗茶２。でした。

Vimを使っているとWeb上に存在するリソースもVimで扱いたくなることがあります。
そんな時の強力なお供がmattnさん作のwebapi-vimです。
webapi-vimを利用することで簡単にWeb上のリソースをvimに取り込むことができます。

let res = webapi#http#get(s:pull_request_list_url(a:repo), {}, s:github_request_header)

if res.status !~ "^2.*"
  return ['error', 'Failed to fetch pull request list']
endif

let content = webapi#json#decode(res.content)

こんな感じで webapi#http#getやwebapi#http#postを呼び出すことでcurlで通信した結果を取得できます。
JSONを返すAPIであれば、webapi#json#decodeを呼び出すことでvim scriptのディクショナリやリストにデータを変換してくれます。

Web上のリソースを扱う時、保存方法に良く使うテクニックがbuftypeオプションとBufWriteCmdです。

setlocal buftype=acwrite

autocmd BufWriteCmd <buffer> call s:post_comment()

function! s:post_comment()
  let body = join(getline(1, "$"), "\n")
  let b:comment_info.body = body
  if pull_request#post_review_comment(b:repo, b:number, b:comment_info)
    setlocal nomodified
    bd!
  endif
endfunction

buftypeをacwriteに指定する事で、:writeコマンドの実行時に発生するBufWriteCmdイベントでファイルを書き込む処理を行うことができます。
後は任意のvim scriptで書いた関数を呼び出せばオーケーです。
そこでwebapi-vimを使えば、Web上に何かを投稿するような処理をVimで普通に編集して保存するような感覚で利用できます。
autocmdでコマンドを定義する時にはバッファローカルにしておかないと暴発するので注意しましょう。
BufWriteCmdからファイルを書き込む時には、ちゃんとmodified状態を無効にする処理を書いておく必要があります。
普段の:writeコマンドと違って自動では処理してくれません。

最近、このwebapi-vimを利用してPluginを作ったので紹介しておきます。

GitHub - joker1007/unite-pull-request: unite-pull-request is a unite.vim plugin for Viewing GitHub pull request.

uniteでgithubのpull requestの一覧を参照したり、変更されたファイルのdiffをvim上で表示するプラグインです。
githubのWeb UIで見るよりvimで見た方がファイルの差分を確認しやすいのでは？と思って作りました。
また、Vimからレビューコメントを送信することができます。

差分表示画面でEnterを押すと新しくコメント用のバッファが開くので、そこにコメントを書いて普通に保存するように:writeを実行すると、Enterを押したカーソルの行に対してレビューコメントが送信できます。
vim上の表示とgithubのコメント対象行を一致させるのが困難だったので、既に存在するファイルを編集した差分の場合は、下部に表示されているdiffデータのバッファからしかコメントが投稿できないのが難点の一つです。
他にもページネーションを考慮してないのでpull requestの一覧を最新30件しか取得できないとか、まだまだ機能不足な点がありますが興味があったら使ってみてください。

余りvim scriptに詳しくなくても、webapi-vimのおかげで比較的簡単にvimからWeb上のリソースを編集することができるようになります。
webapi-vimで良く利用するWebサービスをVimから扱う快感に酔いしれましょう。

ジョジョAdvent Calendar 7日目 ジョジョが教えてくれたこと

この記事はジョジョの奇妙な冒険 Advent Calendar 2013 - Adventarの7日目です。

土曜日中に書くつもりだったのが日曜日になってしまった…。
まあ、最終的に書けばよかろうなのだァーッ！ってことで。
ドイツ軍人は締め切りを過ぎてもうろたえないッ！

最近のジョジョでグッときたところは常秀のスタンド「ナット・キング・コール」とカツアゲロードの「オータム・リーブ」ですね。狙い過ぎ感があって、ニヤっとしてしまった。
やっぱ枯葉と言えば、ナット・キング・コールです。
ジョジョリオンはスティール・ボール・ランより好きかもしれない。
やっぱ杜王町は良い。

さて、エンジニアはジョジョを読んだ方が良いと思う理由について、ちょっと書いてみようと思う。
一言でまとめて言うなら、エンジニアが持つべき精神というものと非常に親和性が高いからだ。

ジョジョの登場人物は基本的に前向きであり、過去の自分や運命を乗り越える事を非常に重視している。
これは性質が悪だろうが善だろうが変化ない。
自分自身の現状を認識し、迫ってくる運命を自分の意思で乗り越えることが重要だと表現されている。
問題があった時、それを乗り越えられるかどうかは最終的に自分の意思であり覚悟なのだ。
成長する気の無い奴は何も変わらないし何も掴めない。
成長する意思、乗り越える意思の大切さをジョジョは教えてくれるのだ。
日々、新しい技術をキャッチアップして成長し続けていかなければならないエンジニアにぴったりですね！

そして、ジョジョにおいて勝敗を決定付けるのは観察力や応用力だったりする所に、自分は面白さを感じている。
自分の能力が限られたものでも、得意とするフィールドに持ち込んだり、相手の心のスキを突くことで状況を打開する。
自分の出来ることを最大限に活かすことが大事であり、そのためには自分をちゃんと知ること、そして物事を良く観察し理解すること、それが重要であることをジョジョは教えてくれる。
エンジニアも応用の効く能力を身に付けるということが大事だということが良く分かります。

特にエンジニアにオススメしたいのは五部だ。
少人数のチームで成果を挙げるためのリーダーの在り方、自分が正しさに向かいたいという意思を持ち続けることの重要さを教えてくれる。
特に五部は台詞がカッコいい！

「覚悟はいいか？オレはできてる」
「『言葉』ではなく『心』で理解できた！」
「『覚悟』とは！！暗闇の荒野に！！進むべき道を切り開くことだッ！」
「オレは「正しい」と思ったからやったんだ。後悔はない…こんな世界とはいえ オレは自分の『信じられる道』を歩いていたい！」

そう、SIerでエクセルと格闘して悶々とした日々を過ごしていた時、「信じられる道」を歩いていける自分になりたい、とそう思ってもっとプログラマーとして生きていける道を探すことが出来たのは、ジョジョを読んでいたからと言っても過言では無いかもしれないw

周りがユニットテスト書かないとかメンバーが新しい技術に興味が無いとかウォーターフォール至上主義の上司とか、中々正しいと思う事が出来ないって話を良く聞く業界ですが、正しさに向かう意思を失ったら辿り着く可能性は失われてしまう。
自分が信じられる道を歩くこと、歩こうとすることを止めないで居たいものです。

というわけで、無理にとは言いませんが、興味はあるけどまだ読んでないよーって人は五部までは読んでみることをオススメします。

次のジョジョ Advent Calendarはjune29さんです。

「我が心と行動に一点の曇りなし。全てが正義だ…」
To be continued...

パーフェクトRubyの心残り

この記事はパーフェクトRuby Advent Calendar 2013 - Adventarの6日目です。

Rubyサポーターズの一員としてパーフェクトRubyという本を執筆する幸運に恵まれました、joker1007です。
そもそもはryopekoさんに指名していただいて途中からの協力者という形で参加しました。
私が主に担当してたのは、12章から14章までの、Rubyの周辺ツールやgem周りの部分です。

原稿が揃うまでは、仕事終わってから夜中に黙々と格闘する日々が結構多くて、中々辛いこともありましたが、形に残るアウトプットが出せたことを非常に嬉しく思っています。声をかけていただいて本当にありがとうございました！

さて、こうして世に出たパーフェクトRubyなんですが、技術書の常というか既に古くなってる情報がそれなりに存在します。
特に、発売した後になってふざけんなよ！と言いたくなるぐらいがっつり変わった代物が一つありまして…。

皆様ご存知のGitHub - capistrano/capistrano: Remote multi-server automation toolという奴です。

Capistranoの記事書くの本当に大変だったんですよ。
良く使われてるツールの割にドキュメント少ないし、技術書に動かないサンプル載せるとまずいからって、ちゃんとVMにノード3つぐらい作って一つ一つ実行して結果を確認しているわけです。時間も大分かかったと思う。

それなのにCapistrano3ですよ。
今までと全然互換性無いわ、Rails向けの機能は分離されるわ、そもそもコマンドも変わってるわで、本当ふざけんなよ！ですよ。

えー、あんだけ頑張って書いたのに、もう期限切れかよー…。と嘆き悲しみました。
マジ辛い…。
せめて、1年早く3を出しておいてくれれば…。
まあ、まだ2系は結構現役で活用されてると思うので、全く無用になったわけでは無いと思いますが。

というわけで、Capistranoについて参考にする場合には、バージョンに注意してくださいね。

後、もう一つギリギリのタイミングで載せられなかったのがGitHub - deivid-rodriguez/byebug: Debugging in Ruby 2についてです。
Ruby-2.0.0時代のデバッガーとして最近主流になってきているbyebugですが、パーフェクトRubyを執筆し終わった時点ではまだ存在を知らなかったため、デバッガーについて書いたコラムで紹介し損ねてしまいました。
そして、入稿が終わって発売までのタイムラグの中でbyebugについて知りました。
byebugを利用し始めたのはそれなりに早い方でしたが、後1ヶ月早く知ってればなあ、と思ったものです。

2.0系のRubyを使っていてデバッガーを探している方は、まずbyebugを使ってみるのが良いと思います。

心残りを吐露する機会があって、少し気が済んだかなw
次のAdvent Calendarはyui-knkさんです。よろしくお願いします。

■

[Ruby][Redis]オブジェクトをredisにキャッシュしたり検索したりするConcernを表現するgemを作った
Concernスタイルなモジュールを作ってみたかったので、Redisのキャッシュ機構をActiveSupport::Concernを使ってそれっぽくなるように書いてみた。
元々仕事で書いたコードだったけどちょっと直せば汎用化できそうだったので、夜なべしてgem化してみた。

GitHub - joker1007/redis-cacheable: It is concern style redis caching helper. It makes very easy to cache object.

使い方はこんな感じ

class MyObject
  include RedisCacheable

  attr_reader :id, :name

  redis_key   :id          # optional (default: :id)
  redis_attrs :id, :name # method names

  def initialize(attributes)
    @id = attributes[:id]
    @name = attributes[:name]
  end
end

class ProcObject < MyObject
  redis_attrs ->(obj) { obj.id * 10 } # can give proc
end

my_object = MyObject.new(id: 1, name: "my_object")
my_object.cache_to_redis # KEY = my_object.id, VALUE = MultiJson.dump({"id" => my_object.id, "name" => my_object.name})

MyObject.find_from_redis(1) # => {"id" => 1, "name" => "my_object"}

proc_object = ProcObject.new(id: 1, name: "proc_object")
proc_object.cache_to_redis # different namespace with MyObject
ProcObject.find_from_redis(1) # => 10

もし、どこかで使えそうな機会があったら検討してみてください。

デフォルトでは新しくredisのコネクションプールを生成しますが、既にredisのコネクションが存在するならそれを再利用することができます。

RedisCacheable::Connectable.redis_connection = $redis # $redis is Redis instance or ConnectionPool