Jesus Valera Reales

Anemic vs Rich Domain Model

2026-04-09T00:00:00+00:00

When designing object-oriented applications, one of the first decisions is how to structure your domain models. Two contrasting approaches exist: the Anemic Domain Model and the Rich Domain Model.

Anemic Domain Model</h2>
An anemic domain model is a model where objects contain only data (properties) with no behavior. Business logic lives in service classes that manipulate these data objects from the outside.
final class User { private string $email; private string $password; private bool $active; public function getEmail(): string { return $this->email; } public function setEmail(string $email): void { $this->email = $email; } public function getPassword(): string { return $this->password; } public function setPassword(string $password): void { $this->password = $password; } public function isActive(): bool { return $this->active; } public function setActive(bool $active): void { $this->active = $active; } }</code></pre> The User</code> class is a bag of getters and setters. It doesn't know what a valid email looks like, how passwords should be stored, or what "registering" means. All of that lives somewhere else: final class UserService { public function register(User $user, string $email, string $password): void { if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { throw new InvalidArgumentException('Invalid email'); } $user->setEmail($email); $user->setPassword(password_hash($password, PASSWORD_DEFAULT)); $user->setActive(true); } public function deactivate(User $user): void { $user->setActive(false); } }</code></pre> Nothing prevents other code from calling $user->setEmail('not-an-email')</code> directly, bypassing validation entirely. The model can't protect its own invariants. Rich Domain Model</h2> A rich domain model places business logic inside the domain objects themselves. The object encapsulates both data and the operations that can be performed on it. final readonly class Email { public function __construct( public string $value, ) { if (!filter_var($value, FILTER_VALIDATE_EMAIL)) { throw new InvalidArgumentException('Invalid email'); } } }</code></pre>final class User { private function __construct( private readonly Email $email, private readonly string $hashedPassword, private bool $active, ) { } public static function register(string $email, string $password): self { if (strlen($password) < 8) { throw new InvalidArgumentException('Password must be at least 8 characters'); } return new self( new Email($email), password_hash($password, PASSWORD_DEFAULT), true, ); } public function deactivate(): self { $copy = clone $this; $copy->active = false; return $copy; } public function isActive(): bool { return $this->active; } public function email(): string { return $this->email->value; } public function verifyPassword(string $password): bool { return password_verify($password, $this->hashedPassword); } }</code></pre> There is no way to create a User</code> without going through register()</code>, which enforces the rules. The Email</code> value object rejects invalid values at construction time. deactivate()</code> returns a new copy instead of mutating state. The model protects itself. The antipattern debate</h2> Martin Fowler called the anemic domain model an "antipattern</a>" because it goes against a fundamental principle of OOP: combining data and behavior. If your objects are just data bags and your services do all the work, you're writing procedural code with extra steps. Anemic models can be practical for simple CRUD applications where there's barely any business logic to encapsulate. A form that saves rows to a database doesn't need a rich domain. But the moment you have rules like "a user can't be deactivated twice", "an email must be unique", or "a discount can't exceed 50%", those rules belong in the model. Otherwise, they end up scattered across services, duplicated, and eventually contradicting each other. For most applications with non-trivial logic, a rich domain model leads to code that is easier to test, harder to misuse, and simpler to reason about.

