Hank Lin

Jamie流行銷 也許你會說：我是專業的軟體工程師，我不需要會行銷。 這邊的軟體工程師可以換成其它許多工作，都可以通。但是以現在變換速度越來越快的世界，如何把我們的產品/網站/服務做最有效率的改進，這不單是行銷人員的責任。如果是新創公司團隊，可能只有2、3人，每個人如果除了自己的專長之外，對工作夥伴的專業能有多一些的瞭解，可以讓整個合作更流暢，讓產品能更快的進步。當團隊都能認同這個作法，自然工作效率也會比較好，也可以預期，在每個產品循環生命週期，能把產品越改越好。 你不知道的流行銷 在這本「Jamie流行銷」，Jamie介紹的是在新新網路世界，如何用科學方法得知「行銷」或是說任何產品的改動，對營收的影響。這是一個精確的科學方法，需要由技術人員支援，所以沒辦法只由行銷人員達成。這是因為我們在這整個改良產品的循環，有很多步驟要記錄。例如：下載app、加入會員、使用產品、付費等等。記錄之後，才能夠作為將來跑產品生命週期循環的數據。 這也是因為，在新的網路、社群網路、及行動上網，我們有機會能夠精準的得知使用者的行為。也就是說，今天任何一個新的行銷行為，或是對產品做任何更新，我們都有能力知道，這些變化，究竟對最後的營收，有怎麼樣的效果。這是在以前的廣告媒體，不可能做到的精確。現在真實的朋友都在facebook上連結、mobile app使用的人是能追蹤到的真實客戶、網站也很大程度可以個人化，都帶給我們全新的、不同的可能性。例如我們能藉由朋友推薦的病毒行銷，或是個人化的app或網站使用經驗。 這裡又和Jamie常提到的MVP、Lean startup完全有相關。所以，這裡不單是介紹一個新的行銷概念，網路的創業在整個團隊心態、開發流程、創業思維，都和舊作法有革命性的不同。也就是這整個環境因素都有根本的改變了，所以真的無法再像過去一樣，美術設計歸美術，程式歸程式，行銷推廣歸行銷。而必需有一個「團隊責任」的新概念。 其實不是教你行銷 因為我們重視的是科學的方法，所以讓客戶來直接告訴我們結果，是最快也最好的。既然是要準確的結果，一次就只能改一個變因，然後再去觀測結果。如果結果是好的，那就繼續下一個測試。如果結果比原本還差，那就馬上改回來。這裡又談到另一個Jamie常講的重點，也就是LTV > CPA。套在這個「Jamie流行銷」上，就更明顯了。也就是說，如果你的行銷花費，大於營收，(在這裡都用一個客戶的平均值來看)那無論你花多大的力氣去推廣，你的產品還是無法產生正的收益。當然，平平是行銷，處方相同，提煉作法不同，成本效果也不同。所以有的成本低，帶來客量大，但成交少，有的成本高，客量少，但是都成交。要怎麼樣去記錄、分析、判斷，就是又要靠智慧和敏銳的感覺了。 前面說的是我們不斷改進產品，並以行銷活動測試結果，但是舊的作法，常常是行銷和產品分開，也就是產品作出來了之後，不是用客戶的回饋，去快速的更改產品，而是用不同的行銷活動想辦法賣出去。當然這會有差異，但是效率可能會很差。這讓我想到愛因斯坦的一句話： The definition of insanity is doing the same thing over and over and expecting different results。 如果這個產品是錯的，那再怎麼樣高明的行銷活動，都無法產生好的結果。所以講到這裡，重點仍然是只有一直不斷的改進產品，找出高轉換率的產品之後，才能在行銷上加大力道。 只要有心，人人都會行銷 現在是一個需要自我行銷的時代，找工作，提案子，或是平常搞定朋友間出遊的地點等，都有可以參考的地方。這世界正在不斷的改變，而且就和宇宙擴張的速度一樣，還越來越快。現在每一天的新資訊，可能一年都看不完。要如何能夠動作更快，勝過競爭者，勢必要在心態上有徹底的改變，方法上也要更有效率。這不論是行銷人員，或是技術人員都應該精進和學習的。

需要銀杏嗎 我記得(至少這件事還記得，不錯)，以前看技術的書，雖然不到過目不忘的地步，但是至少我很清楚，要找的時候在哪裡可以找得到。最近這幾年，一直有一個感覺，就是: 如果你看過的資訊，不記得細節，以至於無法馬上拿來使用，那即使你知道你看過，也沒用，因為沒辦法馬上幫你達成效用。 即使你花時間去找，最後幸運找到了，花的時間也可能不符合成本。不過我最近常發生的，就是找了半天也找不到，我究竟在哪裡看過這個資訊的。之前花時間看的功夫等於白費了。 由於我知道人的大腦，能力非常強。經過訓練，可以發揮一般人想像不到的境界。所以我想，在吃銀杏之前，還是先訓練一下自己的腦子吧。所以我前一陣子又買了有關記憶的書，和我以前的習慣一樣，同樣題材的書我會一次買2、3本。這本「超級記憶王」就是我先看的書。 心中有畫面 我很久以前就知道，記憶是可以訓練的，但是要怎麼訓練? 最重要的就是心中要有畫面，把你想記的東西聯想起來。只要你心中有畫面，就一定不會忘記。這本書的兩個作者，都是從小就愛東想西想。然後漸漸把這一套作法系統化，發展成可以記憶演講內容、數字、人名、臉孔、日期、地圖等等，真的是很厲害。不過由於兩個作者是美國人，所以他們的作法都是完全依賴英文，不是天生說英文的人，可能還要轉一層，會有點慢。這兩個作者從小就有開始訓練這種本事，所以當然他們已經能夠想記什麼就記什麼。所以這不是沒有代價的，對不喜歡動腦的人，就沒辦法了。一但你肯花腦筋把要記的東西連結起來，就能要記多久就記多久。 訓練再訓練 這本書如果只是看完，而沒有真的去自我訓練的的話，就太可惜了，也沒辦法真的提昇記憶力。不過照著訓練真的是很花腦力的事，原本看過就好變成要「用心」看。但是這樣不就是原本我所希望的嗎? 看過一次，然後不需要回頭找資料，雖然第一次可能會看得久一些。現在我也開始試著記數字，看到路上的車牌、門牌，就想辦法練習。 所以，開始訓練吧!

下一個AWS 上一場我在精誠資訊的演講，有提到「下一個AWS從何而來」這個議題。我有列出了一些，不過我最有興趣的，還是「大量資料的處理」這一塊。 就像我在裡面講的，我不認為用小資本就能進入IaaS的市場，賣貨櫃機房更不算得上是雲端運算。那我認為比較有希望的還是在PaaS或SaaS。其中我認為將來最需要的就是「大量資料的處理」(big data processing)、「即時的資料處理」(realtime processing)、以及「資料的視覺化」(data visualization)。因為這些功能都和資料的儲存、使用、形態很緊密結合，所以開發好用的SaaS就是我最感興趣的。 真實的需求 現在的網路世界，不單是server數量大增，可以上網的裝置也大量增加。以前的電腦還一定要人走過去用才上網，現在手機、平版電腦、販賣機等可以上網的裝置爆增，以後可能所有電子產品都可以上網，簡單到一個插頭都可以回報資料。所以資料量是以等比級數在上昇的，要如何快速、正確的取得我們要的資料，就變成最重要的問題。 以前有一個名詞叫data porn，形容資料太多，像色情一樣泛濫，不知從何處理起。那可以想像，資料如果用等比級數在增加，這個data porn會越來越難處理。而Hadoop的出現，幫助我們解決一部份的問題。 一切從一篇paper開始 一般公司要解決大資料的處理，大都是開發程式，用自己的方法去解決資料處理的問題，開發一個應用成本比較高，不易再利用。Google在2004年發表一篇很有名的「MapReduce: Simplified Data Processing on Large Clusters」，說明Google如何處理爬回來的網頁，以支援Google的搜尋等服務。特點就在於可以用一套程式設計界面，處理各種問題。寫一個應用時不需要處理分散式的程式設計等問題，重用性較高。可以投入更多機器，讓問題更快解完。而且還有容錯能力，會自動重試失敗的jobs。 MapReduce這麼神，但是當然Google沒有發表實作細節，許多細節還申請了專利。其它人想用MapReduce怎麼辦? 黃色大象Hadoop 另一個大師，Doug Cutting，為了支援Nutch，又建立了Hadoop這個專案。以模擬MapReduce的樣子，做出這個分散式資料處理的框架。因為是free open source，所以被許多公司拿來用。現在Yahoo!是最大的操作者，單一cluster有到4,000個節點。Facebook、Amazon、Apple、eBay、Microsoft、IBM、HP等等大公司也用Hadoop來處理大量資料。所以就像我前面說的，隨著資料越來越多，增長得越來越快，Hadoop(或大量處理資料的工具)就會越來越重要。投資在Hadoop上，似乎是下一個最被關注的課題。 當然，除了Hadoop，還有許多的類MapReduce的資料處理框架，只是Hadoop是比較多人在用的。 這個星期五(3月23日)，我在精誠資訊分享第2場「向成功的雲服務學習」，歡迎你。

令人又愛又恨的小圖檔 小圖檔在網站上，扮演一個很重要的角色。即使是像我這個懶得放圖的blog，還是得有favicon小圖示，按鈕、上一頁/下一頁的小圖示等。一般的商業網站更是需要大量的圖。這些圖的請求量通常很驚人，所以怎麼優化就變得很重要了。 根據Yahoo!的研究(http://www.yuiblog.com/blog/2008/10/29/imageopt-1/)，圖的請求量(總bytes數)，平均約佔總傳輸量的46.6%。當然每個網站都不相同，但是這個平均數也太驚人了。如果可以減少圖的負擔，網頁可以讀取得更快，伺服器也可以服務更多的使用者，頻寬費也可以降低。所以要做一個高品質的網站，圖的規範最好從一開始就建立好。 縮小圖檔的大小 優化圖檔有許多作法，其中一個最簡單的作法就是：縮小圖檔的大小(bytes數)。 一般設計師輸出的圖，常常存了許多不必要的資訊(metadata)，在網站顯示這些圖檔是完全不需要這些資訊的，把它們去除通常可以減少檔案大小。唯一要注意的就是有版權的圖是不能這樣作的，除非你有這張圖的版權。另外可以做的就是優化壓縮的效率，而不至於損失圖像的資訊(lossless)。可以縮小圖檔大小的工具有很多，我們可以只看一些免費的工具。 imagemagick: 萬用的圖像工具 OptiPNG: 專門處理png的工具 PNGCrush: 專門處理png的工具 PngOptimizer: 專門處理png的工具 PngOut: 專門處理png的工具 AdvanceCOMP: 專門處理png的工具 DeflOpt: 專門處理png的工具 PngQuant: 把png24轉成png8的工具 Pngnq: 把png24轉成png8的工具 Improved Pngnq: 把png24轉成png8的工具 ImageWorsener: 把png24轉成png8的工具 JPEGTran: 專門處理jpeg的工具 Gifsicle: 專門處理動畫gif的工具 可以用的工具不少，每一種工具對不同的圖，處理完的大小還可能有不小的差異。但是要對每個圖試用每一個工具，拿最小的來使用，會太花時間。所以只要選一個自己覺得好用的來用就可以了。 據我的經驗，jpeg最多可以減少20%的大小，png則可以減少10%的大小。 處理圖檔的原則 圖的尺寸較小、但要有清析的邊緣，例如小圖示，使用png。缺點是使用png8時，顏色受到限制，用png24在大圖的檔案大小又會太大。 圖的尺寸較大、顏色要鮮明，例如照片，使用jpeg。缺點是高對比的邊緣和大色塊會模糊 可以的話，把所有gif轉成png8(除了動畫gif)，或是一開始就規定不要使用gif。 動畫gif的數目也要儘量減少，有的話，使用工具去縮小 用工具對所有png圖檔執行縮小的步驟 用工具對所有jpeg圖檔執行縮小的步驟 壓縮 許多網站伺服器，如Apache, 或是應用程式框架，都有動態壓縮輸出內容的功能，可以很簡單的設定那些輸出是要壓縮的。由於常用的圖檔格式: jpeg、png、gif都是已經壓縮過的，再經過壓縮程序常常多花時間、花記憶體、花CPU，但常常壓出來的東西反而還更大，所以這些圖都記得絕不要設定壓縮。 favicon 一定要記得在你的網站放favicon，而且favicon最好不要太大，最好小於1KB。有的favicon檔案包含了各種大小的圖檔，所以就會太大。可以的話，使用16色palette png就好了。動畫gif的favicon是完全不必要的，要避免(但是動態更換favicon倒是在一些場合很有用)。

很久以前看英文的技術書時學到「nuance」這個字，查字典的解釋是「細微的差別」，例如音調、顏色、見解等細節的不同。 我喜歡這個字，是因為這個字代表每個個體的獨特性。以音樂來說，貝多芬的第九號交響曲的樂譜只有一種，但是不同的交響樂團，不同的指揮家，甚至不同的音樂廳，演奏出來的感覺都不同。而這些不同的版本就有個人喜好、意境的不同。節拍快0.1秒、音符修飾的1/100差異等等，這些用科學統計方法來看，不具顯著性的差異，但是卻能表現出不同的風格。例如福特萬格勒在拜魯特的貝九就被視為是經典詮釋。 有的指揮家認為，要完全遵照作曲家在樂譜上的指示，忠實的呈現出來，貫徹作曲家的意志。但有的指揮家覺得，樂譜有其表達力的限制，應該要適時揉合作曲家的作曲背景，並由指揮/演奏去詮釋作品。但不論是哪一種，都要有一定的能力才能達到。 我是Leica M相機的愛好者，這款高品質的德國相機，堅固耐用，功能非常少，他僅有的功能都是讓你能專注在「拍照」這件事上。用Leica M拍出來的照片，優異的暗部細節和寫實性，讓我非常的喜愛。看習慣用Leica M拍的照片之後，看一般的照片就會覺得「少了很多細節」。有些人看不出細節差異，但是我剛好是看得出來的那種。 回到軟體開發上面，「nuance」這個字就更重要了。軟體開發雖然是一種「創作」，但是本質上和「演奏」比較像。演奏要以「樂譜」為本，加上演奏者的詮釋。而軟體開發也是有一個目標，例如「需求」，再由開發者去詮釋。但是這個目標不像樂譜，有非常明確的規範，所以開發者能夠發揮的空間非常的大。就算再詳細的設計文件，在真正實作時，還是有一大段空間要填滿。 例如，我想做一個線上購物網站，這是目標，但是在作出來之前，沒有人知道這個網站將來會長什麼樣。就算網頁看起來一模一樣好了，也許背後用的技術完全不同，也許scalability不同，也許performance不同，也許cost不同。而這一切一切的不同，就是由許多開發時的選擇累積出來的。這些自由選擇(詮釋方式)，就是我所說的軟體nuance。 所以，軟體的開發者、設計者、架構者所作的大大小小的選擇，也就決定了這個系統的個性。和音樂一樣，在達到一定水準之後，沒有絕對的對錯，就只有「品味」(或喜好)的問題了。例如：貝九我可能比較喜歡卡拉揚的版本。 對軟體工程師來說，要有能力控制nuance，就必需要不斷增加見識廣度和技術深度，也要保持一顆熱情開放的心，願意嘗試新的東西，不能習慣於過去的作法。我的經驗是，我以為我已經看得夠廣夠深了，在和不同領域的人談過之後，我才發現自己看得太少了。同時，也要能培養出辨別「nuance」的能力，要知道作這個選擇會有什麼影響。 品質，是由許多小細節累積而成的，讓我們一起勉勵！

每個原始檔要先最小化，然後依照引用的順序合併。檔名可以在佈署時動態產生，常用的選擇有亂數、佈署版本的號碼或名稱、最後修改的檔案時間戳記、或可閱讀的曰期時間字串。 每個頁面所引用的JavaScript檔，組合會有很多種。所以對整個網站考量時，就有幾種合併的作法，以下是比較常用的。 整個網站用到的所有JavaScript，都合併成一個檔案 適合所有頁面引用的JavaScript，組合並不多時。並且引用的順序都一樣，也就是順序不影響的時候。這種作法當然網站速度最快，但是常常每個頁面引用的JavaScript，都有不同。而且有些JavaScript檔案，只在一、二個網頁被引用到，這個比例高的話，就變成每一頁都還要引用原本只需要在那一個網頁要讀取的JavaScript。有一些這類的JavaScript函式庫還滿大的，例如所見即所得編輯器(WYSIWYG)，所以實務上不見得是最適合的作法。 將所有頁面，或是超過一半的頁面，都有引用到的JavaScript，合併成一個檔案 這個JavaScript會被全部的網頁所引用，然後每個網頁再各自去合併自已的專屬JavaScript檔案。也就是變成一個是整個網站都用到的合併檔，另一個是這個網頁用到的合併檔。這樣的作法，會減少單一頁面的傳輸量，不至於包含了過多沒有用到的JavaScript檔案，但是至少會有兩次的JavaScript請求。適合每個網頁所引用的JavaScript很分歧，而且檔案又不算小的時候。這也是一般常見的情況。 每一個網頁各自合併自己引用的檔案 這樣每個網頁只會有一個JavaScript請求，而且不會有多餘的內容，也容許相同組合的JavaScript以不同順序引用。缺點就是你可能需要把JavaScript合併成多種組合，最多到和網頁數一樣多。如果在各網頁間，引用相同的JavaScrip檔案數量很少時，就適合用這個作法。其實這個作法不用管理”共同的”及”各別的”JavaScript檔案，是我比較喜歡的作法。 合併完成後，再來就是要最小化（minify）。JavaScript很適合最小化，可以用語法解析器（parser）檢查，並把不需要的空白去掉。例如使用rhino、jslint。 在合併完後，尤其是最小化之後，JavaScript原始檔會變得完全不能由人去編輯，所以合併及最小化的工作必須在佈署時期，由工具幫我們作。最好是命令列的工具，可以整合進專案的自動管理流程。 如果原本的一個JavaScript檔案，被合併到多個合併後的檔案。那麼，即使你只改了原始檔的一個字，所有合併後的檔案，都要重新產生，使用者也應該重新下載。 這裡可能有二個問題： 我們有設定快取標頭，如何通知使用者(瀏覽器)下載新的合併檔？ 只改一個檔案的一個字，就要使用者重新下載合併的檔案，會不會影響速度？ 第一個問題，只要改變下載合併檔的URL，下次使用者到這個網頁，就會重新下載這個合併檔。麻煩的地方在於，我們要把所有修改過的合併檔，傳到伺服器上。也就是說，一定要再走一次佈署流程，把所有合併檔都產生好，再佈署上去，即使有工具幫我們作，負擔也是不小，過程也很多地方可能會出錯。所以使用「lazy initialization」，在伺服器端作「合併」、「最小化」的工作，也是一個不錯的方法。 第二個問題，我認為影響不大。因為我們的目標是，即使客戶端完全沒有快取，也要能很快的顯示網頁。以每一個網頁只使用一到兩個<script>元素來看，負擔很小。這也可以說是，因為我們把請求數目大量的減少，所以不用太擔心快取的問題。 進行好合併、最小化之後，其它的工作就比較簡單了。也就是在網站伺服器上，對JavaScript檔案進行壓縮及設定快取標頭，把JavaScript的下載最佳化。 JavaScript檔案和區塊，都應該放在HTML文件的最後面。例如我的習慣，是像這樣子： <html> <head></head> <body> …… <script src="combined.js"></script> <script> $(function() { init(); }); </script> </body> </html> 我們常常需要在我們的網站上，引用第三方的JavaScript函式庫，如社羣網站API、測量工具、或廣告商等。以前通常會對放置JavaScript的區塊作限制，甚至要求要用document.write()的語法，對我們網站的效能造成嚴重的限制。我真的不希望使用者看我的網頁，要先等廣告render好，才出現真正的內容。尤其是JavaScript的請求會擋住(block)網頁的render，如果第三方的網站回應較慢，還會連累我們的網站，讓使用者等半天，只看到白畫面。 還好，現在比較大的第三方JavaScript函式庫，都支援了非同步的JavaScript使用法。所以我們也要把這些JavaScript，在HTML文件和資源都準備好(onload)之後，再去呼叫初始化。初始化的步驟通常是用JavaScript插入一段引用第三方JavaScript函式庫的<script>元素，然後傳入必要的參數。 現在非同步的JavaScript函式庫的支援很常見，所以一定要用這個方法去引用。如果你要用的函式庫，沒有支援非同步的使用法，那我建議考慮別家，有支援非同步的函式庫。 另外應該避免的作法，就是使用「inline」的JavaScript，或是說<script>區塊。所謂的「inline」，就是直接寫在HTML裡的<script>元素，例如： <div> <script> alert("!"); </script> <img src="what.png" /> </div> inline又分成兩種，一種是寫在靜態HTML裡，如果量不多倒是還好。另一種是隨著伺服器端腳本（server side script）或範本（template）工具動態產生的HTML寫出去的。 這兩種作法都會造成許多管理、開發、和優化的麻煩，所以要從一開始就要儘量避免。 如果要最小化這些源始碼，必須先把inline的一段段<script>的內容拿出來，進行最小化處理之後，再塞回原本的地方。這個過程很囉嗦，也很容易出錯。 然而，還有一種寫法比inline更糟，那就是用伺服器端腳本或範本工具，動態產生JavaScript區塊，例如： <script> alert("Hello, <%=userName%>"); </script> [...]