前編では、Reactive Extensions (Rx) の機能を関数型プログラミングの視点で読み解いた。続いて後編では、前編で紹介した Rx が関数型的な機能を提供している背景、つまり Observable と他の一般的なコンテナの関係に対してスポットライトを当ててみたい。 あらかじめ断っておくと、本編の話題は、実際に Rx を使う上で理解している必要は（あまり）ない。とりあえず、 Observable は、List や Future と同じくモナドの一種である 以下の表に出てくるコンテナは、隣同士で互いによく似た（あるいは正反対の）性質を持っている: 単数 複数 同期 (pull) T/Try[T] Iterable[T] 非同期 (push) Future[T] Observable[T] …という話だけ記憶に留めてもらえば、ここで回れ右してもオーケー。とはいえ、興味のある人はこの
概要 『Observable は単なる非同期データストリームにおけるモナドのインスタンスだよ。何か問題でも？』 まともな概要 つまり、Reactive Extensions (Rx) って何だ？ ということでウェブをガサゴソと漁っていたところ、オンライン講義サービス Coursera の Principles of Reactive Programming に行き当たった。この講座では、Rx の主要開発者の一人である「双対おじさん」こと Erik Meijer 氏自らが一部の章を担当し、Rx の理論的側面を講義している。 この講座の大きな特徴は、Rx を（命令型プログラミングではなく）関数型プログラミング (FP) の側から解き明かしていくことにある。 こう書くと奇をてらっているように見えるかもしれないが、実際には Rx は FRP (Functional Reactive Program
- + 最近の小学校では、「お父さん・お母さんの名前をグーグルで検索してみましょう」という、世にも恐ろしい授業があるらしい。・・・。 — 丹 洋介 (@yosuke_tan) January 25, 2015
Reactive Streamsというのはノンブロッキングなback pressure可能な非同期ストリーム処理の標準的な仕様を提供しようというもので、実装としてはAkka Streams、RxJava、Reactor Composable、Ratpackなどがあります。 Reactive StreamsについてはAkkaのコミッタであるKonrad Malawskiさんの以下のスライドがとてもわかりやすいです。 2014 akka-streams-tokyo-japanese from Konrad Malawski ストリーム処理（というか非同期メッセージング全般に言えることですが）では受信側の処理能力を超えるデータを送信し続けるといずれキャパシティを超えてオーバーフローが発生してしまうため、送信側に比べて受信側の処理能力が低い場合は送信側が手加減してデータを送信する必要があります。な
Wikipediaで リアクティブプログラミング (reactive programming)を調べてみました。また、 関数型リアクティブプログラミング (functional reactive programming, FRP)についても少し説明があったので確認してみましたが、どちらも説明が大雑把です。 実際のところ関数型リアクティブプログラミングとはどういう意味なのでしょうか？リアクティブプログラミングは（非リアクティブプログラミングと比べて）何で構成されているのですか？私は命令型のオブジェクト指向言語を使っているので、そのパラダイムに関連させて説明して頂けると大変有難いです。 asked by JtR Answer(s) FRPの感触をまず試してみたいのであれば、 1998年に発表された古典のFran tutorialに目を通してみると良いでしょう。 これは動画で説明されています。
Rebuild.fm に出させてもらいました。ありがたいことです。 さっそく録音を聞き直す。自分の声を聞くのは辛い・・・のはさておき、 リアクティブプログラミングの話は我ながら主張がよくわからない。 反省のため何が言いたかったのかを考え直したい。 たぶん趣旨は二つあった: A. RxJava や RxAndroid はなかなかいいやつだ。 B. リアクティブプログラミングは一つのはっきりした概念ではない。 A については試してもらえばわかるはず。ReactiveX のサイトからぽつぽつ資料を読めば済む。ここでは B を補足してみる。 X 指向は Y みたいなもの リアクティブプログラミングとは何だろう。どうもつかみどころがない。私は腑に落ちるまでけっこう時間がかかった。 このわかりにくさには大きく二つ理由があると思う。一つはプログラミングの概念をコードなしに説明する一般的な難しさ。オブジェ
はじめに もうすっかり年末なので、これから2015年にかけてアプリケーションアーキテクチャがどのようになっていくのかという個人的な考え/妄想や背景について、「リアクティブ」というキーワードをもとににまとめてみたいと思います。 Google Trendsを見ると"reactive programming"という言葉は2010年前後から、ゆっくりとバズをし始め、現在も上昇を続けています。 また、仕事としては、2010年ごろから大規模なWebサービス開発において、フロントエンド、バックエンド、アルゴリズム改善といった様々な箇所で、リアクティブプログラミングの要素を取り入れながら、アーキテクチャの改善を進めてきました。そのため、こういったアーキテクチャがコード品質の維持や安定性の向上、実際的で複雑な問題の解決にも適応可能であるということを実感として持っています。 近年、そういった要素が様々なツール
original: The introduction to Reactive Programming you've been missing (by @andrestaltz) (translated by @ninjinkun, reviewed by @ma0e) あなたはリアクティブプログラミングと呼ばれる新しい方法が気になっている。 勉強するのは大変で、良い教材がないのでさらに難しい。私が勉強を始めたときは、まずチュートリアルを探した。見つけたのは一握りの実践的なガイドだけ、しかもそれらは表面をなぞっているだけで、リアクティブプログラミングのアーキテクチャ全体像を構築しようとしてはいなかった。ある関数を理解するのに、ライブラリのドキュメントは役に立たないことがある。 これを見て欲しい。 Rx.Observable.prototype.flatMapLatest(selector,
TL でこんなのが流れてたので少し調べてみた。 Learn about the Reactive Streams initiative & how we're supporting a standard for asynch stream processing on the JVM http://t.co/5wUF0PjTBe— Twitter Engineering (@TwitterEng) 2014, 4月 17 Reactive Streams って？ Reactive Streams ”JVM 上でのノンブロッキングなバックプレッシャーを持つ非同期ストリーム処理の標準の提案”（公式サイトより）。 ざっくり言うと、既にある JVM ベースの様々な非同期ストリーム処理フレームワーク実装の共通部分を括りだして API 化、SPI 化しようというもの。最終的には JSR での標準化を目指
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
