2012-04-26

as3c2dm を使うときに、送信側が使うパラメータ

Adobe AIR で Android アプリを開発できるんですが、そのアプリに C2DM で通知しようとして手間取ったのでメモ。

as3c2dm というライブラリを使うのを想定しています。

結論から言うと、C2DM サーバに送る POST パラメータには、
  • data.parameters
  • data.tickerText
  • data.contentTitle
  • data.contentText
を含める必要があります。

アプリから Google のC2DM のサーバから Registration ID を受け取るときには、ActionScript で onRegisterd() 関数を定義しておきます。通常は、この関数の中でどっかのサーバに Registration ID を登録するような処理をします。

Java レベルでは BroadcastReceiver が、com.google.android.c2dm.intent.REGISTRATION というインテントを受け取ったら、onRegisterd() を呼び出します。

ところが、C2DM サーバからメッセージデータがプッシュされたとき(インテントは com.google.android.c2dm.intent.RECEIVE)の関数定義が、サンプルにはありません。onMessage() みたいなのを呼び出すこともない。で、ソースを見てみると...

public class C2DMBroadcastReceiver extends BroadcastReceiver {
     // ...
     @Override
     public void onReceive(Context context, Intent intent) {
          if (intent.getAction().equals(
            // ...
          } else if (intent.getAction().equals(
                    "com.google.android.c2dm.intent.RECEIVE")) {
               handleMessage(context, intent);
          }
     }
 
     // ...

     private void handleMessage(Context context, Intent intent) {
          try {
               // ...
               String parameters = intent.getStringExtra("parameters");
               CharSequence tickerText = intent.getStringExtra("tickerText");
               CharSequence contentTitle = intent.getStringExtra("contentTitle");
               CharSequence contentText = intent.getStringExtra("contentText");
// ...

待てやコラ ヽ(`Д´)ノ

この後、Notification オブジェクトを作って、端末に表示する処理が入っています。

なんで onRegstered() と同じレイヤで受けられるようになってないのか、唐突に tickerText じゃねーよなどと思ったわけです。が、事情をよく分かっていないのでなんとも。Notification とか Toast ってプラットフォームの機能なので、ActionScript からアクセスできないか、アクセスが大変なのかも知れません。

C2DM を受け取る処理の置き場所

Android のプッシュ通知であるところの C2DM 。この処理をどこに書けばいいのかを調べるのに、えらく時間がかかったのでメモ。

注意: Hello World も書いたことがなくて、クライアントアプリは他の人がやってくれるんだけど、動作確認をしようとした、というシチュエーション。Android やってる人なら、たぶん常識。

Google Developers の Android Cloud to Device Messaging Framework に、必要なことは載っています。困ったのは Handling Registration Results 以下にある onReceive() メソッドをどこに書くのか、ということでした。文章には your application に、としかないし。

このサンプルの場合、マニフェスト XML のなかに
<receiver android:name=".C2DMReceiver" android:permission="com.google.android.c2dm.permission.SEND">
と記述します。なので、メインのアプリ(っていうんですかね? Activity っていうんですかね?)と同じ階層に C2DMReceiver.java を作って、その中に、

public class C2DMReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        //...
    }
    //...   
}

みたいに書きます。

2012-04-16

体重と食事は別のブログへ引越し

あまり知られていないけれど、もともとこのブログは Python に関連する技術的なことや、その周辺のことを書くつもりだったのだけれど、最近狂ったように、体重と食事を晒していて、それは、いかんのではないかということで、 体重とかは http://endorphinmania.blogspot.jp/ で続きを書きます。あっちもこっちも、読者ほとんどいないんだけれど気分的に。

2012-04-13

健康診断を受ける

健康診断を受けてきた。ほとんど流れ作業で、細かいこと、たとえばガンの兆候なんかは分からない、と聞いたことがある。けれど「ちょ、こいつ、末期だろ」くらいは分かるだろうと思って、わりと真面目に受けている。

問診票の回答が我ながらダメすぎて泣けてくる。一部抜粋。
  • 自覚症状 → 太ってきた
  • 1日30分以上の汗をかく運動を週2日以上、1年以上実施していますか? → いいえ
  • 日常生活において歩行または同等の身体分銅を1日1時間以上実施していますか?→いいえ
  • ほぼ同じ年齢の同性と比較して歩く速度が速いと思いますか?→いいえ
  • 20歳の時の体重から10kg以上増加していますか?→はい
  • この1年間で体重の増減が±3kg以上ありますか?→はい
  • 夕食後に間食(3食以外の夜食)をとることが週に3回以上ありますか→はい
  • お酒を飲む頻度 → 毎日
  • 運動や食生活の生活習慣を改善してみようと思いますか? → 近いうちに

人体の前投影面積

スイム 500m 12分。体重 67.4kg、体脂肪率 23.9% 。25m を19から20ストロークで泳げた。前回は少なくとも20ストローク必要だった。これが進歩であることを願う。上半身を沈めて、前方からみて脚を隠すつもりの姿勢をとっている。実際にどんな姿勢なのかは不明。

先日、直方体の前投影面積を計算して、1度傾いているだけで、10%近く抵抗が増える、と書いた。けれど、この数字は直方体の各辺の長さの比率によって異なる。興味があるのは、自分の身体ではどの程度のロスが出るのか、だ。

計算するにあたって、体の複雑な形状や、体の丸みをここではないと考える。悪かったわね、丸くて。概算を出したいのだから、細かいことはいいのである。私の体がコレジャナイロボみたいな形をしていると仮定する。上から見たときの面積 を B、 正面から見たときの面積を C とすると、泳いでいるときの進行方向からの投影面積 A は以下のようになる。

A = B cosθ + C sinθ

自分の体をなんとなく画像で撮影して、概算をだすと、B = 5200 cm^2、 C = 2500 cm^2 程度だった。式に当てはめてみると、


  • θ=0度 ... 2,500 cm^2
  • θ=1度 ... 2,592 cm^2 (+3.7%)
  • θ=2度 ... 2,683 cm^2 (+7.3%)
2度傾くとかなり影響があるので、やはり水中姿勢は重要だ。ちなみに、上から見た時の画像を見ると、おそろしく腹が出ていたので、痩せれば 5% くらい節約できる気がする。



2012-04-12

3本ローラの振動に悩む

以前、ちゃんとトライアスロンのトレーニングをしようと思ったときに、3本ローラを買った。ペダリングやバランスのとりかたなど、自転車に乗るスキルが身につく、はずだ。負荷装置をつけなくても、そこそこの負荷がかかる、はずである。

問題は騒音と振動だ。意外に音が出る。さらに深刻なのは振動で、結構な勢いで響く。騒音動画を公開している人もいるけれど、聞いた感じ振動による騒音だ。(以下の動画は、知らない人のもの)


音とは空気の振動なので、同じことなのだけれど、なんというか自転車やローラ台が、目で見えるくらいの周波数の振動が原因のように見える。ローラ、ペダル(クランク)、ホイールが回りまくるので、床やローラ台の構造と共振するのだろう。

私の場合は、どうもホイールが共振しているように見える。空気を入れるためのバルブの周期と、一番大きな振動の周期が一致しているっぽい。こんど検証してみよう。

それで、みなさん対策を講じているようだ。ただ、どういう条件で、どういう対策が効くのがいまいち分からない。軽微な対応でうまくいっている人もいるし、厚さ10cm 以上の防振剤を使っている人もいる。

ぐぐって調べつつ、 Facebook でアンケートもとっているが、こういうのは普段からコミュニティに入っているほうが情報を集めやすいと思った。自転車友達がいないので(そもそも友達がいないわけで)どうも情報が集まりにくい。(いかの動画も知らない人の)



2012-04-11

おめざ


通勤ウォーク 2.8km 35分。体重 67.9kg、体脂肪率 24.%。小雨がぱらついてたけれど、大したことなかったので、歩いた。


寝付きが悪い上に、寝起きが悪い。早起きした自分へのごほうびを、おめざ、というらしい。残念ながら、台所に向かうことさえ億劫なので、これまでおめざが通用しなかった。しかし早起きの神が降りてきて、名案を思いつきました。枕元に置けばよい。というわけで、たけのこの里で目覚めた。しばらく続けてみよう。

2012-04-10

直方体の前投影面積

スイム 500m 10分。体重 68.1kg 体脂肪率 21.0% 。20 ストロークで安定して25mを泳げるようになってきた。水中姿勢がよくなってきたからか。


1000mm x 500mm x 200mm の直方体を考える。文庫本が巨大化したような形状だ。これを一定の早さで、水中を移動させるとき、文庫本の向きがどの程度影響するかを考えてみる。

文庫本を倒した状態で、文庫本の底(500mm x 200mm の面)を進行方向にすると、一番抵抗が少ない。流体を進むときの抵抗の大きさは、速度×面積に比例するからだ。文庫本の表紙の面を進行方向にすると、かなり抵抗が大きい。



文庫本を真横に倒しているときが抵抗が少ないわけだけれど、すこし傾いているときはどうだろう。水中で(私のような)ヘタクソが泳いでいると下半身が沈んでいる。文庫本にもこういう姿勢を取らせて、水中を進む場合を考える。このとき、水の抵抗を受ける前投影面積 A は次の式で得られる。

A = 500 x (200 cosθ + 1000 sin θ) [平方ミリメートル]

θ(シータと読む)は傾いている角度だ。これを計算すると、


  • θ=0.0° ... 100,000 [平方ミリメートル]
  • θ=0.5° ... 104,359 [〃]
  • θ=1.0° ... 108,711 [〃]
となる。体が1度傾いているだけで、8.7%も抵抗が大きくなるのだ。なかなか進まないわけである。バルス。




2012-04-09

トレーニングのケア不足を指摘される

トレーニングなし。体重 67.7kg、体脂肪率24%。



整体の費用対効果に疑問を持ったわけだけれど、ランの後で、整体に行ったら「あれ?走ったりしました?」と聞かれた。はい、と答えると、ケアができていないので、いつもよりかなりカタいと言われた。仕事がしんどいから整体に行っているのだ、的なことを書いたけれど、トレーニングもかなりな勢いで影響していたらしい。せめてというわけで、ストレッチをした。

エンデュランススポーツの応援テクノロジ

ラン 4.5km 30分。整体師の心配と、先週の膝の痛みを考慮して、控えめに走る。さぼる言い訳はいくつもある。

一般選手のエンデュランスイベントにおいて、応援に意味があるのか甚だ疑問だ。スタートラインに立った時点で、市民ランナの結果はほぼ決まっている。応援があってもなくても、たぶん結果は変わらない。とは言え、行きたいので行く。荷物持ち、直前まで着ていた上着を預かる、水を持ってくる、ビールを買っておく、うっかり飲んでしまうなど、レースの前後にアシスタントになることには付加価値がある。

けれど、テクノロジがこれを変え始めた。と、ここで、大きく出てみよう。

ニューヨークシティマラソンで、アシックスがやった(金を出した)システムがある。応援する人が、事前に応援したい人当てにメッセージを登録する。選手のシューズには計時用RFIDがついていて、アンテナがあるところを通過したら、誰がいつそこを通過したか分かる。そこにスクリーンがあって、各選手宛の応援メッセージが液晶パネルに出る。

フルマラソンの、しかも人気大会の応援はすごく大変だ。だいたい、何時間もコース近辺にいるとか、時間効率が悪すぎる。上の応援システムがあれば、手軽に応援を届けることができる。

東京マラソンも各選手の5kmごとの通過タイムが、ほぼリアルタイムでネットで公開される。八重洲でビールを飲んで暖をとりつつ、15km通過したみたいだから表に出よう、みたいなことができる。

RunKeeper の有料会員になると、GPSで取得した現在地をひたすらウェブにアップロードするオプションが使えるらしい。Google latitude でも、友達を探すでもいいんだけど、エンデュランス系スポーツで現在地を公開するというのは、応援をしやすくする。

あと、走りながら Twitter とか、原始的だけれど楽しい。30knから本気出す、
折り返しでもいってたやん!みたいな。そういうコミュニケーションがなくてもマラソンは楽しい。ないほうが楽しいときや、そういう人もいる。けれどコミュニケーションがあると、より楽しい場合がある。応援というより、実況と突っ込みみたいなコミュニケーション。飽きたらやめるし、見なければいいっていう気楽さ。今年のレースでやってみたい。

などということを、ハーフマラソンの周回コースの傍らで考えた。あ、もうすぐゴールのようです。



プレゼンとマジック - 森博嗣「タカイ×タカイ」

森博嗣の X シリーズ 3 作目「タカイ×タカイ」の文庫が出ていたので、読んだ。

マジックって、たしかに、観客に何かが起こっていると見せかけるけれど、それって、実際に起こっていることを隠すためのものですよね。

真鍋瞬市が、高いポールの上に死体があったことに対して、死体を見せたいからではなくて、別のことから目を逸らしたいからでは、と、疑問を投げるセリフだ。実際がどうたったかは、読んでのお楽しみ。



ここから我田引水。プレゼンをするときにも、この手法は使えるだろう仮説。少なくとも私は今まで使ってきたし、これからも使うと思う。

場合によるけれ聴衆に何かアクションを起こして欲しいとき、何か変化を起こさせたいとき、伝える側がフォーカスして欲しいことに、聞き手にフォーカスさせたいことがある。そんなとき、嘘じゃないけど、注意の引き方を工夫する。

たとえば新製品や新サービスを発表をするとき。当然だけど、競合できて、自社製品にできないことや劣っていることがある。おそらくそれは戦略上、優先順位が低いから落とした機能だろう。けど、状況によっては(メディアや顧客は大事だと思い込んでいるかも知れないけど、こちらは重要ではないと思っているとか)、めんどくさい形で突っ込まれるかも知れない。そんなときには、100項目もある新機能ぜんぶではなくて、ポイントになる数機能にフォーカスさせるようなストーリィの組み立て方をする。うまくいっているのか、うまくいってないのか分からない。

ところで、そうやって推理小説にうまく騙されたときは気持ちいい。


2012-04-08

サドルの前にずり落ちる

バイク 18 km、59 分。先週と同じコースを軽く走る。先週に比べて楽だったのは、体が慣れてきたからか、単に風が弱かったからか。



バイクのハンドルとサドルのポジションを半年前に出たレース以来ほったらかしである。直線で DH バーを使うのが前提の前乗りポジション。今は、フィットネスレベルがガタ落ちだし、腹も出ているので、こんなポジションで乗ったりしない。ドロップハンドルのブレーキレバーを握っている。すると、どうも尻が前にずり落ちてきて、しんどい。次に走るときには、サドルを少しさげてみよう。あと、サドルがちょっと低い気もする。


2012-04-07

整体の費用対効果

ラン 6.0km 38分。体重 68.1kg、体脂肪率 20.3%。 5kmくらいで膝が痛くなって、フォームが崩れてくる。しばらくは、4km くらいで体を慣らすのがいいかも知れない。


土曜日には整体に行っている。首、肩、腰のどこかがものすごく凝っていたり、痛かったりするので、週に1度ケアをしている。短い時で60分、長い時で120分。間違いなく仕事の疲労なのだけれど、費用対効果は実際のところどうなんだろう。もっと楽な仕事について、給料の下がり幅が、整体の時間と費用よりも小さいなら、そのほうがいい。実際に試すわけにいかないのが悩ましい。

とりあえず10分だけやる


Getting Started Is Everything という記事の内容を実践してみたら、簡単なわりに効果があった。やる気が出ないときに10分だけやる、というシンプルな方法。

... I convince myself to spend ten minutes on my project. Just ten minutes. Enough time to accomplish one small task. Then, after that ten minutes is up, I can go back to zombies, guilt-free, if I so choose. 
The beautiful thing is, I almost never do.
10分だけやってみようと自分に言い聞かせる。たった10分だ。ちょっとしたタスクなら完了するだろう。10分たてば、罪悪感を感じることなく、ゾンビ映画でも見ればいい。 
ポイントは、ほとんどの場合、ゾンビ映画を見たりしないってことだ。

とりあえず10分やることで、なにがしかの進捗がある。記事に書かれているとおり、たいてい 10 分でやめないので、プロジェクトはもっと進む。普段仕事に集中するために、3-2-1 という OS X 用のアプリを使って、いくつかタイマを用意している。ポモドーロ用に25分と5分、とりあえず片付けるための2分、そして、とりあえず取りかかるための10分。


10分のタイマだけは設定の「Bring to front」のチェックを外している。こうしておくと、10分たったときに、まだ集中して作業をしていれば、そのまま続けられる。


とりあえず始める、というのは、すぐやる系の自己啓発本にも書いてあったのだけれど、10分でいいんだ、と思うと気が楽になって、先延ばし屋の私もとりかかれるようになった。おかげで、手付かずのタスクがほったらかしになるのが少なくなった。

気温と体感

スイム 500m 10分。体重 67.2kg、体脂肪率 23.1%。首が凝っていて、左の息継ぎをしにくい。続けているうちに、ほぐれてくることを期待している。根拠はない。

今日は昨日より寒かった。天気予報で最高気温、最低気温を見ても、ほとんどの場合、自分にとってどの程度、暑いのか、寒いのかよく分からない。30度超えたら暑そうだとか、5度まで下がると寒そうだ程度。寒いのは苦手だけど、おっさんが汗かいていると見苦しそうなので、気温に合わせた服装で出歩きたいものだ。

2012-04-05

ハートレートモニタのトランスミッタで負傷する

通勤ウォーク 2.8km 27分。 体重 67.6 kg、体脂肪率 23.0%。気温が17度あって、コートを着ていると汗をかいた。このくらいの季節は歩いたり、走ったりするのに適している。もう少し暑くなると、喉が渇くのだろう。


この間、ハートレートモニタのトランスミッタの下あたりの胸に、擦り傷があった。太るとこんなところが擦れて怪我するのだなぁ、と呑気に思っていた。しかし、トランスミッタの電池の蓋の溝が、ギザギザになっている。電池を交換するときに、10円玉で溝をなめたからだ。負傷したのは、太ったからではなくて、ギザギザだったからだ。ヤスリで平らにしておいた。


2012-04-04

RunKeeper を使い始める

通勤ウォーク 3.6km 33分。体重 67.1kg、体脂肪率 23.8 %。歩いても、信号でちょっと走っても、ふくらはぎは痛くない。けれど階段を登ると痛い。ランで痛めたわけではなさそうだ。バイクでふくらはぎなんて痛くならないので、生活習慣の問題のような気がしてきた。


RunKeeper を積極的に使い始めた。これまでは気が向いたときに、ランを記録するだけだった。久しぶりにアクセスすると、スイムの練習を記録できるようになっていた。RunKeeper を避けていた最大の理由が解消されたことになる。

他にも睡眠記録、栄養記録、体重記録、ソーシャルゲームなどのアプリケーションが、RunKeeper に連動している。ということは、と調べてみたら API が公開 されている。ポータルもドキュメントもそれなりに整備されているようだ。

2012-04-03

右のふくらはぎが痛い


スイム 500m。ストロークを数えている。25m あたり 20ストロークくらい。15 くらいでいけると速いんだとおもう。先は長い。

駅の階段を降りていて、右のふくらはぎが少し痛いことに気づいた。急に走り始めたからよりも、それとも生活習慣に問題がありそうだ。たとえば座っているのに、足は床に対して爪先立ちをして、力が入っているときがある。腹筋が弱いとか、そういう理由で、こういう変な姿勢をとっているのかも知れない。と、姿勢を正してみたら、腰が痛くなってきた。どうしろと。


Python を使った開発の技術とプラクティス - ビープラウド / Python プロフェッショナルプログラミング

ビープラウドによる「Python Professional Programming」が出版されたので、早速、購入。「Python を使ったウェブサービス開発のプロセス、ツール、プラクティス」がまとまっている。

ビープラウドでは、定期的に社内での情報共有を目的にした「BPStyle」という集まりがあります。誰かがこの本は BPStyle なんだよ、と言ってたような、言ってなかったような気がする。

たとえば「Chapter 10 環境構築とデプロイの自動化」を見てみよう。技術的には、Debian 系パッケージのインストール、dpkg -l 、 pip freeze 、Fabric の簡単なチュートリアルと、簡単なレシピになっている。ググればすぐに出てくるし、ヘルプやドキュメントを見れば分かるような内容だ。

が。

ユーザの作成、MySQL、nginx などのインストール・設定、この章までに使った pip によるパッケージインストールをして、構築とデプロイの手順をまとめて、手順書から環境ごとの fabfile.py を作る、という一連の流れを説明したような文書は、なかなかない。少なくとも、私はググっても見つけられなかった。

そういうプラクティスが詰まっている本なのだ。私がビープラウドにいた時にやっていたこと、やっていなかったこと、アップデートしていることなどいろいろある。

この本は、ふつうに自腹で購入しているのだけれど、以前の勤め先なので贔屓目じゃないか、と言われたら、否定はできない。ちなみに、今の同僚が、この本を読んだ感想は「古川はビープラウドにいたんだなぁ」とのこと。全部とは言わないまでも、あそこで学んだことは生かせているらしい。



ってか、この本を先に読んでたら、Jenkins であんなに苦労しなかったのに! ひどいよ、さぼてんまん!

2012-04-02

凝っていることに気づく

回復日につき、トレーニングなし。67.6 kg、25.5%。回復日と言うと、サボっているのではなく、わざわざトレーニングをしていない感がある。実際がどうであれ。

 

最近、整体に通っている。肩こりが酷くて、気分が悪くなったので、これはやばいと行き始めた。最大の発見は、肩や背中よりも、腰や脚がはるかに凝っているということだ。言われてから意識するようになると、たしかに脚が疲れている。座り方をちょっと変えるだけで楽になったりする。

長い年月をかけて、少しずつ凝ってきので、意識しないと気付かないのだろう。肩が凝る、という言葉がない言語圏の人たちは、肩が凝っていることに気づかない、というまことしやかな噂がある。本当か嘘かはしらなけれど、ありそうな話だと思う。肩が凝るという言葉を作った、夏目漱石は、日本人の認知に大きな影響を与えたという意味で偉大だと思う。あ、福沢諭吉は、もっと。

2012-04-01

慣れないことをすると段取が悪い

バイク 18km。半年ぶりに乗った。ブレーキも変速もちゃんとできた。チェーンにうっすら錆が出ている箇所があったので、注油して拭き取り。



普段、バイク(自転車のこと)に乗っていないと、出かけるまでの段取りが悪くて、効率がものすごく悪い。着替えて、バイクを玄関にだそうとして、あ、空気入れなければとポンプを出してくる。空気が入ったので出かけようとするが、サングラスどこだっけ?とかなっている。サドルバッグがないことに気づき、予備のチューブや空気入れなどを入れて装着。やっと出かけようとすると、今度は、自宅の鍵がない。とかやっているうちに、30分くらい経過した。

本格的にデブってきた

ラン 4.5km。体重  68.8 kg、体脂肪率 25%


本格的にデブってきたので、運動をしようと思う。年に15回くらい、同じようなことを思うわけですが。今日は決意をした直後なので、強風の中、走ってきた。と、書くといかにも大変な感じがするけれど、スタートとゴールが同じ地点で、風の状況が変わらなければ、追い風と向かい風の積分値はゼロになるので、無風のときと条件は同じだ。横風の影響はあるけれど、しんどさに影響があるほどデブっていない、と信じている。