[OFF-TOPIC] Metodo de aprendizaje rails

Hola a todos. Veréis llevo por la lista un año y medio, pero no es hasta
hace un par de semanas que no me he puesto en serio a intentar aprender.
Y
aquí está mi pregunta. Veréis, os cuento un poco mi caso particular.
Yo no soy programador (Licenciado en Bellas Artes), pero desde hace un
par
de años estoy enganchado al desarrollo web y la programación (OOP) y más
en
concreto a RAILS.

El caso es que, ahora que quiero aprender, me planto delante de mi
oredenador y pienso “¿Por donde empiezo?”. La idea que yo llevaba era:
Primero aprendo Ruby y luego Rails
¿Cómo?
1- Primero leo unos cuantos tutoriales básicos de Ruby (string, module,
class,inheritance,…conceptos…y más conceptos) HECHO
2- Leo un libro currado. Me compré: “Curso de Ruby” de Lucas Carlson
(CASI
LEIDA la parte básia, hasta el capitulo 15, a partir de hay es demasiado
para mi). Un tocho muy completo.
3-Luego aprendo un poco de Rails, lo mismo que con ruby pero de cosas
concretas sobre ActiveRecord, ActiveResource, REST,…LOS CONCEPTOS LOS
TENGO [más o menos :-)]
4- Me meto con un tocho de RAILS. En mi caso me compre el de Obi “The
Rails
Way”.NO LO HE TOCADO

¿No parece mal plan, no?
Pues estoy rallado. El otro día en un hilo de esta lista, [2], Raúl me
recomendo que congelase RAILS en una App de prueba y que trastease con
su
código, así aprendería mucho de Ruby. NO LO HE HECHO TODAVIA
Veréis en ese mismo hilo me aconsejaba que me instalase el ruby-debug y
que
empezase a trastear. Me mando a google para que me informase de que es
el
ruby-debug y cómo se usa:
INCISO:

No he visto ningún tutorial que profundice mucho en el uso de
Ruby-debug.
¿me podéis recomendar alguno?

El caso es que en esa busqueda que me recomendo [3]. Una de las primeras
opciones que salían era un RailsCast de Ryan B… Bueno,…para
aprender
lo básico (instalarlo y dos comandos).
En este tutorial el usa una App en la que hay un modelo Task (tareas)
que
hace un find_near_due. Un metodo en el modelo Task que le falla y
debugea…Bueno, no sé cómo yo me imagine que este modelo TASK iba
anidado
con un modelo PROJECT y
me empeñe en completar mi aplicación con dos modelos anidados
(PROJECT>TASK). Pero nunca me había puesto a hacer algo REST (leer si,
hacer
NO) entoonces googlee y llegue a un post de Jaime I. [4] sobre
REST-recursos-anidados
He cogido su codigo y lo he adaptado a mi App así que ahora tengo una
triple
anidamiento (PROJECT>TASK>COMMNENTS).

La parte positiva de esta historia es que me ha resultado bastante fácil
comprender el funcionamiento básico del anidamiento con REST. Mi App
funciona perfectamente.

Lo que pasa ahora es que las dudas me corroen.
1- ¿debo seguir por el camino de la lectura y la meditación :-)?
2- o debo de enfrentarme a un proyecto real que yo me busque y llevarlo
a
cabo
(desarrollo-test-debug-deployment[capistrano,Git]-producción[encontrar
hosting-elegir servidor de App])?

Lo de montar esta App ha sido una experiencia positiva, pero no sé si
intentar lanzar una App a producción es demasiado, teniendo en cuenta
que no
me enfrentado nunca a los TEST ni al control de versiones, ni a poner en
produción una App

Buff,…¿Qué harías vosotros si estuvieráis empezando y quisieráis
aprender?

En mi caso la curva de aprendizaje la veo muy empinada :slight_smile:

No os quejéis, es una pregunta para el debate, ideal para una tarde de
domingo…

Un saludo a todos

[1]

[2] ¿Rails es multi-hilo o no? - ES - Ruby-Forum
[3] LMGTFY - Let Me Google That For You
[4]
http://www.jaimeiniesta.com/2007/12/22/tutorial-recursos-anidados-con-rest-y-rails-2/

El día 25 de enero de 2009 13:34, Andrés gutiérrez
[email protected]
escribió:> Lo que pasa ahora es que las dudas me corroen.

1- ¿debo seguir por el camino de la lectura y la meditación :-)?
2- o debo de enfrentarme a un proyecto real que yo me busque y llevarlo a
cabo (desarrollo-test-debug-deployment[capistrano,Git]-producción[encontrar
hosting-elegir servidor de App])?

2… pero una aplicación sencilla… super sencilla… 2 modelos a lo
sumo, sin pretensiones o las turbulencias te hundirán.

f.

2… pero una aplicación sencilla… super sencilla… 2 modelos a lo
sumo, sin pretensiones o las turbulencias te hundirán.

Gracias,…si te soy sincero, es lo que quería oir. De hecho, lo que voy
a
hacer es llevar a producción la App que os he comentado (3 modelos),
sin.css
ni florituras, ni nada, solo un background de color y el contenido
centrado. Ahora lo que me toca es buscar un hosting baratito-bueno (creo
que
jaime Iniesta había hecho un ranking en su blog), hacerme una cuenta
free en
GitHub, instalarme Git, instalar capistrano y aprender a usarlos.

Tengo jaleo ¿no? :slight_smile:

Por cierto, el tema del debug y de los TEST es independiente de que la
ponga
en producción, asi que si alguien me puede recomendar algún tutorial
sobre
debug con ruby-debug,…
Tema TEST, creo que me lo voy a mirar en el libro de Obie

Un saludo y gracias Fernando.

El 25 de enero de 2009 13:43, Fernando G.
[email protected]escribió:

Ah, para completar el hilo. El otro día vi este blog [1] en el que hace
una
clasifocación bastante buena de libros ruby-rails por niveles
(principiante-medio-avanzado)

[1]

El 25 de enero de 2009 14:03, Andrés gutiérrez
[email protected]escribió:

El día 25 de enero de 2009 14:07, Andrés gutiérrez
[email protected]
escribió:> Ah, para completar el hilo. El otro día vi este blog [1] en el que hace una

clasifocación bastante buena de libros ruby-rails por niveles
(principiante-medio-avanzado)

[1]
Mr. Neighborly: A Ruby and Rails bibliography of sorts

buen link… al delicious que va :slight_smile:

El día 25 de enero de 2009 14:03, Andrés gutiérrez
[email protected]
escribió:>

Por cierto, el tema del debug y de los TEST es independiente de que la ponga
en producción, asi que si alguien me puede recomendar algún tutorial sobre
debug con ruby-debug,…
Tema TEST, creo que me lo voy a mirar en el libro de Obie

Lo del debug es mucho menos importante que lo de los tests…

En muy pocas ocasiones he necesitado debuggear una aplicacion, un par
de puts aquí y allá casi siempre es suficiente,… y cuando lo he
necesitado no me ha hecho falta un conocimiento muy profundo de esta
técnica… por lo que no me preocuparía por este punto…

Lo que sí tienes que mirarte bien es el tema de los tests… da un poco
de pereza al principio… pero si le coges el tranqui al final es
adictivo y sumamente útil, tranquilizador y ahorrativo.

f.

En muy pocas ocasiones he necesitado debuggear una aplicacion, un par
de puts aquí y allá casi siempre es suficiente,… y cuando lo he
necesitado no me ha hecho falta un conocimiento muy profundo de esta
técnica… por lo que no me preocuparía por este punto…

Entiendo tu punto de vista, de verdad. Pero aprecio mucho los consejos
que
se me dan aquí. El otro día Raul me recomendo debuggear un poco por un
Rails
Freeze para aprender cositas
y es algo que tengo pendiente. Se que rompe un poco el plan que me he
marcado, pero es un break que creo me aportara cosas (le voy a dedicar
un
par de tardes)…o igual meterme en el código de Rails me viene grande,
no
lo sé.
En cualquier caso si alguien le ha dado al tema del debugger…¿me
podría
mostra algún link donde expliquen algunos casos prácticos?

En lo de los test estoy totalmente de acuerdo contigo.

Sobre el hosting… yo me miraría uno que te dieran una ubuntu pelada y
te dieran acceso root para instalar todo a pelo… así lo que prenderás
a poner una aplicación Rails en producción y no a manejarte (pelearte)
con el panel de control de un servicio de hosting determinado.

Muy buena idea, voy a ver que dice Jaime [1], y si no hay ninguno que
sea lo
que tu dices, vengo y os pregunto :slight_smile:

Gracias

[1] http://www.jaimeiniesta.com/tag/servidores/

El 25 de enero de 2009 14:12, Fernando G.
[email protected]escribió:

El día 25 de enero de 2009 14:03, Andrés gutiérrez
[email protected]
escribió:> Ahora lo que me toca es buscar un hosting baratito-bueno

Sobre el hosting… yo me miraría uno que te dieran una ubuntu pelada y
te dieran acceso root para instalar todo a pelo… así lo que
prenderása poner una aplicación Rails en producción y no a manejarte (pelearte)
con el panel de control de un servicio de hosting determinado.

f.

Sigue los consejos de Raúl y Jaime antes que los míos… donde hay
patrón no manda marinero :slight_smile:

… y yo el que barre la cubierta :slight_smile:

El 25 de enero de 2009 14:30, Fernando G.
[email protected]escribió:

El día 25 de enero de 2009 14:21, Andrés gutiérrez
[email protected]
escribió:
Sigue los consejos de Raúl y Jaime antes que los míos… donde hay
patrón no manda marinero :slight_smile:

f.

Qué tal Andrés? :slight_smile:

El día 25 de enero de 2009 13:34, Andrés gutiérrez
[email protected]
escribió:> concretas sobre ActiveRecord, ActiveResource, REST,…LOS CONCEPTOS LOS

TENGO [más o menos :-)]
4- Me meto con un tocho de RAILS. En mi caso me compre el de Obi “The Rails
Way”.NO LO HE TOCADO

¿No parece mal plan, no?

Tu plan me parece perfecto :slight_smile: Sólo le añadiría lo que te comentaba el
otro día: aderezar lo que estés aprendiendo con alguna experiencia
práctica, algún pet project al que puedas aplicar lo que
estésaprendiendo en cada momento.

Pues estoy rallado. El otro día en un hilo de esta lista, [2], Raúl me
recomendo que congelase RAILS en una App de prueba y que trastease con su
código, así aprendería mucho de Ruby. NO LO HE HECHO TODAVIA

Antes de seguir, aclarar que te no conocía tu roadmap y por tanto mi
sugerencia no se enmarca en ningún “plan de estudios” :slight_smile: En ese hilo
denotabas mucho interés en cuestiones relacionadas con el
funcionamiento interno de Rails e intenté ayudarte a seguir por
ahí,si eso es lo que quieres ahora :wink:

INCISO:

No he visto ningún tutorial que profundice mucho en el uso de Ruby-debug.
¿me podéis recomendar alguno?

El caso es que en esa busqueda que me recomendo [3]. Una de las primeras
opciones que salían era un RailsCast de Ryan B… Bueno,…para aprender
lo básico (instalarlo y dos comandos).

En realidad no es necesario aprender cada detalle de ruby-debug:
sólosaber cómo parar la ejecución de un programa ruby en el punto que te
interese e inspeccionar el estado de los datos para saber qué está
ocurriendo ahí dentro. Como decía Fernando, hay otras técnicas para
depurar programas, como por ejemplo escribir logs. Todo esto está muy
bien explicado en esta guía:
Debugging Rails Applications — Ruby on Rails Guides

Otro tutorial más específico sobre ruby-debug:
Debug Your Rails App With ruby-debug — SitePoint

Buff,…¿Qué harías vosotros si estuvieráis empezando y quisieráis
aprender?

En mi caso la curva de aprendizaje la veo muy empinada :slight_smile:

Para mí una curva de aprendizaje es empinada cuando es muy difícil dar
el siguiente paso, y creo que en tu caso no es así, creo lo que ocurre
es que tienes varios puntos donde poder continuar, que son los que
comentas:

  • seguir profundizando en ruby (testing, debugging…)
  • seguir profundizando en rails (más REST, testing específico, debugging…)
  • aprender algún sistema de control de versiones
  • aprender a poner en producción una aplicación rails

