Tag Archives: Windows

Red Hat/OpenShift – Finding the silver lining

I have been in the Uniface business for longer than twenty years. I have experienced the GUI baby steps of Uniface 6 at around the same time Windows 95 saw the light. I could keep up with the new features that were presented with each new version of Uniface that was released. So, with regards to Uniface, I can proudly say that although I may look like a monkey, I am an old monkey. I know a lot of tricks.

The world is changing at a fast pace and it is necessary to keep my bag of tricks up to date. With Uniface moving into the direction of supporting cloud features, I feel that it is necessary to do a bit of homework to prepare myself for this mind shift.

As a first step, I joined a few colleagues at the Red Hat Openshift Roadshow that was held in Amsterdam. With many similar cloud-technology related events currently taking place and with Uniface being so strong in supporting multiple platforms, it seemed like a good idea to search for the silver lining at the Red Hat event.

Red Hat Cloud Blog

Why Red Hat?

Red Hat is just one of multiple platforms that Uniface supports. It is a leading enterprise Linux platform. It is supported on both Amazon Web Services and Microsoft Azure. These two providers are currently the preferred providers for Uniface cloud support. In addition, it is also open, reliable, secure and flexible for customers who have business-critical systems.

How does Red Hat align with the goal of supporting multiple platforms for Uniface?

At Uniface we are not in the business of putting one platform in front of the other. We want the client to make the decisions around the technologies that are going to be used and we want to fit into it. Red Hat is just one of the platforms that we as well as the cloud providers do support. What makes us strong, is the fact that we can confirm that Red Hat is one of the many platforms that are on our list that we can tick off.

What benefits does this bring?

As a result of our work, we now have the infrastructure in place to verify and test Uniface on cloud platforms, therefore enabling us to tick the box that Uniface is supported.  This means customers do not need to make changes to their application source code, because, we can deploy to Red Hat as well as other platforms in the cloud in the same way as if they were deploying to on premise operating systems.

What is OpenShift?

Before we understand what OpenShift is, we first need to understand a few other terms (in short of course).

  • Infrastructure as a Service (IaaS)

When a provider runs computers on demand with specified configurations. This is alternative to rack and stack hardware. You specify the amount of RAM, CPU, disk space and operating system and the provider starts up a machine that meets these specifications within minutes.

  • Software as a Service (SaaS)

Requires zero or very little maintenance or setup. You just sign up for a cloud based service and it is available for you to use. A simple example of SaaS is Gmail.

  • Platform as a Service (PaaS)

This falls between IaaS and SaaS. Currently it is targeted at application developers. With PaaS, all the necessary pieces of your application are spinned on a server up from either the command line or a web interface. These pieces can be applications and databases.

This is where OpenShift starts to play a role. OpenShift provides the command line/web interface for the developer to spin up everything. From one command, all the necessary networking and server installs are done and a Git repository is created. OpenShift administrators will update the operating system, manage the network and do other admin work so that the developer can focus on writing code. The interface also allows the user to scale his application and do some performance tuning.

What does this mean for Uniface?

The strategy of Uniface has always been to support multiple platforms/databases etc. Internally, we are currently using Ansible as part of our build processes rather than OpenShift, but we are always investigating new ways to improve our processes and we try not to focus on specific technologies or tools. Therefore, from a DevOps point of view, I do see that OpenShift could play a part for us.

By making use of Infrastructure as Code, we can spin up multiple processes in the cloud to assist us in our build and verification processes. In our case, our application(s) are our tests, and we can now run them in parallel. We are also able to research new platforms without making investments in new physical infrastructure. This is a micro services approach which is the magic of the cloud.

I see OpenShift as a possible tool that can be used by our users. It is very powerful and useful and could be used to deploy applications into cloud environments, and to scale or contract as required.

Every cloud has a silver lining. The new silver lining is the fact that the cloud opens up so many restrictions. With new tools released every day, it is important to stay informed so that we can also be as open minded as the cloud.

Uniface 64 bit deployment for Windows

During the deployment session from the Uniface Lectures, we covered Uniface 64 bit deployment for Windows in the morning session (not in the afternoon because it took to much time, the videos are available to watch on our YouTube channel though). 

We had a few really interesting questions, I’ve worked the answers into the text below and I dug up an old posting from the old Frontline site, and used that as the basis. 

