The Google App Engine is launched for a while and many creative works have been developed. Since Google App Engine is provide by Google itself so it should be easy to process single sign on by using Google account. It's true for partial: according to the official document of GAE, developers could use User API to integrate with Google account easily.
However, if your application would like to communicate with other Google web services such as Google mail, Picasa Web, Google calendar ... etc, and tend to provide a single sign on interface to avoid too many authentication process for users then the solution of User API is totally not enough.
To achieve this goal, we need to use another Google API called "Account Authentication API". It's pretty much a Google version of Yahoo! BBAuth. The operation process to both solutions is very simular but Google's implementation provides better administrative interface.
2008年9月25日 星期四
2008年9月17日 星期三
An ideal software development schedule
For those software development rookies, estimating an accurate time table for the tasks assigned to them seems a difficult job. Project manager always faces the same situation here: an repeatable development deadline postponement. As a developer with 4 years working experience, I still make a promise to my project manager sometimes to claim that the job could be done within x days no more. And usually I need to make an apology and ask them to give me more time to complete the task. Why such things always happen? Why developers couldn't avoid it happens? And no matter what new software development strategies or new development tools come out, the problem never be solved completely.
An important reason that developer underestimates development time is they only think about one feature at the time and miss the intersaction part in certain of functions. It usually happens on the rookie developers who have limited working experience or rarely join a scale software project. Also by the specification they made, we see the ambiguious design and roughly features. So for the co-work developers, it is hard to understand the whole picture in the blue print. Maybe for the rookies themselves they don't have a clue too! They just try to illuminate their idea by an immature mind.
Another key is developers always put too much features into "must have" list. They never figure out what kind of features are necessary and what kind of features should be considered as "nice to have". They always dream a fantastic picture about their software is going to be and are unable to see the implement difficulty. Well, in my words, developer especially rookie just like the share investor who always have a great confidence to the market and refuse to be aware of incoming bear wave. They will learn from the failure and grow but not now. They need to fall down at least one time to gain the experience and no short cut for them.
An important reason that developer underestimates development time is they only think about one feature at the time and miss the intersaction part in certain of functions. It usually happens on the rookie developers who have limited working experience or rarely join a scale software project. Also by the specification they made, we see the ambiguious design and roughly features. So for the co-work developers, it is hard to understand the whole picture in the blue print. Maybe for the rookies themselves they don't have a clue too! They just try to illuminate their idea by an immature mind.
Another key is developers always put too much features into "must have" list. They never figure out what kind of features are necessary and what kind of features should be considered as "nice to have". They always dream a fantastic picture about their software is going to be and are unable to see the implement difficulty. Well, in my words, developer especially rookie just like the share investor who always have a great confidence to the market and refuse to be aware of incoming bear wave. They will learn from the failure and grow but not now. They need to fall down at least one time to gain the experience and no short cut for them.
2008年9月3日 星期三
Using the Datastore in Development Web Server of Google App Engine
一個朋友在開發 Google App Engine 的 app 時對於 Development Web Server 的 Datastore 操作有所疑惑,所以特別將 Official Website 上的說明翻譯在此,
Development web server 是以 local 檔案的方式來模擬真實狀況的 Datastore,這些 local 檔案在每次 web server 的服務期間均會保持,所以你所儲存的資料在下次 web server 啟動時依舊存在。如果 developer 想要強制清空這些已儲存的紀錄,必須於命令列下達『--clear_datastore』:
dev_appserver.py --clear_datastore myapp
在每次 developer 於命令列啟動 Development web server 時,作為 Datastore 的 local 檔案路徑會輸出於螢幕上,developer 可透過備份該檔案達到保存某特定資料儲存狀態的需求,在需要時隨時將備份的檔案覆蓋回原檔,即可回復當初的資料狀態。唯特別注意的是,執行上述的覆蓋動作之後,必須重新啟動 Development web server 才會生效。另外,developer 亦可使用『--datastore_path』選項來指定該 local 檔案的儲存路徑:
dev_appserver.py --datastore_path=/tmp/myapp_datastore myapp
當程式對 Datastore 發出 query 需求時,Development Web Server 會檢查該 query 動作是否有在應用程式的 index.yaml 設定檔案中被支援。若該 query 必須被註明在 index.yaml 檔案中而 index.yaml 此時沒有該筆設定,則 Development Web Server 會自動將該筆 query 的設定加入 index.yaml。Developer 亦可自行編輯 index.yaml 以加入那些沒有在測試中執行過的 query 條件。
index.yaml 檔案會在 Datastore 檔案建立或清空後的任何一次 query 動作發生時自動產生。而每次的 query 歷史紀錄均會記錄在一獨立檔案,developer 可以使用『--history_path』選項來更改歷史紀錄檔的儲存路徑(就跟更改 Datastore 檔案路徑類似)。
若想深入瞭解 indexes 或 index.yaml 設定檔,請參考 official document 的『Queries and Indexes』和『Configuring Indexes』部分的說明。
原文出處:http://code.google.com/appengine/docs/thedevwebserver.html
Development web server 是以 local 檔案的方式來模擬真實狀況的 Datastore,這些 local 檔案在每次 web server 的服務期間均會保持,所以你所儲存的資料在下次 web server 啟動時依舊存在。如果 developer 想要強制清空這些已儲存的紀錄,必須於命令列下達『--clear_datastore』:
dev_appserver.py --clear_datastore myapp
在每次 developer 於命令列啟動 Development web server 時,作為 Datastore 的 local 檔案路徑會輸出於螢幕上,developer 可透過備份該檔案達到保存某特定資料儲存狀態的需求,在需要時隨時將備份的檔案覆蓋回原檔,即可回復當初的資料狀態。唯特別注意的是,執行上述的覆蓋動作之後,必須重新啟動 Development web server 才會生效。另外,developer 亦可使用『--datastore_path』選項來指定該 local 檔案的儲存路徑:
dev_appserver.py --datastore_path=/tmp/myapp_datastore myapp
當程式對 Datastore 發出 query 需求時,Development Web Server 會檢查該 query 動作是否有在應用程式的 index.yaml 設定檔案中被支援。若該 query 必須被註明在 index.yaml 檔案中而 index.yaml 此時沒有該筆設定,則 Development Web Server 會自動將該筆 query 的設定加入 index.yaml。Developer 亦可自行編輯 index.yaml 以加入那些沒有在測試中執行過的 query 條件。
index.yaml 檔案會在 Datastore 檔案建立或清空後的任何一次 query 動作發生時自動產生。而每次的 query 歷史紀錄均會記錄在一獨立檔案,developer 可以使用『--history_path』選項來更改歷史紀錄檔的儲存路徑(就跟更改 Datastore 檔案路徑類似)。
若想深入瞭解 indexes 或 index.yaml 設定檔,請參考 official document 的『Queries and Indexes』和『Configuring Indexes』部分的說明。
原文出處:http://code.google.com/appengine/docs/thedevwebserver.html
訂閱:
文章 (Atom)