君は3つのリロードを知っているか?
はい、今さら聞けないウェブ開発者の基礎知識のお時間です。
ブラウザには3つの読み込みモードがあることはご存知ですか?
2つくらいはわかるけど、3つ目が出てこないって方は少なくないかもしれません。
- リロード
- 一番オーソドックスなのがブラウザのリロードボタンを押したときの挙動ですね。普通ですね。
- スーパーリロード
- ページ遷移(リフレッシュ)
- 3つ目はちょっと良い名前が思いつかないのですが、リロードではなく、通常の画面遷移での読み込みのことです。アドレスバーにフォーカスしてenterするといった方法で実現できます。むしろこれこそが普通です。
id:edvakfさん曰く、Operaにはリクエストを投げずに更新するRefresh Displayというアクションがあるらしい。確かにリフレッシュというのは適切な名前な気がする。
それぞれどう違うのか、特に1つ目と3つ目はどう違うのか不思議でしょうか?
ちゃんとリクエストの様子を眺めてみると違いがよく分かります。
ページ遷移
リロードは大元のHTMLを受け取ったら、そのページ内のリソースについてレスポンスヘッダを確認しに行っています。その結果304 Not Modifiedが帰ってきて、実際にはキャッシュを使っています。
対してスーパーリロードはキャッシュに関係なく、すべてのリソースを取得しなおしています。
そしてページ遷移時は、キャッシュがあり、Expireが効いている場合はそもそもリクエストを送っていません。完全にローカルキャッシュだけを使っています。
(ちなみに、ページを進んで(ブラウザの戻る機能で)戻ったときは大元のHTMLを含めてキャッシュが使われたりします。)
なお、当然ですがすべてのブラウザがこの3つのモードを持っているわけではありません。Operaにはスーパーリロードに相当する手段がなさそう(知らないだけかもしれませんが)だったりします。
というわけで、3つのリロードの違いを意識して、開発時に使い分けるのがウェブ開発者のたしなみです。
Google ChromeのJavaScriptデバッガの進化がすごい
Chrome版のFirebugことGoogle Chrome Developer Toolsですが、以前gihyoで解説したときよりさらに便利になっているので、少し紹介します(元はWebKitなので、そのうち(近いうちに)Safariでもそれなりに使えるようになるはずです)。
圧縮されたコードの整形
まず、目立つところからいきましょう。ちょうど先日更新されたChromeのdev版(12.0.742.0)に搭載されたばかりの機能で、minifyされているJavaScriptコードを読みやすいように整形して表示してくれるというものです(IE9の開発者ツールにも実装されている機能です)。
例えば、Google Analyticsのコードは圧縮されていて普通は読めません。
しかし、Chromeのデベロッパーツールなら、
このように整形してくれます。
やり方は簡単で、デベロッパーツールのScriptパネルの左下に { } というアイコンがあるのでそれをクリックするだけです。*1
このチェックはデベロッパーツールを起動している間だけ有効で、リロードしても維持されます。
つまり、整形した状態でブレークポイントを設定して、実際にブレークすることができます。
これで圧縮されているライブラリのデバッグがものすごく簡単になります。
なにより大事なのは、これまでは開発者にとってJavaScriptを圧縮するかどうかは、デバッグしやすさとパフォーマンスとの間のトレードオフで悩ましい問題だったわけです。しかし、それはもう過去の話で、圧縮してもデバッグに支障がなくなったので、圧縮しない理由の1つがなくなった訳です。
とは言ったものの、今のところ実装されたばかりの機能なので安定していません。実際に使えるようになるにはまだ少し時間が必要です。今後が非常に楽しみですね。
JavaScriptのインスタント編集
Scriptパネルのコードエリアでダブルクリックすると編集モードに入り、自由にコードを書き換えることができます。残念ながら(2011年4月22日時点では)編集した内容を保存できないので、デバッグには使いにくいですが、あとからデバッグコードを埋め込むことなどが可能で、こちらも今後が楽しみです。こちらはstable(10.0)とdev(12.0)で少し挙動が違いますが、stableでも使えます。
柔軟なブレークポイント
様々なブレークポイントを設定することが可能で、通常の行単位でのブレーク以外に以下のようなものがあります(こちらはstable版でも使えます)。
- 条件付きブレークポイント
- 任意の条件式がtrueを返すときだけブレークする
- DOMブレークポイント
- DOMの内容や、属性、削除されたときにブレークする
- XHR ブレークポイント
- XHR送信時にブレークする、送信先が特定の文字列を含む時だけブレークすることも可能
- Event Listenerブレークポイント
- キー入力、マウス、タイマー(setTimeout)などのイベント時に自動でブレークする
- 例外発生時にブレーク
- 例外が発生したときにそこでブレークすることも可能です。catchしているときはブレークしないようにもできます。
パネルでの表示はこんな感じです。
特に、XHRでのブレークとタイマーでのブレークがすごく便利です。非同期処理はコードを追いにくいので、そこでブレークできるのは非常に助かります。
他にも色々な改良が行われていて、個人的には(特にJavaScriptに関しては)FirefoxのFirebugよりChromeのデベロッパーツールの方が使いやすくなったと思っています。ただ、概してツールというのは慣れによる使いやすさが大きな比重を占めてしまうので、最初は使いにくいと感じるかもしれません。が、そういった固定観念に囚われてしまうのは勿体無いので、是非デベロッパーツールをアレコレ試してもらえればと思います。
ところで、ちょうど4/22から4/23にかけて、第2回 開発コンテスト24というイベントをやっています。ものづくりに情熱のある方が是非ご参加ください!クックパッドオフィスのラウンジを開発スペースとして提供もしているので、是非ご利用ください。
*1:記事を書いた当初は右クリックメニューにDe-obfuscate Sourceという項目があったのですが、今はアイコンになっています
prototype.jsからjQueryに移行するたったひとつの冴えたやりかた
どうもこんにちは、os0xです。
実は(Twitterに書いただけで)ブログに書いてなかったのですが、3ヶ月ほど前からクックパッドで働いています*1。なんかもう今更ですよね、すみません。
さてさて、クックパッドですが、つい一昨日までprototype.jsを使っていました。で、昨日jQueryへの移行をリリースしたところだったりします。
というわけで、その辺の話を少し書いてみたいと思います。
そもそも、なんでjQueryに移行するのか
まあ、prototype.jsとjQueryどちらを使うかと問われたら、大抵の人はjQueryと答えますよね。確かにjQueryの使いやすさは魅力的です。使いやすいということは、みんなでjQueryを使ってサービスを作ることができます。特定の誰かに依存してボトルネックになったりすることがないなら、それは素晴らしいですね。
しかし、ライブラリを変えるのは簡単なことではありません。JavaScriptのテストがしっかり書かれているなら安全に移行できるかもしれませんが、まあ、それは期待できないでしょう(というか、そのテストがライブラリに依存してたり)。
本当にそのコストをかけてまでjQueryへ移行するメリットはあるのか、というのが実際的な問題です。
ただ、コストが問題というのなら、簡単にprototype.jsからjQueryに移行できるなら、それをしない理由はないというわけです。
prototype.js依存をなくす
jQueryとprototype.jsは共存できますが、共存させるということはつまり両方に依存するということです。一度両方に依存してしまうと分離はまた面倒なことになります。なので、動くようになるまで多少大変でも完全に切り替えてしまったほうが良いでしょう。
prototype.jsからjQueryへの書き換えは割と単純で、例えばAjax周りだと、次のようになります。
new Ajax.Request(url, { onSuccess: function(response) { // } });
jQuery.ajax({url:url, success:function(response){ // });
new Ajax.Updater('id', url, { parameters: params });
jQuery.ajax({ url:url, data:params, success:function(response){ jQuery('#id').html(response); });
他にも、
- Element → jQuery().show/hide...
- Event → jQuery().bind
- $('id') → jQuery('#id')
- $$('#id .class') → jQuery('#id .class')
- $A(arguments).each(function(){}) → jQuery.each(arguments,function(){})
- $H({}).each(function(){}) → jQuery.each({},function(){})
といった感じで割と簡単に書き換えできます。$とかEventとかAjaxとかキーワードがあるので、割と機械的にいけるはずです。
ちなみに、あえてjQueryは$を使わずにjQueryと書いたほうが書き換えたことが分かりやすくなるのでお薦めです。
コードの量にもよりますが、この作業自体はそれほど大変ではないと思います。
jQueryで正しく動いているかの検証
さて、最大の問題はjQueryに書き換えたコードが正しく動いているかどうかの検証です。どうしてもバグを作ってしまうはずなので、以下にしてそれを検知するかが課題となるわけです。
そこで、役に立つのがwindow.onerrorです。FirefoxとIEではwindow.onerrorを定義しておくと、ページ内で起きたすべてのJavaScriptエラーを捕まえてくれます。Firefoxでは(new Errorで)スタックも取れますし、IEでは呼び出し元関数を取れたりするので、デバッグに必要な情報を集めることができます*2。
はてなスターのユーザー名をCSSだけで強引に表示
なんとなくブログの見た目を少しいじった(テスト前になると部屋を片付けたくなるアレ)。
シングルカラムだと横に間延びするのは前から気になってたので、max-widthを1000pxで設定して、あとフッターをシンプルに。
で、はてなスターってデフォルトだとマウスを乗せるまで誰のだかわからないのが気になってて、自分ではGreasemokey Scriptでユーザーのアイコンに置き換えてるんですが(hatena big profile star)、そういうことをしてない多くの人はが並んでいるだけで、わかりにくいなーと。
ってことで、装飾してやろうと思ったけど、CSSだけだとやはり厳しい。まあ、IEを考えなければ(IEだと普通の表示のまま)ってことで、afterとか使って強引にIDを表示してみた。
CSSはこんな感じ(ネガティブなtext-indentとoverflow:hiddenというよくあるバッドノウハウ)。
span.hatena-star-star-container a[href^="http://d.hatena.ne.jp/"]:after{ font-size:11px; color:#666; content:attr(href); display:inline-block; overflow:hidden; text-indent:-11.5em; font-family: "Consolas", "Inconsolata", "Menlo", monospace; }
追記:リンク先がはてなダイアリー以外だと残念なコトになるのにも対策した
で、こんな感じに。
おっと、グリモンが効いてた。
IEも8-9で標準モードを強制すればちゃんと見える。Operaはちょっと変…。
しかし、有料オプションでもいいからDOCTYPEの選択ができるようになってほしいな。
2011年のJavaScriptとかなんとか
昨年に続いて、新春特別企画:2011年のJavaScript ─ウェブアプリ全盛の時代へ|gihyo.jp … 技術評論社を書きました。
去年、当たったら(自分が)面白いよねくらいな気持ちで書いた「拡張」とか「サーバーサイドJavaScript」が見事に的中してて驚きました。特にNode.jsブームはすごいですね。
ってわけで今年は、Node.jsのどこが注目されているのかを書きました。あと、それに呼応してBigPipeにも言及。BigPipeはid:brazilが東京に来たときの飲み会で@kzysに教えてもらった。確かにかとーさんはいつも良いネタ持ってる印象があるなあ。
そういえば、今年の後半は色々忙しくてブログにあんまり書いてなかったけど、DeNA Technology Seminar #3 : ATNDでJavaScriptの未来みたいな話をしました。この時も@kzysが来ていた。@h_kishiのHTML5@iPhoneゲーム開発でCanvasは遅いとされていた件について、
@os0x: canvasが遅いのではなく(速くはないけど)、iPhoneのCSS AnimationはGPU使って速くしてるから差が出るって話だった気がする。canvasでもGPU使われるようになればその差はなくなるはず。 #denatech
2010-11-15 19:59:41 via web
と発言したんですが、これについて懇親会で@kzysからCanvasのGPUってほんとに効果あるんですかと的確なツッコミが…。去年IEのPlatform PreviewでCanvasにGPUを効かせることで高速化したってデモが公開されたことで、CanvasもGPUで高速化するって印象がありますが、実際のところCanvasでGPUの恩恵を得られるのはdrawImageを呼ぶところくらいしかない(IEのデモはでっかい画像をdrawImageしまくるという露骨なデモ)ので、GPU入っても大抵のCanvasは全然変わらないというか、むしろ遅くなりかねないくらいです。。なので、上の発言は確かに誤解があるかなと…。
まあ、Canvas+CSS Animationで頑張っているところを、CSS Animationの代わりにGPUパワーのdrawImageにしてCanvasで統一するくらいはできそうですよってことです。
あと先月はHTML5とか勉強会でFile API話をしました。File System API周りについてのプレゼンは、日本初どころか世界初との言を b:id:vantguarde より頂きました。
連載:これでできる! クロスブラウザJavaScript入門|gihyo.jp … 技術評論社のほうも順調(?)に回を重ねています。しばらくUIの実装を色々書いてみようと思います。
MacをJavaScriptの開発環境にするメモ
以前は自宅も仕事もWindowsメインな環境だったんですが、仕事の方がでMac+英語キーボードな環境になり、ついでなので自宅もそれに合わせることにしました。
環境はMac miniの最新型で一番安いの(6月くらいに購入)とMacbook Airのやっぱり一番安いの(11月に購入)です。両方合わせて15万くらい。お手頃…なのか?どうでもいいけど、mac miniは1.3kgしかなくて、Macbook Airの13インチとほぼ同じ重さだっりします。miniデスネー。
ついでにWindowsのほうは2年半前に買ったCore2duo(Windows7アップグレード済み)で、当時そこそこハイエンドだったやつです(ちょうどMac miniと同じくらいのスペックだけどこいつは一体何kgあるんだろう…)。
以下、Macの開発環境をなるべく最近の流行りを取り入れてレポートします。
ブラウザ
さて、マシンのセットアップで最初にすることといえば、もちろんブラウザのインストールですよね! とりあえずスタンダードにChrome、Opera、Firefoxを入れておきます。
ChromeはChrome Release Channels - The Chromium Projectsからdev、beta、stableの各バージョンがそれぞれダウンロードできます。ダウンロードしたファイルを実行するとGoogle Chrome.appが出てきます。通常はこれをアプリケーションフォルダに放りこめば良いのですが、JavaScripterとしてはそれぞれのバージョンを同時に使いたいので、一工夫します。まず、アプリケーションフォルダに適当にディレクトリを作ります(Chromesとする)。その中にさらにdev、beta、stableとさらにサブディレクトリを作ります。で、それぞれのディレクトリにGoogle Chrome.appを保存します。これで一応各バージョンを起動することはできますが、プロファイルが共有されているの同時起動できませんし、バージョン違いでプロファイルを共有すると色々と問題がでます(というか、起動できないこともある)。というわけで、プロファイルを分けましょう。Chromeのプロファイルを分けるには、起動オプションの--user-data-dirでプロファイルの場所を指定してあげればOKです。ただ、Macは起動オプションを指定するのが少々面倒で、こういうときにAppleScriptが活躍します。アプリケーションの中のユーティリティの中にAppleScriptエディタがあるはずなのでそれを起動し、以下のコードをコピペしてください。
do shell script "/Applications/Chromes/beta/Google\\ Chrome.app/Contents/MacOS/Google\\ Chrome --user-data-dir=/Users/$USER/Library/Application\\ Support/Google/ChromeBeta > /dev/null 2>&1 &"
パスは適宜調整してください。これを実行すると、beta版のChromeが立ち上がると思います。動くのを確認したら.appとして保存しましょう。保存場所はアプリケーションの中などにして、ファイルフォーマットをアプリケーションにしましょう。これで.appファイルとして保存されます(ただ、この方法で起動したChromeをDockに追加すると、追加されるのはChrome自体であってAppleScriptではないのでご注意を)。
Firefoxもバージョン違いを共存させる方法は大体同じで、Firefoxの場合は起動オプションの-p(profile)と同時起動のための--no-remoteをやはりAppleScriptにしておくとよいでしょう。
システム環境設定
(だいぶ脱線しましたが、)つづいてシステム環境設定まわりを見ていきます。まあ、好みが大きいところなので、大事なところだけ触れます。
まず、「言語とテキスト」で入力ソースを開き、「入力ソースのオプション」を「書類ごとに異なるものを使用」にしましょう。これでブラウザはIME ON、コンソールではOFFと使い分けできるようになります。これがないと死にます(これに1ヶ月くらい気がつかなかった…)。
あと、「キーボード」の「キーボード」の右下にある「修飾キー」で、Caps Lockの割り当てをControlなどにしておくのがオススメです。また「キーボードショートカット」のほうで「フルキーボードアクセス」を「すべてのコントロール」にしておくとタブキーでボタンにもフォーカスできるようになるので、これもオススメです(OSの設定ですが、多くのブラウザもそれに従います)。
あとは、アカウントでまず左下の鍵アイコンをクリックして鍵を解除し、自分のアカウント名のところでControl+クリック(もしくは右クリック)して詳細オプションを開きます。ここでターミナルのログインシェルを変更できます(私はzshに)。
裏:システム環境設定
Secretsの PrefPane( Secrets_[バージョン].zip)をダウンロードしてSecrets.prefPaneを実行するとシステム環境設定のその他の項目にSecretsが追加されます。このSecretsはいろんなアプリケーションの隠しオプションを設定できるツールで、画面キャプチャ時のファイルフォーマットをPNGなどに変更できたり、Finderで非表示属性のファイルを表示するようにできたりします。他にもいろいろありますが、自己責任なのでご注意を。
基本ツール
Finder
Finderの環境設定の「詳細」で、「すべてのファイル名拡張子を表示」にチェックを入れておきましょう。
Google IME
ATOKユーザーでないならGoogle 日本語入力を入れておくと良いです。設定は特に弄らなくても大丈夫だと思います。
KeyRemap4MacBook
英語キーボードだとIMEのON/OFFが面倒です。そこでKeyRemap4MacBookで左⌘を単独で押したときは半角英数モードに、右⌘を単独で押したときは日本語入力モードに切り替えるように設定します。設定方法はキーボード操作をもっと便利に! KeyRemap4MacBook オススメ設定からどうぞ。
エディタ
ベーシックなエディタとしてはCotEditorがオススメです。文章を書くときはCotを使っています。vimなひとはMacVimを入れておくとコンソールからも使えて便利です。他の候補はTextWranglerとかでしょうか。あと、JavaScripterとして、も気になるところですね。FirefoxなひとはXULで出来てるKomodo Editとかが気になるところでしょうか。
Windowsとの連携
Windowsも同時に使いたいので、以下にしてスムーズにMacとWindowsを使い分けるかが重要な課題です。
Synergy
まずは定番のSynergyです。私の場合、モニタを2個並べて右をWindows、左をMac miniにしていて、Windows側でマウスを画面左に持って行くとそのままモニタを抜けてマウスポインタがMac側に移動するようになっています。
設定方法などは複数の PC を手元で操作 「Synergy」を使おう! -Win&Mac 混合対応版- - livedoor ディレクターブログが参考になります。
ただ、キーボード周りが今一つで、私の環境だとシングルクオートとダブルクオートの入力がおかしくなるという問題があります。というかMacとWindowsのキーは結構違うので仕方ないところも大きいんですが…。
リモートデスクトップ
もうひとつの選択肢はMacからWindowsへのリモートデスクトップです。MicrosoftからRemote Desktop Connection Client 2というアプリが出ていて、これがかなり高性能です。特にKeyRemap4MacBookで設定したキーも認識してくれるのがポイントで、前述のIMEの切り替えがWindowsでも効きます。その他も色々とよきに計らってくれる感じで、かなり快適です。今のところMacbook Airからリモートデスクトップで使うことが多いですが、Mac miniもリモートデスクトップにしようかと検討中です。
コンソール
さて、いよいよ開発環境らしくCUI周りを見ていきます。なお、前述のとおり私は今までWindowsをメインでやっていたので、CUI環境にはかなり疎いです。突込みどころと思ったら是非突っ込んで頂けると助かります。
MacのデフォルトコンソールはTerminal.appですが、256color modeをサポートしてなかったりと機能的に物足りないので、MacのコンソールといえばiTermが定番のようです。特に最近はiTerm2がいい感じみたいです(ただ、iTerm2は自動アップデートの通知の度にフリーズするという現象が起きているので、自動アップデートには注意)。
パッケージマネージャ
MacのパッケージマネージャといえばMacPortsが定番ですが、最近はhomebrewが人気…なんですが、あえてMacPortsを選びました。
homebrewが人気な理由は、MacPortsはデフォルトで入っているパッケージを使わずにすべて自前でコンパイルするから重い、それに対してhomebrewはデフォルトをそのまま使うので軽いというのが主な理由(あと、homebrewのほうが新しいので各パッケージのバージョンも最新に近いのもメリット)みたいなんですが、MacPortsも昔はデフォルトのパッケージを使っていたけどMacのバージョンが変わったときに問題が出るから自前でコンパイルするように切り替えたという経緯があるそうです。というわけで、homebrewも同じ道を歩む可能性が高そうです。ただ、結局MacPortsもOSのバージョンが上がったときに問題が出ることがあるみたいで、環境の再構築に時間が短くて済むhomebrewのほうが良いかもしれません。どっちに転ぶかとりあえず様子見ということで、今回はMacPortsを選びました。
MacPortsのインストールはThe MacPorts Project -- Download & InstallationからSnow Leopard用のdmgを落としてインストールするだけです。
2011/10/20追記:その後、homebrewに切り替えました。homebrewのほうが使い勝手が断然良いので、もはやMacPortsに戻れない感じです。Lionへのアップデートもhomebrew自体は全く問題ないですね。
screen
今時はtmuxかtscreenらしく、MacPortsからインストールできるのはtmuxなので、tmuxにするという安直な判断に…。
sudo port install tmux
して、
cp /opt/local/share/doc/tmux/screen-keys.conf .tmux.conf
でscreen互換なキーバインドになります。ただ、zshのC-aはよく使うので、やはりC-tが無難だと思います。まあ具体的な設定はtmux.confでググって色々参考にしてみるのが良いと思います。
coreutils
折角iTerm2にtmuxなので、カラフルにしたいよねってことで
ls --color=auto
とかしてみるとそんなオプション対応してないと怒られます。代わりに-Gで色は着くのですが、配色がしっくりこないんですよ。というわけでcoreutilsをいれます。coreutilsはBSD系のOSでLinux系の基本コマンドを使えるようにするユーティリティ集です。ls以外にもLinuxとの互換性があがって、同じドットファイルを使いやすくなるのでオススメです。
sudo port install coreutils
ただ、coreutilsで入るコマンドにはprefixでgが付いています。なので、aliasで
alias ls='gls -v --color=auto'
のようにしています。aliasの一覧など詳しくはMint's log: Macportsのcoreutilsコマンド群はなんでも「g」から始まるをどうぞ。
vim
Mac OSXでのvim環境整理。.vimrcやらオヌヌメPlug inやらまとめ。 - ( ꒪⌓꒪) ゆるよろ日記を参考に、MacVimを使うようにします。
export EDITOR=/Applications/MacVim.app/Contents/MacOS/Vim alias vi='/Applications/MacVim.app/Contents/MacOS/Vim "$@"' alias vim='/Applications/MacVim.app/Contents/MacOS/Vim "$@"'
iterm,tmuxのおかげで256色で使うのに特に設定は必要ありません。あとはいい感じのcolorschemeを頂いてくればOKです。ただ、colorschemeはカラースキーマ — 名無しのvim使いとかにいっぱいあるけど、どれがいい感じかわからなくてどうしたものかと思ってたんですが、idのバリエーションが豊かな方がおすすめしていたir_blackに決めました。ir_blackはいろいろ凝ってて面白いですね。ただ、ちょっと凝り過ぎな感じもするので、様子見て h2u_black.vim に落ち着くかも。
ちなみに、その他のdotfileは主にid:cho45のdotfileを参考にさせていただいています。まだよくわかってないところが多いので自分のは公開してません。
git
sudo port install git-core
でインストールできる…はずですが、(おそらく)XCodeインストールしてない状態だとJavaがなんとかと言われてエラーで止まります。そのメッセージにURLが書いてあるとおり、Java Developer Package for Mac OS XというやつをAppleのサイト(要ログイン)からダウンロードしてインストールするとgitが入るようになると思います。
SpiderMonkey
sudo port install spidermonkey
でとりあえず入るけど、versionは1.7でFirefox2相当。古い…。まあ、jslint走らせるくらいなら困らないかな…。homebrewなら1.8.5(js -vの結果はJavaScript-C 1.8.0 pre-release 1 2007-10-03でした。Firefox3.5相当かな?)が入ります。ウラヤマシイ。
node.js
sudo port install nodejs
で(2011年1月1日時点で)v0.2.5が入ります(homebrewだとv0.2.6)。ただ、node.jsはバージョン管理したいので、naveを使うほうが良いです。
git clone git://github.com/isaacs/nave.git ~/.nave ./.nave/nave.sh install 0.2.6
インストールはこんな感じで。インストールしただけではパスが通ってなくて、
./.nave/nave.sh use 0.2.6
を呼ぶ必要があります。
これを毎回呼ぶのは面倒なので、上記を.profileとかに書く…でもいいけど、アプリごとにバージョンを管理するのがベターなので少し工夫してみます。
まず適当にnaveコマンド作ります。
ln -s ~/.nave/nave.sh bin/nave
.zshrcに次のように記述します。chpwd_functionsはcdしたときに実行する関数を入れておく配列です(めも - Zshでディレクトリを移動したときに色々やるを参考にしました)。
typeset -ga chpwd_functions function _naverc_check() { if [[ -f '.naverc' ]] ; then source '.naverc' fi } chpwd_functions+=_naverc_check
これで、cdしたときにそのディレクトリに.navercというファイルがあったらsource で読み込むようになるので、プロジェクトの中に
nave use 0.2.6
とだけ書いた.navercファイルを置いておけば、そのプロジェクトにcdすると適切なnodeがセットされるという塩梅になります。
これはRVMの仕組みと全く同じです。naveもそのうち同じような仕組みになってくれるかも。
RVM
ついでに RVM(Ruby Version Manager)もインストールしましょう。
bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )
でインストールは完了です。
rvm install ruby-1.9.2 rvm install ruby-1.8.7 rvm install jruby
といった感じで色んなバージョンのRubyを簡単にインストールでき、手軽に切り替えできます。前述の通り、.rvmrcファイルを用意すればプロジェクトごとに自動でバージョンを切り替えることもできます。
終わりに
だいぶ長くなってしまいましたが、いまのところこんな感じです。そういえば、あんまりJavaScriptしてないですね…。第2弾に期待ということで。。とにかくMacもUnixもほぼ素人なので、知らないことばかりなので調べ甲斐があって楽しいです。
「Google API Expert が解説する Closure Library プログラミングガイド」
日本初の Closure Library 本「Google API Expert が解説する Closure Library プログラミングガイド」発売です! - WebOS Goodies
Google API Expertが解説する Closure Libraryプログラミングガイド
- 作者: 伊藤千光
- 出版社/メーカー: インプレスジャパン
- 発売日: 2010/12/10
- メディア: 単行本(ソフトカバー)
- 購入: 4人 クリック: 179回
- この商品を含むブログ (14件) を見る
献本頂きました!
WebOS GoodiesのIto ChihiroさんによるClosure Libraryの解説本です。HTML5ガイドブック - 0xFFのシリーズ本になります。
Closure LibraryはGoogleが開発・提供しているクロスブラウザなJavaScriptライブラリです。jQueryなどに比べると実際に利用されているケースは少ないですが、なんといってもGoogleのプロダクトで実際に使われている点がポイントです。
JavaScriptのライブラリというとjQueryが強固な地位を築いていますが、jQueryはどちらかというと個人での開発に最適化されたライブラリであって、複数人での開発には自由過ぎてやりにくい面があります(例えばセレクタで対象の要素がないときにエラーにならないなど。自分が書くときは便利ですが、バグの温床になりがちです)。
最近はウェブアプリの開発が活発になりつつありますが、その流れで今後は複数人での大規模な開発が増えてくるはずです。そういったケースでは、Closure Libraryという選択肢は十分に現実的です。
さて、Closure Library プログラミングガイドですが、まさにウェブアプリの開発を目的にした解説書です。HTML5とかなんとか騒がれていますが結局のところウェブアプリを構成するのは地味なHTML/CSS/JavaScriptであり、Closure Libraryでその面倒な部分を解決する方法を教えてくれます。サーバーとの連携方法についても解説されているところも素敵です。
あと、なんといっても個人的に嬉しかったのはClosure Compilerの解説です。ちょうどClosure Compilerについて調べようと思っていたところだったのですごく参考になりました。
というわけで、Closure Library プログラミングガイドを(ついでにHTML5ガイドブックも)よろしくお願いします。