Web Platform Dive into the web platform, at your pace.

The Netflix Tech Blog: Going Reactive — Asynchronous JavaScript at Netflix Link: The Netflix Tech Blog: Going Reactive — Asynchronous JavaScript at Netflix Our own Jafar Husain shared how we’re using the Reactive Extensions (Rx) library to build responsive UIs across our device experiences. Pretty impressive talk on Rx by Netflix. Looks like a great alternative to Promises, on handling asynchronou
だいぶ前から時間経ってしまいましたが、非同期の落とし穴シリーズPart3。ちなみにまだ沢山ネタはあるんだから!どこいっても非同期は死にますからね! async void vs async Task 自分で書く場合は、必ずasync Taskで書くべき、というのは非同期のベストプラクティスで散々言われていることなのですけれど、理由としては、まず、voidだと、終了を待てないから。voidだと、その中の処理が軽かろうと重かろうと、終了を感知できない。例外が発生しても分からない。投げっぱなし。これがTaskになっていれば、awaitで終了待ちできる。例外を受け取ることができる。await Task.WhenAllで複数同時に走らせたのを待つことができる。はい、async Taskで書かない理由のほうがない。 んじゃあ何でasync voidが存在するかというと、イベントがvoidだから。はい。b
Philipp Haller, Aleksandar Prokopec, Heather Miller, Viktor Klang, Roland Kuhn, Vojin Jovanovic 著 Eugene Yokota 訳 概要 Future は並列に実行される複数の演算を取り扱うのに便利な方法を提供する。それは効率的でノンブロッキングな方法だ。 大まかな考え方はシンプルなもので、Future はまだ存在しない計算結果に対するプレースホルダのようなものだ。 一般的に、Future の結果は並行に計算され後で集計することができる。 このように並行なタスクを合成することで、より速く、非同期で、ノンブロッキングな並列コードとなることが多い。 デフォルトでは、Future も Promise もノンブロッキングであり、典型的なブロッキング演算の代わりにコールバックを使う。 コールバックの使用を
時代は AsyncTask より AsyncTaskLoader Android 4.0、通称 Ice Cream sandwich というスマートフォンもタブレット端末もカバーする新しい OS がもうすぐデビューするとかいう時期なので、Android プログラミングもそれの普及をにらんだ実装に切り替えていくべき。 まずは、きっと Activity 上での非同期処理に多用されているであろう AsyncTask を、Android 3.0 以降で追加された AsyncTaskLoader へ乗り換えるところから始めるのもいいんじゃないかと思ってちょっと書いてみます。 あ、これは Activity での非同期処理について、という前提での内容になりますので、たとえば Service の中で非同期処理したい場合はどうすれば的な質問には役に立たないと思います。 いくら 4.0 がリリースされたとはい
日本マイクロソフト株式会社 Digital Sales 事業本部 Digital Cloud Solution Architect 上坂 貴志 クロスプラットフォームに対応した .NET Core、.NET 5 を得てリリースされた .NET 6は待望の LTS (Long-term Support)です。新規開発であれば .NET 6 での開発を検討できますが、.NET Framework で作成された既存のシステムはどうすれば良いでしょうか。 .NET Framework は version 4.8 を最後に新機能の追加予定は今のところありません。今後のことを考えて .NET 6 へのアップグレードを検討したいところですね。 このセッションでは .NET Framework から .NET 6 へのアップグレードについての様々な情報をお伝えします。
C# 5.0のasync/awaitを使うと、多くの場面ではシングル スレッド的な動作になるし、多くの場面ではlock不要(結果的に、デッドロックが起こりようなくなる)になったりします。 ただし、「多くの場面で」。「必ず」ではないのがはまりどころ。いくつかの場面では、同時実行制御が必要です(普通にマルチスレッドの平行実行になるので、同時に同じデータにアクセスされる可能性を考慮しないとバグります)。 前提知識 いくつか、C# 5.0世代の非同期処理についての前提知識は、以下のスライド(先月末の.NETラボでの発表)を参考にしてください。 5~12ページ: async/awaitの書き方 17~22ページ: スレッドとそのコスト 24~26ページ: スレッド プール 29~32ページ: I/O完了待ちと非同期API 36~40ページ: UIスレッドとディスパッチャー 41~45ページ: 同期コ
You're Missing the Point of Promises · GitHubを読んだ。 特に興味深かったのが"That Second Paragraph"の見出しで始まるセクション。曰く、Promisesとは、非同期ルーチンとその結果を受ける処理における以下の「4つのシナリオ」を表現できるようにするものらしい。 非同期ルーチンが正常に終了し、その結果も正常である。 (fulfilled and accepted) 非同期ルーチンが正常に終了したが、その結果が異常なので例外を投げる。 (fufilled but rejected) 非同期ルーチンが例外を投げたが、その例外をキャッチして適切に処理する。 (rejected but handled) 非同期ルーチンが例外を投げ、その例外をキャッチするも、処理できずにrethrowする。 (rejected and rethrown
Andy Kogut Arthur Axel 'fREW' Schmidt Breno G. de Oliveira Clinton Gormley David Steinbrunner Erik Huelsmann Felipe Gasper Florian Ragwitz hatorikibble InfinityGone Luke Triantafyllidis Mohammad S Anwar Opera Wang Perlover Peter Valdemar Mørch Ricardo Signes Ruslan Zakirov Sean Zellmer Stevan Little stuckdownawell Tom van der Woerdt Yanick Champoux NAME Promises - An implementation of Promises in
前回からかなり時間が空いてしまいました...やっと時間取れた.今回は 2 回に分け,1 回目で TameJSを,2 回目で node-fibers を取り上げたいと思います. ちなみに,「この方法が良い」と言うよりは「こんな方法もありますよね」というスタンスで書いています*1. 見出し はじめに TameJS とは? TameJS の利用例 TameJS のしていること おわりに はじめに Node.js は非同期処理が基本であり,コールバックを多用するスタイルです.そのため,コードは簡単にコールバックのネストだらけになります*2. この "深いネスト" を解消するため,多くの場合は control flow ライブラリ が使用されます*3. TameJS では,非同期処理の記述に await/defer を持ち込み,上記の解決を試みています. TameJS とは? TameJS は tj
closureで継続(continuation)を実現する技法ってあるじゃないですか。 例えば次の記事は私が5年以上前に書いてますね。 C#2.0時代のゲームプログラミング(49) 〜 delegateを用いたcontinuation http://d.hatena.ne.jp/yaneurao/20070207 上の技法は私は10年ぐらい前にclosureを使い出したころに自力で発見しましたが、まあ、いまや常識ですよね。それで最近、それに似た話題があったので取り上げてみます。 ここで再度認識して欲しいのは、node.js の素晴らしさは「クライアント側で皆が使っているJavaScriptでプログラムが書ける」という部分などにあるのではない、という点だ。node.js がこれほど多くの支持者を得ているのは「本来記述が煩雑になりやすい非同期処理をJavaScriptの無名関数を利用して書きや
Tame is an extension to JavaScript that makes event programming easier to write, read, and edit. JavaScriptで非同期処理を記述したことがあるプログラマであれば、その記述の面倒さに閉口したことがあるだろう。たしかに、パフォーマンスを考えるとシーケンシャルに処理するよりもパラレルに処理させた方が有利なことが多い。しかし、記述がかなり煩雑なものになるため、あとからデバッグやアレンジ、ほかの非同期処理のマージなどを実施しづらい。 この問題に対するひとつの解決方法として活用できるライブラリが登場した。「TameJS」がそれだ。TameJSは日に1億のHTTPリクエストをさばいているサービスOkCupidの開発者らが開発したライブラリ。非同期処理を簡単に記述できるようにするという特徴がある。 もと
asynchronous disk I/O | libtorrent blog Libtorrent experience - the poor state of async disk IO | Hacker News libtorrentの作者が、ディスクI/Oをパフォーマンスを向上させるために非同期I/Oを試した結果、どの環境でも残念なので、ブロックI/Oをスレッドプールで行う擬似非同期I/Oで実装したとブログを書いている。その問題について、Hacker Newsでも議論されている。 非同期I/Oは、話を聞くとたのもしい機能に思える。読み書きが完了するまでブロックせずに、完了したらOSが通知するという仕組みだ。 問題は、その実装がどの環境でも貧弱だという事だ。 環境というのは、主にOS側のことだ。多くのモダンなOSは非同期I/Oを提供している。特に著名なのがみっつある。 Linux A
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
前からやりたいと思っていたのだけど、先日 ujihisa さんが correr.vim なるものをリリースして、これはこの波になるしかないと言う事で勢いで機能を追加した。 quickrun.vim 0.4.0 で使えるよ。 GitHub - thinca/vim-quickrun at v0.4.0: Run commands quickly. 使い方 前提条件 Vim が +clientserver 付きでコンパイルされている必要がある。確認するには、 echo has('clientserver') で 1 が返ってくれば OK。 さらに、v:servername に何かしら名前が入っている必要がある。 echo v:servername で、何か表示されれば OK。されない場合は Vim を vim --servername VIMなどとして適当な名前を付けてやる。 複数の Vim
プラグイン名は activefix.vim です。まだ開発途中ですが、それなりに動作するようになったので公開します。 説明 シンタックスチェックを行うVimプラグインは GitHub - vim-syntastic/syntastic: Syntax checking hacks for vim が有名ですが、これはシンタックスチェックを実行している間ユーザーの操作をブロックしてしまいます。 そこで、操作をブロックせずに、syntasticのように多数のファイルタイプに対応したシンタックスチェッカーを開発することにしました。 必要なもの GitHub - Shougo/vimproc.vim: Interactive command execution in Vim.が必要です。ただし、vimprocがインストールされていなくても動作しないわけではなく、syntasticと同様にファイルを
概要 注意: 2010年10月時点での CTP (community technology preview)版を元にした記事になっています。 製品版までに変更の可能性があります。 (async や await というキーワードも変更される可能性あり。) Ver. 5.0 スレッドを使った非同期処理を行いたい動機としては、以下の2つが挙げられます。 非ブロッキング処理: I/O 待ちとかで UI スレッドをフリーズさせないようにする 並列処理: マルチコアを活かした並列処理でパフォーマンス向上 このうち、並列処理に関しては、Parallel クラスや Parallel LINQ で簡単に対応可能 (ラムダ式や LINQ を使えば、並列じゃない場合とほとんど変わらず書けます。 参考: 「[雑記] スレッド プールとタスク」)。 一方の、非ブロッキング処理は、今までは結構面倒だったものの、 as
node.js を代表とする JavaScript を用いた非同期プログラミング環境においては、コーディングパターンのベストプラクティスが共有されておらず、結果として品質の低いコードが多くなるという問題があるように思います。そこで、特にエラー処理をどう書くべきか、既存のライブラリを使う方法を紹介してみることにしました。 いきなりですが、ファイルの文字数を返す関数を作ることを考えてみます。Java だと以下のような感じになるでしょうか。countChars メソッドに注目すると、エラーを例外として扱っていて、モジュラーかつ簡潔になっていることがわかります。 class FileCounter { static long countChars(String filename) throws IOException { FileInputStream is = new FileInputStre
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く