I’ve just released version 3.0 of Shrine, a gem for handling file attachments in Ruby applications. It’s been months of hard work, but I feel it’s finally ready.
The last couple of months I’ve been working hard to prepare for Shrine 3.0, which I expect will be released by the end of October. A lot of work has gone into it, including some big but much needed rewrites. I feel the API has stabilized now, so I thought it would be a good time to share with your some of the new features and improvements that will be coming to 3.0.
This has been published on the Citrusbyte blog.
The ImageProcessing gem has just reached version 1.0, and I thought this would be a good opportunity to write an article about it. For those who don’t know, ImageProcessing is a wrapper gem that provides common image processing functionality needed when accepting image uploads from users (most notably resizing images).
Before talking about the implementation, I first want to explain where and why I needed partial downloads.
When I’m building web applications, a requirement that almost always comes up is that the app needs to accept file uploads. It can be an app with users that have profile images, posts that have cover photos and some additional documents attached, or whole galleries where people can upload many photos or videos.
Whenever we need to solve a problem in our application, if this problem is common enough, chances are there are already libraries out there which can help us with that. Great, now we just pick the library with most GitHub stars, and start integrating it into our project. So, the next thing—
Accepting file uploads in web applications is very delicate, because all actions for dealing with attachments are slow:
I’m really excited about this. I’ve just released Shrine, a new solution for handling file uploads in Ruby applications. It was heavily inspired by Refile, most notably its idea of backends. However, unlike Refile, it is designed primarily for upfront processing (as opposed to on-the-fly). It’s also inspired by CarrierWave’s idea of uploaders.
When developing gems, often one of the difficult problems to solve is creating a good ratio between simplicity, convenience and flexibility.
When I decided that I want to move away from Rails, I have investigated and experimented with a lot of other Ruby web frameworks (Sinatra, Grape and Lotus), but this one really stood out in every regard, and it became my framework of choice. That’s why I want to show it to you.
I’ve used and loved ActiveRecord for most of my Ruby life. While I was in Rails, I couldn’t imagine why I would want to use anything else. When I moved away from Rails, I was still using ActiveRecord at first, but some things started to bother me:
In Ruby applications it is considered good practice to encapsulate your ActiveRecord querying logic. To achieve this, it’s natural to use ActiveRecord scopes.
Writing code which reveals intention is one of the most important things to me. Some time ago, I read “5 Reasons to Avoid Bundler.require” by Myron Marston, which talks about how Rails requires all of your gems at startup and some of the downsides of that approach. After reading it, I started noticing how many gems, when they need to require their parts, use a similar approach as Rails by just requiring everything in one place.