DEV Community: Matheus Richard

TIL: JavaScript's void Operator

Matheus Richard — Fri, 21 Jan 2022 14:30:38 +0000

Today I discovered the voidoperator in JavaScript. It evaluates an expression but always returns undefined.

console.log(void "hello world") // prints `undefined`

It can be used on a IIFE, which usually uses parenthesis to make the function definition be interpreted as an expression and not a declaration:

void function() {
  console.log("hello world")
}();
// prints "hello world"

(function() {
  console.log("hello world")
})();
// prints "hello world"

function() {
  console.log("hello world")
}();
// SyntaxError

This operator is also useful to ensure that an arrow function always return undefined:

// changes to the return value of `doSomething` won't affect this code
button.onclick = () => void doSomething();

Caveat

It’s important to note that this operator has a high precedence with right-to-left associativity, so you may want to use parenthesis to correctly construct some expressions:

void "hello" + " world" // parsed as: (void "hello") + " world"
// => 'undefined world'

void ("hello" + " world") // parsed as: void ("hello" + " world")
// => undefined

How To Get Pull Requests Merged Faster

Matheus Richard — Thu, 25 Nov 2021 00:00:00 +0000

No one likes huge Pull Requests. Reviewers have a hard time reading them, bugs sneak in, they took ages to get merged, conflicts pop everywhere… It’s a nightmare. There’s a better way to handle this.

Listen carefully. It’s a secret: 🤫 make them small.

“How do I do that?” - You may ask. To answer that, we have to learn about developer hats.

🎩 Wearing one hat at a time

Martin Fowler, in the Refactoring book, says that there are two types of software changes: behavioral and structural. Behavioral changes are when you add or remove features from the existing codebase, while structural changes are changes to the code structure without changing any of its functionality. Those kinds of changes are fundamentally different, and we should avoid mixing them. Structural modifications are easily reversible, whereas behavioral often aren’t, for example.

And that is the secret sauce for smaller PRs : splitting those two kinds of changes whenever possible. In other words, separate refactoring from adding new features. It may seem small at first, but once we know the difference between those changes, we can start thinking a few steps ahead and plan how to work more efficiently.

Preparing the field

Have you ever thought “This change would be so simple if the code looked like X”?
I have, and it’s often easier to add a new feature by refactoring the surroundings first.
This technique is known as preparatory refactoring
Remember this classic quote:
“For each desired change, make the change easy (warning: this may be hard), then make the easy change” — Kent Beck
Before you start coding a new task, ask yourself: “Would this be easier with some preparatory refactoring?”. The answer can make your work far easier.

Another side effect you’ll see it’s that the code reviews themselves will improve. This happens because smaller code samples are easier to understand, so reviewers can focus deeper on what you did.

➗ Dividing work

Sometimes our workflow may lead to lots of files changed, and that’s okay. The thing is that we don’t need to add all of them to the same PR. Once we got the work done, we can split commits into several deliverable PRs. Being comfortable with Git will make this task far more manageable.

💅 Nice presentation

Stepping out from the code side a bit, if you want to make a good PR, make sure to make it appealing. Some file changes with no context at all won’t make a reviewer happy. Here are some things you can do to put a smile on their faces:

Good description : What is this PR doing? Is it a bugfix, a new feature, or refactoring? Does it include any breaking change?
Context : Please don’t just link a GitHub issue or a Jira ticket on your PRs. Try to answer some of these questions: Why are you doing this? Why did you choose a particular approach? If possible, provide information (links, docs) to back it up. Benchmarks and screenshots are welcome as well.

A good PR description makes the reviewer do less back-and-forth by proactively answering a lot of their questions in the first place.

🧪 Tests!

Don’t forget to add tests to your code changes as well — unless it’s a refactoring, where the behavior stays the same. If you’re doing a bugfix, you already have the test scenarios; if you’re doing TDD, well, you already have the tests 😅. No matter how you prefer to work, tests add more confidence that the code works and prevents regressions in the future.

Easy View Components In Jekyll

Matheus Richard — Thu, 28 Oct 2021 00:00:00 +0000

Jekyll is a famous static site generator. It has over 43k stars on GitHub, but in our current JAMstack world, it’s not the shiniest star anymore.

With web development becoming more complex — some would say _too_complicated—, Jekyll may feel bare bones when compared with competitor tools. One of the key aspects it lacks is components, which becomes a must with the introduction of utility-first CSS libraries like Tailwind.

I was losing hope, but then I discovered the include tag.

Creating components

Include tags are kinda similar to partials in Rails: they allow us to include content from another file (stored in the _includes directory).

  <!-- This includes the contents of _includes/footer.html into this file -->
  {% include footer.html %}

The cool thing is that you can pass parameters to include tags! This is where things start to get interesting. We can create components similar to what we would do with React, for example. But instead of using JS, we use Liquid.

<aside class="max-w-md p-5 rounded bg-gray-50 border-l-4 border-l-blue-500">
  <strong class="block mb-4">{{include.title}}</strong>
  <p>{{include.content}}</p>
</aside>

Poorman's JSX

And we use it in the template like this:

{% include aside.html title="Include tags are cool" content="Keep reading for caviats, tho" %}

It’s even possible to have parameters with default values using Liquid’s default filter:

<aside class="max-w-md p-5 rounded bg-gray-50 border-l-4 border-l-blue-500">
  <strong class="block mb-4">{{include.title | default: 'Note' }}</strong> <!-- default value here -->
  <p>{{include.content}}</p>
</aside>

Don’t be greedy!

Include tags are powerful, but they add an overhead on the build time for your site, so don’t use them for every single thing. The docs recommend not using them for every image on your blog, for example.

A different approach would be using custom Liquid tags to create components, but note that they are not supported by GitHub Pages — so automatic build/deploy won’t work.

TIP: If you wanna something more… modern (?) for doing JAMstack with Ruby, check out Bridgetown.

How Spaces Can Improve Your Code

Matheus Richard — Tue, 31 Aug 2021 15:53:10 +0000

