Why does #Symfony define what appears to be a “real” value for APP_SECRET in the .env file that’s committed to your repository, and then, right above it, there’s a comment that says (in all caps):
“DO NOT DEFINE PRODUCTION SECRETS IN THIS FILE NOR IN ANY OTHER COMMITTED FILES.”
Where’s the documentation that explains what APP_SECRET is used for? Why doesn't it put this value in .env.local (ignored by .gitignore)?
@ramsey@manal@nicolasgrekas well it's not sensible if it's used only locally, and then you use a .env.prod or (better) inject a real env variable in your prod environment.
I managed to avoid #Kubernetes for 10 years, but it’s finally caught up to me, so I hope I’m a Kubernetes god after going through all this required (by job) Kubernetes training.
@maxalmonte14@dantleech IMHO default implementations could be a good use case for traits. I rarely use them, but I consider them useful and good only with a few caveat:
they must be self-contained (no reliance on external properties/methods)
you have to remember that they are the same as copy-pasting code, without relying on inheritance
if you're tempted to rely on their presence, put an interface on it and rely on that
@maxalmonte14@dantleech another useful use case of traits for me is splitting utility code inside PHPUnit tests, where you're already bound by the TestCase inheritance chain.
@afilina@dantleech@maxalmonte14 totally agree. And in fact your reply made me remember another use case for traits, exactly to avoid inheritance: a Timestampable trait with createdAt and updatedAt properties and getters to avoid to create an AbstractTimestampableEntity.
suggestion: check that your local LAN isn't a bottleneck! 😂 I have a docking station for my laptop with an ethernet cable, and switching to fiber made me notice that I was going at 100Mbit instead of 1Gbps 😅 and I had to replace the cable
A journalist sent me a bunch of questions about Baby Reindeer, so I watched it this weekend, and not only did I not answer the questions, but now I really need to watch something that is not about stalking and sexual assault.
"In my new role as VP of Engineering, there was one question I was dreading more than any other: 'How are you measuring productivity?'
I can’t fault the question. I mean, sure, I’d rather it be phrased about how I’m improving productivity, rather than how I’m measuring it, but fair enough. There are real problems in the org, I do need to fix them, and I need to demonstrate that I’m doing so."
@jamesshore very interesting article! Also, "product bets" is a very interesting concept, but I fear it may hide a trap: since it considers the bet the number of eng-days to employ against future return over multiple years, it seems to me that it doesn't consider the ongoing cost that the new feature (or any shortcut take) may introduce.
Is there a failsafe against this problem? Maybe some detail that you didn't mention?
Spent the morning writing code to test a microservices architecture. Wondering at what point testing relationships between services becomes cumbersome.
@sarah that makes total sense, because those tests should not be too hard to develop/maintain, and you can easily put them in CI.
But I don't think they can replace contract testing, since they require merge/deploy, so I would consider them a "safety net", not a part of the vital "development feedback loop" that normal CI gives you.
Later, you can start deploying ephemeral environments from branches and run the smoke tests there, but that kind of stuff has a medium-to-high maintenance cost...