読んでいる本，読みたい本

あれやこれやと手を出して，結局まともに読めている本が少ない気がします．
ちょいとメモ代わりに読んでいる本と読みたい本をまとめてみます．

いずれ，一冊ずつちゃんとレビューしたいですね．

1. 読んでいる本

• プログラミング
JavaScriptはブラウザでリッチな動作をさせるために，必須の言語・技術と言っていいでしょう．が，意外とSEでこの言語に詳しい人って少ないんじゃないでしょうか．
案件によく知っている人がいれば，その人に相談したり，レビューに呼んだり，実際に作ってもらえばいいんでしょう．でも，少人数の案件だとそ うも言ってられません．提案するためには何ができるか知っていないといけないですし，設計したりレビューしたりするには思想を知っておくべきです．まして や自分で実装するとなるとなおさらです．
• JavaScript: The Good Parts
JavaScript: The Good Partsは，JavaScriptの言語思想や設計方法を学ぶには最適な本だと感じます．あと，この手の本にしては薄くて気軽に持ち運べます．O'Reilly Japan Ebook StoreでPDF版も売ってます．ただ，JavaScriptを軽くいじった程度の僕にとっては結構難しいです．1週目では十分理解できていない気がしましたので現在2週目です．徐々に分かってきたぞー！
• jQueryデザイン入門
JavaScriptを適当に使ってみた印象は，「良く分からない」，「何かとめんどくさい」 でした．「良く分からない」の方はただ単に言語自体が分かってないだけでしょう．「めんどくさい」のはデフォルトで用意されているAPIがあんまりよろしくないせいかと．無理して書こうとすると酷いことになりそうです．プレーンなJavaScriptで大量のDOM操作や，Ajax実装するとか勘弁して頂きたいところです．
んなわけで，JavaScriptの代表的なAjaxライブラリであるjQueryのレシピ集として買いましたが，すごい分かりやすいですね．上記のJavaScript: The Good Partsを読んだ後だと「ん？」と思うこともありますが，頭空っぽでも読めるし，「おお，こんな事もできるのか！」と楽しく読める良い技術書だと思います．jQueryのプラグインとか自作できるようになりたいですね！
• jQueryクックブック
ちょっと凝った事がやりたくて，上のレシピ集に満足できなくなってきたらこの一冊？オライリーのクックブックはただやり方を書いてあるだけでなくて，何故そうなるかを書いてくれる本が多いので好きです．理屈が分からないと覚えられない人なので．．．
• アーキテクチャ，フレームワーク
• システムアーキテクチャ構築の原理 - ITアーキテクトが持つべき3つの思考
先輩に勧められた本．アーキテクトが業務を行う上での，視点や仕事の仕方に分かりやすく論じられています．しかし，分厚い．．．分かりやすいので休日1日とかで一気に読んでみようかな．
• JavaによるRESTfullシステム構築
数年前から話題のRESTですけど，実際にエンタープライズでの実装ってどうするの？というのが気になっていたので購入しました．後回しになってしまっているけど，是非読みたいです．
• エッセイ
• プログラマが知るべき97のこと
O'Reilly Japan Ebook StoreでPDF版を買ったので，通勤途中にiPhoneで読んでます． 1トピックが2ページに収まっていて，落ち着いて読めない通勤中にサクッと読むにはちょうど良い感じ．（難しい本とかろくに読めない．．．）
97人のプログラマのエッセイ．97もあるとネタが被ってたり，ただの武勇伝になってたりする人とかいますけど，様々な課題に取り組む人の考え方が一覧できていいですね．
プログラマって書いてあるけど，コードを書くだけのプログラマでは無くて，顧客に提案をして，見積もりして，設計して，もちろんチームをまとめて〜という業務を想定してます．

2. 読みたい本（メモ代わり）

• プログラミング
• Java: The Good Parts
上記のJavaScript: The Good Partsにお世話になってますので，新刊のこれにも注目．Javaで実装を妨げるような設計・コーディングをしていないか再確認したいですね．
• JavaScriptパターン - 優れたアプリケーションのための作法
1ページずつ別々にJavaScriptでクライアントサイドのコードを実装しているうちはさほど問題は無いけれど，大きな実装や，フレームワークを作ろうとする際にはJavaScriptにも適切な設計が要求されるようになるでしょう．で，JavaScriptでの実装パターンてどんなの？と思っていたところの新刊なので，とりあえずAmazonでポチっておきました．結構楽しみです．
• アーキテクチャ，フレームワーク，設計
• 検討中・・・
• Spring関連 or J2EE関連
• WCF関連
• UML
UMLのうちいくつかは頻繁に使うけれども，読む人に意図が伝わらなかったり，我流で使用して誤解を生んでしまっては意味が無い．むしろ，そのドキュメントは無いほうがいいでしょう．
偉そうに書いてますが，僕自身が我流でやっているので，自信を持って業務で利用できるような，他人のUMLに対して適切なアドバイスができるようなレベルを目指したいですね．
• エッセイ
• ソフトウェアアーキテクトが知るべき97のこと
『プログラマが知るべき97のこと』の手軽さが気に入ったのでこっちも読んでみたいですね．ただ，こっちはPDF版がまだ出てないので満員電車だとちょっときついです．

（多い．．．優先順位つけないと全体的に浅くなりそう）

WEB+DB PRESS Vol.60 - プログラマが知るべき言語設計の基礎知識

個別の技術書ではなく，技術系の雑誌を読むと，普段意識していない分野についても情報収集ができてお得な気分です．

プログラミング言語を開発した人は，どうすれば人が『楽に』開発を行えるようになるかを考えてその言語を設計しています．なので，プログラミング言語の設計思想を知った上で，言語の選択や，設計・実装を行う事で，プロジェクトの生産性を高めることができるかもしれないですよね．まぁ，そんな劇的には効果はないでしょうが，一つの考え方の指針にはなるんじゃないかとは思います．

現在，当たり前のように使われているクラス・オブジェクトという概念や， もっと前から使われてきた文法規則などは，昔の言語設計では難しかったことを，『楽に』するために取り入れられ，徐々に受け入れられて来たもの．今普及している言語にも解決できていない弱点がある（多重継承の問題など）から，将来的にはそれを補うような設計思想を持つ言語に世代交代していくんでしょう．

弱点を補うために，より抽象的で表現力豊かな言語を採用すると，生産性を高める事ができるけれど，同時に学習コストが高いという問題もあります．現実的には学習コストが低く，より広く普及している言語と，目的に適した支援ツールやフレームワークなどを組み合わせた方がスムーズになる可能性は高いですね．

ただし，現状スタンダードな言語が将来もそうあり続ける可能性は低いので，現状の言語仕様が当然のものという思いは危険です．近い将来も，設計者・実装者としても役に立つよう，今使用している言語の課題を認識しておく必要があると感じます． 実際のプロジェクトで使うかは別として，空いた時間等で他の言語に触ってみるという学びの姿勢は重要なんじゃないかなと改めて感じました．

考えを文字にする

最近，読んだ本のことを人に伝えようとしても，あんまりうまく説明できないのが悔しい．原因の一部として，十分に考えを整理していない事があるんじゃないかと．そんなわけで，技術書なり小説なりを読んだら，メモ代わりに一回ここで文字にして整理してみようと思います！