Thoughts about "The future of programming"

Bret Victor, in this excellent video, told us to think about the way we are programming today.

I'm really glad to have this chance to muse about this because in the ongoing “mobile revolution” a lot of new tools have appeared, all of them following the same programming paradigm: basically procedural, focusing on HOW we do things instead of on WHAT we want to achieve.

Since the beginning GeneXus (a programming language created by Nicolás Jodal and Breogán Gonda) has had a different paradigm. Breogán and Nicolas were probably influenced by different languages that appeared at the time. As Bret said, there was more variety because the “correct way to do things” was not yet established.

The influence of “goal-oriented” languages ​​is evident in GeneXus. It was always clear that WHAT is quite more important, in the long term, that HOW. The GeneXus model focuses on WHAT from the beginning, and always emphasized “declaring” over “programming”.

Breogan always say that GeneXus is a Knowledge-based development platform.

Knowledge-based development has two premises that other languages don’t have:

• Capture WHAT information the user wants (user views)
• Infer information based on these user views.

In GeneXus we have remained steadfast on not incorporating programming practices “oriented on HOW”, and evolving on a different path instead. From its point of view, the 3rd generation languages of today (with their relatively low level of abstraction) are not very different from the binary code of yesteryear.

Some very specific things you can do in those languages may not be achievable with GeneXus; however the things you do in GeneXus will be useful over time... generating COBOL code one day, and Objective-C code decades later.

GeneXus has long resisted object-oriented trends, prioritizing declarative techniques based on data and rules instead. Things like threading, exceptions, locks, &c do not belong in GeneXus, because we believe those are part of “HOW-space”.

I’m a GeneXus development team member and I don’t think GeneXus is a perfect language. However, I do believe that most of its principles are sound, and lead to a different programming paradigm. In fact, I’m expecting (and hoping) GeneXus will be an inspiration to create software in a different way in the future.

Again, I loved this call to think about the world of programming. I did it ;)

8 reasons why Model Driven Development is great

This article was inspired by some conference talk with some prospects that basically are worried about the dangers around Model Driven Development, which really started me thinking.
I believe there are many articles written about the dangers of Model Driven Development (MDD), many of them have valid points and some others are more of an historical and repeated nature, not taking in consideration the current developments in this area.

You'll hardly find articles saying "8 reasons because writing code manually is very dangerous", surely there are more than 8 and I was almost tempted to write some of them down. Model Driven Development has many dangers many of which come mostly from not understanding its real value. Thus, while recognizing that a number of risks written in many articles are real, I would like to enumerate some of the good things about MDD.

1. MDD actually introduces a lot of flexibility

Indeed, MDD introduces a lot of flexibility for companies and businesses. Flexibility means responsiveness to change, adaptability, both in the technical side and in the business side. If  you choose a language and hand write a solution, you may have a type of flexibility (related to power in the chosen language? ) in the short term but you are adding a lot of rigidity in the long term. So you have to take into consideration the time you want your investment in development to last, before defining which way to go.   

If you chose Silverlight, Flash, Visual Basic, Fox in the past and now you need to
create HTML5 or iOS applications: How flexible are you? How many
concepts can you reuse from your existing code? If any.

When coding by hand all you have is code, which you may but -most likely- may not reuse. In a Model Driven Development you have a model and you can reuse concepts. People creating an Android app from its FoxPro Win model are the ones who have the most flexibility in the long term.

So, Is MDD flexible? It depends. If you are a businessman or a company planning to stay in the game for the long run, then yes, Model Driven Development it’s extremely flexible.

2. Modern Models have great extensibility

Today there are models with a great extensibility at different levels and are designed to interact with hand-written code at all levels. What commonly happens is that much of this code in the medium term (if it is really very common) is incorporated into the model at some point. There are no perfect models, but many of them are useful and with great extensibility. The trick is to find a way that has the productivity advantage of MDD and the possibility of extending it when modeling is not enough.

3. Programmers can focus on what instead of how

It is great to allow people -who know absolutely nothing about Objective-C- to create business applications for iPhone and iPad that conform to the Apple guidelines, based on a model. A model that can also be used to generate apps in Android, BlackBerry or Windows 8 if required, with marginal effort. It's fantastic!

4. There are MDD platforms that support version control & continuous integration

Contrary to traditional complains against Model Driven Development, it really can support version control, collaboration, and even more. For example we have been working many years to achieve this status, and it’s fantastic to have a full version control system integrated with continuous integration tools.

5. There are great tools embracing MDD

Almost any industry uses software to increase productivity, and improve efficiency and efficacy in all operational levels, it’s an obvious approach of using software.

But the software industry is the only industry that refuses to create software using software to achieve the same goals: increase productivity, improve efficiency and efficacy. Luckily there are many companies working in a paradigm shift.

The only way to do the paradigm shift is by creating more amazing tools that create software using software.

6. The requirements team needs to focus only on the business-side

The requirements team can focus on the business side, without having to see the technical side.
It is often true that a requirement can not be met for example in a particular way due to model limitations, but this is also true in a hand coding solution!
If I request for a form with a scroll inside another scroll in an Android solution, this hardly can be accomplished and that's not because of Model Driven Development.

Because, as I said before, a big advantage of the current models is its interoperability with manually written code the worst-case scenario is to have to write something by hand, which does not invalidate most of the cases, in which the teams only need to focus in the business-side of the equation and not on how to program a particular solution.

7. Sell the solution, not the MDD paradigm

MDD is a way to create a solution efficiently, you don't need to explain MDD to the final customer, he will reap the benefits of it.
Anyway you could say that  your solution is going to be extremely flexible in the long term and that you are saving a lot of business knowledge (represented in models) for further use.

8. Technology evolution is not a worry anymore

If you have a business, you probably want to use the best technology at any particular time, but you will probably lose your focus if you need to worry about any new technology details.

Using a Model Driven Development approach you just need to focus in the model of your business, not worrying about the continuous, trending changes of the underlying technology.



So, that was my initial take on the subject, but it’s a list of reasons that can be improved.
Here Johan den Haan has more reasons to start using Model Driven Development.

Do The Harlem Shake & GeneXus Evolution 2 Upg 3

A new upgrade of GeneXus Evolution 2 (Upgrade 3) is coming.

As always this upgrade brings improvements on several areas such as usability, performance and robustness.

However in this upgrade for mobile generators we have been adding new features to create sophisticated mobile applications.

I like having fun trying out the new features. And the best way to do it is by creating some small application.

This time, because I could not get my teammates do a Harlem Shake video, I decided to create at least one Harlem Shake application ;). Basically a simple one with a catalog of Harlem Shakes, a ranking, you can find some particular one or shake your phone for a random new Shake, etc

A  feature included in this release is the ability to easily create an application with the Navigation Side pattern. This pattern is used in applications like Facebook, Gmail, YouTube, Zite, etc.. (For more about the pattern, see the Android UI Patterns blog entry).

Thus, the first thing I decided is to add this pattern to my application. This is done in GeneXus by simply setting the property to Navigation Style = Side. In this case I used this navigation style for iOS application and left a Tabbed navigation for Android.



I remember I wrote this article 2 years ago saying that Model Driven Development is slower in the initial steps but at some point you start having a more sophisticated model that covers a high percentage of applications requirements faster than coding by hand.

In this Upgrade 3 we started talking about things like transformations, effects for entering and exiting and now you can do sophisticated things using similar concepts to the ones you use when you for example change the border of a table or the color of a button.

Effects, transformations, animations, gestures are elements that we must use with care in order to create an application that is easy to use.

In U3 effects are added in the model without necessarily interfering with the programming model.
For example, if I have a call to a Panel A, the enter and exit effect of the panel are specified declaratively in a Theme.


In my application I added the Harlem Shake Curl effect to show a panel with a Harlem Shake.
So you shake your phone and the application shows a new Harlem Shake panel using a Curl Up effect and the panel exits using a Curl Down effect.



Not only UI elements were incorporated into the Upgrade 3. One extremely interesting feature that was added was Google Analytics, so you can use it in your applications to know what is happening with your application after release.
Adding this feature to your app is really easy just setting a property with an Id given by Google Analytics.
As you can see Analytics is telling me my app is not trending yet ;).



By the way I did this application in 4 days for Android and iOS and my friends from i+Dev uploaded it to the stores, even though there is someone in their team who doesn’t like my great background image ;)


You can download it now from Google Play or from appstore for iPhone or IPad

Creating an External Object for the iOS generator

As Gaston explained in a previous post, one of the mechanisms for extending the model, is the use of External Objects. By creating an External Object you can provide functionality that is not provided by default by GeneXus.

The problem to be solved

Recently I needed for a project to interact with the actions of a panel, in a way that is not the default. There were basically to possibilities: to hack the solution into the GeneXus libraries, or to create an External Object to provide the functionality. We decided to use the later.

What I needed, was to be able to display the low-priority actions in a panel where the navigation bar is hidden.

Some background here. When you create a Smart Device Panel in GeneXus, you can define actions, which have a priority: High, Normal or Low. The low-priority actions are displayed in an action sheet, that is presented from a button in the navigation bar.

The problem was that the navigation bar was hidden, so the user didn't even see the button to show the action sheet.

Creating a new External Object

The implementation of an External Object consists on three parts:

1. The implementation of the functionality, in Xcode
2. The GeneXus object that defines the External Object's API
3. The mapper, that translates the name of the GeneXus object to the Objective-C class.

Defining the methods in GeneXus

Lets start by creating the definition. To do that, in your GeneXus KB, create a new object of type "External Object" and give it a name. In this case, the object is called EOActions.

After that, you need to define the methods of the External Object. In this case, it has only one method named "ShowLowPriorityActions" that doesn't receive any parameters and has no return value.

Important: every method must be declared as "static" in the method properties.

Implementing the External Object

The implementation is of course in Xcode, since we need to create a library.

So, open Xcode and create a new library project.

Add a reference to the GXFlexibleClient.framework.

The main class implementing the External Object must subclass GXActionExternalObjectHandler (you'll need to add an '#import <GXFlexibleClient/GXFlexibleClient.h>' ), and it must provide two methods:

• + (BOOL)canHandleAction:(id <GXActionExternalObjectDescriptor>)actionDesc
• - (void)actionExecuteWithContext:(id<GXActionHandlerContext>)context delegate:(id<GXActionHandlerDelegate>)delegate

In the second one, don't forget to call [super actionExecuteWithContext:context delegate:delegate];

After that, you need to provide your custom implementation, and once you are done, you must call either one of:

• [self onFinishedExecutingWithSuccess];
• [self onFinishedExecutingWithError:error];

depending on the result, so the actions that are after the External Object call, can get executed.

After you compile the library, you need to copy it to the GeneXus KB. It must be placed in

• <model_dir>\mobile\iOS\<main_obj_name>\iOS\Genexus\UserControls

so it gets copied when compiling and liked against.

Mapping the External Object name to the implementation class

The last piece, is the source file to provide the mapping between the GeneXus' object name and the class implementing it.

The class must be named GXCustomExternalObjectsMapper, and has only one method:

• - (NSString *)externalObjectClassNameForObjectName:(NSString *)objName;

that receives the name of the object and returns the name of the class.

This sources (GXCustomExternalObjectsMapper.h and GXCustomExternalObjectsMapper.m) should be placed in

• <model_dir>\mobile\iOS\<main_obj_name>\iOS\Genexus\Classes

Example implementation

I know this may be a little intimidating at first, but once you've done an External Object, you'll see it is not too difficult. It involves only this three steps as described above.

I've uploaded the XCode project, the GeneXus External Object export (as a .xpz file) and the mapper class to a GitHub repository, so you can play with the code.

Designing on the mobile era

We are once again facing a design challenge: creating applications for new platforms we are not fully familiar with yet. This is the same situation we experienced when we jumped from a text-based UI to a Windows UI, or from Windows to the Web. The new platform is, in this case, “smart devices” (phones and tablets).

From Unconsciously incompetent to Consciously incompetent

The main point we need to realize is that we need to move outside our comfort zone and accept we are, most likely, “unconsciously incompetent” in terms of Mobile design. Even if you are a Web design expert! But don’t feel bad about it, because almost everybody is.

Things we must know to move to a “consciously incompetent” state:

• Web Design is not Smart Devices Design
• In most cases “One Design Doesn't Fit All” (form factors, sizes, densities, orientations, modes, etc). You could try adaptive layouts but that won’t be enough in many cases.
• Platform Guidelines matter
• Win8 != Android != iOS
• UX Patterns are key on mobile design

From Consciously incompetent to Consciously competent

I'll write some essential point to move to a consciously competent state.

The basics:

• Always take into account User Centric design.
• Read Human Interface Design Principles
• Read Designing UX apps
• Read Android Design

Some more specific ones, but basics anyway:

• Data Entry

Users are not too keen on custom data entry controls, so try to use the standard ones. By the way, avoid data entry if you can ;)

