Neo's Blog

[PHP] RobotAway 發文不用再輸入驗證碼

討厭每次都發文都要打一串數字嗎?

剛剛在酷學園看到 ricky 寫的:
http://www.ez2.us/~ricky/RobotAway/

看起來還不錯，但沒時間去玩。之前也有想過這種免輸入驗證的機制，不過也一直沒時間去實作出來。XD

我猜 Y! 拍也有免驗證碼的防堵機制，詢問拍賣商品問題的時候除了要登入外，也不需要額外輸入任何驗證。但是 Yahoo! 家族的驗證碼就很恐佈了，像這個大概沒人看的出來是啥吧。

現在網站加入 CAPTCHA 這個都很自然了，還有要用人腦去想圖的，真是五花八門:

(1.輸入名字按 submit。2.選三張屬於自然界的圖。3.驗證)

延伸閱讀:
[HumanAuth] 自然圖型的驗證碼

莫名的一攤水

昨天晚上，我到廁所的時候發現浴室裡面有一小攤水。

我很確定我浴室的門有關好，至少我還是開門進去的。

這攤水哪來的?

難到這也是鬼月效應嗎?

仔細一看，原來是我們家小狗亂尿尿...

XD，不對呀，門都關的好好的，他是怎麼進來尿的?

GOD，電影驚悚片的爆點出現了..

難道這隻跟我一起生活多年的小狗早掛了..

關著門的浴室也能進來尿..

當然這種事不無可能...

只是...
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:

最好是鬼魂會尿尿啦..Orz

ZRM for MySQL 即時備份的新選擇

備份機制對於 MySQL 來說是最弱的一環，當中最難處理的就是 InnoDB 備份，除了透過 mysqldump 這種原始的方式之外，還有 MySQL 官方提供的手動備份資檔案的方式。然而唯一可以即時備份 InnoDB 的軟體又只有 InnoDB Hot Backup 壟斷整個市場。(諷刺的是，現在已經是 Oracle 的公司了)

所以只要談到 InnoDB 的即時備份，也只能乖乖的每年繳保護費給 InnoDB Hot Backup 了。

然而，在 2007 年初 Zmanda 在 MySQL 發佈了MySQL Backup & Recovery for the Enterprise，也正式宣告這些令人困擾的備份方式將有所改變。

Zmanda Recovery Manager for MySQL (以下簡稱為 ZRM for MySQL) 不但有 InnoDB 的即時備份、定時自動備份功能，還有 Incremental backup 以及 Granular recovery、Selective recovery。

(ZRM for MySQL 與 MySQL 常見的備份方式比較)

ZRM for MySQL 不但功能強大，而且還是 OpenSource 的軟體，想要了解 ZRM for MySQL 其它強大的功能，可以從下列的網址下載簡報:
http://downloads.mysql.com/webinars/pdf/Zmanda_Jan_17.pdf

ZRM for MySQL –Downloads
http://www.zmanda.com/download-zrm.php

ZRM for MySQL –Wiki
http://mysqlbackup.zmanda.com/

ZRM for MySQL –Forums
http://forums.zmanda.com/

延伸閱讀:
MySQL AB: Backing Up and Recovering an InnoDB Database
Jeremy Zawodny: MySQL Backup & Recovery

台灣的消費環境，需要你我一起把關

大概二年前的新聞:
長途客運 開放寵物半票搭車

(圖片來源)

根據昨日通過的收費要點，未來民眾可攜帶搭車的寵物，為長、寬、高不超過30公分的小型寵物，且不得具有攻擊性，蛇、鱷魚等寵物初步均排除在外，民眾將小寵物攜帶上車，需放置於籠、網、簍等物件，並將寵物放置於座位下方。

這個收費不合理的地方在於，同樣買半票，為什麼寵物不能坐椅子?

當然有人會說: 肯載就不錯了，還要有位子咧~

即便是飛機也有類似的規定:
http://blog.xuite.net/kaipolly/kaipolly/316325

國內線飛機按照行李託運的價格收費還說的過去，國道客運比照乘客收費卻又無位可坐，實在相當不合理。(或許另訂寵物票價也是一個方式)

這跟今年4月起開始施行有價票卷(如禮卷、回數票、儲值卡、預付卡..等等) 不得限制使用期限是一樣的。

消費者先花了錢買，為什麼要限制使用的時間?
在過去業者也會拿促銷期、有時限才有特惠鬼話來呼攏消費者。

(圖片來源)

消費者預付購買票卷及儲值卡可以提高業者的現金支付能力，業者給予折扣已經是理所當然，如果還限制消費者的使用時限以加速消費循環，根本就是一頭羊剝二層皮。

這次我坐某客運回去，已經取消了寵物要收費的限制，還算有點良心。但是必須要坐司機旁邊...Orz (不過我坐了二趟，司機也不喜歡旁邊有人，只要上面有位子還是可以坐)

台灣發展到現在，消費環境已經愈來愈好了，但是詐騙、黑心商品...仍層出不窮，許多商家枉顧消費者權益的事件也需要大家一起來糾正。

遇到消費糾紛，消基會是國人第一個想到的"民間團體"，但是還是能看到有人把消基會當成是國家單位來罵，自己卻不盡一點心力，實在很無奈:
http://www.mobile01.com/topicdetail.php?f=294&t=365575

消基會多次傳出財務危機不足已經不是新聞了，如果手頭上也有點小錢，也可以考慮贊助消基會，一同為台灣的消費環境加油:
http://www.consumers.org.tw/unit510.aspx

至於為什麼消基會常常沒錢，可以參考這裡。

今年創業的 Blogger 還真不少..

本來習慣用的 RSSBandit 因為新版沒有中文語系而且又佔資源，而且最近工作繁忙，已經很久一段時間沒在看 RSS了，直到上星期開始就改用 Google Reader，比較接近我習慣的閱讀方式。

註: 本來我比較喜歡的 Web RSS Reader 是 Rojo，不過對中文支援差，以分類閱讀也會有問題，後來也就想到才用一下

換了新的 Reader，也開始把 Feed 整理一下，很多人的 Blog 也久久沒更新了，因為訂閱Feed 實在太多，只好逐一清查了。

整理的過程中發現，今年開始創業的知名 Blogger 還真不少。

hlb --- 和多工作室

(黃綠紅? 哇...王力宏呀~~)

Mr.6 --- VOOFOX

才剛放上去就有低調的 Blogger 說不要公開，砍到現在只剩 2 則了...Orz
看樣子應該還有很多 Blogger 在鴨子划水創業中...XD

Bluehost 本日 Ping 的回應時間

Bluehost 是繼 Dreamhost 之後，Blogger 們大力推薦的國外超值虛擬主機。我也跟 Sam 借了帳號看了後台，如果 Bluehost 有比較好就來搬了，不過介面操作起來比起 Dreamhost 的彈性還是差了一大截，就只有列入觀察對象了。

今天正好颱風天，難得可以看 Blog 小小休息一下，不過逛到用 Bluehost 的 Blog，怎麼出來的時間那麼久，一 Ping 之下還真的傻了..

C:\>ping www.sharecool.org

Pinging sharecool.org [69.89.31.77] with 32 bytes of data:

Reply from 69.89.31.77: bytes=32 time=3281ms TTL=51
Reply from 69.89.31.77: bytes=32 time=3308ms TTL=51
Reply from 69.89.31.77: bytes=32 time=3370ms TTL=51
Reply from 69.89.31.77: bytes=32 time=3434ms TTL=51

Ping statistics for 69.89.31.77:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3281ms, Maximum = 3434ms, Average = 3348ms

另一個用 bluehost 的 Blog 也一樣:

C:\>ping blog.nahoya.com

Pinging blog.nahoya.com [69.89.31.110] with 32 bytes of data:

Reply from 69.89.31.110: bytes=32 time=3276ms TTL=51
Reply from 69.89.31.110: bytes=32 time=3191ms TTL=51
Reply from 69.89.31.110: bytes=32 time=3196ms TTL=51
Reply from 69.89.31.110: bytes=32 time=3144ms TTL=51

Ping statistics for 69.89.31.110:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3144ms, Maximum = 3276ms, Average = 3201ms

暫時不敢想搬家到 Bluehost 的事了。XD

企業該不該採用 RoR 開發專案?

企業該不該採用 RoR 開發專案? 這是很多人都有想過的問題。

以企業的觀點來看，絕大多數的答案是「No!」

RoR 開發的速度的確很快，但是以 RoR 目前的狀況還沒有穩定到可以讓企業做為主要開發的語言。而這裡所指的穩定不單指系統執行上的穩定，而是人力及開發資源上的穩定。

解決問題的時間遠比開發的時間還長

或許用其它語言要 1 天才能開發出來的程式，用 RoR 不到半天開發出來了，正沈醉在快速開發的喜悅中時...卻發現在執行上出現一個不知何故產生的問題。翻遍網路上所有資源，在社群上發問也沒有結果，因為你可能是全世界第一個遇到這個問題的人，只能自力救濟一步一步的找出問題發生的原因，並且想辦法解決它。而這段時間卻有可能花上3天到一個星期。

人才尋找不易，人力青黃不接

緊接著遇到的問題是，企業在業務擴張後的人力去哪找。104 的履歷在一個月內都不一定會出現一個 Ruby 的。就算出現會 Ruby 的也不一定熟 Rails，而且必須了解對方的工作意願，是否有機會共事...等等，更不要說進來之後還有可能根本就不適任。

最差的狀況就是自己重新訓練一個人，以目前就業市場來看，學 Ruby 只能靠興趣、靠熱誠，有了實作經驗對未來工作是不是有幫助就看每個人怎麼想了。但是訓練新人學 Ruby 也回到一開始的問題，開發資源太少容易造成學習曲線過長，很容易就把人給嚇跑了。

極易造成業務拓展的絆腳石

使用 RoR 開發專案，對於以 RoR 為主要技術的公司或許沒問題，但是客戶可是會有意見。絕大部分的客戶不會希望花錢買了一個只有少數公司能維護的產品，很容易有"花錢讓人捏著脖子走"的感覺。尤其大型企業還會要求內部要有人力可以維護專案，而且還要有原廠在台灣服務，這也是為什麼大企業還是喜愛 Microsoft 跟 Sun Java Solution 的原因之一。這個連 PHP 都很難打入的大企業市場，RoR 要打進去更難。

快速開發的原罪? 屬性適合最重要

從 RoR 衍生出的諸多問題並不是代表這個技術不好，而是"現階段"的 RoR 很容易把專案工作內容由減法轉為加法，企業必須去承擔快速開發所帶來的二面刃，以及許多無法掌控的變數。

每個專案的在執行的過程一定有其適合使用的技術，當然一定有專案以 RoR 開發是最佳的選擇。因此企業在採用 RoR 做為開發技術之前，絕對需要經過審慎的評估。而目前已經採用 RoR 的企業，也要有回饋 RoR 社群的心，透過良性的循環才能讓每個創新的 Web 技術變的更好。

延伸閱讀:
約耳-語言戰爭 (正體中文)
Why PHP is the choice language - a business owners perspective.
何飛鵬: 工作的加法邏輯

用 PHP 實作 ActiveRecord

剛剛本來寫了一大堆，結果一存檔網站就斷線了。現在帶過去就好..Orz

PHP 跟 Ruby 先天上語法就不同，Ruby 的特性就是 "Everything is an object"，因此要用 PHP 要實作出 ROR 的 ActiveRecord 也有相當的難度。

PHP and ActiveRecord:
http://www.actsasflinn.com/articles/2007/08/08/php-and-activerecord

再來就是看 Mix-ins 的實作。Arnold 除了用 PHP5 的 Interface 跟 Class 來實作之外，也使用 runkit 實作一個可排序的 object。而 runkit 用來實作 Mix-ins 在之前也有人提出來過。

總之要 PHP 跟 Ruby 一樣，就看 PHP 6 能不能供這些功能了:
http://livepipe.net/blog/programming/what_php6_actually_needs

這樣也算是 Google 廣告?

剛剛在 Brain 那邊看到的，本來還以為是文章的一部份，仔細一看..

(看出來哪裡奇怪了嗎?)

大概是懶的設計網路專屬的廣告，乾脆把名片放上去就好。Orz

除了名片，或許未來也有人會上傳照片，用 Google 廣告徵友也說不定..XD

(而且用來求婚也是不錯的 idea，哈哈~~~)