發表文章

目前顯示的是 六月, 2012的文章

現實中,我的創業,問題,解答,手札。

最近看到一些網友轉貼的文章,還有聽聞了一些朋友的創業故事,加上自己也是在創業,因此有感而發。其實,過去就一直想寫下『在我眼中的創業』,一方面重新整理自己在創業生涯中的思緒,另一方面鼓勵自己不能倒下。此外,如果可以,讓更多人知道創業的現實面,也不是什麼壞事。這邊要先感謝許多同是創業人的朋友,無論他們現在是否還在這條路上,都給予我很多幫助和啟發,更感激許多親身跳下去『證明』的人,讓我知曉許多悲慘的事實。

依然強調,我尚未成功,也還年輕,我說的話可能影響不了什麼人,也沒什麼說服力,只是單純地將我所見的一切,如實的描述出來。如果你對我所說的一切不以為然,如果你仍然覺得你自己原本想法是對的,請堅持自己所想,無論最後是成功還是失敗,開心或痛苦的,你都能因此得到實質的經驗和正面的回報。

因為我還沒成功,所以我不會告訴你怎麼成功,更不會告訴你創業一定要做到的成功守則有哪些,這些事我都沒有答案。如果你有這樣的困擾,你應該去問的是那些研究創業的部落客專家,或是書報周刊。在這我只會告訴你,我在創業中遭遇到或看到的問題。

首先,恭喜自己。經歷過兩年的努力,好不容易還活著,這是我是創業至今最值得開心的事。相信我,這是真的,在經歷過痛苦磨難、倒閉危機和理想於現實搏鬥後,你會非常慶幸,自己還撐的下去。這一切不像是某些知名的『談創業』部落格文章中,所輕描淡寫的這麼簡單,也不像書店架上滿滿的『各類成功學』所提到的這麼有跡可循,因為你永遠可能被任何一個創業的細節所打倒,一切是這麼出乎意料,現實中的『啊!你已經死了!』天天都可能上演。所以,如果你克服了這些細節,不管落地動作好看與否,你都應該先為自己鼓掌。

問一下自己,什麼才叫做『成功』?既然提創業,就得提大家都想要成功這件事。包括我自己,很多人不曉得創業最中最大的問題,就是『不知道什麼才是成功』。對許多創業人來說,看到 Facebook 有今天的地位會感覺到相當興奮,為自己『創業的理想』注入了一劑莫大的強心針。是的,因為你認為他是成功的,所以你感覺到了『我也有機會成功!』,夢想實現也近在眼前。

但是,我們應該先問一下自己,什麼才叫做『成功』?

是上市上櫃?手上握有幾百億美元資產?還是不缺錢用?握有極大的權力?又或者是走到世界各地,都能有人認出你來?如果你回答不出來這個問題,那請試著去想個更簡單的問題,你認為 Facebook 算成功嗎?你覺得他從什麼時…

實作 X11 底下的 Popup Menu

既然要投入 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 和依賴他們的應用…