All posts by Henk van der Veer

The new Uniface Integrated Development Environment .. more than just a new term

Uniface 10 is all about the new environment for developing Uniface applications. To underline that, we  have given it a new name: the Uniface Integrated Development Environment, or Uniface IDE.

For thirty odd years, we have referred to our development environment as ‘the IDF’. What does the term IDF stand for? How is IDE different from IDF? Is the difference relevant at all? Here in  the Lab, we use the terms IDF and IDE to make the following distinction:

  • IDE is the development environment for Uniface 10
  • IDF is the development environment for all Uniface 9 versions.

The IDE in Uniface 10 has its own new executable, called ide.exe. You can find it in the common/bin folder.
This new IDE uses a new assignment file, named ide.asn. This file is in the uniface/adm folder.

So, some things have changed, others have not. The logical path to the database that stores the repository is still called $IDF in Uniface 10.

IDE and IDF are totally different applications with their own characteristics and a very different user interface. Added to that: the repository has been changed substantially to cater for new functionality in the IDE. So, it’s important for us to distinguish between IDE and IDF.
The Uniface 10.2 IDE is largely composed of a completely new set of editors. Editors for components, modeled entities and projects, to name a few.
And yes, the IDE still contains a subset of editors that also exist in the IDF – you will find these under ‘More Editors’ in the IDE’s top menu. Over time, the old style editors will be replaced by new style editors, i.e.  IDE style editors

Where does the term IDF come from?

Way back, in the late eighties and early nineties of the previous century, the days of Uniface versions 4 and 5, the Uniface development tool was called Information engineering & Design Facility, IDF for short. Here’s a screenshot of the IDF start screen, taken from the Uniface 5.2 manual (and notice that other terminology has changed over time!) 

Uniface 5.2 Manual
Uniface 5.2 Manual

The name idf was also used for the executable that started the development tool: idf.exe on Windows and VMS, or just idf on Unix.
To use the development tool on Unix in those days, you would typically use the environment variable $idf that was defined by the install scripts. And to keep things simple, a predefined logical database path $IDF is used by Uniface to this very day to define where the repository is stored. 

In later versions the term Information engineering & Design Facility disappeared. We introduced the term UDE, short for Uniface Development Environment. The terms UDE and Uniface Development Environment were used all over the place in the documentation,  but I don’t recall ever having seen the term UDE in the tool itself. The executable that started the UDE was still named idf.exe – we’re talking Windows only in the meantime – and the assignment file for the UDE was still named idf.asn.

Enter the $UDE function in the Uniface Proc language in Uniface 9. A function that helps the developer define custom actions on repository data, including compiling, exporting, importing, and converting. On disk, you will find a file called ude.exe. This executable is not used to start the Uniface Development environment, but is used by the $UDE function. There is no ude.asn file for the ude.exe.

And for completeness sake: for a short period in the Uniface 9 lifetime we used the term Uniface Application Platform Suite, or APSThe APS is the workbench that integrates Uniface application development with the BPM product Uniface Flow. Note that as of Uniface 9.7, Uniface Flow is no longer delivered.

Summary
Uniface IDE vs IDF
Uniface IDE vs IDF

Confused? Naah, not anymore, I hope ….

 

A toolbox in Uniface 10, anyone?

What’s an engineer without tools? The first hit of a Google search for the phrase “Engineer without Tools” is a quote from Star Trek Deep Space Nine – Millennium Book Three (Inferno): “He was alone and useless, an engineer without tools, … “

Alone and useless … I guess that says it all.

Vice versa: the better the tools, the more efficient the engineer can be. Application developers, software developers, software engineers, they all need tools. Of course, the Uniface Development Environment as we know it in Uniface 9 and before is a very advanced tool already, or a collection of tools. In the Uniface 10 IDE we take that to a much higher level, using the concept of the toolbox.

The next release of Uniface 10, internally named 10.00c, shows the first contours of the toolbox. This release will be used for product demos at User Conferences as of mid-May. And no doubt the toolbox will be featured in the next product update on the Uniface Partners United website.

Each task in Uniface 10 will have its own dedicated toolbox. Visually the different toolboxes look and work the same and they can always be found in the same location: at the left side. A toolbox provides the elements (the tools) that are appropriate for creating content in the editor we’re in: when we model an entity we’ll have a toolbox that enables us to create fields, keys and relationships. The project editor will provide a toolbox for creating project content: the elements to choose from in the project editor’s toolbox may range from a single component to a completely predefined application.

