This week’s The Payload newsletter is out. It has the latest news and more in the Symfony, Drupal, PHP, Cybersec, and Fediverse development communities.
Bin nicht so der visuelle Typ. Mir fallen auch eher wenige UseCases ein, für die ich einen wirklichen Vorteil in der Bedienung sehe.
Aber offenbar gibt's doch Anhänger davon. @danielsiepmann
We had a great time at the #CMS Experts Group in Berlin, engaging in meaningful conversations and gaining valuable insights. Our team covered the recent General Assembly in Zurich and our upcoming communication strategies. A big thank you to Janus Boye for hosting us. #TYPO3#TYPO3CMS
Couple weeks ago speaking with @ocramius about Annotated Container. He brought up something about Attributes I had heard a few times before. Something along the lines of:
"I don't want container wiring code littered throughout my codebase."
So, I wrote a blog article that talks about how Attributes aren't really the point of Annotated Container and how you can use the library with no Attributes or highly limit their spread through your code.
@cspray@edorian one stronger feeling I have at the moment is that I don't want my domain (or "good") code to be have symbols that couple it to a framework or DI container. So prefer orchestrating "externally" to the class. I.e. aiming for "closed for modification" even if it's modifying an attribute...
@dantleech@edorian From my conversations, this appears to be a popular line of thinking. One I understand the reasoning for and I hope my article shows AC can support!
I'm planning on continuing to eat my own dogfood with AC and create an app using the per-module DefinitionProvider design. Hopefully I might discover ways that the library can be improved when using this style of DI config.
When developing #Laravel applications I'm always a little afraid of sending emails to actual customers or placing real orders by accident. So I came up with a habit that works super well for me and maybe this will suit you as well.
In my /config/mail.php I add a 'developer' email address and ensure in my AppServiceProvider all emails are sent to this address when in non-production environments no matter what. Makes me build and test stuff way more confidently 😁
@rolfdenhartog That's a great solution, thanks! For such cases I usually work with Laravel Herd. However, many times I know my clients work with outlook for example and then I ensure everything looks fine in outlook. But still, your approach in general feels cleaner than adding my code snippet to the service provider.
I have a FREE book on object-oriented programming available for you to download and enjoy. It's my way of giving back to the #php community. Check it out: https://masteringobjectorientedphp.com
Have you ever stood up, from scratch, a completely new version of your application in a production-ready state?
If you haven't, you should.
You may never need to fully stand up a complete production instance, but what happens if a part goes down like your database, your webservers, or your jobs? Are you prepared for emergencies?
@sarah I had to do this some time last year. Proud to say: it only took us a few hours, in part because we had copious backups and had trained for this. 👍
@sarah We do that, several times a year, one where we restore crashed servers, one where we restore single installations, one where we restore multiple, one for hot backup, one for cold backups.
Everytime we review the procedures, and fix any changes we encounter.
In my last post I talked about linking microservices together inside a single Docker network for easy communication between the services. For web developers, this poses an interesting problem: if we want to access the services from our local machines, we need to deal with the fact that we can't have multiple machines bound to
