Riojasoft

Esto se pone interesante.

Como parte del proceso de mejora contínua que seguimos en nuestra empresa se encuentra el lanzamiento (el día 1 de Abril) de Buscador Inmobiliario, una web dedicada a simplificar y facilitar la búsqueda de inmuebles.

La web está ideada, creada y desarrollada pensando en los usuarios. La primera prioridad es simplificar al máximo la búsqueda y ayudarles a seleccionar el/los inmuebles que realmente les interesan. Nuestra experiencia en el desarrollo de software y webs para inmobiliarias nos ha ayudado a conocer lo que los usuarios quieren cuando acceden a una web de búsqueda de inmuebles.

Algunas de las características más interesantes serán:

Sin publicidad ni enlaces patrocinados.

Solo publicamos ofertas de agencias inmobiliarias.

Publicación de inmuebles gratuíta.

Si alguien quiere más información sobre la web puede entrar a buscador inmobiliario y dejar su email (no emplearemos ese email más que para informar sobre las novedades y lanzamiento del portal, tampoco cederemos el email a terceros).

Permiteme contarte una historia sobre la web de una empresa.

Un cierto día una empresa decide crear su propio sitio web para lo que se pone en contacto con un “profesional”. Tras unos meses esta empresa cuelga en Internet su web, que contiene una breve descripción de la empresa y productos, un formulario de contacto y una animación muy espectacular en la portada.

Pasados unos meses, durante los cuales no recibe ninguna información de su web, decide pedir una nueva versión mejorada de su web. Lo que antes era verde ahora será amarillo, la animación cambia para acabar con un fundido en negro y le añaden una nueva sección llamada noticias donde aparece el dibujo de un obrero junto al texto: “en construcción”.

Fin de la historia.

En este segundo artículo sobre las bases sobre las que se asienta Rails voy a hablar de las bases de datos y el papel que juegan en el desarrollo de una aplicación con Rails.

Si no has leído los artículos anteriores puedes ir a la Introducción

El principal creador de Rails (David Heinemeier) considera que toda la lógica debe estar centralizada en la aplicación y no repartida en la base de datos:

No, Mr. Database, you can not have my business logic. Your procedural ambitions will bear no fruit and you'll have to pry that logic from my dead, cold object-oriented hands.

Seguramente más de un administrador de bases de datos estará ahora mismo rechinando sus dientes y gritando: ¡herejía! ¡ Este tipo está loco y no sabe de lo que habla! -volvamos a citar a David:

As long as you're not banking your savings on a hope we'll change our ways once MySQL "grows up" and adds all these Enterprise Features to become something bigger and better than a "toy project". You'll die poor, then, I tell you.

Pero bueno, dejemonos de sensacionalismos y vayamos al grano, a explicar como esta filosofía ha condicionado el desarrollo de Rails, y más concretamente de ActiveRecord.

ActiveRecord

Convención frente a configuración

ActiveRecord, al igual que el resto de Rails, favorece la convención frente a la configuración, es decir, seguir unas normas (convenciones) ya establecidas a la hora de, por ejemplo, llamar a las tablas, campos, ficheros, etc.... Esto nos evita (o minimiza) el tener que crear y mantener ficheros de configuración y parametrización.

Los nombres de las tablas deben ser todos en plural: Coches, Productos, Personas, mientas que los Objetos que las referencian iran en singular Coche, Producto, Persona (Rails es lo suficientemente inteligente como para si creamos un objeto de tipo Coche automáticamente saber que su tabla asociada es Coches, si trabajamos con los nombres de las tablas en inglés, muy recomendable, sera capaz de asociar Person con people, así como muchas otras formas de plural irregulares).

En cuanto al nombre de los campos, rails nos permite total libertad. Por supuesto existen una serie de convenciones que nos facilitarán y simplificarán la tarea de crear los campos de las tablas: si un campo acaba en _at (vendido_at) rails espera (y lo tratará), un campo de fecha-hora mientras que si acaba en _on (visitado_on) espera un campo de fecha.

Si nuestra tabla incluye un campo llamado lock_version rails implementará de manera automática bloqueos optimistas a la hora de gestionar la concurrencia (2 ó más usuarios accediendo al mismo registro).

Si añadimos un campo llamado created_at ó created_on rails se encargará de insertar la fecha/hora de creación cuando demos de alta un nuevo registro. Para control de modificaciones podemos crear un campo llamado updated_at updated_on.

Relaciones entre tablas

Rails implementa las relaciones entre tablas mediante etiquetas :has_one, :has_many, :belongs_to y :has_and_belongs_to_many Este último para relaciones muchos-a-muchos.

Al definir las relaciones entre tablas se crean una serie de metodos de instancia muy útiles en su posterior manejo.

Una ayuda muy útil es la que nos proporciona para mantener un contador automático y evitarnos constantes consultas del tipo "select count(*)" mediante el uso de un campo _count.

Otra de las ventajas de Rails es la herencia. Al trabajar con objetos podemos aprovechar la herencia para crear modelos de datos que comparten una única tabla de la base de datos. Por ejemplo: podemos tener una tabla llamada vehículos y crear nuestros modelos de datos de la siguiente forma:

class vehiculo < ActiveRecord::Base Esto generaría el modelo de datos maestro. Gracias a la herencia ahora podemos hacer:

Turismo < Vehiculo

Furgoneta < Vehiculo

Rails se encarga de diferenciar automáticamente los diferentes tipos de registros (Turismos, Furgonetas) gracias al empleo de un campo type (que habremos de definir en la tabla maestra).

Validación

Una de las opciones más útiles y potentes son los validadores. Mediante esta opción podremos verificar la coherencia e integridad de los datos.

Rails nos proporciona 3 eventos de validación: Validate, Validate_on_create y Validate_on_update donde podremos situar todo el código que deseemos para asegurarnos de la coherencia de los datos recibidos con los esperados (números, fechas, nombres, etc....). Además nos proporciona unos cuantos validadores predefinidos (helpers) que simplificaran las tareas de validación como ejemplo ( validates_length_of ó validates_numericality_of.

Callbacks

Los callbacks son a Rails como los Trigges a las base de datos. Existen una serie de métodos del tipo:

-before_validation

-after_validaton

-before_save

-after_update

-before_create

-after_save

-etc.....

en los que podremos insertar nuestro código. Rails nos permite crear callbacks comunes a varios modelos de datos. Recordemos que Rails es un framework DRY.

Observers

Los observers están pensados para añadir funcionalidad a los modelos de datos sin tener que modificar su código. Los métodos creados como observers se añaden al modelo de datos aunque sin llegar a pertenecer al mismo de manera que el modelo de datos no se ve afectado. También es posible crear observers comunes a varios modelos de datos.

Resumen

Rails nos proporciona toda una serie de herramientas para evitar trasladar código (lógica de negocio que dirian los analistas) a la base de datos mediante el uso de la clase Active Record.

El conocimiento de esta clase y sus capacidades son decisivos para aprovechar las ventajas de Rails y su filosofía de creación de aplicaciones web de forma rápida y efectiva.

Mi experiencia personal me demuestra que el uso de Active Record de forma eficiente simplifica y agiliza el desarrollo de forma notable. Al minimizar el trabajo con la base de datos (escribiendo triggers y procedimientos almacenados) y emplear un único lenguaje para todo el desarrollo, se consigue acortar los tiempos de desarrollo (time2market).

Sin embargo una vez que nuestra aplicación está funcionando conviene analizarla y detectar posibles cuellos de botella y procesos que serían mucho más eficientes ejecutados en forma de trigger o procedimiento almacenado.

He trabajado en bastantes proyectos que gastaban más tiempo en optimizar una aplicación para que soporte 1.000 usuarios concurrentes que en conseguir, antes de nada, esos 1.000 usuarios concurrentes.

Este es el primer capítulo dedicado a intentar "esclarecer" toda la filosofía de desarrollo que hay detrás de la creación de Ruby on Rails y que sin duda han marcado la forma de crear esta útil herramienta.

Ir a la Introducción

Menos es más

Creo que esta es la máxima que subyace bajo todo el desarrollo de RoR. Desde un primer momento se nos enseña que RoR favorece la convención frente a la configuración, es decir: Los nombres de los ficheros, tablas, campos, modelos, etc... todo debe seguir un patrón establecido. Si nombramos todo, tal y como el programa lo espera nos evitaremos una buena cantidad de tiempo en configuraciónes.

Desde la web de 37 Signals (los creadores de RoR) van más allá en esta idea de menos es más e incluso nos hablan de "Menos como una ventaja competitiva".

Los seis puntos principales de su argumento son los siguientes:

1. Menos dinero:
   

   No necesitas dinero para el hardware. El hardware es barato. No necesitas dinero para el software. El software es gratis.

2. Menos gente.
   

   Todo lo que necesitas para desarrollar aplicaciones basadas en web son tres personas: Un programador, un diseñador y alguien con sentido común para los negocios y el marketing.

3. Menos tiempo.
   

   La mayoría del tiempo que pasas trabajando es tiempo perdido. Demasiadas reuniones, demasiada planificación, demasiado pensar..... Cuanto más tiempo tienes, más tiempo pierdes.

4. Menos abstracciónes.
   

   La mejor manera de aprovechar el tiempo es hacer menos trabajo que no sea "real". Menos gráficos, menos documentación, menos especificaciones funcionales. Directo al grano, el producto que tus clientes realmente verán.

5. Menos software.
   

   La clase de software que es satisfactorio de emplear es aquel que es simple, útil y va directo al grano.

6. Mas restricciones.
   

   Intenta resolover cosas simples, necesidades simples. Deja a tus competidores resolver las necesidades complejas y los problemas complejos.

Creo sinceramente que este modelo de desarrollo será el que triunfe. Se acabarón los grandes desarrollos de aplicaciones a 1 ó 2 años vista. Las aplicaciones están cambiando del escritorio a la web y en la web el tiempo lo es todo. Ofrezcamos a los usuarios aplicaciones sencillas y funcionales y obtendremos información úitl que nos permitirá ofrecer a estos usuarios las soluciones y mejoras que realmente necesitan.

Evidentemente no es necesario estar de acuerdo con esta filosofía para emplear RoR como herramienta de desarrollo pero creo que aquellos que compartan este modo de ver el desarrollo de aplicaciones web encontrarán en RoR la herramienta perfecta.

Durante las conversaciones previas al desarrollo de una web solemos hacer mucho hincapié en la necesidad de que las webs de las empresas sean estándares y accesibles. Esto hace que mucha gente nos pregunte si realmente es necesario esto.

Se puede decir más alto pero no más claro

Tu usuario más importante es ciego. La mitad de las visitas a tu sitio vienen de Google, y Google sólo ve lo que un ciego puede ver. Si tu sitio no es accesible, tendrás menos visitas. Fin de la historia.

Steven Pemberton

Esta cita ha sido extraida de una presentación realizada por Jose Manuel Alonso de la oficina española del W3C durante los laboratorios que organiza Caduis.

Además de citar a Steven Pemberton suelo añadir: Las webs estándares y accesibles son más baratas de crear y mantener.

En uno de mis primeros post comentaba que estoy leyendo un libro titulado The Design of Every Day Things. Trata sobre como nos comportamos las personas ante todo tipo de objetos: puertas, lavadoras, coches, videos, teléfonos. Porqué unos teléfonos son sencillos de manejar y otros no hay quien los entienda, porqué hay puertas que sabes perfectamente como abrir y otras que siempre intentas abrirlas por el lado de las bisagras.

Comentan en el libro un curioso efecto que sucede en las personas cuando no sabemos hacer una cosa. Si una persona intenta programar un video y no puede, o intenta pasar una llamada de un teléfono a otro y no sabe o intenta manejar la radio de su automóvil y es incapaz de sintonizar una emisora: la primera reacción es echarnos la culpa a nosotros mismos.

Analizandolo detenidamente es éste un comportamiento humano bastante curioso. Si no sé programar el video es que soy tonto y hay algo que no he entendido. Mentira, mentira y mentira.

Basta ya de autoinculparnos por los errores de otros. Si no sabes programar un video es que el fabricante no ha diseñado un mando lo suficientemente bueno, si no sabes guardar un teléfono en la agenda de tu móvil el problema es que el software del teléfono no está lo suficientemente claro. Todos los objetos deberían estar diseñados y pensados para que su funcionamiento no pudiese conducir a error.

Exijamos pues a los fabricantes que no sólo se preocupen de lanzar productos con la última tecnología sino que además sean sencillos de manejar.

A la hora de crear webs hemos de tener especial cuidado pues con un teléfono o con un video recibimos un manual, pero al visitar una web no hay ayuda ninguna. Solo una adecuada estructura de la información, una terminología correcta e informar al usuario del resultado de todas sus acciones nos ayudará a crear webs fáciles de usar por la gente y por lo tanto capaces de responder a sus espectativas.

Se que no debería alterarme, que no merece la pena hacer mala sangre por la estulticia de quienes no tienen ni idea de hacer webs, pero no puedo evitarlo.

Tengo una debilidad, la música. Sin música no se trabajar ni conducir (ni salir por las noches). Debido a esto suelo visitar las páginas web de casi todos los grupos que me gustan. Y ME CABREO MUCHO CUANDO ESTÁN HECHAS EN FLASH. Y si encima no tienen versión html pues es cuando ya llego a los insultos.

En el ordenador de mi trabajo tengo instalado Linux. Me encanta, tengo todas las herramientas que necesito, nunca tengo virus, ni programas espía, nunca se cuelga y no hay que andar reinstalandolo. Desventajas: no hay iTunes para Linux (hasta que descubrí Amarok) y reconozcamoslo si no tienes mucha paciencia no intentes crear un DVD en Linux. Si he dicho crear, no grabar, me refiero a coger tus fotos y tus videos caseros y crear un DVD. Eso en un Mac son 20 minutos en Linux… no quiero ni pensarlo.

Bueno, que se me va la cabeza, en Linux, el plug-in de Macromedia para Flash deja bastante que desear y según con que versión hayan creado el Flash no se verá bien. Es decir que gracias a la chapuza de crear una web 100% en Flash acaban de impedir que algunos seguidores de esa banda podamos disfrutar de su página. Si voy a casa de mi madre (que tiene windows y 389 programas spyware instalados) a usar su ordenador compruebo como (juro que no he tenido nada que ver) el plug-in de Flash no funciona en su pc. Aunque descarges el plug-in una y otra vez te dice que todo ha ido ok. Entras a una web con flash y nada de nada. Conclusión solo puedo ver webs con Flash cuando cojo el portatil lo reinicio en windows (aquí tengo los dos sistemas instalados) y entonces gracias a dios ya puedo entrar en las web que tienen Flash.

Todo esto gracias a alguien que sin tener ni idea de hacer webs pensó que para que complicarse la vida haciendo un trabajo profesional. Lo hacemos todo el Flash que es muy cómodo y no hay que saber ni html, ni css ni tonterias de esas.

Si las personas que tiene la responsabilidad de desarrollar la web de un grupo de música (o cualquier tipo de web) fuesen gente profesional y que conocen el medio en el que trabajan, harían cosas como la web de Rammstein. (Si tu resolución de pantalla es 1024 ó más prueba a encoger el navegador y fijate en el menú izquierdo).

Eso es una web hecha con cabeza, de diseño agradable, se ve bien en todo tipo de navegadores, sistemas operativos e incluso resoluciones y sin usar tanto Flash y tanta po..a. Y si hay un artículo o noticia que me gusta y le doy al botón de imprimir del navegador, joder, se imprime…y no con el Flash.

¿Y si quieres publicar videos o contenido multimedia?... Pues entonces si, ha llegado la hora de emplear Flash, que para eso fue creado, para reproducir contenido multimedia. Ahora bien, una cosa es que no puedas ver un video por no tener un plug-in y otra cosa es que no puedas ver nada.

En fin que la conclusión es que la tecnología no es ni buena ni mala. Lo malo es tener que aguantar que gente no profesional y sin los debidos conocimientos sean los encargdos de crear webs.

Mi trabajo consiste en crear webs para todo tipo de empresas. Para algunas de ellas es este su primer contacto con Internet, pero la gran mayoría ya dispone de web.

Cuando trato con el responsable de la web de una empresa una de mis primeras preguntas es: “¿Es rentable su web actual?”

La gran mayoría me responde que “ellos no venden nada por Internet”.

La respuesta es obvia: “Seguramente su departamento contable tampoco se encarga de la venta de los productos o servicios de su empresa y no por ello dejamos de controlar su rentabilidad”.

Las empresas deberían tratar a su web igual que a cualquier otro departamento, bajo el prisma de la rentabilidad. Si existe una manera de definir a una web que verdaderamente me irrita es: web presencial. No existen las webs presenciales, este término es totalmente incorrecto cuando hablamos de una web de una empresa. Ninguna empresa está en Internet solo por el gusto de estar. Todas las empresas buscan un objetivo para su web. Algunas se conforman con mostrar sus productos, otras facilitan el acceso a información adicional, otras venden productos y/o servicios e incluso cada día hay más empresas que desarrollan toda su actividad comercial mediante su web.

Los objetivos pueden (y deben) ser medibles y cuantificables. No parece lógico marcarse objetivos que luego no podemos saber si se van a cumplir o no.

La misión de quienes creamos webs empresariales debe ser ayudar a las empresas a definir objetivos claros acerca de la estrategia de su web. Una vez definidos estos objetivos deberemos proporcionarles la manera de comprobar, medir y valorar si se están cumpliendo. Es en este momento cuando estamos dotando a las empresas de la información necesaria para comprobar que su web es realmente rentable.