Showing posts with label Computer Science. Show all posts
Showing posts with label Computer Science. Show all posts

Sunday, March 28, 2010

Ada Lovelace

Ada Lovelace was the world’s first computer programmer. She wrote programs to run on Charles Babbage‘s Analytical Engine. Unfortunately, the machine was never  built. I first heard of Ada when I started programming in 1996.

Match 24th was “Ada Lovelace day”, an international day of blogging (video logging, podcasting, comic drawing etc.!) to draw attention to the achievements of women in technology and science.

I missed the day itself, so I don’t know if I’ll create a post of my own, but I suggest you mosey on over to the list of existing posts.

-- Robert

Saturday, February 21, 2009

Atlantis... Found... or Not

Yesterday, British tabloids reported the discovery of the Lost Continent of Atlantis! The discovery was made, not by intrepid explorers, but by searching Google Earth's maps:

Can you see the highways on the bottom of the Ocean?


View Larger Map

Well, it seems that these highways are simply the paths of the oceanographic ships which mapped the area - Plato can rest easy, his hoax has not been discovered :)

Link to the tabloid "The Sun"

Link to better explanation.

 

-- Robert

Friday, September 12, 2008

Flush the buffer

A recent conversation in the Developerworks ITM 6.x forum dealt with an unusual problem with Universal Agents.
A few rows were showing up cropped - only the first part of the line was making it's way from the UA to the TEMS/TEPS database.

The root of the problem turned out to be the UA's "unflushed buffer". What is a buffer and why should it be flushed?
A computer program, be it a simple "hello world" application or a complex missile control system, can often be summarized like this:

Get Input -> Do Something -> Write Output and repeat.

Now, things get complicated when we try to be more efficient. Say we've got a script which is checking a series of files/disks/servers/anything. If it wrote the result of each check immediately then the hard disk writing heads would constantly be starting and stopping - which is not efficient. What happens (behind the scenes) is that the operating system creates a Buffer of information which holds the lines temporarily. Once enough lines have been written into the buffer, the buffer is written (flushed) to the disk. This translates as much less starting and stopping of the disk heads. If you run the script yourself then you'll see everything displayed on the screen because the operating system will flush the buffer at the end of the script - at the latest.

Now, I don't know what the exact reason for the UA losing parts of lines, but I assume that the way the script UA works is reading the buffer that the script writes. If the UA reads the buffer BEFORE the operating system flushes the buffer then the UA will only get part of the information. This will not affect all UAs, but it might come and bite a few.

There is a full solution in the works, but a good workaround (for Perl) in the meantime is to add the following line to the beginning of the script:

BEGIN { $| = 1; }

This will make sure that the operating system flushes the buffer at the end of every output operation and that guarantees that the script and the UA are synchronized. If you're using other script languages, you'll have to find the equivalent function.

This also happened to me way-back-when when I was writing DCL scripts for the OpenVMS operating system. Just goes to show that what comes around, goes around! It also demonstrates that we Tivoli types need a good background in general computer science knowledge to help us solve fiddly little problems.

-- Robert

Saturday, May 10, 2008

The Mythical Man-Month

I ran across a copy of "The Mythical Man-Month" in a second hand book shop yesterday.

Despite being written back in 1975, the book is a still Delphic oracle of software engineering. I credit it (and the friend who introduced me to it) with starting the boost me from a code-monkey-programmer to a software engineer.

The largest theme of the book is that adding manpower to a late software project makes it later.
i.e. if you're behind schedule, adding a newbie is NOT going to help.

Sounds like a truism in these days of XP/Agile/Scrum and so on, but it was revolutionary back then.