l

2018年6月22日 星期五

羅技Logitech R500 雷射簡報筆開箱

June 22 12:51~14:16

需求分析

因為工作的關係Teddy經常需要使用簡報筆,雜牌的不算,光是羅技的簡報筆Teddy就買過以下四種(R500是最新上市產品,也是今天介紹的主角)  :

▼畫面節錄自羅技官網

螢幕截圖 2018-06-22 12.57.10


Teddy心中理想的簡報筆應該有以下幾個功能:

  • 重量輕且好握、容易操作
  • 支援藍芽連線,可以省去每次簡報都要外接一個USB接收器的麻煩。這原本也不是什麼太大的問題,但自從買了MBP 2016之後,整個筆電只有4個type-c接口,有藍芽功能在簡報的時候可以少接一個USB接受器就顯得方便很多。
  • 綠光。Teddy用過紅光和綠光雷射筆,覺得綠光指示比較清楚。
  • 可以按鈕讓簡報畫面變黑。有時候希望聽眾把焦點放在講者身上,此時把簡報畫面變黑就可以避免聽眾有意或無意地盯著投影畫面看。
  • 內建鋰電池可直接USB充電。這一點也很重要,因為Teddy使用充電電池,有時候簡報筆用到一半電力突然變成0,因此身邊隨時都多帶著一份備用電池。如果支援USB充電,可以利用休息時間直接用筆電幫簡報筆充電,就不需要擔心沒電的問題,也不用再隨身攜帶備用電池。
  • 外觀好看,讓簡報者看起來比較專業。

之前買過的R400、R800、以及價格非常高「貴」的Spotlight,沒有一個完全滿足Teddy的需求。最接近的要算是要價3999的Spotlight,幾乎滿足上述全部要求,但是它有一個非常大的敗筆,就是沒有實體的雷射光,而是透過軟體在電腦畫面中模擬「聚光燈」的效果。不管網路上有多少疑似「業配文」吹捧Spotlight有多好用,但Teddy覺得這是一個非常難用的產品。近四千元的價格其實專業的講師都可以接受,它要用酷炫軟體功能去模擬聚光效果也OK,但沒必要把實體雷射光的功能拿掉啊。真的覺得好可惜。

***

新品上市

▼昨天在PChome無意中看到羅技出了一款新的簡報筆R500,因為Teddy一直想買一個支援藍芽連線的簡報筆,而R500剛好有這個功能,價格也還可以接受,所以就抱著踩雷的決心買一隻回來用看看。

螢幕截圖 2018-06-22 12.52.32


▼開箱照,把投影器本體拿出來之後才想到要照相XD。

螢幕截圖 2018-06-22 13.26.22


▼支援USB接收器與藍芽連線兩種方式。R400與R800都需要兩顆AAA電池,R500只需要一顆。可惜沒有像Spotlight一樣支援內建鋰電池充電。

螢幕截圖 2018-06-22 13.27.39


▼R800含電池重量76克。

螢幕截圖 2018-06-22 13.31.49


▼R500含電池重量57克。

螢幕截圖 2018-06-22 13.31.21


▼一顆電池11克,所以R500大約比R800少了76-57-11=8克。

螢幕截圖 2018-06-22 13.35.14


▼R500長度比R800短了一公分左右。按鈕分布R500很明顯是學Spotlight,Teddy覺得R800的按鈕比較好按,距離較短,簡報時大拇指不會太忙碌XD。

螢幕截圖 2018-06-22 13.39.32

***

使用

▼有兩種連線方式,Teddy只試了藍芽連線。如下圖使用說明所示,只要同時按簡報器下上下兩顆按鈕3秒鐘,簡報器前端的燈會閃爍,此時便可與電腦透過藍芽連線。

螢幕截圖 2018-06-22 13.44.59


▼MBP 2016很快就找到R800。

螢幕截圖 2018-06-22 13.48.02


如果只是單純使用上一頁、下一頁功能,連線成功後即可使用。但如果要使用「讓簡報畫面變黑」功能,就需要安裝軟體。

▼直接到羅技官網下載R500軟體,安裝很簡單。

