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.

The User Experience Team of One: A Research and Design Survival Guide



I’ve recently made it one of my goals to learn more about UX and design.  To that end, I read a book that was highly recommended by our Grio designers, The User Experience Team of One: A Research and Design Survival Guide, by Lean Buley. The book is written for people who are or want to be UX professionals, with a focus on those who either the only person in their company working on UX or who are in some way UX evangelists in their organizations.  Although the intended audience of the book is UX professionals, there were also number of tips and ideas that a company like Grio can find useful.  On many projects, especially when budgets and time are tight, Grio takes on the role of UX evangelist for our clients.

Parallel Computing with a GPU



Graphic Processor Units are becoming more and more important in recent years and are spreading into many different fields, some of which include: computational finance, defense and intelligence, machine learning, fluid dynamics, structural mechanics, electronic biology, physics, chemistry, numerical analysis and security. There are many reasons why a person should learn how to write code for a GPU. For example, GPU’s have been used to successfully decrypt passwords (add reference) in record time, a 25-GPU cluster is able to crack any standard Windows password (95^8 combinations) in less than 6 hours. Other applications of the GPU include data mining for Bitcoin and also applying machine learning for sentimental analysis on tweets.