スマホアプリのバージョンとか署名でハマった件

先日とあるアプリの開発に関わったけど、最後の最後で納品したapkが
ストア登録に失敗するということで、ドタバタしてしまった。

理由はapkをビルドした時にversionName変えてたけど、versionCode変えてなかったとか
署名したとかしてないとか、そんなこと。
どこかを失敗するたびに、発注者>ディレクター>プログラマーというやり取りが
(全員別の会社で物理的にも離れてた)
発生してしまい、期限が迫ってるところでなかなか胃がキリキリする展開だった。

そんな値は先に決めておけというのが次回に向けてのTryなんだろうけど
とはいえビルドした人への情報提供不足やビルドの設定ミスで失敗しないとも
限らないのでチェックしてから納品しましょうということで。

最後にビルドしたものを納品した時はこんな方法で確認してから納品した。

署名されてるかどうか確認する

 
jarsigner -verify -verbose -certs hoge.apk


署名がされていれば、署名の組織の情報とかでてくる。

 
X.509, CN=Hoge Fuga, OU=company, O=hogehoge Ltd., L=Tokyo, C=jp
ーーー以下略ーーー


されて無ければ、debug用の署名をされたことになってる。

 
X.509, CN=Android Debug, O=Android, C=US
ーーー以下略ーーー


android:versionCodeとandroid:versionNameを調べる

コマンドラインで以下を実行
 
aapt l -a hoge.apk


こんな結果が出てくる。

 
E: manifest (line=2)
A: android:versionCode(0x0101021b)=(type 0x10)0x3
A: android:versionName(0x0101021c)="1.20" (Raw: "1.20")
ーーー以下略ーーー


android:versionCodeが3で、android:versionNameが1.20

ってことでいいのかな。
jarsignerもaaptもAndroid SDKに含まれてます。
パスが通してあれば、普通に使えます。

ジョニーのタコライス

家の近所でランチ行ったことないなということで、近所の店を回ってみることに。

今日はジョニーのタコライスに行ってみた。
2月にできたばかりの模様。

ジョニタコセット


セットと勧められるがままに頼んでしまったウインナートッピングで980円。
持ち帰り用のコーヒーもついてる。

肉、野菜、チーズしっかり量があったので満足した。
サルサがもっとかかってるといいなと思ったけど、自分で後から追加でいるから
そのへんは好みでどうぞってことなんでしょう。

あとコーヒー美味しかった。

画像2


尚、お店はaiko押しの模様。
音楽もaikoでした。

nginxでcronologを使う

だいぶ前に設定してgist
残してたけど、改めて設定する機会があったのでメモ

環境は
OS CentOS 6.3
nginx 1.2.5

cronologとnginxはyumでインストールした。

/etc/init.d/nginx

nginxの起動スクリプトに起動時にmkfifoでパイプを作るのとcronologの起動を設定する

cronolog_startでpipeを作ったり消したりしてるのは、何かの拍子でパイプのパスに
ファイルが出来てしまった場合に備えて。

 
cronolog_start() {

if ! [ -p $logdir/access_log_pipe ]; then
rm -f $logdir/access_log_pipe
rm -f $logdir/error_log_pipe
mkfifo $logdir/access_log_pipe
mkfifo $logdir/error_log_pipe
fi

/bin/sh -c "/bin/cat $logdir/access_log_pipe | $cronolog $logdir/%Y/%m/%d/access_log &"
/bin/sh -c "/bin/cat $logdir/error_log_pipe | $cronolog $logdir/%Y/%m/%d/error_log &"
}



/etc/nginx/nginx.confの設定
ログの書き出し先を上で設定したパイプのファイルにする。

 
access_log /var/log/nginx/access_log_pipe main;
error_log /var/log/nginx/error_log_pipe warn;


以上

素のRedmineに比べて様々な使い勝手が向上してるAlminiumのご紹介

社内で最近DatawareHouseやBIツールと戯れてる@ntakaakiと申します。
VG Advent Calendarの8日目を担当させていただきます。

以前弊社の海外子会社の開発環境の構築を手伝っていた際に
導入したAlminium(Redmine)についてご紹介させていただきたいと思います。

Redmineは弊社でも数年前から利用していて、今ではほぼ全社で使われてる状況です。

今回の海外子会社の場合、現地の通信事情が悪くリモート環境に構成管理ツールや
リポジトリを置いてしまうと断線が即業務に影響を与えてしまうという問題が発生していました。
通信環境の改善もビル側の事情で簡単には改善できないとの話だったので
現地オフィス内で閉じた形で運用できるものがほしいとのことでした。

vit_office01


最初はGitlabを検討したのですがインストール手順の煩雑さに
嫌気がさしてしまい、もっと楽に入れられるものはないかと探していたところ
ちょうど見つけたのが下記の記事です。

かんばん!〜もし女子高生がRedmineで「スクラム」開発をしたら

いろいろ混ざってますが、細かいことはわきに置いとくとして。
内容自体は至ってまっとうにRedmineを使ったスクラム開発を
ストーリー仕立てで解説してくれてます。

この記事でAlminiumを知り、さっそく導入を進めました。

インストール自体は素のRedmineよりも圧倒的に簡単です。
自分はScientific Linux 6.2を利用しました。
私が構築した際は、Redmine1.3相当でしたが現在は2.0.3がインストールされますようです。

運用中の環境にインストールしようとするとうまくいかないかもしれません。
Alminium自体がRubyをインストールするのですが、先にRubyが入ってると
うまくいかないようなのでまっさらな環境にインストールすべきです。

インストール手順に従ってコマンドを実行するだけです。(当然ですが管理者権限です)

yum install git
git clone https://github.com/alminium/alminium.git
cd alminium
bash ./smelt

これだけで必要なRPMやRuby、Gem、Redmineのプラグインのインストールを
一通りやってくれます。

Alminiumを使っていて一番気に入ってるのはRedmineのプロジェクトの作成とは別で
行なっていたSVNやGitの設定をまとめてやってくれて、尚且つ両方のユーザーの権限設定を
Alminiumで一元管理してくれることです。

その他にも
 Backlogs Pluginでチケットの状況を視覚化できる

kanban

※サンプルで作ったプロジェクトのカンバンです

 CodeReview Pluginでのコードレビューの実施

と、これらのことが追加作業なしでできました。

上記のプラグイン以外にも素のRedmineに比べて様々な使い勝手の向上が
図られているので、余程の理由がない限りはAlminiumでRedmineを使うのがいいと思います。
Redmineとの違いはこちらをご確認ください

またプロジェクト作成時に設定されたGitのHooksを利用して
 別にインストールしたJenkinsの静的解析ジョブのキック
 確認環境への自動ディプロイ
なども行っています。

以上のようなことが様々なツールやサービスを組み合わせることなく
一台のマシン上で完結して実現することができました。
新たに構成管理ツールやリポジトリの設置を考えられてる方は検討されては如何でしょうか。

明日はAA職人のおみさんです。お楽しみに!

参考リンク
https://github.com/alminium/alminium
http://alminium.github.com/alminium/git.html
http://www.atmarkit.co.jp/fjava/index/index_scrum.html

参考書
Gitポケットリファレンス

時間短縮革命を読んだ -[書評]

時間短縮革命って本を読んだ。

おすすめ度 ★★★★☆
クリティカルチェーンとか好きな人向け。
仕事に期限があり、かつ複数の人が動かないと仕事が完成しないような状況に関係がある人が
読むとよいかも。

読みやすさ ★★★★★
200ページもないので、すぐ読める。

ライフハック系の本ではない。

病院での健康診断の時間を短縮するためにやってきた日産の工場の業務改善の部隊と病院スタッフの話。
なぜ工場の人たちが病院の業務改善というのは、この病院が日産の系列だから。

今の会社にも工場と呼ばれている部門があるのでそんなわけで読んでみた。

病院が工場のライン、受診者が車、検査を部品の組み付け作業みたいに置き換えると
人と物の違いはあっても病院と工場ってそんなに違いはないかもとも思う。

この一連の改善活動の手法の基礎となっているのが日産生産方式でその思想には
”限りないお客様への同期”という言葉が深く関わっている。
何を同期するかといえば時間、コスト、品質。

この本では特に時間の同期が主軸になっている。
病院での滞在時間中の無駄な時間を省き滞在時間そのものを短くしていくことで
お客様の要望する時間に同期していこうというのが目標。

改善活動は検査そのものの時間を短くするのではなく検査の順番を工夫したり
受診者やスタッフの動きの無駄を排除していく話が中心になる。

改善の例として
・検査の流れを一方向にする。
 (それまでは看護士があいてる部屋に行き当たりばったりで通してた。)
・一番時間のかかる検査に合わせて受診者を流していく。
 (タクトを合わせるというらしい)


途中、トヨタと日産の生産方式の違いに触れられていてその違いは在庫の有無と書いてあった。
トヨタ生産方式は、工程毎の在庫に着目してその無駄を改善していくとしている。
日産生産方式は、在庫がなく発注があったらそれに合わせて工程が計画・実行されていく
同期生産とされている。
工程間の同期をとるために無駄を省いていくという視点で改善していくとしている。

先ほどの改善例でも、タクトを合わせるという部分はまさに工場でやってることで
一番手間のかかる工程に合わせてラインを流すということで、前工程で作業しすぎて
時間のかかる工程の手前に在庫を発生させないということ。

同期生産ってクリティカルチェーンに出てきたTOC(制約理論)っぽい話なのかな。

感想
 現場の業務改善が実際にどう進んでいくか。
 データは説得するための材料。データを見て人は納得して協力してくれる。
 押しつけはだめ。
 ということがよくわかる.
 
日産生産方式の異業種分野への適用事例を紹介することがこの本の目的なので
多少の自画自賛ぽさがあるけど、気になるほどではない。





もっと、突っ込んだこと知りたい人はこっち読めってことかな。


Parallels-transporterでレンタルサーバーのLinuxを取り込んだ

Parallelsにさくらに借りてるサーバーの環境を
取り込んだので、そのメモ。

環境
ホスト側 MacOS X 10.5.6 Paralells 4.0
ソース側 CentOS 5.2

手順
1.ソース側にParallels-transporter-agentをインストールする
 agentはParallelsのサイトからダウンロードする
 
2.ホスト側のMacからソース側のMacにSSHで接続する
 X11 forwardingを許可した状態で接続する
 ssh -[X|Y] host名

3.ソース側でparallels-transporter-agentを起動する
 parallels-transporter-agentを実行する
 ホスト側のMacにParallels Transporter Agentのウィンドウが表示される
ピクチャ 3


4.ホスト側でParallels-transporterを起動する
 移行モードを高速
 移行元の種類をリモートの物理コンピューター
 接続タイプをネットワーク
 ソースコンピューターのIPアドレス
 以上を入力してMigrationを開始する

 Migrationが完了すると、”ソース側マシンのIPアドレス.hdd”というファイルが
 Parallelsの仮想マシンを保存してるフォルダのMigrationフォルダにできている。

5.仮想マシンを新規作成する。
 CD/DVDイメージは指定しない
 種類はLinux、バージョンはCentOS
 仮想マシンの種類は標準
 名前と場所は適当に指定
 以上で、作成をクリックして完了する

 仮想マシンの構成のハードウェア>ハードディスク1を開く
 イメージファイルの選択で、先ほどMigrationした際に作成した
 ソース側マシンのIPアドレス.hddを指定する

6.作成した仮想マシンを起動する

Recent Comments
Recent TrackBacks
  • ライブドアブログ