iPadの購入を機に、ちょっと昔買ったMac Miniをいじっている。
キーボードはHHKBなんだけど、なんか接続すると英文字列入力時に配列がAsciiになってしまう。
Shift + 2が@になる感じ。
僕はずっと日本語キーボード配列だから、そうしたい。
でもなんだかぜんぜん設定いじってもできず、かれこれ数ヶ月放置していた。
んで今回、またチャレンジ。
http://plus-alpha-space.cocolog-nifty.com/blog/2009/12/windowsjisleopa.html
ありました。やりかた。
ただ、・・・なんでこんなに難しいことしなきゃいけないのって感じはするけど。
しょうがない。やりました。慣れないファイルシステムやらなんやらで、とにかく時間がかかった。
（Finderでルートディレクトリを見ても、ターミナルから見るルートディレクトリと様子が違うのはなんで？見る人が見れば一緒なのか）
でも、くじけずがんばった。意味わからないところだらけだけど、やった。
できた！
これからちょっとずついじっていく。次はOpenLDAPのインストールに挑戦
合格
プロジェクトマネージャ試験受かった。これはかなりラッキーだ。
午前2 60点 午後1 60点
大学からこの点数は変わらないな・・・。
あと、RSA Conference Japan 2010で講演することになりました。
午前2 60点 午後1 60点
大学からこの点数は変わらないな・・・。
あと、RSA Conference Japan 2010で講演することになりました。
コードレビューの仕方
今日自分の書いたコードをレビューしてもらった。
ほんの数十行のコード。
コードレビューをお願いする直前に、もう一度よく見直した。そしたら1つバグが見つかった。
で、ちょっと思った。このバグはコードレビューに出したら見つかっただろうかと。
見つかったかもしれないし、見つからなかったかもしれない。
それは分からないのだけれど、もし自分がこのコードのレビューをしたとしたら、見つけられた可能性は・・・やっぱり5分5分だと思う。（少なくとも僕は見逃しそうになったわけだし）
問題はコードレビューの意図だと思った。僕が見つけたバグはそのコード全体の全体の動きに比べると小さなもので、ある意味そのバグがあっても、ほとんどの場合うまく動いてしまう。
1つ1つの命令の詳細をレビューで追っていくと、ものすごく時間がかかるから、たいていの場合、自分が普段気をつけているいくつかのポイント（ポインタがNULLだったらどうかとか、メモリは開放されているかとか）を中心に見ていくことが多い。
やっぱり細かいところを1つ1つ追っていくのは骨が折れる・・・って最初から思って、やっぱりあんまり真剣に頭を使ってひとつひとつ追っていかない。（これは人のコードを修正するときの、最初のオーバーヘッドの重たさに似ている）
で、ちょっと考えた。なんとか頭を使って読んでもらう方法はないか。レビューアーには嫌われる方法かもしれないけど、以下の方法。
「あらかじめバグを仕込んでおいて、それを伝える」
最低1個はバグがあると言っておけばいい。そうすれば少なくとも1つはバグを見つけてもらえる。同じ所かもしれないし、違うところかもしれない。でも、きっと頭を使ってやってくれるはずだ。
コード量がある程度多いなら、3つとかでもいいと思う。最低3つはバグが存在するのだから見つけられる。コード領が多ければ、別の3つを見つけてくれる可能性が高い。
バグが見つからなければ、見つかるまでやってもらう。でも、見つけられるだけの情報（関数の仕様とか）はちゃんと伝えなくちゃいけない
あと、埋め込むバグは難しいものにしなくてはいけない。簡単なのだとみんなそれを見つけてくる。
整数オーバーフローとか、オフバイワンとか、ちゃんと考えないと見つからないやつがいい。
誰かやってみてください。で、どれくらい嫌がられるか報告ください。
ほんの数十行のコード。
コードレビューをお願いする直前に、もう一度よく見直した。そしたら1つバグが見つかった。
で、ちょっと思った。このバグはコードレビューに出したら見つかっただろうかと。
見つかったかもしれないし、見つからなかったかもしれない。
それは分からないのだけれど、もし自分がこのコードのレビューをしたとしたら、見つけられた可能性は・・・やっぱり5分5分だと思う。（少なくとも僕は見逃しそうになったわけだし）
問題はコードレビューの意図だと思った。僕が見つけたバグはそのコード全体の全体の動きに比べると小さなもので、ある意味そのバグがあっても、ほとんどの場合うまく動いてしまう。
1つ1つの命令の詳細をレビューで追っていくと、ものすごく時間がかかるから、たいていの場合、自分が普段気をつけているいくつかのポイント（ポインタがNULLだったらどうかとか、メモリは開放されているかとか）を中心に見ていくことが多い。
やっぱり細かいところを1つ1つ追っていくのは骨が折れる・・・って最初から思って、やっぱりあんまり真剣に頭を使ってひとつひとつ追っていかない。（これは人のコードを修正するときの、最初のオーバーヘッドの重たさに似ている）
で、ちょっと考えた。なんとか頭を使って読んでもらう方法はないか。レビューアーには嫌われる方法かもしれないけど、以下の方法。
「あらかじめバグを仕込んでおいて、それを伝える」
最低1個はバグがあると言っておけばいい。そうすれば少なくとも1つはバグを見つけてもらえる。同じ所かもしれないし、違うところかもしれない。でも、きっと頭を使ってやってくれるはずだ。
コード量がある程度多いなら、3つとかでもいいと思う。最低3つはバグが存在するのだから見つけられる。コード領が多ければ、別の3つを見つけてくれる可能性が高い。
バグが見つからなければ、見つかるまでやってもらう。でも、見つけられるだけの情報（関数の仕様とか）はちゃんと伝えなくちゃいけない
あと、埋め込むバグは難しいものにしなくてはいけない。簡単なのだとみんなそれを見つけてくる。
整数オーバーフローとか、オフバイワンとか、ちゃんと考えないと見つからないやつがいい。
誰かやってみてください。で、どれくらい嫌がられるか報告ください。
技術力とは
技術というものを追求するとか、生かすとか、ITの世界では求人などでもよく使われるし、人と話しているときもよくでてくる。
さて、技術力を付けるというのはどういうことか。Windows APIをすべて覚えることか、Linuxのソースコードをすべて読むことか、数あるページングアルゴリズムについてそれぞれのメリット、デメリットを理解することか。
僕のアプローチは、技術力とかそういうものだけでなくてだいたい以下のようになる。
なぜ、今の形になったかを知ること。
「どうなっているか」を知ることよりも「なぜ、そうなったか」を知ることの方が重要じゃないか、というのが今回とりあえず言っておきたいこと。
だから、Windows APIがどうなっているとか、Googleのサーバーがどうなっているとか、そういうことは、まあまず知ることとして、なぜそのような作りになったのか（他のやり方の候補があったはずであるにもかかわらず）ということをしっかり理解できるだけの知識を身につける必要があるんじゃないかと思う。
さて、技術力を付けるというのはどういうことか。Windows APIをすべて覚えることか、Linuxのソースコードをすべて読むことか、数あるページングアルゴリズムについてそれぞれのメリット、デメリットを理解することか。
僕のアプローチは、技術力とかそういうものだけでなくてだいたい以下のようになる。
なぜ、今の形になったかを知ること。
「どうなっているか」を知ることよりも「なぜ、そうなったか」を知ることの方が重要じゃないか、というのが今回とりあえず言っておきたいこと。
だから、Windows APIがどうなっているとか、Googleのサーバーがどうなっているとか、そういうことは、まあまず知ることとして、なぜそのような作りになったのか（他のやり方の候補があったはずであるにもかかわらず）ということをしっかり理解できるだけの知識を身につける必要があるんじゃないかと思う。
3年で読む本
今後3年で読むべき本をリストアップしてみた。
いろいろなサイトを参考に。すでに持っている本がほとんどだった。
特に参考にしたのは以下のサイト
http://leoclock.blogspot.com/2009/09/blog-post_21.html
一番上にMolecular Biology of the Cellが紹介されていて、これは自分が求めているサイトではないと一瞬思ってしまった。（この本は生物の本で僕も持っていたけど、すでに後輩にあげてしまった。たぶん、生物やってる人で持っていない人はいないんじゃないだろうか）
さて、というわけで読むべき本リスト
3年=1000日として、1日平均7ページだ。1週間に1回読むとすると、50ページほど読まないといけない。いままでの経験から、技術書を一度に50ページ読むことはほとんどできない。1週間に3回は時間を取らないといけないかもしれない。平均して1回17ページならなんとかなるだろうか・・・。1回辺りの時間は2時間。厳しいか。内容によるし、どれだけ自分で整理しながら読むかにもよるけど。
「コンピュータの構成と設計」と「構造化コンピュータ構成」はかなり内容がかぶりそうなので、とりあえず前者を中心に。
とにかく、基礎的なところを中心に。
この中でもっとも異色なのは「セキュアソフトウェア」。一応セキュリティ技術者なので、この分野のことを、具体的に一通り経験した方がいいだろうということで選んだ。教科書的な存在ではないので、ちょっと基礎からははずれる。そういう意味では優先度は低い。
ところで、このリストを作る過程ですごいものを発見してしまった。といっても、当然といえば当然なのかもしれないけど。
http://video.google.com/videoplay?docid=-2333306016564732003#
おそらくこれ、リストに一番上に上げたアルゴリズムイントロダクションの授業だと思う。
ただでMITの授業受けられるのか。感動的だ。
まだ、ちょっとしか見てないけど、役に立ちそう。
何より僕は本を読むより、授業の方が好きなので、これは助かる。
いろいろなサイトを参考に。すでに持っている本がほとんどだった。
特に参考にしたのは以下のサイト
http://leoclock.blogspot.com/2009/09/blog-post_21.html
一番上にMolecular Biology of the Cellが紹介されていて、これは自分が求めているサイトではないと一瞬思ってしまった。（この本は生物の本で僕も持っていたけど、すでに後輩にあげてしまった。たぶん、生物やってる人で持っていない人はいないんじゃないだろうか）
さて、というわけで読むべき本リスト
- アルゴリズムイントロダクション 1～2
- 計算理論の基礎 1～3
- 暗号の数学的基礎
- 離散数学 コンピュータサイエンスの基礎数学
- Windows Internals 5th Edition
- モダンオペレーティングシステム
- 詳解 TCP/IP Vol1
- コンピュータの構成と設計 上下
- 分散システム
- Database Management System
- 構造化コンピュータ構成
- セキュアソフトウェア
数えたら全部で 6979ページあった。
すでにある程度読んでいて、分かっている分もあるので、本当にすべてを端から読むわけではないけど、きちんと理解していくには相当時間がかかりそう。3年=1000日として、1日平均7ページだ。1週間に1回読むとすると、50ページほど読まないといけない。いままでの経験から、技術書を一度に50ページ読むことはほとんどできない。1週間に3回は時間を取らないといけないかもしれない。平均して1回17ページならなんとかなるだろうか・・・。1回辺りの時間は2時間。厳しいか。内容によるし、どれだけ自分で整理しながら読むかにもよるけど。
「コンピュータの構成と設計」と「構造化コンピュータ構成」はかなり内容がかぶりそうなので、とりあえず前者を中心に。
とにかく、基礎的なところを中心に。
この中でもっとも異色なのは「セキュアソフトウェア」。一応セキュリティ技術者なので、この分野のことを、具体的に一通り経験した方がいいだろうということで選んだ。教科書的な存在ではないので、ちょっと基礎からははずれる。そういう意味では優先度は低い。
ところで、このリストを作る過程ですごいものを発見してしまった。といっても、当然といえば当然なのかもしれないけど。
http://video.google.com/videoplay?docid=-2333306016564732003#
おそらくこれ、リストに一番上に上げたアルゴリズムイントロダクションの授業だと思う。
ただでMITの授業受けられるのか。感動的だ。
まだ、ちょっとしか見てないけど、役に立ちそう。
何より僕は本を読むより、授業の方が好きなので、これは助かる。
