• 海外のJavaScript情報を見つけよう
• 世界のJavaScript情報を読もう
• 今からRSS購読すべきタグと検索結果
• ブラウザの最新情報を知るために、Web開発者が読んでおくべきブログ
• HOW TO LEARN (これだけ記事じゃないですが)

世界のJavaScriptを読もう @ 2012を発表していた時、RSS購読フローの部分がなぜか受けが良かったようなので、簡単な補足を書いておきます。

自分はRSSリーダを多用しているので、何でもRSSにしてとりあえずRSSリーダーに流れてくるような状況を作っています。
Webサイトを見ていて、Read It Latorなどで後で読むことにしても結局読むのを忘れてしまうことがあるため、Read It Latorに登録したリストがRSSとしてRSSリーダーに流れてくるといった感じです。

Pinboardやはてなブックマークやソーシャルニュースサイト等もRSSで購読していると、同じ記事を扱ったものが何度もRSSに出てきます。
これは今からRSS購読すべきタグと検索結果でLDRの読み方にでも書いていましたが、SBMなどは量が多くなってしまうので、全て目を通そうとすると気疲れします。
そのため、SBMや検索結果等のRSSは高めのレートにして心理的に飛ばしやすい(LDRでいうSキーを押す)状態にしています。

なんで検索結果のRSSは★4にしてるかというと、検索結果RSSで出てくるサイトは★3のサイトと被ったりすることがあるので、
★4で飛ばしても★3で出てくるからまあいいっかと適当な感じで読める安心感が生まれます。

今からRSS購読すべきタグと検索結果 | Web scratch

ここから、発表してたときにウケてた部分ですが、RSSリーダで読んでいるときに少しでも気になった記事は
とりあえずTwitterへ投稿しています。(Post Now browsing to TwitterがLDRから直接投稿できるようにしているのもその辺の関係)
一応軽くは目を通してからTwitterへ投稿していますが、専門的な記事や英語の記事など一度みるだけじゃ理解が出来なかったり、判断が難しい記事も多いと思います。

そういう時にTwitterのフォロワーから反応があると理解しやすかったりします。
またFavやRTがあったものが流れてくるようにRSSを購読しておけば、重要な記事 (少なくてもフォロワーが興味を持った記事)が再度RSSとして流れてくるようになります。

こういう感じで、重要な記事は何度もRSSとして流れるようにして、読み忘れを減らしたり & 心理的に軽い気持ちでフィードを読み飛ばしても大丈夫なように意識しています。
他の人の力も借りて手を抜きつつ、人があまり見ないようなところもチェックするようにして、いろいろな情報を共有できればいいかなと思います。

どういう所などをみているかについてはオフライン勉強会でJSer.info一周年について発表してきた | JSer.infoのスライドの方にもまとめたのでそちらを見てください。

• オフライン勉強会でJSer.info一周年について発表してきた | JSer.info

「JavaScriptで大規模ゲーム開発」渋川

ソーシャルゲームの定義

• ユーザー間で非同期のやり取りが発生する

ngCore

• マルチプラットフォーム
  • 同一ソースでAndroidとiOSに対応
  • テスト環境はFlashにも対応

ゲームの構成

• ngCore上にゲームロジック/JavaScript
• サーバ/APach+FCGI上に認証とか結果の書き込みをMobageサーバに

役割分担

• ngCoreのクライアント
  • アクションシーン
  • サーバ側で作ったデータの再生
• ゲームサーバ
  • パラメーター保持、変化
  • アイテム管理
  • ミッションのスロットの目の決定など
  • ずる防止をするためサーバ側でロジックがある

ngCoreの開発サイクル

• node.jsで書かれたビルドサーバでビルドを行う。
  • ファイルの結合とか

コード

• CJSライクなモジュール
• クラスを作るsubclass関数
• ゲームはmain関数から始まる
• Core.UpdateEmitter でゲームループを回す

ゲームの基本構成

• シンプルなクラス群
  • Sceneクラスを継承してシームを作っていく
  • Sceneを遷移してゲームの遷移が行われる
• サーバ側からjsonのジョブスタックを受け取る
  • ミッション結果なども配列で返ってくる
  • 知らないジョブが来たら無視が基本方針
  • クライアントは順番に再生していくだけ
  • 新しいミッションも簡単に追加できる
• サーバエラーがおきたらホーム画面に強制的に戻る

DnLig/ngGo

• DnLib
  • ゲーム開発の共通ライブラリ
• ngGo

開発拠点

• サンフランシスコ
• 日本

• パキスタン

• SKypeチャットが主なインフラ

• git
  • git flow
• ドキュメントSphinx

ngGo/ngBuilder

• – データ駆動で行えるように
• - パラメーターチューニングのしやすさ

デバッグとテスト

• デバッグメニュー
  • サーバにデバッグ用画面がある
• Jasmineを使ってる

今後のngCore

• 3D対応、HTML5対応

まとめ

JavaScriptベースで

オフラインWebアプリケーションの作り方 (白石)

Google Gearsを使ってオフラインアプリケーションを作ったことがある。

オフラインWebアプリケーション

Google Gears

• Google Gears終了 –> HTML5へ以降を推奨
  • HTML5を中心にするようになった

オフラインでも読めるアプリの作り方

• それほど実装は難しくない
• アプリケーションキャッシュを利用すればいい

アプリケーションキャッシュとは

• 静的なリソースをキャッシュすることができる機能
• ローカルキャッシュの利点
• IE以外のブラウザでは実装されてる

キャッシュマニフェスト

• リソースのリストを作成する
• Titanium Mobileのリファレンスはローカルキャッシュされてる

アプリケーションキャッシュのJavaScript API

• window.applicationCacheにJavaScriptから操作できるアプリケーションキャッシュAPIがある。

アプリケーションキャッシュを利用する上での注意点

• キャッシュマニフェストを更新しないとリロードで反映しない
• キャッシュ容量が限られている
  • モバイルとかだと10MBぐらい

オフラインでも書けるアプリの作り方

• 割りと面倒なもの
• デスクトップアプリとやりたい事はあんまり変わらない

オフラインWebアプリを作るポイント

• 基本はリッチクライアント+同期機能

利用できるローカルストレージ

• Web Storage
• Web SQL Database
• Indexed Database API
• File API
  • ドメインごとに仮想的な空間
  • セキュリティ的なものがあるため

双方向同期

かなり難しく面倒くさい – フェールセーフ – 更新の衝突 – 同期のタイミング – ネットワーク状態、データの状態管理 – ローカルDBのスキーマ管理/サーバのスキーマと2つできてしまう – ローカルDBのクオータ(5MBぐらい)

- 容量の限界がきたときにどうするか

まとめ

• オフラインアプリケーションといっても読む/書くの2つがある
• 書く/同期的なアプリケーションはかなり面倒臭い
  • 割り切ったほうがいい

スケールするUIについて – @monjudoh

Objective-Cで非同期処理のチェーンライブラリとか

要素数

ループの中でbind/unbindしてたので大量に追加されたときに重たかったのでliveメソッドに変更 bindはここの要素に付けるから、要素が多いと死ぬ。delegateとかliveはその枠の方にイベント一個張るだけだから軽くてすむ。

D&D

• ユーザが触れる範囲だけにイベントを付ける
• D&Dは複数のイベントから成り立つので複雑(down->move-up)

要素の生成

• UITableView
  • 表示範囲+ぐらいのみを描画してる
  • 再利用してる

JavaScriptのテスト事情 – @os0x

• JavaScriptのテスト
  • まだまだ未成熟
• 二種類
  • JavaScriptのテスト
    • JavaScriptだけなので比較的わかりやすい
  • JavaScriptを含めたテスト
    • UIとかも含むインテグレーションテスト

インテグレーションテスト

• インテグレーションテストは書くのが大変
• 動いてあることが保証できるので重要
  • 後から追加修正とかも

インテグレーションテストの定番 – Selenium

• インテグレーションテストは遅い

テスト実行環境

• カピバラさん + Webkit

QUnit,Jasmine

• Jasmineの方がアプリケーションテストは向いてる

jasmine-headless-webkit

• jasmine のspecをCUI環境で実行できる

Titanium Mobile – Masui Yuichiro

• ココログ
• liblis
• AKB
• サイボウズLiveの
• MobSnap

Titanium Mobile

• JavaScriptだけでアプリを作成できる
• Titanium Mobile のモジュール売買できる
  • mobile market place

モバイルのUX

• それぞれのプラットフォームに合わせた形に変換する
• それぞれに合わせたUIはUXに
• タブバーの位置がAndroid/iPhoneで逆になったり

飯食う

• 追加モジュールとサポートのみが有料
• 認定トレーニング

感想

• ちょっと落ち着きがなかった気がするの
• あまり掘り下げた感じにはならなかったのは少しもったいない気がした。

メモ環境

• Mou

イベントのページ: Mozilla 勉強会＠東京 6th
Twitterのまとめ: Mozilla 勉強会＠東京 6th – Togetter

• 14:30 – 15:00: 開場、発表者準備

• 15:00 – 15:10: Opening

自己紹介の流れ。

• コマンドの補完

Inspector

• 次世代のセキュリティポリシー
  • XSSの攻撃防止
• コンテンツ種別で読み込み制御
  • 画像やCSSやJSなども制御できるようにする
• Webkitではほぼ開発されてる

• デフォルトセキュリティポリシーがいろいろ強化される
• CSPの使い方
  • X-Content-Security-PolicyのHTTPレスポンスヘッダを送信
  • HTMLのメタタグは書き換えできたりするものだからヘッダーで
  • Apache でCSPの設定
• CSP対応に移行する
  • JS,CSSは外部ファイルに
  • evalを使わない
  • ポリシー違反レポートでどこがおかしいのかも確認できる
    • ヘッダーでレポートを報告するURLを指定してログを残せる
  • CSPブックマークレットもある

HTTP Strict Transport Security

• Do-Not-Trackヘッダ
  • ブラウザ側でサイトに通知する
  • IE,Safariも対応
  • Chromeだけ非対応
• 受け取ったらユーザー追跡をしない

• ALT
• back to owner tab
• Fox Splitter

restartlessのコードリーディング

• アドオン SDK を利用した初めてのアドオン開発– by knagato
  
  • 初めてアドオン開発する人が対象
  • SDKを使ったアドオン開発を特徴
    • HTMLやJavaScriptなどが中心で、XULやXPCOMなどMozilla特有の機能を使わなくても開発できる
  • 開発環境の種類
    • Add-on BuilderをWeb上での開発
      • 再起動不要なのでその場で試せる
    • Addon SDKを使った開発
      • コマンドラインベース
  • Add-on SDKのチュートリアル
• Thunderbirdアドオンによるワークフロー開発について– by Nakashima
  
  • 提案するツール
    • 自分自身でのプロセス改善が可能
    • やり取りの簡略化ができる
  • http://www.p2pwf.com/ に仕様の詳細
• Forking Secure Login – by saneyuki_s
  
  • Secure Loginアドオンのフォークの話
    • 現在はメンテナンスアップデートのみになってる
    • 全面改装してる
  • 一部機能の省略
  • レガシーコードの除去
  • doorhanger対応
    • Firefoxに入ってるSSLのポップアップするやつ
• jQueryで破棄されたrequestAnimationFrameとJSでのアニメーション実装で注意すること – by kyo_ago
  
  • requestAnimationFrame
    • setIntervalの問題点としてアニメーション向けではない
  • jQuery 1.6から削除された
    • setIntervalとrequestAnimationFrameが衝突してキューがたまる
    • タブがバックグランドにあるときの挙動
• ES.next WeakMap– by mooz (@stillpedant)
  
  • WeakMap = 連想配列
  • Firefox6から利用可能
  • {}やObject()と比較して
    • keyにオブジェクトが指定可能
      • ハッシュはkeyに文字列しか指定できない(toStringされてる)
      • WeakMapはkeyにオブジェクトが指定可能
        • オブエジェクトしか指定できない
        • プリミティブ値はエラー
      • オブジェクトの外部拡張
        • DOMノードに独自プロパティは危険
        • ES5ではオブジェクトの拡張がfreezeできる
        • オブジェクト自体は拡張しないで、外部に付加情報を持つ
        • WeakMapを利用する
          • キーとして外部情報をもたせる
    • keyに指定されたオブジェクトを弱く参照
      • CGにたいして
• Firefox4以降のE4X– by teramako
  • ワイルドカード
    • *が指定子に使える
  • 属性アクセス
    • @が使える
  • Firefox3.6までは上記のものがE4X以外でも使えた
    • Firefox4以降は禁止された
    • ざんねんでしたね

翻訳許可のメールをわずか15分で返してくれた著者のJan Odvarkoさんに感謝を。
Thnak you, Jan Odvarko.

原文: Software is hard | Page load analysis using Firebug

ページ読み込みパフォーマンスはWeb開発者にとって重要なトピックです。
各ページロードの例において、FirebugのNet panelから得たデータをどのように解析するかを見ていきます。

このテストにおける例はFirefox 3.6 + Firebug 1.5 + NetExport 0.7においてのNet Panelの結果をNetExportによりHAR形式で出力したものをオンラインで表示しています。
(HAR形式はChromeのWeb Inspectorからも出力できます。)

• HTTP Archive Viewer 2.0.10(オンラインビューアー)

Example 1: Simple Page Load

ここでは2つのリクエストが表示されています。
1つめのリクエストではページは16msで取得できていて、load event (赤いライン)は58msで発生している事がわかります。ログ上にマウスオーバーさせると詳細な表示がされます。

• 青の縦線であるDOM Loaded はDOMContentLoaded event
• 赤の縦線であるPage Loaded はLoad event
• 灰色のReceiving がページの取得にかかった時間

同じように2つ目のリクエストを見てみると、5msでXHRが実行されています。
そして合計経過時間は408msであることもわかります。

2つ目のリクエスト(XHR)上でもマウスオーバーで詳細な情報が表示されています。
こちらでもload event を表していますが、こちらはXHRのリクエストからの相対値が表示されています。XHRが発生(Started)したのは403msなので 403 – 357 = 58msでload event が発生したことがわかります。(load eventはページの取得を見た方がわかりやすいからこう見る必要はない気がするけど)

Example 2: Connection Limit

各ブラウザは一つのページをダウンロードするのに同時接続制限あります。もし、同時接続の制限に達したとき、他のリソースは接続してるリソースが解放されるまでブラウザ内部のキューで待機させられます。
次の2つのページログを見ると、同時接続制限数の違いで8つの画像をロードするのにどれぐらいの違いがでるかがわかります。

#1 Cuzillion (同時接続制限 == 6)

• Firefox 3.6の同時接続制限のデフォルト値は6で、最初の6つの画像をダウンロード開始した時点でドキュメントは利用可能(DOMContentLoaded event が発生する)
• 他の2つの画像はコネクションが空くまで待っている(light-brown 色の部分がblocking部分)
• 他の2つの画像がダウンロードされたときは緑色のconnectionフェーズ無いのは、最初の6つの画像をダウンロードに使用したconnectionを再利用しているためです。

#2 Cuzillion (同時接続制限 == 2)

このテストだと、各画像ごとに2～3秒の時間がかかり、合計経過時間やload eventが発生時間に#1の2倍弱近くかかっていることがわかります。
同時接続制限が2なのはIE7以下のものやモバイル向けのブラウザなどがあります。
各ブラウザの同時接続数はHome – Browserscopeを見るといいでしょう。
Firefoxではabout:configのnetwork.http.max-persistent-connections-per-serverの設定から変更可能です。

同じように#2のポップアップされる詳細のログを見てみると、Blocking(light-brown 色)はページを取得(DOM Loaded)した時から4.63s待たされていて、リソースの取得は2.22sかかり、6.85sで完了している事がわかります。

Example 3: Pipelining

#2と同じページを使い、ブラウザのパイプライン処理がONとなっている場合を見てみる。

Firefox(3.6)でパイプライン処理が有効(network.http.pipelining == true)になっている場合を比べてみると、実際にはload eventが発生するまでにかかる時間が増えていることがわかります。
1から6の画像はそれぞれ異なる接続を利用していますが、7から8の画像は共有接続を利用してダウンロードしています。実際にどれと接続を共有しているかは明らかではありませんが(Firebugからそれを知るAPIはないため)、最後の2つの画像は接続を共有して合計時間を増加させているのは明らかです。

Example 4: Persistent Connections

このテストはHTTP Connectionヘッダーの効果を現しています。このヘッダーは既存の接続が閉じられているか将来のリクエストのために保持されているのかをサーバーに教えるために使われます。
それぞれKeep-Alive (default in HTTP/1.1) or Closeでどのような違いが出るかを見てみましょう。

それぞれのログで、最初のページと3つのリクエストとで合計4つが表示されています。
Connectionヘッダーは3つ(file1.php, file2.php, file3.php)のリクエスト時に要求されます。

#1 Test page (Connection: Keep-Alive)

• 一つ目のページのログでは、ページダウンロードのための一つの接続しか作られていないことがわかります。緑色のConnectionフェーズが一つだけになっていて接続が再利用されている事がわかります。

#2 Test page (Connection: close)

• 二つ目のログでは、ページダウンロードとfile1.phpのリクエストで接続が再利用されている事がわかります。しかし、他の接続ではConnection: closeなため、また接続を作り直す必要があります。

Example 5: Inline Scripts Block

インラインスクリプトがページのダウンロードをブロックすることはよく知られていますが、ネットワークの観点から見るとどのように見えるかを調べてしましょう。

#1 Cuzillion

3番目と4番目のリクエストの間に隙間ができています。これは5秒間のインラインスクリプトの実行によりブロッキング発生しています。 (*ここで言うインラインスクリプトとは<script>/*実行スクリプト*/</script>という感じで<script>タグ内で実行しているものを言う)
Inline Scripts Blockのページにて試すことができます。

Firefox5に試すとちょっと挙動が異なるけど、インラインスクリプトで隙間ができるのは同じ。
どちらかというとChromeがログに近い動きをしていた。
Firefox4からインラインスクリプトの実行タイミングが変わったのも関係するかもしれない。
詳細はSoftware is hard | Script Execution Analysis in Firefox 4に。

#2 Cuzillion

こちらはインラインスクリプトをページの底(</body>前かな?)に置いた場合のログです。
リクエストの合計時間は減っていますが、load eventは#1と同じくインラインスクリプトにより遅れていることがわかります。
こちらはCuzillionのようなイメージだと思います。

特にこれをどうとらえるべきかについては元記事に記述はありませんでしたが、この例はリソースのダウンロード時間よりもload eventなどへブロックが発生している事が重要な気がします。
負荷が大きいインラインスクリプトやdocument.writeなどのブロッキングを誘発するものがある場合loadやDOMContentLoadedイベントの発生を遅くしてしまいます。そのためdocument.writeそのものを避けることや、load eventなどイベントリスナーにして実行させるなどした方がページの表示は速くなるかと思います。

Example 6: Redirects

これはネットパネルにて、リダイレクトがどのように見えるかを表示した例。

#1 Final Page (one redirect)

サーバーによって301リダイレクトが行われて、URLの末尾に/がついたことがわかります。

#2 Final Page (infinite redirection)

無限ループしているリダイレクトの例
自分自身にリダイレクトしているのでいつまでもループしてしまいますが、Firefoxではデフォルトで20回で停止しています(network.http.redirection-limit の設定値)

document.getElementById("ASIN").value

Amazonはページ中のhiddenなinput要素にASINを持たせてるのでこういう手が取れる。

<input id="ASIN" type="hidden" value="4253196519" name="ASIN">

ページの構造が変わったらダメだけど、結構昔からこの部分は変わってないので意外と安定しているかもしれない。
amazon.comだと構造が違うものがあって、Amazon.com: Buried Prey eBook: John Sandford: Kindle StoreのようにKindle Storeだとページ構造が違ってID=ASINがない代わりに次のようなものがある。

<input type="hidden" value="B004LRPGPC" name="ASIN.0">

var ASIN = document.getElementById("ASIN") || document.getElementsByName("ASIN.0")[0];

もう一つの方法はwindowオブジェクトのプロパティから取得する方法

(2011年6月5日現在だと)

window.sitbAsin;

• Amazonの商品個別ページでASINを抜き出す – おれ ここ めも かきなぐる おまえ ここ よむ なぐる – subtech

最後はURLからASIN部分を切り出す方法

URLにはASINが入ってるはずなので、ページに構造の変化には強いけど、少しパースが面倒なところがある。
どのようなURLがあるかを把握する必要があるので、条件分けなども必要になる。
まあASINのフォーマットは\w{10}と決まっているので、ある程度安定するのかもしれない。

ついでに、replaceStateを使ってリロードなしでAmazonのURLを/dp/ASINだけの短いURLにするGreasemonkey書いた。

• Amazon URL Cleaner for Greasemonkey

有名な企業やライブラリはコーディングルールも公開している事が多いので適当にまとめてみました

JavaScript style guide – MDC Docs

Mozilla/Firefox向けのものなので、一部ECMAScriptの範囲を超えたものも含まれています。
多くの人が見ていると思うので、見たことない人は一度読んでみるといいです。

Google JavaScript Style Guide

Google JavaScript Style Guide 和訳 — Google JavaScript Style Guide 和訳(日本語版)
Googleのコーディングルールですが、ルールを並べるだけではなくなぜ悪いのかについても触れているので、一読をお勧めします。
Closure Linterというチェックツールもあるため、採用しやすいかもしれない。

JQuery Core Style Guidelines – jQuery JavaScript Library

jQuery Coreのもの。
Typeチェックの仕方についても触れている。

Dojo Style Guide – The Dojo Toolkit

Dojoのコーディングルール。
コード例が豊富で、命名規則やホワイトスペースの扱いなど細かいところまで入ってる。

Felix’s Node.js Style Guide

Felix’s Node.js Style Guide(和訳)(日本語版)
Node.jsにおけるコーディングルール。(公式なものではない。no official document)
Node.jsに限らず、クライアントサイドJavaScriptに置いても参考になる部分は多い。

Code Conventions for the JavaScript Programming Language

Douglas Crockfordによるもの。
コーディングルールというよりは慣習的なもの。
同作者によるJSLintも併用しましょう。(JSLint or JSHintは他のコーディングルールであっても採用してよいもの)

Code Guidelines for Rich Internet Application Development

コーディングルールではなくてガイドライン的なものです、HTMLやCSS、JavaScriptについてのガイドラインを書かれている。

Introduction to Apple JavaScript Coding Guidelines

JavaScript Coding Guidelines for Mac OS X(日本語版)
Appleによるコーディングのガイドライン。
“JavaScriptのベストプラクティス”でコーディングで気をつける事について触れている。

The WebKit Open Source Project – WebKit Coding Style Guidelines

JavaScriptではありませんが、Webkitにおけるコーディングルール。
ホワイトスペースやLine breakingの所はJavaScriptの場合でも参考になる。
uupaaさんがこれをベースに一部分を変更した感じで使ってるそうです。

• CodingStyle – uupaa-js – JavaScript Coding Style Guide – JavaScript Library for Casual Creator – Google Project Hosting

サイボウズで学んだこと – IT戦記

amachangによるもの。
大規模 JavaScript 開発におけるルールや命名規則、デバッグ、パフォーマンスについて触れています。
コーディングルールを整えてどのように実践したかについて参考になります。

JavaScriptパターン (オライリー本)

JavaScriptパターン ―優れたアプリケーションのための作法

posted with AZlink at 2011.5.27

Stoyan Stefanov,豊福 剛
オライリージャパン
売り上げランキング: 8213

Amazon.co.jp で詳細を見る

この書籍のChapter 2. Essentialsにおいて、JavaScriptのコーディングルールが紹介されています。
また避けるべき事やどう書くべきなのかについてもかなり深く書かれています。

コーディングルールは”どう書けばいいのか分からない”という人向けのものではないと思います。どう書いたらいいのか分からない人は、まずなぜそのように書いたらダメなのかを知るのがよいと思います。
そのため、書き方に不安を持ってる人はなぜダメなのかについても触れているGoogle JavaScript Style Guide 和訳を読むのがよいと思います。(読みやすい日本語版もあるしね)
コーディングルールはコードに一貫性を持つためにあると思います。頻繁にルールを変える必要はないと思いますが、必ずしもそのルールが、その時の(実行環境|JavaScript)において最適な書き方ではない場合もあります。そういうときはルールの更新をしましょう。

おまけ

自分の場合はWebStormの自動整形に任せている(といっても膨大なルール設定があるため、上記で紹介したコーディングルールを自動化できる)ので、基本的にはIDE任せという書き方にしています。
セミコロン忘れなどについてはcomplete current statement機能( [WebStorm]Complete Current Statementがとても便利な件(・∀・))を使ったり、WebStormのシンタックスチェックはかなり優秀なのでエラーも書いてる途中で発見しやすいです。(シンタックスチェックも細かく制御できる)
そのため、やっぱり道具任せといった感じではありますが、WebStormを使用していない場合も同じコードが書けるようにある程度のルールは持っています。
Google JavaScript Style Guide + WebKit Coding Style Guidelines に近いですが、ホワイトスペースなど見た目的なちょっとした違いにはそこまで厳しくしない感じで書いています。
if, for, while, doなどの{}は省略しない(WebStormの自動整形で中括弧を強制的につける)、誰が見てもある程度読める感じにする、ブレークポイントを打ちやすい空間を作るように配慮するなどなどで、他のコーディングルールに書いてある事と同じようなものだと思います。

DropPagesについて

DropPagesの導入方法

詳細はGetting started | DropPages.comを見る。

1. DropPagesから好きなThemeファイルのzipをダウンロードする
2. zipを展開すると<Theme名>.droppages.com というフォルダができるので、
   このフォルダ毎、Dropboxフォルダの好きな所に置く
3. <Theme名>..droppages.com の<Theme名>を自分の使いたいサブドメイン名にする。
   たとえばうちはhttp://sig.droppages.com/なので、sig.droppages.comというフォルダ名にリネーム。
4. Dropboxフォルダ内なら、右クリック->Dropbox->このフォルダを共有からDropboxのサイトが開いて、
   コラボレータのメールアドレスを入力する画面になる。
5. 招待するコラボレーターにserver1@droppages.comと入力すれば共有は完了。

後は、その共有したフォルダ名のアドレス(sig.droppages.comならhttp://sig.droppages.com/)にアクセスできるようになるまで待つだけ(結構かかります。一日とか)

Droppagesの構造

FolderLayout | DropPages.com

sig.droppages.com
├Content[DIR]
│  └記事となるmarkdownファイル
├Public[DIR]
│  └css, js ,画像などのテンプレートから呼び出すリソース
└Templates[DIR]
   └テンプレート.html

自分のサイトはazu/4-Code-Reading – GitHubでコンテンツ共々テンプレートも公開しているので、適当に見てください。(アクセス解析のコードとは固有になっちゃってるけど)

Droppagesのコンテンツ(記事)はtxtファイルに、以下のような感じで書いていって保存すると、Dropboxで同期されて自動でWebサイト側が更新される仕組みなってます。

@Title タイトル
@Body
記事内容書ける
Markdown記法を使える
これ以外にも変数は定義できるけど

• Markdown – 閾ペディアことのは
• Kawaz – Markdownの使用方法

などを見るとよいと思います。

MarkdownならiPadのTextasticなど対応してるアプリもいろいろある。

コードリーディング

Droppagesを使えば、markdownファイルに書いて保存するだけど自動的にWebに公開するという手順が簡単に行えます。
で、なんでコードリーディングサイトにしようと思ったのかは、元々Markdownなどでコードリーディング記録を書きたいなーと思っててGithub pages + Sphinxなどいろいろ試してたんですが面倒な手順が多くて、そこに自動的にMarkdownを変換して公開できるサービスとしてDropPagesがきたわけです。

コードリーディングの環境にはWebStormを使っています。
WebStormならMarkdownプラグイン(EAPだと動かなかったりするのでWebstormは正式版を使う)があるのと、WebStormには構文解析をおこなってコードの構造がつかみやすいのでコードリーディング自体に最適だと思います。
(ブックマークや変数、関数、参照先へのジャンプ、アウトラインなどなど)

WebStormはファイルの分割表示を持ってるので、左でコードを読んで、右でMarkdown形式でコードリーディングの記録を書いていくという事もできます(EmacsとかVimとかでも似たような環境作れると思う)

Markdownのプレビューもその場でできる。

少し戻って、テンプレートはいろいろいじって、記事毎にいろいろメタ情報の変数を定義させるようにすれば、普通のブログと遜色ないぐらいの記事が簡単に作れます。
毎回その変数定義を手入力だと面倒なので、WebStormのテンプレートからファイルを作るFile Templeteの機能を使って以下のような感じにしています

• DroppagesのFile Templete — Gist

実際に入力して出てくる感じは下のようなもの。後はBody以下を書いていくだけ。

@Title Underscore.js
@description 便利関数の詰め合わせライブラリUnderscore.jsのコードリーディング
@keywords Underscore.js
@Dates 2011年05月03日
@Body
[Underscore.js] 1.1.6のソースコードを見ていく

Table of Contentsによるとそれぞれジャンル分けされているので、それに沿って読む。

1. コードはブロックぐらいで適当に区切って読んでいく
2. ## ブロックタイトル とMarkdownにブロックのタイトルをつける(テンプレートで自動的に目次生成をしているため)
3. コードを読みながらコード本体にコメントとして、コードの解説やアノテーションなどを書いていく
4. コードブロックを読みながら、気になったことや使い方や例などはMarkdownに書いていく
5. コードブロックを読み終わったら、そのコードブロックをMarkdownにコピペする(先ほどのように字下げしてpreにする)
6. 1から繰り返し
7. 全部読み終わったらDoccoでコンパイルして、コード全体とコメントを見比べしやすいHTMLを生成する。(コード本体にコメントを書いていくのはこれも目的にしているため)

## でサブタイトルをつけて区切っていくのは英語が読めない人向け、英語技術書の読み方 | Web scratchでやっていたような章ごとに本を読んでいくのと同じ感覚でやっています。
またFunctions of undersocore.js – 4 Code Readingなど適当なページを見てもらうと分かると思いますが、h2,h3などのタグには自動的に内部リンクを振って目次を作るためにもサブタイトルをつけています。

また、コンテンツは先ほどから言っているようにmarkdownで書けるので、githubとも相性がいいです。(githubはmdファイルを変換して表示してくれる)
どこまで読んだかをgitで管理できたり、githubなどを使って複数人で共有したりもできるのでいろいろな使い道があると思います。また仮にDropPagesが消滅しても手元にはコンテンツファイルが残るので、markdownならそこそこメジャーなので逃げ道もいろいろあると思います(htmlに変換もできるし)

Dropbox+DropPages+Markdown+GitHub+WebStorm(任意のエディタ)

= 素敵なコードリーディング生活

ここからDropboxに登録すれば250MBのボーナスがうんぬんです。

• azu/4-Code-Reading – GitHub (自分のサイトのテンプレートなど)
• Home | DropPages.com

現在のFirefox4に正式対応しているのはFirebug1.7xで、Firebug1.8xはAlpha版として公開されているのでまだ不安定な部分もあることに注意して下さい。
特に注意書きしてない部分はFirebug1.7の項目だと思って大丈夫だと思います

コマンドラインに履歴ボタン

コンソールパネルでのコマンドエディタ(でかい方のコマンドライン)にHistoryボタンが新たに追加されました。
過去に実行したコマンドをポップアップから選択して挿入することができます。(以前はCtrl+ZでUndoし続ける必要があった)

コマンドライン(小さい方)も同様に履歴ボタンが存在します

スタイルサイドパネルの表示が細かく制御できるように

CSSパネルにあるスタイとるサイドパネルの計算済みスタイルでアルファベット順のソートができるようになりました。
そのため並び順でどのようなスタイルが適応されているのかが見やすくなりました。

同じくスタイルサブパネルにて、Only Show Applied Stylesフィルターが追加されました。
これは重複して適応されているものなどを非表示にすることで、実際に適応されているスタイルが見やすくなります。

• Getfirebug Blog » Blog Archive » Firebug 1.7b1

コンソールの実行結果の表示形式が変更

コンソールの実行結果の表示にてglobalStorageオブジェクトにも対応しました。

それに伴ってDOMパネルにおいてDOM Storage(global, session, local)の表示に対応しています。

また、以前はDateオブジェクトをコンソールに表示すると、DateをtoStringした値が表示されていたのがちゃんとDateオブジェクトとして表示されるようになりました。

この辺のコンソール実行結果の表示形式の変更に伴ってか、http://jsfiddle.net/efcl/zVFdd/3/ のようにconsole.log()の返り値が_firebugIgnoreとなっています。これはconsole.log(“hoge”);でundefinedが返ってくるとログ画面にundefinedが表示されてしまうので、仮の値として_firebugIgnoreを返してログ画面ではそれを無視しよう的な方法がとられているため、undefinedではない値を返すようになっているようです。(FIrefox4 +Firebug1.7以降)
なので、console.logがundefinedを返す事を期待するのは少し危険です。

• Re: Test results for Firebug 1.7 + Firefox 4 combo

Break時のメッセージUIが変更

JavaScriptやHTMLの変更に対してブレークポイントを打った際にBreakした事を知らせるメッセージUIが変わりました。
以前よりわかりやすい表示になりました。

ファイルの指定行数目にジャンプ

エディタではよく見られる、JavaScriptやCSSなどの指定行数にジャンプする機能が検索バーに追加されています。

検索バーに #行数 と入力する事で指定行数にジャンプすることができます。

メモリプロファイラー

Firebug1.8a2にてメモリ使用量の変化を見るメモリプロファイラーが実装されました。

これはabout:memoryと同じAPIを使っていて、Firefox4からJavaScriptのヒープメモリなども取得できるようになったのに基づいて作られています。以前書いたJavaScriptからメモリ情報を取得する方法 | Web scratchでのWebkitに実装されているconsole.memoryに近い感じの値がとれるようになったと思います。
メモリプロファイラーはボタンを押してから次にボタンを押すまでのメモリについての変化を見る機能となっているようです。Firebug1.8aを入れた状態でTest Case for Issue #4376にて実験することができます。

このメモリ監視機能は元々MemorybugというFirebug拡張として開発されていて(Firebugの実験的機能は別アドオンとしてくられることが多い)、それがFirebug本体にポートされ始めたものだと思います。将来的にはコンソールAPIにconsole.memoryProfile()などのメモリプロファイル操作APIが追加されると思います。

• Firebug Memory Profiler – FirebugWiki

DOMパネルの表示が細かく制御できるように

同じくFirebug1.8a2にて、DOMパネルにshowOwnProperties と showEnumerablePropertiesのフィルタオプションが追加されました。
showOwnPropertiesはprototypeチェーンの表示を決めるフィルタで、showEnumerablePropertiesはenumerableなプロパティの表示を決めるオプションとなっています。スタイルサイドパネルと同様にDOMパネルにおいてもフィルター機能が充実してきているようです。

ここで書かれている内容はほとんど

• Firebug 1.7 New Features ✩ Mozilla Hacks – the Web developer blog
• Getfirebug Blog
• Firebug Release Notes – FirebugWiki

に載っている内容です。
今回書いたもの以外にも変更点はあるので上記のサイトを読むといいです。
動画で見るFirebug1.6の変化も What’s new in Firebug 1.6 on Vimeo

蛇足

Google ChromeのJavaScriptデバッガの進化がすごい – 0xFFが元ネタなので、それと似たようなアドオンの紹介。

圧縮されたコードの整形

IE9の開発者ツールに実装されていたJavaScriptコードの整形機能はJavascript Deminifierというアドオンによって行う事ができます。

たとえばGoogleのJavaScriptは圧縮されているため普通は読めませんが、

JSBボタン(Javascript Deminifierをインストールするとステータスバーに表示)をONにする事で

このように整形してくれます。
これはリロードした際にも維持されているので、整形した状態のJavaScriptにたいしてもブレークポイントを打つことができます。

これで圧縮されているライブラリの確認も楽にできます。

Firebugをエディタにする拡張

Firebug AutocompleterはFirebugのコマンドラインに自動補完機能をつけてくれます。
コマンドライン(小さい方)は公式にも一応ついていますが、コマンドエディタに対してもポップアップして表示される自動補完機能をつけてくれます。

AcebugはFirebugのコマンドエディタをAjax.org Cloud9 Editorのものに変えてくれます。
Syntax Highlightingや自動補完やファイルからロード、セーブなどエディタさながらの機能をつけてくれます。
少し重たいですが便利です。

そのほかにもjQueryに特化したFireQueryやリッチUI系のExtJSやSproutCoreなどのライブラリに特化しているIlluminations for DevelopersやRuby on Railsに特化したRailsBugなど様々なFirebugアドオンがあります。
後、FirebugはIndex of /releasesあたりに新しい機能や実験的なものをFirebug拡張として分けて置いていることが多いです。その中には要素に適応されているイベントを表示するEventbugやCSSパネルでCSSが適応されてる要素を表示するselectbugなど結構便利なものがあります。(いずれFirebug本体に載るのかもしれない)

• Firebugを拡張するアドオンをまとめてみた | Web scratch

表面的にはFirebugはそこまで大きく変わっていないように見えますが、少しづつ内部の整理も入ってきているため、Firebug拡張も作りやすくなるようです。

IE、Firefox、Chrome&Safari、Operaとブラウザ自体も大きく変化していきますが、その中のデバッガもいろいろな変化が起きています。それぞれのブラウザでいい機能はどんどん取り入れて(パクって)いってもらいたいですね。

• Downloads: All Versions of Firebug : Firebug

追記

タイトルにJavaScriptデバッグとあるのは元ネタに合わせてみただけですが、Firebug1.7はCSS関係の機能が結構拡充されてる印象。

アイコンが…ってのはFireBugのアイコンを置き換えようじゃなイカ : Firefoxをイカ娘が侵略プロジェクトなんてのもあるんじゃなイカ
userChrome.cssとかStylishでアイコンぐらいなら簡単に差し替えできるよ(アップデートの度にやり直さなくてもいいという利点も)

以前はDownloading jQuery – jQuery JavaScript Libraryに書いてあるようにAntを使ってどのOSでもビルドできたようですが、現在はuglifyやJSLintを使う都合上かも知れませんがNode.jsがビルド環境に必要となっています。
jQueryの開発コードをビルドして使う (Win & Mac) – Rewish の後半がNode必須になった感じ。

環境はWindows7 6bitで、cygwinでもNode使う事ができるのでやればできるみたいですが、VM上のUbuntuをつかって作業しました。
参考

• WindowsからVM上のLinuxをSSH経由で利用する開発環境の構築 | Web scratch

必要なもの

• git
• node.js環境

jQueryのコードはgithubからcloneして持ってきます。
git clone –recursive https://github.com/jquery/jquery.git するのが楽ですが、他の方法もjquery/jquery – GitHubに書いてあります。

$# git clone --recursive https://github.com/jquery/jquery.git
# githubからサブモジュールも含めて再帰的にclone
Initialized empty Git repository in /media/sf_D_DRIVE/MyDocuments/Dropbox/workspace/toybox/lib/jquery/.git/
remote: Counting objects: 18336, done.        
remote: Compressing objects: 100% (5977/5977), done.        
remote: Total 18336 (delta 13065), reused 17001 (delta 11817)        
Receiving objects: 100% (18336/18336), 12.53 MiB | 1.04 MiB/s, done.
Resolving deltas: 100% (13065/13065), done.
Submodule 'src/sizzle' (git://github.com/jquery/sizzle.git) registered for path 'src/sizzle'
Submodule 'test/qunit' (git://github.com/jquery/qunit.git) registered for path 'test/qunit'
Initialized empty Git repository in /media/sf_D_DRIVE/MyDocuments/Dropbox/workspace/toybox/lib/jquery/src/sizzle/.git/
remote: Counting objects: 1422, done.        
remote: Compressing objects: 100% (622/622), done.        
remote: Total 1422 (delta 903), reused 1169 (delta 734)        
Receiving objects: 100% (1422/1422), 526.34 KiB | 243 KiB/s, done.
Resolving deltas: 100% (903/903), done.
Submodule path 'src/sizzle': checked out '4bcc09702d6dadfd0b90c7de3c8b206e97ff97f4'
Initialized empty Git repository in /media/sf_D_DRIVE/MyDocuments/Dropbox/workspace/toybox/lib/jquery/test/qunit/.git/
remote: Counting objects: 995, done.        
remote: Compressing objects: 100% (751/751), done.        
remote: Total 995 (delta 415), reused 661 (delta 241)        
Receiving objects: 100% (995/995), 158.30 KiB | 98 KiB/s, done.
Resolving deltas: 100% (415/415), done.
Submodule path 'test/qunit': checked out '9887663380693009874e8c76f0bf77a921931766'
$# cd jquery/
$# ls
GPL-LICENSE.txt  MIT-LICENSE.txt  Makefile  README.md  build  speed  src  test  version.txt
$# make
# makeコマンドでjQuery.jsとjQuery.min.jsを生成
Building selector code from Sizzle
Building ./dist/jquery.js
Minifying jQuery ./dist/jquery.min.js
Checking jQuery against JSLint...
JSLint check passed.
jQuery build complete.
$# ls dist/
# jquery/distディレクトリに生成される
jquery.js  jquery.min.js

makeコマンドでJSLintや圧縮がかかったものが生成されますが、make jqueryとすることでそれらをかけないで生成することもできます。
細かい事はjquery/jquery – GitHubに載っています。

まずはJavaScript librariesの設定(Settings> JavaScript Library)で、Addボタンを押してローカルにおいたjQuery.jsをFileに指定します。
Documentation URLsのSpecifyボタンを押して、http://api.jquery.com を指定してからダウンロードボタンを押すとローカルにjQueryのドキュメントがダウンロードされます。(実際にダウンロードされるのはRaw XML API Dumpですがhttp://api.jquery.comの方を指定する)

これでライブラリの追加は終わったので、次は実際にjQueryを使うプロジェクトを開きます。(プロジェクトを開いていない状態で設定すれば常に適応されるグローバルとして設定できると思う、その辺はWebStormのコード補完に新しく候補を追加する方法 | Web scratchと同じかな）
また同じく設定に行き、JavaScript Library>Scopeを見るとそのプロジェクトで適応されているライブラリが分かると思います。jQuery(Addボタン追加したライブラリ名の事）にチェックを入れれば準備は終わりです。(逆をいれば、プロジェクト毎に補完候補に現れるライブラリを指定できるようになっている)

後はjQueryのメソッドにカーソルを合わせて、Quick Documentation Look-up(デフォルトCtrl+Q)をすれば、APIドキュメントがパネルに表示されます。

Shift+F1か、ポップアップしたドキュメントの矢印ボタンからドキュメントのWebページのジャンプもできる。

今回はjQueryだけみたいですが、ちゃんとオフライン向けのドキュメントを発行してくれるライブラリなら対応されるかも知れません。ドキュメントのヘルプページへのジャンプ機能はjQuery以外にも対応しているライブラリがあります。
WebStorm & PhpStorm Blog » Blog Archive » External API Docs Support for Popular JavaScript Frameworks

jQueryの補完もちゃんとできるし、APIドキュメントもすぐに見られるようになったのでjQuery使うのがかなり楽になったと思います。後、自分で追加するJavaScript librariesを設定できるので、ライブラリバージョン別に分けるといった事もできたりすると思います。

参考

• WebStorm & PhpStorm Blog » Blog Archive » External API Docs Support for Popular JavaScript Frameworks
• WebStormのコード補完に新しく候補を追加する方法 | Web scratch

おまけ

WebStormが今春のキャンペーンがまだ続いているので半額で購入できるみたいです。
JetBrains公式のNodeJSプラグイン(Node.jsもそのうち公式対応されると思う)の公開が始まったりして、まだ進化のスピードは落ちてない印象なので、安いうちに買っておくのもいいかと思います。