Pros and cons of the low-code

Here we are again. We left with some signs that the market was sending us:

• immediate time-to-market
• massive digitization of processes
• fast development and always in line with technologies
• reduced time of system maintenance
• reduced time in bug fixes

These demands seem to be throwing standard development into crisis, as it is unable to keep up with customer demands. These needs seem to undermine standard development, which cannot keep up with customer requests.

Everything seems to be very complex because of the continuous need to “customize” every product, with the consequent being a strong request for developers compared to the real availability. In addition to this, there are problems related to the style of code writing, subjective from developer to developer, which rises to software maintenance problems. Last but not least, the number of projects that are in real life insist on a single figure…and so on and so forth.

What seemed to make the developer a fascinating job, future-oriented, innovation, research, “cool” things, today has made it a nightmare.

And it is precisely by acting on these aspects that low-code can lighten the load, allowing developers to dedicate themselves again to what makes them “happy”. (Some people enjoy seeing others running after a ball and some people benefit from incomprehensible strings of characters. That’s just the way we are!)

Be careful though: lighten up, not replace.

In this episode we’ll talk about the advantages and disadvantages of a low-code approach.

What really is low-code?

When we talk about low-code, we’re talking about an approach in which the creation of a digital service/product can be done through the use of third-party platforms, without necessarily having development skills. Writing code is not, however, completely abandoned. The developer is strictly necessary for a few reasons:

• Customization of low-code modules, when required
• Integration between modules
• Insertions of any “pure” software layers to ensure interoperability between frameworks

What is gained is mainly in the fact that the intervention of a developer can be easily restricted, allowing even non-technical figures to create digital products and services. A logical approach to problems and the ability to structure and modulate a solution are required.

Not all that glitters is gold.

But then if it’s so simple, why don’t we do everything in low-code?

Because it goes without saying that we are faced with a short blanket: if I pull on one side, I uncover the opposite.

Not writing code involves someone writing it for us, maintaining it for us, and ensuring for us that everything works. You become dependent on someone else, and this must be taken into account when you choose to go down this road. If whoever manages the low-code platform that we have chosen, at a certain point decides to close, the risk that we find ourselves with a system that no longer works is very high..

It is also true that we are now in a historical context in which we tend to “own” less and less. The cloud and the services linked to it are the places/non-places where all the digital components on which we base our lives exist and live. And the cloud is not an eternal entity and is also subject to the rules of the market. The services on which we base our sites, our photos, our music, are also in this case, in the hands of someone else. And as much as we may consider it a valid solution, this someone else may one day decide to abandon everything, leaving us in the street.

So by creating a similarity between the two contexts, just as with the cloud, with low-code, the risk of depending on someone is high. .

But it tends to be the case that the larger the entity you rely on, the more users that platform has, the less likely it is that it will abandon us.

Advantages and disadvantages of low-code

Below are the most obvious pros and cons of using a low-code approach.

What are immediately apparent are two aspects:

• anyone can create a technological product: this solves the problem of lack of developers
• we don’t have full control: we don’t know exactly what’s going on “under the hood”.

Everything is working, everything is spinning, we are fast, but there is a huge question mark over how this happens. Of course, that’s not a bad thing as long as you decide to focus on the end result and not on how it is achieved.

It is also true, however, that if we wanted to act with a “screwdriver” and go perform a “fine tuning” of our solution, this is impossible, since what we have in front of us is to all intents and purposes a closed box with “suggested” tools to use it.

Possible scenarios

So, given the benefits and risks, what scenarios does it make sense to cover with a low-code approach?

1. Products with fast time-to-market, but not long-lasting: e.g. applications related to particular events, campaigns, historical moments.

Once we have established the theoretical duration of the project and chosen the low-code components that we are going to insert, we are almost sure to obtain an optimal result in a very short time without having to worry about having to scale up the product. In addition to this, if we have the fear of being left on the street by those who have developed the low-code platform we are relying on, we are almost sure that, if when it was chosen, it was solid, it will hardly close down without a fade-out that will lead us to sustain our solution until the established duration.

2. Poc/MVP/Prototypes: if we need to evaluate the goodness of an idea, of a solution, without losing too much time in the implementation, the use of low-code platforms allows us to validate in a short time if a hypothetical architecture, a UX or certain functionalities have reason to exist for the hypothesized scenarios. In this way, the client can immediately understand whether to invest in a digital product or to abandon the decision.

3. Business processes or tools: automating business processes. At certain times in a company it may be necessary to automate processes in order to dispose of jobs, migrations, conversions due to reorganization, systems audits that inevitably highlight inefficiencies that need to be corrected in a very short time. In addition to this, there is the need to create internal tools to manage certain activities related to projects: data analysis, machine learning, integration with external tools.

4. Innovative projects: The continuous proliferation of new technologies makes it impossible to immediately implement solutions based on them. However, these new technologies put a lot of pressure on IT departments that have to maintain legacy projects and meet the “crazy” demands of those who want to see a new technology applied at all costs. IoT, Vocal Assistant, VR, AR, Smart Home, are filling our minds, stimulating ideas, but without real and measured validation on what impact they can have in our lives. Using a low-code approach we can quickly drop these technologies into reality raising the bar for experiences. We are approaching the future, but without too much “flutter”: we are experimenting.

5. Software Modules: if within our architecture we have repetitive, boring and time consuming software components in the development, these can be replaced, temporarily, by low-code modules, allowing an initial reduction of implementation time and costs. Only afterwards they can be replaced or strengthened with “pure” code.

So?

In conclusion: low-code today can be defined as an approach that, if placed side by side with the standard one, allows us to compensate for criticalities, allowing us to solve problems in the short term, with a series of advantages:

• Extension of the tech team with non-technical figures, making up for the lack of developers
• Easing the workload of the developer who can concentrate on more complex projects
• Experimentation without too much complexity
• Realization of non-critical architectural modules, to be placed side by side to the “pure” code.

In the next episode, we’re going to look at some low-code platforms to understand how they can fit within a project.

See you soon.

Alex.

[Ita]

Let’s talk about the low-code approach (Episode 2) was originally published in Caffeina Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Pro e contro del low-code

Eccoci di nuovo qui. Ci eravamo lasciati con alcuni segnali provenienti dal mercato:

• time-to-market immediato
• digitalizzazione massiva dei processi
• sviluppo veloce e sempre al passo con le tecnologie
• riduzione dei tempi di manutenzione sistemistica
• riduzione dei tempi di risoluzione dei bug

Queste esigenze sembrano mandare in crisi lo sviluppo standard, che non riesce a stare dietro alle richieste dei clienti.

Tutto sembra essersi complicato negli ultimi anni, vista la continua necessità di “personalizzare” ogni prodotto, con la conseguente forte richiesta di sviluppatori rispetto alla reale disponibilità. A questo si affiancano problemi legati allo stile di scrittura del codice, molto diverso da sviluppatore a sviluppatore, che fanno sorgere diverse difficoltà nella manutenzione del software. Infine il numero di progetti che nella vita quotidiana insistono su una unica figura…e chi più ne ha, più ne metta.

Ciò che sembrava fare dello sviluppatore un mestiere affascinante, orientato al futuro, all’innovazione, alla ricerca, alle cose “fighe”, oggi lo ha reso un incubo.

Ed è proprio agendo su questi aspetti che il low-code può alleggerire le attività, permettendo ai developers di dedicarsi di nuovo a ciò che li rende “felici”. (Eh si…siamo felici quando facciamo codice. C’è chi gode nel vedere gente che corre dietro ad una palla e chi trae giovamento da stringhe di caratteri incomprensibili. Siamo fatti così!)

Attenzione però: alleggerire, non sostituire.

In questo episodio parleremo dei vantaggi e degli svantaggi legati ad un approccio low-code.

Cosa è veramente il low-code?

Quando parliamo di low-code, parliamo di un approccio in cui la creazione di un servizio/prodotto digitale può avvenire attraverso l’impiego di piattaforme terze, senza necessariamente avere competenze di sviluppo. La scrittura del codice non è, però, completamente abbandonata. Lo sviluppatore è strettamente necessario per alcuni motivi:

• Personalizzazione dei moduli low-code, quando richiesto
• Integrazione tra moduli
• Inserimento di eventuali strati software “puri” atti a garantire l’interoperabilità fra framework

Ciò che si guadagna risiede principalmente nel fatto che l’intervento di uno sviluppatore può essere circoscritto, limitato, permettendo anche a figure non propriamente tecniche, di poter realizzare prodotti e servizi digitali. E’ richiesto, fondamentalmente, un approccio logico ai problemi e la capacità di saper strutturare e modulare una soluzione.

Non è tutto oro quel che luccica.

Ma allora se è così semplice, perchè non facciamo tutto in low-code?

Perchè vien da se che siamo di fronte ad una coperta corta: se tiro da una parte, scopro la parte opposta.

Non scrivere codice comporta che qualcuno lo scriva per noi, che lo mantenga per noi e che garantisca per noi che tutto funzioni. Si diventa a tutti gli effetti dipendenti da altri e questa situazione va tenuta in considerazione quando si sceglie di intraprendere questa strada. Se chi gestisce la piattaforma low-code che abbiamo scelto, ad un certo punto decide di chiudere, il rischio che ci si trovi con un sistema non più funzionante è molto alto.

E’ anche vero che ci troviamo ormai in un contesto storico in cui si tende a “possedere” sempre meno. Il cloud e i servizi ad esso legati sono i luoghi/non luoghi in cui esistono e vivono tutte le componenti digitali su cui basiamo la nostra vita. E il cloud non è una entità eterna ed è soggetto anch’esso alle regole del mercato. I servizi su cui poggiamo i nostri siti, le nostre foto, la nostra musica è anche in questo caso in mano a qualcun’altro. E per quanto una soluzione può sembrarci valida e affidabile, questo qualcuno un domani potrebbe decidere di abbandonare tutto, lasciandoci per strada.

Quindi creando una similitudine fra i due contesti, così come per il cloud, anche per il low-code, il rischio di dipendere da qualcuno è alto. Ma tendenzialmente, più è grande la realtà a cui ci si appoggia, più sono gli utenti che quella piattaforma la usano, meno probabilità ci sono che possa abbandonarci.

Vantaggi e svantaggi del low-code

Di seguito i pro e i contro più evidenti nell’uso di un approccio low-code.

Quelli che risultano subito evidenti sono due aspetti:

• chiunque può creare un prodotto tecnologico: questo risolve il problema della carenza di sviluppatori
• non abbiamo il pieno controllo: non sappiamo esattamente ciò che accade “sotto la scocca”.

Tutto funziona, tutto gira, siamo veloci, ma c’è un enorme punto interrogativo su come questo accada. Ovviamente non è un male, nel momento in cui si decide di concentrarsi sul risultato finale e non sul come questo si ottenga.

Se volessimo, però, agire con un “cacciavite” e andare ad eseguire un “fine tuning” della nostra soluzione, questo è impossibile, o comunque difficile, dato che ciò che abbiamo davanti è a tutti gli effetti una scatola chiusa con degli strumenti “suggeriti” per usarla.

Scenari possibili

Quindi, visti i vantaggi e i rischi, quali scenari ha senso coprire con un approccio low-code?

1. Prodotti con time-to-market veloce, ma non duraturi nel tempo: per esempio applicazioni legate ad eventi particolari, campagne, momenti storici.

Stabilita la durata teorica del progetto e scelte le componenti low-code che andiamo ad inserire, siamo pressoché sicuri di ottenere un risultato ottimale, in pochissimo tempo senza doverci preoccupare di dover scalare il prodotto. Oltre a questo, se abbiamo il timore di essere lasciati per strada da chi ha sviluppato la\le piattaforma\e low-code a cui ci appoggiamo, siamo pressoché sicuri che, se quando è stata scelta era solida, non possa chiudere di punto in bianco senza un fade-out che ci porti a sostenere la nostra soluzione fino alla durata stabilita.

2. Poc/MVP/Prototipi: se abbiamo esigenza di valutare la bontà di un’ idea, di una soluzione, senza dover perdere troppo tempo nella messa in esercizio, l’utilizzo di piattaforme low-code ci consente di validare in poco tempo se una architettura ipotetica, una UX o determinate funzionalità hanno ragione di esistere per gli scenari ipotizzati. Il cliente ha così la possibilità di capire immediatamente se investire su un prodotto digitale o se abbandonare la decisione.

3. Processi aziendali: automazione di processi aziendali. In determinati momenti storici, in una azienda potrebbe risultare necessario andare ad automatizzare dei processi per smaltire lavorazioni, effettuare migrazioni, avviare conversioni dovute a riorganizzazioni, audit di sistemi che inevitabilmente vanno ad evidenziare inefficienze da correggere in pochissimo tempo

4. Progetti innovativi: il proliferare continuo di nuove tecnologie, rende impossibile una applicazione immediata di soluzioni basate su esse. Tuttavia proprio queste nuove tecnologie esercitano molta pressione sui reparti IT che si trovano a dover mantenere progetti legacy e a soddisfare le richieste “pazze” di chi a tutti i costi vuole vedere applicata una nuova tecnologia. IoT, Vocal Assistant, VR, AR, Smart Home, stanno riempiendo le nostre menti, stimolando idee, ma senza una reale e misurata validazione su che impatto possano avere nella vita. Usando un approccio low-code possiamo in poco tempo calare queste tecnologie nella realtà alzando il livello delle esperienze. Ci avviciniamo al futuro, ma senza troppo “sbattimento”: stiamo sperimentando.

5. Moduli software: se all’interno della nostra architettura abbiamo delle componenti software ripetitive, noiose e time consuming nello sviluppo, queste possono essere sostituite, temporaneamente, da moduli low-code, permettendo un abbattimento iniziale dei tempi di realizzazione e dei costi. Solo successivamente potranno essere sostituiti o irrobustiti con codice “puro”.

Quindi?

In conclusione: il low-code ad oggi può essere un approccio che, se affiancato a quello standard, permette di andare a compensare delle criticità, permettondoci di risolvere alcune problematiche nel breve periodo, con una serie di vantaggi:

• estensione del team tech con figure non tecniche, sopperendo alla carenza di sviluppatori
• alleggerimento del lavoro dello sviluppatore che può concentrarsi su progetti più complessi
• sperimentazione senza troppe complessità
• realizzazione di moduli architetturali non critici, da affiancare al codice “puro”.

Nel prossimo episodio andiamo ad analizzare alcune piattaforme low-code per capire come possono essere inserite all’interno di un team di sviluppo.

Alla prossima.

Alex.

[Eng]

Parliamo dell’approccio low-code (Episodio 2) was originally published in Caffeina Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

I was also a developer and one of those people who fell in love with the philosophy that put the “beautiful code” at the center of their work, well written, in a refined way, only for the sophisticated palate.

I have seen the concept of development change: from monolithic C to object-oriented programming in C ++, to get, with JAVA, the abolition of the pointer, up to C #, which provided a beneficial and functional visual environment, passing through standardization of patterns, up to the tools of today that make the work more accessible and more solid.

This path always had critics or sponsors due to change being seen as a danger for those who believe “It already works well!” or those who “The future is already here.”

The fact is that these changes have made it possible to focus more and more on ideas, trying to break down where possible and the recursive and recurrent components’ implementation times.

It’s called progress or innovation or whatever the hell you want to call it!

The “progress” at the base of new choices

In philosophy, progress is “the development of human society in its history conceived as a linear proceeding, where improvements in every aspect of human existence, presumed as prevalent to interruptions and setbacks, accumulate in such a way as to determine favorable conditions, advanced material and spiritual aspects of human life “(cit. Wikipedia)

Applied to technology, I would translate it as follows: placing a new brick to build subsequent ones endlessly.

So why not take all that is useful and good that has been done in software development, make it easy to access, and use to concentrate on subsequent evolutions?

And this is where the low-code approach can prove to be successful.

Before delving into and dissecting all the hidden implications behind such an approach, I would like to discuss what prompted me to consider such a solution. I will do this in several articles so that you can reflect and metabolize the concepts every time.

I believe that a gradual path is critical because such a choice can have non-trivial consequences. Not only from a technical point of view but also from a “social” point of view: new types of teams, new professional figures, new organizational models will have to be born.

I conclude this introduction by providing the first starting point for the subsequent analysis, calling into question what drives most of the entrepreneurial choices: the market.

Today, what is the market suggesting to us?

“Every company is now a software company” is the message that Satya Nadella, CEO of Microsoft, launched a couple of years ago from the Mobile World Congress stage.

The message was born from the companies’ awareness that a digitization process was appropriate to keep up with the markets’ evolution.

Processes and services must be digitized, and doing it well means making a difference compared to competitors. And what if software development can make this possible? This is why it has become a critical activity for (almost) everyone.

Placed in this new perspective, “software development” today is not only creating monolithic applications. It becomes the creation of applications, workflows, and services that act within the company to improve its processes and, why not, the lives of employees and end-users who use the services.

Development is, therefore, more articulated, sometimes even more complex, while professionals are asked to develop more and more quickly, to meet the increasingly numerous and pressing demands of customers. But software development is not magic: well-made software requires time, people, investments. And developers seem to be in short supply compared to today’s immense demand.

This is why companies have always looked with interest to the promises of “alternative” development, which reduces the “code-grinder” part to get to the applications first while trying to satisfy the tendency of developers to learn, create, dare.

But is there a solution?

For some time now, these needs seem to be met by platforms and frameworks that promise to facilitate development with results comparable to those of a classic development.

So the question we all ask ourselves (and which I have also asked myself, of course) is: have we found the panacea for all ills? So now we can make developers happy, produce code in no time, satisfy customers and even become “rich”?

That’s not quite the case. However, the right alchemy of ingredients can lead to unexpected results for critics and balanced solutions for those too enthusiastic.

Therefore, it seems possible to respond to a particular slice of the market, which requires speed, scalability, solidity, and a pinch of customization, without completely distorting the approach, work, and skills of the developers that are always fundamental and essential, whatever the scenario.

