Saturday, July 22, 2017

Going beyond with your OutSystems Mobile App

Creating a native mobile app with OutSystems is so easy that it's scary! Just a few clicks and, in a few minutes, you'll have an iOS and Android application. Out of the box, the resulting app will look like this:

Simple. It's your show now, your "drawing board". Create!
This is the common pattern. However, before you go public, you should do the final tweaks. It's that extra mile, that "wow factor", that "5 star rating" that you must go after. Did you notice the "glitch" on app startup? Take another look at the video. What's happening is that the native splash screen wasn't customized and you're seeing the black screen (Operating System starting the app) and then a white "glitch", which is actually the webview loading content (OutSystems apps are Cordova based).

What happens OutSystems app start
What happens by default

To create that super user experience, you just have to do some small steps as described in the documentation: Use Custom Splash Screens. In the article, the splash screen will disappear after 3 seconds (enough time to load the webview) but, if you want, you can have fine control over the hiding of the screen. The result will be an app that gracefully starts:

The graph is now different:

What happens OutSystems app start
Fast feedback to the user

If you're having troubles following the documentation, I've created a small video on how to do it. Here it is:

Here's a MyResources.ZIP and here's an Extensibility Configuration JSON to get you going. This is valid at the time of the writing of this post, it might change in the future as Apple and Google change resolutions. You should keep an eye on the documentation.

Wednesday, March 29, 2017

The next train to production

Most of my professional life was spent working with banking, insurance, telco and media. Clients with mature processes in place that yield predictable results. In these industries, "safety is king". They are "control freaks"! And Cloud solutions are only "a dream" on most cases. On premises is still how they live. So, with this mindset you can expect (lots) of bureaucracy in place when staging software. The focus is not on "rapid continuous delivery" but rather more complex release processes spread through wider release cycles. They privilege stability over "the latest and greatest" that comes out of whatever software provider. This isn't a problem "per se". It's methodologies they've been maturing for decades to fit their business goals. Now, having said all this, you can expect the complexity illustrated below for a typical staging scenario in these types of clients:

Staging Environments
(click to enlarge)

Again, keep in mind this scenario is all using on premises.
So, how does your code get to production? Send a Zip file? Well, it's not that simple. Safety first right? Risk aversion! You might have noticed that I separated environments by team types: Development Teams versus Operational Teams. Project is rolling and it's time to got to production. Until QA, it's up to the development teams to promote software in a repeatable process that can be easily replicated. The jump to QA typically implies filling a rather complex form (normally using Change Management tools) with lots of info, namely, "why is this going to production", "impact analysis", "risk analysis", "who authorized", "who's the business group that requested the features", "who are the business users that will validate things... and on and on.

Staging Environments
(click to enlarge)

It also implies instructions to operational teams on how to deploy, rollback, etc. This is very important because, from QA onward, the deploy in the environments will be in charge of operational teams that might not have the slightest context about what is going to production and what changes it implies. After some time, if QA is "ok" and property validated... there's another request to pre-production, identifying issues that appeared in QA, etc etc. To production! Even more complex because if it's an upgrade to an existing system with an agreed operation time of 24/7, then no downtime. You have to clearly state how is that "no downtime" guaranteed and a special authorization might be required. Ok, this is a 24/7 scenario but there are apps that can have agreed times to upgrade production.

Does all this sound like fun? No. But, again, safety first. Where does all this fit this post? Well, in a recent project we had to create a new system, from scratch. No environments setup yet, no processes in place. Just a blank sheet of paper and a white board for us to do our best.

Staging Environments

We started with only a development environment. That spawned to QA and, afterwards, production. Then... you see where this is going right? Well, not quite. Dev, QA and production are "olympic minimums". But more than that? Would you buy all the complexity from these industries? Maybe not. Maybe you value the "rapid continuous delivery". Maybe you just want some parts, the ones that do fit your use case. Processes? YES! Excess bureaucracy? Maybe not. Maybe not. We’re currently evolving our system to fit our needs. We recently created the concept of "trains" because it made sense in our context.

Summing up: The complex processes that are typically found in banking, insurance, telco and media are good learning points, but you'll probably want to create your own. Their processes were matured throughout decades to fit their needs. I've learned to appreciate them. I do prefer other approaches, but I recognize the value of all this for these clients.

If, like me, you have the privilege to define the future of your organization and build something from scratch: It's really amazing! Learn from good examples. Then build your own good example.

Tuesday, February 21, 2017

The weight of decisions – moral machine

At some point, if you're developing some system, you will have to make decisions. But what if your decisions have real life impact? If you had to choose between killing yourself or another person? What's the rationale?

Here's an interesting test:

(Click on the image. Then just press Start Judging. In the end, you'll have a nice report)

Thursday, February 16, 2017

Top 5 funny things about JavaScript

The year was 1995, Google wasn't born yet. Mark Zuckerberg was 10 years old. Javascript was making its first steps. 22 years latter and JavaScript is everywhere. It's probably one of the most simple programming languages around and it's a good choice for someone that wants to start programming. However, there are some funny things about Javascript that anyone entering the language might find odd. Here's my top 5 funny things about the language. Just open a Google Chrome window and press F12. Have fun.

#5 – null is not an object?
What does a null look like in JavaScript? Well, let's check:

null is not an object

Object? Shouldn't null be the absence of meaningful value? Well, yes. Despite the above result, null is not considered an instance of an object:

null is not an object

Looking at the language specification, you can see that:
44.3.9 *undefined value*: primitive value used when a variable has not been assigned a value.
4.3.11 *null value*: primitive value that represents the intentional absence of any object value.

So, it's a case of misinterpretation.

null is not an object

#4 – NaN is a Number
What's "Not a Number"? Well... a number!

NaN is a Number

Funny as this might look, there's more. Not a Number has "identity issues" and is not equal to itself:

NaN is a Number

Well, the technical explanation for this is complex and it's related to the types of NaN (quiet NaN and signaling NaN). You can read more here, but the real way to check for a number is using the function isNaN():

NaN is a Number

#3 – Math.min() > Math.max()
Hum... So, the minimum value is higher than the max?

Math.min() Math.max()

Let's look at what they "represent":

Math.min() Math.max()

Well, seems to be wrong. These don't represent the max or min values for a number, but actually functions that given two numbers return the max or the min of the provided parameters.

Math.min() Math.max()

But why Infinity? And, apparently, in the inverse order? Well, looking at min(), "all numbers that are lower than positive infinity should be the smallest from a list, if there aren't smaller". So, the below makes sense:

Math.min() Math.max()

Number 5 is the minimum between 5 and positive Infinity.

#2 – true + true === 2
Let's do the math:

true + true === 2

So, someone entering the language might think that true === 1. Lets check:

true + true === 2

As odd as it might look, it actually makes sense. "EcmaScript standard specifies that unless either of the arguments is a string, the + operator is assumed to mean numeric addition and not string concatenation." So, it was the sum of the conversion to integer. As for the second part, true === 1 yields false because it's also comparing type and

true + true === 2

#1 – 0.1 + 0.2 !== 0.3
This is the coolest one and it's not a bug or anything. And it actually happens on several other programming languages, like C# (.NET) and I've written about it in the past

0.1 + 0.2 !== 0.3

"Computers can only natively store integers, so they need some way of representing decimal numbers. This representation comes with some degree of inaccuracy. That’s why, more often than not, 0.1 + 0.2 !== 0.3."
You can read more here (Floating Point Math) and see the behavior in other languages as well.

There is more to it, but these are definitely my favourite. If you want more, there's a cool video about JavaScript:

JavaScript Like It's 2013 (OutSystems)

Here's the full presentation at OutSystems Next Step 2013.

What's your favourite JavaScript funny fact?

Saturday, February 4, 2017

A huge handmade progress bar

We're all used to have everything digital nowadays. Onenote, outlook, notepad++, whatever-tool-to-take-notes-not-in-paper. We also have all the tools in place for a proper project management, from Microsoft Project to JIRA, Asana, whatever-tool-to-make-sure-your-project-is-successful. It's a digital world and there's no need to run from it. It's good. However, there's something all these tools cannot give: the sense of reality. Really see the finish line.

One of the best places to run in Portugal

What does this have to do with a progress bar? Well, I'm an old school guy. I like paper books rather than PDF. I spent more than a decade learning in chopstick boards. And the first years of your life are spent drawing things. So, I'm one of those that religiously believe that the first step of a task is always either a whiteboard or a blank piece of paper. The great news is that I have the privilege of working in a place where almost every wall is available to write. So, we draw a lot.

In the past months we were "under water" (again) with milestones to hit. Our attention was again starting to get scattered. "What needs to go to production when? What does JIRA say?". Argh, this is hard. Hum, drawing boards...

César Afonso
We have whiteboards everywhere

And magic happened. We decided to draw a progress bar on one of the walls next to the team (The little man walking the progress bar is actually a joke from a contest, "Right Price"). A small thing that made a huge difference. Everyone sees it when they arrive. Everyone knows when they leave. Everyone understands the weight of it. Everyone is focused on our progress. When someone comes to our team with a feature request we can quickly give visibility of "can or can't do". We even get creative around it.

So, the wall behind me is now a huge handmade progress bar that we updated everyday. It's a small detail but for me makes a huge difference.