¿Qué estrategia seguir? Yo te recomendaría algo como esto (ya te digo
que todo es muy opinable):

  1. Aprender el uso básico de un sistema de control de versiones.
    Fíjate que digo “lo básico” porque algunos como git me parecen un
    mundo en sí mismos, tienen una cantidad de funcionalidades tremenda.
    Me conformaría con llegar a un punto en el que sepas crear un
    repositorio y seguir un flujo de trabajo habitual: descargar la última
    versión, trabajar en local, subir los cambios y resolver conflictos.

  2. Crear un pequeño proyecto en rails. Aquí el consejo que te da
    Fernando me parece excelente: algo sencillo, lo más sencillo que
    puedas. Como dicen por ahí, “el diablo está en los detalles” y si te
    preocupas demasiado de la funcionalidad terminarás saliendo del camino
    que te has marcado (lo cual no está mal si puedes volver atrás). Ya le
    añadirás funcionalidades y complejidad después, de momento me
    conformaría con tener algo muy básico con 2-3 controladores y 2-3
    modelos con alguna relación de por medio, sin ajax ni javascript de
    por medio. Por supuesto, te recomiendo gestionar siempre los cambios
    de tu proyecto con el sistema de control de versiones aprendido en el
    paso anterior.

  3. Coincido de nuevo con Fernando, me parece importante aprender a
    testear. Coge uno de tus modelos y aprende a hacer tests unitarios. No
    intentes testearlo todo, sólo aquellas funciones que has programado
    tú. Como le oí alguna vez a Sergio Gil, cuando estás aprendiendo a
    testear y falla algún test seguramente el test está mal y tu código
    está bien. Cuando sea tu código el que falle puedes hacer uso de
    ruby-debug, de logs o de simples puts para saber por qué tu modelo no
    funciona. Te recomiendo usar solamente Test::Unit y lo que trae rails
    de serie, tendrás tiempo de usar mocks, rspec, shoulda o cucumber
    másadelante.

  4. Cuando hayas testeado tus modelos, intenta aprender a hacer tests
    funcionales. Hay gente que no los usa demasiado, pero a mí me parece
    muy interesante testear como mínimo que la respuesta es la
    redireccióno la vista sin errores de ejecución que esperabas. Aunque se puede, no
    te recomiendo testear el contenido de las vistas en este momento. En
    cuanto a las librerías, mi consejo es el mismo.

  5. Llegado a este punto, aprendería a poner en producción tu
    aplicación. Siguiendo el mismo principio que hasta ahora, intenta
    abarcar lo mínimo imprescindible (para mí sería hacer el setup inicial
    de tu servidor y conseguir automatizar el deploy de tu
    aplicacióndesde el repositorio del control de versiones).

Cuando hayas dado estos 5 pasos habrás avanzado en todos los terrenos,
tendrás bastante controlada la base de cada uno y una aplicación en la
que experimentar sin miedo a romper nada porque estará versionada y
tendrás automatizada su puesta en producción. A partir de
aquí podrásmejorar tu aplicación de forma iterativa y aprovechar para
experimentar: añadir y testear nuevas funcionalidades, probar
algúnframework de testing, automatizar la monitorización de la
aplicación,ejecutar tareas en background, mashups, integración con cosas tan
interesantes como XMPP…

Si en algún momento no estás motivado para trabajar sobre tu
aplicación puedes aprovechar para estudiar algún proyecto ajeno que te
interese e incluso intentar contribuir de alguna forma, ya sea en
forma de código, de documentación o contestando alguna pregunta en las
listas de correo. Yo mismo debería dedicarle más tiempo a esta tarea:
generalmente soy el único desarrollador en mis proyectos y tengo
pendiente en mi to-do el dedicar más tiempo a leer código ajeno y a
trabajar con más gente para aprender de ellos.

