Eclipse EGit でのリベースのやりかた

Gitで便利な機能の1つ、リベース。
リベースの機能や動作自体については、各所で解説されているのでここでは説明しません。

便利なリベースですが、普段 Eclipse を用いて開発を行い、EGit プラグインのお世話になっていますから、リベースもぜひ EGit でやりたいでしょう。

しかし、EGit上でのリベース手順の情報が少なく、迷うことがあるでしょう。
ということで、今回は、Eclipse プラグイン EGit を用いてリベースを行う手順について説明します。

まず、リベースを行いたいブランチをチェックアウトします。

リベースを始める前に、ヒストリーを出しておくといいでしょう。
「プロジェクトのルートディレクトリを 右クリック → チーム → ヒストリーに表示」で出しておきます。

それではリベースを開始しましょう。
「プロジェクトのルートディレクトリを 右クリック → チーム → リベース...」と選択します。

リベースをどのブランチの上に行うか選択するダイアログが表示されます。

任意のブランチを選択し、「リベース」をクリックします。


リベースが始まります。表示させておいたヒストリーを見ると、リベースが行われる様子が表示されるので面白いです。

途中、リベースで適用される差分とそのコミットでの差分が衝突すると、ダイアログが表示されます。

そのままマージを開始するので「Start Merge Tool to resolve conflicts」が選択されているのを確認し「OK」をクリックします。

するとマージ方法を聞かれます。

ここでは「Use the workspace version of conflicting files」の方を選択しておきます。

マージ・ツールが起動します。
マージ・ツールではリベース前のコミットに記録されているファイルが右側、リベース対象のマージ中のファイルが左側に表示されるの出ます。左側を編集して、意図する形にします。（右側はそもそも編集不可になっています）

衝突を起こしているファイルは赤い両矢印のマークが表示されるので、それらのファイルを全て正しく編集することになります。衝突箇所が<<<<<<<,=======,>>>>>>>で区切られているのはGitコマンドラインツールと同じで、そのあたりはGit本家の解説をご参照ください。

衝突を解決しているときに、HEADと比べてみると参考になります。マージ・ツールではリベース前のコミットのファイルが表示されますが、衝突解決中のHEADはリベースが適用できた最後のコミットのファイルになっているので、比較することで衝突解決後の（リベースされたブランチ上での）変化がわかるからです。

衝突を解決できたと思った時点で、そのファイルについて「ファイルを右クリック → チーム → 比較 → HEAD」と選択して比較してみましょう。

さて、衝突を解決できたらそのファイルを Add します。Add すると、赤い両矢印の衝突マークが消えて、アスタリスクのステージングマークが表示されます。

全てのファイルの衝突を解決し Add  し終わったら、プロジェクトのルートディレクトリに表示されていた赤い両矢印の衝突マークが消えて、アスタリスクのステージングマークが表示されるでしょう。

その状態になったら、「プロジェクトのルートディレクトリを 右クリック → チーム → リベース → Continue Rebase」を選択します。

これでリベース処理が再開されます。

衝突が起きるたびに上記手順を繰り返し、最後に完了メッセージが表示されれば、リベースは完了です。

[改造版] jQueryのiPod風メニュープラグイン『jQuery iPod-style Drilldown Menu』をちょっと改造

jQueryを利用したメニューを実現するプラグインで、
iPod風に深い階層をスライドして表現するプラグインがあります。
『jQuery iPod-style Drilldown Menu』 http://filamentgroup.com/lab/jquery_ipod_style_and_flyout_menus/ 

結構有名なプラグインのようで、「jQuery menu ipod」あたりで検索すると
多くの紹介ページがヒットします。 

しかしながら、実際に利用しようとした際にバグがあったり、
手を入れたいと思った部分がありました。
そこで、バグ修正および若干の機能追加を行ったものを作成しました。
変更点は以下の通りです。

• サブメニュー項目数が親メニューより多い場合に、Backボタンの表示が崩れるのを修正
  (本家ページのDenis Shaposhnikov氏のコメントより)
• 速いスピードでメニューを開閉すると、表示が崩れることがあるのを修正
  (本家ページのtim氏のコメントより)
• ウィンドウサイズを変更した際、メニューの位置がずれるのを修正
• 初期化時のcontentオプションにjQeuryオブジェクトを指定できるようにした
• メニュー内のボタン以外の部分をクリックした際、メニューが閉じないようにした
• オプションの"backLinkText"がパンくずリストを使用しない時に反映されなかったのを修正

初期化時のcontentオプションにjQueryオブジェクトを指定できるようにした理由は、
メニュー内部の要素にイベントを設定していた場合、元コードではメニューはcontentオプションに指定した要素内のHTMLをコピーして作成しており、イベントはコピーされず意図した動作にならない可能性があるためです。
contentオプションにjQueryオブジェクトを指定することにより、イベントを維持したままメニューを構成できます。

メニュー内のボタン以外の部分をクリックした際、メニューが閉じないようにした理由は、
例えばラジオボタンや入力欄などのinput要素をメニュー内に設置した時に、クリックした瞬間にメニューが閉じられては困るからです。

