Ruby ed enterprise

Effettivamente anche a me fa un po’ paura la situazione
retrocompatibilit e aggiornamenti. Avevo posto una domanda su questo
forum tempo fa circa gli aggiornamenti di Ruby che anche nelle
versioni minor rompono i programmi per mancata compatibilit.
Per me che vengo dal mondo .NET “sconvolgente” perch passare dal Fx
2.0 al 4.0 un’operazione indolore.

Mi sono fatto una ragione perch come dice Duncan Rails + veloce a
prendere le novit che arrivano dal web e soprattutto non vincolandosi
al passato pu crescere meglio (ad esempio Java IMHO rimasto
indietro rispetto a C# proprio per i vincoli di compatibilit che
vuole mantenere).
L’altra ragione : nessuno ti obbliga a migrare alla nuova
versione…vabb questa vera solo se non fai grosse manutenzioni
all’appplicazione :-).

Aggiungo che a me sembra che l’ecosistema Ruby sia l’ideale per un
team skillato e motivato…per i monkey-dev forse meglio qualcosa
di pi “tranquillo” e legacy :slight_smile:

ema

2011/7/14 Michele C. [email protected]:

Il 14/07/2011 16:30, Michele C. ha scritto:

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.

guarda, nemmeno io voglio fare il difensore di ruby/rails tout-court,
quello
che dici fondamentalmente vero, ma anche vero che nessuno ti obbliga a
cambiare versione. molte web apps girano su versioni 1.x, questo non
significa
che l’aggiornamento a versioni superiori sia facile ed indolore (quando
mai lo
stato in altri ambiti?), ma comunque un fatto da tenere presente.

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.

se vuoi rimanere al passo, devi adeguarti

non che sia per forza un pregio, ma fa parte dell’ecosistema ruby
evolversi cos
rapidamente. anche perch non che gli aggiornamenti siano sterili,
normalmente
aggiungono funzionalit (spesso) richieste e/o apprezzate dagli
sviluppatori.

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.

con tutto il rispetto per Python e gli sviluppatori di Django, anche io
provengo
da l. forse sarebbe meglio dire “scappato” :stuck_out_tongue: ricordo ancora le
mazzate che
ho preso quando ho provato a studiarlo. all’epoca stava per uscire la
1.0 e
c’erano gi i libri che dicevano di puntare per quella versione (che se
non
ricordo male la “stabile” era la 0.97). morale: soldi sprecati, NON
funzionava
nemmeno un “hello world” ed in rete se ne parlava pochissimo. ogni
settimana
cambiavano qualcosa ed era davvero difficile stargli dietro. sicuramente
dopo 3
anni le cose saranno cambiate, ma nel frattempo sono approdato a
ruby/rails
definitivamente, e non mi sono pi guardato indietro :wink:

ciao,
A.

On Jul 14, 2011, at 4:30 PM, Michele C. wrote:

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.

Zooppa e’ partito su Rails 1.0, e’ passato a Rails 2, e ora chi e’
rimasto (non io quindi) lo sta portando a Rails 3.
Questo progetto su 2.3 che livello di testing ha? Cosa dice rcov?

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.

Ma che ca*zo e’ 'sto mondo enterprise? Neanche mongo/couchDB sono “per
il mondo enterprise”. Neanche Erlang, le variabili di stato sono “mondo
enterprise”.
Che vuol dire, “vecchio” ?

ngw

2011/7/14 Emanuele DelBono [email protected]

Aggiungo che a me sembra che l’ecosistema Ruby sia l’ideale per un
team skillato e motivato…per i monkey-dev forse meglio qualcosa
di pi “tranquillo” e legacy :slight_smile:

ema

Per me l’opposto, a volte i monkey-dev son cos perch gli vengono
imposte
scelte poco qualificante, ho visto gente a cui stata lanciata una sfida
rispondere in modo molto positivo, difficilmente si fa i programmatori
per
caso, spesso stata una scelta, magari frustata dall’azienda in cui si
andati a lavorare.

2011/7/14 Roberto De Ioris [email protected]

Partendo dal presupposto che per me l’Enterprise e’ una e una sola (Lunga
vita e’ prosperita’ TM), direi che si’, in campo
informatico mi sono convinto che significa proprio “vecchio” :slight_smile:

+1


Le informazioni trasmesse attraverso la presente e-mail ed i suoi
allegati
sono diretti esclusivamente al destinatario e devono ritenersi riservati
con
divieto di
diffusione e di uso.
La diffusione e la comunicazione da parte di soggetto diverso dal
destinatario è vietata dall’art. 616 e ss. c.p. e dal d. l.vo n. 196/03.
Se la presente e-mail ed i suoi allegati fossero stati ricevuti per
errore
da persona diversa dal destinatario siete pregati di distruggere tutto
quanto ricevuto e di informare il mittente con lo stesso mezzo.

Il giorno 14/lug/2011, alle ore 16.52, Nicholas W. ha scritto:

Zooppa e’ partito su Rails 1.0, e’ passato a Rails 2, e ora chi e’ rimasto (non
io quindi) lo sta portando a Rails 3.
Questo progetto su 2.3 che livello di testing ha? Cosa dice rcov?

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.

Ma che ca*zo e’ 'sto mondo enterprise? Neanche mongo/couchDB sono “per il mondo
enterprise”. Neanche Erlang, le variabili di stato sono “mondo enterprise”.
Che vuol dire, “vecchio” ?

Partendo dal presupposto che per me l’Enterprise e’ una e una sola
(Lunga vita e’ prosperita’ TM), direi che si’, in campo
informatico mi sono convinto che significa proprio “vecchio” :slight_smile:


Roberto De Ioris
http://unbit.it

concordo che enterprise s’ha di stantio, ma di questo si sta parlando
(guarda il titolo) … oh per la cronaca io sviluppo principalmente con
il cobol, e se non e’ enterprise quello :slight_smile:

Per applicazioni enterprise intendo applicativi che hanno una base dati
articolata e funzioni di elaborzione complesse (ad esempio la gestione
di polizze assicurative [sara’ forse che lavoro in una assicurazione?]).
La parte web è solo una minuscula parte di tutto quello che c’e’ dietro.
E qui entra in funzione il (buon) vecchio mainframe e tutto quello che
comporta cobol, cics e db2/oracle.
Non fatevi illusioni, anche chi credere di essere lontano da questo
mondo si sbaglia. Ogni volta che accedete al sito della banca, cosa
pensate ci sia dietro? Con quale metodologia agile credete che venga
controllato il saldo del c/c? Vi assicuro che è tutto cobol (sara’ forse
che ho lavorato anche in banca?)
PS quando inizia a lavorare in ambito informatico (1998) c’erano ancora
applicativi in assembler e il cobol 1 era la tecnologia agile , con
l’avvento del cobol II … wow una ventata di aria nuova :smiley:

Si possono avere applicazioni miste rails 1 e rails 3, ma sono due
framework differenti e la manutenzione potrebbe essere complicata.

P.S. usando Django dalla 0.96 per arrivare alla 1 non ho visto tutte
queste difficolta’.

Il giorno 14 luglio 2011 17:08, Luca De Marinis [email protected] ha
scritto:

2011/7/14 Roberto De Ioris [email protected]

Partendo dal presupposto che per me l’Enterprise e’ una e una sola
(Lunga
vita e’ prosperita’ TM), direi che si’, in campo
informatico mi sono convinto che significa proprio “vecchio” :slight_smile:

+1

+1

Ciao
Sergio

p.s. leggendo la mail sentivo in sottofondo la sigla di Star Trek.
Forse era solo immaginazione … basta con questi informatici trekkiani
:slight_smile:

Bellissima la lista.
Comunque tu sei l’esempio che Rails pu entrare nell’enterprise :wink:

Ema

Che ignoranti che siete :smiley:
Per sapere se il vostro linguaggio e’ Enterprise basta rispondere alle
seguenti domande:

  1. ci sono corsi mangiasoldi che possono certificare che sei un master
    nel suddetto linguaggio?
  2. ci sono (noiosissimi) tomi dai 3 ai 5 Kg dedicati al suddetto
    linguaggio?
  3. e’ il suddetto linguaggio creato e supportato da una megaditta?
  4. c’e’ una hotline in india che posso chiamare in caso abbia un
    problema (con il suddetto linguaggio)?
  5. c’e’ un CD di installazione del suddetto linguaggio?
  6. e’ il suddetto linguaggio coperto da una garanzia in caso di
    malfunzionamento?

Enterprise e’ la calda coperta che conforta il manager inetto che
adora il suo “cushy job” (lavoro dove non muovi il culo).
Ma Enterprise e’ anche la corda che tiene insieme reparti IT che non
si vogliono muovere di un millimetro dal mondo Entrerprise (vedi le
ragioni/domande di sopra).

Lavoro alla ABC a Sydney, una delle principali TV in Australia.
Stiamo ricostruendo in Rails3 un portale scritto in ASP (classic)
circa 10 anni fa’. Il mio supervisor si e’ guardato in giro, ha
valutato le opzioni (propietarie e non) e poi ha deciso per Rails. Ha
assunto un team di sviluppatori interni alla compagnia, e un team di
contractors per gestire ed aiutare il port.
Lo sdogamento di Rails e’ avvenuto grazie al nulla osta per servirsi
di hosting esterno. Se non avessimo potuto fare hosting esterno
(EngineYard) le tecnologia era limitata a quello che il reparto IT
dell’azienda puo’ supportare (.NET).

Ceo,
Enrico

Tutto può entrare nell’enterprise basta convincere i propri capi e per
farlo servono motivazioni come il punto 3 ed il punto 6 di Enrico.
Noi siamo riusciti ad utilizzarlo ed i risultati sono ottimi, sviluppo e
manutenzione sono più semplici. L’unica cosa è che, come scriveva
Michele, lo sviluppo di rails è troppo caotico, dovrebbero separare le
patch di sicurezza dal resto che andrebbe concentrato in due-tre rilasci
l’anno. Non si può lavorare continuamente per aggiornare un applicativo
che in un amb-iente enterprise è più complesso e più lento.

Ciao
Marco