It has been a long time since my last post, almost 2 1/2 years ago. Where does the time go. So many life changes. So many things to talk about. and

I am hoping it motivates me to start writing on a regular cadence. Writing is a great way to clear ones head, to work out thoughts and ideas.

I’m looking forward it…

I moved over the posts I had under WordPress and have noticed some weird formatting and layout. Give me some time over the next couple weeks to fix up those conversion errors.

Many people I followed on Twitter have moved on to other platforms.

I decided to explore the world beyond Twitter. You can find me in various places:

Here of course, with plans to write more.

I finally created a Mastodon account over on ruby.social. I am pretty sure I am the last holdout to create on. :-) Follow me over there…

I started using the Micro.blog account I’ve had some Manton created the service. I thought I started posting over there but it appears I never did. Thanks to Manton for getting me going again. I plan to write some smaller posts, useful notes or other short-form there. I can be found at rbazinet.micro.blog.

If I am missing some great community somewhere else, please let me know.

What to write about?

Is writing about Ruby on Rails and how to do this or that even relevant any long? Does anyone still look to blogs for solutions to problems we might be facing? I don’t know. I solve problems this way though but maybe I am the rare case.

Is it time I start writing more about the entrepreneurial side of what I enjoy doing? I’m not sure.

I am here and still existing.

Problem

I was in the process of testing some validation changes I implemented and realized errors were not being displayed. I went through the typical debug scenarios and found that errors were being returned but just not displayed. The code consists of just trying to create a user:

def create
  @user = User.new(user_params)
  if @user.save
    redirect_to root_path, notice: "User created successfully"
  else
    render :new
  end
end

When creating a user, the new form rendered but errors were not displayed.

Solution

The reason the messages were not being displayed is because of Turbo and Rails UJS conflicting. Solving the problem can be done in one of two ways:

1. It appears Turbo expects form submissions to redirect to a new location. When there is an error, we are staying on the same page. Adding status: :unprocessable_entity to the render fixes the problem:

def create
  @user = User.new(user_params)
  if @user.save
    redirect_to root_path, notice: "User created successfully"
  else
    render :new, status: :unprocessable_entity 
  end
end

1. A similar solution from yesterday’s post also works. Adding:

data: { turbo: false }

The form declaration disables turbo and lets Rails UJS handle as desired. I hope future versions of Turbo handle this better.

The Problem

Everything was working great until I implement some of the HTML over the wire goodness of Hotwire. I have a couple of areas on the site that rely on a Sidekiq and update a page when the job is complete. A perfect use case for Hotwire. The job processed, changes broadcast, and pages updated when the model changed. It worked as planned!

I deployed the update using Hotwire, tested and everything was working as I wanted. Deciding to authenticate a different Twitter account, no longer was I sent to the Twitter page to enter my credentials. No error on the page; it just did no redirect. I looked for any errors in the Rails log. I could see the request initiated but it seemed to drop out of sight with nothing additional logged and no errors.

Maybe it’s a browser-specific issue. I usually use Firefox so I tried Chrome and Safari with the same results. Digging a bit deeper I decided to look at the Network tab in the browser to see if the request was giving an error and I found nothing. The request wasn’t going out to Twitter.

Inspecting the console in Firefox revealed this ugly message:

Access to fetch at 'https://api.twitter.com/oauth/authenticate?oauth_token=<my secret token>' (redirected from 'https://127.0.0.1:3000/auth/twitter') from origin 'https://127.0.0.1:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

I started to search around for the error, and many solutions had me trying the rack-cors gem and other methods to satisfy what needed to be done. Nothing worked. I spent a couple of hours going down this path to no avail. The error is deceiving and not indicative of the real problem.

Debugging

I had done many updates since the last time I knew this worked, including gem and NPM package updates. After removing and testing each update, the message still appeared. I determined which code was updated since the feature recently worked. I evaluated and ranked each change by how much I thought it could cause the problem. The only change that was a bit of a black box to me was the addition of Hotwire to the mix.

I removed the Hotwire-rails gem and removed all the code related to Hotwire and, moved back to Turbolinks. Magically it all worked again. Adding Hotwire caused this problem.

A Solution

Being new to Hotwire I wasn’t sure where to start. I started with what any good developer does…a Google search. I came across some posts on the Hotwire forums and on the Devise Github issues list that provided a solution that worked.

One, in particular, gave this solution:

It seems like adding:

:data => {turbo: "false"}

and making my link a button seems to make it work as per: Devise github login not working after Turbo enabled. · Issue #45 · hotwired/turbo · GitHub. I now have a different error, but that it something different. So I suppose this is solved for now.

The original button I used to connect with Twitter, looked like this:

button_to "Connect a Twitter account", "/auth/twitter", method: :post, class: "btn btn-primary"

After the suggestion above, it now looks like this:

button_to "Connect a Twitter account", "/auth/twitter", method: :post, data: {turbo: "false"}, class: "btn btn-primary"

After adding the code to the button, it works as it did before. Simply don’t use Turbo for this type of request. The Turbo docs do discuss disabling Turbo on specific links. The error I received did not do a good job of pointing me in the right direction and I spent some time going down the wrong path. I hope someone else can save some time if they have a similar problem.

Conclusion

Solving this problem was time-consuming, but I learned a bunch. Hotwire is in beta at this time. I’m sure things will improve, and maybe we don’t have to solve problems in this way in the future. A lesson I learned is the need for some better end-to-end tests for this project. I thought since it was going to Twitter and back, it wasn’t necessary. I was wrong.

Problem

When performing the usual command to install Ruby with rbenv, I started getting this message:

~ $ rbenv install 2.6.7
Downloading ruby-2.6.7.tar.bz2...
-> https://cache.ruby-lang.org/pub/ruby/2.6/ruby-2.6.7.tar.bz2
Installing ruby-2.6.7...
ruby-build: using readline from homebrew

BUILD FAILED (macOS 11.2.3 using ruby-build 20210423)

Inspect or clean up the working tree at /var/folders/mq/tlm78wy92v54ygbzfykqc8640000gn/T/ruby-build.20210424214159.42314.u6mGui
Results logged to /var/folders/mq/tlm78wy92v54ygbzfykqc8640000gn/T/ruby-build.20210424214159.42314.log

Last 10 log lines:
        rb_native_mutex_destroy(&vm->waitpid_lock);
        ^
vm.c:2489:34: warning: expression does not compute the number of elements in this array; element type is 'const int', not 'VALUE' (aka 'unsigned long') [-Wsizeof-array-div]
                             sizeof(ec->machine.regs) / sizeof(VALUE));
                                    ~~~~~~~~~~~~~~~~  ^
vm.c:2489:34: note: place parentheses around the 'sizeof(VALUE)' expression to silence this warning
compiling dmyenc.c
1 warning and 1 error generated.
make: *** [vm.o] Error 1
make: *** Waiting for unfinished jobs....
~ $

Trying to figure out the problem by looking at the message, it didn’t seem like something I could fix. Searching the rbenv Github issues didn’t give many clues. Knowing that rbenv uses ruby-build to automate the Ruby build process, I looked at the issues reported. It looks like I was not the only one having similar problems.

I tried several of the suggestions found from those issues and none of the solutions worked.

Solution

I decided to turn to my friends on Twitter to see if anyone had faced this issue. Twitter never lets me down and Robby Russell of Planet Argon came through, suggesting installing Ruby with these CFLAGS:

CFLAGS="-Wno-error=implicit-function-declaration" rbenv install 2.6.7

It worked perfectly and I was able to get additional versions of Ruby installed. This should also work if you’re having problems with asdf Ruby version manager too. Asdf uses ruby-build behind the scenes.

I wondered why I hadn’t stumbled on this solution in the ruby-build issues on Github. It turned out I saw the issue but ignored it because it referenced installing older versions of Ruby when Xcode 12 was installed. I have Xcode 12 but was installing new versions of Ruby. The ticket was a little deceiving as it worked with new versions as well.

For those interested in the details, they can be found in the ticket - Installing older Ruby versions on OSX after Xcode 12.

I attended RailsConf this year, as I did last year. Due to COVID-19 these events were virtual-only. Unlike last year, this year’s event included a live component for keynote speakers as well as a large number of Discord rooms so that attendees could live the hallway track as best a virtual even could provide.

