Quick tip: say (OSX)

If you have a command that you need to run and it takes too long to watch it (say, a profiling test suite), you can do: your_command; say “all done”, and your computer will tell you when it’s done running.

Woot!

Gluten Free Restaurants

Sara and I were talking and realized that having a quick reference of what’s gluten free and what isn’t would be valuable, not only for us, but for other people planning things or if we need to look on Google Maps.

Right now it’s just chains and Austin specific restaurants (and the chains are almost all in Austin), but we figure every time we visit a city, we’ll add a new sheet for that city.

Suggestions encouraged.

Here’s the link to the Google spreadsheet.

Months of effort

I won’t lie. Coffee tastes better in this cup.

Rails Gotcha: touch

If you call model.save, where you expect it either to return false or true depending on the validation, but that model is associated with another model via belongs_to and has :touch => true on that association, the touch calls save!

Inconsistent, and kind of makes touch useless unless you only use save!

Sometimes I get carried away…

Cap Release Notes

One of the really good things I learned from some guy, we’ll call Donkey, is to have everyone write down deployment dependencies in a file, so if someone goes on vacation or whatever during a deploy, you at least have an idea of what you should do.

I put it in /README, and separate everything by sprints. It looks something like this:

Even though everyone tries to remember to put things in there, there’s still a single point of failure, when the idiot who deploys it forgets to check the readme.

So, to prevent future self-indictments, I put a task that runs at the end of our cap script that prints the current release notes.

Ideally all of these are handled with a comprehensive deploy script, but that’s not always feasible/doable. Here’s the cap task, and if you make it the last thing that runs, you’ll get a friendly reminder at the end of every deploy for things you need to do.

Quick Tips

Chrome view source
I ran into an incredibly confusing bug last week where I had some fields named user[field_x], but they were being posted to my Rails server as user[field_y]. I started to blame all sorts of crazy things (becoming superstitious in not knowing wtf could be happening).

I pulled my field-level identity map (another blog post). I wrote some Rack middleware to intercept the parameters before Rails’s ParamsParser could touch it and make sure they were good. Fail. Nothing worked. After 2 hours of fighting with it, unable to reproduce in tests or anything, I realized I wasn’t viewing the source of the content I was actually viewing.

Chrome sends another, new request to the server when you say view source. This means that you’re not viewing the source from the page you’re viewing. If the pages are static or if there’s no way server state affects your page, then you’re good. Otherwise you might lose 3 hours.

This bug was painful enough that I’ve dropped Chrome as my default browser and am back on Firefox. I hope that by reading this you’ll think of it when you do view source on Chrome and nothing makes sense.

Git stash
I learned about git-stash over the weekend. It allows you to stash your changes on a stack, make some other changes to the codebase, do what you want with them, and then pull those stashed changes back out.

Example use case: I branch before everything I work on, but eventually I have to merge stuff back in. So I branch to make feature X, get it written, then merge it back into HEAD. Unfortunately, tests are failing. I’m not going to push my changes yet, but something needs to be changed for another developer who wants something to run locally. git stash –keep-index; do changes; git push; git stash pop. Done and done, and no broken builds!

Timecop
A developer at our office was working with some relative time methods. These are inherently tricky to test, because if “next week” means “next business week”, you can’t just willy-nilly add 7 days to a day and do tests. Same with “this week”, etc.

Instead of doing a bunch of complicated date math that would arguably make the tests just as scary as the code, we found Timecop, which lets you freeze time for your tests. You can say, “I want Date.today to evaluate to 20Apr2010″, and it will. This allowed for significantly simpler tests and saved a ton of time.

Avoid toggle actions
Even on some of the more popular sites on the internets, there are a lot of AJAX actions that don’t handle network failures well. Backpack (at least on my iPhone) just keeps the in progress icon going forever. We’re not doing anything super-critical with AJAX on our app, but we’d like to at least handle timeouts or failures gracefully.

The simple solution is to check for the HTTP response code and act appropriately (2xx? Yay! 4xx? BOO!). We decided to do this, but realized that it’s possible that your request makes it through to the server, then your network fails, and you get a timeout. What do we say happened on the client side?

If they’re single-direction actions (e.g., marking something done), then you can just say “Something went wrong,” and not worry about changing it back or anything. If it’s a toggle, though, you can’t make any guarantees. “Something went wrong,” sure, but should the user try again? What if it only went through for the first 3 items?

As such, we’re no longer writing toggle_x actions. Now we’ll handle that on the frontend, and have negative_x and positive_x methods.

DelayedJob scheduling improvements

Last week I talked with a guy who noted that the scheduling patch I’d blogged about for DJ was insufficient for scheduling something every day at 8AM. This is because running a job and then scheduling the job again after a success pushes the job out a little bit each time (maybe in a week or so it runs at 10AM, e.g.)

I thought about trying to make a run_at class method that would let you specify it, like “run_at ’8am’”, but that quickly fell through when I realized ’8am’ is ambiguous – 8AM every day? Every Wednesday? Every 4th week in July?

I fall inline with Brandon Keepers when I say that I don’t want to re-implement cron, because (imo) cron is one of the best scheduling tools out there already, and it comes packed onto every Unix distribution that ends with x.

Instead, I changed the run_every method to now accept a block, so you can pick the new best time to run if you’d like, or just keep using the same old (8.hours) syntax.

Think something like this:

If you like it, here’s the GitHub Repo.

Pivotal Pulse and Integrity

For better or worse, I’m committed to Integrity. Its green successful builds are alluring enough that I can’t put it down, even if it’s a little … different … occasionally.

At my old job, I had Integrity in an iframe taking up half of a ginormous TV mounted on the wall. There was some javascript I tossed in to bounce the iframe into build-specific views every 15 or so seconds. It was nice, but kind of hard to see quickly, and limited to only the Integrity builds.

At my new place, I’m working on getting some automated testing working on several servers (Cuke/Watir tests run by Hudson on a few Windows machines, and our unit/functional/integration tests run on Integrity), so I wanted something that could aggregate across those.

I found Pulse by the Pivotal guys, and it looks really pretty. I like the boxes. Rounded edges. It’s the little things.*

Anyway, hooking that up to Integrity wasn’t straightforward, because Integrity doesn’t implement a project-specific RSS feed (Pulse requires either a Hudson or CC-style feed). So I wrote one tonight.

I could have released this as a gem that you could include on your Integrity app, but I don’t really have any intention of maintaining this for anyone else, so I wouldn’t want to put out that expectation.

If you want the code for a project-specific RSS on Integrity for something like Pivotal Pulse, here you go:

* A friend informed me as I was telling him about this that Hudson (which I’ll be using on the Windows machines) has an aggregator plugin. Color me a Hudson noob.

html2haml an entire directory

I didn’t see a way to do this with just using html2haml, so here’s a bash script that will convert an entire directory’s .erb files to .haml: