Fred's blog

最近有一些想法，便和伙伴在空閒時間寫一些 Prototype 的專案，既然是嘗試形態的專案開發，就不必考慮穩定性和熟悉度，也不用顧慮失敗的問題，可以盡情玩弄新的，或是過去不常使用的技術。所以，這次使用了 nodejs + express + HTML5 來開發，大玩 JavaScript。 JavaScript 雖然看起來像 Java，但畢竟它不是真的 Java，很多功能考量以易於使用為優先，所以並不嚴謹，一些功能也因此被拿掉。畢竟，當初被設計出來只是為了讓『網頁動起來』，並沒有考量太多。但是隨著需求大增，而現在我們所看到的 JavaScript ，已經是一層層為了需求而疊出來的產物，其不旦保留與舊的 JavaScript 相容，又要擴充物件導向的現代化語言特性，這也是為什麼使用起來總是沒有一個固定的模式。 筆者過去總苦惱 JavaScript 的寫法變化太大，在過程中跌跌撞撞，雖寫了不少 Code，但總是覺得不順手，非常想尋求一個 JavaScript 設計模式的『基本款』，也希望和開發伙伴們有共同遵循的標準，讓專案更容易維護。 經過和隊友們的一番討論，總算有一些結論： /* Example Class */ var Example = function() { /* Private */ var Status = 0; var doms = { object: false; }; var subObject = false; /* Constructor */ subObject = new OtherClass(); doms.object = document.createElement('div'); /* Public */ return { setStatus: function(_status) { Status = _status; }, getStatus: function() { return Status; }, getDOMs: function() { retu...

常有人說，資訊產業變化太快，如果不及時跟上，馬上就落伍了。事實上不全然如此，應該說在這產業是不進則退，至於要不要跟著潮流走，不一定。其實講明了，電腦科學並不是真正的科學，而是種社會學，由於大家的方向和需求多半是一致的，可以很容易預測到未來需要用到的各種技術，或是常有別人已經完成的工具或技術可直接使用，而且研發新技術也不需要像真正科學一樣，我們不需要長篇幅的理論基礎，只要能解決當前問題即可，如何不斷的解決需求和問題才是我們所在意。 在之前舊文『程式開發者之萬事起頭難』有提過，開發軟體相當依賴經驗。所以，不管是如何找到解決問題的辦法，都必需要經過實作執行然後吸收，並轉化成程式人員的經驗才有意義。也因此，只要能獲得新的經驗，拓展視野，什麼方法都可以。不過，筆者認為『追著最新的外來技術』和『自己發展技術』兩種途徑最為重要，而且缺一不可。如果用武俠小說的角度來說，就是招式和心法的配合，增加內力的累積。 自己發展技術就不用多說，我們能從實地的演練，獲得大量經驗和想法，而且會得到實務考量的觀念。比較需要注意的是『追著最新的外來技術』，因為很多時候，我們面對這些技術的態度，會讓自己無法分辨自己所得到的是『招式』還是『武功』。 或許很多人以『學了很多招式』而自豪，但面對真正的需求和挑戰時，便無法應對自如，招式套不上去，此時才抱怨『書到用時方恨少』，殊不知是學習新知的態度有問題所造成。因為缺少了質的招式，並不具有太大的意義，而且永遠要追求更新更有用的招式，才不會有招用老的一天。可是，一旦碰到 Google 大神或書裡沒有答案，就完蛋了。記得，學會很多招式或工具，只是『幫助提升工作效率』，相當於大學生會剪剪貼貼罷了，缺少深入的理論和資訊定位分析，或沒有學習問題的根本，並無法累積解決問題能力。 所以時時都要準備哪一天『如果沒有 Google』，也不要再只是窮追新的 Library 或 open source project。導致一旦沒有其他人供獻這些東西，自己便沒能力完成專案。雖然說要全部都懂是很困難或不可能達成，但要盡量做到，才能得到屬於自己的關鍵技術。以前人說的：『站在巨人肩上』，指的就是追到最新技術後，再發展技術，如果只是使用而沒有再發展，就等於沒有進步可言，遲早會被騎在更高巨人身上的人所打敗。 程式人員要盡可能快速從『請 Google 幫...

常聽到有人說專案選錯技術而失敗，或是造成什麼嚴重問題，其實這其中，是有很多原因導致選錯技術。不過，對於初入這行業的人來說，所知所見不夠廣，是最主要的問題。 使用正確的解決方案能讓軟體專案或是產品專案更加順利。所以開發前要做足功課，通盤的瞭解和業界各種大小的動態都不能放過（相信身為程式人員，看英文資訊的能力應該不必擔心），哪怕該技術存在的領域可能與我們當前熟悉的領域相差十萬八千里遠。因為如果視野太狹窄，就看不到更好的技術方案，更沒有機會觸類旁通。有了足夠資訊，如同有了一張地圖，也就有跡可尋自己不足之處和其解決之道。 有了地圖，便要開始認清方位，身為程式開發者，懂一項技術的優點和極限是絕對必要的，所以一定要了解一件事實：『懂一種技術能做些什麼，並不代表了解該技術只能做些什麼。』瞭解透徹，才能正確的選擇解決方案和確實將目標達成。 搞清楚各種技術的定位後，便要應用在一個專案開始前，使用所知去選擇解決方案。記得過程中要隨時保持所選擇的技術，在緊急時刻可替換的彈性。專案開始後，切勿將陌生領域的東西寫得太過死硬，要可以容易被切割獨立。因為若是在開發過程中，才發現原先使用的技術可能並不適合在目前的用途上時，可以用另外的技術來彌補或替換。除非，有時間上的壓力或限制，硬是使用不適當的技術完成任務是容易有後遺症的，而且容易傷害到使用者體驗。更重要的是有很大機會達不成目標的標準。 此外選擇技術的評估，除了應該先有通盤知識為基礎，應該以客觀或是跨時代的角度來做，而不是以自己手上的電腦硬體，或是自己目前正習慣使用的平台或喜好的技術為準。一旦專案有挫折或失敗，才來說當初選錯平台，實在是浪費時間。而且，還可能錯上加錯，因為不是選錯平台而是選錯技術的可能性更大。 要知道，這個時代是多元的，只熟悉或知曉單一方向技術，是無法有太多創意和實作能力的。解決問題的方法並不需要貫徹技術到底的決心，只要選擇適當即可。

接觸程式開發也已經十五年有餘，雖然不算多，但也算經歷過不少風雨。於是趕在二十五歲結束前，開始記錄起『程式開發打字工』的種種心得。之後，如同數學家的二十五歲大限，希望『程式開發打字工』將成為興趣與次要的工作，不敢說可以完全放下，但必要動手做時也會不假別人之手。 首先談到開發一個新的專案，俗話說萬事起頭難，我們馬上會碰到千頭萬緒襲來。而且我們什麼都想做，什麼都想完美，往往還沒開始就已經結束了。此時心神不定，煩燥之時若螢幕上閃過X浪或 Facebxxk 的身影，再來個香蕉動新聞，一整天馬上就過去。 寫程式很重要的的一個原則就是：『不要想一次都要做太多功能。』尤其是在初次接觸的領域。因為，光是計劃架構和細節就會先消磨掉大半熱情。甚至開始實作以後，你會因為到處要留後著而難以前進，把自己陷於無法動彈之地。一但沒有動力，也沒有前進的路，該專案將胎死腹中。 如果有足夠的時間，專案初期不斷打掉重練，是可以接受的。因為這比起日後累積太多量後，才發現不適合再打掉重練而來得好。也不會因為在錯的基礎上開發，而降低開發效率，甚至寫出問題重重的軟體。 至於『如何才叫太多功能』，這依每個人而定，經驗多寡決定了一個人能快速設計多大規模的架構，並且能在該架構下工作而不會自亂陣腳。同樣類型的程式，如果你有過去的實作經驗，這次肯定有思緒改進或是延用。反之，如果沒有過去的經驗，很難做太長遠的細節規劃，你能靠的只有『過去學會的程式技巧』和『類似經驗』，盡力設計一個勘用的架構罷了，然後經過提早發現問題提早重新來過，盡可能補完整個專案所需。 當然，除了程式技巧和相關知識，經驗是不通用的，如果碰到不熟悉的專案，還是得從頭累積經驗，從小規模的設計一步步前進。記得不要貪多，一個功能一個功能確實完成，『慢慢來，比較快』。

如果沒意外，Apple 將以低價重回戰場，掃蕩剩下的反抗勢力，用升級版的硬體，鞏固現有的防線。那麼，過去的電腦王國，準備好應戰了嗎？顯而易見：『還沒。』 我們可以期待，接下來手機裝置的局面很可能是三分天下：『Apple、Nokia、Moto』，他們分別背後擁有強悍的軟體公司或團隊支援。雖然 Google 目前沒有說要開始親自投入戰場，但是品牌和代工合體後的 GMoto(Google + Moto Mobility)，難保有一天不會自己殺出條血路。就算是台灣當前的對手 - 『韓國』， Samsung 也擁有著自己的軟體系統。那麼，電腦王國怎麼辦？身為電腦王國的國民，不免擔憂起這樣的局面。 舊時代王者的現實 郭董已經證明，鐵血毛利之下除了逼人跳樓之外，缺少政府『幫助』後，現在才正要開始體現代工產業下應有的利潤和風險。在這薄利又不景氣的時代，比誰和銀行借的錢多，已經不管用了。 缺少商業模式的資訊產業 如果有夠大的商業模式或願景為前提，就算是當年 PC 時代的『大補帖』歪風，都能有掀起錢潮的機會。任何點子和創意，都足以大舉刺激商業發展。 今天，拼命的生蛋和不停的脫皮，算斤兩的生意，卻已經變成主流。 硬體廠商心中的不平衡 還記得當年 PC 獨霸的年代，微軟一舉跳上枝頭，收盡一切好處。硬體廠商雖然拼命做，扛下所有生產風險，但每台電腦所獲得的利潤逐年降低，直至今天這『毛利』的勢態後咬牙苦撐。反觀微軟靠著數不清的五毛光碟片，賺得荷包滿滿。現在殘存的硬體廠商，誰不恨得牙癢癢？所以只要有機會解決微軟，讓原本應該進微軟進自己口袋，何樂而不為？ 此外，Apple 以一家非硬體製造商的身份，用 iPhone/iPad 打下一片江山，讓所有人失了面子也失了市場。沒有一家廠商不這麼想：『既然 Apple 可以從一家軟體（或稱為系統整合）的公司，跨足到完全不相干的手機產業，那麼，身為硬體製造商的我們，為什麼不能跨界成為 Apple 呢？』 於是，成為『類 Apple 公司』變成這些傳統 PC 製造商的夢。 Android 滿足了硬體廠商心中的不平衡 終於有機會可以自己掌控作業系統，不用再給微軟或任何系統軟體業者半毛錢。各家廠商無一不開始宣布自家有完整的系統技術團隊，可以針對作業系統做任何改進和維護。對硬體商來說，有了一個可以佔有的作業系統後，這不就代...

雖然 Nokia 擁抱了 Microsoft，但不可否認，其旗下的 Qt Framework 經過十載演進，也有 Open Source 出來，實在是個好東西。因此，筆者認為 Nokia 的決定並不會影響我們繼續使用 Qt 的意願，長期在 Linux 下並以 Qt 為基礎的 KDE 桌面環境，就足夠證明了 Qt 尚未死。 而最近筆者使用 QML 實做了一些應用程式，發現圖型渲染效能並不是非常好。猜想是和 Android 有相同的問題，於是著手將程式改用 OpenGL 來繪圖，果然，效能立即獲得大幅度改善： int main(int argc, char *argv[]) { QApplication app(argc, argv); QGLWidget *glWidget; QGLFormat format = QGLFormat::defaultFormat(); /* Create OpenGL Widget to render QML */ format.setSampleBuffers(false); glWidget = new QGLWidget(format); glWidget->setAutoFillBackground(false); /* Create QDeclarativeView to open QML file */ QDeclarativeView *viewer = new QDeclarativeView; viewer->setViewport(glWidget); viewer->setSource(QUrl::fromLocalFile("main.qml")); viewer->show(); return app.exec(); }