juan lucas dijo

Hombre, una de las razones es que la performance es muy muy muy pero que muy mala.
php con un framework (aunque sea hecho desde dentro) o asp.net son muy superiores a ror.

el que un cio no siga la moda no significa que sea más tonto que los demás.
vamos, digo yo.

saludos!

27 Abril 2010 | 08:54 AM

Alvaro dijo

Nosotros somos pequeños como dices y utilizamos Danjo/phyton que es prácticamente lo mismo. El problema es que no encuentras gente buena que desarrolle en estos lenguajes y los que hay ya están trabajando y bien pagados... nosotros estamos buscando en Mexico y Argentina gente que desarrolle en estos lenguajes porque nos dimos por vencidos aquí.

Alvaro

27 Abril 2010 | 09:02 AM

Iván de Benito dijo

Buenos días Rodolfo. Como veo que nadie ha contestado seré yo el primero...

Pues si te soy sincero no se como no tiene más tirón. Yo personalmente uso Symfony que sigue la misma filosofía que Ruby on Rails y no he experimentado nada con ROR por falta de tiempo más que nada...
Yo personalmente, más que centrarme en ese framework en concreto y el porqué no despega me centraría en cuestionar... "¿porqué no funcionan los frameworks en los entornos de trabajo?". He trabajado en varias empresas y en ninguna de ellas se usan frameworks que no sean "propios". Es como si se quisiera reinventar la rueda en cada empresa.

Todo el mundo sabe que son mucho más productivos y sólidos a la larga, todo el mundo sabe que usando eso si contratas a un programador o alguna otra persona se tiene que poner a programar va a saber como funciona, todo el mundo sabe que las propias empresas desarrolladores ofrecen mantenimiento de los 'bugs' del propio framework... y como esas, miles de ventajas de usarlos.

Yo me decanto más por el motivo de que la gente no quiere pagar el precio de la curva de aprendizaje que suponen en los inicios (recompensado con creces cuando se usa) y prefieren el... "déjame que esto lo hago yo en 5 minutos y así sabremos como funciona porque lo hemos programado nosotros" que el... "vamos a invertir en aprender 5 horas para luego hacer las cosas en 2 minutos".

¿Alguien más se anima a comentar su punto de vista?

27 Abril 2010 | 09:17 AM

Jose M, Cantera dijo

las prestaciones y escalabilidad de RoR están todavía por demostrar
aunque el potencial del lenguaje es alto en cuanto a incremento de productividad y agilidad en el desarrollo los entornos de ejecución todavía no son maduros, desde mi punto de vista

un saludo

27 Abril 2010 | 09:59 AM

Alejandro Andrés dijo

Buena entrada, yo estoy aprendiendo rails ahora mismo, dejando un poco "atras" otros frameworks como symfony, que tampoco es muy usado.
El problema (creo yo) es que los grandes desarrollos de sw en España llevan mucho dinero detrás y por lo tanto se busca el gastar todo lo posible. Y eso requiere tiempo. No le vas a decir al cliente que le cobras 2M€ por una web que luego es fácil de usar y has tardado en hacer 3 meses. Es mejor que tenga muchas opciones muy difíciles de encontrar (quiere decir que has trabajado más) y tardar en hacerlo 2 años (quiere decir que has trabajado muy duro mucho tiempo).
Recomiendo leer a todo aquel que le interese el montar una startup tecnológica (aunque no sea con RoR) los dos libros de 37signals: Getting Real y Rework. Pueden abrir bastante la mente a nuevas formas de hacer las cosas, mucho más ágiles y dejando atrás paradigmas y metodologías mastodónticas, orientadas a proyectos dinosaurio de grandes empresas, que se trabaje o no se trabaje fluye el dinero.

27 Abril 2010 | 10:01 AM

JoSeK dijo

Rodolfo, ya que te parece de retrógrados no utilizar Ruby on Rails, cuéntanos qué ventajas tiene a la hora de desarrollar grandes aplicaciones web.

Y que conste que me gusta mucho RoR para prototipar, pero me parece que lanzar posts como este, que no están fundamentados para nada, no aporta valor. Empresas como Twitter lanzaron su primera versión sobre RoR y han tenido que migrar a otros lenguajes (véase el caso de Twitter que ha dejado de usar RoR para ciertas partes críticas de su plataforma).

RoR no es la solución definitiva, ni la herramienta básica de los "monstruos de la programación". RoR es una alternativa más que puede ser muy útil en determinados entornos, pero que se une a un ecosistema muy amplio de entornos de desarrollo para la web.

Por otro lado, el tema que comentas de COBOL es más un problema de la industria financiera que la del software (aunque creo que hace años ya que COBOL dejó de ser la principal fuente de ingresos de la industria del software en España). Es la banca la que no quiere arriesgar a migrar sus aplicaciones escritas en COBOL que gestionan partes críticas de sus procesos, y por ello pagan verdaderas barbaridades por seguir manteniendo esos sistemas.

