Passwords are the most common way to protect our digital resources. They are not perfect but have been here for so long that they are now part of our daily life. While they should follow some well-known guidelines to ensure actual protection, many of us tend to choose passwords not on a robustness basis but on their familiarity, that is, their ease in memorizing.
I didn’t extensive studies, but in my limited experience, I realized that the criteria the users follow to create their passwords are always the same. These criteria are roughly related to some… psychological types:
So, you’ve heard about functional programming. And you’ve heard that it a good and right thing. But you’re afraid to learn new programming languages and all that new weird stuff with strange names.
Be aware that functional programming is not a programming language. It’s a programming paradigm, a programming mindset. It is based on one fundamental principle:
A program is a mathematical function.
I hope you already know what a mathematical function is:
A binary relation over two sets that associates every element of the first set with exactly one element of the second set.
Once you’ve understood how functions…
My fellow members! Ladies and gentlemen of the court!
My client has too often unfairly been an object of ridicule and public derision. Too many times developers, especially the developers of other languages, have made fun of him and laughed at him. They insist on considering it, so to speak, weird, bizarre, geeky.
Most of the reasons for these attacks on my client are based on alleged oddities such as
 == ! // -> true
NaN === NaN // -> false
Math.max()>Math.min() // -> false
 == '' // -> true  == 0 // ->…
In the React environment, every piece of a UI is a component. Components can be composed together to create other components. The application itself is a component: a composition of components. The developer approaching React is naturally led to think of it in terms of Object-Oriented Programming. The syntax itself to define a component promotes this idea:
However, under the Object-Oriented dress…
Last year I tweeted something similar about the REST architectural paradigm.
In fact, most people believe that to build a RESTful API you can simply create an API based on URLs and HTTP verbs. This is absolutely false.
Suppose you are so good at writing self explanatory code: easy to read and to understand. Congratulations! This is not so common. If you’ve been able to achieve this result, you can afford to say anyone asking you info about your software: read the code!
Well, maybe that’s not right. Although your code is written in an exemplary way, it does not mean that everyone will be able to use it on the fly. Briefly consider who will somehow interact with your code. Apart from end users (you can not absolutely claim that they read your code), there are other…
In the late sixties, Edsger Dijkstra wrote an article about the use of the goto statement, highlighting how it encouraged the spread of a unstructured code style often hard to understand: the so called spaghetti code. The proposed measure was the removal of the goto statement from all high-level programming languages in favour of the use of structured control flow constructs like if/else, while, repeat, etc.
We all agree. Documenting code is a waste of time and a considerable cost. It is much better to refer directly to the code if you want to understand how an program works internally.
Of course the intention is good, but what if we run into a snippet of code like this?
const f = (st, p) => p.filter((i) =>
Considering the code as documentation may be a nice idea, but it remains just an idea if we do not strive…