Riojasoft

Una web que ofrece trabajos para diseñadores y programadores. Hay empleos a tiempo completo y en plan freelance.

Una gran extensión para Firefox, que una vez instalas ya no puedes vivir sin ella, está a punto de llegar a su versión 1.0. Descarga Firebug ya!.

Una idea útil: un conversor de mensajes de voz a texto. LLamas a un número y dejas un mensaje para uno o varios destinatarios. El sistema convierte tu mensaje a texto y envía un mensaje a los destinatarios (que si lo desean pueden elegir entre oír el mensaje o recibir el texto).

Nuevas utilidades para Google Earth. Ahora se integra con la Wikipedia y con Panoramio (una empresa española, por cierto) para presentar una mayor información sobre las zonas que visitas.
También, de la mano de Google nos llega una nueva característica de GMail: Poder leer cuentas de correo de otros operadores. Todas tus cuentas integradas en un único lector de correo.

En Ojobuscador publican unas gráficas del uso de buscadores en Europa. Domino aplastante de Google, Por un lado es un dato preocupante ya que todos sabemos lo malo que es el monopolio pero por otro lado si Google es quien mejor productos y servicios ofrece es lógico que sea el que más usuarios tiene.

¿Trabajas con Rails? Cuentaselo al mundo. También puedes mostrar tus aplicaciones hechas con Rails
Y para los que quieran descubrir o perfeccionar la forma de programar en Ruby no deben perdense The Rails Way (aunque debería llamarse The Ruby Way). Programar puede ser divertido y elegante!!.

Guerra de titanes: Publicidad en el sector de automóvil

Me voy a Fundamentos Web a Oviedo.

Promenten ser dos días interesantes. A priori el nivel de los ponentes hace presagiar buenas conferencias.

Veremos a ver que sale.

Dios los cria, ellos se juntan y cuentan cosas interesantes sobre diseño, programación y negocios enfocados a la cosa esa de la web.

Thinkvitamin

Cuando se abusa de un término acaba por darsele significados que en nada tiene que ver con el original.

Esto es exactamente lo que está pasando con web 2.0.

¿Que es el término web 2.0?

La wikipedia dice textualemnte:

Web 2.0 se refiere a la transición percibida en Internet desde las webs tradicionales a aplicaciones web destinadas a usuarios. Los propulsores de este pensamiento esperan que los servicios de la Web 2.0 sustituyan a las aplicaciones de escritorio en muchos usos.

En la definición se mencionan los dos conceptos principales: usuarios y aplicaciones.

Cualquiera que piense que la mejor manera de desarrollar aplicaciones hoy en día es a través de la web está desarrollando en la llamada web 2.0.

El resto de adjetivos que se han venido añadiendo al término (ajax, ruby on rails, web semántica, etc…) no son sino un medio para alcanzar el objetivo, que no es otro que crear aplicaciones útiles y sencillas de emplear.

Al final quienes deciden si una aplicación web es o no 2.0 son los usuarios. Si es sencilla de usar y constituye una mejora frente a los programas tradicionales es web 2.0.

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).

Recientemente hemos ampliado nuestra cuenta con Basecamp.

Basecamp es una herramienta de gestión de proyectos sencilla, fácil de usar y que realmente te permite gestionar los proyectos o tareas sin necesidad de tener que aprender engorrosos manuales.

Desde que la descubrimos se ha convertido en la herramienta preferida de Informática 32 para gestionar todos nuestros proyectos. Tanto es así que hemos tenido que ampliar nuestra cuenta para poder acceder a gestionar más proyectos.

Creo que Basecamp aparte de una buena herramienta es una buena muestra de hacia donde va el desarrollo de software: sencillo de emplear, útil, via web, estándar y económico.

Está desarrollada por 37 Signals.

Entre las novedades que tienen previstas para este año 2006 está el lanzamiento de una herramienta de CRM. Si es igual de sencilla y facil de emplear les auguro un éxito seguro.

Diariamente tenemos que visitar webs diseñadas, estructuradas y programadas de una manera pésima. Es muy normal, en pleno año 2006 encontrarse webs que no son más que una mera conversión del catálogo de productos de una compañia en html.

Otras muchas, las peores, están desarrolladas integramente empleando Flash llenas de efectos, menús que desaparecen, transiciones y vacías de utilidad. Prohiben fumar en los bares y no prohiben hacer webs en flash que eso si que daña nuestra salud y la de los que nos rodean.

Por eso encuentro TreeHouse interesante por 3 motivos:

1.- Recopila información e ideas útiles para aquellos que se dedican a desarrollar webs.

2.- Hace ver como un buen diseño no solo nó está reñido con la funcionalidad sino que un buen diseño de una web aporta y mejora la funcionalidad de la web.

3.- Demuestra como aquellos que no hacen sus webs empleando tecnologías como xhtml+css y siguen empleando flash, no es más que por ignorancia, falta de formación y desconocimiento del medio en que se mueven: Internet.

Aunque la mayoría de sus contenidos los podemos encontrar on-line visitando otras muchas webs, aquí los tenemos todos a nuestra disposición agrupados, lo que nos ahorra mucho tiempo y con una presentación exquisita.

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.

Hace aproximadamente un mes terminé de leer el libro "Agile web development with rails". Desde entonces lejos de arrinconar el libro en algún rincón de mi estantería, he pasado muchas horas probando Rails y empleando el libro como guía y como referencia.

Desde el principio de comenzar con la lectura del libro, me enganchó. Puede parecer raro emplear ese término, más propio de novelas policíacas que de libros de informática, pero es así.

La curiosidad me ha llevado a profundizar y conocer más a los autores y a visitar sus webs. Leyendo diferentes artículos en 37 Signals, Basecamp, Loud Thinking y en el propio blog de Rails he podido comprobar que detrás de una útil y eficaz herramienta de desarrollo, hay toda una filosofía de entender la creación de programas.

En próximos post iré desgranando toda la filosofía que se esconde detrás del desarrolo de rails y que, desde luego, han sido la base para la creación de Rails del modo en que lo conocemos.

• Parte I - Menos es más
• Parte II - Bases de datos