When do we change from a website to a webapp?

For context: I'm currently looking at moving my long awaited site www.playmyvenue.com from Struts2 to GWT, primarily due to the fact that I'm wanting to deploy to Google App Engine and I've hit all sorts of issues with the Struts2/GAE combo which I'm not in the mood to solve today.

Without doubt GWT is a very cool piece of kit, allowing me to create screens easily without having to switch to framework specific jsps or embed hardcoded html in servlets, but whilst viewing my amazing automagically created AJAX pages I felt somewhat uneasy; you guessed it, “am I using a website or a webapp?” Looking at my site it actually felt a little, dare I say it, amateurish having all these page updates and data forms flying around the screen, almost unnerving quickly, and I wondered if it was because I was missing the one thing that, perhaps, separates the website user experience from the webapp; page refreshes.

Take a look at “sites” like Twitter or eBay compared to your online banking or Email accounts. You feel like you’re moving AROUND the site, it’s a place with various areas of interest you peruse and occasionally interact with. Your online banking, email account, office suite, etc all demand constant interaction from you. It’s a subtle distinction but non the less profound. The mechanism for interaction is the same but the user experience and expectations are totally different. When using a traditional desktop app you expect desktop performance and as such web based alternatives must strive to provide the same levels of experience. Websites however have always behaved in this manner and we’re familiar with it. Sure connections are now faster and browsers more powerful but the underlying HCI experience hasn’t changed much, which I believe is the reason I’m not comfortable using a website written in GWT.

Unlike most blogs I read I don’t believe I have the answer the question I’m posing and I’d love to hear other peoples views on this subject.

Not blogged for a while

As the title says I've not been blogging for a while, mainly because I've nothing new to add that hasn't already been thrust into the blogosphere. A few posts will be on the way soon as I've been up to my knees in new projects and technologies, including Google App Engine, Guice and Protobuf (notice the google theme). There will also be a venture into IPhone world too in the not too distant future.

Hudson for Java and Windows builds

Sometimes you might have both .Net and Java projects in your organization. When this happens you'll probably want to have a unified build server to display the outcome of all CI builds. Hudson has wonderful support for all aspects of Java building and also has some great integration for NAnt/NUnit/MSBuild/MSTest and even NCover for your .Net code coverage needs. This is great when you're building all your apps on the same OS but what happens when you want to build your Java apps on linux? Well Hudson has a solution for this too, Distributed Builds. This allows you to run a single master Hudson node with any number of slave nodes, which can all be different OS, Java/.Net versions, any configuration you want really.

Setting this arrangement up is very simple.

(This example describes setting up a Java master on linux and a .Net slave on Windows)

(On the master)

• Install and start Hudson on the master box ( http://wiki.hudson-ci.org/display/HUDSON/Installation+and+Execution )
• Create a node (Manage Hudson -> Manage Nodes -> New Node), the node name needs to be the ip or dns of the slave box and lauch should be via jnlp. Make sure usage is set to "Leave this machine for tied jobs only" or Hudson might start trying to run Java jobs on your windows box.
  

(On the slave)

• Open a browser and go to the following url http://<ip>/computer/<node>/ (e.g. http://infrastructure.mycompany.com/hudson/computer/10.0.0.56/)
• Click the big orange launch button
• (One extra step if you want is to install the slave as a windows service. There is a menu option to do this on the slave agent window that opens on the slave box.)
  

And thats it, create your .Net jobs just like Java ones but make sure you check the "Tie this project to a node" option and select your .Net slave node.

NAnt, NUnit, MSBuild, MSTest and NCover support is available from the plugins menu.

Now at this point I should tell you about the gotcha. NAnt support doesn't seem to work when you run Windows as a slave service as the options for specifying tool locations (NAnt etc) only stretches to Java tools. If someone has managed to make it work please let me know. The workaround is to not use the NAnt support and use Windows batch commands, just enter the command you would do at a terminal window to run the build and Hudson will do it for you, simple :-)

Feedback is king

Have you seen these symptoms:

• @ignore
  
• maven.test.skip=true
  
• Tests commented out
  

If so then you've probably been working on a project thats suffering from a lack of feedback.

Since the early 00's we've had the term "Continuous Integration", the essence of which being integrate often so you don't get a nasty surprise at the end. The problem here is that feedback is essentially a synchronous process, i.e. you have to be there to receive that information. Lets assume we've gotten into the healthy habit of atomic commits, say approx every 30 mins, how long are you prepared to wait to see if you've broken anything, 2 mins? 5 mins? What if your build process takes 60 mins? Would you wait? Probably not. In this situation one of two things tend to occur.

1.) Checkins continue at the same rate, which means that two subsequent checkins occur before checkin 1 has been tested. This usually means lots of wasted time reverting changes when bugs have been introduced.

2.) Checkin numbers are reduced to keep up to date with the build cycle, this causes more integration issues as the codebase across the team is out of sync for longer.

Eventually people stop relying on the build as an indication of stability and this is when you start seeing the aforementioned symptoms.

This almost certainly leads to brittle code, a decrease in velocity, an increase in bugs and a heavy reliance on manual testing.

So remember that builds need love and care to make sure they're as efficient as possible. Spend time making sure that heavy weight acceptance tests run in a separate target to your unit and integration tests and that your integration layers and tests are as thin as possible to make the rest of your code as light, as supple and as rapidly testable as possible.

Simpletons - Smarter than you think

"Divide and Conquer" and "separation of concerns" are terms that have been banded around software design conversations for some time, yet how many of us still see classes being implemented that try to deal with everything under the sun? This got me thinking about how can we make it easier to visualize the simple entities, which are easier to understand and easier to test.

Simpleton – An object that has one purpose.

I applied this thinking to a recent story where I had to implement a security model in our public service api. The model needed to validate http requests against username and password and a digital signature.
Following the simpleton approach it was possible to drive out the following objects:

BasicRequest – Extract http BASIC credentials from an http request.
SignedRequest – Extract custom http headers from an http request.
BasicRequestValidator – Validate request based upon the provided basic header details.
SignedRequestValidator – Validates request based upon the provided digital signature.

By allowing objects to have only one purpose it was remarkably easy to tdd each object in turn and integration into the service tier was simply a case of newing up the Request objects and passing them to the validators.

So next time you're thinking about the objects you need in your system, become a simpleton, it might be pretty smart :-)