(注：2017/04/20、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) 要約 HTTP/2 にはHTTP/1.xに比べて多数の改良点がありますが、 カオステスト を行ったところ、HTTP/2のパフォーマンスがHTTP/1より劣る状況があることが分かりました。 ネットワーク上にパケット損失がある場合、TCP層での輻輳制御によって、少数のTCPコネクションの中に多重化されているHTTP/2ストリームがスロットリングされます。さらに、TCPリトライのロジックにより、リトライが行われている間、1つのTCPコネクションに影響しているパケット損失が、いくつかのHTTP/2ストリームに同時に強い影響を与えます。言い換えれば、ヘッドオブラインブロッキングが事実上、ネットワーク階層の レイヤ7 から レイヤ4 へ移動したということです。 背景とサー

リモートワークのストレス ソフトウェアエンジニアリング業界では、リモートワークは大いに理にかなった働き方です。大抵はPCとインターネット接続さえあれば仕事ができるからです。よって、決まったオフィスに毎日通って働く理由は比較的少ないため、リモートワークはIT職の重要な要素になっています。最も先見的な求人市場とは決して言えないベルギーにおいてさえもです。とはいっても多くの場合、リモートワークが認められるのは週の一部のみ（おそらく週に1日か2日ぐらいが一般的）にすぎません。それにもかかわらず、リモートワークは大部分の企業で導入されるようになってきたのです。 リモートワークには多くの利点があると言われており、この働き方を過激なまでに擁護する声もよく耳にします。その多くには同意するものの、リモートワークを5年以上してきた経験から言えるのは、リモートワークにはストレスが付き物だということです。そう聞く

元記事の著者より：この記事は主に北米文化で私が見たことを反映しています。 誰かに職業をきかれたら、私は「フロントエンド開発者です」と答えます（答えは相手によって変わることもあります）。10年か20年前は、自分の仕事に必然的に伴うものが何なのかは、かなり明瞭でした。インタラクション用にHTMLやCSSを書き、JavaScriptも多少は書いていました。駆け出しの頃、PHPやMySQLの作業に職務の大半を費やしていたとはいえ、フロントエンド開発者として見られる方が好きです（これに関しては、後に詳しく説明します）。この状況は、2010年の初頭に変わり始めました。JavaScriptが、重要で、非常に大きな存在になってきたのです。昨年の初め頃から、たくさんのフロントエンド開発者に会うようになり、あることに気付きました。フロントエンド開発者は、もはや、私が以前から知っているフロントエンド開発者ではな

本記事はWebAssemblyに関するシリーズの第5回目で、今回のテーマはWebAssemblyが高速な理由です。前の記事をお読みでない方は、 初めから目を通される (訳注:原文リンク)ことをお勧めします。 前回の記事 (訳注:原文リンク)では、プログラミングに WebAssembly あるいはJavaScriptを使うかは二者択一の選択ではないことを説明しました。私たちは、WebAssemblyのみのコードベースを書く開発者が膨大な数になるとは思っていません。 ですので、アプリケーションにWebAssemblyとJavaScriptのどちらを使うか選ぶ必要はありません。しかし私たちとしては、開発者がJavaScriptコードの一部をWebAssemblyに置き換えることを期待しています。 例えば、Reactで開発しているチームは、リコンサイラコード（言い換えれば仮想DOM）をWebAss

Node8が出たのを知っていますか。より速くなりました、というか、そう言っています。 しかし数字で表されてはおらず、「より速い」と書かれているだけです。 幸い私には、Node6で実行している大きなReactのサイトと、2時間の空き時間がありました。 Node8へのアップデートはとても簡単でした。所要時間は10分ほどで、不完全なライブラリは1つもありませんでした。 このWebサイトから MacOSに pkg ファイルをインストールしたのですが、比較的順調でした。 しかし、 usr/local/lib/node_modules/ を 手動で削除 する必要がありました。 全てがうまくいきました。後ほどWindowsのパソコンにもインストールしてみますが、4日ほどかかるでしょう。 追記：驚きました。Windowsでは、まるで魔法のように働いたんです。手動で行うステップもなし、不完全なパッケージもな

RESTの規約。URLはリソースであり、CRUDはHTTP動詞にマップされる。 RESTの規約に1つ問題があるとすれば、規約が十分でないということでしょう。上記で”通常”、”多くの場合”、”時に”という表現を使ったのは、これらのやり方は仕様で推奨されているものの守られるとは限らないためです。実世界では、大抵のAPIはRESTishがせいぜいです。例えばStripeでは、リソース更新に PUT ではなく PATCH を使うべきですが、歴史的理由でそうはなっておらず、おそらく現時点では変更に値しないでしょう。いずれにしても開発者はドキュメントを読む必要があり、その時、 POST メソッドのユビキタスな使い方があることに気づくのです。 RESTには他の問題もあります。必要なものだけでなく全てが返ってくるため、リソースのペイロードが非常に大きくなることがあるのです。そして多くの場合、クライアントが

安全で堅牢なWebアプリケーションをクラウドで開発するのは 非常に困難 です。それを簡単だと思っているような人は、例えばとんでもない頭脳をお持ちというなら別ですが、遠からず痛い目を見ることになるでしょう。 もし MVP（Minimal Viable Product：必要最低限の機能を備えた製品） のコンセプトを鵜呑みにして、有益かつ安全な製品を1ヶ月で作成できると考えているようなら、プロトタイプを立ち上げる前に一度考え直した方がいいと思います。以下に挙げたチェックリストをご覧いただければ、セキュリティに関するクリティカルな問題の多くをスキップしていることが分かるはずです。あるいは少なくとも、潜在的なユーザに対しては 誠実 であるように心がけ、製品が完全ではないこと、そしてセキュリティが不十分な製品を提供していることを伝えるようにしてください。 このチェックリストはシンプルなもので、決して完

ボタンはごく普通の、インタラクションデザインの日常的な要素です。ボタンはとてもシンプルなUI要素に見えますが、過去数十年間でそのデザインはかなり変わってきました。しかし今でもボタンのUXデザインは認識しやすさと明確さについて言及されています。 この記事ではボタンデザインの発展を辿りながら、有効なボタンを作るために何が最も重要で最適なのかを見つけて行きたいと思います。 スタイルの発展 3Dボタン 初期からオペレーティング用のボタンは、周りのコンテキストと区別するために、浮き彫りと影に依存していました。この設計の解決策は枠、グラデーション、ドロップシャドウを使用して、要素を背景やコンテンツから目立たせ、クリック可能な要素だと簡単に認識できるようにするといった単純な原則に基づいていました。 ボタンが浮かび上がっているように見えます。 このWindows95のダイアログボックスは、濃い影とハイライ

ソーシャルメディアのAPIとそのレート制限は、あまり気分のよいものではありません。特にInstagram。あんな制限つきAPIを欲しがる人がいったいどこにいるんでしょうね？ 最近のサイトは、スクレイピングやデータマイニングの試みを阻止するのがうまくなってきました。AngelListはPhantomJSすら検出してしまいます（今のところ、他のサイトでそこまでの例は見ていません）。でも、ブラウザ経由での正確なアクションを自動化できたとしたら、サイト側はそれをブロックできるでしょうか？ 並行性を考えたり、さんざん苦労して用意した結果として得られるものを考えたりすると、Seleniumなんて最悪です。あれは、私たちが「スクレイピング」と聞いて思い浮かべるようなことをするためには作られていません。しかし、賢く作り込まれた今どきのサイトを相手にして、インターネットからデータを掘り当てるための信頼できる

