modulus blog

For years, I have done the vast majority of my web programming in Perl. It’s a powerful, flexible language, excellent for CGI programming. Many of its features, especially associative arrays and regular expressions, are so well integrated into the core language that they make coding a particularly genial activity. There are few tasks for which Perl is an unsuitable choice; if I were so foolish as to make a list of these, no doubt someone else could point to an example of, say, Perl performing process control of a nuclear power plant.

Due to its recent popularity, I’ve dabbled over the years with PHP as well, and found it great for the tasks for which it was specifically designed and less than great in some other areas. The quality and consistency of its documentation is patchy and its OOP model has only recently fully evolved.

However, I’ve taken the plunge and I’m moving across to using PHP for all my web programming. I want to do more in the way of mobile devices; this made the previous mix of HTML, CSS, Perl, PHP and Javascript untenable. I could not readily achieve fully conforming mobile device web pages with this mix, so I’m in the process of replacing my Perl modules with PHP versions and, in the process, eliminating as much Javascript as possible. This will enable me to tailor the pages rendered from my website to the particular device and user agent, desktop or mobile, requesting the page. So far, the experience has been quite enjoyable and I have not found any insurmountable problems.

The modules which I’ve already fully ported include the locations.module, sitesearch.module, guestbook.module and validlinks.module, with more of them to come shortly.

An important part of analysisng business processes is covered by RACI analysis, which concerns the determination of who is Responsible, Accountable, Consulted and Informed (RACI) for each business process. Assuming you’ve got the Identifying, Documenting and Analysing Business Processes e-Book, you will fully understand RACI analysis and how effective it can be in analysing business processes. To help you apply RACI analysis, I’ve prepared a RACI cheat sheet. It’s a two-page PDF file which you can download and print.

Print the RACI cheat sheet and put it on your desk; you’ll find it an effective reminder of the RACI section in Identifying, Documenting and Analysing Business Processes.

Assuming you’ve got the Generating & Selecting KPI Sets e-Book, you already have a good idea of how to construct good candidate KPIs and how to select between those candidate KPIs to form effective KPI sets, you’re all set to go. But can you recall all of the key steps in the process?

As an aide memoire, I’ve created a KPI cheat sheet. It’s a one-page PDF file which you can download and print, to guide you
through the creation of KPIs and KPI sets.
It leads you through all of the key principles of selecting KPIs and KPI sets, including Kaplan & norton “Balanced Scorecard” reminders, as well as KPI system rollout steps.

Print the KPI cheat sheet and put it on your desk; you’ll be surpised how effective a remider of the principles of Generating & Selecting KPI Sets it is.

Service Level Agreements are agreements for a scheduled set of services to be delivered at an agreed quality for an agreed cost. In this sense, a service level agreement is, formally, just a contract. However, service level agreements are a rather special type of contract; they represent a highly cooperative agreement between two willing participants. Service level agreements spell out the expectations of both the parties; they can be internal (e.g. a SLA constructed between the IT department and the operational department of an organisation) or purely external (e.g. a business continuity service level agreement between your organisation and Hewlett Packard). The most common SLAs currently in use are IT service level agreements, especially for telecommunication and support services.

The formalisation of a service level agreement tends to take the emotive content out of service provision; by clear, concise agreement on the scope of services to be delivered, the quality of those services and the compensation for provision of those services, each party to the SLA is relieved of the emotional baggage of service provision and freed to concentrate on the efficient provision and consumption of those services. Of course, a service level agreement is no panacea for problems arising in the provision of services. However, when tribulations do arise, they can be dealt with within the framework of the service level agreement, even when this means that the agreement needs to be varied.

Service which are suitable for management by Service Level Agreement include:

• well understood, established services
• services which are delivered in small lots, fequently
• repeatable, definable services
• relatively stable demand for the services
• existence of a capable labour pool to fulfill the service level agreement.

This is not to say that service level agreements cannot be constructed for larger, more complex services or that the realm of service level agreements ios limited to blue collar labour, but it does mean they are unlikely to be a good fit for original intellectual property deliver, e.g. a service level agreement for the delivery of poetry is likely to yield doggerel rather than consistently high quality verse.

To find further information about implementing service level agreements, look at our e-book at: e-Book – Implementation Guide for Service Level Agreements. This e-book includes a complete template for the construction of SLAs, enabling you to get a well-constructed agreement in place in minimum time.

When I draft my e-books, my editor often complains about my use of the abbreviation “e.g.”. She prefers me to write “for example” and, even then, there is always a struggle for me to get the commas in the right places.

Even worse, “for example” often is not all that I wish to say; often I’m trying to say something of the style “that is, for example”, so I wind up doubting whether I’m really wanting to “i.e.” or “e.g.”

I’ve decided to cut the Gordian knot; from this day hence, when appropriate I will use the newly coined T.L.A.* “i.e.g.”, meaning “that is, for example,”. I’m sure you will find i.e.g. a perfectly cromulent T.L.A.

* T.L.A. = Three Letter Abbreviation.

Google vice-president of search product and user experience, Marissa Mayer made an interesting observation recently, when speaking of on-line newspapers:

I can go to various newspapers and when you scroll down to the bottom, what do you do next? There were related stories and related videos but those were up on the top. So now the most committed user – the one that reads through the entire piece – is now looking at the bottom of the page with nothing to do.

It is well worth while looking at each of your web pages with the specific aim of ensuring that there is something engaging to reward your most committed site visitors, at the end of each article, at the bottom of each page. This is especially true for longer articles or pages.

