« October 2004 | Main | December 2004 »

November 30, 2004

Too many Perls

Why do people invent new programming languages? In some cases it's for commercial reasons - they want a share of the cake and really they would be far more efficiently employed elsewhere; I guess that languages such as J++ and C# fell/fall into this category, but then that's a personal view that not everyone might share. For sure, such languages can end up being a success, but often at the expense of a different and perfectly good language that was already around.

Other languages (I think we can call Perl 6 a "new language") are a genuine move to new ground - in the case of Perl 6, taking a language that's coming up to 20 years old and using what's been learnt in those last 20 years to provide something designed for the next 20. When Perl was first written, functions like format and write were a vital part of the language and the "." operator was a natural for string concatenation.

Yet other languages fill niches. PHP is a good example; it's (?) the first language to be truly written to provide web site content rather than simply embedding an existing language in web pages or interfacing it through CGI. And the result? For the niche that it's in, it provides a really excellent solution with little compromise to other wider application area - and it's made it big as a result, now being available on about a third or worldwide domains.

PHP's success is based on the premise that it's a web language and modifications, developments and enhancements are aimed in that direction. It turns out that it's also very good for certain stand alone use, and I'll even encourage people to use it stand alone in certain circumstances but that's not its main thrust and to add facilities to the language to improve its support for a non-core use at the expense of its core use would be a mistake. I was, then, very happy to listen to Rasmus Lerdorf talking on this subject last month - to hear him say that the future direction remains the web and that the language is not looking to widen itself into a general purpose computing language. I think he's right; we already have one C and two Perls, and three Perls (one called PHP) would be one Perl too many.

Posted by gje at 05:59 AM

More about Graham Ellis of Well House Consultants
Useful link: Perl training

November 29, 2004

Geekmas - a brief review

What a fun weekend!

Thank you for coming everyone!

Now it might not be everyone's idea of fun, but our training room was stuffed full on Saturday afternoon and Sunday morning with "geeks" - I hope you don't mind me calling you that - as we explored views and exchanged ideas on open source languages and their applications. Represented were commercial organisations, folks from the academic world, and independent contractors and small business people too.

Without exception, everyone made a great contribution to our enjoyment of what we christened "Geekmas" and it will be a slippery slope for me if I start to single out individuals - however - I'm going to take that risk and than Bruce for his talk covering Design Patterns, with examples written in Perl. Although I found many of the techniques familiar, it's the first time I've seen them formalised and presented in that way and I'll now be thinking about my classes (in PHP and Python too) in an extra new light.

For anyone who didn't make the weekend, there's an agenda on this web site with links in it to the material that we covered.

Posted by gje at 08:14 AM

November 28, 2004

Tcl embeds

Tcl is perhaps the most "niche" language in which we provide training courses - and also perhaps the oldest. It's used as an embedded language - being written into larger pieces of software to provide a tailoring capability for the users. This means that typical users are required to write just a few lines of Tcl (rather than a complete application), and many of them are programming novices - our public Tcl course is unusual in that we get trainees without prior programming knowledge, and the course is designed and paced to suit them. Tcl is also a little unusual in that we run a lot more private courses than public ones, as trainees often come in groups rather than being "singletons".

Amongst the systems that use embedded Tcl are Vignette (through their VCMS adaptor), UG (Post Builder), Cloverleaf (where callouts are made to Tcl procedures) and Radia (formerly Novadigm, now part of HP). Add to that list a number of applications in the IC and circuit design industries, and I think you'll find that Tcl will be around, thinly spread but important, for years to come.

Posted by gje at 06:45 AM


Useful link: Tcl training

November 27, 2004

Portrait of the author

You could walk past this stockily-built 36 year old of Scandinavian decent, polite, short haired, short trousered on this cruise ship and not notice him amongst the other 2000 guests. And, yes, he can and does circulate freely without challenge. Those few of us who know who he is respect his privacy, and the rest of the ship haven't heard of him.

Who is he? He's Rasmus Lerdorf, originator of the PHP programming language that powers much of this site, and still very much in charge. And, when you have the opportunity to listen to him for a day as I did yesterday, you come to realise that it's no accident that PHP is the great language that it is - he's an excellent captain steering this Open Source ship, and he knows where he's headed and when he's not going too.

"I don't care" is a common saying of Rasmus's. But you have to hear him saying it to put it into context and to understand him. He's written PHP as a templating systems that's now a language for web content and he's done an excellent job. Keep it simple. Keep it easy to use. Keep it on target for the application for which it was designed. Enhance it to support new technologies within its area, but don't try to add and add features to meet everyone's requirements away from the Web and templating. If such features were to be added it would be slowed, obfuscated, harder to use and it would inflate like a balloon. Inflate a balloon enough, and it bursts.

So - if you're using PHP for exotic applications away from the Web, you'll find Rasmus saying "I don't care". You're very welcome to use it, he's not saying don't ... but you can't expect him to support enhancement requests you make. If you're using it (as Leah is here) for a Web Application, Rasmus has your application and your future as his mainstream design goal for the future. And the PHP ship has an excellent captain; I'm delighted to be on his vessel.

Posted by gje at 09:09 AM

November 26, 2004

Thanksgiving dinner

Yesterday was American's Thanksgiving Day, and having a wife who was born American in North Carolina and lived for many years before I met her in Florida, it's one of the special days / times on a par with Christmas and Easter that we celebrate a little. We sat our our dining table with friends and family who happen to be around (a small group as it's a midweek evening between 2 working days in the UK) and shared a turkey dinner with Richard and Maureen, Stephen Norman and Ian.

Thanksgiving is, traditionally, a time to consider how fortunate you are - and we are indeed very fortunate. I'm thankful for family, for health, for being able to spend my time doing things that I enjoy, for that time spent earning me a living, for having a roof over my head .... and this is beginning to sound rather like an "Oscar acceptance speech". Let's keep it short today - let's just say thankful for everything - even that which might appear negative since it's usually a strengthening experience.

Posted by gje at 06:38 AM

November 25, 2004

Spelling and grammar

Here on "The Horse's Mouth" and in our Forum, you'll find many writings and posts that have spooling mistooks and where the grammar aint quite right.

I do try to type accurately, but this is very much a diary, and forum answers are pretty informal too, so I'm not too worried about the odd letters transposed. I do try to ensure accuracy of sample code by running it before I publish the page.

Other can post comments here, and ask questions on open talk. Do I correct their spelling and grammar? No - I don't - I let it be. Only where an incorrect word claerly causes a change of meaning will I jump in (my own common error is "now" for "not") and edit, and I'll add a footnote to say what I've done. Where a post shows a misunderstanding of a subject and draws an incorrect conclusion, I'll add the what / why / wherefore in a separate post.

But if you find any typos on our main site - PLEASE email me - at graham@wellho.net and you'll find that I both acknowledge with thanks and have the page fixed in very short measure.

Posted by gje at 08:43 AM

November 24, 2004

Trawling our site to prevent student copying

Updated March 2007

We keep "an eye" on our web traffic - watching for broken links, unusual patterns of access, heavy traffic in particular areas, etc. Yesterday, I came across a crawler known as the TurnitinBot with sufficient accesses to our site to put it high up the list of browsers. A new one on me; visited their web site and learnt " This robot collects content from the Internet for the sole purpose of helping educational institutions prevent plagiarism."

I don't know whether to laugh or cry.

My first reaction was to say "Of all the damned cheek" .... like many sites, we generally welcome robots because they provide a service for both our potential users and also for ourselves, by telling people about our web site / helping with our marketing. But here is this new crawler using considerable bandwidth and saying "We're not here to help YOU - we're here ONLY to help educational institutions .....".

But then, I guess I'm in favour of students handing in their own work rather than someone else's - both in order for it to be a "level playing field" and in the longer term so that people we might look to employ are thinkers rather than duplicators. And I guess I have a slight feeling that I'm delighted that this robot feels that our content is actually worth indexing in the fight against copyright theft.

What irks me slightly is that the robot is being used for an out-of-the-normal purpose, and it's a purpose that provides us with much obvious (and perhaps lesser) benefit, an the operators just helped themselves to our bandwidth without so much as an introductory email. To be fair, they did check (and are re-checking every 12 hours) our robot exclusion settings through which I could ask them to cease indexing us.

In the light of day, I'll probably let the robot index our pages. It's been going through our Open Talk Forum with great vigour, which means that it's protecting not only the content that we at Well House Consultants have written, but also the content of our contributors.

Addition - March 2007. I note that my concerns are NOT alone about this company - the Washington Post reports: "Two McLean High School students have launched a court challenge against a California company hired by their school to catch cheaters, claiming the anti-plagiarism service violates copyright laws. The lawsuit, filed this week in U.S. District Court in Alexandria, seeks $900,000 in damages from the for-profit service known as Turnitin..

Full Article

I have to admit that I'm in support of this Student's case - I feel the company acts arrogantly in the field of breaking individual's copyright and imposing traffic loads, etc while at the very same time claiming to be providing a service to prevent such copyright breaches. A case of the pot calling the kettle black.

Posted by gje at 06:49 AM

November 23, 2004

Technical Weekend / Geekmas

Coming up - this Saturday and Sunday. Meet other geeks, discussions, talks - from lunchtime Saturday through to lunchtime Sunday. Curry in the evening. Email coming overnight tonight to anyone who's signed up with final details. Anyone else welcome but please let me know.

Links:
topics to be covered
admin and organisation

Posted by gje at 08:40 AM

November 22, 2004

Conversion and coercion in Java

The accuracy and conversion of primitive arithmetic variables in Java is something that I'm questioned on regularly.

Ideally in Java, you'll perform arithmetic on two pieces of data of an identical type, and the result returned will be of the same type. However, if you perform a calculation on two different types the "least accurate" will be coerced up to the accuracy of the second. For example, integer is coerced to float which in turn may be coerced to a double.

What does this mean?

CalculationtypesResult type Stored in variable
of type
a = 5.0/2D/IDD
b = 5/2.0FI/FFF or D
c = 5/2I/III L F or D
d = 5/2.0I/DDD
I - int L - long F - float D - double

Note that a constant such as 2.0 id double, whereas 2.0f or 2.0F is float.

If you wish to save a result into a "less accurate" variable, you may do so by casting it. For example
a = (float) (5/2.0)
will convert an integer up to a double for the division through coersion and will then cast it back to a float before saving it in the variable a

Select here for a download of my "variables in Java" training notes released under an open training notes license. Further examples of simple variable use in Java can be found in our modules resource centre.

Posted by gje at 03:04 PM


Useful link: Java training

Feedback shows the tip of an iceberg

If there's something wrong with your website, you can drive so much traffic away and not even realise it. Let's say that 100 people try to make use of a resource that you have mis-labelled. Only 10 will actually find it, and of those only 1 will take the time to email and let you know.

How can I be sure of these statistics? I can't .... but I do know that a high proportion of traffic gets lost when something goes wrong, and that only a tiny proportion of people who still get through but with difficulty will actually write and let you know. This "square rule" makes all feedback received rather special and valuable.

I was reminded on this overnight - a new user to our forum had signed up using an email address which implied to me that any administration emails weren't going to be read. I wrote him a note (in the circumstances via the public board!) asking him to make amends; to my (I confess) surprise, he did reply - observing that no-one else had ever actually looked at it before. I'm going to disagree with his observation. I'm guessing that the majority haven't looked, but that a minority have. Of that minority, the majority have just rolled their eyes / deleted his posts / taken no further action. And I'm, it seems, the only one who has gotten back to him. He probably doesn't realise that he's alienated an "on the ball" minority.

Posted by gje at 06:46 AM

November 21, 2004

Staff theft

"Graham - do you know someone who could do xxxxx job for us?"

You would be amazed how often I'm asked that, and I have two things I say in reply:

a) The people who come on our courses are sent and paid for by their employers, and they send them to learn a skill for the job they're currently in. It would be a conflict of interest for me to put our trainees in touch with others who are looking to poach them from the very employers who are good customer of our and send their staff to learn.

