2009年10月 のアーカイブ

DAYS 11 日時に関して

2009年10月27日 火曜日

[ GAE Google App Engine ][ Phthon ][ Google Bigtable ]
日時のデータに関していくつか。
・タイムゾーンについて
db.modelの日時に関するプロパティで
「auto_now_add=True」「auto_now=True」を設定すると
すべて世界協定時刻(UTC)が保存される。
「キャッチ&リリース(ベータ版)」では、「締切」を入力するようになっているため、
日本時間の締切を入力するのが当り前であるが、
更新日時、登録日時は世界協定時刻(UTC)なのである。
この違いの解決方法としては、
データはすべて世界協定時刻(UTC)で保存し、
表示するときに、日本であれば、日本標準時(JST; GMT+09:00)表示に
変換するというのが正しいやり方のようだ。
ちなみに、入力した日時は、世界協定時刻(UTC)に変換しなければならない。
参考:はしっこの、そのへん「Google App Engine再び」
今回のシステムでは、変換は行っていない。
なぜなら、今後、世界規模でプロジェクトを実行することは容易に想定できるからである。それであれば、日時の基準を世界にひとつにした方がよい。
このシステムはWebである以上、日本時間が基準とはいえないのだから。
(日本語で作ってはありますが・・・)
日本にいる人間は、「現在の時間 プラス 9時間」という前提で、締切を決めたり、
作業を行えばよいのである。人間側で対応すべき問題である。
データの登録、更新処理の全ての処理に
この変換をいれるのが大変だから、と理由では断じてない!
・日時の整合性について
「締切日が現在より、未来であること」
「開始日と、完了日がひっくりかえらないこと」
といったチェック機能を入れようとしたが、やめた。
チェックは人間がする。そして、間違いに気づいたら人間が直す。
・日時の表示の変更について
HTMLページで、DateTimeデータを表示させると
「 2009-10-14 14:00:18.156817 」
のようにわけのわからない数字が、最後に入ってしまう。
表示形式の指定方法を変更するには、以下のようにする。
変更前「 2009-10-14 14:00:18.156817 」
{{ data.add_date}} と指定
変更後「 2009-10-14 14:00:18 」
{{ data.add_date|date:”Y-m-d H:m:s” }} と指定
私がつくったアプリ↓
協調型意思決定支援システム「○ 賛否両論 ×(ベータ版)」
http://sanpiryoron.appspot.com/

協調型プロジェクトタスク管理ツール「キャッチ&リリース(ベータ版)」
http://ctchandrls.appspot.com/

DAYS 10 俺はなんてアフォーム(FORM)なんだ!

2009年10月26日 月曜日

データの追加、編集処理、HTMLでいうFormの画面で、いくつか分かったことがあるので以下に記す。
前回の「○ 賛否両論 ×(ベータ版)」では、
唯一のデータ編集画面「ユーザー情報の編集」で、
編集のHTMLのFORM画面に、更新前のデータを表示させることができなかった。
表示させても、submitするとデータが追加されてしまい更新処理ができてなかった。
泣く泣く、Djangoを使わず処理した。
DjangoがGAEバージョンなので、あきらめていた。
だが、今回、試行錯誤した結果、Django使って、更新処理を行う方法が分かった。
本来、分かって当たり前なのかもしれないが、
やっと・・・
やっとわかった!
こんなかんじ↓↓↓

# モデルクラス
class UserData(db.Model):
user = db.UserProperty(required=True,auto_current_user=True)
name = db.StringProperty(required=True,verbose_name='※名前')
presentation = db.TextProperty(verbose_name='自己紹介')
del_flg = db.IntegerProperty(default=0,verbose_name='削除フラグ')
add_date = db.DateTimeProperty(auto_now_add=True,verbose_name='作成日時')
update_date = db.DateTimeProperty(auto_now=True,verbose_name='更新日時')
def __unicode__(self):
return self.name
# DjangoFormを使うためのフォームクラス
class UsrForm(djangoforms.ModelForm):
class Meta:
model = UserData
exclude = ['user','del_flg']
# ハンドラー
class UsrEditHandler(webapp.RequestHandler):
~~~(省略)~~~
def post(self):
user = users.get_current_user()
if user:
q = db.GqlQuery("SELECT * FROM UserData WHERE del_flg = 0 AND user = :1", user)
q = q.get()
<span style="color: #ff0000;">ここ!</span>
form = UsrForm(<span style="color: #ff0000;">instance=q</span>,data=self.request.POST)
if form.is_valid():
data = form.save()
data.put()
self.redirect('/user')
~~~(省略)~~~

そのほかには、
データ更新画面で入力ミスをした時のパラメータ受け渡しを完全に忘れていた。
たとえば、
「 http://ctchandrls.appspot.com/—-/—?id=XXXXX 」
のように、GETで「id」パラメータを渡している時は、
入力ミスをして、更新画面に戻った時にも、「id」パラメータを渡しておかないと
エラーになってしまう。
テストしたときに気づけばいいのだが、
入力ミスのテストは、少ししかやってないし、
やる気もあまりなく、公開直前に気付いた。
以上。
私がつくったアプリ↓
協調型意思決定支援システム「○ 賛否両論 ×(ベータ版)」
http://sanpiryoron.appspot.com/

