網站製作學習誌

前天去聽了 PHP 之父 Rasmus Lerdorf 的演講： Simple is Hard ，感覺還不賴。也意外發現自己的英聽還算及格，不過也可能是大師沒有用到什麼深奧詞彙的關係 :P

投影片在此：台大場

以下簡單講一些我覺得有興趣的部份：

Siege

Siege 是一套很有趣的工具，它可以幫我們測量出 HTTP 回應的效能。 Rasmus Lerdorf 在前半段介紹中大量使用它來查看程式修改前後的效率，感覺還不賴。

可惜它沒有 Windows 版本，你必須在 Unix-Like 系統上編譯使用。

投影片 10

檔案引入路徑

預設 php.ini 上的 include_path 都是把「 . 」 (也就是當前目錄) 放在 include_path 的最前面，使得我們在用 include 或 require 時會從當前目錄先尋找要引入的檔案。

為了不讓 PHP 程式在執行時，花費太多時間去尋找引入檔案， Rasmus Lerdorf 建議當前目錄把放在 include_path 的最後面。

這樣一來 PHP 引擎會先從指定的位置開始找要引入的檔案，而不是從當前目錄先找起。

投影片 13

找出相依的類別

安裝 PECL 的 included 套件，可以幫我們找出程式引用了哪些類別，而且還能圖形化顯示。

另外這裡有個重點就是，找出相依的類別後，最好改用 require 來取代 require_once 。

投影片 16

KCacheGrind

KCacheGrind 是一個可以顯示程式流程所佔的百分比或執行時間的工具，而且還是圖形化顯示；而解析的檔案就是 Xdebug (PHP) 或 valgrind (C) 產生的 profile 檔。

在 Windows 下有類似的工具稱為 WinCacheGrind ，但沒有圖形化顯示。

投影片 19

預設時區

PHP5 以後有預設時區的設定，如果我們在 php.ini 中強制設定的話，就能夠加速程式的運作。 (？)

引用 steve 的說明：

整段意思說 要coding的時候避免任何錯誤或警告
不管有沒有設定要顯示或關閉任何顯是錯誤
只要有錯誤或警告 都會減緩執行速度（要處理錯誤）

投影片 25

不要用 HTML 的 onxxxx 事件

因為 onxxxx 事件會透過 JavaScript 的 eval 來解釋裡面的內容，而「 ' 」就會被解釋成「 ' 」 (單引號) ；因此就算有做 htmlspeicalchars 也是沒用的。

投影片 40

後記

在寫這篇文章的時候， Mark 跟我說其實他比較想知道 Rasmus Lerdorf 對 PHP 未來的發展有什麼看法，而不是講這些很底層的東西。

我個人倒覺得是有一些收獲，至少我光看投影片看不出什麼鬼就是 :P

但我也覺得內容跟主題「與大師相遇－PHP教父談理想網路環境」有些偏差，但仍不失為一場有深度的演講。

另外 kiang 也在他的網站上寫了一些摘要，和我有興趣的部份不太一樣，大家不妨也參考看看。

• 程式框架會因為需求導向的不同而有所改變。
• 在不良管理下工作，程式員不會覺得他的工作有價值。
• 程式員需要不受干擾的環境，否則他的生產力將大打折扣。
• 人不是 CPU ，通常只能專注一件事，因為人在轉換 Process 上的代價是很大的。
• 正視並善用你手邊的工具，不要一昧一味地追求新技術。
• 不要因為新技術為你帶來好處，而忽略它也可能同時為別人帶來壞處。

桌面放正妹，萬事都 OK

說謊，正妹，壓榨工程師

爭論前，先聽聽別人怎麼說。

大師發明技術
廠商包裝技術
高手掌握技術
阿宅沈迷技術

繼承抽象類表示類別「是個什麼」，
實作介面表示類別「能做什麼」。

不管你要做什麼服務，
正妹
就是最好的 Interface !!!

這篇主要是給 kuni 的一篇回應，雖然我覺得他說的很好，可是畢竟我是活在台灣這個現實社會，所以就有了以下的感想：

To kuni:

我覺得你說的很對，學習多種語言是很重要的。不過在現實專案壓力下，在短期能這樣做嗎？我抱持著懷疑的態度。

我的原因主要有兩項：一來我不是主事者，每個專案在成本的考量之下，技術的易用性及維護性是非常顯見的課題；二來成員的能力與經驗也是重點，要大膽採用新技術的話，有誰能保證一定能解決可能發生的問題？

當然不能排除像你這樣把各項技術都瞭然於胸的開發者，不過在團隊開發中，強者還是得配合其他較為資淺的成員。如果整個團隊能保證在期限內交付給客戶滿意的東西，也能向客戶保證專案後續的可維護性，那麼我想你要採用任何技術都不是問題。

不過就長期而言，其實我和你抱持的想法是一樣的。一個真正的資深技術人員，不能只因為在某個領域發光發熱，就忽略掉其他有用的技術；然而這還是得看個人對技術的敏感度。

因為每個人都不可能擁有一樣的智慧，有的人能博學多聞，通曉各種領域的開發方式。有些人可能資質較為駑鈍，只能專研單一領域；他們不是因為學不懂，而是可能學得比較慢。

我自己應該就是屬於學得慢那一型的，不過我也不會對自己設限。例如未來有機會我應該會重新學習如何利用 C 來寫 PHP 的 extension ，或是拋開對 Ruby 語法的好惡，來好好研究 RoR 更底層的架構，這些對我來說，都是時間與時機的問題。

另一種狀況是生活的壓力，每個人所面臨的情形都不太一樣。我看過有高手因為來自家庭的壓力而放棄對技術的熱愛，轉而接受一個薪水高卻沒有樂趣可言的工作。 在國外我是不清楚這樣的狀況多不多，不過我的感覺是他們似乎就是能以興趣為職業，而且家人也沒什麼反對意見 (這是個人猜想，也許是錯的) 。

拉拉雜雜寫了一堆，其實我只想說一個重點：在台灣，除非主事者重視技術也肯付出相對的酬勞，而且你也真的能表現出你真正的價值時，那時候我們技術人員才會有抬頭的一天。

然而現實真的就是如此...誰不希望薪水能再高一點呢？

以上一點意見，參考看看就好，因為也許你的狀況會比我們來得好。

那天看到丫凱在 MSN 上的 Wii 閃光大頭照，讓我一整個的好羡慕...orz

然後看看自己 Blog 上的貼紙，腦海裡就浮現出：「我要啃的雞！我要啃的雞！」的場景。而且一想到可能有網友和我一樣的時候，不禁悲從中來...(有那麼離譜嗎？)

不過先前貼紙一直掛著我的名字，大家也許就不好意思拿去用了；所以我就把我的名字給拿掉，順便把 Wii 的商標換成比較正式的。

也許不像彎彎她們那些專業網路畫家畫得那麼好看，不過有需要的朋友就自便吧。 :)

咦？又一篇跟網站製作無關的了？算了，放鬆一下也不錯啦。

丫凱有一個很好的建議，不過目前我還沒有時間處理，所以暫時先保密囉。 ;)