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:
The Sentimental…
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
[] == ![] // -> trueor
NaN === NaN // -> false
Math.max()>Math.min() // -> falseor even
[] == '' // -> true [] == 0 // ->…
As you know, React is one of the most popular JavaScript libraries to create Web user interfaces. Its success is due to several factors, but maybe one of them is the clean and effective approach to programming.
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…
At the beginning of 2000, Douglas Crockford claimed that JavaScript was the World’s most misunderstood programming language. The reason for this misunderstanding was mainly due to bad naming, design errors, non strict standard, etc. So, misunderstanding was almost natural.
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.
This misunderstanding is going around for too long. But unlike JavaScript, the REST guidelines are clear enough. …
I know, this topic has been discussed so many times, too many times. However it is always a current topic. Every time a Java or C# or any other OOP language developer get in touch with JavaScript, he complains of it. He says that working with it is a mess, that it has no types, it is not well-structured, it has several oddities, its object support is trivial and definitively it is not an OOP language.
Some of these complaints may be acceptable, but some others are prejudices, such as the claim that JavaScript has no types and that it…
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.
Nowadays almost nobody uses anymore the goto statement when writing programs with high-level languages, although this statement is still provided by languages such as C/C++, C#, PHP.
It is more than one year and half since the class construct has become part of the official JavaScript syntax. Introduced by the ECMAScript 2015 specifications, this construct has been enthusiastically welcomed by many developers. Indeed, it has been considered a sign of the formalization of various attempts to simulate classes, inheritance and other Object-Oriented features offered for several years by many libraries, such as Prototype, ExtJS, Dojo, Backbone, Ember and others. TypeScript itself was born with the aim of bringing the class-based Object-Oriented programming in JavaScript language. However the class construct may lead to serious misconceptions about the Object-Oriented…
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) =>
i.title?i.title.includes(st):false||
i.keywords?i.keywords.includes(st):false);The JavaScript code is perfectly working. It does its job properly. But exactly what is its job?
Considering the code as documentation may be a nice idea, but it remains just an idea if we do not strive…
