[Titanium] iPhoneでAdMaker広告を掲載

Titaniumで作ったiPhoneアプリに広告を出す場合、モジュールが簡単に手に入るAdMobが人気ですが、AdMaker(MediaAd)は使えないの?という声も多いみたいです。やってみたら簡単に出来たので、やり方をまとめてみます。

モジュールを使う

下記を落としてきます。

tryden/TiAdMaker – GitHub

titanium.xcconfigを開くと、TitaniumSDKのバージョンが定義されているので、これを自分の好みのものに書き換えます。1.6.1はちょっと微妙ですね。
titanium.xcconfig.png

で、build.pyを走らせるとモジュールが出来上がります。
build.png
build2.png

出来上がったモジュールを解凍して、新しいプロジェクトにこんな感じで配置。
module-1.png

example/app.jsにサンプルがあるので、まずはこれを動かしてみるのがいいんじゃないかと思います。

app.js-1.png

AD_URL、SITE_ID、ZONE_IDはAdMakerでメディアを作るともらえます。
medibaad-1.png

というわけで起動してみるとこんな感じ。
sample1.png

めでたしめでたし。

webviewを使う方法

 ちなみに、AdMakerの公式サイトでは、こんなふうに案内されています。

TitaniumへSDKを実装できません。どうすればいいですか?
SDKでの対応はしておりません。
Web Viewを作って頂き、そこにJavaScriptタグを実装して頂くことで表示して頂くことも可能です。
(よくあるご質問|スマートフォン広告なら「mediba ad」|iPhone、Androidアプリ・サイト広告)

JavaScriptと空っぽのbodyタグを書いたHTMLを用意してwebviewで開いたところ、広告はちゃんと表示されたのですけど、クリックしたあとの広告もwebviewの中で開いて、どうしてくれようかという感じになりました(当たり前ですね)。
webviewのイベントをハンドリングしてあれこれという手も考えられるのですが、あんまりやると広告に手を入れているように見えてしまうことが懸念されます。モジュールが動くのだったら、そのほうがいいんじゃないかな、と思います。

P.S: Android用はこちら。
titanium の AdMaker モジュール作ってみました(Android用) #titaniumjp – harukazepcの日記

ホウレンソウに頼らないマネジメント

sxchu_299380_hourenso.jpg

Twitterのつぶやきを見ていたら、わりと常識に縛られないタイプの方なのに、「新人研修で覚えてもらうのはホウレンソウとプログラミングくらいかなぁ」的なことを言われていて。そういえばホウレンソウって必須でもなんでもないことは意外と知られていないなぁ、と思ったので書いてみる。

ホウレンソウに頼ったAくんの仕事の進め方

  • 9:00 業務開始。朝Mtgで、その日やることをみんなの前で発表。ぼく早くプログラム書き始めたいんだけどな…
  • 9:30頃 昨日の進捗報告に上司からツッコミが。詳細な説明を書いて返信する。
  • 10:00頃 ようやくプログラムを書き始める。
  • 12:00 お昼休み。
  • 13:00 再びプログラムを書き始める。
  • 14:00 今朝のメールに上司は納得しなかったらしく、呼び出された。状況を説明してようやく納得してもらう
  • 15:00 えーと。何してたんだっけ。あれ。このあと進捗会議か。
  • 15:00 さっき上司に説明したばっかりの状況をもう一回みんなに報告。みんな興味ないから聞いてないんだけどね。
  • 18:00 延々と関係のない人たちの状況を聞かされて、ようやく終了。晩御飯食べに行きますか。
  • 19:00 定時後はプログラミングの時間だ!
  • 22:30 今日の進捗をメールに書いてMLに投げる。メールボックスに届いている他のメンバーからの進捗報告は、興味が無いのでまとめてゴミ箱へ。

だいたいこんな感じかと思います。公平を期すため、3時からのラジオ体操とか、11時から健康診断に行かないといけないイベントは省きました。

sxchu_994712_carot.jpg

ホウレンソウに頼らないBくんの仕事の進め方

  • 9:00 業務開始。昨日思いついたアルゴリズムを猛然と書きはじめる。
  • 9:30頃 マネージャさんが後ろを通った気がしたけど、猛然とプログラムを書いていたら通りすぎていった。用事があればまた来るでしょ。
  • 12:00 お昼休み。
  • 13:00 再びプログラムを書き始める。
  • 14:00 マネージャさんが後ろから覗いた気がしたけど、猛然とプログラムを書いていたら去っていった。用事があればまた来るでしょ。
  • 15:00 一休みしていたら、マネージャさんが走ってきた。手が空くのを待っていたらしい。
    「様子はどう?」と聞かれたので、進捗を説明。納得の行かないところにはツッコミが入るけど、説明したら納得してくれた。1vs1の会話だから、所要時間は15分もあれば十分
  • 15:30 再びプログラムを書き始める。
  • 18:00 仕事終わり。スポーツジムによって帰ろう!

かっこ良く定時で仕事を終えていますが、プログラムを書いている時間はAもBも7.5hです。Bくんが超高速で仕事を終えているわけではありません。

sxchu_977756_salad.jpg

進捗の把握は誰の仕事?

じつは、AもBも自分が経験したことのある仕事です。Bは夢物語だったわけじゃなくて、実際にそういうふうに仕事をしていました。ラピュタは本当にあったんだ!(海の向こうに)

  • Aでは、進捗を報告するのがメンバーの責務になっています。Bでは、進捗を把握するのはマネージャさんの仕事です。だってマネージャってマネジメントする人でしょ?
  • 進捗会議で全員の時間を束縛するより、1vs1を繰り返したほうが、進捗把握に係る工数は少なくなります。わかりきっているところはカットできるし、わからないところはその場で聞き返せるので、マネージャさんの理解度も高いです。
  • 進捗を把握するのはマネージャさんの仕事であってメンバーの仕事ではないので、マネージャさんはメンバーの仕事を邪魔しないように、忙しくなさそうな時間を見計らって進捗を聞きに行きます。「忙しいところ悪いけど、進捗を聞かせてもらえるかな?」
    とはいえ、マネージャとメンバーは同じ目標に向かって進むチームなので、メンバーも可能な限りマネージャさんがヒアリングしやすいように協力しますけどね。
  • Bの問題は、マネージャさんが異常に忙しいことです。メンバーが日報を書かなくていいのも、進捗会議に出席しなくてもいいのも、マネージャさんが進捗を聞いて回っているからこそです。
    マネージャさんは大変ですけど、メンバーより多くお給料が出ているんだから、メンバーよりたくさん働くのはとても正しい姿ですよね。

メンバーはお互いの仕事の進捗を知らなくて、マネージャさんだけが全ての進捗を把握することになるので、誰かがコケたときに他の人がカバーすることはできません。
各人の責任範囲が明確で、メンバーの役割がはっきりしている欧米型の仕事の進め方だからこそやれるやり方なのだと思います。
でも、ここで書いたのは、実際にぼくがメンバーとして働いたことのある体験談なので、これで仕事が回っている職場が実在します。というか、日本以外で働いたときはたいていこのやり方でした。

日本式に、メンバーが状況を報告したり、やばい時に自発的に動く能力を持っていることは、別に悪いことではないです。やばい時に自発的にアラーム上げてくれたら、マネージャさんは進捗を聞いてまわる頻度を下げることができるし、メンバーの報告だって下手であるよりは上手なほうが嬉しいに決まってます。
でも、そうじゃないと仕事が回らない状態が常識だと思っているとしたら、世の中そうじゃないやり方もあるんだよ、という話も知っておいていただけると嬉しいです。

関連記事

[Titanium]CFBundleVersion must be no longer than 18 charactoers

個人的なポリシーで、アプリケーションのバージョン番号は、1.0, 1.1, 2.0とかじゃなくて、20110923, 20110925…っていうふうに年月日でつけることにしています。
どこでマイナーバージョンを上げてどこでメジャーバージョンを上げるかとか悩んでも仕方ないし、ユーザーさんにとってはどっちが新しいかさえ分かればOKなんだから、無理に数字に丸める理由はないよね。

というような経緯で俺ポリシーを採用していたら、えらい目にあいました。

理由は知らないんだけど、Titanium MobileはInfo.plistに書いてあるBundleVersionの後ろに、タイムスタンプをくっつけてしまいます。例えばInfo.plistに「1.0」と書いた場合、実際のビルドに使用されるCFBundleVersionは「1.0.1316956026」という具合に。
普通の人はバージョンなんてせいぜい5文字だから、
日付時刻をつけても弊害はなかったのだけれど、年月日方式だと、「20110925.1316956026」となってしまいます。実はバージョン番号には18桁までという制限があるので、これだとCode SignをするときのVelificationでエラーになってしまうのです。

厄介なことに、このアプリの旧バージョンはXCodeで開発していたので、年月日方式ですでにリリースしてしまっています。
しょうがないので、「3.0」にしてみたんだけど、これも「The key CFBundleVersion in the Info.plist file must contain a higher version than that of the previously uploaded version.」ということでどうにもならなくて泣きそうに。Adhoc Buildまで無事通って、最後の最後に発覚するので心理的ダメージがでかいです。

そういうわけで、このTitanium Mobileの余計な処理を止める方法。
builder.py ( /Library/Application Support/Titanium/mobilesdk/osx/#{TITANIUM_SDK_VERSION}/iphone/ )をひらいて、この辺をコメントアウトする。

僕から見たら余計な処理だったけど、書いてあるからには必要な理由があったのだろうから、普通の人はまねしない方がいいと思う。
バージョン番号が長くなって困った方だけ、自己責任でどうぞ。

おまけ:Distribution Buildのハマリどころ

 iPhoneアプリの開発は、エミュレーターで動いて、AdHocビルドも動いているのに、最後の最後でリリースできない!って苦労することが多い気がする。
自分が今回はまった点と解決策。

  • Distribution Buildした後、Validateするとすっごい長いエラーダイアログが出る
    →キャプチャしておくのを忘れたんだけど、ほぼ画面いっぱいのエラーダイアログ。長すぎて結局何がエラーなのか全然分からなかったんだけど、ダイアログの上でcommand+Cを押すと全文がコピーできるので、エディタに貼り付ければ内容を見ることが出来る。
  • 「Icon specified in the Info.plist not found under the top level app wrapper: icon.png Unable to verify icon dimensions, no icon found」
    →可能性1:info.plistに書いてあるアイコンファイルと実際においてあるアイコンファイルの名前が違う。大文字小文字にも注意。
    →可能性2:アイコンファイルが8bit pngになっている。24bit pngじゃないとダメらしいです。
  • 「a sealed resource is missing or invalid」
    →Resourcesに余計なファイルがあると起きるらしい。.gitとか.gitignoreとかそのへんをひと通り削除したら出なくなった
  • 「CFBundleVersion must be no longer than 18 charactoers」
    →上に書いたとおり。「バージョン番号は18文字以下でないといけません」。

CodeSignとかMobileProvisioningになってしまえば、もはやTitaniumMobileであることはあまり関係が無いので、「エラー文字列 iPhone」でググるのが王道のような気がしました。

[titanium]TKAnimationSampleはTitanium開発者必見のアニメーションサンプル集

Ti.Developers.meeting vol 0.3 で、MogSnapのコバヤシトールさんに、アニメーションについてお話していただきました。

その際の説明用サンプルとして掲示されたTKAnimationSampleがとても素晴らしかったのでご紹介。

toru0325/TKAnimationSample – GitHub

TKAnimationSample1.png
KitchenSinkみたいに、複数のサンプルが見られるようになっています。

TKAnimationSample2.png
HelloWorld.js。静止画見ても何のことだか分からないと思いますが、HelloWorldが下から飛び出してくるサンプルです。

TKAnimationSample4.png
buttons.js。ボタンが出現するサンプル。よりかっこいいbuttons_with_scale.jsというのもあります。

TKAnimationSample5.png
赤いボールが複雑な軌跡を描いて飛び回るredbox.js。「Hint」ボタンを押すことで、どういうふうに実現されているかを見ることが出来ます。

TKAnimationSample6.png
AndroidやiPadのように画面上にポップアップを出現させるInfo_view.js。iPhoneではあまりやらないことになってますが、実現させたい人はたくさんいると思うので、そういう方はこのサンプルを参考にすると良いと思います。

ゲームやかわいいアプリケーションにアニメーションが必須なのはいうまでもないですが、情報系のアプリケーションでも、ちょっとアニメーションを利かせておくことで、
ユーザーさんの目線を誘導することが出来るのでとても役に立ちます。
APIリファレンスを見て実装してもなかなか上手く動かないのですけど、TKAnimationSampleで動いているサンプルをみて実装するのなら簡単に実装できますよね。
自分はTKAnimationSampleを見て30分くらいで、今作っているアプリにアニメーションを追加することが出来ました。
とても勉強になるので、ぜひさわってみてくださいませ。

[ti.devs.me] window.urlを使わないプログラミング

明日16日のTi.Developers.meeting vol 0.3 in Kyotoで、「window.urlを使わないプログラミング」というテーマでお話させていただきました。

Ti.Developers.meeting.001.jpg
Ti.Developers.meeting.002.jpg
Ti.Developers.meeting.003.jpg
Ti.Developers.meeting.004.jpg
Ti.Developers.meeting.005.jpg
Ti.Developers.meeting.006.jpg
Ti.Developers.meeting.007.jpg
Ti.Developers.meeting.008.jpg
Ti.Developers.meeting.009.jpg
Ti.Developers.meeting.010.jpg
Ti.Developers.meeting.011.jpg
Ti.Developers.meeting.012.jpg
Ti.Developers.meeting.013.jpg
Ti.Developers.meeting.014.jpg
Ti.Developers.meeting.015.jpg
Ti.Developers.meeting.016.jpg
Ti.Developers.meeting.017.jpg
Ti.Developers.meeting.018.jpg
Ti.Developers.meeting.019.jpg
Ti.Developers.meeting.020.jpg
Ti.Developers.meeting.021.jpg
Ti.Developers.meeting.022.jpg
Ti.Developers.meeting.023.jpg
Ti.Developers.meeting.024.jpg
Ti.Developers.meeting.025.jpg
Ti.Developers.meeting.026.jpg
Ti.Developers.meeting.027.jpg
Ti.Developers.meeting.028.jpg
Ti.Developers.meeting.029.jpg
Ti.Developers.meeting.030.jpg
Ti.Developers.meeting.031.jpg
Ti.Developers.meeting.032.jpg
Ti.Developers.meeting.033.jpg
Ti.Developers.meeting.034.jpg
Ti.Developers.meeting.035.jpg
Ti.Developers.meeting.036.jpg
Ti.Developers.meeting.037.jpg
Ti.Developers.meeting.038.jpg
Ti.Developers.meeting.039.jpg
Ti.Developers.meeting.040.jpg
Ti.Developers.meeting.041.jpg
Ti.Developers.meeting.042.jpg
Ti.Developers.meeting.043.jpg
Ti.Developers.meeting.044.jpg
Ti.Developers.meeting.045.jpg
Ti.Developers.meeting.046.jpg
Ti.Developers.meeting.047.jpg
Ti.Developers.meeting.048.jpg
Ti.Developers.meeting.049.jpg
Ti.Developers.meeting.050.jpg
Ti.Developers.meeting.051.jpg
Ti.Developers.meeting.052.jpg
Ti.Developers.meeting.053.jpg
Ti.Developers.meeting.054.jpg
Ti.Developers.meeting.055.jpg
Ti.Developers.meeting.056.jpg
Ti.Developers.meeting.057.jpg
Ti.Developers.meeting.058.jpg
Ti.Developers.meeting.059.jpg
Ti.Developers.meeting.060.jpg
Ti.Developers.meeting.061.jpg
Ti.Developers.meeting.062.jpg
Ti.Developers.meeting.063.jpg

[titanium]画像を使わずにボタンを表示

TitaniumMobileにはSystemButtonというのがあって、ローカルに画像を持っていなくても標準的アイコンのボタンを表示させることができる(iphone only)。

systembutton.png

でも例えば、ブラウザでよく見る左右の三角形、forward/backボタンはsystemButtonに存在しない。
デザイナさんと一緒にお仕事をしている人はいいのですけど、プログラマが適当に作ったアプリでは、こういうのを下手に描いたせいでデザインが素人っぽくなってしまったりする。著作権的なものには目をつぶって他のアプリからキャプチャするにしても、この程度の画像をいちいち切り出すのはめんどくさいよね。

そこで、文字コードを使ってそれらしい文字をtitleに指定してみた。

// Forward and back button for browser.
var buttonForward = Titanium.UI.createButton({
title:String.fromCharCode(0x25b6)
});
var buttonBack = Titanium.UI.createButton({
title:String.fromCharCode(0x25c0)
});
win.setToolbar([flexSpace,buttonBack,flexSpace,buttonStop,flexSpace,buttonReload,flexSpace,buttonForward,flexSpace]);

browserbuttons.png
お、いい感じ。もしかしてもっと色々出来るかも?

// OK. more buttons!
var buttonApple = Titanium.UI.createButton({
title:String.fromCharCode(0xf8ff)
});
var buttonCommand = Titanium.UI.createButton({
title:String.fromCharCode(0x2318)
});
var buttonOption = Titanium.UI.createButton({
title:String.fromCharCode(0x2325)
});
var buttonReturn = Titanium.UI.createButton({
title:String.fromCharCode(0x23ce)
});
var buttonForward2 = Titanium.UI.createButton({
title:String.fromCharCode(0x25c1)
});
var buttonBack2 = Titanium.UI.createButton({
title:String.fromCharCode(0x25b7)
});
var buttonNote1 = Titanium.UI.createButton({
title:String.fromCharCode(9833)
});
var buttonNote2 = Titanium.UI.createButton({
title:String.fromCharCode(9834)
});
var buttonNote3 = Titanium.UI.createButton({
title:String.fromCharCode(9835)
});
win.setToolbar([flexSpace,buttonForward2,buttonBack2,buttonApple,buttonCommand,buttonOption,buttonReturn,buttonNote1,buttonNote2,buttonNote3,flexSpace]);

morebutton1.png
もうソースコードは省略するけど、こういうのも出せる。

morebutton2.png

WEBの世界では、エンドユーザーが持っているフォントにその文字がある保証がなかったり、フォントによってどんな文字が出るか予想ができないということで、こういう文字を使うのはご法度ということになっていた。
iPhoneアプリをTitaniumMobileで作るのであれば、クライアントのフォントは常に同じだから、かなりの数の記号を使うことができる。
残念ながらtoolbarにはフォントを指定できないみたいなので、toolbarに出せる文字はヒラギノで出せる範囲に限られるみたいだけど、labelとか普通のボタンだったら、font指定することで、もっと変な記号も出せるかもしれない。

文字と文字コードの関係を調べるには、下記サイトか、Mac標準の「文字ビューア」を見ればOK.

Androidは試してないのだけれど、原理的には同じようなことができるはず。
でもAndroidの場合、インストールされているフォントが保証されないから、機種によってボタンが見えなくなったりするリスクがあるかも。

テストアプリのソースコードは下記。もちろん、画像ファイルなんて不要です:-)

松山秀太郎 ペーパーモデル展が超かっこよかった

IMG_1612.JPG
松山秀太郎 ペーパーモデル展を見に行ってきました。

松山秀太郎 ペーパーモデル展
(残念ながら公式サイトがないのですが、上記は知り合いの方のブログで、松山君がどういう人なのか、大変わかりやすく説明されています。)

まだ声変わりもしていない12歳の男の子なのですが、写真を見ただけで展開図を起こして上のようなペーパーモデルを作ることが出来ます。

IMG_1622.JPG
この電車が超かっこいい!

IMG_1626.JPG
「神は細部に宿る」という言葉を思い出してしまいました。

IMG_1615.JPG
新聞紙トレイン。影がいい感じに写ってますが、撮った人じゃなくて元の作品がいいからですw

IMG_1608.JPG
展開図。精緻な図面なのに文字は小学生相応なのが萌えポイントです。

IMG_1617.JPG
机を見ると、定規だけじゃなく、デジタルノギスまでありました。

残念ながらそんなに大きな個展じゃないので、今回見られるチャンスはあと一回。9月11日、13:00~18:00、天神橋3丁目のR+Sギャラリーというところで見ることが出来ます。入場無料。もし良かったらどうぞ。

↓この建物の2Fがギャラリーになっています。

大きな地図で見る

ホントに小規模なサービス運営者のためのサーバ監視入門

sxchu_785076_small.png

待って待って待って~!

今日は AV女優.com で行っているサーバ監視を魚に、 小規模ウェブサービス向けのサーバ監視 についてまとめます。
(中略)
監視サーバと呼べるのは1台のみで、その上にZabbix-Serverが走っています。
小規模ウェブサービス向け、サーバ監視入門

それは小規模ウェブサービスとは呼ばないと思いません?複数台構成で小規模?

AV女優.comの方がzabbixを使われることは全然かまわないし、むしろ良くがんばっておられると思うのですけど、この構成を小規模と認めてしまうと、「ウェブサービスを作ってみたよ!」という人の立場がなくなってしまいます。複数台のサーバを使い始めた時点で「小規模」と名乗るのは卒業していただきたいのです。
ということで、僭越ながら、サーバ一台で全てをまかなう、本当の小規模ウェブサービス開発者さんのためのサーバ監視記事を書いてみました。

小規模っていうのはこういうのを言うんだ!

サーバは一台。さくらのVPSか、Linode.comの一番安いのが一台。これより高いサーバは認めない。
データベースとWEBでサーバを分けているとかありえない。監視用サーバなど論外!
この記事で紹介している方法は、そういう安価なサーバ一台で運営されている方のためのサーバ監視の方法です。

そもそもサーバ監視って何?

自分の提供しているウェブサービスが落ちている時、ユーザーさんから「なんか動かないんですけど」といわれるより先に開発者がそれに気づける状態にすることです。
気づいたからといってすぐ復旧に着手できるとは限らないのですけど、それでも、早く気づくことによって、「今日は早く帰れるように手配しよう」とか、「とりあえず通知だけ出しておこう」とか、そういう対応をとることが出来ます。
ユーザーさんから直接連絡をもらって、「わー!なんとかしなくちゃ」とパニックになってしまっては、とるべき対応もとれなくなってしまいますよね。

落ちた原因を究明するためにメモリやHDDの残り容量推移を記録しておいたり、ログを定期的にウオッチしたりする機能も便利ではあるけど、小規模ウェブサービスでまずやるべきは「生きているか死んでいるか」の監視です。片肺飛行であろうがメモリがリークしていようが、動いていりゃいいんです!どうせユーザーさんには出力されたページしか見えないんだから!

で、どうやんの?

mon.itor.usを使います。定期的にHTTPアクセスして、返事がなくなったらメールを送ってくれるサービスです。
有料版で高機能なmonitisというのがあって、今自分はこっちを使っているのですけど、無料版でも小規模ウェブサービスには十分な能力を持っています。

monitorus.png
これがmon.itor.usの管理画面。自分の管理しているサーバがどれくらいで応答したかがグラフになっています。

moni.tor.usを使おう!

mon.itor.usにアクセスして…

monitorus0.png
ここの「SignUp」から登録します。

