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.

On Saturday 11 January, Denis Payre, the president of 'Nous Citoyens' (a new French political movement) was a guest on French presenter Laurent Ruquier's show, 'On n'est pas couché.'

This new french political movement has been officially launched on the 10th of october 2013, and allow its members to be part of it, thanks to its collaborative website, developed by the parisian web agency Sooyoos.

Coded with PHP, a few configuration steps on Clever Cloud made by Sooyoos were needed to get the app ready for the TV broadcast.

Usually, the app runs on a 2GB and 2CPU scaler type (scalers are the equivalent of instances on Clever Cloud). But the TV audience brought 2 massive peaks of visits.

Around midnight, the webapp scaled from a L scaler size to a XXXL scaler size (8 CPU, 16GB of RAM), in a few seconds.

In most cases, media exposure of this kind (over 30 mins for Nous Citoyens here) leads to a huge load on the servers of the sites concerned, causing slowing down, and in the worst cases, periods of unavailability. For those who are lucky enough to be able to foresee such a load, the solution is to prepare a migration of the site to a more suitable infrastructure.

Unfortunately, this is not always the case. Because some companies fell victim to the "Capital effect" ('Capital' is a popular magazine program on the French TV channel, M6). According to social networks, some of them often acknowledged several minutes of unavailability during the program.

However, the Nous Citoyens website, hosted on Clever Cloud, remained perfectly stable throughout Denis Payre's interview on France 2, and that despite the increase in traffic due to the millions of television viewers.

Clever Cloud, therefore, managed the increased load without problem, thanks to an automatic attribution of resources to the infrastructure of NousCitoyens.fr.

Version française

Samedi 11 janvier, Denis Payre le président de Nous Citoyens, un nouveau mouvement politique, a été reçu dans l'émission de Laurent Ruquier "On n’est pas couché".

Lancé officiellement le jeudi 10 octobre et déjà fort de plusieurs milliers d'adhérents, Nous Citoyens propose à tous de devenir acteur du mouvement, notamment grâce à sa plateforme web collaborative conçue par l'agence parisienne Sooyoos.

Développée en PHP, celle-ci repose sur Clever Cloud pour son hébergement. Avec quelques réglages simples, l'agence Sooyoos a pu être en mesure de préaprer le site de Nous Citoyens à l'émission de France 2, où était invité Denis Payre.

En temps normal, la plateforme repose sur une scaler (équivalent d'instances chez Clever Cloud) de taille "Large", soit 2Go de RAM et 2 vCPU dédiés. Mais face à la forte médiatisation, 2 grands pics d'audience ont été enregistrés.

À partir de minuit, l'application a migrée d'une instance de taille 'L' jusqu'à 'XXXL' (8 CPU, 16Go de RAM), en passant par les tailles intermédiaires, puis est redescendue petit à petit vers sa taille d'instance habituelle.

Dans la plupart des cas, une telle exposition médiatique (ici plus de 45 minutes pour Nous Citoyens) entraîne une charge momumentale sur les serveurs des sites web concernés causant des ralentissments, et dans le pire des cas, une indisponibilité.

En revanche, hébergé sur Clever Cloud, le site de Nous Citoyens est resté parfaitement stable tout au long de l'interview de Denis Payre sur France 2, et ce malgré la montée conséquente du trafic due aux millions de téléspectateurs.

Malheuresement, il n'en va pas de même pour tout le monde, certaines entreprises étant victimes de “l'Effet Capital” par exemple sur M6, résultant en ralentissments ou indisponibilité de quelques minutes au cours de l'émission. Pour ceux qui ont la chance de prévoir une telle charge, la solution est de prépaprer une migration du site sur une infrastructure adaptée.

Another kind of ‘external’ DBs

Until now, databases hosted on Clever Cloud were only available from within the hosted apps. Since it was impossible to use external DB management software, it was a bit cumbersome to import or export data.

This era is over: right now, the services are available from outside!

Indeed, it means you will be able to use your favorite DB management tool. If you want to use our platform simply for host a database or if you have to access to your db for initial setup or migration, you can.
It also means you can use Clever Cloud as a pure Database as a Service (DBaaS) provider.

The current form (only available from within Clever Cloud apps) is
"dbname.engine.internal" (eg "customers.my.internal").

The new domain names will follow this pattern:
"dbname.engine.clvrcld.net" (eg "customers.mysql.clvrcld.net").

As for the ports, they stay the same (3306 for MySQL, 5432 for PostgreSQL).

Old domain names remain active for now (no sunset date is planned yet), but we strongly encourage you to make the switch.

We will indicate a date for the end of the internal databases services later.

The support remains at your service to help you tomigrate from .internal to clvrcld.net in your code.

Don't hesitate ton contact the support for more precisions

Version française

Lancement des Databases as a Service sur Clever Cloud

Jusqu'ici les bases de données hébergées dans Clever Cloud n'étaient utilisables que depuis l'application hébergée. Il était alors impossible d'utiliser un outil de gestion de base de données externe, ce qui était fastidieux notamment pour les imports/exports.

Cette ère est révolue: désormais, les services sont accessible depuis l'extérieur !

Concrètement, cela signifie qu'il sera possible d'utiliser l'outil de management de votre choix. Si vous souhaitez utiliser notre plateforme uniquement pour héberger une base de données ou si vous devez accéder à votre base depuis l’extérieur pour l'amorçage ou la migration de vos données, c'est désormais possible.
Clever Cloud devient donc aussi fournisseur Database as a Service (DBaaS) !

La forme actuelle (seulement accessible depuis les applications Clever Cloud) est:
"dbname.engine.internal" (ex "clients.my.internal").

Les nouveaux noms de domaine adopteront désormais cette forme:
"dbname.engine.clvrcld.net" (ex "clients.mysql.clvrcld.net").

En ce qui concerne les ports, ils restent les même (3306 for MySQL, 5432 for PostgreSQL).

Nous préciserons une date de fin des services des bases de données internes ultérieurement.

Le support reste à votre service pour vous aider à migrer de .internal vers le clvrcld.net dans votre code.

N'hésitez pas à contacter le support pour plus de précisions