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?