• The main input today is touch. Controls on the screen should not only be touchable, but also have minimum dimensions for making it comfortable. See Touch Interaction Guidelines
• When designing layouts for iOs (it almost applies to Android too) consider using the 4px pattern
• Do not put many tabs on screen, remember that more is less.
• For grids, consider using the “empty dataset pattern”.
• Multiple layouts should be considered, normally one by size (small, medium, big).
• Avoid using the virtual keyboard whenever possible.
• The color scheme must be the same throughout the application.
• Windows 8 apps must use a “chrome-less” design, so no action buttons on layouts.
• For Android and iOS, consider using the application bar whenever possible; do not create your own way to handle actions.
• Read about patterns that already work in many applications:
• http://mobile-patterns.com
• http://pttrns.com/
• http://www.lovelyui.com/
• http://www.androiduipatterns.com/

• http://landingpad.org/page/3
• http://www.iospirations.com

And the last and most important thing: create your first application in each platform, it is the best way to become competent.

From Consciously competent to Unconsciously competent

We could reach this status as we do in any other activity: by exercising a lot! We simply need to create a lot of applications until the best practices become second nature to us.

By the way, if you find some useful sources for learning more about design, please drop me an e-mail or just comment on this post.

@gmilano

GeneXus vs PhoneGap vs Titanium

In http://developer.appcelerator.com/blog/2012/05/comparing-titanium-and-phonegap.html there is an excellent comparison between two good products used to develop mobile applications: PhoneGap and Titanium.
Since we released GeneXus X Evolution 2 with the ability to generate Smart Device apps, both developers and companies are asking us how we stack up when compared with these two. There is much to say about this topic, so in this article I will cover just the most important aspects of the comparison.

Let’s start with the basics:

What is each product trying to achieve? 

• PhoneGap: Development of HTML-based web applications, while installing them as if they were native applications.
• Titanium: A cross-platform JavaScript runtime and API for mobile development.
• GeneXus: Model Driven Development to create cross-platform Smart Devices applications.

GeneXus is a lot more that a “mobile application generator”. To start with, an application created by GeneXus is a “true” native code application: Objective-C for iOS, and Java for Android and BlackBerry.

In addition, mobile applications need more than the UI. In general they are “connected” applications, and therefore need a server back-end. For this reason GeneXus also creates the database and service layers (derived from the same model) that expose the business logic to the mobile application. The database can be Oracle, SQLServer, MySQL, Informix or DB2, and the business logic may be generated in .NET, Ruby or Java.

This means that, for GeneXus, the concept of application is very different than for the other products. “Application”, in GeneXus, involves the ENTIRE application, from the data layer to the client presentation layer. As a plus, GeneXus can be used to generate the “web portion” of an application too.

Philosophical Differences

The development philosophy of GeneXus has been historically different from “mainstream” development. In fact, the concepts closer to our core philosophy are those around Model Driven Development (MDD). We do not believe HTML, Javascript, Java, Objective-C, .NET (Mono) or any other particular technology should be the centerpiece around which developers build their software.

For GeneXus, languages are just an assembler to obtain final applications, simply a tool to obtain the objective, and (most importantly) an interim tool that will change over time. Based on this, it is not important for us if tomorrow’s applications are programmed (say) using a functional language, or a paradigm completely opposite to the current one. Languages are merely a way to reach the goal. Never-ending discussions like “native vs. web applications” are not relevant. What is really important is the model representing your application.

It is for this reason that, in GeneXus, our intention is to provide a way to declare the application, and not to actually code it. For instance, you can declare that you want:

• A List/Detail interface over an entity, and that will result in two, three, or more forms, depending on the entity being displayed.

• To show a list of entities, and then choosing whether to display them in a simple grid, a map, a magazine viewer, or chart.

• Authentication, via Facebook or Twitter.
Declaring in a model allows for an abstraction level infinitely superior to coding in Javascript or any other third-generation level language.

Weaknesses of the GeneXus Approach

If you're used to “coding everything”, then MDD can feel quite rigid. The goal of MDD is to ‘program' on a higher level of abstraction. This means that you have to specify less and generate more. However, this also means that you can't tweak every last detail the way you want.
Since GeneXus is a modeling platform with more than 20 years of development, it provides a flexible and extensible model so that most of those details can be configured. While in the short term our approach can lack some particular features of the target platform, this is solved by a model built to be extensible from the ground-up.

GeneXus Strengths

GeneXus allows developers to separate themselves from the different platform details (as PhoneGap and Titanium do) but that’s not all the value it provides. Unlike them, it also includes abstractions and patterns to develop applications in a way that positions the developer closer to the domain of the application than to the technological details. This way has been proven to be more sustainable over time than coding in a third-generation language.
GeneXus also conceives the application as a whole: Data Layer, Business Layer, Services Layer, Security Layer, UI Layer. The mobile component is one component of the application: an important one for sure, but still only one part.

