seri::diary

日常

2013年に読んだ本

2013年の振り返りということで、今年読んだ本を読んだ順にまとめてみる。

amazonの購入履歴と後は個人的な記憶に基づいてまとめるので多少の過不足はご勘弁を。こうやって見ると今年はあまり本を読んでなかった。ネットの情報に非常に頼りまくっていた感がある。

紙媒体でしか得られない知識はまだ沢山あるので来年はもっと読まなないとなーと思う。

Java関係

 Effective Java

EFFECTIVE JAVA 第2版

EFFECTIVE JAVA 第2版

 

2012年12月頃に購入。

javaやってる出来る人はみんなこの本読んでるイメージ。ピアソン社の日本撤退により日本語版が絶版になってしまったが、また来年2月に丸善出版から再販されるらしい。

昨年12月に今の会社に転職して初めてまともにjavaを書き始めたのできちんとjavaを勉強しようと思ったのだが、javaの入門書は大体がプログラミング初心者をターゲットとしているので、説明過多で自分が知りたい「他の言語との違い」みたいな所が掴みづらい本が多かった。なので初心者向けじゃなくて、ちょっと知ってる人向けのjavaの本が欲しかった。

 なんていうリクエストを職場の先輩にぶつけてみたら紹介してもらったのがこの本。頭から読まず、ジェネリクスアノテーションの章から読み始めた。この章だけはjava1.5からの新機能ということもあって、入門的に丁寧に書いてあった。

なぜジェネリクスアノテーションが必要か?そもそもそれらはどういう役割なのか?どう使うのか?みたいなことが書いてあって非常に分かりやすかった。これ読まなかったら「Eclipse先生に叱られるから」程度の理由でジェネリクス使ってたし、アノテーションは「おまじない」ぐらいにしか思わなかったと思う。まぁ自分でclassからアノテーションを参照するコード書いてみればおまじないじゃないってことぐらい分かるけど、業務ロジックだけ書いてるとそういう機会も殆ど無いのでアノテーションの仕組みを一度はきちんと勉強してみることは大事だと思う。

それ以外の章については始業の1時間ぐらい前に会社に来て黙々と読み進めて1ヶ月で半分ぐらいまで読んだのだが、段々1人では理解がしんどくなってきて、そもそも自分の理解が正しいのか自信が持てなくなってきた。そこで今年の春ぐらいから週一回、業務時間外に社内読書会という形で同僚と一緒に読み進めることにした。参加していたのは自分と同じぐらいのスキルのメンバーだったので、何でもわかってる先生という感じでもないので「これはこういう意味じゃね?」「これは作者言い過ぎじゃね?」とかあーだーこーだと議論しながら進めた。あと、Effective javaの読書会議事録はネットの至るとことにアップされているのでそれらを参照することもあった。

中々これは楽しかったのだが、参加メンバーは自分含めて最初5人ぐらいいたはずが、1人来なくなり2人来なくなり、今では自分ともう一人しかいない。別に退職したとかじゃなくて、仕事が忙しいとか朝早く来るのがしんどいとか、そんな理由でモチベーションが落ちてしまったのだと思う。自分は「継承よりコンポジションを選ぶ」に衝撃を受けて、今までガンガン継承使って共通処理をまとめる実装をしてたのを、デザパタを適用する時以外は殆んど継承を使わないようになるとかの影響を受けているのだが、クラス設計レベルの話に興味が無い人には面白く無い本なんだと思う。

OOP言語使ったプログラミングにおいて、クラス設計・インターフェース設計が一番大事だと個人的には思っているので、Effective javaを来年以降も読み込んでもっと良い設計が出来るようになりたい。

 

Seasar 2 徹底入門 SAStruts/S2JDBC 対応

Seasar 2 徹底入門 SAStruts/S2JDBC 対応

Seasar 2 徹底入門 SAStruts/S2JDBC 対応

 

2012年12月頃に購入。

入社してからずっと関わっているプロジェクトはStruts2なのだが、Struts2の日本語本が無かったのと、他のプロジェクトではSAStrutsを拡張したフレームワークを使ってたり、社内にSeaserコミッタの人がいたりもするので勉強のために買った。

