Ruido blanco

Creacción de un nuevo usuario en Dreamhost

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.

Ver entradas relacionadas

• Wet Floor se renueva
• Si todo ha ido bien… (y II)
• Rails: moviendo el código al servidor
• Si todo ha ido bien…
• Dreamhost capitula

Según las estadísticas de acceso (cosa que me recuerda que voy a tener que re-activarlas) las páginas más visitadas del dominio son las versiones inglesa y española de Wet Floor (entre las dos acaparan el 44% de las visitas), pero desde que lo publiqué (allá en el lejano 2006) no le he hecho demasiado caso, aunque siempre supe que era lento, lento, lento.

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í.

Ver entradas relacionadas

• Wet floor
• El año ha muerto, viva el año
• High Fidelity

TextMate es un gran editor para Mac que tiene pequeños detalles increíbles escondidos, principalmente entre sus “Bundles&rlquo;.

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?

Ver entradas relacionadas

• Mujeres de la facultad
• Todo el porno a tu alcance
• Buscar en la página
• Por ahora la mejor entrada del concurso de WTF
• LA