2012年2月28日火曜日

第二回 #TokyoMercurial に行ってきたよ〜 --reverse編

先週土曜日に #TokyoMercurial に行ってきました。

今回は事前にやることを宣言して、各自モクモクと。
たまにどうやるかなどわいわいと。
前回同様楽しかったです〜

覚えたことやったこと
  • bookmark の挙動覚えた
  • --reverse 覚えた
  • ちょっとだけコードリーディング
  • MQの布教支援?とでもいうのかな???MQ可愛いよ、MQって言ってきた
  • sphinx について簡単な注意点とblockdiag@usaturn さんに教わった

ちなみに自分が宣言したのは
  • bookmarkが未だにわかってないので使ってみる
  • VPS契約したし、sshでpushしてみたい
だったかと。
まあ前半だけやりました。というかできませんでした…

BookMarkの動きはわかったものの
「やっぱり使いどころがわからねぇ…ブランチ切らせて…」
で終わりました…

あとはrebaseに「--keep/--keepbranches」を常に有効にさせるような
ラッパ関数をrebase.pyの中に書いてキャッキャウフフしてましたw
つっても4行くらいしか書いてないし、直接いじるとかどうよ?とか
シェルスクリプト書けないことを露呈したりとかとか…

ということで次回はもっとMercurialのコードリーディングに当てたいと思います〜
やっぱりもっとpython勉強せなイカンなと。


以下メモ

前回逆向きパッチについて備忘録的なものを書きましたが、まあ「--reverse」ってオプションがあるよってことをちょこっと。

例えば現状と特定リビジョンと差分を比較するなら

hg diff -r 比較対象リビジョン

となるわけで、まあ動かすとこんな感じ

$ hg diff -r 0                                      [/tmp/test]
diff --git a/1.txt b/1.txt
--- a/1.txt
+++ b/1.txt
@@ -1,1 +1,3 @@
 hoge
+hoge
+hoge

これは以下と等価(作業中でなければ)

hg diff -r 比較対象リビジョン -r 親リビジョン

$ hg diff -r 0 -r 2                                 [/tmp/test]
diff --git a/1.txt b/1.txt
--- a/1.txt
+++ b/1.txt
@@ -1,1 +1,3 @@
 hoge
+hoge
+hoge

前回はこの後者のパターンを使って逆向きパッチ作ったけど --reverse オプションが使えるよと

hg diff -r 親リビジョン -r 比較対象リビジョン


hg diff -r 比較対象リビジョン --reverse (作業途中のものがなければ)
or
hg diff -r 比較対象リビジョン -r 親リビジョン --reverse

と等価になります。
出力はこんな感じ。

diff --git a/1.txt b/1.txt
--- a/1.txt
+++ b/1.txt
@@ -1,3 +1,1 @@
 hoge
-hoge
-hoge

まあこれも知っておけば、どこかで使えるかも?

そういえば前回qguardについて書いてたけど、今回もMQはやっぱり話題に出てきました。

便利だよ〜
ci = qnew ってエイリアス書くのはどうだろう?
とか言っているだけでは伝わらないので「俺は普段Eclipseでこんな感じにMQ使ってます」メモ書いたら需要あるかな?

次回は4月なのでどこかで書いてみますか。

2012年2月27日月曜日

Mac Book Air 初期化後やったことメモ

単なるメモです。誰(@ngsw_taro くん)と無く向けたメモですけど
なんかほしいって言ってたしw

というよりも3月1日にも恐らく下記作業ヤル気がするので俺メモ…

win→mac乗り換え数ヶ月の今なら下記のように最初作業するかなぁ… というかしたんですけどね。

  • まずは無線LANに接続
  • 環境設定でキーボードとトラックパッドの設定(CapsLockはしねばいい)
  • ここ http://3a3k.blogspot.com/2011/10/dsstore.html
  • お好みのブラウザインストール(Chromeとか)
  • お好みのエディタインストール(MacVimとか)
  • ソフトウェアアップデートを何回か…
  • AppStoreからXcodeインストール
  • XcodeからCLIをインストール
  • XcodeがCLI分離したため注意しないとHomeBrewとかで困る http://mogutan.wordpress.com/2012/02/18/trouble-installing-xcode4-3/
  • JavaRuntimeインストール → コマンドでjava -h とか打てばインストールする?って聞かれるはず
  • PATHが気に入らないので書き換え → /usr/local/bin を先頭に (多分.bash_profileとかを生成して頑張る系)
  • HomeBrewとかインストール
    • 好きなだけ必要なものをお入れください

      • git(CLIにいるけど最新入れたいから入れる)
      • hg(無いと生きていけない)
      • zsh(既にいるけど最新じゃないし…)
      • …てかほしいもの探せばだいたいあるんじゃねーのな感じでだらだらと…
  • お好みのシェルに切り替え(zshとか)
  • sshキー作ってgithubやらbitbucketやら自分のサーバやらに登録
  • 好きな統合開発環境(eclipseやらIntelljやら?)入れて一段落?

こんな感じ?
あとは必要時に適当でなんとか(多分忘れ事は多いけど…)なる気がする、俺の使い方だとw

あ、Twitterクライアントも入れないと生きていけないですね。

2012年2月20日月曜日

ADK ハッカソンに行ってきた #adk_hack

ADKハッカソンに行って来ました。

昨年の5月くらいでしたっけ?ADKが出てきたの。
当時から触ろう、触ってみよう、触れたらいいなぁ…
とか思って会社のHT-03Aを2.3.4に上げた記憶があります。

まあ今日まで触ることなかったわけですが。


サンプル一通り触ってそれなりに楽しめたのでよかったです。
ある意味その時点で目的は達成しました(ぉぃ
主催者の @itog さんのところに標準のサンプルを見やすくしたものが置いてあります。
http://d.hatena.ne.jp/itog/20110701/1309487325

本日一番頑張った奴
https://plus.google.com/113699421589247328057/posts/9QQuoHQcBcn

え、ハッカソンの結果?
間に合わなかったんだよ、イワセンナ(*^Д^*)ハズカシイ

なので俺個人としてはLED光らせてAnimationSet弄って終わりましたw

未完のそのアプリの姿はこちら。




あれだね、デザイナーさんって素晴らしいね。
画面だけ見れば、いかにも出来ている感満載じゃねーかw

えぇ、まあ本来はジョイスティックでドロイド君がゴールに向かう予定でした。
アプリ名称の通りダルマさんが転んだなので

  • 3つ有るLEDを信号機のように使用する
  • 3つ目(赤)点灯時にドロイド君が動いている(ジョイスティック押下状態でない)場合NG
  • NGにならずにゴールに向かう
  • LED点灯タイミングは指定範囲内でランダム

とまあそんな予定でしたがマージが間に合わずにできませんでした、テヘヘ

とかいう発表だったんですが、今思えば
「上記のどこがゴールなのか」
という疑問があります。

うむ、仕様すら決めきれてなかったかw

ついでにいうと2回くらい「あれ、これって仕様と違くない?」って @tmk_beta さんに突っ込まれてたのはこちらのアカウントになります。







ということで完成させるのに強力な味方が増えました。
仕様追加は @kerukerupappa さんまで!

って、あれ、それこれじゃないよね?
とりあえず今度 @kerukerupappa さんにお会いした時に考えます。

まさかのヨチヨチロボ部?w

もしくはおもかげるラジコン部に食いつかせるというのもあるなぁ…

2012年2月19日日曜日

#StartupGroovy に行ってきた

件名の通り昨日行って行きました



らしいです。つまり俺のStartupGroovyは終わっていない(違

と、言いましても既に多くの方がまとめられていますし、詳細はそちらとかを

http://d.hatena.ne.jp/absj31/20120218/1329636558
http://d.hatena.ne.jp/grimrose/20120219/1329619718
http://tomykaira.hatenablog.com/entry/2012/02/19/155237
http://d.hatena.ne.jp/orangeclover/20120219


私の超素直な一言感想



普段Java(つーかAndroidっつーか)をメインで触っているとScalaにしてもGroovyにしても
確かに超短くなりますし、便利だなーって思います。
→すみません、その程度の認識です。こまけーこたーいいんだよ

そんな俺の結果。いいのか悪いのかは正直よくわかんないけど。
https://bitbucket.org/daneko/startupgroovy


でも楽しかったです。また有るなら参加したいですね〜

@kyon_mm さん見れたし。


以下重要


後日模範解答がでるのと

Android + JUnit + Robolectric + Gradle

な環境構築に関してまとめてくれるそうです。


Android + JUnit + Robolectric + Gradle

な環境構築に関してまとめてくれるそうです。

大切なことなので2回書きます。

やっぱり言ってみるものですね。


ということでSpockやらGradleやら触ってみたい項目がTODOに積まれるわけですが、他にも積んでいるものがあるわけで…
いつになったら消化できるんだこれ…




2012年2月5日日曜日

AsyncTaskLoader使ってみた…んだけど

今更ながらAsyncTaskLoaderを使って見ました。

コンパチライブラリを使用してです。(未だに2系だけしか持ってません( ー`дー´)キリッ)
動作させたのは2.2のエミュレータとDesire(2.2)とINFOBAR(2.3)

以下参考サイト
時代はAsyncTaskよりAsyncTaskLoader
ソフトウェア技術ドキュメントを勝手に日本語化

サンプルはこちら
githubじゃなくてスミマセン。
単に指定した秒数待ってランダムに値をぶん投げるだけのものですが…
https://bitbucket.org/daneko/asynctaskloadercheck

まあ今までAsyncTaskは使わずに自前でThread書いたりHandlerに投げたりばっかしてました…
なのでこれからは時代の流れにそってAsyncTaskLoaderを使いたいと思います。



で終わるんだったらこのエントリーはしません。

以下ハマった現象

画面回転を行なうと「FragmentActivityから生成されたLoader側はなぜかおかしい挙動をする
Fragment#getLoaderManagerで生成したものは期待通りの動きをするんですが…

何を言っているのかわか(ry

とりあえずおもむろにログを晒す

02-05 18:36:30.732: D/jp.omokageru.dnk.loader.HelloLoaderActivity(613): onButtonClick
02-05 18:36:30.732: V/LoaderManager(613): initLoader in LoaderManager{44f79998 in HelloLoaderActivity{44f43928}}: args=Bundle[{sleeptime=2000}]
02-05 18:36:30.741: D/jp.omokageru.dnk.loader.HelloLoaderActivity(613): onCreateLoader
02-05 18:36:30.741: D/jp.omokageru.dnk.loader.CheckLoader(613): CheckLoader
02-05 18:36:30.741: V/LoaderManager(613):   Starting: LoaderInfo{44f7adb0 #0 : CheckLoader{44f7af20}}
02-05 18:36:30.741: D/jp.omokageru.dnk.loader.CheckLoader(613): onStartLoading
02-05 18:36:30.771: V/LoaderManager(613):   Created new loader LoaderInfo{44f7adb0 #0 : CheckLoader{44f7af20}}
02-05 18:36:30.781: D/jp.omokageru.dnk.loader.CheckLoader(613): loadInBackground
02-05 18:36:32.786: V/LoaderManager(613): onLoadComplete: LoaderInfo{44f7adb0 #0 : CheckLoader{44f7af20}}
02-05 18:36:32.786: V/LoaderManager(613):   onLoadFinished in CheckLoader{44f7af20 id=0}: String{44f7e390}
02-05 18:36:32.791: D/jp.omokageru.dnk.loader.HelloLoaderActivity(613): onLoadFinished
02-05 18:36:32.791: D/jp.omokageru.dnk.loader.HelloLoaderActivity(613): loader:CheckLoader{44f7af20 id=0}
02-05 18:36:32.791: D/jp.omokageru.dnk.loader.HelloLoaderActivity(613): data:Finish9
02-05 18:36:42.191: V/LoaderManager(613): Retaining in LoaderManager{44f79998 in HelloLoaderActivity{44f43928}}
02-05 18:36:42.191: V/LoaderManager(613):   Retaining: LoaderInfo{44f7adb0 #0 : CheckLoader{44f7af20}}
02-05 18:36:42.191: V/LoaderManager(613): Destroying Inactive in LoaderManager{44f79998 in HelloLoaderActivity{44f43928}}
02-05 18:36:42.291: V/LoaderManager(613): Finished Retaining in LoaderManager{44f79998 in HelloLoaderActivity{44f813a0}}
02-05 18:36:42.331: V/LoaderManager(613):   Finished Retaining: LoaderInfo{44f7adb0 #0 : CheckLoader{44f7af20}}
02-05 18:36:42.331: V/LoaderManager(613):   Stopping: LoaderInfo{44f7adb0 #0 : CheckLoader{44f7af20}}
02-05 18:36:46.451: D/jp.omokageru.dnk.loader.HelloLoaderActivity(613): onButtonClick
02-05 18:36:46.451: V/LoaderManager(613): restartLoader in LoaderManager{44f79998 in HelloLoaderActivity{44f813a0}}: args=Bundle[{sleeptime=2000}]
02-05 18:36:46.451: V/LoaderManager(613):   Making last loader inactive: LoaderInfo{44f7adb0 #0 : CheckLoader{44f7af20}}
02-05 18:36:46.451: D/jp.omokageru.dnk.loader.HelloLoaderActivity(613): onCreateLoader
02-05 18:36:46.451: D/jp.omokageru.dnk.loader.CheckLoader(613): CheckLoader
02-05 18:36:51.482: V/LoaderManager(613): Retaining in LoaderManager{44f79998 in HelloLoaderActivity{44f813a0}}
02-05 18:36:51.491: W/LoaderManager(613): Called doRetain when not started: LoaderManager{44f79998 in HelloLoaderActivity{44f813a0}}
02-05 18:36:51.491: W/LoaderManager(613): java.lang.RuntimeException: here
02-05 18:36:51.491: W/LoaderManager(613):  at android.support.v4.app.LoaderManagerImpl.doRetain(LoaderManager.java:733)
02-05 18:36:51.491: W/LoaderManager(613):  at android.support.v4.app.FragmentActivity.onReallyStop(FragmentActivity.java:634)
02-05 18:36:51.491: W/LoaderManager(613):  at android.support.v4.app.FragmentActivity.doReallyStop(FragmentActivity.java:616)
02-05 18:36:51.491: W/LoaderManager(613):  at android.support.v4.app.FragmentActivity.onRetainNonConfigurationInstance(FragmentActivity.java:442)
02-05 18:36:51.491: W/LoaderManager(613):  at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:3617)
02-05 18:36:51.491: W/LoaderManager(613):  at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:3673)
02-05 18:36:51.491: W/LoaderManager(613):  at android.app.ActivityThread.handleRelaunchActivity(ActivityThread.java:3789)
02-05 18:36:51.491: W/LoaderManager(613):  at android.app.ActivityThread.access$2400(ActivityThread.java:125)
02-05 18:36:51.491: W/LoaderManager(613):  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2037)
02-05 18:36:51.491: W/LoaderManager(613):  at android.os.Handler.dispatchMessage(Handler.java:99)
02-05 18:36:51.491: W/LoaderManager(613):  at android.os.Looper.loop(Looper.java:123)
02-05 18:36:51.491: W/LoaderManager(613):  at android.app.ActivityThread.main(ActivityThread.java:4627)
02-05 18:36:51.491: W/LoaderManager(613):  at java.lang.reflect.Method.invokeNative(Native Method)
02-05 18:36:51.491: W/LoaderManager(613):  at java.lang.reflect.Method.invoke(Method.java:521)
02-05 18:36:51.491: W/LoaderManager(613):  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)
02-05 18:36:51.491: W/LoaderManager(613):  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
02-05 18:36:51.491: W/LoaderManager(613):  at dalvik.system.NativeStart.main(Native Method)

ログを見たら破棄したローダを再利用して落ちているように見えます。

発生させる挙動としては以下
  • アプリを立ち上げる
  • AsyncTaskLoaderを実行する
  • 結果を見る
  • 画面回転する
  • AsyncTaskLoaderを実行する
  • onCreateLoaderで止まる(なぜ…)
  • 再度画面回転する
  • 上記ログが出る

回避方法はわかった範囲では以下2つ
  • 画面回転時Activityを破棄しないようにする(単に逃げる)
  • onCreate時にFragmentActivity#getSupportLoaderManagerを呼び出す(なぜうまく行くのかわからん…)
2つ目なんてバットノウハウ以外の何者でもないんだけど

@Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        // ここでの呼び出しを無くすとなぜか画面回転後は動作しなくなる
        // しかもonCreate以外での呼び出しは駄目っぽい
        getSupportLoaderManager();
    }

ただ画面回転で起こるということは、状況によってはIntentなんかで画面遷移した際にも
起こりそうで嫌です…
destroyまで走れば一緒かな…

Fragment#getLoaderManagerもFragmentActivity#getSupportLoaderManagerも
結局はFragmentActivity#getLoaderManagerを呼んでいますしなんでなんだろ

どっちもonDestroy時にLoaderManager#doDestroy呼んでいるし



何れにしても、なんかうまくいきませんでした。
「使い方がおかしいだろ」とかあったら教えてください。