※Bloggerの仕様変更なのか、この投稿内でのサンプルは動かなくなったので削除しました。

ダウンロードはGitHubに本家からforkしたものがあるのでそちらからどうそ。
https://github.com/takaaki-kasai/jQuery-Menu

Eclipse PDT でコメント切り替えショートカットキーが効かなくなるのを直す

Eclipse 4.2 Juno にアップデートしたら、Ctrl+/によるコメントアウトの切り替えが動作しなくなることがありました。

どうやら、エディタを複数開くと2つ目以降でCtrl+/が効かなくなるものがあるようです。
調べるうちに、同じ現象での相談がフォーラムに投稿されているのを見つけました。

http://www.eclipse.org/forums/index.php/m/894630/

解決方法はPDTプラグインの中身を直接いじるというもの。jarファイルを展開、編集して再度アーカイブするように書いてあります。

展開後再アーカイブする方法を試してみましたがエラーが出るなどうまくいきませんでした。しかし、再アーカイブではなくアーカイブ中の対象ファイルのみを更新する方法でうまくいきましたのでその方法を書きます。

jar を展開する

まず、編集対象のファイルを取り出すため、対象のjarファイルを展開します。
Eclipse Pleiades All in Oneでは、

eclipse\dropins\PDT\eclipse\plugins\org.eclipse.php.ui_3.0.1.v201201110400.jar

にありました。 元のjarをバックアップした後、一時フォルダにコピーします。

その後コマンドプロンプトを起動し、一時フォルダに移動してjarを展開します。

> jar xvf org.eclipse.php.ui_3.0.1.v201201110400.jar

plugin.xmlを書き換える

展開されたファイルのうち、plugin.xmlを書き換えます。書き換える箇所は612行目付近の次の箇所です。

書き換え前：

<!-- overriding WST's Handlers with the same 'commanId' -->
<handler class="org.eclipse.php.internal.ui.actions.PHPToggleLineCommentHandler"
    commandId="org.eclipse.wst.sse.ui.toggle.comment">
    <activeWhen>
    <or>
        <reference definitionId="org.eclipse.php.ui.phpContentType.definition" />
       <with variable="activePartId">
        <equals value="org.eclipse.php.editor"/>
       </with>
    </or>
        
    </activeWhen>
    <enabledWhen>
        <reference definitionId="org.eclipse.php.ui.phpContentType.definition" />
    </enabledWhen>
</handler>

書き換え後：

<!-- overriding WST's Handlers with the same 'commanId' -->
<handler class="org.eclipse.php.internal.ui.actions.PHPToggleLineCommentHandler"
    commandId="org.eclipse.wst.sse.ui.toggle.comment">
    <activeWhen>
        <reference definitionId="org.eclipse.php.ui.phpContentType.definition" />
    </activeWhen>
    <enabledWhen>
        <reference definitionId="org.eclipse.php.ui.phpContentType.definition" />
    </enabledWhen>
</handler>

jarを更新

書き換えたplugin.xmlをjarに注入して更新します。

> jar -uf org.eclipse.php.ui_3.0.1.v201201110400.jar plugin.xml

更新したjarで元ファイルを上書きし、eclipseを-cleanオプション付きで起動します。
これでエディタを複数起動した時も2つ目以降でCtrl+/が効くようになります。

Eclipse Pleiades All in One PHP 版でタスク一覧から特定のフォルダを除外する

Eclipse Pleiades All in One PHP 版でタスク一覧から特定のフォルダを除外する方法です。
（確認したバージョンはEclipse 4.2 Juno）

1. まず公式の「Eclipse Web 開発者ツール(Web Developer Tools)」をインストール
   メニューの「ヘルプ→新規ソフトウェアのインストール...」を選び、Eclipseのリリースサイトからインストールします。
2. プロジェクトのプロパティーに「検証」が出現
   PHPエクスプローラでプロジェクトのルートディレクトリを右クリック→プロパティ
3. 「検証」のバリデーター一覧のうち、PHPTaskValidatorの設定で除外したいフォルダを指定する。
   「プロジェクト固有の設定を可能にする」チェックボックスをオンにし、 PHPTaskValidatorの設定ボタンをクリックします。
   出てきたダイアログで「除外グループの追加..」ボタンをクリックし、追加された除外グループを選択して「ルールの追加...」をクリックします。
   ダイアログの指示に従い除外したいフォルダを指定します。

これでタスク一覧から指定したフォルダが除外されます。「Eclipse Web 開発者ツール」を入れないとプロジェクトのプロパティーに「検証」メニューが出てこないので注意してください。

Symfonyを使った開発で機能テストはlimeかSeleniumか

Webアプリの開発をテスト駆動で行おうとするとき、機能テストを自動化するためのテスティングフレームワークの選択は重要であると思います。

lime vs. Selenium

機能テストの自動化にSymfony付属のlimeとSeleniumのどっちを使うか、と思ってたら同じ事考えてる人がいました。

http://stackoverflow.com/questions/2777913/selenium-vs-phpunit-lime

