本記事はRubyについて書かれたものではありますが、Python、JavaScript、Javaなど、全ての言語コミュニティに当てはまる事実を述べたものです。依存関係が引き起こす負の連鎖は誰のためにもなりません。 上の図は、私がこれまでに使用した全てのRailsアプリの依存関係を可視化したものです。以下の例はいずれも、どこかで聞いたことのあるものではないでしょうか。 何百ものエントリを含むGemfile 本番環境で読み込まれるテスト用Gem 数百メガバイトもRAMを食うRailsのプロセス Rubygemsシステムは、それを再利用する誰もが容易にRubyのパッケージを作ることができるという点で、賞賛に値するものです。しかし、その便利さが意味するところは、そうしたGemと他のGemを非常に安易に結び付け、さらにそれが、「インターネットでダウンロード」され、数百もの依存関係を持つRailsアプ

Goというプログラミング言語の強みの１つは、 Tony Hoare考案のCSP に基づくビルトインの並行性(Concurrency)です。Goは並行性を念頭にデザインされているため、複雑に並行したパイプラインの構築を可能にしています。でも、それぞれの並行性パターンがどのように見えるものなのか気になったことはありませんか。 もちろん、気になったことはあると思います。恐らくそれぞれ形は違っても、誰もが頭に描いているのではないでしょうか。もし、「1から100までの数字」について聞かれたら、無意識に頭の中で数字のイメージを思い浮かべると思います。例えば、私の場合、自分の前から1から20までがまっすぐに並び、21以降は90度右に曲がり1000以降まで続くイメージが浮かびます。これは多分私が幼稚園の時に教室の壁に沿って数字が貼られていて、ちょうど角に数字の20があったからなのだと思います。別の例えをす

Node.jsが多数のイベントの非同期な処理に長けていることはよく知られていますが、それが単一のスレッドで行われていることを多くの人は知りません。Node.jsは実際にはマルチスレッドではないので、リクエストは全て単一スレッドのイベントループで処理されているだけなのです。 そこで、Node.jsクラスタを使って、クワッドコアプロセッサの能力を最大限に引き出しましょう。コードの複数のインスタンスで起動し、さらに多くのリクエストを処理します。少し難しく思えるかも知れませんが、Node.js v0.8で導入された cluster モジュールを使えば、実はとても簡単です。 もちろん、これは、作業を別々のプロセスに分割することのできるアプリならどんなアプリにでも役立ちますが、webサイトのような多くのIOリクエストを処理するアプリには特に重要です。 残念ながら、並行処理は複雑なので、サーバ上でのアプ

(訳注：2016/3/2、頂いたフィードバックをもとに記事を修正いたしました。) 注 このブログ投稿は不満をぶちまけています。かなりのものです。自説は曲げません。長いです。そして、頭に血が上っています。かなり暴言です。 目次 アプリケーションの中身は？ アプリケーションについての考え方が間違っている アプリケーションは 体験 のようなもの この問題の解決策 1. 設定より規約 2. アプリケーションを使いながらユーザを丁寧に導く 3. 失敗は起こる。その直し方を知りたい 4. ドキュメンテーションについて考えるのは、やめよう まとめ 参考文献 最近、ソフトウェア開発において復活しつつあるとても 興味深い 傾向があるようです。おそらくNode.jsの哲学に影響を受けているのでしょう。何かを使うためには、まず大量の「依存パッケージ」をインストールする必要があり、さらにそのコンフィギュレーション

ここ数年、私はWeb開発と機械学習の自習に多くの時間を割いてきました。 学習のテーマは、Javascript、Node、ReactからPython、scikit-learn、ニューラルネットワークに至るまで多岐にわたりましたが、全てに対して私は一貫したアプローチで取り組みました。 そのアプローチとは、単純な（陳腐と言ってもいい）3ステップで進める、という手法です。しかし、 Web開発のシロウトだった私が5カ月で、プロだと自覚できるほどになった のはひとえに、このアプローチで臨んだ自習の成果だと思っています。 そこで私は、この自習法がほかの誰かのお役に立てるかもしれないと思い、少し記事を書いてみることにしました。 この記事は、何も分からないままやみくもに挑戦を始めた、2012年当時の自分自身に教えるつもりで書いています。 ステップ1：習うより慣れろ 新しいテクノロジを学ぶためにまず実行する最

どうすればPythonをJuliaと同じくらい速く動かせるのか？ : 様々なやり方で計算の高速化を図る Julia対Python 科学技術計算には、Pythonなどの言語よりもJuliaを使った方がいいのでしょうか？ http://julialang.org/ に載っているベンチマークを見ると、どうしてもそんな風に思ってしまいます。というのも、Pythonなどの高水準言語は、スピード面で大幅に劣っているのです。けれども、これは私が最初に感じた疑問ではありません。私が気になったのは、「Juliaのチームが書いたPythonのベンチマークは、Pythonに最適なものだったのか？」ということです。 こういった多言語の比較について、私の考えを述べましょう。まずベンチマークというのは、実行するタスクによって定義されるものです。よって、そのタスクを実行するための最適なコードを、各言語に精通した人々が最

