Forem: Jose M Valera Reales

Update your team to be more extreme

Jose M Valera Reales — Sun, 27 Feb 2022 08:00:43 +0000

Our profession is constantly evolving; therefore, it demands a non-stop learning process. Embracing the change is not optional in our software industry.

We need to create spaces to get out of our comfort zone, so our cognitive brain can train and improve how to adapt to our surroundings, which are constantly transforming.

Continue reading at:
https://chemaclass.es/blog/update-your-team-to-be-more-extreme/

Open-Source Software

Jose M Valera Reales — Mon, 03 May 2021 08:18:41 +0000

The power of contributing to OSS 🖥

What is Open-Source Software (OSS)? 🤔

OSS shares similarities with free software but it’s not the same. Free software is a form of OSS, but that doesn’t necessarily mean that it has to be free. For example:

PHPUnit is an example of OSS which is free.
Spryker is an example of OSS which is not free.

OSS is basically software that is public, open to the world.

Benefits — for a company 🛕

Adoption: the easier the access, the easier the adoption.
Training and tutorials help the system to grow.
Tech: often on the cutting edge of technology. Tech moves fast. They will get obsolete if they don’t.
Community: the people around want to improve as it grows. Public channels enable easy access and community building.
Trust: the software is public and accessible. Everyone can check the quality of the software anytime.

Benefits — for you, as a single contributor 🤓

Flexibility: decide on what you want to work on.
Self-confidence: the experience improves your skills.
Training: without the pressure of a PROD environment.
Tech: play with the latest features of your tech. Try upcoming versions of your coding lang, or even try new ones!
Soft skills: improve your communication skills. Good communication in the project is important. Especially when you face disagreements.

TL;DR: It can be a “constant kata” if you want to.

Github to the rescue 😃

Nowadays, it’s really trivial to start contributing to OSS:

You can start your own project. A pet project fits here perfectly!
You can contribute to an existing OSS project.

Pet projects 🐘

A pet project is a playground to create software and train your professional skills. Creating pet projects in your public Github profile has all the benefits of contributing to OSS, plus you’re your own boss:

You dictate the roadmap.
You decide what to do and how.
You’re your own boss.

The project is there for you.
You are responsible to play, explore and pass your limits.

Some Chema’s Pet Projects 🦣

Active

php-best-practices: what I consider best practices for web-dev.
php-scaffolding: a basic PHP scaffolding with Docker.
typed-arrays: generics replacement for PHP.

Inactive

stock-ticker: get a notification with the news from your favorites Tickers.
jira-status-notifier: Notify when the JIRA tickets don’t move along.
edifact-parser: a parser for a UN/EDIFACT file format in PHP.

Abandoned

knob-mvc: a framework to create WordPress templates (2015/2017).

Some of Chema’s OSS org contributions 🌚

Active

phel-lang: Phel is a functional programming language that compiles to PHP. It is a dialect of Lisp inspired by Clojure and Janet. I already wrote a post about phel-lang: Phel: A Lisp that compiles to PHP
gacela-project: Gacela is a PHP framework that helps you to improve the design of your application by splitting the logic into different modules.

Abandoned

nm_template: The base template for NuevaMetal (2013–2016).

Knowledge sharing ✍🏼

... and many more on https://medium.com/@Chemaclass

The beauty of this 🧑‍🎓

Seeing the corrections that you constantly keep doing
Seeing how your own code gets old with time
Seeing the many mistakes that you have done
Seeing how you are getting better at coding over time

Developing a sixth sense to smell patterns which you have already done and their positive & negative experiences.

Showing your skills and helping the community around you.

Open-Source Software offers you one of the best opportunities to start building your career path towards continuous improvement.

References

Getting started with Open Source Software

Originally written in https://chemaclass.es/blog/the-process-itself-is-the-goal/

Pull Requests vs Pair Programming

Jose M Valera Reales — Mon, 05 Apr 2021 14:50:25 +0000

Why choosing when you can have both?

Pull Requests

A Pull Request (PR) is basically a way of showing your suggested code changes such that they are easily comparable with the existing source code. This is part of a workflow that helps developers to share knowledge about the changes that are being done within the system.

A Pull Request is the moment where you ask your peers to review and check out your code changes.

Usually, it’s also used:

For discussions about code style.
To spot potential bugs.
For architectural or design discussions once the solution is done.

Pull Requests aren’t the best tool for everything

The main problem with these topics above is that PR’s are usually ready when the feature/bug is already being worked on and in the last stage of its development process. It’s an “already change proposal to be merged into the current system”, don’t forget that.

The concept of “Draft PR” exists to make explicit that a PR is not ready to be merged, so it’s still a “work in progress thing”, but that’s another topic.

Pull Requests are, indeed, one of the best tools that we have in our industry to share knowledge about the changes that we are doing in the system, but sometimes they might be misused, as for example:

Discussions about code style. Code style shouldn’t be discussed in a PR. There should be already a CI running a code style checker, that’s all. If you want to talk about code style, request a change in your code style checker, but not in a random PR.
Spot bugs. Bugs and desired behavior should be covered by automated tests. The developer is the first responsible person for this topic.
Architectural or design discussions. Once a particular solution is developed and ready for review, it is usually really hard to “rollback” that idea and rewrite it again. Because “why would you do that? For some subjective opinion? It’s done already. And it seems to work just fine.”

Having an extra person looking at the changes that we have done for “designing decisions” might be beneficial, but we could have addressed “potential disagreements” in a sooner stage.

What should the purpose of a Pull Request be?

Sharing knowledge about the proposed changes with the team.
Ensuring the team aligns and agrees across the multiples changes that are getting submitted every day in order to keep a healthy direction for the project. Yes, this might include double-checking the outcome design, but… What if that is now too late? How could we solve all those issues?

Pair Programming

The concept of “Pair Programming” can be understood from different points of view. Pair thinking and pair programming, driver-navigator roles concepts, or pure live coding from one side. Actually, this is way easier than it looks like at first instance:

Either you watch and help the other person to write code,
Or you type while getting another pair of eyes watching and helping you.

Pair Programming helps the team to work together.

Pair programming is the joy of working with an extra brain and another pair of eyes, where the key is to build a context where you two share the same goal in order to find the best possible solution. All of this while learning from each other every single second.
Pair Programming is not about developing the best solution at the very beginning. It’s about making it work, sharing ideas, and finding a better solution together. After that, you can refactor and clean the code.

Pair Programming is a continuous code review

Pull Requests are an asynchronous way to share code changes, while Pair Programming is totally synchronous because it happens at the same time.

That said, Pull Requests and Pair Programming aren’t mutually exclusive, they can coexist. They are tools, and we should wisely choose them in order to achieve our objectives.

The most common fear that I saw while encouraging to do Pair Programming is that some people are shy and they don’t like to have other eyes around them while they are coding because of:

Fear that they don’t know what to code or where to start.
Fear that others will laugh at their solutions.
Fear to don’t succeed in public.
Fear to not be able to develop the expected solution for multiple reasons: misunderstanding the task or lack of knowledge.
Fear to change your mind in front of others.
Fear to discuss and make decisions loud.
Fear of disagreeing with others.

After several years of experience on this topic

The pattern which rejects Pair Programing is basically “fear”, and being out of your comfort zone. And this is due to the misunderstanding of the roots of the actual Pair Programming concept.

Pair Programming is not “to show off in front of your colleagues” or “to be screwed by your peers”, but to be transparent (showing your skills as they really are) and improve as a team lifting up each other.

Programming is an iterative process that needs a continuous refactoring of our way of thinking in order to achieve better solutions, day by day. Therefore, programming with another person next to you (with a different way of thinking) will help the team to get the best from each other while discarding the waste or bad habits if necessary.

Pair Programming doesn’t need to be always set for everything. As a tool, it’s flexible, and we can choose how, when and for what reason.

A personal rule of thumb, before starting tasks that might involve touching multiple modules or complex business rules, think about a quick Pair Thinking/Programming with another more experienced colleague in that field.

Everything depends on a particular context and people: the developers, the pairs, the tasks, the mood.

Still uncomfortable with Pair Programming?

If you still feel uncomfortable having another person next to you while you write code, it might be because you aren’t particularly happy with your own code, or the process that you follow in order to achieve some result. My favorite way to work on this is by exercising on your own and working on improving your skills as a software developer.

Create and play around with your own pet projects.
Work on code katas on your own and with others.

Practice makes the master.

Summary

Don’t get me wrong, Pull Requests are great. Keep doing them.
Team collaboration is essential. Pair Programming aims for this.
Pair Programming encourages the team to proactively work together.
Don’t be afraid of coding while having eyes around you. Ask questions when something is unclear. Ask for help when you don’t know how to solve something.

It’s totally ok not knowing everything. The most important thing is to know how to work together.

Originally written in https://chemaclass.es/blog/pull-request-vs-pair-prog/

Embrace the change

Jose M Valera Reales — Mon, 01 Mar 2021 08:15:43 +0000

Who moved my cheese?🧀

Published in 1998 and I just read it at the beginning of 2021. Better late than never. Actually, thanks to my brother Jesús, who recommended it to me.

The book Who moved my cheese? presents a tale inside the main story that consists of four characters: two mice, Sniff and Scurry, and two little persons, Hem and Haw.

They live in a Maze (that represents one’s environment) and in order to survive they need to go out of their comfort zone and look for cheese (which represents happiness and success).

The tale starts when both groups end up at “Cheese Station C”, full of cheese. The humans established routines while the mouses kept their instincts active.

One day the mouses arrive at the “Cheese Station C” and find no cheese left. So they go out to find more cheese somewhere else. On the contrary, when Hem and Haw see that there is no cheese left, they start complaining. Hem, angry and annoyed, demands “Who moved my cheese?!”. Both humans counted on the cheese supply would be endless constant, so they weren’t prepared for that unexpected. The main difference here is how Haw and Hem react to this situation.

Hem denies moving away from the “Cheese Station C”, so he keeps going there every day expecting to find cheese without success, being weaker, and with continuous fear of doing something different. Haw, on the other hand, decides to laugh at the situation, turns down his fear, and goes out looking for more cheese.

... I will leave the rest of the tale to you.

The tale is a beautiful metaphor of the different attitudes that people adopt as part of their identity in life when they have to confront any change.

Noticing small changes early helps you adapt to the bigger changes that are to come.

This book is full of lessons that apply to everyone no matter who they are or when they read it. I fully recommend it.

My favorite lessons of the book

Change happens. They keep moving the cheese.
Anticipate change. Get ready for the cheese to move.
Monitor change. Smell the cheese often so you know when it's getting old.
Adapt to change quickly. The quicker you let go of old cheese, the sooner you can enjoy new cheese.
Change. Move with the cheese.
Enjoy change. Enjoy the taste of new cheese
Be ready to change quickly and enjoy it again. They keep moving the cheese.

"Everyone knows that not all change is good or even necessary. But in a world that is constantly changing, it is to our advantage to learn how to adapt and enjoy something better. It is not what is in the story of "Who moved my cheese?" but how you interpret it and apply it to your own situation that gives it the value." - Ken Blanchard.

Find the book in Amazon.de.

“Life moves on and so should we” — Spencer Johnson

Originally written in https://chemaclass.es/blog/embrace-the-change/

Phel: the Lisp that compiles to PHP 🐘

Jose M Valera Reales — Mon, 01 Feb 2021 09:51:56 +0000

The new functional language. Fully interoperable with PHP 🚀

The Phel Language

Phel is a Functional Programming (FP) language that compiles to PHP. It is a dialect of Lisp inspired by Clojure and Janet.

Features

Built on PHP’s ecosystem
Good error reporting
Different Datastructures (Arrays, Tables, and Tuples)
Macros
Recursive functions
Powerful but simple Syntax
REPL

Why Phel?

Phel is a creation of Jens Haase, and as he mentions on the website, “it is the result of many failed attempts to do functional programming in PHP”. He was looking for something with these characteristics:

A LISP-inspired
Functional Programming language
That runs on cheap hosting providers
And is easy to write and debug

From my point, it was ending May 2020 when I finished the book “Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages”, in which I learned a bit of Prolog, Erlang, Clojure, Haskell… I even created a repository in Github to store my progress over the weeks with these learnings.

Suddenly, one day beginning of June 2020, I saw a post in Reddit's PHP official channel, with a message of someone mentioning this “Phel” project, claiming to be a “functional programming language written in PHP”! (or something like that).

I work with PHP for around 8 years so far, and I always try to combine OOP with FP as much as possible (because I believe both paradigms are better combined; they are not necessarily exclusive), and a new dialect of Lisp fully written in native PHP 7.4 sounded really exciting. I decided to take a look at it. I wanted to see the code.

The fresh readings from Mathias NoBack books such as Object Design Style Guide, Principles of Package Design, and Advanced Web Application Architecture, gave me the courage to try out what I learned and put it for real in a project. This was (and still is) a beautiful challenge, which helps me to test myself and grow professionally at the same time.

My first commit was done on 6 June 2020, and since then I work on this project a bit (almost) every day in my free time. It helps me to learn more about FP, languages internal design, and best practices on testing and software design architecture in general.

I started applying minor changes until I ended refactoring the whole compiler structure (among other things) in order to make the modules easier to read and understand. Psalm, strict types, good test coverage, unifying code style… These were some of my favorite topics.

Example of Phel code

The following example gives a short impression of how Phel looks like:

# Define a namespace
(ns my\example)
# Define a variable with name "my-name" and value "world"
(def my-name "world")
# Define a func with name "print-name" and one argument "your-name"
(defn print-name [your-name]
  (print "hello" your-name))
# Call the function
(print-name my-name)

Current status of Phel

We have an open Gitter Community where we help each other
We prepared an easy Getting Started Guide
We prepared an easy Github Repository with a Phel Scaffolding Template
We just released the first official version: 0.1.0

Check out the official website with all documentation of the Phel Language:

https://phel-lang.org/

Also recommended

Functional Programming with Phel

Originally written in https://chemaclass.es/blog/phel-first-release/

To mock or not to mock

Jose M Valera Reales — Mon, 11 Jan 2021 09:13:41 +0000

How to escape the mocking hell

What is actually happening when we create a mock? Which types of mocks are there? Is mocking good or bad? Well, as always, everything depends on the context. And here we will consider some of the main situations about when to mock and when not to mock, but especially why.

What happens when you mock something?

First of all, we should define what a mock is:

In a unit test, mock objects can simulate the behavior of complex, real objects and are therefore useful when it is impractical or impossible to incorporate a real object into a unit test.

Mocking makes sense in a unit testing context. An integration test should go through the real implementation checking the integration between multiple units, which are even allowed to talk to the DB or File IO: infrastructure code. Therefore we should agree that a unit test is a fast and deterministic test that doesn’t rely on external dependencies and doesn’t require any special context to run.

Mock objects meet the interface requirements. In consequence, they allow us to write and unit-test functionality without calling complex underlying or collaborating classes.

A mock is a test double that stands in for real implementation code during the unit testing process. It is also capable of producing assertions about how it was manipulated by the test subject during the test run.

I strongly recommend you to read this post if you want to get into the details of why Mocking is a code smell (Topics like these: What is a mock? What is a unit test? What is test coverage? What is tight coupling? What causes tight coupling? What does composition have to do with mocking? How do we remove coupling? and more!)

The problem with mocking

When you mock you are overriding the logic of the mocked class. The real logic is getting hidden behind the scenes and there is actually where bugs love to live. Consider that:

The mock may have attributes, methods, or arguments that the real object doesn’t.
The mock’s return values may differ from the real objects’ return values. For example, it may return a different type of object that has different attributes.
The mock’s side effects and behavior may differ from the real objects’ ones. For example, maybe the mock fails to raise an exception when the real object would raise it.

Alternatives to mocking

“Are you saying that mocking is bad and we shouldn’t mock?!” No.

It depends on what you are “overriding”.

Is your business domain logic what you are mocking? Then it’s wrong.
Is the connection to the DB what you are mocking? Then it’s right.

It depends on the context of the logic and where that logic belongs.

Is it part of your business domain logic? Then you shouldn’t mock it but instantiate it.

Is it part of any infrastructure dependency like DB connection, IO file system, Network, or any external service that has nothing to do directly with your business domain? Then mock it using abstractions/interfaces.

The interface should be the contract between your business domain logic and its external infrastructure dependencies. Imagine how easy it would be to unit test your domain logic by instantiating it and calling their methods with different arguments expecting different inputs under your entire control. Here is an example of how to unit test written code.

Some tricks

When you are writing a unit test:

Try to instantiate your classes first.
Avoid mocking concrete classes. I wrote an article exclusively about this exclusively: encouraging final classes and interfaces.

Mock interfaces. Instantiate concrete classes.

https://youtu.be/RbSqXFUfRMU

“Excessive use of mocks leads to legacy code.” — Philippe Boargau

How can we avoid excessive mocking?

Favor immutable state over a mutable state.
Make dependencies explicit.
Program to an interface, not to an implementation.

Originally published in https://chemaclass.es/blog/to-mock-or-not-to-mock/

Sharing your git patches

Jose M Valera Reales — Wed, 02 Dec 2020 07:45:27 +0000

Another way of sharing quick suggestions with your team

Imagine this situation

You are reviewing a Pull Request (PR) and you see some minor improvements or suggestions that you would like to share with the author. You might write some comments, and usually, that would be sufficient.

But imagine that in order to transmit your “whole idea” you would need to change some files because just communicating the full picture will end up in a huge comment which might be not as clear as it could be.

What possibilities are there apart from just comments in a PR?

Well, there are multiple options. The key is to be aware of them and use them wisely depending on the priority of the task and the changes themselves:

As already mentioned, writing a comment as feedback is a good idea by default, but not the only one.
We can always do some pair-thinking, talk at any time. Communication is always good in order to clarify the possible uncertainty.
Sharing your git patches is another good option.

Git diff to the rescue!

What if you (as a reviewer) could share your idea without any single commit or comment in the PR, but sharing your changes directly with the author?

Well, that’s actually possible and really easy. As you already know, the git diff command gives you the differences between any two branches.

git diff origin develop > ../my-origin-develop.patch

What we are doing here is redirecting the output of the diff command into a file (aka: patch), so we can share that output with any other peer-team.

What now?

Well, having that patch file, it’s pretty easy to apply those changes in your local machine without doing any commit:

git apply ../my-origin-develop.patch

Applying this patch will simply change your local system in the same way the patch was created.

“How to” by steps

Let’s divide the responsibilities into two: the creator of the patch and its user:

The patch creator: the person who will create the patch

# Checkout that branch
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Do your suggestions and changes in the targeted branch
# Generate the patch file using the diff command
$ ~/myProject git:(the-branch) ➜ git diff > ../your-diff.patch
# Share the patch file with the author of the PR

The patch user: the person who will see the patch

# Ensure you are in that branch
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Apply the patch file
$ ~/myProject git:(the-branch) ➜ git apply ../your-diff.patch

References

https://git-scm.com/docs/git-apply

Originally published on https://chemaclass.es/blog/sharing-git-patches/

Never use array_merge in a loop

Jose M Valera Reales — Tue, 10 Nov 2020 09:12:51 +0000

The spread operator to the rescue.

Flattening a one-level array

I have seen people using the array_merge function in a loop like:

$lists = [
  [1, 2],
  [3, 4],
  [5, 6],
];
$merged = [];
foreach($lists as $list) {
    $merged = array_merge($merged, $list);
}
// $merged === [1, 2, 3, 4, 5, 6];

This is a very bad practice because it’s a (memory) performance killer!
Instead, you should use the spread operator (in PHP since 5.6!):

$lists = [
  [1, 2],
  [3, 4],
  [5, 6],
];
$merged = array_merge(...$lists);
// === [1, 2, 3, 4, 5, 6];

Unpacking an assoc-array

What if you had an assoc-array instead like this one?

$lists = [
  'key-1' => [1, 2],
  'key-2' => [3, 4],
  'key-3' => [5, 6],
];

In that case, you will need to unpack its values:

$merged = array_merge(...array_values($lists));
// === [1, 2, 3, 4, 5, 6];

In Functional Programming, this is known as flatting a list.
No loops & no more performance problem.

Flatting a multilevel array

What if you wanted to flat a multilevel array like this one?

$lists = [[1], 2, [[3, 4], 5], [[[]]], [[[6]]], 7, 8, []];

Or like this one, even with key-values?

$lists = [
    'key-1' => [
        1,
        [2],
        'key-2' => [
            3,
            [
                'key-3' => [4, 5],
            ],
        ],
    ],
    6,
    'key-4' => [7, 8],
];

In these cases, you might want to use the internal standard library:

$merged = iterator_to_array(
    new RecursiveIteratorIterator(
        new RecursiveArrayIterator($lists)
    ),
    $use_keys = false
);
// $merged === [1, 2, 3, 4, 5, 6, 7, 8];

Conclusion

Usually, being aware of how to flat a “2 level” array might be sufficient:

$flattenList = array_merge(...array_values($lists));

Otherwise, the internal standard library will help you deal with it.

Originally published on https://chemaclass.es/blog/array-merge-in-loop/

Typed arrays in PHP

Jose M Valera Reales — Tue, 13 Oct 2020 08:42:01 +0000

An alternative to the missing feature in PHP: Generics

The perfect combination

Argument unpacking: Instead of passing the argument itself to the function, the elements it contains will be passed (as individual arguments).
Function variable argument list: The arguments will be passed into the given variable as an array.
Variadics function: Types can be checked with a type-hint.

We will use this snipped for our examples
Having a class, Customer:

/** 
 * @psalm-immutable 
 */
final class Customer
{
    // Using PHP 8 constructor property promotion
    public function __construct(
        public string $name,
    ) {}
}
// We create a list of 6 customers
$customers = array_map(
    fn(int $i): Customer => new Customer("name-{$i}"),
    range(1, 6)
);

Whenever we want to manipulate a list of Customers, we can pass as an argument: …$customers.

How we use to do it

We define the array type using the PHPDoc param comment block above. But we cannot define the real type of the item. The code will still run without any problem passing any type on that argument array $customers:

/** 
 * @param Customer[] 
 */
function createInvoiceForCustomers(array $customers): void
{
    foreach ($customers as $customer) {
        // ... some irrelevant logic for this example
    }
}

The code below would work at "compile-time". But it might fail at "runtime".

createInvoiceForCustomers($customers);
createInvoiceForCustomers([new Customer('any name')]);
createInvoiceForCustomers([new AnyOtherType()]);

An alternative (recommended!) might be to extract that logic and ask for the particular type in order to "check it" at runtime in that particular moment, failing if one of the items wasn't really a Customer:

/** 
 * @param Customer[] 
 */
function createInvoiceForCustomers(array $customers): void
{
    foreach ($customers as $customer) {
        createInvoice($customer);
    }
}
function createInvoice(Customer $customer): void
{
    // ... some irrelevant logic for this example
}

Everything here below would work at "compile-time". It will for sure break during "runtime" if the createInvoice(Customer $customer) receives something different than a Customer.

createInvoiceForCustomers($customers);
createInvoiceForCustomers([new Customer('any name')]);
createInvoiceForCustomers([new AnyOtherType()]); // won't work

By doing that createInvoice(Customer $customer) we are ensuring the type of the argument, which is good! But, what about going one step further. Could we check the types of the elements when calling the function createInvoiceForCustomers(array $customers), even making the IDE complain when the types are not right?

Well, that's actually what Generics are for, but sadly, they are not yet in PHP. Not even in the upcoming PHP 8. Hopefully in a near future, but we cannot predict that for now.
Luckily, we have currently an alternative nowadays, but it's not that popular. It has its own "pros" and "cons", so let's take a look at an example first:

function createInvoiceForCustomers(Customer ...$customers): void
{
    foreach ($customers as $customer) {
        createInvoice($customer);
    }
}

Everything here below would work at "compile-time". It will for sure break during "runtime" if the createInvoice() receives something different than a Customer.

createInvoiceForCustomers(...$customers); // OK
createInvoiceForCustomers(
    new Customer('any name'), 
    new Customer('any name'),
); // OK
// This is not even possible to write. The IDE will yeld at you. 
// It's expecting a `Customer`, but `AnyOtherType` is given:
createInvoiceForCustomers(new AnyOtherType());

PROS

We can easily type a list of any concrete type.

CONS

We better define our functions with one or two arguments max. Otherwise, it would be too complicated to read.

Important remarks

It needs to be the last taken argument of a function.
It helps to minimize the number of arguments that we use in a function.

Conclusions

Argument unpacking is a great feature that, in combination with variadic functions, can help us to simulate typed arrays. With great power comes great responsibility, and this is no exception.
We need to learn about our toolbox in order to use it wisely.

References

Originally published on https://chemaclass.es/blog/typed-arrays-php/

Strict Types in PHP

Jose M Valera Reales — Mon, 10 Aug 2020 12:02:25 +0000

In December 2015, PHP 7 introduced scalar type declarations and with it the strict types flag.

To enable the strict mode, a single declare directive must be placed at the top of the file. This means that the strictness of typing for scalars is configured on a per-file basis. This directive not only affects the type declarations of parameters, but also a function’s return type.

The good thing about declaring a PHP file as strict is that it actually applies to ONLY the current file. It ensures that this file has strict types, but it doesn’t apply to any other file in the whole project. It allows you to do, step by step, this migration from non-strict code to strict code, especially for new files or projects.

Strict types affect coercion types

Using hint type without strict_types may lead to subtle bugs.

Without this, int $x meant $x must have a value coercible to an int. Any value that could be coerced to an int would pass the hint type, including:

a proper int (example: 42 -> 42)
a float (example: 13.1459 -> 13)
a bool (example: true -> 1)
a null (example: null -> 0)
a string with leading digits (example: “15 Trees” -> 15)

By setting strict_types=1, you tell the engine that int $x means $x must only be an int proper, no type coercion allowed. You have the great assurance you're getting exactly and only what was given, without any conversion or potential loss.

Who should care about this “strict type” line?

Actually, declare(strict_types=1); is more for the reader than for the writer. Why? Because it will explicitly tell the reader:

The types in this current scope (file/class) are treated strictly.

'strict_types=1' is more for the reader than for the writer

The writer just needs to maintain such strictness while writing the expected behavior. That said, as a writer, you should care about your readers, which also includes your future self. Because you are going to be one of them.

References

Originally published on https://chemaclass.es/blog/strict-types/

The Art of Refactoring

Jose M Valera Reales — Thu, 02 Jul 2020 13:43:08 +0000

TL;DR: If you see something, in the scope of your current task, that can be easily improved, improve it. And if you have any questions about it, ask.

What is refactoring?

Refactoring means improving your code. It can go from making a variable name more readable, extract some lines of code into a private method, or separate the responsibilities of a class into subclasses, for example.

Refactoring is the action of showing that you care about what you do as a professional. It can be a controversial topic; it is indeed one of the major controversial topics since a long time ago. But we shouldn’t stop trying our best in order to improve the quality of the system just because of that controversiality.

When and how should we refactor?

Always in the scope of your current task unless it is an already planned task, something like “architecture refactoring” or similar, where the scope of the task is actually to do refactoring.

Refactoring should be part of our daily job, not a separate task by default.

We do not need to ask permission to refactor. Or do we ask our managers for permission to do our best job?

In order to do proper refactoring, the intention of such refactoring needs to be clear. What is intended to achieve and how? Pair programming (or even pair thinking!) certainly helps in this topic because it syncs two brains on the same topic and that encourages team building and a better understanding of them.

Applying refactor in a collaborative way, in a “bidirectional channel”, is fundamental when working within a team. Refactoring shouldn’t be a tabu topic, on the contrary: it will be helpful in order to unify the goals and the direction of the team code quality.

Some personal advice about the “how”

Continuous improvement is what we’re looking for within this topic, but…

If you realize your changes are generating more noise than help, stop immediately and think again if your changes are worth in the current system status.

Maybe it’s not the right moment for that refactoring.

Maybe you are polluting your current diff with out-scoped changes.

Or, maybe, your refactoring idea is too big to be applied in your current task. In such a case, a follow-up task (in order to apply the refactoring) would be a better idea.

If you see that refactoring is perhaps needed even before starting your current task, do the refactoring first.

We usually refactor in order to increase our productivity, making the code more readable and therefore easier to understand.

Testing

Be aware that you should have a pretty well suite of tests covering the logic that you might have changed. Without tests, refactoring can be really risky. Usually, the easier something is to be tested, the easier it is to be replaced or removed.

You can read more about how testing is related to quality here.

Why should we do it?

Wouldn’t you want to have a better system as time goes by?

Software isn’t like wine: it doesn’t get better as time passes by. Therefore, if you want to have a better system you must work for it.

Originally published on https://chemaclass.es/blog/art-refactoring/

Final classes in PHP|Java|Any

Jose M Valera Reales — Thu, 02 Jul 2020 13:34:18 +0000

TL;DR: Benefits of final classes: clear contracts, isolated side effects, testability, low complexity and cognitive load, code fluidity, and confidence in yourself.

Motivation

Reduce the scope visibility to the minimum

When you see a class prefix with final you will prevent a particular class to be extended by any other, which not only makes it more readable but also makes you be sure that the scope of the logic where you are is limited to that particular class.

Encourage “composition over inheritance” mentality

The Open-Close Principle states: open for extension but close for modification.

If for any reason, a good one you should be completely aware of, you decide to create an inheritance there, well, then just drop the final keyword and you are good to go.

When you “by default” can’t extends from a class (because it’s final), you will help yourself by thinking about using composition instead of inheritance.

Why isn’t this class final?

If we aim for composition over inheritance, then we should try to avoid inheritance as much as possible, and use it only when it’s really necessary. Inheritance is often misused in OOP.

Misconception

When we first taught OOP, we usually introduced the classic inheritance example.

Nonetheless, when Alan Kay created Smalltalk, the inheritance was never the main concept of it. The main concept was messaging, which is that you can send messages to objects and they encapsulate the data and logic in it, and you can change their behavior by using different objects, which is actually composition. But the concept of inheritance is too popular that eventually overshadows composition.

Benefits

Clear contracts. Using interfaces will force you to think in terms of communication between objects.
Isolated, side effect free code units. Injecting interfaces only as dependencies will remove every nasty side effect around the code you are working on.
Testability. Mocking dependencies is extremely easy when they are interfaces.
Low, manageable complexity. Since everything is isolated, you won’t need to worry about rippling changes. This dramatically decreases the complexity of your code.
Low cognitive load. With decreased complexity, your brain will be free to focus on what matters.
Code fluidity. By removing any unnecessary coupling, you will be able to move things around way more easily than before.
Confidence in yourself. Being able to test your code in isolation so well will give you a wonderful sense of confidence in changing it.

Composition over inheritance

If you feel the need to reconfigure an object, to change parts of an algorithm, or to rewrite part of the implementation, consider creating a new class instead of overriding an existing class.
If you need to represent a hierarchy of classes, where subclasses are proper substitutes for their parent classes. This would be the classic situation where you may still consider inheritance. However, the result may even be better if you don’t inherit from concrete parent classes but from abstract interfaces.

What you should start doing instead

Use interfaces to define the contracts between your classes.
Use final classes to implement behavior for those interfaces.
Use composition (through constructor dependency injection) to put things together and prevent complexity.

Interfaces -> Final classes -> Composition

Originally published on https://chemaclass.es/blog/final-classes/