Ruby on MoskitoHero

An introduction to Barley, the fast model serializer

Tue, 06 May 2025 00:00:00 +0000

The story

The company I used to work for had an ageing API in v1 that was very poorly designed and slow in its implementation. It served 4 frontend platforms (a website, two mobile apps and an administration tool). Being in a startup environment, our team had to move fast, but that was at the expense of performance and maintainability. This was the situation when I arrived there. Returning JSON objects was very cumbersome. It used a custom method, available in each model that built a nested Hash, based on the attributes you gave it. That turned out to be a mess with poor performance and concerning security implications. It was difficult to maintain, with odd variable naming and behavior, so we set out to get rid of it somehow and moved to a kind of serializer DSL that was gradually introduced to replace the old mess. Later, we decided to tighten up our API with a new version to get rid of the legacy. A few requirements quickly emerged, among which:

API V2 should be easy to maintain, with clear naming conventions and namespacing
Since it is an internal API, it should be tightly coupled to the intended use and platform
API V2 should use some sort of view DSL to generate the JSON payloads
API V2 should be as predictable as possible in terms of typing and formatting.
API V2 should be super fast by default. It should be the last thing we need to optimize.

So I looked at the serializer DSL that we had designed for API v1. The first thing I did was to benchmark it against other solutions. So I stripped it out of legacy / no longer needed features, moved it to a local gem, and started playing with a few benchmarks. And it was very fast indeed ! This is the result of a benchmark I did back then:

Warming up --------------------------------------
# Omitted for conciseness
Calculating -------------------------------------
ams                    67.770  (± 1.9%) i/s -    657.000  in  10.042270s
jsonapi-rb            157.239  (± 2.3%) i/s -      1.521k in  10.010257s
barley                 96.909  (± 2.4%) i/s -    945.000  in  10.036316s
barley-cache            4.589k (± 2.8%) i/s -     44.620k in  10.010004s
ams          eager     68.237  (± 6.2%) i/s -    592.000  in  10.087602s
jsonapi-rb   eager    289.733  (± 3.7%) i/s -      2.805k in  10.033912s
barley       eager    406.732  (± 3.2%) i/s -      3.922k in  10.020076s
barley-cache eager    639.935  (± 2.4%) i/s -      6.300k in  10.053710s
with 95.0% confidence

Comparison:
barley-cache      :     4589.3 i/s
barley-cache eager:      639.9 i/s - 7.17x  (± 0.27) slower
barley       eager:      406.7 i/s - 11.29x  (± 0.49) slower
jsonapi-rb   eager:      289.7 i/s - 15.83x  (± 0.74) slower
jsonapi-rb        :      157.2 i/s - 29.17x  (± 1.08) slower
barley            :       96.9 i/s - 47.37x  (± 1.75) slower
ams          eager:       68.2 i/s - 67.25x  (± 4.69) slower
ams               :       67.8 i/s - 67.72x  (± 2.31) slower
with 95.0% confidence

Calculating -------------------------------------
# Omitted for conciseness

Comparison:
barley-cache      :      46090 allocated
barley-cache eager:     216790 allocated - 4.70x more
barley       eager:     354326 allocated - 7.69x more
jsonapi-rb   eager:     694430 allocated - 15.07x more
jsonapi-rb        :     926082 allocated - 20.09x more
ams          eager:    1068038 allocated - 23.17x more
barley            :    1102354 allocated - 23.92x more
ams               :    1299674 allocated - 28.20x more

Which is quite nice 😎.

So I made a gem out of our serializer and published it on Github. It is named Barley. I have recently made the gem even faster (from v0.9.0 on) and benchmarked it against Alba, Blueprinter, Turbostreamer, Jserializer, FastSerializer, Representable, SimpleAMS, AMS, Rails JBuilder and Panko. Here are the results of these new benchmarks:

ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +YJIT +PRISM [x86_64-linux]
Warming up --------------------------------------
# Omitted for conciseness

Calculating -------------------------------------
                alba    401.119 (± 1.7%) i/s    (2.49 ms/i) -      2.016k in   5.027350s
