Feedburner
Ehi, guarda cosa scrivo su doxalog!
- Marchionne contro il sindacato. Gli operai polacchi lavorano meglio. 19 giugno 2010Marchionne: La Panda la producono in Polonia, l’hanno prodotta bene con un livello di qualità che non è mai stato raggiunto in uno stabilimento italiano. Mai.. Ed infatti la FIAT è così contenta dello stabilimento polacco, ma così contenta che, secondo gli operai polacchi, adesso vuole nuovamente spostare la produzione in Italia. Gli operai polacchi avevano […]Vincent Vega
- Cota, Zaia ed i leghisti contro la ru486 (pillola antiabortiva). La chiesa plaude. 2 aprile 2010Zaia e Cota si scagliano contro la pillola abortiva. La Chiesa plaude. Normale, d’altro canto la Chiesa ha dimostrato in più di un’occasione il suo amore per i fanciulli. Leggi anche:Mario Chiesa, mani pulite, arrestato nuovamente per tangenti l’uomo che diede il via alla famigerata inchiesta dei giudici di Milano. Benedetto XVI e la politica. Albanese picch […]Vincent Vega
- Pedofilia, le parole di Christoph Schoenborn, arcivescovo di Vienna 13 marzo 2010Asca news riporta le parole di Christoph Schoeborn, arcivescovo di Vienna, il quale afferma che la Chiesa cattolica dovrebbe riesaminare le regole del celibato per i sacerdoti, come una delle possibile cause dei recenti scandali per abusi sui minori che hanno visto coinvolti diversi preti in Germania, Austria e Olanda. Certo, rivediamo le regole del celibato […]Vincent Vega
- Brunetta e lo yogurt scaduto. 5 marzo 2010Brunetta: “Contro lo spreco mangio yogurt scaduti” Tanto poi i mal di pancia vengono a noi. Niente altro da leggere Niente altro da leggere […]Vincent Vega
- Napolitano ed il decreto legge per salvare Formigoni e Polverini. 5 marzo 2010Caos liste, Napolitano: “Firmo solo con ampio consenso” Quindi se c’è ampio consenso si può violare la legge. Buono a sapersi. Qualcuno fa un esempio lampante, qualcun altro si chiede: se ad essere esclusa fosse stata una lista meno conosciuta sarebbe stato fatto tutto questo casino? La risposta è no, perché ad ogni elezione migliaia [...] Leggi anche:Napoli […]Vincent Vega
- Il popolo delle carriole, il popolo viola, il popolo del precari, il popolo dei girotondi 1 marzo 2010Il popolo delle carriole, il popolo viola, il popolo dei precari, il popolo del No-TAV, il popolo del NO al Molin, ancor prima il popolo dei girotondi, il popolo del family day. Tanti popoli, ma non viene mai nominato il più importante: il popolo italiano. Leggi anche:Precari, scuola, licenziamenti. 12.000 posti a rischio. Gelmini (Ministero dell’Istruzione) […]Vincent Vega
- Berlusconi e l’esclusione delle liste del PDL. Che la burocrazia non prevalga 1 marzo 2010Berlusconi: “non è possibile che nella regione della Capitale il primo partito del Paese, accreditato del 40% dei consensi, venga escluso dalla tornata elettorale, che la democrazia burocrazia prevalga anche in un caso del genere, così importante”. Leggi anche:Berlusconi, via i corrotti dalle liste Margherita Boniver: salvate Berlusconi Sunday Times intervis […]Vincent Vega
- Saviano si è accorto che la mafia è nel Parlamento 25 febbraio 2010Saviano si è accorto che la mafia è entrata nel parlamento. Attendiamo prossime importanti rivelazioni come: l’acqua quando è calda bolle, quando piove l’asfalto si bagna, stare al sole provoca scottature, l’acqua dei fiumi è inquinata. Leggi anche:Mafia: Schifani, Parlamento ha fatto la … Napolitano, guai a sottovalutare la mafia. Berlusconi: Parlamento Ple […]Vincent Vega
- Fastweb e Telecom Sparkle, truffa del secolo 25 febbraio 2010Fastweb e Telecom Sparkle, secondo il gip si tratta della “più colossale frode di sempre”. Alla faccia degli scettici secondo cui la banda larga in Italia non esiste. Io l’avevo detto in tempi non sospetti: in Italia di bande larghe ne abbiamo in abbondanza. Leggi anche:Finlandia, la banda larga è un diritto. Anche in Italia. Banda larga addio Mai [...] Legg […]Vincent Vega
- Do Androids Dream of Electric Sheep? 22 febbraio 2010Mi scrivono nei commenti: Thank you! You often write very interesting articles. You improved my mood. (trad. Grazie. Scrivi spesso articoli interessanti. Hai migliorato il mio umore). Peccato che a scrivermi questi complimenti sia uno spam bot, tocca accontentarsi. Significativo anche il nome del bot “erectile dysfunction treatment” e l’articolo su cui ha sc […]Vincent Vega
Php, Python, Ruby per lo sviluppo web. Un'analisi.
14 nov2008
Pochi giorni fa ho pubblicato un video confronto, a mio parere molto interessante, tra J2EE, Ruby On Rails, Zope, Turbogears e Django. I linguaggi utilizzati da queste piattaforme di sviluppo sono Java, Ruby e Python, manca il linguaggio di programmazione per il web più conosciuto, sicuramente quello più utilizzato dagli utenti che con la programmazione hanno meno a che fare: PHP.
No, non preoccupatevi, non intendo scrivere l'ennesimo articolo che mette a confronto le peculiarità ed i punti di forza di tutti questi linguaggi di programmazione cercando poi di nominare un vincitore assoluto, vorrei invece concentrarmi su aspetti che a volte sono ritenuti secondari ma che invece molto spesso sono alla base del successo di molte tecnologie.
A scanso di equivoci vi dico subito che tra questi tre linguaggi il mio preferito è Python: mi piace la sintassi elegante, la disponibilità di librerie, la maggiore disponibilità di documentazione (esistono ad esempio molti libri e fonti per Wxpython quasi nulla di corrispondente per Ruby). In generale è una questione di "comfort", ed io mi trovo bene con Python, tuttavia ritengo che Ruby abbia alcune caratteristiche che lo rendono altrettanto interessante, non ultima il fatto che sia un linguaggio completamente ad oggetti ed un paio di cose riguardo l'eleganza della sintassi. Tuttavia l'unico linguaggio che effettivamente utilizzo in ambienti di produzione per lo sviluppo di applicazioni web è il PHP.
Il problema base di Python e Ruby e di tutti i framework e template engine disponibili per questi linguaggi è uno solo: facilità di distribuzione.
Mi spiego meglio: se io volessi realizzare un servizio web come twitter e reddit molto probabilmente punterei ad una qualche soluzione basata su Python o Ruby, magari un framework come Django o Ruby On Rails. Probabilmente, per una mera questione di flessibilità, di libertà e di pieno controllo dell'applicativo, avendo tempo e denaro cercherei di sviluppare una soluzione tagliata specificamente per le mie esigenze.
Ma farei la stessa scelta se dovessi sviluppare una piattaforma di blogging che faccia concorrenza a Wordpress, un cms che contrasti Joomla o Drupal, una piattaforma per forum come Phpbb o un programma in grado di gestire una galleria di immagini come Gallery? Probabilmente no.
La forza di applicativi come wordpress è dovuta non soltanto all'enorme disponibilità di plugin ed estensioni, facilitata anche dall'enorme numero di sviluppatori con competenze in php (aspetto da non sottovalutare) ma soprattutto dalla facilità con cui anche un utente con conoscenze quasi nulle di informatica è in grado di portare a termine l'installazione e la configurazione di wordpress su di uno spazio web personale (il famoso 5 minutes install, senza considerare che molti hosting provider forniscono script automatici di installazione per wordpress ed altre piattaforme sviluppate in php).
Provate a fare lo stesso con Django e Ruby On Rails, per i quali sono disponibili interi how-to di deployment pensati non per l'utente alle prime armi ma per lo sviluppatore che vuole installare la sua applicazione su un sito web! Se io sviluppassi un software con Django o con Ruby On Rails mi divertirei molto di più e risparmierei un sacco di tempo, ma il mio applicativo faticherebbe a diffondersi proprio perché l'installazione della mia creazione sarebbe un'operazione molto meno banale rispetto ad un qualsiasi software sviluppato in PHP, scritto male, pieno di include e con il codice mischiato all'html.
Questo non dipende soltanto dalla disponibilità di hosting a basso costo per php ma anche dalle caratteristiche più deprecate dai puristi della programmazione: la possibilità di embeddare codice in pagine web e di inserire il codice dell'applicativo all'interno delle pagine servite dal web server.
Infatti, se volessi risparmiare tempo ed avere un bel po' di classi già scritte, potrei decidere di utilizzare un framework per PHP, come ad esempio Cake PHP, ed anche in questo caso per il deployment basterebbe copiare tutte le cartelle sul server e configurare un db, magari con uno scriptino ad hoc. La mia applicazione sarebbe sviluppata con il supporto di un framework, con tutti i vantaggi che questo comporta, ma la sua distribuzione sarebbe comunque molto più semplice di una controparte scritta in Django o Rails.
Questi limiti non sono certo secondari, ed infatti non esiste nessun prodotto sviluppato in Django e RoR in grado di competere, per diffusione, completezza, facilità di utilizzo e di installazione, con le controparti sviluppate (magari anche male) in PHP.
Non è un problema da poco e credo che sia sentito anche dagli sviluppatori di framework come Django e Rails, non a caso David Heinemeir Hansson, nel capitolo 22 del libro "Sviluppare Applicazioni Web con Rails" scrive:
WEBrick può d'altra parte essere considerato una piattaforma ottimale per applicazioni ad ampia diffusione: per esempio il clone di Wiki, Instiki, è riuscito a diventare l'applicazione Ruby più scaricata da RubyForge soprattutto grazie alle promesse di No Step Three.
La selta di WEBrick come server web ha permesso a Instiki di essere distribuito con una procedura d'installazione molto semplice; addirittura, la versione per Mac OS X, è fornita con lo stesso linguaggio Ruby e, quindi, è sufficiente un doppio clic sul file .app per attivare il vostro Wiki personale.
Certo, WEBrick perde rapidamente il suo fascino quando si prendono in considerazioni applicazioni diverse da quelle ad uso interno o personale, ma questo non deve impedirvi di iniziare ad utilizzarlo. Un'applicazione sviluppata per WEBrick non richiede alcuna modifica per funzionare con Apache e lighttpd. Potete persino valutare di continuare a sviluppare localmente con WEBrick, mentre l'applicazione è in produzione su uno degli altri due server, basati su C.
La mia speranza è che in un futuro prossimo la situazione cambi in meglio. I mezzi ci sono: eRuby, Cheetah, Mako, ma mod_python e mod_ruby non sono ancora affidabili e diffusi come mod_php. Fatta l'integrazione naturalmente bisognerà fare i programmatori, ma credo che pian piano anche gli sviluppatori php si stiano abituando all'idea di utilizzare template engine e di sviluppare utilizzando un paradigma object orientend.
Leggi anche:
- Video confronto tra J2EE, Ruby On Rails, Zope, Turbogears e Django
- Sviluppare applicazioni web con Django. Il tutorial rilasciato gratuitamente sul web!
- Quanto valgono il kernel Linux ed i software liberi?
- World Wide Web Consortium, portare il Web al suo massimo potenziale
- Una suite di sviluppo Linux per gli smartphone
(Gli utenti ritengono che questo articolo valga +1, hanno votato 1 utenti)
Loading ...Articoli correlati
- In: Il Ueb| Informatica| Open source| Software| recensioni
- Tags: Cake PHP, Django, framework, Open source, PHP, Python, Ruby, Ruby on Rails, sviluppo web
Articolo scritto da Doxaliber per Doxaliber, vuoi partecipare anche tu?
Se questo articolo ti è piaciuto aiutami a diffonderlo.
Segnalalo sul tuo blog, invialo agli amici, segnalalo sugli aggregatori di news.
Se vuoi seguire Doxaliber con maggiore tranquillità iscriviti ai feed, trovi i link in alto a destra.
Intanto questo blog ha già:
senza contare i lettori dei feed per categorie e gli abbonati alla newsletter!
20 Risposte to “Php, Python, Ruby per lo sviluppo web. Un'analisi.”
Rispondi
Doxaliber, blog di Salvatore Ingrosso, è distribuito con licenza Creative Commons. - Collegati -
Questo blog usa wordpress | Tema Evidens [White] realizzato da Design Disease per PremiumThemes.com, modificato, riadattato e tradotto da Doxaliber
Che dire, analisi condivisibile.
Sul fronte Ruby on Rails sono nati dei cms (Radian) o customizzazioni a più alto livello (Community engine), ma un'alternativa a Drupal la vedo ancora lontana, anche per il semplice fatto che Rails attuale non ha ancora un sistema di localizzazione standard.
Ti piace questo commento?
1 
0
Radiant (qui il link), a quanto vedo sul sito, si installa via Ruby Gems, ergo richiede un hosting che fornisca accesso via shell.
Ti piace questo commento?
0 
1
Ciao,
condivido quasi in tutto l'analisi.
Pure io ritengo linguaggi come Ruby e Python più divertenti per lo sviluppatore rispetto a php, ma vorrei far presente un framework per php (che attualmente uso) e che secondo me tiene testa abbastanza bene al tanto blasonato RoR; si tratta si symfony, un bellissimo framework scritto in php, considerate inoltre che l'ultima versione di RoR ha copiato qualcosina da symfony stesso...
ciao ciao
Ti piace questo commento?
0 
0
Avevo dato uno sguardo a symfony un paio di anni fa, sembrava potente, però era necessario scrivere un sacco di xml. Probabilmente le cose sono migliorate da allora, ci darò uno sguardo, grazie.
Ti piace questo commento?
1 
0
è vero un paio di anni fa la parte di configurazione del model si faceva tutta in xml, ma ora non si deve più scrivere nemmeno una riga di xml... il framework è migliorato tantissimo; se poi hai dubbi o quesiti su questo framework puoi contattarmi alla mia mail (riesci a vederla vero?)
Ti piace questo commento?
0 
0
Certo, come amministratore sono l'unico che riesce a vedere l'email dei commentatori.
Ti dirò, visto che avevo due minuti liberi stavo testando il tutorial proprio adesso. In effetti i miglioramenti si vedono subito.
Ti piace questo commento?
0 
0
Veramente complimenti per l'analisi chiara della situazione. Si trovano sempre articoli di parte ma un'analisi asciutta e obiettiva così è apprezzabile.
Ti piace questo commento?
0 
0
Grazie mille.
Ti piace questo commento?
0 
0
Due note:
1. Python è un linguaggio totalmente ad oggetti come Ruby ma permette anche uno stile di programmazione funzionale.
2. In ambito Python esistono diversi web framework ma quello più potente è sicuramente Zope, che è un application server, su questo si appoggia Plone, un CMS di classe enterprise. Plone ha moltissimi plugin, la maggior parte dei quali si installa con un click. Unico neo di questo ambiente è che imparare ad usarlo è alquanto faticoso e richiedere un investimento a lungo termine.
Qui trovate un' applicazione per confrontare i vari CMS:
http://www.cmsmatrix.org/matrix/cms-matrix
(prendete i risultati solo come indicativi).
Riguardo alla facilità di deployment: Plone usa buildout ed eggs (il sistema di pacchettizzazione delle librerie di Python), le installazioni sono praticamente automatiche e facilmente replicabili (il buildout contiene tutte le informazioni necessarie). Sul fonte hosting invece si ha qualche problema ha trovare soluzioni a basso costo (istanze condivise), ma normalmente i progetti che si sviluppano con Plone richiedono una macchina dedicata.
Ti piace questo commento?
0 
0
Axaroth, sul punto 1:
- Naturalmente Python consente lo sviluppo sia in forma procedurale che ad oggetti, questo è scontato (ed oltretutto io lo considero un vantaggio). Tuttavia quando scrivo che Ruby è un linguaggio "completamente ad oggetti" intendo dire che in Ruby TUTTO è un oggetto. In ruby ad esempio gli operatori sono metodi che vanno applicati agli oggetto, quando ad esempio scriviano
1+2
stiamo in realtà applicando il metodo + all'oggetto 1 (si, 1 è un oggetto), passandogli come parametro l'oggetto 2. Ogni oggetto è quindi manipolabile a livelli impensabili. Anche sel 99% dei casi ed il 99,9% dei programmatori non useranno mai tutta questa potenza. Potenza che tra l'altro si paga in complessità e lentezza.
Su punto 2:
Nessuno mette in discussione la potenza di Zope, anche se oggi forse comincia a dimostrare i suoi anni in quanto la curva di apprendimento è alta e lo sviluppo di applicazione è un po' più complesso e meno "agile" rispetto ad esempio a Django (anche se la filosofia dietro ai due progetti è completamente diversa). In quanto a eggs e buildout richiedono l'accesso ad una shell, cosa che come sai è assolutamente difficile da ottenere con un hosting a basso costo. Naturalmente quando parlo di deployment non mi riferisco all'installazione su un server personale o in locale, ho già specificato nel pezzo che se uno sviluppa un servizio web che non richiede ridistribuzione il problema non esiste. Io mi riferisco alla facilità di installazione su hosting shared da utenti non molto esperti, ed è qui che i progetti PHP hanno la meglio (per i motivi scritti nell'articolo). Anche Plone infatti si è ritagliato certamente un suo spazio nell'ambito dei CMS, soprattutto in ambito enterprise, ma Joomla, (Wordpress), Drupal e gli altri CMS PHP hanno raggiunto una più vasta utenza proprio perché la loro installazione è per forza di cose più banale.
Ti piace questo commento?
0 
0
[...] Php, Python, Ruby per lo sviluppo web. Un’analisi. [...]
Ti piace questo commento?
0 
0
1. anche in python i tipi builtin sono oggetti (non lo erano nelle prime versioni del linguaggio), e lo sono anche i relativi operatori:
http://blog.ianbicking.org/ruby-python-power.html
2. per quanto riguarda l'hosting sono perfettamente d'accordo, ho infatti messo in evidenza il fatto che zope e plone si usano normalmente in progetti che per la loro natura richiedono comunque un hosting dedicato.
Per quanto riguarda lo sviluppo agile: non sono sicuro della definizione che usi ma se si intende che si può rifattorizzare facilmente il codice allora con zope/plone si può fare; se si intende che è difficile scrivere nuove funzionalità allora dico no, un programmatore che conosce la piattaforma zope/plone ed è in grado di sfruttare tutto quello che essa mette a disposizione può implementare funzionalità complesse scrivendo pochissimo codice... ma la barriera di ingresso è alta.
Nell'articolo però affermi che non useresti python per progetti in cui useresti wordpress, joomla o drupal dimenticando completamente che zope/plone sono una piattaforma che compete direttamente con questi.
Ti piace questo commento?
0 
0
1) Leggerò il link, grazie, sicuramente non sono aggiornato, anche perché sinceramente non è un problema che mi sono mai posto.
2) Mah, sai, io credo che lo sviluppo "agile", per come lo intendo io si possa fare con qualsiasi linguaggio di cui si abbia una completa padronanza. Nello specifico non mi riferisco certo al refactoring, cosa che d'altro canto è possibile con qualsiasi linguaggio (credo che tutti noi abbiamo le nostre belle classi e librerie, come piccoli framework, che riutilizziamo migliorando di volta in volta), quanto alla possibilità di creare in pochi minuti, da zero, intere interfacce web, complete di form di create, insert, edit, delete e viste, altamente personalizzate, anche se basilari, così da far vedere al cliente il lavoro mano mano che viene sviluppato non quando ormai è quasi tutto completo. Qui una spiegazione più dettagliata, nello specifico io mi riferivo più all'esempio che ho scritto in questo commento.
Non mi sono spiegato bene. Io ho scritto che se dovessi SVILUPPARE una piattaforma COME wordpress, joomla o drupal probabilmente sceglierei di svilupparla in PHP perché in questo modo la mia piattaforma sarebbe utilizzabile da un'utenza più vasta perché sarebbe più facile da installare anche per un utente alle prime armi, ancora di più se essa deve essere utilizzata su hosting condiviso e a basso costo (ovvero il 90% dei casi in cui la piattaforma deve essere utilizzata da un soggetto privato per un progettino/sito personale*). Al contrario se dovessi sviluppare un servizio web, come ad esempio Reddit tanto per capirci, allora sceglierei sicuramente Python. Su questo mi pare che siamo
d'accordo.
(*) Edit: d'altro canto sono ANCHE e soprattutto queste caratteristiche che hanno reso wordpress la piattaforma di blogging più diffusa ed utilizzata.
Ti piace questo commento?
0 
0
ok, 'agile' per Extreme Programmig: la mia azienda lavora con zope/plone dal 2001 e abbiamo adottato fin da subito questo tipo di metodologia.
Per quanto riguardo la creazione di interfacce web complete: Plone ha a disposizione due strumenti che forniscono queste funzionalità: Archetypes e la formlib di zope3 (quest'ultima è molto simile a quella di django). In affiancamento a questi strumenti esistono due prodotti che facilitano ulteriormente: paster che permette di generare scheletri di applicazioni (cioè tutto il boiler code necessario) e ArchXMLGen che crea un content type in formato Archetypes a partire da un diagramma UML (http://plone.org/documentation/tutorial/archgenxml-getting-started/tutorial-all-pages e meglio ancora questo video http://www.archive.org/details/SeanKellyGettingYourFeetWetwithPlone)
In quanto all'uso del php piuttosto che ruby o python: c'è sicuramente un ampio spettro di utenti: dal quello finale/finale che vuole solo scrivere i propri contenuti, all'utente finale/sviluppatore che vuole modificare e aggiungere nuove funzionalità, all'azienda che usa la tecnologia come riferimento per tutti i suoi progetti. Ognuno di questi profili ha bisogno di un prodotto diverso. Plone copre tutti questi profili ma rimane scarso per quanto riguarda la disponibilità di hosting di basso costo.
Ti piace questo commento?
0 
0
Ok Axaroth, grazie per le informazioni aggiuntive ed i commenti. In generale, anche in futuro, se vuoi puoi rispondere ad un commento utilizzando il link "rispondi", così l'autore del commento originale riceverà una notifica e seguirà più facilmente la conversazione. A rileggerci.
Ti piace questo commento?
0 
0
Ach! Distrazionen!
Ti piace questo commento?
0 
0
Stavo vedendo il video che mi hai segnalato ed ho notato che è Sean Kelly, lo stesso autore del video che ti avevo segnalato prima. In quel video alla fine l'autore da' un overall score leggermente superiore a Django rispetto a Zope (ma le differenze sono minime). Te lo dico solo a titolo informativo.
Ti piace questo commento?
0 
0
Sicuro? La tabella a 36:09 mi pare che sia fortemente a favore di Zope/Plone.
Ribadisco comunque che le piattaforme si adattano in buona misura al tipo di sviluppatore/azienda e progetto. Chi vuole usare Zope/Plone deve prevedere una adozione di lunga durata per compensare l'alta barriera di ingresso, ma i progetti evolutivi beneficiano fortemente dell'uso di questa piattaforma.
Ti piace questo commento?
0 
0
Ahah, hai ragione cavolo, cosa mi ero fumato? Ricordavo esattamente il contrario.
Comunque mi sorprende che Zope abbia 0.9 come (easy) quando finora abbiamo detto che la curva di apprendimento è alta. In ogni caso la tabella finale dice che Django non supporta i template (inesatto) e l'internazionalizzazione (inesatto), probabilmente dipende dal fatto che la versione di Django testata quando è stato realizzato il video ancora non supportasse questi aspetti.
Ti piace questo commento?
0 
0
'easy' per via dell'uso di ArchXMLTool.
Il video mi pare sia del 2006 quindi con la velocità con cui si muovono i prodotti open source è sicuramente datato.
Ti piace questo commento?
0 
0