Rails no es fácil

Community ES
21

On Wed, 2008-03-12 at 08:59 -0300, Ricardo M. wrote:

2008/3/12 Jaime I. [email protected]:

¿Qué opinais sobre esto? Lo digo sobre todo porque en esta lista cada vez
tenemos que explicar cosas más básicas a gente que da la impresión de que

Como yo lo veo es un problema generalizado en toda la rama IT (al
menos acá en Argentina me pasa tooodo el tiempo). Este “problema” se
ve muchas listas de tecnologías “nuevas”, basta solo suscribirse a
cualquier lista de GNU/Linux para encontrarse con preguntas como “como
configuro apache?” o cosas similares :).

simple, es mas facil preguntar que buscar el camino para abrirse paso.

Los programadores tienen cada vez menos ganas de leer, menos ganas de
buscar, menos ganas de investigar y menos ganas de aprender. Muchas
veces pienso que la profesión de programador se asemeja más y más a la
de un carpintero, cortamos aca, pegamos allá, y tenemos la mesa para
el cliente :).

la culpa no es del chancho

bastaria solo con enviar a leer a cada persona que haga una pregunta que
facilmente se pueda resolver con un faq, ej RTM! (version amigable de
RTFM)

salu

–
Gabriel

22

El 12/03/08, Jaime I. [email protected]
escribió:> Hola Andrés, aunque pienso que haya que googlear antes que preguntar, lo que

quería decir no era esto, sino que… Rails no es fácil.

Retomando el hilo:

Completamente de acuerdo: Rails no es fácil.

Llevo 5 años desarrollando aplicaciones web basadas en Java… y me
estoy volviendo loco con la nomenclatura Ruby & Rails.

:smiley:

Saludos
f.

23

Hola gente,

El día 12/03/08, Jaime I. [email protected] escribió:

Hola Andrés, aunque pienso que haya que googlear antes que preguntar, lo
que quería decir no era esto, sino que… Rails no es fácil.

Yo creo que el problema es que rails està basado en ruby, y ruby es muy
suyo. Viniendo del C/C++ puedes saltar a Java i/o Php sin casi dolor.
Pero
con ruby es diferente, el ser dinámico despista si vienes de un lenguaje
como Java…

24

En mi opinión se juntan dos cosas diferentes: por un lado la actitud de
cada
cual y por otra el rails es fácil.

Mi experiencia viene de Java, por lo que POO, MVC y más está controlada,
o
hasta tal punto que no necesito que me guíen, sé caminar sólo aunque
preguntas siempre salen. El propósito de rails, para mi es interesante,
por
lo que contestáis varios. Resuelve detalles que con otros lenguajes
empieza
a ser demasiado engorroso y tedioso. La metodología, la sintasis, etc es
normal que cambie al cambiar el lenguaje, además uno está acostumbrado a
otro y el cambio cuesta. Pero se llega.

La actitud, es que en muchos foros, listas, etc la gente pregunta pero
no ah
googleado lo suficiente, incluso a algunos les pasas un manual y pasan
de
leerselo, no sé si sera el extremo de la lista, pero cuando esto sucede,
la
verdad es que la gente que tiene poco tiempo acaba cansada porque no
puede
seguir el hilo de tanto ruido.

La conjugación de ambas entiendo que da lugar a que quizás Jaime abogue
por
que miremos más en la red antes de preguntar, que nos informemos más
antes
de decir “yo es que de mvc no tengo ni idea” o “yo de POO ná de ná”
porque
eso hace que la gente demuestre pocas ganas de contestar.

Por otro lado una cosa que yo hago desde hace tiempo es escuchar. Tengo
proglemas sí, y quizás tarde en resolverlos, pero prefiero leer la lista
un
tiempo antes de preguntar por cosas que parecen triviales para la
mayoría,
prefiero ir leyendo los problemas de otros porque así resuelvo los mios
en
parte y en otra parte evito futuros problemas propios.

Y si bien es cierto que si se quiere controlar a un nivel más o menos
alto
una tecnología es normal que sea un libro, incluso que se lean artículos
de
tecnología adyacentes como puede ser el caso de mvc y otros. Eso también
le
da un poco de más interes a la lista. También es cierto que cuando se
pregunta hay que saber preguntar, y algunas veces no somos capaces de
formular la pregunta demasiado bien.

Un saludo,

25

2008/3/12 Andrés gutiérrez [email protected]:

aunque mi duda sea algo genérico de la POO y no sea específico de RoR, lo
saber.

Espero que nada de lo que dicho le sepa mal a nadie. Cada dia abro mi correo
y leo entusiasmado todos los mensajes de la lista, mi deseo es que un dia
pueda ayudar como otros me ayudan.

Un saludo a todo el mundo

Andrés, creo que no se está debatiendo la posibilidad de que se puedan
hacer preguntas “novatas” (tú dijiste “estúpidas” pero no me gusta el
término =;-) ) sino cuál es la mejor manera de responderlas.
Entendiendo “lo mejor” como “lo mejor para el que
preguntó”.Básicamente saber cuál es la mejor forma de que el preguntador llegue
a saber hacer lo que no sabe hacer (y por eso preguntó). Y ponernos de
acuerdo en qué cosas necesita saber antes de plantearse con garantías
la pregunta. ¿No?

–
Sergio Gil Pérez de la Manga
e-mail > [email protected]
blog > http://www.lacoctelera.com/porras

26

2008/3/12 Jaime I. [email protected]:

suficiente…

Bueno, en mi opinión parte de su poder reside en esto que comentas, y
eso lo
intuyes cuando te las has tenido que ver con XML, properties, etc que no
hacían sino emborronar la idea y que a veces hace que pierdas la
referencia
de donde estás. Pero esto lo ves “claro” cuando pasas por ello y sufres,
entiendo que si han hecho cuatro cosas, no saben ver esa idea.

Y sí, es mejor dejar la discusión en ese momento.

27

En la experiencia que yo tengo de explicar Rails a gente que ha hecho
alguna
cosilla por su cuenta con PHP o ASP, en plan lenguaje de script
imperativo y
sin usar orientación a objetos (lo que llamo “cuatro bucles, un par de
ifs y
dos o tres funciones”) es el tema de adaptarse a las convenciones de un
framework determinado.

En lugar de ver la potencia que les da esto de la convención sobre la
configuración, lo ven como una limitación: “¿pero quién se cree el rails
este para decirme dónde tengo que poner yo las cosas?”… Momento en el
que
es mejor cortar y dejarle que siga con sus cuatro bucles si con eso
tiene
suficiente…

28

Creo que el problema es que estas enfocando el “reclamo” en el punto
equivocado.

No es que Rails sea facil o dificil. Lo que es dificil es el
desarrollo de aplicaciones web. Son creaciones complejas que
interactuan con sistemas muy diversos, con muchas piezas que se mueven
y sobre las cuales no siempre tenemos control. No importa la
herramienta que uses, siempre sera un problema dificil de resolver.

Y para empeorar la situacion, cuando hablamos de ese problema, “las
aplicaciones web”, no siempre nos referimos a lo mismo. Usamos el
mismo termino para referirnos a una pagina que recoge direcciones de
email de los usuarios que quieren recibir mas informacion, o para
hablar de una aplicacion como Twitter. Y comparamos, implicita o
explicitamente, consciente o inconscientemente, lo facil que resulta
hacer esa simple pagina en PHP con el trabajo que te lleva hacer
Twitter en Rails.

Rails es dificil porque el problema es dificil, y si no entiendes el
problema no entiendes Rails. Y si el problema es mas complejo de lo
que estas acostumbrado, te va a parecer mas dificil, sin importar que
tan buena sea la herramienta.

Si le das una maquina de coser a un sastre lo haras mucho mas
productivo, pero si te dan una maquina de coser a ti te vas a quedar
mirando al techo sin saber que hacer con ella. Y escribiras a la lista
de “sastres-es” sobre lo dificil que es entender como funciona la
maquina esta.

No hay muchos atajos a la hora de acumular experiencia y
conocimientos, que son los que te ayudan a entender mejor el problema
y aprovechar mejor las herramientas. Simplemente tienes que hacerlo
una y otra vez y otra vez hasta que poco a poco te va resultando mas y
mas facil, y mas y mas natural y un dia te das cuenta que puedes usar
cualquier herramienta de desarrollo web y ser bastante productivo, y
que hay algunas que te hacen mas productivo en ciertos problemas y
otras que son mejores en otros casos.

29

Humm, tal vez la afirmación sea un poco desatinada… “Rails no es
fácil”, la verdad si no fuera fácil no me habría enamorado a primera
vista. Más bien, lo que no es fácil es encontrar documentación.

En mi caso personal, empecé a aprender rails hace poco menos de un año
recuerdo que el primer tutorial que leí fue el de rolling with ruby on
rails. Y aún no teniendo ni idea de cómo funcionaban las cosas, la
simplicidad con que se ponía en marcha el recetario fue lo que me
atrajo. Después de ahí comencé a buscar información por la red, y dí con
esta lista tan maravillosa. Sin embargo no puedo llegar y preguntar
“cómo funciona rails?” (aunque creo que mi primer pregunta si fue algo
“novata” jeje…) y lo que hice fue ponerme “auto proyectos” empezando
por cosas sencillas, una vez que aprendía cómo funcionaba lo que había
hecho seguía con algo un poco más difícil y así… Cabe mencionar que
estos proyectos eran vagos sin ningún propósito.

Al día de hoy no puedo decir que sepa todo de rails, pero al menos tengo
las nociones básicas para formular una pregunta. Mi problema principal
no era la POO (aunque con ruby he terminado aprendiendo aún muchísimo
más!), sino el concepto de MVC ya que jamás había utilizado un framework
para desarrollo web.

Pienso que lo que nos hace pensar que “Rails no es fácil” es que no
conocemos muchos de los métodos que incluye (y la falta de documentación
incluso en el sitio oficial!) y tratamos de solucionar problemas “a la
antigüita”, por eso ahora cuando algo se me complica en rails pregunto:
“Hay una manera de hacer esto facilmente?”… porque rails es eso, cosas
simples sin complicarse, sigue el concepto KISS (keep it simple,
stupid!)

Algo que me ha ayudado mucho para conocer más aún sobre estos métodos
“escondidos” de rails son los libros de pragmatic programmers y
peedcode, no es ninguna publicidad más bien es recomendación.

¿Y que por qué aprendo rails? Empecé por gusto, no tenía nada que hacer
y me puse a leer… luego entré a trabajar pero no usando rails, y aún
sigo aprendiendo rails como pasatiempo. De rails he aprendido, además de
la programación, que el internet ofrece muchas posibilidades y
beneficios y esto mismo hace que me piense el ser freelancer o incluso
iniciar mi propia consultoria de rails aquí en méxico. Vamos, que pase
de ser hobby a ser algo útil en mi vida.

Mi conclusión concuerda con la de algunos: uno debería leer al menos
para saber cómo hacer una pregunta antes de enviarla aquí. No importa si
la pregunta es “novata”, pero debería formularse bien.

Sobre todo hay que recordar que los programadores Ruby son programadores
felices. :wink:

30

Bueno creo que este ha sido un hilo bien largo y quiero aportar algo de
mi
experiencia con Rails y de mi participacion en algunas listas en
general,
ire por partes:

  1. Lo primero que aprendi al participar en listas, es a respetar el
    tiempo
    de los demas, es decir, antes de enviar una consultar primero sacarle
    toda
    la pulpa a los buscadores, luego darme una siesta de media hora y tratar
    de
    seguir buscando alguna solucion al problema, una vez que he agotado
    todos
    mis recursos recien acudo a la lista.

  2. Otra cosa muy importante que aprendi, es a nunca quedarme con la
    duda,
    como decian en un mensaje anterior, si tienes algo que te funciona muy
    bien
    pero no sabes como lo hace, estas en un grave problema, investiga, agota
    tus
    recursos, y si aun no te queda claro, acude a la lista: “No hay pregunta
    tonta, si no tontos que no preguntan”.

  3. Si hay algo que tengo que agradecer a Rails, es el 99% de mi
    formacion
    como desarrollador, con Rails aprendi las buenas practicas de desarrollo
    de
    software en general y con Ruby he llegado hasta tener que investigar
    sobre
    Smalltalk para comprender bien toda la base de la OO.

  4. Hay personas que se trauman o desmotivan cuando le conversamos sobre
    TDD/BDD, creo que estas 2 metodologias de desarrollo solo las van saber
    apreciar aquellos que llevamos algunas canas con el desarrollo, pero hay
    una
    cosa que todo desarrollador la deberia saber(aunque lo hace siempre,
    pero no
    se da cuenta): “Los requerimientos en una aplicacion siempre cambian,
    recuerdalo bien SIEMPRE, o bien cambian o bien surgen nuevos
    requerimientos”, creo que cuando un desarrollador comprende esto va a
    apreciar TDD o BDD.

  5. “Rails es facil”, esto piensan todos los que han leido parte del
    Agile
    Web… y ademas han hecho un ./script/generate scaffold …, creo que
    deben
    saber que una aplicacion web no solo esta compuesta de eso, tenemos
    muchas
    otras cosas como: Arquitectura de la informacion, Usabilidad,
    Accesibilidad
    entre otras cosas mas, que si bien no debemos saberlo al 100%, al menos
    debemos tener bien en claro de que va la idea.

  6. “Por mi culpa, por mi culpa, por mi gran culpa”: Antes de conocer
    Rails,
    desarrollaba en PHP puro, lo unico que esperaba era terminar con el
    bendito
    proyecto y no verle la cara al cliente mas, yo pensaba de esa manera por
    una
    sencilla razón: si el cliente se contactaba conmigo solo era por 2
    cosas, o
    bien para cambiar algun requemiento que me hizo, o bien para agregar uno
    nuevo, entonces que sucedia, me ponia a pensar en ese mismo instanste,
    si
    modifico el codigo aqui esto otro tambien voy a tener que modificar y
    esto
    otro va a explotar, eso me paso por una sencilla razón: no conocia
    ningun
    estandar de desarrollo, osea mi código era espagueti. Un tiempo despues
    conoci diversos conceptos: Cohesión, Acoplamiento, TDD/BDD, Patrones de
    Diseño, entre otras muchas cosas, y dije: carambas!, pero si esto no me
    lo
    enseñaron ni enseñaran en ningun instituto/universidad, esto es genial y
    la
    gente no sabe, bueno para concluir creo que todavia estas a punto de
    cambiar
    ;).

Bueno es el mail mas extenso que he escrito hasta ahora, y he relatado
mi
experiencia como desarrollador hasta ahora, espero que matemos esa
excusa
de: “No tengo tiempo para leer”, y seamos buenos profesionales.

Saludos.

31

Aquí va mi experiencia en el poco camino que llevo en Ruby/Rails.

Comencé hace aproximadamente medio año. Al principio me resulto algo
extraña la sintaxis, lo cual me llamó la atención aún más. Llevo varios
años desarrollando en PHP, aunque también he visto (sin profundizar)
algo de Python, C y Java.

A pesar del poco tiempo que llevo, ya me resulta pesado realizar algunas
tareas en PHP después de comprobar lo sencillo y ameno que se hacen con
Rails. No se ustedes, pero a mi me divierte muchísimo más programar en
Rails (y también en Ruby, que lo he tomado para los scripts de la vida
cotidiana) que en PHP.

Con respecto a la programación en general… metodología de la
programación. Una vez lo entiendes bien, un lenguaje de programación es
sintaxis, propiedades (del lenguaje), estructura del mismo, etc…
algunos con más/menos dificultades que otros, pero un “objeto” es un
“objeto” y un “if” es un “if”, por muchas vueltas que se le de. Después
están las buenas prácticas/maneras en lo referente a programación (o no
jejeje).

¿Rails es difícil? Cero que no, podría decirse que la sintaxis es
distinta, que usa MVC… y poco más. Esto pueden ser dificultades para
una persona que se busca excusas para no leer una buena referencia en
Rails (véase “The Rails Way” o “Agile…”). En cambio, si alguien tiene
un poco de interés e investiga lo suficiente descubrirá la potencia de
Rails y entonces ya si que no podrá abandonarlo jeje.

Conclusión (desde mi punto de vista): programar en Ruby/Rails es
divertido y te proporciona buenos hábitos en lo que a programación se
refiere. Si no te diviertes con lo que haces, difícilmente llegarás a
ser bueno.

Nota: que conste que yo también he realizado alguna pregunta de esas que
no gustan mucho.

Jaime I. escribió:

32

Hola , en mi opinion Rails es muy fácil, y a estas alturas
documentacion
hay y mucha, gente lanzando libros , miles de blogs , editores
especializados, hostings compatibles, screencasts comunidades muy
activas
,etc… hay googlear un rato nomas :smiley:

a mi parecer el problema de Rails es que es muy facil! :D, es decir, es
rápido implementar sistemas simples con lo que trae el core o instalar
plugins y hacerlos funcionar. Hasta aqui yo creo que Rails es FACIL. el
problema a mi parecer es que esto nos hace comprender el framework, o
bien,
RUBY de manera muy superficial y es facil quedarse pegado en la magia de
ROR, por eso es posible que personas hagan preguntas triviales , porque
aunque ya han hecho su blog en 15 minutos, conocen poco muy de RUBY, y
la
gracia de Rails es que no hay que ser un gurú en RUBY para usarlo,
tampoco
un gurú de OOP, esta claro que los gurus de RUBY le sacarán mucho mas
partido al framework :smiley:

creo que con Rails se da algo muy particular en cuanto a la curva de
aprendizaje, en mi caso aprendí primero el framework y luego RUBY
(creo),por
lo menos yo no conosco a nadie que halla empezado programando en CAKEPHP
antes de meterse en PHP

bueno eso …

Saludos a la lista, muy interesante el hilo

2008/3/12 Edgar J. Suarez [email protected]:

33

Hola gente,
retomando el tema para recomendar un poco de lectura[1] que creo que
viene
al dedo con el tema.
Tened paciencia y leedlo hasta el final.

[1] The Law of Leaky Abstractions – Joel on Software

El día 13/03/08, Valentín Palacios [email protected]
escribió:

34

2008/3/17 Dani D. [email protected]:

Hola gente,
retomando el tema para recomendar un poco de lectura[1] que creo que viene
al dedo con el tema.
Tened paciencia y leedlo hasta el final.

[1] The Law of Leaky Abstractions – Joel on Software

Perdón por seguir el off-topic, pero me pareció interesante.

Me parece un artículo poco fiel a la realidad. Compara TCP con IP,
cuando la comparación correcta es con UDP. Mientras IP es una
abstacción a nivel de red (internet layer en el modelo reducido OSI)
que podemos ver con protocolos como ping, TCP es una abtacción de esta
(que eso si lo dice el artículo) a nivel de transporte. En este nivel
es donde se produce la asignación de puertos.

Siempre que hablo de esto, la gente se pregunta por que si el ftp, usa
o puede usar UDP, como es que los archivos llegan bien. La cosa es que
es tarea de la aplicación el ordenar y comprobar.

Si en vez de usar holliwood express(tcp) usasen holliwood FTP(udp),
tendrían que contratar a personal que ordenase a los actores y
pidiesen que los reenviasen incluso por otras vias, en caso de que
alguno se hubiese perdido.

Alguien me puede ayudar con la traducción de leaky.

All non-trivial abstractions, to some degree, are leaky.

¿Todas las abtracciones no triviales, son de alguna manera, propensas a
fallar?

Un Saludo.

