WebSocket

FacebookのReactをいい感じに使えるReagent

今回、長野県のペンションマウンテンパパというところに開発合宿に来ています。

Python mini hack-a-thon 雪山合宿 2015

今、公私ともにClojureでいろいろなことをやっていて、フロントエンド部分もClojureScriptでやっていこうかなと思っています。(Google closureライブラリではないです)

そんな中、FacebookのReact をClojureでラッピングしたライブラリで有名なものに om がありました。

他にも reagent というライブラリが存在しています。わかりやすさレベルでいうと、reagentに軍配があがるような気がします。

ということで、このreagentの紹介をします。

reagent – A minimalistic ClojureScript interface to React.js

この記事の対象者前提

  • Clojure がなんとなく読めること、興味があること
  • PCにleiningen(というClojureのビルドツール)がインストールされていること、使い方がわかること

まずはプロジェクト作成

leiningenは、テンプレートからプロジェクトファイル一式を作る機能があります。

これを使うことで、ライブラリの導入などの手間が省けます。

$ lein new reagent [プロジェクト名]

ライブラリなどのダウンロードと起動

reagentプロジェクトのディレクトリが生成されるので、黒い画面で、該当ディレクトリに移動します。

まずは、何もファイルの変更をしないで、デバッグが簡単なモードで起動してみましょう。

$ cd [プロジェクト名]
$ lein figwheel

実行すると下記のようにメッセージがずらずらと出ます。

JavaScriptが生成されたのがわかります。

Figwheel: focusing on build-id 'app'
Compiling ClojureScript.
Figwheel: Starting server at http://localhost:3449
Figwheel: Serving files from '(dev-resources|resources)/public'
Compiling "resources/public/js/app.js" from ("src/cljs" "env/dev/cljs")...
Successfully compiled "resources/public/js/app.js" in 19.221 seconds.
notifying browser that file changed:  /js/app.js
notifying browser that file changed:  /js/out/goog/deps.js
notifying browser that file changed:  /js/out/reagenttest1/core.js
notifying browser that file changed:  /js/out/reagenttest1/dev.js

どうやら、サーバも起動したぽいので、http://localhost:3449 をブラウザで開きます。

ブラウザで何かサンプルページが表示されれば準備は完了です。

IDEAで編集を楽にする

ClojureScriptを編集するのは、各自エディタを使えばいいのですが、僕はCursive というIntelliJ IDEAのプラグインを使っています。

括弧の閉じ忘れや、ライブラリの参照、宣言していない値の利用ミスみたいなことがなくなるので便利です。

reagentプロジェクトテンプレートについて

先ほどのプロジェクト作成を行うと、いくつかのファイルやディレクトリが作成されます。

これらのうち、今回大事なのは以下の2つです。他にもいろいろ入っていますが、今は無視でOK。

  • project.clj -> 依存しているライブラリなどが書かれている
  • src/reagenttest1/core.cljs -> JavaScriptとして書き出されるロジックなどを書く

reagentのプロジェクトテンプレートの便利なところ

reagentプロジェクトテンプレートを使うと、下記のようなメリットがあります。

  • ルーティングのライブラリが組み込まれている
  • ページ遷移の履歴がサポートされている
  • ちょっとしたサンプルページが2ページほど用意されている

小さなコンポーネントを作ってみる

では、早速ちょっと小さなコンポーネントを作りつつ、リアクティブ的な挙動を体験してみましょう。

まずはコンポーネント定義

src/reagenttest1/core.cljs に下記を追加していきます

(def test-val (atom ""))

これは、reagent側でアプリケーションの状態を保持しておくための入れ物です。

Clojureは基本イミュータブルな値を使ってプログラムを組んでいきますが、atomというものを使って状態を保持しています。

続いてコンポーネント本体を書きます。

src/reagenttest1/core.cljs に下記を追加します

