Douglas Crockford 在 Google Tech Talk 的一個演講: JavaScript: The Good Parts
RSS originated in 1999, and has strived to be a simple, easy to understand format, with relatively modest goals. After it became a popular format, developers wanted to extend it using modules defined in namespaces, asspecified by the W3C.
RSS 2.0 adds that capability, following a simple rule. A RSS feed may contain elements and attributes not described on this page, only if those elements and attributes are defined in a namespace.
The elements defined in this document are not themselves members of a namespace, so that RSS 2.0 can remain compatible with previous versions in the following sense -- a version 0.91 or 0.92 file is also a valid 2.0 file. If the elements of RSS 2.0 were in a namespace, this constraint would break, a version 0.9x file would not be a valid 2.0
最近剛好有機會接觸PostgreSQL
一部分的工作是將存在舊版PostgreSQL的資料 porting 至新版
在 porting 的過程當中，發現 PostgreSQL 8.3版針對 implicit type conversion 做了更嚴
所以~ 在舊版 PostgreSQL上面存在的一些default的自動轉型函式(implicit type conversion function)都被移除掉了
當然，過去寫的程式若是比較髒 (例如: 拿 integer 跟 char varing比較、Join)的SQL Statement在新版就會行不通~
比較用功的人~ 當然要藉機好好的review一下 schema的設計是符合理，schema, SQL Statement語句是否要調整~
但，如果影響範圍很大的話，倒是可以自已將新版拿掉的 自動轉型函式再補回去~
這樣 就不用改程式囉 :Q
以下是我在網路上找到，補在新版PostgreSQL的一些function，補上去後 原本的app就可順利執行了:
CREATE FUNCTION pg_catalog.text(integer) RETURNS text STRICT IMMUTABLE LANGUAGE SQL AS 'SELECT textin(int4out($1));';
CREATE CAST (integer AS text) WITH FUNCTION pg_catalog.text(integer) AS IMPLICIT;
COMMENT ON FUNCTION pg_catalog.text(integer) IS 'convert integer to text';
CREATE FUNCTION pg_catalog.text(bigint) RETURNS text STRICT IMMUTABLE LANGUAGE SQL AS 'SELECT textin(int8out($1));';
CREATE CAST (bigint AS text) WITH FUNCTION pg_catalog.text(bigint) AS IMPLICIT;
COMMENT ON FUNCTION pg_catalog.text(bigint) IS 'convert bigint to text';
最近在把原本佈署在 Resin 的 Java Web Application移植到 Tomcat 時，有許多原本正常的中文get / post 功能，都變的異常，只要是透過 get / post 得到的資料，就會變亂碼
剛好也驗證了 Resin 在Character Encoding的部分做的較好
而看看網路上大家的問題，也可以知道 Tomcat 在編碼處理的部分 真是讓很多人頭痛
主要的原因是，TOMCAT 預設都是用 ISO-8859-1 的編碼方式來傳遞資訊
這個問題，可以解決的方式整理如下:
1. JSP 頁面的編碼宣告需與實際儲存檔案時用的編碼一致
這是個很好玩的問題~ 有些人 在頁面宣告用 big5 or UTF-8 or... 字集
但是，檔案實際儲存的方式與該編碼不同，則 頁面當然會出現亂碼的問題
2. 自行轉碼
form method=POST or GET 時 因為Tomcat預設編碼是ISO-8859-1的關係
直接用 <%=request.getParameter("firstname")%> 取值，中文字會變亂碼
(你傳的明明是UTF-8, 但是讀取時 確用 ISO-8859-1來解譯.. 當然有問題囉)
要使用 <%=new String(request.getParameter("firstname").getBytes( "ISO-8859-1"), "UTF-8")%>這種方式 來轉換編碼才會正常 (假設，頁面用的編碼為UTF-8時)
3. 透過設定 server.xml URIEncoding的方式 來處理 GET 亂碼問題
在 tomcat 的設定檔內 ./conf/server.xml 修改下列設定的話，則透過GET的方式傳遞參數
的話，Tomcat會用你指定的編碼方式來對待用get方法傳遞的參數，而不是使用預設的ISO-8859-1 (get 的方式是透過 url parameter傳遞參數)
但是，因為只處理 URIEncoding, 所以若使用 Post 傳遞，還是會有問題
URIEncoding: This specifies the character encoding used to decode the URI bytes, after %xx decoding the URL. If not specified, ISO-8859-1 will be used.
P.S. 若使用 GET Method, 且設定了URIEncoding 的話就不用再做上述二的自行轉碼動作，如果多加該處理，一樣會有亂碼的問題
4. 使用 request.setCharacterEncoding 來處理 GET / POST 的亂碼問題
在處理的頁面，加上下列的處理即可，明確的告訴Tomcat request的編碼為何，不要一廂情願的使用ISO-8859-1來解讀~
<%request.setCharacterEncoding("UTF-8");%>
javax.servlet.servletRequest.setCharacterEncoding(string env)
Overrides the name of the character encoding used in the body of this request. This method must be called prior to reading request parameters or reading input using getReader(). Otherwise, it has no effect.
5. 使用 filter 來處理 GET / POST 的亂碼問題
這個方法是最方便的，只要在 web.xml 裡面 透過 filter 的設定，讓每個網頁都能
透過 filter 的處理一體適用所有編碼問題的解決
方法如下:
a. 目前 Tomcat 提供的範例裡面，就有現成的 Encoding Filter, 位置如下:
.\Tomcat 6.0\webapps\examples\WEB-INF\classes\filters\SetCharacterEncodingFilter.class
b. 所以，只要把該 class 檔，copy 到你的 web application 的
.\WEB-INF\classes\filter 下，再搭配 web.xml 的filter 設定，
就可以讓所有符合 url pattern 的網頁，都能自動apply所想要的編碼設定(透過 encoding這個 parameter來設定)，是不是很方便呢 ?
(這個功能 就像是自動把上述第四點的 setCharacterEncoding 語句 自動apply到各頁面囉)
------------
以上~ 就從 Resin Porting 到 Tomcat 的經驗，當然是使用 filter 的方式 一次解決~ 不然的話 就得每個網頁每個網頁去改囉~
延伸資料:
FAQ/CharacterEncoding
http://jim.blogsome.com/2005/05/27/jsp-chinese-character-solution/
http://www.javaworld.com.tw/confluence/pages/viewpage.action?pageId=752
每年的 3月14號，是商人的白色情人節，是很多數學狂熱宅男的Pi Day~
π(Pi) 這個數字 代表一圓直徑與圓周的比例~ 大約是
3.1415926535897932384626433832795028841971693993751058209......
到目前為止，大概已經被算出 一兆位了~ (天啊)
Pi 的符號π在1706年由 William Jones 首先使用
但在 1737年由Euler所引用 而廣為人知
有一個Pi Day的網站專門用來提供一堆跟Pi有關的資訊 這數字還真偉大 ><~ 想鍛鍊記憶力的人~ 這邊有100萬位數的Pi可以參考背誦~
Pi記憶的世界記錄目前是由一位中國人 Lu, Chao 保持，他在2005年時創下記憶67,890位數的世界紀錄，總共花了整整二十四個小時又四分鐘來將這些數字完整無誤的背誦出來
也有人把 Pi的每個位數 mapping 到鋼琴鍵盤，透過不同的mapping方式 弦律當然不一樣~這個人的mapping方法，彈奏出來的曲子 還滿好聽的呢:Pi Song
前言: 98/2/28 在做file copy時，突然電腦就當掉、畫面不動，想說... windows 本來就很不穩，重開一下就好了。結果...重開時...在BIOS階段的時間停的非常久，最後，出現「主硬碟磁區錯誤」的訊息，之後試了非常多的方法、搜尋了非常多網路的訊息，終於確認是因為Seagate H.D. 軔體(firmware)瑕疵所造成，雖說Seagate承諾firmware所造成的問題，並不會造成資料遺失，也會協助受影響的用戶回復資料。但是，依我找到的訊息以及本身的經驗，並不想將硬碟報修，原因如下:
Web Browser 的大戰 真的慢慢的展開了~
雖說 Chrome 以 process per tab 的方式，將不同的tab isolate至不同的process
Google 推出了新版工具列的Beta版本，包含:
Google Tool Bar 5 for FireFox 的 Beta版本 &
Google Tool Bar 6 for IE 的 Beta版本
但是還是一樣沒有提供for chrome的版本
用chrome對我個人來講最大的困擾是~ 少了google tool bar 真的讓我使用上較不方便
像是，bookmark就無法像裝了google tool bar一樣容易存取/跨電腦分享
不過 目前這版chrome大概只是為了驗證新的 process per tab 的概念跟rendering&javascript enginge的速度吧...
BTW, 新版的 Google Tool Bar 有些新功能
1. 可以把 google gadgets加到tool bar的按鈕列~ 用起來 有些噁心~ 個人覺的呈現介面太小了 看不慣，不過 把一些小工具做成按鈕 隨時可以叫出來 又不用回到更噁心的iGoogle就能用~ 個人覺的還不賴~ 也很符合google想把browser/Web當作OS的企圖
2. 把chrome那一套搬過來: 新增tab時 會把常上的網站、最近關閉的分頁(tab)、最近新增的書籤 都呈現在新分頁的預設畫面中 --> 個人覺的這功能 還算ok用
3. tool bar 的設定，可以跨電腦 share 囉~ 就好像shared bookmark 一樣
4. Quick Search Box(QSB)功能: 要裝 for IE 的 toolbar 才有
在windows的工具上 出現了Google的按鈕，按個 Ctrl+Space就可以開始進行搜尋
(因為Ctrl+Space被佔用掉了 所以 我是用Alt+Space) 搜尋的東西除了網頁，還包含
本機電腦的應用程式~ 當然 免不了的 也會有搜尋的提示 以及 針對搜尋的結果可執行程式 or 打開網頁的功能。印象中 MAC OS X 的Finder 也有類似的功能，這功能 真的很優~ 透過google toolbar 完全把微軟OS變棒了 :) 哈哈...
Google 的產品品質 一向是讓人非常滿意~
不過 最近 好像頻頻出錯~
包含
2009/1/31 因為惡意網站的設定問題(malware filter, http://stopbadware.org/)，讓google search出來的網站 都被標示上「惡意網站的標籤)
2009/2/24 Gmail outage, 聽說是設備當機?! 約二個半小時恢復正常
2009/2/27 上午使用Blogger時，發現 主頁資訊出不來，firebug show 出一些 javascript error
應該也是 google 出了什麼問題才對
其實，資訊系統出錯 在所難免 所以 我也不會像網友嘰嘲Gmail為 GFail.. 哈
反而覺的 google 還是有點人性的 :)
以後 系統出包，我們就可以把google的例子拿出來講 看可不可以擋掉一些炮火攻擊 哈哈..
Same Origin Policy(SOP) 是一般 browser 針對 client-side script(如java script) 在安全性上面的一項處理原則
由於 client-side script 是在使用者的作業環境中進行，而在使用者的環境當中，常有一些穩私性的資料(如 cookie, 瀏覽行為...等)，為避免這些 client-side script 去存取client端穩私資訊後 送交給無法限定範圍的遠端伺服器，所以 有了 SOP 這個原則
簡單講，就是client-side script不能存取所在網頁之外的資源
例如: 使用者目前瀏覽網頁為 http://example.com 上面有運行一些 javascript
依 SOP 的原則，browser 只會容許 javascript 存取 http://exmaple.com/* 下的資源
其它domain(e.g., http://malware.com), subdoamin(e.g., http://sex.example.com), domain 同port不同的(e.g., https://example.com)，browser都不允許 client-side script來存取
當然~ 目前 Web 2.0, AJAX, Mashup 大量運用到 client-side script的技術，所以 SOP 也變成這些新設計方法的一大限制
不過~ 上有政策 下有對策~ 還是有一些方法可以繞過這個限制，即 work-around solution
目前我知道的方法如下:
1. 透過proxy的方式處理
即在網頁所在的Web server 建立一 proxy功能，所有要繞過SOP檢查的client-side script存取 都透過這個proxy去拿或處理~ 這種做法的先決條件是，開發人員要有辦法在該 Web server 上面開發並佈署上這個proxy的功能
2. 透過 HTTP 內 document.domain 的設定 解決跨sub-domain的限制
透過 設定 HTTP DOM裡面的 document.domain 值
只要 script 所在網頁的 document.domain值 與 資源所在網頁的 document.domain值一樣
Browser即會允許存取
注意: 這只能用來解決 跨 sub-domain (e.g., AAA.example.com 及 BBB.example.com)
而不能跳離跨domain的限制
3. JASONP (JASON with Padding)
基本原理有3個
1. html 裡頭的 script src (即 script 的來源)並不限定只能在 local domain
2. 利用 javascript 可以操作 HTML DOM 的特性讓 javascript 動態的引用外部script
即，增加一 script type=text/javascript src=[...url + parameter + call back function] 的 tag
3. 透過 client-side script與不同domain的service的配合(有點暗通款取的味道)
讓 另一domain有動態吐出script 並配合在script內加入 client-side定義好的
call back function 的能力
所以，只要遠端的server支援JASONP，那麼就可以透過動態插入 script tag及script src，
來取得遠端的 script 資料(裡面可能含有動能改變的data 及client端的call back function)，script-client端 在動態取得這些所謂遠端的script資料後 即會在client端運行
這些script，透過callback function的機制 會再與原先設計用來handle JSONP的client端
script 碼有一關連性~ 最後 達到目的 繞過SOP的限制
下面應該是最早提出JSONP的的文章: Remote JSON - JSONP，我認為比較難懂
下面這篇文章，我認為較淺顯易懂: 利用 jsonp 进行 Javascript 的跨域数据访问
--
其它參考: wikipedia: SOP
Google 去年四月推出的 Application Engine 服務
提供免費的運算資源供開發者佈署開發完成的程式供Web User使用
限額是每月不超過 500萬個 page view
今天在 app engine 的blog看到，GAE公佈了收費模式
文中提到~ 雖然目前提供限額的免費資源
不過 使用者的使用狀況可能太好了 使得 目前資源有不夠的狀況
未來，雖仍會提供500萬個page view的免費quota, 不過資源會在90天內做適度的調整
(一定是調小的啊...)
若要取得額外的Quota, 則需另外付費
下列是我目前用的免費帳號的 resource 分配狀況
依照google 的計價方式的話，1個app google 每天免費送你 7.035塊美金耶 :Q
聽起來還滿爽的唷 :) 呵呵...
依這樣的 Service Level, 一年大概二千六百塊美金, 折算台幣約九萬塊~
不用maintain 底層的infrastructure, 機房, 電力, 備援, ... 等有的沒的... 我想 這種價格應該算值得吧 :)
| Resource | Budget | Unit Cost | Paid Quota | Free Quota | Total Daily Quota |
|---|---|---|---|---|---|
| CPU Time | n/a | $0.10/CPU hour | n/a | 46.30 | 46.30 CPU hours |
| Bandwidth Out | n/a | $0.12/GByte | n/a | 10.00 | 10.00 GBytes |
| Bandwidth In | n/a | $0.10/GByte | n/a | 10.00 | 10.00 GBytes |
| Stored Data | n/a | $0.005/GByte-day | n/a | 1.00 | 1.00 GBytes |
| Recipients Emailed | n/a | $0.0001/Email | n/a | 2,000.00 | 2,000.00 Emails |
| Max Daily Budget: | n/a | ||||
Google 也出漫畫了哦: Google Chrome Comic
Google委託了Scott McCloud這個畫家，透過與20多位google engineers的interview
用漫畫的方式，呈現出 chrome發展的背景以及重要的設計
若即早報名今年的Google I/O活動，主辦單位會送你一本hard copy 哦 :)
以下是我從這本漫畫看到的一些重點:
* 因Web application日漸普及，Browser也變成一執行application的重要平台，有重新發展以因應需求的需要
* 有別已往整個browser在OS看來是single process的設計
chrome 是採 multi-process 的架構，即一個 browser tab 為一單一的process
整個browser不會因為單一tab crash掉，而整個browser都垮掉
* 採用 WEBKIT opensource rendering engine (與 Safari相同)
提升頁面處理效率
* garbage collection 更有效率
過往single-process model, 在關閉單一Tab時仍可能有部分resource沒被釋放掉，
由於 memory fragementation的關係，在另開新tab時 因為剩餘的address space不夠
仍需再allocate新的address space供該process使用，久而久之就算把tab關掉 也無法解決
browser佔用大量resource導致系統變慢的可能
筆者不論在 IE/Firefox 都真的有這樣的經驗，最終 只能把整個 browser關掉、重啟來解決
Chrome 的 multi-process的model 每個 tab 都是獨立 process 在關閉tab時 resource是完全釋放的
* 每個Chrome Tab 所花用的 cpu/memory 都可透過其 chrome task manager來檢視其資源使用狀況，更容易找出來執行效果不佳的web site為何
* 透過大量的設備及page rank資料，進行涵蓋面廣且抓到重點web site的自動測試
以確保chrome的品質
* 採 V8 javascript virtual machine 提升 java script 處理效率
V8為 位於丹麥的google 團隊發展，並有 opensource 供它人使用
* V8對javascript 的處理，採用 dynamic code generation的技術，將java script compile為
machine code執行，更快、更有效率
(有別一般 interpret式的 java script engine, 每次要執行 javascript時 都要重新interpret一次)
另，有別過往javascript virtual machine 對 garbage collection 採的 conservative garbage collection機制，因java script都被v8 轉成machine code了，故可對memory使用有精確的常握，
故可採用 precise & incremental 式的garbage collection, 讓記憶體的回收更有效
* OMNIBox 做為 URL 的輸入列，但又不同於過往的URL Bar
除提供url auto-completion功能外，亦會依user的瀏覽歷史 做出類似搜尋+字詞提示的功能
假設，今日我瀏覽過一個汽車網站，我也許只要在 OMNIBox內打上 C.. 就會出現該網站的URL..
* NEW Tab的處理
不同於browser的home or 空白頁設定
Ghrome依 user 在 OMNIBox的輸入及瀏覽歷史，在 new tab 內會呈現出
最常光顧的站台 & 搜尋供user直接點選
* 提供privacy mode(無痕模式)
即，提供一個readonly 的瀏覽環境，google 會在該chrome tab(process)關閉後清除所有資料
(包含 cookie, brows history....)
* 針對 malware / phishing site 的處理
- SANDBOX設計 讓browser被攻陷的機會降低
- 持續自動更新惡意網列表
* Google Gears (Opensource)
為一Browser extention的API，可擴充 browser能力(含 chrome)
以提供更進階的 web application所需
當然，google 也想讓這個東西 變成一個標準
那麼，未來的 web app 與傳統跑在os上的app 的距離會日漸縮小
* Google Lives on the Internet --- google 也希望透過 OpenSource 的無私精神
釋出上述多項技術的opensource 供研究發展 讓 Web 的應用能快速進步
--
以上~ 儘量寫囉 應該也是有不少寫錯的東西啦 :Q
Google 的街景圖示做的真的太細太屌了啦 :)
這是 Google Map從幾年前開始的計劃
早先的 Google Map 先是有衛星圖、接著 加入國界、地區街道標示、地圖後...
更恐怖的這個街景圖是 google 用車子 沿街拍出來的
最早只有美國部分地區有 現在美國應該已經做全了
日本也有很多地方的街景都拍好了 也在google map 上可以看到
台灣則是預計今年會開放這項服務 (這禮拜一 剛好在看到google street view的工程車在信義路上拍 我還故意在他後頭停留了一下... :) )
anyway, 既然日本拍好了 我也去日本玩過 就去找了一下當時的照片...
我只能說 google 太強了... 看看下面的對照你就知...
1. 小樽運河旁-Google 版
google map link
MinChuan比對版:
2. 小樽運河旁-Google 版
這裡是小樽運河，三點鐘方向那間小木屋是 小樽觀光案內所
MinChuan比對版:
一群高中女生班遊吧~ 在小樽運河旁 被我偷拍 :Q
3. 小樽郵局-Google 版
MinChuan比對版:
4. 六花亭 北果樓 -Google 版
google map link
MinChuan比對版:
這兩家賣的菓子很有名哦~ 我也有買說 ;)
------------------------------------------------------------------------------------------------
Google Car 長這樣 (引用自 http://www.ithome.com.tw/itadm/article.php?c=52744)
Google Gadgets API 目前提供兩個版本
新的版本使用 gatgets.* 這個 namespace，主要看起來 是加入了 OpenSocail 的功能
舊的版本使用 _IG_ 這個namespace
下列是一些開發的小要點:
A. Gadgets 組成
Gadgets的開發之所以很簡單，是因為 Gadgets只需用一XML文件來描述所謂的Gadgets Spec.
即可完成 Gadgets的開發，在Gadgets Spec.中 除了透過XML 宣告一些屬性供Gadgets Container參照以決定Gadgets的重要特性外(如，這個Gadgets的一些user偏好屬性、tabs的支援、標題作者資訊...等等)，再來就幾乎是 html + javascript(AJAX) + css 的開發了
下列是一個Gadgets Spec XML 的長像...
* Content type = html 時
- 將 html/javascript/css/...等直接寫在 gadget spec. 內 (該XML檔案)
- 只能包含 body 內的東西 不含 head/title...等外層element
- google 建議使用這種，此種做法 gadget 除在 iGoogle可用外，其它support gadget的container亦可使用(如, Google map, Orkut, YouTube, ...)
-
* Content type = url 時
- gadget 的血肉，是透過 url 去參照另一個網路上的html文件
- 只能在 iGoogle中使用
C. 使用者偏好設定- 透過
E. 測試 & 除錯
只要在 gadget spec 內定義好，屆時佈署於gadgets container時，gadgets container即會render出
這些偏好選項供user設定，並可被 gadgets的主體程式所參照引用。
- user preference可設成share，即 可透過這個特定 在不同user中 share資訊
- 由gadgets container來管理/儲存 針對各別gadgets user的 UserPref設定，開發者無需介入處理
D. 佈署及安裝
- 佈署: 將撰寫好的 gadgets spec (一個XML檔案) upload到internet上的任何一處即可
- 安裝: 使用者在Web Container上，新增一gadgets並給定該gadgets spec的 URL即可完成
- 因為deploy只是一個upload xml 的動作，所以我是隨便找一個web container(即, blogspot)來測試開發出來的gadgets
- 可利用firebug之類的browser addon 來進行 gadgets的除錯 (通常是 javascript 的問題)
F. 範例
寫了一個簡單的 Feed Reader gadgets，可透過 UserPref來設定抓取的 feed lists URL
並將Feed內項目的 title, link, summary 資訊show出
Gadgets Spec(source code)置於: http://minchuan.wang.googlepages.com/MinChuan_RSS.xml
Reference:
發表文章