When specifying text size in HTML markup by way of the font-size attribute in CSS, the units used can be either absolute or relative. Absolute units (such as pixels) mean that the website designer retains more control over the appearance of the page, but that requests from web browsers for larger or smaller sizes will be ignored. When relative sizes are used (such as ems or percentages) some additional testing is needed to ensure that the page does not become illegible or jumbled at large and small point sizes, but the degree of convenience offered to those whose vision is less than 100% is, in my opinion, well worth the extra five minutes of testing. Furthermore, relative sizing allows for both automatic and manual adjustment of the font size on devices such as mobile ‘phones.

I visited 40 randomly-selected websites and checked each for compliance with requests from the web browser to increase or decrease the text size (note that this is not the “zoom” function present in some browsers, it should affect text only. The results are as follows:

“Full” means that all text on the site resizes as requested by the browser, and that the end result is still legible.

“Partial” compliance means that while much of the text might resize as requested, some of it does not (or the site becomes illegible due to text overlaps); the most common symptom here is menu text which stays at the same fixed size.

“None” means that, apart from some minor and accidental spacing changes, none of the text responds to requests for size changes.

As I often do, when planning development of my text processor I consider first what capability Microsoft Word has. I have Word 2000; its “Thesaurus” function is really a list of synonyms (with the occasional antonym) rather than a proper thesaurus. When you look up “updated”, the Thesaurus form looks like this:

It’s not very pretty. There are four input boxes, four buttons, three labels and a control alignment which appears to be largely random. The substantive content is a flat list of synonyms. It occured to me that there might be better designs available.

After some trial and error, I have ended up with the following design in my text processor, Weblex:


The synoym list uses a Windows Tree-view; when you select a synonym by clicking on it, synonyms for that synonym are presented, as is the case for “modernism” displayed above.

There are two input boxes and three buttons, one label. One of the buttons is additional to the Word fuctionality (“Find on WWW”), so the net reduction in clutter is quite significant.

The moral of this story is that, despite the owerwhelming number of designers, software engineers, ergonomists, hair-dressers and spin doctors in the larger software development firms, it is still not only possible but indeed feasible realistic practical workable viable to compete with them on good design.

In 1980, Martin Porter published a stemming algorithm for English words; stemming is essentially the reduction of a word to its stem by removing its suffixes. Thus, for example, the word “stemming” can be reduced to its stem “stem” by use of Porter’s algorithm. This is immediately useful, since, when searching for the word “stemming”, we can also search for the word “stem”. Normally “stemming” will not match with “stem”, but, when reduced to its stem by suffix removal, it will.

The Porter algorithm removes about 150 common suffixes by way of an algorithm that occupies about 400 lines of Pascal or about 100 lines of Perl, courtesy of the latter’s regular expression library. For those looking for implementations of the algorithm in a variety of languages, the best starting point is Martin Porter’s own website,
tartarus.org/~martin/PorterStemmer/.

The algorithm is useful for searching (Google makes use of it) and a variety of language processing tasks. One interesting use is to find alternate bases for synonym searching. In my “weblex” text editor, when a user seeks synonyms for the word “interesting” the following happens:

1. synonyms for “interesting” are sought in the synonym dictionary and presented to the user
2. the stem “interest” is determined using the Porter algorithm
3. synonyms for the stem are sought
4. about 150 suffixes are added to the stem and, for each Frankenstinean suffixed form, synonyms are sought and presented to the user together with the suffixed form

One possible optimisation would be to check whether each suffixed form is an English word before seeking synonyms, but as the process descibed above completes in milliseconds this
does not seem to be necessary.

Software documentation and comments are highly variable in quality and usefulness. At the useless end of the spectrum are the detailed source comments which tell you what the next line of code is going to do. As the next line of code tells us exactly the same thing, this is at best pointless; at worst, when the comment does not accurately describe what the next line of code is going to do, it can be seriously misleading; here’s an example of what I’m describing:

#increase each object's value by 10
for (sort keys %objects){
$_ += 10;
}

Perl programmers will notice that the code does not increase the object values, but rather the keys of the %objects hash, so the comment is not only redundant but also plain wrong.

On the other hand, very high-level, abstract documentation which tells us what a program or function library does conceptually is only useful in a very high-level, abstract sort of way.

One type of documentation which is much more successful is the “Javadocs” style of functional documentation, which describes each function (or subroutine or procedure) principally in terms of its inputs and outputs. “Javadocs” is a documentation methodology maintained by Sun Microsystems, originally intended for documenting Java functions, but easily adapted to almost any other language. Here’s an example of the use of Javadocs on a PHP function:

/** * Returns the capability for a given capability name.
 *
 * @author Modulus Pty. Ltd. - prh
 * @version 2008 1.0
 * @param $id unique string id of the device
 * @param $name string name of the capability
 * @param $fallback boolean for considering fallback

 * @param $fallbackChain array of strings, where known, provide this to avoid unnecessary repetitive lookups
 * @return string capability

 */

function lib_getCapability($id, $name, $fallback, $fallbackChain) {
   ...
}



This documentation is immediately useful in the source code for developers maintaining or altering the source code. Furthermore, the effort required to create and maintain the documentation is quite limited in relation to the benefit derived. However, you may wish to publish an API to your functional library without publishing the source code. One way to do this is to use our javadoc.module,
which, for a modest $19.95, creates elegant, valid and conformant XHTML documentation from Perl, PHP, Javascript or Java source code. Here’s an example of the output generated: