I spend a lot of time at work on a read-only RESTful API. A little bit of big picture here, the company I work for, Digitalsmiths, builds the data delivery APIs for TMS (they provide most of the scheduling data you see when you “Guide” on your TV remote). This is powered by Digitalsmiths’s own APIs. Basically what happens is that the TMS API is a front-end for our own API. Calls come in, we build queries for our own API, and query said own API, process the results and then return the appropriate data. When the API was first written, the data covered just the US and Canada. As TMS expanded started to cover other countries, that data grew, and with that has come some growing pains. Continue reading »
If “it’s not that important” why are we even bothering at all?
Have you ever been working on something, and had a thought how something should be done, started to talk it out with somebody, only have the phrase “it’s not that important” get used? If it’s not important enough to think about doing well, why are we thinking about doing it at all then?
1 of the things I work on regularly was originally created with a fairly consistent data set. We had a very good idea of what fields were going to be in the data. As a result, we thought we knew where exactly we needed to check for null data, and when we didn’t need to know. Then the data set expanded, and the new data wasn’t nearly as consistent as what we started with. That’s when we realized that we were very much wrong in thinking we knew what needed null checks. Continue reading »
Wedding planning tips from a software developer (part III)
Not to be a shill in this series, but there are vendors that will print addresses on the outer set of wedding invitation envelopes when you place an order (the one the post office uses to deliver mail). Well, at least David’s Bridal does, which is who we happened to use. I’m not going to go so far as to say you should spend money on this kind of thing, just that we decided the convenience was worth it for us, and this is how it played out on our end. Continue reading »
One thing I’ve noticed the more I work on anything is that reusability is everything. Even if you’re slapping together some simple little script that is intended for 1 specific thing to do some piddly little task, odds are you’re going to need to dig it back out and adapt or convert it for something else. In short, you’re always going to need it. So what does this mean to you as you write any sort of code? Continue reading »
Delete or get off the pot
I have to be honest, I’ve never understood part of “soft” deletes that makes it a good idea. You know the basic gist, labeling an action “delete”, and removing it from display, but behind the scenes all you’re really doing is flipping a bit somewhere to tell your application to never show this thing again, as opposed to actually removing it. I suppose it makes sense for when you absolutely, positively, need to retain data (auditing purposes, court orders, etc.), but as far as a general practices go, “delete” should mean “delete”, not “please just don’t show it to me again”. Continue reading »
Recently, I was looking what it would take to notify a Zabbix server whenever an error is encountered in a Python web server. Ultimately (before I realized that Zabbix has log monitoring and that we weren’t going to be installing a Zabbix agent on the server), we went with Zabbix’s log monitoring, but before that I started looking at sending the notification directly from the Python code itself. The quick and dirty lesson here is to thoroughly research the features of monitoring servers (and discuss them with your system admins) before writing code to solve a problem you don’t actually have. The other lesson is here’s how I learned to send notifications directly to Zabbix servers directly from your Python code. Continue reading »
Remember kids
Not a lot of useful, thought out content this time (like every time really, but that’s another point), just a few quick things that I’ve run into over the past few weeks that are worth noting for future reference. Continue reading »
All developers have been in this situation, sitting around, staring at the monitor, trying to make sense of the code staring us back. It’s a tough, miserable period for developers going through this. Specifically, it’s a tough, miserable period for developers that doesn’t have to happen. No matter what the code that does this to you, there’s 1 common, glaring thing in common with the code that does this to developers – there are hardly any, if any at all, comments in the code. In the interest of sparing developers this pain, here are some simple rules about commenting that will reduce developer suffering whenever somebody has to read your code. Continue reading »
I want to tell you a story. It’s a story of failure, heartache, and not a lot of sleep. It’s also set during a college course, so it’s not like lives were totally ruined by the end of this or anything. Continue reading »