目次 1. はじめに 2. Promiseの概念を理解する 幕間：行列が嫌いな女の子 2.1 Promiseとは何か？ 幕間：実行順序 2.2 Promiseと並行処理 幕間：式の抽象化 3. Promiseのからくりを理解する 3.1. Promiseで式を順序付けする 3.2. 最小限のPromise実行 4.Promiseとエラー処理 幕間：計算失敗の場合 4.1. エラーをPromiseで処理する 4.2. Promiseの失敗の伝播 5. Promiseの結合 5.1. Promiseを確定的に結合する 5.2. Promiseを非確定的に結合する 6. Promiseの実用的な理解 6.1. ECMAScript Promiseの導入 6.2. .then の分析 7. Promiseとは相性が悪いケースとは？ 8. まとめ 参考文献 追加資料 資料とライブラリ 1. はじめに

この記事を書き始めたのは、現在使われているCSSの命名規則やスタイルの融合についての見解を Atomic OOBEMITSCSS という題名で風刺的な記事にまとめ、SitePointに投稿した数週間後です。それが8月頃のことだったのですが、この投稿はその後の私の生活に影響を及ぼしました。冗談のつもりで「 Atomic OOBEMITSCSS 」という題名をつけたがために、世間の人々はその題名を取り上げ、話題にしたのです。（正直言って、その内容について直接人々に質問することは、私にとって非常に愉快なことでした）。そして今年のSassConfで @extend の利用について議論したことがきっかけで、この見解を再検討する必要性に気づきました。 Classy CSSについて 上記で紹介した記事（「Atomic OOBEMITSCSS」）では、コンポーネントをマークアップする方法について（Pint

注釈： CASH LAYER：キャッシュレイヤ FRONT END：フロントエンド ASSET SERVE：アセットを供給 WEB SERVER W/ROUND ROBIN FAILOVER：ラウンドロビンとフェールオーバーを実装したWebサーバ THE CLOUD：クラウド ALL READS!　：全ての読み込み WRITES：書く READS：読む MASTER：マスタ INPORTANT POINTY THINGS：重要な鋭い情報 MULTI MASTER DB CLUSTER：複数のマスタからなるデータベースの集合体 「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。データベースを使ったサービスが他のサービスと関係する様子を、線や矢印で表したのが上の図です。キャッシュレイヤ、ロードバランサ、その他の複雑な形も上図の情報フロー

先日、私はBrightonで開かれたJavaScriptのカンファレンスFFConfで「(ここにライブラリやフレームワークの名前を入れる)を使おう。これこそ最強中の最強中の最強だ！」と題して話をしました。 ここに、そのプレゼンテーションの内容を書き起こします。もっと注目されるべき、最近のモバイルデバイスのフレームワークにかかるコストに関して、議論を広げる一助となればと思います。 2015年11月16日更新 – テーブルに1行、プロダクション環境下のReactについての行を追加しました。良いニュースをお伝えしますと、これはvanillaよりも3倍遅いですが、TodoMVCに関して言えば速いと言えます！PolymerのTodoMVCサンプルも最新バージョン1.2.2にアップデートされ、同様により速くなりました。 読むよりも見たい方へ、講演のビデオはこちらです。（必要なら、 スライドも入手できま

他のフレームワークやライブラリから React に乗り換える人たちは、「ReactはUIのレンダリングに関する問題しか解決しておらず、状態管理とアプリケーションアーキテクチャの選択は開発者に委ねられているのだから、どうやってアプリケーションの状態を管理したらいいのか？」 と疑問に思う傾向があります。FacebookはReactのレンダリングモデルに適している、 Flux と呼ばれるアーキテクチャを勧めています。 この記事では、UIレイヤとしてReactを用いてJavaScriptのアプリケーションの状態を管理する方法を探り、 Om のような ClojureScript ライブラリのアイデアを用いてFacebookのFluxの抽象的なフレームワークを作り変えてみたいと思います。 Fluxの核となる考えは、 データは一方通行で流れるべき というものです。これによってアプリケーションの論証が簡単

