2013年4月28日 星期日

牽車視同騎車!? 真是讓人難理解的法律


法律真的讓人很難懂.....很多時候又模稜兩可....

而且法律難懂就算了，媒體還會來亂....

前一陣子在路上牽機車，被警察警告，說牽車視同騎車！！還說交通部的律令....

只好趕快回家查，卻發現各種說法...

首先先看相關網友討論內容mobile01連結，有網友推測規則如下：

路線1→人下車→用牽的 = 行人違規穿越馬路(未走斑馬線及人行道的部份)
路線1→人坐在車上→用騎的或用蹬的 = 闖紅燈
路線2→人下車→用牽的 = 不違法
路線2→人坐在車上→用騎的或用蹬的 = 行駛人行道違規了+逆向行駛(相對於前方左邊往右邊的車流，除非前方式右往左的單行道，那就是前者)
圖片來源：mobile01


 然後我們在來看看新聞怎麼報導？


 PTT - 牽機車走斑馬線  (根本找不道所謂 警署交字第1010133556號函)
TVBS - 移動=駕駛　男子酒後牽車算酒駕挨罰
TVBS - 紅燈牽車過馬路　等同行人「不違規」
蘋果 - 紅燈牽車過馬路 不違法紅燈牽車過馬路 不違法

內政部 - 保一總隊政令宣導 - 引用蘋果日報內容：

蘋果日報100.11.05A37
紅燈牽車過馬路，不違法
交大執法組組長黨一凡表示，只要機車用牽的過馬路都視同行人，不算違規；但若是跨坐在機車上，不管是否熄火都視同騎車，恐被開闖紅燈罰單。

但是最重要的還是法律依據！！於是我就開始找尋各種法規....

另外找到一篇文章，裡面有引用1000812臺灣板橋地方法院100年度交聲字第2227號交通事件裁定：

【裁判日期】 1000812
【裁判案由】 交管條例聲異
【裁判全文】
臺灣板橋地方法院交通事件裁定　　　 100年度交聲字第2227號
原處分機關　交通部公路總局臺北區監理所蘆洲監理站
異　議　人
即受處分人　魏辰宏
......略
所謂「駕駛機車」，係指駕駛機車、使機車移動、行駛在道路上，亦即凡以人力、電力、獸力或其他方式，使機車在道路上行進，均屬之（參照臺灣高等法院98年度交抗字第1345號交通事件裁定）。

法官引高院判例解釋「駕駛機車」是指使機車移動、行駛在道路上，亦即凡以人力、電力、獸力或其他方式，使機車在道路上行進，都算駕駛機車。




交通部 101.08.16. 交路字第1010024025號函：

主旨：關於貴署函為駕駛人騎乘機車行進遇圓形紅燈改以牽引方式右轉後
      繼續騎乘，認應依道路交通管理處罰條例第53條第 2項規定舉發乙
      案，復如說明，請查照。
說明：
  一、復貴署 101年 6月22日警署交字第1010097477號函。
  二、查汽車駕駛人行經有燈光號誌管制之交岔路口闖紅燈，屬紅燈右轉
      之違規行為者，其違規處罰於旨揭條例第53條第 2項定有明文規定
      ，爰駕駛人如有違反上開規定之具體行為，執法機關依規定稽查舉
      發之，並無疑義。
正本：內政部警政署

李桐豪 ：針對機車騎士牽車過馬路屬不屬違法
(有解釋跟沒解釋一樣...=_=)
李委員就機車騎士牽車過馬路是否違法問題所提質詢，經交據內政部查復如下：

一、有關機車駕駛人行經路口遇紅燈時，在停止線前停車後，離開駕駛座位，於車道上直接以「行人」動作牽引(推行)機車有無違規部分，經查依交通部65年11月27日函釋略以：「機器腳踏車駕駛人或腳踏車駕駛人，如因機件失靈或其他事故，僅藉人力推動穿越道路時，可視同行人走路行為，並應遵守行人穿越道路之規定。」

二、依「道路交通管理處罰條例」第78條第1項第2款：「行人在道路上不在劃設之人行道通行，或無正當理由，在未劃設人行道之道路不靠邊通行。」暨同項第3款：「不依規定，擅自穿越車道。」等規定，如機車駕駛人牽引(推行)機車時未依前開規定辦理，執勤員警仍得視個案具體事實審酌，依法製單舉發。

結論：

1. 網路上流言謠言真的很多，請確認法規的正確性
2. 我還是搞不清處到底怎樣算違法!! 只能看警察心情...=_=
3. 法規系統真的很難用....浪費我一個早上得時間..=_=



Reference:
[1] 道路交通管理處罰條例 - 參照版，法規版
[2] 行政解釋查詢
[3] 道路交通法規
於 張貼者： 0 意見
標籤：

2013年4月25日 星期四

何時Hadoop 才能正式轉換至 JDK7 ?

圖片改編自：Oracle


雖然Oracle對於Updated Java 6 EOL date 已經延過一次(From July 2012 to November 2012)，會不會在延不知道，但是可以確定的是JDK 6 的維護已經進入尾聲，所以何時要把系統全面轉換到JDK7 應該是許多人遇到的問題。

其中最頭痛的應該是Hadoop EcoSystem吧，目前為止(2013.04)在Hadoop官網上關於 Hadoop Java Versions 的 wiki仍尚未出現JDK 7的蹤影，雖說已經有很多勇者已經開始測試在JDK7 上跑Hadoop Cluster 了，甚至有許多Performance Tuning 的文章也開始在比較使用JDK 7是否能提高效能：


研究了一下目前針對JDK 7 列出來的Issue 都還處於Open unassign 的狀態，所以看樣子正式轉換之路還是遙遙無期啊，有興趣的人也可以一起持續關注這幾個Issue

[2013.07.08] 看樣子CDH4.2.0 在一定的限制條件下，已經宣稱可以跑在JDK7上

於 張貼者： 0 意見
標籤：

2013年4月21日 星期日

測試SyntaxHighlighter


找了老半天終於找到問題，原來是之前裝的code plugin css 跟syntaxHilghter 衝到，會造成SyntaxHighlighter Render 出來的程式碼會被強迫換行，雖然裝這個讓程式碼比較好閱讀，但是blogger也會load更久~:P (裝太多Plugin了...)


/**
 * ---------------------------------------------------
 */ 
public void test(String contents )
{
 System.out.println("Hello World:"+contents); 
}

跟下面這段衝到~ 

/* Posts
----------------------------------------------- */
.post code {
  display: block; /* fixes a strange ie margin bug */
  font-family: Courier New;
  font-size: 12pt;
  overflow:auto;
  background: #f0f0f0 url(http://klcintw.images.googlepages.com/Code_BG.gif) left top repeat-y;
  border: 1px solid #ccc;
  padding: 10px 10px 10px 21px;
  //max-height:200px;
  line-height: 1.2em;
}

h3.post-title {
  margin-top: 20px;
}

h3.post-title a {
  font: $(post.title.font);
  color: $(post.title.text.color);
}

h3.post-title a:hover {
  text-decoration: underline;
}

.main-inner .column-center-outer {
  background: $(post.background.color) $(post.background.url) repeat scroll top left;
  _background-image: none;
}

.post-body {
  line-height: 1.4;
  position: relative;
}

.post-header {
  margin: 0 0 1em;

  line-height: 1.6;
}

.post-footer {
  margin: .5em 0;
  line-height: 1.6;
}

#blog-pager {
  font-size: 140%;
}

#comments {
  background: $(comments.background);
  padding: 15px;
}

#comments .comment-author {
  padding-top: 1.5em;
}

#comments h4,
#comments .comment-author a,
#comments .comment-timestamp a {
  color: $(post.title.text.color);
}

#comments .comment-author:first-child {
  padding-top: 0;
  border-top: none;
}

.avatar-image-container {
  margin: .2em 0 0;
}

/* Comments
----------------------------------------------- */
於 張貼者： 0 意見

閒聊從資訊的接受者成長為資訊的分享者


圖片來源：banyuleyouth

昨天牧師傳講得訊息是真道教會是小組化教會，以及何謂小組化的教會，而我的感想就是參與小組和參與聚會的最大差別在於對靈命追求深入的程度，參加聚會就像聽場演唱會，也許激情過後你又會恢復原本的生活步調，對於你的生命沒有太大的改變。

但是參加小組就不一樣，你需要付出時間和代價去準備分享的內容、去查經、去整理你的想法(代表需要預備，需要被操練)，而且由於人數少，你必須更需要花時間去認識與關心你的組員，而不再只是參加主日點頭微笑的陌生人，所以參與小組我們才會有真正的成長。

這也觸使我想要寫這個題目，因為最近實在加入太多幫派團體了(誤)，以致於有種時間與精力怎樣都不夠用的無力感，原本也說不出個所以然來，現在我知道原因了.....

這應該就是從資訊的接受者成長為資訊的分享者所伴隨的陣痛吧? (會不會轉的太硬?XD)

