Syntax testing

I have to post some python, ruby and java code in this blog. This is how the syntax highlighting is set up (documenting it for myself).

After changing the template:
  1. Copy contents of http://syntaxhighlighter.googlecode.com/svn/trunk/Styles/SyntaxHighlighter.css and paste it into the template before ]]></b:skin>
  2. Add before </head>:
    <script language="'javascript'" src="'http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shCore.js'/">
    <script language="'javascript'" src="'http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shBrushPython.js'/">
  3. Add before </body>:
    <script language="'javascript'">
Code pasted into the blog should:
  1. Have instances of < replaced with &lt;
  2. Be placed in a section like:
<pre name="code" class="py">

Add extra brushes as needed...

Note that the Blogger editor eats your line indentation if you edit a posting. So where indentation is important (say, in Python, but any scripts really), paste in the script as the last part of any edit action (gah!).

Configuration of WebSphere

Ah, always a hassle to set up, WebSphere.

Why must one programatically use an API to change the server configuration - which is then saved to XML files. Why not just document the configuration files, and let me poke them directly (as some other application servers allow)?

Anyway, such is the world I have chosen to live in. So I try to make it at least bearable.

Most WebSphere configuration scripts I have seen, whether Jython or Jacl, tend to be a glorious mix of code and data. Which I guess is fine, if the data does not change much. And if anyone who must change the data are fluent in the given language, so they do not mess up the
logic. Not cool.

Once More From the Top

I decided to sprinkle a dose of Separation of Concerns on the issue. I had to rewrite some of our WebSphere configuration magic to handle some new features, and we are starting to look at WAS7 migration. So we needed a new tool.

What I ended up with is a Jython script that takes a configuration file as input. The configuration file contains commands in brackets followed by optional properties. It looks a bit like Windows ini files:

[command, options, ...]

So the logic for interaction with WebSphere is stored in the script.

And the configuration you want to stuff into WebSphere is stored in the configuration file. (See the comment in the script for command documentation.)

Not really revolutionary. But it works and we can have different configuration files for WAS6, WAS61, and WAS7. Without polluting the logic with knowledge about the diffent versions. And without changing the logic when we find some new configuration node we must set.

Missing Feature

I know there is at least one logic feature missing: to change the console group permissions, I need to find a specific numbered node, and change it. That is, I need assignment from list (or something similar).

The current script cannot do that - because I did not need it for anything else, and because the changing the console group fails from Jacl and Jython in WAS6. But I will probably extend the script when I start to look at WAS7 in earnest.

Also, since we only use it to set up the initial configuration, there are probably some other stuff it cannot handle in its current form.

You are welcome to extend it...

Making Configurations

So how to make a configuration file? I make a new configuration by more or less following these steps:
  1. Use [types] and [attributes] to find the relevant configuration type to use and its attributes.
  2. Use [list] and [show]/[showall] to examine the default configuration.
  3. Use [create] and [modify] to make changes.
  4. Again use [list] and [show]/[showall] to see the result.
Loop a few times. Throw in [save] when it looks like it is working.

I have also been searching files in WebSphere's config folder to find the nodes/types I need to modify after making manual modifications in the Administration Console.

Or asked Google if everything else failed...


I have moved the script to Buildmeister@Kenai.

DOS Command Substitution

I have written many scripts in shell script (Bash mostly). By no means am I an expert in shell, but I like its power.

So when I have to do stuff in DOS, I feel powerless. DOS is such a poor and restricting environment for the unlucky shell programmer.

My pet peeve has been the lack of command substitution:

$ variable = `command`

where the variable is assigned the output from the executed command.

Well, as it turns out, it is possible to do something similar in DOS. It is just not very simple to do (in comparison).

Have a look at the FOR documentation. The /F variant allows you to execute a command. The output is assigned to a temporary variable, which can then be accessed in the loop part.

For example, assign the date to the variable TODAY with:

DOS> FOR /F "usebackq delims=^" %i IN (`date /t`) DO @set TODAY=%i

(yes, I know of %DATE% - it is an example!)

Two notes:
  1. the delims character must not appear in the output
  2. if you use it in a script, replace %i with %%i.

It would be a stretch to call it elegant. But it works.

I have also used one of the other FOR /F variants for reading values from a property file (using = for key/value separation):

DOS> FOR /F "usebackq delims== tokens=1,2" %i IN (c:\temp\file.properties) DO set PROP_%i=%j

Here FOO=BAR in the file will result in %PROP_FOO% being assigned the value BAR.

Welcome to the Buildmeister Blog

Hello Stranger!

My name is Jesper Skov. I'm 37 years of age and have a Master's degree in Software Engineering from AAlborg University, Denmark.

I am a buildmeister/toolsmith at heart: Understanding, analyzing, tinkering with, and, in particular, improving the tools used in the software developer's trade has always been an interest of mine.

Currently I am working at Jyske Bank, the 3rd largest bank in Denmark.

I spend most of my time developing and maintaining the build infrastructure and development tools for some 80 Java Enterprise developers.

With this blog, I hope to pave the ground for an exchange of knowledge and code with other buildmeisters and toolsmiths.

Before I started at Jyske Bank, I worked at Systematic doing pretty much the same. And I have solved many similar problems at both places.

Clearly, as I see it, there is a need for exchange of experience and code for solving common problems in the context of build and development tools.

Or, if this is old hat and everyone else have been exchanging buildmeister and toolsmith gems in some corner of the Internet I do not frequent, please let me know where it is. I need to know. Badly.

If you dabble in the same area of expertise, please consider creating your own blog so we can exchange knowledge and solutions. If there is more than one or two blogs on the issue, we should probably start a blogplanet.

Whether you intend to start your own blog, comment on my postings, or just lurk: Welcome!