2011年10月アーカイブ

sxc_hu_738173_map_money.jpg

ブログやWEBサイトに地図を表示することが出来て大変便利なGoogleMapsAPIに関して、Googleが有料化を発表したのでビックリしました。

 Googleは、Google Maps APIの利用規約を今年4月に改定し、10月1日から同APIの利用上限を定めることを発表していた。
 現時点で利用上限を超過しても、即座に課金されることはない。利用者には、APIの利用状況を確認する期間が与えられる。その上で、利用上限を超えている場合には「2012年初めごろ」から強制的に課金されるとしている。その場合は、最低30日前に通知されるとしている。
(Google Maps API有料化の詳細発表、該当ユーザーは2012年初めに強制課金開始 -INTERNET Watch)

今一番知りたいことは「どれくらい使ったら課金されるようになるのか」だと思うのですが、自分が調べた範囲では、あまり気にしなくてよさそうです。根拠はこれだ!

maps_limit1.png
(FAQ - Google Maps API Family - Google Code)

Styled Maps というのは最近出来た機能で、GoogleMapsから線路を消したり海の色を変えたりといったデザイン変更が出来る機能です。こちらを使っている場合はちょっと厳しいのですけど、そうでない場合は 25,000 map loads / Day。1ページに大量の地図を埋め込むことは普通ないので、つまり実質25,000 PV/Day ≒ 75万PV/月ということになります。
モバイラーズオアシスが10万PV程度なので、食べログさんとか、大手不動産業者さんレベルにならない限りは課金されないんじゃないかと。30min.さんあたりが微妙なラインかなぁ。

さらに上記ページを見ると、越えた場合の課金金額も書かれています。

maps_limit2.png
(FAQ - Google Maps API Family - Google Code)

25,000を越えたあと、1,000usageごとに4$だそうです。例えば100万PV/月のサイトがあったとすると、約3万3千アクセス/Dayなので超過部分が8300usage=$32。$960/月なので、76,800円/月ということになりますね。
ちなみに、Google Maps API Premier、お値段を公開している代理店を見つけました。85万円/年~だそうです。
GOGA - Google Maps API

追記:Google Maps API Expertの方からコメントがいただけました。
回数は、APIライブラリの読込回数です。
ANN:Google Maps APIへの使用制限の導入について - Google-Maps-API-Japan | Google グループ
ということは、iPhoneアプリなんかは、アプリを起動して地図を表示するごとに1回と考えれば良さそうですね。


iOS5のMobile Safariから使えるようになったHTML5・CSSを試してみました【前編】 - くらげだらけ(くだくらげのBLOG)で、Web Symbols typefaceというテクニックが紹介されていた。
WebFontという技術を使って、文字の代わりにボタン画像なんかを埋め込んだフォントを使えば、画像ファイルを持たなくてもよく使うアイコンを表示できるよ!というアイデア。
みんながこのフォントを使うようになって、jQueryみたいに高速なサーバからこのフォントが落とせるようになれば面白い技術だと思う。

でも、iOSに限定していいんだったら、[titanium]画像を使わずにボタンを表示の手法を使ってWebFontなしにボタン画像を表示することも出来る気がしたので、やってみた。

machine_dependent_charactors.PNG
machine dependent charactors on iOS5 - mogya

理屈は前回と同じ。Apple SymbolsやLucida Grandeといったフォントは、上記のようなデザインの文字を元々持っている。これらは、同じフォントを持っていないと表示できないからWEBの世界では使わないことになっているけれど、iPhone専用サイトと割り切るのであれば、CSSでフォント指定して上げれば表示することが出来る。
どんな記号が使えるかは、下記を参考に。

長所としては、WebFontを使うより当然高速軽量に表示が出来る。短所としては、iOSの持っているフォントに依存してしまうので、昔のIE専用WEBページと同様、他の機種で見た時の表示が保証されない。
実際問題としては、サンプルをひらいてみると分かるようにWindowsでもけっこう表示できちゃうんだけど、WEBの精神から行くとあんまり望ましくないことなのは事実。「iPhone」といったらiPadもAndroidも含めた全てのスマートフォンで動くものを想像されるお客さまも日本にはいらっしゃるので、利用する時は慎重に利用することをお勧めします。



jhmr.gif

PHPな人が集まって一晩中開発を行うイベントPHP祭りに行って来ました。

「mogyaさんPHP祭りは来ないの?」
「最近PHPは全然書いてないのでノーチェックですねぇ。」
増井さんを呼んでTitaniumの話をしてもらうよ」
「今申し込みました(即答)」
というような経緯です。

実際行ってみたら、
masuidrive「この中で、Titaniumをご存知のかた?」(挙手)
masuidrive「Titaniumでプログラムを書いたことがある方」(挙手)
masuidrive「Titaniumでアプリを作ってリリースしたことのある方」(挙手)
masuidrive「今日は初心者向けなので、今挙手された方が聞くような内容はありませんw」
って言われました。そりゃまあそうですよね。

ハッカソンでは、電源検索の無料版「電源検索Lite」を開発して「Titanium大賞」をいただきました。

6253918541_5b2d940be1_o.jpg

そういうわけで、「電源検索Lite」for iPhoneは今Appleで審査中なので、審査が通ればAppStoreに登場する予定ですので、楽しみにお待ちくださいませ。
ちなみに、待ち切れない方は、電源がないお店も検索できる有料版がすでにAppStoreに出ております。



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_1341556_hubgrybird.jpg

「安くて飲み物がおいしいのに混んでなくて快適な喫茶店」は、つぶれる。




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の問題は、マネージャさんが異常に忙しいことです。メンバーが日報を書かなくていいのも、進捗会議に出席しなくてもいいのも、マネージャさんが進捗を聞いて回っているからこそです。
    マネージャさんは大変ですけど、メンバーより多くお給料が出ているんだから、メンバーよりたくさん働くのはとても正しい姿ですよね。

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

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

関連記事



このアーカイブについて

このページには、 2011年10月 に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは 2011年9月 です。

次のアーカイブは 2011年12月 です。

最近のコンテンツは インデックスページ で見られます。過去に書かれたものは アーカイブのページ で見られます。

Powered by
Movable Type