Tuesday, January 3. 2006
RubyOnRails o Symfony?
Comments
Display comments as
(Linear | Threaded)
Bisogna anche essere onesti e dire che, se non hai un cliente disposto a sostenerti nelllo sviluppo agile, una buona parte dei vantaggi che ottieni usando rails svaniscono, mentre permangono i (pochi) aspetti negativi. Chi ha committenti così lungimiranti? 
Sentendomi preso in causa :-), voglio sottolineare un paio di cose. A prescindere dal linguaggio e dalle metodologie di sviluppo, la programmazione su framework come symfony o rubyonrails richiede conoscenza di:
[list]
[*] programmazione a oggetti avanzata;
[*] conoscenza di pattern architetturali.
[/list]
Secondo me framework come rubyonrails non lasciano spazio alla libertà di implementare soluzioni semplici per risolvere problemi semplici, ma vincola molta nella scrittura del codice, per la complessità della sintassi del codice stesso (Come ruby c'è solo smalltalk, puri linguaggi ad oggetti, ma secondo me non tutto è un oggetto); nonostante anche Symfony vincoli la scrittura di codice, ti lascia però qualche libertà in più con una sintassi like c quale quella del php.
Non so non vorrei che rubyonrail più che "La Soluzione" sia diventata più una moda. Tuttavia l'avvento di questi framework fanno pensare all'avvento di applicazioni web sempre più evolute e dinamiche e questo è solo un bene. Cmq prima di esporsi troppo io aspetterei l'avvento del framework Zend.
Per quanto riguarda le metodologie di sviluppo credo che entrambi i framework si adattino a metodologi Agili, XP e compagnia bella e ritengo che i clienti vadano educati a queste metodologie di sviluppo, in quanto se un progetto fallisce spesso la colpa non è di chi crea il progetto ma di chi si fa false aspettative senza essere in grado di spiegare quello che desidera. La metodologia agile dovrebbe aiutare in questo e non dovrebbe aumentare i costi di sviluppo, anzi li dovrebbe abbassare.
Vabbè dopo questo commento borbonico e annoiante vado a letto. Notte
[list]
[*] programmazione a oggetti avanzata;
[*] conoscenza di pattern architetturali.
[/list]
Secondo me framework come rubyonrails non lasciano spazio alla libertà di implementare soluzioni semplici per risolvere problemi semplici, ma vincola molta nella scrittura del codice, per la complessità della sintassi del codice stesso (Come ruby c'è solo smalltalk, puri linguaggi ad oggetti, ma secondo me non tutto è un oggetto); nonostante anche Symfony vincoli la scrittura di codice, ti lascia però qualche libertà in più con una sintassi like c quale quella del php.
Non so non vorrei che rubyonrail più che "La Soluzione" sia diventata più una moda. Tuttavia l'avvento di questi framework fanno pensare all'avvento di applicazioni web sempre più evolute e dinamiche e questo è solo un bene. Cmq prima di esporsi troppo io aspetterei l'avvento del framework Zend.
Per quanto riguarda le metodologie di sviluppo credo che entrambi i framework si adattino a metodologi Agili, XP e compagnia bella e ritengo che i clienti vadano educati a queste metodologie di sviluppo, in quanto se un progetto fallisce spesso la colpa non è di chi crea il progetto ma di chi si fa false aspettative senza essere in grado di spiegare quello che desidera. La metodologia agile dovrebbe aiutare in questo e non dovrebbe aumentare i costi di sviluppo, anzi li dovrebbe abbassare.
Vabbè dopo questo commento borbonico e annoiante vado a letto. Notte
io parzialmente concordo: rails ti da una struttura che in qualche modo ti vincola. O meglio, se sai come farlo puoi altamente fregartene, ma non è la cosa [i]ovvia[/i] da fare.
Quindi per progetti semplici forse è meglio la classica paginetta html con qualche pezzetto di php quei e la, il problema credo sia stabilire qual'è il punto in cui "semplice" diventa "complesso".
Però on ho capito che vuol dire "per me non tutto è un oggetto", ruby non è java, la sua oop è raramente invasiva.
PS
rails non è scritto in C, è ruby al 100%, ma può usare dei moduli in C per alcune cose come il layer di connessione al db, i binding fcgi etc..
Quindi per progetti semplici forse è meglio la classica paginetta html con qualche pezzetto di php quei e la, il problema credo sia stabilire qual'è il punto in cui "semplice" diventa "complesso".
Però on ho capito che vuol dire "per me non tutto è un oggetto", ruby non è java, la sua oop è raramente invasiva.
PS
rails non è scritto in C, è ruby al 100%, ma può usare dei moduli in C per alcune cose come il layer di connessione al db, i binding fcgi etc..
si ok, qui si parla tanto di teoria e poco di pratica. le solite guerre di religione.
guardate [url=http://weblog.rubyonrails.org/articles/2005/12/21/thoughtworks-wins-big-contract-on-rails]qui[/url] e [url=http://www.jroller.com/page/obie?entry=productivity_arbitrage]qui[/url].
ovviamente questo è un confronto tra java e ruby, ma vi da l'idea di quello che sto cercando di capire. ovvero come può funzionare un businness con ROR, piuttosto che con Symfony.
guardate [url=http://weblog.rubyonrails.org/articles/2005/12/21/thoughtworks-wins-big-contract-on-rails]qui[/url] e [url=http://www.jroller.com/page/obie?entry=productivity_arbitrage]qui[/url].
ovviamente questo è un confronto tra java e ruby, ma vi da l'idea di quello che sto cercando di capire. ovvero come può funzionare un businness con ROR, piuttosto che con Symfony.
Ok, allora faccio finta di essere antipatico 
usato rails per farci un progettino d'esempio e testarne le caratteristiche ?!?!?!?! ma prima ancora di metterci le mani vi siete lasciati incuriosire da chi lo ha inventato e perchè? ...ad esempio per scoprire che è stato concepito molto prima di Java ma è rimasto nell'ombra fino a qualche anno fa (mi ricorda qualcosa a proposito di mele & Steve Jobs 
)
Non è un pippone di retro-cultura informatica, ma sviluppo di applicazioni (non solo web): nello scegliere gli strumenti di lavoro sarebbe (!) più produttivo quantomeno sapere quali sono i punti di forza e le debolezza di ciò che usiamo, linguaggio [b]incluso[/b].
E' certo che se mi sono votato a PhP | Java | C# non ho altra scelta, ma qui stiamo parlando di adottare un nuovo modo di fare le cose e non solo imparare nuove grammatiche per esprimere gli stessi concetti.
Da piccolo mio zio (elettricista) mi ripeteva spesso di usare lo strumento giusto x ogni lavoro (volevo pelare un cavo elettrivo con una tenaglia).
Questo è il punto: Rails [b]è[/b] [url="http://en.wikipedia.org/wiki/Agile_software_development"]agile[/url], ma se usato fuori da questa filosofia non se ne hanno benefici evidenti, anzi grosse rotture di pa__e; Ultimamente se ne fa un gran parlare più ne sento più ho l'impressione che taluni lo facciano per "senso comune delle cose": oop, xp, semplice/complesso, pattern, agile, architetture. Fuffa.
Altri invece lo dipingono come il siccessore di Java, l'antidoto a quello che noi tutti quotidianamente definiremmo "Sviluppo software". Fuffa.
Due spunti personali
[list]
[*] Ruby è un'ottima soluzione, un linguaggio x molti aspetti di nuova generazione (e IMVHO anche una 'gustosa' sfida per esercitare alcuni dei miei neuroni più pigri)
[*] Rails è una risposta ad alcune problematiche dello sviluppo di web-app odierne.
[/list]
...quello che (non) ho ancora capito è se lo è anche per la domanda che avete in mente
Riguardo al topic: sei pronto a coinvolgere i tuoi clienti nel processo di sviluppo ed adottare (leggasi erudire i tuoi colladoratori) un metodo di sviluppo agile? Se la risposta è 'hmmm, forse', 'no!', 'ci devo pensare', 'non ho capito la domanda', 'mi piacerebbe, ma...' scaricati un buon tutorial su PHP5 e comincia.
PS: Ci lavoro, tutto sommato mi piace, a volte pure ci gioco, altre vorrei aprire un chiosco al mare, ma... non vorrei cambiare: Java.
usato rails per farci un progettino d'esempio e testarne le caratteristiche ?!?!?!?! ma prima ancora di metterci le mani vi siete lasciati incuriosire da chi lo ha inventato e perchè? ...ad esempio per scoprire che è stato concepito molto prima di Java ma è rimasto nell'ombra fino a qualche anno fa (mi ricorda qualcosa a proposito di mele & Steve Jobs )Non è un pippone di retro-cultura informatica, ma sviluppo di applicazioni (non solo web): nello scegliere gli strumenti di lavoro sarebbe (!) più produttivo quantomeno sapere quali sono i punti di forza e le debolezza di ciò che usiamo, linguaggio [b]incluso[/b].
E' certo che se mi sono votato a PhP | Java | C# non ho altra scelta, ma qui stiamo parlando di adottare un nuovo modo di fare le cose e non solo imparare nuove grammatiche per esprimere gli stessi concetti.
Da piccolo mio zio (elettricista) mi ripeteva spesso di usare lo strumento giusto x ogni lavoro (volevo pelare un cavo elettrivo con una tenaglia).
Questo è il punto: Rails [b]è[/b] [url="http://en.wikipedia.org/wiki/Agile_software_development"]agile[/url], ma se usato fuori da questa filosofia non se ne hanno benefici evidenti, anzi grosse rotture di pa__e; Ultimamente se ne fa un gran parlare più ne sento più ho l'impressione che taluni lo facciano per "senso comune delle cose": oop, xp, semplice/complesso, pattern, agile, architetture. Fuffa.
Altri invece lo dipingono come il siccessore di Java, l'antidoto a quello che noi tutti quotidianamente definiremmo "Sviluppo software". Fuffa.
Due spunti personali
[list]
[*] Ruby è un'ottima soluzione, un linguaggio x molti aspetti di nuova generazione (e IMVHO anche una 'gustosa' sfida per esercitare alcuni dei miei neuroni più pigri)
[*] Rails è una risposta ad alcune problematiche dello sviluppo di web-app odierne.
[/list]
...quello che (non) ho ancora capito è se lo è anche per la domanda che avete in mente
Riguardo al topic: sei pronto a coinvolgere i tuoi clienti nel processo di sviluppo ed adottare (leggasi erudire i tuoi colladoratori) un metodo di sviluppo agile? Se la risposta è 'hmmm, forse', 'no!', 'ci devo pensare', 'non ho capito la domanda', 'mi piacerebbe, ma...' scaricati un buon tutorial su PHP5 e comincia.
PS: Ci lavoro, tutto sommato mi piace, a volte pure ci gioco, altre vorrei aprire un chiosco al mare, ma... non vorrei cambiare: Java.
concordo pienamente con quello che dicono ciccio ed anche michele e quindi non dico nulla di più su programmazione agile, framework e linguaggi.
Vorrei aggiungere però un grosso contro a ROR: grossa necessità di risorse (computazionali/memoria).
Ruby IMHO non è un linguaggio per una web application con milioni di datahits giornalieri, necessita di un server customizzato a dovere e gestito per l' "ambiente ruby".
Dove ti trovi dei clienti (in italia) che affronteranno la spesa di un server ad hoc per far girare un solo sito/applicazione?
Dove ti trovi un sistemista che abbia le stesse conoscenze di ottimizzazione e gestione dell'accoppiata apache/php con il trio apache/fastcgi/ruby?
oltre alla sola parte "ludica" (programmazione) quando si deve realizzare un'applicazione "pesante" bisogna andare a valutare anche come il linguaggio impatterà sul medio/lungo termine su tutti i processi tipici di tale applicazione.
Gestione/manutenzione/ottimizzazione server, aggiornamento linguaggio librerie (onestamente non so come si comporta ruby sui discorsi di retrocompatibilità)...
ciauz
Vorrei aggiungere però un grosso contro a ROR: grossa necessità di risorse (computazionali/memoria).
Ruby IMHO non è un linguaggio per una web application con milioni di datahits giornalieri, necessita di un server customizzato a dovere e gestito per l' "ambiente ruby".
Dove ti trovi dei clienti (in italia) che affronteranno la spesa di un server ad hoc per far girare un solo sito/applicazione?
Dove ti trovi un sistemista che abbia le stesse conoscenze di ottimizzazione e gestione dell'accoppiata apache/php con il trio apache/fastcgi/ruby?
oltre alla sola parte "ludica" (programmazione) quando si deve realizzare un'applicazione "pesante" bisogna andare a valutare anche come il linguaggio impatterà sul medio/lungo termine su tutti i processi tipici di tale applicazione.
Gestione/manutenzione/ottimizzazione server, aggiornamento linguaggio librerie (onestamente non so come si comporta ruby sui discorsi di retrocompatibilità)...
ciauz
Fullo, sfatiamo questo mito delle performance di php.
Per esempio, con ezpublish devi avere la cache attivata e sicuramente anche un acceleratore. Questo è un "problema" di molte applicazioni complesse in php: la curva lentezza/complessità della maggior parte delle applicazioni in php è praticamente un esponenziale, mentre con altri linguaggi magari no. E per ottimizzare devi avere sviluppatori con i contro-cazzi.
Inoltre, per quel che è la mia esperienza, qualsiasi manutenzione di applicazione che fa milioni di hits giornaliere è un lavoro per professionisti e non per sistemisti-nerd.
Cmq concordo abbastanza con la tua visione "globale", probabilmente per essere affidabili nello sviluppare soluzioni in Ruby ci si deve mettere sotto...
Per esempio, con ezpublish devi avere la cache attivata e sicuramente anche un acceleratore. Questo è un "problema" di molte applicazioni complesse in php: la curva lentezza/complessità della maggior parte delle applicazioni in php è praticamente un esponenziale, mentre con altri linguaggi magari no. E per ottimizzare devi avere sviluppatori con i contro-cazzi.
Inoltre, per quel che è la mia esperienza, qualsiasi manutenzione di applicazione che fa milioni di hits giornaliere è un lavoro per professionisti e non per sistemisti-nerd.
Cmq concordo abbastanza con la tua visione "globale", probabilmente per essere affidabili nello sviluppare soluzioni in Ruby ci si deve mettere sotto...
Per chi conosce debian/redhat ruby ha un meccanismo di aggiornamento equivalente ad apt-get/yum che si chiama [url=http://docs.rubygems.org/]gem[/url]. L'upgrade non è un problema persino dei moduli sorgenti, perchè se li scarica, li compila e li installa tutti semplicemente con un click.
Se parti da una situazione consistente quella che ti ritrovi dopo un aggiornamento è altrettanto consistente.
Data la massa di rails-app che stanno nascendo la retrocompatibilità comincia ad essere un punto chiave, ma non lo considererei un problema o almeno non più dell'eventualità che stravolgano il framework php di riferimento.
Per performance/hardware non ho riscontri di produzione per confutare la mia idea, ma ho l'impressione che, skills a parte, costi meno un sistema ruby (magari cluster di macchine low-cost) visto che serve solo apache+fastCGI; onestamente non è molto complicato realizzarlo anche per un sistemista alle prime armi.
Ovviamente la manodopera costa e non è che si trovino sys-admin con esperienza in ruby oggigiorno (almeno non in italia) ma non era così anche per linux 4 anni fa? ...come per le borsette, anche nell'IT la novità si paga.
Per chiudere il cerchio considera che, se è vero che i tempi di sviluppo di riducono del 50-70% (ma anche il 40% basterebbe) ti resta un buon margine x pagare un sysadmin
Uno spunto: agile significa anche non sviluppare un'applicazione da milioni di function points ma mezzo milione di applicazioni (cooperanti) da 5 fp l'una; [url=http://www-128.ibm.com/developerworks/webservices/newto/]SOA[/url] incalza!
Se parti da una situazione consistente quella che ti ritrovi dopo un aggiornamento è altrettanto consistente.
Data la massa di rails-app che stanno nascendo la retrocompatibilità comincia ad essere un punto chiave, ma non lo considererei un problema o almeno non più dell'eventualità che stravolgano il framework php di riferimento.
Per performance/hardware non ho riscontri di produzione per confutare la mia idea, ma ho l'impressione che, skills a parte, costi meno un sistema ruby (magari cluster di macchine low-cost) visto che serve solo apache+fastCGI; onestamente non è molto complicato realizzarlo anche per un sistemista alle prime armi.
Ovviamente la manodopera costa e non è che si trovino sys-admin con esperienza in ruby oggigiorno (almeno non in italia) ma non era così anche per linux 4 anni fa? ...come per le borsette, anche nell'IT la novità si paga.
Per chiudere il cerchio considera che, se è vero che i tempi di sviluppo di riducono del 50-70% (ma anche il 40% basterebbe) ti resta un buon margine x pagare un sysadmin
Uno spunto: agile significa anche non sviluppare un'applicazione da milioni di function points ma mezzo milione di applicazioni (cooperanti) da 5 fp l'una; [url=http://www-128.ibm.com/developerworks/webservices/newto/]SOA[/url] incalza!
io credo che rails sia lento rispetto a php liscio (e ruby liscio è più veloce di php), ma visto che il caching lo aggiungi con due linee di codice e dopo servi quasi tutto come fosse html (leggasi: sendfile) non so quanto sia un problema rilevante.
Gabriele perchè fai il timido e non linki i tuoi post su come fare il caching in ROR?
ok faccio io: [url=http://riffraff.blogsome.com/2005/12/29/il-mio-tav-caching-con-rails-parte-1/]parte uno[/url] e [url=http://riffraff.blogsome.com/2006/01/02/caching-con-rails-parte-2/]parte due[/url]
ok faccio io: [url=http://riffraff.blogsome.com/2005/12/29/il-mio-tav-caching-con-rails-parte-1/]parte uno[/url] e [url=http://riffraff.blogsome.com/2006/01/02/caching-con-rails-parte-2/]parte due[/url]
attenzione, non ho mai parlato di performance ma di esosità di risorse. Sul calcolo a virgola mobile ruby è un mostro, con prestazioni simili al perl. [url=http://shootout.alioth.debian.org/benchmark.php?test=all&lang=php&lang2=ruby]qui trovate[/url] dei bench interessanti per tutti i linguaggi, purtroppo sono limitati ad applicazioni matematiche ed ad accessi singoli. Il discorso cambia un attimo quando si parla di accessi multipli (sto cercando dei bench visti su un ng tempo fa.. appena trovo posto).
michele: SOA/Orchestrazione di Servizi/GridService/Trovagli-tu-il-nome ha un solo difetto. Overhead. per fare una minchiata fai transitare 4mb di messaggi soap/xml-rpc/trovati-tu-il-protocollo da tutti a tutti per fare l'orchestrazione con i vari service distributor attivi in giro. Se poi viene inteso come offerta di servizi "statici" (un server da un solo servizio, e solo lui lo da) allora la faccenda cambia un pochino, passi a 2mb di mex
gem lo conoscevo, ma non sapevo che ricompilasse anche.. fico.. buono a sapersi
michele: SOA/Orchestrazione di Servizi/GridService/Trovagli-tu-il-nome ha un solo difetto. Overhead. per fare una minchiata fai transitare 4mb di messaggi soap/xml-rpc/trovati-tu-il-protocollo da tutti a tutti per fare l'orchestrazione con i vari service distributor attivi in giro. Se poi viene inteso come offerta di servizi "statici" (un server da un solo servizio, e solo lui lo da) allora la faccenda cambia un pochino, passi a 2mb di mex
gem lo conoscevo, ma non sapevo che ricompilasse anche.. fico.. buono a sapersi
Add Comment
MySelf
In breve: 34 anni, friulano, vivo a Roma, lavoro nel web come user experience consultant.
Nel tempo libero mi dedico alla fotografia e alla natura.
Puoi contattarmi via mail e Skype.
Descrizione completa
Linkedin profile
Bookmarks
Fotografie
PublicBrain
View blog reactions
Scambio link, no grazie!
Mail indesiderate, no grazie!
Nel tempo libero mi dedico alla fotografia e alla natura.
Puoi contattarmi via mail e Skype.
Descrizione completa
Linkedin profile
Bookmarks
Fotografie
PublicBrain
View blog reactions
Scambio link, no grazie!
Mail indesiderate, no grazie!
Quicksearch
Lavora con me
Web user experience
[17/07/08] Cosa togliere (less is more)
[16/07/08] Scorecards per definire le priorità
[10/07/08] Design Epicentrico
[04/07/08] Internet Explorer e i costi della compatibilità browser
[26/06/08] Form in linguaggio naturale
[13/05/08] Definire le priorità di un progetto
[29/04/08] Slide dell'IA Summit 08 americano e video del FOWD
[28/04/08] Swimlanes: deliverable da collezione
[23/04/08] Prima gli utenti (Last.fm blues)
[07/04/08] Web giocoso e Bruno Munari
[16/07/08] Scorecards per definire le priorità
[10/07/08] Design Epicentrico
[04/07/08] Internet Explorer e i costi della compatibilità browser
[26/06/08] Form in linguaggio naturale
[13/05/08] Definire le priorità di un progetto
[29/04/08] Slide dell'IA Summit 08 americano e video del FOWD
[28/04/08] Swimlanes: deliverable da collezione
[23/04/08] Prima gli utenti (Last.fm blues)
[07/04/08] Web giocoso e Bruno Munari
!Evenz
Categorie
FeedMe
Penso e faccio
Tags
6nations , adsl , ajax , apple , arrampicata , aziende , barcamp , beppe grillo , blog , business , calcio , cms , community , comunicazione , cordenons , donne , ecommerce , elezioni , ezpublish , firefox , flickr , folksonomy , foto , framework , friuli , futuro , gaudio , giornalismo , google , google analytics , iasummit , information architecture , italia , lavoro , libri , linux , mercato , microformats , mondiali , montagna , motori di ricerca , musica , myblog , nova24 , olipal , opensource , php , politica , politiche2006 , privacy , project management , prototipazione , prototyping , roma , rss , rubyonrails , rugby , scalability , self , seo , skype , skypecast , snoopy , social network , soldi , spam , stats , technorati , telecom , tempo , trasporti , trekking , tumblelog , usabilità , usability , user centered design , user experience , user king , vacanze , viaggi , video , web 2.0 , web application , web design , webdays , weinberger , wiki , yahoo , zen
La piccola rivoluzione dei framework Michele aggiunge complessità al problema, presentandoci un nuovo framework, stavolta per Python. Ora, magari mi sbaglio, ma se qualcuno cerca e sceglie bene secondo me fa un buon investimento per il futuro.
Tracked: Jan 09, 11:29