Prototype, Prototype, MVP … 誒?

“In writing, you must kill all your darlings.”― William Faulkner

Prototype一詞目前最常見的翻譯為『原型』,意指在實際製作成品之前,先用較簡易的方式將概念具現,以求能以低成本早期取得使用者回饋。這放在工業設計上,可能是從早期數百種草圖中挑出來幾個做成的紙板模型;從app UI/UX上,可能是用invisionproto.io製作的;遊戲上就更精彩了,因為沒有既定形式,各有各的獨門絕活。我個人最喜歡的例子是Journey:

比較一下完整的Trailer:

他們用簡單到不可置信的方式成功捕捉遊戲的核心機制,並有效進行調整。

我的經驗上,相較於這些許許多多的設計師,軟體工程師在prototype上的概念比較薄弱。或許是職業使然吧?設計師因為是擘劃藍圖的人而不是實際下地抹水泥的人,這類實務對他們不但是習以為常,更是實際跟工程師溝通時不可欠缺的工具。但工程師因為可以直接做出來,常常覺得prototype只是多了好幾次工,增加麻煩而已。

但我們還是需要prototype:prototype某項設計、prototype某項功能、prototype整個產品的最小集成看看感覺。因為實作成分多,結果就是常常看到有人說要給prototype,給出來的卻是MVP(minimum viable product,最小可行產品)。

『我們處在太空時代』

Clojure作者Rich Hickey的這段2012年的演講:The Value of Values,這陣子一直忍不住在腦海裡玩味,完整演講請右轉infoq: https://www.infoq.com/presentations/Value-Values,總長58分53秒,有空嗎?買包洋芋片配著看吧,絕對值回票價。

他首先定義何謂"place-oriented programming",到"value-oriented programming",最後推衍到為何我們可說是處在編程的太空時代,為何我們應該要建立全新的資訊系統來符合這個時代。

關於pull request這檔事

之前寫過關於code review這檔事,那反過來說,關於發pull request這檔事呢?(或者說發patch也適用,以下就姑且都說PR吧,節省篇幅愛地球。)

Automattic的夥伴們都挺愛挑毛病修細節的,PR來回修個幾週才進、打掉重寫,或是要拆細重發等等多不勝數,所以以下也算是個人在敝公司發PR的生存守則:

  1. 單一目的
  2. 測試方法清楚簡單
  3. 迭代大於完美

如果2023,只是如果 …

又到了新的一年了。自從加入中年俱樂部,我已經不太搞新年新希望那一套了。我不知道別人,起碼我自己以前寫過所有的新年新希望似乎從未達成;與其在年初寫下遠大的OKR用來在年末宣告個人今年經營不善,對我來說還是專注當下比較有意義。

不過,幻想未來會發生什麼事還是很有意思。

回想起來,2017年軟體界真是熱鬧又扼腕,全世界投入這麼多資源發展了這麼多新技術,主要都還只是拿來幫大企業吸金而已。舉例來說,深度學習是門令人讚嘆的技術,它從根本改變了人們對智能活動的認識,但目前最大的應用是做廣告。區塊鏈從根本改寫了信用,但目前最大的應用卻是到處灑加密貨幣吸金。

啊,咱市井小民只好期待那些大玩家玩夠後,就會開始出現些跟把錢從我們口袋中抽走比較無關的應用了。在那之前,就來好好幻想一下五年後可能會有些什麼事吧。

homebrew與tmux在OSX Sierra & High Sierra上的幾點雜症處理

自從OSX升到Sierra以來,我萬年沒更新的homebrew與tmux每天都在噴錯誤訊息給我,今天發現要寫一些tmux customizing script沒辦法運作,只好面對現實處理一下。以下幾點紀錄供未來參考用。

症頭:brew update => /usr/local is not writable.

解法:更新homebrew

如果跑brew doctor,homebrew會建議跑chown -R ${whoami} /usr/local,但我的情況是這招沒用,有查到一些討論串說這是Sierra開始有的bug。後來是直接安裝新版的homebrew解決。寫這篇文章的當下,官網提供的命令為:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

過程中會提示刪除一些東西,按照指示刪除後再跑一次brew update就行了。

症頭:[warn]: kq_init: detected broken kqueue; not using.: File exists

解法:更新tmux

tmux在2.3以前會有此症,更新就好囉!用homebrew的話就:

brew uninstall --force tmux
brew install --HEAD tmux

詳細請看tmux github issue 475

症頭:warning: reattach-to-user-namespace: unsupported new OS, trying as if it were 10.10

解法:更新reattach-to-user-namespace module

brew upgrade reattach-to-user-namespace。詳情請見:https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard/issues/52

症頭:invalid or unknown command: bind-key -t vi-copy

解法:用新的語法改寫

用tmux 2.2太久了,一升到2.4就碰到這個問題,所幸有人佛心來著寫了一篇簡單明瞭的轉換教學。以下步驟引用自該文:

  1. replace -t with -T
  2. replace vi- with -mode-vi
  3. prefix the command with send-keys -X

( 嗯…這麼一看,基本上都是長期懶得更新的問題啊… )

窮人Stack: github page + WordPress.com

前陣子因著自己的需要,做了這個『寶咖咖搜尋器』:

demo-bao.gif

如果你跟我一樣看房看了數年仍是無殼蝸牛,大概一眼就看懂這在做什麼了;如果看不懂,恭喜!你的人生還粉粉嫩嫩、閃閃動人。不過請放心,本篇跟這些黑漆抹烏的完全無關,只著墨在tech stack上。有興趣了解背後悶到出汗的故事者,可以參閱這篇ptt發布文

這個專案不大,但考量到平日龐大的工作量加上顧小孩,我能用的時間既零碎又少,能承受的維護成本非常低,所以最好不用自己host,也不需要我花太多力氣在null exception之類的蠢bug。最後的結論就是:

  • Backend: WordPress.com
  • Frontend host: Github page
  • Frontend development: elm

熱狗攤與專案管理

上圖為加拿大熱狗名店Japadog的hot & spicy,我是覺得不怎麼辣,倒是薯條鹹到我快中風;整家店就看我一個人拿著張餐巾在那邊邊帶著複雜的表情邊對薯條不知道磨蹭些什麼,想來畫面應該挺微妙的 …

好啦,言歸正傳,這篇的重點不是熱狗,我們來想想一個問題:

『如果要經營一個超棒的熱狗攤,最重要的要素是什麼?』

這個問題並非我原創,是我在Rapid Development一書中讀到的,作者Steve McConnell試圖用貼近生活的問題來帶領讀者思考專案開發中最核心的問題。

那答案是什麼呢?

你今天把產品弄壞了嗎?

昨天台灣時間凌晨1點前後,咱家WordPress.com分享至社群網路的功能Publicize全面炸裂長達4小時,只見論壇上哀鴻片野,眼看俺們公司就要被鄉民給放火燒掉 …

這件事詳細的原因不方便明說,就姑且說是某位夥伴不慎上了一個patch把整個功能弄壞吧。這段時間受害的用戶上萬,從system team到product team頃全力救災,最後仍有些損壞資料無法恢復。好像很嚴重吧?揪~竟這位夥伴事後受到怎樣慘絕人寰的處置呢?

關於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. 我們能做得更好嗎?

輕快的檔案巡覽組合: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這樣大型的專案也可輕鬆巡覽。