EloquentJavaScript（本家） http://eloquentjavascript.net/
英語力のない人間が、英語の技術資料を読むのって大変で、ついつい斜め読みしたり、必要だと思うところを（根拠もなく）決めつけて拾い読みするという感じになりがちだ。ソースは私。
やっぱり日本語訳で読みたい。その一方で、ちゃんとJavaScriptも勉強しておきたいな、と思ったので、勉強のために自分で翻訳することにした。有名な資料だから、誰かとっくに翻訳してるだろうけど、自分の勉強だから。
EloquentJavaScript（日本語訳） http://dl.dropbox.com/u/2198478/eloquentJavaScript/index.html
本文を翻訳したところで力尽きたので、とりあえずできたところまで。
#!/usr/bin/env python
#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""
toodledo2grwol : Display grwol notify tasks of Toodledo
"""
from datetime import datetime
from apiclient import ApiClient
import gntp.notifier
# Task Filters
def _taskFilter(tasks):
"""
Task Filter -- return filtered tasks
"""
def _isUncompleted(task):
"""
Task Uncomplered
"""
if hasattr(task, "completed") == False:
return True
else:
if task.completed == "0":
return True
else:
return False
def _hasDuedate(task):
"""
Task Has Duedate
"""
if hasattr(task, "duedate") == True:
if task.duedate != "0":
return True
else:
return False
else:
return False
for task in [ task for task in tasks if (_isUncompleted(task) == True) and \
(_hasDuedate(task) == True)]:
yield task
# create Toodledo Client
api = ApiClient(app_id = "aaaaaaaa", app_token="bbbbbbbb")
# Toodledo Authentication
api.authenticate('cccccc@cccc.cccc', 'dddddddd')
# Get Task list from Toodledo
task_list = api.getTasks(fields="duedate")
# Register to Growl
growl = gntp.notifier.GrowlNotifier(
applicationName = "aaaaaaaa",
notifications = ["Task"],
defaultNotifications = ["Task"],
)
growl.register()
# Send Notify to Growl
for hot_task in _taskFilter(task_list):
duedate = datetime.fromtimestamp(float(hot_task.duedate))
growl.notify(
noteType = "Task",
title = hot_task.title,
description = duedate.strftime("DueDate: %Y/%m/%d"),
icon = "file:///C:/Users/eeeeeeeeeeeeeee/icon.png",
sticky = False,
priority = 1,
)
# end
自分PCローカルで動くGrowl通知に加えて、boxcar経由で通知を送るWebサービス(GAE/p)版も作ろうとしてる。こっちは難航中。GAEにモジュール突っ込むときのimportのルールがいまいち怪しいのだ。アジャイル開発のメリットを活かし、難しいところをどうカバーするか。そんな観点で書かれたRedmine本。
Redmineそのものの説明もさることながら、現場の悩みをどう解決するかというところに深く切り込んでいて、ソフトのスクリーンショットより、チーム内で発生する仕事（チケット発行やら障害対応やら）のワークフロー図の方がむしろ多いくらい。
ツールの解説書によくあるような、「便利だから皆使おうぜ！」的バラ色話のノリは無い。クリーンな実験室のような、それ自体ありえないような環境でなく、現場の中でどう使ってきたという話が中心になっている。ホワイトボードと付箋の組み合わせから、Excelのガントチャート、Tracのような障害管理ツールなど、他のツールを経てRedmineにたどり着くまでの試行錯誤。既に他のツールでの管理が行われている中での部分的な利用など。実体験に即した話には「お前のところではそうだったんだろうけどよ～」的な感想を抱きがちな私だが、取り上げられている事例の豊富さと、適用の柔軟さには素直に感心した。
Redmine自体については、基本的な操作方法とか、見れば分る的なところはそこそこに、おすすめのプラグインの紹介があったり、あるいは個々の事例で、Redmineからどのような情報を引き出して報告書を作ったかといったプロジェクト管理をやった事がある人なら当然知りたいことに多くの紙面が割かれている。
自分が一番うれしかったのはTestLinkとの連携について書かれていた第3部。「アジャイルやテスト駆動開発のテスト自動化って、単体テストだけなの？」という長年の疑問に対する答え（の一部）がここにあった。情報が溢れて泣きそうになるのは、むしろ結合テスト以降なんだよなぁ。（私だけかもしれんけど）
科学、社会調査、画像、自然言語など、様々な大量のデータの収集、分析、表現の事例集。
1人の著者がインタビューを元に構成したものではなく、当事者自身が論じる形式になっている。そのため、切り口と語り口は各章でかなり違い、サンプルコードが示されているものもあれば、収集に使った機器の機能とスペックに紙面を割いているものもある。
読めば役に立つという類の本では無い。「こうしましょう」「こうすればうまくいく」的な定石、ベストプラクティスはなく、「あれを実現するために、こういうことをやった」という個々の活動を過去形で語っているだけの本だから。「うまくいったと思うんで、真似してよ」ですらない。
退屈にしか思えない章もあれば、とても面白かった章もあったが、これは自分の興味関心の偏りによるものだろう。具体的には、データを正しく扱うこと、役立てることの難しさについて語った13章「データでできないこと」(Coco Kurmme氏)が面白かった。
忙しい人が仕事の合間を縫って読むには全く適していない。重いし、かさばるし。読み物として、本を読めるだけの余裕のある人が、知見を広げるために読む本。あるいは、目の前の問題をどう扱うか考えあぐねていて、ヒントを求めている人にはもっといいかもしれない。いろいろな分野に取り組んでいる人が、どういうことを考え、どういう道具を使っているか知ることができるから。
装丁や図版は美しいが、安価な本では無いし大判なので都市住人の本棚には向かない。読みたい人は最寄りの図書館にリクエストするか、購入した後、図書館に寄贈するのが良いと思う。
ソースコードを読む技術（amazon）
ソースコードの書き方ではなく、読み方にフォーカスした本。
しかも、どちらかというと技術そのものを解説している本ではなく、コードを読むためにどのような前提知識や道具が必要かということの紹介に徹している。既にプログラマーである人が感銘を受けるようなものではない（「2年前から知ってたわ～」的な意味で）が、プログラミング言語を覚えた人がプログラマーになるために必要な（だが伝えにくい）ステップの一つをうまく整理していると思う。
初学者だけでなく、今まで自己流でやってきて他の人から教わってこなかった人が読むのにもいいと思う。初学者にとっては「こんなことまで知ってなきゃいけないのか」、自己流の人は「あ、こんなやりかたもあったんだ」と思える（かもしれない）ような内容だ。だから、初学者には「何から、どんな情報を読み取ることができるか」、自己流の人には「こんな道具もあるんだよ」ということを読み取ってもらいたい。
後半では、実在するC言語の標準ライブラリの一部を全体の1/3かけて、丁寧に（執拗に）解析して見せている。人がいちいち教えたら何時間もかかりそうな（放り出してしまいたくなるような）内容だ。こういうところが書籍という自習に適した形になっているのはありがたい。
自分の手元に置きたい本というよりは、他人に読ませたい本。
本の記事が増えてきて、「雑談」と言い切りづらくなってきたし、タイトルが「今日読んだ本」で揃っちゃうのもアレなんで、今後は本のタイトル（or内容）を意識したものにしていこうと思いますよ。
SEのための見積もりの基本 (amazon)
見積もりの2つの側面
- 見積もることそのもの
- 実際に起こったことを、見積もりに合わせて調整すること
やはりこの世の真実はそうだったのだ。それ自体が正しい見積もりなど存在しないのだ。最初に掲げた見積もりに合わせて、現実の方を修正する。自己成就予言という奴だ。この本には顧客や会社に対しての報告数値をごまかして、あたかもプロジェクトが見積もり通り終わったのだということにするための手練手管が書かれているのであろう。
しかし「見積もりが正しい」ってどういうことなんだろう？結果が実際にそのようになれば正しいのか？そして見積もりはなぜ正しい必要があるのか。
本書は、システム開発の流れに沿って、局面毎に必要になる見積もりとその方法を解説する構成になっている…はずなんだけど。扱う見積もりの種類がシステムの規模・工数から性能予測、バグの件数まで多岐にわたっていること。そして、見積もりから外れてしまいそうになった時への対処に多くの紙面が割かれていること。この2点の影響で、見積もりそのものをこの本から学ぶのは、かえって難しいのではないかと思われる。
本の内容は、開発の局面毎に順を追って構成されており、その場その場で必要な技法が紹介されている。それはそれでいいのだろうが、それぞれの局面で何を見積もる必要があって、それはなぜなのかという説明が（恐らくは自明のものとして）省かれているので、何かにつけて、とても唐突な印象を受ける。単体テストでは、境界値と網羅率でテストをし、エラーを測ってエラー率を計算し、信頼度成長曲線を引きます。えっ、そりゃそうでしょうけど…。
本書の対象読者は「SEやPMなど、見積もりを作成する全ての人」とされている。それだけでなく、発注者側・受注者側、双方の立場で読めるようになっている。各人の担当により、プロジェクトの中でどのような利害対立が起こるかの図示から始まる構成は面白いと思った。ただ、タコのように足を多方向に伸ばした結果、今読んでいる説明が誰の立場で書かれているかがわかりにくくなっているのが惜しい。また、複数の立場の者に読ませようという意図があるなら、数値の出し方だけでなく、それぞれの立場での読み方（例えば、出て来た数値の妥当性をチェックする観点）も書かれていないと片手落ちだろう。
1冊の本を書き上げるのには、大変な労力がかかる。一生のうちに、複数の本を出版できるなんて、想像できる人も少ないだろう。今まで何冊か読んできて思ったのは、1冊で何もかも書いてやろうとしてわかりにくくなっている本の多さだ。要素技術にフォーカスしている本と違って、実際のプロジェクトへの適用を意識した本だと、なかなかスパッと整理されたものが出てこないね。想定する前提で変動するものが多すぎ、大きすぎるのだろうか。かといって、事例を挙げるだけだと「お前の中ではそうなんだろう。お前の中ではな…。」になっちゃうしなぁ。