Developing with Browser Guards in Rails 8 - As part of the Rails 8 milestones, DHH added a browser guard which he explains thus:

To take full advantage of our #nobuild defaults, we need to ensure that developers have easy control over which versions of the major evergreen browsers they intend to support, and guard their application from being accessed by unsupported versions.

In the pull request that followed we can see that by default, the browser minimums have been set to:

• Safari 17.2
• Chrome 119
• Firefox 121
• Opera 104
• and well, no IE at all.

What this means in practice is that if you visit a newly generated Rails site with a browser below these versions, you will get this 426 error page:

[read more...]

Memory Issue After Rails Upgrade - I upgraded a bunch of sites to Rails 7.1 recently and the ones deployed on Heroku started to show some massively increased memory usage:

[read more...]

Debugging Action Mailbox Issues in Production - When receiving and processing incoming emails with ActionMailbox, you may come across issues with particular emails that you need to debug. There is a tiny section in the Rails Guides about how to work with ActionMailbox in development. But how do we get an email that caused issues in production and debug it in development with the tools Rails provides?

[read more...]

Installing Ruby 2.6.7 on MacOS with asdf - On MacOS Big Sur - installing Ruby 2.6.7 may fail during the compilation step. Here is the snippet I used to ensure it compiles and installs.

See what javascript caused an attribute to change - I was working on some front-end code today - and when I clicked on a checkbox it mysteriously shrunk. I mean its height was set to 0px when I clicked on it. It was so strange. Some code somewhere was adding a style attribute with height: 0px. Searching my codebase I couldn’t find anywhere where this was happening.

To solve these sorts of issues, Chrome (and I’m sure other browsers) have a feature in the dev-tools where you can stop execution and see what is happening under the hood so to speak - in other words see what javascript is running at exactly the moment a particular event happens on the DOM.

To access this feature - open up dev tools - and select the element you want to watch change. Right-click the element and in the Break on fly out menu select attribute modifications.

Now you will need to trigger the event. In my case, I clicked on the checkbox. Execution stopped and the browser popped up the exact code that was causing the checkbox to have a style attribute added.

A very handy feature.

Execution order of after_commit and after_rollback ActiveRecord callback - Rails allows the adding of various callbacks that trigger during the lifecycle of an ActiveRecord operation. The standard callbacks are before_validation, after_validation, before_save, before_create, after_create, after_save, after_commit, and after_rollback.

These are documented quite extensively in the Rails Guides and the Rails API documentation.

The documentation is quite good at showing you the order the callbacks are executed - eg before_validation fires before validate which fires before before_save etc. Most of these validations execute in the order they are defined. For example, if you have two before_save callbacks defined, then they will execute one after the other.

[read more...]

Asking For Help Is OK - Last week I was stuck on a coding problem on some code I wrote a while back but that contained a nasty bug that had been intermittent and hard to pin down.

This particular application I had written myself before I had a team in place, so I was the only one that knew the codebase. Over the weekend I thought about the best way to keep tackling this problem and the solution I came up with was to involve another person.

This may seem like a no-brainer to some of my astute readers but here are some reasons why it wasn’t my first thought:

1. No one else knew the codebase
2. Pulling them into this problem meant pulling them off their own projects
3. It was a bug I had caused, so surely I was responsible for finding it and fixing it.
4. It’s probably a small, stupid bug and I will look incompetent to my peers/staff if I need help fixing it.

To me, at the time, these all seemed plausible reasons to keep tackling the issue myself. Problem is that I wasn’t getting anywhere. I was actually costing my company money by spending more of my time on it. It was unproductive and not effective.

So I asked my colleague to look at the problem. And then the magic started happening.

He cloned the repo and immediately ran into problems. Bundling wouldn’t work (this was a Ruby/Rails app). The README on starting work on the app was out of date. There was no solid database seed file. A whole slew of issues just getting the app bootstrapped onto his machine. Embarrassment turned into an opportunity to make the app better, document things better and making it easier for new devs to come onto a project.

After an hour or so he started to look at the initial problem. It was a JavaScript bug and adding console.log statements strategically started to highlight some issues. He sat at my desk and whilst I wasn’t paying 100% attention as he was still in discovery mode, I was hearing the frustrations and questions. Eventually I gave him my full attention and we tried a few things and solved the problem together. We high-fived each other, commited and deployed the fix.

At my work we try and pair at least once a week. Either on something challenging or to check out new techniques. Rarely do we do it when we are stuck on a bug. I think this example has shown how good it can be to get another set of eyes onto your code, either through pairing or pull-requests.

As a manager of a project, it can sometimes be confronting to get a colleague or team member to review your current or older code. You are meant to be be the guru. You are meant to help them. But you know, we all have rough days. Sometimes we don’t write our best code. Sometimes we can’t see the cause of a particular bug. Asking for help is the right thing to do.

Know Your Customer - A few weeks ago, I finalised some new code for a new section of an existing website. I always code websites using web standards and always test on the latest versions of Chrome (v10), Safari(v5), Opera(v11), Firefox(v3.6) and Internet Explorer(v8). In the case of the latter two, I test both the current version and the upcoming version. So the site is also run through its paces on Firefox 4 and Internet Explorer 9. As for mobile, I test on iPhone and iPad too. As you can see, it’s a pretty comprehensive test. However we began getting customer feedback that they couldn’t log in to the new section of the site.

I looked through the logs and couldn’t even see that they’d made an attempt to login. Very weird. I went back to the tests and everything worked. Then some users were able to log in. But the majority couldn’t. We started to get some screenshots and feedback and discovered that it was a browser issue. Internet Explorer 7 to be exact. The jQuery login popup we had implemented didn’t render correctly on the old Microsoft browser. Hence it didn’t work, and no entry was made in the logs, as the customer wasn’t even able to submit the form.

I had a look at the analytics data for this group of users and found that 89% of them were using Internet Explorer 7. A browser not in my test suite but used by the vast majority of our users (of this part of the site). The fix was easy once we knew the problem. And all customers can now log in.

Suffice to say that Internet Explorer 7 is now part of our test suite. We don’t test that things “look” the same. We just test that the site “works”. Internet Explorer 7 has 5.7% of the worldwide market share, and Internet Explorer 6 has 3.8%.

But the main lesson learned, is that when developing for a closed group (like an intranet or a internet site that is locked to certain users), make sure you know the browser statistics data. Not only will it ensure that what you’re developing works, but it also provides the opportunity to give them a better experience through harnessing the power of that particular browser.