Frank W. Zammetti's Blog

This was prompted by a recent discussion began by (Adam Bien on TheServerSide) and continued on Adam’s blog.

This describes my underlying philosophy of programming…

“Any coding project should be designed and coded as simple as possible, and no simpler.”

I didn’t make that up, and I don’t know who did, but that’s the maxim I always work by, and it has served me well. I frequently bump up against other architects I work with on the job and in open-source projects because they are thinking in terms of this pattern, that design concept, this abstraction and that model. I instead think in terms of what’s really the underlying goal, and what’s the simplest way I can pull that off? Once I have that answer, only then do I think about adding all the other typical complexities we all deal with every day.

To be clear: sometimes complexity is inevitable and even good, no question. Some problems just don’t have a particularly simple answer. Other times, complexity is actually desirable, usually in the name of needed flexibility. I have no problem with those ideas, I agree completely and I certinly recognize that each case is different and needs to be judged on it’s on merits.

But it’s when people take a relatively simple problem and over-burden it with all sorts of ideas and techniques that they’ve heard about over time, all the while thinking they are creating an elegant architecture because it dutifully implements every advanced CS technique there is, it’s at that point I believe they’ve lost their way. For example, patterns are good. Implementing patterns simply because it seems like the right answer, or because it’s the way you’ve been trained, is not.

I’ve seen people creating factories for things that arguably didn’t need a factory… I’ve seen people making all sorts of things singletons for no obvious reason… I’ve seen people go out of their way implementing all sorts of concurrency-aware code when simple synchronization would likely have sufficed… I’ve seen people create a 30-class-deep hierarchy just in case someone wanted to extend the code at any of those 30 points… I’ve seen people choose EJBs over any number of other ways to go because “EJBs are the way to do distributed code in Java"… I’ve seen people refactor code into 30 different methods, each 2-3 lines long, because it supposedly enhanced the readability of the code… I’ve seen people create DTOs for two fields of data… I’ve seen people choose this persistence library or that when basic JDBC and SQL would have more than done the job… and so on.

I’m not saying any of that stuff is inherently bad, nor is it necessarily wrong in any particular case, and sometimes it’s a debatable point either way. All I’m saying is that if that kind of stuff is coming out of your initial design sessions, either (a) you’re designing something inherently very complex and the flexibility is required, or (b) you’re way over-thinking things. If the answer is (a) then fine, so be it, that’s life and I’ll cope! But I’ve seen way too many cases where it’s really (b), but the architects/developers only know how to think in terms of (a), which is a Very Bad Thing™, IMHO.

And none of this is to say I’m perfect by the way… Indeed, there’s only a few pieces of code I’ve written that I look back on now and think I got it 100% right. I’ve certainly over-complicated things sometimes. And sometimes I haven’t complicated it enough, which can certainly happen. That’s when you get down the road, try and extend what you’ve done and realize it’s not viable because you under-thought things a bit in the beginning. That’s a danger, true enough.

But be honest here… in all your programming experience, how many times have you thought something like “gee, this code is too simple, I can’t work with it"? I’d bet not too many. Simple can (nearly) always be extended somehow. On the other hand, how many times have you thought “this code is crazy, the only way I can meet the current requirements is to rewrite it from scratch"? Every developer I’ve ever talked to would say the second scenario happens far more frequently than the first, and that’s my underlying point: if you keep things as simple as they reasonably can (and need) to be, then the second scenario tends to happen less frequently.

Simplicity is good. When something breaks, finding the problem is easier. When something needs to be extended, you can see the consequences of the changes easier. It’s easier to maintain, less brittle, and ultimately, simplicity is simply more elegant than complexity. Why do you think physicists have for years been trying to find a grand unifying theory, something basic based on simple concepts that virtually anyone can comprehend and that’s based on (ideally) a single, simple equaton? That strive for simplicity has at it’s core the realization that simplicity equates to elegance, and that’s a concept I whole-heartedly agree with.

Homer Simpson once quipped: “The Internet? Is that thing still around?!?”

I now ask the same question of Struts.

Now, before I go any further let me just say that contrary to the title of this post, I’m not actually picking on Struts. You can in fact insert virtually any existing Java framework in place of Struts and come away with the same meaning. I specifically said Struts because (a) it’s the framework I’ve historically had the most experience with, (b) it’s the most well-known framework out there, and © even in it’s latest incarnation it strikes me as especially superfluous (ok, *that* one might be picking on it a little ).

What do I mean by superfluous exactly? Well, let me explain the way I’ve been developing applications of late, what technologies I’ve been using.

It all starts with DWR. There’s some Spring mixed in, but not to a great extent (I see using Spring more and more as time goes on, but so far it’s just doing some basic IoC for me, and providing some nifty JDBC code). That covers the server-side. Yes, that’s right, nothing more than DWR and Spring.

On the client-side I use a couple of different libraries, although I’m migrating quickly towards ExtJS almost exclusively. I’ll also mix in other libraries as needed, a little Dojo here, a little dhtmlx there, a sprinkle of Prototype and a dash of Mootools. But by and large, it’s ExtJS.

So, what happens by using this “technology stack"? A couple of things….

First, the fundamental architecture of the application changes. No, to be precise, it more clearly defines what I’ve been doing for years. You see, I’m one of those people that have been building what we now call RIAs for about 8 years now. I didn’t think to come up with names for all the stuff I was doing, otherwise it would be Frank Zammeti rather than Jesse James Garrett who invented AJAX! I’m far from the only person that can say this by the way, I now know plenty of people were doing things similarly.

The fundamental change I’m referring to is that you let the client essentially be your view and control layer, and your server-side code is a service-oriented architecture hidden behind a simple, clean POJO-based API.

This is nothing new. Remember Swing apps? Remember VB apps? Remember everything we did on PCs before the web? It’s that all over again, except that now, our model code, and our core application logic, runs on the server. The presentation, and the application flow logic, resides on the client. So in many ways, this is absolutely nothing new, it’s just a different set of technologies we’re implementing with.

The second thing that changes is that all these frameworks that everyone has been using all become absolutely pointless. I frequently get asked how to use AJAX with Struts. How do I return JSON from an Action and use it on the client? I used to give an answer to that, show how to do it. Then I started to realize that it’s the wrong question to be asking in the first place.

What happens when you use Struts (or any other framework I remind you) when you return JSON (or XML, or whatever)? At first you may think this is no different than using DWR. But it is, and here’s why: your API, the functionality your server exposes, is abstracted behind URLs. You’re aware that you’re working under the constraints of HTTP. Developers love abstractions, but I submit that superfluous abstractions are… well, SUPERFLUOUS!

When we program in Java on the server, we have classes. We have instances of classes to be more precise. We call methods on those objects. We get some object (or primitive) back, and we use it in some way. So, would you accept the premise that for class A to call method B of class C you needed to make an HTTP request to some URL that mapped to that method of that class? I’d certainly hope not. Even when you do distributed coding in Java, you’re dealing with RMI, or CORBA, or EJBs, you don’t think about the actual communication protocol. You aren’t mechanically constructing a string that identifies what you want to connect to. You simply make a method call, and a container of some sort deals with the details.

So, why should you accept that just because “class A” happens to be some Javascript running on the client and that the method it’s calling happens to be some object on the server that it’s OK for it to not work the same way as it does in the above situation? You shouldn’t, that’s my proposition.

DWR allows you to stop thinking in terms of URLs and get back to thinking in terms of method calls, just like always. I say the server becomes a service-oriented architecture, but I mean this in the same way that class A calling a method of class B views class B as a service provider. It’s stretching the typical definition of “service” a bit I admit, but to the extent that class B provides some function, some service, that class A calls upon, the stretched definition holds.

Even with the nicest frameworks out there that prefer convention over configuration and allow me to develop an application with little “cruft” (i.e., XML config files and the like), the fact is I’m still writing an abstraction above what I’m trying to get at, which is the functionality provided by the server code, even if the framework keeps my workload to a minimum. It’s pointless abstraction in my opinion. It’s not about the amount of work you have to do to implement the application, it’s the approach itself that’s the problem.

Again, I remind you, none of this is revolutionary. None of this is new. It’s simply a recognition of the fact that a modern RIA is much like a fat-client with the exception that much of the application “logic” doesn’t run in the same process space as the code for the presentation portion of the application, or of the code that handles flow through the application.

If you’re getting the feeling that I like DWR, it’s because I very much do! It’s the only “AJAX library", that I’m aware of at least, that leads you to a fundamentally different paradigm. DWR effectively *is* the framework, it’s simply not a “framework” like you’re used to because you simply don’t *need* a framework like you’re used to.

Here’s the structure of an RIA with DWR in the mix:

