ntschutta.com

I’ll admit, when I first read about Google and Sun’s big announcement (a bit late I might add - we were in Madrid at the time) I couldn’t help but think: what would the world be like if I could get at my documents and spreadsheets from anywhere? While in Spain, we used a few different websites to help us get around and we kept in regular contact with the family back here in Minnie via my gmail account. It was only during our second week, when we didn’t have free Internet access in our hotel, that I realized how cutoff we became without that connection. Of course being out of touch isn’t always a bad thing - with the already Shrinking American Vacation, I have to wonder, is it a good thing that someday soon I might be able to get at any document? What demands might an employer make if we really could check those numbers while on a trip? I know, many people take laptops or at least a Crackberry with them but still - what if Word really was accessible anywhere?

Frankly some of this falls into the Web 2.0 meme what with the mashups and all. I hate to disagree with Joel Spolsky’s piece Architecture Astronauts Are Back but I do think there is something to this Web 2.0 thing. Sure, it’d be nice to have a more concrete definition but Tim O’Reilly has his What is Web 2.0 and recently Paul Graham has gotten in on the action with his Web 2.0 post.

Anyway, something’s happening here, I’m certainly not going to hazard guess as to what, but when you see the tremendous success of 37signals with fantastic tools like Basecamp and Salesforce.com with their CRM solution, you’ve got to wonder what is the future of the massive in-house IT departments many companies employee to keep their systems running? Sure some (heck maybe most) of that work is being outsourced to the accentures of the world but just think of what this idea means to small and medium sized businesses. They now have access to affordable solutions. My family used to own a hardware store - we certainly couldn’t have justified an SAP installation but maybe we could have taken advantage of other options.

With all that in mind, today one of the major issues with this approach became blatantly clear to me. Around lunch time or so, our network went down. No email, no voicemail, no access to our servers, no access to the Internet…nothing. For about an hour or so, we were effectively shutdown. Some meetings were still going on and a lot of people just went to lunch but still, that cost us some money. I don’t know exactly what the problem was, but it involved our Internet provider so I doubt it was an isolated incident. Luckily for us, the problem was fixed quickly but what if it had taken longer? What if all our documents were on a website somewhere?

Don’t get me wrong, I’m not arguing against the hosted model - in fact I think it makes a ton of sense for a lot of businesses. However, in the brief time without a connection I realized how helpless we were without it. It’s quite remarkable to think that just a few years ago, many of us thought a 56k modem was out of this world…now our T1 line goes down and we get the shakes.

If you want to see a cool Ajax based contact manager that takes advantage of ColdFusionMX and SQL Server (once again proving that Ajax is completely agnostic about the server), head on over to this example from John Theis. John was kind enough to point out a couple of typos in our sample code and has given us some great feedback (seriously, we listen to this stuff). Thanks John - cool demo! Oh yeah and we’re glad you enjoyed Foundations of Ajax!

This past weekend I did something I’ve never done before. Now, before your dirty little mind wanders astray, I assure you it was nothing salacious - in fact I was with my in-laws the entire time. You see, I finally witnessed live stand-up comedy. Sure, I’ve been to my share of improv at places like Brave New Workshop but I’d only witnessed stand up via late night TV and cable.

But Saturday, that all changed - we wandered down to the acme comedy co. located in the historic Warehouse District in downtown Minneapolis to see Derek Hughes. My father-in-law actually used to hire Derek (he’s a local boy now living in LA) to do corporate events back when he worked for the former Norwest Bank. Anyway, we had a great time - all the comedians were hilarious! The atmosphere was fantastic (gotta love that smoking ban) and they even served my favorite beverage: 1919 root beer. Besides having a blast, I learned a few things, things that apply in a more general way than I would have imagined.

1. Some material may not be suitable for all audiences. The show we were at was clearly intended for mature audiences and while few of us regularly curse during our day jobs or pull a deck of cards from our underpants, you have to be aware of your surroundings. Now, I’m not just talking about political correctness and promoting a harassment free work environment - we all know there are some topics that you just don’t bring up to around certain folks. While everyone may see that the emperor isn’t wearing any clothes, it’s rare that the emperor has any interest in being enlightened on the topic.
2. Some material just won’t work. Some of this is contextual - jokes about North Dakota probably don’t work so well in, say, Orlando. This point goes hand in hand with the previous one however, you have to realize that some approaches just won’t fly in your organization. Take my company. We work on one of the largest Java applications on the planet - how receptive do you think we are to, say, rewriting the whole app in C#? Now in the comedy world, maybe that joke bombs tonight but just kills tomorrow - sometimes that same thing happens in the business world. Maybe that email about how your team should adopt agile methods would be better received next week, when your manager isn’t stressed out about budgets or that big customer bug. That said, you can’t always change your employer but you can usually get a new one.
3. Hecklers are inevitable. If you ever decide to, say, write a book or you give a talk or two for a local user group, you come to realize that hecklers are inevitable. While you probably won’t have to put up with drunken idiots, no matter how good you are, no matter how fantastic your book or article is - someone, somewhere will think you are full of it. Sometimes they will provide actual constructive criticism and if you’re lucky they will at least be informed remarks (as in they’ve actually read your work) but more often than not you will get empty comments. A darkened room (or the anonymity of the web) provide ample coverage for those that can’t create on their own. As Dale Carnegie put it:
   

   Any fool can criticize, condemn, and complain - and most fools do.

   Don’t take it personally - grow from it but don’t let it get you down. Now if even your parents aren’t so sure about your ideas…

4. It takes a vast amount of pluck to get up on stage. Frankly, this is a corollary to the previous entry. I have a tremendous amount of respect for those that have the guts to display their work to the public - you risk revealing the limits of your abilities and few of us willingly admit to being less than perfect. It’s very easy to sit on the sidelines and point out where the strong have stumbled but to actually put on a pair of cleats and compete - that takes courage.
5. Engage your audience. Of course this isn’t anything new to those of you that track Kathy Sierra’s work but in case you still think it’s about you, well, it isn’t. Sure, I love to look smart but your audience is selfish - they want to have a good time (or learn something). Deliver on that and they will tell everyone they know how fantastic you are. Try to convince them you are the greatest thing since sliced bread and you will fail. To quote Dale Carnegie again:
   

   You can make more friends in two months by becoming interested in other people than you can in two years by trying to get other people interested in you.

   Comedians don’t hide behind obtuse PowerPoint slides - if they did, they’d be out of work pretty fast. Next time you have a presentation keep that in mind.

So there you have it - a simple night out turned into a learning experience (there’s a lesson in there somewhere I think). While I certainly expected to laugh, I didn’t imagine I’d see so many connections between the comedian’s job and my own. But now that I have, I don’t think I’ll ever look at a stand-up the same again.

I’m pleased to announce that I will be speaking about Ajax at the upcoming Code Freeze at the University of Minnesota. Looking at the local luminaries on the schedule, I’m amazed to find myself in their midsts.

It’s a chance to see a great slate of speakers including James Rumbaugh! The cost is very reasonable at $70 ($50 if you are a student or an MSSE alum) which includes all the talks, breakfast, lunch, snacks, and the program material. Here’s the email that’s going around:

The first annual Code Freeze Symposium will be held on Friday January 13, 2006, presented by the University of Minnesota Software Engineering Center. This is a chance to meet your colleagues and share experiences and best practices in our profession. The theme this year will be “Enterprise Architecture and Development.” Details and registration are now available at http://www.umsec.umn.edu/code_freeze/index.html

We will have a full day of talks and discussions focused on practical application of Software Engineering to real-life enterprise architecture and development problems. Our keynote speakers will be James Rumbaugh, one of the leading software development methodologists in the world, and Bran Selic, who has contributed extensively to the definition of Model Driven Development (MDD) methods and tools.

Other speakers this year include David Hussman of SGF, Jim Pichler of Digital River, Mike Calvo of Citronella Software, Don Monk of General Mills, Nate Schutta of PTC, and Scott Costello of Unisys. See the symposium program for details.

The symposium will be held in the EE/CS building on the University of Minnesota East Bank campus, from 8:30-17:00, with registration and breakfast starting at 8:00. The cost of the program is $70, which covers the program, continental breakfast, snacks, and materials. If you register by 9 January, we’ll include free parking in the Washington Avenue Ramp. Students and alumni of the University’s Master of Science in Software Engineering program can pay a discounted price of $50. For more information, please contact Kim Kramer at 612-625-1381 or kkramer at cs dot umn dot edu.

We hope to see you there.

Jamshid Vayghan, Symposium Chair
John Collins, Program Chair
University of Minnesota Software Engineering Center

I’m really looking forward to the talk and if you’re in the Twin Cities area, I hope to see you there!

We who cut mere stones must always be envisioning cathedrals.
-Quarry worker’s creed

That quote comes straight out of one of my favorite books: The Pragmatic Programmer. Ever since I stumbled on this book four plus years ago I have been an evangelist for its teachings. I read the author’s blogs (PragDave, and Andy’s Blog) religiously and I keep hoping the Rails Studio will make a detour to the Midwest.

Anyway, one of my absolute favorite pearls of wisdom from Pragmatic is “Don’t Live with Broken Windows.” Basically, a car in a seedy part of town will be left untouched until a single window is broken - then it’ll be stripped in a matter of hours. For more on the theory, check out the Wikipedia entry: Fixing Broken Windows.

This theory was brought to my attention today in a code review. Not that the code was bad (though truthfully, I don’t know enough about the business yet to be able to do more than “that variable name isn’t very descriptive”) but it had some dead code in it. I’ll admit, there was a time (a brief while) when I didn’t mind having lines and lines of commented out code but not anymore. With version control (you do use version control right?) there just aren’t any good reasons to keep unused code around. All you’re doing is making the code harder to read - and most of us prefer writing code anyway! A simple thing, sure, but next time you’re editing some source and you run into a chunk of code that the compiler is ignoring do yourself and everyone else in your shop a favor and burry that code for good. You can always look back at the history in your version control…

Update: I knew there was something else that made me think of this topic recently. Check out Anatomy of Ugly: How Good Code Goes Bad. This is what happens when you read way too many blogs and newsletters (or so my wife says).

There seem to be a set of questions that any software developer worth his salt asks about any new technology: How are patterns involved? Will it help me get out of this crappy job? Is there a conference around February in Tahiti? Sometimes, we even ask questions about scalability.

The other day, I gave a presentation on Ajax at my company. Now, I only had thirty minutes so it’s not like I got into anything deep but we did have some interesting questions. Being surrounded by some really great software engineers, someone was bound to ask “does Ajax scale?” Until recently, scalability was not the most important “ility” in my world - I only had a few users and they only did a few transactions a week. However, on my current application, scale matters. We sell enterprise class software that is key to the businesses that purchase our wares. For us, this is a central question.

So, does Ajax scale? Like any good computer scientist, I’ll rely on my default answer: it depends. If your architecture is solid, you shouldn’t have any issues with scaling - in fact, if your app can scale well horizontally you’ll be just fine. However, a poorly designed system will be brought to its knees. Of course, if your system isn’t designed to scale, it really doesn’t matter what you’re doing on the client side - you will have problems! That said, I’m very interested to see what kind of impact Ajax has on load testing - old assumptions about the number of concurrent users might not hold up when we consider the high number of fine grain calls that Ajax engenders.

Ajax is certainly seeing wide spread adoption - heck, one of my hometown papers, the Star Tribune, has snuck in some hover magic lately. While I think this is a very good thing, I also realize it will lead to an overuse of the technique. I know, this is inevitable (new hammer - everything looks like a nail) but I plead with you: think before you leap. At my company, we are actively looking at Ajax as a performance booster. Being able to essentially “lazily instantiate” parts of our page will make them smaller and changing just a little piece of the DOM will cut down our full page refreshes. Those are our primary focuses. We aren’t going to be rewriting our app as a single page!

Don’t forget, just because the calls are asynchronous doesn’t mean they don’t have a cost. If you start making 30-50 calls on every page where before it was just a few, you might have some issues. I can’t help but think about the early days of EJBs (you remember those, right?) when we had a whole bunch of “get” calls that were all going across the network and we all know what happened as a result of that experience. Could we be too far away from JavaScript Data Transfer Objects?

The Ajaxian boys mentioned granularity in Audible Ajax 6 - it’s around the 17th minute or so. We have to think about the number of calls we are making to our server and try to minimize those. For an interesting look at this, take a look at Scaling Connections for Ajax. So, in a nut shell, yeah, Ajax scales - but that doesn’t mean we should overdo it. If we’re not careful, we will kill our systems - with thousands of tiny little cuts.

Last night Ryan and I spoke about Ajax at the Twin Cities Java User Group. We had a great time - thanks to everyone that braved the cold we hope you’ll take a look at Foundations of Ajax! Jeff Jensen was a great host, we really appreciate the opportunity to present. I felt bad for the book that no one wanted (and no, I won’t tell you which book that was) and for the lucky folks that won our book - enjoy!

Anyway, people asked me to post the slides so here you go. Enjoy!
This PDF - Foundations of Ajax is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.

If you’re following the whole Ajax thing, chances are, you visit Ajaxian on a regular basis - and if you don’t, you really should be. Ben and Dion (and now Rob) are great and they seem to find just about everything interesting that’s happening in the Ajax space. I should also add, they’re really fantastic guys too, if you ever have a chance to see them present, take it!

Back in late August, they launched a podcast. Now, I’ll admit, I was late to this whole iPod thing but I have to tell you, I find podcasts really interesting. Heck, they *almost* make me wish for a Californian style commute so I could actually keep up with all the great podcasts out there. I’m currently “reading” an audiobook and I have to tell you, I find myself gravitating to podcasts…

Anyway, I just wanted to say thanks to Ben and Dion for discussing Taconite (oh and Ben, it’s pronounced like tackle, not taco - though one guy did post something to SourceForge saying Tuesday was Taco Night at his house! No biggie, I suppose only us Minnesooootans would know that one.) The whole podcast is worth listening to but if you just want the dirt on Taconite, its just under 6 minutes into the podcast. They were also kind enough to mention our book, Foundations of Ajax!

Ryan and I are really flattered that you guys find the approach so appealing! And yes, we aren’t big fans of innerHTML - sorry, we’ve just been burned bad. Yeah, I know, XHR isn’t a standard…but it’s better than iframes! Yes, innerHTML makes tables a lot harder and frankly, that’s one of the best uses of Ajax that we’ve found. One of these days I’m going to write about something I built at my former employer called maintainable table - but that’s a story for another night.

I know it’s odd, but we actually tried to stay near the W3C’s Load and Save spec. We actually think someday…maybe…this will actually be implemented. Personally, I think it would really help with overall adoption of Ajax if we could guarantee it would work, as desired, across browsers. Ahh, who am I kidding…that won’t happen anytime soon. Still, we liked a lot of the ideas in there so, rather than invent our own, we just borrowed theirs.

A little latter (around minute 12) in the podcast, Ben made a fantastic point about the hack-ability of Ajax while discussing the jsquery toolkit. I couldn’t agree more - I want to keep an open mind too but I have serious concerns about any application that is opening up their business data like that. While I’m sure there are some excellent uses, this style feels like a nail gun or a circular saw - in the hands of a professional, these tools can do amazing things. However when someone with less skill uses them…people lose fingers.

Thanks again guys, we really appreciate the kind words! By the way, I’m really enjoying Pragmatic Ajax. Like Foundations, Prag Ajax is focussed and very readable. I know some people think a book needs to be 700 pages long to be valuable but in my experience, I rarely finish a book that size. Truth be told, I think small books that get to the point without a lot of extraneous material are far more useful to the reader. I don’t know about you, but I certainly don’t have a ton of free time to read through a book that tries to be all things to all audiences. This is part of why I am so excited about Pragmatic Fridays!

I tell you, this whole beta book idea is just great! This is the second book I’ve purchased this way (yes, I laid out my own money so don’t think I’m biased by a free copy) and I expect to do it more often. Pragmatic Ajax has some great material, heck the chapter on Google Maps is worth the price of admission! I’ve come to expect a lot out of books from the Pragmatic Bookshelf and I can tell you that this book lives up to that reputation. Great work guys!

I’ve been getting this question quite a bit lately - especially as people find out about Foundations of Ajax. Obviously I’m not the first to talk about this but I’ve developed a bit of a stock answer so here goes. Don’t agree with something I’ve said? Let me know!

First things first, Ajax has really lost its acronym status so if you’re tossing around AJAX, you might get some funny looks. That said, you’ll see both versions depending on where you look so don’t sweat it. If anyone asks, AJAX stands for Asynchronous JavaScript and XML. The term itself comes from Jesse James Garrett and his seminal piece Ajax: A New approach to Web Applications. While the software world certainly didn’t need yet another term, Garrett needed someway to succinctly describe “Asynchronous JavaScript+CSS+DOM+XMLHttpRequest.”

