RFC 4122 文件中，版本 3 和版本 5 比較特殊，是以名字產生 UUID，在特定條件下，每次產生的 UUID 都應該是一樣的。當時的情境用不到 v3 或 v5，但現在的情境就非常合適用 v3 或 v5，因為我們希望的是對同一筆資料，不管是 email 或是交易紀錄，都能產生同樣的 UUID。

職場產業

音樂藝文

軟體開發

閒談軟體設計

這是從 Medium 開始的一個專題，主要是想用輕鬆閒談的方式，分享這幾年軟體開發的心得，原本比較侷限於軟體架構，但這幾年的文章不僅限於架構，也聊不少流程相關的心得，所以趁換平台，順勢換成閒談軟體設計。

Spirit的沙龍

閒談軟體設計：UUID 之三部曲

UUID 有個致命的缺點是，它實在太長了，128 bits 用 Hex 表示法，至少要 32 個字元，如果再加上分隔符號，就要 36 個字元，把這放在面向使用者者的頁面上，應該不會有人會記得住吧！但 UUID 就真的只能這麼長嗎？其實是可以再短一點的。

學習

閒談軟體設計：再聊 UUID

這是 UUID 三部曲的首部曲，接下來兩周陸續更新第二部與第三部，首部曲先聊聊 UUID 的前世今生，二部曲會聊聊如何縮短 UUID 的長度，第三部曲則是聊聊特殊應用，希望能幫助到大家。