photo by vitalyzator

I presented on RSpec 1.1 tonight at the Dallas.rb. I don’t claim to be an expert, I just love my specs (and now stories).

Feel free to take a look at the slides.

Last night I recieved my very own copy of “Nobody Knows Shoes” by why the lucky stiff. Shoes, in case you are wondering, is a small framework for writing GUI applications that can run on multiple OS’s (Windows, Mac, Linux). “Nobody Knows Shoes” is the API documentation for the framework presented in the form of… well… comic book/ short stories/ examples… and that doesn’t even do it justice. I played around with Shoes and decided to get the book to see what it was all about. It is well worth the cost (less than $15, including shipping), if not for the pure entertainment value. It is also a good reference, as well.

If you haven’t experienced why or any of his code, you should definitely take a look. You will be entertained and enlightened.

photo by laffy4k

So I came across Dan Manges Fixture Factory as a way to relieve myself of the pain of fixtures for testing. I don’t mind fixtures that much, but when I have to start setting up so many different combinations, it gets a little challenging. In reading through the comments I found that Scott Taylor had implemented it as a plugin. Now I get all that goodness for my specs.

The other day I wanted to play with some things using script/console, but was feeling too lazy to set up all of the data I was going to need to do what I wanted. Sure enough after looking at the documentation for fixture_replacement, I can use it there too:

  % script/console
  >> include FixtureReplacement
  >> cause = create_cause
  >> user = create_user
  >> cause.users << user 

It is really useful for easily setting up your test data in the spec (or test) that you are writing. Instead of having to go off to the fixture files and add new fixtures (and try to remember to set up all of the dependent fixtures that are needed), you can use new_xxx or create_xxx to get an object to test in a valid state with all its dependent data.

Take a look at the FixtureReplacement plugin now.

My friend, Chris Gay, is a finalist in the Amazon Web Services Startup Challenge with his company, MileMeter. I love the concept of only paying for the auto insurance I am going to use. Both my wife and I work out of the home and therefore our cars sit in the garage alot. But I still have to pay the same rates as my neighbors who drive to downtown Dallas everyday. For both cars!

So now I urge you to go and vote for Chris and MileMeter.

photo by chick_e_pooo

Last night, Adam Keys and I did a little ping pong pairing for the Dallas.rb meeting. It was fun. Of course it highlighted how much I have to jump back to the Ruby docs to get much done. But I don’t see that as a problem, since it leaves more room in my head for other things. It also showed my lack of regex-fu.

Here is the code we worked on. We were trying to solve the Ruby Quiz Credit Card problem, and got most of the way through. The fun part about pairing was bouncing ideas off of each other. Others in attendance were also helpful with their suggestions. It was especially interesting as we looked back over the code and discussed even more ways to clean it up.

Would I do it again? You bet. But I think next time, I would like to work on something that I am more comfortable with, like a Rails related app. I love writing specs for that.

photo by anyoungkevin

We are doing lightning talks at this month’s dallas.rb meeting. I decided to give the group some choice of what I would present.

I will do a short one on “Why Firefox Makes Me Look Good” or “Better Web App Development using Firefox and a Buttload of Extensions”

I can also do one “JQuery: I Don’t Know Much, But I Know I Love You ”

And since neither of those are Ruby related, I will throw another one out there: “Tighter Abs: XML Situps Made Easy With Ruby”

I’ll let everyone decide which ones you want to hear more about.

Update

I only did the JQuery presentation and here are the slides (although they were much more interesting in person).

photo by zruvalcaba

After my last post, I thought I would share what I use for developing on Ubuntu.

Editor

I have always been a hands-on kinda guy, so I don’t use any of the fancy IDEs. Right now, I am using SciTE for two reasons. It feels lightweight and it is available for Linux and Windows. Since my laptop does not have a lot of memory, a lightweight editor is a must. I tried Eclipse, but it chewed up all my memory and slowed things to a crawl. So SciTE with some additional plugins (and information on getting them going) powers the development at McKinney Station.

Ruby and Rails

I am using the latest Ruby and Rails for all new development. For testing I am using RSpec, which seems a lot more intuitive to me. Other gems I have installed include:

• FasterCSV - parsing CSV files
• starfish - simple Ruby Map/Reduce
• mongrel - lightweight Ruby web server
• hpricot - Ruby HTML parser

Database

I love starting all of my development projects with SQLite. It is so easy to get up and running. As the project matures, I am able to quickly switch development over to a MySQL database with a change in the application’s database configuration and a quick rake db:migrate.

Version Control

All source code versioning is done with Subversion. With this quick little script, I can get a Rails project committed and started in minutes.

Conclusion

I am always looking for ways to speed up my development process, but so far this is working for me. And it is very enjoyable.

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?

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.