twitter から:
okuji: 私が常日頃口を酸っぱくして言っていることに、commit logにはやったことのまとめを書くのは結構なことだが、それ以上に「なぜ」を書け!ってことだ。コードの説明はコードそのものやコメントにあるはずだから、logを見たくなるのはなぜそういうコードにしたかったのか、ってことだ
okuji: そういう変更というアクションに付随した説明をコード自体に入れるのは、そこにない古いコードを参照しなければならないので、難しい。だからそれをcommitに残せばよいのだし、そのためにVCSを使っているのだ
okuji: 今回よくわかったのは、rubyはあいかわらずだってことだった。悲しい。http://bit.ly/s7hEo
すみませんすみません orz とにかく何か書けばいい,という意識でした.気をつけよう.
メールを書く擬音はめるめる,では,会議をするのはなんだろう.
議事議事……違うか
個人的には,議論するのでギロギロはどうかと.
「ねむねむ」だろう常識的に考えて……
そんな会議は「いらいら」ですねぇ :-)
成果物ベースで仕事してると、たるい会議は時間単価を下げるだけなので、さっさと切り上げるか抜け出します。
そんな会議では「こそこそ」と内職して仕事を続けるとか.
ハッカーは常識を知らないなwww けんけんごうごう、かんかんがくがく、ま、擬音かどうかはあやしいけど
長いじゃないですか.
東京に戻ってきた。
出雲大社の復元模型、模型を初めて見てすごさがわかった。これは、本当に凄い。ファンタジー。見てみたい。
海外スピーカーにサインをもらった → http://www.atdot.net/fp_store/f.izqqpk/file.P1000166.JPG
紙漉体験というのをしたんだけど、それで漉いた紙に。
Evan Phoenix のサインは読めない。
http://d.hatena.ne.jp/wasisan/20090905
難しいことはよくわからないのですが,Gauche は凄いですよねぇ.
先日の「研究者はRubyが嫌い」というのに通じるところはあるんですよね,これ.まぁ,立脚点が違うというか,なんというか.ちなみに,見たくないものは放っておく,という選択肢はないんだろうか....
彼の憎むRubyの「妥協」とか「異質」とか「媚び」とか「いい加減」って、現実とのすり合わせの結果に選択したもののように見えるんですよね。つまるところ、彼はRubyを通して汚い現実を嫌っているように見えるんだけれど・・・。放っておかないのはそれに気付いてるからなんじゃないですかね。ある種我々がPHPを無視できないのと同じで。
http://d.hatena.ne.jp/takkaw/20090815 を見たので,#size を速くした.
自分はsize派ですので速くなって嬉しいです。どうも、ありがとうございました。
で,見直してたらデグレードが再現しない.なんじゃこれ.
遅かったのは,--with-valgrind してたからかも.と,思ったけど違うなぁ.なんだこれ.
へろへろ.
タスクがぼろぼろと落ちていく orz
非常にまずい.なんとかならないか.基本,タスクはメールで来るのだから,Tb と連携させてタスク管理できるといいと思うんだが.
検索フォルダだと,検索対象フォルダを決めないといけないのが,個人的には良くない.今数えたら,ML 系フォルダだけでも258個あった.こんなの全部登録したくない.全部のフォルダ対象の検索フォルダって作れないのかなぁ.ただ,メモを残してくれればいいんだけど.
なんか,もう駄目だなぁ,と思う最近.少し前までは,Ruby の開発やら何やらに,少なからず貢献していたと思うんだが,最近はダメダメ.自分のバグの修正やら何やらもできず,ストッパーになってる.新機能追加についてもそう.うー.
オフラインの話でも,例えば以下のようなことはやっていた.
るびまとかイベントとかは,幸いにして角谷さんや島田さんが積極的にやってくれているのでいいのだけれど,開発系のイベントに心を砕く余裕がなくなってしまっている.IRCやメールなんかで順調なら,それでもいいのだろうけど.
色々思うところはあるなぁ.
発表のために,データを取り直してたら,なんかえらい trunk が遅くなってる.1.8 よりもメソッド呼び出しが遅いってありえないだろ!
デグレードだよなぁ,これ.
9月になりましたねえ.
acm portal で調べた限り,
うーむ,gcc キモイ.
struct empty{ }; struct empty2{ struct empty empty; }; main(){ int a; struct empty e; int b; struct empty eary[10]; int c; int i; for (i=0; i<10; i++) { printf("&eary[%d]: %p\n", i, &eary[i]); } printf("%d, %d, %p, %p, %p\n", sizeof(struct empty), sizeof(struct empty2), &e, &a, &b); printf("sizeof(eary): %d\n", sizeof(eary)); printf("%p\n", &c); }
Linuxでは論文っぽいcommit logを推奨されてるので、僕はいつも ・現在の仕様の概略 ・問題点の指摘 ・どうやって直すか の3点を書くようにしています。 普通、後からチェックしたいのは意図した変更なのかサイドエフェクトで入った変更かなので、これで大体回っています。 説明がメンドイときは、テストプログラムを貼り付けて、「ほら、うごかないだろ」とか書いちゃう時もありますが :-)