This is the second post in a series about my experience bringing an app from an idea to a deliverable product. You can read about the first part here. This post will be slightly more technical, walking through some of the code and design decisions I made along the way.

If you remember from last time, these are the agreed upon requirements for the first iteration:

Features
- Create a new client
- Create a task
- Mark a task as being highest priority (only one can be highest priority)
- When looking at clients I see client name and top task for client

Implementation
- Clean markup (HTML)
- Normalized CSS (Require CSS file from somewhere else)
- Deploy on local machine

When I see that I need to be able to create clients and tasks, I immediately think of making a client class and a task class. Each of these objects can have the desired behaviors -- the client class looks like this and the task class looks like this. (Here are the tests for the client and task classes.) As you can see from the client tests, I can add a new client, prioritize tasks, and find the highest priority task. A task contains fields for priority, description, and whether or not it has been completed. All that is left is to create a way to keep track of the clients -- how about a client manager (client manager tests)!

Now that I have the code, all I have to do is hook it up to Sinatra, a lightweight web framework that I have some experience with from connecting my tic tac toe game to a browser. The controller has four basic routes, a GET for the homepage and a GET for the task page, and POST routes for each respective page. I can start it up by typing in ruby config.ru and land on a page that looks like this:

Not very attractive (and straight out of nineteen-ninety-seven), so let’s add a CSS file I borrowed from someone:

Still nothing to write home about, but it gets the job done. At this point, I try adding some clients with things for them to do, and voila! It works! I’m ready to demo! Although what I have isn’t very pretty, it’s functional enough to get feedback and direction from my client, which is what I need at this point. I can only speculate about the features or appearance that my client is looking for, so I’d rather not waste any time creating things that aren’t needed (or wanted).

Next time I’ll talk about the first IPM and show how the code evolves afterwards. Look out for more code examples!