Mauro Morales

software developer

Month: September 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.

    , ,