Reading time ~3 minutes

之前一直沒在淘寶買過東西, 所以也沒體驗過從對岸買個東西到台灣到底多快, 這個第一次呢, 就給了小米盒子 2

之所以突然想買小米盒子, 主要的原因是, 之前看影片, 都在電腦上射手影音播放器看, 很方便也不用煩惱字幕的問題, 但搬到了新家之後, 有大的電視後, 再用電腦的小螢幕看就有點過不去了

本來是用PS3透過DLNA看放在電腦上的影片, 電腦上跑得是Universal Media Server, 不得不說這是一個不錯的open source軟體, 可以轉碼也可以結合字幕, 但一個問題就是, 常常中文(而且是大部分的)字幕顯示有問題, 雖然後來發現是MEncoder的問題, 改用ffmpeg的話就正常了, 但字幕還是得自己先上網找好, 懶慣了, 實在很不想手動, 後來看到小米盒子看影片, 甚至透過DLNA看, 都有自動尋找字幕功能, 一看到這個就毫不猶豫的上淘寶下訂了


今天下午, 小狗狗, 喔…不是, 是快遞, 送來了一個包裹:

先來看看, 這包裹旅行了多少的時間:
其實也沒很久, 4/30下訂, 5/3就收到了, 還蠻有效率的, 而且運費也不算貴
 
包裝還蠻仔細的, 除了快遞郵包外, 裡面又一個紙箱包住原先的包裝, 存心讓人多拍一張開箱照的(誤), 裡面多了一張使用說明說, 這是店家附的, 並不是小米盒子原本的說明書, 由於我買的是所謂的強化版, 是店家改過的, 所以多了這一張, 還算貼心
 
這就是原本的包裝, 就很簡潔, 小米的風格, 這樣的設計除美觀外, 應該也降低不少印刷成本吧
打開盒子, 不意外的盒子就躺在裡面(繞口令呀?!), 也是黑黑的, 說實在的…不漂亮, 談不上啥設計感, 不過還蠻小的, 如果不漂亮, 做成電視棒或許更好, 我還有機會把它藏起來 XD
本體現身, 真的是沒啥, 黑黑的印個"mi", 倒是真的不大啦! (我是不是說過了?), 另外還有個遙控器, 店家還送了矽膠保護套, 這遙控器, 第一時間還是讓我想起Apple的遙控器, 像的亂七八糟的, 只是Apple的銀色黑色設計還是比較好看, 不過也不能這樣比啦, Apple那隻遙控器就差不多快這一台一半價錢了
開箱之後當然要裝上電視實測囉, 先開個影片看看:
對呀, 到底誰這麼狠心? 我也想知道…喔, 不, 離題了….第一印象, 其實不太好, 一開始播影片時斷斷續續的, 並不是很流暢, 我接的還是有線網路
官方版的, 看起來有些影片並不能在台灣播, 還有不少是得付費的, 老實說, 看到一開始那品質我不會想付費, 雖然把環繞音設定打開, 但在我家的音響上感覺不出多聲道, MOD的音質都比它好
由於是所謂的"強化版", 所以除了原先的小米盒子桌面外另外還有裝了米睿桌面
從這邊就有比較多…嗯…就…那個…影片.. (喂, 想到哪去啦?是X劇那類….)
由於這些影片, 來自於各大知名網站(像是愛奇藝), 所以片源好像蠻充足的, 但實際上看起來的品質…就別期待了, 影片目前看到也都只有兩聲道, 我還是透過DLNA看我電腦上的比較實在
DLNA, 一如預期, 自動會幫我配對字幕, 字幕當然是由射手網下來的, 這的確是我要的功能, 5.1聲道音效也還在, 已經達標了….但玩了一下, 好像不只這麼簡單, 居然還可以開啟3D, 這感覺好像很不得了, 趕緊打開戴上3D眼鏡看…..看了一分鐘後….呃…還是關掉好了…這啥鬼….
東西還真只要做到一項打中使用者想用的, 就會有人買單, 看來小米成功的其中一個因素就是這個吧…對我來說, 字幕這功能真的實用呀….
Reading time ~1 minute

過完年, 趁著轉換工作的空檔, 去了新加坡玩, 也順便去了馬來西亞的樂高樂園(Lego Land)

這樂園算是蠻新的, 2012年的九月才開幕的, 至今也不過一年多, 地點蠻偏僻的, 但從新加坡搭巴士過去(我們是搭WTS的車, 門票也是透過他們買的)大約一小時吧, 中途要出入海關(新加坡, 馬來西亞)

論設施來說, 這樂園可能有點不及其他著名的主題樂園, 玩樂的設施比較偏年紀小的小朋友, 但對樂高迷來說, 也算是一個天堂

這邊隨處可見樂高拼成的人物, 建築, 尤其是在中間miniland的建築, 相當的逼真

像這棟馬來西亞的KLCC, 拍起來的照片真的很像如臨現場, 感覺不出來這是一片片樂高堆積起來的作品

不過這邊的缺點是, 販賣店賣得樂高其實價格偏高, 不太適合樂高迷來這掃貨

Reading time ~1 minute

好久沒寫Blog了, 先來寫一篇充一下版面

最近由於新房子要裝潢, 為了跟裝潢師傅好溝通, 就自己想辦法用Sketchup塗塗抹抹的, 本以為做這樣的設計圖不是很容易, 沒想到意外的簡單, 就當起兼差室內設計師了…

做這樣一張圖其實還蠻容易的, 只要拿建商提供的CAD檔來修改就好了, Sketchup是可以匯入AutoCAD的檔案的, 由於建商給的圖是平面的, 但這樣就已經很足夠了, 只要把牆壁拉出來就好了, 拉牆壁其也不難, 在封閉的形狀上(原本的平面圖的線有些並沒造成封閉的部份先補齊它就好), 然後再用Push/Pull這個工具把牆面拉出(可以直接輸入高度到你想要的高地)

家具的部份, 當然也可以自己做, 不過比較費工(我自己做出我家的中島, 花了一兩個小時 orz), 找現成的看看樣子也是不錯的選擇, 直接從 http://sketchup.google.com/3dwarehouse/ 就可以找到不少現成的家具, 甚至是裝潢的樣本

Reading time ~1 minute

前一篇有提到, TINKER API提供的四個功能都是很基本的, 如果只靠那四個, 那Spark cloud的負荷會很大, 想像一下, 如果說要做一台遙控車, 把馬達控制的程式都寫在遠端, 那需要發出多少命令? 如果REST API只是負責來發前進, 後退, 轉彎, 其他如該輸出多少給馬達或哪個腳位這類的邏輯留在core上面, 這樣的設計就會顯得合理多了

所幸Spark其實有考慮到這問題, 只是目前的文件真的很殘缺, 還真很難找到相關資料, 這問題的答案就是:

Spark.function()

這函數的作用在於對應core上的函數以及自定的REST API:

這函數第一個參數是REST命令的名字, 第二個則是處理這命令的函數, 相當簡單

Reading time ~3 minutes

image

Spark core跟一般Arduino不同, 它並沒有一個在PC上的IDE供你寫及編譯程式, 這動作完全是在雲端, 開發者在Web IDE上攥寫程式, 之後server會去編譯並下載firmware到Spark core端執行

明明電腦跟Spark core都在眼前, 但程式卻不是在眼前編譯反而繞了一段路從Spark cloud下來, 感覺是有點多此一舉, 但其實Spark cloud的功能不僅於此, 它還提供了一個叫TINKER的服務

TINKER分為兩部分, 一個是手機上的TINKER APP

image

這App的用途就是讓你可以在不用寫任何一行程式的情況下, 就可以測試你的Spark core, 它背後的作法就是發送REST API, 也就是另一部分, 所謂的TINKER API, 到Spark cloud上, Spark cloud在把對應的命令轉到core上面, 由於core設定只要一打開就會連上網連到Spark cloud上, 因此可以用如此的方式控制它

因為可以透過TINKER API來控制core, 加上TINKER API也是公開的REST API, 因此, 我們未必要用Arduino的程式寫法來控制core, 我們也可以透過TINKER API用自己想用的程式語言來做開發

以以下的閃爍LED當做例子:

image

以傳統Arduino的寫法, 這樣一個程式(這範例應該老到掉牙了), 應該是這樣的:

跟C有點像, 當然啦,你不用期待它有啥多執行緒(Multiple threading), 或是啥事件驅動(event driven)等等東西可以用啦, 基本上它也是編譯好跑在Spark core上, core並沒有強大的運算能力跟複雜的硬體可以搞這麼複雜的東西, 有一點要注意的是, 這樣一個程式從Spark cloud燒錄到core去, 原本的TINKER就會被取代而失效, 必須由TINKER APP重新燒錄

至於說到TINKER API, 由於是REST API, 因此你可以用你習慣的語言去包裝, 不管是java, javascript, 或是go也好, 包裝它相當容易, 基本上目前也只有四個API: digitalwrite, digitalread, analogread, analogwrite

我包裝了Node.js跟Go可以使用的版本, 需要的人可以直接取用:

  1. Node.js module: https://github.com/julianshen/SparkCoreJs
  2. Go: https://github.com/julianshen/SparkGo

如果改用了Node.js或是Go, 那這個閃爍程式該如何寫?

Node.js:

這邊就可以把原本用"delay"的方式改用javascript中的setTimeout來實作

Go:

Go這邊則就是用了Tick

Access token跟device ID其實是可以去你的Web IDE上查到的

透過TINKER API, 這樣程式就不用一定得要"on board"去執行, 而且使用的程式語言也不會有侷限, 但缺點是, 首先要考慮到網路所造成的時間差問題, 另一個問題是, 現在提供的API像是digitalread這樣的API都非常的基本, 如果所有程式全部放在遠端, 遠端程式就必須要很頻繁的透過Spark cloud來發號司令, 如果連上Spark cloud的core越多, Spark cloud的負擔就相當可觀, 如果能提供custom command或custom api的方式, 把部分常態的邏輯變成在core端執行的內儲程序被呼叫, 或許可以減輕些Spark cloud的負擔