We all know that modern applications can get very complex, very quickly. Because of that, I’ve been trying to add more automation to my daily life in general, as I know I’m human and will eventually mess up due to being distracted, tired, or something else.

One of the first things I did while on my automation journey was to figure out a way to automate the creation of cloud resources. In order to accomplish that, I became proficient at using Infrastructure as Code (IaC) tools such as Terraform and AWS CloudFormation, among others.

After that, the next logical step was to integrate that knowledge in infrastructure provisioning into the CI/CD pipelines, since I have (or try to have) CI/CD pipelines setup in every project I’m involved in. In this post, I will present the benefits of doing just that and will demonstrate it using a specific Terraform + CircleCI example.

This article tells the story of our experience implementing a shift in approach during the Daily Scrum meeting. We went from a typical approach centered on each individual to one centered on each story of the Sprint Backlog. The idea for such a shift was inspired by a Jeff Shuterland paper, one of those many great writings Jeff has produced throughout his career.

The goal is to briefly explain why and how the change was adopted; the strengths and weaknesses we observed; and feedback we were able to obtain upon having adopted such a shift in approach. But, before launching into explanation, it is important to provide you with the context of this experience.

A couple of months ago, I came to realize I might actually like DevOps. I wasn’t sure what to do, so I talked to the VP of Engineering at WyeWorks. Following that conversation, we found a way for me to work in a DevOps position for several months and try it out.

I left the project I was working on at that time and was given a month to learn some basic stuff so that I would be somewhat useful in a DevOps job. And that’s exactly what I did. Beginning January 2nd of this year, I’ve been reading up on and doing DevOps work 5 days a week, 7 hours a day.

In this post, I’m going to discuss my perspective on IAC (Infrastructure as Code), what problems it solves, and how it can be implemented. I will also share some resources for further learning, as well as briefly present Terraform, an IAC tool.

In the project I’m working on, I was given the task of investigating how to integrate Vue.js with our existing Rails app. So I started reading the official guide, watching tutorials and reading various posts until I finally got a fully working Vue component.

Finally it was time to write some tests, but unfortunately, the Webpacker gem doesn’t include testing configuration, so I had to do it on my own.

To my surprise, I found that there wasn’t much documentation on how to do the setup. So I figured I’d make this post to share with you how I managed to eventually get it working.

There was a time when I found myself constantly switching between my personal and work computers, and it was really annoying. After some time switching back and forth, I decided to use just one computer.

After settling on the single computer approach, what irritated me most was having to remember to switch my Git username, email, and SSH keys when moving from a work repository to a personal repository and vice versa. I would frequently forget to do that and, every now and then, I would find work commits tagged with my personal email or the other way around.

At work, most of the repositories are private, but at home most of my work is public, which means that my work email became public, and I didn’t like that. Hence, in this post I will share one way you can go about forgetting to switch back and forth and let the computer do it automatically for you.

Recently, I have been investing some time learning VueJS and I found that it is a very interesting framework to play around with. In fact, I have been working on a new project prototype for the last few days and wanted to show it to some people, so I wanted to publish it somewhere in the Internet.

I decided to deploy the project on Heroku so I started to research what is the best way to do it. To my surprise, I did not find much about it apart from a few posts like Quick-n-clean way to deploy Vue + Webpack apps on Heroku and Easily deploy a Vue + Webpack App to Heroku in 5 Steps. Nevertheless, I ended up with a different setup and this is the topic of this post.

If you have been developing software for some time you have probably noticed that there are lots of things that can go wrong, no matter how hard you try there is always something you might forget because after all, we are only humans doing an extremely difficult task: Telling a computer what to do.

In this post I will expose some of the git-hooks we use in some projects here at WyeWorks to make developers life easier by preventing bad commits to even leave their computers. I will cover linting, tests and commit formating use cases.

The 2.5 series of Ruby first saw the light on October 10th, as part of the first preview release toward Ruby 2.5.0. Just a couple of months later, on Christmas day (a popular release date on the Ruby releases calendar), the first stable version of the series was born.

Reflected on the release notes, we can find a whole bunch of features, changes and performance improvements which found their way to the final release. On this post, I’d like to do a quick rundown of the features that I’ve found most interesting.

In this article, we will discuss how different (or similar) it is to use Glimmer as compared with React. Glimmer is a new library in the Ember ecosystem, which was released in March. Since the creation of this project, the Ember team has been experimenting with a new components API and the result of this work is expected to gradually be integrated into Ember itself in the future.

To some extent, Glimmer is comparable with React because the scope of both libraries is very similar: UI components for the web. However, let’s take a look at some examples to highlight some of the similarities, as well as the differences.

At WyeWorks, we are passionate about improving on what we do. Indeed, our software development process emphasizes continuous improvement. To implement this, we use Scrum’s proposed framework. This article intends to explain our experience conducting Sprint Retrospectives with teams located across different parts of the world, in this particular case members working in Spain, Germany, and Uruguay.

On several occasions, we have done retrospectives with remote team members, trying several techniques such as paper and post-its and some digital solutions. This year, however, we performed an experiment from June up to the current day that we found we preferred to the previous ones. That’s why we want to share it with you.