On 5/1/06, Gulfie <gulfie@...> wrote:
> On Sun, Apr 30, 2006 at 11:55:57PM -0400, Rodrick Brown wrote:
> > I would like to adopt a uniformed way of writing in house scripts and
> > tools between the different admins, its been a uphill battle trying to
> > get everyone to confirm to one particular language this is becoming a
> > bigger problem as our staff expands.
>
>
> 'bigger problem', what exactly is the problem(s)?
>
The big problem is having everyone using what ever language they want
as it forces everyone to be well competent in each language which imo
wastes alot of time at hand, if there were one main tool that everyone
confirmed to productivity would go up, and the skill at hand would
also go up as it will be in everyones best interest to learn X tool to
be more effective in the environment.

> Figure out a cost model for it, and find out if you are chucking
> the baby out with bath water.
>
> Different languages lend themselves to differnet problems. Maybe
> it is a good thing to use the different languages if only becase you have
> good LANG_X programers and getting them to write in LANG_Y will decrease
> there efectivity for a year or two as they come up to speed and rewrite
> everything that was done in LANG_X.
>
Not a big issue really as our most complex scripts are just a few
hundred lines we are not talking about applications here, mostly log
parsers, and system automation scripts.

> What is your primary motivation? Time to delivery, maintainablity,
> cost of implimentation? etc. etc.
>

maintainablity is the biggest problem, its not very fun have some 50+
scripts in our highly distributed heterogenous environment written by
a slew of different folks split across every scripting/programming
langugage imaginable. This also increases our administrative load as
we need to make sure version XYZ of tools ABC are unified across the
board, if we got rid of B and C productive would definitly go up and
ease of administration over all.

> <..>
>
>
> > As the lead engineer i'm almost ready to make it mandatory for
> > everyone to learn and use python as unlike perl and other scripting
> > languages it forces strict style formality and with its vast array of
> > objects/types and built in routines you can clearly identify what the
> > code is doing, no time spent reinventing the wheel or spending time
> > trying to read complex regex.
>
> Making arbitrary disisions without the input of your team, might
> ruffle a few feathers, and get good people to walk.
>
> du -sk * | sort -n
>
> should probibly be done in shell, it's one line in shell, simple
> and consise.

Obviously were not talking one liners here but scripts 10+ lines of
code used in our day to day infrastructure to tackle repetitive
mundane tasks.
>
>
> > I dont want this to end up in a Perl vs Python vs XYZ but I am open to
> > friendly discussings about why this is good and bad. We are in the
> > financial service industry and Perl is the natural choice for most
> > firms.
> >
> > How are others handling situations like these?
>
> Define interfaces and protocols, not implimentations.
>
> The success of the web is in no small part due to the simple
> interfaces that allowed anyone to write whatever they wanted to attack
> there problem.
>
> -gulfie
>

Sadly I dont see this working in most larger environments where
colloboration is the key, I can see this being a non issue for small
environments 2-4 admins 20-100 servers. But in our environment we
closing in on about 1500 servers and a staff of 12.

--
Rodrick R. Brown
Senior Systems Engineer
http://www.rodrickbrown.com
http://groups.yahoo.com/group/wallstandtech