Por si os sirve de ayuda, en dreamhost los logs del servidor, se encuentran en:

/home/username/logs/yourdomain.com/http.#####/access.log
/home/username/logs/yourdomain.com/http.#####/error.log

Los tenía localizados, pero no lograba ver nada en error.log, y en access.log sólo veía mis peticiones, lo normal.

Hace tiempo que no actualizo el servidor, y pensaba continuamente en los posibles errores que podría haber con respecto a versiones de gemas utilizadas, por lo que después de redesplegar varias veces intentando reajustar, seguía sin lograr ver la traza del error.

Tras comparar con mi instalación en local, decido buscar a fondo en el servidor, compruebo versiones de gemas, configuración, tenía cambios importantes con respecto a una versión anterior, a parte de estar utilizando una versión mucho más reciente de Rails, pero seguía sin funcionar y sin ver nada en las trazas. Cierto es que tenía algunas cosillas que no estaban del todo bien, y que gracias a esto he ido corrigiendo, pero nada que apuntase en la dirección del erro. Así que ejecuto un simple:

rake -T

si todo funciona bien con los plugins y las gemas, me dará el listado de tareas, simple; y he aquí que localizo la fuente del error! La versión de RubyGems es demasiado antigua para esta versión de Rails, la verdad es que las trazas inexistentes no han sido de gran ayuda para ver este error . Mi versión era la 1.2.0 y se requería mínimo la 1.3.

Decidido a solucionarlo, intento actualizar, un simple:

gem update –system

… no soluciona nada, dado que responde con un:

Nothing to Update

Así que probamos la siguiente opción:

gem install rubygems-update
update_rubygems

El problema es que ya de partida la instalación de rubygems-update, versión 1.3.5, arroja unos errores, aparentemente no preocupantes al terminar de instalarse, sin embargo al intentar ejecutar el segundo comando, nos da un error, siento no haber anotado la traza.

Navegando en internet, descubro que dicha versión tiene ese problema, que está anotado en los foros, pero que no ha sido resuelto, y la recomendación es: instalación manual; ante esto me han entrado las dudas y la simple pereza. Si actualizaba, ¿existirían problemas con mis gemas instaladas en mi directorio personal? Tendría que reinstalarlo todo, en principio suponía que no, pero no estaba del todo seguro, cuando sin embargo me he acordado de algo.

En las últimas versiones de RubyGems, si no antepones sudo, al comando de instalación, la copia se hace en la home del usuario que instala y todo funciona sin problemas, para él. Así que me he decidido por quitar todas las configuraciones que existían en mis ficheros acerca del mi propia instalación de RubyGems y he logrado comprobar que los chicos de dreamhost ya habían actualizado a la última versión. Así que ni corto ni perezoso he pasado de actualizar manualmente mi copia, y eso sí, continuaré utilizando mi instalación de gemas en mi cuenta de usuario, así podré controlar que gemas instalo y que versiones, dado que no siempre he encontrado las gemas que necesitaba instaladas, es por esto por lo que empezó todo (…y por no poder ejecutar sudo ).

Los cambios:

- El sistema de gestión del blog, hasta ahora serendipity, deja de ser el alma del blog y pasamos a Wordpress. Todos los datos, las imágenes, etc. han sido migrados ya.

- Los feeds. Con respecto a esto hace tiempo que empezé a utiliar feedburner, pero tras la compra por parte de google, he migrado la cuenta tal como me recomendaba el sistema y a partir de ahora hay una nueva dirección:

http://feeds2.feedburner.com/jenaiz

aunque según cuentan el sistema redireccionará automáticamente a los antiguos. Os recomendaría pasaros a la nueva dirección.

- El dominio, un pequeño cambio. La dirección del blog ahora colgará de:

http://blog.jenaiz.com

así el dominio general dará cabida a otras cosillas que iréis viendo.

- Cambiamos de servidor, nos pasamos a utilizar el servicio de dreamhost a ver que tal resulta.

Golpes de tambor….

- Habrá un nuevo diseño, que espero os guste más que el actual. Un poco más moderno, y con colores que permitirán leer los post con mejor contraste.

Sólo decir que la gestión del dominio cambiará también de servidores, por lo que puede que existan algunos problemas en 24 – 48 horas.

Object o = Class.forName("className").newInstance()

lo curioso es que vi que no necesitaba esta solución, que mi problema era otro , sin embargo la curiosidad pudo más que la necesidad.

Esperaba utilizar para ello la misma clase: Class, sin embargo descubrí que no podía hacerlo así. En Ruby el camino es distinto. Un post en stackoverflow me llevó a encontrar una solución múltiple, aquí las distintas posibilidades:

Object::const_get('String').new()

class_name = 'String'
eval(class_name).new

Module.const_get('Array').new

Y un helper:

"String".constantize.new

Module.const_get no funciona con clases anidadas en módulos, digamos que no admite la sintaxis Admin::Folder, debido a que sólo reconoce sintaxis válidas para dar nombre a una constante.

eval, por el contrario sí permite nombres de clases con namespaces, aunque sufrimos un decrimento en el rendimiento.

Podríamos comprobar el rendimiento de todas ellas con un simple script:

#class_instanciation.rb
#!/usr/bin/env ruby
#
#  Created by  on 2008-11-24.

require 'benchmark'
require 'qualified_const_get'

n = 1000000

Benchmark.bmbm(10) do |rpt|
rpt.report("simple") do
n.times {Array.new}
end

rpt.report("Object::const_get") do
n.times {Object::const_get('Array').new()}
end

rpt.report("Kernel.const_get") do
n.times {Kernel.const_get('Array').new}
end

rpt.report("Kernel.qualified_const_get") do
n.times {Kernel.qualified_const_get('Array').new}
end

rpt.report("eval") do
n.times {eval('Array').new}
end

# no funciona!!
#rpt.report("eval") do
#  n.times {"String".constantize.new}
#end
end

#qualified_const_get.rb
module Kernel
def qualified_const_get(str)
path = str.to_s.split('::')
from_root = path[0].empty?
if from_root
from_root = []
path = path[1..-1]
else
start_ns = ((Class === self)||(Module === self)) ? self : self.class
from_root = start_ns.to_s.split('::')
end
until from_root.empty?
begin
return (from_root+path).inject(Object) { |ns,name| ns.const_get(name) }
rescue NameError
from_root.delete_at(-1)
end
end
path.inject(Object) { |ns,name| ns.const_get(name) }
end
end

Los resultados obtenidos los podéis ver en la siguiente gráfica:

en ella podemos apreciar que si utilizamos const_get se tarda aproximadamente 2 veces más que con la creación normal; que el uso de eval nos hace emplear 5 veces más tiempo y que sin duda la implementación de qualified_const_get no es nada buena, dado que nos hace emplear unos 10sg! osea unas 15 veces más.

La recomendación sería utilizar const_get siempre que se pueda, es decir mientras nuestra clase no tenga namespaces y eval cuando no quede más remedio. El caso de qualified_const_get, me parece poco apropiado para cualquier caso.

Por otro lado, el caso de constantize, no terminó de funcionar, por lo que es imposible compararlo.

Algunas de las características que me han llamado más la atención por el uso inmediato que voy a hacer de ellas o por su potencial futuro:

- Internacionalización i18n. Aún existiendo numerosas opciones para internacionalización (tal como gettext, globalize, etc), sin duda es una de las características que más se le echaban en falta a Rails desde hacía tiempo. Nosotros en Tog habíamos empezado a internacionalizar utilizando esta característica que estaba disponible en el Edge.

- Compatibilidad con Ruby 1.9 y con JRuby. Mucho es el trabajo que se ha realizado para utilizar las nuevas características del lenguaje mejorando el rendimiento y adaptándose a la nueva versión de Ruby.

- Documentación. En este sentido caben destacar las guías, donde se está realizando una labor de documentación increíble. Aquí podemos apuntar un nombre de alguien que a todos os sonará por su labor: Xavier Noria. Sin duda uno de los puntitos para haber sido elegido personaje Rails 2008 .

- Mejoras en HTTP. Soporte de ETag y Last-Modified que responderán con una respuesta vacía si la página no ha cambiado.

- Thread Safety. Threads en rails; sin duda un tema complejo, para el cual os recomiendo leer una explicación realizada por Charles Nutter.

- Migraciones transaccionales. Desde ahora los errores producidos en una migración harán que la migración no se ejecute, como hasta ahora, pero también que quede registrado todo el proceso de la misma como inválido, restableciendo el estado de la base de datos a la migración anterior.

- Pool de conexiones. Podemos manejar un pool de conexiones para conectarnos con la base de datos, fácilmente configurable en nuestro database.yml.

- Resources con acciones específicas. Hasta ahora cuando creabas los resources automáticamente para un modelo se creaban las 7 acciones por defecto: index, show, create, new, edit, update y destroy. Sin embargo esto tiene un gasto de memoria extra y crea una lógica que en ocasiones no tienes porqué usar, por lo que ahora puedes seleccionar cuales te interesan:

map.resources :articles,  nly => [:index, :show]

- Action Mailer: Ahora dispone de soporte para layouts; tal como el resto de nuestras vistas.

- Se incluye también soporte para cuentas de Gmail, aunque esto requiere de la versión 1.8.7 de ruby.

Existen más características e información ampliada de todo lo aquí mostrado en la nota publicada de esta release.

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 .

En breve mi feedback de la misma.

Si alguno estáis por allí y aún no nos hemos visto, no dudéis soy tímido pero no muerdo .

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.