I share some articles that may give evidence of the interest currently presented around the low-code approach.

• https://insidebigdata.com/2021/01/09/why-2021-is-the-year-of-low-code/
• https://blog.cubeapps.co/2021-how-low-code-will-be-at-the-heart-of-businesses-fight-in-the-post-covid-world-cd2b4b4f3f89
• https://powerapps.microsoft.com/en-us/blog/3-low-code-trends-why-low-code-will-be-big-in-your-2021-tech-strategy/

We will see in the following articles if all this is possible and how.

See you soon and stay tuned.

[Ita]

Let’s talk about low-code approach (Episode 1) was originally published in Caffeina Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduzione

Sono stato anche io sviluppatore e uno di quelli innamorati della filosofia che metteva al centro del proprio lavoro il “codice bello”, scritto bene, in modo raffinato, solo per palati fini.

Ho visto cambiare il concetto di sviluppo: dal monolitico C, alla programmazione a oggetti del C++, per arrivare, con JAVA, all’abolizione del puntatore, fino al C# che metteva a disposizione un ambiente visuale molto utile e funzionale, passando per la standardizzazione dei pattern, fino ad arrivare agli strumenti di oggi che rendono il lavoro sempre più agevole e solido.

Questo percorso ha avuto sempre detrattori o sponsor, perchè ogni cambiamento è sempre visto come dannatamente pericoloso per quelli che “Funziona già bene!” o magicamente risolutivo per chi “Il futuro è già qui”.

Fatto sta che questi cambiamenti hanno fatto in modo che ci si potesse sempre di più concentrare sulle idee, cercando di abbattere, dove fosse possibile, i tempi di realizzazione di componenti ricorsivi e ricorrenti.

Si chiama progresso o innovazione o come diavolo vogliate chiamarlo!

Il “progresso” alla base delle nuove scelte

In filosofia, il progresso è “lo sviluppo della società umana nella sua storia concepita come un lineare procedere, dove i miglioramenti di ogni aspetto dell’esistenza umana, presupposti come prevalenti rispetto alle interruzioni e agli arretramenti, si accumulano in modo da determinare condizioni positivamente avanzate, materiali e spirituali, della vita umana” (cit. Wikipedia)

Applicato alla tecnologia lo tradurrei nel seguente modo: piazzare un nuovo mattone per poter costruire quelli successivi, all’infinito.

E allora, perchè non prendere tutto ciò che di utile e buono è stato fatto in ambito di sviluppo software, renderlo di facile accesso e utilizzo per potersi concentrare sulle evoluzioni successive?

Ed è qui che l’approccio low-code può rivelarsi vincente.

Prima di approfondire e sviscerare tutte le implicazioni nascoste dietro ad un approccio del genere, vorrei ragionare con voi su cosa mi ha spinto a prendere in considerazione una tale soluzione. Lo farò in diversi articoli, in modo da poter ogni volta riflettere e metabolizzare i concetti.

Ritengo che un percorso graduale sia importante perchè una scelta del genere può avere conseguenze non banali, non solo dal punto di vista tecnico, ma anche dal punto di vista “sociale”: dovranno nascere nuove tipologie di team, nuove figure professionali, nuovi modelli organizzativi.

Concludo questa introduzione fornendo già adesso il primo spunto per l’analisi successiva, chiamando in causa ciò che guida la maggior parte delle scelte imprenditoriali: il mercato.

Cosa ci suggerisce oggi il mercato.

“Every company is now a software company” è il messaggio che Satya Nadella, CEO di Microsoft, lanciò un paio di anni fa dal palco del Mobile World Congress.

Il messaggio nasceva dalla presa di coscienza delle aziende che un processo di digitalizzazione fosse opportuno per essere al passo con l’evoluzione dei mercati.

I processi, i servizi vanno digitalizzati e farlo bene significa fare la differenza rispetto ai concorrenti. E cosa se non lo sviluppo software può rendere possibile questo? Per questo è diventato un’attività critica per (quasi) tutti.

Calato in questa nuova prospettiva, lo “sviluppo software” oggi non solo è la creazione di applicazioni monolitiche. Diventa la creazione di applicazioni, di workflow e servizi che agiscono all’interno dell’azienda per migliorare i suoi processi e, perchè no, la vita dei dipendenti e degli utenti finali, che i servizi li usano.

Lo sviluppo si fa quindi più articolato, a volte anche più complesso, mentre agli addetti ai lavori si chiede di sviluppare di più e più in fretta, per soddisfare le richieste sempre più numerose e pressanti dei clienti. Ma lo sviluppo software non è magia: software ben realizzati richiedono tempo, persone, investimenti. E gli sviluppatori sembrano scarseggiare rispetto alla grande domanda di oggi.

È per questo che le imprese hanno sempre guardato con interesse alle promesse dallo sviluppo “alternativo”, qualsiasi cosa che aiutasse a ridurre la parte “macina-codice” per arrivare prima alle applicazioni, cercando al contempo di soddisfare la tendenza degli sviluppatori ad apprendere, creare, osare.

Ma esiste una soluzione?

Queste esigenze da un po’ di tempo, sembrano essere soddisfatte da piattaforme e framework che promettono di facilitare lo sviluppo con dei risultati paragonabili a quelli di uno sviluppo classico.

E allora la domanda che ci poniamo tutti (e che mi sono posto anche io, ovviamente) è: abbiamo trovato la panacea di tutti i mali? Quindi ora possiamo rendere felici gli sviluppatori, produrre codice in poco tempo, soddisfare i clienti e addirittura diventare “ricchi”?

Inutile dire che non è proprio così. La giusta alchimia degli ingredienti, però, può portare a risultati inattesi per i detrattori e a soluzioni equilibrate per quelli troppo entusiasti.

Sembra possibile, dunque, rispondere ad una particolare fetta di mercato, che richiede velocità, scalabilità, solidità e un pizzico di personalizzazione, non snaturando del tutto l’approccio, il lavoro e le competenze degli sviluppatori sempre fondamentali e imprescindibili, qualsiasi sia lo scenario.