(注：2015/11/18、記事およびタイトルを一部修正いたしました。) CNN.com で働いていた2012年6月に、大統領選挙投票日の夜のユーザエクスペリエンス（以後UX）のデザインを任されました。私はそれからの6カ月間を投票日の夜のための仕事に専念しました。しかし、仕事が成功するかしないかは、選挙結果に関係はありませんでした。私が懸念していたのは、情報の見つけやすさやデータの見やすさ、canvasでのオブジェクトの変形、そして一体どのようにしたら、iPhoneでマウスオーバーのフライアウトが動作するのかでした。CNN.com史上初めてWebデザインをレスポンシブにすることにしたのです。さらに史上初めて私が、その デザイン を担当することになったのです。 大きな賭けでした。CNN.comにとって大統領選挙投票日の夜と言えば、スーパーボウル（プロアメリカンフットボールの優勝決定戦）の日曜

—もはやOOP（オブジェクト指向プログラミング）は”クラウドモンスター”から私たちを守りきれない おそらくあなたは、”Clojure”、”Scala”、”Erlang”といった言葉や、”Javaにラムダ式が導入された”という話を聞いたことがあるでしょう。そしてそれらの言葉が”関数型プログラミング”と関連があるのをご存じかもしれません。プログラミングコミュニティに参加していれば、おそらく既にこのテーマが議題に上がっているでしょう。 Googleで”関数型プログラミング”を検索しても、目新しいものは何も見つかりません。言語の中で2番目に古い言語は、関数型プログラミングを利用しています。1950年代に登場した、Lispという言語です。では一体なぜ人々は、今になって関数型プログラミングに沸き立っているのでしょうか？　およそ60年も経っているのに？ 初期の頃、コンピュータは実に遅かった 信じられない

私はテスト駆動開発（TDD）について、Kent Beckの著書『 Test-Driven Development By Example 』（邦訳『テスト駆動開発入門』）で学びました。これは大変優れた入門書で、TDDにますます関心を持つようになった私は、さらにSteve FreemanとNat Pryceの著書『 Growing Object-Oriented Software, Guided by Tests 』（邦訳『実践テスト駆動開発：テストに導かれてオブジェクト指向ソフトウェアを育てる』）を読みました。この本も私のお気に入りです。 ただし、両書には弱い部分もあります。現代の静的型システムがテストを補ったり、場合によっては置き換えたりできるかもしれないことには、全く触れていないのです。このような本を読んだだけでは、”typing”（型付け）と聞いてもキーボードの”タイピング”のほうを考

科学はその方法論上のイメージよりもはるかに”ぞんざい”かつ”非合理的”なものである。 Paul Feyerabend著『Against Method（方法への挑戦）』（1975年） プログラミング言語は魅力的な分野です。それは、計算機科学（と論理）を 社会学や人間とコンピュータの相互作用 、科学的に定量化できない直感や嗜好、そして（良くも悪くも）政治などを含む分野と結び付けてくれるからです。 プログラミング言語を話題にする場合、たいてい何らかの客観的な真実を追求する科学的議論になってしまいます。科学は完璧のオーラに包まれているため、科学的本質の核心部だけに集中し、他の部分を無視するのが正しいプログラミング言語の考え方だと単純に思ってしまうのも無理ありません。 しかし、これではプログラミング言語を面白くしている多くのものが除外されてしまいます。この隙間を埋める1つの方法は、科学の哲学に目を向

Scalaの型システムが先進的であることは、皆さんもご存じのことかと思います。この投稿では、Scalaの型システムのみを使った クイックソート アルゴリズムの実装方法をご紹介したいと思います。なお、ここで紹介するデモの完全なコードは こちら をご覧ください。 自然数 まずは準備から。ソートアルゴリズムを実装するには、ソートする対象が必要ですよね。ここでは自然数を用います。もちろん、Scalaの型システムには利用可能な自然数はありません。そんなわけで、全ての自然数の型を作る必要があります。 型を無限に作るというのは、恐らく時間の浪費になるでしょうから、ここはもう少し賢い手を考えます。そう、数学を使いましょう。 ペアノの公理 ペアノの公理とは、自然数を形式的に定義するためのシンプルな方法のことです。 0 は特別なものとする。 0 は自然数である。 全ての自然数 n には、それに続くもう1つ別の

私の小論 “In Search of Types” では、プログラミングで使われる“型”という言葉の概念や目的、考え方について、公平な批評を心がけました。所々で、私の真剣さを感じ取っていただけるはずです。このブログ記事では逆に、思い切って堂々と批評していきます。いくつかの意見や考え方に、私は苛立ちを隠せません。先日参加したStrange Loopでも、このような状況に陥りました（補足しますが、すばらしいコンファレンスでした）。この機会に、“型”について多くの人が（誤って）語った“重大な誤り”をリストアップしていきます。 ここで話す内容は、説得力のあるものです。私が苛立ちを覚えるのは、人々が正当かつ透明性のある議論を行っていないことに対してです。結論に誤りがあってはいけません。私は、OCamlである程度の数のプログラミングを行っており、それは型チェックから多くの価値を得ることができるシンプル

Gitは速く柔軟性がありますが、理解に時間のかかる分散型バージョン管理システムです。Gitを始める前に次を理解しておきましょう。 通常のバージョン管理 分散型バージョン管理 本 や 学習書 、 指南書 はGitを理解するのに役に立ちました。しかし、その他にもGitの理解に至ったきっかけがありますのでご紹介します。 ステージング・エリアがある Gitにはステージング・エリアがあります。繰り返しますが、 ステージング・エリアがあるのです 。 これには混乱しました。リポジトリ（「オブジェクトデータベース」）とステージング・エリア（「インデックス」と呼ばれる）の両方がGitにはあります。チェックインには2段階あります。 git add foo.txt インデックスにfoo.txtを追加します。これだけでは、チェックインは完了していません。 git commit -m "message" リポジトリ

以前の記事で、 Webアプリケーションのデバッグの仕組み について触れました。今回は実践的なJavaScriptのデバッグについて掘り下げていきたいと思います。 ブラウザデベロッパツール 私の個人的なお気に入りはChromeデベロッパツールです。SafariやFirefoxはChromeほどの高水準に達していません。しかし、徐々に改善されてきています。FirefoxにはFirebugと改良されたFirefoxデベロッパツールが組み合わされた機能が備わっています。もし、Firefoxチームがビルトインされているデベロッパツールの改良の中で素晴らしい仕事をし続けたとしたら、Firebugはいつか、すたれるかもしれません。 個人的な好みにかかわらず、ターゲットとするあらゆるブラウザで、全てのコードのテストやデバッグができるようにすべきです。”あらゆるブラウザ”には、かの有名なInternet E

私はポストモーテム（事後分析）の記録を読むのが大好きです。ポストモーテムを読むと勉強になりますが、大抵の教材的資料とは違って、興味深いストーリーが含まれているのです。相当な時間をかけてGoogleとMicrosoftのポストモーテムを読みました。大きな障害を招く最大の原因について、私は（まだ）きちんと分析していませんが、何度も繰り返し目にするポストモーテムのパターンがいくつかあります。 エラーハンドリング 適切なエラーハンドリングのコードを書くのは難しいものです。エラーハンドリングのコードに含まれるバグは、 大きな 問題を引き起こす主な原因となっています。つまり、エラーによってバグのあるエラーハンドリングのコードが実行されるということは、単に個々のエラーが重なるだけという事態にはとどまらないのです。障害が重なって重大なシステム停止につながることはよくあります。それはある意味明らかなことで、

コード中にコメントを書くべきでしょうか？　是が非でも避けるべきでしょうか？　それとも控えめに書けばいいでしょうか？　開発者たちはそれぞれ、ソフトウェアを開発する際にどのように、そしてどんな時にコメントを書くかについて、独自の考え方を持っています。この記事では私の意見を述べますが、これが誰にも当てはまるというわけではありません。 なお、関数型プログラミングまたはオブジェクト指向プログラミングの原則に則ってJavaScriptで書かれたソフトウェアに絞った上で、私の意見を述べることにします。 コメントと保守性 この記事では、保守性のあるコードを書く場合について考えます。つまり、以下のようなコードです。 簡単に理解できる 簡単に拡張できる 簡単にデバッグできる 簡単にテストできる 保守性のあるコードには、大量のコメントが必要でしょうか？　明確に書かれたコードであるならば、大量のコメントは不要だと

