Fred's blog

國內一年一度最大的開放原始碼（Open Source）活動，再次順利落幕。很多人都意猶未盡，所以每當活動結束，便會開始思考明年要分享什麼、反省今年哪裡做的不夠，有人會在活動過後的連續幾天，電腦上開著簡報編輯器，盯著空白的內容，靜靜的發著呆。可惜的是，最後總是因為沒有任何想法而放棄。一直到了明年 COSCUP 的徵稿消息發出，一堆人又開始拾起空白了近一年的想法，擠出一個題目，逼著自己在一兩個月內完成，上台發表。就如同學校的期中、期末考，沒有死到臨頭，大多數同學都沒有唸書的動力，也不會激發自己 120% 的腦力和體力。所以，Event-Driven 的開發模式，一直是在很多開發者促使自己進步的方式。 別以為兩個月時間很充足，大家都有外務、有工作、要過生活，所剩的時間實在有限，所以每當到了 COSCUP 的前夕，總是會聽到很多講者在拼命趕工的聲音。其實，這樣都還算是常態，頂多拼命一點，少睡一點，都還可以頂得過去。可是，今年一次給『兩個 Talk』，就真的讓人會虛脫到不行，還好，熱情能戰勝一切。:-) 由於今年活動承辦的分工方式比較特殊，所以被選上了兩個稿，分別是： JavaScript 全面逆襲！使用 Node.js 打造桌面環境！ 用最潮的 JavaScript 盡情開發 KDE/Qt 程式 前者是總結這一年來，我們團隊所開發出來的各種 Node.js APIs，並整合成為一個如同 GNOME/KDE 的桌面環境（Desktop Environment），並展示使用 JavaScript 開發出來的 Juice Desktop Environment（果汁桌面環境）。後者則是為符合 KDE 的議程方向，探討使用 Node.js 開發 Qt 程式的可能。 後記 退學不是件好的事情，請勿模仿。:-S

跳脫出前端應用之後的 JavaScript 語言，所遭遇的挑戰極大，至今還沒有一個非常好的開發模型和原則，讓人不免抱怨。因為沒有前人可學習，也沒有太多文獻可以參考，所以，為了讓自己能夠更快完全領會 JavaScript 在各種極端環境之下的開發情況，在這一年來，花了相當多的時間投入去做各種不同類型的 Project，從 Web service、Embedded System、System Programming 到各式雲端技術開發，嘗試從中累積更多用 JavaScript 打天下的經驗。唉，慣 C 都不慣 C 了。 不過，做了許多東西後，就會開始有機會重覆開發相同的功能，這時就會希望能重覆利用舊的程式碼，讓同一段程式，不用每次都重寫一次而浪費時間。於是，開始慢慢把之前做過的專案整理，然後整併許多功能，獨立出來變成一個個 Node.js 模組。 Courser 就是這樣被獨立出來的專案，而功能是為 Express Web Framework 提供一個管理 HTTP Routing 的方案。你可以從 github 上找到專案首頁： https://github.com/cfsghost/courser Express 範例的傳統做法，是每次增加一個 API 或頁面，就要更動一次主程式檔案(app.js)，以管理 HTTP Routing，相當麻煩，尤其當有許多人協同開發時，更多不必要的程式碼衝突便出現了。此外，管理專案中的 Handler 也是件麻煩事，因為我們總不可能將所有的 Handler 寫在同一支檔案裡，必須適當分類分檔，才能便於維護。隨著專案規模越來越大，需求越來越複雜，這便是件苦差事。 這些問題當然有解決方案，Express Source Code 裡的範例，就提供了幾種不同的方法，供開發者參考，只不過，這些方法大部份很簡陋、不通用，多半還是要靠專案開發者自行想辦法，開發一套機制，才能解決需求。因此，之前為了專案的需要，就實作了 Courser 去管理專案下的 HTTP Routing 和所有的 Handler，嘗試讓 routes 不要每次開發出來，都是這麼醜。 Courser 目前已經釋出 v0.0.2，你可以從 NPM 上直接安裝它： npm install courser 假設你已經會使用 Express Web ...