The oldest Uniface PAM (Product Availability Matrix) I could find was from Uniface 6.1, and with that old version we  delivered 64 bit support on DEC Alpha hardware with Uniface 6.1. OpenVMS, and DEC Unix ports of Uniface. I remember seeing one of the DEC Unix workstations here in the Amsterdam Lab, running the Motif GUI and thinking how advanced it was, how fast it was and I wanted one. Always dangerous to wish for more, I ended up with a Mac on my desk a week later. 

For a number of releases we focused on Uniface server versions for 64 bit, think IBM AIX, HP-UX, Intel Titanium hardware and so forth.  

It was in 2012 that we delivered a 64 bit Windows server version, delivering it in Uniface 9.5.  

It took us a long time, and to be honest, I recall have a few conversations on the topic over the years, and from an out and out technical perspective, the view was that there were few perceived benefits when compared to the 32 bit version to justify the investment to make it happen. I should mention that we had done some clever things with compiler switches to enable memory addressing for a number of releases. 

A Windows 64 bit Uniface client was a different story, and was quite a significant project.  Clearly there were overlaps with the Windows Server (technically they share a lot of common source), but the GUI layer needed a lot of work. We had to refactor a lot of code, as we had a lot of legacy (technical debt) from older versions of Uniface. The name Uniface originated from Universal Interface, and it was possible to develop one Uniface app and deploy it on those old GUI platforms which we used to support thanks to the Uniface specific widgets such as the unifield.  (I’m sure some of us who have been around Uniface for a long time remembers Uniface on Mac, Motif, OS/2 and Windows 3.x.)  There was a lot of old code to clean up and/or remove, and we also have to keep those legacy widgets operational. 

A few additional challenges included our use of automated test tools which didn’t support 64 bit platforms, which also forced our journey to replace them and use Ranorex for our testing. (I’ve covered this in the forums and talked at a few user groups on this topic.)  

We delivered a Windows 64 bit client with Uniface 9.6 in December 2012. We’ve had some good feedback, I recall talking to a customer in the UK, and their comment was that it just seems more ‘fluid’. I talked about this with one of the architects, and the view is that this is probably as a result of the refactoring, possible the additional memory capabilities, but it’s great to get positive feedback. 

It’s available for deployment rather than development, as we have a few external pieces of functionality in the developer, for example the DSP Editor which are not available as a 64 bit product. 

The HTML control we delivered in Uniface 9.6 is also currently restricted to 32 bit. But this will change, it’s based on Chromium (sometimes know as CEF) from Google, and the sources were (finally) updated to 64 bit and we have been working on getting that into Uniface 9.7, and will be part of the Uniface 9.7.02 update which we are finalising. That was a challenge to get working, changes to threading models and API’s meant some rework and lots of testing, but it’s pretty well code complete. 

The Uniface 10 IDE uses that same HTML control extensively, so the move to CEF3, now opens the way to deliver a 64 bit developer. There will be a significant Uniface 10 release in September, but this is something for another posting next month.    

 

Uniface Modernization: Modern buttons are flat

New button properties are welcome

During the modernization of IDF 9.7 it became clear that 3D buttons could not be used anymore. Windows has gone flat and all the office applications as well. So we needed to address this with some simple properties on the command button widget. The defaults stay untouched even though the new properties make the button more appealing. So we don’t break the look and feel of the existing applications but open the possibilities to a modern user interface.

Properties explained

These new properties make the difference and allow the UNIFACE developer to change the looks of the entire application in a wink. You need to set the button representation to “UNIFACE” is you want to make use of the new properties.

Uniface

With the new properties we were able to completely mimic the Windows 8 tiles as well as the common flat buttons.

Some examples

In the following example the “Transparent” property is set while the button is placed on a form with a very colorful image. Not very user friendly, since it looks like a label, but it shows the possibilities.

A button with transparency set to TRUE.

Uniface

The following table shows a button with an image which is styled in different ways:

Uniface

New property value

Unifac

During the modernization of IDF we missed the option to create big buttons with an image big enough to fill up the button. The “imgsize” property has a new value to accommodate the workspace buttons in IDF.

Uniface

Example the UNIFACE Journey planner

