Every now and then I read a piece about DRY vs WET, explaining their benefits over its counterpart. Most of the time, these pieces are quite unhelpful, as they are way too vague and general. They lack a crucial thing, and that is context. I believe this is the most common aspect on disagreements about any topic in software development. Someone writes a piece about X or Y topic arguing a point, but then another piece comes up arguing a different case (or sometimes totally the opposite one).
How do you test code that integrates with a third party HTTP service? The Philosophical Answer If you think about it, it is not an easy question to answer. Maybe you have already some strong opinions formed about it. But, in my experience, answers to this question differ greatly among developers, even between seasoned ones. I believe those differences are due to some preconceived ideas or different definitions about what testing is.
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.
Recently I put myself back into the market: I went job hunting. I did this after a year and three months at Spatialest, in which I had the privilege of meeting kind and hardworking people that welcomed this very weird and unknown Chilean person into their lives and into their company. It was also a time of growth: I could develop some mentoring skills; I was able to become pretty good at React, and I was able to learn a bit more about multi-tenant solutions and implement my first multi-tenant platform.
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.