alba_with_transformation
                        256.123 (± 1.2%) i/s    (3.90 ms/i) -      1.300k in   5.076497s
         alba_inline     22.749 (± 8.8%) i/s   (43.96 ms/i) -    114.000 in   5.049973s
                 ams     16.923 (± 5.9%) i/s   (59.09 ms/i) -     85.000 in   5.029061s
              barley    427.045 (± 2.6%) i/s    (2.34 ms/i) -      2.162k in   5.066130s
        barley_cache    378.285 (± 2.4%) i/s    (2.64 ms/i) -      1.927k in   5.097462s
         blueprinter    120.704 (± 1.7%) i/s    (8.28 ms/i) -    612.000 in   5.071371s
     fast_serializer    142.347 (± 1.4%) i/s    (7.03 ms/i) -    720.000 in   5.058924s
         jserializer    252.455 (± 1.6%) i/s    (3.96 ms/i) -      1.274k in   5.047584s
               panko    510.262 (± 4.7%) i/s    (1.96 ms/i) -      2.585k in   5.077381s
               rails    107.589 (± 7.4%) i/s    (9.29 ms/i) -    546.000 in   5.104715s
       representable     50.264 (± 6.0%) i/s   (19.89 ms/i) -    252.000 in   5.027987s
          simple_ams     36.584 (± 5.5%) i/s   (27.33 ms/i) -    184.000 in   5.054347s
       turbostreamer    351.551 (± 1.7%) i/s    (2.84 ms/i) -      1.776k in   5.053401s

Comparison:
               panko:      510.3 i/s
              barley:      427.0 i/s - 1.19x  slower
                alba:      401.1 i/s - 1.27x  slower
        barley_cache:      378.3 i/s - 1.35x  slower
       turbostreamer:      351.6 i/s - 1.45x  slower
alba_with_transformation:      256.1 i/s - 1.99x  slower
         jserializer:      252.5 i/s - 2.02x  slower
     fast_serializer:      142.3 i/s - 3.58x  slower
         blueprinter:      120.7 i/s - 4.23x  slower
               rails:      107.6 i/s - 4.74x  slower
       representable:       50.3 i/s - 10.15x  slower
          simple_ams:       36.6 i/s - 13.95x  slower
         alba_inline:       22.7 i/s - 22.43x  slower
                 ams:       16.9 i/s - 30.15x  slower

Calculating -------------------------------------
# Omitted for conciseness

Comparison:
               panko:     259178 allocated
              barley:     633521 allocated - 2.44x more
       turbostreamer:     641760 allocated - 2.48x more
alba_with_transformation:     818181 allocated - 3.16x more
                alba:     818241 allocated - 3.16x more
         jserializer:     822281 allocated - 3.17x more
        barley_cache:     849521 allocated - 3.28x more
     fast_serializer:    1470121 allocated - 5.67x more
         blueprinter:    2297921 allocated - 8.87x more
         alba_inline:    2736041 allocated - 10.56x more
               rails:    2757857 allocated - 10.64x more
                 ams:    4713401 allocated - 18.19x more
       representable:    5151321 allocated - 19.88x more
          simple_ams:    9017033 allocated - 34.79x more

With YJIT enabled, Barley really shines and is the first Hash serializer of the group. There are more benchmarks to be found in the Barley repository. Barley is very simple in its implementation and allocates very little. I believe that it is what makes it so fast. I’ll write another post on how I optimized it in version 0.9.0.

The Features

Barley provides:

a clear DSL to define your serializer
inline / block sub-serializer definition
russian-doll caching
type-checking with dry-types
context handling

This is how Barley works:

In the model you want to serialize

First, include the Barley::Serializable concern in your model.

# /app/models/user.rb
class User < ApplicationRecord
  include Barley::Serializable
end

Once you include this module, Barley will look for a UserSerializable class in your codebase, so you need to define one, typically in the app/serializable directory. It should inherit from Barley::Serializer

# /app/serializers/user_serializer.rb
class UserSerializer < Barley::Serializer
end

Once this is set up, the as_json method on your model will return what you have defined in your serializer class. You can also chose to use a different serializer to render your data. You can use the serializer method in your model. This method also allows you to pass a cache argument.

