Title: You Write - The Editor Responds

Dear Francis,

Periodically we get a letter to C Vu such as the one in the last issue: I took a degree in a non-computing subject but like programming why won't someone employ me as a programmer. This letter is a little different in that the person is already employed in SW.

Whilst his efforts to learn C++ are laudable what about the other "fringe" elements? Such as OO and structured design methodologies, project control, system analysis? Looking back I also covered real-time systems, databases, communications, C, Mod2, assembler (even a bit of Ada). There is a LOT more to "being a programmer" than learning C++. The writer suggested that he would be prepared to enter the profession as a new graduate and not count his experience. I assume this is as a new mathematician? As I said even on a Computer Systems Degree specialising in embedded and real-time I had to do some database work so I would think the writers experience in databases is germane. The writer says that SW engineering is a profession. Well like any other profession: to enter one must take the appropriate exams. With a maths degree one would not expect to become a doctor just by doing a few medical courses. So why assume that one can or computing?

There is one disturbing aspect of the letter. The writer is in programming. He is doing databases and SQL. C++ is just another facet of SW engineering. As I have said both are usually covered on computing degrees.

C and C++ are just a small part (despite what some may think) of SW Engineering. On my last project (C) only 20 percent of the time was actually programming. Less than 15 per cent on the project before (C++).

C++ was "the new kid on the block" much like Java is now and C was a few years before. The language is largely immaterial. Both C and C++ (like COBOL ) may well be dead in 5 years. I was taught Modula2 and Smalltalk because at the time they were going to save the world (and C++ was not). I would not base a career on a language.

My advice is to carry one gaining experience in the industry where you are. Prove your computing skills and see if your current company will let you move onto projects with more of a C or C++ content. Otherwise go and get qualified in the profession in which you wish to work.

Regards

Chris Hills <chris@phaedsys.demon.co.uk>

There is a great deal of truth in what Chris writes. None of you would consider ability to use the tools of an electrician as sufficient qualification for employment as an electrician (though many cowboys seem to think that just partial familiarity with the tools is enough). As in many jobs, employers reasonably take on people with suitable talents as trainees. What is unreasonable is those that consider that those who are graduates in some other discipline (actually I would argue that that term should include Computer Science) only need to learn a programming language to be fully trained software developers..

Francis,

As a computer science graduate, now with 8 years commercial experience, I hope I can offer some advice to that particular recent graduate.

I agree with you that the actual degree subject matters little, in fact, it is sometimes thought (by some employers I have worked for) that computer science graduates "think they know it all". They sometimes actually prefer maths/science graduates.

In addition to this I'd like to point out that as a computer science graduate I probably learnt about as much C++ as would fit on the back of a postage stamp; and I attended one of the most respected Universities who teach the subject.

I would urge the graduate to politely discuss his/her concerns and desire for work in C/C++ with his/her manager. I once left a graduate position due to the work and when I left my manager said, "why didn't you just tell me you wanted to do XYZ...". If you don't ask -you won't get!

5 years ago I was a graduate recruit with no commercial C/C++ experience. I applied for a job with a large very well known retail bank for a relatively low salary in order to get trained in C++. I am now still learning C++ (have been for whole 5 years) and write C++/Windows NT/SQL Server software for two blue chip companies on a contract basis earning over 3 times my previous annual income.

I suggest that if his/her present employer simply cannot, or will not, move him/her to C/C++ then it is time to apply for a position which involves SQL Server/Access (current area of expertise) in conjunction with C/C++. I have yet to work on a project simply involving my knowledge of C/C++.

And, it should also be remembered that the job market is also all about supply and demand. In my experience (as an interviewer) in the South East there is a huge shortage of people who really know C++ - I find it amazing sometimes that people who claim to know C++ cannot even tell me what a default constructor looks like! In other words, sometimes employers cannot be too choosy and have to pick candidates who they believe have a genuine interest in the subject and the ability - not necessarily vast amounts of experience.

Finally, I wish him/her the best of luck.

Stefan Bates. <stefan.bates@btinternet.com>

Thanks for the comments. The best advice I have ever been given was when I was a young teacher. My deputy head commented that there is nothing in the World for the dumb and that generally the worst you get when asking for something is 'No.'

Dear Francis,

I read David Watson's article on internation-alisation with interest. Actually this is stretching the definition of 'internationalisation' a bit, if you define it as 'taking code that was meant for one language and modifying it to work with others'. The process of I18N (an abbreviation for 'internationalisation' - count the letters) and 'Japanisation' can be much more difficult than writing code from scratch.

I am very surprised that Shift-JIS is being used in an embedded system. What was the reason for this design decision? It does not save memory, because in practise the set of half-width katakana that can be represented by single bytes are hardly ever used - they're half-width so they can be displayed on an 80x25 screen, but nobody really wants half-width katakana these days. Also the set is not really portable - JIS encoding (not to be confused with the JIS standard) and EUC encoding, the other two common encodings in Japan, have no support for the half-width kana, only full-width (actually, JIS has an escape sequence to go into a katakana set, but it's not usually supported). Neither do they support the user-defined set.

(By the way, 'kana' is a collective name for hiragana and katakana. It is not short for katakana. And another thing you're likely to encounter is 'romaji' - Romanised Japanese, and I won't go into the debates on what is the best way to write it....)

Many people do not like Shift-JIS. Its popularity is largely because it is what Japanese Windows 95 uses. However, it is certainly not universal. In particular, you cannot successfully send an email encoded in Shift-JIS (or EUC) without uuencoding it (or MIME-encoding it) because international email gateways are not eight-bit clean, and Japanese email usually sends in JIS encoding (with escape sequences and so on). So, if you are writing a Japanese email client for Windows 95, it needs to send and receive email in JIS but work in Shift-JIS. Actually, if you're writing software for Windows 95, you need to know about most encodings anyway - somebody might paste some EUC (say) into your application and you have to know what to do with it.

Actually, JIS encoding for email isn't perfect either, because the escape characters are sometimes stripped. It's a pity you can't represent Japanese using Hz encoding, an encoding used for Chinese that uses entirely printable characters, with the tilde as an escape character.

