Android Bazaar and Conference 2011 Survey: 10年に１度の変革期を遊びたおすために

先日、琉球大学で開催された eXtreme HAGO 2 LT 大会 ( #xhago2 )に参加し、表題の内容を発表してきました。内容は、以前登壇したABC2011sというカンファレンスで見聞きしたことに、僕個人の意見を加えたものとなっています。

発表動画：Xhago2nd, Ustream

※始めの部分は録画出来てないようです。ネタを仕込んだのに...残念(´・ω・｀) スライドと当日の反応からネタの雰囲気を感じ取って下さい。

スライド：

Abc2011s survey

View more presentations from Yohei Yasukawa

当日の反応：eXtreme HAGO 2 LT 大会 第2セッション, togetter

おまけ：もしもエンジニアが本気でダイエットしたら

※夜の部でネタ発表をしてきました。反応が良かったようなので、後日、目標まで到達したらブログ記事でまとめるつもりです。

Tweet

Android Bazaar and Conference 2011 Summerで登壇します。

告知です。

7月17日開催のAndroid Bazaar and Conference 2011 Summerの学生トラックで、「震災対策アプリ：ホイッスル on Android−5万ダウンロード達成までにやったこと−」を発表することになりました。

当日は、東北地方太平洋沖地震の２日後にリリースされた「ホイッスル on Android」が、３ヶ月で５万ダウンロードを達成するまでに、どんなことをやってきたのかについて話します。具体的には、Androidアプリ開発未経験で、Androidに対して特別な知識を持っていなかった僕が、何故大勢の人にダウンロードしてもらえるアプリを作れたのか、について話す予定です。

端的に言い換えると、「ガチのAndroid Geekじゃなくたって、イイ物つくれますぜ！」ってことと、「じゃあ、どうすればNon-Geekがイイ物つくれんのよ？」ってことについて話す予定です。

この講演を聞いて、参加者の（特に、非エンジニアや技術力に自信がない方々の）Androidアプリ開発へのモチベーションを高められたら幸いです。

参考："ホイッスル on Android"のGoogle検索結果



追記：

当日の講演動画が公開されました。(21:30~)
#前半の発表も結構すごいです。

スライド資料：

震災対策アプリ：ホイッスル on Android -5万DL達成までにやったこと- Android Bazaar and Conference 2011 Summer

View more presentations from Yohei Yasukawa

Tweet

Whistle App: A Case Study of Smart-phone Development and Comparison

ホイッスル on Androidがそろそろ50,000ダウンロードに到達しそうなので、記念に(?)ホイッスル on Androidを題材としたレポートをアップしときます。本当はブログに本文をべたーっと貼りたいのですが(検索に引っかかるので）、うまい方法が見つからないので、とりあえずアブストラクトとインデックスだけ貼っておいて、中身はリンク先へ、という形でアップします。興味があればどうぞ(*)。

* 諸事情でノー添削ver.です。文章はかなりroughなので注意。

Whistle App: A Case Study of Smart-phone  Development and Comparison

Abstract

In order to clarify the insight of differences between Android and iPhone applications, this paper first introduces Whistle App, which is a smart-phone application that runs on both devices. And then, using it as a case study, this paper attempts to compare both de-vices in terms of UI components, resource managements, and markets. The other works not directly related to this paper yet helpful to write it are all attached as an appendix.

Index:

1. Introduction

　　a. Background

　　b. Why comparing with a case study

　　c. What's Whistle App

2. Evaluation Environment, Resource, and Collaborators

　　a. Evaluation Environment

　　b. Resources

　　c. Collaborators

3. Comparison

　　a. UI Components

　　　　i. Whistle on Android

　　　　ii. Whistle on iPhone

　　b. Resource Management

　　　　i. Whistle on Android

　　　　ii. Whistle on iPhone

　　c. Market

4. Future Work

5. Conclusion

6. Acknowledgement

7. Reference

Appendix

　　Multi-media Productions of Whistle App

　　Reports on Whistle App

　　Whistle on Titanium Studio

　　Whistle Widget

Body:

https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B2FvmcJSggmCZjhmMmUzM2UtZTRlNy00NTY0LWEzOGUtNmNkNGMyN2QyYmU0&hl=en_US

Whistle App in Android Market:
https://market.android.com/details?id=org.sorarier.whistle

Tweet

DoCoMo Smartphone Lounge

「ホイッスル on AndroidがDoCoMo Smartphone Lounge(DSL)で紹介されている」という噂を検証するべく、先日、実際にそこに行ってきました。ただ、一人で行くのは寂しかったので、研究室にいた留学生達にも無理矢理こころよく同行してもらう事に。以下、現場の証拠写真＋レポート。

DSLへのアクセスマップ

入り口

Touch & Tryコーナーの一角

おや...

おぉ！

本当に紹介されてる！あれ、でもなんかロゴが違うような...。まぁいいか。

紹介文によると、「自分の居場所を教えるために」ホイッスル on Androidを使うそうです。なるほど。例えば、渋谷のハチ公前で待ち合わせしているときなんかに、これを使ってお互いの居場所を教え合えばいいわけですね、分かります。そんな待ち合わせ方が流行ったら、それはもうなんかカオスです楽しい世の中になりそうですね！ということで、是非「ここにいるよーー！と伝えたときに」ホイッスル on Androidをどうぞ。

以上、現場レポートでした。

yasu

Tweet

ホイッスルアプリがAppleからRejectされたので反論したが、再びRejectされるまでの経緯

追記：NGな内容が入っていたので、一部修正して再投稿しました。

エンジニアとしての生き方という本を読んで、自分も思考をまとめるためにブログの記事を書いてみようと思い立ち、早速、実験的に自分の思考をまとめてみたいと思います。今回まとめたい内容は、Android Marketにおいて１週間で10,000ダウンロード、一ヶ月で35,000ダウンロードを達成したホイッスル on Androidが、AppleにはRejectされてしまったよ、という話についてです。「こんなアプリはRejectされるよ」という１つの例として参考にしてもらえれば幸いです。

3月13日、かくかくしかじかの背景があって、友人らと共にホイッスルアプリのAndroid版とiPhone版を開発し、それぞれのMarketで同時に投稿しました。Android版のアプリは、特に問題なくAndroid Marketにアップロードされ、各レビューサイトやブログなどで徐々に注目を集めていき、最終的にはDoCoMo Smart-phone Loungeに展示されたり、Mobile ASCIIに載ったりするまでに至りました。

それなりに盛況だったAndroid版ホイッスルアプリでしたが、一方で、iPhone版の方はどうなったのかというと、App Storeにアプリを投稿した約１週間後に、AppleにRejectされてしまいました。

Rejectされた理由については、指摘してもらった項目がいくつかありますが、ポイントをまとめると、こういう意味になると僕は解釈しました。

   理由1. ホイッスルアプリはあまり役に立ちそうではない.
   理由2. ホイッスルアプリの価値は長く続かない(?).
   →したがって、App Storeには載せられない。

確かに技術的にはとても簡単なので誰でも作れそうなアプリではありますが、価値が長く続かなく、役に立たないかと言われれば、「本当に？」という疑問がありました。というのも、事実として、Android版のアプリではそれなりに人気があり、今もなおダウンロード数は伸びているからです。なので、次の論拠を元に、Appleの主張した理由1.に対して反論を試みてみました（理由2.については、文脈からそこまで重要ではないと判断したため、理由1.に対して重点的に反論）。

   1.1. ホイッスルは緊急時の生存確率を上げる
          (cf. 登山時の緊急用ホイッスルの存在).
   1.2. ホイッスルは常に持ち歩かないし, 緊急時に持っていないかもしれないが,
          iPhoneは常に携帯している→いざという時に使える可能性が高い.
          →ホイッスルをiPhoneアプリにする必要性
   2. 素早く簡単に音が鳴らせること, また, 災害時は節電が
     （ネット接続を試みたり, 重い処理をしないことが）重要であること.
       →機能をシンプルにした正当性
   3. Android版では(当時)10,000ダウンロード/週だったこと,
       かつ, アプリに対して肯定的なレビューがほとんどであったこと。
       →ユーザーがusefulだと思っている証拠。
  →したがって、ホイッスルアプリは役に立つ。

これらの論拠を元にAppleに問い合わせをし、さらに待つ事２週間。Appleから来た返事は、審査委員会によって再びRejectされた、という内容でした。詳細は省きますが、僕なりに意訳すると「ホイッスルアプリに簡単にアクセス出来るようにする理由は理解出来ました。しかし、もう少し追加機能があると、より良くなると思います。」といった理由で、ホイッスルアプリの承認はやはり出来ないそうです。

ちなみに、ここでいう"追加機能"とは、フラッシュライト、緊急用アイテム一覧、避難場所案内などの機能を指しているようです。しかし、これらの機能を実装しても承認は保証できないそうです（これは、審査した人と提案した人が違うので当たり前ですね）。

少々長くなってしまいましたが、こういった経緯があってホイッスルアプリのiPhone版はApp Storeには未だありません。今後、Appleが提案したような機能を実装して再びsubmitするかもしれませんが、現段階では未定です。すみません。仮にsubmitするとしても、少なくとも「ホイッスルアプリ」という名前ではないと思います。

最後に、今回の件で得た知識を僕なりにまとめると、

   1. 論理的な思考だけでは、Appleを説得出来ないかもしれない。
   2. シンプルすぎるor技術的に簡単すぎる機能は、審査を通らないっぽい。
   3. 問い合わせの返事は、１週間〜２週間の単位で見積もりましょう。

といった感じです。何か他に気付いたことがあれば、コメント等でお知らせしてもらえると嬉しいです。

うん、結構思考がまとまったような気がする。あと、こんな記事を書いてしまうと勘違いされそうなので、少し断っておきますが、僕はApple好きのマカーです。友人に勧めるLaptopは常にMacBookで、"Besides Mac!"と友人に言われたら、"Okay, then there is nothing I can recommend."と返してしまう人間です。

Tweet

User Review Notifier for Android Market

１つ前の投稿で紹介したUser Review Getter from Android Marketを利用して、Android Marketにある任意のAppのユーザレビューを取得し、新しいものがあればメールで知らせるスクリプト(の組み合わせ)です。

Source Code:
https://github.com/yasulab/user-review-notifier-for-android-market

以下、READMEから引用
====================

Periodically check user reviews on your android app
in Android Market, and email you if there is new reviews.

What You Need
-------------

- Unix Server
- sendmail (command)
- lxml (python)
- cron

Setup
-----
1. Replace upper-case strings in user-review-notifier.sh with your own.

   #!/bin/sh
   dir="PATH_TO_THIS_DIR"
   package="PACKAGE_NAME"
   mail="YOUR_ADDR@YOUR.DOMAIN.COM"

   python ${dir}user-review-getter.py ${package} > ${dir}latest.data
   diff ${dir}latest.data ${dir}last.data > ${dir}diff.data
   mv ${dir}latest.data ${dir}last.data
   python ${dir}sendmail.py ${dir}diff.data ${mail}

Example:

   #!/bin/sh
   dir="/home/yasulab/user-review-notifier/"
   package="org.sorarier.whistle"
   mail="yasulab@gmail.com"

   python ${dir}user-review-getter.py ${package} > ${dir}latest.data
   diff ${dir}latest.data ${dir}last.data > ${dir}diff.data
   mv ${dir}latest.data ${dir}last.data
   python ${dir}sendmail.py ${dir}diff.data ${mail}

2. Make sure that your server can type the following commands.

- $ sendmail
- $ python
    >  import lxml

3. Check if python scripts run.

- $ python user-review-getter.py PACKAGE_NAME
- $ python sendmail.py FILENAME TO_ADDR

4. Test to run initial shell script.

- $ sh user-review-notifier.sh

5. Check your e-mail box if you got an e-mail.

6. Setup your cron to run the shell script periodically.

- $ sudo crontab -e

Example:
# m h  dom mon dow   command
0,10,20,30,40,50 * * * * /bin/sh /PATH_TO_DIR/user-review-notifier.sh >/dev/null 2>&1

7. Done! You will be able to get an e-mail if there is new reviews.


Reference：
User Review Getter from Android Market

Usage of user-review-getter.py (GitHub)
--------------------------------------------

     $ python user-review-getter.py PACKAGE_NAME

Example
-------

     $ python user-review-getter.py org.sorarier.whistle

Result
------


非常に素晴らしいアプリだと思います。 そして迅速な改善に頭が下がります。 製作者樣、ありがとうございます。by あっきー–2011/03/19
こまめな更新に、感謝感激by Gaz–2011/03/19
音量自動最大はいいんですが、元々の音量設定に戻りません。 これだと困ります。改善おねがいします。 Xperia 2.1by 陸–2011/03/19
強制終了問題解決！対応の早さに感謝！by 環境IS04–2011/03/18
ちゃんと意見を汲み上げ判断したのち反映する誠実さと、その迅速な行動力に感服しました…。 災害時のみならず、防犯上でも役に立つ。 ...by aki–2011/03/18ちゃんと意見を汲み上げ判断したのち反映する誠実さと、その迅速な行動力に感服しました…。 災害時のみならず、防犯上でも役に立つ。 できうるなら、音声（例えば自分で録音しておいたものとか）の方がより分かりやすいのだろうが。
速やかな改良、対応に頭が下がります。by Gen–2011/03/17
使用時に端末の音量設定を最大まで上げるようには出来ないのですか？by まーさん–2011/03/16
音が小さいby 沙弥香–2011/03/15
音が小さいよねby 綾子–2011/03/15
シンプルで良いと思うけど、もっと音が大きくないと…by 五月女–2011/03/14
Works on droidx. No permissions needed.by Leonard–March 13, 2011

Tweet

User Review Getter from Android Market

Android Marketの中の、指定されたAppのユーザレビューを取り出すプログラムを書きました。いずれRSSが登録出来るようになる(もしくは既にあるけど知らないだけ?)でしょうが、待てなかったので自分で作りました。

Usage:

     $ python user-review-getter.py PACKAGE_NAME

Ex:

     $ python user-review-getter.py org.sorarier.whistle

Result:

非常に素晴らしいアプリだと思います。 そして迅速な改善に頭が下がります。 製作者樣、ありがとうございます。by あっきー–2011/03/19
こまめな更新に、感謝感激by Gaz–2011/03/19
音量自動最大はいいんですが、元々の音量設定に戻りません。 これだと困ります。改善おねがいします。 Xperia 2.1by 陸–2011/03/19
強制終了問題解決！対応の早さに感謝！by 環境IS04–2011/03/18
ちゃんと意見を汲み上げ判断したのち反映する誠実さと、その迅速な行動力に感服しました…。 災害時のみならず、防犯上でも役に立つ。 ...by aki–2011/03/18ちゃんと意見を汲み上げ判断したのち反映する誠実さと、その迅速な行動力に感服しました…。 災害時のみならず、防犯上でも役に立つ。 できうるなら、音声（例えば自分で録音しておいたものとか）の方がより分かりやすいのだろうが。
速やかな改良、対応に頭が下がります。by Gen–2011/03/17
使用時に端末の音量設定を最大まで上げるようには出来ないのですか？by まーさん–2011/03/16
音が小さいby 沙弥香–2011/03/15
音が小さいよねby 綾子–2011/03/15
シンプルで良いと思うけど、もっと音が大きくないと…by 五月女–2011/03/14
Works on droidx. No permissions needed.by Leonard–March 13, 2011

Requirements:
- lxml

Source Code:
https://github.com/yasulab/user-review-getter-for-android-market


User Review Getterは、ただ英語と日本語のユーザレビューを取り出すだけなので、単品ではあんまり役に立たないと思いますが、他の物と組み合わせると便利になると思います。僕の場合は、User Review Getterとdiff、smtp、cronを組み合わせて、最新のユーザレビューを見つけたらメールで知らせてくれる、Notifierみたいな感じに仕上げました。もしかしたら他にも使い道があるかもしれません。

とにかく、これでいちいちAndroid Marketでユーザレビュー確認する必要が無くなり、少し効率的な生活が送れるようになりました。あとはAndroid MarketのRSS対応を待つばかりです。

追記：
User Review Notifierを作りました。

Tweet

ホイッスル on Android

友人達とホイッスルアプリを作成し、先ほどAndroid Marketに投稿しました。後日App Storeにも投稿される予定です。このアプリを作るきっかけはこんな会話でした。

今回の東北地方太平洋沖地震に対して、自分も何かできないか色々考えたんだけど、献血とか節電くらいしか思いつかなかったんだよね。色々調べてたら、どうやらホイッスルがあるとさ、生存確率がすごい上がるらしいんだよね。今回の被災者には役立たたないかもしれないけど、次回地震が起きた時に、一人でも助かればいいなと思って、ホイッスルアプリを作ろうかと思うんだけど、どう思う？

こんな話をしたのが、Android Marketに投稿する約１０時間前のことです。すぐに開発に取り掛かりすぐにリリースする事が当初の目標だったので、Androidアプリ開発未経験者としては本当に作れるかどうか不安だったのですが、今までの経験とカンを頼りに、なんとか作り上げることが出来ました。これも、暇な時にGoogle App EngineやGoogle Web Toolkitなどで遊んでいたおかげかもしれません。

ホイッスル on Androidは、普通のホイッスルと同じ機能を実装しただけなので、機能はかなりシンプルです。中央のボタンを押すと大きなホイッスル音が鳴り続け、もう一度ボタンを押すと止まります。画面を見ずに操作出来ることを踏まえて、このような設計にしました。

# トップ画面のどこにこのアプリを配置するか、という事も同様に重要です。
# また、スリープ状態でも音は鳴るので、電池節約のため、
# 音を鳴らしたままスリープ状態にすることをオススメします。

起こらないに越した事はありませんが、万が一、二次災害や次の地震が起こったとき、このアプリが役立てばいいなぁ、と考えています。もちろん、普通のホイッスルとしての使い道もOKだと思います。何かの役に立てば幸いです。

開発：@riarne2000, @yasulab

デザイン: @migihiza

DEMO動画
--------------

以下、Android Marketから引用

========================

ホイッスル on Android

-----------------------------

ホイッスルは、災害時における生存確率を高めます。居場所が外部と遮断されてしまった場合、救助隊や近くの人に助けを求める時に役立ちます。ホイッスルを常に携帯する事がベストですが、必要な時に手元に無いかもしれません。本アプリ「ホイッスル」は、起動後、中央のボタンを押すと大きなホイッスル音が鳴り続け、1ボタンでON/OFFの操作が可能です。万が一に備えて、あるいは女性や子供の方への防犯としてもお役立てください。Android版/iPhone版の両方があります。

# 今回の東日本大地震を受け、製作しました。2011年3月の大地震で被害に遭われた方には心よりお悔やみ申し上げます。

また、本アプリへのご要望、ご意見はお気軽にどうぞ。

# iPhone版は現在審査中...

Whistle on Android

-----------------------

According to the rule of thumb in Japan, whistles help you survive after natural disasters such as Tsunamis and earthquakes. In particular, they will be beneficial in case that you cannot escape from collapsed buildings. However, it is not in practice to always hold a whistle for disasters that you cannot expect to occur. So, put it into your belongings, your smart phones. This will help you when accidents happen. Whistle on iPhone can be downloaded from App Store as well.

# Whistle on iPhone is being reviewed by Apple

Tweet

Android携帯でGmailからログアウトする方法

Android携帯では, Gmailからログアウトする機能がついていません. これなんて孔明の罠?

「How to sign out of Gmail on G1 phone?」

http://groups.google.com/group/android-beginners/browse_thread/thread/9f362779566197e7/874238837445fe51?hl=en&lnk=gst&q=log+out+account#874238837445fe51

苦肉の策としてデータリセットも考えましたが, どうやらcacheをクリアすればどうにかなるようです. 実際に試してみたところ, ちゃんとログアウト(?)出来ていました.

Link dev phone to a different account, WITHOUT factory reset!
http://groups.google.com/group/android-beginners/browse_thread/thread/4d1e0f9f80bc6fb4#

恐らくメールの通知機能を持たせるとき, Loginしているかどうかの状態を考慮してしまうと, 想定しなければならない振る舞いが多くなってしまったから実装しなかったのかもしれません. とはいえ, ちょっと不便を感じずには入られませんでした. というか, キャッシュのクリアによるログアウトって, 一般ユーザは理解できるのかな?

Tweet

Google Developer Day 2009

今日は横浜まで行ってきて, Google Developer Day 2009に参加してきました。サプライズとしてAndroidが搭載されている携帯を無料で貰えました。開発用なので勿論サポートは無いし, SIM差すと請求額がとんでもなくなるらしいから, 実質Wi-Fi環境でしか動かせませんが, それを考慮してもメチャクチャ使い勝手が良いです(文字入力を除いて). 例えば, カメラで取った画像は2タッチでgmailおよびpicasaに送れます. また, 動画ならば2タッチでgmailおよびyoutubeにアップロードできます.

当日, 横浜で何があったかは, ネットで検索すれば色々と分かると思うのでここでは割愛します. とりあえず, Google Web Toolkitのベストプラクティスや, Google App Engineでjavaを動かす時の仕様および注意点などを聞けただけでも個人的には大満足です. あそこまで至れる尽くせりだと, なんか少しはオープンソースに貢献しないとバチがあたりそうな気がします. 時間が空いたらちょっとやってみたい気にさせられました.

Google Web ToolkitとGoogle App Engineには御世話になるつもりでいるので, またこのような機会があったら是非また参加したいと思います.

以上, 近況報告レポートでした.


#以下、メモ
※注意: 誤字脱字・誤解誤認の可能性あり

Google Developer Day 2009 memo

[基礎講演]
Google Chromeによる利点
-Speed up
--高精度化
--HTML5: canvas, vide, geolocation, app cache/DB, web workers(マルチタスク化)

1. canvas
-javascriptはスケールでない.
-canvasは宣言するだけ(?)
-O3D
--web app(NOT flash)で高解像度の3Dが描画可能

2. video
video tag
-Ex. 動画そのものをjavascriptで回転
-HTMLだけで動く, not flash

3. geolocation
???

4. app cache/DB
connectionに不具合がえってもcache/DBで補完

5. web workers
canvasで動かすタスクをマルチスレッド化

「これら全てをweb標準にする」
-そのためのGoogle Chrome
--IE以外(firefox, safari, opera)は賛同
--IE8でどうなるかは分からない

web socket -> Unixのsocketライク(パンフレット参照)
notice -> ポップアップは別の形で(パンフレット参照)

Google Chromeプロジェクトは"chromium"で今も動いてる。
-いつでも参加可能。
HTML5を実装し, マルチplatform化した(パンフレット参照)

次は, Mobileと統合したnew techを!

[Tom moss]
androidは活発で, USAでは既にNo.2に.
-次はJapanへ進出

[NTT docomo Mr. nagata]
Androidへの期待
-今までのdocomoのサービスを反省し, Smart phoneへ

keyはdeviceとapplication.
-deviceは良い
--あとはアプリ開発
---アプリ開発が売り上げ曲線の傾きに影響すると考えている.
----「ケータイするGoogle」
----Docomo Pro series HT-03A

app, dev, costの正の循環に期待
6月末〜7月上旬に環境を提供

[Chris Pruett]
Android storyの話

download app
-directly download
--easy to get
-develop business

サプライズ企画:Android Phoneの無料配布
-androidを広げたい
-androidのキラーアプリはGoogle以外の開発者が作ると期待


[Daud Glazer]
social webの話
-open social

webの特長
-web connect
--web <---> doc
--web <---> open

Problem
-app ---> user
--app <---> user

Social Web motivates innovations.

[Mr. kasahara]
mixiの次のステップ
-communication service

Mixi platform
1. application
-inside mixi
--social application
--PCとMobileの整合

2. connect
-outside mixi

3. ビジネス支援
-広告: 1page = 0.01 yen
-課金: 手取り8割
-資金: 出資or融資

利点: marketing costが低い
-マイミクによる伝播を利用
--social networkの一つの魅力
---アイデア勝負の環境を提供

Ex. ハグ☆ミー
-ハグ友達を選択
--相手に通知(それだけ?)

OSDE with Eclipse plug-in
-OpenSocial hackathonで使われている

[Ex. Goo home]
2 or 3以上のappを統合
-Goo homeのあるgadgetのアクションが他のgadgetに伝播

[Google Wave]
Google Waveの話
product, platform: API, protocol:open source
-serverにユーザがアクセス

Google Wave Demo
1. insert sentnce
2. real-time chat
3. 3人目以降は時系列を参照可能
4. localfileからD&Dでアップロード
5. uploadしたものはスライドショー可能
6. Blogからもアクセス可能
7. twitter + wave
8. Gameもシームレスにプレイ可能
9. Gameの時系列(Ex. チェスの手順)も参照可能

Ex. API
-loggy
--real-time translation

まとめ
-wave.google.com
-code.google.com/apis/wave
-222.waveprotocol.org
-devアカウントを後日配布

[Mr. Ishihara]
他productの紹介
-Google Web Elements
--make blog pwerful
-MapsAPI ver.3
--3年ぶりのバージョンアップ
--Key less
-ルート検索
--近いうちに公開予定
-GTUG(Google Technology User Group)発足
--1,2 monthlyで活動
---詳細はGOogle Lightening Talk

Android phoneについて
-Wi-Fi環境を強く推奨(通信費用の関係上)

Key: Make Powerful Web By Yourself


----------------------
[Google App Enging]
GAE-request処理について
-分散システムに類似してる?
-Ex. 分散システムのスケーラビリティ
--Ex. データでは無く参照ポインタを伝播

まとめ
-Fan-out
-Geolocation Info
-Relationship Glaph
-membership question
-write時間を考慮する


-----------------------
[Java on GAE]
outline
-GAEとは
-On Java Support
-App Enging Datastore

使えるもの
-Java 6が動く
-servelet/lib
-Google interface

特長
-install / maintainance不要
-負荷に応じてリソースの動的割り当て
--自動scaling
-CPUやband widthに応じて課金
--入っていの規模まではFree

App Engineについて
-Load Balancingベース
-開発者はアプリにfocusして欲しい
-最低でも3つのサーバ
--高信頼性

注意点
-HTTPリクエストが30秒をこえるとExeptionを投げる
--長いbackground processの禁止
-sand-box内でのみ動作
--ユーザによるスレッド操作はダメ
---serverはok(?)
--File Systemのread禁止
---FS readは必要ないはず

servelet API 2.5
Jettyを使用
-しかしjettyの特長は使えない
--jetty-web.xml
--continuations(継続) ← tango!は動かない可能性高いorz

Software Service
-JBBCはダメ
--Relational Databaseはコンセプトと合致しない
---正規化は必ずしも必要ではない
-APIはAPIProxyを通してつかう
--AOPができる
---サービス前後のprofilingが取得できる
----debugが簡単に!

sand-boxについて
-制限
--JVM permission
---local file / socketの禁止
----互いに参照させないため
--ただし, JVM上で動くものなら全てok
---JRuby, Jython, Rhino, etc.

under constructing...
-tech theme -> async
-full text search
-mail receive
-Datastore import/export tool
-etc.

Data Storeについて
-dataの格納の仕方が違う
--big tableは動的に分割される
---一見、制限は無いように見える
--schemaが無い
---not strict
--NOT RDBMS
---RDBMSはpowerful過ぎる
----ターゲットと合致しない

storeはsimpleに
-App dev
-App message
-App environment service on GAE
-APP scaleするインフラ
--リクエスト量, データ量を重要と考えているため

Data storeの特長
-Entity
--object in Java
-Kind
--Class in Java, table in DB
---person
-key
--primary-key in DB
---person/person:44, /pet:8
-e-group
--Transaction in DB
-property
-- Column in DB
-friends
--1対多
---/person:32, /person:34

functions
-get()
-put()

soft schema
-App layerによって決定
--devが楽 based on 経験
-JDO/JPAのmete-def

移行のヒント
-databaseはRDBMSは置換できない
--designし直す
---Primary key
---transactionが必要かどうか
----結構大変かも
----何がrootか考える
-----userがrootになりやすい
------複数かどうか考える
---array, view, trigger, data移動

Ex. joinが使えない
-非正規化

まとめ
-AFDを永続化
-soft schema
-非正規化を恐れずに行う
--高速化と堅牢性のトレードオフ

参考資料
-Google developer relations japan
-google code


※次はGoogle Web Toolkit: ベストプラクティスから

追記:
----------------------------
[Google Web TOolkit: ベストプラクティス]
Introduction
-nontrival cache
-client side
-AdWardsUI

History
-Event Bus
-DI + MVC(Model, View, Controller)

3 themes
1. async
-AJAX, ID array for scaling
--Sync/Asyncを2つとも用意
-make arm torelable
-failureを1つの場所に!
--GWT.ranAsyncUI to split
-Abstract Got
-通信したらレンダリング

2. decouple
2.1 DI
easy test, wit, debug
-Connection's'
-Geust's'
--remove over connections
-Instant
--if(コンタクトIDs!=???)
-EventBus for tossing

Ex. Private onSuccess{
cb.onSuccess{
... // then, create a new contact
}
}

2.2 MVC(Model, View, Controller)
ブラウザ遅い
-model<----prefetch<--->View
--Model: Keep Simple!
--prefetch:
---class PhoneEditor
inteface G_Display{
// ハンドラを増やす(?)
}
--View
---Keep Simple, but still slow
---MochView

3. stateless
duplicate functions
-Phone.front() // safer
-Save
-Cancel

Dependency Interaction(?)
-No Global, No Service
-GIN - client
-GUice - service

Decoupling Advantages
LayOff
-tests run fast
--Store Action in Local
--After cancelling, We can test

Ex. FireEvent(GwtEvent(?))...
// 色々用意して
-editor.editPhone
-display ...
//verify
-vndate...
-assert...
-phone...
-assert...

User Should NOT notice Server restart
-Expect multiple Instances

Recap
-Get b-history
-Use EventBus
-DI + MVP FTW
-3 themes
--1. 同期/非同期を含める
---常に使う必要は無い. scaleするため.
--2. 常にdecouplingする using EventBus
--3. strive to archive statelessness

参考資料
code.google.com/webtoolkit/
-スライドあり?

----------------------
[Google & OpenSource]
Googleとopensourceの関係の話
-結構面白かったからyoutubeであとでみるのも良いかも!

Google Code
-CSの学生は理論が強い
--しかし, 実践に弱い傾向がある
---Google Summer of Code

ライセンスの話
-GoogleのライセンスはBSDが多い
-Google Chromeは最もexposureなproject
--processやgoogleのstrategyもオープンにしている

プロジェクトによってopenの度合が違う
-Ex. 広 GoogleChrome, Android 狭

----------------------
[Google Lightening Talk]
Google Technology User Groupが各5分で自分のプロジェクトを発表
-Key by matsuo-san
-JRuby on GAE
--800 files to 100 files
-OpenSocial
--hackathon is opened for even begginers
-???VM

GTUGの発足
-メンバー募集
-活動は1,2ヵ月に一回

----------------------
[Google Wave API]
Google WAVE APIの仕様の話?
-途中から興味が無くなり, 寝惚け眼で聞いてた

3 waves type
-1. oneself
-2. 2 participants
-3. more than or equal to 3
※詳細は基礎講演のメモ参照

2 part
-1. embedding
--archtecture
---include javascript

method
-LoadWave
--ID
-SetUIConfig
--style???
-AddReply
--Visit -> reply
-Follow???

-2. Robot
???
※理解できなかった

Tweet