Grio and Angular 2: Are They Ready for Each Other?

by

At Grio, we love Angular.  By my estimation we currently use it for at least half of our front-end web application code.  And I in particular have affection for it, so I greeted the recent release of Angular2 with some interest and trepidation.

The release was just an event, though. The framework had already been around long enough for me to fret about it for some time.

Using Ansible for provisioning

by

Due to the recent increase of personnel at Grio, it emerged the need of having an automated way of setting up new employers’ machines.

Starting with a brand new machine is always a pain for a developer, and setting it takes at least a couple of days if not the whole first week, resulting in big waste of valuable time. Besides, when a developer starts on a new technology it is not always clear which tools are suggested and which ones the rest of the team are using. Therefore, I have been asked to work as a side project on a way to solve such issues.

Release Practices at Grio

by

In a previous blog post, I covered the “textbook” definition of continuous integration, along with a handful of tools and practices that fulfill or help to fulfill said definition. These tools and practices include breaking up your app into components (e.g. front-end and back-end, or, for much larger projects, using microservices), utilizing “watch” utilities locally to iteratively run tests, and choosing test-oriented frameworks (e.g. Rails, Django, Grails, etc.). However, I didn’t talk much about any specific continuous integration setup, nor some of the third-party services that go together to make an efficient release process. I also didn’t talk much about how continuous integration fits into the larger cycle of deployment and release management. I aim to cover some of those topics here, and fill in the larger picture of how CI helps to ensure code quality and stability in a software project.

Bundler Bulkheads for Rails on Docker

by

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.

Intro to Software Methodologies

by

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.

Keep Your App on the Rails with BDD – Part 1

by

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.

Drinking The Koolixir – Part 2

by

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.