Ciao a tutti
Non sono (ancora) un vero programmatore Rails, sto studiando e
imparando e ammetto che Ruby e Rails sono ottimi strumenti per
realizzare applicazioni web.
Ho per la sensazione che RubyOnRails (e lo stesso Ruby) non siano
considerati validi per applicazioni “Enterprise” (usate la vostra
versione per la parola Enterprise) e sinceramente non capisco quali
siano i motivi.
Sembra che nel mondo .NET (e credo anche nel mondo Java) le
applicazioni debbano essere montagne di architetture, pattern, DI,
layer, ecc…e quindi il semplice Active Record sia relegato ad
applicazioni amatoriali.
Volevo un parere da chi usa RoR per “campare” per capire come visto
nelle aziende e perch, almeno in Italia, sia cosi poco diffuso.
Ciao
–
ema
Credo che Rails e Ruby siano maturi per essere utilizzati
nell’enterprise
e ne la conferma che diverse (ex) startup lo abbiano usato per tener su
un bel p di lavoro.
Solitamente il problema nelle grandi aziende uno, cio il boss che deve
decidere la tecnologia da usare. Se usa Java o .NET e va male, dir che
non poteva far altro, che le scelte fatte erano le ‘migliori’. Se invece
rischia
di usare tecnologie nuove, avr il sedere che gli brucia se qualcosa non
va
bello diritto.
Detto questo, Rails con la versione 3 ha fatto un grande salto in avanti
con
un’architettura pi chiara e pensata. Inoltre esistono diversi interpreti
Ruby e
soluzioni come JRuby, in questi casi, aiuta non poco a convincere i
grandi
capi.
2011/7/12 Emanuele DelBono [email protected]
Il giorno 12 luglio 2011 20:54, Emanuele DelBono
<[email protected]
ha scritto:
applicazioni debbano essere montagne di architetture, pattern, DI,
layer, ecc…e quindi il semplice Active Record sia relegato ad
applicazioni amatoriali.
I miei 2 cents.
Guarda, la semplicit (poi relativa) di Rails rispetto alla montagna di
pattern e antipattern Enterprise un suo punto di forza: possibile fare
di pi con meno risorse. Essendoci passato dal mondo Enterprise posso
dire
che il 95% di quei pattern e architetture sono inutili, portano a
lievitare
i costi e a complicare i progetti, e vengono imposti perch “si vendono”.
E quindi la maggior parte delle societ di consulenza sputa sopra a Ruby
(perch se posso utilizzare una tecnologia che fa spendere meno al
cliente,
io che fatturo a giornate poi fatturo meno).
Matteo
On 12 Jul 2011, at 20:54, Emanuele DelBono wrote:
Non sono (ancora) un vero programmatore Rails,
Io non sono nemmeno un programmatore, e quindi farei meglio a starmene
zitto 
Ho per la sensazione che RubyOnRails (e lo stesso Ruby) non siano
considerati validi per applicazioni “Enterprise”
Dal mio punto di osservazione, quello che a prima vista manca
all’ecosistema ruby per essere utilizzabile per software enterprise (che
comunque nella mia visione al 90% esclude roba in .net) la mancanza[*]
di:
- transazioni distribuite
- clustering applicativo
Con “enterprise” intendo installazioni grosse e nelle quali dove anche
se c’ un interfaccia web a fare da frontend la parte complessa quella
di backend, dove spesso esiste una logica molto strutturata e magari si
parla con svariati altri sistemi legacy (tipicamente database e MOM).
Torquebox (http://torquebox.org/ - jruby su jboss, per spiegarlo in 2
parole) potrebbe aiutare a tappare questi buchi, ma ancora un po’
giovane.
Quanto sopra dal punto di vista puramente tecnologico, ci sono - e sono
importanti - anche tanti altri fattori relativi allo staffing, alla
sicurezza che viene percepita nell’utilizzare tecnologie consolidate e
cos via.
My 0.02,
[*] con /mancanza/ intendo che AFAIK non ci sono modi standard, ben
conosciuti e collaudati per fare quanto sopra. Poi ovviamente tutto si
pu scrivere…
Il 13 luglio 2011 15:07, Matteo C. [email protected] ha
scritto:
[…] il 95% di quei pattern e architetture sono inutili, portano a lievitare
i costi e a complicare i progetti, e vengono imposti perch “si vendono”.
E quindi la maggior parte delle societ di consulenza sputa sopra a Ruby
(perch se posso utilizzare una tecnologia che fa spendere meno al cliente,
io che fatturo a giornate poi fatturo meno).
Concordo.
In molti linguaggi la proliferazione esponenziale di classi e
interfacce, oltre una certa soglia (peraltro piuttosto bassa) quasi
inevitabile, e solo uno sforzo continuo e rigoroso pu riuscire ad
arginarla almeno in parte. Questo vale soprattutto per Java, .Net
almeno ha i delegate, che ti fanno risparmiare un po’ di salute.
Ci ha portato per imitazione all’instaurarsi, in ambienti Enterprise,
di un cargo cult dell’architettura complessissima.
Alcune feature di Ruby (ad esempio l’utilizzo di messaggi e closure e
il fatto che le classi siano first-class object) permettono di
contenere enormemente il numero di classi, cos che necessario
(quasi) solo create le classi business, e non anche le classi o
interfacce “ponte” tra un oggetto e l’altro.
Per quel che mi riguarda, gli unici due motivi validi per non usare
Ruby in un progetto sono la mancanza di sviluppatori Ruby all’interno
del team e la necessit di integrare codice legacy (quest’ultima
motivazione perde per via via di valore al maturare di Jruby e
IronRuby).
pietro
Concordo con le vostre risposte.
Aggiungo un fattore psicologico. Mi sembra che nelle aziende l’uso di
Java/.NET dia una (finta) sensazione di sicurezza (un po’ quello che
diceva AndreaR): siccome dietro c’ Sun/Microsoft sono tranquillo che
in qualche modo ne vengo fuori.
Per non tengono conto della produttivit e della riduzione dei costi
che pu dare uno strumento come Rails che grazie alla community e alle
gemme (che IMHO fanno davvero la differenza rispetto a .NET)
permettono di avere a disposizione librerie pronte all’uso in poco
tempo.
Io vengo da .NET (in realt ci sono ancora dentro) ma da quando ho
iniziare a lavorare con Rails molte mie certezza stanno
vacillando…sto vedendo la luce? 
In questo periodo sto cercando una nuova occupazione e sto facendo
colloqui con alcune aziende, colloqui che spesso diventano conversazioni
sullo stato del mercato IT e simili.
Durante una di queste conversazioni, un direttore tecnico di un’azienda
non grande ma in crescita che mi sembrata molto ben organizzata sul
versante software (con anche alcuni elementi di “agilit”) mi ha
commentato che dal suo punto di vista e per i suoi progetti Ruby non
sufficientemente scalabile e performante e che quindi non pu prenderlo
in considerazione se non per pezzi minori del suo sistema. Ha aperto un
po’ di porta per Ruby Enterprise Edition.
Cos mi stato raccontato, cos vi riporto.
–
Alessio B. [email protected]
Stop starting, start finishing.
On Jul 14, 2011, at 9:54 AM, Alessio B. wrote:
In questo periodo sto cercando una nuova occupazione e sto facendo colloqui con
alcune aziende, colloqui che spesso diventano conversazioni sullo stato del
mercato IT e simili.
Durante una di queste conversazioni, un direttore tecnico di un’azienda non
grande ma in crescita che mi sembrata molto ben organizzata sul versante software
(con anche alcuni elementi di “agilit”) mi ha commentato che dal suo punto di
vista e per i suoi progetti Ruby non sufficientemente scalabile e performante e
che quindi non pu prenderlo in considerazione se non per pezzi minori del suo
sistema. Ha aperto un po’ di porta per Ruby Enterprise Edition.
Scalabilita’ e performance prese senza un metro sono buzzword, cosa che
tendo sempre a far notare quando qualche “responsabile” mi accenna
questi problemi. Dal 2000, tra il software non scalabile ricordo: MySQL,
Linux, Samba, Python, Java (C++ non ha una VM ne un GC, questo si
diceva, l’informatica e’ l’unico ambito in cui una tecnologia viene
valutata specialmente per quello che non ha), PHP, nginx, e chi piu’ ne
ha piu’ ne metta.
Quando invece si comincia a legare una tecnologia ad un task si riesce a
ragionare decentemente, e a capire se tale tecnologia puo’ essere
d’aiuto o meno.
Io, ad esempio, non so cos’e’ questo “enterprise”, non l’ho mai capito e
non credo lo capiro’ in questa vita. Se questo signore magari dice che
cos’e’ sufficientemente performante e sufficientemente scalabile e
magari anche per fare cosa, si puo’ abbozzare una risposta.
ngw
Il 13 luglio 2011 20:28, Andrea P. [email protected] ha scritto:
Quanto sopra dal punto di vista puramente tecnologico, ci sono - e sono
importanti - anche tanti altri fattori relativi allo staffing, alla sicurezza che
viene percepita nell’utilizzare tecnologie consolidate e cos via.
Pienamente d’accordo su questo ultimo aspetto: viene percepita poca
“sicurezza” da parte dell’ecosistema Ruby/RoR.
–
Carlo P.
email: [email protected]
twitter: @carlopecchia
++1
Concordo in pienissimo.
La cosa buffa che girando come consulente in queste “enterprise”
vedo software che scritto nelle stored procedure (quindi in SQL),
tanto SqlServer scala…o no? Allora perch mi chiamano per problemi
di performance?
Sono buzzword da capo-progetto. Io credo che per realt medio-grandi
italiane (quindi lasciamo perdere google, amazon, ecc…) puoi scalare
con qualsiasi linguaggio, basta saper scrivere il software.
2011/7/14 Paolo P. [email protected]:
2011/7/14 Nicholas W. [email protected]:
Scalabilita’ e performance prese senza un metro sono buzzword, cosa che tendo
sempre a far notare quando qualche “responsabile” mi accenna questi problemi. Dal
2000, tra il software non scalabile ricordo: MySQL, Linux, Samba, Python, Java
(C++ non ha una VM ne un GC, questo si diceva, l’informatica e’ l’unico ambito in
cui una tecnologia viene valutata specialmente per quello che non ha), PHP, nginx,
e chi piu’ ne ha piu’ ne metta.
Quando invece si comincia a legare una tecnologia ad un task si riesce a
ragionare decentemente, e a capire se tale tecnologia puo’ essere d’aiuto o meno.
Io, ad esempio, non so cos’e’ questo “enterprise”, non l’ho mai capito e non
credo lo capiro’ in questa vita. Se questo signore magari dice che cos’e’
sufficientemente performante e sufficientemente scalabile e magari anche per fare
cosa, si puo’ abbozzare una risposta.
+1
Io credo che abbia azzeccato chi nelle risposte prima del thread
accennava al fatto che con i linguaggi “enterprise fighi” puoi fare le
stesse cose che fai con Rails (ma anche Padrino direi) solo mettendoci
il triplo del tempo, facendo fatturare il triplo al tuo cliente.
Secondo me purtroppo c’ troppa gente a certi livelli che lucra sul
margine invece di inseguire il GTD.
Ma sono un po’ in fase di burn-out quindi non badate troppo alla mia
negativit… piuttosto scrivete sempre codice sicuro
Bacini
Paolo
–
“… static analysis is fun, again!”
life from an application security guy ~> http://thesp0nge.com
Tutto vero.
Aggiungerei che, all’interno delle aziende, da una parte si incontra
l’esigenza del fornitore di fatturare il pi possibile ( specie in tempi
in cui trovare clienti nuovi molto difficile) dall’altra quella del
responsabile aziendale del progetto - che spesso occupa un ruolo
intermedio- di aumentare la propria visibilit e il proprio prestigio
all’interno della gerarchia in cui si muove.
Questo porta a finanziare pi facilmente progetti Complessi, Costosi e
che creano Centri di Potere ( progetti CCCP che progetti piccoli ed
efficienti che per, proprio per la loro semplicit e mancanza di
problemi, rischiano di non essere nemmeno percepiti dai piani superiori.
Un giovane quadro si sentir ( e temo a ragione) molto pi prossimo ad un
salto di carriera se gestisce un progetto di un anno con 15 persone e
una architettura hardware e software molto complessa piuttosto che se
completa lo stesso progetto con due persone e in 3 mesi
Ciao
Luca
Il giorno 14/lug/2011, alle ore 10.18, Paolo P. ha scritto:
E’ esattamente quello che ho visto in questi anni di consulenza come
appsec specialist.
Ahim.
E’ anche la ragione perch le aziende trasano via un sacco di soldi.
Perch poi cambier il capo di quel giovane quadro ed il suo mega
progetto verr buttato a mare ed affidato ad un altro contractor amico
del nuovo capo e tutto il giro ricomincer.
Bacini
Paolo
2011/7/14 luca Terzaroli [email protected]:
2011/7/14 Nicholas W. [email protected]:
il triplo del tempo, facendo fatturare il triplo al tuo cliente.
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
“… static analysis is fun, again!”
life from an application security guy ~> http://thesp0nge.com
Sono buzzword da capo-progetto. Io credo che per realt medio-grandi
italiane (quindi lasciamo perdere google, amazon, ecc…) puoi scalare
con qualsiasi linguaggio, basta saper scrivere il software.
Si, la maggior parte di progetti/aziende/ecc... che ho visto sarebbe fortunata ad avere il problema di scaling - invece il problema e non
avere abbastanza clienti/visitatori/whatever.
Una cosa, comunque, che si puo dire di Java e compagnia varia e che
c’e un po' piu interesse per il backwards compabitlity.
Se non dedichi molte energie a stare sul ‘cutting edge’ di Rails,
rischi di essere tagliato fuori alla grande. Aggiornare a Rails 3,
per esempio, non e` una passeggiata.
–
David N. Welton
http://www.welton.it/davidw/
http://www.dedasys.com/
Il 14 luglio 2011 10:39, luca Terzaroli [email protected] ha scritto:
Questo porta a finanziare pi facilmente progetti Complessi, Costosi e che creano
Centri di Potere ( progetti CCCP che progetti piccoli ed efficienti che per,
proprio per la loro semplicit e mancanza di problemi, rischiano di non essere
nemmeno percepiti dai piani superiori.
Un giovane quadro si sentir ( e temo a ragione) molto pi prossimo ad un salto di
carriera se gestisce un progetto di un anno con 15 persone e una architettura
hardware e software molto complessa piuttosto che se completa lo stesso progetto
con due persone e in 3 mesi
Hey, occhio a non sottovalutare Ruby per! Ruby pu essere benissimo
un linguaggio adatto ai pointy-haired boss, anzi!
Nessuno vieta di prendere “Refactoring: Ruby Edition” e applicarlo al
contrario, per trasformare un insignificante progetto da 30 file e 100
righe di codice in un molto pi interessante megaprogetto da 3000 file
e milioni di righe!
Analogamente, si pu buttar via il DRY e buttarsi su RJ (repetita
juvant), si pu abbracciare il DIY invece del Don’t reinvent the
wheel.
Un po’ di creativit, insomma!
pietro
2011/7/14 Nicholas W. [email protected]
Io, ad esempio, non so cos’e’ questo “enterprise”, non l’ho mai capito e
non credo lo capiro’ in questa vita. Se questo signore magari dice che
cos’e’ sufficientemente performante e sufficientemente scalabile e magari
anche per fare cosa, si puo’ abbozzare una risposta.
Come quoto (e godo). Non ho avuto la medesima rapidit nel rispondere a
tono
quando mi sono trovato davanti anche io ai medesimi generici scetticismi
out-of-context. Ma al prossimo giro, sar pronto. Uh, se lo sar.
–
Stefano V. - @steffoz
http://stefanoverna.com
Spero di non tirarmi addosso le antipatie di tutti voi, ma io
sconsglierei ruby on rails. Ogni 3 per due esce una minor release che
cambia le carte in tavola.
Fortunatamente il mio progetto e’ in rails 2.3.5 e non cambiero’ nulla
di questo perche’ funziona (si trova in una intranet), ma il prossimo
sarà con la 3.1 e sara’ un altro framework (passatemi il termine). Con
la 3.2 ci saranno altri stravolgimenti. E’ piu’ impegnativo seguire
l’evoluzione di rails che svilupparci siti.
Io vengo da Django e le modifiche arrivano dopo anni (non i bugfix),
cosi si ha una situazione stabile per un lungo periodo, sara’ per questo
che Rails non lo considero ancora pronto per il mondo enterprise.
Il 14/07/2011 10:43, Paolo P. ha scritto:
E’ anche la ragione perch le aziende trasano via un sacco di soldi.
Perch poi cambier il capo di quel giovane quadro ed il suo mega
progetto verr buttato a mare ed affidato ad un altro contractor amico
del nuovo capo e tutto il giro ricomincer.
+1 anche da parte mia. esattamente quello che ho visto fare per anni, a
livelli abbastanza indecenti&spudorati, aneddoto epico:
- webapp in java sviluppata da circa 10 persone di 3 societ (amiche del
boss di
turno)
- totale utenti finali dell’app: ~10-15
- oltre 4 anni di sviluppo ininterrotto e costi da capogiro
- app lenta? -> raddoppiamo i processori e la ram!
- kernel panic (!!) su 3 sistemi linux differenti (distro e kernels
tutti
diversi) ogni tot giorni -> pazienza… 
- etc…
A.
2011/7/14 Michele C. [email protected]
.
Fortunatamente il mio progetto e’ in rails 2.3.5 e non cambiero’ nulla
di questo perche’ funziona (si trova in una intranet), ma il prossimo
sar con la 3.1 e sara’ un altro framework (passatemi il termine). Con
la 3.2 ci saranno altri stravolgimenti. E’ piu’ impegnativo seguire
l’evoluzione di rails che svilupparci siti.
In parte vero, per in questo momento di grossa evoluzione del WEB per
me
pi una qualit essere cos liquidi che un problema.
2011/7/14 Duncan [email protected]:
In parte vero, per in questo momento di grossa evoluzione del WEB per me
pi una qualit essere cos liquidi che un problema.
Adesso mi faccio odiare io… considerazione a naso… il livello di
competenza dei decision maker sull’approccio ad una tecnologia nuova
tale da farli fermare a “Ruby? Ma chi? Quella di Berlusconi?”
Cos lancio una provocazione.
Mi sento una mosca bianca quando parlo di code review di sicurezza…
figuriamoci uscendo dal seminato dei linguaggi di programmazione,
gi tanto che han digerito cos’ un webservice!!!
Paolo
“… static analysis is fun, again!”
life from an application security guy ~> http://thesp0nge.com