Link Local Packages using Composer 2026-01-19T00:00:00+00:00 When you're developing a PHP package or library, you often need to test it within another project before publishing it to Packagist. Instead of constantly publishing new versions or using complicated workarounds, Composer provides a clean solution: path repositories. What are Path Repositories?</h2> Path repositories allow you to use a local directory as a source for a Composer package. When configured, Composer creates a symlink from your vendor</code> directory to the local package, meaning any changes you make are immediately reflected in your project. This is particularly useful when: You're developing a library and want to test it in a real application</li> You need to make changes to a vendor package and test them immediately</li> You're working on multiple interdependent packages simultaneously</li> You want to contribute to an open-source package and test your changes</li> </ul> Basic Configuration</h2> Let's say you have the following directory structure: workspace/ ├── my-project/ │ └── composer.json └── my-local-package/ └── composer.json</code></pre> To link my-local-package</code> to your project, add a repositories</code> section to your composer.json</code> file: { "repositories": [ { "type": "path", "url": "../my-local-package" } ], "require": { "vendor/my-local-package": "dev-main" } }</code></pre> The url</code> points to the root directory of your local package (where its composer.json</code> is located). You can use either absolute paths or relative paths from your project root. Take into account that the package name in the require</code> section must match the directory name in your path. In the example above, my-local-package</code> appears in both url: "../my-local-package"</code> and require: "vendor/my-local-package"</code>. Composer uses this to link the correct local directory to your project. Version Constraints</h2> When working with local packages, you can use different version constraints in your require</code> section. Using *</code> tells Composer to accept any version from the local path, which is convenient during development: { "require": { "vendor/package": "*" } }</code></pre> Alternatively, you can be more specific and require a particular branch: { "require": { "vendor/package": "dev-main" } }</code></pre> This requires the main</code> branch of your local package. Multiple Local Packages</h2> You can configure multiple path repositories at once: { "repositories": [ { "type": "path", "url": "../package-one" }, { "type": "path", "url": "../package-two" }, { "type": "path", "url": "/absolute/path/to/package-three" } ], "require": { "vendor/package-one": "*", "vendor/package-two": "*", "vendor/package-three": "*" } }</code></pre>Installing the Package</h2> Once you've configured your composer.json</code>, install the package: composer install</code></pre> Or if the package is already required but you're adding the path repository: composer update vendor/package-name</code></pre> You should see output indicating Composer is symlinking from the local path: - Installing vendor/package-name (dev-main): Symlinking from ../my-local-package</code></pre>Removing Path Repositories for Production</h2> Path repositories are intended for local development. Before deploying or sharing your code, you should: Remove the repositories</code> section from composer.json</code></li> Update the version constraint to a proper semantic version</li> Run composer update</code> to pull from Packagist instead</li> </ol> </div> References</h2> Composer Repositories | Composer</a></li> Loading a package from a VCS repository | Composer</a></li> </ul> Avoid using array_merge within a loop 2025-07-04T00:00:00+00:00 If you're a PHP developer, chances are you've encountered (or written) code like this: $userLists = []; foreach ($this->someCall() as $someObject) { $userLists = array_merge($userLists, $someObject->getUsers()); }</code></pre> The goal here is to populate the $userLists</code> array with users returned from some external source (in this case, from $someObject->getUsers()</code>). An instinct is to use array_merge</code> inside the loop to combine arrays. While this works, there's a performance caveat: array_merge</code> creates a new array every time it's called, duplicating all elements and discarding the previous one. This approach may be fine for small arrays, but the cost grows significantly with larger datasets. Alternatives for better performance</h2> Spread operator (merge once at the end)</h3> Instead of merging in every iteration, we collect all elements and merge them only once at the end. $userLists = []; foreach ($this->someCall() as $someObject) { $userLists[] = $someObject->getUsers(); } $userLists = array_merge(...$userLists);</code></pre>Pros and cons:</h4> Requires PHP 7.4+ (spread operator for arrays)</li> If any $someObject->getUsers()</code> returns an empty array, PHP emits a warning (you'll need to check or provide a default value)</li> Holds all intermediate arrays in memory before merging</li> Clean and modern syntax</li> Performs only one merge operation - faster than repeated array_merge() in a loop</li> </ul> Manual nested loop</h3> This method avoids all intermediate arrays and merges on the fly. $userLists = []; foreach ($this->someCall() as $someObject) { foreach ($someObject->getUsers() as $user) { $userLists[] = $user; } }</code></pre>Pros and cons:</h4> Works on all PHP versions</li> No risk of warning if $someObject->getUsers()</code> returns an empty array (the inner loop is not executed)</li> Best memory performance for large datasets</li> Slightly more verbose</li> </ul> Jobs (Queues) vs. Events 2025-04-18T00:00:00+00:00 When a heavy task needs to run outside the main request-response flow, or multiple actions need to occur when something happens, you have two main options: jobs and events. They serve different purposes. Jobs</h2> A job is a task that runs in the background, either on a schedule or triggered outside the main request-response cycle. Jobs handle resource-intensive, time-consuming, or non-urgent processes. Use cases: Scheduled tasks (cron jobs)</li> Processing that doesn't need to run immediately</li> Large file operations (PDFs, images)</li> Syncing with third-party services</li> </ul> Example: A system that generates and emails financial reports every night at midnight. No user action triggers it - it runs on schedule. Events</h2> An event is a signal that something has happened in your application. Events can be triggered by users or by the system. An event doesn't do anything by itself - one or more listeners react to it. Events decouple your logic. Instead of hardcoding all actions inside one method, you fire an event and let other parts of the system respond independently. Use cases: Broadcasting when a specific action occurs (like UserRegistered</code>)</li> Triggering multiple follow-up actions</li> Separating concerns between modules</li> </ul> Example: When a user registers, a UserRegistered</code> event fires. Different listeners can send a welcome email, create an audit log, and notify an admin - all independently. </div> You can combine both patterns. An event fires when a user performs an action, and one of the listeners queues a job to run in the background, like sending a welcome email asynchronously. Jobs are like an alarm clock that rings at the same time every day, whether you're awake or not. Events are like a doorbell - they ring when pressed, and everyone inside hears it. When to use each</h2> Use a job when you need to: Perform heavy or background tasks</li> Execute one-off tasks with no notification requirement</li> Retry failed operations</li> Run scheduled processes</li> </ul> Use an event when you need to: Trigger multiple reactions from one action</li> Broadcast that something happened</li> Decouple business logic across modules</li> </ul> Git: Reset last commit 2025-03-25T00:00:00+00:00 When working with Git, it is possible that you committed some code by mistake. You can use git revert</code> or git reset</code> commands to have a cleaner Git history. Git revert</h2> If you want to undo a commit without losing the history but creating a new commit undoing what you did, consider using git revert</code>: git revert HEAD</code></pre> This command is a safer option in shared repositories. Git reset</h2> The git reset</code> command moves the HEAD</code> pointer to a previous point, removing intermediate commits. Git reset soft</h3> After running this command, the changes from the last commit will still be staged. git reset --soft HEAD~1</code></pre> Use cases: You made a commit but realized you need to modify something before finalizing it</li> You want to combine multiple commits into one before pushing</li> </ul> Git reset hard</h3> After running this command, the changes from the last commit will be removed. git reset --hard HEAD~1</code></pre> Use cases: You want to remove some commits and return to a clean state completely</li> You accidentally committed something and need to reset without keeping any modifications</li> </ul> Git push origin</h4> What if you pushed some commits into a remote branch and needed to push your latest changes regardless? In that case, you can force the push using the flag -f</code>. This command will override the history, which means the previous commits will be removed. git push origin {branch} -f</code></pre></div> Conclusion</h2> Use --soft</code> when you need to adjust your commits without losing changes and --hard</code> when you need a complete reset. Always double-check before using --hard</code> to avoid unintended data loss! If you have doubts, or you are working in a branch with other people, it is preferable to use git revert</code> instead. New PHP 8.4 array functions 2024-11-29T00:00:00+00:00 The PHP 8.4 version includes four new array functions that will help to write more clear and concise code. Here are the current PHP array_*</code> methods and a small example about how to deal with each of them (similarly as I did in this JavaScript post</a>). Imperative vs Declarative</h2> There are two ways of applying transformations to arrays in PHP. While in imperative way we tell step by step how to get,</li> in the declarative we tell not how to do it, but what we want</li> </ul> Example: Having a list of numbers from 1 to 10, to filter odd numbers, we can do: $numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]; ## Imperative $result = []; foreach ($numbers as $n) { if ($n % 2 === 1) { $result[] = $n; } } ## Declarative $result = array_filter($numbers, fn (int $n) => $n % 2 === 1);</code></pre> In the declarative way, we did not create any explicit loop or added any if</code> statement, it was all done automatically under-the-hood, we just defined which condition should be applied to each element of the list. There is no a better way, both imperative and declarative codes do the same, in some situations one way could fit better than the other, although, usually the declarative is shorter and cleaner. Declarative functions</h2> Before PHP 8.4, we have numerous PHP functions, eg: array_map(?callable $callback, array $array, array ...$arrays): array</code> array_walk(array|object &$array, callable $callback, mixed $arg = null): true</code> array_filter(array $array, ?callable $callback = null, int $mode = 0): array</code> array_reduce(array $array, callable $callback, mixed $initial = null): mixed</code> array_key_exists(string|int|float|bool|resource|null $key, array $array): bool</code> in_array(mixed $needle, array $haystack, bool $strict = false): bool</code> Since PHP 8.4 we have the new following methods: array_find(array $array, callable $callback): mixed</code> array_find_key(array|object &$array, callable $callback, mixed $arg = null): true</code> array_all(array $array, ?callable $callback = null, int $mode = 0): array</code> array_any(array $array, callable $callback, mixed $initial = null): mixed</code> The new four methods were discussed in this RFC</abbr></a>. New functions</h2> array_find 🔎</h3> array_find()</code> is useful to get the value of the first occurrence of a certain element in an array. It will return NULL otherwise. $countries = ['Spain', 'Germany', 'Portugal', 'France']; $find = array_find($countries, fn(string $c) => str_contains($c, 'an')); var_dump($find); *** OUTPUT *** string(7) "Germany"</code></pre>array_find_key 🔑</h3> array_find_key()</code> is useful to get the key of the first occurrence of a certain element in an array. It will return NULL otherwise. $countries = ['Spain', 'Germany', 'Portugal', 'France']; $findKey = array_find_key($countries, fn(string $c) => str_contains($c, 'an')); var_dump($findKey); *** OUTPUT *** int(1)</code></pre>array_all ☘️</h3> array_all()</code> is useful to know if all elements from an array meet a specific closure. This method will return true or false. $countries = ['Spain', 'Germany', 'Portugal', 'France']; $allA = array_all($countries, fn(string $c) => str_contains($c, 'a')); $allE = array_all($countries, fn(string $c) => str_contains($c, 'e')); var_dump($allA); var_dump($allE); *** OUTPUT *** bool(true) bool(false)</code></pre>array_any 🧵</h3> array_any()</code> is useful to know if any element from an array meet a specific closure. This method will return true or false. $countries = ['Spain', 'Germany', 'Portugal', 'France']; $anyA = array_any($countries, fn(string $c) => str_contains($c, 'a')); $anyE = array_any($countries, fn(string $c) => str_contains($c, 'e')); var_dump($anyA); var_dump($anyE); *** OUTPUT *** bool(true) bool(true)</code></pre> Git Rebase onto 2024-07-01T00:00:00+00:00 When you are working with Git, you may find yourself in a situation where you need to rebase your branch onto another branch. This can happen when you want to incorporate changes from one branch into another, but you want to keep the commit history clean and linear. What is git rebase --onto</code>?</h2> The git rebase --onto</code> is a powerful command when you need more control over the rebase process. It allows you to specify a different branch or commit to rebase your changes onto, which is not necessarily the upstream branch of the current branch. The command takes three arguments: The new base commit</li> The exclusive starting commit of the range to rebase</li> The inclusive ending commit of the range to rebase</li> </ol> Syntax</h3> git rebase --onto <new-base> <upstream> <branch></code></pre>Rebasing a Subset of Commits</h2> When you want to rebase a subset of commits from your branch onto another branch: A---B---C (feature) / ---X---Y---Z (master)</code></pre> If you want to rebase A</code> into Z</code>, you can use the following command: (feature)$ git rebase --onto master Z -- also works -- (feature)$ git rebase --onto master master feature</code></pre> This command will rebase the commits from feature</code> branch onto the master</code> branch, starting from commit Z</code>. A'---B'---C' (feature) / ---X---Y---Z (master)</code></pre>Skipping Commits</h2> When you want to skip a set of commits from your current branch: A---B---C---D (feature) / ---X---Y---Z (master)</code></pre> If you want to skip A</code> and B</code> (start from C</code> commit), and rebase the rest onto Z</code>, you can use the following command: (feature)$ git rebase --onto master B feature # exclusive selection - we pick B, not C</code></pre> This skips commits A</code> and B</code> and applies the remaining commits onto the master</code> branch. C'---D' (feature) / ---X---Y---Z (master)</code></pre>Rebasing to a different base</h2> When you want to rebase a branch onto a completely different base that is not its current base. A---B---C (feature1) / ---X---Y---Z (master) \ D---E (feature2)</code></pre> If you want to rebase feature2</code> onto feature1</code>: (feature1)$ git rebase --onto feature1 master feature2</code></pre> This command will rebase feature2</code> onto feature1</code>. A---B---C---D'---E' (feature1) / ---X---Y---Z (master)</code></pre></div> References</h2> Git Rebase | Git</a></li> Git rebase --onto an overview | Woman on Rails</a></li> </ul> The testing pyramid 2024-04-09T00:00:00+00:00 The Testing Pyramid (also known as Cohn Pyramid) visualizes the ideal distribution of different types of tests. It has three layers: Unit at the base, Integration in the middle, and E2E tests on top. The pyramid shape matters. As you move up, tests become slower, more expensive, and more brittle. But they also provide more confidence that the system works as a whole. The key is balancing speed and cost at the bottom with confidence at the top. Unit Tests (50-60%)</h2> Unit tests are small, focused tests that validate individual components in isolation. They're fast to run and cheap to maintain. They verify that each function, method, or class behaves correctly under different conditions. Because they run in milliseconds, you can run them constantly during development. public function test_calculate_discount(): void { $calculator = new PriceCalculator(); $result = $calculator->calculateDiscount(100, 20); self::assertSame(80, $result); }</code></pre> Unit tests should form the foundation of your test suite. They're the fastest feedback loop - run them on every save. They also force better design by making you write testable code with clear dependencies. The majority of your edge cases, error handling, and boundary conditions should be covered at this level. Testing a division by zero? Unit test. Testing negative numbers? Unit test. Don't push these scenarios up to slower test layers. Integration Tests (20-40%)</h2> Integration tests verify interactions between different components or modules. They're broader than unit tests and may involve multiple layers of the application, such as database interactions or API endpoints. These tests catch integration issues - problems that appear when components that work individually fail when combined. public function test_create_order_persists_to_database(): void { $orderService = new OrderService($this->database); $order = $orderService->createOrder($items, $userId); $persisted = $this->database->findOrder($order->id); self::assertEquals($order->total, $persisted->total); }</code></pre> Integration tests are slower because they involve real dependencies - databases, file systems, external services. They catch issues like incorrect SQL queries, serialization problems, or misconfigured connections. Don't test every possible scenario at this level. Test the happy path, major error cases, and critical workflows. Leave the edge cases to unit tests. E2E Tests (0-10%)</h2> End-to-end tests interact with the application as a user would, typically using tools like Selenium or Cypress. They're the slowest and most brittle tests, but they validate complete user flows from start to finish. test('user can complete checkout', async ({ page }) => { await page.goto('/products'); await page.click('text=Add to Cart'); await page.click('text=Checkout'); await page.fill('#card-number', '4242424242424242'); await page.click('text=Pay'); await expect(page.locator('text=Order confirmed')).toBeVisible(); });</code></pre> E2E tests are expensive to write and maintain. They break when CSS classes change, when animations slow down rendering, or when network latency increases. A single E2E test can take 10-30 seconds to run, compared to milliseconds for unit tests. Use them only for critical user journeys. Authentication flow? Yes. Checkout process? Yes. Every possible form validation error? No - test those at the unit level. The Anti-Pattern: Inverted Pyramid</h2> Some teams end up with an inverted pyramid - mostly E2E tests, few unit tests. This happens when developers skip unit testing and rely on E2E tests to catch everything. The result of that are slow test suites that take 30+ minutes to run, frequent false positives from flaky tests, and difficulties with debugging because failures don't point to specific components. If your test suite takes more than a few minutes to run, you probably have too many integration or E2E tests. </div> These percentages vary depending on your project. Legacy codebases coupled with third-party libraries often make unit tests difficult to write. For legacy projects, invert the pyramid temporarily. Start with Integration or E2E tests to prevent breaking existing functionality. Once you have this safety net, refactor the code and add unit tests. The broader tests give you confidence to make changes, while also teaching you how the system works. Eventually, migrate toward the proper pyramid. As you refactor and decouple the code, add unit tests and remove the broader tests that become redundant. The goal is still a fast, maintainable test suite dominated by unit tests. Three dots in PHP 2024-02-09T00:00:00+00:00 The three dots have three different meanings in PHP. First-class callable syntax</li> Variadic function</li> Argument unpacking</li> </ol> First-class Callable Syntax [since PHP 8.1]</h2> This syntax is used to create Closure</code> objects (anonymous function) from callable</code> (any expression that can be called in the PHP grammar). That means, you could store a function or method in a variable and pass it around as a parameter. $snakeCase = static fn($s): string => strtolower(preg_replace('/\B([A-Z])/', '_$1', $s)); $upperCase = strtoupper(...); function helloWorldFrom(Closure $closure): void { echo $closure('HelloWorld'); } helloWorldFrom($snakeCase); // => hello_world helloWorldFrom($upperCase); // => HELLOWORLD</code></pre> In the previous snippet, both $snakeCase</code> and $upperCase</code> are Closure</code> objects. An anonymous function is always a Closure</code> object, while the PHP native functions like strtoupper</code> are callable</code> expressions, which are transformed into a Closure</code> object using the ...</code> operator. We can use the ...</code> operator to create a Closure</code> object not only from functions but also from static/non-static methods from class instances. </blockquote> Variadic function</h2> A variadic function doesn't have a fixed arity, that means, it can take an indeterminate number of arguments; in the end, the parameter will behave like an array. The variadic argument MUST be at the end of the parameter list. function foo(string $string, int ...$numbers): void { echo sprintf('%s [%s]', $string, implode(', ', $numbers)); } foo('Foo'); // => Foo [] foo('Foo', 1); // => Foo [1] foo('Foo', 1, 2); // => Foo [1, 2] foo('Foo', 1, 2, 3, 4, 5); // => Foo [1, 2, 3, 4, 5]</code></pre> It is also possible to explicitly the type of all parameters that the variadic function expects to receive. In case some argument doesn't match with the type that was defined in the function signature, it won't work. Argument unpacking via ...</h2> Arrays and traversable objects can be unpacked into argument lists when calling functions by using the ...</code> operator. This is also known as the splat operator</code> in other languages. function add(int $a, int $b, int $c): void { echo $a + $b + $c; } $numbers = [2, 3]; add(1, ...$numbers); // => 6</code></pre></div> While variadic function</code> and argument unpacking</code> both work like a kind of array, the functionality of each one is practically the opposite. While the variadic function allows to receive multiple values and inside of it, it behaves like an array; the argument unpacking is about transforming an array into multiple variables. The following snippet is a valid PHP code. echo (fn(int ...$n) => array_sum($n))(...)(...[1, 2, 3]); // => 6</code></pre> The same code but a bit more readable. function add(int ...$n): void { echo array_sum($n); } $numbers = [1, 2, 3]; $f = add(...); $f(...$numbers); // => 6</code></pre> The three dots in PHP let you work with functions and methods in a more flexible way. PhpStorm tricks ✨ 2023-11-27T00:00:00+00:00 PhpStorm is a powerful IDE that helps to boost your development. Here are some tricks to get more out of PhpStorm! ⚡️ Plugins</h2> Plugins extend what the IDE can do. If you are a Symfony user, probably you use plugins like Symfony Support</a> and Twig</a>. In the other hand, if you are a Laravel one, I bet you use Laravel Idea</a> and Blade</a>. However, I recommend you GitToolBox</a> or String Manipulation</a> in case you never tried them. Another recommendation, in case you want to familiarize with the IDE shortcuts is Key Promoter X</a>. Although, my favorite so far, which is also not very well-known is PHP Inspections (EA Extended)</a>. This plugin helps you with architecture related issues, regular expressions, non-optimal, duplicated and suspicious "if" conditions, performance issues beyond others. You can check the full list of features on their GitHub</a> page, this one is a MUST. </div> Code Style</h2> PHP is a programming language where everybody can write the code as they wish, in order to unify the industry, PSRs was born. That is the reason we can find standards for Loggering</code> (PSR-3</a>), Event Dispatcher</code> (PSR-14</a>), and even for the Clock</code> (PSR-20</a>). You can check the full list of all available PSRs here</a>. One of the most popular PSRs is concerning the Code Style</code>, that is, it defines things like: Should I use tabs or spaces?</li> Where should I place the brackets in a method? And in a conditional/loop?</li> Are the parenthesis required when instantiating a class with empty constructor?</li> </ul> During the last years, due to the big and fast changes the language experienced, PSR-2 was quickly replaced by PSR-12. However, the language continues evolving very fast, and to avoid creating a new PSR each year, a new standard called PER was introduced. To define PER standard by default, go to the following path and select PER-CS. Settings ➔ Editor ➔ Code Style ➔ PHP ➔ "Set from..." ➔ PER-CS </blockquote> </div> Live Templates</h2> Live Templates are snippets of code that are very used, and you can write them in a few characters. PhpStorm brings some live templates, for example, if we type prif</code>, the generated code will be: private function ░() { }</code></pre> There is a live template for all function combinations: prif</code>, prisf</code>, prof</code>, prosf</code>, pubf</code> & pubsf</code>. It is possible to enhance the auto-completion with a default : void</code> return type as follows. Go to Editor ➔ Live Templates</code> and adjust each template with the $RETURN_TYPE$</code> variable. private function $NAME$($PARAMETERS$): $RETURN_TYPE$ { $END$ }</code></pre> Finally, press on Edit variables and insert "void"</code> (with quotes) on RETURN_TYPE field. </div> File and Code Templates</h2> The scaffolding you get when you create a new file in PhpStorm is also editable. If you are into strict_types</code> and final</code> classes by default, you are in luck! 🎉 To change this, go to Editor ➔ File and Code Templates</code> and update all PHP</code> templates. You can copy-paste the following code snippets into its own category (notice the spaces). PHP File</summary> <?php declare(strict_types=1); #parse("PHP File Header.php")</code></pre></details> PHP Class</summary> <?php declare(strict_types=1); #parse("PHP File Header.php") #if (${NAMESPACE}) namespace ${NAMESPACE}; #end final class ${NAME} { }</code></pre></details> PHP Interface</summary> <?php declare(strict_types=1); #parse("PHP File Header.php") #if (${NAMESPACE}) namespace ${NAMESPACE}; #end interface ${NAME} { }</code></pre></details> PHP Trait</summary> <?php declare(strict_types=1); #parse("PHP File Header.php") #if (${NAMESPACE}) namespace ${NAMESPACE}; #end trait ${NAME} { }</code></pre></details> PHP Enum</summary> <?php declare(strict_types=1); #parse("PHP File Header.php") #if (${NAMESPACE}) namespace ${NAMESPACE}; #end enum ${NAME}#if (${BACKED_TYPE}) : ${BACKED_TYPE} #end{ }</code></pre></details> PHP Test</summary> <?php declare(strict_types=1); #parse("PHP File Header.php") #if (${NAMESPACE}) namespace ${NAMESPACE}; #end #if (${TESTED_NAME} && ${NAMESPACE} && !${TESTED_NAMESPACE}) use ${TESTED_NAME}; #elseif (${TESTED_NAME} && ${TESTED_NAMESPACE} && ${NAMESPACE} != ${TESTED_NAMESPACE}) use ${TESTED_NAMESPACE}\\${TESTED_NAME}; #end final class ${NAME} extends#if(${NAMESPACE}) \PHPUnit_Framework_TestCase #else PHPUnit_Framework_TestCase #end{ }</code></pre></details> PHP Unit 6 Test</summary> <?php declare(strict_types=1); #parse("PHP File Header.php") #if (${NAMESPACE}) namespace ${NAMESPACE}; #end #if (${TESTED_NAME} && ${NAMESPACE} && !${TESTED_NAMESPACE}) use ${TESTED_NAME}; #elseif (${TESTED_NAME} && ${TESTED_NAMESPACE} && ${NAMESPACE} != ${TESTED_NAMESPACE}) use ${TESTED_NAMESPACE}\\${TESTED_NAME}; #end use PHPUnit\Framework\TestCase; final class ${NAME} extends TestCase { }</code></pre></details> PHPSpec Specification</summary> <?php declare(strict_types=1); #parse("PHP File Header.php") #if (${NAMESPACE}) namespace ${NAMESPACE}; #end #if (${TESTED_NAME} && ${NAMESPACE} && !${TESTED_NAMESPACE}) use ${TESTED_NAME}; #elseif (${TESTED_NAME} && ${TESTED_NAMESPACE} && ${NAMESPACE} != ${TESTED_NAMESPACE}) use ${TESTED_NAMESPACE}\\${TESTED_NAME}; #end use PhpSpec\ObjectBehavior; final class ${NAME} extends ObjectBehavior { }</code></pre></details> Codeception Unit Test</summary> <?php declare(strict_types=1); #parse("PHP File Header.php") #if (${NAMESPACE}) namespace ${NAMESPACE}; #end #if (${TESTED_NAME} && ${NAMESPACE} && !${TESTED_NAMESPACE}) use ${TESTED_NAME}; #elseif (${TESTED_NAME} && ${TESTED_NAMESPACE} && ${NAMESPACE} != ${TESTED_NAMESPACE}) use ${TESTED_NAMESPACE}\\${TESTED_NAME}; #end final class ${NAME} extends \Codeception\Test\Unit { }</code></pre></details> Codeception Functional Test</summary> <?php declare(strict_types=1); #parse("PHP File Header.php") #if (${NAMESPACE}) namespace ${NAMESPACE}; #end #if (${TESTED_NAME} && ${NAMESPACE} && !${TESTED_NAMESPACE}) use ${TESTED_NAME}; #elseif (${TESTED_NAME} && ${TESTED_NAMESPACE} && ${NAMESPACE} != ${TESTED_NAMESPACE}) use ${TESTED_NAMESPACE}\\${TESTED_NAME}; #end final class ${NAME} { }</code></pre></details> </div> Shortcuts</h2> It is very important to learn the IDE shortcuts, that will bring you confidence and will help you to be more productive, in case you don't know them, definitely you SHOULD. I would like to remind the plugin Key Promoter X</code> that I mentioned before. PhpStorm also brings a PDF file with the most important shortcuts, go to Help ➔ Keyboard Shortcuts PDF</code> to download it. List of most important shortcuts: Windows/Linux</summary> Ctrl + Shift + S</code> = Open Settings</li> Alt + 1</code> = Display/hide Project bar</li> Alt (twice)</code> = Search in the whole project (class names, files, symbols, actions...)</li> Ctrl + N</code> = Search by class name (similar to Alt (twice)</code> but only for class names)</li> Alt + →/←</code> = Move to left/right tab</li> Ctrl + G</code> = Go to line X:Y</li> Ctrl + B</code> = Navigate in/out (similar to Ctrl + Click</code>)</li> Ctrl + Y</code> = Delete current line</li> Ctrl + C/V (without selection)</code> = Copy/Paste full line</li> Ctrl + Shift + V</code> = Paste with history</li> Ctrl + E</code> = Display recent files</li> Ctrl + Shift + E</code> = Display last 3 recent files</li> Ctrl + Shift + F</code> = Find in path (search words in the whole project)</li> Ctrl + Shift + L</code> = Reformat Code</li> Ctrl + Shift + ↑/↓</code> = Moves the current code block</li> Ctrl + Shift + M</code> = Go to start/end of current brackets</li> Ctrl + Shift + T</code> = Open test from specific class (and vice-versa)</li> Shift + Alt + Click</code> = Multiple cursor</li> Ctrl (twice keeping it pushed) + arrows</code> = Multiple cursor from adjacent lines</li> Ctrl + W</code> = Select gradually</li> Alt + J</code> = Select next occurrence similar to current one</li> Ctrl + Alt + F/M/C/V/P</code> = Refactor Function/Method/Constant/Variable/Parameter</li> Ctrl + Alt + N</code> = Inline refactor</li> Ctrl + Insert</code> = Contextual menu to override methods, generate getters, setters...</li> Ctrl + Shift + F10</code>: Run the scope where the caret is</li> Ctrl + Alt + Enter</code> = Jump to next line (adds ";" automatically if needed)</li> </ul> </details> Mac</summary> ⌘ + ,</code> = Open Settings</li> ⌘ + 1</code> = Display/hide project bar</li> ⇧ (twice)</code> = Search in the whole project (class names, files, symbols, actions...)</li> ⌘ + O</code> = Search by class name (similar to ⇧ (twice)</code> but only for class names)</li> ⌃ + →/←</code> = Move to left/right tab</li> ⌘ + L</code> = Go to line X:Y</li> ⌘ + B</code> = Navigate in/out (similar to Ctrl + Click</code>)</li> ⌘ + ⌫</code> = Delete current line</li> ⌘ + C/V (without selection)</code> = Copy/Paste full line</li> ⌘ + ⇧ + V</code> = Paste with history</li> ⌘ + E</code> = Display recent files</li> ⌘ + ⇧ + E</code> = Display last 3 recent files</li> ⌘ + ⇧ + F</code> = Find in path (search words in the whole project)</li> ⌥ + ⌘ + L</code> = Reformat Code</li> ⌘ + ⇧ + ↑/↓</code> = Moves the current code block</li> ⌘ + ⇧ + T</code> = Open test from specific class (and vice-versa)</li> ⌥ + ⌘ + ⇧ + Click</code> or = Multiple cursor</li> ⌘ (twice keeping it pushed) + arrows</code> = Multiple cursor from adjacent lines</li> ⌥ + ↑</code> = Select gradually</li> ⌥ + ⌘ + F/M/C/V/P</code> = Refactor Function/Method/Constant/Variable/Parameter</li> ⌥ + ⌘ + N</code> = Inline refactor</li> ⌘ + N</code> = Contextual menu to override methods, generate getters, setters...</li> ⇧ + ⌃ + R</code> = Run the scope where the caret is</li> ⌘ + ⇧ + Enter</code> = Jump to next line (adds ";" automatically if needed)</li> </ul> In case the shortcut ⌃ + →/←</code> changes between Desktops in Mac, you can disable it in Settings ➔ Keyboard ➔ Keyboard Shortcuts... ➔ Mission Control</code>. </blockquote> </details> Add Custom shortcuts</h3> We just saw the Ctrl + 1</code>/⌘ + 1</code> shortcut displays/hides the project bar, it is also very handy to set the shortcut Ctrl + Alt + 1</code>/⌘ + ⇧ + 1</code> to display and select in the project bar the current file. This way, we don't need to use the mouse at all, we can navigate between tabs with only the keyboard. To set this new combination, in Settings ➔ Keymap</code> search by Select File in Project View</code> and Add Keyboard Shortcut</code>. It is also very handy to add shortcuts to Split and Move Right</code> or Split and Move Down</code> with Ctrl + I/-</code>/⌃ + I/-</code>. Functional Tests 2023-08-26T00:00:00+00:00 A test is an empirical assertion that verifies whether a piece of functionality behaves as expected under specific conditions. Tests can be classified using the "box" approach, which categorizes tests based on how they interact with the system from the tester's perspective. There are two main approaches: white-box</code> and black-box</code> testing. The white-box</code> approach occurs when the tester has access to the source code. In this scenario, the tester focuses on testing different code paths and internal structures to cover as many branches as possible. In the black-box</code> approach, the system's internal workings are hidden from the tester. Here, the tester can only provide input and observe output, focusing on whether the application behaves correctly from an external perspective, without concern for the internal implementation details. However, there is another, more specific classification: functional</code> and non-functional</code> tests. Non-functional</code> tests refer to aspects that are not related to specific functions or user actions. They can be divided into security</code>, performance</code>, usability</code>, and compatibility</code> testing. Functional</code> tests refer to activities that verify specific actions or functions of the code. They can be divided into unit</code>, integration</code>, and e2e</code> tests. From a tester's point of view, functional tests are more fundamental as we spend most of our time writing these types of tests rather than non-functional ones. Additionally, it is tremendously important to master them to write cleaner code. Differences between functional tests</h2> Unit test</h3> A unit test verifies the relationship between an input and an expected output for a single, isolated piece of logic that is decoupled from external dependencies. You can think of a unit test as testing one public method of a class. It's usually a good idea to use interfaces to invert dependencies in your application (following the Dependency Inversion Principle). When unit tests need to interact with external dependencies, we use stubs or mocks instead of real implementations. The benefit of unit tests is that they execute quickly, allowing them to be run more frequently. They also force you to write loosely coupled code, leading to better software design. In essence, a unit test demonstrates that an isolated piece of functionality works correctly in isolation. Unit tests provide you with: A simple way to test your code exhaustively and independently</li> Quick feedback that points you directly to the problematic code section</li> </ul> A test is not a unit test if it performs queries to a database</li> connects to the network in any way</li> operates with the file system</li> cannot be run in parallel with other unit tests</li> requires you to modify configuration files to run</li> </ul> They are also known as ‘white box testing’. We know the internal code from the method. These tests focus on verifying the object's behavior and state. There are frameworks for automating unit testing, with the most popular being the xUnit family: JUnit, PHPUnit, NUnit, etc. Integration test</h3> Integration tests are similar to unit tests except that they focus on verifying the interaction between two or more components working together, such as classes, modules, services, etc. Unlike unit tests, integration tests can connect to databases, networks, file systems, and other external dependencies. The integration tests are slower than unit tests due to their complexity, besides, sometimes it’s needed to load specific configuration in order to work properly. These tests are environment-dependent, meaning that if a test fails, the problem could be due to different configurations between environments. You can even create integration tests with PHPUnit, the Unit</code> in the name is just a convention. E2E test</h3> The E2E tests (End-to-End) are also called system tests or browser testing. These tests focus on what the application does rather than how it does it. In other words, they verify the expected behavior from the user's perspective, regardless of the internal implementation details. E2E tests simulate real user interactions and validate that the entire system works correctly from start to finish. For example, if we submit a form with an invalid value, we expect to see an error message in a specific field. We don't care about the underlying validation logic or regular expressions—only that the user sees the appropriate feedback. E2E tests are also known as “black-box testing”. We don't need to know the internal code structure. They focus on testing the application's behavior from the user's perspective. Popular E2E testing tools include Selenium, Cypress, and Playwright. Parlamento de la batalla del 3 de Mayo 2023-05-03T00:00:00+00:00 CRISTIANO Cita te di y a la cita acudiste presuroso; que el cielo te haga dichoso le pido a mi Cruz bendita. SULTÁN Parlamento me anunciaron los sones de tus clarines y vengo a saber los fines que para ello te impulsaron. Sé breve. CRISTIANO Ya lo has de ver, pues me abruma la impaciencia por cumplir de mi conciencia con un sagrado deber. SULTÁN Pues di cristiano. CRISTIANO ¡Sultán! Ya nuestros bravos soldados frente a frente situados, prestos a la lucha están. Ya el relinchar de los brutos y el crujir de las corazas óyense cual amenazas de desolación y lutos. Bien pronto los resplandores de ese sol que nos alumbra, convertiranse en penumbra llena de sangre y horrores. Y esta alfombra matizada de violetas y tomillos, y esos tiernos pajarillos que trinan en la enramada y esas fuentes cristalinas en do se miran los cielos, y esos mansos arroyuelos, y esas bordadas colinas, ruinas quedarán mañana de la destructora guerra y no habrá un palmo de tierra que no haya una tumba humana. SULTÁN Tétrica es la descripción que me haces de la guerra, ¿crees que mi ánimo se aterra? Termina ya tu sermón. CRISTIANO Sé indulgente, gran Sultán y un momento más escucha. SULTÁN Vamos cristiano a la lucha. CRISTIANO Es que la quiero evitar. Quiero que seamos hermanos como tales nos amemos y sólo al Dios adoremos que adoramos los cristianos. Que no busques otra luz del mundo en nuestro camino que la del faro divino de mi Santísima Cruz. Que jamás ostentar dejes esas reliquias mentidas de sectas envilecidas que obras son de los herejes. Que os inspiréis en mi Dios, de Cielos y Tierra Rey y de su divina Ley caminéis por siempre en pos. Que apagues tu encono fiero y hacer la paz te decidas para salvar estas vidas que va a segar el acero, y con nobleza y honor los ejércitos unidos, desde hoy queden convertidos a la gracia del Creador. El hablarte en este estilo ya ves que no me avergüenza, cumplí así con mi conciencia y espero el fallo tranquilo. SULTÁN ¡Tranquilo, sí… estarlo debe y con sobrada razón quien no tiene corazón o como el tuyo que es de nieve! Gran ruindad se necesita, ¿dije ruindad? ¡Cobardía!, para venir este día a hablar de una Cruz bendita, de un Dios que será un cualquiera y que en verdad y no en broma, será un criado de Mahoma de los de más baja esfera. CRISTIANO ¡Impío, calla esos labios! SULTÁN Cristiano, no alces el grito, que para un leño y un mito no hay ofensa ni hay agravios. Que es su valor tan menguado y tan mezquino su precio, que sólo con mi desprecio lo encuentro muy bien pagado. Ya verás, gran General, dentro de breves momentos esas cruces y esos cuentos a donde van a parar. Ya verás el fin que tienen tus orgullos altaneros y esos míseros guerreros que a luchar contra mí vienen. Sangre, lodo y confusión quedará tan solo de ellos antes que el Sol sus destellos retire de esta mansión. Y al golpe de los alfanjes de mis huestes agarenas, cubrirán estas arenas los cuerpos de esas falanges, y una por una segadas sus desgreñadas cabezas en mis altas fortalezas ordenaré sean colgadas, do el águila y el milano con sus garras como el hierro no dejen rastro de un perro de ese ejército cristiano. Y esa Cruz tan altanera, falsa, engañosa y mentida, la mirarás convertida en asta de mi bandera. ¿Qué dije? Locura fuera elevarla a tal destino: la quemo… y tu Dios divino que la saque de la hoguera. CRISTIANO Maldito seas agareno, maldita tu raza mora y maldito cuanto adora ese pueblo sarraceno. ¡Infame, blasfemo, vil, sucia escoria del averno, aborto del mismo infierno y venenosos reptil! Ya para ti no hay perdón, africano mal nacido, que de mi pecho has oído la piadosa compasión. ¡Guerra a muerte miserable! ¡Guerra que cuartel no haya para ti y esa canalla, asquerosa y despreciable; y exterminio, sangre y fuego que hagan tus ídolos trizas y confundan en cenizas a ese Alá del que reniego! ¡Sólo esto espero, traidor, sólo esto espero, cobarde! ¿Tiemblas? Pues ¿do está tu alarde de arrogancia y de valor? ¿Qué hiciste de aquellos bríos que mostrabas belicoso cuando, humilde y silencioso escuché tus desvaríos? Qué gran mentira revela ese rostro demudado más propio que de un soldado de una simple mujerzuela. SULTÁN ¡Cristiano! CRISTIANO No hay que perder un momento más. Escucha ¿quisiste lucha? A la lucha hasta morir o vencer. Mando moros a millones, trae tus estados enteros, que un puñado de guerreros basta para tus legiones. ¡Di a Alá que te preste luz, di que de su altura baje y en mi presencia ultraje a mi Santísima Cruz! Cruz bendita, Cruz gloriosa, Madre del mundo cristiano, llega que el perro africano ciegue al verte tan hermosa. Llega de mi ayuda en pos, llega radiante de gloria y preside la victoria de los hijos de tu Dios. Llega en la lucha y goza, que la piel de ese agareno cubrirá el polvo y el cieno por do pase tu carroza. Llega que tu hijo está aquí, y en terminando esta guerra no habrá un lugar en la Tierra donde no se adore a Ti. ¡A la batalla ahora mismo! SULTÁN Mas si el plazo dilatara. CRISTIANO ¡Te hallaré aunque te ocultaras en el seno del abismo! Tu cabeza es mi ambición, darte muerte mi deseo y escupir tu rostro feo, mi mayor satisfacción. Aléjate moro impío. SULTÁN Volveré, perro cristiano… CRISTIANO No volverás, africano, lo juro por el Dios mío. SULTÁN Guerra a muerte el moro grita. CRISTIANO Guerra a muerte sarraceno. SULTÁN ¡Viva nuestro Alá agareno! CRISTIANO ¡Viva nuestra Cruz bendita! ¡VIVA! José Ortega Martínez, 1883 </blockquote> </div> </iframe> </div> How to create a global .gitignore file 2023-04-25T00:00:00+00:00 Sometimes while we're creating a pull request, we realise we're committing some unnecessary config files, like the settings from your IDE, some cache files or even auto-generated files like the .DS_Store</code>. Fortunately, there is a way to ignore all these files in your system and don't bother to add them anymore to every project in the specific .gitignore</code>. The first step is to create the global .gitignore</code> file we're going to use. touch ~/.gitignore</code></pre> Depending on your SO, the IDE, the programming language, etc that you use, the content of this file could vary, but the idea is to place it here all these files you want to omit. *~ .DS_Store .idea *.cache</code></pre> Finally, let's add this file to your git</code> as follows: git config --global core.excludesFile ~/.gitignore</code></pre> You can confirm your file was added by running the previous command without specifying the path. You should see the file location, if so, it should be done 🐙 git config --global core.excludesFile /Users/Jesus/.gitignore # Output 👀</code></pre> If you aren't working alone on a project, consider that maybe other people aren't ignoring the duplicate files globally as you do, so for this, it is worth adding these lines not only on your global but in the .gitignore</code> from that project. </blockquote> Happy programming! 🤓 Declaring array structures in PHP 2023-02-20T00:00:00+00:00 Currently, it is not possible to define explicit array types like Java does. List<User> users = new ArrayList<>();</code></pre> There have been some attempts to achieve that. Nikita Popov made one of the most recent ones in this pull request</a>. Unfortunately, the conclusion was that regarding the current PHP status, that is not doable (at least in the short/medium term), as it would require rewriting an enormous amount of code, some of which is very critical. Fortunately, tools like PHPStan or Psalm help us analyze the code statically. That means, they do not execute but check the code for inconsistencies based on PHP comments. There are three different ways to define the type of elements in a PHP array: Legacy way: User[]</code></li> List Shape: array<int, mixed></code> & list<mixed></code></li> Object Shape: array{foo:?string, bar:array{name:string, value:mixed}}</code></li> </ol> The Legacy way</h2> This is a legacy approach to define a list of elements of a specific type. The problem is that it becomes ambiguous, and developers using this kind of list cannot know if keys are integers or strings. Also, while modern static analyzers will infer User[]</code> as array<int, User></code> by default, this inference may not always align with the actual runtime behavior or your intent. Being explicit with array<int, User></code> or list<User></code> is still a better practice because: It's more explicit about intent</li> Avoids any ambiguity about what keys are valid</li> Makes the code more self-documenting</li> </ul> In the end, the more explicit, the better. /** @var User[] $users */ $users = [ ... ]; # Are keys auto-incremental integers, random numbers, maybe strings... ? $firstUser = $users[ ? ]; # Static analyzers won't complain if you use an incorrect key type 🤕</code></pre>List Shape</h2> We use lists when we have an array of elements with the same type. We use angled brackets to declare the types of the key and the value: array<TKey, TValue></code>. 💡There is a very handy shortcut when the key is an auto-incremental integer: list<T></code>. list<T></code> is an alias of array<int<0, max>, T></code> </blockquote> /** @var array<string, User> $users */ $users = [ 'jesus' => new User('Jesus Valera'), 'chema' => new User('Chema Valera'), ]; $userJesus = $users['jesus']; $userChema = $users['chema']; $users[0]; # ERROR: "Offset 0 does not exist on array<string, User>" --- /** @var list<User> $users */ $users = [ new User('Jesus Valera'), new User('Chema Valera'), // ... ]; $firstUser = $users[0]; $secondUser = $users[1];</code></pre>Object Shape</h2> We use object shape when the array is not a collection of objects but a map which holds information. To do that, we use the curly bracket syntax and define the key name and the type, we can split by commas if there are multiple elements: array{foo:int, bar:string}</code>. /** @var array{id:int, birthdate:DateTimeImmutable} */ $additionalInfo = [ ... ]; $id = $additionalInfo['id']; # int $birthdate = $additionalInfo['birthdate']; # DateTimeImmutable</code></pre> Given the following 'object shape' array ['hello' => 'world', new stdClass(), false];</code></pre> It will be addressed internally as follows: array{'hello': string, 0: stdClass, 1: false}</code></pre> By default, numeric indices starting from 0 are auto-assigned to elements without explicit keys </blockquote> </div> Example of a User class that holds two arrays: a list and an object shape. final readonly class User { /** @var list<Comment> */ public array $comments; /** @var array{id:int, birthdate:DateTimeImmutable} */ public array $additionalInfo; }</code></pre> There are multiple advantages when using these PHP comments, they not only provide better feedback on the array shape to the developers but IDEs will suggest auto-completion when iterating on individual elements! </div> Of course, it's possible to represent any complex array structure using these PHPDoc annotations. Example: /** * @var list< * array{ * uuid?: string, * content: array{name:string, foo:?stdClass}, * } * > $array */ $array = [ 0 => [ 'uuid' => '550e8400-e29b-41d4-a716-446655444000', 'content' => [ 'name' => 'str', 'foo' => null, ], ], 1 => [ 'content' => [ 'name' => 'str', 'foo' => new stdClass(), ], ], // ... ];</code></pre> We can use the PHP comments on arrays anywhere (class properties, function params, inline initialization…) </blockquote> Resources:</h2> Psalm | Array Shapes</a></li> PHPStan | PHPDoc Types</a></li> </ul> ORM: Data Mapper vs Active Record 2022-12-06T00:00:00+00:00 ORM stands for Object-Relational Mapping, that is, the technique that transforms Objects from OOP into rows in the database and vice versa. There are two patterns: Active Record: The record (entity) itself can actively change the DB</li> Data Mapper: There is an external object that persists the entities</li> </ul> I will skip everything related to the DB setup like the XML configuration files for the Data Mapper and the hasOne() / hasMany() methods for the Active Record. </blockquote> Active Record</h2> As I previously mentioned, the entity itself can be created, updated or deleted. In PHP for example, Eloquent is an Active Record ORM developed by the Laravel community. final class UserCreator { public function create(UserInformation $userInfo): void { $address = Address::createFrom($userInfo->address()); $address->save() # Address is stored in the database $user = User::createFrom($userInfo->user()); $user->address = $address; // Set relationship $user->save(); # User is stored in the database } }</code></pre>Data Mapper</h1> In the data mapper, we need an external class that will update the DB. In PHP for example, Doctrine is the de facto Data Mapper ORM for Symfony. final class UserCreator { public function __construct( private EntityManager $entityManager, ) {} public function create(UserInformation $userInfo): void { $address = Address::createFrom($userInfo->address()); $user = User::createFrom($userInfo->user()); $user->address = $address; # Set relationship # We persist all objects we want to update $this->entityManager->persist($address); $this->entityManager->persist($user); # Finally, flushing the entity manager will execute the SQLs $this->entityManager->flush(); } }</code></pre></div> So far, the code was very similar in both situations, you have to create a specific entity object, (for simplicity) we used a createFrom()</code> named-constructor in both snippets and we called save()</code> or persist()</code> and flush()</code> depending on the scenario. Although, if you take a look at both snippets, you can see already the Data Mapper is using an external dependency (Entity Manager</code> object) which is odd and clearly, is harder if you decide to introduce some tests to the UserCreator</code> class, meanwhile in the Active Record</code> class, the entities are saving themselves, so we don’t have any dependency at a glance, but that is not completely true, the entity itself has knowledge of the DB, and it will be difficult to write some tests if we use the User</code> entity directly. Repository Pattern</h2> The repository pattern is a design pattern that hides the database logic into a new class, exposing only the methods we want to provide to the user. In order to do this, we need to create an interface and a class that will implement the interface where we will drop all logic. # App/User/Domain interface UserRepository { public function save(UserInformation $userInfo): void; } ~~~~ # App/User/Infrastructure final class ActiveRecordUserRepository implements UserRepository { public function save(UserInformation $userInfo): void { $address = Address::createFrom($userInfo->address()); $address->save() $user = User::createFrom($userInfo->user()); $user->address = $address; $user->save(); } } final class DataMapperUserRepository implements UserRepository { public function __construct( private EntityManager $entityManager, ) {} public function save(UserInformation $userInfo): void { $address = Address::createFrom($userInfo->address()); $user = User::createFrom($userInfo->user()); $user->address = $address; $this->entityManager->persist($address); $this->entityManager->persist($user); $this->entityManager->flush(); } }</code></pre> So the last step is to define which class will be resolved when we inject our UserRepository</code> interface, and finally, our UserCreator</code> will be like: final class UserCreator { public function __construct( private UserRepository $userRepository, ) {} public function create(UserInformation $userInfo): void { $this->userRepository->save($userInfo); } }</code></pre> Regarding tests, with the current UserCreator</code> implementation, it would be really simple to add a unit test, but it won’t make sense as the saving logic would be mocked, and the test would provide no value at all. A functional test where we check the user and the address was actually persisted in the database properly makes more sense, but I will skip the test as it would add unnecessary complexity to the post 🙂 How does the Service Container work? 2022-10-21T00:00:00+00:00 A Service Container is basically a class that behaves like a box, we can think of it as a singleton object (but it is not, it is simply an object that is instantiated by the framework while it is being bootstrapped), on which we can declare all of our dependencies to be resolved automatically by the framework. The role of a Service Container is to define which classes (with their inner dependencies) should be resolved automatically. Usually, frameworks like Symfony or Laravel brings already a bunch of interfaces that will resolve automatically specific classes. So, for \Psr\Log\LoggerInterface</code> there is somewhere a class that implements this interface like Monolog</code> or any other. Let's imagine we have a service whose dependency is a UserRepository</code> (this dependency belongs to our use case, so it is not defined in the framework), additionally, depending on the environment, we want to inject a PostgreSQLUserRepository</code> or a InMemoryUserRespository</code> instance. This post will be based on the two most popular PHP frameworks (Symfony & Laravel), but the idea works for any other programming language/framework. </blockquote> Symfony</h2> We can define our services as php</code> or yaml</code> file extension (you can define this configuration directly in the src/Kernel.php</code> file). # config/services.php namespace Symfony\Component\DependencyInjection\Loader\Configurator; return function(ContainerConfigurator $containerConfigurator) { $services = $containerConfigurator->services(); $services->set( \App\Domain\UserRepository::class, \App\Infrastructure\PostgreSQLUserRepository::class ); };</code></pre> Alternatively, we can define a different instance for the testing environment: # config/services_test.yml namespace Symfony\Component\DependencyInjection\Loader\Configurator; return function(ContainerConfigurator $containerConfigurator) { $services = $containerConfigurator->services(); $services->set( \App\Domain\UserRepository::class, \App\Infrastructure\InMemoryUserRespository::class ); };</code></pre>Laravel</h2> In Laravel, however, you can do this in the AppServiceProvider</code> class. namespace App\Providers; final class AppServiceProvider extends ServiceProvider { public function register(): void { if (env('APP_ENV') === 'test') { $this->app->bind( App\Domain\UserRepository::class, App\Infra\InMemoryUserRespository::class ); } else { $this->app->bind( App\Domain\UserRepository::class, App\Infra\PostgreSQLUserRepository::class ); } } public function boot(): void { // ... } }</code></pre>Injecting the dependencies in our services</h3> So, from now on, the next time we try to inject our interface UserRepository</code> as a dependency in the constructor of another class, eg: final class UserCreator { public function __construct( private UserRepository $userRepository, ) {} // ... }</code></pre> The framework will handle it, checking firstly if we defined in our service provider the injected class and creating a new instance of it. In case this class has any dependency, the framework will resolve them automatically recursively by reflection until the class is ready, in case any dependency cannot be resolved or the dependency is a primitive, and we didn't define the value, it will throw an exception. </div> Let’s go deeper into the technical details, how could you create such a dependency resolver? This is how we did in Gacela (link</a>), and this is a simplified version of it: final class DependencyResolver { /** @var array<class-string,mixed> */ private array $container; public function resolve(string $className): object { $reflectionClass = new ReflectionClass($className); $constructor = $reflectionClass->getConstructor(); # If constructor is empty, we can do a `new $className()` if (null === $constructor) { return $reflectionClass->newInstance(); } # If not empty, let's resolve the class dependencies $dependencies = []; foreach ($constructor->getParameters() as $parameter) { $paramName = $parameter->getType()?->getName(); $dependencies[] = $this->container[$paramName] ?? $this->resolve($paramName); # 🌀 Recursion } # Finally, we store in the container the resolved class $class = $reflectionClass->newInstanceArgs($dependencies); $this->container[$className] = $class; return $class; } }</code></pre> This is the idea of what a framework does under the hood; ideally, we should use a cache layer. Using reflection takes a lot of resources, and it is very slow; additionally, we are not taking into consideration different scenarios like what to do depending on whether the resolved parameter is a primitive or even a callable. Reference:</h2> Symfony — Service Container</a></li> Laravel — Service Container</a></li> Gacela — Bindings</a></li> </ul> Why and How to decouple your classes 2022-08-17T00:00:00+00:00 There are some ways to couple your code, some frameworks like Laravel embrace you to do using their own façades or even using ORM as ActiveRecord, but this is also possible using PHP native methods like time()</code> beyond others. Unfortunately, in the long run, if you don't invert the dependencies, the code will get messy faster/easier, hurting your application. To avoid this, you must write tests. Writing tests help you realize how coupled is your business logic to infrastructure code. Examples of classes that should be decoupled</h2> Belongs to the Programming language itself like</h3> I/O functions like fopen()</code>, file_exists()</code>, file_put_contents()</code>…</li> Network related like curl_init()</code>, http_response_code()</code>, setcookie()</code>…</li> Relative to time like date()</code>, time()</code>, microtime()</code>…</li> System like getenv()</code>, exec()</code>, system()</code>…</li> </ul> Belongs to the infrastructure code like</h3> Framework classes like Laravel Façades</li> Database (Active Record or raw queries instead of Repository</code> pattern)</li> Third-party services like Monolog</code>, Mandrill</code>, Salesforce</code>…</li> </ul> Decoupling a real example</h2> For the next example, let’s try to use a Laravel facade and a PHP function. Imagine we have the following service, and we really want to invert the dependencies. We have thetrans()</code> facade and the date()</code> PHP function. namespace App\Application; final class WelcomeService { /** * Output: "hello {$name} @ {Y-m-d}" */ public function welcome(string $name): string { return trans('messages.welcome', [ 'name' => $name, 'date' => date('Y-m-d'), ]); } }</code></pre> The first thing we should do is to move the trans()</code> Laravel function logic to a different place, in order to do that, we have to invert the dependencies introducing a new interface as follows: namespace App\Domain; interface Translator { public function trans(string $message, string ...$placeholders): string; }</code></pre> And place in a new class (which belongs to infrastructure layer) the original Laravel implementation. namespace App\Infrastructure; final class LaravelTranslator implements Translator { public function trans(string $message, string ...$placeholders) { return trans($message, ...$placeholders); } }</code></pre> From now on, we are able to switch the translator implementation between Laravel or a third-party one by implementing the Translator</code> interface. We can inject the new LaravelTranslator</code> service in our WelcomeService</code> defining in the service container which implementation we want to resolve when the framework faces the Translator</code> in the constructor. namespace App\Application; final class WelcomeService { public function __construct( private Translator $translator, ) {} public function welcome(string $name): void { return $this->translator->trans( 'messages.welcome', ['name' => $name, 'date' => date('Y-m-d')], ); } }</code></pre> The next step is to do the same but with the date()</code> method. namespace App\Domain; interface Date { function toString(): string; }</code></pre> And the PHP implementation: namespace App\Infrastructure; final class SystemDate implements Date { public function toString(): string { return date('Y-m-d'); } }</code></pre> Let’s do the same as we did previously, but this time we can inject our own SystemDate</code> implementation through the Date</code> interface. namespace App\Application; final class WelcomeService { public function __construct( private Translator $translator, private Date $date, ) {} public function welcome(string $name): void { return $this->translator->trans( 'messages.welcome', ['name' => $name, 'date' => $this->date->toString()], ); } }</code></pre> Finally, we can create a test for the WelcomeService</code> injecting the required dependencies. final class WelcomeServiceTest extends TestCase { public function test_welcome(): void { $translate = new LaravelTranslator(); // Real implmentation $date = $this->createStub(Date::class); // Fake implementation $date->method('toString')->willReturn('2022-02-22'); $name = 'World'; $service = new WelcomeService($translate, $date); $response = $service->welcome($name); self::assertSame('hello World @ 2022-02-22', $response); } }</code></pre> Ideally we should write the test first, later the real implementation </blockquote> Conclusion</h2> Decoupling your classes is a good practice that will help you to maintain your codebase in the long run. It will also help you not only to switch between different implementations of the same interface in case you decided to change the framework or the third-party service but also to test your code in a more efficient way. A brief introduction to GraphQL 2022-03-16T00:00:00+00:00 A RESTful API is a de-facto standard to allow communication between applications, although, recently GraphQL comes up. From the user-client perspective, GraphQL is similar to RESTful, they work as an entry point between different applications, but GraphQL is slightly different, and because of this, this technology has a reason to be. GraphQL vs RESTful API</h2> GraphQL and RESTful have the same foundation. They use the HTTP methods, and they have the idea of resource, but, in REST, each endpoint is a single resource, while in GraphQL there is only a single resource. GraphQL is not about resource state management, but about separating read operations (queries) from write operations (mutations). This is known as the Command Query Separation pattern</a>. In REST, the server determines the shape and size of a resource, in GraphQL depends on the user's needs. How to manage a GraphQL schema?</h2> A schema contains objects, every object has different parameters, and those parameters can be properties or even sub-objects. Usually, if you want to filter an object(s) from a specific Type, you can apply a filter into brackets, the output is always a JSON response. Queries</h3> The queries are the GET requests. That means you can only fetch data. Mutations</h3> The mutations are the POST, PUT, PATCH, and DELETE HTTP methods. That means you can mutate the data model, and persist it in the database by creating, updating or removing elements. In a mutation, the addOffer() is the instruction you will perform into the system, though the body of the mutation is the response you want to receive. </blockquote> </div> To write queries and mutations effectively, you need to understand the database architecture and relations between elements. Beyond that, GraphQL works similarly to REST, just with different syntax. The GraphQL documentation</a> covers more advanced topics like enums</code>, interfaces</code>, entity management, and schema design. Worth checking out if you're building a GraphQL API from scratch. Sorting functions in PHP 2021-08-18T00:00:00+00:00 When dealing with PHP, there are multiple ways to sort a collection of items, and sometimes it’s not clear which method we should use and why. What is the difference between sort()</code>, arsort()</code> and uasort()</code>? </blockquote> Before explaining the repercussions of a</code>, r</code>, k</code> and u</code> + sort()</code> function, we need to know the very basic concept of lists and maps. List</h2> A list is an ordered collection. The order is sequential starting from 0 and increasing 1 by 1 for each item. It is also possible to have duplicated items in a list. $list = ['Croatia', 'Belgium', 'Austria', 'Belgium', 'Denmark']; print_r($list); Array ( [0] => Croatia [1] => Belgium [2] => Austria [3] => Belgium [4] => Denmark )</code></pre>Map (also known as Dictionaries)</h2> A map is an unordered collection. Each element is composed of a key and a value. It is not possible to have the same key more than once. $map = [ 'Croatia' => 0, 'Belgium' => 1, 'Austria' => 2, 'Denmark' => 3, 'Belgium' => 4, ]; print_r($map); Array ( [Croatia] => 0 [Belgium] => 4 // 'Belgium => 1' was overriden [Austria] => 2 [Denmark] => 3 )</code></pre></div> It was important to do a quick overview of maps and lists, they are different kinds of collections, and because of that, each one has its own specific sorting methods. The idea of those a</code>, r</code>, k</code> & u</code> + sort()</code> is to work as modifiers as follows: R = reverse ➝ sort in descencing order, lists & maps K = key ➝ sort by key, only for maps A = associative ➝ sort by value, only for maps U = user-defined ➝ defined by the user in a callback </div> Sorting Lists 🧵</h2> sort() & rsort()</h3> These methods sort lists in ascending/descending order. # sort: Sort list by *ascending* order. $sort = ['Croatia', 'Belgium', 'Austria', 'Belgium']; sort($sort); Array ( [0] => Austria [1] => Belgium [2] => Belgium [3] => Croatia ) --- # rsort: Sort list by *descending* order. $rsort = ['Croatia', 'Belgium', 'Austria', 'Belgium']; rsort($rsort); Array ( [0] => Croatia [1] => Belgium [2] => Belgium [3] => Austria )</code></pre>Sorting Maps 🗺️</h2> asort(), arsort(), ksort() & krsort()</h3> These methods sort associative arrays by key/value in ascending/descending order. # ksort: Sort map by *key* in *ascending* order. $ksort = [100 => 'Croatia', 200 => 'Austria', 300 => 'Belgium']; ksort($ksort); Array ( [100] => Croatia [200] => Austria [300] => Belgium ) --- # krsort: Sort map by *key* in *descending* order. $krsort = [100 => 'Croatia', 200 => 'Austria', 300 => 'Belgium']; krsort($krsort); Array ( [300] => Belgium [200] => Austria [100] => Croatia ) --- # asort: Sort map by *value* in *ascending* order. $asort = [100 => 'Croatia', 200 => 'Austria', 300 => 'Belgium']; asort($asort); Array ( [200] => Austria [300] => Belgium [100] => Croatia ) --- # arsort: Sort map by *value* in *descending* order. $arsort = [100 => 'Croatia', 200 => 'Austria', 300 => 'Belgium']; arsort($arsort); Array ( [100] => Croatia [300] => Belgium [200] => Austria )</code></pre>User-defined functions 👩‍💻</h2> Until now everything was nice, but as you know, usually we have a collection of complex objects, and sometimes we want to define our own sorting function, in these scenarios, the asort() method simply doesn't work. Eg: “Sorting a collection of Product</code> by price in ascending order, and when more than one product has the same price, sort them alphabetically by the name”. We need to find a more sophisticated approach. And this is only possible if we can define our own sorting method, in this case, we can take advantage of using the spaceship operator</code>! 🚀 Basically, this operator is syntactic sugar specialized for comparisons. The first parameter is the array we want to sort and the second is a callback that returns an integer value. /** @var callable(mixed,mixed):int $callable */ $callable = function (mixed $a, mixed $b): int { ... } usort(&$array, $callable): bool</code></pre> The values this callable must return are -1</code>, 0</code> and 1</code> if the current item is less, equal or greater than the previous one, to be sorted before or after in the collection. function compare(int $a, int $b): int { if ($a == $b) { return 0; } return ($a < $b) ? -1 : 1; } # Is the same than... function compare(int $a, int $b): int { return $a <=> $b; } # Is the same than... fn (int $a, int $b): int => $a <=> $b;</code></pre>usort(), uksort() & uasort()</h3> These methods sort by keys or values (preserving or resetting the keys) in a user-defined callback. Let’s see some examples: # usort: Sort list/map by callback from the values, keys are reset. $usort = [100 => 'Croatia', 300 => 'Austria', 200 => 'Belgium']; usort($usort, fn (string $a, string $b): int => $a <=> $b); Array ( [0] => Austria [1] => Belgium [2] => Croatia ) --- # uksort: Sort map by callback from the keys. $uksort = [100 => 'Croatia', 300 => 'Austria', 200 => 'Belgium']; uksort($uksort, fn (int $a, int $b): int => $a <=> $b); Array ( [100] => Croatia [200] => Belgium [300] => Austria ) --- # uasort: Sort map by callback from the values preserving the keys. $uasort = [100 => 'Croatia', 300 => 'Austria', 200 => 'Belgium']; uasort($uasort, fn (string $a, string $b): int => $a <=> $b); Array ( [300] => Austria [200] => Belgium [100] => Croatia )</code></pre> For the sake of simplicity, I used the function: fn ($a, $b) => $a <=> $b;</code> if the collection was holding complex objects, it would be the same but comparing some property, it depends on your needs. 📑 Cheat Sheet</h2> sort() - sort list in ascending order rsort() - sort list in descending order asort() - sort map by value in ascending order ksort() - sort map by key in ascending order arsort() - sort map by value in descending order krsort() - sort map by key in descending order usort() - sort list or map by value in a user-defined callback, reset keys uksort() - sort map by keys in a user-defined callback uasort() - sort map by value in a user-defined callback</code></pre> * Take into account that the array is passed by reference to the sorting function, which means you must initialize the array in a different line, and the sorting function will mutate the original array 👀 </blockquote> Reference</h2> Array Sorting | PHP Doc</a></li> PHP Sorting Arrays | W3Schools</a></li> Difference between Set, List and Map in Java | Java67</a></li> </ul> Functional Programming in JavaScript 2021-05-17T00:00:00+00:00 Functional Programming is a paradigm where programs are constructed by applying and composing functions. The Functional Programming keys are: You treat functions as first-class citizens.</li> You can pass them as arguments to other functions.</li> A function can return another function.</li> You can modify functions.</li> </ul> When a function is called with some given arguments, it will always return the same result, and cannot be affected by any mutable state or other side effects. And now, we are going to take a look at the most common JavaScript functions that allow us to write Functional Programming: forEach, map, filter, reduce, find, findIndex, some and every. </div> For Each 🧩</h2> We use forEach() when we like to iterate through an array of items. Using this method, you can get the item of the current element when iterating and/or the index. It is recommendable not to use it unless you are sure you want to modify the original array. This method is mutable. It means it will modify the original array. const countries = ['Spain', 'Germany', 'Portugal', 'France'] countries.forEach( (country, index) => console.log(index, country.toUpperCase()) ) --OUTPUT-- 0 "SPAIN" 1 "GERMANY" 2 "PORTUGAL" 3 "FRANCE"</code></pre>Map 🗺</h2> We use map() whenever we want to map the values into other values producing a new array. const countries = ['Spain', 'Germany', 'Portugal', 'France'] const mapped = countries.map((country) => country.toUpperCase()) console.log(mapped) --OUTPUT-- ["SPAIN", "GERMANY", "PORTUGAL", "FRANCE"]</code></pre>Filter ⌛️</h2> We use filter() when we want to pick just some specific elements regarding a filter. It returns a new array with the filtered elements or empty if no matches. const countries = ['Spain', 'Germany', 'Portugal', 'France'] const filtered = countries.filter( (country) => country.includes('an') ) console.log(filtered) --OUTPUT-- ["Germany", "France"]</code></pre>Reduce ⛏</h2> We use reduce() when we want to return a single value depending on a specific closure. This function can take an initial value, which by default is empty (0 or "") as the second parameter. const numbers = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] let initialValue = 5 const sum = numbers.reduce( (accumulator, value) => accumulator + value, initialValue ) console.log(sum) --OUTPUT-- 60</code></pre>find 🔎</h2> We use find() if we are interested in the first occurrence of a certain element in an array. It will return undefined otherwise. const countries = ['Spain', 'Germany', 'Portugal', 'France'] const find = countries.find((country) => country.includes('an')) console.log(find) --OUTPUT-- "Germany"</code></pre>find Index 🔑</h2> We use findIndex() if we would like the first occurrence of a certain element in an array, this method is pretty similar to find but it will return not the value but the index. In case there are no matches, the output would be -1. const countries = ['Spain', 'Germany', 'Portugal', 'France'] const findIndex = countries.findIndex( (country) => country.includes('an') ) console.log(findIndex) --OUTPUT-- 1</code></pre>Some 🧵</h2> We use some() if we are interested to know if some element from an array meets a specific closure. If any of the items satisfy the criteria the result will be true, else, it will be false. const countries = ['Spain', 'Germany', 'Portugal', 'France'] const isAn = countries.some((country) => country.includes('an')) const isLand = countries.some((country) => country.includes('land')) console.log(isAn) console.log(isLand) --OUTPUT-- true false</code></pre>Every ☘️</h2> We use every() if we want to know if every element from an array meets a specific closure. This method is somehow similar to some but the opposite. This method also returns true or false. const countries = ['Spain', 'Germany', 'Portugal', 'France'] const isEveryA = countries.every((country) => country.includes('a')) const isEveryE = countries.every((country) => country.includes('e')) console.log(isEveryA) console.log(isEveryE) --OUTPUT-- true false</code></pre></div> These are the most common functions when dealing with Functional Programming, but there are many more (fill, join, sort, etc). You can easily check the full list on the Mozilla Developer</a> 🦊 site. Functional Programming with Phel 🐘 2021-02-01T00:00:00+00:00 What is Functional Programming?</h2> Functional Programming (FP</a>) is a programming paradigm that was created in the late 1950s. It’s even older than Object-Oriented Programming (OOP</a>). The main concepts of this paradigm are: Pure functions: The concrete input will produce always the same output.</li> Recursion: There are no loops. In order to get this approach, the functions can call themselves using recursivity.</li> Functions are First-Class: A function is treated as a variable, which means you can pass functions as function arguments.</li> Variables are immutables: A variable cannot change its value once it is declared, but it’s possible to create new ones.</li> </ul> Imperative vs Declarative</h2> Let’s start with the typical factorial example to explain the differences between those two terms in the programming world. The factorial is the product of all positive integers less than or equal to a given positive number. </blockquote> n! = n * (n - 1) * (n - 2) * ... * 1</code></pre> Following this formula, we can assert that the factorial of 5 is: 5! = 5 * 4 * 3 * 2 * 1</code></pre> But if you noticed, the factorial of 5 is actually 5 times the factorial of 4. 5! = 5 * 4!</code></pre> And the factorial of 4 is 4 times the factorial of 3… and so on. It’s a recursive problem! Imperative programming</h2> The developer describes the steps one-by-one to achieve the desired result. function factorial(int $number): int { $factorial = 1; while ($number >= 1) { $factorial *= $number; $number--; } return $factorial; }</code></pre> We are overriding the $factorial</code> variable in every single iteration. We focus on “HOW”. Declarative programming</h2> The developer declares what the program does usually in small functions, with immutable variables, without side effects using recursivity instead of loops if needed. (defn factorial [number] (if (<= number 1) 1 (* number (factorial (- number 1)))))</code></pre> As you probably may guess, FP uses a declarative paradigm. We focus on “WHAT”. Conclusion</h2> FP is not better or worse than OOP, they are different but complementary in order to solve the same problem. If you want to learn/practice with some FP, I definitely recommend you Phel. You can read more information here: Phel: the Lisp that compiles to PHP</a>. Version 0.1</a> has been recently released, and I am sure you will have fun! 🎁 https://phel-lang.org/</a></h2> </blockquote> Immutability, the good way 2020-08-20T00:00:00+00:00 A mutable object can be modified after its creation, an immutable cannot. An immutable object will remain in the same state as it was created. Design and implementation will be much easier and consistent. In the case of problems, locate a potential bug is faster due that it won't have side effects. Although, creating immutable objects sometimes require more code, and it doesn't fit in all scenarios (entities need to be mutable for example). Mutability examples and their impacts</h2> final class ProductTransfer { public function __construct( public string $name, public float $price, public array $tags, public \DateTime $releaseDate, ) {} public function toString(): string { return sprintf( "Name: %s\nPrice: %.2f\nTags: {%s}\nRelease date: %s\n", $this->name, $this->price, implode(', ', $this->tags), $this->releaseDate->format('Y-m-d') ); } } --- (new ProductTransfer( name: 'Asus 452X', price: 1024.5, tags: ['computer', 'asus'], releaseDate: \DateTime::createFromFormat('Y-m-d', '1999-12-31') ))->toString(); *** OUTPUT *** > Name: Asus 452X > Price: 1024.50 > Tags: {computer, asus} > Release date: 1999-12-31</code></pre> We are going to store some object properties in a different variable. We will modify their values and finally print the variable and the object itself. Modifying the name (being a string)</h2> $name = $product->name; $name = 'Acer FC-288'; echo "Modified name: {$name}" . PHP_EOL; echo $product->toString(); *** OUTPUT *** > Modified name: Acer FC-288 > Name: Asus 452X > Price: 1024.50 > Tags: {computer, asus} > Release date: 1999-12-31</code></pre> Strings in PHP are copied by value, therefore. When we modify the variable $name</code> the original value from $product->name</code> will remain the same. Modifying the price (being a number)</h2> $price = $product->price; $price = 1.0; echo "Modified price: {$price}" . PHP_EOL; echo $product->toString(); *** OUTPUT *** > Modified price: 1.0 > Name: Asus 452X > Price: 1024.50 > Tags: {computer, asus} > Release date: 1999-12-31</code></pre> Numbers in PHP are also copied by value. Modifying the tags (being an array)</h2> $tags = $product->tags; $tags = ['phone', 'reconditioned']; echo sprintf('Modified tags: {%s}' . PHP_EOL, implode(', ', $tags)); echo $product->toString(); *** OUTPUT *** > Modified tags: {phone, reconditioned} > Name: Asus 452X > Price: 1024.50 > Tags: {computer, asus} > Release date: 1999-12-31</code></pre> In Java, arrays are passed by reference, however. In PHP, they are considered as primitive types, which means if you have an array with 5.000 elements and you pass it to a function, that array will be fully copied inside that function and any modification won’t alter the original one. Modifying the released date (being an object)</h2> $date = $product->releaseDate; $date = $date->modify('+1 day'); echo "Modified released date: {$date->format('Y-m-d')}" . PHP_EOL; echo $product->toString(); *** OUTPUT *** > Modified release date: 2000-01-01 > Name: Asus 452X > Price: 1024.50 > Tags: {computer, asus} > Release date: 2000-01-01</code></pre> In OOP languages, objects are passed (or assigned) by reference: any modification will alter the original object. Trying immutability</h2> If we replace the \DateTime</code> by a \DateTimeImmutable</code> class, let’s see what happens with the previous example. final class ProductTransfer { public function __construct( public string $name, public float $price, public array $tags, public \DateTimeImmutable $releaseDate ) {} // . . . } --- $date = $product->releaseDate; $date = $date->modify('+1 day'); echo "Modified released date: {$date->format('Y-m-d')}" . PHP_EOL; echo $product->toString(); *** OUTPUT *** > Modified date: 2000-01-01 > Name: Asus 452X > Price: 1024.50 > Tags: {computer, asus} > Release date: 1999-12-310</code></pre> This is happening because what \DateTimeImmutable does is to create a new instance of the same object with the same values. Perfect, now our code is working like a charm, doesn't it? Well, take a look at the following snippet. /** @var \DateTimeImmutable $date */ $date = &$product->releaseDate; // Notice the '&' character 👀 $date = $date->modify('+1 day'); echo "Modified released date: {$date->format('Y-m-d')}" . PHP_EOL; echo $product->toString(); *** OUTPUT *** > Modified name: 2000-01-01 > Name: Asus 452X > Price: 1024.50 > Tags: {computer, asus} > Release date: 2000-01-01</code></pre> The ‘&’ operator is used to get a value by reference, which means we are modifying the original value instead of creating a copy of this element (this is the standard behaviour for primitive types). The point of Data Transfer Objects (DTOs) is to have immutable objects. Regarding the previous snippet, we have two alternatives. On the one hand, is to make private the properties and implement getters, then, in the getter use the clone keyword. private \DateTimeImmutable $releaseDate; public function releaseDate(): \DateTimeImmutable { return clone $this->releaseDate; // Notice the 'clone' 👀 } --- // 🚨 Error - Only variables should be assigned by reference // $date = &$product->releaseDate();</code></pre> On the other hand, is about a static analyzer code library (such as Psalm), it will complain if you are not taking into account the PHPDoc that you define. /** @psalm-immutable */ final class ProductTransfer { public function __construct( public string $name, // ... ) {} // ... } --- // 🚨 Error - InaccessibleProperty Product::$name is marked readonly // $product->name = 'Acer FC-288';</code></pre> With @psalm-immutable on your immutable classes you don’t need to worry about any of this (cloning or getters), and you can even leave your properties public without any fear because they are write-only. Recommendations</h2> Use \DateTimeImmutable over \DateTime</li> Encourage immutability for your Value Objects</a> & Data Transfer Objects</a></li> Don’t use the ‘&’ character</li> Introduce a static analyzer tool in your projects (as Psalm or PHPStan)</li> </ul> </div> Reference</h2> Mutable vs Immutable Objects | InterviewCake</a></li> From Impure to Pure Code | Tommi Kaikkonen</a></li> Entity vs DTO | StackOverflow</a></li> </ul> Getting started with Open Source Software 2020-07-02T00:00:00+00:00 Have you ever wondered how you could collaborate with open-source projects, but you didn't know how to start? It couldn't be easier. Take a look: Fork the repository into your account</li> </ul> Clone the forked project on your computer</li> </ul> git clone git@github.com/myself/forked.git</code></pre> Add the upstream to sync with the new changes to your project</li> </ul> (master)$ git remote add upstream https://github.com/owner/repo.git # If you run `git remote -v` you should see: origin git@github.com:myself/forked.git (fetch) origin git@github.com:myself/forked.git (push) upstream git@github.com:owner/repo.git (fetch) upstream git@github.com:owner/repo.git (push)</code></pre> Get the last changes in your project (not necessary if you just forked the project). (master)$ git fetch upstream master (master)$ git merge upstream/master</code></pre> Create a new branch</li> </ul> (master)$ git checkout -b new-branch</code></pre> Once you're done, let’s create a PR! (new-branch)$ git add . # Add to git your changes (new-branch)$ git commit -m ‘Type the commit message’ (new-branch)$ git push origin new-branch # Push in forked & origin</code></pre> If you get errors trying to push your last changes, add your SSH credentials</li> </ul> (master)$ git remote set-url origin git@github.com:myself/forked.git</code></pre>That's all!</h3> If your changes (or someone else’s) have been merged in the origin, you need to run fetch upstream master and git merge upstream/master in master to be up-to-date! </blockquote> Summary</h2> # Synchronize your local repository to the original one # Need to run only once the first time git remote add upstream git@github.com/owner/repo.git # Get all changes from sync project into upstream branch git fetch upstream master # Merge upstream branch into your current branch git merge upstream/master</code></pre></div> Reference</h2> Syncing a fork | GitHub doc</a></li> Learn Git commands | GitExplorer</a></li> Git Tips | Oh Shit, Git!?!</a></li> </ul> Testing with Test Doubles? 2020-06-11T00:00:00+00:00 Test Doubles</h2> A Test Double is an object that can stand-in for a real object in a test, similar to how a stunt double stands in for an actor in a movie. As I wrote in "The importance of the Tests in our Software"</a>, there are several types of tests. They are also known as Test Doubles instead of "Mocks". The five types of Test Doubles are:</h3> Dummy: A dummy is passed around but never actually used. It exists only to satisfy a parameter requirement. If your test inspects it, it stops being a dummy</li> Stub: A stub provides predefined responses to calls made during the test. It doesn’t care how it’s used; it just returns canned data</li> Spy: A spy records information about how it was used (for example, whether a method was called, with what arguments, and how many times). The test inspects the spy afterward</li> Mock: A mock defines expectations up front about how it should be used and will fail automatically if those expectations aren’t met. The verification is built into the mock itself</li> Fake: A fake is a working implementation of the interface, but simplified. It behaves realistically enough to run tests, but isn’t suitable for production (eg: in-memory database)</li> </ul> The snippets are a pseudo-language based on a mix of PHP & Java. The idea is to make it understandable to everyone familiar with OOP. </blockquote> Dummy</h2> The dummies are objects that our SUT depends on, but they are never used. We don't care about them because they are irrelevant to the test scope. Let's imagine we have a service with a dependency that is irrelevant in the current test. We can perform something similar to the following snippet: final class Service { public final String OUTPUT = 'something'; public function format(dependency: Dependency?): String { // 'dependency' won't interfere in the expected result. return self::OUTPUT; } } final class ServiceTest extends TestCase { public function testFormat(): void { // Notice as the parameter is irrelevant. String result = (new Service()).format(null); self.assertSame(Service::OUTPUT, result); } }</code></pre>Stub</h2> A stub is an object which returns fake data. Let's imagine our service depends on a user model, then the service does something, and finally, it returns the user's UUID. We can create a stub object with fake values to assert the service works as expected. final class Service { public function doSomething(user: UserModelInterface): Int { /* Do things */ return user.uuid; } }</code></pre> To test this service, we can create a stub of the user and check if the response is what we were expecting. final class ServiceTest extends TestCase { public function testDoSomething(): void { // The service needs a implementation from `UserModelInterface`. String uuid = (new Service()).doSomething(new UserStub()); self.assertStringContainsString('0000-000-000-00001', uuid); } } interface UserModelInterface { public function getUuid(): String; } final class UserStub implements UserModelInterface { public function getUuid(): String { return '0000-000-000-00001'; } }</code></pre>Spy</h2> A test spy is an object capable of capturing indirect output and providing indirect input as needed. The indirect output is something we cannot directly observe. We can achieve that by extending the original class and saving the function params as class arguments. In the following snippet, we can know exactly how many times the log() method has been called, as well as the content of the messages. The point of this spy is to have much more knowledge of the internal object state in exchange for deeper coupling, which could be problematic in the future because it makes our tests more fragile. interface LoggerInterface { public function log(message: String): void; } final class LoggerSpy implements LoggerInterface { public Array<String> messages = []; public function log(message: String): void { this.messages.add(message); } } final class UserNotifier { public function __construct( private LoggerInterface logger, ) {} public function registerUser(user: UserModelInterface): void { this.logger.log("Notifying the user: {user.name()}"); // ... } }</code></pre> The following would be the implementation of the spy in a test: final class UserNotifierTest extends TestCase { public function testLogMessage(): void { LoggerSpy logger = new LoggerSpy(); UserNotifier notifier = new UserNotifier(logger); User user = new User(name: 'Jesus'); notifier.registerUser(user); self.assertStringContainsString( "Notifying the user: Jesus", logger.messages.firt() ); } }</code></pre>Mock</h2> A mock is an object that is capable of controlling both indirect input and output, and it has a mechanism for automatic assertion of expectations and results. The key difference between a mock and a stub is that a mock verifies behavior: it sets expectations about how the collaborator should be used (which methods are called, how many times, with what arguments) and the test fails if those expectations aren't met. Imagine we have a PaymentService</code> that processes payments and must notify the user via email after a successful payment. We want to verify that the notification is actually sent. interface NotificationServiceInterface { public function sendEmail(to: String, subject: String, body: String): void; } final class PaymentService { public function __construct( private NotificationServiceInterface notifier, ) {} public function processPayment(user: User, amount: Float): void { // Process the payment... // Notify the user this.notifier.sendEmail( user.email(), "Payment Confirmed", "Your payment of {amount} has been processed." ); } }</code></pre> In this test, we use a mock to verify that sendEmail()</code> is called exactly once with the expected arguments. If the method isn't called, or is called with wrong arguments, the test fails: final class PaymentServiceTest extends TestCase { public function testProcessPaymentSendsNotification(): void { User user = new User(email: 'jesus@example.com'); MockNotificationService notifier = this.createMock(NotificationServiceInterface::class); notifier .expects(this.once()) // Expectation: must be called exactly once! .method('sendEmail') .with( 'jesus@example.com', 'Payment Confirmed', this.stringContains('100.00') ); PaymentService service = new PaymentService(notifier); service.processPayment(user, 100.00); // No assertion needed! The mock itself verifies the expectation. // If sendEmail() wasn't called (or called incorrectly), the test fails. } }</code></pre> Notice that unlike stubs (which just return fake data), mocks verify interactions. The expects(this.once())</code> sets up an expectation that will be automatically verified when the test ends. This is powerful for testing side effects like sending emails, logging, or calling external services. </blockquote> Fake</h2> A fake is a simpler implementation of real objects. Fakes are used when we want to test an infrastructural class, in other words, fakes are for the classes which are beyond our application limit (repositories or queues, for example). As you can observe in the first picture (the diagram), a fake is not in the hierarchical line within the dummy, stub, spy or mock. This is because a fake can behave like a dummy, stub, spy or mock for our concrete use case. interface UserRepositoryInterface { public function getUserById(uuid: String): User; } final class FakeUserRepository implements UserRepositoryInterface { public function getUserById(uuid: String): UserModel { return new User(uuid, 'Jesus', "['ADMIN_ROLE']"); } }</code></pre> So, when we use this fake repository, we will receive a stub User. Final thoughts</h3> We must know the scope of the code we are going to test to get coupled as less as possible. That means if we have to pick a test double, first, we must know if the test is within our boundaries or not, if not, a fake is the best option, otherwise, my recommendation is to pick the corresponding test with the least knowledge as possible: dummy, stub, spy or mock (in that order). </div> References</h2> Best practices — Testing | Chemaclass Github</a></li> A better PHP testing experience | Matthias Noback</a></li> All about Mocking with PHPUnit | TutsPlus</a></li> The Little Mocker | Clean Coder</a></li> Testing on the Toilet | Google Testing Blog</a></li> TestDouble | Martin Fowler</a></li> GivenWhenThen | Martin Fowler</a></li> </ul> Why you should not use Reflection when testing 2020-04-03T00:00:00+00:00 It causes bugs when refactoring due to the high coupling</h2> When we use reflection, our tests get too fragile, we are allowing our tests to know so much information about the real implementation. We need to hardcode the method name, and we are coupling our test method to the production code. Furthermore, we need to write a lot about boilerplate to test a simple method. Question: I need to get at least 80% of code coverage, how can I get it without the Reflection class?</li> Answer: You should test ONLY your public methods, and depending on the variables we pass, we should reach all the possible paths.</li> </ul> So, we do not need to test the private methods per se; they are called indirectly from our public functions. Comparison between standard and Reflection tests</h2> final class Addition { public function simpleOperation(int $number1, int $number2): int { return $number1 + $number2; } } final class Operation { public function addition(int $number1, int $number2): int { return (new Addition())->simpleOperation($number1, $number2); } } final class OperationTest { // Without Reflection. public function testSimpleOperationWithoutReflection(): void { $operation = new Operation(); $this->assertSame(4, $operation->addition(2, 2)); } // With Reflection. public function testSimpleOperationWithReflection(): void { $addition = $this->createPartialMock(Addition::class, [ 'simpleOperation', ]); $result = 2 + 2; $addition ->expects($this->once()) ->method('simpleOperation') ->willReturn($result); $operation = new \ReflectionClass(Operation::class); $reflection = $operation->invoke($addition); $this->assertSame($result, $reflection->addition()); } }</code></pre> What would happen if we modified the simpleOperation()</code> method from the Addition class to the following, and we run the tests? final class Addition { public function simpleOperation(int $number1, int $number2): int { return $number1 - $number2; } }</code></pre> Question: Will the ‘standard’ fail? What about the Reflection one?</li> Answer: The standard will fail because we expect 4 as a result, but we got a 0. However, the reflection will pass, because we are not focusing on the real implementation, we are creating a false positive which can be dangerous.</li> </ul> Dealing with some problems when not using Reflection</h2> Let me show you a more realistic example (idea from PHPTheRightWay</a>): final readonly class Vehicle { public string $model; public int $price; public function __construct(string $model) { $this->model = $model; $this->price = random_int(1000, 3000); } }</code></pre> To test the vehicle’s model is easy, but what about the price? public function testModel(): void { $model = 'Seat'; $vehicle = new Vehicle($model); $this->assertSame($model, $vehicle->model()); } public function testPrice(): void { $model = 'Seat'; $vehicle = new Vehicle($model); $this->assertSame( ¿¿?? , $vehicle->price()); }</code></pre> One possible solution could be using the Reflection class to be able to set explicitly the price like: public function testGetPrice(): void { /** @var Vehicle|MockObject $vehicle */ $vehicle = $this->createPartialMock(Vehicle::class, []); $reflection = new \ReflectionProperty(Vehicle::class, 'price'); $reflection->setAccessible(true); $price = 200; $reflection->setValue($vehicle, $price); $this->assertSame($price, $vehicle->price()); }</code></pre> But our Vehicle class is final, so we cannot perform this test, also, we said we shouldn’t use the Reflection class, so, probably we are doing something wrong in this class (TIP: you should make final your classes by default 😉). Question: So what is the problem here?</li> Answer: The problem here is that we are performing an action inside the class (on the constructor) to which we do not have access from the outside.</li> </ul> One solution could be to inject the value in the constructor like: final readonly class Vehicle { public function __construct( public string $model, public int $price, ) { } }</code></pre> And when we want to create this class, we could pass the final price as: $vehiclePrice = random_int(1000, 3000); $vehicle = new Vehicle(‘Seat’, $vehiclePrice);</code></pre> So, our price test could be like: public function testPrice(): void { $price = 200; $vehicle = new Vehicle('foo', $price); $this->assertSame($price, $vehicle->price()); }</code></pre> I don’t recommend using the Reflection class anywhere in your code unless you are very aware of what you are doing. Usually, there are alternative implementations to what you want to achieve without using it. Additionally, defining our classes as final</code> helps us to have a better design, not only because it forbid us the use of Reflection, but also it prevents us from mocking our business logic, which is good. The importance of tests in our software 2020-03-20T00:00:00+00:00 Writing tests is one of the most effective ways to verify your software works as intended. Tests check that each part of your program behaves correctly under different conditions, acting as a safety net that catches issues before they reach production. Verification and Early Detection</h3> Tests verify correctness and catch bugs before they reach production. A bug caught during development takes minutes to fix, while the same bug in production can take days and cost far more. public function test_applies_discount_correctly(): void { $result = $calculator->calculateDiscount(100, 20); self::assertSame(80, $result); }</code></pre> This simple test catches calculation errors, edge cases, and regressions immediately. Without it, bugs slip through to QA or production where they're exponentially more expensive to fix. Safe Refactoring</h3> Tests give you confidence to improve code structure without breaking functionality. Without tests, refactoring is risky and developers avoid it, leading to code degradation over time. // You can safely refactor this: return $price - ($price * $percentage / 100); // To this: return $price * (100 - $percentage) / 100; // Tests ensure the behavior remains identical</code></pre> When your test suite passes, you know the refactoring didn't introduce bugs. This enables continuous improvement of the codebase. Better Design and Documentation</h3> Writing testable code forces you to break code into smaller, independent components with clear responsibilities. Tests also serve as executable documentation showing how the code should be used. public function test_order_workflow(): void { $order = new Order($items); $order->applyDiscount(20); $order->addShipping(10); self::assertSame(90, $order->total()); }</code></pre> This test documents the expected workflow and demonstrates the API. Anyone reading it understands how to use the Order</code> class without digging through implementation details. Common Mistakes When Writing Tests</h2> Testing Implementation Details</h3> One of the most common mistakes is testing how something works instead of what it does. Tests should verify behavior, not implementation. If you refactor the internal logic without changing the public API, your tests shouldn't break. // BAD - Testing implementation details public function test_uses_percentage_calculation(): void { $calculator = $this->createPartialMock(PriceCalculator::class, ['getPercentageValue']); $calculator->expects($this->once())->method('getPercentageValue'); $calculator->calculateDiscount(100, 20); // This test breaks when you refactor the internal logic } // GOOD - Testing behavior public function test_applies_discount_correctly(): void { $calculator = new PriceCalculator(); $result = $calculator->calculateDiscount(100, 20); self::assertSame(80, $result); // This test only cares about the result, not how it's calculated }</code></pre> The first test will break if you change the internal implementation, even if the behavior remains correct. The second test only verifies the outcome, making it more maintainable. Creating Brittle Tests</h3> Tests that break whenever you make minor changes are worse than no tests at all. They slow down development and eventually get ignored or deleted. Common causes include: Hardcoding values that should be dynamic</li> Testing private methods directly</li> Over-mocking dependencies</li> Asserting on exact string matches instead of patterns</li> </ul> Not Testing the Right Things</h3> Some developers chase code coverage metrics without thinking about what they're actually testing. You don't need to test framework code, simple getters/setters, or language features. Focus on business logic, edge cases, and error handling. </div> Tests are not just about finding bugs. They're about designing better software, maintaining confidence in your codebase, and reducing the cost of change over time. The initial investment in writing tests pays off in the long run through fewer production incidents, easier maintenance, and faster development cycles.

References</h2>

Composer Repositories | Composer</a></li>
Loading a package from a VCS repository | Composer</a></li> </ul>

References</h2>

Git Rebase | Git</a></li>
Git rebase --onto an overview | Woman on Rails</a></li> </ul>

Resources:</h2>

Psalm | Array Shapes</a></li>
PHPStan | PHPDoc Types</a></li> </ul>

Reference:</h2>

Symfony — Service Container</a></li>
Laravel — Service Container</a></li>
Gacela — Bindings</a></li> </ul>

Queries</h3>
The queries are the GET</em> requests. That means you can only fetch</strong> data.</p>
</p>

Sorting Lists 🧵</h2>

Sorting Maps 🗺️</h2>

Reference</h2>

Array Sorting | PHP Doc</a></li>
PHP Sorting Arrays | W3Schools</a></li>
Difference between Set, List and Map in Java | Java67</a></li> </ul>

https://phel-lang.org/</a></h2> </blockquote>

Reference</h2>

Mutable vs Immutable Objects | InterviewCake</a></li>
From Impure to Pure Code | Tommi Kaikkonen</a></li>
Entity vs DTO | StackOverflow</a></li> </ul>

Reference</h2>

Syncing a fork | GitHub doc</a></li>
Learn Git commands | GitExplorer</a></li>
Git Tips | Oh Shit, Git!?!</a></li> </ul>

