2012年10月31日 星期三

Growth hacking by measure conversion



這幾天在看Mattan Griffel 所寫的Growth Hacking投影片，因為內容實在太多了有166頁，所以得慢慢吸收消化，先把比較有感覺的部分記錄下來。

首先Mattan Griffel 花了很大的篇幅再介紹什麼是Growth hacking以及這的名詞的起源：

A growth hacker is a person whose true north is growth

 Growth hacker are a hybrid of marketer and coder
- Andres Chen, andrewchen.co


好這其實不是重點，重點是介紹所謂的Growth hacking 應該要做什麼事，其中很重要的就是透過測量轉換率 (conversions)來擬定策略。這讓我想到之前寫的 精實創業之虛榮指數(Vanity metric) 就是在說明如測量正確的指數，下圖就是我之前揣摩Lean Startup 那本書畫出來的。


但是國外真的有人做出這樣的分析系統，投影片介紹到兩個網站 kissmetrics 和 mixpanel 都有做到這樣的功能 (不過這類型網站真的越來越多了，應該競爭很激烈吧？)，真的讓是讓我非常讚嘆，因為他們不但把這些概念都做出來，而且使用上淺顯易懂，有真的在經營網站和系統的人可以去試用看看。

下面就是網站的截圖：




除了做筆記外，另外我的感觸就是我的行動力也就僅止於對於書本內容的需求分析：
  • 這些指數應該怎麼產生
  • 該怎麼正確的觀察指數
然後畫出一個示意圖，想著之後有機會也許可以用google analytic 來做出這種圖 ，就沒了....(不過我還真的研究過到底要從google analytic 產生這種圖，還真的一點也不容易...Orz..有高手可以教一下嘛) 。

這時候如果是個hacker應該就會直接做一個出來，如果是一個entrepreneur也許就會考慮做出這個系統並想著它的business model該如何獲利，而如果是一個嘴砲...(就會像我一樣只能在這邊介紹這個系統~XD)
於 張貼者： 0 意見
標籤：

2012年10月30日 星期二

邁向自動建置佈署之路(3) - Maven plugin




 (Please let me know if I violate any legal copyrights)



現在來到自動佈署的最後一站，以下內容與圖片都是節錄自Automated deployment with Maven and friends  Going the whole nine yards 這個投影片，這個投影片主要就是在教授如何透過Maven 做到Build automation and Deploy automation，不過這裡的deploy 我個人認為比較適用於 testing and staging 環境為主，如果要上production 則必須有更嚴格的機制。下面我把一些重點節錄出來：



最好的佈署策略就是由Deploy 經由CI Build 出來且驗證過的War檔，不應該由RD 的sourec code (snapshot)重build的那一份 。


在這邊使用的是cargo-maven2-plugin 的個plugin，用來自動佈署


在這邊是設定要佈署到哪一台測試環境的機器上，這邊的範例是用tomcat

當然Cargo也支援其他J2EE的container 包然Jboss、Jetty、JonAS...等


另外這個投影片也有提到，如果自動佈署可能會因為佈署的環境不同，會需要有不同的設定檔，此時可以設定不同環境，讓maven去讀取不同的設定檔，或是patch file，所以首先你要先建立一個專門為了佈署用的mave專案



在這個例子就是dev 和 staging 分別使用不同的版本或是不同的設定檔


然後這個專門用來佈署的maven 專案，就只要透過webapp的版本就可以控管每次要佈署的版本是什麼，才不容一造成錯誤。也比較好明確定義這次上的是哪個版本，測試的是哪個版本。


這篇壓了很久，不知道是不適合Po出來，比較很多圖片都是直接截圖下來，不過當初看到這投影片真的有種長久以來的問題被解決的感覺~:P 希望對大家有幫助


Reference:
[1] Automated deployment with Maven and friends  Going the whole nine yards
於 張貼者： 0 意見
標籤：

2012年10月28日 星期日

[DevOps] Continuous delivery - tools and techniques


圖片來源：功夫

快~快~快，大量閱讀，快速學習，似乎已經是資訊產業的常態 (變態) ? 看越多書和資料就越是覺得要學的東西學不完，於是也越來越焦慮，不過追根究柢就是自己基礎功不夠扎實(內功沒練好)，另外就是不夠專注吧，每一塊都想要碰，沒有個定性，所以才會落的如此下場 (囧rz....)。

那我今天要焦慮的主題是什麼呢？就是關於DevOps這個範疇，如果要號稱自己是在搞 Cloud computing 的，而且又有在實行敏捷是開發，那一定要知道什麼是DevOps ，也一定要知道所謂的 Continuous Integration / Delivery / Deployment。 因為這些方法與工具的目的就是：
  • 提高品質
  • 降低Cycle time
而所謂降低Cycle time 就是在幫忙加快速度，不管是開發速度，更新速度，實驗的速度，最終的目標就是加快找到你的MVP (加快賺錢速度，趕快停止燒錢)，這其實也就是Lean的精神。

就我的認知DevOps所包含的範圍大概如下圖所示，如果單看傳統的Dev 和傳統的Ops 也許會有一些地方有重複。

圖片來源：自行繪製

下面列出來的就是整個DevOps 所需要用到的工具和要注意到的環節 (主要是列出來的是以Java Solution 為主)，看到這些東西是感到興奮還是胃痛呢？XD

我覺得Dev的部份每一個項目至少要熟悉一種工具才能稱得上是稱職的Java Developer，遙想當年每個項目與工具都只能慢慢摸索出來，在沒有人帶的狀況下走了許多冤枉路，同樣的現在我覺得自己目前需要補強的就是Ops 這一塊的經驗與能力。


要列下去是沒完沒了....有沒有人要分享一下還有什麼該學習的技術和工具呢?:P


Reference:
[0] Continuous delivery tools and techniques
[1] The unsexy side of big data: 5 tools to manage your Hadoop cluster
[2] WhosCall

於 張貼者： 0 意見
標籤：

2012年10月24日 星期三

到底Facebook用了哪些技術?

Source: network


如果今天錢不是問題，會員不是問題，要你打造一個facebook，你認為作不作的到？之前曾經在很多地方比如說ptt soft_job版看到相關的問題，說台灣只是沒有環境，不然要打造一個facebook，只要有人出錢，對台灣工程師來說技術上都不是太大的問題.....真的是這樣嘛？

這個答案可能是對的，但也可能非常錯，因為這個假設沒有加上一些明確的變因：
  1. 時間：做出來是2004年的facebook？還是2009年的Facebook？還是2012年的Facebook？
  2. 人數：做出來給1M的使用者？還是100M的使用者？還是300M的使用者？

下面放了兩個Facebook Architecture 的投影片，Facebook 為了承載更多的使用者，為了增加更多的功能，提供更好的效能，它的Architecture也是一直在演進的，下面分別列出2009和2012年的介紹，就可以看出其中的差異。



另外也有許多篇文章提到Facebook architecture and design [1]

下面列出Facebook 所用到比較有名的技術：
  • Web Tier
  • Cache Tier
    • memcached   
      • 用來處理分散式快取記憶層，加速資料存取速度
    • Tao (Distributed Graph Database)
      • 專門設計用來儲存Social Link 關係的資料庫
  • Storage Tier
    • Cassandra      
      • 雖然是Facebook release 出來的，但是後來他們改去用Hbase
    • MySQL Cluster
    • Hbase
    • Maystack  (BLOB Storage) 
      • 用來存放照片、影音、Email附檔..等，Binary形式的資料。
    • Tired Storage 
      • 心一代的儲存機制，不過仍在開發中
  • Framework
    • Thrift               
      • 用來處理跨平台 Serialization 傳輸資料的格式和方法 - 某種RPC
上面列的還都只是軟體相關的，還不牽扯到Datacenter(網路、硬體...)相關的技術，因為facebook也有參與open compute project。

這讓我有一個感想，覺得關於程式啊，技術啊，這些可能一半靠腦袋和天份，一半靠磨練和熱情，不過都是可以到達一定的程度，但是系統架構與解決問題的能力就真的很大部分都是靠經驗和機運了，因為遇不到就完全不會知道這種東西(也不需要知道?:P) 就算現在資訊那麼發達，我試著問我自己，如果是我，現在錢不是問題，會員的來源不是問題，又有上面的資料參考，你是否作的出一個facebook呢？

這時候是不是要把經濟動能推升方案的口號拿出來！

系統設計與開發是很複雜的，很難用三言兩語講清楚

系統開發，做就對了！ (誤)




Reference:
[1] Facebook Cassandra Architecture and Design
[2] Facebook's New Real-time Messaging System: HBase to Store 135+ Billion Messages a Month
[3] Why Facebook Uses Apache Hadoop and HBase

於 張貼者： 0 意見
標籤：
訂閱： 文章 ( Atom )