米オライリーが Fluent Conference 開催を記念して JavaScript 関連書籍 53タイトル を 50% オフにするセール実施中（5月31日まで）

JavaScript

タイトルのままです。講演のビデオライブも配信しています。月末締め処理してる場合じゃないですね。

http://oreilly.com/javascript/index.html?cmp=tw-velocity-lp-javascript-

  • DRMなしのマルチフォーマット
  • 無料アップデート
  • ビデオはアクセス無期限

タイトルをざっと眺めると、

  • ほとんどが未翻訳
  • Early Release が 5 タイトル
  • 2012年出版のものが 19 タイトル
  • 無料のものも 2 つある

といったところです。

一覧を作ってみました。気になるタイトルがあるか確認してみてください。（オライリージャパンから出版済みのものが一部あります。）

通称サイ本と呼ばれる、JavaScript のバイブル『JavaScript: The Definitive Guide, 6th Edition』は1100ページもあって、通勤で紙の本を読むのは現実的ではないので eBook で購入した方がよさそうです。（翻訳に1年以上は待たされるという噂も。）ダグラスおじさんのビデオも気になります。

ちなみに、英語がちょっとつらくて、 Node.js か CoffeeScript に挑戦してみたいという方には『CoffeeScriptファーストガイド モダンJavaScriptによるアプリケーション開発 (NEXT-ONE)』をオススメします。タイトルからはCoffeeScriptのシンタックスまわりのみを扱っている印象を受けますが、CofeeScript (第1章〜第6章)以外に、Node.js 向け開発のベストプラクティス(第7章)、ブラウザ向け開発のベストプラクティス(第8章)の2章で半分のページ数を割いていて、扱っているトピックも多く、かなりのお買い得感でした。

CoffeeScriptファーストガイド モダンJavaScriptによるアプリケーション開発 (NEXT-ONE)

CoffeeScriptファーストガイド モダンJavaScriptによるアプリケーション開発 (NEXT-ONE)

HOLSTEE社 の Manifesto

会社 語学

Twitter で回ってきたので紹介します。

NYに「持続可能性、地球に優しい」をモットーに、より良いデザインの服や小物を作って販売する『HOLSTEE』という会社があります。彼らは起業するにあたり、最初に「事業計画」を書くかわりに、下記のマニフェストを書いたそうです。そして、その内容には心打たれるものがあります。

http://www.sircus.tv/2012/02/ny.html

画像にて引用します。

この Manifesto について、以前、平鍋さんが翻訳してブログに紹介されていました。読んでみると、平鍋さんの訳が元になっているような気がしました。

「HOLSTEE マニフェスト」読んでみてください
「HOLSTEE マニフェスト」読んでみてください：An Agile Way：オルタナティブ・ブログ>

HOLSTEE のマニフェスト、日本語版続報
http://blogs.itmedia.co.jp/hiranabe/2011/06/the-holstee-manifesto-japanese-2.html

HOLSTEE Manifesto (3)
http://blogs.itmedia.co.jp/hiranabe/2011/08/holstee-manifesto-3.html

ぼくはこのマニフェストが気に入って、先月の自分の誕生日に、これを日本語に訳して、Dave（マニフェストの著者の1人）とMikeyに送ったのです。日本にもファンがいることを知ってもらいたくて。日本語訳はカナダの上馬さんにもレビューしてもらいました。

すると、早速Mikeyがそれを整形して日本語版をブログで紹介してくれました。

HOLSTEE のマニフェスト、日本語版続報：An Agile Way：オルタナティブ・ブログ

平鍋さん訳の PDF の入手は以下から。
http://blog.holstee.com/the-holstee-manifesto-now-in-japanese

その後、今年の7月に仕事でニューヨークに行く機会があった。astahのお客さんがニュージャージーとマンハッタンにある。そこを訪問したのだ。

そして、HOLSTEEが、ブルックリンブリッジの近くにあることを知り、そこを訪ねた。こんな訪問は、どんどん行った方がいい。

会ったことがない人でも、その人の仕事に尊敬できることがあったら、それを伝えに行きたいと思う。きっと受け入れてくれる。

HOLSTEE Manifesto (3)：An Agile Way：オルタナティブ・ブログ

この Manifesto を元にしたビデオがあります。
こちらは Manifesto の朗読と共に動くタイプグラフィ。

こちらは社員が出演しているようです。

