thirdbIT

From a fascinating blog called Coding Horror:

It’s painful for most software developers to acknowledge this, because they love code so much, but the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can’t get away with no code, the next best thing is to start with brevity.

I did my first successful Capistrano deployment last night. The rubyonrails manual is pretty nice, though it is a bit out of date, and uses rake migrations, which are now deprecated in Capistrano. What really was a tremendous help for me was Coda Hale’s article *Time For A Grown-Up Server: Rails, Mongrel, Apache, Capistrano and You*, which not only convinced me of the superiority of a Mongrel cluster proxied via Apache’s mod\_proxy\_balancer to anything using FastCGI, but which also provided a fantastically useful walkthrough.

I was flummoxed for a bit by my failed deployment, when it turned out that all I had wrong was that the :repository variable in config/deploy.rb was set to something slightly wrong, so the remote Subversion client was unable to check out the code. And I even thought that I saw the activity appearing correctly in the Subversion server’s Apache logs. Once that was fixed, “cap cold_deploy” worked like a charm. The error was a bit inscrutable (to me) for a while. See the dumb syntax error? My “prj” abbreviation for “project” was what killed me. (That’s not the real project name; I have anonymized the thingy.)

my-host:~/project max$ cap cold_deploy
* executing task cold_deploy
* executing task update
** transaction: start
* executing task update_code
* querying latest revision…
svn: REPORT request failed on ‘/repos/!svn/bc/40/prj/trunk’
svn: ‘/repos/!svn/bc/40/prj/trunk’ path not found
*** [update_code] transaction: rollback
* [update_code] rolling back
* executing “rm -rf /u/apps/project/releases/20070601032656″
  servers: [”www.project.com”]
  Password:
   [www.project.com] executing command
    command finished
/usr/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/lib/capistrano/scm/subversion.rb:24:in `latest_revision’: Could not determine latest revision (RuntimeError)
     from /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/lib/capistrano/configuration.rb:62:in `initialize’
     from /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/lib/capistrano/configuration.rb:89:in `call’
     from /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/lib/capistrano/configuration.rb:89:in `[]’
     from /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/lib/capistrano/configuration.rb:236:in `method_missing’
     from /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/lib/capistrano/scm/subversion.rb:63:in `checkout’
     from /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/lib/capistrano/recipes/standard.rb:80:in `load’
     from /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/lib/capistrano/actor.rb:159:in `instance_eval’
     from /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/lib/capistrano/actor.rb:159:in `update_code’
     … 13 levels…
     from /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/lib/capistrano/cli.rb:12:in `execute!’
     from /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/bin/cap:11
     from /usr/local/bin/cap:16:in `load’
     from /usr/local/bin/cap:16

Look out: Capistrano 2 is *just* about to come out, and migrating from 1.4 -> 2.0 will be somewhat involved.

I am profoundly disappointed that previous family commitments are going to keep me from attending this month’s Boston Ruby meeting, which includes a presentation by the delightfully acerbic Zed Shaw, the author of Mongrel.

Today I needed to figure out how to best paginate results from an acts_as_ferret search (Go here for a tutorial on acts_as_ferret.) Kevin Clark told me that I shouldn’t be using the built-in rails pagination, though I was not the only person wondering why the hell it’s in there if I’m not supposed to use it. Lazy as always, I went looking for someone else’s paginating code. Here’s what I found. I’ll update this entry with my impressions of the code once I’ve actually used it:

Cardboard Rocket offers a paginating find plugin.

Ilya Grigorik provides a discussion of aforementioned plugin, plus the helper and view code to go along with it.

He also offers a version for acts_as_ferret paginating find.

Also, the chowhound developer provides some alternate pagination code, which I was thrilled to find, not least because I used to love the content of chowhound (way back when we ate out a lot) but hate the format (message board circa 1992). And yay, now chowhound has the standard rails look-and-feel, of which I am a big fan.

By the way, if you’re new to Rails, you should be aware that the pagination issue was a minor explosion in the rails-world. File that one away in your “rails cultural literacy” dir, and you’ll be well on your way to faking everyone out about how long you’ve been in RoR land.

As mentioned before, tests offer proof that you’ve done a good job. Your tests become your own personal QA assistant. If you code your tests correctly, at any point in development, you will know:

• what processes work
• what processes fail
• the effect of adding new pieces onto your application

With your tests as your safety net, you can do wild refactoring of your code and be able to tell what needs to be addressed simply by seeing which tests fail.

In addition to normal “did it pass?” testing, you can go the opposite route. You can explicitly try to break your application such as feeding it unexpected and crazy input, shutting down critical resources like a database to see what happens, and tampering with things such as session values just to see what happens. By testing your application where the weak points are, you can fix it before it ever becomes an issue.

A strong suite of tests ensures your application has a high level of quality. It’s worth the extra effort.

Another positive side-effect of writing tests is that you have basic usage documentation of how things work. Simply by looking at your testing code, you can see how you need to work with an object to make it do it’s thing.

The online book is a fantastic resource. Thank you, thank you, Sam-I-Am.

Max and I are trying to learn how to write tests for our rails apps. Like many things in rails, testing seems intuitive to those who understand what’s going on already, but people who claim there’s no learning curve are deluded. The first three times I opened up my test directory and started trying to write test code, I grew incredibly frustrated and confused and gave up. “What’s assigns() do? How do I write my fixtures? Why do I always stick my colon in the wrong place when going back and forth between yaml and ruby code? What should I be testing anyway?”

“Who needs tests?” I thought. “That’s what QA is for! No one can figure this stuff out! I have no frackin’ clue what is going on here, and I never ever will.”

But I kept trying. When Max and I sat down this morning to write tests for our current project, we quickly grew, yes, frustrated and confused. We snapped at each other. Max squinted a lot, and I pointed accusingly at the screen a number of times. “See! See! Do you SEE what we are doing here?!” We couldn’t get one teeny tiny little test to pass. We wanted to do pretty much anything else.

But okay, we said. Learnd-ing is hard, as Ralph Wiggum (or a certain George) might remark. We are frustrated, but we will get it.

Eventually, we got our test to pass.

Now we just have about a zillion more tests to write, and we’ll be all set.

Why are we learning Ruby on Rails? Let’s ask _why.

_why: his very existence, his poignant guide, his utter bizzare-itude. His hackety-hack project. Having come across _why, how could we turn down his invitation to learn ruby?

Now, apparently, some people have a very different reaction to _why. Some people think _why is what’s wrong with Ruby. _why thinks that is funny:

The problem here is: the author of the article is trying to do academics, to gain knowledge, to build a career. And my cartoons and stories have patronized him, belittled him, by treating him as if he wasn’t a real professional. This is a terrible breach of conduct. He has accolades innumerable. He has done no small deed. His peers are all gathered around him, wishing him the best and swelling with nothing but respect and esteem for him. NOW WHAT IS THIS CARTOON BOOK DOING HERE??Programming is for world commerce. It is like agriculture or fossil fuels. It is lot a like baling hay. I’ll give you an example: You wouldn’t write a cartoon book with a plot and running narrative just to show a guy how to bale hay! That would frustrate the guy! He would throw that book in the pig’s pen! He just wants to get straight to the nitty-gritty and, for once in his life, just bale hay, straightway!

It’s not just _why, of course. We’d be pretty pathetic if we decided to devote lots of time and effort to a new programming language just because of a cartoon book. I mean, we have to have serious, professional, career-oriented reasons for learning ruby. And Rails, of course. Not that ruby doesn’t exist without rails. Ruby doesn’t need rails to justify its existence. Matz is not DHH, after all. Matz came first. And then, presumably, came _why. 37signals was later.

Learning a new language takes a lot of effort. I’m trying, lackadaisically, to learn french, since Max speaks French and Ari is learning it, primarily by having Barbapapa books read to him over and over again. And we have a bunch of french friends, and it’s really depressing at dinner parties how I’m never quite sure what people are saying. It’s hard, though, and what would make it even harder is if I didn’t like french culture.

Learning a new programming language is a lot like learning a new human language. It comes with a culture. You have to like the culture to want to put in the effort.

So, you know, we have a friend who’s making fistfuls of money because he’s a crack ActionScript 3 developer. Every time we turn around he gets another promotion, and another raise, and he says the world is desperate for ActionScript 3 programmers. We hear this from other people we know, people with jobs. We don’t have jobs right now. Well, Max consults. And I consult to Max on his consulting. But not a 401(k) plan between us. So I keep thinking “fine, let’s learn actionscript”. Except that it’s like trying to have sex with someone you’re just not attracted to. close your eyes and think of Ruby. Oh wait, I swore I wasn’t going to mention sex on this blog. Note to self: blog is for professional presence. Sex: not professional. Well, except for sex workers, for whom sex is professional. But I’m not a sex worker. Am I calling my actionscript friend a sex worker? Not sure. We love you, actionscript friend! And I will be quiet now.

What I’m trying to say here is that we like the Ruby culture. No doubt we’ve come to it too late, and in about two weeks it won’t be cool anymore and people will be all ‘ewww, you’re a ruby person? Rails is soooo 2006. Didn’t you know that Twitter proved it wasn’t scalable? And it’s s…l….o….w.” But that’s okay. When I first started programming, it was because I fell in love with a heapsort. Heapsort had been around for a pretty long time then, but I felt like I was the first person who’d discovered how cool it was. (Kind of like teenagers and sex. Oh wait, there I go again. Shut. Up. Amy.)

Anyway, here we are, immersing ourselves in Ruby culture. We’re gonna go to a Boston Ruby Meeting, where Hackety Hack will be demo-d. I’m subscribed to all these Ruby blogs. We’re studying the idioms and learning about the people and the projects in the Ruby world. And, of course, learning the language. We’d like to contribute to the conversation at the Ruby table.

As for Rails, we’re learning it because we need to write our own web-based to-do list. I’m joking, I promise. Rails comes along with Ruby because most of our experience in IT has been web-related. So we’re leveraging our experience with web technologies and increasing our skillset with Rails, an agile Ruby-based framework that dramatically increases the speed and ease of web app development. See: serious and professional. Ignore the cartoon foxes and sex workers.