最近因為忙錄，遲遲未寫下今年六月初飛去香港(Hong Kong)參加 GNOME.Asia 2012 的心得，以及將當時在活動中的簡報檔釋出。:-) 對一個台灣來的人而言，香港不會讓人感到陌生，若不說新發展的地方，走在街頭，讓人有走在台北西門町的感覺，或是像台灣一些繁華的老市區以及夜市，站在路中央看過去，當下可以感受到早期台灣和香港之間的微妙關係，其共同點難以言喻。事實上，除了廣東話，還有那些銅板和五花八門的紙鈔外，沒有什麼會讓台灣人不習慣的地方。 話說回來，今年的 GNOME.Asia 2012 是在香港城市大學舉行，據當地朋友所說，這是一個與大型商場（百貨公司）纏綿的學校，由於學校、商場和交通樞紐的動線很密切，走在裡面，你會感覺到商場就像學校的一部份，走沒有幾步路，就會走入了商人的魔掌，錯進了名牌服飾的專櫃。 不過，身為一個宅宅開發者，當然不會被這些名牌服飾所迷惑，它們是嚇不倒我的！活動，當然才更重要！ 我能了解，很多人在今天看到 GNOME 幾個大字就興趣缺缺，GNOME 讓大家又愛又恨，許多人不喜歡 GNOME 3 將桌面大改，像是 Linux 之父 Linus Torvalds 前些日子跳出來劈天蓋地的砲轟；也有很多人（像是我）對於許多元件被改壞或是效能不彰而感到很不悅。但由於歷史因素，太多人無法逃脫出 GNOME 所設計出來的大框架，就算你不想用 GNOME 的桌面環境，在 Linux 等 Unix-like 系統中，你還是免不了要去使用基於 GTK+/GLib 所設計的軟體，可以說 GNOME 無處不在，已經不是單單『桌面環境』一詞可以概括。 喜不喜歡新一代的 GNOME 桌面環境是其次，對於我而言， GNOME 是一座作業系統『操作機制』的兵工廠，他生產了太多元件讓我們可以自由使用，然後提供方法讓使用者和開發者可以用『人的角度』去控制作業系統。所以，如果你真的不滿意新的 GNOME 圖形介面設計，自己將 UI 打掉重練也不會是件難事。 這次去香港參加活動，見到了不同地方的開發者和使用者，尤以『中文輸入法（包括輸入框架）』這個議題特別引起討論。這些同是非英語系的 CJK 開發者和使用者們，有頗多的交流。雖然有些議程全程是以廣東話進行討論，我完全聽不懂，但好在有些坐旁邊的香港朋友自動自發充當即時翻譯，還順便介紹了許多當地輸入法開發...

最近 Node.js 推出了 v0.8 穩定版，除了改善 I/O 的效能和一些 API 外，最大的變動就是跨平台開發環境的改進。包括了決定徹底使用 GYP 取代 node-waf(wscript)、宣布 libev 將死。或許，這些變動這對大部份的 Node.js 使用者來說不是什麼問題，但對於我們這些寫 Native API 和底層的開發者來說，關係到自己程式能不能跑在未來 Node.js 的新版本上，而且產生了很多移植性的工作。但是整體來說，好處其實大於壞處，因為以後我們的程式更容易跨平台了。 轉用 GYP GYP 是 Google 發展出來的 Build script tools，就像是傳統 Autotools、Makefile 或 CMake 這類的工具。GYP 最早被應用在廣為人知的 Google Chrome/Chromium Project ，是個跨平台的解決方案，這也是為什麼 Node.js 決定要採用的主要原因。 在以前，不同的平台上，你需要為 C/C++ Addon 製作不同的 Build script，沒有統一的方法和途徑去設置和編譯程式，這讓跨平台的工作非常麻煩。使用 GYP 後，可以大幅減少這樣的問題。 棄 libev ，轉用 libuv 首先，有一點要注意，Node.js 開發者打算在下一個穩定版（應該是 v1.0）拿掉 libev 的支援，所以請所有的開發者盡快轉用 libuv。 libev 是 Node.js 在非 Windows 平台上所使用的 Event loop 解決方案，讓 C/C++ 開發者可以開發 Event-driven 的程式，除了可以用來監聽 FileSystem 等用途，也更容易整合 Thread 進 Event-driven 的設計模式中，要是你有印象，GLib 其實也是類似的解決方案之一，只不過 libev 更為輕量。不過， libev 主要還是被應用在 Unix-like 的系統上，若 Node.js 要支援多個平台，在其他系統上，就必需尋求別的解決方案，如 Windows 的 IOCP。 而過去這樣的情況，對我們 Node.js Native Module 開發者來說，是個莫大的挑戰，你必需在不同系統上，採用不同的寫法，導致開發上很困難。所以 Node.js 自行開發了 libu...

