發表文章

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

商業操弄,軟體研發人員不喜歡做的事!

在國外,許多大型軟體公司林立,老牌軟體商建立了不少現今軟體業仍在使用的遊戲規則。而比較小的軟體外包商、工作室或是個人,也糊裡糊塗依照這些大公司使用的遊戲規則走,甚至是遵守不合時宜的淺規則。然後,軟體業進入了國內,又被代工思維牽著走,軟體業因此哀嚎聲不斷。軟體研發人才不喜歡去操弄商業,卻被商業操弄著。

身為軟體外包或是軟體客製化的外包商,你是否曾遇過,客戶有很多大大小小的鎖碎要求,不定期會交代過來? 這些修修改改,看似不癢的功能和需求,做起來毫不費功夫,三兩下順手就能完成,卻往往造成雙方驗收標地的分岐,此外,不知不覺中所累積的份量,也讓結案時間遙遙無期,甚至造成軟體產生更多的問題待解決。對於只想當水電工的研發人員,總是在客戶的要求下,修完馬桶順道通水管,又補個土、也打個臘。另外,如果馬桶旁邊剛好有漏水,那你要自認倒楣了,因為客戶也會請你幫忙『順手』解決一下,或認定是你在修馬桶時弄壞的。是吧,令人難過。

難道研發人員就要這麼可憐嗎?我們做錯了什麼,為何就要這樣被對待?明明是為了提供更好服務,卻累死三軍,又讓人有把柄指著鼻子唸。更慘的是,一旦這些看似不起眼的修修改改,累積成有影響力,讓專案與合約內的需求不完全相符。客戶就有機會利用『與合約不符』的矛盾點,再殺下一城。

筆者也同是天涯淪落人,曾經不斷思考這問題也同時咒罵著台灣的業界,咒罵他們總不給軟體商有活命的空間。尤其受了委屈後,更是一股惱自命不凡,認為自己無論做什麼樣的事,都應該比一般人收取更多費用,以平心頭之恨。但過些時日後,經過冷靜思考,發現是一開始雙方的互動模式就錯了,或許更仔細檢視這個行業,才能找到改變現況的辦法。

大多數軟體開發不是演藝事業

一直不認為『軟體程式設計師』是演藝事業,所謂『台上一分鐘,台下十年功』不能完全形容軟體開發的工作。雖然,越厲害的研發人員,越能設計好品質的軟體;越是名不經傳的軟體商,也越難生存於業界。許多面向與藝人生態有些相似,但其實完全不是這個樣子。

因為我們雖練功多年,在專案過程中,卻仍然做很多沒技術性又取代性高的工作,或是『順手工作』這類連項目都寫不出來的事。所以,與演藝事業最大的不同是,我們不是只做一件事:『像巨星一樣站上台吸引全場目光,解決觀眾們長達數十分鐘的無聊時間』,而是因應專案需求,巨星仍然要下海當工讀生或工作人員,甚至是清潔工。所以,大多數軟體研發人員,其實扮演的是『跨年…

NodeJS + Express + i18next 支援多國語系吧!

除非是區域性的網站服務,不然在這個網路通全世界的時代,開發網站服務就一定有多國語系的需求。一般來說,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):
{ "example": {…

【企業顧問咨詢】為您的產品選擇作業系統解決方案

你將為自家的產品,選用什麼樣的作業系統?我想,這年頭,不外乎是 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 與 MongoDB 的邂逅

雖然 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 = new mongodb.Db(&#…

苦其心志,勞其筋骨後,世界末日年快樂!

2012 新年快樂!今年格外不同,也是人稱世界末日將來臨的一年,而在這人生將結束的一年,不免開始思考今年的自我期許。 :-)

回顧去年的風雨,當了一年的『救火隊長』。曾經為了救援朋友的案子,連續三個月,每天平均睡不到一小時,且平均連續工作達72小時以上,如果過程中突然一命嗚乎,一點也不意外。還好,這樣可怕的惡夢,都一一挺了過去,雖然身體似乎出現了點問題,不時陣痛襲來。不過,老天讓我完好的活下來,是祂已經頒發『超級救火員勛章』的最佳證明。

我總相信,只要有信念和方向,任何困境都是老天賜予的挑戰,每當苦盡甘來,就會有許多更好的機運等著。事實上,當了一年職業救火員不是沒有好處,看到了許多人不為人知面貌,許多業界的問題和盲點,更認清了自己該做的事,也得到了更棒更成熟的點子。甚至,某個程度上,已經不害怕死亡突然降臨。

為什麼過的這樣辛苦?為什麼總是孤單的拼命?是否該檢討一下自己?
還清楚記得,這一年有些人這樣問過我,我都沒有正面回答,直到現在才有時間靜下來思考這個問題,也自我檢討了一番。

如果因為負責任而辛苦減壽,為了理想而拼了命和全世界作對,那我真的想不出有任何一點不正確的地方。我只能推論,許多人不願意辛苦,甚至可以『不負責任』去避免辛苦;許多人沒有懷抱理想,所以沒有拼命的目標,只有隨波逐流的生活。

真的要自我檢討,除了憤世忌俗外,就是我死腦筋的總是依據一件事的『順利和成就』,考量應該做什麼,甚至不是自己的義務,也會執行到底,貫徹著父親所囑付:『幫忙之前叫幫忙,幫忙之後叫責任。』然而,許多人理所當然以為處處都是我的義務和責任,一股惱全加諸於我身上。使我,做會自己勞累不堪,不做則內心不舒服,痛苦萬分。

而這樣的個性,讓我和傳統做生意一點都不搭軋,因為我永遠不愛也不喜歡打『把對手權利變成對手義務』的拉拒戰。在這樣的商場戰爭下,人人都不想執行自己的義務,只想行使自己的權利,甚至讓對方的權利變成自己的權利。不過,雖然不喜歡,但不代表我不懂,每次回歸原點和原貌來看,就會發現『人有多不要臉』和『許多醜陋的臉孔』的戲碼都正在天天上演,過程中的種種掩飾都讓人不敢相信,任誰看了都會臉紅找洞鑽。

如果這樣才能不辛苦不孤獨,我寧可苦一輩子。我也永遠不相信,那樣的結黨,能夠有什麼未來。此外,如此彆扭的生意,也不是我所期望的目標。

過去無數個日子,腦袋從未停止轉動過。啄磨過許多想法,也思考過許多問題…