Jesus Valera Reales

Anemic vs Rich Domain Model

Link Local Packages using Composer

Avoid using array_merge within a loop

Pros and cons:</h4>

Works on all PHP versions</li>
No risk of warning if `$someObject->getUsers()</code> returns an empty array (the inner loop is not executed)</li>`
`Best memory performance for large datasets</li>`
`Slightly more verbose</li> </ul>`

Jobs (Queues) vs. Events

Git: Reset last commit

Git reset</h2>
The `git reset</code> command moves the HEAD</code> pointer to a previous point, removing intermediate commits.</p>`

New PHP 8.4 array functions

Git Rebase onto

The testing pyramid

Three dots in PHP

PhpStorm tricks ✨

Functional Tests

Parlamento de la batalla del 3 de Mayo

How to create a global .gitignore file

Declaring array structures in PHP

ORM: Data Mapper vs Active Record

How does the Service Container work?

Why and How to decouple your classes

A brief introduction to GraphQL

Sorting functions in PHP

Functional Programming in JavaScript

Functional Programming with Phel 🐘

Immutability, the good way

Getting started with Open Source Software

Testing with Test Doubles?

Why you should not use Reflection when testing

The importance of tests in our software

Jesus Valera Reales

Anemic vs Rich Domain Model

Link Local Packages using Composer

Basic Configuration</h2> Let's say you have the following directory structure:</p>

References</h2> Composer Repositories | Composer</a></li> Loading a package from a VCS repository | Composer</a></li> </ul>

Avoid using array_merge within a loop

Pros and cons:</h4> Works on all PHP versions</li> No risk of warning if $someObject->getUsers()</code> returns an empty array (the inner loop is not executed)</li> Best memory performance for large datasets</li> Slightly more verbose</li> </ul>

Jobs (Queues) vs. Events

Git: Reset last commit

Git reset</h2> The git reset</code> command moves the HEAD</code> pointer to a previous point, removing intermediate commits.</p>

New PHP 8.4 array functions

Imperative vs Declarative</h2> There are two ways of applying transformations to arrays in PHP.</p> While in imperative</strong> way we tell step by step how</strong> to get,</li>

Git Rebase onto

Syntax</h3> git</span> rebase</span> --onto</span> <</span>new-bas</span>e</span>> <</span>upstrea</span>m</span>> <</span>branc</span>h</span>></span></span></code></pre>Rebasing a Subset of Commits</h2> When you want to rebase a subset of commits from your branch onto another branch:</p>

Rebasing a Subset of Commits</h2> When you want to rebase a subset of commits from your branch onto another branch:</p>

References</h2> Git Rebase | Git</a></li> Git rebase --onto an overview | Woman on Rails</a></li> </ul>

The testing pyramid

Three dots in PHP

PhpStorm tricks ✨

Plugins</h2> Plugins extend what the IDE can do.</p>

Functional Tests

Parlamento de la batalla del 3 de Mayo

How to create a global .gitignore file

Declaring array structures in PHP

List Shape</h2> We use lists when we have an array of elements with the same type. We use angled brackets</strong> to declare the types of the key and the value: array<TKey, TValue></code>.</p>

Resources:</h2> Psalm | Array Shapes</a></li> PHPStan | PHPDoc Types</a></li> </ul>

ORM: Data Mapper vs Active Record

How does the Service Container work?

Symfony</h2> We can define our services as php</code> or yaml</code> file extension (you can define this configuration directly in the src/Kernel.php</code> file).</p>

Laravel</h2> In Laravel, however, you can do this in the AppServiceProvider</code> class.</p>

Why and How to decouple your classes

A brief introduction to GraphQL

Queries</h3> The queries are the GET</em> requests. That means you can only fetch</strong> data.</p> </p>

Sorting functions in PHP

Map (also known as Dictionaries)</h2> A map is an unordered collection. Each element is composed of a key and a value. It is not possible to have the same key more than once.</p>

Sorting Lists 🧵</h2>

Sorting Maps 🗺️</h2>

Reference</h2> Array Sorting | PHP Doc</a></li> PHP Sorting Arrays | W3Schools</a></li> Difference between Set, List and Map in Java | Java67</a></li> </ul>

