CTOとしてデビューすることになりました

近況報告、というかタイトル通りなのですが、CTOとしてデビューすることになりました。
7月から、最近お世話になってたReproという所のCTOという肩書を得ました。
自営業の個人事業主からいきなりCTOですよw
まあ、CTOといっても、そこのフェーズ次第でやることってのは色々と変わってくると思います。
私の当面のミッションは、中長期的なアーキテクチャの方針決定とそれを実際に形にすること。
そしてリクルーティング、つまり転職斡旋おじさん業です。
なので、責任とコミットする割合が増えるだけで、そんなに今までとやってることは変わらないと思う……多分。


まさか自分がCTOになるとは全然思ってなかったんですが、30歳も越えたし肩書きと共に仕事するのも新しい挑戦としては良いかと思いました。
後は、収入ラインとかIT健保の任意継続が切れた後の社会保障の確保ですかね……。まあ、金は大事ですよね。
他にも色々と仕事してみたい所とか一杯あったんですが、自分の体が二つ無いのが悲しい所です。影分身が欲しい……。


転職斡旋おじさんとしても活動しなければならんので、「なんか新しい環境で仕事したい」と思ってる人が居たらですね、匂わせてくれると寿司とか日本酒ぐらいごちそうできるかもしれません。
特に機能追加に追従しつつRailsコードのリファクタリングとアップデートができる人とかインフラ見れる人とかが足らんので、業務委託も含めて人を探しております。
他にもハイスループットでデータを処理できるアーキテクチャが組める人とか。
まあ、そんな簡単にホイホイと雇える程でかいところではないのですが。


コード的なアウトプットのペースが下がらないかとか、自分を売り込むのは慣れてるけど人を雇うのは慣れてないとか、色々と不安も一杯ありますが、何とか頑張っていこうと思います。
CTOの先輩とか採用活動の先輩の皆様方におかれましては、色々と参考にさせていただきたいので、勉強会やらコミュニティで会ったらお話聞かせてください。


一応、例のリスト。
(最近入れたものが、もう無くなってしまってたので休止中。)

これから忘年会を迎える諸君らに伝えたいオススメの日本酒45選

そろそろ忘年会シーズンですね。年末の飲酒予定がちらほらと埋まってきている頃だと思います。
というわけで、日本酒を飲んだ経験ならRubyist界の中でもトップクラスと勝手に自負しているこのjoker1007が、年末に向けてオススメの日本酒を紹介したいと思います。
居酒屋で日本酒を選ぶ時や、酒屋で買って宅飲みする時の参考にしていただけると幸いです。
ちなみに、書いてる内容は私の主観であって明確な根拠があるわけじゃありません。
私の味覚が適当な場合もあるし、同じ銘柄でも作り方によってはかなり違った味わいになるし、年によっても味は結構変わりますので最終的には勘に頼ってくださいw

鉄板

まず、ここ最近の俺的鉄板銘柄をいくつか。自分が旨味のしっかりした銘柄の純米吟醸が好きなので、その辺りで美味しい所が多いです。

東洋美人 (山口県)

少し前に大規模な水害に遭って蔵元がかなりの被害を受けましたが、その後復活してから非常に良い酒を連発していて本当素晴らしいなと思います。
最近飲んだ原点からの一歩として作られた「IPPO」も美味かった。

宝剣 (広島県)

ほうけんと読みます。
超辛純米、純米吟醸、純米大吟醸、様々なラインナップで外れ無しです。
超辛純米はめちゃめちゃコスパの良い日本酒なのですっきりとした辛口が好きな人にはオススメできると思います。
以前TokyuRuby会議に持ち込んだ「純米吟醸 山田錦」は単品の人気投票としてトップを獲得した逸品です。

津島屋 (岐阜県)

旨味のある味わい深い酒が多い印象です。山田錦系の酒が美味い。
「外伝」というシリーズ(?)があるんですが、やばい美味さでした。
ただ外伝は中々手に入らないか……。普通の津島屋もめっちゃ美味いので是非。

勝駒 (富山県)

かちこまと読みます。
数が余り出ないので、中々見かけないのだが、もし見かけたら飲んでおきたいお酒。
個人的なおすすめは「純米吟醸」。
昔は生もあったように思うけど、最近は火入れしか出してないのかな。