Vi condivido alcuni articoli che possono dare evidenza dell’interesse ad oggi presenta attorno all’approccio low-code.

• https://insidebigdata.com/2021/01/09/why-2021-is-the-year-of-low-code/
• https://blog.cubeapps.co/2021-how-low-code-will-be-at-the-heart-of-businesses-fight-in-the-post-covid-world-cd2b4b4f3f89
• https://powerapps.microsoft.com/en-us/blog/3-low-code-trends-why-low-code-will-be-big-in-your-2021-tech-strategy/

Vedremo nei prossimi articoli se tutto ciò è veramente possibile e come.

A presto e “stay tuned”.

[Eng]

Parliamo dell’approccio low-code (Episodio 1) was originally published in Caffeina Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;TR

Many times we’ve been asked to develop interfaces containing material-design style input elements and, since they usually require some custom validation logic, we have always relied on javascript for their visual state handling too. Today we want to propose a leaner pure-css approach for their implementation. It’s very useful and performing, especially if the javascript part would be used for graphic purposes only.

THE CHALLENGE

Our goal is to create a classic material-design style input without javascript, i.e. a field with a label overlaying the input that moves above it on focus, as shown in the figures below:

LET’S CODE

First, we define the markup code of the sample field:

<div class="field">
<input class="field__input" type="text" name="firstname" />
<p class="field__label">Firstname</p>
</div>

With no custom CSS applied, it will look something like this:

Now, let’s write a few lines of CSS to apply some basic style to the input and to make the label overlying it:

.field {
position: relative;
}

.field__input {
appearance: none;
width: 100%;
padding: 12px;
border: solid 1px grey;
outline: none;
font-size: 16px;
line-height: 20px;
}

.field__label {
position: absolute;
top: 0;
left: 0;
margin: 0;
transform-origin: 0 0;
transform: translate3d(12px, 12px, 0);
font-size: 14px;
line-height: 20px;
}

The result should look like this:

At this point, we want the label to move above the input when it’s focused, so the user can freely enter some text. Let’s manage this feature with some additional CSS:

.field__input:focus + .field__label {
transform: translate3d(0, -100%, 0) scale(0.875);
}

and just a few minor adjustments on the code written before:

.field {
/* ... */
margin-top: 24px;
}

.field__label {
/* ... */
text-transform: uppercase;
transition: transform .2s;
}

And that’s the result!

But… just wait a second!

How can we keep the style applied on focus when the filled input will blur? This is most likely just the case where using javascript is the first solution we think of. Instead we can rely on the CSS :placeholder-shown pseudo-selector, which represents the status where the input shows its placeholder, i.e. when it’s not filled. So let’s apply some tweaks taking into account that this pseudo-selector will only work when the input tag’s placeholder attribute is set:

HTML

<input
class="field__input"
type="text"
name="firstname"
placeholder="Firstname"
/>

CSS

.field__input:not(:placeholder-shown) + .field__label {
transform: translate3d(0, -100%, 0) scale(0.875);
}

Just look how close we are to the desired result!

Only one new problem remains: if the input value is deleted, we notice how the label overlays the native placeholder just set…

Luckily, there’s a very simple solution: we can override the default style applied by the browser to the ::placeholder pseudo-element in order to hide it, as shown below:

.field__input::placeholder {
color: transparent !important;
user-select: none !important;
}

Et voilà! Our pure-css material-design input is ready!

Take a look at the full example!

BUT… WHAT ABOUT SUPPORT?

Although the pseudo-selectors/elements seen so far are well supported by modern browsers, your project could require some extended support, for instance, to IE11. In that case, no worries: let’s apply the following CSS and that’s it!

.field__input:not(:-ms-input-placeholder) + .field__label {
transform: translate3d(0, -100%, 0) scale(0.875);
}

.field__input:-ms-input-placeholder {
color: transparent !important;
-ms-user-select: none !important;
}

For more information about support, look at the following links:
https://caniuse.com/css-placeholder-shown
https://caniuse.com/css-placeholder

THAT’S ALL FOLKS! HAPPY CODING!

Pure CSS Material Design Input was originally published in Caffeina Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

New year new TM episode. Back at work full of (food) ideas after the winter holidays, here we are with our first experiment of the year.

We wanted to explore the power of AR and develop common and shared knowledge.

The Path choice

To develop our idea we had several options, eventually narrowing the choice down to Unity + Vuforia, SparkAR, ARCore. Our decision was guided by the prototype needs and the platform features, we needed:

• AR features
• Multi-target image recognition
• Scripting interface

Unity + Vuforia was our final choice, as SparkAR does NOT have multi-target image recognition support and ARCore needed a deeper knowledge of mobile technology and ecosystem. At this stage, we didn’t take into account the distribution so that combo seemed to be the better choice.

First enemies and friends

After setting up Unity with Vuforia, we got used to working with the Unity interface. Thanks, YouTube mate. 😄

At first, we were quite confident in handling the platform but, shortly after we realised RTFM was the only way.

Learning to read the map.

Reading the manual facilitated our journey in developing the idea, we took some pictures of some posters we have in the office and uploaded the images on the Vuforia developer portal, several times until we got the best score for every single image in order to be recognised by the tool.

Implementing some strategy

In Unity, we created target image objects. Every target had a handler to manage image detection.

To orchestrate the treasure hunt, we created another script aimed at handling the objects already recognised and notifying the user once they find a new object during the quest.

Conclusion

Considering none of us were 100% confident with the Unity interface, the prototyping took us 3–4 hours but we sorted out how to properly write the scripts and link them to the objects. In the end, the result was quite good.

Here you can find the code repository to run a demo.

Tech Mondays is a series of events spontaneously organized at Caffeina’s HQ in Parma by the Technology Department and (for the time being) aimed towards its employees only. Never Sleep.

Tech Mondays #4 was originally published in Caffeina Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

So… holidays came and went, but right before enjoying our food-centric Italian traditions we worked on another experiment in the series.

This time our team was very small.
In fact, because of vacations, we were just 3 people.

A Pong game, in the browser, controlled by YOU!
Our very own user.

Try for a live version here!

We wanted to explore body-based UIs.

