Design Tradeoffs for SSD Performance
HDDの処理性能を測定するシミュレーションソフトDiskSimをSSD向けに改造し、SSDの設計における選択肢の分類と選択にともなうトレードオフを報告した。 主要な選択肢は、論理アドレスと物理アドレスのマッピング、ページサイズ、オーバープロビジョニング、複数のpackageでcontrollerに接続するピンを共有するgangingがある。
Posts
Program Comprehension and Code Complexity Metrics: An fMRI Study
コードの複雑さのメトリクスがコードを理解する難しさの指標になるかは疑問視されてきた。 19人の被験者に16個のソースコードを読ませ、関数の返り値を回答してもらい、作業中の脳の状態をfMRIで観察することで、メトリクスと回答時間、正答率、脳の活性状態の相関関係を調べた。 メトリクスと主観的な評価を比較するために、回答後に被験者にコードの複雑さを評価してもらった。 調べたメトリクスは、41種類あり、コードの行数(LOC), 語彙の多さ(Halstead), とりえる実行パスの数(McCabe), 依存するデータの数(DepDegree)の4種類に大別できる。 相関関係をケンドールの順位相関係数\(\tau\)で評価し、相関なし(\(\tau <0.1\)), 弱い(\(0.1 < \tau < 0.3\)), 中(\(0.3 < \tau <0.5\)), 強い(\(0.5<\tau\))とみなす。
回答と脳の活性状態と相関関係にあったメトリクスはDepDegreeだったが、被験者の主観的な評価のほうが強い相関がみられた。 LOC, Halstead, DepDeegreeは回答時間や正答率と弱い〜中程度の相関があった。 この3つのメトリクスは脳の活性度合いと弱から中の相関があり、活性度合いと正答率には強い相関、回答時間には弱から中の相関があった。 一方、主観的な評価は、メトリクスと弱い相関があり、問題の正答率や脳の活性状態と強い相関関係があった。
The UNIX Time-Sharing System
デニス・リッチーとケン・トンプソンによるPDP-11/40, /45, /70で採用されたUnixのファイルシステムとコマンドラインインターフェースの解説である。 PDP-11は1971年2月から運用がはじまり、当初はアセンブリ言語で実装されていたが、1973年の夏にCで再実装された。 ファイルシステムは、UNIXの最も重要な役割に位置づけられ、特殊ファイルによるI/Oデバイスの抽象化、外部ディスクのマウント、ファイルの権限、i-nodeをふくむ多くの特徴が今日まで引き継がれている。 2人は、UNIXの設計に影響したものとして、プログラマとして対話的なインターフェースを望んでいたこと、ハードウェアの低い性能ゆえにソフトウェアの設計を洗練させる必要があったこと、ソースコードをUNIX上で編集し簡単にプログラムを変更できたことをあげている。
What helped, and what did not? An Evaluation of the Strategies to Improve Continuous Integration
TravisTorrentにある100件のプロジェクトで10種類のCIのテクニックを定量評価した。 テクニックは、不要なビルドやテストをスキップするか、実行順序を優先づけるものかに分かれる。 前者は計算資源の消費を減らすこと、後者は失敗するケースを早めに実行することを目的にする。 もっとも成功するテストやビルドをスキップできたテクニックは、コードに変更のないケースをスキップするものだったが、同時に失敗するテストを多く見落とした。 実行順序を優先付ける手法で最も性能のよかったテクニックは、Thomasらのもので、シグネチャやコメントで学習したトピックモデルを使い直前に実行したテストと違うトピックのテストを実行する。
Don't Do That! Hunting Down Visual Design Smells in Complex UIs against Design Guidelines
2020年5月時点のマテリアルデザインの公式ドキュメントから93種類の不吉な匂いを洗い出し、71種類の匂いを検出するツールUIS-Hunterを開発した。 文中に"don’t"や"caution"があることとUIの画像があることを条件に不吉な匂いを選び、9,286個のアンドロイドアプリにある7,497のUIを調べたところ、2,587個のアプリから1つ以上の不吉な匂いのあるUIが見つかった。 UIS-Hunterは、FigmaやAndroid Studio Layout EditorなどのモックアップやAndroid UI AutomatorやSeleniumのスクリーンショットから不吉な匂いを解析し、UIのソースコードを必要としない。 9,286個のアプリの60,756のUIで検出性能を評価したところ、precisionが0.81, recallが0.90だった。
An Empirical Analysis of UI-based Flaky Tests
GitHub上の5つのWebアプリケーションと37のAndroidアプリケーションから集めた235件のUIのflaky tests（何度か実行すると成功する不安定なテスト）を調査し、原因と修正を分類した。
大きく原因を、非同期処理の待機、環境依存の動作、DOMのセレクタやテストライブラリの誤用、テスト対象の事前条件を満たしていないテストスクリプトの4つに大別した。 具体例をあげると、環境依存の動作には、IE固有のバグや予期していないレイアウトで画面が表示される場合、テストの事前条件については、テストの実行順序次第で誤ったテストデータが作られる場合がある。 最も多くのテストが分類され、全体の45%を占めたのは、非同期処理の不適切な待機方法だった。
修正のパターンには、待機時間の追加、テスト用APIの誤用の修正やAPIのアップグレード、テストスクリプトのリファクタリング、アニメーションの削除、不要なテストの削除がある。
論文をこちらからダウンロードできます。
A Case Study of Onboarding in Software Teams: Tasks and Strategies
オンボーディングのためのタスクの選び方とタスクの効果を調査するために、マイクロソフトのエンジニアとマネージャーにインタビューした。 まず、新しいチームに入った32人のエンジニアとエンジニアを迎えた15人のマネージャーにインタビューし、特に、チームのことを知る、担当する役割を果たせる自信の醸成、メンバーとの交流の3つを重視し、これらに対するタスクの影響を調査した。 タスクの選び方は、大きく、割り当てるタスクを少しずつ複雑にする、優先度の高いものを選ぶ、曖昧なタスクを選ぶ、の3つがあった。 オンボーディングするエンジニアがジュニアであれば最初の選び方、シニアであれば最後の選び方、アジャイルを採用するチーム、新しいチーム、納期の厳しいチームは優先度でタスクが選ばれやすく、効果的であった。 以上の考察を189名のエンジニアと37名のマネージャに評価してもらい、妥当性を確認した。
A Differential Testing Approach for Evaluating Abstract Syntax Tree Mapping Algorithms
AST mappingは、コードの変更前後のASTを比べてノードの対応関係を見つける手法であり、変更差分検出に使われる。 現状、対応関係の精度を自動で評価する有効な方法はなく、評価には人手による手間がかかる。 多くのノードに1対1の対応関係があることに着目し、異なる2つのAST mappingを同じ変更に適用した結果を比べ、個別の文やトークンごとに、より正確な方を推定するアルゴリズムを提案した。 これを応用し、複数のAST mappingアルゴリズムに同じファイルの変更差分を入力し、アルゴリズムごとの不正確に検出した箇所を自動で推定できることを示した。 特定性能は、Precisionが0.98-1.00, Recallは0.65-0.75だった。
“Ignorance and Prejudice” in Software Fairness
特徴の種類を増やすと、機械学習の予測の公平性と精度を改善できることを5つのデータセットで例示した。 データセットのタスク内容は、性別、人種、年齢を特徴に含み、経済的な裕福さや再犯率を予測するもの。 他方、教師データの数を増やしても公平性は改善されなかった。
Time, Clocks, and the Ordering of Events in a Distributed System
分散システムの各プロセスにおける送受信の半順序関係をすべてのプロセスで起きた送受信の全順序関係に拡張するアルゴリズムを提案し、アルゴリズムを同期処理に応用できることを例示した。 分散システムではプロセスの時刻が同期しているとはかぎらない。 各プロセスで起きたメッセージの送受信をプロセスでの時刻順に並べられても、その計測時刻を信じて全プロセスで起きたイベントを正しく発生順に並べることはできない。
アルゴリズムは、プロセスごとに論理的なクロックをもたせる。 クロックは、メッセージを送信するときに時を進める。 メッセージを送信するプロセスは、送信時刻をメッセージにふくめる。 受信したプロセスは現在の時刻とメッセージにある送信元の時刻より先の時刻に時を進める。 以上の手続きで、異なるプロセス間の送受信であっても送信時刻が受信時刻より必ず前になり、全プロセスの送受信イベントに全順序関係を定義できる。