John Reynolds's Blog

Programming Archives

Iterative Development

GUI Builders Considered Harmful

I came across this Hacknot blog entry today, and thought I'd like throw in my own two cents worth on this topic...

The following pretty much sums up the tone of the blog entry:

"For the benefit of those who risk falling for the superficial appeal of GUI builder tools, this article will outline the major failings of this application genre."

Hacknot's intent was to sound an alarm and warn folks from making a costly mistake, but what grabbed my interest was something quite different... the article unintentionally points to the features that a Successful GUI Builder^TM would have to incorporate.

I think that the primary mistake of the unsuccessful GUI Builder's that I have used to date is that they are Screen or Page oriented.

Many of the issues raised by Hacknot involve interactions between low-level components on a screen.

Consider the following interface panel from the Hacknot blog:

Hacknot offers this commentary:

"Looking at the above, it is immediately obvious that the "Home" and "Work" groups are so similar that they could be different instances of a custom component, with labels and callbacks parameterized differently. Will a GUI builder spot this? No. Press the "Generate Code" button and the GUI builder will happily generate two near-identical blocks of code, probably within the same class body, probably within the same class method. "

All successful programming tools complement the skills of the human programmer (rather then over-riding those skills). In Hacknot's example, the programmer may have not recognized the advantages of creating a custom component when first designing the screen... but it would have become obvious soon after prototyping began.

We don't really need tools that spot opportunities for code reuse. We need tools that help us refactor our code once we have recognized the patterns. The one thing that us humans are really good at is pattern recognition.

How does this apply to creating the Successful GUI Builder^TM?

I think it all boils down to blurring the lines between what is a screen and what is a component. We should be able to build up sophisticated components from common atoms, and then build up sophisticated screens using sophisticated components... all without having to switch to another tool or radically shift our development paradigm.

In this respect, I think that theTapestry web component framework is a bit better then Java Server Faces. In Tapestry, there is almost no difference between a component and a page definition. In JSF it's quite a bit different (hopefully this can be addressed in the future).

Will the Successful GUI Builder^TM ever be built? I don't know for sure, but I wouldn't bet against it.

Java and scripts and pipes

All the recent ramblings about Groovy and Jython makes me wonder:
What makes scripting so powerful?

Let's start with what a "script" is:

In a play a script tells the actors what to do. In a software environment a script tells preexisting components what to do.

Scripts aren't about creating actors or components, they're about orchestrating actors or components.

So why isn't Java a scripting language? After all, Java can be used to invoke preexisting components.

I think that shells and pipes are the answer. Scripting languages (such as bash) have interactive shells. The shell lets an author interactively develop and execute the scripted behavior of preexisting actors (components)... but it also places constraints on those components to enable the use of pipes.

Components that can be executed within a shell must have well defined text-based interfaces. Each component must be able to accept text-based input, and each component must return a text-based outcome. If non-text input or output parameters are necessary, they must be packaged in entities that can be referenced by a text string (such as a file or a stream). These interface constraints are what enables pipes, and the ability to pipe the outcome of one component to another is a big factor in what makes shell scripts so powerful.

I'm just thinking out loud here, but when I look at Groovy and Jython and compare them to bash, I get worried that the value of scripts and pipes might get lost in all the syntactic sugar.

The Rich Web Client conundrum

In reality, there are only three options for implementing the client-side of a Rich Web UI...

Client-UI options:

1. Construct the UI using Javascript, DHTML and CSS based components
2. Construct the UI using components provided by a browser plugin (such as the Java plugin or Flex)
3. Attempt to combine the two approaches using something like LiveConnect (Trust me, this never works)

Options for implementing the server-side of the application have really only two options...

Server-Procesing options:

1. Process HTTP Posts
2. Process "custom" data streams or remote method calls (HTTP tunneling, RMI, etc)

I don't believe that this is an over-simplification; you could certainly nuance each option, but essentially these are your choices.

Tapestry, JSF and Echo all use Javascript/DHTML components and process HTTP posts. Each of these frameworks hides the Javascript and DHTML from the programmer, but peek under the covers and that's what you'll find.

Macromedia Flex, Laszlo, Thinlets and plain old Java applets use custom UI components and encourage the use of custom protocols. With these frameworks the line between web-app and traditional network app blurs... maybe that's a good thing, maybe not.

Life can be simpler if you accept this general view of Rich Web Client frameworks... well, perhaps life won't be simpler but your decision making process for choosing your Rich Web Client framework can be.

Your client-side choice boils down to accepting the basic constraints of the ubiquitous browser, or to tie the use of your application to the installation of a third-party plugin (Flex, Java-plugin/Web Start, RealPlayer, etc.) If you really can't live with browser constraints this choice is simple, but most of the time the browser is more of a pain then a true brick wall.

There is one other very important concern before you're done with your client-side choice: What devices will you need to support?

A few years ago, Desktop and Notebook browsers were the only concern, but increasingly PDAs and mobile phones are the devices of choice for accessing Web-based applications. Will your choice of Rich Web Client framework preclude you from supporting these devices?

Your server-side choice has a lot to do with your control over the server: the more esoteric your processing, the fewer hosting options, more firewall concerns, etc. In general I shy away from custom protocols, but if you gotta have it, you gotta have it.

Now comes the bad news. If you pick the wrong approach you're pretty much hosed. There is not a clean migration from the Javascript/DHTML UIs to the richer component UIs. Frameworks like Echo and Tapestry help erase the differences between the browser programming model and traditional component programming models, but if you find that you need a component that cannot be implemented with Javascript, you're out of luck.

So what of the future for Rich Web Client development? Are our choices going to get simpler, or more complicated? Only time will tell.

Update: I came across an excellent discussion by Oliver Steele on Serving Client-Side Applications.

For another perspective, check out this article on Intergrating Macromedia Flex and Java.

Continue Reading...

Anti-Pattern - The Swiss Army Effect

After the "new" had worn off, the knife disappeared somewhere into the bowells of a dresser drawer. I didn't lose the knife, I just discovered that it wasn't all that practical. I never did use all the blades, and the tools that I did use were encumbered by all the superfluous ones.

I'm sure that you figured out where I was heading with all this when you read the title of this blog. Don't get trapped by the Swiss Army Knife pattern. Don't add too many "blades" to your applications. Build focused tools that solve specific problems.

All of that is true, but it's also far from controversial. Why waste time blogging about it?

Why indeed? Because I want to make a different point. In many ways, Java is becoming a great big Swiss Army Knife.

I am not real happy with the oposition by IBM, BEA, and Oracle to the JDO 2.0 jsr, but embedded in their arguments is a valid point ( see Three votes no on JDO by Daniel H Steinberg ). The J2EE specification is huge and Java development is complicated by too much flexibility. In this specific case, EJB and JDO both specify a persistence mechanism. EJBQL and JDOQL greatly overlap and both are subsets of JDBC's capabilities. Why not agree on a common core and deprecate the duplications?

I tried to make this point in my earlier blog: Make JDO the "P" in CMP. JDO and CMP should be complementary rather then competing solutions

The EJB/JDO overlap is just one symptom of Java's march to complexity. Perhaps we need to expand the mandate of the JCP to include consolidation and deprecation rather than just expansion. Our knife already has plenty of blades ;-)

Continue Reading...

Coding for your own legacy

I fear that most programmers (myself included) usually think of the word "legacy" as something bad, as in the following article:
Do your customers have legacy COBOL applications written around the time King Nebuchadnezzar II built the Hanging Gardens of Babylon?

Legacy doesn't have to be a bad word, as is seen in The American Heritage® Dictionary of the English Language:

leg•a•cy

Something handed down from an ancestor or a predecessor or from the past:
"a legacy of religious freedom." See Synonyms at heritage.

What are you doing today to insure that the programmers of tomorrow don't curse that @#%!! legacy Java code that they're stuck with?

Based on my own astute powers of observation (and my gut feelings), I will hazard to publically predict that the programmers in the distant future (say five years from now) will not all be using Java. I further predict that the many programmers who will be using Java will not be using the primitive dialect that we currently employ.

With this limited knowledge of the future, how can I increase the odds that my coding efforts will be appreciated rather then cursed? To answer this question, I took a look at my least favorite legacy "assets" and tried to put my finger on what annoys me most.

Many of my least-favorite legacy applications have poor documentation. If you want to make a future programmer happy, explain what your code does and how to use it in clear and concise terms.

Hard to generate inputs and hard to parse outputs are guaranteed to produce expletives rather then praise. I once wrote a "survey" application whose output was serialized C++ objects. A companion application, also in C++, reinstantiated the survey objects to populate a database (The "surveys" were mailed to consumers on floppies. When the consumers mailed the floppies back, the results were retrieved). This was a great idea until the company switched to Java. If I had added code to produce ASCII output (this was pre-XML days), I would have been cursed less often. Efficiency does less to assure a good legacy then interoperability.

Several of my least-favorite legacy applications are bound by Graphical User Interfaces. GUI applications are notoriously difficult to integrate with anything else (see the blog by Rich Burridge for specifics): Contrast reusing GUI applications with reusing the CLI shell utilities that are so prevalent in Unix environments. I'm not suggesting that GUI interfaces aren't appropriate, just that life is easier when designers include command-line interfaces or programmatic APIs to access the core functionality.

Finally, my least-favorite legacy assets often do more then they need to. Sometimes the programs have bizarre side effects, but often the problem is that the original designer didn't distill the functionality to its essence. It's like having to pay for a reverse-osmosis purification unit when all you need is a water heater.

We can't guarantee that our heirs will value our code, but with the benefit of hindsight we can improve the odds.

All this leads me to think that embracing the Service Oriented Architecture paradyme will reduce the chances that I will be burned in effigy some day. SOA is defined in an IBM article as:

SOA is - "an application architecture within which all functions are defined as independent services with well-defined invokeable interfaces which can be called in defined sequences to form business processes."

"this is my service it does X, and when you tell it to do X with this data, it does something and gives you this back"

Continue Reading...

This work is licensed under a Creative Commons License.