Command Lines (Apr 5)

Qt has a command-line tool called macdeployqt6 that assembles a full Macintosh app. It adds 135 MB of their code inside the app bundle, and does some other tweaking.

We got the Mac deploy to work this week: it made an accounting app that will run on any Mac that’s M1 or newer.  Except, it didn’t run, because newer Macs require code signing. That’s a whole ’nother command-line process. The first step is for Apple to verify that TurtleSoft LLC is legit. We’re working on that now.

Intel Macs require a different app, built with an older version of Qt. Those can run on older OS versions without code signing, but so far all attempts to deploy the new accounting software for Intel have failed. That first success was one of many tries, and we didn’t write down exactly what it took to get there.

Back in the 80’s, almost all PCs ran MS-DOS. It gave a text prompt, and you typed in instructions. Command lines are fussy: one wrong character and it fails or goes haywire. There’s no Undo. Type in del *.*, hit the enter key and you will be very sad. Working with files is extra hard: they need to be in the right place, with the correct path to get there.

Back then, our staff had to explain many times why the GUI on a Mac was better. Just click and drag. Harder to make small stupid mistakes. Less brain-draining. Undo saves your ass. Despite all that, the Mac was a tough sell.

These days it’s opposite land. Windows GUI has caught up, and Microsoft users almost never see a C prompt. Mac OS is now Unix-based, and command-line at heart. Most Mac users can stick with GUI apps, but for some tasks you’ll need to type into Terminal. For example, to add spacers to the Dock you type or copy/paste:

defaults write persistent-apps -array-add '{"tile-type"="spacer-tile";}' killall Dock

Software developers have it worse. Nearly all utilities are command-line. It stinks. Online instructions help a little, but not enough. They don’t know the readers exact setup, so they show stuff like:

../%{JS: Util.asciify("build-%{Project:Name}-%{Kit:FileSystemName}-%{BuildConfig:Name}")}

Users must figure what to put in for Name, FileSystemName and Name. And yes, that’s a real step and some are worse.  The process makes C++ code seem like poetry. After a couple hours, it all gets blurry and looks like A$sdfas8%ferw#rr33@34bre/grgle.

This is tax season. Between the above, Apple, and IRS instruct@!#%ions , it probably will be a few weeks until something is ready to download. So far, no experienced subcontractors want to deal with the final deploy. They’ve all been there, suffered that.

The only good news is that once the process works a few times, we can set up scripts and 1/2/3 instructions. From then on, future builds are just a matter of text copy-paste in proper order. Less painful. We hope.

Dennis Kolva
Programming Director

DNA (Mar 28)

The source code for Goldenseal estimating/accounting software has a clone. The same database and interface also builds an app for DNA sequences and protein structures. It imports data from different science websites, and links them.

I wrote it while attending Cornell as an older undergrad, 2008 to 2013. The goal was a late career in science, and/or new software to sell. Neither panned out, but the app still found interesting things lurking in the human genome.

It all started after a long canoe trip in the late 90s. Around the campfire, the biologists complained about all the repeating “junk” DNA turned up by the Human Genome Project. It’s 98% of your DNA. A few million chunks of it. Far more than the 20,000 regular genes that create proteins. As a computer person, it sure sounded like data. Maybe something I had the skills to help solve.

Cornell was one of many distractions that have slowed down TurtleSoft. On the other hand, genomes are a another good reason to keep slogging on the 64-bit update.

Humans have 3.3 billion base pairs of DNA (3.3 gigabytes as text, or 780 megs compressed to binary). A 32-bit app can only store a few genomes before it runs out of space, thanks to the 8-gig address limit. Because of that, the DNA app desperately needs 64-bit. Unlike Goldenseal, which will never hit that memory cap. Our current accounting software could go forever if Apple still supported 32-bit apps, or made it easier to update.

Will a DNA/protein database help make sense of the human genome? Maybe. Problem is, there’s too much data. Most likely there are many thousands of traits controlled by repeat lengths. Matching them up would require millions of full-genome sequences, millions of measurements, and way too much computer time.

A better approach may be to find the proteins that read that data. There are candidates: e.g. HEXIM1, pictured above. Cool machinery runs life at nano-scale, propelled by ATP. When the new accounting app is polished, I’d like to explore how it works.

Dennis Kolva
Programming Director




First Release Soon (Mar 18)

The new accounting software is almost ready for its first public release. Enough features are functional that it can run a business. The interface is better than Goldenseal’s, and the database is reliable and solid.

A few known problems still lurk in the code. Most likely there are plenty of unknown ones, too. However, the only way the app will reach perfection is to get user feedback.

Our staff has tested the new app on our own business accounting for more than a year now (sporadically). We run it side-by-side with Goldenseal, and make sure they both work the same. Sooner or later, a bug turns up that takes time to fix. Then the new file lags behind and needs to be trashed. Each test cycle lasts a bit longer.

Problem is, testing is tedious. We never do enough of it. Good programmers check to make sure their code works, but that doesn’t catch every possible error. When we’ve hired full-time testers, they rarely last more than a month. The work is just too boring.

Another problem: there are plenty of features that we don’t use here. The only way we find out about how they should work is from user feedback.

To increase the number of eyes looking, the new app will start as free accounting software. Anyone can use it, current Goldenseal owner or not. When polished enough, the app will cost something, but that will take a year or longer. Anyone on a tight budget can keep the final free version and use it forever. They just won’t get updates after that.

The new accounting/estimating software will be permanently free for Goldenseal users who prepaid for the update, many years ago. We’ll also give free time or a discount for each bug report that’s not a duplicate of what we already know.

If nothing else, Goldenseal users should try converting their company file to the new format. The process is easy: it works great for our data, but may have problems with yours. The sooner we learn about errors, the sooner we can fix them.

Up until now, we’ve used the Qt debugger to build and test the new software. It doesn’t create a working app that users can download. Qt has a process to build finished app packages, but it’s not easy. Our staff is wading through the instructions now. It may require help from a Qt expert.

After the first release, new versions should be available every week or so. There won’t be instant bug fixes, but we probably can get most of them zapped and published within a release cycle or two.

Quite honestly, our staff is extremely burnt out on this project. It has been a long, long slog. Having specific bugs to fix will be excellent motivation to keep us in the grind. Most software problems take longer to find than to fix, and we’re good at fixing. Each success gives a jolt of that sweet, sweet serotonin.

Dennis Kolva
Programming Director



Open Source Software (Mar 7)

We use Qt to build our new accounting software: it’s a GUI framework for Mac, Windows and Linux.

Qt has two different flavors. Right now we use open source, because it’s free. Open source means that anyone can download the Qt source code and do almost anything with it. At some point we’ll pay an annual fee for the commercial version, to get better support and fewer license restrictions.

The Qt Company currently has a market cap of two billion dollars. So far they’re successful at having both open source and commercial versions, though their history has been rocky at times. For a few years Qt was owned by Nokia: part of a failed plan to stave off the iPhone.

These days, open source software is extremely common. Apple, Microsoft, Google, Meta and Amazon all use it. Nearly all websites run atop many, many layers of open source code. The tech ecosystem has grown far too complex for anyone to build anything completely from scratch. And open source is a safer way to run code made by strangers: you can see its insides.

Should TurtleSoft go open source for our new accounting software? Maybe.

The extreme version is to just put it out there for anyone to build and use. Free accounting software, what’s not to like? It would definitely get some attention. On the other hand, it will be difficult for us to ever be paid for the development time we’ve put into the new app, so far. On the third hand, that ship probably has sailed. We took too long to upgrade.

There’s a security argument against full open source. Problem is, anyone could run the app in the debugger, and open any accounting file: even if it’s password protected. All it takes is a breakpoint in the sign-on dialog code. The password is encrypted in the database, but the code has to decrypt it to compare with what you typed. That breakpoint is how we rescue users who forget their password.

Of course, there aren’t many people with the chops to do that level of hacking. And you still can protect your data by keeping the company file on an encrypted drive. The OS has more security tools than we do. Ultimately, we’d be the same as all other open source code: black hats use it to break things, white hats try to prevent that.

