Bug Tools not in U2 Shops.

In U2 world (Universe, Unidata, and D3) very few of us use any bug related tools.  Maybe your IT department uses a spreadsheet for all outstanding tasks, or maybe you use email from users to fix and change software.  At U2logic many years ago we thought we would create our own tool.  We definitely were suffering from NIH (not invented here) mentality.  Our tool looked great because it was web based, but it suffered from a lack of vision of what was important.

One of the more important components was email feedback.  Whenever a task or problem is requested of you or your programmers, it should be visible to the entire staff.  That way if someone is on vacation or it is after hours then many eyeballs can and will be watching the bug tool queue.  When status is changed on your task or problem, the user that requested the task or pointed out the problem should be emailed with that notification.

Another important component that was missing in U2logic homegrown version was the ability to upload pictures.  We did not even comprehend how important this was to users.  Some users would spend hours designing a report or web form and we would either not pay attention to it or we would do our own thing for whatever reason.  With a great bug tool programmers and users should be able to upload screen captures, spreadsheets, text documents or PDF’s, so that everyone can visually see what is wrong or what direction they would like to go.

One component we have found that users and programmers must have is ability to edit and re-edit their comments.  We cannot tell you how many times some of programmers cannot spell and that makes the bug tool and the issue look bad.  We have found that users have sent us off on tangents because of bad descriptions of the problems.  Now, they still have bad descriptions but we can edit them back to reality.

After we abandoned our in-house tool, we went to Bugzilla which was very good but not well received by our users.  We have dropped Bugzilla for JIRA last year which is a paid tool unlike Bugzilla which was free.  Whatever tool you decide to use make sure it fits within your organization and those you support.

U2 Programmers Framework Creators

It seems everyone Universe, UniData, or D3 shop we have talked to in the past few years has been creating their own frameworks. These programmers thought they had to create the frameworks for everything they wrote including screening and printing routines. This article, fortunately, is only about printing frameworks.

A good definition for framework from "http://whatis.techtarget.com/definition/framework":

"In computer systems, a framework is often a layered structure indicating what kind of programs can or should be built and how they would interrelate. Some computer system frameworks also include actual programs, specify programming interfaces, or offer programming tools for using the frameworks. A framework may be for a set of functions within a system and how they interrelate; the layers of an operating system; the layers of an application subsystem; how communication should be standardized at some level of a network; and so forth. A framework is generally more comprehensive than a protocol and more prescriptive than a structure."

Whether this frameworks are used extensively or just with new code, this something that a lot of U2 sites continually propagate them.   Without documentation for these frameworks and the fact this framework is used only at a single site this means outside organizations such as U2logic must figure out what all of this code does and what it can do.   Some of the UniBasic frameworks are 20 or 30 years old and make no sense today.  What a programmer or company to do?  Easy answer is stopping using this madness.

At U2logic, we believe, in the open source model. Many sites have asked why we are using the Business Intelligence Reporting Tool (BIRT) as a framework for printing reports.  First, this was not a framework written by U2 people. Secondly, this framework is used by an estimated 7 million programmers. Thirdly, we can use internet resources like Stackoverflow.com to help us with BIRT questions or problems. Lastly, our UniBasic code has been reduced by at least 60% per program.

About a year ago we created an open data access to BIRT for Universe and UniData. This allows U2 programmers to access the world's most used open source report writer. We have converted about 100 reports to date for our applications. We have found our UniBasic code is so inconsequential to the report procedure. All UniBasic subroutines do is get the data in a JSON format to BIRT to format the report. No more sorting or special code on the UniBasic side to hide columns or add columns of data. All of these functions are handled on the BIRT side. This framework is updated at least once a year through the Eclipse foundation IDE.

For our clients of our applications and our clients of our tools, this means they have an open source frameworks for printing.  Should they need programming staff they will have a printing framework prospective employee's and other support organizations can have knowledge on. Sounds like a win-win for U2 marketplace.

Crazy release strategy (CRS)

