プロジェクトマネージャ試験受かった。これはかなりラッキーだ。
午前2 60点 午後1 60点
大学からこの点数は変わらないな・・・。
あと、RSA Conference Japan 2010で講演することになりました。
My Daily Programming Life...
コードレビューの仕方
今日自分の書いたコードをレビューしてもらった。
ほんの数十行のコード。
コードレビューをお願いする直前に、もう一度よく見直した。そしたら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つを見つけてくれる可能性が高い。
バグが見つからなければ、見つかるまでやってもらう。でも、見つけられるだけの情報(関数の仕様とか)はちゃんと伝えなくちゃいけない
あと、埋め込むバグは難しいものにしなくてはいけない。簡単なのだとみんなそれを見つけてくる。
整数オーバーフローとか、オフバイワンとか、ちゃんと考えないと見つからないやつがいい。
誰かやってみてください。で、どれくらい嫌がられるか報告ください。
素数
RSA暗号の話を読んでいて、ついつい素数のところで寄り道してしまった。
Wikipedia読んだり。
素数なんて最初聞いたとき、これに何の意味があるんだ?って感じがするけど、おもしろい数の集合なんだなぁと思う。
きっと数学をやっていくと、どんどんこういうおもしろさにはまるんだろう。
Wikipediaにある素数は無限個あることの証明なんて、高校の時にやった記憶があるけど、僕もこんなことを勉強していたときがあるのか、と思うと不思議だ。・・・何の役にも立ってないw
でもこれからRSA暗号の話を読んでいけばきっと役立つはずだ
Wikipedia読んだり。
素数なんて最初聞いたとき、これに何の意味があるんだ?って感じがするけど、おもしろい数の集合なんだなぁと思う。
きっと数学をやっていくと、どんどんこういうおもしろさにはまるんだろう。
Wikipediaにある素数は無限個あることの証明なんて、高校の時にやった記憶があるけど、僕もこんなことを勉強していたときがあるのか、と思うと不思議だ。・・・何の役にも立ってないw
でもこれからRSA暗号の話を読んでいけばきっと役立つはずだ
技術力とは
技術というものを追求するとか、生かすとか、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の授業受けられるのか。感動的だ。
まだ、ちょっとしか見てないけど、役に立ちそう。
何より僕は本を読むより、授業の方が好きなので、これは助かる。
コンピュータセキュリティへの興味
CanSecWestで話をしたSEH Overwriteのエクスプロイトテクニックとそれに対する対策。
これはこれで、セキュリティという面でなんらかの貢献のできる内容なのかなぁとは思うけど、基本的にはやはり技術ありきでの話の内容になっている。
何らかの問題があって、それを解決するために調べてこの話をしたのではなくて、技術的にこういうことが可能であることを知ることが楽しいから、これを書いたということ。
コンピュータの利用や通信が安全になることには意味があると思う。ただ、現在存在するハードウェア、ソフトウェアの上に、安全性を築こうとする行為は、僕はあまり意味があるとは思っていない。
つまり、今回のSEHの話も、ものすごく小さな目先の話であって、こういうことをいくらやったところで、コンピュータを安全に(情報を盗まれないとか、不正アクセスされないように)使うことは無理だと思っている。
さて、一方ですばらしく安全なシステム、ハードウェア、インターネットが整備されていたら、僕はきっと楽しくないから、こういった内容について調べたりはしないだろう。
そういう適当さのある世界が好きだからインターネットやコンピュータが好きなのだと思っている。インターネットの世界も、僕が初めてインターネットを使い始めた当時(1996ねんごろ)の方が面白かったと感じる。
いろんな驚きがあったし、いろんな自由があった。いまでも自由だけど、あまりにも社会に影響しすぎている。
twitterとかも、みんなそんな自由さを求めているんじゃないかと感じることもある。(なんとなく適当に一言感じていることを言って、特に責任ある発言を求められるわけではない。)
今のネットワークや、個人PCに、それだけの安全性や責任を求める行為そのものに、僕は抵抗を感じているのかもしれない。今のままで十分楽しいと思ったり。
それは僕は基本的に性善説的な考え方をしているせいかもしれない。みんなで楽しく使えばいいじゃん、みたいな気楽なのりなのだ。
形式ばった、なんのミスも許されない、ちょっとしたミスでみんなからいろいろ言われる、そんな社会じゃ面白くないし、何にもしたいと思えない。悪い人もいるかもしれないけど、コンピュータそのもので人は殺せないし、いいんじゃないかって思う。
僕が大企業が向かない理由はこういうところにある。僕にとっては楽しく生きるうえでどうでもいいことが多すぎるんだ。
コンピュータの世界は中小企業のような自由さから、だんだんと大企業的な世界に変わっていっているように思う。
そのうち、コンピュータやインターネットにも興味を持たなくなるときがくるかもしれない。
これはこれで、セキュリティという面でなんらかの貢献のできる内容なのかなぁとは思うけど、基本的にはやはり技術ありきでの話の内容になっている。
何らかの問題があって、それを解決するために調べてこの話をしたのではなくて、技術的にこういうことが可能であることを知ることが楽しいから、これを書いたということ。
コンピュータの利用や通信が安全になることには意味があると思う。ただ、現在存在するハードウェア、ソフトウェアの上に、安全性を築こうとする行為は、僕はあまり意味があるとは思っていない。
つまり、今回のSEHの話も、ものすごく小さな目先の話であって、こういうことをいくらやったところで、コンピュータを安全に(情報を盗まれないとか、不正アクセスされないように)使うことは無理だと思っている。
さて、一方ですばらしく安全なシステム、ハードウェア、インターネットが整備されていたら、僕はきっと楽しくないから、こういった内容について調べたりはしないだろう。
そういう適当さのある世界が好きだからインターネットやコンピュータが好きなのだと思っている。インターネットの世界も、僕が初めてインターネットを使い始めた当時(1996ねんごろ)の方が面白かったと感じる。
いろんな驚きがあったし、いろんな自由があった。いまでも自由だけど、あまりにも社会に影響しすぎている。
twitterとかも、みんなそんな自由さを求めているんじゃないかと感じることもある。(なんとなく適当に一言感じていることを言って、特に責任ある発言を求められるわけではない。)
今のネットワークや、個人PCに、それだけの安全性や責任を求める行為そのものに、僕は抵抗を感じているのかもしれない。今のままで十分楽しいと思ったり。
それは僕は基本的に性善説的な考え方をしているせいかもしれない。みんなで楽しく使えばいいじゃん、みたいな気楽なのりなのだ。
形式ばった、なんのミスも許されない、ちょっとしたミスでみんなからいろいろ言われる、そんな社会じゃ面白くないし、何にもしたいと思えない。悪い人もいるかもしれないけど、コンピュータそのもので人は殺せないし、いいんじゃないかって思う。
僕が大企業が向かない理由はこういうところにある。僕にとっては楽しく生きるうえでどうでもいいことが多すぎるんだ。
コンピュータの世界は中小企業のような自由さから、だんだんと大企業的な世界に変わっていっているように思う。
そのうち、コンピュータやインターネットにも興味を持たなくなるときがくるかもしれない。
