DEV Community: Umair

Why should we use Lombok's @Builder annotation ?

Umair — Mon, 26 Jul 2021 19:35:42 +0000

Have you also ever looked at the long list of getters and setters methods in an Object class, like this User class (for example)

and got a gut feeling that all these boilerplates are useless. There must be a better way to achieve similar functionality ?

Well, we were correct!

What to expect out of this article ?

In this blog, We’ll be discussing what Lombok's @builder annotation is and why we need it in the first place? Bit about how we can use it.

Why am I writing this ?

This is to set the context for next article. In which I'll be sharing with you a recent learning which we had in our project, of course, related to this Lombok's @builder.

Before diving into this annotation, let’s review what Lombok is.

What

Recently, I have started working in Java and that’s how I came to know about Legendary Lombok. For those people who haven’t encountered it yet (like me, until recently) -

Lombok is a Java library. Easily integratable with our IDE, build tools. It provides getter, setter, constructors, few other default functions like equals, etc. We just have to use it’s annotations. It works out of the box.

@builder annotation enforces Builder Design Pattern. It provides APIs to build objects of the annotated class. It also provides an option to convert existing objects into it’s builder, so that we can modify and rebuild it.

Why

If we have to build object of the User class shown above, (without using Builder) we’ll be doing something like this:

This is still okaish, we’re just setting each of the properties of the user class object. What's more annoying is that there is a long list of getter and setter methods in the User class. Which are nothing but boilerplates. So kinda frustrating.

How

This is where @builder annotation of the Lombok comes into picture. If we just annotate our User class with @builder then all the getter setter boilerplates from our User class will be striped out. The Object creation would get simplified something like:

You see, how intuitive it becomes ? It’s just like assigning properties value and building it.

So this is how we create User objects from a builder or raw values. But, what if we want to convert an existing object to it’s builder equivalent.

For that purpose, @builder provides a configuration parameter toBuilder. This is how we configure and use it:

That's a quick intro about Lombok, @builder and it's toBuilder.

Watch out for next article regarding our recent learning experience.

Just to ignite the curiosity in you, so we we're modifying an object exactly similar to one shown in above example. As a result, instead of updating same object it was behaving bit weirdly. That's how we uncovered an interesting part of this. Which we'll be covering in next article.

Looking forward to your feedback

How to create an automated code cleaner with pre commit hook

Umair — Wed, 18 Sep 2019 15:59:17 +0000

We had a repo with code, some parts of which were not formatted properly. So this is the story of how we kick started our mission to clean-up our codebase, eventually, using git pre-commit hook. Maybe we won’t need these anymore (as nowadays, IDEs have these in-built) but my motto is to demonstrate how we can automate & improve our day to day development process, with no to very little efforts.

So the other day, I was going through the pull request of my teammate and I noticed that several minor code formatting have been overlooked. Those very ignorable (as per normal human being) so I felt a bit kinda stupid of myself to explain the logic behind my thoughts and comment to fix them. I wish we had a Development Style Guide defined and mutually agreed upon also but unfortunately, we didn’t. Something like this https://thermondo.github.io/style-guide/

So I thought why don’t we automate this whole code formatting process. So for that we need to agree upon a code style format and figure out a way to format in common way.

Lucky for Python we have a very well-defined PEP-8 https://www.python.org/dev/peps/pep-0008/ which I really miss in few other languages. So with this our first checklist was DONE.

Secondly, we had to figure out a common way to format our code. We discovered this jewel, black - https://github.com/psf/black.

Now the human behaviour come into play, we had everything in place. A style guide and a formatter but sometimes we were not conscious enough to format our code before committing. This part was not in the initial plan, typical example of - why software projects are not delivered on time. Surprises everywhere!
So we took this as a challenge and thought about automating this part too. Maybe integrate it with something that we won’t miss.

All of us had one thing in common and we can’t miss that - Committing. We were using git as our version control system thus all of us will certainly use git commit. How can we integrate this to commits itself - git pre-commit hook came to our rescue.

We designed this tiny very simply pre-commit hook to format and verify our code before committing it.

for file in $(git diff --cached --name-only | grep -E '\.(py)$')
do
  black "$file"
  $(git add "$file")
done

for file in $(git diff --cached --name-only | grep -E '\.(py)$')
do
  flake8 "$file"
  if [ $? -ne 0 ]; then
    echo "flake8 failed on staged file '$file'. Please check your code and try again. To check output manually run flake8 $file"
    exit 1 # exit with failure status
  fi
Done

So with this no manual intervention was required. We only needed to committ as usual and it will auto-format the code and verify it - sometimes black fails or something goes wrong, so it’ll fail in verification stage and we’ll need to manually fix it.

So just for the sake of clarity, in pre-commit hook we’re iterating through the files staged to be committed and black(ening, auto-formatting them) and then again verifying them same way - exit with non-error code just to indicate error occurred. We need to place this in our repo at .git/hooks/pre-commit For this hook to work we need to have black and flake8 pre-installed in our system.

Learning:

We started to not worry about formatting our code.
We didn’t need to worry about missing a line or two.
WE WERE CLEANING OUR REPO - best part was unconsciously. If we opened a file after a while, we felt like a magic, when did we format this file ? Awesome!
We were not bloating the commits with irrelevant changes - by only formatting those files which we were committing anyways. Passive code clean-up drive.
Lots of developers time were saved, arguing whether & why to have curly braces at the end of line or in the next line.

References:

We discussed this pre-commit hook :

https://gist.github.com/umr55766/ece111837cfb468211ccacb9e65fb5be
We used this : The uncompromising Python code formatter https://black.readthedocs.io/en/stable/
Tool For Style Guide Enforcement : https://github.com/pycqa/flake8

Pair programming vs Long drive

Umair — Wed, 18 Sep 2019 15:45:37 +0000

As we want to build products which are maintainable, extensible and scalable in the long run. Usually we do this with the help of a team of solo developers. Let’s see how this can be done more efficiently in a better way with developers working as pairs.

Recently I went through a Developer Bootcamp focused on Agile methodologies of Extreme programming. Pair programming was one of the focus of my bootcamp. This bootcamp was like an eye opener for me, so I would like to share a few misconceptions which were cleared in the same.

Before we get into technical stuff of pair programming, I would like to tell you a short story from a real life incident which is analogous to software development.

One fine Saturday, me and two of my friends decided to go on a long drive. I took my bike and my friends started with their car. Since I was on two wheelers I was able to pierce through the city traffic very quickly, but as soon as I got to the outskirts of the city, my progress was struck, because I have to stop and see the navigation map in short intervals and therefore I cant drive myself beyond a certain speed. Whereas my friends were behind me, stuck in the city traffic, but as soon as they crossed the chaos of city traffic their velocity became quite high and sustainable, as one of them drove and the other navigated.

Do you see the difference ? Why my friends overtook me in cars, even though I was able to take a good lead in the beginning?

If you’re wondering how is this related to pair programming, keep reading.

No alt text provided for this image
So basically, the same thing happens in traditional project development. In kick off phase of any project we just allocate head counts and ask them to start working. At first, everything seems to be smooth,We can see new features being released frequently. Remember how I pierced through the city traffic and took lead ?

But as the project progresses and things start getting complex ,few small issues start popping up. Code reviewers starts getting too many code review requests and then it becomes bottle-neck.

What if a person responsible for devops fall sick ? What if I met with an accident ? If something goes wrong (which I hope never to happen) with one of my friends, another can take over. This is called the Bus effect in action.

So to sum up -

Pair programming is an agile software development technique in which two programmers work together at one workstation in order to :

deliver efficient work
write code with fewer bugs
share technical knowledge while developing (thus reducing pain points)
upskills developers interpersonal skills

Now, few misconceptions which I had :
Why should an experienced person waste time ramping up novice ?
Focus is on building up large pool of redundant assets rather than only on delivering features.

It’s like carrying Stepney, which would help you when something goes wrong with the main tire. Reducing Bus effect.

Some may feel that they are not able to get into focused mode, since they are supposed to talk while thinking/coding. -

They can ask for a time-boxed break to think independently and then come up with data.

It’s like using first gear in steep ascend, where speed is slow but it elevates you. Don’t expect to drive in same speed/gear throughout the journey.

Some may feel that it takes two asset and double man-hours to accomplish same features

Reality is code review and the refactor cycle time is saved. It’s not exactly double, it’s way less. And at the same time, quality is way beyond the sum of the parts.

Four wheelers takes more space than two wheelers but in long journey two wheelers can’t beat them

No alt text provided for this image
Two wheelers(solo developers) can help in conquering city traffic(starting of big projects). But if we want to go on a comfortable(maintainable), sustainable long(scaleable) journey(product). Four wheelers(pair programming) are go to. It(pair programming) has redundant assets — drivers, tyres, etc (large pool of assets). It(pair programming) has more momentum (one pair can motivate another one). It(pair programming) is fault-tolerant (One pair may catch corner-cases missed by another pair), safer (reduces bus effect)

Still not convinced ? Cool! Checkout this research paper https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF and let’s connect!

Thanks for your time. Let me know your feedbacks.