目前分類:軟體開發 (16)

瀏覽方式: 標題列表 簡短摘要

研发管理中的轻量级思考方法 王福润(中兴)

這場要談的是系統思考與陰陽五行,之前因為對中醫有點興趣,在看到五行時,就覺得他是中國最佳系統思考代表,但是不知是不是時間的關係,我覺得許多關鍵點沒有交代的很清楚,所以收獲很有限。

 

所有事情都是平衡的,不平衡是因為你對它有期望。

陰中求陽,類似Satir的冰山理論,例如他"意願低",這時你要從另外四點去看看有沒有辦法改善。 

但是回來後,對系統思考有著墨的朋友似乎都對這主題不感興趣,William Yeh 給了一句話:過度化約論的學說,會變得什麼都可以解釋,卻也什麼也解釋不了 好像蠻有道理的啊...

不過老師有在微信上建了群,後續再讓我繼續一探虛實吧。

 

让价值顺畅流动——数据驱动转型之路 张燎原(阿里)

燎原是我去年在上海上 Less 時的同學,因為上次上課時有些討論讓我覺得他很有料,所以選擇這場。

他前半段在分享關於度量這件事,我覺得講的很好:一個好的度量,要講述完整的故事,並回答一個本質的問題。這乍看之下還是不大懂,但他後面舉汽車油耗的例子就清楚多了。

他也提到好的度量應該"由外度量",要由"整個系統"的外面去度量,否則會型成筒倉。例如千行代碼缺陷率、測試覆蓋率等等(像可以測出幾個 bug 我覺得也算)

好的度量才能引出正確的行為,燎原舉了英文窗戶稅(Window Tax) 的故事當例子,令人印象非常深刻,出發點是富人要多繳點稅,但最後卻變成大家把窗戶封起來...

接下來的分享講到流動效率、湖水岩石效應,持續交付,最後一路到 feature team。這部份比較常聽到,我就不再多寫了。

 

Walking Scrum history with patterns Kiro原田骑郎

聽完這場,發現 Kiro 桑根本就是大師級的人物啊 XD

從 pattern 的起源,一路講到 scrum 的起源,當中的 pattern,其實重點都寫在這裡了: http://scrumbook.org/   

連ScrumMaster / Product Owner 都是有 pattern 的 (Sacrifice One Person):

  • If a smaller diversion hits your team, Then: assign just one person to it until it gets handled.

欣赏式探寻-激发团队的无限潜能 五毛(一块工坊)

這門課感覺很注重在NLP,一開始講師讓小組內大家去分享二個自身的優勢,並搭配自身的故事來說明這兩個優勢。在說故事時,小組其它成員可以做三件事:

1.亮點:故事中還透露出的其它優勢

2.共嗚:分享者的優勢跟自己一樣,可以表達共嗚

3.探詢:問故事中的其它問題

我覺得重點在於AI是鼓勵大家用正面去討論問題,有一個很重要的點:組織是個機器,還是個生命體?AI 欣賞式探詢的發明人 David Cooperrider 說:組織是個值得擁抱的奇蹟

從昨天的李衛紅到今天的五毛,都蠻強調正向、相信人的潛力這塊的,後來發現他們是 重塑組織 這本書的翻譯人員之一 。

重塑組織可以看看 Yves 的介紹,馬上就有點概念:

https://funevo.com/2016/07/12/reinventing-organizations-agile-transformation/

也因為這門課,讓我認真去看了 "比賽,從心開始" 這本書,但是仍然覺得領導團隊、重塑組織這塊還有很多東西要學,還有很長的路要走。

diro 發表在 痞客邦 留言(0) 人氣()

http://scrumgatheringchina.com/2018/

RSG 10 年了,不過今年是我第一次參加 XD

三叔公已經在第一時間寫好了重點,我就另外再寫些他沒提到的吧 :-)

 

Keynote - Bas Vodde

Bas Vodde 在演講中有說到,一個好的演講應該是會好好利用說故事來分享觀念的,他就接著分享了一個小故事:

有一次,他在新加坡,正在開車載小孩回家,但是非常塞車,行進非常緩慢,小孩坐在車上有點不耐煩,跟就 Bas 說他想要車子開快一點...

Bas:但是現在塞車,就只能這麼慢

child:對向車道沒有車,我們可以開對向車道,就可以很快了

Bas:但那是 wrong direction,你要慢慢的往 right direction 前進,還是快速的往 wrong direction 前進?

child: 快速的往 wrong direction!

Bas 要表達的意思是,很多組織只看速度,卻不理會方向正不正確,這是很可惜的一點。

此外,Bas 也再次強調 feature team 的重要性及好處

 

騰訊敏捷轉型之路 - 薛軍

強調 feature team 的重要性,騰訊在轉型後也轉向 feature team.

當時CTO發現騰訊決策慢、離用戶遠,因此決定導入敏捷

當時訂了一個KPI,要把用戶從200W人變成400W人,所以大家的想法就是:加功能,就搞出了邊發郵件邊聊天 =.=,這是傳統軟件思維公司的做法,因此失敗了

當時QQ的刻板印象就是給年輕人用的,是玩具,因此他們改從 qqmail 出發。 

發佈為終 -> 發佈為始

投資很多資源在CI及自動化測試,做到每天release

不再寫進度報告(證明你媽是你媽...),而是用 working software 來代表一天的工作成果。每天 daily scrum 前,先玩半小時自己昨天的產出。

用戶有感這覺的事再做,不要去優化工程師自high的東西

優化用戶的高頻行為,就是一種減法策略

不敏捷,無微信

微信的 UX 進化之旅也蠻有意思的,很多小細節都很貼心,說當初 CTO 大概寄了一千封信出來討論一些功能上的 refine

 

重新塑造组織 - 李衛红

Bosch 的敏捷轉型推動者,分享了他在 Bosch 推動的心路歷程,比較偏向引導、人性、心靈層面領域。

我要強調的是,Bosch 也是 feature team 的架構(他們稱為 purpose team),這已經是今天第三次提到 feature team 了。

 

全链路项目管理 刘煦萍、曹靓(网易)

學了二個遊戲:拼樂高及 pizza工廠,這兩個應該在網路上都可以找到。

拼樂高要讓大家體會的是需求有多麼難描述清楚,以及你應該跟客戶更加緊密的溝通

Pizza 工廠跟傳球遊戲有點像,讓大家思考如何改善流程,還蠻有意思的。

我覺得相較於樂高遊戲,Jugg 的 Scrum Drawing Game 其實更好玩,可能也是時間比較充足的關係,更能讓你體驗整個 Scrum 的架構及精神,我真心推薦大家有機會一定要試試。

 

今日小結

Tell Story、Feature Team、相信人與團隊、遊戲學習

其實有時候跟大家交流並沒有什麼新東西 ,但重點是有些舊東西又會重新的啟發你一些想法,例如今天大家一直提到的 feature team,這概念很普通,但你在組織內可能沒有做的很好,現在一直收到 feature team 的訊息,又會讓人重新審視一下自己目前的狀況。在不同的 context 下,一樣的訊息會給你不一樣的啟發

引導及團隊這塊,當更偏向心靈層面時,是我一直比較弱的地方,我想接下來可以好好拜讀衛紅老師的文章,希望能有更多啟發。其實敏捷像是東西方哲學在靠攏時的一個中間產物。因此中間牽扯到的知識實在是太廣泛了。

diro 發表在 痞客邦 留言(0) 人氣()

QML extension

 


 

For QML extension (inherits from QQmlExtension) , you have to place the custom QML extension into the qml folder in Qt installed directory (ex: /Users/diro/Qt5.3.0/5.3/android_armv7/qml).

