ふと思い立ち、「人月の神話」「理科系の作文技術」とかIT業界で生きる技術者に勧める100冊みたいなのを考えてみた。どんなものがあるのだろうかとtwitterで聞いてみたら、「100人のプロが選んだソフトウェア開発の名著」というのを教えてもらった。というか、わたしも一冊紹介していることをすっかり忘れていた。すいませんすいません。（ぺこり） そこで、久しぶりに、読み返してみた。というか今までじっくり読んでいなかった。すいませんすいません。そして未読のものに付箋をつけた。付箋だらけになった。 100人のプロが選んだソフトウェア開発の名著 http://www.seshop.com/1satsu/100nin/ それはともかく本の紹介もさることながら、それにまつわるお話が面白い。読んだことがない本の紹介だと、ふーん、そうなのかぁーと思うこともあれば、ぜひ読んでみたいと思うものもあり、自分の趣味と皆

読んだ。2ヶ月かかってしまった。*1 ウォームアップ問題、その解答と解説があって、その応用ともいえる問題が記されている。で、ウォームアップ問題ですら、自力では解けるとは思えないほど難しい。むひょー。難しい。全然解けない。遅々として進まず。 解けないので、問題を読んで、ちょっと考えて、あきらめて、解答を読む。解答を読んで、問題の意味を理解するということもしばしばだった。問題を理解すらしていなかったということを再確認したりして、またむひょーとなる。 全然解けないのであるが、それでも徐々に慣れてきているような感覚を覚えた。 例えば、12ページのウォームアップ問題だ。 AliceはBobよりも所持金が多い。コイントスで出たコインが表か裏かで勝負を決める。Bobが先に裏か表にかけるか、そして掛け金を提示しなければいけない。残りゲーム回数はあと5回。Aliceはどのようにして勝率をあげることができるか

仕事で文書を書く必要がある人は「理科系の作文技術」(ISBN:9784121006240)を読むべきだ。 ここでいう仕事で書く文書というのは他人に読んでもらう文書をさす。他人に読んでもらうことを前提としないメモの類や狭義の日記などはこれにあたらないので、どう書こうが構わない。他人に読んでもらうことを前提とした文書は、相手に内容が伝わらなければ意味がないのだから、間違いなく相手に通じるように表現しなければならない。 小説、詩などの文学作品は、ここでいう「仕事で書く文書」に含めないことにする。文学作品と対比して、仕事で書く文書の特徴はどこにあるのか。それは、読者に伝えるべき内容が事実と意見にかぎられていて、心情的要素を含まないことである。 仕事の文書を書くときの第一の原則は、「必要なことは洩れなく記述し、必要でないことは一つも書かない」ことである。何が必要かは目的により、また相手の要求や予備知

内容：「DEBUG HACKS」の出版を記念して、著者らによる講演を行います。 http://www.oreilly.co.jp/books/9784873114040/ Debug Hacks――デバッグを極めるテクニック＆ツール * 吉岡弘隆、大和一洋、大岩尚宏、安部東洋、吉田俊輔　著 * 2009年04月25日 発売予定 * 424ページ * 定価3,360円 * ISBN978-4-87311-404-0 日時：4月23日、18時半開場、19時開始 場所：IIJ大会議室 http://www.iij.ad.jp/info/map/head-office.html 〒101-0051 東京都千代田区神田神保町1-105 神保町三井ビルディング 定員：100名 無料 プログラム案（変更の可能性あり) 19時00分　あいさつ 19時10分　DEBUG HACKS著者によるデバッグネタ＊5

4月下旬にオライリージャパンから「DEBUG HACKS――デバッグを極めるテクニック＆ツール」を出版する。http://www.oreilly.co.jp/books/9784873114040/ ミラクル・リナックス株式会社の精鋭エンジニアたちが、長年のLinuxカーネル開発の経験で培ったデバッグテクニックを詳解。こころがまえから、準備、必要な知識、バグの原因をすばやく特定し修正するために便利なテクニックとツール、高度なデバッグ技まで惜しみなく披露します。多くの事例に基づいた実際的実用的な技が満載です。効率良くかつクオリティーの高い開発のために必須の一冊です。 オライリーのページから目次を見ていただければわかるが、アプリケーションからカーネルのデバッグまで幅広く、記述している。デバッグに関する書籍が、あんまりなかったので、ミラクル・リナックスのエンジニアと約10ヶ月にわたって喧々諤々議

デバッグハックス校正中。 昨日の質問力(d:id:hyoshiok:20090306#p1)にはブックマークやコメントを思いのほかいただいた。やはり質問って大事だよね、という空気が少しでも漂うとウレシイ。とってもウレシイ。 質問が少ないのは、参加者だけがいけないのではなく、発表者も質問するなよオーラを微妙に漂わせているからではないか、というような趣旨のことを思っている人もいると思うので、それについても考えてみた。 わたしが発表する場合、必ず質疑応答の時間を取るように心がけていて、冒頭に質問もぜひしてください、と申しあげる。セキュリティ＆プログラミングキャンプキャラバンでは、最初のスライドで、質問してねと明示している。 それでもなかなか質問を喚起することが難しい。 アイスブレーキングだなんだというテクニックがいろいろあるらしいのであるが、空気をあたためるために、会場に質問をする。「〜について

前夜祭に出るために前泊し、懇親会に出るために土曜日も泊るというスケジュールを組み、OSC2008福岡に行ってきた。 http://www.ospn.jp/osc2008-fukuoka/ 出張！イケテルビジネス勉強会＠OSC Fukuoka 出張！イケテルビジネス勉強会＠OSC FukuokaというRBC (Ruby Business Commons)がやっているセッションに、まづ参加した。土曜日の朝一だし、どれでも良かった(失礼)のだけど、先日楽天テクノロジーカンファレンスの最首さんのセッションで紹介していたRBCを聞くことにした。やっぱしRBCのセッションは福岡じゃないとなかなか聞けないので、どーせなら、東京で聞けるものよりローカル色(？)が強いものを選らびたいなどと思ったのである。 会場の教室に入るときに、名前を登録するのだけど、なかなか土曜日の朝一にもかかわらず参加者が多い。名前を