目次 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. はじめに

ブロックチェーン の基本的な概念は非常にシンプルです。分散型データベースで、順序付けられたレコードのリストが連続的に増加していきます。しかしシンプルとは言え、ブロックチェーンやそれを使うことで解決しようとしている問題について話をする際に、頭を悩まされることがよくあります。これは、 ビットコイン や イーサリアム といった、一般にもよく知られているブロックチェーンベースのプロジェクトでよく聞かれる話です。「ブロックチェーン」は、 取引 や スマートコントラクト 、または 暗号通貨 といったコンセプトと強い結びつきがあります。 そのため、本来シンプルであるべきブロックチェーンの理解がより困難になってしまっています。抜け目のないソースコードであれば尚更です。 そこで、 NaiveChain という、200行のJavascripitに実装した、非常にシンプルなブロックチェーンを紹介したいと思います

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

イントロダクション 数ヵ月前、広く成功を収めており、非常に役立つ“10個のシンプルなルール”シリーズの提唱者であるPhil Bourneは、何人かの統計学者に統計に関する10個のシンプルなルールの記事をまとめることを提案しました。（そのルールのうち「PLOSでTen Simple Rulesの記事を書くためのルール」はPhil Bourne ^(1) のものです。その代わり、Philに対するあふれるほどの賞賛で満足してくれると思います。） 10個のシンプルなルールを書くガイドライン ^(1) の中で示唆されているのは、「自分の読者を知りなさい」ということです。私たちはルールのリストを、研究者を念頭に置いて作り上げました。研究者は統計に関する幾分かの知識を持ち、同じビルに少なくとも１人は統計学者がいたり、あるいは健全なDIY精神と、ノートパソコンの中に統計のパッケージを持っていたりするかもし

最小限の設定のTDD手法を使い、「何をテストすべきか？」から、よくある落とし穴の避け方まで、Reactコンポーネントをテストする方法を学びましょう。 導入 まず、 React を触ったことがあり、更にはいくつかのテストも書いた経験があるとしましょう。それでも、コンポーネントをどうテストするのが最善なのか、よく分からないかもしれません。どこから始めるのでしょう。具体的には何をテストすればよいのでしょうか。 いくつかのReactコンポーネントは簡潔過ぎて、そもそもテストが必要なのかすらはっきりしません。 AngularからReactに乗り換えた 人なら、テストには愛憎のような思いがあるかもしれません。 確かに Angular にはテストを支援するツールがたくさんありますが、同時にテストを書くのが難しくなる可能性があります。冗長ながら省略できない定型コードが多々ある上、 $digest の呼び出

最近、普段以上にChromeの開発者ツールを使うことに時間をかける機会がありました。その過程で、自分が今まで気づいていなかった機能をいくつか見つけました（少なくとも今までその機能を探す必要に迫られていなかった、とも言えるのですが。例えばブラックボックス化や非同期のスタックトレースなど）。そのため、開発者ツールでとても気に入っているいくつかの機能についてまとめてみたくなったのです。 小さな虫眼鏡ののアイコンは、特定の要素やCSSプロパティに対して、「どのCSSファイルに書かれているどのセレクタ/クラスが最終的なスタイルを決めているか」を示してくれます。例えば、どれかDOM要素に対して「要素を検証」を選び、右側の「Computed」というタブを選びます。確認したいCSSプロパティを見つけてその虫眼鏡アイコンをクリックすることで、すぐさま右側に正しいCSSファイル内のクラス/セレクタを表示してく

データを扱うときに、きちんと定められたワークフローがあると助かります。具体的には、「ストーリーを伝える」（データの可視化／ジャーナリズム）ことだけを目的として分析を行いたいのか、それとも一定のタスク（データマイニング）をモデリングするためにデータに依存するシステムを構築することが目的なのか、プロセスが重要です。前もって方法論を定めておくことによって、チームの足並みが揃い、次に何をすべきか考え出そうとして無駄な時間を費やさなくて済みます。それによって早く結果が得られ、資料の公表も早くなります。 これを念頭に、Ashley Madisonの漏洩データ分析に関する 前回の記事 に続いて、私たちが現在使用しているワークフローをご紹介します。このワークフローは、データ漏洩（Ashleyのケースなど）を分析するためだけでなく、社内のデータの分析にも使用されます。ただし、重要な点として、このワークフロー