最近看到一些網友轉貼的文章，還有聽聞了一些朋友的創業故事，加上自己也是在創業，因此有感而發。其實，過去就一直想寫下『在我眼中的創業』，一方面重新整理自己在創業生涯中的思緒，另一方面鼓勵自己不能倒下。此外，如果可以，讓更多人知道創業的現實面，也不是什麼壞事。這邊要先感謝許多同是創業人的朋友，無論他們現在是否還在這條路上，都給予我很多幫助和啟發，更感激許多親身跳下去『證明』的人，讓我知曉許多悲慘的事實。 依然強調，我尚未成功，也還年輕，我說的話可能影響不了什麼人，也沒什麼說服力，只是單純地將我所見的一切，如實的描述出來。如果你對我所說的一切不以為然，如果你仍然覺得你自己原本想法是對的，請堅持自己所想，無論最後是成功還是失敗，開心或痛苦的，你都能因此得到實質的經驗和正面的回報。 因為我還沒成功，所以我不會告訴你怎麼成功，更不會告訴你創業一定要做到的成功守則有哪些，這些事我都沒有答案。如果你有這樣的困擾，你應該去問的是那些研究創業的部落客專家，或是書報周刊。在這我只會告訴你，我在創業中遭遇到或看到的問題。 首先，恭喜自己。經歷過兩年的努力，好不容易還活著，這是我是創業至今最值得開心的事。相信我，這是真的，在經歷過痛苦磨難、倒閉危機和理想於現實搏鬥後，你會非常慶幸，自己還撐的下去。這一切不像是某些知名的『談創業』部落格文章中，所輕描淡寫的這麼簡單，也不像書店架上滿滿的『各類成功學』所提到的這麼有跡可循，因為你永遠可能被任何一個創業的細節所打倒，一切是這麼出乎意料，現實中的『啊！你已經死了！』天天都可能上演。所以，如果你克服了這些細節，不管落地動作好看與否，你都應該先為自己鼓掌。 問一下自己，什麼才叫做『成功』？ 既然提創業，就得提大家都想要成功這件事。包括我自己，很多人不曉得 創業最中最大的問題，就是『不知道什麼才是成功』 。對許多創業人來說，看到 Facebook 有今天的地位會感覺到相當興奮，為自己『創業的理想』注入了一劑莫大的強心針。是的，因為你認為他是成功的，所以你感覺到了『我也有機會成功！』，夢想實現也近在眼前。 但是，我們應該先問一下自己，什麼才叫做『成功』？ 是上市上櫃？手上握有幾百億美元資產？還是不缺錢用？握有極大的權力？又或者是走到世界各地，都能有人認出你來？如果你回答不出來這個問題，那請試著去想個更簡單的問題，你認為 F...

既然要投入 JavaScript 的發展，一個很重要的目標就是讓 JavaScript 能被用來開發 Native 桌面程式。而為了達成這樣的願景，我們的團隊沒日沒夜的發展各類基礎技術和擴充底階 API，甚至是將以 JavaScript 開發整個桌面環境（Desktop Environment, 如：GNOME、KDE、LXDE 或 XFCE 這類專案）為終極目標。 當然，跳出瀏覽器之後的 JavaScript，缺少了繪圖引擎，所以要拿來做圖型化使用者介面，會更為困難。慶幸的是，前些日子發展出的 jsdx-toolkit 已經解決了大多數的問題，除了有 3D、動畫等支援，也已經有了許多現代桌面有的UI元件（如：Entry、Label、Button... 等），以致我們完全可以放心的開發屬於自己的圖型化應用程式。 不過，目前的情況，在手機、平板或是特定用途的嵌入式系統中完全夠用，一旦回到更為複雜的桌面環境下，就會遭遇到許多的問題。像是回到 XWindow 底下後，會遇到許多 X11 的視窗管理機制，其視窗之間錯縱複雜的交互關係，就是我們要處理的。尤其是當我們在開發桌面環境時，就會發現在一般的桌面環境下，使用者可能會同時開無數個視窗和程式，並且隨機又大量的切換使用，這迫使我們必須去修改 jsdx-toolkit 以處理 X11 底下的更多狀況，符合並更完整支援一般桌面環境下的操作習慣。 你可能用過 GTK+/Qt 這類常見的 Toolkit，也知道在 X11 之下有很多種類型的視窗（Window），像是 Dialog、Splash、Menu、Popup Menu 等等，但你可能不知道這些現代 Toolkit 內部做了多少事。事實上，X11 本身雖定義了各類視窗的類型，但實際上 XWindow 和 Window Manager 並不會完全去照定義去處理你的視窗行為，更準確的說法是，X11 HWMH 中的基本定義和我們實際的認知是有出入的，該定義只是說希望達成的行為，但沒說是由誰（XWindow、Window Manage 還是 GUI Toolkit）去處理。 舉例來說，我們現在寫一支程式，該程式不使用任何現代的 GUI Toolkit，然後單純使用 X11 API 把一個 Window 的類型設成 Popup Menu。但是你會發現，它的實際行為並不像我...

