サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Wikipedia
jxck.tumblr.com
Node.js を学んだり、 2013 年に Go を学んだりしている中で、色々思うことについてつらつらと。 見直しもせずに書く。 ここでは面倒なので、それを新しいパラダイムと言うけど、 新しいパラダイムが出てきて、例えばそれがバズったりとかすると、 色々な人が入ってきて ML で発言する。 Node.js が出来てきた時、それがネットワーク・サーバ系を意識していたことにより、対比として今までそれをやっていた、人々が色々な知見を披露した。 別に Node.js 自体が使い物になるかどうかは別として、 そういう人たちの話が聞けることも、 Node.js を見ている中で得られる大事なものだったと思う。 従来の、スレッドモデルにはどういう問題があったか プリフォークの本質はなんだったのか コールバックは何をもたらすのか シングルスレッドで何が嬉しいか JS が選ばれたことの意味はなんなのか Ja
小ネタなので、ひさびさにこっちに。 Google の検索結果の期間指定ができるのは結構前からですが、 この期間は 1時間24時間1週間1ヶ月1年の選択肢しかない。 「欲しいのは 3ヶ月なんだよ!!」 と思うのは自分だけでしょうか? (1ヶ月は近いし、1年は長い) で、それをやるには検索結果の URL に "&tbs=qdr:m3"という文字列をつけるだけでできます。 ってのはあまり知られてないようなので。 詳しく言うと &tbs=qdrの後ろに 1時間 = :h24時間 = :d1週間 = :w1ヶ月 = :m1年 = :yという感じ、その後ろに数字を加えることで :y2 (2年以内) みたいに調整できます。 3ヶ月以内、をブックマークレットにするなら javascript:location.href += '&tbs=qdr:m3'小ネタでした。
とはいっても、今 HTTP2.0 を追うことは、 SPDY を追うことと同義な部分が多い。 メモっとく。 2012年1月24日 Mark Nottingham 氏が、 IETF の HTTPbis の ML に 「新しいバージョンのHTTPについての作業を開始する機が熟したのではないか」。 と投稿。 http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0098.html HTTP 2.0の議論を始めるための新たな憲章案も付記。互換性を保たない方針を打ち出す。 http://www.publickey1.jp/blog/12/http_20spdy_ietf.html 2012年3月29日 IETF の会議で、HTTP2.0 の議論を正式に開始。 その話し合いでは、Google の 「SPDY」や、Microsoft の「H
openssl コマンドって、直接叩いてファイルを暗号化できることをしらなかったのでメモ。 ちょっとファイルに鍵をかけたい場合に便利そう。 開発機なら大体 openssl-dev とか入れている気がするので、すぐ使えると思う。 ファイルの暗号化に使えるのは openssl enc コマンドで、そのヘルプは openssl enc help で見ることができる。 覚えておきたいのは以下のコマンド -in 入力ファイル -out 出力ファイル -e encrypt(暗号化) -d decrypt(復号化) 暗号化方法は色々選べる。同じく help で確認できる。 いくつかあって、あまり詳しくはないけど -aes-256-cbc あたりを選んでおけば良さそう。 ファイルの暗号化はこう。 $ openssl enc -e -aes-256-cbc -in test.txt -out test.tx
Socket.IO で RangeError: Maximum call stack size exceeded #nodejs_jp Node.js v0.7 系から、 EventEmitter の変更が原因で、 Socket.IO が落ちるバグが発生しています。 具体的には Socket.IO@0.9.6(およびそれ以前) を node@0.7.8(及び 0.7.x 全般) で起動した後、ブラウザからアクセスしたら、下記のようなトレースを吐いて落ちます。 Jxck$ node server.js info - socket.io started /../gist-2292777/node_modules/socket.io/lib/manager.js:0 (function (exports, require, module, __filename, __dirname) { /*!
JS のスコープをなんとかするよくあるイディオム、 var foo = { num: 10, fn1: function(n, cb){ cb(n * 2); }, fn2: function(a, cb){ var self = this; this.fn1(a, function(ans) { cb(ans + self.num); }); } } foo.fn2(10, function(ans){ console.log(ans); // 30 }); この var self = this がないと、 num が参照できないのでうまく動かない。 時には var that = this の人もいるけど、いずれにせよなんかちょっとなぁなどと思う。 そこで、ES5 の bind() を使うと、 this を差し込んでコンテキストを変えられる。 var foo = { num: 10, f
Socket.IO と WebSocket が混同されてることある。 Socket.IO は WebSocket の上位プロトコルを定義していて、 それは生の WebSocket とは違う。 で、その仕様はドキュメントとは別、 というか Socket.IO とは別のリポジトリで管理されていて、 以下にある。(たぶん、仕様は別で議論/管理したかったんだと思う。) https://github.com/LearnBoost/socket.io-spec で、これあまり表に出てないけど、結構重要だということで翻訳しました。 https://github.com/Jxck/socket.io-spec これは Socket.IO を正しく理解し、使用するためには必須の知識です。 またを喋れれば、 Node.js じゃないクライアントも書けます。 翻訳ですが、あまり時間がかけられなかったのもあるけど
今日こんなことを聞かれた。 https://twitter.com/#!/bluerabbit777jp/status/176982463040602112 @Jxck_ の考えるWebSocketで今後Webがどうなるか?聞きたいなぁーー で、まあ素直に @bluerabbit777jp むしろ俺が聞きたいですw などと答えてしまったわけですが。。 これじゃあんまりにもあんまりにもなので少しだけ。 ずっと 「WebSocket できる事があまりにも多く、俺達はその可能性を10%も引き出せてないんじゃないかな」 とは漠然と思ってる。 文章を共有することを目的として、ステートレスでプルベースが基本だった Web を、 色んな目的からこれでもかってくらいいじって使いたおしてきたんだけど、 ステートフルでプッシュ可能な技術を手に入れて、 「これであれもできるし、これもできるし、世界変わるぜ!!」
(やる場合は一回最後まで読んでからの方がいいです。) Lion に上げた mac で ab(apache bench) を打ったらなんか上手く動かなかった。 $ab -n 10 -c 4 http://localhost:3000/ This is ApacheBench, Version 2.3 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ググったら、ようするにビルドし直せって言われた。 http://stackoverflow.com/questions/7938869/ab-is-erroring-out-with-apr-socket-recv-con
Stream.io の example として Stream だけで Chat を実装してみた。 https://github.com/Jxck/stream.io/tree/master/example/chat いずれも socket.io と jquery そして、自分が移植した events.js, stream.js util.js を使ってる。 まず server 側では client を Stream に抽象化する。 この時は、 echo サーバであれば、以下のようにつなぐだけ。 io.sockets.on('connection', function(socket) { var client = new ClientStream(socket); client.resume(); client.pipe(client); }); client 側では、 server と i
Node.js の assert, events, stream を移植しました。 #nodejs_jp Stream.IO (https://github.com/Jxck/stream.io) のために、 クライアントで Stream を使いたかったので移植しました。 そのため、依存する events と、テストのための assert をも一緒に移植しました。 events は [https://github.com/Wolfy87/EventEmitter]assert は [http://chaijs.com/]などもあるんですが、 events や stream の Node.js のテストまでは動かなかったので、 そのものまるごと移植しました。 https://github.com/Jxck/asserthttps://github.com/Jxck/eventshttps:/
[追記] nvm は .zshrc のいじり具合によっては、表示がうまくいかなかったり、すこし変な動きをしたりすることが有るという意味で。nvm 自体はそれらを事細かに対応するつもりはなく、自分は bash に切り替えることで全ての不具合を回避しているという意味です。「nvm は使い物にならん」とか「インストールもまともに出来ない」などと言うつもりはないし、書いてません。実際今使っています。 全ては自分が zsh を使っていることに起因している。 node.js v0.6 のリリースと npm のアップデートも有り、 一旦環境を見直そうと .nvm/ .npm/ を全部消した。 折角ならツールも見直してみようかと思ったが、あまり変わってなかった。 node.js の環境管理(version manager)は以下のものがある。 nvmnavennodeenvnvm(https://gith
node には readableStream と writableStream というインタフェースがある。 EventEmitter のインスタンスなので、イベントとメソッドをもつ。 何を持つべきかは、マニュアル参照。 そして、node ではしばしばこの Stream を用いてデータのやり取りをすることがある。 ファイルを読むときも、 Socket を使うときも、標準入出力にも stream がでてきて、 受け取ったり、渡したり、 pipe で中継したりして、データの流れをコントロールするような感じ。これは Node では非常に重要な考え方。 たとえばファイルの中身を Stream で読むと、 on(‘data’, cb) でちょっとづつ中身がとれたりする感じ。これだと、一行ごとに処理とかできないので、例えば data イベントのたびに、改行を探して自分で切ってあげたりしないといけない。
Hook.IO というプロダクトがある。 Nodejitsu という実力派スタートアップの Marak が中心になって作られたようで、Node.js のプロダクト。 Node.js はイベントを扱うために、 EventEmitter という仕組みが有るんだけど、このイベントは発生したのと同じプロセス上でしか捕捉できない。 しかし、 Hook.IO はあるプロセスで発生したイベントを他のプロセスで捕捉できる。裏ではネットワーク通信してるので、イベントがスケールするイメージ。 これを使うと、サービスをコンポーネントで分けて、別々のプロセスで起動して、イベントでつなぎ、スケールさせるみたいな構成が可能になる。 非常におもしろいし、これから必要になるだろう仕組みだと思う。 Forever といい、 Node-http-proxy といい、 Nodejitsu はいつも玄人向けのプロダクトを出してく
こんな簡単なことに今まで気がついてなかった自分を、心より恥じる。 例えば、なんかサーバがあって簡単な認証をしたいとき。DBを使うほどでもないし、ファイルで良いし、まあ最悪頑張ってこじ開けられてもそんなに問題じゃない、でも一応 admin パスワードだけ欲しいな。な時。 if(req.body.pass == 'password') //okみたいに直には書けない。(さすがにソース見るとばれるのは。。) で、外部ファイルにして読み込み、 .gitignore に加えてリポジトリにはコミットしない。などする。もしくは環境変数や pit 的なものに入れてそれを見たりする。 // configファイル的なものや環境変数 var config = { pass: 'password'}var config = // config ファイル的なものか環境変数を読み込む if(req.body.pass
よく log というエイリアスを貼るんですが。 Node の場合は var log = console.log; でいけるんですが、 これってブラウザ(Chromeしかやってないけど)じゃ動かなくて log(1, 2, 3); // Uncaught TypeError: Illegal invocation というエラーが出ます。 そこで、apply してみるが function log(){ console.log.apply(null, arguments) }; function log(){ console.log.apply(window, arguments) }; function log(){ console.log.apply(this, arguments) }; これもできない。。 しかたなく、 function log(){ console.log(argumen
正確に言うと、 「サーバサイドでテンプレートエンジン使って画面を作ってから、そいつを丸っとレスポンスで返す」のはNodeにはあまり合わないんじゃないかと常々思っている。 理由は、レンダリングはCPUヘビーな処理だから。 CPUヘビーな処理は、Nodeのメインループを止めて全体に影響してしまう。これはあまりよろしく無いはず。 どうしたいかというと、やっぱりシングルページなアプローチがしたい。 完全にシングルでないとしても、準シングルくらい。 リソースはAPIで公開。Ajax,WSで取得してクライアント側で組み立てたい。サーバはCUPでの処理の代わりに、クライアントからのコネクション増加を負うけど、Nodeにはその方が良さそう。特にWSで。 画面構築はクライアントに押し付けるけど、最近それをあまりにも気にする感じではないよね。 重たくなるのは、一気にやろうとするからで、最初にテンプレートを受け
このページを最初にブックマークしてみませんか?
『Jxck's OutPut』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く