上記リンク先では用途によって使い分けるべし、という論調でたしかにその通りなのですけれど、問題は「機能テスト目的としては両方とも使えてしまう」ことです。たしかにlimeでしかできないこと・Seleniumでしかできないことはあります。しかし機能テストのほとんどの部分はどちらでもできてしまうことなので、やっぱり選択は迷うことになります。

自分の結論：lime

で、ともかく自分でやってみようということで両方使ってみました。

結果、現在のところ自分はlimeのみ使っています。その理由は、

• 速い
• テストが書きやすい

です。

まず実行速度は当然といえば当然ですが圧倒的にlimeの方が速いです。これはテスト駆動開発を行う上で何度もテストを実行する必要が有ることを考えると、開発効率にかなりの影響を与えます。Seleniumではブラウザで実際にアクセスするのでどうしても時間がかかります。

また、テストファーストで開発を進めるのに、limeならPHPですから条件分岐やループなどの制御構造をテストに組み込むのも全く難なく出来ます。Seleniumでは制御構造をテストに組み込むにはプラグインを導入する必要があったり、書き方もHTMLを使った独特の文法ですので若干テストが書きづらいです。（PHPUnitと連携できるみたいですが環境構築が大変。やろうとして途中でやめました。）

Javascriptのテストはどうする？

ちなみにJavascirptの単体テストにはqUnitを使っています。limeによるテストではJavascirptの機能は反映されませんので、Javascriptに依存する機能は別途qUnitでテストを行うことになります。

逆に言うとlimeによるテストがJavascirptなしでも可能になるようにコードを書く必要があります。

現状、lime+qUnitという構成で自動テストの環境はほぼ十分です。最後はブラウザから操作して確認することが必要ですが、これは自動テストに抜け漏れがなかったかを意識するとよいと思います。

同じ点を複数回通れる場合の「パターンロック」のパターン数

Androidなどに採用されていてる、並んだ点同士を指でなぞって結ぶことにより、パスワードの代わりとする認証方法があります。正式名称は知らないのですが、とりあえずここでは「パターンロック」と呼ばせていただくことにします。

Androidのパターン数については既に計算している方がいます。
http://blog.goo.ne.jp/nihongi/e/d0cfde12d440b92c181b6afd2b7dc4cb
http://beust.com/weblog2/archives/000497.html

Androidでは一度通った点は再度通れないことになっています（上を通過するのはOK）。しかし、独自に認証を搭載したアプリで、同じ点を何回でも通れるようなパターンを設定できるものがありました。これのパターン数を知りたいという方がいましたので、数えてみました。
条件は、

• 隣接する上下・左右・斜め方向の動きで点を結べる
• 将棋の「桂馬」の動きのような結び方はなし
• 一度通った点も再度通れる
• 使える点は3x3の9個

です。

3x3の点で同じ点を複数回通れる場合の「パターンロック」のパターン数

結ぶ点の数	パターン数
1	9
2	40
3	200
4	952
5	4624
6	22272
7	107648
8	519552
9	2509056
10	12113920
11	58492928
12	282425344

結ぶ点の数が12個までを計算しましたが、同じ点を複数回通れるので結ぶ点の数はいくらでも増やせます。

Androidで一度通った点は再度通れないようにしているのは、UI上で通った点の軌跡を表示する都合上、同じ軌跡を2度描けないからだと思います。

私が見たアプリではUI上で通った点の軌跡を表示せず、通り方そのものを覚える方式であるため、複数回同じ軌跡を描くような通り方も設定可能になっていました。

たしかにUI上で軌跡を表示すればグラフィカルに記憶できますが、制限を外して自由にパターンを書けるようにしたほうがかえって覚えやすい場合もありますので一長一短ですね。

参考：Rubyによるプログラムのソース

以下に3x3の点がある場合のパターン数を計算するRubyスクリプトを示します。 実行時の引数に結ぶ点の数を指定するとパターン数を出力します。

#!/bin/ruby
# assume dots such as:
# a b c
# d e f
# g h i

class PatternLock
  def initialize
    @dots = {
      'a' => ['b', 'd' ,'e'],
      'b' => ['a', 'c' ,'d', 'e' ,'f'],
      'c' => ['b', 'e' ,'f'],
      'd' => ['a', 'b' ,'e', 'g' ,'h'],
      'e' => ['a', 'b' ,'c', 'd' ,'f', 'g' ,'h' ,'i'],
      'f' => ['b', 'c' ,'e', 'h' ,'i'],
      'g' => ['d', 'e' ,'h'],
      'h' => ['d', 'e' ,'f', 'g' ,'i'],
      'i' => ['e', 'f' ,'h'],
    }
  end

  protected
  def countPattern(level, dot)
    if (level <= 1) then
      return 1;
    else
      count = 0
      @dots[dot].each do |x|
        count += self.countPattern(level - 1, x)
      end
      return count
    end
  end

  public
  def getCount(length)
    count = 0
    @dots.each do |k, v|
      count += countPattern(length, k)
    end
    return count
  end
end

pl = PatternLock.new
puts pl.getCount(ARGV[0].to_i)

PatternLockクラスのインスタンス変数@dotsは、パターンに使える点をキーとし、次に結べる点の集合の配列を値に持つ連想配列です。上記例では各点にアルファベット1文字を割り当てています。@dotsを変更することで点の数が異なる場合や将棋の桂馬の動きを許可する場合なども計算できます。

yumでCentOSのバージョンをダウングレードする(6.3=>6.2)

yum update でOSごとアップデートしてしまった時、元に戻したい時はどうすればいいか試してみました。
検証用に以下のCentOS6.2のVMware用イメージを使わせて頂きました。
http://www.thoughtpolice.co.uk/vmware/#centos6.2
これをyum updateで6.3 にアップデートした状態。ここから6.2に戻してみます。

まずリポジトリの参照先を戻したいバージョンに強制します。
（参考 → http://d.hatena.ne.jp/stakizawa/20100522/t1）

# cd /etc/yum.repos.d
# cp CentOS-Base.repo CentOS-Base.repo.orig
# vim CentOS-Base.repo
:%s/$releasever/6.2/g
:wq
# yum clean all

で、yum distribution-synchronization を実行。このコマンドはリポジトリ上の全てのパッケージをまとめてインストールあるいは更新し、バージョンもリポジトリと同じになるように試みます。例えばすでにインストールされているバージョンよりリポジトリ上のバージョンが古い場合はダウングレードを行います。

# yum distribution-synchronization

これですんなり成功してくれればいいですが、エラーが出ました。

Transaction Check Error:
file /usr/lib/python2.6/site-packages/system_config_keyboard/__init__.pyc from install of system-config-keyboard-1.3.1-3.el6.x86_64 conflicts with file from package system-config-keyboard-base-1.3.1-4.el6.x86_64
file /usr/lib/python2.6/site-packages/system_config_keyboard/__init__.pyo from install of system-config-keyboard-1.3.1-3.el6.x86_64 conflicts with file from package system-config-keyboard-base-1.3.1-4.el6.x86_64
file /usr/lib/python2.6/site-packages/system_config_keyboard/keyboard.pyc from install of system-config-keyboard-1.3.1-3.el6.x86_64 conflicts with file from package system-config-keyboard-base-1.3.1-4.el6.x86_64
file /usr/lib/python2.6/site-packages/system_config_keyboard/keyboard.pyo from install of system-config-keyboard-1.3.1-3.el6.x86_64 conflicts with file from package system-config-keyboard-base-1.3.1-4.el6.x86_64
file /usr/lib/python2.6/site-packages/system_config_keyboard/keyboard_models.pyc from install of system-config-keyboard-1.3.1-3.el6.x86_64 conflicts with file from package system-config-keyboard-base-1.3.1-4.el6.x86_64
file /usr/lib/python2.6/site-packages/system_config_keyboard/keyboard_models.pyo from install of system-config-keyboard-1.3.1-3.el6.x86_64 conflicts with file from package system-config-keyboard-base-1.3.1-4.el6.x86_64

エラーの発生したパッケージを削除し、作業後に依存パッケージとともに再インストールすることにします。

# yum remove system-config-keyboard

依存性のため一緒に削除されるパッケージがあるのでメモしておきます（この場合anacondaとfirstbootが一緒に削除された）

再度トライ
# yum distribution-synchronization
今度は成功。

先ほど削除したパッケージをインストールします。
# yum install system-config-keyboard anaconda firstboot

古い情報が残っていて再インストールに失敗しました。rpmコマンドで直接対象のパッケージをアンインストールします。
# rpm -e system-config-keyboard-base-1.3.1-4.el6.x86_64
再度トライ。
yum install system-config-keyboard anaconda firstboot
これでOK。

カーネルの新しいバージョンのパッケージが残っているのでyumコマンド実行時に依存パッケージ欠如で怒られますが、ダウングレードしたバージョンで起動するので特に気にならないのであればこのままでも問題ないでしょう。気になるようなら削除すればいいと思います。

クライアントサイドJavascript UIの「擬似」テスト駆動開発

Web アプリケーションのテスト駆動開発において、クライアントサイドJavascript による UI の開発は最もテスト駆動にすることが難しい部分の1つだと思います。今回は、クライアントサイドJavascript による UI の開発において、テスト駆動開発のメリットを採り入れるにはどうするか、試行錯誤しつつ今こうやっていますよ、という方法を書こうと思います。

UIのテストは間接的に行う

そもそも UI のテスト駆動開発は難しいと言われています。数値や文字列が出力結果となるような他のプログラムと違って、UI はグラフィカルな変化が出力結果となるため、自動化テストにおけるアサーションを書きにくいからです。

といっても、確認する方法がないわけではありません。クライアントサイドJavascriptにおいて、画面上の位置、背景の色、幅、高さ、透明度など、見た目を構成する要素の多くはCSSプロパティとして取得可能です。

直接見た目が正しいかを確認できなくても、これらCSSプロパティを通じて間接的に確認することができます。自動化テストのアサーションもCSSプロパティの値を対象に行えばよいでしょう。

また、クラスを付与・削除することによってCSSの適用範囲を変えて視覚的効果を実現する場合もあります。その場合はクラスの存在の有無を確認すればよいでしょう。

ではそれでテスト駆動で開発がスタートできるかというと、そうは問屋が卸しません。

外部ライブラリがJavascriptのテスト駆動開発を困難にする

Javascript のテスト駆動開発を困難にしているもう1つの原因は外部ライブラリです。 時間と労力の節約のため、先人の知恵を用いるのは有効な方法です。jQueryやその上で動くプラグイン等を始めとして先人の知恵の結晶であるライブラリが数多く存在します。しかしながら、テスト駆動開発においては「得られる結果を先に決める」ことが重要になるため、外部ライブラリはその点で不利です。

UI 上で、ある効果を実現したいと思った時、採用することにした外部ライブラリがどのCSSプロパティの値をどう変化させるのかコーディング前に正確に把握することは一般的に困難です。ライブラリのAPIドキュメントを読んでもわからない場合が多いです。この状態ではテストを先に書くことができません。テストファーストで開発を進める最初の1歩が難しいのです。

「擬似」テスト駆動開発による解決策

そこで、本来のテスト駆動開発の流儀からは外れますが、まず目的の効果を部分的に得られる段階まで、テスト無しで実装を行なってしまいます。 これを「試験的な実装」と呼ぶことにします。

そして、試験的な実装がどのようにCSSプロパティやクラスを変化させるか分かったら、それらの変化を自動化テストのアサーションとして記述します。ここで書くテストは、試験的な実装を全てカバーするようにします。そうすることでテストコードを伴わない実装をなくします。この段階でテストは全てグリーンです。

次に、テストコードを本来満たすべき仕様に合わせて変更します。試験的な実装を行ったおかげでCSSプロパティやクラスの変化の仕方はわかっているはずですので、書くべき自動化テストコードがわかるはずです。もしまだ分からないのなら、分かるようになるまで試験的な実装を進めて、そのぶんテストコードを書き足してから、上記作業を行います。

この時点でテスト結果はレッドです。ここから先は、通常のテスト駆動開発になります。レッド→グリーン→リファクタリングのサイクルを繰り返していきます。

開発を進めていくと、またテストファーストが難しい状態になるかもしれません。その際には再度試験的な実装を行い、試験的な実装を全てカバーするテストを書いてグリーンとし、そのテストを本来の仕様に合わせてレッドにします。そこから再びレッド→グリーン→リファクタリングのサイクルをスタートします。

このように、完全にテストファーストではありませんが、試験的な実装をうまく使うことで擬似的にテスト駆動開発を行うことができます。

まとめ

• UI 開発では視覚的効果を直接自動化テストで確認するのは困難だが、クライアントサイドJavascriptにおいてはCSSプロパティや クラスの変化を確認することで間接的にテスト可能。
• 「テスト無しの試験的な実装 → グリーンなテスト付きの試験的な実装 → 本来の仕様に変更しレッドとなったテスト」というプロセスを最初及び適宜途中に挟むことによって、擬似的にテスト駆動開発を行う。

Eclipse EGit によるタグの作成とプッシュ

バージョン管理システムにおけるタグとは、特定の時点でのリポジトリの状態です。一般的にソフトウェア開発ではリリースしたバージョンをタグとして保存することが多いようです。私の場合現在仕事でアジャイルで開発しており、イテレーションごとにタグを作成する方針を採っています。

Eclipse でEGitプラグインを使っていますので、タグの作成方法について書こうと思います。（使用しているのはEGit 1.3.0.201202151440-r です。）

Gitにおけるタグの種類

まず、Git のタグには３種類あります。（参考・・・Git公式サイト：2.6 Git の基本 - タグ）

• Lightweight （軽量）タグ
  特定コミットへの単なるポインタです。 
• Annotated （注釈付き）タグ
  チェックサムが付き、タグを作成した人の名前・メールアドレス・作成日時・タグ付け時のメッセージを保持します。 
• Signed （署名付き）タグ
  Annotated （注釈付き）タグにさらにGPG秘密鍵による署名を付与します。対応する公開鍵により検証を行うことができます。 

EGitがサポートするタグ

これらのうち、EGit でサポートされているのはAnnotated （注釈付き）タグのみです。とはいえ、公式ドキュメントでも Lightweight （軽量）タグよりもAnnotated （注釈付き）またはSigned （署名付き）タグの利用が推奨されていますし、GPGで署名を検証する必要がある場面は少ないと思いますので、Annotated （注釈付き）タグのみで十分な場合が多いでしょう。

なお、Lightweight （軽量）タグの作成は出来ませんが読み取りは可能です。Signed （署名付き）タグについてはサポート外とされています。（参考：Light-weight and Signed Tags | EGit/User Guide）

タグの作成

タグを作成するにはプロジェクトを右クリック→チーム→拡張→タグ...とメニューをたどり、タグ名と注釈を入力して「OK」ボタンをクリックすればタグが作成されます。

タグを作成した後再度タグ作成のダイアログを開いてみると、作成したタグが追加されています。なお、アイコンに黄色い人のマークが付いているものが注釈付きタグ、黄色い人のマークがないものは軽量タグです。

ちなみに軽量タグが存在する理由は、もともとリポジトリをSVNサーバから移植した際に、SVNサーバ上のタグが自動的に軽量タグに変換されたからです。（前述のとおりEGit上では軽量タグを作成できません。）

タグのプッシュ

デフォルト設定ではローカルリポジトリに作成したタグはリモートにプッシュしないようになっています。これはEGitだからというわけではなくそもそもGit自体そういう仕様のようです。

設定は以下のメニューから変更します。プロジェクトを右クリック→チーム→リモート→アップストリームからプッシュ構成…（ちなみにどうでもいいですが「アップストリームからプッシュ構成…」って誤訳ですよね。正しくは「アップストリームへプッシュ構成…」だと思います。）

出てきた「プッシュ構成」ダイアログで「参照マッピング」の「編集…」ボタンをクリックします。

「Push Ref Specifications」ポップアップが出ます。「Add All Branches Spec」ボタン、「Add All Tags Spec」ボタンをクリックして設定を追加し、「完了」ボタンをクリックします。

参照仕様が追加されているのを確認し、「保管およびプッシュ」ボタンをクリックします。
これでローカルリポジトリに作成したタグがリモートにプッシュされます。

[アジャイル] 不確実性コーンのモデル式とベロシティ予測

現在仕事で担当しているプロジェクトではアジャイル開発を採用しています。

アジャイル開発では繰り返し単位であるイテレーションにおいてどのくらいの進捗があったかを表す値をベロシティと呼び、このベロシティの見積りがスケジュールを立てる、あるいは進捗の予測を立てる上で非常に重要です。

マイク・コーン著 「アジャイルな見積りと計画づくり」（安井力、角谷信太郎 翻訳） によると、ベロシティの見積りには不確実性コーンを活用できる、とあります。
（不確実性コーン自体の説明はこちら→ アジャイルな見積もりと計画づくりに学ぶ 不確実性のコーン | Act as Professional - hiroki.jp by HIROCASTER）

その方法は実施したイテレーション数に基づき、ベロシティの予測値に幅を持たせるための下限係数と上限係数を不確実性コーンによって決めるというものです。具体的な数値も示されています。

実施したイテレーション数	下限係数	上限係数
1	0.60	1.60
2	0.80	1.25
3	0.85	1.15
4以上	0.90	1.10

（出典：「アジャイルな見積りと計画づくり」p.194 表16.1）

例えば実施したイテレーション数が2の場合、下限係数0.80、上限係数1.25ですので、仮にベロシティの実測平均値を10とすれば、ベロシティの予測は8～12.5の範囲ということになります。

しかしイテレーション数で決めるのもいいですが、それだと全イテレーション数の違いを計算に含めることができません。例えば、実施したイテレーション数が2の場合、全体のイテレーション数が8の時は進捗率25%ですが、全体のイテレーション数が15の時は進捗率13%です。

進捗率が違えば、本来なら不確実性コーンによる下限係数と上限係数も違わなくてはなりません。そこで不確実性コーンのモデルを近似式で作って進捗率から下限係数と上限係数を計算できるようにできないか、と考えました。

というわけで作ったモデル式がこちらです。

下限係数	log10(63+進捗率×937)/3
上限係数	2-log10(16+進捗率×984)/3

（0 <= 進捗率 <= 1）

Excel でグラフを出すとこんな感じになります。

不確実性コーンのモデル式とグラフ

対数関数を選んだのは単純に不確実性コーンに合わせやすいと思ったのが理由です。

進捗率は「実施したイテレーション数/全イテレーション数」でもいいですが、「完了ストーリーポイント/全ストーリーポイント」のほうが正確だと思います。後者の方が実際の状況を表していますので。

ここで「アジャイルな見積りと計画づくり」でも指摘されているように、プロジェクトの進捗が進んでくると不確実性コーンの右の方では下限係数・上限係数共に1に近づくため、ベロシティの幅を持たせるには範囲が狭すぎるという問題があります。上限係数の方は下がっても問題ないかもしれませんが、下限係数の方を上げ過ぎるとベロシティが落ちるリスクを少なく見積もりすぎてしまうので危険です。

したがって下限係数による予測はプロジェクトの進捗にともなって実績値による指標に置き換える必要があります。「アジャイルな見積と計画づくり」ではベロシティの実績値による指標として

• 直近8イテレーションの平均値
• ワースト3の平均値
• 最後のイテレーションの値

の3つを挙げています。これらのうち最初の2つが統計的意味を持つので、私は次のようにしています。

平均予測 ベロシティ	直近8イテレーションの平均値（小数点以下四捨五入） （実施したイテレーション回数が8より少ない場合は全ての平均値）
最高予測 ベロシティ	平均予測ベロシティ×不確実性コーンの上限係数（小数点以下四捨五入）
最低予測 ベロシティ	平均予測ベロシティ×不確実性コーンの下限係数（小数点以下切り捨て） と ワースト3の平均値（小数点以下切り捨て） のうち、値の小さい方

上記のようにすることにより、プロジェクト中盤～終盤にかけては下限係数による予測よりもワースト3平均のほうが小さくなるため、実測に基づくより安全な値を採用することができます。