Whether it is Facebook, or LinkedIn, or now even Microsoft, software changes will be released at least on a weekly basis or even daily basis by these companies.  Not to mention Google, Mozilla, or Oracle that are releasing software and a continuing basis for many years, this is a trend that it only escalating.

The quality assurance departments of those companies are either pulling their collective hair out or rejoicing in that the daily changes are far easier to test than changes that have taken the company many months or years to produce.  Probably many companies are just releasing software and hoping for the best outcome like Google did for years with the word Beta on the software page you were running.  Do we really know or really care?

What all of the CRS means that changes have to be drilled down to their smallest element.  The maximum time for those code changes and bug fixes are reduced from months and weeks to hours.  That means the programmers must have a laser focus as to the problem or enhancement and not worry or even think about the other ramifications of this change.  Those issues should have been already thought of by the person filling out the bug or enhancement request.

We here at U2logic have put out 25 plus releases this year for our flagship XLr8 Tools product.  There have even been some days that we have put out 2 releases in a day for various reasons.  One particular reason was the feature was requested by a user in the morning after we had generated a release and that user needed the release today.  We put out another release late in the afternoon with that feature.

In order to keep some control of your CRS you must have a good version control.  Another indispensable product is bug tracking system.  At U2logic we are using SVN for version control after using CVS for many years.  We are using Bugzilla for bug tracking because there is a built-in interface for Eclipse.  You never have to leave the Eclipse environment to version control, bug tracking, and programming.

For those applications developers, we at U2logic have been updating our code on a daily basis and sending it through our XLr8Installer to our customers.  Some days the customers could get multiple fixes and enhancements.  Does this sound like a Universe or Unidata programming shop?  We think not.

This CRS really is Crazy Release Strategy not Continuous Release Strategy.

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.

Your company killed your skill set

It is probably not intentional that your company is actively killing your skill set or maybe it is.  A better view is that they refuse to train you in any new technologies because of your age, or the fact that their applications you are maintaining are hopeless out of date, or change is not something that they want to embrace for business reasons.

Many years ago when my former partner discussed where the U2 (Universe and Unidata) industry is going, he believed that we would always make money as consultants.  Since most of our clients we were their IT department that seemed like a safe statement.  When the economy does is down cycle, then the first people that are out of work are the consultants whether you are running your clients business software or not.

Our U2 world with its plethora of "green screen" applications with the accompany tool sets written by staff that has a lot of learning to do.  Whether it is education of the current IT department, with seminars, or in-house training, or even enrolling in University sponsored, management must embrace it.

Enrolling in U2 University is a start.  But the learning at U2U is more of a walkthrough of current technology and will not help those who do not know what data objects are or even there is a format called JSON.  The web, the resource at your fingertips, is the best place to start.  Some programmers spend hours and hours reading articles and taking on-line study guides.

In summary, your company has a lot responsibility to have you highly trained.  But the question is will they spend the money?  More importantly, you have to push you company to embrace new technology and you have to have gained the knowledge to help them along this course.

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.

The Red Headed Step Child

U2 databases Universe and Unidata are like the red headed step child.  U2 has had a lot of suitors from Informix to IBM and now to Rocket Software and still not much as changed.  The growth rate is double digits, but the software is still not well know.  There are approximately 35,000 customers with 2.7 active maintenance licenses around the world.

Rocket/U2 does not really have sales people that sell software because the have none to sell.  All of the sales are driven by U2 VAR's that package the database in with their software.  The time to change this model is now. 

When Oracle started in 1977 selling its signature database and middleware it only took 9 years before it started developing business application software.  In the intervening years it spent billions to purchase software companies like PeopleSoft, Siebel Systems, and Hyperion solutions to name just a few of the 100 or so acquisitions.

So Rocket needs to loosen the purse strings and start acquisitions that help sell the databases licenses just like Oracle and Microsoft are doing.  Then those sales people will not be writing sales orders from the VAR's, they will be out on the street, so to speak, making those sales.  The growth rate could be 10 times better instead of a 120 million dollar business that should be a billion dollar business.

