Posted by Doug
Mon, 28 Apr 2008 17:57:00 GMT
As my family prepares for our pending Disney trip, I’m thinking about clever ways to take advantage of my wife’s iPhone. One of the things we’ve done is budget the trip based on a few simple categories of expenses. There’s a lot of ways to track expenses to budgets, but I’m particularly happy with how this worked out using Google Documents and the iPhone.
The kicker is that Google Docs are only viewable from the iPhone. My initial hopes of editing a spreadsheet directly from the phone were quashed rudely in a live demo with the wife. Plan B is to use Google Doc’s forms to add individual expenses. This is really a better solution as it’s much easier for my wife to fill out three text fields than to worry about editing a spreadsheet in the right cells.
So the expense sheet of the document is simply the form entries: description, amount, and type. I added help text that listed the valid values I was looking for: food, gas, tickets, junk.
The budget sheet has four rows; one for each budget type. One column has the budgeted amount, and another uses “SUMIF” to sum up all the expense entries if the type matches the budget category. I can then subtract these two to get how much of our budgeted money remains in that category.
I bookmarked the form url on the iPhone for my wife and she can fill it out repeatedly. I also bookmarked the actual spreadsheet. It’s unfortunate that the Google Doc forms don’t let you specify a “thank you” url instead of a thank you message. Anyway, I bookmarked the actual Google Document so we can check the budget remaining easily while out and about. It seems that the iPhone has some trouble changing sheets while viewing Google Documents, so I made the budget sheet the first and default page.
All in all it’s very simple and has a high wife approval factor. Plus, the whole thing took me less than 30 minutes to setup including several “customer approval testing” iterations. Spreadsheets with Google Docs are really fun. Adding in these forms is almost like rapid prototyping custom web apps.
Tags budget, Disney, expenses, finances, Google, iPhone, vacation | 1 comment
Posted by Doug
Tue, 05 Feb 2008 21:35:00 GMT
I’ve just fixed a bug in production that took me more than eight hours to find. When I show you the code, you’ll wonder why it took me so long. I have lots of excuses, but it’s a fairly interesting bug to think about. It shows some of the weaknesses in my usual modus operandi. The code that looks something like this:
class Article
CURRENT="start_publish_on <= #{Date.today} AND stop_publish_on > #{Date.today}"
def self.find_latest
find(:all, :conditions => CURRENT)
end
end
In retrospect the bug is obvious and probably is obvious to you as well. The Article::CURRENT constant is dynamically generated using the date at the time the class is evaluated. With rails in production mode, that could be a long time; certainly more than a day. The conclusion to draw here is to be very, very careful about dynamically generating constant strings. As a rule, I might suggest not doing it.
The most interesting thing about this is you can’t write a test to catch this error. I think that’s the the biggest thing that took me so long to find the error. I tend to be over confident in our test suite. As the new guy to the project, I’m proud of them for how conscientious they are about testing their code. I’m trying to fix this bug by triggering it in a test. Well, it can’t be done. The difference is how the production environment cache classes versus how testing and development does it.
Here’s another tidbit that threw me off the trail for a long time. Our copy editor that is responsible for publishing articles says to fix it she simply back dates the articles by a day. So I spent a lot of time looking for off-by-one errors. I had recently fixed a problem with comparing times to dates and causing off-by-one, so I thought that might be it. As it turns out, this was a red herring. There’s such a tight loop for feature request, implement, deploy that the production environment gets restarted fairly regularly (like nearly every day).
I guess what prompted me to write about this particular bug was what it said about our testing. Clearly automated testing can’t find all the bugs. It also says something about our rapid development. As long as we’re really busy, this bug didn’t bite us. It’s not until our deployment slows down (like a weekend) that it showed up.
Posted in Ruby on Rails, Programming | 1 comment
Posted by Doug
Mon, 21 Jan 2008 13:49:00 GMT
Friday was my last day at the company that won’t let me blog about them. I am very excited to be 100% independent freelancing! This has been a goal of mine for many years and it’s finally come true.
This morning Mark Windholtz is coming over to pair with me on a contract we share. It’s his good for not making me commute on my first day of independence. I’m looking forward to working with him and several other independent developers.
Hopefully now that I’m not under corporate thumbs I’ll be able to blog more about the types of problems I’m seeing and methods for overcoming. I’ve specifically been asked to write an article on my experiences working remotely on a Scrum project.
In addition to writing more, I’m also hoping to be able to contribute back to the open source community. It’s tricky when your family depends on your billable hours to also give your work away. However, I think it’s good balance to work on things my clients require as well as things I’m interested in. At first, this is likely to be helping Phil Hagelberg shape up Emacs for ruby development.
So, there you go. I’m going to be working with some good guys; doing more writing; and working on more open source. Wish me luck!
Tags consulting, emacs, family, Rails, Ruby | 4 comments
