MACでMercurial

Mercurial テスト

WindowsでMercurialを使う方法はこちらにまとめてあります。
ここでは、MACでMercurialを使う手順と、はまった点をログに残しておきます。

Homebrewのインストール

よく使われているパッケージ管理を調べたらこれだった。まずは使ってみる。

homebrewのwikiへ行く

https://github.com/mxcl/homebrew/wiki/installation

コマンドを調べる

Installation欄にある以下のコマンドをコピーして、ターミナルから実行。

$ /usr/bin/ruby -e "$(/usr/bin/curl -fsSL https://raw.github.com/mxcl/homebrew/master/Library/Contributions/install_homebrew.rb)"

「Installation successful!」と表示されれば成功。

gitのインストールでエラー

homebrewを更新できるようにgitを入れておく。

$ brew install git

なんかエラーになる。brew doctorを試せと言っている。

Error: Failed executing: ./configure --disable-debug --prefix=/usr/local/Cellar/pkg-config/0.25 --with-pc-path=/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/pkgconfig:/usr/X11/lib/pkgconfig (pkg-config.rb:23)
If `brew doctor' does not help diagnose the issue, please report the bug:
    https://github.com/mxcl/homebrew/wiki/reporting-bugs
We saved the configure log, please gist it if you report the issue:
    ~/Library/Logs/Homebrew/config.log

brew doctorを実行してみると、どうやらXcodeにCommand Line Tools がセットされていないと言っています。

Error: You have no /usr/bin/cc.
This means you probably can't build *anything*. You need to install the Command Line Tools for Xcode. You can either download this from http://connect.apple.com or install them from inside Xcode's Download preferences. Homebrew does not
require all of Xcode! You only need the Command Line Tools package!
Error: Git could not be found in your PATH.
Homebrew uses Git for several internal functions, and some formulae use Git
checkouts instead of stable tarballs. You may want to install Git:

そもそもXcodeも入っていなかったので、Xcodeのインストールをする。

Xcodeのインストール

  • iOS Dev CenterでAppleDeveloppterの登録
  • 登録が完了したら、XCodeをダウンロード。Xcode 4.3.3 for lion
  • インストールが完了したら、Xcode→Preferences→Downloads→Command Line Tools→install

git他のインストール

以下を実行する。

$ brew install git
$ brew install python

日本語化

brewでインストールしてからhgコマンドを実行してみると、日本語になっていない
場合がある。以下のいずれかの方法で有効にできる。

本家からバイナリをゲットしてインストール

以下からバイナリをダウンロール。
Mercurial SCM
ファイルをダブルクリックするとインストーラーが起動。言われた通り続ければ完了。
インストール直後から、hgコマンドの結果が日本語になる。

必要ライブラリのインストール

参考サイト：Mac OS X 開発環境構築手順：Mercurialドキュメントの日本語化 - Shinya’s Daily Report

$ brew install gettext
$ brew link gettext
$ brew uninstall mercurial
$ brew install mercurial

以上

How Google Tests Software - Part Threeを訳してみた

テスト

How Google Tests Software - Part Three
Wednesday, February 16, 2011 2:47 AM

By James Whittaker

Lots of questions in the comments to the last two posts. I am not ignoring them. Hopefully many of them will be answered here and in following posts. I am just getting started on this topic.

Google Testing Blog: How Google Tests Software - Part Three

（略）

At Google, quality is not equal to test. Yes I am sure that is true elsewhere too. “Quality cannot be tested in” is so cliché it has to be true. From automobiles to software if it isn’t built right in the first place then it is never going to be right. Ask any car company that has ever had to do a mass recall how expensive it is to bolt on quality after-the-fact.

Googleでは、品質はテストとイコールではない。それは、他のどこへいっても同じはずだ。“品質はテストに依るべきではない”は古い決まり文句だが、今でもそうであるべきだ。自動車からソフトウェアまで、もし最初に間違って組み立ててしまえば、もう正しい形になることはないだろう。事後に品質を組み込むことがどれだけ高くつくかは、過去大量のリコールを出したことのある自動車会社に聞いてみるといいだろう。

However, this is neither as simple nor as accurate as it sounds. While it is true that quality cannot be tested in, it is equally evident that without testing it is impossible to develop anything of quality. How does one decide if what you built is high quality without testing it?

けれども、これはそんな単純なものでもないし、そのまま適用できるものでもない。品質はテストに依るものではない、というのは正しいが、テストすることなしに品質を作りこむことはできないということも同様に明らかでだろう。あなたが作ったものは高品質であると、誰がテストせずに言い切れるでしょうか？

The simple solution to this conundrum is to stop treating development and test as separate disciplines. Testing and development go hand in hand. Code a little and test what you built. Then code some more and test some more. Better yet, plan the tests while you code or even before. Test isn’t a separate practice, it’s part and parcel of the development process itself. Quality is not equal to test; it is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other.

この難問に対するシンプルな解決策は、開発とテストを別々の分野として扱うことをやめることです。テストと開発が手をつないで行く。少しコーディングしたら、少しテストする。もう少しコードを書いたら、もう少しテストする。いっそのこと、コードを書きながらか、または書く前にテストを計画してしまいます。テストはプラクティスから分離したものではなく、開発プロセスの一部なのです。品質は、テストをすることではない、これは、開発とテストをミキサーにかけて、区別がつかないまで混ぜ込むことで、ようやく達成できます。

At Google this is exactly our goal: to merge development and testing so that you cannot do one without the other. Build a little and then test it. Build some more and test some more. The key here is who is doing the testing. Since the number of actual dedicated testers at Google is so disproportionately low, the only possible answer has to be the developer. Who better to do all that testing than the people doing the actual coding? Who better to find the bug than the person who wrote it? Who is more incentivized to avoid writing the bug in the first place? The reason Google can get by with so few dedicated testers is because developers own quality. In fact, teams that insist on having a large testing presence are generally assumed to be doing something wrong. Having too large a test team is a very strong sign that the code/test mix is out of balance. Adding more testers is not going to solve anything.

開発とテストが、お互いがなきゃならない状態になるまで融合すること。それはまさにGoogleにおけるゴールです。少し作って、すぐテストする。もう少し作って、またテストする。ここでのポイントは、誰がテストするか、です。Googleでは、純粋なテスターの人数は、不釣り合いなほど少ない。だから、唯一の選択肢は、開発者がテスターになることです。コードを書いた本人よりも良いテストを誰ができるかい？誰がコードを書いたやつよりもバグを見つけられるかい？バグを入れ込むことを防ぐのに、もっともいい位置にいるのは誰だい？Googleが少ないテスターでやっていけているのは、開発者自身の品質によります。もっと言えば、大規模なテストチームの存在を主張する場合は、大抵は何か間違ったことをしているでしょう。大規模なテストチームの存在自体が、コードとテストのバランスが崩れているという、とても大きなサインです。テスターを投入しても、何も解決しないのです。

This means that quality is more an act of prevention than it is detection. Quality is a development issue, not a testing issue. To the extent that we are able to embed testing practice inside development, we have created a process that is hyper incremental where mistakes can be rolled back if any one increment turns out to be too buggy. We’ve not only prevented a lot of customer issues, we have greatly reduced the number of testers necessary to ensure the absence of recall-class bugs. At Google, testing is aimed at determining how well this prevention method is working. TEs are constantly on the lookout for evidence that the SWE-SET combination of bug writers/preventers are screwed toward the latter and TEs raise alarms when that process seems out of whack.

これは、品質とは、検出よりも予防行為によってより保たれることを示している。開発にテストのプラクティスを持ち込める範囲においては、我々は、ハイパーインクリメンタルプロセスを作りました。そこでは、あるイテレーションの成果物が超buggyであった場合に、ロールバックすることができます。我々は、顧客の問題を避けるためだけをやっているわけではないので、リコールクラスのバグがないことだけを保証するようなテスターをかなり減らしてきた。Googleにおいては、テストの目的は、予防機能がちゃんと機能しているかを測ることへ向かっています。TEチームは、バグの埋め込み・予防のSWE-SETコンビネーションが、予防に向かってねじ込まれているか常に目を光らせて、プロセスの調子が悪そうならアラームを上げています。

Manifestations of this blending of development and testing are all over the place from code review notes asking ‘where are your tests?’ to posters in the bathrooms reminding developers about best testing practices, our infamous Testing On The Toilet guides. Testing must be an unavoidable aspect of development and the marriage of development and testing is where quality is achieved. SWEs are testers, SETs are testers and TEs are testers.

「where are your tests?」この開発とテストのブレンドというマニュフェストは、コードレビューのノートからトイレのポスターへ超えて、開発者に最適なテストプラクティスをリマインドしてくれる。私たちの忌まわしき「Testing On The Toilet guides」テストは開発の避けられない側面であり、開発との結婚でなければならず、そしてテストは品質が実現される場です。SWEはテスターであり、SETも、TEもはテスターなのです。

If your organization is also doing this blending, please share your successes and challenges with the rest of us. If not, then here is a change you can help your organization make: get developers fully vested in the quality equation. You know the old saying that chickens are happy to contribute to a bacon and egg breakfast but the pig is fully committed? Well, it's true...go oink at one of your developer and see if they oink back. If they start clucking, you have a problem.

あたなの組織が、すでにこのブレンドを実現しているなら、その成功と、私たちの残りの課題を共有させてください。もしそうでなくても、これは分岐点です。絶対的な品質の教育を受けた開発者を取得できるような・・・組織へとあなたが手助けできるはずです。
こんな古い話がありますね。「鶏たちは朝食のベーコン＆エッグに喜んで卵を提供するだろうけど、はたして豚は納得するだろうか？」確かに、そうですね。あなたの開発者の一人にブーブー言ってみて、ブーブー返ってくるかやってみてください。もし彼らが鳴きはじめたら、何か問題があるのかもしれません。

64ビットのWindowsOS上でNUnitがテストプロジェクトをロードできない

UT

NUnitでテストプロジェクトをロードすると、以下のようなエラーになることがあります。

Test load failed!
You may be attempting to load an assembly built with a later
version of the CLR than
the version under which NUnit is currently running (2.0.50727) or
trying to load a 64-bit assembly into a 32-bit process.

System.BadImageFormatException : ファイルまたはアセンブリ
'YourTests, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null'、またはその依存関係の1つが読み込めません
でした。間違ったフォーマットのプログラムを読み込もうとしまし
た。

For further information, use the Exception Details menu item.

再現条件

これは以下の条件で発生します。

  • PCが64ビットOS
  • VisualStudioで、プラットフォームターゲットをx86にしてビルドしている
  • スタートメニューから「NUnit」を選んで起動している。

問題の状況

64ビット環境にNUnitをインストールした場合、スタートメニューの「NUnit」は64ビット版のnunit.exeを起動するようになっています。
その後、テストプロジェクトをロードしようとすると、dllがx86でビルドされていると、アセンブリのロードに失敗してエラーになっている、という状態です。

解決方法

実は、NUnitのインストール先フォルダーには、32ビット版のNUnitが入っています。そちらを起動すれば問題なくテストプロジェクトをロードできます。

C:\Program Files (x86)\NUnit 2.6\bin\nunit-x86.exe

ちなみにこの例外は、参照している.NET Frameworkのバージョンが異なるアセンブリーをロードした時や、32ビット←→64ビットで参照しようとしたときに良く見るので、そんな時はプロジェクトのプラットフォームターゲットや参照先のDLLのプラットフォームターゲットを確認すると、だいたい解決します。

以上

WindowsでMercurial

Mercurial

MercurialをWindows上で使う場合の手順をざっくりとまとめました。

全体の手順は以下のような流れです。大体１時間ぐらいかかります。

  1. bitbucketアカウントを取得
  2. リポジトリ作成
  3. SSHの設定
  4. Mercurialクライアントのインストール
  5. 環境設定
  6. リポジトリのダウンロード
  7. リポジトリへファイルの追加
  8. コミット
  9. リポジトリへ変更の反映

1．bitbucketアカウントを取得

「bitbucket」はMercurialのリポジトリをフリーで使わせてくれるサービスです。ひとつのリポジトリに対して５人以内なら無料で使えるそうで、練習なら十分すぎるほど使えます。
Free source code hosting — Bitbucket
上記ページを開き、「SIGN UP NOW, FREE」ボタンを押すと、個人情報入力画面が表示されるので、登録します。
登録が完了すると、自分のポータルのページが表示されたはずです。

2．リポジトリ作成

bitbucket上に新しいリポジトリを作成します。
「Repositories」→「Create Repository」
表示された画面で、Name欄にリポジトリ名、それ以外も適当に入力して「Create Repository」押下で実行すると、Overviewページへ移動します。

3．SSHの設定

PuTTYのダウンロード

まず、以下からzipかmsiをダウンロードします。
PuTTY Download Page　（2012/6/19現在の最新はver0.62）

SSHキーの準備

適当な場所に展開またはインストールしたら、まずはキーを作成するために「puttygen.exe」を起動します。
「Generate」ボタンを押し、上のエリアでマウスをグリグリ動かすと「Public key for pasting into OpenSSH authorized_key file:」欄にOpenSSHの公開鍵が表示されますのでコピーします。ついでにパスフェーズを入力して「Save private key」押下で秘密鍵をローカルに保存しておきます。

ローカルのSSHキーの設定

「pageant.exe」を起動します。タスクトレイのアイコンをダブルクリックし、「Pageant Key List」を開いてから「Add Key」を押下し、秘密鍵のファイルを選びます。

サーバーのSSHキーの設定

bitbucketを開き、ユーザーのメニューから「Account」→「SSH keys」と選びます。
LabelはそのPCの名前など、SSH Keyは、上でコピーした文字列をペーストし、「Add key」で追加します。

4．Mercurialクライアントのインストール

TortoiseHgという、Mercurialの機能＋GUI＋Explorer拡張という便利なフリーソフトがあるので、それを入れます。以下から環境にあったセットアップをダウンロードします。
Mercurial SCM　（2012/6/19現在の最新はver2.2.2）
言われるままインストールしていけば完了します。GUIでも色々できそうですが覚えるのが大変そうなので、以下はCUIベースで説明します。

5．環境設定

コレをしないと動きません。「mercurial.ini」という名前の設定ファイルを、ユーザーのフォルダ直下に入れます。

c:\Users\suzuki\mercurial.ini

このファイルには以下のような設定を入れておきます。

[ui]
username=Taro Suzuki <taro.suzuki@abc.com>
[extensions]
graphlog=

前半はユーザー名の設定です。名前とメールアドレスの間は半角スペース１文字が必要だそうです。後半はログを「hg glog」でグラフィカルに見たい場合に入れておきます。

次に日本語化。コントロールパネル→システムとセキュリティ→システム→「システムの詳細設定」で「システムのプロパティ」ダイアログを開く。「環境変数」ボタン押下し、システムの環境変数欄の「新規」ボタンを押下。
名前を「LANG」、値を「ja_JP」と入力し、OSを再起動する。

6．リポジトリのダウンロード

ようやく準備が整いました。早速、bitbucketに作ったリポジトリをローカルに落としてきてみましょう。
まず、bitbucketで先ほど作ったリポジトリ画面を開きます。Overviewのタブの中に、「Clone this repository」とあってその下にcloneのコマンドが表示されているので、コピーします。

$ hg clone ssh://hg@bitbucket.org/taro.suzuki/myrepository

コマンドプロンプトを開き、このリポジトリをダウンロードしたいフォルダへ移動してから、closeコマンドを実行します。

$ cd \users\suzuki\documents\
$ hg clone ssh://hg@bitbucket.org/suzuki/myrepository

色々表示されて完了したら、ローカルのdocumentsフォルダを開いてみます。myrepositoryというフォルダーができているはずです。さらに、「.hg」というフォルダーが見えます。このフォルダーにはリポジトリの接続先や履歴情報が格納されており、ルートに一つだけ存在します。このフォルダーを削除すると、連動が切れた状態に戻ります。よって消してはいけません。
このcloneやpullの作業は、VSSやTFSのチェックアウトの操作を表しています。そのためこのフォルダー以下への編集は、すべて差分として認識されます。

7．リポジトリへファイルの追加

管理対象への追加は自動ではやってくれないので、自分で追加してやります。
まず、エクスプローラー等でファイルを追加し、ローカルリポジトリのあるフォルダーへ移動してから、addコマンドで管理対象へ追加します。

$ cd \users\suzuki\documents\myrepository
$ hg add

これだけです。

8．コミット

Mercurialでは、追加・編集・削除・マージのたびにコミットしなければならなりません。コマンドは以下。これで、それまでの変更がローカルのリポジトリにコミットされます。

$ hg commit

これだけです。

9．リポジトリへ変更の反映

コミットはローカルのリポジトリへ変更が反映されただけです。bitbucket上のメインの（セントラルの）リポジトリへ変更を反映するには「push」します。

$ hg push

これだけです。

bitbucketの「Repository」で「Source」のタブを見てみると、ファイルが追加されているはずです。

以上で完了です。次回はVisual Studioのプロジェクトをリポジトリへ追加してみます。

SCM Boot Camp in Hokkaido

勉強会 Mercurial

先日「6月17日 SCM Boot Camp in Hokkaido(北海道)」というすばらしい勉強会に参加してきました。

今回、周りはMacばかりでWindowsは私だけ、というつらい状況だったもので、最初の設定で結構苦労した。。。忘れないうちに、MercurialをWindows上で使う場合の手順をざっくりとまとめておこうと思う。

勉強会の内容はまた別でまとめようかな。