【萌典 x HanGee x DOITT x 黑客松】睡不著嗎?那就不要睡了!

2014年9月3日星期三
熱血的開發馬拉松活動(Hackathon)來囉!讓我們吃吃喝喝、不眠不休地設計應用吧!一群素不相識的設計人,無論是程式設計師、視覺設計師、UI/UX設計師,還是任何一種從事『設計』和『開發』工作的人們,在短短有限的時間內組隊並相互合作,一起投入設計同一個專案,與不同隊伍相互較勁!

這次萌點、DOITT 和 HanGee 合作,將於 9/20 - 9/21 兩天,聯合舉辦 80 人不中斷黑客松活動,熱血的朋友們,快來報名並幫忙宣傳吧!如果你願意贊助,也歡迎聯絡!

報名網址:
http://han-gee.kktix.cc/events/hangeehackathon201409

讓我們回歸原點,什麼是黑客松呢?

由於這幾年國內舉辦過很多大大小小的黑客松活動,大多數人對於黑客松早就耳熟能詳。不過,除了由技術背景的單位和社群自發性舉辦的活動外,許多黑客松活動,比較像是純粹的比賽,讓許多團隊來展示自己研發已久的專案或產品,慢慢脫離了開發馬拉松的原意。所以,因此不免也有許多人對黑客松產生誤解,覺得就只是個普通的比賽活動。

事實上,和時下流行的路跑活動一樣,黑客松並也不是個普通的比賽活動,而是一個讓設計人在閒暇時間,參與的開發運動。解放自己,做自己想做的設計和開發,挑戰自己,在有限時間內做出東西來,才是黑客松活動的原始目的。

我能參加嗎?

對開放社群的朋友們來說,『黑客松』已經是一個再熟悉不過的名詞了,但對普通人來說,只要看到『黑客』兩個字,就覺得是一個敬而遠之的東西。不只如此,很多技術人員和設計師也對這活動有所誤解,覺得一定要非常有實力才能參加黑客松活動。

其實,黑客松和路跑活動一樣,並非只有專業選手才能參加。只要你有興趣、想實際參與多人設計和開發,無論你是學生、普通程式人員、還是新手設計師、初級自造者,都歡迎帶著學習、共樂的心前來參加!

你可以來找人一起完成自己天馬行空的想法,也可以和別人一起完成其他人的鬼點子,亦或是在這找到同伴共同想出新點子!

我能得到什麼?

在這活動中,參加者將帶著愉快的心情前來,一邊吃吃喝喝交朋友,一邊與從未合作過的朋友和高手們組隊,做出作品!然後你會發現,因為只有短短的一兩天,大家將使出混身解數,在短時間內做出出乎意料的驚人成果。最重要的是,也能從其他高手身上學會不少東西!兩天所獲得的東西,絕對物超所值!

此外,黑客松就像微創業,有限的時間、有限的資源、三五好友聚在一起,然後打造出產品,上台公開發表。這是找回自信心和工作效率,以及想體驗創業的最佳途徑!

活動上有什麼?

有高手大大、帥哥與美女人才們,有電有網路、有吃的有喝的,既然台灣的夏天嚴熱,當然還有附上空調視野絕佳的舒適環境,讓大家安心動手做設計、做開發!挑戰自我!

歡迎更多合作單位聯名加入!找人才?重視人才?快來吧!

HanGee 將會持續不定期舉辦黑客松活動,歡迎各界加入並可以以任何形式共同合作。舉辦一個黑客松活動需要食物、人力、場地等各種資源,歡迎您的參與和協助!

如果您是公司行號,這樣的活動,非常值得重視人才的您長期贊助。此外,這也將是你挖掘頂尖人才的最佳場合,履歷和面試怎麼也比不上近距離接觸觀察,實際與人才們合作從頭完成專案,才是最好的方法!

有興趣嗎?請務必與 HanGee 聯絡!

也想要辦黑客松(Hackathon)嗎?也請務必與 HanGee 聯絡!

聯絡方式:hackathon@han-gee.com


嘴炮不再!MDS 加密檔案系統釋出!

台灣的電玩機臺一直是一個很少人探討的遊戲產業,他們外銷機台到國際各大賭場,除了一直在設計讓人願意掏錢的有趣遊戲機外,也真真實實用到很多資訊科技。在多年前一次南部的經驗,有幸接觸到這樣神秘的產業,也幫他們開發過一些東西。而其中一項專案,就是一個加密檔案系統,讓他們可以保護他們的遊戲程式,避免被對手輕易偷走自家的程式。

於是就有了這個 MDS 檔案系統(Middle Stone Filesystem),採用 blowfish 演算法加密,支援 384-bit key 和同時多組 key 的存取。由於作業系統本身會很容易破解修改,要保留可以將解密工作和 key 放在額外的硬體鎖或晶片上,甚至是多組 key 可跨多個硬體晶片存放,增加破解的難度。所以因此也設計了一些單獨的讀取工具範例,讓硬體鎖的開發人員,可以參考做法,寫在其硬體韌體(Firmware)中。不過,更近一步和硬體整合的版本,礙於敏感,這次就沒有釋出了。

專案網址:
https://github.com/cfsghost/mdsfs

其實,這專案多年來一直對周圍的朋友嘴炮說要開放出來,可是一直沒負諸行動(當然也是因為懶惰)。而今天看到 iCloud 被破解的新聞,受到一點資料安全問題的刺激,於是想起這個專案,所以就花點時間挖出來整理一下文件並往 Github 上丟。由於,這個基礎版本很久沒維護了,安全性如何我不能保證,但拿來做學習 FUSE 和加密演算法應用,倒是有點參考價值。如果有人想要接著開發,也非常歡迎!

另外,有些人反應不知道能拿來幹麻。關於這件事,其實把 MDS 當做一個簡單的加密打包工具,也是可以的。

後記

看到 iCloud 被破解的新聞,不由得讓人重新思考雲端和未來物聯網時代,資料安全的重要性。稍為瞭解真象的人通常都會跟你說,千萬不要相信任何人,將東西和隱私放在雲端。而通常你第一個要害怕的是雲端系統管理人員和系統設計人員的操守,他們是不需要經過任何破解手段,即可全權存取你資料的人。再來,我們要擔心的是系統的安全性,設計者和管理者能否真有能力去保護使用這的資料?這從使用者手上的 App、作業系統、瀏覽器,一直到雲端上的一切系統,都是必需要考量的範圍。也因為這樣種種的複雜情境,使用者實在難以得到真正安全的保護。

原因其實很簡單,當檔案自你手邊的機器準備發出去的一刻開始,你的資料便以明碼的方式在程式、網路和機器間處理,或許你手上的 App 很安全,沒有後門;或許你的網路傳輸很安全,有加密所以不會被人監聽;或許雲端伺服器也很安全,經過重重保護。但是,只要有人在過程中找到漏洞,或在其中找到缺口並進入了資料庫,你的秘密就赤裸裸的躺在哪。

包括我自己,總不認為自己運氣會這麼差,不會有人這麼有空或有能力去破解取得自己放在雲端上的資料。畢竟,這些意圖不軌的駭客,要對抗的是像 Apple、Google 這類比哥吉拉還可怕的大公司。我們也總是想,真要是被人看光光了,就當隱私賣給了別人,自己可以向這些大公司求償噱一筆。

就是這樣自我安慰的想法,讓我們從來就不真正在乎資料的安全性。那些所有信件和檔案都要用 GPG Key 先加密過再傳送的人,在我們的眼中,總覺得他們是個怪咖。但,可能隨時我們的報應就會來了呀。就算他們的檔案被偷光,沒有他們的 Key,那些檔案資料根本就是一堆沒意義的亂碼垃圾;而我們,就是什麼都被人看光光。

【Node.js 小密技】使用 crypto 模組亂數產生字串

2014年6月26日星期四
已非常熟悉 Node.js 的人都知道,crypto 模組是一個無中生有的神器。我們可以用它的 API 加工加密資料,也可以解開加密後的包裹。既然和密碼處理相關,當然也有亂數產生器,可供開發者產生一大堆的亂數資料。

如果你需要一個 32Bytes 長度的亂數資料,可以直接呼叫 crypto.randomBytes() 並帶入長度後生成:
var crypto = require('crypto');
var buf = crypto.randomBytes(32);
註:回傳的結果 buf ,是一個 binary buffer,而每一個 Bytes 都會是範圍在 0 ~ 255 (0x00 ~ 0xff)的數字。

不過,在多數應用中,我們更常需要一個亂數字串,而非二進位的亂數資料,這時就需要做一些進一步的加工處理。方法其實不只一種,如建表、取代不可見字元碼等方式都可以,沒有標準做法。但懶惰的開發者們,多半是直接利用 Buffer 內建的 API 來將資料轉換成字串,並指定編碼方式來達成。

下面兩種方法都可行:
buf.toString('hex');
buf.toString('base64');

只是,使用十六進位(hex),會讓你的最後的字串單純只有 0-9 和 a-f 的字元存在,所以使用 base64 是比較好的選擇,讓字串多變並複雜些。

註:base64 編碼是以 6 bits 為單位來進行處理,而 1 Byte 有 8bits。如果你的資料長度非 6 bits 的整數倍長度,base64 會在結尾補上『=』。有些人覺得多了一些『=』符號很醜,就會用 replace() 替代掉或者是一開始就取 6 bits 整數倍長度的亂數資料(如:3 bytes、6 bytes 等等)。

有些情況,我們需要特定長度的亂數字串,也可以搭配使用 substr(),只是要確定生成的字串長度,比我們想要的字串長度還要長。下面的範例,就是取八個字元長度的字串:
buf.toString('base64').substr(0, 8);

當然,若你想要一次搞定,也可以將之前所說的,全部串在一起寫:
var randomString = crypto.randomBytes(32).toString('base64').substr(0, 8);

後記

最近在開發的 Project 中,一直在處理 Token 以及密碼相關的東西,常用到亂數字串。之前用過不少方法,每次要寫不少 code 相當讓人煩燥。所以記錄下來,以後自己直接 copy & paste 即可,也讓有相同需求的人可以直接參考使用。

我的創業原點:科技和藝術的結合

2014年6月19日星期四
義大利咖啡館-科技和人文的結合

看到時不時有新聞在報 POS,一時興起,就去把舊照片翻出來,沒想到癮科技還保留了快十年前的照片和報導『義大利咖啡館-科技和人文的結合』。

這套 POS,是在當時在經營 Coffee Shop (以現在的角度來看,其實是半個 Working Space)時所開發的,店在板橋江子翠捷運站旁(建築物前還有一座三層樓高的羅馬柱),共三層樓約四五百坪左右,店裡沒有對外掛招牌並擺滿了各種收藏品和古董家具,不知道的人看起來像間古董家俱店,不太敢進來,所以來的都是慕名或是口耳相傳,以及喜歡我們咖啡的人,因此也有人以『神秘咖啡廳』稱呼。

不過,Coffee Shop 其實一直不是主業,只是公司的招待、展示中心和團隊休閒區,而應用、工程、軟體開發和軟硬體整合的產品開發才是我們主要的工作。所以我永遠窩在店裡的某一角,寫著我喜歡寫的程式,周遭來來去去的客人並不真的清楚我是誰。

還記得,點餐系統軟體、平板硬體和後面印單系統整套做出來並實際上線,大概是在 2004 年(大概是高二時),報導則是 2006 年的事了。而且因為這套系統和管理流程設計,讓幾百坪的店面,只需要一兩個人就可以完全掌控、經營和服務,讓我們著實省下不少功夫。雖然很懷念當時的日子,但一想到惡房東後來給我帶來的多年痛苦,以及官司上的問題,至今我仍然還是恨的牙癢癢,因而有很長很長一段時間,我絕口不提這段往事。

所以這也是為什麼,多年後看到這標題,感觸極深,當時『科技與人文的結合』和『科技與藝術的結合』這個標語,一直都掛在店裡的展示大螢幕上,因為這是我們自己對設計的最高期許,也是一直身體力行的方向。許多進進出出拜訪我們的人和國內外大佬們,應該多少都看過。只是後來大多數人再次使用這段話時,是在多年後 Apple 的產品身上,這也算是種台灣的悲哀吧。

很多人不知道,我其實非常喜歡喝咖啡,甚至會燒,只不過後來若不是真的跟我很熟的人,可能從來都沒看過我喝。當時店裡的紀念款 La Marzocco 機器,現在還好好保存著,期盼哪一天能夠在我比較穩定的時候,再次拿出來使用或是與朋友分享。

不曉得還有多少人記得我們這家店?但無論如何,總有一天,我會讓他復業。不為別的,就為了從小所抱著的夢,這是我一頭栽進創業和改變世界的原點。

