A better hotel, collaboration tools, and development tools.
I'm now firmly ensconced in a motel a few blocks further
from the convention center. It costs about the same, but
I'm reveling in the luxurious surroundings and modern
appliances. The furnishings are little space-age--which
means they're designed more for looks than comfort, but
the huge bed, digital TV, and heat lamp in the bathroom
moe than compensate for that, along with all the other
amenities, including a wireless connection that works.
Highlights were a talk on open source development
tools that I'll be summarizing today, and a panel on
JRuby. I'll combine my notes from that with a similar
session tomorrow, and give you an update. There's some
good stuff to tell.
Also, I'll be looking for the Network.com booth in Sun's
section of the show. I've been waiting for quite a while
to blog about that effort--a suite of Ruby-based tools
for distributed project collaboration that includes a Wiki,
bug reporting, source code versioning, and web site management.
I know it as project Kenai ("keen-eye", or "key-nigh").
Here's what the web site has to say about it:
Network.com provides wide range of easy to use Internet
services for developers to create, deploy and manage their
next generation applications. Cloud computing is the next
disruptive force on the horizon and Network.com enables
developers to ride the cloud wave to quickly build and
deploy cloud based applications.
Here's what I know: Its a flexible, well-architechted, and
highly functional, highly usable, and extensible open
source effort that is worth a serious look.
In the meantime, here's a summary of the talk on
open source development tools given by John Smart of
ANT and Maven were mentioned, but not Rake. That put
me off a bit, because I happen to love Rake. This was
a Java talk, but even so, plenty of folks are using
Rake for Java builds.
So Rake is a clear winner for me over Ant and Make.
But I confess that I had no clear idea understanding
of Maven's capabilities prior to this talk.
Maven 2 is a pluggable build framework, with many plugins.
It also lets you do some scripting when scripting, but
your build configuration is mostly declarative. And it
chants the "convention over configuration" mantra that
makes Ruby on Rails powerful without being painful.
Maven 2 also allows for declarative dependency management,
which solves the problem of JAR files that contain
different versions of the classes you need.
Ivy solves that problem for ANT, meanwhile. And there are
Maven tasks that do the same thing--which suggests to me
that running Rake in JRuby makes sense, in order to take
advantage of the Maven tasks, and other tasks built for
Fellow attendee Steve Davidson mentioned that Hibernate
and most of the Apache projects use Maven, and they love
For testing, John mentioned JUnit 4.4 and TestNG, but only
went into detail on JUnit. (Ruby's RSpec wasn't mentioned,
but it was interesting to see Java's unit test harnesses
moving in that direction.)
With JUnit 4.4, any class can contain tests, which makes it
easier to do behavioral testing, because your test classes
no longer have to match up with applciation classes. The
tests can also contain annotations like @before and @after
for setup and teardown code.
JUnit 4.4 also allows for timeouts, tests to make sure the
right exceptions are thrown, and parameterized tests.
One of it's more interesting features is "Hamcrest asserts".
Those asserts read more English, so instead of seeing:
That's all a vast improvment, but it's still nowhere near as
readable as RSpec--a Ruby-based vehicle for unit testing that
was designed from the ground up for behavioral testing, and
which takes advantage of Ruby's language-constructing
capabilities to create tests that are truly readable, but
they're all steps in the right direction.
Another tip from Steve Davidson: For database testing, he
uses HSQLDB--a standards-compliant database with a version
that runs totally in memory, for lightning fast testing.
(To be sure he testing against the latest schema, he runs
the setup scripts the Q/A team is using.)
Finally, for test coverage, developers will want to take
advantage of IDE-level tools to guage the effectiveness of
tests for the code they're writing, and the team as a whole
will want a project-wide coverage tool that provides useful
For IDE tests, there is the tool built into NetBeans, the
EclEmma plugin for Eclipse, and an experimental Crap4j tool.
For project-wide coverage, there is Cobertura.
(On a related front, there are test frameworks like Selenium
and HtmlUnit for Web apps.)
If you don't have automated testing, continuuous integration
doesn't help you much. And if you don't have automated builds,
it's not possible. But if you have both, and you're using any
kind of source control system (cvs, subversion, etc.) then
continuuous integration is the next most important step you
can take to ensure success.
StarTeam was also mentioned for source control. That could
be worth a look.
With continuuous integration, you identify integration issues
sooner, rather than later. Like unit testing, it lets you find
bugs closer to when you created them, which makes them easier
to diagnose. It also means that, two weeks before you're supposed
to ship, you don't suddenly discover significant problems that
require a massive design change.
Continuous integration allows lets you do frequent releases,
which is important for any kind of agile development cycle.
To do it, you need a continuous build tool. Open source systems
include CruiseControl, Hudson, Continuum, and LuntBuild. There
are also commercial systems like TeamCity, Bamboo, and Pulse,
but according to Smart, the open source tools do pretty much
what you need (as of today, anyway).
Automated checking of source codes helps to ensure quality,
but if nothing else it ensures consistency, which improves
maintainability -- and maintenance can be as much of 90% of
the cost of any sustained application effort. (And with
automated checks, developers train themselves!)
You still need to put together high-level architecture docs,
but these tools let you generate details automatically:
JavaDoc (for APis)
UmlGraph (for class hierarchy)
SchemaSpy (for a graphic rendition of the database model)
Missing from the list was object interaction diagrams--A UML
model that tend to vastly more informative than class hierarchy
diagrams for understanding how a system works but which, like
high level architecture docs, need to be created with a selective
focus and high-level understanding.