I don’t really have a lot for this post – between the limited uses I have for the Facebook and the somewhat surprisingly non-breaking release, there’s not a lot for me to note with this update. The only issues of note I saw had to do with graph API calls for custom audiences. Continue reading »
About a month ago, Bronto released single-send API aggregation for deliveries. Full disclosure – I work for Bronto, but on the apps team, not the main product (by the way, buy Socialite), and I certainly don’t speak for them – everything here is my personal opinion and observations. This was a good change that improved the performance and efficiency of what was 1 of the more expensive API operations. That’s fantastic, but it also impacts the API in ways that Bronto developers are going to need to be aware of. Continue reading »
EDIT – This post was written for mocking a Netty 3.x server. For mocking a Netty 4.0 server, see this post.
While working on an app with my current job, I wound up touching some code that didn’t have any unit tests associated with it. Since we’re a small team (but growing), any automation in testing really helps (not to mention just being a good thing to do). The issue was the code was all in a request handler for a Netty server, which meant I needed a way of either running a Netty server during the Maven build process, or I needed to simulate 1 via some type of mocking library. Ultimately, I settled on the latter. Here’s how I did, and the things I learned along the way.
TechCrunch had 2 articles last month on “Secretly terrible engineers.” Reading the articles makes it sound like there’s a serious problem with how we interview software engineers. Personally, I just don’t see it. Software engineers are like every other profession, the people in it range from terrible to amazing, and the which engineer is which is hardly a secret. Likewise, having just gone through the interview process within the past year, I haven’t really encountered the issues Danny Crichton described. Granted, I wouldn’t interview anywhere near Silicon Valley, so my geography could be affecting what I observed, or I could just be absurdly lucky, but somehow I doubt it. Continue reading »
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?
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 »
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 »
Work anywhere long enough, and you’re going to become the <something> person. From that point on, all questions, advice, etc. on that topic by default go to you. In my experience, this isn’t usually the result of some deliberate action to make a person the <something> “expert”, it’s the result of the work they get assigned and end up doing. The bigger questions are, what are your areas of expertise, what would you like your areas of expertise to be, and what are you doing to make the 2 previous answers line up?
Apparently, there’s some managerial best practice out there that says managers and the employees that work under them should meet once a month 1-on-1. I think the goal is to have some sort of fairly informal time set aside for anything the employee might want to talk about – concerns about management, workplace issues, problems with co-workers, etc. My biggest problem of these things is that I never know just what there is to talk about. Continue reading »