(訳注:2016/3/3、頂いたフィードバックをもとに記事を修正いたしました。) オープンソースプロジェクトでバグを見つけたとします。まずは、慌てずに落ち着きましょう。これは実によくあることです。ソフトウェアは人間の手で書かれるし、人間はミスを犯すものです。 または、こんなふうに考えるかもしれません。「やったね、バグの修正は大好きだ」。さっと現れて、何百万人とまではいかなくても、何千人もが使っているプロジェクトのバグを修正してしまうようなヒーローになりたくない人なんていますか？　オープンソースコミュニティに恩返しできたという温かな喜びを感じられる上に、一連の Github 履歴 ^(1) に追加得点を上げられるわけです。 *訳： 人気のあるプロジェクト 典型的なバグ * しかしコーディングの初心者にとっては、オープンソースプロジェクトにコントリビュートするなんて恐れ多いことに思えます。私の

オープンソースソフトウェアを開発する日々をハッピーに ― あるいは、OSSコントリビュータに感謝を伝えるためにできること この数か月、複数の人たちがオープンソースから手を引いたり、オープンソースで燃え尽きないよう苦慮したりするのを見てきました（ 1 、 2 、 3 、 4 ）。matplotlibプロジェクトを率いる1人であるThomas Caswellに、私がどのようにオープンソースへの貢献にうまく取り組んでいるかを話したところ、 彼はその話を気に入った と言いました。そこで、私が前向きな気持ちをキープし、オープンソースに貢献し続けるためにどのようにしているか、また、他の人の仕事に感謝の気持ちを表すために何ができるかを共有することにしました。 燃え尽きる理由 しかし、まず初めに、なぜ人はオープンソースで燃え尽きるのかを説明したいと思います。コントリビュータ自身以上にユーザを抱えるプロジェ

このブログ記事では、私たちの製品の使用運転を基に、Amazon Redshiftを使った顧客分析の構築方法を説明していきます。この記事で扱う内容は以下の通りです。 なぜ顧客分析に移行しつつあるのか？ あなた は、顧客分析を構築すべきか？ Amazon Redshiftが普及してきている理由 データを可視化するBIツールの選択 Amazon Redshiftクラスタの設定 Alooma でデータパイプラインを構築 エンゲージメント、リテンション、ファネル、パフォーマンスダッシュボードを作成するための一般的なSQLクエリ 顧客分析の台頭 今日では、何かしらの分析ツールが実装されていないWebサイトやアプリケーションを探すことは難しいと言っていいでしょう。製品を作ったり、戦略的な意思決定をしたりする上でデータを活用することは常識ですし、消費者市場ではことさら必要不可欠なことです。製品の変更に対し

uxdesign.ccのチームは2015年、様々なことを目にしてきました。そして、48回のニュースレターを発行し、384件のリンクを紹介し、世界中のデザイナー6万1,295人に毎週 メール で配信しました。ユーザエクスペリエンスデザインの驚くべき世界でどのようなことが書かれ発表されているか、そのパターンや傾向をチームが把握するには十分なコンテンツでした。 この記事では私たちの視点から、これまでの状況を振り返り、現状を理解し、そして2016年のUXで何が起きるかを展望してみたいと思います。 1. ピクセルに熱中するのはもう終わり 2015年、ついに「UX」というバズワードをLinkedinプロフィールに追加した人もいるかもしれません。しかし作業時間の多くは、いまだ画面上のピクセル操作に費やされていたのではないでしょうか。でも、そんなPhotoshop漬けの日々はもうすぐ終わるかもしれません。

100Mにスケーリング：Key-ValueストアとしてMySQLを使い、NoSQL以上のパフォーマンスを出す MySQLはNoSQLよりも優れています。Key-ValueストアといったNoSQLのユースケースを考えてみると、パフォーマンスや使いやすさ、安定性の点でMySQLの方が合理的です。MySQLには、オペレーションや障害に関することからレプリケーションや異なる使用パターンまでと、多くのオンラインマテリアルが用意されおり、堅実なエンジンです。こういった理由から、比較するまでもなく、MySQLは最近のNoSQLエンジンよりも優れていると言えます。 ここ最近では、NoSQLエンジンが主流になってきています。多くの開発者が、MongoDBやCassandra、Redis、HadoopといったNoSQLエンジンをアプリケーション構築の第一候補としており、それらが全て昔からのSQLエンジンを上回

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