メジャーなとこ

続いて割とメジャーだと思っているお酒を紹介。

醸し人九平次 (愛知県)

関東だと割と良く見る銘柄。多分、東京駅でも割と良いのが買える。
きれい目の味だがバランスの良い旨味があると思う。ただコスパがそんなに良くない印象。
「純米大吟醸 別誂」が香り良く美味いのだが、かなり高いです。
ものによってはかなりワインに近い味です。

梵 (福井県)

割と甘めのフルーティな味のものが多いように思います。
良く飲むのは「艶 純米大吟醸」。
置いてる所には安定してあったりするので、見つけたら試してみると良いかもしれません。

而今 (三重県)

メジャーなので、入手しづらいのが難点。
後、味に幅があって割と好みの当たり外れがある気がします。
個人的には山田錦を使ったものが一番良いと思います。

新政 (秋田県)

最近、急にメジャーになってきた気がする。
かなり甘口のお酒が多い。日本酒初心者にも勧めやすいし、割とあちこちで飲めるのでここから入るのは良いかも。

その他のオススメラインナップ

その他、これは良い！と思ってる酒をまとめて紹介します。

東一 (佐賀県)

あずまいちと読みます。
どっしりした味わい深いお酒が美味いところだと思います。
濃い目のつまみと合わせてじっくり飲みたいお酒。

作 (三重県)

ざくと読みます。
某MSを連想させますが、ちゃんとプロトタイプ-Hとかそれっぽい名前のバリエーションが付けられていて期待を裏切らないお酒です。
どっしり目の重めのお酒から旨口系のお酒の印象があります。
料理と合わせても負けない味です。

紀土 KID (和歌山県)

キッドと読みます。かなりコスパの良いお酒です。
純米、純米吟醸ぐらいなら一升瓶でも2,3000円ぐらいだったと思う。
しかし、味はしっかり美味い。

風の森 (奈良県)

私の地元の奈良県のお酒です。今の所、奈良のお酒では一番好きかもしれない。
旨味の強い系のお酒で、中でも笊籬採り(いかきどり)という独自の技法を使ったシリーズがとても美味い。

タクシードライバー (岩手県)

比較的最近知ったお酒。日本酒らしからぬ変な名前と、B級映画のポスターみたいな謎なラベルで怪しさが凄いんですが、これが美味いから驚かされる。
きれい系に媚びない、しっかりした味わいと酸味のあるお酒です。

来福 (茨城県)

甘口で香り良い日本酒としてオススメできるお酒です。
特に愛山という米を使った純米吟醸が好みで何度か飲んでいます。

仙禽 (栃木県)

せんきんと読みます。
かなり独特の味わいで、やたらフルーティです。酸味もかなり強い。知らずに飲むと日本酒と分からないかもしれません。

遊穂 (石川県)

酸味と旨味のバランスが良いお酒。秋前に「山おろし 純米」と秋刀魚で飲んだのですが、とても美味かった。

会津娘 (福島県)

めっちゃバランスの良いお酒です。山田錦の純米吟醸は最高に美味かった。

七本槍 (滋賀県)

宝剣と並んで辛口が美味いお酒です。
辛口の切れ味がありながら旨味もちゃんとあるのが七本槍の良い所です。

王祿 (島根県)

おうろくと読みます。
辛口から旨み系、酸味もしっかり系まで色々とバリエーションがありますが、最近どうも甘口に寄ってる気もする。
個人的には純米吟醸か超辛純米がおすすめです。
熟成された数年前の純米吟醸とかは死ぬ程美味いのですが、ちょっと手に入らないですね……。

十旭日 (島根県)

じゅうじあさひと読みます。王祿と同じく島根のお酒です。
こちらはどっしりとした重量感のある旨味が特徴です。
濃い目の料理にも負けない味わいです。

段々書くのが疲れてきた

ここからは、飲んだことあってオススメできるものをひたすら書いていきます。味はググったりして想像してくださいw


というわけで、オススメの日本酒45種類(多分)紹介しました。
ちなみに、後半羅列してるものは、本当に単に書くのが疲れてキリが無くなってきたからで、ちゃんとコメント書いてるものにも全然劣らない美味い酒です。
記憶と過去に撮った写真から思い出して書いてるので、普通に書き忘れも色々あると思うので、思い出したり増えたりしたら、またいつか書きます。
とりあえず、これだけの銘柄を頭に叩き込んでおけば、割と良い日本酒生活が出来るはずです。
日本酒はワインやウイスキーに比べて大分安いので、良い地酒を扱ってる酒屋を見つけて買いにいくととても安く良いお酒が飲めます。
3000円も出せば、かなり良い一升瓶が買えて、普通の酒量なら毎日飲んでも10日弱は持ちます。1日300円ですね。
ただ開けて放置すると味が抜けたり酸味が強くなり過ぎたりすることもあるので、開けたら早めに飲みましょう。


さあ、年末に向けて、美味い酒飲んでいきましょう。

Electronでメディアファイル用のファイルブラウザ「BlackAlbum」を作った

Electronで動作する動画ファイル及びJPG in Zip向けのファイルブラウザを作ってみました。
構成としてはElectron+React+Reduxで、gulpfile以外はbabelを使って書いてます。
そこそこ今風な感じを目指して、一部flowtypeとかも取り入れてますが、割と適当な感じで使ってます。
実は以前Node.jsで同じもの作ってたんだけど、せっかくちゃんとデスクトップアプリとして作れるようになったしReactにも慣れたのでElectronと今の技術で作り直してみたのがこれです。名前も同じだったりする。


https://github.com/joker1007/blackalbum
https://github.com/joker1007/blackalbum/releases/download/v0.2.0/BlackAlbum-darwin-x64-0.2.0.zip
https://github.com/joker1007/blackalbum/releases/download/v0.2.0/BlackAlbum-linux-x64-0.2.0.zip

Screenshot


仕様

動作にはffmpegthumbnailerとffprobe(ffmpeg付属)という二つのコマンドが必要です。
Macならhomebrewで両方入ります。
その他は、PureJSのライブラリで動作しているのでLinuxでもコマンドがあれば動くと思います。(バイナリは作ったけどロクにテストしていない)


特定のディレクトリのファイルを攫って、メタデータとファイルパスをIndexedDBに登録しつつElectronアプリ用のuserDataパスにサムネイルを生成します。
ファイルは完全にフラットに並び、無限スクロールで全てのファイルを参照できます。
後は、設定で拡張子毎に再生用のアプリケーションの実行コマンドを書いておけば実行できます。
再生用アプリケーションは複数登録可能で、右クリックで再生プレイヤーを選択して起動できます。
雑な検索フォーム、ソート順変更、お気に入り登録と、検索クエリのプリセット保存機能なんかがあります。
しかし、設定画面作るのが面倒だったので、設定はuserDataパスにYAMLで直で書くスタイルです。
設定ファイルはこんな感じで、Macだと~/Library/Application Support/blackalbum/config.ymlにLinuxだと~/.blackalbum/config.ymlに置きます。

directories:
  - "/path/to/target/directory"
filterWords:
  - NGWORD
thumbnail:
  concurrency: 3
  size: 200
players:
  mplayer: open -a "/Applications/MPlayer OSX Extended.app"
  vlc: open -a "/Applications/VLC.app"
  cooViewer: open -a "/Applications/cooViewer.app"
extensions:
  avi:
    - mplayer
    - vlc
  mkv:
    - mplayer
    - vlc
  mp4:
    - mplayer
    - vlc
  m4v:
    - mplayer
    - vlc
  mpg:
    - mplayer
    - vlc
  wmv:
    - mplayer
    - vlc
  zip:
    - cooViewer


自分のために作ったものなので、色々不親切ですが自分としてはそれなりに便利に使えてます。
その内、もうちょっと親切なインターフェースを作るかもしれませんが、あんまりモチベーションは無いですw

使った主要なライブラリ

dexie.js

IndexedDBを操作するために使ってます。大体何でもPromiseで帰ってくるのでasync/awaitが使えると綺麗に書き易い。

immutable.js

不変データ構造定番のやつ。

material-ui

Material DesignなReact Componentを簡単に使えるライブラリ。見た目がそれっぽくなるw

react-infinite

React用の無限スクロールライブラリ。リングバッファっぽくなっていて、何件表示しようが一定範囲しかDOMを描画しないので項目が大量になっても動作が軽い。
同種のライブラリが他にもいくつかあった。
ファイル数が数万の単位になると、この手のライブラリが無いと重過ぎてまともに描画できなくなる。

mousetrap

キーボード操作によるホットキーの定義に利用。

redux-thunk/redux-promise

Reduxで非同期処理のアクションを扱うためのミドルウェア。

sweetalert

Material Designっぽいアラートダイアログ。

jszip

Pure JSなzipの圧縮・解凍用ライブラリ。adm-zipという同種のライブラリがあるが、こっちの方が大分早い。

pica

Pure JSな画像リサイズライブラリ。lanczosでリサイズできて、触ってみた中ではPureJSでは結構早い方だと思う。

humanize

ファイルサイズとか日付を読み易く整形する。

ビルド環境

gulpとbrowserifyでビルドし、パッケージ化にelectron-packagerを使っています。
一部、browserifyをバイパスしなければならないライブラリがいくつかあるので、その用途で使うものだけどdependenciesに追加し、後は全てdevDependenciesにしてます。
最終的にパッケージ化する時にelectron-packagerのignore設定でdevDependenciesのライブラリを全てignoreすることで、無駄なパッケージでファイルサイズが肥大化しないようにしています。
参考にしたのは以下の記事です。

また、実験的にReactのホットリロードにlivereactloadを使っていますが、SourceMapがおかしくなったりしてちょっと微妙感があります。後、バージョン上げたらビルド壊れたりするし……。

苦労した点

別に大したことはしてないのですが、いくつかハマりました。


まず、無限スクロールはreact-infiniteと同種のライブラリを見つけるまでは、初期描画のパフォーマンスに大きな問題があった。
後、リストする対象が多いのでshouldComponentUpdateをちゃんとやらないとクソ重くなりました。


zip展開と画像縮小のパフォーマンス問題の解決に少し手間取りました。
最初に選択したライブラリが割と遅くて、動作はするけど使い物にならなかった。
picaは高速だったけどbitmap化された画像しか扱えなかったので、BufferをBlobに変換してからCanvasに取り込んでpicaで縮小してからCanvasをElectronのnative-imageモジュールで画像に戻す、というやり方でそこそこ実用的なスピードでzip展開とサムネイル作成ができました。


picaの画像縮小はWebWorkerを使って並列で動作できるようになっているが、そのために利用しているwebworkifyというnpmパッケージが作成したobjectURLをrevokeせずに放置するため、いくつも処理するとobjectURLが溜まり続ける問題があった。そのせいか300件程処理した時点でWebWorkerにアクセスできなくなる謎のエラーが発生。適切にrevokeするようにライブラリをforkして修正して解決しました。


async/awaitのエラー処理をサボると、何の情報も無いままいきなり処理が止まるのでデバッグに苦労した。当たり前ですが、失敗しそうな処理はちゃんとtry/catch書くようにした方が良さそうです。


ElectronはNode.jsのネイティブモジュールが呼べるので、一部のモジュールがbrowserifyと衝突します。何が大丈夫で何が引っかかるのか手探りだったので、動いたり動かなかったり調べてglobal.requireしていくのが面倒だった。
でもbrowserify使わないとnode_modulesでファイルサイズが無駄に膨れ上がるし、それはそれで困る。


後、これ→→ Electronを使ってMac向けのアプリを開発する時のファイル名の扱いについて (所謂UTF-8-MAC問題) - Qiita


と、こんな感じで1ヶ月弱ぐらいElectronとReduxを触ってみたけど、大体使えるようになった気がする。
まあソースコードは割と雑な感じになってるしテストも無いんだけど……。

(株)ウサギィを退職してフリーランスになった話

実はこれが初「で、お前だれよ?」エントリです。
最初の転職の時は、書くと愚痴と怒りしか出てこなさそうだったので書かなかったw


およそ3年半ぶり二度目の転職、というか初の失職です。会社員を辞めてフリーランスになりました。
実は、年末の時点で退職を考えてたんですが、ちょっとタイミングが微妙に噛み合わなかったんで、1月から3月までの間は週に半分フリーランスという形で仕事してました。
で、4月から本格的に退職して完全にフリーランスです。
ITゼネコンの頂点みたいな会社に心疲れて2年半ちょっとで転職したので、もうプログラマーになってからの方が長いのかーと思うと感慨深いですね。
プログラマーとしても4年目に突入して、いよいよ中堅というかおっさん界の中でも中ぐらいのおっさんになってきた感じです。


今回会社を辞めたのは別に仕事に不満があったわけではないです。流石に完全にゼロでもないですがw
基本的には受託開発という形で仕事してたんですが、非常に自由にゆるくやらせてもらえたし、技術的な裁量に関してもかなり自由が効いたので、結構貴重な環境で仕事ができたと思います。
受託開発という都合上、あんまり何作ってたか明確に話せないのが残念な所ですが、結構しっかりしたRailsアプリケーションのサーバーサイドをほぼ一人で設計から実装までやれた事で大分成長できたと思っています。
最後にやってた仕事は小規模ながら納期がタイトで割と色々な事をやらなければならないプロジェクトだったんですが、それなりにいい仕事をしたんじゃないかなーと自分で思ってたり。


辞めた理由は、今は無策で飛び出してもそこそこ仕事が貰えそうな感じがするけど、この先どうなるか分からんから、というのが一番の理由です。
そもそも自分の経験やキャリアが大分偏ってることもあって、内心不安が無いわけではない日々を過ごしてました。
仕事上の不満ってのはその辺にあって、対等な相談相手が居ないって事が大きかった。
自分一人で我武者羅により良い方向を模索し続けるにも限界があるように感じていて、このまま日々が続いていくと、いつか世の中に着いていけなくなるんじゃないかと思い始めてました。
非常にかいつまんで言うと、刺激が無いとダレるってやつですw
それに会社自体が零細企業なこともあって、自分が困るようなタイミングでいきなり飯の種が無くなる可能性も結構あるし、それは結構怖い。
幸いなことにRubyとRailsで立て続けに本を書かせてもらって、Qiitaに何か書いたりどっかでちょこちょこ話したりという活動を続けてきたおかげで、そこそこ名前と得意分野を知ってもらえるような感じになってきたので、だったら困る前に辞めてまえー！って感じで退職することにしました。
まあ、その分期待値も上がってるんで、仕事もしっかりやっていかんとあかんわけですが……。
しかし、思えば遠くへ来たもんだというやつで、誰も自分の事を知らない所でエクセルとパワポばっか書いてた所からスタートして、今はRubyやってる人の内では「おー、あの人かー」ぐらいに伝わるようになったのは、とても嬉しく思っています。
うん、結構頑張ったよね、俺。


何でフリーランスかというと、正直そんなにやりたい事があって辞めるわけじゃないからです。
どちらかというと、バリバリサービス開発やってたり優れたエンジニアとチームで仕事ができる現場で経験を積みたいという思いの方が強く、一箇所に留まってそこに尽力し続けるよりも身軽なフリーランスという形を取ることにしました。
とはいえ、一度に複数箇所から仕事受けると自分の性格上結構きついという事が分かったので、できるだけ一箇所づつから仕事受けるようにしたいとは思ってます。


とりあえず直近はどうするかというと、4月からしばらくはクラウドワークスに常駐します。
期間は明確には決めてないですが、少なくとも3ヶ月〜半年ぐらいまで。
Shibuya.rbのRubyKajaに選ばれたこともあったんですが、渋谷で働くの初めてなので、渋谷近辺の皆様、よろしくお願いいたします。
とりあえずグリフォン行きましょう。若しくは飯の美味い所を教えてください。


何でクラウドワークスで働くのかというと、大体以下の様な理由になります

  • サービス開発メインでやった事無かったのでやってみたかった
  • あんまり大きくない会社の方が好き
  • 一緒に働いてみたい人が居た
  • ゲームやエンタメを提供する系より業務っぽい方が好き

まあこんな感じですが、実際の所あんまり深く考えてません。なんとなくですw


これからずっとフリーランスでいく、とかそんな事は全然考えてないですが、とりあえず1年〜2年ぐらいはフリーランスとしてやっていけるといいなあとか考えてます。
仕事無くなりそうだったらTwitterなりブログなりで泣いてると思うんで、もしその時にちょうどRubyとRailsチョットデキルというエンジニアを探していたら、是非声をかけてください。よろしくお願いします。


そういえば、今日初出社という形でクラウドワークスさんの所に行ったわけなんですが、4/1なんで新入社員の方もいらっしゃるわけですよ。
そしたら、その中に自分のSIer時代の元先輩が居ましてね、本当この業界狭過ぎんだろとマジでびっくりしました。
SIer時代の同僚とか何千人も居る中でこれか。人の縁ってのは面白くもあるんだけど怖くもあるなあと思いますね。


例のリスト。 http://www.amazon.co.jp/registry/wishlist/PTRGLVCCH4YH

2014年を振り返るクソポエム

今年はどんなことをやってたのか思い返してみる。

パーフェクトRuby on Rails

外向きの大きな話はパーフェクトRuby on Railsの執筆。

Amazonにいくつか辛いレビューが並んでいるのだが、想像していた通りだとも言える。
そもそも書き始める前に決めたコンセプトでは、研修が一通り終わった新人が仕事でRailsで開発し始めるって時に読む本というのを想定している。

またパーフェクトシリーズの名前を冠しているが、書き始めから網羅性を高くすることは考えていなかった。
Railsの網羅性高い解説というのは、ほとんどRails Guidesの和訳にしかならない。Rails GuidesとAPIリファレンスを読む方が早いし正確だ。

というわけでパーフェクトシリーズの言語本とは少し趣が違うような感じになっている。


趣味でRailsを触るようになって8年ぐらいかな。まさか自分がRailsで本を出せるとは思ってなかったので嬉しかった。
まあ、その分疲れたけど…。

仕事とか

仕事は去年に引き続き客先常駐しつつ受託開発していた。
余りビジネス色の強くない変わった案件だったので比較的自由にやらせてもらえた。
常駐先の新人のコードレビューをめっちゃやってたのでコードリーディングのスピードが結構上がった気がする。
一方で、コードを書く速度が落ちた気がする。
人のコードの改善点を指摘してる内に、自分のコードの駄目な所も想像が付くようになったからだろうか、どうも「完璧主義の呪い」というものにハマっている気がする。
なんかガムシャラに一人で勉強して実践してってのを繰り返すにはそろそろ限界が見えてきたように感じている。
そういうのもあって、ちょっと年明けから環境を変えるつもり。
詳しいことについては、ちゃんとしてから書くかも。

読んだ本とか

今年は技術書よりSF小説を読んでたと思う。
去年グレッグ・イーガンにハマってからSF小説を読むスイッチが入ってしまった。
今年読んだ中で面白かったのは以下の通り。

他にもいくつか読んでるけどこの辺。

読んだ技術書の中でこれは良かったなーってのは「ハイパフォーマンス ブランザネットワーキング」かな。
無線LANの物理レイヤーの話からTCPの輻輳制御からHTTP2に至るまで幅広いネットワークの技術をカバーしてて非常に勉強になった。

2015年に向けて

最近、何か作る意欲が減退傾向にあるのでちょっとモチベーションを取り戻していかんとなあと思っている。
Leap Motionとかラズパイ辺りに手を出してみるのもいいかもしれない。
仕事については、プログラマーとして仕事し始めて3年。ちょうど30歳にもなった所なので、これからどうするかを一回考え直す時期に来ていると思う。
来年4月辺りには結論を出しておきたい。

パーフェクトRailsで俺が書いた所について思うこといくつか

Rails

既に大きい書店の店頭には並んでいる所もあるようで、自分もアキバの書泉で現物を見てきました。
立ち読みして、ほほーうとやってる著者の図って感じです。

献本させていただいた方にも、既に届いていて読んだよーって言ってくれてる方がちらほら。
参考になったと言っていただけて、とても嬉しく思っています。

さて、今回はちょっと自分の担当した部分と思ってた事について少し書いてみたいと思います。

私が担当したのは、3章のアセットについてと4章のlibディレクトリ周り+Railsのロードパスについて、そして9章のモデル実践編みたいな所です。
一応それぞれありますが、主に言いたいのは9章についてですw

3章について