Take the extension DiroComponent for example, then you should have a directory named /Users/diro/Qt5.3.0/5.3/android_armv7/qml/DiroComponent , and the libDiroComponent.so & qmldir should be put in the directory, too. Finally, the androiddeployqt tool will pack this custom QML extension into the APK file for deploying. 

For the underlying detail, the androiddeployqt will rename the .so file into libqml_DiroComponent_libDiroComponentExtension.so, and copy it into build_dir/android-build/libs/armeabi-v7a (Actually, all the native .so shared library are placed here)

Now you can enjoy your QML without any modification.

 


 

QML extension (inherits from QQmlExtension) 的作法比較特別,你必需把你的 QML extension 乖乖的放到 qt 安裝目錄中的 qml 資料夾(ex: /Users/diro/Qt5.3.0/5.3/android_armv7/qml)。例如你有個 extension 叫做 DiroComponent,那麼你就會有個
/Users/diro/Qt5.3.0/5.3/android_armv7/qml/DiroComponent 資料夾,並在裡頭放著你的 .so & qmldir,這樣子 androiddeployqt 就會把你的 QML extension 打包進 APK 中。

打包的細節部份,他會 rename 你的 .so,變成 libqml_DiroComponent_libDiroComponentExtension.so ,並放進 build_dir/android-build/libs/armeabi-v7a 裡頭(其實所有的 .so 都會被放在這,包含 implicit&explicit link 的 shared library)

這樣子你就可以在你的 QML 中快樂的使用這些 extension ,不需要做任何更改。

diro 發表在 痞客邦 留言(0) 人氣()

在很多時侯我們會用到自己開發的Plugin,但是在Android平台上要如何才能載入呢?

重點在於要把要被載入的plugin (.so) 放在正確的資料夾

build/android-build/libs/armeabi-v7a

這樣就可以正確被load到了。

 

但如果有些 plugin 是在其它 project 中預先 prebuilt 好的,那麼要怎麼樣包進來呢?

作法1 - ANDROID_EXTRA_LIBS

基本上這是最標準的用法,如果沒什麼問題,只要把你會用到的lib (.so) 加進這個變數即可

http://qt-project.org/doc/qt-5/deployment-android.html

 

作法2 - Custom Process Step

你必需在 project 中新增一個 Custom Process Step,在 androiddeployqt 打包之前把 .so 放好,以便一並併入 .apk 中。

[Make install]

[Custom Process Step]

cp xxx.so build/android-build/libs/armeabi-v7a/xxx.so

[Deploy Configurations]

diro 發表在 痞客邦 留言(0) 人氣()

新版的QtQuick已經改用QQmlApplicationEngine取代原本的viewer class,因此要取得application的snapshot作法也不大相同:

class SnapshotMgr

{

void getSnapshot(void);

QQmlApplicationEngine m_pEngine;

}

void SnapshotMgr::getSnapshot(void)

{

if(!m_pEngine)
return-1;

foreach(QObject*obj,m_pEngine->rootObjects()){
QQuickWindow*window=qobject_cast<QQuickWindow*>(obj);
if(window){

QImageimage=window->grabWindow();
image.save("./test_screenshot.jpg");
qDebug()<<image;
}
}
return0;
}

diro 發表在 痞客邦 留言(0) 人氣()

Canvas 可以說是 QML 最令我激賞的 element 之一,我認為它對 QML 在實用性上的提昇遠超過許多 Qt Quick 2.0 加入的 elements.

遙想當年的 HTML,在沒有 CSS, Canvas 等等神器的時代,要畫個線是多麼驚人的壯舉,要設計個圓角矩形更是非得出得繪圖軟體..

雖然 Canvas 在 Qt Quick 2.0 才被加入,不過其實它已經存在很久了 (見之前的討論串 http://qt-project.org/forums/viewthread/11689 不得不說 Qt Labs 真的是創造了許多好東西)

canvas 帶來最大的好處,便是可以利用程式產生圖形,不必再仰賴圖檔,也可以做到各式各樣的 UI 進階應用,尤其是在資料報表、Data Visualization的部份,如 D3.js (http://d3js.org/)  的呈現效果(註:D3使用的是CSS + SVG)

現在 QML 有了 canvas,也許有一天也可以看到 D3.js 等級的 library 也說不定!

--

以前大概只能用Rectangle來畫畫直方圖吧..或著用一堆Rectangle + Rotation 硬幹出一個效能很差的折線圖 XDDD

diro 發表在 痞客邦 留言(0) 人氣()

這個故事是發生在 Qt 4.x 身上.在這個版本中,要 parsing JSON,最簡單的方式就是用 QScriptEngine 去呼叫 JavaScript 來 parsing,再用 QScriptValue 得到結果即可(註:在 Qt 5.0 之後已有現成 API 可以使用 https://qt-project.org/doc/qt-5.0/qtcore/json.html).

但 QtScript 中的許多函式並不是 thread-safe,如很常使用到的 QScriptEngine::evaluate(),QScriptValue::call() 如果你multi-thead 去執行,將會得到不可預期的結果.

看一下QScriptValue 的 source code,可以發現到它會出問題的點可能跟使用 d->engine->currentFrame 有關.(當然,可能還有很多地方都不是 thread-safe,必竟原本就不是要設計成 thread-safe)

1558 QScriptValue QScriptValue::call(const QScriptValue &thisObject,
1559 const QScriptValueList &args)
1560 {
1561 Q_D(const QScriptValue);
1562 if (!d || !d->isObject())
1563 return QScriptValue();
1564 QScript::APIShim shim(d->engine);
1565 JSC::JSValue callee = d->jscValue;
1566 JSC::CallData callData;
1567 JSC::CallType callType = callee.getCallData(callData);
1568 if (callType == JSC::CallTypeNone)
1569 return QScriptValue();
1570
1571 if (QScriptValuePrivate::getEngine(thisObject)
1572 && (QScriptValuePrivate::getEngine(thisObject) != d->engine)) {
1573 qWarning("QScriptValue::call() failed: "
1574 "cannot call function with thisObject created in "
1575 "a different engine");
1576 return QScriptValue();
1577 }
1578
1579 JSC::ExecState *exec = d->engine->currentFrame;
1580
1581 JSC::JSValue jscThisObject = d->engine->scriptValueToJSCValue(thisObject);
1582 if (!jscThisObject || !jscThisObject.isObject())
1583 jscThisObject = d->engine->globalObject();

 

 

diro 發表在 痞客邦 留言(0) 人氣()

在 linux console 下編寫一些 script 時,為了表示 script 還有在運作,常用一個 rotating animation 或著 dot animation 來讓 script 看起來有在動作。那麼在 linux 下要如何呈現這種效果呢?

while [ true ];

do
  i=$((++i%4 + 2));
  printf '\b|/-\' | cut -b 1,$i | tr -d '\n';
  sleep 1;
done

關鍵是利用\b及tr -d '\n',達成同個位置不斷呈現不同文字。再搭配 cut 來輕鬆的在|/-\四個字元中輪播。當然,習慣用 echo 的,也可以把當中的 printf 換成 echo

echo -e '\b|/-\' | cut -b 1,$i | tr -d '\n';

 

Reference:

http://stackoverflow.com/questions/10470139/creating-rotating-circle-using-characters-in-shell-script

diro 發表在 痞客邦 留言(0) 人氣()

Spotify 是最近頗火熱的音樂串流軟體,之前一直沒有留意他們的研發團隊,直到最近讀了《台灣軟體產業的失落十年》,才從中去研究了一下Spotify的團隊運作模式。

英文:http://ucvox.files.wordpress.com/2012/11/113617905-scaling-agile-spotify-11.pdf

中文:http://zh.scribd.com/doc/148375738/Scaling-Agile-Spotify-%E4%B8%AD%E6%96%87%E7%BF%BB%E8%AD%AF%E7%89%88

精美投影片:http://www.slideshare.net/vmysla/scrum-at-spotify

整篇文章最令我印象深刻的是他們的研發團隊成長速度:三年,從30人成長到250人。這需要多大的管理能量?我一直認為引進新的工作伙伴,需要培養他的技能、融入工作文化,這有時侯需要數個月甚至一年才能完成,而 Spotify 竟然以不可思議的速度在擴張,秘訣到底是什麼?

我覺得有幾點是比較重要的:

 

用優沃的薪資雇用優秀的有經驗人才:

Glassdoor 的資料來看,Spotify的software engineer 薪資在 100K~155K 之間,這在美國甚至全球的軟體工程師界都算是非常高的薪資(可以參考 Glassdoor 去年的 25 Highest Paying Companies For Software Engineers (2013)),基本上與Yahoo, Google, Facebook等大公司是差不多的。

基本上,這種薪資水平雇用進來的人,你不大需要培養他的技能,他的技能應該有相當程度的水準,並具備高度的自我學習能力,總之,丟東西給他,他自己會完成。這一點,解決了培養技能的問題。

此外,利用這些人組成的 Agile Team,是一個很優秀的團隊:Self-organized, Self-motivated, Responsible, Communiactive, Senior and Perfect(請參考上頭的投影片)

 

Agile Team - 班 & 工會制度:

Spotify 裡頭約略有 30 個班,不過在這裡班並不是重點,重點是公會制度,讓每個班裡頭負責不同工作的人可以彼此交流(Agile工會,Testing工會,Web工會...)因此新形成的 team 除了在技能上很快跟大家一致外,在文化上也比較容易接近。新進的測試人員可以在公會中得到公司對於測試人員的工作期望,以及測試人員該肩負的使命。

 

用品質營造更棒的工作氛圍

Spotify有提到他們沒有 release 時程,只有等到品質夠好,他們才會推出。這一點堅持可以提昇員工對產品的認同感與榮譽感(沒有一位專業人士會想在市面上推出一個爛產品),一但這種精神成為公司文化,會比薪資更吸引優秀人才的加入。此外,堅持品質能減少技術債的產生,員工們不會花大量的時間在償債,大家可以真的實踐創意,開發新東西,可以讓整體工作氣氛更棒更有趣!

 

結論:用對的人,堅持做對的事。

我們不斷往這個方向邁進,期許能成為卓越的軟體公司 :)

diro 發表在 痞客邦 留言(0) 人氣()

I am developing an embedded system with a local display and multilingual support. Now I am wondering if my font contain all the glyphs the system need.
Of coz, we always google it first, but...

 

Method 1 (Qt)

http://stackoverflow.com/questions/2681405/how-to-detect-missing-font-characters

https://bugreports.qt-project.org/browse/QTBUG-1732

 

Yes, the Qt have a bug (actually, it isn’t a bug, but user misunderstand the document), so we can’t do it easier with Qt.

 

Method 2 (GDI – GetGlyphIndices())

http://msdn.microsoft.com/en-us/library/windows/desktop/dd144890(v=vs.85).aspx

But I think it is too complex, the DC is surplus in my case, I just want to focus on font!

 

Method 3 (FreeType library)

Finally, I decide to use python + freetype library to solve my problem. With this script, you can input a TTF file and a text file(UTF-8), and than it will report you what character in the text file is missing with this TTF font.

 

Source Code:

https://github.com/diro/pyGlyphChecker

 

Thanks for the freetype-py library XD

https://code.google.com/p/freetype-py/

diro 發表在 痞客邦 留言(0) 人氣()

iSwifter makes iPad game streaming available to all PC game companies (exclusive)
(摘自 Venturebeat.com)

iSwifter這家公司號稱可以流暢的傳送影像畫面到iPad上,使的iPad可以玩 Flash games 或著其它的遊戲。簡單的說,它讓遊戲在雲端執行,然後擷取畫面,再傳送到iPad上,接著接收使用者的輸入,再丟回正在雲端上執行的遊戲。看似簡單,但如果延遲時間能處理的很好,那就很值得研究一番了 XD

這種雲端技術應該可以解救不少從 Desktop Application 一直跨不進 Mobile Device 的廠商吧

之前有 OnLive 及 Gaikai 兩個選擇,但對硬體需求較高。iSwifter 則是宣稱它不需要這麼好的硬體,但相對的畫質也就略差了些。

Reference:

  1. http://venturebeat.com/2012/03/05/iswifter-makes-ipad-game-streaming-available-to-all-pc-game-companies-exclusive/
  2. http://iswifter.com/

iSwifter makes iPad game streaming available to all PC game companies (exclusive)(摘自 Venturebeat.com)

iSwifter這家公司號稱可以流暢的傳送影像畫面到iPad上,使的iPad可以玩 Flash games 或著其它的遊戲。簡單的說,它讓遊戲在雲端執行,然後擷取畫面,再傳送到iPad上,接著接收使用者的輸入,再丟回正在雲端上執行的遊戲。看似簡單,但如果延遲時間能處理的很好,那就很值得研究一番了 XD

這種雲端技術應該可以解救不少從 Desktop Application 一直跨不進 Mobile Device 的廠商吧

之前有 OnLive 及 Gaikai 兩個選擇,但對硬體需求較高。iSwifter 則是宣稱它不需要這麼好的硬體,但相對的畫質也就略差了些。

Reference:

  1. http://venturebeat.com/2012/03/05/iswifter-makes-ipad-game-streaming-available-to-all-pc-game-companies-exclusive/
  2. http://iswifter.com/

diro 發表在 痞客邦 留言(0) 人氣()

要打造一個效能良好的 Multi-Thread Application 是難度相當高的一件事,一般來說第一個會碰到的問題就是因為 synchronization objects 的 contention 造成的效能下降,通常可以用 atomic operator 及 lock-free algorithm 做一些改善。而隨著現在 CPU 的核心數愈來愈多,又把難度向上提高了不少 Orz。其它常碰到的問題包括了:

第一個是 Load imbalance:假設你的電腦是 4 cores,理想上開 4 threads 來做事是最好的,但是這 4 個 threads 要做的事情必需一樣重,不然就會有人是閒閒沒事做,別人操的要死的狀況,如果你是開發演算法,可以考慮用 Intel TBB 中的 task 來解決這個問題。

第二個是 Threading overhead:大家都知道 context switch 是很花時間的,但是並不是說 threads 愈少就一定愈好!這是一個很複雜的問題,留待之後再來討論~

第三個是 Memory Bandwidth Bottleneck:因為每個 thread 它所需要讀取/寫入的資料有可能是毫無關聯的,但因為資料及指令是需要被讀入 L1 Cache 才能執行,因此會大幅增加 cache line miss 的機率,一般來說L2 Cache 比L1 Cache慢約七倍,而 Main Memory 就更不用說了,更是無敵慢,因此這點將會是造成效能問題的最大瓶頸。老實說,這是我目前覺得最難處理的:如何讓 cache 及 memory 作最好的運用。

前面三個問題(sync obj, imbalance, overhead)比較容易解決,Intel 的工具 Thread Profiler 可以幫你很有效的分析出問題所在,下面這份教材是我目前看過最好的,如果你現在在開發 Multi-Thread Application,你一定要看一看這一篇:

http://www1.ju.edu.jo/ecourse/cpestcourse/notes/Intel/06%20Edited_ThreadProfiler.ppt

Thread Profiler 可以讓你在不需要修改程式的狀況下就進行分析,支援了目前大部份主流的 compiler,而且可以跟 source code 結合,直接指出問題的所在~你也可以拿來分析你 Synchronization Objects 的 contention 狀況, 強力推薦。

至於記憶體的問題,則是要請出神器 Vtune 來解了,我們下回再做討論~

diro 發表在 痞客邦 留言(0) 人氣()

在 debug 時最常用到的就是 symbol file / symbol server,然而相信常有 load 不到 symbol file 的經驗,不管怎麼按,怎麼換,不對就是不對,有時覺得明明就放對了,還是不能用 Orz。如果你用的是 VS.NET,應該永遠都只能繼續怨天尤人、哭天搶地了,但如果你用的是 windbg 的話,那麼請照著下面步驟來解決這個問題。

例如我在追查memory leak的時候,去分析一個 address 的 call stack

!heap -p -a 0x12344545

結果得到的 callstack 非常詭異,一看就覺得不可能,或著它很明顯的告訴你「Following frames may be wrong」,那們八成是 symbol 不正確了

首先要先判斷為什麼 load 不到,先用 sym 打開 symbol 的詳細訊息

!sym noisy

此時重新執剛才的指令 !heap -p -a 0x12344545, 此時它便會告訴你它有那些 symbol file 是有問題的

  1. checksum 不正確
    1. 如果你確定 symbol (.pdb) 是對的, 或著你是重新用一模一樣的 compiler setting 所編出來的 pdb,那麼你可以試看看強制忽略 checksum
    2. .reload /f /i [xxxxx.exe]
  2. 根本找不到 .pdb
    1. 請注意看 message,它會告訴你它在那些目錄下搜尋過 pdb,看一下你的 pdb 是不是真的放對位置了吧! (如果你連 symbol path都不會設,趕快去翻一下手冊吧)

通常這樣就可以解決大部份的問題了, 而 !sym noisy 還可以顯示 .pdb 中的一些警告資訊,如 source index 沒有做之類的, 相當有幫助。

最後別忘了用 !sym quiet 把 message 關閉,才不會看到一堆沒有用的訊息。

diro 發表在 痞客邦 留言(0) 人氣()

上次介紹的 TeamCity 預設是不支援 Boost Unit Testing Framework 的,需要額外的 plugin 才能將Boost UTF 的測試報告整合進 TeamCity 中。

首先先到 TeamCity 官方網站下載 plugin,檔案在
http://confluence.jetbrains.net/display/TW/Cpp+Unit+Test+Reporting
裡面有一個 teamcity-boost-1.2.zip for Boost.Test library,下載回來之後解壓縮可以得到三個檔案

teamcity_boost.cpp
teamcity_messages.cpp
teamcity_messages.h

只要將這三個檔案加入你原有的 testing project 中即可,不需更改任何設定。

咦,這麼神奇,為什麼這三個檔可以達到這種效果,答案是它是用了 UTF 中的Global fixture,如果你不知道什麼是 fixture,可以先去查詢一下軟體測試的相關文章。這個 Global fixture 會去處理每個Test Case的測試結果,並加以回報給 TeamCity,整體的整合度還蠻高的,可以看到有那些 Test Case,有那些 PASS 以及那些 FAILED,當然FAILED 的訊息也會完整的呈現。

diro 發表在 痞客邦 留言(0) 人氣()

大教堂和市集(The Cathedral and the Bazaar) 是一篇相當有名的文章,不過之前一直沒有看,直到後來讀了Dreaming in Code 一書後,才把這篇文章仔細讀完。這篇文章是由 Eric Steven Raymond 所寫,內容在描述 Linux 的開發模式(市集)及Raymond 自己仿照這個模式開發 fetchmail 的過程,並探討其為什麼成功,其中列了十幾項格言,有幾項個人還蠻有感覺的,如果你覺得你的團隊現在碰到了一些瓶頸,推薦你可以讀讀這篇文章。

http://www.linux.org.tw/CLDP/OLD/doc/Cathedral-Bazaar.html 這篇文章的翻譯翻的蠻好的,推薦!

[格言 1] 好軟體都是起源於程式發展者要解決切身之痛.
[格言 14] 任何的工具以我們所知道的方法來使用都會有用, 但一個真正了不起的工具會以你從未想過的使用方法來發揮它的功能.
[格言 19] 假如專案發展協調者擁有至少跟網際網路一樣好的媒體, 而他也不靠強制力來領導, 那麼一群人必定勝過一個人.

其中我認為最要的,仍舊是格言 1,因為它背後的含意是"熱忱",有熱忱才能開發出好的軟體,如果你的團隊不知他為何要打造這個軟體?這個軟體到底有什麼用處?那麼,這個軟體註定不會成為一個優秀的軟體。

diro 發表在 痞客邦 留言(0) 人氣()

http://www.jetbrains.com/teamcity/index.html

持續整合是軟體開發時相當重要的一環,透過持續整合可以了解目前專案的狀態,包含是否能正確編譯、通過測試,甚至是整體的整合是否也運作良好。在現實的軟體開發環境中,其實很有可能因為修改了一行程式碼,便讓整個專案陷入無法編譯或運行結果不正確的狀態,而如果這個專案又是多人開發且高度相依,更有可能會影響到別人的作業。

  1. 不但影響別人的工作流暢性,使其離開神馳(flow)的狀態,更會讓程式設計師進入一種非"愉悅"的狀態。而程式設計師一但離開神馳或著進入非愉悅狀態,生產力將大幅下降(請參考Refactoring to Patterns及Peopleware)。
  2. 更甚者,每每到了產品要Release的時候,才發現整合不起來,導致在緊要關頭呈現兵荒馬亂的慘況(且嚴重影響士氣)。

以往要做到持續整合(Daily Build + Daily Test),是採用手寫script的方式進行,但是自己就要處理許多部份,包含checkout source code, compile, test, report, email 等,但最近用了JetBrain 的 TeamCity,發現原來世界是這麼的美好 :) 我再也不用手工去打造這個環境了。


其實原本實在試 CuriseControl.Net,不過因為前幾天他的網站進不去,我就另外找到這套 TeamCity,不但容易安裝而且功能強大,在這裡稍做說明。

我的開發環境是VS.NET 2008,主要以C/C++為主,測試框架是採用Boost Unit Test Framework,而 TeamCity 原本是不支持boost的,因此還花了一番功夫才整合起來,這部份之後再撰文描述。

先看看TeamCity有那些優點:

  1. 容易安裝、設定,只要一個安裝檔案裝完,就已經完成,包含Server, Agent, WebServer等
  2. VCS Monitor,可以設計成只要有人commit code就自動做編譯及測試
  3. 支援許多編譯及測試環境(VS.NET, Ant, Command Line, NUnit, MSTest, CPPUnit...)
  4. 超強的Agent系統,可以建立Cloud Computing的環境來做編譯的動作,不必集中在一台Server
  5. 支援超多種VCS,大概唸的出來的都支援了(SVN, SourceSafe, Git, TFS...)
  6. 支援自行開發plugin,我的Boost Unit Testing就是這樣完成的
  7. 提供專業免費版(有20個Configurations旳限制)
  8. 豐富的回報機制(IM, e-mail, RSS, System Tray Notifier, IDE Plugin...)
  9. Personal Build功能,在commit前會先做build/test,test pass才會幫你commit code
  10. 其它的可以參考官方網站的Feature List

現在在導入TeamCity後,我只要在網頁中就可以看到所有projects的狀態,包含checkin的訊息、修改資訊、編譯狀態、測試狀態,對於要管理這麼多projects時,真的是非常方便。下面是官網的示範圖片(看看它有多少test cases,再看看自己的有多少 Orz)。

強烈推薦一定要試看看,這個比FireScrum還要有價值許多

diro 發表在 痞客邦 留言(0) 人氣()