Author Archive

If you are a developer, I have one question for you: When was the last time you had fun?
Well, that’s all about to change!

Get ready for the newest rage in development communities around the world, it’s called FOP – and it’s all about fun!

Fun Oriented Programming reinvigorates the ho-hum of development by encouraging you and your team members to choose names which are fun to type and read. These names aren’t simply focused on your variable names, FOP encourages you to think creatively about the names of your classes, methods, members, anything!

The idea of FOP came to me one day when I was planning out the implementation of code that would time-release content on predefined dates. Right away, my thoughts centered around a class named something like “TimedContent” having members similar to “StartTime” and “EndTime”.
This solution is two things: Sensible and BORING!

Wouldn’t it be much more fun to use something like “TimeMachine”, “IsInvented” and “DestryosTheEarth”? Yea, I think so.

You may be thinking “That’s stupid, who will remember those names?!” To that, I have two responses.
First, give it a try, you may be surprised how much this increases your recollection.
Second, why do you think they built IntelliSense, duh?

There are some key advantages to using this new, super fun coding technique. Some of which are as follows.

* encorages code reviews by team members
* makes daily standup “more fun”
* keeps creative juices flowing
* builds your comedic skills

Do you have ideas to re energize your job with new found fun? Post your ideas here in the comments.

Disclaimer: This post is entirely meant in jest. Please do not choose random fun names over contextually valid names – or you will likely be using those new found comedic skills as a stand up comedian.

Happy Working!

Imagine there was a technology that could cripple your site analytics, clutter your SEO, compound your development effort, complicate your view code and aggravate a portion of your site’s visitors. Would you implement this technology on your site? Of course not. But guess what… you probably already have. It’s called AJAX, and everybody’s doing it.

Here’s a little secret, though, that I’ve come to realize over the past few months. AJAX itself isn’t to blame for any of these problems. The way we are taught to implement AJAX is to blame, and it all started with the Nowhere Link.

The Problem

The way most of us have learned to implement AJAX is to first create a link that goes nowhere, attach some Javascript to start the AJAX call, and then conjure up some more Javascript to process the AJAX response and manipulate the page accordingly. Just in that first step, creating a link that goes nowhere, we have introduced 4 of the 5 problems of AJAX:

1. We now have a link that directs users to content that Search Engines cannot follow. It’s kinda like eating empty calories, what’s the point?
2. We have content that users are accessing that has no URL associated with it, rendering the event generally untraceable by the site’s analytics engine. The diligent developer would insert a manual call to register the event represented by some imaginary URL. This has two problems, first it’s manual, second it’s imaginary. Somewhere else on the site could very well use another imaginary URL to represent the same data request, splitting your analytics.
3. Non-Javascript users and, more importantly to me, users who make shameless use of middle-click-tabbed-browsing now have reduced or no access to that content. I know I’m tired of middle clicking on a link only to find a blank page in my tabs list.
4. When the AJAX call doesn’t work the first time, or it breaks later on, we have no standard means to debug the situation. With custom Javascript handlers firing asynchronously and complex DOM manipulating functions chained together and no standardized AJAX response structure, we typically resort to very tedious and archaic debugging techniques consisting of alerts and console.logs (we love you Firebug!)

Lastly, all of this complex functionality that is custom written for each AJAX call ends up cluttering our view code or adding HTTP requests for the client to download external scripts before the page can be used, neither of which are desireable.

The Solution

“To take a step forward, sometimes you must first take a step back.” Amazing how that simple, profound statement seems to hold true no matter what you’re talking about. Not surprisingly, it holds the key to solving this AJAX dilemma too. Solving this problem starts with going back in time, before the wonderful days of AJAX, and asking yourself what that link would have done back then. The answer is probably something similar to “It would have sent a request to the server and displayed a page that looks exactly like this one, only with this small section added/changed/removed.” Build that first.

Now, guess what? You have a link that search engines can follow, you have a URL that can be tracked in analytics, you have a non-javascript fallback, you have the full power of your development environment to debug problems, and you also have the cleanest structure of view code you decided to implement. All you’re missing is the AJAX.

Now pretend that you have a generic lightweight javascript tool that allows you to intercept the click of your link, stop the default page refresh, send the very same request to the server with a simple header set to tell the server “Hey! This is AJAX,” track that call in your analytics package, and put the results somewhere. Then you could process the request on the server exactly like you already do, only send back the pertinent area without all the duplicated stuff.

Now you’ve added AJAX, with little to no change in your view code, just a simple logic addition to your controller to switch a view, or swap a layout when the request is AJAX. Finally, you now have AJAX content with none of the evils of AJAX!

You may find my explanation above to seem a little too simplistic to tackle the insane complexity of your amazing AJAX interactions. I challenge you to think about it a bit, you may find, as I have, that the beautiful simplicity of this approach leads to beautifully simple AJAX implementations. There are also numerous possibilities that this model opens up, such as passing more than one view element back from the server, overlaying a “processing” pane on the target element, preloading AJAX responses for faster response, and many more.

Here at Engauge, we have developed such a tool on top of the lightweight jQuery library. Implementing this model in real-life development has been both fun and challenging, as sometimes the simple solution is a tad harder to see when looking at a problem. So far, this model has served me well in tackling my AJAX needs, and it has definately helped me to abandon the old days of the Nowhere Link.

Ok, here it comes, any second now. It’s gonna be really cool … wait…hey… where are you going?

In today’s world of jQuery, Prototype and Mootools, the possibilities for rich user interaction expands by the day. You want that oh-so-nineties of a paginated search results to fade in and out? Done. You want that dusty old file input to be styled and totally awesome? No Problem.

First we’ll choose a javascript library, doesn’t really matter which one. Then we’ll put some placeholder on the page, maybe an empty div or, if we’re feeling really smart, we’ll put a fallback element for the non-Javascript crowd to use (do they still exist?). Next we’ll tag the placeholder with an id or class, your choice. Now all we have to do is write this really awesome Javascript initialization function that finds this element blows it away and replaces it with exactly one bazillion tightly packed elements with event listeners linked so tightly it looks like spaghetti. Beautiful, tasty DOM spaghetti. All wrapped up in Javascript too – so we never have to see it again. Finally, we’ll slap that initialization function onto body load and sit back and wonder at our creation.

Now we’re feeling pretty good right? We’ve got this new interaction that we’ve always wanted, and we’ve got a non-Javascript fallback for all 5 users that have Javascript turned off. Let’s view our page and gloat. Oh, what was that? The page loaded, I had no widget then a few seconds later, I have a widget. That was annoying. But don’t fret, let’s throw our initialization function in earlier. Let’s trigger it after the DOM is ready, but before the page is rendered.

Ah, that’s better. Now instead of seeing an ugly broken page first, I just stare at an entirely blank screen for a second or two. What’s going on? I just want the page to load like it did before but with this new (really awesome!) widget in place. Is that so hard?

Well, lets look at what is really going on here. (Disclaimer: I am no browser developer, so please give me a little leeway here in my explanation)

1. The browser downloads the requested page,
2. It parses the page to find assets it should download,
3. It fires off threads (usually only 2 at a time) to download all the CSS, Javascript and Image files,
4. Simultaneously, it is constructing the DOM and executing any inline Javascript,
5. Once the Javascript files are downloaded, it executes them,
6. Once all the files are downloaded and Javascript is loaded it renders the page,

… All that in milliseconds – pretty amazing huh?

Now, to implement our widget, let’s inject a step 5.5. As the library loads, it will fire off a piece of code to CONTINUOUSLY ask the browser “You done yet? You done yet? …. ” Finally the browser says “Yes, I’m done.” Now we’ll put in one more little tiny itsy bitsy step, 5.75, of creating one bazillion DOM elements all of which now need CSS styling and event listeners.

I’m sure the browser developers didn’t really try to optimize the other 6 steps in order to squeeze every tenth of a millisecond out of the page rendering time. I’m sure there’s room in there for my created-in-a-day Javascript to execute and have everything ready in time. … Really?

So what am I saying? Surely I’m saying that its a tradeoff – performance for features right? Absolutely Not! You just need to step back, think about the problem, and think about what needs to happen when and most of all, realize that using a Javascript library doesn’t mean that your old-school Javascript ways are outdated.

Start by taking that DOM spaghetti and throwing it directly there in your page. Go ahead, do it, it’ll feel dirty. Ok, now it’s not hidden behind Javascript, so clean that crap up. No really, it’s disgusting. Now throw your non-Javascript fallback in there and wrap it up in a container (hey, maybe even that same placeholder you used eariler). You may end up with something like this:

<div class="awesomeWidget">
  .. fallback elements ..
  <div class="widget" style="display:none">
	.. spaghetti ..
  </div>
</div>

See what we did? Now Javascript doesn’t have to create our spaghetti. It’s right there for all the world to see immediately. As soon as we let them. Remember the days of inline scripts and getElementById? They’re back!

<div class="awesomeWidget" id="awesomeWidget1">
  .. fallback elements ..
  <div class="widget" style="display:none" id="widget1">
	.. spaghetti ..
  </div>
</div>
<script type="text/javascript">
  document.getElementById('awesomeWidget1').className += " processed";
  document.getElementById('widget1').style.display = "block";
</script>

Now this is cake for the browser. It creates the DOM adds a class name and sets a style – all in time for page render. As an added bonus, we still have our non-Javascript fallback and enough CSS hooks to setup fallback styles as needed.

“But wait a second,” you say, “what about all the event listeners that make my widget work? I’m not writing all that stuff inline. I have a library and I want to use it!” Now I say, “Let your library skills loose!”. Now’s the time for the library to take over. You’ve rendered the page, the user doesn’t know that the widget doesn’t actually work yet – they’re still marvelling at it’s beauty. A second later, all the events are hooked up and your widget is ready to roll. You’re so awesome.