[Sviluppo WEB] .net vs java [Archivio]

dojolab

29-12-2010, 09:12

sento spesso parlare del confronto .net contro java, in parole povere il confronto si riduce a parlare sempre degli stessi termini:
- portabilità
- semplicità di programmazione e conseguentemente maggiore velocità di produzione
- costi di produzione di un servizio o tot servizi

adesso vorrei fare la classica domanda che spariglia tutto: perché nessuno cita mai python ?

Abbiamo ad esempio la più grande società fornitrice di servizi web, per altro gratuiti nella stragrande maggioranza dei casi, ma questo rientra nello schema più grande dell'advertising che nel mondo tecnico informatico, che usa python per la qualsiasi cosa.

è difficile da gestire python ? è difficile da imparare ?

Guarda, esperienza diretta: lavoro in ambito web app da molti anni oramai, prima tramite cgi (C) e poi con php; da un annetto mi sono avvicinato a Python con django e, a parte l'inizio un pò duretto, per il resto è una figata colossale :D :D, oltre che Python è veramente un bel linguaggio; peccato sia poco richiesto in ambito enterprise e lavorativo (salvo in qualche azienda, tra cui una molto grossa Italiana di cui non posso fare il nome).

Imparare Python? Una vaccata :) se hai dei rudimenti di programmazione, OOP principalmente (magari VB.NET proprio).

Quindi .net e Java sono giustamente delle tecnologie a cui bisogna puntare per 'lavorare'. Io le ho provate entrambi e, sinceramente, .net l ho trovato più pulito di Java per quanto riguarda asp.net stesso e lo sviluppo di Web App.

Dove non mi è piaciuto .net? In IIS, nella sua gestione/configurazione, nel deploy dell'app., nalla configurazione di SQL Server, ecc. (troppe GUI, mi sono perso) e nel discorso licenze (ma è a parte).

Quindi io ho optato per Java, dove con Apache-Tomcat (0 licenze e semplice da configurare) e dbms come pgsql e firebird posso ottenere eccellenti risultati. Poi se voglio esagerare sulla macchina di test... ho pure Oracle :D che con JDBC va a nozze.

Sisupoika

29-12-2010, 16:43

sento spesso parlare del confronto .net contro java, in parole povere il confronto si riduce a parlare sempre degli stessi termini:
- portabilità
- semplicità di programmazione e conseguentemente maggiore velocità di produzione
- costi di produzione di un servizio o tot servizi

adesso vorrei fare la classica domanda che spariglia tutto: perché nessuno cita mai python ?

Abbiamo ad esempio la più grande società fornitrice di servizi web, per altro gratuiti nella stragrande maggioranza dei casi, ma questo rientra nello schema più grande dell'advertising che nel mondo tecnico informatico, che usa python per la qualsiasi cosa.

è difficile da gestire python ? è difficile da imparare ?

Se parliamo di web development direi che sia .NET che Java sono tecnologie old-fashioned che non hanno nulla a che vedere con la produttivita' di frameworks come Rails (Ruby) e Django (Python) a causa della troppa configurazione e del processo di sviluppo troppo "pesante" e lento.

Purtoppo sono ancora molto popolari soprattutto presso corporates che preferirebbero avere qualcuno da portare in tribunale se qualcosa va storto a causa della tecnologia usata, vedi banche etc. :D

Almeno questo e' il mercato IT qui in UK. Aziende grandi o di vecchia mentalita' diciamo tendono a preferire (ed assumere per) .NET e Java, mentre giovani startups che hanno bisogno di sfornare prodotti velocemente e con budgets limitati, preferiscono soprattutto Rails (e FOSS in generale), seguito in minor misura da Django e altri simili.