Some of us have prior experience doing pose estimation with Kinect, but we wanted to see how far we could get on our most loved (and hated) platform: the browser.

We used a handy (badum, tss…) hand-detection library on top of tensorflow: Handtrack.js

This kickstarted our development, gifting us with ready-made hand tracking! Now, that’s something!

We just needed to:

• map hand coordinates to screen-space
• draw the paddles and the ball
• write some game logic

We also wrote some code on top of that library to only pick the best hand in both sides of the scene.

Soon we realized that waving your hand around for a long time is quite tiresome.

So we reduced the actual physical space which controlled the paddle, limiting it around the center of the scene.

This increased sensitivity of the controls and also resulted in higher stability.

After playing around for a while with some magic numbers, we found a balance, which allowed us to play a full game.

The Aftermath

We’re quite happy with the result.
It’s poor-man style, but it works, and it took between 3 and 4 hours to accomplish this.

While this is definitely NOT what we would do in production, we now know it is doable indeed!

If we had to bring this into a real world application we would most probably write our own logic on top of tensorflow + body-pix.

This was the last one for 2019.
Let’s see what we’ll come up with in 2020!

Tech Mondays is a series of events spontaneously organized at Caffeina’s HQ in Parma by the Technology Department and (for the time being) aimed towards its employees only. Never Sleep.

Tech Mondays #3 was originally published in Caffeina Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

👋 Welcome back to the second issue of Tech Mondays!

For this episode we’ve taken a lot of inspiration after a weekend at KIKK Festival in Namur 🇧🇪

Walking into the city we were overwhelmed by fresh tech installations and talented people who ⚡️ fueled our minds, so we came back with the idea of experimenting something with Arduino.

The idea: visualizing people’s heartbeat on LEDs.

We wanted to get out of our comfort zone: none of us have solid knowledge of hardware topics and the first idea was visualizing something that human senses 💗 can’t perceive.

The main goal was to attempt a physical output having a physical input.

Some practical use cases for this could be:

• Outdoor installations, for client exhibitions
• Physical Interfaces, like video playback speed
• Engagement, attracting people to try something new

Here’s the Shopping List for our journey!

Same as the last episode, we split up into three working teams, with the following tasks:

• Normalize heartbeat sensor values between 0 and 1
• Plug-in the power supply
• Turn on LEDs using Arduino

What’s Bad? 🖕

• The first team spent a lot of time because of a broken heartbeat sensor.
• The second team messed up by plugging the 5V ground cable into the regular power supply’s ground.
• At the end we had to fine tune sensor values by averaging them, in order to have a smooth LED wave.

What’s Good? 🤟

• We found a sound sensor and we saved the journey.
• The IDE Plotter was awesome to debug our application.
• In almost 4 hours we came up with a first prototype which we shared with coworkers in our Innovation Room!

What’s Next? 👉

The first final result didn’t meet our expectations because of the output.
The interaction wasn’t engaging for the final users and visual was very basic as well.

In the following days we decided to:

• Replace the sound sensor with the heartbeat one.
• Blend physical output with a digital one using Processing.

We bought another heartbeat sensor, plugged it into the Arduino and it finally worked! 🔮

We improved the code by modifying the way we read the input values and the LED visual output.

At the end, we added a final visualization with Processing. As shown in the video above, it begins when then LED stripe lights reach the end.

Code and further technical details can be found in this GitHub repo.

We also suggest to follow these tutorials (Tutorial 1, Tutorial 2) if you want to know more.

Tech Mondays is a series of events spontaneously organized at Caffeina’s HQ in Parma by the Technology Department and (for the time being) aimed towards its employees only. Never Sleep.

Tech Mondays #2 was originally published in Caffeina Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

This story has two main parts to it. The first is a road, 481km in America that connect West Sacramento to Ocean City. The second is a young boy, born in Rome at 16 Via Tevere on 31st October, 1930. He was the son of an American soldier working at the embassy.

On 20th July 1969, while Armstrong and Aldrin made history by stepping foot on the moon, this boy who was now an adult, was on the Apollo 11 Command Module Columbia. He had to be in orbit for twenty-one and a half hours, an experience that journalists described as ‘the most profound solitude any human has ever known’. Michael Collins, the name of the boy, is the third hero in the moon landing story, and for us in the Tech Team, a symbol.

He is a symbol for all those who, thanks to their hard work behind the scenes, push the limits of mankind forward, which would otherwise be impossible without them. Going back to the road at the beginning, its name is Route Fifty, and it is known as being the most isolated road in the United Sates.

Whether the name Route Fifty reminds you of the 50th anniversary of the landing on the moon, or the strength and determination shown by Collins during his incredible endeavour, Route Fifty is a tribute to this story either way.

Where we started?

As an R&D project our aim was to experiment with the creative process of an interactive game. To do that, we started with basic shaders and used Three.js to build up, step by step, a complete experience.

The Team was composed of 3 developers (Alberto Parziale, Lorenzo Girardi, Vincent No), a 3D artist (Gian Guido Ponzini), a copywriter (Daniel Molinari), a QA Tester (Pietro Tancredi) and a UI/UX Designer (Nico Cherubin).

Our deadline was to be finished in one month.

From Cubes to Ship

We started creating a scrolling ground through shaders with some basic 3D shapes to test the scene. Immediately, we had the idea of creating an infinite runner, set in Space with various bonuses and enemies, and a little bit of 80s Sci-Fi flavour. With everything shown on screen, the next steps were to bind the controls with the keyboard and touch inputs and to create a spawning system with different PowerUps.

At this point we had our first prototype.

Something more…

“That’s one small step for man, one giant leap for mankind” — Neil Armstrong

The more we worked on the project, the more we started craving a narrative drive for the entire experience. We came up with the idea of celebrating one of the most important events of the 19th Century, a milestone for mankind, the 50th anniversary of the Moon landing which will take place this year.

Thinking about this glorious date brings up the memories of the famous words spoken by Neil Armstrong and his iconic walk on the Moon’s surface, but there is also another perspective of the story.

An Alternative Hero

Armstrong was making history bouncing without gravity on the lunar sand, but meanwhile, deep in space, there was another hero that had one task: to fly around in orbit of the Moon, keeping radio contact with the other members of the crew.

All those three men, together, made this amazing achievement of science and exploration possible. This moment, addressed by the newspapers as “not since Adam has any human known such solitude”, is a great emotional trigger and, moreover, fits perfectly with the mechanic of an infinite runner.

So, we had our Hero: Michael Collins, an American astronaut born in Rome in 1930 and who, at the age of 39, contributed to writing history.

The title has a double meaning: it can be connected with the 50th anniversary, and also because Route 50 is one of the longest roads in the US, measuring at more than 3000 miles long, and is well-known as being “the loneliest road” in America. We thought that was a touching reminder to the solitude of flying around the Moon all alone.

That’s what Route Fifty is all about.

3D Assets

Once we had the main narrative driver, we updated all of the 3D placeholders with some ad hoc stuff: we reproduced a low-poly faceted version of the Apollo 11 capsule used by Collins and created some Sci-Fi PowerUps for our arcade experience.

For optimisation’s sake we decided to keep a unique colour palette texture for all the assets (with huge improvements on download size and draw calls), mapping the UVs of each model on it and shading everything with a Matcap custom shader. Each model has been optimised by deleting back-faces and keeping the polycount as low as possible.

One Project to Rule Them All!

One of the most important achievements of this R&D project has been to test the possibility of working on a single project that can be delivered on many different platforms.

By meticulously working on the optimisation, we stripped all the shaders, used many best-practices from games such as object pooling and a single texture atlas through all the assets to create minimal effort on draw-calls.

All those tricks helped us to gain best performances even on low-end mobile devices.

Thanks to this, with one project we have been able to deliver the browser experience both on desktop and mobile devices. Moreover, we also worked on PWA support, and being able to export an APK that can be distributed through the Android Play Store.

Easter Egg

When we reached the deadline we literally went crazy and decided to add a little Easter Egg: through the Konami Code you can access an alternative setting, a tribute to the conspiration theory that the Moon landing was just a movie recorded in an artificial studio. Will you be good enough to find it? :)

Be the Rocket Man!

During the Route Fifty game you can explore some interesting facts about the Moon Landing and all the journeys human beings have made in Space, as well as seeing realtime stats of all the users connected. Just prepare yourself, start the engine and be an alternative hero.

START YOUR ENGINES!

Route Fifty was originally published in Caffeina Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is the simplest design you can configure Kubernetes on (except minikube). It is not meant to be for production use as it does not offer high-availability on the cluster. More on the reasons later.

Two words on Kubernetes

Just because it’s getting a lot of hype lately, it doesn’t mean that it is the right technology for your use case or that your company is ready to adopt it.

Kubernetes is not a way to lower costs on itself, in fact you’ll probably spend more on servers. What it does though, is guarantee a high availability for your projects, meaning that it will be hard for them to have downtime even if you deploy a bugged software. It needs to be configured correctly though.

If you can, opt for a cloud based K8s solution. They offer a lot of complicated parts that otherwise you’d have to configure yourself. (read: control plane high availability, network, storage, autoscaling on nodes)

Some situations when it might come in handy:

• Cluster management
• Structures that use continuous deployment.
• Canary deployments.
• A/B testing or even multiple different projects on the same cluster
• Management of multiple clusters on different availability zones
• Rollback on faulty deployments
• Autoscaling
• Microservices

Deploying K8s on a single server may be too much. It is best when you have multiple servers to deploy it on.

The parts that make Kubernetes are:

• kubeadm or the control plane, made of etcd controller manager scheduler api server
• kubelet which is the software that manages deployments as instructed by the control plane

The design I’m explaining here requires about 3 servers. One for kubadm, and two for kubelet.

Cloud VS On-Premise

All major players offer Kubernetes on their platforms. Microsoft has AKS (Azure Kubernetes Service), Amazon offers EKS (Elastic Kubernetes Service) and Google has GKE (Google Kubernetes Engine).

There are some other providers that offer it too such as Digital Ocean which introduced it recently.

Although I’m a fan of AWS, for a K8s cluster I’d suggest Google Cloud because it has the most complete implementation.

Generally all these providers will offer out of the box these features:

• High availability on the Control Plane which you don’t even pay
• Scalability with autoscaling on nodes
• Fast storage of different kinds (Block Storage, FS)
• Load Balancer and External IPs
• Auto update on the nodes

You can have all of the above with an on-premise solution by combining virtualisation and somewhat more powerful servers while still having a

Design

Let’s stick with a simple design like this and analyse it. With my knowledge at the time, this is what I had come up with, considering to scale the worker nodes in case it was necessary.

So there’s a Master node where basically we’ll install kubeadm out of the box. And there are 3 nodes dedicated to app deployment.

Master

Configuring the master node is very simple, especially considering that this part is well documented. You only need to install a few software packages on the host system such as Docker, Kubelet, Kubeadm, Kubectl and their dependencies.

To install Docker these are the commands needed to be executed. Remember that the official supported Docker community edition version for Kubernetes is the 18.06. To check the available versions for the exact version code run apt-cache madison docker-ce

sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg2 \
    software-properties-common

curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -

sudo apt-key fingerprint 0EBFCD88

sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/debian \
   $(lsb_release -cs) \
   stable"

apt-get update
apt-get install docker-ce=18.06.1~ce~3-0~debian

The following code installs Kubernetes components instead.

apt-get update && apt-get install -y apt-transport-https curl

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF

apt-get update
apt-get install -y kubelet kubeadm kubectl
apt-mark hold kubelet kubeadm kubectl

The above snippets should be executed on all the servers.

There some other configuration requirements for Kubernetes.

# The swap should be turned off
swapoff -a

# Remove the line that contains swap from /etc/fstab
nano /etc/fstab

# Check that all servers have different mac addresses
ip link

# Check that all servers have a different product ID
sudo cat /sys/class/dmi/id/product_uuid

The only thing left to do is to bring up the master and that’s done with the simple command kubeadm init don’t execute this yet though.

Networking