CoffeeとSassについて、どの程度解説するか非常に悩みました。
実際、書くとなるとリファレンスマニュアルを日本語で解説する、以上の事はページ数的にできない。
かといって、昨今のRailsアプリケーションでは欠かせない要素なので、解説しない訳にもいかない。
RubyとJS以外の他の言語から入ったって人は使ってないって話も聞くので、それなりに書いておいた方が良いとは思ったけど、ちょっとページ使い過ぎたのでは、と思っていたりします。


Sprocketsについては多少詳しく書いたつもり。
特にRailsの中の一要素ではなくて、アセットを管理するRackアプリであることを意識した書き方をしています。
いざアセット管理の詳しい所を更に突っ込んで知りたい場合、どこに当たるのが良いか、ということが伝わるといいなと思っています。
本当は、コンパイルエンジンが実際に何やってるのかとか書きたい気持ちもあったんですが、流石にそれ書いてどーすんだって感じでした。

4章について

一つの章にするにはコンパクト過ぎたような気もする。
しかし、実際仕事で書いたりしてると、ファイルの置き場所に非常に悩むような代物がしばしば登場してきます。
そういう時に取れる選択肢を解説しておきたかったので、1章分の形にしました。
この辺りのテクニックは、実は濫用するような状態になると結構負けフラグなのですが、かといって知らないとそれはそれでもっと辛い事になるかもしれませんので……。

9章について

ここを書くのが、私の中でメインの仕事だったと思っています。
Railsの肝はモデルを如何に上手く作るか、という所にかかっています。
しかし油断して、大丈夫だろーと思ってるとActiveRecordが肥大化して辛いことになる、というのもよくある話だと思います。
この章は、そういう事態を少しでもマシにするための選択肢を紹介する章です。
既に読んでくれた方からもらった感想によると、フルボディのワインのようなどっしりとしたマニアックさらしいですw


私なりに、役に立った知識や上手くいった事をいくつか書いたつもりですが、これが全て正しいのか、というとそんなことは全く無いと思っています。
Railsで取り得る選択肢の一つでしかないし、もっとハイレベルな人から見れば、何言ってんだこいつ?みたいな話もあるかもしれません。
もし、この本を読んでくれて、そして物申したいことがある人は、是非それをブログなどに書いて欲しいと思っています。
そうやって、色々な人が実際に取り組んでるやり方や考え方が、もっと世の中に広がっていってくれればいいなと思います。
そういう意見があれば、そこから私自身も更に勉強していきたい所存です。
なので、マサカリ投げたい人は遠慮なく投げてください。一応喰らう覚悟はしてますんで……。(ダメージを受け流せるわけではない)


そもそもRailsは、最近あちこちで使われてる割に、実際に仕事で開発するような中規模以上のアプリケーションになると、業務内容に直結してしまうので外に出せない情報が多いのですよ。しかも、コンテキストが共有できていない設計の断片は共有しようがない。
(Gemfileの情報交換するだけでも、すげー参考になるぐらい)
そういう理由もあって、書く内容の具体性を出すのに非常に苦労しました。サンプルコードとか理屈の通った説明をするのが、もうめっちゃ辛かった……。


自分自身もまだ試行錯誤段階を脱し切れていないので、勉強会で話す、とかならできるけど本に書くには勇気が出なかった内容とかもあります。
Refinementの活用とか、コレクションオブジェクトとValidatorの組み合わせとか。
というか実際、この章書くの、表向きはちゃんと自信持って書いてますよ、ってポーズを取るのが著者の責任ってものだろうとは思うんですが、実際の所、なんて言うかアレですよ……。
まあ、この日記読むような人は、多少気持ちを分かってくれると思います……。


というわけで、色々と思う所ありながら書いてたわけですが、実際私が書いてみたかったのは9章みたいな話だったので、何とか書けて良かったなーって所です。
他に売ってるRailsの入門系の本とは違う差別化要因になってるはずですが、これが吉となるか凶となるか……bkbkしながらTwitterを眺めています。

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

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を拡張する方法なんかに力を入れています。
機能紹介は、おさらい的な箇所を除けば、恐らく他の本では解説されないだろうという点にフォーカスしています。
ある意味で、偏った内容の本になっているので、それでもいいよーという方は、是非手に取っていただけると幸いです。


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