The core strength of GeneXus is that models last longer than any leading technology, and models are what you build in GeneXus. Applications were once built on iSeries or Windows platforms, and today they might be on mobile or web platforms. The technology changed, but the model behind those applications is still valid.

In regards to Smart Device applications, the model allows designing the application independent from the platforms but not ignorant of them. The same application, generated from the same model, will not look the same in, say, iOS and Android. GeneXus is cognizant of the design patterns for each platform, so you will never see, for example, an application generated with GeneXus for Android that has a “Back” button in the action bar.

The model has also many strengths:

Model extensibility 

GeneXus provides two main extensibility concepts to make the model more flexible:

• User Controls

If you want to include in the model a specific UI control (for example, based on any found in http://www.cocoacontrols.com), it can be used in GeneXus by adding a simple wrapper for the control in Objective-C or Java.

• External Objects

This refers to extending an API to use native functionality that is not (yet) built-in. For example if you want to interact with NFC, you can develop a wrapper to do the mapping of the API calls, so it can be included and used in the model.

Design is not “one size fits all”

The model allows for elements to vary depending on the platform. A very simple example is that you can, say, add more information to a screen if the device is an iPad, without having to write any specific logic to achieve this.

Grid based design

The Form designer uses a “grid-based” approach, which allows placing “tables” (containers) with relative (percentage) sizes at design time, and they are transformed to pixel values at runtime. As a result, developers don’t have to create multiple screens because of small variations in the form factor, density, or other screen characteristics.

Separation of Concerns

The model also provides an abstraction for all visual design elements called a “Theme”. Everything related to visual design (such as colors, backgrounds, borders, images) is defined in the theme separately from the screen layout, and can be tweaked for each platform without having to create multiple form definitions.

Summary

Although Titanium, PhoneGap and GeneXus all help you create smart devices applications, they are quite different in the way the achieve this. GeneXus creates the whole application (data layer, business logic, web, and mobile) based on a model. GeneXus is a good option in the medium and long term because of its philosophy of software creation: declaring over programming in low-abstraction languages.

Events in Smart Devices objects

In the Smart Devices objects (Panels and WorkWith) you can write events as you would normally do in any GeneXus object. However, due to the differences between platforms, the way events are triggered is not the same as in Win or Web objects.

When you generate a smart device object in GeneXus, it creates the client component that runs on the device, but also some services that run on the server.

The events, programmed in the smart devices object, may be executed in the server or in the client, based on some rules:

• the Start event runs on the server, the first time the object is shown on screen (in the device)
• the Refresh event runs on the server, every time there is a refresh triggered on the client (by calling the refresh command or whenever it is called automatically)
• the Load event runs on the server, and is called immediately after the Refresh event, with the difference that it is used to modify Grid variables.
• every other user event is executed on the client device.

Regarding user events, even though the event runs on the client device, it may need to send requests to the server. For instance, when you call a procedure, the procedure runs on the server.

Having said so, there are a few tips we can give you.

Tip 1: don't call two procedures in the same event

In some cases, you may want to write the following code:

Event 'SomeUserEvent'
    Composite
        Procedure1(...)
        Procedure2(...)
    EndComposite
EndEvent

This wil perform two server requests, one for each procedure. This is an expensive operation and should be avoided when possible. Instead, write

Event 'SomeUserEvent'
    Procedures1and2(...)
EndEvent

and make Procedures1and2 call Procedure1 and Procedure2. This is better because there will be only one request to the server.

Tip 2: move as many code as you can to the Refresh or Load events

Suppose you need to initialize a certain variable, that will be used in a user event. You may write something like

Event 'SomeUserEvent'
    Composite
        &MyVar = InitalizeVariable()
        DoSomething(&MyVar)
    EndComposite
EndEvent

However, if the initialization doesn't depend on any information from the client device, it is better to make the call in the Refresh or Load event, because it avoids making a new server request. The code may look like this:

Event Refresh
    &MyVar = InitalizeVariable()
EndEvent

Event 'SomeUserEvent'
    DoSomething(&MyVar)
EndEvent

Tip 3: execute device-dependent initialization code in the caller object

The Start and Refresh events are executed in the server, so it is not possible to access device information (geo location, for example) when executing those events.

If you need to have that information available in the Start or Refresh events, you should pass them as parameters to the smart device object.