幹壞事是進步最大的原動力
如果是自己搞網站 (程式美術都自己來)，用 Zend_Form 設定完後，透過 render() 將 HTML code 呈現的確不錯，畢竟強迫你要用 CSS 去處理頁面呈現。不過，如果是請別人先做好美術版面，產生 HTML 後才要轉成 Zend_Form 生出來的話，就會用到很多 manual 裡不會教的「壞方法」XD
目前用到的方法是在 view 裡面 (我用 Zend_View) 直接顯示 Element，像是這樣：
<?= $this->post_form->post_title ?>
但只用上面的方法會產生一堆 dt + dd 之類的東西，這是因為 Element 預設的 Decorator 太多，所以需要重設只用 ViewHelper：
$element->setDecorators(array('ViewHelper'));
其他的在原來的 tutorial 都有寫。
另外有點很重要，因為 Zend_Form 在 1.5 版才納入，所以文件並不一定能夠涵蓋所有的方法，看 source code 瞭解用法的能力很重要…
今年四月四日正式發佈的 Unicode 5.1.0 (Unicode Version 5.1 Released)，Google 也在五月宣佈正式支援這些新的字元：Moving to Unicode 5.1。
Google 除了宣佈支援 Unicode 5.1.0 以外，也分析了目前網頁編碼的比例。UTF-8 編碼網頁所佔的比例超越了 ASCII & ISO8859-1，而且還不斷在成長…
幫我們公司徵人 :p
要徵熟悉 PHP，以及 MySQL 的正職 coder 兩名，工作地點在台北市民生東路二段這邊，有興趣的人請將履歷寄到 104@pixnet.tw，標題請寫上「應徵 PIXNET 程式設計師」。
這份工作主要的內容是寫 PHP，如果熟悉 Zend Framework (目前我們用這個開發) 或其他 Framework 更好。
有問題除了可以在 comment 問以外，也可以直接寫信到 gslin at pixnet.tw 問我。
本來要寫「一些 Zend_Form 地雷」，結果整理起來還不少，還是改成「很多地雷」比較合理。
第一個地雷是 select 元素：
$el = $this->createElement('select', 'siteshow');
$el->setLabel('是否顯示下一頁');
$el->addMultiOption('1', '顯示');
$el->addMultiOption('0', '不顯示');
$this->addElement($el);
對這個元素設定值時，要記得用 intval() 轉成數字，像這樣：
$f->siteshow->setValue(intval($dbval['siteshow']));
第二個地雷是 setRequired() 的處理，假設你這樣寫：
$el = $this->createElement('text', 'article_title');
$el->setLabel('文章標題');
$el->setRequired(TRUE);
$this->addElement($el);
因為 setRequired 是使用 empty() 判斷，所以標題取 “0″ 時就會過不去。目前的解法是用 stringLength 指定最小與最大長度：
$el->addValidator('stringLength', FALSE, array(1, 255));
$el->addValidator('stringLength', FALSE, array(1)); # 沒有最大長度限制
第三個… 忘記了，想到再寫 Q_Q
老闆的老闆說 ok，所以…
遊戲基地與 PIXNET 是同一個集團，而巴哈姆特與大頭們都相當熟識。我本來星期一請假，下午三點把事情處理完回到家準備要睡一下，四點就接到急 call 電話，弄到隔天凌晨四點才回家…
攻擊的模式是大量 IP 用發出大量 HTTP 連線，所以暫時性的解法朝著壓低連線限制，而且要儘快，最好是有現成的設備直接做，不要自己用軟體調整參數調半天。
Gamebase 有將近一打的 Web server，是 Alteon AD3 撐不住所以掛掉，(中間有一堆測試的過程就不講了)，最後是在前端放一台 Cisco ASA 5520，然後用 HAProxy 換掉 AD3。但 ASA 5520 不夠力，目前還是請 ISP 先做一些處理。
巴哈姆特因為架構比較單純，所以前端放了 Cisco PIX (型號忘了…) 擋著，放上去後站方也是請 SEEDNet 幫他們先做一些處理。
其實我並沒有幫到什麼忙，主要還是 SI 願意賣面子先借硬體設備處理。我只是大概知道要朝哪個方向，聯絡哪些單位而已。
本來今天是請假的，結果下午四點被急 call 處理事情，這加班的內容… 一整個冏啊… (抱頭)
Update：兩個網站的消息都出來了：
login.aol.tw 沒有去買正式的 SSL Certificate 而是自己弄？這是認真的嗎…
第二天的一大早就到會場了，分成兩個場地同時進行議程。
第一場我去聽 Gene 所講的「Open Source, Open Standard, Open Service (OS^3)」，其實我對於 {Gene,askareiko,wildcat} 三人組 (也就是部落格觀察上方的 {G,A,W}) 很不滿，原因請參考我在兩個禮拜前寫的「部落格觀察」這篇文章，以及下方 Gene 所回的 comment。
不過我聽完後就發現沒有必要講什麼了，花時間跟他解釋只會浪費體力與時間，聽到要開始 Q&A 就閃人了。
接下來是 clkao 講 SVK，主要是 SVK 2.2 的新功能，不過還沒測試過，等正式版釋出後再看看 branch 的行為。
再來是高橋メソッド講 Ruby 1.9 的過去與現在，其中 Benchmarking 的部份蠻奇怪的，會場上測試的數據顯示 Ruby 1.8 花了很多時間在 “sys” 上，而 1.9 改善了這個部份，所以速度快了許多，但這是在純粹只有數學運算的 function 跑出來的結果？這個問題到後來還是沒有答案，先放著再說。
另外高橋先生沒有提到關於 Ruby 1.9 對 GC 的處理是蠻可惜的，這個反而才是重點…
接下來是 Jserv 講的「許我們一個 Keroro 的桌面」與 clkao 講的「Prophet: A Distributed Syncable Database」，這兩個 talk 都很歡樂 :p
中午休息時間，大家各自去吃東西，還是有些人留在會場聊天…
幾天前就一直有消息，Google 打算要把 BigTable 的服務拿出來給大家用。結果拿出來的餅比預期的更大，直接幫你 Hosting 整個服務：Google App Engine。
Google App Engine 目前以 Python 為語言 (更仔細的說，是以 Django 為參考的標準，所以有用過 Django 的人會蠻熟悉的)，後端則是以 GFS 與 BigTable 支撐整個系統。Hosting 的服務以 appspot.com 這個獨立域名避免 Cookie 與 XSS 安全性的問題，看起來是呼應 blogspot.com。
昨天一睡醒看到有一萬個人的註冊限制，就先丟進去註冊，出門到公司就發現已經申請到了。
另外，這個系統有一些限制：500MB storage、200M CPU cycle/day、10GB bandwidth/day，這個量對於自己玩看起來是沒什麼問題，等到收費後要看看價錢到底如何。
在開始玩之前，看看 The Datastore API 可以知道 BigTable 可以做到的事情，其實還蠻有趣的，像是不支援「!=」… XD
Update：在「TechCrunch Labs: Our Experience Building And Launching An App On Google App Engine」這篇裡面有後台的畫面，可以看到相當多資訊！
在 ImageShack Starts Free BitTorrent Download Service 這篇看到 ImageShack 開始提供 BitTorrent 下載服務了。
看了一下介面，把 torrent 檔傳上去後就會開始抓，另外一個比較特別的功能是選擇下載的檔案 (在 Windows 上的 BitTorrent 軟體還蠻常見的功能)。開 µTorrent 同時抓可以看出用的是 Transmission 1.10。目前服務在 beta，有兩個 15GB 的限制，一個是空間，一個是每個月的 HTTP 下載流量，在正式上線後可能會有修改。
丟了一個 torrent 上去測，下載到 ImageShack 的速度好像還蠻快的，不過我沒測完 :p