Node.jsフロー制御 Part 1 – コールバック地獄 vs. Async vs. Highland | POSTD
（このシリーズのPart 2はこちら: Node.jsフロー制御 Part 2 – FiberとGenerator ） 今回は、JavaScript/node.jsアプリケーションのフロー制御に対するアプローチを、いくつか取り上げて比較してみたいと思います。 通常のコールバックを使う 平坦化されたコールバックを使う Async （ @caolan 作）を使う Highland （こちらも @caolan 作）を使う Bluebird （ @petkaantonov 作）を使う Expressフレームワークを使った以下のルート処理（お粗末ですが）を例に見てみましょう。 ファイルから読み込む いくつかのプロセスを実行する（ステップの数は3つ） プロセスとは、単に拡張データをコールバックする任意の非同期処理を指します ファイルに結果を書き出す リクエストに対して成功またはエラーのメッセージを返す
[Javascript] 非同期設定でレスポンス速度を改善させる | mkoba のお部屋 ： DREAMHIVE Staff Blog
この記事は2年以上前の投稿になります。 記載された情報が古くなっている可能性がございますので十分ご注意ください。 ウェブサイトのレスポンス速度を改善させる手法の1つとして、読み込む JavaScript ファイルの非同期化というものがあります。 通常、外部の JavaScript ファイルを呼び出す場合、特に何も指定しなければ同期設定で読み込まれます。 これを非同期にすることで待ち時間を減らしてレスポンス速度を改善させることができます。 先日ご紹介した「GTmetrix」や「PageSpeed Insights」でも非同期を推奨していますね。 設定の仕方も簡単です。 <script async src="//xxxxxxxxxxxxxxx.js"></script> や、こんな感じで設定します。 (function(){ var elm = document.createElement('
![[Javascript] 非同期設定でレスポンス速度を改善させる | mkoba のお部屋 ： DREAMHIVE Staff Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/bf9f20a6b7d49de5a75020648483027fb553aa5b/height=288;version=1;width=512/https%3A%2F%2Fblog.dreamhive.co.jp%2Fmkoba%2Fwp-content%2Fuploads%2Femblem-mkoba_200x200.png)
コールバック……駆逐してやる…この世から…一匹…残らず!! - Qiita
このテキストは JavaScript のコールバック地獄に疲れたひとのためのコールバック駆逐術指南書です。対象読者は JavaScript道初段くらいの人です。このテキストを読むと、以下のそれぞれの手段における非同期処理制御の仕組み、利点および欠点がわかるようになるかもしれません。 コールバック地獄 jQuery.Deferred async.js Concurrent.Thread generators co fibers Web Workers (※なぜか『進撃の巨人』の一部ネタバレが含まれるので注意してください) それは『何故人はコールバックするのか』という話でしょうか？ 非同期処理って面倒ですよね。JavaScriptではいわゆる コールバック地獄 というやつにしばしば陥りがちです。たとえば、Ajax でふたつのファイル hoge.txt と piyo.txt を持ってきて、それら
WalB v1.0 リリース - Cybozu Inside Out | サイボウズエンジニアのブログ
更新情報 2017年6月現在、WalB のプロジェクトページはhttps://walb-linux.github.io/です。 こんにちは．サイボウズ・ラボの星野です． 今日は，効率的なバックアップと非同期レプリケーションを目的とした Linux カーネルドライバ WalB についての簡単な紹介と，そのバージョン 1.0 のリリース告知をさせて頂きます． WalB って何？ WalB は「ワルビー」と発音します．名前の由来は Block-level WAL です．WAL は Write-Ahead Logging (ログ先行書き込み) のことで，データベースの一貫性制御等に用いられます． WalB を使うと，オンライン状態のブロックデバイスにおいて，アプリケーションやファイルシステムによるデータ書き込みによって生じる差分データを，ブロックデバイスをフルスキャンすることなく効率的に取得出来る
非同期I/OやノンブロッキングI/O及びI/Oの多重化について
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 2017年5月20日追記 本エントリはI/OのOperationとCompletionおよびデータ整合性を混ぜてまとめた一部誤った定義になっているので、正確な定義を日本語で知りたい方は下記にリンクしたエントリを読むことをおすすめします。 非同期とノンブロッキングとあと何か Apache2.4.1のevent_mpmやnginx及びnodde.jsのアーキテクチャを考える上で、非同期I/OやノンブロッキングI/O、I/Oの多重化に関してある程度正確な理解が必要だと思ったのでまとめておく。 ここで「ある程度」といったのは、非同期を表すAsynchronousとノンブロッキングのnon-blockingは曖昧に使われる場合が多いからだ。まず、英語の
非同期プログラミングを驚きのシンプルさに (するかもしれない) Flow.js を公開しました。 - latest log
(ε・◇・)з o O ( (ミ・◇・ミ) o O ( あたし。ずっと思ってた… (ミ・◇・ミ) o O ( あたしの脳みそだと Deferred/Promises は、ちょっと難しすぎるって… (ミ・◇・ミ) o O ( jQuery.Deferred 解説記事をいくつかみたけど、すごく… モジモジしてて、ちょっと縦長すぎるんですもの… (ミ・◇・ミ) o O ( だから作っちゃった… ).done(); 非同期処理をシンプルに書ける、とても小さなライブラリをリリースしました。 Deferred/Promises は既存の構造や, そもそもの考え方を大きく改変する必要がありますが、 flow.js はあまり大きな違和感もなく、現在の流れを維持したまま導入できると思います。 使い方はこちらをごらんください http://www.slideshare.net/uupaa/flowjs リポジ
Node.jsアプリで結果が非同期になる箇所はコールバックを渡せるようにした方がいい - yo_waka's blog
既存のNodeアプリのテストを書いていて思ったことをメモ。 書いてるうちに別にNode.jsに限った話じゃなくて、JavaScript全般に言える話じゃんと思ったけどまいっか。 Node.jsで書くアプリは中の処理で非同期API使われてると、テストを書くのがとても難しいというかめんどくさい。 例えばfsモジュールで非同期でファイル書いてる処理があって、もし書き込みに失敗したらエラーイベントを投げて上のレイヤーで処理する、みたいなのがあるとする。 // HogeクラスはEventEmitterを継承している Hoge.prototype.writeFile = function(file, data) { var self = this; fs.writeFile(file, data, function(err) { if (err) { self.emit('error.file', e
node.js におけるエラー処理のコーディングパターン (もしくは非同期 JavaScript における例外処理) - kazuhoのメモ置き場
node.js を代表とする JavaScript を用いた非同期プログラミング環境においては、コーディングパターンのベストプラクティスが共有されておらず、結果として品質の低いコードが多くなるという問題があるように思います。そこで、特にエラー処理をどう書くべきか、既存のライブラリを使う方法を紹介してみることにしました。 いきなりですが、ファイルの文字数を返す関数を作ることを考えてみます。Java だと以下のような感じになるでしょうか。countChars メソッドに注目すると、エラーを例外として扱っていて、モジュラーかつ簡潔になっていることがわかります。 class FileCounter { static long countChars(String filename) throws IOException { FileInputStream is = new FileInputStre
Deferred/Promisesと非同期処理 - 素人がプログラミングを勉強していたブログ
概念/仕組み Deferred/Promisesは非同期処理を簡単にするための取り決め。 callback hellと呼ばれているような、非同期処理によるコールバックのネストを軽減することができて非常に便利。 慣れれば便利だが、一見どう使えばいいのか分かりづらいので、少し解説を書く。 ここではPromises/Aという仕様を実装したQというライブラリを使うが、jQuery.Deferredなどもほぼ同じである。 まず、Deferred/Promisesは、関数のreturn、try/catchの非同期版である。 www.example.comの内容を取得し、正しく取得できたら中身を表示し、取得できなければエラーを表示する、というプログラムは 同期的なコードでは、 function get() { var req = new XMLHttpRequest(); req.open('GET',
node.js と thread hog の話（３）
[前回までの話へのリンク] ・node.js と thread hog の話（１） ・node.js と thread hog の話（２） では、なぜ今頃になって HTTP Server の c10k 問題（もしくは、thread hog 問題）が顕在化したのだろう。 当時（９０年代の終わり頃）と比べて、もっとも大きく変わったのはCPUの性能である。クロック数は、数百MHzから数GHzへと一桁増えたし、マルチコア化もしている。CPU 性能だけ見れば、当時の数十倍の能力が出てしかるべきである。 しかし、実際の人生はそう簡単ではない。サーバーのパフォーマンスはCPU性能だけが決めるわけではないからだ。そこで、ボトルネックの一つとして注目されはじめたのが、thread の数なのである。 前回述べた様に、thread 一つあたり 2MB～8MB のスタック領域を仮想メモリ空間に確保しなければならな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