大体コレ一冊でSeaser2のDIコンテナの仕組みからSAStruts使ったwebアプリの開発までいける。2010年と古めの本だが今でもSASturtsでwebアプリを作るならまだまだ使える本。

ただ、書籍内ではDolteng使ってSASturtsプロジェクトのひな形を作る方法が紹介されているが、今作るんだったらMavenarchetype使った方がいいと思う。
そっちのがラクなのと最初からmavenプロジェクトとしてimportできるので何かと良い。自分の環境では、Doltengで作ってからMavenプロジェクトにコンバートしたらプロジェクト自体がおかしくなったことが何度かあった。Maven使わないでアプリ作るとか昨今のjavaではあり得ないので何でも最初からgenerate : archetypeで作るようにしている。

 

Spring2.0入門 Javaオープンソース・Web開発自由自在

Spring2.0入門 Java・オープンソース・Web開発自由自在

Spring2.0入門 Java・オープンソース・Web開発自由自在

 

2012年12月頃に購入。関わっているプロジェクトでSpringのDIコンテナだけ使っているのだが、Springのbean.xmlの定義複雑過ぎワラタwwwということで購入。bean定義のオプション書く時にリファレンス代わりに使っている。上記のリンクはSpring2.0だが、今は新しくSpring3.0入門が出ているので、今買うならSpring3.0で良いかも。自分は関わっているプロジェクトのバージョンに併せてSpring2.0の方を買った。

sprint mvcは使ってないのでスルーしてるがぼちぼち使ってる人がいるみたいなのでそのうちやってみようかと思う。

 

実装パターン

実装パターン

実装パターン

 

2013年5月ぐらいに購入(多分)。

java-ja DDDの講演資料のスライド↓で紹介されてたので購入。javaを書くようになってオブジェクト指向が何となく板に付いてきたが、それでもやっぱり自信なかったのでクラス設計やメソッドの分割粒度の決め方について知りたくて購入した。

書籍の内容については初心者に毛が生えた程度~中級者向がOOPを使いこなして良い設計や実装をするためのノウハウ集といった形。最初の第一章~第四章まではプログラミング全般において設計に気を付ける目的とか理由といったことが書いてあって、第五章からは各論(クラス、コレクション、例外等)について書いてある。

良い所として、全章を通じて、理論上の話だけでなく具体例を上げて説明しているので解りやすい。第三章なんかは、メソッドの名前付けについて実際のコードを例にダメな点と改良すべき方向について述べた上で、段々とサンプルのコードが改良されていく流れの構成になっており、名前付けに関して著者がどういう思考をしているのかトレースできる。

余談になるが、この「誰かの思考をトレースする」ことは技術学習においては大事だと思っていて、例えば「名前付けはより具体的な名前を付けた方が良い」という情報があっても、それを受け取った人が「具体的な名前ってなんだ?どうやって自分のコードを改善していけばいいんだ?」となるわけで、大事なのは「具体的な名前を付けるべき」ということではなく、「どういう観点で具体的な名前を探していけば良いのか」ということである。この書籍の良い所は後者の点が凄く丁寧に述べられている点である。納得しながら読み進めることができるので頭にすんなり入るし、作者の思考をトレースして背景がしっかり分かっているから応用を効かせやすい。

 

読み物系

Team GeekGoogleギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

 

2013年7月に購入。

「チームビルディング」や「チームマネジメント」の話。開発がしんどくて行き詰っていた頃に読んでいたが、これを読んでから何となくチーム内での自分の立ち位置とか、動かない人を動かす方法とか、周りからの見られ方とか考えるようになった。色々書いてあったけど、結局はエンジニアも人間なのよというお話。多分エンジニア以外の人が読んでも面白い。

 

 Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ

Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus)

Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus)

 

 2013年夏ぐらい?

ゆーすけべーさんの書籍。Webサービスを作るためのアイデアの考え方から実装のコツ、宣伝、運用まで。一冊あればWebサービス作って回せるぐらいにはなりそうな本。

何か作りたいーけど作るものがないーという人は是非「第一章 心構えと下準備」を読んで欲しい。最初の一歩を踏み出すきっかけをくれるんじゃないかなーと思う。技術的には最後の章のtwitter APIを例にしたOAuth認証の実装はなかなか細かく書かれていてOAuth認証するアプリを書いたことない人には凄くためになると思う。

