Emili Parreño

Attachment_fu no está preparado para realizar crop de imágenes, así que tendremos que hacerle una pequeña modificación para disponer de esta funcionalidad. Editamos el archivo rmagick_processor.rb, ubicado en el directorio processors, dentro de los archivos del plugin, y cambiamos el siguiente método:

# Performs the actual resizing operation for a thumbnail
def resize_image(img, size)
size = size.first if size.is_a?(Array) && size.length == 1 && !size.first.is_a?(Fixnum)
if size.is_a?(Fixnum) || (size.is_a?(Array) && size.first.is_a?(Fixnum))
size = [size, size] if size.is_a?(Fixnum)
img.crop_resized!(*size)
else
img.change_geometry(size.to_s) { |cols, rows, image| image.crop_resized!(cols, rows) }
end
self.temp_path = write_to_temp_file(img.to_blob)
end


Ahora cuando configuremos los atributos de la imágen en el modelo correspodiente, podemos hacer esto:

has_attachment :content_type => :image,
:storage => :file_system,
:max_size => 500.kilobytes,
:resize_to => '400>',
:thumbnails => { :cropped => ‘50×50!’ }


18-3-2008: Actualizado para Rails 2

Una manera fácil de dar el formato que más nos guste a las fechas es hacerlo una a una utilizando strftime:

<%= post.created_at.strftime("%d-%m-%Y") %>

Eso esta muy bien para formatear un par de fechas, pero para toda una aplicación hay que encontrar un método de hacerlo automáticamente. Para eso creamos un archivo en el directorio config/initializers/ que formaterá las fechas de nuestra aplicación, le podemos poner el nombre que más nos guste, yo siempre utilizo date_format.rb y añadimos:

ActiveSupport::CoreExtensions::Time::Conversions::DATE_FORMATS[:default]='%d-%m-%Y %H:%m'

Con esto convertiremos todas las fechas que aparezcan en las vistas al formato “03-11-2008 22:34″

Si necesitamos varios formatos de fecha podemos hacerlo de la siguiente manera:

ActiveSupport::CoreExtensions::Time::Conversions::DATE_FORMATS.merge!(
:default => >%d.%m.%Y',
:my_format_1 => '%d/%m/%Y - %H:%M',
:my_format_2 => '%l:%M %p, %B %d, %Y',
:my_format_3 => '%d/%m/%Y')

:default es la manera por defecto como se mostrarán las fechas. Las variables my_format_x indican diferentes maneras que utilizaremos para formatear las fechas. Una vez hecho esto, cuando queramos escribir una fecha, lo haremos de la siguiente manera: supongamos un modelo u objeto llamado “Evento”, que en la tabla tiene un campo que se llama “fecha” de tipo DATE, para ver la fecha correctamente escribiremos:

<%=h Evento.fecha.to_s(:my_format_3) %>

Si el campo es DATETIME podemos utilizar el formato 1

<%=h Evento.fecha.to_s(:my_format_1) %>

Si no especificamos nada, utilizará el formato definido en :default

Así­ de fácil!

Esta es una de esas cosas que no se me graban en la memoria, así que lo anoto aquí y a lo mejor le puede servir a alguien.

Cuando queremos añadir algun servicio a init.d para que se inicie cuando arranque la máquina y lo tengamos disponible como demonio, únicamente tenemos que colocar el script de inicio en el directorio /etc/init.d, darle permisos de ejecución y ejecutar:

sudo update-rc.d nombre_del_script defaults

Existe la posibilidad de importar datos de un archivo CSV a una tabla de una base de datos MySQL. El proceso es muy sencillo; lo primero que debemos hacer es guardar el archivo en formato CSV, separando los valores por “;”. También se puede separar una coma, pero hay que tener en cuenta que si el texto de alguno de los campos contiene una coma, el proceso de importación entenderá que ha llegado al final de un campo y pasará al siguiente, con lo cual tendremos la información mal guardada. Es menos probable que encontremos un punto y coma que una coma. Si algún campo contiene estos dos caracteres podemos probar con otro símbolo para marcar la separación entre campos.

Una vez disponemos del archivo CSV entramos en la consola de MySQL desde el directorio donde hayamos guardado el archivo y ejecutamos:

LOAD DATA LOCAL INFILE 'archivo.csv'
INTO TABLE nombre_tabla
FIELDS TERMINATED BY ';'
LINES TERMINATED BY '\n'
(campo1, campo2, campo3);

No es necesario dejar campos en blanco para respetar la estructura de la tabla, el archivo CSV simplemente debe contener los campos que queremos importar y como podéis ver al final se especifica en que campos se debe guardar la información, eso sí, respetando el orden en que están en el archivo de importación.

Cómo cargar las fixtures en el entorno en el que nos encontramos

rake db:fixtures:load

Cómo cargar las fixtures en un entorno diferente al que nos encontramos

rake db:fixtures:load RAILS_ENV=development
rake db:fixtures:load RAILS_ENV=test
rake db:fixtures:load RAILS_ENV=production

Cómo cargar sólo unas determinadas fixtures en la base de datos

rake db:fixtures:load FIXTURES=users,products

Para los que usamo selectores en CSS, Dean Edwards dispone de una libreria en Javascript, ie7.js, que nos permitirá utilizar selectores en Internet Explorer, tanto en el 7 como en el 6. Está es la lista de funcionalidades:

• supports the following CSS selectors:
  • parent > child
  • adjacent + sibling
  • adjacent ~ sibling
  • [attr], [attr=”?value”?], [attr~=”?value”?] etc
  • .multiple.classes (fixes bug)
  • :hover, :active, :focus (for all elements)
  • :first-child, :last-child, only-child, nth-child, nth-last-child
  • :check, :disabled, :enabled
  • :empty, :contains(), :not()
  • :before/:after/content:
  • :lang()
• supports imported style sheets
• preserves the cascade of the style sheet
• does not alter the document structure
• does not repeatedly query the DOM
  tree using JavaScript
• uses pure CSS to enforce style sheet rules
• supports the W3C box model in both standards and quirks mode
• supports fixed positioning (flicker free)
• supports overflow:visible
• supports min/max-width/height
• fixes broken (X)HTML elements (abbr, object)
• standardised forms behavior
• supports PNG alpha transparency
• lightweight script (11KB)
• works for Microsoft Internet Explorer 5+ (Windows only)

Enlaces
Tabla de compatibilidades de selectores CSS con todos los navegadores

1. Si diseño cosas usables, hago Diseño Centrado en el Usuario
   (usabilidad ≠ DCU)
   

   Pues no. El Diseño Centrado en el Usuario consiste en diseñar mediante metodologías que involucren activamente a usuarios reales y futuros en el proceso. Al principio, para investigar necesidades, características y limitaciones; y más tarde para evaluar directamente que el diseño se ajusta a sus requisitos de usabilidad, funcionalidad, etc.
   Diseñar objetos usables es algo muy loable, pero NO ES necesariamente Diseño Centrado en el Usuario.

2. Usabilidad es diseñar algo para que cualquiera pueda usarlo
   (diseño universal ≠ usabilidad)

   No es correcto. La usabilidad es la facilidad de uso que representa un objeto (sistema, interfaz…) para sus usuarios. Y estos no serán, muy probablemente, el mundo entero. Hay aplicaciones que van a ser usadas por un grupo de usuarios inmensamente amplio, y que necesitan de un enfoque universalista. Sin embargo, la mayoría de los sistemas interactivos se hacen para públicos muy específicos. Cuanto más adaptados estén a ellos (y por ende más desadaptados al resto), más usables serán.

(más…)

Esta es la lista de palabras que no puedes utilizar ya que están reservadas por Ruby o Ruby on Rails. Vale la pena tenerla a mano, te ahorrarás algún cabreo que otro.

(más…)

Ayer decidí fulminar el proyecto Webkimia. Para los que no lo conocíais era un Menéame de nuevos proyectos web donde la gente podía promocionar sus creaciones y así empezar a conseguir un poco de difusión. Hacía algún tiempo que no podía estar cada día revisando que pasaba y se ha ido degradando hasta llenarse de spam. Así que he decidido fulminarlo, sin previo aviso.

Voy a utilizar el dominio (no vamos a perder baclinks así como así) para algo que hacía tiempo que me rondaba por la cabeza: un blog sobre diseño y desarrollo web donde publicar artículos, consejos, recetas, enlaces interesantes… inspirándome en Smashing Magazine.

Espero que lo disfruten!

Sólo hay 10 clases de personas: las que saben contar en binario y las que no