If we start making changes to GUI widgets or the GUI driver, we always look to other applications and try to make the user interface in UNIFACE. For the buttons I took the Android application made by the Dutch national railway company NS. With the new button properties we could mimic the user interface completely. Following picture shows the UNIFACE Journey planner which uses flat buttons.

Uniface

To make designing the application more easy, I created logical widgets with the necessary properties, so I was able to paint the Journey planner very quickly. Creating the logical widgets was some work but after this you can develop an application following a certain theme. You can paste the following buttons into you usys.ini to get the looks as shown in the sample.

pltimebutton=ucmdbutton(representation=uniface;transparency=true;forecolor=white;frametype=bottom;framecolor=#9bd1f3;framewidth=2;font=SansLarge)

plheadbutton=ucmdbutton(representation=uniface;backcolor=#ffcc33;transparency=false;forecolor=black;frametype=bottom;framecolor
=#dcab1e;framewidth=5;font=SansHuge)

plplanbutton=ucmdbutton(representation=uniface;backcolor=#3395e4;transparency=false;forecolor=white;frametype=bottom;framecolor
=#1762cc;framewidth=5;font=SansHuge)

pldepariv=ucmdbutton(representation=uniface;backcolor=#1b8ee1;backcolorhover=#349ae5;backcolorfocus=#349ae5;transparency=false;
forecolor=white;frametype=bottom;framecolor=#9bd1f3;framewidth=4;font=SansHuge)

pldfromto=ucmdbutton(representation=uniface;backcolor=white;backcolorhover=#349ae5;backcolorfocus=#349ae5;transparency=false;
forecolor=#272775;frametype=off;framecolor=;framewidth=1;font=SansHuge;imgsize=img_xlarge;halign=left)

I hope this helps you in creating modern looking UNIFACE applications and modernizing existing applications.

When thinking Desktop “first” still matters

By Clive Howard, Principal AnalystCreative Intellect Consulting

A few months back, I registered for Mobile World Congress 2015 in Barcelona. As an Analyst, there is a different registration process to the one used for regular attendees. This is so the organisers can validate that someone is a legitimate industry analyst. As well as entering a significant amount of personal data, additional information such as links to published work and document uploads are also required. Crucially, there are a number of screens to complete the registration and accreditation process. But more to the point, many different types of data must be entered – from single and multiple line text entry to file uploads. Some data (such as hyperlinks) requires cut and pasting.

I’m sure that I could have done this using a mobile phone but it would have taken a long time, been awkward and irritating and probably highly prone to mistakes. In short, I would never have considered doing something like this using my phone. Could I have used a tablet? Without a keyboard and mouse it would have been problematic, especially if the screen is small. Using a tablet only Operating System might also have had its problems in places: such as uploading documents from centrally managed systems. Actually I did use a tablet but one connected to a 20inch monitor, keyboard and mouse and running Windows. In that traditional desktop looking environment the process was relatively quick and painless.

Rumours of the desktop’s demise are greatly exaggerated

It is not just complex data entry scenarios such as this that challenge mobile devices. Increasingly I see people attach keyboards to their tablets and even phones. Once one moves beyond writing a Tweet or one line email many mobile devices start to become a pain to use. The reality of our lives, especially at work, is that we often have to enter data into complex processes. Mobile can be an excellent complement, but not a replacement. This is why we see so many mobile business apps providing only a tiny subset of functionality found in the desktop alternative; or they are apps that extend desktop application capabilities rather than replicate or replace them.

One vendor known for their mobile first mantra recently showed off a preview version for one of its best known applications. This upgrade has been redesigned from the ground up. When I asked if it worked on mobile the answer was no, they added (quite rightly) no one is going to use this application on a mobile device. These situations made me think about how over the last couple of years we have heard relentlessly about designing “mobile first”. As developers we should build for mobile and then expand out to the desktop. The clear implication has been that the desktop’s days are over.

This is very far from the truth. Not only will people continue to support the vast number of legacy desktop applications but will definitely be building new ones. Essentially, there will continue to be applications that are inherently “desktop first”. This statement should not be taken to mean that desktop application development remains business as usual. A new desktop application may still spawn mobile apps and need to support multiple operating systems and form factors. It may even need to engage in the Internet of Things.

The days of building just for the desktop safe in the knowledge that all users will be running the same PC environment (down to the keyboard style and monitor size) are gone in many if not the majority of cases. Remember that a desktop application may still be a browser based application, but one that works best on a desktop. And with the growth of devices such as hybrid laptop/tablet combinations, a desktop application could still have to work on a smaller screen that has touch capabilities.

It’s the desktop, but not as we know it

This means that architects, developers and designers need to modernise. Architects will need to design modern Service Orientated Architectures (SOA) that both expose and consume APIs (Application Programming Interfaces). SOA has been around for some time but has become more complex in recent years. For many years it meant creating a layer of SOAP (Simple Object Access Protocol) Web Services that your in-house development teams would consume. Now it is likely to mean RESTful services utilising JSON (JavaScript Object Notation) formatted data and potentially being consumed by developers outside of your organisation. API management, security, discovery, introspection and versioning will all be critical considerations.

Developers will equally need to become familiar with working against web services APIs instead of the more traditional approach where application code talked directly to a database. They will also need to be able to create APIs for others to consume. Pulling applications together from a disparate collection of micro services (some hosted in the cloud) will become de rigueur. If they do not have skills that span different development platforms then they will at least need to have an appreciation for them. One of the problems with mobile development inside enterprise has been developers building SOAP Web Services without knowing how difficult these have been to consume from iOS apps. Different developers communities will need to engage with one another far more than they have done in the past.

Those who work with the data layer will not be spared change. Big Data will affect the way in which some data is stored, managed and queried, while NoSQL data stores will become more commonplace. The burden placed on data stores by major increases in the levels of access caused by having more requests coming from more places will require highly optimised data access operations. The difference between data that is accessed a lot for read-only purposes and data which needs to be changed will be highly significant. We are seeing this with banking apps where certain data such as a customer’s balance will be handled differently compared to data involved in transactions. Data caching, perhaps in the cloud, is a popular mechanism for handling the read-only data.

Continuation of the Testing challenge

Testing will need to take into account the new architecture, design paradigms and potential end user scenarios. Test methodologies and tools will need to adapt and change to do this. The application stack is becoming increasingly complex. A time delay experienced within the application UI may be the result of a micro service deep in the system’s backend. Testing therefore needs to cover the whole stack – a long time challenge for many tools out there on the market – and the architects and developers will need to make sure that failures in third party services are managed gracefully. One major vendor had a significant outage of a new Cloud product within the first few days of launch due to a dependency on a third party service and they had not accounted for failure.

Tab widget extensions for 9.6.04

The new tab widget also known as the TabEx has got some new properties. This small article shows how they work and what it looks like. The new properties are introduced to allow developers to mimic a kind of browser look and feel whereby tabs can be closed or opened based on events in the programming language. For this purpose we introduced a tab button which lives on top of the selected tab. Some developer talk about a close button but this depends on the programming code in the extended trigger of the Tab.

The UNIFACE lab has chosen to follow the MS Internet explorer look and feel. This means that the button is only shown on the active tab.  There is no standard definition in Windows for showing the button on a tab se we had to choose.

The new properties should be defined in the more properties form.

Property TabButton
A button on top of the active tab is shown when this property is set to true.

Property name: “TabButton”

Values: TRUE | FALSE (default)

The active tab shows a small cross when this property is set. By default the button is a cross with the foreground color of the tab. So it follows the label color. When hovered it shows a small button with a red cross.

Tab Widget Image 1

The lab added some extra properties to allow the 4GL developer to design its own tab button.  By default the tab works and looks nice however a developer who wants to be in control can use the following new properties to design a distinct look.

Property TabButtonImg
Defines the image on top of a tab button.

Property name: TabButtonImg

Value:

When a valid image is defined the button will show this instead of default cross. Following image shows the tab widget with the tabbuttonimg=@ball.png and tabbutton=true

Tab Widget Image 2

Property TabButtonImgHover
Defines the image on top of a tab button when the button is hovered by the mouse pointer.

Property name: TabButtonImgHover

Value:

Defines the image which is shown when the tab button is hovered.

Extended trigger onTabButton

When the button is clicked the tab widget fires the onTabButton extended trigger. There are no parameters. The developer can use the current field value to act on the active tab.

; -- start triggers for tab widget 
trigger onTabButton

end ; trigger onTabButton

Overview of the sample
Following picture shows an overview of the used tabs in this document and the opened form.

Tab Widget Image 3