Second, Ajax is not a specific thing - it represents a collection of technologies, better yet, think of it as a technique. You might argue that JavaScript and CSS and the DOM are nothing new, so what makes Ajax so special? Notice above that the ‘A’ in Ajax, stands for Asynchronous. Why is that interesting? The standard web interaction is a request/response paradigm. Remember, the Web started with a bunch of researchers sharing their reports and studies - a shopping cart was not part of the original concept. Using Ajaxian techniques, we can create a richer more dynamic user interface by allowing asynchronous communication with the server. This also means we don’t have to refresh the entire page which can significantly improve the user experience.

At this point you might be saying “so what, I’ve done this for years.” Truth be told, none of the technologies that Ajax represents are new - however, the widespread browser support is. Many people (including me) have used iframes to call the server in the background or to submit/repaint just part of the page. I’ll admit, it works fine, but truthfully it’s a hack. Today, thanks to modern browsers allow us to take advantage of a Microsoft invention - the XMLHttpRequest object (XHR for short). XHR provides a simple mechanism that allows us to call the server and tie the response to a callback function. With improved DOM support, we can take data from the server and modify just part of a page.

This means we don’t have to refresh the entire page just to fill in one or two fields. A minor thing maybe, but it really opens up some new possibilities. Like what you might ask? Well, take a look at two of my favorite examples - the browse section of Netflix and Google Maps. With Netflix, just hover over any box cover. A “tool tip” containing a significant amount of information pops up. Go ahead, view the source, the information in the bubble isn’t hiding in the page - it’s requested when you mouse over a specific movie.

What makes Google Maps so special is the scrolling. Want to see what’s off the map? Just use your mouse to drag the map. That’s it. No repaint like Mapquest. John Carroll glosses over this point in his blog on Google Maps and innovation but I really think the drag makes Google Maps so special. And it’s not rocket science! The lads at Ajaxian (Ben Galbraith and Dion Almaer) whipped out a version in less than 2 hours at a conference. Don’t believe me? Check out their piece “Ajax is rocket science”. “Ajax isn’t simple”. Enough already!

In a nutshell, Ajax is a technique that allows us to create richer web applications - applications that are often indistinguishable from their thick client cousins. It certainly won’t end world hunger or even guarantee you’ll make it home in time for dinner, but Ajax will certainly influence what we build over the next few years. We’re only just starting to explore Ajax and what it means but I’m convinced it will ultimately make our web applications more responsive and improve usability.

Java and I have been together now for more than 6 years. After a college fling with C++ and a very brief not-so-torrid affair with COBOL (coming from C++, a few months was enough to make a guy seriously consider the priesthood), I met Java one fine Spring (you know, the season) day back in the late nineties. Sure, maybe I was on the rebound but compared to working storage areas, Java was one sweet lady! Once more I had full blown object support and no silly restrictions on where a comment could go…and of course all the excitement of a fresh new passion.

After the heady first couple of projects, Java and I settled into a nice little routine. We had a very comfortable relationship - I knew her limits and she knew mine. Sure, like anyone, I was a little annoyed when every year or so brought a whole new raft of changes and I couldn’t help but notice she’s added a few kilobytes (OK, megabytes) to her formerly svelte frame. I’m not one to judge and she just smiles saying “it’s just more of me to love.” Or was it learn?

Still, lately I feel like we are starting to grow apart. After all, I’ve spent most of my career “webifying” legacy COBOL applications and while I certainly prefer semicolons to line numbers after a while I started to wonder if maybe grafting a web page onto a relational database wasn’t just a tad too difficult with Java.

Don’t get me wrong, I mean, heck, her support for transactions and threading and whatnot is great - but I find myself largely ignoring so much of the “enterprise” stack. Heck once I even got into an argument with a guy that insisted I wasn’t “doing EE” since my projects were favoring straight JDBC over entity beans. But as I take an objective look at what goes into generating simple HTML representing a basic table with Java, frankly, I had to wonder - isn’t there an easier way? It wasn’t that long ago all those spurned by C were saying Java was so much simpler…

Lately, I’ve been wondering if it’s time for Java and I to talk a little break, you know, get some space. I mean, after all, I’ve been faithful (mostly) for the last six plus years and we’ve had a lot of good times but I can’t stop thinking about that sexy little number across the street. And man, when Ruby gets all dressed up in nine inch Rails…can you say stops traffic?

I guess I shouldn’t be surprised. After all, I’m coming up on the seven year itch.