Memory Lane – Uniface

January 10, 2012

In 1995, I started working with Oracle, with the front end being Uniface from Compuware. I worked with Uniface versions 5 and 6 from 1995 until early 1999. The screens were GUI, and worked with a mouse, but were character based. Something like Wordperfect for DOS at the time.

These Uniface versions we ran on Windows 3.1 machines with only 16 megs of ram! So, I learned a lot about tuning, having worked with Uniface!

Uniface was a client server product. It had an interesting concept. Create your schema using entities in Uniface. Uniface would generate scripts for table creation in Oracle. Then deploy it to: dbase on a LAN, Oracle on Unix, Sybase on a VAX, etc.

Then, you would create your screens in Uniface to access and modify the data. The screens were executable files that were stored on the LAN.

The idea was that Uniface would handle everything, in spite of the differences between systems. In theory, Uniface could work with two different products (dbase and Oracle) at the same time. One Face.

Uniface Strengths:

Read the rest of this entry »


Design a la Steve Jobs

October 25, 2010

Today I saw an article interviewing John Sculley, former CEO of Apple.  He spoke about the early days of Apple, Steve Jobs, and a lot about, Design.  I loved many of the things he said.   Here are some excerpts:

Steve, from the moment I met him, always loved beautiful products, especially hardware. He came to my house, and he was fascinated, because I had special hinges and locks designed for doors. I had studied as an industrial designer, and the thing that connected Steve and me was industrial design. It wasn’t computing.

Steve had this perspective that always started with the user’s experience; and that industrial design was an incredibly important part of that user impression. He recruited me to Apple because he believed the computer was eventually going to become a consumer product. That was an outrageous idea back in the early 1980s. He felt the computer was going to change the world, and it was going to become what he called “the bicycle for the mind.”
Read the rest of this entry »


Consuming Huge Amounts Of Unstructured Data

October 20, 2010

The recent presentation about Oracle Data Storage started me thinking about data.  I’ve worked with the Oracle database since 1995.  Lots of structured data in fields, tables and databases.  A certain amount of my job has been to turn these large amounts of data into usable information.  The result of which itself may in fact be unstructured, such as “the trend is …”.

But when I think of it, so much of what I actually consume and interact with, is in fact, very unstructured.  I started making a list of everything.

So much Content on the Web!

Google
Blogs and feedback
Webpages, articles, including animated GIF files that help explain things
News
Linked IN Read the rest of this entry »


Poor Or No Error Trapping

October 19, 2010

More Architecture Mistakes To Avoid

One thing that should be blatantly obvious to anyone who has ever had to fix some code on the weekend, or in the middle of the night, is the importance of excellent error trapping and logging routines.

When you need to fix something, now, you don’t want to be reverse engineering the code or the whole system.  You want to know what happened, and what to do.  Now.

You need what I call, instantly digestible error messages.  I don’t want to hunt it. I don’t want to kill it.  I don’t want to clean it.  I don’t want to cook it.  I just want to eat it.  I want both the cause, and the solution, in the same message.

The error trapping routine must be totally reliable.   Let me list some strange things that I’ve seen in production.

Complex and Useless:
Read the rest of this entry »


System Performance: Cobol Versus Database

October 7, 2010

More Architecture Mistakes To Avoid, Database Design Mistakes To Avoid, Tuning

When I started working with Oracle, I helped to replace a Cobol system. For a while, the company systems ran half on Cobol, and half on Oracle.  The Oracle 7 system was pretty slow then.  After the cold backups had run overnight, it was not unusual in the morning to see a query against a 700K row table take about 30 seconds.

I was asked to write a C program that only interfaced with the Cobol flat files, and read Cobol transaction records.  Each transaction was stored in multiple rows, and given repeating groups of records, could vary in size from a few rows, to dozens of rows.  The files contained about 700K to 800K rows altogether.  The program grabbed information out of the multiple lines, tallied the numbers up, and output one line of summary. Lots of IF statements, and loops.  About 800 lines of code.

I expected this program to take at least 30 seconds, given that database queries to similar size tables took that long, and that there was so much logic and so many lines of code.

In fact, the program ran in about 5 seconds!  I was really surprised.

But when you think of it, it should be obvious that Read the rest of this entry »


%d bloggers like this: