まず、国土交通省csvデータをDBへ移す。
http://nlftp.mlit.go.jp/cgi-bin/isj/dls/_choose_method.cgi

スマホの場合は個別にGPS取得プログラムがある。
AndroidならJava、iPhoneならObjective-C
統一機構としてwebブラウザ経由なら、
javascriptで渡してもいいが、
携帯には専用タグを利用するライブラリがある。
http://pear.php.net/package/Net_UserAgent_Mobile/
http://pear.php.net/package/Net_UserAgent_Mobile_GPS
内部的には抽象クラス定義の拡張になるので、
全部同じメソッドで実装していて非常に楽。
使い方が分からん人はググればすぐ出てくる。
後は取得したGPSのlatとlngをDB情報と比較して、
場所を特定して処理を返すだけナリ。
情報の錯綜していた昔に比べてずいぶんと
楽になったもんだ・・・。

同日　8:00
面白かった。
『東のエデン』が訴えてる日本の問題って
http://bipblog.com/archives/4750407.html
大方同意する。
最後の方で、ゲームとか物書きとかコンテンツで
人を動かせればみたいな発言があったが、
昔自分もそう考えてたけど実は根本的解決に
ならないと今は確信している。
直接的に影響ある行動しないと蚊帳の外だから。
大体、昨今の業界は金に腐心するばかりで
自由な発想で物を作れないし、
そういうの作りたいなら趣味が一番なのよね。
やはり、視野を広く現実を見ないとアカンよ。

メールサーバーの動作は結構バラバラだけど、
EC系で触ってた機会が多い割に、
ログによるエラー原因追及とかしかやった記憶が
無いこのPostFixの概要を把握。
プログラミング言語との連携方法も分かった。

メーリングリストについてだが、
簡単に言えば、エイリアス使ってアドレスを
プログラムなりに飛ばし、プログラム側は
stdin(標準入力)でその内容を読解して
メールの返答を返す様にする。
読解はmimetypeやらが面倒なので他のライブラリ
使って、ヘッダ部分にあるfromにメールを返す。
ここを参考にすればいいと思うよ。
http://coelacanth.dip.jp/emptymail.php
後はその情報をDBなりに登録しておき、
送りたい時間にcrontab設定したりでもすれば
簡単メーリングリスト完成。

PostFixというかメールサーバー自体は何を
してくれるか、についてはある程度同じ機構で

Message User Agent
(メールソフトみたいな感じ)
Mail Retrieval Agent
(メールの受信担当)
Message Transfer Agent
(どこに送るかと一時的なデータ保持)
Main Delivery Agent
(実際に送る係)

が動く事でメールが処理できる。
プロトコルとしては基本的な話だが
POP(受信)
SMTP(送信)
IMAP(メールのコピーとか検索やら)
DNS(宛先の問い合わせ)
が必要。

過去、数千件のメーリングリスト動かした際に
どうしても時間がかかる問題ってのがあった。
簡単な話、専用サーバーじゃない上に、
プログラムでウェイトも無しに送出すると
スパムと間違えられて止められたのよねｗ
複数台のサーバーでバランシングするみたいな
贅沢な環境は限られてるので、ってか中小では
まず無かろうなので、一回の全送出に2時間は
かかってた懐かしい思い出。

朝っぱらから歯医者行った。
その後、本を引っ張り出して再確認。
サンプルはGoogle Play Billing Libraryと言う事で
SDK Managerからダウンロードする。

やり取りの詳細が完全にOAuth認証思い出す訳だが、
同期と非同期メッセージの受け取り用レシーバとか
間に仲介役が入ったみたいな面倒な印象。
ただ、理解できなくは無いので、一旦進めてみる。
開発者登録とテストアカウントは別にしておかないと
後で確認作業の時に困る事だけ気に留めておく。

同日　15:40
静的メッセージで動作確認できた。
半分程動作は理解したが、大変面倒である。

後は運用サーバー側の購入時のデータ保存部分。

同日　18:36
実機落とし込み確認完了。
android.test.purchasedで確かに正常動作する。
ただ、さっきAndroid系記事で
全データ消失するハッキングがstring.xmlを使って
できるのではと出てたのがスゲー気になる。
http://gigazine.net/news/20140325-android-bug-app-delete-data/

Androidの場合、プリファレンスというxmlファイル
によるデータ保存機構があるので、初回はこれを使う。
次回以降はこのファイルを見て自動でログインする。
ログイン前にサーバー通信してユーザーを特定する。
UUIDが既存情報と違う場合はIPASSが合ってても
問い合わせ必須。

１、プリファレンスを意図的に消した。
２、他者が不正ログイン仕掛けてる。

どちらかだろうから、初回登録時にID、PASS以外に
もう一つ問い合わせ認証用の鍵を作っておいた方がいい。
つまり、最低限必要なのは４点
UUID、ID、パスワード、認証キー
こんな所か。

ログイン用のレイアウトとゲーミングスレッドは分離。
ゲーミングスレッドで処理しても意味無いし。
本格的に次は非同期通信入らななぁ。

同日　17:04
試験勉強ついでにCCENTの方にも手を出す。
ルーター本読んでたのが大活躍する。
とりあえず100ページ程読み進めて止める。
継続は力也。

同日　23:47
非同期通信一通り実装。挙動としては悪くない。

DDMSで見る限りサーバーからの送信データも
キチンと受け取れている。
後は、別に使い道は微妙だが課金構成も実装視野に
入れるべきかね。
あれメンドクサイんだよな・・・。