DEV Community: Kyle Keesling

Migrating to jsbundling-rails

Kyle Keesling — Sun, 23 Jan 2022 16:00:00 +0000

Now that Webpacker is riding off into the sunset, many of us find ourselves switching over to using one of the solutions offered by jsbuilding-rails.

With the move comes a much simplier javascript story, which is a welcome change for many of us, but making the move can quickly lead to a few gotchas. Below I’ll outline the few that I’ve run into and how you can avoid them so you can ensure a smooth transition to using esbuild.

Gotcha #1 - Importing CSS in your Javascript

This has been one of the most common problems I’ve noticed folks having. Say you’re using a javascript package that also includes CSS assets, esbuild does allow you to import those, but will name the output file the same name as the root javascript file in app/javascript which in most cases will be application.js.

The result of that being two files output to app/assets/build , application.js and application.css - and that’s where the hang-up occurs. If you are also using cssbundling-rails it will by default name it’s output the same thing - application.css, causing a naming collision that will inevitably cause you to bang your head against the wall if you aren’t sure what’s going on.

There are two solutions here, one is renaming the output of your cssbundling-rails file, or renaming your app/javascript/application.js to something else, which in my case is what I did, making it application-esbuild.js. Now, esbuild will process your javascript and CSS and place two files named application-esbuild.js and application-esbuild.css into app/assets/build. Then all you need to do is make sure you include those files in the head of your application.html.erb file:

<!-- app/views/layout/application.html.erb -->

<%= stylesheet_link_tag "application", media: :all, data: { turbo_track: "reload" } %>

<%= stylesheet_link_tag "application-esbuild", media: :all, data: { turbo_track: "reload" } %>
<%= javascript_include_tag "application-esbuild", data: { turbo_track: "reload" } %>

Gotcha #2 - Having Two Javascript Directories

If you’re not starting fresh in Rails 7 there’s good chance you’ve got files in app/assets/javascript. If so you’ll also want to make sure you’ve got sprockets setup to serve those assets. This can be done in app/assets/config/manifest.js, just make sure you’ve got the following line in the config:

// app/assets/config/manifest.js

//= link_tree ../images
//= link_tree ../fonts
//= link_tree ../builds

// this is the key addition, referring to the file app/assets/javascript/application.js
//= link application.js

Of course you could also use link_tree or any of the other methods that sprockets provides in order to properly include the necessary javascript files in app/assets/javascript/, but I think explicitly including just one file helps keep things clean and easy to understand.

Also note that doing this also assumes that you’ve renamed your esbuild output file to application-esbuild.jsas mentioned above, otherwise you’d run into similar naming collision issues that Gotcha #1 covers.

Setting Up Proper Amazon S3 Permissions for ActiveStorage

Kyle Keesling — Tue, 28 Jan 2020 17:43:00 +0000

If you’ve found yourself marveling at how cryptic and impenetrable understanding AWS services, then you are definitely not alone. For much too long have I relied on doing a quick web search and blindly copying and pasting settings and policies, so when I found myself doing it again this week for one of my applications I decided it was time to slow down and actually understand what it was that I was doing.

The Problem

I’m creating a demo environment that needs to be completely separate from our production data, so part of that entails creating its own S3 bucket for use with ActiveStorage. Having not really done this since ActiveStorage was first released I begin DuckDuckGoing (is this even a thing?) for a how-to.

Some perfectly fine write-ups and tutorials popped up on the first page, but I noticed that all of them recommended setting up an IAM User with AmazonS3FullAccess permissions. As soon as I looked at the description for this policy it threw up a big red flag:

AmazonS3FullAccess: Provides full access to all buckets via the AWS Management Console

Full access to all buckets? That’s gonna be a big nope from me.

The Solution

At an absolute minimum the permissions need to be locked down to a single bucket, but ideally we’d only give the app the ability to perform solely the actions that are required for the framework to function properly. Luckily there’s a callout right in the Rails guide that states:

The core features of Active Storage require the following permissions: s3:ListBucket, s3:PutObject, s3:GetObject, and s3:DeleteObject. If you have additional upload options configured such as setting ACLs then additional permissions may be required.

Assuming you already have a bucket created, we just need to create an IAM User so we can generate the access_key_id and secret_access_key necessary to configure the config/storage.yml Amazon service.

