[AWS][ELB]ELBがスケールアウトされないケース
ELBがスケールアウトされず、Latency低下に悩んでた原因がハッキリしたのでメモ。 状況 アドサービスの入り口部分で、 フロントをさばいているELBのLatencyが、 ピークタイムに不自然な動き、Latencyが1sec超えるなどの遅延。 （何故かMAX3秒以上は遅延しない。） 対応 memcachedへのアクセスをinternal ELB経由で行なっていた部分を IP直指定とした。 Latencyは 10ms前後で落ち着いた。 このことから、遅延原因はinternal ELBと断定。 ELBの動作 SA様に聞いた所、 ELBは、内部的にEC2を動かして動作させてるとのことなのだが、 そのインスタンスが一定条件を満たした際に、ELBのスケールアウトが行われる。 （スケールアップも有るのかな？） スケールアウト条件は、対象インスタンスの CPU Utilization、Network
*nixのプロセスまわりについて書いてたやつがついに書き終わった - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
プロセスさん最終回書いた。 最終回： https://gist.github.com/Shinpeim/5205353 目次： https://gist.github.com/Shinpeim/4736099 第一回を書き始めたときには、もっとさらっと書けるだろうと思ってたんだけど書いてみたらいろいろ書くべきことがあって、なんだかかなり辛い量の文章書いてしまった。最後のほうとかもう書くのがかなりしんどかったんだけど、プロセス周りの話はだいぶ網羅できたんじゃないかなって思う。 小出しに書いてる間、はげましのブクマとかはげましのスターとか付けてくれたひとがいたから書けたし、「おもしろい」って言ってくれたり「わかりやすい」って言ってくれたひとたち本当にありがとうございました。あなたがいなければプロセスさんは存在しなかった。 なんか噂によると Working with Unix Processes
async/await不要論
4. 昔話をします 初めて買ったPCのCPUは Duron 850MHz (2000年ごろ) ハイエンドCPUが、ちょうど1GHzを越えたあたり ◦ PentiumⅢ1GHzとか、Athlon 1.2HGzとか このころは、「2010年には20GHzのCPUを実現」とか言ってた ◦ 同じように、Hyper-Threadingやマルチコアの「サーバ用途での」重要性も言われ始めた Intelはこの頃デスクトップ向けCPUでクロック周波数を向上させ続けていた ◦ プログラマにとっては、「フリーランチの時代」 しかし、2003年にクロック周波数の向上ペースは落ちてしまった ◦ 増え続ける発熱に対処できなくなった ◦ 2013年3月現在、x86向けCPUでの最高クロック周波数は4.2GHz ◦ フリーランチ時代の終焉・・・？ 5. CPUはデュアルコアへ 2005年に、Pentium4の
デベロッパーツール - AWS での構築のための SDK とプログラミングツールキット
開発環境に統合した C ++ 固有の API と使い慣れたツールを使用して、アプリケーションを開発する
「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ
「アジャイルがダメだと思う7つの理由」という刺激的なタイトルのエントリを、先週木曜日、3月21日にグロースエクスパートナーズの鈴木雄介氏が公開してから、アジャイル開発に関する議論の波紋が広がっています。 おそらく、これだけさまざまなブログを通じてアジャイル開発の議論が活発化したことはこれまで国内ではなかったのではないでしょうか？ ここでは現時点での議論をまとめますが、興味のある方はぜひここを起点にそれぞれのエントリを読んでみていただきたいと思います。 発端は鈴木雄介氏（id:arclamp）のブログarclampにポストされた「アジャイルがダメだと思う7つの理由」というエントリ。以下がその7つの理由として挙げられたものです。 1.全体スケジュールにコミットできない 2.アーキテクチャ上の無駄が生じる 3.コーチって何だよ 4.変化ヲ抱擁スルために固定化している 5.実証主義的な説明に過ぎな
アジャイルがそんなにダメだと思わない7つの理由 - haradakiro's blog
鈴木雄介さんが、「アジャイルがダメだと思う7つの理由」というすごいブログを書いてくれたので、がんばって返答を書いてみる。どこかでディスカッションできるといいなぁ。 1. 全体スケジュールにコミットできない コミットメントって何だろう。コミットメントは約束なのか。約束であったら、破った場合のペナルティも受け入れるのか？受け入れたところでバッファが巨大になるだけではないのか？そして、そのバッファは見えないところで食い尽くされる。 全体を見えずに計画したところでうまくいくはずはない。アジャイルがタイムボックスで計画、実施を行うからといって、全体を計画しないわけではない。むしろ積極的にやるべきである。 全体を計画する上では、なるべく漏れがないように、実施可能なように最大限の努力をする。ただ、それに時間を掛けすぎるのは無駄だ。そして、神ならぬ人間が計画するのであるから、以下を認めなければならない。
アジャイルがダメだと思う7つの理由 - arclamp
1.全体スケジュールにコミットできない アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ
Niigata.LL で JSでTDDをどう実践しているのか をトークしました - .blog
Niigata.LL ATND NiigataLL by dictav ポータルサイト ポータルサイトの方を見てもらうとわかりますが、VBAとかPowerShellとかもあって面白かったし、飛び入りで来てトークしてくれた方もいて面白かったし、PHPを話す人が居なかったのはなにか陰謀があったんじゃねーのかとか妄想できるし、濃密で良かったですよ。 トークタイトル:「JS TDD(and test) with your language」 Webアプリを作っていると得意（メイン）の言語とは別に JavaScript に触れざるを得ないプログラマは多いんじゃない？ という観点で、非JSer対象にJSのTDD周りの話を。 ※ 余談ですが、Niigata.LL では 18名の方の参加がありましたが、主にJavaScriptを書いているというJSerは2名ほど。開催日現在で Node.js 使っている方
DOMイベントの基礎から深淵まで
DOMイベントの基礎から、細かい情報まで、最新のDOMイベントの仕様策定状況も含めて、解説しています。Read less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JavaScript上位言語の比較表 - Qiita
【HTTP2.0最新動向】SPDYからHTTP/2.0へ～HTTPbis WG Interim Meetingレポート