2012年6月29日 星期五

Google 推出 IaaS - Google Compute Engine


Goolge 也來分食大餅了！IaaS 的市場進入全面化戰國時代！

正當ithome還在討論台灣的IaaS上軌道了嘛？ 在昨晚 2012 Google I/O 投下了震撼彈，正式推出 Google Cloud Platform，其中最讓人驚喜的就是對外營運的IaaS - Google Compute Engine (GCE)，有別於PaaS - GAE 對與許多開發者可能綁手綁腳，這次推出的GCE也是以虛擬化技術為基礎 (不知道使用哪種技術？Xen? KVM?)，讓使用者可以任意開啟Linux VM (沒錯目前只有支援CentOS 與ubuntu)，那Google Cloud Platform到底有提供哪些Service呢？
豪華旗艦服務一字排開，這讓我覺得Google 要跟Amazon兩大帝國將要展開正面對決了(M$表示：我勒我勒~)，不過如果拉高層次，目前整個網路界的狀況應該可以比擬成東邪、西毒、南帝、北丐、中神通的華山論劍，只是這回合是輪到 Google 和 Amazon 開始切磋，戶Google 準備要去踩 Amazon的地盤了。



Google Compute Engine vs. AWS EC2

老實說，規格一比較起來，Google 還有頗長的一段路要走 (謎之音：你看連Google也很難一次到為跟Amazon拼~XD)，下面就簡單整理一些比較：

名詞比較




GoogleAmazon
VM關機會消失Additional Ephemeral Disk local Disk
VM關機後不會消失Persistent DisksEBS


Google Compute Engine Units  (GCEU or GQ)Amazon EC2 Computing Unit (ECU)
Computing UnitWe chose 2.75 GQ’s to represent the minimum power of one logical core (a hardware hyper-thread) on our Sandy Bridge platform One EC2 Compute Unit (ECU) provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor 


價錢

很明顯的看出來價錢很有針對性，不過Google 目前似乎沒有分Zone，所以只有單一價錢，這點仍須確認。




Spec
Google 
Amazon
Small Instance
1Core
1 EC2 Compute Unit
1.7 GB of memory
160 GB of local torage

$0.080 per Hour
Medium
1Core
2 EC2 Compute Unit
3.75 GB of memory
410 GB of local storage

$0.160~0.23 per Hour
n1-standard-1-d
1Core
2.75 GQ
3.75 GB of memory
420 GB of local storage
$0.145 + 0.053 per Hour
=0.198

Large
2 Core
4 EC2 Compute Unit
7.5 GB of memory
850 GB of local storage

$0.32~0.460 per Hour
n1-standard-2-d
2Core
5.5 GQ
7.5 GB of memory
870 GB of local storage
$0.29 + 0.053 per Hour
=0.343

Extra Large
4 Core
8 EC2 Compute Unit
15 GB of memory
1690 GB of local storage

$0.640~0.92 per Hour
n1-standard-4-d
4Core
11 GQ
15 GB of memory
1770 GB of local  storage
$0.58 +0.053 per Hour
=0.633





於 張貼者： 1 意見
標籤：

2012年6月27日 星期三

精實創業之虛榮指數(Vanity metric)


圖片來源：網路

初創事業的任務

  • 積極評估自己現在所處的位置，然後勇敢面對評估出來的慘忍事實
  • 設計可以學習如何將實際數字推向目標的實驗

不管任何時候，看到這種向上攀升的數據(拜託不要是體重)，對任何人來說都應該會感到開心，有成就感 ，但是看完精實創業 (The Lean startup) 的第七章-評估後，才知道這只是讓自己爽，卻沒有太大意義的虛榮指數(vanity metric)，你沒辦法靠這個數據去做任何有效的判斷，因為這裡面混雜了太多的變因在裡面。

到底要修改或是新增產品的功能是誰說的算老闆？Product Owner？還是工程師自己決定？

正確的方法是誰都可以提出意見，但是所有的意見和結果都必須以科學化的方法去建構初一個責任制架構，每個Business Model 的絕對假設，都必轉化成可以量化的數字或指標，所謂科學的方法：
  • 觀察→假設→實驗→分析→結論
  • 觀察→新假設→實驗→分析→結論

三大學習里程碑

  • 產生最小可行產品，才能開始收集數據
  • 建立基準線(base line)，才知道任何的改變是不是真的有幫助
    • 數據(漏斗式數據)
      • 轉換率 (由粉絲頁，由Google廣告)
      • 登記率
      • 試用率 (登記卻未登入，登入後使用x種功能)
      • 客戶關係週期價值 (重複使用率，使用頻率)
      • 購買率
    • 實驗原則 
      • 就像做科學實驗，操控變因，應變變因(但是一次只能改一樣)
  • 軸轉(Pivot)或是堅持 
    • 根據實驗的數據與結果

其中關於實驗的目標，必須要使用群組研究法(cohort analysis)，以每個月或是每週的顧客為一個群體，分別產出如下圖所示的漏斗式數據圖表，這樣看才有意義，以我的認知，應該把圖表做成下面這個樣子。 (下圖是簡化的模擬案例)

圖片來源：自製

把每個月加入的客群分開觀察

橫向為時間軸(假設每個月Release 一次新功能)，縱向是每個月加入的客戶群組數據，舉例來說：
  • 二月的時候可能有做功能改辦，但是對於二月才加入的客戶，這個改版對他們來直接的影響比較小(因為他們不知道以前是怎樣)，但是對於一月加入的人，可能就會影響他們的感覺進而影響數據。
  • 三月的時候，又新增了一個功能，但是造成一月和二月加入的客戶數據都往下掉，代表這個功能可能真的不受歡迎。雖然單看三月加入的客群是上升的，但是應該跟功能改版比較沒關係，這時得分析，是否是這個月廣告成效比較好，還是有被哪個媒體報導造成人數增加，亦或是上個月的功能增加的口碑效應。
結論：

總之每次只做一小部分的修改，然後把每個月的客群分開，分別針對不同客群的漏斗式數據做分析，這樣才可以得出比較有參考價值的數據和推測，然後依此作為參考的依據，到底該不該加這個新功能，或者是推論到底要增加怎樣的功能才可以吸引更多的客戶，讓客戶願意付錢。

這是我目前看書的解讀，如果有錯誤，還請各位高手前輩給我意見~:)
於 張貼者： 0 意見
標籤：

2012年6月26日 星期二

邁向自動建置佈署之路(1) - 建置 Maven Repository


曾經有個PM問我東西什麼時候可以build好，什麼時候可以Demo，但是我沒鳥他...
等到Demo時，現測試機上不是最新的程式才後悔莫及，工程師最痛苦的是莫過於此。
如果上天可以給我個機會再來一次的話，我會對這PM說，我要Reschedule~~
如果非要在schedule 上壓個期限，我希望是一萬年....   
 (喂~~最近有人很愛亂用星爺梗~)

好廢話不多說，延續"沒有搭配工具與方法的敏捷式開發"這篇文章，如果要達到 Build automation 甚至 Deploy automation，必須要搭配哪些工具呢？接下來我會分幾個章節來分享，應該要安裝怎樣的系統，以及我們目前所使用的是哪套軟體：
此外還是想建議一下，在公司內裝一個Project Management 或Issue tracking 系統，真的對於專案的運行會很有幫助 (之後再來分享)，我們目前採用對內：JIRA 、對外：BugZilla，給各位參考一下。

野人獻曝之安裝個Maven Repository吧!


SVN 我想應該就不用再介紹了吧？(沒在用Soruce control？拖去處斬了)，所以我們先從Maven開始介紹，Maven主要是要解決Jar dependency地獄，回想起沒有Maven的那個年代，大家可能就是jar檔copy 來copy去，常常會抓到錯誤的版本，不然就是升級jar檔時，又會發現許多API根本不相容，或者是還需要引入其他的3rd-party lib，那時候開發專案，真是茹毛飲血的日子啊~@@

還好現在有Maven (讀音：是妹份不是媽份)，用Maven 可以很容易管理所需要用到的library，不管是 3rd-party還是自己公司開發的，此外他也提供一個產品庫模型，一個管理和描述項目的軟件引擎。定義了構建、測試、部署項目產品的標准生命周期 [優點與介紹]，不過有個小小的缺點：
  • 從公司連 public maven repositories 很慢
  • 很多Libray 並沒有放在官方的repository，所以必須手動加入其他網站 
  • 公司內部的 libraries無法(也不適合)放到 public repository 讓大家存取
解決這幾個問題的方式很簡單，就是建立自己的 local maven repository，有以下好處：
  • 具有Proxy的作用，可以有效減少對外網路頻寬的浪費與提昇速度。
  • Admin可以事先把常連到的Repository設定好，這樣開發人員只要連上使用就好
  • 提供一個可以管理團隊自行開發library的機制 (這對將來Build Automation 與 Deploy Automation很重要)。

下面列出一些跟Maven相關的重要資訊：

Maven repository Manager

Maven Repository Manager有那麼多種，究竟要選擇哪個呢？各位可以參考這篇文章，根據幾的需求，去選擇要使用哪套系統 "Maven Repository Manager Feature Matrix"

Maven Repository


因為並不是所有的Library都會放在Central Repository 所以下面列了一些我收集常用的Repository：
  • repo2 
    • http://repo2.maven.org/maven2 
  • ibiblio 
    • http://mirrors.ibiblio.org/pub/mirrors/maven2 
  • javanet
    • http://download.java.net/maven/2 
  • springframework
    • http://maven.springframework.org/release
  • jboss           
    • http://repository.jboss.com/maven2
  • anyframejava 
    • http://dev.anyframejava.org/maven/rep 
  • internet2
    • http://www.internet2.edu/grouper/downloads/maven2
  • Codehaus 
    •  https://nexus.codehaus.org/content/repositories/releases/
    •  https://nexus.codehaus.org/content/repositories/snapshots/

 Maven Plugin 


Maven 的Plugin 就真的是Maven 最powerfull的地方，透過Plugin結合CI就可以幫你自動化產出許多報告和報表，以下就列出我們常用的Plugin：

呼...好累今天就先整理到這裡~
於 張貼者： 0 意見
標籤：

2012年6月25日 星期一

如何利用DRBD的搭配來架設HA Service


HA? 其實概念跟替身術差不多，就是Primary 死了沒關係，Slave馬上會起來代替 (這個梗好像太牽強~XD)，所以許多Mission critical 的Service 都應該要做成HA的架構，通常來說簡單的HA架構會搭配幾個軟體：
  • Heartbeat 
    • 用來互相偵測對方是不是掛了，或是活著
  • DRBD 
    • 如果不是要備援，還要做到資料同步，那就要搭配DRBD ，他可以達到類似RAID1的功能，架透圖如下。


這幾天在整理這陣子記錄在Evernote的研究筆記，索性就敢脆整理整理放到Blog上，反正這些資料也都是Google 來的，正所謂取之於Google 用之於Google，如果連結死掉....那就敬請見諒，下面是我之前整理的資料：

其他關於DRDB +NFS 注意事項：

1. 只有擔任primary 的主機，partition才能夠讀寫、掛載目錄

2. primary掛掉時 HA 機制會將Secondry 啟用成Primary，並且掛載目錄，建立虛擬ip，啟用NFS，注意這時drbd 屬於無法正常運作階段(因為另一台掛了資料當然無法同步)
 
3. 修復掛掉的機器時，需要做以下程序
   1.internet 先別起來(否則drbd、ha會被干擾)
   2.先將drbd service 停止
   3.停止nfs 、 umount目錄
   4.將drbd設為secondary
   5.drbdadm create-md r0
   6.service drbd 啟用
   7.確認修復的這台是secondary  另一台則是primry

Reference:
[1] 24小時不打烊的雲端服務：專家教你用CentOS架設萬年不掛的伺服器，是這個網站的作者出了一本書
[2] Remus 是專門為 Xen 打造的HA架構，不過太新了我也還沒玩過~XD
於 張貼者： 0 意見
標籤：

2012年6月24日 星期日

中小企業是否該花錢在資訊系統上？


早上起來看到前同事對於"新創事業與中小企業應該要使用哪些工具與軟體來幫助營運？" 這篇文章似乎有點不同的觀點，不過也許是我寫的有點太工商服務性質造成誤會(讓人家覺得似乎有"有批牛肉好便宜的~有需要就打這個電話吧~"的感覺)，所以想再來補充一下。

那篇文章，要傳達的主要是兩個觀點，只是可能需要分開討論：
  • 中小企業和Startup應該使用一些工具和方法來提升競爭力 (工具不一定要錢)
  • Google apps 是便宜好用的好東西 (而且五個人以下還可以免費試用) 

中小企業和Startup的定義


先針對企業規模來做個定義 (各國定義不同，這邊以台灣為主)，根據經濟部中小企業處的標準，與我之前上課所了解的定義 (我聽到時都嚇一跳，要賺好多錢捏~@@)：
  • 微型企業 (人數<10  ，年營收<500萬 )
  • 小型企業 (人數<30  ，年營收<3億，資本額<3000萬 )
  • 中型企業 (人數<100，年營收<10億)
 而Startup的定義就比較模糊了：
  • 根據Mr. Jamie的定義：公司規模25人以下，設立 3 年以內的公司。
  • 根據郭氏兄弟的定義：公司規模不超過10人
  • 根據中小企業處大概五年以內(因為五年以內會倒超過92%)的公司都算新創事業

中小企業是否該花錢在資訊系統？

根據統計，同樣是中小企業，台灣的平均壽命比國外還有短的多，那到底是什麼原因造成的呢？可以怪罪的地方很多，比如說市場太小、競爭太激烈、政府不幫忙...等，這些也許都是原因，但是很多時候公司會倒並不是沒有錢或不賺錢，而是土法煉鋼、沒有制度、甚至人謀不臧所造成。另外很常見的就是成長失控，公司快速擴張，人才、內控制度與公司基礎建設跟上，最後的下場就是高速失控而墜毀。

所以我們該怎麼找出自救的方法？或是改善這個市場的方法，而不是向下沈淪，在這邊先不談論免費的解決方案(我可以另外寫篇文章列出許多免費的軟體)，我們先來談論要花錢這件事，為什麼國外願意使用這些工具甚至花這些錢呢？舉例11 Great Technology Tools for Small Business、Type Of Technology You Should Use During A Small Business Start-up。而台灣中小企業卻不願意？ 到底新創事業和中小企業是沒錢？還是不願意花錢？或是不知道可以把錢花在這些地方？(不知道價值)這三件事要分開討論：
  • 中小企業沒錢
  • 中小企業不願意花錢
    • 的確現在很多中小企業都是用所謂的"套裝軟體"比如說M$ Office系列 (合法性就是一個問號)，也許問題不在於企業願不願意花錢買，而是不知道怎麼用和怎麼轉換，至於要怎麼讓企業從Office 20xx轉換到 M$ Office 365，甚至轉換到Google apps，這就是行銷與教育的議題了，君不見M$也砸了大錢在推廣與宣導。
    • 套句現在做火紅的話 "只出得起香蕉的公司，那也只請得到猴子"
  • 中小企業不知道可以把錢花在不同地方(不知道價值所在)
    • 政府與教育是很重要的一個環節，現在台灣學校與政府機關都被M$所把持，所以為學生了出了學校只會用套裝軟體，到職訓局上課也只會教套裝軟體，公司為了作政府的案子所以一定只能用套裝軟體，那當然整個市場的思維就侷限在套裝軟體了。
    • 花錢買一套正版的套裝軟體，遠比使用雲端系統的費用高的太多了，更不用說還得請MIS來幫忙安裝與維護，所以是把錢花錯地方。
    • 根據 2005 年消基會的調查發現(有點舊的資料，不過仍有參考性)，平均每人每年花費 30 小時在刪垃圾郵件，若每人每天約花 10 分鐘過濾並刪除垃圾郵件，若以50 人規模的中小企業來計算，企業每月損失約 9,000 元的薪資。累積一年下來，相當於多發了超過 10 萬元的薪水，浪費在員工處理垃圾郵件的工時上。大家每天忙的跟狗一樣，其實都是在處理垃圾郵件，如果使用好的垃圾郵件防堵機制，把這些錢省下來，可以創造多少經濟效益？
    • 人員流失與異動率大也是台灣中小企業會遇到的問題，如何有效的建立KM系統，讓工作交接與教育訓練更順暢，就可以減少許多人力與時間的浪費。
    • 中小企業資安問題，造成人力錯誤的配置與浪費：
      •  職能分工不當與過度授權
      • 資訊人員淪為救火隊
      • 缺乏企業經營角度的資安控制 