Express 4 來了!好用的 Router 機制

2014年6月15日星期日
還記得前陣子,就在書將出版之際,半路殺出來最新的 Express 4,使得筆者手忙腳亂,緊急通知出版社修改書的內容。將所有使用到 Express 的範例,都特別加上版本號的指定,讓讀者在照著範例做時,能夠使用舊的 Express 3.0,而不會發生任何問題。最新的 Express 4 雖然效能提升不少,也有一些好用的新東西,但和舊版有些微 API 的不相容,此外,也因為是新東西,可能很多東西的支援會發生問題,如果舊版本在上線的產品中運行相當穩定,建議先不要急著升級。

Express 4 做了一些改進,有不少新東西,其中相當值得提的一項就是路由機制(Router)的翻新。如果你以前在使用 Node.js + Express 開發網站服務時,因為 Router 很難管理而痛苦不已,這將是一個你會愛上的功能改進。

傳統的使用方法

傳統的 Router 設定方法依然可以運作,我們可以放心使用。

var express = require('express');

// Create express application
var app = express();

// Apply this router on (/apis/user)
app.get('/', function(req, res) {
    // Home
});
app.listen(8000);


新 Router 物件的使用方法範例

除了舊的方法之外,你可以用 Router() 去建立一個 Express 的 Router 物件,然後管理你一系列的路由規則。

var express = require('express');

// Create express application
var app = express();

// Create a router to handle routes for a set of  user API
var userAPI = express.Router();

// Sign in (/apis/user/signin)
userAPI.post('/signin', function(req, res) {
    // ...
});

// Sign out (/apis/user/signout)
userAPI.get('/signout', function(req, res) {
    // ...
});

// Sign up (/apis/user/signup)
userAPI.post('/signup', function(req, res) {
    // ...
});

// Apply this router on (/apis/user)
app.use('/apis/user', userAPI);
app.listen(8000);

一次指定多種方法到同個路徑

有時候,同一個路徑我們想賦予他不同的方法(如:GET 或 POST),讓它有不同的功能。這尤其是在開發 Restful API 時,非常常用。像是如果我們要設計一套管理使用者帳號(User)的 API 時。

var userMgrAPI = express.Router();
// A set of API to manage users (/apis/admin/user/:username)
userMgrAPI.route('user/:username')
    .get(function(req, res) {
        // Getting user information
    })
    .post(function(req, res) {
        // Create a new user
    })
    .delete(function(req, res) {
        // Delete specific user
    })
    .put(function(req, res) {
        // Update
    });

app.use('/apis/admin', userMgrAPI);

檢查 Parameter 的 Middleware

前面的例子,在路由上設計了一個 username 的 Parameter,每個方法的 Handler 都會用到它。但有一個需求是,既然每個 Handler 都會用到這個 Parameter,也需要檢查這個使用者帳號是否存在,那麼是否可以用類似 Middleware 的做法,寫一次程式套用在所有方法上?

答案是可以的,你可以直接使用 param() 設計一個 Middleware,去安插一個檢查程式在前面,並指定他要檢查什麼 Parameter 欄位。

userMgrAPI.param('username', function(req, res, next, username) {
    if (username == 'fred') {
        next();
    }else {
        res.send(404);
    }
});

// userMgrAPI.route('user/:username') ...

設計一個其他的 Middleware

如果你過去已經熟悉 Express 的開發,應該對開發一個 Middleware 不陌生,在 Express 4 的 Router 上,你也可以引用。通常我們會設計一個 Middleware 去檢查使用者登入與否,或是前面例子所提及的,檢查使用者是否存在,而不需要在每個路徑的 Handler 中都寫一次。

下面的例子和前一個例子有相同功能:
userMgrAPI.use(function(req, res, next) {
    if (req.params.username == 'fred') {
        next();
    }else {
        res.send(404);
    }
});

// userMgrAPI.route('user/:username') ...

後記


Express 4 帶來了新的方法,讓我們可以更好的管理 Router,這讓開發者們可以輕鬆許多,如果你有新的專案要開跑,不妨快來嘗試一下全新的 Express!
Copyright @ 2013 Fred's blog. Designed by Templateism | MyBloggerLab
載入中…

誰在追蹤 Fred

您可以贊助 Fred 持續寫作

廣告與公益


Blog Archive