大手Webサービスがクライアント側で発生したJavaScriptのエラーをどう収集しているのか まとめ - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
HTML5時代の「運営しやすいアーキテクチャ」の話
増井君と二人でPhotoShareというサービスを立ち上げてもう１５ヶ月になるが、いろいろと学んだことがある。その中でもつくづく思うのは、サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などなどである。 そんななかで強く感じるのは、「AJAXを見た目や使いやすさの面だけに利用するだけでなく、『運営しやすいサービス』を作るのに利用できないか」ということである。 私のイメージするアーキテクチャを図にするとこんな感じになる。 まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく（上の図で、CSS,
Javascript雑学：SetTimeoutについて知っておくべき事
昨日のベンチマーク・プログラムだが、MacやWindows上で走らせて60-70fps程度しか出ていない事に驚いた人も多いかも知れないのでひと言補足しておく。 あのベンチマーク・プログラムは１フレーム描画するごとにSetTimeout()を使って1msの遅延で関数updateFrameを呼び出し、実際に１秒間に何回呼び出されるかを測定している。スマート・フォン上でこのベンチマーク・プログラムを走らせると、フレームの描画の部分に30msとか40msとかが必要なので、その結果33fps、25fpsなどの測定結果が得られる。 ということは、Javascriptの実行速度が猛烈に早ければ1000fpsも可能なはずだが、どんなに高速なパソコンを使おうと、どんなに描画のロジックを単純化しようと、実測値が通常100fpsを超えることはないのをご存知だろうか。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
