—

Let’s imagine that we’re working on e-commerce platform. Each user can sold maximum 100 items How to do it properly? How to introduce domain limit on doctrine relationships? How can I introduce it? Let’s use rich entities (trying to follow Domain-Driven-Design and Test-Driven-Development rules):

<?php

use Doctrine\Common\Collections\ArrayCollection;
use Doctrine\Common\Collections\Collection;
use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity]
#[ORM\Table(name: 'users')]
class User
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column(type: 'integer')]
    private int|null $id = null;

    #[ORM\Column(type: 'string', length: 255)]
    private string $name;

    /** @var Collection<int, Item> */
    #[ORM\OneToOne(inversedBy: 'createdBy', targetEntity: Item::class)]
    private Collection $items;

    public function __construct(string $name)
    {
        $this->name = $name;
        $this->items = new ArrayCollection();
    }

    public function addItem(Item $item): void
    {
        $this->items[] = $item;
    }

    public function getItems(): Collection
    {
        return $this->items;
    }
}

and item:

<?php

use Doctrine\ORM\Mapping as ORM;

class Item
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column(type: 'integer')]
    private int|null $id = null;

    #[ORM\Column(type: 'string')]
    private string $description;

    #[ORM\Column(type: 'integer')]
    private int $price;

    #[ORM\ManyToOne(targetEntity: User::class, inversedBy: 'items')]
    private User $createdBy;

    public function __construct(string $description, int $price)
    {

    }

    public function setCreator(User $createdBy): void
    {
        $createdBy->addItem($this);
        $this->createdBy = $createdBy;
    }
}

And basic test for that:

<?php

namespace tests;

use Item;
use PHPUnit\Framework\TestCase;
use User;

final class ItemsLimitPerUserTest extends TestCase
{
    public function testItemsLimitPerUser(): void
    {
        $user = new User('John');
        $itemA = new Item('My aswesome item A', 20);
        $itemB = new Item('My aswesome item B', 20);
        $itemC = new Item('My aswesome item C', 20);

        $itemA->setCreator($user);
        $itemB->setCreator($user);
        $itemC->setCreator($user);

        $this->assertEquals(
            3,
            $user->getItems()->count()
        );
    }
}

Now let’s add new test case that adding fourth item will fail (let’s set limit = 3). Basically we will implement items limit per user logic.

public function testItemsLimitPerUserIsMet(): void
{
    $user = new User('John');
    $itemA = new Item('My aswesome item A', 20);
    $itemB = new Item('My aswesome item B', 20);
    $itemC = new Item('My aswesome item C', 20);
    $itemD = new Item('My aswesome item D', 20);

    $itemA->setCreator($user);
    $itemB->setCreator($user);
    $itemC->setCreator($user);

    try {
        $itemD->setCreator($user);
    } catch (Exception $exception) {
        $this->assertInstanceOf(LimitMetException::class, $exception);
    }

    $this->assertEquals(
        3,
        $user->getItems()->count()
    );
}

Which obviously will fail for that moment:

~/Development/doctrine-playground$ ./vendor/bin/phpunit tests
PHPUnit 11.5.6 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.2.27

.F                                                                  2 / 2 (100%)

Time: 00:00.007, Memory: 8.00 MB

There was 1 failure:

1) tests\ItemsLimitPerUserTest::testItemsLimitPerUserIsMet
Failed asserting that 4 matches expected 3.

/home/adt/Development/doctrine-playground/tests/ItemsLimitPerUserTest.php:48

FAILURES!
Tests: 2, Assertions: 2, Failures: 1.

Now let’s try to implement this requirement (git diff):

diff --git a/src/User.php b/src/User.php
index ec83b61..d8dcde8 100644
--- a/src/User.php
+++ b/src/User.php
@@ -8,6 +8,8 @@ use Doctrine\ORM\Mapping as ORM;
 #[ORM\Table(name: 'users')]
 class User
 {
+    public const ITEMS_LIMIT = 3;
+
     #[ORM\Id]
     #[ORM\GeneratedValue]
     #[ORM\Column(type: 'integer')]
@@ -26,8 +28,15 @@ class User
         $this->items = new ArrayCollection();
     }
 
+    /**
+     * @throws LimitMetException
+     */
     public function addItem(Item $item): void
     {
+        if ($this->items->count() >= self::ITEMS_LIMIT) {
+            throw new LimitMetException();
+        }
+
         $this->items[] = $item;
     }

Now, all tests are passing:

~/Development/doctrine-playground$ ./vendor/bin/phpunit tests
PHPUnit 11.5.6 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.2.27

..                                                                  2 / 2 (100%)

Time: 00:00.003, Memory: 8.00 MB

OK (2 tests, 3 assertions)

