Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #22112 > unrolled thread

il ruolo di un validatore

Back to article view | Back to it.comp.www.php

Contents

  il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-25 11:03 +0200
    Re: il ruolo di un validatore fmigliori <fmigliori@gmail.com> - 2018-07-25 02:36 -0700
      Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-25 13:31 +0200
        Re: il ruolo di un validatore fmigliori <fmigliori@gmail.com> - 2018-07-25 05:50 -0700
          Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-25 17:13 +0200
          Re: il ruolo di un validatore enrico bosi <rnsrico@bo.b> - 2018-07-25 17:48 +0200
            Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-25 17:59 +0200
              Re: il ruolo di un validatore fmassei@gmail.com - 2018-07-25 09:53 -0700
    Re: il ruolo di un validatore fmassei@gmail.com - 2018-07-25 08:22 -0700
    Re: il ruolo di un validatore Umberto Salsi <salsi@icosaedro.it> - 2018-07-26 11:54 +0200
      Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-27 09:45 +0200
        Re: il ruolo di un validatore Alessandro Pellizzari <shuriken@amiran.it> - 2018-07-27 10:22 +0100
          Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-27 12:39 +0200
            Re: Re: il ruolo di un validatore Umberto Salsi <salsi@icosaedro.it> - 2018-07-28 13:01 +0200
              Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-29 11:22 +0200
                Re: il ruolo di un validatore Umberto Salsi <salsi@icosaedro.it> - 2018-07-29 12:18 +0200
                  Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-03 07:40 -0700
                    Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-04 09:40 +0200
                      Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-04 05:41 -0700
                  Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-10 19:45 +0200
                    Re: il ruolo di un validatore Umberto Salsi <salsi@icosaedro.it> - 2018-08-27 11:43 +0200
                      Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-30 11:21 +0200
          Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-01 08:26 +0200
            Re: il ruolo di un validatore Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-05 15:51 +0100
              Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-05 18:56 +0200
                Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-05 21:30 +0200
              Re: il ruolo di un validatore enrico bosi <rnsrico@bo.b> - 2018-08-06 16:33 +0200
                Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-06 07:47 -0700
                  Re: il ruolo di un validatore enrico bosi <rnsrico@bo.b> - 2018-08-06 22:47 +0200
                    Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-06 14:59 -0700
          [OT] Re: il ruolo di un validatore g4b0 <g4b0@nospam.com> - 2018-08-03 15:27 +0000
            Re: [OT] Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-03 08:35 -0700
            Re: [OT] Re: il ruolo di un validatore Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-03 18:24 +0100
              Re: [OT] Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-03 17:23 -0700
              Re: [OT] Re: il ruolo di un validatore g4b0 <g4b0@nospam.com> - 2018-08-06 07:52 +0000
                Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-06 10:22 +0100
                  Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) fmassei@gmail.com - 2018-08-06 08:10 -0700
                    Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-06 16:31 +0100
                      Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) fmassei@gmail.com - 2018-08-06 08:39 -0700
                        Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-06 18:03 +0100
                          Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) fmassei@gmail.com - 2018-08-06 10:29 -0700
                            Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-08 15:51 +0100
                              Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 07:02 +0000
                  Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-07 07:50 +0000
                    Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-07 16:30 +0100
                      Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-08 07:06 +0000
                        Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-08 13:27 +0200
                          Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-08 12:39 +0000
                            Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-08 15:13 +0200
                              Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-08 13:44 +0000
                                Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-08 16:15 +0100
                                  Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 06:48 +0000
                        Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-08 16:57 +0100
                          Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 07:00 +0000
                            Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-09 11:28 +0100
                              Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 12:41 +0000
                                Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-09 13:50 +0100
                                  Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 15:27 +0000
                                    Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 15:31 +0000
                                    Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-09 18:23 +0100
                                      Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-10 07:26 +0000
                                        Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-10 10:27 +0100
            Re: [OT] Re: il ruolo di un validatore fmigliori <fmigliori@gmail.com> - 2018-08-03 23:04 -0700
              Re: [OT] Re: il ruolo di un validatore Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-05 16:24 +0100
                Re: [OT] Re: il ruolo di un validatore fmigliori <fmigliori@gmail.com> - 2018-08-05 09:59 -0700
                  Re: [OT] Re: il ruolo di un validatore g4b0 <g4b0@nospam.com> - 2018-08-06 07:17 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#22152 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

On Monday, August 6, 2018 at 1:03:25 PM UTC-4, Alessandro Pellizzari wrote:
> On 06/08/2018 16:39, fmassei@gmail.com wrote:
> 
> > Se hai un progetto di un mese per un team di quattro persone, far perdere
> > cinque minuti o un'ora ad una di queste il primo giorno, non cambia
> > praticamente nulla sullo schedule, anche visto che comunque leggere la
> > documentazione di tale liberia toglie molto più tempo. ;)
> 
> Vero, ma, di contro, posso dirti che ho prototipato microservices in Go 
> nel giro di 2 ore, e in un caso quel prototipo poi è diventato 
> production-ready solo aggiungendo il logging remoto e un po' di gestione 
> degli errori (altre 2-3 ore).
> 
> In mezza giornata ho scritto un app CLI in Rust che mi analizza una 
> directory e calcola gli hash dei file per trovare duplicati. In 
> parallelo su n thread basata sul numero di core della macchina... :)
> 
> In C/C++ non avrei nemmeno finito di scaricare e installare le librerie 
> giuste.
> 

