Parliamo di software 2: Dudeswave
-
@absc Rinnovo quello che ho gia' detto. Compatibilmente con i miei tempi a disposizione, si, e volentieri. Davvero.
@amigaunicorn
sti cercando di convincermi di una cosa sul quale sono gia' d'accordo.
pero' io punto la luna e tu guardi il dito.Parlando solo di "web", perche' altrimenti cade il discorso. Posso "scaricare" la mia "macchina" dove c'e' il web-server dal lavoro di fornire html ad ogni richiesta ? Si.
Aiuta nel strutturare i miei micro-servizi (login, categorie-dei-mondi-degli-arkonnen, pagamenti o quello che vuoi). Si.
Posso ovviare al carico del lavoro del web-server e del linguaggio che gira sulla macchina (php o chi vuoi) con una CDN. Si. Sarebbe uguale, no. Dipende da cosa fa il "sito", avra' dei costi differenti.
Posso ammortizzare tali costi. Si.Eh no, seppur programmo ancora (mi piace sempre tanto), qualche infrastruttura medio-grande (tipo 40 milioni di sterline al black-friday, 80 milioni di accessi unici in 3 gg [lo so che per quelli grossi davvero sono numeretti eh]) ci ho lavorato. E non per mettere su i css
@Aethiss said in Parliamo di software 2: Dudeswave:
Eh no, seppur programmo ancora (mi piace sempre tanto), qualche infrastruttura medio-grande (tipo 40 milioni di sterline al black-friday, 80 milioni di accessi unici in 3 gg [lo so che per quelli grossi davvero sono numeretti eh]) ci ho lavorato. E non per mettere su i css
non capisco, allora perche' insisti? sai benissimo che una volta fatto il backend, OGGI o spedisci javascript o spedisci JSON. Ma sai anche benissimo che non e' la cosa piu' efficente. Si sono fatte cose ben piu' belle di quel sito ferrari usando flash, ai suoi tempi.
Solo che flash ha perso.
Parlando di html, non hai bisogno di renderizzarlo ogni volta. Lo puoi renderizzare per user-agent, e a quel punto la cache non ti richiedera' di renderizzarlo ogni volta. Cosa cambia se la renderizzi con una macchina virtuale node.js o con una che lavora con erlang?
-
@absc Rinnovo quello che ho gia' detto. Compatibilmente con i miei tempi a disposizione, si, e volentieri. Davvero.
@amigaunicorn
sti cercando di convincermi di una cosa sul quale sono gia' d'accordo.
pero' io punto la luna e tu guardi il dito.Parlando solo di "web", perche' altrimenti cade il discorso. Posso "scaricare" la mia "macchina" dove c'e' il web-server dal lavoro di fornire html ad ogni richiesta ? Si.
Aiuta nel strutturare i miei micro-servizi (login, categorie-dei-mondi-degli-arkonnen, pagamenti o quello che vuoi). Si.
Posso ovviare al carico del lavoro del web-server e del linguaggio che gira sulla macchina (php o chi vuoi) con una CDN. Si. Sarebbe uguale, no. Dipende da cosa fa il "sito", avra' dei costi differenti.
Posso ammortizzare tali costi. Si.Eh no, seppur programmo ancora (mi piace sempre tanto), qualche infrastruttura medio-grande (tipo 40 milioni di sterline al black-friday, 80 milioni di accessi unici in 3 gg [lo so che per quelli grossi davvero sono numeretti eh]) ci ho lavorato. E non per mettere su i css
Posso "scaricare" la mia "macchina" dove c'e' il web-server dal lavoro di fornire html ad ogni richiesta ? Si.
Aiuta nel strutturare i miei micro-servizi (login, categorie-dei-mondi-degli-arkonnen, pagamenti o quello che vuoi). Si.
Posso ovviare al carico del lavoro del web-server e del linguaggio che gira sulla macchina (php o chi vuoi) con una CDN. Si. Sarebbe uguale, no. Dipende da cosa fa il "sito", avra' dei costi differenti.
Posso ammortizzare tali costi. Si.Io a questo punto fallisco nel capire cosa c'entri il linguaggio di programmazione usato per la parte back-end. Sul serio, non ci arrivo.
Erlang lo uso per il back-end, per servire risorse e in teoria nessuno mi vieterebbe di costruire una SPA con un back-end Erlang, usando cowboy come webserver.
Un altro punto che non comprendo: dove andrebbe a prendere il bundle del codice dell'applicazione il browser web dell'utente se non dal mio back-end? Una qualche CDN? Dove?
Un'ascia e' per sempre
-
Posso "scaricare" la mia "macchina" dove c'e' il web-server dal lavoro di fornire html ad ogni richiesta ? Si.
Aiuta nel strutturare i miei micro-servizi (login, categorie-dei-mondi-degli-arkonnen, pagamenti o quello che vuoi). Si.
Posso ovviare al carico del lavoro del web-server e del linguaggio che gira sulla macchina (php o chi vuoi) con una CDN. Si. Sarebbe uguale, no. Dipende da cosa fa il "sito", avra' dei costi differenti.
Posso ammortizzare tali costi. Si.Io a questo punto fallisco nel capire cosa c'entri il linguaggio di programmazione usato per la parte back-end. Sul serio, non ci arrivo.
Erlang lo uso per il back-end, per servire risorse e in teoria nessuno mi vieterebbe di costruire una SPA con un back-end Erlang, usando cowboy come webserver.
Un altro punto che non comprendo: dove andrebbe a prendere il bundle del codice dell'applicazione il browser web dell'utente se non dal mio back-end? Una qualche CDN? Dove?
@absc said in Parliamo di software 2: Dudeswave:
Io a questo punto fallisco nel capire cosa c'entri il linguaggio di programmazione usato per la parte back-end. Sul serio, non ci arrivo.
@amigaunicorn sostiene, che un servizio che gira (node, php o quello che vuoi) che deve fornire dell'html (ripeto questo punto eh, un servizio web, che ritorna un html bello pronto che il tuo browser ti mostra), con i dovuti "accorgimenti" (cdn) non debba essere "chiamato" dinamicamente ad ogni sezione.
Io dico che si, e' vero, ma una cdn non ha senso che cachi tutto. Io dico che un app js, una volta ricevuto il bundle js (sempre di "servizio" in un server che restituisce, un html), e' piu' performante, e non ti serve richiamare quel servizio ad ogni pagina.E' pur sempre vero, come altresi' fatto notare da @amigaunicorn , che puoi scrivere
<html> <script type='text/javascript' src='il-path-del-mio-js'></script> ....ed ottieni (se vuoi) lo stesso risultato. Io sostengo che a quel punto ci sono framework (aimhe' in quel linguaggio di merda che e' js), che gia' lo fanno, e lo fanno meglio. Tutto qui' .
-
@absc said in Parliamo di software 2: Dudeswave:
Io a questo punto fallisco nel capire cosa c'entri il linguaggio di programmazione usato per la parte back-end. Sul serio, non ci arrivo.
@amigaunicorn sostiene, che un servizio che gira (node, php o quello che vuoi) che deve fornire dell'html (ripeto questo punto eh, un servizio web, che ritorna un html bello pronto che il tuo browser ti mostra), con i dovuti "accorgimenti" (cdn) non debba essere "chiamato" dinamicamente ad ogni sezione.
Io dico che si, e' vero, ma una cdn non ha senso che cachi tutto. Io dico che un app js, una volta ricevuto il bundle js (sempre di "servizio" in un server che restituisce, un html), e' piu' performante, e non ti serve richiamare quel servizio ad ogni pagina.E' pur sempre vero, come altresi' fatto notare da @amigaunicorn , che puoi scrivere
<html> <script type='text/javascript' src='il-path-del-mio-js'></script> ....ed ottieni (se vuoi) lo stesso risultato. Io sostengo che a quel punto ci sono framework (aimhe' in quel linguaggio di merda che e' js), che gia' lo fanno, e lo fanno meglio. Tutto qui' .
no, piano con gli straw man argument. Con me non funzionano.
Sei tu che te ne sei uscito col fatto che se usi il bundle javascript, allora tutto il lavoro si sposta dalla CPU del server alla CPU del mobile.
Ed e', ripeto, una catastrofica cazzata, della quale non riuscirai MAI, per OVVIE ragioni, a produrre alcuna prova o test che lo confermi, nel caso ci sia un'infrastruttura decente, con gli acceleratori nel frontend e le CDN.Generare HTML o generare JSON, di cui la tua "bundle" si nutre, per una CPU e' uguale, in termini di sforzo, o quasi. E non voglio parlare di quando usate dei cazzo di graph database sul backend , o Jquery, e nessuno dei due gira sul frontend. Che differenza faccia, secondo te, per la CPU del server tra generarti pagine web statiche o json, lo sai solo tu.
Poi, dentro la tua stanzetta di developers puoi usare i soliti termini mai definiti, tipo 'ottimizzare". Noi di operations invece parliamo di KPI,
e no, non si e' mai vista traccia, sulle CPU dei server, di alcuna "ottimizzazione", se scarichi il bundle da una CDN, o ce l'hai che gira sul cellulare.Quella e' soltanto l'unica tecnologia che il developer moderno sa usare, sull'unico protocollo che conosce parzialmente, cioe' HTTP. Ed e' per questo che va forte.
“Il deuterio è come il Grana Padano”. (J.R.Oppenheimer)
-
undefined philotette referenced this topic
-
no, piano con gli straw man argument. Con me non funzionano.
Sei tu che te ne sei uscito col fatto che se usi il bundle javascript, allora tutto il lavoro si sposta dalla CPU del server alla CPU del mobile.
Ed e', ripeto, una catastrofica cazzata, della quale non riuscirai MAI, per OVVIE ragioni, a produrre alcuna prova o test che lo confermi, nel caso ci sia un'infrastruttura decente, con gli acceleratori nel frontend e le CDN.Generare HTML o generare JSON, di cui la tua "bundle" si nutre, per una CPU e' uguale, in termini di sforzo, o quasi. E non voglio parlare di quando usate dei cazzo di graph database sul backend , o Jquery, e nessuno dei due gira sul frontend. Che differenza faccia, secondo te, per la CPU del server tra generarti pagine web statiche o json, lo sai solo tu.
Poi, dentro la tua stanzetta di developers puoi usare i soliti termini mai definiti, tipo 'ottimizzare". Noi di operations invece parliamo di KPI,
e no, non si e' mai vista traccia, sulle CPU dei server, di alcuna "ottimizzazione", se scarichi il bundle da una CDN, o ce l'hai che gira sul cellulare.Quella e' soltanto l'unica tecnologia che il developer moderno sa usare, sull'unico protocollo che conosce parzialmente, cioe' HTTP. Ed e' per questo che va forte.
@amigaunicorn said in Parliamo di software 2: Dudeswave:
. E non voglio parlare di quando usate dei cazzo di graph database sul backend , o Jquery, e nessuno dei due gira sul frontend.
Sinceramente non so che intendi. Forse graphql? JQuery, se intendiamo la stessa cosa, cosa centri con il back-end non lo so. Forse intendiamo cose diverse.
Sul resto…Bho, come ho detto qualche post fa, non sono d’accordo, ma rispetto la tua competenza e le tue posizioni.
Io dovevo “gestire” un e-commerce con migliaia di items.
Ho sbattuto la testa sui costi/configurazione della cdn (Akamai). Io ero un supervisore, gli esperti ci mettevano le mani. Il sito mobile era un app in react, il desktop era ancora un vecchio mix di php e amenie varie.
Diciamo che 2 o 3 cose le ho viste su come dovevano scalare i server a seconda del carico.
Forse eravamo scarsi noi, tutto può essere. -
@amigaunicorn said in Parliamo di software 2: Dudeswave:
. E non voglio parlare di quando usate dei cazzo di graph database sul backend , o Jquery, e nessuno dei due gira sul frontend.
Sinceramente non so che intendi. Forse graphql? JQuery, se intendiamo la stessa cosa, cosa centri con il back-end non lo so. Forse intendiamo cose diverse.
Sul resto…Bho, come ho detto qualche post fa, non sono d’accordo, ma rispetto la tua competenza e le tue posizioni.
Io dovevo “gestire” un e-commerce con migliaia di items.
Ho sbattuto la testa sui costi/configurazione della cdn (Akamai). Io ero un supervisore, gli esperti ci mettevano le mani. Il sito mobile era un app in react, il desktop era ancora un vecchio mix di php e amenie varie.
Diciamo che 2 o 3 cose le ho viste su come dovevano scalare i server a seconda del carico.
Forse eravamo scarsi noi, tutto può essere.stai mescolando cose che non c'entrano niente. Il database di backend di un sito di e-commerce di certo non gira sul tuo cellulare. gira sul backend. qualsiasi cosa tu metti sul cellulare chiamera' indietro per avere dei dati. Il punto e' molto semplice: alla fine il server consuma CPU solo per dare dei dati a qualsiasi cosa giri sul cellulare. E non c'e' modo di fuggire da questo.
Ma a questo punto ho un dubbio: secondo te, cosa gira sul cellulare, di preciso, e cosa gira sui backend? Che cosa, secondo te, consuma CPU sui server, e che cosa sul client?
“Il deuterio è come il Grana Padano”. (J.R.Oppenheimer)
-
stai mescolando cose che non c'entrano niente. Il database di backend di un sito di e-commerce di certo non gira sul tuo cellulare. gira sul backend. qualsiasi cosa tu metti sul cellulare chiamera' indietro per avere dei dati. Il punto e' molto semplice: alla fine il server consuma CPU solo per dare dei dati a qualsiasi cosa giri sul cellulare. E non c'e' modo di fuggire da questo.
Ma a questo punto ho un dubbio: secondo te, cosa gira sul cellulare, di preciso, e cosa gira sui backend? Che cosa, secondo te, consuma CPU sui server, e che cosa sul client?
@amigaunicorn said in Parliamo di software 2: Dudeswave:
stai mescolando cose che non c'entrano niente. Il database di backend di un sito di e-commerce di certo non gira sul tuo cellulare. gira sul backend.
Scusa, mi trovi dove mai ho scritto questo ?
@amigaunicorn said in Parliamo di software 2: Dudeswave:
Ma a questo punto ho un dubbio: secondo te, cosa gira sul cellulare, di preciso, e cosa gira sui backend? Che cosa, secondo te, consuma CPU sui server, e che cosa sul client?
sul cellulare, ma sarebbe piu' appropriato dire sul browser, e' indifferente mobile o desktop. (sempre web eh, non stavo parlando di app native), gira solo html & javascript. Niente altro.
forse ha tratto in inganno quando ho scritto "sito mobile". Spiego meglio, quando un browser accedeva sul sito, veniva intercettata la richiesta, se era un dispositivo mobile, gli si dava in pasto un app in react, ottimizzata per l'uso in un browser di un cellulare, altrimenti andava sulla versione legacy.
-
@amigaunicorn said in Parliamo di software 2: Dudeswave:
stai mescolando cose che non c'entrano niente. Il database di backend di un sito di e-commerce di certo non gira sul tuo cellulare. gira sul backend.
Scusa, mi trovi dove mai ho scritto questo ?
@amigaunicorn said in Parliamo di software 2: Dudeswave:
Ma a questo punto ho un dubbio: secondo te, cosa gira sul cellulare, di preciso, e cosa gira sui backend? Che cosa, secondo te, consuma CPU sui server, e che cosa sul client?
sul cellulare, ma sarebbe piu' appropriato dire sul browser, e' indifferente mobile o desktop. (sempre web eh, non stavo parlando di app native), gira solo html & javascript. Niente altro.
forse ha tratto in inganno quando ho scritto "sito mobile". Spiego meglio, quando un browser accedeva sul sito, veniva intercettata la richiesta, se era un dispositivo mobile, gli si dava in pasto un app in react, ottimizzata per l'uso in un browser di un cellulare, altrimenti andava sulla versione legacy.
@Aethiss ma non hai risposto alla domanda. cosa fa la app, di preciso, per consumare la CPU sul cellulare?
Perche' sinora stai descrivendo quello che IO ho cercato di dire, ovvero che qualcuno legge il tuo user-agent della chiamata http, e gli fornisce un contenuto statico. Va bene ma in che modo questo ti ha salvato CPU sui server? Nel senso che, cosa fanno i server, di preciso, per consumare CPU, che adesso non consumano piu' perche' hai il javascript sul client?
“Il deuterio è come il Grana Padano”. (J.R.Oppenheimer)
-
@Aethiss ma non hai risposto alla domanda. cosa fa la app, di preciso, per consumare la CPU sul cellulare?
Perche' sinora stai descrivendo quello che IO ho cercato di dire, ovvero che qualcuno legge il tuo user-agent della chiamata http, e gli fornisce un contenuto statico. Va bene ma in che modo questo ti ha salvato CPU sui server? Nel senso che, cosa fanno i server, di preciso, per consumare CPU, che adesso non consumano piu' perche' hai il javascript sul client?
@amigaunicorn sembra quasi che io sia qua a rispondere perche' voglio avere ragione. Se mi conoscessi, io amo essere nel torto. Vuol dire che e' il momento in cui imparo qualcosa.
Mi rendo conto che per rispondere con cura devo fare un wall of text.
Se mi dici, fallo. Lo faccio. -
@amigaunicorn sembra quasi che io sia qua a rispondere perche' voglio avere ragione. Se mi conoscessi, io amo essere nel torto. Vuol dire che e' il momento in cui imparo qualcosa.
Mi rendo conto che per rispondere con cura devo fare un wall of text.
Se mi dici, fallo. Lo faccio.senti, sono ore che mi sbrodoli addosso buzzwords. Adesso voglio capire cosa volevano dire. Perche' dall'inizio del thread io ti sto dicendo che alla fine non risparmi nessuna CPU nel backend scaricando dalla rete un javascript, e finalmente dopo qualche domanda apprendo che effettivamente la tua soluzione comprende di far scaricare il javascript dalla rete, soltanto uno diverso a seconda dell' header User-Agent.
Che e' quello che sto cercando di dire sin dall'inizio del thread. Credi davvero che scaricare una cosa da un filesystem faccia crescere la CPUoccpata? No , perche' su Linux il filesystem e' sotto cache, e quindi, alla fine legge da memoria e serve indietro, che e' di fatto una print.
E allora dov'e', di preciso, che usare questastrategia ti fa risparmiare CPU sui server, di preciso?
“Il deuterio è come il Grana Padano”. (J.R.Oppenheimer)
-
senti, sono ore che mi sbrodoli addosso buzzwords. Adesso voglio capire cosa volevano dire. Perche' dall'inizio del thread io ti sto dicendo che alla fine non risparmi nessuna CPU nel backend scaricando dalla rete un javascript, e finalmente dopo qualche domanda apprendo che effettivamente la tua soluzione comprende di far scaricare il javascript dalla rete, soltanto uno diverso a seconda dell' header User-Agent.
Che e' quello che sto cercando di dire sin dall'inizio del thread. Credi davvero che scaricare una cosa da un filesystem faccia crescere la CPUoccpata? No , perche' su Linux il filesystem e' sotto cache, e quindi, alla fine legge da memoria e serve indietro, che e' di fatto una print.
E allora dov'e', di preciso, che usare questastrategia ti fa risparmiare CPU sui server, di preciso?
@amigaunicorn okies, ci mettero' un po', per descrivere con cura la mia esperienza a riguardo (nel post successivo scrivo tutto nel dettaglio)... coming...
-
Per spiegare nel dettaglio cosa intendo nel consumare meno risorse lato server, utilizzo una (delle tante) esperienza lavorativa che ho avuto nella mia carriera.
Nell'anno del signore 2015, vengo assunto come programmatore senior, per una multinazionale che vendeva (per lo piu') indumenti online, fatturato di varie centinaia di milioni di sterline l'anno, con vari marchi, ognuno dei quali con il suo sito.
Scrivevamo un applicazione, che doveva essere sfruttata per gli utenti che si connettevano al sito web tramite cellulare.
Se si accedeva da un portatile, rispondeva il sito "legacy", di cui, al tempo, non era di mia competenza.Il vantaggio, era che se si andava in uno dei qualsiasi siti (erano 7 brand diversi) era sempre la stessa applicazione che rispondeva, e renderizzava i contenuti in base a quale richiesta (leggi url) veniva fatta. Applicazione isomorfica in React (https://en.wikipedia.org/wiki/Isomorphic_JavaScript)
Perche' un applicazione isomorfica ? Perche' ogni singolo prodotto (un jeans, una scarpa) doveva essere indicizzata. E cioe', un motore di ricerca doveva vedere l'html bello che pronto senza alcun javascript, di cui non tiene conto. (E' ancora cosi' ? penso di si).
Tagliando corto, sono diventato lead developer, e poco dopo Principal Lead developer. Cosa comportava ? Tanti cazzi, riportavano a me tutti team di programmatori (circa 50-60), il team di dev-ops etc. Ma soprattutto la responsabilita' di portare la versione "legacy" (chiamiamola per semplicita', versione Desktop) al pari di quella mobile.
L'infrastruttura:
-
Akamai era il servizio che usavamo per la cdn e qualche altra cosa che ora non ricordo.
-
Il servizio Node (App isomorfica), girava su macchine (EDIT: scrivo meglio) in aws ec2 (regole di scaling e tutto quello che serve).
-
Il Database era un servizio offerto da una grossa compagnia indiana, Cognisant (https://www.cognizant.com/us/en/industries/information-services-digital-solutions). In realta' fornivano il servizio completo, e cioe' tutta la parte rest per interfacciarsi con il loro database, fatto apposta per e-commerce (a detta loro).
-
Il servizio per i pagamenti, non ho memoria di come si chiamasse, era ovviamente anche esso esterno, e fuori dalla mia giurisdizione (come per la parte DB)
Quando si accedeva al sito, cosa doveva sputare indietro l'applicazione Node/React, tante cose.
Ad esempio il content della pagina iniziale, che era servito da un micro-servizio sul quale lavoravano i designer, creava un html, e ce lo dava in pasto. La lista dei prodotti piu' importanti, e gia' qua' c'e' un primo scoglio. La lista dei prodotti piu' importanti, NON e' uguale per tutti.
Esempio: io e tu accediamo nello stesso momento allo stesso sito. Ci sono cookie, soprattutto se era gia' stato loggato ed avevi/o gia' acquistato, sa la mia/tua eta', sa i miei/tuoi gusti, e deve darci come primi "vestiti" quelli che si pensa siano tra i nostri preferiti, ed altre cose simili, come ad esempio se ho qualcosa salvato nella lista dei preferiti, il sistema decide se fartelo vedere in sconto o no.
Tutto questo, nella applicazione Desktop, veniva fatto durante la richiesta, direttamente dal php. La quale comunicava con il database gestito dagli indiani, e ritornava i risultati al browser che aveva fatto accesso al sito. Lo stesso valeva per un qualsiasi Item (scarpa, sciarpa o quello che volete), se qualcuno ti mandava un link, tu potevi/dovevi accedere a quella specifica pagina, e non solo vedere quella bella sciarpa, ma anche cosa altro poteva piacerti di simile (e no, non era uguale per tutti. Sembra una cosa stupida, ma su milioni di accessi, queste cose in termini di resa finale di $$, fanno una bella differenza).
Quando ho avuto l'incarico di gestire anche la parte "Desktop", ho lavorato tanto con i dev-ops e gli esperti di Akamai per cercare di cachare il piu' possibile, ma aimhe', quello qua' sopra spiegato, era un grosso limite, e spesso si faceva piu' danno che altro.Comparando le 2 applicazioni ("mobile" e "desktop"), ho potuto vedere il carico sui server web della versione php e della versione React/Node.
Per capirci, e dare 2 numeri, fatto X il numero di persone che accedevano in un minuto, la macchina dove girava il servizio React/Node poteva reggere un numero X * 5 di utenti, rispetto alle macchine dove girava l'applicazione php (e mi tengo basso), prima di iniziare a scalare su un nuovo server.
Inoltre, quando un utente accedeva al sito "Desktop", ogni navigazione, aveva l'effetto sopra spiegato, ripeto: vedo scarpa, dammi tutte le scarpe che possono piacere a me relativa a quella (ed altro che non ricordo), e tutto questo veniva fatto via php, e cioe' lato server appunto.
L'applicazione React/Node, una volta servita la prima pagina, tutto il resto della navigazione, non parlava piu' con la macchina dove girava il server Node dell'app isomorfica, ma semplicemente diceva al servizio di cognisant (dammi questo ItemID, sono l'utenteID), e avevo lo stesso risultato.
Client -> Micro-servizio -> Client.Quando c'era un evento particolare, i numeri di accessi e di navigazione, si moltiplicavano a dismisura, ed ho visto con i miei occhi, cluster di server per l'applicazione php, nell'ordine di 100 a 1 rispetto a quella React/Node.
Era un buona architettura ? No, era una merda, ma purtroppo, nel mondo reale bisogna adattarsi a cose gia' esistenti, contratti di anni gia' definiti (mazzette??) etc etc.
Le nostre conoscenze erano scarse nel saper configurare una CDN come dio vuole ? Puo' Essere, ma caxx, abbiamo pagato della gente di Akamai, ore ed ore di meeting, dove spiegavamo la nostra infrastruttura, i nostri problemi etc etc.Comunque, dopo poco tempo, ho fatto fare dei cambiamenti (il lavoro maggiore alla fine era, non scherzo, css e design) ed abbiamo adattato la versione Node/React anche per essere correttamente visible su un browser da portatile/desktop.
Una sola app, serviva 7 brand, salvava centinaia di migliaia di sterline l'anno solo di costi per i server web.
Ovviamente il mio lavoro era anche quello di garantire tutti i processi della piramide di Test. Il corretto funzionamento/implementazione della CI , dal localHost, passando per develop, pre-prod, ed infine produzione.
Piccola Nota di Colore: Usciva la seconda stagione di Stranger Things. Mega evento al centro di Londra con quella caxxo di bambina protagonista, televisioni etc etc.
Era un giovedi', io dovevo andare ad un matrimonio fuori ferrara, mia moglie mi aspettava la sera all'aereporto di Bologna.
Dovevamo mandare in prod una serie di aggiornamenti (mandi in produzione, di venerdi'????), cosa poteva mai andare storto ?
Al sabato, mentre sto sorseggiando vinello da qualche parte in una villa intorno a ferrara, nel mio cellulare iniziano ad apparire tanti allarmi, e chiamate .... e.
Per farla breve, avevamo inserito un bug nei pagamenti visa, soldi persi "stimati", circa 2 milioni di sterline.Evviva gli sposi
-
