東京node学園祭2013行ってきました
東京node学園祭2013行ってきました
■基調講演
印象に残ったのは
・strongloopのように優秀なモジュールを組み合わせた環境を用意したりするのもkernelとdebianみたいな関係でnodeコミュニティとしては問題ないと。
・小さなコアを維持する
・モジュール機構は完成している
・stream2は後方互換性を維持
・node.jsは後方互換性を重視する
特に後方互換性を重視する姿勢はプロダクションレベルのソフトをつくる基準にたっしているとおもう。
■Grunt, yeoman, bower
YOおじさんがテンプレートから自動生成して開発を助けてくれますよという話で
generator-generatorつかえば自動生成機能も簡単に作れますよという感じでした
gruntやbowerはそこそこ使われてるけどyeomanはまだあまり使われてないみたい。
自分はyeoman使ってないけれどrailsみたいなイメージでした
■JSXネタ
前半は@kazuhoさんの話でした
DeNAでたくさん使われているかといえばそうではなくて新規プロジェクトで条件が合えば使うみたいな感じでした。
後半は@wasabizさんの話でした
コンパイラを担当されているようで今後C#のasync-waitの構文をいれてみるとかそういう話をしてました
JSの問題点である、オブジェクト指向言語、最適化、コールバック地獄の解決をやっているようで
JSX使ったゲームフレームワークとかも公開してくれると使いやすいかもなぁとおもったりしたのですがその辺どうなんだろうなぁ
普及するかしないかはフレームワークがあるかどうかにかかってるとおもうし。
（ノウハウは金になるから公開しないだろうなぁとおもいつつ。）
アフィン変換で行列をあつかっているスライドがあったけど、JSで行列の速度まともにでるならつかってみたいかなと。
この辺、自分で実装してテストしたのだけど普通に実装するとメソッド呼び出しでかなり時間が取られることがわかってるのでインライン展開使いたいなぁ。。。
■ES6で変わるNode.jsプログラミング
プリミティブな型の整理が言語として行われているという話でした
・generatorとpromise
・クラス
・イミュータブルな値
・変数スコープのブロック化
・引数や配列など基本的なところ
JSの構文がついに整理された感じです
■ロボットの外部脳としてのnode.js
Bluetoothによるシリアル通信でセンサーからのデータをうけとりnode.jsで制御するという話だった。
・組み込みは通常コンパイルしてROM焼き込みという手順をするのだがjavascriptでは手直しして再起動という手順ができるので楽。
・フィジカルとネットワーク（スマートフォンなど）のつなぎ込みはお金の匂いがします。
（実際センサーからのデータ使ってzabbixやfluentdと組み合わせたりスマートフォンでモニタリングしたりいろいろできそう）
■総括
nodeはフレームワークとか使い道とか多様性（WEBに限らない）が出てきていて
一つのプラットフォームになりつつあるなぁという感じです
■以下資料
録画
http://www.youtube.com/playlist?list=PLuLCOB9HcrT0ZeWiyddLVNR93QdGmtW57
基調講演
Grunt, yeoman, bower
https://speakerdeck.com/yosuke_furukawa/yeoman-grunt-bower
Rendr入門
http://www.slideshare.net/mshk/rendr
JSXネタ
http://www.slideshare.net/kazuho/jsx-oct-26-2013
http://www.slideshare.net/yuichinishiwaki/jsx-generatorimpl
Node.jsを選ぶとき,選ばないとき
http://www.slideshare.net/tricknotes/nodejs-27589695
WebRTCを始めよう
http://www.slideshare.net/mganeko/2013-web-rtcnode
#台風の開催ポリシーがしっかりしてたのでとても良いと思いました
運営サンGJ
懇親会のピザパーティもアドリブだったのによかったです
node.jsのセキュリティ
nodeの脆弱性について
http://www.ustream.tv/recorded/40193490
node学園のLTでコレをみて思い出したのだけれどHTTPの脆弱性を直してもバックエンドが遅い場合
nodeの場合いくらでもリクエストを受けてしまってバックエンドのリクエストをキューにためてしまう場合に結局メモリ不足で落ちてしまう
それに対する一つの解として以前qiitaに記事を書いた↓
一つのセッションあたりの秒間リクエスト数がキャパシティプランニングから導き出せていれば秒間あたりのリクエスト数を絞ることで回避できるかなと。
