2017 MacBook Pro without TouchBar 敗家心得

在 2017 MacBook Pro 之前我用的是 2015 MacBook Pro Retina,當時因為更早的 2012 MacBook Pro 上班時忽然無法開機整台烙賽了,只好迅速到優仕拿了一台有現貨的 8G Ram、512G 硬碟版本。

當時因為工作的型態主要會在 Terminal 裡連到 Server 上作業,所以記憶體 8G 就夠了。但隨著時間過去,我在公司的工作型態從 System Admin 轉移成了 Developer 之後,8G 的記憶體要開一大堆有的沒的開發工具、以及本機的 docker 測試環境實在太勉強。於是在 2017 的 MacBook Pro 發表之後,就一直等待台灣的上市,趁勢把工作機更新成 16G 的機種。

在上市之前我花了很多時間在考慮要買沒有 TouchBar 還是 TouchBar 版本的,我自己考慮的點有幾個:

無 TouchBar 版本:

  • 有實體 esc 鍵
  • 有實體 Function Key
  • 便宜
  • 雖然 CPU 時脈比較低,但 GeekBench 分數比較高

有 TouchBar 版本:

  • 潮(有新東西可以玩)
  • 有 TouchID 指紋解鎖
  • 有四個 USB type C

在各種考慮後,最後我還是在台灣官網第一天開賣就買了沒有 TouchBar 的版本。接下來就來說說用了這幾天的感受。

鍵盤

這次的鍵盤有「英文」可以選,印象中 2016 版本只有「拼音鍵盤」,雖然看起來也是只有英文,但是和同事的 2016 Macbook Pro 比較起來,發現「拼音鍵盤」的 caps lock 上面印的是「中/英」,而不是 caps lock,稍微影響爽度。而 2017 直接可以在官網指定全英文鍵盤。

在使用上,新的鍵盤雖然按鍵行程變的比較短,但這個改變其實是最容易習慣的。打個幾天甚至還變的比較喜歡新的手感了。

不過新鍵盤對我來說討厭的是右邊方向鍵的上/下變的很小,coding 的時候盲打很容易按錯。

喇叭

我平常都會戴耳機,電腦沒有接耳機的時候都會靜音。但意外發現 2017 新設計的喇叭(其實 2016 版本應該就是採用這樣的設計),發出來的聲音比以前好太多了。

螢幕

Retina Display 物理上的實際解析度是一樣的,但桌面看到的預設解析度變了,從原本的 1280×800 變成 1440×900。最大的感覺就是桌面變大、可以看到的東西變多了。

USB type C

我原本的 MacBook Pro 2015 有兩個 DisplayPort,我工作時也外接了兩台 Dell U2414H,加上 MacBook Pro 自己的螢幕,平常都是三螢幕在作業的。2017 MacBook Pro 把連接埠都拔掉剩下兩個 USB type C 之後,我如果要繼續用三螢幕作業,最簡單且踩到地雷機率最低的方法就是買兩個 USB-C Digital AV 多埠轉接器,直接就噴掉 NT. 4380…

雖然有些副廠的轉接器可以用,但是有看到一些災情是副廠轉接器會干擾 2.4GHz wifi 訊號的…

然後因為我需要接兩個轉接器,所以變壓器就得接在轉接器的 USB type C 上,弄得一大串看起來真的很智障…

風扇

和我前一台機器相比,2017 MacBook Pro 不知道為什麼風扇起飛的機率變頻繁了,感覺機器也有比較熱。不過我是認為外部機殼發熱表示內部在散熱,所以不太在意,只是手汗會比較討厭。

TrackPad

變大的 TrackPad 的確會在沒注意的時候不小心壓到,導致打字時會出現一些意料之外的靈異現象。不過對我來說發生的頻率沒有太高。

變壓器

新的變壓器因為把原本整線用的耳朵拿掉了,所以變成那條 USB type C 線要一大把的收在包包裡,雖然可以用魔鬼氈束起來,但是線本身的材質和以前也不一樣,變的比較硬,所以用束的也不是很方便…

