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 as
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 ex
--- 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 cluste
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
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 y
--- 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 co
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 c
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
pro
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 alterabl
--- 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 co
(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 an
--- 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
> a
Dave, you're heading for a lightbulb moment, if you have a enum which
has the value of dev, test, prod (or something else depending on the
environment), and you use it in conditionals you end up with
special-case code in the app, which is what I think is bad and you seem
not to prefer.
Enjoy
--- 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 h
--- 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 debatin
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 wrong),
24 matches
Mail list logo