Kubernetes has some core components. These components are standard but for the whole system to work some third party components are needed. These pieces communicate to each other through interfaces. For example the container engine used isn’t necessarily Docker, it can be any software implementing the Container Runtime Interface or CRI.

Networking is a difficult concept in this context. Consider the diagram above again. We have 3 servers where eventually our applications will go.

Let’s say I want to deploy a database (MySQL) and a php application on my cluster. Kubernetes puts them where it thinks they fit best. This means we can have all sorts of combinations like having the database on server Node 1 and the application on server Node 2. Now my php container needs to communicate to the mysql container but it isn’t in the same server. We need a way to make it seem to my containers that they’re in the same local network and communicate to each other. For this purpose Kubernetes exposes the Container Network Interface (CNI).

The CNI is supposed to create a virtual network on each server node and make it possible for each container to reach the others on the same IP space like 10.244.0.0/16. When a container tries to reach another container it will ping an IP such as 10.244.0.1, the CNI will translate this IP to the node IP and then to the container address inside that node.

Available CNIs include different features. But generally they add some overhead to networking. It is possible to define your own networking through iptables rules. This isn’t difficult and doesn’t add overhead, but it’s a manual job that is manageable only if you have a few servers.

The documentation is quite well written and there are many articles explaining this issue with clusters. Here is a well written article that explains networking more in detail https://medium.com/google-cloud/understanding-kubernetes-networking-pods-7117dd28727

This is a great article that classifies all the CNIs and analyses their features. https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-10gbit-s-network-36475925a560

One of the simplest to use is Flannel, it offers basic connectivity features and doesn’t add much overhead.

Now that we have some knowledge on networking we’re ready to execute kubeadm init and we’ll add to it, the POD network space through the flag --pod-network-cidr=10.244.0.0/16 If you choose another CNI, you have to check the documentation on what network space to give it, for example calico uses 192.168.0.0/16.

# - Initializing kubernetes master with a 
#   network space ready for flannel
# - Add --dry-run and write the output to a file to have
#   an idea of what configurations the installation will use
kubeadm init --pod-network-cidr=10.244.0.0/16 --dry-run >> init.log

# Finally run the following to initialise the node
kubeadm init --pod-network-cidr=10.244.0.0/16

Worker Nodes

Technically the Kubernetes cluster is up but it only has a master server. What’s missing is the worker nodes. The output of the kubeadm init command will show you the join command which can be used on any server exposed on the internet as long as it has kubeadm kubelet kubectl docker installed.

If for some reason you cleaned the command output and don’t have the join command, you don’t need to panic. It can be generated again.

kubeadm token create --print-join-command

# The output will be something like below
kubeadm join 10.10.10.1:6443 --token vpo60f.pk0x3fhrnzhvr2sy --discovery-token-ca-cert-hash sha256:8d55ca78560cb926d2953e14042dd3de40137234a4b51698894db0f43849aa97

It’s easy as that, running the code on the other nodes will set them up. We can monitor it like this.

watch -n 1 kubectl get nodes -o wide --namespace kube-system

The command below instead will show the state of the components.

watch -n 1 kubectl get pods -o wide --namespace kube-system

There you might notice a couple of pods name core-dns that seem to not be working. That’s because we told Kubernetes to get ready on the network space for Flannel by adding --pod-network-cidr=10.244.0.0/16 but didn’t really “install” Flannel yet.

The installation of Flannel (or any other CNI) generally means deploying it to the cluster.

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Done… Not yet

So the cluster is up and running. Trying to deploy an application, like the one I mentioned before, wouldn’t work though. There’s another problem with having an application living in multiple servers and that is storage.

Generally all of the applications will work with files, some will get generated, some will get deleted and a few need to be saved persistently like the files a database generates.

Out of the box, Kubernetes gives you the possibility to save files in the Pod context, which means that other Pods can’t access them, but containers in the same Pod could. It also means that the files remain if the Pod restarts but they will be deleted if the Pod itself is deleted. Thus we need a better way to save files. We have two requirements, the files need to be accessible by multiple Pods possibly in different servers and they need to be persistent.

Not focusing on how good the application design is, let’s see what are the problems of this deployment.

So I told Kubernetes to deploy a php application that generates pdf files, stores the “generated” status on the database and then renders them. Then I also deployed a MySQL database. I said, I want 2 replicas of the php application and 1 of my database.

Now consider the php application generating a file, storing to the database the fact that it generated that particular file and then rendering it.

When I ask again for that pdf file but this time, I ask my other php container on the second Pod, the application will check the database which will tell it that the file has already been generated, but when php looks on the filesystem, it won’t find anything.

This issue is not easy to explain and you realise the gravity only when deploying an application and scaling it up.

To solve this Kubernetes came up with something called CSI, Container Storage Interface.

Storage

When an application defines a storage in Kubernetes, it asks for a PVC, which translates to Persistent Volume Claim. It’s like telling the cluster that I, the application, need this much persistent storage. When this happens, Kubernetes will activate a storage Provisioner and allocate that storage to the application. There may be different storage provisioners. For each provisioner, there will be a Storage Class.

This makes sense because there are different kinds of storage thus different storage provisioners. Each one will create it’s own kind of storage.

There must always be a default Storage Class. Application deployments don’t have to define it always.

To allocate the storage, the provisioner has a few options such as being bound to a file server like Ceph, GlusterFS or others.

Ceph and GlusterFS though, are clusters of their own. They can be installed on the same servers where the Kubernetes cluster is running or on other servers completely. The second option is strongly advised.

I won’t get too into the storage servers on this article but consider two things when it comes to storage.

• Persistent means persistent. The software I mentioned above offer replication.
• Network. The servers on the Kubernetes cluster communicate continuously with each other, and with the world. The storage servers need to communicate to each other continuously to replicate the data and to serve it.

I’ll eventually write another article to explain better how to set up a storage cluster.

Production

This cluster is not yet production ready for three reasons.

• Persistent Storage configuration
• Creating a cluster with highly available master nodes
• Hardening the cluster security-wise

Special thanks to Adriano Pezzuto for his support.

Thanks for reading this far and stay tuned for more fun articles :)

Configure Kubernetes on premise was originally published in Caffeina Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.