Studying for the Exam

I may not be in class this semester, but it sure does feel like I’m studying for an exam.

That’s what doing the documentation feels like. It reminds me of reviewing the little details you learn over the semester to make sure you understand them and how they relate to the other details. I thought doing documentation would be a matter of writing a few blurbs explaining what we made and how it works. But most of the time has been consulting the source code and my team mate to remind myself how a feature works. And I finish the documentation section with a much better understanding of what we created. It’s been a long time since September, and now I can view the design decisions we made in a new light.

Some examples:

In our JavaScript code, we chose to store Dates as Numbers. We used the number of milliseconds since the UNIX epoch. Why? Because it was accurate and explicit. There’s no way to misinterpret that. We felt that storing them as strings might be a bad idea because there’s no standard. Turns out the ORM we use (Mongoose) ended up storing them as the Double type in MongoDB, which is kind of weird for a whole number. And I’ve since learned that there is indeed a standard for storing a date as a string, the ISO8601 date, and it’s well-supported by mainstream programming languages. And it turns out using strings for dates is actually more developer friendly, since we could then look inside our MongoDB collections and instantly know what time something happened. Oops.

In MongoDB, we chose to convert some of the primary keys for our collections from ObjectIds to Strings (being the string representation of the ObjectId). To be honest, I don’t even remember the exact reason for this, except that it had to do with compatibility. ObjectIds are a BSON type, so there’s no representation of them in JavaScript without using a library to do it. This happens for all of the BSON types in MongoDB that lack JSON equivalents. In retrospect, I would have either used just Strings consistently from the beginning, or put in the effort to consistently use BSON types (by using whatever libraries necessary to do whatever conversions necessary) from the beginning. Right now, we have a combination of Strings for some collections and ObjectIds for others, and when you factor in that the primary keys often act as references due to the somewhat relational nature of our data, this causes me some mental overhead I’d rather not have. Oops.

The problems I’ve described aren’t major issues. They don’t impact the functionality of our creation, they just break standards (which, in our defense, we weren’t familiar with when we started) and cause some issues with maintainability. Luckily, this is CDOT. It’s open source. So the world can clean it up for us. (Thank you, world.) Or maybe we’ll even have some time for some cleanup before the end of the project.

One thing is for sure – I’ve learned a ton working on this project and I have no doubt that the code I write for web apps going forward is going to look a lot better than the code I produced in class before starting this project.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s