Va, os dejo unos segundos para que os riáis a gusto… ¿ya? No, ¿que si me instalo el pepino dónde? xD
En serio, dejémonos de coñas (ahora viene el contenido de verdad):

Siempre he intentado no estancarme, renovar mis conocimientos cada poco tiempo y ampliarlos según las necesidades de los proyectos que hago. Eso y algunas -acertadísimas- decisiones estratégicas del departamento al que pertenezco me han llevado a dar un paso más en mis desarrollos con Rails: empezar con el BDD. Para ello, me he puesto manos a la obra con Cucumber, mejorando la experiencia al combinarlo con Mundo Pepino. Pero claro, no todo iba a ser de color de rosa, y es que es imposible instalar la gema si trabajamos bajo una distro basada en Debian (como Ubuntu, el cual es mi caso).

La solución a esto es hacernos con un par de paquetes de los que depende, así que ejecutamos el siguiente comando como superusuario:

Y ya está, con esta tontería nos acabamos de librar del error que escupe justo después de “Building native extensions“.

Se da el caso en que a veces, cuando utilizamos Paperclip, necesitamos que el path de un mismo adjunto sea diferente según su origen. Esto viene bien para guardar su información relacionada (MIME type, tamaño y nombre) en el mismo campo, pero flexibilizando al máximo su ubicación. Para ello, esta popular gema de Rails pone a nuestra disposición una característica muy útil: las interpolaciones.

Con ellas podemos mandar un parámetro extra (mediante un campo oculto, por ejemplo) al modelo para decirle dónde guardar el archivo, qué nombre darle o cualquier otra cosa. Ahora mismo nos centraremos en el primer ejemplo.

Primero, creamos un “initializer” con el siguiente contenido:

De esta manera estamos habilitando el uso de la palabra reservada “:folder” en la instrucción “has_attached_file“, así:

Hace unos meses tenía entre manos una aplicación que consumía Web Services de una API que servía la información en varios formatos (XML, YAML, texto plano y PHP serializado -entre otros-). Para ello se ideó un proceso que con el tiempo se vio que era bastante chapucero, pues se basaba en varias peticiones HTTP y la escritura de su resultado en archivos temporales. Debido a ello, en ocasiones el rendimiento caía en picado, cosa que pasaba hasta que descubrí la forma correcta de manejar este flujo de datos:

Nueve sencillas líneas de código es lo único que necesitamos para lograr este objetivo. Primero, lo encapsulamos todo en un bloque que pueda capturar una posible excepción (”begin [...] rescue“). En la primera parte del mismo obtenemos el contenido y lo parseamos con la herramienta correspondiente al formato de salida que elijamos (YAML en este caso). En la segunda, guardamos en el log el nombre del problema ocurrido y devolvemos “false“.

Parece ser que una de las últimas versiones de Passenger (”mod_rails” para los amigos), la 2.2.4, tiene un bug bastante conocido pero sin solución aparente: la carpeta temporal se crea sin permisos de escritura.
Como en todos los lenguajes de servidor, a la hora de subir un archivo se copia el mismo a un directorio temporal, donde permanece hasta que la transferencia ha llegado al 100%. Como paso posterior a este, vendría el momento de moverlo a su ubicación definitiva, pero es mucho antes cuando ocurre el error que estamos tratando.

Si echamos un vistazo al log, veremos que el proceso falla porque dicho directorio no tiene permisos de escritura. Podríamos pensar en dárselos sin más, pero esto sería sólo una solución temporal, pues este path se renueva cada vez que reiniciamos el server. Para arreglar esto de forma definitiva, deberemos abrir el archivo “Utils.cpp” y buscar esta línea:

Una vez la hayamos encontrado, la sustituimos por esta y reiniciamos el proceso:

…

Fuente: Fermín, mi compañero de Jet. Yo estaba a su lado, pero en realidad el cerebrito de todo esto es él, ¡gracias tío!

RoR tiene muy buena integración con todos los tipos de BBDD existentes, aunque a veces su compatibilidad con algunas características deja mucho que desear. Este es el caso de los “schemas” de PostgreSQL, que para ser usados en la sentencia “set_table_name” de un modelo necesitan que pongamos el siguiente código en el fichero “environment.rb“:

Este bonito mensaje nos aparecerá si acabamos de instalar Ruby y al intentar meter Rails nos damos cuenta de que necesitamos actualizar nuestro ya anticuado RubyGems (< 0.8.5, 1.1 o 1.2). A pesar de ser lo contrario, dichas versiones se empeñan en pensar que son las más modernas, lo que nos obligará a sacarlas como sea del sistema. Esto lo podemos hacer manualmente o ejecutando estos dos sencillos comandos:

• gem install rubygems-update
• update_rubygems

Me he pasado toda la puta mañana intentando probar el “nuevo” Ruby 1.9.1 y el resultado ha sido nefasto. Al ir a la página oficial me he encontrado con que la única versión estable es la de Linux, por lo que me he tenido que conformar con un “Preview binary” de mierda (desgraciadamente trabajo sobre Windows).

Al principio pensaba que con eso bastaría, que la primera release no-windoze llevaba mucho tiempo en circulación y les habría dado tiempo a madurarla lo suficiente… Pero no, me equivocaba. Si dicen que no es la definitiva y que no se recomienda para entornos de producción, por algo es.
Si queremos meterle Rails, el primer escollo que debemos salvar los usuarios del SO de M$ es un error con varias DLLs que faltan, para lo cual tenemos que copiar el contenido del siguiente archivo en la carpeta “\ruby\bin“:

Ruby 1.9.1 Missing DLLs (RAR - 1,52MB) -fuente-.

Desconozco cual es el motivo que les ha llevado a los desarrolladores a prescindir de ellas, si alguien me lo dijese se lo agradecería.

Una vez hecho esto y después de leer el Changelog, podemos ver que la lista de cambios es enorme y bastante significativa. La mayoría de ellos contribuyen a mejorar el lenguaje (haciendo hincapié en la rapidez del mismo), por lo que la migración no puede ser más que positiva. No obstante, hay un gran punto que me ha llevado a volver a la 1.8.6: la incompatibilidad de gemas.
Si tenéis paquetes críticos que desconocéis si siguen estando soportados, os recomiendo la siguiente web: Is It Ruby 1.9?. En ella cuentan con una gran BBDD llena de experiencias de usuarios en este aspecto.

Si a pesar de trabajar con un framework como RoR te empeñas en salirte de las convenciones prefijadas, ya sea por gusto, desconocimiento o circunstancias del proyecto, eres de los míos. Mi caso se acerca más al último punto (con un pequeño toque del segundo ), por lo que he tenido algunos problemas derivados de esta situación.

Llegó un punto en el que tuve que almacenar una gran cantidad de texto en “flash“. Todos éramos felices, el Sol salía cada mañana y los pajarillos canturreaban… hasta que dicha información superó los 4 Kb . No había caído en que se estaba haciendo uso de las cookies para almacenar el ID de sesión, por lo que a veces aparecía una bonita excepción con el nombre que titula este post.

Pero Rails siempre tiene una alternativa, y esta vez consistía en guardarlo todo directamente en la BBDD, mejorando de rebote la seguridad del sistema (no así su rendimiento, aunque la diferencia es mínima). Para ello, sólo tenemos que seguir los siguientes pasos:

• Descomentar el “protect_from_forgery :secret” en el archivo “controllers/application.rb“.
• Descomentar también la línea que tiene lo siguiente en el “environment“: “config.action_controller.session_store = :active_record_store“.
• Ejecutar estas dos tareas “rake”: “db:sessions:create” (que nos creará el archivo con la estructura de la tabla) y “rake db:migrate” (que ejecutará la migración de acuerdo al paso anterior).

Si todo ha ido bien, en el próximo reinicio del servidor deberíamos ver el tinglado este funcionando.

Llevo sin escribir dos meses justos, lo sé, y lo peor no es eso, sino las pocas ganas que tengo de solucionarlo…

La verdad es que está siendo una de las etapas de mi vida con más ajetreo que recuerdo, y no es que esté haciendo muchas cosas, sino que las pocas que hago absorben todo mi tiempo. Por todo esto y la vaguería que me caracteriza para según qué asuntos, he acabado con una pedazo de lista de links sobre temas que quería tocar en el blog, pero como al final veo que me va a ser imposible abordarlos todos sin que caduquen, he preferido hacer una breve reseña de cada uno en este post.

No os guiéis por el orden, pues los soltaré según me vengan, de la misma manera que me los encontré por Internet.

Y cuidado… que vienen curvas. Leer más…

Pero en su versión standalone, claro, sino conseguirás todo lo contrario.

…

Llevo tiempo utilizando sólo Notepad++ como editor de texto y única herramienta de desarrollo. Siempre me ha ido bien así, ya que me gusta hacerlo todo a pelo (malpensados… xD), pudiendo ver en todo momento qué está pasando. Incluso con las BBDD he seguido esta manera de trabajar, nada de Query Browsers ni polladas, hasta los “CREATE TABLE” los hacía a mano. Pero no, ya no. Con mi incursión en el mundo Rails no podía seguir así, tenía que seguir una metodología ágil totalmente (con su Scrum y todo), y eso pasaba por abandonar todas estas costumbres.

En PHP no tenía que preocuparme de nada, simplemente iniciaba Apache y listo. Ahora, además de eso tengo una bonita consola que me sirve para generar modelos, hacer scaffolding, migrar tablas y muchas cosas más. De hecho, hasta el arranque del server se hace con un comando… Y tenía que encontrar un buen compañero de viaje. Leer más…