如何使用一些科技工具和方法來提升競爭力


所以錢要花在刀口上，時間也要花在對的地方，當然我同意在工具上的使用上，還是得針對特定的族群，不同的行業會需要不同的科技工具，那我隨便舉幾個極端的例子：


所以重點不是該用哪些工具，重點在於不同產業，各個企業都應該找到能幫助自己，提昇競爭力的工具，科技不就是為了這個目的存在？

最後回到網路資訊相關產業 

這可能也是我Blog比較會接觸到的族群 (阿阿我也只想當旅遊部落客，貼貼照片啊！！)

正所謂外行看熱鬧，內行看門道，網路資訊產業更應該知道這些工具的價值與必要性，使用正確的工具來提升產能與品質，更是無庸置疑。我自己說可能還沒啥說服力，不然我們來看一下Xdite大之前寫的一系列文章，網站程式上線前需要準備的事(1)~(4)、Startup : 如何挑選適合的 Hosting Plan、為什麼必須使用 Issue Tracking System 管理專案。

有興趣的人也可以去看看這本書"走出軟體工廠"，作者是大陸人，裡面也提到許多大陸軟體公司採用土法煉鋼的方式遇到與多問題，該怎麼使用正確的方法，與適合的工具來提升公司的競爭力。


於 張貼者： 0 意見
標籤：

2012年6月23日 星期六

新創事業與中小企業應該要使用哪些工具與軟體來幫助營運？


在創業初期，你應該專注於找尋好的合夥人、適合的員工、確認Business Model與獲利模式，以及盡量的節省開支。要注意與煩惱的地方已經夠多了，怎麼還有多餘心力去管其他事情？但是往往創業者與中小企業老闆都被關於行政管理、基礎建設...等柴米油鹽醬醋茶的問題困擾著，成為事經營者浪費最多時間的地方。

許多Startup公司會失敗的原因往往都是還沒撐到獲利或是找出可行的商業模式就陣亡了，通常都是沒控制好花費，很快就把錢燒光了。就算順利度過這個階段，緊接著就是隨著公司日漸成長，規模逐漸變大，關於行政管理、基礎建設..等問題，也會一個一個浮現、擴大、甚至引爆，變成公司成功的絆腳石。

如何在適當的時機，引入適當的管理機制，和使用有效率的工具，就成為經營者的一個難題(至少我們就遇到過這些問題~@@)，好在我們是生長在這個高度分工與雲端科技的年代，許多創業的門檻都被大大的降低，有很多都的問題都可以尋求外部專業服務(顧問，專家)，甚至外包出去，另外你要做的就是選擇適合的科技與服務來幫忙解決問題，舉例來說SaaS的兩個核心價值：隨選即用，用多少花多少，隨著公司成長無痛的升級與擴張，在這邊引用兩本書的例子：

創業其實沒那個難：小創意勝過大資本裡面也有提到
..尤其是專業的現成服務也在此替我們包裝與配送。跟這些結合在一起的，還有幾乎免費的網路通訊、電話或者視訊會議，不但完成聯絡工作，費用也大大降低。 我們面前擺著一個巨大的工具箱與無數的積木，我們可以用這些東西發想出無窮盡的新組合。就像上個世紀史坦尼斯勞‧萊姆(Stanislaw Lem)所寫的，由各種高科技建構而成的未來小說，今日我們也可以寫經濟小說，描寫人和如何透過手邊可用的基石與零件，架構出她的想法。
80後老闆，教世界的八堂課裡面也有提出一個觀察，就是在美國80後的創業模式：
虛擬辦公室特別適合80後企業，當經濟不景氣，逼的許多公司不得不想盡辦法刪減固定成本，這樣的工作方式往往成為明顯的優勢。....我們透過電子郵件、skype、Gchat、Facebook、電子郵件照片、視訊會議、手機簡訊、維基協作系統、及其他任何適當工具來模擬在一起工作的感覺。....P271各位要注意一點，能夠成功使用虛擬方式營運的公司往往都搭配高科技工具。
所以一個Start up 應該使用哪些高科技工具的來提高工作效率，和幫助你的事業呢？下面列出一個中小企業應該必備的系統(軟體)：
  • 財務會計系統 (Finance /Accounting Software)
  • 資料備份與回復系統 (Backup and recovery)
  • 公司官網與部落格 (Web site and Blogging Tool)
  • 行事曆 (Calendar)
  • 線上協作平台與Office 套件 (Collaboration/Office Suite)
  • 客戶關係管理系統 (CRM)
  • 電子郵件 (E-MAIL)
  • 專案管理系統 Project Management 
  • 檔案分享與版本控管系統 (File sharing and version control)
  • 網路電話/視訊會議系統 (VOIP)
其中七項Google apps 都幫你準備好了，剩下的部分我們也可為您張羅 (再度工商服務一下~XD)，除此之Google apps還有幾大的優勢：

專業的IT技術與安全第一 (Security first)

很多人可能都會想把東西放在外面會 不會很危險，資料會不會不見，Google 會不會被入侵...等問題，但是反過來問，這些問題在你的公司就不會發生嘛？你請的MIS人員有能力解決嘛？會比Google更專業嘛？你們花在資安與備 援的經費會比Google多，作的更完善嘛？如果沒有那為什麼不交給專家呢？Google有以下承諾：
  • Your work is always backed up
  • You own and control your data 
  • Increased security and reliability 
  • Strong encryption and authentication 
  • Our team is constantly improving your security 

遠端存取與行動性(Stay connected from anywhere)

讓你可以在任何地方，使用任何的Device 取得你所需要的資料(不管是Email、行事曆、文件..等)，並且讓你達到隨時，隨地，跨組織的線上協作平台體驗。

零先期建置成本，低轉換成本（Invisible IT that just works）

你不用架設自己的伺服器，你只要有電腦連上網路就可以使用，甚至在初期五個人以內，使用Google apps都是免費的，超過五個人，每人每年也只要幾千元，就能擁有這麼多的服務。如果你公司已經有自己的伺服器(如M$ exchange Server)，只要一通電話來，Google 也有提供工具幫你把現有的服務無痛轉移到Google apps上面。(說實在有哪家的郵件系統檔垃圾信的能力可以跟Google比的)

夠環保(Go Green)

