Author at Infinum Building digital products Fri, 10 Apr 2026 14:51:20 +0000 hourly 1 8013https://infinum.com/uploads/2020/12/code-quality-rubocop-0.webp Improve Code Quality with RuboCop https://infinum.com/blog/code-quality-rubocop/ Fri, 11 Dec 2020 11:20:00 +0000 Marko Ćilimković https://infinum.com/the-capsized-eight/code-quality-rubocop/ Cleaner pull requests, automated knowledge sharing, and easy engagement with open-source software? Sign me up!

The post Improve Code Quality with RuboCop appeared first on Infinum.

]]>

Modern code reviews are considered a key component in the development lifecycle of any IT organization.

Yearly case studies performed by various researchers report that it’s one of the main methods for improving code quality, sharing knowledge across the team, increased collaboration as well as greater adherence to coding standards.

Unlike Fagan’s code inspection design introduced in 1976, most of us employ a more lenient process, which is:

  • informal
  • asynchronous
  • tool-based
  • focused on reviewing code changes

Results from multiple analysis have shown that the latent defect discovery rate is about 30% in case of informal reviews, proving them to be very effective. They are also a great source of knowledge, because the process usually entails multiple developers collectively looking at a problem and the possible solution.

However, code reviews can become quite cumbersome for newcomers, especially if you find yourself in a company that has some tribal knowledge, which is usually the case.

Tribal knowledge is any unwritten form of how a process should work, or in our specific case, how to produce code. And there can be quite a lot of it, spanning from syntax preferences to unwritten rules and established conventions, which in turn results in code reviews containing dozens of comments that could have been avoided.

That kind of noise takes a lot of focus from the business logic and design. It further elongates the code review process as each back and forth takes additional time due to the asynchronous nature of the process.

A solution to this problem are linters and if you chose Ruby as your programming language, chances are high that you already used RuboCop.

RuboCop linter

Linters are tools used during development that warn the programmer about formatting and adhering to a set of rules.

The warnings are usually related to syntax, but the Ruby community went a step further and introduced a couple of behavioral ones like rubocop-rails that can even spot unwanted behaviour for you.

If you think about it, why wouldn’t you want automatic warnings when you introduce a bug…before the code is shipped. It sounds amazing!

A very cool behavioural cop is the Rails/UniqueValidationWithoutIndex, which detects model uniqueness validations and checks if the uniqueness constraints are also set on the database level. In the following example you can see how the warning looks like if you forget to add the unique index during database migrations.

This concept opens up a lot of ideas and opportunities for a company to create a code convention template that is shared throughout all projects. This increases technical cohesion on a team level and ensures that everyone is roughly on the same page when it comes to conventions and best practices.

Let’s look at a specific code example in Rails that declares the attribute confirmed_at on a User and it defaults to the current time. The Attributes API provides just what we need:

class User
  attribute :confirmed_at, :datetime, default: Time.zone.now
end


pry> User.new
=> #<User id: nil, confirmed_at: Tue, 27 Oct 2020 11:39:22 UTC +00:00

At first glance, this looks totally fine, but if you don’t write thorough tests, the bug can be hard to catch, even during code reviews. Look at what happens for every new user:

pry> User.new
=> #<User id: nil, confirmed_at: Tue, 27 Oct 2020 11:39:22 UTC +00:00
pry> User.new
=> #<User id: nil, confirmed_at: Tue, 27 Oct 2020 11:39:22 UTC +00:00
pry> User.new
=> #<User id: nil, confirmed_at: Tue, 27 Oct 2020 11:39:22 UTC +00:00

Time.zone.now is being passed as a value to the default option, and since attribute is a class method, the value of Time.zone.now is set at the moment when the application is booted. This means that all values will be the same regardless of the return value of Time.zone.now at the time of code execution.
The solution is defining confirmed_at dynamically:

class User
  attribute :confirmed_at, :datetime, default: -> { Time.zone.now }
end

This is a perfect example of tribal knowledge. You either learn to avoid it by breaking production, writing very thorough unit tests or by having someone more experienced mention it during the code review.

Now imagine someone’s watching over your code as you type it, without the awkward presence of course, and giving you real time feedback to avoid such pitfalls. This is exactly what RuboCop’s cops provide us with. In order to be able to build such a layer of protection, you first need to understand how the source code gets converted into data structures.

Abstract syntax tree

AST is a tree representation of the written source code. Each node of the tree denotes a piece of the source code, which can be any literal, object, constant or any other construct used in the programming language.

