里斯本流水帳

在Automattic,每年固定會有兩次meetups:一次小組meetup,一次全公司的grand meetup。今年俺們Happiness Gardening team選在葡萄牙里斯本,除了看上風景優美加上消費低廉,也順便給大夥一個去歐洲的藉口。

本次meetup為期一週: 5/3 – 5/9,我提早在4/29搭上阿聯酋,於4/30到達,為的就是有幾天餘裕好好到處走走,幫太太remote shopping和買些伴手禮。每個國家總是有每個國家的眉眉角角,而且這次第一次去歐洲,總有些少見多怪。以下以流水帳的形式略記下記憶較深的點。

繼續閱讀 “里斯本流水帳"

關於Code review這檔事

說到code review這件事,相信這年頭凡是吃碼農這行飯的,多多少少已經成為工作的一部分了( 啥?貴公司沒在做這件事甚至反對這件事?塊陶啊~~~)

如果估狗『how to code review』、『code review guidelines』等關鍵字,很容易就可以找到許多不錯的參考文章,但很多都是超過十項的點檢表,我實在不擅長記憶這麼多項目,常常邊看邊忘,在腦內只留下了浪漫模糊的輪廓。

點檢表是非常有用的,特別是在初期對一個code base還很不熟悉的時候。例如咱家WordPress VIP code review guidelinesWordPress theme development checklist、這篇Kevin London的Code Review Best Practices也曾被轉載一陣。待對code base熟悉到一個程度以上後,記憶幾個好記的思考源作起點再從之延伸,對我來說比較容易掌握:

  1. 我了解整個patch / PR的目的嗎?
  2. 我知道該怎麼測試嗎?
  3. 每一行變更的意義我都完全了解嗎?
  4. 我們能做得更好嗎?

繼續閱讀 “關於Code review這檔事"

輕快的檔案巡覽組合:Unite + unite-git

demo-unite.gif

Github repo連結:

寫程式工具百百種,個人在工具選擇上較偏好用多種專做一件事的工具鏈而非一個整合一切的IDE。單一工具的功能愈單純愈輕量愈好,有點像是Unix的『do one thing and one thing well』原則。愈單純通常代表了高泛用性,讓我不管在哪個平台、開發哪種語言,都可以使用同一套工具;也因此,vim一直是我慣用的文字編輯器。我知道它有點像藍紋起司或納豆,喜歡的人看到就心臟蹦蹦跳,討厭的人聞到就吐得不能自己。

vim畢竟是文字編輯器,巡覽檔案並不是它的強項;它沒有『專案』的概念,原生不帶IDE必定會有的專案內檔案快查功能。我以前靠FuzzyFinder,但它真的很慢又不穩定,後來發現了Unite,簡直是發現新大陸。Unite + unite-git用起來就如上圖,我可以透過Unite的fuzzy search來快速巡覽git ls-files --cached的輸出,加上這個指令的輸出本身僅會列出目前所在工作目錄下的檔案,即使是像calypso這樣大型的專案也可輕鬆巡覽。

繼續閱讀 “輕快的檔案巡覽組合:Unite + unite-git"

以前曾聽到wp engine的co-founder Jason Cohen訪談:

『請問您當初為何要創業?』
『因為想要賺大錢啊,哈哈哈~』
『請問您是如何制定計畫,熬過創業前幾年的難關呢?』
『哪有什麼計畫?都沒錢,想辦法活下來啊,哈哈哈~』
『…您真是誠實啊』
『可是事情就只是這樣啊,哈哈哈~』

這真是我聽過最直白的創業家訪談了 ❤️

從WordPress REST API到WordPress Compatible

去年底WordPress 4.7熱鬧登場,在諸多熱辣辣的新功能中,要算將WP REST API納入核心使得人人有REST API用,影響最為深遠了。這代表往後任何人只要實作了與此API溝通的app,自動就有像天上星星那麼多的WordPress網站是你的潛在用戶;討厭php嗎?理論上你可以用任何你喜歡的toolchain實作這個API,那些透過此API與WordPress網站溝通的app,自然而然就能用在你的網站上。(不過後者恐怕還要等使用者認證、授權等API穩定後才較實際)

其實這不是什麼新概念,所謂interface as contract的概念早在web前就有了,令人想哼起經典老歌:Everything Old is New Again:

之所以放在WordPress上好像鑲金了,主要還是『像星星這麼多』這件事,造成它不容忽視的影響力。看看那個知名的content injection漏洞吧!甫一露出就十幾萬網站爆炸呢 ^.<

繼續閱讀 “從WordPress REST API到WordPress Compatible"

函式的兩易一難

正文開始前,分享一段個人非常喜歡的演講:Philip Wadler的『Propositions as Types』:

其中有一段很讚的話:

Computer Science. There are only two things wrong with it: Computer and Science.

身為CS出身的碼農真的是被婊到心坎裡 …

這句話背後的意義是,我們真正在做的事情,其實是資訊的構築與轉換,計算機或程式語言不過剛好是我們用來處理這些問題的工具,也因此他認為較適合的名稱其實是Informatics之類的東東。什麼意思呢?例如Int版的toString如果用Haskell type annotation來寫,大概是

toString :: Int -> String

也就是從一個結構為整數的資訊到一個結構為字串的資訊的轉換。sort則是

sort :: Ord a => [a] -> [a]

從[a]到[a]雖然沒有發生資訊的類型轉換,但輸出的[a]會是排序過的。這件事通常不會表現在type annotation上,但硬要幹的話應該也不是不行;例如定義一個type叫OrderedArray,上式就變成

sort :: Ord a => [a] -> OrderedArray a

雖然骨子裡我們做的是如此充滿數學與工程的事情,也許正因為語言扮演要角吧?寫過幾年程式後,大家都會發展出自己的風格,為了避免一個code base被搞得像超現實主義的大雜燴,於是有了各式各樣的coding standard來做基本規範。一個好的coding standard,個人覺得會像是制定一個基本框架,讓大家能在維持基本結構統一的情況下發揮創意,就好像七言絕句或詞牌一樣,與各種programming paradigm交叉組合下,漸漸地寫程式這樣聽起來如此geek的事情,本質上好像與更為貼近了。

可能因為個人偏好functional programming吧?我寫程式喜歡以函式為單位開始,而不管用哪個語言,我寫一個函式的原則是兩易一難易讀、易測、難誤用

繼續閱讀 “函式的兩易一難"