Google AppsとGAE
[Google Apps]を仕事で使うことになった。
ざっと見た感想
- [Google Apps API]の使いどころがわかりずらい。
- AppsとGAE連携してAppsに付加価値をつけようとしてるんだけど、GAE/JからCalendarやDocsのデータを参照できるのだろうか。できるらしい。
今晩の軌跡
GAE/Jで作ったアプリのデータ移行がうまくいかない。嵌ってる。
↓の手順で移行してみようとしたんだけど、途中までしかデータが移行されてない。
- 移行元のデータを画面に出力
- 移行元のデータをフォームで送信
- 新規のエンティティに内容を移し変えて makePersistentInTx!
これで129/195件しか処理されない。。。
なんかやっちゃいけない事をやっている気がするなぁ
今晩の軌跡をメモ
GAE/Jで作ったアプリをメンテしようとしたんだけど、なぜかスクリプトレットでガリガリやってたので修正困難に(゚ペ)
ガリガリくんは癖になるけど、あんまりいいことがないので困りモノです。
で、この際フレームワークに載せてみることにしました。
- MVCろうと思ってSlim3の導入を決める
- Slim3のドキュメントを読む
- "Getting a blank project"のとおりにやってみる
- blankをダウンロード
- controllerを作ってみる
- controllerまねてmodelを作ってみる
- primary key関連のmodelのアノテーションの意味がわからない
- GAE/Jのドキュメントをあさる
- Slim3のデータストア操作方法がわからない
- Slim3のメーリングリストをあさる
- メーリングリストからSlim3itの存在を知る
- Slim3itダウンロード
- テストケース発見して使い方を覚える
- データストア操作関連を実装
- これまでのデータをどうやって移行するか考える
- もう直ぐエクスポートとかcronの機能を追加するって言ってたことを思い出す
- エクスポートまだらしい(と思う)
ここまで4、5時間!
あとは明日
開発標準に何を書くか
- アーキテクチャ概要図
- ソースファイル命名規則(JSP、BL、遷移先に対してのBLであること)
- 業務クラスではSQLを発行しないでDAOを使用する
- システムリソースの取得方法
- メッセージの取得方法
- キャッシュされたデータを使用する
- 例外ハンドリング
- ログ出力
- クロスサイトスクリプト対応
- 暗号化方式
@ITから引用
■要約■
「開発標準とはかくあるべし」というような決まりはどこにもない。企業によって、業務の進め方や文化が異なることは当然あるし、プロジェクトごとに形や内容も違ってくるものだ。とはいえ、開発標準の標準的なあり方がまったくないかといえば、そうでもない。共通する要素は確かに存在する。以下のような要素を頭に入れながら、標準化作業を進めていくのがいい。
1. 時には国境まで越える、さまざまなパートナーとの協働の考慮
2. 開発技術の絶え間ない進化への対応
3. 人材の流動性への対応
1. 時には国境まで越える、さまざまなパートナーとの協働の考慮
2. 開発技術の絶え間ない進化への対応
3. 人材の流動性への対応