トップ «前の日記(2010-04-18) 最新 次の日記(2010-04-25)» 編集

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|

ToDo:


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)

お名前:
E-mail:
コメント:
人生、宇宙、すべての答え
本日のリンク元

2010年
4月
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
1.naruse(2014-05-24 05:33) 2.kosaki(2014-05-24 05:33) 3.shinh(2014-05-24 05:33)
search / home / index

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

shinichiro.hamaji _at_ gmail.com / shinichiro.h