Mientras los devotos se dan cita en la Conferencia Rails 2008 (o en la paralela CabooseConf), FiveRuns está lanzando TuneUp, una herramienta “social” de debugging para controlar el rendimiento de las aplicaciones Rails.

TuneUp es un plugin que te dice dónde está funcionando con lentitud tu aplicación Ruby On Rails, y es capaz de señalarte las “queries” inadecuadas que has lanzado contra la base de datos. El informe generado se envía a un sitio web para que puedas compartirlo y revisarlo con otros programadores o miembros del equipo (de ahí su denominación “social”).

Visto en TechCrunch.

Ha sido una carrera contra-reloj para llegar a tiempo a la RailConf08, que se celebra a finales de este mes (dentro de nada) en Oregon. Pero, al menos en teoría, el equipo del proyecto Rubinius lo ha conseguido. Rubinius ya es capaz de correr una aplicación simple (aún les queda mucho trabajo por hacer) de Rails.

Algunos, como Chad Fowler, ya lanzan las campanas y al vuelo, y afirman que “en el plazo de un año, Rubinius será usado en los desarrollos de producción y, a partir de ahí, pronto se convertirá en el estándar de Ruby”.

Muchas de las miradas están puestas ahora en IronRuby, la apuesta de Microsoft en este campo. Parece que ellos también están trabajando en la misma dirección.

Más info en InfoQ y en RubyInside.

Rails Cells: desarrollo orientado a componentes para Rails

El objetivo de Rails Cells es “trasladar las ventajas del desarrollo orientado a componentes a la plataforma de aplicaciones web Ruby on Rails, pero sin los problemas asociados al subsistema propio de Rails”. Una “celda” es una especie de controlador ligero con vistas asociadas. Cells quiere insertarse en la tradición de los WebObjects de Apple y el Seaside de Smalltalk.

El mercado de soluciones dedicadas a gestionar el rendimiento de aplicaciones Ruby on Rails sigue creciendo y ya cuenta con un nuevo competidor. New Relic ha conseguido nada menos que 3,5 millones de dólares en una primera ronda de financiación, y tratará de hacerse hueco en un escenario hasta ahora dominado por FiveRuns (que, dicho sea de paso, acaba de publicar una entrevista a nuestro compañero Xavier Noria).

El producto de New Relic se llama RPM y, al menos en teoría, proporciona información que los desarrolladores pueden utilizar para detectar, diagnosticar y arreglar con rapidez los problemas de rendimiento de la aplicación. Por el momento, parece que el RM-Manage de FiveRuns incorpora bastantes más funcionalidades (seguimiento de bases de datos, Web daemon, etc.) pero habrá que esperar a las tarifas de New Relic para ver qué es lo que le interesa a cada empresa.

Como siempre, hay quien opina que no es necesario un servicio propietario para realizar estas funciones, y que hay recursos gratuitos suficientes, tipo Query Reviewer. En cualquier caso, el lanzamiento es interesante, no sólo por la inversión realizada (comparable con la de FiveRuns y Engine Yard ), sino porque demuestra que tanto los medios como los inversores están empezando a tener muy en cuenta los movimientos en el escenario Ruby on Rails. De hecho, la todopoderosa Teccrunch se hizo eco de la noticia.

Vía Ruby Inside.

Esta semana le hemos pegado un repaso a nuestro plugin model_auto_completer con algunas versiones seguidas (release often!) que han llevado a la 1.5.3 de hoy mismo.

Lo más destacado de estas releases:

• Test suite semi-automática.
• Nuevo helper de conveniencia model_auto_completer_result para generar de una tacada la lista de resultados que espera el código cliente.
• Nuevo flag :append_random_suffix que permite deshabilitar la generación de sufijos aleatorios en los IDs de los campos. (Sugerencia de Wolfram Arnold, thank you dude!)
• Nueva opción :url para poder configurar la acción de autocompletado con una named route.
• Corrección de un bug relativo a seleccionar dos veces modelos usando el ratón.
• Buena revisón a la documentación.

Maqueros del mundo, no desesperéis. La sección para desarrolladores de Apple nos ha sorprendido con un artículo bastante práctico e interesante sobre cómo utilizar Ruby on Rails 2.0 en Leopard, la última versión del sistema operativo de MAC.

El “tour” arranca con consejos para construir aplicaciones web explotando las últimas funcionalidades de Rails y termina con la puesta en producción de la aplicación en un servidor Leopard.

Parece que la cosa no va a quedar aquí, y que éste va a ser sólo el primer artículo dentro de una serie. Podéis leerlo aquí. Que lo disfrutéis.

Desde ASPgems queremos dar la enhorabuena a Ernesto Jiménez por haber ganado la Hackfest de febrero, y a Juanjo Bazán por ese peasso de quinto puesto, y no es la primera vez ¡Buen trabajo chicos!

¿Cuál es la mejor manera de adoptar “Agile” para una organización? ¿Hacerlo poco a poco, a partir de un proyecto piloto, o cambiarlo todo de golpe? El patrón más común sigue siendo el de empezar la transición a Agile con un proyecto piloto, para aprender de él y después extenderlo al resto de la organización. Normalmente se arranca con uno, dos o tres equipos de 5 a 10 personas cada uno. Sin embargo, también hay empresas que prefieren atacar el cambio a Agile de una sola vez, es decir, que apuestan por realizar la conversión “de golpe”. Veamos algunas de las posibles ventajas y desventajas:

POCO A POCO

Ventajas.

• Se minimiza el coste de los errores. No es lo mismo fallar con un solo equipo que hacerlo con 100…
• Permite seleccionar y centrarse en los equipos y los proyectos más exitosos, para vencer así las reticencias de los escépticos
• Siembra la organización con personas que actúan como embajadores para que otros comiencen a aceptar el cambio.

Desventajas.

• Las conclusiones del trabajo con un grupo pequeño no tienen por qué ser extrapolables a un proyecto mayor.
• Se tarda más en empezar poco a poco y escalarlo que en atacar el cambio de una sola vez.
• Se puede transmitir la sensación de que la empresa duda o desconfía del proceso ágil, y que por eso prefiere empezar por unas “pruebas” para tantear la situación.

DE GOLPE

Ventajas.

• Muestra el compromiso y la confianza de la empresa con Agile.
• Todo acaba pronto. Puede ser doloroso, pero no dura demasiado.
• Se evita el conflicto entre 2 procesos opuestos, el ágil y el tradicional, que de otra forma tienen que convivir, con los roces que eso implica.
• Los escépticos se ven obligados a asumir la estrategia de la empresa: no les queda otra opción, puesto que es la única estrategia posible.

Desventajas

• La transición es muy arriesgada. La empresa se juega el todo por el todo.
• Lo más probable es que la transición requiera una complicada reorganización de los equipos y las relaciones internas.
• El proceso puede generar mucho stress, presión y tensión.

Más sobre patrones de adopción de agile.

Y otras dos gemas:

1. PHP o Ruby, ¿quién corre más? Un blogero ha realizado un pequeño experimento para medir la velocidad de ejecución -en segundos- del código PHP y Ruby. También ha incluido Perl, Python y C++ en este “benchmarking” casero. Los resultados, aquí.
2. Una compañía de Manchester, 34SP, ha comenzado a ofrecer a sus clientes un servicio de hosting configurado específicamente para Ruby on Rails. Según su director técnico, “Ruby on Rails no funciona bien en un entorno de hosting compartido, así que para sacarle todo el jugo necesitas tu propio servidor. Pero dado que un servidor dedicado puede resultar demasiado caro, ofrecemos un servicio configurado para las aplicaciones de Rails con un frontend Apache“.

Recursos para Ruby y Rails (RRR).

Ruby Plus es un sitio que ofrece screencast gratuitos de Ruby y Rails. De momento, cuenta con 31 episodios grabados por Bala Paranj. Los primeros 12 están dedicados a Ruby (blocks, recursión, etc.) y se encuentran en la sección “Archivo”, por lo que es necesario registrarse para efectuar la descarga; la segunda parte, la más actual, se centra en Rails.

Los screencasts están en la línea de los ofrecidos por Railcasts, el sitio de Ryan Bates. Eso sí, Bates va bastante más adelantado: acaba de “producir” el capítulo #88, dedicado a los menús dinámicos de selección. La descarga también está disponible para iPod y AppleTV. Que aproveche.

Ya están publciados los contenidos de la conferencia Rails del 2.007.

Están e:  Conferencia Rails Hispana

Pronto empezaremos con la del 2.008.

El pasado 6 de noviembre participé en una mesa redonda sobre frameworks en SIMO. Expertos en Drupal, Code Igniter, Zend Framework, .Net y Sun JSF expusieron su punto de vista sobre el estado del arte de los frameworks para desarrollo de aplicaciones web.

Yo por mi parte me encargué de explicar porqué hemos elegido Ruby on Rails como nuestra herramienta favorita para este tipo de proyectos. Podeis ver a continuación la explicación -más o menos fidedigna- que realicé en los 4 minutos de presentación que me correspondían.

Ruby on Rails es un framework para desarrollo de aplicaciones web escrito en el lenguaje de programación Ruby.

En ASPgems, donde todo el equipo tenemos experiencia en otros entornos sobre todo en proyectos grandes en el mundo corporativo, utilizamos Ruby on Rails porque nos permite desarrollar proyectos web de calidad en tiempos muy competitivos y usando metodologías de programación ágiles. Esto nos permite empezar a desarrollar un proyecto con un número mínimo de requisitos que sabemos que van a cambiar mucho durante la vida del proyecto, y que podemos aceptar cambios incluso en los días previos a la salida a producción sin que tengan un impacto significativo en la mayoría de los casos.

Encontramos varias ventajas en Rails sobre algunos otros frameworks. Por un lado, el lenguaje sobre el que se desarrolla, Ruby, es un lenguaje muy orientado a objetos, potente, y muy expresivo. Con pocas líneas de código puedo conseguir muchas cosas, con lo que la legibilidad del código es mayor y la probabilidad de errores se reduce.

Ruby on Rails, es un framework con opinión que se basa en el principio de “Convención sobre Configuración”, de forma que si yo utilizo las convenciones que el framework espera, Rails es capaz de hacer gran parte del trabajo por mí. En rails no hay que mantener ningún fichero XML para configuración de filtros, mapeos, validaciones o nada parecido. Además, al trabajar todo el mundo siguiendo las mismas convenciones, se puede incorporar gente a un proyecto en marcha o rotarla con un coste mínimo.

Otra gran ventaja de Rails, es la filosofía misma del framework. Rails está creado a partir de un proyecto real puesto en producción. Se desarrolló un proyecto web con Ruby siguiendo patrones de diseño estándar como MVC, Inversión de Control, Persistencia de Datos… y se vio que el proyecto funcionaba bien y que había varias partes reusables. Ese código reusable se extrajo para hacer un proyecto Open Source. Además, se le añadió un mecanismo de plugins para poder ampliar o modificar el comportamiento del framework de forma simple.

Como el código del framework es fácil de entender, y es sencillo crear un plugin, en seguida se consigue una comunidad de desarrolladores muy activa. Cuando un plugin se usa mucho dentro de la comunidad, se acaba incorporándo al núcleo del framework; y al contario, si una parte del framework no la usa casi nadie, se acaba sacando como plugin. Se puede seguir usando, pero no se mantiene dentro del framework, con lo que no se convierte en un framework monstruo donde cabe todo.

Debido a esto, tenemos un framework que está vivo y que se va modificando según los proyectos y las necesidades reales de la comunidad que lo usa en sus proyectos en producción.

El resultado es que, para una persona acostumbrada al desarrollo web, se puede desarrollar una aplicación completa con muy poco código. Te puedes centrar en la lógica de negocio y dejar muchos detalles de implementación al framework.

Esto choca con otros frameworks que están pensados en abstracto para cubrir cualquier caso posible, y acaban teniendo una arquitectura tan compleja que en muchos casos te da la impresión de que, más que desarrollar, estás luchando contra el framework.