協調型プロジェクトタスク管理ツール「キャッチ&リリース(ベータ版)」
http://ctchandrls.appspot.com/

DAYS 9 タスク管理ツール 「キャッチ&リリース(ベータ版)」

2009年10月25日 日曜日

新たにアプリケーションを作成した。
協調型プロジェクトタスク管理ツール「キャッチ&リリース(ベータ版)」
http://ctchandrls.appspot.com/

前回作成したアプリは、GAEでの初めてのアプリで、
GAE、Python、Bigtableの勉強と
Google Visualization APIと連携して、
かっこよくグラフだしたいなぁというような想いで作った。
でも、グラフは表示するようになってはいない。
今回のアプリは、タスク管理ツールなので
カレンダーAPI(Google Calendar APIs and Tools)と連携できたらいいなぁと想いで作った。
結局、Google Calendarとも連携はできなかった。
次回作は、Googoleドキュメント(Google Documents List Data API)との連携を考えている。
前回のアプリ作成での教訓は、
「できるようにやれ!」である。
こっちがいくら頭で考えていたことがあっても、
GAEには制約があり、その通りはならないこともある。
そういう時は、自分の考えを変えることである。
「できるようにやる」で運用と使用する側で対応するということである。
「システムより人間の方が能力が高い」ということと性善説を前提にしたシステムである。
ウォータフォール型のシステム開発では考えられない作る側が作りやすく仕様を変えてしまうやり方だ。
以下に、当初考えていたが変更した点を列挙する。
いわゆる、できないリストなので、注意されたし!
・プロジェクトチームというグループを作り、そのメンバーだけが、
「責任者」のselectボックスに表示させたかったが、
作り方がよくわからず、セレクトボックスには、ユーザー登録した全てのユーザーが表示される。
・ユーザーデータとして、「技術レベル」「対人スキル」「報酬ランク」を入れて
マネージャだけがそのデータを閲覧できるようにしたかったが、
権限、ロール、アクセス制御など大変そうなのでやめた。
・タスクのリレー、つまり、タスクをメンバー内でやりとりしたり、
タスク作業時間を計算しようとしたが、やめた。
タスクの報告・連絡・相談のやりとりは、
プロジェクト責任者とタスク責任者の間のみで可能。
・プロジェクトの進捗度を、
(全てのタスクの進捗度の和)÷(タスク数)で自動的に表示させようと思ったが、
タスクごとの負荷が違うので、やめた。
以上。

電子経済産業省アイディアボックスと賛否両論

2009年10月14日 水曜日

電子経済産業省アイディアボックスというものが実験的に運用されている。セールスフォース・ドットコムの「Salesforce CRM Ideas」をカスタマイズしたものらしい。
Salesforce CRMについてあまり知らないのだが、
これは、クラウドというか、Saasという形で提供されているのだろうか?
であれば、これまでのものより、かなりコスト削減になったかもしれない。
よくわからない情報としては、
「2週間」というキーワードだが、
意見の募集期間が2週間という認識であっていると思う。
「2週間」でつくったという意味にとらえてたので・・・。
同じようなものをGoogleAppEngineで作成、以下。
「○ 賛否両論 ×」
http://sanpiryoron.appspot.com/

経産省が
Salesforce.comを使うメリットは多くあると思う。
国内企業を顧客ととらえ、コミュニケーションツールして使えるし、
相手もSalesforce.comを使うとさらに便益は高まる。
コスト面に関しては言うまでもない。
特に中小企業は、Saasで提供されており、システムの初期費用、運用費用のハードルもかなりさがるうえ、行政との連携がとれることは非常に便利ではないか?
ただ、国として、
パッケージソフトウェアにたよる部分と
独自に作り上げる、または、管理する部分の
切り分けはできているのだろうか?
アイデアの募集はよいと思うが、
国の指針、評価基準、採用されて実現までのプロセスみたいなものが
明確になっていないと、意見を出す側も
「こんなことやって、意味あんの?」という気がするのではないか?
(ネガティブなものいいになってしまったので、訂正。)
国の指針、評価基準、採用されて実現までのプロセスみたいなものが
明確になっていれば、意欲的で優秀な意見が集まると思う。
システムが意欲を引き出すのではなく、
意欲を引き出す仕組みの一部分をシステムが担っているのである。

成田空港のゆくえ

2009年10月13日 火曜日

前原大臣の「羽田空港のハブ化」発言で、
千葉県が熱い。っていうか、政治家が熱い。
ただ、国民は冷めているのではないか?
正直、東京から遠すぎる。
外国人観光客はみんな文句を口々にする。
日本人だってそう思っている。
政治家がいままでどんな苦労があったか知らないが、
政治家は、選挙の時だけ、ハコモノも誘致の時だけで
目的があいまいだ。
利益や便益もないのに続けることは
税金を払っている国民を愚弄してはいないか?
これまでなにをしたか、そして、どんな結果だったかを考えれば、
成田空港の使えなさ加減は、明らかではないか?
ダムもそうだが、いままでやってきたからとか、
泣く泣く先祖代々の土地を離れたとか、
精神論、感情論で話をするのはやめてほしい。
政治家に数字の視点がなさすぎる。
もしかしたら、自分たちの数字(利権)については計算していて、
あえて、感情論をあおっているのかもしれないが・・・。