day3: ActiveRecord, Pirates, and knowing what's hard is hard.

Appy Days

This is a day 3 reflection for 12 days of coding projects. We also have link to source code and other info on github pages at http://12days.github.io/.

Prior blog about this project and its rationale are:

• Attitude over aptitude - calling out BS, and
• Can you really learn to code in a month?

Day 3 Reflection

step 1 - User Stories

We decided to build a Flickr clone with a pirate theme, hence Pickr (source code). What I learned was not that mind-blowing. Nonetheless it is worth capturing. As usual, we started with user stories.  Something like the following:

• As a user, I want to be able to upload my photos and delete them (paperclip gem)
• As a user, I want to see a livestream of recent uploads
• As a user, I want to see a stream of my friends uploads

Once we understood the expected behavior, and the general idea that it's a photo application, we were ready to build.

step 2 - Survey Existing Tools

First, it's great to leverage existing technology. For example, we used a gem called paperclip for photo upload. It saved us a ton of time to be able to use this technology.

Since we wanted to be able to see friends uploads, we needed to be able to make friends, etc., and that means we needed to authenticate a user. It also meant that for the first time in three days, we would be using a database. Thankfully, there is also a gem called devise, which makes authentication quite easy - it gives you almost on the fly the ability to get users to sign up for an account with password.

step 3 - Mapping Data

So the next step is invariable mapping the object model relationships. In Rails programming (and more generally in the model-view-controller (MVC) paradigm of programming), "model" is the business logic of data object. So for example, in this case, we would have something like the 'user' object, which would have 'photo uploads' and also have 'friends.'

Rails abstracts these types of relationships via Active Record associations. Using this convention, one uses syntax that writes out model relationships in more or less plain English, like user has_many uploads. Or photos belong_to user.

step 4 - have fun
And pirates ... well, we just want to have fun while working. Arrrrggghh!

What we learned

So, using gems like paperclip and devise, we set up the initial authentication and photo upload in no time. Before noon, we had a running app.

Then, even after sketching out database table relationships, we found that it was not very straight-forward to build the many-to-many relationships between users and friends, especially since we wanted to be able to allow users to interact on a permission-based flow of first receiving a request, and then deciding to accept or reject a relationship. It was pretty late in the night when we had all the models hashed out, and it fell to the more experienced among us (Josh) to do most of that coding and validation.

As someone less experienced struggling through the associations and related validations, what I learned was the following:

• As a new web developer, we probably don't spend enough time thinking about database design and data associations. Frameworks like Rails has encouraged this by abstracting database queries. You no longer need to write SQL to look-up data. But, it is still necessary to build the right relationships, meaning one needs to get into the mindset of thinking about how data is stored, and what the relationships between data tables might look like. It's easy for those experienced, and yet very abstract and difficult to handle for those inexperienced.
• Development time is hard to estimate. This is a truism. But, part of the 'hack' of placing a one-day constraint on building a product is to limit the error in estimation. Even so, it seems, we are notoriously bad at estimating our progress and estimated time to finish. We are often mislead by early success (as we were with a skeleton of a working app by noon). The harder pieces happened to come later, and took quite a long time to build.
• Unless you've built it before, it's hard to know what's easy and what's hard. This is a catch-22. I would think that this insight is useful from hiring point of view. Why does one hire a senior developer vs. a junior developer and what does senior mean anyway? It means that the developer has built the very piece of technology you want, and knows exactly how hard it is. It is not to say that senior developer is better ... but just an important observation that knowing what's easy and what's hard is ... hard.

I think these were the main points, and the rest are probably not worth mentioning. If you enjoyed reading this post, you might also enjoy reading about my observations from attending a local meetup event called RailsBridge, and how I started to go down this road of web development after working in business as a MBA grad.

Finally, if you're interested in engaging Josh or me to help you with your web development projects, please feel free to reach out.

Pickr was hoisted up in a day and could use some love. Please fork it and contribute. Once again, you can get all of the posts, lists of projects, and source code links at the project page.