そういや今年はGithub認証なんかも試して会社のエンジニアブログに書いたりした。

 

 Yコンビネータシリコンバレー最強のスタートアップ養成スクール

Yコンビネーター シリコンバレー最強のスタートアップ養成スクール

Yコンビネーター シリコンバレー最強のスタートアップ養成スクール

 

少なくとも2013年中には買った。

 読み物。「ハッカーと画家」や「On Lisp」で有名なポールグレアムがたちが上げたベンチャーファンドである「Yコンビネーター」の取材記録のような形でまとめられている。このファンド、ただ資金提供するだけでなく、有望なスタートアップ(或いはスタートアップになりそうなサービスを作ってる学生グループ)を集めて、住む場所と少額の資金提供を行って自立したスタートアップとして育てるという珍しい取り組みをしている。タイトルに「スタートアップ養成スクール」と入っているのはそのため。

本書内では、面接の様子から始まり、実際に「授業」としてポール・グレアムとの問答をしている場面や定期的に行われる「夕食会」様子を通して、Yコンビネーターや昨今のスタートアップに関する事情を述べている。

所感としては、自分自信は起業に興味がある訳ではなかったが、スタートアップのメンバーがどういうことを考えてサービスを開発しているかという点で色々勉強になることが多かった。

BtoCオンリーのサービスは非常に難しいので資金繰りを考えたらBtoBでスタートすべきだ、というグレアムの言葉が印象的だった。自分も思いつくのは大体BtoCだが、マネタイズの部分でいつも詰まってそこで「アイデア」レベルで止まってしまう事が多い。BtoBでマネタイズまで含めて考えて、そこからBtoCに拡大することも出来るわけで、そういう考え方をしないとビジネスとしてサービスを作るのは難しいと感じた。

 

デザイン

 ノンデザイナーズ・デザインブック

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

 

2013年9月ぐらい。

フロント側の実装案件が増えて、いい加減自分でもまともなUIが組めないといけなくなったのでデザインの原則を学びたくて購入。

デザインってセンスだと思ってたけどどちらかと言えば「パターン」や「原則」をいかに多く知っていて、それらをどういう時に使うかを知ってるかどうか、だと感じた。色の意味やフォントの効果は確かにセンスかも知れないが、全体の構成とかは完全にパターンがあるのでそれを守ってUIを作ることが大切だと感じた。

 Ruby関係

 今年に入ってから、個人的な勉強に始まり、自分で作ってるサービス、会社でのちょっとした社内システムでRuby + Railsを書いている。
Railsの本は。例によって例のごとく「プログラミング初心者向け」の本ばかりだったので一切買わなかった。それにバージョンが3.x系ばかりだったし、rubyも1.8系前提が多かった。ナウなヤングである自分はRuby2.0系とRails4.x系を使い、最初Macports + rbenvで挑んでドハマりしたものである(遠い目)。それ以来brewとrvmの組み合せが最もトラブルが無く、gemsetも使えて最高だということに気づいた。
自分はRailsチュートリアルRailsの日本語ドキュメントGithubでpublicになっているRailsプロジェクトのソースを読んで勉強した。
Railsは大きなプロジェクトになった時にどこに何のファイルを置けばよいのかが最初よく分からなかったが、クックパッド中村さんのソース等を参考に色々考えてやっている。(来年もお世話になります!qchan期待してます!)
勉強に使った書籍をも何冊かあるのでまとめておく。 
パーフェクトRuby (PERFECT SERIES 6)

パーフェクトRuby (PERFECT SERIES 6)

 

 

初めてのRuby

初めてのRuby

 

 

プログラミング言語 Ruby

プログラミング言語 Ruby

 

 

Rubyアプリケーションプログラミング

Rubyアプリケーションプログラミング

 

 

元々自分はPHPerなので(このブログの過去記事がPHPネタだらけなのもそういう理由)javaよりも取っ付き易く、それでいてPHPよりOOPの原則を守っていて例外もちゃんと投げてくれるし(PHPの大体の組み込み関数は未だにエラー時に例外を投げてくれない)、型指定が不要な分、javaより簡潔にいろんなのが書ける。
何よりブロックを引数として渡せるのが凄く便利でコードを完結にしてる。java8はよ来い。
というような感じでこれからも長く付き合って行きたい言語である。