另外就是 MagSafe 2 這麼好用的東西被拿掉了真的很智障…

結語

雖然難免有些吐嘈點,但整體用起來我覺得 2017 MacBook Pro without TouchBar 還是一台不錯的機器,但是以目前 Apple 把 TouchBar 版本當作主打的情況下,也不知道沒有 TouchBar 的版本還能撐多久。我想總有一天還是得要面對 TouchBar 的吧。

用 gitlab-ci 自動測試 django 專案

隨著手上的 django 專案越來越大,就會遇到改了 A 功能以後 B 功能爛掉的情況。這時候測試的重要性就顯露出來了。

雖然 django 自己有 Unit Test 功能,但是要每個人在 commit 前都手動跑一次測試有點太勉強,總是可能會有忘記測試,結果 commit 爛掉的 code 上去的機會。所以把測試的工作丟給 gitlab-ci,讓每次 push 的時候 gitlab 都能自動跑 django 的 Unit test,並把測試結果吐到 Slack 上面會是比較方便的作法。

要使用 gitlab-ci 自動測試,需要完成以下步驟:

  • 編寫 django 的 Unit test
  • 安裝/註冊一台或多台 gitlab-ci-runner,用來執行測試
  • 編輯專案根目錄的 .gitlab-ci.yml 設定檔

編寫 django 的 Unit test

可參考 django 關於測試的文件

安裝/註冊 gitlab-ci-runner

  1. 先到 gitlab 專案頁面,點選右上角的齒輪圖示,選取「Runners」。會在這個頁面看到 gitlab 提供給 runner 註冊的 URL 以及 token
  2. 我用來跑 runner 的機器是 Ubuntu,可參考這份文件安裝 gitlab-ci-runner
  3. 裝好後執行 gitlab-ci-runner,會提示您輸入剛剛看到的 URL 和 token
  4. 然後根據您需要設定其他項目,在這邊我選用 docker 環境來執行測試。gitlab-ci 會在 runner 上跑一個 docker 環境,把您的 django 專案丟到這個環境內測試。所以也會需要在 runner 上安裝好 docker。

安裝/註冊成功後,會在 gitlab 的 Runners 頁面看到剛剛註冊的 runner:

2017-05-18 下午4.57.20
設定好的 gitlab-ci-runner 已註冊進 gitlab

編輯 .gitlab-ci.yml

再來編輯 .gitlab-ci.yml 設定檔,這個設定檔定義了 gitlab-ci 要幫你做什麼,範例如下:

# 使用 python 3.4 的 docker image 來建立 docker 環境
image: python:3.4

# 定義 unit test
unit_test:
    script:
        # 執行 ./shell/install.sh 設定系統環境
        - sh ./shell/install.sh
        # 指定 django 設定檔,並執行 django unit test
        - export DJANGO_SETTINGS_MODULE=official_web.settings.test && python3 manage.py test -k
    when: on_success

./shell/install.sh 的內容如下,我在這個檔案定義了 runner 在啟動 docker 之後、執行 django unit test 之前需要做些什麼:

#!/usr/bin/env bash
echo "********************************************"
echo "***************** Install ******************"
echo "********************************************"
# 先更新系統
apt-get -y update

echo "********************************************"
echo "************** Run apt-get *****************"
echo "********************************************"
# 用 apt-get 安裝必要的套件
apt-get -y install ca-certificates python3-dev libssl-dev netcat libmysqlclient-dev python3-pip mysql-client

echo "********************************************"
echo "************* Run pip install **************"
echo "********************************************"
# 根據專案目錄下的 requirements.txt 安裝 python 套件
pip install -r requirements.txt

這樣設定好之後,push 上 gitlab 就會在專案的「Pipelines」→「Builds」看到測試的狀況,如果測試成功就會在這個 Build 及 Pipeline 看到 passed 的標誌:

如果另外還有在 gitlab 設定和 Slack 的整合,Build 的結果也會一起吐到 Slack 上面。

在 docker 中使用 Elasticsearch 作為 django 的 search backend

目前手上的專案用了 django 作為網站的 Framework,而為了確保所有開發人員能夠在自己的開發機上用相同的環境進行開發,所以我們把整個 django 專案用 docker-compose 包裝成容器。

且為了未來專案正式上線時,可以放在 AWS 上,並盡量使用 AWS 的 managed service,所以選擇了 Elasticsearch 來作為 search backend。

這篇文章是把 Elasticsearch 加入 docker-compose 中的 django 專案的筆記。

閱讀全文

新同文堂無法在 Firefox 使用後的簡繁轉換方案

2017-04-26: 新同文堂新版 release 了,這個版本在 Firefox 53.0 上使用沒有問題,所以就不再需要使用 workaround 了

新同文堂這個簡繁轉換套件,在開啟了 e10s 之後的 Firefox 中無法使用的問題困擾我有一陣子了。現在似乎也從附加元件中下架了。在這之後一直沒有找到順手的替代方案。今天稍微拜了一下 Google 才發現這個走 Greasemonkey 的替代方案。

  1. 如果 Firefox 沒有安裝 Greasemonkey 套件的話,請先到這裡安裝
  2. 安裝簡繁自由切換這個 Greasemonkey script

以後如果再遇到簡體中文網頁,就會自動轉換成正體中文。

數位機上盒奇怪的 UI/UX 設計

其實我不是 UI/UX 專家,不過因為家裡同時裝了中華電信 MOD 以及台灣大寬頻 CATV 的數位機上盒,正好可以比較一下這兩家應該是國內最大的數位電視供應商。

剛搬到現在住的地方時,和光世代一起裝了中華電信 MOD。但是以我個人的收視習慣來說,沒有緯來日本台和國興衛視兩個頻道,直接降低了讓我打開電視的誘因。所以這段期間我比較常用 Apple TV 看 Netflix。這樣撐了兩年,因為還是想看上述兩個頻道,所以又裝了台灣大寬頻 CATV

台灣大寬頻 CATV 和以前第四台的收視習慣比較接近,第四台有的頻道它都有,MOD 有些國外的頻道像是 FX、Comedy Central 也都有。所以馬上就變成看電視的主力了。中華電信 MOD 幾乎就不會打開了。

但老是覺得用起來不太對,這才發現台灣大寬頻 CATV 的遙控器有個很奇怪的設定。

因為數位電視的時代有即時節目表這種東西,所以循序換頻道(1→2→3→4)習慣會到節目表裡面用遙控器十字鍵的上、下鍵來換(如下圖綠色區),而且 MOD 的節目表很好用,在一個畫面內可以看到大量的節目資訊,所以這樣使用不會有什麼問題。

但是台灣大寬頻 CATV 這樣用就糟糕了,因為他的節目表「很不好用」,所以轉台時會變成要馬直接按數字,要馬直接用遙控器上的「選台」來循序換頻道。

於是這樣就撞牆了,在節目表中,循序增加頻道是按十字鍵的「下」,但是如果要用「選台」鍵來換頻道,卻是按「選台」的「上」。要是依照習慣按了「下」,頻道會變成遞減(4→3→2→1)

在中華電信的 MOD 上,遙控器其實也是這樣的行為。但是因為他節目表好用,所以不自覺的我就不再使用遙控器「選台」這個鍵了,用節目表選台更方便啊,於是也就避開了這個問題。在台灣大寬頻這邊我就是一天到晚按錯,頻率高到覺得困擾了。

其實我希望台灣大寬頻 CATV 這邊能強化節目表啦,現在的節目表在各個區塊都留了大片的空白,又醜又浪費空間。如果能做到接近 MOD 的資訊量,用起來肯定更方便吧。