Advent of Code is a set of coding challenges published between 1st and 25th of December every year. Everyone gets their own exclusive input and what matters is giving the correct answer.

This year I’ve made a effort to write my solutions in Rust. Even though I ignore most of the generic parts of the language, I still get very effective with it. Rust clicked for me in 2022 for good. My coding style is very caveman-ish with strong influences of regular C, but I find it very effective. I post my solutions on my GitHub.

Computer science problems are always on my list of things I would want to be better at. After leaving the university, I never really had an occasion for that. AoC has been a great hack for that. The problems are presented in very nice way. There is no pressure on being the most efficient. Some tasks require a trick to finish in a reasonable time, but there is a lot of room to do different optimizations.

I encourage everyone to give it a try. I haven’t finished all challenges on time, nor I fight to get a good spot on the leaderboard. I still have a lot of fun. It’s like LeetCode, but actually motivating. My brain haven’t got that much focused thinking in a very long time.

Lately, we noticed that our Heroku deploys got frustratingly long. Over 10 minutes to build and release our main application wasn’t acceptable. Add CI runtime and Heroku’s preboot to the mix and now we could easily end up with around 25-30 minutes of full deploy time. This was getting very annoying when trying to ship a hotfix.

What if we could make it shorter?

What’s going on?

The biggest chunk of time in the build process has been asset compilation. With each build, Heroku was installing all npm dependencies (using yarn) and compiling webpacker assets from scratch. It took very long with each build, even if we didn’t touch any code (deploying the same code twice).

Something didn’t smell right as on local dev environment if there were no changes, the process ran in less than a second.

As time passed, we also noticed that our slug size was growing, which causes deploys to be longer. There were lots of uncleaned leftovers after each webpacker build. Simple repo purging was enough to get rid of this problem, but it required manual command execution.

It was clear that there are a couple of problems:

• Yarn cache isn’t re-used.
• Full webpacker build runs even if JavaScript code was not touched.
• Old build products were not cleaned.

Getting to a solution

Luckily some people already worked on a solution. With that webpacker will reuse the previous build if JavaScript files were not touched. Otherwise, webpacker will do a full rebuild. On top of that, these changes include a Yarn cache, which remedies problems with dependencies installation (however this could be achieved installing official node.js buildpack from Heroku).

Another problem is that webpacker does not ship with a cleaning task (similar to `assets:clean``). Without it, the slug size of our application will keep growing in time. Luckily for us, there is a webpack plugin called clean-webpack-plugin that does exactly this.

Combining that plugin and making a little tweak in the solution by @kpheasey we can achieve the effect we want. We included that tweak on our GitHub fork of heroku-buildpack-ruby.

Putting the solution together

Technical note:

This solution works on Rails versions >= 5.1, < 6.0. It should be easy to modify it to work with other versions.

Firstly, you need to have `clean-webpack-plugin`` in place:

yarn add clean-webpack-plugin

Now add plugin’s config code to config/webpack/environment.js:

1// ...
2const { CleanWebpackPlugin } = require("clean-webpack-plugin");
3
4environment.plugins.prepend("CleanWebpackPlugin", new CleanWebpackPlugin());
5
6// ...

And the last step – replace the official Ruby buildpack with the custom one in your app’s Settings on Heroku.

https://github.com/pilotcreative/heroku-buildpack-ruby.git#feat/yarn-cache

Now run a full build to build your cache and you’re done! For us builds take from 2.5 to 5 minutes depending on what changes are being deployed.

Sources

• https://github.com/rails/webpacker/issues/1410
• https://github.com/heroku/heroku-buildpack-ruby/pull/892
• https://github.com/johnagan/clean-webpack-plugin
• https://github.com/rails/webpacker/pull/1744
• https://thoughtbot.com/blog/how-to-reduce-a-large-heroku-compiled-slug-size

The trick is hotkey terminal window. It is basically an additional terminal window that is always visible, and you can show/hide it using a keyboard shortcut.

This additional window seemed to be really handy as a code scratchpad or dedicated man window. It is so convenient that I sometimes use it as the main terminal.

I believe this feature should be available on most platforms. I personally use iTerm2 (Mac only) and it has this functionality built-in. In my case, the new window show/hide up after I press CTRL two times.