Ma no, questo dipende dal grado di expertise che hai in quel campo e per
quello specifico caso.

Ti posso fare un esempio subito: qualche mese fa ho scritto al volo, in
due ore, un programmino che fa k-mean clustering su video, in Java. Da
zero, perché sapevo l'algoritmo. Chi non lo sa ci mette un'ora solo per
*scaricare* tensorflow o simili.

Ma sarò più preciso tra poche righe.


> > Certo, sarebbe meglio non doverlo fare, ma come sai rimuovere la
> > possibilità
> > di poter configurare manualmente certi pezzi non è considerato accettabile
> > nella maggior parte degli ambienti dove si usa C++.
> 
> Per quello dico che sono dinosauri. :D
> Sono rimasti a uno stile di sviluppo di 20 anni fa, e secondo me la 
> pagheranno nel corto-medio periodo.
> 
> Mi rendo conto che il sistema a microservizi è tipicamente web, e non si 
> applica, per esempio, a microcontrollori o a buona parte delle app 
> desktop, ma ugualmente si potrebbe applicare alla separazione dell'app 
> in librerie: definisci un'API per ogni pezzo dell'app e ogni persona si 
> concentra su quello.
> 
> Ogni pezzo è testabile per conto suo, la struttura dell'app è più 
> pulita, ogni sviluppatore deve tenere in testa meno informazioni.
> 
> Ma senza un sistema di gestione delle dipendenze fai presto a diventare 
> matto, e tendi a continuare a ragionare in monolitico.
> 

Qui si vede che non programmi in C++ da un bel po' :)

10 anni fa, quando ancora scrivevo principalmente in C/C++/C#, già tutti
lavoravano solo con DL, DI, e tutti i metodi di sviluppo che per il web,
all'epoca, sembravano arrivati dal futuro :D
Ma non è strano, se ci pensi: da un lato hai ingegneri preparati e dallo
altro newbies che copiano da stackexchange.

Quello che serve per portare a termine, in poco tempo e al massimo della
qualità, un progetto C++, sono un progettista con le palle e due/tre
programmatori coi peli. Visto che questa gente costa effettivamente tanto,
il management semplicemente decide di tagliare sulla qualità del software
finale.
Non che abbiano torto, eh, anch'io quando do fuori i lavori chiedo a
ragazzini in India.


Ciao!

[toc] | [prev] | [next] | [standalone]

#22168 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

On 06/08/2018 18:29, fmassei@gmail.com wrote:

> On Monday, August 6, 2018 at 1:03:25 PM UTC-4, Alessandro Pellizzari wrote:

>> In C/C++ non avrei nemmeno finito di scaricare e installare le librerie
>> giuste.

> Ma no, questo dipende dal grado di expertise che hai in quel campo e per
> quello specifico caso.

Sicuramente. Ma io avevo 3 mesi di expertise in Go... :)

> Qui si vede che non programmi in C++ da un bel po' :)

Mi dai troppo credito. :)
Non ho mai sviluppato in C++. Lo trovo troppo complesso. Ho cercato di 
impararlo più volte e non sono arrivato a niente.

Ho sviluppato in C per un po'.
Esperienza (recente e meno recente) ce l'ho con tutto il software 
scritto per Linux, e ho ancora gli incubi su autotools e make.
È troppo complicato sia per iniziare che per mantenere un progetto in 
crescita.

Come dici tu: o hai un team di senior o non vale nemmeno la pena iniziare.

Quello che dico io è che sul lungo termine, se non cambia qualcosa, C e 
C++ (e in un secondo tempo Java) perderanno sempre più utenti.

È già iniziato: praticamente tutto il nuovo software opensource per reti 
è scritto in Go. Buona parte del software con UI è scritto in JS con 
Electron.

Bye.

[toc] | [prev] | [next] | [standalone]

#22174 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

Il Wed, 08 Aug 2018 15:51:16 +0100, Alessandro Pellizzari ha scritto:

> Quello che dico io è che sul lungo termine, se non cambia qualcosa, C e
> C++ (e in un secondo tempo Java) perderanno sempre più utenti.

Consiglio: non scrivere mai una frase del genere su i.l.i.: vengono a 
prenderti a casa :D

g4b0

[toc] | [prev] | [next] | [standalone]

#22158 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

Il Mon, 06 Aug 2018 10:22:20 +0100, Alessandro Pellizzari ha scritto:

> On 06/08/2018 08:52, g4b0 wrote:
> 
> Cambiamo il subject, va. :)
> 
>>> PHP non sta rimanendo affatto indietro, rispetto soprattutto a Python
>>> e Ruby. Anzi, sta crescendo a una velocità mostruosa: tipizzazione
>>> forte,
>>> nuova gestione delle eccezioni, performance che crescono ad ogni
>>> versione, ecc.
>> 
>> Questo è vero, sta crescendo, ma l'hype si sta spostando. Essendo un
>> programmatore PHP non vorrei far la fine di chi sviluppava in Flash :)
> 
> Vero. Personalmente mi sono spostato verso Go per lavoro (e Rust per
> hobby, finché non diventa abbastanza trendy per usarlo al lavoro), e
> nell'ultimo anno ho scritto un paio di centinaia di righe di PHP.
> 
> Non perché ritengo PHP pessimo, ma perché il tipo di software che scrivo
> è diverso.

Interessante Rust, ci do un'occhiata.
 