Writing code is similar to writing an essay: it consists of many small parts that interact. One big giant blob of words is hard — and tedious — to read. To address this, we use paragraphs. The same technique can benefit our code. Here’s how.

Logical blocks

A paragraph is a self-contained unit of discourse in writing dealing with a particular point or idea.— Wikipedia

The critical thing in this definition is “dealing with a particular point or idea”. Structuring our code with paragraphs (i.e., logical blocks) means we group related things and visually separate them from the others. A simple new line makes a huge difference in readability. Let’s look at some examples to clarify this idea.

Separate test phases

Consider this function: it takes two numbers and returns their sum. Pretty simple.

fn sum(a: i64, b: i64) -> i64 {
  a + b
}

A possible unit test for this function could look like this:

#[test]
fn it_sums_two_numbers() {
  let a = 1;
  let b = 2;
  let result = sum(a, b);
  assert_eq!(3, result);
}

While this test follows the four-phase pattern, separating each test phase makes them more clear:

#[test]
fn it_sums_two_numbers() {
  let a = 1;
  let b = 2;

  let result = sum(a, b);

  assert_eq!(3, result);
}

Grouping related concerns

Programmers often use structures like modules and classes to tie code together. It is a great technique, but can lead to clutter if we’re not careful.

Check out this Rails model. Even though it’s only a few lines long, it’s a bit hard to parse this class.

class User < ApplicationRecord
  include Clearance::User
  has_many :books
  belongs_to :organization
  validates :name, presence: true
  validates :email, presence: true, uniqueness: true
end

See how different it looks when we separate its logical blocks:

class User < ApplicationRecord
  include Clearance::User

  has_many :books
  belongs_to :organization

  validates :name, presence: true
  validates :email, presence: true, uniqueness: true
end

Here, we grouped each section by its “theme” (mixins, associations, validations, query methods, etc.). The spacing helps us see the logical separation between each section, which speeds us up when searching where to add and change code.

Separate calculations from the return value

Another great opportunity to use code blocks is in function bodies. We often do some preparation work before return the result, so it’s good to split those two parts up. This technique is especially beneficial when the language allows omitting the return keyword.

OBS: I’m omitting some details in this Rust implementation to keep it simpler.

enum FileFormat {
  HTML,
  Latex,
  Markdown,
  // ...
}

fn render_markdown_to(markdown_content: &str, format_to_convert_to: FileFormat) -> String {
  let renderer = match format_to_convert_to {
    FileFormat::HTML => HTMLRenderer::new(),
    FileFormat::Latex => LatexRenderer::new(),
    other => panic!("Cannot convert markdown to {}", other),
  };
  renderer.render(markdown_content)
}

For those unfamiliar with Rust, omitting the semicolon in the last line indicates the function’s return value. It’s a subtle detail that is easy to miss. Adding a new line here makes it more evident where the calculations end and what is the actual return value.

fn render_markdown_to(markdown_content: &str, format_to_convert_to: FileFormat) -> String {
  let renderer: Renderer = match format_to_convert_to {
    FileFormat::HTML => HTMLRenderer::new(),
    FileFormat::Latex => LatexRenderer::new(),
    other => panic!("Cannot convert markdown to {}", other),
  };

  renderer.render(markdown_content)
}

Extracting behavior

Using logical blocks also helps us to refactor. It’s particularly useful to extract functionality: grouped lines probably will move together. Looking at the last example, we could extract the match expression to its own function:

fn render_markdown_to(markdown_content: &str, format_to_convert_to: FileFormat) -> String {
  let renderer = renderer_for_format(format_to_convert_to);

  renderer.render(markdown_content)
}

fn renderer_for_format(format: FileFormat) -> Box<Renderer> {
  match format {
    FileFormat::HTML => Box::new(HTMLRenderer::new()),
    FileFormat::Latex => Box::new(LatexRenderer::new()),
    other => panic!("Cannot convert markdown to {}", other),
  }
}

Simple but effective

Separating logical blocks is a technique that is really simple but highly effective in making code more maintainable. Remember, we read code more than we write, so optimize your code for reading. A little effort today can save your team hours in the future.

Kitchen Sink

Matheus Richard — Thu, 22 Jul 2021 20:13:13 +0000

Imagine you drink a glass of water and go to the kitchen sink to wash it. When you get there, there’s a HUGE pile of dirty dishes in the sink. To wash your glass, you would have to clean all the mess before. You look around… no one’s watching. You carefully put the glass in the sink’s corner and sneak out. You walk away thinking “How things got this way?”. The ironic answer comes to your mind: one glass a day.

In the same way, software accumulates technical debt over time. Most of the time, tech debt starts from simple actions:“let’s add another method to that class”, “let’s add another parameter to that function”, “let’s duplicate that code for the 10th time… What? Don’t look at me, it’s how everyone does this!”.

Giant classes/functions/modules are like magnets: they attract all responsibilities to themselves and tend to get even bigger! There is so much code stuffed inside that everything seems to fit in there. That creates a sort of black hole that won’t stop growing.

I’m not saying you should abstract early. I’m all aboard with ma’am Sandi Metz on “duplication is far cheaper than the wrong abstraction”, but an abstraction will have to exist at some point.

🚪 A way out

If you thought “I can’t touch this without breaking all the things”, you’re not the only one. Every developer will eventually deal with software that has technical debt and sometimes it may even seem that there’s no salvation. Luckily, smart folks like Martin Fowler taught us patterns for dealing with this very situation! The Strangler Fig Pattern, for example, allows us to refactor big classes (or even applications) incrementally, without breaking backward compatibility!

The point is, in the same way that there are design patterns for creating new code and addressing issues, there is a list of code smells and refactoring techniques to deal with them as well. Refactoring should be part of our daily work, not something ~special~. We should study, learn and teach others about it. The more we do it, the easier (and natural) it gets!

“A refactor a day keeps the rewrite away!” - Developer Granny

🎸 Gravity is working against me

Bad code attracts (more) bad code. Developers, especially when they’re new in a codebase, tend to repeat patterns. That way, expect a bad piece of code to influence similar instances. To prevent this we must resist inertia. Yeah, it’s easy just to follow what everyone’s been doing, but this approach won’t work forever.

How to do this? Following the boy-scout rule “always leave the code behind in a better state than you found it” helps to create a good mindset for it. We’ll think twice before just adding a new line of that huge method or nesting another if/else statement. This rule helps us not to be afraid of taking small actions to improve the code. Did we touch a function? How can we improve it? Does it have tests? Can we use code to get rid of some comments?

When we finally understand that piece of spaghetti code (everyone has at least one in mind), we won’t keep it to ourselves! We have to materialize this knowledge in the code itself by renaming variables, functions, extracting small methods to clarify intention, etc. It costs us a bit today but will save a ton of time for other developers (or ourselves in 6 months).

Those simple actions can be powerful in the long run! One glass a day, that dirty pile gets smaller. You may even have some partners joining this quest! Soon enough, that sink will be shining, and when it is clean, no one will want to be the first to leave a dirty dish there.

My First Month (or so) With Rust

Matheus Richard — Fri, 04 Jun 2021 11:00:00 +0000

I’m learning Rust and this is the first post about my experience with it. I’m a Ruby programmer, so you may wanna check out my post about the decision of learning Rust for more background.

I delayed this post a lot because I didn’t do a lot of Rust in my first month. I had several things going on in my life, so I couldn’t focus on Rust as much as I would like. Anyway, I know that I have to put on paper some of my impressions before I forget them, so here I am.

🔧 Setting up

Setting up Rust was very easy: rustup makes everything pretty straightforward, so I had no problems here. Cargo is also very good, and I had no problems installing libraries (crates) too! Well done, Rust!

📚 Reading

As I didn’t have much time to actually code Rust, I spent a lot of time reading about it. Regarding this, Rust is the language with best learning tools I’ve seen to this day! Not only it has a book (The Book, I must say 😅) that guides you in the first steps to know the language and its unique features, but Rust also has a Learn by Example book!

I think that this is a very nice pairing and both books are awesome in their way:

Wanna start from scratch and learn about a concept? Check out The Book.
Just want to know the syntax for creating an anonymous function? Here’s a book full of examples.

Chapter 04 (the one about Ownership) of The Book was especially great for me. My mind was blown after reading it. Not because it was hard to read, but because everything made SO MUCH sense! All the pain points in C++ seemed to be solved with this ✨magical✨ compiler. Well, that was in theory, let’s see how I did in practice, tho.

✍️ Writing

I know that I should pick a simple topic to get me started when learning a new language, but I can’t control my desire to create things. I don’t like to create build-and-throw-away things, either. They should be useful things (at least to me)! So, to learn Rust I started building an interpreter following Lisperator.net’s tutorial.

To be honest, my first 100 lines of Rust were the basic algorithms in Chapters 01 and 02 of The Book, just to test out my setup and get to know a bit of the syntax. Four-space tabs and semicolons everywhere were kinda weird for me, but at least Rust doesn’t require explicit returns (and can avoid semicolons in the last expression too). rustfmt was a neat addition, since I don’t have to care about how my code should be indented. 👍 for Rust here too!

I was looking for things that were different in Rust and Ruby. Here are some examples of what I found:

🔢 Underscores and numbers

Rust, like Ruby, allows underscores to separate numbers. The difference is that Rust allows multiple underscores (you can even have trailing ones):

// Both examples work like a charm in Rust
let a = 1_;
let b = 1_____2;

// SyntaxError in Ruby: trailing `_' in number
a = 1_

// SyntaxError too
b = 1_____2

❓ Rust has no ternary operator

We can use if/else expressions — which I’m very familiar with, coming from Ruby —, so I didn’t care not having it in Rust.

Although this feature may be very valuable for some users...

📏 Ranges are not inclusive

To me this was weird because it’s not the same I’m used to in Ruby.

Ranges in Rust:

println!("{}", (1..10).count()) // => 9

Ranges in Ruby:

puts (1..10).count # => 10

I guess I’ll do some off-by-one errors until getting used to this. I found out later that there’s an inclusive version of ranges too:

println!("{}", (1..=10).count()) // => 10

All in all, it was not that different from Ruby. Yeah, Rust is a “curly braces language”, but with things like enums and impl, I could translate my OOP code fairly well. The Gentle Introduction To Rust chapter on OOP was particularly helpful for that.

The main difference from Ruby for me was that in Rust I feel like I have to think about memory usage in each line of code I write.

❌ Learning by error

Generally, Rust gave me really good compiler error messages. The fact I can run rustc --explain SOME_ERROR and see details for this error makes learning Rust (without leaving the terminal) much easier.

The stdlib documentation seems thorough and very modern: it has links for return types, traits, enums, tips, and examples.

🤝 The compiler is my friend

After a long time writing in an interpreted dynamic typed language like Ruby, Rust’s compiler was a breath of fresh air. It’s so good to know that I got a type checker having my back when I screw things up. I feel like I have to write fewer tests but still have the feeling that everything is working.

Another difference is the lack of null values 🙌. This is one of my favorite choices in Rust comparing to C++. Option types are much better IMO and having pattern matching makes dealing with them quite easy. About that, some constructors were really well thought out, like: enums, if let,while let. They are cohesive and fit the language like a glove.

🦀 Rusty Code

It’s funny to learn a new language because I can’t tell what is idiomatic or not yet. For example, while coding my interpreter, I created the following function:

fn is_punctuation(c: &char) -> bool {
    ",;(){}[]".contains(c.clone())
}

I used clone to satisfy the compiler, but I had the feeling that it was unnecessary. Later I ended up refactoring it to this version (which I think is better):

fn is_punctuation(c: &char) -> bool {
    ",;(){}[]".contains(*c)
}

I don’t know if having the string inside the function is a good idea or if I should extract it into a constant or something. And that kind of question happened a lot:

🤔 A lot of questions

As a beginner, I don’t know what are the best practices and idioms in Rust, so I had a lot of questions to ask. I had some classic beginner stuff like how to work with modules and the String vs str vs &str dilemma (which this blog post and my rustacean friend@PotHix helped me to understand), and I’m expecting to have even more questions about memory management and that kind of stuff.

I also don’t know when to move and when to borrow values, so I’m defaulting to borrow all the things and cloning defensively.

I just found out 📎 Clippy, which I think is kinda like👮‍♂️ Rubocop for Rust, so I hope it will help me to write better Rust code.

🔮 Future

I plan to keep writing my interpreter in Rust to learn more about this language. One thing I didn’t explore yet is testing. Since I’m a big fan of TDD I hope Rust has a good test support. I have an interest in digging a bit in game development with the Bevy game engine.

I’ll also make a post comparing Rust with Crystal showing my experience with both languages.

Oh, and if you’re a rustacean, feel free to give me any advice or tip you think is useful! Bye 🦀!

Different Ways to Contribute to Open Source

Matheus Richard — Mon, 31 May 2021 23:00:00 +0000

OSS is a wonderful thing! I was so grateful for the OSS tools I used in my projects, that I started contributing to OSS as retribution! If you want to get started with OSS contributions, here are several ways to do it.

In each section I’m going to present a topic, explain it, and link some Pull Request that I did in that “category” so you can take a look to get inspired/learn something.

🐛 Bugfixes

If you fix a bug, maintainers will love you. It can be a bug you found, or a issue tagged with a bug label. It is a good opportunity to fix that 1px misaligned item that is bothering you since forever.

Or maybe you tried something and it didn’t work quite well on your machine. If you figure out what went wrong, don’t keep it to yourself! Open a PR!

Some bug fixes I did:

✨ New features

Do you wish that a library did X for you? Don’t expect maintainers will do it for you. Code it and submit a PR! Maybe you already have something in your codebase that could be pushed upstream. That is what happened with the following contributions:

That is one of the nicest things about open source: you can contribute back to projects that helped you! You may open an issue first, asking maintainers if they like your feature idea.

⚡ Improve performance / Refactor code

If you’re experienced in a language you probably know some patterns or methods that are more performant than others, i.e, they run faster and/or with less memory. For instance, in Ruby using each + push is slower than using map. This is an opportunity to find those patterns and replace them with the more performant alternatives. When you do this kind of contribution, don’t forget to add benchmarks to your PR to make it more compeling.

You can do some refactoring too: deleting unused code, fixing deprecation notes/methods, untangling some nested if/else with guard clauses, etc. Making the code easier to read is important to add new features and finding bugs in the future.

Here’s some PRs I did for Ruby on Rails in this category:

🧪 Add tests

Tests make us feel more confident about the code we write and the changes we make. Well tested OSS benefits everyone using it! So, you can help yourself and the whole community by adding tests to a project! Adding a test coverage tool is another way to contribute in this topic. Setting up a coverage tool helps to understand which areas of the core aren’t tested.

This was exactly what I did for gem-web. I added simplecov and with the coverage tool properly configured, I added tests for the missing parts:

🐋 DevOps

Adding a Docker/Docker Compose setup is a nice way to help newcomers onboard a project, especially when the project is an app with several moving parts (core, database, cache services etc). Setting up all that may be hard, but running docker-compose up is far easier.

There’s other things you can contribute: almost every project nowadays has a Continuous Integration (CI) pipeline (Gitlab CI, GitHub Actions, Travis CI, Circle CI, Jenkins etc). Setting up a pipeline is an contribution in itself, but you can go further and set up linters, security checks and even a staging build in some cases!

Here’s an example of a PR where I introduced a Dockerfile as an alternative setup build script:

zynaddsubfx - Add Dockerfile

👩‍💻 OSS is more than code!

As developers we love to code, but OSS is far beyond just coding! Maintainers have to deal with a variety of different problems: documentation, helping beginners, handling poor written issues, spams, reviewing Pull Requests, etc. We can do OSS by helping them with these tasks!

👍 Reviewing PRs

You don’t need to be a maintainer to do that! I took much time to understand this. Reviewing PRs also helps the contributor to not feel bad about their work not being reviewed for many days, and you help address issues faster (typos, changing naming, refactorings, adding docs, etc). Just be kind and helpful. Here’s more tips on good code reviews.

🕵️‍♂️ Reproducing issues

If you’ve been part of a reasonably used OSS project, then you know how hard is to handle issues. Many of them don’t even have enough information to reproduce and diagnose its causes. You can help maintainers by trying to reproduce issues! You may have to ask users for more information (OS, language, library versions, for example), or steps to reproduce it. Sometimes the behavior is not a problem, but a deliberate choice.

📝 Improving documentation

This is one of my preferred ways to contributo to OSS. Here we have a lot of options: fixing typos, rewriting confusing sections, adding docs where it’s missing. The best is that you can improve documentation as you read it! If you’re learning a new tool, this may be the simplest way to start contributing!

The contributions bellow were made just as I started studying the tools:

🎨 Use your imagination!

As I said earlier, OSS is not only about code! Any skill you have may be useful to someone! If you’re a musician or artist, for example, there’s plenty of things you can contribute to. Here’s an example of a PR where I created a logo for a project of a friend of mine:

Commit Helper - Add logo

🎯 General advices

Read contributing guide and code of conduct This should be your first step before actually doing some contribution. Reading those guidelines will help you understand what contribution are accepted, how to make them, and what is necessary for approving them. Those are generally the files CONTRIBUTING.md and CODE_OF_CONDUCT.md;
Be patient and kind: Maintainers have lives too! Most of them make no money from OSS, so please be patient if your PR takes a while until being reviewed/approved;
It’s not about you: Do not take things personally! If someone adds a comment about your code, it’s just about your code, don’t be sad about it, but use it as an opportunity to learn something;
Not everything you do will/needs to be approved: Sometimes our contributions don’t match the projects needs/vision and end up not accepted, and that’s okay. This is part of open source and we have to understand it. The code you wrote can always live as a plugin/extension too. Here’s three unapproved PRs I did:

💪 Yes, you can

First of all, contributing to open source is not a experienced-developer-only thing. Many of the contributions I did were because I was a beginner on the language/tool. Use this as your advantage : beginners have sharp eyes for missing or confusing docs, for example. Your trajectory can help future beginners have a smoother onboarding!

Look for issues with the tags first-timers-only-issue, easy, beginner and good first issue. And here’s a list of beginner-friendly projects.

Now grab your cup of coffee, streach your hands and go do something awesome 😉!

Mocking Made Simple

Matheus Richard — Thu, 22 Apr 2021 12:23:40 +0000

TD;DR: Inject dependencies instead of mocking functions.

I was refactoring some React Native code the other day and ended up extracting the following function:

// src/screen.js

const logScreenOpened = async screenName => {
  try {
    await FirebaseLogger.logScreenView({screen: screenName});
  } catch (e) {
    console.error(`Could not log screen view. Error: ${e}`);
  }
};

When I got to testing, I wanted to change the logger behavior in each test case, but I was struggling with Jest mocks. I wanted to do something like this:

// tests/screen-test.js

describe('logScreenOpened', () => {
  it('logs a screen view', () => {
    // TODO: mock logger's `logScreenView`

    logScreenOpened('HomeScreen');

    // TODO: expect logger to have received `logScreenView` with `{ screen: 'HomeScreen' }`
  });

  it('logs to console if logger raises an error', () => {
    // TODO: mock logger's `logScreenView` to raise a error

    logScreenOpened(null);

    // TODO: expect console to have received .error
  });
});

const logScreenOpened = async screenName => {
  await FirebaseLogger.logScreenView({screen: screenName});
};

It was taking more time than I wanted to, so I gave up and came up with other solution. Not a fancy solution, neither changing the mocking library. It was, in fact, a very old one (and very known among Java devs): Dependency Injection (DI for short).

Injecting dependencies

So, instead of accessing FirebaseLogger directly, we’ll provide it as an argument of our function:

// src/screen.js

const logScreenOpened = async (screenName, logger = FirebaseLogger) => {
  await logger.logScreenView({screen: screenName});
};

This function is almost the same of the previous implementation, but receiving logger as an argument gives us some flexibility.

Here’s the thing: the logScreenOpened function don’t need to know what logger is. As long as it is an object that responds to logScreenView, we’re good. That’s the only thing we care about. This is known as duck-typing (or interfaces).

Back to testing: now we can change the logger implementation as we wish:

describe('logScreenOpened', () => {
  it('logs a screen view', () => {
    const logScreenViewMock = jest.fn();
    const fakeLogger = {logScreenView: logScreenViewMock};

    logScreenOpened('HomeScreen', fakeLogger);

    expect(logScreenViewMock).toHaveBeenCalledWith({screen: 'HomeScreen'});
  });

  it('logs to console if logger raises an error', () => {
    const logScreenViewMock = () => {
      throw 'Some error!';
    };
    console.error = jest.fn();

    logScreenOpened(null, fakeLogger);

    expect(console.error).toHaveBeenCalledWith(`Could not log screen view. Error: Some error!`);
  });
});

OBS: We could’ve injected the console.error bit too, but for this post I decided to keep things simple.

Going ✨ fancy ✨

We don’t have to always inject the dependency directly in our methods. We could go fancy and have a logging module that gives us different loggers depending on which environment we’re working on. Something like this:

// config/log.js
import {FirebaseLogger} from 'firebase-logger';
const TestLogger = {
  // simplified code to run in tests
};

export const logger = process.env.NODE_ENV === 'test' ? TestLogger : FirebaseLogger;

And in the app code we just import it:

// src/screen.js

import {logger} from 'config/log';

const logScreenOpened = async screenName => {
  await logger.logScreenView({screen: screenName});
};

Speeding up

Refactors like this are nice when you want to to improve test performance too. Our fake logger is very lightweight, so those test are blazing fast! Use this to your advantage!

Let’s say we have an function that does some heavy computation:

function doStuff() {
  Lib.veryHeavyComputation('some', 'params');

  doMoreStuff();
}

We don’t want our tests to be slow, so let’s do the same thing here: inject dependencies.

function doStuff(lib = Lib) {
  lib.veryHeavyComputation('some', 'params');

  doMoreStuff();
}

So, in our tests we swap the implementation:

describe('doStuff', () => {
  const fastLib = {veryHeavyComputation: jest.fn()};

  doStuff(fastLib);

  expect(fastLib).toHaveBeenCalledWith('some', 'params');

  // other expectations
});

Now we have fast tests but guaranteeing the same API!

Wrap up

Don’t be afraid of this kind of code! As I said, there’s nothing new here. Is an old techniche used everywhere. In fact, Elixir’s guides encourages this very approach! They call it “mock-as-a-noun” (in opposition of “mock-as-a-verb”).

One think to keep in mind: we must keep the API of our fake logger in sync with the original one. This is important because we don’t want our tests passing but our production code failing. So is it good to have a integration test covering the usage of that mock too!

That’s it, happy mocking! (wait, that’s a verb!)

On learning Rust

Matheus Richard — Sat, 27 Mar 2021 20:46:58 +0000

As of March 26th of 2021, I decided to learn Rust. I’ve heard of it a couple of years ago but never had time (i.e. priority) to dig into it. Now it’s time to really understand what is it all about.

Where I am starting

I already know — or think I know — some things about Rust. It is a systems language, but with a modern feel. That means:

It’s fast: it wants to replace C/C++ for a reason;
It’s safe: no nulls here;
It has a nice package manager: no more vendoring dependencies;
It has something about memory management: it seems almost like type-checking, but for memory.

Those things really speak to me because I’ve spent the past 5 years or so doing Ruby. Don’t get me wrong, I love Ruby. It’s my main language, I work with it every day (and in my side projects). It really fits my way of thinking and it’s my go-to tool. But, because I know it so well, I know its flaws too.

With that in mind, I wanted to have a “complementary” tool at my disposal. Instead of a dynamic-typed, scripting language, this time I need a statically-typed, fast, compiled language.

I did some C/C++ in the past, but I feel like they’re stuck in the past. I know Crystal and even started to build an interpreter with it. It was pretty easy to get started with it, due to its huge similarity to Ruby. Unfortunately, the language is still in its infancy (but I have hope in its future). Thus, Rust became my choice.

I worked a bit with functional languages like Haskell and Elm, so concepts like monads are no scary to me. I hope that this will make things easier for me in Rustland.

What I am aiming for

I have no intentions to work professionally with Rust (who knows, tho? 🤷), but I think it’s nice to have different (and complementary) tools. Now I don’t have performance-demanding requirements, but when I have — and that day will eventually come — I want to be prepared. I may even use Rust in my current job.

My main goal is to have a fast and safe systems language to build games and interpreters. Those are the only performance-heavy tasks that are fun to me (sorry machine learning). It’s important to stress this word: fun. Learning a new language is a kind of investment, and I wanted it to be fun, so I don’t feel like I’m wasting my time.

How I’ll do it

Since I have no professional goals with Rust, my study will be guided by my curiosity. That’s the way I like to study things. I’ll read the docs, tutorials, make small programs and games just for fun.

I won’t establish goals, or study ours. I have a full-time job, an undergraduate thesis to finish, and a family. This should be as fun as playing God of War on my PS4.

I’ll document the process if I find something interesting to share (like differences between Rust and Ruby in my experience), or how one language influenced how I code on the other.

Evaluating my results

One year from now I’ll write another blog post about my journey. Maybe I’ll end up liking Rust very much, maybe not. Or maybe I’ll be lazy and not studying so much, after all. Anyway, if you’re reading this blog post after 2021, my impressions of one year doing Rust will be linked »here«.

Cya, rustaceans.

Don't use comments! Use code.

Matheus Richard — Fri, 26 Mar 2021 20:56:17 +0000

Let’s get this straight: comments are a code smell.

Whenever I feel like adding comments to my code I stop and ask myself: “Is there any way to NOT use comments here and use code instead?”. Often the answer is “yes”.

Comments are a lazy solution for developers. They spare us from thinking about abstractions and naming (which is one of the hardest things in Computer Science indeed), and that’s why they’re so tempting.

However, we can easily avoid (most) comments! As the saying goes “Talk is cheap, show me the code”. So, here we go:

Describing the obvious

Let’s get this one out of the way: these “describing” comments are just useless. They’re just duplications and add no value. On the contrary, they encourage other developers to do the same! Just get rid of them. Good variable and function naming is the way to go here.

### DON'T ###

module Dungeon
  # Generates an array of rooms
 def generate_arr
    # Initializes an empty array of rooms
    arr = []

    # Creates five rooms with the given width and height and add them the `arr` variable
    5.times { arr << create_room(10, 12) }

    # ...
 end
end

### DO ###

module Dungeon
 def generate_rooms
    rooms = []

    5.times { rooms << create_room(width: 10, height: 12) }

    # ...
 end
end

Just do it

Probably the most common use of comments: explaining what the code does. If we have the principle “Tell, don’t ask” in OOP, for commenting it should be “Do, don’t tell”. Extracting behavior into modules/functions makes searching, modifying, and testing far easier than when using comments.

### DON'T ###

def something_important
  system("stty -echo") # disables echo on terminal
  read_password
  system("stty echo") # enables echo on terminal
end

### DO ###

module Terminal
  def self.enable_echo
    system("stty echo")
  end

  def self.disable_echo
    system("stty -echo")
  end
end

def something_important
  Terminal.disable_echo
  read_password
  Terminal.enable_echo
end

No magic numbers!

I’ll admit this: comments are a bit better than nothing in this case. But we can do better! Fixing those is pretty simple: add a constant. You can use a simple type like an integer, or get fancy with hash-tables, structs and objects if needed.

### DON'T ###

def notify
  send_msg "Hello world!", channel: 0 # General
end

### DO ###

GENERAL_CHANNEL_ID = 0

def notify
  send_slack_msg 'Hello world!', channel: GENERAL_CHANNEL_ID
end

### DO² ###

CHANNEL_IDS = OpenStruct.new(general: 0).freeze

def notify
  send_slack_msg 'Hello world!', channel: CHANNEL_IDS.general
end

Comments for measurement units

Some people think this kind of comment is OK. I think, as in most of the cases, that a simple function replaces them. This is the kind of thing that spreads quickly throughout your code, but it’s easy to avoid:

### DON'T ###

module RecurringJob
  def perform
    do_important_stuff

    seconds = 60 * 60 * 6 # 6 hours
    RecurringJob.run_in(seconds)
  end
end

### DO ###

module Seconds
  def self.from_hours(hours)
    hours * 3600
  end
end

module RecurringJob
  def perform
    do_important_stuff

    seconds = Seconds.from_hours(6)
    RecurringJob.run_in(seconds)
  end
end

Using a module like that opens the possibility for other conversions, like from_minutes, from_days, etc.

Don’t use comments to separate things

If you’re using comments to divide a file into sections, this may indicate that this file does too much. It’s better to split it into several modules:

### DON'T ###

module Utils
  ### File System ###

  def create_file(path, content = "")
    # ...
  end

  def file_exists?(path)
    # ...
  end

  ### Text format ###

  def bold(str)
    # ...
  end

  def italic(str)
    # ...
  end
end

### DO ###

module Utils::FS
  def create_file(path, content = "")
    # ...
  end

  def file_exists?(path)
    # ...
  end
end

module Utils::Format
  def bold(str)
    # ...
  end

  def italic(str)
    # ...
  end
end

Don’t add TODO’s

These kinds of TODO’s rarely get done. If you’re the one adding the comment, you’re the one that cares about it. Do it now!

### DON'T ###

# TODO: handle exceptions
def tweet(msg)
  TwitterClient.tweet(msg)
end

### DO ###

