Mauro Morales

software developer

Year: 2020

  • Using a Hackathon to Stress Test Your Development Process

    A hackathon’s value proposition is generally one of innovation. Companies see these events as an investment to come up with new products. However, I recently found out they are also a great way to teach us about existing flaws in our software development processes.

    I’ve participated in a handful of coding events before and have come to appreciate hackathons, as a good way to boost camaraderie and do some individual learning. That’s why I got very excited when a few months ago our CTO announced we were going to do ListMinut’s first hackathon. And so, for 3 days in mid-September, our product development team moved to the Belgian coast to design and code an MVP.

    Let me first give you a bit of context. ListMinut is growing, and while this is good, it’s also challenging. Just like most other businesses, at first, it was possible to add features fast and easy, but with time the development process became harder and slower and throwing more man-power doesn’t seem to balance the situation. This scenario is very similar to a city whose streets grew organically and were not designed with growth in mind. At some point, the excess in population causes the entire traffic system to collapse. Fortunately for us, software is way more malleable than a city.

    To mitigate these growing pains, there are two major changes we are introducing. On the operational side, we are setting agile processes in place to help us work smarter. And on the technical side, we are improving code quality and optimizing performance, while also evaluating architectural changes which can deliver long-term benefits. This is basically why I joined the team.

    The main motivation behind the hackathon was to address the latter. What I didn’t expect, was how good the hackathon would be, as a way to surface out any flaws in the way we work. You’ll see, as part of my work during my first four months, I’ve been pushing for (1) shorter-lived feature branches, (2) code reviews, (3) automated testing, and (4) improved code quality. The team has been taking all these changes very positively. I’ll even allow myself to say that they’ve even been somewhat enthusiastic about it, which not only has made my job much easier but is enabling us to rip off the benefits early on.

    During the hackathon, without any request from my side, the back-end team didn’t rush in to code like crazy but instead followed each of these 4 principles, which completely made my day. The fact that we did so, allows us to easily incorporate what we built during these 3 days without having to go through a big refactoring or suffering some high maintenance costs later on. This is already a considerable win, but I know we can still improve and the fast-paced rhythm of the hackathon was a great way to put our processes to the test.

    For us, it pointed out little communication problems which forced us to do some re-writes and some problems with WIP (work in progress) and bad design which gave us some ugly merge conflicts. These difficulties aren’t new to development teams, as a matter of fact, they are very common but sometimes challenging to see in the busyness of the day to day. So teams adapt and cope with them or worse yet, they start to think of them as myths. The good news is that our industry has been solving these issues for a while now, so we will follow some Lean/Agile advice while also improving our OOP design and iterate until this machine is finely tuned.

    I’m quite excited to be working as a part of a team that experiments and isn’t afraid of exposing its issues. I think this is the only way to learn and improve. If you’d also like to expose any issues with your development process, let me recommend that you do a hackathon and follow your existing development process, you might surprise yourself about what you find.

    , ,

  • ActiveRecord Except

    August 19th was Whyday, and to commemorate it, I decided to write a gem called activerecord-except.

    WHAT IS IT?

    activerecord-except is a Ruby gem that extends the functionality of ActiveRecord, allowing you to select all the fields from a table, except the ones that you specify. For example, if you have a table users.

    development_db=# \d users
      Table "public.users"
            Column             | 
-------------------------------+-
 id                            | 
 username                      | 
 password                      | 
 email                         | 
 first_name                    | 
 last_name                     | 
 phone                         | 
 ...
 created_at                    | 
 updated_at                    |

    And you want to get all the fields except for the password, you’d have to pass each of them in your select clause like so

    User.all.select(:id,
                :username,
                :email,
                :first_name,
                :last_name,
                :phone,
                ...
                :created_at,
                :updated_at)

    Instead, using activerecord-except, can simplify your statement by saying only the field you don’t want, in this case, the password one

    User.all.except(:password)

    HOW DOES IT WORK?

    Under the hood, the except clause makes use of the traditional selectclause. So our previous example will produce the following query

    SELECT "users"."id",
       "users"."username",
       "users"."first_name",
       "users"."last_name",
       "users"."phone",
       "users"."created_at",
       ...
       "users"."updated_at"
  FROM "users"

    This is because the SQL language doesn’t provide such functionality out of the box.

    I don’t know what is the reason for this. I can only speculate that it’s to be more explicit and not be caught by surprise if a field in a table gets added/deleted/changed. However, * is also wildly used. In Rails for example, it is what you get, when you don’t specify a select clause in your query.

    The way I managed to make it work is by adding a method toActiveRecord::Relation which asks the model for all its attributes and rejecting those that match with the ones passed as arguments.

    klass._default_attributes
     .keys.map(&:to_sym)
     .reject { |attr| fields.include?(attr) }

    Note: As you can see, I’m using _default_attributes which starts with an underscore. This can mean that the method is not intended to be relied upon.

    Whether or not you might want to use in production, I leave up to you, where I really see the benefit of activerecord-except is for writing one-off scripts to extract data, because it makes them much easier to read.

    WANT TO GIVE IT A TRY?

    You can install it from rubygems or you can check the source code either on Sourcehut or GitHub.

    , ,

  • 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.

    SPECS

    • 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.

    COMPARISON SHOTS

    Vortex Core compared to Das Keyboard 4 Ultimate

    Vortex Core compared to Macbook Pro 13″

    Vortex Core compared to Magic Trackpad

    MY PERSONAL CUSTOMIZATIONS

    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.

    GOTCHAS

    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.

    ALTERNATIVES

    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.

    FINAL THOUGHTS AND RECOMMENDATIONS

    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.

    CONTEXT

    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

    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 https://cache.ruby-lang.org/pub/ruby/2.6/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

    USING THE BUILDPACK IN YOUR APPLICATION

    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 https://github.com/some/buildpack.git -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": "https://github.com/some/buildpack.git"
        }
      ]
    }
  }
}

    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}

    CONCLUSION

    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.

    , ,

  • Ruby’s DATA Stream

    The STDIN and ARGF streams are commonly used in Ruby, however there’s also the less popular DATA one. This is how it works and some examples in the wild.

    HOW TO READ FROM DATA?

    Like with any other stream you can use gets and readlines. This behaviour is defined by the IO class. However there’s a caveat, your script needs to have a data section. To define it use the __END__ to separate code from data.

    $ cat hello_world.rb
puts DATA.gets
__END__
hello world!

$ ruby hello_world.rb
hello world!

    Look at that, another way to code hello world in Ruby. Without the __END__keyword, you’ll get the following error:

    NameError: uninitialized constant DATA

    WHEN TO USE IT?

    You could use the data section of the script if you wanted to keep the data and code really close, or if you wanted to do some sort of pre processing to your sources. But to be honest, the only real benefit I can think of is performance. Instead of starting a second IO operation, to read a file containing the data, it’d get loaded at the same time than the script.

    EXAMPLES

    One thing I’ve learned while working with Go, is to check Go’s source files for good examples. Even though you cannot do this with Ruby at the same degree because the sources are in C, you can still check the parts of the sources that are in Ruby and the gems and tools maintained within the Ruby sources. Here are some examples: