DEV Community: Ali Ilman

8 Tips on Giving Effective Code Reviews

Ali Ilman — Thu, 07 Jan 2021 03:17:00 +0000

A pull request isn't just the responsibility of the author, but also the reviewer. In this article, I'll be sharing 8 tips on giving effective code reviews.

1. Practice conventional comments

I've been practicing conventional comments for around 6 months. I find it to be a good practice. Here are a few reasons.

The intention of our comment is clear
The separation between the topic of the comment and the example and / or reasoning of the comment is clear
The author knows what they should prioritise on because our comments are well-labelled

2. Suggest changes by masking them as questions

When we mask our suggestions as questions, they can be thought-provoking to the author and the tone of our suggestion is highly likely to come across as friendly. Here are a few examples.

What if we rename this boolean variable from invitationAccepted to hasUserAcceptedInvitation? hasUserAcceptedInvitation is more clearer than invitationAccepted.
Since we're doing ${address.city}, ${address.country} more than once throughout these files, how about moving this combining of city and country into the Address class?

3. Add an example in our suggestion

Adding an example in our suggestion can be more beneficial than leaving just a reason. An example coupled with a reason might just give the author a eureka moment. 💡

4. Replace 'you' with 'we'

The effect of using 'we' instead of 'you' with people that know us well may not be significant, but with people we've not worked with before, it can provide a psychological difference, especially to those new to the industry. It can make them feel welcomed and makes the code review feel like a learning session.

5. Mind your nitpicks

Some nitpicks are necessary, but some of them are not. A code review filled with unnecessary nitpicks can affect the author's self-esteem and might even make us look unkind. How do we decide when to nitpick?

I suggest asking ourselves whether the code we're reviewing is misleading.

Is there a typo on user-facing content or a variable with a misleading name? If there is, it is a necessary nitpick.

Is our suggestion purely a stylistic change that makes no positive difference in readability? If it is, then it is an unnecessary nitpick.

But what if we want to enforce a convention within the codebase such as using double-quoted strings?
Then this should be taken care of by a linter. In JavaScript, there is ESLint. In Ruby, there is RuboCop.

6. If you're reviewing code, dedicate some time for it, don't rush

Reviewing code is also a part of the job. When we do our code review in haste, it's easy for sneaky bugs to slip through. If you're in a rush, I suggest doing the code review later if it's not urgent.

7. Use emojis and GIFs!

Most of the time, we communicate with the author of the pull request through text. It's easy for them to misinterpret our comments negatively, especially if we don't know each other well. Using emojis and GIFs can keep the atmosphere warm. Though please avoid leaving sarcastic emojis or GIFs because sarcasm doesn't transfer well through text. 😁

8. Leave a summary when necessary

Sometimes, we encounter some code that are similar and require similar changes. We shouldn't be leaving the same comment more than a few times as it can make the author feel overwhelmed. Instead, leave a summary. Here's an example.

The rest looks good to me! Just a few minor suggestions.

Link to code block A

Link to code block B

Link to code block C

Link to code block D

These blocks of code are doing the same thing. How about creating a reusable method?

Summary

When we review code, the objective isn't just to tidy up code and then merging the pull request for the sake of keeping a project moving. A code review is also a place for learning. Not just for the author, but also for the reviewer. Making ourselves approachable is one way of making code review a fun process.

If you find this article helpful, please spread the word! If you're looking for tips on opening effective pull requests, this article is just for you!

Do follow me on Twitter to read about my findings while programming or my feelings of joy and despair while watching football. I'm also active on Instagram and Goodreads where I frequently share what I'm reading and what I've read.

Thanks for reading! ✌️

3 Tips on Opening Effective Pull Requests

Ali Ilman — Mon, 14 Dec 2020 09:07:34 +0000

When I first started working almost 3 years ago, I couldn't see the need to include anything in the description of my pull requests. I had felt that the title is enough. In some cases, this is true. But in other cases, a Fix broken ABC feature sounds vague to code reviewers. Being provided at least some context about the pull request can be helpful.

In this article, I'll be sharing 3 tips on opening effective pull requests.

1. Describe why you made the changes

Describing our changes is a great way to provide the context of the pull request (and commit). It can be helpful now and in the future. Here are reasons why. 👇

The reviewer can view the pull request from a certain angle, providing potentially better suggestions
Tracking down bugs in the future are easier as we would have an idea as to why certain changes were made

2. Keep the pull request small

When a pull request is big, the reviewer can feel overloaded with information. When this happens, it can affect how the reviewer views the correlation between a piece of code with another and worse, a sneaky bug can slip through. But when exactly can a pull request be considered as big?

We can use this study as a guide and follow our instincts because pull requests are unique.

A SmartBear study of a Cisco Systems programming team revealed that developers should review no more than 200 to 400 lines of code (LOC) at a time. The brain can only effectively process so much information at a time; beyond 400 LOC, the ability to find defects diminishes.