def tweet(msg)
  TwitterClient.tweet(msg)
rescue TwitterClient => e
  log_error(e)
end

Don’t have time to deal with it? Open an issue instead. Issues are prioritized and end up in your development pipeline (or maybe in some OSS contributor’s). Those TODO comments will be forgotten as soon as your code goes to production.

Don’t add deprecation notes

Deprecating code with comments is not efficient. Especially in libraries, developers won’t read source code before using it. Be proactive and do something actionable (like a warning) right away.

### DON'T ###

# DEPRECATED: use `puts` instead
def printf(str)
  # ...
end

### DO ###

def deprecate(target, alternative:)
  Log.warning("[DEPRECATION] `#{target}` is deprecated. Use #{alternative} instead.")
end

def printf(str)
  deprecate(:printf, alternative: :puts)

  # ...
end

Are you using comments to generate deprecation documentation? Read this section.

Don’t add after-update notes

This is the same principle as the one before: codify your comments.

### DON'T ###

class Post < BaseModel
  def self.without_author
    # TODO: Use Post.where.missing(:author) after Rails 6.1
    Post.left_joins(:author).where(authors: { id: nil })
  end
end

### DO ###

class Post < BaseModel
  def self.without_author
    raise 'Use `Post.where.missing(:author)` instead' if Rails.version >= '6.1'

    Post.left_joins(:author).where(authors: { id: nil })
  end
end

If an exception is too harsh for you, you can just give a warning.

You could go even further:

### DO² ###

class Post < BaseModel
  def self.without_author
    if Rails.version >= '6.1'
      Log.warn 'Delete the else branch of this conditional'
      Post.where.missing(:author)
    else
      Post.left_joins(:author).where(authors: { id: nil })
    end
  end
end

This is especially useful if the new method is more performant than the older one. You’ll get instant performance without changing your code.

Don’t use comments as backup

Developers shouldn’t fear deleting code. Commented code just muddles everything around it. Do you think you may need it later? Short answer: you probably won’t. And even if you do, that’s why we have Version Control Systems like Git (If you’re not using a VCS, what are you doing?!).

### DON'T ###

# NOTE: Maybe I'll need this someday
# def my_algorithm
# old(implementation)
# end

def my_algorithm
  new(implementation)
end

When comments are OK

I’m not here to say that every comment is bad. There are some cases when they’re the last resource. If no code can do what you want, don’t be ashamed to add a comment. Some examples:

1. Comments as documentation

Most languages have tools to generate documentation using code comments. That is nice because it keeps the docs near the code it refers to. Here’s an example of YARD, a Ruby documentation tool:

# Reverses the contents of a String or IO object.
#
# @param contents [String, #read] the contents to reverse
# @return [String] the contents reversed lexically
def reverse(contents)
  contents = contents.read if contents.respond_to? :read
  contents.reverse
end

2. Comments as code (wut?)

Sometimes comments are actually code. That is, they can be used to produce some behavior.

Magic comments

Ruby has magic comments that change the behavior of the interpreter in some ways. Just put them in the beginning of the file, and it will take effect. For example:

This comment makes the interpreter warns about wrong indentation:

# warn_indent: true

You can change the file’s encoding:

# encoding: utf-8

Parsing comments

Some libraries parse comments too. Linters often use comments to disable rules momentarily:

# rubocop:disable Layout/LineLength
def this_could_be_a_very_long_line_that_extends_forever_into_infinity
  # ...
end
# rubocop:enable Layout/LineLength

Another example is the library Bake, which parses documentation comments to get information about type coercions.

# Creates a new post
#
# @param post_name [String] name of the post to be created.
# @param categories [Array(Symbol)] categories of the post.
def new_post(post_name, categories: [])
  pp categories
end

This way it parses input from the terminal and automatically coerces params into the desired type.

$ bake new_post 'test-post' categories=ruby,testing
# output: [:ruby, :testing]

OBS: even though type checking can be implemented with comments, sorbet, rbs, and several others have shown that type checking dynamic-typed languages is possible with code.

3. When you have no other tool

Sometimes there are some things that you cannot explain with code. I’m not talking about how you did, but why you did them.

def fetch_foos
  # NOTE: We're disabling params sorting because the FooAPI requires
  # params to be in the following order: foo, bar, baz
  HTTP.get('/foo-api', params: { foo: true, bar: false, baz: false }, sort_params: false)
end

Do you have any other good cases for comments? Let me know in the comments!

Comments are not code!

Comments tend to get lost and collect dust. When we’re in a big refactor, we’ll rarely think in refactoring comments too. Comments are not tested, so they end up outdated, with typos, wrong information, and worse: bugs.

Using code, on the other hand, has several benefits: syntax highlighting, grepping, compile/runtime checks, testing!

Comments are a confession that we were unable to represent our ideas with code. That happens sometimes, but try your best to avoid them.

TLDL: Don’t use comments. Codify your comments.

Productive Laziness

Matheus Richard — Wed, 24 Feb 2021 13:57:55 +0000

You’re tired. Exhausted. Your mind simply isn’t responding. You stare at the code; it stares back at you. You type something. It doesn’t work. You delete it. The clock says: 04:00 PM.

You know what you need: a break.

Working when we’re tired is really dangerous (to us and our applications). We write buggy code, make silly mistakes, they frustrate us, and, finally, we burn out. Everyone has been there. So, what to do rather than keep hammering your head on the keyboard?

In fact, you got a lot of options:

Lie down (or get up if you’ve been sitting for a long time);
Change the room you’re working on;
Take a shower;
Take a (short) nap;
Go on a walk (to your backyard 😢) and look at the sky;
Play a song on your guitar;
Play with your pet;
Tell your loved ones you love them;
At least go drink some water! You get hydrated and it may boost your productivity!

The important part is to get some distance from the problem you’re facing. Context switch is really important. You may think that breaks will kill your flow, and it’s easy to convince yourself that you don’t have time for them, but hear me out: they work! Well, you don’t have to trust me, science has shown this over and over again.

I can’t take a nap! I’m working!

I realize not everyone has the freedom/opportunity to do those things. Or you may not be comfortable doing them during work time, and I get it. So, I’ll list some alternative tasks you can do instead. I call them productive laziness because even though they’re not your primary task, they’re still useful (for you and your app)!

Productive laziness tasks

Review Pull Requests from libraries you like

You don’t need to be a maintainer to do this! OSS folks have lots of work to do, so go ahead and give them some help (and maybe you do end up as a maintainer). You don’t need to be an expert in the project. Just knowing the programming language behind it can help you! You can suggest better variable/method names or methods with better performance, for instance. But please, be kind.

Open Pull Requests for libraries you like

If you’re feeling brave, you can help OSS ever further! Fix some bug reported into their issue tracker. Maybe a refactor or performance improvement? Search for issues with tags likegood-first-issue, easy, beginner or first-time-contributor. That’s how I got my first contribution merged into Rails!

Read docs from languages/libraries you use

This is quite obvious, but learning that one method can save your life later! You may found a new helper method that makes your code simpler or faster.

Read a blog post

This is basically the same as the previous one, but it doesn’t have to be technical. You can learn some productivity technique, read something inspiring or just laugh out loud. I’m pretty sure you have some marked as “read later” somewhere.

Write a blog post

I’m pretty sure you have something to tell. Don’t worry, you don’t have to finish it right away. Just put some basic ideas in the paper. You’ll perfect it later.

Learn some keybindings on your text editor

Consider this an investment: a couple of minutes today saves you a life of keystrokes! You can learn some terminal tricks too! It is the same idea.

Reply that one email you’ve been postponing

It’ll only take you 5 minutes. Get rid of it accumulating dust in your mailbox and in your brain.

Pay off some technical debt

This is by far my favorite alternative task. Here you can do what you like the most:

Fix N+1 queries;
Add tests to improve your test coverage;
Improve the loading time for some page in your web app (using lighthouse and other dev tools);
Fix that one exception that your monitoring tool reported. This might be a good opportunity to start TDDing. Here’s how.
Solve some simple CSS problem: alignments or spacing issues, for example;
Refactor some nasty code you find. You can do simple things like renaming variables/methods or extracting functions/classes.

Remember:

“A refactor a day keeps the rewrite away!” - Developer Granny

You may not fix that nasty bug by the end of the day, but a least your app will be faster/cleaner/have more tests! I think that’s a nice trade-off.

It’s all about incentives!

These short tasks give us small wins, and they motivates us to keep working on annoying chores.

Here’s something to keep an eye on: be sure to make the laziness time-boxed! You don’t want to spend the whole day in a alternative task 😜.

Finally, no matter how your day goes, be kind to yourself. Some days are amazing, some days are terrible, but most days are just doing the work of life. Do your best to enjoy them!

A Simple Way To Get Started With TDD

Matheus Richard — Mon, 18 Jan 2021 13:49:33 +0000

TDD is awesome , but also confusing (and even scary) for those who never practiced it. But it doesn’t have to! We’re gonna learn how to get started with it by fixing bugs (so we can kill two birds with one stone).

» If 3 min is too long, here’s the TL;DL

OBS: the code snippets are below are in ruby, but the core concept applies to any language.

Oh, no! You got a bug in production!

Your monitoring tool is screaming at you the famous Billion Dollar Mistake: NoMethodError: undefined method 'split' for nil:NilClass

You look at the logs a see where this exception raised:

NoMethodError: undefined method `empty?' for nil:NilClass
your_app/models/user.rb:2:in `invalid?'

Something went wrong with that User model. Let’s check its code:

class User < BaseModel
  def invalid?
    @name.empty? # <-- The error occurred here
  end

  def save!
    raise 'Cannot save invalid user!' if invalid?

    :saved_on_db # I'm simplifying the record creation on DB here
  end

  # ...
end

So, before saving the user, it had a nil name. We have a validation, but it only checks if @name is not empty. Well, this is probably the bug: it shouldn’t allow nil values too.

Before we run to fix this bug, let’s confirm our thesis by writing a test that reproduces the error. This is very important! If our test fails with the same error that the monitoring tool had, we’re on the right track.

class UserTest < Test::Unit::TestCase
  def test_that_user_with_name_is_valid
    user = User.new(name: 'Matz')

    refute user.invalid?
  end

  def test_that_user_with_empty_name_is_invalid
    user = User.new(name: '')

    assert user.invalid?
  end

  def test_that_user_with_nil_name_is_invalid # <-- New test here
    user = User.new(name: nil)

    assert user.invalid?
  end

  def test_that_can_save_user_with_name
    user = User.new(name: 'Matz')

    assert_equal :saved_on_db, user.save!
  end

  def test_that_cannot_save_user_with_empty_name
    user = User.new(name: '')

    assert_raise_message('Cannot save invalid user!') do
      user.save!
    end
  end
end

We run it and… BOOM!

Error: test_that_user_with_nil_name_is_invalid(UserTest):
  NoMethodError: undefined method `empty?' for nil:NilClass

So, we’re able to reproduce the error. Now we must fix the bug, and if we patch it correctly, this test will pass.

We should check if user’s name isn’t nil before checking it isn’t empty:

class User < BaseModel
  def invalid?
    @name.nil? || @name.empty? # <-- In Rails this could be written as `@name.blank?`
  end

  # ...
end

We rerun our tests, and now we’re green!

Loaded suite /your_app/tests/user_test
Started
.....
Finished in 0.000720944 seconds.
-------------------------------------------------------------------------------
5 tests, 5 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed

We TDDed, so…?

With this approach, we’ve not only fixed the bug but added a test confirming our fix (making sure the error doesn’t happen again). Now, just open a Merge Request for it (or push to master you’re feeling rebel enough).

TL;DL

Let’s review the steps:

Identify the bug;
Write a test that reproduces the error; (This is the critical step)
Fix the bug;
Watch the test pass.

I hope this helps you too see some TDD niceties! Happy TDDing!