LIBERO.IT: Hypotheses Non Fingo

La frase in questione la disse lui, Isaac Newton, all’inizio del XVIII secolo. Letteralmente sta per “non faccio ipotesi” e si riferisce al cuore del metodo scientifico: osservazione del fenomeno, deduzione di cause ed effetti ed elaborazione della teoria sottostante. Ma nel caso in cui nulla fosse deducibile dall’osservazione del fenomeno Newton dichiarava che non avrebbe fatto ipotesi di alcun tipo.

Nel momento in cui scrivo sono 60+ ore di blackout del servizio di email LIBERO.IT. Ho un paio di account gratuiti che uso soprattutto per ricevere spam e cancellare una cinquantina di email era da mesi la mia prima attività giornaliera. Con nostalgia mi viene da pensare anche che a volte mi mettevo di buzzo buono a cercare di “disiscrivermi” da alcuni di questi fantasiosi servizi finendo per scoprire che in molti casi essi erano gestiti proprio da IOL e richiedevano di loggarmi al mio account IOL (???) per dismetterli.

Dunque, il metodo scientifico.

L’osservazione del fenomeno ci dice che il servizio è giù e i messaggi cambiati ogni 6/8 ore parlano di problema infrastrutturale, escludono l’attacco hacker (e magari crypto-riscatti) ed escludono anche la perdita di dati. Nell’ultimo messaggio, firmato dal CTO di IOL, però non si trova la stessa nettezza di prima sul recupero dei dati. Pare invece verosimile che le email ricevute in queste 60+ ore siano andate perse.

Non mi metto a menarla con saccenza a coloro che stanno subendo un danno economico e professionale. Non è questo il punto di questo punto. Non ho trovato ancora un resoconto sulla faccenda e vorrei condividere i miei pensieri di “esperto del settore”. Al di là dei danni causati, ho la fortissima curiosità intellettuale di sapere/capire cosa diavolo può essere successo.

L’osservazione del fenomeno mi porta a formulare le seguenti ipotesi più o meno nell’ordine in cui si sono formate nella mia mente.

1. Fallito upgrade programmato della piattaforma. Nella notte di domenica si è intrapreso un qualche aggiornamento di un qualche software infrastrutturale (qualcuno ha ipotizzato Kubernetes) la cui configurazione è risultata imprecisa/incompleta/errata al punto da tenere fermo il servizio di email. Quando IOL parla di software “esterno” fa pensare proprio a questo; non bug di qualche tipo (che NON POSSONO FISICAMENTE buttare giù un sistema) ma configurazione errata. Ora, però, se intraprendi un upgrade dovresti ragionevolmente essere in grado di tornare immediatamente (in poche ore) indietro. Senza contare che magari quello stesso sistema “nuovo” l’avrai testato e ritestato in un ambiente parallelo e invisibile al pubblico prima. VERIDICITA: 6/10
2. Attacco hacker. Che sia stato subito escluso categoricamente da IOL non significa che l’ipotesi non stia in piedi. Potrebbe essere stato DDOS (ovvero fantastiliardi di richieste auto-generate che affogano i server) o ransomware. Nel primo caso, siti ben più esposti come Github reagiscono e isolano il sistema in pochi minuti. 60+ ore sembrano decisamente troppe. Ransomware? Se sì, l’intero sistema sarebbe criptato e inutilizzabile. Ci stanno le 60+ ore a oltranza di attesa senza soluzione. Potrebbe essere in corso una trattativa o un tentativo alla cieca di rimettere in piedi un sistema gemello. Ci sono i backup? Dove sono? Sono anch’essi criptati? Rimettere il tutto in piedi richiede qualche giorno. Però questa ipotesi è stata smentita con forza. Certo, questione di immagine! VERIDICITA: 7/10
3. Problema hardware. Significherebbe che è saltato un “macchinario” cruciale per un problema di obsolescenza o forse sbalzo di corrente o forse perché le cose semplicemente accadono. 60+ ore di stop fanno pensare a un componente nient’affatto secondario. La comunicazione tende a incoraggiare questo generico scenario usando il termine “infrastrutturale” ma quale pezzo di infrastruttura esattamente? VERIDICITA 4/10
4. Malfunzionamento dello storage. La comunicazione IOL, sebbene fastidiosamente generica, pare sincera. Ciò porta a rientrare nell’ambito del problema hardware focalizzandosi su un particolare elemento: lo storage, ovvero il “database” è saltato. Se così fosse, allora effettivamente il sistema riceve le email in arrivo ma non riesce a capire dove deve scriverle e per conto di chi. Al tempo stesso il database rotto impedisce login a chi vuol leggere la posta o scrivere nuovi messaggi. Ciò pare in linea con quanto largamente riportato su Twitter sotto #liberodown. E torna pure con l’enfasi posta sul recupero dei dati nelle comunicazioni ufficiali. Si tratterebbe di dotarsi di hardware sostitutivo (e qui il discorso obsolescenza torna prepotente) e soprattutto di recuperare i dati da backup esistenti o addirittura da hardware danneggiato. Più passa il tempo più si fa strada l’ipotesi che qualcosa possa essere andata persa. Nell’ultima comunicazione (martedi sera) si parla di ogni possibile sforzo per evitare perdite di dati. Sempre in questo scenario, una domanda che assilla molti utenti che non ha ancora risposta è: e le mail che arrivassero nel frattempo? Potrebbero essere state dirottate su un server parallelo e accantonate. Se ci hanno pensato! E se sono stati pronti a farlo! Se non lo hanno fatto sono perse. Punto. Quanto ci vuole a tornare su? O dicono “signori abbiamo piallato il sistema” e ripartono da zero appena sostituiscono l’hardware o la tirano per le lunghe (finché reggono) e poi ripartono con quello (>0) che avrebbero recuperato. VERIDICITA 9/10

