Hosting Ruby on Rails Gratuito ed Italiano

Ciao Ragazzi,
ho a disposizione dello spazio in una web farm su di un server niente
male ed ho pensato di offrire hostig ruby on rails gratuitamente.

Secondo voi cosa dovrei offrire?

Pensavo prima di tutto di offrire un account ftp alla propria
applicazione fornendo l’accesso alle seguenti cartelle:

app config doc log Rakefile script tmp
components db lib public README test vendor

Ovviamente farei partire ogni applicazione su di una porta a mia scelta
( tipo: 3001, 3002 o altro ).

Ho già installato ruby, apache, mongrel e ruby on rails sul server.

Poichè programmo solitamente in java e sono un pò a digiuno di ruby on
rails ( ma con linux me la caso benino anche coem sistemista ) qualcuno
può guidarmi a riguardo?

Ovviamente assicurerei account gratuiti a tutti :wink:

Ciao!

Nessuno? :frowning:

Ciao!
Siamo tutti (chi più chi meno) in ferie… non disperare.
La community italiana di Ruby è una delle più attive, non disperare…
a settembre ti “bombarderanno” di richieste/supporto…

Buone vacanze, ciao!

— Magnus M. [email protected] ha scritto:

Nessuno? :frowning:

Posted via http://www.ruby-forum.com/.


Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml

  ___________________________________

L’email della prossima generazione? Puoi averla con la nuova Yahoo!
Mail: http://it.docs.yahoo.com/nowyoucan.html

On Wed, 8 Aug 2007 20:53:46 +0200, Magnus M. [email protected]
wrote:

Secondo voi cosa dovrei offrire?
Ciao,
ottima idea!
Cercando un po’ ho trovato questi:

http://www.ambitiouslemon.com/features.html
http://www.soyhost.com/

Potresti orientarti verso una cosa del genere.

Ovviamente assicurerei account gratuiti a tutti :wink:
PRIMO!! :smiley:

Ciao e beati i vacanzieri,
Ivan

Vorrei incominciare ad offrire:

  • spazio web ( da definire credo un 50 - 100 Mb )
  • 1 account mysql
  • indirizzo del tipo USERNAME.miodominio.it ( l’indirizzo in realtÃ
    maschera il fatto che la propria applicazione gira su una ben
    determinata porta - il mascheramento è eseguito mediante apache
    utilizzato come proxy )
  • 1 account ftp alla propria applicazione
  • mongrel come server dietro apache

Penso che per adesso basti per caricare la propria applicazione online o
sbaglio?

E’ indispensabile offrire la possibilità di stoppare / riavviare la
propria instanza di mongrel?

On Sat, 11 Aug 2007 01:02:59 +0200, Magnus M. [email protected]
wrote:

E’ indispensabile offrire la possibilità di stoppare / riavviare la
propria instanza di mongrel?

In quanto novizio non ne ho la certezza, ma forse
modificando i modelli il server andrebbe riavviato.
Puo’ darsi che sia una str***ata. Sono le 2 di notte.
Ivan

Ivan Morgillo wrote:

On Sat, 11 Aug 2007 01:02:59 +0200, Magnus M. [email protected]
wrote:

E’ indispensabile offrire la possibilità di stoppare / riavviare la
propria instanza di mongrel?

In quanto novizio non ne ho la certezza, ma forse
modificando i modelli il server andrebbe riavviato.
Puo’ darsi che sia una str***ata. Sono le 2 di notte.
Ivan

Non ho nessun problema a dare la possibilità di riavviare il proprio
mongrel. Però vorrei fornire questa opzione solo se è strettamente
necessario :wink:

Ho notato che è necessario riavviare il server anche quando viene
cambiato il file database.yml

Quindi questa funzione la devo dare.

Il giorno Sat, 11 Aug 2007 12:04:55 +0200
Magnus M. [email protected] ha scritto:

Ho notato che è necessario riavviare il server anche quando viene
cambiato il file database.yml

Quindi questa funzione la devo dare.

è un idea mia o per il deploy di rails bisogna fare un casino immenso???
mettere n server più uno di frontend, dare la possibilità di riavviare
il server se cambio un file; cioè non si è mai visto che bisogna
riavviare un server perchè ho cambiato un file di un applicazione
che ci gira sopra.

Rails è un ottimo framework, ma dovrebbero semplificare di molto il
deploy.

Secondo voi??

Pero’ ora mi hai fatto venire la curiosita’… come dovrebbe
funzionare
il “tuo” sistema di deploy ideale ?

A questa domanda rispondo anche io, e credo che il buon Michele
Franzin possa concordare con me :slight_smile:
Per quanto riguarda il mio sistema di deploy ideale, esiste già:
capistrano.

Capistrano è mal documentato, pecca enorme, ma a parte quello ha
tutto ciò che si possa chiedere ad un sistema di deploy. Granulare,
flessibile, estendibile, manca solo che faccia il
caffé.
Il mio consiglio è quello di perdere il tempo necessario ad
approfondire capistrano, non ve ne pentirete.

On 8/22/07, Giovanni I. [email protected] wrote:

Pero’ ora mi hai fatto venire la curiosita’… come dovrebbe
funzionare
il “tuo” sistema di deploy ideale ?

A questa domanda rispondo anche io, e credo che il buon Michele
Franzin possa concordare con me :slight_smile:
Per quanto riguarda il mio sistema di deploy ideale, esiste già:
capistrano.

sottoscrivo pienamente!
:wink:

Capistrano è mal documentato, pecca enorme, ma a parte quello ha

qualche piccolo passo avanti lo hanno fatto qui [1], ma non ti
fare troppe illusioni, mentre la documentazione uffciale [2] è più
estesa ma largamente obsoleta (ancora buona per farsi un’idea
generale)

Michele.

[1] http://www.capify.org/
[2] http://manuals.rubyonrails.com/read/book/17


SeeSaw | Intuitive web stuff


[email protected]

Il giorno mar, 21/08/2007 alle 15.01 +0200, [L]ash ha scritto:

il server se cambio un file; cioè non si è mai visto che bisogna
riavviare un server perchè ho cambiato un file di un applicazione
che ci gira sopra.

Magari non si fosse mai visto…sarebbe un mondo bellissimo, ma ti
assicuro che il 99% dei framework/application server/blah blah
funzionano cosi’ a partire da tomcat per arrivare a zope (ed entrambi
hanno un frontend web per forzare il riavvio)

Rails è un ottimo framework, ma dovrebbero semplificare di molto il
deploy.

Secondo voi??

Secondo me e’ una parte che va gestita con un’ applicazione esterna (ad
esempio via web) perche’ rails gia’ ti fornisce dei canali per
effettuare la rilettura delle modifiche di configurazione (anche se sei
sotto mongrel) che vanno solo utilizzati.
Non c’e’ motivo di appesantire la struttura.

Pero’ ora mi hai fatto venire la curiosita’… come dovrebbe funzionare
il “tuo” sistema di deploy ideale ?

Il giorno Wed, 22 Aug 2007 09:19:43 +0200
Roberto De Ioris [email protected] ha scritto:

Pero’ ora mi hai fatto venire la curiosita’… come dovrebbe
funzionare il “tuo” sistema di deploy ideale ?

non avere un server web separato per applicazione + 1;
un qualcosa di più facile come php, python, perl sarebbe l’ideale :slight_smile:

probabilmente uno che cerca più sicurezza e vuole separare tutto e
allora gli va bene avere n server che girano con utenti diversi; mi
piacerebbe che ci fosse la possibilità di scegliere tra le due opzioni,
anche perchè la mia macchinina n server non li tiene :slight_smile:

Ciao

On 8/22/07, [L]ash [email protected] wrote:

non avere un server web separato per applicazione + 1;
un qualcosa di più facile come php, python, perl sarebbe l’ideale :slight_smile:

probabilmente uno che cerca più sicurezza e vuole separare tutto e
allora gli va bene avere n server che girano con utenti diversi; mi
piacerebbe che ci fosse la possibilità di scegliere tra le due opzioni,
anche perchè la mia macchinina n server non li tiene :slight_smile:

potresti spiegarmi meglio ?

Michele


SeeSaw | Intuitive web stuff


[email protected]

Il giorno mer, 22/08/2007 alle 12.42 +0200, [L]ash ha scritto:

Il giorno Wed, 22 Aug 2007 09:19:43 +0200
Roberto De Ioris [email protected] ha scritto:

Pero’ ora mi hai fatto venire la curiosita’… come dovrebbe
funzionare il “tuo” sistema di deploy ideale ?

non avere un server web separato per applicazione + 1;

fastcgi, scgi e se vuoi farti del male (e hai tanto tempo libero) cgi

un qualcosa di più facile come php, python, perl sarebbe l’ideale :slight_smile:

la logica di funzionamento e’ diversa, (qualcuno ti dira’ che stai
paragonando un linguaggio a un framework ma ho capito cosa vuoi dire),
la parte piu’ evidente e’ che l’applicazione rails deve rimanere
residente pronta a ricevere richieste, l’alternativa e’ avere un sistema
lento (lentissimo…).
Probabilmente le perplessita’ che hai derivano tutte da questo aspetto.

probabilmente uno che cerca più sicurezza e vuole separare tutto e
allora gli va bene avere n server che girano con utenti diversi; mi
piacerebbe che ci fosse la possibilità di scegliere tra le due opzioni,
anche perchè la mia macchinina n server non li tiene :slight_smile:

usa semplicemente webrick e hai risolto.

Il giorno 21/ago/07, alle ore 15:01, [L]ash ha scritto:

mettere n server più uno di frontend, dare la possibilità di riavviare
il server se cambio un file; cioè non si è mai visto che bisogna
riavviare un server perchè ho cambiato un file di un applicazione
che ci gira sopra.

Rails è un ottimo framework, ma dovrebbero semplificare di molto il
deploy.

Secondo voi??

Rails non richiede un riavvio se “cambi un file”.
Richiede un riavvio quando

  1. Modifichi roba che viene caricata dall’initializer - ovvero
    plugin, librerie sotto lib/, configurazioni in config/

  2. Sei in production mode, quindi cachi il cachabile. Un grosso hint
    ti arriva da RAILS_ROOT/config/environments/production.rb dove trovi

    config.cache_classes = true

Quasi tutti i framework richiedono un riavvio. Rails no, nel momento
in cui sviluppi in development mode e vai in produzione in production
mode.
Mai visto applicazioni di un certo rilievo non andare in produzione
con un server che proxa le richieste a n server di backend - certo,
per il blog puoi anche usare fastcgi, ma il blog non è una
applicazione di un certo rilievo :slight_smile:

HTH,
ngw


Nicholas W.
[email protected]

Il giorno 22/ago/07, alle ore 12:42, [L]ash ha scritto:

non avere un server web separato per applicazione + 1;
un qualcosa di più facile come php, python, perl sarebbe l’ideale :slight_smile:

probabilmente uno che cerca più sicurezza e vuole separare tutto e
allora gli va bene avere n server che girano con utenti diversi; mi
piacerebbe che ci fosse la possibilità di scegliere tra le due
opzioni,
anche perchè la mia macchinina n server non li tiene :slight_smile:

Lighty + fastcgi.
Chi ti ha detto che non è possibile ? :slight_smile:

ngw

Nicholas W.
[email protected]

Il giorno 11/ago/07, alle ore 02:10, Magnus M. ha scritto:

Non ho nessun problema a dare la possibilità di riavviare il proprio
mongrel. Però vorrei fornire questa opzione solo se è strettamente
necessario :wink:

Dipende.
Se l’applicazione gira in dev mode no, se è in production (e credimi,
tu non vuoi tutte le applicazioni in dev mode sulla tua macchina) si.
Anche la roba sotto lib/ richiede un restart di mongrel.

ngw


Nicholas W.
[email protected]

Il giorno mer, 22/08/2007 alle 18.22 +0200, [L]ash ha scritto:

Il giorno Wed, 22 Aug 2007 13:05:09 +0200
Roberto De Ioris [email protected] ha scritto:

fastcgi, scgi e se vuoi farti del male (e hai tanto tempo libero) cgi

come performance come siamo messi con cgi?

a mio modesto parere e’ praticamente inaccettabile su qualsiasi hardware
e configurazione, e te lo dice uno che userebbe cgi per ogni cosa

sopracitato framework, ma secondo me il meccanismo di funzionamento non
dovrebbe cambiare più di tanto. Invece mi trovo a dover avviare un
demone dedicato interamente ad una applicazione.

il problema e’ che stai paragonando un contesto in cui hai php embedded
in apache (con mod_php presumo).
Puoi usare rails in maniera molto simile con mod_ruby ma come gia’
emerso piu’ volte in questa lista ci sono dei problemi di stabilita’ (o
presunti tali) abbastanza fastidiosi (senza contare la base di utilizzo
infima rapportata a mod_php)

la parte piu’ evidente e’ che l’applicazione rails deve rimanere
residente pronta a ricevere richieste, l’alternativa e’ avere un
sistema lento (lentissimo…).
Probabilmente le perplessita’ che hai derivano tutte da questo
aspetto.

quindi rails è talmente lento che deve rimanere caricato in memoria per
avere dei tempi di risposta accettabili? e quanto di questa lentezza
dipende da rails e quanta da ruby stesso?

Detto cosi’ e’ abbastanza brutto, ma essendo pragmatici e’ un analisi
abbastanza veritiera.
Io ho una pessima opinione delle performance di ruby (sono un perlista,
quindi sono abituato a scrivere male e in fretta, ma con la certezza di
avere un overhead dell’interprete praticamente nullo), ma e’ un fattore
che viene totalmente eclissato dalla velocita’ di sviluppo e l’eleganza
del codice.

usa semplicemente webrick e hai risolto.

non posso ne voglio usare webrick come IL server web della mia
macchina, credo non tenga il confronto con apache :wink:

Eh ma cosi’ vuoi la botte piena e la moglie ubriaca :slight_smile: comunque per il
background che hai ti consiglio di dare un occhio a mod_ruby

Il giorno Wed, 22 Aug 2007 13:05:09 +0200
Roberto De Ioris [email protected] ha scritto:

fastcgi, scgi e se vuoi farti del male (e hai tanto tempo libero) cgi

come performance come siamo messi con cgi?

un qualcosa di più facile come php, python, perl sarebbe l’ideale :slight_smile:

la logica di funzionamento e’ diversa, (qualcuno ti dira’ che stai
paragonando un linguaggio a un framework ma ho capito cosa vuoi dire),

ok è un framework, ma un framework è sempre implementato con un
linguaggio :slight_smile: per usare ad esempio lo ZendFramework (il primo che mi
viene in mente, non lapidatemi) devo solo metterlo sotto una directory e
fare l’include dei file e usarlo. Rails ha e fa molto di più del
sopracitato framework, ma secondo me il meccanismo di funzionamento non
dovrebbe cambiare più di tanto. Invece mi trovo a dover avviare un
demone dedicato interamente ad una applicazione.

la parte piu’ evidente e’ che l’applicazione rails deve rimanere
residente pronta a ricevere richieste, l’alternativa e’ avere un
sistema lento (lentissimo…).
Probabilmente le perplessita’ che hai derivano tutte da questo
aspetto.

quindi rails è talmente lento che deve rimanere caricato in memoria per
avere dei tempi di risposta accettabili? e quanto di questa lentezza
dipende da rails e quanta da ruby stesso?

usa semplicemente webrick e hai risolto.

non posso ne voglio usare webrick come IL server web della mia
macchina, credo non tenga il confronto con apache :wink:

Ciao

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs