Logo de La Coctelera

Categoría: Javascript

Colorea código Ruby, Javascript, HTML y CSS de forma no intrusiva

8 Abr 07

La falta de coloreado de código es, desde que tengo este blog, una de las cosas que más echaba de menos en The-Shaker.

Sin embargo, gracias a Dan Webb, del que soy fan desde la Conferencia Rails de Londres, y a su CodeHighlighter el problema está más o menos resuelto:

por un lado se deben de incluír los ficheros javascript necesarios: uno básico y el resto según los lenguajes que queramos colorear.


 <script type="text/javascript" src="code_highlighter.js"></script>
 <script type="text/javascript" src="javascript.js"></script>
 <script type="text/javascript" src="css.js"></script>
 <script type="text/javascript" src="html.js"></script>
 <script type="text/javascript" src="ruby.js"></script>
 

Posteriormente, a cada bloque de código que queramos colorear le debemos de dar como nombre de clase, el lenguaje en cuestión. Por ejemplo:


 <pre><code class="ruby">
   def foo
     puts "bar"
   end
 </code></pre>
 

Y, por último, debemos de dotar de estilos al HTML al código que queramos colorear. Por ejemplo, mi hoja de estilos es tal que así, aunque la pienso ir ampliando:


 pre {
   border: 1px solid black;
   border-color: #BBB #DDD #DDD #BBB;
   padding: 0.2em 1em;
   line-height: 1.2;
   background: white;
 }
 code {
   font-size: 1.2em;
 }
 .javascript .comment, .ruby .comment {
   color : green;
   font-weight: bold;
 }
 .javascript .string, .ruby .string {
   color : teal;
 }
 .javascript .keywords, .ruby .keywords {
   color : navy;
 }
 .javascript .global {
   color : blue;
 }
 .javascript .brackets, .ruby .brackets {
   color : navy;
 }

De momento colores muy sosos, pero cogiendo los de Textmate, por ejemplo, puede quedar algo más "bonito".

2 comentarios

24 ways vuelven en el 2006

1 Dic 06

24 ways (to impress your friends) es una especie de recopilación con 24 trucos y tutoriales sobre desarrollo web muy actualizados, concretos y bien explicados. Si no recuerdo mal la actualización se realiza diariamente, por lo que día a día, hasta el 24 de diciembre vamos a ir viendo un nuevo post.

El proyecto surgió el año pasado y la verdad que la calidad de los artículos presentados a mí me sorprendió. Los podéis consultar en la edición 2005.

La sorpresa es que han hecho una edición 2006 y han empezado desde cero, con un artículo sobre cómo implementar un slider sobre párrafos de texto (podéis ver la demostración).

En resumen, mucho Javascript, Ajax y CSS para impresionar, no sólo a tus amigos sino a tí mismo.

sin comentarios

Ajax Off-line

11 Nov 06

Zimbra es una suite de comunicación que incorpora mensajería instantánea, correo, calendarios, etcétera vía una interfaz en Ajax que hace que parezca prácticamente una aplicación de escritorio.

Sin embargo, dando una vuelta más de tuerca, los desarrolladores han conseguido tener la misma experiencia de usuario incluso aunque te encuentres desconectado, es decir, un Ajax off-line.

La idea es poder hacer lo mismo que si estuvieras con conexión: interactuar con los elementos de tu aplicación (leer, modificar, eliminar) y que parezca que esta está sincronizada, aunque se encuentre off-line.

El secreto es una caché de objetos sincronizada, que se mantiene en el lado del navegador. La idea, aunque no lo dicen en ningún lado, será que cuando el cliente vuelva a tener conectividad dicha caché se sincronizará con el servidor.

¿Cómo lo han hecho? A mí no me suena que ninguna librería soporte este tipo de almacenamiento del lado del cliente (corregidme si me equivoco, que no soy un experto precisamente), así que posiblmente sea una implementación suya propia.

Un pasito más que demuestra que la interfaz del sistema operativo puede ser web incluso cuando se trate de un ordenador sin conexión.

2 comentarios

Heatmaps en Ruby: determinando las zonas calientes de tu página

17 Ago 06

Es raro ver a un blogger español escribiendo en inglés, y más si es de Ruby, y más aún un post tan desarrollado y bien trabajado.

El caso es que en Corunet han publicado un tutorial para desarrollar un sistema de Heatmaps en tu propio site utilizando Ruby y Javascript: The definitive Heatmap [en].

