Benvenuti nel Dudes Club Italiano

@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?

@Aethiss said in Parliamo di software 2: Dudeswave:

Seppure rimango della mia idea che con una web (progressive) app full client, si possano strutturare meglio i micro-servizi ed ottimizzare i consumi di questi lato server,

come se fosse antani. Il punto e' che hai un client e un server. Il resto della supercazzola non serve a nulla. Se mi metto sulla rete e sniffo il traffico, non vedo passare niente di tutto questo. Vedo passare traffico. Vedo passare il tuo javascript, come potrei veder passare flash, e come un tempo vedevo passare applet java, e altro e altro e altro.

Se mi dici che puoi mettere il Javascript nel back-end, che poi cosi' una volta arrivato al browser fa il suo lavoro... bhe, che posso dire, in linea mooolto astratta si. Ti vuoi male ma si

non mi voglio affatto male, perche' alla fine anche sul tuo cellulare e' sempre un client che lo fa girare. E ho migliaia di tool a disposizione per fare in modo che la latenza che conta in realta' sia quella del tuo lentissimo schermo da cellulare. Te lo ripeto: se ho un accordo con la telco, metto un netscaler a fare cache direttamente nell'infrastruttura dell' ISP, dove termina il tunnel GPT del tuo cellulare. E praticamente, hai il javascript al massimo della banda.

Cosa mi cambia, alla fine? Quasi il 100% delle automobili "connected mobility" funzionano cosi'. Mica in Javascript.

Il carico sui server cala di pochissimo. Conosco un'azienda di auto che gestisce otto milioni di auto continuamente connesse, ogni volta che sono accese, e non usa javascript, al massimo fa passare del json. E per 8 milioni di auto paga circa 50K/mese al suo cloud.

Davvero pensi che risparmierebbe molto se mettesse il javascript sull'auto, sotto forma di app?

Molti ci hanno provato.
Ci hanno provato e hanno fallito?
Ci hanno provato e sono morti. (cit. Reverenda Madre bene Gesserit, dune) 

Perche'? Perche' la distribuzione di software su dispositivi embedded e' un casino. L'auto parte, scarica il JS , lo esegue in locale comincia la magia.

Del resto, Whatsapp e' scritto in Erlang sul backend, e non mi sembra che abbia particolari problemi di performance.

Ma alla fine, per esempio, il JS di cui parlo nelle auto non e' certo scaricato da un server con node.js, nel caso delle auto e' in Java.

Davvero, non capisco la tua attenzione verso il particolare linguaggio.

@absc un tempo i siti come quello di ferrari li facevano in Flash. Il concetto era lo stesso, ma anziche' scaricare un pezzo di javascript scaricavi un pezzo di flash. Il guaio era che a livello di sicurezza flash era penoso, altrimenti avrebbe probabilmente vinto su javascript.

Perche'?

Perche' a quei tempi tutti sapevano usare flash, e nessuno javascript.

Puoi sempre scrivere questo:

<script type="application/javascript" src="https://example.com/script.js"></script>

e girera' uno script in javascript. Ma se scrivi:

<script type="text/html" src="https://example.com/myrest"></script>

al posto del pulsante ti compare il codice html che vuoi, compreso se serve un altro pulsante.

Ci sono tanti modi per fare quel sito, anche usando object e flash.

Ha vinto javascript perche' i programmatori lo amano di piu', tutto qui.
O meglio, perche' non sanno fare nient'altro.

@Aethiss said in Parliamo di software 2: Dudeswave:

Se poi mi dici e dimostri che, senza javascript, puoi offrire un sito come (esempio) ferrari.com , a costi minori, ed uguale resa finale, cospargo il capo di cenere e ti daro' ragione da oggi fino all'eternita' .

aspetta, stai chiedendo di sapere quanto cala il consumo della CPU dei server se io metto il javascript sul server, con CDN e acceleratori, o sul client come app?

La differenza e' nemmeno misurabile. Se anche metti il javascript sui server, o altri contenuti statici, un'azienda come il gruppo fiat avra' i suoi netscaler direttamente nel DC dell' ISP telefonico, dove termina il tunnel GPT, e non passi nemmeno da internet per scaricarli. Cosi' come li ha BMW, o Porsche, o chiunque altro. Si chiama edge computing.

Tutto quello di cui non fai cache sara' al massimo qualche chiamata ad un API gateway, che non e' possibile mettere in cache, ma appunto, facendo edge computing, non mi raccontare che hai tolto carico sui server se metti il javascript sul client anziche' sul server.

In linea astratta, puoi generare lo stesso javascript del sito usando unbackend erlang: lo fa per esempio Discord, che e' scritta in Elixir, che gira sulla VM di Erlang, come Scala gira su quella Java. E ha una signora UI.

Non capisco davvero questo tuo ignorare l'infrastruttura e concentrarsi sul linguaggio... sei tu, quello che sosteneva che mettere il JS sul client risparmiasse CPU sui server. Che non e' assolutamente vero.

@Aethiss said in Parliamo di software 2: Dudeswave:

O forse c'e' un perche' sui siti moderni si sviluppa con determinate tecnologie ?

o forse perche' si tratta dei sistemi consigliati dai maggiori produttori di telefoni, social network, eccetera?

Per diventare "industry standard" non servono dei razionali.
Ma ti sfido a misurare qualsiasi impatto sulla CPU dei backend, passando con milioni di utenti da browser puro a Vue, o React.
Uno standard di fatto puo' vivere anche semplicemente perche' e' quello che conoscono tutti i programmatori che si trovano sul mercato. Nessuno vuole aspettare mesi per trovare programmatori esperti in Erlang.

Non ho negato che esistano motivi per usare vue o react, ho solo detto che non sono quelli che dici tu. Tutto qui.

@philotette said in Ciao a tutti:

, loro discutono nelle riviste

quindi, se chiamassi questo posto "Rivista dei dudi, o ci mettessi un sottoforum chiamato "Rivista", secondo te verrebbero?

"La rivista del dudeismo letterario" funzionerebbe?

@Bibibibodibibu said in Linkedin:

Metti come esperienza lavorativa pornoattore presso purhub e vedi se non l accetta

non mi dare idee.