更重要的是，光是不用準備隨時都有冷氣在吹的機房，與24h開機的伺服器，就可以為你節省多少電費，更可以為地球減少碳排放量。也許有人會說放在Google data center 還不是會耗電增加碳排放量，但是我相信Google 在機房對於省電和節能的設計，以及能源轉換效率一定比我們自己高的太多，就像你會選擇自己買個柴油發電機，還是要跟買台電買由火力發電所產生的能源，哪個比較有效率?

(工商服務：有興趣的請參考思昉科技的網頁，留下你的資料，我們將有專員跟您聯絡)

接下來，我會在陸續分享，一般公司應該使用那些軟體與系統，以及我們的使用經驗，當然還有軟體公司應該建置怎樣的開發環境(參考我之前寫的：沒有搭配工具與方法的敏捷式開發？)
於 張貼者： 0 意見
標籤： ,

2012年6月22日 星期五

到底功夫熊貓(Xen)踢不踢的動大象(Hadoop)呢



到底功夫熊貓(Xen)踢不踢的動大象(Hadoop)呢？ 

這幾天我在Facebook - Taiwan Hadoop User Group 拋磚引玉貼了 "要使用大象，真的得養頭大象嗎？為何不使用AWS EMR"的文章，意外引起熱烈的討論，把許多潛水的高手和同好都吸了出來~XD (你自己不是也都在潛水)，因為大家都有遇到虛擬化效能的問題。

一般來說，要養Hadoop (或是大型分散式系統)，如果不是用實體機器來養 (除非你像google一樣有錢，不然一定養不多，也養不起)，不然通常就是用虛擬化的技術來玩。
如果只是玩玩和測試安裝與練習寫寫程式，那可能還沒什麼大礙，但是一到要玩到真實案例，甚至要上Production 就會遇到許多效能瓶頸的問題需要去解決。像在 Taiwan Hadoop User Group 的討論串裡， James 大大就有提到：如果同樣都是 100TB 的 terasort 好了, 如果把一個實體的hadoop cluster搬到AWS，要多多少個 node 才能有相同的效能 ?
老實說，目前我們也還沒有玩到這麼大的資料量，所以還真的沒對於這麼大量的資料做過benckmark，希望將來我們系統長到那麼大，有機會分享這些數據給大家知道~XD

回到效能問題，第一步可能要先引自Jazz大的名言：學控制的人都會知道『先能量測，才有辦法控制』，Jazz大建議安裝 Ganglia 跟 Munin來觀察，我們是裝OpenNms，總之要先確認Performace是出在哪裡：
  • Host Dom0?
  • CPU ?
  • Memory ?
  • Disk I/O ?
  • Network I/O ?
 第二步，就是要確認你的虛擬化環境與設備：
  • 你Server 的等級
  • 你目前是使用哪一版的Xen?( 3.x、4.x)
  • 你是使用PV  還是HVM?
  • 你是使用怎樣的deivce當domU's disk?( file: ? tap:aio:? phy:?)
因為公司內部和專案開發都是使用Xen，所以之前倒是有為了效能問題去找了一堆資料，整理如下：
  1. VM 盡量不要使用 SWAP (不過這還有爭議)
  2. RAID10 array is recommended
  3. 使用PV (半虛擬化)效能較好，或使用Xen PVHVM drivers for Linux HVM guests
  4. 盡量直接使用 block device (without file system).
  5. 如果還是要用File System 請參考這篇 Filesystem performance on Xen
 不過好像也沒啥特別的，大家應該都知道了，如果有其他作法，歡迎大家留言討論~:P

於 張貼者： 2 意見
標籤： ,

2012年6月20日 星期三

要使用大象，真的得養頭大象嗎？為何不使用AWS EMR


Amazon 在6/12宣布Amaozn EMR (Elastic MapReduce) 增加支援HBase的功能[1]，對於一般開發者來說真是一大福音，因為可以減少要自己養大象的痛苦，套句現在企業經營節省成本的一句名言：要喝牛奶，真的要養頭牛嗎？同樣的想要使用MapReduce 一定要自己養一群大象嘛？更讓人心煩的是大象一點都不好養，因為更精確的來說大象其實是個航空母艦戰鬥群，是由許多戰艦組合而成：

閱讀更多 »
於 張貼者： 2 意見
標籤：

聊聊獨立思考與組織邏輯能力


最近在Facebook有兩個熱門轉貼文張，(中日兩國歷史考題比較，法國高中會考哲學考題)，由這兩篇文章可以探討兩個議題：
  1. 轉貼網路的真實性，討論資訊爆炸下的速食資訊文化
  2. 談獨立思考與組織邏輯能力

轉貼網路的真實性


在網路上轉錄金句第一名的大概就是李嘉誠吧，用googgle 搜尋"轉貼文章 李嘉誠"，就可以發現一堆李嘉誠的名言，人生哲學，人生感悟....等，但底究竟有多少真的是他說呢？我想應該沒人在意，反正只要覺得裡面的內容講的蠻有道理，就瘋狂轉錄。

我不確定大部分的人是不是真的都有把文章看完 (有時候真的太長我也懶得看)，就算有看完又會花多少時間去深入思考其中的破綻或漏洞 (除了戰文和酸文，這要另外討論~XD)，所以大多順著文章的脈絡帶過去，只要邏輯沒有明顯的破綻，不反對甚至贊同他的論點，下一步就是轉寄，轉貼，按讚。其實這無可厚非，現代人每天要處理大量的資訊，又要期待能快速的消化並且給出回饋，本來就是一件很傷腦筋的事，不過如果不牽涉到專業知識那到還好，就怕轉貼"知識性"的東西可能根本就是有錯的，像這篇文章就非常有爭議 "下雨天戴墨鏡開車 看得更清楚？"，所以在轉貼文張前可能最好還是三思一下，至少google 一下是不是謠言。

(google 應該要提供一種謠言過濾的搜尋功能？:P)

談獨立思考與組織邏輯能力


對於文章的來源，出處，引用做確認，只能算是驗證的能力，但是要批判文章內容，就真的需要獨立思考與組織邏輯的能力了。 二千多年前孔老夫子就說了：「學而不思則罔，思而不學則殆」。只有閱讀，只是複製別人的思想，是別人思想的影子；如果沒有經過自己的思考，學習只是往大腦塞進很多資料。然而若不能經過思考消化，大量的資料累積其實只是「一堆垃圾」，豈能不陷於迷罔之中？

獨立思考就是要有自己的想法,但是也接受別人不同的意見，把自己所吸收到不同的意見自己去分析利弊，然後檢視對方的邏輯而不要只看結論，思考"?什麼對方會這麼想"，"對方的論點是否有瑕疵或漏洞"，再回來檢討自己的想法，是不是少想了什麼？ (好難啊!!!)


這也讓我想到之前關於洪蘭教授的報導，引自：

【2007/07/29 聯合晚報╱記者謝蕙蓮╱台北報導】
在完整表達自己這件事上面，這跟邏輯訓練有關。洪蘭說：台灣學生進了美國名校，在課堂上也無法侃侃而談，表達自己。這句話講的並沒有錯。台灣學生本來就是以背誦考試見長，組織能力見短。台灣學生也許聰明，努力，解決問題的能力很強，但是卻難以把自己的思想完整表達出來說服人。舉例來說，一個一個問題都可以解決，但是當把問題兜在一起，就分不出輕重緩急先後順序，或難以說服別人：我為什麼要這樣去解決問題。在國外與別人競爭，除了語言的障礙以外，我們的教育更缺少組織與邏輯訓練，讓台灣學生只能成為優秀的執行者卻難以成為優秀的領導者。
別人是怎樣我不敢說，但是這句話套在自己我自己身上真的是當頭棒喝，我自認為很會收集資料(因為資訊焦慮)，很會解決問題 (其實是trial and error的黑手)，不過在組織整合能力上就真的很弱，尤其是想要寫出言之有物的文章，真的還差的遠了。

