afongen

No Fluff Just Stuff is in town this weekend and I’m missing it. Sigh. I have to make a more concerted effort to attend this sort of event.

My RSS feed is on Feedburner now, so I am redirecting requests for the RSS there. If you use an aggregator, it should follow the redirect, but you might want to update to the new URL anyway.

Why Feedburner? Two reasons to start:

1. It integrates my del.icio.us links into the feed, which is something I’ve meant to spend ten minutes doing myself but never quite got around to.
2. It creates a pretty version with a style sheet. Something else I’ve meant to spend ten minutes doing but never quite got around to. Story o’ my life.

It will be nice to see some stats on the feed use, too, something I occasionally generate with a series of Perl scripts but don’t follow closely.

“So,” Tim asked, “still down on Java?”

When we had last spoken, I was reading Beyond Java, so that was an understandable question. I’ve had the conversation an awful lot lately and people keep being surprised by whatI say, so I figure it’s about time I write something here to explain my position.

Am I down on Java? Not per se. Java is not a language I generally enjoy working with, but I write web apps for a living. I do not believe that Java is an ideal choice for the work I do — I don’t even think it’s a good one. There are rays of hope: RIFE looks to be especially promising (hell, even exciting!) for making Java web apps far less painful than the norm. But by and large, the way I believe most people write Java web apps makes it a very unpleasant platform to work with. Unpleasant in the sense of slow and ineffective, with far too much code.

I’ve also been turned off by unbearably slow development cycles, which I cannot lay entirely at Java’s feet. Other factors like politics and methodology contribute. Still, in most people’s hands it takes longer to write something in Java, becaCan a team of experienced, solid developers work fast and well with Java? Of course. But most development teams are not filled with that kind of programmer.

If it works for you, great. I don’t think it’s worth anyone’s while to get into pointless language debates. But personally, I would rather use something other than Java for web apps, especially the whole JEE stack. My experience with J2EE has been barely manageable complexity in both development and operations management, which stands a good chance of making apps more difficult to maintain and secure. It is a good fit for some applications, when JEE serves to address and alleviate complexity in the problem space by providing simple solutions. Assuming that happens. :) I just don’t see web app control flow and presentation as being a hugely complex problem until Java enters the picture.

So what’s the alternative? Oh, there are plenty. Could or should Java play a role in our development? Of course. There’s often a reluctance to involve more than one language in an application stack to keep things “simple,” which I think is short-sighted. I often like to use more than one language for complex apps because it forces me to keep the design and APIs clean, a collection of loosely coupled services. Sometimes I like to use a full-stack framework, too. It depends. Use the best tools for the job. Leverage the strengths of the languages in your arsenal. Java fits well on the far back end, integrating legacy systems and managing interplanetary navigation. Closer to the front end of a web app, I’d use something a bit more suited to web development, like PHP. In the end, I think it would be faster to develop, easier and cheaper to maintain, and make developers happier. I try to be pragmatic and happy in my work.

On the latest Pro::PHP Podcast, Marcus Whitney interviewed Microsoft’s Brian Goldfarb and Joe Stagner about PHP on Windows.

PHP developers may have already heard this interview (if not, why not? It’s a good podcast!). I wanted to be sure to mention it here because just as I think it’s useful and important for PHP programmers to separate the language from the LAMP platform and get away from knee-jerk reactions against anything having to do with “M$”, I believe that .NET developers should hear discussion from within Microsoft of non-Microsoft languages on their platform and how that might be a Good Thing. Good stuff.

I haven’t talked or written much about it, but I like a lot of what I see in .NET. Microsoft has done a far, far better job than Sun (or Oracle, or IBM…) at marketing to developers. I’m still not about to take much time to play around with .NET, since I don’t have a Windows box at home and have better things to do with my time at work, but it is compelling. I’ll probably watch some of the webcasts at learn2asp.net, and who knows? Maybe I’ll get Mono up and running on my Mac, although I think it’s too early for .NET 2.0 on Mono at this point, right?

Of course, first comes more Ruby, more PHP 5, then Smalltalk, Lisp, Haskell, Erlang… oh, and raising two kids. Do you see my problem? :)

Go listen to the interview.

I spend far too much time explaining to my coworkers that no, Internet Explorer is not behaving correctly: that caching behavior is broken, that box model is not standard, that JavaScript behavior is unusual. Sometimes it’s not even that IE is wrong, it just chooses a different path than every other damn browser we test. Yet the expectation I confront is that if IE behaves a certain way, it is right and everything else is broken, so we should just tell people to use IE. Aargh! And best yet, it doesn’t matter that IE on my computer doesn’t behave the way it does on theirs, because IE on their computer does what they expect so I must have a nonstandard configuration. Grrr…

So it is with great relish that I read Amy Hoy on troubleshooting Internet Explorer. I’m pinning that to my wall, you can be sure.

I’ve had Selenium on my radar for a while. Automating web app tests in a browser? Sounds great. FIT-style test definitions? Fantastic. Run it from JUnit? Wow! But I was always “too busy” and never got anywhere with it until I discovered Selenium IDE, a Firefox extension that can create and run Selenium tests. I watched this screencast, installed Selenium IDE, and was up and running in no time. I highly recommend it.

It immediately proved useful, as I discovered an intermittent bug in one of our web apps. Selenium IDE recorded my session on the web app, including a check for certain text that indicated the bug. I saved the test definition as an HTML file and attached it to the bug report. After I walked the developer through installing Selenium IDE and loading my test, she could run through it several times to finally trigger the bug. Bingo! I don’t think I’ll need more than that to sell the tool to the rest of my team.

Now I need to dig deeper and see what more Selenium can do for me. Also, take a look at Selenium on Rails.

I’ve been using RadRails for Ruby on Rails development at work. It’s a Rails IDE built on Eclipse, available as a standalone (which they recommend) or as a plugin. We already use Eclipse for Java development, so it’s an easy step for me to make. And it does make a few things easier than, say, JEdit. ActiveState’s Komodo now sports Ruby and Rails features, but its project file handling annoyed me so I quickly gave it up. TextMate is definitely my editor of choice on the Mac, but on Windows I’ll happily stick with RadRails for Ruby and Rails projects.

They’ve just posted a screencast that demonstrates RadRails features. It does about what you’d expect with regard to editing: RDT for Ruby editing, and an RHTML editor that, while not perfect (no tag completion yet), gets the job done and has enough syntax highlighting to make my life easier. If all I wanted was a text editor, though, I’d stick with a text editor and avoid the Eclipse overhead. What keeps me with RadRails is the easy stopping and starting of a WEBrick web server, generators, tailing the development log, and the simple database browser. This is all available through a terminal window or other apps, yes, but sometimes it’s nice to have everything in one place. The raison d’être of an IDE.

Strangely, this isn’t how I work on a Mac, where I feel more at home with small, well-defined apps that each do one thing well. On Windows, though, I’m more at home with an IDE. Odd.

Ah, who am I kidding. I ought to just cave and start using Emacs.

One more nicety: the developers podcast their releases, discussing what’s new in the release and what’s coming up. I enjoy these. They’re easier to digest than just scanning through a changelog.

“Do you really read all those goddamned blogs?!”

My brother asked me that after he saw a couple hundred feeds in my blogroll. “Sure,” I wrote back, “it’s not as bad as it seems.”

That was 200 feeds ago.

Now that I’ve tipped over the 400 mark, I’ve had to make some changes. It happened when Alec was born and I took three weeks leave from work. I decided to stay away from the computer for a while, checking email only occasionally and not opening my feedreader at all.

It felt good. Really good.

I fell back on my old habits, though, for several weeks, feeling like I was more and more behind the times, until I caught Merlin Mann’s interview on Inside the Net. Listening to Merlin talk about email management, I was feeling pretty good about my inbox. I’m brutal with it. I open email just a few times a day, and clear out the inbox completely. To-do items end up in Remember The Milk, some email gets filed for reference, and an awful lot gets deleted. It feels great.

Then I opened up Feedlounge, which I was test-driving as my new web-based aggregator, and was crushed by the 3000+ unread items. Then and there I decided to simplify. I cancelled Feedlounge and resolved to stop using web-based aggregators entirely. Now I read only at home on my Mac, checking in on just a handful of core feeds every day or two. I still have the full feed list in NetNewsWire and scan through it occasionally, but feel no compunction whatsoever about marking everything read. Very liberating.

How very sad that this feels liberating. But it does.

And yes, NetNewsWire. My friend Jim suggested Vienna, which I used for a while but had to abandon because it was choking on one of my core feeds (Stephen O’Grady’s). NetNewsWire does what I need, perhaps because it’s very good at what it does.

I haven’t received official confirmation, but it looks like my two proposals for the Minnesota State Colleges and Universities Information Technology Conference have been accepted this year. This is an annual conference for IT staff from our colleges and universities statewide. I was sorely tempted to do a third and am still kicking myself for not proposing a web security talk, but I didn’t want to stretch myself too thin.

The first is an introduction to Ajax, which I’ll be doing with Dave Kruse, webmaster at South Central College. Dave is damn sharp and a real pleasure to work with, so I’m looking forward to collaborating with him on this talk. The second is an introduction to this new wave of web frameworks, using Ruby on Rails as the starting point.

Oh heck, it’s probably easiest if I just share the proposals.

Introduction to Ajax

Ajax is changing how we create and experience web applications. No longer are we constrained by the slow and restrictive practice of loading an entire page in response to a user action. With Ajax, we use JavaScript to make HTTP requests and modify sections of a page on the fly — without reloading the page. Once the load-click-reload cycle is broken, we can write more responsive, engaging web applications to meet and exceed users’ growing expectations.

This session explores the technology and the impact of Ajax. We provide an overview of the technology behind Ajax and how to use it. The basic code and techniques are straightforward, but there are enough gotchas and quirks that it’s worth using one of the many libraries available. We will introduce popular toolkits and describe/demonstrate their interaction with server-side platforms.

In recent months a creative and vigorously active community has built up around Ajax; we have learned much about how to use it effectively and where the pitfalls lie. After our introduction to the technology, we will turn to common patterns and best practices for using Ajax to enhance web applications, as well as antipatterns that impede usability and accessibility.

We have found that developers are sometimes aware of Ajax and even familiar with coding techniques, but often do not know how or whether to use it in their applications. For this reason, throughout the session we will again draw on real-world apps, including our own, to illustrate and support the concepts.

Ruby on Rails and the New Web Application Frameworks

Since its appearance just over a year ago, Ruby on Rails has drawn tremendous attention. Over-hyped as a Java killer, unfairly dismissed as a toy, the web application framework embodies time-saving, productivity-enhancing ideas about web development that can mean a five- to tenfold increase in developer speed. Similar frameworks for other languages and platforms have emerged in the past year, as well: Django and TurboGears in Python, PHP’s Symfony and the Zend Framework, Catalyst in Perl… All promote a notion of radical simplicity and solid application design, dramatically reducing the amount of work necessary to get an app up, running, and maintainable.

I believe that this is the future of web application development.

This session explores what we can learn from this new breed of web application frameworks. I will start with a demonstration of Ruby on Rails, building in minutes what might normally take hours with traditional development methods. Using that application as an example, I’ll then touch on what makes Rails special, including:

• DRY. Rails embraces the “Don’t Repeat Yourself” principle, reducing coupling between application components. This results in more flexible and maintainable code.
• Convention over configuration. Developers working with web application frameworks, especially in Java and .NET, struggle under the burden of numerous, complex, and interdependent configuration files. By adopting simple naming conventions, Rails “figures out” what would otherwise be handled in configuration: object-relational mapping, request dispatching, and so on. This allows a programmer to focus on application functionality instead of losing untold hours muddling with config files that have little or nothing to do with the app itself.
• Change is instant. The dynamic nature of the language and framework mean that changes made to the code and to the database structure are immediately reflected in the application, without costly compilation and deployment cycles. This will be nothing new to most web developers at MnSCU institutions, but Rails does take it up a notch. A rapid feedback cycle supports a development model that encourages close interaction with customers and improves the likelihood that apps meet their needs.
• Full-stack framework. Most web apps piece together their components: MVC scaffolding, database access and object-relational mapping, request routing, templating, etc. Rails is a one-stop shop, providing the necessary components as an integrated but loosely coupled stack.
• Integrated testing. Developers are waking up to the importance of unit testing to the design and stability of their code. Rails makes testing easy and so more likely to be done.

Having introduced Rails, I will then describe several similar frameworks that have emerged and express the same ideas about web development. I will tease out common threads and put forward lessons that we can learn from this new class of frameworks, including:

• The power of dynamic languages. Yes, powerful apps can be written in something other than statically typed languages such as C# and Java.
• Rapid prototypes and iterations are invaluable. Nothing beats working software for getting customer feedback and identifying what the requirements really are.
• Rapid application development is not necessarily antithetical to good architecture and design. The new frameworks are built on proven design patterns.
• Favoring convention over configuration is an enormous advantage. In cases when you need it, dynamic languages allow code as configuration (instead of the ever-present XML files).
• Simplicity is essential. We’ve all paid lip service to this idea, but the new frameworks really take simplicity to heart.
• The importance of testing. Untested code is broken code. The usual way of developing web apps does not support good testing practices, and in some cases throws up huge roadblocks. The new frameworks make testing easy, promoting it an integral part of the development process.

Even if we never use Ruby on Rails or any of the other frameworks, we can learn from what they’re doing and why they’re being adopted with such fervor, to make our lives easier and our web applications better.

It’s been a while since I’ve posted here, and since Owen has amazed me by going to sleep on his own for naptime, I thought I’d share a couple cute Owen stories.

1. Kiara overheard this when he was playing by himself: “‘What a fascinating passenger,’ the dinosaurs giggled.” Tee hee.
2. Unrelated, but still a dinosaur story. “These dinosaurs are in packs,” he told me. “Some of them are in smaller packs. I call those ‘packets’.”

   

He’s so fun to have around.

And yes, Brian, if you’re reading, these are those plastic dinosaurs.