>> Guardandomi attorno le offerte che vedo in giro sono sempre più
>> sbilanciate verso lo stack MEAN piuttosto che LAMP. Sarà una questione
>> di hype, o ci sono dei reali vantaggi ad avere JS spalmato su tutto lo
>> stack?
> 
> Scomponiamo la sigla. :D
> 
> MongoDB vs MySQL/PostgreSQL: hanno usi diversi. Vero che moltissimi
> problemi che la gente risolveva con un DB relazionale si adattano meglio
> a un DocumentDB, magari accompagnato da un KeyValue Store (tipicamente
> Redis). L'importante è sapere quando usare cosa.
 
Chiaro. Devo mantenere delle applicazioni legacy con DB relazionali che 
passando al NOSQL si semplificherebbero non poco, ma ad oggi è ancora 
difficile farlo digerire al management (purtroppo).

> Express+Node vs PHP+framework: sono due modi diversi di affrontare il
> problema. Uno è stateful, l'altro stateless. Uno è asincrono, l'altro
> multiprocesso. I programmatori PHP che non capiscono la differenza sono
> mediamente MENO di quelli JS. :P 

PHP multiprocesso l'ho usato qualche tempo fa in accoppiata con React, 
con un paio di pcntl_fork, un pizzico di shared memory e qualche socket 
sono tornato indietro ai tempi dell'università :D

> Non hai idea di quanti sviluppatori JS ho visto scrivere
> ```
> const data = fetch(...).then(v => v.data); // O quello che era
> console.log(data);
> ```

Un classico. Io per primo ci sono cascato nei miei primi esperimenti con 
JS, e finchè non si entra nell'ottica giusta il codice che si scrive è un 
abominevole schifezza.

> e lamentarsi del server o della connessione perché stampa undefined...
> Poi scoprono async/await e fanno tutto async/await.
> Poi gli mostri i generatori e non capiscono più niente. :P

LOL

> A presumo sia Angular. Tecnologia già morta. Tutti usano React e una
> buona percentuale sta andando verso Vue, abbandonando Angular.
> Praticamente Angular sopravvive in ambienti legacy. E stiamo parlando di
> un framework nato 4-5 anni fa...

Vero, però nelle ricerche dei vari 'head hunter' MEAN la fa da padrone.

> Personalmente preferisco un approccio `[A-Z]+` sia a MEAN che a LAMP:
> usa quello che va meglio per la situazione.

Devo ancora conoscerlo un bodyrentallaro che capisce una regerxp =D

> Lo stack su cui sto lavorando adesso include Go, Elixir, Node+Express,
> Node+Express+React+Next, Nginx+Vue, con script (non web) in PHP e Python
> e sto appunto pensando di introdurre Rust per alcuni servizi che
> richiedono massima stabilità.

E sitcazzi. Lavori da solo o in team? Se proponessi tutta 
quest'abbondanza in ufficio penso che potrei essere linciato!

> Il problema è fossilizzarsi su un unico linguaggio, non su quale
> linguaggio.

Hai ragione, però alle volte il linguaggio ti "piove dall'alto", e non 
puoi farci nulla. Pensa che conosco gente che se la ride sentendo il nome 
MongoDB, per via della sua ovvia assonanaza...

>> JS lo conosco, ci lavoro con Cordova per scrivere app, ed in quel
>> contesto devo dire che non è male. IMO però ha dei gotcha molto più
>> invasivi del PHP, checchè ne dicano gli haters innamorati di nodeJS.
> 
> Una sola domanda: what is this? :P

var self = this;

>> Ho provato anche a smanettarci lato server, sarà che sono abituato a
>> PHP,
>> ma non riesco proprio ad essere produttivo in quel contesto. Infilarmi
>> in una callback hell, oppure scrivere n Promise, solo per
>> leggere/scrivere da un file mi sembra un idiozia. Concordo sui vantaggi
>> di un approccio asincrono, ma IMHO andrebbe usato in contesti dove
>> attendere l'ouput diventa un problema e non a prescindere.
> 
> Per come la vedo io avere codice asincrono esplicito è un bug, non una
> feature, e infatti Go non ne ha bisogno: quando crei una goroutine è il
> runtime che si occupa di interrompere l'esecuzione quando fai IO e
> passarla ad un'altra goroutine. Non ha senso doverne tenere traccia con
> async e await.
> Quando voglio gestirlo esplicitamente mi creo un channel e ci aspetto
> sopra, esponendo sempre una API sincrona.

Interessante.
 
>> Anche i programmatori Java sono haters non male, pressochè tutti quelli
>> di i.l.i. sono programmatori Java che odiano il PHP.
> 
> I programmatori Java sono forse i primi haters della storia dei
> linguaggi di programmazione. :D Loro avevano Sun che gli diceva che
> erano i migliori (e adesso hanno Oracle), e i poveracci che sviluppavano
> in C e C++ non avevano idea di cosa si stessero perdendo.

In effetti sono proprio abbruttiti, non capisco da dove derivi questo 
odio per il resto del mondo. Gliel'ho anche scritto: se non ti piace il 
PHP non usarlo, fine.

> Per come la vedo io sono dinosauri entrambi. Il linguaggio è importante,
> ma l'ecosistema intorno, a partire dai package managers, è quello che fa
> la differenza. Prendi composer, npm, cargo e confrontali con maven e il
> nulla con il Makefile intorno che c'è per C/C++ (e parzialmente Go, per
> ora).

