何年にも渡り、私は相応量の製品戦略、ロードマップ、プロジェクトガントチャートを作成しました。しかし、もうこれらの資料を作ることはありません。以下に説明する優れた代替策を見つけたからです。 まず、以前のやり方はこちらです。 注釈： 戦略 ロードマップ プロジェクトプラン 実行 アジャイル このプランニング方式だと膨大な仕事が必要です。株主全員の同意を得るだけでも大変だと言うのにROIはかなり低くなります。プランはあっという間に現実と一致しなくなり、期間が長いほど、乖離も大きくなります。私の作ったすてきなロードマップやプロジェクトガントチャートが公開する時点で既に古くなっていると気づいたのは、少し経ってからでした。このプランニングもウォーターフォールのひとつなので（有名な ウォーターフォール・モデル とは異なります）、即応性はほとんど期待できません。トップで変更があると、それが波及しボトムでの

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

1996年にcurlプロジェクトの先駆けとなるhttpgetを始めたとき、私は初めてURLパーサを書きました。当時はまだ、ユニバーサルアドレスは URL : Uniform Resource Locators と呼ばれていました。その仕様は1994年にIETFによって発行されたものでした。この”URL”という用語からインスピレーションを得てツールとプロジェクトに命名したのが curl でした。 URLという用語は後に事実上、 URI : Uniform Resource Identifiers (2005年発行)に変わりましたが、「オンラインでリソースを指定する文字列のための構文と、そのリソースを得るためのプロトコル」という、基本的な点は変わりませんでした。curlでは、この構文仕様RFC 3986の定義に従う”URL”を許容するとうたっていますが、それは厳密には正しくありません。その理由

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

先日、Facebookは 膨大なプルリクエスト をReactにマージして、既存のビルドシステムを Rollup ベースのシステムに移行しました。 その結果 、 何人もの人々 から「なぜwebpackではなくRollupを選んだのか」という質問が寄せられました。 これは、もっともな疑問でしょう。 webpack は、近年JavaScriptコミュニティで最も評価されているツールの1つです。毎月のダウンロード数は何百万件にもおよび、何万個ものウェブサイトやアプリケーションに使用されています。巨大なエコシステムがあり、コントリビュータも多くいます。さらにオープンソースプロジェクトとしては珍しく、 かなりの寄付金 が集まっています。 それに比べるとRollupは小規模です。しかしReact以外にも、Vue、Ember、Preact、D3、Three.js、Momentなど、数々の有名なライブラリに

私は時折、コーディングに対する考え方を変えさせられるような、従来と非常に異なるプログラミング言語に出会います。本記事では、その中でも特に気に入っている発見をいくつかご紹介したいと思います。 これは、先賢による「関数型プログラミングは世界を変える！」的な投稿ではありません。本記事で挙げるのは、もっと「知る人ぞ知る」的なリストです。多くの読者の方にとって、以下の言語やパラダイムは聞いたことのないものが大半だと思いますので、私が経験したように、これらの新しい概念を学ぶ楽しさを感じていただければ幸いです。 注：私は以下の言語の多くに関して最低限の経験しかありません。その発想に引き込まれたのであって、専門的知識は持ち合わせていないため、訂正すべき点や誤りがあればどうぞご指摘ください。また、本記事で取り上げていない新しいパラダイムや概念に出会った方は、ぜひお知らせください。 最新情報：本記事が r/p

多くのフロントエンド開発者が 一方向のアーキテクチャ を採用し始めている中で、Model-View-Controller（MVC）に未来はあるのでしょうか。 状況を把握するために、まずはフロントエンドのアーキテクチャの進化を振り返ってみたいと思います。 過去4年にわたり、私は多数のWebプロジェクトに取り組み、フロントエンドの構築、そしてフロントエンドとフレームワークの統合に多くの時間を費やしてきました。 2010年以前は、従来のウェブサイトにDOM操作を追加する場合は大抵JavaScript（ jQuery が書かれたプログラミング言語）が使用されていました。当時の開発者はアーキテクチャ自体についてはそれほど気に掛けていなかったと思います。コードベースを構造化する場合、 Revealing module pattern のようなものがあれば十分でした。 現在、多くの議論が交わされているフ

