Thursday 31 May 2007

Surface Computing

Microsoft have just presented a new product (technology?) named Surface Computing. I have to say that this is awesome. The possibilities are enormous. This video shows up several applications developed by Microsoft along with partners like T-Mobile, Sheraton and Caesar's Palace to demostrate several concepts able to be implemented with Microsoft Suface Computer.


Microsoft mentions hotels, casinos, etc.. as the target consumers for this technology. Anyway, I we just think about the possibilites, we can find easily tons of applications. The first thing that comes to my mind is a bunch of people working together in a software project. An analysis or design meeting with several people contributing to define an architecture. Ease of use, collaborative, impact, impressive.

Please, take a look at the videos. You won't regret.

Thanks to Larry Larsen's blog for the information. http://on10.net/Blogs/larry/first-look-microsoft-surfacing-computing/

Tuesday 29 May 2007

New Language

Hi all

After one month and a half, I have decided to switch the blog's language from Spanish to English. There are several reasons, but the main one is the Ruby on Rails community. Most Ruby on Rails blogs are written in English and all the documentation is generated also in Shakespeare's language.

Last friday, one of my posts was replied in english. That was awesome because the reader didn't know a word in spanish but he managed to translate the post and reply giving me very useful information (thanks Jeremy).

So, welcome English, Bye Spanish.

ActiveRecord - Multiples Bases de datos

Durante un seminario acerca de Rails, alguien me pregunto sobre la posibilidad de acceder a una fuente de datos que fuera la configurada por defecto en el entorno en el que nos encontremos, a saber, desarrollo, test y producción. Tengo que confesar que la pregunta me cogió un poco por sorpresa, pero pensando en ello, y con la confianza que te dan las buenas ideas que se desprenden de todo lo que rodea a Rails, supusimos entre todos que si que se podría. Efectivamente, asi es. De hecho, es realmente sencillo.

Tendremos que llamar al método establish_connection del modelo que apunte a la BD externa con una sintaxis como esta.

Class_name.establish_connection(
:adapter => "mysql",
:host => "host_name",
:username => "username",
:password => "password",
:database => "db_name"
)

De este modo, tanto esta clase, como el resto de subclases harán uso de la nueva conexión. El resto de clases del modelo seguirán usando la BD configurada por defecto en el archivo database.yml

Friday 25 May 2007

Documentación de Rails

Este va a ser el primer post en el que critique un aspecto de Rails: su documentación. Y es que si bien el Framework en si mismo es genial, la documentación no llega al mismo nivel de excelencia. Siempre bajo mi punto de vista, claro esta.

Y es que yo, que he sido los últimos años un enamorado de Java, soy de esas personas raras dentro del desarrollo de software que valoran mucho la documentación, tanto de los productos finales, como de las APIs.

Si yo me enfrento a documentación en JAVA DOC, se exactamente que tipo de parámetros necesita un método para funcionar, las excepciones que lanza, el tipo de retorno, etc... en cambio en Rails no es asi.

Algunos de los métodos (ActiveRecord::Base.find() por ejemplo) si que están correctamente documentados, con ejemplos, etc... De echo, muchas de las clases tienen información buenísima al comienzo del documento sobre como utilizarlas. Lamentablemente esto no pasa en todas ellas. El módulo de vistas tiene algunos métodos con explicaciones de este estilo.

check_box_tag(name, value = "1", checked = false, options = {})

Creates a check box.

Esto no ayuda mucho. Personalmente me cuesta averiguar que puedo meter en options.... en este sentido, creo que es necesario progresar en la redación de la ayuda de ciertos métodos.

Bueno, no voy a seguir más, ya que no quiero criticar demasiado a Rails.

Tuesday 22 May 2007

Active Record = Join Tables

En uno de los primeros POSTs de este blog, hablaba de las relaciones entre tablas a través de los modelos de ActiveRecord e intentaba (conseguía?)explicar un modo para entender como definir correctamente estas relaciones. Me gustaría ampliar un poco esto para analizar una de las relaciones que creo que no he tratado correctamente, las relaciones N a N a través de Join tables.

Estas relaciones se dan cuando tenemos dos tablas relacionadas entre si a través de una tercera tabla. En esta tabla, se suele sustituir la clave primaria por la unión de los índices de las dos tablas relacionadas, si bien esto no es obligatorio.

Rails permite definir estas relaciones de una manera muy sencilla usando en ambos modelos la relación has_and_belongs_to_many :tabla (vaya nombrecito). Usando esta sencilla fórmula, seremos capaces de acceder desde un objeto de uno de los modelos a la lista de elementos del otro modelo de una forma muy sencilla. Por ejemplo, si relacionamos Authors y Articles a través de la Join Table Publication, podremos hacer algo así.

autor = Author.find(:first)
lista_articulos = autor.articles

En lista_articulos tendremos un array de objetos Article que se han asociado a Author a través de la tabla Publication. Tendremos que seguir ciertas convenciones que rails nos indica como que el nombre físico de la join table este compuesto por los nombres de las tablas enlazadas en minúscula y en orden alfabético. Si queréis ver la especificación, visitad el API. Facil no???

Pero hay un problema. Imaginemos que esta tabla Publication tiene campos adicionales que no son los índices de las tablas referenciadas. Rails no nos pone ninguna pega para acceder a esta información. De hecho, la incluye en el array que hemos obtenido anteriormente. El problema es que estos campos son de solo lectura. No se pueden modificar. La aproximación que se tomaba era la utilización de delete para borrar una entrada antigua y del método push_with_attributes(object, attributes) para introducir una tupla nueva en la join table. PERO ESTE METODO ESTA DEPRECATED. NO LO USEIS.

Afortunadamente, este problema ya esta resuelto. El truco (no es un truco, pero vaya) es usar una doble relación has_many en ambas tablas a relacionar usando el modificador :through. Ah, y creando un nuevo modelo que nos identifique la join table. Esto es muchísimo mejor, ya que recuperamos toda la funcionalidad que nos proporciona el tener una tabla identificada por un modelo. También eliminamos la necesidad de llamar a la tabla con nombres raros (autor_articulo en el caso anterior)

Bueno, como definiríamos esto en la relación anterior???? Marchando.

class Author << ActiveRecord::Base
has_many :publications
has_many :articles, :through => :publications
end

class Publication << ActiveRecord::Base
belongs_to :author
belongs_to :article
end

class Article<< ActiveRecord::Base
has_many :authors
has_many :authors, :through => :publications
end

Que os parece??? tenemos ahora acceso a tooooodos los métodos de inserción, etc... De la tabla Publication y podemos trabajar de un modo mucho más sencillo.

Thursday 17 May 2007

NetBeans 6 Preview Milestone 9

Como anunciaron en la JavaONE, ya tenemos disponible el Milestone 9 de NetBeans 6 con soporte Ruby, JRuby y Ruby on Rails. url.

En varios videos que han publicado en NetBeans.tv, he visto una integración de Rails muy avanzada. Llevaba tiempo esperando una versión estable para poder probarla y detallar como avanza esta nueva alternativa dentro de los IDEs para el desarrollo Rails.

En estos momentos estoy terminando de descargar el software (pesa unos 166 megas). En cuanto lo instale y lo pruebe, pondré un post comentando mis impresiones. De todas formas, si se confirma lo que mostraban estos videos, es un rival muy fuerte para Aptana. Muy, muy fuerte.

El link al software. http://bits.netbeans.org/download/6.0/milestones/latest/

Wednesday 16 May 2007

Ruby on Rails VS JEE

Os acordais de los anuncios Mac VS PC de los tios gordo y bajito??? Pues aqui tenemos una versión del mismo enfrentando a RoR y JEE. Me ha echo muchísima gracia. Supongo que por el tiempo que me he pegado peleandome con JEE (Antes J2EE), sus config.xml, sus ear de 5 megas, etc... Espero que os guste tanto como a mi.

Wednesday 9 May 2007

Active Record find

Actualmente me encuentro desarrollando una aplicación WEB que dispone de un API REST y una parte estándard. A la hora de desarrollar las consultas a los modelos, me he encontrado con que algunas de estas son muy complejas y tiendo a pensarlas en SQL directamente, ya que es un lenguaje que da un gran rendimiento y flexibilidad.

ActiveRecord::Base nos proporciona dos métodos para realizar estas consultas, find y find_by_sql. En el caso del segundo la opción está clara: insertar directamente el SQL que he pensado para obtener solo lo que yo quiero obtener y con el formato que yo necesito. En el caso del primero, solo con echar un vistazo al API podemos ver que tiene un gran número de posibilidades, parámetros, etc.. que lo convierten en una opción muy poderosa para realizar las consultas. Asi pues, me surge una duda ¿Cual de ellas usar?

Esta pregunta, que en principio parece muy sencilla, no lo es tanto. Si controlas SQL tenderás a hacer uso de find_by_sql ya que te abstraeras de aprender las opciones y posibilidades de ActiveRecord y trabajarás con algo conocido. Pero precisamente esto es algo que no deberíamos hacer. Bajo mi punto de vista, tendríamos que usar las ventajas que nos da Rails evitando usar SQL directamente.

Diseñamos la BD, definimos los modelos de las tablas, declaramos las relaciones entre ellos. CONTROLAMOS la estructura de nuestros datos. Imaginemos que tenemos una tabla Articles y otra tabla Tags. Definimos una relación n-to-n con sendas directivas :has_and_belongs_to. Bien, pues en el caso en que queramos obtener todas las tags de un artículo, podemos bien escribir un SQL que obtenga la información de las distintas tablas o podemos dejar hacer a ActiveRecord, ya que por el hecho de tener esta relación, es capaz de proporcionarnos esta información automáticamente con el siguiente código.

article = Article.find(article_id)
article.tags.each do |tag|
puts tag.tag_name
end

Mantenemos el código sencillo. Usamos los convencionalimos de Rails. Resulta extremadamente sencillo de interpretar. EVITAMOS MEZCLAR LENGUAJES.

Tuesday 8 May 2007

Aptana (I) : Debug

Hace unas semanas, comentaba en una entrada del blog que me había decidido finalmente por el plugin Ruby in Steel para visual Studio. Bueno, pues desde hace muy poco tiempo, exactamente desde el 1/5/2007, tenemos disponible la primera versión de Aptana que integra RadRails. Si y no. De "serie" no incluye esta funcionalidad, pero es muy sencillo descargarnosla siguiendo los pasos que se indican en la página de descargas.

Las versiones night-build de este entorno que incluían RadRails era demasiado inestables para ser usadas para desarrollo, sobre todo la parte de Debug. Pero todo esto ha cambiado. Y de que manera!!! Me voy a atrever a afirmar que el debug de aplicaciones de Rails está casi conseguido al 100% en la versión actual de Aptana. Voy a enumerar las que, a mi modo de ver, son las principales funcionalidades de que disponemos para debug.

  • Botón Script/Console. Nos lanza una consola o símbolo de sistema dandonos acceso a todos los componentes de la aplicación. Imprescindible para debugear cuando estamos creando los Modelos. Podemos comprobar las relaciones que hemos establecido, el resultado de las consultas, como se producen las excepciones al intentar eliminar cuando tenemos recursos protegidos, etc... Todo aquel que se inicie en Rails tiene que pasar un tiempo con la consola para adaptarse al lenguaje y al API. Aptana nos permite realizarlo dentro del propio IDE, sin tener que tener varias consolas de sistema abiertas y lo que es más importante, pudiendo introducir pequeños scripts y ejecutarlos de vez sin tener que soportar el tedio de la consola de sistema.
  • Botón Debug. Le indicamos que nos lance un Debug de Ruby para nuestra aplicación. De este modo, nos abre la perspectiva de Debug permitiendonos poner puntos de ruptura, hacer una ejecución paso a paso, etc... Para poder hacer debug necesitamos tener instalado el gem ruby-debug. La siguiente imagen nos muestra la página de propiedades tal y como tiene que estar configurada.
Vemos que nos indica que tenemos que tener instalada la gem ruby-debug-ide. Con Ruby-gems podemos instalarla ejecutando gem install ruby-debug-ide

Esta es una captura de la perspectiva de Debug en Aptana con puntos de interrupción activados.

Espero con impaciencia que permitan poner puntos de interrupción, en definitiva debugear, no solo en el modelo y los controladores, sino también en las vistas. Hasta este momento, los archivos .rhtml no permiten activar los puntos de interrupción para ver paso a paso como se van generando. No obstante, la velocidad de carga del servidor interno es muy buena, la respuesta del entorno en debug inmejorable y la sensación general es que esto esta avanzando a pasos agigantados.

Voy a ir diseccionando poco a poco que añade esta versión de Aptana al desarrollo Rails. Espero que en cosa de unos meses, dispongamos de un IDE tan avanzado que el no usarlo sea casi pecado!!!!!!!!

Thursday 3 May 2007

Fiddler

Hoy quiero alejarme un poco de Rails, aunque no mucho y más adelante vereis por qué, para hablar acerca de una utilidad genial que he descubierto esta misma semana. Fiddler.

Lo primero de todo, que es Fiddler? Pues Fiddler es un Proxy HTTP para Debug. Es decir, un Sniffer especializado en HTTP pensado para que la tarea de rastrear una conexión HTTP no sea un quebradero de cabeza. Si habeis utilizado Ethereal estareis de acuerdo conmigo en que, a pesar de ser una gran utilidad con muchas opciones y muy util, a la hora de acceder al contenido de los paquetes y de rastrear una conexión en periodo de Debug, esta herramienta muere de exito. Nos perdemos en las opciones y no es sencilla.

Fiddler incorpora un generador de peticiones HTTP genial que nos permite configurar la URL, el verbo HTTP a usar (GET, POST, PUT, DELETE...) los parámetros, cabeceras, etc... y también permite por medio de un pequeño plugin el renderizar correctamente contenido xml para su visualización. Lo cual es genial cuando estamos desarrollando un API REST ya que vamos a poder lanzar tests funcionales muy facilmente, rastreando los resultados inmediatamente y todo con la misma herramienta. Aqui incluyo unas cuantas capturas de las pantallas de Fiddler.


Request Builder


Session Inspector

Si usais Internet Explorer, comprobareis que todas las peticiones que lanceis automáticamente son capturadas por Fiddler. Bien, yo uso Firefox y aunque en principio esta funcionalidad no está configurada, es tan sencillo como seguir los pasos que se indican en esta pagina para configurar la dirección de configuración del proxy. Es muy sencillo y muy intutitivo.

Ah, se me olvidaba, la dirección de la página principal de Fiddler. http://www.fiddlertool.com/