Archive for the 'Uncategorized' Category


Troubleshooting IE

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.


Selenium IDE

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.


Limited attention.

“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.


Conference Proposals Accepted.

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 a boy! Welcome, Alec.

Alec Friday, 11:37 p.m. Kiara shakes me awake. “I keep wanting to wake you up to remind me to relax through the contraction, so I think they’re getting stronger.

“Let’s go have a baby.”

We arrived at the hospital sometime after midnight, and three hours later we welcomed Alec Matthew Buchanan into the world. 8 pounds, 10 ounces, 20.5 inches.

I won’t say much about the labor and birth right now except that it was amazing. And now there’s a new sleeping baby in the house.

Our heartfelt thanks to everyone who helped, especially our moms.

But right now, it occurs to me that Owen is going to be waking up in six hours and I’d best get to sleep myself.


Head First HTML

A coworker picked up a copy of Head First HTML with CSS & XHTML. I’ve written before about how much I like the Head First series, and have raved to this coworker about all the Java books ever since I saw the first one. Solidly based in brain research and smart pedagogy, and just a damn fun good time, I can’t think of a better way to learn. He agreed but wasn’t interested in the Java. At last the HTML book was released, he bought it, and I stole a few minutes with it when he wasn’t looking.

I am impressed. First, it’s heavier than the others. Downright hefty. Why? Color. Full-color photos and illustrations, something that’s been missing from previous books in the series but that makes so much sense for a book whose aim is to grab your brain’s attention and make it think something like markup languages are important enough to remember.

It starts out with the basics, suitable for an absolute novice, As you might expect from the title, it does delve into XHTML & CSS, and in the way that a standards-oriented guy like me would hope for. I was very pleased to see that. Much as the depth of Head First Java might surprise you for an intro Java book, having you build threaded network applications before it’s through with you, Head First HTML is teaching CSS positioning by the end of the book. It really looks like if you want to know how to put together web pages, this is the book to start with. You’ll have to go elsewhere to learn much about JavaScript, Flash, etc.. This is a Good Thing: pleased as I am by what is covered, I’d hate to see the book try to do too much. Still, to use those well you need a solid foundation in (X)HTML and CSS; from what I’ve seen in a stolen two minutes, this book provides that.


Not What We Thought

The word of the day was going to be prodromal labor. But it turned out to most likely be Braxton Hicks.

Two full days of Braxton Hicks.


Web Developer Toolbar 1.0

Chris Pederick’s Web Developer Toolbar 1.0 has been released, with lots of new features and bugfixes. I find it so indispensible that I am floored when I see a web developer who doesn’t use it.


Night Trains

We took Owen to see Night Trains at the Twin City Model Railroad Museum in Bandana Square. I’m not into trains, but this is amazing. They’ve built an enormous model of the Twin Cities that fills the room. For Night Trains they dim the room lights, light up the trains and show off their work. Everything is designed and built by hand from scratch. Many (all?) are modeled after real trains: one guy talked about building a train that a buddy of his had driven for years, complete with a miniature model of his friend inside. Owen loves it. Highly recommended.

« Prev - Next »