Data data everywhere

I learned basic SQL my sophomore year of college (late 2003 if you’re keeping score). I didn’t learn Python until the summer of 2006 during an internship at IBM Watson Research Labs. As someone who obsessively collects data, my standard approach had been to collect the data and then dump it to a yaml file. Once the data I collected was big enough, I realized I needed to be smarter about storage, and ever since then, I’ve been frustrated by the integration of SQL and Python.

I found what appears to be my first usage of the sqlite3 library in some code from Saturday, January 23, 2016, and it’s practically the the same as what I use today: A class that wraps both the sqlite3.Connection and sqlite3.Cursor and gives me helper methods so that I don’t have to think about what the difference is between the two things.

In 2019, I expanded that for my ROS Metrics project, resulting in a class called MetricDB, which is more or less the same wrapper but with spoonfuls upon spoonfuls of syntactic sugar laid on top to make queries easier.

And now, I’ve spent so much time using the same database structure for side projects, I decided to take the time to package it all up neatly, now under the name MetroDB. Featuring a couple Python skills that I hadn’t touched before.

• Packaging by pip
• Sphynx Documentation on readthedocs.org
• Automatically run Python tests with Travis CI.
• Automatic test coverage checks

I liked that it was a relatively short walk to get from metric_db to metro_db and it extends my “Metro” branding from MetroRobots. (speaking of websites in bad need of a modern update). And nearly a decade after I created the brand, I feel relatively confident to say that it is the only robotics company in business today that was named after a baseball team.