# /app/models/user.rb
class User < ApplicationRecord
  include Barley::Serializable

  serializer MyCustomSerializer, cache: true
  # or
  serializer MyCustomSerializer, cache: {expires_in: 1.hour}
end

Another way to achieve this is through the as_json method:

User.first.as_json(serializer: MyCustomSerializer, cache: {expires_in: 1.hour})

Please note that Barley overrides the as_json method and does not provide it with standard only, include or except arguments. This is because the purpose of this serializer is precisely to do that job. The root argument works, though.

Defining the serializer

Let’s go back to the serializer class. Barley provides a simple DSL that allows you to define your JSON in a readable and maintainable way. Here is an example definition that covers most use cases:

# /app/serializers/user_serializer.rb
class UserSerializer < Barley::Serializer

  attributes id: Types::Strict::Integer, :name

  attribute :email
  attribute :value, type: Types::Coercible::Integer

  many :posts

  one :group, serializer: CustomGroupSerializer

  many :related_users, key: :friends, cache: true

  one :profile, cache: { expires_in: 1.day } do
    attributes :avatar, :social_url

    attribute :badges do
      object.badges.map(&:display_name)
    end
  end

end

For type-checking to work, you need to define a Types module like this, somewhere in your codebase:

module Types
  include Dry.Types()
end

1. Attributes

They can be defined as an array with the plural attributes method. It can be an array of symbols, or an array of hashes in the key: TypeDefinition pattern, or a mix of both. They can also be defined with a singular attribute method, that accepts a type keyword argument. If type is included in an attribute’s definition, it will raise an error. You can use types to coerce types and define constraints. Please refer to the dry-types gem for more options. If you give a block to the attribute method, you can also return anything you like. You have the object object at hand that refers to the serialized model.

2. Associations

They are defined with the one or many methods. It will use the default serializer if no argument is given. You can provide it with a serializer and a cache option. These methods do not provide a type argument, as it makes no sense to do so. You can also decide to give it a block, that allows you to define the association’s serializer inline.

Wrapping it up

The Barley gem’s goal is to provide a simple DSL to define your JSON payloads with a type-proof option, and render it in a very fast and efficient manner. It is probably not as feature-packed as other serializers available to the rails community, but it is a no-brainer, yet powerful option that you should consider if you are looking for performance and simplicity. I’d be happy to see more projects starting to adopt it and would love the community to provide optimizations to make it even better.

Ruby Best Practices - Method Arguments

Fri, 12 Jan 2024 00:00:00 +0000

To write readable and maintainable code, follow a few simple rules about argument ordering.

Tip 1: Optional arguments go last

When a method takes several arguments, and some of them have default values, make sure to put the optional ones at the end. Take this method definition:

def foo(a, b = "val_b", c)
  # some code...
end

Looks fine at first glance. But in practice, it’s impossible to call this method with values for a and c without also specifying b. You end up writing:

foo("val_a", "val_b", "val_c")

…which defeats the purpose of setting a default for b if you’re forced to specify it every time. ¯(ツ)/¯

Solution: move optional arguments to the end

def foo(a, c, b = "val_b")
  # some code...
end

Now you can call:

foo("val_a", "val_c")

No problem 😎.

Tip 2: Use keyword arguments (aka kwargs)

Tip 1 only gets you so far. What if you have multiple optional arguments and want to override just the last one? You’d still need to specify all the previous ones. For example:

def foo(a, b, c = "val_c", d = "val_d", e = "val_e")
  # some code...
end

Want to change only e? Too bad — you still have to write:

foo("val_a", "val_b", "val_c", "val_d", "my_val_e")

Now imagine this in a large codebase:

foo(user.id, "DONE", true, false, 1, "always", true, post.id)

And you’re left thinking: "Wait, what’s that false again? What does the 1 do? Why 'always'?" Not ideal, especially under pressure in a production bug fix.

Solution: switch to keyword arguments when you hit 2+ optional params

Benefits:

Argument order doesn’t matter anymore
You can ignore defaults entirely

The method now becomes:

def foo(a, b, c: "val_c", d: "val_d", e: "val_e")
  # some code...
end

To change only e, you write:

foo("val_a", "val_b", e: "my_val_e")

Ninja-level tip — the clean coder’s take:

If your method takes more than 1 argument, make everything after the first a keyword argument. Always.

Example:

def send_message_to(recipient, confirm: true, bcc: "joe@bill.com", cc: "jane@doe.com")
  # ruby code
end

Here, the first argument is obvious thanks to the method name: you’re sending a message to someone. Called without options:

send_message_to("sam@sam.com")

Clear and concise. Compare a non-keyword version:

send_message("recipient@mail.com", false, "joe@bill.com", "paul@smith.com")

…with the keyword version:

send_message_to("sam@sam.com", bcc: "paul@smith.com", confirm: false)

If you adopt these habits, future you will thank you when you revisit the code to debug or tack on yet another parameter.

Love your error messages as thyself

Tue, 17 May 2022 07:44:36 +0000

Learn to hate, then love error messages.

Stack Overflow overflow

I have lost so much time on Stack Overflow.

I mean Stack Overflow is great, and software development knowledge would not be so advanced and so widespread without its great influence. What I mean is that I have often found myself repeating the endless pattern of 'Hey, I have an error… Wow, so many words… Let’s google this. Stack Overflow has it! Let’s see what they say'

I am not talking about the infamous Stack Overflow copy-paste syndrome, nor am I dismissing the great answers produced by the great developers out ther, but rather about the missing step in the example above: making sense of the error message myself before actually looking for a ready-made answer.

Our brain is so quick at taking shortcuts that it often makes us lazy and skip the seemingly unneeded steps our thinking needs to fully develop. Take the example of walking. Although I don’t exactly remember taking my first step in this world, I can imagine it was a movement that required so much concentration - not to say bravery - and coordination that it must have felt quite awkward at the beginning. Today, I don’t even think about it. My brain just orchestrates everything, allowing me to go for a walk and actually think about something else.

Think about the first day you typed your first computer program. Think about the way you were thinking at the time. Maybe you are currently learning computer science and many mechanisms experienced developers don’t even think about are steps you consciously take, one by one, in order to reach code quality - or even to write code that actually works.

And while learning, we all encountered bugs. The language we were coding in was talking to us with complicated words, and concepts we sometimes did not even know about. We all googled for solutions. And Stack Overflow is so well conceived and maintained that we most certainly found the answer there. And it happened again. Error messages were so hard to understand, so cryptic, sometimes. So we just kept copy-pasting the error messages, and it just kept throwing correct answers at you, which, with a little adaptation, just worked.

And then, your brain skipped the error-message-reading step.

But we don’t want to just be very, very, very talented googlers, do we?

RTFEM!

Read the f***ing error messages!

So I encourage all of you learners to actually take a long look at the error messages that are thrown right in your face just as you were expecting a successful compilation. Take the time to read them. Take the time to look at those weird symbols that show up here and there. And you know what? You may not get to the point quicker at first, but you will gain a deeper knowledge of how your language is actually built, how it works internally. You might look at your fellow programmers increase their skills faster on the surface, but your understanding of error messages will eventually turn you into a Code Jedi Master.

What made me really stop overlooking error messages was reading Ruby Under A Microscope by Pat Shaughnessy, a most excellent book about the way Ruby is actually written in C, the way the language parser works and the way it turns the words you write into machine-understandable concepts.

Somewhere in the first part of the book that introduces how the parser works, the author talks about language tokenisation, which is - very basically - how the parser takes words and understand how to match them with a feature. And here they were, in a code example, my long-seen-yet-so-little-known error message friends, namely tSTRING, tCONSTANT and tINTEGER.

If only I had known what these correspond to before, error messages such as these would never have had me google for an answer.

But how could I know? When you google for ruby tString, you get all sorts of results, mostly skipping the preceding t. In order to get to the real stuff, I should have taken the time to actually read the error messages and wonder:

What is the language trying to tell me?

And if that sounds awkward, just remember that your programming language is actually a computer program written by other humans, and ask yourself:

What is the author of the language telling me to look at?

Chances are he is trying to get you to look at features of the language that may not be plain to see, but a little hidden from sight. And if he is trying to have you look at these, you might just as well do it. And learn.

Learn to love your error messages

Not only should you read error messages carefully, but you should also take the time to craft yours with love and care. Like I said in an earlier post, you should always try to write code with your future self in mind. And I guess the same applies to error messages.

Don’t just raise Error, or StandardError in your lib. Actually write your own OddError class. Give it a message. Make it clear. Make it so your user - and that may be the future you - is eager to look at what you coded and understand how it is architectured.

An error message must be clear, so it requires your code to be clear, and therefore it requires your programming mind to be clear about what the code is actually doing. Error messages tell something about your self.

Error messages are the conversation between the author of a program and his users. As a programmer, you will be either one or the other, in turn, and often both at the same time.

Error messages will make you grow while learning software. They will make you grow while using software. They will make you grow while writing software. Do not just dismiss them and skip to the Stack Overflow step.

Writing code for your future self

Sun, 21 Nov 2021 07:44:36 +0000

We all write bad code. Let’s face it. Even if we do our best at writing the most efficient and well-designed code, we all happen to write this dirty method we don’t feel so proud of and dread having to debug next month, or next year.

I’m not going to talk about that code, because it’s so easy to spot and there is no need to write blog posts about it. What I’m interested in is code which looks fine when you have finished typing, but will bite you in the back someday. It ends up being hard to maintain, extend or even understand. After years of coding, I have come up with a set of warnings that alert me whenever I am heading for a dead end.

Meaning

Code is language. Even more so when you use a programming language such as Ruby, which is designed to be very expressive. But to me, code begins to smell when it becomes unclear what it really does.

Names

Naming is essential. One of the thing that changes the most in my creation process is probably the name of the classes, methods and variables I design.

Humans name things they understand. And the higher the knowledge of an element, the sharper the naming. Renaming my classes in the development process is usually a good sign that I am getting a better idea of what they do or what concept they stand for.

Method length

One of the most frequent design patterns we are taught as aspiring OOP developers is to keep methods shorter than a few lines. One caveat, however, is that code ends up scattered all over the place, and you can sometimes lose touch with the lifecycle of your data. This is especially true for classes that are used to build a data structure.

For instance, take this class that builds a data hash to be sent to FCM:

module MobilePush
  class FcmNotification < BaseNotification

    def launch
      # Bootstrap stuff...
      push_service.send_message(project, data)
    end
    private
      # Lots of methods...
      def data
       {
          notification: json_notification,
          recipient: recipient_name,
          room: room_name
        }
      end
      # Lots of other methods...
      def json_notification
        @notification.to_json
      end
      def recipient_name
        @recipient.name
      end

      # Maybe a few other methods...
      def room_name
        @room.name
      end
      # The rest of the methods...
  end
end

Note: This example is a little over-simplified for brevity. But you get the idea.

I wrote this thinking "Hey that’s smart! Everything is nicely sorted. It really looks like clean code".

Then I took a few day’s break with my family. While I was away, one of my co-workers had to deal with my new code and add a new feature. But he found it unnecessarily abstracted, hard to maintain and extend. And he was right. So I refactored it to:

module MobilePush
  class FcmNotification < BaseNotification

    def launch
      # Bootstrap stuff...
      push_service.send_message(project, data)
    end
    private
      # Lots of methods...
      def data
       {
          notification: @notification.to_json,
          recipient: @recipient.name,
          room: @room.name
        }
      end
      # The rest of the methods...
  end
end

So OK, I had to swap out room_name for @room.name in two or three places in the class, because it was also used elsewhere. But I also made my code a little less abstracted. Now, my co-worker knows exactly what data is made of, at a glance.

Stories

One thing to remember when writing code, is that it is not just meant to be effective and concise. Code is meant to be read by others. Your co-workers, your team leader, and even more crucially, by the person who will be in charge of your once-new, now-legacy codebase.

One-liners

I love one-liners. They are fun, straight to the point, and they showcase the technical skills and the wit of their creators. They are to programming what punchlines, or newspaper headlines are to writing. But who wants to read a whole book written in this way?

Even though I sometimes use one-liners in my code, I only do so when I feel confident my successor - or my future self - will be able to make sense out of it easily.

Be explicit

I believe that most code should be explicit and guide the reader with landmarks that will help him or her follow along.

For instance, instead of this kind of expression:

Device.where('last_seen > ?', 1.hour.ago).where(logging: true).where(notifications: true).last.send_message(topic, payload)

I would rather either use class methods, or scopes in the model, to end up with:

device = Device.active_last(1.hour).logging.notifying.last
device.send_message(topic, payload)

I’m not stupid. I can understand the first example. But when parsing hundreds of lines of code to find a bug, I can look at this code and instantly tell what it does. No need to make sure I got the < and the > right. This was done once, on the day it was typed, and I can rely on it with confidence because each of these methods is tested and does what it says.

Be methodic

I like to separate intents in what I do with my class. When you tell a story, you first introduce your character with a clear description. Then only you give him an active role in your story. That’s what the code example above is doing. I could also have easily written:

Device.active_last(1.hour).logging.notifying.last.send_message(topic, payload)

But that’s mixing intents. This line is both querying the model and triggering an action, so you start reading the line thinking: "Oh, he is defining the Device" and finish it thinking "Ah. No, he is sending this device a message". Your reader should never ever be misguided, even in short, simple assertions like these.

I try to separate queries from actions. They are two types of tasks and require two distinct steps in my code.

Consider these three sentences:

The man in the bar that is old and dirty is talking about yesterday’s soccer results. - messy

There is a man who is talking in the dirty old bar about yesterday’s soccer results. - clearer

In the dirty old bar, there is a man. He is talking about yesterday’s soccer results. - crystal clear

I want my code to be crystal-clear. I want my code reviewer, my successor or my future very-tired-on-a-friday-afternoon self to perfectly get what I am doing with my code.

Tests

Writing tests helps me identify dependencies. Integration tests often require quite a lot of bootstrapping: a logged in user, a few related entities… that’s fine.

But I sometimes write tests that rely too much on other models. If you can’t test your Comment model without a Post model, then something may be too tightly coupled in the code, and the relationship between those entities needs to be inquired.

Assertions also guide me towards code clarity. I have found that when I have trouble defining an expectation in my test, it usually means that this particular method is not doing something clear enough. It either needs to be split into smaller methods or completely re-thought about.

A word about comments

Another sign that code needs to be refactored is comments. Comments mostly indicate that what the program does is unclear. So when I see comments in code, the first thing I do is delete them and figure out what is happening without reading them. And whenever that comes out messy, it’s a good sign that they can all be replaced by a single TODO: refactor.

Comments are also often a sign of an external dependency. Typically, you will get this kind of thing:

# Handle temperature > 21
# Deal with legacy customer IDs

The first one might depend on the device you’re dealing with, and that dependency might be addressed by the hardware team.

The second one could be deleted by resorting to an inherited class, like LegacyCustomer, which could handle that kind of special user cases and keep the Customer class clean with a predictable and simple interface.

The only comments I keep are top comments above class declarations, Yard documentation, a few refactor TODOs and silly, fun meta about the code.

Conclusion

I sometimes look at messy code and wonder "who wrote this piece of crap?"

Let’s see… Git blame…

Me.

I don’t like this feeling. I want to feel proud of my code. I want other developers, including my future self, to make sense out of it easily and instantly, and thank me for making the effort of crafting code that makes sense, is easy to debug and maintain.

Following this set of guidelines will hopefully help me down that path.

An alternative to the ActiveRecord after_initialize callbacks

Sat, 03 Oct 2020 00:23:33 +0000

I was playing with dynamic nested forms with Stimulus today and I stumbled upon a void left by Rails' ActiveRecord callbacks.

