はじめてのにき

自分が誉められた時は少し謙虚に受け止める。特に Cool, but ... とかはよく考える
自分が相手の仕事を誉める時は大袈裟気味に
相手の仕事をけなす時は Overall looks good, but this patch could be better if you consider something something ... みたいな

って感じでやるのを心がけると、親しくない相手でもそれなりにうまくコミュニケーションが回るかなぁと思う。あとは同じ人の他の事象への反応とかと比較するといいかなぁと。

まぁこんなものは処世術というかなんというかなんかでしかないので、当然相手との間柄によって変わることではあると思う。

でもそもそもコミュニティによってそのへんの文化はだいぶ違うよねたぶん。 kosaki さんの記述とか見ると linux だとだいぶはっきりとけなすみたいだし。

他の僕の知ってる範囲だと(つってもチラ見しただけのも多いので眉唾)

Chrome: 基本的におだやか。ただ内部で先に議論してる場合があるので外部の人にはちょい冷たい印象になってることがあると思う。あとまぁ社内もそうだけど、当然キツい人もいる。
WebKit: たまに激しめの議論になるし、基本的にちょっと殺伐としてる気がする、がまぁ基本的には丁寧。ちょっと素気ない感じの表現が多いか。
Ruby: ruby-core はあんま見ないけど、なんか素気なく見えるかなぁ。単に長い英語書くのがめんどい日本の人が多いだけなんだろうけど。
D: なんか孤高の Walter たんと割とちゃらんぽらん(良く言えばフレンドリー)な仲間達、というイメージ(だった。今は知らない)
Boost: 固い感じ(だった。今は知らない)。標準化委員会とかにいそうななにか(いや実際いるんだろうけど)
Io: わりと上品。大将が丁寧な感じだし。最近はそもそも流量少ない。
codegolf: とてもフレンドリーな感じでみんないい人だったように思う。まぁ仕事じゃなくて趣味だから利害関係ないしね。
GCC: 丁寧だけどフレンドリーという印象じゃないかなーという感じだけどよく知らない。よく知らんけど、たぶん仕事でやってる年喰った落ちついた人たち、ってイメージ。
TCC: 大将 (Fabrice さんじゃないよ) すらたぶん仕事じゃないと思うんだけど GCC に似た印象。ちょっと素気ないけど丁寧的な。
SDL: 普通に感じのいい感じだったと思うけどなんかあまり印象ないな…

つーかたまにリンクはられてて見る LKML 程度に口が悪いコミュニティは LKML と glibc の一名しか知らん気がする。

(22:56)

本日のツッコミ(全4件) [ツッコミを入れる]

_ kosaki [えー、LKMLって口が悪い部類だったの。全然知らなかった勉強になります。じゃあ、LKMLのノリでruby-cor..]

_ shinh [まぁそのへんはそいう人だって認識されてれば問題ない気もしますし実際はほとんど問題にはならない気がします。でもまぁなん..]

_ kosaki [Googleはなんというか世間知らずなのが損をしている感じ。世の中の一般のユースケースを知らないのでregressi..]

_ naruse [「素っ気ない」ってのは多分英語ネイティブでない人の割合が大きいって意味なのかなぁ。 IETFとかW3Cとかもシンプル..]

2010-04-25

_ はすける

pi8027 さんとかにいろいろ教えてもらって僕のはすけるの認識は色々間違えまくってるということがわかった。

でまぁ Haskell で標準入力を全て読み込んで、しかるのちに Hello, world! とでも出力してください、という問題がむつかしいという話を聞いた。

http://twitter.com/pi8027/status/12763914373

いやーなにやらむつかしそうですねーはすけるはすごいなー

とりあえずダメな方針での解をいくつか書いてみた。

main=interact(\s->take(14+length s)"Hello, world!\n")
main=interact$flip take"Hello, world!\n".(14+).length
main=interact(\s->"H"!!(0*length s):"ello, world!\n")

なんか全部同じサイズになる上に僕のはすける力ではこの程度が限界無念

(00:09)

_ seq

http://twitter.com/tanakh/status/12780733954

そうか単に length の結果を seq してやればいいのかぁ。

単に seq が何かよくわかってなかったというのが正直なところです

(11:13)

_ 対戦勝負

http://niha28.sakura.ne.jp/b/log/146

またも面白そうだなぁ。

3時間でこのルールはたしかに結構大変そう。

ガイスター100本勝負とかくらいがちょうどいいか。

(11:14)

[ツッコミを入れる]

2010-04-21

_ twitter

http://www.atmarkit.co.jp/news/201004/19/twitter.html

なんか意外と普通だなぁ。

twitter って planet wide にはなってるのかな。キャッシュはそこらに適当にあるけどデータ自体はアメリカだけーというのを予想。

http://q.hatena.ne.jp/1256635527

