グーグル ネット覇者の真実

先月末にぎっくり腰をやってしまい二日間寝たきりだったので Kindle 版を買って読んでみました。

グーグル　ネット覇者の真実

創業当時から広告事業で大成功を納めるまでのわくわくするような話から、超大企業になったことによる様々な苦しみに続き、フェイスブックにこてんぱんにやられるところまでが書かれていました。スタートアップ企業に務めている方などは読んでみるとテンションが上がってよいのではないでしょうか。

技術的なことはほとんど書かれていないどころか「ジャバスクリプト」なんて書かれている始末なので、技術的な側面に興味がある方は少し古い本ですが「Googleを支える技術」を読んでみると面白いと思います。

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

この本の終盤に書かれている Google Buz とか Wave (なつかしいですね...) の失敗から Google +1 のリリースまで、Google はあくまでネット企業というイメージでしたが、ここ数年は Google Glass や自動運転自動車、Chromecast など、人々をパソコンから引き離そうとしているようにも見えます。

そう言えばスマートウォッチなんてものも発表されましたね。

• Google、スマートウォッチOS、Android Wearを発表―最初の製品はLG ‘G’とMotorola Moto 360 - TechCrunch
• 長年腕時計嫌いだったぼくがAndroid Wearスマートウォッチを常用したくなった理由 - TechCrunch

正直もうちょっとデザインなんとかならなかったのかとも思いますが、どうでもいいアプリを作ってみるのも楽しそうです。

WEB+DB PRESS vol.73

見本誌を頂きました。ありがとうございます！

WEB+DB PRESS Vol.73

今回の特集は「たのしい開発実況中継」「詳解 Rails 4」「Redis 大活用」です。また、連載「一歩先ゆくRuby」の第五回として「Ruby 2.0 最速入門」が掲載されています。

以下、簡単ではありますが紹介します。

たのしい開発実況中継

課題が発表されてから 24 時間でアプリケーションを開発する、クックパッドの「開発コンテスト24」第三回で特別賞を受賞した「おやすみシャワー」の開発風景が時系列に紹介されています。

限られた時間の中で様々なツールを活用しながら取捨選択をくり返し、それでも底抜けに楽しそうにアプリケーションを開発していく様子と、そこから得られる様々な気付きが書かれています。

開発に必要なインフラは既に充分に整っており、技術者の知恵とモチベーションさえあれば、本当に短期間で何も無いところから価値を産み出すことができるんだと改めて実感させられました。

詳解 Rails 4

Merb との統合という衝撃のメジャーバージョンアップであった Rails 3 と比べると、どうもぱっとした印象のない Rails 4 でしたが、この記事では Rails 4 では何がどのような理由でどう変わるのかを丁寧に解説しており、DHH を筆頭とする Rails 界隈の Web に対する造詣の深さと、対応の速さ、正確さ、大胆さに改めて舌を巻く想いでした。

個人的には Turbolinks の大胆さに度肝を抜かれました。癖も強そうなので一般的に普及するかは不透明ですが、そもそも発想すること、そしてさっさと実装してしまうことに驚きました。

Rails 当初からの一貫した DRY の精神に加え、近年ではパフォーマンスとセキュリティも意欲的に改善されており、Rails 4 は DHH 曰く最高傑作の Rails となっているそうです。

Rails は web アプリケーションフレームワークの先頭を走り続けているので、それぞれの事情により Rails を使わない、あるいは使えないアプリケーション開発者でも、Rails の向かう先を抑えておくことは重要だと思います。

Redis 大活用

KVS である Redis の紹介です。

個人的に Redis は「Redisの基礎 (全14回) - プログラミングならドットインストール」で概要をさらった程度の知識しか持ち合わせていなかったので、この特集でさらに踏み込んだ内容をまとめて読むことができました。

日々の業務ではここまで爆速の KVS が必要になることはまずないので、まだしばらくは MySQL と必要に応じて memcached を使えば事足りそうですが、いつ必要になってもすぐに対応できるように準備しておきたいと思います。

Ruby 2.0 最速入門

2013 年 2 月 24 日に 20 歳の誕生日を記念してリリースされる Ruby 2.0 の入門記事です。2.0 の新機能のうち、キーワード引数、Enumerator::Lazy, Module#prepend, Refinement を中心に取り上げられています。

著者のブログ「WEB+DB PRESS vol.73 に Ruby 2.0 について書きました。 « blog.udzura.jp」によると Refinement の内容に一部誤解が残っているとのことなので、その点だけは注意したほうが良いと思います。

まつもとゆきひろさん曰く「言語してほぼ完成した」という Ruby 2.0 では、キーワード引数や Enumerator::Lazy でより柔軟に、Module#prepend や Refinement でより安全にプログラミングできるようです。Rails4 と併せてこの機会に習得してしまうのも良いかもしれません。

まとめ

今回も最先端の情報が満載でとても楽しく読めました。発売日は今週末 2 月 23 日の土曜日 (Ruby 2.0 リリース前日) です！

WEB+DB PRESS vol.72

見本誌を頂きました。ありがとうございます！

WEB+DB PRESS Vol.72

今回の特集は「コードレビュー実践入門」、「詳解 nginx」、「Backlog/Cacoo 開発ノウハウ大公開」でした。以下、簡単ではありますが紹介します。

コードレビュー実践入門

なんとなく済ませてしまいがちなレビューという作業のポイントや手法、使用できるツールが体系的にまとめられていて、とても参考になります。

論述的だったり小説風だったり、メリハリの効いた内容で楽しく読むことができました。

詳解 nginx

多くの人が読み方すら知らないであろう北はロシアの HTTP サーバがここまで来たか、という感じです。

WebSocket などにより WEB がガラっと変わる日に備えてかじっておきたいミドルウェアですね。

Backlog/Cacoo 開発ノウハウ大公開

WEB+DB PRESS vol.71 に寄稿した際も、原稿やタスクの管理には Backlog を使わせて頂きました。いつもお世話になっております。

徹底的にモノづくりにこだわるヌーラボさんが、開発や運用はもちろん、海外展開やビジネスまでそのノウハウを惜しみなく公開されており、サービス開発者は必見の内容です。

まとめ

近頃は雑誌に限らずネット上の記事などでも、特定の言語やフレームワークよりもチーム開発や運用のノウハウにフォーカスした内容が増えてきたように感じます。

そんな時代の変化に即した特集記事が読める WEB+DB PRESS vol.72 は本日 12/22 (土) 発売です。

リーダブルコードを読みました

翻訳者である角征典さんの このツイート に手を上げて献本頂いた 「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック」 を読み終えました。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

以下、長いですが、各章ごとに簡単に思ったことを書いてみます。

1章　理解しやすいコード

そもそも「良い」とか「きれいな」「読みやすい」「理解しやすい」とは言うけれど、どれも主観による曖昧な評価です。この章では読みやすさの基本定理を

コードは他の人が最短時間で理解できるように書かなければいけない。

と定めています。明快ですね。

第I部　表面上の改善

2章　名前に情報を詰め込む

これはもう諸手を上げて大賛成です。特に tmp や get などの汎用的な名前を避けるという箇所は大きく頷きながら読みました。

ぼくを含め、多くの日本人は英語の語彙が貧弱なために、ついつい似たような変数名や関数名を付けがちですが、これまでより少しだけ時間を掛けて考えて、よりよい名前を付けなければいけないなと思いました。

3章　誤解されない名前

コレクションを扱う際に「範囲を指定するときは first と last を使う」や「包含／排他的範囲には begin と end を使う」というテクニックは、なるほどなあと思いました。

ブール値に is, has, can を付けるというテクニックはよく使います。分岐条件がぐっと読み易くなるのでお勧めです。

4章　美しさ

この章の内容は以下のまとめに集約されています。

一貫性のあるスタイルは「正しい」スタイルよりも大切だ。

それから、個人的に「縦の線をまっすぐにする」には反対というスタイルを貫いています :-p

5章　コメントすべきことを知る

