Post

Htaccess. Más mal que bien?

Publicado en Sysadmin el 26 de Mayo de 2010 by Reven | Tags: , ,

Los archivos .htaccess, llamados también “archivos de configuración distribuidos“, son una forma de controlar la configuración de Apache a nivel de cada directorio. Se han hecho terriblemente populares gracias a los servicios de alojamiento compartidos, en los que no es recomendable dar acceso a la configuración de Apache a los usuarios, y por tanto esta es la única forma de que estos la cambien.

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.

Compartir
DiggMenéamedel.icio.usFacebookReddit

t

Éxito

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

Posted 25 de Mayo de 2010 by Reven

Compartir
DiggMenéamedel.icio.usFacebookReddit

t

Hemos puesto nuestra repo en G…

Publicado en Status el 25 de Mayo de 2010 by twitter | Tags:

Hemos puesto nuestra repo en GitHub: http://github.com/nuuve En él publicaremos nuestros proyectos “workshop”.

Compartir
DiggMenéamedel.icio.usFacebookReddit

Post

Los ocho secretos del éxito

Publicado en General el 31 de Marzo de 2010 by Pau | Tags: ,

TED (del inglés Technology, Entertainment, Design) es una organización sin ánimo de lucro que lleva desde 1984 dedicada a difundir las ideas que merezca la pena difundir (como dice su eslogan, “ideas worth spreading”). Entre todo lo que hacen, algo que me tiene especialmente cautivado son las TED Talks: una serie de charlas con expertos en tecnología, sociedad, cultura, política y cosas así que son realmente interesantes.

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?

Compartir
DiggMenéamedel.icio.usFacebookReddit

Post

Filosofía Unix

Publicado en Desarrollo el 30 de Marzo de 2010 by Pau | Tags: ,

No se cómo llegué el otro día a un capítulo del libro The Art of Unix Programming en donde se explican las bases de la filosofía de diseño que sigue Unix. En síntesis, se exponen 17 normas generales que me parecen muy interesantes e importantes. De hecho, no estaría mal que el primer día que pisas una clase de informática te lo pusieran delante…

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…

Compartir
DiggMenéamedel.icio.usFacebookReddit

Post

Convertir todas las tablas InnoDB a MyISAM

Publicado en Bases de datos el 24 de Marzo de 2010 by Pau | Tags: , , , ,

Hace ya unos días se me planteó la necesidad de cambiar el motor de almacenamiento de los datos de todas las tablas de una base de datos (bastante grande) de InnoDB a MyISAM.

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.

Compartir
DiggMenéamedel.icio.usFacebookReddit

Post

Depuración en Ruby on Rails

Publicado en Desarrollo el 5 de Febrero de 2010 by Pau | Tags: ,

En Ruby on Rails sólo las vistas pueden enviar datos formateados a la salida estándar (el documento HTML en este caso), así que en los demás casos la depuración de la aplicación puede llegar a ser algo tediosa. En este artículo vamos a introducir algunos trucos útiles para depurar programas en Ruby on Rails, separándolos según sean aplicables en vistas o controladores.

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.

Compartir
DiggMenéamedel.icio.usFacebookReddit

Post

¿Por qué Ruby on Rails?

Publicado en Desarrollo el 4 de Febrero de 2010 by Pau | Tags:

Uno de nuestros proyectos, sobre el que quizás escribamos próximamente, está siendo desarrollando sobre el framework Ruby on Rails. Pero ¿por qué? Podríamos dar muchos motivos: la legibilidad del código, la generación automática de código, el elevado grado de abstracción que propone, la sencillez de la arquitectura… pero al final, estaríamos hablando de lo mismo: la productividad.

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.

Compartir
DiggMenéamedel.icio.usFacebookReddit

t

Poniendo a punto nuestro blog….

Publicado en Status el 3 de Febrero de 2010 by twitter | Tags:

Poniendo a punto nuestro blog. Empieza la aventura. :D

Compartir
DiggMenéamedel.icio.usFacebookReddit

Post

¡Hola, mundo!

Publicado en Nuuve el 28 de Enero de 2010 by Pau | Tags:

En Nuuve queremos cambiar el mundo cambiando Internet.

Dedicaremos este nuevo espacio a escribir sobre un montón de cosas muy distintas y que, sin embargo, dan forma a nuestro día a día: medios, redes sociales, metodologías, desarrollo, administración de sistemas… en pocas palabras, todos los aspectos que implica el desarrollo de aplicaciones web.

¡Empezamos!

Compartir
DiggMenéamedel.icio.usFacebookReddit