Se dovessi scommettere i miei 2 cent lo farei sullo storage saltato che significa giorni di stop. Se dovessi scommettere altri 2 cent direi almeno altre 24/36 ore. E sono le 10:00 del 25 gennaio.

PS: Se ritenete di entrare in contatto fatelo su LinkedIn (https://linkedin.com/in/dinoesposito)

Architecting for the .NET Platform and Deep Diving into the new CRUD

Whatever CRUD means to you, architecturally speaking it is now dead. CRUD is dead? Long live CRUD, then. A more abstract approach to software design and development, summarized by the CQRS/ES acronym, has been around for a quite some time now. Many have coded it already and shared their experience and each did it in a kind of unique and personal way. It’s about time, however, we standardize to a few reusable patterns.

Here’s where “Architecting for the .NET Platform — UX, DDD, Events, Polyglot persistence” fits is.

Three days of SDD Deep Dive are enough to see a few of these CQRS/ES patterns in action within a new framework in development that aims at bringing the same smooth and familiar sense of programming of old CRUD to the next step. Join me then and I promise that in three days you’ll take a tour of the “known” (requirements, estimates, domain analysis, modeling, coding) and how it needs to change in order to remain mainstream and largely used.

Architecting for the .NET Platform — UX, DDD, Events, Polyglot persistence is a 3-day workshop taking place in London 8-10 November 2016. Register now. (Save £200 if within Sept 23).

ASP.NET Core, John McEnroe and the Mirror of my Office

At Wimbledon 1981, during his first round match against Tom Gullikson, John McEnroe had a chance to pronounce those (in)famous words: “You cannot be serious, man”. As a long-time tennis fan, those words remained printed in my mind. More than the wording itself, though, I remember the tone of speaking—blunt speaking.

I didn’t spend much time on ASP.NET vNext until it was really close to RC. To be honest, at this time moving away from battle-tested and mature ASP.NET MVC 5 is neither crucial nor critical for my everyday real-world development business. But, of course, any new thing is crucial and critical for a “guru” who gets exposure and gigs out of experimenting and speaking about new things. Imagine then when such a huge new thing like ASP.NET vNext comes out.

Anyway, I took it very lightheartedly until the final beta and then RC1. And when I looked at it—and the documentation—in front of the mirror, locked in the toilet of my office, me and me alone, I recalled those (in)famous that John McEnroe pronounced on the Centre Court of Wimbledon in the spring of 1981.

You cannot be serious, man.

I didn’t tell this anybody. I took it as my knee-jerk reaction to something that—no matter the announced stage (RC === release candidate) –I felt to be a great piece of work. Just in progress, though.

“It’s you, Dino—I said—YOU cannot be serious if you think so.”

But then it came the rename of tools, the rename of the entire framework, the RC2 announced and postponed. And you probably know the ongoing facts much better than me.

As I see things, ASP.NET Core was born to be a smaller thing than it is envisioned now. So it is now being repositioned, probably redesigned in some way and put in some sort of a different perspective. In the end, it will probably be the great piece of software it was supposed to be. But—as it was said at some point—it will take the time it takes.

This is a great lesson for anybody in software. Certain things must take their time to become serious things.

My wife and the MS/Xamarin deal

I’m inclined to say that the author of this article on Fortune.com speaks with my own words on the Microsoft/Xamarin deal. Yesterday, like everybody else in the software industry, I got to know that Microsoft bought Xamarin. Really? OMG, we’re still there? I thought it was a closed deal since at least two years. My sentiment? In a sense, I don’t care. In another sense I do care and I feel comfortable.

Recently, my wife asked me a similar question, one of those women’s periodical questions like “Honey, do you still love me?” Believe it or not, my reply was along the lines of “In a sense, I don’t know and I don’t care” — well, it was actually just a tiny bit softer than this :).

