a Freelance Web Developer

Estaba yo haciendo unos testecitos y veo que no se me estaban borrando los datos de la base de datos al ejecutar cada test lo cual me estaba generando unos poltergeist horribles.

Un comportamiento de Rails en el que confiaba como era este: “La base de datos vuelve al estado original en cada test“, me estaba traicionando.

Bueno el problema era que como mis tests no usaban fixturas no las estaba cargando y resulta que es la carga de las fixturas lo que borra la bd y no la propia suite de tests.

Solución:

fixtures :mimodelos

Aunque no use las fixturas es lo que he tenido que hacer para que la tabla se borrase con cada test.

¡Qué cosas!

Normalmente cuando se escribe un email en formato enriquecido el propio cliente de email se encarga de generar dos partes dentro del email, una con el texto en formato html (enriquecido) y otra en formato texto plano por si el cliente de correo con el que finalmente el destinatario lo abra así lo quiere.

Bien, para una aplicación en la que estoy trabajando se requiere que dado un email con varias partes (html y texto plano) pueda extraer sólo la parte html.

No he encontrado nada en la clase TMail::Mail de Ruby que me ofrezca esta funcionalidad.

No parece difícil en un principio, pero en realidad si profundizas un poco si que se vuelve lioso. Si cogemos el body del Mail lo tenemos todo junto y no sabemos donde cortar, ni siquiera si es requerido cortar. Si empezamos a recorrer las partes del Mail podemos empezar a rastrear los content_type de cada una pero esto puede resultar engañoso pues la parte con el body en formato enriquecido tiene el mismo content_type que un fichero html adjunto en el email.

Al final lo que me ha quedado es este método:

def body_html
  result = nil
  if multipart?
    parts.each do |part|
      if part.multipart?
        part.parts.each do |part2|
          result = part2.unquoted_body if part2.content_type =~ /html/i
        end
      elsif !attachment?(part)
        result = part.unquoted_body if part.content_type =~ /html/i
      end
    end
  else
    result = unquoted_body if content_type =~ /html/i
  end
  result
end

Es un método que extiende la clase TMail::Mail para ofrecer el método .body_html que devuelve la parte html o nil si no hay ninguna parte de texto enriquecido.

Puede parecer liosa pero en realidad está inspirada en el método .body de la propia clase TMail::Mail.

Podéis descargaros el parchecito de TMail::Mail y hacer un require del mismo, o también podéis mirar directamente el repositorio donde lo he subido junto con unos pocos tests.

Cualquier comentario es bienvenido.

Mis versiones:

• Mac OS X 10.5.4
• Ruby 1.8.6 patchlevel 114
• Rails 2.1.0

Tengo problemas para introducir caracteres no ASCII ( caracteres especiales, acentos y ñs ) en la consola IRB de Ruby así como también en la consola script/console de Rails.

Gracias a las lista ror-es lo he podido solucionar.

Resumo aquí a mi manera el post con la solución:

Instalamos la versión universal de la librería readline mediante MacPorts:

$ sudo port install readline +universal

Si te dá error de:

-bash: port: command not found

Asegúrate que tienes instalados los MacPorts y que tienes esto en tu .bash_profile:

export PATH=$PATH:/opt/local/bin
export MANPATH=$MANPATH:/opt/local/share/man
export INFOPATH=$INFOPATH:/opt/local/share/info

Instalamos la extesión Ruby para readline. Vigila la versión que te bajas, debe coincidir con tu versión de Ruby exactamente:

$ ruby --version
ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]

v1_8_6_114

$ cd /tmp
$ svn co http://svn.ruby-lang.org/repos/ruby/tags/v1_8_6_114/ext/readline/ readline

Aplicamos un parchecito:

$ curl http://pastie.textmate.org/pastes/168767/download | patch readline/extconf.rb

Y compilamos, necesitarás tener instaladas las OS X developer tools:

$ cd readline
$ ruby extconf.rb
$ make
$ sudo make install

Si el script/console te sigue dando problemas asegúrate de tener bien la $KCODE:

$ script/console
Loading development environment (Rails 2.1.0)
>> puts $KCODE
UTF8
=> nil

Gracias de nuevo a Daniel Rodriguez Troitiño por la solución.

Aclaración: En este texto repito mucho la palabra Rails, todo el mundo entiende que me refiero a Ruby on Rails. Pero creo que en muchos de los contextos debería haber puesto Ruby. Para mí Rails no sería nada sin Ruby y Ruby no sería nada sin un framework como Rails.. pero Rails es más suplantable que Ruby.

He estado viendo una de las charlas de las Conferencias Rails 2007.

Concretamente la de Fernando Blat sobre caché en Rails. Estoy intentando integrar esto de las cachés en un proyectillo basado en Rails que estoy haciendo.

La paradoja es la siguiente: resulta que sale uno haciendo una pregunta (minutos 41:40 al 43:00) que justamente me ha surgido a mí mientras videaba la charla. Resulta que el que hace la pregunta soy yo, resulta también que el proyecto en el que estoy trabajando lo hago bajo la supervisión del mismo Fernando Blat y es a quién se la iba a preguntar en persona. Resulta que no me acordaba de nada de esta charla. Resulta que no tenía ni idea de Rails en ese momento y que justamente ahí y entonces es cuando estaba pasando la etapa de la ironía y del rechazo para pasar a la de la aceptación.

Han pasado exactamente 9 meses de esa charla y las cosas han cambiado realmente mucho.

Conferencias Rails 2007

Fuí a las Conferencias Rails 2007 con una actitud completamente escéptica. Ya había oído hablar de Rails a los más freakies de mi cuadrilla, y también al más experimental de mis socios, pero había obviado sus comentarios con bastante incredulidad, yo soy una vieja mole de Java y estaba encantado con ser así.

Normalmente actúo con esta actitud ante la presencia de cualquier nueva tecnología que me presentan, no me gusta ser pionero en experimentar, me gusta vigilar desde la costa hasta ver si el barco sigue navegando cuando el viento amaina.

Voy en la cola de la comunidad, un paso por detrás de la cresta. Esto puede que me haga retrasarme un poco pero conozco el esfuerzo que requiere adquirir experiencia en cualquier tecnología, y lo que es peor, el esfuerzo que requiere dejarla cuando ha sido una decisión desacertada, por lo que cuando pongo algo en el punto de mira lo hago con mucha energía ahorrada.

Si me hubiera dejado llevar por todo canto de sirena que he escuchado me habría perdido en el baile eterno de ruidos como EJBs o Google Web Toolkit.

Durante las Conferencias Rails 2007 yo era un convencido de Java, no creía que nada de lo que oyera ahí fuera a convencerme, tengo la experiencia de que este tipo de conferencias endogámicas suelen ser un circuito de palmaditas en las propias espaldas vacías de contenido.

El primer día lo pasé discutiendo con la gente que se me acercaba, incluso con los conferenciantes ( Arquitectura hardware en Rails minutos 46:00 al 50:45, Tomatine minutos 18:30 al 20:30, Mtv.es minutos 26:20 al 28:00, y alguna más que no quedá grabada.. menos mal :) ) , expresando mi escepticismo hacia el cúmulo de bondades que este semi-nuevo framework estaba trayendo al mundo del desarrollo de software. Lo llaman la fase de la negación. Ya había pasado la fase de la ridiculización.

El segundo día llevaba un cabreo de la leche. No podía ser, no era cierto. No quería cambiar, quería que Java siguiera siendo lo mejor. Pero dentro de mí empezaba a solidificarse una revelación: Rails era mejor, no para el desarrollo web, sino para mí.

Era la primera vez que oía tantas veces repetida como feature de un framework: “la búsqueda de la felicidad del programador“. Me estaban hablando a mí, eso es lo que he buscado siempre en mi profesión: la felicidad. Entiéndase la felicidad del programador no como currar poco y cobrar mucho sino como ‘resolver‘ una necesidad de una manera elegante y ágil.

Me entró un temblor débil, dejó de ser desagradable. Recuperé el entusiasmo que cíclicamente me viene: Cuando hice mi primer FOR en el BASIC del MSX, cuando moví mi primer Sprite, cuando parcheé mi primera interrupción de teclado, cuando hablé con una bombilla vía puerto paralelo, cuando hice mi primera función C, cuando accedí por primera vez directamente a la memoria de vídeo, cuando inserté mi primer registro en una base de datos, cuando envié mi primer mensaje entre dos sockets, cuando hice mi primera web dinámica, … creo que a partir de entonces lo había perdido, todo se había vuelto pesado y costoso.

Rails había venido para rescatarme.

Las conferencias acabaron pero del poso en el estómago surgió una inquietud indomable.

Dejo Constela

Todo se había juntado, a mi agotamiento como desarrollador se sumaba el peso y responsabilidad de ser socio de una empresa que había empezado ha crecer y a comer recursos y presupuesto con avidez.

