これに関連する興味深い指摘を社会学者の佐藤俊樹さんがされています。佐藤さんによれば、最近「ガリ勉」は絶滅の危機に瀕しているそうです。一昔前だったら、暗くても地味でも野暮ったくても勉強ができれば、「ガリ勉」タイプの若者でもそれなりに周囲から認められていたのが、今はそうではなくなっているそうです。今の若い人の間では、仲間内でおもしろい話をして場を盛り上げることができたり、音楽や服装・髪型など洗練された消費文化によるセルフ・プロデュースの能力がとても重視されるようになっている。こうした状況のもとでは、ちょっと無口だったり元気がなかったりするだけで、その子はとても生き辛くなります。その結果、「負の連鎖」がいっそう増幅されかねないのです。
べつに今に始まったことじゃないと思うけどなあ。勉強ができるということが昔ほど人として立派なことだと思われなくなったり、場を盛り上げるのが簡単ではなくなったり、ということはあるのかもしれないけど。でも、昔から無口だったり元気がなかったりする人間は、あんまりアピールはしなかったんじゃないのか？
てゆーか、気の利いたことの一つも言えない「ガリ勉」って、なんのための知識よ？
家のマシンにもMySQLのソース・コード展開したので自分メモ。MySQL5.0.15準拠。
ビルド環境の構築がどうのこうのとか、面倒くさいことは全部飛ばして、いきなり核心に入ると、重要なのは sql/handler.h で定義されている class handler。すべてのストレージ・エンジンはこのクラスを継承して作ることになる。コイツを継承して、pure virtualになってるメンバ関数を定義してやれば、それで一応ストレージ・エンジンとして動作するはず
……と言いたいところだが、ちょっとだけ違う。まずstruct handlertonというストレージ・エンジンについての情報を保持した構造体を作って、handler.cc中のsys_table_typesに追加しなきゃいけない。そしてなぜかストレージ・エンジンの終了処理についてはhandlertonに記述できないので、handler.cc:ha_panic()の定義中に直接書き込まないといけない。謎。
これだけやって、自分のソースファイルがmysqldにリンクされるようにsql/Makefile.amあたりを修正すれば、オレ様エンジン内蔵のmysqldが作れるはず。(つづく予定)
1書いたそばから2。細かい話する前に自前のストレージ・エンジン書くと何ができるか？
MySQLのクエリ・プランナはclass handlerを操作する。handlerの子クラスはクエリ・プランナに対して若干のパラメータを渡すことはできるが、基本的にクエリ・プランに対するコントロールを握ることはできない。なので、特殊なクエリ・プランを実行してもらえればいい事がある、というようなエンジンの実現はストレージ・エンジンだけでは難しい。MyISAMやInnoDBと同じようなクエリ・プランを投げられると思っていた方がいい。その前提の下で、特定のデータ、特定のアクセス・パターンにおいて、なんらかのメリットが生まれるデータ形式ってのがあれば、自前のストレージ・エンジンを書く理由になる。
5.0で追加された、別のMySQLサーバにホストされてるテーブルにアクセスするfederatedエンジンとか、データをgzip圧縮して格納するarchiveエンジンなんかは、まさしくそういう例だ。
逆にいうと、4.xではNDB Clusterがかなり異色だったのを除くと、MyISAM,BerkeleyDB,InnoDBとどれもそんなに特殊な用途に最適化されたエンジンではなくて、ストレージ・エンジンをplug-inできることのメリットってのがあんまりよく分からなかった気がする。
つか、ぶっちゃけ、BDB,InnoDBを取り込むためにたまたまそうなっただけであって、元から深く考えてそういうアーキテクシャになったわけじゃないんだろう＞ストレージ・エンジンのplug-inシステム。
昔書いたWordで40ページぐらいの報告書の内容をupdateして、高橋メソッドでプレゼン化したらすげー枚数になってしまった。まあ、1枚20秒ぐらいでやれば時間的には大丈夫か。予行演習やってないのでアレだが、たぶん実際は平均5秒/枚だろ。てゆーか、すでに十分多いのに、ウケ狙いのネタ追加するな＞オレ。
しかし、こうしてみると、高橋メソッドってアレね。OHPや35mmスライドじゃなくてPCでプレゼンできる時代になって、初めて現実的になったと言ってもいいよな。OHPでこの枚数はとっちらかっちゃって不可能だし、35mmスライドならマガジンに入れときゃとっちらかりはしないけど、内輪のプレゼンでこの枚数のスライド焼くのは財政的にどうなのよって感じ。