Kind of shocked, but not too much, she replied “And in another sense?” (Well, Silvia has really a strong sense of humour.)

Well, in another sense I just feel more than comfortable and happy with you even after so many years of living together. So naturally comfortable and in a good mood that I don’t even realize I’m happy. It’s happiness by nature. Or, in software terms, by design.

 

Question is, Xamarin products are going to be integrated in the MSDN subscription now? 🙂

 

Ubiquitous Language Is Everywhere, Even in Your Nose

When it comes to designing software, the first step is getting familiar with the domain. The second step is modeling the domain into a more and more formal set of statements up to diagrams and code. To model the domain, Eric Evans suggested the use of something he called the “ubiquitous language”. In spite of the evocative name, it’s something as simple as a glossary of terms including verbs, names, adjectives, adverbs, form the pillars of a language being used in all written and spoken communications between all parties involved in the software project. The primary goal of the ubiquitous language is avoiding misunderstandings and assumptions on both ends—stakeholders and development teams. Put another way, the ubiquitous language aims at making any use of a given word or expression within the project absolutely crystal-clear and unambiguous. When that word or expression is used, therefore, there should be all around the absolute certainty that it was understood and in the right and expected way.

And now let me share a personal note to emphasize the vital role that a ubiquitous language plays in life and subsequently in software.

My wife had nose surgery a couple of months ago. In particular she had turbinectomy, namely the surgical reduction of her quite enlarged turbinate. When we discussed pros and cons, the doctor (aka, the development team) said clearly that it was a routine surgery with the hardest part of it coming in the following weeks once the patient had been sent back home. To illustrate possible complications, the doctor used the expression “nasal crusting” to be removed in a clinic or any sort of doctor’s office, in case of trouble. He also said that sometimes patients do so well that they never show up to remove nasal crusting.

We confused the term “crust” and“scab” and that was reasonable too as both usually happen when you have nose surgery. Now, crust refers to a mix of dried mucus, blood and dead tissue that altogether form a solid block as big as a small finger. A piece of crust is stuck inside the nose with barely any chance to get rid of it without a doctor. Scab is simpler matter as it’s a superficial cover on a wound of any type. You have scabs in the nose whenever you get significantly cold for example.

To make things worse, in Italian we use the same word for both crust and scab. To cut a long story short, my wife enjoyed two weeks of trouble until we called the doctor and he promptly removed the crust and explained us that crust is not the same as scab.

How many times did that happen to you software-wise? That’s just the ubiquitous language in action.