b) Our trainees are here to learn and that means that they're new to the skills we teach. I have no formal way of knowing how any particular individual gets on once they have left us, though we keep in touch with many, see them again for other courses, get recommended, and do have a pretty good idea.

When approached for an introduction, I WILL see if I can think of anyone appropriate who has either paid for himself/herself on our courses, has let me know that he/she has moved on, or was sent in the first place by an employer as a "golden handshake" - an employer restructuring and helping the employee retrain to make him / her more employable elsewhere. In such a circumstance, I'm happy to make introductions.

Posted by gje at 11:33 PM

November 20, 2004

PHP v Java

Question to me yesterday: "Do you have a chart that compares the strengths and weaknesses of the various languages that you teach ...." to which I had to answer "Sorry, no". That's partly because it's like trying to compare apples and oranges, and partly because there are so many different scenarios and ifs and buts that it would be pretty tough to come up with a definitive and easy to follow document. But what I [i]can[/i] do is offer a number of insites, snippets, pieces of evidence that will help provide pointers.

For example:

I saw a demonstration yesterday of a web site, running on two browser windows on the same computer. The two windows looked identical, but were pointed to different test servers. One was pointing to a version of an application written in Java, and the other to a version written in PHP.

The gent running the demonstration clicked on a link on the Java version, moved to the PHP version, and clicked on the same link on that window. The PHP version can back to him (and completely redrew the window) before the Java version had even started. Upon questioning, I learnt that both servers were test machines that were very lightly loaded indeed, that the link ran some fairly compute-intensive code, and that the Java server was a higher spec machine than the PHP server. Their own benchmarks (run more scientifically) showed a 3:1 improvement in performance when switched from Java to PHP.

Conclusion: That you 're likely to need more compute power if you're going to write your application in Java rather than in PHP.

Conclusion about the language to choose: No definitive conclusion. For some projects (such as those with a large number of junior staff involved in a relatively secure big system development), Java may be a strong contender. But don't rule out PHP for some of the "traditionally Java" roles - especially with the private, protected, abstract, interface and final enhancements added at PHP 5 which allow for enforcement of encapsulation. Object Oriented PHP has really come of age in version 5 - and we're seeing a much more rapid update for applications that run on dedicated servers that I would have dared forecast.

Posted by gje at 08:52 AM


Useful links: PHP training, Java training

November 19, 2004

Short underground journeys and a PHP book

I know London; I was brought up here and I'll travel around by bus and tube (and train) quite happily; usually, I don't even need to bother with a map except, perhaps, a streetmap of the immediate area I'm visiting to find the right street and building.

I'm always amazed by the number of travellers who get onto a tube at one station and off at the next - I rather suspect they walk further under ground to and from the tube than they would by simply completing their journey on the surface - and they'll end up 2 pounds the poorer too. This week, I'm staying in a hotel 1 stop from the place I'm giving a PHP course and I've explored the leafy inner suburban roads of Highbury and Islington each evening and morning. I now know where to go to get Ethiopian Cuisine, and I've see the King's Cross end of the Islington canal tunnel for the first time.

But after the course last night, I *did* catch the tube into town - just too good an opportunity to visit Waterstone's (formerly Dillon's) and catch up on what's new in computing books. The more "regular" topics from the "usual" publishers we buy on line - they're a pretty fair bet and if there's the occasional "lemon" we still like to have a copy on our shelves and know why it's a lemon. But there's a welter of more interesting topics. I think it was on a previous visit to Foyles that we bought "Web Bloopers" by Jeff Johnson - ISBN No. 1-55860-840-0 and that's turned out to be one of the books most read by our trainees. It's not from one of our "regular" publishers, it's not an Open Source book as such, yet it's peculiarly thought provoking to many of out trainees.

Last night I picked up another book, interesting also published by Morgan Kaufmann, entitled "Multi-tier application Programming with PHP". Written by David Wall, ISBN 0-12-732350-3. I'll be very interested to see what others think of this book on our courses. It provides a useful tutorial with examples into how to write a PHP application (where the accesses are transient) that talks to a persistent level for efficiency and data storage. But I find myself slightly concerned at the number of global statements that are present in the code examples, and the use (in parts) of page full of echo commands. I was taught (and experience confirms my teaching) that too many globals are a bad thing, and that if you find yourself repeating the same thing (such as an echo) over and over, there must be a better way of doing it. Looking at the echos, they could be simplified into a single statement very easily - the code change almost SCREAMS at me. But perhaps the author wanted to cover the principles without getting bogged down in another piece of PHP syntax.

Posted by gje at 07:02 AM


Useful link: PHP training

November 18, 2004

Passing arrays to procs in Tcl

If you're writing a Tcl proc, you'll normally pass in parameters by value, specifying a $ in front of the variable whos contents you want to pass in in the calling sequence:
dojob $passin

If, however, passin is a Tcl array, tis won't work since $passin cannot be expanded to string. So you'll need to make the call using:
dojob passin
and then use upvar within the proc to access the data.

INDIVIDUAL ELEMENTS of an array CAN be passed in to a Tcl Proc by value as they're simple strings:
dojob $passin(demo)
or dojob $passin($elname)

References: our Procedures and Variable Scope and Tcl Array modules

Posted by gje at 06:17 AM


Useful link: Tcl training

November 17, 2004

Fair and Simple

Fair and simple

We welcome customers at our training centre on public and private courses. If they ask us to present our courses at their offices, we're very happy to do so, but we do charge them the additional expense this puts us to - basically travel and accommodation. Naturally, they want a fixed price quote for this ahead of time (no-one likes placing an order for an "open" amount), and for a number of years we've operated a scheme based on travel at x p per mile and overnight expenses at y pounds per night I'm staying away.

It's a simple scheme, and it averages out so that the money we charge is usually about the same as the expenses - in other words, we don't look to make any profit on it. Fair? Well - it was fair 2 or 3 years ago, but hotel prices in London have been creeping up, car parking there is expensive, and there's also the congestion charge. And that means that our scheme has become less fair - it means that if we raise expenses across the board, our "provincial" customers will be subsidising our "capital" ones.

So - a moral dilemma - keep it simple, or sacrifice some simplicity to keep it fair.

All London courses confirmed after 1st January 2005 will be subject to a higher "overnight" expense charge - an extra 30 pounds per day - and our non-London course prices (and expenses) will remain unaltered.

Worked Example - Visit the web site of a typical hotel chain - I'm in London at a Travel Inn this week (King's Cross) at 83 pounds per night; I was at their Nuneaton hotel a fortnight ago, and there the charge was just 46 pounds per night. I can park, eat and pay for internet / phone on the change from 95 pounds in Nuneaton, but not in London.

Posted by gje at 07:05 PM

November 16, 2004

Good early morning

Good morning - yes - I'm posting even earlier than usual. It's pitch black outside at this time of day at this time of year, and I'm just engaging brain ready to drive and present a PHP course close to the centre of London. Time was when I would commute to present such a course - 4 to 6 hours of travel each day. But these days, I'll stay over. On a longer course with a heavy commute, an inevitable fatigue would lead to a lessening of training quality by the third and fourth day and as well as the course quality, my quality of life during the course would suffer. The Travel Inn at King's Cross is a much more practical solution.

Posted by gje at 04:20 AM

November 15, 2004

PHP course. Come by train.

In a couple of days time, trains will be stopping at Melksham Station throughout the day once again. As from next week's PHP Course we'll be able to resume meeting students off the 09:11 arrival. Please let us know ahead of time if you wish to use this service, for which we make no charge.

For the past 10 days or so, our railway line through Melksham has been in use as a diversionary route for trains headed for the West of England, due to the accident near Reading earlier this month that has blocked the main line. So many extra trains have been put through the single track that Wessex trains were required to suspend the local service after 7 a.m. each morning. In all the circumstances, we understand the need for this though it would have been thoughtful of First Great Western to stop a few of their expresses here to cater for the local traffic.

Since the train service to Melksham was dramatically improved in 2001, we have collected students off the 09:11 (formerly 09:21) arrival on the first day of the course, and returned them to the station on the conclusion of their course to catch the 17:07 or 18:18 services. On many courses, the majority of our trainees use this service, although we have plenty of parking if you prefer to drive.

Posted by gje at 07:34 AM


Useful link: PHP training

History around you

We live and work in an old Georgian house that's set incongruously just off the Melksham bypass on the outskirts of the town. This morning, I'm going to share with you an article I wrote for the newsletter that's circulated in the suburb that we border.

Have you even wondered about those tall old buildings hidden behind the trees off "The Spa" roundabout?

I used to commute regularly from Devizes to Bristol and pass by, wondering as to what they were and to their history. Now I'm lucky enough to live and work in one.

In the early 1800s, Chalybeate waters were discovered in the area and a scheme was proposed in Melksham to rival Bath. A ballroom was built, and a well head building. And in 1813 and 1814 a start was made on a 'crescent' of six lodging houses at which visitors to the town, coming to partake of the waters, could stay. They were built under a Tontine scheme that's a system where a number of people contribute, and as each passes away his interest passes to the remainder until just one is left. There weren't too many takers for the scheme, and just three of the Georgian blocks were built, as you can see to this day. The ballroom building is still here in the trees, and the Well Head is now under one of the more modern looking bungalows.

"Melksham Spa" didn't rival Bath as a town to take the waters; on one hand it was said that the fouler waters tasted, the better they were for you but on the other hand it was said that they tasted so foul that no-one wanted them. Within a very few years, the lodging houses closed their doors to their original trade, although the water was bottled and distributed until late Victorian times. We know of two "Melksham Water" bottles in existence; when in the possession of a collector in Bristol, he brought them here to show us.

The houses are "semi"s. Spread over four floors, they're really too large to be used as family homes, and too small for big business purposes; they've had a variety of uses over the years. During the second world war, they were taken over for the war effort and used as officers quarters for RAF Melksham. Post war, at least some of them were converted into flats. By the time we bought No. 404 in 1999, it had been converted back into a single residence but was - shall we say - in need of a great deal of attention. And it was (and remains) a listed building to add to the paperwork. Both the attached house, and also the next neighbour, had somewhat reverted to their original use as they were B&Bs (Springfield has since been sold and the new owners no longer offer accommodation though, leaving just The Spa B&B where many of our customers stay), and folks worked from home in at least some of the remaining three properties.

At long last, we're getting to the beginning of the end of our repair work to bring 404 back from the semi-dereliction that we bought. Works have ranged from laying trenches to bring in a new water supply (we had a single tap on a lead pipe coming through from next door when we moved in) and major waterproofing through to removing woodchip paper that was holding walls and ceilings together. Lisa and I work from home here, running high tech computer training courses in this elegant setting - at this stage in its history, would you believe that people come to Melksham to learn the programming languages used on the internet, and the languages used to progress research into genetics to help find the reasons and cures for diseases. I'll never forget the day a few months ago when we took a small class to Lee's for lunch. One lady on the course was wheat intolerant - a condition that was scarcely understood a few years back but which is far better understood today - and the gentleman across from her was actually undertaking research in the same genetic area to help others like her better live with and treat the condition.

Additional reading:
Download of our accommodation list
Melksham Resources
Some interior pictures

Posted by gje at 05:09 AM

November 14, 2004

A case of case

Do you have people enter their (postal) addresses on a form on your web site?
Does everyone lay out their address as it should be on the postage label?

If you've answered "yes" to the first question, I'll bet you've answered a resounding "no" to the second. It depends on just what you're selling online (and so on how net-aware your users are), but chances are that many people will supply their addresses all in one line, and that many will be all-capitals or all-lower-case. We've found that (in general) these problems apply to 1 in 5 submissions.

But what to do?

Catch 22.
If you always re-capitalise the first letter of each word only, you upset the daVinci-s and MacDonalds.
If you leave alone, your labels will look unprofessional and some bright spark will tell you that you're rude to use a lower case letter at the start of his name.

The solution that we've come up with over the years is as follows:

Check the address for case (in PHP, ereg("[A-Z].*[a-z]" .... will check for upper followed by lower)
a) if the user has entered it using both upper case and lower case characters, then he/she probably knows what he/she's doing and it should be left alone.
b) if the user has entered it in a single case, force it all to lower case the capitalise the first letter of each word - if you're using PHP, functions strtolower and ucwords will do this for you.

THEN check the address for new line characters
c) If you have at least one new line character between "printables" you can once again assume the user knows what they're doing
d) If you don't have embedded new lines, try replacing "comma-space" sequences with a new line, but not is that leaves just a number on a line on its own!

No solution id 100% user-proof but you should find the above deals with 95% of the rogue entries!

Posted by gje at 08:25 AM

November 13, 2004

The next generation of programmer

Ten years ago, I was teaching languages like Shell Scripting and C, but the requirement faded. As computers became steadily more powerful, standard applications were developed by a few, to be used by the many, rather than each of the many having specific code written for them.

So now, I'm teaching languages like Perl and PHP which are being used as "glueware" to connect data that's going in and out of other pieces of software and is in other standard formats. I finished a Perl course yesterday evening and there we were talking CGI, HTML, XML, SQL, Apache. POD, Makefiles and other such components and using Perl as the link. What would have taken a week to write, test and develop 10 years ago now takes just a morning.

But if goes further - is there really a need to write a great deal of code at all? The web site on which I'm publishing this article is using a standard (Perl) package for the purpose, and a standard (Perl) package for the Forum that's also here. We're using a standard (PHP) piece of code to identify which country a user is located in when they visit the site .... and a standard database to hold library book information.

So is a programming knowledge and skill still useful? Yes, utterly. In interfacing the different applications. In providing "mods" and tailorings for them. I've just written a short piece of code to allow posters on "opentalk" to use the same email address to post comments to "The Horse's Mouth" without having to await approval, and another bit of special code added mean that new articles here are automatically referred to be relevant pages on our main site.

Looking ahead, I see myself teaching more and more "interfacing" type courses, and getting involved with pieces of code / modules that talk to more and more standard packages. SMB, OS Commerce, Moveabletype, YaBB, Maxmind, Plone ...

Posted by gje at 03:33 PM

November 12, 2004

Expiration dates or times on web pages

I enjoy providing helpful answers on line - just have a look at how active I am (for example) on Opentalk and you'll see questions and answers flowing back at the rate of several per day over several years. I'll even "research" the more interesting issues although I can't guarantee complete solutions from a free service.

But occasionally I get frustrated. A question is posted, and (less that 24 hours later - which is our stated target) I'll get a few minutes to look at it / follow up. "Oh - I sorted that out just after I posted" comes the reply. "I'm fixed" .... well ... thank you for telling me!! Thank you for having me, out of the kindness of my heart, wasting my time over you!!

This is an endemic problem. I was reading a message elsewhere just a few minutes ago - looking through a history. "Can you advise me where to find" .... and a couple of responses. Then another response "I've been looking around - have you tried xxxx" to which the reply from the original poster was "oh - we got that fixed a long while back".

And so I make a case for putting an expiry date on web requests and web pages. With a newspaper advert, you knew it would be active for a day or a week then history. A card in a newsagent's window is paid for a week or two then expires. A timetable says "until 30th September 2005" or something like. But a web page goes on and on.

Netiquette suggestions for time-dependent pages:
* Provide the date and time for event(s) if you're talking about events
* Give an idea of how long you'll be leaving the question open
* REVISIT THE PAGE and post when the issue is sorted (the flat found, the car sold, the code working)
* When you revisit, post what the solution was, and thank anyone who's helped you.

Posted by gje at 06:47 AM

November 10, 2004

Relative or absolute milkman

Rather contrary to current trends, we've just started taking regular deliveries of milk (+ bread + eggs) at our training centre from the local milkman. As we grow busier, it's more effective to have someone deliver to us as part of his round rather than having to make a special trip out. And our "mint on the pillow" approach to training means we really want to provide real milk rather than powder for the real coffee.

Monday's delivery - ace. Fine. AOK. A little bit of a stocking up order for the start of (another) busy week. For this morning, we asked for 5 pints of semi-skimmed milk. Sure - we got them. And a pint of Channel Island. And a pint of full fat. And bread. And eggs ...

At first thought - had our instructions been ignored? No - it turns out that our Milkman took our instruction as a relative path (i.e. changes from what we had on Monday) rather than an absolute path. Perhaps we should have written C:\ or / on the front of the order?

Why is this relevant to Horse's Mouth? Because so often people write their programs using a relative path when they would be better using an absolute, or vice versa, and it's a reminder worth making. Just this morning, I answered a question on Opentalk where my writer was having problems, I suspect, because of a changed current directory and a relative path.

When we look at file handling in Perl (or take a second or even a third look) - or when we get involved with file handling in PHP or Python or our other languages, we always try to stress careful file name selection in order to ensure that the user's script works correctly no matter what their current directory. I think I'll start telling my "milkman story" to help people appreciate the importance.

Posted by gje at 08:15 AM

November 09, 2004

A Parallel for Perl 6

Perl 6 is still sufficiently far ahead for me to need to know the general direction in which it's headed, so that its future use can be planned for, but it's too early to be actually trying to do any more with it in the general training arena. I've been pointed (thank you, Caitlinn) to an article by Teodor Zlatanov which talks about a building that's being built but isn't ready for occupation yet and I like the parallel. In his article, 'Ted' describes how you see a lot of activity initially on a building site as foundations are put in place, and then there's a period where little appears to be happening and there's just a lot of rusty steelwork to be seen from the outside. Yet it all comes together, somewhat quickly in the end.

One of the other great beauties of Perl (and Perl 6 too) is that it's designed to be usable at many levels. In other words, for an easy job it's easy to use and you don't need to get into the intricacies, but if you want to, you can get in there. Most jobs are easy, it turns out, so a lot of the RecDescent stuff mentioned in the article is, and will remain, a niche interest for the few while the majority of us get on with good basic coding.

Posted by gje at 06:51 AM


Useful link: Perl training

November 08, 2004

Avoid the wheel being re-invented by using Perl modules

"Don't re-invent the wheel". Such is the underlying philosophy of programming - if you re-write a piece of code that's already been written and tested, you're probably wasting time that could also be better used. You're also likely to be creating a longer term support issue - someone's going to have to look after your code in the future.

Am I discouraging you from writing new code? Yes, if the code already exists. But no - there are still things to invent.

Having invented something, you should make it as easy as possible for others to find and use it:
* You should be writing your Perl code for distribution in classes /modules. That way, you can encapsulate the logic that you need within the class and provide a neat and short way for users and other programmers to make use of what you've written.
* You should be using the structure that's already been defined (and become something of a standard) to add your documentation, test routines and support files to your class; this will package it in a similar way to that in which it would be uploaded to the CPAN
* You should publicise your module well so that it can be found easily by anyone who searches for it, even if they don't know exactly what they're searching for.

Samples of files that make up a standard module are available on our web site and our Perl for Larger Projects course will be updated to include extra coverage on this topic before the next public run in December.

I'm giving a Perl course tomorrow, which is why I'm thinking Perl today - but the philosophy described here applies to PHP and the PEAR, Python and the Vaults of Parnassus [[ or now - the Cheeseshop ]] and elsewhere too.

Posted by gje at 06:17 PM


Useful link: Perl training

November 07, 2004

Training notes available under Open Distribution license

We've released our complete Java Programming for the Web course material under an Open Training Notes license. We've also released all of our general modules on Object Oriented Design (used on Java, Perl, Python and PHP courses), and around 10% of our other material too - typically the modules releases are those on subjects which provoke the greatest interest, and aren't necessarily required to be presented as part of a complete course.


The Web site for this new material is
http://www.training-notes.co.uk


Do I hear you asking "Why?" Because we get a lot of requests for training help and material in Java, in connecting to an FTP server in Perl, in writing a shopping cart application in PHP. Sometimes those requests are from far afield, and other times they're from personal user - both groups for whom it's impractical to book a place on one of our courses for logistical or cost reasons. It's "no skin off our nose" to help them - indeed, we're delighted to share these exciting technologies with them - and if they want to learn more deeply, they can still book us to run a private course for them or attend one of our public sessions.

Posted by gje at 02:20 PM

November 05, 2004

Friday, busy week!

A non-technical thought today ... it's been a very busy week (and, yes, I still have a Linux Basics day to do today. I love giving programming courses. Last week was Python and next week is Perl - an extended private advanced course. Plenty of good practicals and the whole thing Jells. But this week has been much more "admin" topics - MySQL on Monday and Tuesday and Apache httpd and Tomcat Deployment on Wednesday and Thursday - both course which are 60% talk 40% practical rather than the other way.

Success breeds success, though. We set ourselves perfection as a goal (and, of course never reach it). I think we get nearer than most, and we constantly strive. Like climbing towards a high peak - once you're well up there, each subsequent step, small though it may appear, takes you even higher.

Posted by gje at 09:05 AM

November 04, 2004

URLs - a service and not a hurdle

"A URL should be a service that provides a visitor with access to the information that he/she wants, and not a hurdle that he/she must pass in order to access that information". I'm paraphrasing there, but it's what Rasmus Lerdorf was saying in his "do you PHP?" lecture last month.

Ours is a "sales and marketing" site, and I want visitors and crawlers to be encouraged to find the information they require, and index it appropriately - so the concept described above is particularly attractive to us, and I posted up here a couple of weeks back about how to implement this in practice.

We've implemented the scheme outlined on our main domain, and our "Error 404" traffic has been halved; it was already low, accounting for perhaps 1 access in 200, but it has now been reduced further - just 10 requests in 18000 yesterday (that's 1 access in 1800).

I'm voting it to be a success, but not blindly so. Failing requests are checked to see if they're calling for a known file in the wrong directory, or if they're calling for a URL that does exist except they have the capitalisation wrong. Such cases are diverted, and send out a "200 OK" header. Requests for html pages that consist of alphabetic names that don't otherwise exist result in a search of "The Horse's mouth" and an appropriate results page if there is indeed a "hit", again with an OK status. And users who try to call up Microsoft's FrontPage technology to update our site (!!) get a polite page asking them to let us know of any corrections that they feel are needed.

If none of these situations allows us to return a good page, we still return a "404", but as you see from my stats above that's now a tiny minority of cases.

Where did all the errors that we previously had come from? A lot of them came from poorly written spiders, or from accesses to pages that had briefly appeared on our site or brief incorrect links that the search engines had found (we also have a table of about 10 specific URLs with specific diverts for such situations). And now we *can* be helpful.

Is our scheme going to give us long term issues with search engines? The concern has been expressed that search engines can now index the extra URLs since they're getting code 200s back. Well - that's fine by us. It's a resource through which the page can be found and a route that lets the user mine the information they need. It's more likely to drive the traffic to our site, which provides us with much of our sales and marketing, up rather than down.

Posted by gje at 07:40 AM

November 03, 2004

A typical morning

Up at 05:30

Three posts to Opentalk (with a research program written to work out one of the answers)

Four customer emails answered, one of which included the need for online research and testing.

Training room tidied to prepare for today's Apache hpptd and tomcat course.

Travel and Transport Board at UK-Yankee checked to see if any responses or moderations needed.

Washed, showered and it's now 08:15.

Comments made in last 24 hours to this Blog reviewed, spam deleted. Now writing "the Horse's Mouth".

Post arrives, "scanned", passed through to Lisa.

Station pickup due at 09:10 - link

Course starts 09:45

Posted by gje at 08:16 AM

November 02, 2004

Taking Equipment offshore to run a course

I learn something every day .... and one of the things I learnt yesterday was how I can take equipment to and from places that are within the United Kingdom, but are not part of the EU. Yes - you read that right; the Isle of Man and the Channel Islands are not a part of the EU, but rather what I think is called "offshore" locations on our doorstep.

So why would I even be interested in taking equipment to Jersey or Douglas? Well - there are a number of big companies that have operations based at such places and indeed we have trained people who have travelled from both groups of islands in the past. Now we have a whole group who want a course there. It turns out that running a course on the Isle of Man is easy, as are courses on the Channel Islands.

Taking equipment to one of these locations:
a) Complete a customs and excise form (call their help line on 0845 010 9000 and they'll post one)
b) Produce two lists of the equipment to be taken, including serial Nos., on company letterhead
c) Check the equipment out with customs as you leave the country. They will stamp and retain a copy
d) Check the equipment back in with the second list on your return.
I've been advised to phone ahead to the Ferry port to ensure that there's a customs rep on duty.

Posted by gje at 08:10 AM

November 01, 2004

Far from the sea, but close to the heart

The town of Weedon in Northamptonshire was the home of a great fort built by one of the Kings George about 200 years ago as a last retreat against the invading French, and that location was chosen because it's further from the sea than any other place in England.

I wasn't too many miles from Weedon last week, training at a company where they have a "dress down" day once a month, and collect money from employees for local charities for the privilege of dressing down. Noble action, noble intent. Our talk turned to what constitutes a local charity, and we had a chuckle that one of their charities a couple of month ago was the RNLI - the Royal National Lifeboat Institution .... when they're so far from the sea! And yet, the RNLI is an organisation that, I believe, receives no government funding and does such good works. Far from the sea, but close to the heart.

Posted by gje at 07:36 AM