Archive for the ‘design’ Category

Give your DB the love it deserves

Pity the poor database. As critical to most apps as a foundation to a building. And as interesting as an accounting seminar at a nudist colony.

Not sexy enough for the attentions of the senior dev, or considered to be “well understood”, DB work frequently end up getting handed off to the junior guys on the team. Who promptly make all the mistakes the senior guys have learned not to make. Mistakes which end up with massive hunks of sub-optimal compensating code in layers above them. Then they write some code off the back of them. Viola! Instant technical debt.

Queue self-perpetuating “relational databases aren’t web scale“, “normalised schemas aren’t performant”, “You don’t have these problems with NoSQL”.

Senior guys often don’t have the time to deal with it. DBAs aren’t seen as being responsive enough for JFDI/iterative development. Peer review at the end is too late.

So what’s the fix? Just enough design. Back of napkin. Whack together a schema, and talk through with someone (else) who knows what they’re doing. Then code. It’s not rocket science.

Rich UI -> Component Based

A client of mine is developing a web application. The framework decision was made up front – Spring Webflow/MVC. I like Webflow. Its state machine based continuations concept is very cool. It lets you easy deal with things like back buttons, switching into a side piece of application flow (think needing to log in before continuing on to a section of the site) and maintaining a history of the state of a flow (where going back means using the application state as it was at that point in time). In short it’s pretty powerful stuff.

Only one problem – the application front end has been prototyped and signed off on by analysts used to working with desktop software.

Put simply, it’s expected to do some pretty crazy stuff. Think multiple layers of tabs, where the user can switch between different parts of the app without saving, navigating around fields from a central list of items that need correcting. Erk! The amount of hoops that have been had to be jumped through to get the requirements working have been huge, and it only keeps getting more complex. Without Webflow, I can’t imagine how something of this complexity could have been addressed. Classic web frameworks wouldn’t help on this one without some serious

The thing is, while Webflow makes it achievable, it’s not the right tool for the job. The interface requirements are too complex to easily do this stuff. Using a framework that ties you to the request based programming paradigm is the wrong way to go.

Put simply, we wouldn’t have the same sort of problems if the system we are building was constructed on a component based framework like Tapestry, JSF, or Wicket. Components have state, the page is composed of them and you react to events – “the button was clicked”. No more
request. No more session. Need to pull together info from multiple tabs? No worries – do it when the “I’m finished” button has been clicked. It takes a big mind shift to step away web concepts, but it’s worth it. At the very worst, there’s a new piece of kit in your toolkit that you can select for the task at hand.

As your tools become more capable, the requirements from your clients get more demanding. Your next web app interface won’t look like the last one you did. It will look like the latest whizz-bang offering from the latest flash in the pan start-up. Your clients use the net. They can see what others are doing. They expect that you can deliver the same. This is especially the case for internally used desktop replacement apps. If you don’t have the tools, you’re in for some late nights.

If it looks like a desktop app running in a browser, forget your father’s MVC framework – it’s just won’t cut the mustard.

It seems like a happy coincidence for Ruby on Rails that Web 2.0 apps emphasise simplicity. Classic MVC is not up to the task of rich UI.