comp.software.extreme-programming Google Group

Call for Papers: The 2010 International Conference on Foundations of Computer Science (FCS'10), USA, July 2010

amgs...@yahoo.com (A. M. G. Solo) — Sat, 12 Dec 2009 06:57:24 UT

It would be greatly appreciated if this announcement could be
shared with individuals whose research interests include
theoretical foundations of computer science. Thanks.
-------
CALL FOR PAPERS
and
Call For Workshop/Session Proposals

Call for Papers: The 2010 International Conference on Computer Graphics and Virtual Reality, USA, July 2010

amgs...@yahoo.com (A. M. G. Solo) — Wed, 12 Dec 2009 05:35:03 UT

It would be greatly appreciated if this announcement could be
shared with individuals whose research interests include
computer graphics and virtual reality. Thanks.
-------
CALL FOR PAPERS
and
Call For Workshop/Session Proposals
CGVR'10

Software Configuration Management: Continuous Integration Widely Adopted

edi...@methodsandtools.com (editormt) — Tue, 11 Nov 2009 20:54:30 UT

A recent Methods & Tools poll tried to evaluate how software
configuration management (change management / version control) is
performed by organisations. Is it an informal activity or performed
with formal procedures that are validated by an automated tool?
Read the results on [link]

Re: Extending pair programming to groups

phlip2...@gmail.com (Phlip) — Fri, 11 Nov 2009 20:22:24 UT

The goal is high-quality, realtime communication & decision making.
Pairs rotate frequently, so everyone learn to work with all the modules. And
pairs should work on "pairstations", with dual keyboards & mice. The
pairstations should be in a common programming room, so people can overhear
who's having trouble.

Extending pair programming to groups

rohitagarwa...@rediffmail.com — Sat, 10 Oct 2009 14:34:56 UT

In XP, you use pair programming -- a pair of programmers work on a
piece of code together. Can this idea be extended to a larger group of
programmer like say the entire project group?
While this would require greater documentation since more than two
people can't work at one PC, one obvious benefit would be that

titanium ecm2001 crack torrent rapidshare download free dGuMRnz^EN

ecm2001.win...@free-downloads.com (ecm2001 winols cpwin rapidshare torrent) — Mon, 10 Oct 2009 03:41:49 UT

We can crack or emulate any protection type: Dongle,
Hardlock, Hasp, Serial, Password, Hasp4, Flexlm, Sentinel,
Wibu, Eutron Smartkey, Hasphl, Proteq, All the Protections!!
email = yshowsoft@???
email = yshowsoft at gmail.com
ecm2001 titanium download
ecm2001 titanium rapidshare
titanium ecm2001 torrent

ecm2001 crack torrent rapidshare download free mPCC)aiGuX

ecm2001.win...@free-downloads.com (ecm2001 winols cpwin rapidshare torrent) — Sun, 10 Oct 2009 20:20:57 UT

We can crack or emulate any protection type: Dongle,
Hardlock, Hasp, Serial, Password, Hasp4, Flexlm, Sentinel,
Wibu, Eutron Smartkey, Hasphl, Proteq, All the Protections!!
email = xshowsoft@???
email = xshowsoft at gmail.com
ecm2001 download
ecm2001 rapidshare
ecm2001 torrent
ecm2001 crack
ecm2001 v 5.3

[ANN] Scrum Project Management in Methods & Tools Fall 2009

edi...@methodsandtools.com (editormt) — Wed, 09 Sep 2009 16:13:49 UT

Methods & Tools is a free e-magazine for software developers, testers
and project managers. Fall 2009 issue's content:
* Mature Scrum at Systematic
* Implementing Automated Software Testing
* The Spring Framework
* The Learning View
* Time and Synchronization in Executable UML
75 pages of software development knowledge that you can download from

Re: how to avoid continuous integration build problems blocking agile developers

paul.sinn...@gmail.com (Paul Sinnett) — Sat, 09 Sep 2009 15:16:49 UT

My guess is that a pure XP approach is unsuited to the project you are
describing. I think you'll need to make adjustments for these
problems. You describe the size of the project as "large," whereas XP
was designed for a team of a dozen. You have real-time requirements,
whereas XP was designed on (I think I'm correct in saying) an offline

Re: how to avoid continuous integration build problems blocking agile developers

johnro...@gmail.com (John Roth) — Fri, 09 Sep 2009 20:35:12 UT

Do these timing problems show up in production, or are they an
artifact of the way that tests are being written?
John Roth

Re: how to avoid continuous integration build problems blocking agile developers

marlow.and...@googlemail.com (Andrew) — Fri, 09 Sep 2009 07:54:53 UT

Yes. The selenium tests are failing due to timing issues. Sometimes
the test code waits for something asynchronous to happen and does not
wait long enough. These errors are intermittant.
Problems in the test code. It is very dangerous to have to wait for
asynchronously computed results in tests.

Re: how to avoid continuous integration build problems blocking agile developers

paul.sinn...@gmail.com (Paul Sinnett) — Wed, 09 Sep 2009 08:48:26 UT

Can you describe a case where a test passes on the developer's machine
but fails on the server?
What is the cause of the error?

Re: how to avoid continuous integration build problems blocking agile developers

johnro...@gmail.com (John Roth) — Tue, 09 Sep 2009 13:04:16 UT

XP doesn't distinguish between unit and integration tests; code
is integrated on the developer's machines. What the integration
system is for is to catch the, hopefully very rare, occasions where
two developers have made incompatible changes and a race
condition occurs.
In the same sense, previously passing automated acceptance tests

Re: how to avoid continuous integration build problems blocking agile developers

marlow.and...@googlemail.com (Andrew) — Tue, 09 Sep 2009 06:59:52 UT

I should have mentioned that the failing tests are always at
integration or acceptance level. Of course the unit tests should
always run as part of the build and any unit test failure should cause
the build to fail.
See above.
The test suite IS being run on the developers machine.

Re: how to avoid continuous integration build problems blocking agile developers

johnro...@gmail.com (John Roth) — Mon, 09 Sep 2009 15:45:47 UT

The standard XP answer is that you should never have failing
unit tests. Period. End of discussion.
So I'd ask why failing unit tests are happening in the integration
process in the first place? This should be a very unusual occurrence,
not an everyday occurrence.
At a guess, the relevant part of the test suite isn't being run on