Web scratch

Archive for the ‘javascript’ Category

もう既に見た人もいるかもしれませんが、オフライン勉強会でJSer.info一周年について発表してきた | JSer.infoで
今まで書いてた記事のまとめ的な発表をしてきました。

• 海外の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

第七回ありえるえりあ勉強会 〜JSで大規模・エンタープライズ開発〜に参加してきたので、その時のメモ。

「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

2011年10月1日に行われたMozilla 勉強会＠東京 6thのメモ

イベントのページ: 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以降は禁止された
    • ざんねんでしたね

Software is hard | Page load analysis using Firebug の記事を元に書いています。
January 18th, 2010に書かれた時点での例を使用しているため、現在のブラウザでは若干挙動が違うかもしれません。
また、著者のJan Odvarkoさんに翻訳許可は頂いていますが、翻訳というより意訳や自分の理解のために書いていたので、いろいろ書き加えたりしています。
Net panel(ネットパネル)について理解したいと思って書いたので、Net Panel自体の解説記事Software is hard | Introduction to Firebug: Net Panelも一緒に読むといいかもしれません。

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

一つの方法はinput要素から取得する方法

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の書き方はJavaScript自体がある程度自由なためいろいろな書き方ができますが、一貫性を持って書いた方がバグなども発生しにくくなるため、コーディングルールを定めておくのはよいことだと思います(特に複数人の開発の場合)

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

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というDropboxにテンプレートファイルとMarkdownで書いたコンテンツ(記事)を置いて公開できるサービスを利用してどこでもコードリーディングができる環境を作って使っています。

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

Firefoxのデバッグ拡張ことFirebugですが、Firefox4よりFirebugとは別にWeb Consoleという機能が入りました。
しかし、Firebug自体もさらに便利になっているので、少し紹介します。(Firebug1.7 –1.8 の範囲で)

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

Read the rest of this entry »

普段、jQuery(本体)のコードを見たりする時にウェブだと見づらいので、ローカルにダウンロードして見ているのですが、jquery/jquery – GitHubからpullしたものにはビルドしたjQuery.jsが含まれていないので、ビルドできる環境を整えてみました。

以前は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に載っています。

WebStorm & PhpStorm Blog » Blog Archive » jQuery API documentation at your fingertipsで紹介されていますが、WebStorm上でjQueryのオンラインヘルプをローカルにダウンロードしたものを表示できるようになっていました。(WebStorm/PHPStrom 2.1 以降が対象)

まずは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もそのうち公式対応されると思う)の公開が始まったりして、まだ進化のスピードは落ちてない印象なので、安いうちに買っておくのもいいかと思います。