螢幕截圖 2018-06-22 13.50.47


▼安裝完畢之後預設情況下長按下一頁按鈕就可以「讓簡報畫面變黑」(空白畫面)。

螢幕截圖 2018-06-22 13.51.12


▼開始簡報。

螢幕截圖 2018-06-22 13.54.52


▼簡報畫面變黑(空白畫面)。

螢幕截圖 2018-06-22 13.55.00


▼R800(綠光)和R500(紅光)的比較,很明顯綠光指示點比較大顆也比較亮。

螢幕截圖 2018-06-22 13.56.22螢幕截圖 2018-06-22 13.56.11

***

結論

Teddy覺得R500算是Spotlight的陽春閹割版,留下藍芽連線功能、相似的按鈕設計以及軟體支援自訂按鈕,拔掉看起來比較高級的外型、內建鋰電池充電功能以及酷炫(但不實用?!)的軟體聚光燈與局部放大功能。

優點:

  • 支援藍芽與USB接收器連線
  • 重量輕
  • 外型相對它牌而言算比較好看
  • 價格適中
  • 可透過軟體自訂按鈕功能與計時器計時

缺點:

  • 紅光雷射指示效果沒有綠光好
  • 沒有支援內建鋰電池
  • 垂直按鈕設計上下兩顆按鈕距離太遠,沒有R800那麼好按。


在此呼籲羅技簡報器的產品經理或Product Owner,可以給Teddy一個支援「藍芽連線與內建鋰電池的 R800 2.0,或是「實體綠光雷射的Spotlight 2.0」嗎?拜託了…Orz

***

友藏內心獨白:不知道電池電量可以使用用多久?

Clean Architecture精選參考範例

June 22 10:01~11:14

螢幕截圖 2018-06-22 11.08.47

這學期Teddy在北科大資工所兼任軟體架構課程,轉眼下禮拜就要學期結束。Teddy在網路上找了幾個外國鄉民實作的Clean Architecture程式範例,請學生當作期末報告。聽完學生報告,今天選了四個相對簡單易懂又可以反應Clean Architecture精神的範例推薦給鄉民們參考。

***

範例介紹

範例1:Real Life Clean Architecture

範例2:A complete idiot’s guide to Clean

範例3:A Clean Architecture in .Net

範例4:Architecting Android...The clean way?

***

學習重點

在觀看範例程式時,可留意以下幾個重點:

  • 專案結構:一個專案還是多個專案?如果是多個專案,分了那些專案,為什麼?專案之間的相依性為何?

  • 有哪些Entity物件?

  • 如何實作Use Case雙向介面?Use Case的Input與Output介面以及資料結構如何定義?由誰實作?

  • Use Case是否採用Command方式實作?

  • 如何處理物件跨層的問題?

  • Interface Adapter這層有哪些物件?如何跟 Use Case溝通?

  • 是否如《Clean Architecture》書中所示套用MVP?

  • 是否有使用View Model?

  • 範例是否遵循dependency rule?

  • 是否有外層(low level)物件跨層參考內層(high level)的物件?例如 controller直接參考entity。

  • 如何實作Repository?

  • 如何實作View?

***

結論

Clean Architecture》這本書讀起來不難,但有很多實作細節需要注意,如果自己不動手做過一次不容易發現箇中奇妙之處。一邊自己動手練習,同時參考別人的範例,學習效果可收加倍之效。

***

友藏內心獨白:實作方式有很多種。

2018年6月1日 星期五

幫Macbook Pro 15” Late 2016尋找外出電源轉接器(2):InnergiePowerGear 60C

June 01 10:54~12:16

螢幕截圖 2018-06-01 11.26.41

▲開箱貓


前情提要

2017年7月Teddy買了Innergie PowerGear 45瓦 USB-C筆電充電器用來取代MacBook Pro 15” Late 2016的87瓦原廠白豆腐(請參考〈幫Macbook Pro 15” Late 2016尋找外出電源轉接器〉),最後的結論是:

  • Apple原廠的87瓦電源轉接器重362公克。
  • Innergie PowerGear 45瓦電源轉接器重185~249公克。
  • 兩者重量相差113~187公克。

後來Teddy出門就只攜帶Innergie PowerGear 45,減輕一些背包重量。

***

持續改善

前陣子在網路上看到Innergie出了一款新的充電器Innergie PowerGear™ 60C,不但具備60 瓦的輸出功率,重量還只有140公克,一上市之後造成搶購熱潮,各大通路都缺貨。

螢幕截圖 2018-06-01 11.11.23


等了一陣子,前兩天剛好看到又有貨了,價錢一樣但「紐頓e世界」有贈送一隻便宜的滑鼠,就跟它買了。

螢幕截圖 2018-06-01 11.18.40


▼開箱照,充電器與贈品滑鼠。

螢幕截圖 2018-06-01 11.21.18


▼打開包裝,看到小巧的充電器本體,一條1.5公尺的USB-C連接線,一本說明書。

螢幕截圖 2018-06-01 12.14.56


▼先量一下體重,充電器加電源線共重140公克

螢幕截圖 2018-06-01 11.29.29


▼充電器83公克,長寬高各是3公分、3公分、6公分

螢幕截圖 2018-06-01 11.30.51


▼電源線58公克。

螢幕截圖 2018-06-01 11.31.02

***

上場實戰

▼把充電器接上延長線。

螢幕截圖 2018-06-01 11.34.18


▼先試充一下HTC U11。

螢幕截圖 2018-06-01 11.33.56


▼沒問題,可以對手機充電。

螢幕截圖 2018-06-01 11.37.47



▼拔掉照片右方原本MacBook Pro的充電線,改用Innergie PowerGear 60C。

螢幕截圖 2018-06-01 11.39.08


▼當然也是可以充電。

螢幕截圖 2018-06-01 10.36.29


▼新舊同學互相比較。

螢幕截圖 2018-06-01 11.47.43


▼Innergie PowerGear 60C的充電器體積的確是非常小巧。

螢幕截圖 2018-06-01 11.47.54

***

結論

花了2490元把筆電充電器的重量由原本的185~249公克減為140公克,減少了45~109公克。除了重量減輕,體積也變小了很多,輸出的瓦數又多了15瓦,雖然Innergie PowerGear 60C的單價貴了一點但也值得了。


▼以下是Teddy出門上課所需攜帶的MacBook Pro筆電配件:

  • USB-C轉VGA + USB-A。
  • USB-C轉HDMI + USB-A(因為不知道客戶家的投影機是否有支援VGA還是HDMI輸出,所以兩條轉接器都要帶)。
  • Innergie PowerGear 60C。
  • 羅技簡報筆。這一隻很好用,不用去買最新的羅技 Spotlight,Teddy也有一隻,覺得又貴又難用。
  • USB-C轉USB-A轉接線(白色)。
  • USB-A轉USB-A mini(要幫以前的手機充電)。
  • USB-A mini 轉 USB-C(幫新的手機充電)。

螢幕截圖 2018-06-01 11.56.31


▼配件加起來重達372公克。

螢幕截圖 2018-06-01 12.06.15


真的是有夠麻煩的,Teddy對MacBook Pro最不滿意的四點:

  • 給我4個 USB-C我用不到啊那麼多啊,只需要2個USB-C,保留HDMI和一個USB-A那該有多好。
  • 新式蝴蝶鍵盤有夠難打。
  • 記憶體最高只有16G,希望可以支援到32G。
  • 電池續航力。


▼還好後來找到一個小包包可以把這些配件全部裝起來,要拿取配件也很方便。

螢幕截圖 2018-06-01 12.07.57

***

友藏內心獨白:希望部要有第3三集,否則又要花錢了。

2018年3月19日 星期一

為什麼要寫自動化測試?

March 19 22:00~22:40

螢幕截圖 2018-03-19 22.04.10


問對問題很重要

最近兩個周日到台中上「單元測試這樣學就會了實作班」企業內訓,有學員問到:「如果工程師不寫測試怎麼辦?」這是一個經常被問到的問題,Teddy想從另一個角度來思考這個問題:「為什麼要寫自動化測試?

Teddy曾經聽過一種說法:「公司不是花錢請你來寫測試,是請你來解決問題。」言下之意就是寫自動化測試並不重要,寫程式解決問題才重要。某種角度來看,這樣說也沒錯。但如果順著這個邏輯推演下去,這句話是不是也可以改成:「公司不是花錢請你來寫程式,是請你來解決問題的。」所以開發人員也不用寫程式了,整天想著怎麼解決問題就好了?這樣聽起來好像有點怪怪的。

除非你是老闆的兒女或親戚,否則公司當然是花錢請員工來解決某種類型的問題。所以Teddy覺得這句話應該這樣看:「公司是花錢請你來解決問題,如果寫程式不寫測試可以解決問題,那就不寫測試。如果寫測試可以解決問題,那就寫測試。如果什麼都不做可以解決問題,那就每天裝忙就好」。

所以現在問題變成:「自動化測試可以解決什麼問題?

***

測試的兩種價值

螢幕截圖 2018-03-19 22.17.42

自動化測試提供公司與開發團隊兩種價值:

  1. 確保系統品質(出貨前系統沒有明顯的bug)
  2. 讓軟體變軟(團隊不懼怕修改系統並加速產品上市時間)

一般人,尤其是沒有開發經驗的管理階層或是涉世未深的開發人員,很可能只看到自動化測試的第一種價值。因此,在時程很 趕的時候,測試就變成可犧牲對象。就好像以前,為了聯考音樂課、體育課、美術課這些「聯考不考」的課程都可以被借去上國文、英文、數學一樣。反正退一萬步想,還是可以在出貨之後「請客戶幫我們測啊」。

因此測試變成可有可無,或是為了趕上時程而應該也可以被拿來省略的一道工序。

***

真正的專家知道,自動化測試的第2個價值才是改變團隊與產品的根本,也是公司競爭力很重要的一環。如果你的產品寫好之後不需要修改與維護,大可不需要自動化測試。例如,用完即丟的活動性軟體、接外包專案寫好後丟給客戶自己維護的系統、注定沒人用的系統,或是開發完之後你就準備離職的那種系統。

如果你的系統會被長期使用,而且很可能需要修改,省略測試所「賺到」的時間,很快就會「還回去」。正所謂「出來混,總有一天是要還的」。用比較正式的說法,累積技術債的利息已經太高,高到還不起的程度。

***

結論

在《Clean Architecture》書中,用「龜兔賽跑」的故事來說明「一開始看起來很快不一定最後是贏家」的道理。敏捷開發強調團隊需要有穩定的開發步調,而自動化測試就是一種讓團隊保持穩定開發步調的方式。

公司不是花錢請你(程式設計師)來寫測試,是花錢請你來解決問題,完全正確。因為你是專業人士,所以你知道什麼時候寫測試可以幫助公司解決問題,什麼時候欠點技術債可以獲得更好的投資報酬率。

***

友藏內心獨白:炒短線與長期投資的操作手法一定不同。

2018年3月15日 星期四

Clean Architecture(2):Port and Adapter Architecture

March 15 18:56~19:12;21:01~21:40

螢幕截圖 2018-03-15 18.58.07


一個架構各自表述?

今天在北科上軟體架構講到Port and Adapter Architecture(接口與轉接器架構),這個架構又稱為Hexagonal Architecture(六角形架構),是Clean Architecture的核心。關於該架構的介紹可以參考Alistair Cockburn寫的〈Hexagonal architecture〉。

上課前一周請同學先閱讀〈Hexagonal Architecture Is Powerful〉這篇文章,有同學發問:「為什麼有些網路上的文章把Port畫在六角形外面,有些則是把Adapter畫在外面?」(請參考下圖)

▼圖1:Port and Adapter的兩種不同畫法。

螢幕截圖 2018-03-15 17.39.22

這難道是一個架構各自表述?

***

畫圖的角度不同

參考圖2,不同的文章從不同的角度來畫Port & Adapter,畫出來的圖自然不同。如果是從客戶端的角度來看整個系統架構,客戶端先接觸到Port,然後Adapter再把客戶端傳來的資料轉成函數呼叫,執行Use Case所提供的功能。

▼圖2:從不同角度來看Port and Adapter

螢幕截圖 2018-03-15 17.41.18


如果是從Use Case的角度來看架構,則Use Case透過Port與外界溝通,當傳輸資料時,先把資料傳到Output Port (定義在Use Case中的Interface),然後Adapter實作這個Interface,再把資料轉給客戶端。接收資料時,客戶端透過Adapter把資料轉成Port所能接受的格式,然後傳給Use Case。

附帶說明,Adapter與通常Use Case執行於同一個記憶空間(屬於同一個Process、同一個Runtime Environment或同一個虛擬機器),轉接客戶端與Use Case之間的互動。

***

摻在一起做成撒尿牛丸啊

也有人把架構畫成圖3的樣子,感覺起來有點圖1左、右兩圖的合體,但清楚標示Port與Adapter的相對位置,應該是有比較清楚一些。

▼圖3:Port在最外層,Adapter介於Port與Use Case(圖中的Mediation)之間。

螢幕截圖 2018-03-15 17.41.54

鄉民們可以參考看看各種不同的畫法,以後看資料的時候也許比較不會搞混。

***

結論

嚴格來講,在《Clean Architecture》裡面,每跨一個階層邊界 (boundary)就會產生一組Input Port與Output Port,也就是說整個系統中,不同的邊界都有個別的Port and Adapter。這也是Port and Adapter的特色:「體架構可以透過好多組Port and Adapter 一直不斷地串接下去」。

類似下圖的概念。MacBook Pro的Thunderbolt 3的Port,配上HyperDrive這款Adapter,提供了好幾種不同的Port。而這些Port,又可以透過其他Adapter,繼續轉接下去。例如,HDMI轉VGA或USB Type-A轉乙太網路。


▼畫面節錄自https://goo.gl/xBU3zN

螢幕截圖 2018-03-15 18.09.17

***

友藏內心獨白:轉接器越來越多,越來越貴。

2018年3月1日 星期四

Clean Architecture(1):軟體架構的定義與目的

March 01 23:01~23:58

螢幕截圖 2018-03-01 23.57.25

▲佩納宮

定義

這學期開始在北科教軟體架構,使用《Clean Architecture》當作教科書,這一系列文章節錄Teddy認為的重點介紹給鄉民。

要談軟體架構,首先就要先知道軟體架構的定義。很多組織都有「架構」,例如公司組織架構、學校組織架構、政府組織架構,這些都是一般人類可以理解的架構。從這些架構著手,可以類推軟體架構的定義。

以中型公司組織架構為例,有董事會、董事長、董事會、總經理、處室、組等,以及各部門裡面的員工。由組織架構圖可以看出,所有的架構一定有三個東西:

  • 構成組織的單元:也就是不同職能的員工,在Clean Architecture中則稱為元件(component)。
  • 人員的安排:階層式、扁平式、矩陣式,component team還是feature team。在Clean Architecture中稱為元件的排列方式(arrangement)。
  • 人員溝通的方式:直接溝通、透過部門主管或PM與其他部門或外部客戶與廠商溝通、禁止溝通、聖上垂詢才可開口等。在Clean Architecture中稱為(communicate)。

Clean Architecture》的原文如下:

  • The architecture of a software is the shape given to that system by those who build it.
  • The form of that shape is in the division of the system into components, the arrangement of those components, and the ways in which those components communicate with each other.

軟體架構的定義很多,這可以算是Teddy看過最簡潔、清楚又實用的定義。

***

形狀與功能基本上無關

既然軟體架構是建構軟體的人所賦予它的形狀,那麼這個形狀的目的是什麼?假設你要蓋一個美術館,你會給這個美術館什麼形狀(外觀)?不少人可能聽過「Form follows Function」這個說法,形狀會跟隨著功能而改變,換句話說,軟體架構的形狀應該也會跟著功能(use case或user story)而改變。但實際在軟體架構領域中,一種廣為被接受的說法則是架構基本上與功能無關。實際上在真實世界中也是如此,下圖是用Google搜尋圖片下「美術館」關鍵字所找到的四個美術館,達到同樣的功能,但外型卻各異。


螢幕截圖 2018-03-01 23.36.23


那形狀的目的是什麼?依據《Clean Architecture》的說法,形狀的目的是為了幫助:

  • 開發(development)
  • 佈署(deployment)
  • 維運(operation)
  • 維護(maintenance )

換句話說,決定軟體架構的因素,主要是考量如何有助於軟體開發、佈署、上線營運以及日後的維護與功能擴充。

總的來說,軟體架構的終極目標可以簡化成以下兩點:

  • 最小化軟體生命周期的總成本
  • 最大化程式設計師的生產力

***

好的架構要反應功能

最後一個重要的觀念就是雖然架構的外觀與功能基本無關,但好的架構本身卻需要能夠反應系統的功能。《Clean Architecture》有個例子,你看到住宅的架構圖(平面圖),你會知道這個建築的用途是住宅,你看到圖書館的架構圖,你會知道這是一個圖書館。

回到軟體本身,試想一個Web購物網站應用系統,當開發人員打開程式,看到的是

tw.teddysoft.web

tw.teddysoft.controller

tw.teddysoft.domain

tw.teddysoft.database

類似這樣的架構組織關係,還是可以看出來系統有顯示產品列表、加入購物車、結帳、付款、選擇運送方式、追蹤訂單等功能?

為什麼好的架構要反應系統功能?因為這樣才可以協助開發、佈署、維運與維護。

***

友藏內心獨白:架構形狀與功能無關但架構內在要反應出系統功能。

2018年2月28日 星期三

軟體架構課程的準備

Feb. 28 23:24~23:59

螢幕截圖 2018-02-28 23.56.55


今天是2月最後一天,這整個月一篇部落格文章都沒寫,實在是有點不好意思。不過Teddy也沒閒著,因為這學期在北科大資工所兼任一門新的「軟體架構」課程,所以這幾個月花了大部分的時間與腦力在準備新課程。看了十幾本軟體架構的書,好不容易決定使用使用《Clean Architecture》當作教科書,接著又花時間用力地把書本內容看懂、吸收,想辦法用簡單易懂的方式講給學生聽。

這門課打算用一個小專案來反映Clean Architecture,光是專案要做什麼也想了一陣子。題目不能太大,因為這門課的重點不是coding,不需要也不應該花太多時間在撰寫過於複雜的軟體功能。但專案也不能太小,否則就無法表達Clean Architecture的Entity、Use Case、Controller、Gateway、Presenter以及串接Database、Web、UI等外部系統的架構。

想來想去想到以前研究過的一個開放原始碼監控軟體:Nagios,這個軟體有詳細的說明文件,Domain Model(領域模型)也很清楚,因此學生只需要專注在如何從軟體架構的角度,開發一個微小版的Nagios,然後把它的軟體架構採用Clean Architecture即可。


▼超簡化版的Nagios領域模型。

螢幕截圖 2018-02-28 19.47.31


***

Teddy會採用迭代與增量的方法,讓學生分組逐一把Clean Architecture的每個階層(Layer)都實作過,這樣子會比較有感覺,也不容易忘記,日後也可以直接在新專案中使用此架構。

為了驗證這個方法可行,這幾天Teddy都在寫程式,進度完成了Entity、Use Case、Controller、Gateway,剩下Presenter還沒接上去。俗話說,魔鬼藏在細節中,《Clean Architecture》這本書,光是用看的,就可以學到很多實務上非常有用的觀念。自己實作一次,則可以讓觀念變成實際解決問題的能力。


▼Teddy目前的專案進度

螢幕截圖 2018-02-28 23.52.00


在實作範例的過程中,發現之前研究的Domain-Driven Design(DDD)也可以與Clean Architecture相輔相成,不過DDD本身有點複雜,Teddy還要花點時間融合這兩者,等過一陣子弄得比較清楚之後再跟鄉民們報告。

活到這把年紀,要偷懶也沒人會罵你,靠教新的課程來督促自己重新學習也是挺好的一件事。


***

友藏內心獨白:突破關卡之後還滿有趣的說。