#工廠妹萬歲

星期五晚，我喺風涼水冷的IT 公司office 中𡚒鬥。

我應承大家可以上架嘅新年貨品，仲未搞掂，
做新鮮即製貨品，要做到俾客人預先訂貨，
真係好難。

貨有限量，呢頭要訂新鮮材料，
嗰頭要排廠期做貨，
預埋車隊人手假日送貨取貨，
寫無數咁多嘅說明俾各相關單位，
最後一步，講俾IT知，
幾時幾日做貨，預先收預訂，
唔可以超賣，唔想有餘貨。。。

由客人到客服到貨倉到廠
到Chefs 到procument到backend account / admin，
全部等我將所有嘢hook 埋，
一齊起動，唔可以甩碌。。。

嘩，如果今次我搞得掂，我就壯大了，
香港正式出產多一個工廠妹/婆。。。

工廠妹萬歲，做廠長原來好難，
尤其在這艱難日子，
樣樣都要預到好盡。

搞咁長disclaimer，
即係咁，我又對你哋唔住，
做唔晒啲嘢😅😅
啲蘿蔔糕、芋頭糕、大煎堆、
鴨鵝盤菜，又可能要明日先有得訂嘞，
非常唔好意思。

星期五，自己做唔晒啲嘢，
又想IT男交功課，咁點做？
下午，我搬埋自己電腦同文件，
上去IT公司踎喺人哋office門口做嘢，
有嘢就敲門問。

IT男到7點就開晒交響樂，
唔知有無特別意思呢？
我扮唔知，我問佢哋幾點收工，
佢哋話公司有O’Chef Lab即食餸包，
OK 啦，陪我作戰到底，掂。

喂，我做嘢先，一陣如果悶悶哋，
10:30pm 開個live 傾吓偈吖，
我做人肉客服，
回答下啲新年食品問題 ，
又或者傾吓做網店expand 有咩嘢要注意 😅😅
答完再寫可能會頭腦清醒啲。

最近跟手機串接其中一支 API 的時候，小編在規格上設計了 request 必須帶一個 UUID 的值給 backend，以 Android 來說其實直接使用 UUID.randomUUID().toString() 就可以了，但 iOS 熱門的 FCUUID library 看起來好像給了一個錯誤的實作，而且大家好像常誤解了 UUID 的意思。為了這件事，昨天凌晨跟朋友弄了一個小時 Orz

---

一般大家常知道的 UUID 應該是像這樣 8909ea35-8b0e-4e1a-8ba3-9c0af47c77ca，由 8-4-4-4-12 及 16 進制的字元，共 36 個字元所組成的，Java 及一些 npm 的 library 也是如此實作。可是 iOS 的 FCUUID 卻是產生 8909ea358b0e4e1a8ba39c0af47c77ca，連續 32 個字元的字串

---

下面是對話內容，沒想到 UUID 的格式還有不一樣的 Orz

---

(I: ios, B: backend)

* I：你說的uuid有長度限制嗎？
* B：uuid 就是 36 chars
* I：format我不用管對吧，我只要送36個字元過去
* B：uuid 就 uuid
* I：你要well format的uuid，還是我給你一串36個字元的字串
* B：well format 的 uuid
* I：ok
* B：因為我就是講 uuid 啊 xddd
* I：這詞早就被亂用了
* B：怎說？
* I：很多人的uuid不是那個uuid阿，就一串unique的id，以前接過很多api，uuid就unique的id，他們就這樣叫，也沒人在管，uid??uuid??阿災，他們都這樣叫
* B：不夠嚴謹，這工程師不行吧

(半小時後)

* I：要不要dash呢？
* B：要，因為是 uuid
* I：我現在的uuid是用lib產生的
* B：昏
* I：uuidForSesion，這method聽起來是不是很完美，完全就是我們要的
* B：看起來是
* I：但他是32個char，沒4個dash
* B：心累 orz

---

雖然小編不會寫 Objective-C 但還是去 FCUUID 翻了一下程式碼 (https://github.com/fabiocaccamo/FCUUID/blob/master/FCUUID/FCUUID.m#L99)，發現作者拿到 UUID 之後把 - 取代為空字串，所以只剩下 32 個字元。看了 README 的所有內容也沒提到會改變 UUID 的格式，「This library provides the simplest API to obtain universally unique identifiers with different levels of persistence.」

最後看到更有趣的一個 method (https://github.com/fabiocaccamo/FCUUID/blob/master/FCUUID/FCUUID.m#L358)，uuidValueIsValid 會判斷所傳入的字串是否為 UUID 格式，結果不知道是不是為了相容於正確的 UUID 格式，裡面的 regex 寫成 ^[0-9a-f]{32}|[0-9a-f]{8}-([0-9a-f]{4}-){3}[0-9a-f]{12}$，讓小編啼笑皆非 囧

只不過在 GitHub 上都沒有討論到 32 個字元及 36 個字元的話題，不知道是不是使用 FCUUID 的 iOS 開發者都沒有這種需求呢？

#uuid #ios #fcuuid

本日網路大事件：Parse 要關門大吉了！

小編今天早上睡醒收到的最震驚消息就是 被 Facebook 收購的 Parse 要關門大吉了，時間還有一年 (2017/1/28)，相信有在注意網路消息的大家，今天的動態牆應該是被洗版了。

現在有許多的 App 為了不想自己花時間做 backend，包括 Database, Push server, MQ, scale-out ...等麻煩事，所以常常都把這些事情丟給其他業者來代管，也就是所謂的 MBaaS (Mobile backend as a service)。其中小編比較常聽到的有 Firebase (被 Google 買下) 和 Parse (被 Facebook 買下)，小編自己是用過 Firebase，還算不錯的一個服務。

而今天就要來分享一下在使用這類服務，如 PaaS 或 MBaaS 時常要考量的一點，就是：lock-in。

意思就是使用某家廠商 (vendor) 的產品時，若因為某些原因想要換到新廠商，但想把在原廠商所留下的所有資料遷移 (migrate) 到新廠商卻無法遷移時，就發生 lock-in 了。

如果以雲端服務來舉例的話，通常有下面兩個原因：

* 用了 A 廠商的 SDK，換到 B 廠商時要改用 B 的 SDK。
* 用了 A 廠商的 DB，換到 B 廠商時可以變成另一種結構的 DB。舉例：NoSQL 轉成 RDBMS。

因為 migration 這件事情在不同 vendor 上面會是非常麻煩的一件事，所以開發者要用就要一次用到底，要不然就會發生像現在一樣要做 migration。

不過 Parse 還不錯，提供了 migration tool 把資料 dump 出來成 MongoDB，也把 Parse server open source 出來，已經是非常佛心了啊！！！

所以如果你的服務原本是用 MBaaS，但做到愈來愈大的時候，請記得該時把服務移到 IaaS 上面啊，要不然變大之後發現 lock-in 是很可怕的一件事啊！

像小編下星期一就要去幫最近火紅的 Funliday-台灣 移機了 XDDD

#parseshutdown #funliday #firebase #lockin