One of the things that I don’t like about Laravel is their abusive use of environment variables. I think it sets a bad precedent for when developers need to come up with their own environment variables in their applications. I have seen environment variables in an application that should have never been environment variables. And other things that should have been but have not made it to the list. So, I thought I’ll write this piece to rant a bit about this.
Not long ago some of my CI pipelines failed in its psalm step. The error was due to an exception that could not be caught, because it was not an exception class. The culprit, the 1.1.1 version of psr/container, had removed extends Throwable from the Psr/Container/ContainerExceptionInterface. Here is the related issue. Now, this was all done to a language support issue, which is understandable. But this exposed a somewhat related issue.
Last year I built a multitenant system for my employer Spatialest. It was my first time doing a multitenant system, so I researched a lot before doing it. I studied carefully the experience of platforms like Shopify, as their multi tenant requirements were similar to ours. But even after some careful study, I made some mistakes. One of those mistakes is what I’ve come to call tenant pollution. This means that many services or routines need the tenant as an argument in order to do something.
The Discovery of a Syndrome The past week I had some really nice holidays, but my wife still had to work. That’s nice sometimes because it means staying at home with loads of time to do one of my favorite things: getting myself into learning and coding (I also did some cleaning, cooking and DIYing too!). I was surfing YouTube for good coding talks and one caught my attention. It was Jack Diederich’s PyCon 2012 talk entitled “Stop Writing Classes”.
Introduction: A Tale of Simplicity VS Complexity NOTE: Every time the word array is used in this article I’m referring to the PHP definition of this term. You can also consider that term equivalent, for the purposes of this article only, to use instances of stdClass or instances of classes that contain dynamic public properties, like Active Record Models. This is because the deficiencies pointed with arrays apply to those constructs as well.
The repository pattern is one of the most well established patterns in Domain Driven Design. It’s origins can be traced as early as when Object Oriented Programing was born. Of course, like it happens with almost every pattern or tool, you can really use it terribly the first time (or even the second, or the third one). The only way to improve upon that is good literature and seeing other, more appropriate, uses of the pattern/tool.
I used to be a big fan of filesystem abstractions, not only for the abstraction benefit, but also for the testing benefit as well. It is trivial to unit test classes depending in filesystem abstractions like Flysystem or Gaufrette: just a simple mock of the interface and we are done. However, from time to time I was kinda annoyed with some limitations of the abstractions, specially in regards to stream handling.
When it comes to reporting, I have a predefined set of rules that I follow sacredly and that will ensure that my report writing experience will be nice and problem-free.