How should we decide to keep our pull requests small? Ask ourselves this question whenever we think about fixing a bug or implementing another feature altogether.

Can this be done separately? If yes, then do in a separate pull request.

3. Write a changelog

Unlike my first two tips, this is rather insignificant. Before I started describing my changes, I tend to just include a changelog to give the reviewer an idea of what to expect. Nowadays, the changelog acts as an addition to my description. A changelog could look like this.

If you find this article helpful, please spread the word!

Thanks for reading! ✌️

What is a Kubernetes Object

Ali Ilman — Mon, 17 Aug 2020 00:13:41 +0000

A Kubernetes object is something that exists in a Kubernetes cluster. There are configuration files we can write, and these files are used to create Kubernetes objects.

In Kubernetes, there are object types. An object type has its own purpose.
An example of an object type is the Pod object type. Pod is used to run a container.

To specify an object type in a Kubernetes config file, we use the kind property.

kind: Pod

Resources

https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/

What is a Kubernetes Cluster

Ali Ilman — Wed, 12 Aug 2020 11:12:04 +0000

A Kubernetes cluster is a group of machines that are connected to each other to work as a single block.

A Kubernetes cluster consists of two resources.

The Control Plane
The Nodes

The control plane and the nodes communicate with each other through the Kubernetes API.

The Control Plane

The control plane is responsible for managing our cluster. It can be deployments, scaling etc.

The Nodes

A node works as a machine within a Kubernetes cluster. A node runs an application, and it handles container operations through Docker. A node can be either a virtual machine or a physical computer.

The String#chars method

Ali Ilman — Sun, 26 Apr 2020 13:46:05 +0000

Originally published on https://ali-ilman.com/blog/the-string-chars-method.

I was browsing the web and I noticed Ruby code that utilises a String instance method called chars.
Until today, I'd never used nor heard of String#chars. What does it do?

String#chars is used to return an array of characters within a string.

name = 'Ali'
name.chars
=> ["A", "l", "i"]

Do note that it does not work similarly to String#split, although we can achieve the same result.

name = "Ali"
name.split('')
=> ["A", "l", "i"]

So how are String#chars and String#split different to each other?

String#split uses a regular expression to divide characters within a string, thus returning an array.

String#chars parses the byte of each character within a string and then it returns an array.

Cheers for reading! 🤓

Specifying a Template and a Layout through Action Mailer's mail function

Ali Ilman — Mon, 13 Apr 2020 14:52:51 +0000

Originally published on https://ali-ilman.com/blog/specifying-a-template-and-a-layout-through-action-mailer-mail-function.
Photo by Mikaela Wiedenhoff.

In this article, we'll take a look at one of the lesser-known features within Action Mailer, that is specifying a template and a layout through the mail function. This can come in handy if we want to display specific content for certain emails without creating unnecessary mailers. 🧠

Specifying a template

There are a few ways to specify a template through the mail function. The mail function accepts keyword arguments called template_path and template_name.

`template_path`

template_path is for telling Action Mailer which folder to use to look for a template. template_path can either be a string or an array.
Action Mailer will start looking for the specified template_path from within app/views folder. Let's say, our template_path is set to invitations. Then, Action Mailer will look for app/views/invitations folder.

`template_name`

template_name is for telling Action Mailer the name of the template that we want to use.

Examples

The first example here shows how we can use a template called welcome that sits inside of app/views/mailers/user_mailer/special folder. The template_path here is a string.

class UserMailer < ApplicationMailer
  def welcome(user)
    email = user.email

    mail(to: email, template_path: 'mailers/user_mailer/special')
  end
end

The second example here is similar to the above, but template_path is an array. It's an array of path to folders. Action Mailer will look for the welcome template by starting on the first folder, app/views/mailers/user_mailer/non-special. If the template is not found, Action Mailer will move onto the next folder, app/views/mailers/user_mailer/special, which is where our template sits. Here, Action Mailer will stop looking for the template folder and send the email.

class UserMailer < ApplicationMailer
  def welcome(user)
    email = user.email

    mail(
      to: email,
      template_path: ['mailers/user_mailer/non-special', 'mailers/user_mailer/special', 'mailers']
    )
  end
end

The third example here shows how we can use a template called special_welcome instead of welcome. special_welcome sits inside of app/views/mailers/user_mailer folder

class UserMailer < ApplicationMailer
  def welcome(user)
    email = user.email

    mail(to: email, template_name: 'special_welcome')
  end
end

The fourth example here shows that we can specify both template_name and template_path! This will look for a template called special_welcome inside of app/views/mailers/user_mailer/international_launch folder.

class UserMailer < ApplicationMailer
  def welcome(user)
    email = user.email

    mail(
      to: email,
      template_name: 'special_welcome',
      template_path: 'mailers/user_mailer/international_launch'
    )
  end
end

The fifth and last example here shows that we can specify the name and location of the template by passing a block to the mail function. Within the block, we can determine what to render for html, which is basically the content of the email.

One of the keyword arguments accepted by render is template.

class UserMailer < ApplicationMailer
  def welcome(user)
    email = user.email

    mail(to: email) do |format|
      format.html do
        render template: 'mailers/user_mailer/international_launch/special-welcome'
      end
    end
  end
end

Specifying a Layout

Another keyword argument accepted by render is layout.

Example

The example here shows how we can use a layout called yet-another-layout. Action Mailer will look for the layout from within app/layouts folder.

class UserMailer < ApplicationMailer
  def welcome(user)
    email = user.email

    mail(to: email) do |format|
      format.html { render layout: 'yet-another-layout' }
    end
  end
end

Specifying both the layout and template at once

Yup! We can specify both of them. 😉

Example

The example here will use a layout called yet-another-layout in app/layouts folder and a template called yet-another-template in app/views/mailers folder.

class UserMailer < ApplicationMailer
  def welcome(user)
    email = user.email

    mail(to: email) do |format|
      format.html do
        render layout: 'yet-another-layout', template: 'mailers/yet-another-template'
      end
    end
  end
end

Cheers for reading! 🤓

8 Things I Have Learned After 2 Years of Work

Ali Ilman — Mon, 06 Apr 2020 17:16:45 +0000

Originally published on https://ali-ilman.com/blog/8-things-i-have-learned-after-2-years-of-work.

It has been two years since I started working as a software engineer. Prior to that, I had been an intern for 3 months at the company I've been working for. There's more to being a software engineer than just writing code and pushing to GitHub repositories.
In this article, I'll be sharing some of the things that have helped me become a better software engineer and a better person, tips that you can apply or serve as a base for you to achieve your goals, and things I only realise after I started working. 🧠

1. The internet is your best friend

No matter how experienced you are, you will always end up browsing the web looking for a method name. And this is all right! No one knows everything, and no one remembers everything. What's important is that you understand what you're doing with the code. Through this, I realised that googling is a skill.
And yes, using StackOverflow isn't cheating. Don't be like me who thought it's cheating to use StackOverflow. 🤦‍♂️

2. You will learn on-the-job

There will be methods, classes and libraries you've never used or heard of. Imagine a feature where you can use a library called XYZ to aid the implementation, but you never heard of XYZ before. Start by going through the documentation and playing around with the library. Then, use it to implement the feature.

3. Get involved with the community

Is Ruby the main programming language that you use? Are you a React wizard? There are meetups for people who use or are curious about these technologies! You get to meet like-minded people and make new connections, you get to gain knowledge from talks. And if you've something to share, you can always get in touch with the organisers and tell them that you're interested in giving a talk. It's good to give back.

4. Don't get too excited to implement a feature or a bug fix

It's easy to feel excited to start working on a feature or a bug fix when it's ready to be implemented. This can be a misconception of what you should be doing as you're eager to get going. Instead, try to understand what needs to be done, and think how this can be implemented in the cleanest way possible.
Keep in mind that it's easy to overthink about keeping the code clean as there are many ways to implement something, so don't waste too much time on this. We could ask our teammates for their opinions, and there are always code reviews.

5. Don't be aggressive in code reviews

One of the things I've learned about code reviews is to not approach them aggressively. This can be in your choice of words and / or the intonation of your words. Remember, a code review isn't just for tidying up code. A code review is also a way for you and the author of the code to improve as engineers. Build each other up. 💪
A personal rule of mine is to not use GitHub's Request changes when submitting a review. I feel it can make the person who wrote the code feel less confident or make their suffering of imposter syndrome even worse.

6. Ensure that your pull requests are descriptive

There will be bug fixes, enhancements and features being implemented. Writing a descriptive pull request will give the reviewers the context of the pull request, which can result in effective improvements to the code.

7. Self-care is important

One of the topics I've seen people talk about is whether you should code in your free time.
Can working on side projects in your free time help you become a better engineer? Yup. But should you be doing this? This is for you to decide. Only you know your body well. A good rest is important. And most importantly, don't forget to spend time with your loved ones.

8. Build up fellow engineers

Remember, always stay humble. It's easy to let your knowledge negatively control your behaviour. Use your knowledge to build up fellow engineers. 🙂 I encourage you to check out BuildUpDevs.

I hope this article has given you an idea of how it's like to work in the tech industry. Feel free to ask me questions!

Cheers for reading! 🤓

I share the life of a software engineer on Twitter, you might want to follow me. 😉

4 Mistakes I Made When I First Learned How To Code

Ali Ilman — Mon, 30 Mar 2020 15:41:40 +0000

Originally published on https://ali-ilman.com/blog/4-mistakes-i-made-when-i-first-learned-how-to-code.

With my two-year anniversary of working permanently coming soon, I took a look into the past and thought of what were the mistakes that I made in the very beginning.

1. Let completing a course influence how I feel

I was a course champion in the beginning. It felt good knowing that I have completed a course, but I kept going through courses without an idea of which path I wanted to take in the tech industry. I had completed courses on Codecademy and SoloLearn, a couple of tutorials on freeCodeCamp, and the courses were sort of similar.

2. Not writing down notes in my own words

Instead of using my own words, which can test myself on whether I understand what I've learned, I wrote down courses' content word-for-word, including the exemplary code snippets! And I did this for more than a few courses on a few platforms. Ouch!

3. Not going in-depth with concepts I found difficult to understand

I feel this go hand-in-hand with number 1. It felt good completing a challenge for a tutorial, so I continued onto the next tutorial without thinking deeply whether I understand what I've learned.
Because of this, I relearned JavaScript in the second-half of 2019 because I mostly learned JavaScript in the beginning.

4. Built barely anything with what I've learned

When I first started learning, I didn't build much in the first 2-3 years. I can only remember two projects, and they were on Codecademy. For these two projects, I had wanted to mimic the landing page of Twitter and Lowyat. And that's about it. It was only in 2017 in which I started to build projects.

Finishing a course doesn't mean you understand everything you've went through. And remember, learning is lifelong. 🧠

The only true wisdom is in knowing you know nothing. - Socrates

Cheers for reading! 🤓

I share the rumblings of a Man United fan and the life of a software engineer on Twitter, you might want to follow me. 😉

Profiling and Speeding Up Our Rails Test Suite with TestProf

Ali Ilman — Sun, 22 Mar 2020 13:49:13 +0000

Originally published on https://ali-ilman.com/blog/profiling-and-speeding-up-our-rails-test-suite-with-test-prof.

RSpec best practices can only go so far in speeding up our test suite. Are you looking to speed up your Rails test suite? You've come to the right place! In this article, we'll take a look at TestProf, a Ruby gem that provides profilers for analysing our test suite, and helpers to improve the test suite's performance.

How did I end up using TestProf?

A month ago, I gave a go at speeding up the test suite of a project I'm working on. For a bit of background, the project's codebase is almost 6 years old, developers have come and go, new technologies and practices have appeared after all these years. We had a sprint where we can make our lives easier, in other words, enhance the codebase! And we decided speeding up the test suite was one of them. 🕵️‍♂️

The test suite took around 45 minutes (!) to run on my Mac. That's horrendous! 😭 Initially, I applied practices (which you can read about here) that can speed up the test suite, but the improvement was little. It was clear that something else is making the test suite take longer than usual. And that's when I decided to add TestProf to the project.

What are the common causes of a lengthy test suite?

There are a few common causes, and the most common cause is arguably the factory usage. And what is a factory?

A factory generates test data that are used in tests. These data can be an Active Record object, a plain Ruby object and so on.

Factory usage can negatively affect the performance of the test suite because of these two reasons.

1. Creation of records for each test

Wait a minute. Don't we sometimes need to seed our database before running our tests?

Yup, that's correct. But wouldn't it be great if we can create one single record for the entire test file? Let's take a look at the example below. 🤓

# factories/books.rb
FactoryBot.define do
  factory :book do
    title { Faker::Book.title }
  end
end

# requests/books_controller_spec.rb
RSpec.describe BooksController, type: :request do
  let(:book) { create(:book) }

  describe 'GET #show' do
    it do
      get book_path(book)
      expect(response).to have_http_status :ok
    end
  end

  describe 'DELETE #destroy' do
    it do
      delete book_path(book)
      expect(response).to have_http_status :ok
    end
  end
end

As we can see in the code above, the book variable is invoked for each test (it), which means we're telling the book factory to create a book for each test! This is unnecessary for the tests above.

Can't we initialize a @book variable inside of a before(:all) to create a record just once? 🤔 We can, but before(:all) doesn't wrap the tests within a transaction, so nothing is rolled back after they have been ran.
We'll see later on in the article how a TestProf helper allows us to create a record only once and without going through the headache of cleaning our test database.

2. Nested factory invocations

Nested factory invocations can cause factory cascades.

A factory cascade is a term given to the process of creating new associated objects inside of each factory through nested factory invocations. 🧠

Here's an example of factory cascades, copied mostly from test-prof's documentation.

factory :account do
end

factory :user do
  account
end

factory :project do
  account
  user
end

factory :task do
  account
  project
  user
end

create(:task)

What is happening when we tell FactoryBot to create a task?

The task's account is created
The task's project is created, followed by the project's account and user, followed by the user's account
The task's user is created, followed by the user's account.

In overall, four accounts are created even though all we need is one account.

Here's an example of simple nested factory invocations.

# factories/publishers.rb
FactoryBot.define do
  factory :publisher do
    name { Faker::Company.name }
  end
end

# factories/authors.rb
FactoryBot.define do
  factory :author do
    name { Faker::Book.author }
    publisher
  end
end

# factories/books.rb
FactoryBot.define do
  factory :book do
    title { Faker::Book.title }
    author
  end
end

If we were to use the book factory to create a book, it'll invoke the author factory, which in turn will invoke the publisher factory! Do we really need a publisher and an author for all tests? Not really, because some tests can be written with record(s) from only one single model, which in our case is the Book model.

One of the reasons why a factory is used is to help generate data for associations, but at the same time, this can come at the cost of unnecessary factory usage.

How can TestProf help us improve our test suite?

TestProf comes with various of profilers and helpers, but in this article, I'm only going to share the ones that can make a significant improvement to the test suite and the ones that I've utilised. Let's start with the profilers!

1. FactoryDoctor

FactoryDoctor will go through our test suite for any tests that perform unnecessary database queries.
Here's an example.

FDOC=1 rspec spec/services/books/update_availability_spec.rb


Total (potentially) bad examples: 1
Total wasted time: 00:00.018

Book (./spec/models/book_spec.rb:3) (2 records created, 00:00.018)
  is expected to validate that :title cannot be empty/falsy (./spec/models/book_spec.rb:10) – 2 records created, 00:00.018

Finished in 0.12646 seconds (files took 1.18 seconds to load)
2 examples, 0 failures

We can also make FactoryDoctor ignore a test, by adding :fd_ignore to the test.

RSpec.describe Book, type: :model do
  describe '.published' do
    subject { described_class.published }

    it(:fd_ignore) { should eq([]) }
  end
end

There's one thing to be wary of when using FactoryDoctor, though. There's a chance that it'll report false positives and false negatives as it's still learning, so don't always trust it. Dig deeper into certain tests if you're looking to eliminate unnecessary database queries.

2. FactoryProf

FactoryProf will analyse our factory usage, and after the tests have finished running, it'll display the following report.

FPROF=1 rspec spec/services/books/update_availability_spec.rb

Finished in 21.08 seconds (files took 1.15 seconds to load)
3 examples, 0 failures

[TEST PROF INFO] Factories usage

 Total: 6
 Total top-level: 6
 Total time: 0.0515s
 Total uniq factories: 2

   total   top-level     total time      time per call      top-level time               name

       3           3        0.0304s            0.0101s             0.0304s             author
       3           3        0.0211s            0.0070s             0.0211s               book

What does the report show?

The number of times factories were invoked
The number of times factories were invoked (excluding nested factory invocations)
The time spent generating records
The number of factories, in our case is 2 for author and book.

You will love FactoryProf. I was utterly astounded to see the report for the project I work on, I found out that we spent 36 minutes just for generating records! 🤯

Let's move on to the helpers.

1. FactoryDefault

FactoryDefault helps with eliminating factory cascades by reusing associated records.
Going back to the factory cascades example, we can use FactoryDefault's create_default to reuse associated records.

factory :account do
end

factory :user do
  account
end

factory :project do
  account
  user
end

factory :task do
  account
  project
  user
end

create_default(:account)
create(:task)

What is happening here?

An account is created and the same object is reused for user, project and task
The task's account will refer to the one created with create_default
The task's project is created, followed by the reusing of the account, and the creation of user, followed again by the reusing of the account
The task's user is created, followed by the reusing of the account

In overall, only one account is created.

Do be careful with using FactoryDefault, as it can reduce the readability of your tests. 👁

2. before_all

before_all is similar to RSpec’s before(:all). The only difference is that when we use before_all, it wraps the tests within a transaction, thus destroying the records afterwards. For RSpec’s before(:all), we have to destroy the records ourselves through after(:all).

Before

RSpec.describe Book, type: :model do
  before(:all) { create_list(:book, 5) }

  # test
  # test
  # test

  after(:all) do
    Book.destroy_all
    Author.destroy_all
    Publisher.destroy_all
  end
end

After

RSpec.describe Book, type: :model do
  before_all { create_list(:book, 5) }

  # test
  # test
  # test
end

This keeps our tests tidy. 🤓

3. let_it_be

let_it_be works similarly to before_all, with the addition of allowing us to use variables.

Before

# requests/books_controller_spec.rb
RSpec.describe BooksController, type: :request do
  let(:book) { create(:book) }

  describe 'GET #show' do
    it do
      get book_path(book)
      expect(response).to have_http_status :ok
    end
  end

  describe 'DELETE #destroy' do
    it do
      delete book_path(book)
      expect(response).to have_http_status :ok
    end
  end
end

book is invoked twice, thus creating two book records.

After

# requests/books_controller_spec.rb
RSpec.describe BooksController, type: :request do
  let_it_be(:book) { create(:book) }

  describe 'GET #show' do
    it do
      get book_path(book)
      expect(response).to have_http_status :ok
    end
  end

  describe 'DELETE #destroy' do
    it do
      delete book_path(book)
      expect(response).to have_http_status :ok
    end
  end
end

book is invoked twice but only one book record is created.

There is one caveat with using let_it_be.
If we were to a modify record generated within a let_it_be outside of let_it_be, we need to reload or re-find the record. The cost of reloading or querying for a record is still less than generating one.

Before

RSpec.describe Book, type: :model do
  let_it_be(:book) { create(:book) }

  describe '#update' do
    context 'when title is valid' do
      let(:new_title) { 'And Then There Were None' }
      before do
        book.update(title: new_title)
      end

      it do
        expect(book.title).to eq(new_title) # => false
      end
    end
  end
end

After

RSpec.describe Book, type: :model do
  # let_it_be(:book, refind: true) { create(:book) }
  let_it_be(:book, reload: true) { create(:book) }

  describe '#update' do
    context 'when title is valid' do
      let(:new_title) { 'And Then There Were None' }
      before { book.update(title: new_title) }

      it do
        expect(book.title).to eq(new_title) # => true
      end
    end
  end
end

Conclusion

Using TestProf can help speed up your test suite massively. Benchmark your test suite by utilising the profilers that come with the gem, though you might find FactoryProf and FactoryDoctor become your go-to profilers. Then, identify the slowest tests, and try to determine the tests that can gain significant improvement in speed when helpers provided by TestProf are used. Performant tests are a nice-to-have, but don't forget, keep the tests readable.

Cheers for reading and I hope you find this article helpful! 🤓

3 Practices to Apply to Speed Up Our Rails Test Suite

Ali Ilman — Wed, 29 Jan 2020 13:52:05 +0000

When more features are added to our application, the time it takes to run our tests increases. The pain of this is more evident when we work in a team of fellow developers, pushing to the repository and triggering builds on the CI platform multiple times per day! 😭
But don't worry, there are 3 practices we can apply to speed up our test suite!

1. Replace `let!` variables with `let` variables

Why should we replace let! with let? How does using let help speed up our test suite? Let's first take a look at what let! does behind the scenes. 🕵️‍♂️

This is how the let! method looks like in rspec-core's codebase.

def let!(name, &block)
  let(name, &block)
  before { __send__(name) }
end

As we can see, it basically calls let and before. But notice the block passed to before.

{ __send__(name) }

This will invoke the method which is identified by the name parameter before each example is run. Let's move onto to an example!

This service was written as dumb as possible for the sake of this example. 😁 The service returns books that were fetched from a fictional platform called Bibliothek.

module Bibliothek
  class GetBooks
    def self.run
      new.run
    end

    def run
      [
        {
          title: 'And Then There Were None',
          author: 'Agatha Christie'
        },
        {
          title: 'Far from the Madding Crowd',
          author: 'Tom Hardy'
        },
        {
          title: 'This Was a Man',
          author: 'Jeffrey Archer'
        }
      ]
    end
  end
end

And we have this spec for the service above.

describe Bibliothek::GetBooks, type: :service do
  describe '.run' do
    let!(:titles) do
      # An expensive process
      sleep(2)

      ['And Then There Were None', 'Far from the Madding Crowd', 'This Was a Man']
    end
    let(:authors) { ['Agatha Christie', 'Tom Hardy', 'Jeffrey Archer'] }

    subject { described_class.run }

    it 'has 3 book records' do
      expect(subject.length).to eq(3)
      expect(subject.pluck(:author)).to eq(authors)
      expect(subject.pluck(:title)).to eq(titles)
    end

    it { should be_a Array }
  end
end

Even though we're not explicitly invoking titles, the titles variable will be evaluated for each example thanks to the way let! was written.
The time it takes for the entire .run example group to run is 4 seconds on average!

How can we enhance this?

We convert the titles variable from a let! into a let.

describe Bibliothek::GetBooks, type: :service do
  describe '.run' do
    let(:titles) do
      # An expensive process
      sleep(2)

      ['And Then There Were None', 'Far from the Madding Crowd', 'This Was a Man']
    end
    # other code
  end
end

Now, the time it takes is slashed by half! 🎉🎉🎉

The key here is to remember that a let variable is only evaluated when we explicitly invoke it.

2. Write multiple expectations in one single example

Sometimes, it's unnecessary to write an example (it) for each expectation (expect, should etc.).

Although it's cleaner (who doesn't love short one-liners? 😍),
it can affect the performance of our tests.
How?

Say, we have a service that updates the availability of a book.

module Books
  class UpdateAvailability
    attr_reader :book

    def initialize(book)
      @book = book
    end

    def self.run(book)
      new(book).run
    end

    def run
      # An expensive process
      sleep(5)

      book.update(available: !book.available)
      OpenStruct.new(success?: true, book: book)
    end
  end
end

And we have this spec.

describe Books::UpdateAvailability, type: :service do
  describe '.run' do
    let(:book) do
      create(
        :book,
        title: 'And Then There Were None',
        available: true,
        author: create(:author, name: 'Agatha Christie')
      )
    end

    subject { described_class.run(book) }

    it { expect(subject.success?).to be true }
    it { expect(subject.book.available).to be false }
  end
end

The time it takes on average is a staggering 10 seconds! Why is this the case?

The subject is executed for each example, in our case being 2 examples. This is unnecessary, and it makes no sense for us to separate the expectations when they're clearly related to the data returned by described_class.run(book).

What can we do? It's simple. We group all expectations in one example.

describe Books::UpdateAvailability, type: :service do
  describe '.run' do
    let(:book) do
      create(
        :book,
        title: 'And Then There Were None',
        available: true,
        author: create(:author, name: 'Agatha Christie')
      )
    end

    subject { described_class.run(book) }

    it do
      expect(subject.success?).to be true
      expect(subject.book.available).to be false
    end
  end
end

This will reduce the time taken by half! 🎉🎉🎉

3. Use `build_stubbed` when persisted objects aren't required for the test

There are times when the tests we write do not require us to use persisted objects. And that's when we realise we should use build_stubbed instead of build or create.
build_stubbed will stub out methods relevant to persistence. In other words, you won't be able to:

Test the persistence of an object.
Test the callbacks that should execute after updating an object.

These are the methods excluded from the stubbed object returned by build_stubbed. (retrieved via factory_bot's code base)

DISABLED_PERSISTENCE_METHODS = [
  :connection,
  :decrement!,
  :delete,
  :destroy!,
  :destroy,
  :increment!,
  :reload,
  :save!,
  :save,
  :toggle!,
  :touch,
  :update!,
  :update,
  :update_attribute,
  :update_attributes!,
  :update_attributes,
  :update_column,
  :update_columns,
].freeze

Conclusion

These three simple practices allow our test suite to run faster, but the gains varies. If we've not applied the first two practices, then the more complex and larger the codebase is, the more the amount of gains we can extract. But don't expect any massive gains from using build_stubbed! 😝

If you want to take a look at the code, feel free to visit the repository.

Cheers for reading and I hope you find this article helpful! 🤓
Please leave your comments below if you have any questions / thoughts or if you know of other practices we can apply to speed up our Rails test suite. ✌️

A Look into Discard

Ali Ilman — Mon, 02 Sep 2019 12:41:05 +0000

Originally published on ali-ilman.com/blog

Sometimes, we want to soft delete specific records in our app.
What is a soft delete?

A soft delete is a term for flagging a record in the DB as deleted. A use case for this is when you want it to be hidden from the public but visible to the admin for record purposes.

In the world of Rails, there are various ways you can do that. You can write your own soft delete feature or you can use a gem such as discard.

A Look Into Discard

Discard is a gem created by John Hawthorn, describing the gem as soft deletes for ActiveRecord done right. The gem is basically a simple ActiveRecord mixin to add conventions for flagging records as discarded.

Setup

For this example, I'll create an app where there are authors, books and publishers tables.
An Author can have many Books, a Publisher can have many Authors, and a Publisher can have many Books through Authors.

class Author < ApplicationRecord
  belongs_to :publisher, optional: true
  has_many :books, dependent: :nullify
end

class Book < ApplicationRecord
  belongs_to :author
end

class Publisher < ApplicationRecord
  has_many :authors, dependent: :nullify
  has_many :books, through: :authors
end

Add this into your gemfile and then run bundle.

gem 'discard', '~> 1.0'

For the record that you want to be discardable, in our case, Author, include discard in the author model like so.

class Author < ApplicationRecord
  include Discard::Model
end

Then, you generate a migration to add the relevant attributes to the authors table.

rails generate migration add_discarded_at_to_authors discarded_at:datetime:index

How to discard a record

author = Author.first
author.discard # => true
author.discarded_at # => Sun, 01 Sep 2019 10:48:31 UTC +00:00
author.discarded? # => true

How to undiscard a record

author = Author.first
author.undiscard # => true
author.discarded_at # => nil
author.discarded? # => false

Accessing records

Discard adds the following 4 methods for the discardable record.

Author.with_discarded # an alias for Author.all
Author.kept # returns a collection of undiscarded authors
Author.discarded # returns a collection of discarded authors
Author.undiscarded # an alias for Author.kept

Callbacks?!?!?!

Discard adds before_, around_ and after_ callbacks for you to utilise if needed.

class Author < ApplicationRecord
  ...
  before_discard { puts 'Hallo before_discard!' }
  after_discard { puts 'after_discard!' }

  before_undiscard { puts 'Waving at you before_undiscard...' }
  after_undiscard { puts 'Yay after_undiscard!' }
  ...
end
> Author.first.discard
# other logs
Hallo before_discard!
# other logs
after_discard!
=> true

> Author.first.undiscard
# other logs
Waving at you before_undiscard...
# other logs
Yay after_undiscard!
=> true

Unfortunately though, the around_ callbacks don't seem to work. An example would be, Author.first.discard. It'll query for the author and run the code in around_discard but it won't discard the author. It may be a bug within the gem. 🤔

Summary

Discard removes the magic that comes with alternatives such as paranoia and acts_as_paranoid.

I've used paranoia on a few projects, and one of them's a project of a decent size. I remember initially making most models paranoid. We encountered issues, one of them being a has_many dependent: :destroy association. Those dependent records needed to be paranoid as well, otherwise the records will be destroyed for good. 😱 Another issue is that, although I can't exactly call it, one of the records has a has_many_ association and it was searching for a soft-deleted record using an id that still exist within the collection, but the said record with the existing id couldn't be found! 🤯

One might argue that discard goes against convention over configuration, which is one of the principles of Rails, and can add verbosity to the codebase. An example would be, you'd have to keep on adding .kept to a model or an association to access a collection of undiscarded records. But personally, it's easy to setup and use. Plus unlike the other two gems, discard doesn't change the model's default_scope. I suggest you to go with discard to avoid possible long-term pain. 😉

You can check out the code for the app above here where you can select different branches to view the implementation with discard or paranoia.

Why Do You Write Code?

Ali Ilman — Sat, 29 Jun 2019 17:31:55 +0000

Originally published on ali-ilman.com/blog.

I recently read an Instagram post by a fellow programmer. There's a question in the post, which is why do you code / program. Whenever I read such question, the first thing that pops into my mind would be, the satisfaction in seeing the code you wrote brings a product to life.

I remember starting out on Khan Academy back in May 2014. Oh Lord, it feels like that was yesterday. 😱 I can't recall exactly what I learned on Khan Academy, but I believe it was Drawing & Animation in JavaScript. I'm not sure why I started with Drawing & Animation. To be quite honest about it, I hated it! 😂
I didn't finish the course either, and I never liked drawing anyway when I went to school. Plus the course felt rather advanced for a beginner, or it could be me being oblivious to there being more beginner-friendly courses. 🤷‍♂️ After Khan Academy, I learned on Codecademy, freeCodeCamp, SoloLearn. It was mostly JavaScript tutorials. I never really got going after each of the fundamental JavaScript courses on each platform. I was trapped in-between the after tutorial and the creating projects phases. Having known myself more, I find that Udemy courses give me those Oh I see! moments. If only I discovered the platform much earlier!

But two things stuck with me, and they are the excitement in creating something and knowing that you can create almost, if not, anything, with code. One can solve a problem for society, improvise on something for fellow developers and many more!

Fast forward to 2019, I've been working for a year & a half. Including the reasons above, why do I write code?

Excitement in creating something.
Knowing that you can create almost, if not, anything, with code, and contribute to society in such way.
The satisfaction in seeing the code you wrote brings a product to life.
Writing code is a piece of art. Clean, readable code is utter beauty, poetry-esque!
Solving code problems are satisfying.
The flexibility in being able to work from basically anywhere.
The demand for programmers.

How about you? Why do you write code? 🤓

DEV Community: Ali Ilman

8 Tips on Giving Effective Code Reviews

1. Practice conventional comments

2. Suggest changes by masking them as questions

3. Add an example in our suggestion

4. Replace 'you' with 'we'

5. Mind your nitpicks

6. If you're reviewing code, dedicate some time for it, don't rush

7. Use emojis and GIFs!

8. Leave a summary when necessary

Summary

3 Tips on Opening Effective Pull Requests

1. Describe why you made the changes

2. Keep the pull request small

3. Write a changelog

What is a Kubernetes Object

Resources

What is a Kubernetes Cluster

The Control Plane

The Nodes

The String#chars method

Specifying a Template and a Layout through Action Mailer's mail function

Specifying a template

template_path

template_name

Examples

Specifying a Layout

Example

Specifying both the layout and template at once

Example

8 Things I Have Learned After 2 Years of Work

1. The internet is your best friend

2. You will learn on-the-job

3. Get involved with the community

4. Don't get too excited to implement a feature or a bug fix

5. Don't be aggressive in code reviews

6. Ensure that your pull requests are descriptive

7. Self-care is important

8. Build up fellow engineers

4 Mistakes I Made When I First Learned How To Code

1. Let completing a course influence how I feel

2. Not writing down notes in my own words

3. Not going in-depth with concepts I found difficult to understand

4. Built barely anything with what I've learned

Profiling and Speeding Up Our Rails Test Suite with TestProf

How did I end up using TestProf?

What are the common causes of a lengthy test suite?

1. Creation of records for each test

2. Nested factory invocations

How can TestProf help us improve our test suite?

1. FactoryDoctor

2. FactoryProf

1. FactoryDefault

2. before_all

Before

After

3. let_it_be

Before

After

Before

After

Conclusion

3 Practices to Apply to Speed Up Our Rails Test Suite

1. Replace let! variables with let variables

2. Write multiple expectations in one single example

3. Use build_stubbed when persisted objects aren't required for the test

Conclusion

A Look into Discard

A Look Into Discard

Setup

How to discard a record

How to undiscard a record

Accessing records

Callbacks?!?!?!

Summary

Why Do You Write Code?

`template_path`

`template_name`

1. Replace `let!` variables with `let` variables

3. Use `build_stubbed` when persisted objects aren't required for the test