Es este uno de los casos en que cuesta mucho más decir lo que quieres hacer que hacerlo.
Necesito seleccionar un fichero de forma aletaroria de entre todos los que se encuentran en un directorio y por suerte para mi, uso Ruby.
Esta es la solución, simple y efectiva.
all_files = Dir.entries('/images') - ['.', '..']
return all_files[rand(all_files.size)]
No creo que se pueda decir más con menos.
Acabamos de lanzar al mercado nuestra nueva web, desarrollada 100% empleando rubyonrails .
El nombre de la web es buscador inmobiliario y como se puede deducir por su nombre es una web orientada a facilitar la búsqueda de inmuebles (vivendas, locales, naves y parcelas).
El tiempo total de codificación de la aplicación ha sido de un mes y creo que podríamos haberlo reducido ya que algunas partes del desarrollo las hemos cambiado por otras más optimas según nuestro conocimiento de rails ha ido creciendo conforme avanzaba el desarrollo.
En general estamos bastante satisfechos con el resultado y creemos que hemos acertado con el uso de rails. Conforme el número de visitantes crezca y se consolide veremos que tal rendimiento obtenemos.
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.
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, 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.
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).
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.
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.
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.
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.
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.
