A history of my favourite software

For some time I’ve been thinking of creating a list of software I’m proud to have created. These projects aren’t necessarily work related or even publicly successful. Just projects that I’ve done and I regard fondly for personal reasons. There are many other projects I’ve worked on, but these are my favourites, starting from the very earliest.

Casio 702p game

When I was 15, Dad gave me a Casio 702p programmable calculator. It had a single line LCD display and a capacity of 512 programming steps using a hybrid basic/assembler language. Needless to say it wasn’t built for games, so I spent a large amount of time working out flow diagrams for a side scrolling shoot-em-up game and used every one of those 512 steps to code it.

CLIST security

Back in the 80’s I got a job at a mainframe computer site. Not long after I was asked to manage the security systems on their IBM 3090 and DEC VAX (PDP-10s I think) mainframes Yep - no knowledge or experience in security and no-one to guide me, it was the 80s!

I was horrified to find that all security was handled from the command line on the IBM’s, so I taught myself the CLIST language and ISPF development. Then proceeded to create a UI for security. I knew almost nothing about programming so it was a mess of GOTO statements, but it only 400 odd lines long and it worked.

REXX security

Not long after the CLIST version, I discovered a more modern language called REXX and now understanding what a subroutine was, re-wrote and expanded the functionality of the security UI.

Kill user

I was also horrified to find out that if we detected someone on the main frame doing something they should not be doing, the security system had no available option to terminate the user's session. A little digging and I built a program that did just that, and for effect - drew a full screen skull and cross bones on their terminal whilst it killed their session.

3090 mainframe logons

The system programmers had a problem in that the resources a user had access to were setup in during the logon process using hard coded JCL scripts. It was proving un-maintainable.

I rewrote the mainframe’s logon system using REXX to source setup from common configuration files instead. To my surprise, performance testing showed that my dynamic REXX logons were actually faster than the hard coded JCL scripts.

The MANTIS bar code scanner

When I got to Australia I was asked to look at an app that someone else had written. It was a mainframe app which received data from a portable var code scanner. The app was written in a language called MANTIS. Both it and the scanner where very buggy and unreliable. I soon found multiple bugs and poor design decision in both and ended up completely re-writing them to get it all working.

XStream

I don’t actually remember why I called this project XStream, but I did. Anyway, working in Adabase/Natural CICS on IBM mainframes I decided there was a major issue with the development environment. To examine the database structure or data a developer would have to exit the code editor, log out of the development environment, log into a database environment, query the DB, then log out of the database environment, log back into the development environment and open up the code they where editing. Awful flow.

I queried the DBAs who said database access from the development environment wasn’t possible. I didn’t believe them and wrote an app that could be called from within the development editors and did exactly that. You could view the DB structures, query the data and cut ’n’ paste generated Natural source code back into the development editor. Unfortunately being government, management had no understanding of tooling and no vision in terms of helping their staff so I was the only one who used it.

GUI style reports

Being responsible for about 50 FOCUS users spread across a dozen insurance companies who needed to generate WorkCover (now known as WorkSafe Victoria) reports from the mainframes, I was a bit bored just doing support work. So I built a GUI (or a near as it can get on a 80x24 character terminal display) for running reports. It featured dynamic screens, validation, menus, and submissions components and was used extensively by the people I was supporting.

My first VB

Finally leaving the mainframe world I was asked to fix some bugs in a Visual Basic app before collecting my redundancy.

The app accessed an Access database. It turned out there where numerous bugs starting at the database. Being used for financial calculations the database had one table where every field was a string and labelled ‘Field1’, ‘Field2’, ‘Field3’, etc. The program had massive multiline calculations where values where converted from strings to numbers, used and converted back. Sometimes numerous times in a single calc.

Clearly the developer had no clue and I reported back that the app was beyond redemption. I then built a completely new app and database from the ground up. Needless to say, no more bugs.

Reverse engineering WorkCover

Working for an insurance company who specialised in WorkCover insurance I was asked to write an app that would allow the sales people to show clients predictions on their WorkCover premiums should various scenarios occur.

The problem was that all we had from WorkCover was a single page pamphlet that describes the calculations at a very high level.

It took almost a year of reverse engineering the highly complex calculations but in the end I achieved an accuracy of around +/-1%. Meaning my app would be within 1% of the offical WorkCover calculations. The app was written in PowerBuilder.

Batch processor

Working for a small company I was asked to build a batch processing system using PowerBuilder. I suggested that PowerBuilder was not the appropriate tool because it was GUI orientated. But the company wanted to use it. A couple of months later I had a system where developers could extend a class and fill out the batch processing step. Then runner programs would pick it up and run it. Multiple step jobs where supported as was branching and processing based on step results.

Java Layout Manager

Early days in Java and the only flexible way to layout a GUI was to use a thing called a GridBagLayout. It was a bit like a spreadsheet where you allocated widgets to cells and could join cells together to allow for bigger widgets. It was notoriously difficult to work with so I decided to build my own layout.

I based it off relational springs and struts style layouts. Which mean that a GUI was laid out by specifying relationships between widgets. For example widgetA.leftOf(widgetB, 10) to place widgetA to the left of widgetB with a 10 pixel gap.

Pages

Early days on the internet and the only options for writing HTML websites where a variety of dodgy editors and Sausage Software’s HotDog. None where particularly good or ran well on OS/2.

So I decided to write my own and wrote Page. Apart from the usual tools bars for inserting tags, etc. I concentrated on tooling for people editing sites with numerous pages. So things such as search and replace across directories. etc.

Pages was written in VxREXX.

J2ME GUI

Working at Lonely Planet, the needed a high compact GUI for their mobile phone guides that could fit within 50kBytes and leave space for data and images. It needed scrollable text areas, buttons, menus, etc.

Ignoring all general programming practices for Java, I concentrated on reducing the size to a minimum and within a few weeks had a J2ME GUI API that compiled down to about 13kBytes.

Simon and the Pieman

After a while of dealing with a very average set of BDD testing tools for iOS, I decided to build a new tool which was native to iOS and OS X rather than a hacked together app built in Ruby.

After about 6 months I had Simon which was a iOS static library that could be embedded and interact with an iOS application’s GUI whilst it was running. Simon also had the ability to run tests based on included story files and to display test results with an embedded runner.

Then I built The Pieman which could act as an OS X driver program that can read BSS stories and map them to the GUI being controlled by Simon. Starting and stopping the app as required.

Story Teller

For some time I had been questioning the way that logging APIs are architected. I found that every single framework I found all had the same basic architecture. As a developer you specify a ‘logging level’ when you add a log statement to your code. And when debugging, you set the level of logging you want to see.

The problem with this is that it depends on the developer to be able to decide what is relevant to each level when logging is turned on. Invariably what happens is that when debugging, you have to troll through a large amount of output to figure out what is relevant.

So I decided to take a different approach and wrote Story Teller. This API allows the developer to specify anything as a ‘logging level’/key when adding a log statement to the code. Then when activating logging, you can use expressions to select log statements that are relevant to your problem.

The result are logs which are highly targeted at the problem being solved. Cool.

Alchemic

A couple of years ago I took a look at Dependency Injection frameworks for iOS. I only found a few and they all had problems. Ranging from minimal functionality to requiring as much code to use as to not use.

So I decided to write a new one based on my requirements and wrote Alchemic.

Alchemic is loosely based on the Spring Framework in the sense of trying to have a minimal requirement for using it, yet providing a powerful set of injection tools.


Comments powered by Disqus