Think about would you rather buy your software from a VAR or the company that makes the database?  Easy answer in Q4 of 2010 Oracle had 7 billion in licenses and 13.1 billion in software services.

PHP for U2 databases

After see a crude but amazingly effective demo of PHP for the Web, I was convinced we needed to have an easier way to access U2 from the environment. Well, after searching for many hours on the web I found PHP Java-Bridge.

This open source software allows you to access any Java code without a lot of hassle. Within a few hours U2logic's Java programmer had a fully working interface. Installation is a bit more complicated because of our use of Apache's Tomcat but that is really nothing in the big scheme of things.

Our U2WebLink(tm) product has another way of accessing the U2 databases using PHP instead of HTML/JavaScript. This means that Python can use this system as well. More back for the buck, you can not really beat that.

I hope those of you reading this blog will try it out and give us some feedback.

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.

Horse Blinders for U2 Programmers

Over the course of many years we have wondered why U2 UniBasic programmers still insist on coding with vi, notepad, ED or AE. The latter two are line by line editors that were developed in the 1980's and are installed with the database. So coding with horse blinders on seems to fit some of our esteemed colleagues.

Many programmers believe ED or AE keeps them focused on what is in front of them, encouraging them to pay attention to the code rather than other distractions. ED or AE programmers are commonly seen to help keep them from being distracted or spooked. See the real Wikipedia explanation http://en.wikipedia.org/wiki/Blinders and not the satirical piece that was co-opted in this paragraph.

That not to say they cannot do the job or that the job they do does not have value with those tools. The point really here is that some U2 programmers are stuck in the 1980's coding with those tools or have some hybrids that have been cobbled together from various open source projects. Why should we not be programming like millions of Java, C#, and VB programmers that have great tools.

We can have state of the art tools with full screen editors, reserved word colorization, syntax completion, cognitive help, local or database editing, search, local history change log, and version control to name a few of the new features. Bugzilla or other connectors can be attached to some editors an allow you to see what bugs you have to fix or software you have to enhance.

Some enlightened programmers live all day in their tool set and very rarely wander into the world of TCL (terminal control language). Of course, we know a few of them.

Eclipse platform is what IBM, the former owner of the U2 databases, believes is the integrated development platform of the future. Eclipse is used by hundreds of thousands of programmers. There are plug-ins for many languages such as Java, PHP, Cobol, C++, and C# to name a few that come to mind. There are thousands of other plugs-in to do whatever you can think of.

The Basic Developer Toolkit that is part of client software for U2 databases since 2008. The Basic Developer Toolkit is free when you upgrade your database. The other Eclipse developer is from U2logic, Inc. and it is called XLr8Editor. XLr8Editor has been on the U2 market since late 2006.

It time to change old habits and move to the 21st century.

Looking for the "one".

I have spent countless dollars and hours looking for the "one". I am not talking about the finding a significant other. What I am talking about is a tool for the Universe/Unidata world. Not a day had gone by when some programmer would announce the great tool since sliced bread. I cannot name half of them nor would I care to.

Today, except in some green screen software companies and those not enlightened, every one is looking for a way to GUI the interface for the multivalue applications. To say I found the solution for everyone is a brash statement that would need considerable facts that would be worth the effort. There are, however, some points that I have learned in this arduous process of taking code that is some cases over 25 year and moving them into our Web-enabled world.

I have a significant amount of business logic that I just do not want to lose or reinvent, so what did I do with all the Basic code. First, every program that had a user interface (UI) was removed. That's right I delete all of the UI from the Basic code. All that was left was just the basic code necessary to update the files and verify the integrity of that data or the business logic.

I found JavaScript a scripting language that is very close to Basic in many ways and unfortunately very close to Java as well. The validation of dates, numbers, codes, and even calling Basic Subroutines to verify inventory levels, was re-written in JavaScript. I, then, had a series of functions that could be called from any form and perform the data checking I needed to accomplish what I had been doing in Basic for many years.

I had not even found the "one", but I found a way to accomplish one of the goals without purchasing a product.

There is a great tutorial at W3Schools if you need help with JavaScript.