Apple's iPhone Programming

With some delay, I'd like to rant about Apple's iPhone Programming Environment. As you may know, two weeks ago Steve Jobs made one of his worst presentations ever. He gave little new information to the world. But one of the pearls he throw out was the new programming environment for the iPhone. This one and a port of Safari for Windows (full of bugs, by the way).In fact call it programming environment is a bit pretentious.

Apple, following their tendency of "wallet gardens", has created a mobile phone without programming capabilities. When Steve Jobs first presented iPhone, there were no programming functionality planned. No native programming, no java. But everything changed two weeks ago. They have created a programming environment for the iPhone. It is a solution based on Safari, the web browser, and AJAX as a platform. Impressive.

The first think that comes into my mind when I think in such environment is security. AJAX is not the quintessence of security. The combination web + AJAX is dangerous. They are based on a connected environment and if you allow a web site to access phone capabilities such as contacts, personal information, etc... the risk of appearance of malicious software increases exponentially.

In order to add capabilities to access phone's functionality through Javascript, they must extend ECMA Script with propietary functionality. Do you find the irony in this point? You use an standard tecnology (web+javascript in this case) in order to attract a big development base, but you add your own extensions to that technology making the software created for iPhone not standard.

I hope, for their own good, that the iPhone will limit that capabilities to remote applications, but on the other hand, all the benefits of an application accessed remotely (distribution cost, ease of access, less error prone) are missed. It's difficult to set up an environment with an adequate balance between security and functionality. At least when we are considering a web based environment.

New Course

My blog has been very quiet during the last weeks. No, I haven't quit my blog but from now on updates will be less common. The reason why is I have changed my job. I've left my old company, Vodafone, where I was working for 4 years and a half and I've started a new adventure.

My new company's name is TB Solutions Sevenclick. Well, Sevenclick is the actual name and TB Solutions is the mother company's name. I have assumed the role of CTO (Chief Technical Officer) which is a great opportunity for my career.

Sevenclick is a mobile focused start-up. We don't depend on a single product or idea. Our focus is customers. Currently we are just 3 people (we'll be six in one month time) with great excitement and willing to succeed.

As soon as I have more time (we are currently configuring servers, network, workstations and so on and so forth) I'll update my blog. Probably the main theme will change, as long as I'm going to be involved in lot of different subjects, but I will get back to Rails once in a while.

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/

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

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.

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.