DEV Community: João Brandão

🥋 Happy Teams with Coding Dojos

João Brandão — Tue, 11 Apr 2023 09:55:39 +0000

Building and powering up software development teams is not just about hiring good developers. It’s also about keeping them happy, challenged and engaged.

Over the past years, I’ve been pushing for the teams I work with to share the knowledge between their members. I’ve done it through Knowledge Sharing Sessions, Hands-On Sessions and more recently with Coding Dojos. All of these have had great advantages for teams but I noticed that Coding Dojos have not only a great technical and social impact but they’re also a great contribution to the team member's happiness.

Let’s see two of the Coding Dojos fundamental pieces and some tools to help with them.

“A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge.“ - codingdojo.org

Challenges

As per definition, the main goal is to tackle a programming challenge. The challenge is what you want to solve. There are so many different ones that, for me usually the most difficult part is choosing one.

Choosing a challenge always depends on what exactly you want to technically tackle. I tend to choose according to what I see and understand from the team’s daily work: difficulties, improvements or new topics to keep the learning going.

Here are a couple of topics that usually challenges want to tackle:

SOLID principles
Pair-programming
Refactoring
Test-Driven Development (TDD)
...

And here are a couple of Web sites to help you pick them up:

LeetCode

Dojo Puzzles

Kata-Log

Constraints

As I said initially, Coding Dojos are not just about the technical impact but social as well. Constraints are how you want the challenge to be solved. I like to call this the fun part of Dojos. They are a set of rules that participants must follow so the result is valid.

Here are a couple of constraints that I usually choose for Dojos:

1 pilot (coding) + 1 co-pilot (helping) + rest in silence.
No passing of primitives between methods as parameters or return types.
Do not use “else”.
No more than 2 parameters per method.

By adding constraints to the challenge we can:

Enforce participants to choose specific technical topics to overcome the challenge.
Enforce collaboration and communication between participants.

Tools

Currently, more and more teams work in remote environments so we should use the right tools to help us out. I’ve been mostly using a combination of an IDE/Code Editor and whatever provider the team uses for calls. The goal here is to have everyone writing and reading code at the same time and in the same place while they’re able to speak to one another.

VS Code has been my number 1 choice for this. It allows multiple people to work on the code at the same time by using the Live Share extension with very decent performance! Plus different developers use different IDEs and code editors and VS Code can run in a Web browser just by going to vscode.dev. I mean, anyone can be up and running for the Coding Dojo in less than 5 minutes with pretty much everything they need.

VS Code - Host

VS Code - Participant in a Web browser

Conclusion

I have been using Coding Dojos mainly for three reasons:

technical skills improvement
engaging the team to socialize and have fun together
bring community trends and best practices in

We pick up a challenge which is about what we want to tackle on the technical side. The challenge we choose is usually related to topics we want the team to improve or learn based on topics like TDD, SOLID principles, refactoring techniques and many more!

Solving problems to technically improve people and teams is great. But there’s nothing like having fun doing it! To do that, we usually add constraints to the challenge to impact how people interact with each other.

So now go and try it yourself! If you do, let me know about the outcome. 👋

🧪 Given, When, Then

João Brandão — Tue, 11 Apr 2023 09:51:46 +0000

In this post, let’s check Given, When, Then. A sequence of **words that not only helped me to improve my way of thinking about coding but also has been helping me in my personal life.

Background

I started to think more about Given, When, Then when I got into software testing. In this post, I told you that used to spend a lot of time improving my coding skills by watching videos in Laracasts. There are a couple of testing video series in there and in almost all of them, they write the tests in the same way:

**Given** I have this
**When**  some action is triggered
**Then**  I expect that to happen

If you think about this, you can cover so much ground with such a simple way of thinking. And if you structure your tests in the same way, you end up with code that is very simple and easy to understand, making them very straight to the point.

I started to think and use more and more this concept. Not only for testing but pretty much for all steps of a feature’s lifecycle.

Let's jump into a technical example.

Technical Example

Let's imagine that you and I have a Pet Store website and, during this month, we have a 10% discount on our Premium subscription. So, every time a free account user login we want to show them a message saying: "Hey 👋 Subscribe to Premium now with a 10% discount!".

At this point and technically speaking, we want to create an endpoint from where we can get a subscription discount for a given user: GET /v1/discounts

Planning

You're the one creating this endpoint! We start by getting together and creating a working ticket. In there, we want to ensure that we include something called Acceptance Criteria. When you finish your work, you'll pass the ticket to me. I'll be responsible to test it and ensuring that what you implemented covers every use case that we wrote on that Acceptance Criteria. Let's check the ticket!

# Description
We want to create an endpoint in our API that allow us to get the available
discount for a given user.
Later, the UI will handle the received discount value and provide the message.

# Acceptance Criteria
**Given** I am a User
and   I have no subscription (free account)
**When**  a request to get my discount is made
**Then**  I should receive a 10% discount.

**Given** I am a User
and   I have a Premium subscription
**When**  a request to get my discount is made
**Then**  I should receive nothing.

Development & Testing

You picked up the ticket from the queue and put your hands to work! You ended up developing a pretty simple logic.

@Controller('/v1/discounts')
class DiscountsController {

    @Get()
    getSubscriptionDiscountForUser(
        @UserToken() user: User,
    ): Discount | undefined {
        if(user.subscription === Subscription.PREMIUM) {
            return;
        }

        return new Discount(10);
    }
}

In the DiscountsController, you added a getSubscriptionDiscountForUser method. That method receives the User object resolved from a token passed in the request (@UserToken() decorator will do that for you). You return undefined when the user.subscription is already premium or a new instance of Discount with the value.

To ensure that this works as expected, you created two tests for the new code:

The first one verifies that you get the 10% discount when a user subscription is free.
The second one verifies that you get no discount when a user subscription is a premium.

Let's see those tests!

describe('getDiscountForUser', () => {
    let controller: DiscountsController;

    beforeEach(() => { controller = new DiscountsController() });

    it('should return a 10% discount when user has a free subscription', () => {
        // Given I am a User with a free subscription
        const user = new User(Subscription.FREE);

        // When I get my discount
        const discount = controller.getSubscriptionDiscountForUser(user);

        // Then I should receive a discount with a value of 10
        expect(discount).toBeInstanceOf(Discount);
        expect(discount.value).toEqual(10);
    });

    it('should return undefined when user has a premium subscription', () => {
        // Given I am a User with a premium subscription
        const user = new User(Subscription.PREMIUM);

        // When I get my discount
        const discount = controller.getSubscriptionDiscountForUser(user);

        // Then I should receive no discount
        expect(discount.value).toBeUndefined();
    });
});

Nice one! I noticed that you used a similar approach to the one in the Acceptance Criteria of the ticket to create your tests.

QA

You finished your work and passed me the ticket for some QA. Let's bring that ticket back!

Ok! So we need 2 users: one in a free account and a second in a premium account. After getting those, I'll use an HTTP client tool and execute two requests:

curl "http://pookiequino.pet/v1/discounts" \
    -h "Authorization: Bearer $freeUserToken"
# Response: {"value":10}

curl "http://pookiequino.pet/v1/discounts" \
    -h "Authorization: Bearer $premiumUserToken"
# Response: undefined

Perfect! Now I got the 10% discount for the user in a free account and got nothing for the user in the premium account.

As you probably noticed, we used this Given, When, Then concept in different steps: planning, development, testing and QA. This is something that is not oriented to testing but a way of thinking that can help you through many steps.

Let’s take a look at this concept applied to non-technical matters.

Applied to Personal Life

As I started to use this Given, When, Then daily at work, I noticed that I was also applying this in my personal life.

If you pay a little attention to your thoughts over your day, you’ll notice that, without even planning on it, probably your brain is already behaving in that way.

I’ll give you one of my examples! A couple of months ago, my partner and I were thinking about adopting a second cat. At first, I was very reluctant about it as I was afraid of Pookie (first cat) not receiving the kitten well. As for any important decision, I started to think more about it: upsides and downsides. As I was listing all of these points in my head I started to structure them in a Given, When, Then way, like this:

# Upsides
**Given** I have a cat
and   I work from mon to fri
**When**  I adopt a second cat
**Then**  they will make each other company

**Given** I have a cat
**When**  I adopt a second cat
**Then**  they will play together
and   they will be less sedentary
...

# Downsides
**Given** I have a cat
**When**  I adopt a second cat
**Then**  I'll have at least 2 litters to clean
...

Conclusion

Given, When, Then are just three simple words that combined create this simple and logical way of thinking. It is something that your brain does every day without you even noticing. You just need to be more aware. As it naturally occurs, If you take advantage of that flow of thinking you can easily apply it to pretty much anything.

As a software engineer, this has been helping me through most of the development cycle steps of a feature. It is also useful to improve team members’ communication by creating this kind of standard way of defining what is expected to happen. This way, developers can take advantage of that information to guide them through the coding process. Testers take that statement as their source of truth for what's expected when testing a feature.

I hope you've enjoyed it, cheers! 👋

