26 May 2000 star   » (Journeyer)

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.
  • Latest blog entries     Older blog entries

    New Advogato Features

    New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

    Keep up with the latest Advogato features by reading the Advogato status blog.

    If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!