これも大賛成です。特に「コメントするべきでは「ない」こと」などは、読んでいて「そうだ！」と叫びそうになりました。

何をしているかはコードを読めば分かりますし、システムはコードの通りにしか動きません。設計書やコメントには何故そうしなければならないのかを書き記していかないといけませんね。

6章　コメントは正確で簡潔に

これは「言うは易く行うは難し」だと思いました。簡潔さを気にし過ぎて重要な情報が落ちるくらいなら、多少は冗長でも構わないのですべての情報を正確にコメントして欲しいと思います。

第II部　ループとロジックの単純化

7章　制御フローを読みやすくする

この章は必読です。関数から早く返すガード節やネストを浅くする方法など、試行錯誤の中で次第に身に付いたテクニックが網羅的にまとめられています。

なお、個人的に三項演算子はそこまで読みにくいとは思わないので、使って良いと思います。

8章　巨大な式を分割する

この章も必読です。説明変数、要約変数という名前に膝を打ちました。

先のブール値の名前と同様に、変数名や関数名に説明的な名前を付けると、英語のように読み下せるコードになります。

一箇所からしか呼び出されない private 関数は無駄だと言われることもありますが、ある程度まとまった処理を段落的に切り出して説明的な関数名を付けるテクニックは、意識的に使っています。

9章　変数と読みやすさ

この章では「変数を削除する」という点に特に共感しました。どうにも一般的な名前しか付けようのないローカル変数の命名に悩むときがありますが、多くの場合はメソッドチェーンを使うか、ガード条件で早めに関数から処理を返してしまうことで、そのローカル変数を削除することができます。

「変数のスコープを縮める」は、言語の仕様に依るところも大きいと思います。テクニックや規約も大事ですが、言語仕様でできるだけ多くの誤りを防止できると良いと思います。

「変数は一度だけ書き込む」は、関数型言語では一般的な考え方のようですので、今後 Scala を学ぶ際には意識して取り組もうと思いました。

第III部　コードの再構成

10章　無関係の下位問題を抽出する

この章もおすすめです。コーディング初心者はコードを動作させようと一所懸命になるあまり、コーディング熟練者はより高度な実装を突き詰めるあまり、この問題にはまり込んでいくように思います。

コーディングは手段に過ぎません。実現しなければならない目的を常に最優先するよう、常に気を付けていたいものです。

11章　一度に1つのことを

この章も重要ですね。処理を手続き的に上から下に書き下してしまうと、コードが断片化され、冗長で読みづらくなってしまいます。

コードから一歩離れて、実現しなければならない目的の全体像を把握してから、問題を小さく分割してひとつずつ片付けるようにすると、自然と一度にひとつのことしか実現しないコードが書けると思います。

12章　コードに思いを込める

ややスピリチュアルなタイトルですが、内容はとてもリアルです。

これ以前の章で紹介されているテクニックを駆使すると、「言葉で説明している」ようなコードが書けるようになります。コードが英語のように読み下せるのであれば、コードの内容を説明するコメントはもちろん、コードとの整合性を保つのがとても難しい冗長なドキュメントを書く必要もありません。

13章　短いコードを書く

この本は「リーダブルコード」ですので、可読性を犠牲にしてでもコードを短くせよ、という内容ではありません。書く必要の無いコードを書いてはならないという内容で、YAGNI (You Ain’t Gonna Need It) や 車輪の再発明 として知られる問題に触れています。

この本では触れられていませんが、システムを利用するユーザから実際に使用する機会のほとんど無い機能を求められることも多くあります。コードは書けば書くだけコストが掛かり品質が下がるので、必要最低限のコードのみを優先度順に確実に書かなければなりません。

第IV部　選抜テーマ

14章　テストと読みやすさ

読みやすく保守しやすいテストの書き方について網羅的に触れられています。コードは書いて終わりではなく、動いてからが本番です。コードを書いている途中は、テストコードを書くことを煩わしく感じるかもしれませんが、動き始めたコードが正しく動き続けることを保証するために、テストコードはとても有効です。

テストコードが読みづらく保守しづらいと、あっという間に負の遺産となってしまい、誰も見向きもしなくなってしまいます。この章の内容を常に念頭においてテストコードを書かなければいけないと強く思いました。

15章　「分／時間カウンタ」を設計・実装する

これまでの章の内容を使ってテストコードをリファクタリングしていく内容です。数学的なパフォーマンスの話題なので、取っ付きづらいと感じる方もいるかもしれません。

なにか新しいテクニックが紹介されているわけではありませんので、時間のあるときにゆっくりと目を通すとよいと思います。

解説（須藤 功平）

実に 9 ページに渡る熱い解説です。一部、文言を変更した全文が リーダブルコードの解説 - ククログ(2012-06-11) にて公開されていますので、興味のある方はご覧になるとよいと思います。須藤さんの熱い想いが伝わってくると思います。

さいごに

冒頭の訳者まえがきにあるとおり、この本を読んで「Nothing New (別に普通じゃん)」と思う人もいるかもしれませんが、その人はその「普通」がどれだけ普通でないか、近い将来に思い知らされることになると思います。少なくとも、ぼくの周りにはまだまだ「リーダブル」ではないコードが溢れています。

当然、この本を読んで目からウロコが落ちたように感激する人も勿論たくさんいることと思いますし、この本を読んで「これだ！」と膝を打つ人もたくさんいることだろうと思います。そういう意味で、この本は「コード」を「読む」必要のあるすべての人にとって価値のある本です。

角さん、このようなすばらしい本をお送り頂き、本当にありがとうございました。また、「アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き」 をはじめ、角さんの訳書には度々お世話になっており、これら海外の良著を母国語で読めることにいつも感謝しております。この場を借りて御礼申し上げます。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

参考

• 『リーダブルコード － 忘れてもいいコードを書こう。』に参加してきた #devlove - Shinya’s Daily Report

情熱プログラマー ソフトウェア開発者の幸せな生き方

買いました。読みました。

情熱プログラマー ソフトウェア開発者の幸せな生き方

まず注意しなければいけないのは、この本はそこそこ有名な "My Job Went To India オフショア時代のソフトウェア開発者サバイバルガイド" の増補改訂改題版ということです。改題版なんてあまり聞いたことがありませんが、知らずに読んでしまって「どこかで読んだことあるなあ」なんてことになり兼ねないので、気を付けなければいけません。
また、タイトルに「プログラマ」、「ソフトウェア開発者」、そして「幸せな生き方」とありますが、これも内容を端的に表しているとは言い難い気もします。
まず、本書は確かにプログラマ向けではありますが、その内容の本質は「自分の人生（キャリア）に自分で責任を持ってどう取り組むか」というものであり、プロフェッショナルな仕事をしている人であれば、どなたが読んでも意味のある本だと思います。
これと関連して、「幸せな生き方」という副題についても、その内容は「人生ってすばらしい」みたいな、ほんわかしたメルヘン的なものではなく、とにかく「現実を見る」「戦略を立てる」「自分を売り込む」「自分でやる」「今すぐやる」と言った超現実主義的なものです。
個人的には、色眼鏡を通して斜めに世間を見るだけで何も成し遂げなかった二十代の頃に読んでおきたかった内容です。遅まきながら、ようやく自分の人生のケツを自分で持つ覚悟ができてきました。

Seasar 2 徹底入門 SAStruts/S2JDBC 対応

Seasar 2 徹底入門 SAStruts/S2JDBC 対応

当然、速攻で予約して買いました。まだ読了していないのですが、著者の竹添さんが興味深いエントリをポストされていたので便乗してエントリ。

Seasar2 について

一部のみを引用するとぼくの主観が入って作為的になってしまう恐れがあるので、必ず原文にも目を通して頂くとして、著者の竹添さんが Seasar2 について以下のように言及されています。

でも、そんな今だからこそ、僕が好きになれなかったのはSeasar2というプロダクトではなく、（言い方は悪いですが）ある意味ミーハーな盛り上がりを見せていた、当時のSeasar2のコミュニティだったのではないかと思うようになりました。

