Archive for the ‘Tools 'n' Tips’ Category

Older Entries »
h1

Preventing ticket ping-pong

February 27, 2010

This is the first opportunity I have had for a while to put something on this blog — busy, busy, busy. (I can tell you that I am building up a fairly sizeable backlog of articles on parallel development and I will, I promise, get round to publishing them soon.) In the meanwhile, here’s a brief thought on designing ticketing systems.

Many ticketing systems, supporting processes such as incident management, are prone to ticket ping-pong where tickets are bounced from queue to queue as people keep forwarding the problem to get it off their queue. This is simple to control once you see the problem. Read the rest of this entry ?

Posted in Plain Old Blog, Process, Tools 'n' Tips | Leave a Comment »

h1

Fences and Ambulances

February 17, 2010

Suppose you are in charge of a cliff edge. Your task is to maintain the views from the cliff, but keep visitors safe. You can construct a fences along the top of the cliff, to stop people falling over, or you can place ambulances at the foot of the cliff, to clear up once someone falls over. Read the rest of this entry ?

Posted in CMCrossroads, Plain Old Blog, Process, Tools 'n' Tips | Leave a Comment »

h1

Common Interface

January 31, 2010

After much deliberation and soul searching I’ve finally decided it’s time to address one of my all time bugbears. I am going to develop a set of transferable libraries for analysing and operating a CMS. And because I am most familiar with Perl (and, as explained in my earlier post Glue Software, I find it the most useful language for my needs) I shall write them in that language.

As with most people who have worked long enough on the coalface of SCM I have a ragtag collection of routines, scripts and utilities already but now is the time to pull them all together, clean them up, give some thought to a coherent design and build a better mousetrap that I can use whenever I go to a new client.

This is not an effort to develop a be-all-and-end-all CM system, but more a matter of me realising that I develop the same sort of scripts time and again. So I would be better off developing a more robust architecture that will allow me to exploit report generators or integrity checkers written when using one tool when I go to a client who uses another tool but has the same problem to be solved.

A typical example of a script I have written several times is one to check the integrity of a build configuration. Answering questions such as, ‘does this build configuration contain all, and only, the completed change requests assigned to this release?’

It would also be nice to have a tool for federated reporting across tools. Often clients have several version control tools and it would be nice to have one reporting front-end that I could plug into their many VCSs and get information about them all.

There are, of course, many problems to overcome (not least all the different philosophies supported by these tools) but this is not a case of trying to solve all problems in one go, rather the idea is to write a facade that will allow me to access the implementation tools through a common interface. In this way, all I need do for each client is write a new facade that complies with my own interface definitions but interrogates their particular implementation. The hard parts of these scripts, the logic, will remain unchanged and useful in multiple applications, treating the tools as databases.

As with many efforts born of frustration, this one is not completely thought out yet (in fact some of the ideas are positively vague), so expect more to come on this side project…

Posted in CMCrossroads, PERL, SCM Tool | Tagged , | 1 Comment »

h1

Glue Software

January 25, 2010

As someone who inevitably becomes involved in the technical implementation of configuration management systems (CMS) I am often called upon to create what I choose to call ‘glue software’. Glue software is not a full integration between two products (often there is simply no way to fully integrate products) but rather it is a more Heath Robinson collection of scripts, triggers and hooks used to provide some connection between applications that support the CMS.

There are a multitude of technologies that can be used to create glue software, including but by means limited to; SQL, various shell scripts, C, C++, C#, Java, PHP, Python, various web technologies (XSLT, ASP etc.) and so on. Over the years I have used all of these and more but by far and away my favourite glue software development language is PERL. And here’s why… Read the rest of this entry ?

Posted in CMCrossroads, Glue Software, PERL, Plain Old Blog, Tools 'n' Tips | 1 Comment »

h1

Subversion’s Ignore List

January 8, 2010

The idea behind the Subversion ignore list is very simple: when adding (using svn add or svn import) files into a Subversion repository, any file that matches a pattern on the ignore list is skipped.

The ignore list is constructed from two sources:

  1. the client specific global-ignores list;
  2. any svn:ignore property associated with the directory into which the file is being added.

The global-ignores configuration parameter is set in the client’s config file and applies to all additions executed from that client (excluding those that specify the command line option –no-ignore). To this global-ignores list is added, on a directory by directory basis, any patterns associated with svn:ignore properties associated with directories.

The ignore list becomes a little more complicated when combined with wildcards in file names provided to the add commands. Rather than write a long post on the subject I have provided an extract from my Subversion training course (divided into two parts here because of YouTube length restrictions, it’s all one video in the course :) Oh, and WordPress, who host this blog, do not support embedded playlists. If you prefer to watch this as a playlist, go here).

If you watch these videos here I suggest you expand then to full screen otherwise they’re too small to read (again, this is a limitation of wordpress.com hosting).

Part 1

Part 2

Posted in CMCrossroads, Subversion, Tools 'n' Tips | Tagged , , , , | Leave a Comment »

h1

Creating Tags in Subversion

