行動遺伝学 - 兼雑記
社会的に成功した人は、遺伝的に有利だったのか、環境が良かったのか、本人が頑張ったのか、犯罪を犯した人は、先天的になにかあったのか、教育や環境が悪かったのか、よくそういうことが気になります。ときどきその手のことを考えるヒントになりそうな本とかを読んでみたりしてたのですが、友人から教えてもらった本のおかげで、行動遺伝学というジャンルが、この手のトピックに科学的なアプローチで取り組んだりしているぽい、ということを知りました。というわけで、冬休みの自由課題的に色々読んだりしてみたので、なんか色々と書いてみます 結論から書いておくと、最初にあげたような疑問は、行動遺伝学を学ぶことによって完全に解決する、ということはなさそうです。ですが、いろいろわかっていることもある、考えるヒントになる、というあたりが収穫かな、と思っています 読んだもの Introduction to Human Behaviora
開発イテレーション偏重 - 兼雑記
開発イテレーションを早くすれば、かなりの問題が勝手に解決される、と信じています。なんか最近、他の要素を軽視しすぎていたり、特にイテレーション速度に影響しなさそうなことすらしている気がしていて、信仰とかのレベルかもしれない、という気がしてきたので、ちょっと書いてみようかなと。主に C++ の話です。 仕事とかしてると良い判断力が求められたりしますが、判断というのは結構難しいですよね。アプローチ A と B で悩んだ時に、手が速ければ両方できたりします。開発イテレーションを無限に速くすると、必要とされる判断力はゼロに漸近していきます。やったね。 2手で変更の正当性を高速に確認できるようにする make (かその他のビルドコマンド)てやったらビルドができて、 make check (かその他のテストスクリプト)てやったら遅くないテストが全部走る、という体勢が好きです。試すためにはあっちのディレク
Brainfuck interpreter in Ruby's Regexp - 兼雑記
Ruby の正規表現だけで Brainfuck インタプリタを作ることができました。正規表現の実行は =~ だけなので、ループなども正規表現の内部で実行してます。 https://github.com/shinh/hack/blob/master/bf_rb_reg/bf.rb つまりどういうことができるかというと、 BF_REG という Regexp と BF_SUFFIX という文字列定数があって、 bf という文字列に格納された Brainfuck のコードを BF_REG =~ bf + BF_SUFFIX で実行することができます。出力は $~['o0'], $~['o1'], ... に入っているので、 output = '' 256.times do |i| o = $~["o#{i}"] break if !o output += o end 的なコードで取り出すことができ
機械は人狼を見つけられるかな - 兼雑記
http://shinh.skr.jp/expwolf/ スパムフィルタの要領で作った人狼を探すプログラムです。新四国のURLを適当に放り込んでください。 http://shinh.skr.jp/expwolf/?q=http%3A%2F%2Fmshe.skr.jp%2Flog_591_3.html んでもって、「情報」のところのページのURLを放り込むとその村全体を評価してくれます。「情報」のページに結果が出ていたらその結果を [] 内に表示します。 http://shinh.skr.jp/expwolf/?q=http%3A%2F%2Fmshe.skr.jp%2Flog_591_info.html この村は人狼吊れなくて狼勝利のようですが、この予測装置は正解を当てています。もちろん白ログしか見てません。 たぶん進行中の村でもオケです。後述しますが、データはたく国654村以前から取得した
StringPiece というライブラリの話 - 兼雑記
例えばこう、ディレクトリの名前とその中のファイル名を / でくぎって結合する関数を書くとします。引数が std::string でも使いたいし const char* でも使いたい、ということで、たいていは void JoinFilePathStr(const string& dir, const string& base, string* out) { out->clear(); out->append(dir); out->push_back('/'); out->append(base); }なんてのを書くんじゃないかと思います。この関数で問題になるのは const char* を渡すと不要な string object が一度できることで、敬虔な C++ 屋さんだと、 void JoinFilePathStr(const string& dir, const char* base,
WebKit について (テスト) - 2010-01-04 - 兼雑記
テストについて。テストは、 Layout tests と呼ばれるもので行なわれています。 LayoutTests というディレクトリに入っています。これはテストの html を用意しておいて、それに対してどういうふうに rendering する予定であるかをあらわす render tree というものをテキストとして出力させて、それに対してテストを増やす時に置いておいた expectation との diff を取って diff が無ければテスト成功という感じで行なうテストです。 テストは、緑背景に PASS と書いてあるなど、見た目で成功しているか失敗しているかがぱっとわかるテストが好まれるようです。例えばこんな感じ: http://lt.shinh.org/t.html#t=css2.1/t0801-c412-hz-box-00-b-a 元々はその render tree の比較しかな
WebKit について (レビューとか文化とか) - 2010-01-03 - 兼雑記
WebKit のコードレビューについて。 Google ではこのコンポーネントはあの人が詳しそうだなーという人にコードレビューをお願いするシステムなのですが、 WebKit では WebKit reviewer 全体に review を頼んで、このコードは俺が得意だとか見られると思った reviewer が review するシステムになっています。また、 Google やら Chrome やらではほぼ committer==reviewer と言って良いのですが、 WebKit の場合は committer になってさらにかなりの修行を積んだ人だけが reviewer として認められるシステムになっていて、 reviewer は committer よりかなり人数が少なめになっています。 さてこのシステムだと実際のところどういう感じになるかというと、 reviewer を指定しないので「
WebKit について (コード) - 2010-01-02 - 兼雑記
WebKit のコードについて。 Google 社内のコードを見慣れてると、 WebKit のコードはまず、オープンソース的な感じというか、ありていに言うとコメントが圧倒的に少ないように感じます。特に内部についてわかってない人もわかるようなコメントを書く気は基本的に無いらしく、冗長気味なコメントを書くとむしろ削ってちょとレビューされたりします。偉い人死んだらどうするのかなー的な。 あとは関数名とかもイマイチなのが多いように思います。個人的な体験で一番印象的だったのは HTML parser 内にあった parseSpecial という関数でした。この special ってのは textarea, script, style, iframe なんかの中にあるタグが無視されるような種類のものを指していたのですが、 special って命名はアレだなぁ…と。そう思いつつ WebKit の人はみん
Glen 2009-08-12 - 兼雑記
Linux Chrome にちょっとおもしろいバグがあったので書いてみます。ある日、 Linux Chrome の閉じるボタンが (Glenさんという) 人の顔になるという change がコミットされました。何が起きてるかは以下のスクリーンショットが大変わかりやすいです。 http://www.flickr.com/photos/yanbe/3792080316/ それに対してみなさんがバグを登録。みんなヘンなオッサンとか魅力的な女性の方が良かったとか言いたい放題です。 http://code.google.com/p/chromium/issues/detail?id=18385 http://code.google.com/p/chromium/issues/detail?id=18397 http://code.google.com/p/chromium/issues/detail
思い出し - 兼雑記
もう2日になってしまったけど、少し1年を振り返りたいと思うのでした。作ったツールで今でも使ってるものとしては、 caddy wga fake_isatty binspect あたりは今年らしい。 binspect はもうちょいなんとかしたいなぁ(TODO)。 まっとうなものとしては jsdmkun google-glog sevilwm に色々 あたりかな。バイナリ遊び的なものは Yajit TCC for x86-64 Rubygrind あたりか。後 glog のバックトレースまわりとかもそんな感じではあった。 Yajit はもうちょいなんかしたいなぁ。 TCC も TODO 残ってるのでやらねばならぬ。 クソコードとしては、 quine.grass fizzbuzz7.gif hh.gif 数値とアルファベットだけの Ruby プログラムを生成 GIFは楽しいなぁと再確認したりしてい
binspect - 兼雑記
http://shinh.skr.jp/dat_dir/binspect.tgz ずっと放置するよりは…と思って出すことに。JVM Golf をやった時に作った、汎用バイナリフォーマット解析コマンド&ライブラリ、を作りたかったものです。 binareal 見て 1 年後にちょっと作ってみたものを 2 年してから出すというようなそういう。 % ./binspect.rb hello.gif hello.pなどとすると Ruby の pp で GIF をダンプしたものが出力されます。 [[:fileHdr, [[[:signature, "GIF"], [:version, "89a"]]]], [:logicalScreenDescriptor, [[[:width, 35], [:height, 100], [:packed, 128], [:bgcolor, 1], [:aspect_r
息を吸うように objdump 2007-12-16 - 兼雑記
このへんで書いた、どうなってるか自信が無いことがあったらとりあえず objdump しちゃえという話…とか言うと「アセンブリは…」みたいな雰囲気になることが多い気がするんですが、正直アセンブリなんか読めなくてもコードがどうなってるかくらいはわかるよん、という当たり前の話。 #include <stdio.h> struct S { explicit S(int x) : x_(x) {} int x() const { return x_; } int x_; }; int main() { S s(3); printf("%d\n", s.x()); } とりあえずこんなコードをインライン化されるか知りたいとする。とりあえず -g つきでコンパイルして objdump 。 % g++ -g inline.cc -o inline % objdump -S -C inline | lvコツ
更新履歴兼雑記 - dumper-0.1.0
http://shinh.skr.jp/binary/dumper.tgz C で使える Kernel#p 作りました。マジメにやってみると結構面倒だったです。 http://d.hatena.ne.jp/shinichiro_h/20051207#1133881740 の続きです。 libdwarf が必要なので、なんとなく適当な rpm パッケージも作りました。 Debian はパッケージがあるみたいですね。 http://shinh.skr.jp/binary/libdwarf.spec http://shinh.skr.jp/binary/libdwarf-20051201-1.i386.rpm typedef struct TestDump_ { short s; int i; long l; size_t st; unsigned long long ll; char c; c
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