I have this Caregiver model within a nested form and I need to create it along with a User entity in my form, to be able to populate the fields. The problem is that creating an after_initialize callback (even with :new_record? will break the general behaviour of my app, and I don’t want to run through all the specs and fix FactoryBot issues etc.

So I just decided to create a small method in my Caregiver model:

# caregiver.rb

def init_with_user
  self.build_user
  self
end

Then I just need to call it in my view like this:

<%= f.fields_for :caregivers, caregiver.new.init_with_user, child_index: 'TEMPLATE_RECORD' do |cf| %>
  <%= render 'caregiver_fields', cf: cf %>
<% end %>

This makes the code in my view simpler, more explicit, while avoiding the dreaded callback hell.

Chaining conditions in regular expressions

Sat, 03 Oct 2020 00:23:33 +0000

I recently had to make a semi-complex check on a string to validate it.

Basically, I have this model method which produces a serial number based on the ID of the object. Valid returned values for this method are L00000002, L00000587 or L00014522. In short, they should be constituted of a capital L followed by 8 digits composed of the id of the object padded with zeros.

So I had to find a way to simply created a matcher for this to use in my model spec. I could have built two expectations, one for the length, and one for the composition. But I just decided to believe that regular expressions are powerful enough to do both at the same time. So I headed to rubular and started fiddling and googling around.

The solution I came up with was the following (with an id of 12, for instance):

/^L(?=[0-9]{8}$)0*12$/

What this does, is - after the starting ^L character - create a condition matching whatever follows the ?= inside the parentheses. If this condition is true, then the rest of the expression is read. So I just check for any digit ([0-9] - it could have been \d but readability make the first option a better fit IMHO) exacty 8 times ({8}) and then the end of the string with $. If this is matched, then I check any number of zeros (0*) followed by the id (12) and the end of the string ($).

Now I could use this expression in my spec, using the Regexp.escape method on my model’s id within a string interpolation:

# spec/models/my_model_spec.rb
describe "serial_number" do
  let(:my_model) { create(:my_model) } # I use the FactoryBot gem

  it "returns a valid serial number" do
    expect(my_model.serial_number).to match(/^L(?=[0-9]{8}$)0*#{Regexp.escape(my_model.id.to_s)}$/)
  end
end

and create the corresponding method like so:

# app/models/my_model.rb
def serial_number
  "L#{id.to_s.rjust(8, "0")}"
end

Don’t you just love regular expressions?

Prevent Devise from sending confirmation emails

Sun, 26 Jan 2020 00:00:00 +0000

I am about to release a huge rails project I have been working on for quite a while. This project is meant to replace an old app that manages a database of customers with emails. The new rails project uses Devise for authentication.

Before we push the final update to the production server, we need to find a way to import the users without sending confirmation emails, but still keep them unconfirmed until they actually login to the new system and provide a password. New registrations should also still be confirmable.

So I had to find a way to override an instance method. This is easy to do with a simple module:

# Module to be included in a User instance whenever we don't want to send an email
# Useful when importing users or for testing
module SkipConfirmationEmail
  def self.included(base)
    base.send(:include, InstanceMethods)

    base.class_eval do
      alias_method :send_confirmation_instructions, :return_false
    end
  end

  # Instance methods
  module InstanceMethods
    def return_false
      false
    end
  end
end

What this basically does is alias the send_confirmation_instructions method to a new return_false instance method we can inject into our model like this :

user = User.new
user.send(:include, SkipConfirmationEmail)

user.send_confirmation_instructions
#> false

Therefore, my users will still have to confirm their account at first login on the new system, but won’t be notified when I import the database a few days before launch.

This can easily be adapted to serveral use cases, whenever you need to override an instance method in an exisiting Ruby class, as seen in this GitHub gist.

Ruby on MoskitoHero

An introduction to Barley, the fast model serializer

The story

Sharing is caring

The Features

In the model you want to serialize

Defining the serializer

1. Attributes

2. Associations

Wrapping it up

Ruby Best Practices - Method Arguments

Tip 1: Optional arguments go last

Solution: move optional arguments to the end

Tip 2: Use keyword arguments (aka kwargs)

Solution: switch to keyword arguments when you hit 2+ optional params

Ninja-level tip — the clean coder’s take:

Example:

Love your error messages as thyself

Stack Overflow overflow

RTFEM!

Learn to love your error messages

Writing code for your future self

Meaning

Names

Method length

Stories

One-liners

Be explicit

Be methodic

Tests

A word about comments

Conclusion

An alternative to the ActiveRecord after_initialize callbacks

Chaining conditions in regular expressions

Prevent Devise from sending confirmation emails