In the first and second post of the series, we covered the very early years of Docker when it was just starting out as well as the series of rapid changes that occurred as it started to stabilize into the platform for containers that we know it for today. This post within the series is the last one, and it will cover the time from the release of Docker 1.7, all the way into the more recent versions of Docker Community Edition (CE) released in 2018.

Much of what the first post in this series covered was the first year or so of Docker’s existence, all the way back in 2014, and while we kept it relevant, a lot has changed in the years following the stable 1.0 release of Docker. This post within the series specifically focuses on what we like to call the “growing pains” phase of Docker, from the first stable 1.0 release to the 1.6.2 release, the last version supported on the update channel of Ubuntu 14.04 LTS. Unlike the first post, which covered what was learned within the first year of using Docker in production, this post will cover the next 3 years of using Docker in production, and what we learned duirng that time.

We have been using Docker at Rediker Software since May of 2014 to manage the development and deployment of some of our applications. This series of blog posts is going to cover how we have used Docker throughout the years, and some of the major changes we have seen during that time.

The latest project that I’m working on is using Azure Web Apps (formerly Azure Web Sites) to serve a Django-backed web application. Azure Web Apps supports Python and Django, but the guides provided do not work out-of-the-box and have obscure bugs that make it difficult to actually deploy your application properly.

After HackUMass, the final hackathon that I attended this school year, I decided that I would do a “year in review” for the hackathons that I attended. I attended my first hackathon this year, HackMIT, and by the end of the year I was able to attend four others (for a total of five). Each one put a new spin on what I thought a hackathon was and inspired me to continue attending hackathons in the future.

In the summer of 2011, GitHub added the ability to transfer repositories between users and organizations. Especially when working with repositories that start off in one user’s account, the ability to transfer repositories is a life saver when it gets a new maintainer or is moved into a central organization. Since the initial release, GitHub has made this considerably easier by creating redirects for Git and GitHub issues traffic. Unfortunately for those who use GitHub pages, they do not automatically redirect GitHub traffic.

One of the biggest issues with older versions of Select2 was the slow performance when working with thousands of options in a <select>. This was primarily because Select2 had to generate a JavaScript object for each element, as well as a DOM element within the dropdown for each possible option. There was a long-standing ticket in the Select2 repository for improving the performance, with a few ideas having come up over the years and some improvements that eventually made their way into the code.

OpenCV 3.0 alpha was released in August, after long delays and time management problems that pushed the project past the projected release date of May 2014. Until it is fully released and pushed into the package managers, OpenCV must be built manually in order to use it in projects. This post will give instructions on how to build and install OpenCV 3, from installing the dependencies to verifying that the Python extensions were correctly installed.

The GNU build system is often used to build projects for easy distribution, independent of the language that is being used. It supports the cross-platform distribution and testing of code, making the installation of software predictable and easy. For Python projects, which are typically distributed using setuptools and pip, working with Autotools as well adds additional complexity to the project, but makes it easier to distribute packages on a larger scale.

Especially for larger jQuery plugins, AMD seems like a reasonable pattern to use when designing and separating the code base into modules, eventually allowing for customized builds to be generated using the r.js compiler. It is especially common in popular plugins for AMD support to be added alongside the standard jQuery plugin registration, which is usually accomplished through an anonymous module and some extra code when the plugin is registered. Doing this for a personal or private project is not difficult, but when working with a public project you cannot always assume that users use AMD or would be willing to switch. Because of this, the project has to be able to handle users without an AMD loader, who just want to use the distributed versions without going through any additional hoops.

With websites such as GitHub and Bitbucket opening up the door to quickly creating and sharing open source projects, there has never been a better time to make your way into the open source community. There are a few things you should know in order to get started working with open source projects, which will be outlined in this post.

Select2 is a jQuery plugin that can be used as a replacement for standard select boxes. It has support for remote data sets, pagination, and infinite scrolling of results. The plugin was initially released in 2012 as an alternative to Chosen that supported remote data sets and has since evolved into a flexible plugin that is configurable using a long list of options.

Last year GitHub added the ability to add more information to tags in your repository through their new releases section. This allows you to draft releases through GitHub and have them automatically tag the master branch when they are released, making the process of tagging a release with notes considerably easier. There are a few things you need to consider when further integrating GitHub into your release process: