Facebook released version 2.3 of their Graph API 1 week ago, on March 25. Earlier this week, after encountering errors claiming I was using a deprecated version of the API (a bug in Facebook that I’m pretty sure is long since fixed), I tried switching to the latest API version to see if that solved the problem. It did, but exposed a couple of things missing from their changelog, because what’s Facebook development without incomplete documentation?
Pretty much everybody in the developed world (and most of the developing world) interacts with Facebook as an application. Not many people have to actually deal with Facebook from an API level. I’ve spent a few months writing some code that tries to perform a few simple tasks on Facebook, and it’s been rough. Here’s a random collection of things I’ve learned, gotchas, and other points worth noting in the process. As a brief point of reference, most of my interaction with Facebook comes from the server-side code, written in Java, although I’ve played around with Facebook’s JavaScript SDK as well.
1 of the last projects I worked on at my previous job involved aggregating, storing, and querying log data into and from Elasticsearch (yes, I know that Logstash does that – and in reality I should have gone that route). That, along with some lookups on the data outside of the code, gave me a chance to start playing with Elasticsearch. After my brief experience with it, I can tell you there’s a lot of power in Elasticsesarch, but it’s going to take you a surprisingly longer to figure out how to tap it than you would expect. Continue reading »
On August 1, 2014, Facebook went down. It came back after a few hours or less, but it was a visible reminder of their (now-former) motto of “Move fast and break things.” I made a joke about the issue, but I appreciate the philosophy, even if Facebook’s since tried to move away from it. I think it has a lot to do with their new model of “Move fast with stable infrastructure.” In fact, I think moving fast and breaking things is how they got their stable infrastructure. Continue reading »
For the first half of the summer, I took the online Functional Programming Principles in Scala course on Coursera. I should probably point out that I didn’t take the $50 official I’d heard good things about the language, mostly from Dick Wall on Java Posse podcasts, and it seemed like a good way to try functional programming again after a brief, rather unpleasant, introduction to Lisp in college. Overall, my main goals were to a) re-acquaint myself with functional programming and b) get a basic, can-start-on-some-code-now understanding of Scala.
Read any technical blog post that gives a deep dive into fixing any type of issue, and 1 thing you notice fairly quickly is that going through the logs is an important part of the process. Debug issues in any application you’re working on, and 1 thing you notice fairly quickly is whether or not your logs are any good. It’s a distinction that can make all the difference when the question of “What the deuce just happened?” rears its ugly head. Better logging can make your life easier, largely by telling you all about the state of what’s going on in your code so you can spend your time actually fixing and updating things instead of running down just what is going on in the first place.
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 »
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 »
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 »