Python non e' difficile da imparare, e' soltanto diverso, cosi' come Ruby - che comunque e' il mio preferito (lavoro piu' con Sinatra e Rails).
Trattandosi di linguaggi dinamici e dynamically typed (che NON sono la stessa cosa, come molti credono), possono condizionare in maniera significativa come le applicazioni vengono sviluppate e come funzionano, rispetto a linguaggi statici.

Un esempio e' il meta programming, che ti consente ti modificare a runtime il comportamento e la natura di un qualsiasi oggetto sia class level che instance level senza toccare l'oggetto originale se vuoi, cosa non direttamente possibile con linguaggi statici e che rende molto potente la possibilita' di fare override -o come direste in italiano- di funzionalita' di componenti e dipendenze esterne, molto, molto piu' potente che con linguaggi statici.

Come detto il mio preferito e' Ruby, che uso praticamente per tutto - dallo sviluppo vero e proprio (APIs => Sinatra, web apps => Rails) al task automation etc.

Cmq dipende anche dai requisiti in performance. A volte mi capita di fare drop di C code in Ruby per accelerare alcune cose, ma in generale Python e' molto piu' veloce, quindi lo preferirei in alcuni casi.

cdimauro

29-12-2010, 18:20

Soltanto una nota. Python, pur essendo dinamico e dinamicamente tipizzato, è anche fortemente tipizzato, al contrario di altri linguaggi (non necessariamente dinamici, ma anche statici) che sono debolmente tipizzati.

Per il resto, non posso che concordare.

khelidan1980

29-12-2010, 22:42

Sisupoika

30-12-2010, 00:05

cobol....wtf???? scherzi, vero? :D

anonimizzato

30-12-2010, 11:41

Se parliamo di web development direi che sia .NET che Java sono tecnologie old-fashioned che non hanno nulla a che vedere con la produttivita' di frameworks come Rails (Ruby) e Django (Python) a causa della troppa configurazione e del processo di sviluppo troppo "pesante" e lento.

Purtoppo sono ancora molto popolari soprattutto presso corporates che preferirebbero avere qualcuno da portare in tribunale se qualcosa va storto a causa della tecnologia usata, vedi banche etc. :D

Almeno questo e' il mercato IT qui in UK. Aziende grandi o di vecchia mentalita' diciamo tendono a preferire (ed assumere per) .NET e Java, mentre giovani startups che hanno bisogno di sfornare prodotti velocemente e con budgets limitati, preferiscono soprattutto Rails (e FOSS in generale), seguito in minor misura da Django e altri simili.

Python non e' difficile da imparare, e' soltanto diverso, cosi' come Ruby - che comunque e' il mio preferito (lavoro piu' con Sinatra e Rails).
Trattandosi di linguaggi dinamici e dynamically typed (che NON sono la stessa cosa, come molti credono), possono condizionare in maniera significativa come le applicazioni vengono sviluppate e come funzionano, rispetto a linguaggi statici.

Un esempio e' il meta programming, che ti consente ti modificare a runtime il comportamento e la natura di un qualsiasi oggetto sia class level che instance level senza toccare l'oggetto originale se vuoi, cosa non direttamente possibile con linguaggi statici e che rende molto potente la possibilita' di fare override -o come direste in italiano- di funzionalita' di componenti e dipendenze esterne, molto, molto piu' potente che con linguaggi statici.

Come detto il mio preferito e' Ruby, che uso praticamente per tutto - dallo sviluppo vero e proprio (APIs => Sinatra, web apps => Rails) al task automation etc.

Cmq dipende anche dai requisiti in performance. A volte mi capita di fare drop di C code in Ruby per accelerare alcune cose, ma in generale Python e' molto piu' veloce, quindi lo preferirei in alcuni casi.

Dio quanto ti capisco e appoggio.

Ho lavorato per anni con PHP, poi sono passato a Ruby (RoR) per "diletto" e allora ho visto LA LUCE!!!! :sofico:

Adesso lavoro principalmente in Java e passare dallo sviluppo web con Rails a Spring2/3, Ibatis, Hibernate ecc. fà venire voglia di suicidarsi.

Per carità, trovo Java un fantastico linguaggio, molto potente e versatile ma se devo guardare alla semplicità e rapidità di sviluppo siamo decisamente rimasti indietro rispetto a linguaggi dinamici come Ruby/Python e relativi framework.

Con Java devi essere molto più "rigoroso" (altrimenti nemmeno compila :D), il che ti evita sicuramente la creazione di bug "banali", dall'altra parte la mostruosa quantità di righe XML di configurazione non fà altro che rende tutto molto più "ERROR PRONE" e quando le scadenze si avvicinano sei costretto, a volte, a scrivere codice poco "ortodosso" per venire a capo di qualche problematica che ti ha fatto rallentare. Il tutto, ovviamente, a danno della manutenibilità.

Viva Ruby e Rails!!!! :D

Sisupoika

30-12-2010, 12:20

Java.... se rimanesse l'unica opzione aprirei un negozio di frutta :asd:
Lo !!!ODIO!!!

Ludo237

30-12-2010, 12:46

Java.... se rimanesse l'unica opzione aprirei un negozio di frutta :asd:
Lo !!!ODIO!!!
:mano: :mano: :mano:

dojolab

30-12-2010, 12:55

Quanto odio :D
Io arrivo da PHP e qualche mese fa ho iniziato ad usare Python e DJango.

Java lo uso per 'lavoro'. :)

Freaxxx

30-12-2010, 14:05

non per sapere i fattacci vostri: ma mi date una idea di quello che si intende per applicazione aziendale, a conti fatti ?

quindi alla fine Ruby e Python pagano lo scotto di non avere una azienda grande alle spalle che li rappresenti? quindi devo desumere che di cause contro Sun, Oracle e Microsoft ce ne siano a quintalate :D

tomminno

30-12-2010, 15:02

eraser

30-12-2010, 15:33

Java.... se rimanesse l'unica opzione aprirei un negozio di frutta :asd:
Lo !!!ODIO!!!

Non posso concordare di più :read:

anonimizzato

30-12-2010, 18:18

Già che parlate di old-fashioned mi fate capire un esempio di quanto possano essere più produttivi Rails o Django per la realizzazione di tabelle html con la visualizzazione di operazioni CRUD, ordinamento, paginazione, esportazione in pdf, excel, word, colonne riordinabili a piacere dall'utente, customizzazione di ogni elemento tramite Css.

Un ordine di grandezza è difficile da dare perchè dipende molto dalla conoscenza che hai dei linguaggi e dei framework utilizzati.
Comunque sia con Rails, secondo me, si può fare quanto hai citato sopra nella metà del tempo che si impiegherebbe con lo SpringFramework + Hibernate/iBatis.

Cosa intendete esattamente per maggiore produttività?
Perchè lavorando in un posto dove di tabelle come le summenzionate ne vengono realizzate circa 100 l'anno strumenti che possano essere molto produttivi da questo punto di vista fanno comodo.

Per produttività io intendo la quantità (al pari della qualità) di lavoro svolto in base al tempo e alle energie dedicate ad esso.

Sisupoika

30-12-2010, 18:50

non per sapere i fattacci vostri: ma mi date una idea di quello che si intende per applicazione aziendale, a conti fatti ?

Beh, rispondo per me. Nel mio caso per "applicazioni" intendo APIs di una certa dimensione e applicazioni che consumano queste APIs, il tutto facente parte di una piattaforma di advertising online, che e' il mio lavoro al momento.

Con Ruby e frameworks come Sinatra (per API) e Rails (per le applicazioni che consumano queste API), ho scritto direttamente o guidato (come head of development) lo sviluppo di una piattaforma di advertising in pochi mesi. E la API principale si occupa di data collection, data cleansing & validation, e delivery verso i clients (advertisers).

Se avessi scritto un sistema simile in Java, c'avrei/avremmo impiegato anni :asd:

quindi alla fine Ruby e Python pagano lo scotto di non avere una azienda grande alle spalle che li rappresenti? quindi devo desumere che di cause contro Sun, Oracle e Microsoft ce ne siano a quintalate :D

Un po' si', anche se come detto la mentalita' in proposito sta cambiando eccome, visti gli indubbi vantaggi.

Prova a cercare su http://www.cwjobs.co.uk/ per Ruby jobs, per esempio.

Già che parlate di old-fashioned mi fate capire un esempio di quanto possano essere più produttivi Rails o Django per la realizzazione di tabelle html con la visualizzazione di operazioni CRUD, ordinamento, paginazione, esportazione in pdf, excel, word, colonne riordinabili a piacere dall'utente, customizzazione di ogni elemento tramite Css.

Cosa intendete esattamente per maggiore produttività?
Perchè lavorando in un posto dove di tabelle come le summenzionate ne vengono realizzate circa 100 l'anno strumenti che possano essere molto produttivi da questo punto di vista fanno comodo.

E poi se il lavoro viene affidato all'esterno non è che se ho 10 team mi ritrovo con 10 volte il calendario o anche la tabella reimplementata in maniera diversa a seconda di come gira al team di turno e magari non tutte customizzabili allo stesso modo?

Che supporto c'è per i vari standard WS-*?
Integrazione con ESB?

Grazie per le eventuali risposte!

Per produttivita' intendevo: velocita' di realizzazione di applicazioni che siano performanti, sicure, scalabili e che si possano agevolmente e rapidamente aggiornare, ristrutturare, etc.

Non per riproporre roba cotta e ricotta quando si parla di Rails e simili, cmq i vantaggi principali sono -soprattutto per Rails:

- una implementazione pressocche' perfetta di MVC (addirittura la parte dei controllers in Rails e' rimasta piu' o meno la stessa in anni perche' era gia' stata "indovinata")

- configurazioni ridotte ad un minimo, e sostuite invece da una marea di convenzioni. Il framework propone tutta una serie di practices (nella maggioranza dei casi best practices): se semplicemente ti attieni ad esse, puoi pensare di meno ad una marea di cose e concentrarti di piu' su cio' che la tua applicazione deve fare, e come ottenerlo

- database migrations molto user friendly, e un ORM che funziona come si deve (anche se non perfetto - naturalmente parlo di ActiveRecord, visto che e' il piu' usato)

- tutta una serie di vantaggi che derivano, come gia' citato, dal fatto di usare per esempio Ruby invece che C# o Java ( :asd )

Un ordine di grandezza è difficile da dare perchè dipende molto dalla conoscenza che hai dei linguaggi e dei framework utilizzati.
Comunque sia con Rails, secondo me, si può fare quanto hai citato sopra nella metà del tempo che si impiegherebbe con lo SpringFramework + Hibernate/iBatis.

Giusto per essere carini? :D

Per produttività io intendo la quantità (al pari della qualità) di lavoro svolto in base al tempo e alle energie dedicate ad esso.

Uhm... la tua definizione e' 1000 volte meglio della mia :D

tomminno

30-12-2010, 23:48

Un ordine di grandezza è difficile da dare perchè dipende molto dalla conoscenza che hai dei linguaggi e dei framework utilizzati.
Comunque sia con Rails, secondo me, si può fare quanto hai citato sopra nella metà del tempo che si impiegherebbe con lo SpringFramework + Hibernate/iBatis.

Di Java per il web ho una limitata (e molto pessima) esperienza, utilizzo prevalentemente webservice e Mule Esb. Il mio riferimento di produttività web è .Net (Asp.Net) dove posso fare tutta l'interfaccia semplicemente selezionando quello che voglio ottenere da Visual Studio, senza scrivere una riga di codice, dove le tabelle recuperano automaticamente i campi dalla sorgente dati impostata e altrettanto automaticamente mi impostano il corretto formato di editing (date con calendari, booleani con checkbox, ecc), i css si impostano da editor grafici con preview automatica del risultato, che poi il grafico ottimizzerà per proprio conto, senza interferire con il lavoro del programmatore.

Ho già provato e scartato Asp.Net Mvc in quanto sebbene nettamente superiore come organizzazione logica delle richieste, comporta una non proporzionale maggiore "perdita di tempo" sui dettagli dell'interfaccia che non lo rende conveniente rispetto ad Asp.Net classico.
Per non parlare del fatto che i grafici devono mettersi lì a mischiare C# e html.

Non c'è la netta separazione tra i compiti del programmatore e quella del grafico in nessuno dei tool che ho mai sperimentato in quanto entrambe le figure devono intervenire sugli stessi file, Asp.Net per lo meno tiene ben separata la parte grafica dalla logica dell'applicazione, una volta che il programmatore ha stabilito cosa visualizzare il grafico si limita a ritoccare senza intervenire nella generazione dell'html.
In questo contesto ad oggi mi sembra che il più vicino all'ideale separazione dei compiti sia, strano a dirsi, Qt con QML, a confronto XAML perde per il fatto che è una sintassi estranea per qualcuno che abitualmente lavora con Css, Javascript e Flash.

Per produttività io intendo la quantità (al pari della qualità) di lavoro svolto in base al tempo e alle energie dedicate ad esso.

Si mi riferivo nel concreto riguardo al contesto web, volevo capire in cosa si è più produttivi.

tomminno

31-12-2010, 00:00

- una implementazione pressocche' perfetta di MVC (addirittura la parte dei controllers in Rails e' rimasta piu' o meno la stessa in anni perche' era gia' stata "indovinata")

Ma nella View c'è un misto di codice Ruby che genera html? Dagli esempi che ho visto in rete mi pare sia così. Se si come ti trovi quando devono intervenire i grafici? Perchè grafici e codice è un'accoppiata fallimentare, secondo la mia esperienza.
Quanto tempo impieghi per generare una View con tutti i ninnoli grafici che le scimmie utilizzatrici tanto amano?
Ogni volta c'è da riscrivere sempre le solite cose?

- configurazioni ridotte ad un minimo, e sostuite invece da una marea di convenzioni. Il framework propone tutta una serie di practices (nella maggioranza dei casi best practices): se semplicemente ti attieni ad esse, puoi pensare di meno ad una marea di cose e concentrarti di piu' su cio' che la tua applicazione deve fare, e come ottenerlo

Puoi dettagliare meglio?
A cosa non devi pensare sviluppando in Ruby?

- database migrations molto user friendly, e un ORM che funziona come si deve (anche se non perfetto - naturalmente parlo di ActiveRecord, visto che e' il piu' usato)

Sinceramente è molto difficile che un applicativo web cambi il dbms utilizzato, vuoi perchè generalmente tendi ad utilizzare comunque le peculiarità di un DBMS (già che lo usi) e che la migrazione della base dati non è che sia poi così trasparente.

- tutta una serie di vantaggi che derivano, come gia' citato, dal fatto di usare per esempio Ruby invece che C# o Java ( :asd )

Ovvero? Messa così senza una spiegazione più dettagliata di quali possano essere i vantaggi, fa un pò spot.

Sisupoika

31-12-2010, 01:26

... Il mio riferimento di produttività web è .Net (Asp.Net)

LOL, davvero non posso fare a meno di sorridere :D

dove posso fare tutta l'interfaccia semplicemente selezionando quello che voglio ottenere da Visual Studio, senza scrivere una riga di codice, dove le tabelle recuperano automaticamente i campi dalla sorgente dati impostata e altrettanto automaticamente mi impostano il corretto formato di editing (date con calendari, booleani con checkbox, ecc), i css si impostano da editor grafici con preview automatica del risultato, che poi il grafico ottimizzerà per proprio conto, senza interferire con il lavoro del programmatore.

Forse non te ne rendi conto (probabilmente perche' non hai ancora provato alternative come quelle gia' suggerite), ma hai appena descritto i piu' grossi limiti di .NET e del principale tool, Visual Studio.

Il significato di queste parole diverra' piu' chiaro quando incominci a lavorare, per esempio, con Rails. E te lo dice uno che ha 8 anni di sviluppo .NET (AVANZATO - mi basti dire che ho scritto booking engines e/o backends per aziende come Last Minute, Expedia, Travelocity, Eurostar, Easyjet, etc - quando ancora lavoravo nella travel industry e principalmente in .NET prima di spostarmi nell'advertising e lavorare con Ruby a tempo pieno da qualche anno)

Ho già provato e scartato Asp.Net Mvc in quanto sebbene nettamente superiore come organizzazione logica delle richieste, comporta una non proporzionale maggiore "perdita di tempo" sui dettagli dell'interfaccia che non lo rende conveniente rispetto ad Asp.Net classico.

Ooops... da quanto ho letto prima speravo che ALMENO tu lavorassi in MVC :D
Lavori ancora con quell'obbrobrio dei web forms? Non ho mai fatto esperienza con orrore piu' grande da quando lavoro nel web.
Se parli di perdita di tempo vuol dire che non vi hai neanche lavorato. MVC, nella sua implementazione in .NET, mi fa pena in confronto a Rails, Django e altri, ma almeno e' anni luce meglio di quei orribili web forms.

Chi lavora ancora oggi con web forms e roba simile, tanto per cominciare non ha molto a cuore le prestazioni sia server side che client side di una applicazione :D

Non te la prendere: piu' che come critica, leggi i miei commenti come un invito a provare qualcosa di meglio, da parte di uno che ha una certa esperienza con varie tecnologie e piattaforme (lavoro nel settore da 15 anni, e da 10+ con esperienze miste tra vari frameworks - tra cui appunto .NET, Rails etc, vari DBRMS, e vari OS -tra cui ovviamente Linux, e Mac OS assieme a Windows).

Alla fine poi, e' anche vero che il toolset perfetto per ognuno e' quello che piace e in cui ci si riconosce. ;)

Per non parlare del fatto che i grafici devono mettersi lì a mischiare C# e html.

La strada provata coi webforms e' stata imho un totale fallimento. Non solo Microsoft. Mai sentito parlare di http://www.visualwebgui.com/ ?
Lo e' stato -sempre imho- sin dalla concezione come idea, dal momento che non si puo' equiparare (e pertanto lavorarci sopra) il web -che e' stateless e dipendente da varie constrinzioni- ad un sistema desktop.

Parli di mischiare codice con design? Giusto. Per questo esiste MVC, e nelle implementazioni piu' corrette -come Rails- se usato e "rispettato" come si deve, non vedrai mai uno "spaghetti code" degno di questa label, e in cambio avrai migliori performance e ineguagliabile flessibilita'.

Se lavori in MVC (qualunque implementazione), ti basta seguire queste semplici regole:

- MAI eseguire queries (con un ORM o altrimenti), in un controller. MAI! Qualunque funzionalita' che ha a che fare con il contenuto o comportamento di un model, VA NEL MODEL e va esposto come metodo accessibile, o come per esempio named scope

- MAI HTML in un controller o, peggio, ritornato da un metodo da un model. Le views esistono per questo.

- MAI eseguire query o comunque business logic nelle views, che vada oltre il print di un valore o looping through a collection. Se proprio necessario, ci sono gli helpers.

Se segui queste regole con un framework MVC, hai applicazioni molto -enormemente- piu' flessibili e performanti che con webforms, e una struttura ordinata, familiare, con una perfetta separation of concerns.

Non c'è la netta separazione tra i compiti del programmatore e quella del grafico in nessuno dei tool che ho mai sperimentato in quanto entrambe le figure devono intervenire sugli stessi file, Asp.Net per lo meno tiene ben separata la parte grafica dalla logica dell'applicazione, una volta che il programmatore ha stabilito cosa visualizzare il grafico si limita a ritoccare senza intervenire nella generazione dell'html.

Dipende, con qualunque framework (persino webforms) puoi lavorare con temi, anche in modo tale che i designers possano lavorare su templates senza dover mischiare del codice. Il tutto dipende dal come le applicazioni vengono sviluppate.

Sisupoika

31-12-2010, 01:51

Ma nella View c'è un misto di codice Ruby che genera html? Dagli esempi che ho visto in rete mi pare sia così.

Si', ma parliamo del minimo necessario per fare output di valori e, come detto, looping. Ma, volendo... (=> leggi risposta alla domanda seguente)

Se si come ti trovi quando devono intervenire i grafici? Perchè grafici e codice è un'accoppiata fallimentare, secondo la mia esperienza.

Personalmente ho una serie di practices (che cerco di far adottare ad altri developers che dirigo dal momento che il mio ruolo e' anche quello di technical evangelist), che adotto in qualunque applicazione.

Se parliamo di collaborazione con designers (e, lavorando nell'advertising, ti lascio immaginare a che livelli di collaborazione parliamo), allora la soluzione da me adottata e' quella di usare linguaggi di templating disconnessi dal codice vero e proprio della applicazione.

Quello che uso quasi sempre ormai e' Liquid. E' un codice markup sul quale designers possono lavorare direttamente. Guarda per es. https://github.com/tobi/liquid/wiki/liquid-for-designers
per la sintassi.

Poi, se si tratta di applicazioni che senza JavaScript/AJAX non funzionerebbero comunque (perche' per natura sarebbero useless altrimenti), tipo data management apps, allora uso parecchio anche client side templating con jQuery; ve ne sono vari tipi, e se proprio non vuoi mischiare server side code con HTML, puoi! Puoi anche lavorare soltanto con pagine HTML statiche direttamente, e lasciare la parte dati all'applicazione per es. .NET, leggendo e manipolando dati e templates con richieste JSON.

Et voila': rendering superveloce (e incredibile cacheability grazie alle pagine in plain HTML), e nessuno spaghetti code.

Quanto tempo impieghi per generare una View con tutti i ninnoli grafici che le scimmie utilizzatrici tanto amano?
Ogni volta c'è da riscrivere sempre le solite cose?

Se hai lavorato soltanto con .NET, mettiamola cosi'. Potrei mostrarti come scrivere una applicazione seria in Rails in 1/10 del tempo che con .NET :D

Il segreto della produttivita' non sta soltanto nel linguaggio e nel framework, ma anche dai tools utilizzati. Da tempo lavoro esclusivamente su Mac per il development (e Linux servers, of course, per production environments), e uso TextMate come editor, con i suoi eccezionali bundles.

Dopo diverso tempo conosco a memoria cosi' tanti shortcuts (anche molti da me stesso creati), che potrei scrivere codice senza darti il tempo di renderti conto che il contenuto dello screen e' cambiato :asd:

Puoi dettagliare meglio?
A cosa non devi pensare sviluppando in Ruby?

Piu' che altro si tratta di caratteristiche del framework (e.g. Rails), non del linguaggio in se'. La community che sviluppa Rails (di cui sono contributor a tempo perso) decide una marea di best practices e le implementa nel framework. Poi tutta una serie di decisioni sono gia' fatte per te, diciamo, dal framework stesso. Tipo: dove mettere X e Y, come fare Z, etc. Perdi MOLTO meno tempo ad organizzare e strutturare la tua applicazione, per esempio.

Sinceramente è molto difficile che un applicativo web cambi il dbms utilizzato, vuoi perchè generalmente tendi ad utilizzare comunque le peculiarità di un DBMS (già che lo usi) e che la migrazione della base dati non è che sia poi così trasparente.

Non e' vero :D
Se dici questo vuol dire che hai lavorato solo su siti e applicazioni piccole.
Quando parliamo di scalabilita', capita SPESSO che inizi a lavorare per esempio con MySQL, per poi passare a Postgres o Oracle etc se hai bisogno di funzionalita' non disponibili all'inizio con MySQL, man mano che l'applicazione cresce. Il tutto, mentre per esempio sviluppi sulla tua macchina con Sqlite... - e' giusto un esempio, di solito uso MySQL anche in development.

Poi un altro vantaggio di un ORM database-agnostic come ActiveRecord (default in Rails) o DataMapper o Sequel etc etc etc, e' che hai a disposizione anche adattatori che ti consentono di passare da un DBRMS come MySQL ad un sistema NoSQL come MongoDB (il mio preferito), CouchDB, Cassandra, etc etc. Mi capita spesso: inizio una applicazione con MySQL quando i requisiti di scalabilita' sono bassi (per esempio, qualche master con semplice sharding, qualche slave, e splitting reads/writes), per poi passare a MongoDB quando i database e l'uso cominciano a crescere a dismisura :D

Ovvero? Messa così senza una spiegazione più dettagliata di quali possano essere i vantaggi, fa un pò spot.

Tanto per cominciare, come gia' detto Ruby e' un linguaggio totalmente dynamico. Non e' velocissimo di per se' anche per questo (anche se raramente e' un problema e, trattandosi di web apps, puoi fare ottimo caching very easily), ma col meta programming e tutto il resto e' PURE FUN :D

Mi fermo qui altrimenti scrivo un libro :D

tomminno

31-12-2010, 08:43

Ooops... da quanto ho letto prima speravo che ALMENO tu lavorassi in MVC :D

Provato e scartato, per me è improduttivo.

Lavori ancora con quell'obbrobrio dei web forms? Non ho mai fatto esperienza con orrore piu' grande da quando lavoro nel web.
Se parli di perdita di tempo vuol dire che non vi hai neanche lavorato. MVC, nella sua implementazione in .NET, mi fa pena in confronto a Rails, Django e altri, ma almeno e' anni luce meglio di quei orribili web forms.

Se parliamo di produttività Asp.Net MVC è anni luce indietro, quello che con Asp.Net faccio in 10 click con MVC devo realizzare a mano tutte le volte.

Chi lavora ancora oggi con web forms e roba simile, tanto per cominciare non ha molto a cuore le prestazioni sia server side che client side di una applicazione :D

Sinceramente problemi di prestazioni non ne ho mai riscontrate, avendo macchine bilanciate. E un server costa meno di un mese di lavoro (lordo) di una persona. Se questa persona mi deve perdere giorni dietro alla realizzazione di una banale tabella html stiamo freschi.

La strada provata coi webforms e' stata imho un totale fallimento. Non solo Microsoft. Mai sentito parlare di http://www.visualwebgui.com/ ?
Lo e' stato -sempre imho- sin dalla concezione come idea, dal momento che non si puo' equiparare (e pertanto lavorarci sopra) il web -che e' stateless e dipendente da varie constrinzioni- ad un sistema desktop.

Si parlava di produttività. La vedo difficile scrivere un tabelle come queste (http://demos.telerik.com/aspnet-ajax/grid/examples/hierarchy/nestedviewtemplate/defaultcs.aspx) con la stessa rapidità di un editor.

Parli di mischiare codice con design? Giusto. Per questo esiste MVC, e nelle implementazioni piu' corrette -come Rails- se usato e "rispettato" come si deve, non vedrai mai uno "spaghetti code" degno di questa label, e in cambio avrai migliori performance e ineguagliabile flessibilita'.

Finchè ci sarà almeno un ciclo for che genera ogni riga di una tabella ci sarà spaghetti code.

Se lavori in MVC (qualunque implementazione), ti basta seguire queste semplici regole:

- MAI eseguire queries (con un ORM o altrimenti), in un controller. MAI! Qualunque funzionalita' che ha a che fare con il contenuto o comportamento di un model, VA NEL MODEL e va esposto come metodo accessibile, o come per esempio named scope

- MAI HTML in un controller o, peggio, ritornato da un metodo da un model. Le views esistono per questo.

- MAI eseguire query o comunque business logic nelle views, che vada oltre il print di un valore o looping through a collection. Se proprio necessario, ci sono gli helpers.

Sono esattamente le stesse regole di un applicativo 3-tier.
Mai eseguire query nel business.
Mai generare html nel business.
Mai inserire logica applicativa nella visualizzazione.

Se segui queste regole con un framework MVC, hai applicazioni molto -enormemente- piu' flessibili e performanti che con webforms, e una struttura ordinata, familiare, con una perfetta separation of concerns.

Sicuramente le prestazioni sono superiori, ma si parlava principalmente di produttività.

cdimauro

31-12-2010, 08:52

Mi fermo qui altrimenti scrivo un libro :D
Ma no, dai, per me puoi continuare quanto vuoi: c'è parecchio da imparare. :D

Mi spiace soltanto che leggo poco di Python, che è il mio linguaggio preferito, ma da quel poco che ho letto e visto su Django la situazione non dovrebbe essere dissimile. :fagiano:

tomminno

31-12-2010, 09:00

Se hai lavorato soltanto con .NET, mettiamola cosi'. Potrei mostrarti come scrivere una applicazione seria in Rails in 1/10 del tempo che con .NET :D

Sarei interessato! :D
Anche perchè sono alla ricerca di qualcosa di diverso ma che mi consenta di realizzare un'applicazione web in minor tempo.

Non e' vero :D
Se dici questo vuol dire che hai lavorato solo su siti e applicazioni piccole.

Lavorando in ambito "enterprise" (parola tanto abusata) i siti web sono la parte minore del lavoro, il grosso è quello che ci sta dietro! Per questo devono essere realizzati nel minor tempo possibile, le scadenze sono sempre molto strette.

Quando parliamo di scalabilita', capita SPESSO che inizi a lavorare per esempio con MySQL, per poi passare a Postgres o Oracle etc se hai bisogno di funzionalita' non disponibili all'inizio con MySQL, man mano che l'applicazione cresce. Il tutto, mentre per esempio sviluppi sulla tua macchina con Sqlite... - e' giusto un esempio, di solito uso MySQL anche in development.

Ah ecco mai usato MySql per un sito (eccetto all'univeristà), solo SqlServer e Oracle, MySql viene usato solo dagli applicativi linux, ma niente web...
Anche perchè dietro c'è un sistema integrato, non è che il database viene creato per il sito web, il sito web è qualcosa che viene dopo o come evoluzione dell'architettura già presente.

Poi un altro vantaggio di un ORM database-agnostic come ActiveRecord (default in Rails) o DataMapper o Sequel etc etc etc, e' che hai a disposizione anche adattatori che ti consentono di passare da un DBRMS come MySQL ad un sistema NoSQL come MongoDB (il mio preferito), CouchDB, Cassandra, etc etc. Mi capita spesso: inizio una applicazione con MySQL quando i requisiti di scalabilita' sono bassi (per esempio, qualche master con semplice sharding, qualche slave, e splitting reads/writes), per poi passare a MongoDB quando i database e l'uso cominciano a crescere a dismisura :D

Che dici me le regge MongoDB tabelle da 500 milioni di righe e oltre?
MySql va un pò in crisi con tabelle di tali dimensioni.

cdimauro

31-12-2010, 09:30

anonimizzato

31-12-2010, 11:13

Sicuramente le prestazioni sono superiori, ma si parlava principalmente di produttività.

Per nulla, non c'entrano le prestazioni ma i principi di creare codice chiaro, modulare e manutenibile.

Cercare di rispettare il più possibile il paradigma MVC per una Web Application è proprio una questione di produttività immediata e, soprattutto, manutenibilità.

La separazione logica dei compiti che i componenti di una determinata applicazione svolgono sono una delle migliori pratiche da attuare quando si realizzano web-apps che siano più di 4 semplici pagine html con una banale form.

Soprattutto quando il progetto viene svolto non da un singolo sviluppatore ma da un team o anche più team (magari esterni).

tomminno

31-12-2010, 12:05

Per nulla, non c'entrano le prestazioni ma i principi di creare codice chiaro, modulare e manutenibile.

E questo lo fai solo con MVC? No fammi capire perchè questo significa che per tutti gli applicativi senza la View non è possibile scrivere codice chiaro modulare e manutenibile?

Cercare di rispettare il più possibile il paradigma MVC per una Web Application è proprio una questione di produttività immediata e, soprattutto, manutenibilità.

Per me produttività nel web è fondamentalmente il tempo impiegato a realizzare pagine con layout complessi anche con report e grafici.

La separazione logica dei compiti che i componenti di una determinata applicazione svolgono sono una delle migliori pratiche da attuare quando si realizzano web-apps che siano più di 4 semplici pagine html con una banale form.

La separazione logica delle responsabilità non è certo paradigma esclusivo dell'MVC.
E' sempre stato realizzato nei progetti ben impostati che utilizzino MVC, o Forms, o PHP o cgi o quant'altro.

Soprattutto quando il progetto viene svolto non da un singolo sviluppatore ma da un team o anche più team (magari esterni).

A maggior ragione quando su un progetto lavorano più team è essenziale avere strumenti che uniformino il più possibile lo sviluppo evitando che 10 team mi forniscano ognuno la propria revisitazione dello script per validare una data considerando l'internazionalizzazione.

Sisupoika

31-12-2010, 13:23

Provato e scartato, per me è improduttivo.

OK, fine :D

Se parliamo di produttività Asp.Net MVC è anni luce indietro, quello che con Asp.Net faccio in 10 click con MVC devo realizzare a mano tutte le volte.
Sinceramente problemi di prestazioni non ne ho mai riscontrate, avendo macchine bilanciate. E un server costa meno di un mese di lavoro (lordo) di una persona. Se questa persona mi deve perdere giorni dietro alla realizzazione di una banale tabella html stiamo freschi.

OK, hai provato .NET/MVC e non ti e' piaciuto. Perche' non provi The Real Deal (http://rubyonrails.org/)? :read:

Si parlava di produttività. La vedo difficile scrivere un tabelle come queste (http://demos.telerik.com/aspnet-ajax/grid/examples/hierarchy/nestedviewtemplate/defaultcs.aspx) con la stessa rapidità di un editor.

LOL, se parliamo di Rails hai una immensa vastita' di gems e plugins con cui puoi fare MOLTO di piu, spesso con una sola riga di codice :Prrr:

Finchè ci sarà almeno un ciclo for che genera ogni riga di una tabella ci sarà spaghetti code.

Meglio qualche riga di codice per visualizzare una tabella che una pagina che pesa 1MB solo per il crap che .NET genera per far funzionare un web form :D

E, poi, rispondi: Cosa vedi nel codice di una pagina .NET? "L'ultima volta che ho controllato" avevi dei custom tags per il rendering dei controlli. Anche essi hanno poco a che vedere con l'HTML per il design. Sono spariti o sono ancora li'? :D

Facciamo un esempio: i custom tags e tutta la configurazione di, chesso', un DataGrid, un Repeater o quello che e'. Dove li metti?

Sicuramente le prestazioni sono superiori, ma si parlava principalmente di produttività.

Se per produttivita' intendiamo come gia' suggerito meglio da altri, la quantita' di risultati prodotti a parita' di qualita', secondo la mia esperienza in passato con sia web forms che .NET w/ MVC, ho trovato comunque MVC piu' produttivo perche', in molti casi, era piu' facile riutilizzare il codice, e il codice prodotto con MVC essendo piu' accessibile nei minimi dettagli, mi ha spesso risparmiato tempo qualora dovessi aggiornare o cambiare qualcosa, in confronto a riconfigurare web forms perche' facessero cio' di cui avevo bisogno. Sara' che la mia esperienza e' stata diversa, ma comunque ritengo che web forms possa andare bene in genere e possa anche essere piu' rapido, soltanto con applicazioni tutt'altro che complesse, altrimenti - e di questo ne sono convinto! - perdi piu' tempo a far fare ad un web form cio' che ti serve che a scrivere del codice in MVC!

Cmq chiudendo questa parentesi su .NET w/ o w/o MVC, come detto io non lavoro piu' in .NET in generale da anni perche' preferisco tutt'altro modo di sviluppare, che e' quello con Ruby (e in alcuni casi Python) based frameworks.

Ti faccio un invito: guardati questi (http://www.youtube.com/watch?v=Gzj723LkRJY) video e altre demo su Rails.
In particolare i video del 2005 in cui, come esempio, viene mostrato come creare un blog engine in 15 minuti.
Perche' ti suggerisco di vedere un video del 2005? Perche' cosi' ti renderai conto di quanto piu' produttivo Rails era gia' all'epoca, poi -superato lo shock iniziale :D- ti invito ad immaginare quanto il framework sia evoluto in questi anni sino alla vesione 3.
Se quel video dimostra gia' un'alta velocita' di esecuzione nel tipico sviluppo di un progetto con Rails, sappi che la versione odierna e' diverse volte piu' produttiva grazie ad una marea di aggiornamenti, e grazie ad una immensa disponibilita' di componenti (plugins e gems) che svolgono qualunque tipo di compito e sono pronti all'uso.Altro che .NET, non c'e' paragone. Provalo! :D

Sisupoika

31-12-2010, 13:39

Ma no, dai, per me puoi continuare quanto vuoi: c'è parecchio da imparare. :D

Mi spiace soltanto che leggo poco di Python, che è il mio linguaggio preferito, ma da quel poco che ho letto e visto su Django la situazione non dovrebbe essere dissimile. :fagiano:

Non sono up-to-date con Django e Python come lo sono con Ruby, ma sinceramente ho sempre preferito 1) Ruby come linguaggio, 2) Rails come framework, soprattutto adesso che e' stato migliorato con alcune cose prese da Merb. Django e' ottimo, of course, e piu' veloce, ma davvero mi piacciono molto di piu' Ruby e Rails (e Sinatra per varie cose).

Poi visto che qui si parla di produttivita', c'e' molta piu' roba disponibile per Ruby/Rails al momento. Cmq Django e' il singolo framework che si trova sempre nelle mie frasi tipo "se non lavori in Rails, ma lavori in Django, that's OK!" :D

Sarei interessato! :D
Anche perchè sono alla ricerca di qualcosa di diverso ma che mi consenta di realizzare un'applicazione web in minor tempo.

Fai un salto qui a Londra allora. :D
Ti mostro qualcosa io stesso e ti porto anche ad uno dei nostri Ruby meetings - qui c'e' una bella community e ogni tanto, quanto capita, sono speaker anche io su topics come performance/scalability e security soprattutto. ;)

Lavorando in ambito "enterprise" (parola tanto abusata) i siti web sono la parte minore del lavoro, il grosso è quello che ci sta dietro! Per questo devono essere realizzati nel minor tempo possibile, le scadenze sono sempre molto strette.

Un motivo in piu' per passare a Rails :D

Ah ecco mai usato MySql per un sito (eccetto all'univeristà), solo SqlServer e Oracle, MySql viene usato solo dagli applicativi linux, ma niente web...

Hold on: intendi nella azienda in cui lavori, vero? Non in generale?

Anche perchè dietro c'è un sistema integrato

In che senso? Che intendi per sistema integrato?

Che dici me le regge MongoDB tabelle da 500 milioni di righe e oltre?

Puoi andare anche molto oltre. MongoDB ha un supporto sia per sharding che per replication notevole e rende molto piu' veloce e semplice scalare molto in alto.

MySql va un pò in crisi con tabelle di tali dimensioni.

Ho lavorato con MySQL data di 1.8 terabytes, con una marea di text columns (contenenti un sacco di debugging info serialized) e ~800 milioni di righe aggregate :D
Il tutto sta nell'ottimizzare i clusters, e naturalmente a progettare correttamente l'uso di sharding e replication, ancora una volta.

Ecco che mi ricordi di altri vantaggi di Rails etc: mi dici come shardi un database con .NET se, ipoteticamente, fossi Facebook con 500+ milioni di users? :D

(waits)

Ecco, appunto. :asd:
Con Rails se vuoi hai gia' la pappa bella e pronta con Data Fabric e altre gems. E tra non molto vedrai su Github la mia soluzione visto che (non appena finisco alcune cose) voglio renderla pubblica. E' una gem dai concetti molto simili a Data Fabric, in piu' ha il supporto per database multipli :D
piu' altre cose tipo supporto nativo per serialized tableless models e altre chicche.

Un lavoro simile in .NET avrebbe richiesto anni di ricerca :D

Sisupoika

31-12-2010, 13:46

Dipende da quello che devi farci con quelle milioni di righe. MongoDB scala decisamente meglio di un qualunque engine SQL, MySQL incluso, ma hai a che fare con "collezioni di dati", dati senza una rigida struttura.

Come ho già detto altre volte, preferisco un engine SQL "tradizionale", e opto per qualcosa di NoSQL (MongoDB mi piace rispetto ad altre soluzioni) soltanto se ho più problemi che benefici lavorando con gli strumenti usuali.

In alcuni casi purtroppo e' anche vero che decidere in anticipo per una soluzione tipo MongoDB, CouchDB o simili, puo' salvarti un bel po' di noie in futuro se l'applicazione cresce velocemente.

Adoro l'idea di gestire i dati in maniera gerarchica eliminando molte associations, pero' purtroppo la difficolta' principale che ho incontrato in questi casi e' stata proprio definire in anticipo una struttura dati adeguata.
More often than not, ho dovuto cambiare parecchio lungo il percorso di crescita di una applicazione/sistema.

Cmq mi veniva in mente di menzionare un'alternativa a MongoDB e simili che si basa invece sul buon vecchio MySQL. Vi sono varie implementazioni che usano MySQL come key/value store e spesso sono piu' veloci che usando MySQL normalmente :D

Una recente e very cool e':
https://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL

Sempre a proposito di MySQL, vorrei aggiungere alcune note @tomminno a proposito di performance con grandi database.

Con database grandi, qualche versione di MySQL usi? La standard? Prova la build di Percona invece.

Poi usa InnoDB plugin invece del built in InnoDB support.
E poi, quanta memoria dedichi all' innodb buffer?

Sisupoika

31-12-2010, 13:50

Per nulla, non c'entrano le prestazioni ma i principi di creare codice chiaro, modulare e manutenibile.

Cercare di rispettare il più possibile il paradigma MVC per una Web Application è proprio una questione di produttività immediata e, soprattutto, manutenibilità.

La separazione logica dei compiti che i componenti di una determinata applicazione svolgono sono una delle migliori pratiche da attuare quando si realizzano web-apps che siano più di 4 semplici pagine html con una banale form.

Soprattutto quando il progetto viene svolto non da un singolo sviluppatore ma da un team o anche più team (magari esterni).

QUOTO, indeed

E questo lo fai solo con MVC? No fammi capire perchè questo significa che per tutti gli applicativi senza la View non è possibile scrivere codice chiaro modulare e manutenibile?

Con webforms, molto del codice neanche lo vedi. E' questo il principale problema a cui mi riferivo prima quando parlavo di flessibilita' quando hai da fargli fare qualcosa di particolare. Perdi piu' tempo col fiddling nelle classi e controlli etc che se creassi quelle funzionalita' from scratch a mano.

Per me produttività nel web è fondamentalmente il tempo impiegato a realizzare pagine con layout complessi anche con report e grafici.

Ci sono componenti di tutti i tipi per questo genere di cose. Dubito avresti mai da realizzare questo genere di funzionalita' a mano.

La separazione logica delle responsabilità non è certo paradigma esclusivo dell'MVC.
E' sempre stato realizzato nei progetti ben impostati che utilizzino MVC, o Forms, o PHP o cgi o quant'altro.

Beh, su questo siamo d'accordo :D

A maggior ragione quando su un progetto lavorano più team è essenziale avere strumenti che uniformino il più possibile lo sviluppo evitando che 10 team mi forniscano ognuno la propria revisitazione dello script per validare una data considerando l'internazionalizzazione.

Per curiosita'... visto che si parla di lavoro in team: quale SCM usate? SourceSafe o..? :D

ashram

31-12-2010, 14:52

Tempo fa volevo imparare qualcosa riguardante il web (partendo da zero o quasi,solo conoscenza rudimentale html)...dopo aver analizzato le diverse opzioni ho provato rails (2.3.5 all'epoca).

Ebbene in 2 settimane ho fatto una applicazione qui al lavoro su mysql che usiamo continuamente ancora oggi.Certo ci sono ampi margini di miglioramento ma la produttività è terrificante.E avevo conoscenze 0 di ruby.

Complice una pausa di un paio di mesi e l'uscita di rails 3 (che ha cambiato molte molte cose anche se si dice il contrario) sto dando una occhiata a Django (e l'interfaccia amministrativa è omfg ahah)...ma ogni volta che devo scrivere un import devo dire che rimpiango rails ahahah

Nel mio piccolo ho trovato questi difetti a Rails :

- scarsa facilità di deployment.Certo c'è capistrano,ma siamo lontani anni luce da php,asp.net e affini

- aggiornamenti troppo frequenti,nel giro di 3 mesi ho trovato cambiato MOLTISSIMO,troppo.

- mancanza di visual gui per la parte html...da nabbo mi darebbero spesso una mano :)

- sistema di gem praticamente inutilizzabile senza connessione.Ci sono talmente tante dipendenze incrociate che scaricarle non è una opzione...e in ambienti enterprise è un problema non da poco in fase di deployment e sviluppo

My 2 cents :)

Sisupoika

31-12-2010, 15:39

Nel mio piccolo ho trovato questi difetti a Rails :

- scarsa facilità di deployment.Certo c'è capistrano,ma siamo lontani anni luce da php,asp.net e affini

Ti prego, ti supplico: dimmi che e' uno scherzo o che non hai usato molto Capistrano e simili :D

Facilita' di deployment anche in parallelo su clusters di servers e' una delle cose piu' belle con Capistrano, e non ho mai trovato eguali per .NET, PHP o quant'altro, a meno di usare Capistrano anche per essi! :D

Hai anche provato una interfaccia web per Capistrano, tipo Webistrano (https://github.com/peritor/webistrano/wiki/)?

E comunque ci sono alternative tipo Vlad, Fabric? E il bello e' che si possono usare anche con PHP, Python etc!

Premesso questo, PLEASE menzionami almeno una soluzione di deployment migliore di queste, e per es. per .NET :D
E tutto cio', senza considerare le varie possibilita' di continuous integration, tipo Cruise, Integrity, Cerberus, ecc.

- aggiornamenti troppo frequenti,nel giro di 3 mesi ho trovato cambiato MOLTISSIMO,troppo.

E' un male o un bene? :D
Certo, a volte puo' voler dire accelerare un po' i tempi per tenersi al passo, questo e' vero. Ma al di la' di questo, c'e' tutto da guadagnare!
Per di piu' puoi anche avere applicazioni nello stesso sistema ma che usino diverse versioni di Ruby e Rails grazie a RVM e freezing delle gems.

- mancanza di visual gui per la parte html...da nabbo mi darebbero spesso una mano :)

Non ci avrei mai pensato, se non all'inizio, anni fa.
Forse e' perche' sei abituato ad altro tipo di tools?
E cmq, volendo, usando per esempio TextMate puoi anche avere preview ecc.
Poi ci sono una marea di gems e plugins per realizzare al volo complesse administration pages con tanto di temi eccetera, il che vuol dire puoi anche giusto customizzare queste e spendere meno tempo a disegnare l'interfaccia.

- sistema di gem praticamente inutilizzabile senza connessione.Ci sono talmente tante dipendenze incrociate che scaricarle non è una opzione...e in ambienti enterprise è un problema non da poco in fase di deployment e sviluppo

Per questo potresti anche clonarti l'intero repo di Ruby gems come faccio io :D
A che serve Git, se non -tanto per cominciare- come distributed SCM? ;)
Io lavoro anche offline in aereo, quando capita. Ho un bel po' di gems in un local mirror, tanta documentazione & APIs, etc.

tomminno

31-12-2010, 15:45

OK, hai provato .NET/MVC e non ti e' piaciuto. Perche' non provi The Real Deal (http://rubyonrails.org/)? :read:

E' nella lista dei miei todo da un bel pezzo. :cry:

LOL, se parliamo di Rails hai una immensa vastita' di gems e plugins con cui puoi fare MOLTO di piu, spesso con una sola riga di codice :Prrr:

Link please! :sbav:

Meglio qualche riga di codice per visualizzare una tabella che una pagina che pesa 1MB solo per il crap che .NET genera per far funzionare un web form :D

Mmmh il peso di .Net è certamente trascurabile rispetto alle immagini che oggi come oggi si è obbligati a mettere dentro ad un sito web per farlo apparire gradevole.

E, poi, rispondi: Cosa vedi nel codice di una pagina .NET? "L'ultima volta che ho controllato" avevi dei custom tags per il rendering dei controlli. Anche essi hanno poco a che vedere con l'HTML per il design. Sono spariti o sono ancora li'? :D

Facciamo un esempio: i custom tags e tutta la configurazione di, chesso', un DataGrid, un Repeater o quello che e'. Dove li metti?

Quella è la parte puramente ASP.Net non troverai mai una riga di C# in un file aspx.
DataGrid e Repeater? Roba da .Net 1.1 :D

Se per produttivita' intendiamo come gia' suggerito meglio da altri, la quantita' di risultati prodotti a parita' di qualita', secondo la mia esperienza in passato con sia web forms che .NET w/ MVC, ho trovato comunque MVC piu' produttivo perche', in molti casi, era piu' facile riutilizzare il codice, e il codice prodotto con MVC essendo piu' accessibile nei minimi dettagli, mi ha spesso risparmiato tempo qualora dovessi aggiornare o cambiare qualcosa, in confronto a riconfigurare web forms perche' facessero cio' di cui avevo bisogno. Sara' che la mia esperienza e' stata diversa, ma comunque ritengo che web forms possa andare bene in genere e possa anche essere piu' rapido, soltanto con applicazioni tutt'altro che complesse, altrimenti - e di questo ne sono convinto! - perdi piu' tempo a far fare ad un web form cio' che ti serve che a scrivere del codice in MVC!

Ho avuto esattamente un'esperienza opposta alla tua. Scomponendo la pagina in controlli si riesce a riutilizzarli dove servono anche in siti con layout completamente differente.

Ti faccio un invito: guardati questi (http://www.youtube.com/watch?v=Gzj723LkRJY) video e altre demo su Rails.
In particolare i video del 2005 in cui, come esempio, viene mostrato come creare un blog engine in 15 minuti.

Ti dirò a me non pare tutta questa meraviglia. Niente grafica, niente autenticazione, niente internazionalizzazione, è un banale CRUD su un database minimale.
Vedo che non ha scritto una riga di codice per la View, lo scaffold automatico dei dati gli ha però generato un layout a tabelle ;)

Se in quei 15 minuti ci avesse messo anche tutto il resto, magari con customizzazione delle operazioni visibili solo a determinati ruoli di utenti, sarebbe stato da sbavarci, chissà magari essendo un vecchio esempio ora si riesce a fare di meglio.

Sicuramente per essere un esempio del 2005 è notevole, .Net, allo scaffolding automatico, ci è arrivato molto più tardi con Asp.Net Dynamic Data, che però è adatto più che altro alle operazioni CRUD, diciamo che è limitato alle intranet.

ashram

31-12-2010, 15:49

Premesso che inizio a vederti un attimo troppo di parte,e lo dico da estimatore del framework e del linguaggio ti rispondo :

Ti prego, ti supplico: dimmi che e' uno scherzo o che non hai usato molto Capistrano e simili :D

Mai usato webistrano,tra le 10000 gemme di cui il 90% non vanno come dovrebbero o non hanno documentazione adeguata non lo avevo mai visto ;)
Poi si trattava di un deplyment di un mysql con 10 tabelle e 20 pagine di applicazione..roba che in php fai il deployment in 5 secondi via ftp in una cartella..con rails non confrontiamo dai :)
Tu parli di applicazioni livello mega-enterprise che svilupperà il 10% di chi utilizza rails secondo me

.
Poi ci sono una marea di gems e plugins per realizzare al volo complesse administration pages con tanto di temi eccetera, il che vuol dire puoi anche giusto customizzare queste e spendere meno tempo a disegnare l'interfaccia.

Ti sei scordato di dire il 99% ancora per rails 2.3.5 e il restante 1% non documentato :)

Per questo potresti anche clonarti l'intero repo di Ruby gems come faccio io :D
A che serve Git, se non -tanto per cominciare- come distributed SCM? ;)

A questo non ci avevo pensato,effettivamente hai ragione.Come fai giusto per sapere ?

tomminno

31-12-2010, 15:59

Hold on: intendi nella azienda in cui lavori, vero? Non in generale?

Ovviamente.

In che senso? Che intendi per sistema integrato?

Nel senso che il sito web è solo l'ultimo tassello di una catena di eventi ben più lunga.

Ecco che mi ricordi di altri vantaggi di Rails etc: mi dici come shardi un database con .NET se, ipoteticamente, fossi Facebook con 500+ milioni di users? :D

Beh prima di arrivare a quello c'è da dire: Dove me lo trovi un datacenter Windows che supporti più di 500 milioni di utenti?
Comunque .Net non ha il supporto nativo allo shred, ci sono delle librerie di terze parti da usare in tali casi.

tomminno

31-12-2010, 15:59

Per curiosita'... visto che si parla di lavoro in team: quale SCM usate? SourceSafe o..? :D

Svn :Prrr:

Ludo237

31-12-2010, 16:03

Piccola provocazione

parlate di produttività ... ma chi parla su un forum quanto produce???

sinceramente non bado al linguaggio (se non è specificato dal cliente/azienda oppure certe funzioni richiedono specifiche di particolari linguaggi) piu ne so meglio è ... e più si può guadagnare

Chiusa parentesi.

Sisupoika

31-12-2010, 16:12

Link please! :sbav:

Dai una occhiata a http://ruby-toolbox.com/
C'e' una bella selezione dei componenti piu' usati in varie aree.

Mmmh il peso di .Net è certamente trascurabile rispetto alle immagini che oggi come oggi si è obbligati a mettere dentro ad un sito web per farlo apparire gradevole.

Non direi trascurabile, perche' a parte la pagina dei anche considerare gli axd scripts che vengono automaticamente aggiunti, che sono pesanti.
Fra l'altro, almeno fino a qualche tempo fa c'era un bug nel .NET framework (non so se e' stato risolto) che comprometteva la cacheability di questi scripts da parte del client.

Quella è la parte puramente ASP.Net non troverai mai una riga di C# in un file aspx.

Sempre non standard HTML e'. Qual e' la differenza? :ciapet:

DataGrid e Repeater? Roba da .Net 1.1 :D

Actually, non mi venivano in mente i nomi dei nuovi controlli - come detto non uso .NET da tempo.

Ho avuto esattamente un'esperienza opposta alla tua. Scomponendo la pagina in controlli si riesce a riutilizzarli dove servono anche in siti con layout completamente differente.

Ma io non parlavo soltanto di controlli intesi come tali; interi templates, etc secondo me sono piu' "portabili" con MVC.

Ti dirò a me non pare tutta questa meraviglia. Niente grafica, niente autenticazione, niente internazionalizzazione, è un banale CRUD su un database minimale.
Vedo che non ha scritto una riga di codice per la View, lo scaffold automatico dei dati gli ha però generato un layout a tabelle ;)

Ma quello, come premesso, e' un esempio di 5 anni fa per dare una idea sul diverso processo. Tra il creare il database, le tabelle, configurare connessioni, creare equivalenti web forms che replichino le stesse funzionalita', quanto ti occorrebbe in .NET? :D

Se in quei 15 minuti ci avesse messo anche tutto il resto, magari con customizzazione delle operazioni visibili solo a determinati ruoli di utenti, sarebbe stato da sbavarci, chissà magari essendo un vecchio esempio ora si riesce a fare di meglio.

Authentication e authorization sono un gioco da ragazzi che gia' scrivendo codice richiedono al max 1-2 minuti con before_filter a livello di controller. Ma naturalmente sprecheresti meno time con gemme e plugin tipo authlogic, restful authentication e simili :D
Se poi vuoi aggiungere anche completa gestione di ruoli e permessi, con gems tipo CanCan aggiungici un altro minutino :D

Sicuramente per essere un esempio del 2005 è notevole,

Appunto. Dai una occhiata a qualche video su Rails 3. Magari su PeepCode oppure RailsCasts.

.Net, allo scaffolding automatico, ci è arrivato molto più tardi con Asp.Net Dynamic Data, che però è adatto più che altro alle operazioni CRUD, diciamo che è limitato alle intranet.

Ho usato Dynamic Data con uno degli ultimi progetti in .NET (che naturalmente ho portato in Rails), e richiedeva una marea di configurazione in confronto a Rails sui controlli, i tipi di dati associati alle views e quant' altro non ricordo piu'.

Sisupoika

31-12-2010, 16:23

Premesso che inizio a vederti un attimo troppo di parte,e lo dico da estimatore del framework e del linguaggio ti rispondo :

OK, lo ammetto e prometto di calmarmi un pochino :Prrr:

Mai usato webistrano,tra le 10000 gemme di cui il 90% non vanno come dovrebbero o non hanno documentazione adeguata non lo avevo mai visto ;)

Ma dai, non puoi dire questo, semplicemente e' una esagerazione fuori proporzioni ;)

Poi si trattava di un deplyment di un mysql con 10 tabelle e 20 pagine di applicazione..roba che in php fai il deployment in 5 secondi via ftp in una cartella..con rails non confrontiamo dai :)

Mi suggerisci come fare deployment in parallelo su 1000 servers, piu' database migrations, con FTP, allo stesso tempo? :D

Tu parli di applicazioni livello mega-enterprise che svilupperà il 10% di chi utilizza rails secondo me

Come adozione ovviamente non siamo ancora ai numeri di PHP o altro, ma perche' non consideriamo anche la tendenza della crescita in adozione? Nessuna altra tecnologia per lo sviluppo web ha un trend di crescita comparabile a Rails.

Ti sei scordato di dire il 99% ancora per rails 2.3.5 e il restante 1% non documentato :)

Vero, ma tu dimentichi ugualmente di dire che sebbene quel 99% (enormemente esagerato: basta dare una occhiata al principale repo, Github) sia stato scritto per 2.3.x, un buon 70-80% di esso funziona anche con Rails 3.

A questo non ci avevo pensato,effettivamente hai ragione.Come fai giusto per sapere ?

Es. "gem mirror" o https://github.com/rubygems/rubygems-mirror a seconda dei casi
Cmq al momento uso un semplice Ruby script per mantenere un minirepo delle gems che uso di piu' su uno dei miei servers personali.

Sisupoika

31-12-2010, 16:26

Beh prima di arrivare a quello c'è da dire: Dove me lo trovi un datacenter Windows che supporti più di 500 milioni di utenti?

Oh, vero :D

Svn :Prrr:

Ok, gia' va meglio considerate le solite abitudini attorno a .NET :D
Prossimo passo: git

Piccola provocazione

parlate di produttività ... ma chi parla su un forum quanto produce???

Dipende -personalmente- dal se sono in ferie oppure no :D

sinceramente non bado al linguaggio (se non è specificato dal cliente/azienda oppure certe funzioni richiedono specifiche di particolari linguaggi) piu ne so meglio è ... e più si può guadagnare
Chiusa parentesi.

Da una parte e' vera: meglio evitare over specialisation o come la chiamereste in Italiano. Pero' e' anche scegliere una tecnologia di riferimento che si puo' approfondire di piu'

ashram

31-12-2010, 16:44

Come adozione ovviamente non siamo ancora ai numeri di PHP o altro, ma perche' non consideriamo anche la tendenza della crescita in adozione? Nessuna altra tecnologia per lo sviluppo web ha un trend di crescita comparabile a Rails.

Sottoscrivo assolutamente con un piccolo distinguo : è adottata in massa per progetti medio-piccoli dove la velocità di produzione è incomparabile...molto di meno in grandi progetti (twitter e basta in realtà...contando che ha migrato parte del codice per velocizzarlo su scala a quanto ne so).

Vero, ma tu dimentichi ugualmente di dire che sebbene quel 99% (enormemente esagerato: basta dare una occhiata al principale repo, Github) sia stato scritto per 2.3.x, un buon 70-80% di esso funziona anche con Rails 3.

