Sponsored Link •
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 Wakaleo Consulting:
To do things right, you'll want tools for:
- Automated builds
- Automated testing
- Source code management
- Continuous integration
- Automated Code Checking
- Automated Documentation
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 ANT.
Note: Fellow attendee Steve Davidson mentioned that Hibernate and most of the Apache projects use Maven, and they love it.
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:
assertThat(color, is("blue"); assertThat(color, Not(isIn(colors))));
You also get more readable error messages:
"Expected "blue", got "red"
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.
Note: 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 reports.
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.
Note: 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!)
Tools for automated code checks include:
- Checkstyle (for naming conventions, formatting)
- PMD (helps to ensure best practices)
- findBugs (identifies potential bugs, e.g null ptr exceptions)
- crap4j (an experimental tool that finds overly complex and untested classes, when it is used for unit-testing)
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.
Have an opinion? Be the first to post a comment about this weblog entry.
|Eric Armstrong has been programming and writing professionally since before there were personal computers. His production experience includes artificial intelligence (AI) programs, system libraries, real-time programs, and business applications in a variety of languages. He works as a writer and software consultant in the San Francisco Bay Area. He wrote The JBuilder2 Bible and authored the Java/XML programming tutorial available at http://java.sun.com. Eric is also involved in efforts to design knowledge-based collaboration systems.