1. Oída en el capítulo final de la temporada 4 de House, que curiosamente utiliza la versión original como música de la presentación (al menos en EEUU).
2. De la que ya hablé en Bolsa de basura adolescente.
3. La pillé el otro día en RNE3, y consiguió que me gustase una canción de Take That
4. Are teenage dreams so hard to beat, everytime she walks down the street. Única canción con 28 estrellas en el iTunes de John Peel
5. La voz, en acústico, de la Srta. Furtado, hacen de esta una deliciosa versión.
6. Todo cantando a capella suena mejor. Y se ve mejor
7. Que me perdone el Sr. Cohen, pero esta versión es la mejor que se ha hecho de Hallelujah, y Jeff nos abandonó poco después.
8. Porque no puedo poner Still Alive.
9. Como con casi cualquier canción que cantase Johnny Cash, la canta, y la hace suya.
10. En la versión original (un rap) soy incapaz de seguir la letra. Pero me he resistido a poner la versión a capella.
11. Willian Shatner (sí, el Capitán Kirk) “recita” Common People junto con Joe Jackson y Ben Folds al piano (y algunas voces). The Shat rocks!

Este es un paso opcional, pero como DreamHost a veces mata a los procesos que consumen mucha CPU o memoria, si tenemos otras aplicaciones o páginas web corriendo en DreamHost, y esperamos que nuestra nueva aplicación tenga una carga moderada es recomendable crear otro usuario específico para cada nueva aplicación.

1. Accedemos a la gestión de usuarios del panel de DreamHost.
2. Creamos un nuevo usuario y nos fijaremos que para “Type of User Account” esté seleccionada la opción “Shell”.

Creación del nuevo dominio o subdominio

1. Entraremos en la gestión de dominios del panel de DreamHost.
2. Creamos un nuevo dominio o subdominio.
3. Es muy importante seleccionar el checkbox “Ruby on Rails Passenger (mod_rails)?”.
4. Si en el apartado anterior hemos creado un nuevo usuario lo utilizaremos aquí. En el caso de utilizar un usuario que ya teníamos debemos cerciorarnos de que podemos acceder por SSH con él.
5. En el cuadro de texto “Specify your web directory” aparecerá el nombre de nuestro dominio. Si pensamos utilizar Capistrano para hacer el deploy deberemos añadir al nombre del dominio /current/public. Si no vamos a utilizar Capistrano simplemente añadiremos /public.

En estos momentos DreamHost se pondrá a trabajar y en un tiempo tendremos nuestro nuevo dominio preparado. Si vamos a utilizar Capistrano es importante que accedamos al servidor ahora y borremos el directorio current que DreamHost haya creado (y junto con él, el directorio public que contiene). Capistrano creará estos directorios cuando sea necesario.

Utilizando Capistrano con nuestra aplicación

Voy a suponer que nuestra aplicación Sinatra está en un directorio llamado app, y dentro de él se encuentran el archivo app.rb, que es el archivo principal de nuestra aplicación, y varios directorios (algunos específicos a Sinatra como public y views, y otros que no lo son).

La herramienta de línea de mandatos de Capistrano (cap) busca en el directorio actual un archivo denominado Capfile donde podría encontrarse toda nuestra receta, pero para poder reutilizarla más sencillamente en otros proyectos vamos a crearla en recipes/sinatra.rb. Podéis descargar sinatra.rb y copiarlo a esa carpeta (cambiad la extensión .rbs por .rb).

La receta utiliza la receta original de Capistrano para Rails, por lo que hay muchas tareas que realizan la misma función (adaptadas a Sinatra y mod_rails, claro), y otras que han desaparecido (las de migraciones y las de start y stop).

Finalmente crearemos el archivo Capfile en el directorio raíz de nuestra aplicación con unos contenidos similares a los siguientes:

load 'recipes/sinatra'

# Nombre de nuestra aplicación
set :application, 'app'

# URL de nuestro repositorio.
# Personalmente utilizo Git, por lo que tengo un repositorio justo en
# el directorio de la aplicación.
set :repository, 'file://.'

# El nombre de usuario en el servidor remoto.
# Necesario si no vais a utilizar .ssh/config
set :user, 'usuario'

# Directorio de la máquina remota donde se encontrará la aplicación.
# Atención: sin la parte de current/public.
set :deploy_to, '/home/usuario/www.example.com/'

# El tipo de control de versiones que
# utilizamos (:subversion, :git, :mercurial, …)
set :scm, :git

