Revision as of 17:30, 30 July 2007

"Harnessing the power of magic..."

Facilitated by Josh Price and Tom Adams

Build Tools

Performance is not always optimal.

programming in xml doesn't make sense
big ball of ant problem
- the 9000 line "untouchable" collection of build script
few conventions
- lots of rope to hang yourself
hard to refactor
ill-conceived
- even JDD has disowned it

good conventions but hard to diverge from the norm
- simple things are simple
- moderate things are really hard (write a plugin)
- hard things are virtually impossible
too much voodoo
not enough docs
- hard to find where/how to configure things
kind of buggy
- (I think this was attributed to plugins)
declarative model is too strict
- flexibility is needed here
appeals to the less experienced
- can get yourself in trouble if you assume it all just works

testing your build?
- once it gets really big you need to be able to reason about your build.
- tests could allow you to refactor/optimise/etc without breaking anything
- testing is much simpler with a real language
  - if you're stuck with ant you could use antunit (http://ant.apache.org/antlibs/antunit/)
we really need a first class language for flexibility
- programming in xml doesn't make sense
- pure declarative model solves some problems but reduces flexibility
auto include of rake files allows easy factoring
possible to separate the definition of dependencies - who depends on me?
builtin namespaces (ie db:*, test:*)
plugins in ruby are really simple
- monkey patching
file dependency checking is built in
- what changed? do it anyway not optimal speed
auto checking of timestamps

posix only (no windows yet)
- installing cygwin is a solution
- write adapters for the commands used (ssh, ftp, etc)
version 2.0 just released
peepcode demo (http://topfunky.com/clients/peepcode/free-episodes/peepcode-free-deprec.mov)
- building ubuntu box remotely via ssh
- using the deprec gem (http://www.deprec.org/)
convincing management that using a Ruby tool on a Java project is a good thing
- it's often easier to just do it and show the benefits
- ask for forgiveness rather than permission

@@ Line 40: / Line 40: @@
 ** once it gets really big you need to be able to reason about your build.
 ** tests could allow you to refactor/optimise/etc without breaking anything
+** testing is much simpler with a real language
+*** if you're stuck with ant you could use antunit (http://ant.apache.org/antlibs/antunit/)
 * we really need a first class language for flexibility
 ** programming in xml doesn't make sense