Fred's blog

在國內，很多人或許對 Qt 很陌生，但這一直是筆者近年來想要推廣的技術，尤其是 QML 這個自 Qt Project 衍生出來的新 UI 技術，更讓人著迷。具有原生效能和擁有炫麗效果的 QML ，確實是一個打造產品的好東西，如大家近來所聽到的 Tesla 汽車、Jolla 手機等，其 UI 就是使用 QML 所開發。當然，之前舊文章中所展示的 UI 和介面，以及能跑在 Android 手機上的 OwaNEXT，也有不少是結合 QML 技術所開發。 推廣過程中總有人質疑，覺得 QML 不是一個設計師能學會的東西。事實上，它的語法相當簡單且模組化，所以也聽聞一些國外的設計公司，其設計師都直接用 QML 做出 UI ，再交給工程師去接上功能。這也是為什麼 HanGee 國民機在開發手機和各種裝置的 UI 時，要選用 QML 為底層的原因了。 因此，筆者自己的公司最近也在籌備許多課程和分享，也與許多朋友成立了一些社群（你可以在 Facebook 加入我們的 Qt @ Taiwan 社群），並設計開發一些相關的工具，以協助更多人能更快速進入到 QML 的世界。不過，因為 UI 與設計師更密切相關，近期應該會針對不懂技術的設計師，推出許多相關的 UI 開發課程。（如果你對這樣的技術有興趣，歡迎與我們聯絡） 其實，這次的黑客松活動與 HanGee 社群合作開設 QML 課程就是一個嘗試，也想收集一些 Qt/QML 初入門者狀況和資料。其中發現一個最大的問題是，無論是技術還非技術人員（如設計師），在安裝 Qt 時就會碰到各種狀況，而且 Qt 開發環境因為功能繁複且龐大，安裝一整套下來要花上不少時間，在學習上也就是一個阻礙。這對技術人員來說，可能不是什麼大問題，但這對設計師來說，就是一個極大的挫折。 因此，我們、講師和 HanGee 社群合作，開發了一個新的工具『OwaViewer』。原本這個工具只是被設計來開發 HanGee 手機介面，但現在可以用來讀取和執行一般的 QML 檔案。這意味著，你再也不需要安裝 Qt 和學習一堆知識，就可以使用 QML 開發使用者介面了，也可以很容易提供一個成果給客戶直接操作，這對許多設計師來說應該是個好消息。 OwaViewer 是個 Open Source Proje...

最近比較忙，一直拖到現在，才有點時間上傳我在今年 JSDC 的簡報。這次，給的講題是『我編譯故我在：誰說 Node.js 程式不能編成 Binary』，主要探討怎麼使用 NPK 打包你寫的 Node.js 程式，以及把 JavaScript 程式碼編譯成二進位(Binary)檔，甚至是進一步的加密設計。NPK 雖然還只是初版，目前支援了三種博君一笑的封裝等級：卸妝(Remove mock-up)、媽媽不認識(Mom doesn't recognize)、爸爸不認識(Dad doesn't recognize)，有興趣了解這三種等級不同的人，可以參考我的簡報： 當然，參加這種活動需要的是熱血，不在 Lightening Talk 閃電秀登場一下怎麼可以呢？於是當天毫不考慮的搶了一個名額，用短短的五分鐘介紹 Mandice 團隊最近在做的 JavaScript OS - 『 Stem 』。在 Stem 的平台之下，無論你是否為嵌入式系統或作業系統的高手，只需要懂 JavaScript 和純粹的 Web 相關技術，你就可以開發自己的嵌入式應用，或讓你的舊電腦或開發板有全新的用途。 後記 大家都知道，做外包工作，一向很難累積東西，唯一能累積的，就是設計工具以加速自己做案子的速度。因此，Stem OS 就是我們經歷過許多的案子後，自己設計的平台，讓我們可以盡可能完全用 JavaScript 快速開發嵌入式系統，然後結合硬體開發設計各式應用。在 Stem 裡，只需要懂 JavaScript 和 Web 相關技術，就能勝任開發工作，實現你心中的 Idea。如果說 3D Printer 是可以讓你快速打造模型實體，那 Stem OS，就是能將你心中的 Idea，化為空硬體的靈魂，Idea 的 3D Printer。 這對創業者、創新者和非資訊產業的公司來說，都是一個可以快速切入設計產品和自家工具的機會，不妨嘗試看看。:-) 如果有任何需求，無論是顧問、教育訓練還是合作開發，都歡迎與我們 Mandice 聯絡，或來信到 fred@mandice.com。

昨日應邀參加『 企業雲端環境建置與應用技術研討會 』，給予一場『AppHouse - 國產 PaaS』的簡報分享，聽眾相當熱情，在會後也一起相互討論了許多技術與非技術等議題。這次的分享，主要在說明 AppHouse Project 的細節，並闡述了 PaaS 在雲端產業中的定位。為了讓聽眾更能理解，也特意以小弟的淺見和觀點，用簡單明瞭的方式描述『什麼是雲端』。 後記 會後與不少人交流，發現過去很多人被『雲端』一詞搞糊塗了，不能理解。如果你也有此困擾，不妨可以看看此簡報。 若您有任何疑問，或需要協助的地方，歡迎與我聯絡。:-)

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

在處理技術問題時，我喜歡和他人討論，因為這是有助於大家提升技術的機會，也是種讓自己覺得不孤獨的方式，互相放下身段然後交換意見，每次都能不亦樂乎。這無關乎誰技術高低，只要大家能夠共同解決問題，除了是種樂趣也是種團隊集思廣益的機會。 由於有些人可以接受反證的方式，而有一些人比較能接受列舉推導的證明方式。所以，難免會碰到種情況，就是有人會大玩文字遊戲，讓你分不清他到底是真心想要找出問題，還是為辯而辯。其實，他們常常只是因為無法接受其他人的證明手段而已，所以互挑對方的骨頭。造成公說公有理，婆說婆有理，沒有交集點的局面。 一旦碰到這種情況，為避免文字遊戲混淆主題，我總是會請在乎『文詞精確』的人，先自己定義一些文字和用詞，然後再行討論。或是請有一些想法的人，針對問題先列舉出他們自己認為的所有可能性，然後接著追加自己認為的可能性，最後再行討論。這樣做的目的是，試圖採用他們們各自喜歡的證明方法，正反舉證，然後以交集去找出問題，除了讓兩邊都沒有話說之外，也能更快讓大家有『同樣的語言』可以溝通。此外，有時候為使討論順利進行，我也會一項項以詢問的方式進行，有時問題相當愚蠢，甚至會穿插基本面的問題。 很幸運的，使用這種方法後，在多數情況下，在大家列舉和回答問題之後，通常都能透過排除矛盾的方式，將問題給釐清，找到可能的疑點或是直接得到問題的解答。 不過世界不是這麼美好，既然過程中有愚蠢或基本面的問題，有些自認有本事的人被問到時，難免會覺得你在污辱他或是瞎扯蛋，有些人會回嗆：『自己去看 Spec』 、『連這麼基本的問題都不會，還問、還想討論？』。一旦扯到人的問題，就會讓整個討論進行不下去。 而有些人，在討論不下去後，會搬出多年來死背活背的聖經，在你面前推導了無數公式，繞了一大圈，最後『告訴你無解』或『證明自己沒有錯』。好一點的狀況，他們最後會『猜測問題』所在，回到討論的主題；不好一點的情況，他們就會告訴你『絕對不會有問題，是個無法解釋的靈異事件』，終結討論。 值得注意的是，如果問題的原因是：『執行那本聖經的理論時出現了 Bug』，你會更容易從他們口中得到『無解』和『不可能』的回答，因為這是『完美的聖經理論』內不會記載的東西。 不過，當碰到這種人時就沒辦法了，只能等他們自己想通後給你解答，亦或是另請高明。所以，如果你是他們的主管，又不想得罪他們，你需要給他們更多時間讓...

前一陣子有人寫了文章，以硬體工程師的角度，跳出來罵軟體工程師，因而吵得沸沸揚揚，在各社群網站上也被人重覆轉貼了好一段時間，掀起不少戰文。雖然整篇文章看下來情緒化字眼相當多，在某些部份也有些偏頗甚至太超過。但是不可否認，他的確有提到一個長久以來，許多工程師的通病，無論是軟體工程師還是硬體工程師。 身為工程師或與工程師一同工作的人，應該常聽到或自己本身常說這句話：『不是我的問題。』，就是這經典名句，總是搞得老闆慌、主管氣、工程師們更怒。而對這句話，我特別有感觸，因為過去我身為一個科技業救火員，常跳入火坑滅火，發現很多時候，就是這句話讓什麼問題都解決不了，導致起了大火，又沒人要解決，最後還需要我這外人進去犛清問題。 而在這些救火經歷中，我深刻體會到，證明『不是我的問題』是非常困難的。 一方面，有原罪加身，別人會把你當做在推卸責任。另一方面，因為非常難用『列舉法』去證明自己沒錯，又加上當局者迷，所以，才會有這類『列舉不全』的自我辯解：『我的程式在我的機器上測一點都正常，所以沒問題』、『我測量的電壓和波形都很正常，所以不是我硬體的問題』。其癥結在於，你有在其他電腦環境上測過嗎？你有測過所有工作狀況之下的電壓和波形嗎？大家似乎都忘了高中數學就學過，要找出『向量』以指出方向，要有兩個或更多個點嗎？就算你要用列舉法證明問題不在於你，你也要取樣更多更完整的證據。 所以，很多工程師想盡辦法證明自己沒錯，以為自己是在犛清問題，根本不然。因為『犛清問題』與『不是我的問題』是兩碼子事啊！ 我認為，如果你要犛清問題，又證明自己沒錯，『證明是別人的錯』才是最好的方法，並且有助於專案前進和實質意義。 這邊有個自己團隊最近遭遇的小故事與大家分享： 我們與硬體廠 X 合作開發一個產品，其中發生了一個問題，播放影片時常會鈍鈍卡卡的，此外，因為該產品有觸控面板，如果影片播放中，用手去碰觸觸控面板，影片會立即變很鈍。 由於是 ARM 平台，播放影片都藉助晶片解碼(Decode)，所以起初是找晶片供應商 Y 來查明真相，但是，晶片商『並不認為是自己的問題』，他們認定自己已經出了不少貨，平台夠穩定，所以應該也不可能會有問題。此外，因為觸控面板也會影響影片播放，所以供應商 Y 認定，問題肯定出在 X 廠商因自己動了手腳，加了其他模組或軟體所導致。所以，廠商 X 只好摸摸鼻子，請自己的 ...

和我比較熟的人，最近應該都知道，目前我專注於 JavaScript 和 Google V8 engine 的相關研究上，甚至決定從今年開始，公司營運以及技術團隊的方向，是企圖提供『最專業的 Node.js 和 JavaScript 相關服務』。（所以，如果您有需要，請聯絡我們 :-) ）我非常清楚知道，有些人聽到 JavaScript 就歡天喜地，而有些人則不將他當一回事。更有多到數不清的技術人員，熟悉並使用 JavaScript 非常多年，聽到我說要提供『最專業的 JavaScript 相關服務』，會不屑一顧甚至以為我在瘋言瘋語。不過，如果你願意聽，接下來我會說明這是怎麼樣的瘋狂服務。 我不能阻止你對 JavaScript 有預設立場，因為這是無奈的歷史包袱，但請暫時放下過去成見，聽我靡靡道來。 我所遭遇的矛盾 過去，絕大多數人都只將 JavaScript 視為 Web 開發的一環，在大家的印象和認知中，JavaScript 充其量只是一個在瀏覽器中控制著 HTML DOM 的腳本語言。雖然近年來出現了 Node.js，過去微軟也支援使用者使用 JavaScript 撰寫 ASP 和系統腳本程式，但也不改這樣的看法：『JavaScript 是身處於末端的語言，與網頁、網站密不可分的東西』。所以，對許多硬底子的企業和研發人員來說，JavaScript 象徵了 Web/HTML 與不彰的效能，一種幻想的存在；而對很多 Web 開發者和前端工程師來說，JavaScript 卻是一種當今資訊產業的萬靈丹。如此天差地遠的矛盾，一直存在於這個產業界。 曾經當過 Web 開發者一段不少的時間，我承認也理解，使用 Web 技術來實作各類使用者界面(User Interface)和資料庫應用，非常容易和快速，不用考慮到太多的事。這一切要歸功於 JavaScript 和 HTML 的合作無間。所以，不時能聽到一些 Web 開發者，嘲笑作業系統程式開發者和嵌入式裝置的技術人員的辛苦，認為許多功能和特效，使用 Web 技術一下就達成了。 由於我過去也是『慣C』一族，做過很多包羅萬象的硬碰硬開發，小從一般電腦到嵌入式裝置、桌面系統到手機平版，大到各類特殊需求的系統研發，都有所涉獵。所以，對於系統資源和效能，一直有著莫明...

這是創業者的心聲，我們永遠為了為數不多的錢，拼老命和客戶周旋。在客戶面前包到好包到腳，扛的責任何其多，回來後又當業務又當 PM 還要當 R&D，最後還得當會計，數不盡的心酸誰知道。沒辦法，對我們來說，現金流（CashFlow）比什麼都還重要，能不能挺過這個月或下個月，維持周轉才是首要任務，為此，任何苦我們也得吃下。 筆者做了幾年的 Outsourcing，雖然不是當初創業的核心目標，但為了養家活口，接案卻成了主要業務。不過，筆者確實也因接案而活了下來並壯大團隊，能夠有機會持續朝理想發展。接案的過程中，風風雨雨自然不在話下，但慶幸受到前輩和朋友間的提攜，近來也總算是開始有個根基，剛好穩住腳。 接案就是這樣，有一頓沒一頓，如果要穩定收入，案子的價與量就必需相應提高，這是所有以接案當食糧的創業者，所都要經歷的過程。但是，往往在提升價和量後，案子開始會吃掉團隊的全部時間，漸漸失去當初創業的核心目標。然後，進入了『招人力』後『招案子』再『招更多人力』後『招更多案子』的惡性輪迴中，最終你會想：『辛苦到快暴斃，工時責任換算下來，賺得比去上班來得少，那我何必創業？』。如果你有同感，不用灰心，因為現在有無數的創業團隊和創業者， 也都正面對著同樣問題，甚至面臨崩潰。 有鑑於此，筆者尋思，何不與大家分享自己的經營成果，讓大家各自都能得到更多時間經營自己的核心目標？創業者、SOHO族和個人接案者所需要的源源不絕的食糧，不必各自重新發展重新耕耘，只需要從筆者這接手過去即可。由於舊有團隊原本已經有業務和PM的佈署，大家也可專注於技術性的工作，並提供如自來水般的技術供應即可。 對筆者來說，自己的核心技術團隊得以鬆口氣， 能慢慢以階段性放下養活自己的短期目標，有更多時間朝自己原本創業的核心目標前進。另一方面，也能給予其他創業者、SOHO族和個人接案者穩定的收入支持，不必重蹈覆徹筆者同樣的道路。如此雙贏的局面，樂見其成。 所以，如果你們是有技術的創業者或創業團隊，SOHO族或個人接案者，趕緊來報到吧！ 後記 無論你是專精或有經驗於哪一領域（Web、Linux、Android System（Integration/Porting）、Android App、iOS App 或 Embedded System... etc），都歡迎來信，最少先交個朋友也是不錯的。:-)