A lesser version of open source is to allow limited access: vetting who gets access. If any current Goldenseal users want to see the new code, you can give it a whirl now. We use SourceTree and Bitbucket for source control, and it’s easy to add read-only access.

To build and run the new accounting app, you’d need to download the project, download/install open source Qt, and install Xcode (on Mac) or Visual Studio (Windows). It may work fine after that, or there may be frustrating error messages to deal with. Welcome to the programmer’s life.

Open source projects can allow contributors to add features or fix bugs. Qt does that, but the approval process is quite complex. TurtleSoft could do it more easily, at least for a while.

Dennis Kolva
Programming Director



Progress Bars (Feb 26)

Goldenseal accounting software shows a progress bar for anything that takes more than a second or two. It helps entertain users, and makes sure they don’t think the computer has frozen. If the bar moves slowly, maybe there’s time to fetch a snack.

To make the bar work, Goldenseal uses about 20 lines of source code to create a progress window, move the bar as things happen inside a loop, then close the window when done. Some bars have a button so you can stop before the end, which is a couple more lines. Our staff copy/pasted code blocks each time, then tweaked the details for each action. That was a bad decision.

The new accounting software has a permanent bar at the bottom of the window. Progress messages are also at the bottom. The new code is entirely different. That means we need to revise 125 different chunks inside many files, scattered all over the place inside the business logic. Not a fun project.

Sometimes it’s possible to use clever text replacements, and update masses of code without much pain. Our staff tried that, but it was too big a gulf. Reluctantly, we got new bars working for a few of the more common actions that need them. The rest still need rewrites, which we’ll add gradually during testing.

At least the new design is better. Now there’s a bar manager that sits in the middle. Three lines of code is enough to set up the bar and move it. Business code doesn’t need to know anything about the interface, so the next update will be easier. Sometimes we learn things the hard way.

Computers and storage are much faster now. The new app zips through some things so fast that we don’t even need a progress bar. It’s something we can tweak during testing.

Some progress bars were in import/export code. It’s left over from the early days of Goldenseal, when we frequently changed data inside the company file. Rather than write code to support older formats, we exported sample data to a text file, then imported it back. We’ve never used it in the past two decades. The Reports interface is a better way to work with company data and export it as text.

Right now, the new software does not show import/export commands at all. We’d need to spend a few days on the interface to get them working, and it’s probably not worth the effort. Most likely we’ll abandon them, unless someone complains.

Dennis Kolva
Programming Director




User Interface (Feb 15)

It has been an excellent winter for working outdoors. Many warm spells. Not much snow, mud, or frozen ground. Zero sweat, sunburn or biting flies. Most days, the routine here has been daytime physical labor, then programming our new accounting software during the long evenings.

The big project right now is 300 feet of French drains to handle runoff from the neighbors. Step one is trench digging, with the soil going into raised beds for gardening. Then add a 4″ corrugated drain, plus a water line for irrigation. Finally, fill with many tons of crushed rock (slag?) that a previous owner piled onto everything not lawn. Removing it lets us use those spaces for planting. The project kills three birds with two stones.

Last week was warm enough to assemble a greenhouse kit from Amazon. Sadly, the build process was a nightmare, with instructions even worse than Ikea’s. It took 27 hours, mostly puzzling over what goes where, and redoing whatever went to the wrong where.

Good human interface design takes time and skill, but it’s worth the effort. This build would have gone twice as fast if it were set up better. It lacked 1/2/3 instruction steps, simple part labeling with up/inside/outside markers, photos for difficult areas, and maybe tricks like matching color dots where pieces connect. Instead, the project was such a brain-drain that it left no energy for programming afterwards. It cost us quality time, not just time.

User interface is even more important for accounting software. It will be used for hundreds or thousands of hours, so every time-saver (or time-suck) has a big impact. Our staff runs each screen and function many times to test and debug, so we also want it easy for selfish reasons. Plus we manage a couple of businesses with it, and have to suffer any flaws.

Right now the main focus is progress bars. They aren’t that complicated, but moving them from Goldenseal to the new accounting app is tricky. The work is about half done.

Dennis Kolva
Programming Director

Reconciling Walmart (Feb 2)

Goldenseal is pretty good at reconciling bank accounts, but our new accounting software is better. The list of transactions loads almost instantly. It’s easier to switch from one account to another. But there still is a rough spot: what do you do when the bank statement doesn’t match what you entered?

Sometimes it happens because of typos, or bad data from faded/crumpled receipts. Sometimes it’s because of Walmart. They have a bad habit of adding an extra penny to sales tax for online orders, but then rounding correctly on the actual charge.  The result is a Reconcile line item that’s off by a penny.

Goldenseal has no easy way to fix that kind of error while the middle of a Reconcile. The quickest goes like this:

      1. Remember or write down the error.
      2. Leave the Reconcile window.
      3. Find the bank transaction and change its status to Void.
      4. Save changes. That removes Paid status from the purchase and unlocks it.
      5. Open the purchase, and enter the proper amount.
      6. Go back to the bank transaction, and also give it the proper amount.
      7. Change payment status to Entered, and save changes. That also updates the purchase.
      8. Go back to Reconcile and try again.

More than three weeks ago, our staff set out to improve that. The goal was to do the One Penny Tango in just a step or two. Except, we ran into bugs. Many bugs. One crashed the new accounting app. Several were due to changes in bank transactions. One zapped the purchase record in the database. That took a couple days to track down: a lingering problem in how we mark records as “dirty” so they’ll be saved.

The Walmart problem is almost fixed now. You can double-click in the Reconcile window, and see the bank transaction. Then right-click to see the purchase. You can change them and save, but we haven’t tested the posting yet. That will be tricky. It also needs to update the line item in Reconcile.

Adding those pop-up transactions is a big design change. We’ll need to play with it for a while, and see how well it works in real life. If good, the same thing can happen in all the other action windows: Pay Bills, Project Billing, Deposit Funds, Job Costing, etc.

Linking from one record to another is a big strength in our software. Usually it’s easy to get from here to there. The links also are a PITA for our programmers. They make a complex web, with so many ways to go wrong.

Dennis Kolva
Programming Director




Templates & Software Marketing (Jan 26)

Templates are a nifty feature in our construction estimating software. They are blank estimates already set up with dimensions and specs, so you get a running start on a project bid. In Goldenseal, click a little button to the right of the New button to see them. It shows a popup menu of available templates (some are already included in the starter files).

Sadly, many new users never click the template button, and lose out.

The new accounting/estimating software also has a New button, but it’s different. It shows a popup with New, Duplicate, and a list of templates. More obvious. It’s one extra step to make a new blank record, but worthwhile if it gives users an easier way to start records.

While testing templates in our own company file, Other Costs showed a long list of weird names: Accounting411, Ask Jeeves, BuilderSpace,, Capterra, ePilot, etc. It was a reminder of our phase 2 software marketing during the early 2000s.

Phase 1 started in 1987, with a $50 classified ad in Fine Homebuilding. It listed MacNail (our first estimating app) for $145. About 25 users bought it that year: a good return on investment. TurtleSoft soon upgraded to larger ads in every magazine aimed at builders, plus trade show booths and many bulk mailings.

When Goldenseal launched in 2000, we repeated phase 1, and got very poor results. Most people already had switched from paper to Internet. Next try was listings in every possible search engine and software directory. Hence the many templates for their monthly charges.

Those did better, but still not great. What worked best was SEO (search engine optimization). Our staff spent many hours tuning text, links and website pages to get on the first page for “construction estimating software” and the like. Also, many hours analyzing web traffic to see how buyers found us. Phase 2 was quite successful for 6 or 7 years.

Getting sales with a minimum of advertising expense was great, but SEO has a built-in problem. It’s best explained by the Red Queen to Alice:

“Now, here, you see, it takes all the running you can do, to keep in the same place.” — Lewis Carroll

If it’s successful, SEO gets your page high in search results. But search engines want to capture users, then have them click on ads. Different goals. SEO can out-smart Google for a while, but they soon adjust pagerank to bypass the tricks. Different SEO approach, different counter-measures. Rinse and repeat.

The result is a constant struggle, with no way to win in the long run. With AI entering the scene, it will only move faster.

Phase 3 marketing for our new accounting software will not be raw SEO. It has gone the way of magazine ads printed on glossy paper. Instead, I think we’ll revert to the advertising that worked best for Turtle Creek Carpentry in the 70s and 80s: word of mouth.

I’ll talk more about the details as the new app gets closer to first release.

Dennis Kolva
Programming Director

Bank Transactions, Name & Website (Jan 19)

This past week, testing the new accounting software gave all sorts of weird error messages. It turned out to be something stupid: the code for deleting records wasn’t finished. It screwed up the database and caused mystery errors in other places.

Fixing that still didn’t help for deleted bank transactions. That was a whole ‘nother problem. The new app made a big change from Goldenseal, and all details are still not shaken out.

Goldenseal uses 7 different data classes for bank transactions. All checking transactions are lumped together. Ditto for cash, credit cards, escrows, etc. To show records for just one bank account, the code pretty much does a Find. For various reasons, there’s no way to see windows for two different checking accounts at the same time. Sometimes it’s awkward.

The new accounting app lumps all non-escrow bank transactions together. Then each account keeps track of its own transactions. You can view transactions for as many bank accounts as you want, all at the same time. The interface is better, but it makes some things more complex.

One example: tabs and window titles show the bank account name, but the data is bank transactions. Everything else only needs one class ID for both, so a lot of code assumed that. I think we switched back and forth several times, fixing one bug for banking and making a new one. Now everything uses two separate classes, and things work OK.

There are more oddities, but our staff is tracking them down.

Meanwhile, the new accounting software is down to 3 possible names. We will register domains for all three, just in case the trademark registration falls through. We learned to be cautious after the 1990s rewind from BidWorks to BidMagic.

Also, the TurtleSoft website is switching to a different hosting service. There may be brief outages over the next week.

Dennis Kolva
Programming Director

Anatomy of a Crash (Jan 10)

Goldenseal accounting software rarely crashes, thanks to lots and lots of sanity-checking code. If something isn’t kosher, it gives an error message with the exact source code line that failed. That makes it easy for us to find and fix the bug. Then it exits to the event loop, so you can keep working.

The approach works well, but it does have a cost. Of the 26 megabytes in the Goldenseal app, almost half is just text for error messages. 99% of them will never be triggered, but it’s worth the weight to get quick fixes for the naughty 1%.

Programming the new accounting software works the same way. We rarely see crashes: just error messages and things that don’t work right. However, this week there was an actual crash. It happened after using the Link button to see the bank transaction that pays for a purchase. The dialog worked OK, but the app crashed later.

The bug turned out to be a dangling pointer in the bank transaction. We can’t test for those, so we must never let them dangle.

The accounting app has to keep track of which records are visible, so the screen will update if one is changed remotely. For example, changing payment status also changes the purchase status. In Goldenseal, each record keeps a pointer to the viewer it’s in (or null if not visible). When we post to the record, its viewer is also reloaded (if it exists).

The code is efficient, but a design flaw. A risky way to do the job. This wasn’t the first time the app has crashed there. Rather than slap on a quick fix, we decided to scrub it clean. The new app now checks every tab and window to see if the record is showing. No need for a pointer at all. It’s slower, but only by microseconds.

During the rewrite, a couple other possible bugs turned up, deep in the guts. To fix those, we need to understand the old code better. That means running current Goldenseal in the debugger, to make sure the new app does the same things at the same times. Linking records to the screen is complicated.

Setting up an old machine to run version 4.96 was a challenge. Because of the tough real estate market, TurtleSoft was in two temporary offices in 2023, plus the original and the new. Many chances for important stuff to be tucked away in a miscellaneous box. Some are still unopened.

We finally found an older Mac Mini with proper setup, plus all the wiring and converters it needs. Weather sucks, so app development is moving right along.

Dennis Kolva
Programming Director