WSAD and Maven - playing together

Ok, from what I could determine the latest (and now no longer supported IBM's WSAD) is akin to a 2.1.3 Eclipse build (just for those people still tied to this IDE). To integrate Maven with WSAD, follow these steps:

WSAD (requires a project to have a Maven project file, ie. project.xml)

• Select Window / Preferences

• Select Java -> Classpath Variables

• Select 'New'; type MAVEN_REPO for name; and location of the Maven repository for path (specific to the view of each developer)

• Go to the project's location; checkout the .classpath and .project files type maven eclipse (this will generate the accurate classpaths according to the Maven project.xml descriptor).

• 'Refresh' your project space; you will notice that under Properties -> Java Build Path that all libraries have been updated with the Maven repository (and not hardcoded)

No more hardcoded libraries and one can check in the .classpath, and .project files for a seamless, defined, development environment.

Writing tests in development

I recall on a number of previous projects that there was always some confusion around the type of tests that were written in development; that is, unit tests, integration tests, component tests, system tests, etc.. Of interest, then, I recently read this article from IBM developer works (a truly interesting RSS feed for those in Java software engineering).

Basically, it states that tests need to be categorised into:

1. unit tests: single-class driven tests; isolating a piece of functionality (hopefully only one public interface per class!)
2. component tests: multiple-class driven tests; often including core pieces of logic and functionality
   
3. system tests: end-to-end testing; high-level, arbitrary logic executed; does the application work?

Importantly, it defines that the time taken for each category will increase significantly and therefore there should be multiple build / test loops with their own individual reports. So the unit testing which is used everyday is not corrupted by the component testing (e.g. driven by test defects) or system testing (e.g. driven by releases).

3 mantras of modern day software development

Ok, I have been an avid reader of 43 folders for a while now. This week, however, they published a 3-part article on 'getting things done - software development' - and I thought that I would reiterate these mantras, how to apply with modern-day tools and discuss what happens if they are not applied.

So what are the 3 mantras: test, refactor, document! Ok, a caveat to these mantras, this should only be followed if you want to maintain (and improve) an application for more than a year, but if you don't want to do this, what sort of business case do you have?!

1. TEST: despite overwhelming industry material over the last few years about the advantages of unit testing, there still seem to be a significant number of projects that do not enforce unit testing. The advantages are clear, unit testing enhances design (e.g. that there should be only one public API per class), enhances quality (e.g. combined with a coverage tool, all branches of logic are run, and verified in terms of expected behaviour), and most importantly this provides a baseline for the application's operation and maintenance. So, with a complete set of unit tests (i.e. coverage greater than 90%), any change to the underlying code base can be made by anyone because if the existing functionality is compromised a unit test will break. Therefore, immediately new developers are able to confidently make changes to the application, regardless of the size or complexity. In Java, one needs to look no further than JUnit, TestNG, etc..
   
2. REFACTOR: refactoring is the ability for developers to change, rework, and enhance any exisiting code from an application that is required. Why? well this enables applications to be modernised and for existing, or more importantly future flaws to be corrected and countered. Not every line of code is written at the same quality as every other line of code (due to poor requirements, inexperience, poor implementation, etc.), with refactoring (as long as it is controlled) then the application's code base is continually being refined and in conjunction with unit tests, provides a robust, modifiable approach to maintaining application longetivity. A prerequisite for refactoring a featured IDE - and IntelliJ 6.0 cannot be beaten in this regard.
   
3. DOCUMENTATION: probaly the most controversial; I used to think that unit tests alone could document an application, but in order to capture the brainstorming, design sessions, implementation decisions made in developing an application than some form of documentation is needed. I am a firm believer that all documentation related to an application: namely arhcitecture, requirements, design sessions, implementation, and maintenance should be held in a wiki with the condition that it has Google-like search features. To this end, Confluence must be the only option, and I see it as almost standard to any software development.

Without these approaches, I would foresee significant difficulty in maintaining any application.

Design and development

Just recently read an article in Wired as to how the iPod was developed; one byline in particular caught my attention:

"Apple's designers spend 10 percent of their time doing traditional industrial design: coming up with ideas, drawing, making models, brainstorming, and they spend 90 percent of their time working with manufacturing, figuring out how to implement their ideas."

No argument could have been described more aptly as to relationship between solution architecture and development. That is, design is important, it is critical that it is conducted at the beginning, but in the end, it is in the implementation that real issues arise. It is the 'figuring' out how to deal with these issues and implement the design where the focus of architects and team leads should be.

Software development is easy

Ok, I have decided to create a presentation (and indeed a white paper, if I truly become inspired) describing why enterprise software development is easy, and what companies should be expecting from software vendors in terms of quality. Expect draft - beta soon!

Crucible - code reviewing tool

I was recently reading an excellent article on the development of a 'coding factory'; in this article it referenced Crucible as a code review tool. I registered for EAP and downloaded version 0.7.

I was very impressed with this tool (despite its inability to support IBM Clearcase as a SCM). Crucible is a code-reviewing servelt / web tool which hooks into the project's SCM. Once hooked in, all code can be reviewed and comments inlined. The main advantage of this is that it allows code reviews to be done continuously. Much like pairing and the obvious advantages in quality with which this provides, Crucible allows for other developer's to touch and review the code leave comments that relate to particular lines / patterns. A workflow is automatically generated allowing the comments on the code to be looked at, and if necessary refactored into the code. I can see that the main advantage of this would be onshore / offshore development as it would allow online review and feedback loops to be aligned to the project / iteration lifecycle. Secondary to this, it is a great way for more senior developers to break new starters / graduates out of poor coding styles , or even as a means to stage gate code going to test / production.

Now if only I could work on a project that used subversion or cvs to test this out!

IntelliJ 6.0 released and a tip!

Yes, having used IntelliJ for the past 5 years now, I was pleased to see IntelliJ 6.0 released, although since I am not on Java 5 project - I can't test many of its juicier features. Nonetheless, it appears the best version ever.

And if you are getting some performance issues for IntelliJ on Windows when into IntelliJ:

1. go to Settings -> General -> toggle Synchronize files on frame activation;
2. set JDK (for running IntelliJ) to version 6 Mustang; by setting IDEA_HOME and overriding 'idea.no.jdk.check=true' in the idea.properties file
   

RAD - 'the evil WSAD legacy' strikes back

Ok, interestingly I read that IBM will not support WSAD from September 30th, 2006; so inevitably that means the big corporates will migrate to RAD (IBM's Rational Application Developer) over the next year.

The experience I have had with RAD is minimal. Of interest, I did, however, try and import a legacy J2EE project which was being developed and maintained with WSAD. RAD was unable to do this.

Let me clarify this - RAD was able to import all the source, ejb folders and the J2EE project was able to compile. The RMIC deployment however was significantly flawed. The only theories I have at the moment are:

(1) WSAD embeds IBM-centric descriptors in the configuration of EJBs (in particular entity beans) that are not fully supported in RAD
(2) the RMIC deployment tool between WSAD and RAD is not the same (requires some feature to deply RMIC code like WSAD)
(3) more stringent validation occurs in the RMIC deployment of RAD over WSAD
(4) updates to libraries (e.g. database drivers) causes errors in the OR mappings

Unfortunately, for the J2EE legacy project I am working on, this means that WSAD is no longer supported and RAD cannot support it! And indeed the error messages that RAD has produced have been highly ineffectual.

So IntelliJ? well that would be a great! but like any high-quality IDE it does not allow cyclic dependencies. So what now?

IntelliJ live templates

I know, I know a lot of other people have done this; but I am continually working in IntelliJ and keep losing the live templates I write, so whenever, I need one, I will just update this post.

JUnit test

public void test$METHOD_TO_TEST$() throws Exception {
    $END$
}

JUnit test (fail condition)

public void test$METHOD_TO_TEST$() throws Exception {
    try {
        $FAIL_CONDITION$
        fail();
    }
    catch ($EXCEPTION$ $EXCEPTION_ABBREVIATION$)
    { }
}

J2EE development and the 'evil WSAD legacy'

Around 2 years ago, I read a blog from a prominent software engineer in Melbourne (Jon Eaves) who posted about the 'evils' of Websphere Application Developer - having never used it, I read with curiosity and this reaffirmed my own development management of the team I was running at the time, in using: IntelliJ for an IDE, Maven for an independent test/build/development management system, and predefined, one-per-developer based IBM Webpshere Application Server (to which developers deployed to).

2 years forward (and as mentioned before, working on a legacy J2EE project) - I am using IBM's Eclipse2.0-based WSAD and a 1 hour + ANT development management system. After using it for a week, there are several key characteristics of WSAD which seem to engender poor code and development practises:

• In-built pseudo 'test' Websphere Application Server; what is the rationale in deploying to a IDE-based server? if everything deploys what has this actually proven? it has not been deployed on a Websphere Application Server and does not mitigate any of the risk associated with this. If anything, it promotes point-and0click testing and runtime debugging to be used as a substitute for unit testing. A better idea would be to have WSAD / RAD, etc. to have an extensible / callable EJB container that could be invoked off a unit testing framework such as JUnit, TestNG such that unit tests of legacy EJB2.0 code actually be tested. Assumptions regarding the full application deployment could then be verified on developer instances of WAS (and with integration tests).
• Non-standards based directory structure; if WSAD / RAD is going to provide Wizards to set up a new project - then conform to the industry standards in terms of directory structure, or at least allow any directory structure to be used. Currently, WSAD imposes a directory structure.
• Non-standards based artifact generation. Upon seeing the monolithic ANT development management process, I thought, I would be easy able to refactor the constituent jars, wars, and ejbs of the project. Unfortunately, this is not possible because IBM introduces its own bindings in the ejb-jar.xml such that it does not even conform to the schema - nonetheless it is able to be deployed on WSAD, WAS. Now only through WSAD (or by calling WAS libraries) is a deployment possible - complete vendor lock-in!
• Loose intra / inter project error checking - WSAD allows projects to have cyclic dependencies - when is this ever a maintainable approach? Error checking within a project is also poor (somewhat an artifact of Eclipse2.0).
  
• Extremely poor IDE responsiveness / performance on projects with multiple modules.
  

The 'evil WSAD legacy' results :- J2EE projects that are WSAD-bound (i.e. not able to develop / develop in any other IDE), poorly defined, poorly error-checked, and poorly tested. Of course, this is somewhat dependent on the developers that worked on the project in the first place - but with WSAD's loose industry compliance - it is difficult to see how any significant J2EE project will be maintainable in the long run if it has been developed, and continues to be devloped on WSAD.

So what do all the projects that have been run on WSAD do in the next 2-3 years when dealing with this legacy unmaintanenable code ...