@albione un giorno io e un paio di colleghi di security ci siamo coalizzati, e siamo andati dalla nostra team assistant (non sono piu' receptionist) a spiegare cosa sia un attacco sul layer 8. Le abbiamo mostrato anche i video su youtube.

Adesso, da brava tedeschina, blocca questi tentativi con il fare di chi fa una crociata.

@teflon said in DevOps e' solo il termine piu' fallito della storia dell' IT:

A mia esperienza, forzare sviluppatori ad avere oncall per escalation oncall con 30 minuti di ready time risolve il problema - o quanto meno li rende improvvisamente interessati a scrivere roba che funziona.

scordatelo. Il team di devops parte sempre, diciamo, con 10 dev e 10 sistemisti, ognuno che pretende di saper fare il lavoro dell'altro, se non altro almeno nella questione di creare ambienti di test e CI/CD, anche se la CD nessuno sano di mente la utilizza e si fanno ancora i golive schedulati.

E quindi abbiamo il glorioso team di DevOps, che contiene tutti gli skill che la skill matrix richiede.

Poi arriva il cliente. E dice: firmami lo SLA. I prio 1 , anche di notte, hanno dieci minuti per la prima risposta e preanalisi, e un'ora per la soluzione. Altrimenti scalano.

In quel momento, non e' che i dev si sforzeranno di scrivere codice che funziona. Semplicemente, i dev diranno che non fanno callout notturno, perche' poi l'indomani sono stanchi e non sviluppano bene. E quindi saranno esentati dal fare callout notturno. Da quel momento, solo quelli con gli skill di sysadmin saranno papabili, e diventeranno il team di callout. E quindi avrai due team separati, con orari di lavoro separati e procedure diverse:

• un team agile/scrum per i dev, che lavorano dalle 8 alle 17
• un team di sistemisti, che oltre alle CRQ per andare in produzione, si pippano l 24/7 e la reperibilita'.

e DevOps rimane sulla carta.

scene gia' viste ovunque.

@Aethiss

certo che la metti in cache, te lo fa una CDN, o te lo fa il reverse proxy che mette in cache i contenuti static, ed e' qui il punto.

Lo so che mentre i programmatori stanno chiusi nella loro stanzetta e testano il codice su localhost , o su un sistema di sviluppo che non ha niente in mezzo - perche' e' vero, testare coin le cache torna scomodo - si creano il loro mondo di favole ove l'infrastruttura e' trasparente e neutrale.

Ma quando esci dal mondo di favole, scopri che persino il tuo bundle, almeno in parte, lo aggiorni mediante una CDN, e che non passa quasi nessuna differenza - se non per i costi e le latenze della rete mobile - averlo in locale o scaricarlo dalla cdn di turno. Puo' fare differenza di costi sulla rete mobile, se proprio vogliamo, ma sulla CPU dei server, e' praticamente invisibile. I frontend cacheranno con un bel "Vary: User-Agent" e verranno salvati su disco per essere messi in cache.

Tra qualche giorno, appena avro' testato a dovere, mettero' un cache proxy davanti a nodeBB, non so ancora se usero' varnish o nginx, se non squid, e praticamente scaricherai i contenuti solo se sono cambiati. Il resto te lo fornira' come contenuto statico un server.

E servire un contenuto come contenuto statico e' molto diverso da generare il contenuto, che normalmente richiede CPU.

Ripeto, spesso chi fa il codice e' convinto di avere il nulla piatto , trasparente e neutrale tra client e server. Invece, oggi e' letteralmente impossibile farlo, perche' se anche ignori la cache, ti becchi un bel 301, 30x, o simili, e vieni rediretto ad una CDN.

Da quando e' arrivato il mondo mobile, con modelli di costo a consumo, non esistono piu' connessioni trasparenti E neutre.

Il vantaggio che hai avendo il bundle sul telefono, spesso, non e' nemmeno misurabile sui server rispetto al browser.

Ripeto: in situazioni reali. Su localhost (AKA "works on my laptop") o sulla rete di test (AKA: please, operations, no cache we need testing) , ovviamente e' come dici tu. Solo che non e' la realta' in cui vivi quando sei in produzione.

Il problema e' che i developers tendono a creare un mondo di fiabe nella loro stanzetta, e finiscono col meritarsi questo:

https://varnish-cache.org/docs/trunk/phk/notes.html

@Aethiss me ne rendo conto. E sto scancherando non poco. Ma, se solo metto un piccolo nginx con cache di fronte, vedo che il traffico sul backend cala drasticamente, specialmente alla voce "Ragazze sgargianti".

Siamo di nuovo li'. ALla fine non e' VUE che fa calare il traffico....ne' l'uso della CPU.

@Aethiss said in Parliamo di software 2: Dudeswave:

puoi cachare "abc", "123" e quello che vuoi, ma i contenuti sono quelli rilevanti, che sara' il server a fornire. Ad ogni chiamata.

solo se i contenuti cambiano tra una chiamata e l'altra. Altrimenti, anche escludendo le CDN, ci pensa la cache del frontend, bigIP o quant'altro. Ma se c'erano header di cache, succedera' ogni ora, non ad ogni refresh.

abc123 e' il nome dell'etag. Un tempo indicava l' inode del file statico sul server, ora non piu'.

E non c'e' affatto bisogno di rigenerare un contenuto statico, mi spiace. Se non cambia ad ogni click, puoi servirlo da una cache, anche su disco, se proprio detesti le CDN. Quella chiamata non arriverebbe mai al server, dove sta la business logic, si fermerebbe al reverse proxy di frontend.

Adesso mi dirai "ignora anche il proxy di frontend e gli RFC.

E allora, il tuo problema si esprime con:

siamo nel 1984, quando non esistevano CDN, non esistevano frontend proxy, e quando non esistevano gli header HTTP , cioe' nemmeno HTTP.Il nostro client si connette, usando un modem 28800 BAUD, alla BBS, e deve scaricare il file tette.zip dalla libreria "cose zozze". Come faccio una app react?"

E la risposta sara' "usa QWK con rz/sz".

Ma ripeto, nel 2025, avendo le CDN, avendo il cloud, avendo i proxy di frontend, avendo ottimizzatori del TCP come BigIP, avendo gli header cache, l'idea che tu migliori la vita al server solo perche' usi react mi fa alquanto ridere, onestamente.

Header HTTP	Funzione	Livello OSI	Note
Content-Type, Content-Encoding, Content-Language, Content-Transfer-Encoding	Descrizione del formato e codifica del contenuto	6 – Presentazione	Gestione di formato, lingua e codifica dei dati
Content-Length, Transfer-Encoding	Gestione e trasformazione del corpo del messaggio	6 – Presentazione	Controllano come viene interpretato il payload
Authorization, WWW-Authenticate	Autenticazione, avvio di sessione logica	5 – Sessione	Stabiliscono un contesto utente
Set-Cookie, Cookie	Persistenza della sessione utente	5 – Sessione (concettuale)	Permettono sessioni, ma sono header applicativi
Connection, Keep-Alive	Gestione della persistenza della connessione TCP	5 – Sessione	Controllano se tenere aperta la connessione TCP
Host, Referer, User-Agent	Informazioni contestuali sulla richiesta	7 – Applicazione	Header informativi, propri di HTTP
Cache-Control, ETag, Expires, Last-Modified	Gestione semantica della cache	7 – Applicazione	Agiscono solo a livello logico HTTP
Accept, Accept-Encoding, Accept-Language	Preferenze sul formato della risposta	6 – Presentazione	Il client dichiara come preferisce ricevere i dati
Upgrade, Sec-WebSocket-Key, Sec-WebSocket-Accept	Negoziazione per cambio protocollo (es. WebSocket)	5 – Sessione	Implicano transizione di protocollo su TCP
Date, Server, Via	Metadati e diagnostica	7 – Applicazione	Informazioni accessorie

@cicerchia

non so, io ho assistito al fenonemo Fika quando lavoravo per E. Ma onestamente, tutti andavano nella cucina aziendale e mangiavano, tra smorgasbord e tanta roba ad alto tasso diabetogeno.

Ok, se il concetto era "festeggiamo il venerdi' tutti insieme" era ok, ma il mio problema era che, a differenza dei finlandesi che ho amato per quanto sono folli, non riesco a trovare divertente la compagnia degli svedesi. Secondo me, svizzeri, svedesi e danesi sono le persone meno adatte per la convivialita'.

@Aethiss

siamo davvero nel 2025 a discutere del fatto che la cache funziona SOLO dopo la prima volta? E' ovvio che non puoi evitare la prima chiamata.

Ma la foto di tette non cambia, ed e' contenuto statico. Finira' in CDN. Che bisogno hai di programmare ad hoc un client, solo perche'.... boh.

@charlie

e' un fenomeno legato alla "tastiera". Non posso mettermi a certificare il sito per ogni modello di device portatile e per ogni app di tastiera, onestamente.

@Aethiss said in Parliamo di software 2: Dudeswave:

Hai un sito in php, Che cache mandi ?

che tu mi creda o meno, ci sono degli header, menzionati in un posto chiamato RFC, che se ne sbattono il cazzo di che linguaggio usi il tuo sito, e usando etag con i dovuti parametri, possono fare in modo che il tuo client metta in cache una risposta.

RFC 9110 – HTTP Semantics
RFC 9111 – HTTP Caching
RFC 9111 – HTTP Caching
RFC 9110 – HTTP Semantics
RFC 9110 – HTTP Semantics

per esempio

Cache-Control: max-age=3600, must-revalidate
ETag: "abc123"
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

non c'entra se a generare abc123 sia php o erlang, il tuo browser la mette in cache per un'ora. Poi , e solo poi, se la va a riprendere.

E no, non esiste un sitino in php, esiste il client ed esiste il server.

@marcomarco said in scandinavia news:

A Ginevra, basta che rispetti la legge, poi in privato puoi fare quello che vuoi.

e questo implica, come minimo, che i vicini di casa ti spiano con dei microfoni nascosti nel tuo cesso.

@teflon said in Parliamo di software 2: Dudeswave:

maledetto, ci sono cascat

questi vanno:

https://www.theyarehuge.com/

https://www.bigboobspictures.com/busty/

@Aethiss

guarda , tutto questo andava bene, diciamo, fino ai primi del 2000, quando si faceva il "sizing" dei server confrontando domanda e capacita'.

Poi l'uomo bianco ha inventato delle cose.

• I primi programmatori hanno cominciato a chiedersi, per esempio , quante volte cambia il numero di film che fa una pornostar in un anno. In un giorno. In una settimana. E cosi' prima e' arrivata la cache. Un meccanismo fantastico, quasi sconosciuto ai programmatori, che consente di aggiornare molto meno. Ma il programmatore di oggi non legge gli RFC, perche' mai dovrebbe? Non scrive documentazione, figuriamoci se la legge.

• Poi sono arrivati quei bastardi degli architetti di sistema, e la cache ha cominciato ad evolversi , sino a raggiungere il concetto di "CDN".Content delivery Network. Credi davvero che ogni chiamata raggiunga il server di Facebook? Davvero aumenta il load di qualsiasicosa?

• Poi e' arrivato il cloud, ed ecco che puo' addirittura succedere che usi solo le risorse che effettivamente consumi. (se lo fai bene). E puf, tutto questo discorso e' ridondante. Infine il cloud si e' evoluto nei vari SAAS, e oggi si, dell'efficienza del client non frega piu' niente a nessuno.

• Il tutto si e' evoluto, per il settore mobile, in un "edge computing", per cui alla fine dei conti, il tuo server di traffico ne serve davvero poco. Anche quando usi il browser. A meno che tu non VOGLIA fare tutto da server, a carico tuo.

Nel frattempo, pero', il problema era di trasformare in programmatori piu' incompetenti possibile, in modo da abbassare gli stipendi aumentando l'offerta. E cosi' abbiamo i programmatori javascript. Gente che faceva gli effetti speciali nella pagina web delle pizzerie, e adesso parla di UI/UX.

E questo per un semplice motivo: perche' spostare il traffico da server a client ha senso solo se il traffico ti costa pochissimo. Ma tra client e server c'e' la rete, e almeno per il mondo mobile, una rete che costa molto. Quindi, abbassare il costo della capacita' dei server (che costa sempre meno) a spese del traffico mobile - che non e' decisamente economicissimo oggi - ha senso solo quando ha senso.

Ho visto succedere questa cosa tante di quelle volte, ormai, partendo da Java , che non mi preoccupo piu'. Per via di due teoremi.

• ogni tentativo di abbassare il reddito dei programmatori alza il reddito dei sistemisti
• ogni tentativo di abbassare il reddito dei sistemisti alza il reddito dei programmatori

E questi due teoremi sono inamovibili, per una semplice ragione: "informatica" significa che del software gira su dell'hardware. Quello che togli da una parte, va dall'altra.

i fessi che continuano a proporre nuove tecnologie per tagliare i costi, insomma, non fanno altro che, nel lungo termine, alzarti il reddito, che tu sia un sistemista, o un programmatore. A spese di complicarti la vita al lavoro.