Alex’s Notes

It shouldn't come as a surprise that deployments of new code can be stressful times. After deployment, developers tend to wait with baited breath for things to "break".

Even with the best testing strategy and coverage, real world use of a system quickly uncovers issues. Real users use a system in less predictable ways than the unit tests we run or system tests we may perform.

Developers very often patch these issues quickly. Less time has been spent on formal testing which isn't always an accurate reflection of real use.

After a period of firefighting, the system is good to go. Exposing flaws developers hadn't anticipated would be why beta testers exist. However, not all environments have a worthwhile number of beta testers at their disposal.

The question is - is it acceptable to use users as guinea pigs following the "release early and often" mantra?

It is my belief that we reach a level of system stability* quicker this way, at the risk of causing frustration and losing user confidence. As ever, it depends on the nature of the system.

* Within the envelope of the operations all users perform - unused functionality is still untested.

Cleanly defining and managing the flow of screens in web applications, particularly multi-step processes or workflows can be challenging. Due to the stateless nature of HTTP, state has to be managed through cookies, hidden fields, URLs or session data held on the server. What if the user clicks the back button? Meh.

I was thinking, why can't we model web application flow like the monolithic programs we knocked together when we were young? (Or was that just me?)

10 PRINT "What is your name?"
20 INPUT NAME$
30 PRINT "Hello, ";NAME$
RUN

What is your name?
? Alex
Hello, Alex

It turns out I hadn't invented anything. An approach known as a continuation can make this happen. The Apache Cocoon and Seaside framework do just this in a web setting and this article from IBM describes it very well. A continuation is effectively a way of freezing code execution mid flow and squirreling it away to be continued later. When that happens, all prior state/variables are as they were and the code can continue to run, unaware that anything happened.

Somewhat like hibernating your laptop, rather than shutting it down, perhaps.

As it happens, this approach fits well with the HTTP request/response cycle. Code runs, needs more input - continuation stored and HTML form displayed. User supplies more input and clicks submit. Server runs continuation and does some processing - decides more data is needed, continuation stored and another HTML form displayed.

I imagine this kind of monolithic flow would make for very readable business process implementation. I like the idea of the logic of a process is defined as simply as possible in a single location, not scattered across user controls and databases.

One to ponder. This could be one of those cases where a disproportionate amount of complexity is introduced to make something else simpler. Maybe the way we program for the web isn't perfect, but isn't horribly broken either.

My view - your business logic always lives on the server.

User-interface JavaScript running on the client should essentially be a slave to the server. Any decisions or calculations must be made on the server.

Building logic in JavaScript is tempting. It's often fast as no server roundtrip is involved. It is very easy to code as you're not having to worry about shipping values to and from the server.

However, when running on the client you have little control over faulty language implementations or, more likely, people manipulating your code and XHR payloads with tools such as Firebug. 

If the server blindly accepts what it is given by the client, you're in trouble. In Web 1.0 terms, this is synonymous with having a form with only JavaScript validation - a browser without JavaScript enabled would be able to submit invalid data.

Always running logic on the server has a host of advantages in addition to closing security holes. You are in control of the runtime and can reliably test its behaviour to be consistent. You only need to test your deployment runtime, not every browser you plan to support. From a performance point of view, the .NET or Java runtimes are likely to be considerably faster than JavaScript running on a client PC.

Some applications could run logic on both the client and server but this may result in duplication. Offloading processing to the browser could make an application more scalable. However, logic on the client should be considered supplemental and should only invested in where there is tangible benefit. 

Reading through my prior posts, it may seem like I don't have much time for user interfaces and don't value the user experience. I really do - I love good ones. This is why I enjoy using my Mac. 

During development, the user interface is the part that all stakeholders see. Consequently it is what they will comment on. They don't care about the beautiful object model, the all green jUnit test suite, the indexing and caching strategy or the queries that return in a fraction of a nanosecond at this point. (They will only care about that after the system has gone into production.) No, at this point they'll ask you to change the wording on a button or to try a different shade of green.

Everyone has an opinion about what makes a good UI. Most people know it when they see it. If they don't see it, they'll make suggestions - often with no basis in reality. Their suggestions can be useful but are only an opinion. One stakeholder's views on buttons being right aligned, for instance, may not be representative of your entire user base. 

A project needs a UI/UX lead who is skilled in managing the oft-subjective (or ridiculous) suggestions from other project stakeholders. Without such a person, a project can find itself in trouble. It should not be assumed that visual / graphic designers know the first thing about interface design. Likewise, database developers may happen to be good at neat and tidy programmer-style UIs but they are often not UI experts, just as a UI expert may not write the best SQL or be able to operate Photoshop. 

Without a UI guru, there's a real danger that a disproportionate amount of time is spent by a team of UI amateurs agonizing over bevels, rounded corners or the wording used on a button... whilst system functionality gets neglected or forgotten about. 

As developers we continually seek to improve our game. In good teams, people share approaches and patterns.

