Debugging versus Logging

Being first to the market with our XLr8Editor for Universe and Unidata, we were asked why we did not have a debugger.  Most of the time the answer was that you could not hookup to Universe's RAID debugger or Unidata's debugger without Telnet session and some type of changes to both products.  After Rocket Software's BDT came out with a debugger we looked at what they had done.  Rocket Software had changed both Universe and Unidata to talk to Eclipse.  Now our answer was that we needed access to the API they wrote for Eclipse.

In "The Practice of Programming" the authors Brian Kernighan and Rob Pike state: "As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient."

We have found the debugger certainly has its place but we are not Fan Boys.  Whenever a program has HTML, JavaScript, and UniBasic code, how can you figure out where the problem lies?  Maybe you are not even getting to your UniBasic code and your error is in the JavaScript.  That is why we use Firebug's console.log statement in JavaScript which just prints out a log to the console.  In our UniBasic code we call a logger throughout our code.  This logger subroutine writes out data to a file which we can use later to figure out where our problem is.

We always do say that logging has its problems.  It can slow down an application and calls to the logging subroutine are sometimes left in long after the problem is resolved.  However, we find that the process is much cleaner and we can look at the output long after the program has been run.

Vindication of our Release Strategy

Many U2 (Universe and Unidata) programmers had disliked and voiced their opinion negatively when U2logic announced many years ago that our XLr8 Tools was going to 3 to 4 week release cycle. We felt that most of our bugs and enhancements could be released after they had been completed, unit tested and quality tested.  While Firefox, Chrome, and Safari browsers were getting released at least every month and half, we did not see any reason we could not do the same even though we have a smaller team.

Just the other day Rocket Software announced that it has been releasing it's Eclipse based tools almost every month since March of this year.  They also stated that they had fixed around 60 bugs, plus added many new features.  A competitor vindicates our strategy.

During the same period as Rocket Software, U2logic has enhanced and fixed over 140 items.  We should be patting ourselves on our back for a job well done.  This represents a lot of work from our staff of programmers, testers, QA's, and customers.

Whenever we are going through our Bugzilla items and deciding what we will tackle in the next few weeks, we are always aware of this mandated release schedule.  We have stopped working on some enhancements because they are taking too long and would contribute to a slower release schedule.

The question becomes can we keep this strategy going for more than a couple of years?  Is this strategy harmful to our customer base?  And last but not least, can we remember what the release numbers mean after 10 or 15 releases?

Just in case you have not updated your copy XLr8 Tools, the current release is 3.5.15 which was released yesterday.

ABS Brakes and U2 Databases

While my life experiences were flashing before me in the few seconds before my ABS brakes gripped the frozen payment in front of a stop sign, I thought how similar this braking system was to U2 databases.

ABS was first introduced in late 1920's by Gabriel Voisin for stop his aircraft without blowing tires.  It took until 1970's when Ford and General Motors first put them on mass production cars.  Around the early 1990's you could get ABS brakes as option on most cars.  ABS brakes took some where around 60 years to refine the technology for the masses.

The Pick database the precursor of U2 databases Universe and Unidata was started in 1973 with the release of Microdata version.  In around the middle 1980's Universe and Unidata we started.  We are 40 years in to this technology.  Hopefully, before the next 20 years main stream users, programmers, C-suite people, and the media will find out revolutionary these databases can be.

I believe we won't have to wait another 20 years to harvest this technology.  I, with my team of programmers, have created our suite of tools using Eclipse IDE.  Our XLr8Editor allows editing of programs, dictionaries, procedures, paragraphs, and data with built-in version control.  With our XLr8Resizer you can resize your account with a few click of the mouse.  Our XLr8Installer allows you to build a XML install script you can run to build you software accounts for your internal use or for your customers.  Our XLr8Developer and XLr8Object Editor the help you create these wonderful web pages using our middle-ware call U2WebLink.

U2logic offers free trials on all of our tools.  With U2logic there is no capital investment you just pay maintenance every year to get access to all bug fixes, releases, and email support.

Scope is either local or global, but not here

Having an animated discussion with a Java programmer is not always the best way to start or finish you day. Java programmers have a valid point about the strong typing of variables that Java requires. This was no contest with Java and UniBasic, because I have spent the better part of the last two weeks changing our Java U2WebLink. I really know what scope is after trying to figure out why Eclipse editor kept pointing out to me that I had my code in the wrong area for the try/catch loop to work.

Had I not been programming in UniBasic so long, I should have known what variable scope is. All of the variables you create in UniBasic are global, so what is the local scope thing anyways. Wikipedia defines local scope as: “…a variable that accessible only from the function or block in which is declared.”

In UniBasic a variable is assigned through a couple of ways. It must be on the left side of any operation such as math or string manipulation. You can introduce variables through Common statements, includes or my perennial favorite Subroutine calls.

So now you ask yourself how a UniBasic programmer keeps track of all of those variables. Surprise I don’t. That’s right I don’t. If the programmer before us was good or bad I don’t sometimes care with how prior programmer handled the variables. If the program is working then the variables are handled correctly. When the program starts malfunctioning then I have to care and must trace the problem.

That is where the fly is in ointment. UniBasic programmers have no tool to show us where all the variables are assigned or re-assigned which Java programmers have built into the Eclipse Java Editor.

U2logic has begun to approach this problem in our XLr8Editor that is based on the Eclipse IDE. Hopefully, in the next few months I will have something positive to show that UniBasic programmers can control their scope as well.