photo by penywise

I am going to RailsConf next month in Portland. Of course, up until today, I didn’t know what sessions I would be attending. But Dr Nic fixed all that for me with a great application.

Check out the RailsConf schedule and see where I’ll be.

photo by bjearwicke

I have come across a few situations recently where testing is a second class citizen in the development process. The latest was a job posting where the part of the development environment was described as “testing when possible.” A lot of the larger projects I have worked on have 1 or 2 weeks of testing tacked on to the end of the development cycle. More times than not, this “testing” time becomes padding for development schedules that overrun. Besides “you tested as you developed, right?” and “we can’t move the delivery date.”

I am becoming more and more an advocate of writing automated tests. This has become even more important when I am the sole developer on a project. Now you might say to yourself, “If there is no one else to mess up the code, shouldn’t everything work?” It does work. But as I come across areas of code that need to be refactored, because I am DRYing up my code, I want to be sure that my changes do not break existing functionality. Now I could make the changes and then manually try to test all of the possible scenarios, but I usually miss one or two, especially in more complex applications. This is where the automated tests come in very handy.

photo by mcconnell6

Maybe I am thick, but writing tests using JUnit or Test::Unit never seemed natural. It always seemed to go at the end of my development cycle. Maybe it was the vocabulary implying that something had to exist to be tested. Maybe it was the unnatural language of assertions: assertTrue, assertThis, assertThat. Who talks like that?

Then I came across something that encouraged me to write specifications for an application that could then be used after the development was complete to verify that the specifications were met. All of the sudden I was discussing how the application should behave, which does not imply that the application even exist yet. This makes sense to me. I saying things like “this should equal that” or “something should have 5 of these”. It is subtle, but powerful.

So I am now using RSpec, the Ruby implementation of Behaviour Driven Development, for all of my projects. My latest Rails project has only 6 models and 2 controllers, but has over 200 specs. I have a better understanding of how the application is supposed to behave. Combine that with a way to continously re-run the specifications when the code is changed and I am now a lot more confident that my changes aren’t breaking existing functionality.

Plus, it’s cooler, right?

I wanted to mention a simple little tool that has saved me hours. The Yahoo! UI CSS Foundation is actually three separate CSS files: Reset, Fonts, and Grids.

Reset removes all of the default styling from the browser. Even with out add a stylesheet to you website, the browser (Internet Explorer, Firefox, Opera, Safari) has already add some default styles. This is why headers are bigger and bolder than text in a paragraph. But, amazingly enough, the default styles vary from browser to browser. Reset CSS is great because it removes all of the default styling and let me, the developer/designer, go and set the style that I want. I can be sure that some default style won’t creep in and ruin a good design.

Where Reset removes all of the default styling, the Fonts CSS sets a level playing field and uniform approach to font sizing. With the various ways to size fonts (px, pt, em, %), it shouldn’t be any suprise that once again the various web browser handle these differently. The Fonts CSS gives you a uniform way of setting the base size of the document and adjusting all other font sizes as a percentage of the base size. It turns out that, while requiring a little bit of math, this is super easy and keeps things looking good.

While I start every project with the Reset and Fonts CSS, it is the Grids CSS that really is the time saver. Now that using tables for layouts is so 1990’s, coming up with cross-browser compatable grid layouts can be a challenge. When you combine it with the decisions of fixed-width or fluid layouts, sidebar positioning on the left or the right, semantic markup, and search engine optimization, grid layouts can make you scream and run. The Grids CSS gives you three tools in one: fixed-width or fluid layouts, sidebar size and positioning, and grids. I won’t get into all the details, but you can play with the Yahoo! Grid Builder or check out some of my latest projects to see it in action.

To top it all off, there is one combined file that is compressed and includes all three CSS components. All you have to do is add a link tag pointing to the latest version and you are off and running. Now you can focus on more important things, like making your application functional.

I went to the Dallas DemoCamp2 on Monday night to check out some of the latest offerings from North Texas entrepreneurs. And there was quite a showing with 6 presentations and at least 25 people in attendance.

What I love about DemoCamp is the format. You get 15 minutes for the entire presentation. And that is broken down into 10 minutes for for the demonstration and 5 minutes for questions and answers. With this format you aren’t intimidated by amount of time to fill. Almost anyone can talk for 10 minutes about their project that is the “next big thing.”

Check out the photos and be sure to make it out for Dallas DemoCamp3. Who knows, I might even have a project or two to show off.

It finally happened. McKinney Station got a blog! Right now there is not much here, but should be changing very soon. I have all sorts of articles in my head wanting, no, demanding to get out. Thoughts on web applications, Ruby, Rails, Java, xHTML, CSS, JavaScript and more.

Check back soon for my latest thoughts and ideas. Welcome to the Station, this train is about the leave.