Publicidad:
Logo de La Coctelera

mamuso.net

inicio sindicaci;ón

Categoría: herramientas

Composición:

Esta vago-receta necesita de un poquito de preparación. Debemos de instalar la gema w3c_validators. Una vez hecho eso necesitaremos copiar este cachito de código en un archivo Rakefile en la raiz de donde tengamos nuestras maquetas. Si ya tenemos un Rakefile sólo añadiremos la tarea:

 # # Massive html validation task
 # 
 # This rake task comes from the nanoc validation task (http://gist.github.com/8961)
 # Copy this Rakefile to the root of your htmls or add the task to your existing Rakefile 
 # and run:
 # 
 #   rake validate
 # 
 # and that's all :)
 
 task :validate do
 
   require 'w3c_validators'
   include W3CValidators
 
   desc "W3C validation of all the files of the current folder"
   task :validate do
     validate '.html'
     # add validate '.theextensionofyourhtml' to extend this task
   end
 
 
   private
   
   # Colorize your output :) 
   def colorize(text, color_code); "#{color_code}#{text}\e[0m"; end
   def red(text); colorize(text, "\e[31m"); end
   def green(text); colorize(text, "\e[32m"); end
 
   # Validation calling to the w3c_validators methods
   def validate ext
     @validator = (ext == ".css" ? CSSValidator.new : MarkupValidator.new )
 
     files(".", true, ext).each do |file|
       results = @validator.validate_file(file)
       if results.errors.length > 0
           results.errors.each do |err|
             puts "** #{file} => #{red(err)}"
           end
         else
           puts "** #{file} => #{green('Valid!')}"
         end
     end
 
   end
   
   # Stoled from nanoc :) (but with a lot of love)
   def files(dir, recursively, ext = '')
     glob = File.join([dir] + (recursively ? [ "**", "*#{ext}" ] : [ "*#{ext}" ]))
     Dir[glob].reject { |f| File.directory?(f) or f =~ /(~|\.orig|\.rej|\.bak)$/ }
   end
 end
 
  

La última versión y correcciones estarán siempre en este gist.

Si la extensión de los archivos a validar no es .html, no dude en variar la línea de la tarea donde se especifica la extensión o añada tantas líneas como sea necesario (esssto hay que mejorarlo)

Esta vago-receta no usa nanoc ni nada por el estilo. La podemos usar en cualquier carpeta llena de archivitos html.

Indicaciones:

Se indica su uso especialmente en todos aquellos casos en el que necesitemos validar el código y tengamos más de 3 htmls :)

Especialmente recomendable cuando más de un zángano guarrea sobre el código.

Posología:

Vaya hasta la carpeta raiz de su proyecto en un terminal y escriba rake validate tantas veces como sea deseable y usted obtendrá un ouput coloreadito super majo.

Cada validación tarda casi nada, pero cuando hay un buen puñado de htmls necesitamos un poquito de paciencia. Aunque bien mirado siempre es mejor que ir uno por uno.

Contraindicaciones y sobredosis:

Validar constantemente puede convertirte en un pequeño psicópata, úsalo con mesura ;)

Otras presentaciones:

Añadiendo en la tarea un validate ".css" conseguimos validar nuestros estilos. Funciona pero en hojas de estilo enormes saca cositas un poco raras.

  • Tags: , , , , ,
  • compártelo favorito

Hace bastante tiempo intentamos usar nanoc para maquetar proyectos más o menos grandes. Era una versión muy decente, pero que necesitaba madurar. Al mismo tiempo exploramos algún otro mini framework similar como staticmatic, pero estaba todavía menos cocido.

Desde la versión 2 de nanoc el framework se ha convertido en algo bastante sólido, pero además es open souce, es extensible, el código está documentadísimo y su uso también. Si hace mucho que lo probaste tal vez deberías darle una segunda oportunidad.

Vaaale

Está claro, hay métodos más sencillos de hacer html, y que requieren menos conocimientos técnicos, quién no se acuerda de home site.

Tampoco hace falta ser ingeniero aeronáutico para manejar esto. Con tener ruby y rubygems es suficiente para instalarlo y comenzar a trabajar, y hasta ahí llegamos todos.

"Envíeme las maquetas a..."

El clásico include de php nos permite reutilizar gran parte de nuestro código, incluso introducir lógica en nuestra maquetación, nada nuevo. Pero si el sistema nos obliga a tener configurado un host o no funciona si no es bajo un servidor con unas características determinadas (más o menos comunes, eso da igual) sólo nos sirve a nosotros y a nuestro entorno de trabajo cercano.

Con nanoc tenemos las mismas ventajas pero su output es siempre html independiente del framework, de manera que podemos enviar el directorio de salida a cualquiera y lo podrá ver sin obligarle a configurarse nada, como en los viejos tiempos :)

Si son 4 comandos!

Tanto keko como Jose han hablado ya de las maravillas del tutorial de nanoc2 que escribe y actualiza el gran Ale y que nació del tallercito de maquetación ágil que vivimos hace ya casi un año.

No te voy a contar nada que no puedas ver en el tutorial de Ale o en la documentación oficial, de hecho sólo estoy rascando la superficie un poquito.

  • nanoc create_site nombredelsite para crear un proyecto nuevo. Tienes muchísimas posibles combinaciones, pero los valores por defecto nos permiten trabajar estupendamente.
  • nanoc create_layout nombredellayout. Hay un layout por defecto con el que puedes trabajar. Aquí el concepto de layout es también el de partial. Puedes incluir un layout que contenga, por ejemplo, la cabecera de nuestro site en el layout por defeto llamándolo <%= render 'cabecera' %>.
  • nanoc create_page nombredelapagina para crear las páginas. Cada página tiene un yaml en el que le podemos definir filtros, variables a usar...
  • nanoc compile hace lo necesario para juntar layout, páginas, lógica, etc... y meterlo en la carpeta de salida que hayamos definido.

Para no tener que estar compilando el proyecto a cada cambio (sí, yo también soy de los que cambia dos divs y tiene que recargar la página) existe el comando nanoc autocompile, que nos lanza un servidor, por defecto en el puerto 3000, y cada vez que entramos a http://0.0.0.0:3000/nombredelapagina recompila esa página. Este comando no funciona bien en windows al menos en esta versión, puedes ver el html generado, pero muestra las imágenes como corruptas.

Vamos, que son 4 comandos! A cambio tenemos un proyecto mucho más sostenible y hemos reducido al mínimo el impacto de los cambios sobre la maqueta.

Hay varios comandos más, pero con estos ya podrías crearte un site majísimo. ¿Merecería la pena construir una aplicación de ejemplo complejita por entregas?

Big, bigger, biggest

Lo mejor de todo es que podemos dejar nanoc como está e ir extendiendo nuestra aplicación. Lo podemos hacer a base de plugins, que son archivos .rb situados en el directorio lib o bien con rake tasks, en el directorio tasks.

Así que el límite está en tu imaginación, en tu dominio de ruby y tu experiencia con rake.

Por poner un ejemplo. Sería maravilloso que en un proyecto enorme, antes de entregar, tuviésemos una manera de validar de golpe todas las maquetas (y bola extra css).

Lo más fácil sería crear una tareita rake que analizase nuestro output por nosotros. Si copias este validate.rake (*) en tu directorio tasks podrías ir a la raiz de tu proyecto y correr rake validate. En un momentito tooooodo validado :)

(*) en el momento que escribo esto el gist de la tarea rake está fallando, así que puedes verlo aquí.

Esta y otras tareas y plugins las trataremos de colgar (y mantener) en nuestro gist, por si encontráis alguna cosilla que os resulte útil.

Si todavía tienes dudas instálalo, trastea un poquito con cosas nada comprometidas y si no encuentras respuesta a tus dudas siempre puedes unirte a la lista de nanoc en castellano.

Ya le he dado algo de rodaje al plugin y creo que se puede sacar. Toda la explicación de qué es el plugin, para qué, y cómo funciona está en el post anterior, así que no me repito.

Esta release (totalmente beta) la podeis instalar en vuestro mephisto:

Si quereis curiosear código pasaos por este svn (si dreamhost os deja).

Creo que no hace falta decirlo, pero cualquier feedbak será bienvenido.

  • Tags: , ,
  • compártelo favorito

Si eres de los que usa mephisto y te has planteado poner gravatar en tus comentarios, resulta que la cosa es mucho más fácil de lo que parece.

La librería que liquid incorpora por defecto nos permite hacerlo de esta forma tan sencilla. Dentro del bucle de comentarios se pone:

 {{ comment | gravatar:40,'avatarpordefecto.png' }}
 

Es una tontuna, pero es mucho más fácil que hacerlo desde cero (que es lo que me había planteado :) )

  • Tags: ,
  • compártelo favorito