JavaScriptはとても強力な言語です。強力がゆえ、実はプロトタイプをデザインしたり、オブジェクトのインスタンスを生成したりするのに何種類もやり方があります。それぞれの方法には長所も短所もあります。そこでJavaScript初心者の皆さんのために私がそのあたりを整理して説明したいと思います。今回の投稿は、以前私が書いた 「JavaScriptを分類するな」 の続編です。前回の投稿でたくさんのコメントをいただき、コードの例を出してほしいをいう反応をいただいたので、今回はそれらにお応えします。 JavaScriptはプロトタイプを使って継承 つまり、JavaScriptでは、オブジェクトは別のオブジェクトを継承することができます。 { } 波括弧を使って生成されるJavaScriptの基本的なオブジェクトは、唯一のプロトタイプとして Object.prototype をプロトタイプに持ちま

調査：Subredditsに投稿される肯定的・否定的意見の分析 先週、私は 素晴らしくて、少し笑える非公式の調査 を偶然見つけました。これはTobias Hermann(ハンドルネームは Dobiasd )が行った調査で、subredditのフィードから20以上のプログラミング言語に関するスレッドを探し出し、ユーザ同士のやりとり、コメント、意見を再度見直したものです（警告：ユーザによる不適切な投稿もあるので、職場での閲覧には注意が必要です）。それでも、私はTobiasの調査内容をとても気に入り、Typesafeのブログに記事の投稿を打診するため、そして、なぜ彼がこのような興味深い実験を行ったのかの理由を聞くために、彼にコンタクトを取りました。彼はとても謙虚でありながら、その返事からは好奇心がみなぎっていることが感じられました。以下がTobiasからの返事です。 “正直、どうして私がこのよう

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

前回は、グラフィックカード上だけで コンウェイのライフゲームを実行するアイデアを説明しました 。このアイデアは、3つ以上の状態を有するオートマトンを含め、 どのような セルオートマトンにも当てはめることができます。今回の投稿では、二次元グリッドの 最短経路問題 をGPUだけで解決するのに、このアイデアを活用してみたいと思います。CPUによる従来の検索と比べても、その速さは遜色ありません。 JavaScript側の状態は基本的に以前と同様なので（2つのテクスチャと、それらを繋いでオートマトンを次のステップに進めるフラグメントシェーダ）、ここでは説明は割愛します。変更したのは次の2点、（オートマトンの全ての状態を表現する）セルの状態のエンコーディングと（新しいルールをプログラムする）フラグメントシェーダです。 オンラインデモ （ ソース ） デバッグや実験のために使ったセルオートマトンの純粋な

イントロダクション このチュートリアルでは、とあるデータサイエンティストの典型的な1日の過ごし方をご案内しましょう。まず地理空間のデータセットを入手し、不要なものを整理し、補強し、可視化します。使用するツールはPython、BeautifulSoup、pandasとNominatimライブラリ、そして地理情報システムの組織で広く使われているオープンソースの地図ソフトウェア、 QGIS です。 データセットになるのは、全米UFO情報センター（NUFORC）の このページ に掲載されているアメリカ全土のUFO目撃情報です。目標は、過去12カ月間に目撃されたUFOの地図を可視化することです。可視化によりデータセットをはっきりと示し、調査して、目撃されたとされるUFOの行動をよりよく理解することができます。可視化は地図作成プログラム内で行われます。QGISは地理空間データの手軽な試験的分析に特に向

def deploy(ip): copy('code/', ip + ':~/code', recursive=True) write_template('conf/config.py', ip + ':~/config.py') write_template('conf/crontab', ip + ':~/.crontab') write_template('conf/crontab', ip + ':/etc/apache2/httpd.conf') run_as_root('service cron restart') run_as_root('service apache restart') post('https://pingdom.com/api/2.0/checks', { 'name':ip, 'host':ip, 'type':'ping' }) タスクを実行するものと

最近のフロントエンド開発では、多くのフレームワークやライブラリが利用できます。ただし玉石混淆で、良い物もあれば悪いものもあります。そんなわけで多くの場合、私たちは特定のコンセプトやモジュールまたは構文に傾倒しがちです。でも、それが万能かと言うとそうでもありません。この投稿では、将来的なフレームワーク、つまりまだ存在していないフレームワークについて話をしていきたいと思っています。現状で利用可能なJavaScriptフレームワークの利点や欠点をまとめて、完璧なソリューションを思い描いてみましょう。 抽象化は危険 私たちはシンプルなツールが好きですよね。複雑さはある意味、命取りです。作業が難しくなり、一定時間内で多くのことを覚えなければならなくなる（急勾配の学習曲線が求められる）ようなことが多々あります。プログラマは仕組みを理解するまで気も休まらないのではないでしょうか。複雑なシステムで作業をす

JavaScriptのパフォーマンスに関する講演やブログ記事では、よく単相的コードの重要性が強調されています。しかしながら、モノモーフィズム（単相性）／ポリモーフィズム（多相性）とは何なのか、それがどうパフォーマンスに影響してくるのかということについては、あまり分かりやすく説明されていません。私自身の講演でも、＜＜ 1.良い型、2.悪い型 ＞＞的な二者択一のスタイルに要約してしまうことが少なくありません。パフォーマンスに関するアドバイスを求められることがありますが、そういう時に最もよくリクエストされるのは、 モノモーフィズムとは実際のところ何なのか 、ポリモーフィズムがなぜ生じ、それがなぜ悪いのか、ということを説明して欲しいというものです。 困ったことに、そもそも「ポリモーフィズム」という用語そのものが相当に多重定義されています。昔ながらのオブジェクト指向プログラミングにおいては、 ポリモ

はじめに 既にお気づきでしょうが、私たち2lemetryはAmazonの最新AWS製品であるLambdaに興奮を抑えきれません。LambdaがMQTTプロトコル（訳者注：pub/subモデルに基づく軽量なメッセージプロト […]はじめに 既にお気づきでしょうが、私たち2lemetryはAmazonの最新AWS製品であるLambdaに興奮を抑えきれません。LambdaがMQTTプロトコル（訳者注：pub/subモデルに基づく軽量なメッセージプロトコル）やThingFabric（訳者注：2lementry社のIoTプラットフォーム）と共にどのように稼働するかを我が社の数名のエンジニアが検証しました。私も、IoT（モノのインターネット）においてLambda内でニューラルネットワークがどのように機能するのかを確かめるため、実際に使用してちょっとした実験を行ってみることにしました。私たちのCEOであ

私の 前回の記事 では、 Heartbleed バグを早めに見つけられないことは、ある意味で改良とデプロイの失敗となると論じました。そうでなければ、これは静的解析にとって効果的なテクノロジーです。特に、商業的な静的解析ツールは故意に潜在バグを無視しますが、これは間違ったアラームが大量に報告されるのを避けるためです。つまり、健全性よりも完全性が好ましいということです。このようなツールを作る企業は、利益になるサービスを好況市場に提供することを狙いとしており、彼ら独自の調査では健全性は売れ行きに関して重要ではないということが示されています。その代わり、生き残るためには、本当に重要なバグを開発者が効率的に発見する手助けになるツールでなければいけません。全てのバグの検出は必要ないのです。リサーチャーの挑戦は、効率（それと、その他の望ましい基準）を維持しながら、健全性に背を向けてビジネス案を推進する方

この記事の目的はKen Perlinの改良パーリンノイズを分かりやすく分析し、お伝えすることです。記事内のコードはC#で書かれており、自由にご利用いただけます。最終形のみを見たい方は、こちらから最終的なソースをご確認ください。 パーリンノイズは手続き的なコンテンツ生成によく使われる、非常に強力なアルゴリズムです。ゲームや、映画などの視覚媒体に特に有用です。パーリンノイズの開発者であるKen Perlinは、この最初の実装でアカデミー賞を受賞しました。彼が2002年に発表した改良パーリンノイズについて、私はこの記事で掘り下げていきます。パーリンノイズは、ゲーム開発においては、波形の類や、起伏のある素材、テクスチャなどに有用です。例えば手続き型の地形（Minecraftのような地形はパーリンノイズで生成できます）、炎のエフェクト、水、雲などにも使えます。これらのエフェクトのほとんどが2次元、3

私は 以前の投稿 で、Angularなどのフレームワークがあまり好きではない旨を述べました。宣言的なHTMLのタグや属性、{{二重波括弧}}のプログラミングを開発するということには、 どうも抜け落ちている部分がある ようです。そして、どのフレームワークも独自のやり方で開発されているため、それを理解しサポートするためには、ツールのアップデートに多大な労力を 浪費する 注ぐ 必要があります。 さらに、そんな先入観を抜きにして考えてみても、Angularの今後に関して最近入ってきた情報は、私がますます頭を抱えてしまうような内容だったのです…… ツールに新たに追加される概念は、1つではなく3つ！ Angularをサポートするためにはツールのアップデートが必要ですが、今は下記を考慮していく必要があるようです。 Angular v1の構文 Angular v2の構文（従来と 大きく異なる ようです）