Let’s take a look at some simple examples of Ruby constructs and how their AST looks like.

For this, the parser gem is used. After installing it, you can jump into your terminal and start playing around:

ruby-parse -e &#8217;1&#8217;
(int 1)

ruby-parse -e &#8217;”1”&#8217;
(str “1”)

ruby-parse -e &#8217;:key&#8217;
(sym :key)

ruby-parse -e &#8217;[]&#8217;
(array)

ruby-parse -e &#8217;{}&#8217;
(hash)

The basic constructs are pretty straightforward. We get a readable description of the code, which tells us that 1 is an integer with value 1, while “1” is a string with value “1”. We can see that this continues to be the case in more complex expressions:

ruby-parse -e &#8217;[1, 2, 3]&#8217;
(array
  (int 1)
  (int 2)
  (int 3))

ruby-parse -e &#8217;{username: “john”, password: “doe”}&#8217;
(hash
  (pair
    (sym :username)
    (str "john"))
  (pair
    (sym :password)
    (str "doe")))

If you haven’t grasped what’s going on, it really helps reading the Ruby code out loud. Take a look at the last example and try reading every bit of Ruby code in the most descriptive way possible. I said it the first time like this:

I have a hash that contains 2 elements, where the first element key is :username and value is “john” and the second element key is :password and value is “doe”.

This is not explicit enough, because I didn’t specify the primitive type of the key (symbol) and value (string) of the elements.

So, let’s investigate the AST of our example:

ruby-parse -e &#8217;attribute :confirmed_at, :datetime, default: Time.zone.now&#8217;
(send nil :attribute
  (sym :confirmed_at)
  (sym :datetime)
  (hash
    (pair
      (sym :default)
      (send
        (send
          (const nil :Time) :zone) :now))))

Looks familiar, doesn’t it? It’s a combination of all the nodes we’ve parsed in the previous examples. Any class that inherits ApplicationRecord or includes the AttributesAPI module can receive the attribute message that accepts 3 arguments:

  • symbol confirmed_at
  • symbol datetime
  • keyword argument :default with any value (in our case Time.zone.now)

The AST concept gives us the ability to convert source code into data structures. Now we just need another tool that will traverse the tree and find specific nodes in Ruby using pattern matching, or maybe regular expressions?

Node pattern

Fortunately for us, this problem has also been solved with the Node pattern. It is a DSL for finding specific nodes in the AST using simple strings.

This is the last step before diving into the implementation of a custom cop – finding the right string that will match against a specific AST. Here are some examples of the Ruby code, AST, and the pattern.

The only real difference between the AST and the pattern is nil?, which is a special case predicate that matches against nil objects. Bear in mind that the goal is to match arbitrary code to these patterns, not just our specific examples in the table. We need to take great care of warning of invalid cases while keeping the valid usages unaffected:

attribute :role, :string, default: :user
attribute :role, default: :user
attribute :active, :boolean, default: true

Sandi Metz gave an excellent talk on RailsConf in 2015, where she stated:

You can reveal how things are different, by making them more alike.

By putting this quote to use, we can spot the static nodes in an infinite range of code possibilities and reveal the pattern:

attribute :any_name, :optional_argument, default: any_construct
  • attribute – the class method that never changes, so we keep this as “attribute” in the pattern
  • any_name – doesn’t really concern us, as long as it is there because the API requires it as a method parameter. This fits the bill nicely for the _ matcher. It will fit any single node.
  • optional_argument – also doesn’t matter what it is, but it doesn’t have to exist. The “?” matcher limits the match to 0 or 1 nodes, and when used in conjunction with “_” you effectively create a pattern for any optional construct “?_”
  • default – the Attributes API also receives keyword arguments, but we are only interested in the hash when the first node is a symbol with value “default”. This is covered in the Abstract Syntax Tree chapter by parsing the hash.
  • any_construct – this is the target we are interested in. If we can get the type of this node we’ll be able to warn the developer for offending cases like a method call, array or hash, because none of those should be used on the class level, since we’re creating an attribute that will be used on the instance level. The $ matcher captures the node, making it available for processing.

Let’s use the information and write the pattern that would fit the bill for all cases:

