Let’s talk about how to format code and name things.
I remember when PSR-1 and PSR-2 became a thing. Jeez that “use only spaces” thing was just ridiculous, I knew that tabs where better (right?). And those crazy formatting rules were the opposite of what I was used to. Nonsense! One day I did the jump and after a few weeks, I just didn’t care anymore. I was over it, just like everyone else did, and PSR-2 was my new religion.
Fast forward a few years and I’m at a talk where the speaker argues to use snake case for naming test methods. Dude, you crazy? We just finally got consistent style across all the PHP world! And we all know that camelCase looks much better right? How can I go against PSR-2? It turns out, after trying it, that this was a wonderful idea…
Habits are sometimes making us blind. We think X looks prettier than Y but that’s just the habit speaking. In this article I’ll try to take a rational approach at coding style. That means leaving the “it looks ugly/better” at the door.
Decoupling packages is a hard thing. There are not a lot of options, and this blog post is about how some options are better than others.
Let’s say for example that you are writing a “package”, or library, to respond to HTTP requests (that kind of package could be considered the basis for a web framework). How do you handle routing?
If you write your Router package as an independent package (which is good: small and specialized packages are more reusable and maintainable), you might not want to couple the HTTP package to the Router package: you want to leave users free to choose the router of their choice.
So, what are your options to make the HTTP package and the Router package decoupled from each other?
Today is my last day at My C-Sense, after almost 2 years working on creating and modernizing existing PHP applications. This has been an incredibly rich experience in an excellent work environment, I will surely miss this job and my colleagues.
Now is probably a good time to look back on our open source experience as a company, and as a developer. It all started when we moved all of our code to GitHub: we used a lot of open source software and libraries, and we thought we might try to contribute some day with some small internal projects too.
So that’s how MyCLabs was born: let’s keep the door open for open source because “why not”.
This article logically follows the previous: The Repository interface. In there I suggested a better interface for repositories based on a Collection interface so that repositories could be manipulated like collections.
This article goes further in that idea and presents an API to abstract database access behind collections of objects.
A repository represents all objects of a certain type as a conceptual set (usually emulated).
It acts like a collection, except with more elaborate querying capability.
For each type of object that needs global access, create an object that can provide the illusion
of an in-memory collection of all objects of that type.
While I love Doctrine, I really dislike
their repository interface
because it doesn’t look and act like a collection.
And that’s too bad because Doctrine even provides a very good abstraction for collections
through the doctrine/collection project. It even supports filtering with criterias over collections and repositories.
I know that Doctrine is not targeted at Domain Driven Design only, but I think having a better repository interface
would still benefit the project and the users.
Here is a basic repository interface I tend to use instead:
If your application sends emails, you probably don’t want emails to be sent when you are developing on your machine.
If you use nice libraries like SwiftMailer, it is easy to use a mock instead of sending real emails.
But if you don’t, you can act on PHP’s configuration: instead of installing and using a real SMTP server on your machine, you can fake one using a simple script.