El uso de archivos .htaccess se ha extendido hasta el punto de que muchos usuarios creen que deben ser usados para cosas como la autentificación de usuarios o las reglas de re-escritura (Rewrite) de la URL.

Muchos desarrolladores, entre los cuales me incluyo, que luego se pasan a un servidor privado (o VPS) siguen usando los archivos .htaccess indiscriminadamente, sin darse cuenta del golpe que esto supone al rendimiento de Apache, sobre todo teniendo en cuenta que los recursos de esos sistemas suelen ser limitados. La documentación de Apache sobre .htaccess lo deja bien claro:

En general, nunca se deberían utilizar archivos .htaccess cuando se tiene acceso al archivo de configuración principal del servidor.

Apache .htaccess docs

La primera razón para esto, es que cada vez que se le pide un archivo a Apache, éste deberá buscar un archivo .htaccess en ese directorio y los superiores para ver si se aplican reglas adicionales a las que tiene en la configuración principal (la cual se carga una sola vez, al iniciar Apache). Además en el caso de que encuentre el archivo, deberá cargarlo e interpretarlo.

La segunda razón es la seguridad. El archivo de configuración principal suele estar fuera de la raíz del servidor y bien protegido con los permisos adecuados. Los archivos .htaccess son un poco más susceptibles a ataques si la configuración de Apache no es la adecuada y también son más susceptibles a errores que pueden comprometer la seguridad de otros archivos.

No hay ningún ajuste de configuración que no pueda ponerse en el archivo central. Así, los siguientes 2 bloques son equivalentes:

Archivo .htaccess en /www/htdocs/example

RewriteEngine On
RewriteCond %{REQUEST_URI} !/paginavieja.html$
RewriteRule $ /paginanueva.html [R=302,L]

Archivo de configuración principal de Apache:

<Directory /www/htdocs/example>
RewriteEngine On
RewriteCond %{REQUEST_URI} !/paginavieja.html$
RewriteRule $ /paginanueva.html [R=302,L]
</Directory>

Para evitar que Apache siga buscando archivos .htaccess, tendremos que encontrar la directriz AllowOverride en la configuración y cambiarla a lo siguiente:

AllowOverride None

Conseguiremos un incremento de rendimiento notable.

El éxito es algo complicado de definir porque quiere decir cosas distintas para personas distintas. (…) Realmente me encanta lo que hago. Trabajo con gente interesante y divertida. Mi mujer y yo esperamos nuestro primer hijo pronto y puedo trabajar las horas que quiero. Para mí estas cosas son indicadores mucho mejores del éxito de un negocio que cualquier cosa en una hoja de cálculo.

David Greiner, de Campaign Monitor, en una entrevista en svn

Y de todas esas charlas, hay una que me parece útil para recordarnos qué es verdaderamente importante: qué marca la diferencia en nuestras vidas y en nuestras carreras profesionales. Los 8 secretos del éxito, por Richard St. John:

Si el inglés no es lo tuyo, el vídeo dispone de subtítulos en castellano (se pueden activar haciendo clic en “View subtitles”). Interesante, ¿verdad?

Las 17 reglas, en traducción libre, son las siguientes:

1. Regla de la modularidad: escribe partes simples conectadas por interfaces limpias.
2. Regla de la claridad: la claridad es mejor que la astucia.
3. Regla de la composición: diseña programas para que puedan ser conectados a otros programas.
4. Regla de la separación: separa las reglas de los mecanismos: separa las interfaces del procesado.
5. Regla de la simplicidad: diseña para la simplicidad: añade complejidad sólo donde sea necesario.
6. Regla de la parsimonia: escribe un programa complejo sólo cuando esté demostrado que no hay otra solución.
7. Regla de la transparencia: diseña para la visibilidad, para hacer más fácil la inspección y la depuración.
8. Regla de la robustez: la robustez es hija de la transparencia y la simplicidad.
9. Regla de la representación: mantén el conocimiento en los datos, de manera que la lógica del programa pueda ser estúpida y robusta.
10. Regla de la mínima sorpresa: en el diseño de interfaces, busca siempre producir la mínima sorpresa posible.
11. Regla del silencio: si un programa no tiene nada sorprendente que decir, es mejor que no diga nada.
12. Regla de la reparación: si el programa tiene que fallar, que lo haga lo más rápida y ruidosamente posible.
13. Regla de la economía: el tiempo del programador es caro: consérvalo sobre el tiempo de la máquina.
14. Regla de la generación: evita hacer las cosas a mano: siempre que puedas, escribe programas que escriban programas.
15. Regla de la optimización: prototipa antes de perfeccionar: haz que funcione antes de optimizarlo.
16. Regla de la diversidad: desconfía de todo el que diga “es la única forma correcta”.
17. Regla de la extensibilidad: diseña para el futuro, porque estará aquí antes de lo que piensas.

Es para pensar en ello…

Como editar una a una cada tabla de la base de datos no era una opción, me puse a buscar un poco y encontré una solución muy sencilla y flexible en CodeSnippets, que simplemente genera el volcado de las consultas necesarias para convertir las tablas de todas las bases de datos del servidor:

SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name,' engine=MyISAM;') FROM information_schema.tables WHERE engine = 'InnoDB';

Si queremos convertir sólo las tablas de una base de datos en concreto, podemos modificar la consulta anterior y escribir algo así:

SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name,'  engine=MyISAM;') FROM information_schema.tables WHERE engine = 'InnoDB'  and table_schema = 'NOMBRE_DB';

En donde sólo sería necesario sustituir NOMBRE_DB por el nombre de la base de datos cuyas tablas queremos convertir de InnoDB a MyISAM.

Ambas consultas generan únicamente un listado con las consultas necesarias para realizar la conversión, así que para hacer efectiva la misma tendremos, además, que copiar, pegar y ejecutar las consultas resultantes. Próximamente dedicaremos un artículo a valorar las distintas tecnologías de almacenamiento que ofrece MySQL y sus ventajas e inconvenientes.

Vistas

El caso de las vistas es el más sencillo: basta con utilizar la instrucción “debug”. Por ejemplo, en una vista de la clase “Project” podríamos escribir:

<%= debug @project %>

Y obtendremos una descripción del objeto en cuestión en formato YAML como la que sigue:

--- !ruby/object:Project
attributes:
name: Test
created_at: 2010-02-04 16:00:37
updated_at: 2010-02-04 16:00:37
id: "13"
description: This is a project for testing
attributes_cache: {}

Esto mismo puede obtenerse también con una línea como la siguiente:

<%= simple_format @project.to_yaml %>

Controladores

El caso de los controladores es algo más sutil. Podríamos añadir datos a una variable y mostrar el contenido de la misma a través de una vista, pero es mucho más sencillo utilizar el Log de Ruby on Rails. En desarrollo, el log se guarda en el archivo development.log.

Para enviar texto de depuración al log, podemos utilizar el siguiente método:

logger.debug "Texto de depuración"

Para leer el contenido del archivo de logs podemos abrirlo sin más con un editor o con el entorno de desarrollo que estemos utilizando, aunque hay un truco. Si utilizamos Linux o Mac OS, podemos escribir en el Terminal (desde la carpeta de la aplicación):

tail -f log/development.log

Esta instrucción nos mostrará en pantalla el final del archivo, y, lo que es más importante, irá añadiendo a la salida los nuevos mensajes conforme éstos se vayan añadiendo al log. De esta manera podemos hacer un seguimiento más preciso de la ejecución de nuestra aplicación.

Para saber más

La mejor referencia sobre depuración es, evidentemente, la guía oficial de Ruby on Rails. En la guía hay también una explicación muy detallada del uso de ruby-debug, la herramienta de depuración propia de Ruby.

Antes de empezar a escribir este artículo andaba dándole vueltas a lo siguiente: ¿Cómo explicar las ventajas de trabajar con Ruby on Rails a alguien que nunca haya trabajado con Ruby on Rails?. Y creo que he encontrado la respuesta: mostrando el código.

Lo más adecuado, teniendo en cuenta que este framework está enfocado a trabajar bajo el patrón MVC, sería poner un ejemplo relacionado con cada tipo de componente. Creo que, en conjunto, aportan una idea bastante buena de la filosofía del sistema.

Modelos

¿Cómo describir un modelo en Ruby on Rails? Pongamos que tenemos una clase Proyecto (Project), cuyos objetos están vinculados a un directivo (Manager) y a varios hitos (Milestone), y que además deseamos garantizar que el nombre está presente al guardar el objeto. Pues bien, bastaría con algo así:

class Project < ActiveRecord::Base
  has_one :manager
  has_many :milestones

  validates_presence_of :name
end

Por otro lado, necesitaríamos definir el modelo en la base de datos. Para ello, Ruby on Rails, nos proporciona las migraciones (Migrations), que son descripciones abstractas de los modelos de datos que se convierten automáticamente al lenguaje de consultas del sistema gestor que estemos utilizando. Así, uno simplemente especifica algo como:

class CreateProjects < ActiveRecord::Migration
  def self.up
    create_table :projects do |t|
      t.string :name
      t.string :description

      t.timestamps
    end
  end

  def self.down
    drop_table :projects
  end
end

Y es Ruby on Rails el encargado de hacer el “trabajo sucio”. Este enfoque nos permitiría, por ejemplo modificar el motor de la base de datos de nuestro proyecto en cuestión de minutos.

Controladores

Los controladores agrupan métodos que actúan sobre el modelo de datos, sirviendo de intermediarios entre las vistas y el modelo. Su organización es algo más compleja que la de los modelos y las vistas, así que sólo voy a mostrar algunas líneas significativas.

¿Cómo obtener todos los proyectos del sistema?

  @projects = Project.all

¿Y cómo grabar los datos de un nuevo proyecto (“Project”) recibidos desde un formulario? Muy sencillo:

  @project = Project.new(params[:project])
  @project.save

Vistas

Por último, hablemos de las vistas, que en este caso vienen a ser las páginas en HTML que presentan datos y formularios. Por ejemplo, ¿cómo sería el formulario que recogiera los datos del ejemplo anterior?

<% form_for @project do |f| %>
  <%= f.error_messages %>
  <p>
    <%= f.label :name %><br />
    <%= f.text_field :name %>
  </p>
  <p>
    <%= f.label :description %><br />
    <%= f.text_area :description %>
  </p>
  <p>
    <%= f.submit 'Create', :action => 'create' %>
  </p>
<% end %>

¿Te han convencido estos ejemplos? Entonces prueba a darle una oportunidad a Ruby on Rails. No te arrepentirás.