monitorus1.png
メールアドレスとパスワードを入力。Phoneは入れなくてOKです。確認メールとか来ることもなく、SIGN UPを押したら登録完了の簡単登録。

monitorus2.png
登録ウイザード。見ての通りHTTP以外にも、POPとかSSH、MYSQLの生存確認もやってくれますが、まずはHTTPでやってみましょう。

monitorus3.png
監視対象のURLを入れます。まずはトップページを。

monitorus31.png

どこから監視するか、どのくらいの間隔で監視するかの設定ですが、無料版だと30分に一回、USとEUからの監視に限られています。監視間隔がちょっと長いのですけど、まずはこれで使ってみて、満足したら有料版も考えてあげてくださいませ。

monitorus4.png
HTTPの応答が一回なかったら落ちたと見なすのか、EUとUS両方なかったら落ちたと見なすのか、それとも数回応答がなかった時点で落ちたと見なすのか・・・なども設定できますが、ここはデフォルトで十分。
それよりも、「Add Contact」をクリックして、落ちた時の連絡先を登録します。

monitorus5.png
連絡先登録画面。まずはEメールで登録しましょう。iPhoneのプッシュ通知とか、Twitter(DM)とか、面白げな機能はあとの楽しみということで。

monitorus6.png

「Add」を押すと、今度は確認メールが送られてくるので、メールに書かれているURLをクリックする必要があります。ちなみに、ここで確認したメールはmon.itor.usで共通なので、一回確認すれば、他のサーバを監視する際は確認せずにそのまま使うことが出来ます。

monitorus7.png

メールアドレスの確認がすんだら、「Add Rule」をクリックして通知ルールを登録します。最後に「Done」

monitorus8.png

監視サービスが追加されました。まだ一回も監視されていないのでさみしい見た目ですが、一晩待てば、どのくらいの時間で応答したのかを見ることが出来ます。

あとは、サーバが落ちるまで存在を忘れてしまってもかまいません。メールアドレスを登録する際、「WeeklyReport」にチェックを入れていたら、週に一回レポートが送られてきます。
サーバが落ちた時には、登録したメールアドレス宛にメールが飛んできます。
ビックリすると思うけど、落ちてからせいぜい30分。たぶんまだユーザーさんは「あれ?」と思うか、まだ誰も気づいていないくらいです。今のうちに直してしまえば大丈夫!

その先のサーバ監視

まずはこれで十分です。サーバが落ちたことをユーザーさんより先に気づいてサービスを復旧させることが出来れば、第一の役目は果たしていると言えますよね。
とはいえ、使っているうちに、もうちょっと楽が出来ないのかな?と思い始めると思います。

  • 完全に落ちた訳じゃなくて、エラーページを返している時も通知してほしい
  • メモリとかHDDが減ってきたのも見てほしい

今回使った監視機能は、HTTPの応答があるかないかで見ているので、Apacheは生きているけどデータベースが死んでいるなどの理由で中途半端な(たとえばPHPのワーニングを含んだ)WEBページを返していると、一応生きていると見なしてしまいます。

また、今回つかったExternal Monitorは外からアクセスして確認しているだけなので、メモリが減ってきているとか、HDDの空き容量がなくなってきたとか、そういう事象も見ることが出来ません。

そういうことが気になるようになってきたら、Nagiosとか、ZABBIXとか、そういう高機能な監視サーバのお勉強を初めてもいいかもしれません。
自分の場合は、mon.itor.usが大変気に入ったので、有料版のmonitisを使うことにしました。有料版になると、1分単位で監視したり、WEBページの中身を見てチェックしたり、ajaxページの遷移を一通りテストしてもらったりすることが出来ます。InternalMonitorでメモリやHDDを見てもらうのも可能。
監視のためにサーバ用意しなくていいですし、インストールとか監視サーバが落ちる現象に悩まされたりもしないので、もし良かったらmonitisもどうぞ。

[Titanium]window.urlが駄目な理由

sxchu_1276335_threads.jpg

[Titanium] window.urlは推奨されないプログラミング手法らしい – もぎゃろぐの続きです。

つい先日まで使っていた物を突然駄目だと言われても納得が出来ないと思うので、どういう場面で困ったことになるのかの例を一つ。

ある程度大きなプロジェクトになると、アクセスクラス付きのデータクラスみたいなのを作りたくなることがあります。たとえばこんなクラス。

var Obj = function(){
this.v = 1;
}
Obj.prototype.setVar = function(v){
this.v = v;
}
Obj.prototype.getVar = function(v){
return this.v;
}
var obj = new Obj();

obj.vを直接書き換える代わりに、セッターとゲッターを用意しておくことで、例えばセットした時にログを書くとか、セットする時に不正な値だったらはじくとか、いわゆるカプセル化のクラスです。
この状態で、objをあちこちの画面で共有したいとします。

var Obj = function(){
this.v = 1;
}
Obj.prototype.setVar = function(v){
this.v = v;
}
Obj.prototype.getVar = function(v){
return this.v;
}
var obj = new Obj();
var win = Ti.UI.createWindow({});
win.obj = obj;
win.obj.setVar(2);
Ti.API.debug('app.js win.obj.getXXX:'+win.obj.getVar()); // 1が帰ってきてしまう

obj.setVar(2)で値を渡したはずなのですけど、newした時の値が帰ってきてしまいました。
この例では簡単にテストするためにファイル一個でやっていますが、winの定義を別ファイルに分けても再現します。

なんでこうなるの?

Ti.UI.createWindowで生成したオブジェクトは、JavaScriptのオブジェクトみたいに振る舞っていますけど、実際にはObjectiveCやJavaのオブジェクトにリンクされています(そうじゃないとネイティブUIの部品を画面に出すことが出来ないですからね)

ここからは推測なのですけど、そうやって生成されたWindowオブジェクトのプロパティに値を代入する(たとえば、win.obj = obj; のように)と、JavaScriptとObjectiveC/Java言語の壁を越えるために、いったんJSON文字列に変換されてしまいます。

結果としてメソッドは生き残ることが出来ないので、obj.setVar()がまともに動作しなくなります。

それだったらいっそ例外になってくれれば良いと思うのですけど、中途半端に動くあたり、もしかしたらJSON化じゃなくてもう少し別の実装になっているのかもしれない。その辺はちょっと自信なしです。ソース追ってみたんだけど糸口がわかんなかった(><)

オブジェクトはコンテキストを越えられない

ちょっと底の浅い説明になってしまいましたけど、ともあれ、obj.setVar()が動作しないことは事実です。この現象は、Windowオブジェクトに限らず、Ti.Appのプロパティとして割り当てても同じ現象が起きます。要するに、Ti.のプロパティにメソッドがついたオブジェクトを引き渡してはならない、ということです。

なぜwindow.urlを使ってはいけないのか。
window.urlスタイルのプログラムを使うと、上記のようなメソッド付きのオブジェクトを共有する手段がなくなってしまうからです。

単に数値や文字列を画面間で共有したいだけであれば、windowのプロパティに渡してもいいし、相互に変更をやりとりしたければ、Titanium.App.Propertiesを使うこともできます。
このやり方で実装してしまうと、各画面がロジック部分まで持つことになるので、UIとロジックを分離することが困難になってしまいます。
UIとロジックを分離するためには、メソッドの共有がどうしても必要なのです。

公式ビデオの三本目、Building Native Mobile Applications 03 – UI Fundamentalsでは、こんなふうに説明されていました。

「真っ平らな地面」が必要な場合のみ、マルチコンテキストを使う意味がある。KitchenSinkは、たくさんのデモを見せるための物で、互いにデータを共有する必要がなかったからマルチコンテキストが使われている。

あと、ロジック部分は全部インターネット上のサーバにあって、各画面はWebAPIを叩くだけ、というアプリも、マルチコンテキストで実装しやすそうな気がします。TitaniumMobileが得意とするカタログアプリみたいなのですね。