Vero,ma anche qui dimentichi un fatto importante.Lo sviluppatore medio vuole sviluppare e basta,non perdere tempo a cercare il perchè e il per come una gemma non funziona o documentazione inesistente in giro per il web.Per completare la mia (piccola) applicazione ammetto di aver passato più tempo su google che davanti al codice.

Volevo anche aggiungere un'altra caratteristica propria di rails e invece molto meno per altri framework come django : la sensazione di non sapere niente del perchè e del per come si fanno certe cose è terrificante,a volte spiazzante..perchè una determinata azione si fa così ? Perchè si,imparatela a memoria ahaha

Alla fine del mio progettino certo ho creato una bella applicazione intranet usabile,veloce e sicura ma posso dire di aver imparato ruby ? No

Posso dire che sarei in grado di applicare la stessa conoscenza ad altre applicazioni ? Non ne sono molto sicuro

Posso dire di aver compreso pienamente il codice ? Assolutamente no (soprattutto con l'uso di gem tipo authlogic & similia current_user da dove cavolo arriva ? ahah)
Certo puoi sempre andare a leggertelo ma così perdi tutto il tempo che hai risparmiato usando rails...e chi lo fa volendo la pappa pronta ? Nessuno :)

Certo il risultato c'è,ma...

Aggiungo che avendo anche usato un po' Django ho avuto la medesima sensazione pur in modo molto molto minore...codice python ce ne è molto,metodi da imparare a memoria altrettanti

Sisupoika

31-12-2010, 17:32

Sottoscrivo assolutamente con un piccolo distinguo : è adottata in massa per progetti medio-piccoli dove la velocità di produzione è incomparabile...molto di meno in grandi progetti (twitter e basta in realtà...contando che ha migrato parte del codice per velocizzarlo su scala a quanto ne so).

Se non sbaglio hanno migrato soltanto il message queueing.

Vero,ma anche qui dimentichi un fatto importante.Lo sviluppatore medio vuole sviluppare e basta,non perdere tempo a cercare il perchè e il per come una gemma non funziona o documentazione inesistente in giro per il web.Per completare la mia (piccola) applicazione ammetto di aver passato più tempo su google che davanti al codice.

OK, ma questi sono comunque passaggi dovuti, a prescindere dal framework usato. Se io dovessi cambiare framework domani, mi ritroverei in una situazione simile per i primi tempi

Volevo anche aggiungere un'altra caratteristica propria di rails e invece molto meno per altri framework come django : la sensazione di non sapere niente del perchè e del per come si fanno certe cose è terrificante,a volte spiazzante..perchè una determinata azione si fa così ? Perchè si,imparatela a memoria ahaha

Questo e' vero ma -ancora- soltanto agli inizi. E' una sorta di trade off per quella famosa produttivita', ma e' vero che all'inizio uno puo' avere tanti question marks a proposito del perche' o del percome qualcosa funziona in un determinato modo. Ma una volta che incominci a crearti le tue gemme, modificare altre, modificare parti di Rails stesso e a fare abbondante uso di meta programming, tutto diventa molto meno misterioso! (non a caso si usa spesso la parola "magic" quando ci si riferisce a Rails)

Alla fine del mio progettino certo ho creato una bella applicazione intranet usabile,veloce e sicura ma posso dire di aver imparato ruby ? No

Questo in realta' non mi sorprende. Uno degli aspetti di Rails e' appunto quello di poter creare applicazioni con un minimo di codice. Prendo in prestito una risposta che Microsoft employees danno spesso nei forums di Ms: "it's a feature, by design, not an issue" :D

Personalmente penso sia corretto, anche in termini di mercato, distinguere tra rubyists - ovvero sviluppatori, in primis, in Ruby e che di conseguenza conoscono molto meglio anche i frameworks associati, e "semplici" rails developers che si limitano al puro sviluppo di applicazioni web e che, pertanto, non conoscendo in profondita' Ruby secondo me possono soltanto far delivery di applicazioni ad un livello junior, in un certo senso.

Per quanto mi riguarda, appartengo naturalmente alla prima categoria, e pertanto devo ammettere di aver lavorato con sviluppatori Rails che non conoscessero a fatto i meccanismi dietro a Rails, con tutto cio' che comporta.

Quindi da questo punto di vista sono d'accordo con te. Essere in grado di creare applicazioni velocemente con poco codice ha i suoi vantaggi, ma i suoi svantaggi dal punto di vista del bagaglio di competenze e conoscenze che uno puo' avere.

(soprattutto con l'uso di gem tipo authlogic & similia current_user da dove cavolo arriva ? ahah)

Hai dato una occhiata a lib/authentication_system.rb? (occhio e croce eh, vado a memoria il che vuol dire che posso ricordare male adesso su due piedi, senza controllare codice)

Certo puoi sempre andare a leggertelo ma così perdi tutto il tempo che hai risparmiato usando rails...e chi lo fa volendo la pappa pronta ? Nessuno :)

Beh questo dipende dall'individuo! C'e' chi (come me) non si accontenta della pappa pronta e invece impiega tempo a studiarla, capirne il dietro le quinte, e magari spesso migliorarla, e c'e' chi invece lo fa soltanto per lavoro, mira ad ottenere la "instant gratification" e se ne frega un po' del resto ;)

Ma questo, credo, ancora una volta vale per tutti i linguaggi, frameworks, e tecnologie in generale.