Using test doubles to replace dependencies in tests has become a standard practice.

Generally, there are three main types of components that should be substituted with test doubles during testing:

What is NODE_ENV?

The NODE_ENV environment variable became popular early in Node.js development as a convention to distinguish between runtime environments like development, testing, and production. It is now widely used and supported across many tools and frameworks in the Node.js ecosystem, allowing developers to implement environment-specific configurations and optimizations.

Unfortunatley, many developers don’t grasp its purpose and use it incorrectly.

An interesting question from Stack Overflow asks “Why is MySQL’s maximum time limit 838:59:59?”

The official reference at https://dev.mysql.com/doc/refman/5.7/en/time.html says

TIME values may range from -838:59:59 to 838:59:59. The hours part may be so large because the TIME type can be used not only to represent a time of day (which must be less than 24 hours), but also elapsed time or a time interval between two events (which may be much greater than 24 hours, or even negative).

The TIME values were always stored on 3 bytes in MySQL. But the format changed on version 5.6.4.

A question that occurs frequently on the Q&A programming sites looks like this:

I want Git to ignore one of the files in the project. I added the file name and/or the file path to .gitignore and/or .git/info/exclude but git status still shows the file as being modified.
It seems Git doesn’t ignore the file, it ignores me. I’m desperate, please help!

Is it quite so? Does Git ignore you?

Resolving the conflicts in composer.json can be done in the usual way: use a diff tool and pull into the merged file the correct changes from both sides. Save the merged file, add it to the index and you’re good to go.

Regarding a VCS conflict, composer.lock behaves more like a binary file.

Encapsulation is one fundamental concept of object-oriented programming. It refers to the bundling of data with the methods that operate on that data. Encapsulation is used to hide the values or state of a structured data object inside a class, preventing unauthorized parties’ direct access to them.

That’s it, the object properties (and some of its methods) should be private (or, sometimes, protected) and not public.

This article explains how I made Sismo work with Atlassian SourceTree on macOS. First I thought it doesn’t work out-of-the-box because of a $PATH problem but soon it turned out that the biggest issue comes from the command line used for integration. Keep reading to learn how I found it out and how easy is to fix it.

or why 2+2 is not always 4

WITH ROLLUP is a GROUP BY modifier that causes extra rows to be added to the result set produced by the query. These rows represent higher-level (or super-aggregate) summary operations.

A shallow examination of the effects of WITH ROLLUP on a query like:

SELECT user_id, COUNT(product) AS nb_products, SUM(amount) AS total FROM cart GROUP BY user_id

can lead to the erroneous conclusion that the WITH ROLLUP modifier is just a courtesy of the database implementors to the front-end developers and the extra rows added by it could be computed on the client-side as well. Big mistake!

The DateTime class and its friends introduced in PHP 5.2 are a very nice replacement for the old date & time processing functions (date(), getdate(), strftime(), strtotime() and so on).

But they come with a minor glitch that is hidden in the plain sight: they are objects and as all the other objects in PHP, they are assigned and passed as parameters by reference^[1] and not as copies.

Most of the time I think of a DateTime as a Value Object, passing it from here to there without special precautions. And most of the times this works just fine as long as the code doesn’t try to change it.

Several years ago I started a project that was stored in a Subversion repository. After some time, the current (at that time) version of the code was used to create a new Git repository and the development continued. Several months and hundreds of commits later, I decided to gather the code from both repositories into a single repository and keep all the historical data intact.

The goal was to get all the code since the project started until the most recent version into a single Git repository as we have used Git from the project beginning.

I’ll explain below how to accomplish this goal.