このへんを見るに

fan out されたポストはリングバッファ的な空間に
- これは最近のつぶやき数*フォロワー数な感じのオーダーで大きくなるのでユーザごとの空間は狭め
- ここが TL のページ数の限界は 40 ってのを決めてる感じかなぁ
リングバッファの量越えると時系列のパーティションに切られた空間を見ていく
- こっちもどっかの時点で捨てられて行ってる
- ここで一人のつぶやきは 3200 残す感じで
- つーことはこっちは TL とかには使わないってことかね
データは元々あったシンプルなつぶやきIDをキーかつパーティションに使ってる DB に残ってるので permalink は残る

とかかなー

(08:40)

_ ↑

あ、普通ってのは fan out あたりの話を読んだ感想。時系列のパーティションとかはなるほどなーと思った。

ユーザごとにパーティション切ってるとしてこう一緒の TL によく出てくるソーシャルグラフの距離が近い人は同じパーティションに行きやすいかっこいい分散データ構造があって…とか妄想したけど fan out 的なことしていいならそんなことする必要ないなーと

(08:46)

_ 並列処理

なんか会社入った時に、ビルドとかデータ生成とかの待ち時間とか結構長いとかいう文脈で、仕事の方を並列にするといいとか聞いて感心して、実際3並列くらいまでは結構やれるような感じがしてる気がする。

つまりたぶんシングルコアで HT が入ってて、後は IO 待ちとかあるから make -j は見えてる CPU の数 + 1 くらいにするから… とかいう感じで 3 並列くらいなんだろうか。

で問題はちょっと最近 3 じゃ効かない感じがしていて、どうにも頭がぼんやりしてる日の作業効率が悪い気がする。

今日はそれなりによかったのでメモっておこう

(22:31)

_ メモ

flexbox がネストしてる件 (1)

最初は double-layout から来る double-repaint が腐ってる問題と同じような話かなーと思ったけど違うか。

異常

layer at (0,0) size 785x600
  RenderBlock {HTML} at (0,0) size 785x600
    RenderFlexibleBox {BODY} at (0,0) size 785x600
      RenderFlexibleBox {DIV} at (0,0) size 785x600
layer at (0,0) size 785x1620 scrollWidth 770
  RenderBlock {DIV} at (0,0) size 785x1620
    RenderText {#text} at (0,0) size 752x1620

正常

layer at (0,0) size 785x1620
  RenderBlock {HTML} at (0,0) size 785x600
    RenderBody {BODY} at (0,0) size 785x600
      RenderBlock {DIV} at (0,0) size 785x1620
layer at (0,0) size 785x1620
  RenderBlock {DIV} at (0,0) size 785x1620
    RenderText {#text} at (0,0) size 776x1620

つまり外側の DIV が flexbox なので body にあわせて縮んでしまっている。

つか 2 重じゃなくてもこれ起きたりしないかなーと思ったけどやっぱ 2 つ必要か。修正はこれどうなるんだろうね

yen sign

とりあえず一番問題なコピペは land

gtk の test failure は修正した。単に gtk が悪い

chromium-win は謎。 transform でおかしくなってるあたり明らかに僕が悪そうだけど、うーん。あ、 capitalize や変更が起きないケースでも試してみた方がよさげ (0)

あとは

- font based transcoding (3)
- for all japanese encodings (2)
- find (4)

あたり

<button> の default padding (2)

修正は一瞬だけど議論が必要なので早く考えた方がいい

個人的には修正したくない、が

するとしたら -webkit-focus-inner もやる必要があるんだろうなあ…

setPrinting

待ち

png の方を調整するくらいなら今でもできるが (2)

margin rendering (2)

実装は大変そうだけど、考えるのはとりあえず早めにやれると良い

new-run-webkit-tests (2)

せっかくいじったんだからテスト書くといい

calc (5)

絶賛放置されている

glog (2)

絶賛放置されている

プライオリティつけてみたが (2) ばっかでどうしようもない。 (2) くらいは GW までとかに終わってるといいんだけど

(22:49)

[ツッコミを入れる]

2010-04-18

_ てすと

てすと

(02:47)

_ leaks

ひさしぶりに ruby を rmemcheck にかけてみた… 対象は test/ruby で。

これは昔リークゼロにできてたようなそうでもなかったような。もはや記憶になくて、記憶にないのは良くないのでとりあえずここに記録を残して置いてみよう。

http://shinh.skr.jp/t/leaks.txt

特に何もしないプログラムでも Init_VM と Init_sym でリークが検知されるけど、まぁこれは問題ないんじゃないかな。前者は INSTRUCTION_NAMES とかで後者は register_symid とか。なんかでもこれ leaks.txt には書いてないな謎。

ていうか発生個所が単体で走らせると結構 leaks.txt と違ったりして謎。

とりあえず test_m17n_comb.rb は何かがおかしそうだ。

==19285== 39,982 (32,480 direct, 7,502 indirect) bytes in 70 blocks are definitely lost in loss record 63 of 68
==19285== Ruby /usr/local/lib/ruby/1.9.1/minitest/unit.rb:176
==19285==    at 0x4C255D3: malloc (mc_replace_strmem.c:1127)
==19285==    by 0x49737D: onig_new (regcomp.c:5600)
==19285==    by 0x489D4C: rb_reg_prepare_re (re.c:1259)
==19285==    by 0x489F4F: T.591 (re.c:1318)
==19285==    by 0x48A724: rb_reg_match (re.c:2703)
==19285==    by 0x512496: vm_call_method (vm_insnhelper.c:377)
==19285==    by 0x513B85: vm_exec_core (insns.def:1002)
==19285==    by 0x5183F8: vm_exec (vm.c:1133)
==19285==    by 0x5199B5: rb_yield (vm.c:586)
==19285==    by 0x52A954: rb_ary_each (array.c:1413)
==19285==    by 0x512496: vm_call_method (vm_insnhelper.c:377)
==19285==    by 0x513B85: vm_exec_core (insns.def:1002)

これは re.c の

   if (tmpreg) {
       if (RREGEXP(re)->usecnt) {
           onig_free(reg);
       }
       else {
           onig_free(RREGEXP(re)->ptr);
           RREGEXP(re)->ptr = reg;
       }
   }

を適当に

   if (tmpreg) {
       onig_free(reg);
   }

とかにしたら消えた気がする。しかし RREGEXP(re)->ptr はそもそも解放されてないような気がするのが謎で謎。

とりあえず最小テストケース

d = "foobar"
d.force_encoding("EUC-JP")
/./ =~ d

というあたりで飽きた

(03:06)

本日のツッコミ(全2件) [ツッコミを入れる]

_ naruse [gc.cの以下で解放されてませんか case T_REGEXP: if (RANY(ob..]

_ shinh [ああそこなんですね。なんか僕の記憶が確かなら tmpreg なら必ず onig_free するようにいじった場合も、..]

2010-04-17

_ 日本なう

なんか今回はビジネスクラスというのに乗ってみた。実際サービスはいいと思う…というか 10万単位の金払ってるんだからこれくらい全員にやってもいいんじゃねーとか思った。

僕の感覚では 20 万程度という差額の価値はどこにも無くて、そうなってくると会社に払わせるとしても貧乏症的にはちょっと微妙な感じではあるなーという感じだった。

帰りになんか火山がどうこうでどっかの線が止まってるらしいとか聞いたんだけど、実際 kmizu さんが被害にあっていた… がんばってください

http://twitter.com/kmizu/status/12284574428

今回のメインの出張理由は webkit contributor meeting とかいうのに行くことだったのだけど、まぁそれについてはまたなんか書いてもいい気もする… けど普段から webkit な感じな人でもないと無価値な感じの話な気がする。 JS engine くらいかなぁ。

_ screen

http://niha28.blogspot.com/2010/04/screen.html

みたかんじ screen-devel でいいんじゃないでしょうかと思いました。

http://lists.gnu.org/archive/html/screen-devel/2010-04/threads.html

GNU ってある程度以上長いパッチは書面送る必要あるらしいけど今でもそういうのあるのかな

_ amazon.com

http://www.amazon.com/gp/product/B00342PJ5M/

が欲しいなーと思ったけど海外発送できないみたいだ。

向こうにいる間に買っときゃ良かったか。

日本で売ってるものに比べて

4セル=>6セル
英語配列
Windows 7 professional
RAM 2GB=>3GB

というメリットがあるみたいだ

_ gc_book_tkb

面白そうなのがあったみたいだ。

http://atnd.org/events/3616

次は日本で!!

_ URLバー

http://code.google.com/p/chromium/issues/detail?id=41467

楽しいことになってるみたいだ。

たぶん http:// が無くなってすごくうれしいという人はいないだろうし、無くなってむかついてる人ばかりがこのバグを見つけるわけで、となるとわざわざ味方してくれる人とかいなくて大変そうだなー

RFC 3986 に違反してると言ってる人は URLバーに日本語ある場合に %-encode されてない文字列が出てるのもダメなのかなぁ。

X のコピーはたしかにこれ問題だな。まぁすぐに直せるだろうけど

本日のツッコミ(全2件) [ツッコミを入れる]

_ rui [買っときましょうかそれ。]

_ shinh [ありがとうございます。でもあきらかに輸送が手間なのでいいです。]

全てリンクフリーです。コード片は自由に使用していただいて構いません。その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。なにかあれば下記メールアドレスへ。


		2024年 10月
日	月	火	水	木	金	土
		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