P.S. The Cats are now each other besties! 🐈🐈

Hero to Zero

João Brandão — Tue, 11 Apr 2023 09:29:03 +0000

If you’re learning something new within the programming world, most likely you’ll be able to find some tutorials with the title “Zero to Hero...”. It means that you'll be learning everything you need to deliver some awesome work with it, from the scratch!

Now, let me tell you an opposite story: from hero do zero!

About a year and a half ago, I was working as a developer for almost 3 years at a big company. By that time, the team was building the new version of its main software. You can probably see what this means: we were redesigning the whole architecture for the system. What a challenge!

At the same time, we wanted to migrate from the legacy no framework PHP 5.4 to a brand new monolithic Laravel application. Right from the beginning, I fell in love with Laravel and started to push myself to learn more about it day after day. This made me subscribe to Laracasts, a platform to push your web development skills to the next level. At night, I started watching Jeffrey Way diving into Laravel while washing dishes. By day, I was applying the concepts that I was learning: design patterns, tips and tricks, everything!

A year later, I was working on every step of a feature's life cycle: requirements, architecture design, coding, deploying and sometimes presenting it to clients. This hero kind of feeling started to arise - doing anything with a small amount of effort. In other words, it felt like I wasn't learning and improving my skills and myself as much as I wanted. Pure coincidence, a recruiter reached out to me with this: You'll be designing, building and maintaining APIs and workers in a microservices architecture, using Node.js and Kotlin, plus deploying your code through the CI/CD process. Quoting our beloved friend Yoda: "Much to learn, you still have"!

I have to admit: I was so scared of just thinking of moving to a different job. Even more at the time that Covid made us all go into lockdown. Everything felt so uncertain. Even though, I went for it. It was tough, but at the end of March 2020, I joined a small company, which meant: moving from a ~4k people working place and always working at the office to a completely remote startup environment. I felt I was back to zero - learning everything from scratch: new programming languages, frameworks and DevOps stuff that I had never worked before in my life. But everyone on the team was so available to share their knowledge that it kept me going, and most importantly, wanting to keep on this learning journey. The feeling of learning new things day after day and my brain having difficulties executing some tasks... It was such a good feeling! At the same time, the impostor syndrome hitting me. I think that at some point, we all go through this - time passes and you feel like you should be better by then. I still feel it sometimes.

After a year in this role, I'm back at architecture design, coding, deploying. Node.js and TypeScript became the default for my brain and I started to explore more of the JVM world with Kotlin and Spring. I learned so much in the past year and I still feel that I have so much to learn.

It's not the road from zero to hero that makes you improve. Neither the other way around. All of those different situations have a certain weight on your life's learning journey. On yourself! I'm still very eager to keep going, learning, improving but I'm also so grateful for everything and everyone. After all, learning is an ongoing process. We'll never know everything.

This is my retrospective. It doesn't mean that you have to go through all of that to feel the same. You are responsible for your path, needs and happiness.

🔄 Self-reference Laravel Model

João Brandão — Tue, 11 Apr 2023 09:27:32 +0000

First things first!

A year or two ago, when I was a Software Engineer at Bosch a colleague of mine came with this amazing solution of a self-reference trait to map relationships inside a single SQL database table. He wrote a small but very effective piece of code and then I just added the ability to change the name of the database column responsible to keep that relationship.
So, all props to Sérgio here! 👊👏

Use case

Big companies tend to have big nested levels of hierarchy organization. So the main goal here was to create a departments database table to allow people to manage how many nested levels of departments they want. Let's see the example.

Department 1

Section 1

Team 1

Team 2

Section 2

...

You can imagine this scaling up to Country Department, Europe Department, or even if they'd like to create groups of people inside a team with a large amount of people.
Well, we wanted to provide our end users the freedom to organize their teams as they wish!

Let's use the next set of data for future examples!

departments

Show me the code!

Let's dive into the code then! The following Gist contains the Trait that will be used in the models on which we want to apply the self-reference relationship. Take a look! 👀

https://gist.github.com/joaorbrandao/f23c8e4cdf776a2dfe7fd1f75f64f15e

As you can see, it is a small piece of code but powerful enough to get the job done.

When using Laravel's model relationship methods they will return the relationship itself (BelongsTo, HasMany, ...). But if we access it like a property, Laravel will automatically get us an instance of the related entity!

Let's make use of our brand new Trait in our Department model.

class Department extends Model {
    use SelfReferenceTrait;
}

The parent method

The parent method defines a belongsTo relationship. This means that a deparment can belong to another one.

parent will return a Department instance, when the current department has another department above or it will return null when there are no more departments above.