日本語に訳している方が他にもいて、テイストが違って味わい深いのでご紹介。

「HOLSTEE マニフェスト」読んでみてください：An Agile Way：オルタナティブ・ブログ

平鍋さん訳
http://blogs.itmedia.co.jp/hiranabe/2011/05/the-holstee-manifesto-japanese.html

technohippy さん訳
http://d.hatena.ne.jp/technohippy/20100917/1284742670

mehori さん訳
http://lifehacking.jp/2010/09/this-is-your-life/

原文を読んでみた人は、どなたの翻訳を気に入りましたか？

37signals が公開している Getting Real の PDF 版が無料になった

Biz 語学

37signals の"Getting Real" というWeb書籍があります。

「Getting Real」自体が37signalsの方法論、すなわち「より小さく・より早くソフトウェアを作る」というアプローチを解説したもので、実際に37signals自身がその極端ではあるけれどもシンプルではっきりとしたいくつかの方法を組み合わせることで、数々の使いやすいウェブアプリケーションを世の中に送り出しており、それらは有料ですが多くのユーザーや企業から支持されて利用されています。

なぜプログラマを難問奇問・一風変わったテストなどで雇ってはいけないのか？ - GIGAZINE

原文 http://gettingreal.37signals.com/
日本語版 http://gettingreal.37signals.com/GR_jpn.php

Web 版は無料で PDF版と印刷版は有料だったのですが、先日、原文の PDF が無料になりました。

上記エントリーの最後に出てくる「Getting Real」というのは、この37signalsが出した書籍のうちのひとつで価格は24.99ドル(約1900円)なのですが、なんと全文が日本語訳されており、以下からネット上で無料で読むことが可能です。

なぜプログラマを難問奇問・一風変わったテストなどで雇ってはいけないのか？ - GIGAZINE

入手は以下の URL から。
http://gettingreal.37signals.com/

日本語版の 公式 PDF はないようですが、僕は以前、日本語版の Web 版から PDF を作っていました。Mac は PDF 変換が簡単にできていいですね。
こんな感じです。表紙にあたる部分はかっこ良くならなかったので載せません。^^;

原文でも読んでみましょうかね。

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

  • 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,黒沢　健二,松永　肇一,美谷　広海,祐佳　ヤング
  • 出版社/メーカー: 早川書房
  • 発売日: 2012/01/11
  • メディア: 単行本
  • 購入: 21人 クリック: 325回
  • この商品を含むブログ (39件) を見る

Shibuya.rb に参加した。

勉強会 Ruby

今月は参加できた。@tyabe さんとか 会場提供の VOYAGE GROUP さんとかありがとうございます。
http://www.zusaar.com/event/280051
今回はLT大会みたいな感じで流れで各自の開発環境を晒したり、残りの時間でわいわいやったり。自分にはとても参考になるので、各自がブログやスライドをアップするのを楽しみに待つ。ちなみに上記の記事を翻訳の2/3ぐらいはLT中に作業してた。仕事で Ruby を使っている人には既視感があるらしくて、コードリーディングや何か gem を作ってみるといったことがやりたい人が多く、そういう方向性で行きそうな雰囲気。あと、 Rack層を知りたい人はかなり多い気がする。Rackについて誰かLTをしに来てください。そのうち自分も何かのネタでLTしよう。

なぜ私たちは NodeJS から Ruby on Rails に移行したのか

JavaScript Rails 翻訳

以下の文章は Targeter App Blog の記事を翻訳したものです。原文は 2012年5月12日 に書かれました。


Why we moved from NodeJS to RoR
http://blog.targeterapp.com/post/22984987832/why-we-moved-from-nodejs-to-ror

免責事項：この記事は NodeJS や Ruby on Rails について騒ぎ立てるものではありません。ただ私たちの決定とその理由について振り返るものです。両フレームワークはそれぞれが作られた目的において素晴らしいものであり、そのことは、私たちのスタックの一部がいまだ NodeJS で動いている理由でもあります。

私は NodeJS のすごいファンで、これは非常にエキサイティングな技術だと信じていて、これらの人気が出る様を目にするだろうと思う。私はとても賞賛しているが、それにもかかわらず、私たちは Targeter App を NodeJS から Ruby on Rails に移行した。