話說這幾年拜Social Network 的發達之賜(如：Facebook)讓原本不認識的人更容易認識，以及辦活動網站的興盛(比如說活動通、registrano )讓辦活動的門檻大大降低，這一兩年各式各樣的Conference, Meetup, xx社團、xx小聚...等，如雨後春筍般的冒出...

而最喜歡學習新知的我(資訊焦慮鬼~:P)，向來最喜歡去參加這種活動或是聽講座，一方面可以了解目前這個圈子的最新資訊或者得到啟發，另一方面還可以藉著機會認識這些領域的大大或同好，借此擴展人脈。(話說回來擴展人脈這倒是因為參與Start-up後才特別積極~:P)
 
所以這一兩年我還真的參加和加入了不少的活動、講座、社團，雖然說很多社團性質算是重複的，舉例來說下圖是由 Jazz 大大整理的在 Facebook (Big Data/ NoSQL) 界各社團之間的關聯性，可以看到很多人可能同時都參與在好幾個社群。


不過就算把同性質的社團算在一起，參加的種類實在還是有點太多...
真是繁族不及備載...更不用說每年固定參與的大拜拜(如：COSCUP....)

話說回來如果只是當個參與者單純去"參加活動"，所要附上的代價就只是花時間到現場去"聽"，並不會讓我有種時間與精力怎樣都不夠用的無力感 ，會讓我有這種感覺的原因是：
  • 想要對社群和社團有所貢獻 (那就要附上時間和精力的代價)
  • 想要有所成長，那就要從資訊接受者變成分享者 (也必須花時間去準備)

光是去聽對自己的成長是有限的，唯有開始分享(寫Blog、準備Talk..等)才更會強迫自己去準備，去找梗，去反思自己到底是不是真的懂了。

其實說穿了就教學相長

當然除了自己的成長外更重要的是社團/組織的成長，如果一個社團/組織要成長，就一定要像下圖一樣，有個正向的循環，是要靠參與在其中的人都貢獻心力，這個社團和組織才有可能成長與精進，如果大家都只想獲得不想付出，每次都靠那些大大在撐場，沒有一個正向的循環，就算有些團體是由某些公司贊助，或是有潛在的商業利益，但是沒有熱情與鄉民的回饋，我想再熱情的大大可能都會感到無力。

圖片來源：educube


所以我應該要把有限的精力與時間放在哪裡呢？

這就是我頭痛的地方.....

每個都在腦袋裡大喊：選我、選我、選我~~~XDD








於 張貼者： 1 意見
標籤：

2013年4月9日 星期二

ApacheCon2013 - Mastering Sqoop for Data Transfer for Big Data

圖片來源：siliconweek


這個Talk同樣是由Cloudera 的工程師 Kathleen Ting 和 Arvind Prabhakar 來輪流報告 (我也不知道為啥他們同一份投影片要輪流穿插講)，主講的題目是Mastering Sqoop for Data Transfer for Big Data，不過主要的內容是在講解Sqoop1 的缺陷，以及目前他們在發展的Sqoop2 預計怎麼改上Sqoop1的缺陷。

Sqoop的主要功能就是 SQL to Hadoop and vice versa，而Sqoop1的特色如下：
  • Base on connectors
    • Responsible for meta data lookup,and data transport
    • Majority of connection are JDBC based 
  • Connectors responsible for all supported functionality
    • Hbase import, Avro Support
也就是說Sqoop1 其實很單純只是一個Client side的工具，都必須在Local 執行，且需要Root的權限。此外如下圖所示



圖片來源：sqoop

而 Sqoop1 目前所遇到的挑戰：
  • 只使用原生的JDBC，沒有使用每個平台特定的Driver
    • 例如Oracle 的Driver 所提供的最佳化。
  • 安全問題 
    • 用明碼記錄帳號密碼，甚至把帳號密碼設定在Config File裡
  • Type mapping is not clearly :
  • Client needs access to Hadoop binaries configuration and database
  • JDBC model is enforced (這樣可能造成要符合Hadoop 模式會有問題)
  • Non-uniform funtonality
    • Difference connectors support different capability
  • Overlap / Duplicated functionality
    • Different connectors may implement same capabilities differently
上述的問題都是由 sqoop1 的歷史包袱所造成，因為一開始sqoop是設計給都是給power user 使用，主要用在內部系統有大量的資料在轉移的需求，所以就很少考慮到安全性問題。

為了解決這些問題，在Cloudera所主導開始了 Sqoop 2  (CDH4)的版本，這個版本主要的改變是多了一個Server 當中間者的架構，很多東西都儲存在Server 那邊，目標就是把sqoop從一個Tool變成一個Service，整個架構改成如下圖所示：

圖片來源：sqoop



圖片來源：ApacheCon 2013


Design goals
  • Ease of Use
    • Uniform functionality (不需要specific table?)
    • domain specific interactions 
  • Ease of Extension 
    • No low-level Hadoop knowledge needed
    • No functional overlap between connectors
  • Security and separation of Concerns
    • Role based access and use

主要的改進如下：(不過有些我也還不是很瞭解)


Sqoop提供兩種連線方式 (Connection vs Job meta)：
  • Connection (distinct per database)
  • Job (distinct per table)
運作原理如下：
  1. Connectors register metadata
  2. Metadata enables creation of connections and jobs
  3. Connections and jobs stored in metadata repository
  4. Operator runs jobs that use appropriate connections
  5. Admin set policy for connection use

在當下我不太了解，所以有跟講者確認，她說 Connector 由admin 去產生， 工作由operator 拿這個connector 去工作，這樣就不用洩漏帳號密碼。

所以Security方面改善如下：

Support for secure access to external system via role-based access to connection objects
  • Administrator create/edit/delete connections
  • Operator use connection (session base?這點待確認)

Usability $ Extensibity:
  • Connections and jobs use domain specific inputs (Tables, Operations, etc) 
  • Domain isolation and thus easy to understand and use
  • Connectors work with intermediate Data format
  • Any downstream functionality needed is provide by swoop framework
所以新版的Sqoop還是有許多地方需要在研究了解~ (Sqoop2目前是1.99版~XD )

最後幫他們宣傳一下sqoop2 專案還很缺人，現在加入還蠻有機會變commiter唷~XD

Reference:
[1] Apache Sqoop: Highlights of Sqoop 2
[2] Sqoop2 apache wiki

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

2013年4月8日 星期一

ApacheCon2013 - Text Lacks Empathy - Noirin Plunkett


延續上一篇"How to Delegate Like a Boss"，這個Talk也是關於Open source 專案營運管理會遇到的問題，也就是所謂的溝通問題，因為Open Source 專案的開發人員散布在全世界，最常使用的溝通管道不是透過Email就是IRC ，所以如何透過文字有效的溝通就是一個很重要的課題 - Text Lacks Empathy 

而這位紅髮姑娘 Noirin Plunkett 的主要職業是一個Technical writer，所以她也特別明白文字的力量，和該如何注意用字遣詞。就如同上圖都是在講Ship 和 Shipping 其實都有很多意義。



最重要的注意的是：We are not writer , We speak with our fingers. ..

同樣的字句，通常透過不同的語調就會有不同的意思，但是對於讀者來說可能都會有自己的解讀，比如說 sure it's fine 語調不同就會有不同的意思，所以用這些字句似乎可能得小心。

 下面是她建議的一個Email Template格式 (其實很普通常見)


Tact template

Hello $your_name,

$body

Thanks,

$my_name

所以下面幾點就是在溝通時要注意的：

Using Social Code
(在問別人狀況時，也許可以先說自己的狀況，所以老外最愛問人家how are you? How do you do?)

Listener ,try not to second guess. 
(不要想太多，對於人家的文字有過度解讀)

They don't know how you feel. State your emotions
(要清楚的說出自己的心情，不然人家從字面不知道你真正的意思)

Paraphrase (釋義)
(在聽到別人的話後，可以用你理解的話再反問一次，來確定是不是他的意思)

她也覺得顏文字非常很有力，可以多加運用


Try to be nice 
(就算人家是grek 但是還是要對他好，不然永遠不會有好的溝通)

其實最好的溝通方式還是當面，用Email通常已經是最不得已的方式
(Email --> IM or IRC--> Voice -->video --> Real Life)

所以她認 yahoo目前也是因為這樣的原因才要取消remote work，因為面對面溝通會比較好，對於外國人來說，最常看見的就是大家一起到公司，就算再玩，都可以建立關係和trust，這樣之後不管是工作和合作起來才會比較方便和順利。

It's not a competition 
(所以發email 的速度慢一點，不要一直cc bcc 來去，如果發的頻率太高，到時候人家就會不想看你的mail，想說這傢伙總是用寄信的)

Use the passive
(用被動語句 "The build broken"  ，對事不對人)

If it doesn't matter, do it their way.
If it doesn't matter and you still want to do it your way, you're lying.
If you care , say I don't want do your way, because following reason…..

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

2013年4月7日 星期日

ApacheCon2013 - How to Delegate, Like a Boss Deb Nicholson



圖片來源：businessbyjanice



Open Source 專案通常也會有所謂的Team Leader 的角色，但是這個Team Leader 的角色通常不像公司的Team Leader一樣有那麼具有權力，或是對於Team merber有制約力，所以如何管理一個Open Source Project 就變成一個難題。

因此這次ApacheCon 就有一整個Track 專門在談論針對Open Soruce Project 如何管理/營運/發展。而這個Talk就是在談論如何像老闆一樣授權 (How to Delegate, Like a Boss - Deb Nicholson)，以下是我記錄的筆記。


身為一個Team leader 或是mentor，不應該把自己當老闆看待，應該視自己為一個協調中介者。

不要等到你透支了才想到要授權，一開始就要授權！ (Don't wait delegate until you burn out. Delegate at first!)

由馬斯洛理論來看，通常會來參加 Apache 專案的都是為了自我實現(Self-actualization)，贏得尊重(Esteem)，增加社交網路(Social)，比較少是為了較低層次的Safety 和 Physiological，所以對於這些人，最好的獎勵就是稱讚：
Thank you as the free money!
對於Team Leader 要學會稱讚人的藝術，她舉個例子，稱讚就像在Code review一樣，要講詳細的內容具體的成就，而不是只是說好或不好。

Question welcome . more document on wiki can help you reduce your jobs.

雖然平常的分工可能都是把工作切的很細(Tie micro tasks to macro goals)，但是務必要想辦法讓他們知道Total Picture Goal，讓他們知道他們做的東西都是為了大目標，不是在做無聊的事，知識工作者(尤其是Hacker / Geek )都不喜歡只當一個小螺絲釘，希望能有參與感。

如何控制大家的活動或意向，比如說用比賽或是成就系統，比如說現在很少人在review patch code，也許可以舉辦一個比賽，給大家分數。Review 越多的的人可以排名越前面 (因為大家都為了榮耀)


最後她還demo了一個社群討論專案信產生器 (Live delegating)，不過似乎沒有Open Source出來~XD


Reference：
[1] How to Delegate, Like a Boss



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

2013年4月6日 星期六

閒聊 Software Defined Network(SDN) 如何影響傳統 IT 產業的工作分工



 圖片來源：自行製作

接續之前我寫的 "閒聊技術趨勢與產業觀察"，裡面提到IaaS還可以被拆分為幾塊來討論，今天要討論的是IaaS的三隻腳之一 network virtualization 或者可以稱作Software Defined Network (SDN)。

不過老實說這一塊算是我最不熟的領域  ╮(╯▽╰)╭  但是就是因為最不熟悉，所以特別會痛也特別有感覺，因為隨著越來越多系統號稱上雲端，已經不能用傳統的系統架構去設計，必須要多考量下列幾點因素 (參考自：Full contact cloud architecture and design linthicum ver 2)：
  • 讓你的Architecture 是可以scale out (取代傳統Scale up 思維)
  • 必須考量Mutli-tenancy 的問題 (不管是資源效能分配，還是安全問題)
  • 如何正確的使用SOA 來設計你的服務
  • 如何能快速的移轉/災難還原你的服務

同樣的SDN 的出現，對於系統開發者與系統維護者也會出現巨大的影響與改變，在以往一個IT大型系統建置需要兩大類型的技能，開發人員與維運管理人員：
  • Dev (系統開發人員)
    • Designer (UI or HCI or UX ...etc)
    • RD (Programmer or Developer)
  • Ops (維運管理人員)
    • System Administrator (SAdmin )
    • Network Administrator(NAdmin)
而SDN首先衝擊到的就是Ops這一塊，因為在以往System Administrator 和 Network Administrator的 工作劃分與責任釐清是很清楚的，System Administrator只需要懂作業系統，懂如何部屬程式，如何維護資料庫，VM管理與設定...等，而相對的 Network Administrator 就是俗稱的網管，負責的是所有網路相關的部分(包括：防火牆設定，網路配置規劃到接線，網路流量監控...等)

傳統的分工情境可能是這樣：

Dev： 我系統都寫好也測試好了可以麻煩SAdmin幫我正式佈署上線嘛?
SAdmin： OK~ 我已經幫你灌了 5個CentOS 的機器在機架上 ，系統參數都設定好，也幫你把DB都灌好了，等下就幫你把程式佈署上去~

Dev：喔對了系統會需要用到 8080,63382,3233...port，然後會必須要開一個VPN tunnel 連到美國分公司的xxx Service
SAdmin：喔這個等下你直接跟NAdmin講，網路設定是由他們負責的~
NAdmin：沒問題~我已經幫你把Junipter 的VPN Gateway 連線設好了，等下在把防火牆設定輸入到CISCO Router上面，你確定你要開這些Port?

但是SDN 出現以後，這個分工將會逐漸模糊，因為SDN的影響就是把希望把網路虛擬化後，可以讓網路設定的權力從硬體解放出來，交回給系統本身，舉例來在傳統，所有的網路設定是每一家硬體都不一樣，所以很容易被Vendor lock-in (其實就是CISCO )，但現在SDN出現後，說現在幾乎是所有虛擬化架構，與IaaS 管理系統幾乎都Default 內建 OpenvSwitch，用的是 OpenFlow 的標準，這樣一來不但可以解除Vendor lock-in的問題，更可以讓網路的設定與現在的虛擬化架構或 IaaS 管理軟體更緊密的結合，純 SAdmin 與 NAdmin的工作將會慢慢消失，取而代之的是Cloud Ops Administrator (COAdmin 原諒量我自創簡寫～XD)。


圖片來源：Openstack

COAdmin 除了必須了解傳統SAdmin的知識外，更需要了解NAdmin 的知識，因為場景可能會變成這樣：

Dev： 我系統都寫好也測試好了可以麻煩SAdmin幫我正式佈署上線嘛?
COAdmin：好我已經在 Amazon (or CloudStack or OpenStack)上幫你開好 5個 CentOS Instance，系統參數都設定好，也幫你把DB都灌好了，等下就幫你把程式佈署上去~

Dev：喔對了系統會需要用到 8080,63382,3233...port，然後會必須要開一個VPN tunnel 連到美國分公司的xxx Service

COAdmin：ok~這簡單Security Group 我已經幫你開這幾個Port了，我現在正在設定VPC，等下你就的程式就直接可以跟美國分公司連線了，另外需要我也幫你在美東設了一組備援服務，定期會把資料庫的資料Sync過去，這樣就算這邊的系統掛了，也可以馬上把網路設定轉過去，系統不會中斷太久....


結論，不管是程式設計師，或是傳統的 SAdmin或是NAdmin，在面對Cloud的時代，都必須要與時俱進的更新Skillset 和 Mindset 才能生存下來~~~

(不得不說~真是累人啊...≧◇≦  所以這只是一篇抱怨文...XD )


延伸閱讀：
[1] Virtual networking in Linux - IBM
[2] An Extremely Brief Conceptual Introduction to Open vSwitch
[3] The Rise of Soft Switching (Part I: Introduction and Background)
[4] The Rise of Soft Switching Part II: Soft Switching is Awesome ™
[5] Open vSwitch for Openstack Quantum
[6] 云中的网络：Open vSwitch带来的巨变

於 張貼者： 0 意見
標籤：

Scrum與Architecture是否有矛盾或衝突 (3)

圖片來源：網路


今天在找資料間無意看到這篇文章 Architecture and Design Practices for Agile Project Management，如何規畫才可以減少衝突？

首先參考下圖，節錄至agilemodeling的網站，裡面有提到關於 iteration0的存在[1]，而Agile modeling 網站描述如下：
During "iteration 0", the first iteration of an agile project, you need to get your project organized and going in the right direction.  Part of that effort is the initial requirements envisioning and architecture envisioning so that you are able to answer critical questions about the scope, cost, schedule, and technical strategy of your project




也就是說的確在初期，會做到某種程度的Architecture design以及 model define，但是Days是多久? 但要做到怎樣的程度？

延伸閱讀：

[1] Agile Architecture Interactions
[2] The software architecture role in agile methodologies
[3] Agile Architecture: Strategies for Scaling Agile Development
[4] How To - Design Using Agile Architecture
[5] From User Stories to Architecture

於 張貼者： 0 意見
標籤：

2013年4月5日 星期五

Object based storage or block device storage ?

圖片來源：Cloudcomputing Journal

這一陣子花了不少時間在研究與思考一個問題，就是關於資料的儲存與分析，同樣是面對資料，但是卻往往使用不同的技術在處理，舉Amazon來說，如果你想要使用EMR來分析資料，Amazon 的流程是這樣，資料的儲存使用Object based storage (如：S3)，而資料分析才是使用block device storage(如：HDFS)，不過現在甚至可以直接從S3 取代HDFS....

所以何時開始用Object based storage何時該使用block device storage呢？

在研究這個問題前，先看看wikipedia對於object based storage的定義：
An Object-based Storage Device (OSD) is a computer storage device, similar to disk storage but working at a higher level. Instead of providing a block-oriented interface that reads and writes fixed sized blocks of data, an OSD organizes data into flexible-sized data containers, called objects.

由文字可能比較難理解，但是由圖片來看應該就比較好理解。


另一份是IBM的論文在解釋Block Device 和 Object Store的差異



所以兩者最大的差異是怎麼去看待物件這回事，Object Storage 存取是針對Object 像是create Object delete object，另一個重點是要提供Http API (Restful)，所以只要符合這幾個原則，不管後端是block file system or HDFS 都算是Object storage。



此外我在找資料的時候剛好看到這一篇文章 "Because Hadoop isn’t perfect: 8 ways to replace HDFS"，這就厲害了，這篇文章舉出八個替代HDFS的Solution：
  1. Cassandra (DataStax) ：Hadoop on Cassandra
  2. Ceph (inktank) ： Hadoop on Ceph
  3. Dispersed Storage Network (Cleversafe)
  4. GPFS (IBM)
  5. Isilon (EMC)
  6. Lustre
  7. MapR File System
  8. NetApp Open Solution for Hadoop
Well...這時候Hortonwork CTO就跑出來說話了...XD 他寫了這篇 Thinking about the HDFS vs. Other Storage Technologies 的文章，來說明HDFS的優點：
  • Extreme low cost per byte
  • Very high bandwidth to support MapReduce workloads
  • Rock solid data reliability
然後再進一步列出上述八個替代方案的缺點(簡單來說就是不是為了Hadoop量身訂做)
  • System not designed for Hadoop’s scale
  • System that don’t use commodity hardware or open source software
  • Not designed for MapReduce’s I/O patterns
  • Unproven technology
我想Commofity就是重點了，因為上面列的八個產品其中好幾個都是要搭配貴悚悚的特殊硬體，不過這些都是題外話了~:P



Reference:
[1] Object Storage: The Future Building Block for Storage Systems - IBM Haifa Research Laboratories
[2] Object-Based Storage Devices
[3] Objectively speaking: the future of objects



於 張貼者： 0 意見
標籤：

2013年4月2日 星期二

從 Amazon Virtual Private Cloud (VPC) 到 CloudStack 的 VPC

圖片來源：techcrunch


前一陣子看到一篇不錯的文章 "Anyone To Create A Virtual Private Cloud Showing Again How Enterprise Tech Is Obsolete"，想說是不是應該來寫一篇關於VPC的介紹。

AWS 的 Virtual Private Cloud (VPC) 對於Startup公司或一般小公司可能很少用過，也不太需要用到，因為Startup公司的Service 通常直接就在EC2上了，此外Startup公司通常也不會有內部系統 (大多可以直接利用許多雲端服務，如：Google App, Microsoft office 360,Trello...等)。

但是對於許多中大型企業就不是這樣了，中大型企業通常都會有自己的內部系統與機房，因此他們就必須要考量的點就比較多了，比如說轉移成本，資安考量...等，所以通常會優先考量把本來就對外營運的Service移到Public Cloud 上，但是內部系統繼續留在公司內部機房。但時候對於MIS和IT來說可能就會頭痛了 ，因為必須要管理兩套網路環境與兩套系統，更不用說這兩套系統可能還必須溝通，所以這個時候企業就可以考慮使用AWS VPC (當然前提是你使用的Public Cloud 是 Amazon~XD)

AWS 的VPC 主要分成幾種模式：

主要用意就是幫助企業把私有網路環境延伸到Public Cloud，也就是同時可以享受Public Cloud的彈性與優勢，另一方面又可以保有公司私有/內部網路的架構與設定。

下圖是我整理最常見的使用架構，VPC與內部網路透過VPN Gateway 的方式串接


圖片來源：自行整理


不過這時候另一個問題來了，那如果公司內部想要架構跟AWS一樣方變得Private Cloud，那我該怎麼做？這時候就一定得來推薦CloudStack了，話說 CloudStack 4.0 主要新增功能之一就是增加類似 AWS VPC的功能，那CloudStack 的VPC 和 AWS的VPC有啥差異？可以混在一起用嘛？

欲知詳情？歡迎來參加由趨勢所舉辦的 Cloudstack TW Design Camp....
(要知道下一次舉辦的時間，請多留意TCloud 的Facebook 粉絲團的消息唷~)

延伸閱讀：
[1] Amazon Virtual Private Cloud Connectivity Options
[2] Connecting a Single Customer Router to Multiple VPCs
[3] Connecting Multiple VPCs with EC2 Instances (SSL)
[4] Connecting Multiple VPCs with Astaro Security Gateway
[5] Connecting Multiple VPCs with EC2 Instances (IPSec)
[6] Amazon VPC介紹與建置-簡介


於 張貼者： 0 意見
標籤：

2013年4月1日 星期一

ApacheCon2013 - Apache in Business Panel


ApacheCon 這一場Business Panel 主要是邀請幾間把他們公司產品Open Source 出去的大廠，所以還蠻值得一聽的，畢竟對於公司來說最常問的問題就是參與Open Source有啥好處，可以帶來啥商業價值？如何跟社群共處等問題....

整個Panel是由主持人準備幾個問題，然後由每間公司分別回答。而我也盡量用我的聽力把重點記錄整理下來。

開場白：Apache 的精神就是不被任何人擁有，大家一起成長

你們覺得Apache怎麼看 Business vs Open source


Bertrand Delacretaz (Adobe): 目前Adobe 90%專案都是使用或跟apache 專案有關，對於adobe認為，apache 的專案都是基礎共通的部份，每天公司可以在上面加值應用，所以不會牴觸

Phil Robb (HP) : 因為這些open source 的user 就是他們自己本身，所以市場本來就很清楚，然後為了自己使用方便，所以會更努力的讓這個程式更好

Mark Hinkle(Citrix): 如果你加入open source 你可以跟user 更接近，使用者可以更容易加入你，給你意見和幫你測試，Cloudstack 之所以要加入apache，因為apache 的方式與流程，很有公信力，對於open source 成長很有幫助，也不像GPL那麼有限制

加入了Apache 和open source 有啥影響


Mark Hinkle(Citrix) : 當然一開始每天都在掙扎，因為有點失去了自主的控制，但是只要follow apache 的方式，了解apache的文化，的確還是有用的

Phil Robb(HP) : 要學會跟社群相處，學會怎麼溝通和推動產品的方向

Bertrand Delacretaz (Adobe): 跟傳統的公司開發差很多，因為不是中央集權，這是一個分散式的架構，所以對於產品的開發與release 的管理方式就要因應有所改變，因為你不能壓了時間就要求大家一定要release，因為很多人都是義務幫忙的。

Phil Robb(HP) : 發現省錢是越來越不重要，反而是要跟工程師學會越來越彈性，因為對於軟體公司這些社群都是資產，會幫助HP。整個apache 的方法，不管對於Manager 和 Architect 都是跟以往很不一樣，必須要學習怎麼分散式的工作，但是Open source 已經是趨勢無法抵擋只能擁抱

Bertrand Delacretaz (Adobe): 我同意花費不再是專注於省錢，花多少錢，而是專注於軟體的功能，可以解決什麼問題，因為很多傳統的軟體工程方式，估價方式幾乎都不管用(永遠會落後進度)，此外要教會員工怎麼與社群一起工作開發專案，也是一個挑戰，但是公司最後還是會從中的到益處

結論：

對於軟體產業的cost 最花錢的的是行銷和客戶關係，反而不是RD人事費用，但是加入了社群後，這些花費反而可以解少，透過apache 的光環就自己被宣傳，使用者自己會來使用，測試，回饋，此外如果要聘用好的工程師，最容易驗證的方法就是從open source community 去找到人才，因為這個人的品質，能力是被大家驗證和所見的。

Apache 該如何在教育界推廣

對於美國學生來說，目前對於工程師Geek 的type都是覺得不酷的，所以還是很少人願意投入，所以這也是apache foundation想要嘗試解決的問題，而且透過apache的方式，人來自全世界各種人，所以可以增加多元性(人種，性別…等)。

apache  之後會有什麼計畫，類似童子軍一樣，從教育來改變嘛？

但是Apache不用像一般公司一樣，一定需要所謂的未來發展與十年願景之類~:P (像是IBM每年都會有啥趨勢預測)

但是apache 本身就由 User 和 Developer 的組合，趨勢就是由這邊去產生的，所以是由下而上去推動，不是由上而下推動

所以apache foundation 的任務不是要往哪裡方展，基金會唯一的目標就是協助發展更好的軟體，所以方向還是由工程師去推動

所以不管是獨立開發者和企業都對等重要的~


最後開放的Q&A：

有人問，這些公司怎麼看待Github，同樣是Open Source 怎樣的專案會選擇放入Apache？

Bertrand Delacretaz (Adobe): 對於公司來說，通常是長期基礎發展的就會放入apache，但是如果是短期實驗之類的就會放入github

Mark Hinkle(Citrix) :Github 對 Citrix 來說是專門用來發展branch 和 plugin 的地方，讓使用者可以自由發展發揮創意的地方

Bertrand Delacretaz (Adobe): Adobe 提醒，把東西放在Github要小心，因為對於軟體的擁有權，使用權…等，是不確定的有很多模糊地帶，所以是很重要的東西放上去要小心




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