我現在只是「不用」Facebook 而不「反」Facebook 了

昨天跟同事聊到的話題,我的回應如標題。

大概是這樣的想法吧:

  • 貼技術文,很多友人看不懂,不想洗版。
  • 貼社運、政治文,很多「政治好髒」小確幸友人不想看,不想洗版。這點是在反課綱學運的林冠華自殺那時,湧到最高點。
  • 偶而同步發表 Instagram 照片讓友人知道我還活得像個「正常人」,大概也夠了。
  • 以前很討厭無名小站,主要是美感問題,但不可諱言它匯集了當時相當豐富、百花齊放的網民思想內容,就跟現在的 FB 一樣。雅虎奇摩關掉無名小站,至今還是讓我非常度爛,顯示這家公司根本不在意「內容」這件事。
  • 總結來說,無可諱言地,FB 某些作風至今還是很爛,爛到家,但是上面的社群與內容不應恨屋及屋。

面對新技術的心態

Drupal

使用 Drupal,不應該只是認為「別人都幫你寫好了模組、做了很漂亮的版型,只要抓下來拼湊、修改一下就可以交差了。」而是要學習到這個基於 hook 的 design pattern 要怎麼依樣畫葫蘆,在 Drupal core 上開發符合自己需求的程式,讓 Drupal 真正為自己所用。

不然,你做出來的網站就是會有很濃的拼裝車味道。

同時,也因為 Drupal 有自己的一套 architecture 與 design pattern,所以也不應該認為「反正只是 PHP。」言下之意好像 PHP 入門簡單、會的人多,隨隨便便都找得到人來開發。同款,不同師傅。

況且單看臺灣的話,真正寫得「好」的、精通 PHP 的開發者,事實上並不多。

當然啦,有人會說:「我只求能動、先求有不求好、能交差 60 分」,這種人基本上不是我寫這篇文想要鼓勵的對象,麻煩請關掉分頁,去享受你其他面向的快樂人生與成就,畢竟人各有志。

Rails

使用 Rails,也不應該被「10 倍速的快速開發網站魔法」之類的宣傳詞迷惑,而是要從中學得如何做出一個可維護的網站,包括透過 MVC 將系統元件分而治之、包括 DB schema versioning、包括從 ORM 學得 OOP 的基本精神與 metaprogramming 等,諸如此類的技術成長,自此就從「一隻程式通心粉式地把所有事情做完,之後再也看不懂這隻程式當初是在寫尛」的程度畢業,成為一個講究軟體工程、架構的進階開發者。

不然,其實你我也見過,很多去上了速成班的人,寫出來的 Rails 跟用 Raw PHP 差不多髒。這樣的「快速開發」只是製造用另一種語言寫出來的技術債而已。

順道一提,如果你在 Drupal 上的開發習慣、思維夠好夠清晰,來學習 Rails 基本上除了程式語言不同以外,不會有什麼障礙。

Docker

使用 Docker,也不應該把它當成是比較好用的 chroot 而已,而是要想說透過這樣的隔離,我可以更充分利用機器的運算資源,並透過 API 的呼叫,來操作容器裡頭包裝的程式元件,將思考的層次從「伺服器」轉化到「資源」。

此時你傳統「一個網站專案解決一切」的系統架構,為了 HA 與 scalability 就勢必要進行進一步的重構。

反之,如果你硬要把既有一把通抓架構的程式塞進 Docker 裡,搞了一堆有的沒的讓它跟在實體機、虛擬機做的事沒兩樣,其實還反而弄得更綁手綁腳,未蒙其利,先受其害,那麼拜託你不要去外面跟人宣傳說「我們也有用 Docker」。

TL; DR

其實我寫這篇只是想說,很多盲目追求技術的熱潮,並沒有搞懂本末終始核心精神,這樣營造出來的 ecosystem 其實只是在搞技術宗教崇拜,比誰的信眾多,其實是很不健康的一窩蜂,瘋潮一過,留不住多少人,對 IT 產業也就沒有什麼真正的助益。