Functional Programming in JavaScript

Map 🗺</h2> We use map()</em> whenever we want to map the values into other values producing a new array.</p>

Functional Programming with Phel 🐘

Imperative vs Declarative</h2> Let’s start with the typical factorial</em> example to explain the differences between those two terms in the programming world.</p>

Immutability, the good way

Getting started with Open Source Software

Reference</h2> Syncing a fork | GitHub doc</a></li> Learn Git commands | GitExplorer</a></li> Git Tips | Oh Shit, Git!?!</a></li> </ul>

Testing with Test Doubles?

Test Doubles</h2> A Test Double is an object that can stand-in for a real object in a test, similar to how a stunt double stands in for an actor in a movie.</p>

Stub</h2> A stub is an object which returns fake data.</p> Let's imagine our service depends on a user model, then the service does something, and finally, it returns the user's UUID. We can create a stub object with fake values to assert the service works as expected.</p>

Why you should not use Reflection when testing

The importance of tests in our software

References</h2>

Composer Repositories | Composer</a></li>
Loading a package from a VCS repository | Composer</a></li> </ul>

Pros and cons:</h4>

Works on all PHP versions</li>
No risk of warning if `$someObject->getUsers()</code> returns an empty array (the inner loop is not executed)</li>`
`Best memory performance for large datasets</li>`
`Slightly more verbose</li> </ul>`

Git reset</h2>
The `git reset</code> command moves the HEAD</code> pointer to a previous point, removing intermediate commits.</p>`

References</h2>

Git Rebase | Git</a></li>
Git rebase --onto an overview | Woman on Rails</a></li> </ul>

Resources:</h2>

Psalm | Array Shapes</a></li>
PHPStan | PHPDoc Types</a></li> </ul>

Queries</h3>
The queries are the GET</em> requests. That means you can only fetch</strong> data.</p>
</p>

Reference</h2>

Array Sorting | PHP Doc</a></li>
PHP Sorting Arrays | W3Schools</a></li>
Difference between Set, List and Map in Java | Java67</a></li> </ul>

Reference</h2>

Syncing a fork | GitHub doc</a></li>
Learn Git commands | GitExplorer</a></li>
Git Tips | Oh Shit, Git!?!</a></li> </ul>