client-side javascript - ✘╹◡╹✘
JavaScriptのすごく初歩的なことでよくわからないので整理する。よくわかってなくてすごい恥ずかしい感じがするけど書いたら誰か何か教えてくれそうだし書く。client-sideのJavaScriptは、未だあまりよく分からずにもやもやしながら適当に書いてる。もやもや感が説明したいけどなかなか説明しづらい。 例 こういうタブをJavaScriptを使って実装する例を考える。タブをクリックすると、そのタブに切り替わるというやつ。 HTML CSS JavaScript Pattern 1 深く考えずに素朴に実装すると、こういう感じになる。clickイベントに与える無名functionの中に全部詰め込む。こういう風に書いてるJSのコードはよく見る。こういうの大量に書くのはすごい簡単だけど大量にこういうのが書かれてたら読むの辛い感じがする。 懸念 例えばこれまでRubyでコードを書いていたとき
Google Chart で Imp と Click のグラフとかをうまいこと書く - tokuhirom's blog
たとえば広告システムがあるとして、Impression 数と Click 数をそれぞれ数字としてもってたとして、普通に Google Chart でグラフを書くと以下のようになります。click 数が imp 数にくらべて非常にちいさいので、このグラフは役にたちません。 が、Google Chart では targetAxisIndex というのがあるので、これをもちいて以下のように指定すれば OK でした。 options = { series: { 1: {targetAxisIndex: 1} } }; あたらしいグラフは以下のようになります。2012-10-16 が Imp のわりにすげー click 数のびててなにこれ!! っていうのがわかります。 以上のグラフは以下のようなコードで描画することができます。 <html> <head> <script type="text/jav
node.js と thread hog の話（３）
[前回までの話へのリンク] ・node.js と thread hog の話（１） ・node.js と thread hog の話（２） では、なぜ今頃になって HTTP Server の c10k 問題（もしくは、thread hog 問題）が顕在化したのだろう。 当時（９０年代の終わり頃）と比べて、もっとも大きく変わったのはCPUの性能である。クロック数は、数百MHzから数GHzへと一桁増えたし、マルチコア化もしている。CPU 性能だけ見れば、当時の数十倍の能力が出てしかるべきである。 しかし、実際の人生はそう簡単ではない。サーバーのパフォーマンスはCPU性能だけが決めるわけではないからだ。そこで、ボトルネックの一つとして注目されはじめたのが、thread の数なのである。 前回述べた様に、thread 一つあたり 2MB～8MB のスタック領域を仮想メモリ空間に確保しなければならな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
