Passive/Reactive プログラミングの違いを学ぶ - Qiita
MVI (Model-View-Intent) を学ぶために、Cycle.js の Observable のチュートリアルから Passive と Reactive の違いの解説を翻訳しました。ライセンスは原文と同じ MIT ライセンスとします。筆者の André Staltz さんが公開しているスライド (How Reactive Programming can help reduce code spaghetti ) は補助資料になるでしょう。Staltz さんは「Reactive ではデータの変更は遠くから観察される」「Passive ではデータは遠くから変更される」とも述べています (twitter、Redux と RxJS の違いは？)。 モジュール Foo とモジュール Bar があるとします。モジュールは OOP クラスのオブジェクトもしくは状態をカプセル化するためのほかのメ
アプリの外側とのやりとりをModelから取り除く - ✘╹◡╹✘
変更前 これはクライアントサイドのアプリケーションの例で、Modelの背後でWeb APIやonpopstate/pushStateを利用しており、Modelが太くなってる様子。 HTTP History | ^ | ^ | | | | v | v | .---- View <-- M o d e l <-- Intent <--. | | `----------------> DOM -------------------' 変更後 Web APIもonpopstate/pushStateもアプリケーションの外側にあり、DOMと同レイヤに存在するものであると位置づける。アプリケーションの外界とのやりとりを行う、ビジネスロジックを含まないアダプタを、ドライバーと呼んで抽象化する。ドライバーには入力を受け取る機能と出力を購読させられる機能がある。いまつくってるアプリでは以下の2つのドライバー
MVI (Model-View-Intent) と MVC との違い - Qiita
Cycle.js の MODEL-VIEW-INTENT のチュートリアルから MVI (Model-View-Intent) と MVC (Model-View-Controller) に関する説明を抜粋して翻訳しました。原文のライセンスは MIT です。 「Passive/Reactive プログラミングの違いを学ぶ」 をあらかじめ読んでおくと理解が深まるでしょう。筆者の André Staltz さんは Flux、Redux などのアーキテクチャの比較や評価を UNIDIRECTIONAL USER INTERFACE ARCHITECTURES と NOTHING NEW IN REACT AND FLUX EXCEPT ONE THING の記事で述べています。 MVI (Model-View-Intent) について MVI は Cycle.js の main() 関数を3つの
Redux っぽく Rx で実装しようとして結果的に Cycle.js に惹かれる話 - Qiita
はじめに Flux のような unidirectional なアーキテクチャに興味があって、評判のよいものに触ってみた感じです。 実際に業務でやってみたことはないので、ガチ勢の方から見たらまだまだ甘いと思われる点が多々あるかもしれません。 TL;DR (投稿から一日たって少し考えがまとまってきたので追記) Redux の印象 before 思想は分かりやすい (Three Principles) アプリケーションの状態 (state) を単一の store で管理 state は read-only (直接更新できない), 更新は action の発行を介して行う state を更新する reducer は純粋な関数 でも action.type で switch する書き方が好きになれない Rx で簡単に re-implement できるとのことなので、 switch なしで書けるように
ES6、React、RxJS、Cycle.js に関する調査 - Qiita
React と Cycle.js を学び始めると、Twitter のつぶやきを含めて、こまごまごしたことを調べる必要があり、記憶力の限界を超えたので、自分の関心の変遷を振り返りながら、情報源をまとめました。ES6 の実装の課題とおよび将来の ES.next の標準化の動きについても併記しました。 プログラミングスタイル 新しい機能をなぜ導入するのかについて振り返るために QCon Tokyo 2013 の Douglas Crockford 氏の講演を文字に起こした記事 (前編、後編)を読んで印象に残ったことを抜粋しました。 スタイルは間違いを減らすためにある スタイルは個人の嗜好や自己表現のためではなく、間違いを減らすためにある。 わるいスタイルを採用する人の典型例は勉強不足な人、古い教育を受けた人、スリルを好む人、自己顕示欲家。 めったに起きないと思っていることはいずれ起きる。 エレガ
cycle.jsでのMVI分割時にどう考えてるか - ✘╹◡╹✘
実装していくうちにレイヤやシステムの境界に対する認識が変わってきたので現状を整理。 Intent アプリ外部から受け取った入力をアプリ内部で使える語彙・データ形式に変換するためのアダプタ。アプリ外部からの入力を解釈して、アプリに何をしてほしくてそれを入力したのかを判断し、その要求をModelに伝える。「xxxが起こった」という形式ではあまり良くなくて、「xxxしてほしい」という形式になるのがベストという理解をしている。 例: ボタンがクリックされたので記事を作成してほしい (DOM経由の入力に反応する例) 例: 記事が作成されたので記事を表示するページに遷移してほしい (HTTP経由の入力に反応する例) Model Intentからの入力をもとに状態の管理を行う。状態は変数に格納するとかではなくて、Observableの中に生き続ける。Elixir/Erlangやったことがある人は、Age
エディタの実装をcycle.jsでMVIベースにしてみた話 - ✘╹◡╹✘
最近Electronでエディタをつくっており、最初はReact.jsを使いながらゆるいFlux風の設計でつくっていたのを、cycle.jsを使いながら一部をMVI風の設計に置き換えてみた。400行程度の一画面のコードだったので3時間ぐらいで置き換えられて、前よりも責務が適切に分割されるようになったので、本体部分も次の機能追加時に置き換えようと思っている。 とりあえずプレビュー画面だけ置き換えた 置き換えたのは、編集中のファイルを別画面でプレビューとして表示する画面で、ただプレビューするだけの機能のほかに連続したスライドとして表示するプレゼンテーション機能もある。1つ前のブログ記事を見てもらうとわかりやすいと思うけれど、次の画像のようなやつ。ボタンをクリックしてモードを切り替えたりキーボードを使って移動したり、またエディタ側でファイルの内容が書き換わったりと、それっぽく言えば幾らか動きのある
船員さんが足りなすぎてたぶん日本は死にます。
船員さんの高齢化がマジでヤバイ。 どんぐらい足りないかって言うと年金生活したい船員さんを土下座して引き止めるくらい。 会社はいえないけど80歳の船長さんがいるくらいだし噂じゃ90代もいるらしい。 統計で見ると50歳以上が全体の56％で60歳以上も25.2％って状態。 内航海運は日本の物流の半分を担ってるのに若い人が全然来てくんない。 いや来るけどすぐやめちゃう。なんでかというと ・激務（航行と荷役ができるギリギリの最少人員で常に回しているので一人あたりの負担がでかい）※ ・3ヶ月乗船1ヶ月休暇という勤務形態が不人気 ・の割に給料あんまり良くない（上の要因の割に合わない、金額だけで見たらそこそこ良い） ・上述のように狭い船内でお爺ちゃんとおっさんと同世代がいない中で3ヶ月間顔つき合わせて働く が理由。 まあカネさえあれば、乗員の数も増やせるし、給料もよく出来るんだけど 荷主がマジで鬼のように
「現在時刻」を外部入力とする設計と、その実装のこと - クックパッド開発者ブログ
こんにちは。技術部 開発基盤グループの諸橋です。 クックパッドでは昨今の多くのWeb企業と同じように、GitHub EnterpriseのPull Requestを使ったコードレビューを広範に実施しています。わたしたちのコードレビューでは、ソースコードの字面にとどまらず、サービスの機能として魅力的かどうかや、保守性を含めた設計が適切かといった議論に発展することも良くあります。 きょうはそんななかで話題に上がった「現在時刻」の扱いかたに関する設計の話を書きます。 背景 サービスを開発・運営している我々には、時間帯によって出し分けたり、特定の期間のみに表示したいコンテンツがたくさんあります。 そのたびにデプロイし直すというのはつらいので(特に24:00に出なくなるコンテンツなど)なんとかしたくなりますが、一方で時限式のコンテンツはその時になるまでちゃんと動いているか確証が取れないので怖いです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News