Wilbur Suero

Rants and Ravings

Menu Close

Los 10 principios del buen diseño : Dieter Rams

  • 01. El buen diseño debe ser innovador. Rams establece claramente que es improbable agotar las posibilidades de innovación en el diseño debido a que el desarrollo tecnológico ofrece continuamente nuevas oportunidades para innovar.
  • 02. El buen diseño debe hacer a un producto útil. El objetivo primordial de un producto es su utilidad. Su diseño es primordialmente práctico y de manera secundaria tiene que satisfacer ciertos criterios de carácter psicológico y estético.
  • 03. El buen diseño es estético. El diseño bien ejecutado no carece de belleza.
  • 04. El buen diseño hace a un producto comprensible. Un buen diseño simplifica la estructura del producto y lo predispone a expresar claramente su función mediante la intuición del usuario.
  • 05. El buen diseño es honesto. Un diseño honesto nunca intenta falsificar el auténtico valor e innovación del producto dado. Asimismo, un diseño verdaderamente honesto nunca trata de manipular al consumidor mediante promesas de una utilidad apócrifa, inexistente o más allá de la realidad física del producto.
  • 06. El buen diseño es discreto. Todo producto y su diseño debe de ser simultáneamente neutro y sobrio.
  • 07. El buen diseño tiene una larga vida. Toda moda es inherentemente pasajera y subjetiva. La correcta ejecución del buen diseño da como resultado productos útiles y atemporales.
  • 08. El buen diseño es consecuente en todos sus detalles. Un buen diseño nunca deja nada al azar dado que el cuidado y la exhaustiva precisión de cada detalle expresa el respeto de los diseñadores para con sus consumidores. Cada error es una falta de respeto.
  • 09. El buen diseño respeta el medio ambiente. Un buen diseño debe de contribuir significativamente a la preservación del medio ambiente mediante la conservación de los recursos y la minimización de la contaminación física y visual durante el ciclo de vida del producto.
  • 10. El buen diseño es diseño en su mínima expresión. Dieter Rams subraya la distinción entre el habitual paradigma en diseño:”Menos es más” y en su lugar recomienda su propio modelo: “Menos, pero con mejor ejecución”, destacando el hecho de que este enfoque fomenta los aspectos fundamentales de cada producto y por lo tanto evita lastrarlos torpemente con todo aquello que no es esencial. El resultado ideal es un producto de mayor pureza y simplicidad.

Instalando Node con Homebrew en Mac OS X

Yo soy un fan full de Homebrew y trato de instalar todos los paquetes a través de Homebrew para actualizar, verificar actualizaciones y todo lo demás con los mismos comandos en los mismos directorios. Hace poco comencé a aprender Node.js y pude notar que no es tan sencillo de instalar como la mayoría de los paquetes que uno instala usualmente con Homebrew. Hay una serie de pasos extra que hay que ejecutar para configurarlo y ponerlo a funcionar correctamente, así que decidí poner una guía corta para ayudar a cualquiera que se encuentre con el mismo problema.

Lo primero que voy a asumir es que ya tienes Homebrew instalado. Si no, puedes visitar el website de homebrew para ver como obtenerlo, los comandos, configuraciones, etc … También podrías correr el siguiente script para instalarlo bien rápido.

ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"

Es bueno correr brew doctor para verificar que en el sistema está todo bien.

brew doctor

Homebrew va a mostrar una serie de información, seguro algunas sugerencias, tu puedes elegir si seguirlas o continuar con la instalación.

brew install node

OK, todo muy simple, pero hay un pequeño asunto con instalar Node con Homebrew y es que el Node Package Manager (NPM) no viene con Node desde Homebrew, por tanto debes hacer una serie de pasos extra.

Corre curl para descargar e instalar NPM

curl http://npmjs.org/install.sh | sh

Listo, pero como instalamos Node con Homebrew, debemos apuntar el NODE_PATH al lugar correcto donde encontrar los módulos de Node.

export NODE_PATH="/usr/local/lib/node"

Finalmente debes modificar el $PATH porque los módulos de Node deben ejecutar archivos

export PATH="/usr/local/share/npm/bin:$PATH"

Ahora corre:

echo $PATH

Asegúrate de que “/usr/local/share/npm/bin” se encuentre en la lista de directorios, si está ahí ya estás listo para instalar módulos de Node sin problemas. Yo comencé instalando Express.

sudo npm install -g express

Muchos módulos de Node van a requerir que se instalen con sudo.

Usando Sinatra con SASS

He estado trabajando últimamente mucho con Sinatra y Sass, al mismo tiempo he estado buscando soluciones mas sencillas para automatizar mis procesos de trabajo. Uno de los procesos que hago casi automáticamente es lanzar una consola y escribir …

sass --watch public/css/layout.sass

… funciona correctamente, solo tengo que linkear el archivo css correspondiente y listo.

