We love him and gather food for him to eat.
Monthly Archives: August 2009
Tasty comfort food
I’m a lucky man. Not only do I get to learn about a new comfort foods from my partner, she’s a phenomenal cook too. Last night we had fishcakes, mac and cheese and green beans. Admittedly the mac and cheese was from a box, but it at least it was organic. We got a new camera, so I’ve been a bit trigger happy with it. Enjoy some macros of the three dishes all plated up!
Wonderful Bike Lane Signs
My sweetie and I were on our way out to the California Academy of Sciences and took the good ol’ wiggle up to Fell to get to the pan handle. Just before Divisadero on Fell there was the well known ‘bike lane’ symbol. But someone had added a smile and antlers. It made my day.
iTunes iMovie on Lenovo’s new Media Center PC
Flipping through a recent blog post, I clicked through to Lenovo’s new media center PC, the Q700. Ho hum, another small form factor desktop. Wait…those icons on the features page look familure. Hey! Those are the iTunes (slight color tweak) and iMovie icons (verbatim)!
Here’s the two icons followed by a screenshot with blow up of the icons on the page:
I’m not getting into any sort of “Apple is better than Windows” or “Linus Rulez”. However, this is just sloppy!
Don’t just commit, commit intelligently
If you’re a developer, you probably use a revision control software. For both work and personal projects, I use SVN, which is great. At work we use SVN as a way of releasing new features and bug fixes to our web site. We can push a specific a revision as well as roll back to a previous revision, thus leveraging revision control to be our release software for a 4 server load balanced site. SVN + rsync + shell scripting = : )
Recently at work we were doing a bunch of little changes all over the site, including having the designers do a bunch of css and DOM tweak as well. The time came to commit all of the changes. Instead of doing the commit at the root of the repository and stuff all the changed files in at once, I enforced a multiple granular commits of the functionally changed files. Each commit had a relevant comment.
Enter a week later. We hadn’t done sufficient regression testing and a visual element was broken in ie6. Which of the thousands of new lines we committed and pushed was the culprit? Had we done one massive commit we would have been screwed. However, we were able to cull over the commites via our trac instance (awesome!) and review the comments. In this case we couldn’t actually find the exact commit that caused ie6 to break, but we were able to step through our dev instance of the site, slowly adding each revision to it until it broke in ie6.
The moral of the story is that, much like backup, revision software is only as good as it’s end user. Think of every commit as chunk of functional related code. Think of every comment for these commits needing to solve the problem for another developer who has no idea what the code was and they’re up at 2am trying to figure WTF is up with the site. For every commit, where possible, you should also site a bug number so that should the bug crop up again, it’s easy to cross reference the “fix” with the code.