Software and the Auto Industry

Many years ago I was wondering why personal computer (PC) pricing was dropping and car pricing was rising. Several news articles explained the difference, but I still did not get it. I never thought much about it because I did not want to reboot my car at 75 miles an hour on a highway.

One day though I ran across this information from http://www.teslamotorsclub.com/showwiki.php?title=Model+S+software+firmware+changelog that has a change log.  I have many change logs for our U2logic application software and our XLr8 tools software.  I know what those are.  I own two cars. I know one of those cars has about 7 computers. But never once have I had the dealer call and say I need a software update.  With, I’m guessing here, millions of lines of code running these computers why have I not ever had an update?

Maybe the auto industry, except Tesla in my example, thinks you bought the car or truck as is and you don’t need and update. Obviously, the government will not let a safety update be withheld, but all else is up to the auto company you bought it from.

Let’s, for example, buy a car without cruise control, automatic door locks, and dual air conditioners for you and your seat mate. A few months after you bought this great car, you want the prior mentioned options.  Guess what you are out of luck whether by design or by lack of forethought.

Maybe if all cars were built with all of the hardware installed and the software controlled the use, then you and I would have to pay for those options just like we do with our desktop software.  With the reduction of components that go into the car by using software to control those options, there would be some price reduction but nowhere what I would like.

Next time you are driving to work think about all of the functions you are using to get from your home to work that could be computerized.  Or maybe I will be calling you from my “Johnny Cab”.

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.

Finally a "real" editor for D3

OMG, what is this flip the buffer thing.  I am ported back in time.  Yes, that is what is happening.  I have to edit a program in D3 and I forgot about flipping the buffer to see the changed code.  It cannot be 1984 again.  I did not like it when I first experienced D3 but it was not called D3 back then.  What was it called?  Maybe it was called OA or R83.  Why should I care why is this editor so archaic?  This is just a dream.  I'm waking up now...

U2logic has created a full screen editor using the open source program Eclipse IDE for our D3 programmers.  You can experience continuous compile of your D3 code.  You can have a local history of all your changes to each program.  You can have highlight reserved words that can be any color that Eclipse supports.  You can edit D3 programs from you Mac or Windows work stations.  You can see compiler errors via the Marker window by line number.  You can see compiler error via console window.

Within Eclipse there is support for source code control for D3 via mainstream technologies like GIT, SVN, Team Foundation, and others.  If you have a particular source code technology you like, they will have built an Eclipse plugin to access source code server.

Over time has we get going we will add the ability to copy from D3 to U2 and from U2 to D3.  This will make porting or moving data from system to system pretty easy.  We have use our copy and paste technology to copy between Universe and UniData for years.  Our copy and paste technology allows us to copy data from server to server faster than most other U2 products saving you time.

Many D3 customers have already ask us to port many of our other tools to work with D3.  We are prioritize them now and will be adding them over the next many months.  Thanks to all of our beta testers for their valuable input whether it be a bug or a suggestion.

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.

Copyrighting and defending your UniBasic code

Although I would not consider myself an expert on this topic, I would like to explain this from my point of view.  All of U2logic's software did have what is called an unpublished copyright right.  This means we have not spent the money or time to get a copyright on our software from United States Copyright Office:

"Copyright is a form of protection provided by U.S. law to authors of “original works of authorship.” When a work is published under the authority of the copyright owner (see definition of “publication” below), a notice of copyright may be placed on all publicly distributed copies or phonorecords. The use of the notice is the responsibility of the copyright owner and does not require permission from, or registration with, the Copyright Office."

Over the last 20 plus years we have sent out UniBasic source to our customers thinking we were protected.  No so much.

One of our clients, or should I say former client, told us they no longer wanted our software and were not using it even though it was embedded in their operational software.  I believed them.

Some years later they stopped support on our last product they had licensed with us.  They said they were going to SB/XA.  Besides my confusion from going from U2logic's Web based products to SB/XA which is web based, I thought this was very suspicious.  I went to their facility for a conversation with one of their programmers and noticed they were still using the software we had licensed to them many years ago.

Our former client said they owned the software since it was embedded.  U2logic hired lawyers to protect these U2logic's assets.  Many years later and hundreds of thousands of dollars, U2logic prevailed in court.  See internet references using "U2logic, Incorporated v. American Auto Shield, LLC".

All of U2logic's code is covered with copyright issued from the United States Copyright Office.  Any new code written will be copyrighted as well.

No blogs were published while this lawsuit was active as to not give the other side any ammunition or insight to their adversary.  From today forward please keep watching as the backlog of ideas come streaming forth.