Microsoft Azure Machine Learningのサンプルを動かしてみる。「4.Choose and apply a learning algorithm」前半

この連載ももう終盤ですね。
引き続き、Azure Machine Learningのサンプルを動かしていきます。
[Create your first experiment in Azure Machine Learning Studio]
http://azure.microsoft.com/ja-jp/documentation/articles/machine-learning-create-experiment/#step-4-choose-and-apply-a-learning-algorithm

第1回、2回、3回はこちら。

  • Microsoft Azure Machine Learningのサンプルを動かしてみる。「1.Get Data」

http://toshimana.hatenablog.com/entry/2014/08/09/005803

  • Microsoft Azure Machine Learningのサンプルを動かしてみる。「2.Pre-process data」

http://toshimana.hatenablog.com/entry/2014/08/11/113416

  • Microsoft Azure Machine Learningのサンプルを動かしてみる。「3.Define, extract and enrich features」

http://toshimana.hatenablog.com/entry/2014/08/12/185342


今回は機会学習の学習アルゴリズムを設定します。
いよいよ何をしているのか分からなくなってます。
が、サンプルを動作させる手順だけは整理しておきます*1

1.データを分割する。

1-1.「Split」を用意します。

f:id:toshimana:20140813183922j:plain

1-2.末尾に接続されている「Metadata Editor」と「Split」を接続します。

f:id:toshimana:20140813184105j:plain

1-3.「Properties」-「Split」-「Fraction of rows in the first output dataset」を0.75に設定します。

f:id:toshimana:20140813193918j:plain

2.学習アルゴリズムを選択する。

2-1.「Two-Class Boosted Decision Tree」を用意します。

このブロックは「Split」と接続しません。ここでは「Split」の隣に配置しています。
f:id:toshimana:20140813194325j:plain

3.学習アルゴリズムを評価する。

3-1.「Cross Validate Model」を用意します。

f:id:toshimana:20140813194824j:plain

3-2.「Two-Class Boosted Decision Tree」と「Cross Validate Model」の"Untrained model(ボックス上部左側の小丸)"を接続します。

f:id:toshimana:20140813195406j:plain

3-3.「Split」の"Results Dataset1(ボックス下部左側の小丸)"と「Cross Validate Model」の"Dataset(ボックス上部右側の小丸)"を接続します。

f:id:toshimana:20140813200023j:plain

3-4.「Cross Validate Model」の「column selector」を表示します。

f:id:toshimana:20140813200729j:plain

3-5."Include", "column names"と設定し,入力項に"price"を入力します。

f:id:toshimana:20140813200858j:plain

3-6.右下のチェックボタンを押します。

f:id:toshimana:20140813201011j:plain

4.処理を実行する。

4-1.画面下の「Run」ボタンを押します。

f:id:toshimana:20140813201123j:plain

4-2.処理が実施されます。

f:id:toshimana:20140813201255j:plain

4-3.処理が終了するまで待ちます。

処理が終了すると、画面右上に「Finished running」が表示されます。
f:id:toshimana:20140813201349j:plain

5.結果を確認する。

「Cross Validate Model」の"Scored Result(ボックス下部左側の小丸)"

f:id:toshimana:20140813201924j:plain

「Cross Validate Model」の"Evaluation results by fold(ボックス下部右側の小丸)"

f:id:toshimana:20140813201931j:plain

終わりに

一通りサンプル動作の手順をまとめた後に、
やっていることを整理したいと思います。

*1:機械学習が分かる人がサンプルを試してみて、内容をまとめると良いと思います

プログラマのコードレビューと学生マジシャンの手順見せの関連について

ソニックガーデンさんの「コードレビュー7つの秘訣」と自分の大学時代のマジックサークルにおける「手順見せ」のポイントについて、私が感じた関連について書いていきます。

はじめに

8/11(月)に受けたSonicGarden Studyを聞いて思ったことを書いてあります。

「いつまでクソコードを書き続けるの? 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜 - SonicGarden Study #11」
http://sonicgarden.doorkeeper.jp/events/13229?utm_campaign=event_13229_10033&utm_medium=email&utm_source=registered_message

以下、上記受講後に書いた記事です。
「2014/8/11(月) 「SonicGarden Study #11いつまでクソコードを書き続けるの? 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜」に参加しました。」
http://toshimana.hatenablog.com/entry/2014/08/11/234145

最初は「へぇーそうなんだ」と思ってみていましたが、話が進んでいくと、何か昔似たことをやったことがあるな…と既視感がありました。
そう、自分が大学で所属していたマジックサークルの「手順見せ」におけるポイントと「コードレビュー7つの秘訣」がそっくりだったんだよ!!*1

というわけで、あまり関係がなさそうな、プログラマのコードレビューと学生マジシャンの手順見せについて、ソニックガーデンさんの「コードレビュー7つの秘訣」をベースに関連性をまとめてみました。

手順見せとは?

ここでは、自分が所属していたマジックサークルの手順見せについて簡単に説明します。
ここでの手順見せとは、「年に1度の発表会のために、発表会演者が他の部員に自分の手順を披露して、意見をもらうこと」を指します。
発表会は12月ですが、そのために1年かけて準備を行います。演者は初期は2週に一度手順見せを行いますが、8月以降は1週に一度手順見せを行います。

「コードレビュー7つの秘訣」

ソニックガーデンさんの「コードレビュー7つの秘訣」は、以下になります。

  1. レビューの観点を明確にすること
  2. 我が身に返ることを恐れずに指摘すること
  3. 何故悪いコードなのかを論理的に説明すること
  4. 良いコードについて共通認識を持つこと
  5. 小さい単位でレビューを繰り返すこと
  6. 指摘は素直な気持ちで受け入れること
  7. 指摘は人格否定でないことを理解すること

「コードレビュー7つの秘訣」とマジシャンの手順見せの関係

1.レビューの観点を明確にすること

手順見せの時期によって観点が変わります。序盤は演技の方向性について、中盤は演技構成について、終盤は細かい技術や表現についてなどについて指摘します。
おそらく、納品がない開発をしているソニックガーデンさんはあまり細かい指摘はしないと思いますが、手順見せは納品相当である発表会の時点で最高の演技を届けるように指導することから、細かい指摘を行うという差はあるかと思います。

2.我が身に返ることを恐れずに指摘すること

マジックの舞台は"理想を表現するところ"なので、指摘する側も自分ができないような指摘をする場合があります。その場合は、指摘して終わりではなく、どうすればその理想に近づけるかをしっかり議論します。

3.何故悪いコードなのかを論理的に説明すること

マジックの舞台としてやってはいけないことは共通認識として部員みんなが持っています。なので、「やってはいけない事に抵触している」という指摘は、受ける側も素直に受け止めます。

4.良いコードについて共通認識を持つこと

みんな過去に発表会に出た人の演技を見ているので、憧れるような演技について共通認識ができています。指摘をする際にも、「xxがやった演技を参考にするといい」という指摘はよく出てきます。

5.小さい単位でレビューを繰り返すこと

1週間に一度、部員全体に手順見せを行います。しかし、それとは別に、より小さい手順見せを別途行います。同じ種類のマジックをする人たちで師弟関係があり、発表会に出る予定の弟子は、部員全体の手順見せの前に師匠に手順見せを行います。そうすることで、弟子たちはフィードバックを多く行い、短い期間でマジシャンらしい技術、考え方を身に着けることができます。

6.指摘は素直な気持ちで受け入れること

技術的な指摘については、素直に指摘を受け入れて練習する人の方が伸びる傾向がありました。ただし、感性的な指摘は受けた側が納得できないことも多いです。ここは「コードレビュー7つの秘訣」とは異なり、学生マジックは"変わったことが好まれる"ことから、感性的な部分は我を通すことが望ましいと考えられています。マジシャンにおける"感性的な指摘"は、プログラマにおける"宗教戦争"に相当するかと思います。

7.指摘は人格否定でないことを理解すること

そもそも、指摘として人格否定をすることがほぼなかったように思います。指摘も技術的に具体的なことが多いので、指摘を受けた側が指摘を人格の否定に捉えることもあまりないと思います。手順を良くすることが目的であることを全員で共有できていれば、「人格を否定しても良いものはできない」ことが分かるかと思います。

おわりに

コードレビューのような文化はプログラマ以外の業界でも多く行われているはずです。
8/7(木)にソニックガーデン倉貫さんが仙台で「納品のない受諾開発」について話してくれました。その中で、「絵描きが成長する際も、書いた絵を師匠に見てもらい、良い絵の描き方を学んでいる」という内容の話をしていました。
プログラマに限らず、良いレビューというのは、あらゆるクリエイティブな業界で必要になるものと感じました。
また、ソースレビューがより良い方向に発展するためには、他業種のレビューから発見できそうだと感じています。
いろんなレビュー文化を調べてみると面白いかもしれませんね。

*1:な、なんだってー!!

Microsoft Azure Machine Learningのサンプルを動かしてみる。「3.Define, extract and enrich features」

Azure Machine Learningのサンプルを動かしていきます。
[Create your first experiment in Azure Machine Learning Studio]
http://azure.microsoft.com/ja-jp/documentation/articles/machine-learning-create-experiment/#step-3-define-extract-and-enrich-features

第1回、2回はこちら。

  • Microsoft Azure Machine Learningのサンプルを動かしてみる。「1.Get Data」

http://toshimana.hatenablog.com/entry/2014/08/09/005803

  • Microsoft Azure Machine Learningのサンプルを動かしてみる。「2.Pre-process data」

http://toshimana.hatenablog.com/entry/2014/08/11/113416


ちなみに、今回からは画像加工ソフトに[Skitch]を使っています。*1

1.「Project Columns」を用意する。

1-1.新しい「Project Columns」を用意します。

f:id:toshimana:20140812185146j:plain

1-2.「Missing Values Scrubber」と「Project Columns」を接続します。

f:id:toshimana:20140812100050j:plain

2.データを選別する。

2-1.「Project Columns」の「column selector」を表示します。

f:id:toshimana:20140812100734j:plain

2-2.「Begin With」を"No columns"に設定します。

f:id:toshimana:20140812101253j:plain

2-3.次列を"Include", "column names"と設定します。

f:id:toshimana:20140812101328j:plain

2-4.column nameの入力項に、以下の項目を入力します。

  • make
  • body-style
  • wheel-base
  • engine-size
  • horsepower
  • peak-rpm
  • highway-mpg
  • price

f:id:toshimana:20140812101921j:plain
ちなみに、入力補完機能があるので、簡単に入力できます。
f:id:toshimana:20140812102353j:plain

2-5.右下のチェックボタンを押します。

f:id:toshimana:20140812102603j:plain

3.Labelを設定する。

3-1.「Metadata Editor」を用意します。

f:id:toshimana:20140812103150j:plain

3-2.「Project Columns」と「Metadata Editor」を接続します。

f:id:toshimana:20140812103454j:plain

3-3.「Metadata Editor」の「column selector」を表示します。

f:id:toshimana:20140812103658j:plain

3-4.「Begin With」を"No columns",次列を"Include", "column names"と設定し,入力項に"price"と入力します。

「Project Columns」のときと違って、入力補完機能が利きません。何故?
f:id:toshimana:20140812104139j:plain

3-5.右下のチェックボタンを押します。

f:id:toshimana:20140812104241j:plain

3-6.「Properties」-「Metadata Editor」-「Fields」を"Labels"に設定します。

f:id:toshimana:20140812104603j:plain

4.Feature typeを変更する。

4-1.新しい「Metadata Editor」を用意します。

以下、特に追記がない場合、「Metadata Editor」は4-1で作成したものを指すものとします。
f:id:toshimana:20140812105116j:plain

4-2.3-1で作成した「Metadata Editor」と「Metadata Editor」を接続します。

f:id:toshimana:20140812115700j:plain

4-3.「Metadata Editor」の「column selector」を表示します。

f:id:toshimana:20140812115841j:plain

4-4.「Begin With」を"No columns",次列を"Include", "column names"と設定し,入力項に"make"と"body-style"を入力します。

f:id:toshimana:20140812120417j:plain

4-5.右下のチェックボタンを押します。

f:id:toshimana:20140812120451j:plain

4-6.「Properties」-「Metadata Editor」-「Data type」を"String"に設定します。

f:id:toshimana:20140812120636j:plain

4-7.「Properties」-「Metadata Editor」-「Categorical」を"Categorical"に設定します。

f:id:toshimana:20140812120812j:plain

5.処理を実行する

5-1.画面下の「Run」ボタンを押します。

f:id:toshimana:20140812121018j:plain

5-2.処理が実施されます。

f:id:toshimana:20140812121221j:plain

5-3.処理が終了するまで待ちます。

処理が終了すると、画面右上に「Finished running」が表示されます。
f:id:toshimana:20140812121344j:plain

6.結果を確認する。

確認できる処理結果:2-4で指定した項目のみが表示される。

変更前(Missing Values Scrubber)

f:id:toshimana:20140812121947j:plain

変更後(Metadata Editor)

f:id:toshimana:20140812121953j:plain

確認できる処理結果:"price"のFeature typeがNumeric Labelsになる。

変更前(Missing Values Scrubber)

f:id:toshimana:20140812182544j:plain

変更後(Metadata Editor)

f:id:toshimana:20140812182722j:plain

確認できる処理結果:"make","body-style"のFeature typeがCategoricalになる

変更前(Missing Values Scrubber)

f:id:toshimana:20140812183143j:plain

変更後(Metadata Editor)

f:id:toshimana:20140812183100j:plain

終わりに

現時点では、デモの動作方法だけを説明しています。
処理の細かい意味は特に説明していませんが、後で解説するかもしれません。

*1:前回までは画像加工ソフトにGIMPを使用していました

2014/8/11(月) 「SonicGarden Study #11いつまでクソコードを書き続けるの? 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜」に参加しました。

「SonicGarden Study」とは株式会社SonicGardenが開催する、WEB上のIT勉強会です。
勉強会はUstream上で行われました。

表題の通り、クソ天使コード*1をなくす取リ組みとして有効なコードレビューについて、実践で気を付けるべき7つのポイントについてお話がありました。

クソ天使コードとは?

勉強会ではクソ天使コードを"読む人を怒りの渦に叩き込むコード"と定義している。私の印象だと、デスマーチを誘発するもの、でもあるんじゃないかと思います。

優れたプログラマとは?

クソ天使コードを書かないプログラマは優れたプログラマと言える。
また、優れたプログラマであることを測るためには、コードの1行1行に対して、どういう処理か、どういう意図で書いたか、を確認することが有効。

コードレビューが改善の近道であること

クソ天使コードが"読む人に怒りをもたらすコード"とするなら、クソ天使コードかどうかは読む人がいないと分からない。

しかし、"優れていない"プログラマ同士がレビューをしても、指摘内容に限界があるため、成長が遅い。
そのため、"優れた"プログラマが考え方を伝えることで、"優れていない"プログラマの成長速度を高めることができる。

ただし、"優れた"プログラマでも闇雲にレビューをしていたら効果はない。そのため、ソニックガーデンが実践で築いた「7つの秘訣」を意識すると、良いレビューができるようになる。

コードレビュー「7つの秘訣」

大きく、「レビューをする側の秘訣」と「レビューを受ける側の秘訣」に分かれている。

【レビューをする側の秘訣】

1.レビューの観点を明確にすること

その時のレビューで何を指摘するかは明確にすること。観点を明確にすることで、観点から外れた指摘(その時点では重要ではない)を抑えることができます。また、観点があらかじめ明確であることで、指摘を受ける側が"理解する準備"ができているため、指摘内容を効果的に吸収できます。

2.我が身に返ることを恐れずに指摘すること

レビューする側がその時点でできていないことでも、本質的な部分については容赦なく指摘することが大事。レビューする側も今後気を付けるようになるため、双方の成長につながる。
ちなみに自分が感じたこととして、レビューする側のことを棚に上げたとしても、実現できないような無茶事は指摘すべきでない*2と思います。レビューを受けた側の行動に繋がらないような指摘は、良くないと思っています。

3.何故悪いコードなのかを論理的に説明すること

指摘内容について感覚的な指摘しかない場合、レビューを受けた側は修正しようがありません。レビューをする際は論理的な理由を添えて、レビューを受けた側が理解できるようにしましょう。

4.良いコードについて共通認識を持つこと

目指すべきコードはチームで認識を合わせ、全員で目指すことが重要*3。ただし、宗教戦争が起こりやすい部分は、無駄な議論が起こりやすいので、戦争を悪化させないように注意する必要がある。