私たちが当初 NodeJS でアプリを書いた理由というのはいたって単純だ。アプリをすぐ出すのに使えるライブラリがあったということと（Startup Weekend で使える時間は 54 時間だった）、Ruby に比べると、 JavaScript の方がコーディングする機会が多かったということだ。私たちのスタックは MongoDB を含んでいて、JS 環境で生かされることに意味があった。しかし、アプリが成長してくると、NodeJS がこのアプリには間違った選択だと気づいた。以下に主だった理由を挙げる。

NodeJS は数多くの短いリクエスト(short lived requests)を実行するアプリに適している。伝統的な CRUD アプリでも上手く動作はするが、理想的なツールというわけではない。PHP、Ruby、Pythonにもフレームワークがあり、そういった用途のアプリには十分磨き抜かれ、成熟している。NodeJSがすべて非同期(async everything)であるということは CRUD アプリでは効果がない。人気のフレームワークは、とても良いキャッシュや、アプリに必要なものをすべて備えていて、同期処理であっても十分に上手く動作する。

NodeJS はとても若いフレームワークで、パッケージ周りは未成熟だ。このことで多くの優れたパッケージを生み出してきた素晴らしいコントリビュータを攻撃するつもりはまったくない。しかし、ほとんどのパッケージはまだ成長段階だし、NodeJSの急速な開発は、新しいバージョンになる度にたくさんの変更があるということを意味する。つまり、最先端の技術を使うには、最新バージョンに出来るだけ早く更新しなければならない。これはスタートアップには多くの問題となる。

さらなる理由として、テスティングがある。NodeJS のテスティングフレームワークは良いが、Django や RoR といったプラットフォームで利用できるものには敵わない。1日に数十のコミットがあってそれらすべてを1、2日中に使えるようにしなきゃならないときに重要になってくるのが、何も壊れていないと保証することで、それができなければ、苦労して獲得したアーリー・アドプターを失うことになる。ささいなバグを直すのに丸一日を費やしたい人はいない。

最後に、私たちは、すべてをキャッシュすることが必要で、それをできるだけ早く終わらせる必要があった。アプリが成長して秒間数千ヒットになったが、洪水のようなリクエストを経験することはなかった。チャットアプリじゃないんだ！ 最大でもメインアプリは 1000 RPS で、それぐらいは、RoR と Nginx を使えば容易に対応できる。

さて、ここまで読んでいる人は、私たちがどこで NodeJS を使っているか死ぬほど訊きたいのだと思う。説明しよう。私たちのアプリは 2 つの部分で構成されている。1つはユーザが見るユーザインターフェースで、もう一つはレポートを管理する部分だ。後者は NodeJS を使うのに完璧なシナリオだ。たくさんの短いリクエストがある。この部分は、多くのものをプッシュしているときでもレスポンスをできるだけ速く終わらせる。リクエストがオープンになっている間はブラウザがそれの終了待ちになり、ユーザ・エクスペリエンスを損なってしまうので、これは重要なことだ。NodeJSがすべて非同期だということが私たちを救ってくれた。データは DB に書き込まれたり、ガシガシ処理されたりする一方で、リクエストは終了し、ブラウザはより重要なことを続行できる。

私たちが従事しているプロジェクトは Targeter App で、私たちのアプリの更新を twitter や ニューズレターにサインアップすると受けとることができる。

PS: ここに NodeJS をどこで使うべきか、また、上司を説得して使わせる方法についての優れたガイドがある。
http://nodeguide.com/convincing_the_boss.html

Rails でよくある 5 つの間違い

Rails 翻訳

以下の文章は、Mike Perham 氏のブログ記事を翻訳したものです。原文は2012年5月5日に公開されました。


Five Common Rails Mistakes
http://www.mikeperham.com/2012/05/05/five-common-rails-mistakes/

Railsをそれなりに仕事で使ってきて多くの Rails アプリを見てきて、悪い Ruby コードを読み書きした。この記事では、だいたいすべての Rails のコードベースで見られる共通の間違いを5つ挙げる。

1. スキーマの仕様がないマイグレーション
データモデルはアプリケーションのコアだ。スキーマに制約がないと、データはコードベースに存在するバグにより徐々に蝕まれていき、フィールドに値が入っているか信頼できなくなる。ここに Contact スキーマがあるとしよう。

create_table "contacts" do |t|
  t.integer  "user_id"
  t.string   "name"
  t.string   "phone"
  t.string   "email"
end

これに何が必要だろうか？おそらく、User に所属(belogs_to)していて、1つの名前を持っているだろう。データベースの制約を使ってこれを保証しよう。:null => false を追加してやれば、バリデーションにバグがあったとしても、データベースがモデルの保存を許さないので、モデルが常に一貫性を保てる。

create_table "contacts" do |t|
  t.integer  "user_id", :null => false
  t.string   "name", :null => false
  t.string   "phone"
  t.string   "email"
end

ボーナスポイント
limit => N を使って、string 型のカラムを大きさを正確に決めてやろう。 string はデフォルトで255文字で、電話番号にはそれだけの大きさは必要がない。


2. オブジェクト指向プログラミング
ほとんどの Rails プログラマはオブジェクト指向の Ruby コードを書いていない。MVC 指向の Ruby コードを書いてモデルとコントローラを所定の場所に配置する。たいていはユーティリティモジュールにクラスメソッドを書いて lib/ に追加する。2、3年して開発者は気づく。「 Rails も Ruby なんだ。Rails が明示して保証していないやり方でも、シンプルなオブジェクトを作って組み立てていいんだ！」と。

ボーナスポイント
サードパーティのサービスを呼び出すのにファサードを導入しよう。テストコードにモック・ファサードを提供し、テストスイートではサードパーティのサービスを実際に呼ばないようにできる。


3. ヘルパーで HTML を結合する
ヘルパーメソッドを作っていれば、最低限ビュー層をきれいに(clean)しようとしているということなので、賞賛しよう。しかし、開発者はヘルパー内部でタグを作る際の基本を知らないことが多く、文字列をきたなく結合したり改変したりすることになる。

str = "<li class='vehicle_list'> "
str += link_to("#{vehicle.title.upcase} Sale", show_all_styles_path(vehicle.id, vehicle.url_title))
str += " </li>"
str.html_safe

ああ、これは醜く、XSS のセキュリティホールを容易に生んでしまう！content_tagこそが友達だ。

content_tag :li, :class => 'vehicle_list' do
  link_to("#{vehicle.title.upcase} Sale", show_all_styles_path(vehicle.id, vehicle.url_title))
end

ボーナスポイント
ブロックをとるヘルパーメソッドを導入しよう。ネストしたブロックはネストした HTML に違和感なく合う。

4. すべてをメモリにロードする巨大なクエリ
データを訂正する必要がある場合、すべてをイテレータで回して修正するのではないかな？

User.has_purchased(true).each do |customer|
  customer.grant_role(:customer)
end


100 万ユーザを抱える EC サイトを運営していた場合、1 ユーザが 500 バイトだったらどうだろう？このコードはランタイムのメモリに 500MB を使っってしまう！ より良い書き方はこうだ。

User.has_purchased(true).find_each do |customer|
  customer.grant_role(:customer)
end


find_each は find_in_batches を使っていて、一度に引っ張ってくるのは 1000 レコードなので、ランタイムのメモリ要件を劇的に下げてくれる。

ボーナスポイント
update_all か 生の SQL を使って、大量更新のパフォーマンスを上げる。 SQL の学習にけっこうな時間がかかるが、それだけ利点は数多くある。パフォーマンスを 100 倍改善できるだろう。


5. コードレビュー！
Github を使っていると思うが、pull request は使っていないと思う。1、2日使って機能を追加するなら、ブランチ上で作業してpull request を送ろう。チームが君のコードをレビューできるようになり、改善点と考えていなかったエッジケースの提案が得られる。そのおかげで君のコードがより高い品質を持つことを保証する。僕らは TheClymb の変更の90%を pull request で行っていて、それらは 100% ポジティブな体験だった。

ボーナスポイント
最低限、ハッピーパス(happy path)ぐらいはテストコードなしで pull request をマージしたりしないこと。テスティングはアプリケーションを安定させて、平穏に眠るためには不可避だ。


僕がよくある問題を見逃していたらコメントで知らせて！


更新: Mike Perham 氏から許諾頂きました。ロシア語にも翻訳されていました。

『「紫の牛」を売れ!』

本

マーケティング業界では有名なセス・ゴーディンの本。ちなみに、AppSumo による「すべての起業家が読むべき本トップ40」リストの翻訳版を地道に調べてみた（前編）のリストの一つ。プロローグにあるが、著者のものを含む、以下の書籍をおさえた上での話になっている。

「紫の牛」を売れ!

「紫の牛」を売れ!