ジェネレータの解説と非同期への適用 - Block Rockin’ Codes
update 2014-01-16 ご指摘頂いたので修正しました。ありがとうございます！ @Jxck_ 動画すごくわかりやすかった！一個、重箱の隅っこなんだけど、convert関数のapplyしてるところ、fn.apply(fn, args) になってるけど fn.apply(this, args) が正しい気がしました！— Kazuhito Hokamura (@hokaccha) 2014, 1月 13 https://gist.github.com/Jxck/8380852 は修正済みです。動画の取り直しは勘弁して下さい(汗 - fn.apply(fn, args); + fn.apply(this, args); intro あけましておめでとうございます。 今年からはてなブログへ移行しました。 去年末くらいから流行っている Express の後継 Koa では JS の新機能ジェ
HTTP2 時代のサーバサイドアーキテクチャ考察 - Block Rockin’ Codes
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
「for やめろ」またはイベントループと nextTick() - Block Rockin’ Codes
ものすごく遅レスですが、LLDiver で @esehara さんの LT であった話。 forやめろ、あるいは「繰り返し」という呪縛から逃れるために 簡単に言うと、 1~10 までを出力する方法を複数考えるというもの。 for, while, 再帰, goto etc.. と出て、途中で終わっちゃったので結論はよくわかりませんでしたが、 Node ではどれも使わずにできるな、と思ったのでちょっと例を出してみます。 ちなみに、タイトルでネタバレしている通りイベントループの話です。 そしてよくある「イベントループとは何か」「なぜ止めてはいけないのか」「process.nextTick() とは何か」「setImmediate() と何が違うのか」 などを解説する良い例だったので、書いてるうちに実はそっちがメインの解説となりました。 サンプルの実行結果は Node v0.11.13 です。(書
Go の並行処理 - Block Rockin’ Codes
intro 先日の Go のカンファレンス GoCon で、 Go の並行処理周りについて発表させて頂きました。 Go Conference 2013 spring - connpass 具体的には Goroutine や Channel の話ですが、これらの機能は結構面白くて、いじって遊んでるだけでもわくわくします。 Go の並行処理は、設計方針がわりと特殊だと思うのですが、設計がシンプルなので分かるとそこまで難しくはないです。 (使いこなすのは、経験が必要そうですが) 今回話すにあたって色々調べましたが、発表時間の都合上省いたものもあるし、質疑応答で聞かれて応えられなかったこともあるので、 ここでまとめて置こうと思います。 発表資料 今回の発表資料はこちらです。 このブログの内容は、これをベースにします。 http://jxck.node-ninja.com/slides/gocon-
Go1.1 の Race Detector - Block Rockin’ Codes
intro 先々週、Go 1.1 がリリースされました。 いくつか新しい機能が入ったのですが、その中の Race Detector というのが面白そうだったので、 軽く調べてみました。 Race Detector この機能は、簡単に言うと「レースコンディションが発生していないか」を調べる機能です。 といわれると、なんだかすごい機能ですね。 そもそもレースコンディションとは、マルチスレッドプログラミングなどで、単一のリソースを複数のスレッドで共有した際に、競合状態が発生して、予期しない結果を生んだりする状態です。 レースコンディションによるバグは、再現生が低かったりするので、一般的にデバッグが難しいとされています。 そうした状態が起こらないように、がっちりロックを取り合ったり、そもそもメモリを共有せずメッセージパッシングするなど、別のパラダイムで情報を共有する方法が取られます。 Go も、以
Advanced Go Concurrency 3 つのパターン - Block Rockin’ Codes
intro ちょっと時間が経ってしまいましたが、 Go研 vol.03 では、 Google I/O 2013 で行われてた Go のセッションの 1 つである下記をテーマに研究しました。 Advanced Go Concurrency Patterns 資料は以下です。 https://github.com/goken/goken/blob/master/goken03/goken03.md また、ここから順に実装しながら解説をしますが、その完成品はこちらにあります。 (commit 履歴も、本記事にある程度沿っています。) https://gist.github.com/Jxck/5831269 スライドにそってやったのですが、セッションの内容は結構重ためだったので、 2 時間の Go 研だとちょっと消化不良ぎみだったのが反省点です。 そこで、このセッションの要である、並行処理に関する
Node.js の Stream API で「データの流れ」を扱う方法 - Block Rockin’ Codes
追記 11/12/6 少し誤字脱字を修正、加筆 11/12/7 koichik さんにコメントで頂いたリンクと、その内容について追記 11/12/7 edvakf さんに頂いた指摘を修正 本文 この記事は、JavaScript Advent Calendar 2011 (Node.js/WebSocketsコース) の 4 日目の記事です。 Node.js には Stream という API があります。 Stream はとても重要な技術で、 「Stream を制するものは、 Node.js を制す」と言っても過言ではありません。 実際、 Stream は Node.js が得意とする I/O の部分を使いこなすために、 押さえておくべき技術なので、今回はこの Stream について紹介したいと思います。 参考 Jxck's OutPut - Node.js の Stream I/O のお
JavaScript のパフォーマンスと Sweet Spot の甘い罠 - Block Rockin’ Codes
本文 先日 JavaScript を高速化するには、 VM を知る必要があるんだろうと思い、 以下のような発言をしてみました。 とにかく今は 「V8の最適化の恩恵を受けるための JS の書き方」や「ホットスポットを温めて C よりも速い JS を書こう」という釣りっぽいけど釣りじゃない記事を @Constellation さんや @bad_at_math さんに書いていただく必要があるということでした！ 2011-10-23 21:53:44 via Echofon しかし、釣り針が小さかったためか、誰も釣れず。。 自分で調べろってことですよね、すいません。。 と思っていたら、先日下記のエントリが話題になりました。 そのものずばり、JavaScript を最適化する話。 mraleph-The trap of the performance sweet spot 先に感想を言うと、これはい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
