Archivo de la categoría ‘Desarrollo’

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

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