Mobile Platform Wars

Went to the conference last night, basically it was all about (free beers & foods,) presentation & debates from developer's perspective between 3 major mobile platform + cross platform.

It was present in a more friendly way than what I thought to be, here are a little summary from it:

Android is catching up iOS in terms of Apps have developed per month:

pro:

• Developer-friendly with those who had wrote JAVA Swing before;
• The learning curve is starting with easy but will encounter hump at later stage;
• Free install on any android phone;

con:

• Pirate problem - free install on any android phone (yes, both pro & con).
• Compatible problem - inconsistency version of android OS with different handset (CPU speed, memory and resolution etc.)

iOS is still holding the crown, but I feel people is getting a bit of aesthetic fatigue with it.

pro:

• Apple controls the version update and handset standard (only Apple products running iOS);
• Rich documentation and examples from Apple;
• No pirate problem, money guaranteed;

con:

• Approval process of Apps required to go through Apple, and need to pay money before putting on shelf.
• Object-C and iOS dev kit require a bit more time to get familiar with, hump at begging of the learning curve.

Windows Phone 7 was all re-designed, they learnt a lot of experience from previous two platform. Plus that Microsoft is putting huge amount of money into it, it looks promising.

The demo was directly projected from the prototype phone (previous two were through slides), which was pretty cool.

Its new clean & slice Zune style UI gave me some impression on over those iPhone style touch-phone UI (although android does provide some different things, such as widget/gadget on dashboard)

pro:

• Backed by the powerful Visual Studio & .net, this isn't something like iOS devkit or Eclipse can compete with.
• Instant wealth feedback with Microsoft's money support even before you start list your apps.
• Microsoft chose some middle way between Android & iOS:
  a. Controlling with approval, but also allow you to invite people for free install.
  b. Still have different manufactures but they mentioned they will control the version updates and standardisation.

con:

• Still need to wait for market reaction after a real phone on shelf.
• The conference was sponsored by Microsoft, and they present in a more user experience way rather than from developer's perspective.

Cross-Platform basically means you write apps as web app, good for writing small scale apps.

pro:

• With a local platform wrap you can write core codes once and able to run on all kind of OS.
• Easily hop on for those web developers - cross languages.

con:

• Compatible problem, different resolutions etc.
• Performance problem because app is not running in native code.
• Development curve might be hump after humps.

Overall I felt that if Apple is not going to do any change in future years, they might fall behind with the fierce growing of Android and menacing return of the Windows Phone.

However consumers will be happy to see the competition in smartphone world is going into a new stage soon.

Software Testing

Developers will rarely like to work on software testing because it's boring. It isn't like creating code that requires creativities, but more like a repeating labor work. To help/enforce developer to overcome this laziness, with the power of Agile methodology, TDD (Test-Driven Development) requires you to write tests based on requirements before you can start actual coding.

Ok, Software Testing is not in my job description, but because there are no tester or QA in our development firm, every developer has to do his testing by himself, consequently we only have automated tests, and as SCMer I need formalize them as part of build automation, therefore I need to understand a bit more in it.

Software Testing is an complicated and time-consuming discipline, what I'm addressing here will not be entirely correct, but rather to be just my understanding at moment. Write them down to allow me to revisit and revise in the future.


All testing were done by our developers with all automated, hence they are all white box testing.

Unit testing verifies the functionality of a specific section of code at the function/class level, it is the most fundamental one, we use it from first year of computer science study. But unfortunately it is still the only test that some of our projects have, and in a few projects they don't even have a proper unit testing.

Unit testing frameworks help simplify the process of unit testing, it provides assertions, exception handling and other control flow mechanism that make your work of adding unit tests become relatively easy. We use Boost Test Library for C++ and NUnit for C#, some of our cool kids start to use google test.


One of the task I was working on is the Code Coverage, it tests how your source code been covered by your unit tests. In other word unit tests test code, and coverage test measure unit test. We use gcov for C++ projects (with lcov as an extension to generate reports), and NCover for C# projects.

Three common metric we get from code coverage are:

• Function coverage - How many times each function in the program been called during exercising unit tests.
• Statement coverage - How many times does each line been visited.
• Branch coverage - Does every edge/decision/condition been executed?

Unit testing is a Dynamic testing, there are other Dynamic testing such as Integration Tests, System Test and Acceptance Tests. We don't have most of them, and due to the nature that our software are in-house only software, our end users are acting as tester and doing all these tests for us kindly.


Contrast to dynamic testing there is static testing, or as we called it - code review, primarily it is just to walkthrough the code manually. In my previous company we were required to have a "buddy check" before doing any commit, now in my current one we are not that restricted but people will still ask someone in the same team to review. This does help the collaboration by letting other team members to understand what your are working on, thereby improve both the overall quality of code and the developers' skills.

ReviewBoard is the tool that I deployed to help pre-commit review, it is a relatively new open source tool so don't expect to be that perfect. I also configured post-commit mailer for Subversion to emails code to reviewers automatically after checkin is made.


Static testing without human analysis is called static code analysis, this is performed by an automated tool. Coverity is one of the tool that identifies security vulnerabilities and code defects, some say it is a very powerful, but it is very expensive as well - charge by per line of code it analyse. I wonder if it's worth because I only had a glance on it, for next few days I will take some time to deploy and test it.

There are other two statis analysis tools we use for our C# projects, they are both from Microsoft and they are free (uhh?). FxCop analyse .NET programs that compile to CIL object code, and StyleCop analyse C# source code to enforce a set of style and rules. Although FxCop was running there for a long time and its result appeared to be similiar to what we got from Coverity, but no one had ever care about them. Because they are from Microsoft and they are free, hence most of our developers think they are weak? what a pity.


These are just the tip of the iceberg in the entire software testing empire, but they covered most of what SCMer need to know and take care with. If your boss ask you to do anything more than tests that can be automated, you should suggset him/her to hire some more experienced tester to setup a testing team.

Remember, as the hub of the wheel we help but we don't do everything.

Clash of Titans: G.A.M on!

從第一輪起到現在，多數挑戰者都是採用了G大神的Android系統，在單一手機上也許愛鳳無敵，但G神要像上個世紀M帝一樣使出人海戰術，讓喬幫主的歷史再一次重演。

生果的的iOS與G神的Android，就好比上個世紀的MacOS與Windows之爭。MacOS是個人電腦的奠基者，有著1984年的iPhone之稱，創意與風頭都是一時無兩。但是其系統只出在自己生産的硬件上，自己的硬件也無法運行其他的系統，軟硬沒有分離，被後來居上的Windows超過。M帝只做軟不做硬，與intel結成了wintel聯盟，除了生果集團的硬件廠商都用它的，最後以量取勝。

和Windows一樣，G神推出Android，創意沒做到，先機沒搶到，但是現在卻穩步搶奪市場，因爲更多的手機開發商採用，就有更多的機型可供選擇，就有更多的使用者，然後就會有更多的開發者，更多的内容，而後鋪天蓋地。生果一年推出一支愛鳳，以精品取勝，可據一方，但要以一敵百，霸佔市場，恐怕很難。

不知道喬幫主還會不會讓自己重新走上幾十年前的老路？Android反其道以多搶攻，之後會佔上風，但要達到Windows在個人電腦市場上那種壟斷，應該也不行。畢竟M帝的Windows Mobile現在仍有手機平臺不少的份額，比之個人電腦那種OS格局，手機OS今後更有可能是三分天下再加上Symbian、RIM等其他攪局的情況。

RIM雖然現在仍然是美國境内購買量最多的智能手機OS，但因爲它因爲也是種生果（黑莓）所以只在自己的手機上裝專屬的OS，而且其本來的出發點就過於企業化，不具有大衆效果，所以逐步下滑被iOS與Android吞噬份額。其最終形態應是像電腦有專作服務器OS那樣的繼續守住商務區的一畝三分田了。

Symbian作爲最早的智能手機系統、Nokia作爲最大的手機制造商，至今仍然佔據半數以上的智能手機市場，但竟被認爲跟不上時代的步伐，不禁讓人感嘆一代江山一代人，前浪死在不思進取上。至於其他的Linux based系統（Intel的MeeGo、Samsung的bada），沒有更具創新的點籽及過硬的實力，想要尋找夾縫，極其之難。


以前說生果代表的是硬件、M帝代表的是軟件、G神代表的是網絡，但現在這三者相互競爭，領域並不局限於自己擅長的，也逐漸侵蝕到對方的市場，手機平臺的較量，只是一部分。現在的戰爭，就是全面戰爭，請看下回－－G.A.M: Total War。

Media Distortion

本人不是果粉，曾經追隨過M帝一段時間，但現在沒有，對G神的使用基本上也僅限於search engine上，所以相對中立。西方的傳統就是講究均勢制衡，不希望看到哪個集團坐大，這應該是源自歐洲一族一國的歷史。不像中國傳統上是期待統一化，都喜歡那種大國思想、大企業觀念，所以也容易產生壟斷。

說來以前M帝還是M帝的時候，可沒被媒體少批，一點小小的問題就會被無限放大。這是爲啥？他如果產品不好，光靠市場策略和行銷手段，還能佔據90%以上的世界市場不成。不過既然市場不喜歡見到被壟斷，媒體作爲消費者的指向標自然也要誤導一下，否則如何矯正？國内的主流媒體就不一樣，都是一味鼓吹。爲什麽？都被掌控了。

所以Media Distortion也不全是不好，校正偏移一下市場方向標，對整體也有好處，畢竟競爭才是第一創造力的動力來源。沒有火狐的出現，IE現在還是6。誇大修飾算是媒體一貫做法，這可以理解。不渲染一下，讀者沒有情感偏頗，誰還會感興趣呢。只是人類的平均本質上沒有良好的自我辨析能力，所以盲從與互噴也是這種群居社會的景象之一。不要以爲五毛黨與五美分黨只有中國才有，在西方他們只是換了一種形式存在而已。


這次生果愛鳳的天綫寶寶門事件，也是人類特性的一種表現手法。也許愛鳳設計上確實有問題生果沒有正面承認，也許普羅大衆太不能接受愛鳳沒像一貫的完美，但這事還是被媒體無限放大了。一來市場不喜歡被一方做大，二來互噴盲從被當作生活樂趣。結果如何？排隊的排隊，斷貨的斷貨，免費的套子算是這場喧嘩中最大的好處。

事實上從愛鳳出現以來，就不停的有愛鳳殺手們登場。記得以前看ChannelWeb，每代都有比較（括號内是贏的場次）：

1. 第一輪：iPhone 3G (6) vs T-Mobile G1 (5) vs BlackBerry Storm (3)
2. 第二輪：iPhone 3GS (8) vs Palm Pre (6)
3. 第三輪：iPhone 4 (10) vs HTC Evo 4G (6)
4. 第四輪：iPhone 4 (9) vs Motorola Droid X (6)

就算媒體想要偏頗，但是這種硬性評分的結果還是顯示了公正，每一輪愛鳳都是贏家。有的輪看起來比分接近，不過現在誰還記得當初最大的殺手Palm Pre？還有那個G大神出的Nexus One，現在停產了。這兩個是我印象最深刻的殺手，而現在最出名的對手就是HTC Evo 4G和Motorola Droid X了，不過這兩個都沒在澳洲出，澳洲是HTC Desire與Samsung Galaxy S i9000。

在前兩輪，市場需要靠媒體來鼓吹一下以避免愛鳳風頭太盛，但現在對手越來越多，越來越多。以前是一年都難找個對手，現在一季就會出幾個競爭者。從單一手機來看愛鳳無敵手，但是雙拳難敵眾手，從整體市場來説生果卻很有可能再次重演歷史。請看下回－－Clash of Titans: G.A.M on!

Elegant Code

每個Programmer，都應該是有能力分辨出一段code是否具有美感。只是有時候有人問我靠什麽去評判時，我一時無法詳細地去解釋，只能説是靠種感覺。現在仔細想來，優雅的Code應該是具有「簡潔明瞭精致有效」這八個字。

前四個字是做WhiteBox時的評判，只有Programmer在意，因爲他們看得到内部的code，他們需要clean code是因爲這樣他們可以更快速的去理解（無論是自己寫的還是別人寫的），從而能在理解基礎上快速修復或增加新的東西。

后四個字是BlockBox時的評判，User和Developer都在意，這關乎的是一個成品的表現。成品在意的是效率，就是速度與精確。而一般來説，聰明的算法與數據結構總是有更好的效率。換句話說，我們現代CPU架構的模式使得在相同標準下短小精悍的code有優勢。

這些東西說太多，也只是意會，不好理解，下面用四個例子來做更好的作説明。需要注意的是，這四段Code都是合理優秀的，裏面就算最普通的第一個也是有如教科書般經典。

 def f1(list):
string = ""
for item in list:
string = string + chr(item)
return string

 def f2(list):
string = ""
ichr = chr
for item in list:
string = string + ichr(item)
return string

 def f3(list):
return "".join([chr(item) for item in list])

 def f4(list):
return "".join(map(chr, list))

給一個相對大的list，f1-f4的運行時間分別是：

• f1: 3.01409792928ms
• f2: 2.99986600876ms
• f3: 2.69300198555ms
• f4: 1.84089493752ms

1. f1是最正規的寫法，只要不是很performance intensive的程序，相信大多數Programmer都是這麽寫。
   
   
2. f2只比f1相比只有一處變化，性能上也只是稍微快了一點點。因爲python的特性，當執行chr()這個function的時候，intepretor需要不斷向上回溯去找chr()被定義的地方。而f2則將local variable ichr指向了chr，避免了每個loop都要向上回溯的時間。當然，這個減少的時間微乎其微，因爲大多數compiler都會幫你優化。
   
   
3. f1和f2還有一個地方是很浪費資源的，就是string concatenation。一般Programming初學者總是喜歡用這個方法：初始化一個empty的string，然後再把内容用+ operator粘貼在後面。這個方法在string相對小並且操作量少的情況下並無壞處。但是在上面的function裏，每個loop可能都以運行十萬計的情況下，就非常耗費資源。因爲其操作是每次重新初始化一個string在memory裏，然後把舊的string和新的string添加在一起放入那個memory位置。這樣的complexity是O(n**2)。而使用join()這個内建函數，其complexity則是O(n)，因爲它一次性把所有要加的部份粘在一起。
   
   
4. 這4個function裏面，以f4的字符數最少，但是速度提升最大的也是f4。f4比f3的改變僅僅是用map代替了for，如此小的改變獲得的效果比前兩個改變大得多。你可以把map當作是for被移到了C code裏了，唯一不好的地方是map的loop body必須得是一個function。結論就是一個program的效率最大影響的還是compiler，只要有内置相同作用的function，還是用内置的更快也更方便。

以上是我最近從http://wiki.python.org/moin/PythonSpeed/PerformanceTips所學到的小技巧，每种語言都有其類似的提升方法。

Good programming style的視覺美感不僅僅是如何format及indent，簡潔的code也總是能有更高的性能。如果要做一個更好的Programmer，光遵循書上或者老師教的好code是不夠的，優雅的code，那是必需的。

CM娘與Agile君

一個是靦腆寡言默默在背後服務的女僕式隨從，一個是當今最灸手可热的万人迷，兩人之間又有什麽不得不說的故事呢？

CM娘，可不是Agile君專屬的天使喲！早在Agile君成爲萬人迷很久之前，CM娘就默默地在幕後耕耘了，才不在乎誰是現在的主子呢。她不為堯存，不為桀亡，管你是瀑布君，還是叠代君，都能很好的為之服務。

只是她實在太不爭太小眾了，以至人們甚至都忘記她也是IEEE Computer society所制定的SWEBOK十大技術娘之一，知名度甚至遠不如其妹妹QA娘。爲什麽呢？人們難道忘記CM娘帶來的諸多便利的服務了嗎？


其實是在於，如果說Developer衆是一輛法拉利跑車，那麽CM娘就是這輛跑車上的各種減速系統。雖然速度被控制讓人很不爽，但這能避免你車毀人亡。

所以嘛，CM娘這個女僕，並不只是單純的服務於Developer眾的喲，她同時也監督著這些小祖宗們。所以這些小少爺呀，當然會去選擇性的忽略她，讓她越不起眼就越好。


回溯結束，讓我們就來開始開始八卦一下CM娘與Agile君的故事吧！

如前所述CM娘並不為Agile君而存在，她幾乎能適應各種主子們，所以呢，這個八卦的真相就是：其實是Agile君更需要CM娘！

爲什麽呢？如上一篇所述，Agile君的特質具有更大的多變性與適應性，並且需要進行更頻繁的交付。這些都需要CM娘們更多更細心地為他打理一切，進行調控和提供管理服務。

著名的Agile君專屬八卦雜誌AgileJournal.com曾經向Agile君的粉絲們推出一份問卷，請粉絲們為CM娘對Agile君的重要性從各方面進行投票，0分爲最不重要，10分爲最重要。

下面這份圖表，就是問卷答案在各方面的平均得分

我們可以看出，其中最低的平均得分“CM娘的報告”也有6分，而整體平均線在7.5分以上，可見就算是Agile君的粉絲，也是對CM娘的重要性相當的認同哦！

也難怪CM娘的粉絲們，如其專屬的八卦雜誌CMCrossroads.com會對這兩者的關係相當瘋狂的追逐了。在他們看來，這可是麻雀一朝變鳳凰，躍上枝頭衆人羡的美事呢。


在我看來，願望是美好的，但事情都不是那麽容易的。CM娘一直都是孤獨的CM娘，她缺少與其他人在同一個氛圍進行交流的機會，她的圈子太局限太被動了。這也是爲什麽CM娘的粉絲們那麽希望兩者能結合在一起，畢竟Agile君理論上也應該是獨行俠，現在卻大受歡迎。CM娘如果能學習Agile君身上的那些讓他流行起來的元素，例如專業集群化，那麽兩者就算最終不能在一起，又有何懼呢？

The Knight bringing Agile to the Day

Agile君是誰？

傳説很久以前，有一位聖騎士對他的國王說，我們應該給人民他們所需要的，而不是我們想給他們什麽就給他們什麽。並且，與其在他們已經等了很久以後再把他們想要得到的一次性全部給與，還不如分階段按需分配，這樣他們可以更快地獲得缺需的，從而改變他們的生活，讓人民更快樂。

聖騎士他認爲國家中的人民才是真正推動各種需求的，而政府所能夠提供的價值，其核心就在於如何讓人民從這個不斷改變的世界中感知並獲得他們的價值。

這位聖騎士就是被後人稱之爲Agile君的那位，他建立了Agile騎士團，制定了騎士團的四大信條：

1. 政績實效大於完整文檔。
   這不是說文檔不重要，只是人民更看重施政效果，而非口號、文件、以及各種上級部門所下達的各類指示。
2. 個體互動大於工具過程。
   這也不是說工具與過程不重要，只是要讓人民進行生産並不是把他們當成無腦的機械，而是需要通過體現個人，並相互之間的互動來達到。
3. 協同合作大於律法合約。
   只有當政府持續與人民互動時，才能減少危機的出現，才能帶給人民更多他們所需要的。
4. 適應變化大於盲從計劃。
   能夠適應各種變化地來與人民合作及進行控制；表現出各種意見都是受歡迎、可理解、什麽時候都是有其道理的誠意。

能夠擁抱變化，接受現實生活的這種不定性，Agile騎士團通過提供方法與技術來最大限度的降低風險並增加確定性來治國，這減少了政府與人民之間的隔閡，保證了政府能夠讓人民獲得他們真正想要的。

With that, the Knight brought Agile into the day and people into the light.

－－「Agile君做軟件則軟件大賣，治國則國富民強。」

Cloud

Cloud叔叔（右圖）與CM娘的關係？

按照之前所提到那些高人的説法：

1. Cloud叔叔現在在更多方面進行的擴展，這必將需要更多的CM娘來協助其進行管理；
2. CM娘通過Cloud叔叔的模式進行專業服務，這已經有許多案例，比如美麗雪梨情人港兼Market St FF旁的Atalassian就有提供CM娘專業服務的一些。

不過這兩個説法都很攀龍附鳳耶，弄得好像CM娘硬要和Cloud叔叔扯上關係似的。Cloud叔叔這種類型的新概念的普及，何時不是需要各種不同的技術娘來多多支持呢？
充其量，CM娘也只是獲得了更多打雜的地方而已嘛，在這方面電腦軟硬諸界以及下屬各領域的情況其實是差不多的才對。

而第二點則更是無稽，Cloud叔叔的這種服務概念，連小狐狸都自稱家裏的視頻共享也是其中一種，IT大千世界又有哪方哪面會應用不上呢？

在我看來，Cloud叔叔對CM娘來説最大的幫助，就是讓本來大多時間都是單獨勞作的CM娘們有更多可能性在一起工作，因爲那些提供Cloud叔叔的應用公司需要好多CM娘而非一個的說。

而其他組織大多數會因爲有了這種通過Cloud叔叔來提供服務的CM娘，就不再需要那種聘請一兩個CM娘來為整個公司提供各項服務的模式了。因爲被外包了，公司内部的Development Services將不再需要，剩下操控的部分則可能被整合入管理裏面（這就給了CM娘與Agile君親近的機會，當然這是後話）。

這種服務專業化的模式是大勢所趨，畢竟CM娘這種缺稀且需求不大的技術娘，無法像Developer眾經常可以通過討論交流來增強自己。大部分CM娘都是獨立工作，最多有事找找Google大神，很少能有互相交流提高的機會。有時候就算去一些CM娘大聚餐、High派對之類的，也都是聼彼此說一些誰不知道你媽是女的之類的東西，再喝喝酒，劃劃拳，讓人無法感知到半點Inspiration。

像Thoughtworks那樣，專業服務專業化，被包的公司可以得到更專業更有效率的服務，而各專業人才之間也經常可以交流，並且可以有渠道在不同行業不同公司提供技術性服務與咨詢，從而更大化的獲得知識，真是美哉！

Cloudy with a chance of Agility

到底我的job title是要換成SCM Engineer，還是Configuration Anaylst，亦或仍是Build Engineer，都尚不可知。但我已覺得CM(Configuration Management)是那麽的無聊，枯燥且缺乏變化。上手之後的大部份時間都是重復性勞作，缺乏創意與巧思的動力不禁讓我懷疑自己還敢這樣做多久。

不過，既然無法在短期（半年内）轉爲C++ developer，那麽秉著幹一行愛一行的原則，還是把本職做精了，做神了，至少做出成果，做出實績再説。既不跳出圈外，我就需要在圈内求變化。

首先要和一些先進性名詞挂上鈎，比如Cloud，Agile什麽的IT新抱，能拉多近拉多近。

Cloud云云，本來就是和IT所有東西可能有關的概念，最近連MS都趁熱打鐵推出了Windows Azure。我貼個近乎，也就是走走過場，理所當然不在話下。

至於Agile，以我敏銳的預判本能，早在半年多前就看到了CM和Agile之間不可分割的聯係，兩者的水乳交合，在公在私，正是大勢所趨。剩下的只是我將如何推進此跨時代的轉型？

Agile的書，看了不少；公司新的Dev Manager，也是Agile正統科班出身，正把這些信條步步帶入三樓。只是這些無論理論還是實踐的玩兒，聞之見之，都只覺是空泛之辭，難覺其妙，無法讓我有那種Programming時見到巧妙算法解決難題時候的興奮。

或者Engineering的東西就是這樣，按班就步，條條有理，不興奮，但穩妥。可悲的是這十分適合我的區域，卻讓我興趣缺缺。性格如此，興趣卻非如此，豈不奇哉怪也！

在這樣十字路口，需要的是高人指點迷津，沒有更多知識來獲取，那就需要前人的經驗。CM這貨，本來就是靠著經驗吃飯的活。

於是乎我上網查詢有關資料，想找一些高人的Blog來觀摩Follow。正好，讓我逮着了http://cmforagile.blogspot.com/，這也是爲什麽我會建此Blog，因爲我follow了人家的blog嘛！沒登陸是無法follow的，既然登陸了就順便建了。順藤摸瓜，又摸到了http://www.cmcrossroads.com/，與其連接或下屬的http://www.cmwiki.com/。

於是乎，歷史的車輪又再一次滾動了起來，但在此之前讓我先去FF Market St.！