The Component Editor in Uniface 10 has three main tasks, each supported by its own specific toolbox: Define Structure, Write Script and Define Layout. Here’s a preliminary screen shot of the Component Data Structure toolbox:

Henk blog May2

The toolbox allows for multi-select, which makes it easy to pull multiple elements into the editor with just a few clicks. In a superficial test we noted down which steps we needed to create a data structure for a DSP based on a modeled entity.

First of all, it’s much more intuitive to discover what you need, because the toolbox puts it ‘in your face’. But more important, in Uniface 10 we needed less than 50% of the mouse clicks compared to Uniface 9.6 to achieve the same result.

But it’s not limited to these benefits, in fact the sky’s the limit! Engineers can create their own custom toolboxes. Whether as a matter of convenience or as a way to encourage or even enforce standards, e.g. project or organizational standards. Agreeing on standards and guidelines is no longer an exercise on paper, but can actually be implemented through software in an intuitive and consistent manner.

One small step…

Since Neil Armstrong landed on the moon, stating “That’s one small step for (a) man…” the moon’s surface hasn’t changed much. At least, to my knowledge. Maybe a few rocks have been moved, but to me the moon by night still looks the same as back then in 1969.

The difference with the changes in development land could hardly be bigger. The older programming languages aren’t extinct yet, but many new have appeared on the set, including complete frameworks implemented in one or more languages, each with their own API. Back then, say 20 years ago, life was simple.  You learned one language, at school or in your own spare time, and reached a varying degree of expertise in that single language. Maybe you touched a second language at the surface, to make sure you could at least read the statements. But programming in a second language was, well, let’s say a challenge.

It may sound like a memory from past life, but I do remember an annual company kick off meeting by – back then – Uniface Corporation in the US, probably around 1992 or 1993. All sales reps and tech reps came to Alameda, CA for a few days and one of the items on the agenda was a ‘pub quiz’ for the techies. A questionnaire with a dozen or so questions about our infamous Proc Language constructs. Of course, we were all cocky, as a tech support guy (or girl) you wouldn’t see the light of day if you didn’t know the Proc Language manual by heart. It was easier then: we knew one language and we knew it very well, it was still limited in functionality and in syntax.

Today, developers hardly ever work with one single development language. They often find themselves in the middle a Software Development Ecosystem, a virtual working space consisting of a variety of tools: development tools, build tools, test tools, etc. But even merely developing a modern application user interface already involves frequent switching between languages: Uniface, JavaScript, HTML/CSS, maybe even Java…

And then, the modern languages are functionally much richer too. Meaning: more functions, more command statements. But also meaning: sometimes small but sometimes big differences between languages for the same type of constructions. For most humans it’s near to impossible to memorize the exact syntax in each language. Already within a single language the syntax may not be strict, often due to later developments and new insights when enhancing the language.

For example, compare the following two Uniface language constructions that sort of serve the same purpose:

Target = $item(Id, Source)

getitem/id Target, Source, Id

Each time I use one of these statements, I find myself invoking the online Help, simply because I forgot. With or without parentheses? And what’s the order of the parameters again?

Comes the IDE to the rescue… Ideally the language editor in the IDE of your choice provides hints, or even better: a degree of intelligent code completion. It takes away the mental load of memorizing and the nuisance of separately looking it up in the reference documentation. So, where is Uniface’s IDE in that respect? Well, we can’t revert the past: it was never there except the keyword coloring and keyword completion (using Tab and Shift Tab to scroll through a list statements or functions one by one).

Uniface release 10.00b, released internally last week for the purpose of showing at User Group conferences these days, makes the first small step:

Henk blog 1

Yeah! Just what I needed: I can see which parameters are expected. I can see their types, their order. I can see where I am in the construction, i.e. which parameter I’m at. Admittedly, a first small step. But remember how Armstrong started. Many more steps to make, one at a time.

And while we’re at it, you actually see a glimpse of the new Script Editor, with new features like line numbering and code folding:

Henk blog 2

More about that and all sorts of other new stuff in 10.00b in the next blog.

Henk van der Veer

PS: I mentioned Java once, but I think I got away with it all right …

Picking Up Speed

Now that Uniface 10 is presented at user group conferences worldwide, it’s high time to start blogging about this new version. My name is Henk van der Veer, program manager for this new release. And I find myself in good company, in a mix of colleagues with a similar longevity of working for the Uniface product (25 years) as well as brilliant young colleagues, less tainted by Uniface history and crucial to the Uniface IDE modernization. And that’s what Uniface 10 is about: the mix of maintaining its strengths, preserving the customers’ ROI and reshaping the IDE’s User Interface.