5.小さい単位でレビューを繰り返すこと

1度で多くのレビューをすると、量が多く、十分に見きれない場合が多い。また、レビューする側も訓練が必要であり、レビューを多くこなすことで経験値を多く得られるようにする。

【レビューを受ける側の秘訣】

6.指摘は素直な気持ちで受け入れること

指摘内容をしっかり理解し、次回以降に反映することが重要。指摘内容について納得できない場合は、そのことを指摘者と十分に話し合うこと。納得できない内容を議論せずに無視することは、成長を自ら止めていることになる。

7.指摘は人格否定でないことを理解すること

レビューでの指摘はコードの指摘であるため、必要以上に落ち込んだりしないように意識する必要がある。もちろん、レビューする側も人格を否定する発言をしないように心掛ける必要がある。

終わりに

「7つの秘訣」の内容は、特に奇抜なものはなく、どちらかというとレビューの基本に近いものに感じました。しかし、(理想にも近い)基本をしっかりと追い続けられることが、ソニックガーデンさんの強みなのだとも感じました。

また、「7つの秘訣」にはありませんでしたが、個人的に付け加えたい項目として、「問題点を指摘するときは、共に改善案を与えること」があります。問題点を指摘するだけだと批判的になり、レビューを受けた側もどのように改善すればよいか分かりません。問題点と共に改善案を与えることで、レビューを受けた側の次のアクションが明確になります。自分はレビューをする時は、指摘に対してできる限り改善案を用意するようにしています。

しかし、Webで受ける勉強会は初めてだったのですが、思った以上に気楽に受講できて、楽しかったです。次回以降も受けたいと思いました。

*1:勉強会内で表現をマイルドにするために呼ばれていたが、後半の方は使われていなかった

*2:ソニックガーデンさんは"無茶なことも指摘せよ"とは言っていないです。

*3:ソニックガーデンさんでは、例えば"重複コードがないこと"など

Microsoft Azure Machine Learningのサンプルを動かしてみる。「2.Pre-process data」

前回に引き続き、以下のサンプルを動かして見ます。
[Create your first experiment in Azure Machine Learning Studio]
http://azure.microsoft.com/ja-jp/documentation/articles/machine-learning-create-experiment/#step-2-pre-process-data

前回の記事は以下のURLページにあります。
Microsoft Azure Machine Learningのサンプルを動かしてみる。「1.Get Data」
http://toshimana.hatenablog.com/entry/2014/08/09/005803
f:id:toshimana:20140809003009j:plain


今回は、機械学習処理を実施するための前処理を行います。

1.データがないセルを"?"に置き換える

1-1.検索ボックスに"convert"と入力します。

f:id:toshimana:20140811080736j:plain

1-2.候補が表示されます。

f:id:toshimana:20140811080951j:plain

1-3.「Convert to Dataset」をexperiment canvasに配置します。

既にexperiment canvasに配置してある「Automobile price data(Raw)」の下に配置しましょう。
f:id:toshimana:20140811083202j:plain

1-4.「Automobile price data(Raw)」と「Convert to Dataset」を接続します。

1-4-1.「Automobile price data(Raw)」のoutput port(ボックスの下側にある小丸)にマウスカーソルを合わせます。

f:id:toshimana:20140811090325j:plain

1-4-2.ドラッグ&ドロップで「Convert to Dataset」のinput port(ボックスの上側にある小丸)までマウスカーソルを移動します。

f:id:toshimana:20140811090659j:plain

1-4-3.「Automobile price data(Raw)」と「Convert to Dataset」が接続されました。

f:id:toshimana:20140811112943j:plain

1-5.「Convert to Dataset」ボックスを選択します。

選択状態のボックスは青枠で囲まれます。
画面右側に選択状態のボックスのPropertyが表示されます。
f:id:toshimana:20140811113000j:plain

1-6.「Properties」-「Convert to Dataset」-「Action」を"ReplaceValues"に設定します。

f:id:toshimana:20140811091513j:plain

1-7.1-6と同様に、「Replace」を"Missing"に、「New Value」を"?"に設定します。

f:id:toshimana:20140811091707j:plain

2.「Project Columns」を用意する。

2-1.「Project Columns」をexperiment canvasに配置します。

f:id:toshimana:20140811092418j:plain

2-2.「Convert to Data」と「Project Columns」を接続します。

f:id:toshimana:20140811092539j:plain

3.処理する列を選択する

3-1.「Project Columns」を選択します。

f:id:toshimana:20140811093854j:plain

3-2.「Properties」-「Project Columns」-「Launch column selector」を選択します。

f:id:toshimana:20140811093950j:plain

3-3.「select columns」画面が表示されます。

f:id:toshimana:20140811100950j:plain

3-4.「Begin With」を"All columns"に設定する。

f:id:toshimana:20140811101312j:plain

3-5.次列を"Exclude", "column names"と設定し、入力項に"normalized-losses"と入力する。

f:id:toshimana:20140811101756j:plain

3-6.入力項に入力後、Enterを押すと表示が変わります。

f:id:toshimana:20140811102159j:plain

3-7.右下のチェックボタンを押します。

f:id:toshimana:20140811102225j:plain

3-8.「Properties」-「Project Columns」-「Selected columns」に設定内容が反映されます。

f:id:toshimana:20140811102559j:plain

4.列を削除する

4-1.「Missing Values Scrubber」をexperiment canvasに配置します。

f:id:toshimana:20140811103134j:plain

4-2.「Project Columns」と「Missing Values Scrubber」を接続します。

f:id:toshimana:20140811103400j:plain

4-3.「Missing Values Scrubber」を選択します。

f:id:toshimana:20140811103718j:plain

4-4.「Properties」-「Missing Values Scrubber」-「For missing values」を"Remove entire row"に設定します。

f:id:toshimana:20140811113132j:plain

5.処理を実行する

5-1.画面下の「Run」ボタンを押します。

f:id:toshimana:20140811104704j:plain

5-2.処理が実施されます。

f:id:toshimana:20140811105010j:plain

5-3.処理が終了するまで待ちます。

処理が終了すると、画面右上に「Finished running」が表示されます。
f:id:toshimana:20140811105114j:plain

6.結果を確認する

6-1.「Missing Values Scrubber」のoutput portにマウスカーソルを合わせます。

f:id:toshimana:20140811110111j:plain

6-2.右クリックでメニューを開き、「Visualize」を選択します。

f:id:toshimana:20140811110123j:plain

6-3.「Missing Values Scrubber」の処理結果が表示されます。

f:id:toshimana:20140811110240j:plain

確認できる処理結果:"normalized-losses"の項目が削除されている。

変更前(Automobile price data(Raw))

f:id:toshimana:20140811111010j:plain

変更後(Missing Values Scrubber)

f:id:toshimana:20140811111033j:plain

確認できる処理結果:データがないセルの内容が、"?"に変わっている。

変更前(Automobile price data(Raw))

f:id:toshimana:20140811111454j:plain

変更後(Missing Values Scrubber)

f:id:toshimana:20140811111538j:plain

終わりに

本ページでスクリーンショットを多用しているため、
画像の加工技術がちょっと上がりました。
しかし、画像加工には結構時間が取られます。何とかしたい。

Microsoft Azure Machine Learningのサンプルを動かしてみる。「1.Get Data」

以下のサンプルを動かして見ます。
[Create your first experiment in Azure Machine Learning Studio]
http://azure.microsoft.com/ja-jp/documentation/articles/machine-learning-create-experiment/#step-1-get-data

今回はサンプルのデータを読み込むところまでやっていきます。
ML-Studioが起動している状態から始めていきます。
f:id:toshimana:20140809000039j:plain
ML-Studioを起動するまでは、以下を参照してください。
http://toshimana.hatenablog.com/entry/2014/07/30/230312

ちなみに、Azureポータルページでは日本語がいっぱい出てきましたが、
ML-Studioは基本英語です。頑張りましょう。

1.新しいExperimentを作る

ここでのExperimentは、Visual Studioでいうプロジェクトだと自分は理解しています。

1-1.左下にある「+NEW」を選択します。

f:id:toshimana:20140809000050j:plain

1-2.下からグイっと出てきます。

f:id:toshimana:20140809000157j:plain

1-3.「EXPERIMENT」を選択します。

f:id:toshimana:20140809000356j:plain