很多時候書是看完了，但最多就是寫寫書摘，列出一些自己贊同的話，但還是寫不出一套屬於自己的系統， 還有很多時候腦袋會有許多靈光乍現的點子，一旦把點子訴諸文字把它記錄起來時，就會發現非常不嚴謹，甚至漏洞百出，所以我現在希望透過寫Blog 強迫把自己腦袋的想法重新整理過一遍，寫出來，然後再反覆的檢視與修正，一方面把自己的思緒順過一遍，一方面又可以檢查在邏輯上與架構上是否有錯誤與不足的地方。(我真的好怕寫錯東西到時候被人戰~)

獨立思考必須要做到批判和思考別人的文章，不過也必須做到不以言廢人，不以人廢言，就拿 Mr.6 和 Mr. Jamie 為例子，有很多人喜歡他們，但以也有蠻多人不太喜歡他們，有些人甚至直接就殺到他們版上去戰了，何苦呢？可以這樣長時間的產出文章，真的還是要多給他們拍掌(至少我覺得這真的很難)，至於覺得他們邏輯有問題的部份，就在自己的blog 再寫一篇批判文就好啦~:P

寫那麼多，其實如果我的爸爸是李嘉誠，那我應該可以不用管那麼多獨立思考，與邏輯能力了吧？XD (誤)
於 張貼者： 2 意見
標籤：

2012年6月19日 星期二

海峽兩岸雲端運算產業合作研討會



今天原本是去聽海峽兩岸雲端運算產業合作研討會，原本內容應該如下：

大陸刻正扶植雲計畫及開發多個城市試點，其未來發展策略及佈局為何？百度與Google分庭抗禮的秘密武器「框計算」(Box Computing)究竟為何物？聯想完成「個人雲」的戰略佈局，推出結合終端四屏的移動網際網路服務，目標瞄準蘋果的雲端服務(iCloud)，最後誰會勝出？兩岸雲端運算產官學研重量級代表齊聚，精闢分析兩岸雲端合作發展趨勢，保證精采可期。

結果到了現場變成了海峽兩岸"高新"產業合作研討會，討論四大領域，LED、面板、雲端產業、物聯網 (咦？...LED和面板跟對岸還有戲唱嘛？不是都被吃死死的？)，而且老實說聽完演講感覺還蠻失望的，不過不是對演講內容失望(因為本來就沒有太大期待~:P)，而是對台灣的發展感到憂心，很多題目其實在一兩年前都已經聽過，但是台灣都還停留在概念，願景的階段，而大陸很多都已經進入試營運，和大量佈建的階段，這個研討會美其名是大陸來台找合作夥伴，吸引陸資來台採購，但其實是大陸來這邊展示和來台招商吧。

研討會一開始是~~前~~前經濟部長王志剛(現在是外貿協會董事長)上台致詞，從"各位尊敬的領導、前輩，早上好～"開始，我就有一種置身在北京的感覺，接下來更是聽著大官們在互相吹捧對方的，感覺整個很糟糕。(ZZZZzzz,,,,,)

在各位大官表演完畢，簽了啥戰略合作意向書之後，四大領域的演講就各自帶開，我負責去聽的是物聯網，下面我把每間公司比較有趣的投影片內容列出來，研討會心得，用遊記寫法~:P

ZTE中興

中興的研究主軸比較偏向網路端，並且列出了許多目前物聯網在大陸的實際應用。

物聯網市場預估

物聯網的架構


上海世博會車輛監控應用


太湖藍綠藻監控


行動支付在大陸也是物聯網的領域

研華科技


漂亮的投影片但都是從IBM抄來老梗


介紹物聯網的定義

物聯網架構可以分成三層

最下層為「感知層」，由各種資訊擷取、識別的感知元件所組成 (Sensor、Meter...等)；中間為「網路層」，即各類無線傳輸技術；最上層為「應用層」，即物聯網的各種應用領域也就是軟體(管理系統平台)。硬體和網路本來就台灣的強項，只要把軟體好好發展，在搭配現在的雲端運算，一整個就非常適合台灣發展，但是....唉....


物聯網產業比重IDC提供

中華電信


物聯網的應用領域

中華電信跟物聯網相關的應用與產品


上海坤銳電子


2009-2013年中國手機行動支付成長趨勢


目前大陸主要行動支付的解決方案


坤銳電子展是他們的評價行動支付方式

根據他們的說法，根據最近觀察，在短期間內iphone也不會支援NFC，然後其他手機的支持度也還不高，所以目前最有可能與最平價的方法，就是使用外掛模組~XD



結論：

靠政府不如靠自己，在台灣軟體產業和雲端產業真的要好好思考如何與物聯網這個題目搭配，走出屬於台灣的路。

於 張貼者： 0 意見
標籤： ,

Google Apps Certification Program


阿阿阿真的很討厭考試，但是為了維持公司的Google panther資格，只好拼了，趁著個機會整理一下考試的規則和該看怎樣的資料。

Google Apps Certification Program 主要有分兩個部分：

身為技術人員，所以就被指派去考Deployment Specialist Exam，不過老實說，跟我們程式開發人員最有關係的只有Google Apps API Basics，只佔了2%的比重。

建議閱讀順序：

 重點：
  • 業務人員考試總共有50個問題
  • 技術人員考試總共有60-65個問題 (而且依照google apps的更新頻率更新，代表很頻繁)
  • 每次考試都會有不計分的考題 (用來測試新考題難易度)
  • 考試題目是複選提 (當遇到有more than one answer，系統會等你選完，才會繼續)
  • 業務考試時間兩小時
  • 技術考試時間兩個半小時
  • 如果考試沒有過，系統會寄Email建議你加強哪一個章節
  • 第一次考試沒過要隔14天以後才能考，第二次考試沒過要隔60天，第三次沒過要隔1年
  • 每次考試都要簽NDA確保不會洩題 
  • 證照每隔18個月(一年半)就要重新認證

所以對於證照內容，也只能僅限於此，因為不能洩漏跟考試問題和答案相關的任何內容，如果有要去取得證照的各位，只能說Goodluck~XD


Reference:
[1] 目前最新版是2012.5.18 公布的版本
於 張貼者： 2 意見
標籤：

2012年6月17日 星期日

資訊焦慮放大器(Information Anxiety amplifier)


其實資訊焦慮這個詞已經有點年紀了， 來自於1994年初版的一本書[1]，作者認為所謂的資訊焦慮源於「我們真正了解的」與「我們以為應該了解的」之間日益擴大的鴻溝。如果我們能夠領悟資訊的最終目的在於解決問題，那麼我們該追求的是，自己感興趣的問題是什麼？又如何尋找答案？資訊一旦無法滿足人們想要或需要知道的，我們就會更迫切與瘋狂的去找尋，深怕少看了什麼，漏掉了什麼，因此我們的病情會更加嚴重。

1994年(20世紀)如此，到了21世紀更是嚴重，有太多最新出爐的資訊，有太多的網路平台、Facebook、Twitter、Youtuble上流通的最新消息，有太多電視台在傳播新聞，有太多雜誌、書籍與傳播媒介在促銷全球最新發展趨勢，先不說現在上網買書太方便，很容易不小心手滑就買了一堆書(不過至少還有空間和金錢上的框架限制)，最恐怖的就是智慧型手機出現，又加深與放大了資訊焦慮的症頭，所以繼資訊焦慮(Information Anxiety)之後又產生了低頭族(Smartphone Addicts)，最恐怖的莫過於智慧型手機與社群網路所造成的共泛效應，想要隨時知道流行新知，想要隨時了解朋友狀態，想要隨時知道產業動態，想要.....，深怕漏掉什麼就敢不上潮流，或是顯得自己無知。

幾個低頭族(Smartphone Addicts)的跡象[3]：
1. 在廁所使用手機 (有..Orz..)
2. 從不關手機 (有..Orz..)
3. 可以盲打手機鍵盤以及有經常傳簡訊的習慣
4. 在公司開會時仍然在更新臉書 (有..Orz..)
5. 不想社交的時候開始使用手機 (有..Orz..)
6. 使用智慧型手機取代看電視 (有..Orz..)
7. 半夜醒來時習慣性檢查自己的臉書及推特狀態 (有..Orz..)

但是身為身為工程師處在日新月異競爭激烈的資訊產業，只要沒有感覺到進步其實就已經在退步了，資訊焦慮根本就已經是種職業病吧，自己深受其害就算了，其實我們根本是資訊焦慮病毒的散播者與製造者。

怎麼辦？這讓我想到兩個經典著作：

莊子養生篇：
吾生也有涯，而知也無涯。以有涯隨無涯，殆已！已而為知者，殆而已矣！
聖經-傳道書：

傳道者說：虛空的虛空，虛空的虛空，凡事都是虛空。
人一切的勞碌，就是他在日光之下的勞碌，有什麼益處呢？
一代過去，一代又來，地卻永遠長存。
日頭出來，日頭落下，急歸所出之地。
風往南颳，又向北轉，不住地旋轉，而且返回轉行原道。
江河都往海裡流，海卻不滿；江河從何處流，仍歸還何處。
萬事令人厭煩（或譯：萬物滿有困乏），人不能說盡。眼看，看不飽；耳聽，聽不足。
已有的事後必再有；已行的事後必再行。日光之下並無新事。
豈有一件事人能指著說這是新的？哪知，在我們以前的世代早已有了。

看起來似乎都有點消極？但是這些才真的真理，是資訊焦慮的解藥啊~Orz..

其實自己都知道多資訊都是不重要的(是虛空的)，是該放下追逐那些虛空的東西，但是真的很難辦到，所以我現在只能期許自己放慢閱讀的腳步，真的把看完的東西消化和內化後(至少寫個心得感想)，才能再看新的東西。

 (說完的這個當下..Facebook待閱讀訊息45條，Google Reader 待閱讀文章372篇......囧rz...)

Reference:
[1] 資訊焦慮 作者：理查‧伍爾曼
[2] 面對資訊焦慮症
[3] 淺談低頭族(Smartphone Addicts)與資訊焦慮(Information Anxiety)
於 張貼者： 0 意見
標籤：

2012年6月16日 星期六

AWS Trusted Advisor

Well 就在今天Amazon 宣布了一個Beta版的新服務，叫做AWS Trusted Advisor，這項服務的功能其實就是之前MeshCloud所提到的系統診斷分析功能，看到的當下我就想到上面那張圖，這些功能本來就是大廠(鋼鐵人，蝙蝠俠)應該要提供卻沒有提供，所以我們小廠(蜘蛛人)，就是找到這些空隙和Niche點，提供加值服務，但是如果大廠真的要自己跳下來做(那我們也只能哭哭)，的確會有不少壓力，不過也沒那麼悲觀，畢竟我們提供的是Hybrid Cloud的服務，所以除了服務Amazon的客戶，還可以同時服務其他IaaS的客戶，更何況，目前這個服務
These new features are available for all Gold and Platinum customers
只給大客戶~~~只給大客戶用~~~~，是要多大才算Gold and Platinum級客戶呢？[1]
呼 ～那我們來看看Amazon 將會提供哪些功能：

  1. Security Group - Open Ports - This check inspects your security groups and classifies each open port into one of three categories. Green ports for common protocols such as SSH and HTTP, Red ports for protocols that don't usually need to be open on internet-facing servers (e.g. port 1443 for Microsoft SQL Server), and Yellow for all others. (系統安全分析，看有沒有開哪些port是危險的)
  2. Security Group - CIDR Rules - This check inspects your security groups for rules that have errors which might allow more access than may be intended. Some people (me included) often confuse "/0"and "/32" addresses. (幫你檢查Rule是否有設定好)
  3. Reserved Instance Recommendations - This check looks at your billing and instance utilization history and recommends optimizations that could be achieved by the purchase of Reserved Instances. (檢視你的用量，建議是否要改用Reserved Instance)
  4. Unused Elastic IP Addresses - Elastic IP Addresses that are not attached to an Amazon EC2 instance will be flagged since you pay for them if you don't use them.(幫你檢查是否有申請了Elastic IP卻沒有使用)
  5. EBS Snapshots - This check looks for EBS volumes that don't have a snapshot, or which have only aged snapshots. The Red/Yellow/Green model is also used here: Red if there is no snapshot at all or if the most recent one is very old; Yellow if the most recent snapshot is somewhat old, and Green if the most recent snapshot is reasonably recent (we're still fine tuning the thresholds for these checks). (是不是每個EBS都有定期做Snapshot)
  6. Amazon EC2 Availability Zone Balance - This check identifies situations where Amazon EC2 instances are not evenly distributed across Availability Zones, or if (even worse) they are all in the same Availability Zone. The Red/Yellow/Green model is used to characterize the situation.(檢查機器是否過度集中，是否有把你的服務均勻的散在不同的Zone，以免一個Zone掛了，你的服務就停擺了)
  7. Elastic Load Balancer Optimization - This check determines whether instance allocation across Availability Zones for each Load Balancer is balanced.(檢查Load Balancer 的設定是否是最佳化)
  8. Service Limits - This check gives you visibility into the per-account limits and usage of things like instances, Elastic IP addresses, and other resources (in almost every case, limits can be raised using the appropriate online form). (你可以針對所有的Resource設定一個ThreshHold，然後Amazon會幫你確認是否有到達你設定的Threshold)
其實這些東西的確透過API 都很容易查到，下圖就是Amazon 在Blog上所畫的架構圖，唯一的差別就是我們不只是連AWS而已。






Reference:
[1] AWS Support Pricing
於 張貼者： 0 意見
標籤：

2012年6月15日 星期五

沒有搭配工具與方法的敏捷式開發？(Running Agile without specific methodology and Tools ? )

太極
軟體開發也許就像練太極拳一樣，最後的境界就是無招勝有招，但是在達到這個境界之前，我們一般人還是得先找位大師加入個門派拜師學藝，按照其心法與招式來好好練功，但是師父領進門修行在個人，所以在這段期間一定會遭遇挫折，會遇到瓶頸，你會懷疑，可能也會灰心，不過也就是痛過才更容易對那些心法有所領悟，也才有辦法跨越，這是沒有任何捷徑的，除非你是萬中無一的練武奇才。


而Agile與Scrum，對我來說就像心法與功法，舉例來說我們公司說我們是採用Agile(敏捷式開發門派)，主要依循的是Scrum與XP，不過套句Ken Schwaber 的話來說：

Scrum不是一個方法學，它是一個框架(Framework) 。

也就是說Scrum不像CMMI和PMP有很清楚的規範和SOP，他只有一個建議的運行準則，以及靠著實戰中不斷累積的經驗分享，這也是Scrum 的強處和痛苦的地方，就是你被迫需要根據你的團隊特殊的狀況，來進行調整，不是像拿到一本武功秘笈，照表操課就就會練成絕世武功，而且走火入魔的機率還很大~:P


此外通常在採用Agile與實行Scrum，根據許多前輩的經驗通常還會再搭配一些methodlogy和機制，例如TDD[1]、Build Automation、CI [2]、pair programming...等。這時候就有幾個問題出現了，到底是因為你要採用Agile才需要搭配這些methodlogy？還是這些本來就是軟體開發專案就該採用的方法？如果我今天不是採用Agile還需要使用這些方法嘛？

