Gitで失敗コミット＋修正コミットをひとつのコミットにする（git rebase -i）

gitを使っていて、間違ってコミットしたファイルを修正したコミットを、後からくっつける（正しく作ってコミットしたときと同じにする）方法。

概要としては、git rebase -iを使い、特定のコミットに戻した後、interactiveにコミットを操作する。

以下、手順。
1) 状態確認
git logで、状態を確認する。

$ git log --oneline
68af727 Write CCC                →でも他のコミットをしてしまった
719560b Write BBB (Retry)        →間違いに気づいてまたコミットした
92746af Write BBB                →ここでコミットしちゃったんだけど
585c5d6 Write AAA
84041cf Created initial files.

「Write BBB」で誤って、「Write BBB (Retry)」で修正をして、コミットしたのを、「Write BBB」に統合する。(Retry)の時点でうっかりamendを忘れた感じ。

2) rebase -iで「Write AAA」の時点に戻す
git rebase -iをすると、指定したコミットから後の処理をeditorで指定してリプレイできる。

$ git rebase -i 585c5d6

エディタが開くので、(Retry)の「pick」の部分を「f」に変更する。

pick 585c5d6 Write AAA
pick 92746af Write BBB
pickf 719560b Write BBB (Retry)  ←修正
pick 68af727 Write CCC

# Rebase 84041cf..68af727 onto 84041cf
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message ←fはfixup
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

「f」でなく、「s」にすると、コミットログを修正できる。

保存してエディタを終了すると、修正される。

[detached HEAD a7fb63f] Write BBB
 1 files changed, 1 insertions(+), 1 deletions(-)
Successfully rebased and updated detached HEAD.

3) 確認
くっついている。

$ git log --oneline
d519a6c Write CCC
a7fb63f Write BBB
585c5d6 Write AAA
84041cf Created initial files.

git本当に難しい...

ScanWebにスマートフォンUIとプレビュー機能を追加

前に「SheevaPlugを使ってScanSnap fi-5110EOXをネットワーク対応スキャナにする」という話で、簡単なWebUI (scanweb)を作ったが、以下の点が不便だったので、改良を加えた。思想はそのまま、作りはごっそり変更という形。

•  スマートフォンからボタンが操作しにくい
  →jQuery Mobileを利用したスマートフォンインタフェースを実装
• 結果がわからないので、裏表が間違っていたりしてもわからない
  →プレビュー機能を実装

launchpadのjunkに置いてあったが、launchpadのprojectを作るほどでもないので、githubに置いた。必要であれば、zipで落とすなりgit cloneするなりお願いします。
https://github.com/sunnyone/scanweb

操作イメージは、以下のような形。

 

スキャンを押してしばらくすると...↓

 

 プレビューとログが出力される。

生のWEBrickはしんどくなってきたので、Sinatraを使った。プレビューはどうしているかというと、pdfを作るときに、サムネイルの入ったzipファイルを作るようにして、Webから呼び出されたら中身のファイルを抽出して表示するようにしている。

jQuery Mobileは使いやすくて、↑の画面には装飾されたボタンなんかがあるけど、CSSやJSは全然書いてない。マークアップのルールにしたがっただけ。こういう適当なアプリでは、見た目は何も考えなくてよくなってすばらしい。

問題は、SheevaPlugが遅くて、スキャン後の後処理にかなりの時間がかかること。これは想定外だった...

PowerShellをMSBuildから呼び出す

MSBuildは、MSの世界のAntのようなもの。そのMSBuildから、PowerShellのスクリプトブロックを呼び出す方法。

きれいな方法を目指すのであれば、PowerShell MSBuild Taskというものがあり、そのTaskを呼び出してPowerShellを実行すればよいのであるが、入っているdllが32bitであった。

32bit版MSBuildから呼べばいい話なのだと思うが、他のツールとの関連が面倒なので、本エントリでは安直にpowershellコマンドを呼ぶ方法を紹介する。

単純に書けば簡単で、Execタスクを利用して、powershell -Command "& { }" を呼び出せばよい（この表記については、PowerShell.exe コンソールのヘルプを参照。）

ただし、生で記述するとごちゃごちゃするので、MSBuildのPropertyGroupの中に、コマンドの始まりと終わりの文字列をPSBegin, PSEndなどとして定義し、ExecのCommand属性で$(PSBegin) $(PSEnd)などのように使うことで、ちょっときれいに書ける。
 
 例は以下のとおり。


上述のように、Invoke-Commandを使ってのリモートの呼び出しを塊にしておけば、リモート呼び出しもさっくり書ける。（リモートからPowerShellを呼ぶ環境を作るのが難しいのはまた別の話。）

参考：http://blog.brianhartsock.com/2009/10/20/using-powershell-scripts-from-msbuild-scheduled-tasks-etc/


まったく余談だが、勝手な要素をどんどん作っていくのがキモチワルイ...

Javaっぽいスクリプト言語BeanShell クイックスタート

前のエントリとは打って変わって、今度はJava世界のお話。

BeanShellは、JavaVM上で動くスクリプト言語。Javaっぽい文法で、Javaのライブラリを利用することができる。簡単な説明はこちら：http://news.mynavi.jp/column/jsr/031/index.html

どうしてこれを使いたかったかというと、JMeterからBeanShellのスクリプトを実行することができるため、前処理等で好きな処理を実行することができる(らしい)ためである。
(ctxやvarsなど、JMeterからBeanShell側に渡ってくる変数から、JMeterのデータを操作することができる。らしい。これはまだ試してない。)

基本

マニュアルのQuick Startにある通り、bshのjarにクラスパスを通し、"bsh.Console"か"bsh.Interpreter"のクラスを動作させることで、実行することができる。
http://www.beanshell.org/manual/quickstart.html#Quick_Start

C:\temp> java -cp c:\opt\bsh\bsh-2.0b2.jar bsh.Interpreter
BeanShell 2.0b2 - by Pat Niemeyer (pat@pat.net)
bsh % System.out.println("Hello, World");
Hello, World
bsh %

bsh.Interpreterは、ふつうのインタプリタで、/bin/bashみたいなものだと思えばOK.
bsh.Consoleは、GUIつきのコンソールを出してくれる。そのため、Windowsでは、以下のようなバッチファイルを準備しておくと便利。

ファイルを実行

ファイルに書いたスクリプトを実行するには、bsh.Interpreterにファイル名を渡せばよい。ファイル名のあとにさらに引数を書くと、プログラム側のbsh.argsから取得できる。

c:\temp\sample.bsh

C:\temp> java -cp c:\opt\bsh\bsh-2.0b2.jar bsh.Interpreter c:\temp\sample.bsh FIRST-ARGUMENT
args[0]: FIRST-ARGUMENT

編集環境を作る

Eclipse上で動くEclipseShellを試してみたが、なにやらいまいちだったので、安直にサクラエディタを使うことにした。サクラエディタの設定 > タイプ別設定一覧からJavaを選択し、設定変更で「ファイル拡張子」にbshを加えれば、色づけはそれっぽく使える。

ツール＞外部コマンド実行(Ctrl+F5)で実行できると便利なので、以下のようなバッチファイルを作成して実行できるようにする(～%4とかは適当。$@的に書く方法もあると思うが調べていない。)



あとは「外部コマンド実行」ダイアログから以下のように指定すればOK

C:\opt\bsh\bsh-interpreter.bat $F FIRST-ARGUMENT

ここまでわかれば、あとはJVMの世界なので、適当に使えると思う。

PowerShellとWPFでシンプルGUIプログラミング

ずっとWindowsでお手軽にGUIを作る方法を探していたが、ついに見つけてしまったかもしれない。

欲しかったのは、こんな感じのことができるもの：

• なるべく追加ソフトウェアをインストールせずに使えるもの
• 複雑なレイアウトは別にできなくてもよい
• UIはなるべくシンプルに書ける
• プロジェクトなどを必要とせず、1ファイルのスクリプトで表現できる

どのようにするかというと、PowerShellスクリプト上にXAMLをインラインで記述し、WPFのUIを作ればよい。

以下、ボタンを押すとWebサービスを呼び出して、テキストボックスに東京の天気を表示する例である。


PowerShellの仕組み上、.NETでできることはできるだろうとわかっていたので、Windows Formsを使えばいけそうな気はしていたが、コードがごちゃごちゃしそうでやめていた。
しかしWPFという発想はなかった。

なお、「なるべく追加ソフトウェアをインストールせずに使えるもの」という条件を外せば、ShowUIというモジュールがあり、よりPowerShell的に記述できる(らしい)。しかし使う人みんな入れないといけないので、ちょっと微妙だと思っている。

また、蛇足であるが、PowerGUIというエディタが便利。一度走らせると、ダイナミックな言語にも関わらず、ちゃんとVisual Studio的な補完が可能である。

参考：
http://stackoverflow.com/questions/5829787/powershell-wpf-from-xml-findname-problem
http://thepowershellguy.com/blogs/posh/archive/2009/05/15/powershell-v2-get-weather-function-using-a-web-service.aspx
http://www.dougfinke.com/blog/index.php/2011/07/24/extending-powershell-to-the-gui-with-showui/

gitレポジトリのテキストファイルがWikiになるGititのインストール

プレーンテキストなファイルで保存されるWikiでモダンなものがないかなーと思ったら

Gitをバックエンドに使ったプログラマ向きWiki - Gitit を見つけたので、Gititを Debian squeezeにインストールしてみた。

最初は記事の通り入れようと思ったんだけど、cabal installでエラーになり失敗。

検索してみると、

もしかしたらコンパイラが古いのではとGHCについて検索してみると、yumでインストールしたものは6.12.3で、http://www.haskell.org/ghc/ にある最新版は既に7.4.1になっていました。
さくらVPS（CentOS6）にGititをインストール

とのことなので、ビルドの依存パッケージを入れようとしたが、apt-cache searchしてたらgitit自体のパッケージがあることが判明。

# apt-get install git
# apt-get install gitit

でインストール完了。

 あとは、

$ mkdir gitit
$ cd gitit
$ gitit --print-default-config > gitit.conf
$ gitit -f gitit.conf

 とすれば、とりあえず5001ポートで立ち上がるので、http://localhost:5001/で試すことができる。

 デフォルトでは、gitit/wikidataがレポジトリとなり、ページを作成すると、ページ名.pageというテキストファイルができる。ページの名前に/を入れてページを作れば、ディレクトリができる。日本語のページ名にすれば、日本語のファイル名ができる。UTF-8だったので、普通にlsで見れる。すごく幸せな感じ。

Webから変更するときに、変更内容を入力するが、これはコミットメッセージになる。

なお、フォーマットはデフォルトではMarkdown. reSTなどいくつかの形式に変更できる。

デーモン化

 gititは(デフォルトでは？)フォアグラウンドで立ち上がるので、runitでデーモン化した。Debian的には、start-stop-daemonを使えばいいと思う。

 いつもの通り、適切な場所に"run"ファイルを作ってあげればおしまい。

(runsvdir対象ディレクトリは~/service, ログディレクトリは~/var/log/gititとする)


 これでサービス化完了。

Apacheで受け付ける

Wiki自体に認証をかけたかったので、5001の前にApacheを立てる。


リンクに含まれるパスを調整する方法がわからなく、mod_proxy_htmlを使うのもなんだったので、VirtualHostで作った。適当なVirtualHostの設定を/etc/apache2/sites-available以下に置いて、a2ensiteで有効化した。

BASIC認証のユーザを使う

デフォルトではGititは自前のフォームで認証するため、BASIC認証とかぶってしまう。そのため、gigit.confを変更して、Apache側で認証したユーザ名を使えるようにする。
～～～

authentication-method: http  #formから変更

～～～

ついでにトップページのファイル名もFront PageからFrontPageに変えてしまった。
～～～

front-page: FrontPage

no-delete: FrontPage, Help

～～～

これで完了。

掛け時計を修理する（ムーブメントの交換）

全くITとは関係ないのだが、GWに時計の修理をしてノウハウっぽいものが若干たまったのでブログに載せる。

家にある壁掛け時計が壊れてしまった。前々から兆候はあり、たまに止まる現象が発生していた。入れていた電池がひどく液漏れしていたので、同じ現象が発生し、電池に負荷を与え続けながら最期を迎えたのだと思う。

新しい時計を買ってきて壊れた時計は捨ててしまえば良い話なのだが、おそらく10年、もしかすると20年以上使い続けている時計なので、修理を試みることにした。
（修理といっても、時計についているムーブメントを交換してしまうので、別物といってもいいのだけど...)

ムーブメントは通販で買えるようだったが、実物を比較しながら買いたかったので、東急ハンズに買いに行った。買ってきたムーブメントが以下である。

ちなみに、このムーブメントは、掛け時計の場所には置いていない。ジャンル分けを聞いたわけではないので確実ではないが、ハンズに売っているのは、自作の時計を作るためのもののようなので、クラフト用品という扱いで、そのフロアにあるのだと思う。2012/5/2時点では、新宿のハンズでは7Fにあった。

＜ムーブメント購入時の注意点＞

このムーブメントだが、買う際にチェックすべきポイントがいくつかある。
  1. ステップ式(カチカチと動くタイプ)か、スウィープ式(なめらかに動くタイプ)か
  2. ネジ部分(下図青線部分)が必要かどうか(組み込み式かどうか)
  3. 突起部分を通す穴の幅（下図黄色線部分）
  4. 突起部分の高さ（下図赤線部分）
  5. 針が適合するかどうか

1. ステップ式(カチカチと動くタイプ)か、スウィープ式(なめらかに動くタイプ)か

これは好みの問題なので、好きなほうを買えばいいのだが、2種類あることは知っておく必要がある。

2. ネジ部分が必要かどうか(組込み式かどうか)

今回購入したムーブメントは、突起部分の一番下についているネジと、時計板の穴にセットした金具をネジ止めすることにより固定するタイプである。

しかし、今回修理対象となった時計がそうなのだが、時計板裏面に切欠があり、ムーブメントをひっかけて止める時計がある。

Webによると前者が一般的なようである。後者は「組込み式」と呼ぶらしい。
http://item.rakuten.co.jp/watchparts-okayama/10000725/

ムーブメント側がネジ止めするタイプで、時計側がひっかけて止めるタイプであっても、ムーブメントにひっかける部分があれば止めることができる。そのため、今回は特に問題にならなかった。しかし、ひっかけて止めるタイプの場合、ネジ止めする金具が不要のため、3.で記載する穴が狭く設計されていて、幅が足りない可能性があるので、注意が必要である。

3. 突起部分を通す穴の幅

時計板の真ん中に空いた穴よりも、突起部分の幅のほうが大きいと、ムーブメントを取り付けられない。そのため、穴の幅は測ってからムーブメントを買いに行くべきである。
（どうしてもつけたい場合は、時計板の穴を大きくするという方法もあるが。）

4. 突起部分の高さ

突起部分の高さはとても重要である。低すぎると時計板を通らないし、高すぎると時計のカバーに当たってしまう。

5. 針が適合するかどうか

ムーブメントの突起に針の根元の穴を押し込んで止める形になるので、ムーブメントと針が適合していないと、針を差し込むことができない。

今回はまってしまったのだが、もともとの時計についていた秒針が今回購入したムーブメントとあわず、針の穴の奥まで差し込むことができずに、秒針が高く（図の緑線）なってしまい、時計のカバーをかけることができなくなってしまった。

そのため秒針は、再度ハンズに行き、このメーカーの、元の時計と似たようなデザインのものを購入し、交換した。

＜交換作業の注意点＞

適合するムーブメントを購入することができれば、あとは交換するだけなのだが、1点だけ注意点がある。

それは、針をセットするときは、すべての針を12時に揃えてセットすることである。

これをしないと、長針が0分なのに短針は4時と5時の真ん中を示している、といった読み取れない時計が出来上がってしまう。
（上記を一度やってしまい、プログラマが一度ははまる、テトリミノが壁を突破するテトリスを作ってしまった気分になった。）

＜まとめ＞

秒針が刺さらないというアクシデントはあったが、無事に交換することができた。
出費は、ムーブメントが1,500円くらい、針が400円くらいである。
Web情報だが、作業を時計屋さんにお願いすると、4桁円台後半のようであった。調査やら作業の手間、なにより部品適合のリスクを考慮すると、妥当な金額と思える。
安い時計であれば買い換えてしまえば良いし、高い時計であれば修理を依頼したほうが良いと思うので、ムーブメント交換は趣味の範囲かもしれない。

なお、100円ショップで買ってきた時計のムーブメントと交換するという技をよく聞くが、上述のようなハードルがあるので、対応する時計を選択することは難しいかもしれない。100円なのでダメだったら捨てればよいという考えもあるかもしれないが、注意が必要である。

＜蛇足＞

時計の修理とは違う方向になるが、電波時計のムーブメントや、逆方向に動くムーブメント、24時間で1周のムーブメントといったものもあった。自作時計という意味では面白いかもしれない。