So, let’s kick off this blog about Uniface 10.  What, dear reader, can you expect from this blog? I plan to blog on a monthly basis about this project. First of all to keep a finger on the project’s pulse and provide a sneak preview every now and then. But also to share news from behind the scenes that we think is of interest to you, obstacles we’ve overcome with solutions worth sharing.  But be aware: there’s also a zillion things this blog is not. Like, it’s not an alternative for attending the product presentations at User Group conferences and it’s not the channel for formal product announcements or product downloads.

Before we start to look ahead, I have to make up a bit for the recent past. Early September we created a stable code drop, internally named 10.00a. This version was provided to be shown at User Group conferences in the fall of 2013. For the first time we showed actually working software instead of mockups at these conferences. Big deal? Yes, pretty big deal. We were now delivering software that realizes the ideas we’ve been telling you about before.

If you’re only remotely involved with the project, you might think that the project is – finally – picking up speed. Well, if you’ve been involved in a software project of a certain size, you know there’s an unavoidable phase with lots of activity before artifacts become visible. Call it lead time, startup phase, research, whatever you call it: it takes time. We created very detailed mockups of the new Uniface 10 Look and Feel. We used them to develop new ideas, to present ideas to stakeholders, to challenge each other’s ideas. We involved a 3rd party, specialized in ergonomics, to review the future product using these mockups. We did not want them to tell us what the new user interface should be like, but had them challenge us. We had to convince them that the user interface we developed was the best way to discover and apply the strengths of our product.

What does 10.00a bring us? Apart from an extensive new framework (a set of APIs developed in 4GL) that provides and consumes data, that handles exceptions consistently, that controls transactions and enables multiple editors open at the same time (I could go on); version 10.00a shows the contours of what the final product will be. It’s not GA, it’s not eligible for sharing with early adopters, but it does show what the GA product is going to be like. We’re building the real thing and it shows how the Uniface 10 IDE will be a showcase of a modern IDE and a modern Uniface application.

Bluntly spoken, the IDE is just a set of editors. Pretty sophisticated editors, I should add. We started with developing the Component editor. It’s the most encompassing and most complex editor.  The first thing that strikes the eye is the ability to have multiple editors open simultaneously:

Henk1

In the Uniface 9 IDE and older versions you may not recognize editors as such: the IDE looks like a large set of forms that can be invoked one after another. Editing in Uniface 9 is ‘form based’, and too often does not provide a clear notion of the context. In Uniface 10 the context is always visible. For instance: the component editor immediately shows which tasks belong to creating that component type:

Henk2

And just like navigating between editors by clicking on a tab you can switch between the tasks for a component. Of course, we only show tasks that apply to a specific component type. For instance, a Dynamic Server Page as shown above has a layout which is maintained on the Design Layout Worksheet. A Service on the other hand does not have a layout:

Henk3

By the way, did you notice: goodbye to Proc, hello Script! We’re no longer calling the Uniface procedural language ‘Proc’. The language constructs will not change, but we’re calling it Script from now on. We think that’s a better term that has a familiar ring in the industry. I mean, who in the world calls their language Proc? But I admit, the term ‘Proc’ has become embedded deeply after so many years. In the Lab we even use it as a verb: to proc. If you’d make me pay a dime for each time I still say Proc instead of Script, I’d be broke soon.

So, what does the Define Structure Worksheet look like then? It’s no longer limited to just the structure of entities, field and labels like you are used when you create a DSP or USP today, but it provides direct access to some common properties:

Henk4

At a glance you can see the hierarchical component structure and examine whether elements in the structure inherit from a model or from a template and whether the inheritance is broken. You can even edit an object’s properties in line in this view. But of course, Uniface objects have a lot more properties. These are visible and editable in the same view, in the Properties Pane at the right side:

Henk5

There’s a lot more to say about 10.00a, but this blog is not intended as a presentation or a course. Todays’ blog was merely intended to provide some context for the next series of blogs about Uniface 10.

Next time I’ll elaborate on what we’re developing right now for the next code drop, 10.00b. Within the Uniface lab we use the agile Scrum methodology. Each development cycle (each sprint), lasts 4 weeks. Every 4 sprints we aim to deliver a code drop that is stable enough and has enough new substance for us to show at User Group conferences and customer visits to the Lab.  We will show version 10.00b at User Group Conferences in the UK, France and Australia and we’ll also run an online session somewhere around April 2014.

See you in a few weeks!

Henk van der Veer