Month: May 2019

Goldenseal Pro has a new, single-window appearance. To move between different functions, you click on on tabs rather than separate windows. We’ve used it enough now to really like the change.

Unfortunately, the tab view has had a serious bug: crashing after a few tab switches. It started about a year ago, when we updated to Apple’s newest memory management system. About once a month, we’ve spent a day or two trying to fix it, without success.

Our staff spent most of the past week attacking it again. We finally cracked it Wednesday, with help from folks on the Cocoa Developer Forum. The root cause was some unexpected behavior in Apple’s NSTabViewController class, complicated by the fact that we can’t see Cocoa source code.

We have been using Apple’s Cocoa framework for 2.5 years now. It is probably the most difficult programming environment our staff has ever used. Unfortunately, there are no viable alternatives for building software that runs on future versions of Macintosh OS. We are getting there, but it has been a real struggle.

As an attempt to quantify the difficulty of programming environments, I’ve decided to invent the Serius Scale. It’s a measure of programmer pain.

0 on the Serius Scale is an absolute joy for programmers. Productive days that create useful code, quickly. 10 on the scale is a tool that causes maximum frustration, and never results in anything useable. Right now, I’d rate Cocoa at about a 6, maybe a 7. Apple really could do better.

The scale is based on Serius Developer, a software development tool that came out in 1989. It had an amazing demo that included a built-in spreadsheet. We were desperate for a better platform for our construction estimating and accounting software, so we plunked down $2000 for it.

Unfortunately, we soon discovered that their spreadsheet tool was hard-coded to run the demo, and nothing else. Other features were similar. There was no way to get it to do what we wanted. Serius was a totally useless black box. Its developer later moved on to start a Ponzi-like Internet company, then got into space aliens. So, I’ll rate his software a 10 on the eponymous Serius Scale.

Before that, TurtleSoft started out in 1987 with simple construction estimating templates for Excel. They took less than a year to develop, and sold like hotcakes. That was a fantastic time to be in software.

I’d give early versions of Excel a 1 or 2 on the Serius scale. The macro language had its quirks, but it was pretty decent for its day. Things improved in Excel 2.2 and 3.0, but then went seriously downhill. Excel 4.0 added a bug that randomly changed our code. Then the macro language was replaced with Visual Basic. That’s why we were so desperate to find a better way to produce software.

Back then, we also shipped a few products based on Apple’s HyperCard. It was a fun app that could whip up something functional, very quickly. At the beginning, I probably would have given it a pain-free 0 or 1. Unfortunately, after using it to build real software, we discovered race conditions. HyperCard worked by passing messages around, and they weren’t always received in the same order. It made hard-to-find, intermittent bugs. Apple never fixed them. Instead, HyperCard languished, and was never updated for OS X.  I guess the net result is a high Serius number. It just never lived up to its potential.

After fiddling with FileMaker, Omnis, Double Helix and a half-dozen other platforms, we finally decided to use plain old C++ for Goldenseal. It was built upon the PowerPlant framework that came with Metrowerks CodeWarrior. Basic, but easy to understand. About a 2 on the Serius scale. Metrowerks was a small, competent company. Very pleasant to work with. Life was good again, for a while.

Unfortunately, Metrowerks was bought and strip-mined by Motorola. They sold off the Intel version of CodeWarrior a month before Apple switched from Motorola chips to Intel. A quick end for CodeWarrior and PowerPlant.

Unfortunately, this post has been using “unfortunately” a lot. We would like to spend our time writing code for estimating, accounting, payroll, and other functions that users need. But, looking back, at least 75% or 80% of our programmer days have been spent on OS and hardware issues. Too much time struggling with tools that are high on the Serius Scale.

The good news is, we are making progress. It’s hard, but not impossible.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff is well into the miscellaneous phase of the Goldenseal Pro project. That means tidying up small details until it’s all shiny.

First thing, we enhanced the database verification reports so they catch a few more potential errors. The reports will make the final testing go much faster. Rather than waiting around to see if file error messages pop up, we can run Verify File a few times a day. It will notice any problems right away.

It’s quite possible there won’t be any more database issues. The data conversion from version 4.96 to version 5.0 already futzes with many thousands of records, and it may already have hit every possible problem. Really, database code is not that huge a task. It’s much simpler than construction estimating or payroll. A database has to locate records on disk, make sure they don’t write on top of each other, and manage gaps (otherwise the file becomes an enormous hunk of Swiss cheese). Most of our database code is just sanity checking, and duplicating info so it’s possible to recover if data is corrupted by the outside world.

Since we are already converting data from old format to new, we decided to simplify bank accounts and transactions in the new accounting software. Goldenseal Pro only has 3 types of bank accounts instead of the current 7. The update process converts any old records, and also converts links between records. As we started using the Reconcile command, one missed link turned up. We fixed it.

Right now, Passwords are on the plate. I personally designed the Goldenseal interface, with little sliders to set the access each employee has to different parts of the data. It looks nice, but it was so non-standard that it took more than a month of programming. Too much time for a minor feature that many companies don’t even use.  In Goldenseal Pro it won’t look quite as nice, but it will use existing code. One more day to finish it, instead of a month.

Our staff started work on the Custom Layouts view more than a year ago. Some things work, but we got stuck on a few things and moved on to other code. Our staff is revisiting it, now that we’re more experienced with Cocoa.  It’s the last major interface element. The first release doesn’t absolutely need Custom Layouts, but it will make Passwords easier to finish.

Dennis Kolva
Programming Director
TurtleSoft.com

The past week, our staff has focused on the database code that runs our new accounting software. First thing was to update the Verify File command to work for Goldenseal Pro. It reads every record, runs a few sanity tests, then reports any errors. When we ran the verify, the Sample Company File showed 4 errors, and our Turtlesoft file had 8.

As it turned out, almost every error was caused by something different.  They were all very obscure problems. Hard to find and hard to figure out, so it took a full week to fix them all.

Along the way, we added a few other commands that test the integrity of the database structures. They helped with the bug fixes. Even better, they’ll show any future file errors before they become serious problems.

Like almost all databases, Goldenseal Pro locates records with a tree structure. Searches in a tree start at the root, then travel up through branches to the leaf nodes: one for each record. Actually, Goldenseal Pro uses a few thousand branches at each node, so it looks more like crabgrass than an actual tree. It’s faster that way.

With such fat nodes, it only takes two levels to handle anything under a few million records. None of our test files are even close to that big, so we temporarily turned one class into a binary tree, with just two records per node.  For 900 records it built a 10-level binary tree, and that tested out fine. So we are now confident that our accounting database can handle at least a few nonillion records. That’s a thousand billion billion billion, or a 1 followed by 30 zeros.

Our current company file has a bad NeoAccess node, which breaks several thousand Sales records from the early 1990s. Fortunately, we found a way to recover all but 8 of them, when converting from the old format to the new.

There are times when it feels insane to be writing our own database code, rather than using something well-established and open-source. So, I recently downloaded the MySQL source code to see what we are missing. It is very old C and C++ code. Hard to read and understand, and probably very hard to debug. Many potential security flaws and time bombs. Its style is similar to the NeoAccess code that we struggled with, partly rewrote, then finally abandoned. However, MySQL has several thousand source files rather than a couple hundred. It’s probably even more convoluted.

I think we made the right choice. It’s nice to have a report that explains every bit within the accounting file.

Dennis Kolva
Programming Director
TurtleSoft.com