Como te decía antes, la curva no es empinada, simplemente hay muchos
caminos a elegir: una de las virtudes de la comunidad ruby es que es
muy activa y cada poco tiempo surgen alternativas a explorar. Si
quieres dedicarte a trabajar con ruby o con rails te
recomendaríaseguir un enfoque sistemático parecido al que te comentaba
anteriormente, sobre todo porque te ayudará a mantenerte centrado en
tu objetivo. Si no es el caso, te diría que simplemente disfrutes
aprendiendo lo que más te llame la atención en cada momento.

Todo esto, en mi opinión :wink:

Ahora si. primero de todo tomar nota de los dos enlaces de deug que me
has
pasado. Decir también que dejare para más adelante lo de trastear con el
código de Rails.
Voy a ser prácticoy me voy a ceñir al plan que has marcado. Como tu
dices
puede estar mejor o peor y ser opinable, pero a mi me vale y lo voy a
intentar seguir.

1-Instalarme Git en local
2-Buscar un buen tuto de Git. Algo ya tengo por ahí [1][2][3], aunque si
conocéis algo que sea bueno,…
3- Hacerme una cuenta en GitHub. y subir la App
4-Una vez me sienta seguro, y no tenga problema en machacar mi código,
empezaré a aprender a testear. Buff,…esto me da mucha pereza, pero ya
que
empiezo de 0, lo voy a hacer bien.
intentare pillar los conceptos básicos para cuando amplie los modelos de
mi
App pueda crear los Test segun los voy programando. Eso es lo que
recomienda
Jaime [4]
5- Buscar hosting:
Condiciones:
a- Disponga de ssh. Para aprender a manejarme por consola.
b- Que me lo den pelado, para que tenga que aprender a moverme en
entorno LINUX. consejo de FERNANDO,aunque me da respeto la idea.
c- No se si esto es una chorrada, porque un scv como git trabaja
desde
local ¿no? pero es que he mirado un poco slicehost y sólo hablan de
subversion. Entoces un requisito más es que el hosting sea compatible
con
Git

[1]
http://www.buildingwebapps.com/podcasts/6894-version-control-with-git/show_notes
[2] Git User Manual
[3] http://github.com/guides/home
[4] http://www.jaimeiniesta.com/tag/desarrollo-guiado-por-tests/

El 25 de enero de 2009 20:00, Andrés gutiérrez
[email protected]escribió:

Vale, voy a dedicar un mensaje sólo a agradecerte el tiempo invertido:

GRACIAS, de verdad muchas gracias.

El 25 de enero de 2009 19:02, Raul M. [email protected]
escribió:

Perdón, se me ha disparado el dedo y he enviado el mensaje. Con esto ya
termino:

Si quieres dedicarte a trabajar con ruby o con rails te recomendaría
seguir un enfoque sistemático parecido al que te comentaba
anteriormente, sobre todo porque te ayudará a mantenerte centrado en
tu objetivo. Si no es el caso,…

Si, este es mi caso. Aprender por aprender está bien, pero me queda mal
sabor de boca si lo que aprendo no se ve reflejado en un resultado
final,
algo práctico, aunque sea una App chorra.

Bueno Raul, lo dicho, muy agradecido por tu genial explicación. Muy
agradececido

Un saludo y que acabéis bien el domingo

El 25 de enero de 2009 20:21, Andrés gutiérrez
[email protected]escribió:

La parte de testing siempre da pereza, pero también es algo que va en
gustos: algunos de los mejores profesionales que conozco no escriben
tests y no les va nada mal. Personalmente es una de esas prácticas que
me gustaría haber adquirido antes, veo que me aporta muchas cosas y
recomiendo probarlo al menos en un proyecto antes de decidir si seguir
usándolo o no.

En cuanto al hosting, si vas a alojar el código en github (me parece
una idea excelente) no te preocupes porque si tienes permisos de
administración te será trivial instalar git y no
necesitarásconfigurar nada especial para servir el código.

Bueno Raul, lo dicho, muy agradecido por tu genial explicación. Muy
agradececido

Jeje, yo sólo he hecho una propuesta: el trabajo duro te toca a tí :wink:

Un saludo y que acabéis bien el domingo

Igualmente Andrés! :smiley:

