Up ] [ Link Farm ]
Reload ] [ Top ]
  autobuilder and unit tests  
tools:
BuildBot - writeup; Large user; Ximian mono
Continuous Integration
Test::Autobuild also, Test::Autobuild - perl autobuilder Daniel Berrange and Dennis Gregorovic (archive), build-env.txt (local) - perl
DamageControl CodeHaus (continuous integration) - Java based
Continuous Integration and automatic building, Martin Fowler - Cruise Control at SourceForge- Mandrake
Mezzanine Michael Jennings - Scons software construction tool, ex Software Carpentry competition -

.spec file lint - Florian La Roche - local

Chroots and initfs
initrd from RPMs without yum solver - Andrew Mileski - (local copy)
Miscellena:
LSB Bugzilla
Articles:
Ant at Apache.Org - Martin Fowler articles index -
Cross-Compile in Debian - Reexamining The Cost of Change Active Listening during requirements generation (wish exposition); listen early, listen well - Continuous Integration feature matrix -
See also:
Quality Assurance - Unit Testing -
http://primates.ximian.com/~thunder/bb/doc/html-docs/doc/bb-overview.txt.html
http://www.luntsys.com/luntbuild/index.html
http://www.urbancode.com/projects/anthill/default.jsp	

In June 1999, Tim Peters channeled Guido and listed 19 guiding principles
for Python's design in a comp.lang.python posting. The principles
shouldn't be taken too seriously, as they're not hard-and-fast constraints
and for each rule you can probably list instances where it's been broken.
Still, no one has had much disagreement with this list of design criteria.

    * Beautiful is better than ugly.
    * Explicit is better than implicit.
    * Simple is better than complex.
    * Complex is better than complicated.
    * Flat is better than nested.
    * Sparse is better than dense.
    * Readability counts.
    * Special cases aren't special enough to break the rules.
    * Although practicality beats purity.
    * Errors should never pass silently.
    * Unless explicitly silenced.
    * In the face of ambiguity, refuse the temptation to guess.
    * There should be one -- and preferably only one -- obvious way to do it.
    * Although that way may not be obvious at first unless you're Dutch.
    * Now is better than never.
    * Although never is often better than right now.
    * If the implementation is hard to explain, it's a bad idea.
    * If the implementation is easy to explain, it may be a good idea.
    * Namespaces are one honking great idea -- let's do more of those!

Don't take these 19 aphorisms too seriously -- tattooing them on your body
is probably a bad idea, for example -- but it's instructive to contemplate
them. Some parallels can be drawn to the guiding principles of extreme
programming, most notably the emphasis on "Do the simplest thing that can
possibly work".

 
 
  Site search:  
    
    
 
 Modified: Sun, 01 May 2005 23:18:16 -0400
Copyright © 2012 R P Herrold
http://www.herrold.com/autobuilder/