Pero no funciona tan automáticamente, cada vez que voy a trabajar con ese proyecto tengo que hacer ese proceso y mantener un tab de la terminal abierta mientras esté trabajando con ese archivo. Yo quisiera que el proceso de trabajar con Sass en Sinatra tenga algunas de las funcionalidades que ofrece el Assets Manager en Rails.

Para comenzar tuve que utilizar Sinatra de la forma modular, por eso en el tope del archivo de la aplicación incluí esta línea:

require 'sinatra/base'

Manejando los llamados a los archivos CSS

Tuve que crear una aplicación de Sinatra para manejar las llamadas a los CSS. Cuando haga un request a un archivo CSS directamente, esta aplicación va a leer el archivo .sass con el mismo nombre y va a mostrar el resultado en lugar del CSS que estamos llamando.

class SassHandler < Sinatra::Base
  set :views, File.dirname(__FILE__) + '/templates/sass'

  get '/css/*.css' do
    filename = params[:splat].first
    sass filename.to_sym
  end
end

Línea por línea SassHandler es una clase que hereda de Sinatra::Base por tanto es una aplicación standalone de Sinatra.

En la primera línea configuré esta aplicación para que el directorio donde el va a buscar los views sea templates/sass ahí guardo los archivos Sass y desde ahí la aplicación los va a cargar para convertirlos en CSS.

Luego capturé todas las rutas dirigidas a archivos CSS dentro del folder css, nótese que el parametro del archivo está definido por un Wildcard *. Dentro del bloque tomé el nombre del archivo desde la URL utilizando params[:splat].first.

Luego simplemente se convierte el nombre del archivo en símbolo y se le pasa como parametro a la función de Sass.

Usando el SassHandler y la aplicación

El segundo paso fué crear la aplicación en si.

class MyApp < Sinatra::Base
  use SassHandler

  set :public_dir, File.dirname(__FILE__) + '/public'
  set :views, File.dirname(__FILE__) + '/templates'
  set :root, MyApp.root

  get '/' do
    haml :index
  end

end

Esta vez la clase MyApp es otra aplicación de Sinatra, pero en esta es que vamos a llamar nuestras URL’s como siempre que usamos Sinatra.

Lo primero que hacemos dentro de la clase es incluir la funcionalidad de SassMaster cuando se ejecute nuestra aplicación de Sinatra.

Luego definí algunas configuraciones como donde va a estar el directorio para los archivos públicos (public), el directorio para los views (templates) y cual va a ser el root de la aplicación.

Cuando tuve todo listo, el último paso fué correr la aplicación.

 MyApp::run! if __FILE__ == $0

En el template Haml llamé el CSS de esta manera:

%link{:rel => "stylesheet", :href => "css/layout.css" }

Para llegar a esta solución fue muy importante leer sobre la configuración de una app de Sinatra y sobre Sinatra::Base – Middleware, Libraries, and Modular Apps.

Ruby.do – Devise Authentication

Hoy fué la reunión de Ruby.do con el tema de Devise. El tema fué muy interesante por que casi todas las aplicaciones con Rails llevan de una forma u otra algún método de authentication y el Devise Gem es muy completo y flexible.

La charla la impartió el Sr. Luis Urraca con mucho dominio del tema y con ejemplos que mostraron como con pocas líneas de código podemos tener un sistema de authentication completo y con funcionalidades complejas.

Lo que yo pude entender de la charla fue que:

  • Devise es un gem para authentication para aplicaciones de Ruby on Rails bien flexible y completo.
  • Es una aplicación de Rails en si misma (Engine).
  • Es completamente modular, lo que nos permite utilizar solo las funcionalidades que nos interesan para nuestro proyecto.

Mas Información sobre Devise se puede encontrar en la página del repositorio en Github donde hay algunos ejemplos básicos  sobre como usar Devise. En Railscasts hay un episodio dedicado a introducir Devise.

El 13 de junio hay otra reunión de Ruby.do en el mismo lugar, las oficinas de Pixel Perfect Tree, el link a la invitación para el evento está en Google +

El costo del cambio

Siempre buscamos herramientas que nos ayuden a trabajar mejor, a trabajar mas rápido, a hacer las cosas con menos código, pero, una de las principales razones que debemos tomar en cuenta antes de comenzar a utilizar son las facilidades que nos ofrece cuando cambiemos de idea.

El cambio es parte de todos los proyectos, aunque no esté en los planes, siempre las especificaciones que fueron aceptadas hoy pueden cambiar mañana. Es muy probable que todo lo que pueda cambiar, efectivamente cambie.

Ya que el cambio es inminente, si tenemos procesos muy largos y que involucren muchas cosas, si las herramientas, frameworks o lenguajes de programación que usemos no nos permiten cambiar rápidamente, vamos a incurrir en una deuda tecnológica que va a subir el costo del cambio quizás para el cliente, pero también para el developer. Los resultados a corto y largo plazo le ponen una etiqueta a tu prestigio como profesional y el costo del cambio influye mucho en los resultados que puedes ofrecer.