このブログは、 FastMail 2015年アドベントカレンダー に掲載している8つ目の記事です。リンクをクリックすると全ての記事がご覧いただけます。 先月、 私たちはDDoS攻撃を受けました 。その週、私たちはこの手の攻撃スタイル、そしてその防御法に関して多くを学びました。この記事では、私たちが学んだことや、あなたのサービスがDDoSの攻撃にあった時に何ができるかを説明したいと思います。私たちはどうしても皆さんにこのことを伝えたいのです。急いでいる時にこのような情報をまとめて探しだすのは簡単ではありません。あなたが既に攻撃にあっている場合は特に難しくなります。ここに掲載されていることが少しでも皆さんのお役に立てるようであれば、うれしい限りです。 DDoSとは？ “DDoS”とは”Distributed Denial-of-Service（分散型サービス妨害）”の略なのですが、これを理解す

私は、多数の大容量のデータをあちこちに移動させなければならない(クライアント端末をHTTP APIに接続してデータを取得します)ような特殊な使用事例を扱っています。なぜだか ^(1) 、転送形式にはJSONが使われていました。ある時、その大容量のデータが、さらに巨大になったのです。数百メガバイトどころではありません。JSONのデコード処理を実行すると大量のRAMが使用されることが分かりました。たった240MBのJSONペイロードで4.4GBですよ。信じられません。 ^(2) 組み込みのJSONライブラリを使っていて、まず「もっと性能の良いJSONパーサがあるはずだ」と思いました。そんなわけで、計測を始めたのです。 さて、メモリ使用量の計測はやっかいです。 ps コマンドを使ったり、 /proc/<pid> を見たりすることはできますが、断片的なスナップショットが得られるだけで、実際の最大使

分散システムについては、もう随分と前から学びたいと思っていました。ただ、それは一度首を突っ込んだら最後、ゴールのない迷路に迷い込むようなものなのです。どこまでも続いているウサギの穴のようなものです。分散システムに関する文献は星の数ほど存在します。様々な大学からたくさんの論文が発表されているばかりでなく、膨大な数の書籍もあるのです。私のような全くの初心者には、どの論文を読んだらいいのか、どの書籍を買ったらいいのか、見当もつきません。 そんなとき、一部のブロガーが、 分散システムエンジニア （それがどういう意味であれ）になるなら知っておくべき論文というものを推奨しているのを見つけました。その一部を紹介しましょう。 FLP , Zab , Time, Clocks and the Ordering of Events in a Distributed Systems , Viewstamped

はじめに バックプロパゲーションとは、ディープモデルの学習を計算可能にしてくれる重要なアルゴリズムです。最近のニューラルネットワークではバックプロパゲーション (誤差逆伝播法) を使うことで、最急降下法による学習が愚直な実装と比べて1000万倍速くなります。 例えば，バックプロパゲーションでの学習に1週間しかかからないのに対して、愚直な実装では20万年かかる計算になります。 ディープラーニングでの使用以外にも、バックプロパゲーションはさまざまな分野で使えるとても便利な計算ツールです。それぞれで呼ばれる名称は違うのですが、天気予報から、数値的安定性を分析する時にまで多岐にわたり使用できます。実際に、このアルゴリズムは、いろいろな分野で少なくとも20回は再開発されています（参照： Griewank（2010） ）。一般的な用途自体の名前は”リバースモード微分”といいます。 基本的に、この技術は

近い将来WebSocketがRailsで使用できるようになると聞くと、デベロッパはみんな舞い上がって興奮します。 しかし、 あなたのユーザは、あなたがWebSocketを使用しているかどうかなんて気にしません 。 ユーザは、”快適なリアルタイムWebアプリ”を求めている。 デベロッパは、”快適でビルドが簡単なリアルタイムWebアプリ”を求めている。 オペレーションは、”デプロイ、スケール、管理が簡単なリアルタイムWebアプリ”を求めている。 上記全ての要望をWebSocketがかなえてくれるのなら素晴らしいことですが、この実装の詳細は高いコストがかかります。 超高性能で全二重なクライアントとサーバ間の通信は、本当に私たちに必要なのか？ WebSocketは、クライアントに情報を配信するための簡単なAPIと、クライアントからWebサーバへ情報を送信するための簡単なAPIを提供します。 サーバ

今年からAWS（Amazon Web Services）クラウドコンサルタントとして、中小規模のAWSデプロイの相談を受けています。その多くは典型的なWebアプリケーションです。ここで、ぜひ避けたい5つのよくある間違いを紹介します。 インフラストラクチャを手動で管理する。 Auto Scaling グループを使わない。 CloudWatchのメトリクスを分析しない。 Trusted Advisorを無視する。 仮想マシンを活用しない。 典型的なWebアプリケーションにおける間違いを防ぎたい人は、次に進んでください。 典型的なWebアプリケーション 典型的なWebアプリケーションは最低限次の要素で構成されているものを指します。 ロードバランサ スケーラブルなWebバックエンド データベース そしてこのアプリケーションは、次の図のような仕組みを持っています。 注釈：（左から）DNS、CDN、静