I’m sure at least a few people have been wondering where we’ve been the last few weeks. We’ve been busy on a number of products, and we released one of them at the end of June. It’s called Clickframes, and it’s a set of frameworks for building usable, reliable, scalable software faster, better and cheaper. The original Clickframes concept was based on three observations:

Good software requirements can be very useful.
Most software requirements aren’t very good.
Even when requirements are well thought out, they’re generally created in a format that limits their usefulness.

At ISG, we develop software using a design methodology that focuses on understanding user needs through interviews, observations and deep research. We learn as much about the problem space up-front, do as much work as possible to validate our designs with real users, and only then proceed with the implementation. This approach works very well for us (and the one time we allowed ourselves to be persuaded to approach a problem differently the results were a lot more typical for the industry), but it requires a lot of agility. Clickframes helps give us that agility by turning static software requirements into a dynamic specification of how the application should work.

Here’s how it works: at some point during the design process we start building an application specification (or “appspec”), which is a description of the web application we want to build. The early iterations can be very schematic – identifying a couple of pages, perhaps a form or two, and a few buttons. As we learn more about the application we can extend the appspec to include additional detail, including specific requirements, security, and flows between different pages in the application.

That’s actually all pretty standard, so here’s where things get a little different. The appspec isn’t a Microsoft Word document, or a stack of index cards, or a drawing on a wall. It’s an XML file, and it’s maintained by the application’s lead designer. By managing requirements in XML, we can generate a whole range of useful artifacts on the fly. The most important is the Clickframes Interactive Preview (click the link for a sample from our Issue Tracker demo), which provides an easy to navigate HTML representation of the application. As requirements change the CLIPs can be easily regenerated. Clickframes also provides generators for conventional requirements documents (the system shall…) and a visualization tool that generates interaction maps of the application. Here’s the Issue Tracker example, generated from the same appspec as the CLIPs linked to above:

Once the design stabilizes, we move on to implementing the software itself. Clickframes helps here too. We’ve built code generators for three different web architectures – PHP, JBoss Seam, and Spring WebFlow (the latter two, for the non-technical reader who has stuck it out this far, are Enterprise Java platforms, and the first is a very common scripting language for web applications). This is an area where conventional prototyping tools break down – they don’t provide a bridge to development. With Clickframes, the plugins give us a skeleton of the application immediately, and our developers and designers can go in and immediately start creating content and the final look and feel, rather than worrying about details like implementing edit checks on form fields. If you want to see the Clickframes Issue Tracker demo, just click on the link (to log in, enter anything for the username and password). This isn’t a complete application, by the way – it’s just the generated code, before being customized by a programmer.

We’ve spent a lot of time on the Clickframes code generators and on the architecture of the underlying applications. We’ve implemented a range of features we call “CodeSync” that allow us to regenerate applications even after the development team has started to customize them. This is critically important, because it keeps the requirements from becoming out of date. If a business user, or a a designer, wants a change made, they can have the appspec updated and the programmer can re-run the code generator. It creates a feedback loop that’s often missing.

The final step in the Clickframes project lifecyle is testing. Since we have a version of the software requirements that a computer can understand, we can use it to generate a suite of automated tests, as well as templates for test strategies and manual test scripts. It’s not magic – the quality assurance team still has to do some work, and we can’t automatically generate every single test, but we can save a tremendous amount of up-front work. And developers can have access to automated tests of the final application almost from the first day of development. It saves a tremendous amount of time.

Clickframes is software to streamline development of enterprise applications. So how much would you pay? Don’t answer, because it’s free – we’re releasing Clickframes as Open Source Software under the LGPL. You can download Preview Release 1, sign up for the mailing lists, and see some demo screencasts at www.clickframes.org, and you can find a lot of documentation on The Clickframes Wiki, including instructions on how to get started without downloading anything. The Preview Release is out there to gather feedback – we’ll be releasing new versions at a pretty rapid clip over the next two months, with a goal of 1.0 by the end of the summer. We’re also rolling out some new web site features in July that will make it easier to explore the Clickframes model.

This has been a long road for all of us – we started working on Clickframes back in May of 2008, so it’s been over a year to get to this point. So give it a try and let us know what you think!

(And if you like it, or like what we build, give us a call – we’re always looking for interesting new projects).

The Old Days

If you’ve ever developed a web application in Java, you’ve spent a considerable amount of time configuring your container and your IDE. For some applications, this is a small and reasonable sacrifice: “the cost of doing business.” For more complex applications, it’s a brutal time-sink that requires having every engineer that builds your application go through a training session just to get the application started.

With every project I’ve been assigned to, I’ve often had to spend the first day just configuring my environment so it will function exactly like everyone else’s. Typically the procedure has been:

Download and install essential prerequisites : Java, a version control program (SVN, CVS, P4, etc), ANT, and an IDE.
Download source code
Download tomcat (often a very specific version which is no longer the latest version)
Install tomcat
Configure the server.xml and tomcat-users.xml
Configure some local build properties for someone’s ANT script.
Build the application
Deploy

Isn’t this a huge waste? In my experience, this is a full day for most developers when put on a project for the first time. Some of the really productive ones can do all these steps in a half day.

The New Procedure with Maven

What if you could eliminate most of this? Maven offers the promise to do so. Here’s the procedure actual we use here at ISG:

Download and install essential prerequisites : Java, a version control program, Maven, and an IDE.
Download source code
Run mvn compile tomcat:run (for JEE5 projects it’s glassfish:run)

Now you can log into the application. Maven downloads all of the dependencies, builds the application, downloads a container, configures it based on our pom.xml and and deploys it to an embedded container.

To configure your application to use the embedded container, simply edit your Maven pom.xml and add the plugins below to your build section.

<build>
   <plugins>
      <!-- Embedded Glassfish v3 prelude (glassfish:run) -->
      <plugin>
         <groupId>org.glassfish</groupId>
         <artifactId>maven-glassfish-plugin</artifactId>
         <version>1.0-alpha-4</version>
         <configuration>
            <!-- technically optional, but helpful to declare explicitly. -->
            <!-- I personally put all 3 containers on different ports. -->
            <!-- This allows me to test them simultaneously. -->
            <httpPort>8070</httpPort>   
         </configuration>
      </plugin>
      <!-- Jetty Launcher Plug-in -->
      <plugin>
         <groupId>org.mortbay.jetty</groupId>
         <artifactId>maven-jetty-plugin</artifactId>
         <configuration>
            <contextPath>${project.artifactId}</contextPath>
            <!-- This parameter will auto-deploy modified classes -->
            <scanIntervalSeconds>3</scanIntervalSeconds>
            <connectors>
               <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
                  <port>8090</port>
                  <maxIdleTime>60000</maxIdleTime>
               </connector>
            </connectors>
         </configuration>
      </plugin>
      <!-- embedded tomcat (tomcat:run) -->
      <plugin>
         <groupId>org.codehaus.mojo</groupId>
         <artifactId>tomcat-maven-plugin</artifactId>
      </plugin>
   </plugins>
</build>

Now your application can run in Tomcat, Jetty, or Glassfish without any configuration on the user’s part.

Try it yourself:

I recently had to learn how to use Spring WebFlow. Fortunately, their booking sample application (SVN URL) has been configured to build with Maven. I added the snippet above to their POM and was running and modifying their application less than 15 minutes after downloading their sample. All I had to do was paste in the lines of code above and execute one command via command-line (mvn compile jetty:run).

Real-time Editing of Static Resources

Not only can your users launch the application without installing a container, but they can edit most of the application and view the results in real-time. All three containers will automatically publish static resources, such as JSP, CSS, or HTML files to the running application so that the files are instantly viewable. For example, a graphic designer could edit a CSS file, using Dreamweaver, Notepad, or the tool of their choice, and see the results in real-time, in your dynamic JEE application.

Real-time Publishing of Java Code

Jetty supports publishing of Java code automatically. Now you can see your Java code automatically redeployed to the container, on edit. This eliminates the need for contributors to configure an IDE to publish changes to the underlying Java code and view them in the container. While Glassfish doesn’t have auto-publishing support like Jetty, it will do a full redeploy if the user hits enter in the terminal window, which is almost as convenient. Glassfish is also incredibly speedy.

Development Server Atrophy

In the old days, every team had a development server they’d use to deploy their application to after making edits on their machine. Often the developer would code on a local server install and deploy the to the development server when demoing their work-in-progress or collaborating with another contributor.

As soon as we discovered these plugins, we started using our development server less and less. Eventually the company repurposed our development server. When I want another person to view an application’s progress before it hits our staging server, I can have him or her simply type “mvn jetty:run” and start using the application locally.

Conclusion

Maven is not only a powerful tool for building an application and handling its dependencies, but it can even run the application for you. This greatly lowers the barrier to contribution on a Java project as it allows people who aren’t as familiar with IDE’s like, graphic designers, business analysts, and programmers who don’t usually work in Java, to modify files on their local machines and see the results, in real-time, in a dynamic web application. It’s also very handy for demo-ing applications as the app can be setup on new machines very quickly.

info.rmatics

Business, Healthcare, Informatics, Software – in the real world.

Tag Archives: J2EE

Introducing Clickframes!

Increasing your productivity by using an embedded container in Maven