Bundler Bulkheads for Rails on Docker



As part of my exploration of a minimum set of devops tools, I’ve been learning how to stack containers full of Rails apps onto the Docker. There are plenty of examples of how to get started with Rails and Postgres on Docker, even one from the whale’s mouth, as it were. Working from this example, it was pretty clear to me that one of Docker’s major strengths is that it makes it really, really easy to get something running with a minimum of fuss; it took all of about a half day to learn enough Docker to hoist anchor, and even tweak a few things to my liking. One thing kept nagging me about the Docker example, though, and that was a warning from bundler when running docker-compose.

UX Sketches: When to Share and When to Keep Them to Yourself


Sketched wireframes are a catalyst for conversation with developers. During implementation developers continue to communicate with design as questions arise.

Why Sketch?

One of the great things about Grio is that designers and developers often work together on projects. We have lunch together and tell each other jokes while collaborating to solve challenging problems brought to us by our clients. Some projects come with constraints that force the team to be savvy in the way we produce deliverables. As a result, sketches and sketched wireframes are often a suggested deliverable.

Content Delivery in P2P networks



Scalability is a hot topic, especially in Content Delivery Networks (CDN) where scalability, robustness and availability are crucial. A CDN is a system that has the aim to deliver Web content, such as videos, images, and any other type, to end users. Content providers such as media companies need to deliver their content with high availability and high performance, and CDNs offer them the infrastructure to do it. There are different approaches, each one with its advantages and flaws.

Intro to Software Methodologies



Software Engineering is about more than just writing code. It is a complex process that has a lot of moving parts. Requirements gathering, planning, testing, deployment and source control management are just a few of the pieces to the software engineering puzzle. So how do we manage all this complexity? Software methodologies come to the rescue.

Twelve-Factor Apps and Containers



In the past we would often treat a server as a machine which has a variety of
roles. A single server may be responsible for serving web content, email,
processing background jobs, and even hosting a database system. Your application
is really only one of the many things that runs on that machine.

Scaling with a traditional server model is hard. Adding a new machine takes
time to provision. Those machines may store application data directly on their
storage devices, including log files. It becomes more difficult to manage as
your deployment infrastructure grows larger.

A more modern approach is to use many virtual machines, containers, or even
physical machines that serve a single purpose. This architecture will allow an
application to scale horizontally without requiring lots of extra effort. If
your application follows the 12 factor principles then scaling will be much
easier and your app will be ready to run in a modern infrastructure.

12 Factor Apps

The Twelve-Factor App is a set of guidelines which
provide an outline of factors for application architecture which will allow a
modern web application to scale with minimal friction and extra effort.

The Twelve Factors

1. Codebase
One codebase tracked in revision control, many deploys
2. Dependencies
Explicitly declare and isolate dependencies
3. Config
Store config in the environment
4. Backing Services
Treat backing services as attached resources
5. Build, release, run
Strictly separate build and run stages
6. Processes
Execute the app as one or more stateless processes
7. Port binding
Export services via port binding
8. Concurrency
Scale out via the process model
9. Disposability
Maximize robustness with fast startup and graceful shutdown
10. Dev/prod parity
Keep development, staging, and production as similar as possible
11. Logs
Treat logs as event streams
12. Admin processes
Run admin/management tasks as one-off processes


Using containers can be a great way to package, distribute, and run your
12 Factor application.

Why use a container? The analogy frequently used is to compare your application
to the shipping industry. It is complicated to ship objects of varying size and
shape — same with software. Wrapping your application up in a container is
similar to putting all kinds of items into the large metal shipping containers
that are loaded onto ocean freighters. To the ship it doesn’t matter what is
in a container: they just load up with containers and do their thing. The same
goes for running software containers!


Docker is the most popular container solution. It initially built on top of
LXC but now uses its own libcontainer. Docker
focuses on being a standard format for linux-like containers. The Dockerfile
makes it super easy to define a container for your application. This removes
much of the pain typically associated with building a script or image to
provision a new machine or instance for a specific role. Builds happen
incrementally so that the image building process only needs to run the steps
which changed.

A basic Dockerfile for a Ruby on Rails application may look something like

FROM ruby:2.2.2
MKDIR /app
ADD Gemfile Gemfile.lock /app/
RUN bundle install
ADD . /app
CMD bundle exec rails s

Each line can be considered a step. A snapshot image of each step is cached
so that they only need to run if there was a change in the prior step. The
reason we add the Gemfile before the rest of the app is so that your gems
don’t need to be reinstalled for application code changes, only changes to the
Gemfile itself.


This was a brief overview of the ideas that are used for building modern web
applications to ensure their scalability. Lightweight containers can help us
package our applications and their dependencies for easy deployment to cloud
platforms, physical servers, and even developer machines. Containers help
insure dev/prod parity so we can focus on building high-performance software
rather than worrying about the nuances in different environments.

Keep Your App on the Rails with BDD – Part 1



A common way to describe requirements on Agile projects is through the use of user story mapping, and, as a result, user stories. This post will not cover this process, but rather the process of taking an existing set of user stories and leveraging them within our development workflow to ensure that an application is built as accurately and efficiently as possible. To this effect, we will set up tools (Rails, RSpec, Capybara, FactoryGirl, and Guard, to be precise) for implementing our app using behavior-driven development. Structuring our app in this way gives us much better odds of producing robust, low-defect code that delivers on the requirements we set out to build.

Android Tip: adb reverse



I work from all over the place: Home, on public transit, the office, coffee shops, etc.

A big challenge to developing android apps in an environment where my laptop and phone are on different networks (wifi vs. LTE, or laptop tethered through phone) is the inability for my phone to see the API server that is often running locally on my laptop. Here is a simple tip to allow your phone to hit the backend over ADB and a usb cable.

Drinking The Koolixir – Part 2



To get a better handle on Erlang’s behavior, I decided to install a popular set of tools for debugging and performance profiling: EPER. I think it stands for “Erlang PERformance tools”, but it could also mean “Everything Proves Erlang Rules” or “Egrets Prefer to Eat Robots” or really anything for that matter. One thing is for certain, however: getting these tools built and running on Mac OS X was fraught with danger and build errors.