2005年に発表された論文で、これまでのようにDBMSを様々なデータ中心のアプリケーションに利用することがデータベース市場で受け入れられなくなったと主張する。 データウェアハウスとストリーミング処理を例にとり、これらに特化したデータベースをDBMSで代用することの限界が説明されている。 表題の"One Size Fits All"はフリーサイズ、転じて、万能、汎用的を意味する。
Amazonで社内運用されている高可用性のKVS, Dynamoのアーキテクチャを解説している。 まぎらわしいが、Dynamoは、AWSサービスのDynamo DBとは違う*。 Dynamoは、リーダーレスレプリケーションモデルで、Dynamo DBはシングルリーダレプリケーションモデルを採用している。 Dynamoは、高信頼性が必要なシステムの状態管理に使用される。 その用途から、トランザクション分離レベルのサポートは不要で、可用性を優先するために結果整合性を許容する。
語義曖昧性解消のためのアーキテクチャ, Extended WSD Incorporating Sense Embeddings(EWISE)を発表した。 EWISEは単語の意味をアノテーションしあテキストと辞書を教師データにもちいる。 実験では、辞書にWordNetをつかい、概念同士の上下関係や関係を示す分散表現を獲得する。 学習であたえられていない意味を推定するために、離散値ではなく分散表現でラベルの意味を表現する。
5つの分散システムのバグのうち198件を無作為に抽出、調査したところ、エラーハンドリングに対する単純なテストが有効であることが分かった。
198件のうちの48件は、論文でcatastrophic failuresと形容された、多くのユーザに影響を与える障害が占めた。
調査対象は、Cassandra, HBase, HDFS, Hadoop MapReduce, Redisの5つである。
catastrophic failuresの35%の原因は、エラーハンドラがログの出力だけしかしていない、過剰に上位の例外クラスが宣言されたcatch構文で例外を処理していること、例外にFIXME, TODOコメントがある、の3パターンに分類された。
Javaのバイトコードから以上の3パターンを検出するツールを実装し、9種類の分散システムに適用したことで、121件の未知のバグを特定することができた。
開発におけるブレーンストーミングが、マイノリティに属する開発者の満足度の向上に貢献することを実験的に示した。 ここでの開発は、ハッカソンのような短時間かつ集中が求められるものが想定されている。 満足度は、開発プロセスと成果物に対するもので分けて扱われ、どちらの観点でもブレーンストーミングは満足度に対してよい効果をもたらした。
タスク固有の特徴を使わないEnd to Endの系列ラベリングのためのネットワークアーキテクチャを発表した。 実験では、Penn Treebank WSJの品詞タグ付けで97.55%のaccuracy, CoNLL 2003の固有表現抽出で91.21%のF1値を発揮し、発表当時の先行研究を上まわる性能を示した。
アジャイル開発に熟練する過程でチームに生じる変化をグラウンデッドセオリーで調査した。 調査のために、ニュージーランド、オーストラリア、アメリカ、インド、ポルトガルの5カ国から18のチームを選び、その中の31名に半構造化された約1時間の面接を実施した。 面接では、職歴、自己組織化の実践、仕事のわりあて方の3つを話してもらった。
Pivotal Labs(Pivoital社の一部門、PivotalはSpring Frameworkを開発している会社。昨年VM Wareに買収された？)における8プロジェクトを、グラウンデットセオリーにしたがって参与観察し、ソフトウェア開発においる無駄を特定し、無駄を9つの区分に分類した。 論文では、無駄は「リソースを使っのに顧客にとっての価値を生みださなかった活動」と定義されている。 調査期間は2年5ヶ月で、調査結果は、ソフトウェア開発者、インタラクションデザイナ、プロダクトマネジャーからなる33名のステークホルダに面接した結果もふまえてある。 分類のほかに、無駄を生みだす二項対立や原因にも言及されている。
ニューラルネットワークによる共参照解析の手法で、End-to-Endとあるように、構文解析やルールベースの参照表現に頼らず、先行研究を上回る性能を発揮した。 文書中の全ての単語系列を参照表現の候補とみなし、ある単語系列の組が照応関係にある確率の分布を学習する。
マイクロソフトにおいて、誰が(RQ1)、どんな(RQ2)自作ツールを、どのような動機(RQ3)で、いつ(RQ3)開発し、どのように普及するのか(RQ4)を調査した。 調査結果では、大多数の開発者はツールを自作し、そのほとんどは所属するチームの外までは普及せす、ツールの使用者と共同開発者は一人以上いることが多かった。 受容的な組織文化はツールの自作を促進し、また、自作ツールは組織に大きな影響をあたえる可能性があることを示唆している。