很抱歉，因為台北大雨來襲，導致班機延誤，讓小弟無法及時從香港趕回台灣參加 FreedomHEC 2012。相當對不起主辦單位，就這樣讓當天議程開了天窗。但是，之後我有空時，仍會整理資料，依舊會公開原先預定要給予的簡報。 不幸的是，活動第二天被客戶抓住，所以也沒辦法到場聽講。不過，雖然沒參加到 FreedomHEC 2012，為了賠罪，第三天當了司機（Be a driver, not writing driver :-S），開著車載著外國講者們一路到了宜蘭大學，給予學生機會直接面對面與 Kernel 開發者交流。 除了面對面問答解惑，其中當然也有保留一點時間，讓講者們可以自我介紹，也分享一些經驗。我也給予了一份簡短的心得分享，由於對象是學生，時間也有限，所以就不直接討論艱澀的技術，而是以輕鬆的角度切入，分享一下創業的經驗和業界的感想，還有描述就算在面對不利軟體業的環境之下，身為一個軟體人所需要的熱情和自我要求。 衷心期盼我們能培養軟體開發的熱忱，然後才有機會做出軟體的價值。:-)

經歷過許多救火任務（這邊當然是指軟體系統專案的問題），從 Kernel、Driver、Porting 到各類系統應用程式、Web 應用程式，幾乎無所不救，有社群內的朋友嘲笑著說：『在國內大概沒有團隊，像我們一樣什麼火都救。』。有許多的感觸是肯定的，從問題發生的那一面看去，加以急迫時間的摧化之下，感受到許多程式開發者最真實的思維和邏輯，當然，還有發案老闆的著急，以及清楚看到許多關係人暗地裡的算盤。我不敢說自己是優秀的救火員，但至少一旦承諾並接下案子，有再大的困難和阻礙也總是使命必達，哪怕連續數個月每天平均只睡兩小時，三四天只睡一次，也不會倒下。我想，最少我可以談談如何救火，還有從火堆中看到的許多『人』的問題。 其實，救火沒什麼訣竅，撲滅它是其次，主要是確保不會再燃起。俗話說『打蛇打七寸』，解問題時也要解到夠力才行。但是，或許你常聽有人說：『產品要出貨，能動最優先，好不好其次。』，似乎恰恰與我所提到的相反。沒錯，因為要確保火不會再燃起，理論上是要找出問題根源，從根源著手和解決，很多人乍聽之下，都會覺得是費工又花時間的工作。但是，每次的經驗都告訴我，實際上，找出問題根源，並解決他，往往比修補來得快很多，而且一勞永逸。尤其是碰到死線(deadline)將至，卻一直解不掉的一大坨 Bugs（指同類相關或互相影響的問題），從根本上並深入解決問題才是最快的辦法。 這邊有個簡單的案例： 有一個應用程式，與 Library、System API 和 Driver 都有相關，他們相依關係是： 應用程式 -> Library -> System API -> Driver 假設現在有個問題，這支應用程式出現了一個 Bug，而這個問題最終被發現是 Driver 缺少一些功能，而造成功能不正常。那我們應該從哪裡去解決？ 一般人的做法，若是為了因應『產品要出貨，能動最優先』，所採取的方法當然是拿掉應用程式上的某些受影響的功能，或是改寫應用程式以另循途徑的方法達成同功能。但是，若你選擇這樣的做法，最可怕問題是，如果應用程式太過複雜，修改起來會有更多的副作用(Side effect)，你要花更多時間去處理更多原先不存在的問題。 況且，這都還沒講到，我們根本都還不知道 Driver 造成的影響範圍有多大，有哪些 System API 、Library API 和...

