In ancient times, developers weren't able to be just developers. They had to be experts in computer networking and development platforms as well.

Great ideas had to sit on the sidelines and wait. You had to build out a sandbox to play in before you started coding. If you wanted to use Ruby (on or off Rails), you had to start with something like Ruby Version Manager (RVM) to set up the server space you needed. If you decided that Node.JS was a better fit for your next application, you would have to tear it all down and go get Node Version Manager (NVM) from GitHub. Obviously, people couldn't live that way for long.

The Dawn of Reason

Platform as a Service (PaaS) providers started popping up about a decade ago and civilization took off from there. Now developers worry about development and the host manages the OS, the software stack, the runtime, the servers, virtualization and storage. That problem then became that PaaS providers were too narrow in their focus.

That's when Clever Cloud Driven Development (CCDD) was born. It evolved the concept of PaaS and made it polyglot. That means that now you have the freedom to work in any of your preferred runtimes (Docker, PHP, Scala, etc.) and have access to your favorite services (MongoDB, PostgreSQL, Redis, etc.). Now, instant access to those capabilities can be deployed with a simple git push.

Tell Me How

One of the tricks that do the magic is the Clever Tools™, the official and open-source CLI. Installing it allows the rest of us to use Clever Cloud deploying without leaving the terminal. And that's pretty awesome.

…deploying without leaving the Terminal.

Here the quickstart to install and use it without leaving this page: open your term and paste this:

# Do this once, and forget about it
npm install -g clever-tools && install-clever-completion && clever login

# Go to your workDir
# For the Terminalesque ones, create your app without touching a mouse
clever create -t node "My Great Application"
clever deploy
## PROFITT
clever open
## Grep logs as in ye olden days
clever logs --before 2016-10-13 | grep "undefined is not a function"

What to Do With All the Extra Time

CCDD is not merely a convenience. It actually makes the app world a better place™. It allows developers to do a better job at continuous delivery. When you don't have to set up and maintain your local environment, your time is freed up to create the additional features that customers want or concentrate on performance tuning.

You don't need to manage your sandboxes for dev and production. CCDD can update your apps in production with no downtime and assure that they will automatically self-heal and redeploy after a crash.

For lean startups and small developer teams, CCDD means scalability from day one. You don't need to invest in more servers to handle spikes in traffic if you suddenly someone says something nice about you on Hacker News (one can only hope). CCDD scales horizontally and vertically as needed in an instant.

Every developer deserves top-of-the-line security and reactive monitoring. CCDD is built to handle the infrastructure while you handle the accolades.

Nowadays, we know that null is to be avoided. It's been dubbed the billion dollar mistake by its own creator, and the dreaded NullPointerException everyone knows about. Yet, when it comes to getting rid of nulls, nobody agrees.

null is bad, m'kay

• NPEs
• hard to read (is this value always defined?)
• handling possibly undefined values is tedious

The issue is that we focus on null, and not on the actual problems it causes. If your only goal is to get rid of NPEs at all costs, then you will pay those costs. Dearly.

The memory safety issues caused by null are solved on most platforms. In many languages, null is a pointer to a specific value with specific properties, so not literally a null pointer anymore, and on modern OSs, the memory protection system will prevent your code from directly accessing the address 0x00.

So the big risk is having your program blow up (NPE, segfault, panic, …) because of an unexpected missing value. The core issue is that you were unable to express that the value was possibly missing; the crash is a consequence of this issue. Yet many people try to solve the issue by preventing the crash (null check, null object pattern, …) instead of handling the core issue: a value could be missing and you weren't able to express it.

Stop chasing NPEs and fix your domain model

If you're trying to get rid of NPEs by removing the difference between "there is a meaningful value" and "there is no value", then not only you're not solving your issue, but you're making it far, far worse.

Your domain model didn't let you express statically the possible absence of a value, but the presence of null at least gave you a stuctural difference at runtime. That's why putting default values or worse, following the null object pattern, is terrible. You had structural information, but couldn't use it in a rigorous way, so you're just throwing it all away because of an implementation detail.

If you're searching for a replacement to null to denote missing values, it has to be structurally different from a regular value (it cannot belong to the domain of the value you may have). So if you're in a typed system, then a value that may be not there has to have a different type from a value that's definitely there. In an untyped language, you can't have a static difference, so using null is kind of OK (though there are better solutions).

For example, in java you can do:

// Bad
String notThere = null;
String there = "my string";
// Turbo-bad
String notThere = ""; // or "N/A", etc
String there = "my string";
// Good
Optional<String> notThere = Optional.empty();
Optional<String> there = Optional.of("my string");

