Spring Roo (wasting time tonight)

Okay so I sat down tonight to work on my Roo commands. I checked the version numbers to make sure I have the latest version. Of course I was one version behind so I decided to download the latest version of the software, extract it and point my ROO_HOME to the new location. Now I pop open a shell and type "roo" to fire up the Roo shell. The previous version of Roo comes up. I checked and re-checked my .bash_profile to make sure the ROO_HOME was configured correctly.

What is the point of this blog? I forgot to create the symbolic link for the roo.sh file. I had created the symbolic link earlier and forgot about it. I had to unlink the roo.sh file and create a new link before things got back to normal.

sudo ln -s path/to/spring/roo.sh /usr/bin/roo

Life is good now after loosing about an hour of time goofying with this.

Modeling External Integration Points

Developing an application that is new and has it's own database can be pretty easily done offline. By offline I mean disconnected from the client's networks and systems. Since the application is new and the database is new the developers are generally free to develop within corporate standards. It is very easy for a developer to disconnect from the corporate network and take their work somewhere else to work more productively. They are free to use tools that they have used for years and even new tools that they have found useful. What does all of this have to do with modeling integration points?

Well if you have to integrate with existing systems or third party systems then it isn't possible to disconnect from client network. It is often necessary to use a client machine to develop the code since these machines submit to heavy scrutiny and corporate security policies. License violations are also of concerns to organizations that have hundreds of thousands of dollars at stake. This can lead to a less productive developer since the tools and techniques they have developed may not be applicable on a machine absent of the technologies and tooling required. The client processes for obtaining software usually amounts to weeks of back and forth emailing and in the end usually denial of the tool or technology requested.

The other issue that comes about with external integration is the black box effect. It is complicated to describe exactly how the two systems will interact at a protocol level. There for when writing the requirement the writer simply places a black box around the integration point by saying "system A will integrate with system B and do thus and such". Wow! In those few words there is a ton of complexity that gets glossed over.

So why am I blogging about this? I have wondered for several years now if this is not just an engineering problem that needs to be solved. How many devices do we have that communicate through the USB interface. Do you have any devices that use serial, parallel, firewire, etc...? Why not treat these third party integration points as if we are designing a new device that communicates over USB? I am getting a little over my head talking about hardware but I want to give visual that everyone can understand. What makes USB work is the ability to standardize the interaction between the computer and the device.


I believe that with some thought a simple process can be put in place to model these integration points. Once the model has been created and verified, say by a unit test suite, then the developer is free to move to a more productive mode of operation. Disconnecting from heavily regulated client networks and moving into a productive development environment focused on developing high quality code in a rapid and reliable manner. I have a simple form that I am developing that will document the desired interactions between systems and hopefully will turn the black box into a transparent box that can then be estimated easily and validated for accuracy.

This will also help focus the implementation effort on implementing the new system instead of the quirks of the external system. While this should eliminate the black box nature of the specification process it will not remove the need for integration testing. It will still be necessary for the system to be integration tested once dropped in place but the system can be developed off the client network. Happy developers and hopefully more cost competitive fixed bid projects. A topic for another time.

Level 1 Discussion Form

CSS Design in Dayton

Back in May I was working at Starbucks in Oakwood and found myself talking with a designer from Forge. I started our conversation because I noticed the high definition site he was working on behind his text editor. He explained that he was a big proponent of web standards. I mentioned that I had started trying to learn CSS and good design and that I had recently purchased a book, "Mastering CSS". He quickly told me that I had made the right purchase. I enjoyed our meeting and have bumped into him and his company several times now. The latest is in this presentation from prezi below. Prezi is great and is for another post sometime. Enjoy!!

CSS In The Real World on Prezi

Chromed Bird

Just a quick mention of the Chrome Extension "Chromed Bird". It is a great little client for the browser that allows me to keep up with my twitter friends without being obtrusive to my work day. Check it out if you haven't. It has already helped me discover a half-a-dozen cool things that have been noted for later. Until recent I had pretty much tuned out of twitter just because there wasn't a good way for me to keep up with it. Now I have a little bird icon in my browser that has an unread count. I quickly view the unread and back to work I go. If I am busy I never see the little the unread notices.

This is working great for me.

What happen to the "copy to clipboard" button

Okay I was posting to my blog today when I ran across for the second time what seemed to be an updated version of the Syntax Highlighter library I am using for highlighting code. The nice little flash buttons that use to appear in the upper right hand corner are now gone. Hmm.... I don't like this. So I went to the site to find out where and why the little buttons have disappeared.

Copy To Clipboard

Since the first version back in 2004, SyntaxHighlighter has always used Flash to provide copy to clipboard functionality. At first it was Flash 8, then it was Flash 9 and now 10. It's never been a crowd pleaser and a lot of requests over the years demanded Flash to be removed.

Well, it's finally happening -- no more Flash. I think I've came up with user interface to copy code to clipboard which is a lot more intuitive and almost too easy.

If you double click anywhere on the code, the entire code view is replaces with a pre-selected view from which users can copy with a simple Ctrl/Cmd-C. Clicking anywhere else returns the view to the original state.

Grab Groovy in a Shell

I saw a tweat today about Groovy Grab and using it in a shell script. It reminded me how cool Grapes and Grab are for pulling dependencies into a Groovy file.

Here is a little script that will execute an HTTP call using Apache HttpClient and the script is executable like any other shell script on your machine ./go.sh.

1. Create a file named go.sh


2. copy the code below into the file


3. from shell type "chmod +x go.sh" without parentheses

#!/usr/bin/env groovy
@Grab(group='commons-httpclient',module='commons-httpclient',version='3.1')
import org.apache.commons.httpclient.HttpClient
import org.apache.commons.httpclient.methods.GetMethod

HttpClient client = new HttpClient();
GetMethod get = new GetMethod("http://www.apache.org/");
client.executeMethod( get)
println get.responseBodyAsString

Note: The @Grab is actually annotating the first import statement.

AppEngine and Gradle

I have a project that was initiallly created using Eclipse and the Google Eclipse plugin. This creates a project structure where the web resources go in /war and the java resources go in /src. What I would like to be a be able to do is execute gradle build or gradle jettyRun and execute the web app from the command line. Here are the modifications that I had to make to get this to work.

apply plugin:'war'
apply plugin:'jetty'

sourceSets {
    main {
        java {
            srcDir 'src'
        }
    }
}

war {
    from 'war'
}

jettyRun{
 webAppSourceDirectory = new File('war')
}

Google Sitebricks

I just need to take a few minutes to talk about this. I have really started to love Google Guice the lightweight dependency injection framework. The next question was how to use Guice and some web technologies to build the simplest website with some basic capabilities.

Enter Google sitebricks. I selected sitebricks the other day while working on a report problem in another application. Today I selected it again and included it in the maven pom.xml for a project. After grabbing the dependencies I was a little turned off by how much was brought down. After all I like to think of myself as a minimalist. So off I went to find something even smaller and simpler. I even went back to using plain old JSPs, which would be a good option but I am too lazy to find the TLD's hidden amongst the piles of JSP garbage on the Internet. During this process I even revisited an old friend Wicket. I almost through the switch on using Wicket when I saw how much configuration went into the web.xml to use Guice. Forget that. Something didn't feel right.

So I went back to my last project where I used sitebricks and started looking for what was really required. The first thing was to toss maven out and use Gradle. I set the new project up with the same build.gradle used in my last project with a few less configurations and I was ready to see how small I could make things.

The good news is that I didn't need all those jars brought down initially by Maven.

Summary

google-sitebricks 200kb

google-guice2 650kb

google-guice-servlet 28kb

mvel 680kb

For around 1.5MB (Floppy size) I can start developing and can't wait to show how simple it really is to develop a Java backed page.

To see now go to sitebricks.

Roo Investigations (Part 1)

This is the first post on a series of post that I plan on making. Roo is a new productivity product from SpringSource. Why do they need another rapid application development tool? I am not totally sure but that is one of the reason's I have started looking into it. One thing I have learned over the past few years is that the folks at SpringSource know what they are doing. When the rest of the industry was going nuts over J2EE Rod Johnson was making stuff work.

What initially brought me back to look at Roo again is the fact that Bruce Johnson the lead developer for GWT (Google Web Toolkit) and Ben Alex the creator of Roo was on stage at the Google IO keynote this year and announced a partnership between the two teams. Well I am already sold on GWT for building RIA style applications and this meant I needed to pull up the Roo home page and give it a second look.

The point that I want to make today is that the whole download of Roo is around 5MB. That is impressive. I checked the Grails download and it sits around 41MB. For someone that likes to keep there code lean and mean as possible this is very cool!

A little closer look at the spring-roo distribution reveals that they are using Apache Felix for their platform. From my 10 seconds of research on Felix it looks like an OSGi container.

The last thing of note for me about Roo is the fact that the samples come as scripts that get executed in the shell. The shell actually generates the applications on the fly. I like the fact that you can potentially write a script that will generate scaffolding for the application and the application itself. I know, I know grails create-app... but that only creates a default application and then you need to run additional commands to create domains, controllers, views, etc... granted that can all be in a single .bat or .sh but that is not the standard procedure for Grails. Roo is designed to handle this kind of generation and provides commands for creating the fields and restraints.

Loving the tab completion too!

Chrome features

Google's new browser Chrome, or not so new now, has some great features that I have just started to explore. Pinning tabs. While I had seen folks do this I had never really thought much about it. Well today there are several windows that I keep open all the time. Gmail happens to be one of them. Why take up the full amount of tab room for something that is always there and I don't need to think about it. So if you right click on the tab and select Pin it will shrink the tab down and stack it nicely off to one side. Very cool.

Then for the next level of coolness is the Gmail extension for Chrome that allows you to turn on Desktop notification. That is one feature of Outlook that I tend to like because it helps me respond promptly to important messages. Now my Gmail can have those features too.

Chrome is a crazy fast, extremely cool browser. Thanks Google!

Creating Unix scripts with Groovy

I ran across a need to write some scripts that could run on my Mac or any Linux box. I don't regularly keep up with Groovy changes but last night I ran across this article and thought it was very cool. I know very little about writing Unix shell scripts but I have been playing in Groovy and Java for a long time. So the fact that I can create a Unix like script but in Groovy makes me very happy.

#!/usr/bin/env groovy
println("Hello world")
for (a in this.args) {
  println("Argument: " + a)
}

Name your file something like "project" and execute a chmod +x project. You are now good to go and can execute the Groovy code by typing ./project. Any parameters that are passed to this file will be passed to the Groovy script using the implicit args parameter.