Good Module, Bad Module01 Sep 2016
You already know how to use modules in Ruby, but are you abusing them? In this post, we’ll take a look at different ways to program with modules and why they may or may not be a great idea.
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.
Have you ever felt like a framework was getting in the way instead of helping you go faster? Maybe you’re stuck on some simple task that would be easy to do manually, but your framework is making you jump through configuration hoops. I end up getting lost in a sea of documentation (or no documentation), and the search for that one magical config key takes just a tad bit too long. It’s a productivity sink, and worse than the time delay it adds to my frustration throughout the day. When I hit
ETOOMUCHFRUSTRATION, then I’m definitely fighting the framework. One way to alleviate this configuration fatigue is by making configuration consistent and composable. That’s what Sprocket’s new “manifest.js” seeks to do.
These days web assets such as JS and CSS aren’t simple text files. Instead, they’re typically minified or come from a complex build process involving compiling or transpiling. For example, CSS can be generated from a SASS file. JS can be compiled from ES6 using Babel. These toolchains make working with assets easier for developers, and make following best practices such as minification much easier. Yet, there’s a problem. What do we do when there’s a error? If there’s an exception in your JS and it’s minified, you will have short variable names which are all on one line and it’s impossible to see where the error comes from. Source maps seek to solve this problem.
Do you have 5 minutes? Do you want to decrease the “over the wire” size of your Rails app by 80%? Sure you do! I added Rack::Deflate to CodeTriage.com, the best way to get started in Open Source, and went from a page size of 85,523 bytes to 15,568 bytes (over the wire). You can verify with this retro looking web based compression tool.