這幾個問題讓我想到，剛好在前一陣子ptt Soft_job版有個網友轉貼他的Blog"[心得] 為什麼軟體開發者需要在意軟體品質指標"，引起熱烈的討論(戰的很厲害)， 從一開始在討論為什麼要注意軟體品質，到後來戰火一路延燒，論戰的內容大略如下：
  • Test Case的定以與必要性
  • Unit Test是否有其必要性與功用
  • Test Automation(自動化測試)到底有啥益處
  • 到最常見的，寫程式都來不及了幹嘛要用TDD
也讓很多高手前輩浮出水面來討論(我承認我很孬，又怕戰，所以就沒在上面加入筆戰討論)，我只敢在這邊小聲的說說自己的想法，個人覺得這些機制和方法就像一個保護傘，你不用他當然還是有可能順利的完成案子(而且就我的經驗，可能都是一些一兩個人開發的小案子)，你用了當然也不能就保證你的案子就不會失敗，但是至少大大了提高勝率與降低失敗的風險，此話怎講！？

舉例來說，現在很難想像一間軟體公司沒有使用版本控管系統(不管是SVN、Git、Hg...等)，沒有issue tracking 系統，但是對於那種一兩個人開發的小專案，的確可能不需要版本控管，反正都存在你電腦裡，最多用時間分檔案資料夾；也可能不需要所謂issue tracking 系統，一切就靠email往來記錄；如果你一時興起要重構程式，就直接改，反正也不用跟其他人co-work.....所以當你小的時候，人少的時候，你的確什麼方法都不用考慮也可以過的好好，只要能交出東西就好。但是隨著系統越來越龐大，參與的人越來越多，你敢不用版本控管系統嘛？你能沒有issue tracking 系統嘛？再沒有寫足夠的unit test的狀況下，你敢任意重構系統嘛？或去改別人的Bug嘛？(通常只會越改越多Bug，越補越大洞)。

一般專案開發是如此，採用Agile更是如此，因為你會遇到更常變更的需求，更頻繁的Release和Demo，一旦當你release的頻率越來越頻繁，你不加入CI以及Test Automation的機制，我想你應該就會越聽到以下的抱怨，引自"程式設計師最常說的藉口"：

第 20 名：這很奇怪喔。
第 19 名：以前從來不會這樣啊！ (有做版本控管嘛？有用CI做Regression testing嘛？)
第 18 名：昨天明明會動的啊！     (有做版本控管嘛？有用CI做Regression testing嘛？)
第 17 名：怎麼可能~
第 16 名：這一定是機器的問題。 (有用放在CI上Build過然後deploy到測試環境嘛？)
第 15 名：你到底是打了什麼才讓程式當掉的？(請記錄在Issue Tracking，補入Test Case)
第 14 名：一定是你的資料有問題。
第 13 名：我已經好幾個禮拜沒碰那一段程式了。
第 12 名：你一定是用到舊版了。 (有做版本控管嘛？有用CI做Regression testing嘛？)
第 11 名：一定是巧合！為什麼這種壞運氣只讓你碰上。
第 10 名：我不可能什麼功能都測試到吧，有 bug 是正常的！ (這倒是真的~XD)
第 9 名：這個不可能是那個的原始碼！
第 8 名：這程式應該是會動的，只是我寫好後還沒做測試。 (有用放在CI上Build過嘛!?)
第 7 名：可惡！一定有人改了我的程式。 (有做版本控管嘛？)
第 6 名：你有檢查過你的電腦有沒有病毒嗎？
第 5 名：儘管這功能還不能動啦，你覺得他如何？
第 4 名：在你的系統不能用那一個版本的程式啦！
第 3 名：你幹嘛要那樣操作，都是你的問題。(請記錄在Issue Tracking，補入Test Case)
第 2 名：程式發生問題時你在哪裡？
第 1 名：在我的機器明明就可以動啊！(有用放在CI上Build過然後deploy到測試環境嘛？)

說真的很多風險和愚蠢的Bug都是不應該發生，是可以被避免的。

不過話說回來很多時候也不是工程師不做，而是不知道可以這樣做，或是不知道這樣做的好處，如果上頭又只是出張嘴說，好我們今天要推行TDD，但是沒有配套的工具和教育訓練，當然工程師一定會反彈，因為可能會增加他的工作量。

剛好這幾天在找資料，看到一篇文章"Bootstrapping an agile project with continuous deployment using cloudbees"，裡面有一個26min的影片，看完後除了深深佩服Henrik Kniberg [3] 行雲流水般的Coding能力外，最感到興趣的就是他Demo的那套系統" CloudBees"，這套系統許多的開發流程會需要用到的工具都整合在一起了，有興趣的人可以進去看一下影片，並且可以試著去了解這些工具如何幫助到自己的日常開發。


 Source:collabNet
 

如果覺得有用，或是有幫助，就可以試著在自己的公司與組織內導入這些系統和機制，自己當第一個願意嘗試的人，分享給大家，很多時候不要只是會抱怨環境和組織有多爛，都沒有人願意改變和嘗試，因為你也是這個環境和組織的一份子 ，你罵這個環境或組織爛，也就是罵到自己~:P


Reference:
[1] TDD - Test-driven development
[2] CI - Continuous Integration and Delivery
[3] Henrik Kniberg, Scrum and XP from the Trenches的作者

Update [2012.06.20] 覺得這個影片也很具代表性
於 張貼者： 0 意見
標籤：

2012年6月11日 星期一

隨選、訂閱式經濟(On Demand or Subscribe Economic)



相信大家應該都看過這個影片，介紹電子產品如何被設計成無法回收，觀察整個產品的生命週期，從生產製造到最後被當成垃圾丟棄，一路都在浪費地球資源以及毒害整個世界，但是我們除了拒用外是否有其他的選擇？今天看到一篇文章"從搖籃到搖籃”模式與訂用式經濟相融合"(Cradle-to-Cradle Meets the Subscription Economy) 給了我不少啟發與想法，裡面其中一段寫著：

Subscribe (訂用式經濟)的這一要素不應僅限於洗衣機，還可以延伸到電視機、洗碗機、家用電腦和工業設備等更多消費品。大多數公司已經開始訂用影印機和企業計算能力 （例如雲計算）。製造商也將在辦公室、車間內的機器以及車隊車輛內提供訂用式臺式電腦（尤其是鑒於ZipCar等服務的受歡迎程度）。

On Demand & Subscribe (隨選、訂用式經濟)其實有一個更古老的前身，就是租賃業， Google一下就可以查到不少資料，租賃業應該可以追朔到，西元前1400年，居住在地中海沿岸的腓基人發明了租賃這種新的商業貿易模式。當時有些商人從事水上貿易，另一些人對出租 船隻更感興趣，於是船主便租船給從事貨物貿易而不願或無力自備船隻的商人使用，船隻租賃便由此產生了。經過幾個世紀一直到現在，船舶租賃始終是資助水運業 務的一種主要方式，“造船不如買船，買船不如租船”，這句古老的格言就是對船舶租賃歷史最好的寫照。[1]

租賃的內涵也不斷發展和變化，租賃形式不斷創新，租賃交易合同也日漸複雜，租賃業從原始租賃向更高級的傳統租賃、近代租賃、現代租賃，到現在的隨選模式，隨便舉例，從傳統的房子、車子、衣服、OA、手機....等，能被租賃的範圍越來越廣，靠的就是科技的進步。

租賃業的本意為一方閒置不用而另一方急需使用的物品，承租人不願購買或無力購買、以付租為條件短期內使用之，仔細想想其實這樣的模式在哪裡被發揚光大？就是現代人的信用卡分期模式，想要享受某樣東西，但是無力馬上購買，所以用分期付款的方式先享受(等於是跟銀行租)，但是這樣換來的就試過度生產，過度消費的泡沫。

同樣的從前因為需求大於供給，所以企業有願意投入大量的資本買地蓋大樓廠房，預先投資大量花費在硬體與軟體， 努力的拼規模與拼產量。但是時代變了，現在是供給大過需求，企業都要想盡辦法的節省成本，能租就不要用買的，能外包就不要自己做，所以這是一個必然的趨勢。

在"從搖籃到搖籃”模式與訂用式經濟相融合"(Cradle-to-Cradle Meets the Subscription Economy)裡面也有提到：

誰將將成為那個首開先河的公司？我們認為，在2017年地球日之前，或者從現在開始五年內，會有一家製造公司提供“從搖籃到搖籃”的訂用式服務。沒錯，我 們目前面臨著嚴重的環境和資源制約問題。但綜合這兩種想法可能會讓一些業內領軍企業有機會做出改變，實現良性發展。最終，我們相信，業務利益幾乎和環境效 益一樣可觀。

所以不管是為了環保還是為了順應潮流，我們應該來好好研究與思考這種新的經濟模式，除了雲端產業外是否能更擴大到所有的產業，進而改變拋棄式的生產模型？白話一點就是什麼都用租的，用多少租多少，服務另外收費，此外廠商負責維護與回收再利用？


Reference:
[1] 融資租賃業的發展歷史回顧與現狀分析融資租賃業的發展歷史回顧與現狀分析
於 張貼者： 0 意見
標籤：

2012年6月10日 星期日

說好的背包魂呢! 一股淡淡的哀愁...




這張照片是2005年去瑞士法國自助旅行的背影，轉眼間就7年過去了耶！

真是懷念當初在少女峰下吃泡麵的日子~XD 

這幾天看到一篇文章"如何環遊世界一整年？程式設計師 Alex MacCaw 的背包客旅行故事 "整個就刺激到我。話說距離最後一次出國已經是一年前的事了！！(那時候是剛離開資策會去日本東京畢業旅行)

話說當初開Blog目標是要成為旅遊Blog，而且每年的目標都是要出國兩次以上(不管是出差還是旅遊)，怎知道現在，完全沒有梗可以寫，最近一次在國內旅行是去天馬牧場看羊駝，國外旅行已經超過一年沒出國了！！怎麼會這樣！！



於 張貼者： 2 意見
標籤：

2012年6月9日 星期六

Un-Bundling Business Models！What business are you really in?


Business Model Generation [簡中版] [英文版]第二張主要在講述各種Business Model 的Pattern，第一個Pattern 就是Un-Bundling Business Models，這章開宗明義說明Business Model主要就分成三種類型：
  • Product Innovation (產品創新)
  • Customer Relationship Management (客戶關係管理)
  • Infrastructure Management (基礎設施管理)
而這三種模式都有不同的Economic (經濟模式)，competitive (競爭模式)，與Culture(企業文化)，雖說在許多企業這三種模式可能都會同時共存，但是理想上還是應該適度的un-Bunding(鬆綁或是拆分？)，不然只會讓企業內部產生許多衝突與矛盾的地方。 


Product Innovation
Customer Relationship 
 Management
Infrastructure  
Management
RoleConceive of attractive new products and services and commercialize themIdentify, attract and build relationship with customersBuild and management facilities for high volumes,respective operational tasks.
Economics
Early market entry enables charging premium prices and acquiring large market share; 
speed is key.		High cost of customer acquisition makes it imperative to gain large wallet share; 
economies of scope are key		High fixed costs make large volumes essential to achieve low unit costs;
economies of scale are key
CultureBattle for talent; 
low barriers to entry; 
many small players thrive		Battle for scope; 
rapid consolidation; 
a few big players dominate		Battle for scale; 
rapid consolidation;
a few big players dominate
CompetitionEmployee centered; 
coddling the creative stars		Highly service oriented; 
customer-comes-first mentality		Cost focused; 
stresses standardization, 
predictability, 
and efficiency

Source: Hagel and Singer, 1999.[pdf]

然後，書上就以蘇黎士銀行，以及某大型電信公司為例，利用 Business Model Canvas來解說這些巨型企業，為什麼在內部充滿了衝突與矛盾，到最後怎麼因為拆分開來，而產生了不同的局面。如果單是用文字描述，可能還很難理解，但是透過 Business Model Canvas以及用不同的顏色代表不同的類型，就可以很清楚了解這其中的問題。

Source: Business Model Generation P61

看到這邊其實就給我很大的啟發，也讓我嘗試想要以此來闡釋我以前觀察到但是無法解釋的現象，一直以來透過觀察國外的一些軟體公司(尤其是以Open source 起家的)，我一直在思考，是什麼樣的文化和價值觀，可以讓一間只賣某個Component (核心元件)的小公司得以存活？是因為他們Business Model 定位很明確屬於Product Innovation？還是因為西方文化認為軟體的創造是有價值的？我願意花錢去買別人提供的技術和軟體來補我的不足，我願意把某些我雖然可以做，但是應該不屬於我核心價值的部份切分出去向外採購，自然而然就會產生軟體"產業"，與"產業鏈"，雖然還是有競爭，但是最後受惠的通常是消費者和顧客。

同樣都是創業，可是定義上可能卻差很多，一種是發現市場上有個需求的缺口，或是市場需要但是自己所在的公司因為商業考量無法提供這樣的價值與服務，所以會跳出來創業，另一種就是單純的想自己當老闆 (格局不同，結局自然會不同)

所以我看到的是中西方大不同 (也許我也只是看到表象，也歡迎糾正指教)，在西方社會是專業分工，把一個大公司不同的價值拆解出來，然後相互依靠，去取得自己不足的地方，也可以更專注在自己核心價值的地方，所以外包服務才那麼盛行 (你也可以說是為了Cost down，但是他們知道該保留什麼屬於自己的核心價值)

但是反觀東方，或者就直接說台灣好了，我看到的創業是大家誰也不服誰，誰也不信任誰，中小企業林立，但都只是把大公司的形狀，拆解成許多小的個體，但是本質與思維是不變得，沒有專業分工，沒有互相支援，只是有錢大家一起搶，所以才會被說是一盤散沙，然後最後都是殺成一片紅海。

其實在製造業(也可以說以生產硬體導向的高科技業) 或許還是看的到所謂的專業分工，與上下游供應練得整合的現象，但是仔細思考與深入探究，真的是這樣嘛？

樂觀的角度來看，或許可以說這幾年台灣企業家還是有在積極努力的想要轉型，以及學習國外經營管理的技巧，知道怎樣做對台灣或是對企業最好，不過以悲觀的角度會不會這只是因為在資本密集的高門檻下不得不因應的策略？抑或是因為酬庸與權力分配的關係，才會不得不拆分出子公司？是因？是果？抑或許只是美麗的巧合。

所以回到軟體業，相對起來資本密集度低，只要有一個人一台電腦就可以開工創業，所以更是亂象叢生，這也是到現在台灣軟體業還是死氣沈沈哀鴻遍野 (好啦大家也是可以把責任推給市場小，或是推給政府~)

其實也不用那麼悲觀~(都是你自己在悲觀的...囧rz..) 就像最近看到的appworks的Mr. Jamie，無私的在網路上分享一些東西(不管是宣傳或是教育)，然後最近台灣也有越來越多的講座與創業者聚會，只希望大家是真的可以互相幫忙，產生出價值鏈和供應鏈，為台灣的將來創造不一樣的未來。

(這一切都是小時候作文教育遺毒啊！只是寫個blog 沒事結尾都要搞扯到台灣未來嘛?XD)


[Update] 延伸閱讀：Unbundling Your Businesses / Marcos Nähr
Unbundling will increasingly become a pre-requisite for creating scalable growth platforms
這其實就是軟體設計的Loose coupling 概念吧~:P
於 張貼者： 0 意見
標籤：
訂閱： 文章 ( Atom )