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!

Siguiendo con lo que os contaba en el post anterior, en otra ocasión tuve que importar un CSV, para lo cual disponemos del un módulo cojonudo con ese mismo nombre. Además de otras muchas cosas, nos permite leer y parsear un archivo con sólo escribir esto:

Como veis, se trata de un bucle que saca una línea cada vez, permitiéndonos operar con ella como si de un array se tratase. Si en una de estas operaciones nos decidimos a insertar los datos directamente en la BBDD, podemos encontrarnos con el siguiente fallo:

Si nos fijamos en los valores del “insert” que intentamos ejecutar, vemos que hay una interrogación (que en este caso se corresponde con una “í“). Esto se debe a que, al ser de texto plano, el archivo no cuenta con ninguna indicación que le permita al parser saber qué codificación tiene, por lo que debemos decírselo nosotros con una simple instrucción que nos brinda “Iconv“:

Si conocemos el charset de entrada se lo podemos poner directamente (tal y como hemos hecho ahora). Sino, nos será de gran ayuda una librería como CharGuess, que se encarga de hacer diferentes comprobaciones para decirnos, finalmente, qué encoding cree que se ha encontrado. Es importante remarcar esto último, pues el resultado siempre será una mera conjetura de la aplicación, nunca una verdad absoluta.

Trabajando con Ruby te das cuenta de que en Internet está todo lo que puedas imaginar. No necesitas cursos, profesores ni ejemplos. Nada. Cualquier ayuda extra es bien recibida, aunque sin ella también puedes llegar a la resolución de ese problema que te lleva comiendo la moral una semana.

Eso sí, ser autodidacta tiene dos grandes pegas:

• Sólo aprendes lo que te exige la experiencia, el día a día.
• Generalmente, inviertes más tiempo de lo deseable en ello.

Esta pequeña introducción viene a que el otro día, intentando hacer algo tan trivial como copiar un archivo de una ubicación a otra, me encontré con varias supuestas soluciones bastante confusas o erróneas. Pese a esto, que probablemente sea uno de los detonantes del segundo punto, conseguí llegar al final de la historia. Todo ello me llevó a querer postear más a menudo sobre temas breves, sencillos y que no deberían ser problemáticos, pero que a veces nos consumen más tiempo del que deberían…

Al grano

Según un montón de webs, basta con hacer un simple “File.copy“… Nada más lejos de la realidad, pues si lo intentamos sólo conseguiremos ver el siguiente error:

Como no queremos crear un nuevo objeto de la clase “File” ni nada parecido (que es lo que intuyo que necesita el comando anterior), debemos echar mano del módulo “FileUtils“. Este es el más indicado cuando queremos ejecutar métodos de bajo nivel, de entre los cuales elegiremos “copy_file“:

Fácil, ¿no?

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.