Brian Pontarelli wrote:
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 experience, this is painful for any application of size. I've
even written frameworks to ensure configuration setup like this is
correct. It's not a good way to manage large complex applications from
my perspective.
I'm not saying the app must be configured from scratch, what I'm saying
is that conditional branches which alter the programs behaviour should
branch based on something that an environment manager decides, and not
branch based on a decision made by a developer who may not fully
understand the deployment environment.
So, for your class reloading example, if someone takes your
framework, uses it in dev, does something which relies on the class
being reloaded, and when the app is moved into production it
suddently doesn't you'll end up with the person building on your code
going "It works for me". You can't rely on people reading documents,
you can't rely on them knowing a few years down the line what you
choice of dev, test, and production settings were, and therefore
knowing what behaviour to expect.
You appear to aggressively debate things that are de-facto in other
languages and many situations. Look at Rails, Grails, Turbogears,
Django, etc. Heck, even Struts2 suggests that for a production system
you disable caching of FTLs. Most production systems don't check JSPs
for reloading. If developers want to make assumptions around things
that are conventions, they need to figure them out on their own or use
a different system. Assuming your audience aren't going to be good
citizens is not a good place to start in my opinion.
I appologise if my style comes accross as agressive (it's probably form
spending too long working with bank trading floors).
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?".
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).
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.
I disagree that there is configuration defined by environment
deployment people but managed by developers. Managers of the
environment should be able to manage the configuration, developers
should only have an advisory role. The product my company produces is
running in well over a hundred different companies, can you imagine
the reponse we would get if we said that we were the only people who
could change it's configuration?, if we had to be involved if their
changed their servers, clustering solution, database, or anything
else related to the app?, and the increase in support work for us
because we imposed that rule? we wouldn't make anywhere near the
sales of the product we do. One of the things companies look for is
the solution to the "If the development company goes bust can we run
without them?", and how can they do that if the development company
is the only people who can make changes to configuration?
Defined = Filled out or selected or configured.
Managed = Code against.
They still shouldn't go changing things without asking the developer.
If I coded an application to expect the configuration they are
defining to hit an specific type of JMS server or distributed cache
and then they change it to hit a different cluster or smaller cluster
I might not be too happy about that.
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.
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.
You can set some best guess values for things like cache sizes,
thread pools, etc., but the end user should still be able to alter
them hopefully with the advice of a developer. You put disclaimers
saying things like "Altering these values without our involvements is
not advised and may result in an non-working application", but you
still shouldn't stop them doing it. If there is spare techie time and
they want to test a P4 server against a Q6600 server against a
virtualised multi-core machine on a massive multi-CPU box then thats
something they should be able to do without having to call the
developer every time they want to try something new.
Yep. But I'm not certain this applies for everything. I'd much rather
be able to dictate certain behavior in some cases. The Inversoft
Profanity WebService, which customers can purchase and deploy, can be
set into production mode which dictates certain types of behavior.
That's really all I'm saying.
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 .
This could be a difference in viewpoint that we have based on our
experience (I get the feeling your app is designed for deployment in
environments you t have a fair amount of control over), but for me
apps should never enforce configuration changes on users purely based
on what environment they in, the deployment/support folk should
always be able to change things when neccessary (including dropping
down thread pool sizes if they need to run the app on a less powerful
server in an emergency).
Yes and no. I just think it is not very pragmatic to discount certain
things. I can understand the need for other folks to manage some
configuration, but this is not always the case. I just feel you are
being too strict in your analysis. Your situation might call for
certain things but saying that adding environmental awareness to JSF
makes people lazy is rather short-sighted in my opinion.
Whilst I repect your position I still hold my view that it will
encourage developer lazyness because why would you include code that you
know will never run once you've released the application?, in my view
thats just unncessary bloat because a developer was too lazy to develop
a solution where the code can be removed from the app prior to release.
-bp
Al.
Brian Pontarelli wrote:
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 convention that is based on environment where
adding configuration would incur unnecessary overhead?"
Take class-reloading as an example. The answer to the question would
be yes. The convention is that in development reload and in
production don't. You could use a configuration parameter with a
default value that says reload, but then the developer has to
remember to add the configuration for production to turn it off. For
me, it often comes down to being pragmatic about it while reducing
configuration whenever possible. So, I think code still needs access
to the environment.
In terms of configuration, it falls out into these rough areas:
- There are configuration that should be defined by environment
deployment folks, like computer names, but managed by developers
(since after-all we are going to be using that configuration). Those
folks should understand where the configuration lives and possibly
how to change it, but not without consulting developers who wrote
the code that uses it.
- There are configuration that should only be managed by developers
and still vary by environment, like cache sizes, thread pools,
heuristics, etc. This shouldn't be touched by anyone else, but
support staff can make recommendations and then developers can
implement.
- There are configurations that shouldn't change by environment.
Usually things like security configuration, kill-switches, etc.
These are the same everywhere and you only change them if something
goes wrong.
In all cases, the configuration should be changing per environment
and not the code. So, back to the original statements, I think none
of this is really about laziness. I think that's a poor wording. I
think it is really more about application integrity and making the
correct decisions that will ensure the application doesn't get into
production and explode. However, the more ability to manage the
better. I personally feel that all frameworks, tools, servers, etc,
should be environment aware. Be nice to have web-development.xml and
web-default.xml. Currently, there are just too many things that need
to be wrapped, adapted and proxied because they don't understand
environment.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
