関数型リアクティブプログラミングにさよならを - Qiita
以下の記事は、Evanの許可を得て A Farewell to FRPを訳したものです。 訳者はElm初心者ですので、理解が足りてない箇所があるかと思われます。何か誤りやベターな記述がありましたら、ご指摘いただけると幸いです。 ちなみに、関数型リアクティブプログラミング全般の話ではなく、あくまでElmに関する話です。 ElmアーキテクチャはWebアプリを設計するためのシンプルな手法です。Elmを書くならばElmアーキテクチャに沿うのが普通ですし、ElmはReduxに影響を与えています。ElmアーキテクチャはもはやJavaScriptを書く際の手法としても人気になりつつあります。しかし、いまだにこんな疑問を耳にすることがあります。WebSocketをElmアーキテクチャで使うにはどうすればいいのか？あるいはGlaphQLは？あるいはGeolocationは？ 今日Elmのバージョン0.17が
「リアクティブプログラミングが読み難い」というのは本当なのか? - Qiita
追記(2017/05/2) redux-sagaでの非同期バージョンの紹介とリンクを追記。 追記(2017/2/23修正) 元記事の追記3にて言及を頂いたように、以下の「見易い版」コードは元コードが実現していた機能が抜けおちているという誤りがあります。遅くなりましたが、お詫びの上修正させていただきます。 修正内容は以下の「refreshボタン押下ですべての候補を消去」の項目に追記しました。 上記追記の趣旨として、リアクティブプログラミングはそれほど判り難いのだ、というご指摘になっていますが、返す言葉もございません。 はじめに 先日「リアクティブプログラミングとは何だったか」という記事を目にしまして、内容はたいへん興味深かったのですが、以下の記述がありました。 『宣言的』といえそうなのはわかりますし、パラダイムとして従来のコードとは一線を画すものであることは確かですが、どう贔屓目にみてもひた
RxJSでMVVMやってる - @hadashiA
Rxは、すごくUIを書くのに向いているのではないだろうか。アプリケーションの状態を山盛りの変数で管理することから解放され、状態から状態へ変換する関数を書けばよくなるから。 非同期処理を同期っぽく書きたいならawait でいいじゃん。UIイベントを宣言的に書きたければ 2-wayバインディングがあれば良いじゃん。という話では終わらず、その辺の問題解決に加えて、値の発生器を全て同じ宣言にまとめられ、状態変数がなくなるところが書いていて楽しいところです。 // たとえば、、 Observable.fromEvent(searchBox, 'input') // 検索窓に字が打ちこまれたら .debounce(500) // 0.5秒ごとに .map(e => e.target.value) // 入力されたテキストを .filter(q => q.length > 0) // 1文字以上の場合だ
リアクティブ宣言
異なる分野で活動する組織が、同じようなソフトウェア構築のパターンを独立に発見している。このようなシステムはより堅牢で、より耐障害性があり、より柔軟で、より最新の要求を反映しやすくなっている。 こうした変化が起きているのは、近年、アプリケーションの要求が著しく変化してきているからだ。ほんの数年前、巨大アプリケーションは数十のサーバから構成され、数秒の応答時間と数時間のオフラインメンテナンスを許容し、データは数ギガバイトだった。今日のアプリケーションは、モバイル機器から数千のマルチコアプロセッサによって動作するクラウドベースのクラスタまで、あらゆる機器上に配備される。ユーザはミリ秒の応答時間と 100% の稼働率を期待する。データはペタバイト単位で測定される。昨日のソフトウェアアーキテクチャは、今日の要求を全く満たしていない。 求められているのは、システムアーキテクチャに対する明快なアプローチ
JJUG ナイトセミナー 「Reactive Streams特集」の感想 - AOEの日記
6/24 に開催された 【東京】JJUG ナイトセミナー 「Reactive Streams特集」 に参加してきました。これはその感想エントリになります。 ここ最近は勉強会に参加しても、それについてのエントリを書くのをサボってましたが (^^;; 、今回の勉強会は自分にとって非常に考えるところが多かった内容でしたので、ちょっと思ったところをだらだらっと並べてみました。 勉強会について 勉強会の内容は 2 部構成になっていました。前半は岡本雄太 (id:okapies) さんによる「Reactive Streams 入門」で、Reactive Streams について、似た言葉である Reactive Programming や Reactive Manifesto と併せて、それぞれの概念の違い、関わりについて分かり易く説明してもらいました。 https://speakerdeck.com
Rubyベースの文法でJavaScriptにコンパイルされるAltJS-Opal言語とReactiveなWAF Voltの情報まとめ #opal #ruby - Tbpgr Blog
Rubyベースの文法でJavaScriptにコンパイルされるAltJS-Opal言語とReactiveなWAF Voltの情報まとめです。 2015/06/30 時点の内容をまとめました。 Official Site Opal Official Docs Opal Docs GitHub Opal - GitHub Playground 環境構築せずにPlaygroundで試せます。 Playground - Opal Volt - Web Application Framework Links Volt Framework Official Volt Framework - GitHub Volt Docs(English, Japanese 選択可能) What is Volt? Qiita Opal Ruby で JavaScript を書く、 Opal を使ってみる 最近のOpal
RxJavaに3日で入門し、Androidアプリのリスト操作、非同期処理、変更通知の課題を解決した話 - Qiita
なんでこの記事書いたのか 今開発中のプロダクトにおいて、RxJavaの導入をやってみたので、実際に使った箇所とその例、調べないとわからなかったことを載せておきました。 そう（retrolambdaのためにjdk8を投入）までして導入したかったメリットを話してくれ、サンプルコードがないとわからん、といった声を頂いているので、実際に何が解決されたのか、どんなコードで解決したのかということと、そのために勉強しなくてはならなかった点について書いています。 （追記）警告：差分作ってコード上では解決したんですが、この差分まだ「リリース」したわけじゃないので、その点だけご注意くださいｍｍ 続報あり次第追記します。 追記：リリースして安定運用しています！最近まで監視に難がありましたがそれも修正しました。この記事の監視スニペットも更新済みです！ なぜRxJavaを導入したのか 次の課題をまとめて解決できるの
銀の弾丸は川から流れて来ない - saneyuki_s log
The Evolution of Flux Frameworks — Mediumを読んだ。自分がここ3ヶ月～半年くらい考えてたことと殆ど一緒で、若干の安心感を得たり。実装論の話も概ね同意ではあるのだけれど、自分は必ずしも同意しかねる面がある。 今のメモリマネージド言語のトレンド、特にクライアントアプリケーションの存在を想定したアーキテクチャは、C#が筋道を立てた実践理論に追随してる面があるので、過程はどうあれ、彼らの先端スタイルに近づいていくことになると思うのよね。 Fluxパターンの話をすると、あれが偉かったのは「疎結合すると色々楽になるから、オブザーバーパターンにして、コマンドパターン使って、コマンドは単方向にすると破綻しにくい割に弄りやすいよ」ってのを、フレームワーク症候群に陥っていた凡百なWebクライアントサイドに、一発、投げつけた辺り（というのは半年くらい前に書いたな……）。
RxJSをもくもくしてReactivePropertyの価値らしきものを気づかされた話（仮） - saneyuki_s log
Reactive Extensions JS port（RxJS）をもくもくしていた結果、C#界隈がReactive Propertyを作り出した理由が（なんとなく）わかってきた。 Rxの流儀にのっとれば、ある値を使おうとする場合、その値を生成するObservableの結果を受けて、そのObservableも同様に……とObservableの依存関係を作っていく必要がある。 Rx.Observable.do()メソッド中に、関数外のグローバル変数などを副作用なmutateをさせてもいいが、これは基本的によろしくない。Rxで実行される各Observerが、一体どのタイミングが動作するかの順序保証が本来的には存在しないためだ。イベントループがひとつしかない & Workerは完全にメモリ空間が分割されたアクターライク & Rx.SchedulerもDOMのイベントループ原則に則るJavaScr
Introduction to Reactor & Reactive Streams
Task scheduling can be boring, but not with Symfony Scheduler
2010-12-26
リアクティブプログラミングは、「時間とともに変化する値」＝「振る舞い」同士の関係性を記述することでプログラミングを行うパラダイムです。 GUIなどのようにインタラクティブなシステムや、シミュレーションやアニメーションのようにダイナミックに状態が変化するようなシステムを宣言的に記述することができます。 これらの「変化する状態」や「外部とのやりとり」が支配的なシステムは、純粋関数型言語が、その強みを発揮しにくい部分でもあります。 本稿では、リアクティブプログラミングが副作用を含む系を宣言的に記述することを可能にし、状態の管理という厄介な問題からプログラマを開放する可能性があることを示したいと思います。 （割と独自研究に基づく解釈ばかりなのでその点ご了承ください。あと例としてでてくるコードは、Pythonベースの擬似コードで具体的なライブラリに基づくものではありません。） Why Reactiv
ReactiveX と「普通のやつらの上を行け」の意外な関係 - Okapies' Archive
これは「関数型プログラマのための Rx 入門」の補足記事です（タイトル変えた）。 前編、後編とお送りしてきたこの記事だが、特に後編について「何を言ってるのか分からん」というコメントを何人かの方から頂いた。…なんというか、ごめんなさい。 繰り返しになるが、Rx を使う上で関数型プログラミングの知識は必ずしも必要ではないし、むしろ（関数型のコンセプトが基礎にあるのに関わらず）知らなくても使えるようになっている。ライブラリの作者たちは「過度な抽象化は害になる」ということを弁えているのだろう。 しかし、Rx と関数型プログラミングの関係を把握しておくと、非同期データストリームのビルディング・ブロックの作り方について大いに視野が広がるだろう。もし、貴方がこの記事の前提となる「関数型」のパラダイムに興味をお持ちなら、まずは「関数プログラミング実践入門」をお勧めしたい。 関数プログラミング実践入門 ──
【Akka】Akka Streamsがめっちゃ便利すぎて脳汁が出た話し | Scala Tech Blog
こんにちは！Smalgoの來田です。 注意：タイトルは過激ですが内容至って普通なチュートリアル記事です。 仕事でWorkerを作った時に使ってみてめっちゃ便利だと思ったのでAkka Streamsについて書きたいと思います！ まだまだ中の実装の深いところまで追えてるわけじゃないので間違っていたら教えてください。 Akka Streamsとは Reactive Streams（ノンブロッキングでback pressureな非同期ストリーム処理の標準仕様）のAkka実装 Back Pressureとは 非同期なストリーム処理の場合下記の問題が起きる Publisher側の処理が早い場合Subscriber側のバッファーが溢れてしまう Subscriberに遠慮してPublisher側の処理を抑えた場合は無駄が多くなってしまう それをSubscriberが自分が処理できる量をPublisherに
RxのHotとColdについて - Qiita
UniRxについての記事のまとめはこちら RxのIObservable<T>にはHot/Coldという大きな2つの特徴があります。 これら性質を理解しないままストリームを設計すると、意図した動作をしてくれない場合があります。 今回はこのHot/Coldの性質について簡単にまとめたいと思います。 概要 一言で言うと？ Cold : ストリームの前後をつなぐだけのパイプ。単体では意味が無い。だいたいのオペレータはこっち。 Hot : ストリームから値を発行し続ける蛇口。常に垂れ流し。後ろにパイプがたくさん接続できる。 細かく説明すると Cold Observable 自発的に何もしない受動的なObservable Observerが登録されて（Subscribeされて）初めて仕事を始める ストリームの前後をただつなぐだけ。ストリームを枝分かれさせる機能は無い。 Hot Observable 自
What is Reactive Programming?
To understand Reactive — both the programming paradigm and the motivation behind it — it helps to understand the challenges that are faced by developers and companies today compared to the challenges faced only a decade ago. The two major game changers for developers and companies are: Advancements in hardware.The Internet.While “gathering around the campfire to discuss the olden days” is consider
2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 - Qiita
はじめに もうすっかり年末なので、これから2015年にかけてアプリケーションアーキテクチャがどのようになっていくのかという個人的な考え/妄想や背景について、「リアクティブ」というキーワードをもとににまとめてみたいと思います。 Google Trendsを見ると"reactive programming"という言葉は2010年前後から、ゆっくりとバズをし始め、現在も上昇を続けています。 また、仕事としては、2010年ごろから大規模なWebサービス開発において、フロントエンド、バックエンド、アルゴリズム改善といった様々な箇所で、リアクティブプログラミングの要素を取り入れながら、アーキテクチャの改善を進めてきました。そのため、こういったアーキテクチャがコード品質の維持や安定性の向上、実際的で複雑な問題の解決にも適応可能であるということを実感として持っています。 近年、そういった要素が様々なツール
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リアクティブ・アーキテクチャ ～大規模サービスにおける必要性と課題〜 #devsumi
Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3
Reactive Streams 入門 #jjug
State, Promises, and Reactive Programming
