The products featured below were developed for social service institutions, clubs, and other non-profit organizations (and before Blade Technologies officially existed). To this end, no compensation was accepted, save for a nice dinner or two.
There are obvious reasons these programs aren't in the "Landmark Projects" category, but as you can learn from the descriptions, each is remarkable (as in "worthy to be remarkmed upon," as opposed to "astonishing") in its own way. Unfortunately, they were mostly written in obsolete or otherwise now-disused development environments. In time, we hope to recreate these obsolete development environments so proper screenshots can be posted.
This project may seem trivial — and this lengthy "making of" story far out of proportion to its importance — but it shows my life-long love of programming better than any other. I was just a free-coding kid, but unknowingly used some quasi-professional methods, juxtaposed as they were against the kind of hacks that were so often required to make things work in ye olden times. I miss terribly the thrill of seat-of-your-pants hacking, and would love to find a project that allowed me to experience that again while still supporting my family. If you know of any such opportunity, please share it with me!
In 1989, our high-school chemistry teacher got the idea to enlist a computer match-making service for a physical science club Valentine's Day fundraiser. I was titillated by the concept, but being who I was, insisted on implementing it myself: It just sounded, like, totally bitchin'! (Did I mention this was the '80s?)
The idea — which was met with considerable excitement — was to distribute to students a questionnaire intended to identify and quantify their individual characteristics via queries falling into four top-level categories: Religious/moral convictions, life objectives, general interests, and romantic expectations. Completed questionnaires would form the candidate data pool. After analysis, each "client" could purchase a list of "most-likely compatible" romantic partners, with each entry composed of a name, a "confidence factor" for each of the question categories, and an "overall adjusted confidence factor" based on 1) the aforementioned, categorized confidence factors and 2) the "combined importance factors," calculated from the deltas of the priorities assigned to each question category by both the client and each candidate-match.
A R C H I T E C T U R E A N D I M P L E M E N T A T I O N
Within weeks, I'd banged-out two applications running on the venerable Commodore 64:
The first was an all-BASIC program that enabled club members to 1) create, revise, and print side-by-side versions of the questionnaire, 2) assign weighted-values to its questions for use by the analysis algorithm described below, and 3) convert the completed, tree-based questionnaires into genuine, 80s-era, electronic data. ;-) Questions were accepted in one of four formats, three of them close-ended: Multiple-choice, check-all-that-apply, rank-by-importance, and client-specified lists. Component-level database technology simply didn't exist on the Commodore platform, so I created a system that used index-augmented, relative-access files to store questionnaire answers, while the questionnaires themselves were archived in simple sequential files.
The second program analyzed the questionnaire data to produce a list of the highest-probability romantic matches. Safeguards were instituted to flag and log suspect data. All match-scores were weighted in accordance with the specifications provided by the questionnaire team, as described above. Comparing answers to multiple-choice questions was obviously the simplest of matters. Check-all-that-apply questions required identifying matching answers and scoring according to the percentage of matches. For rank-by-importance questions, I chose to use averaged, differential computations. Open-ended lists called for a set of partial-string-matching functions, including metrics-calculation so I could objectively judge (more guess-at-non-wildly than judge, actually) the reliability of each match.
I originally wrote these string-matching functions in BASIC, but they proved so dirt-slow when looped-over against anything more than a tiny data pool that I resorted to coding them in 6502 assembly. This would've been fine except that I'd recently spilled sweet tea on a pile of floppies that included both the original and backup copies of my assembler. (Yeah, it kind of defeats the purpose to keep them in such geospatial proximity.) In 1989 rural Kentucky, you just didn't bop down to your local K-Mart for programming tools, and our runway was short.
So I wrote the assembly by hand — literally on notebook paper. I then converted the mnemonics to machine-language op-codes and — to avoid errors and save time — used a tiny utility to convert hex addresses and operands to decimal. I aggregated the op-codes and operands into DATA statements, wrote loops to POKE them into memory blocks that were safe from my BASIC program and variable-storage areas, and called them from within my BASIC program using SYS statements. Admittedly, this was a fairly-common methodology during this computing era, but one that was traditionally automated! ;-) After a few assemble-by-hand/test/debug cycles, I had some efficient string-matching functions and a working data-analysis program.
T E S T I N G A N D R E V I S I O N
At my suggestion, the club enthusiastically formed what today might be called a quality assurance team: They recruited what were perceived to be happy, stable couples to complete the test questionnaires, filled out questionnaires of their own, created dummy questionnaires for fictional clients, entered the data, and ran the analysis program in hopes that the generated matches would prominently feature the real-world couples. Based on the resulting matches and on follow-up conversations (i.e. post-mortems) with the lovebirds, they'd then modify the questions and/or their weighted-values and repeat the process.
In essence, they implemented their own tweak/test/debug cycles to keep improving the service, at least as well as they could in light of their limited and subjective test data. Hey, we were just a bunch of high-school kids using pseudo-science to describe and predict the most mysterious of human-interactions. In 1989. On a 64 kB, 8-bit machine running at 1.023 MHz. I think we did pretty well.
L A U N C H A N D C A N C E L L A T I O N
By the end of January, we were pushing out questionnaires and pulling in cash. Students offered almost nothing but encouraging comments, and the limited but impassioned dissension only stoked interest in our activities. and their anticipation was even higher than we'd dreamed. The feedback even spurred us to add a premium feature (more money!) that would provide match results against a specific student who didn't already appear in a client's best-match list. It was simply exhilarating, and it lasted about two days.
That's when the club president and I were unexpectedly summoned by the principal. The school newspaper had just published a brief story covering our efforts, which we considered a terrific piece of well-timed publicity. (It included some errant details, but that happens to me every time I'm interviewed for any story.) Unfortunately, the moment a copy hit the principal's desk, he spewed coffee through both nostrils and hit the roof. We were ordered to cancel our fundraiser and issue immediate refunds. He claimed his head was swimming with visions of the livid, litigious parents he'd be facing the instant one of our matched-couples went down in tearful flames, and was adamant that allowing us to proceed would be akin to school-sponsorship.
P O S T - M O R T E M
In hindsight, we should've launched off-grounds and without school resources. As it was, we spent much of the remainder of the semester explaining, ad nauseam, why our service never emerged as promised.
I regret that our ambitious match-making service was forcefully-aborted. (I confess: I was bitter for a time.) I would've loved to have seen the roller-coaster reactions and colorful fallout when our system was run against 800+ teenagers who spend five days a week together. Fireworks pretty! Still, the entire experience was extraordinary fun, and I'd relish the opportunity to help create another product with a similar gee-whiz factor. Somehow, I doubt working for adult-based eHarmony in 2016 would bring the same delight as helping hormone-jacked teens pair-off in 1988. Heck, if I'd had more foresight, my physical-science-club-friends and I might BE eHarmony. Then again, I would've robbed the world of all those Neil Clark Warren commercials. He seems such a nice guy. :)
While this is certainly one of the most unexciting projects imaginable, I've never hacked anything else in quite the same way, so I thought it worthy of inclusion.
In the late '90s, my wife volunteered and worked at what was then known as Life House Care Center for Women. Of course, that meant that I was the resident IT guy, handling all the usual hardware issues and tasked with troubleshooting every access violation and blue screen of death; and back in the Windows 95 days — as I'm sure you'll all remember — there was no shortage of either.
D E V E L O P M E N T
Life House was using a client-tracking program named — oddly enough — ClientTrack. They were perfectly happy with this program, but there was still a great deal of data in an older piece of software that they never had the time or impetus to re-key into ClientTrack. Since LifeHouse had many repeat clients, it made sense to merge the two.
My first thought was to use a hex editor to identify the older program's storage scheme, as I'd previously done in so many similar situations. However, after taking a quick peek, it was obvious that untangling the knots in that overly-convoluted and purposely-cryptic layout would be anything but a simple matter. (Did I mention I wasn't getting paid for this?) No, this task called for a different approach.
The program was DOS-based and used fixed-boundary fields, so theoretically, I could screen-scrape records from display memory and copy them to ClientTrack. (Thankfully, ClientTrack's creators weren't compelled to obfuscate their data scheme to oblivion.) Since the program that would do this would lie between the two client-tracking apps, "Intercession" seemed as apt a name as any. (Why I bothered to name a one-time-use/for-my-eyes-only program in the first place is a question for my psychoanalyst. I name everything I create.)
Fortunately, when in "browse" mode, the user could scroll through every record in the old database using the CTRL + CRSR_DN key-combo, and through every tab within the record using the CTRL + CRSR_RT combo. So, I employed the old-as-silicon technique of stuffing the keyboard buffer along with a timed delay before I scraped each tab from display memory.
P O S T - M O R T E M
There was some trial-and-error regarding the timer setting, and a few false starts from incorrect character counts, but once I worked through those issues, Intercession was able to unify all data. Happy times.
Once the Paducah Chess Club grew beyond a few members, the need for computerization quickly became obvious, both for administrative tasks and to help competitions run more efficiently. Chess Exchange was written to handle both, but in two distinct development phases.
D E V E L O P M E N T
Phase one was a straight-forward database application that tracked player contact information, US Chess Federation membership details, official ratings, and club dues. It also plotted player-rating trend charts.
Phase two was far more novel, as it was intended to address many of the duties normally required of the tournament director and other officials. Using the player information from Phase 1, the software could set up either a multi-game match, or a round-robin, Swiss, and/or direct-elimination tournament in a matter of minutes. Initial player color could be assigned randomly or manually. Game results would be entered into the system, which enabled pairings to be calculated on a round-by-round basis, although they, too, could be manually overridden when necessary.
Usually, only game results were entered, but game scores could be recorded by the software and replayed via code that used Commodore character graphics for the board and a partially-redefined character set for the units. Game results were compiled into the "career record" displayed as an enhancement to the player profiles implemented in the first development phase, as well as used for various performance-analysis functions that were added over the life of the program. All pools, brackets, standings, and other data could be printed for public posting, either with or without the character graphics that made up tables and bracket lines. (Letter-quality printers weren't able to produce graphics, so they were only included if printing to a dot-matrix printer or plotter.)
P O S T - M O R T E M
From Blade Technologies principal Jason Purcell:
The system ran on an SX-64, a twenty-three pound "portable" version of the Commodore 64. ;-) I considered porting it to the PC and issuing it as shareware, as it would've been a fairly straight-forward translation. However, the use of such technology in chess was largely-unheard of at the time (late '80s / early '90s), and the realm was so tradition-bound I doubted my software could turn many heads.
Developed for Murray State University's Fencing Club, Riposte! is very similar to Chess Exchange in both its dual-purpose design and the basics of its implementation.
D E V E L O P M E N T
Once again, the first step was to push out a module to maintain the club roster, except this time, it was also built to keep tabs on other clubs and schools, equipment suppliers, division officials, and coaches. Club profiles included photographs, contact information, United States Fencing Association (USFA) membership details, official ratings, and club due information. Each contact type included its own, specialized fields, and user-defined field functionality was included, as well. Photos can be imported via native TWAIN support, and cropped and resized using a simple, built-in editor.
Fencing competition administration can be quite error-prone, so this functionality was made as bullet-proof as possible and gold-plated to boot. Leveraging information from the aforementioned fencer profiles, competitors are correctly divided into even-strength pools and later seeded into direct-elimination (DE) brackets. The software resolves all conflicts that can possibly be anticipated: It separates fencers from the same club, indicates on which side of the strip each fencer should appear, tracks each score, warns the director when the fencers should switch sides, keeps time and issues the appropriate warnings and end-period/end-intermission signals, implements the complete tie-breaking algorithm dictated by the USFA, records each penalty and displays the prescribed punishment, calculates both the tournament rating and the ratings earned by each fencer, and loads of other details.
The entire array of documents required by the USFA at event-completion can be sent to printer and HTML. (Adobe considered PDF a military-level secret at the time.) Pool sheets, DE brackets, and DE score-sheets are printed for directors and public posting during competition, as well.
P O S T - M O R T E M
From Blade Technologies principal Jason Purcell:
Probably the most shiny thing about the system was a second executable I created to drive an external display with a series of screens showing the immediate and cumulative results, the upcoming bouts, and a series of configurable announcements. Now, I know that's no big deal today — I see similar setups at my daughter's gymnastics competitions (though they typically only show immediate results). However, I finished developing this program in the late fall of 2000, so it was at least slightly ahead of most of the pack.
Though the market was (and still is) minuscule and a number of competitors existed even at that time, this software was so complete that I should've pitched it to the USFA as soon as it was tested in a tournament. Instead, I decided to first develop a data-connected companion-product that directors could hold in their hands while conducting live bouts, and — in a stroke of geeky optimism — chose the Palm OS as my platform. (Stop laughing — I was hardly alone!) I actually did start on this app around Christmas, but of course, the bottom fell out of Palm (and its stock) the next year. If anyone's interested in how I planned to develop a dependable mobile network application in an age without dependable mobile networks, check out the Palm Query Applications (PQA) quasi-API. If that didn't work, I was going to roll-my-own, which is my natural tendency, anyway.
I'd still love to port the entire thing to .NET and direct someone to create an HTML5, cross-platform companion app, but I can't imagine how I'd justify the time-and-materials in light of the minimal potential return: I'm not a childless twenty-something anymore. As Blurryface is told, "Wake up, you need to make money!"