Better File Uploads with Shrine: Eager Processing

This is the 7th part of a series of blog posts about Shrine. In this part we will dive deeper into Shrine's eager processing feature, showing some interesting use cases that are possible thanks to its advanced API.

Shrine 3.0 Released

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.

Upcoming Features in Shrine 3.0

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. :tada:

ImageProcessing 1.0 Released

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).

Better File Uploads with Shrine: Direct Uploads

This is the 6th part of a series of blog posts about Shrine. In this part we'll show how to do direct uploads to S3 or your app on the client side, as well as how to handle large uploads.

Better File Uploads with Shrine: Attachment

This is the 3rd part of a series of blog posts about Shrine. In this part I talk about Shrine's high-level interface for attaching uploaded files to model instances.

Better File Uploads with Shrine: Motivation

This is the 1st part of a series of blog posts about Shrine. In this part I talk about the motivation behind creating Shrine, by going over the limitations of existing file attachment libraries.

Shrine meets Transloadit

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.

Improving open-uri

When working on the Shrine library for handling file uploads, in multiple places I needed to be able to download a file from URL. If you know the Ruby standard library well, the solution might be obvious to you: open-uri.

Evaluating (Ruby) Libraries

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—

Shrine 2.0 Released

Shrine is a full-featured library for handling file uploads in Ruby applications. Main advantages of Shrine are good design, loads of flexibility for achieving maximum performance and best user experience for any use case, and advanced features like backgrounding, direct uploads, logging and more.

Asynchronous File Uploads

Accepting file uploads in web applications is very delicate, because all actions for dealing with attachments are slow:

Introducing Shrine – A file upload toolkit

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.

The plugin system of Sequel and Roda

When developing gems, often one of the difficult problems to solve is creating a good ratio between simplicity, convenience and flexibility.

Introduction to Roda

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.

Ode to Sequel

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:

Finder Objects

In Ruby applications it is considered good practice to encapsulate your ActiveRecord querying logic. To achieve this, it’s natural to use ActiveRecord scopes.

Let's keep frontend outside of Ruby

Rails started as an excellent full-stack web framework. It made web development incredibly easy and fast, especially when the asset pipeline came along. However, the JavaScript world has evolved significantly since then, and it is able to take care of itself now.

Require only what you require

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.