For most of us, a local development server proves to be good enough to get our day to day coding done. Even mobile device displays can be tested quite well on Chrome (or other browsers) using built-in developer tools. There are times though, where using a real device is better or even necessary.

This is a walkthrough of lessons learned from hosting a project on Elastic Beanstalk using Docker Containers as deployment strategy. I’ll link to documentation as much as possible and avoid explaining Docker/AWS basic concepts to try keep things short.

After migrating my website/blog to Jekyll on GitHub pages I was left with this lingering feeling: The theme I was using felt too “stock/off-the-shelf” even after a few color tweaks. I gave customizing the theme a try instead of coding it from scratch and learned a thing or two along the way.

Ideas pop in and out of existence unexpectedly, that’s my experience at least. This one professor from college always comes to mind when an idea is lost because I failed to write it down. He spent a few classes discussing with us some productivity/time management methods like Get Things Done, Eisenhower Matrix and others.

This is a bit of an update on the latest version of Martilla. The feature introduced that I’m more excited about is the ability to limit the retention of your backups.

Headless tests are necessary for CI environments and very useful for unobtrusive local development. No need to ditch the driver that directly controls the browser though, there’s lots of debugging value in being able to switch between both modes.

Martilla is a project I’ve been working on recently. It’s a CLI tool to help automate database backups. It’s main objectives are to remain modular, configurable and simple to understand.

Instead of hosting this site myself any longer I’ve finally decided to move over to GitHub pages. This probably isn’t an interesting blog post for anyone other than myself. I just wanted it out there for the record.

Activek8s is a gem that relies on certain conventions to provide a thorough Kubernetes integration on a set of Rake tasks. The gem is a byproduct of a project that makes use of Kubernetes to orchestrate our services and other tools (Redis, CI/CD, logging, etc). This is not the absolute truth, it’s only a solution that worked for our team and we open sourced on GitHub.

This is a “walkthrough cheatsheet” from my initial experimenting with AKS (Azure Kubernetes Service). Everything here can be run using Azure’s Free Account trial.

It’s no secret that Kubernetes has seen a booming interest in the past year or two. It’s also known that its learning curve is steep and its complexity remains relatively high. Because of this I’ve been interested in striking a simpler alternative in Docker Swarm for a while now. The following is my experiment for setting up a Swarm cluster that is able to publish different services using Let’s Encrypt SSL certificates with ease.

So far this year has been surreal & hectic to say the least, and we’re basically halfway through. I started a new job late last year, which I expected to be challenging for plenty of reasons. Arguably the most important one: I was going to support a large codebase built in Ruby (on Rails).

This post will break down an example setup to deploy multiple HTTP services secured with TLS using docker-compose and an NGINX reverse proxy. I already had an SSL certificate for this website and figured my experiments could benefit from HTTPS, so here we are.

Open-source software is a beautiful thing. Whether you’re coding, documenting, giving feedback, etc. there is something bigger than you out there. We live in a time where we can ride the whale wave together, regardless of where you happen to live.

Something big went down last Tuesday, at least for me. Not only @mattfgl gave an amazing talk on kubernetes but I got to step in front of a room packed with fellow Docker enthusiasts to give my first lightning talk ever, on my Dockerized tests in a dockerized Jenkins blog post. Here are the updated slides