JavaScriptの救世主(?)

またまたお久しぶりです。はざまです。
先日、TypeScriptというものが発表されましたね。Microsoft製の型安全なJavaScriptのスーパーセットとのことですが、ネット上ではなんだか盛り上がってるようなので、自分も軽く触った所感でも記しておこうかと思います。

まず、シンタックスについてですが、現行のECMAScriptの要項を素直にそのまま実装した感じといったところでしょうか。型指定子は後置形式ですし、関数シグニチャもHaskellやScalaのような書き方になっています。そういえば、C++11ではこれと似たような関数シグニチャの書き方も出来ましたね。
次に互換性ですが、これは全く危惧する必要は無さそうです。というのも、Typescriptは一旦コンパイルしてしまえばプレーンJavaScriptに翻訳されるようですし、公式サイトにも既存のコード資産を有効活用できる旨がしっかり明記されています。ただ当然、それらのJavaScriptで記述されたコードはTypeScriptの恩恵を受けられないのが残念なところではありますが。（と思ったら、既存のJavaScriptのコードでも型情報を追加する方法はあるみたいですね。公式サイトにはNode.jsとjQueryの例が載っていました）
さていよいよ、TypeScriptの真髄とも言える機能に焦点を当てることにします。まず、名前からも推測できるように「型」が追加されたことで、プレーンJavaScriptでは実際に動かしてみるまで全く予想がつかなかった型不一致や型誤認によるありもしないプロパティーを参照するなどの凡ミスをコンパイル時に発見できるようになり、error-proofなコードが書きやすくなっています。さらに、型の追加による恩恵はこれだけにとどまらず、プレーンJavaScriptでは、コンテキストというものがほぼ存在せず、推測するべくもなかったコード補完機能がパワーアップして使いやすくなったり、随時変数の型が確認できるようになるなど生産性の向上が見込まれます。
また、TypeScriptでは(やはり見た目だけですが)クラスベースのオブジェクト指向が使えます。プレーンJavaScriptでも、ライブラリを使用すれば多少いびつながらもひと通りのOOPはできるので、必須とは言えないかもしれませんが、コードがすっきりするのでプログラマの意図をコードに載せやすくなると言えるでしょう。
その他にもモジュールやラムダ関数(JavaScriptには標準でクロージャーがついていますが、ここでいうラムダ関数は、どうやらほぼクロージャーの糖衣構文のようです。TypeScriptの開発者がC#も開発していたとのことなので、C#のラムダ関数を思い浮かべればイメージしやすいでしょう)もサポートされているようです。
そのへんについてはこれからいろいろいじってみて、後日改めて記事にすることにしましょうか。


まだまだ開発途上のTypeScript。いずれジェネリックプログラミングもサポートするとのことなので、JavaScriptといったらTypeScriptのことを指すことになる日が来るかもしれませんね。
でもその前に、IEでのHTML5やCSS3のサポート範囲を広げてくださいよ、Microsoftさん。


参照したサイト一覧：

• TypeScript公式サイト
• ITProのTypeScript紹介記事

※こちらの記事は、あくまで所感です。もしかしたら間違った記述も含まれているかもしれないので、100%鵜呑みにはしないでください。

Webアプリからローカルファイルへアクセスする(後編)

また多少間があいてしまいましたね。
今回は前回の続きでWebアプリからローカルファイルの内容を読み込む方法について考察したいと思います。

前回の記事ではWebアプリからローカルにファイルを保存する際に一旦サンドボックス化された領域に保存してから、それを改めて<a>要素のdownload属性を使用してデフォルトのダウンロードフォルダに保存するという回りくどい方法を紹介しました。
しかし、ローカルファイルから読み込む場合についてはもう少しスマートに解決する方法があります。それは、<input type="file">を使う方法です。input要素を使用すればファイルダイアログはブラウザーが勝手に表示してくれますし、結果も前回の記事で紹介したFilesystem APIでも使用できるFilelistというオブジェクトで取得できるので、そこからバイナリーデータやテキストデータを取り出すことは非常に容易に出来ます。

以下にjsdo.itを使用したデモを掲載しておきます。詳しいコードの書き方などはそちらを参考にしてください。

Webアプリからローカルファイルへアクセスする(前編)(FileSystem APIを使ってみる)

え〜皆様ご無沙汰しております。またも、以前の投稿から２週間前後もの日にちがあくことになってしまいました。いい加減このサボりぐせを何とかしたい…


今回は前回の記事で紹介したぴこぴこ・しーけんさーのアップデートを行ったので、その技術解説も兼ねて紹介することにしようと思います。
さて今回のアップデートで追加した機能とは、ずばり「ローカルファイルへの保存/からの復元」です。ネイティブアプリを開発したことがある方なら「なんだ、そんなことかよ」と思われるかもしれませんが、Webプラットフォームからローカルシステムへのアクセスには大きな障壁が未だ存在しているのです。
では、まずこの機能を実装するにあたってなにか使えそうなAPIは思いつくでしょうか？いえまあ、そんなことせずとも、ちょっとググればすぐ答えは見つかるんですがね…そう、今回私が目をつけたのは「Filesystem API」というものです。少し名前が不可解な気もしますが、これを使えばとりあえずネイティブアプリのようにローカルファイルに自由にアクセスできると誰もが思うでしょう。しかし、そうは問屋がおろしません。Filesystem APIの基礎についてはこちら
このFilesystem APIが扱えるFilesystemとは、通常のファイルシステムではなく、サンドボックス化された他の領域から隔絶されたほんの小さな領域だけなのです。通常のファイルシステムを巨大な氷山に例えるならば、そのほんの一角、ほんの一片のみにしかアクセスできないわけです。これは、ローカルディスク内にVirtual Boxで仮想OS用のディスクイメージを作成するように、小領域のCドライブ領域を新たに用意するというようなイメージで捉えるといいでしょう。
この制限によって今現在はFilesystem APIのみでファイルへの保存・からの復元を実装することは困難になっています。ならば、前述したような機能はどのようにして実装すればいいでしょうか？

今回ぴこぴこ・しーけんさーで実装するにあたって復元・オープンの方は、正直なところあまりFilesystem APIと関係ない実装方法になってしまったので後述するとして、まずは保存の方の実装法から見て行きましょう。
Webアプリからローカルシステムへ保存する場合、既述のFilesystem APIの仕様からユーザーがそのサンドボックス化されたFilesystemの場所を自ら探しだして二次利用できるようにすることが可能という前提があれば、Filesystem APIのみを使用することで晴れてこの問題は解決と相成ります。しかし、それではあまりにも不親切ですし、ユーザーエージェントによっては、Filesystem API固有のファイルシステム（以下、固有のファイルシステムと記述）全体をtarのようなアーカイブファイルとして管理し、通常のファイルシステムからは容易に個々のファイルにアクセスできないなどの事態が想定されるため、現状の解決策としては及第点以下でしょう。
ではどうするか。そこで上述のリンク先を細かく見ていくと下の方のコメント欄に

Is there a way for download and save the file in a whatever directory using a function? (jQuery)

Not as of yet. There's much to work out in the way of security when you allow read/write access to arbitrary directories. You can you(おそらくuseのtypo) a[download] to have the user download the file to the default Downloads folder.

というやりとりがあり、その直後に<a>要素のdownload属性の使い方に関するページヘのリンクが貼ってあります。今回はこの方法を採用しています。
具体的にはまず、Filesystem APIで固有のファイルシステムに一旦編集内容を保存後、そのファイルへのURLと曲のタイトル名をdownload属性に指定した<a>要素をユーザーに提示して、それをクリックしてもらうことでファイルのダウンロード=保存を完了するという方法です。
以下にjsdo.itを使用した例を提示しておきます。

上述の例は、「webkit」というベンダープレフィックスが付いているとおり、Chromeでしか動かないと思われます。Filesystem APIもGoogle以外あんまり実装してくれてないんですよね……
思った以上に長くなってしまったので、オープンの方の実装法はまた後編で紹介することにしましょう。では、さらば|彡ｻｯ

※参考程度に本文中で引用した英文の訳を提示しておきます。
「好きなディレクトリーにファイルを保存したりダウンロードしたりする関数ってある？(jQueryなんだけどさ)」
「いいや、今はないよ。あらゆるディレクトリーへの書き込み、からの読み込みを許可するにはセキュリティー上解決すべき問題が山積みだからねー。ただ、a[download]属性を使えばユーザーにデフォルトのダウンロードフォルダーへファイルをダウンロードしてもらえるよ。」

HTML5とJavaScriptでミュージックシーケンサー

またもや前回の投稿から間があいてしまいました、はざまです。
今回は、６月頃から開発に勤しんできたミュージックシーケンサーの紹介をしようと思います。とはいっても、基本的には以前こちらでお披露目した自作音ゲーの延長線上にある代物です。なお、今回も以前の音ゲー同様、Google Chrome以外では音が鳴らないと思います。予めご了承ください。(同じWebkitを使用しているSafariなら、ナイトリー、あるいは自分でビルドすれば鳴らせるようになるかもしれません)


さて、余計な前口上はこのくらいにして本題に入りましょう。

肝心のURLはこちら：http://picopico-seq.appspot.com
見た目とは裏腹にまだ、ピアノロールからの編集機能は実装していません。つまり、ピアノロール上部に見えるツールバーは(今のところ)ただの飾りです(笑)
そのため、音楽編集・制作にはMMLソースを直接いじる必要があります。まあサンプルやヘルプなどがあるので、詰まることはないとは思いますが・・・

今のところ、当初の目標の８割程度の機能は実装できていると思います。これから、GUIでの編集機能の追加やMML自体の機能追加など細かな機能向上を図る予定ですが、具体的にいつぐらいに可能になるかの目処はたっていません。(なにせ、途中１ヶ月ほどの空白期間ができてしまったぐらいですし・・・)
あまり期待せず、気長に待ってやってください。
今回はソース一式をGithubにupしてあるので、あるいはご自身で実装に挑戦してみるのもまた一興でしょう。(GithubのURLはこちら)
(ちなみにご自身でソースを改変する場合には、一部シェルスクリプトによる自動化を図っている部分があるためbashの入ったLinuxを使用することをおすすめします。おそらくCygwinでは動作しないと思います)


それでは、また会う日まで！

もはやWindowsはいらない子？

えー、みなさんこんにちは。随分とご無沙汰してしまいましたね。このブログでは、技術系のポストしか取り扱わないことに決めていたら、こんなに書くネタがなくて間が開いてしまう結果になってしまいました。

さて、今日取り扱うのはプログラミングとは関係ないのですが、Ubuntuで使えるノンリニア編集ソフトのkdenliveです。
実は私、先日初めてニコニコ動画に動画を投稿してみようと思い立ちまして、最近は主にUbuntuを使っているのですが、さすがに動画編集はWindowsじゃなきゃできないだろうと思い、フリーで使える動画編集ツールを探していたんですね。ニコニコ動画のWikiにも載っていたツールをいくつか試したんですが、残念ながらWindowsのノンリニア編集ソフトはどれもプロプライエタリなものばかりなんです。ニコ動のWikiによればAviUtilsやffmpegなどを使って地道に編集するみたいなんですが、いちいちあっち行ったりこっち行ったりするのは煩わしいな〜と思ったので、思い切ってUbuntuで使える動画編集ツールを探していくつか試してみました。その中でも、インターフェイスのわかりやすさ、機能の豊富さ、安定度などを総合的に鑑みてkdenliveが一番しっくりきたのでこいつを使って一つ動画を仕上げてみたのですが、これがとにかくすごい！
最初、画像の重ね方がわからずに一日ぐらい悩んでしまったんですが、使い方がわかってからは今までの苦労が嘘のように次々にフレームが埋まっていくんですよ。
おまけに最初はさすがに直接ニコ動で使える動画は出力できないだろうなと思っていたんですが、実際に試してみたらあっけないほど簡単にニコ動で使える動画が出力できてしまったので拍子抜けしました。これひとつで編集からエンコードまで全部できちゃうなんて・・・いやあ、いい時代になったものですね。

そんなわけでもうWindowsの寡占市場は終わりなのかなと思った今日このごろでした。

自作音ゲー(もどき)の技術解説(後編)

またもや少しご無沙汰してしまいました。今回はいよいよ核心部分となるWebAudioAPIの使い方について説明します。
まず、WebAudioAPIで音を鳴らすには２つの方法があります。

• HTML5のAudioタグのように別途用意した外部の音声ファイルを再生する方法
• 必要に応じて逐次波形を生成する方法

です。これらのうち、前者についてW3Cの規格では、あくまで「長さの短い効果音などの音声ファイルに対して適用すべき手法であり、普通の曲などについてはAudioタグを使用するべき」と書かれています。さらに、今回のゲームでこの方法を適用するには音色ごとにすべての音階の音声ファイルを用意せねばならないため、実用的ではないと判断し後者の手法を取ることにしました。

さて、WebAudioAPIで逐次波形を生成するに当たって気になる点がいくつかあります。
まず、パフォーマンスの問題です。WebAudioAPIを制御するのは当然JavaScriptです。ブラウザ上で動作する（多くの場合）インタプリタ言語に過ぎないJavaScriptで聞くに耐えるほどのリアルタイム波形生成が可能なのか？同様に速度面という意味では、GCによる遅延の発生も懸念点の一つになりますね。
さらに、JavaScriptでどの程度まで波形を操ることができるのかということも、本格的にWebAudioAPIを活用することを考えた場合に問題になるでしょう。

上から順に一つ一つ疑問点を解決して行きましょう。まず、パフォーマンスの問題ですが、現状まともにWebAudioAPIを実装しているユーザーエージェントがGoogle Chromeしかないため、はっきり言ってなんとも言えない状態です。今回実際に使用してみてChromeによる実装では特にパフォーマンスが問題になることはないだろうと感じたのですが、Webkit系のブラウザでChromeと双璧をなすSafariでは動作することが確認できていないのでパフォーマンスについて言及する意味がないと判断しています。もっとも、実際の音を鳴らす部分については(Chrome)の実装だとネイティブ側でバックグラウンドで行なっているようなので、バッファリングさえきちんと行われればパフォーマンスが問題になることはほぼないでしょう。
GCによる遅延の発生もChromeで使用する分には特に大きなグリッチも発生せず許容できる範囲でしょう。
さて、この中で一番問題になりそうな、どの程度インターフェースが充実しているのかについてですが、これについてはWebAudioAPIの仕組みを解説しながら考えるのが一番いいでしょう。
まず、WebAudioAPIでは一つ一つの処理をノードとして表します。ゲインや各種フィルターはこのノードして表され、これをつなぎ合わせることで必要な処理手順を示します。そして、これらを入力や出力をあらわすノードに接続することで音が鳴るわけです。
つまり、WebAudioAPIでできる事の種類は、このノードの種類とその接続方法の数で決まるという事です。現状、W3Cの規格には16種類のノードが規定されています。そして、これらの接続順序は特に規定されていません。ユーザーが完全に自由に組み合わせることができます。また、JavascriptNodeというものを使用すれば、ユーザー独自の処理をJavascriptで記述することができます。ゆえに、処理速度を度外視すればどんな処理も実行可能なわけです。


さて、そろそろ規格の話は終わりにして実際にWebAudioAPIを使う方法を見ていく事にしましょう。WebAudioAPIで音を鳴らすには前述のとおり、現状ふたとおりのアプローチがあります。前者については再生する音楽ファイルさえ準備できていれば例えばこんなコードで音を鳴らすことができます。

var context = new webkitAudioContext();//2016/9/1 追記: (new AudioContext();とも)

var source = context.createBufferSource();
var gain_node = context.createGain(); //2016/9/1 追記: API変更 var gain_node = context.createGainNode();  //音量変えるノード
    
gain_node.gain.value = 0.5;

source.connect(gain_node);
gain_node.connect(context.destination);   //destinationが最終的な出力

var request = new XMLHttpRequest();
var url = "path/to/music/file";

request.open("GET", url, true);
request.responseType = "arraybuffer";

request.onload = function() {
    //2016/9/1 追記: API変更により以下に変更 source.buffer = context.createBuffer(request.response, false); //ArrayBufferからバッファを作成　第２引数をtrueにするとモノラルに
    //source.noteOn(context.currentTime);   //指定した時間に再生する　もし指定した時間がcontext.currentTimeより小さい場合はすぐ再生される
    context.decodeAudioData(request.response, function(buffer){
        source.buffer = buffer;
        source.start(context.currentTime);  //指定した時間に再生する もし指定した時間がcontext.currentTimeより小さい場合はすぐ再生される
    }, function(){
    })
};

request.send();

audioタグを使う場合に比べてかなりすることが多くなっていますね。まあ、そこら辺は仕方ないところでしょう。
一方、リアルタイムに波形を生成する場合はこうなります。

//簡単なコード例を思案中

ここでは、個々の処理の意味は解説しません。いずれ、このゲームのシステムを元にしたシーケンサーを公開した時にでもより詳細な記事をあげようと思います。

自作音ゲー(もどき)の技術解説（前編）

二重の意味で間が開いてしまいましたが、先日jsdo.itで公開した音ゲー（もどき）の技術解説をしようと思います。まだ遊んだことがないという方は、ここに貼り付けておくのでどうぞご自分で一度遊んでみてください

簡易MMLパーサーによる音ゲーもどき(コーディングコンテスト Q vol.3エントリー用コード) - jsdo.it - share JavaScript, HTML5 and CSS

まず、今回のゲームで核となる機能は次のとおりです。

• 音楽データとパネル表示パターン生成に使うMMLパーサー
• 音ゲーゆえに音がならなければ話しにならないので、ブラウザー上で音を鳴らす（何らかの）手段
• ゲームとして成り立たせるためのフレームワーク

上記の内、今回特に苦労したのが前者２つでした。MMLパーサーの"パーサー"の部分については、以前別のゲームを制作した際に汎用性の高い部分をライブラリのような形で定義していたので、それにMML固有の文法や各種パラメータ抽出のセマンティックアクションを定義するだけでよかったのですが、いかんせん、MML自体昔の規格だからか読みづらい！(まあ、MIDIよりはアルファベットでかける分マシなんでしょうけど・・・ちょっと余談ですが、世の中は実に広く不思議なもので、この世には画像ファイルをバイナリで"解析"するバイナリアンという人たちがいます。なんでも、彼らはあの数字の羅列から"画像"をイメージすることが可能なんだとか。もしMIDIファイルのバイナリアンがいたら、数字の羅列から曲をイメージできたりするんですかね〜。そうか、MIDIのバイナリでアスキーアートを表現しつつ、MIDIシーケンサーにかけたらちゃんとした曲になるっていうファイルを作るのも面白そうかもな〜。まあ、きっと二番煎じだろうけど)
え〜、随分脱線してしまいましたが、本題に戻しましょう。MML自体が読みづらいのは構わないんですよ。人間が読みづらいものとプログラムにとってパースしにくいものは等価ではないので。(今でこそプログラミングを当たり前のようにしているので、MMLのソースを見ても特になんとも思わなくなりましたけど、耐性のない人が読んだら確実に暗号ですよね、あれって。試しに次のソースを読んでみてください。なんの曲だかわかりますか？

   @1 t110 l4 cdef edcr efga gfer
   crcr crcr l8 ccddeeff l4 edcr
   l2 {ccd}{dee} {ffr}e dc r4
   (t2) @0 l4 "ceg""ceg""ceg""ceg" "cfa""cfa""cfa""cfa"
   "dgb""dgb""dgb""dgb" "gb<d>""gb<d>""gb<d>""gb<d>"
   "ceg"r"ceg"r "gb<d>"r"gb<d>"r "ceg""dfa" "egb""fa<c>"
   "dfa<c>""g<cd>""eg<c>"r
   l2 "ceg""dfa" "egb""cdfa" "dfgb""ceg" l4 "<ceg<c"

正解は「カエルの歌」です。今回の主題のゲームのサンプル曲から引用したものなんですが、これが歌だとひと目でわかるでしょうか？わからないですよね・・・)

いかんいかん、また脱線してしまった。MMLパーサーを作るにあたってなやんだことは、文法の方言の多さなんですね。昔、（それこそBASICの時代）にMMLは隆盛を極めたようで色々亜種が存在するようです。このゲームを作り始めるまでMMLについて存在自体は知っていたものの、具体的にどのような規格なのかまでは知らなかったのでまず、どのような文法があるか調べその中からどの文法を採用するかに随分時間がかかってしまいました。
なんだか技術的な話ではなくなってきてしまったので次行きましょう。

次は音ゲーの命とも言える音なのですが、このゲームを作成するにあたってFlashは一切使わずに完成させたかったので選択肢は２つに絞られてしまいます。一つ目はMozillaが独自に実装しているAudio Data APIを使う方法、そしてもうひとつがW3Cの勧告にもあるWeb Audio APIを使う方法です。
今回の場合、なるべく早く完成させたかったのとドキュメントの充実性という観点から後者を選択することにしました。（まあ、ドキュメントが充実していると言っても実際はW3Cの勧告ドキュメントだったんですが。それでも、ちょっと検索しただけで実働デモ以上のプログラムが発見できたのは大きなプラスでしたね〜）
なんだか今回は余談だらけで長くなってしまったので、一旦ここで切りたいと思います。次回はWeb Audio APIの解説をします。それでは！(^O^)／

WebWorkerはJSの救世主となれるのか？

「JavaScriptはシングルスレッドしか扱えない」というのは、JavaScriptをいじったことがある人には馴染み深い定説でしょう。一見するとsetIntervalやsetTimeoutなどでマルチスレッドな作業がこなせるように見えるJSですが、実はあれはそれらの関数に渡したコールバックオブジェクトをキューに追加しておいて今実行している関数を抜けたらそのキューから次の関数を呼び出すという実装をしているだけなのです。

そんなJavaScriptですが、コーディングしてChromeやSafariなどでWebInspectorを開いてデバッグをしているとグローバルスコープに気になるオブジェクトを見かけることがあります。

Workerとあります。みなさんもC++などでマルチスレッドなプログラムを組んだり、GUIつきのプログラムを書いているときに「ワーカースレッド」という言葉を耳にしたことはないでしょうか。このWorkerがその「ワーカー」と同じなら、何やらマルチスレッドできそうな「匂い」を感じませんか？感じますよね？
そう、このWorkerコンストラクタこそ、我らがJavaScripterの救世主（になる予定）のマルチスレッド化の秘密兵器なのです。
さて、そんなWorkerオブジェクトですが、一体どうやって使うんでしょうか。結論から言ってしまうと次のように書けば使えます。

//main.js
var worker = new Worker("calc.js");    //Workerの処理を記述したファイルのパスを引数にコンストラクタを呼び出す

worker.onmessage = function(event){    //Workerからメッセージが返ってきた時の処理を設定する
   var data = event.data;
   data.forEach(function(num){
      write(num + ", ");
   });
};

var defs = {a_n : [0, 1], to : 20};
worker.postMessage(defs);               //Workerにデータを渡して処理を開始させる

//calc.js
onmessage = function(event){            //メインスレッドからデータを受け取って処理する
   var data = event.data, results = [data.a_n[0], data.a_n[1]];
   for(var i = 0; i < data.to; ++i){ //フィボナッチ数列を計算して配列に収める
      results.push(results[i] + results[i + 1]);
   }
   postMessage(results);                //処理した結果をメインスレッドに返す
};

WebWorkerを使うには最低限.jsファイルが２つ必要です。一つは、Workerを呼び出すメインのファイル（上記の例のmain.jsに当たります）、もうひとつはWorkerがすべき処理を記述したファイル（上記の例でのcalc.js）です。大まかな流れはコメントに書いてあるとおりなので、詳しい解説は不要でしょう。
しかし、その中でも注意すべき点が２つあります。まず、calc.js内のonmessage関数の定義の部分に注目してください。まるでグローバル変数のような定義をしていますが、これはWorkerのスコープとメインスレッドのスコープが分離しているためです。つまり、このonmessage変数はメインスレッドからは参照不可能なわけです。
またこれに伴って通常、ユーザーエージェントでJavaScriptを実行するとグローバルスコープにwindowやDOMなどのオブジェクトが定義されているものですが、Workerが動作するスコープにはこれらのオブジェクトは一切定義されていません。そのため、WorkerからDOM操作などはできません。これは、自らGUIつきのプログラムを書いたことがある人はよく解ると思いますが、好き勝手にGUIをいじるコードを書いていると複数のスレッドが同時にGUIをいじってしまって整合性に破綻をきたしてしまう場合があるので、メインスレッド以外からは一切GUIをいじれないようにするための措置です。
２つ目は、メインスレッドとWorkerでやり取りされるデータの形式です。この二者間のデータのやり取りは、JSON形式でやり取りされているようなので関数を含むオブジェクトをpostMessageに渡すと関数が失われてしまいます。このため、メソッドによる振る舞いの定義が必要なオブジェクトを扱う処理をWorkerでこなすには少し手を加える必要があります。

以上、自サイトで公開しているプログラム内でWebWorkerを使う機会があったので、備忘録も兼ねて記事にしてみました。



後日追記：もうちょっと実用的なサンプルをjsdo.itに公開しました。

おすすめのIDE

本格的な記事の投稿テストも兼ねて今回は、最近自分が愛用しているIDEを紹介したいと思います。
その名も「Cloud9 IDE」です。
「名は体をあらわす」とはよく言ったもので、このツールは名前の通りクラウド上で使えるIDEなのです。つまり、ブラウザ上でソースコードの編集からデバッグまでこなせてしまうわけです。（もっともbuiltinのデバッガーはNode.jsを使ったコードにしか使えませんけどね）
投稿のテストも兼ねて以下にCloud9IDEの紹介動画を貼りつけておきます。


このCloud9IDEはクラウド上で使うのが筋なんですが、実を言うとローカル環境で動かすことも出来ます。（ただし若干めんどくさいです。それに今のところWindowsじゃうまくいってません）
そこで今回は比較的簡単に構築できるUbuntu上での方法を軽く紹介したいと思います。まず、必要なものはソースコードを落とすのとセットアップのシェルスクリプトが使用するgitだけです。あと、できればNode.jsのパッケージ管理ソフトのnpmとそれを使うのに必要なcurlもインストールしておくべきなのですが、これらはたぶん、シェルスクリプトを起動したら勝手に入ると思います。（自分はその前にインストールしてあったのでわからない^^;）

必要なものをSynapticでインストールしたらまずは、ソースコードを落としてきます。

   $ git clone git://github.com/ajaxorg/cloud9.git

そうしたら次にカレントディレクトリをcloud9/binに移してcloud9.shというシェルスクリプトを起動します。

   $ cd cloud9/bin
   $ ./cloud9.sh

これだけでおしまいです。あとはしばらく待っていれば、勝手にスクリプトが必要なサブモジュールを拾ってきてくれてブラウザ上にCloud9IDEのウェルカムページを表示してくれるはずです。いや〜、実に簡単ですね。
うまく動かない場合はcloud9にカレントディレクトリを移して

   $ git submodule update --init --recursive

とかやるとうまく行くかも。なんて無責任な…

ちなみにcloud9.shにはいくつかオプションが渡せます。
まず-wはワークスペースとして使用するディレクトリを指定します。デフォルトではcloud9のルートディレクトリになっています。
-pはポート番号を指定します。デフォルトは3000です。
-dはデバッグモードでcloud9IDEを起動します。デバッグモードだとIDE自体のログがブラウザのコンソールに出力されます。
よく使いそうなものはこのくらいですかね。

正直なところCloud9IDEの日本語サポートは全くと言ってなされていません。事実、htmlエディター以外ではIMEからのインプットが処理されてないらしく、変換を確定するまでテキストが表示されません。
おまけに半角文字を使用するとカーソルの位置がおかしくなります^^;
さらには唯一IMEからのインプットが処理されているhtmlエディターでさえ変換中のテキストが明後日の方向に表示される始末…

ですが、Cloud9IDEが素晴らしいツールであることには変わりありません。Node.jsの開発のデファクトスタンダードになる可能性だって大いにあります。
さああなたも、Cloud9IDEでよいプログラミングライフを。

ブログ始めてみました

いやあ、春ですね〜。なにか新しいことを始めたくなる季節ですよね〜。
というわけでどうも、はざまと申します。以後お見知りおきを。

初回の投稿なので、軽く自己紹介でもしましょうか。
名前は最初に述べたのでいいとして、こちらのブログでは主にWeb（基本的にJavaScriptによるプログラミング。もしかしたらそれに関連してHTML5などの周辺技術も）とNative（ネイティブ環境で動作するプログラミング言語。主にC++）をテーマにこれら言語の仕様やこれらの言語でプログラミングしていて思ったこと、つまづいたこと、使ってみて自分が素晴らしいと思った技術のメモ、別途公開している自作プログラムの解説、製作日記などを綴っていこうと思っています。
よろしくお願いしますm(__)m