http://d.hatena.ne.jp/takezoe/20100425#p1

竹添さんの仰りたい趣旨とはややズレるとは思いますが、自戒の念を多分に込めて言うと、この「ミーハーな盛り上がり」は Seasar2 に限ったことではなく、この業界全般に言えることでもあると思います。
OSS に限らず、何らかの製品や概念など、対象は何でも良いのですが、それそのものの本質や、それによって引き出されるメリットやデメリットまで踏み込まずに、上っ面だけで持ち上げたりこき下ろしたりすることが多過ぎるように思います。

クラウドと NoSQL について

これを踏まえて、同じく竹添さんの別のエントリを引用します。上記同様、こちらについても原文まで目を通して頂きたいと思います。

というわけで、データ中心に設計する場合と比べると事前に決めておかなければならない部分が多く、さらに追加や手戻りのダメージが大きいとなると、そういうデメリットを差し置いてまでスケールアウトすることが必要なアプリケーションでしか分散KVSを使うメリットはないわけです。少なくとも、いわゆる業務アプリケーションの分野ではメリットよりもデメリットのほうがまだかなり上回っているような気がするんですよね…。

http://d.hatena.ne.jp/takezoe/20100424#p2

上記の「ミーハーな盛り上がり」は、現在では「クラウド」と「NoSQL」についても見られると思うのです。
バズワードに食いついて「これからはクラウドである」なんて言っている経営層は言うに及ばず、クチバシを尖らせて「これからは分散 KVS なのれすっ！」とか言っている技術屋も等しく問題です。
クラウドが重要なのではなく、システムの初期導入コストの削減やスケーラビリティの向上によるビジネスチャンスの拡大が重要なのであり、それが実現できれば、あるいはそれが必要なければ、何もクラウドでなくたっていいわけです。
分散 KVS も同じで、従来のような更新頻度が少なくて参照頻度だけがバカ高く、かつ多様な導出項目を求められるようなシステムであれば、RDBMS クラスタリングの方が適しているはずです。

まとめ

ぼくはこれからも技術を磨いていきたいと考えているので、これはと思った技術にはどんどん手を付けていきますし、それをこのブログにエントリしていきます。
ただし、それら全てを仕事に持ち込むかと言えば、決してそんなことはありません。その時々に応じて、プロの技術屋として広げた引き出しの中から最適な技術を提案して、リードして、確実に成果を残していきたいと考えています。

小さなチーム、大きな仕事―37シグナルズ成功の法則

小さなチーム、大きな仕事―37シグナルズ成功の法則 (ハヤカワ新書juice)

ずっと気になっていながら読みそびれていた本をようやく買いました。
ご存知 Ruby on Rails の作者であるデイヴィッド・ハイネマイヤー・ハンソンが勤める先進的企業 37signals の仕事に対する考え方をまとめた書籍です。文庫本と同じ大きさで 175 頁程度だったので、三日程度で読了しました。
37signals はこの書籍の出版時点で社員数 16 名で、各社員は二大陸八都市に散らばっていたり、週休三日制を採用していたり、社員全員にクレジットカードを渡して経費の裁量を任せるなど、型破りな運営を実践しつつ、確かな成功を収めている事で世界中から注目されています。
そんな企業の仕事に対する考え方はどのようなものか要約すると

• 必要最低限のことを
• 自分で
• 今すぐ

やろう、ということだけのようです。
とても当たり前のことのようですが、少なくともぼくの周りでは仕事の目的と手段を取り違えてしまう人や企業がまだまだ多く、ぼくを含め誰も彼もがやらなくていいことに縛られてきゅうきゅうとしているように見えます。
日本と諸外国の事情の違いもあると思うので、一概に 37signals のやり方が素晴らしいとは言えないと思いますが、

• 自分は何をしたいのか
• 自分は何をするべきなのか
• 自分は何をしてはいけないのか
• 自分は何ができていないのか

を改めて見直すには良い本だと思います。