想像してください。あなたは今、オフィスにいます。周りとは仕切られた個別スペースです。今週は、近々新たに展開する予定の製品を紹介するために多くの時間を割いてきました。疲れが溜まり、不機嫌ぎみになっています。今はようやく近づいた週末が待ち遠しくて仕方ありません。 しかしその前に、新製品を紹介するホームページがWindows 10で正常に動かくかどうかを試してみなければなりません。あなたは問題ないはずだと信じています。あなたが信頼を寄せているMacには、Windowsを問題なく実行できるソフトもインストールされています。 ソフトを起動してみると、丁寧にもWindowsがポップアップ通知で可能なアップデートがあることを知らせてくれます。もちろんアップデートを開始するため、あなたは了承します。 すると、こんなものを目にするのです。 訳：何かが発生しました。 何かが発生。 新製品の準備のため期限が迫っ

ここ最近、CSSに対する考え方が広がりを見せています。皆さんの中には、その転換点を見つけようと、Christopher Chedeauの”CSS in JS”という講演を聞いた方もいるでしょう。2014年11月にNationJSで行われたこの講演は、CSSにおける重大な分岐点となりました。まるで高エネルギー粒子が衝突した後のように、それを機に、数ある多様な考え方が、各々の方向へ渦を描くように広がったのです。その例として、 React Style と jsxstyle 、 Radium を挙げましょう。これら3つは、Reactのスタイリングにおける最新かつ最良、そして最も実行しやすいアプローチに含まれており、 各々のプロジェクトのReadmeファイルでも、 そのように言及しています。もし”発明”が、 adjacent possible（一歩先にある可能性） を探ることの一例であるのなら、Ch

データマネージャ このステップで、クエリマネージャはクエリを実行するので、テーブルとインデックスからデータを取得する必要があります。そこでデータマネージャに対してデータを取得するよう要求するのですが、ここで次の2つの問題が発生します。 リレーショナルデータベースはトランザクションモデルを使用しています。この場合、「いつでも・どんなデータも取得できる」というふうにはいきません。どこか別の場所で、ここに格納されているデータを同時に使用したり更新したりしている可能性があるからです。 データの取得は、データベース内で実行する処理の中で最も時間のかかるもの です。従ってデータマネージャはそれを見越して、メモリバッファにデータを取得しておき、それを保持しなければなりません。 このセクションでは、リレーショナルデータベースがこの2つの問題にどう対処しているかを説明します。なお、データマネージャがデータを

Sift Scienceで製作にReactを使い始めてからほぼ1年になりました。その間、Backbone+Reactという フランケンシュタインのような 複合アプリケーションを、Reactコンポーネントからなる、かなり大きな1つの階層に育て上げました。この記事では、UI不和を最小限にしながら、コードベースをスケーリングするために役立った技法とベストプラクティスを紹介します。また、一般的なコンポーネントのデザインパターンについて、いくつか説明します。 この記事が皆さんの時間の節約と精神衛生の維持に役立ち、UIが複雑になってもReactコードベースの保全性を維持する（破綻するのではなく）ための新しいツールを提供できれば幸いです。 componentDidUpdateで、もっとできる Reactの本質は、DOMの更新というタスクを命令的なものから宣言的なものに変えるということです。他のタイプの命

恒等モナド Maybeモナド リストモナド 継続モナド Do 記法 連鎖呼び出し モナド とは、一連のステップによって実行する計算を記述する際に使用する、1つのデザインパターンです。 純粋関数型プログラミング言語 では、モナドは 副作用を管理する ために広く利用されていますが、 マルチパラダイム言語では、モナドで複雑性を制御することもできます 。 モナドはデータ型をラップして、空の値を自動的に伝播したり（ Maybe モナド）、非同期コードを簡略化したり（ 継続 モナド）といった、新たな動作を既存のデータ型に追加します。 一連のコードをモナドと見なすためには、その構造には次に挙げる3つの要素が含まれていなければなりません。 型コンストラクタ — 基本的な型に対してモナドの動作を追加した型を作成する機能です。例えば、基本的なデータ型 number に対して、 Maybe<number> とい