December 4, 2009

Subversion does not support labels as many version control tools do. Instead Subversion uses the svn copy command to create ‘tags’.
By convention a Subversion repository is often divided into three sub-directories;

  • trunk, where the main development is often (though not necessarily) done;
  • branches, where (unsurprisingly) we maintain branches that may be used for any number of reasons to isolate some sequence of changes from the trunk;
  • tags, where we maintain tagged sets of files and directories.

It is this last area tags that this post considers in more detail. Read the rest of this entry ?

Posted in CMCrossroads, Subversion, Tools 'n' Tips | Tagged , , | 2 Comments »

h1

Analysis Paralysis

July 27, 2009

This is something to which I have been a victim in the past (and, if I am honest, occasionally I still fall prey to now); analysis paralysis, the inability to do because we feel uncertain about which of several alternative courses of action to take. Read the rest of this entry ?

Posted in General, Plain Old Blog | Tagged , , , | Leave a Comment »

h1

Tool selection: beware the ideal case

July 16, 2009

When selecting tools, for any purpose, beware the ideal case.

When a product is demonstrated, online or directly, the presentation has, generally, been carefully worked out in advance to present to tool in the most favourable light possible. The tool will perform optimally and the use case will appear flawless. Sadly, real life is never an idealised case like this.

It is very easy to be beguiled by these idealised demonstrations, they look so smooth, so simple, and they seem to address some serious development issues. It is difficult to remain objective, especially when the tool seems to offer an easy solution.

Real life is not a demonstration though. It takes time to migrate to a new tool. Tools all have limitations, and you need to know what these are and how likely they are to cause you difficulties.

You need to know how difficult it will be to migrate your existing system over to the new system.  Many tools will demand that you work in a particular way in order to get the best from them, so remember to account for the cost of changing your process too. Are you going to need to sacrifice integration with other tools because the new tool does not integrate properly? Then there are training costs in order to get the whole project trained on the new tool.

Another irritant with many modern tools is the lack of a command line, or an impoverished command line that does not provide access to all of the tools functionality. The move to more and more GUI based interaction presents difficulties for real life scenarios where it is often necessary to integrate tools using scripts. Be careful of the lure of a powerful API. APIs are wonderful to have, but they are seldom as accessible as a command line interface, making quick integrations more difficult to implement.

Do not accept a demo as a reason to change tool. Demand that the tool vendor show your system using their tool. Demand that the vendor show how your system would migrate to their tool. Demand that they show the migration process, how the tool will integrate into your existing process or what you will need to change, evaluate the total cost of migrating to the tool, and so on. Any vendor that refuses, or cannot show the cost benefit of this migration should be dropped immediately from you evaluation. No matter how good the tool looks, no matter how well it performs with an idealised demonstration system, if it cannot perform for your system it is useless.

All of this may seem like I am arguing against looking at new tools, or that I have some downer on new tools in general. I do not. I love new toystools and I think tools should be constantly reviewed in order to make sure we have the best tool for the job. Just remember, the best tool for the job does not necessarily mean the newest tool and the newest tool may come at too high a cost in terms of impact on your environment and process.

Posted in General | Tagged , | Leave a Comment »

h1

Writing documents that people will read

July 11, 2009

One common complaint, and one to which I have fallen prey in the past, is that “no one reads the documentation”. This seems to be a particular problem for documents recording process and procedure. In this series we will look at how you can write documents that people will actually read.

We will look at every aspect of documentation, including each of the following.

  • Audience — Who are you writing for? And, how to make sure your document appeals to them.
  • Content — What are you writing about?
  • Structure — Creating documents that make finding information easy.
  • Presentation — Creating documents that are appealing.
  • Delivery — The different methods of delivering information.

Many documents focus only on content, neglecting all other aspects. This is in part because many documents are written to the same formula by domain experts. They are not written to be read, they are written to comply with a requirement that they exist.

This series is not interested in producing documents for compliance, it is interested in producing documents that are useful and used. Read the rest of this entry ?

Posted in General, ITSLM | Tagged , | 2 Comments »

h1

Allowing users to change their own password using svnserve and passwd

July 7, 2009

One recurring issue users bring up when using Subversion’s own svnserve server and its own internal authentication system (password-db) is that users cannot easily change their own passwords.

The problem is that, when using svnserve and the internal password-db, usernames and passwords are held in a plain text file, usually within the conf directory of the repository to which they apply. This file cannot be made read/writeable to all users because this would allow all users to both see and change one other’s passwords (which would be very silly).

The usual solution to this is for the administrator to issue passwords to users and whenever a user wishes to change their password they ask the administrator to do it for them.

Here is a method for allowing users to change their own passwords. In summary, this is a hook script that intercepts requests to delete a special file. When an attempt is made to delete this special file the script assumes that the log message is the new password to be set for the user who requests the deletion. It then changes the entry in the local Subversion password database and rejects the request to delete the file.

Full details are available on the Principia Subversion FAQ.

Posted in Subversion | Tagged , , , , , , | Leave a Comment »

Older Entries »