So I ran into an interesting issue a while back doing something on a project at work. I was doing something that involved interacting with files on S3, and had updated the AWS libraries my application was using, but I was running into errors every time I tried to do anything that touched S3. The issue wound up being a dependency conflict between my code and an S3 wrapper utility we wrote around the AWS SDK. While the main project’s AWS SDK was up-to-date, the utility had older versions that were causing the errors. Although I had used Amazon’s BOM and thought that made sure that my AWS libraries were all set to a particular version, the reality was that assurance didn’t spread to other libraries my project pulled in. The solution was simple enough – update the AWS SDK versions in our other internal library, but that did lead to the question, how does one manage dependencies between projects?
Amazon’s DynamoDB service is a managed NoSQL database that promises great speeds that allow it to be “…a great fit for mobile, web, gaming, ad tech, IoT, and many other applications.” That claim is pretty much just a pipe dream. The reality is that DynamoDB is a terrible fit for most applications, and your best bet would be to prefer regular NoSQL databases and manage the machines yourself.
I recently finished up some data aggregation work involving Apache’s Hive, and as a means of getting some MapReduce work off the ground quickly, it’s pretty good. Hive’s goal is to abstract away MapReduce behind basic SQL queries, and on that front it succeeds. The fact that I’m ultimately doing MapReduce jobs is hidden except for what would look like a minor quirk if I didn’t know that was what was going on under the covers. That said, there were a couple of things I noticed both during development and with running the jobs on Amazon’s EMR service that are worth noting.
Campus Navigator updated
So I hadn’t touched Campus Navigator since it was first released in February 2013. Elon University, which I used for my sample implementation, has changed a lot in the nearly 3 years since I published that example, so I spent a little time during the Christmas down period updating that reference implementation, which is now live.
It’s a tale as old as development – you make an application, and now you need to sell it. That means you need to have a demo, and demos require data in there. The dilemma is, what do you do to get that data? Do you have a demo app in a sandboxed environment, do you just add it to your regular production database, do you just take some screenshots of what the app looks like with data from a development environment, or do you do something else entirely? It seems like a stupid thing to worry about, until you’re actually trying to figure it out, then it becomes really important because whatever you decide to do about sample data, you’re going to have to live with forever.
A special thank-you to the people who make good software possible
Since ’tis the season of Thanksgiving, I wanted to offer up a special thank-you to the unsung heroes of any software development project. They’re vital to a good final product, yet most of the time nobody ever realizes the impact they had on getting your software where it is today. So, in the interest of spreading the thanks and love all around, thank you to all the people who aren’t “dev” or “ops” that make all this possible.
The ups and downs of social voting
My friend Warren Myers had an interesting blog post on voting mechanics on various websites, along with “like” mechanic various social networks use (like buttons, +1 buttons, tweet favorites, etc.). I’ve made my feelings on things such as “like” buttons known, so I’m not going to go into those here. Warren raises some good points about the issues with voting on a lot of sites, but there are some places where I think works well that I think are worth noting, along with why they seem to work well. It’s important to note these reasons if you want to make sure your voting mechanic improves your site.
1 of the last things I worked on in my previous job was converting a cron-generated set of emails about server SLA stats into a web service. Early on into this process, I looked at the ELK stack, discussed it with my team lead, and the two of us ultimately came to the conclusion that going that route would be overkill, and that instead we should just write our own utility. That, boys and girls, was a stupid, stupid mistake. Instead of using an existing, free, open-source, project, we decided to re-invent a wheel that other people had already invented, debugged, and was working well for a lot of projects, including bigger ones than what we were intending to do. Continue reading »
Titansgrave – proof that RPGs can make good television
Wil Wheaton’s RPG show, Titansgrave: The Ashes of Valkana, recently finished its first season, and it’s been a lot of fun, not to mention a very well-done story. Normally, you wouldn’t think that an RPG show would make for particularly good television (even if the “television” is airing on YouTube), but it’s a testament to the world-building, story, characters, and players that it worked as well as it did. Continue reading »
My last post about mocking a Netty server using Mockito worked for Netty 3.x, but the changes made in Netty 4.0 broke a lot of that work. After spending some quality time reading up on the changes from 3 to 4 and debugging my testing code, I got my mocked Netty server working with Netty 4.0, and now I’m posting it here in the hopes it helps anyone else who’s looking to mock a current Netty server for their unit tests. Continue reading »