[筆記] Overview of Spring Integration

Source:網路

Spring 出的玩意真是太多了，繼Spring Data後，最近又開始使用Spring Integration，那到底Spring Integration是用來幹什麼呢？ 要跟什麼"Integration"？

Spring 一開始設計的出發點，是要讓系統內部各個元件 (component) 和 building blocks 可以自由的組合，並且透過 Inversion of Control 達到鬆耦合(loosely coupled)的設計理念。但是一旦涉及到系統與系統間的整合，就不是 spring 當初設計理念的專長了。

為了增加Spring 在大型系統整合的能力，Spring 必須提出新的擴充功能(Extension)，並且達到以下目標：

• Provide a simple model for implementing complex enterprise integration solutions.
• Facilitate asynchronous, message-driven behavior within a Spring-based application.
• Promote intuitive, incremental adoption for existing Spring users.

為了達到這些目標，Spring 參考了  Gregor Hohpe and Bobby Woolf 的大作： “Enterprise Integration Patterns.” ，並且奉行幾個準則 (principles)：

• Components should be loosely coupled for modularity and testability.
• The framework should enforce separation of concerns between business logic and integration logic.
• Extension points should be abstract in nature but within well-defined boundaries to promote reuse and portability.

因此就我看來，Spring Integration 是想要提供一個類似 ESB (Enterprise Service Bus)的框架，核心的概念是想提供一個 Async 的 Message-driven architectures ，這點就跟AMQP的概念不謀而合，因此你可以直接使用Spring Integration 提供的介面與實作，或這是搭配其他的實作，就像我們所選擇的就是實作 AMQP (Advanced Message Queuing Protocol )的RabbitMQ來搭配。 (以上是我目前為止的理解) 整個核心概念就是下面這張圖：

Source: Spring integration

Spring Integration  AMQP  RabbitMQ

下圖以一個叫做eBond 的系統範例，來說明Spring Integration與AMQP 和 RabbitMQ 之間的關係。

Source: Using RabbitMQ, Spring AMQP and Spring Integration

嗯嗯不過我還沒搞清楚，何時要用Spring integration 的設定，何時要直接用AMQP的設定，這方面仍須研究清楚....


Reference:
[1] Spring Integration Overview

[筆記] HAL-Hypertext-Application-Language

Source: HAL

HAL 的用意是要提供 JSON or XML 一種簡單的Linking 機制，另外意圖就是想要變成HTML的API：

A standard linking format that general-purpose libraries and tooling like 'API browsers' can be built against.It provides a set of conventions for expressing hyperlinks to, and embeddedness of, related resources - the rest of a HAL document is just plain old JSON or XML.

延伸閱讀：

• JSON Linking with HAL. 
• Linking in JSON，

Reference:
[1] GitHub : hal_specification
[2] GitHub : hal_specification.md 
[3] Internet-Draft: JSON Hypertext Application Language

創業猶如自助旅行?

圖片來源：網路

這幾天被生火，開始規劃合掌村旅行，有了目標，開始會有期待，雖然會遇到許多困難(訂不到房間，機票很貴...等)，但是還是很快樂很開心，突然覺得創業跟自助旅行不也是很像嘛？

通常在朋友間談到自助旅行，可能常會聽到以下的情境：

• 聽別人在講時：
• 挖好厲害，好羨慕喔，不用趕行程一定很自由....
• 自己來規劃？
• 自找苦吃、做一大堆功課、不知道該怎樣開始、語言不通怎麼辦、會不會很危險...

同樣談到創業的話題，也可能常聽到以下情境：

• 聽別人在講：
• 挖做老闆耶，要賺大錢摟，不用像上班族一樣被人管....
• 自己要創業？
• 自找苦吃，倒閉怎麼辦？該怎麼開始？我不會技術耶.....

嗯我承認上面描述的是有點誇張和簡化啦，不過是不是有種熟悉的感覺？
再來不負責任的類比一下：

跟團 (在一般企業當職員)

行程都有人幫你打理好 (公司制度都很完善，你只要來上班就好)
有導遊引導，有領隊打理生活大小事 (管理階層都會幫你分配好工作，也有行政人員輔助)

機加酒自由行 (在一般企業當管理職)

雖說相對起來比較有挑戰，需要自己規劃要去哪玩，但是困難麻煩的旅行社都幫你處理好了。 (公司會給管理階層一定的目標和空間去發揮，不管是管理或是達到績效，但是還是在體制內，而且相對起來也是在公司的保護傘下)

自助旅行 - 參考網路範本 (加盟創業)

其實自助旅行也是有分等級的，對於許多第一次想要嘗試自助旅行的人，可能都會戰戰兢兢的到網路上收集許多前輩背包客的遊記分享，或者是買了許多旅遊書，然後就參照前人規劃好的行程，自己去實踐，我覺得這跟加盟創業蠻類似的。

自助旅行  - 流浪走天涯的背包客 (創業)

這就是自助旅行的最高境界了，因為可能要前往的地方沒有太多前人的資料可以參考，可能只能只有一個簡單的目標和粗略的規劃，然後就背著背包出發了，一路上可能會遇到許多困難攔阻，就只能硬著頭皮去闖，到時候再隨機應變。可能中途盤纏不夠還得停下來打工或乞討才能繼續往下一站前進，如果完成了壯舉，成功開發了某個行程和路線，之後就有許多人追隨或參考你的腳步。

不過說實在，青菜蘿蔔個有所好，真的沒有所謂好與不好，有些人就是比較喜歡輕鬆跟團，不一定每個人都適合自助旅行，就像有些人適合在一般公司企業內發展，不一定每個人都適合創業，就像前一陣子蠻紅的的一篇文章為什麼你不應該創業？。

自助旅行與創業的共通點

在網路上也剛好找到有人有跟我一樣的想法"5 Ways Backpacking Prepared Me for Startups "，作者Tim Berry [1]他認為創業和自助旅行有五個共同點：

1. It’s mostly about the people (就像自助旅行最重要的是旅伴，創業最重要的也是夥伴)
2. You compromise, improvise, and make do (你必須要不斷的妥協，改進，和嘗試)
3. You have to plan very well  (事先都必須要有完善的計畫與準備)
4. You also have to revise plans quickly (都必須要能隨時修改變更計畫)
5. You don’t get downhill without some uphill (旅行和創業都是有起起浮浮)

規劃行程就規劃行程咩...怎麼會扯到創業呢？！真是走火入魔....XD

Reference:
[1] Tim Berry： founder of Palo Alto Software. Founder of Bplans. Co-founder of Eugene Social. My most recent book is The Plan-As-You-Go Business Plan.

[筆記] NAT Traversal and Peer to Peer

Source: html5rocks

Cloud Computing 被翻成雲端運算，現在又被解讀成雲與端的整合 (其實還蠻貼切的)，最近又可以再擴大解釋成 - 雲與端、雲與雲、端與端之間的互動整合 (好像在勞口令)，像是Line和whatsapp 就是最好的例子，透過雲來協助端與端(手機與手機)之間的互動和溝通。

除了手機與手機之間的溝通，另一個應用就是物聯網(IOT)的概念，讓Device 與 Device 互相溝通，或是手機與Device 互相溝通。但是隨著端點(End Device)的種類越來越多，而端與端之間所處的網路環境也越來越複雜，這時就會遇到許多問題，其中NAT Traversal與穿越防火牆的問題，就是其中之一，還好再此之前傳統的P2P (IM、VoIP...等)相關應用領域就已經有相當多的解決方案和案例可以參考。

(把收集到的資料整理如下)

NAT穿透 (NAT traversal)

NAT穿越（NAT traversal）涉及TCP/IP網路中的一個常見問題，即在處於使用了NAT設備的私有TCP/IP網路中的主機之間建立連接的問題。