With optional, not only you have a structural difference between defined and undefined strings (instead of having to check if the string is equal to "" or "N/A", without any guarantee that it's not the actual value), but it's clearly documented in the type.

Optional is available in Java 8 (and in Guava if you're not using java 8 yet). In scala, rust, ocaml and many other languages, it's called Option, in Haskell it's called Maybe.

This is why you can have nice things

Ok so now you have a proper representation for your optional values. In a typed language it means that you're forced to check if the value is already there before using it.

For instance, in java:

Optional<Integer> parseOptionalString(Optional<String> myOptionalString) {
    if(myOptionalString.isPresent()) {
        Optional<Integer> result = parseInt(myOptionalString.get());
        return result;
    } else {
        return Optional.empty();
    }
}

This works perfectly well, but is still as verbose as using explicit null checks. So if you're only concerned about code terseness (you really shouldn't), it can feel like a marginal improvement (it's way better than that).

Thankfully that's not the idiomatic way of handling Optional values: now that we can denote the abstract concept of being possibly not there (in this case, Optional<_>), then we can do useful stuff about it:

• transforming it only if it's defined (with map)
• eliminate the option by providing a default value when we don't need the information anymore (with orElseGet)
• sequencing several operations returning options (with flatMap)

All of this comes for free because we were able to clearly define our domain model. Some languages like Kotlin provide approaching solutions with things like the Safe Call Operator for chaining operations (instead of using map and flatMap) and the Elvis Operator for providing default values. This, however, is less extensible and less composable than having proper options (map and flatMap are not specific to Optional).

Optional<Integer> parseOptionalString(Optional<String> myOptionalString) {
    return myOptionalString.flatMap(parseInt);
}

Once you have properly defined your domain model, then you can have cleaner code thanks to the information encoded in your types. Aiming at terser code without proper abstraction will lead you to perlish nightmares.

To sum up

Using null causes problems. Resorting to solutions that erase information (setting a default value too early or worse, the null object pattern) will cause graver and subtler problems.

In order of decreasing importance, the problems with null are:

1. it's not clear for people if a value can be missing
2. the program can blow up if somebody forgot to handle a missing value
3. it's tedious to sequence operations returning null

Don't settle for solutions that only address #2 and #3.

At Clever Cloud, we like giving a try to new technologies when they're released, especially if it means safer software. When facebook recently announced the release of infer, we surely wanted to try it out!

The concept of static analysis

The idea behind infer is quite simple: it analyses your code before you actually run it and looks for common code issues or misconceptions which can lead to unsafe code.

You can think of it as some kind of compiler plugin which will do some stricter checks and produce more warnings than your compiler usually does.

The idea of static analysis is really great as you get to know some of your code's problems before even trying to run it. An issue with most static analyzers though is the false positives, those warnings you know shouldn't be there as you perfectly know that this problem is 100% impossible to happen.

Testing our code with infer

We tend to use a lot of different technologies to run our platform. From the languages supported by infer, Java was the most interesting to us. I decided to run a first pass on all of our Java projects.

After getting the code on github and following the installation instructions in INSTALL.md, I started with one of our core small pieces of software.

I didn't expect to see many defects but was afraid of getting a ton of false positives when I ran the test: infer -- mvn clean package. Turned out we got a couple of legitimate warnings about resource leaks when spawning a process and then waiting for it but not destroying it once done, and nothing more! No false positives at all.

For the record, those warnings looked like that:

error: RESOURCE_LEAK resource acquired by call to exec(...) at line 89 is not released after line 89

Fix was as easy as changing return Runtime.getRuntime().exec(cmd).waitFor(); to

Process p = Runtime.getRuntime().exec(cmd);
int res = p.waitFor();
p.destroy();
return res;

As the beginning was encouraging, I went on and ran it on one of our core libraries. One similar problem found, one potential null dereference in an error path and another resource leak warning. The first two were trivial to fix, the last one was a weird one as in some cases it didn't detect a stream to be closed. After refactoring this piece of code which was quite old, the warning was gone, but what appeared to me as being a false positive frightened me when it came to running it on our big API.

The relevant annoying warning: error: RESOURCE_LEAK resource acquired by call to FileReaderHelper(...) at line 28 is not released after line 30

FileReaderHelper makes use of a BufferedReader; changing the scope of the inside reader fixed the issue.

Most of our other projects are really small and no defects were detected at all; then came our API. Our API is the oldest piece of software we're running. As time goes by, we externalise the codebase into separate projects but it's still quite a huge one with its 415 files.

Good surprise: only 20 defects, 18 of them in the same error path which would mean that our platform is unavailable anyways. Amongst the two others, one was clearly a false positive. I added an assertion to silence the warning with a comment explaining why it was there. But the warning wouldn't go. I've since then opened an issue for this which hopefully will be fixed soon.

An example of NULL pointer dereference for which we added checks because "better safe than sorry" when it really should never happen: error: NULL_DEREFERENCE object returned by token.getUserId() could be null and is dereferenced at line 86

Conclusions

Only two false positives in all of our codebase, and a couple of really pertinent warnings makes this project really promising. It doesn't throw a lot of warnings yet (or we didn't hit much) but it reduces the noise by giving only relevant ones and avoiding false positives, which is a really good thing for a static analyser.

With an integration into our CI, it'll now provide yet more guaranties about code safety.

Go and try it for yourself!