Yay today I did my first commit to Nautilus,
OK it was someone elses code, but I did commit something.
Right now I am going over some various idea for how to deal
with developer environments.
Do not store data in the environment unless you have to.
Keep configuration information seperate from logic, or even
seperate from a particular programming language.
Use a sensible programming language. I am choosing perl despite some complaints
that it is not sensible.
Keep it easy, yet keep it simple.
Configuration Information
You always need to have value pairs, X=Y, this is simple
and generic and you will need it for any programming or
configuration. It makes the most sense to store this in a
file, that you have other scripts/application parse to gain
the configuration. This way you do not have to hard configs
into your application (other than the location of the
configs) and it makes it easily extensible, so you could
have an IDE load the configs, a series of installation
scripts, and possibly even and environment. This also
bennifits maintainability greatly, if you only have to
change setting once! Not in 15 million files.
I am currently working on some tools so you can have a perl
modules or a bourne derived shell extract settings from the
same file and then set those settings for further use.
sensible programming language
Maintainability, Maintainability, Maintainablity. Tools do
not have heavy performance requirements. They need to be
changed and adapted frequently, for integration with other
tools, other networks, new releases of OS's. They need to
be able to do fancy text processing and deal with
meta-data. Your tools will also need to call other tools
at the OS level. Continual change, and text processing, and
calling external utilities makes scripting languages ideal
for this.
Generally builds have enough complexity and logic, that you
want a language with decent referencing, library abilities,
and scopeing.
Shell is a little weak, as is tcl. Perl I chose because,
way more people know it than others (this is important for
maintainability), it is easy to learn (if you are
familiar with programming in any other language - I would
never reccomend perl as a first language), perl
integrates very nicely with calling outside programs, and
perl has LOTS of usefull
ready made modules. The problem with perl is that it
can be difficult to maintain your code, the language
discourges you from writing clean code, but it does not
require you to write unreadable code.
keep it easy keep it simple The idea for tools is to
make developers more effective, and to allow a new developer
to become effective quickly. At the same time, it is not
worth while to reduce the number of commands if it requires
additonal conceptioual complexity. DO NOT make context
senstive setup commands. This saves typing but does not
make it easier for people to become familiar with what is
going on.
Some other ideas are that their should be one command to do.
initialize an environment from scratch.
This just saves time. New developer comes in, gets new
OS, runs one command gets all the required tools and setup,
should download the packages needed, should setup the
filsystem, give the developer the localizations they need.
update tools and source.
Things change, it happens. Developer should have one
command to hit a centralized spot, and find out what changed
and be up to date.
build and release everything.
This is really needed to verify that a setup is correct and
that the code that was there doesn't break anything. It
needs to be done, it should do all related components.
initialize development environment to work on a project.
In a command line world this is one command, in a GUI
world this is a button or open the IDE config file, but
there should be one simple way to grab all the settings for
a project. These need to be maintained regularly.