Lazy means making the developers life easier at the expense of an
operational issue (such as making support harder because if you move the
applications data, configuration files, and war file to another machine
the behaviour changes).
Al.
Frank W. Zammetti wrote:
I'm not sure what you see
Brian,
It's always good to get a discussion going :).
The application isn't changed between boundries, it's the configuration
that changes, and the configuration is controlled at each stage by the
person responsible for that environment and not by the developer.
Let me give you a concrete
--- On Sun, 6/29/08, Al Sutton [EMAIL PROTECTED] wrote:
If the techies at DR just had a dev, test, or prod
switch how could they have done that?
How could they do it if they had to change code?
Complex environments require complex configuration management; I'm not sure how
the example
Then the questoin becomes Hows does the developer create a
configuration set when the application is released which uses the
database server which is chosen by the tech support team when things
start going wrong at a later date?
Al.
Dave Newton wrote:
--- On Sun, 6/29/08, Al Sutton [EMAIL
In order to complete the test one the databases of one
application was dumped to disk and moved to another available database
server, and that individual applications configuration was updated to
point at the new server (the other apps on the app server remained
pointing at the original
I'd contend that once you hit QA it's an admin's job to point to an appropriate
DB server for instance, not a dev's (although the devs will clearly have a
say)... However, none of this should be built into the EAR and therefore can be
changed in any environment without the EAR itself changing.
Frank,
Thats the point I'm trying to get accross.
It's not that an environment enum couldn't work, it's that the ability
for a developer to write an application which changes it's behaviour
just because someone has move a copy of it from production to a
debug/test environment is a bad idea.
--- On Sun, 6/29/08, Al Sutton [EMAIL PROTECTED] wrote:
Then the questoin becomes Hows does the developer
create a configuration set when the application is
released which uses the database server which is
chosen by the tech support team when things
start going wrong at a later date?
They
Exactly. Now if you limit the admins choices to a limited set of
configurations your making their a lot job harder because they need to
go back to the dev guys if the configuration they want to test does not
have already exist as part of a set.
Frank W. Zammetti wrote:
I'd contend that once
--- On Sun, 6/29/08, Al Sutton [EMAIL PROTECTED] wrote:
Imagine the fun of having an app which only sends live
messages when your in production. The QA team run all
the tests they have in a QA labe, they all pass because
the app decides to only use test data, they move the app
and
I've written code that uses environment. Of course, I mainly write
frameworks, so it probably makes more sense there, but I have used
environment to dictate code rules. Eager singletons versus on-demand
singletons, class-reloading, etc. I think it breaks down to this
question, is there a
And so don't you then come to the conclusion of what is the point of a
dev, test, prod switch when things are set individually anyway?
Al.
Dave Newton wrote:
--- On Sun, 6/29/08, Al Sutton [EMAIL PROTECTED] wrote:
Then the questoin becomes Hows does the developer
create a configuration
That's my poing Dave, and if you have code which alters behaviour based
on it's detection of it's environment (dev, test, prod), the code will
care about which environment it's because that determines its very
behaviour.
This means that even if you move a non-production configuration into
Just to follow this on, as I understand it dev, test, and prod map to
configuration sets which are configured into the system at development
time. Therefore the developer determines what the dev, test, and prod
settings are so althought the configuration is in the application it is
not
--- On Sun, 6/29/08, Al Sutton [EMAIL PROTECTED] wrote:
And so don't you then come to the conclusion of what is
the point of a dev, test, prod switch when things are set
individually anyway?
*Can* be set individually; you bring up a special case, which would necessitate
a special case
(I've chopped some of the previous messages from the end for the benefit
of those in digest mode).
I'm coming from the other side of the configuration debate; the side
that says you should have the configuration file which shows whats
happening as opposed to having intelligent defaults which
Just to bring it round Dave, were talking about application logic whose
execution is based on an environment setting, so we're not talking about
a base dev-config.txt and production-config.txt, we're talking about an
application where something like a method will only return test data in
dev
--- On Sun, 6/29/08, Al Sutton [EMAIL PROTECTED] wrote:
Just to follow this on, as I understand it dev, test, and
prod map to configuration sets which are configured into
the system at development time. Therefore the developer
determines what the dev, test, and prod settings are so
--- On Sun, 6/29/08, Al Sutton [EMAIL PROTECTED] wrote:
Dave, you're heading for a lightbulb moment [...]
If I had a nickel for every time somebody's assumed that about me I wouldn't
need to have people assume that about me ;)
if you have a enum which has the value of dev, test, prod (or
Dave Newton wrote:
--- On Sun, 6/29/08, Al Sutton [EMAIL PROTECTED] wrote:
Dave, you're heading for a lightbulb moment [...]
If I had a nickel for every time somebody's assumed that about me I wouldn't
need to have people assume that about me ;)
:).
if you have a enum which
--- On Sun, 6/29/08, Al Sutton [EMAIL PROTECTED] wrote:
As I understand it the others are in favour of the
environment dependant enum as mentioned by the URL
James originally pointed to at [...]
Oh. So... I was arguing with someone that agreed with me.
I really have to rethink my debating
I'll reply inline quickly.
I'm coming from the other side of the configuration debate; the side
that says you should have the configuration file which shows whats
happening as opposed to having intelligent defaults which hide
configuration options from the deployer/support person.
In my
I've kind of lost track of the original point anyway :/
Al mentioned that adding environment awareness to JSF makes people
lazy. I jumped in and stated I disagreed and that adding this just
allows people that need it to use it. From what I've gathered thus far
(Al correct me if I'm
23 matches
Mail list logo
