Title: Editorial

Another end to another academic year and the usual cohort of students have passed through the doors of the country's universities with their pieces of paper signifying the sum of their past three or four years of study. For some, it's their first step into the wide world of employment, for others - who can say. Sounds nice doesn't it?

The problem really is that there is a world of difference between the world of academia and the world of business and unfortunately for the students, they don't seem to realise this. Being up and in work for 9am is not normal, neither are long vacations or the excuse of having roadworks in the centre of Manchester enough to cut the ice.

For business there is a problem not only with this transition, but also when interviewing.

At the April conference, I was talking with a very nice chap about this problem. He cited one example (the waiter in the restaurant problem) which required a threading model. Now that in itself is not a big hassle, the difficulty comes in which threading model is used - the posix implementation or the one used by Microsoft? Typically, universities use the Microsoft.NET packages, therefore use the MS implementation and are not generally taught the posix model. Without knowing the posix model and without the employer specifying which model to use, the prospective employee really only has at best a 50/50 chance of using the correct threading model.

Is this the fault of the employer or the university? I would suggest it's six of one, half a dozen of the other. Yes, it is the responsibility of the university to teach both threading models (and to use both), but there is then the problem of having to have more than one compiler per machine. Not a huge problem, but given most machines work on a standard ghost image, this does mean additional problems when installing. There is also the time factor - a typical 3 year course really only lasts 18 months which is simply not enough time to include a second threading model without the detriment of another aspect. For the employer, it's both not talking to institutions about requirements and also possibly not specifying which thread model to use; a Unix (or variant) company will have almost no use for someone using the MS model!

Eh?

By the time this edition hits the doormat, the free implementation of the .NET framework, Mono, will be at version 1.0 and released to the waiting masses.

Mono gives all supported platforms access to the C# language and everything that .NET offers. How is this possible?

Well, unlike Sun, Microsoft decided to make the API for .NET open and have a published standard for the language. This has meant that anyone who wishes to sit down and implement the API will have access to this rather good language. I must admit that I didn't like C# originally (being more a cross over language than a distinct language - or so I was led to believe), but having used it both for fun and to review books with, I am very impressed with Mono and the C# language.

There are versions for MacOSX, Linux, Unix, BSD, Windows and quite a few others in development at http://www.go-mono.com

There is yet another new series starting . This time it's Objective C.

Please, don't think that just because there are lots of articles already in C Vu, that we're not after anything for a while, that's not the case. If you have something you think is up to being in C Vu, please send it in. Currently, I'm looking for a good introduction to C++ as well as material on Java and over on the Overload side of things, I know Alan is screaming for material!

There has recently been quite an interesting discussion on the accu-general mailing list regarding the temperature at which water boils at for a given pressure. This is right up my street having been a physical chemist in a previous regeneration.

Water, as we all know, boils at 100°C (1 atmosphere pressure) - perfect for a cup of tea. If you were to go up a mountain though, the temperature at which the water boils drops, sometimes as low as 75.5°C (roughly 8000m above sea level) - absolutely useless for making a cup of Earl Grey or Darjeeling.

There is a dependency therefore between the height (and therefore pressure) and the temperature water boils at. This has caused about a week's worth of debate. Anyway, I'll provide the answer for someone to provide the solution as a program. The shortest gets a prize out of the editor's lucky bag.

How to work it out though?

The answer is quite simple.

At ground mark, atmospheric pressure (in mm mercury) is 29.921 and as you move up from ground level, the pressure will decrease. This decrease can be calculated using the formula:

Pressure (in. Hg) =
   29.921 * (1-6.8753*0.000001
     * altitude, ft.)^5.2559

(these are from really old notes given during my degree, which is why I'm using inches of mercury instead of standard atmospheric units and feet instead of metres).

We know (from what we've seen) that as you move up into the atmosphere, there is a decrease in the boiling point of water. Again, it's quite simple to work this out:

Boiling point = 49.161
         * ln (in. Hg) + 44.932

(this is all perfect spreadsheet fodder)

Again, this is in °F rather than °C, so:

C = 5/9 * (temp in °F - 32)
1m = 3.282 ft

What the actual numbers represent have been lost in the mists of time (they had a nasty accident with some Old Peculier a few days after my finals!)

What you should be able to do now is transform this into a quick and simple program (you choose the language). Happy hacking!

I've had quite an interesting week this week.

Besides the usual rush to have the magazine ready for putting to bed (for which I'm sure we should all be charging our respective glasses to the sterling and hard work of our Production Editor who doesn't seem to get anywhere near as much credit as she deserves), I had an unusual phone call from somewhere that I had applied for a job at a while ago.

While that may not seem odd to quite a few people, it was odd to me as normally in the education sector, if you don't get the job, that's it - you don't hear anything back. This was unusual as it was to give me feedback on exactly why I didn't get the post.

Now, despite knowing everything required and being possibly the best candidate for the position, the reason for not getting the post was that the employer had done a web search on groups.google to see what could be seen.

On usenet, I have quite a high profile (and not just on the programmers groups) and unfortunately have been involved in a very small number of flame wars - one of which happened last year on the uk.comp.os.linux group. Now, as this is actually a matter of some ongoing legal action against the chap who started it all (and also a long running Police investigation into this character's nefarious activities), I can't comment on the nature of the flame, but because of it it the company decided to dig further... and further... and further.

In one sense, it actually helped my application as it showed the nature of how I work with a disperse group and the methods I employ to solve problems. On the other hand, the number of open source groups I contribute to made the company consider me possibly not the best candidate for proprietary work.

Let this be a lesson then: while usenet is fun and a very useful forum for learning on, it can act as a double edged sword.

But how does this apply to the us, the ACCU? Well, we do have a number of publicly open groups where not only members of the ACCU reside, but also prospective employers and those who just need help. It is therefore of paramount importance that a professional attitude is given and threads on the list kept on topic. All too often a thread begins with something sane, but by about 10 replies down the line, the original topic has changed, but the email subject title hasn't - very confusing and if you get the same number of emails as I do, then the probability of missing something useful increases.

It also demonstrates an important difference that should be recognised between a personal and professional persona.

For instance, it would be unprofessional for me to post from my ACCU account and be expressing a detrimental opinion against any particular vendor of any particular product as it could be considered as being that of the ACCU; something which may definitely not be the case. Now, the case is different if I post from my personal email address. Many who subscribe to the accu-general list will know my opinions of London, it definitely isn't endorsed by the ACCU or anything like that, but for some, the difference between me as the editor and me as, well, me is not always clear. Which is another problem with people when scanning usenet!

Enough of that ramble, many will be puzzled as to why I brought it up. The answer is simple.

One fund raising idea the committee has been considering is "selling" ACCU email addresses (in the same way as is done with the ACM), so it would be possible to have the email address paulf.johnson@accu.org - sounds nice, but having such an email address would put a distinct number of problems on us which would need a disclaimer to be added. However, how many bother reading disclaimers?

We have a standard one at work

Would that be enough if we were to make available ACCU email addresses? I personally don't think it would be.

This idea is still being discussed, but I'm sure your opinion would be greatly appreciated. If you have comments, please send them to the committee.

An ACCU email address and its inherent problems are not the only aspect where this distinction between ACCU-endorsed and not endorsed material raises its head. The other place is obviously in the book reviews.

A claim levelled by some book companies is that as we publish the reviews, they therefore must be the views of the ACCU. Again, this is not the case; all reviews are a personal opinion of the reviewer. This is definitely a problem with respect to the website. While we have a limited readership of the printed magazine, the book reviews are publicly available for all to see without any form of disclaimer as to the personal nature of the reviews. You can now appreciate the problem of a disclaimer...