昨晚看了 BS JAPAN 的「ものラボ」節目,介紹 Dyson 的創業故事,兼賣 Dyson 吸塵器

ものラボ,頭一次看到這樣「有誠意」的電視購物(?)節目,真的爆笑出來。

一開始以為是紀實介紹節目,看到 James Dyson 屢敗屢戰的創業歷程,試作了約 5,000 個 prototypes 才做出理想的作品,卻又幾經波折,方能找到願意生產的廠家。

就在感動於這樣的創業者、發明家精神的時候,節目旋即轉換為電視購物模式,賣起 Dyson DC35 來,感覺雖然有些突兀,卻又比一般的電視購物節目來得更有說服力。

BS 上頭的好節目真的不少,像「ものラボ」這樣的節目製作型態,對我而言又是一次啟發。觀眾不是不喜歡廣告與推銷,而是你的行銷之道夠不夠細膩。

寫 Dockerfile 的時候,過程當中應該關閉的資源、服務,一樣要如實關閉

這幾天 debug 的心得之一。

這例子是這樣的:在打包 Docker 容器中安裝 PostgreSQL,並在安裝後就立即啟動服務,做了一些初始化的設定,但是忘了要在設定完成後關掉它,於是就會造成某些資料庫相關的檔案沒有正常關檔。

在之後要用到 PG 時,伺服器雖然表面上正常啟動了,但是背景仍在執行因為之前沒有正常關閉服務而需要跑的復原工作,於是就出現 “psql: FATAL: the database system is starting up” 這個第一眼讀來有點丈二金剛摸不著頭腦的錯誤訊息,同時 PG 也不能正常對外服務,便會造成相關的操作失效。

執行 docker build 的時候,要記得每個步驟都是 run 完就由 docker 寫入差異部份至檔案系統,然後就結束了,這個步驟執行時跑起來的 process,在下一個步驟執行時,是不會留在記憶體待命的,這跟使用其他的 configuration management 軟體來做這類「無人值守」工作時,有很大的不同,務必要記住這點。

2015 回顧

  • 搬回宜蘭,揮別在台北租房子的日子,開始長途通勤。
  • 結婚,告別單身。
  • 離開信義區,回到南港區工作。
  • 頭一次出國,頭一次去日本,久久不能忘懷當地那種相較於台灣「不過正不足以矯枉」的龜毛做事方式。
  • 在 Modern Web 聽到很多場值回票價的演說。
  • 看到 Readmoo、想起カーリル,很感慨,對於閱讀社群的經營,別人能,為什麼我不能。
  • 因為之前在 development 方面長期拙於實戰,武功退化不少,到了丟辭呈的那段準備交接時間,拿起之前借同事看的 Erlang 書,反而因為腦袋空空,而很能吸收,不較之前認為「Erlang 是個天書語言、函數式語言不曉得在幹嘛」,可謂失之東隅,收之桑榆。
  • 對容器化技術、微服務架構,有了一定的認知。配合 Erlang 這樣的語言與平台設計,我覺得簡直是天造地設的組合。
  • 被前端技術的治絲益棼嚇著,根本搞不懂這些三不五時冒出來(然後隨即又死掉的)新工具是在幹嘛,於是決定專注在後端的發展。

裝了 BS 衛星碟與接收機

從八月寫了〈NHK World Premium 從台灣大寬頻類比頻道中消失〉說要去裝衛星碟之後,到本週一晚間才真的實踐,但是這中間其實做了很多功課,才讓整個安裝過程沒有遇到什麼麻煩。在本文就稍加整理心得。

安裝衛星碟的條件

BS 衛星 BSAT 3 大約在方位角 210 度、仰角 60 度左右的位置(這只是大略位置,之後會說明如何取得更精確的),如果估算想要安裝、可以安裝的位置望出去,有障礙物遮蔽,那麼就沒辦法安裝衛星碟了,因為衛星訊號只要稍微偏掉,就收不到,遑論還有遮蔽物在干擾。

針對這個問題,我找到最好的輔助工具,是 Satellite Director 這套 Android app,也是到目前為止我在 Play Store 上看到同類工具中做的最好的。利用它尋找 110.0E BSAT 3A,很容易藉由手機 GPS 與電子羅盤、相機鏡頭三者結合,去觀測衛星位置與目前所在地點中間是否有障礙物。

當然,運用這套 app 的前提,也就是手機的 GPS 與電子羅盤要夠精準。因為我考慮房間位置、衛星方位等因素,打算把衛星碟架在家裡後方,其實是個很尷尬、卻又不得不選擇這裡的地點,因為與對面人家中間僅有很小的視野可以看到天空,所以 GPS 常常要看天候、時間狀況才能取到 Satellite Director 判斷容許的 5m GPS 距離誤差。

至於電子羅盤,這是更難保證精準的感測器,我用過好幾隻 smart phone 和平板電腦,沒遇過一打開就「至少不要偏得太誇張」的,常常偏個 180 度、南方變北方是家常便飯,使用「繞 8 字形校正法」又很難保證確實校正了。這時,去準備一隻實體的指南(北)針做對照組還是必要的,不然像我這樣的安裝環境,很容易誤判可安裝或不可安裝衛星碟。

最後再到 Satellite Finder 網站,在地圖上輸入、找到自家位置,並指向 110E BSAT-3A | BSAT-3C | N-SAT-110 (SUPERBIRD-D),計算更精準的仰角 (Elevation)、方位角(Azimuth,有分別以磁北與真北為基準的兩個數值),記在紙上備用。

設備、材料、工具準備

確定地理環境可以安裝衛星碟後,我就開始張羅各種設備、材料、工具了。因為我打算 DIY,所以上網看過很多文章後,才把東西備齊。如果是找廠商來安裝,就不用這麼麻煩了,相對地就是要多準備一點預算在廠商師傅的工資上。

先列出我這次施工用到的全部東西,所列價格是台幣:

  • 前面提過的指南針,文具店購買,30 幾元。
  • 前面提過的 Satellite Director 軟體。
  • IO-DATA REC-ON(HVTR-BCTX3)接收機,請網拍從日本帶回,12, 000 元。我不需要藍光光碟錄放機能,一來燒錄片難找,二來我已經有 PS3 可以當 BD player,所以買了這款可用 USB HDD 或 NAS 錄影、還可以用 App 遠端收視的機種。
  • TOSHIBA BCA-453K / BCA-453AK 衛星碟,隨接收機加購,2,800 元。若要個別採購請一定要注意自己買的是含支架的 BCA-453AK 還是不含支架的 BCA-453K,我因為要架在鋁窗上,所以買的是前者。這組衛星碟已含 LNB(把衛星碟訊號「聚焦」起來接收的元件),所以不用再買 LNB 了。
  • 請廠商製作的兩條各 20m, 10m BS 衛星專用纜線,加上一條「過窗線」,580 元。雖然 BCA-453AK 就有附纜線,但是我要利用過窗線把纜線拉進房間,所以另外去請專業廠商製作纜線。請注意,這種纜線雖然長得跟有線電視用的很像,但是頻寬規格差很多,不能混用。
  • 配線槽,90 元。為了讓進房間的纜線好鋪設、不影響觀瞻。
  • 螺絲起子。
  • 延長線,為了就近接電視與接收機,確認衛星碟有無正確收到訊號。
  • 電視,慶幸這個時代是液晶電視當道,不用再扛傳統笨重的 CRT 電視了。

施工

DSC_1964
尋星(尋找衛星的簡稱)是整個施工過程中,最讓陌生新手感到畏懼的一項。但是若有基本的、國中生程度的幾何概念,其實很簡單。

首先是支架安裝,這裡一定要確認支架有 90 度垂直,利用簡單的鉛垂法就可以測定,如果支架這個基準點沒有垂直安裝好,那麼之後的衛星碟相對角度都會有誤差,反之,如果支架確實安裝好,那麼尋星會非常簡單。

再來是把碟盤與 LNB 裝好、纜線接上 LNB 預備,然後把碟盤裝上支架。螺絲要暫時鎖在「讓碟盤固定不會亂晃,卻還能維持左右轉動」的「假固定」緊度。碟盤暫時大概指向指南針的南方 (180 度)就好,因為從 180 漸漸調整右轉至 210 度左右其實沒什麼傷腦筋,但是若一開始就想調方位角卻不得法,反調得過頭,就會迷失在「不曉得該往左調還是往右調」的難題中。

所以應該先調整仰角,注意碟盤後的角度刻度,調整到盡可能與之前在 Satellite Finder 得到的數值一致。我的經驗是,若傻傻地沿用網上文章講的 60 度,則什麼訊號都收不到。因為一開始支架是確定垂直的,所以調整的仰角刻度也應該是可信的。

然後把纜線另一端接上接收機,接收機插入 B-CAS 卡、接上電視,再設定接收機要對天線(其實是 LNB)供電,進到接收機的天線設定畫面,觀察訊號強度。

此時以每隔 5~10 秒的步調,慢慢往右轉調整碟盤的方位角,直到找到衛星訊號、並定位到最大訊號強度為止。最後再鎖緊螺絲固定。

後續的拉線進房間,沒有什麼技術難度,就略去不多寫了。
DSC_1965 DSC_1966

BS 節目絕大部分都是高畫質的,除了一些電影頻道與 Animax 有時會播畫質較差的老片,高畫質節目看起來非常賞心悅目。不過試看期之後這些付費頻道也看不到了,變成黑畫面要你訂閱才能收看,除此之外幾個免費頻道,我下班、休假時偶爾看看也很滿足了。重點是我又能看到 NHK 了,雖然不是濃縮精華的 World Premium,但是很多節目 BS Premium 上也都有。

續談 OpsWorks + Docker 管理架構

Cookbooks 的規劃

對應 OpsWorks 的任務分支,分為以下幾個 cookbooks:

  • common
  • setup
  • configure
  • deploy
  • shutdown
  • service-pack

不要有類似 OpsWorks 的 nginxrails 這類獨樹一格的「專用」、「特用」cookbook,依以上基於動詞的 cookbook 來做事。

比如如果遇到要設定 nginx 某個獨特的項目,就是 setup::nginx_do_somethingconfigure::nginx_do_something,而不要自己搞一個 nginx::do_something

這樣做的好處就是管理起來簡單,一眼望過去知道這個 recipe「要做什麼事、對象是誰」,寫 recipe 時有明確分類可以遵循。

其中有幾點要注意:

  • common cookbook 是用在「支援、配合任一其他類 cookbook」的地方,而不是「萬用類」。開發初期如果不曉得某任務應該歸在哪類,可「暫時」放在這裡,一旦確定放在某特定類比較適當後,則應立即 refactoring 改放到該特定類。
  • service-pack cookbook 適合用在「單次任務」如元件安全更新、強制不使用 cache 重建 Docker images 的地方。
  • 因為 Docker 的特性,基本上不需要 undeploy 類的任務,退版其實就是切回到某個舊版本的 Docker image 開 container 出來而已。所以不規劃 undeploy cookbook。

Docker 的部署設計

理想上,應該是把 docker image 從 registry pull 回來後立即 docker run 就能動起來。

實務上,我們有些地方還是需要仰賴 stack, layers, nodes 的設定資訊,所以還是免不了要使用 Chef 的 template 命令幫我們生成設定檔與 Dockerfile,最後再疊加上一層,生成新的 image 後予以部署。

部署時特別要注意,像是 Rails 應用會產生 logs、Unicorn 也會產生 logs,這些 logs 是營運績效、問題診斷的重要資訊 ,我會盡可能在 container 內把這些 logs 放在同一個目錄下,再用 volume 對應到 host 某一目錄底下保存。這樣可以直接從 host 取得 logs,不用進到 container 內,方便很多,也利於 logrotate, fluentd 之類的工具操作這些 logs。

目前想到的是這些,以後若有想到再寫…。

NHK World Premium 從台灣大寬頻類比頻道中消失

今天凌晨,位在 CH95 的 NHK World Premium 突然斷訊,有幾秒的時間被調到 CH94,旋又消失,接著 CH95 換載 MTV 綜合台。

求證有裝數位有線電視機上盒的岳家,NHK World Premium 還在數位頻道裡。

親眼見證這段歷程,很有感觸,我在當下還抱著希望,以為像之前一樣只是被賣藥台排擠而換了頻道。重新掃描頻道掃了兩、三次,再按著遙控器一台接一台尋找,覺得這很像是國中時新買的自行車失竊,我茫然地在附近兜圈那樣。

我知道類比頻道頻率範圍有限、數位頻道(理論上)無限的道理,但是今天台灣大寬頻可以這樣獨斷決定一個類比頻道的去留,我相信同樣的事情,很有可能也會在數位頻道裡發生。

於是我(終於)決定去裝衛星碟。

真假 DevOps

今天談到一個話題:「不熟 OP 的 developer 如果缺少 OP 相關知識,那怎麼做好 DevOps?」

我覺得這是個假議題。

今天就是因為 developer 都認為 OP 會負責 deploy 到好、負責出來坦,所以開發時毫不考慮 OP 負荷,logs 也不看不管,這才是真正導致 DevOps 做不起來的原因,也就是我一直批評的「假 DevOps 之名,行傳統 OP 之實」。

而 developer 真的需要很強的 OP/sysadmin 知識嗎?不用,真的不用,developer 缺的是很強的 DRY 意識。

如果能時時設想「我做的這個東西,能不能在 10 分鐘內整套自動 setup run 起來?」那 developer 自然會去想「程式能不能通過測試?」、「設定、部署能不能簡單輕鬆?」這才是以 developer 這一側要實行 DevOps 該有的思維。

我親愛的網站案件客戶,您好

我自大學開始學習如何製作「帶有語意的網頁」、「樣式與本體分開處理的網頁」,早在 SEO(搜尋引擎最佳化)這個詞出現之前,便已瞭解「一個讓搜尋引擎覺得『好』的網頁,其結構應該是如何如何」的眉眉角角。

從碩士班開始,又學到 IA(資訊架構學),深知內容如何妥善編排,導覽動線該如何設計。

製作「帶有語意的網頁」、「樣式與本體分開處理的網頁」是讓機器(搜尋引擎、瀏覽器)高興。

妥善編排內容,設計良好的導覽動線,則是讓高興。

能夠兼顧「機器」與「人」的 Web 設計師在這市場上真的不多,許多從業者照本宣科跟著「專家」做 SEO,還不如我們這類圖資系出身的、一直被以為只能在圖書館櫃台處理借還書的人,動手調整一下網站架構,結果立即大不同。

您的網站,因為我的勸阻,沒花錢去買當初您不知聽了哪位「專家」說的關鍵字廣告,但是在搜尋引擎排名還是名列前茅,實不相瞞,就是我提供給您如上述的專業服務,正如貴寶號也提供專業服務給客戶那般。

您在意「效果」、「設計」、「美學」,是的,這些的確很重要,但並非一個網站的全部。當我向您表達我擅長的 Semantic Web, Information Architecture 如何幫助貴寶號的時候,希望請您不要認為那些不重要,而不當一回事,執意要做您認為「視覺效果好才是硬道理、壓倒一切」的網站,因為若忽略這些要素,您的網站只能吸睛,但不會好用,搜尋引擎也不愛來爬資料。

無論之後我們還是不是可以繼續合作,我衷心感謝您看完我這篇苦口婆心、肺腑之言,謝謝!