世界を考察する新しい方法を手に入れたときの感覚が大好きです。特に好きなのは、いずれ具体的なコンセプトに形を変えるボンヤリとした考えがあるときです。情報理論は、その最たる例です。 情報理論は、多くの物事を説明するための正確な言葉を与えてくれます。自分はどのくらい理解できていないのか？質問Aの答えを知ることが、質問Bを答えるのにどのくらい役立つのか？ある種の信念が他の信念とどの程度似ているのか？こういうことに対し、若くて未熟なころから自分なりの考えがありましたが、情報理論に出会って正確で強固な考えとしてはっきりと固まりました。その考えは、桁外れの、例えばデータの圧縮から量子物理学や機械学習、さらにはその間に広がる数多くの分野に応用が利くものです。 残念なことに、情報理論は少々威嚇的に見えてしまうのですが、そう断定すべき根拠は全くないと思います。実際、情報理論の多くの重要な概念は完全に視覚的に説

ここで論じているのは、オーディオアプリの開発者が陥りがちな 4つの間違い 、 より良く開発する方法 、 問題個所の発見方法 です。主に開発者向けの内容ですが、開発者以外の方にも知っておいてもらいたいと思います。ここでは、開発者向けの診断ツールである Realtime Watchdog を紹介し、 人気のあるオーディオライブラリの調査結果 を提示します。 オーディオアプリの開発はとてつもなく楽しいです。やりがいを感じるし、創造力を発揮できる範囲が大きく広がり、ひとたび開発が終われば、 誰かがクリエイティブなツールとして使ってくれるのです！ こんな分野は多くないし、この領域で働けるなんて非常に幸運だと自分でも思っています。 しかし、仕事でオーディオアプリを扱う時には深く考えなければならない部分もあります。オーディオアプリの開発者としてユーザに対する責任があるのです。大前提として、ユーザを公共の

最近、「モーションデザイン」という言葉がデザイン業界で急に出てきていることに気づいていますか？大小様々な企業が、これに特化した肩書きを持つデザイナーたちを雇いはじめています。最近ではGoogleが I/Oカンファレンス で、Googleの製品で統一化されているモーションランゲージの概要について話していました。 この騒ぎは何でしょうか？そして何の意味があるのでしょうか？ モーションはストーリーを語ります。 アプリにおける全ての物事は連鎖になっていて、モーションはあなたのガイドになります。ボタンをクリックして、画面が変わる度に、そこにはストーリーがついてきます。例えば、アイテムを作ったり削除する時、アニメーションがどのように役に立つかを見ていきましょう。 アイテムを消すことは劇的で破壊的な作業ですので、適切に反応するようにしましょう。アイテムをただ画面から消すだけということはしないようにしまし

数週間ほど前にオランダのウィンデスハイム実務専門大学校で客員の講師として講義を行いました。私自身、同学校の卒業生で、恩師たちと連絡を取り続けています。最近、恩師の1人から、多くの学生がITのセキュリティとハッキングについて深く学びたがっているという話があり、客員として講義しないかと招待がありました。喜んで！　講義を面白くするためにハッキングのデモも行うことにしました。 ハッキングのデモを始めたときに、学生に企業の名前を聞き、続いて私がその企業のセキュリティを検査したら面白そうだと考えました。次の段階で全く驚きの発見をしてしまい、その企業のセキュリティを保護するため、デモの方向性を変えざるを得ませんでした。 ユニリーバをハッキング？ ある学生がオランダでも有名な企業であるユニリーバの名を挙げ、私はこの企業を調べるのが良さそうだと思いました。もちろん法律の範囲内で、です。ユニリーバのサイトのH