One approach I use a lot is to write each step of functionality as a one line comment. After all the steps have been 'defined' as comments, I review and refine them - possibly changing the order and refactoring before any code has been written. Once I am happy with the comments, I find that filling in the implementation between the comments is easy.

It keeps code focused and forces me to consider the whole problem before diving straight in.

I obviously haven't invented this approach but it works for me. If you prefix the comments with TODO: in Eclipse, it populates the To Do window. Neat.

So that's one oldie that works for me. What approaches along these lines would YOU recommend?

Having sung the virtues of Google Web Toolkit for well over a year, I did an experiment. I rewrote a section of a prototype GWT application using JavaScript and YUI. It took me less than two hours, including time to consult the excellent documentation. The YUI version was deployed this afternoon.

Those of you who follow me on Twitter will be used to my occasional rants about web development. I love my job, but almost every day think that there has got to be a better way to do things, particularly on the client-side.

As we all know, the web started out as a way of displaying documents, regardless of computer type. This collection of hyperlinked documents somehow managed to become the runtime of the 21st century. It doesn't matter if you run OS X, Linux, Windows - a vast amount of what you do on a computer these days is in a web browser. Fact. Don't believe me? Unplug yourself from the network - turn off your wireless card. See how long you last.

Due to our reliance on the browser, JavaScript has become the world's most popular language.

Douglas Crockford, creator of JSON and author of one of the few decent JS books excellently sums up the misinformation and understanding that surrounds JavaScript. "...JavaScript has more in common with functional languages like Lisp or Scheme than with C or Java. It has arrays instead of lists and objects instead of property lists. Functions are first class. It has closures."

So why on earth did I attempt to write a web front-end in an arguably inferior language: Java, with the Google Web Toolkit?

I'll hold my hands up. Despite being able to churn out a lot of JavaScript code, I guess I didn't know JavaScript.

When Google released the Google Web Toolkit sometime in 2006, I was intrigued. I had dabbled with creating AJAX-y front ends of my own but almost consistently had ended with very brittle code. $$ and $A and $ functions made me feel unusual. Debugging was impossible. Things would stop working - yet no error messages would be given. With this in mind, GWT made perfect sense. A good UI widget library, strong typing, a compilation step to catch errors early, debugging, excellent IDEs, optimized code for each browser masking quirks and behaviour variation..... oh my, I was sold.

I enjoyed the rigidity of working in Java for client as well as server-side work. Using Eclipse I was soon refactoring frequently, being forced to define interfaces, unit testing, creating mock objects, using dependency injection, creating components, thinking in terms of events rather than forms and URLs... the list goes on and on.

However, in the last week I came to the realization that, with a bit of discipline, I could apply identical development approaches when using plain old JavaScript and YUI. For every perceived advantage of GWT, JavaScript had an answer. Unfortunately, GWT brought disadvantages of its own. 

• The built in widget library - calendars, drop down menus, trees, etc - whilst comprehensive, was fairly basic and hard to skin with CSS. Remember the promise of being shielded from browser quirks and variations? Forget it. Any web front-end library is all about the widgets. YUI (and others) are arguably superior.
• Compiling five versions for each supported browser proved to be very slow: 20 seconds on a 2.26Ghz MacBook Pro for a very small app. This may sound like a minor thing, but it did slow the development process down considerably. The rapid edit-refresh-edit development model of the web is extremely productive - live in-browser CSS and JavaScript editing are now also becoming common place. Some advantages of the compilation step can be matched by using a tool like jslint. jsunit also allows in-browser unit testing of JavaScript code.
• Eclipse is a fine Java IDE and the Google plug-in is an excellent addition. Code generation, hinting and completion were all welcome additions having come from a text editor. Refactoring GWT code within Eclipse was something I did frequently - although ultimately my use boiled down to a semi-intelligent search and replace. My time with GWT reminded me how important refactoring is. 
• Debugging within Eclipse only worked when running the Java code - you were not debugging the compiled JavaScript. There were differences between what happens in hosted mode and what happens in the browser. In addition, native JavaScript debugging within the browser has come a long way - particularly in recent versions of Safari and Firebug.
• Browser speed. It was easy to forget that one is targeting a web browser. It is natural to think in terms of components, event listeners and forget about the crazy HTML that is being produced somewhere. Although this is the logical assumption to make when using GWT, it is a mistake - the result is extremely slow code. Whilst this isn't such an issue in modern browsers, it is if you want your code to run well in Internet Explorer. For instance: a complicated list of objects took 20ms to render in Safari and 4000ms to render in IE7. 4000ms is unacceptable. The solution?  Render HTML in a stringbuffer (or on server) and use element.innerHTML = ".." to inject it onto the page. You throw away all the object-orientated/component/event goodness. The issues with speed are no doubt due to the slowness of DOM manipulation routines in certain browsers which aren't GWT's fault. Regardless, this low-level work around defeats the purpose of GWT to my mind.
• The event bus pattern I previously blogged about is trivial to achieve in JavaScript with a lot less code. Events are core to JavaScript within a browser. Custom event models are extremely easy to implement with a good library such as YUI or prototype.js. Whilst the GWT HandlerManager worked fine, I felt a disproportionately large amount of code was needed. 
• JavaScript can be fabulous. It has closures. More can be done in less code. A callback object can be defined inline, in literal form: { onSuccess: function(e) {}, onError: function(e) {} }. I intend to elaborate on this further with some some side-by-side GWT vs YUI code comparisons in a future post.