Está claro que la industria del software en España no está al nivel de la industria del software a nivel estadounidense, pero hablar de CIOs retrógrados por no usar RoR es otro cantar.

27 Abril 2010 | 11:15 AM

Jordi dijo

Los proyectos que llevan años en internet necesitan de una inversión muy grande de tiempo y dinero para cambiar de tecnología, por eso no es normal contratar técnicos en RoR a no ser que sean para miniproyectos que puedan estar aislados con el resto.

27 Abril 2010 | 11:33 AM

Daniel Brandi dijo

Hola Rodolfo,

creo que has tocado un tema interesante en el que como CTO de algunas empresas de Internet he tenido que abordar alguna vez: RoR si o no.

Cuando abordamos la decisión de elegir en qué lenguage de programación vamos a desarrollar nuestras aplicaciones debemos tener en cuenta que estamos tomando una decisión a medio o largo plazo ya que cambiar de lenguage de programación supone casi dos años de freno en la evolución de nuestro producto. Por ello debemos tener en cuenta que el lenguage elegido nos debe permitir desarrollar aplicaciones flexibles y escalables, debemos poder encontrar buenos profesionales a precio razonable y sobre todo debemos estar seguros de que no es flor de un día y ese leguage va a seguir evolucionando y mejorando.
Normalmente solemos tener cuatro alternativas en la mano: Java, PHP, Ruby y .NET. Casi todos los que nos dedicamos a Internet solemos desechar .NET rápidamente por ser un entorno propietario y que necesita de tecnología Microsoft para funcionar (proyecto Mono aparte). De las tres alternativas que nos quedan siempre miramos con recelo a RoR ya que todo lo que leemos al respecto es que escala bastante mal, para funcionar decentemente necesita de un servidor de aplicaciones Java modificado (JRuby) y es muy complicado encontrar más de una referencia (Twitter) de web de gran crecimiento y escalabilidad de exito.

Por ello mi opinión es que siempre con el espiritu de tomar la decisión adecuada, decidimos que las apliciones web de la empresa se desarrollen en Java o PHP.

Un saludo

27 Abril 2010 | 12:29 PM

menestro dijo

Bueno, desde el punto de vista de un "CIO" o Analista, la respuesta es bastante más sencilla. Actualmente RoR no cuenta con el respaldo de ninguna corporación o grupo de desarrollo importante que apoye o impulse esta tecnología, lo que lastra bastante sus posibilidades de interacción en los entornos de desarrollo que lideran el resto de compañías.

Sin hacer una disección del entorno, que me resultaba muy atractivo en sus inicios, hay que ser conscientes del escenario actual en lenguajes de desarrollo. Microsoft apoya a la plataforma .NET y C#, Oracle y SUN cimentan sus sistemas en Java, Google se ha decantado por Python y Go, Y la comunidad Open Source lleva mucho tiempo utilizando como plataforma de desarrollo LAMP, con PHP como lenguaje en detrimento de antiguo binomio Perl-CGI.

Esto limita mucho la capacidad de crecimiento del ecosistema de RoR. Esa es la realidad, no es un fenómeno nuevo en el mundo de los lenguajes de programación. Para la elección de una plataforma de desarrollo hay que tener muy claro el aspecto relativo a la estrategia tecnológica y los apoyos que recibe, no basta con que sea una plataforma atractiva para los programadores. En muchas ocasiones estas alianzas estratégicas y posibilidades de crecimiento son determinantes en si mismas a la hora de elegir una plataforma de desarrollo, más que las propias cualidades de ese Framework.

Pasado un tiempo se produce en el mercado el temido efecto de retroalimentación similar al que sucedió con las cintas de video, relegando a los competidores con mejores cualidades técnicas, Beta y Video2000, en beneficio de la plataforma más difundida por los distribuidores cinematográficos, el VHS.

Esta es una de las razones de la importancia de que las decisiones tecnológicas sean tomadas por directores tecnológicos y no por programadores o personas con un perfil técnico exclusivamente. Es una decisión estratégica en la que influyen variables económicas, de mercado, escalabilidad, soporte, y muchas otros aspectos que no pueden ser valorados sin la orientación y perfil adecuado en ese área.

Si en cualquier empresa es una área de importancia vital, más aun precisamente en empresas del ámbito de la tecnología. Una decisión en ese terreno determinará la trayectoria futura de esa iniciativa.

Si tenéis en consideración la importancia de un director financiero o comercial, el peso de un director tecnológico abarca habilidades y competencias muy similares en la toma de decisiones aplicadas al ámbito tecnológico. No es para programadores.

27 Abril 2010 | 10:27 PM

menestro dijo

Se me ha escapado un CIO por CTO. Se entienda lo que corresponde.

27 Abril 2010 | 10:30 PM

menestro dijo

Aunque hay una cosa, que después de alentar el pragmatismo en la toma de decisiones tecnológicas, no quiero dejar de subrayar porque lo considero interesante, creo que la elección de RoR de La Coctelera es bastante acertada, por citar dos razones, primero porque la diferencio dentro del desarrollo de plataformas de blogging, y segundo porque supone liderar esa tecnología en país como España, y es precisamente esa última razón la que la posiciona muy favorablemente dentro del mercado de esta tecnología. Lo que debería ser un elemento de dinamización de este framework en muchos otros proyectos.

No todo van a ser desventajas en tecnologías incipientes, el posicionamiento también es una consideración importante.

Tal vez Rodolfo, tengas bastante razón en pensar que esta todo por hacer y que hay que sentar las bases de desarrollos más ambiciosos en tecnología. Tal vez solo es necesario darle el enfoque adecuado.

27 Abril 2010 | 10:55 PM

unoqueva dijo

Menestro, lo que comentas es pura y simplemente FUD, aquello que se resumia con la frase de marras: «No one ever got fired for buying IBM».

27 Abril 2010 | 11:44 PM

Sergi Morales dijo

Buenas, después de hablar bastante con gente que desarrollan o quieren desarrollar en RoR por las ventajas de tener un desarrollo rápido siempre me encuentro que me preguntan. ¿Y no conocerás a alguien que sepa de llevar un servidor RoR?
Y la verdad es que no conozco a ningún proveedor de hosting, housing, IaaS, o como se quieran identificar que pueda decir claramente que es bueno en la gestión de un entorno RoR, con sus tunings de los mongrels, accesos a DB, etc.
Por desgracia, el modelo de gestión de peticiones de Ruby es bastante diferente al del resto de lenguajes y claro, debes conocer sus manías para proponer algo decente.

¿Y porqué el que sabe de RoR no se mete a gestionar el servicio? pues porque la mayoría de veces son pequeños y no pueden asumir montar un 24x7, con lo que se van a los USA a montar máquinas con todo lo que implica (latencias, lopd, horarios, etc) o se van a un Java / PHP / .Net donde aquí no se si expertos pero si experiencia en la gestión de entornos grandes y pequeños.

Y como todo en esta vida, si la demanda no encuentra oferta pero tiene productos substitutivos y se va hacia los otros, porque la oferta tiene que meterse en cambiar su modelo, hasta que no exista suficiente demanda, no formo a mi gente en RoR, Ruby, Mongrels y demás.

Por mi experiencia, los únicos proyectos RoR que van avanzando son los que tienen el conocimiento interno, muy al estilo DevOps y si les falta algo, consultoría externa para acabar de limar las asperezas del RoR en entorno productivo. Por ejemplo como configuro los servidores para tener usuarios concurrentes, ya que Mongrel (el Tomcat de Ruby) solo permite un thread simultáneo

Saludos

28 Abril 2010 | 11:27 AM

ger dijo

Muy sencillo, ahora mismo no hay nada en ror que no se pueda hacer con otro framework.
Yo mismo me pase de ror a django (python) en su dia, el motivo, a mi modo de ver se consigue una mayor productividad con django.
(no doy el enlace pq no lo encuentro, pero en su dia encontre un post comentando que en silicon valley,en las nuevas startups ya se usaba mas django que ror)

28 Abril 2010 | 05:58 PM

Román Cortés dijo

La respuesta más simple que se me ocurre: no hay documentación oficial de RoR en castellano y el nivel de inglés en España es bastante bajo. Por otro lado, alternativas como PHP sí que disponen de una documentación amplia y totalmente en castellano.

Se me ocurren otros factores, pero yo diría que este es el principal.

2 Mayo 2010 | 03:00 AM

Jose M. Cantera dijo

hombre decir que porque la documentacion no está en ingles ... es un poco fuerte por no decir descabellado. Cualquier técnico en informática medianamente competente sabe al menos leer documentacion en ingles xD ejem, ejem

3 Mayo 2010 | 08:45 AM

Lluis Faus dijo

Rodolfo,

vLex.com está programado en Rails y tiene un nivel de complejidad muy grande y un tráfico bastante relevante. En mi opinión lo de "las prestaciones y escalabilidad de RoR están todavía por demostrar" es un tópico. En nuestra experiencia usar Rails ha sido una muy buena decisión por múltiples razones. Sin embargo el principal concern es el acceso al talento. Existen muy pocos desarrolladores con experiencia.

BTW si hay algún lector desarrollador en RoR y quiere trabajar en una empresa fantástica.... que se ponga en contacto con nosotros !!!! ;-)

5 Mayo 2010 | 08:57 AM