A single JSP.

Some POJOs on the server.

Thank you, have a nice day.

There’s no Actions to write, no controllers to configure, none of the mess of JSF, nothing aside from Javascript, Java and method calls. This is all the kind of thing that you’ll be reading this post and thinking I’m nuts, I have no clue what I’m talking about, I’m an idiot, so on and so forth.

But try it. Write yourself a simple application with DWR at the core in the manner I’ve just described and then tell me, SPECIFICALLY, how any existing framework makes it better. Believe me, I’ll listen, and I’ll recind every last word here if you can convince me. But you have a tough hill to climb because I’ve done it. I’ve written applications with Struts and even with JSF and have tried a few other frameworks. I’ve also done it the way I’m talking about here. I know which way I prefer, by a mile.

Now, to be fair, do I lose something not using a well-known framework? Sure. I’m still trying to figure out how to do i18n well without a framework essentially providing it to me for free. Naturally, more is dependant on the client and it’s horsepower, which can be problematic. Security, as with all RIAs, is more difficult. I’m not claiming this approach solves every single problem without creating any of it’s own. I’m simply saying it’s better in enough ways to make it the only way I want to develop applications going forward.

This is mostly about DWR in terms of technology, and indeed it’s the key piece to the puzzle. That’s not to say some other library that works similarly wouldn’t do the trick too. The point is it’s got to present an RPC-like methedology, that’s the real underlying point.

I also mentioned ExtJS, which for my money is the single most impressive client-side library in existance today. With ExtJS forming the basis of the UI, and with DWR as the RPC mechanism, you have yourself a winning combination. It’s absolutely amazing what you can do with them (and I’m working on something that I hope will be available to the public in the next few months that will more than prove this… err, assuming I can actually pull off my rather lofty goals!)

So, the next time you’re starting a new application and trying to decide what approach to take, think to yourself: “what is Struts doing for me?” Even moreseo, ask yourself: “is the architecture <insert framework here> push me towards really the best approach?". And regardless of those answers, do a quick proof-of-concept using what I’ve discussed here today and make up your own mind. And if you DON’T agree my approach is better, write back and let me know why. I’m listening.

So, I just finished watching The Lost Book of Nostradamus. It was frightening, as most of those “this is how the world is going to end” shows are. You know, I remember being scared shitless watching Alien as a young child, but as an adult with kids of my own, it’s these types of shows that scare me far more.

But, here’s the thing… after it was over and I thought it through a bit, I realized that it doesn’t scare me in the least. It can’t because I don’t believe in prophecy.

If you’ve known me for a while, that statement is a bit of a shock to you.

It was to me too!

You see, I’ve historically been a believer in things mystic, from aliens to prophecies and the like. I still do believe there is something else out there that we don’t quite grasp yet, but I don’t get more specific than that any more.

But prophecies about the end of the world? Nah. And it boils down to a simple belief, and I think you need to ask yourself this question to see where you stand…

Do you believe that you have free will or not? It’s that simple.

You see, if you, as I do, believe that we have free will, that we make choices and face the consequences, or bask in the rewards, than the idea of someone telling you what WILL happen next week is ridiculous. They are two totally contrary beliefs. Either it’s “No fate but what we make", as Sarah Connor said, or the world ends in 2012 as the Mayans said. For me, I go with the hot chick on this one (well, hot in the first Terminator, pretty much down-hill after that).

I’m not a particularly religious person, but I think if there is a God out there, I don’t figure he dropped us here and then gave us no say in what happens to us. Nope, I don’t buy that. What would be the point of heaven and hell then anyway? No, we live our lives, we shape the world together by our words and deeds, and however it turns out is on us, and none of it is set in stone. That’s what I believe.

So, while Nostradamus may make for a good scary story on Halloween night on one level, on another it’s total rubbish, and has to be, otherwise you don’t believe in free will the way I figure it.

But how’s this for proving my point: *YOU* get to decide whether you believe in free will or not! Hell, just by making that decision, regardless of your answer, you’ve already proven the conjecture!

Metaphysics kicks ass, doesn’t it?!?

So, this past Saturday my son and I entered a Guitar Hero tournament at the local Game Crazy. It was a blast. Until the end. You see, it was father vs. son in the final match… and I came out on the losing end! Yes, got my butt kicked by a 7-year old. Actually, twice… I faced him two matches before and he beat me, but it was double-elimination, so I won the next match, and then he and I hooked up in the finals. Wasn’t even close frankly, which is the worst part. Then again, I was only one of a bunch of people who got destroyed by a 7-year old, so I can’t feel *too* bad about it. Of course I’m proud of him, but I also reminded him of who’s in charge of his college fund (to which he replied “what’s college?", so that threat unfortunately didn’t work out).

Anyway… last week I attended The Ajax Experience in Boston. I actually got to co-host the Hands-On DWR session with Joe Walker, who graciously asked me to share the stage with him (thanks Joe, next time we’ll be more rehearsed, I promise!). It was the first bit of public speaking I’ve done in a number of years, so it was fun. I actually wasn’t nervous, which I thought I would be, so that bodes well because I’m tentatively scheduled to have a few speaking engagements in the coming months.

The conference was good overall. I learned a few things here and there, but mostly I got validation on a lot of things that I wasn’t totally sure I was right about. For instance, there was a general concensus that CSS-based layouts are a bust at this point. And here I thought I was way wrong for still favoring tables. That’s not to say everyone doesn’t *want* to do CSS-based layouts, I certainly do, just that right now, with the current state of browsers, it’s more trouble than it’s worth in many cases.

I got to meet and spend some good time with Ted Husted and Ian Roughley, both great guys, and Joe Walker of course. I also said hello to Alex Russell of Dojo fame and John Resig from the jQuery team. I didn’t get to talk to either of them in any depth though unfortunately.

A few people recognized my name from my books, and a handful even asked for autographs. Which just weirds me out frankly… if you ever meet me and want an autograph, that’s perfectly fine, I don’t mind, but it still seems so odd that anyone would want *me* to sign a book… and I’m not very good at it, I know it! I never have a clue what to write… I usually try and think of something witty, but I’m sure most of the time I fail. But it seems like I should do something more than just scribble my signature, you know? And in the end, I just can’t get over the fact that anyone wants me to write anything in the first place. I mean, who the hell am I after all?!? I’m not exactly Elvis, you know?!?

I have a few thoughts that should make for some decent blog posts that came out of the conference, so gimme a few days to compose a few (somewhat) rational thoughts and I’ll post some stuff. I’ve got quite a backlog of topics I want to write about besides, so there’s no lack of topics here

FYI, if you ever decide to get a hotel outside Boston, I’d suggest not picking the Wyndham in Billerica. The hotel itself was decent, no major complaints really, but there isn’t jack s**t for miles around. It’s truly in the middle of nowhere. I had to drive about 5 miles before I found any stores, and then they were little rinky-dink places, and a K-Mart that made me think I was in the town from Deliverance. I did see a bit more about 10 miles up route 3 (I think it was 3, I may be wrong about that), but in the dark with a GPS unit that didn’t want to work right half the time, I didn’t want to risk it. One good point: room service twice gave me a really good steak dinner, so at least there’s that.

…then now is your chance! Last night, Michael Kimsal of WebDevRadio (http://webdevradio.com) interviewed me. Why he wanted to do that we may never know, but he did, and me, never being one to avoid any situation where I can make a total fool of myself, agreed.

I plug my books, I talk about Java Web Parts and even DataVision a bit… I give my “insights", such as they are, about modern web development… I touch on things like debugging, why AJAX has now become an accepted practice, why Javascript is no longer viewed with *quite* the same distain it used to be… we talk a bit about GWT, about Flex and about various libraries like Dojo, Mochikit, YUI and so forth. I discuss some of the work I’ve done lately in terms of RIA development, and I even give some hints about something I’ve been wanting to do, and designing off and on for some time. I even touch on the Boston/Cleveland playoff game from last night (I am now, by the way, officially rooting for the Indians because I really want to see them against Colorado, I think that will be a phenomenally good series, and since my Mets screwed themselves and their fans a month or so ago, that’s about all I have left to hope for as a Baseball fan).

All the while I meander from topic to topic while Michael tries to reel me in! But like a large-mouth bass, it’s not as easy as it seems it should be… it was fun to do though, and I think Michael enjoyed what I think he’d agree was a bit of a change of pace for him.

And plus, I’m *relatively* sure I didn’t say anything that I really regret a day later, which is always a plus! So check it out if you dare, but I suggest having some aspirin handy as my microphone was clearly too close to my mouth and the audio (which Michael says isn’t as bad as some other cases he’s had) is a little distorted in spots.