Peter
聊聊 Sudo 的名片吧
其實 Sudo 名片製作是一系列複雜事情的集合， 從設計的那一刻起，就開啟了一連串的任務清單。
從印刷流程上看 Sudo 名片
手上拿到的名片總是覺得很普通很一般，單色的名片，看不出什麼特別。 實際跑過印刷流程之前，我曾經覺得拿在手上的設計品，製作起來好像很簡單。
對，設計品製作可以很簡單，但也可以很困難。 市面上很多印刷一條龍服務，是許多設計品產出的 total solution， 應付大量的印刷、快速完成、便宜，更重要的是他們將印刷流程簡化成： 交檔案 -> 付費 -> 收成品
印刷品製作變成如此簡單，快速完成如此理所當然。
直到製作 Sudo 名片，將自己的雙手弄髒，跳進去參與印刷流程，才發現印刷流程是：
交檔案 -> 開版（按照印刷品顏色，這裡指開獨立版） -> 調色 -> 試印 -> 正式印刷 -> 墨乾
上述只提到「印刷」的流程，但沒提到的是「紙張」， 沒有紙或是墨的載體，你要怎麼呈現設計？
所以要得到載體「紙」，我要做到：
確認印刷尺寸 -> 研究紙張 -> 向紙廠買紙 -> 裁切成可印刷大小 -> 送印 -> 視情形而定再裁切
當上述兩個流程合併在一起，才是完整的印刷流程， 既然印刷流程那麼麻煩，為什麼還要親自參與其中？因為參與其中才可以控制許多細節， 例如： 1. 選擇質地更好的紙，而非印刷廠準備好的紙張。 2. 調整墨色，設計檔案中的顏色與實體墨能呈現的顏色必定有差距，而我們只能盡力的調整墨的顏色近似設計。 3. 實際接觸印刷廠，更能把關品質。
然而，這樣參與印刷流程耗費的是時間與人力，製作 Sudo 名片需要花上兩個多禮拜（還很緊迫）。 人力花費則是不斷地要確保每個環節沒問題，確保流程持續進行不中斷，才可以在兩個禮拜內完成。 更重要的是 Sudo 名片的印刷方式不是一般的平版四色印刷，而是凸版印刷， 凸版印刷因為金屬版面是凸出的，將墨水滾上金屬版後壓上紙張，凸金屬面將顏色印上紙面的同時會使紙面出現凹痕， 使紙張更有層次與立體感， 而隨凸金屬面壓入紙張，墨有時候會微微溢出凹面，行程手作感的溫度。
從公司營運上看 Sudo 名片
凸版印刷讓名片更有人的溫度，但合作的廠商卻都是以小型工作室型態生存的印刷廠商。 小型工作室的缺點： 1. 無法開立發票，因為規模較小，進貨墨水時上游廠商沒開立發票，因此印刷廠無進貨成本，更沒辦法有銷貨收入。 2. 規模小，產能較低，若剛好在同一時間有很多案子排入生產流程，印刷廠會消化不良，拖到名片完成的時間。 無發票是公司營運最無法接受的，無法開立發票，公司也無法報帳。
尋尋覓覓凸版印刷廠商，大多使用老式的凸版印刷機，收費方式也多以一千次（師傅重複一千次動作）估算印刷費用， 也因為一次一張的特性，使名片製作成本上升，較平版四色印刷昂貴。
總結
目前 Sudo 名片製作遇到的問題： 1. 製作時間長 2. 需要人力協調流程環節 3. 無法開立發票
製作時間長
製作時間長我認為是可以妥協的，因為基本上印刷廠的師傅已經熟悉 Sudo 名片的製作要點，Sudo 名片的配色， 因此不需要親自去監工（但有時候趕案子品質下降還是要反應）。 基本上要確認的是公司名片的資訊， 要分英文版、中文版，還是統一用英文版？ 要不要放地址在名片上？ 統一編號真的需要嗎？
當公司名片資訊確定了，就可以量產個人名片， 一個人印刷一次三千張，將名片的庫存保持在一年，如此一來名片製作時間長的缺點可以被彌補。
更重要的一點，新人進公司，不論如何應該都要配有名片，而非參加活動時才緊急出名片， 這種緊急需求，唯一的解法就是找大量便宜快速低品質的廠商印製名片。
此外公司的每個人都需要管理自己的名片， 例如一綑名片是 100 張名片，當自己剩下五綑名片時，就要趕緊提出名片需求了。
需要人力協調
負責協調印刷廠，專跑印務的人，我們稱他「掮（ㄑㄧㄢˊ）客」。 掮客可以解決人力協調的問題，但掮客會額外收取服務費，通常都是依照設計品直接報價，例如： 完成五本作品集冊子，一共多少錢（其中包含了紙張成本、印刷成本與掮客服務費）。
雖說掮客是理想的解決方案，但是掮客的服務費不便宜（他們就是靠這吃飯的啊）， 會讓名片的成本不合理地上升。
而且掮客通常也是個人工作室接案，開立發票也有困難。
無法開立發票
無法開立發票是整個流程最無解的問題， 一來是合作廠商都是小型工作室，都沒有辦法開立發票。 整個印刷流程：開版（無發票）、印刷（無發票）、購買紙張（有發票）。 只有紙廠可以開立發票，如此一來公司報帳就非常困難。
如果要有開發票的廠商，通常都是印刷一條龍服務的廠商， 卻又和 Sudo 名片製作的精神互斥， 這個是需要公司取捨的地方。
ocowchun
例外處理
笑談軟體工程：例外處理設計的逆襲，這本書買很久了，不過最近才開始看，一直以來對於例外處理一向就是try catch，然後在 catch的地方記錄錯誤訊息 然後做一些簡單的處理，並沒有很認真的去考慮如何處理例外。在書裡面
將發生例外的前因後果分解成三個部分 Failure,Error,Fault
Failure
是指軟體提供的功能失效，比如你寫了一個加法函數，正常的情況他應該要回傳兩個參數的和，例如 add(1,5)應該要回傳 6，如果回傳的結果不是 6 的話就代表這個函數失效(Failure)
Error
表示元件內部處理錯誤狀態，此狀態可能會導致 Failure
Fault
是經過判斷後導致 error 發生的原因，根據產生的原因可以分為設計缺陷與元件缺陷 設計缺陷就是你的程式裡面有 bug 所以你的程式無法正常運作，元件缺陷則是元件與元件間的互動不正常導致的錯誤，例如呼叫的Facebook API時，Facebook發生錯誤，這類型的問題必須要先釐清發生的原因才能找到解決的方式。
三個部分串連起來就是說缺陷(Fault)會產生錯誤(Error)，而錯誤(Error)會使程式的執行結果失效(Failure) 於是你會從 Fault 去檢視說會為什麼會產生這樣的 Error ，要如何應對才能避免程式 Failure 我覺得這樣子好像比較清楚知道該怎麼去做對應的處理， 非常建議大家買這本書
Amazon CloudWatch
這禮拜在玩 CloudWatch，研究使用 CloudWatch 搭配 AWS WAF 來監控每個 ip 的請求量，然後當超過一定數目的時候(例如每分鐘請求一百次以上)使用執行 Lambda 去修改 rule 來 ban 掉特定 ip 。不過研究之後也發現了使用 CloudWatch 來記錄指標(metric)還蠻方便的，有內建的統計功能，可以很方便的根據間隔來整理數據，本來有想要使用它來取代 Elasticsearch 不過很可惜的是他的 Dimension 功能在搜尋上不夠好用，在官方的文件寫到 You could not retrieve statistics using combinations of dimensions that you did not specifically create. 也就是說 如果你建立了一筆 metric 他的 dimension 是 Server=Beta,Domain=Rio, 搜尋時就一定必須要兩個 dimension 同時存在(Server=Beta,Domain=Rio) 不可以只搜尋其中一個 dimension(i.e. Server=Beta) 可是在實務上我們很常會進行這種類型的彙總計算 ，當你只能針對特定指標去做分析時，實用性就降低了很多，這點我覺得很可惜，而且就其他 AWS Resource 的 metric 來看，這樣的功能應該是早就做出來了才對，不太懂為什麼沒有辦法做，這時候又想到了另一間做資源使用間空的公司 Datadog 其實如果 Datadog 願意在監控 server 之外，另外獨立做一個類似 CloudWatch custom metric 這樣的功能(不需要相依於 server) 我覺得會是個不錯的產品。