In effetti i colleghi che si occupano di C++ spesso li vedo in difficoltà 
a caccia di bug nascosti dietro a bitmask o processi in deadlock, perchè 
in effetti lavorano ad un monolite gigantesco su cui mettono mano decine 
di sviluppatori, con tanto di kernel custom ed amenità varie. In effetti 
lo sviluppo web è decisamente più snello e moderno, almeno dal mio punto 
di vista

g4b0

[toc] | [prev] | [next] | [standalone]

#22162 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

On 07/08/2018 08:50, g4b0 wrote:

> Interessante Rust, ci do un'occhiata.

Un solo suggerimento: persisti! :D
Ti farà piangere e incazzare per almeno 3-4 mesi. Poi esci dalla pubertà 
e capisci che lo fa per il tuo bene. :)

>> Express+Node vs PHP+framework: sono due modi diversi di affrontare il
>> problema. Uno è stateful, l'altro stateless. Uno è asincrono, l'altro
>> multiprocesso. I programmatori PHP che non capiscono la differenza sono
>> mediamente MENO di quelli JS. :P
> 
> PHP multiprocesso l'ho usato qualche tempo fa in accoppiata con React,
> con un paio di pcntl_fork, un pizzico di shared memory e qualche socket
> sono tornato indietro ai tempi dell'università :D

Non intendevo gestire a mano il multiprocessing, ma proprio che 
apache/nginx/fpm lanciano un processo per ogni richiesta. Non devi 
gestirlo tu a mano, e non devi preoccuparti di liberare risorse o di 
gestire codice asincrono.

> Un classico. Io per primo ci sono cascato nei miei primi esperimenti con
> JS, e finchè non si entra nell'ottica giusta il codice che si scrive è un
> abominevole schifezza.

Been there, done that.
Ma io non mi "vendevo" come "senior frontend developer". :D

> Vero, però nelle ricerche dei vari 'head hunter' MEAN la fa da padrone.

Non so per il mercato italiano. Su quello inglese è praticamente solo 
React, ormai, con qualcuno che chiede anche Angular o Vue.

>> Lo stack su cui sto lavorando adesso include Go, Elixir, Node+Express,
>> Node+Express+React+Next, Nginx+Vue, con script (non web) in PHP e Python
>> e sto appunto pensando di introdurre Rust per alcuni servizi che
>> richiedono massima stabilità.
> 
> E sitcazzi. Lavori da solo o in team? Se proponessi tutta
> quest'abbondanza in ufficio penso che potrei essere linciato!

Grazie per il complimento, ma sono in team. :)
Due frontend, un backend e 2 full-stack (70% backend, 30% frontend).

Io (uno dei due full-stack) mi smazzo Go e node+express, con qualche 
"avventura" in Vue e React.

Elixir ce lo siamo trovato imposto, e solo il backender lo conosce bene. 
Ora stiamo cercando di allargare la conoscenza, visto che non ce lo 
possiamo togliere.

> In effetti i colleghi che si occupano di C++ spesso li vedo in difficoltà
> a caccia di bug nascosti dietro a bitmask o processi in deadlock, perchè
> in effetti lavorano ad un monolite gigantesco su cui mettono mano decine
> di sviluppatori, con tanto di kernel custom ed amenità varie. In effetti
> lo sviluppo web è decisamente più snello e moderno, almeno dal mio punto
> di vista

Questo succede ancora in parecchi casi anche nel backend. I problemi 
sono diversi, con linguaggi dinamici, ma il casino è lo stesso.
Non è ancora diffusissimo il concetto di spezzare i servizi.

Ho avuto difficoltà anche io all'inizio, ma poi quando entri 
nell'ingranaggio non riesci a farne a meno.

Bye.

[toc] | [prev] | [next] | [standalone]

#22163 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

Il Tue, 07 Aug 2018 16:30:45 +0100, Alessandro Pellizzari ha scritto:

> On 07/08/2018 08:50, g4b0 wrote:
> 
>> Interessante Rust, ci do un'occhiata.
> 
> Un solo suggerimento: persisti! :D Ti farà piangere e incazzare per
> almeno 3-4 mesi. Poi esci dalla pubertà e capisci che lo fa per il tuo
> bene. :)

Per ora mi piace molto, anche se la sintassi un po' mi spiazza :D Sto
leggendo The Rust Programming Language, molto interessante per esempio il 
concetto di Enum e Pattern Matching.

>>> Express+Node vs PHP+framework: sono due modi diversi di affrontare il
>>> problema. Uno è stateful, l'altro stateless. Uno è asincrono, l'altro
>>> multiprocesso. I programmatori PHP che non capiscono la differenza
>>> sono mediamente MENO di quelli JS. :P
>> 
>> PHP multiprocesso l'ho usato qualche tempo fa in accoppiata con React,
>> con un paio di pcntl_fork, un pizzico di shared memory e qualche socket
>> sono tornato indietro ai tempi dell'università :D
> 
> Non intendevo gestire a mano il multiprocessing, ma proprio che
> apache/nginx/fpm lanciano un processo per ogni richiesta. Non devi
> gestirlo tu a mano, e non devi preoccuparti di liberare risorse o di
> gestire codice asincrono.