不像其他的語言，JavaScript 開發者永遠沒有辦法自己去釋放記憶體，頂多只能移除物件的 Reference （代表這物件已經沒有人在使用），而且這物件所佔的記憶體並不會馬上被釋放，而是 Garbage Collection 在滿足某些條件的情況下，才在背景自動去尋找沒有被使用的物件，然後釋放。若你嘗試過尋找釋放記憶體或移除物件 Reference 的方法，得到的解答，應該不外乎是使用 delete 關鍵字或是將變數設為 null，但是你真的了解它的意義嗎？事實上，有很多人都是在不瞭解的情況下使用它們，還可能因此產生 Memory leaks 的狀況。欲弄清楚這一切，我們必須先簡單理解一下 JavaScript 的記憶體管理機制，更準確的說，是物件的管理機制。 從 JavaScript 開發者角度來看，JavaScript Engine 在運作時，記憶體使用是呈現樹狀結構，也就是所有命名或建立的變數或物件，都是存放在一個全域(global)的 Object 中。在 Node.js 中，你可以直接讀取 global 變數看到目前 Context 的環境狀態： console.log(global); 我們可以做個實驗理解一下： var myVar = 'Hello'; function myFunc() { return 123; } var myObj = { a: 1, b: 2 }; console.log(global); 執行以上程式，你應該可以從 global 中找到我們自己定義的變數和函式： { ...（已省略基本預設的環境變數）... myVar: 'Hello', myFunc: [function], myObj: { a: 1, b: 2 }, ... } 從結果可以發現，所有的物件都以樹狀的形式被 global Object 保存著，無論是變數還是任何一種類型的物件，都是一組組 Key/Value 的存在。而 Value 就是各種不同形態的物件，如字串、函數、陣列、數值等。 所以，移除某物件的 Reference，就意味著將把物件從這棵樹上拔除掉。因此，我們可以直接將該變數設為 nul...

由於一些因素，被徵招去救火，在 JSDC.tw 2012 (JavaScript Developer Conference 2012) 給與了一場 Talk，由於準備時間相當緊迫，就把最近在研究和試驗的半成品匆匆拿上場展示和說明，題目是『Non-MVC Web Framework』。你可能在議程上沒有看到這場 Talk，實際上是因為主辦單位的一些小疏忽，議程上仍是寫著之前的舊題目『Build Node.js Module』，而且小弟的名字也打錯了，從 Fred 變成了 Frend，差一點就變成二十世紀少年的友民黨教主。:-) 本次議程其實和前幾天發的舊文『 前端工程師也可以淡定的開發網站應用！RedTea Web Framework！ 』息息相關，探討的是改善 MVC 的開發流程，和引入 JavaScript/Node.js 後的大膽嘗試，而且進一步討論實作細節。此外，因為 RedTea 本身只是一個實驗性的專案，目的只在於驗證可行性，還不到實際使用程度，所以藉著這次機會，公開並宣布新專案『 Kamalan Web Framework（葛瑪蘭） 』，Kamalan 引入了 Express Web Framework 為基礎，然後將結合 RedTea 的成果，並更進一步簡化其中細節和使用方法，讓前端工程師能真正無痛上手。 雖然還沒完全將 RedTea 的機制完全整合進 Kamalan，但目前 Kamalan 最少可以和 Express 一樣使用，你如果有用 Express 寫的程式，直接將 require() 引入的模組名改成 Kamalan 即可。由於 Kamalan 在根本上就是 Express，甚至是可以使用 Express 的所有 Middleware。 後記 這場 Talk 後，引起了一些 JavaScript Developer 趕的迴響，一些建議和聽眾的期待相當令人開心，討論過程也非常愉快。感謝大家的參與。:-)

