Category Archives: Blog

GDG DevFest, Amsterdam Edition

On October 10th 2015, Google had organized the biggest Google Tech related event in The Netherlands, located in Science park, the heart of science in Amsterdam. Uniface as one of the sponsors was invited to join the event. As the representing group of Uniface, the mobile development team attended the Google DevFest, an event carefully crafted for the developers by the Dutch GDG communities.

Uniface Mobile Dev Team
Uniface Mobile Dev Team

GDG DevFests are large, community-run events that can offer speaker sessions across multiple product areas, all-day hack-a-thons, code labs, and more. Google Developer Groups (GDGs) are for developers who are interested in Google’s developer technology; everything from the AndroidChromeDrive, and Google Cloud platforms.

A GDG can take many forms — from just a few people getting together to large gatherings with demos and tech talks, to events like code sprints and hackathons. However, at the core, GDGs are focused on developers and technical content, and the core audience are mainly developers.

Each GDG DevFest is inspired by and uniquely tailored to the needs of the developer community that hosts it. DevFest 2015 also had a series of speaker sessions and workshops for web, mobile and cloud solutions, glimpses of the sessions were about –

        Material coordination –a new design support library by Google, which helps bring a lot of material design components including a navigation drawer view, floating labels, floating action buttons, snack bars, and a new framework to tie motion and scroll events. The library is supported for Android version 2.1 and higher.

        Firebase : codeless backend for Android – Firebase is a cloud services provider and backend as a service . Firebase’s primary product is a realtime database which provides an API that allows developers to store and sync data across multiple clients.

        Google Cloud Endpoints and AngularJS -Google Cloud Endpoints consists of tools, libraries and capabilities that allow you to generate APIs and client libraries from an App Engine application, referred to as an API backend, to simplify client access to data from other applications. Endpoints makes it easier to create a web backend for web clients and mobile clients such as Android or Apple’s iOS.

        UI Router – It’s a routing framework that allows us to organize the interface by a state machine, rather than a simple URL route.

        Polymer – library makes it easier than ever to make fast, beautiful, and interoperable web components.

 Last but not least, and most importantly, being a sponsor, we also had an opportunity to provide a short pitch and say something about Uniface to the developer groups. The pitch was very nicely outlined and well presented by Thomas Stolwijk.

Uniface Sponsor Pitch

Yow Connected Mobile and IoT Conference Report

The YOW Connected conference was held in Melbourne on 17th to 18th September . It was a developer’s conference based on Mobile and IoT topics. Since Uniface is adding Mobile devices as a deployment option in 9.7, I thought I should find out what problems existing and aspiring mobile application developers are experiencing, and how they are solving them.

Keynote presentations should give a buzz to the audience, and this conference had one on the magic of mobile devices, with plenty of Harry Potter analogies. Another keynote was on IoT wearables, which showed many examples of how technology failed to make good partners with fashion.

The technical presentations for smart phones generally fell into iOS and Android camps, i.e. native app development was very important to most attendees. There was a strong belief in maximising the user experience over portability of business applications, and this meant gaining the most out of native platform features. Indeed, whilst people figure what to do with Apple watches and Galaxy gear, I can imagine that they need to use native platform features.

Given that there was strong commitment to native mobile development, it came as little surprise that using JavaScript to program the user experience was seen as second rate technology. However, when an industry heavyweight like Facebook come along with a new JavaScript library, people start to overlook their general JavaScript prejudice. So this is where I first learnt of the React library . React differentiates itself from other JS libraries with the use of a virtual DOM. Your JS programming updates the virtual DOM, and then these updates are combined to update the real browser DOM. This turns out to perform much better than scanning and updating the browser DOM for each individual update.

But Wait, Facebook has done more … they have also introduced React Native . So, instead of using JS to manipulate HTML for rendering inside a UIWebView container, you use JS to manipulate view structures inside native components. There is still a virtual DOM equivalent, and then the actual native component objects are updated by this library. Facebook has initially developed this with iOS native component models, and thus you are limited to developing on an Apple platform, but as recently as one month ago, you could also target the Android native platform.

This is where the development philosophy gets interesting. In the Uniface world we are used to “write once, deploy anywhere”, and there is a suggestion that React Native might support something similar, but in fact their mantra is “learn once, write anywhere”. Even though React Native has adopted standardized layout mechanisms from CSS3 using flexboxes, they really encourage you to choose native component types that exploit the best of what the native platform offers, i.e. avoiding a lowest common denominator user experience, at the expense of full portability and productivity. My personal view is that you would only choose React Native when user experience is clearly a very high priority, and use more proven platform independent tools, like Cordova, as often as possible. Perhaps this would change as React Native evolves, after all, it is still at release 0.11.0.

There were numerous IoT technical presentations, and I include Virtual Reality and Augmented Reality apps in this category. The presentations covered things like how to make a LED flash on a microprocessor (see for examples) using calls to the Particle Cloud written in JavaScript (groans from the smart device developers, but IoT developers don’t mind). Another presentation covered VR from high-end Oculus products to DIY Google Cardboard, once more, using JavaScript to program the API calls. This article shows the basic JavaScript libraries that you can practice with .

I did initially struggle to see why these IoT technologies would be important to business applications, and thus where Uniface might be able to help, but eventually the spirit of adventure in programming comes out of you (OK, call it inner geekiness) and you want to play with it anyway. Besides, we know that other IT technologies have evolved from past experimentation, and so I wasn’t surprised to find myself ordering a Google Cardboard device on the weekend . Soon enough, I may be using the Uniface JavaScript API, to send data to 3D rendering JavaScript libraries, for display in my Google Cardboard device.

Polymer: Getting a closer look

Last week, a few of us from the mobile scrum team attended the first ever Polymer summit organized by Google. Amsterdam was chosen as the perfect location for the international conference, since it is has an “incredibly strong developer community in Europe”. 


The event is fully devoted to Polymer: a new web library fully developed by Google and widely supported by the WebKit-based browsers (i.e. Chrome, Opera) and Microsoft Edge. With Polymer, users can create composable and modularized web applications that make use of a new web standard, called web components. Web Components are currently being produced by Google engineers as a W3C standard. They are built on four basic foundations: (1) native client-side templating; (2) shadow DOM scoping and composition; (3) custom elements to create your own HTML DOM elements; and (4) HTML imports to load web components.


Polymer web components architecture is already used by many companies and users. One user was quoted at the event: “We no longer build applications. We have and are enriching, a module market sourced from industry and the ING global community. Modules are assembled into applications as the business requires,” ING – one of the first users of web components – quoted in one of the presentations.


I also speak on behalf of my colleagues who also attended, when I say it was an interesting and well organized event full of useful information and examples of what is coming our way regarding web and mobile development. In case you are interested, the whole event was recorded and can be viewed on their YouTube page.


The Future of Programming May Not Involve Coding (Part 2)

By Bola Rotibi, Research Director, Creative Intellect Consulting

Part 2 in a 2 part series: Read Part 1 Here

Developers: I’m better than you and I need my code

The most significant barrier to adoption has perhaps been the developer. Within the development community there can be a snobbery about writing code. A hierarchy of developers often exists in which those who are closest to the metal are better developers. So a C++ developer is far superior to a JavaScript developer. Therefore a developer who writes no code at all is perhaps not even a developer. Aside from this unofficial cast system there has always been a desire amongst developers to write code. Becoming a developer to not write code is like choosing to be a racing driver and not driving a car.

Finally there is the niggling suspicion within the minds of developers for whom the low-code approach might be appealing is that a requirement will come along that cannot be fulfilled. If you are writing the code then this is highly unlikely to happen, any requirement can be met. This has been true in some cases such as the early days of .NET when developers discovered that something which was possible pre-.NET was not possible within the framework. Anyone who remembers the challenge of needing more than one form in an ASP.NET page will know what I mean.

These issues, in many cases more emotional than real, have managed to drown out the many sensible reasons for adopting low-code development tools. Had software development been any other part of a business it probably would have shifted to this approach many years ago as the business case for it is overwhelming. But, within IT the old guard of developers has stemmed the tide and most development today, especially within the enterprise, still means many, many lines of code being written, tested, deployed and maintained.

The rise of a new breed of developer

Just as technology has changed so has the developer. The 2015 Stack Overflow survey found that the average developer does not have a computer science degree (almost half are self-taught) and has only been coding for 2-5 years. They are a product of the micro-service, API, framework, born-on-the-web world. These are not the Fortran or Mainframe or even Visual Basic guys of old. The most popular language in the survey was JavaScript with C#, PHP and Python beating out C++ and C. The main driver for this generation is speed and technology choices largely flow from that.

This is highlighted by many of the new coding bootcamps that have sprung up. These are very short training courses in which people with usually zero coding experience learn how to develop in a few weeks. In order to operate in these timescales they choose technologies such as Ruby on Rails or Node.js simply because the more traditional technologies take longer to teach.

Then there are the micro-service based applications often built on Platform as a Service such as Heroku or Cloud Foundry. These are also popular with the bootcamps because even quite complex applications can just be a few lines of code that knit together a few services. In this world some developers do not even see themselves as developers but merely curators of services. For them the issue of whether they are a “real” developer is irrelevant. Their aim is to create an application as quickly as possible. They would rather invest time in making it a great user experience.

The applications that this generation have been creating are those that have disrupted many traditional industries or notably impacted society in recent years: Facebook, Netflix, Twitter, Dropbox and so on. The result is that now traditional enterprises and SME’s are having to respond in kind. Innovation, agility and time to value are the buzz words in today’s business with respect to IT. Developers are having to change and that includes languages, technologies and tools. We see this reflected in the products that their traditional vendors are producing such as Microsoft and IBM’s PaaS platforms.

The future demands change

Then there is the challenge of mobile and Internet of Things. Whereas for a long time developers just had to worry about building a desktop application (often for a very specific OS) they now have to worry about the web, phones, tablets and potentially many other types of device. Codebases need to be able to serve many different clients. If every line of code is going to be written by hand then building an application that works on desktop, multiple phones and tablets and beyond is going to mean a lot of lines of code across numerous languages, technologies and tools. All of which must be tested, maintained and evolved.

This will push developers, development teams and budgets to their limits. And with speed being an overriding factor the old ways simply won’t work. Coding and creation of applications is opening up to a wider group. The advent of the citizen developer: regular folks building mobile apps in their spare time; or people at work building apps to aid their productivity; the iOS Gold Rush saw many designers begin writing Objective-C in order to push out iPhone apps. Everyone is getting in on the act and they are not playing by the old rules or caring about the developer hierarchy.

This evolution began with the web when many people (such as myself) who had no development background or training became developers at the forefront of technology. That change has accelerated and continues to do so. This is being enabled by and driving the growth in low-code tools and technologies. As I said in the beginning, it is ironic that as governments push for the better training of software coding within the younger generation, the need to actually write code is rapidly diminishing.

Many software application developers should look willingly to embrace this evolution not least because of the act of development is to build to deliver value. Code is a construction asset like bricks are in the building trade. In the building trade, ultimate value comes from the finished product and the way it is architected and the function it delivers. Of course the quality of the bricks also helps to cement that value but at the end of the day it is a commodity component. The analogy works for the business of programming with many tools now are able to auto generate the building block code to a consistent standard and quality: i.e. a commoditised function.  Full and lasting value must surely then lie not in the construction of code but in the application that is devised and the way it is architected or modelled to deliver the function required. The resulting experience of engagement for the user is intrinsically tied to the value perceived and this is rooted more in the application model and architecture than the underlying code.

The Future of Programming May Not Involve Coding

By Bola Rotibi, Research Director, Creative Intellect Consulting

Part 1 in a 2 part series

It is perhaps ironic that we live in a time when governments and many others are calling for young people to be better educated with regards to writing code, yet at the same time the software development industry is requiring developers to write less code. Microsoft’s Azure App Service or’s Lightning are recent examples of new tools that aim to eliminate code writing from the process of developing an application (desktop or mobile).

The principle of this approach is not new and tools such as Uniface have long aimed to increase developer productivity and application quality by reducing the number of lines of code that need to be written. The terminology, approach and experiences have evolved and differ but the aim has remained the same.

Even in the world of code writing the popularity and growth in frameworks from .NET to JQuery have sought to reduce the amount of code written. As has tooling like Integrated Development Environments such as Visual Studio and Eclipse. For example, tools provide drag and drop controls with properties windows that mean a developer can add a control to a screen or web page without writing the underlying code. We saw this in Visual Studio, Adobe FlexBuilder and others. Perhaps the question is why it has taken so long for low-code development environments to see wider adoption?

Making the complex simple is a challenge for tooling

Part of the reason may be technology. It is inherently difficult to make the complex process of writing applications into something that can be done in a way that involves no or little code. Modern applications are incredibly complex, often using multi-tier architectures and integrated with other applications. Creating a visual development experience that can work with these complexities and provide the myriad possibilities that the modern developer requires is inherently challenging. Changes in technology have made it easier in recent years.

The wide spread adoption of the API economy and the proliferation of micro-services has changed application architectures and exposed capabilities in more simplistic and easy to consume ways. Let’s take a rather modern concept such as mobile Push notifications. Each mobile platform (iOS, Android and Windows Phone) implements this capability differently and it involves a degree of complexity and quite a bit of code to manually create. Instead there are a number of services exposed as APIs (Web Services) that abstract all of this complexity and allow developers access to the capability via a few simple calls.

By basing these APIs on common programming concepts such as RESTful Web Services and JSON formatted data it allows development tools to more easily create a further level of abstraction that means developers do not need to write the few lines of code required to work with them. SOAP made consuming any service from within a development tool even easier as the WSDL allowed tooling to auto introspect and understand any service. REST is not as simple but is now widely accepted as the way to build modern services. Modern tools are finding ways to make working with RESTful services very simple.

Part 2 (coming soon):  Developers: I’m better than you and I need my code