Este año he podido disfrutar asistiendo ambos días, además he disfrutado como más me hubiese gustado hacerlo siempre. Dado que desde hace un tiempo he estado trabajando más intensamente con Rails, y este ha sido el primer evento relacionado con el tema al que he podido asistir, eso si no contamos el evento de Tog en octubre .

Como es habitual, aporto mi pequeña gota de feedback y como también es normal, no lo haré de todas las charlas, sino de aquellas que más me impactaron o que por una causa u otra más recuerdos han dejado en mi. Para los que se queden con ganas de más, les recuerdo que la organización grabó las charlas y que seguramente pronto estarán disponibles los vídeos como en otras ocasiones.

Apertura y keynote por fxn. Una manera de abrir la conferencia singular, con referencias a hechos que originaron cambios. Personas que fueron contra corriente, con formas de pensar y/o hacer diferentes… Somos reacios al cambio, somos animales de costumbres y nos cuesta aceptar algo nuevo, pero cuando el cambio es llevado a cabo, cuando nos dejamos embaucar por lo extraño, sin duda disfrutamos como niños. Rails sin dudarlo es una pequeña cosa que ha hecho una gran diferencia. Frameworks hay muchos, intentos de hacerlo de otra forma también, pero corrientes como la que vivimos no han habido tantas. Lo que más me maravilla de esta comunidad es que muchos hemos llegado a ella con experiencia sobre otras, con lecciones aprendidas a fuego y veo cosas que me gustan bastante.

Caso de éxito: “Tog: Open Web, Social Networks y cintas de video”. Una explicación de la visión sobre los objetos sociales y sobre lo que una red social debería crearse. Intentando mostrar el aporte que Tog podría hacer con respecto a crear una red social. No sé si fue la charla, si oir a Aitor en estado catarroso o si definitivamente Tog tiene el tirón que parece. El caso es que el último día las votaciones de mejor proyecto del año 2008 recayó sobre él XD, y eso que fue liberado a ¡finales de septiembre! La verdad es que el trabajo detrás de esta primera inflexión que supuso la liberación del código se remonta a bastantes meses atrás. Antes hubo pruebas, proyectos, afinamiento de ideas y tras todo eso la creación de lo que ahora mismo es. Todo ello entorno a la idea que nos mueve de los objetos sociales y su valor.

Rails HOT or NOT. Os recomiendo verla en video . No había utilizado todos los plugins que se comentaron, en ocasiones no podía decir nada malo por uno de ellos, pero sin duda descubrí opciones, opiniones en base a experiencias y espero pronto leer las conclusiones en la lista de ror-es; además de invertir algo de tiempo en cacharrear con alguno de ellos.

Speed dating. Un experimento que pudo hacer que nos relacionásemos gente con proyectos en busca de gente y gente en busca de proyectos, aunque tubo un mayor aporte de empresas que buscaban personal para contratar que lo yo personalmente hubiese querido encontrar. Aún así, una grata experiencia.

Caso de éxito: “b5map: Maps on Rails”. La verdad es que ya conocía la web desde hacía tiempo, conozco Aitor por sus post en jaiku, pero desconocía las tiranteces que parece haber entre los ayuntamientos. Algo que me llamó mucho la atención, fue descubrir que el proyecto se había llevado a cabo aunando a freelances y pequeñas empresas, algo loable viniendo de una administración pública.

Keynote por Obie. Una forma de ver el mundo laboral y empresarial diferente a lo que se ve en este país. Sin duda oír hablar a Obie diciendo que son buenos desarrollando, que les gusta y que eso es a lo que se dedican y es lo que le transmiten a sus clientes; lo cual despertó algún comentario en los asistentes, dada la comparación con lo que vivimos aquí en España. Aplicación de Pair Programming todo el tiempo, un ambiente laboral agradable, invitaciones a personas destacadas dentro del mundo de la programación para que interaccionen con la gente que trabaja en Hashrocket, etc etc. Fue agradable de escuchar y creo que sería increíble trabajar en esos ambientes (al lado de la playa ) y de con esas premisas. Aunque sin duda mi conclusión actual es que no estamos tan lejos de conseguirlo, y que la nueva cultura de empresas pequeñas haciendo software creada entorno a Rails, podría llevarnos a eso.

Por comentar, me queda por ver a fondo la charla de Emili Parreño sobre ActiveRecord, echarle un vistazo a Typus, probar EC2 de Amazon, hacerse con uno de los aparatos que vimos en: Hardware Hacking en Ruby y casi en Rails para iluminar los deploys y definitivamente: hacer TAFT .

Pues bien, he de anunciar que el Internship se ha dado por clausurado y el resultado no ha sido nada alentador.

La verdad es que se juntaron varias cosas, como ya apuntan en el blog de Linking. Una vez más se ha evidenciado la importancia de la dedicación total, es difícil que un proyecto propio o sideproject se convierta en una realidad cuando el tiempo empleado para ello es muy limitado.

Creo sinceramente que el momento en el tiempo no fue el mejor (verano); que se junto con el comienzo de nuestra nueva actividad; que quizás es bastante cierto que faltó algo de presión por tener un entregable; que nuestra dedicación no era completa y se juntó con otras actividades que colapsaron nuestro día a día; y quizás otros factores que no soy capaz de ver en este momento. Todo esto suena a excusas explicatorias, pero nada más lejos; lo importante es el análisis de lo ocurrido y sacar conclusiones, para aprender de la experiencia.

Para mi es un trago amargo pensar en el resultado, no se puede decir que de la experiencia no haya sacado nada, pues no estaría diciendo la verdad. Sin embargo he querido concluir totalmente con ello y en principio dado que no podía comprometerme una vez más y mentirme a mi mismo y a mis compañeros sobre el tiempo real que podría dedicar, he decicido no continuar activamente con el proyecto. No descarto volver a hacer más cosas en el proyecto, pero a día de hoy no tengo la certeza suficiente de cuánto puedo dedicarme a él.

La idea quizás tiene bastantes alicientes aunque a mi me gustaría destacar un par de ellos:

- Una página de referencia independiente del lenguaje, del sistema, de la plataforma… da igual si eres programador o administrador o como ellos mismos dicen informático en general, todos tienen cabida en el mismo espacio.

- Un lugar donde escribir artículos puede darte beneficios, pues debug_mode=ON ha optado por que los obtengas, basta con que añadas tu código de Google Adsense y listo.

El hecho de que me haya retrasado con el post, ha tenido un efecto curioso, porque he podido intercambiar impresiones con alguno de los miembros del proyecto, en concreto con Alberto Gimeno. La verdad es que la idea ha tenido repercusión en algunos medios, tales como: barrapunto, javaHispano y algún otro, lo cual ha hecho más emocionante el arranque inicial.

La tecnología utilizada, para los que aún no lo hayáis adivinado es Google App Engine, lo cual ha sido enriquecedor a un punto y ha traido algún quebradero de cabeza que otro, dado que han tenido que superar bastantes problemas de over quota en los momentos iniciales, aunque lo superaron. Como curiosidad, coincidiendo con el Google Developer Day, que se celebró en Madrid el pasado día 25 de septiembre (al que en el último momento no puede asistir) tuvieron la oportunidad de charlar con los ingenieros de Google sobre la herramienta de Google y sobre la página, además de poder enseñársela a algunas personas que asistieron al evento.

Desde aquí desearles mucha suerte y fuerzas para tirar de la idea.

Ahora os voy a mostrar cómo se podría construir la nube de tags partiendo de lo que hicimos.

Lo primero, es que nuestra aplicación necesita utilizar un método llamado tag_cloud, que es el que se va a encargar de pintar la nube de tags, para ello hacemos que nuestro AplicationHelper incluya el helper que contiene el método:

module ApplicationHelper
  include TagsHelper
end

Nos basta con añadir esto al helper del controlador concreto, pero dada la implementación del plugin creo que querréis crear más nubes de tags para otros modelos, por lo que he preferido tener disponible estos métodos para toda la aplicación.

Ahora Necesitamos cargar en nuestro controlador lo que va a ser mostrado en la vista:

@tags = Entry.tag_counts

Y por último nos vamos a la vista y añadimos la nube de tags:

<% tag_cloud @tags, %w(css1 css2 css3 css4 css5) do |tag, css_class| %>
    <%= link_to tag.name, { :action => :tag, :id => tag.name }, :class => css_class %>
  <% end %>

para que esta pueda tener el efecto adecuado, necestitáis definir los siguiente estilos en la vista:

.css1 { font-size: 1.0em; }
.css2 { font-size: 1.4em; }
.css3 { font-size: 1.6em; }
.css4 { font-size: 1.8em; }
.css5 { font-size: 2em; }

estos deberíais adaptarlos en tamaño según vuestro diseño, ¿sencillo verdad?

La historia de este plugin, es que David Heinemeier Hansson creó un plugin para poder poner tags a sus modelos, llamado: acts_as_taggable, sin embargo alguien decidió hacerle unos añadidos para convertirlo en más actual, haciendo que el nuevo plugin tuviese:

[...] extras such as tests, smarter tag assignment, and tag cloud calculations.

Este nuevo plugin recibió el nombre de acts_as_taggable_on_steroids y es obra de Jonathan Viney.

Para instalarlo, nuestro primer paso debe ser:

script/plugin install http://svn.viney.net.nz/things/rails/plugins/acts_as_taggable_on_steroids

Tras esto, debemos generar una migración para poder crear la tablas en las que se guardaran los datos:

script/generate acts_as_taggable_migration

Esto nos genera:

004_acts_as_taggable_migration.rb

el número no tiene porqué coincidir con el vuestro; aplicamos la migración:

rake db:migrate

Y ahora ya sólo nos queda hacer que nuestro controlador sea tageable:

class Entry < ActiveRecord::Base
  acts_as_taggable
end

Para añadir tags en el formulario de edición o en el de creación de nuestro modelo concreto, en nuestro caso: entries/new.html.erb y entries/edit.html.erb, basta con la siguiente línea de código:

<%= f.text_field :tag_list %>

así nuestras entradas utilizarán tags y se guardarán.

Nuestro modelo cuenta con una serie de métodos para jugar con tags. Uno que debéis esperar, al ver como he llamado al text_field de los tags, es sin duda:

entry.tag_list = "ruby, rails"
entry.save

Con él añadimos los tags a entry, tras grabarlo.

Podemos añadir a una lista ya existente:

entry.tag_list.add("languages", "article")

borrar una etiqueta concreta:

entry.tag_list.remove("ruby")

Podemos encontrar las entradas taggeadas con unas determinadas tags:

Entry.find_tagged_with('ruby, rails')

Esto nos traera objetos que contenga cualquiera de las dos tags, si queremos que contengan las dos o más, tenemos que usar match_all.

Entry.find_tagged_with('ruby, rails', :match_all => true)

Por defecto el delimitador es una coma, si deseamos cambiarlo, también tenemos esa opción:

TagList.delimiter = " "

añadido al config/environment.rb, quedaría cambiado el delimitador.

Para poder comentar nuestras entradas, vamos a generar un scaffold llamado Entry:

script/generate scaffold Entry title:string body:text create_at:datetime draft:boolean

Empezamos por instalar el plugin:

script/plugin install http://juixe.com/svn/acts_as_commentable

Necesitamos crear una migración para contener la tabla de comentarios, dado que el plugin no la crea por nosotros:

script/generate migration create_comments

Esto nos genera un fichero en db/migrate cuyo nombre es XXX_create_comments.rb; XXX es un número, que dependerá de nuestro contenido en el directorio anterior, en mi caso es 002_create_comments.rb, el contenido que debemos copiar en dicho fichero es:

class CreateComments < ActiveRecord::Migration
  def self.up
    create_table :comments, :force => true do |t|
      t.column :author, :string, :limit => 50, :default => ""
      t.column :email, :string, :limit => 100, :default => ""
      t.column :website, :string, :limit => 100, :default => ""
      t.column :body, :text, :default => ""
      t.column :created_at, :datetime, :null => false
      t.column :commentable_id, :integer, :default => 0, :null => false
      t.column :commentable_type, :string, :limit => 15, :default => "", :null => false
      t.column :user_id, :integer, :default => 0, :null => false
    end

    add_index :comments, ["user_id"], :name => "fk_comments_user"
  end

  def self.down
    drop_table :comments
  end
end

ejecutamos el proceso de migración, para poder empezar a usar la tabla:

rake db:migrate

Para que nuestro modelo Entry empieze a ser comentable, necesitamos añadirle lo siguiente:

class Entry < ActiveRecord::Base
  acts_as_commentable
end

A partir de este momento, tenemos todo listo. Aunque ahora necesitamos utilizarlo, para ello, primero cambiamos la vista de las entradas para que puedan ser comentadas cuando las estemos viendo. Así que modificamos el fichero entries/show.html.erb, y añadimos:

<%= render :partial => 'comment',  bject => @entries %>

Creamos el fichero _comment.html.erb:

Comments
<% if @entry.comments.count != 0%>
    <% for comment in @entry.comments %>
    <%= comment.author%> said <%= distance_of_time_in_words(Time.now,comment.created_at) %>.
    	<%= comment.body %>
    <% end %>
<% end %>

<%= form_tag :action => "comment", :id => @entry do %>
  <%= text_field 'comment', 'author'  %> name (required)
 	<%= text_field 'comment', 'email'  %> email ( will not be shown ) (required)
 	<%= text_field 'comment', 'website'  %> website
	<%= text_area "comment", "body" %>
	<%= submit_tag "Comment!" %>
<%= end_tag %>
(falta añadir los saltos de línea correspondientes)

comment:

 def comment
      @entry = Entry.find(params[:id])
      comment = Comment.new(params[:comment])
      @entry.add_comment comment
      comment.save!

      Commentmailer.deliver_comment(comment)
      flash[:notice] = "Comentario añadido con éxito"
      redirect_to :action => 'show'
  end

La creación del comentario es recogiendo los parámetros del formulario, aunque la parte importante es cómo manejar los comentarios, cómo añadírselo a una entrada:

@entry.add_comment comment

Si os habéis fijado, la tabla añade una columna user_id, de esta forma tenemos asociados los comentarios a los usuarios. De tal forma que podremos hacer búsquedas como:

comments = Comment.find_comments_by_user(user)

De tal forma que obtendríamos todos los comentarios para un usuario dado. O podríamos obtener los comentarios de un usuario para las entradas:

postComments = Entry.find_comments_by_user(user)

Por si os entra la vena investidadora, os diré que en la tabla hay un par de columnas “mágicas” que crean la relación con los distintos modelos que quisieramos comentar:

commentable_id >> almacena el identificador de lo que comentemos
commentable_type >> almacena el tipo de lo que comentemos, en nuestro caso Entry

En otros entornos de desarrollo esto se soluciona gráficamente, añadiendo un icono pequeño a cada archivo de tal forma que podemos saber el estado que tiene. Para TextMate existe una solución: SVNmate.

La instalación es bastante sencilla, el zip contiene un archivo llamado SVNMate.tmplugin que con doble click, se añadirá directamente a TextMate. Podéis corroborarlo entrando en las Preferences, allí podréis visualizar un menú similar a:

Ahora necesitáis reiniciar y todos vuestros archivos adquirirán el icono del estado con respecto al svn.

Existe una pequeña pega: si modificas un archivo, el directorio inmediatamente superior queda como modificado por lo cual sabes que dentro existen cambios para hacer commit, pero por encima de esto ningún otro directorio muestra modificaciones. Un pantallazo de mi entorno de desarrollo os lo aclarará mejor:

Esto hace que mientras trabajas con los directorios desplegados sabes más o menos como estás, pero que si los tienes comprimidos, realmente tienes parte del problema por el cual instalé el plugin.

¿Alguno sabéis si esto es configurable? ¿Habéis utilizado otro plugin?

Update: Para hacer commits, updates, add file, etc. directamente seleccionamos un fichero y luego pulsamos a la vez: ctrl + shift + a.

Como parte del Internship 2008 desarrollado para Linking Paths, hemos emprendido el camino de un proyecto que consideramos bastante interesante; su nombre en clave es: flatee.com. ¿De qué va todo esto? Bueno, la explicación es mejor tormarla del propio blog del proyecto, y no repetirnos:

La idea de flatee es darle una vuelta a las webs de clasificados para compartir piso: las webs especializadas están congeladas desde hace mucho tiempo, las generales de inmobiliarias a las que se les nota esa generalidad y por último las generales de clasificados que como se puede entender aportan bastante poco. De todas formas, sabemos que nuestra apuesta por la singularidad compite abiertamente en un mercado tradicional. No será fácil, pero el internship no es sólo desarrollo de software sino también hacerse valer en un sector determinado y estudiar vías de negocio.