依稀記得，當年去越南(Vietnam)參加 GNOME.Asia Summit 2009 的情景，當時甚至寫了一篇[ 遊記心得 ]。因為那是首次以講者身份參加國外的 Open Source 研討會活動，意義非凡。更重要的是，那也是當時和 Penk 組成的 ULLab(/usr/local/lab) 第一次出征，如今這樣的組合雖不復存在，但仍在心中藏有很多回憶。 今年度的『 GNOME.Asia Summit 2012 』將在 6/9 - 6/10 於香港舉行，很感謝 GNOME Foundation 再次贊助，讓小弟幸運的又能以講者身份飛去參加這次活動，而這次要給予的主題是『Enjoy Writing a Modern Desktop Application in JavaScript』。 今日科技變革相當快速，但桌面應用的開發一直跟不上節奏，原因是『開發效率差』和『入門門檻高』一直都是 C/C++ 這類中低階的語言的痛處，不足因應這個時代對應用的大量需求。因此使用有高生產力的腳本(Script)語言來開發桌面應用程式，便是目前可行的解決之道。 JavaScript 自 World Wide Web 澎渤發展以來，一直處於相當重要的地位，用於處理 User Interface 的工作，已經有快要二十年的時間，可說是非常成熟。事實上，GLib/GTK+/Clutter 等底層的事件模型，就與 JavaScript Engine 本身的機制大同小異，在同樣解決使用者介面的工作上，可說是殊途同歸。因此，有這樣豐富的前線作戰經驗當後盾，我們可以確信，JavaScript 非常適合被用於開發桌面應用程式。若是與 GTK+/Clutter 這類底層 Toolkit 相結合，跳脫出瀏覽器，寫原生的桌面應用程式也未嘗不可。 這次的議程，小弟將提及： 回顧 JavaScript 歷史和發展 探討如何使用 JavaScript 開發原生的桌面應用程式（搭配 GTK+/Clutter/Mx） 既然這次活動的主角是 GNOME，主要將以探討原生的桌面程式為主，當然也會因應未來發展，提及 Web Application 的部份。 期待與香港和世界各地前來的朋友相見。:-)

還記得，尚未投入 Node.js 前，一直覺得 Node.js 帶來了未來，讓我們可以用 JavaScript 同時開發 Web 前端(Front-end)和後端(Back-end)，等到真的投入 Node.js 後，發現雖然事實的確是如此，但由於前端和後端應用所需要的背景知識不盡相同，開發模式和概念更是大異其趣，所以，雖然同樣是使用大家熟悉的 JavaScript 語言，但前端開發者仍然不見得能夠如願地來開發後端應用。 這樣的情況讓我想起有位來台灣工作的外國朋友，曾告訴過我一個多年前發生在他身上的笑話。故事是： 他原本是個美術方面的設計師，然後，但有一天老闆對他說：『你從現在起，去做開發程式的工作吧。』 他問：『為什麼？』 老闆回答：『寫程式是用英文寫，而你又會英文，不就可以寫嗎？』 是的，同樣道理，雖然對前端工程師而言，JavaScript 是最熟悉的程式語言，而 Node.js 又可以讓你使用 JavaScript 寫整個 Web 應用，但這不代表對這些人而言，就可以輕易上手 Web service 的後端開發。要真正讓前後端開發合而為一，不只是語言要統一，開發經驗也要相同才是，這才是所有 Web 開發者最期盼的事。 於是筆者基於 Node.js，開發了『 紅茶(RedTea) 』，這是一個和現有的網站框架(Web Framework)所不一樣的全新的嘗試。以前端開發者視角和經驗為出發點，專門設計給前端工程師上手使用的網站框架，讓前端工程師也可以『淡定』的開發網站應用。由於 RedTea 不是傳統 MVC 模型的 Framework（至於 RedTea 採用的是哪種開發模型，筆者一時也說不上來。），所以，如果你是一個已經被 MVC 涂毒已深的開發者，可能要先花點時間重新理解一下。:-) 此外，RedTea 有一個最大的特點，就是支援了在瀏覽器環境下，呼叫後端 JavaScript Class/Function 的功能，就像在使用本地端的 JavaScript 物件般。因此，前後台交換資料，不用再以 GET/POST、URL Path Routing 或 Ajax 相關的方法實作，只要學會怎麼使用 JavaScript Class 即可。重點是，即使你沒有任何 HTTP 通訊協定的知識，或後前後端資料處理的經驗，依然可以開發出網站程式。 ...