W1 X-PERT: Accurate Identification of Cross-Browser Issues in Web Applications Shauvik Roy Choudhary, Mukul R. Prasad, and Alessandro Orso (Georgia Tech,

Presentation on theme: "W1 X-PERT: Accurate Identification of Cross-Browser Issues in Web Applications Shauvik Roy Choudhary, Mukul R. Prasad, and Alessandro Orso (Georgia Tech,"— Presentation transcript:

1 W1 X-PERT: Accurate Identification of Cross-Browser Issues in Web Applications Shauvik Roy Choudhary, Mukul R. Prasad, and Alessandro Orso (Georgia Tech, USA; Fujitsu Labs, USA) 担当：亀井 靖高（九州大学） 2013年07月09日　ICSE勉強会2013

2 本論文の研究ドメインと着眼点 Cross-browser incompatibilities (XBI：ブラウザ間の振る舞いの不一致)に着目している 図はpage 703のFig 2より引用

3 本論文の研究ドメインと着眼点 Cross-browser incompatibilities (XBI：ブラウザ間の振る舞いの不一致)に着目している 4 ボタンが動作 しない。 レイアウトが 異なる Undefinedと して表示される 赤色が表示 されない 1 2 2 3 図はpage 703のFig 2より引用

4 アプローチ XBIを検知するための手法を提案し，自動化ツール・X-PERTを実装する
図はpage 709のFig 4より引用

5 アプローチ XBIを検知するための手法を提案し，自動化ツール・X-PERTを実装する １ 2 3 4
図はpage 709のFig 4より引用

6 結果 14のWebサイトに対して実験を行った． X-PERTのほうが，従来法より効果的であった．
表はpage 711のTable 3(b)より引用

7 所感：３つの良いところ 研究の発展のさせ方 問題点の見せ方 実験の妥当性
ICSM2010 -> ICST2012 -> ICSE2013 問題点の見せ方 2章でXBIの一般的な問題点を述べ，3章で関連研究，4章でWebサイト100件分を著者達が手動でチェックし，XBIを分類している． 実験の妥当性 評価実験に用いたWebサイトは，従来研究で使われているもの + ランダムに選択したものを使っている． ランダム：

8 Expectations, Outcomes, and Challenges of Modern Code Review
Alberto Bacchelli (Univ. of Lugano, Switzerland) Christian Bird (Microsoft Research, USA) 担当：　黄　長贇（九州大学）

9 Research Question 現在のコードレビューの実態を調査する Expectations Outcomes Challenges
W2: Expectations, Outcomes, and Challenges of Modern Code Review

10 実証研究 Microsoftのベテラン開発者17人 インタビューを行う Microsoftのレビューのコメントを集まる
レビュー活動を観察する インタビューを行う Microsoftのレビューのコメントを集まる W2: Expectations, Outcomes, and Challenges of Modern Code Review

11 結果 Q1:コードレビューによって何を求めている？ Q2:実際にどのような結果が得られる？ Q3:何の挑戦を受けているのか？
最も重視されているのは欠陥発見 Q2:実際にどのような結果が得られる？ 欠陥発見関連のコメントは14%だけ Q3:何の挑戦を受けているのか？ レビュー内容を正しく理解するのは一番肝心 結果と要求の間が遠く離れている W2: Expectations, Outcomes, and Challenges of Modern Code Review

12 開発者へのアドバイス コードレビューは欠陥発見でそんなに役に立つ 手段でもない より良いフィードバックをもらえるため
参加者の知識を広げる 参加者にできるだけ関連情報を提供する コードレビューはたくさんの目的に使う ツールを使う以外にも参加者の直接のコミュニ ケーションが重要 W2: Expectations, Outcomes, and Challenges of Modern Code Review

13 所感：個人的に興味あるところ たくさん人からデータを集まる方法 集まったデータの整理方法 Interviewのやり取り，質問の選び方
card sort, affinity diagram W2: Expectations, Outcomes, and Challenges of Modern Code Review

14 UML in Practice Marian Petre The Open University, UK
W3 担当：戸田 航史（福岡工業大学）

15 論文概要（簡易版） Q: UMLは現場で使われていますか？ A: いいえ使われていません W3: UML in Practice

16 論文概要 UMLの企業における利用状況を2年以上にわたり調査した UMLの利用状況は5つに分類できた 50の企業に属する50名のSEが対象
該当者数 利用していない 35 改造したものを利用 1 コードの自動生成に利用 3 限定的な利用 11 完全な利用 インタビュー自体はもっと多くのSE相手に実施したが，最終的に1企業1人に絞り込んだ． 論文の貢献も，現実におけるUMLの利用状況を詳細に調査した，という点に W3: UML in Practice

17 利用していない理由 「利用する気が無い」のではなく「利用してみたが割に合わないので今は使っていない」 理解にコストがかかりすぎる
ステークホルダー側の技術力が十分高い場合でも 一貫性の維持にかかるコストが膨大 小規模プロジェクトならばともかく，大規模プロジェクトでは変更のたびに全体をチェックしなおす必要がある W3: UML in Practice

18 限定的な利用 UMLをソフトウェアを設計する上での「補助的なツール」として用いる ステークホルダーとのコミュニケーションのために
理解にコストはかかるが，有用 コミュニケーションダイアグラム 母語が異なる場合のコミュニケーションツールとして有用 フルで使うには重いが，補助的なツールとして使う分にはいいよね，というような感じですただし，限定的，という条件が付いても全体の2割程度しか使われていないという点は考慮すべき W3: UML in Practice

19 著者の最終的な主張 現場の開発者は有用なコンセプトやツールを受け入れることには躊躇がない
しかし，おかしなツールやイデオロギーは無視する，という点は考慮すべき ESEC/FSE’09にて”Insights expert software design practice”という論文も書いているので興味のある方はそちらもどうぞ 昨年紹介した”How Do Professional Developers Comprehend Software?”といい，実際の開発者のツールの利用状況調査が流行ってるんでしょうか おかしなツールが意味するものは自明． 昨年紹介した”How Do Professional Developers　Comprehend Software?”と同系統で W3: UML in Practice

20 W4 Cassandra: Proactive Conflict Minimization through Optimized Task Scheduling 著者: Bakhtiar Khan Kasi and Anita Sarma (University of Neburaska-Lincoln) 紹介者：眞鍋雄貴(熊本大学) W4: Cassandra: Proactive Conflict Minimization through Optimized Task Scheduling

21 背景 複数の開発者が並行して行う開発では衝突が起こる Rectangle.java Square.java Shape.java 変更 依存
マージ失敗 ビルド失敗 テスト失敗 W4: Cassandra: Proactive Conflict Minimization through Optimized Task Scheduling

22 衝突に関する調査 Perl, Storm, Jenkins, Voldemortプロジェクトを調査 既存手法では衝突してからしか解決できない
マージの34%～54%で衝突が起きている プロジェクトごとに起きやすい衝突の傾向や，衝突ごと の解消にかかる時間が異なる（平均0.75～30.5日） 既存手法では衝突してからしか解決できない ⇒衝突が起こる前に衝突を解決したい W4: Cassandra: Proactive Conflict Minimization through Optimized Task Scheduling

23 Cassandra 衝突がもっとも少なくなるタスクの順序を発見する問 題を制約充足問題とし，SMT Solverで解く 制約
Issue Tracker 制約 見つからなければ 見つかるまで制約を削る タスク間の前後関係 Aliceの タスクの 順序 各開発者のタスク Alice タスク Bobの タスクの 順序 タスク タスク SMT Solver(Z3) で制約を充足する タスクの順序を 探す タスク間の依存関係 Bob タスク タスク タスク 各タスクには編集されるべき ファイルが登録されている W4: Cassandra: Proactive Conflict Minimization through Optimized Task Scheduling

24 実験と結果 Cassandraをいくつかのプロジェクトに適用 大量にある制約を解決し，大部分の衝突を回避で きる
Perl, Storm, Jenkins, Voldemortプロジェクトのデータ Stormプロジェクトのデータをより大きな制約を持つよう に変異させたもの 大量にある制約を解決し，大部分の衝突を回避で きる 衝突の量：2～235 解消できた衝突：43%～100% W4: Cassandra: Proactive Conflict Minimization through Optimized Task Scheduling

25 良いと思った点 調査 実験 実際のプロジェクトで調査し，衝突の発生頻度とその特 徴について述べられている．
実際のプロジェクトより制約を多くした模擬プロジェクトを 作成することでストレステストを行っている． W4: Cassandra: Proactive Conflict Minimization through Optimized Task Scheduling