En enero eran 230.000 el número de copias descargadas de Ruby on Rails.
En la actualidad el 5% de los programdores lo usan de forma regular. Su principal fortaleza es la rapidez para el desarrollo de aplicaciones web: “Un programador de Rails puede hacer el mismo trabajo que un equipo de Java” (Curt Hibbs).
“En un pequeño desarrollo para una startup el código fue la cuarta parte, y el tiempo de configuración el 10% del que hubiéramos empleado con Java” (Bruce Tate).

Estas son algunas de las cosas que publica “en abierto” el número de Febrero de la revista de IEEE Computer Society en el artículo Will Software Developpers Ride Ruby on Rails to Success.

El rumor de que Google iba a lanzar un editor de páginas web se ha confirmado.
Google Page Creator es un servicio gratuito para diseñar y cargar tu propia página web en la dirección nombreusuariogoogle@googlepages.com

Me ha parecido muy interesante el último artículo de Digital Web donde se habla de los patrones de presentación Web y la arquitectura Model-view-controller. Para los que no estén familiarizados con este tipo de metodologías, el dibujito que acompaña al artículo es muy esclarecedor:

El modelo se entiende con facilidad: cuando se realiza una petición HTTP, antes de volcar la respuesta (normalmente en HTML, pero el caso es el mismo cuando se devuelve XML, PDF, etc.) un mecanismo en el código evalúa los inputs, realiza las acciones oportunas basándose en un “diccionario” de posibles argumentos y establece el valor de variables y objetos globales. A continuación transfiere el control a la presentación de la página, donde la interfaz debería encargarse de indicar al usuario qué es lo que realmente hemos hecho con su petición: resultados de búsqueda, entrada en un backoffice, mostrar errores encontrados, etc…

El artículo plantea los dos casos de uso de este principio. El Page Controller es el uso natural, cada página se controla a sí misma y a veces podría ser una entidad independiente de todo el desarrollo. Este es el tipo de metodología que encontraremos en la mayoría de proyectos Web. El otro caso es el Front Controller, que extiende el modelo de escucha y control a cualquier petición realizada, y aunque cada página disponga de su propio módulo de presentación, el núcleo de respuesta que decide el estado del sistema es común a toda la aplicación.

Implementar un controlador es sencillo. Puedes hacerlo mediante una clase única que se instancia en cada petición, o bien un conjunto de variables globales, funciones, etc.

-Eh, que mi “aplicación” es una página web para la tienda de la esquina y no necesito ese rollo de controladores, como mucho para el formulario de contacto, y eso ya lo tengo arreglado.

Bueno, probablemente con lo que tienes puede bastar. Pero veamos qué ventajas pueden extraerse de introducir un controlador común a todo el desarrollo:

• Antes de llamar al controlador puedes definir en sus variables el título de la página, palabras claves, imagen de la cabecera, etc. El controlador los almacena y las cabeceras y los pies de página pueden ser includes que tomen estas referencias del controlador. Muy útil para meter aquí todas las técnicas SEO.

• Si la mayoría de las páginas contiene un formulario de búsqueda, enviar a un amigo, etc. el controlador podría encargarse de comprobar si se han realizado búsquedas, almacenar los resultados, etc.

• Registra los referers y añade un sistema de estadísticas personalizado desde el controlador sin añadir más dependencias a la aplicación.

• Controla el estado de las cookies u otro sistema para comprobar la identificación de usuarios en las páginas de administración.

• En una única función/método se centralizan todos los casos de uso del sitio web, y si se aísla convenientemente de la presentación puede reutilizarse para otras interfaces de servicios web, sindicación RSS, etc.

Y a ti seguro que se te ocurren utilidades más específicas, prácticas y reutilizables.

Nuestro colaborador Juan Palacio relata en su weblog cómo una empresa de desarrolladores sobresalientes ve bruscamente disminuido su potencial y efectividad después de ser pasada por el rodillo de la normalización. Y es que si planificas todo tu entorno para adaptarte a la media de tu sector ¿es extraño que acabes con una empresa que no está mas que en la media?

Esto me recuerda a un chiste que se me ocurrió hace tiempo relativo al proceso de certificación de calidad ISO9000:

¿Cual es el ciclo de vida de una empresa?

Respuesta:

• Formación.
• Expansión.
• Asentamiento-rentabilidad.
• Decadencia.
• ISO 9000.

Después de muchos intentos por lanzar una versión de su afamado Delphi que fuera lo suficientemente buena como para recuperar el respeto perdido, parece que con la versión 2006 lo han conseguido.

Un servidor todavía no lo ha probado, pero por lo que he leído por ahí parece que promete, y mucho:

• Delphi 2006 Pro: A Review for Win32 Developers
• Primeras horas con Delphi 2006

Sinceramente, yo andaba ya buscando alternativas para la realización de aplicaciones de escritorio, principalmente mirando el VisualStudio de Microsoft, pero manteniendo la esperanza de que Borland reaccionase y se recuperara de las pifias del Delphi 8 y del 2005. Parece que va a ser así, sólo esperemos que no sea demasiado tarde. Una buena noticia para los que nos gusta este lenguaje.

Me encanta la serie de entradas en el weblog Signal vs. Noise que tienen por título común Getting Real.

Tienen como tema común el ir directamente al grano para producir un software útil, olvidándonos de los temas accesorios. Digamos que es una llamada a solucionar el problema que tenemos entre manos y centrarnos en nuestro producto, olvidándonos de “neuras” sobre marketing, organización, etc.

No están almacenadas en un sólo sitio, por lo que tendréis que navegar los archivos del sitio, pero aquí os dejo algunos enlaces a entradas concretas.

• Getting Real: Release something today – Para motivarte, fíjate alguna funcionalidad que puedas terminar hoy mismo y hazla.
• Getting Real: Make a list of what it won’t do – Haz una lista de funcionalidades que tu producto no tendrá para centrarte en las que sí tendrá.
• Getting Real: It’s a problem when it’s a problem – Céntrate en los problemas que tengas que solucionar ahora. Los problemas futuros ya llegarán y ya los solucionarás entonces. Probablemente ni siquiera puedes predecirlos ahora, por lo que no sirve de nada preocuparse de ellos.

Martin Fowler está escribiendo últimamente sobre el diseño de API’s y cómo las librerías estándard de diferentes lenguajes afrontan la tarea de diseño de sus respectivas API.

Por un lado tenemos el Interface Mínimo. Con este sistema, los diseñadores de las librerías buscan el mínimo grupo de métodos que permite acceder a toda la funcionalidad de las clases y dejan en manos de los clientes de las API (desarrolladores) la composición de estos métodos para obtener funcionalidades más ricas.

Un ejemplo de esto es el interface List de Java, que no dispone de un método para acceder al último elemento de la colección, debiendo llamarse al método genérico get pasándole la posición del último elemento:

Frente a esto tenemos el Interface Humano que aboga por ponerse en la piel del desarrollador y darle ya implementados los métodos que posiblemente utilizará. Por ejemplo el Array de Ruby tiene un método last:

¿Cual es la mejor forma de diseñar un API? Desde un punto de vista del desarrollador parece claro que lo ideal es el Interface Humano. Ya te da el trabajo hecho. Pero creo que al diseñar para el caso frecuente se corre el peligro de que solo se facilite al desarrollador este uso, dificultándole incluso el que el se pueda componer sus propios funcionalidades si se han olvidado de incluir los ladrillos básicos de funcionalidad necesarios.