以下二行錯誤訊息來自勞虎的Blog
這是剛在看黑米上面William大的書籤時連到，內容在討論LAMP 如何做平行運算的課題，又看到ijliao寫的這篇倒挺有趣的。其中b6s提到"select * from foo_table 高達一億筆，難不成真的都放進記憶體？"，我想這就是Google那些公司的分散式資料庫強處，技術超過我的能力就不討論。
另一點則是William提到
王克明這篇說的很明白，對一般的公司（尤其像敝公司不到200人）都是短線開發。在公司內部80%的MIS程式都是在做資料的處理，老板只想盡快有結果，誰管你後續維護？所以分析與設計都只剩下DB design。雖然Agile開發認為不要預留太多彈性，但是程式到處是商業邏輯與SQL語法，幾乎是動彈不得。而更慘的是通常都是一個人負責一個案子，做爛之後只好重寫。在無法pair programming的情況下，除非有豐富的經驗加上Unit Test，否則Code的品質永遠無法提升，不斷陷入無間地獄循環。
所以在這種情況下，我寧可選Java/CSharp也不要PHP/ASP，至少在Refactoring或debug時有傑出的IDE可用。LAMP不是不好，但必須看場合使用；我比較喜歡 FreeBSD/Apache/Postgresql/Java的組合。
WordPress database error: [File './blog/wp_bas_log.MYD' not found (Errcode: 13)]
INSERT INTO wp_bas_log (visit, stamp, outbound, page) VALUES (26715, '2006-12-13 20:34:28', 0, 1299);
這是剛在看黑米上面William大的書籤時連到，內容在討論LAMP 如何做平行運算的課題，又看到ijliao寫的這篇倒挺有趣的。其中b6s提到"select * from foo_table 高達一億筆，難不成真的都放進記憶體？"，我想這就是Google那些公司的分散式資料庫強處，技術超過我的能力就不討論。
另一點則是William提到
以軟體工程角度來說，很多 nonfunctional requirement 都會影響到程式架構。如果不趁系統亂度還不大的時候及早考慮而預留彈性空間（我說的不是及早實作出來，而是及早預留空間），事後恐怕未必很容易就調整過來。William在另一篇也說
我認為 functionality 和 architecture 應該並進，不可過於忽略任何一個。否則以「短線的專案開發生態」而言，我高度懷疑事後是否真的還有精力去 refactor architecture，尤其當 architecture 的亂度已變得難以駕馭時。這就是為什麼我不喜歡PHP的原因，不知道有多少PHP Open Source的專案寫到爛，最後難以維護。尤其是一個缺乏Refactoring工具的非OO語言，在許多quick and dirty的hacking後，有如回到二十年前的Basic一般。當然，我接觸的是PHP 3版，現在的PHP 5已經是OO語言。
王克明這篇說的很明白，對一般的公司（尤其像敝公司不到200人）都是短線開發。在公司內部80%的MIS程式都是在做資料的處理，老板只想盡快有結果，誰管你後續維護？所以分析與設計都只剩下DB design。雖然Agile開發認為不要預留太多彈性，但是程式到處是商業邏輯與SQL語法，幾乎是動彈不得。而更慘的是通常都是一個人負責一個案子，做爛之後只好重寫。在無法pair programming的情況下，除非有豐富的經驗加上Unit Test，否則Code的品質永遠無法提升，不斷陷入無間地獄循環。
所以在這種情況下，我寧可選Java/CSharp也不要PHP/ASP，至少在Refactoring或debug時有傑出的IDE可用。LAMP不是不好，但必須看場合使用；我比較喜歡 FreeBSD/Apache/Postgresql/Java的組合。
留言