Publicidad:
Terra
La Coctelera

Mis Tags > ruby

Hay 6 artículos con el tag ruby.

Otros artículos en La Coctelera
clasificados con ruby

Vago-receta: validado masivo de tu html

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.

El día a día con nanoc

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.

Youtube, dame el flv!! (con ruby)

Actualización: Esta técnica ya no funciona, tal vez me anime a actualizarlo. Mientras tanto puedes destripar acts as unvlogable :)


Hola de nuevo! Vuelvo a la carga tras mi temporada de barbecho digital bloguero en la que he hecho en the cocktail cosas tan divertidas y bonitas como la web de mtv españa. Qué voy a decir yo que no haya dicho álvaro.

Ahora a divertirme. Jugando con la api de youtube vemos que podemos conseguir lo básico para poder tirar de su información con nuestra aplicación. Tenemos una gema que nos hace la vida más fácil.

Lo único que no nos devuelve la api de youtube directamente es la url del flv que va a cargar su player. No es que nos valga para muchas cosas, pero en casos concretos nos puede interesar (nah, nada de detalles).

Pongamos el caso de la url este video. La anatomía de la url (http://www.youtube.com/watch?v=0xaX7ZfX054) nos da la id del video, y incluso sin tirar de la gema sabremos que la url del player es http://www.youtube.com/v/0xaX7ZfX054.

La url directa al flv no es tan intuitiva de construir.

http://www.youtube.com/get_video.php?video_id=la sabemos&t=token de youtube a averiguar

Así que con un poquito de ruby (y definiendo un método string.to_hash):

Así con una simple llamada a get_flv('http://www.youtube.com/v/0xaX7ZfX054') nos devolverá la url al flv.

A disfrutar!

Ya ha pasado un tiempecito desde que me decidí a trabajar de forma más profunda con rails. Me tiré un tiempo tonteando con rails y pasé por la fase de alucinar con el scaffold y las aplicaciones en 15 minutos, pero mi día a día estaba muy enfocado a php y no le presté demasiada atención. Fue en la introducción que hicieron blat y álvaro donde me enganché y probé a hacer cosas más grandes basándome en rails. Ahora es casi mi ocupación principal.

En todo este poquito tiempo he ido disfrutando de los detalles que hacen más fácil el trabajo cada día. Los que más me gustan:

  • Modelo - Vista - Controlador: Es una forma de trabajar muy cómoda, y se ha hablado hasta la saciedad de ella, pero la verdad es que cuando pasas de trabajar en php a rails cuesta quitarse el vicio de meter casi toda la lógica en la vista.
  • ActiveRecord: Sin duda es una de las características de rails que más me ha cambiado la vida. En php hacer un simple CRUD es un mini infierno según la cantidad de campos que tengas en la base de datos. Y no te quiero contar nada cuando hay una modificación de la base de datos.
  • Layouts: ActionView ofrece una gestión de layouts estupenda que nos permite trabajar con una sencillez extrema. Es tontísimo, pero de eso se trata :).
  • El render de partials: Como estructura o como patrón de repetición dentro de una página los partials nos permiten ser un poquito más DRY.
  • Observers: Podemos desencadenar mil acciones sólo con cambiar un objeto y todo de forma natural.
  • Se basa en ruby: No soy un experto de ruby, de hecho todavía ando peleándome con el gran tocho en mis ratos muertos, pero es verdad que casi todo se puede escribir de una forma super natural. Y no queda ahí la cosa, el código es de lo más escuálido comparado con (por ejemplo) php. Escribimos menos código, por tanto cometemos menos errores, por tanto… (no me acuerdo cómo seguía la cadena, preguntádselo a Sergio) Ruby mola, no?
  • Extender a base de plugins: La manera en la que rails maneja los plugins facilita mucho la vida a la hora de añadir funcionalidad a un proyecto: desde una autentificación hasta geocodificación.
  • Desarrollar en local: Sin saber demasiado puedes crear tu propio entorno de desarrollo local. Si no sabes o no quieres instalar un server específico y configurarlo siempre puedes tirar de WEBrick que viene de serie.
  • Con AJAX de serie: Viene con multitud de helpers que permiten integrar AJAX en tu aplicación casi sin escribir una sola línea de javascript. El más popular es el linktoremote.
  • Todo es como yo te lo digo… o no: En rails todo se puede redefinir. Por poner un ejemplo, yo tuve que retocar la clase CGI para que interactuase como necesitaba con flash y no supuso ningún trauma.

Vamos… que me gusta rails.

Feeds para dummies

Construir un feed de cualquier contenido en rails (a la MVC y sin addons) es una tarea relativamente fácil. El problema muchas veces viene del desconocimiento de las características concretas de los feeds.

El otro día Sergio sacó el tema de feedtools, una gema para tratamiento de feeds (tanto creación como parseo) de la que había oído hablar pero de la que no había hecho uso.

Con feedtools podemos formar documentos RSS, atom o cdf de forma sencilla sin tener que mirar muchas especificaciones. Simplemente conociendo la anatomía básica de un feed nos basta.

El funcionamiento es sencillo, con una consulta obtenemos todos los post/artículos/noticias que nos hacen falta para la construcción. Y ahora de esta forma tan simple formamos el feed.

 feed = FeedTools::Feed.new
 feed.title = "Título del feed"
 feed.author.name = "Si procede"
 feed.link = "aquí el link"
 
 @misresultados.each do |bloque|
   item = FeedTools::FeedItem.new
 
   item.title = bloque.mititlulo
   item.id = bloque.miid
   item.link = bloque.enlace
   item.content = bloque.cuerpodelenlace
   item.updated = bloque.fecha
   item.summary = bloque.resumen
   item.author.name = bloque.autor
   item.author.href = bloque.urldelautor
 
   feed.items << item
 end
 
 xml = feed.build_xml("atom", 1.0)
 

Tengo que reconocer que yo lo compliqué un poquito más, pero llegó Sergio con las 'rebajas del código' y lo dejó en este cachito enano.

Si lo que queremos hacer es crear el feed como estático y no actualizarlo bajo petición existe la posibilidad de hacerlo con feedupdater, y no parece difícil.

Para cualquier dudilla, a la api!

El ruby logo kit a tu disposición

¿Necesitas el logo de ruby? Pues el equipo de identidad visual de ruby ha creado un kit completito con el logo de ruby a tamaños decentes y en distintos formatos. Mejor que algunos dossiers corporativos que han pasado por mis manos :D

El logo es propiedad del creador del lenguaje Yukihiro Matsumoto y se cede bajo la licencia de creative commons.