今年做了一件好玩的事情：我拿了幾首歌去付費的音樂平台上架了。其中一首就是這個去年八月寫的《每顆星球都在加速離去》。
Spotify
SoundCloud
每顆星球都在加速離去
Reply
Author Archives: zonble
PM 的成功之道
在軟體這個行業中，有一種職位叫做 PM。但雖然很多人的職稱都叫做 PM，但實際上的工作內容卻大不相同。
在這邊所講的，倒不是什麼專案經理（Project Manager）或產品經理（Product Manager）之分，就我所看到的，一個專案的從構想到計畫到規格到後面的時程控管，往往不會分給不同的人負責；也不是某種個人的人格特質，而是不同 PM 工作所追求的價值所在。在幾種不同的職場環境中，PM 所能夠追尋的成功目標大不相同，而大大決定了不同的工作方式/生存之道。
我們可以用兩個維度—公司的規模與公司的性質，一位 PM 的環境是在大公司還是小公司，是做專案還是在做產品/服務，區分出四種不同類型的 PM，分別是：全能型 PM、業務型 PM、企業家型 PM 與掠奪型 PM。不過，在這邊討論的 PM，要先排除掉遊戲產業，遊戲是另一個大不相同而且我不了解的世界。
| 專案型公司 | 產品/服務型公司 | |
|---|---|---|
| 小公司 | 全能型 PM | 企業家型 PM |
| 大公司 | 業務型 PM | 掠奪型 PM |
環太平洋
2013 年的《環太平洋》大概是我這輩子看過裡頭有最多糟糕物的電影。
因為你用來做 Code Sign 的 Certificate 是幾個月前產生的，所以你的 App 會 Crash
這篇 blog 就是我在 2015 年四月份台北 Cocoaheads 在台上講的事情。
在過年期間，我把去年 11 月時寫的捷運轉乘這個個人的小 iOS App 改了改，在年假結束的前幾天 submit 一個版本，結果，過了一週，被 reject。
蘋果的 reviewer 說，他們只要一安裝這個 App 的 binary，就會馬上 crash；可是在我自己的開發環境中，完全無法重現這個狀況，由於過完年公司的事情就一件一件接著來，所以也就擱在一邊不管了，我到今天才知道為什麼會 crash，而且理由還頂荒唐的。
這兩天我們把公司產品 code 裡頭的一條新功能的開發分支（講 feature branch 不知道會不會比較好懂）併回主線，然後讓主線的程式進入 Jenkins build，讓公司的 QA 部門做出貨前的測試。狀況很奇妙，原本的 App 也是跑得好好的，在支線開發的過程中，也跑得好好的，但是從 Jenkins 編出來的 build，只要一跑起來，就會 crash。
當秋葉原的女僕轉過頭來跟我說了一句話，我和我的小夥伴們都驚呆了
這是去年八月的事。之所以到了現在才敲鍵盤記下來，主要原因是，這個故事基本上算是人生當中的一段黑歷史，可是這個故事，又充滿啟發，每當你回想起來，就會在心頭泛起一陣陣漣漪。
去年八月參加了公司的員工旅遊，是五天的東京自由行。由於我自己沒有規劃行程，所以就跟著公司安排的室友—另外一位在這個業界也算是有相當名氣的工程師，平常不少人也將這類型的工程師喚做「大神」—一起行動。
這位大神級的同事一年可能會去個十幾趟東京聽演唱會，前兩天先走了他的既定行程，先去獺祭把什麼 Beyond 啦、二割三的吟釀還是大吟釀喝了一輪，又搭了 JR 去趟輕井澤，來趟一天的小鎮單車之旅，吃了燒肉，還在輕井澤的 Outlet 買了一盒星際大戰系列裡頭的 AT-AT 樂高回來。至於吃個什麼一蘭拉麵，也是免不了。而就算在電車上往返的時間，大神也沒有閒著，既然是在東京穿梭，那就順便在 Ingress 裡頭把看到的東京地標也都打了一輪。
第三天，沒什麼其他的規劃，由於剛好是週末，就在網路上聯絡了一位因為軟體開發社群認識，現在在東京工作的朋友，看看東京還有什麼好去處。中午先約在池袋，午餐據說是只有當地人才會知道的道地拉麵，走出來看到對面的百貨公司裡居然有個不錯的畫展，也就進去逛了一圈—像我們這麼有文藝氣息的一群工程師，怎麼有辦法抵抗《攻殼機動隊》原畫展這樣的文藝活動呢？
當我們從士郎正宗的原始漫畫設定，一路看到攻殼機動隊 Arise 的美術之後，又想不到行程了。
「走！去秋葉原。」大神提議。
「來東京這麼多次，還沒有去過女僕咖啡店，我們今天就去—解開成就！」
在 Swift 裡頭呼叫 CFArray
在寫 Swift 的時候遇到 CFArray 都得要花點時間想一下。雖然當你在使用 Swift 語言的時候，你會盡可能希望只呼叫到 Swift 與 Objective-C API，而不用碰到 Core Foundation 的 C API，可是呢，當你在做某些事情的時候，就還是得遇到這些東西。
在 Swift 裡頭處理 CFArray 之所以不好搞，第一個原因是，當某個 API 希望你傳入 CFArray 的時候，建立 CFArray 的方式跟你在 C/Objective-C code 裡頭差異很大，但似乎也沒有看到多少文件在說明這點。
另外當你從 C/Objective-C code 傳遞了一個 CFArray 到 Swift 裡頭的時候，裡頭可能會有兩種類型的東西：一種是可以 bridge 成 Objective-C 或是 Swift 的物件—通常是 Foundation 或是 Core Foundation 的物件；另外也可能是其他種類的 C 指標，可能是某種另外定義的 C Structure，而在這兩種不同的狀態下，要用不同的方式操作 CFArray。