1-4.新しい「Experiment」ページが表示されます。

f:id:toshimana:20140809001006j:plain

1-5.Experiment名を変更します。

適当な名前を付けましょう。ここでは[ML-Sample]としています。
f:id:toshimana:20140809001156j:plain

2.サンプルデータを検索する

サンプルで使用する「Automobile price data(Raw)」データセットを検索します。
ML-Studioは画面左側にあるツリー(下図赤枠内)から必要なデータブロックや処理ブロックを選択し、ブロック同士を線でつなぐことで機械学習に必要な処理を行うことができます。
f:id:toshimana:20140809001654j:plain

2-1.検索ボックスに"automobile"と入力します。

f:id:toshimana:20140809002440j:plain

2-2.候補が表示されます。

f:id:toshimana:20140809002558j:plain

3.データをexperiment canvasに配置する

ドラッグ&ドロップで各ブロックをexperiment canvas(下図赤枠内)に配置できます。
f:id:toshimana:20140809003251j:plain

3-1.「Automobile price data(Raw)」をクリックします。

f:id:toshimana:20140809002500j:plain

3-2.ドラッグ&ドロップでexperiment canvas上に配置します。

f:id:toshimana:20140809003009j:plain

4.データの内容を表示する

4-1.「Automobile price data(Raw)」ブロックのoutput port(ブロック下側の○)にカーソルを合わせます。

f:id:toshimana:20140809003655j:plain

4-2.右クリックして、メニューを表示します。

f:id:toshimana:20140809004003j:plain

4-3.「Visualize」を選択します。

f:id:toshimana:20140809004137j:plain

4-4.「Automobile price data(Raw)」に含まれているデータが表示されます。

f:id:toshimana:20140809004434j:plain

4-5.データの表示を終了するときは、右上の「×」ボタンを押します。

f:id:toshimana:20140809004509j:plain

終わりに

次回からデータを加工していく手順に入ります。
やっとに機械学習らしくなってきてる!

7/31(木)「ソフトウェアテスト勉強会~探索的テストを基礎から学んでみる①~」に参加しました。

名前はよく聞く「探索的テスト」ですが、
正直、”適当な、場当たり的な”印象を持っていました。
今回は、そんな「探索的テスト」についてお話を聞いてきました。

参考資料 : SlideShare[探索的テスト入門]
http://www.slideshare.net/goyoki/ss-34292539?utm_campaign=ss_search&utm_medium=default&utm_source=1&qid=0eac1c4f-ea48-4889-8875-3030115f15c7&v=default&b=&from_search=1

探索的テスト

  • テスト手順のスクリプト化を行わない
  • テスト実施者の知見や思考、事前の分析情報、対象を動作させたフィードバックを元に、テスト実施とテストの構築を並行に実施する
  • スクリプトテスト等と比較して、属人性が高い

アドホックテストとの関係

探索的テストでは、対象をよく理解しようとすることが重要。対象の挙動に基づいて、どのような実装かを予想する。その上で挙動が怪しいと思われるところについて、重点的にテストをする。
また、テスト実施中は“匂い”について敏感にあるべき。対象の挙動について”匂う”と感じた時点では論理飛躍が起きているが、論理飛躍を埋めるような予想とテストを繰り返すことで、匂いの元(欠陥)に到達できることがある。

スクリプトテストに対する探索的テストの特徴

利点

  • 仕様やテスト設計の穴に対して強く、未知の欠陥検出に効果がある
  • 暗黙知や明文化しやすいノウハウを活用できる

欠点

  • 属人性が高く、テスト実施者の能力によって成果に大きな差が出る
  • 記録に残しにくい
  • 網羅的にテストできているかが分かりにくく、テストの品質保証が難しい

探索的テストの活用法

基本的にはスクリプトテストと併用する。回帰テストスクリプトテストで行い、探索的テストで未知な欠陥を検出する。
全てのテストをスクリプトテストで実施しようとした場合、テストのドキュメント化や修正、運用に対して多くのコストを掛ける必要がある。対象の品質を保証するテストはスクリプトテストで構築しつつ、欠陥検出のテストは探索的テストで補完する。

終わりに

探索的テストで重要な”知的なアプローチ”については、もっと色々知りたいと思います。