Back to your embedded system. I don't know what the application is, but I have a feeling that you're shooting yourself in the foot by deciding to work internally in Shift-JIS. The code that you write will be rather more complicated than (say) EUC, and there will be more to go wrong. You have probably now advanced beyond the state of being able to totally change the design, but if it were me I would work internally in EUC (actually I'd work internally in whatever format takes my fancy) and just write conversion code at the appropriate places. But I find it hard to imagine how much conversion an embedded system will need to do anyway - is it meant to be plugged into another computer?

Minor nitpick: I'm not 100% sure if your description of what Hiragana and Katakana are used for is entirely accurate. Usually Japanese use Kana for 'little' words like particles, and I don't think it's possible to write meaningful Japanese in 100% Kanji. Kana is not meant to be just an aid for learning. Also, Katakana is not just used for foreign words but for advertising, formal writing and so on. I read somewhere that Hiragana is considered more 'feminine'.

My understanding is that Kana are primarily used for particles, adjective and verb endings etc. In addition you will sometimes find small print kana beside Chinese characters to show how they are to be read.

One common problem you might be interested in is the fact that JIS includes a double-width Roman set, which is different from ASCII. This usually causes Japanese computer novices on the Internet to get confused. They may think they are writing to you in English, but they are encoding it in that double-width set (because they haven't switched into "US mode" or whatever), and if you don't know how to decode it then it might as well be Japanese. The worst problem is when they start writing email addresses and so on in the double-width set - not only can unconfigured English computers not read it but neither can they copy/paste it successfully. And I have seen HTML and URLs written in that set (at this point I usually write in to the webmaster and point it out).

Another common problem is when a web server lies about its character set. In my own program, I totally ignore what the web server tells me (I'm thinking of adding a "don't ignore web server" option) and use an auto-detect. In Chinese, a fre-quency table of the most common 500 characters works wonders (and I don't know why more software doesn't do this). In Japanese you can get away with checking the ranges of characters.

With regard to setting locales, I don't know that much about them either but I don't think they will help you. As far as I know they set things like whether to use a comma or a dot for the decimal point. If you're looking for CJK (Chinese/ Japanese/Korean) support at the language level, I think you'll be disappointed. (Oh and by the way, perhaps I should acknowledge that CJK is a registered trademark. And I'm English™)

I wrote an overview of my own adventures in this stuff on http://www.cam.ac.uk/CambUniv/Societies/cucs/databus/multling.htm but perhaps it's a bit big for C Vu.

Silas S Brown <silas@earthling.net>

Hi Francis

I know this is probably too late to get into C Vu 11.2 (it's now the 15th December) but I felt that I ought to respond concerning your musings on the future of ACCU publications in general and C Vu in particular. Also, I'm currently unable to access the Usenet and so unable to post this to the newsgroup, hence sending it to you instead.

Call it naïvety, but I was very surprised to read your assertion (;-)) that a lot of people never read C Vu because they feel that its contains subjects that are of no interest to them. To me, that is one of C Vu's great strengths: I never know what topics will be covered in what proportion in any issue, which increases the anticipation in receiving it. I would be the first to admit that I do not read every word if every issue, but that is my choice: my point is that a catholic choice of material is available for me to pick and choose from as I see fit. For example, my experience of Java is limited to a command-line "Hello World" program, but if I want to broaden my view, all I need to do is pick up a C Vu and read of someone else's experience with this rapidly-developing environment. Similarly, my knowledge of Web-based programming is zilch, but I read Silas Brown's article "Security Implications of Running a Web Gateway" as this is a hole in my knowledge that I wish to fill. This option would not be possible if C Vu was to be split up into separate publications. And if said publications were to be bound into a single cover (as mooted in your editorial), is there really any difference from a differently laid-out C Vu?

My main point is that the suggested change could lead to a fragmentation of the ACCU. It seems to be the case that different 'factions' within a whole tend to regard their own interests as all-important and everyone else's as irrelevant. If each group were to have its own publication, how long would it be before (for example) the members of the Java SIG felt that ACCU did not meet its needs properly and broke away? (This is only an example, so no flame mail from Java practitioners (Javanese??) please!!)

The above are just my rambling musings on the subject: I fully take your point that there is no point in producing a journal that does not meet its membership's requirements; likewise Jon Jagger's point that, currently, SIG subscribers effectively subsidise C Vu by having to subscribe to C Vu whether they want it or not. (BTW, I subscribe to Overload and find that it and C Vu do a good job of complementing each other.)

Right, enough of that: I also wanted to thank you (appallingly late) for the excellent conference at Oxford in September. I enjoyed it enormously (even Kevlin Henney at his most brain-straining) and felt it excellent value for money - helped by the fact that my employer reimbursed me :-). I think Kevlin's skull must be built on the same principle as Dr. Who's Tardis (bigger on the inside than the outside) - how else can he fit all that knowledge in? My only gripe was that the timetable meant that I had to choose between listening to you and to Kevlin - you lost Francis. I am not going to complain about the seating at the Oxford Union - I've had to sit in the Sheldonian! (For those not familiar with Oxford, the University's Sheldonian Theatre possesses the most excruciatingly uncomfortable seating in the world - the Marquis de Sade himself could not better it.)

Anyway, that's it. Many thanks for an excellent organisation. Best wishes for Christmas.

Charles Liddell cliddell@cix.co.uk

Well how do you like the revised proposal? However all solutions rely on the right volunteers coming forward. I wonder how many of you would happily edit at least a section if you knew that you would not have to be copy editor, do the page layouts, design the cover etc. as well as selecting suitable material. If you feel able to be purely an editor as long as you are not expected to be responsible for a dozen other jobs for which you have neither the skills nor the time, let me know. We may have a solution.

Francis,

I'm late putting this together, but I hope any readers have good memories!

C Vu 11.1

Silas Brown's Web gateway article

Point 3 NT server security. It's true that the default permissions with Internet Information Server 4 are not good enough. But you can stop executables being downloaded if you are thorough. People do tend to forget that executables may be binary, but any file names and paths are normally unshrouded. The directory architecture on my system is something I don't intend advertising.

I'd also like to echo Silas's comment about checking logs. Our IT services people ran a set of unannounced break-in checks against servers (public and private) on our network. They were targeting common Unix server weaknesses, so my NT box wasn't vulnerable. What was frightening was that of the couple of dozen people who should have noticed, I was the only one to raise a query.

C Vu 10.5

Richard Court's comments about writing GIF files

It is possible to generate Run Length Limited compressed GIF files that can be read by GIF decoders. It was written to get around the Unisys patent restrictions on the LZW scheme. The only example that I am aware of is part of GD 1.3 (http://www.boutell,com/ ), which is a library for generating GIF diagrams. The full GD system isn't very 16-bit friendly because of limits in memory allocation, but it works fine under DJGPP. There are a couple of console interpreter front ends available too.

Why no Java for 16-bit Windows? Lack of long filename support, I think!

Apropos nothing much at all

If anyone wants an alternative to Adobe Acrobat Reader to look at PDF files, try GSView/Ghostscript. The Adobe 5.50 release seems better than the older GNU 4.03 version if the licensing isn't a problem. See http://www.cs.wisc.edu/~ghost/index.html

Graham Patterson <G.A.Patterson@reading.ac.uk>