我同事向我介紹了 Swagger (https://helloreverb.com/developers/swagger)。經過簡短評估後，我認為 Swagger 的想法不錯，但實務上是壞的。

Swagger 嘗試為 RESTful API 服務提供一個自我描述的方法並配合一個有用的客戶端工具，以便 RESTful API 的使用者了解服務內容與調用它。

在前文「Raspberry Pi Kiosk Designing - based on HTML5 and OMXPlayer」中，我曾提到在 x86 PC 上也實作了一個相同設計的替代品。其實我一開始就是在 x86 PC 上實踐這個設計想法。

在 x86 PC 上，我使用 mplayer 作為 omxplayer 的替代品，除此之外的所有條件都一樣。由於 Raspberry Pi 的執行效能並不好，在上面直接開發產品會浪費不少執行等待時間，所以我將此替代品視為在 Raspberry Pi 開發 Kiosk 產品的模擬器。當然將此設計方案作為正式產品對待也無不可。可以搭配 Intel Atom 或 AMD APU 的廉價組合，而且 HTML5 介面的操作流暢度遠勝 Raspberry Pi。

今年3月20日到23日間，在高雄國際音響展又在老地方高雄國賓飯店舉行。我今年當然挑了週末連去了兩天。不過一時事忙，到今天才想起寫篇記事。

年度特色

今年的高雄音響展，有三個特色。第一是發行了「黑膠」版本的大會示範唱片。第二是有許多的小型發燒話題與現場演奏活動。第三是在 7 樓畫了一塊耳機專區，讓耳機族不必四處打遊擊，就可以聽個過癮。

大約半年前，我發佈了「omxplayer-dbus」套件，以便在 Raspberry Pi 上控制 OMXPlayer 播放高畫質影片。我最初的目的，是想結合基於 HTML5 的 UI 引擎設計在 Raspberry Pi 運作的嵌入式桌面環境，更具體的說法，就是一套 Kiosk 環境。我中間去做了工作上的一件軟體專案後，又有時間繼續了。在經過一陣比較後，我覺得用 iceweasel (Firefox 的 Debian 分支) 就足夠實現我的目的。所以我就用它結合 omxplayer 實作了一個具備 kiosk 要素的簡單範例。本文設計架構之宗旨，就是要無縫地銜接瀏覽器與 omxplayer 的協同合作，讓設計者可以像使用 HTML5 的 video 標記一樣地輕鬆處理影片播放工作。

我在 Raspberry Pi 上安裝的作業系統是 Raspbian 7 ，就是 Debian 的 Pi 分支。它提供的 iceweasel 版本足夠支撐我的實作需求。至於它上面的 webkit 引擎，則略顯老舊，有些 HTML5 規格的支援度不如 iceweasel ，故被我捨去了。此外， FirefoxOS 也有 Pi 的版本，我想此文的實作概念也能應用在 FirefoxOS for Pi 。

在 Unix 類系統(Linux)下，如果你曾經嘗試用 Apache + PHP 撰寫一段程式去執行 mplayer/vlc 等影像播放程式，將會得到 Audio: no sound Video: no video 這類的錯誤訊息；又或者執行各種視窗 GUI 程式，也都會得到類似 Can not open display 的錯誤訊息。這些都是 X Window 的安全限制所帶來的影響。

X Window 的設計架構，一開始就允許在同一台主機上登入多個使用者且擁有各自獨立的視窗桌面環境。既然如此，那麼 X Window 就必須提供隔離不同視窗桌面環境的安全性。總不能讓甲使用者執行的視窗程式的畫面顯示在乙使用者的桌面上。如果你或週遭朋友熟悉 X Window 的各種使用途徑，就知道這些事都做得到。我不解釋細節，各位在此只需要了解系統啟動的 Apache 服務被隔離在 X Window 的視窗環境之外，所以透過 Apache 調用的 PHP 程式自然也被隔離在外，而無法再去執行依賴視窗環境的各種 GUI 程式。

VAAPI (Video Acceleration API) 是 Linux 環境下的其中一種利用 GPU 加速視訊播放(硬解播放)的程式介面。在 Linux 常見的影像播放程式中， vlc 是很早(v1.1)就支援 VAAPI ，反倒是 mplayer 遲未正式支援。本文記錄我在 Debian jessie 上安裝 mplayer 支援 VAAPI 之事。

日前，我將 Raspberry Pi (以下簡稱 Pi) 透過 HDMI 接上一台 LCD 電視時，發現它在 X Window 環境下的解析度錯誤。明明電視的 OSD 顯示目前顯示狀態為 1080p@60 ，但 X Window 中執行 xrandr 時，卻顯示 18??x9?? 這種奇怪的解析度。此外，我還發現使用 omxplayer 播放影片時，影像內容顯示的座標與長寬比例有微妙的偏差。舉個例子來說，我指定 --win "10 10 1290 730" 的播放座標，預期應該會在 X Window 的範圍內完整顯示。但結果卻是影像內容超出了整個 X Window 範圍，甚至有一部份影像內容被切掉(超過電視可見範圍)。這也讓我發現 X Window 並沒有佔滿整個電視可見範圍，實際上留了一段黑邊。

我需要設置 Pi 連接電視的正確解析度，以及校正 omxplayer 顯示座標錯誤這兩件事。

朋友轉了一篇關於 ptt 鄉民對羅瑩雪「公民不服從也要守法」的回應內容給我看(http://www.ptt.cc/bbs/Gossiping/M.1397565075.A.E46.html)。文章發文者貼出了現在高中公民課本中的其中一段內容，課文寫著 「公民不服從是一種挑戰法律的公開違法行動，行動者往往會與國家執法者發生衝突，甚至可能付出沉重代價」。

但是看完這段課文，再看 ptt 鄉民的回覆內容，我真心為現在大學生的閱讀能力感到憂心。

我看了「黑色島國青年陣線」發的聲明稿說「持續民主失靈，統治正當性蕩然無存」。若說立法院議事效率不彰、密室協商不符民主原則，這我同意。但是說「民主失靈，統治正當性蕩然無存」，我當時就對朋友說這些人「目中無人，抬舉自己」。「黑色島國青年陣線」言下之意「彷彿眾人皆醉我獨醒」。但我要說，我就算喝了兩罐啤酒，也比他們清醒。

陳長文於 22 日投書聯合報「王院長，立院接下來怎麼辦」，其中論點就是我說「目中無人，抬舉自己」的理由。節錄幾點於下:

今天在看維基百科時，無意中看到一個「水書」條目，其中記載： 水族文字與河南偃師二里頭遺址夏陶上的符號有相通之處，水書先生甚至可以大致解讀其含義，這引起了考古學界的重視。進而提出了水族先民來自北方和夏陶符號是一種文字的可能性。這是早些時候的考古研究。

今年由於日本首相安部晉三參拜靖國神社的舉動，再度激起了東亞諸國的抗議，在混亂的東亞安全局勢中，又增加了不安因素。美國也對日本首相此時的舉動表示不滿。

靖國神社的參拜爭議由來以久，幾乎每年都會吵上一陣。不只是日本國外吵，日本國內也有。 不過吵歸吵，許多外國人(就是我們)，僅知道靖國神社內有祭拜二次大戰戰犯，並不了解為何而吵。 週遭朋友就有人問靖國神社和我們的忠烈祠有什麼不一樣？為什麼年年吵？

網友 makotohsu 在部落格中留言說，想更深入了解奧地利經濟學派和他們關於「人的行為和內心邏輯結構」的論述內容。

我的 anobii 書櫃中，奧地利經濟學標籤所列的書目，都可以看看： 奧地利經濟學書目。 另外，我還有一本台灣銀行經濟研究室翻譯，龐巴維克 (Eugen von Böhm-Bawerk) 的「資本積極理論」(Positive Theory of Capital)。這本老書是在 ISBN 普及之前出版的，所以沒有 ISBN 資料，我也就沒放上 anobii 書櫃。二十年以上歷史的大學圖書館，應該找得到。

非經濟學，但有助於理解的書籍，應看維根斯坦 (Ludwig Wittgenstein) 的「哲學研究」。

「いなり、こんこん、恋いろは」(中譯: 狐仙的戀愛入門；或譯 稻荷戀歌)在今年一月開始播放電視動畫版了。 它的故事取景地就是「伏見稻荷大社」，只是劇中改名為「伊奈里大社」。 巧合的是， AKB48 橫山由依冠名的京都遊旅節目「京都いろどり日記」(京都色彩日記) 同月也播出伏見稻荷大社的旅遊介紹。 雖然我自己兩年前也去過伏見稻荷大社，不過還是借節目的內容來次簡單聖地巡禮。

由於我們最後一天一早就要前往関西空港搭飛機，所以這一天的行程就是實質上的最後一天了。 本日的安排是早上參觀泡麵發明紀念館，中午到天神橋筋吃中餐，順便參觀大阪天満宮。 下午前往鶴見三井outlet，晚上到道頓堀、心齋橋逛街採購。

本日交通全程使用 KTP 。

第六天行程(11/12)：東寺 → 梅小路公園 → 西本願寺 → 安井金比羅宮 → 梅田空中庭園展望台。晚餐：千日前 自由軒。

今天是在京都的最後一天。一早起來 check-out 後，將行李寄放在酒店櫃台，然後前往京都駅附近的景點。前幾次來京都都是住在四条河原町或四条大宮，京都駅附近的幾處有名景點竟然都沒去過。於是特地安排了這次參觀行程。下午三點後，我們將前往大阪難波住宿 Supter Hotel 日本橋。

第五天行程(11/11)：神護寺 → 西明寺 → 高山寺 → 錦市場 → 円山公園。晚餐：寿しのむさし。

今天是京都高雄三尾的三寺行程，也就是神護寺、西明寺和高山寺。神護寺也是已經有見頃消息的景點。 另外，我們下山的時間比預定早些，所以就去錦市場逛了一圈。 然後我再趁著黃昏時刻，到円山公園散步。

第四天行程(11/10)：亀岡 鍬山神社 → (嵯峨野トロッコ列車) → 嵐山午餐、嵐山公園 → 北野天満宮 → 晴明神社。晚餐：三嵨亭(高島屋分店)。

本日原本要去參觀嵐山紅葉祭下午場。不幸的是，天公不作美，今天開始天氣變差而且是本次行程中雨勢最大的一天。雖然下午時雨勢漸小，嵐山紅葉祭仍然停辦了。 所以我改成參觀嵐山公園，再一路登上展望台。

另外，同行友人想要搭嵯峨野トロッコ列車，我也利用從亀岡到嵐山的這段空檔，順利地安排他們接上了由トロッコ亀崗出發的トロッコ列車。

Sass - http://sass-lang.com/。 Sass 是什麼？

Sass 是為了簡化 CSS 文件的重覆內容而設計的擴充語言。這不是 W3C 正式的語法規格，而是 Sass 設計者自定的。相同目的者還有 LESS 。這些擴充語言存在語法差異。

Sass 同時也是指將 Sass 語言轉譯為正規 CSS 語言的工具。

今有一項基於 GUI 的應用軟體，需要整合三個輸出入裝置。其中有兩個看似平常，但卻具有特殊行為的裝置。

輸入裝置S:

1. 圖像輸入裝置，就是搭配觸控式螢幕或滑鼠的 GUI 介面。

輸入裝置K:

1. 接受使用者輸入動作，再將輸入控制碼主動傳送出去，它不理會接收者是否準備接收訊息。 可以將它想像成鍵盤。使用者按下鍵盤按鍵後，鍵盤立刻就會發出鍵碼給作業系統(以中斷的形式)，並不管作業系統這端是否有任何軟體準備讀按鍵。
2. 但是這個裝置有一個特性，就是它要求即時回饋。 它每送出一個指令，就要求接收者在限定時間內回報相對應的控制碼。如果在限定時間內沒有收到回覆，它就認為發生錯誤，轉入它本身的錯誤處理流程。

輸出裝置P:

1. 接受一行訊息後列印到報表。可以將它想像為行印表機。
2. 但是這個裝置也有一個特性。它像是老式的打字機，應用軟體不能連續送出訊息給它列印。 它印完一行訊息後，要回車之後才能再印另一行。 所以應用軟體在送出一行訊息後，要等裝置P 回報它已經回車了，才可以再送下一行訊息。否則下一行訊息不會列印在正確的位置上。

第三天行程(11/09)：延曆寺東塔、延曆寺西塔 → 日吉大社 → 園城寺(三井寺)。

在出發前，我曾考慮要在彥根城和延曆寺之間擇一前往。後來看到紅葉情報說延曆時接近見頃，就決定到延曆寺了。這天也是8點就出門了。