But we have one issue, during adding new item doctrine by default will load whole items collection. It’s not good to load it only to do the count. For that we can use Extra lazy feature from Doctrine ORM:

    /** @var Collection<int, Item> */
    #[ORM\OneToOne(inversedBy: 'createdBy', targetEntity: Item::class, fetch: 'EXTRA_LAZY')]
    private Collection $items;

git diff:

diff --git a/src/User.php b/src/User.php
index d8dcde8..194fe67 100644
--- a/src/User.php
+++ b/src/User.php
@@ -19,7 +19,7 @@ class User
     private string $name;
 
     /** @var Collection<int, Item> */
-    #[ORM\OneToOne(inversedBy: 'createdBy', targetEntity: Item::class)]
+    #[ORM\OneToOne(inversedBy: 'createdBy', targetEntity: Item::class, fetch: 'EXTRA_LAZY')]
     private Collection $items;

Now doctrine won’t load all entities into memory to simply count them, it will do dedicate count SQL query. In that way you can introduce limit for really large entity collections and avoid hitting memory limit and performance issues.

The post How to do performant count of child entities in rich entity with doctrine? appeared first on Angry dev thoughts.

The post We should be able to write test for every bug reported showcasing bug appeared first on Angry dev thoughts.

What Are Story Points?

In Agile methodologies, story points are used to estimate the effort, complexity, and time involved in completing a user story or task. These estimates are relative rather than absolute, meaning they don’t correspond directly to hours or days. The purpose of story points is to give teams a sense of how much work is involved in a user story compared to other stories.

Agile story points help determine how much work a team can realistically take on in a sprint or iteration. The scale is subjective, allowing teams to assign points based on complexity rather than exact time estimates. This method fosters collaboration, avoids overcommitment, and helps teams make informed decisions about the work they can handle during a sprint.

Why Fibonacci for Story Points?

The Fibonacci sequence is a series of numbers where each number is the sum of the two preceding ones: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, and so on. Using the Fibonacci sequence for Agile story points is a popular choice because it effectively captures the increasing uncertainty and complexity that comes with larger tasks. But why Fibonacci for story points specifically? Here are some key reasons:

1. Reflects Exponential Growth in Complexity

As tasks get larger or more complex, the effort required to complete them doesn’t just grow linearly—it grows exponentially. Fibonacci numbers grow at an increasing rate, which is a natural fit for capturing the increasing uncertainty and effort required for larger tasks. As a result, Fibonacci story points allow teams to better differentiate between simple and complex tasks.

2. Prevents Over-Precision

One of the drawbacks of estimating in hours or days is the temptation to be overly precise. In Agile, we aim to avoid false precision by acknowledging that the exact time it takes to complete a task can vary. Fibonacci numbers, being relatively large, help teams focus on estimating in terms of relative effort rather than worrying about precise time measurements. This is especially important in Agile environments, where tasks are often more complex and involve a high degree of uncertainty.

3. Simplifies Estimation

The Fibonacci sequence provides a simple and intuitive scale for estimating tasks. For teams new to Agile story points Fibonacci or estimating in general, it’s easier to think in terms of broad categories like 3, 5, 8, or 13 story points rather than trying to estimate down to the hour. The simplicity of Fibonacci numbers helps reduce analysis paralysis and speeds up the estimation process during Sprint Planning.

4. Captures Uncertainty

The increasing gaps between Fibonacci numbers naturally express the uncertainty and complexity associated with larger tasks. As the size of a task grows, so does the uncertainty, and the Fibonacci sequence reflects this in a way that linear scales (like 1, 2, 3, 4, 5) do not. This makes it easier to estimate larger tasks with a higher degree of flexibility.

Fibonacci Story Points to Days

One common question that arises when using Fibonacci story points is how to translate these points into days or hours. The Fibonacci scale is deliberately abstract, designed to measure relative complexity rather than specific time durations. As such, Fibonacci story points to days is not a direct conversion. For example, a user story assigned 5 points might not correspond to exactly 5 days of work. Instead, it represents a task that is moderately complex compared to a simpler 3-point task.

However, over time, as teams become more experienced with their velocity (the amount of work they can complete in a sprint), they may begin to correlate certain point values with time. For example:

• A 1-point story might take a day or less, depending on the team’s velocity.
• A 5-point story might take 2-3 days.
• An 8-point story could take several days or even the entire sprint.

It’s important to remember that story points should never be viewed as direct time estimates. The goal is to measure relative effort and complexity, not precise hours. However, as teams mature, they can observe patterns that help them predict how many story points they can tackle in a sprint, which indirectly reflects how much time those points represent in real-world terms.

How Fibonacci Story Points Work in Agile

