Tales from the Machine Room


Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Set language to:en it | Login/Register


One + One = Zero

Long, long ago, in a galaxy far, far away, way before a certain guy named "George" started looking like Jabba the Hutt (even in his mannerism), there were SOFTWARE ANALYSTS, whose task was to look into the design for a piece of software and decide on which platform was better to run it, and then write down specs for the software that DEVELOPERS were going to follow as guidance to actually write the software.

There were also, obviously, "update cycles" that usually were longer than 3 hours and weren't repeated 32 times a day. Updates were planned and during the planning phase it was also checked if the infrastructure required updates for the software to run.

But times flies, the prequels multiplies... and we get to the present time when "analysis" is something you do at a psychiatrist's office and instead of "SOFTWARE DEVELOPERS" we have "Apps Implementor Supremo" (seriously, I've seen that shit on somebody business card, I almost chocked on my coffee), and the first step in any 'development or update cycle' for everything is "grab the latest version of whatever crap you think you could possibly use and put it in the specs".

Allow me to elaborate, is not that I think you shouldn't update your environment (developments or production), but usually you should have a reason to update something and a well-defined and documented procedure to update any particular component of an environment, depending of what that component does and how much it can fuckup everything else.

Update the DNS on a web server? Probably it won't make any difference on how the webserver actually work. Update the webserver software itself? Hemmmm... Maybe we should first check if the 47000 redirects and rewrite that we have in the config will still works with the new version of the software?

Anyhow, let's go on with the actual story...

It was a nice day in the middle of May, when one of our customers decided to have a brand new website with some kind of feed connection or whatnot built. Now, I don't remember exactly what was, but our Marketing Man was notified and he immediately sprang into action by sending an offer for a brand new webserver, or "a tiny-iny-server" as he put it. With a "standard LAMP" installation.

After the usual musical chair gig about the budget and the cost, the customer decided to NOT have neither a backup nor a test environment (yes, I know, they're calling it). After that, the server was "installed" by somebody (let's call him CL) and the developer began to ask about login, password and the like.

After a few days, we started receiving complaints about the first problems: the PHP version that was installed wasn't the correct version that was requested. Requested by who? And When? By nobody and never, of course, but for the developer "install PHP" was an alias for "install the latest version available +1" and not "install the latest stable version supported by the distribution".

Repeat basically for everything else that was installed and you got the idea.

Now, as an exercise in stress resistance, I went to check the changelogs between versions and realize that the version requested and the version delivered were basically the same. There were some differences, but nothing should have been so crucial.

Anyhow, the same CL that had installed the server had the task to upgrade it, and then the potato was back in the developer's dish.

About a week later, that also happened to be 3 days to the "live" date of the new site, we got a conference call from the customer and the developer because "nothing works and we don't know why".

Since that day I was "customer support", I had the (not) pleasure to have a look at that pile of crap.

First thing: rpm -q told me that the installed version of PHP was still the original one, but a quick php -version told me otherwise, from which I deduced that CL didn't updated the system by uninstalling the old one and installing the new one using packages but in some other (and very wrong) way.

Second thing: mysql wasn't working anymore. To be precise: mysql was "running" but after connecting I got nothing at all. Once again, rpm -q told me that the OLD version was installed.

Repeat the above for almost all PHP modules and a lot of other things.

Now, one of the customer's "special" requests was to install a specific version of ImageMagick, and here things got confused. Because RPM told me that ImageMagik wasn't installed at all but the executable was there. calling it however, returned a segfault.

TL;DR; the server had to be re-installed from scratch.

At this point I decided to escalate the problem to DumBoss, and told him we had two way: reinstall everything from scratch (and ask why the fuck CL had marked that thing as "ready" in the install sheet) or try to figure out what was wrong and try to fix that. Both could work, but I could do that or go on with my "customer support" because the two things were mutually exclusive.

At that moment DumBoss realized that he had authorized way too many vacations and "work from home" days, the result was that the office was emptier than the beach in December while support tickets were piling up. Obviously one of the "absent" was the mentioned CL. I left him to ponder the difficulties of managing when you really don't want to manage and for that day I didn't heard anything anymore about it.

The next day I noticed that CL was in the office, so I immediately asked a few cautious questions about the server and what he considered an "acceptable install procedure", all the answers were... unsatisfactory.

Apparently, CL's idea about "install version X.Y of product Z" was something along the line of "grab machine with version X.Y or close enough of Z and copy the executable(s) to the new machine". Of course this did not so good with all the libraries and dependencies. And what when version X.Y of Z wasn't available anywhere? Then in that case the procedure was "find some package of that somewhere on the 'net an install it with --force if necessary". Even that wasn't playing very nice with dependencies...

After that little discussion, it was clear that the only viable way was to reinstall the whole server, because try to 'fix' it was going to probably take a lot more time than what we had left before the end of the universe. And that CL was better suited for flipping burger at MacDonald's.

Davide
22/03/2017 15:12

Previous Next

Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.

10 messages  this document does not accept new posts

Guido

By Guido posted 12/06/2017 07:26

c'e' di peggio, tipo quando nuovo collega appena arrivato (che per non sbagliarsi chiameremo $CL) senza nemmeno aver visto l'applicativo sul quale deve lavorare propone di rifarlo ex-novo usando un altro framework (evidentemente l'unico che lui conosce).

-- who uses Debian learns Debian but who uses Slackware learns Linux

Daniele C.

@ Guido By Daniele C. posted 12/06/2017 16:10

 

> c'e' di peggio, tipo quando nuovo collega appena arrivato (che per non sbagliarsi chiameremo $CL) senza nemmeno aver visto l'applicativo sul quale deve lavorare propone di rifarlo ex-novo usando un altro framework (evidentemente l'unico che lui conosce).

mmm, a costo di beccarmi una LARTata, mi sento di dover spezzare una lancia a favore di codesto CL. Quantomeno, lui ci ha provato a voler sviluppare con un sistema che lui conosce e, si spera, sappia usare, invece di mettersi a fare i salti mortali per martellare roba in un framework sconosciuto, finendo per fare schifezze... (avendo sviluppato più cose con linguaggi e framework che non conoscevo, so di cosa parto, o se lo so...)

Certo, dal punto di vista dello sviluppo di un programma è impensabile ripartire da zero perché non funziona una cosa (tipo: Ah, guarda, ho una gomma a terra, compero un'altra auto! O_o^), ma credo che a tutti i programmatori sia capitato almeno una volta di prendere in mano un progetto di tempo addietro e di voler ripartire da zero, se non per evitare che ci sia scritto il proprio nome in cima ad ogni file pieno di porcate assurde...

-- "I was watching the London Marathon and saw one runner dressed as a chicken and another runner dressed as an egg. I thought: 'This could be interesting.'" -Paddy Lennox

---

D.


Guido

@ Daniele C. By Guido posted 13/06/2017 11:29

LART-ata non mi permetterei mai, pero' nemmeno io conoscevo icefaces 2 anni fa. Mi son messo li ed ho imparato qualcosa di nuovo... Se avessi avuto quest'altro atteggiamento non avrei imparato ad usare Hibernate, JPA, Spring ed un sacco di altra roba...

Poi dici giusto sul discorso che non si rifa un progetto che funziona, e vorrei aggiungere che e' stato assunto per fare manutenzione non per rifarlo...

<i>ma credo che a tutti i programmatori sia capitato almeno una volta di prendere in mano un progetto di tempo addietro e di voler ripartire da zero, se non per evitare che ci sia scritto il proprio nome in cima ad ogni file pieno di porcate assurde...</i>

Ne ho visti parecchi, pero' dipende da quello che vogliono da te, magarii e' un progetto "moribondo" per il quale non si investe piu' e deve solo "tirare avanti" un altro po' e nessuno vuole spendere soldi nel rifarlo o semplicemente ci sono cose piu' urgenti da fare e non ci sono abbastanza programmatori (aka budget) da dedicare allo scopo... Le ragioni sono molteplici. 

Quindi da una persona che abbia un minimo di competenze, prima di sparare sentenze, mi aspetterei di prendere consapevolezza della situazione.

Il progetto ha dei problemi? Benissimo intanto dimmi quali (e quindi devi entrare nel progetto, nonlo puoi dire senza nemmeno averlo visto). Una volta appurato quello vediamo come si risolvono. Non nego che ci siano delle classi scritte ad minchiam, ma nel nostro caso non risolvi cambiando framework e rifacendo il progetto da 0 ma semplicemente rifattorizzando quelle parti scritte male...

> c'e' di peggio, tipo quando nuovo collega appena arrivato (che per non sbagliarsi chiameremo $CL) senza nemmeno aver visto l'applicativo sul quale deve lavorare propone di rifarlo ex-novo usando un altro framework (evidentemente l'unico che lui conosce).

mmm, a costo di beccarmi una LARTata, mi sento di dover spezzare una lancia a favore di codesto CL. Quantomeno, lui ci ha provato a voler sviluppare con un sistema che lui conosce e, si spera, sappia usare, invece di mettersi a fare i salti mortali per martellare roba in un framework sconosciuto, finendo per fare schifezze... (avendo sviluppato più cose con linguaggi e framework che non conoscevo, so di cosa parto, o se lo so...)

Certo, dal punto di vista dello sviluppo di un programma è impensabile ripartire da zero perché non funziona una cosa (tipo: Ah, guarda, ho una gomma a terra, compero un'altra auto! O_o^), ma credo che a tutti i programmatori sia capitato almeno una volta di prendere in mano un progetto di tempo addietro e di voler ripartire da zero, se non per evitare che ci sia scritto il proprio nome in cima ad ogni file pieno di porcate assurde...

 

--- D.

-- who uses Debian learns Debian but who uses Slackware learns Linux

Gama

By Gama posted 12/06/2017 08:10

Volevo commentare scrivendo qualcosa di intelligente e profondo, poi ho notato che la quantità di profanità che stavo per scrivere mi sarebbe costata un permaban dall'intera rete! cheeky

 

Mi chiedo chi faccia i colloqui a certi soggetti...

-- Tutti abbiamo bisogno di credere in qualcosa... Io credo che mi faro' un'altra birra!

Daniele C.

@ Gama By Daniele C. posted 12/06/2017 16:13

 

>Volevo commentare scrivendo qualcosa di intelligente e profondo, poi ho notato che la quantità di profanità che stavo per scrivere mi sarebbe costata un permaban dall'intera rete! cheeky

Se più persone la pensassero come te, Gama, Internet sarebbe un posto migliore!!!

 

> Mi chiedo chi faccia i colloqui a certi soggetti...

È una cosa che mi chiedo sempre anch'io: devi fare un lavoro X, perché non chiedi a qualcuno che X lo sa fare?

-- "I was watching the London Marathon and saw one runner dressed as a chicken and another runner dressed as an egg. I thought: 'This could be interesting.'" -Paddy Lennox

---

D.


Francesco

By Francesco posted 12/06/2017 11:49

Ma il CL in questione è lo stesso dei disastri precedenti o ne avete un intero zoo?

-- Francesco

Davide Bianchi

@ Francesco By Davide Bianchi posted 13/06/2017 07:20

Ma il CL in questione è lo stesso dei disastri precedenti o ne avete un intero zoo?

SERRAGLIO. Si dice "serraglio"

-- Davide Bianchi

Mirko

@ Davide Bianchi By Mirko posted 13/06/2017 08:35

Io lavoro per un'azienda che sviluppa un SW per la progettazione elettrostrumentale su base SQL Server: penso che quello che hai indicato sia il workflow utilizzato dai miei teutoprogrammatroti per ogni rilascio di release...

@Davide: domenica ero in Autodromo a Monza, e sono giusto passato dal Serraglio: non ci stanno tutti i tuoi CL...

@Gama: anche il tuo diario langue...

-- Mirko

Anonymous Lorenzo

By Anonymous Lorenzo posted 18/06/2017 18:46

Andiamoci piano a dire che CL avrebbe fatto faville a friggere hamburger da McDonald's: secondo me avrebbe fatto esplodere la cucina. :\)

-- Anonymous Lorenzo

GTP

@ Anonymous Lorenzo By GTP posted 14/08/2017 14:59

Andiamoci piano a dire che CL avrebbe fatto faville a friggere hamburger da McDonald's: secondo me avrebbe fatto esplodere la cucina. :\)

Facendo appunto un bel numero di faville :\) -- GTP


10 messages  this document does not accept new posts

Previous Next


This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.


This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.

This site isn't optimized for vision with any specific browser, nor it requires special fonts or resolution.
You're free to see it as you wish.

Web Interoperability Pleadge Support This Project Powered By Gigan