Once you have your IAM user created you can use the policy template I’ve built down below as a guide to either create and attach the policy to a group you add your IAM user to, or just attach the policy directly to the user, which is what I did.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::BUCKET_NAME_GOES_HERE/*"
            ]
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::BUCKET_NAME_GOES_HERE"
        }
    ]
}

Final Notes

To their credit, one or two articles said something to the extent of “you may want to do this differently in production”, but let’s be honest, most people don’t read the entire article and/or will not remember to do this, so I find it to be a much better idea to set things up right from the start.

Hopefully this helps you in your ActiveStorage-related endeavors, and if you have any suggestions or comments on how you handle S3 permissions, I’d love to hear them!

Piping Your Honeybadger Events to Basecamp with Zapier

Kyle Keesling — Wed, 03 Jul 2019 13:30:00 +0000

My team has been working on consolidating and improving our communication tools and practices, and as part of that we’ve decided to ween ourselves off of Slack and totally leverage Basecamp for all internal and customer communications.

One of the major things that the team appriciated in Slack was the #dev channel I had created that piped all of our deploys, pull requests, and errors into one central location, allowing everyone to know what’s going on without having to tap someone on the shoulder.

Basecamp provides an easy way, using a chatbot, to feed Github events into a Campfire chat, but getting our application errors in wasn’t quite as straightforward.

We use Honeybadger to track our errors, and while they offer many integrations, Basecamp isn’t one of them — enter Zapier.

How’d I do it?

Zapier made it a very simple process:

create a catch webhook to catch incoming webhooks from Honeybadger
create a POST webhook action that massages the JSON payload from Honeybadger, into the format Basecamp expects for a chatbot

The Result in Basecamp

Using the details and summary elements gives you the ability in Basecamp to create a collapsable post. In the sample above notice the little black right arrow, if you click it you can even get a little sample of the stacktrace. Here’s the value of the contents key I used for the chatbot payload:

<details>
      <summary>
        <strong>💥({xxx __fault__ id}){xxx__message}</strong><br>
        <a href="{xxx __fault__ url}">View in Honeybadger</a>
      </summary>
      <br><hr><br>
      <pre>{xxx __notice__ application_trace}</pre>
    </details>

And here’s a preview of what the expanded preview looks like:

Summary

We are still in the process of fulling moving over to Basecamp, but so far I’ve not missed Slack nearly as much as I thought I would.

In all honestly the things we’ve missed the most from Slack are the GIPHY integration, and the quick access to screen collaboration tools, so if you have any suggestions on how your team addresses those areas, I’d love to hear about it.

An Easier Way to Accommodate Deletion of ActiveStorage Attachments

Kyle Keesling — Mon, 03 Dec 2018 22:45:00 +0000

A Little Background

As I continue to phase out Paperclip in favor of ActiveStorage, I’ve wanted to keep the methods I used to manage these assets as succinct and reusable as possible.

ActiveStorage gives us a dead simple way to save and update assets, but the ability to delete assets independently of the parent record, particularly if you’re using has_many_attached, has been left to each individual app to figure out.

I have stumbled upon a couple of different takes on how to potentially do this, but I’ve not been satisfied with their approaches. Many do not take into account authorization and permissions, which if you’re not careful, allows any user to delete any attachment they choose just by randomly hitting URLs in your application. With that in mind I set out to try and roll my own.

The Approach

Since all attachments are saved as the same object/models types, Attachment and Blob, we can use a common controller to interact and modify with them, regardless of the parent record that it belongs to.

In my case I chose to stick closely to the naming conventions already given to us, so I created a new controller named ActiveStorage::AttachmentsController, and since for now I’m only worried about deleting attachments, we only need one method, delete.

I use Devise for authentication, so we need to make sure that the user is logged in before we let them do anything, which we do with :authenticate_user!.

I also want to make sure that the user has the permissions to modify these attachments, so I check their permissions to see if they can modify the parent record using the authorize_attachment_parent! method. I use CanCanCan in this case, but you can always swap out your auth call to fit whatever method you use. This piece is _ critical _ to ensure that your users aren’t deleting anything they shouldn’t.

The purge_later call will take care of the actual file deletion in your background queue, and will delete the corresponding Blob record.

# app/controllers/active_storage/attachments_controller.rb
    class ActiveStorage::AttachmentsController < ApplicationController
      before_action :authenticate_user!
      before_action :set_attachment, :authorize_attachment_parent!

      def destroy
        @attachment.purge_later
      end

      private

        def set_attachment
          @attachment = ActiveStorage::Attachment.find(params[:id])
          @record = @attachment.record
        end

        def authorize_attachment_parent!
          authorize! :manage, @record
        end
    end

Also be sure to wire this new controller up in your routes:

# config/routes.rb
    scope :active_storage, module: :active_storage, as: :active_storage do
      resources :attachments, only: [:destroy]
    end

It’s also important to update the user interface to remove any reference to the attachment, and in this case I used Rails UJS. The javascript necessary to remove the element from my UI is simple and straightforward:

// app/views/active_storage/attachments/destroy.js.erb
    document.getElementById("<%= dom_id @attachment %>").remove()

The only assumptions made here are that you had the representation of your attachment wrapped in a div with ID of attachment_#{id}, which you can easily render using Rails handy dom_id method.

You can now use the following markup next all of your attachments to allow for easy deletion:

link_to "Delete", active_storage_attachment_path(attachment),
             method: :delete, remote: :true,
             data: { confirm: "Are you sure you wanna this?" }

Wrapping it Up

This approach is relatively simple, and relies heavily on the tools and features that Rails provides to us.

In my case I’m also leveraging a common partial to render thumbnails, metadata, and links for attachments, making it dead simple to add attachments to any model I choose to in the future.

As always things evolve over time, and while I’d like ot think I’m perfect I’m sure there are ways to improve this code, so if you have any suggestions or improvements I’d love to hear them.

Migrating Your Assets from Paperclip to ActiveStorage

Kyle Keesling — Thu, 26 Apr 2018 08:00:00 +0000

With the release of Rails 5.2 there is now a native, built in way to handle asset uploads and management called ActiveStorage, making the need to use gems like Paperclip, Carrierwave, or Fog, with Paperclip going so far as writing a migration guide; implying that it may not be long for this world.

To be honest I didn’t even know that Paperclip had written a migration guide until I started writing this post, and while it’s fairly comprehensive, it doesn’t do what in my mind is one of the most important tasks - migrating the files on the remote host.

With that in mind I’ve used the following rake tasks with great success to move assets for many of my models.

There are two flavors here, migrating assets while changing their name, or just plain old moving.

Moving an Asset While Changing Its Name

In my case I had a User class with a Paperclip attachment called headshot. I never really liked that we used the term headshot, so this was the perfect opportunity to change it to avatar.

This scenario is surprisingly easier due and the fact that we don’t have to worry about a naming collision (headshot to avatar), which means we can still use paperclip’s built in URL helpers in our rake task.

Just remember to leave your Paperclip declarations on your model until after you run your rake task.

Moving an Asset As-is

In reality, you’ll likely want to keep the same name, which requires us to get a little more crafty. In my case I have an Organization class with a logo. We wanted to keep using that term, but in order to do so, we have to remove the Paperclip declarations from the model, otherwise would couldn’t refer to all the new ActiveStorage goodness.

To get around this we just need to utilize the actual asset URL in our rake task.

This rake task is pretty straightforward, but what got a little sticky was dealing with filename extensions, mainly the fact that sometimes uploaded files don’t have them, so that’s what lines 5 & 6 are about.

A Few Considerations

There are a few tradeoffs that you’ll have to consider if you use this method though.

The first advantage that you get is that these tasks can be ran from any server, including your dev environment, even before you deploy any actual code.

In my case I ran the rake tasks on my laptop, and as soon as the updated code was deployed to the server, the assets were already there. The only thing left to do is to remove the old assets when you’re ready, but they are still there in the event you need to rollback your deploy.

The biggest downside to this method is simply the fact that you are duplicating all of your assets temporarily. In my app I was able to move thousands of image files in a matter of hours, but if you have millions of records, or very large assets, this method might not be your best option.

Bootstrap 3 Responsive Button Groups

Kyle Keesling — Wed, 12 Aug 2015 17:28:01 +0000

Ever been disappointed/pissed off with how Bootstrap handles (read ignores) button formatting on smaller screens? Check this out:

Makes this:

Look like this:

Permalink ∞