Symfony1.4でログフォーマット変更方法の公式ドキュメントが間違っている件

Symfony1.4 でのログフォーマットの変更方法が書かれた公式ページは次のリンク先にあります。
http://www.symfony-project.org/gentle-introduction/1_4/ja/16-Application-Management-Tools

そこではアプリケーションの factories.yml を次のように変更すると書かれています。

all:
  logger:
    param:
      sf_file_debug:
        param:
          format:      %time% %type% [%priority%] %message%%EOL%
          time_format: %b %d %H

しかしこれをそのまま書いても効きません。正しくは、

all:
  logger:
    param:
      loggers:
        sf_file_debug:
          param:
            format:      %time% %type% [%priority%] %message%%EOL%
            time_format: %b %d %H

となります。追加した “loggers:” 以降の行のインデントは1段深くします。

以下、発見の経緯。

公式どおり設定しても効かないからおかしいと思って色々調べると、 factories.yml のペルプに行き着いて、形式の違いに気づきました。
http://www.symfony-project.org/reference/1_4/ja/05-Factories#chapter_05_logger

念のため、Symfony のパッケージ内部を覗いてデフォルト設定を確認すると、
(lib/vendor/symfony/lib/config/config/factories.yml)

all:
  logger:
    class: sfAggregateLogger
    param:
      level: debug
      loggers:
        sf_web_debug:
          class: sfWebDebugLogger
          param:
            level: debug
            condition:       %SF_WEB_DEBUG%
            xdebug_logging:  false
            web_debug_class: sfWebDebug
        sf_file_debug:
          class: sfFileLogger
          param:
            level: debug
            file: %SF_LOG_DIR%/%SF_APP%_%SF_ENVIRONMENT%.log

となっています。
なるほど確かに “loggers:” が足りない、と言うことで前述の通り設定して解決しました。

Eclipse EGit で作業ファイルの変更を個別に元に戻す方法

ファイルをいじっていて、前回コミットした状態まで戻したくなることってありますよね。

git コマンドを使う方法なら検索すると色々出てきますが、せっかく Eclipse を使っているので、ここは EGit プラグインから GUI 上で操作をしたいところ。

これが Subversion の場合だと Subversive プラグインには「ファイルを右クリック → チーム → 戻す」メニューがありましたが、EGit では「チーム」メニューにはそれらしきものがありません。

さらに検索すると、Stack Overflow で同様の質問をしている人を発見。
http://stackoverflow.com/questions/6788881/undo-single-file-local-uncommitted-change-in-egit-e-g-svn-revert

Right click on the file -> Replace With -> File in Git Index

そっちのメニューにあったのか。

Pleiades で日本語化している場合は例えばHEADに戻す場合は

ファイルを右クリック → 置換 → HEAD改訂

とやればできます。

いやはや、EGitではファイル1つのためにもハードリセットしかないのかと一瞬思いましたが、さすがにそんなことはないって話です。

Symfonyのlimeで使えるCSSセレクタのまとめ

Symfony でユニットテストやファンクショナルテストをする際、組み込みのテストフレームワークである lime を使うことが多いと思います。

しかしながら lime はネット上の情報源が少なく、特にテスト駆動開発をしようと思うと結構苦労します。結局 Symfony パッケージ内部のソースコードを見て調べることもあるでしょう。

ファンクショナルテストにはレスポンス内容を検査する sfTesterResponse::checkElement() メソッドの使用頻度が多いので、sfTesterResponse::checkElement() で使えるCSSセレクタをソースコードを見て調べてみました。対象バージョンはSymfony 1.4 です。

sfTesterResponse::checkElement() から CSSセレクタによってノードを選択する際、最終的に sfDomCssSelector::getElementsForNode() およびsfDomCssSelector::matchCustomSelector()
が呼び出されています。その中で正規表現を用いて CSSセレクタの機能を実現しているようです。

以下、ソースに記述のあったCSSセレクタを列挙します。

IDセレクタ及びクラスセレクタ

#id
指定されたIDを持つ
.class
指定されたクラスを持つ

属性セレクタ

[attr]
attr 属性を持つ
[attr=”val”]
attr 属性を持ち、値が val に一致する
[attre^=”val”]
attr 属性を持ち、値が val で始まる
[attr$=”val”]
attr 属性を持ち、値が val で終わる
[attr*=”val”]
attr 属性を持ち、値に val が含まれる
[attr~=”val”]
attr 属性を持ち、値をスペースで区切ったうちの1つに val が一致する
[attr|=”val”]
attr 属性を持ち、値が val または val- で始まる

範囲を限定するセレクタ

elem
要素セレクタ（elem 要素）
elem1 elem2
子孫セレクタ（elem1 要素の孫要素である elem2 要素）
elem1 > elem2
子セレクタ（elem1 要素の直下の子要素である elem2 要素）
element1 + element2
兄弟セレクタ（elem1 要素の直後の兄弟要素である elem2 要素）

擬似クラス

