yoku0825 @yoku0825 @con_mame ああ、やっぱりそうなりますよね。。こっちは息をするくらい当たり前のことだと思っていても向こうは違って、向こうが当たり前に思っていることも俺は知らなくて、あぁ…ってなります。。
![ORDER BY 狙いのキーの話](https://cdn-ak-scissors.b.st-hatena.com/image/square/be74440ad303f7898c3673ffad642708514a07e6/height=288;version=1;width=512/https%3A%2F%2Fs.tgstc.com%2Fogp3%2Faa423aafc1d5754f44a7039ebc00b5cd-1200x630.jpeg)
こんにちは、@acidlemon です。 ざっくりと書いたつもりなのに長編です。 本エントリでは、スコアがなかなか伸びなかった方々を主な対象として、実際に先週末実施した予選問題を解いていく方法を解説します。高スコアをたたき出した方々は参考までに「こんなやりかたでもここまでスコア伸びるんだなー」という感じで読んでください。 最初の方針は「派手なことをしない」「コンサバにやる」です。「とりあえず」という気持ちでmemcachedやRedis、もしくはvarnishやnginxでキャッシュし始めるとキャッシュの寿命のことを考え始めなければならず、疑心暗鬼になったりして難易度が上がります。まぁその辺は最終的には男気によって解決するものなのですが、その要素を排除したままできるだけスコアを上げてみましょう。 日曜夜よりアップされたみなさんの感想エントリなども拝見しており、やっぱオンメモリに置くのは速い
1つ前の記事「JavaScriptをいかに高速化するか、IE9、Firefoxの取り組み」では、IE9とFirefoxにおけるJavaScriptの高速化について紹介しましたが、そもそもJavaScriptの実行速度はなぜ遅いのでしょう? その理由について、Mozilla Japanテクニカルマーケティング担当の浅井智也氏が、スライド「Trace Monkey」でポイントをまとめています(このスライドはタイトルから分かるとおり、Firefoxの当時の新しいJavaScriptエンジン「Trace Monkey」を紹介するために1年以上前に作成されたスライドですが、1つ前の記事を見ると、ここで示された課題はいまも変わっていないようです)。 全67枚のスライドの20枚目から24枚目の5枚を以下に紹介します。 JavaScriptが遅い原因は、以下の4点にまとめられています。 インタープリタ型言
「ウェブオペレーションエンジニアはリリース前のソースコードのココを見る!」みたいな記事があればいいね — masahiro nagano (@kazeburo) November 20, 2012 ちょいと前にツイートしたこの件のまとめ。新規サービスのリリースや既存サービスに新しい機能が追加される際に、しばしばそのソースコードを確認しているのですが、僕がどんなところを見ているのかまとめてみました。 そのサービスへの導線とランディングページの確認 まず、そのサービスへの導線やランディングページを確認します。そしてその一番アクセスがあろうページ、一つか二つに確認対象を絞ります — masahiro nagano (@kazeburo) November 20, 2012 どんな素敵なサービスも、機能も適切な誘導がなければ使われる事はありません。また誘導次第では大量のアクセスが一度にサーバに対し
こんにちは、ISUCON というイベントのレギュレーションを考えたり環境の準備をやったりコード書いたりしてた tagomoris です。普段はライブドア開発本部のインフラサービス部というところで働いてます。 先日ISUCONは幸いにも大好評のうちに終了したのですが、へとへとになって疲れ切った状態で帰宅し、寝て起きてみると、公開しておいたソースコードをさっそく自分の手元で動かしている人がいました。説明とか何にもなかったのによくそこまで。どういうことなのと思わずにはいられません。 #isucon に参加してきました&isuconツールを試してみました - As a Futurist... また翌日にはTwitterでも続々と動かしてみた報告が見られ、エンジニアのみなさんのバイタリティには感服するばかりです。 ざいりょう で、せっかくだから本番と同じデータで同じように試せるようにしたいよね、とい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く