Fred's blog

對於我們這種『宅宅水電工』，唯一的樂趣就是經營技術，閒暇招三五同好，玩玩新東西。但怎麼也沒想到，我們這種人做出來的東西，卻變成有心人『統獨論』的撰文題材，令人又好氣又好笑。原始文章出自這篇『 台灣人缺乏自信之實例 』，是筆者在閒逛 Google 時搜尋到的，因為有提到自己的名字，就特別點進去看了一下。被說成缺乏自信心，甚至要被除去，百般無奈。 還記得 LXDE 剛開始會為人所知，是因為 PCMAN 於一些台灣社群活動中，首度公開設計理念，當時雖然許多人叫好，但真正參與開發或專案的確寥寥無幾，一段時間折騰下來，包括我在內的開發者和參與貢獻者，不過五六人，甚至 PCMAN 寫了大量的程式，一度荒廢了自己的學業和醫生本業。 說起來心酸，為了得到台灣社群的認同，我們無不熱衷於在台灣各個大小場合，推廣和號招開發者以及有興趣的人加入。當然， 我們不是外國人，都是使用『中文』與其他人說明和討論技術問題，也極力確保軟體都有中文的介面。甚至成天掛在 IRC（相當古老的網路聊天系統，目前仍被全世界的駭客和開放源始碼廣泛使用） 上，與網友以『中文』討論諸多相關問題。當時許多文件和簡報，同時存在著中文和英文版，甚至很多只有中文版本。 LXDE 的成員身體力行在台灣走透透，卻沒想到也能招來不少外國人。在推廣過程中，開始接觸到許多國外來的開發者和自由軟體愛好者，也開始在各國都有人自動自發要幫忙翻譯成各種語言，然後台灣以外的許多愛好者也開始大量使用 LXDE 並回報問題，甚至提交他們修改過後的程式 patch，參與貢獻。我只能說一開始， LXDE 只有一堆一般人不易讀懂的程式碼，後來的許多非中文的文件和說明， 很多是出自於這些外國貢獻者之手。 註：差點忘了提，LXDE 的網域名稱，還是一位印度人所贊助的。 『自由軟體和開放源始碼』會為我們這些宅宅水電工所喜愛，就是能與所有的同好者，一同完成這些程式和專案。但是，這些自由軟體本來就只是花費我們的課餘時間和下班閒暇時間，不可能什麼東西都能親力親為，我們唯一能做的，就是將自己的初衷做好 。所以，LXDE 後來在國外會有一些知名度，也不是一開始所能預期的，更別提到是不是以台灣為榮，那都是不重要的後話。 若真要說到活在台灣的心態，我只能說：『我們在台灣長大，只是將在台灣這一二十載所學的一一展現出來，如此單純而已。』。我們挺胸開發自...

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

最近一直感覺到系統有時莫名緩慢，CPU 負載也相當高，初期沒去注意，也一味的相信應該都是瀏覽器開太多網頁和 Flash 檔案所造成的，但種種情況令人不解，總覺得不完全是瀏覽器所造成的。將所有瀏覽器關閉後追蹤發現，自己之前寫的『 JuShelf 』（Dock 程式）竟吃掉近 50% 的 CPU 資源。原兇是之前寫的一段程式，用來偵測目前螢幕設定是否有改變，並依據螢幕設定而調整顯示位置，以讓 Dock 永遠顯示在螢幕的中央。 原本的做法相當笨，利用 g_idle_add_full() 讓程式空閒時就去偵測螢幕設定，但由於 Dock 通常是晾在一旁沒有工作的，所以程式經常有空閒時間，這讓程式以每秒百計的次數不停檢查。這還不打緊，由於每次檢查都要與 X Server 做一次至數次溝通，付出的代價更為高昂。 抓到臭蟲以後，便開始著手改進，使用了 XRandR Extension 來取代原有的解決方案。過去筆者曾撰文『 寫支 C 程式用 XRandr Extension 設定你的螢幕解析度 』說明 XRandR 的使用方式，不過當時只著重於取得 X Server 的顯示設定，這次將利用 XRandR Extension 以等待 RRScreenChangeNotify event 來得知螢幕設定何時改變。 由於完整程式太長，這邊只摘錄重點片斷，主要是檢查 XRandR 版本和註冊事件： int rr_major_version, rr_minor_version; int rr_minor_version, xrandr_error_base; /* Initializing X Stuffs... */ /* XRandr extension */ XRRQueryVersion(disp, &rr_major_version, &rr_minor_version); if (rr_major_version < 1 || (rr_major_version == 1 && rr_minor_version < 2)) { printf("RANDR extension is too old (must be at least 1.2)\n"); return 1; } /* Al...

NodeJS 日益強大，相關開發資源也越來越多，許多功能已經不再需要自己寫，通通都可以直接利用官方的 NPM（Node Package Manager）工具，從網路上把別人已經開發好的模組抓回來用。這樣的模組交換平台加快了開發速度，讓開發者可以全心全意專注於當前應用的開發工作。但是也因為如此，讓我們的 Project 總是相依於一大堆的第三方模組，而每當要將我們的程式佈建於伺服器時，就必需手動先將所有的模組先安裝好，甚至是用最笨的方法邊試邊裝遺漏的模組。 事實上，我們可以在程式目錄中，建立 package.json 檔，直接管理 Project 的相依性以及所使用到的模組套件： { "name": "my-website", "version": "0.0.1", "private": true, "dependencies": { "express": "2.4.7", "jade": ">= 0.0.1", "oauth": ">= 0.9.5" } } 一旦目錄中存在 package.json，下次要移到新的環境裝起來時，可以直接利用 NPM 把所有的相依模組一次裝好，省下很多功夫： $ npm install

過去無論哪一種網站應用程式的開發語言，初學者教學中第一次會提到的起手式，八九不離十就是 GET/POST Request 的取值。但是，在 Node.js + Express 的世界中，彷彿人人是高手，天生就會使用，從不曾看到有人撰文說明。 這應該算是開發 Web Service 的入門，在 Client 與 Server 的互動中，瀏覽器發出 GET/POST Request 時會傳值給 Server-side，常見應用就是網頁上以 POST method 送出的表單內容，或是網址列上的 Query Strings （ex: page?page=3&id=5）。然後，我們的網站應用程式透過解析這些參數，得到使用者上傳的資訊。 取得 GET Request 的 Query Strings： GET /test?name=fred&tel=0926xxx572 app.get('/test', function(req, res) {     console.log(req.query.name);     console.log(req.query.tel); }); 如果是透過表單且是用 POST method： <form action='/test' method='post'> <input type='text' name='name' value='fred'> <input type='text' name='tel' value='0926xxx572'> <input type='submit' value='Submit'> </form> app.post('/test', function(req, res) {     console.log(req.body.name);     console.log(req.body.tel); }); 當然也可以 Query Strings 和 POST method 的表單同時使用： <form action=...

在國外，許多大型軟體公司林立，老牌軟體商建立了不少現今軟體業仍在使用的遊戲規則。而比較小的軟體外包商、工作室或是個人，也糊裡糊塗依照這些大公司使用的遊戲規則走，甚至是遵守不合時宜的淺規則。然後，軟體業進入了國內，又被代工思維牽著走，軟體業因此哀嚎聲不斷。軟體研發人才不喜歡去操弄商業，卻被商業操弄著。 身為軟體外包或是軟體客製化的外包商，你是否曾遇過，客戶有很多大大小小的鎖碎要求，不定期會交代過來? 這些修修改改，看似不癢的功能和需求，做起來毫不費功夫，三兩下順手就能完成，卻往往造成雙方驗收標地的分岐，此外，不知不覺中所累積的份量，也讓結案時間遙遙無期，甚至造成軟體產生更多的問題待解決。對於只想當水電工的研發人員，總是在客戶的要求下，修完馬桶順道通水管，又補個土、也打個臘。另外，如果馬桶旁邊剛好有漏水，那你要自認倒楣了，因為客戶也會請你幫忙『順手』解決一下，或認定是你在修馬桶時弄壞的。是吧，令人難過。 難道研發人員就要這麼可憐嗎？我們做錯了什麼，為何就要這樣被對待？明明是為了提供更好服務，卻累死三軍，又讓人有把柄指著鼻子唸。更慘的是，一旦這些看似不起眼的修修改改，累積成有影響力，讓專案與合約內的需求不完全相符。客戶就有機會利用『與合約不符』的矛盾點，再殺下一城。 筆者也同是天涯淪落人，曾經不斷思考這問題也同時咒罵著台灣的業界，咒罵他們總不給軟體商有活命的空間。尤其受了委屈後，更是一股惱自命不凡，認為自己無論做什麼樣的事，都應該比一般人收取更多費用，以平心頭之恨。但過些時日後，經過冷靜思考，發現是一開始雙方的互動模式就錯了，或許更仔細檢視這個行業，才能找到改變現況的辦法。 大多數軟體開發不是演藝事業 一直不認為『軟體程式設計師』是演藝事業，所謂『台上一分鐘，台下十年功』不能完全形容軟體開發的工作。雖然，越厲害的研發人員，越能設計好品質的軟體；越是名不經傳的軟體商，也越難生存於業界。許多面向與藝人生態有些相似，但其實完全不是這個樣子。 因為我們雖練功多年，在專案過程中，卻仍然做很多沒技術性又取代性高的工作，或是『順手工作』這類連項目都寫不出來的事。所以，與演藝事業最大的不同是，我們不是只做一件事：『像巨星一樣站上台吸引全場目光，解決觀眾們長達數十分鐘的無聊時間』，而是因應專案需求，巨星仍然要下海當工讀生或工作人員，甚至是清潔工。所以，大多數軟體研發...

除非是區域性的網站服務，不然在這個網路通全世界的時代，開發網站服務就一定有多國語系的需求。一般來說，i18n 的支援都是由 Web Framework 所提供，但 Express 並沒有支援，所以我們要借助 i18next 這個模組。i18next 可以和 Express 以及 template 很完美的結合，最重要的是，有客戶端支援(clientside support)，若搭配 jquery，我們也可以使前端的 JavaScript 支援多國語系。 先使用 NPM 安裝 i18next： npm install i18next 在 express 的應用程式(app.js)中引入使用 i18next： var express = require('express'); var i18n = require('i18next'); var app = module.exports = express.createServer(); /* Initializing i18n */ i18n.init(); i18n.registerAppHelper(app); app.configure(function(){ app.set('views', __dirname + '/views'); app.set('view engine', 'jade'); app.use(express.bodyParser()); app.use(i18n.handle); app.use(express.methodOverride()); app.use(app.router); app.use(express.static(__dirname + '/public')); }); app.get('/', function(req, res) { res.render('index'); }); app.listen(3000); 接著要在應用程式的目錄下，建立預設的翻譯檔和存放路徑（locales/dev/translation.json）： { "exam...

你將為自家的產品，選用什麼樣的作業系統？我想，這年頭，不外乎是 Android。但是，可能不是最佳選擇。 我想大多數人都會同意，由於智慧型行動裝置的掘起，Google Android 在業界大放異彩，使用 Linux 作業系統核心的 Android，實現了許多華麗的UI，也讓眾多廠商取得入門門票，有機會與 Apple iOS 一爭長短。許多人都相信，未來是 Android 的天下，除了手機要用 Android，電視要 Android，救人一命的醫療器材也要用 Android，所謂的 Android anywhere 是終極目標。 不過，經過這幾年下來，許多人發現這不過是我們資訊科技業一廂情願，有太多的領域是難以使用 Android，如工控市場等，無論是以穩定、價格、移植維護成本考量的因素，都可能是無法使用 Android 的重點。因此，如今要選擇作業系統解決方案，又變成一個需要思考的難題。 筆者擔任顧問時，每當面對客戶躊著於這個問題時，我總問他們幾個大問題： 你們的產品用途是否單一且單純？是否要有讓使用者自行上網安裝其他第三方軟體的擴充性？ 你們的產品是否為消費行電子產品？是否需要高可用行和高穩定性？ 你們的軟體需要有華麗特效的 UI 嗎？你們現在擁有的人員有哪些開發 UI 程式的經驗？ 有網路的需求嗎？如果有，需要哪些需求？Ethernet、Wifi、3G？ 計劃中的產品硬體規格？ 有多少規模的人可以參與開發？ 很明顯的，對於手機和行動裝置業者是這樣的答案：（他們都會選用 Android） 用途不單一，需要讓使用者任意自行上網安裝軟體。 是功能複雜的消費性電子產品，所以客戶多多少少能接受偶爾當機 UI 需要有華麗的特效。開發人員都熟悉並使用 Java 的經驗。 有所有網路的需求。 擁有一定等級以上或是當前最頂級的 ARM 處理器。 最少數十個，多半是上百人甚至上千人的研發人員。 如果你是『非手機』和『非行動裝置』業者，你的產品可能不完全具備這些條件。建議您，一旦有任何一點不具備，請慎重考慮是否使用 Android 還是有機會選擇其他的解決方案。 而當前的解決方案主要常見有三種： Android Linux + Qt Framework Linux + Own Application 限於篇幅，太細節的評估無法一...

雖然 NodeJS 的模組和開發資源相當多，但相關文件卻非常不足或是不完整，多半文獻都只著重於基礎的使用和片斷的說明，如果不去看原始程式碼，使用 NodeJS 來完成實用的網站，會有很大的困難度。對於已經有過 Web 開發經驗的人，轉換使用 NodeJS 不免也需要花一番功夫，過去經驗中許多的常用的功能，都仍要一一花大量時間嘗試才得以解決。而這樣的情況，對於開發者來說相當的糟，也是很多人重新再評估是否使用 NodeJS 的重點因素之一。有道是『一人得道，雞犬升天』，因此筆者未來將嘗試將自己的實際經驗，寫成一篇篇重點功能實作的文章和隨 Copy 即用的範例，減少其他人浪費同樣的時間再摸索。 開發一個 Web 應用程式，最重要的莫過於資料庫的使用，過去 PHP 有 MySQL 當最佳夥伴，而現在 NodeJS 有 MongoDB 做最佳的組合。MongoDB 是 NoSQL 的代表之一，其採用 JSON/BSON 當做資料儲存和溝通的格式，亦使用 JavaScript 做為 Server-side 的執行程序語言（相當於傳統 RDBMS 的預儲程序），一切設計和習慣與 NodeJS 搭配使用起來，簡直絕配。若你對 MongoDB 的一些基本操作有疑問，可以先參考舊文『 MongoDB 快速筆記 』。 使用 MongoDB MongoDB 擁有 NoSQL 的普遍特色，不用預先定義 Schema，所有的 database 和 collection（相當於傳統 RDBMS 的 Table），都會在新增資料後，自動被建立，我們只要專注於使用 NodeJS 操作資料庫即可。 要在 NodeJS 裡使用 MongoDB，可以安裝 mongodb native driver，若透過 npm 來安裝： npm install mongodb 然後可以使用 NodeJS 建立 MongoDB connection pool ，做一些基礎的操作： var mongodb = require('mongodb'); var mongodbServer = new mongodb.Server('localhost', 27017, { auto_reconnect: true, poolSize: 10 }); var db = n...

2012 新年快樂！今年格外不同，也是人稱世界末日將來臨的一年，而在這人生將結束的一年，不免開始思考今年的自我期許。 :-) 回顧去年的風雨，當了一年的『救火隊長』。曾經為了救援朋友的案子，連續三個月，每天平均睡不到一小時，且平均連續工作達72小時以上，如果過程中突然一命嗚乎，一點也不意外。還好，這樣可怕的惡夢，都一一挺了過去，雖然身體似乎出現了點問題，不時陣痛襲來。不過，老天讓我完好的活下來，是祂已經頒發『超級救火員勛章』的最佳證明。 我總相信，只要有信念和方向，任何困境都是老天賜予的挑戰，每當苦盡甘來，就會有許多更好的機運等著。事實上，當了一年職業救火員不是沒有好處，看到了許多人不為人知面貌，許多業界的問題和盲點，更認清了自己該做的事，也得到了更棒更成熟的點子。甚至，某個程度上，已經不害怕死亡突然降臨。 為什麼過的這樣辛苦？為什麼總是孤單的拼命？是否該檢討一下自己？ 還清楚記得，這一年有些人這樣問過我，我都沒有正面回答，直到現在才有時間靜下來思考這個問題，也自我檢討了一番。 如果因為負責任而辛苦減壽，為了理想而拼了命和全世界作對，那我真的想不出有任何一點不正確的地方。我只能推論，許多人不願意辛苦，甚至可以『不負責任』去避免辛苦；許多人沒有懷抱理想，所以沒有拼命的目標，只有隨波逐流的生活。 真的要自我檢討，除了憤世忌俗外，就是我死腦筋的總是依據一件事的『順利和成就』，考量應該做什麼，甚至不是自己的義務，也會執行到底，貫徹著父親所囑付：『幫忙之前叫幫忙，幫忙之後叫責任。』然而，許多人理所當然以為處處都是我的義務和責任，一股惱全加諸於我身上。使我，做會自己勞累不堪，不做則內心不舒服，痛苦萬分。 而這樣的個性，讓我和傳統做生意一點都不搭軋，因為我永遠不愛也不喜歡打『把對手權利變成對手義務』的拉拒戰。在這樣的商場戰爭下，人人都不想執行自己的義務，只想行使自己的權利，甚至讓對方的權利變成自己的權利。不過，雖然不喜歡，但不代表我不懂，每次回歸原點和原貌來看，就會發現『人有多不要臉』和『許多醜陋的臉孔』的戲碼都正在天天上演，過程中的種種掩飾都讓人不敢相信，任誰看了都會臉紅找洞鑽。 如果這樣才能不辛苦不孤獨，我寧可苦一輩子。我也永遠不相信，那樣的結黨，能夠有什麼未來。此外，如此彆扭的生意，也不是我所期望的目標。 過去無數個日子，腦袋從未停止轉動過...

我總認為，當別人問起職業，回答『Startup(新創)』是一件很自傲的事。雖然公司不大，但是從兩手空空開始，完成理想的感覺真的是棒呆了！你必需經歷『養活自己』、『勒緊褲帶』、『想破腦袋』還有『革命不怕失敗』的種種過程，最重要的是，伴隨而來的『人的問題』，很有可能成為最後一根稻草，壓垮我們。但每當跨越過每一個階段，彷彿就吃了甜美多汁的果實，相當有滋味。 常聽到有人說：『先不談成功與否，Startup能做超過一年，就相當不容易了。』，其實是事實，從創業中敗陣下來的人不在少數，敗陣的原因更不勝枚舉，有人是受不了壓力，有人把持不住Cash Flow（現金流），有人經營心態不正確，或是 idea 失敗等等。但是，這些原因真的都比不上『同伴』所造成的打擊。 如果你不是一個人創業，而是三五好友有志一同，那我要恭喜你，畢竟要能找到方向相同，又有足夠能力的人一起是非常困難的。但是，我也要為你感到遺憾，因為『人的問題』會帶來更多波折和困難，造成創業失敗的比例更高。『同伴』是個雙刃劍，雖能共患難，有革命情感，但也會因決裂而一夕之間毀滅。 這裡有一個朋友的小故事，相當常見，或許大家都很熟悉其中情節： 有一群人在學校就是好朋友，而所會的技術也讓他們相當出類拔粹，於是，他們孕釀出創業的想法。為了小試身手，這些人開始共同接一些小案子，並培養革命情感。看似一切很美好，但在過程中問題出現了，有人怠惰（或是能力不足）造成其他人負擔增加，又或者是因此造成案子無法順利結案。好不容易，其他隊員們跳出來『Cover』，讓一切過了關，客戶也付了錢。 然而，問題才正要發燒，在分配利益時，有人開始提出不滿：『為什麼出包的同伴，可以拿的錢和沒出包的人一樣多？為什麼救火的人，幫出包的人完成不是自己的大部份工作，卻只拿到原本的待遇？』此外，對工作的分配也頗有微詞，有人認為自己做的工作，相對困難許多，應該分到更多的錢。更誇張的是，每一個人都生怕別人多拿或是拿的比自己多。 還好，為了讓大家不要決裂，盡可能滿足大家的要求，有人跳出來處理這件事，除了自己掏腰包，甚至動用了原本大家講好要保留下來的『公基金』。然後發現，雖然大家都同意切出一部份成為公基金，但心中仍然認定這公基金有一部份是屬於自己的，隨時都可以要回去，有人更不時想動用或拿回這個錢。一旦動用公基金，就會牽動到大夥的神經，引發更多莫明其妙的問題。 問題...

對所有電腦使用者而言，執行一支應用程式就像吃蛋糕一樣簡單。對於程式開發者而言，寫支 Hello World Program 並跑起來，也是三十秒內可以完成的事。但是，這樣容易的動作，其實底層有著複雜的機制，否則短短十行程式碼的 Hello World 能夠動起來，真的是奇跡了。想要知曉程式是怎麼被作業系統執行，要追溯到 Process 的機制，在研究過 Linux Kernel 的 Process 相關機制後，一切就將明朗。 註：在本篇文章內，都將會假設 binary program 已經被作業系統解析並放到記憶體執行，說明只著重於 Process 的部份 。雖然 Process 與 binary program 和其載體息息相關，但本文不會討論 ELF 的細節，有興趣的讀者可以自己去尋找相關文件閱讀。 若你是程式開發者，對『Process（程序）』一詞應該不陌生。嚴格來說， Process 就是處於執行狀態的程式，如果參考一些原文書或英文文獻，它們也許會這樣定義：『Process is a program in execution』。所以我們可以認定，Process 的組成，是擁有著『程式執行檔的 binary code + 記錄資料的記憶體』。 本文將 Process 分成內外兩個角度來探討： 從 Process 內部，程式執行的觀點  從 Process 外部，也就是作業系統的觀點  程式執行的觀點 單純以 Process 內部的角度來看，Process 就是一般的程式碼被放到記憶體執行。曾於舊文『 Linux 下程序的記憶體映射 』略為提及，一支程式擁有著數個 segments（區段），並仰賴著這些 segment 來持續運作。大致上來說，每個 segment 有不同的用途： Code Segment - 存放主要程式 Data Segment - 存放已被初始化並賦予值的全域變數 BSS Segment - 紀錄尚未被賦予值的全域變數 Stack Segment(Stack/Heap) - 紀錄 Process 在執行時動態註冊的變數包括 function 中的 local variable 對程式本身來說，會動態並隨機使用的是 Stack Segment，程式向作業系統(OS) 要記憶體空間...