:contains(“val”)
文字列 val を含むもの
:nth-child(n)
親要素のn番目の子要素であるもの（n は 1 から始まる番号）
:first-child
親要素の最初の子要素であるもの
:last-child
親要素の最後の要素であるもの
:lt(n)
インデックス番号 n より前の要素（n は 0 から始まる番号、n 自体は含まない）
:gt(n)
インデックス番号 n より後の要素（n は 0 から始まる番号、n 自体は含まない）
:nth(n) または :eq(n)
インデックス番号 n の要素（n は 0 から始まる番号）
:odd
奇数番目の要素
:even
偶数番目の要素
:first
最初の要素
:last
最後の要素

注意点

lime の CSSセレクタには ID セレクタ及びクラスセレクタと属性セレクタを同時に使うと意図通りマッチしないというバグがあります(Symfony1.4.10で確認)。
これを回避するには、 ID 指定やクラス指定も属性セレクタと同様に [id=”foo”] や [class=”bar”] の形式にします。

例：
input#foo[checked] → 意図通りマッチしません。
input[id=”foo”][checked] → 意図通りマッチします。
input.bar[checked] → 意図通りマッチしません。
input[class=”bar”][cheched] → 意図通りマッチします。

ハマりやすいポイントだと思いますので注意してください。（私はハマりました・・・）

また、擬似クラス指定の :nth-child(n) の引数に指定できるのは整数のみです。

それから属性指定の [attr|=”val”] は本来 attr 属性の値が val そのものか、val- で始まるものを指定するはずですが、ソースコードを見る限り val で始まるものも許容しています。

参考

http://simonwillison.net/static/2003/getElementsBySelector.html
http://trac.symfony-project.org/ticket/6691

Symfony の url_for() の書き方でどれが速いか

Symfony でurl_for()やlink_to()にはいくつかの書き方がありますが、どれが一番速いのかと思っていたら公式ページに記述がありました。 なお、バージョンはSymfony 1.4 です。

速い順に、

• url_for('ルート名', パラメータの連想配列)
  例： url_for('article_by_id', array('id' => $article->getId()))
• url_for('@ルート名＋パラメータのクエリ文字列')
  例： url_for('@article_by_id?id='.$article->getId())
• url_for('モジュール/アクション＋パラメータのクエリ文字列')
  例： url_for('article/read?id='.$article->getId())

となっているようです。

まず、モジュール/アクションの形式よりもルート名指定のほうが速いのは、リンクにマッチするルーティングルールを見つけるためにすべてのルールを探す必要がないという理由です。
さらに、パラメータをクエリ文字列ではなく連想配列で指定すれば、余分なパースが不要となり高速化できます。

参考
http://www.symfony-project.org/gentle-introduction/1_4/ja/09-Links-and-the-Routing-System#chapter_09_sub_9c0012b84a321294dad618cb44debc4004bf29c0

SVNリポジトリをGitに移行して中央リポジトリとして使う

現在関わっているプロジェクトでバージョン管理システムを Subversion から Git に移行したのでその時の手順をまとめてみました。

Subversion を移行する Git リポジトリは中央リポジトリとしてSSH経由でアクセスするものとし、develpoers グループに所属するユーザにアクセスを許可することにします。

また、Subversion との併用ではなく、Subversion リポジトリは残すものの基本的には Git メインで使っていくことを想定しています。

まず、Git リポジトリ用のディレクトリを作成します。

# mkdir /var/git
# cd /var/git
# mkdir repos-name.git

Git リポジトリを初期化する前に、 ディレクトリの所有者を共有用グループに変更し、グループ書き込み権限を与えます。

# chown root:developers repos-name.git

オプションに --bare と --shared=group を指定して Git リポジトリを初期化します。

# cd repos-name.git# git init --bare --shared=group

ここで作るリポジトリは中央リポジトリとして使うので、作業ファイルは不要なため --bare オプションを指定しています。また、 --shared=group オプションを指定すると、 グループでの共有に適した権限を付与してくれます。（グループ書き込み権限やディレクトリのsetgidなど。）

データを実際に移行する前に、設定ファイルを編集します。先ほどの初期化コマンドでディレクトリ内に config という名前で設定ファイルが生成されています。

# vi config

[core]
repositoryformatversion = 0
filemode = true
bare = true
sharedrepository = 1
[receive]
denyNonFastforwards = true
[svn-remote "svn"]
url = http://example.com/svn/repos-name
fetch = trunk:refs/heads/master
branches = branches/*:refs/heads/*
tags = tags/*:refs/tags/*

追加したのは赤字で示した部分です。

さらに、コミット履歴のユーザ情報を名前＋メールアドレスに変換するためのファイルを用意します。

# vi ../users.txt

username = Mail Address <mail.address@example.com>
nanashi = Gonbe Nanashi <gonbe.nanashi@example.com>

ここまでできたら、あとは Subversion リポジトリからデータを取得して完了です。

# git --bare svn fetch -A ../users.txt

これでコミット履歴も含めて Git リポジトリにデータを引き継ぐことができます。


参考にしたサイト
http://blog.practical-scheme.net/shiro?20110226-sourceforge-git-migration
http://jarp.does.notwork.org/diary/200902b.html#20090213