Here’s my story. In order for my wife and I to make it my family’s Thanksgiving dinner, we had rented a car for Saturday, October 8, 2011. We showed up at the rental location (for reference, it was the Bloor St E location, in the Hudson Bay building concourse) at the appointed time, and arrived to chaotic scene. There was a dude at the front of the line yelling at a couple of workers and a huge lineup of people that stretched out of the office. It quickly became apparent that there weren’t any cars, there hadn’t been any cars for quite some time, and that there weren’t going to be any cars anytime soon.
So I guess there’s no reason not to describe my intended project. It was a wine review database. Here’s the use case: you read a wine review in the paper on Wednesday, but when you’re in the liquor store the next day, you can’t remember what you’re interested in buying. Boom! You simply pull out my app on your phone and sort the available reviews by date, find your review, find your wine, and get all drunkified.
Against my better judgement, I bought my wife a Playbook for her birthday. She’s basically married to her BlackBerry, with me being the newcomer to the relationship. And while I’ve become an Apple fanboy over the last year, she’s equally comitted to RIM.
From some experiences at work, I knew that the Playbook was a little flaky. I thought maybe that was me being over-critical of it based on the experience of developing for it – surely RIM can’t hate its users as much as it hates developers. It turns out I was wrong.
It’s now officially been over a month since I last updated. It’s a little disappointing: I’m sort of striving for weekly updates, and I’ve let the project lapse for several weeks. I’ve got the usual excuses: work has picked up, summer is a difficult time to stay inside and code, and, honestly, it’s turned out to be more of a chore than I expected. Today is Labour Day and I spent it napping and hanging out with my wife when I meant to spend at least a few hours coding.
But I’ve been thinking about apps in the background. Specifically, I’m going to write a drinking companion app branded for drunks.ca. I’m going to use the Google Maps stuff I’ve been doing for a client at work and marry it to an iPhone app that will tell you where you can drink, how to get there, and how to get home (that is, it will provide a list of cab phone numbers for your local area). This isn’t something that I expect anyone to pay for, but I think some of my friends could get a kick out of it.
One of the problems I knew I would have with using Rails is that I don’t know a thing about Ruby or Rails. That’s the point – I wanted to learn at least the outlines of the language, and I learn best when I’ve got a project to use as an excuse to learn things. And since my method of learning this stuff has so far been randomly googling stuff as I need it, I was bound to run across different ways of doing things.
For example, when I wanted to create a drop-down select box, I followed these steps:
- create a find_all_whatever method in whatever.rb model class
- initialize a @whatevers variable in the controller using the find_all method
- define a select object on the form that referenced @whatevers
The last time I touched this code I created an entity named Review that referenced a Publication. I’d like to modify Review to also have a Reviewer. (I’ve decided that Publication and Reviewer are for my purposes independent – a Reviewer is a person and a Publication is, well, a publication. While there can be a relationship between them (e.g., Ebert usually writes for the Chicago Sun-Times), that relationship doesn’t always hold for the entirety of a reviewer’s career.
The first thing to do is create the Reviewer entity. For now, reviewers only have a name.
rails generate scaffold Reviewer name:string rake db:migrate
Now that I’ve got a basic app in place, I’d like to start fleshing it out. I’ve veered off from the Ruby primer and will pick stuff up from the web as I need to.
Today I’d like to set up the Review entity. In addition to the normally-entered data fields (date, URL and full text of the review), each review belongs to a publication. I’d like to select the publication from a drop-down list.
I’m finding that writing up my progress documents is more difficult than just coding on my own. There are blind paths I go down that don’t need to be documented. Sometimes I’m not sure if every line of code is needed to illustrate the point that I’m trying to make. And I’m generally not comfortable documenting something until I’ve done it at least twice.
For my first two project-related blog entries, I’ve ended up recreating the application from scratch. This is obviously insane, especially since it’s so easily rectified – this stuff needs to be in source control.
I’ve been using Git with some success locally, so it’s the obvious choice. In my project directory (that is, Projects/reviewdb), I simply did this:
git init git add . git commit -m "Initial commit"
Then a little more work, and
git add . git commit -m "Second commit" git tag project-blog-entry-x
I also make use of the git status, git diff and git log commands to keep track of what’s going on.
Sometimes you read a book and realize that it’s something that you should have read five years ago. Steve Krug’s Don’t Make Me Think is one of those books.
It’s been lying around the office for ages and I finally picked it up while waiting for a machine to boot up. I was immediately impressed. It’s hard to quantify what I learned from the book, but I can say that it crystallized a lot of my thinking on web site design, sort of an “ah, so that’s why we do that” or “that’s why that didn’t seem to work properly”.
The amazing thing is that the book was originally published in 2000 (with a second edition in 2005, which is what I read). The web has moved on, but most of the suggestions and guidelines still hold.
What I would love to see is a similar treatment of mobile app design. I think mobile in 2011 is the equivalent of the web in 2000 – the metaphors are still evolving, and what seems cool now will be embarrassingly outdated in three years (or less, since product cycles are much shorter now). Best practices are still evolving, but someone must have some idea of what the best thing to do right now is.