Spring Roo Experiment, part 2

Making it perty

Roo does a great job of making a functional CRUD website, and that's great for an admin page. But public-facing websites, especially ones developed in 2011, need to look funky.

Enter Bootstrap, from the good people at Twitter. I'm not a Tweeter, but I have to extend maximum love and respect to these guys for turning out something to make things look so good, so easily.

Including the Bootstrap CSS in your webapp is like having the most web-2.0, rounded-cornered, missing-vowelled, fixie-riding front-end guy pairing with you, except he's actually completely finished the work, it works on all browsers and you don't have to listen to him talk about his iPhone all day :-)

Seriously though, Bootstrap does exactly what it says on the tin, with beautifully-clean, semantic markup, a wonderfully easy-to-use grid system and a contemporary, stylishly-minimal look.

I downloaded the Bootstrap CSS file and added it to my Spring Roo project by following these instructions - so now I can flip between the standard green Roo theme for my admin pages, and the super-funky Bootstrap theme for public pages. Lovely.

Spring Roo Experiment, part 1

Kicking the tyres

Wow - been getting a bit "10,000 foot view" recently. Back to good ol' Java. In particular, Spring Roo.

I had a bit of an idea for a basic database-backed web app, but the thought of all that XML-fiddling, boilerplate Java rubbish just to get something going was turning me right off. I'll admit, I seriously contemplated trying Ruby on Rails to get started ... then I remembered a colleague mentioning Roo as the Java answer to Rails. Java, Spring, Spring MVC and Maven best practices all driven from a console app?! Had to be worth a try!

I ran through the "pizza" sample, doing the setup for my app at the same time. Apart from a hiccup with my local Nexus instance (I always forget to add new repositories to the public Group!), it was super-smooth.

What struck me was how I was able to concentrate on my domain objects (aka entities in Roo-speak) and how they interacted. In four lines, I can make a typical tested, persisted POJO with a full CRUD web GUI!:

roo> entity --class ~.DescribedThing --testAutomatically
roo> field string --fieldName name --notNull
roo> field string --fieldName description --notNull
roo> web mvc all --package ~.web

It's really fun to "meta-program" like this. Less boilerplate, fewer typos (thanks Tab auto-complete!) and more designing.

I'm going to continue developing Roo-style for as far as it will take me and see how it goes.

Extending your SEP field

More anti-complexity ravings

Once you've got over your Complexity "Hump" things become a lot clearer.

The "good programmer == lazy programmer" thing is merely a starting point to a wider world of Using Other People's Stuff. In university this was A Bad Thing, but in the real world, call it "leveraging" and you're on your way to an MBA.

It can be succinctly summarised as Maximising Your SEP - nothing to do with getting a higher Google rank - I'm talking the Somebody Else's Problem. The SEP is the secret to a slender, simple IT solution. The whole "Cloud Computing" hype-bubble is actually SEP translated to the machine-room and its associated sysadmins.

With judicious use of SEP, your "in-house" component is the smallest possible intersection of other peoples' work - be it libraries, frameworks, or servers. Sprinkle in your domain model and you're done.

Moving your infrastructure "to the cloud" is totally hot right now - but how many development shops are actively trying to offload their code too?

Die Complexity! Die!

I've mentioned it before but I feel the need to do so again. What is it with developers and complexity?

You know when in a film or cartoon, a character opens an innocent-looking door and all manner of horror and noise belches out, so they quickly slam the door and the noise stops? I got another blast of that kinda thing recently - innocent-looking website, foul twisted complex horror beneath. Why does this happen?

My current theory boils down to a three-legged milking-stool of failures:

1. Developers move on and can't/don't/won't pass on all their knowledge. Replacement developers have to read between the lines (or worse, read bad and/or out-of-date documentation) and are doomed to repeat the past, slightly worse each iteration. Rinse and repeat


2. Developers love doing new stuff. At least, the good ones do. They love to cover a pristine whiteboard with boxes and arrows. Who doesn't love the purity of a codebase that consists only of interfaces? No implementation means no ugly real-life workaround warts! The trouble is, we can't all be developing new frameworks all the time


3. Lastly, and most controversially, The Agile Process, or rather, the blind adherence to some aspects of it, can be blamed. I'm talking Sprints here. It seems like in the effort to shoe-horn a large piece of work into a too-short sprint cycle, the lethal one-two punch of doing a half-a[rs]sed job and chalking up a load more technical debt to actually do it the right way* has become an acceptable outcome. It isn't

The solution? BAN Complexity in your development team. Stamp on it the instant it makes a first tentative push out of the soil. Make it a priority amongst the team members to simplify any new feature to the utmost. Exercise and extend the Boy-Scout Rule to make each and every code commit an incremental improvement in straightforwardness.

How will this help address the milking-stool of coding horror?

