All of my long-form thoughts on tech, leadership, product design, and more, collected in chronological order.
In Part 1 in this series, we’ve setup our accounts, installed the required tools we need to deploy our Rails application to a Kubernetes cluster. We’ve even started working on our Rake file that we’re using to document our steps and interface with our cluster. In this post, we’ll expand our Rake file to deploy our application to the cluster. In this walkthrough, we’ll accomplish the following:
In the second part of this series, we have a working Rails application up and running in our cluster with a load balancer to boot. In this post, we’re going to explore how to scale and manage our Rails application running in our cluster.
We’ve all most likely received that dreaded message about our Rails application being “too slow” or even worse “the page won’t load”. In a lot of cases, these issues are difficult to track down because likely it works fine on your development machine or the production server is working perfectly now. So we’re faced with the challenge of tracking down seemingly random bottlenecks that happened in the middle of the night.
When DHH announced Action Text, I really like the idea of making rich text editors easier to use especially when throwing photos in the mix. It’s come up multiple times in projects over the years and it’s never been easy to do. It just so happens, I was working on a project that needed a simple blog and would be perfect match for Action Text. Only problem was it was a Rails 5.2 application and Action Text is really slated for Rails 6, which won’t be released until next year. So I decided to see if I can make it work.
In last week’s Dayton Ruby meetup, Chris Chernesky spoke about how he uses Tmux for his everyday Rails development. It was great talk and ever since the meetup, Tmux has been all the buzz at the Littlelines office. I’ve been using Tmux for a few years and it has become an essential tool for my workflow. Tmux’s window and session management make it a no-brainer for those who live in the terminal.
Hello, my name is Matt and I love working with legacy Rails apps. Ruby on Rails is now over 10 years old. That means there are a lot of (old) Rails applications running out there. At Littlelines, we’ve worked on hundreds of Rails projects. Most of them we build from the ground up, but often we have the opportunity to work with legacy Rails apps - some as old as 2006! More often than not, we discover these apps include many many common mistakes made back in the day and it’s our job to fix them.
To be perfectly honest, this is a subject that I have been ignoring for the longest time. I thought A/B testing was just a buzz word that fancy marketers throw around at unsuspecting clients. Recently, I have been proving my past self wrong and starting to see the light. It first started out with asking myself: “How can I help my clients succeed after their product has launched?” In my programmer’s mind, my first thought was how do we know what works and what doesn’t?
This week I want to show you a simple Rake task I’ve been using for years. It’s one of the very first things I do when starting a new Rails project. I call it reset and it’s purpose is to completely tear down our development environment and rebuild it from scratch. Here is what it looks like:
Do you ever feel like you spend most of your day repairing tests in your Rails app? If you have been building Rails apps as long for as we have, then you know the importance of a robust test suite. Working with a brittle and slow tests can really make the most basic tasks difficult. This is especially true for large Rails apps that have been around for a few years.
UPDATE: I’ve added a new section on stubbing with MiniTest and a few helpful comments to the code samples. MiniTest, as the name suggests, is a small and fast unit testing framework. Shipped with Ruby 1.9, MiniTest supports a complete suite of testing capabilities such as TDD, BDD, mocking, and benchmarking.
