Visualizzazione dei risultati da 1 a 7 su 7
  1. #1
    Utente di HTML.it
    Registrato dal
    Feb 2005
    Messaggi
    209

    Argomenti per confutare il rails-scettico

    Ritengo che HTML.it sia il principale centro d'incontro tra web-operatori italiani in assoluto e che l'angolo destinato alle discussioni su ruby sia così deserto mi lascia pensare che investire tempo per imparare ad usare il rails sia tempo "sprecato".
    Nel mondo reale questo framework se è adorato per la sua agilità è anche pesantemente snobbato per le sue performance e i benchmark che ho visto finora concordano. PHP sembra essere generalmente più lento nei cicli rispetto a Ruby, ma a progetto finito PHP/Apache riesce a gestire un maggior numero di connessioni e di richieste senza archittetture esotiche come cluster di mongrel e reverse proxy balancer.
    L'architettura in questione è attualmente la soluzione per avere buone performance con RoR, ma le web agency hanno dei rapporti abbastanza consolidati con le aziende di hosting che conservano i loro siti e quest'ultime ci pensano bene a creare una nuova infrastruttura se poi non riescono a venderla a nessuno, quindi la sconsigliano fino a quando la domanda diventerà consistente.
    Credo che sia un vero peccato perché sarebbe possibile creare applicazioni web più solide e scalabili con meno codice se alle spalle c'è un framework potente come rails, ma purtroppo è, al momento, troppo lento ed è questo l'importante.

  2. #2
    In realtà, a confronto, Rails è il più veloce rispetto a qualsiasi framework PHP.

    In realtà, paragonare due framework è complesso, ci sono troppe variabili in gioco.
    Più facile è paragonare con un benchmark PHP e Ruby dove quest'ultimo è nettamente superiore per la maggior parte delle elaborazioni.

    Non dimentichiamoci che non si può paragonare Rails a PHP, sono due cose diverse.
    O paragoni due linguaggi o due framework.

    A proposito di Apache, puoi usare apache anche per Rails.
    mod_rails + Apache è ad oggi la combinazione più efficace per Rails, più ancora di Mongrel o Thin.

  3. #3
    ci sarebbero da scrivere molte cose, ma sintetizzo: la velocità non è tutto

    vero che questa sezione è desolata http://forum.html.it/forum/showthrea...readid=1239016

    ho giocato un po' sia con RoR che con framework PHP e nessuno mi soddisfava appieno... ora mi sto facendo per puro sfizio personale ( verrà mai usato in produzione? boh ) un framework PHP



    sul fronte scalabilità Ruby/RoR e PHP/frameworks sono più o meno allo stesso livello...
    è messo un po' meglio Python, ma neanche tanto
    ma se voglio scalabilità totale mi butto su Erlang e relativi framework, Mnesia/CouchDB... essì perchè è fondamentale scalare il db

  4. #4
    HTML.it è senza dubbio una voce molto importante tra i "web-operatori italiani"; proprio questo forse limita l'attività ad esempio di questo forum.

    Gartner, Inc. prevede un futuro in crescita per Ruby on Rails, e che l'ecosistema di Ruby e Ruby on Rails toccherà i 4 milioni di sviluppatori al mondo entro il 2013. Dice però anche:

    [..] Ruby will enjoy a higher concentration among corporate IT developers than typical, dynamic ‘scripting’ languages, such as PHP.

    Questa è la situazione che vedo già oggi, che vivo in prima persona e che osservo nelle persone che utilizzano Ruby / Rails in Italia e all'estero. E' solo il mio occhio, sicuramente non rappresenta tutto il mondo Rails; il fatto è che delle persone che conosco nessuno utilizza questo forum, non sono "web-operatori".

    Certo la diffusione di Rails non è paragonabile alla diffusione di un Java che impari all'università; ma non credo che siamo alla calma piatta.

    Spostiamoci ora sul tecnico.

    Rails nelle sue prime versioni (precedente all'1.0) era veramente lento. Veramente lento. Di passi avanti da allora se ne sono fatti (il riconoscimento del routing e per il modulo di connessione db sono decisamente più rapidi). Oggi non mi sento di dire che Rails sia lento.

    La velocità, come già detto da altri più illustri di me qualche riga più in alto, non è affatto sinonimo di scalabilità; le scelte architetturali di Rails lo rendono scalabile. I problemi di scalabilità di un progetto dipendono da cattivo codice o scelte sbagliate nel design dell'applicazione più che da limiti del framework o della tecnologia utilizzati.

    Relativamente all'hosting, in Italia abbiamo in effetti poche opzioni per l'hosting di applicazioni Rails. Non dimentichiamoci però del perché vogliamo utilizzare Rails; Rails ci rende più produttivi e maggiormente competitivi; siamo disposti ad accettare che un fornitore limiti le nostre potenzialità?

    Nel mondo reale:

    * esistono in Italia più sviluppatori Ruby / Rails che gli utenti che hanno scritto un post in questo forum
    * Rails continua a renderti più produttivo di altri framework
    * se impari Ruby / Rails ti avvicini a tecniche e tecnologie che tornano utili alla tua programmazione indipendentemente dalla tecnologia che utilizzi in pratica
    * tutto è migliorabile, ma Rails non espone dei limiti grossolani nella realizzazione di applicazioni web o siti internet
    * per il deploy di applicazioni Rails, è possibile utilizzare Apache con un modulo proprio come capita per PHP
    * per un'azienda soffocare il proprio vantaggio competitivo per un limite imposto da un fornitore mi pare assurdo, meglio cambiare fornitore

    Chiaramente, IMHO
    Qualche volta programmo in Ruby on Rails.

  5. #5
    Ottime considerazioni ynw, grazie!
    Vorrei sottolineare due punti.

    Il primo per quanto riguarda il provider.
    Rails , così come Ruby, è pensato per offrire allo sviluppatore una serie di comandi principalmente eseguibili da CLI.
    Utilizzare un hosting per eseguire Rails è limitante, anche nel caso degli hosting più flessibili.

    Il problema principale con il quale mi sono scontrato in merito all'uso di Hosting è la dipendenza delle GEM.
    Non è raro che capiti l'esigenza di GEM specifiche ed installarle su un piano di hosting è spesso impossibile. In alcuni casi è possibile ricreare un repository GEM nella propria homedir, ma inevitabilmente questo complica il tutto.

    Ho usato Rails su (shared) hosting, VPS e Server dedicati.
    Indubbiamente la seconda e la terza soluzione sono le più efficaci. Allo stesso tempo, i costi di queste due soluzioni sono notevolmente calati rispetto ad anni fa.

    In merito alla scalabilità appoggio l'intervento. Rails è uno dei framework più scalabili che abbia utilizzato. Non dimentichiamo che è stato uno degli obiettivi sempre alla base dello sviluppo.
    Ne è un esempio Capistrano, un software per il deploy multiserver di Rails.

    Se poi si entra nel merito delle caratteristiche, un esempio è il sistema di caching che offre la possibilità di usare sistemi distribuiti come MemCache e Database.

  6. #6
    @weppos: per la gestione delle gemme e della loro installazione in remoto vengono molto utili i task rake -T | grep gem:. Con questi è possibile iniettare le gemme che servono al progetto Ralis direttamente in vendor/gems così da portarsele dietro insieme al progetto.

    L'unica scomodità riguarda le gemme con estensioni da compilare; in questo caso le gemme devono essere preparate su un sistema simile a quello di produzione (il server di CI mi pare sia il posto migliore).

    http://dev.rubyonrails.org/changeset/9140
    http://github.com/rails/rails/tree/m...alizer.rb#L269
    Qualche volta programmo in Ruby on Rails.

  7. #7
    Originariamente inviato da weppos
    In merito alla scalabilità appoggio l'intervento. Rails è uno dei framework più scalabili che abbia utilizzato
    http://homepages.inf.ed.ac.uk/wadler...hitectures.pdf
    http://hypernumbers.com/Hypernumbers...te%20Paper.pdf

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.