(defn test-component []
  (let [val (cond
              (= @test-val "") "[空です]"
              :else "[OKです]")]
    (js/console.log "test-val:" @test-val)
    [:div
     [:input {:type      "text"
              :value     @test-val
              :on-change #(reset! test-val (-> % .-target .-value))}]
     [:p "test-valの中身:" val "(" @test-val ")"]]))

フォームの内容が空だと「空です」と表示し、何かが入力されると「OKです」と出るものを作ります。

ポイントは、divタグやフォームなどをClojureのデータ構造で書いてある点です。これがVirtualDOMとして機能します。

コンポーネントはこれで終わりです。

続いてページの作成

表示するページを書きます。

src/reagenttest1/core.cljs に下記を追加します

(defn my-page []
  [:div
   [:h1 "Reagentのテスト"]
   [test-component]])

見出しと、コンポーネントがあるのみのページです。

test-componentという先ほど定義したコンポーネントを呼び出しています。

ルーティングの定義

最後にURLとページを結びつけるためにルーティングを定義します。

http://localhost:3449/#/my-page を開くとmy-pageページが開くようにします。

src/reagenttest1/core.cljs に下記を追加します

(secretary/defroute "/my-page" []
                    (session/put! :current-page #'my-page))

アクセスしてみる

以上で、コンポーネント一式とそれを表示するページが完成しました。

http://localhost:3449/#/my-page

フォームに入力すると、その場で、内容が変わっていくのがわかると思います。

内部的にはDOMの監視とHTMLの書き換えを行っていると思いますが、コード的には「test-val」という変数を書き換えただけで画面の状態が変化しています。

反響などあれば、続編など書きます~

Read More

第1回&第2回 [Play部屋]Playはじめて&もくもく会を行いました

Play frameworkの手を動かす系の勉強会である「[Play部屋]Playはじめて&もくもく会」を開催しています。Play frameworkは、JavaもしくはScalaで開発が可能な、Webアプリケーションフレームワークです。WebSocketなどをはじめとする先進的なウェブの実装にも適しています。

第1回目を行った自体でブログエントリを書けばよかったんですが、ぐずぐずしている間に第2回も終わってしまいました。。

第1回目の話

第1回目は、2013年01月15日(火) 19時00分 – 22時00分に行いました。

-Play部屋- Play 2.0 Javaはじめて&もくもく会 – 日本Playframeworkユーザー会

実はこの日は結構急に決まったので、開催告知もあまり開催日まで時間がない感じで行ったのですが、多くの方に参加していただき、20人の方が集まりました。

当初募集時は「Play 2.0 Javaはじめて&もくもく会」という名称だったんですが、テーブル担当者が名乗り出ていただいたおかげで、JavaとScalaの両方のサポートが可能になりました。

20人というと、それほど多くないじゃないかと思われるかもしれませんが、そもそも会場となったコワーキングスペース茅場町 Co-Edoのハンズオン系の机有りな状態が25人くらいがたぶんMaxな感じなので、結構ぎゅうぎゅうな感じです。

当日は、この会の特色である初心者の人も積極的にPlay frameworkを試せるようにしていくという点を踏まえて、Play 2.0 Javaのはじめてテーブルを僕が、Play 2.0 Scalaのはじめてテーブルを小原さんが担当する感じにしました。

また、別途もくもくテーブルも用意してあり、ベテランな方々はここでもくもくとマイプロジェクトをしたり、談笑したりするという感じになっています。

shinya31さんによる当日のまとめがあります!

2013/01/15 Play 2.0 Javaはじめて&もくもく会 #play_ja

あと、ブログ記事も!

[勉強会][Playframework][Java]Play 2.0 Javaはじめて&もくもく会 に参加してきた #playbeya #play_ja

第2回目の話

続いて、第2回を2013年01月24日(木) 19時00分 – 22時00分に行いました。参加者は16名くらい。

[Play部屋] 第2回 Play 2.0 はじめて&もくもく会

今回も、Play 2.0のJava、Scalaのはじめてテーブルを僕と小原さんで担当したわけですが、今回は、はじめてその後テーブルというのも用意しました。

はじめてその後テーブルというのは、Playのチュートリアルはやってしまったけど、その後どうしようかという感じの方向けのもので、テーマは毎回変えていく予定です。

今回のはじめてその後テーブルのテーマはWebSocketということに決めていまして、参加者は、WebSocketのサンプルコードをいじって動かしたり、改造してちょっと違うアプリに仕立てたりと、取り組んでいました。

今後もはじめてのその後シリーズはやっていこうと思います。 次はテストとかにしようかなとか考えています。

第2回もshinya31さんによる当日のまとめがあります!

2013/01/24 [Play部屋] 第2回 Play 2.0 はじめて&もくもく会 #play_ja #coedo #playbeya

また、レポートも!

[勉強会][Playframework][Java]第2回 Play 2.0 Javaはじめて&もくもく会 に参加してきた #play_ja #coedo #playbeya

というわけで、「Play部屋」を通じてPlay frameworkを広めていけたらと思います。 よろしくお願いします!

※あと、お手伝いいただける方も積極的に募集しています! 参加料も会場代1000円は必要なものの、それ以外はボランティア的な感じで運営していますので、ご協力いただけると助かります! @kara_dまでお気軽に!!

Read More

WebSocketアプリケーションを作るのにPlay frameworkをつかおう

この記事は、HTML5 Advent Calendar 2012向けに書いています。

HTML5とその周辺技術などを含んでいるアドベントカレンダーということで、WebSocketのバックエンド側の話について書いてみます。 WebSocketはフロントエンド側はおそらくはJavaScript(対応していないブラウザはFlashが橋渡しをするライブラリを使用するかもしれませんが)で書く事になるでしょう。

WebSocketのバックエンド側は、というとNode.jsで書くというのが認識としては広く知られているところではないでしょうか。 しかし、実際WebSocketのサーバーとして機能するものは大量に存在しており、Wikipediaをみただけでも相当数存在することがわかります。

今回は、その中でもオススメなサーバー側フレームワークとしてPlay frameworkを、WebSocketアプリケーション構築のメリット中心に紹介したいと思います。

Play frameworkのサイト

Play frameworkって何ですか?

Play framework(以下Play)は、「一言で言うと、型安全なRails」みたいな形容で表現されることがあります。 Playのバージョンが1の頃は、Javaベースで書かれており、確かにそのような表現がふさわしかったと言えますが、バージョン2以降はScalaで書き直され、それに留まらないようなフレームワークになっていきつつあります。1.xからずっと使ってきたので、2の変化には戸惑いました。 現状、ScalaとJavaで開発が可能な、Webアプリケーションフレームワークとして知られています。

日本では有志による翻訳も行われており、

Play framework 日本語訳サイト

があります。

Playの特徴としては、

  • 全てをコンパイルし、型安全
  • 非同期も同期も得意
  • RESTful的な方向性

が掲げられていますが、

個人的には、

  • Rails以降のMVC型Webアプリケーションフレームワークの作法に則っており、
  • なおかつ、WebSocketとかの非同期系の処理も得意で、
  • 非常に高速に動作し(ただし、コンパイル自体はすこし時間がかかる)、
  • ビルドシステムや本番で使えるWebサーバーがデフォルトで内蔵されていて、
  • 全てがプラガブルな(Play本体自体もビルドシステムのプラグイン)、
  • JavaとScala(とXtend)両方で開発(混ぜられる!!)出来、
  • 静的型付けな言語の魅力を活かしたIDEによる強力な開発サポートを受ける事ができる

という点で気に入っているWebアプリケーションフレームワークです。

Playはよく動作速度に関して、Node.jsと比較されたりします。 両方とも、ノンブロッキングI/O(っていうモデルがあるんです)を採用している点や、WebSocketを扱える点など共通点も多いため、仕方がないのですが、今回は比較はしません。

理由は僕がPlayの魅力のほうを語りたいためと、Node.jsについて語れるほどの知識がないためです。

ということで、WebSocketアプリケーションをPlayで書くメリットについて。

Playおすすめの理由その1

Playは、Webサーバであると同時に、MVCフレームワークである

Playには内蔵サーバーがあり、Playのアプリケーション自体がサーバーとして起動します。これは、テスト用のビルトインサーバーというわけではなく、実際に本番運用も可能な高速なサーバーです。

加えて、Playは、Rails以降のMVC型Webアプリケーションフレームワークと同じように、モデル、ビュー、コントローラーの役割が分かれているタイプのフレームワークで、フォルダ構造もそうなっています。これ系のWebアプリケーションフレームワークをやってきた方なら直感的にどこになにを書くか理解することができるでしょう。

他のフレームワーク同様、テストに関するサポートも手厚く、ユニットテストやファンクショナルテスト、そしてSelenium WebDriverを利用したWebテストが搭載されています。

また、Java版であれば、Ebean ORMによるデータベースアクセス機能、Scala版であればAnorm他様々なデータベースへのアクセス機能が用意されています。

つまり、Playは、従来型のWebアプリケーションを構築する土台として、機能します。

加えて、Playは、WebのサービスにおけるAPIアプリケーションとしても使えるほどの優れたパフォーマンスを発揮します。 例えば、Kloutという世界的に有名なサービスがありますが、これのAPIにPlayが使われていたりします。

Scaling the Klout API with Scala, Akka, and Play « The Official Klout Blog | Klout

そして、重要なのがここからなのですが、これら既にある程度できあがっている作りやすい土台の上に、WebSocketアプリケーションを構築することが出来るのです。

Playおすすめの理由その2

WebSocketとWebアプリケーションの定義がシームレスに行える

ここからは少し実装寄りの話になります。内容としては、Play Javaを例に挙げます。理由はいろいろな事情からPlay Javaが気に入っているからです。 通常Play Javaでは、基本的にはコントローラーのメソッドを1つのURLに割り当てる事が出来ます。 たとえば、こんな風に書きます。

public static Result index() {
    // もろもろの処理を書く
    return ok(index.render());
}

で、これをRoutesの定義ファイルみたいなところに

GET     /index        controllers.Application.index()

こんな風に書くと、「/index」にてアクセスしたときにindex()メソッドが呼ばれるという仕組みになります。 Playではこんな風にルーティングを定義します。 ここまでは、まあだいたいそんな感じだよねってとこかと思います。

続いてWebSocketの場合はどう書くでしょうか。 WebSocketは、フロント側からは独自のプロトコル「ws://」「wss://」でアクセスされます。 コントローラーに書くコードは、下記コードのようになります。

public static WebSocket<JsonNode> websocket() {
  return new WebSocket<JsonNode>() {
    // もろもろの処理を書く
  }
}

さぞや違う書き方かと思えば、ほとんど通常のWebページとおなじだということがわかります。 Result型ではなく、WebSocket<A>型を返すという以外はほぼ同じです。

もちろん「もろもろの処理を書く」の中には、WebSocketで使われる各種メソッドを定義する必要がありますが、定義すればいいものは、開始時に実行されるonReady()、何らかのメッセージを受信した際に実行されるonMessage()、接続を閉じた時に行われるonClose()の3つを定義さえすれば使えます。

これらイベント処理には、Akkaと呼ばれるフレームワークが使われています。

Akkaのサイト

上記コードは、Routesの定義として、

GET     /websocket    controllers.Application.websocket()

こんな風に定義をした上で、ビュー側から

@routes.Application.websocket().webSocketURL(request)

こう呼び出すと、

ws://localhost:9000/websocket

こういうURLとして出力されます。また、wssプロトコルとしてURLを出力したい場合は、

@routes.Application.websocket().webSocketURL(request, true)

と記述すると

wss://localhost:9000/websocket

のようにURLが出力されます。

つまりは、通常のWebアプリケーションを書く感覚でWebSocketアプリが作れちゃうわけです。 加えてフレームワークで使うモデルには当然ダイレクトにアクセスできますし、WebSocketの監視画面なんかもWebSocketとWebアプリケーションを分けて作る場合に比べるとはるかに楽に実装できるであろうことが推測されます。

実はPlay 1.xの頃にもWebSocketは扱えたのですが、WebSocketControllerという専用のコントローラーを使う必要がありました。 その部分もPlay 2.0以降格段に扱いやすくなっています。

是非冬休みにPlay frameworkを試してみてください!

Read More