1. Simpler code groks faster so new devs don't need all the handover baggage
2. Developers can still show their design skills, but at de-baroquifying designs. Surely that's a whole lot harder than over-engineering?
3. And finally, if you can't change your sprint durations (and if not, why not?) then lower complexity should go hand-in-hand with higher velocity. There must be no Tech Debt. Ever

(*) In some mythical far-off time when the schedule does allow for longer-term work to be completed...

I <3 WWW

As I'm not an iOS or Android developer I attended the August "Mobile Focused" Melbourne YOW! Night with a certain degree of reluctance.

I had visions of skinny-jeaned, black-plastic-spectacled iOS-developing hipsters telling me how, like, awesome their, like, app was because like, it totally like mashed up the tweeting paradigm by like ironically cross-pollenating the artisan tumblr mixtape vibe (thanks Hipster Ipsum!).

And while there was a certain amount of that, I was somewhat refreshed to hear from a couple of speakers (native mobile app developers, mind you) that a great deal of the time, when you strip away all of the hype, what the customer needs can be addressed with a mobile-focused website.

I've seen first-hand the hype-storm that (in particular) the iPad has created. One of the speakers at YOW! painted a pretty accurate picture:

• CEO's wife buys CEO a new iPad because they're shiny
• CEO can't really use iPad but notes these apps on the home screen have pretty icons
• CEO sees other companies have apps
• CEO decides his company needs an app
• CEO doesn't exactly know what app is for, but knows that it's needed NOW

What follows (MyCompanyApp v1.0) is usually an app-ification of what the company's current website offers. It is a pointless, money-wasting exercise that gives the CEO his app icon that he can show off in the golf club, but actually has zero advantage over his website (actually negative advantage because it doesn't self-update like a web page).

If the iPad had a way to add a shortcut to a webpage as a home-screen icon, the whole thing could have been done in 30 seconds.

As mobile devices get increasingly capable, well-written, lightweight web pages with advanced features like HTML5 Geolocation can get pretty damn close to the "native app experience" - with none of the approval-process or old-installed-version hassles.

So that's the basket where I'm putting my eggs for the next little while; I just hope the egg doesn't end up on my face :-)

The CSS F(l)ail

I've written before about CSS and why it seems to be so hard for a Typical Java Developer (TJD) to craft "nice" HTML+CSS presentation layers.

Here's the behavioural pattern I've observed when a TJD has to do some front-end web-work

:

• Panic - rather than embrace the opportunity to learn a new paradigm/technology, as they would probably enjoy doing if it was a Java API


• Copy-and-paste from the existing codebase - despite knowing that this leads to unmaintainable code no matter what the language


• Copy-and-paste from the web - without understanding what is going on


• Randomly tweak values in the browser using Firebug or Chrome Developer Tools until it "looks right" (I've started to call this CSS flailing)


• Give Up And Use Tables (for non-tabular data). The ultimate fail

In posts-to-come I'm going to try and identify some CSS "patterns" that a software developer can actually understand (as opposed to copy-and-pasting) which hopefully will put an end to the above behaviours, any of which would be regarded as unforgivable if it was perpetrated in the squeaky-clean corridors of Java-land ;-) but are somehow considered par-for-the-course in the unfamiliar yet forgiving world of UI...

The Battle {For | Against} Complexity

Rod Johnson:

"I probably shouldn’t say this in a Java community website, but I think that the Java community has almost a pathological desire for complexity at times."

Testify, brother! Although I must add that I suspect this is not exclusively a Java-specific syndrome.

I think it's more to do with the average experience level of developers on a given platform. I would expect the typical Rails developer to be more experienced than a Java dev (I have nothing to back this up, but a cursory inspection of the type of questions being asked on Stack Overflow would tend to confirm this). I have observed a distinct correlation between development experience and desire for over-engineered, complex solutions; it looks like this (pardon my ASCII):

D(comp)
|
|               C C C
|             C C C C
|           C C C C C C
|         C C C C C C C C
|       C C C C C C C C C C 
|     C C C C C C C C C C C C
|   C C C C C C C C C C C C C C 
| C C C C C C C C C C C C C C C C C C C C
|------------------------------------------- Exp
0   1   2   3   4   5   6   7   8   9   10            

The initial "I'm so green" fear of complicated stuff quite quickly is replaced by a desire to flex one's "architect" muscles, typically culminating in an extravaganza of ornate (often distributed) designs at the 4-5 year mark. Shortly afterwards, the folly of one's ways is realised. Ornate designs require ornate maintenance, and that doesn't go down too well with anyone, least of all the prima-donna who came up with the design and now is saddled with babysitting it. The enthusiasm for system diagrams with many, many boxes quickly subsides. A pragmatic programmer emerges at the 8-year mark. DRY, YAGNI and anti-NIH are the order of the day.

And that seems to be the difference between the Typical Java Dev, who is probably sitting on top of the above mountain, and the grizzled Typical Rails Dev, who has scaled it and is coasting down the other side :-)