Maybe I'll be back in a future post saying that I didn't understand GWT (or Java) well enough. GWT will continue to evolve and Google Wave, which is built using GWT, will no doubt be a seriously impressive web front-end. 

GWT, particularly the Java-JavaScript cross compiler, is a stunning feat of engineering. Maybe the coolness of the hack is what attracted me to GWT in the first place. But like so many tools made by developers for developers, the beauty lies within - in this case the API and the compiler. The over-engineered end result just doesn't do all of the effort and cleverness justice.

There is much I like and admire about GWT. I may use it again. Regardless of whether I use it in future projects, I have GWT to thank for forcing me to apply proper software engineering approaches to web client development. 

A minor domestic broke out in my house last night. I am a software developer and know nothing about graphic design but I do know what web sites look good and work well.

My other half, a graphic designer, disagreed with my notion that the best looking websites were crafted by designers who were conversational with HTML and CSS, or at least used tools that generated it. In my world, rather than designing in Photoshop (or any other graphics tool), designers would translate wireframes (hand-drawn or digital) directly into HTML and CSS. She contends that websites should be implemented by passing static graphics files to a developer who can translate that into code.

I have several reasons for thinking this is a strange way to work.

The first is the word 'static'. Web sites are not static images. You can click them, scroll them, type into them and zoom them. You could have clever drop down menus, accessible keyboard navigable controls and lovely smooth jQuery animations.
They say that "every picture tells a story" but in this case it only tells the first few chapters.

The next issue is what happens to the PSD files the designers output. Effectively, these are an intermediate blueprint that get thrown away after the build. Following this model, I find it strange that designers, who are understandably protective of their work, allow it to be interpreted and implemented by someone else. The designer effectvely works by proxy and hands over the reins. They cannot directly make small tweaks and iteratively improve their work without asking the developer to make these changes.

The final issue, related to the above, is change agility. The static image approach is clearly a hangover from print work. Deploying a website is not the same thing as sending a job to the printer.
A web page and corresponding stylesheet can be changed at any time. It is likely that at some point, the client may request changes that need the original designers' input.
Imagine the scenario: the client asks for a certain paragraph to appear inside a red box. Does it really make sense for a designer to open up Adobe Illustrator and draw a red box around the paragraph in question, manipulate the text and other jiggery pokery?
In HTML, this would be a case of adding: "background-color:red;color:white;padding:2" to the relevant paragraph. This could be done in the time it takes to open Illustrator. By abstracting away the web and treating it like an image, you throw away the benefits of working in a
powerful declarative content and presentation environment like HTML and CSS. It's a duplication of effort, at least.

In no way am I suggesting that all web sites should be created by programmers nor I am not saying that designers should be CSS masters or gurus in browser quirks.

I just feel that it is important to use the right tool for the job. If a designer is capable of using the frankly baffling Adobe CS4 then they should be able to use tools like CSSEdit in their sleep. Visual tools that emit working, web-ready code that can be used as a basis of the build give designers continued control of their work and allow them to directly target their deployment medium.

Bespoke developments for internal use can fall into many traps. 

Technically, it is harder to justify refactoring or behind the scenes code improvements to your client or internal customer -- the completely reasonable arguments being "it works (albeit slowly); we cannot risk instability; we need new features". As a result, there is a temptation to write, or build upon poorly structured code to get things done.

From a user interface perspective, people are trained to use the system. They are a captive audience who cannot go off and use something else so often internal system UIs are fairly abysmal. The hideousness of the SAP web-front end proves this point. This is inexcusable - if people are being forced to use a system as part of their job for hours every day, extra effort should be made to ensure the system is user friendly and works with them in doing their job. A bit like having a comfy office chair that doesn't give you backache after half an hour.

Functionally, internal systems risk becoming blunt swiss army knives - they try hard be all things to all users yet end up doing nothing well. Even if you don't plan to commercialise or sell your software, I have learnt that it makes sense to consider every change request as if the system was being developed with real, paying customers in mind.

It sounds obvious but actually putting a price on tasks, considering the ROI and the number of users who would benefit makes it possible to plan changes more effectively. Competitive commercial edge, even if imaginary or indirect, is an important driver in ensuring a system moves forward.The early adopters of the system often get confused as to why their 'order' of a few feature is not implemented. An internal system with five users is a different prospect to one with several hundred. 

Users are the lifeblood of a system should be listened to, but it can be dangerous for them to be in charge. Did you see what happened when Homer Simpson's brother let him design his dream car?