Re: [OT] Re: environment awareness (project stage in JSF)

[Ralf Fischer <th...@googlemail.com>]

Hi List,

what a unusually excessive thread for this list!

Most times I agree with Al. I'll just add up my $0.02 to participate
in this rally ...

* The code itself should IMO know as little as possible about the
environment it's running in. If I see stuff like "if ( testMode ) { ",
which for me seems equal to Application.getProjectStage() == UnitTest
(e.g.),  I usually take the persons head! And I really get ugly when
this if here has an else-branch... How are you gonna test this?

* Concerning the discussion who may change which configuration entries
to this or that value: Hell, if the maintainer who runs the site may
not change a configuration entry, why would I care to make this value
configurable? Static configurations which should only be changed by a
developer belong into the code, or at least into a configuration file
within the package. Everything I want to be configurable by the guy
wiring my application to the environment is configurable externally.
Whether it's a file, JNDI or any other mechanism doesen't matter.
That's just a flavor.

All these points depend on the context. When I deliver software to
clients it's much more important for me not to expose sensitive
configuration options in the configuration which should be under
development control. If the software is "only" deployed inside my
company this no longer matters that much, as I'm usually in more or
less close contact to the person running my software and he surely
will ask me when somethings goes wrong.

I also wonder why there is such a (more or less) hard distinction
between QA- and production-environment. From my deverlopers' POV I try
to cover as much testing as possible in unit tests, and usually never
touch the QA - for me it's like production: If it doesn't work,
someone will come in my office, start pointing fingers, maybe even
shouting, and tell me to fix it. :-)

Bye,
-Ralf


On Mon, Jun 30, 2008 at 6:18 PM, Al Sutton <al...@alsutton.com> wrote:
> I think we're pretty much done, I do beleive that a configuration should
> reflect the environment it runs in, but I think our opinions differ when it
> comes to allowing developers to dictate behavioural changes between
> environments and shipping code which is never executed.
>
> Brian Pontarelli wrote:
>>
>> I think we both agree that configuration is best. In fact I think you even
>> support environment awareness in configuration system. So, from that
>> perspective we are solid. The rest is just debating personal style and
>> developer freedom. I will answer a few things below, but I think we can
>> close out this thread or take it off-list.
>>
>>
>>> The key thing here is that S2 *suggests* it, it doesn't impose it. My
>>> point is that it is fine to suggest it something that the user can alter,
>>> but it is bad to do something which alters program behaviour without the
>>> environment managers involvement as would be the case with a conditional
>>> branch dependant on it's environment. I would also ask the question of "If a
>>> developer has seen the framework exihbit a behaviour, are they really a bad
>>> citizen for making use of it?".
>>
>> Suggestions aside, S2 still doesn't make this easy. It needs environment
>> awareness and it should probably default a ton of stuff when in production
>> mode. This one being the top on the list.
>>
>
> Being not easy and being not possible are worlds apart. My view is that it
> doesn't have to be easy, but it should be possible and developers should not
> dictate behvioural changes when an app is moved between environments.
>
>>>
>>> I'm also not a fan of just accepting something as good if it's a de-facto
>>> standard because I know from experience that not all decisions which make it
>>> into the wild are teh right thing to do. Would S1 have been released if
>>> WebWork had already been floating around?,  Would the Java UI Event model in
>>> 1.0 ever had seen the light of day if someone had already started work on
>>> what became the 1.1 model?, and you just need to look at the history of EJBs
>>> to see things which were de-facto standards which have now been "retired"
>>> (Home/Remote interfaces, Message beans that could only get messages from
>>> JMS).
>>
>> Not accepting crap is one thing. Not accepting something that is outside
>> our comfort zone is something else entirely.
>>
>
> Very true, but some things are just crap that looks OK in the right light
> whether they're inside our outside our comfort zone.
>
>>> To me the big switch idea is like hard wiring your headlights and a speed
>>> limiter into your windscreen wipers. Whilst it might seem a good idea, there
>>> are situations when you'll just want the wipers on or off.
>>
>> Haha. Not even sure that's similar enough to the cases I mentioned to make
>> sense. Humorous though.
>>
>
> Glad you appreciate the humour :), the point is that some decisions can look
> good from a certain standpoint, but when the end result goes into use it
> prooves to cause some unexpected problems.
>
>>> You may not be happy about it, but a production issue may neccessitate
>>> it. My previous message had a real world example of where a database was
>>> moved to a smaller system because the performance of many apps was poor due
>>> to the total load on the database cluster.
>>
>> Orbitz was slightly different. No one made environment changes without
>> consulting a developer. We had it happen a few times and it didn't go well
>> because the complexity was too high. It always looked like an acceptable
>> change, but the developers who wrote the code always knew something that
>> others didn't. That's why nearly all of the developers wore pagers and
>> everything was setup to allow developers to help make decisions.  Now,
>> that's just Orbitz and I'm certain there are different environments that
>> this would be okay. But I figure call the developer first and double check
>> to see if any flags go up.
>>
>
> It's an interesting way to do things, but relies on the developers of an
> application staying with the company (and not being on vacation),
> remembering all of the things that they've done, and creates a single point
> of weakness - the developer.
>
> In the environments I've worked in developers are/were moved between
> projects and there was always an element of churn (i.e. people leaving and
> joining), so after six months the developer may have either lost much of the
> knowlege relating to the app due to having a new focus, or may simply be not
> around.
>
> Within many of the companies I've had exposure to that are based in the
> financial sector there is a requirement to have a single two week block of
> vacation in which you are considered uncontactable. This ensures that no
> matter what happens to the employee the company can still function, because
> even though we don't like the idea, people do get hit by busses.
>
>>> In the UK and the US almost all major banks aim to be able to fail over
>>> to a DR site within 2 hours for all critical applications, if you add in the
>>> requirement for a developer to make a new release for any configuration
>>> change that needs to be made you're wasting valuable time.
>>
>> Yeah, we didn't do releases to change configuration or the environment. It
>> took days to do a release. We just patched things. I know people are feeling
>> a little sick at the thought of ad hoc patching, but it worked for our
>> situation.
>>
>
> Ad hoc patching isn't nice, but sometimes it's a neccessity.
>
> My issue is when you need a developer involved in every change the number of
> people involved in any change increases and therefore so does the time
> needed to make the change, and when time is money the number of people
> needed to make a change tends to get "optimized".
>
>>> But if you dictate behaviour why should your choice change just because
>>> the app has changed environment?, if it's a useful feature for you in dev it
>>> will most likley be a useful feature to a techie trying to resolve in issue
>>> in support, so it should be a configurable switch, not a cast-iron decision
>>> that allows you to access features which help you debug the program in dev
>>> but provent the techie checking for the source of a problem in production or
>>> test .
>>
>> Might be useful, but in some cases if you turn on cache checking it will
>> crush the entire system. Again, I'm just advocating being pragmatic and
>> protecting the system. However, most cases aren't like Obritz and I could
>> definitely see that leaving cache checking turned on won't impact things too
>> much. But, I'm sorta stuck now and so I do a lot of my work thinking about
>> massive scale up front.
>>
>
> I can see where you're coming from, but I'm fimly in the camp that if it's
> useful in dev it may well be useful to a techie.
>
> If a problem arises on a customer site I'd far prefer to be able to be able
> to ask a techie to turn on cache checking (or any other dev feature) by
> setting an option, warn them of the system impact, and get the results after
> a short run, as opposed to having to send a developer on site to check and
> probe the customers environment. If nothing else it means that we can
> quickly and easily run our tests in their environment as opposed to hoping
> that we can accurately model their live environment in order to replicate
> problems.
>
> Al.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org