2014年5月27日火曜日

クロスプラットフォーム、クロスブラウザのテストを仮想環境で簡単に

仕事でIE8のテストをしなければならなくて、そんな端末ねーよ!って思ってたら、仮想環境で簡単にテストできたのでメモ。
いやー、時代が変わったなぁ。。。

以下の手順の6と8は日本語対応のため。
XPのCDがあれば、以下の手順でOSレベルで日本語対応できるみたい。
コントロールパネル
->Regional and Language Options
->Languageタブ
->Install files for East Asian languagesにチェック
->Apply

あと、XP以外であれば、他にも方法があるらしい。

1.VirtualBoxのインストール

https://www.virtualbox.org/wiki/Downloads

2.仮想イメージのダウンロード

以下から、Windows, Virtual Box(Windows上)を選択し、IE8-XPのファイルを全てダウンロード
http://modern.ie/ja-jp/virtualization-tools#downloads


3.ダウンロードしたexeファイルを実行する



4.作成されたovaファイルをダブルクリックする



5.VirtualBoxマネージャーの設定から以下を実施

共有フォルダー
->画面右上の追加アイコンをクリック
->任意のフォルダを追加(読み込み専用、自動マウントの両方にチェック)


6.フォントをコピー

C:¥Windows¥Fonts 配下のMSゴシック、MS明朝を共有したフォルダーにコピー


7.仮想環境を起動



8.仮想環境でフォントをコピー

共有したフォルダーのフォントをC:¥Windows¥Fonts配下にコピー


9.Lets's TEST!!!

OSは英語でもブラウザでは日本語がみれる!

2014年5月25日日曜日

PI Study #2 「ペアワイズ法を使ったテスティングワークショップ」

@東京都豊島区東池袋3丁目4番3号池袋イースト10F テラインターナショナル株式会社
http://pistudy.doorkeeper.jp/events/11043

仲間とはじめた勉強会の2回目。
1回目はSTARの良質なコンテンツを使ったので、余裕だったけど、今回は1からつくったので、なかなか大変でした。
で、一人KPT。

KEEP


  • 講義を聞くだけではなく、実際に手を動かす
  • モクモクとやるのではなく、チームで話しながらやる
  • 講師は気負わず、知ってる範囲で知ってることを伝え、共に学び合う
  • みなさん熱中してくれた(休憩もとらずにやってた)
  • 「他の勉強会も色々でてるけど、平均より良い勉強会ですよ」と言ってくれた
  • 永井くんが「Gebを勉強して今度は僕がやります!」と言ってくれた

PROBLEM


  • ペアワイズ法と銘打ったにも関わらず、ペアワイズ法を深堀りしなかった
  • 2因子網羅の部分の説明が足りず、理解してもらえなかった人がいた
  • DevNomiテスト編で、計算が複雑すぎてそこで無駄な時間を食ってしまった
  • チームに発表してもらったときに、気の利いたコメントが言えなかったし、チーム間でディスカッションするファシリテーションができなかった
  • 若手向けを意識したけど、若手は勉強会にはあまり来ない

TRY


  • 絶対に持ち帰って欲しいものを1つ決めて、そこはきちんと深堀りして準備する
  • ディスカッションの時間をきちんととり、準備したうえでファシリテーションする

2014年5月17日土曜日

DevLOVE「オブジェクト設計とリーン開発、その実践」に参加しました


@名古屋市中区錦1-15-8 アミティエ錦第一ビル 4F Coworking Space A+LIVE セミナールーム

正しいものを正しくつくる
ギルドワークス創業おめでとうございます!
増田さんのプロジェクトで増田さんに叱られながら仕事してみたいなぁ。

第一部 オブジェクト設計エクササイズ [13:10〜14:00] 増田亨氏



設計とは、変更コストを下げるためにコードを整理整頓する実践的な工夫

プロセスやツールよりも設計

コードを整理、整頓する。
それは、変更コストを下げたいから。
(作って終わりならいらないけどね。)

実践的ってなんだろう?

いくつかの観点で、対岸を行ったり動きながらバランスを取る。
(全体<->部分、長期<->短期・・・)

具体的にどうやるの?

変更コストの原因を知る。
変更コストの最大の敵は「重複したコード」。

重複したコードのいやな臭い(Martin Fowler "Refactoring")


  • 長いメソッド
  • 大きなクラス
  • たくさんの引数


マスダ流重複の臭い判定基準


  • クラス:50行(100行)
  • メソッド:3行(5行)
  • 引数:0(1)

これを超えたら警戒警報!
(カッコの中はチーム用に緩めた数字)

コード整理の基本パターン


  • Value Object
  • 振る舞いを持った区分
  • ファーストクラスコレクション


Value Object

immutableがポイント。
例)Stringクラス
内部の値を変えずに、新しいObjectを返している。

getメソッドをつくらない。
getをつくるとロジックが散らばる。
データのある場所にロジックを寄せる。
setメソッドもつくらない。
setをつくると状態管理のコードが散らばる。
=> immutable(不変オブジェクト)

プリミティブなクラスは使わず、業務(ドメイン)固有のクラスを作る。
例)
String, StringBuilder, List<String> => ProductName, Remarks
BigDecimal, Integer => Money, Quantity, Unit
Calendar, Date => InitialDate, DueDate, ValidTerm

振る舞いを持った区分

enumにメソッドを持たせる。
定数も、関連するロジックはそこに閉じ込める。

ファーストクラスコレクション

privateなコレクション、publicな振る舞い。
コレクションをgetして操作するとあちこちにコードが登場する。
例)
Customers, OrderLines, UsageHistory, ToDoList・・・

コードの整理 アンチパターン


  • Smart UI(画面単位で設計)
  • トランザクションスクリプト(機能単位で設計)
  • Active Record(テーブル単位で設計)

=> 必ずコードが重複する。

Smart UI => 画面間で重複が発生する。トランザクションスクリプト => 機能間で重複が発生する。
Active Record => テーブル間で重複が発生する。

コードの整理 グッドパターン


  • 3層+ドメインモデル
  • 業務の関心事(業務知識)に基づき設計する

=> 変更が簡単

  • 仕様変更は業務から発生する
  • 業務の関心事の依存関係がクラスの依存関係になっている
  • 変更の対象箇所以外でわけのわからない副作用がおきない


第二部 リーン開発の現場 [14:10〜15:00] 市谷聡啓氏


理想とはたとりつくべき場所のことではなく、ありたい姿に向かい続けることなんだ!

誰かが正解を持っている訳ではない


開発の命運を握る2つのレバー


  • 期待
  • リスク


期待

関係者が互いに持っているプロダクト/プロジェクト/チームへの暗黙的な望み

期待マネジメント

期待を明らかにして適切に調整しつづける。役割と時間を超えて。

チーム => プロジェクト => プロダクト => ビジネス => 組織

レイヤーごとに目的と期待がある。
レイヤーを超え、役割を超えた理解が必要。

Moving Management Target

期待とリスクのバランスは時間とともに変わっていく。
時間を超えた理解が必要。

インセプションデッキ

期待マネジメントのツールの1つ。
大事なのは、アウトプットではなく、その過程でお互いに理解しあうこと。

仮説検証型と最短距離型

目的実現のための選択肢がいろいろある。
=> 何を選ぶか決めるために試行し検証する。
=> 検証から何をどう作るか徐々に決められる
=> 手段と対象がわかれば、最短距離でつくる

スコープが決まってないのに期限だけ決まってる
=> 超危険
=> 仮説検証時は期間契約、スコープが決まれば請負契約

大事なのは、フェーズによって戦い方が変わるということ。

仮説検証型のPlan

リーンキャンバス(仮説)
=> エクスペリエンスマップ(検証)
=> ユーザーストーリーマッピング(仮説)
=> インセプションデッキ(検証)

参考)
「開発戦略は「意思決定」を遅らせろ!」(稲垣 公夫)

最短距離型のPlan

CCPM
パーキンソンの法則:バッファを使いきってしまう。
=> バッファをプロジェクト全体で管理する。

荒ぶる計画を飼い慣らす

  • 要求レベルをMust, Want, Tryで可視化する
  • プロジェクトの8-9割でMustを実現できる見込みを立てる
  • 残った工数でWantを開発する


仮説検証型のDo

なんのための反復?
何を検証するのか?

カンバン(仮説検証型、最短距離型)

仮説検証型:タスク、課題解決の可視化 => タスクボード
最短距離型:全体フローの見える化 => カンバンボード

仮説検証型と最短距離型の見極め

=> インセプションデッキ

ソフトウェアを創り上げるもの

誰が、誰と、誰のために
どういうルールで、何を作るか

リーン開発の現場 P.109

理想とはたとりつくべき場所のことではなく、ありたい姿に向かい続けることなんだ!

第三部 Q&A [15:10〜16:00]


  • DDDをどれくらいかけて覚えれば?
    => 2008年からはじめてわかりはじめたのが2012年。現場で続けるのが一番。
  • フレームワークを使っている場合(コード自動生成)の折り合いは?
    => 大嫌いだから使ってない。折り合いの付け方もノウハウ。
  • クラスが多くなったときのまとめ方は?
    => 業務にあわせてパッケージを構成している。
  • お客様に丸投げされたときにどうすれば?
  • バッファと見積の合意方法は?
    => QCDSのトレードオフスライダーを使ったりする。
  • そもそもドメインって何?
    => まあ、気にしないほうがいい(^^)。カタカナは日本語にするとよい。
  • インフラからプログラマになるとき何を学べば?
    => 今はインフラもコードで自動化する時代。そこからはじめては。
  • 設計の価値をどう伝えれば?
    => 相手が開発者であれば、変更が大変だったネタを思い出して盛り上がる。そこからスタートすると伝わりやすい。設計とは何かとか良い設計とはとかのアプローチは必ず失敗する。ただ、人がつくったコードで痛い目あってる体験共有からだとうまくいかない。
  • 期待をどうマネジメント?どうまとめる?
    => インセプションデッキを使う。困ったらぜひギルドワークスへ(^^)。インセプションデッキの期待が高くなり過ぎないようにしれっとね。
  • 設計の考え方をどう共有するか?
    => 経験がないのでわからない。若い頃は意地になって相手を潰すぐらい勉強した。
  • カンバンをどう広めるか?
    => いきなり実プロジェクトでやるのはリスクが高い。カンバンだったら、まずは、自分でやれる範囲でやるとか。失敗できるところでやってから。
  • どんなドキュメント管理してる?
    => クラス図やドキュメントを全部作ってない。ドメイン知識が増えれば、ドキュメントがなくてもわかる。新しいメンバーにはドキュメントではなく、業務を覚えてもらう。業務がわかれば、ソースが読める構造になっている。
    => IDEが優秀だから。IntelliJ IDEAがオススメ。すぐ乗り換えよう。
  • どんな工程?
    => 全部網羅的に設計せずに、重要な部分だけ抜き出して設計してる。
  • 開発スピードが落ちない?
  • マスダ流は厳しすぎない?
    => 実践でいきなりやるのは難しいかもしれないが、実際にやって、まずは体験してみて。
  • なんのロジックも持たなくて、単純な置き換えでもクラス化する?
    => する。名前がほしいから。

2014年5月13日火曜日

SeleniumとGebとCasperJSの比較

STARの教材を使って、SeleniumとGebとCasperJSを比較してみました。
どれも詳しくなく、軽く触っただけですが。

比較結果

個人的には、Geb(+spock)が好きです。
ただ、Web系でJavaScriptバリバリの人が多いなら、CasperJSは有力でしょう。
コマンド一発でインストールできて、テキストエディタ一本で開発できちゃうし、動作もサクサク。
この軽量さは好感が持てます。
クロスブラウザができないという弱みはありますが、結局、クロスブラウザって目視確認しないと微妙な崩れとかわからないので、実はそんなに弱みではない場合も多いと思います。

操作性

操作性はGebが圧倒的です。
JQueryライクに要素をとれたり、すべてのhtmlコントロールでメソッドが大体同じだったり、シンプルにコードが書けたり、とにかく気が利いています。
CasperJSもJQueryライクに要素がとれて便利ですが、メソッドを揃えるような工夫はあまりないです。
あと、JavaScript全般に言えることですが、入れ子が多くなって私は嫌いです。
Selenium(Java)は、とにかく長たらしく書かなければならないので面倒です。

Selenium:☓
Geb:○
CasperJS:△

環境整備の容易さ

Seleniumを普通とすると、Gebは少し面倒でした。
groovyとspockのバージョンの整合性ではまったり。。。

比較ということでGebを☓にしましたが、SeleniumとGebはそんなに変わらなく、CasperJSが圧倒的に簡単です。
コマンド一発で環境整備できちゃいます。
(「WEB+DB PRESS vol.80」がとてもわかり易いです。)

Selenium:△
Geb:☓
CasperJS:○

クロスブラウザ

CasperJSはPhantomJSで動かすものなので、そもそもクロスブラウザという概念がありません。
SeleniumとGebはクロスブラウザ対応しています。

Selenium:○
Geb:○
CasperJS:☓

コード

GebとCasperJSは私が書いたので、あまりキレイではないかもしれませんが、コードを比較してみてみるとおもしろいです。

Selenium

STARリポジトリ のanswer参照。

Geb


CasperJS

https://github.com/itagakishintaro/STARHandsOnCasperJS