Gracias Raul por re-responder. Yo prometo que este es mi último mail por
hoy. Sólo comentar que he estado mirando dos hostings, GUEBS y SLIDEHOST
y
creo que
me quedo con GUEBS.
1-Por que el inglés no es mi fuerte y esta gente esta en Madrid.
2-Porque desde mi ignorancia, creo que ofrecen más o menos lo mismo.
Aunque
Passenger me parece que Slidehost no lo ofrece. Y es una opción rápida
para
poner en producción una App
3- Porque el plan más barato es el de guebs(100Mb de
espacio-1Gb-transferencia-60€/año) aunque el plan sencillo de slidehost
es
más potente (10Gb de espacio-100Gb de transferencia-240€/año). Para
hacer pruebas y aprender lo básico, me sobra con guebs ¿no?

En cuanto a lo de Git, creo que lo que me confundia era el hecho de que
por
ejemplo GUEBS ofrece(CREO) en sus planes espacio para un repositorio de
Subversión. En lugar de tenerlo en GitHub.
Me motiva más GitHub por eso de que lo usa la gente de rails.

Bueno, lo dicho muy agradecido y espero contar mis avances o por lo
menos
mis frustaciones (querrá decir que lo estoy intentando)

Un saludo

El 25 de enero de 2009 20:51, Raul M. [email protected]
escribió:

Suerte y a disfrutar!

Gracias Jaime lo intentaré. Me corta un poco el rollo que en guebs no me
den
el server en bolas, voy a aprender menos si me lo ponen fácil :slight_smile:
Aunque por otro lado voy a ser humilde y ver si soy capaz de ponerlo en
producción ahí. ya habra tiempo para pasarme a slidehost y darme de
cabezazos :slight_smile:

Nota:
No quiero entretener más a la gente con mis planes de futuro, así que
por mi
se puede cerrar el hilo

En serio, muchas gracias a todos los que me habéis orientado

Un saludo

El 26 de enero de 2009 10:53, Jaime I.
[email protected]escribió:

2009/1/25 Andrés gutiérrez [email protected]:

Gracias Raul por re-responder. Yo prometo que este es mi último mail por
hoy. Sólo comentar que he estado mirando dos hostings, GUEBS y SLIDEHOST y
creo que
me quedo con GUEBS.

Si estás empezando, y/o para proyectos con poco tráfico, buena
elección un hosting compartido en Guebs mejor que un servidor dedicado
en Slicehost.

1-Por que el inglés no es mi fuerte y esta gente esta en Madrid.

Puntualización: están en Bizkaia :slight_smile:

2-Porque desde mi ignorancia, creo que ofrecen más o menos lo mismo. Aunque
Passenger me parece que Slidehost no lo ofrece. Y es una opción rápida para
poner en producción una App

Bueno, es que básicamente en Guebs.com te ofrecen un entorno rails
determinado ya montado con passenger. Slicehost no te ofrece
ningúnentorno: ta dan un servidor dedicado en bolas y tú te montas allí lo
que quieras: mongrel, passenger, apache, nginx… Por lo que si
quieres aprender sobre las diferentes maneras de poner apps en
producción, esta es mejor opción ya que puedes hacer lo que te venga
en gana y den de sí tus conocimientos de administración de sistemas.

3- Porque el plan más barato es el de guebs(100Mb de
espacio-1Gb-transferencia-60€/año) aunque el plan sencillo de slidehost es
más potente (10Gb de espacio-100Gb de transferencia-240€/año). Para
hacer pruebas y aprender lo básico, me sobra con guebs ¿no?

Pues
sí.

En cuanto a lo de Git, creo que lo que me confundia era el hecho de que por
ejemplo GUEBS ofrece(CREO) en sus planes espacio para un repositorio de
Subversión. En lugar de tenerlo en GitHub.
Me motiva más GitHub por eso de que lo usa la gente de rails.

Pues no uses el subversion que te dan en Guebs, y emplea Github.

Bueno, lo dicho muy agradecido y espero contar mis avances o por lo menos
mis frustaciones (querrá decir que lo estoy intentando)

Suerte y a disfrutar!


Jaime I.
http://jaimeiniesta.com
http://www.workingwithrails.com/person/6722-jaime-iniesta

2009/1/26 Andrés gutiérrez [email protected]:

Suerte y a disfrutar!

Gracias Jaime lo intentaré. Me corta un poco el rollo que en guebs no me den
el server en bolas, voy a aprender menos si me lo ponen fácil :slight_smile:

Bueno, es que de eso se trata, guebs.com es alojamiento compartido.

Aunque por otro lado voy a ser humilde y ver si soy capaz de ponerlo en
producción ahí. ya habra tiempo para pasarme a slidehost y darme de
cabezazos :slight_smile:

Slicehost, con “C” :slight_smile:

En mi caso, por si te sirve de referencia, primero aprendí a
desarrollar rails en local, y me hice una
pequeña aplicación. Despuésprobé a ponerla en producción, y para ello usé un alojamiento
compartido en Dreamhost. Después cuando quise aprender más sobre
servidores y apps en producción, me pillé un dedicadito en Slicehost.

Con el tiempo he pasado por muchos hostings [1], y mi conclusión es
que lo mejor es dejar ese tema en manos de administradores de
sistemas, y yo preocuparme sólo del código de la aplicación, no de la
administración del servidor. Esto, desde un alojamiento compartido
pequeñito en guebs.com como en un despliegue con varios slices
balanceados en EngineYard.

[1]
http://www.jaimeiniesta.com/2008/10/02/comparativa-de-hosting-ruby-on-rails/


Jaime I.
http://jaimeiniesta.com
http://www.workingwithrails.com/person/6722-jaime-iniesta

Esta bien conocer el punto de vista de alguien que trabaja con Rails de
forma profesional (como creo que son todos los que han escrito en el
hilo),
pero Javier:

El desarrollador tiene una idea (más o menos aproximada) de cómo está
montado todo, pero no lo monta él.
Yo no tengo esa idea, asi que lo primero que tengo que hacer es tener
idea
de como funcionan las cosas. Para que te hagas una idea, nunca he usado
ssh.
No me cansaré de repetir que estoy muy VERDE.

Y, bueno, aquí va una de perogrullo… para poder pasar a producción, hay
que tener algo que tener que poner en producción.

Ya tengo algo que poner en producción, una App con tres modelos anidados
(project>task>comment). como ya me han dicho aquí, es mejor algo
sencillo
asi no me desvio de mi proposito inicial que es aprender a usar Git y
poner
esta chorrada de App en un server para poder verla (no tiene ni .css ni
.js)
Es la sencillez a su máxima expresión.

Y ya ni te cuento si además la quieres poner en producción bien y si
tienes que dar alto rendimiento.
Este no es ni de lejos mi problema, por favor tomate este hilo desde el
punto de vista docente. No creas que sin saber programar pretendo
comerme el
mundo y montar mi super-chachi App para poder triunfar. NO, sólo quiero
aprender y si es posible con un guión más o menos definido (ahora
aprendo
esto, luego aquello,…)
Porque la web es un mar de información y si sumamos a esto varios libros
de
800pgs, ya no te cuento.

En resumen, y desde mi punto de vista, prefiero tener una App colgada y
luego mejorarla pero a la vez saber actualizarla y versinarla con un
SCV-Git.

Jaime:

En mi caso, por si te sirve de referencia, primero aprendí a desarrollar
rails en local, y me hice una pequeña aplicación.
Esa es mi idea, una App muy muy muy pequeña como ya he contado.

mi conclusión es que lo mejor es dejar ese tema en manos de
administradores de
sistemas, y yo preocuparme sólo del código de la aplicación, no de la
administración del servidor
Esta también es mi idea. Yo no quiero en principio aprender a administra
mi
server. Me ceñiré a lo que me den los de Guebs. Pero si quiero aprender
a
gestionar mi código con Git y poder ver mi App en remoto (llamame tonto,
pero me hace ilusión)

Para Javier y Jaime:
Yo creo que he tomado buena nota de vuestros consejos y creo que lo del
sisteme de control de versiones es algo básico para alguien que quiere
aprender a
programar una App web. Los test también están en mi agenda…

El 26 de enero de 2009 11:55, javier ramirez
[email protected]escribió: