2013年3月31日 星期日

[Ingress] High Density of Dropped Resonators Forced colse Attack/Defense



Two weeks ago we builded a L8 x 14 portal farm in Taiwan, and had a great Harvest.


This week, even more we build a L8 x 16 portal in same place. But we all hit the limit of resources we can carry. So many of our friends start to drop some low level resonators , such as L5,L6. I guest there are more than 1k resonators over there. Then the tragedy happend....


Everyone's ingress forced to be closed. The apps crash!! Even people who use portal key want to remote charge portal got the same result. I look into the stack trace see IllegalArgumentException:Vertex count large than usable with GL_SIGNED_SHOT

PS. Vertex count is the array divided by the size of the vertex ex. (x,y) or (x,y,z)



So We cannot hack those portal , neither the resistance can attack our portal.

We call this action as High Density of Dropped Resonators Forced colse Attack/Defense (something like Ddos...XD )




ApacheCon2013 - Continuous Delivery with Maven, Puppet and Tomcat



參加ApacheCon2013的筆記持續整理消化中....Orz..

話說在DevOps 的概念裡面本來就有包含QA的概念,不過很多時候卻被人誤解成,不需要QA或者是QA不重要,因此講者就在投影片引用一句話:
To make error is human. To propagate error to all server in automatic way is  Devops
所以越是自動化的部屬,就越需要QA的參與,所以講者就特別把QA獨立出來強調,因此才有DevQaOps的詞..XD 其實目的都是為了能達到Agile - Continuous Delivery 的境界。



雖然之前我有整理過一篇文章關於DevOps的工具與技術 -  Continuous delivery - tools and techniques ,但是對於這塊的著墨還是略嫌不足,而這次參加這個Session

這篇文章列出一堆幫助DevOps的工具與技術,而這個Session 雖然題目是寫Maven + Puppet + Tomcat 的組合,但是裡面主要介紹必較新奇的技術卻是 "Puppet + vagrant" 的組合,透過Puppet + vagrant 的組合能快速的建立vm環境和開發環境,加速複製和重建的時間,然後也可以利用puppet 控制maven 的安裝與控制,詳細的範例可以參考講者放在Github上的範例專案:

延伸閱讀:


投影片:



後記:

因為筆者都在介紹Puppet我就好奇,那Chef呢?因為這也是常見常聽到的技術,所以我就順便Google了 Chef 與 Puppet之間的差異。

簡單來說就是Chef 是新公司做出來的產品,有著跟Puppet相同的目標但是不同的技術,所以Puppet陣營的說法就是Chef沒有經過大型系統Deploy 的驗證與知名公司的背書 (不過最近Facebook採用了~:P)

所以同樣的也有Chef 跟Maven 整合的專案和套件:



2013年3月27日 星期三

觀察各公司在Hadoop Ecosystem 的committer 與PMC 數量


圖片來源:Datameer 2013

相信這張圖大家應該都看過,是關於Hadoop Ecosystem technology partnerships之間的關係,第一名的是Cloudera。

剛好今天收到一封信說Hortonwork在Hadoop 專案的數量遠遠超過Cloudera,我就在想這樣看不準啊,因為cloudera在其他專案也有投入許多人力啊!?於是就燃起我一定要察個水落石出的念頭!!(工程師魂~~~~~)

剛好這也算是由另一個角度來分析,藉由觀察各公司在Hadoop Ecosystem (個專案) 的Commiter 與PMC 數量,來看個公司的主力方向以及參與程度。

整理的方法,就是收集Hadoop ecosystem 比較主要專案的PMC 與 committer 名單,雖然發現有幾個committer有跨專案,不過這邊最主要是要比較每間公司佔各專案的人數,所以就先不管混在一起計算(其實是偷懶....),另外我也只計算幾個人數比較多的大公司,其他小公司或獨立開發者就沒特別列出來。


Ambari Hortonworks 18
IBM 2
Avro Cloudera 4
Pig Hortonworks 5
Cloudera 1
IBM 1
Twitter 3
Yahoo 3
Hive Facebook 6
Hoetonwork 1
Sqoop Cloudera 9
Mahout LinkedIn 2
HCatalog Facebook 1
Hortonworks 6
Twitter 1
Yahoo 2
Oozie Cloudera 3
Hortonworks 2
Yahoo 3
MS 2
Flume Cloudera 12
BigTop Cloudera 8
Facebook 2
Hortonworks 3
ZooKeeper Cloudera 4
Hortonworks 2
Yahoo 6
Hbase Cloudera 9
Facebook 5
Hortonworks 4
Hadoop PMC Cloudera 7
Facebook 3 + 2
Hortonworks 13+ 4
Yahoo 3 +7
IBM 0+ 3

--------------------------------------
所以最後統計結果如下,果然還是Hortonwork 大勝!!

Hortonworks 61
Cloudera 48
Yahoo 27
Facebook 17
IBM 6
Twitter 9
LinkedIn 4

報告完畢~~我真無聊....XD