// Let's get 'Development'
$department = Department::find(3);

$parent = $department->parent; // Product

The children method

The children method defines a hasMany relationship. This means that a department can have many other departments bellow it.

children will return a Collection containing all the departments on the next level bellow. In other words, a list of departments that their parent_id equals the id of the current model. If there are no departments above, then the collection returned will be empty.

// Let's get 'Development'
$department = Department::find(3);

$children = $department->children; // Backend and Frontend

The allChildren method

The allChildren method takes advantage of the Laravel's relationship method with to eager load a nested relationship. But in this case, instead of redefining the relationship inside our new method, we use the already defined children method to get the next nested level and then eager load our own allChildren relationship, again! "Say whaaat?!" 🙃

Well, let me make it easier: we loop through all nested levels until all children are loaded! 😄

// Let's get 'Backend'
$department = Department::find(5);

$allChildren = $department->allChildren; // Develpment > Backend and Frontend

The root method

The root method is pretty simple: it checks if the current department belongs to any other and if yes, then it repeats that process until it finds the record on that tree that has a parent_id value of null.

// Let's get 'Backend'
$department = Department::find(5);

$root = $department->root; // Product

I hope that this is as useful for you as it was for our team! Feel free to use it! 🚀

Cheers! 👋

💅 Automatically Format PHP Code

João Brandão — Tue, 11 Apr 2023 09:24:55 +0000

I love to have everything organised and to keep the code as clean as possible. And to do this by hand it's just really boring... And let's be honest it's also something from the past century because there are a lot of useful tools to beautifully help us keeping our beautiful code organised! 🙌

In this post, I'll show you how do I setup my PHP projects to be automatically formatted. 👀

1. Setup Formatter

1.1. Install the package php-cs-fixer

composer require friendsofphp/php-cs-fixer

1.2. Create a .php_cs file on the root of your project

<?php

$finder = \PhpCsFixer\Finder::create()
    ->in(__DIR__)
    ->exclude(['bootstrap', 'storage', 'vendor'])
    ->name('*.php')
    ->ignoreDotFiles(true)
    ->ignoreVCS(true);

return PhpCsFixer\Config::create()
    ->setRules([
        '@PSR2' => true,
        'array_syntax' => ['syntax' => 'short'],
        'ordered_imports' => ['sortAlgorithm' => 'length'],
        'no_unused_imports' => true,
    ])
    ->setFinder($finder);

In this example, here's what will happen:

bootstrap, storage and vendor directories will not be formatted.
All *.php files will be considered.
PRS2 rules are the ones that are going to be used!
Arrays like array() will be transformed to [].
Import statements will be ordered by their length to give that pyramid effect.
Unused imports will be removed.

Check the package documentation and change according your needs!

1.3. Add a script to your composer.json file

"scripts": {
    "format": "vendor/bin/php-cs-fixer fix"
}

1.4. Run it

composer format

Check the following basic example!

<?php

namespace Package\Services;

// Unwanted space here!
use Package\Box;
use Illuminate\Support\Facades\Session as LaravelSession; // This should be the last!
use Package\Contracts\SomeInterface;

class SessionService implements SomeInterface
{
        // Unwanted space here!
    public function load(): Box
    {
        return LaravelSession::has(Box::class)
          ? LaravelSession::get(Box::class)
          : new Box();
    }
}

Only 1 space after namespace.
LaravelSession use line moved to the final import because of its length.
Removed an empty line before load function.
Added an empty line to the end of the file.

<?php

namespace Package\Services;

use Package\Box;
use Package\Contracts\SomeInterface;
use Illuminate\Support\Facades\Session as LaravelSession;

class SessionService implements SomeInterface
{
    public function load(): Box
    {
        return LaravelSession::has(Box::class)
          ? LaravelSession::get(Box::class)
          : new Box();
    }
}

2. Make it run automatically

Now you can run it using composer. But that only means you can run the command... by hand!
Ideally would be to add this to your CI/CD pipeline alongside your tests! But most of the times, at least for me, I don't have a pipeline setup for really small projects like packages.

So I just use husky-php! This is a package for PHP to work with git hooks just like NPM's husky.

2.1. Install husky-php

composer require --dev ccinn/composer-husky-plugin ccinn/husky-php

2.2. Add the hooks to composer.json

Check the package's documentation if you want to use other hooks!
Normally I just use pre-commit for formatting and pre-push for testing.

{
  "hooks": {
    "pre-commit": "composer format",
  }
}

Now when you commit your code, composer format will run automatically! 🚀

I really hope that this is as useful for you as it was for me! 👋