In Agile, particularly in Scrum, the team comes together during Sprint Planning to estimate user stories using story points. When using the Fibonacci sequence for estimation, the team will discuss the complexity of each user story and agree on a point value based on their understanding of the effort involved. A common technique for this is Planning Poker, where team members simultaneously reveal their estimates, and discrepancies are discussed until a consensus is reached.

The typical Fibonacci scale used in Agile story point estimation looks like this:

• 1 Point: Simple, straightforward task with minimal complexity.
• 2 Points: Slightly more effort, but still a manageable task.
• 3 Points: Moderate complexity, requiring some effort but not overwhelming.
• 5 Points: A task with noticeable complexity, but still feasible within a sprint.
• 8 Points: Complex tasks, requiring significant effort and time.
• 13 Points: Very large tasks, possibly spanning multiple sprints.

As the Fibonacci sequence progresses, the gaps between the numbers grow larger, reflecting the increased uncertainty and complexity. This scaling helps teams more easily differentiate between simpler and more complicated tasks without getting bogged down in detailed estimations.

Advantages of Using Fibonacci for Story Points

1. Increased Estimation Accuracy

The exponential nature of Fibonacci numbers more accurately reflects the increasing complexity of larger tasks. As tasks grow more complicated, estimating their effort becomes more difficult. Fibonacci story points provide a practical way to manage this increasing uncertainty.

2. Faster Estimation Process

Teams can estimate user stories quickly without getting bogged down in specifics. The Fibonacci sequence provides enough differentiation for most tasks without overcomplicating the process. The simplicity of the system accelerates the decision-making during Sprint Planning.

3. Improved Collaboration

Using Fibonacci story points encourages team discussions about the scope of each task, helping ensure a shared understanding. If estimates vary significantly between team members, it leads to valuable conversations that clarify ambiguities and improve team alignment.

4. Facilitates Task Breakdown

When tasks are estimated at higher point values, it often signals to the team that the task is too large and should be broken down further. This keeps the work manageable and allows teams to better gauge the amount of work they can complete in a sprint.

Challenges and Considerations

While Agile story points Fibonacci offers many benefits, it does come with some challenges:

• Subjectivity: Story point estimation can be subjective, and different team members might have varying views on how difficult a task is. Clear communication and team alignment are essential to ensure accurate estimates.
• Difficulty in Transitioning: Teams new to Agile or those unfamiliar with Fibonacci for story points may find it difficult to estimate accurately at first. Over time, the team will learn to refine their estimates based on experience.
• Scaling: For very large projects, the Fibonacci scale might need to be adjusted, especially if tasks regularly reach values like 21 or 34 points. Some teams extend the Fibonacci sequence beyond 13 points to accommodate larger estimates.

Conclusion

Why Fibonacci for story points? The Fibonacci sequence provides an intuitive, scalable, and effective way to estimate effort in Agile software development. It captures the increasing complexity and uncertainty that comes with larger tasks, while avoiding the pitfalls of over-precision and encouraging team collaboration. While Fibonacci story points to days doesn’t provide a direct conversion, the system helps teams understand the relative complexity of tasks, which ultimately leads to more informed Sprint Planning and better-managed workloads. By incorporating Fibonacci numbers into the Agile process, teams can enhance their estimation accuracy, improve communication, and ensure a smoother, more predictable development process.

The post Why Fibonacci for Story Points in Agile Software Development appeared first on Angry dev thoughts.

The post Non technical project manager/product manager of IT projects is scam appeared first on Angry dev thoughts.

In general I don’t think so there should be auto rules, like new service = new microservice.

The post Starting development of new feature by creating new micro service does not make sense in most cases appeared first on Angry dev thoughts.

 session.cookie_lifetime int

session.cookie_lifetime specifies the lifetime of the cookie in seconds which is sent to the browser. The value 0 means “until the browser is closed.” Defaults to 0.

https://www.php.net/manual/en/session.configuration.php#ini.session.cookie-lifetime

 session.gc_maxlifetime int 

session.gc_maxlifetime specifies the number of seconds after which data will be seen as ‘garbage’ and potentially cleaned up. Garbage collection may occur during session start (depending on session.gc_probability and session.gc_divisor). Defaults to 1440 (24 minutes).

https://www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime

Sometimes I see that people set PHP session cookie lifetime however it does not increase security and only annoys people. Like if set expiration to 24h then when you logged on at 10 AM you will be logged out at 10 AM next day, no matter what.

The post How to make PHP session sticky/auto renew on last activity appeared first on Angry dev thoughts.

So, we should avoid interfaces with one implementation, right?

From my experience interfaces with one implementation should be avoided. I sometimes hear this explanations from people adding interface with one implementation:

• when I have inerfaces (even with one implementation) code is decoupled – seriously? Adding interfaces changes anything? In my opinion no. If there is need for coupling and there is coupling in real life then it probably should be depicted in the code.
• when I have inerfaces (even with one implementation) testing is easier – I can agree with that, however when I saw code people stating that in tests I did not see implementation of this interface Like RepositoryInterface and InMemoryRepository implements RepositoryInterface, and what they do is just creating another mock with mocking library
• when I have inerfaces (even with one implementation) when I will need second implementation it will be easier – happend zero times in my over 10 years experience. Usually abstraction that you will make based on one case won’t fit more cases. That is why I propose to wait with creating abstractions till you will be able to notice the pattern (at least 3 cases)
• when I have inerfaces (even with one implementation) it isolates parts of the system – I can sometimes agree, but usually what I see is the interface that contains whole public API of given class and what is more is changed with the same pace as given concrete class (bruh)

So what’s wrong with interface with one implementation?

In my opinion the less code we write the better, so I don’t like interfaces with one implementation because:

• they make navigation trough code harder,
• you have more code,
• they hide real dependency even if there is only one implementation

So when to use interface?

From my experience creating abstraction is really hard. That is why I advice to wait till more cases, so you can notice and validate pattern. In general I think that creating interfaces with one implementation is misinterpeetation of DIP from SOLID, here is quote from Uncle Bob:

The need to mock every class interaction forces an explosion of polymorphic interfaces. In statically typed languages like Java, that means the creation of lots of extra interface classes whose sole purpose is to allow mocking. This is over-abstraction and the dreaded “design damage”.

https://blog.cleancoder.com/uncle-bob/2014/05/10/WhenToMock.html

The post I don’t believe dependency inversion princpile makes sense in most cases appeared first on Angry dev thoughts.

I think it is sometimes proposed and forced by non-tech scrum masters, because they think it needs to be that way. It annoys me. It does not have to be like that.

I really prefer to have a linear scale (with step 1), like:

• 1 story point – around 1 day of development
• 2 story points – around 2 days of development
• 3 story points – around 3 days of development
• 4 story points – around 4 days of development

etc. In that way you can really see how much work will fit into sprit.

Do not estimate bugs

Sometimes I hear do not estimate bugs – and I always think WTF? Without estimating bugs you’re not able to asses how many of them you are able to take into sprint. Something different is to fix bug that wrong image is shown and something different is to track why wrong price is calculated at the end of quarter. So it should be visible, how much do you expect them to differ. In my opinion esimating bugs is just fine

Average story points per sprint

With usage of story points constrained to values from fibonacci sequence you cannot do regular maths on that numbers. Why? Because they are not proportional. So using arithmetic mean will not give you reliable results. Probably you heard many times why this time we planned sprint using artiehmetic mean from pasts sprints and we still did not deliver all stories. Sounds familiar?

The post Estimating stories using story points with Fibonacci sequence doesn’t make sense. appeared first on Angry dev thoughts.

On the other hand when we have scrum master with deep software developement experience then I think this can be really valuable addition to the team. But of course if he/she in fact had a chance to feel problems that Scrum/Agile supposed to solve.

Non tech scrum master tends to ask and propose strange solutions, like:

• Use CRUD (create, read, update, delete) strategy to divide project in smaller tasks when whole tasks is about new read model…
• Avoid large tasks at all costs even without understanding that splitting given part does not make sens, make developing and testing harder

In addition non tech scrum master is usually the person that does not deliver any value at all and you can ask yourseflf what does a scrum master do whole day? That is way I much prefer to have scrum master with real experience in IT world and having two responsiblities, for example

• Being a developer + scrum master
• Being a software tester + scrum master

Not seperate role, when it is first time working in IT.

What is more non-tech scrum masters sometimes event don’t know scrum guide (14 pages…), and they trying to convince you something that even scrum guid does not mentions saying that’s it in scrum guide.

It was not a real scrum – does it sound familiar?

What is more I often hear that it was not real scrum. For me tools are for given purpose, we cannot do it something for sake of doing something. If it not works let’s not do it, instead of blindly following some rules. Yes it is worth to know them, but for me winning point is to know when to not use them, instead of using them all the time.

So, scrum is a scam?

I’m not saying that. But with implementation that scrum is lead by people who never experience problems that scrum is trying to solve then it won’t work. And it may be scam.

The post Non tech scrum master is a scam appeared first on Angry dev thoughts.

Finally, I don’t need to by annoyed by browsing through different plugins.

So, I don’t need plugin, which is good. You can find my sitemap here: https://angry-dev-thoughts.com/wp-sitemap.xml

The post How to add sitemap to WordPress? appeared first on Angry dev thoughts.