En el último año me han preguntado en muchas ocasiones las razones por las que la mayoría (¿todas?) de las cosas que hacemos en Linking Paths las hacemos en Rails. Parece ser que mucha gente no comprende que si yo fundé javahispano ahora lo deje por otro lenguaje. ¡Ni que fuera el primero! (obviamente no lo soy). Pero me voy a permitir explicarme en un pequeño post.
Podría decir que la elección de Rails ha sido más bien circunstancial, causada sobre todo por Aitor (Aitor Garcia, de Linking Paths, ese chico que suele escribir por aquí también), ya que le tenía al lado hablándome todo el día de Rails, y me pareció una buena opción. Y no me arrepiento, es una gran herramienta (no es milagrosa, pero es buena en lo que se supone que tiene que hacer), lo mismo que muchas otras son buenas (hace tiempo que tengo claro que la tecnología no es lo definitivo y lo he dicho por aquí) y lo mismo que con Rails también se pueden hacer barbaridades, ni vale para todo (como nada vale para todo), por lo que no encontrareis aquí sectarismo de ningún tipo. Pero esto es el resultado, no la causa. De modo que, ¿por qué dejé Java?.
Primero. No es que lo haya dejado al 100%, simplemente si tengo que empezar algún proyecto web nuevo, es muy probable que no lo haga en Java.
Y segundo, y definitivo. La razón por la que dejé Java fué que me parecía ya demasiado complicado. Me daba pereza. Tan simple como eso. Tan habitual como eso. ¿No esta el mundo java últimamente loco por Groovy/Grails?. Conozco a muchos javeros de antaño (no, no daré nombres, que lo hagan ellos) que están optando por simplificar sus desarrollos con opciones como Groovy. Otros con JRuby, muchos con Rails, también me he encontrado con gente que realmente respeto que se está pasando al PHP (a este si tengo que protegerlo, pobrecito si se entera la gente), e incluso a alguno que dice que si es sencillo, opta por el antaño maltido jsp-spagetti. Y dentro de unos años volverá a cambiarse la gente, no hay nada malo en ello.
Cuando he hablado con toda esta gente que se cambia, o mejor dicho, que ‘aligera’ el desarrollo Java, todos hemos coincidido: unos por otros lo hemos hecho realmente complicado. Para empezar un proyecto web Java, en la mayoría de los casos “empresariales” (ejem) necesitas conocer el framework web de turno, entre 5 y 10 librerias de Jakarta Commons, el API de Servlets, Spring, Hibernate o similar, ant o maven, 10 patrones, una máquina potente para que tire con el IDE y los plugins, tomcat, etc. Seguramente me dejo un montón de cosas más. Pero es que además tienes que tener paciencia. Compilaciones, redespliegues, heap dumps, etc. Simplemente la mayoría nos hemos ido cansando de eso, porque otras opciones nos permiten aligerarlo. Llámese Rails, Groovy, o PHP.
No hay más, así de simple.
Tienes bastante razón Alberto. Desde luego en aplicaciones de arquitectura sencilla el utilizar Java se hace complicado por todo lo que dices.
Yo ahora, tengo algún pequeño proyecto y lo estoy haciendo en PHP utilizando un framework MVC y la orientación a objetos del lenguaje.
El libro de rails lo tengo comprado, pero en la cola de pendientes :-)
Un saludo:
Miki
… Y además, como nosotros no mantenemos en producción esas aplicaciones que se peguen otros con los problemas de rails en producción.
Yo me he cambiado a Groovy on Grails. RoR no se puede vender dentro de la gran empresa, no te lo compran los equipos de operaciones y sistemas.
Firmado:
Otro que se ha cansado de seguir aprendiendo frameworks web en java.
Completamente de acuerdo. Yo soy (momento alcohólicos anónimos) el que de vez en cuando tira de JSP ‘a pelo’. ¿Por qué? por dos razones: la primera, que lo hago cuando quiero protipado rápido. Muchos dirán, ‘¿pero no es este el tío de groovy y grails, y no es grails ese framework-maravilla que permite prototipar rápido?’ pues si, pero eso nos lleva a la segunda razón: uso jsp a pelo cuando quiero probar un pequeño servicio que consuma el mínimo de recursos de mi servidor.
Grails es para mí la mejor opción siempre que se trate de proyectos con cierta garantía de supervivencia, suficiente como para asignar recursos de hardware. Pero a veces sólo queremos lanzar un pequeño servicio al mundo y dejarlo vivir un par de meses, ver si tiene tirón, enseñarlo a un par de posibles clientes, y si al final gana momento, tiramos a la basura el prototipo y empezamos un desarrollo serio respetando el modelo de datos. Nuestros recursos de máquina son limitados, y tenemos que saber administrar bien…
Sé que algunos me vais a entender, y otros no, y sé que los que no me vais a entender sólo lo haréis cuando estéis en una situación similar a la mía (fuera, en el mundo real, sin red…). Yo pasé por ese proceso.
Lo has resumido muy bien en el último párrafo. Yo también me he cansado de compilaciones, redespliegues,… Java me gusta mucho, pero para hacer webs hay mucha sobreingeniería o demasiada diversidad de opciones. Por eso mi último desarrollo lo he hecho con PHP Zend Framework. No obstante ahora he comenzado un desarrollo con GWT-Ext y también me está gustando mucho.
saludos!
Yo cada vez me meto más en Rails, cada vez leo más, cada vez me gusta más, para cosas web me parece cada vez mejor, ¿por qué? Por lo que dices, por su simpleza, por lo simples que pueden llegar a ser cosas que en Java hay que darle vueltas y horas.
El problema, mio, personal, es que no creo que pueda aplicar esto para entornos de producción o mejor, no creo que pueda desarrollar en RoR para una empresa, porque son pocas las que quieren/buscan ese tipo de perfiles. Sin embargo eso no me hace más infeliz, simplemente me permite disfrutar más.
… Y además, como nosotros no mantenemos en producción esas aplicaciones que se peguen otros con los problemas de rails en producción.
Diego, me gustaría saber por qué dices eso. Primero porque nosotros mantenemos nuestras aplicaciones. Y segundo porque no sé, basarse en el caso de twitter (perdón por la simplificación) me arece un tanto injusto como para soltar semejante frase. Sé que eres un tio inteligente, así que me gustaría saber si me he perdido algún tipo de ironía por eso de hacerme viejo.
Pero si te tengo que decir la verdad…. me he encontrado a los administradores de sistemas más receptivos a trabajar con rails que con java, porque son herramientas mucho más cercanos a ellos.
En todo caso, como he dicho, no voy a defender a Rails (ya he dicho que es el resultado circunstancial), ni quiero crear otro flame, me basta con que todos confirmeis que ibamos por el mal camino y con no tener que repetir esta historia más XD.
Hola.
No tengo una buena experiencia con el RoR, al momento de que empezar a usarlo no estaba seguro de que es lo era. Cuando me di cuenta de que era algo parecido a un CGI, pues necesito tener instalado un servidor que soporte ruby en el servidor. En 1ra instancia tenia que instalar el Apache con el modulo para soporte de Ruby(eso creo), la otra opción era bajar un servidor ligero que te permitiría trabajar sin necesidad del apache. Lo cual nunca pude hacerlo.
Luego de pasar un suplicio tratando de configurar el Apache para ejecutar unos aplicativos demos de RoR desiste, pues estaba perdiendo mi tiempo, me parece mas fácil el tomcat no depende del Apache y el despliegue de los WAR’s es simple.
Luego use algo del RubyGems para bajar todo lo necesario para trabajar. Ejecute unas cuantas instrucciones, logre levantar el servidor, pero lo malo es que no todo trabaja como decía el manual.
Si comparo cuando aprendí a levantar mi tomcat y deployar mi war por 1ra vez, sinceramente la plataforma java (en este caso el tomcat y lo mismo podría decir del jboss) es mas fácil que RoR.
No desestimo en aprender RoR, pero para ser sinceros me decepciono para ser la 1ra vez, fue algo realmente traumantizante
Manuel Loayza
SCJP,SCBCD,SCWCD
Yo creo que mas que el que estaba torcido era el camino, pero no Java. Yo soy uno de los que usan ahora Groovy para algunas cosas, por que me es mas comodo, pero sigo programando en Java y no me oiras quejarme de despliegues y re-despliegues, empaquetados, XMLs de la muerte, commons a porrillo etc.
La cuestion es que en “el camino Java”, la gente se ha ido complicando mas que un tonto, sin cuestionarse por que, que beneficios y a que coste. No he usado Spring mas que una vez en un diseño que no era mio, los EJBs 1.x y 2.x los probe y descarté, mis aplicaciones corren en practicamente cualquier contenedor de servlets y virguerias uso “las justas”, no uso .war, no uso .ear, el 90% del programa es recargable en ejecucion… asi que estoy contento, por que es lo que me sirve.
Ojo, no digo que Java sea perfecto y lo cubra todo pero vamos, que si antes usabas Spring y EJB era por que se suponia que te daba unos beneficios a cambio de esa complejidad, y ahora que usas otra cosa (Rails/Grails/Zend… que mas da)… ¿resulta que ya no necesitas lo que te daba Spring/EJB? No será que tampoco lo necesitabas antes y que te estabas complicando la vida.
Y si, hay cosas en las que esta la equivalencia y es mas sencilla, por eso uso yo Groovy por ejemplo, pero vamos, en el 90% de casos apostaria a que el problema no es Java sino pensar que “una aplicacion web en Java” significa Spring, patrones por aqui y por alla, capas sobre capas que encapsulan capas de capas. Lo que ha cambiado es la percepcion de que quiza no haga falta todo ese meollo que algunos se montan, pero para no admitir que en realidad nos equivocabamos con tanta parafernalia, es mas facil decir que la culpa es del lenguaje y que con otro todo es más sencillo.
Ilusiones. Dadle unos años y cualquier lenguaje que se haga popular ira extendiendo sus “zarpas” para cubrir mas y mas “use cases” y acabará convirtiendose en un monstruo complicado con un monton de opciones. Es ley de vida.
Y vuelvo a matizar que cada vez se mejoran algunas cosas, lo cual es bueno, y no estoy en contra del cambio en si, pero en la mayoria de casos muchas de las razones “técnicas” aducidas para cambiar son cortinas de humo, voluntarias o ilusorias.
Hola Dani,
Estoy de acuerdo, si no me he explicado bien, lo reitero, esto no es algo contra Java, es algo contra lo complicado que lo estabamos haciendo. Creo que no tengo que repetirme en que ninguna tecnología es mala en si misma, ya lo he comentado a menudo.
Manuel, está claro, todo el mundo tiene buenas y malas experiencias. Es como un coche, los hay muy felices con un Audi porque les ha salido bien, y otros que lo tuvieron y no quieren volver a verlo.
En cualquier caso estoy de acuerdo, a día de hoy, Rails es todavía un tanto “búscate la vida”, pero creo que es la tendencia de la internet actual, dónde la información esta repartida opr un montón de sitios, sobre todo blogs.
@Alberto,
Sí, mi comentario iba contenido dentro de tags “ironic”, pero parece que no admite tags tu software de blogs. Sin la ironía suena ambiguo y hasta hiriente. Con ironía suena… irónico :-)
Llevo varios años trabajando como puente entre equipos de desarrollo y gente de sistemas, y la gente de sistemas es mucho más conservadora que la gente de desarrollo. Por eso, incorporar una nueva tecnología que no encaje en su mentalidad es tarea imposible. Además, en las grandes empresas la certificación de nuevos productos puede llevar meses e incluso años. Así que cuando les hablas de Mongrel, dicen que te dejes de chorradas. Lo que les vale es que se despliegue dentro de un WAS o de un Weblogic. O de un Tomcat si no queda más remedio. Empresas que se empiezan a plantear usar la JVM 5, y que siguen explotando aplicaciones sobre BEA Weblogic 7 y Oracle 9i.
Por eso me gusta Grails: la gente de desarrollo adopta antes que la gente de sistemas, y pueden ‘colarles’ aplicaciones Grails a la gente de sistemas ya que no les afecta. Supongo que esto aplica también a JRuby, pero el mundo Java es el mundo de la integración con sistemas heredados (sean Java, Cobol, Fortran o lo que sea), y para eso Grails y su integración con Spring ayuda mucho.
Me gusta el concepto de RoR (por eso me gusta Grails), pero no encaja en los proyectos que suelo estar involucrado.
Creo que no tenemos que hundir RoR porque no sea simple su puesta en producción. Es cierto que es más complicada la configuración inicial ya que hay conceptos distintos, que si apache, mongrel, etc… que tienen que funcionar conjuntamente.
¿Pero esto no es trabajo de sistemas? Esta claro que no podemos ser expertos en desarrollo y montando servidores. Podemos tener una idea pero quien mucho abarca poco aprieta. Aunque está claro que muchos tenemos que espabilar-nos y hacer de todo ya que no tenemos los recursos suficientes.
Mi caso es un poco distinto al vuestro ya que no vengo del mundo java. Yo primero empecé con ASP, después por suerte me llegó PHP y empecé RoR por curiosidad y formación personal y lo cierto es que me encanta. Por cuestiones del destino llevo unos meses peleandome con java y struts y la verdad acostumbrado al PHP y RoR, me costaba un montón las esperas de las compilaciones y los deploy. Estaba acostumbrado a modificar y probar, ahora modificas, esperas, esperas y pruebas.
Con java tengo sentimiento encontrados, por una parte su framework struts me obliga a ser muy ordenado hecho que facilita el mantenimiento, pero veo que hacer cualquier cosa es extremadamente lento ya que hay que hacer mil cosas (no conozco otros frameworks para java). Por otra parte, redefinen casi la web, todo tags nuevos… cosa que no me gusta, me gusta usar los estandares de siempre y no estar aprendiendo siempre mil tags con mil propiedades, tengo mala memoria :P
Yo personalmente me quedo con RoR o PHP, aunque la instalación no sea evidente.
Escribid más!! :D Soys geniales :D
Todo esto me resulta abrumador: Ruby, Rails, JRuby , Groovy, Grails…..Estoy bastante perdido, ya tengo bastante con la complejidad de Java.
Nunca me han gustado los lenguajes poco tipados. Mi experiencia con PHP ha sido bastante agridulce y no creo que ninguno de estos nuevos lenguajes dinámicos requiera mi atención por el momento. Tal vez Groovy antes que Ruby….pero en un futuro muy lejano…
Soy autonomo freelance y mis premisas son desarrollar proyectos lo más rápidamente posible, pero sobretodo mantenibles. Con mi própio framework en Java ‘Cinnamon’ (pronto lo liberaré a la comunidad) ya tengo bastante.
Me he dado cuenta que el Hosting es lo que manda en aplicaciones web, sobretodo para las pequeñas empresas. Te encuentras que la mayoria de nuevos clientes ya tienen dominio propio con email y hosting sencillo (PHP/MySQL). No les puedo vender la moto de que contraten un servidor dedicado y me he de adaptar a PHP en bastantes casos.
El Hosting de Java brilla por su ausencia, sobretodo aquí en España. ¿Pasará lo mismo con Ruby y Groovy?. Sin saber mucho de lo que hablo, vosotros me lo confirmareis: Ruby puede funcionar con Apache Web Server y Groovy con un servidor Web Java tipo Tomcat ¿No?….Entonces a priori parece que Ruby tiene más papeletas de que sea adoptado por los proveedores Hosting hispanos habituales (Arsys, Amen, Nominalia, etc). ¿Que creeis?
@Alberto. Entiendo, no lo decia por ti y en tu caso lo explicas clarito y conciso. Es mas una opinion en contra de toda la gente que parece que para cambiar tiene que renegar de todo lo anterior. Y el caso de por que manulinx es un claro ejemplo. Java no es Struts, ni te obliga a usar todos esos tags que no son HTML, ni a hacer despliegues y redespliegues, empaquetados y “mariconadas”. Yo uso Java y no hago ninguna de esas cosas. Pero mucha gente confunde unas cosas con otras.
Y en unos años cuando RoR intente abandonar su nicho para cubrir un expectro mas amplio de aplicaciones, pues le pasará lo mismo, como a Grails, como a todo hijo de vecino.
Lo del hosting es un tema interesante que no se como tirara. Uno de los empujes que tendra Ruby será, creo, gracias a JRuby y a poder integrsr muchas cosas ya hechas en Java y zas, de golpè disponbles sin tener que re-escribirlas. Pero claro, eso pasa por ejecutarse en una JVM y no ocurre con un mero Apache Mongrel. Ahora mismo no me mojaria en como va a seguir la cosa.
Ummm, releyendolo. Con lo del claro ejemplo de manulinx no me referia a alguien que se cambie y reniegue de lo anterior, si no a alguien que percibe usar Java con usar Struts, en este caso no por culpa suya. Como las dos frases estan seguidas, da otra impresion y no queria dejarlo pasar sin aclararlo.
Ms disculpas si parece otra cosa.
tranki greeneyed.
Struts no es java, eso esta muy claro aunque a veces se generaliza de forma incorrecta ya que el framework usado no sea el mejor. Aunq el tiempo te da el conocimiento de valorar cada elemento con su justo valor.
Bueno, no pienso que haya que “huir” de Java porque sea complicado -de hecho tampoco creo que lo sea-, los frameworks y tecnologías que se generan entorno a Java facilitan enormemente la labor de desarrollo, es más, os imagináis afrontar un proyecto J2EE de envergadura desde cero?… sin Struts o Spring o JSF o Tapestry o Hibernate o … buff, eso sí que sería duro.
Ahora bien, por qué Java en lugar de Ruby/PHP/…?, realmente no lo sé, llevo seis años desarrollando proyectos J2EE y todos ellos podrían haberse realizado perfectamente con PHP -aún no conozco Ruby-. Lo de proyecto pequeño -> PHP y proyecto grande -> Java no me convence nada, sobre todo porque no sé de ningún factor en estos lenguajes que determine esta regla.
Por poner un caso cercano… un proyecto en el que participé durante mis comienzos: pobladores.com -en su día, hayá por la web 1.0, llegó a ser la comunidad virtual de habla hispana más importante-, se desarrolló utilizando PHP/Perl, y a día de hoy, si me preguntaran si se podría haber mejorado algo utilizando Java, mi respuesta sería no.
En mi opinión, el que se opte por Java (o .NET) a nivel empresarial, sobre todo en grandes empresas y AA.PP., es simplemente por una cuestión de marketing, y es que realmente no sé muy bien el porqué se ha extendido la idea (sobre todo entre directivos, gerentes y demás cargos con poder de decisión) que Java/.NET son lenguajes de “clase alta” y PHP/Ruby/… son lenguajes de “clase baja”, de andar por casa, vamos.
Y es que hoy por hoy se vende muy bien decir que mi producto X con arquitectura SOA ha sido desarrollado con Struts2 Spring Hibernate Maven … por mi equipo de SCWCDs, SCJPs, SCDJWSs…, en lugar de simplemente decir que ha sido elaborado con PHP o Ruby/Rails por mi equipo de desarrolladores.
Sinceramente espero que este “clasismo” desaparezca cuando algún día todos empecemos a entender que el factor que menos determina la calidad de un producto es el lenguaje sobre el que se ha desarrollado.
No estoy de acuerdo Luís.
PHP es un lenguaje ‘no tipado’ por eso yo lo consideraría de gama ‘baja’. No me imagino una aplicación de software bancario o de seguros realizada en PHP.
Yo no puedo vivir sin tipos de datos. Es como si a alguien se le ocurriera declarar como ‘varchar’ todos los campos de las tablas de una base de datos.
PHP es para lo ques es: sites web de presencia de empresa, blogs, pequeñas aplicaciones de gestión, etc…..
Y hacer grandes proyectos sin Struts o Spring claro que es posible…..aplicando arquitectura basada en estándares JSR’s como JPA, JSTL, etc…al final de tanto utilizar frameworks ya nadie se acuerda de que es un Servlet…..una pena.
OT: Por cierto MrFishKill, de un framework propio minoritario a otro ;), si algun dia te apetece comentar cosas sobre tu framework, como lo usas, para que te sirve, etc., yo te cuento lo del mio y las herramientas que puedo usar gratuitas por ser Open Source, etc.
No te podré comentar como hacerlo un exito mundial :), pero bueno, que siga vivo tras 10 años de vida, algo es ;).
Hola Alberto, conoces GeneXus?
A pesar de no ser un lenguaje de programación en si, es una muy buena alternativa que intenta abstraer muchos de los temas que mencionas.
www.genexus.com
Un saludo
Vito, no, no conocía genexus, al menos no recuerdo ese nombre asociado a eso. Le echaremos un vistazo. Gracias.
Yo también llevo algún tiempo trabajando en Rails y me gusta, sobre todo porque me lo paso bien trabajando. Hace año y medio estaba echando pestes del trabajoq ue había escogido y pensando a qué podía dedicarme en lugar de a trabajar en banc online con un megaframework ‘infuncional’. Pero me ofrecieron la oportunidad de aprender Ruby y programar sobre Rails, y eso llevo haciendo el último año y medio.
Rails tiene sus cosas buenas y sus cosas malas, como todo. Pero en general, tanto lo bueno como lo malo es simple y rápido entender. Y eso que la versión 2.0 se ha complicado un poco y el paso unitario hacia REST aún no lo veo claro (sobre todo esa idea de Rest o REST que parece existir). Todavía no veo Rails para algunas aplicaciones pero poco a poco vemos avanzando.
Salud¡