La verdad es que esto es el comienzo, el pistoletazo de salida. Pero queríamos aprovechar la experiencia con un blog en el que ir contando todo lo que nos sucede a lo largo de este tiempo, a la vez que tener una forma de contacto más natural. El tiempo de desarrollo es bastante corto y esperamos que tras esto podamos ofreceros una herramienta en la que buscar pisos compartidos y anunciarlos, orientada sólo a eso, pisos compartidos.

En esta ocasión la idea no va sólo rodeada de un desarrollo, sino que también la acompañan otros cuestiones más ligadas a crear un producto o servicio desde cero que al desarrollo propiamente dicho.

Cómo compañeros de viaje, estamos varios; por un lado: Daniel Latorre y por otro yo mismo. Está claro que no emprendemos la aventura solos, sino que lo hacemos bajo la tutela de Linking Paths, de eso va el Internship.

Durante dos días tendremos la oportunidad de escuchar y también de interactuar con los talleres organizados a tal efecto.
Algunos de ellos para conocer: OpenCms, Trails, Spring, OpenXava, Glassfish o ItsNat.

Es un encuentro organizado conjuntamente por Sun MicroSystems y javaHispano (asociación sin ánimo de lucro), tal como ellos lo describen: “un evento sobre tecnología Java creado por la comunidad y para la comunidad”.

Yo por mi parte estaré por allí, para escuchar algunas charlas, asistir a alguno de los talleres y cómo no, para intercambiar opiniones con algunos de los asistentes, conocidos y no conocidos. Ya sabéis, si nos vemos por allí no dudéis en saludar, aunque no nos hayamos visto en persona, será un placer conoceros. Nos vemos por allí!!

No quiero entrar en ese debate antiguo, más bien quería ver que problemas tenían, y que soluciones encontraron. Algo que me ha sorprendido bastante es el índice de Alexa presentado en las trasparencias. Si consideráis que no es fiable, no os preocupéis por eso, sólo estamos mirando e investigando, dar por hecho que lo es e imaginaros que haríais; y luego pensad si vuestras ideas son buenas soluciones.

Me ha inquietado bastante que en un par de meses el orden de magnitud se incrementase brutalmente. Vamos que se ha multiplicado por 10, aunque realmente me entra la duda de cómo interpretar la unidad que sale en el índice de la gráfica de Alexa.

Lo realmente curioso es lo que les llevó a la conclusión; realmente mejorar el modelo de datos, las querys que se lanzan, crear índices, mejorar el rendimiento en general de la aplicación, etc; bueno, son las primeras cosas que a priori se te ocurren.

Pero hay algunas anotaciones remarcables:

>> Controla tu aplicación. Cuando pones tu aplicación en un servidor para dar servicio a muchas personas, tienes que saber qué está pasando. Hay cosas tan evidentes como el número de visitas, los errores que se están produciendo, lo más visitado, etc. Hasta los tiempos empleados para acceder a determinadas opciones, cuales son los ataques que se están produciendo, el estado de tus servidores (logs, espacio en disco, servicios caidos, nodos caidos…), etc. Existen miles de cosas que tienes que administrar y otras tantas que debes controlar y ser avisado en cuanto se produzcan determinadas alertas.

>> Cachea, cachea, cachea: No conviertas tu base de datos en tu cuello de botella, e intenta cachear toda la información que puedas necesitar y vuelva a solicitarse, evitando peticiones innecesarias a tu base de datos.

Las estadísticas que existían:

# Over 350,000 users. The actual numbers are as always, very super super top secret.
# 600 requests per second.
# Average 200-300 connections per second. Spiking to 800 connections per second.
# MySQL handled 2,400 requests per second.
# 180 Rails instances. Uses Mongrel as the “web” server.
# 1 MySQL Server (one big 8 core box) and 1 slave. Slave is read only for statistics and reporting.
# 30+ processes for handling odd jobs.
# 8 Sun X4100s.
# Process a request in 200 milliseconds in Rails.
# Average time spent in the database is 50-100 milliseconds.
# Over 16 GB of memcached.

Más datos sobre otras arquitecturas en High Scalability.