開発者と仕事をしていると、スケッチ、ワイヤーフレーム、モックアップ、プロトタイプといった用語をよく聞くかと思います。しかし、あなたはこうした用語の意味を本当に理解しているでしょうか？　ワイヤーフレームやプロトタイプは、それぞれどんなときに利用するのか、知っていますか？ まず、アプリの構築を始める前に、スケッチ、ワイヤーフレーム、モックアップあるいはプロトタイプからスタートするべきだという理由を見てみましょう。 構築したいものがどんなものか、ブレインストーミングをしたり考え出したりするため。こうした作業により、あなたの期待するものが明確になる。 開発者にかかる費用を節約し、構築に必要なものを明らかにすることができる。 こうした作業の結果は投資家や最初の顧客、共同設立者に提示する目的で使える。 顔を突き合わせることのない開発チーム とコミュニケーションを取るためには、これらの用語を正しく区別し

以下に紹介するのは、 Docker を使って node.js 用のWebアプリケーションを開発、およびデプロイする際に、私が四苦八苦しながら学んだ秘訣やコツです。 このチュートリアル記事では、Dockerで socket.ioのチャットサンプル を白紙の状態から本番状態へとセットアップしていきます。このプロセスを通じて、そうした秘訣などを簡単に習得していただければ幸いです。特に、以下のような内容について見ていきます。 実際にDockerでNodeアプリケーションを起動する。 すべてをrootとして実行させない（悪いやり方です）。 開発時のテスト-編集-リロードサイクルを短くするため、バインドを使用する。 再構築を高速にするため、 node_modules をコンテナで管理する（これには秘訣があります）。 npm shrinkwrap で、ビルドを反復可能にする。 開発環境と本番環境で Do

次のステップ 統計学とエンジニアリングを統合する方法はたくさんあるので、うまく始められるように幾つかご紹介しましょう。 計測ツール 統計学の基本に焦点を当ててきましたが、そもそも、どうやって関連するデータセットを生成すればいいのでしょうか？　私たちの答えは、コンポーネントの計測ツールを構造化することです。しかるべき所に正しいフックを使用すれば、私たちが問題をデバッグするために残業しても、パフォーマンスを向上させるために予備のサイクルがある時でも、データは必要な時に得られます。 PayPalのPythonサービスの堅牢性の多くは、信頼性の高いリモートロギング基盤によるものです。そしてこれは rsyslog と似ていますが、より強力なものです。それでも、データを上流に送信する前に、このプロセスは内部の指標を収集する必要があります。メジャーリリースがもう間近なので、2つのオープンソースプロジェク

ソフトウェア開発の原点は可能性の追求であり、不可能を可能にすることです。ひとたび ソフトウェア が開発されると、エンジニアは次に 程度 という課題に向き合うことになります。企業向けのソフトウェアであれば、「速度はどれくらいか」と頻繁に問われ、「信頼性はどの程度か」という点が重視されます。 ソフトウェアのパフォーマンスに関する質問に答え、さらには正しい内容を語る上で欠かせないのが統計学です。 とはいえ、統計学について多くを語れる開発者はそうはいません。まさに数学と同じで、一般的なプロジェクトで統計学が話題に上ることなどないのです。では、新規にコーディングをしたり、古いコードのメンテナンスをしたりする合間に、手が空くのは誰でしょうか？ エンジニアの方は、ぜひ時間を作ってください。近頃は、15分でも貴重な時間と言えるでしょうから、 こちらの記事をブックマークに追加 しておいてもいいでしょう。とに

2004年に Gregor Hohphe が「 スターバックスでは2相コミットを使わない（Starbucks Does Not Use Two-Phase Commit） 」という優れた投稿を発表しました。それを読んでいたら、学生時代にスターバックスでアルバイトをした頃がいきなり関わってきました。何年もの間に次第に分かってきたのは、プログラマでさえ有名なコーヒーショップのチェーンから学べることが思った以上にあるということです。 多くの人はスケーラビリティのあるソフトウェアを作ろうしますが、最初に考えていたよりも非常に難しいことがあります。個々のタスクをこなしているうちに「あらゆるものの重要性は等しく、同じリソースを必要とし、決まった順序で同期的に進行する」と考えてしまう罠に陥ってしまうのです。 実際には、少なくともスケーラビリティのあるシステムでは、当てはまりません。もちろんスターバックス