第一回 JetBrainsユーザーグループ #jbugj に行ってきた

とりあえずサマリーと感想。
うちに帰ったらちゃんとまとめますです。

オープニング

JetBrainsの日本の代理店からはやる気が感じられないよね。
やるきあんの？あるさ！

JB「全員に２か月分のライセンスやるよ！」
JB「抽選でライセンスもやるよ！」
JB「ショートカットのキーボードステッカーもやるよ！」


ライセンスはブログ書いた方から抽選で・・・。
ということで書いてます（欲丸出し）。

JetBrains製品群、ライセンス形態などの紹介 - @yusuke

Intelliｊ IDEA
JetBrainsの主要製品を搭載したIDE。
WebStorm/RubyMine/PyCharm
いまの自分が使えそうなものはSpring/Grails/JSF/HTML5/JSくらい？？

ライセンス形態について
業務開発はCommercialライセンス！

うちもWebStormは商用買ったしね・・・。
趣味でやるならOSSライセンスで楽しめるね
日本語で知りたいことはIntelliJ IDEA Advent Calendar をみるといいよ。


デモではライブコーディングでぱぱぱーっっとJavaのHelloWorldとかJUnitのテストを作ってくれました。
Mavenとの連携も楽ちんですね！
つかタイピングはええ・・・。

IntelliJのここが気持ちいい！(仮) 　あらため。普通IntelliJでしょ@mike_neck

なぜか精神状態が謎めいてらっしゃったが、情熱の伝わるLTでした。

クラスをつくるときや入力補完の候補がオート化されているのでスピーディー。
なんとなくコーディングのリズムを崩さないのが気持ちよさがあるね。
Testも楽ちん。

ってなお話。
あとGrooｖyかわいい的な話。

WebStormとRubyMineについて @sue445

全体的な紹介がありました。

JsTestDriverが意外と受けていた？かな？

実はJsTestDriverについてよくわからなかったのでその辺もっと訊きたかったなー。

あとAZusaar!!の中の人だったんですね。

Azusaar!!の動きをみながらATNDイベント検索のコードを書いてjavascriptコーディングを練習してたのでｷﾞｮｯっと驚いてしまったのは秘密です。

Rubyはようわからんのでまあいいや。

JetBrains発のJVM言語Kotlinの紹介 - @ngsw_taro

タイトルの通り、Kotlinの書き方、使いどころ、デモなどなど。

オブジェクト指向のJVM言語。

デモではBrainf*ckでイケメン仕様のコードのHello Worldしてくれました。

ScalaやGroovyの対比もあったんだけど勉強してないのでよさどころか、構文自体が追いきれなかったり。

もっと勉強せんとな・・・。

プラス、AppCodeのお話(@mike_neck)がありましたがObjective-Cは・・・ね？

いまさらながらnode.jsをつかってみた

いまさら

nodeさわってみたいなーと思いつつ、クライアントサイドアプリつくるのが手一杯だったのでずっと後回しにしてきた。さすがにサーバサイドも作りこまないと作れる範囲に限界がみえてきたのでなにかしらRESTで動くサーバーアプリを作ろうと思い立った。

目指すのはnode.js + mongoDBでRESTアプリケーション。これをクライアントサイドアプリで利用してJSONをコンテンツの中心としたいまどきサービスをつくってみたい。できればOAuthとかもできるといいなと思ったり。

nodeインストール（Win7)

参考にしたのはgihyoさんの記事

基礎から学ぶNode.js

書いてある通りにやればいいだけなのでここは割愛。
Nodeの公式HPからインストーラを落として終了。簡単。
gihyoさんの記事通りにサンプルのexample.jsを作って

node example.js

動いた。
Program Filesに入るのでPathも自動で通っている。
なんとなく開発環境つくってる感じがしないんだが、こんなんでいいのか？

expressをインストール

example.jsだとアプリケーションとは程遠いのでなにかしらフレームワークが必要。
ってことで有名どころなのでexpressを入れてみる。
インストールはnpm。Nodeのrpmだそうだ。
npmはnode本体と一緒にインストーラーからインストールされているので、
npmコマンドはそのまま通る。

npm --version

で一応確認。
1.1.65
って返ってきました。

んじゃexpressをインストール。

npm install -g express

GETやらなんやらがでてきて、見守る。expressのインストール終了。
-gはグローバルインストール。っていわれてもなんだかよくわからないが。
nodeのインストールディレクトリ配下にexpressをインストールするときは-gつけときゃいいのかな？
ほかのアプリがあって使いたい場合グローバルインストールしておく。今回はFWなのでとりあえずグローバルインストールをペシペシ。

expressはnodeアプリケーションのひな形をつくってくれるツールと考えればいいのかね。
HTML5でいうところのInitializrのカスタムビルドがツールになってnodeアプリを吐き出す、という印象。


expressインストールが終わったら適当なディレクトリにcdして、

express -e firstApp


これでfirstAppという名のEJSテンプレート(-e)を持ったnodeアプリの枠ができると。
さらに依存するモジュールをfirstAppに置くためにfirstAppに移動して

node install -d 

-dがなんなのかよくわからんが。

ほいでexpressのテンプレートから自動生成されたアプリが完成。
ふーん。簡単すぎてなにやったかよくわからん。

node app.js

で無事にexpressアプリが起動する。

調べにゃいかん

とりあえずexpressでアプリをつくっていくとして、よくわからずにできてしまったことを整理。意味を理解する課題リスト。

expressってなにもの？

とりあえず有名なので入れてみたけど、いまいちよさを実感してない。

最低限必要な構成はそろってるみたいだけど、なにができるの、できないの？

EJS？

EJSとかjadeとかテンプレートにはいろいろあるらしいけど、そもそもこれって何？
ejsはパッとみだとunderscore.jsの_.template()に近いようにみえる。

むしろ同じと考えるのが妥当なのかしら。

npmの使い方

依存関係を簡単に解決してくれるのはわかったので使い方を覚えないと。ツールはつかえてなんぼだ。

とりあえず今回はここまでメモ書き。

プログラマが理解されない理由

プログラマ？

プログラマは特殊な人間だというある種の誤解がある。
いや、誤解ではないのかもしれないが、とにかく理解されがたい部分が多いのは事実だ。

なんでこんなこと書こうと思ったか。
プログラマだけではシステムを作るのは難しいからである。
主にプログラマとやりとりを（ややうんざりと）しなければならない人たちがいる。最も多いのはデザイナではないだろうか。彼らとはうまくやっていかなくてはならない。分業し、きっぱりと作業境界を引き、責任の所在を明確にしたいと思うのがプログラマだと思う。

別にデザイナの頭が固いとか、プログラマが変人だということを言いたいわけではないのだが、なぜ「プログラマ」は特定の「人種」のような扱いを受けることが多いのか。自分なりに考えておきたい。

プログラマはプログラマ語を話す

最もコミュニケーションの障害になるのは、言葉の違いなんだと思う。同じ日本語なのにまるで行ったことのない土地の方言で会話させられているような気分になるんじゃないだろうか。

プログラマはなにも、嫌味でプログラマ語を話すわけではない。（普通は）

プログラマはその普段の風貌とは裏腹に、非常に繊細な思考をもっている。また流儀や思想を非常に重んじていて、それを共通認識としてもっているため、普通の日本語で表現するととってもとってもまどろっこしい、言いたいことより説明のほうが長くなってしまうような会話になってしまう。コード内の厳密でないコメントが嫌われるように、厳密さの低い説明を嫌う。

言語や技術は基礎的な論理の上に成り立っているので、うわべだけを説明してもそこに行き着くまでの前提を省略するほうが楽なのだ。

たとえば文字の"1"と数字の1の違いをいちいち明確に区別しながらアルゴリズムの説明をしようとすると、まず型とはなにか、オブジェクト指向とはなにか、プリミティブとはなにか、というプログラマなら誰しもわかっていることを意識して話さなくてはならない。これはやってられない。

結局、わかっていることは省略し、わからないことは厳密で思想的な表現が多いということになる。

もっというと、技術や能力が乏しいなどでプログラマ語を話せないプログラマに対して、多くのプログラマは苛立ちを覚える。話が通じない、話すまえに調べて来い、と思う。

嘘じゃないが本当じゃないことを言う

二値論理と三値論理の概念をコミュニケーションに持ち込みやすい。trueでもfalseでもない、「わからない」(=null)という状態が当然の世界で毎日過ごしている。絶対的にT/Fの場合の話も、nullがありえる話も特に区別せずにそのまま扱って話す。

しかも表現を厳密にすることが生活にしみこんでいるので、他者からすると余計にわかりにくい場合、認識の齟齬を発生しやすい場合が非常に多い。あるメールを送ったのにプログラマに届いていない場合に、「そのメールが送られていない」と「そのメールを受信していない」をプログラマは使い分ける。送られているかどうかはSMTPの問題で、受信していないのはそれ以降のネットワークやPOPなどの問題だから。「AがBにメールを送った」「BはAのメールを受信していない」は当然両立され、trueとfalseを両立できるということはそれぞれは別の事象であると考えて譲らない。「常識的に考えて同じことを指している」というのは通じない。

コードを書いているときが仕事をしているときではない

プログラミングという作業の性質上、作業量と成果がまったく関係しない。頑張れば頑張るほど作業が増えている場合なんて普通である。１時間まるまるかけて壮大なバグをコードに仕込むなんていうのは普通にある。

おそらくプログラマがもっとも仕事をしている時間というのは、画面をじっとみつめて、画面の裏側に焦点があっているときだ。そのときプログラマの頭のなかでアルゴリズムがめまぐるしく書かれては消え、消えては書かれ、数学計算や概念モデルがぐりぐりと動いている。（フロー状態というらしい）

プログラマはプログラムを書くのが仕事だ。だから書いている時間がプログラマがもっとも集中している。

これは明らかに間違いだということだ。

じっと画面を見つめているときに話しかけられるのはたまったもんじゃない。でも自然言語の場合は書いているときに考え、書いていないときは文法チェックや表現の精度、スペルチェックなどをしていたりするので、手を動かしていないと話しかけてもよさそうに見えてしまう。

プログラミングはまったく逆の作業だ。頭のなかで書いたものをファイルに書き出しているだけなので、そのときにスペルチェックなんかをしたりしている。そもそも、タイピングすることは会話することと同程度の負荷にしかならないので、書きながら会話をするのも別に苦じゃない。

プログラマ同士はタイピングしながら会話することが普通なのだが、プログラマ以外からみると「無礼」と感じる人も多いようだ。

嘘をつく

完全に、何のツッコミの余地もない、クリーンで、理路整然とした説明をプログラマ以外の人間にすることを、プログラマは半分以上あきらめている。

それでも伝えなければ仕事にならないので、なんとか噛み砕こうとするが、大体失敗する。

プログラマは「考え方を考える」ということにある程度の能力を割いて生きている。そこで成熟した「考え方」はプログラマのなかでは簡潔で完結したひとつの形として揺るがない。

なのであることを説明する場合、その「考え方」の外から説明するという意識に乏しく、むしろ説明するにはその考え方を理解してもらわなければならないとさえ考え、本題に入る前の説明がながったらしかったり、ロジックを間引きして説明しなければ伝わらないと感じ、最終的に嘘をつく。

与えるべき情報と実際の論理の整合性が取れると判断した場合、厳密さを捨ててインプットとアウトプットのみを説明し、間の部分は適当にしてしまうことが多い。プログラマ的にはそれは「本当は違う」程度なのだが、外からみると「嘘をついた」ことになる。

とりあえず今回はこれら４つの原因を考えてみた。

おそらく問題の根はもっと深いところにあるのだろうと思うので、また考えがまとまったらブログに起こしてみよう。

HTML5 WebWorkersでjQueryはロードできない

WebWorkersって？

HTML5、厳密にはW3Cが規定するものが本来の仕様だけど、ここでは一般的に注目されているその辺の「新規技術」全般を指すとして、いろいろな仕様追加がされていて、ブラウザベンダさんは皆様お忙しそうですね。

んで、だ。

JavaScriptでクライアントサイドアプリケーションを構築するなんてのが主流？というか流行りなようなわけで。RESTfulでグリグリ動く１ページサイトなんてのが作れたらかっこいいわけですよ。どうせ作るならいろいろ機能も盛り込みたいし、サーバサイドでやってるようなこともクライアント側で出来たらレスポンシビリティの高いインタフェースが作れる。でもユーザの操作を阻害するような重い処理は避けたい。そこで今までになかったバックプロセス、別スレッドでの処理実行があると便利ですよね、ってことでWebWorkersが策定されているわけだ。

若くて誠実な男もいいけど、裕福で落ち着いたナイスミドルも魅力。ってとこですな。バリバリ働く若い男にはUI系ライブラリを使った「見た目」の処理をバンバンやらせて、裏ではナイスミドルがジットリと職人仕事をする、と。

サポートされるスレッド数はブラウザ、バージョンによって異なるみたい。ただ、そもそもCPUのスレッド数を上回る同時実行なんてのはできるわけがないので、並行処理として有効なのは主プロセスも含めてせいぜい３プロセス程度なようです。一般的に普及しているPCの「平均的な」パワーとしてその程度と「言われている」らしい。ま、処理速度を上げるというよりは、別プロセスで実行されることでユーザ操作をロックしないのが目的ですし、おすし。

とりあえず使う。

バックプロセスの主な使い方、といっていいのかわからないけれど、WebWorkersのサンプルを探すとほとんどが大規模な数値計算、例えば3Dモデルの座標計算であったりとか、比較的単純な計算の膨大な繰り返し実行が見つかる。
まあサンプルは誰が見てもわかりやすいものがよいのでそれはそれでよい。使い方がわかれば後は煮るのも焼くのも生でいただくのもこちらの勝手である。

んで使ってみる。

まず裏で動くナイスミドルを別のjsファイルに書く。
back-process.js

onmessage = function(event) {
    // Workerが起動したときの引数はevent.data.*に渡される。形式はJSON。
    var msg = event.data.message;
    var res;
    var status = '';
    /*
      なにかしらの（重たい）処理を書く
    */
    // 仕事が終わったら主プロセスに処理結果を返す。
    postMessage(
        {
            'status': status,
            'result': res
        });
};

元気な若者から呼び出す。

// スレッドオブジェクトを作る。相対パスはHTMLがルート。
var worker = new Worker('js/back-process.js');

// 処理がもどってきたときのフロントの動き
worker.onmessage = function(event) {
    if(event.data.status){
        // jQueryとかつかって処理結果を画面に出す
    }
};
worker.postMessaage({message:'hogehoge'});

よしよし。動く。

バックプロセスで通信がしたい。

じゃあ次。
上のサンプルともいえないようなコードの通り、Ajaxのように非同期でイベント駆動な処理体系でスレッドを管理する。しかもChromeのデベロッパツールなんかでデバッグするとわかるけど、バックプロセスは独自の空間（？）で実行されるため、HTMLで呼び出しているｊｓのオブジェクトはそのままでは扱えない。しかもDOMやBOMにはアクセスしちゃらめーっってことなので、alert();すらできない。htmlでナイスミドルを呼び出していなくても動くこともあって、主プロセスとは完全に別の話とされているのだろう。
chromeのver21以降のデベロッパーツールではデバッグができるようになったけど、それ以前はフロント側で使わないのにHTMLで呼び出してブレークポイントセットとか必要だったしね。死ね。

それはさておき。
Ajaxぽい非同期実行で管理されるなら、リクエストを定期的に発行する処理をバックプロセスで実行できないか。もしくはユーザトリガーの処理のうちの長い通信を伴うもの、つまりはアップ／ダウンロードなんか、をバックプロセスにお任せしますので終わったら教えてー、みたいなつくりができるといいなと思うわけだ。

じゃあjQueryの$.ajax()でやってみますか！と。
本当はアップロードを作りたいけど、最初はとりあえずPOSTできればなんでもいい。
上記の通り、バックプロセスは独自空間で実行され、HTMLがロードしたjsは全く知らない人なので、とりあえずjQueryをナイスミドルの門下に入れないといけない。
これはimportScripts()でできる。

ナイスミドル門下にjQueryさんを入門させる。
back-process.js

importScripts('jQuery-min.js');

これだけ。
あとは$.ajax()のメソッドを書いて、さっきみたいにWebWorkerを起動すればOK。

ナイスミドルを通信っぽいバックプロセスに書き換える。
とりあえず適当なQueryStringを投げる感じのバックプロセスを作ってみる。 QueryStringはjQueryさんの$.param();でいきましょう。

importScripts('jQuery-min.js');

onmessage = function(event) {
    // Workerが起動したときの引数はevent.data.*に渡される。形式はJSON。
    var msg = event.data.message;
    var res;
    var sts = '';
    $.ajax({
        url:'http://example.com/'
        type:'post',
        data:$.param(msg),
        dataType:'xml',
        async: false,
        timeout:1000,
        success:
        function(response, status){
            sts = status;
            if(sts!='OK') {                
                res = null;
            } else {
                res = response;
            }
        }
    });
    // 主プロセスへ
    postMessage(
        {
            'status': sts,
            'result': res
        });
};

ようしこれでバックプロセスでの通信準備が整った！
まず一発実行して、うまくいったらsetInterval()で定期POSTだ。

颯爽とF5を押してみる。
・・・・？
・・・・あ・・れ・・・・・・？
POSTされない・・・・・だと・・・・・？

WebWorkersでjQueryはロードできない

なにごともトントン拍子で進むわけがないのがプログラミングであり、醍醐味だ。

「オラァ、わくわくしてきたぞ！」と隣のPGには聞こえないようにつぶやきながらF12を押します。

コンソールにはエラーメッセージ

～  DOM Exception

ほぅ。なるほどなるほど、よくわかりません。

DOMにさわっちゃいけないのはWebworkersの仕様。これは守ったぜ俺は。ｸｸｸ。などと余裕をかましていては意味がないのでどこでエラーになったかを見てみる。

jQueryのwindowオブジェクトを呼び出しているところ。

えっ。えっ？えっ・・・・。

WebWorkersってwindowに触れちゃだめよっていう仕様だったみたい。（ゝω・）ﾃﾍﾍﾟﾛ☆

調べてみたら既にその道は通ったひとがいたよ。

HTML Web Worker and Jquery Ajax call
回避策としてはXHRで書いてね。ってことだけど、そもそも俺がやりたかったのはアップロードなんだが、XHRでformのファイル投げるのってめんどくさいんですけど・・・？

ということでバックプロセスで通信したい場合に、DOM操作がなくてもjQueryは使えないよ、というお話しでした。ちなみにHTML5で新たに追加されたFormDataオブジェクト。DOMのformのように振舞ってくれるJavascriptオブジェクトなんだけど、こいつもバックプロセス側でnewするとExceptionが吐き出されました。


WebWorkersの使いどころとしては今のところは2つくらいしか考えられない。

1. 膨大な数値計算。グラフを書いたり、Canvasの描画のための座標計算とか。
2. ファイル操作。HTML5新機能として注目されているFile APIやFile System APIを利用してI/Oがある場合なんかは別スレッドで実行するべきと考えられる。

とりあえず無駄骨を折ったけど、骨は強くなった。かなぁ・・・。