35

Guillermo,

2008/3/17 Guillermo [email protected]:

Me parece un artículo poco fiel a la realidad. Compara TCP con IP,
cuando la comparación correcta es con UDP. Mientras IP es una
abstacción a nivel de red (internet layer en el modelo reducido OSI)
que podemos ver con protocolos como ping, TCP es una abtacción de esta
(que eso si lo dice el artículo) a nivel de transporte. En este nivel
es donde se produce la asignación de puertos.

TCP no es una abstracción construída sobre UDP sino sobre IP, que es
lo que muestra el articulo. El protocolo que se define sobre el nivel
de red (IP) sirve para llevar mensajes de un nodo a otro en una red de
manera no confiable. La abstracción de esto (TCP) permite que el
envíodel mensaje sí sea confiable (dentro de ciertas reglas, como por
ejemplo, que uno de los dos hosts no se desconecte de la red), así que
en esto el artículo es correcto.

Si en vez de usar holliwood express(tcp) usasen holliwood FTP(udp),
tendrían que contratar a personal que ordenase a los actores y
pidiesen que los reenviasen incluso por otras vias, en caso de que
alguno se hubiese perdido.

Puedes cambiar aquí UDP por IP el ejemplo seguiría funcionando. El
“personal” que se encarga de asegurar de que los mensajes lleguen a su
destino podría ser tu propio protocolo de nivel de transporte.

Alguien me puede ayudar con la traducción de leaky.
¿Todas las abtracciones no triviales, son de alguna manera, propensas a fallar?

La mejor traducción de abstraction leaks en mi opinión sería que las
abstracciones tienen fugas, queriendo decir que lo que hay debajo de
la abstracción a veces se puede fugar (¿salir tal vez?) de la
abstracción. El ejemplo que da Spolsky es el de dañar un cable de red
(si mi memoria no me falla, leí el articulo hace mucho tiempo ya). Las
abstracciones no son perfectas y por eso es deseable tener
conocimiento de lo que está pasando abajo.

–
Federico

36

Retomando el tema principal, les platicare que a mi parecer RoR es
facil, el problema esta en lo que comentaban en un post anterior, no
conocemos ruby,

Por ejemplo yo, soy Ing. en computación, en la universidad aprendi POO,
con java, y despues C++ con los conocimientos de POO , despues por mi
cuenta intente con php, y al empezar el boom de rails, me llamo la
atencion eh intente aprenderlo y si puedes hacer las cosas sencillas
generar scaffold, y saltar de pagina en pagina , pero al momento de
hacer procedimientos mas elaborados me topaba con el problema de que no
sabia Ruby y por lo tanto no podia sacarle mucho jugo.

Por lo tanto creo que parte del problema es que a primera vista todos
los blogs y libros te pintan a Rails como muy facil y lo es, pero si
quieres hacer cosas mas elaboradas, viene el problema que no lo es
tanto, es verdad que facilita mucho el trabajo del programador pero para
este punto debes saber realmente como funciona el framework y ruby , a
mi me cuesta trabajo,porque estoy aprendiendo en mis ratos libres y peco
de hacer preguntas que se solucionan facil aveces , pero si googleo y
checo algunos libros de rails, o la api ,incluso checo si no hay
documentacion de algun error en tal modulo, pero es muy comun buscar en
Internet y en contrar mucha informacion de Rails pero casi toda o
almenos la mayoria es solo de lo facil , un blog , un llamado con ajax,
pero si quieres hacer cosas que no sean las que ponen en el ejemplo si
tienes que experimentar y pues no siempre sale , entonces hay que
recurir a los que mas lo conocen o han tenido el mismo problema

En conclusion, yo opino que Rails es facil, pero para explotar todas sus
bondades hay que leer mucho y aprender poco a poco.

37

Yo diría que … directamente: “Programar no es fácil”.

Creo que es la primera premisa que se debe tener.

:slight_smile:

38

Creo que hay que diferenciar entre facilidad de manejo, y una curva de
aprendizaje fácil.