淺談 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 年代，是完全要程式設計師徒手寫出…
繼續閱讀

上手使用 JavaScript 的 Map、Reduce 吧！

圖片
雖然有些概念類似甚至可以相通，但這裡並不是指常聽到的「MapReduce」，本文目的不是要討論如何運用 MapReduce 這樣的架構去處理大資料庫。這裡真正要討論的是，如何使用 JavaScript 裡陣列（Array）中的 .map() 和 .reduce() 方法，並把一些常見的使用方法和情境描述出來大家進行參考。

很多人對這兩個方法不習慣，原因不外乎是這兩種方法本來就不是一個非常直覺的東西，在大多數 JavaScript 語言的開發情境中，其實也沒有非得使用的理由。但不得不說，習慣了這兩個對陣列操作的方法，程式碼會變得簡潔，也更容易能處理一整批的資料。有時也能順便學習到一些「Functional Programming」會用到的概念，無論是在改善程式品質，還是投資自己的角度上，都有相當好處。

從最簡單的遍歷陣列開始
面對一個陣列裡的一堆資料，我們一定是從遍歷開始，一一處理裡面的每一筆資料。你也許已經非常熟悉如何遍歷陣列，最常見的不外乎就是兩種做法。

使用 for-loop：

var myArr = [ 1, 2, 3 ]; for (var index in myArr) { console.log(myArr[index]); }
使用陣列內建的 forEach 方法：

var myArr = [ 1, 2, 3 ]; myArr.forEach(function(element) { console.log(element); });
使用 .map() 對每個陣列元素加工
有些時候，我們想對每個陣列元素（Element）進行加工處理，於是最土法煉鋼的方法大概就是這樣：

幫每個元素加一：

var myArr = [ 1, 2, 3 ]; for (var index in myArr) { myArr[index] = myArr[index] + 1; } // [ 2, 3, 4 ] console.log(myArr);
這時你可以使用 .map() 方法來達成同樣目的：

var myArr = [ 1, 2, 3 ]; var newArr = myArr.map(function(element) { return element + 1; }); // [ 2, 3, 4 ] console.log(new…
繼續閱讀

JavaScript 好用的 async 異步函數！

圖片
先聲明，async 異步函數是 ECMAScript 第七版（ES7）才被支援的語法和特性，目前 ES7 還沒有被大多數的 JavaScript Engine 所實作，如果你要使用，需要用到 babel 這類工具，先把此程式編譯轉換，讓其可在舊版本 JavaScript Engine 上執行。

如果你覺得以 co 模組來操作 Generator 很好用，你可以想像 async 異步函數就是原生的 co，幾乎是同樣的使用方式，同樣的使用概念，只不過不再需要使用 generator 和 yield 這類語法。如果你是個過不了在函數上有個醜陋「*」符號這一關的人，async 異步函數的使用方式應該會讓你感覺到舒服許多。

什麼是 async 異步函數（async functions）？
異步函數使用方式其實和一般的函數一樣，只不過在這函數之內的程式，可以用 await 的語法去執行並等待異步工作（如：Promise）而不需要使用到骯髒的 callback function。宣告並使用一個 async 異步函數，就是在定義函數時加上「async」，然後直接執行這個函數即可，簡單的範例如下：

async function myAsyncFunc() { console.log('Hello async functions!'); } myAsyncFunc();
搭配 Promise 的使用
Promise 通常被大量用來管理非同步的工作，並讓開發者容易管理錯誤拋出等機制，一個典型的 Promise 使用如下：

var task = new Promise(function(resolve, reject) { // 執行一個非同步的工作，完成後呼叫帶入的 callback doAsyncTask(function(err) { // 有問題呼叫 reject，並帶入錯誤值 if (err) return reject(err); // 成功呼叫 resolve 並帶入回傳值 resolve('VALUE'); }); }); // 使用 then 去執行並等待工作完成，成功會呼叫 callback，失敗則用 catch…
繼續閱讀

淺談 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 驅動程式…
繼續閱讀

淺談 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…
繼續閱讀