Hawaiʻi's Technology Community

In April I walked many kilometers in Paris. After quite a few days of walking, sipping coffee and practicing my terrible French, I read a fascinating article on the problems we cause ourselves by wearing shoes with padding in the heels (I'm oversimplifying; feel free to read the article yourself). The padding insulates us from our repeated impacts, and we can't feel how we're walking. The article claims that this slowly damages our joints, doing the most harm to knees and hips.

So I bought a pair of Vibram Five Fingers 'shoes' (and I use the term loosely). They have changed my gait dramatically, because it hurts to slam my heel into the ground with no padding. I've had to learn how to walk smoothly, to pay attention to my gait, to be a more functional animal. Changing the way I walk has changed the way I stand; My sister-in-law flew in today, and she said that she thinks I've lost weight. Unfortunately, I have evidence that my weight hasn't changed since I saw her last; I believe it's the improvement in my posture that gives the illusion of fitness.

What does this have to do with tech stuff? I'm glad you asked.

I'm starting to lay the groundwork for an updated version of a Rails-based site I built to incorporate some critical features like support for multiple companies, background process instead of spinners that make the user wait too long, and an 'a la carte' feature selection system. About 75% of the old code is probably good enough to keep, with the necessary modifications. How can I improve my app's posture so it can go longer without hip replacement surgery? So that it appears to have lost weight while still supporting the new features?

I think my app's biggest weakness is that I don't have nearly enough tests. This gives the illusion of solid, bug-free code by insulating me from the areas where the code doesn't exactly match my original intention, while providing many points of potential failure (if it hasn't been tested, it is a potential failure point). So I'm trying RSpec and BDD. For now, I'm being disciplined (retentive?) about writing specs, and looking into using stories for the the first layer of user level tests.

Is it working? I can't say, yet. But it sure feels better!

Does this analogy hold up? What is 'good posture' for code, or for a coder? I'm still working on it...

Views: 74


You need to be a member of TechHui to add comments!

Join TechHui

Comment by Kurt Sussman on September 3, 2008 at 1:38pm
Laurence, I feel your pain. And I agree completely that BDD won't catch all my bugs. It also won't push my code toward DRYness, nor alleviate the pain of unexpected bugs in other people's code. Real testing is still required before 'shipping' a web app.

An old officemate of mine, Mark Fox, said that programmers do two things: debugging and enbugging. I think that writing tests minimizes the time spend debugging. There will still be bugs, and some will still be painful. But most of the stupid bugs will be caught by my tests, leaving only the challenging bugs for me to deal with manually.
Comment by Laurence A. Lee on September 2, 2008 at 11:13am
Kurt, thankfully that article wasn't one of mine (yeah, I noticed lots of errors in it too), but it did a good job of articulating the problem/solution anyway. I'm not discouraging writing good unit tests, I just think it's a lot of effort for what's essentially an incomplete (false?) sense of security.

IMHO, Rails Coders rely too much on Unit Testing to consider their code "good enough for production". A good example of this that recently nailed me is a little bug in polymorphic_routes.rb.

Despite polymorphic_url's method signature accepting an options hash, it didn't really do anything with the options hash (at least through Rails 2.1.0).

I lost half a day trying to figure out why my extra query parameters weren't showing up in links, going over documentation and questioning my own code because "it's calling Rail Core, so I must be doing something wrong".

I'm a little irritated it took this long (the entire Rails 2.x line including Rails 2.1.0) before this issue was discovered and fixed; and a lot more irritated at myself for blindly trusting the Rails Core team for that long. In fact, the more I work with Rails and monkeypatch the glitches, the more I realize the truth in Zed Shaw's Rails-Ghetto Rant. *Sigh*.
Comment by Kurt Sussman on August 31, 2008 at 5:38pm
Haken, I will climb the stairs on the Eiffel tower next time I'm there. We've been invited to a wedding in Paris in December, don't know if I can afford it though. I would rather climb it semi-barefoot, but not in December!

The almost-automagic API is one of the reasons I'm using Rails. I know that I can't imagine every possible use for the data my system collects; what's the harm in letting people create stuff using their own data? It also allows me to create a desktop app using something like Shoes. I really want to play with that. While I have evaluated APIs, written test plans based on API docs, etc, I don't have the experience creating them from scratch to do it perfectly the first time.

Laurence, I like that article, but it could use a few tests. :) I found some typos, mostly in the code.

I'm trying to decide between make_resourceful and resource_controller right now, so it looks like I agree with you at least to that point. Calling a well-tested super fits perfectly with my BDD path, and increasing DRYness is always a worthy goal. I agree that tests can be ugly, but I've found through experience (mine and others') that failing to test is like sewage in rusted pipes; it's gonna stink eventually.

Writing good tests is as hard as writing the code to be tested, sometimes harder. Dealing with the potential problems that result from Ruby's 'duck typing' are tedious. 'validates numericality of' only goes so far.
Comment by Laurence A. Lee on August 31, 2008 at 3:03pm
Actually, I'm kind of sitting on the fence when it comes to automated unit-testing. On one hand, it is good to know that your known test-cases (the ones you anticipate) are functioning properly. On the other hand, you can't anticipate all entry points unless you have good automated tools to weed them out. Thus, even if your unit tests pass, some punk kid could still find a hole to exploit.

I find unit testing to be especially bothersome for loosely-typed languages like JavaScript and Ruby, where foo could be assigned a number or a string, and you have to do explicit casting to ensure the expression foo + bar evaluates to 3 and not "12". There are just too many "stupid things" to test against and add Guards for, and it just makes for uglier code in the end. *Grr*

I think the best bang-for-buck to slim down code complexity is to spend time identifying any repeated Patterns in your models and controllers, and see if you can DRY up your code along those lines. I know, that's so cliche for Rails.. but it does pay off.

Aside from a few oddball Rails Actions, most of my controllers implement RESTful CRUD, so I've refactored that out. Some will argue it's confusing to hunt for the Base Class that implements the RESTful CRUD actions, whereas I view such code as uninteresting background noise. When I'm working on a controller, I'd much rather see the controller-specific enhancements to the create and a update method with a call to super at the end, rather than wade through all the CRUD cruft that's typically generated by a Rails Generator.

While not exactly the approach I've taken, this blog article describes this in much more detail.
Comment by Cameron Souza on August 31, 2008 at 12:18pm
As you implied, I believe the key is good "coding posture" is test driven development. Systems with heavy unit test coverage are easy to evolve and extend because you know right away if you have broken something. With scripting frameworks like RoR this is particularly important.


web design, web development, localization

© 2019   Created by Daniel Leuck.   Powered by

Badges  |  Report an Issue  |  Terms of Service