3 ms·
> It's a bizarrely common pattern that creates a whole level of confusion, miscommunication, and errors in figuring out the configuration of applications runnin
by whalesalad 7y ago
> It's a bizarrely common pattern that creates a whole level of confusion, miscommunication, and errors in figuring out the configuration of applications running on developer computers, in testing, and in production.
This stems from not having one person or one team design the entire configuration system that will support the entire application.
All the mayhem you are referring to is certainly possible. I have experienced it too. But I would posit that this is not due to having 'named environments' but rather just a poor implementation with no leadership.
- jcrawfordor 7y agoI would disagree with you, in that I encounter this exact problem with first-party software on a team of three. Yes, anyone with total knowledge of the configuration system can figure out the configuration state, but my point is that it should be as easy as possible without any complications - because in practice, even if "everyone knows everything" many mistakes and inconsistencies are introduced.
- whalesalad 7y agoThis is one of those things that is tough to discuss wihtout really seeing code. We might be talking about two different things right now. I can certainly understand the issue you are discussing, but I feel like I have been able to avoid it with this approach. Another thing that I did not put in the post but that I tend to add-in to this concept is a 'dump my env' function. I will occassionally bundle this up and write it out when certain relevant issues or crashes happen. def get_snapshot(): """ Provides a snapshot of the current system configuration. """ return filter_dict(vars(module), exclude_predicate) Very handy. From my ipython shell I can just hit config.get_snapshot() and understand the state of the world.