ToDo:
なにやら大変面白い話が。
http://d.hatena.ne.jp/IwamotoTakashi/20091006/p1
http://d.hatena.ne.jp/ku-ma-me/20091010/p1
http://akimoto.jp/blog/2009/10/08/bug-report-in-foreign-language/
個人的な感覚では、オリジナルの報告者の方も 最初に close した PHP の人も、 その後のいやこれは dup じゃないんだという主張も、 その後の直してくれるまでのやりとりもごく問題ないように見えるかなぁ。
なんか気になるとしても本当に細かい点で。
指摘されてる通り、 オリジナルの報告者が謙譲しすぎっていう点については、 これ要するにパッチには自信無いけどたぶんこんな感じでいいよね、 って言いたいってことなんだと思うんだけど、 まぁそいうのはよくあるからきちんとそう書いた方が 良かったかなぁというかんじはする。 これだとレポート自体に不穏な空気を出してしまうのはそうだし。 でも本当にこんなのは細かい点で。
あとは最初の php.net の人の応対だけど、 まぁどれと dup してるかくらいは言ってよ、 って感じではあるけど、 これもこの対応見るだけで判断すると、 そんなにひどい応対とは思えないなぁ。 仮にこのバグを reopen して、もう一度理由を示されず close されてたとしたら それはひどい人だと思うけど、 この程度だったらまぁ忙しいプロジェクトの バグ管理とか多少雑になっちゃうのはしょうがないと思う。
バグの数が50000とかになってるプロジェクトなんだから (10年やってるわけだけど単純計算で1日10個とかだよねえ…)、 多少ミスがあるかもしれないけど適当に バグの dup 判定とかをざっとやって、 それでお前それ違うヨ! って言われたら もうちょっとちゃんと判断する、みたいな 雑なスキームになっちゃうのはしょうがないように思う。
だからこの応対だけではこれはひどいとは思えないかなぁ。 懇切丁寧な方がそりゃいいんだけど。
でまぁ、エスパーじゃあるまいし実際そいう事情があるかは知らんので、 報告者の方がそのへんを察するべきだった! とかいう主張をする気も全くなくて、 絶望した! とか思っちゃうのもしょうがないと思う。 それでもちゃんといやこれ dup じゃない気がするんだ と言ってるのもすごくいいと思う。
そんなこんなで僕的にはごく普通の bug repot → fix の流れのひとつに見えたようにおもう。
ちょっと改善できたらいいかなぁと思ったのは はてぶとかしてる人で実際に PHP のそのバグを 困るものとわかってる人は、 バグに対して賛意を示してあげたりすると目立つからいいと思うんだよな。 できれば補足説明とかしてあげられるといいけど、 "+1 for this bug" とかだけでもいいように思う。
あと個人的には秋元さんの意見には 一般論としてはあまり同調できないなぁ。 そういう(すごく丁寧に説明する)やりかたも アリっちゃアリだとは思うんだけど、 個人個人のリソースは限られてるんだし、 適当に短いバグレポートをほってみて、 それだけで直してくれたらラッキーだし、 反応が無いようなら重要度に応じてあきらめてみたり ping してみたり、 伝わってない部分があればそこを細かく説明してみたり、 という感じで適当にやればいいんじゃないかなぁ。 伝えるのが難しそうなら日本語でブログ書いて応援求めるとかも すごくいいように思う。
例えば英語とか書きたくなければ、 there is a bug: <再現するコード>, expected: <hoge>, actual: <bug!>、 とかだけでもたぶん良いわけで。 実際 WebKit のバグとか見てる感じでは、 最悪再現する URL だけでも良くて、 できれば再現する最小の html なりなんなりにしてくれると良くて、 さらにそのまま test として使える程度にわかりやすい html だと (緑になるべきだけど赤くなるとかそういうやつ) なおよい感じかな。
直す側に回る時はそのバグの深刻度とかは 正直どうでもいい情報でしかなくて、 開発者側の priority 見積りは信用できないから 急いでなおして欲しい! と思うなら書く、 くらいでもまぁいいんじゃないかなぁ
そいう意味で秋元さんご自身のバグレポートの例それ自体は、 これはこれでこの事情ならこのくらいきちんと説明しないと ドコモのほげほげの事情とか知らんだろうし、 丁寧に説明しておられたのはそれはそれで適切な気がした。 普通に考えるとそんなよくわからんバグに priority あげられないからねえ。
(17:59)
というものがあるようだ。
http://tools.ietf.org/rfc/rfc1924.txt
Git がこれ使って binary diff を作ってるみたいなんだよね。 自分で書きたくないから素直に base64 使って欲しいなぁ…
(02:50)
import std.format;
import std.stdio;
import std.string;
void main() {
stdout.writeln(format("%c", 'a'));
}
ぎぎぎ %c が無いぞ… よくわからんけど今度パッチをほる
(01:41)
http://darwinawards.com/darwin/darwin2008-16.html
ブラジルにもいたらしい。 GPS持って出発したけどGPSの使い方がわからなかったらしい。
(18:50)
http://jibun.atmarkit.co.jp/ljibun01/rensai/leader/33/01.html
かっこいいなぁ。
Chrome もこっち系の仕事をやってる人が何人かいるんだけど、 まぁ彼らはすごいなぁと思う。ありがたい。
Yugui さんて同年代くらいなのか。 別に上という印象も下という印象もなかったのだけど。
(18:06)
CSS1 にテキストを capitalize させる text-transform:capitalize という、 python の str#title() 並にどうしようもなく存在価値が なさそうな物体があるのだけど、 そのブラウザごとの挙動が驚くほど違って面白かった。
http://spreadsheets.google.com/pub?key=tGCsFWV1bwyYanB9y4Ri9IQ&output=html
Firefox が一番まともそうな雰囲気に見えるかなぁ。 シングルクォートへの対応が大変興味深い。 個人的には Opera の挙動がわかりやすいので一番好みで、 これが唯一 CSS の test suite を通るはずで、 かつこんな機能どうせ誰も真剣に欲しがってないと思うので、 test suite 通せるという一点で Opera のでいいと思うんだけどね。
あとこのへんのあきらかに実現不可能な Correct output sample も面白かった。 One-to-One とか無理だろ! とか クリンゴン語 (tlh) とか入れるなよ! とか。
https://bug-3406-attachments.webkit.org/attachment.cgi?id=2381
どうでもいいけど Python の title() は
>>> "foo's".title() "Foo'S"
とかになるので最もどうでもいい。
(21:25)
やる気は一応あるけど過去のコード、 つまり2年前のコードが読めない。 よって CPU ロジックは一から作ろうと思うのだけど、 そうは言っても再利用したい部分はあるので…
if (ev.key.keysym.sym == SDLK_z) {
current_state -= (current_state & 1) * 4 - 2;
}
if (ev.key.keysym.sym == SDLK_x) {
current_state += (current_state & 1) * 4 - 2;
}
if (ev.key.keysym.sym == SDLK_c) {
current_state ^= 1;
}
この int の意味はなんだろう! c はどうもひっくり返してくれるようなので、 下位 1bit は parity というのかそういうもののようだ。
ああなるほど回転はその parity のせいで 方向が変わりうるのね… つまり 0-7 までぶんまわせば全状態が取れるようだ
(21:57)
http://d.hatena.ne.jp/kazuhooku/20090928/1254113043
基本的には正しいと思うけど、 http みたいに細かいヘッダがいくつかあって 後はどんとペイロードが入ってるようなプロトコルを前提にしてる感じなのかなぁ。 バックエンドとミドルエンド的な中継サーバとのやりとりとかで、 細々としたフィールドがあるようなプロトコルだと なかなかテキストではやりたくないような。
たとえば twitter の検索だったら、
[{ uid: 1234, timestamp: 1254330459, text: "なんとかなう", client_id: 3 },
{ uid: 2345, timestamp: 1254330451, text: "ほげほげなう", client_id: 2 },
...
]
とか、こういうのはあんまりテキストで送りたくはないような。
弊社はまぁなんでもかんでも protocol buffer に つめこむ習性があると思うんだけど、 まぁバイナリプロトコルも解析ツールとか 手軽にテキストで送信できるツールとかが そろってればそんなに使い勝手は悪くはない気がする。
一方ゴルフ場はどう考えてもテキストプロトコルであるべきであった…
(02:11)
http://d.hatena.ne.jp/kazuhooku/20090924/1253766558
こっちもそうだよねえと思いつつ読んだのを思い出した。
もうなんか全てのプロセスはたまに止めたいんだよな。 ブラウザとか1日に一回くらい夜中に再起動してて欲しい。 お手軽 Copying GC とか冗談で言ってるんだけど、 まぁ冗談じゃなく普通にアリなんじゃないかなぁ。
(03:05)
減ったけど増えた。
捨てられそうな TODO
(00:51)
twitter の Search に walkinput で飛べないのはなぜか… という課題があったので調べてみた。 要は textarea が 2 つあって、片方は DM 用で普段は隠れているからっぽい。
クソが…クソが…と思ったけど、とりあえず Alt+/ が accesskey で仕込まれてるので、それを覚えれば良いみたいだ…
しかし accesskey を表示する方法とか欲しいもんだね。 今度作るか。
(01:09)
_ social media marketing services [そのような意味&#..]
昔書いた regression tests を走らせて、
12 of 90 tests failed
まで。
今日困った点としては、 bash のかわりに dash 使うと exec の回数増えちゃった、 っていうのと、 あとは aplus-fsf が squeeze と sid にはあるっぽいのに lenny に入ってないとかかなぁ。
後は自力インストールしたものばっかなので結構難易度高いなあ…
(18:53)
とりあえず Chrome もうごいてるし、 extension も flash も IME も動いている。 感動的と言っていい。 さよなら Firefox と vimperator 。
問題は sevil も w3mimg も動いてないことだなー。 明らかに同源ぽくて、 Leopard で deprecated になっていた CGSCStringValue とかそのへんの API が消えたっぽい。 消えるのはいいとして回りの API が残ってる以上、 代替手段はあるのだろうけど、 探すのはちょいめんどいなー。
あとは glog がコンパイルできないらしいのも調べるべき。 それと SDL 。 あと中二病のアレ
(19:11)
ぼんやりとゴルフ場再建などをしてるうちに終わる…
感想したしじみを富士のふもとで買ったので しじみごはんを作って、 なんかフカヒレスープの缶詰めが実家からずいぶん前に来て 放置されているのを思い出したのでそれも作ってたべた。 深く考えずフカヒレスープをあんかけとしてごはんにかけたら うまかった。あんかけチャーハンのような。
このクソみたいな TODO の数的に もっと獅子奮迅のごとくひきこもりプログラミングができればよかったのだけどな
(19:29)
ゴルフ場の弱々しい sandbox の watch.so なのだけど、 これがコンパイルしなおすと全く正しくない動作をしている…
うーむこれはなぜ… あれむ root で動かしてるのが問題じゃないかというか root なのに古い watch.so は動いてるの? とりあえずユーザ作る。
あと git にあるのは SVN head じゃないぞ…
(20:19)
結局、
などと色々買った。
TODO はまた多いくなってきた感じが。
捨てられそうな TODO
(01:51)
| 前 | 2025年 7月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | ||
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
Before...
_ naruse [わたしもほっとくよりはrejectって感じかなぁ。 ruby でも仕様変更のパッチは高確率で放置じゃないかな。 後..]
_ shinh [あーなんかその手の contributor が知ってるとトクなプロジェクトごとの文化みたいなのはお互い難しいですよね..]
_ ku-ma-me [3 日くらい、とは最初ぼくも思いましたが、よく見てみると、報告があって 30 分で「重複すんな」といい、さらに 30..]
_ shinh [http://bugs.php.net/report.php に太字で If you feel this bug..]
_ ku-ma-me [おお。http://www.php.net/mailing-lists.php と http://bugs.php...]