會遇到這個問題的通常是那些客戶端網路交互應用程序的開發人員，尤其是在對等網路和VoIP領域中。IPsec VPN客戶普遍使用NAT-T來達到使ESP包通過NAT的目的。

儘管有許多穿越NAT的技術，但沒有一項是完美的，這是因為NAT的行為是非標準化的。這些技術中的大多數都要求有一個公共伺服器，而且這個伺服器使用的是一個眾所周知的、從全球任何地方都能訪問得到的IP位址。一些方法僅在建立連接時需要使用這個伺服器，而其它的方法則通過這個伺服器中繼所有的數據——這就引入了頻寬開銷的問題。[0]

常用的NAT穿越技術就是下面兩者：

STUN

STUN全名 Simple Traversal of User Datagram Protocol through Network Address Translators (NATs)，(翻譯：NAT的UDP簡單穿越)，是一種網路協議，它允許位於NAT（或多重NAT）後的客戶端找出自己的公網地址，查出自己位於哪種類型的NAT之後以及NAT為某一個本地埠所綁定的Internet端埠。這些信息被用來在兩個同時處於NAT 路由器之後的主機之間建立UDP通信。該協議由RFC 3489定義。[1]

TURN 

TURN（全名 Traversal Using Relay NAT），是一種資料傳輸協議(data-transfer protocol )。允許在TCP或UDP的連線上跨越 NAT 或防火牆。TURN是一個client-server協議。TURN的NAT穿透方法與STUN類 似，都是通過取得應用層中的公有地址達到NAT穿透。但實現TURN client的終端必須在通訊開始前與TURN server進行交互，並要求TURN server產生"relay port", 也就是relayed-transport-address。這時 TURN server會建立peer, 即遠端端點（remote endpoints）, 開始進行中繼（relay）的動作，TURN client利用relay port將資料傳送至peer, 再由peer轉傳到另一方的TURN client。[2]

ICE

互動式連接建立（Interactive Connectivity Establishment），一種綜合性的NAT穿越的技術。互動式連接建立是由IETF的MMUSIC工作組開發出來的一種framework，可整合各種NAT穿透技術，如STUN、TURN（Traversal Using Relay NAT，中繼NAT實現的穿透）、RSIP（Realm Specific IP，特定域IP）等。該framework可以讓SIP的客戶端利用各種NAT穿透方式打穿遠程的防火牆。 如果UDP傳送失敗，ICE會改試TCP： 先是 HTTP，然後改試 HTTPS。此外如果使用STUN (UDP)直接連線失敗，ICE會切換道TURN (relay模式)，ICE uses an intermediary (relay) TURN server。所以 ICE 其實就是混和TURN 和STUN的行為模式的通訊協定。 [3]

Java Open Source Library

• JStun only work for UDP , example    
• PJNATH 
• stund  
• stun4j 
• turnserver 
• ice4j

延伸閱讀：

• NAT Traversal, part 0 
• NAT Traversal, part 1 – NAT Behavior
• NAT Traversal, part 2 – STUN
• NAT Traversal, part 3 – TURN
• 穿越防火牆技術

Reference:

[0] WIKI - NAT Traversal
[1] WIKI - STUN
[2] WIKI -TURN
[3] WIKI - ICE

同樣都是Message Queue 到底AMQP跟JMS 有什麼差別？

Source: U2Canvas 2012

不知道最近寫的blog算不算是策展(Curation)的一種，正因為我遇到一些問題，有一些疑問，所以我就自問自答的整理了網路上收集來的資料(Reference)，用自以為類似寫論文的方式整理這些資料，並且嘗試消化吸收，看看可不可以提出自己的一些見解？ 嗯這都是題外話~XD
今天要自問自答的題目是 -  同樣都是Message Queue到底AMQP跟JMS 有什麼差別？ AMQP 優點在哪?

Message Queue

在介紹JMS和AMQP之前先說一下什麼時候會需要用到Message Queue，就如同下圖所示，如果你今天需要一個Reliable (保證傳達) 且 Async (允許非同步) 的訊息傳達和交換方式，這時候你就需要Message Queue，而首選就是AMQP。此外對於Cloud 和SOA 來說 AMQP也是佔了很重要的角色。

 Source:AMQP and the future of web messaging

JMS的是什麼？

JMS 是Java的標準 API 使用兩種機制來傳遞訊息：

• store-and-forward
• publish/subscribe

但是 JMS 就像許多JSR的標準一樣，只是制定Interface以及行為模式，所以本身並沒有實作，必須倚賴其他的3rd-party實作，此外就如同它的名字，它只能在Java的環境使用，所以不適合跨平台跨系統的整合。而AMQP的出現就是為了要解決這個問題，不但實作了JMS的標準更提供了API for C, C++, Python, C# or any other language on Linux, Solaris, Windows, Z/OS, etc... [1]

AMQP 的緣起

AMQP 全名 Advanced Message Queuing Protocol 是一個由OASIS公開的標準，它誕生是在 2006年 由金融業 JP Morgan 的 John O;Hara  了解決異質平台訊息交換所的問題所提議，目的是要建立一個標準的協定與平台 - 包含資料的結構(binary wire-level protocol) 、如何傳遞，另外也定義了以下的特點 message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability and security.[1]

AMQP與JMS主要差異

這一段就直接貼原文了，這種東西真的很難翻譯..@@

AMQP mandates the behavior of the messaging provider and client to the extent that implementations from different vendors are truly interoperable, in the same way as SMTP, HTTP, FTP, etc. have created interoperable systems. Previous attempts to standardize middleware have happened at the API level (e.g. JMS) and this did not create interoperability.[3] Unlike JMS, which merely defines an API, AMQP is a wire-level protocol. A wire-level protocol is a description of the format of the data that is sent across the network as a stream of octets. Consequently any tool that can create and interpret messages that conform to this data format can interoperate with any other compliant tool irrespective of implementation language.

AMQP主要定義了以下主要元件

AMQP (note that Rabbit works with many protocols including STOMP, HTTP, HTTPS, XMPP, and SMTP), here are some basic component descriptions:

• Exchange 
• The entity within the server which receives messages from producer applications and optionally routes these to message queues within the server
• Exchange type 
• The algorithm and implementation of a particular model of exchange. In contrast to the "exchange instance", which is the entity that receives and routes messages within the server
• Message queue 
• A named entity that holds messages and forwards them to consumer applications，Queues are bound to exchanges with patterns
• Binding 
• An entity that creates a relationship between a message queue and an exchange. Message are routing to queues by matching routing keys against binding patterns.
• Routing key 
• A virtual address that an exchange may use to decide how to route a specific message. Message are published with a routing key.

所以主要的元件如下圖所示：

所以AMQP最主要就是多了Exchange的機制，除了 store-and-forward、publish/subscribe外還多了許多的Routing 方法 [5]：

• Direct Exchange

• Fanout Exchange 

• Topic Exchange

• Header Exchange
• System Exchange    

Refernece:
[1] How is this different from the Java Messaging Service (JMS)?
[2] Advanced Message Queuing Protocol
[3] Migrating From JMS to AMQP: RabbitMQ, Spring, Apache Camel, and Apache Qpid
[4] Introduction to amqp messaging with Rabbitmq
[5] Exchanges

[Design Pattern] Facade和 Front-controler的差別?

圖片來源：網路

一休和尚的名言："考考你，盡管考"，但是我是一考我就倒....Orz...Facade和 Front Controller 一時間也講不出個差異，於是上週老闆出的作業，就是搞清楚Facade和 Front Controller的差別和定義。話說我剛進公司時，好像也跟一堆人討論過，但是沒個結論...XD

上網Google 一下wiki其實很容易就可以知道，Facade 就是透過開放一個介面，可以把很多邏輯，和行為都封裝在裡面，用戶只要Call 這個function，就可以完成動作，並不需要知道裡面到底Call了哪些東西做了哪些行為。

圖片來源：wiki

圖片來源：wiki

而 Front Controller pattern 是使用單一物件，來處理接收其他系統所傳來的Request，通常Front Controller 會是瓶頸所在。[2] 另外Wiki上的定義：

This object can carry out common behavior, which can be modified at runtime with decorators. The handler then dispatches to command objects for behavior particular to a request.

所以Facade 和Front Controller到底有什麼不一樣？

A facade is on the other hand rather used to wrap other methods/services to provide a unified interface, hide complexity or reduce dependency on external systems. A facade is a thin wrapper that shouldn't contains any logic except the logic used to translate between the two systems. Front Controller has no such requirements.

嗯...所以感覺之前好像都用錯?....囧rz...


Reference:
[1] Wiki - Facade Pattern
[2] Front Controller

我心目中理想的訂票網站Skyscanner

圖片來源：Skyscanner

大概是我太久沒有規劃行程，和自助旅行了，對於找機票我的印象都還停留在："背包客-機票比價"、"玉山票務" 、"ezfly" ...之類的網站，不過這幾年似乎相關的網站如雨後春筍般的出現"FunTime"、"wego"，而且許多老牌的旅行網站的網頁和功能也都有不錯的改進"雄獅旅遊"、"桂冠旅遊" (Google 關鍵字廣告打很兇)。

國內這類型的網站都如此蓬勃發展，就更不用說國外了，國外這類型的網站就真多到眼花撩亂了："kayak"、"Matrix Airfare Search"、 "bookingbuddy"...等。

話說前一陣子Fin 在看設計相關的網站，也有給我看到hipmunk 這個網站，以時間軸的概念來顯示，列出不同的價位的機票，根據不同轉機地點，不同航班，列出需要花費的時間來比較，這對商務人士來說很重要，不過對於背包客，我想應該是越便宜越好，用時間換取金錢(畢竟時間就是金錢啊朋友~) 不過這堆一般人來說應該還是太複雜了。

今天在上網找機票時意外發現這個網站 - Skyscanner，這個網站就很符合我心目中的飛航路線規劃網站，簡單列出以下優點 (職業病發作!!順便來分析一下他的Business Model)：

全中文化介面

雖然對於喜歡自助旅行的人來說，英文介面雖然不是什麼太大的問題，但是有中文介面(記不是簡體字，也不是大陸用語!)，就先加分了。

圖形化顯示所有航班組合

我這邊所指的圖形化顯示，是指航空公司的名字，看到KLM的字，跟看到KLM的icon對於使用者來說，哪一個辨別度比較高？(我個人覺得是icon)，然後所有需要注意的地方都會標示特別的顏色，比如說：比較時間、比較航空公司、經停1站、訂位、購票Agency...等。

圖形化的價格比較

因為每家航空公司都有自己飛行的航班時段，所以不一定每天都有班機，因此這個view是以時間為縱軸列出：每天是否有航班，然後航班的價錢Range 是在哪裡。

地圖導覽功能

我覺得這是他最最最方便的地方！對於許多人來說，誰會知道要去某個國家玩該飛哪個機場，很多時候對於機場在哪一點概念也沒有，更遑論去背機場的代號啊....=_= ，我就覺得許多網站都是要我們直接輸入機場代號根本是瘋了！ (好啦常出國常買機票的，還是多多少少會背幾個代碼)。而skyscanner 解決了這個問題，你要去西班牙馬德里？不知道有啥機場？那我就直接給你看地圖，讓你知道有哪些機場，分別在哪裡。(這真是太方便啦~~)

 

最後IT's Free~~(不過這也是缺點啦~)

因為這個網站目前看起來是採用靠廣告維生的Business model (不過至少廣告擺的很整齊，跟網站主軸也很有關係，不會讓人討厭)， 由於他不是靠仲介費在賺錢，所以最後要買機票的時候還是會導到某個購票網站(目前看起來都是國外網站 Orz..)，如果他這段可以也自己包起來作，應該會更方便吧？(不過建置成本可能也更高)

[Update] 2012/07/25

要先聲明，我只是喜歡這個網站的設計和功能，所以我自己也還沒用這個網站訂過機票，因為今天一個在國外的朋友看了我的介紹，就很勇敢的嘗試這個網站...XD

以下是她的描述：

After press booking button, it will redirect to other web site (Not sure if it is true or fake)
And after u provide everything include credit card detail.
The website say, am booking, cannot guarantee your purchase...
Pls wait.....like this.

嗚...只能為她禱告，可能系統整合還不完全，或是速度比較慢所造成~如果有網友有使用經驗，歡迎分享一下使用心得。

[旅遊情報] 合掌村2013 點燈日

圖片來源：網路

好再這樣下去不是辦法，再不出去都不像我自己了！！是該開始規劃下一次旅程了，這次要動用的Quota是長榮航空的里程數，長榮航空的淡季時間：1月01日-1月06日，2月05日-2月15日，所以能選的時間應該就只有第1回到第4回，但是為了夜長夢多，就先以1月19日為目標吧！！(前提是要訂的到民宿....)


情報-交通方式與訂房：

白川很多民宿都是留守村中的歐基桑歐巴桑在打理，一聽到你不講日語 會不敢接客，曾問過原來是因為他們怕無法溝通而影響他們對客人的服務品質...而願意接待外國人的 很早就會客滿了(如:幸工門koemon)

圖片來源：ライトアップ照明時間

參考網路上的玩家的玩法(似乎也是個吃到飽行程)，預計行程：

1/18 第一天：台灣桃園機場→日本小松機場→金澤    (宿：金澤加賀湧泉)
1/19 第二天：金澤→白川合掌村  (點燈日)                  (宿：白川合掌村民宿)
1/20 第三天：白川合掌村→飛驒→古川→高山            (宿：高山民宿)   

1/21 第四天：高山→富山→金澤                                 (宿：金澤加賀湧泉)
1/22 第五天：金澤→日本小松機場→台灣桃園機場

不過老實說對於這些地方的地理位子一點概念都沒有，還好有Google map，大概可以知道這幾個景點的相對位置。

從小松空港出發，第一天到金澤旅遊，車票大約1100日幣

 圖片來源：北路鐵道

第二天坐濃飛巴士(金澤-白川鄉單程1800￥巴士票)到合掌村約70min(天氣好的話) ，
，第三天玩合掌村，飛驒、古川、高山 (白川鄉-高山單程2400¥巴士票)，然後再回到金澤，話說富山就是立山黑部所在，不過一月應該沒有開放，所以應該不會去吧？

Update: 如何上網訂濃飛巴士車票

不過這個路線，要怎麼玩還得再精算一下[B4]：

高山--白川鄉間單程交通費是2400 日圓，來回一起買可打折，只要4300 日圓，如果你持有「飛驒路フリーきっぷ」套票買來回票還可再打九折(就是4300 * 0.9 = 3870)，(關於「飛驒路フリーきっぷ」套票，請見 「飛驒路フリーきっぷ」套票使用心得 一文)，而金澤--白川鄉交通費比較便宜，片道是1800 日圓，來回一起買也有優惠，總共3200 日圓，不過這段即使持有「飛驒路フリーきっぷ」套票也是不打折的喔，如果你是一條線買下去(例如：高山-->白川鄉停留-->金澤) 這樣票價全部都是片道價格來算，沒有打折喔～～

拍照卡位須知[B5]：

要先跟展望台前的阿伯拿整理券，整理券並不是讓你一次拍個夠，因為帶重裝的人非常多，所以是有分時段的，如果你想拍到華燈初上的合掌屋點燈景色，要拿哪個時段最佳呢？這很難說～得看當天天候狀況來決定..，點燈是從傍晚5:30 開始，不過那時天色通常都還是亮的，所以看不太出來點燈的感覺，如果天氣大好，天會暗得晚，你可以考慮拿6:00~6:15 或者 6:15~6:30 這兩個時段

整個都是看運氣的行程....囧

Reference:
1. 長野縣最重要的巴士集團網站
2. 查電車車班
3. 濃飛巴士
4. 白川鄉觀光協會
5. 小松機場
6. 民宿資訊


Blog Reference:
[B1]. 小松機場到金澤的巴士
[B2]. 濃飛巴士買票方法
[B3]. 2013拍照排隊須知

[閒聊] 敏捷式開發的領導與管理

圖片來源：少林足球

前一陣子有一系列的文章在討論，管理與領導，例如MMday："軟體公司該這樣做：領導你的員工、而非管理他們"，孤獨木："軟體公司怎麼會不需要管理員工？"。

就我的認知是管理是建立制度和標準，讓大家都有一個可以遵行的遊戲規則，而同樣的制度和遊戲規則，卻會因為領導風格的不同而給人不同的感覺，和有不同的結果。如果硬是要套梗，那就好像外功和內功，管理制度是外功，是可以速成的，可以學習模仿的，但是領導卻是一種內功，除了資質天份外，是需要經驗累積修煉而來的。所以只要有制度大家都可以來管理，但是要管理的好，要發揮效果，就必須要靠領導。

那到什麼是好的領導？到底該怎麼燃起員工的熱情呢？這跟敏捷式開發又有什麼關係？因為敏捷式開發最重要的精神的就是熱情和自我管理，所有的管理和監督都是同儕間自發性的，不是由上而下的，他也沒有一個很明確的SOP，所以需要Scrum master 領導(或說是幫忙)的成份更大。

參考成功敏捷式開發的十個要點 [2]這篇文章所列出來的十點，光是看就知道Agile 真的是知易型難的方法：

1.  找一塊真的白板
2. 啟動資料收集並使用統計資料
3. 聘用一位教練或顧問
4. 別光說不練
5. 為每個人提供培訓並進行小組討論
6. 要激勵、要引導、不要生拉硬拽
7. 實施敏捷模式的動機
8. 流程與技術，兼而有之
9. 使需求更清晰、更乾淨
10. 結構變更——功能組

其中第六點就有提到：

如果你身處管理層，那你需要營造一股合力來推動變更：一方面員工對於變更的熱情自下而上，另一方面來自管理層的支持自上而下，一拍即合。筆者覺得自上而下地硬拽敏捷模式無異於失敗，員工自然而然地會去質疑自上而下的強制變更。

而所謂的管理階級在敏捷式開發所扮演的角色，會比較像是這一篇文章所提到的僕人式領導風格，Larry C. Spears1是Grennleaf Center for Servant Leadership的總裁兼CEO，他強調了以下對發展個人僕人式領導風格的關鍵要點 [1]：

• 關注員工成長：僕人式領導者相信人有一種與生俱來的價值，它是超越其作為工作者的貢獻的。因此，他/她應該培養員工的職業素養、關注其個人精神發展。比 如，為組織的員工設立基金或提供相應資源來助其職業發展。僕人式領導者也會鼓勵每個員工獻計獻策，積極參與決策。
• 建設團隊：僕人式領導者會採取各種方法在其組織內部建立強大的團隊，並在各部門及機構間發展壯大真正的團隊。
• 解決問題：僕人式領導者要鼓勵和支持每個人的成長發展就必須努力幫助大家解決問題、緩和矛盾衝突。這就形成了一種商業文化，其工作環境是有活力的、有樂趣的、並且是不畏懼失敗的。
• 傾聽：他要積極傾聽下屬的意見並且支持他們。僕人式領導者尤其要關注那些沒有說出來的意見。這就意味著需要依靠他的內在去傾聽身體、神情和心靈的話語。
• 同理心：僕人式領導者要試圖理解並與他人產生共鳴。員工不僅是作為雇員，他們更是需要為其個人發展而得到尊重和欣賞的一群人。因此，領導工作是一項特殊的工作，它可以最終為企業創造一種競爭的優勢。
• 洞察力：僕人式領導者需要獲取一種普遍洞察力，尤其是自我洞察力。他需要能夠從更完整更全面的角度來看待問題。這樣他才能更好的理解道德和價值。
• 循循善誘：僕人式領導者不會利用自己的權勢和地位來脅迫別人順從；而是會說服他的屬下。
• 構想：僕人式領導者考慮的不僅僅是日常的事物。也就是說他具備一種能力，能夠不僅僅看到日常的運營，更重要的是關注於長期經營目標。
• 前瞻性：前瞻性是一種能夠預測未來可能發生的情況。通過瞭解過去，僕人式領導者能夠更好的理解目前的現實狀況。同時也能夠使其明確未來可能產生的結果。這一特質也同構想能力密切相關。
• 管理層職責：管理層成員有責任維持其機構的社會形象和社會責任。

要引導，引導員工心中燃起心中的一團火！ 不過是要熱情，不是發火...Orz..
要修煉的路還很長啊....有興趣的也可以參考 Bossless company [3]這個投影片，裡面有提到許多的Referene case

Reference:
[1] 領導力大挑戰
[2] 成功敏捷式開發的十個要點
[3] Bossless company

是否可以關閉SSH Tunneling 的加密或是降低加密等級

圖片來源：網路

大家一定覺得很奇怪，SSH的存在就是為了要有一個安全加密的通道啊，怎麼會有人想要關閉加密功能或是降低加密等級呢？怎麼會有這樣的需求呢？在解釋之前先來先舉幾個會用到SSH Tunneling 的正常案例：

• 情境一："反向建立 SSH Tunnel、免 VPN 連回公司"

• 情境二："Port Forwarding with SSH" 

所以建立SSH Tunnel的主要用意就是建立一個通道，想辦法可以由外界進入一個受限制的網路，看圖片比較有感覺。

圖片來源：網路

圖片來源：網路

由這張圖就可以看到，透過 SSH Tunnel 傳遞的資料都是有受到加密保護的，一直到離開SSH Tunneling 到達受限制的內網(相對起來也是受信任的內網)。

 圖片來源：網路

這時候問題來了：

1. 如果我要連線的Device (Embedded System) cpu 不夠力怎麼辦?是否可以關掉？
2. 加密對於速度也會有影響，那要如何增加速度呢？
3. 加密到底是用麼演算法在加密呢？

所以我在網路上找到幾個答案：

1. 有加密和沒加密速度可以差到86%

RFC 4253 specifies that, during handshake, client and
server can agree not to use any bulk encryption.
In other words, the encrypted transfer speed is *** 86% SLOWER ***
than the unencrypted transfer speed.

2. 透過patch 的方式：hpn-ssh ，的確可以關掉

3. 就是降低加密等級
---------------------------------------------------------------------------
You cannot disable encryption, at least not in any standards-compatible way. You can pick weaker and/or faster ciphers if you're really worried about overhead. ARCFour and Blowfish are pretty fast. DES is slow.

For OpenSSH:
man ssh_config
man sshd_config

The following ciphers are currently defined:

      3des-cbc         REQUIRED          three-key 3DES in CBC mode
      blowfish-cbc     OPTIONAL          Blowfish in CBC mode
      twofish256-cbc   OPTIONAL          Twofish in CBC mode,
                                         with a 256-bit key
      twofish-cbc      OPTIONAL          alias for "twofish256-cbc"
                                         (this is being retained
                                         for historical reasons)
      twofish192-cbc   OPTIONAL          Twofish with a 192-bit key
      twofish128-cbc   OPTIONAL          Twofish with a 128-bit key
      aes256-cbc       OPTIONAL          AES in CBC mode,
                                         with a 256-bit key
      aes192-cbc       OPTIONAL          AES with a 192-bit key
      aes128-cbc       RECOMMENDED       AES with a 128-bit key
      serpent256-cbc   OPTIONAL          Serpent in CBC mode, with
                                         a 256-bit key
      serpent192-cbc   OPTIONAL          Serpent with a 192-bit key
      serpent128-cbc   OPTIONAL          Serpent with a 128-bit key
      arcfour          OPTIONAL          the ARCFOUR stream cipher
                                         with a 128-bit key
      idea-cbc         OPTIONAL          IDEA in CBC mode
      cast128-cbc      OPTIONAL          CAST-128 in CBC mode
      none             OPTIONAL          no encryption; NOT RECOMMENDED
----------------------------------------------------------------

Reference:
[1] Disable encryption ssh

臺灣在地IaaS的5大問題- 雞生蛋蛋生雞

圖片來源：網路

前一陣子ithome 整理了一篇 臺灣在地IaaS的5大問題：

問題1：頻寬價格比美國貴3倍
問題2：欠缺自助式平臺，企業重新申購還得等半天
問題3：資源選項切分得不夠細緻，難以貼近使用情境
問題4：未釋出API，降低企業控管能力
問題5：缺乏企業的信賴感

其實最大的問題，也最難解決的問題就是第一點和第五點，反而第二、三、四點都好解決，這些都只是都只是技術問題，目前沒有提供這些功能也是因為目前台灣的廠商所提供的IaaS 幾乎都不是自己開發的，或是拿半成品來改造的，所以當然不會有這些功能，要提供這些功能他們可能也只能兩手一攤。(快來找我們幫忙開發啊~XD)
 
對於第一點，網路太慢太貴的問題，之前已經不知道有多少文章在討論這個問題："2010瘋雲端？ 頻寬不足將是最大罩門"、"台灣寬頻全球次貴 速率倒數第4"、"如何挑選適合的 Hosting Plan?"、"台灣頻寬品質倒退嚕, 韓國已經是台灣的 5 倍快, 我們的政府 … ?"、"台灣頻寬太貴是塞車兇手？《暗黑3》官方聲明有隱情"，對於這個問題我們一般企業一點辦也也沒有，只能看中華電信的臉色吃飯了，但是老實說，就算網路頻寬和價錢問題解決了，IaaS就沒問題了嗎？

真正最難的在於第五點所謂的企業缺乏信賴感，因為這其實是個雞生蛋蛋生雞的問題，為什麼企業缺乏信賴感？因為賣這個服務的人自己都沒有在使用這個服務，就像賣水果的自己都不敢吃自己種的水果那誰敢吃！！但是如果要自己公司內部先使用這些服務(IaaS)然後經過證明夠穩後，在Release 出來給大家使用(Amazon & Google 模式)，那除非本身有非常大規模的IT需求才撐著起這些花費，我想的到的除了電信業外，大概就屬7-11或是PChome 有可能有這樣的財力，和這樣的規模，養自己的機房，使用與測試自己的基礎設施？但是放眼望去我想台灣應該也沒有CEO像貝佐斯這樣有guts和遠見吧。

然後這幾天看到這幾篇文章，真的非常贊同，他們都不約而同的把真正的問題點出來，很多時候在於市場經濟規模："真心話系列－想在台灣發展軟體事業，會異常辛苦，但是請不要放棄"、"台灣的環境影響了網路創業發展嗎"、"台灣雲端的困境"。

MMDays提到：

重點就是在於「規模經濟」，台灣的電信業者和硬體廠看到雲端運算的典範轉移，就想要用「複製」的方式打造出「雲」，結果在根本上忽略了這些「雲」是國外網 路產業持續演進、自然發展出來的「雲」，而不是複製出來的「人造雲」，兩者落差極大。大家都在搞自己的雲端，台灣規模經濟就出不來。

所以解決之道就是先把頻寬搞好(夠快夠便宜)，讓服務和軟體開發商可以很容易的把服務推到全世界，以全世界的市場為市場，這時才能堪稱在"發展雲端市場"，這時候才能享受到軟體與雲端低成本傳播與複製的優勢。

有了市場和用戶，才有可能遇到大量的資料，才會遇到scale out/up的問題，這時候architecture與design才能發揮作用，台灣軟體業與軟體人才也才能真的累積到這方面的經驗，不然永遠是小規模經營，吃不飽餓不死，得過且過的經營著，也沒多餘的雄心壯志與財力想要去架構更好更快的系統......

 一切都是雞生蛋彈生雞啊~~要怎麼斬斷這個惡性循環呢?

邁向自動建置佈署之路(2) -安裝 Jenkins

接續前一篇"邁向自動建置佈署之路(1) "的討論，讓我們來複習一下做到Build Automation以及Deploy Automation到底有什麼好處？根據經驗可以提高開發效率，以及產生品質比較好的程式碼。不過我說的可能沒啥說服力，這時就要請出大神 - 根據約耳測試(The Joel Test) 裡面提到的幾個問題，就可以了解到你們軟體開發的成熟度，以及可以產出較好品質的程式碼機率，Yes 的回答越多，代表機率越高，No的答案越多，代表機率越低。有興趣的可以去翻一下"約耳趣談軟體──來自專案管理的現場實錄"

• 你有做版本控管嘛 (Do you use source control?)
• 你能只要一個步驟就可以建出結果嗎 (Can you make a build in one step?)
• 你能每天都至少有一個Build嗎 (Do you make daily builds?)
• 你有用Issue tracking system嗎(Do you have a bug database?)
• 你會先解決Bug再寫新的程式嗎 (Do you fix bugs before writing new code?)
• 能隨時取得一個最新的專案進度嗎(Do you have an up-to-date schedule?)
• 有Spec嗎(Do you have a spec?)
• 程式開發員在良好的工作狀態嗎(Do programmers have quiet working conditions?)
• 有花錢在能幫助你的用具上嗎 (Do you use the best tools money can buy?)
• 你有測試人員嗎 (Do you have testers?)
• 你在面試時有出上機考題嗎(Do new candidates write code during their interview?)
• 走廊使用性測試 (Do you do hallway usability testing?) [1] 

其中用紅色High light起來的這兩項，就是跟Continuous Integration (Build Automation)有關，使用CI不但對於開發者有好處，對於管理者也非常有幫助[2]：

• 不懂技術的管理者，可以光看報表就知道系統的健康狀況。
• 團隊開發時可以及早發現，在整合上是否有所問題。
• 每個developer早點嗅出程式與系統的壞味道。
• 可以讓整個團隊成員有共同的基底、共同的標準、共同協同合作的平台。
• 可以貫穿整個系統開發生命週期，為了品質所花的任何一份力氣，都不會白費而有所累積。

關於CI的好處與介紹可以參考"軟體工程]持續整合 (Continuous integration, CI) 簡介"，這位網友整理的很棒，這邊就不多介紹，所以今天要介紹的是我們使用的工具Jenkins。Jenkins

安裝Jenkins

進入Jenkins官方網站下載最新的jenkins。Jenkins 除了提供的war形式的下載，同時也提供各種作業系統的安裝檔，最簡單的安裝方式，就是將jenkins.war拷貝到tomcat_home的webapps目錄下，啟動tomcat。在流覽器的位址欄中輸入http://localhost:8080/jenkins就ok了。如果是Startup的小公司，甚至沒有自己的機房，我推薦這篇文章 "為小團隊的CI流程建立一個簡單的開始 ﹣架上雲端，讓一切自動化吧"。

設定Jenkins Cluster

如果公司內部只有一個專案，或是你的專案規模還算小，只跑單一台的Jenkins應該是綽綽有餘，但是如果公司內部專案規模大，模組又多，你又只有跑單一台Jenkins Instance，那你就會發現你所有Build的工作都處於排隊等待的狀態，因此還是建議還是要建置成Cluster，也就是建置 n 台同樣的 build slave，至少也要建立一個Master與一個Slave。

安裝常用Plugin

Jenkins 還有一個蠻強大的功能就是擁有許多3-party 的Plugin，像是SVN、Maven、Cobertura (Code coverage report)...等，只要進入他的Plugin 管理介面，裡面就有各式各樣的plugin ，可以裝一些自己有興趣的來試試看。

設定Jenkins Dashboard

Jenkins還有一個蠻好用的功能就是Dashborad，我們可以依據專案屬性類別，把每個要Build的專案分門別類，比如說公司內部的共用Libray，或是特定的某些專案群組。此外還可以設定這個Dashboard 要顯示那寫指數，像我最常看的就是code coverage 和 待辦事項數量。

好都準備好了，下一篇就來講怎麼做到Deploy automation

Reference:
[1] 「走廊使用性測試（Hallway usability）」是指在走廊攔住下一位經過的人，然後逼他試用你剛寫好的程式。如果能攔下五個人並且試用完成，就可以發現程式中95%應注意的使用性問題。
[2] 軟體工程]持續整合 (Continuous integration, CI) 簡介http://www.dotblogs.com.tw/hatelove/archive/2011/12/25/introducing-continuous-integration.aspx

[隨筆] 技術這種東西沒有進步的感覺就是不行了

圖片來源：醫龍20集

前幾天跟到國外發展的前同事聊天，有很深的感觸，腦袋裡千頭萬緒一時間也整理不出個完整的東西，先列出幾個點，看看之後會不會有更多的心得：

對於新技術的行銷與包裝

對於創新技術公司而言老外真的很會包裝和行銷概念... (參考：運用影片和動畫來宣傳與解釋網站概念)

大企業 Vs. 創新公司的思維與做事方法 

在國外大企業的開發方式是使用所謂正規軍的開發方式，但是新創的中小企業需要的卻是Hacker的技術，要創新要突破，要用最省錢的方式得到最好的效果。

因此很多新創公司大都只找資深有經驗的工程師或是Hacker，反而是大公司才會比較希望從剛畢業的開始培養。

軟體公司對於軟體的熱情與實力

在國外，敢開軟體公司都是很有實力和熱情的，創辦人中至少有個是Hacker等級的，不像台灣可能阿貓阿狗都來開軟體公司。不過也不是說阿貓阿狗不能想開軟體公司網路公司，重點式創辦人中至少要有技術很強的，或是有心要精進的，不要想靠外包或是聘幾個工程師就可以打發。這些將來都是會連本帶利還回來的。

並不是說外國的月亮比較圓，他們的工作態度都比較好，應該說至少馬斯洛理論所提到的"生理的需求、安全的需求、社交的需求"，這幾個最低需求他們已經都被滿足到了，畢竟國外軟體公司給的薪水真的都很不錯，也都會提供很不錯的工作環境，所以他們有精力可以最求更高階的成就感。

敏捷式開發

沒有熱情和自主的敏捷式開發都是假的，敏捷式開發就是要靠大家都很自主很有熱情的，所以只需要有幫助專案進行順利的scrum master，而不需要盯進度的PM，所以只有Guide line沒有Rule，此外國外常用Peer Interview的方式，也就是你未來的同事要看到你的熱情與能力，也要了解你是可以溝通和共事的，大家都想跟你工作公司才會想請你。

對於新技術的適應曲線(adaptive curve)

如果我們還在對於熟悉某些技術沾沾自喜(例如： Spring、JPA、struts2)，卻停止研究和嘗試更新的技術，其實就是種退步的表現，套句醫龍的台詞"技術這種東西沒有進步的感覺就是不行了"。國外的開發者都一直在找尋更有效率的開發方式 ，所以他們願意私底下嘗試很多新技術，所以國外才會一直有新的技術產生出來。

以前也常聽到說這些技術不夠成熟你敢用嗎？可是很多時候如果我們都等著用國外夠成熟，發展好的技術來使用，相對的這些技術所衍生的商機、專利...等也被人卡的死死的。

純粹是記錄一些感想~~
不過種碎碎念的確還是適合放在plurk or twitter~:P

[後記] 我還特別去找了學如逆水行舟，不進則退的英文~XD
1. Learning is like rowing upstream, not to advance is to drop back
2. Either to keep progressing or to be washed backward

運用影片和動畫來宣傳與解釋網站概念

Source: Cloud9

一直以來傳統的技術型網站 (SaaS 類型)，大多透過文字和螢幕截圖的方式來描述這個系統的功能與特色，但是在沒有實際使用過前，往往會讓人不明就裡抓不到重點，不知道這個系統到底可以帶來什麼便利性與價值，也很難讓人有想要註冊試用的衝動。所以最慘的下場就是系統都開發好了，但是都沒什麼人想要來試用和註冊 (精實創業裡有提到的許多案例)

不知道是不是從Dropbox開始，越來越多純技術導向的網站 (目標族群鎖定開發者) 都懂得用影片和動畫的方式來行銷和包裝，並且使用類比式的口號(讓你協同寫程式，就像用Google doc一樣方便簡單)，不但讓人很容易理解，也很容易抓到這個網站所要提供的價值與重點。而且很多時候這些網站連Beta 測試程度都還不到，甚至還沒開發好，就可以吸引人想要註冊試用。
 
最近發現這種類型(Distribution Collaboration & Social & DevOPS in the Cloud )的網站越來越多了，這些網站都試圖提供一個可以分散式協同開發的環境，讓你只要有一台Notebook就足夠，其他東西全部都放在Cloud上。

我把最近看到蠻有趣的網站和影片連結整理如下，不過同樣是影片，卡通與動畫的效果我覺得遠遠勝過Demo 影片和介紹影片。(如果看不到影片可以直接連到官網看)

Cloud9  

CollabNet

(這個動畫好像跟電子產品的故事 The Story of Electronics 是同個動畫師畫的?)

CloudBee

Opscode

下面也列一些經典的概念介紹動畫：

What is Cloud Computing

Agile in Practice: Continuous Integration

如何安裝RabbitMQ Cluster

建立測試環境與測試系統總是最花時間的，趁著今天重新安裝一組RabbitMQ 的測試環境，把所有的步驟和順序都整理起來吧。

安裝RabbitMQ

說實在RabbitMQ安裝起來真的還蠻簡單的，參考RabbitMQ - 安裝指南：

• 要先安裝epel-release的套件。 (會不定期更新，要確認是否有新版)
• 再安裝erlang

# rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-7.noarch.rpm
# yum install erlang
# rpm --import http://www.rabbitmq.com/rabbitmq-signing-key-public.asc
# rpm -Uvh http://www.rabbitmq.com/releases/rabbitmq-server/v2.8.4/rabbitmq-server-2.8.4-1.noarch.rpm


設定Cluster

最簡易的方法就是先啟動，cluster master node產生 /var/lib/rabbitmq/.erlang.cookie 這份文件，然後再把這份文件copy 到 每一個cluster node鄉對應的目錄下面去，接下來就參考RabbitMQ - create cluster這份文件，範例事先建立3台的cluster。
 
1. 啟動每台rabbitMQ
# rabbit1$ rabbitmq-server -detached
# rabbit2$ rabbitmq-server -detached
# rabbit3$ rabbitmq-server -detached

2. 確認每一台rabbitmq 是否是standalone狀態

# rabbit1$ rabbitmqctl cluster_status
Cluster status of node rabbit@rabbit1 ...
[{nodes,[{disc,[rabbit@rabbit1]}]},{running_nodes,[rabbit@rabbit1]}]
...done.
# rabbit2$ rabbitmqctl cluster_status
Cluster status of node rabbit@rabbit2 ...
[{nodes,[{disc,[rabbit@rabbit2]}]},{running_nodes,[rabbit@rabbit2]}]
...done.
# rabbit3$ rabbitmqctl cluster_status
Cluster status of node rabbit@rabbit3 ...
[{nodes,[{disc,[rabbit@rabbit3]}]},{running_nodes,[rabbit@rabbit3]}]
...done.
3. 依序加入cluster

rabbit2$ rabbitmqctl stop_app
Stopping node rabbit@rabbit2 ...done.
rabbit2$ rabbitmqctl reset
Resetting node rabbit@rabbit2 ...done.
rabbit2$ rabbitmqctl cluster rabbit@rabbit1
Clustering node rabbit@rabbit2 with [rabbit@rabbit1] ...done.
rabbit2$ rabbitmqctl start_app
Starting node rabbit@rabbit2 ...done. 

4. 確認cluster status是否正確加入

rabbit1$ rabbitmqctl cluster_status
Cluster status of node rabbit@rabbit1 ...
[{nodes,[{disc,[rabbit@rabbit1]},{ram,[rabbit@rabbit2]}]},
{running_nodes,[rabbit@rabbit2,rabbit@rabbit1]}]
...done.
rabbit2$ rabbitmqctl cluster_status
Cluster status of node rabbit@rabbit2 ...
[{nodes,[{disc,[rabbit@rabbit1]},{ram,[rabbit@rabbit2]}]},
{running_nodes,[rabbit@rabbit1,rabbit@rabbit2]}]
...done.


設定Web Management Plugin

參考 rabbitmq - Management Plugin，重點是要在Cluster node的每一台都要安裝這個plugin
# rabbitmq-plugins enable rabbitmq_management 
安裝好以後，要記得重啟服務
# service rabbitmq-server restart

設定好就可以連到http://server-name:55672/#/ 看看web 介面有沒有起來，預設的帳號密碼都是guest，如果是內部測試那還沒關係，如果是要連到外面，一定記得要改帳號密碼和permission。

設定帳號

最後我們可以設定一個vhost 以及這個vhost的帳號密碼和權限

#rabbitmqctl add_vhost /demo
#rabbitmqctl add_user demo mypass
#rabbitmqctl set_permissions -p /demo demo ".*" ".*" ".*"



Reference:

[1] RabbitMQ 指令集

虛擬世界 vs 實體世界的資料 (Internet of Things, IOT)

Source:CISCO

虛擬世界的資料  vs . 實體世界的資料

Source:  Things that Happen on [the] Internet Every Sixty Seconds

網路流量，Facebook  like，Blogger 的文章數...等，這些資料都是屬於虛擬世界的資料，鄉對應的物聯網的資料，就是屬於實體世界的資料。

Business model generation - (Bait and Hook) 誘餌模式

圖片來源：網路

接續"免費只是吸引的手段，如何提高使用者付費轉換意願? "，今天要來聊的是Business Model Generation (商業模式新生代) 裡面免費商業模式之三Bait & Hook (誘餌模式)：

通過廉價的，有吸引力甚至免費的初始產品或服務來促進相關產品或服務未來的重複購買的商業模式。

如果單純看書的字面解釋，心中會有疑問 "這跟Freemium (免費模式)有什麼不一樣"，但是看到了實際案例就恍然大悟，我想最經典的案例就是印表機了。

印表機與耗材

大家一定都有經驗和疑惑，想說印表機怎麼那麼便宜，墨水耗材怎麼那麼貴，那我乾脆每次都買一台新的印表機就好(但是我們是愛護地球的人不會這麼做..Orz..)，原因這就是典型的誘餌模式，利用超低與破壞性的價格讓你上鉤與使用，當你習慣它，愛上它，需要它時，你就離不開它只好每次都乖乖的掏錢買後續"真正賺錢"的產品和耗材。

Kindle 與 Amazon books and apps

最近另一個有名的案另應該就是Kindle 系列吧，用超低價搶攻市場，硬體幾乎用成本賣，甚至賣一台賠一台，但是這也是典型的誘餌模式，因為他等於從Amazon 開了一個蟲洞和傳輸門道你的口袋和錢包，讓你不知不覺很輕易的就在Amazon 上買書買音樂買遊戲...等。

 0元手機與電信商

我覺得這也算是一種變相的誘餌模式，電信商吸收手機成本，提供給你免費或是低廉的手機(硬體)，然後透過電信費和加值服務來賺你的錢，產生持續性的收入，並且簽長約(產生Lock in 機制)。

黑暗篇- 盜版與正版

M$ 讓一般大眾使用盜版軟體，讓學生使用便宜甚至免費的版本，讓大家習慣，但是真正賺錢的就是靠去收公司行號和政府的授權費。  (好像毒品喔..好啦這是錯誤案例~XD)

歸納一下大概有這幾種搭配組合：

• 商品- -> 耗材
• 硬體 --> 平台 (軟體)
• 硬體 --> 服務

 (圖片來源：摩登如來神掌)

不過想要把別人的錢都轉移到自己的口袋 - 誘餌模式也不是那麼容易就可以實行，他有幾個要注意的發動條件：

• 成本結構要很小心計算，包含初始產品補貼和後續服務產生的成本 (不然會變成把你口袋的錢都轉到別人口袋去)
• 通常需要強大的品牌 (不然你賣便宜人家也不敢買)
• 誘餌(廉價商品)和鉤子(耗材)必須緊密結合，必須建立Lock in 的特性，讓人不容易離開

感想

台灣廠商硬體很強，有很多品牌也都經營的不錯，但是真的要好好想辦法建立起搭配的的軟體服務平台，不然賺硬體錢真的很辛苦的，而且隨著科技進步硬體只會越來越不值錢，如何在舊有硬體上繼續賺錢，那就只能靠軟體了。

參加 ezScrum workshop 心得

今天最有感覺的一句話 (Soruce:喲哪桑的投影片)

今天去參加ezScrum所舉辦的活動，想要了解其他公司目前Scrum運作的狀況，以及看看會不會有其他新的啟發，或是有沒有什麼值得我們學習的地方。主講者有兩位，一位是搞笑談軟工的Teddy，另一位是喲哪桑Speaking 之專案工作日誌的 Jonathan 這兩位很久以前就有在看他們的Bloger，今天終於可以一睹廬山真面目，Teddy 在演講與搞笑的功力真的是一流，但是業界實務經驗我就不確定了(畢竟只有50min 可以報告)。而Jonathan 之前在趨勢科技待了十幾年，現在有跳出來在一家新創的公司waveface當scrum master，所以實務經驗非常充足，然後他在分享他們在運作Scrum的經驗，讓我真的很有感觸，因為幾乎所有的狀況我們也都有發生過，然後我們也都是有嘗試各種的方法去改善，其中心思想就像第一個投影片講的"欲改善行為，先改變結構"，所以要改善某些行為與產出結果，組織必須要能靈活的調度，當然員工和管理者也必須以開放的心態來接受。


先說結論，就是發現我們公司其實Agile的味道與精神都已經有抓到了，而且比起外面已經算是不錯了，但是還可以在更好，也就是再度套句 Ken Schwaber 的話來說：Scrum不是一個方法學，它是一個框架(Framework) ，所以我們要在這個Framework內做調整，挑整出屬於我們的Best practice。

下面是幾張我比較有感覺的投影片：

要實行Agile真的要想辦法打破部門的隔閡，組織一個task force ，讓team member能專注在這個案子上，效果才會好。 (因為在場有許多公司有提到這個問題)

team member在分組上，通常有兩種分法，我們也都有試過：

• 一種是縱向由平台或功能面分：
• 比如說你比較熟後端，你比較熟前端，你比較熟iOS，你比較熟Android。
• 一種是由Epic (較大的User Story)來分
• 讓要做同一個Epic的人一組，一起來討論

Designer 和 Engineer 如何良好的合作的確是一個難題，而我們後來也是嘗試讓這兩種角色Pair programming 讓互相知道對方的難處與思考邏輯。(遙想當年我就是這樣把到老婆的XD)

最後就是Product owner 其實本身必須具備Designer 與 SA的能力 (如果沒有那至少找這兩種角色來幫你)，因為一個好的User story 也必須把UX flow  考慮進去。

另外我也有在這個work shop 問一個問題，這個問題也困擾我很久，就是backlog到底是什麼時候要產出，這個時間到底要算在哪個階段，因為以waterfall的開發方式，backlog的產生通常就是kick off meeting完後，SA&SD 根據RFQ去產生類似Use case 文件(專案需求分析書)，以Agile 來說backlog裡面放的user story是不用那麼詳盡，但是也是需要花時間準備啊，而且在每個sprint中，可能也會有新的需求和user story放入backlog，所以Product owner也必須要花時間為下一次的plan meeting做準備。

看樣子我還是得花時間把Agile的武功密集都研究研究，看看有沒有提這一塊....

(Teddy 引用鹿鼎記的梗~XD)

這是武功密集的目錄

這些才是武功密集

劈腿無罪! ?談設計高可靠度的系統架構需要注意什麼

前陣子美國的颶風造成AWS大跳電 [1][2]，網路上怨聲載道[3]，甚至一堆人又開始質疑Amazon與雲端運算可靠性[4]，以及趁機推銷他們的Private Cloud[5]，這些質疑都是合理的，也值得我們省思，但是我們不能因咽廢食就此遠離AWS甚至是Public Cloud，真正重要的是我們是否有任何災難復原計畫？是否有可以藉由架構的設計來減低災害造成的損失？所以我們今天要來談如何(劈腿與腳踏多條船) 設計與建置 High Availability and Reliability 的系統架構。

我真的好愛這隻劈腿狗(誤)，我們都知道在感情上劈腿和腳踏多條船是不被允許的，但是在系統建置上，卻是只要能力許可，財力足夠，你越有錢你愈要腳踏多條船 (這正是Hybrid Cloud的精義!) ，因為你才可以把你的風險分散，而且還有很多等級的分散：

• 分散在 Amazon 同一個Region 不同的AZ (Availability Zone )
• 分散在 Amazon 不同的Region
• 分散在 Amazon 與 其他不同的IaaS provider
• 分散在Public Cloud 與 Private Cloud

越下面的成本越高，設計起來難度也越高，不過才可以有效的降低與分散風險，這也很像理財所說的雞蛋不要放在同一個籃子裡面。

光是分散還不夠，重點是軟體架構

讓我們來參考一下AWS官網提供的Reference Architecture，裡面就介紹一個HA的系統架構應該長成什麼樣子，圖中的範例是把同樣的系統部屬到同一個Region的兩個AZ，所以設計的重點有：

• 如何使用Load Balance 有效把流量導到不同AZ 
• 如何把Service 設計成 Stateless 的，並且讓所有資料與狀態透過DB 來Sync
• 如何讓 DB 可以有效的 Replicate and Sync

同樣的，前幾天去參加AWS201的研討會，大家都對Auto Scale 很有興趣，但是Auto Scale真的難的不是在如何讓Amazon偵測流量和Loading去自動開啟關閉Instance，真的有學問的地方是在如何設計系統架構，讓Auto Scale每開啟一台新的Instance，Instance 內的 Service 可以自動啟動，加入這個Auto Scale Group，並且有效的Share loading。如果Auto Scale 自動shrink Instance size時，可以讓Instance 關閉卻不影響現有的Service 和使用者，資料也不會出現異常。

而且說實在這些都還沒考慮系統安全性和系統效能問題呢...囧rz..

有興趣的人快回去翻分散式系統架構的書吧，另外可以參考這本書：Addison Wesley - Patterns of Enterprise Application Architecture



Reference
[1] Multiple Generator Failures Caused Amazon Outage
[2] After The Storm: Architecting AWS for Reliability
[3] Amazon Takes Blame for Outages, Bugs and Bottlenecks
[4] Amazon outage one year later: Are we safer?
[5] AWS Outage Proves It’s Better to Own Than Rent

免費只是吸引的手段，如何提高使用者付費轉換意願?

免費只是吸引的手段，如何提高使用者付費轉換意願?

Business Model Generation (商業模式新生代) - Pattern 4 : Free as a Business Model，這種Business model 主要有三中類型：

• 基於多邊平台(Multi-side platform)的免費產品與服務：Advertising based
• 可選擇，是否付費服務(基本免費，進階收費)：Freemium model
• 利用免費或是廉價的基本產品或服務，吸引重複購買：bait & Hook model

第一種廣告模式，是最為大家所熟知，但是也是最不好賺的，傳統來說網站的有效會員數就是漏斗(見下圖)的基底，但是要真的讓這些使用者產生有效的廣告點擊，也就是到達漏斗得罪底層，也是最困難的地方，Facebook 就是最好的例子，擁有龐大的使用者，不管是人潮流量、黏著度與，平均使用直間都是非常驚人的，但是他的廣告的收益似乎就沒有使用者數來的驚人，從下圖中，我們可以看到Facebook的廣告收入在其總收入中的比例在逐年下降，2009年98%，2010年95%，2011年85%。相比之下，Google 2011年的廣告收入仍然占其總收入的96%。

 Source: ibtimes

這時就得問自己，你的網站能比Google 和 Facebook 厲害嘛？能吸引更多的使用者呢？所以今天主要是在討論第二和第三種，Business model。

下圖是有名的漏斗模型，也就是從初次來到你網頁的參觀者，一直到產生真正的收益所需要經過的過程：

Business Model Generation 裡面提到，根據統計只有不會超過10%的使用者會訂閱收費的增殖服務，所以必須靠這10%使用者的收入，來補貼90%免費使用者(看到眼淚都流下來了...Orz..)，所以其中最重要的就是由免費變成付費的轉化率。也許有人會說，那我就努力把轉化率便高啊！那我們先來看看Eventote 的例子只有1%~2%，也許你就不會這麼有把握了。

到底Freemium是否可行？

其實在Freemium在國外也是呈現正反兩極，有許多人認為Freemium是不好的Business model (例：Death to Freemium、killing your startup by listening to customers)，而Business Model Generation  裡面舉的例子：Flickr、Redhat、Skype，但是除了Redhat外其他公司幾乎都是靠被併購才能存活下來 (我認為啦...如果有誤還請指正)。

不過Freemium的確還是可行，也在國外行之有年，只是要如何有效操作，因為Freemium model 真的是一個操作起來非常需要技巧的Business model，參考下圖，在不考慮使用者數，單純考慮轉換率，如果你的Free plan 訂的門檻太高或是太貴(當初GAE就是大漲價，訂的太高，造成使用者大出走)，使用者是根本一點都不想付費，如果你的Free plan 訂的太鬆，也就是福利太好了，使用者就用的非常爽，甚至都不會想要升級成付費模式(我覺得Dropbox 和 Evernote 就有這種味道)，所以要拿捏的恰到好處真的是一門大學問。

[Freemium Pricing for SaaS: Optimizing Paid Conversion Upgrades]

有興趣的可以參考 Freemium Pricing for SaaS: Optimizing Paid Conversion Upgrades 這篇文章，裡面舉了許多SaaS 的範例，主要的建議整理如下：

• 隱藏Free Plan 的地方，讓使用者比較難找到，除非使用者真的很想試用
• 盡量提供Full function的試用期限，而不是無限期的免費版本
• 提供非常多價格級距的套餐選擇，且功能差異描述清楚
• 價錢比較的排版方式建議由小至大，由右至左，生動有趣的圖片介紹

整理完感想....賺錢真難...要賺免費的錢更難...Orz...

[Update]Business Model Generation 裡面列出了幾個重要公式：

• Income =(可吸引使用者數 x 付費使用者比例 x 付費價錢 ) x 增長率 x 流失率
• Cost  =    (可吸引使用者數 x 免費使用者比例 x 免費使用者服務成本) + (可吸引使用者數 x 付費使用者比例 x 付費使用者成本)
• 營運收益 (Operating profit) = income - Cost - fixed costs - 客戶獲取成本