android + maven + mockito するときの正しい依存関係
これでおけ。
<dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <version>1.9.5</version> </dependency> <dependency> <groupId>com.google.dexmaker</groupId> <artifactId>dexmaker-mockito</artifactId> <version>1.0</version> </dependency>
色気を出してmockito-allとかdexmaker(-mockitoがついてない版)とかやるとハマるので注意。
C言語でforeachを書いてみた
Boost.Foreachを参考にした。
Boost.Foreachと違ってbeginとendはループの度に評価されるので、副作用を入れこまないように注意
#define FOREACH_C89( var, begin, end ) \ for( var = (begin); var<(end); var++ ) #define FOREACH_C99( var, begin, end ) \ for( size_t _foreach_i=0,_continue=1; _continue && (((begin) +_foreach_i)< (end)); _continue ? _foreach_i++ : 0 ) \ for(int _foreach_j = (_continue=0); !_foreach_j; _foreach_j=1 ) \ for( var = (begin) + _foreach_i; !_continue; _continue=1 ) #define FOREACH( var, begin, end ) FOREACH_C99( var, begin, end )
C++と違ってCではifを使った局所変数宣言ができないので、ダミーのfor文で代用している。
C89とC99の違いは、for文中で変数宣言ができるか否か
void test_foreach{ // C89版は値を受ける変数を事前に宣言しておく必要がある。 int i; FOREACH_C89( i, 0, 12 ){ printf("c89:\d\n", i ); } // C99版はその必要なし FOREACH_C99( int j, 0, 12 ){ printf("c99:\d\n", j ); } }
配列(ポインタ)の繰り返しもできる
#define SIZEOF_ARRAY(ary) (sizeof(ary)/sizeof(ary[0])) #define ARRAY_END(ary) (ary + (SIZEOF_ARRAY(ary))) void test_foreach(){ short s_array[] = {1,2,3,4,5,6,7,8}; FOREACH( short *n, s_array, ARRAY_END(s_array) ){ printf("val: %d\n",*n ); } }
おまけ
#define FOREACH_ARRAY( var, ary ) FOREACH( var, ary, ARRAY_END(ary) ) #define TIMES( count, var ) FOREACH(var, 0, count ) #define RANGE(type) struct { type begin; type end; } #define FOREACH_RANGE( var, range ) FOREACH( var, range.begin, range.end ) void test_foreach(){ int array[] = { 2,4,5,6,12,7 }; FOREACH_ARRAY( int *n, array ){ printf( "%d\n", *n ); } TIMES( 5, int n ){ printf("times:%d\n", n ); } RANGE(int) rng = {0,12}; FOREACH_RANGE(int n, rng ){ printf("range :%d\n", n ); }
AndroidTestCaseでListViewに子Viewを生成させる方法
ListViewのテストをやろうと思ったら、なかなか子viewを生成してくれなくて困った。
ちなみにAndroidTestCaseでは、adapter.notifyDataSetChanged()を呼んでもListViewは更新されないので、データに変更がある度に下記の処理を呼ぶ必要がある。
listViewHeightには子viewを表示するのに十分なサイズを指定すること。
public static void updateListViewChild( ListView listView, int listViewWidth, int listViewHeight ){ int widthMeasureSpec = MeasureSpec.makeMeasureSpec( listViewWidth, MeasureSpec.EXACTLY ); int heightMeasureSpec = MeasureSpec.makeMeasureSpec( listViewHeight, MeasureSpec.AT_MOST ); listView.forceLayout(); listView.measure( widthMeasureSpec, heightMeasureSpec ); listView.layout( 0, 0, listView.getMeasuredWidth(), listView.getMeasuredHeight() ); } public void testListViewChild(){ ListView listView = new ListView( getContext() ); listView.setAdapter( mAdapter ); updateListViewChild( listView, 800, 600 ); assertEquals( mAdapter.getCount(), listView.getChildCount() ); }
Gitリポジトリのディレクトリ構成を変更する
話の発端
例えば、以下のような構成のリポジトリがあったとしよう。
+ project - .git - build.xml - Main.java
projectディレクトリをルートとし、その直下にソースコードが配置されている。
さて、ある日このプロジェクトにテストコードを追加することになった。
しかしアプリケーションコードとテストコードを一つのディレクトリに混在させるのは好ましくない。
そこで、リポジトリの構成を以下のように変更したい。
+ project - .git + app - build.xml - Main.java + test - build.xml - MainTest.java
さて、どうしたらいいだろうか?
単にお好みの構成になるようにファイルを移動して、変更をコミットすればいいだけだ、と考えるかもしれない。
たしかにその通りなのだが、できれば始めからappサブディレクトリ内で開発を行なっていたかのように履歴を書き換えることはできないだろうか?
git filter-branchを使えばそれができる。
git filter-branch
以下で行う操作は基本的に取り消しができないので、作業用に専用のローカルリポジトリをcloneして行うべきである。
まずは現在の状況を見て欲しい。
# find . | grep -v .git/ . ./.git ./build.xml ./Main.java # git log --name-status --pretty=oneline d44f40c4f0a7033586fdb9af795ea2edcec79c33 commit2 M Main.java c5785fbde8a4ae3d5b0ed192c2690922b318f06e commit1 A Main.java A build.xml
現在コミットは二つある。
最初のコミットでbuild.xmlとMain.javaを追加し、二つめのコミットでjavaファイルを修正している。
ではこれらのファイルを履歴ごと、appサブディレクトリに移動させてみよう。
今回の問題を解決するもっとも単純なコマンドは、こうなる。
git filter-branch --tree-filter 'mkdir app; mv build.xml app; mv Main.java app;' HEAD
tree-filterを使うと、全てのコミットの作業ツリーに対して、指定したコマンドを実行した上でコミットをやり直すことができる。
では実行してみよう。
# git filter-branch --tree-filter 'mkdir app; mv build.xml app; mv Main.java app;' HEAD # find . | grep -v .git/ . ./.git ./app ./app/build.xml ./app/Main.java # git log --name-status --pretty=oneline 1d6302d9588a996b00e8d49b85139aa84c71be86 commit2 M app/Main.java 1189fe63f58932fef1d2f249ca84c6271fc6e5af commit1 A app/Main.java A app/build.xml
コミット履歴も含めて、サブディレクトリに移動しているのが分かる。
ここでいくつか注意点を述べる。
- 上記コマンドは、現在のブランチの履歴のみを書き換える。
- リポジトリ内に複数のブランチが存在していた場合、他のブランチとの整合性は失われる。(もちろんoriginとの整合性も失われる。)もはや古いブランチと履歴ツリーを共有することはできない。
- 正確に言うと、他のブランチが持つ書き換え前のコミットと、現在のブランチが持つ書き換え後のコミットは完全に別々のコミットとして扱われる。コミットのハッシュ値が以前と変わっていることに注目してほしい。
- -allオプションをつければ、リポジトリ内の全てのブランチに対して変更を適用することができる。
- -allオプションによって、同リポジトリ内のブランチの整合性は保たれる。しかしこの方法でも、外部のリポジトリ(要するにorigin)との整合性を失うことは避けられない。
- 要するにこの操作は、リポジトリ自体を新しく作り直して、古いリポジトリは破棄する方法であると考えるべきである。
試しにoriginと同期してみれば、実際に何が起こっているのか、よりよく理解できるだろう。
# git pull # find . | grep -v .git/ . ./.git ./app ./app/build.xml ./app/Main.java ./build.xml ./Main.java # git log --name-status --pretty=oneline 2ec94728f52e07f43ea1b2245e72b20c59091732 Merge branch 'master' of /home/as/user-dev-git/subdirectory.doc/project-origin 1d6302d9588a996b00e8d49b85139aa84c71be86 commit2 M app/Main.java d44f40c4f0a7033586fdb9af795ea2edcec79c33 commit2 M Main.java 1189fe63f58932fef1d2f249ca84c6271fc6e5af commit1 A app/Main.java A app/build.xml c5785fbde8a4ae3d5b0ed192c2690922b318f06e commit1 A Main.java A build.xml
移動前のツリーと移動後のツリーがマージされてカオスなことになってしまう。
両者はもはや混ぜるな危険、なのである
コマンドの改良
さて、とりあえずこれで当初の目的は達成したわけだが、実際のプロジェクトに適用する前に、まだ注意すべきことがある。
それは、tree-filterに渡すコマンドについてだ。
今回実行したコマンドをもう一度見てみよう。
filter-branch --tree-filter 'mkdir app; mv build.xml app; mv Main.java app;' HEAD
- このコマンドは、履歴の中に、build.xmlやMain.javaを含まないコミットが一つでもあると、失敗する。なぜなら、その作業ツリー内に存在しないファイルを移動させようとするからである。
- また、履歴の中に既にappというファイル/ディレクトリを持つコミットが一つでもあると、このコマンドは意図しない動作を引き起こす。
前者については、コマンド内で現在のファイルを列挙するようにすれば解決する。
後者については、作業ツリー内のファイルと重複しないランダムな名前の一時ディレクトリを作って、一旦そこに全てのファイルを移動させてから希望の名前にリネームするという方法がいい。
この処理をワンライナーで書くのはさすがに厳しすぎるので、スクリプトの力を借りるべきだろう。
rubyで書いてみた。
require "rake" def main target = ARGV.shift #カレントディレクトリのファイルを列挙 fs = `ls -a`.split.reject{|d| %w{ . .. .git .gitignore }.include?(d) } if(target && fs ) temp_dir = rand_name(1000){|n| ! File.exists?(n) } mkdir temp_dir fs.each{|f| mv f,temp_dir } mv temp_dir,target end end # 与えられたブロックがtrueを返すランダムな名前を作成する def rand_name(max_count) a = ('a'..'z').to_a + ('A'..'Z').to_a + ('0'..'9').to_a max_count.times{|i| name = Array.new(16){a[rand(a.size)]}.join return name if yield name } raise "too many loop" end main
呼び出してみる。リポジトリ外のファイルは絶対パスでないと参照できないので注意。
git filter-branch --tree-filter 'ruby ~/user-script/tree-filter-mv-dir.rb app' HEAD
まとめ
- git filter-branch --tree-filterを使用することで、コミット履歴を再構築できる。
- 再構築されたブランチは、もはや古いブランチやリポジトリとは履歴を共有しない。うっかり混ぜないように注意。
- tree-filterに渡すコマンドは、履歴上のどの時点の作業ツリーに適用しても、問題なく動作するものでなければならない。
- 特にファイル名を直接指定しているところは要注意である。その時点では存在しないファイルにアクセスしようとしたり、逆に既存のファイルを意図せず上書きしてしまうかもしれない。
- tree-filterを使ってあまり複雑なことをしようとは考えないほうがいい。
Activity#onRetainNonConfigurationInstanceについて
いまいちよく分かってなかったのでメモ。
といっても必要なことは全てAPIリファレンスに書いてあるんですが…
onRetainNonConfigurationInstanceは画面の回転などでActivityが再生成されるときに、新しいActivityのインスタンスへデータを受け渡すときに使います。
なんでonSaveInstanceStateとは別にこんなメソッドが用意されているかというと、Activityの新しいインスタンスが直ちに再作成されることが分かっている時に、Bundleを介さずに状態を復元するためです。
onRetainNonConfigurationInstanceが呼ばれたときに好きなオブジェクトを戻り値として返せば、そのあとgetRetainNonConfigurationInstanceメソッドで最後に保存したオブジェクトを取得できます。
goog.ui.tree.TreeControllで選択されたノードを取得する方法
コードにするとたったこれだけなんですが…
goog.events.listen( tree, goog.events.EventType.CHANGE, function(e){ console.log( e.target.getSelectedItem().getHtml() ); }
このEventType.CHANGEにたどり着くのに一日費やしましたよ…
EventType.CLICKやEventType.SELECTだとうんともすんとも言わないんだよな…
参考
今見ているWEBページのリンクを含むtweetを検索する
タイトル通り。
メモとして。
javascript: window.open("http://twitter.com/#!/search/" + encodeURIComponent(location.href ) );