Ruby and Rails don’t have a reputation of being memory-friendly. This comes with a trade-off of being a higher level language that tends to be more developer-friendly. For me, it works. I’m content knowing I might have to pay more to scale a large application knowing I can write it in a language I enjoy.

Turns out…Ruby’s not the memory hog I’d previously thought. After some research and experimentation, I’ve found jemalloc to offer significant memory savings while at least preserving performance, if not improving it as well.

A few articles ago, I wrote about how to monitor Sidekiq retries using AWS Lambda. Retries are often the first indication of an issue if your application does a lot of background work.

As Bark continues to grow, we became interested in how the number of jobs enqueued and retrying trended over time. Using AWS Lambda to post this data to CloudWatch, we were able to visualize this data over time.

Every Sunday Bark sends parents a weekly recap of their children’s activity online. The first iteration was pretty basic, things like “Your children sent X number of messages this past week” and “You have 10 messages to review”. But we wanted to go deeper…

Using PhantomJS, we were able to take screenshots of a modified version of the application’s child analytics page and include the image in the email sent to the parent. The email now contains everything the parent can see from the application, all without leaving their inbox.

It’s no mystery I’m a Sidekiq fan – my background job processing library of choice for any non-trivial applications. My favorite feature of Sidekiq has to be retries. By default, failed jobs will retry 25 times over the course of 21 days.

As a remote company, we use Slack to stay in touch with everyone AND to manage/monitor our infrastructure (hello #chatops). We can deploy from Slack (we don’t generally, we have full CI) and be notified of infrastructure and application errors.

I’ve spent the majority of my career working for companies building products I either wasn’t interested in, or wasn’t the target user. They were jobs. In exchange for my 40 hours, they supplied me a paycheck. As a result, I went home at the end of the day and was able to disconnect.

Fast forward almost 15 years and I’m on the opposite end of the spectrum – I build a product I want to exist, a parent like me is the target user and furthermore, I have equity in the company.

Contrary to popular opinion, I’m a fan of Turbolinks. I leave it enabled in all my Rails applications. Most of the negative opinions I hear relate to it “breaking” third-party jQuery plugins. I say “breaking” because it’s not really changing the plugin’s behavior – just requires the plugin to be initialized differently.

As gem authors, one of the ways we can provide important information to users of our gems is through post-install messages. Let’s explore what they are, how to set them up, what to include and when to use them.

In a previous article, I documented the upcoming public API changes slated for Sucker Punch v2. Because of a poor initial design, these API changes are backwards incompatible.

When I published the previous article, Mike Perham rightly pointed out the opportunity to support the previous versions’s API through an opt-in module. I was hesitant to include support for the old syntax by default, but allowing a developer to require a file to get the old syntax made complete sense to me. My intent was never to abandon existing Sucker Punch users, but it felt necessary for the success of the project going forward.

Sucker Punch was created because I had a need for background processing without a separate worker. But I also figured others did too, given that adding a worker dyno on Heroku was $35. For hobby apps, this was a significant cost.

Having gotten familiar with Celluloid from my work on Sidekiq, I knew Celluloid had all the pieces to puzzle to make this easier. In fact, one of the earliest incarnations of Sucker Punch wasn’t a gem at all, just some Ruby classes implementing the pieces of Celluloid necessary to put together a background processing queue.

In the recent series on transitioning to microservices, I detailed a path to move a large legacy Rails monolith to a cluster of a dozen microservices. But not everyone starts out with a legacy monolith. In fact, given Rails popularity amongst startups, it’s likely most Rails applications don’t live to see 4+ years in production. So what if we don’t have a huge monolith on our hands? Are microservices still out of the question?

Sadly, the answer is, “it depends”. The “depends” part is specific to your context. While microservices may seem like the right move for you and your application, it’s also possible it could cause a mess if not done carefully.