En Constela, con la compañía de mis socios Jesús y Miguel y del resto de equipo que juntamos, me hice fuerte, me hice duro, conseguí una experiencia que solo se consigue con la lucha. Les debo mucho.

Pero me sentía pesado, mis movimientos se habían vuelto costosos, el barco era fuerte pero su timón era muy duro y me bajé. Me dejaron una barca y empecé a navegar, remando, despacito, cantando.

Me pongo a comprar libros Rails como un loco

El entusiasmo había vuelto, la avidez autodidacta solicitaba información, ahora tengo casi todo lo recomendable traducido al castellano y casi todo lo imprescindible sin traducir.

Devoro información, todo es demasiado diferente, el click en mi cabeza tardó en llegar y todavía oigo su eco por lo reciente que ha sido.

Entro en la lista ror-es

La lista de desarrolladores de Rails en castellano, una comunidad muy pequeña pero inspiradoramente entusiasta y animada. Duramente moderada por @mort a quien he temido e incluso odiado en mi primera etapa, ahora casi-superada.

Hago la tienda de Hola Por Qué

Mi primer Hola Mundo en Rails no es una paginita con un mensaje insulso, es una tienda online :)

Muy pocas líneas de código picadas con el método de prueba y error, sin haber conseguido todavía hacerme con la sintaxis de Ruby ni el intríngulis de Rails, escribía instrucciones y declaraba variables al tanteo hasta que ningún Sintax Error ni nigún Error 500 aparecía.

Todo montado sobre sólo 2 tablas de base de datos.

Fichado por La Coctelera

Para mí La Coctelera ha sido, desde que conozco Rails, como el buque insignia español de este framework.

Escribo a Álvaro para comunicarle mi deseo de entrar a formar parte de un equipo con experiencia y entusiasmo como el suyo.

A los pocos días me encuentro con una seudo-entrevista de trabajo en un vagón de metro de la línea 1 con Álvaro y Fernando Blat.

Yo no llevo nada para enseñarles sólo les transmito mi entusiasmo y mi seguridad de que simplemente “se me dá bien esto del desarrollo web”. (Bueno, igual mi experiencia como responsable de tecnología en Constela y jefe de proyecto en el desarrollo de Kroonos fueron una buena carta de presentación).

Tienen entre manos un proyectillo que parece pensado para mí y me pongo manos a la obra. Y aún hoy sigo dando guerra por sus oficinas.

La experiencia de trabajar con un equipo de desarrollo ágil como el que tienen aquí en La Coctelera y The Cocktail en general, además de estar bajo la continua supervisión y apoyo de un joven gurú de nuestros tiempos como es Fernando Blat me está haciendo recuperar a grandes zancadas el retraso provocado por mi, aún valorado y mantenido, escepticismo.

Voy al Euruko

Y cojo y me voy a Praga, al Euruko 2008. Unas conferencias temáticas sobre Ruby. No disfruto tanto dentro como fuera de las conferencias.

Afuera me acoge con un pequeño grupo de raileros que también habían venido desde España, casi todos gurús de Rails y todos un encanto de personas.

Son las primeras conferencias de programación en las que se mezclan de manera perfecta las experiencias freakies con las amorosas.

La foto con el creador de Ruby

Y subiendo escalas en mi incipiente carrera como gruppy de Ruby aquí me tenéis, en una foto de pésima calidad, con el creador de Ruby Yukihiro ‘Matz’ Matsumoto y uno de los gurús al que llaman Dr Nic.

Red de amigos raileros y madrid-rb

El Euruko, las charlas, las comilonas y las risas crean pequeños vínculos que se comienzan a reafirmar con el reempuje de la comunidad Ruby de Madrid, del que soy testigo.

El último jueves de cada mes es la kdd oficial del grupo de Ruby de Madrid y aunque esta comunidad sea mucho más pequeña el karma de este lenguaje hace que las kdds sean mucho más populares que las de Java que solía convocar con la gente de Java-Madrid hace unos años.

Ahora ya conozco en persona a prácticamente la totalidad de los conferenciantes de esa mítica Conferencias Rails 2007 :)

Miembro fundador de rsug

Y me encuentro firmando el acta como uno de los socios fundadores de la asociación Ruby Spanish User Group, que aunque ahora no tenga los conocimientos ni experiencia suficiente espero aportar/devolver algo de lo que siempre tanto recibo a la comunidad.

Participo en el 2º concurso de programación de OpenMovilForum

E hinchado de orgullo por mis rápidos progresos me incribo al concurso de programación del OpenMovilForum con unas expectativas desorbitadas de llevarme el primer premio.

Presento no 1 sino 2 proyectos desarrollados en unas 3 semanas. Algo imposible de imaginar para mí hace pocos meses.

El resultado: me como los mocos. Pero empiezo a notar la soltura, empiezo a sentirme ágil.

Lluvia de ofertas de trabajo

Aunque no todas han acabado en acuerdo, sí que noto que mi perfil empieza a ser apetitoso.

Los principales escollos que veo es que el cliente sigue pensando que esto del desarrollo web es una baratija o que un freelance es intrínsecamente mucha más barato que una empresa.

En cualquier caso me siento cómodo y sé que cada vez me siento más capacitado para dar a los clientes lo que de verdad quieren: opinión, una persona resolutiva, prototipos rápidos y desarrollo iterativo.

Me compro un mac

¿Es este un paso que tiene que ver con mi incursión en Rails?…

Indudablemente sí, contagiado por la fiebre maquera que afecta a esta comunidad. Pero sobre todo tiene que ver con la búsqueda, mucho más antigua, de la agilidad.

¿Soy más feliz ahora?

Sí.

¿Será por Rails?, ¿por volver al mundo freelance?, ¿por mi nuevo Mac?… ¿por el amor?.. qué más da!

El truco más sencillo para precargar las imágenes de tu web y así no ver el horrible efecto de mouse-over hueco es hacer un script javascript como este:

img1 = new Image();
img1.src="imagen.jpg";

Esto invocará la imagen y el navegador, sino es muy tonto, la dejará en la caché para cuando verdaderamente la necesite.

Bueno, pues es lo que quiero hacer para una web que tiene un montón de background-image definidos en su css.

Para ello me he hecho un script en ruby que me busca todas las imágenes en todos los css y me genera un script de javascript con todo el rollito de los preload.

class Preloator
  def self.generate_script( css_directory )
    # take all .css on directory
    css_file_names = []
    Dir.foreach( css_directory ) do |file|
      if file =~ /.*\.css$/
        css_file_names << css_directory + '/' + file
      end
    end
 
    # take all the images by looking at 'url'
    image_names = []
    css_file_names.each do |file_name|
      self.grep( 'url', file_name ).each do |line|
        image_names << line.scan( /.*\((.*)\)/ ).flatten.first
      end
    end
 
    # generate the script
    script = "<script>\n"
    image_names.each_with_index do |image_name, index|
      script += "    img#{index} = new Image();\n"
      script += "    img#{index}.src = \"#{image_name}\";\n"
    end
    script += "</script>"
  end
 
  def self.grep( pattern, filename )
    matches = []
    regexp = Regexp.new( pattern )
    File.open(filename) do |file|
      file.each do |line|
        matches << "#{filename} #{file.lineno.to_s}: #{line}" if regexp.match(line)
      end
    end
    matches
  end
end
 
puts Preloator.generate_script( ARGV[0] )

Esto genera una salida como esta:

$ ruby etc/preloator.rb public/stylesheets/
<script>
img0 = new Image();
img0.src="/imgs/fondo.jpg";
img1 = new Image();
img1.src="/imgs/fondo_carpeta.png";
img2 = new Image();
img2.src="/imgs/blog_sombra_abajo.png";
img3 = new Image();
</script>;

Seguramente quieras mejorarlo un poquito: meterlo en un .js o invocarlo cuando el document.load.

El script ahorra trabajo si, como en mi caso, tienes más de 20 imágenes en el css.. y escribir el javascript a mano sería un coñazo.

Cómo ya dicen en muchas partes, pero me repito aquí para parecer muy listo y por marcarlo como nota mental, para acceder a tu cuenta Pop en Gmail desde Ruby hay que hacer una ñapa porque la versión actual de Ruby (1.8.6) no admite conexiones Pop bajo SSL.

Si si.. la 1.9 ya tiene el soporte, y dicen por ahí que descargándote el pop.rb de esta versión desde el repositorio y haciéndole un require ya funciona.. pero no, por lo menos a mí no porque me salta alguna dependencia con OpenSSl:

NoMethodError: undefined method `set_params' for #<openssl::ssl::sslcontext:0x210f4d0>;
</openssl::ssl::sslcontext:0x210f4d0>

Y no quería seguir tirando de el hilo.

El workarround que más me ha gustado ha sido el de montar un tunel ssh y hacer la petición desde el Net::POP3 al túnel y que el túnel se la haga llegar al pop de Gmail bajo SSL.

No voy a entrar en detalle porque ya lo hacen en muchos sitios.

Actualizado: acabo de ver un sitio dónde explican como usar la implementación pop.rb de la 1.9 sin el problema que me da a mí.

Los pasos resumidos que este post explica son:

1) Descargarte una implementación de la librería POP3: la versión 13778.

2) Ponerla en tu carpeta lib con este nombre por ejemplo: pop_ssl.rb con esto sobreescribiremos la implementación de esta librería que trae ruby por defecto con una versión mayor.

3) Descargarte este fichero y ponerlo también en lib: pop_gmail_client.rb

class PopGmailClient
  def self.read_account( account_user, account_pass )
    mails = []
    Net::POP3.enable_ssl(OpenSSL::SSL::VERIFY_NONE)
    Net::POP3.start( 'pop.gmail.com', 995, account_user, account_pass ) do |pop|
      pop.each_mail do |m|
        mails << m.pop
      end
    end
    mails
  end
end

4) Requerirlos desde el environment.rb al final del todo con:

require 'pop_ssl'
require 'pop_gmail_client'

Y ya podemos usarlo como queramos:

$ script/console
Loading development environment (Rails 2.0.2)
>> PopGmailClient.read_account( "fguillen.testing@gmail.com", "xxx" )

O desde ruby directamente:

$ irb
>> require 'lib/pop_ssl.rb'
=> true
>> require 'lib/pop_client_gmail.rb'
=> true
>> PopGmailClient.read_account( "fguillen.testing@gmail.com", "xxx" )

Es lo que tiene ruby.

Llevo un par de horas intentando sacar un Float en formato ‘d.ddd.ddd,dd’. Hay muchas cosas en internet para conseguirlo, pero no todas funcionaban bien, y otras funcionaban demasiado bien, con un montón de opciones.

El caso es que hay un helper del ActionView que tiene la función number_to_currency pero es un cabroncete de helper y no podía acceder desde el modelo. También teníamos la gema Currency pero era un pedazo monstruo para la tontada que yo quería.

Al final la gema Scruffy me ha dado la pista y esto es lo que tengo:

class Float
  def en_euros
    parts = sprintf("%01.#{2}f", self).split('.')
    parts[0].to_s.gsub(/(\d)(?=(\d\d\d)+(?!\d))/, "\\1.") + "," + parts[1].to_s
  end
end

Es un parchecito del Float para poder hacer esto:

>> 1234.566.en_euros
=> "1.234,57"

¿Tu gusta Ruby? ¿Eres capaz de respirar el aire infectado de las calles de Madrid? ¿Tienes habilidades de comunicación como el habla y/o el oído? ¡Pues vente!

Hace poco se ha vuelto a dar vida al grupo Ruby-Madrid. El pasado jueves  24 se celebró la primera kdd de este nuevo ciclo.

Nos juntamos como unos 12 personajes entusiastas y desde las 19:30 puntuales que fuimos muchos la velada se alargó hasta más de las 24:00.

La idea es programar kdds todos los último jueves de cada mes. La hora aproximada será las 19:30 y el lugar a decidir en cada ocasión, la primera fué en el Starbucks que, pese a las dudas de muchos de los presentes, escaló lo suficiente para darnos cobijo a todos. La siguiente se está pensando ir al Aula The Cocktail.

Lo ideal es que cada kdd tuviera una temática central o una ponencia por parte de alguno de nosotros aunque no es imprescindible, es simplemente para darle un hilo conductor, todos sabemos que luego acabamos hablando de lo que surge, en realidad de mil cosas.

La lista de coordinación es esta: lista de coordinación del grupo Ruby-Madrid.

El calendario para estar atentos: calendario del grupo Ruby-Madrid.

¡Qué bonito y agradable es compartir opiniones, discrepancias y chistes temáticos! De verdad que agradezco mucho este tipo de iniciativas, es una gran motivación ver a gente motivada, relatar experiencias, despotricar de los clientes, pedir opinión y soluciones, … en resumen: sentirse acompañado y, por qué no, protegido.

Se está discutiendo a dónde llevar el próximo Euruko 2009. Podéis participar en el grupo del omnipresente FaceBook: EURUKOBACKWEB, para ayudar a decidirse.

Aunque los organizadores de la actual edición ya declararon sus preferencias:

:)

Actualización 08 de Abril: Parece ser que la gente implicada en llevar la convocatoria española se está decantando por Barcelona, para repartir las conferencias: Conferencia Rails en Madrid, Euruko en Barcelona.