Mauro Morales

software developer

Month: June 2020

  • Vortex Core Mechanical Keyboard Review

    I got myself a new keyboard for my birthday, the Vortex Core. I wanted a mechanical keyboard that I could take everywhere with me. Being a 40% keyboard, I expected it to over deliver on the portable side, what I didn’t expect, is that I’d enjoy using this tiny keyboard so much, even for extended periods of time.


    • Four layers, from which three of them are programmable without having to flash the devise
    • Cherry MX switches. I got mine with silent red ones
    • DSA Profile keycaps
    • RGB LEDs (also programmable)
    • ANSI layout (for the most part)
    • Aluminum case with 4 rubber feet
    • Micro USB connector

    The quality of the printing is great and I really appreciate having the side prints to be color coded depending on the function key. This is necessary to program the other layouts but even if it wasn’t, I wish more keyboard manufacturers would do it.


    Vortex Core compared to Das Keyboard 4 Ultimate

    Vortex Core compared to Macbook Pro 13″

    Vortex Core compared to Magic Trackpad


    I really like how this keyboard looks and feels from but there were two changes I made to make it perfect for me:

    1. Programmed layer 2 so I could access all numbers and symbols plus arrow keys via the Fn key or a combination of Fn+Shift. Edit this layout If you want to know more about how to program the Vortex Core, check out this blog post
    2. Switched the left Space Bar, with a Vim keycap I bought fromVimcaps. The Vim green color, fits perfectly with the beige and gray from the other keys.


    I configure my OS to switch Caps Lock for another Ctrl for easy access, but as you can notice from the layout, the physical Caps Lock is missing. At first I was considering to reprogram another key to be Ctrl because I find the position of Ctrl very inaccessible. However, I noticed that I can easily press the Ctrl key using my palms and I ended up liking this better. So much so, that I also adopted this while using my Ergodox EZ.


    The Vortex wasn’t really my first option for a 40%. I had my eyes on a Planck EZ because I’m very pleased with the quality of the Ergodox EZ by the same company. I ended up picking the Vortex because (a) I liked the retro look better, (b) it was about 60 EUR cheaper and (c) I could get it from a local shop here in Belgium.


    Overall, I’m very happy with this keyboard. I enjoy using it for my everyday writing, no matter if it’s code and prose. It’s a great addition to my keyboard fleet and I’ll keep using it on a daily basis. The only thing I’d change, is the cable that comes with it. Everything in this unit has been built with a very high standard and an average USB cable doesn’t do it justice but if you don’t mind this so much or you don’t mind spending extra on a nice cable then you won’t be disappointed. So, if you’re on the market for a well built, good looking, portable and programmable keyboard, you should consider the Vortex Core.

    Having said that, I wouldn’t recommend the Vortex Core to someone who’s looking to buy their first mechanical keyboard. Instead, try to go with something a bit bigger first so you can get an idea about what you like and don’t about mechanical keyboards before buying something as extreme as a 40%. A good option could be a Das Keyboard 4. It isn’t programmable but the quality is great and I really like the dedicated media keys.

    For those who already have experienced a mechanical keyboard and are considering the Vortex Core, remember that getting used to a new keyboard layout takes time. The great thing about this keyboard is that it’s programmable so you can make that process less annoying by changing the default layout to something you feel more comfortable with. I think it’s better to use something that feels natural so you find yourself coming back to your keyboard over and over again, than something which you might think is the ultimate layout. Little by little you can introduce minor modifications that you can adapt to easily. I’ve been re-programming my Ergodox EZ for the past 4 years and I’ll probably continue doing so in the years to come.

  • Running a Patched Ruby on Heroku

    You use a PaaS because you want all the underlying infrastructure and configuration of your application to be hidden from you. However, there are times when you are forced to look deeper into the stack. In this article I want to share how simple it is to run a patched version of Ruby on Heroku.


    It all started while trying to upgrade Ruby in an application. Unfortunately, every newer version I tried made the application break. After some searching around, I came across a bug report from 3 years ago in Ruby upstream.

    The issue was actually not in Ruby but in Onigmo, the regular expressions library that Ruby uses under the hood. All versions since 2.4 where affected i.e. all supported versions including 2.5.8, 2.6.6 and 2.7.1 at the moment of writing. Lucky for me, Onigmo had been patched upstreambut the patch will only land in Ruby 2.7 later this year.

    This meant that, I was going to have to patch Ruby myself. For local development this is not a big deal, but I wasn’t sure if it was possible to do on Heroku. I remembered from CloudFoundry and Jenkins-X that the part of the platform taking care of the build and installation of the language were the buildpacks, so I decided to investigate about buildpacks on Heroku.


    Heroku’s Ruby buildpack is used to run your application whenever there’s a Gemfile and Gemfile.lock file. From parsing these, it figures out which version of Ruby it’s meant to use.

    Once it knows which version of Ruby to install, it runsbin/support/download_ruby, to download a pre built package and extracts it to be available for execution to your application. As a quick hack, I decided to modify this file to do what I did in my development environment to patch Ruby.

    1. First download the Ruby source code from upstream instead of the pre built version by Heroku.curl --fail --silent --location -o /tmp/ruby-2.6.6.tar.gz tar xzf /tmp/ruby-2.6.6.tar.gz -C /tmp/src cd /tmp/src/ruby-2.6.6
    2. Then apply a patch from a file I placed under bin/support/ (probably not the best place but OK while I was figuring things out).patch < "$BIN_DIR/support/onigmo-fix.diff"
    3. And finally build and install Rubyautoconf ./configure --disable-install-doc --prefix "$RUBY_BOOTSTRAP_DIR" --enable-load-relative --enable-shared make make install

    You can find an unpolished but working version of what I did here


    Now all that is left is to tell your application to use your custom buildpack instead of Heroku’s supported one. You can do this in the command line by running

    heroku buildpacks:set -a myapp

    Or by adding a file called app.json at the root directory of your application sources (not in the buildpack sources). I ended up using this form since I prefer to have as much of the platform configuration in code.

      "environments": {
        "staging": {
          "addons": ["heroku-postgresql:hobby-dev"],
          "buildpacks": [
              "url": ""

    Now every time a deployment is made to this environment, the Ruby application will download the Ruby sources, patch, build and install them.

    This of course is not very optimal since you’ll be wasting a lot of time building Ruby. Instead you should do something similar to what Heroku is doing by pre building the patched version of Ruby, and downloading it from an S3 bucket. {: .notice–warning}


    Using a patched version of Ruby comes with a heavy price tag, the maintenance. You should still apply updates until that patch is fixed upstream (at least security updates). And you also need to use the patched version in all your environments e.g. production, staging, et al. including your CI. Whether all this extra work is worth it, is something you’ll need to analyze. In the cases when the benefits outweigh the costs, it’s great to know that you don’t have to give up all the benefits of a platform like Heroku to run your own version of Ruby.