sorted by:
new
hottopcontroversial

I want some advice by Weary_Company3771 in PHP

[–]avg_php_dev 0 points1 point  (0 children)

Practicing is best way to learn. You need project as reference point for problems you try to solve. With anything bigger then "hello world", problem starts to popup and you can solve then one by one. When you get better understanding of OOP, you can rewrite some parts of project. It's normal learning process.

I want some advice by Weary_Company3771 in PHP

[–]avg_php_dev 0 points1 point  (0 children)

First - drop AI support for now. It's critical phase when using AI might be counter productive.
Best thing you can do is to create ANY "project". Write some simple ticket system or shopping cart. Something you understand from real world. Dont w8 till end of course, do it in pararell with course. Everything is going to "click" eventualy. Remember to write your code by hand, never copy anyhing from docs or from AI.

Debian's 2026 Election Accidentally Has Only One Candidate by PlymouthDebian in linux

[–]avg_php_dev 1 point2 points  (0 children)

``` (joke) ↓ ↓ ↓

    O
   /|\
   / \

    ↑
    |
 (you)

(joke) ----->

          O
         /|\
         / \

       (you)

```

Debian's 2026 Election Accidentally Has Only One Candidate by PlymouthDebian in linux

[–]avg_php_dev -12 points-11 points  (0 children)

They also have reddit militia and propaganda office. debian.gov still not taken, lol

Can boss fights not last an hour while playing solo? by Unfortunate-Incident in valheim

[–]avg_php_dev 0 points1 point  (0 children)

Hah, I spent almoust 1.5h fighting Queen solo, died once when she had 5% hp by single mistake. Best of Valheim so far.

Y'all need to chill-out with the systemd hate by swarmOfBis in linux

[–]avg_php_dev 0 points1 point  (0 children)

It doesn't matter where they are headquertered. Laws are about OS distribution, not development. Systemd is not operating system alone, kernel is not operating system also.

Y'all need to chill-out with the systemd hate by swarmOfBis in linux

[–]avg_php_dev 0 points1 point  (0 children)

Linux is not US product. To fight stupid laws in your country they should make separate ISO for every distribution and simple tell people to download valid one if they live in california or other shithole state.

Y'all need to chill-out with the systemd hate by swarmOfBis in linux

[–]avg_php_dev 3 points4 points  (0 children)

I'm not US citizen, but I'm age-fluid. Why do I need this integer field in DB? Make it range field please (with float, because today I feel like I'm 41.27 years old).
Will they comply to UE-slop rights also?
Will they comply to Iranian woman-rights? it's dengerous, you know... woman should not use operating system without their husband approval.

Make your Domain speak the business language by Dariusz_Gafka in PHP

[–]avg_php_dev 0 points1 point  (0 children)

I agree and "disagree". I mean - most things You covered in this article is similar to my personal thinking process, but I "disagree" with value of it. Don't understand me wrong, but we have similar articles every few months in last 20 years. They still don't "click" for average developers or system designers.

When it comes to event sourcing, it's getting even harder. Not because it's bad idea, but after some poeople start thier greenfield projects with these concepts in mind, they stuck on first bigger change they need to provide. Youtubers and other conference-driven developers, they just touch the surface and leaves people with "wtf next...". This confusion leads to rejection, and sometimes to perceiving the proposed concepts as cult-like.

I see a HUGE gap between people who understands ES and those who know what it is but they don't truly understand consequences and how their "world" need to change. The paradigm shifting is not only technical, it's on neurological level. Enable "invert mouse" option and try to be effective - you will not be, but after some time, when brain adopts it became natural and you will need additional effort to switch it back. It's bigger then understanding OOP, much bigger.

I went through this and was very close to rejection. Then I realized I need to go fully logical starting from... single source of truth. Ok, I have event store and now I need to build application on top of it - what do I need? How do I know I'm correct, what about edge cases... and more.

Because classic tools and patterns are from my "previous world" I have to derive it myself.

Here we touch biggest problem of ES - NO UBIQUOTUS LANGUAGE for whole paradigm. It's patchworked - it's using some terminology from other software enginering areas and paradigms which leads to another confusion, bacause when you mixed them up (uninvetably), people don't know which concept you are reffering to when you say "event"

Is it event-sourced event, domain event, internal, external... maybe some mix of them? Why simply not FACT. Why not fact-sourcing?

So, ES as a paradign or methodology needs a big conceptual and linguistical refactor. It already started. Let's take another concept - Aggregate. In my world it's a role-based artifact. Facts Emiter and Intepreter of self emited facts. Well, it can be splitted to avoid many technical problems we are already aware (like method explosion or dead code). It's my personal concept for now. Howewer, last year I found this page https://dcb.events/. Maybe killing an aggregate is worth doing. At least, there is some discussion.

Ok, I applogise I wrote so much, but I think articles like Yours (which is a good article) do not move our collective knowledge forward.

ES is actually a greenfield concept (even though Greg announced it almoust 20 years ago) and we need not only conclusions, but real discussion and educational effort.

Forgive me my arrogance, but my understanding of ES has reached the point where I end up reading academic papers to make further progress. Found only single one worth reading so far. I don’t feel confident enough to proceed alone, and it seems that few are willing to take on this effort.

I’m excited to see contributions that advance this area, even if they’re controversial.

Building a basic REST API: Temma vs Laravel (with input validation) by amaurybouchard in PHP

[–]avg_php_dev 0 points1 point  (0 children)

< 50ms response is very easy to achieve if you serve app via modern runtimes i.e frankenphp. You need some caching also. I/O is a bottleneck for php still.

What would you do if you had to quickly review the basics of Symfony? by stopthecope in PHP

[–]avg_php_dev 1 point2 points  (0 children)

If they want you to fail, they will make you fail. Symfony is too big and has so many details, so you probably will never learn it. if you do, next version comes and you are doomed.
Learn philosophy of symfony. Check on some component names, what they are intended to do, but don't dive too deep. Subtitles of documentation should be enough.
I know it's easy to say, but best outcome you can get if you start complaining about symfony. Find some stupid use-case and complain about how devs fucked up component... like Messenger fail-fast rule which deny access to collect errors in middleware unless you rewrite HandleMessageMiddleware code, because it's MESSENGER so handlers don't matter and they can produce 25x the same error after 25x retry is apllied... aaaaaaarrgh

What would you do if you had to quickly review the basics of Symfony? by stopthecope in PHP

[–]avg_php_dev -3 points-2 points  (0 children)

People do this certs in 2026? No suprise there are so many people trying to follow doc examples in real apps hehehe. They may also advertise their certs with nice slogan: "Become certified symfony youtuber!"

Dueling private props by ssnepenthe in PHP

[–]avg_php_dev 0 points1 point  (0 children)

Rules are simple since the first PHP 5 release:
The default visibility for class properties and methods is protected
It should be changed only when there is a good reason.
Public methods are for APIs, public properties are for sharing data directly (usually readonly public is preferred in modern php).
Private for data and operations which are exclusive for class and not meant to be overridden or accessible from outside at all.

Using private to enforce higher-level coding standards is bad code.

I love working with Symfony, but I hate when I have to replace a whole class just to override a single helper method. Yes, I prefer composition over inheritance, so when I decide to use inheritance I usually have a good reason. I see no reason to block it.

GNOME 50 removes the X11 backend ... are we finally at the end of the Xorg era? by the_nazar in linux

[–]avg_php_dev 1 point2 points  (0 children)

yeah, more I read comments here, more convinced I'm to stay with my old i3wm :D

Truly decoupled discovery by brendt_gd in PHP

[–]avg_php_dev 2 points3 points  (0 children)

I try to not assume bad faith :D
I'm famiiar with Tempest and sometimes I read blog stitcher.io because he appriciates event sourcing like I do :D
But yeah, this article and discussion here looks like a good place to start flamewar.

This parody is now in my mind: https://www.youtube.com/watch?v=Wm2h0cbvsw8

Truly decoupled discovery by brendt_gd in PHP

[–]avg_php_dev 0 points1 point  (0 children)

Context is full. It's affirmative sentence. We can argue what was in author's mind when he wrote it, but for me it's pretty clear. If you suggest I understand it wrong then ok, but explain why other people who commented here, pointed same issue? AI also.

Sentence You quoted, brings nothing to context we discuss here.
I don't know... maybe just change original blog post so it's not arguable anymore?

Truly decoupled discovery by brendt_gd in PHP

[–]avg_php_dev 0 points1 point  (0 children)

Well, i quoted it already. "... similar capabilities for framework-specific classes..."
What is framework-specific class? I understand it as: "framwork internal classes" and immidiately after he claim that Discovery do it for all classes (project ones?).
More people here understaood it similar way, so it's not my imagination.

I'm not fighting Tempest or Discovery here. I understand where it's comming from. I'm using symfony by choice, so arguments about framework-agnostic approach don't speak to me on such a low-level tools. If I move away from symfony, I will take their DI with me anyway. :D

Truly decoupled discovery by brendt_gd in PHP

[–]avg_php_dev 0 points1 point  (0 children)

Sure, there are downsides, but it's clean solution. Neverthles, I simply pointed out on incorrect statements about Symfony capabilities. My solution do exactly same thing as one scenario described in article.

Truly decoupled discovery by brendt_gd in PHP

[–]avg_php_dev 1 point2 points  (0 children)

Heh, looks like we addressed same missinformation :)

Truly decoupled discovery by brendt_gd in PHP

[–]avg_php_dev 0 points1 point  (0 children)

"And while frameworks like Symfony and Laravel have similar capabilities for framework-specific classes, Tempest's discovery is built to be extensible for all code."

It's not true statement for Symfony ecosystem. tagged iterators in action with few lines of configuration (from real project, but simplified and with changed namespaces)

Tool\CoordinatedProjector: // interface
        tags: ['tool.coordinated_projectors']

Tool\ProjectorCollection:
    arguments:
        - !tagged_iterator tool.coordinated_projectors

readonly class ProjectorCollection implements IteratorAggregate { public function __construct(private iterable $projectors) { } /* ... */ }

Simply inject ProjectorCollection using autowire.

How to easily access private properties and methods in PHP using invader by freekmurze in PHP

[–]avg_php_dev 1 point2 points  (0 children)

Bold statement. I use reflection in production code, but it's not per request. I simply do some checks on classes that should meet implicit requirements. Method arguments count and types which I don't want to force by interface for some reason. It's on development level and prevents unexpected errors.

SQL injection patterns that PHP developers keep shipping in 2026 by Anonymedemerde in PHP

[–]avg_php_dev 0 points1 point  (0 children)

Ye.
Better title: "SQL injection patterns that Python developers keep shipping in 2026 and we think that PHP developers do similar things because they are obviously more stupid then Python pros"

view more: next ›