、東京メトロ オープンデータ活用コンテストがありました。 そのとき私が応募したアプリのソースコードを公開します。
概要
東京メトロの駅の中から行き先を決めてくれるアプリです。 家にいたくないけれど行き先が決まっていないときに使えます。 Android Wear とも連携し、 Android Wear で行き先や周辺スポットを見ることもできます。
理想
開発に使える時間の制約などから、単純に「行き先を決めてくれるアプリ」になっていますが、次の機能も実装したいと思っていました。
- 気学を用いて運勢のいい方角のなかから行き先を決める。
- 運勢のいい方角と現在地をマップ上で見られるようにする
- 行き先を決める中で、そのときの気分を考慮する。
- 行ったことのある東京メトロの駅を記録し、全駅コンプリートしたらなにかを出す。
- 目的地の駅や乗り換えの駅に接近したら、 Android Wear に通知を出す。
- 複数人で出かけるときの設定項目を考える。
- タップだけでなく、 シェイク して行き先を決められるようにする。
要するにパーソナライズして本当におすすめの駅を探すということです。
振り返って
初めて作った Android アプリ にしてはそれなりによくできたのではないでしょうか。
class の名前などは知識不足もあり、 修正した方がいいものもあります。
Disculpa, pero esta entrada está disponible sólo en 日本語 y English.
Disculpa, pero esta entrada está disponible sólo en 日本語 y English.
DIxAOP ってなんだ？ と思っていたら、 ある人が紹介してくれました。 DIxAOPについてはわかりやすく書かれているそうです。 パラパラっと見てみましたが、 EAA や DDD などのアーキテクチャを一通り知っている人が書いた本に見えます。 今回は第1章をじっくり読んでみました。 Spring フレームワーク の前書きみたいな内容で、 Spring を使ったことのない私にはちょうどいいです。
Spring の特徴
Spring の特徴として 際立っているのが DIxAOP だ。 第1章では紹介程度になっているのだが DIxAOP なくして Spring は成り立たないといっても過言ではなさそうだ。
Spring の DIxAOP 設計 は Webアプリケーション が抱える 3つの問題点 を解決する。 以下、簡単にまとめた。
- オブジェクトのライフサイクルの問題
- オブジェクトの生存期間をコントロールする作りこみが困難
- 部品化の問題
- 部品化をするためには実装非依存にする必要があるが、それなりにコストがかかる。 (注: 単にインターフェースを使えばいいという問題ではない。)
- 技術隠蔽や不適切な技術隠蔽
- 高レベルの技術を初級レベルの開発者に利用させて不具合を引き起こしてしまったり、不適切な技術隠蔽をしてその技術の利用が困難になってしまったりすることが開発現場でよく起こる。
Spring では、 上2つの問題を DIコンテナ が、 最後の問題を AOP が解決する。
Webフレームワーク というと Rails や FuelPHP, CakePHP などがあり、 「(アクティブレコードパターンの) 簡単にデータベースが使えるもの」という印象を受けてしまいがちですが、 Spring3 入門 では アーキテクチャ の考え方からしっかりと書かれていて EAAに見られるパターンの説明も(第1章では)随所で行われています。 第1章では特にレイヤの分離の説明が重点的に行われています(フレームワークを使う人には是非ともわかるようになっていてほしい内容です！)。 コードの例もあり、全体的にしっかりした印象を受けます。
以下、第1章の中で私が(個人的に)重要だと思った内容を簡単に書き留めました。
アプリケーションアーキテクチャ
プログラムを作る際には 最低でも 2つの方面からの要件・目標がある。
- ユーザの要件: ユースケースなどで表される機能要求やレスポンスタイムなどの非機能要求
- 開発者・運用者の目標: 開発期間の厳守、変更・機能追加のしやすさ、テストのやりやすさ
この本では 2つ目の 開発者・運用者の目標 からアーキテクチャの重要性が説かれている。
アーキテクチャに求められるもの
- 開発効率
- 意図を把握しやすく、理解しやすい構造
- テストが容易に行える構造
- 柔軟性
- 変更しやすく、機能追加しやすい構造
- 将来の環境の変動に耐えられる頑健な構造
ティアとレイヤ
Web アプリケーション の アーキテクチャ は ティア と レイヤ に分かれている。 ティア は 物理層 を表し、 レイヤ は 論理層 を表す。
ティア
クライアント層、中間層、 EIS(Enterprise Information System)層 の 3つに分かれるのが基本となっている。
各ティアの例
| クライアント層 |
パソコン、スマートフォン |
| 中間層 |
アプリケーションサーバ |
| EIS層 |
DB、レガシシステム |
レイヤ
EAA の冒頭あたりにある分類と同じ分け方でレイヤが書かれている(プレゼンテーション層、ビジネスロジック層、データアクセス層 の3層)。 (もちろん異なる分け方もある。) 互いに隣接するレイヤ間では一方向のアクセスのみ許す。
トランザクション処理がどのレイヤに属するのかは迷うところだが、本書ではプレゼンテーション層とビジネスロジック層の境界と説明されている。
Disculpa, pero esta entrada está disponible sólo en 日本語 y English.
A Life Summary of an Gypsy