Ah, ok. La gestione di apache/nginx/fpm la davo per scontata, tanto ci
sono abituato. Il progetto di cui parlavo era stato pensato da altri in C,
poi ho proposto di farlo in PHP e non me ne sono per nulla pentito.

>> Un classico. Io per primo ci sono cascato nei miei primi esperimenti
>> con JS, e finchè non si entra nell'ottica giusta il codice che si
>> scrive è un abominevole schifezza.
> 
> Been there, done that.
> Ma io non mi "vendevo" come "senior frontend developer". :D

Fortunatamente neanche io :D Anche perchè alla velocità a cui viaggia il
frontend development oggi essere senior significa lavorare di giorno e
studiare di notte, mi ricorda il php di 10/15 anni fa, con framework che
nascevano e morivano ogni mese. Ed i 10/15 anni in più sul groppone si
sentono tutti :(

>> Vero, però nelle ricerche dei vari 'head hunter' MEAN la fa da padrone.
> 
> Non so per il mercato italiano. Su quello inglese è praticamente solo
> React, ormai, con qualcuno che chiede anche Angular o Vue.

In Italia abbiamo la tradizione di essere indietro di almeno un lustro su
tutto, ma soprattutto la sensazione che ho è che non abbiamo voglia di
evolvere al ritmo imposto dalla tecnologia (web in questo caso).
Imparato uno strumento ce lo teniamo stretto finchè non diventa
anacronistico, pieno di bug o falle di sicurezza.

Ma tu sei in UK? Chissà perchè mi ero fatto l'idea che fossi in Italia,
Nordest per la precisione.

>>> Lo stack su cui sto lavorando adesso include Go, Elixir, Node+Express,
>>> Node+Express+React+Next, Nginx+Vue, con script (non web) in PHP e
>>> Python e sto appunto pensando di introdurre Rust per alcuni servizi
>>> che richiedono massima stabilità.
>> 
>> E sitcazzi. Lavori da solo o in team? Se proponessi tutta
>> quest'abbondanza in ufficio penso che potrei essere linciato!
> 
> Grazie per il complimento, ma sono in team. :)
> Due frontend, un backend e 2 full-stack (70% backend, 30% frontend).
> 
> Io (uno dei due full-stack) mi smazzo Go e node+express, con qualche
> "avventura" in Vue e React.
> 
> Elixir ce lo siamo trovato imposto, e solo il backender lo conosce bene.
> Ora stiamo cercando di allargare la conoscenza, visto che non ce lo
> possiamo togliere.

Azienda grande o piccola? Di sicuro sono aperti a nuove idee, qui si vende
ancora Jquery come tecnologia cutting edge (niente contro a Jquery, mi ha
dato il pane per anni)

>> In effetti i colleghi che si occupano di C++ spesso li vedo in
>> difficoltà a caccia di bug nascosti dietro a bitmask o processi in
>> deadlock, perchè in effetti lavorano ad un monolite gigantesco su cui
>> mettono mano decine di sviluppatori, con tanto di kernel custom ed
>> amenità varie. In effetti lo sviluppo web è decisamente più snello e
>> moderno, almeno dal mio punto di vista
> 
> Questo succede ancora in parecchi casi anche nel backend. I problemi
> sono diversi, con linguaggi dinamici, ma il casino è lo stesso.
> Non è ancora diffusissimo il concetto di spezzare i servizi.

Vero. In effetti il problema del ragionare a Microservices è che bisogna 
entrare nella forma mentis giusta, lasciandosi alle spalle il monolite.
Dopo Rust, o in concomitanza, ci faccio un pensiero.

Grazie per le dritte.

g4b0

[toc] | [prev] | [next] | [standalone]

#22164 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

Il 08/08/2018 09:06, g4b0 ha scritto:
> Fortunatamente neanche io :D Anche perchè alla velocità a cui viaggia il
> frontend development oggi essere senior significa lavorare di giorno e
> studiare di notte, mi ricorda il php di 10/15 anni fa, con framework che
> nascevano e morivano ogni mese. Ed i 10/15 anni in più sul groppone si
> sentono tutti:(

Ma i FW si usano ancora, o ormai si va giù di composer (ormai ogni nuovo 
progetto è perlopiù un assemblaggio di librerie)?

[toc] | [prev] | [next] | [standalone]

#22165 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

Il Wed, 08 Aug 2018 13:27:23 +0200, alex ha scritto:

> Il 08/08/2018 09:06, g4b0 ha scritto:
>> Fortunatamente neanche io :D Anche perchè alla velocità a cui viaggia
>> il frontend development oggi essere senior significa lavorare di giorno
>> e studiare di notte, mi ricorda il php di 10/15 anni fa, con framework
>> che nascevano e morivano ogni mese. Ed i 10/15 anni in più sul groppone
>> si sentono tutti:(
> 
> Ma i FW si usano ancora, o ormai si va giù di composer (ormai ogni nuovo
> progetto è perlopiù un assemblaggio di librerie)?

Laravel per esempio è un framework che tiri giù con composer, il quale 
usa parecchie librerie open. Quindi la risposta è si, si usano ancora, ma 
passando tramite composer. Diffida da chi ti propone di scaricare uno 
zip :)

g4b0

[toc] | [prev] | [next] | [standalone]

#22166 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

Il 08/08/2018 14:39, g4b0 ha scritto:
> Laravel per esempio è un framework che tiri giù con composer, il quale
> usa parecchie librerie open. Quindi la risposta è si, si usano ancora, ma
> passando tramite composer. Diffida da chi ti propone di scaricare uno
> zip:)
> 

Io cmq non ne ho mai usati.
Inizio a scrivere la struttura di base (un semplice 
controller/entrypoint senza complicazioni inutili) e poi via via scarico 
i vendors che servono.

[toc] | [prev] | [next] | [standalone]

#22167 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

Il Wed, 08 Aug 2018 15:13:49 +0200, alex ha scritto:

> Il 08/08/2018 14:39, g4b0 ha scritto:
>> Laravel per esempio è un framework che tiri giù con composer, il quale
>> usa parecchie librerie open. Quindi la risposta è si, si usano ancora,
>> ma passando tramite composer. Diffida da chi ti propone di scaricare
>> uno zip:)
>> 
>> 
> Io cmq non ne ho mai usati.
> Inizio a scrivere la struttura di base (un semplice
> controller/entrypoint senza complicazioni inutili) e poi via via scarico
> i vendors che servono.

Beh, fossi in te un giro su Laravel me lo farei, anche solo per 
didattica. Per esempio ha un ORM di livello (Fluent/Eloquent), se usato 
bene puoi dimenticarti la sintassi di SQL.

Oppure se preferisci roba più leggera puoi provare Silex, anche questo è 
un progetto molto interessante.

g4b0

[toc] | [prev] | [next] | [standalone]

#22170 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

On 08/08/2018 14:44, g4b0 wrote:

> Oppure se preferisci roba più leggera puoi provare Silex, anche questo è
> un progetto molto interessante.

Credo che Silex sia stato deprecato di recente, a favore della nuova 
versione di Symfony che permette di avere un core minimale (in pratica 
quello che era Silex).

Io negli ultimi anni ho fatto praticamente tutto con Slim, che mette a 
disposizione praticamente solo un router e poco altro, ma si smazza 
tutta la parte di PSR-7 e può essere esteso facilmente tramite middleware.

Il tutto via composer.

La parte di routing è solitamente la più difficile da fare bene, quindi 
avere un fw che lo fa per me mi toglie molti problemi.

Bye.

[toc] | [prev] | [next] | [standalone]

#22172 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

Il Wed, 08 Aug 2018 16:15:20 +0100, Alessandro Pellizzari ha scritto:

> On 08/08/2018 14:44, g4b0 wrote:
> 
>> Oppure se preferisci roba più leggera puoi provare Silex, anche questo
>> è un progetto molto interessante.
> 
> Credo che Silex sia stato deprecato di recente, a favore della nuova
> versione di Symfony che permette di avere un core minimale (in pratica
> quello che era Silex).

Silex is in maintenance mode. Ends of life is set to June 2018. Me lo ero 
perso, ultimamente lavoro principalmente con Laravel e Silverstripe 
(quest'ultimo è IMHO il CMS definitvo, learning curve impennata, ma 
quando lo domini ti rende veramente produttivo in determinati tipi di 
lavoro)

> Io negli ultimi anni ho fatto praticamente tutto con Slim, che mette a
> disposizione praticamente solo un router e poco altro, ma si smazza
> tutta la parte di PSR-7 e può essere esteso facilmente tramite
> middleware.

Interessante, ancora più micro di Silex. In effetti è quello che serve, 
poi giù di composer. Anche se per progetti più "strutturati" di norma 
preferisco Laravel, forse è solo questione di abitudine.

> La parte di routing è solitamente la più difficile da fare bene, quindi
> avere un fw che lo fa per me mi toglie molti problemi.

Si, nel 2018 farlo a mano è una follia con tutto il buon codice che c'è 
in giro.

g4b0

[toc] | [prev] | [next] | [standalone]

#22171 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

On 08/08/2018 08:06, g4b0 wrote:

> Per ora mi piace molto, anche se la sintassi un po' mi spiazza :D Sto
> leggendo The Rust Programming Language, molto interessante per esempio il
> concetto di Enum e Pattern Matching.

Quello (assieme a Option e Result e agli iteratori) arriva direttamente 
da Erlang, ma è messo in modo leggibile da chi è abituato alla 
programmazione imperativa più che a quella funzionale pura.

> In Italia abbiamo la tradizione di essere indietro di almeno un lustro su
> tutto, ma soprattutto la sensazione che ho è che non abbiamo voglia di
> evolvere al ritmo imposto dalla tecnologia (web in questo caso).
> Imparato uno strumento ce lo teniamo stretto finchè non diventa
> anacronistico, pieno di bug o falle di sicurezza.

Io continuo nonostante tutto ad aspettare almeno 6 mesi o un anno (o 
più) prima di adottare una nuova tecnologia, proprio perché muoiono più 
velocemente di quanto nascano. Aspettare che ci sia un po' di comunità 
intorno permette di non dover riscrivere tutto ogni anno.

> Ma tu sei in UK? Chissà perchè mi ero fatto l'idea che fossi in Italia,
> Nordest per la precisione.

Lo ero. Mi sono trasferito qualche anno fa.

>> Due frontend, un backend e 2 full-stack (70% backend, 30% frontend).

> Azienda grande o piccola? Di sicuro sono aperti a nuove idee, qui si vende
> ancora Jquery come tecnologia cutting edge (niente contro a Jquery, mi ha
> dato il pane per anni)

jQuery lo usiamo ancora anche noi per i siti più piccoli.

L'azienda è grandina. Questo team è parte di un team più grande (circa 
20 persone) che a sua volta è in un "team di team" (una cinquantina in 
tutto, tra sviluppatori, manager, QA, editors, ...).

Il mercato è parecchio diverso. Ci sono pochissime web-agency. Di solito 
le aziende grosse hanno il team web interno, e quelle piccole si 
affidano a piattaforme già pronte.

Ci si aspetta che uno sia flessibile e che conosca già, almeno un po', 
diversi framework.

Le web-agency che ci sono solitamente fanno anche app mobile.

Bye.

[toc] | [prev] | [next] | [standalone]

#22173 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

Il Wed, 08 Aug 2018 16:57:55 +0100, Alessandro Pellizzari ha scritto:

> On 08/08/2018 08:06, g4b0 wrote:
> 
>> Per ora mi piace molto, anche se la sintassi un po' mi spiazza :D Sto
>> leggendo The Rust Programming Language, molto interessante per esempio
>> il concetto di Enum e Pattern Matching.
> 
> Quello (assieme a Option e Result e agli iteratori) arriva direttamente
> da Erlang, ma è messo in modo leggibile da chi è abituato alla
> programmazione imperativa più che a quella funzionale pura.

Un po' prolisso il libro, eh? Cmq di piacevole lettura. Peccato che non 
ci sia un NG dove discutere di Rust, StackOverflow è troppo "tecnico", mi 
piacerebbe qualcosa di più discorsivo.

>> In Italia abbiamo la tradizione di essere indietro di almeno un lustro
>> su tutto, ma soprattutto la sensazione che ho è che non abbiamo voglia
>> di evolvere al ritmo imposto dalla tecnologia (web in questo caso).
>> Imparato uno strumento ce lo teniamo stretto finchè non diventa
>> anacronistico, pieno di bug o falle di sicurezza.
> 
> Io continuo nonostante tutto ad aspettare almeno 6 mesi o un anno (o
> più) prima di adottare una nuova tecnologia, proprio perché muoiono più
> velocemente di quanto nascano. Aspettare che ci sia un po' di comunità
> intorno permette di non dover riscrivere tutto ogni anno.

Ragionevole, ma cmq non sempre paga. Vedi la mia avventura con Silex :D
Comunque un conto è aspettare un po' ad adottare una tecnologia, un altro 
paio di maniche è continuare a sviluppare in php5 nel 2018 ed usare la 
stessa cautela nei confronti di tutto il parco software.
È vero che l'aggiornamento dei server può spaventare, ma il rientro in 
termini di performace (e non solo) è enorme.

 
> L'azienda è grandina. Questo team è parte di un team più grande (circa
> 20 persone) che a sua volta è in un "team di team" (una cinquantina in
> tutto, tra sviluppatori, manager, QA, editors, ...).
> 
> Il mercato è parecchio diverso. Ci sono pochissime web-agency. Di solito
> le aziende grosse hanno il team web interno, e quelle piccole si
> affidano a piattaforme già pronte.
> 
> Ci si aspetta che uno sia flessibile e che conosca già, almeno un po',
> diversi framework.
> 
> Le web-agency che ci sono solitamente fanno anche app mobile.

LOL, mi hai dato più info tu in 3 frasi che un anno di lurking di i.l.i.

g4b0

[toc] | [prev] | [next] | [standalone]

#22177 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

On 09/08/2018 08:00, g4b0 wrote:

> Un po' prolisso il libro, eh? Cmq di piacevole lettura. 

È stato riscritto di recente per renderlo più discorsivo e adatto ai 
principianti. Online dovresti trovare la v1 che è più di basso livello, 
e copre alcuni argomenti avanzati che sono stati tolti dalla v2.

Anche il libro della O'Reilly è ottimo.

Tieni conto che, anche se quello che stai studiando adesso rimarrà 
valido, per fine anno (la chiamano "edizione 2018") dovrebbero 
stabilizzare un po' di roba che ora è in nightly e che dovrebbe 
semplificare diverse cose.

Non so se la parte di programmazione asincrona riuscirà ad essere 
inclusa nell'edizione "2018" del linguaggio o se slitterà alla "2019", 
ma anche quella sarà una botta che convincerà molti a far uscire nuove 
versioni delle loro librerie.

> Peccato che non
> ci sia un NG dove discutere di Rust, StackOverflow è troppo "tecnico", mi
> piacerebbe qualcosa di più discorsivo.

C'è users.rust-lang.org (e iternals.rust-lang.org per le discussioni sul 
compilatore stesso).

Anche io avrei preferito un ng, ma questo, come forum, è abbastanza decente.

Bye.

[toc] | [prev] | [next] | [standalone]

#22179 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

Il Thu, 09 Aug 2018 11:28:09 +0100, Alessandro Pellizzari ha scritto:

> On 09/08/2018 08:00, g4b0 wrote:
> 
>> Un po' prolisso il libro, eh? Cmq di piacevole lettura.
> 
> È stato riscritto di recente per renderlo più discorsivo e adatto ai
> principianti. Online dovresti trovare la v1 che è più di basso livello,
> e copre alcuni argomenti avanzati che sono stati tolti dalla v2.