Organizers reported attendees took part from 61 countries.

There were 5 keynotes, 60 talks (not including attendee lightening talks) and 11 workshops over 4 days. The talks were prerecorded so they could be viewed at anytime. This is a nice feature; as someone who has attended the in-person RailsConf in the past, it’s always hard to decide what talks to attend and sustain the energy to watch one during every time slot.

The keynotes and workshops were live and took place in the afternoon and late morning, respectively. This year live lightning talks, game show, sponsor talks and speaker Q&A were added and made the experience feel as close to in-person as possible.

The 60 session talks will be up on the Ruby Central Youtube channel with a month after the event. Lots of really great talks and tons to learn.

This format worked great but I do miss the in-person events when you can see old friends face-to-face, have good conversations and enjoy group dinners out. I hope next year there is an in-person component of RailsConf. It does appear RubyConf will offer both in-person and virtual attendance. This gives attendees options and likely means more people can attend since some would miss because they couldn’t get away.

I don’t know the numbers for previous RailsConf, but I would have to think attendance was not close to 61 countries.

We are seeing the future

As bad as COVID-19 was for so many, we may see some positive changes for the future.

Conferences were designed to be in-person, face-to-face meetups, bringing attendees from all over the world to a central location. COVID-19 has shown us there had to be a different way.

Organizers had embrace a new way of holding events or shutdown. Technologies like Zoom and Mux proved online video is a solid technology, capable of the demands of many users.

Events than can offer both an in-person and virtual experience, stand to gain the most. This opens up opportunities for both organizers and attendees. People who would not be able to attend a particular conference in-person would now not miss the event because they can watch in the comfort of their home or office. Organizers that had to limit attendance can now open up and allow so many more to take in the event. Win..win.

I’m looking forward to attend more conferences in 2021 than ever before. I will attend some in-person but will attend others virtually. The RailsConf organizers and folks at Ruby Central should be applauded for a great job.

The deployment ran and failed with an error message:

error An unexpected error occurred: "ENOSPC: no space left on device

Hatchbox gives users a nice interface to deploy Ruby on Rails applications. Everything is taken care of for us, from server provisioning to application deployment. It’s really a nice service and allows lots of customizability.

This particular application is provisioned on Amazon EC2. Hatchbox provisions to multiple providers including Amazon and DigitalOcean but their responsibility for the platform does not go beyond provision. Issues such as what to do about these types of errors is up to the user.

Finding the Problem

I am running an a t2.micro instance which does not have a lot of space but I didn’t expect to run out so soon. I ssh’d into the server and ran a check of disk space with the

df -h

command. The result showed me what was wrong:

Granted, this shows I have 93% free and that should be enough to deploy my application and it is. I removed some old deploys and freed up enough space to finish the deploy. Disk space was at 99% before cleanup. This was a temporary solution and adding space is needed.

Fixing the Problem

If you are familiar with how managing partitions on a Mac or Windows system then you should have an understanding how to solve this problem. On these system there is the idea of a partition, which has a set size. The partition is formatted for a given file system and can then be used to store applications and data. These partitions can have their size adjusted and formatted for use. This is how this problem is solved.

This application is running on Amazon EC2 and those servers use Elastic Block Storage (EBS) for server storage. The nice feature of EBS is the ability to easily change the size of the drive allocated for our use. The default size for our t2.micro instance is set to 8G, which seems small but can be easily expanded.

Loggin into the Amazon Web Services dashboard, the available volumes are shown. Selecting Volumes listed under Elastic Block Store on the left side column reveals them:

I have a single volume listed, you mileage may vary. Choose the one for the EC2 instance needing more space. Notice the display shows 16g of storage. This screenshot was taken after the changes were made to expand the volume.

Right clicking on the volume shows a nice menu:

Finding this menu was not obvious when first arriving at this page. You will want to choose the Modify Volume option from the popup menu where you will see the following modal:

I changed this option from 8GB to 16GB for my purposes. Once you click the Modify button it will take some time for the change to take effect. The status will be here:

:

The State field will change and update with progress. Mine took about 5-10 minutes. When it’s all done it will return to showing In-Use.

Unfortunately, once this process is done the disk space is not expanded. You have to expand the volume on your own.

Expanding the Volume

Amazon does have a nice document to accomplish this task. It’s a good idea to take a look at this and follow their specific directions including taking a snapshot of the volume in the event there are problems.

I decided against the snapshot because I didn’t have any production data I needed to be concerned about.

These are the steps to finish expanding the volume. I assume you are familiar enough with the command line to complete these steps. These steps need to be completed from the EC2 instance itself. Access to the instance is accomplished with secure shell (ssh). Root privileges are also needed.

1. Check the file system in the volume. Mine shows ext4.

The Type column shows the format of the filesystem. Take note of this, it will be needed later.

2. Run lsblk to look for the partition that needs to be extended.

This shows my partition after the upgrade had been done. The disk size showed 16G and the partition (xvda1) showed 8G.

3. Extend the partition

We need to extend the partition so we can use it in the next step. From a terminal window of your EC2 instance.

sudo growpart /dev/xvda1 1

The 1 at the end indicates the partition to be expanded.

4. Extend the File System

Since the filesystem of the drive I am targeting is ext4, I use the command:

sudo resize2fs /dev/root

Once this command completes running another df -h shows our partition is expanded and we no longer receive errors when trying to deploy to Hatchbox. This issue is not unique to Hatchbox and will solve this problem for any method used to deploy to your Amazon EC2 instance.

Conclusion

This process is not difficult but does require paying attention to some details. If you aren’t familiar with how-to access remote systems or how partitions and filesystems work then you might want to find a friend who can help.

I hope this helps…

I’ve made use of several of these and it works great.

The list of tools is pretty broad and I can imagine the author adding more to the toolbox as time goes on.

The toolbox is not free, $25 for use on two Macs. Seems like a bargain. I found the source code is available too but I hope is if you find value, you support the author. As developers we know how much time it takes to create and support a nice piece of software.

The gem was yanked from Rubygems and because of this, the gem could no longer be installed so builds broke everywhere. Users received the message:

Your bundle is locked to mimemagic (0.3.5), but that version could not be found in any of the sources listed in your Gemfile. If you haven’t changed sources, that means the author of mimemagic (0.3.5) has removed it. You’ll need to update your bundle to a version other than mimemagic (0.3.5) that hasn’t been removed in order to install.

I have several clients needing a way to resolve this problem. I came up with a couple different options.

Option 1 - Remove Dependency

After a bit of research I discovered that Mimemgic was used by the Marcel gem which is required by ActiveStorage. If the application did not use ActiveStorage then removing the dependency would solve the problem. If you use ActiveStorage, this is not an option.

Implementing this is pretty straightforward. Opening up your config/application.rb, you should see where Rails is required:

require "rails/all"

Instead of requiring all, just require what you need and remove the ActiveStorage dependency. This is what requiring rails/all includes:

active_record/railtie
active_storage/engine
action_controller/railtie
action_view/railtie
action_mailer/railtie
active_job/railtie
action_cable/engine
action_mailbox/engine
action_text/engine
rails/test_unit/railtie
sprockets/railtie

Just remove the second line and require each of these individually and you will be all set.

Option 2 - Change how the gem is included

Since the Mimemagic gem is open source and the code is in a git repo, we can identify the commit created when version 0.3.5 of the gem was released. Some commits that should solve the problem:

• 0.3.3 https://github.com/mimemagicrb/mimemagic/commit/d5ebc0cd846dcc68142622c76ad71d021768b7c2
• 0.3.4 https://github.com/mimemagicrb/mimemagic/commit/64b60d125432bde900fa4d9f77fb6f057a0c325a
• 0.3.5 https://github.com/mimemagicrb/mimemagic/commit/01f92d86d15d85cfd0f20dabd025dcbd36a8a60f

My projects have been using v0.3.5, I found the commit and added this to my Gemfile:

gem 'mimemagic', '0.3.5', git: 'https://github.com/mimemagicrb/mimemagic', ref: '01f92d8'

This is a short-term fix. I expect once the Rails team resolves the dependency, new versions of Rails will be released.