# (Expecífico para Git) La rama de la que haremos deploy
set :branch, 'master'

# Como el código será descargado en el servidor.
# Personalmente utilizo :copy, que descarga en la máquina local el
# repositorio, lo comprime y lo envía a la máquina remota.
# En la documentación Rdoc de Capistrano se encuentran todas las
# posibilidades y sus opciones.
set :deploy_via, :copy
set :copy_cache, true

# Las URL de cada uno de nuestros servidores y que rol desempeñan.
# Algunas tareas de las recetas solo se ejecutan en para ciertos roles.
# En este caso nuestro servidor tiene dos roles.
role :app, 'www.example.com'
role :web, 'www.example.com'

# DreamHost no nos deja utilizar sudo, así que lo desactivamos.
set :use_sudo, false


Instalando gemas en DreamHost

Para instalar gemas en DreamHost necesitaremos un directorio local para almacenarlas y escribir un par de archivos de configuración:

1. Entramos con SSH a la cuenta del usuario que vaya a ejecutar la aplicación (el que hemos creado en el primer apartado o el que ya existia).
2. Creamos el directorio para las gemas: $ mkdir ~/.gems
3. Editamos el archivo ~/.bash_profile y le añadimos la línea: export GEM_PATH=$HOME/.gems:/usr/local/lib/ruby/gems/1.8
4. Editamos el archivo ~/.gemrc:
   gemhome: /home/usuario/.gems
gempath:
- /home/usuario/.gems
- /usr/local/lib/ruby/gems/1.8
gem: –no-ri –no-rdoc
5. Instaleremos las gemas necesarias, por ejemplo, Sinatra:
   gem install sinatra.

Preparando nuestra aplicación para Passenger

Passenger utiliza Rack para comunicarse como muchos framework Ruby que no sean Rails, por lo que necesitamos crear un archivo config.ru en el directorio raíz de nuestra aplicación que le diga a Passenger como servir nuestra aplicación. El archivo es casi identico al que viene en la documentación de Passenger (hay que felicitarles por tener una documentación tan buena).

# Le decimos a Rubygems donde debe buscar las gemas
ENV['GEM_PATH'] = '/home/usuario/.gems:/usr/local/lib/ruby/gems/1.8'

require 'rubygems'
require 'sinatra'

Sinatra::Application.default_options.merge!(
  :run => false,
  :env => :production
)

require 'app.rb' # Nuestro archivo con la aplicación
run Sinatra.application

Preparando el servidor con Capistrano

En este punto hay que cerciorarse que todos los archivos necesarios están bajo control de versiones, porque nada que no lo esté será copiado al servidor. El archivo de la aplicación app.rb, el archivo config.ru, y los directorios public y views, deberían estar bajo control de versiones.

Para preparar el servidor debemos situarnos en el directorio raíz y ejecutar:

$ cap deploy:setup

Depende de como tengamos configurado nuestro acceso mediante SSH al servidor puede que Capistrano nos pida una contraseña o no (si tenemos la clave pública y privada correctamente configuradas Capistrano no debería pedir contraseñas).

Quizá en este punto sería recomendable comprobar que en el servidor está todo correcto. La estructura de directorios que se debería haber creado es la siguiente:

/home/usuario/www.example.com/
/home/usuario/www.example.com/releases/
/home/usuario/www.example.com/shared/
/home/usuario/www.example.com/shared/system/

Realizando el despliege

Tanto si es el primer deploy, como si es uno de los posteriores lo único que tenemos que hacer para enviar al servidor la nueva versión de nuestro código es lo siguiente:

1. Nos situamos en el directorio raíz de nuestro proyecto.
2. Comprobamos que todos los archivos que queremos enviar están en el repositorio
3. Ejecutamos: $ cap deploy

En este momento se habrá creado un nuevo directorio dentro del directorio releases del servidor, y se habrá creado un enlace simbólico desde current a él.

Si no hay problemas nuestra nueva web con Sinatra debería estar funcionando en nuestro dominio.

Con la posibilidad de utilizar mod_rails/mod_rack/Passenger en DreamHost (mi servicio de hosting) pensé que no estaría mal comprobar que tal funcionaba y a la vez hacer el par de cambios que me apetecían para renovar Wet Floor (por debajo, nada de cara al usuario).

Lo primero ha sido cambiar Camping por Sinatra. No por nada en especial, no creo que uno sea mejor que el otro o al contrario. Si bien es cierto que Camping estaba un poco abandonado, aunque la comunidad parece que había sacado adelante un versión 2.0, me apetecía probar Sinatra, que sí que es más claro que Camping en muchos puntos. Este cambio ha sido sencillo: siendo los dos Ruby, gran cantidad del (poco) código que hace funcionar Wet Floor ha sido copiar y pegar. Con este cambio también he decidido que la generación del HTML y el CSS de las páginas sea mediante Haml & Sass, que cada vez me siguen gustando más (pero que me han demostrado mi temor de que no están pensados para escribir “texto” con HTML, si no más bien sólo estructura HTML).

Lo segundo ha sido utilizar Rack, para poder utilizar Passenger con Sinatra. Creo que esto ha sido lo más sencillo de todo: es increíble que en la propia documentación de Passenger viniera como utilizarlo con Sinatra, y es más, que el código funcionase sin problemas en DreamHost. Utilizar Passenger me ha obligado a cambiar de localización Wet Floor, pero es algo que también tenía en mente (la antigua dirección se encuentra redirigida a la nueva, por lo que no necesitáis actualizar vuestros enlaces).

Lo último (por ahora) ha sido crearme una receta para el deploy con Capistrano, adaptando las recetas de Rails para que funcionasen con Sinatra, Rack y DreamHost. Con esta receta instalar nuevas versiones de Wet Floor es cuestión de un cap deploy e introducir una contraseña. Más sencillo imposible.

Como tarea pendiente me queda reducir el peso de la página. Entre contenido, imágenes y JavaScripts me tarda entre 7 y 10 segundos en terminar de cargar. Mis pensamientos se digiren a cambiar todo el JavaScripts para utilizar jQuery y utilizar versiones “minimizadas” del código en producción.

Bueno, creo que nada más, bienvenidos a el nuevo viejo Wet Floor.

PD: Sí, algo más, supongo que caerá un tutorialcillo de como hacer una aplicación Sinatra en Dreamhost utilizando Passenger y Capistrano, no voy a quedarme la receta sólo para mí.

La interfaz minimalista de Muxtape funciona perfectamente, pero a veces se echan de menos características de las verdaderas aplicaciones de usuario. Por suerte tenemos Fluid.

Lo primer es descargar Fluid de su página web, e instalarlo en nuestra carpeta de Aplicaciones. Cuando lo abrimos Fluid nos presenta una ventana donde debemos introducir ciertos datos.

URL

http://muxtape.com

Name

muxtape (aunque cualquier cosa valdría)

Location

Aplicaciones (o donde prefiráis)

Icon

Recomiendo descargar el icono de la cinta de Cocoa Grove, y utilizar uno de los colores proporcionados (utilizad la versión con extensión .icns para mejores resultados)

Cuando le demos “Create” nos creará la aplicación muxtape en el lugar donde le hemos pedido y nos ofrecerá abrirla. Una vez abierta la aplicación mostrará la página de inicio de Muxtape igual que se vería en Safari. Un pequeño “secreto”: se puede sacar una barra de herramientas y una barra de direcciones con el “botón-pastilla” de la parte superior derecha de la ventana (recuerda volver a picharlo para ocultarla cuando no la vayas a utilizar).

Lo primero que vamos a hacer es instalar un UserScript que nos ofrezca información sobre el MP3 que suena a través de Growl. Para ello abriremos el menú con el icono de un papiro y pincharemos en “Browse Userscripts.org…”. En la barra de direcciones introduce http://userscripts.org/scripts/show/25591 y pincha en el botón “Install this script”.

Ahora vamos a instalar un UserScript que he hecho para añadir tres elementos al menú del icono del Dock para poder reproducir/pausar, saltar a la siguiente y saltar a la anterior canción sin tener que ver la ventana. La dirección es http://userscripts.org/scripts/show/29284.

Si recargamos la página y vamos a una muxtape (por ejemplo podéis probar Tom Waits ate my dog for breakfast, os la recomiendo) podremos ver en el menú contextual del icono del Dock tres entradas para controlar la reproducción. Y gracias al otro script al comenzar la reproducción de un MP3 aparecerá un aviso de Growl y se verá en el badge de icono el número de pista actual. Solo le veo un problema a mi script y es que no puedes ocultar la ventana, ya que en el momento en que la ocultes las entradas del menú desaparecen (creo que es problema de Fluid).

Desconozco el estado actual de Prism, pero no creo que fuera difícil adaptar estas soluciones para ese sistema u otro sistema de generación de Site Specific Browsers.

Nota: Algunas de las ideas de esta entrada las encontré en Pimp My Muxtape (SSB) y Muxtape With Coverflow Using Fluid.

Actualización (2008-06-30): Esta mañana me he dado cuenta de que tanto mi script como el que recomendaba han dejado de funcionar porque el tipo que hace Muxtape ha cambiando su propio JavaScript. Creo que tengo el modo de volver a ponerlo a funcionar, pero tengo que probarlo. Espero tener una versión funcional pronto.

Actualización (2008-06-30): Si volveís a descargar volverán a funcionar los elementos del menú. Era más sencillo de lo que pensaba.

Actualización (2008-06-30): Cuando he terminado de pulir un script para las funcionalidades de mostrar el aviso de Growl y la cuenta de canciones en el Dock, me he puesto a escribir un correo al autor original por si quería utilizarlo. Inmediatamente he recibido un correo que acababa él mismo de publicar una nueva versión Su versión y la mía (la mía es mejor, no utiliza espera activa :D).

¿De donde vienen esas frases?

¡Bienvenidos, humanos!

Inspirada por Logan’s Run.

¡Venimos a visitaros en son de paz y con buena voluntad!

Inspirada por The Day the Earth Stood Still.

Un robot no debe dañar a un ser humano o, por su inacción, dejar que un ser humano sufra daño.

Inspirada por la Primera Ley de la Robótica.

Los robots han visto cosas que vosotros no creeríais.

Inspirada por el dialogo final de Roy Batty en Blade Runner.

Los robots son sus amigos de plástico con quien les gustará estar.

Inspirada en el motto de la compañia Sirius Cybernetics Corporation de la serie de novelas Guía del Autoestopista Galáctico.

Los robots tienen brillantes culos metálicos que no deben ser chupados.

Inspirada en la frase más dicha por Bender en Futurama.

…Y tienen un plan.

Inspirada en las frases al comienzo de Battlestar Galactica.

Por favor, no pulse este botón otra vez

Inspirada, de nuevo, en Guía del Autoestopista Galáctico (aparece al utilizar el botón “Reintentar”).

Jodidas tostadoras

Un lost in translation (aunque también en la serie al emitirse en español) inspirada, de nuevo, en Battlestar Galactica (no aparece en las últimas versiones de la página, pero está ahí).

El único texto de la página que parece no ser una referencia “clara” es el “Reintentar” que muestra el botón por primera vez.

Como curiosidad, en la versión en inglés de la página, el title es “Gort! Klaatu barada nikto!”, otra referencia a The Day the Earth Stood Still, pero desconozco porque la traducción al español la ha eliminado y cambiado por “¡Bienvenidos, humanos!”.

• 4 veces más disco y transferencia (es decir, 2TB y 20TB)
• $150 de descuento en los planes a 5 años
• $200 de descuento en los planes a 10 años

Full disclosure: como “referidos” míos, yo recibo $97 de descuento en mis próximos pagos por cada una de las invitaciones que se utilicen (mi única razón para poner esto aquí).

La verdad es que “atarse” con un hosting a 5 o 10 años es un poco duro, y el caramelo “extra” del disco duro y la transferencia… “creo que 640 KB serán suficientes para cualquiera”. Pero si alguien quiere los códigos que deje un comentario con un correo en el campo de correo electrónico, no en el cuerpo (aviso que no se lo daré a los primeros que pasen, si es que pasa alguien, pero si eres una buena persona no deberías tener problemas en recibir una invitación).

Y para finalizar, las invitaciones se terminan dentro de “2 semanas”, así que supongo que el 24 de Junio dejarán de ser válidas (obviamente dejaré abiertos los comentarios, porque la cantidad de comentarios divertidos que puedo recibir después del plazo es algo que no me quiero perder :)).

Uno de esos Bundles increíbles es TODO, que con un simple ⌃⇧T (quizá la gente de Windows no vea esos caracteres, pero como no van a poder utilizar el editor…) te muestra un lista de archivos donde aparecen ciertos comentarios “estándares” (TODO, FIXME, CHANGE) con enlaces a la línea donde se encuentran.

Además dispone de una pequeña ventana de preferencias donde se pueden crear más “etiquetas&rdquot; y editar las existentes. Personalmente me gusta editarlas un poco, porque, por defecto, no funcionan como deberían.

En el caso de “TODO” y “CHANGED” obligo a que deltante de la etiqueta exista un “límite de palabra” (word bounduary, el símbolo \b). En “FIXME”, además, permito que el “ME” final no sea necesario (hay que introducirlo en unos paréntesis de no-captura, la primera captura la utiliza el Bundle para mostrar el comentario asociado). Las “i” al final de las expresiones regulares hacen que no se tengan en cuenta la capitalización de las letras, se pueden quitar al gusto del usuario.

Por desgracia, al menos para mí, con el Ruby por defecto de Leopard esas expresiones no funcionan para palabras como “método” en archivos codificados en UTF-8.

La única solución que he encontrado para arreglarlo es descargarse el Bundle del repositorio de Subversion e incluir una única línea en un archivo:

$ cd ~/Library/Application\ Support/TextMate/Bundles
$ svn co http://macromates.com/svn/Bundles/trunk/Bundles/TODO.tmbundle
$ mate TODO.tmbundle/Support/todo.rb


Incluir justo debajo de la línea que dice #!/usr/bin/env ruby otra línea que diga $KCODE = 'UTF8'. Salvar y reiniciar TextMate. Todo debería funcionar correctamente (bueno… excepto si pones precisamente “todo” en tu archivo, ver el comentario sobre las “i” más arriba).

PD: El Bundle necesita amor desesperadamente, con un vistazo rápido al código, creo que cada archivo del proyecto se abre (y cierra) una vez por cada “etiqueta” definida. ¿Voluntarios?

Anoche se publicaba el cuarto (y parece ser que último) problema del Google Treasure Hunt 2008 (el cuarto aún está en “competición”, pero se pueden realizar los otros tres anteriores), a eso de la 1.15 de la madrugada por estos lares… y ahí estaba yo (medio dormido, medio despierto) intentando solucionar el dichoso problema. Con lo sencillo que había sido el tercero, si estaba recargando la página cerca de la hora tenía oportunidades de ser el primero en solucionarlo.

Desgraciadamente, cuando me pusieron el problema delante, me dije a mi mismo que “primero ni de coña”. Y eso a pesar de que la solución naïve parece haber sido la más rápida. Pero no voy a poner aquí la solución, aunque puedo ofrecer herramientas para conseguirlo (y explicar mi error).

Ruby dispone de una clase Prime (require 'mathn') como parte de su librería estándar, aunque para desgracia de sus usuarios viene en el mismo archivo que el módulo Rational, que modifica el comportamiento de los enteros de una forma no siempre deseable.

Para realizar algunos problemas de Project Euler (que tengo un poco abandonado) era deseable tener disponible la clase que genere primos y no me tocase el funcionamiento “normal” de los enteros. Por eso la extraje a su propio archivo el código de la clase Prime (con algunos métodos matemáticos más, como un factorial y un binomial eficientes). Sin embargo el código de Prime en las versiones 1.8.x de Ruby es muy poco eficiente, pero por suerte en la versión 1.9 se le ha realizado una limpieza de cara (aunque extrañamente no ha sido backporteado a la reciente 1.8.7).

Sin embargo a la clase Prime de Ruby (incluso a la versión 1.9) le falta un método importante: prime?, para conocer si un número dado es primo o no. Después de buscar un poco encontré que el método comprobación de la de Miller-Rabin es un buen algoritmo para comprobar si un número es primo o no (además parece bastante eficiente). La única pega es que el método devuelve si el número es “probablemente primo” y que puede proporcionar falsos positivos, aunque si entiendo bien de las explicaciones de la página de MathWorld los resultados son correctos hasta números alrededor del 3,4×10¹⁴ (lo que no está nada mal). De cualquier forma se puede modificar la probabilidad cuando se invoca al método, aunque pasar de t = 7 parece no tener beneficios evidentes.

Podéis descargar el código de primes.rb.

Y ahora mi error (realmente estúpido), que ha hecho que en vez de llegar a la solución anoche, llegase esta mañana.

La idea que necesitáis conocer es que llevaba cuenta de unos índices de final y de comienzo, que determinaban que primos participaban en la suma. Estos índices iban aumentando de uno en uno, haciendo que una “ventana” se moviese sobre los primos conocidos. Cuando tocaba avanzar la ventana, la idea era que se eliminaba el primer primo y se incluía el siguiente.

Encontrad las “siete” diferencias:

p = Prime.new
# ...

# Versión incorrecta
suma += Prime.primes[final] - Prime.primes[inicio]
inicio += 1
final += 1
p.succ while Prime.primes.length < final+1

# Versión correcta
final += 1
p.succ while Prime.primes.length < final+1
suma += Prime.primes[final] - Prime.primes[inicio]
inicio += 1