Re: [extremeprogramming] About placing configuration defaults

In order to interact with external systems, my code needs their connection information and their code needs me to prove who I am.

For production systems, neither of those things change very often, although they can, so I could probably get away with hardcoding it rather than “configuring” it. And in fact, I do hardcode some connection parameters, although most need to change depending on whether I’m in a test environment or a production environment.

But I never hardcode credentials, because I don’t want them to be visible in the repository.

So I suppose, at minimum, we’d need an unchanging way of locating external systems that automatically worked according to production/staging/development environment we were in, and a way of proving who we are that didn’t rely on secrets, but also didn’t allow the wrong people to get access to sensitive systems.

James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com

> On Nov 20, 2019, at 11:13 PM, Slava Imeshev via Groups.Io <[email protected]> wrote:
> 
> Just a thought, what prevents us from having ‘configure-nothing’ systems? Or, if it existed, how would it behave differently if such an approach existed?
> 
>> On Nov 20, 2019, at 11:04 PM, Jim Shore <[email protected]> wrote:
>> 
>> I had that problem too. I solved it in two ways:
>> 
>> 1) Not providing configuration data directly, but rather objects, built from multiple pieces of configuration data, that use that configuration to do things of interest.
>> 
>> 2) Better design of the lower parts of the system, so that although entry points receive the configuration object, lower layers only receive the objects they rely upon.
>> 
>> It may be relevant that I don’t use automatic dependency injection, so it’s not easy for methods to just get an object. It has to be explicitly provided by the caller. This has made me think carefully about dependencies and class relationships, and it’s painfully obvious when I’m doing something ugly like passing an object everywhere or using a global.
>> 
>> James
>> 
>>> On Nov 20, 2019, at 10:45 PM, Pedro Galan <[email protected]> wrote:
>>> 
>>> We follow that approach ourselves and we have ended up with a huge configuration class that is injected pretty much everywhere. The side? effect is that almost every single component have access to every single configuration parameter, which doesn't make us feel particularly comfortable. We are planning to change the approach which doesn't seem to be the best option for our system (although it don't doubt it can fit others).
>> 
>> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#160274): https://groups.io/g/extremeprogramming/message/160274
Mute This Topic: https://groups.io/mt/60557252/2417047
Group Owner: [email protected]
Unsubscribe: https://groups.io/g/extremeprogramming/leave/4902963/619838065/xyzzy  [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-