Story Time - My First Serious Program

Having a basic knowledge of Commodore Basic v2.0 I took to my A-Levels in 1994 and started to learn Pascal, both "Turbo Pascal" on DOS and "Personal Pascal" on my Atari ST.

One of the first things I did, as most kids do is start to write a game, it was a 2D grid style war-game, 28x28 tiles to a map and maps stitched together, it was very roughly based on a table top game I had which itself was a dice & splice of the Guadalcanal Campaign of World War 2... Anyway, I had jungle, and grass, Desert and beaches, water and the tanks, and troop counters moved around, you could air-drop paratroopers into spots when you had earned enough points, and I last worked on it in around 1995 when I started to add Sound Blaster driven 16bit effects into it.

But, I also needed tools, I was working on DOS, with no Windows - I didn't get Windows 3.1 until later that year - and at college the compiler only ran in DOS, to stop the compiler and loads Windows, then execute a GUI tool just to exit again and load the IDE was not a workable solution, therefore I started to write a bunch of EGA based tools directly in DOS, drawing graphics in DOS.

The first tool was a simple string comparer, almost a version of "Diff" which I used for comparing old and new files.  The second tool was a back-up tool, to indicate the copying of files into a floppy, so I could squirrel them away.

Finally, I needed a serious tool, this was a graphics tool... Almost a version of Paint for DOS.  To help design maps and other information in my game.  It worked by letting me place squares and circles, lines and even text into set places on the screen... It looked just like this...

Unlike anyone else in the class of A-Level students (as far as I know) I was the only one who knew about Interupts and could therefore use the mouse in DOS, so this blew a few people away.

This could save my image too, and I built up a very basic form of "Vector" graphics, without actually knowing what vector graphics were.

Later on, I came to add scale and delete to these items too, and this is where my innocence as a new programmer came along, I first started doing delete by using "GetPixel" to return the colour of the pixel below the mouse cursor, however, this failed terribly the moment I run it up and realised if I clicked on either the red circle or the red square both would vanish and I only had 16 colours in my pallette and really got disheartened.

So, I came up with a scheme to get more colours and workout which item I had clicked on... I went to grey scale, I converted each shape in the list of shapes to a grey scale of RGB (0x01, 0x01, 0x01) to RGB (0xFE, 0xFE, 0xFE)... This suddenly gave me 253 possible shapes in my list (as I used black and white as control colours), but 16 versus 253 I thought I was making HUGE strides.

I could then look up the pixel at the X, Y of the mouse to delete the actual shape below the mouse when delete mode was set... Nifty... So my mind thought, it was certainly a programming exercise, and very laborious on the 25Mhz 486 CPU's the college had.  Only much later did I think about accessing the back-buffer directly, locking the bits and stepping over the image in scan lines at vastly higher speed, anyway...

My next challenge for this program was to stop shapes overlapping, I immediately went to my grey scale mode, and started to so this... as the song goes... with "White Lines".... 

As the line of white moved across line by line, pixel by pixel, really really slowly, it checked if it found a grey - rather than black - making the pixel flip from RGB (0x00, 0x00, 0x00) to (0xFF, 0xFF, 0xFF), if the pixel ALSO was the RGB of the Grey shape I was adding, then this was left black, like so...

And I knew the shape was "free floating", with no overlaps... However, if there was an overlay, I added the RGB differently... So I could see the overlay... like so...

I was not only doing the processing live on screen, but it acted as a debugger for me as I went, without needing to spool up the Turbo Pascal Debugger on my measly 543K of free RAM.

This was a serious amount of work for me, when I learned a lot more about programming I came back to this briefly, but it never warmed my cockles more than when I wrote this program for the first time, I learned so much, I learned patience, to think a head, to plan, to process flow, to research the topic and ultimately to get things done first - in a prototype - and then revisit them.

I also ultimately used this same code later, at university in C++... Making this the first time I had prototyped a working application in one language (Pascal) and converted it to another (C++) and could say it was properly prototyped.  The latter use as as s tool to layout gardens in a sort of designer, I remember far less about the C++ version than the Pascal version.  But it's shadow lasts a long time, and remains over me today, I recall so much more about this one application than most of the others I wrote at the time, because it was something I engaged with.

I can only express to any budding programmer today, no matter that language you use, to just dive in there... 

The Great Bread Mystery

I came to make my sandwiches the other morning, and pulling open the brand new loaf immediately saw this odd shape on all the slices, which collapsed to an air pocket towards the bottom of the stack.

It's a hard, dough smelling thing, quite unpalatable.

I of course asked my colleague the former GBBO contestant Jordon Cox quite what he thought it might be... "Ewwwww" was his reply.

The manufacturer of this particular loaf is yet to reply to my query, as it wasn't a cheap loaf I'll tell you that much.

Hard Drive Heat Problem

Most of us are well aware of how much heat electronic equipment puts out, what can be less intuitive and harder to balance is the problem of heat from hard drives.

Good organised machine operation, with clearly defined device usages, easy control of units across machines, sites or different customers is the key, therefore enter stage left a nice fat label to hold all the details of the unit.

Except, this label acts as a heat blocker, reducing the surface area of the metallic or foil labelled drive as delivered, reducing the area across which the heat from the unit can dissipate, and even causing uneven heating, or heat wearing over time.

The net result... For my project, a high mechanical drive mortality rate, which I simply could not explain, nor model or explain in the man lab.

Only a trip to see how these machines were being employed sufficed to show the problem, label after label applied and reapplied, a drive on within a machine was untouchable it got so hot.  My solution, put a number on the drive in marker pen and link that number to a database entry with all the drive information.

This solved the heat death problem.

But it also opened up the scope of the information being transmitted, with access to any smart phone the customer could then look up the information, so could their designated engineer, they need never bother me - which is again key to efficient business practice.

Like-wise those not wanting the quite useful information on the harddrive to be public, simply have their information about the drive secured away behind a password on the site, or even more simply not on the site.

Options and solutions, that's how I see this problem benefiting projects going forward... If only we'd not been putting label after label on for year after year.

That Moment...

You know that moment when you see this...

And the mage rolls need....

Yeah, that's the kind of day I've had.

More World of Warcraft topics to follow...

People: Email & Names

When you interact with someone, say face to face, you get to gauge who they are, what they're thinking, the subtle and many clues from body language, posture, intonation and even just where they're looking tell you an awful lot about how that person works, how they think, whether you agree with them.

However, when you're communicating digitally, via e-mail or text, you loose this personal grip.

One has to therefore rely on the face value of the information presented, is it spelt correctly, is the grammar correct, have they thought out the reply and addressed all your requirements from anything you sent them?

In my case I am often asked things like... "What do you do to better yourself?"... "Or have you done anything of note recently"... And I'm asked by people who have read my blog, or CV, or just know me... And I often say "Have you read my book?... Have you read my Blog?"

This kind of interaction puts me on a huge downer, why should I bother with this person if they've not performed what I consider the basics of due diligence?

Then there's my huge pet peeve in E-mail... I send a mail... "Dear whoever, bla bla... Xel"... They reply... "Dear Zel"...

No, not "Zel"... "Xel"... spelling, and it's not just spelling, it's that you've been given the answer right in front of you, if you can't have been bothered to take the last thing you read, and put it into the first thing you write, you're being lazy or worst still you're being purposefully obstructive and annoying, because this grates on me so much.

I once worked with a lady called "Grace", she hated being called anything else, "Gracie", "Gracy", "G-dog"... All really, really annoyed her... and people did this day in, and day out, her final response was to stop communicating with these people with their own names... Even our co-boss, who was a "Mr Khan", he became "Mr Purple-Whipple-Snapple"...

When he queried this, she said "if you wish to call me G-Dog, I will call you anything I like also".

It was the perfect most polite and poignant reply on this matter ever seen, but it took a silly outrageous example to make this clear, if you can't call "Robert" a "Robert" on the next page, or a "Susan" a "Susan", or even a "Xel" a "Xel" don't reply.

Development: Silly Things Said in Software

"Rather than get away from the concept of the password required completely, the password is hard coded as 'password'"...

I literally just heard this statement, from a senior software engineer ten feet from my desk to another engineer as they consulted with one another about the system they are working on.  And I simply can't let it go... So here I am to have a moan....

The problem with this kind of thinking really annoys me, they could make passwords optional with configuration, meaning the option is present and supported.  They could remove the passwords altogether, as 'password' as a password is not a password at all, it only leverages an attacker to want to rip the soul from your data and scatter it to the four winds.

But more than that, remove the password if it's useless code, don't complicate the system, don't exacerbate the effort to maintain the code.

There are so many faults in the way this engineer is thinking I'm quite pleased I don't work directly with them; and luckily - as they're departing these fair shores in a fortnight - I never will.

Aaaannnnnddd... Relax...

Seriously though folks, don't over complicate things, if you use good source control you can resurrect sections of code from the previous revisions easily, so get drastic, get smarter in the process, chop and cut your code to bits.

This video from the 2 1/2 minute - ish - mark really shows you the process from someone else's eye... and I agree with him, when he talks about thinking about what's beyond scope, however, this also needs to be considered from the point of view of maintaining the code once released.

https://www.youtube.com/watch?v=4tbPbMRcMFQ&t=169s

Life Tip...

Top tip... If you run a business... And print people invoices... Learn to count... Tip ends.

This story is to be continued....

Development: Design, Prototype then Code

When I were a lad, I were taught to use flow chart stencils....

I was shown how to write data dictionaries, to thought-cloud through the possible data members for these dictionaries, to define the mutable and non-mutable points and abstract away the common elements between these definitions in order to design the code to be written.

All pretty much on paper, before you sat before the computer.

The reason being?  Paper was cheaper than electricity, and it took a long time to compile and recompile, and then even longer to debug, a program.  Bugs got hidden and only appeared when testing took place.

And if a bug ended up in test, which could obviously have been caught on paper, long before it reached the coding phase, then you got egg on your face.  In a nice way, you all knew you had to do more than cut code.

Unfortunately Moores law exists, a blessing, and a curse.  As I feel it's made the quality of software design fall, as people can afford to code and compile and try before thinking.

No-one I work with, certainly no-one immediately around me, designs anything on paper, or performs thought exercises on the task before diving at the keyboard.  Event when they have dived at a keyboard they're not prototyping, they're immediately producing code for release use, and it's starting to show.

As such, I've instigated a new rule, "if you have to prototype, it must be in a different language to the release code", the language I've stipulated is a python for system scripts or data processing tasks, and C# to replace any windows C++ being produced.  For C# I'm still thinking, but Java might be the best option...

This realisation came to be from the back of my mind, and it came from experience, however it seems other authors have had thoughts along these lines:

"One trick to ensuring your prototype code isn't obliged to become real code is to write it in a language different from the one your game uses.  That way, you have to rewrite it before it can end up in your actual game" - Robert Nystrom.