淺談 Hacking LXDE 簡報上線

於 Tossug 心得分享的《淺談 Hacking LXDE 》簡報上線，歡迎各界多多指教。

Hacking_LXDE.pdf

* 更多細節請參閱舊文章《讓我們輕鬆自在設計自己的 LXPanel Plugin》

這個網誌中的熱門文章

Web 技術中的 Session 是什麼？

圖片
很久沒更新了，自從十二月底退伍之後，一直忙著將書完稿給出版社，沒空坐下來好好在 Blog 上寫點東西。沒辦法，在當兵時閒不下來，就答應了出版社的邀約開始寫 Node.js 的書，因此欠下了書的債。還好，如預期的寫完了，預計這一兩個月應該就會上市，還請各界多多捧場！
會寫這篇文章的原故，是因為在 Facebook 的社群上，有人問起了關於 Session 和 Cookie 相關性的問題。其實，社群的人都很好，有許多熱心的網友願意幫助別人。不過，為了幫忙回答問題，大家七嘴八舌的東說一句西說一句，甚至引起莫明的論戰，實在不是一個好的現象。況且，使用不同語言、有不同技術背景的人，都各自用自己的角度去描述和解說，讓原本就已經不懂的人更有如瞎子摸象，見不到全貌，搞更糊塗了。對發問的人來說，也不知該聽誰的好。
說來湊巧，筆者剛好在剛截稿的 Node.js 書籍中，對 Session 概念也有許多著墨。所以之前稍微在網路上查過，發現鮮少有人提出對 Session 技術的完整說明，而多半是討論 ASP、.Net、Java、PHP 等語言或框架中如何使用 Session，以及一些延伸的特性，以致很多人對 Session 的概念相當片面。因此這次的事件後，一些網友也建議我把在 Facebook 上回應的完整內容，在 Blog 發表記錄下來，讓更多人對 Session 有個比較完整且正確的認識。
本文目標
在 Web 的世界裡，Session 已經是被廣泛使用的一種技術，大多數的 Web 開發者，肯定都能運用自如。在現今的各類 Web 應用程式的開發框架和工具中，Session 也已經被包裝成容易使用的模式，所以本文也就不再多討論 Session 怎麼去使用，而是著重在 Session 的原理和實現上。要知道，無論是使用哪一種語言，這 Session 概念上都是通用的，沒有什麼不一樣。
Session 是什麼？
Session 之所以會存在，是因為 HTTP 為 stateless 的設計，Server 和 Client 不會一直保持連線狀態，也不會有雙方狀態的即時更新，所以，Server 並不知道 Client 的狀態（像是是否已經登入）。因此，後來的網站開發者，採用 Session 這樣的設計來解決這問題。有趣的是，Session 機制在最早的 CGI 年代，是完全要程式設計師徒手寫出…
繼續閱讀

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(&#…
繼續閱讀

淺談 USB 通訊架構之定義（一）

圖片
USB(Universal Serial Bus) 的應用範疇以及價值已經不需要再多做說明，其身影從 HID(Human Interface Device)、隨身碟（USB Stick、Flash drive、Pen drive）到各種類比式或非連續訊號接收器（如： Webcam、Microphone、DVB Receiver），更進一步可以講到各種通訊裝置或外接設備，甚至是取代和模擬舊式通訊傳輸線（Serial Port）。USB 所有的 Spec 和相關資訊 ，可參考 http://www.usb.org/ 。

USB 整體運作模式

一般來說 USB 的通訊結構有如 Server/Client，以 PC 上的情形為例，位於主機上的 USB 裝置稱為『USB Host』，我們可以在上面外接上數個裝置（與 USB Host 相連的裝置通常被稱為 USB Device 或 USB Client）。

底層上，『Host 負責主導整個 USB 結構的通訊』，它會輪詢所有的 USB Deivce 以檢查是否有裝置需要傳送資料，所有 USB Device 都必需要等待 Host 的命令，唯有 Host 同意時，USB Device 才可以開始傳送資料。



Host 的行為通常是由 USB Host Controller 在做控制，其控制器是一組控制晶片，而對於現代 PC ，USB Host Controller 的晶片通常都被 Layout 在主機板上，以 PCI Bus 的形式存在供作業系統控制，我們可以使用 lspci 看到它的存在：
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801…
繼續閱讀

淺談 USB 通訊架構之定義（二）

圖片
之前『淺談 USB 通訊架構之定義（一）』已經提過 USB 大致上的概念和一些特性，以及如何從 Linux 上去嘗試驗證 USB Device 上的 Information，但還尚未談及 USB Device 是如何與 USB Host 做溝通。而且，初始化的過程也很重要，該過程會讓一個 USB Device 描述自己的『模式(Configuration)』和『介面(Interface)』以及更多配置上的關鍵訊息。雖然這些初始化過程和定義繁雜，但是拜 OS 優良的包裝所賜，一般驅動程式都可以假設已知或是透過簡單的 API 去取得這些資訊以進行開發，因為大多數初始化動作會自動由 OS Kernel 和 Firmware 所完成。

簡單的 USB Device 初始化流程
插上 USB 裝置Host 請裝置報告『裝置描述資訊(Device Descriptors)』（此過程又稱為 Enumeration）
由 Device Descriptors 得知『模式的數量(bNumConfigurations)』Host 請裝置回報『模式的描述資訊(Configuration Descriptors)』
由 Configuration Descriptors 得知『介面的數量(bNumInterfaces)』Host 請裝置回報『介面的描述資訊(Interface Descriptors)』
由 Interface Descriptors 得知『端點的數量(bNumEndpoints)』Host 請裝置回報『端點的描述資訊(Endpoint Descriptors)』
由 Endpoint Descriptors 得知『該端點的資料傳輸模式(bmAttributes)』等訊息等待驅動程式進行後續處理整個 USB Device 的描述結構可以圖表示：
當然，若不是 USB Device 設計者或是 USB Host Controller 晶片的 Firmware/Driver 開發人員，可以不用知道這麼多過程細節，因為無論是 Linux 還是其他作業系統，它們都會將這些最低階的過程包裝起來，等著驅動程式去使用，而 Linux Kernel 上負責此任務的就被稱為『USB core』。

註：因為古老的 DOS 在設計上沒有 USB 的支援，故沒有這種中間層的包裝，若要在上面開發 USB 驅動程式…
繼續閱讀

Koa 2 起手式！

圖片
在 Node.js 的世界裡，說到今天最潮的 Web Framework，肯定就是 Koa！其用了最新的 JavaScript 語法和特性，來改善 Web Framework 的設計。只不過，Koa 雖然相對於其他舊的 Web Framework 來說有相當多的進步，但很多人卻相當討厭 Koa 的 Generator 設計，尤其是那些「*」符號，那不知所謂的 yield 也讓很多人不舒服。所以至今仍然有許多人在使用 express 來當作自己的 Web Framework，寧可繼續使用那老派的 callback 設計，而不肯嘗試 Koa。

隨著 ECMAScript 標準的進步，Koa 才剛被開發出來沒多久，原本的開發團隊就立即著手打造 Koa 2 ，開始更進一步採用更新的 JavaScript 特性，以 async/await 語法重新打造了全新且更簡潔的框架。可惜的是，由於 async/await 語法一直遲遲沒有被 JavaScript 引擎原生支援，因此總需要靠 babel 編譯打包程式碼後，才能正常跑在 Node.js 之上。這讓 Koa 2 一直無限期處於非穩定版，讓原開發者從開發的一開始，就打算等到 V8 和 Node.js 開始原生支援 async/await 後，才會被以穩定版（stable）的姿態釋出。

所以，即使 Koa 2 到了今天已經相當穩定，也開始有不少人使用在自己的線上服務，卻一直無限期處於非穩定版的狀態。

另外，由於 Koa 2 大量使用 Async/Await，如果你還對 Async/Await 的使用還不熟悉，建議在閱讀本文之前，先閱讀舊文「JavaScript 好用的 async 異步函數！」來學習如何使用。

學習 Koa 的好時機來囉
總算，日前 Node.js v7.6.0 釋出後已經正式宣布原生支援了 async/await 語法，而且不需要額外的參數選項。伴隨著這個消息，Koa 2.0 也隨即正式釋出了！

Node.js 內建支援 ES7 的 async/await 真的是非常棒的消息！過去我們使用 async/await，都還需要 babel 的協助才能正常跑在舊版的 Node.js，不但開發上相當麻煩，非原生的各種 ES7 特性也浪費不少額外的記憶體和效能，這樣的問題在斤斤計較效能的 Server 環境下，更是讓…
繼續閱讀