Here’s the setup: You are a web server named Puma. You need to accept incoming connections and give them to your thread pool, but before we can get that far, you’ll have to make sure all of the request’s packets have been received so that it’s ready to be passed to a Rack app. This sounds like the job for a Reactor!
Today I have an unusual proposition for you. I’m spending a bunch of time to try to get Beto elected to Texas Senate, so I’ve not been able to write as much technical content. Rather than slow down on my door knocking, I’m looking to pick up the pace, and I want you to do it with me. Starting today, I’m offering anyone who phone banks or “block walks” (knocks on doors) the opportunity to win some of my technical time. Here’s how it’s going to work.
Rails applications that use ActiveRecord objects in their cache may experience an issue where the entries cannot be invalidated if all of these conditions are true:
You might know rubocop as the linter that helps enforce your code styles, but did you know you can use it to make your code faster? In this post, we’ll look at static performance analysis and then at the end there’s a video of me live coding a PR that introduces a new performance cop to rubocop.
All previously released versions of Sprockets, the software that powers the Rails asset pipeline, contain a directory traversal vulnerability. This vulnerability has been assigned CVE-2018-3760.
Rails 5.2 was just released last month with a major new feature: Active Storage. Active Storage provides file uploads and attachments for Active Record models with a variety of backing services (like AWS S3). While libraries like Paperclip exist to do similar work, this is the first time that such a feature has been shipped with Rails. At Heroku, we consider cloud storage a best practice, so we’ve ensured that it works on our platform. In this post, we’ll share how we prepared for the release of Rails 5.2, and how you can deploy an app today using the new Active Storage functionality.
Before you can understand how to build a parser using parslet, you need to understand why you might want to. In my case I have a library called rundoc it allows anyone to write documentation that can be “run”. For example, someone might write docs that had this:
When it comes to life events, there’s none that require quite as much “gear” as having a new baby. I recently had my second kid and it’s given me some time to think about the products that truly bring me joy versus those that are merely necessary. There’s plenty of baby product recommendation lists out there, this one is mine.
After this holiday season many of us would like to lose a little weight, page weight that is. In my app CodeTriage I make extensive use of SVG elements for images, the logo, and icons. Until recently, I’ve been rendering the SVG elements directly in the HTML. This was the easiest thing to do. As you might guess by my intro sentence, I’ve been working on decreasing page weight by removing SVG elements from the HTML. How well did it work? Before making changes the homepage was 14kb (77kb unzipped). After the change, the homepage is 6kb (30kb unzipped). That’s a 57% reduction in “over the wire” bytes per page load. What exactly did I do, and what were the trade-offs I made to get to a smaller page? Let’s look at how I was previously using SVG.
When I used my first ORM, I wondered “why didn’t they include a random() method?” It seemed like such an easy thing to add. While there are many reasons you may want to pull a record out of your database at random, you shouldn’t be using SQL’s ORDER BY RANDOM() unless you’ll only be randomizing a limited number of records. In this post, we’ll examine how such a simple looking SQL operator can cause a lot of performance pain, and a few different techniques we can use to fix it.