In realtà è interessante anche se un po' prolisso, ma non credo che un 
principiante possa trovarsi a suo agio. Tutta la questione sulla gestione 
della memoria non è proprio un concetto basic, se non si è masticato 
almeno un po' di C in passato.
 
> Tieni conto che, anche se quello che stai studiando adesso rimarrà
> valido, per fine anno (la chiamano "edizione 2018") dovrebbero
> stabilizzare un po' di roba che ora è in nightly e che dovrebbe
> semplificare diverse cose.
> 
> Non so se la parte di programmazione asincrona riuscirà ad essere
> inclusa nell'edizione "2018" del linguaggio o se slitterà alla "2019",
> ma anche quella sarà una botta che convincerà molti a far uscire nuove
> versioni delle loro librerie.

Quello che non ho ancora capito di Rust è il dove si posiziona come 
linguaggio, se più a basso livello come C/C++ oppure più in alto tipo Java 
e C#

C'è qualche progetto "importante", oltre a Firefox, che usa Rust?

>> Peccato che non ci sia un NG dove discutere di Rust, StackOverflow è
>> troppo "tecnico", mi piacerebbe qualcosa di più discorsivo.
> 
> C'è users.rust-lang.org (e iternals.rust-lang.org per le discussioni sul
> compilatore stesso).
> 
> Anche io avrei preferito un ng, ma questo, come forum, è abbastanza
> decente.

Ho visto il forum, non male, ma un ng IMO è sempre meglio.

g4b0

[toc] | [prev] | [next] | [standalone]

#22180 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

On 09/08/2018 13:41, g4b0 wrote:

> In realtà è interessante anche se un po' prolisso, ma non credo che un
> principiante possa trovarsi a suo agio. Tutta la questione sulla gestione
> della memoria non è proprio un concetto basic, se non si è masticato
> almeno un po' di C in passato.

Sì, danno un po' per scontato che uno abbia programmato a basso livello 
(C o C++).

> Quello che non ho ancora capito di Rust è il dove si posiziona come
> linguaggio, se più a basso livello come C/C++ oppure più in alto tipo Java
> e C#

A livello di C/C++.

> C'è qualche progetto "importante", oltre a Firefox, che usa Rust?

https://www.rust-lang.org/en-US/friends.html

Credo che i più conosciuti siano npm e Dropbox, ma ci sono diversi 
progetti interessanti in quella lista, e ne mancano alcuni.
Per esempio mi pare che Microsoft abbia iniziato a usarlo su Azure di 
recente, e un paio di giorni fa ripgrep è entrato ufficialmente in Debian.
Io sto usando exa al posto di ls da un po'.

Bye.

[toc] | [prev] | [next] | [standalone]

#22181 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

Il Thu, 09 Aug 2018 13:50:25 +0100, Alessandro Pellizzari ha scritto:

>> Quello che non ho ancora capito di Rust è il dove si posiziona come
>> linguaggio, se più a basso livello come C/C++ oppure più in alto tipo
>> Java e C#
> 
> A livello di C/C++.

Beh, ho appena scoperto Rocket [1]. Se ho ben capito è l'equivalente di 
un microframework PHP, ma scritto in Rust. Una meraviglia :D


[1] https://rocket.rs/

[toc] | [prev] | [next] | [standalone]

#22182 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

Il Thu, 09 Aug 2018 15:27:34 +0000, g4b0 ha scritto:

> Il Thu, 09 Aug 2018 13:50:25 +0100, Alessandro Pellizzari ha scritto:
> 
>>> Quello che non ho ancora capito di Rust è il dove si posiziona come
>>> linguaggio, se più a basso livello come C/C++ oppure più in alto tipo
>>> Java e C#
>> 
>> A livello di C/C++.
> 
> Beh, ho appena scoperto Rocket [1]. Se ho ben capito è l'equivalente di
> un microframework PHP, ma scritto in Rust. Una meraviglia :D
> 
> 
> [1] https://rocket.rs/

Preso dall'entusiasmo ho inviato il post. Volevo dire, quotando quanto 
sopra, che Rust si piazzerà anche a livello di C/C++, ma di queste cose 
scritte in C/C++ non se ne vedono dai tempi del CGI.

g4b0

[toc] | [prev] | [next] | [standalone]

#22183 — Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore)

On 09/08/2018 16:27, g4b0 wrote:

> Beh, ho appena scoperto Rocket [1]. Se ho ben capito è l'equivalente di
> un microframework PHP, ma scritto in Rust. Una meraviglia :D

Rocket è figo, ma mi pare abbia ancora bisogno della nightly del 
compilatore.

Un paio di giorni fa è uscito anche warp, che è basato su un concetto 
più funzionale (composizione di filtri sulla request) e che non mi 
dispiace per niente.

Ma appunto, il grosso è basato su hyper (che è in versione 0.12), che a 
sua volta è basato su futures (0.1) e tokio (0.3, mi pare) per l'async.

Sono versioni che, se uso al lavoro, mi mettono un bersaglio sulla 
schiena e mi puntano costantemente col laser. :D

Questo nonostante siano più stabili di un apollo server qualunque.

Stanno lavorando come matti per implementare tutto, ma ci vorrà ancora 
un pochino, secondo me.

Però le prestazioni sono spaventose. Per static file serve va oltre i 7 
milioni di richieste al secondo, e rimane sopra il milione al secondo 
per JSON:

https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

Bye.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | it.comp.www.php

csiph-web