OmniFocusとPivotalTrackerの連携でタスク管理が17倍効率化すると話題に

2013年12月22日日曜日

こんばんは。この記事はGTDアドベントカレンダー2013*0の12/22分の記事で、自分の中で話題沸騰中の案件です。設定方法直行はこちら

Pivotal Trackerは、「やることや、その優先度をどんどん組み換えつつ進行してプロジェクトの目的を達成するための管理ツール」です*1

ソフトウェア開発でありがちな
  • 開発期間が短い
  • 仕様が変わるのに開発期間は延びない
  • やることの順位付けが正しくできない
  • 誰に確認してもらえばいいのか明確でない
  • やってるうちにテンションが下がっていく
といった問題に対して「やりたいことを突き詰めていったら、そりゃ当初見えてなかった仕様が必要になるかもしれないし、優先度が変わってくるかもしれない。市場へ出してみてフィードバックが得られたら尚更。だけど時間は有限なのでそんなに無茶は効かないし、やむなく無茶するならするで最低限無茶をやってることだけは認識を持ちつつ納得して進めよう。いのちだいじに。」という進行をしたいプロジェクトに打ってつけのものです。
逆に、「新しい技術要素は無いし、仕様を変更することもまずないので、粛々とやろう。」という進行のプロジェクトにはあまり向きません。
興味を持ちましたか? 多分持ちましたよね。今なら60日間無料でフル機能を使えるトライアルがあるので、使ってみてください。Googleアカウントでログインしてすぐに使えます。OSSなど、タスクを全世界へ公開しても問題ないプロジェクトであれば全機能を無期限無料で利用できます。

Pivotal Trackerの初歩については技術評論社さんの「Smartphone Design」(2012年9月28日発売)に記事を書いたので、興味のあるかたはぜひどうぞ。思い返してみるとあの本(というかムックか)はVisual Studio方面の高橋忍さん、かれこれ10年ぐらい前に私がWin32 APIとC#を学ぶ際に一方的にお世話になった赤坂 玲音さん、コロプラの馬場さん、Simejiの矢野りんさんやadamrockerさん、先日テックヒルズで話す機会を頂いたAimingの牧野さんら、相当控えめに言っても「錚々たるメンバー」による作で、いろんなトピックをぱらぱらと読んで楽しめて役に立って1,580円(税込1,659円)は大変お得だと思います #sウテマ
ちなみにPivotal Trackerについては、1年経ってサービスのロゴと一部ログインUIこそ変わり検索など機能強化されました(そして執筆当時にはあった日本語処理上の不具合が解消されました)が、基本的な考え方や扱い方は執筆当時から全く変わっていません。

さて、本題です。

Pivotal Trackerは、各ストーリー(タスク)に細かな期日を割り当てないという特徴を持っています。あくまでも特定のスプリント内での処理をターゲットとし、また、柔軟にその処理順を変更することで細かなピボットを繰り返していくというコンセプトからすると、マイクロマネジメント的な過度の細分化と管理は不要ということでしょう。
いえ、正確には不要ではないのです。「自分のやることの期日は自分で管理できる人または集団のためのもの」ということです。純粋にプロジェクトをスクラムで進行する場合であれば、スクラム会議(朝や夕など定めたタイミングでの15分以内の日次ミーティング)を軸として解消するものといえます。
では、オープンソースのプロダクトや日次ミーティングを開催するのが難しい環境ではどうすればいいのか。
やはりプロジェクトメンバー各々が管理するしかありません

ここで大きな問題が生じます。タスクの多重管理です。
GTD運用に重要なポイントはいくつかありますが、それは機会を改めて書くことにして、今回着目したいのは
「要対応のタスクをGTDのツール(手帳でも、ソフトでも)上へ漏れ無く書き出す。そして優先度をつけ、実行フェーズでは脇目もふらずに処理する」
という性質です。このためには
  • Pivotal TrackerとGTDツールとの間でタスク情報を同期する(二重管理を極力避ける)
  • タスク管理に必要な操作量と複雑さを極力低減する(操作は少ないほうが良い)
ことが重要です(※人力で複雑なワークフローを回すと数十〜数百のタスクを処理しているうちにきっと漏れが出ます。漏れを出さないようにチェック回数を増やす策も一定有効ですが、明らかにストレス源となります)。

Pivotal TrackerはAPIが充実しており、外部ツールへと情報を取り出しやすいです。それを使った連携方法としてomnifocus.rb + omnifocus-pivotaltracker.rbが大変便利なので紹介します。OmniFocusでなくても勿論良いのですが、私がOmniFocusにべったり依存した生活を送っているので、OmniFocusベースの紹介です。


設定方法:
先に、Pivotal TrakerのAPIキーを発行します。
My Profileページへ行き、画面下部のAPI TOKEN部分で"CREATE NEW TOKEN"をクリックします。

図のようにトークンが発行されればokです。
続いて、Rubyで書かれたOmniFocusバインディングとPivotal Trackerプラグインをgemsからインストールします。
$ sudo gem install omnifocus omnifocus-pivotaltracker
$ of sync
ここまで実行すると、~/.omnifocus-pivotaltracker.ymlに設定ファイルのテンプレートが作成されます。このファイルに、Pivotal Trackerから発行したAPIキーを記入します。:user_name:には、プロジェクト内で利用している略名を指定しましょう。なお、omnifocus-pivotaltracker 1.1.0以上では、マルチアカウントをサポートしています。公式READMEにあるように
---
-
  :token: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
  :user_name: muo
-
  :token: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
  :user_name: KN
と複数のトークン設定を続けて書くことで、複数のアカウントの情報と同期できます。様々なプロジェクトで別々のアカウントを持っている場合などに大変便利です*2
トークンを設定したら、もう一度
$ of sync
を実行しましょう。OmniFocusのnerdというプロジェクトディレクトリ中にPivotal Trackerのプロジェクト群がインポートされたはずです*3

このような状態のプロジェクトは、OmniFocus上で

このように表示されます。運用ルールとして「期日入力はOmniFocus上でおこなう。ほかの一切のワークフロー処理はPivotal Tracker上で通常通りにおこなう」と定めるのが重要です。あとはcrontabで
*/10 * * * * of sync 1>/dev/null 2>&1
のように10分毎の実行を仕込んでおきましょう。Pivotal Tracker上で完了状態(Deliveredなど)へと変更したタスクは、10分以内に反映されることになります。あとは「完了タスク、ちゃんと完了チェック付けたっけ?」などは忘れてひたすらと実行フェーズを頑張ってください。
ちなみにOmniFocus上でタスクを完了状態にしても、Pivotal Tracker上で何らかの完了状態になるまでは次回同期時に状態が巻き戻されます。期日入力以外をOmniFocusでおこなう=ルールに違反したミスなので、早期に検出できて良いですね*4

Q. ところで17倍ってどういう意味?

A. 素数!*5

*0: こちら
*1: Pivotal...といえばリーン・スタートアップ(懐かしい)書籍中で技術協力としてPivotal Labsがクレジットされていたのを覚えている方もいらっしゃるでしょう。えっ、いない?そんなぁ…ともかく、その会社の製品(サービス)です。
*2: 別のアカウントで持っているプロジェクト名が同じだったらタスクが混ざってカオスなことになるので注意してください
*3: omnifocus.rbの現行版にはnon-ASCII文字コードの扱いに問題があり、日本語プロジェクト名を扱うと「同期するたびに空の同名プロジェクトが増える」という不具合があります。パッチは投げてあるので、取り込まれるのを待つか、日本語プロジェクト名を避けるか、手パッチで対応してください。
*4: OmniFocus側を状態の正とするのはイマイチ良い策といえません。Pivotal Tracker内には「ストーリーの結果をオーナーに確認してもらい、問題があれば差し戻してもらう」というワークフロー概念および「FeatureとChoreというストーリー種別」が存在しており、OmniFocusでシンプルにこれらをカバーするのが割と無理筋なためです。
*5: Effective Android 達人出版会版の36章参照

Android 4.4で加わったメディアAPIの進捗を確認する

2013年11月14日木曜日

本記事はTechBoosterさんによる Android 4.4 KitKat 冬コミ原稿リレーを開催 という企画の11/12の寄稿記事です。11/12の寄稿記事です。

日本の皆さん、こんばんは。頭のなかだけアメリカ西海岸に居ます。11/13の18時を回ったところです。夏時間終わったので日本からは-17時間です。日本の皆さんは既に13日のとみーさんの記事をご覧頂いているかと思います。素晴らしいデザイン系まとめですね。恐縮してしまいます。それでは12日の記事です。

Android 4.4では、マルチメディア機能が大きく強化されました。動画の再生中に解像度変更を伴う動的なストリーム変更ができるようになったり、HTTP越しのライブストリーミング機能が強化されていたりします。



そんな中で今回主に扱うのは、AV同期のためのオーディオタイムスタンプ取得機能です。
http://developer.android.com/about/versions/kitkat.html では
Audio timestamps for improved AV sync
The audio framework can now report presentation timestamps from the audio output HAL to applications, for better audio-video synchronization. Audio timestamps let your app determine when a specific audio frame will be (or was) presented off-device to the user; you can use the timestamp information to more accurately synchronize audio with video frames.
と紹介されています。そのまま訳すと以下の通りです。

AV同期のためのオーディオタイムスタンプ取得機能
オーディオフレームワークにおいて、より良い映像/音声同期のために現在の再生タイムスタンプをオーディオ出力HAL(ハードウェア抽象化レイヤ) からアプリケーションに対してレポートできるようになりました。オーディオタイムスタンプを利用することで、特定のオーディオフレームがどのタイミングで端末からユーザに対して発せられたか(または、られるか)を知ることができます。この情報を利用して、映像と音声をより良く同期させることが可能です。
= 機能の扱い方 =
扱い方の概要はhttp://developer.android.com/about/versions/android-4.4.html#AudioTimestampに記載されています。
割と簡単なAPIで、予めタイムスタンプ取得用に作成したandroid.media.AudioTimestampのインスタンスをAudioTrack#getTimestamp(android.media.AudioTimestamp)として渡すことで、ナノ秒単位のモノトニックなタイムスタンプを取得できます。
モノトニックなタイムスタンプは、それ自体では少々扱いづらいため、オーディオの再生を開始するタイミングなどで記録したSystem#nanoTime()との比較にて処理するのが良いでしょう。

実際に特性を調査していく前に、android.media.AudioTimestampの定義をもう少々読んでみましょう。nanoTimeがナノ秒単位のタイムスタンプを表すのは明らかですが、framePositionは何でしょう。
これは、指定AudioTrackインスタンスの持つバッファ中での現在再生位置を示します。結果、バッファを使い切った際の値更新挙動に差が生じます。例えば

  • AudioTrackのバッファサイズを小さめに確保する
  • AudioTrack#setNotificationMarkerPosition(int)でAudioTrackのバッファサイズを超える位置を指定する
  • onMarkerReached()でのコールバックにてAudioTrack#stop()を呼び出し、再生を停止する
とすると、発音がAudioTrackのバッファサイズ相当の箇所で停止すると共にframePositionの値も更新が止まるのに対し、nanoTimeの値は増加し続けます。このため、AudioTimestampを利用したアプリケーションの開発時には「nanoTimeの値が更新されている=発音が続いている」わけではないことに注意が必要です。


さて、この機能があると何が嬉しいのか、といった点について考えてみます。


= ほいで、ゲーム開発などに使えそう?→調べてみる =

タイムスタンプが取得できたところで、有効に利用できなければ意味が薄いです。今回は、ゲーム開発などのシーンにおいて活躍してくれそうな機能か否かを検討するべく、いくつかの負荷条件下での比較をおこなってみました。

使うサウンドは、先日のPlaygroundハッカソンで@mhidakaさんが作ってくれた「進捗だめです.mp3」(2216ミリ秒程度)です。進捗だめでした。
オーディオ再生、タイムスタンプ取得周辺のスニペットは以下のとおりです。


今回は単純化のために、AudioTrackをSTREAMモードで利用し、事前にbyte列へ読み込んだwavデータ(lame --decodeにてMP3からデコードしたリニアPCM; 16bit-mono)を投入しています。最後のサンプルまで再生されたらリスナでイベントを受け取り、AudioTrackの停止をおこないます。これに割と雑な定期タイマーを組み合わせて(なるべく)定期的にログを取得します。

これをNexus 5で実行すると、以下のようにタイムスタンプが更新されていきます。




なお、AOSPベースの4.4を焼いたGalaxy Nexusではタイムスタンプ取得機能がサポートされておらず、AudioTrack#getTimestamp(AudioTimestamp)がfalseを返します。これがハードウェア上の制約によるものか、ドライバの作り込みによって回避できるものかについては調べられていません。


これを単純に4回計測してデータ処理した結果は以下のとおりです(Nexus 5, 4.4/KRT16M, 単位はミリ秒, 以下同)。

平均サンプリング成功回数
85
最大値(最も性能が良い)
-1
最小値(最も性能が悪い)
-23
最大値-最小値の平均
19.75
中央値の平均
-12
すごい! 優秀ですね。特に最大値と最小値の差が22ms程度に収まっているのはなかなか良いです。そして、今回の計測系では理想的に実行した場合85回程度の処理がおこなわれることも分かります。

この結果が理想的なパターンでのものですが、実際のAndroid端末では

  • 同プロセス内で複数のスレッドが実行されている
  • 他のプロセスにて処理が実行されている

のが普通です。これらがどのような特性変化をもたらすのか、もう少し調べてみましょう。

まずはプロセス内に重い処理(ゲーム実行本体などを想定)を抱える場合を想定し、以下のコードを追加してみます。

プロセス内(Dalvik)に重い処理がある場合
平均サンプリング成功回数
60
最大値(最も性能が良い)
0
最小値(最も性能が悪い)
-21
最大値-最小値の平均
19
中央値の平均
-10


スレッド間のスイッチが発生するためかサンプリング回数は低下していますが、基本的には最初の結果と同様の傾向を示しています。

それでは、外部に重い処理を追加してみます。

= 外部の負荷源を導入する =

今回は手軽に負荷を発生させるために、どこのご家庭にもあるLuaのJITコンパイル対応版実装のLuajitを利用しました。


1|shell@hammerhead:/data/local/tmp $ ./luajit -e "i = 1 while true do i = i + 1 end" &
このようにして無限ループを作り、バックグラウンドで6プロセス走らせます。
CPUをぶん回してますね。この状態でホーム画面などを操作するとかなり引っかかりがあり、使い勝手がかなり落ちています。
「あー端末重いわー、つらいわー、再起動したいわー」という状態よりも更に行き過ぎている感がしますが、古めの端末ではよく見かける状況なので気にせず進みます。

プロセス外に重い処理がある場合
平均サンプリング成功回数
56.75
最大値(最も性能が良い)
0
最小値(最も性能が悪い)
-50
最大値-最小値の平均
32
中央値の平均
-11.75


明らかにオーディオここで"最大値-最小値の平均"に注目してください。さきのふたつの結果よりも明らかに増えています。一方で"中央値の平均"はあまり変わっていません。これは「概ね良い結果を出しているが、時折大きく外れた結果につながる」ことを意味します。
ただし、これはAudioTrack#getTimestamp(AudioTimestamp)の性能が悪いことを意味するものではありません。「Androidでは、アクティブなアプリケーション以外がCPUを一定以上消費している際に、アクティブなアプリケーションの反応も一定以上悪化するケースが多い」ことを示すのみです。とはいえ、これ自体がゲームなどの実行環境として不向きには違いありませんが…。
ちなみに定性的なものですが、計測中に可聴ノイズは特にありませんでした。オーディオを出力するという基本機能はしっかりと維持しています。

さて、最後にプロセス内が重くプロセス外も重いという二重苦状態も試してみます。

プロセス外に重い処理があり、プロセス内(Dalvik)にも重いスレッドがある場合
平均サンプリング成功回数
4.25
最大値(最も性能が良い)
-1
最小値(最も性能が悪い)
-100
最大値-最小値の平均
33
中央値の平均
-12.25


サンプリング成功回数の激減からお察し下さいという感じがしていますが、かなり重い状態です。ここで初めて計測中に音が飛ぶ形の可聴ノイズが数回確認できました。明らかにCPU時間不足です。今回の実装においてユーザ側からは全てのオーディオサンプルを事前にプラットフォームへ渡してあり、バッファキュー追加処理類はおこなっていないため、この挙動は少々不可解です。Androidプラットフォームの実装に優先度制御の甘い箇所があるのかもしれません。
ここで特筆すべきは"最大値-最小値の平均"と"中央値の平均"が共にひとつ前のものとほとんど変わらないことです。これは「CPU性能が足りず音飛びが発生するような環境においても、一定以上の精度でタイムスタンプ取得が可能」という特性を意味します。表中で最も性能の悪いケースで100ミリ秒程度の差が生じているのは、おそらくタイムスタンプ取得後に比較用のSystem#nanoTime()実行までの間にDalvik内のスレッド切り替えがおこなわれたなどの事情によるものでしょう。

= まとめ =
以上の4つの計測結果をまとめると以下のようになります。
状況
理想的
内部高負荷
外部高負荷
内外高負荷
平均サンプリング成功回数
85
60
56.75
4.25
最大値(最も性能が良い)
-1
0
0
-1
最小値(最も性能が悪い)
-23
-21
-50
-100
最大値-最小値の平均
19.75
19
32
33
中央値の平均
-12
-10
-11.75
-12.25


  • 基本的に、取得できるタイムスタンプは信用していい
  • アプリ内・アプリ外が共に高負荷である場合、Androidのサウンド出力自体はまだ甘いらしく、アプリ側での補正が必要
  • 新しいアーキテクチャの低スペック端末などで音飛び/フレーム飛びを補正する上での手軽な策として割と使えそう

= NDKに恩恵は…? =
NDKでバリバリ書かれたものについてはどうなるんだろう、何か効果あるのかな?ということも気になりますね。
ありません。

そもそもJava側のAudioTrack専用の機能なので、Low Latency Audio出力などを視野に入れたOpenSL|ESでの実装系では提供されていません(Android NDK r9b時点)。
そもそも、NDKベースで開発する場合には、ある程度自由なスレッド優先度制御が元々可能であること、バッファキューを利用する場合にはそれなりの精度(概ね10ms未満程度)で現在処理中のバッファ位置を推測できることから、あまり使い道が大きいとも言えないのが実際のところです。
とはいえ「バッファキューへ複数のバッファを積んでいる状態でどこまでが実際にスピーカなどから出力されたか」という点は従来提供されてきた機能では推測することしかできなかったため、将来的にNDKに類似機能が提供されると一定のユーザ体感改善へ寄与するものと考えられます。

以上、「AV同期のためのオーディオタイムスタンプ取得機能」について述べました。

以下は蛇足です。

まず、本機能が実装された背景を少々推測して書いてみます。
まず、端末性能の全体的な向上が挙げられます。これによりDSPにデータを流すだけでなく、一定はOSでの処理を介在させてもユーザ体感を損なわない下地ができてきたのでしょう。また、OS自体の最適化により余裕が生まれたということも考えられます。特にサウンドまわりは、4.1からだいぶ良くなってきたので、サウンドチップ周辺からユーザランドへ情報を戻すような機能を実装しやすくなったのではないかと考えられます。

「動画の再生中に解像度変更を伴う動的なストリーム変更ができるようになった」件
そういえば、前半で書いていた本件について少々触れておきます。
本機能を調べ始めた@muo_jp氏(28歳)によると
「この機能を使うにあたってはプラットフォームにサポート有無を問い合わせる必要があります。当初エミュレータで調べていたところ、以下のような調査コードが
String[] types = codecInfo.getSupportedTypes();
for (int j = 0; j < types.length; j++) {
  MediaCodecInfo.CodecCapabilities ccp = codecInfo.
    getCapabilitiesForType(types[j]);
  boolean isAdaptivePlaybackSupported = ccp.isFeatureSupported(
    MediaCodecInfo.CodecCapabilities.FEATURE_AdaptivePlayback);
  String supportStatus = "adaptive playback is " +
    (!isAdaptivePlaybackSupported ? "not " : "") +
    "supported for " + types[j];
  Log.d(TAG, supportStatus);
}
平然とfalseを返してきました。おっふ…。さすがにエミュレータだとメディア系が諸々弱そうだから使えないか。

それではAOSPベースのGalaxyNexusではどうかなーと考えてhttp://blog.sola-dolphin-1.net/archives/4566598.html で配布されていたものを利用してみたのですが同じくfalse。
そうだよねー、メディア系は割とAOSP実装と商用実装で各種コーデックが異なるとかあるよねー。
こういうのはちゃんと商用実装で確認しよう的なやつだ。

ということでNexus 5(4.4, KRT16M)で試した結果…
adaptive playback is not supported for video/mp4v-es
adaptive playback is not supported for video/mp4v-es
adaptive playback is not supported for video/3gpp
adaptive playback is not supported for video/avc
adaptive playback is not supported for video/x-vnd.on2.vp8
adaptive playback is not supported for audio/3gpp
adaptive playback is not supported for audio/mp4a-latm
adaptive playback is not supported for audio/amr-wb
adaptive playback is not supported for audio/flac
adaptive playback is not supported for video/x-vnd.on2.vp8
adaptive playback is not supported for audio/mp4a-latm
最新開発者向けフラッグシップ端末も平然とfalseを返してきました。oh... 詰んだオワタ、まだ人類には早すぎた。

Xperia系とか、メディア周りの実装がしっかりした端末が4.4にちゃんと対応しないとこれ無理なんでないかという感がしている」とのことです。

Android 4.3来たにゃー 気になる点メモと他雑感

2013年7月25日木曜日

Android 4.3がついに。 http://developer.android.com/about/versions/android-4.3.html

事前情報からあまり外れないけど、やっぱり気になるところはある。


  • restricted profile environmentというのが増えてて、例えば標準ブラウザにすらアクセス出来ないモードとかも出来るようになった(多分iOS 6でのguided accessと同じで、店頭端末用とか企業利用向け及びペアレンタルコントロール用だよね)
  • HTTP経由のメディアストリーミングで、データの暗号化を行いやすいようになった(4.3主流になる頃≒2年後?には使えるかな)
  • DRMのための仕組みが、10バージョンぶりぐらいに強化された。 http://developer.android.com/reference/android/media/MediaDrm.html (同上)
  • OpenGL ESのサーフェスを動画へエンコード出来る機能をサポート(検証系に嬉しい感じする)
  • OpenGL ESで、テクスチャ圧縮を結構まともにサポート。これはGoogle Playでの配布時にMultiple-APKsの条件へ指定出来るので「端末ごとに割と最適なフォーマットで、配布時に重複の無駄なく」ということを実現しやすい。関連はここ http://developer.android.com/guide/topics/graphics/opengl.html#textures
  • 普通のBitmapに、mipmappingが適用出来るようになった。CPU遅めな端末で嬉しいケースあるかもだけど、動的なスケーリングを行うケースってそんなにあるのかな? res/以下のプロファイル切り分けを直接代替するものではないので利用には注意が必要そう
  • 画面回転時のエフェクトが指定出来るようになった(iOSへ少々追いついた感じある)
  • UI操作の自動テストを支援するAPIが追加された。backとかhomeキーのマッピングもあったりと、これは大量の画面がある場合の遷移チェックなど、開発に役立つ感じする http://developer.android.com/reference/android/app/UiAutomation.html
  • アプリ側からsystraceの有効/無効を指定出来るようになった。printfデバッグ仕込むノリでsystrace切り替えられるのは、パフォーマンスしっかり見つつアプリ改善する上で嬉しい
  • "Android Key Store"という、アプリごとに個別の秘密鍵ストアを持てるようになった。これ応用してiOS的なキーチェーン実現出来るのかな?アプリのアンインストール&再インストール時のデータ揮発性など要調査
  • ハードウェアでの秘密鍵生成器/保持器サポート。これは未来が来てる感じ。OS自体の対応はスタート地点でデバイス側対応が重要になるけど、諸々のセキュアエレメントを秘密鍵ストアとして駆動出来るようになるとDRM捗る


----

変更を分類して所感とともにもうちょいメモ。

  • 今日から開発に嬉しい系
    • UI操作の自動テスト(エミュレータ組み合わせてCIが非常に捗る)
    • systraceのアプリ側からのon/off
    • OpenGL ESのサーフェスをがっつり動画に記録して端末動作検証など(これ自体のパフォーマンスインパクトがそれなりにありそうなので、開発用のハイエンド機以外では逆に厳しい感じもする)
  • 新しい仕組みでデモ作ったりすると未来見えて嬉しい系
    • ハイエンド端末でのOpenGL ES 3.0デモ。Galaxy S4とかで扱うと「えっ、モバイルでここまで出来んのSUGEEE!」な感じ出せてよさげ。S4のbig.LITTLE対応Google版はよ(※big.LITTLEは浪漫)
    • Bitmapをうまく使ったデモとか、案外映えるのかもしれない。mipmappingが有効な 奥行きのあるものを、ということになるけど結構鬼門な気がするなー
    • セキュリティ系の技術デモとしては、USBでつないだRSAドングルあたりをLinuxのドライバきちんとつなぎこんでAndroid(AOSP)に手を加えて認識させ、かなり安全な鍵管理を実現(ただし端末盗難に弱いというオチ付きで)という感じのネタやりやすいかも
  • すぐに反映出来て、対応端末ではちょっと未来嬉しい系
    • 画面回転時のエフェクトとか、ゲームではちゃんとしていたほうが嬉しい場面あるので、少数ユーザでも4.3な人々がヾ(*´∀`*)ノキャッキャ出来るものを早めに出せると良いのかも
    • 圧縮テクスチャの強化もこのへん。x86なAndroidが多少なりとも伸びてくるであろうことを考えると、結局Multiple-APKsを使いこなしていかないと配布サイズ的に厳しい局面増えてくる。早めに実戦投入しておくと、シェア伸びてきた際に慌てなくて済むという意味でも早期に開発成果物としてのapk群をほどよく生成出来るパイプラインを作り込むのは大事な感じ
  • 2年後ぐらい、バージョンシェアが十分に伸びてくると新サービスへ積極的に使えて嬉しい系
    • メディアストリーミングにおける暗号化サポート
    • DRMのフレームワーク強化(DRM対象にしたいメディアって、やはり対象のユーザベースが広くないとどうにも話にならないケースが多い。面展開のメリットが出てくるまでは準備期間と位置づける)


一番お金になりそうなエリアは、一番バージョンシェアが必要というね。そらそうですね。「過去18ヶ月以内に発売された端末については、端末メーカーをGoogleが資金面でも技術面でも徹底サポートして、むこう6ヶ月以内に4.3対応アップデートを配信する」ぐらいの男気対応があれば、きっと移行は否応なしに進むんですけどね。あっ、アップデート保証プログラム…(察し)。厳しいですね。こういうエリアはGoogle Play Servicesでカバーする流れになっているので、コンテンツ保護系はPlay側の強化と共に歩んでいくことになるんでしょう多分。

蛇足ですが全体的にメディアフォーマットとしてMP4を標準と扱ってる節があって、WebMどこ行ったの感がしてますが まあChromeからもサポート外すと言いつつずっと乗ってますし今のところこんなもんでしょう。デファクト兼デジュールスタンダード強し。

超主観まとめですが、間違いなどあれば指摘頂けると幸いです。

積読消化メモ: スマートフォンアプリのためのUI&グラフィックデザイン

2013年6月23日日曜日

Amazon.co.jp: スマートフォンアプリのためのUI&グラフィックデザイン: 中野 広明: 本

2011年の6月、出たてに買ってパラパラ眺めて積んでた。ようやく読んだのでメモ。
概要についてはさほど説明要らないかな。タイトルの通りのことを書いてる本。

= 読み方 =
  • 「たまに引っ張り出してきても良いかもしれないけど、基本的にはもう読まない」という程度まで
  • 逆に、ソラかつドヤ顔でこの内容を喋れる程度に習熟することは目指さない

= 気になったポイントメモ =

== Chapter 01: 理論編 ==
  • ちょっと前のスタンダードをまとめた感じ。AndroidのUIガイドライン、今はもうちょいまともだよね
  • さほど(改めて)読むべきことは無いかな
    • webOSのUIガイドラインあたりも載ってるあたりが洒落てていいね
    • ここではAndroid標準のUIガイドラインの出来が著しく悪いという話を書いてあるけど、本が出た後に割と改善されてきた箇所なので割り引いて読むのが良いね
  • ビジュアルスタイルの項(p.34-p.39)は、そこそこ「どんな種類のUIにしたい?」という問いへの答えを楽にしてくれそうなので良い
  • ワイヤーフレームとデザインプロトタイプの違い: ワイヤーフレームは色も細部描き込みもしていないもの。デザインプロトタイプを提示するタイミングが早すぎる構成/コンセプト確認からビジュアルデザイン議論へと発散してしまう。ここへ落ち込まないように目的をはっきりさせるためにワイヤーフレームおすすめ
== Chapter 02: 実践編 ==
  • p.56に載ってる配色サイト/アプリ一覧は割と使えるかも。色弱シミュレーションとか 軽くCIに組み込んでおくと良いかもという感じする
  • ボタンのグラデーションについて
    • 始点と終点の色相は同じ、角度を90度(上下)として明度差により立体感の強弱をつける
    • 押し込まれた状態の表現には、始点と終点を逆にして明度を少し下げる
  • Androidでの9patchについて
    • 左右の拡大場所は複数指定することも出来る
      • たぶん余った領域分だけ均等に伸びることになる
  • アイコンデザインについて
    • モチーフの種類は主に4つ
      • 類似アイコン
        • アクション伝える向き
      • 例アイコン
      • シンボルアイコン
      • 記号アイコン
        • シンボルとの違いは、歴史的や伝統的に意味が一般化されているもの(&意味と記号に図形的な関連性が無いこと)
    • キーワード連想などをもとにモチーフを選び、組み合わせる(ただし多く組み合わせるといみふなので2つぐらいに絞る)
    • 絵を描く必要があるなら、工業製品などの人工物をモチーフに選ぶのが楽。素材の感じを表現出来るような描き込みを頑張る
    • 丸なアイコンよりも四角なアイコンを小さめに作るガイドラインの意味: 四角のほうが大きめの印象となるため(あー、そう言われれば当たり前だわ)
== Chapter 03: テンプレ編 ==
  • PowerPointでワイヤーフレームを作る話ほか。2.3あたりのガイドラインベースなのでちょいきつい感はあるけど手軽ではあるかな。4.0版どこかに無かったっけね

= 小学生並みの感想 =
  • デザインの理論的や脳での認識的な話が時折絡んでくるんだけど、あまり馴染み無いので読んでて面白い
  • 文章から受ける全体の印象(別にdisってるわけでもなんでもなく、ただの印象)として「TLによくいる人が喋ってる感じ」。typoは少々気になるけど気にすると読み進むスピード落ちるので無視。別に論文じゃないので「〜と思います」連打なのも目くじら立てる場所じゃないやね
  • あんまり技術的に正確な言葉遣いではないので、雰囲気でカバーするの大事(アルファチャンネル付きのいわゆるフルカラーなPNGをPNG-32ではなくPNG-24としてるあたり、多分Photoshop度の高い方が書いてるんだろうなという感じ)
  • Photoshop/Illustratorフェーズは、実際に独力でアイコン作成とかをやろうという時までは読まなくてよさそう。ただ、関連するガイドライン的な部分は抑えておいたほうがいい
  • GIMP/Inkscape用のテンプレもあったり、一応の作成方法解説もあるので、実際作る時には活用したい

  • 「気になったポイントメモ」にも書いたけど、Android標準のUIガイドラインの出来が著しく悪いという話については本が出た後に割と改善されてきた箇所なので割り引いて読むのが良い
  • デザイン指針の流行り廃りについては本文中で触れられてる通り。PUMA Phoneってあったんだーというのをそもそも知らなかった

「きつねさんでもわかるLLVM」前半で見つけたtypoメモ

2013年2月15日金曜日

きつねさんでもわかるLLVM
柏木餅子, 風薬
達人出版会
発行日: 2013-02-08
対応フォーマット: EPUB, PDF

この本。先週買って職場往復時間に少しずつ読み進め、本題のLLVM IR生成部分手前まで来て一息ついたのでtypoメモ共有。意味的にやばい間違いとかは特になさげでした。読んでて気になったとこだけ書いてるので漏れあるかもしれません。

先頭の番号は、epub→mobi変換してKindleで付加されるインデックス的なものです。pdf版と対応付けて書こうかとも思ったのですが面倒だったのでやめました。β版なので改訂されることを期待してのんびり待ちましょう。

この思い、著者さんに届け!

  • 1177: 検討→見当
  • 1181: Medata→metadata、MetaData→Metadata
  • 1196: MetaData→Metadata
  • 1302: 捜査→走査
  • 1647: 勘数→関数
  • 1689: doParser→doParse
  • 1694: 実効→実行
  • 1918: 入れま→入れます
  • 1974: 同名の関数名→同名の関数
  • 2022: visitPorotype→visitPrototype

今のところ、ポイント押さえて書かれていて大学の授業教材にも良いんじゃないかなーと思いながら読んでます。

Evernote Hackathon in Tokyo( #enjphack )に参加してきた(1)

2013年1月27日日曜日

または、Titanium Mobileつらぽよい話。
Evernote Hackathon in Tokyo を開催します (1/25 19:00 - 1/27 14:00)というblog記事を見かけ、半ばダメもとで応募したら当選してたので参加してきました。

Evernote APIについては、Evernote APIを使ったAndroidアプリを作る(1) な記事を書いたりと以前から興味を持っていて、昨年のEvernote Devcupへの参加もかなり本気で準備していたのですが形に出来ず 悔しさが残っていました。

組んだチームの話や開発したものの話は改めて書くことにして、今回は自分では初めて開発に使ったTitanium Mobileについての所感的なものを軽く書いてみます。

今回のハッカソンでTitanium Mobileを使った理由は、

  • iOSネイティブアプリを作りたかった
  • UIデザインと開発を切り分けて並行作業したかった
  • チームメイトが、これを使ってアプリを開発した経験を持っていた
  • 万能薬というよりは、最低限のものを共通コード基盤で複数プラットフォームに向けて作るためのものという認識だったけど、実際に使ったことは無かったので使ってみたかった
  • JSなので、辛くてもまあ最終的にはなんとかなるだろうと考えた
というあたりです。


Titanium Mobile、JSでネイティブUI要素を書いていくことが出来る点はとても良いです。UI設計/組み込みと開発の作業分担についても、JSベースなので従来から慣れていれば新しいことを覚える必要がない点はとても良いです。しかし、最新版(3.0.0)のTitanium Studio(とそのツールチェーン)は厄介な問題を抱えてます。以下は、iOS実機(iPod touch 5th gen)用にプロジェクトをビルドした際に生成されるApplicationRouting.mというファイルの一部です。どうもJSとPNG等のアセットをまとめて突っ込んである領域のようです。


-- お分かり頂けただろうか?拡大してもう一枚。

諦めるなよ!!諦めるなお前!! どうしてやめるんだ!!そこで!! もう少し頑張ってみろよ!!駄目駄目駄目駄目

つまりJS系での実行用データをObjective-Cのソースファイル内にパックして詰め込んでる箇所なのだけど、途中で生成を諦めてます。これはどう頑張ってもビルド出来るはずがない。
これをなんとか解消しないと実機テスト出来ない(Xcode用のプロジェクトファイルは生成されるけど、これはTitanium Studioから生成されたコードのビルドをするだけ)わけで、少し調べてみました。けれど再現方法を絞り込んでいる最中に 同Mac上・同コードで挙動が変わったのを見て心折れました。 iOS: Build - Titanium mobile project fails to build intermittently というタイトルで既に登録されていたものの再現性イマイチで問題としてはスルーされる方向にある感。
実際、Titanium Studioからのシミュレータ実行(ベストケースで15秒、中央値で30秒ぐらい)、実機実行共にファイルとしての保存タイミングとビルド&シミュレータへ投入した際のファイル版がイマイチ一致していない気もするし、まだまだだなーという印象でした。Eclipseベースなのでプラグインそのまま使えて、Vrapperとか投入出来るのは良いのだけどね。

Titanium Mobileを触ってアプリをひとつ開発した結果、Objective-C/Cocoa Touchの良さを再認識出来た気がするので取り急ぎObjective-Cの勉強に戻ります。