Un Heatmap (yo lo traduciría por mapa de actividad en lugar del literal mapa de calor) se utiliza para saber qué puntos de una determinada interfaz son más utilizados (marcados en rojo, generalmente) y cuáles menos (marcados en colores más apagados). En este caso la interfaz es una web. Para saber un poco más mira la definición de EyeTracking [en] de la Wikipedia.

Volviendo al post y a implementar nosotros mismos un Heatmap, la idea es utilizar Javascript para realizar el seguimiento de la actividad sobre la web y Ruby y su librería de tratamiento de imágenes ImageMagick para procesar los datos y generar la imagen con las zonas calientes.

Luego sólo falta superponer la imagen obtenida con RMagick sobre la web en cuestión para ver las zonas más y menos populares.

Pero mejor ver su post, que está muy bien y muestra todo el código fuente necesario.

Por cierto, justo el otro día Jesús Encinar habló de una aplicación gratuíta que podemos incorporar en nuestra web para realizar justo los mismo: AdGreed.

6 comentarios

Depurando Javascript con Firebug

14 Ago 06

Firebug es una extensión de Firefox (requiere Firefox 1.5 o siguientes) muy útil para trabajar con HTML, CSS y Javascript. Entre sus virtudes destaca:

  • una consola y un depurador de Javascript, que permite ver incluso las llamadas remotas realizadas vía Ajax
  • un inspector del código HTML y CSS de la página que estés visualizando
  • o la posibilidad de modificar elementos al vuelo (que los modifican localmente, en cuanto recargues seguirá todo como estaba antes)

En concreto, en este post me gustaría comentar cómo se utiliza el depurador de Javascript que viene incluído, y que permite que estemos desarrollando y depurando nuestro código sin tener que utilizar el incómodo alert. Para ello basta saber que Firefug incorpora un objeto Javascript llamado console, el cuál queda instanciado cada vez que cargamos cualquier página.

Dicho objeto tiene una serie de métodos útiles para volcar información en la consola del propio Firebug, mostrando mensajes de distinto tipo: debug, warning, error, fallo o simplemente un mensaje "neutral".

Y como la mejor forma de ver las cosas es con un ejemplo, ahí va uno. Fijáos en el siguiente HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
 
 <html lang="es">
 <head>
   <title>Probando Firefug</title>
   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
 
 </head>
 
 <body>
 <div id="contenido">
 
   <div id="cuerpo">
     <script type="text/javascript">
 
       console.log("console.log");
       console.debug("console.debug");
       console.info("console.info");
       console.warn("console.warn");
       console.error("console.error");
       console.fail("console.fail");
     </script>
   </div>
 
 </div>
 
 </body>
 </html>
 

Se trata de un HTML con código Javascript incrustado, no de la forma más correcta, pero que sirve como ejemplo. En dicho código Javascript hay una serie de llamadas del tipo console.método, donde método son los distintos tipos de mensaje que ofrece el depurador de Firebug.

Si abrís dicha página en Firefox y desplegáis la consola de Firebug veréis algo como esto:

Vamos a analizar con un poco más en detalle cada una de las funciones, según para qué creo que se deberían de utilizar. Aquí debería de aclarar que no he encontrado ninuna documentación oficial del autor al respecto, así que me baso en mi intuición y mi (poco) sentido común:

  • console.log: se debería utilizar cuando queramos mostrar información útil al usuario en la consola, sin que ésta tenga que ser de debugging
  • console.debug: debería mostrar exclusivamente mensajes de debug, exclusivos sólo en desarrollo y en modo depuración, nunca en produción. Nótese que esta función muestra además en qué linea se ha invocado, con lo cuál podemos recuperar el contexto de la llamada en cualquier momento.

A partir de aquí, el resto de llamadas a console creo que están pensadas no para depurar y desarrollar, sino para mostrar información útil al usuario final (una vez la web ya está terminada y en producción), no al programador. Aunque claro, somos libres de utilizarlas para facilitarnos el desarrollo de nuestro código.

Mejor así que matándonos a alert's, ¿no?

Y con esto creo que hay suficiente. En un próximo post me gustaría terminar de repasar las posibilidades que ofrece el objeto console, como un pequeño contador para medir cuánto tarda en ejecutarse determinado código Javascript, y alguna sorpresa más.

sin comentarios