プロジェクトが発展する際は、単純に新しいコードが古いコードの上に追加されているのでしょうか。もしくは、時間をかけて徐々に古いコードが新しいコードに置き換えられているのでしょうか。これを解明するために、手ごわい GitPython プロジェクトの助けを借りて、Gitプロジェクトを分析する 簡単なプログラム を構築してみました。履歴を年ごとに振り返り、 git blame を実行してみようと思ったのです（この処理を多少でも速くすることは簡単ではないと分かりました。しかし、ファイルのキャッシングを便宜的に含ませることや、変更された点を履歴から見つけること、 git diff を使って変更したファイルを無効にすることなどの詳細を、いつかお伝えします）。 頭がさえている時に、 テセウスの船 をダサくもじって、 “テセウスのGit” と名付けました。私は父親になって、ひどいダジャレを作れるようになった

レガシーコードをうまく手なずけて、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。レガシーコードをうまく手なずけて 、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。 レガシーコードはリファクタリングで救出可能 耳寄りなお知らせがあります！ リスたちは毎年何千本もの木を植えてくれています 。まあ自分たちが隠したドングリのありかを忘れてしまった結果ですけどね。そしてもうひとつ。 あなたのプロジェクトも救出できる のです。 ボスから任されたプロジェクトが どんなに醜い泥まみれのレガシーコードだったとしても 、そこには 必ず 道があります。道は曲がりくねっていて、木陰にはモンスターが待ち構えていることでしょう。

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

小数のビット 情報理論の非直感的な点として、小数のビットがあるということが挙げられます。少しおかしな気もしますが、例えば0.5ビットの存在にどんな意味があるのでしょうか。 簡単な答えは次のとおりです。多くの場合、私たちが重視するのは特定のメッセージの長さではなくメッセージの平均的な長さです。送信メッセージの半分が1ビットで残りの半分が2ビットの場合、平均すると1.5ビットになります。こうして見ると、平均値が小数を含むのはおかしなことでも何でもありません。 しかし実際には、その答えは問題の核心を避けています。多くの場合、コードワードの最適な長さは小数ですが、それはどういうことなのでしょうか。 具体的に説明します。あるイベント \(a\) が71％の確率で発生し、 \(b\) が29％の確率で発生するような確率分布を考えてみてください。 \(a\) を表すのに最適なコードは0.5ビットで、 \

交差エントロピー オーストラリアへ引っ越す直前、Bobは、私が作ったもう1人の人物、Aliceと結婚しました。私も、私の頭の中の他のキャラクターたちも驚いたことに、Aliceは犬好きではありませんでした。彼女は猫好きだったのです。それにもかかわらず、2人は、それぞれ動物に夢中で、非常に語彙が限られているという共通点を見出したのでした。 注釈：犬好きが使う単語の頻度　猫好きが使う単語の頻度 2人は、同じ単語を使いますが、その頻度だけは異なります。Bobはいつも犬の話をしているし、Aliceは猫の話ばかりしています。 最初に、AliceがBobのコードを使ったメッセージを私に送ってきました。あいにく、そのメッセージは必要以上に長いものでした。Bobのコードは彼の確率分布に最適化されていました。Aliceは別の確率分布を持っており、Bobのコードを使うのは最適とは言えません。Bobが自身のコード

コードワードの範囲 コードの長さが1ビットなら使用できるコードは0と1の2つ、長さが2ビットなら00、01、10、11の計4つです。つまり1ビット増えるごとに、使用できるコードの数は2倍になります。 では、コードワードによって長さが異なる可変長コードの場合はどうなるでしょうか。3ビット長のコードワードが8つという単純なケースだけでなく、2ビット長のコードワードが2つと3ビット長のコードワードが4つなど、より複雑な組み合わせも考えられます。このような長さの異なるコードワードをいくつ使用できるかは、何を基に決まるのでしょうか。 前述のとおり、Bobは各単語をコードワードに置き換えて、それらを連結することで、メッセージをエンコードされた文字列に変換しています。 注釈： エンコードされた文字列 コードワード 元のシンボル 可変長コードを作成する際は、少々厄介な問題があるため注意が必要です。具体的に

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

マーケティングミックス は数ある有名なマーケティング理論の1つで、「4Pモデル」とも呼ばれています。この理論には、マーケティング計画の鍵となる、4つの主要素があります。 商品（ P roduct）実際に売られているもの 価格（ P rice）商品はいくらで売られているのか 宣伝（ P romotion） 顧客はどのようにして商品のことを知るのか 流通（ P lace）どこで商品が買えるのか 上の4要素の中でももっとも困難で高額、そして（例えば最大の堀のように）商品の最大の障壁だったのが、流通です。商品を顧客に見てもらうためには、流通に多額の投資が必要だったことは言うまでもありませんが、卸売業者や小売業者と関係を築く必要もありました。実際に流通管理ができている会社は大抵もうかっていました。 メディア業界で考えても、放送局は放送電波の権利を持ち、ケーブル局は通信キャリア（多額の利益を得ている民

本日、 gh-ost のオープンソース・リリースを発表します。GitHubの、トリガーレスなMySQL向けオンライン・スキーマ・マイグレーション・ツールです。 gh-ost は、MySQLテーブルの修正が必要な、進行中の継続的なプロダクション変更に伴って私たちが直面する問題に答えるために、ここ数ヶ月で開発されました。 gh-ost は、負担が小さく、制御しやすく、監査しやすく、操作が簡単なソリューションを提供することによって、現在のオンライン・テーブル・マイグレーションのパラダイムを様変わりさせます。 MySQLテーブルのマイグレーションは、よく知られた問題で、2009年からはオンライン・スキーマ変更ツールによって対処されてきました。ハイペースで成長するプロダクトに伴って、データベース構造の変更が必要になります。列やインデックスなどの追加・変更・削除は、デフォルトのMySQLの動作を妨げる

CSSプロパティの1つである display は、CSSレイアウトに用いるプロパティの中でも極めて重要なものです。よく使われているのは、 block や inline 、 none あたりでしょう。 table や inline-block も、今ではかなり一般的になってきたと言えます。一方、 flex は新たに登場したものです。きっとユーザに気に入られるでしょう。これはレイアウト用に特別に作られたdisplayプロパティです。さらには、この先、 grid がまもなく私たちの秘密兵器となるでしょう（現在、盛んに取り組まれています）。これもまた、レイアウトに特化したプロパティです。 本記事は、当初予定していたよりもずっと長くなりました。ご希望に応じて、自由にサブセクションに飛んでお読みいただければと思います。もし、お時間を割いて全体を読んでいただけるのでしたら、大変嬉しく思います???? 目

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

(2016/7/15、著者プロフィールを修正いたしました。) 仮に、高速道路の自動車をより速く走らせることがあなたの務めだとします。もしあなたが、ドライバー全員にただ「アクセルを思いきり踏むように」と言ったら、一体どうなるでしょうか？ 結果は明らかに、大惨事となるでしょう。それなのに、ソフトウェアの構築を速めようとする時に、多くの開発者がまさにそんな態度を取っているのです。その理由として持ち出されるのは、以下のようなことです。 「本当にアジャイルに進めたいので、デザインやドキュメントには時間をかけられない」 「これは本番環境にすぐ反映しなきゃいけないから、テストを書く時間はない」 「何もかも自動化する時間はなかったので、コードのデプロイは手作業でやる」 自動車が高速道路を高速で走るには、安全性が欠かせません。より速く走るためには、ブレーキやシートベルト、エアバッグといった、いざという時にド

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