Si te gusta jugar con rails y nunca has probado hpricot (del siempre genial y bizarro whytheluckystiff) te lo recomiendo. En mi caso lo había probado un par de veces, pero para funciones muy básicas.

En este caso vamos a jugar con la opción que tiene para 'arreglar' inputs de html que vengan un poco escacharraillos ¿quién no se ha dejado un div sin cerrar? Pues esta gema nos va a ayudar a dejar el código limpito de verdad.

No descubro nada que no esté en la documentación, pero es que me ha parecido genial.

Cojamos el código a parsear, bien desde un archivo:

doc = Hpricot(open("tudocumento.html"))
 

Bien desde una variable:

doc = Hpricot(param[:mivariable])
 

Tenemos dos opciones. No toques mi código, sólo cierra lo que esté abierto:

doc = Hpricot(mivariable_o_documento) { |f| Hpricot f, :fixup_tags => true }
 

O bien cierra todo lo que esté abierto, y además convierte mi código en xhtml estricto:

doc = Hpricot(mivariable_o_documento) { |f| Hpricot f, :xhtml_strict => true }
 

Problemas, los hay. Cuando te enfrentas a un código (pegado desde word, por ejemplo) con 300 niveles de anidación no es capaz de decir más que 'too much stack levels'. Evidentemente no es el ejemplo más común, para código normal hecho por gente normal y con unos niveles de errores incluso algo bestia funciona.

Me queda comprobar cuánto consume realmente. Es mucho más ligero que otros parsers de html para rails, pero cuando da el 'stack levels' se come tu máquina y la del vecino. Imagino que se podrá controlar pero todavía no se como.

Ahora, para trabajos sencillo es ideal.

  • Tags: , , ,
  • compártelo favorito

Ya anunciamos que venía, y ya está aquí. Mis compis han publicado ya a nivel técnico y a nivel... humorístico.

Y vamos, creo que ya está todo dicho menos que los errores 500 han desaparecido prácticamente por completo.

Ahora, mi todolist para este blog:

  • Volver a postear con normalidad
  • Añadir a mi listita de cocteleros a mr lupión, que lo tengo abandonado
  • Arreglar la css de una vez :D

Disfruten usándola tanto como nosotros haciéndola.

  • Tags: , ,
  • compártelo favorito

Dos cositas que estoy revisando a ratitos libres:

P.D. El blog en estos momentos no se termina de ver bien... ¿por qué? pues por la máxima esa de la casa del herrero y las cucharas de palo :D

  • Tags: , , ,
  • compártelo favorito

Llevo unos días jugando con liquid y me parece una herramienta bastante flexible. Liquid es un motor de vistas para rails con la particularidad de usar un lenguaje extensible con mucha facilidad, de esta manera podemos limitar y controlar el código que se va a insertar en la maqueta.

¿Tiene sentido? Sí cuando no queremos que nadie introduzca en una vista código ‘no deseado’.

El famoso mephisto viene con liquid de serie y es un ejemplo de cómo se usa este plugin: instalamos una aplicación de la que (salvo rarísimas excepciones) no vamos a tocar nada del código de la aplicación y podemos editar y personalizar paquetes de vistas con el marcado de liquid.

Por mi parte creo que el uso de este tipo de plantillas tiene sentido sólo en casos concretos, por ejemplo:

  • Cuando estemos desarrollando una aplicación en la que el cliente se encarga de modificar las vistas
  • Cuando un gran número de usuarios usan una misma aplicación y tienen la posibilidad de editar sus plantillas (¿un sistema de blogs tal vez?)
  • Cuando el maquetador no sepa nada de rails o la maquetación sea un departamento estanco dentro del equipo de trabajo (recordemos que un maquetador no tiene la necesidad de saber programar todo lo que caiga en sus manos, aunque para esto hay todo tipo de opiniones)

Recordemos también que el precio que pagamos por esto es tener que definir muchos métodos que finalmente se acabarán usando en la maqueta. Existen ampliaciones de liquid para mephisto que podemos tomar como base si nos hace falta crear un método y no sabemos por dónde empezar.

En definitiva liquid puede merecer la pena siempre y cuando se vaya a hacer un uso realmente justificado de él, si no creo que exige mucho para conseguir resultados.

Existen en rails otras extensiones (o sustituciones) de las vistas propias de ActionView, como puede ser MasterView o las subplantillas Markaby, pero decidir la adopción de cualquier opción distinta a ActionView nunca va a ser tarea fácil.