Se sei qui, sei un dude approvato e certificato dalla Comunita' dei Dudi.
DevOps: tagliamo costi, facciamo fare il lavoro di operations ai programmatori (che non lo sanno fare).
Trunk-based development: Buzzword yadda yadda. Quello che qualsiasi progetto open source negli ultimi 50 anni fa.
Il linux kernel? FreeBSD? OpenBSD? NetBSD? GNU?
Tutto quello e' trunk-based, ma sai com'e': in informatica non ci sono mai abbastanza buzzword.
BTW: si, il forum supporta Markdown alla grande.
Io intendo: App-Js --> XHTTP request (Json) --> aggiorna App-js (no caricamenti, leggi : https://en.wikipedia.org/wiki/Single-page_application ).
Ho capito che parlavi di XMLHttpRequest, ma davvero non c'e' nulla nello stack PHP che ti impedisca di fare lo stesso. Uno script PHP e' giusto quello, uno script PHP. Che sputi fuori HTML o JSON non importa e oltre al classiclo plugin per apache, puoi usarlo tramite fastcgi, o lightspeed se vuoi performance migliori.
Zabbix per dire: ha il front-end scritto in PHP, usa XMLHttpRequest per recuperare i dati da delle API tramite JSON e le API sono esposte tramite PHP.
Hai sempre potuto farlo, che PHP fosse usato perlopiu' per generare HTML prima che XMLHttpRequest fosse la nuova bibbia, e' un altro paio di maniche.
Non ho parlato di node. ne ho parlato solo se confronti un server node ed un server in erlang che ti restituiscono "hello world". Node vince. Ma perde vs Go/Java. Non lo dico io, lo dicono i benchmark. Ma puoi testarlo facile tu stesso.
I benchmark hanno sempre lasciato il tempo che trovano e onestamente, non sono mai stati realistici.
Mettiamoci di mezzo un database, mentre in Erlang uso il suo Mnesia e poi ne riparliamo.
Ma a parte questo, sono molto, molto convinto che confrontassero anche li', modelli diversi. Non puoi confrontare Node che e' single-thread con Erlang, dove di default se usi un qualsiasi web framework o web server, la prima cosa che viene fatta e' spawnare un processo interno per questioni di concorrenza. Inoltre, parliamo di un linguaggio imperativo e mutabile contro un linguaggio funzionale e immutabile.
Un sistema come Node vincera' sempre, su un benchmark "hello world", ma non scalera' allo stesso modo e non avra' le stesse garanzie di latenza. Che non significa essere il piu' veloce, in assoluto, ma fornire le stesse performance in modo consistente, pur avendo un garbage collector. La questione e' molto, molto piu' complessa di un banale benchmark.
Spero sia chiaro il punto.
Bho, sara' che mi sto facendo vecchio. Sara' che lato web o app per cellulari ho usato (in produzione) tutta la storia degli ultimi 25 anni. Quando hai app con un livello di complessita', mole di dati imponente, pagamenti anche... no mi dispiace. Divide et Imperat: Microservizi specifici > Monolite.
E dove sarebbe diverso rispetto all'avere moduli specifici? Badaben che non ho detto no ai servizi, sto dicendo no alla proliferazione incontrollata di microservizi.
Importante: Mi sono reso conto che ho fatto una cosa che odio in generale. E cioe' portare la discussione verso tutto un altro discorso mentre tu parlavi del tuo progetto, e di questo me ne scuso.
Non scusarti per questo. Sono sempre discussioni interessanti! Qui siamo al bar, e non ci prendiamo troppo seriamente.
@absc io hjo appena fatto un rage quit su threads dopo aver passato un pomeriggio di sfogo e visto che purtroppo sta cosa era molto più che pubblica e che instagram l aveva mostrata a tutti i miei clienti
Io ho chiuso l'account qualche mese fa. Ne avevo anche scritto.
Io ho effettivamente trovato lavoro tramite linkedin (anche quello dove sono ora), pero' e' diventato un cesso indescrivibile pieno di gente macho, super duper imprenditori, "vincenti" (che vincono in cosa non si sa) e buzzword per qualsiasi ora del giorno.
Siccome fra un po' vorro' rimettermi a lavorare come freelance, sono indeciso de riaprirne uno, ma tenderei al no e cercare altre soluzioni (tipo xing), oppure anche spammarmi un po' nel fediverso.
Ma linkedin no, e' diventata la calcutta del mondo professionale.
Nello specifico intendo la programmazione ad eventi legata al I/O.
Un conto e' la programmazione ad eventi per gestire cose come: "ho schissato un tasto sulla tastiera", ma per dirmi: "Oh hai dati sun una socket!" no, dovrebbe esserci un processo, o thread, anche bloccante solo per quella socket.
Ci rendiamo conto che la programmazione ad eventi spacciata da nodejs cone "asincrona", e' un retaggio di 50 anni fa, quando stavano a malapena scoprendo come gestire la concorrenza?
Il modello di Go funziona, come anche quello di Erlang (una goroutine/processo per socket/richiesta) e rende tutto piu' semplice e chiaro da gestire.
Mai provato a programmare ad eventi in C? O con quella porcheria di libevent?
@Aethiss said in Parliamo di software 2: Dudeswave:
Ni, se dalla tua descrizione parli di CMS, Blog.. social. Insomma roba accessibile via web.
Erlang fa il suo lavoro. Si. E' un must in quello che fa' ? No. E non e' questione di piacere o non piacereLato back-end Go/Java sono ancora un must. NodeJs gia' con node 18.x.x era a livello lato server di fare un lavoro eccellente sia in tempi di risposta, seppur ancora carente nel consumo delle risorse. Siamo a Node 24.x.x (Se fai tu stesso 2 prove facili facili, nel tuo server casalingo, vedrai che la comparazione e' impietosa).
Non confondere "web" con "infrastruttura". Erlang serve il payload al tuo browser e poi non fa altro che rispondere a delle chiamate HTTP con un processo erlang (processo interno alla BEAM) per richiesta.
Go e Java sarebbero dei must su quali basi, di grazia? Per i web framework? Altrimenti qualsiasi linguaggio che abbia un server web decente funziona, se non si bada esclusivamente alla moda.
E no, l'idea di concorrenza di Node (callbacks) e' una merda che deve morire e male. Troppa gente crede che quello sia un modo scalabile di programmare. Non lo e', fa cacare e ti limita tutto ad un processo su una sola macchina. Go va gia' meglio con le goroutines ed i channels. Erlang va oltre, rendendo tutto trasparente fra un set piu' o meno grande di nodi computazionali connessi in una rete di macchine.
Se vuoi, vai a vedere quanto e' schifoso programmare ad eventi in C e tutti vengono a sbragare su libevent e simili. Sono retaggi del preistorico che porca puttana, nessuno ha il coraggio di urlare: "NO! L'I/O NON BLOCCANTE FICCATEVELO NEL CULO!".
Vedo di spiegarmi meglio. Come scala un app ha molte sfaccettature. Molte volte ho sentito da persone piu' varie che i framework javascript vengono usati per moda. In realta' e' falso. Facebook (che ha tirato fuori React), Google (che ha prodotto Angular), l'hanno fatto per un motivo ben preciso. E cioe' spostare il carico dal server ai client, avere applicazioni web piu' veloci e belle da usare, e delegare le comunicazioni server ai vari microservizi (Json its your friend!). Piu' ne hai, meglio scali, meglio tieni botta per tutte le problematiche relative ai big-data.
Un app web JS comparata a ,ignoriamo Erland, mettiamo php, escludendo per il momento il layer di caching, consuma 1/100 delle risorse lato server. Letteralmente scarichi il js sul tuo browser, ed e' TUTTO client. E se sono 100 utenti a navigare, i 100 con un app in React (ad esempio), parlano con il web server 1 volta, un app php ad ogni pagina che naviga.Poi se si vuole andare piu' nel profondo (sicurezza e/o indicizzazione) , bisogna iniziare a parlare di app isomorfiche (https://en.wikipedia.org/wiki/Isomorphic_JavaScript), ma mi fermo qua' che altrimenti sembra che voglio fare il professore (CHE NON SONO).
Io parlo di scalabilita' lato back-end. Se vuoi spingere la complessita' lato client sei liberissimo di farlo. Quello che io voglio e' aggiungere un nodo, fare un ping, ed averlo a rispondere a richieste in un secondo. Ma andiamo ai tuoi argomenti.
"Spostare carico dal server al client". Mi spieghi allora perche' il mio laptop suda ad usare una qualsiasi app scritta con React o Angular? Non e' che forse, ma dico forse, a questo punto queste applicazioni sarebbero dovute essere native e girare come codice macchina vero e non come un bundle di Javascript obeso dentro un browser web altrettanto obeso?
Puoi spostare la complessita' anche lato client se vuoi, nessuno te lo vieta. Ma se vuoi dati aggiornati dovrai andare dal server, per postarli, o almeno richiederli, no? Dove starebbe la differenza con un'applicazione PHP in questo caso? Non capisco il nesso. Non c'e' scritto da nessuna parte che un'applicazione scritta in PHP lato back-end non possa servire lo stesso Javascript che usi nella tua fantasmagorica app react. PHP risponde a richieste HTTP come una qualsiasi altra tecnologia simile, come e quante volte la tua applicazione contatta il server, esula dalla tecnologia usata.
Non c'e' nulla in PHP di diverso da Node in questo senso. Sono due tecnologie diverse che fanno la stessa cosa.
Una parentesi sui microservizi e JSON: i microservizi devono morire e l'idea che JSON sia un buon formato di interscambio dati deve morire con essi, quando nel 99% dei casi una banale chiamata a funzione sarebbe stata sufficente. Hai mai scritto un parser JSON da zero? Tutti quelli che mi vengono a raccontare che serializzare e deserializzare stringhe UTF-8, incluso l'escaping e' un modo efficente di trasmettere dati fra decine se non centinaia di processi, devono essere malmenati :).
JSON e' una merda e le architetture a microservizio devono morire.
Ah! Un cluster erlang ti da un architettura a microservizio in automatico, inclusa service discovery e senza bisogno di JSON. Ma qui me la tiro dai 
Anzi, ti dico questo. Se per caso vuoi una qualsiasi mano (non nei miei unici 10gg di vacanza adesso ehehe), nei miei limiti di tempo e non, lo faccio con voglia e piacere
Detto questo, ma non c'erano Tette un tempo. Che caxx e' successo ?
Tette nella sezione apposita. Potrebbe essermi utile una mano con il front-end, quella si. Non sono un programmatore web purtroppo!