(send nil? :attribute
  _
  ?_
  (hash
    (pair
      (sym :default)
      $_))

At this point, you should be confident enough to start writing some code.

Creating the cop

We love writing tests, especially when the tests are fast and easy to understand.

RuboCop provides a beautiful DSL for testing cops but unfortunately a lot of articles found online don’t have the information how to set up cop tests. Don’t worry, we’ve got you covered this time!

Here are some tips for setting up RSpec cop tests:

Make sure RuboCop is in your Gemfile and bundled up.

Open spec/rails_helper.rb and add:

require &#8217;rubocop&#8217;
require &#8217;rubocop/rspec/support&#8217;

Include it globally or specific category of tests (eg. type: :cop):

RSpec.configure do |config|

  config.include RuboCop::RSpec::ExpectOffense

  # rest of your rspec configuration
end

The ExpectOffense module provides us with a beautiful way of writing clear and descriptive cop tests. They resemble the actual Ruby code you’re trying to cover:

#spec/cop/rails/attribute_default_block_value_spec.rb

describe Cop::Rails::AttributeDefaultBlockValue do
  subject(:cop) { described_class.new(config) }

  let(:config) { RuboCop::Config.new }
  let(:message) { &#8217;Pass method in a block to `:default` option.&#8217; }

  it &#8217;disallows method called from other objects&#8217; do
    expect_offense(<<~RUBY)
      attribute :confirmed_at, :datetime, default: Time.zone.now
                                                   ^^^^^^^^^^^^^ #{message}
    RUBY
  end
end

Now we can create the cop:

#lib/cop/rails/attribute_default_block_value.rb

module Cop
  module Rails
    class AttributeDefaultBlockValue < ::RuboCop::Cop::Cop
      MSG = &#8217;Pass method in a block to `:default` option.&#8217;
      TYPE_OFFENDERS = %i[send array hash].freeze

      def_node_matcher :default_attribute, <<~PATTERN
        (send nil? :attribute _ ?_ (hash <$#attribute ...>))
      PATTERN

      def_node_matcher :attribute, &#8217;(pair (sym :default) $_)&#8217;

      def on_send(node)
        default_attribute(node) do |attribute|
          value = attribute.children.last
          return unless TYPE_OFFENDERS.any? { |type| value.type == type }

          add_offense(node, location: value)
        end
      end
    end
  end
end

RuboCop::Cop::Cop provides a bunch of stuff that’s used in all class instance cops.

The def_node_matcher method is used for matching nodes. It requires the name of the matcher and the matching pattern. In the example above I used matcher chaining, but you can just as easily use one matcher with the AST that was defined at the end of the previous chapter:

def_node_matcher :default_attribute, <<~PATTERN
  (send nil? :attribute
    _
    ?_
    (hash
      (pair
        (sym :default)
        $_))
PATTERN

Callback methods (on_send, on_block, on_class etc…) check whether a node is matched against a pattern. You know what callback to use from the first node AST, which in our case is send. We used def on_send(node).

Inside of the callback methods you usually start off with the matcher name defined in def_node_matcher in order to get the offending construct. When calling default_attribute(node), you get an instance of a type of RuboCop::AST::Node that knows its type and node children, alongside other things.

The add_offense method provides an easy way of adding a warning message, defining the error positioning (^^^) and the severity of the error:

  • refactor
  • convention
  • warning
  • error
  • fatal

I advise you to look at the RuboCop source code, because it’s really nicely documented and there’s a lot of examples for learning. The rest is just…Ruby.

Lastly, include your new cop in .rubocop.yml.

require:
  - ./lib/cop/rails/attribute_default_block_value
  - rubocop-infinum

Upon reopening or changing a file, you should see the new cop in action.

Want cleaner pull requests?

Code reviews are important and the discussions should focus on strategies used to solve the domain-specific problem, finding edge cases, and pointing out possible design or test improvements. They should have a minimum number of comments related to project conventions, as well as company code conventions, typos, or syntax errors.

Having a quick feedback loop in your IDE enables all of that, while being much more effective time-wise than PR reviews.

Another benefit is the feeling of accomplishment when your custom cop gets recognized as useful and gets promoted from a project-specific cop to a company-specific one. Maybe it will even get merged with the other cops to serve and protect codebases all around the world.

We use RuboCop at Infinum and have only started down this road, but we see a lot of benefits. Having cleaner pull requests, automated knowledge sharing and being able to engage with open source software makes it a no-brainer.

The Ruby community is one of the nicest programming-language-related communities out there and we should all actively search for ways to improve it and help other fellow developers write good, clean code.

The post Improve Code Quality with RuboCop appeared first on Infinum.

]]> 8069https://infinum.com/uploads/2017/02/analyzing-rubygems-stats-v2016-0.webp Is Ruby Dead? Hell No! Analyzing RubyGems Stats for 2016 https://infinum.com/blog/analyzing-rubygems-stats-v2016/ Tue, 17 Jan 2017 16:25:00 +0000 Marko Ćilimković https://infinum.com/the-capsized-eight/analyzing-rubygems-stats-v2016/ JavaScript frameworks are growing in number, new languages are developed faster than ever, and people are still talking about the death of Ruby and Rails.

The post Is Ruby Dead? Hell No! Analyzing RubyGems Stats for 2016 appeared first on Infinum.

]]>

Another year is behind us and many things have changed in the web development world – the number of JavaScript frameworks continues to grow, new programming languages are being developed faster than ever and people are still talking about the death of Ruby and Rails.

We did a little research on the use of Ruby gems and created some stats for 2016 which prove otherwise.

Sources

At the beginning of last year we used the official Rubygems data dumps which consisted of a Postgres database and a Redis store to create an overview of the Ruby ecosystem in 2015. Due to Rubygems simplifying their stack, we could no longer access some of the data we collected the previous year because their Redis instances were shut down.

However, we still used their Postgres database dump for some of the stats. Additionally, we used BestGems’ API which provided us with a daily insight into the total number of downloads for any gem we were interested in.

Gem creation continues to fall

With only 16.000 gems created this year compared to 26.000 in 2014, one could assume that something is not right. My opinion is twofold. Nowadays, web development is changing rapidly, and requests for web applications are becoming more complicated. This makes our code more complicated, and therefore developers find other ways of producing code, which results in the creation of other frameworks and languages.

But the language’s stability also plays a big role. We don’t need to create new gems because a version of a gem that does exactly what you need probably exists already.

Gem releases going down

This is strongly correlated to the first trend. Fewer gems created, fewer bugs, fewer version releases.

Rails downloads are still increasing

If we compare the stats with last year’s, there’s an increase of 46% with an obvious spike in July due to the release of Rails 5.0. Unfortunately, because of Rubygems’ stack simplification we couldn’t get the numbers for each Rails version. But, by using a little math, we calculated that there were around 1.78 million downloads of Rails 5 and around 2 million downloads of Rails 4.2.7. The rest went to prior versions.

Rails alternatives in 2016

Sinatra – used 95% less than Rails

Sinatra is being used 95% less than Rails, which is not bad at all considering Rails is the number one go-to framework for Ruby. Comparing the numbers from 2015, we can see an increase of 15%, which translates to 2 million more downloads. Also, the average download count in 2016 was around 1 million, which was the peak in 2015.

Other frameworks have a much lower download count

Padrino, Sinatra’s godfather, had many additions and fixes, including support for Ruby 2.3. Overall, it grew slightly in its total download count but still lacks active users.

Volt, the Ruby framework in which Ruby code runs on both the server and the client via Opal seems to be stagnating since there were no releases nor commits in 2016.

Lotus, a tiny web framework with a more object-oriented style than Rails, had to change its name to Hanami, because of IBM’s Lotus Software. Despite having a stable version and a bigger community than in 2015, it still lacks users.

Database Adapters

Interestingly, Postgres usage blew up in 2015 and left MySQL behind, and even though its download count rose even more in 2016, MySQL almost caught up with just around 2 million downloads less during the whole year.

Mongo’s usage remains consistent, with a slight increase, but it holds 1st place in the NoSQL databases category.

Application Servers

Thin, Puma and Unicorn are obviously being downloaded more and more with each passing month. Thin is surprisingly still in 1st place, but Puma will probably surpass it, since Heroku listed it as the recommended web server, and it replaced Rails’ default web server WEBrick with the release of Rails 5.

Passenger is stagnating at approximately 100k downloads per month. However, it also comes as a standalone Unix package, so the stats are probably higher.

Sequel – amazingly amazing

Apparently, developers just love writing code without having to resort to custom SQL queries. The awesomely flexible Sequel database access toolkit for Ruby remains stable and is very well supported (0 issues, 0 pull requests) with releases coming on a monthly basis.

Interestingly, in 2015 they had an 180% increase in usage, which means it was downloaded a bit below 300k times per month. In 2016, it was downloaded 450k times per month on average. Awesome work, Jeremy!

RSpec – The New King of Testing

If I had to single out one thing that was talked about the most in the world of Rubyists in 2016, it’s testing! Testing does save your bacon, and according to stats, we do love our bacon.

Minitest is still a runtime dependency for many gems such as ActiveSupport or Sinatra which makes the download count increase monthly, but RSpec had more downloads in November and December. This proves that developers choose to install another testing framework and hopefully don’t leave only the scaffolding lines in their testing files.

We investigated why the sudden rise happened in August, but couldn’t figure out the cause. We assume that a gem that had RSpec as a runtime dependency became very popular at that time.

Background Workers

Sidekiq really is faster than its competition! With the release of 4.0 in late 2015 that removed a lot of dependencies and was completely refactored for performance, it’s clearly visible how it impacted Ruby developers, with nearly two times more downloads than in the previous year.

Resque and Delayed job mostly stayed the same throughout the whole year.

Authentication aka Devise for Rubyists

With Devise being the de facto Rails authentication solution, no other authentication layer could even compete. I compared its usage in 2015 and 2016, and both results reflect its increasing popularity, counting more than 6.5 million downloads.

Authorization – CanCanCan VS Pundit

In last year’s blog post Damir stated Pundit should be preferred over CanCanCan. With its nice object-oriented minimal authorization, it almost caught up with CanCanCan at the end of the year, showing how Rubyists have good taste when it comes to code structure and architecture.

Administration Frameworks

Rails is a popular web framework for many reasons, one being that it also provides many choices for developers when tailoring the administration interfaces for their web applications. If you have simple model relations and a ‘straight-forward’ blog-like website, it is advisable to use one of the gems that provide you one.

The two most used UI frameworks, ActiveAdmin and RailsAdmin, are reaching their highest usages ever, with more than a 60% increase in downloads in 2016.

Content Management Systems

Discussing Content Management Systems can be quite misleading, since they usually depend on the architecture and business logic of a project. I advise you not to make decisions based on graph stats, but rather test them out for yourself and see what suits your specifications best.

We crunched the numbers for the most used ones, and there were no great differences when compared to previous years.

RefineryCMS is a well known CMS that is designed for end users to create all of the website content. It is simple to use, flexible when designing and extendable.

AlchemyCMS is more developer-oriented because it is more flexible in certain situations. Only the content itself is manipulated by the end user, not the HTML attributes of the page. Everything else is persisted to the database.

LocomotiveCMS uses Wagon, a command line tool for creating pages and other content on your local machine. It has a very flexible and nice admin interface, a great community but unfortunately not a lot of users.

Pagination

This comparison surprised me since I’m a Rails developer coming from the online school of Michael Hartl that gives an example of pagination using the will_paginate gem. However, looking at the usage statistics from previous years, kaminari was always in the lead. If you haven’t heard about it, definitely give it a try. It provides a clean, flexible solution with scopes that is also highly configurable.

File upload Solutions

Even though Paperclip leads with the total number of downloads, CarrierWave took over in October with a positive trend continuing in January 2017. CarrierWave is much more flexible and offers many options in its configuration. If you’re interested, check out our detailed overview of FileUpload solutions.

Deployment Tools

Lastly, as you might expect, Capistrano remains the number 1 deployment tool with over 300.000 downloads monthly. Since it has no close competition, we compared its usage statistics from 2015 and 2016. There was an increase of more than 20% with over 3.5 million downloads.

Aggregated stats for 2016

  • Rails was downloaded more than 24 million times
  • 44 gems were released per day
  • 332 gem versions were released per day

Conclusion

PHP, Java and Ruby now have one thing in common: despite obvious usage trends, everybody keeps talking about their deaths.

We are living in an era when anything slightly popular, if exploited properly, can explode and be in the spotlight for a certain amount of time. This used to be the case with Ruby on Rails. However, after many years the hype is going down.

All programming languages are good for something, but none are perfect for everything, and Rails still has its place.

Despite the rise of Ruby on Rails alternatives, developers still appreciate the benefits of a large and stable ecosystem with a mature community and easily choose a turn-key solution like Rails for rapid web development.

And Rails is keeping up with trends – Rails 5 has a pure API mode now, Yarn support, Webpack support and we’re glad it’s going in that direction. These three changes will help us a lot because they make up the outline of how we build web apps at Infinum.

Read, study, examine, try. Find a language that fits you most and if one doesn’t work, repeat those steps. Rails isn’t going anywhere anytime soon.

The post Is Ruby Dead? Hell No! Analyzing RubyGems Stats for 2016 appeared first on Infinum.

]]>