Kev Jackson wrote:
Hi all,
I'm preparing a talk for the developers here in Vietnam about how to use
Ant to build software (mainly Java, but you know there's the .net tasks
too). I have the main body of the presentation completed, but I wanted
to include some of the more esoteric things you can do with Ant (not the
videogame!). I noticed on the Manning web-site that Steve mentioned
that he has slides available showing imports, macrodefs etc, these would
be incerdibly hadny if he still has them (nudge, nudge, wink, wink).
Those are the apachecon europe 2005 slides, and they are In the post.I
will put them up online once I have PDF creation and layout right; the
visio image is causing problems with some PDF viewers.
Take the presetdef/scriptdef/macrodef/import slides at the very least,
esp. the one that shows import inheritance. Assume an ASF or creative
commons license.
Actually, maybe we should put together some official ant team
presentations, for use in in-house or external talks, something like the
following set. This could be something to get the user community
involved in too...
-intro to ant
-why testing matters more than you think
-whats new in ant1.7 (the apachecon slides are this)
-.net with ant
-C++ with ant
-Ant XML processing
-script in ant
-continuous integration
I cover:
- Ant versus Make
- Ant instead of IDE compilation
- Continuous Integration (CruiseControl)
- Common tasks (clean, compile, jar etc)
- Server-side stuff (ftp, deploy etc)
Anything else I should include for first-timers? My aim is to help the
developers realise that although it is possible to work as a team with
each person compiling in their own ide, that Ant simplifies things and
allows them to re-use the build script on other projects etc. I've got
another talk on unit testing coming up (I've been here nearly 10 months
and I've only seen 1 unit test and there was nothing tested in it).
uh-oh.
Getting people to embrace unit testing is hard, very hard, unless
management come down and say write unit tests. the reason being is that
the benefits dont show up immediately -at first it is extra effort and
delays above coding, tests are somehow viewed as less worthy than real
code, etc, etc.
Needless to say, the working practices are similar to what I'd expect in
the 80's (SourceSafe as version control, everyone locks files, Waterfall
as the process, massive investment in design up front, testing is done
by teams of bored people etc etc).
upfront design is always useful :) I dont consider VSS to be an SCM
tool, more a pretend SCM tool. which is worse, because you think you
have your source safe, and then suddenly you find out you dont...
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
