ntschutta.com

Ryan and I are proud to announce our second collaboration, Pro Ajax and Java Frameworks! We just got our author copies so I expect it will be available shortly from the major retailers. This book largely picks up where Foundations ends: after a general Ajax overview, we cover some common tools (including my new favorite Firebug) then we discuss a number of frameworks (Dojo, Prototype, script.aculo.us, DWR, etc). Once we’ve covered the client side goodness, we walk readers through integrating Ajax into common Java frameworks including Struts, JSF, Tapestry, and Spring.

We’ve been thrilled with how well received Foundations has been and we hope people learn as much from reading Pro Ajax as we did writing it!

On Monday, I posted about the cool promotion on select Apress and Friend of Ed books at Barnes and Noble. Well, I was just informed that, along with the great discount, you can win an iPod nano! The details are here but the gist is this: take your picture at B&N in front of the display, send the pic in and you’re entered in a drawing to win a 1 gig nano. Remember, the cool kids will be reading Foundations of Ajax… Good luck!

We’ve all been there. You get that frantic call from a customer - somehow a bug got through your intensive suite of automated tests and your kick butt QA team (must have been that dang intern). Of course the problem has to be fixed RIGHT NOW so they can get that much needed report to that ever so important vice president allowing him to make *very big* decisions. You dutifully dig in and, despite that queasy feeling, you put in a quick and dirty little fix. I know, you’re going to go back in and fix it just as soon as you can…but then the next day, just as you’re sitting down to put in the proper patch, wham, the project manager ambushes you from behind the plastic ficus tree. Can you say “cat like quickness?”

The PM has an urgent request (aren’t they all?) - someone very important is going to be in the office tomorrow and needs a demo of that snazzy new feature she promised you’d add to the system (you know, the one you said was nearly impossible to do). Don’t worry about implementation, just make it *look* like it works! If you’re like most of the people I’ve worked with, you swallow hard and get to it pounding out something that functions…mostly. Sure, you had to cut some corners, but it made the PM happy and, well, it is for an important customer. Tomorrow though, you’re going to refactor the quick fix and get the new feature squared away.

Alas the next day brings yet another crisis and your best laid plans are cast asunder. Day after day, we are often asked to put in quick and dirty fixes. Can it be any different? I mean we can’t possibly do quick and clean could we? Well, Obie Fernandez thinks there’s a way: Ruby and its close personal friend Rails. In a recent post about enterprise adoption (essentially expanding on his talk at RailsConf) Obie offers some great advice on how to pitch Rails to the enterprise. He hits it on the head when he says:

The biggest challenge, in my opinion, is that lots of teams doing J2EE have people are used to thinking that quick == dirty. Martin’s keynote had tons of good information for anyone wanting to evangelize Ruby as enabling quick and clean solutions, and well-written Rails applications are all about quick and clean.

Amen. I’ve seen a ton of quick and dirty code in my day and much as it makes my stomach turn, I can empathize with the developer that did it (well, to a point). But it doesn’t have to be that way! As Dave Thomas said, it’s sure slick when you work with glue that doesn’t set! Much as I’d like to think this would be a compelling enough argument to woo even the crustiest of developers, I think Obie nails the underlying problem:

I think the hardest thing about convincing hardcore J2EE devs would be that a lot of those programmers actually get off on the complexity and building of framework upon framework. Most people I know doing Java are not application developers! They are programmers and they like working on plumbing!

There’s not much in the way of plumbing code in a Rails app; it feels to me like virtually every line of code is about delivering business value. There aren’t any little black boxes where people can invent massive subsystems that are little more than their personal playpen. With the rapid feedback loops, it’s darn hard to venture off on some neat little complexity hunt just to soothe your need to utilize that new library. Or put more succinctly:

J2EE teams tend to be larger, due to the extra complexity. Big projects usually give individual members freedom to perform below their abilities and/or skate by working on pet projects and miscellaneous bullshit that does not add business value.

It’s from these folks that Rails backers will hear things like “Rails doesn’t scale” or “Rails isn’t ready for the enterprise” or even “Rails is inappropriate“.

Maybe Rails will never truly be enterprise - perhaps that’s a good thing. The contrarian nature of Rails is one of its greatest strengths and I hope it never loses that. Rails isn’t right for every application (of course we don’t really know the boundaries yet) but it sure fits a big niche. Observant organizations will hop on board, change their thinking and create some amazing applications. Those that are dominated by a certain type of developer will invent reasons why Rails won’t work and wallow in the complexity of their chosen path. Chances are, they’ll never get to quick and clean.

Just before the 4th, Ryan and sat down for a chat with Nem and the rest of the crew at Geek Muse - the results are available on iTunes, from their site or as a plain MP3. Be aware, like ZeroLogic, this one carries the Explicit tag… For the URLs and notes, click here.

My wife doesn’t think it sounds like me but the audio is great! Ryan and I had a great time (many thanks Nem, if you ever need another voice, shout!) - enjoy! Oh, and Nem, thanks for leaving in the part about cream cheese

One of the hard and fast rules of web design has long been “thou shall develop for a screen resolution of 800×600.” Of course with monitors getting larger and larger (heck, this aging PowerBook runs at 1280×854) this maxim might be past it’s prime. So what’s a designer to do? Kyle Neath of Warpspire takes a look at this question in his post Jumping Ship. Basically, Kyle channels Kathy Sierra (check out her Safe is risky, risky is safe) and, well, Nathaniel Talbott’s keynote from RailsConf (check ScribeMedia for a link to his talk). While designing for the lowest common denominator can attract a large pool of customers, taking some risks opens you up to a batch of new ones.

I think Kyle hit’s it on the head when he says

“Making your users feel special is worth more than any advertisement could possibly cost.”

Sure, you can play it safe, follow the well beaten path, but will that inspire The Nod? Of course it takes courage - it’s not easy to try something different; while no one brags about their Camry, Toyota sells a ton of them.

So what is a designer to do? I’m with Kyle, give it a go! If no one pushes the boundaries, we don’t advance the field…

I’m excited to announce a fantastic promotion from Barnes and Noble - from today until the 9th of August, you can get a heck of a deal (a 40% discount!) on Foundations of Ajax and a host of other great books from Apress. The promotional price is good online (via this link) and in physical stores. So, if you haven’t picked up a copy of our book, now you really don’t have an excuse!

Just wanted to point out that the RailsConf keynotes are starting to appear on ScribeMedia. So far it’s just Dave Thomas and Martin Fowler but I suspect the others will follow along shortly. All the talks were great but regardless of your interest in Rails I recommend you listen to Martin, Paul Graham, and Nathaniel Talbott. I first saw this on Fowler’s blog.

Update: DHH’s keynote is now available.

Update: Paul Graham’s keynote is now available - go listen…right now.

Update: The Rails Core panel is now available.

By now, my humble readers (pretty sure I’m up to five or six now) should know I have a thing for quotes and as you might expect, RailsConf provided it’s share of notable quips! I should point out that I’m not a reporter and I didn’t record any of the sessions so I’m mostly paraphrasing (if I’ve misquoted someone, I’ll happily change it, just let me know). Anyway, here are my favorite lines from the weekend.

When discussing REST vs. SOAP and also the buzz behind Rails itself Dave Thomas said:

“There’s a move afoot in our industry to throw away all of the crap.”

When discussing Ajax, Dave defined it as “making browsers suck less” following with:

“The browser is just a 3270 terminal that can display porn.”

Paul Graham is one of my favorite writers - when he posts something new, I pretty much drop everything, print it out, and read it. The following all belong to him. Before diving into his keynote, Paul prepared us for what was about to come:

“I’m going to contradict both the Old Testament and Yoda.”

His talk itself provided quite a number of quotable lines including…

“Better to say something obliquely, then the people that would be offended won’t understand it.”

and

“Don’t learn things from people that are bad at them.”

Paul was followed up by Why the Luck Stiff and anyone that has seen him live knows how entertaining he is. While I can’t do justice to nearly anything he said during his show, I loved this line (if i recall properly, this caused a standing O from Glenn Vanderburg):

“Put your best practices away.”

Obviously, there were other memorable lines, but these were the ones I actually caught in my notes…

I must be on a bit of an Andy Hunt jag here… A couple of weeks ago he posted this link to Only the Adaptable Will Survive Change. In some organizations, change is like the proverbial third rail - touch it and someone is going to get hurt. Some people think change somehow invalidates what was done before but that’s just not true; making adjustments is a healthy activity. Anyway, there are a few great quotes from the article that I’d like to call out:

developing software is such a complex activity, anything substantive that you leave until later won’t happen, won’t happen well, or will grow worse and fester until it becomes unmanageable. A certain kind of friction increases, and things get harder to fix and harder to change. As with any friction, the only way to fight it effectively is to continually inject a little energy into the system.

How many projects have started with the ideal of testing only to have management say “we don’t have time” shortly after the project gets underway? Or my favorite “just hack that change in, we’ll go back and clean it up after that important demo.” Yeah right. Technical debt accumulates - you either pay it off over time or eventually you are forced to refinance. It’s very tempting to just let it ride, especially if things seem to be working well, but eventually you’re going to have to send a check to the bank (and the dollar amount only gets larger). We can’t let the enormity of the problems intimidate us either, a little bit each day and we’ll get to where we need to be. If we focus on the size of the problem instead of just doing something we’ll never accomplish anything. Agile methods fundamentally get this idea. Tests are written everyday, code is refactored everyday, customers are shaping the product everyday. To use an analogy, it’s a heck of a lot easier to maintain a healthy weight than it is to lose 30 pounds.

Tempting as it may be for some, it’s important to realize that agile isn’t the same as crisis management.

Crisis management occurs when problems are left to fester until they become so large that you have to drop everything else you’re doing to respond to the crisis immediately. This causes secondary crises, so now you have a vicious cycle of never-ending crisis and panic. That’s precisely what you want to avoid by adopting an agile approach.

I’ve been in “fire fighting” style organizations and it really isn’t much fun. You never get a chance to act strategically, you’re forced into tactical solutions. The pressure to just “get any fix in” causes the code to deteriorate meaning the next change will be even harder than it has to be. Quick and dirty becomes the mantra and while some congratulate themselves on being responsive, most everyone realizes there is a price to be paid for that speed.

Change isn’t limited to code though - everything we do needs to evolve as well.

Agile development recognizes the importance of pragmatism, and seeks to adjust everything—the schedule, the design, the features—based on what is really happening. It’s about facing reality and dealing with it, not hiding behind an IDE, PowerPoint presentation or a Gantt chart.

Just because we did something a certain way two years ago doesn’t mean we should still do it that way today. Heck, when Java first came out, we used text editors and the command line, today we use full featured IDEs. That doesn’t mean we were somehow *wrong* 10 years ago. Don’t forget, for thousands of years we thought the world was flat too.

As hard as it can be to change, not doing so is a recipe for disaster.

Sticking to any plan or technique that is no longer appropriate is a guaranteed way to fail. Both the dodo bird and the buggy whip manufacturers learned this lesson the hard way.

It’s important to realize that modifying your approach isn’t an admission of failure - in reality it’s the mature reaction to the world around you. It may not be easy, but the consequences of inaction are far worse than any pain the change may cause.

I’ve seen this visual depiction of software engineering before, but Andy Hunt recently posted a link to it. If you haven’t seen this yet, take a look - it hits the nail on the proverbial head!