• Off-topic
  • Programmare in PHP nel 2021 ha senso o no?

eutampieri Si si so di $_SERVER, ma in realtà ho avuto problemi a prendere alcuni dati da lì... e comunque non è neanche bello come viene fatto in php

Per la compilazione non strict si ogni tanto da fastidio.... Ma non lo reputo il problema principale

dadadani
Quindi a che linguaggio ti daresti adesso per lo sviluppo web ?
Quali sono le soluzioni più moderne ?

    il vero problema è che ormai non ha più senso essere full stack

      dadadani riscrivere tutto dipende da quanto sia il tutto.... C'è chi (pochi ma grossi) continua a usare motori applicativi in cobol per non riscrivere tutto, vedi te...

        DE8 Ora il fatto che mi sono definito fullstack è dovuto ad una serie di cose, non è il lavoro della mia vita e come già detto a breve mi occuperò di altro (alla fine il CV non si compila da solo e l'esperienza senza CV non conta), ho fatto tanti lavoretti nel corso degli ultimi anni. Ma attualmente è quello che paga di più.

        • DE8 ha messo mi piace.

        Alfoele C'è chi (pochi ma grossi) continua a usare motori applicativi in cobol per non riscrivere tutto

        😱

        • [cancellato]

        • Modificato

        Alfoele Non così pochi e non solo così grossi, purtroppo.

        Fun fact: praticamente tutte le banche (ad eccezione a quanto so di Banca Sella) hanno ancora tutto il "core" che gira su mainframe. Tutte le applicazioni terminali o home banking sbrilluccicoso altro non sono che appendici che richiamano funzioni al MF.

          [cancellato] Aggiungo anche back end di società come coop che girano su COBOL!

          Carrellata di risposte in arrivo

          simonebortolin Legacy anche perché non vengono utilizzati i comuni sistemi CI/CD ma semplicemente un caricamento via FTP o simili (in realtà si può usare Heroku e fare un PHP legacy CI/CD). Non è da confondere con la modalità con framework come Laravel che fa in modo di lavorare come fosse un ambiente più simile a quelli esistenti come Node.js, e simili, ma che non analizzerò per due motivi: la percentuale d'uso di queste tecnologie è bassa.

          Questo dipende solo ed esclusivamente dall'organizzazione del team, si può fare benissimo CI e CD anche con PHP.

          simonebortolin essere file PHP eseguibili dall’interprete PHP stesso

          Ed ecco a cosa serve la validazione degli input, usare le directory corrette ed escapare le stringhe.

          simonebortolin non permette di elaborare i dati post in formato json.²

          json_decode, json_encode

          simonebortolin l’ennesimo problema di sicurezza

          No(?), se il developer è una scimmia non è un problema del linguaggio.

          simonebortolin il routing³ permette di accedere al file conn.php senza grossi problemi

          Ti ricordo che tutto quello messo tra i tag di php non viene MAI inviato al client, salvo l'esplicito uso di un print o una configurazione errata del webserver.
          Ad ogni modo, in un sistema decente, i file di configurazione non sono esposti al mondo, quindi magari invece di importare "./conn.php" importi "../conn.php", dove ../ è una directory non pubblica.

          simonebortolin inoltre si ha per esempio user.php, login.php: è possibile che uno di questi file ci ha una versione non aggiornata di qualche controllo rendendo pericolosa la sicurezza

          Penso di non aver capito ciò che volevi dire

          simonebortolin PHP legacy di default mette come output il mime-type dell’html, qualsiasi altro mime-type deve essere specificato⁴, PHP legacy ha pochi controlli su user agent, cookie, e tantissimi header che vengono comunemente usati da anche Laravel in PHP.

          Eh beh, di sicuro i mime types non se li può inventare.
          Inoltre è possibile cambiare il default type.
          La gestione di cookies, user agent e header è perfettamente fattibile anche su php stock.

          simonebortolin questo richiede normalmente un invio di messaggi di tipo json o xml

          Please don't.
          Usare xml nel 2021 andrebbe evitato.

          simonebortolin (il principale problema che ho riscontrato nell’usare Json in PHP è quello che basta uno spazio all’inizio o alla fine ed il Json non è più valido)

          La pulizia degli input esiste per un motivo.

          Inoltre se hai generato un json spero tu abbia usato funzioni apposite, e non roba del tipo "{" + key + "\":\"" + type + "\"}", dunque il famoso "spazio in più" non dovrebbe esistere, e se dovesse esistere, il tuo problema è ben differente.

          simonebortolin spesso è necessario avere funzionamenti diversi a seconda di GET o POST

          $_SERVER['REQUEST_METHOD'] esiste per un motivo.
          Bastano 30 secondi su stackoverflow per trovarlo e ti dirò di più, la risposta ha oltre 10 anni.

          simonebortolin PHP 5.0 era molto insicuro e pieno di bachi, ma almeno era veloce

          Ti correggo: PHP5.x era insicuro, pieno di bug e lento come la morte.

          simonebortolin PHP 7.0 ha rallentato tanto l’esecuzione di PHP⁶

          Ceeerto, non è che le aziende non vogliono investire nell'aggiornamento della loro roba "perché tanto funziona" (poi si trovano un backup non programmato su qualche sito di hackeroonies e piangono).
          Tralasciando che la sicurezza al costo della velocità dovrebbe essere sempre preferita, PHP7+ garantisce velocità e sicurezza migliori di PHP5.

          simonebortolin rendendolo di fatto scartato da tutti gli sviluppatori

          Se per scartato da tutti gli sviluppatori intendi "non disponibile tramite apt scrivendo un comando perché quello sappiamo fare e se le cose diventano mezzo secondo più lunghe fa tutto schifo" devo darti ragione, altrimenti beh, sbagli sui dati anche qui.

          simonebortolin Se invece vuoi fare un built-in devi perdere tempo in configurazioni di apache o nginx, fmp, php, sia in ambiente di sviluppo che in produzione.

          Ed ecco come siamo arrivati alla gente che usa i webserver "di debug" in produzione.

          simonebortolin Senza dimenticare l’annoso problema che PHP non usa Unicode, come viene usato da Java, Python, Node.js: in PHP è difficile far pace con i simboli di carattere non supportato, cioè che il principale problema di PHP è se stesso: l’architettura è nata errata negli anni 90, ed ora ci dobbiamo adeguare a questo.

          Basta cambiare un'impostazione per sistemare tutto, non è difficile da fare.
          Senza contare che ci sono migliaia di funzioni per gestire unicode su php.

          simonebortolin Aggiungo anche una ultimissima cosa: integrazione con gli IDE: so che c’è una eterna diatriba tra programmare su terminale con vi(m) o programmare su IDE o su programmi di coding leggero: mentre i primi 2 sono molto orientati a fare operazioni di debug e compilazione tutto su terminale, il terzo usa un ambiente completo che ti fa tutto.

          In realtà l'ambiente completo che "ti fa tutto" *ensomma* è l'ide, non il text editor.

          simonebortolin Mescolando PHP e HTML si potrebbe pensare pure di generare CSS e JS custom in base a cosa genera il PHP: questa è una bad pratices perché il codice sarebbe molto più soggetto a SQL Injection.

          "Se mischi benzina e gasolio ti si hackera la centralina"
          è roba che non c'entra assolutamente nulla, sicuramente non è una buona soluzione per le performance, ma in che modo dovrebbe portarti alla sql injection?
          Senza contare che esistono gli escape, per tutto, ed anzi, esistono pure i prepared statements, va te.

          simonebortolin Concludo dicendo: che fare progetti in PHP nel 2021 senza nessun framework in maniera liscia standard non ha senso, tutto il resto si potrebbe fare perché comunque PHP è un buon linguaggio ma ha senso usare un linguaggio morto, ovviamente è preferibile usare altre strade

          Ti sei contraddetto da solo.

          simonebortolin in una applicazione bancaria è necessario essere sicuri che uno non possa inviare soldi via una richiesta GET

          E perché mai? Se il mio programma sa gestirla non ho problemi.
          Potenzialmente potrei far funzionare tutto a richieste DELETE, non sarebbe standard, ovvio, ma se sia il client che il server sanno come gestirsi la roba, funzionerebbe perfettamente.

          simonebortolin Se ci dimentichiamo di specificarlo succede che un output di tipo json viene stampato con un times new roman.

          Perché viene passato come HTML e quindi i browser applicano lo stile di default, non è PHP che si fa una copia del font e la gira all'utente tanto per simpatia.

          [cancellato] E allora per quali altri utilizzi dovrebbe andare bene?

          simonebortolin essere sicuro che non c'è nessun echo né prima né dopo di spazi altrimenti si corrompe

          Non è che si corrompe, se aggiungi roba non è più un json, dunque, giustamente, non viene interpretato.
          Metti un print sulla pagina prima del respondJSON da te citato e fammi sapere cosa succede.

          simonebortolin Inoltre se il file è già stato parsato non funziona

          File? quale file

          simonebortolin no puoi fare if(isset($_POST)) ma se il post è vuoto non funziona (anzi il comportamento non è definito, per questo si mette come minimo un hidden o sumbit) e non puoi verificare PUT, GET, DELETE e tutti gli altri

          $_SERVER['REQUEST_METHOD']

          simonebortolin Si può dire che l'elaborazione PHP 7.0 è più veloce della 5.0 ma non il tempo di esecuzione di uno script PHP.
          In generale è più lento, poi fare un while(i<1000) i++ è più veloce.

          Mi sa che dovresti cercarti dei benchmark decenti

          uadopo Evidentemente gli piace fare schifo

          handymenny Vuoi dire che una singola esecuzione di uno script è più lenta in php 7 (e successivi) ?

          Mi sembra impossibile, data l'introduzione di sistemi di caching sempre migliori e altre varie migliorie per sistemare eventuali problemi di performance.

          [cancellato] Pessima scelta soldato, pessima scelta

          simonebortolin Beh Wordpress usa questo design e fare tanti file su PHP è un problema di sicurezza

          HO BISOGNO DI UN PO' DI VARECHINA PER I MIEI OCCHI.
          Come dovrebbero essere dei file, esattamente funzionanti nello stesso identico modo, un problema di sicurezza?

          simonebortolin potrei limitare l'accesso con htaccess

          Tralasciando che metterei le mani al collo di chi usa apache e non nginx, non è un problema di PHP se tu lasci accesso a roba sbagliata, sarebbe come prendersela con PHP se metti la stringa di connessione in un echo e lui non dovesse avere una super AI per detectare il tuo errore ed evitare di farti leakare le credenziali di accesso.

          simonebortolin Sì, l'esecuzione di una singola istruzione è più veloce, l'esecuzione di un intero script compreso l'avvio dell'interprete php è più lento

          Guarda, sono piuttosto sicuro del contrario, riesci a dimostrarmelo in qualche modo oggettivo?

          simonebortolin mysqli_real_escape_string

          Certo che se usi roba del genere te lo meriti di farti bucare.
          Ma usare pdo fa schifo a tutti? Vi state complicando la vita per poi lamentarvi delle vostre pessime decisioni.

          simonebortolin le query parametriche quelle con il ? secondo l'attuale letteratura sono da EVITARE in favore di:

          WTF
          Spero tu sia ironico, perché hai appena smontato tutto il web e anni di web development.
          Ah sì, pure youtube le usa, direi che zio google non è proprio il primo pirla dietro l'angolo.

          simonebortolin (c'è clouflare che mi blocca i < ? senza spazio )

          Ed ecco a cosa servono gli ide e i test prima di mandare in produzione.
          Se tu sbagli non puoi prendertela con il linguaggio.

          simonebortolin che su pluto_get.php?value non ho fatto il filtro perché tanto è un valore passato da javascript sai quanto è difficile da testare questo codice

          Se non hai fatto la sanificazione dell'input o ancor peggio non hai usato i prepared statements il problema sei tu, non PHP.
          È grazie alla gente che ragiona in questo modo se poi ci troviamo dump come quello di homobile.

          simonebortolin in php è completamente diverso: un file php è visto come un file dentro la cartella pubblic e l'unico modo per inibire l'accesso è usare htaccess.

          coff coff, dovresti settare la directory del webserver ad un livello più alto

          uadopo Ho lavorato il PHP da autodidatta diversi anni fa ma posso assicurare che la forte tipizzazione e pattern in ambiente .NET lo rende molto più manutenibile e se si cambia azienda tendenzialmente non è un dramma lavorare sul codice di altri

          Tralasciando che da quanto posso vedere sempre più aziende vogliono allontanarsi da .net, PHP supporta la tipizzazione, ovvio, non è un linguaggio a tipizzazione statica, ma i tipi esistono, come esistono le classi.

          handymenny In PHP lo decidi tu, sono previste entrambe le modalità. Da quello che ho capito, si preferisce farle compilare al DB perché è più sicuro

          Ci sono almeno due tipi di approccio differenti:

          • Escape della query lato client -> Funziona, ma poi si rischia di finire come zoom, meglio evitare.
          • Prepared statements -> Il client comunica al db la query che si andrà a fare, ma senza i dati.
            Dunque il server sa già cosa aspettarsi, ha già fatto le sue ottimizzazioni e così via, semplicemente gli si passano i dati e se gli arriva un DROP dentro una stringa, non verrà eseguito, in quanto lui già sa qual è la query da eseguire e dove vanno i suoi parametri.

          [cancellato] comincia a metterci una barriera in più invece di sperare che la libreria di sanitizzazione degli input scaricata da qualche repository

          Esattamente, ma soprattutto, ti garantisce che nessuno vada ad eseguire queries non scritte da te.
          Senza contare che con sta roba si possono richiamare tante volte le stesse query cambiando solo i dati.

          simonebortolin dovuta a varie influenze sul fatto di ridurre al minimo i Prepared statement (e la cosa bella che sento spesso parlare di questo da tante persone, anche autorevoli)

          Citamene una perché è ridicolo

          simonebortolin "sono una complicazioni affari semplici "

          Ovvio che sono complicazioni di affari semplici, come lo è passare per tutti i sistemi di sicurezza della banca.
          Tutti i clienti son contenti di non avere scanner e roba varia, fino a quando non entra uno con un ak47 e pessime intenzioni.

          [cancellato] Webassembly serve esattamente togliere di mezzo Javascript

          In realtà no, visto che wasm ha comunque bisogno di js per funzionare.
          Serve a sostituirlo solo per la roba pesante che esso stesso non sarebbe in grado di gestire.

          Technetium Qualsiasi linguaggio è portato allo sviluppo web, non c'è un migliore, soprattutto nella direzione che si sta prendendo, ovvero quella di dare API e non direttamente del contenuto.

          Devi appunto vedere con cosa gira meglio il backend ed adattare le API ad esso, non il contrario.

            LucaTheHacker Evidentemente gli piace fare schifo

            😂 Potrei dire l'esatto contrario

            Technetium di certo adesso ci sono parecchie soluzioni.
            Oggi utilizzerei ad esempio cose come Vue.js, Angular e simili per gestire il frontend e per il backend qualsiasi libreria che aiuta lo sviluppo di api REST in modo facile (ad esempio specificando soltanto l'oggetto e non dover gestire parte di conversione json ecc), ho sviluppato personalmente già dei backend proprio per queste cose.

            Alfoele Sicuramente anche su questo hai ragione. Ma se possedessi una azienda dove si basa molto sul proprio sistema che sta diventando antiquariato farei un piano apposta per riscriverlo.

              • [cancellato]

              • Modificato

              LucaTheHacker Pessima scelta soldato, pessima scelta

              Mica ho detto che i suoi interventi sono oro colato - e non lo dirò nemmeno dei tuoi poiché NON sono competente in materia quindi NON posso giudicare in autonomia - ho detto che di fatto ho stimolato un dibattito molto interessante in quanto tale cioè in quanto confronto tra persone che in un modo o nell'altro manifestano mi sembra conoscenze ad un livello comunque superiore della media.

              LucaTheHacker Tralasciando che metterei le mani al collo di chi usa apache e non nginx

              Anche un dibattito sulle differenze tra web server in termini di configurabilità, sicurezza, efficienza, etc etc... sarebbe interessante.

                dadadani sistema che sta diventando antiquariato farei un piano apposta per riscriverlo

                Sono tanti quelli che resistono "difensivissimi" sulle proprie posizioni, vuoi per dimensioni e conseguenti impatti della transizione, vuoi per costi, ecc..., mettendo pezze qua e là e tenendo in essere roba obsoleta ben oltre i tempi massimi del ciclo di vita di certe soluzioni...

                  Alfoele stesso motivo per cui certi pos e simili eseguono versioni preistoriche di certi sistemi operativi. 😃

                  come già detto prima il discorso è se dovessi essere costretto a scrivere in una piattaforma esistente legacy, ma cercherei in tutti i modi di convincere a fare il passaggio a qualcosa di moderno (esempio capita che si rompe qualcosa di esterno e proponi di riscrivere tutto).

                    dadadani a fare il passaggio a qualcosa di moderno

                    Sto leggendo cose un po' strane, usare un framework frontend con delle API non significa essere moderni, è solo un modo di fare diverso e che ha i suoi vantaggi e svantaggi. Le API poi in cosa le scrivi?

                    PHP si può usare bene sfruttando framework e tecnologie adeguate, e non ha ad oggi molto da invidiare alla concorrenza. Basta scegliere di usarlo bene. Soluzioni come Laravel sono molto molto complete e ti costringono a scrivere codice bene e in OOP.

                    Questa discussione non finirà mai perché è naturale sia così, ma vedo delle conclusioni un po' affrettate. PHP si può usare male ma si può usare male anche Java, non è il linguaggio ma la predisposizione di chi sta davanti alla tastiera...

                      dadadani di certo adesso ci sono parecchie soluzioni.
                      Oggi utilizzerei ad esempio cose come Vue.js, Angular e simili per gestire il frontend e per il backend qualsiasi libreria che aiuta lo sviluppo di api REST in modo facile (ad esempio specificando soltanto l'oggetto e non dover gestire parte di conversione json ecc), ho sviluppato personalmente già dei backend proprio per queste cose.

                      Mi faresti un esempio più concreto ?
                      Ok.. vue.js e angular aiutano nell'interfaccia e va bene (d'altronde l'interfaccia in php non la puoi fare c'è sempre html e JS) il resto come lo fai ?
                      In php non ci vedo grossi problemi.. si può scrivere codice che funzioni come api REST.

                        Bella questa discussione 🙂

                        Mi presento, sono quello che definiamo Full Stack Developer. 15 anni in PHP (da procedurale a oggetti), oggi anche Java, Python e Javascript (sia FE che BE).

                        Il nostro modo di lavorare è cambiato (o potremmo cambiarlo) da quando ormai i microservizi la fanno da padrone (e meno male!) e sopratutto abbiamo a disposizione Docker. Quest'ultimo, una volta ben compreso (anche da parte dei sistemisti di un'azienda...) spazza finalmente via tutti i problemi di compatibilità e dipendenze...

                        Cercando di rimanere in focus, ho avuto la fortuna di lavorare un po' di tempo con un'azienda USA. Da loro ho assorbito un modo di lavorare che in Italia non trovo facilmente:

                        1 - TDD: Prima scrivo i test, POI il codice (e se ci pensate lo uniamo al BDD)
                        2 - CI/CD: Sempre, sempre, sempre. Oggi sopratutto, dove la CD mi crea la mia bella immagine Docker e la deploya in automatico. E se i test hanno fallito, la nuova versione NON va in produzione 🙂
                        3 - GIT (non solo Github). Con il suo branching, rami develop per sviluppare e master sempre blindato e taggato all'ultima versione FUNZIONANTE.

                        Ho visto programmi Java scritti coi piedi e PHP conciso ed elegante. Ho visto PHP scritto coi piedi e applicativi Java (sempre backend) concisi ed eleganti.

                        Ho visto Backend senza un commento leggibili dal primo giorno di corso e ho visto software con 1000 righe di commenti il cui scopo era ribadire che la variabile $nome conteneva il nome dello user.

                        Concludo dicendo:
                        1 - Si, è vero, ancora ci sono PHP legacy in giro, purtoppo ce li porteremo dietro un bel po'. Sapete quanto costa un refactoring di un applicativo in piedi da 5+ anni e con mille mila patch? E non solo economico... Anche a livello di bug fixing dopo la messa in produzione della 1.0.0. Inoltre... Vai a trovare tutte le patch disseminate nel codice (if amount > 1000 then multiplier = 3) //pseudocode => dove diamine lo avrà messo il collega che è stato qui 3 mesi e poi se ne è andato?
                        2 - Docker aiuta tanto. La curva di apprendimento non è elevata, ed è un'arma atomica nello zaino di uno sviluppatore. Provare per credere.
                        3 - Non è il linguaggio a essere "sbagliato" ma il come è stato utilizzato. Se non metti test, una qualsiasi modifica comporta sempre l'ansia di regressione.
                        4 - Abbiamo i framework: usiamoli. Non ha senso fare un software in PHP senza Laravel (ormai lo standard de-facto), nè un'applicazione Java senza Spring (se è un BE rest). Non ha senso un FE in HTML puro, se non per uso scolastico (ma neanche quello). React è tosto da imparare, ma se impari React tutte le altre librerie FE (Vue, o meglio Nuxt, come anche Angular) te le mangi a colazione.
                        5 - Abbiamo millemila corsi sul TDD: impariamolo, lo sviluppatore che verrà dopo di noi a manutenere il nostro codice ci ringrazierà.

                        Io personalmente
                        1 - non sono più in grado di scrivere software se non partendo dai test 😄
                        2 - non ho più nulla installato sul mio PC: gli ambienti PHP sono gestiti on-the-fly da immagini docker che ho personalmente realizzato (e sono pubbliche, per chi volesse usarle)
                        3 - Come punto 2, anche i database sono tutti presenti sulla mia macchina, ma in versione docker. Quindi mi permetto il lusso di avere 3/4 versioni MySql, Oracle, Vertica e Redis senza che in realtà ve ne sia uno installato.

                          matteocontrini forse mi sono spiegato male fin dall'inizio. Hai ragione sull'ultima parte che potresti generalmente usare male qualsiasi linguaggio/libreria/framework/quello che sia, ma è anche il fatto di come è costruita che aiuta nel scrivere codice.
                          PHP è noto per rendere facile questa cosa, e a meno che ti sei dedicato veramente tanto, rende spesso difficile mantenere tutto la codebase che c'è dietro.
                          Utilizzare le tecnologie moderne dà sicuramente un aiuto perché (come detto ora, se sfruttato correttamente) aiuta ad avere codice che può essere gestito meglio e letto da persone che hanno iniziato appena a lavorarci.

                          Poi non metto in dubbio che nonostante tutto con PHP sia possibile attraverso diverse pezze creare la stessa cosa, ma quante volte questa cosa viene fatta?

                          Technetium il backend REST... Lo puoi scrivere anche sempre PHP se vuoi! I "nuovi" framework come Laravel sono stati molto d'aiuto, ma dato che alla base come linguaggio ci sono molte incertezze, rimane che a lungo termine si possano creare delle parti che ogni volta che lo vedi semplicemente ti viene da dire "WTF?"

                            dadadani

                            si possano creare delle parti che ogni volta che lo vedi semplicemente ti viene da dire "WTF?"

                            Se una parte è ostica, metti un commento. Serve prima di tutto a te, poi al collega che verrà dopo di te. Inoltre, sarebbe sempre opportuno seguire un pattern consolidato. Per esempio Controller <=> Gateway <=> Repository <=> Interface su PHP o il quasi onnipresente DTO in Java.

                            [...]a meno che ti sei dedicato veramente tanto, rende spesso difficile mantenere tutto la codebase che c'è dietro.

                            Scommettiamo che se avessi usato TDD questa frase la potresti cancellare?

                            dadadani il backend REST... Lo puoi scrivere anche sempre PHP se vuoi! I "nuovi" framework come Laravel sono stati molto d'aiuto, ma dato che alla base come linguaggio ci sono molte incertezze, rimane che a lungo termine si possano creare delle parti che ogni volta che lo vedi semplicemente ti viene da dire "WTF?"

                            Continuo a non capire.. per me si parla del linguaggio continuando a confonderlo con i suoi framework/librerie.
                            Non è che java o .net (per quel poco che so) di loro facciano magie 😄 Alla fine ti appoggi sempre a "librerie" apposite che aiutano a fare quello che dici.

                            Io sviluppo e ho sviluppato in PHP.. e "incertezze" particolari non ne ho trovate.. magari al mio livello di uso. Certo, con gli anni il codice è "invecchiato" nel senso che non è più compatibile con versioni nuove dell'interprete però è facile che accada un po' con tutti i linguaggi che si sviluppano in tempi recenti perchè devono ancora maturare.

                            Non ho ben capito.. nella tua mente stai confrontando php con cosa ? Java ?

                              Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈
                              P.I. IT16712091004 - info@fibraclick.it

                              ♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile