Downloaded 184 times
![ダブルMVCの意味するところ
[GoGaRuCo 2013]
http://wazanova.jp/post/64057743910/mvc-gogaruco-2013](https://image.slidesharecdn.com/the-case-of-using-node-or-not-131026021415-phpapp02/75/Node-js-101-2048.jpg)
![[大図解]ピグライフはこう動いている](https://cdn.slidesharecdn.com/ss_thumbnails/pigglifegreexca-110817005057-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Node.js を選ぶとき 選ばないとき
- 1. Node.js を選ぶとき 選ばないとき 東京Node学園祭 2013 2013.10.26 Sapporo.js 佐藤竜之介(Ryunosuke SATO)
- 2. 提供 Community for peoplewho like JavaScript. Sapporo.js
- 3.
- 4. @tricknotes I am asoftware developer who love JavaScript and Ruby. http://tricknotes.hateblo.jp/
- 5.
- 6. I am acontributer of Ember.js
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15. Node.js を選ぶとき 選ばないとき 東京Node学園祭 2013 2013.10.26 Sapporo.js 佐藤竜之介(Ryunosuke SATO)
- 16. 今日の話 私が web アプリケーションを作るときに、 Node.js を選んだ場面、選ばなかった場面があります そのときの背景を交えつつ、 Node.js と Rails を比較し Node.js の適切な使い所について考察 します
- 17.
- 18. Node.js ライブラリには Ruby/ Rails の影響を 受けているものが多い * * * * Rails(generator)<-> Sinatra <-> Sprockets <-> Rails <-> yeoman Express Mincer Sails なので、有意義な比較ができそう
- 19. 対象者 * Node.js 以外の選択肢を知らない方 *Node.js をあまり使ったことがない方
- 20.
- 21. さて、みなさんが web ア プリケーションを作りはじ めるとき、どういう基準でそ の手段を選ぶでしょうか？
- 22.
- 23. Node.js での webアプリ ケーション開発について 確認してみましょう
- 24.
- 25. まずは素の状態で始めてみる var http =require('http'); http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello Worldn'); }).listen(1337, '127.0.0.1'); console.log('Server running at http://127.0.0.1:1337/'); $ curl http://localhost:1337 Hello World
- 26.
- 27.
- 28.
- 29. 例えば、 express を使ってみる varexpress = require('express'); var app = express(); app.get('/', function(req, res){ res.send('Hello World'); }); app.listen(3000);
- 30.
- 31.
- 32.
- 33. model 周りが貧弱 * 関連を扱えない *マイグレーションがない データベースとつなげればいいんじゃなくて、 ドメインロジックの管理も適切に行いたい...!! そこまで大きな手助けしてくれるフレームワークでは ないのでは...?
- 34.
- 35.
- 36.
- 37. 設定を毎回書くのは手間 grunt.loadNpmTasks('grunt-contrib-coffee'); grunt.initConfig({ coffee: { compile: { files:{ 'result.js': 'source.coffee' } } } });
- 38.
- 39.
- 40. Asset pipeline * CoffeeScriptや Sass のコンパイル * asset ファイルの minify, concat * digest hash の付与 Grunt 使ってやりたくなるようなことは、 デフォルトでやってくれる
- 41. Asset pipeline * application.js //=require jquery //= require underscore // //= require app application.js にリクエストを投げると、 すべて連結して取得できる ビルド時には minify + digest が付与される
- 42.
- 43. js のライブラリの管理 * jquery-rails *underscore-rails * moment-rails ... assets のパスが追加される、だけ 静的なファイルをリポジトリに含めなくてOK
- 44.
- 45.
- 46. その道に沿うように他のライブラリが成長していく Rails に乗る形で、まとまった単位の機能を提 供するライブラリが多い * 画像アップロード-> carrierwave * 認証管理 -> devise * OAuth provider -> doorkeeper やりたいことを実現するまでの手数が少ない
- 47.
- 48.
- 49. “Evented I/O forV8 javascript.” あくまで、非同期 IO の環境 web 開発以外でも活躍している
- 50.
- 51.
- 52. “Web development thatdoes’t hurt” web 開発のためのフレームワーク 7 年かけて環境が整備されてきている
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 59. NotHub * GitHub のイベントをリアルタイムに通知する ChromeExtension * 受け取るイベントを設定可能 * public なリポジトリ限定
- 60. よくある使い方 * ライブラリのバージョンアップを早く知りたい * 自分のリポジトリがstar されたのを知りたい * 興味があるハッカーの活動を知りたい
- 61.
- 62. 最初は Ruby で書き始めたが、 パフォーマンスでなくてNode.js で書き直した * GitHub の API をとにかく叩く必要があった * Ruby でマルチスレッド処理するのは意外と面倒 * Ruby で非同期書くのも手間
- 63.
- 64.
- 65. ビルドタスクは Rake 当時は Gruntの開発が始まったばかり Chrome Extension をパッケージしたい 今だと Grunt を使うかも
- 66.
- 67.
- 68. starseeker * GitHub のfollowings の star を daily メールでお知らせする web アプリ * リアルタイムじゃなくてアーカイブ
- 69. よくある使い方 * 良さそうなライブラリを知る手がかりに!! * 朝、仕事を始める前にhot なリポジトリをチェック
- 70.
- 71. * * * * Crawl したデータを MongoDBへ MongoDB なら Node.js と思って書き始めたが... ユーザ管理とか OAuth 周りが意外と面倒 Rails でやることに
- 72.
- 73. メール配信も、Rails がいい感じにフィットした * html/textの multipart メール * html とのコード共有
- 74.
- 75.
- 76.
- 77.
- 78. * DOM を扱うJavaScript と、ネットワーク、 ドメインロジックを扱う JavaScript は違う * 確かに言語は統一できるけど、思考の スイッチングコストは発生する
- 79.
- 80.
- 81. * サーバ側でもクライアント側でも使いたい ロジックはそこまでないのでは...? * utility的な関数群だと、ありえるかも * underscore.js など既存のライブラリ を使いましょう
- 82. 互換性のあるコードを維持するのは結構手間 関数定義の工夫 var exports =typeof(module) === 'undefined' ? this : module.exports; exports.method = function() { // ... };
- 83.
- 84.
- 85. * 採用するアーキテクチャに依存する * Node.jsを使っていてもある程度想定して おかないと、スケール出来ない設計になってしまう
- 86.
- 87.
- 88. * Node.js のAPI 自体は安定している * しかしバージョンアップしたら意外と動かなくなる (パフォーマンス劣化/メモリリークしていることも) * 拡張ライブラリは全く動かなくなる場合もある
- 89. ‘ サーバを API 化すれば、 JSONを返すだけのサーバで OK
- 90. * ドメインロジックの管理のしやすさは ライブラリに依存する * サーバのデータをすべてクライアントに送れない 場合が多々あるので、その制御が必要 *OAuth の認証トークン * 行動履歴 * ...
- 91.
- 92. リアルタイム通信の手段はたくさんある * WebSocket * Server-SentEvents * XHR polling * Socket.IO * Pusher ...
- 93.
- 94.
- 95.
- 96. Node.js は大変素晴らしいけど、 適切に選択する必要がある Node.js 以外の文化も踏まえた上で Node.jsを選択できると選択の幅が広がるのでは いざというときに移行する判断ができるのも大事
- 97. で、これは常に変わっていくので、 バランスを見極めながら選択するんですかねー * エコシステム * ライブラリ *自分の作ろうとしているもの 答えはない
- 98.
- 99.
- 100.
- 101.
- 102.