Proyectos de Apache™ Bloodhound en el Google Summer of Code 2013

El 27 de mayo de 2013 es la fecha en que se determinaron las propuestas que se aceptarían como parte del Google Summer of Code. En total este año se han aceptado 1,192 propuestas de proyectos de estudiantes de varias latitudes. Hasta el momento se han confirmado tres proyectos relacionados con ​Apache™ Bloodhound

Los proyectos son :

1. ​Customizable time series reports
   por ​Pranay B. Sudre
   
   • en este caso espero poder estar apoyando el trabajo con fuentes de
     datos que permitan representar las tendencias en líneas de tiempo
     anotadas.
     
2. ​Embeddable tickets/objects por ​Antonia Horincar
   
   • Esta es una oportunidad muy buena para continuar el trabajo de José Angel Franco
     acerca de una API de servicios REST para los recursos de Trac y
     Bloodhound
     
3. ​Add time series reports for Bloodhound por ​Hua Xiang
   
   • mi colaboración en este caso puede ser relativamente similar a la
     del primer proyecto.
     

Le invito a ​suscribirse mediante RSS a este blog si está interesado en conocer los que acontece con estos proyectos. Espero que haya más noticias pronto acerca de ​las propuestas restantes.

PS: Otras organizaciones han propuesto proyectos interesantes como ​este acerca de RTEMS un sistema operativo de tiempo real y código abierto; o ​las propuestas del W3C. Sospecho que hay más detalles en ​la lista completa de proyectos aceptados.

Knockout.js ... lo que Usted no vió

Le dediqué un tiempo a conocer más acerca del patrón ​MVVM . Me agrada, así que se suma a la lista de tecnologías relacionadas con Microsoft que realmente recomiendo. Este es un enfoque propuesto por la compañía que consiste, según sus propios autores, en una especialización del enfoque ​Modelo Vista Controlador para tecnologías como Windows Presentation Foundation y Silverlight. En la ingeniería de software este tipo de soluciones resulta muy útil para construir interfaces de usuario. Su ámbito de aplicación se ha extendido también al ​framework ZK (del cual tengo muy buenas referencias) y a HTML5. Incluso existe ​Google mdv, una variante relacionada con estos temas. En mi caso particular puse mi atención en la implementación para Javascript conocida como ​KnockuotJs. En esta ocasión no pretendo comentarles las peculiaridades de su uso . Para esto les recomiendo leer ​este artículo y la ​documentación de KnockoutJs. Más bien pretendo comentarles algunos detalles que me llamaron la atención al probar los ​tutoriales.

Dependencias y <select />

Al terminar con el primer tutorial debe quedarnos como resultado un modelo más o menos como el que se muestra a continuación.

// This is a simple *viewmodel* - JavaScript that defines the data and behavior of your UI
function AppViewModel() {
    this.firstName = ko.observable("Bert");
    this.lastName = ko.observable("Bertington");

    this.fullName = ko.computed(function() {
        return this.firstName() + " " + this.lastName();    
    }, this);

    this.capitalizeLastName = function() {
        var currentVal = this.lastName();        // Read the current value
        this.lastName(currentVal.toUpperCase()); // Write back a modified value
    };
}

// Activates knockout.js
ko.applyBindings(new AppViewModel());

A continuación se muestra la vista relacionada después de añadir un elemento <select /> conectado con el atributo lastName del modelo.

<!-- This is a *view* - HTML markup that defines the appearance of your UI -->

<p>First name: <strong data-bind="text: firstName">todo</strong></p>
<p>Last name: <strong data-bind="text: lastName">todo</strong></p>
<p>First name: <input data-bind="value: firstName" /></p>
<p>Last name: <input data-bind="value: lastName" /></p>
<p>Full name: <strong data-bind="text: fullName"></strong></p>
<button data-bind="click: capitalizeLastName">Go caps</button>

<p>Last name: 
  <select data-bind="value: lastName" >
      <option value="x">Pérez</option>
      <option>Suárez</option>
      <option value="z">García</option>
      <option>Bertington</option>
      <option>BERTINGTON</option>
  </select>
</p>

En este punto me resultó muy interesante que la librería preserva automáticamente la consistencia del modelo teniendo en cuenta los bindings. Esta es la razón por la cual el botón Go caps solo funciona cuando el apellido es Bertington . La razón es que el binding con el combobox limita el número de valores que se le puede asignar al atributo del modelo. En el ejemplo el valor mencionado es el único que tiene también una opción con las letras mayúsculas.

Las listas y <select /> ... otra vez …

Pasando la página (literalmente ;) llegamos al segundo ejemplo que trata sobre los bindings para listas y colecciones de objetos. Lo que se muestra es impresionante y se completa cada paso satisfactoriamente; pero ... hay (al menos) un detalle muy sutil que se escapa. Utilizando ​Firebug, ​DragonFly o una herramienta similar es posible constatar que el atributo value de los elementos <option /> utilizados para escoger el menú siempre está asignado a una cadena vacía (al menos en las versiones de Opera, Firefox y Google Chrome que utilicé para probar ...). Con el fin de enviar los datos hacia el servidor es posible que sea útil asignar ciertos identificadores. Para lograr ese objetivo en la versión final es posible añadir en el model el atributo mealId

// Class to represent a row in the seat reservations grid
function SeatReservation(name, initialMeal) {
    var self = this;
    self.name = name;
    self.meal = ko.observable(initialMeal);

    self.formattedPrice = ko.computed(function() {
        var price = self.meal().price;
        return price ? "$" + price.toFixed(2) : "None";        
    });
}

// Overall viewmodel for this screen, along with initial state
function ReservationsViewModel() {
    var self = this;

    // Non-editable catalog data - would come from the server
    self.availableMeals = [
        { mealId: "s", mealName: "Standard (sandwich)", price: 0 },
        { mealId: "p", mealName: "Premium (lobster)", price: 34.95 },
        { mealId: "u", mealName: "Ultimate (whole zebra)", price: 290 }
    ];    

    // Editable data
    self.seats = ko.observableArray([
        new SeatReservation("Steve", self.availableMeals[0]),
        new SeatReservation("Bert", self.availableMeals[0])
    ]);

    self.addSeat = function() {
        self.seats.push(new SeatReservation("", self.availableMeals[0]));
    }

    self.removeSeat = function(seat) { self.seats.remove(seat) }

    self.totalSurcharge = ko.computed(function() {
       var total = 0;
       for (var i = 0; i < self.seats().length; i++)
           total += self.seats()[i].meal().price;
       return total;
    });
}

ko.applyBindings(new ReservationsViewModel());

Después es necesario utilizar el binding optionsValue en la vista como se muestra a continuación:

<h2>Your seat reservations</h2>

<button data-bind="click: addSeat">Reserve another seat</button>

<table>
    <thead><tr>
        <th>Passenger name</th><th>Meal</th><th>Surcharge</th><th></th>
    </tr></thead>
    <!-- Todo: Generate table body -->
    <tbody data-bind="foreach: seats">
        <tr>
            <td><input data-bind="value: name" /></td>
            <td><select data-bind="options: $root.availableMeals, value: meal, optionsText: 'mealName', optionsValue: 'mealId'"></select></td>
            <td data-bind="text: formattedPrice"></td>
            <td><a href="#" data-bind="click: $root.removeSeat">Remove</a></td>
        </tr>
    </tbody>
</table>

<h3 data-bind="visible: totalSurcharge() > 0">
    Total surcharge: $<span data-bind="text: totalSurcharge().toFixed(2)"></span>
</h3>

Al aplicar estos cambios se logra generar unos elementos como los siguientes:

<select data-bind="options: $root.availableMeals, value: meal, optionsText: 'mealName', optionsValue: 'mealId'">
  <option value="s">Standard (sandwich)</option>
  <option value="p">Premium (lobster)</option>
  <option value="u">Ultimate (whole zebra)</option>
</select>

¡Urra! ... pero no todo es color de rosa. Como resultado la columna Surcharge deja de actualizarse . Por consiguiente no se muestra el sub-total que se calcula en el último paso. Sin embargo el comando Remove introducido en esa misma etapa sí sigue funcionando. Esto me hace pensar que haya algún problema al calcular alguno de los diferentes tipos de bindings involucrados.

Quizás existe una forma de hacer que vuelvan a funcionar las actualizaciones, pero hasta este momento no la he encontrado. Tampoco he tenido mucho tiempo para profundizar en el tema.

Conclusiones

​KnockuotJs es una librería excelente. Sinceramente preferiría que algunos detalles de los bindings fueran más parecidos al estilo de Genshi. De todas maneras los própositos son diferentes; quizás ni siquiera sea apropiado o posible realizarlo.

Me da la impresión de que no voy a poder dejar de utilizarlo después que lo pruebe en alguna aplicación. La recomiendo. Le invito a ​suscribirse a este blog mediante RSS si desea conocer si descubro algo más en el resto de los tutoriales . En próximos artículos comentaré cómo utilizar esta solución para enriquecer la experiencia de usuario de sus aplicaciones. A pesar de estas pifias los resultados son impresionantes.

TuxInfo 56 : Interfaces de usuario flexibles con AvalonDock

Hace poco tiempo atrás descubrí cómo implementar interfaces de usuario similares a las de entornos de desarrollo como ​Microsoft Visual Studio , ​PyCharm, ​Eclipse, o ​Aptana . De hecho la librería en cuestión es utilizada en el producto ​SharpDevelop . Hemos estado utilizando este tipo de soluciones en aplicaciones que venimos desarrollando desde entonces . Si está interesado en conocer los detalles le invito a ​descargar TuxInfo 56 . En ese número hay ​otros artículos que podrían ser igualemnte de su interés , sobre todo si Usted se interesa en las alternativas de código abierto para sistemas propietarios .

TuxInfo 57 estará lista en los próximos días, al parecer con un nuevo ​formato de dos columnas . Varios artículos interesantes serán publicados allí muy pronto , incluyendo más detalles acerca de las aplicaciones que hemos hecho con ​AvalonDock y que estamos terminando en este momento . Les invito a seguir los ​próximos números de TuxInfo y ​suscribirse a este blog si desea estar al tanto de nuevas noticias acerca del software libre . Usted siempre contará con mi ayuda simelo pide.

Apache™ Bloodhound se gradua como proyecto de la ASF

Todo comenzó con ​una votación inicial en la lista de discusión ​bloodhound-dev@incubator.apache.org y el consecuente ​voto favorable de los ​miembros del IPMC . Hace unas pocas horas en ​un anuncio de Joachim Dreimann se dió a conocer que la junta directiva de la fundación ha decidido aceptar el sistema de gestión de incidencias ​Apache™ Bloodhound como un proyecto oficial. Gary Martin asumirá el rol de VP Apache Bloodhound .

Felicidades Gary . Ha sido un verdadero placer trabajar contigo durante más de un año . Felicidades también a todos los que han contribuido de una forma u otra a que este feliz acontecimiento suceda .

Todo esto ubica a Apache™ Bloodhound a la altura de ​Apache HTTP server , ​OpenOffice.org , ​Tomcat , ​Hadoop , ​Camel , ​CouchDB , ​Subversion ... y muchos , muchos otros sistemas líderes del mercado que ponen de manifiesto las buenas prácticas auspiciadas por la fundación durante sus ya más de diez años de existencia . A continuación les ofrezco más detalles .

Votaciones

Los resultados de las votaciones fueron los siguientes :

bloodhound-dev@…

Andrej Golcov (andrej)	+1	(non-binding)
Branko Čibej (brane, mentor/IPMC)	+1	binding
Gavin McDonald (gmcdonald, PPMC)	+1	binding
Gary Martin (gjm, PPMC)	+1	binding
Joachim Dreimann (jdreimann)	+1	(non-binding)
Jose Angel Franco Navarro	+1	(non-binding)
Jure Žitnik (jure)	+1	(non-binding)
Mark Poole (mpoole, PPMC)	+1	binding
Matevž Bradač (matevz)	+1	(non-binding)
Olemis Lang	+1	(non-binding)
Peter Koželj (peter)	+1	(non-binding)
Ryan Ollos (rjollos)	+1	(non-binding)

general@…

Branko Čibej	+1	binding
Chris Mattmann	+1	binding
Gavin McDonald	+1	binding
Greg Stein	+1	binding
Joachim Dreimann	+1	(non-binding)
Jure Žitnik	+1	(non-binding)
Matevž Bradač	+1	(non-binding)
Ryan Ollos	+1	(non-binding)

Propuesta de miembros para el PMC

Mat Booth	<​mbooth@apache.org>
Matevž Bradač	<​matevz@apache.org>
John Chambers	<​chambej@apache.org>
Branko Čibej	<​brane@apache.org>
Joachim Dreimann	<​jdreimann@apache.org>
Andrej Golcov	<​andrej@apache.org>
Peter Koželj	<​peter@apache.org>
Gary Martin	<​gjm@apache.org>
Gavin McDonald	<​gmcdonald@apache.org>
Ryan Ollos	<​rjollos@apache.org>
Mark Poole	<​mpoole@apache.org>
Greg Stein	<​gstein@apache.org>
Hyrum K. Wright	<​hwright@apache.org>
Jure Žitnik	<​jure@apache.org>

Listo para la versión 0.5.0

Aprovecho la ocasión para mencionar lo más relevante que ha ocurrido en este trimestre con relación al proyecto . En primerísimo lugar para la versión 0.5.0 se ha obtenido un nuevo diseño basado en ​Bootstrap que logra adaptarse a diferentes resoluciones de pantalla . Este es el primer paso con vistas a una orientación marcada hacia el mercado de dispositivos móviles (smartphones , tablets , ...) . En consecuencia se han incorporado ajustes y mejoras en los elementos de navegación del sitio , en la tipografía, las vistas de los tickets , administración y los formularios para adjuntar ficheros .

El explorador del repositorio, pendiente desde hace mucho tiempo, ya viene incorporado. Todos aquellos que ya tenían esta capacidad previamente instalada no tienen porqué preocuparse . Comparado con la versión que le ofrecíamos a nuestros clientes no hay cambios de ningún tipo .

También se han hecho grandes mejoras en el área de la ​búsqueda avanzada después de ser ​introducida en la versión 0.4.0. Ahora se resaltan las palabras clave de la búsqueda, y se mejora la calidad del algoritmo de indexación, entre muchas otras mejoras .

Sobre la infraestructura de la fundación ya hay dos demos en línea \o/. En ​https://bh-demo2.apache.org/ se puede ver la última versión estable (por el momento ​0.4.0) . En ​https://bh-demo1.apache.org se ha desplegado la versión más reciente en el repositorio (i.e. un nightly build basado en HEAD) . Aquí encontrará todo lo que está incluído en la versión 0.5.x y un poco más .

El voto del PPMC para liberar la versión 0.5.x es bastante favorable. Esto quiere decir que muy pronto todo esto estará listo para descarga desde algún servidor de la ASF . Solo que faltan ciertos tecnicismos y trámites burocráticos relacionados con la graduación , etc ... En fin que si Usted quisiera adelantarse, pues, todo esto está ya en el HEAD del ​repositorio. Las ​instrucciones de instalación son bastante precisas y le facilitarán el proceso.

Contribuciones hechas a Trac

Como parte de la implementación de la búsqueda avanzada a partir de ​una petición de un servidor se ha decidido generalizar y unificar el mecanismo de notificaciones de Trac . De esta forma en poco tiempo muy probablemente todas las interfaces de notificación de cambios e.g. ITicketChangeListener, IMilestoneChangeListener, ... serán descontinuadas en favor de una única interfaz IResourceChangeListener . Esto ya es un hecho en la copia que distribuye Apache™ Bloodhound . Los autores de los plugins no deben preocuparse en demasía (por el momento) puesto a que todavía se ofrece compatibilidad con el ramillete de interfaces existentes hasta el momento ... pero por favor , no creen más ninguna :P .

Otro aporte importante ha sido la separación de las instancias de la clase ComponentManager al ser enumerados los puntos de extensión . Sí , así mismo ... un rollo ... por lo que si está interesado en saber más le pido que lea ​este ticket . Esto será incorporado en ​Trac=1.0.2 . A lo mejor escriba alguna nota al respecto en los próximos días .

Perspectivas

Fundamentalmente a corto o mediano plazo hay dos o tres mejoras importantes . En primer lugar el soporte para múltiples productos ya es un hecho . En estos momentos estamos dando los toques finales a la primera versión que estará ya disponible para la ​versión 0.6.0 .

Hace pocos días con vistas a la graduación del proyecto y otros asuntos relacionados estuvimos analizando algunos retos y limitaciones que tiene el despliegue que utilizamos en la ASF . En lo que concierne al control de versiones ​un mensaje de Branko Čibej puso la última gota a un asunto que desde hace tiempo nos viene afectando de forma negativa : la integración del gestor de incidencias con los repositorios gestionados en la infraestructura d la ASF . La solución completa parece estar en torno al ​soporte remoto de repositorios svn y el manejo de hooks a través de ​pubsub . Esta última es una característica que será incluída en ​Subversion 1.8.x pero que desde ya está desplegada en producción en la infraestructura de la ASF . Esta configuración también facilitará otro ​enfoque de trabajo sugerido por Greg Stein , haciendo más énfasis en el repositorio .

Por otra parte hace unos minutos pude leer el ​anuncio de la versión 3.0.4 de ​trachacks:MasterTicketsPlugin y su ​futura integración con Apache™ Bloodhound .

Además de esto en la nevera tenemos otras sorpresas basadas en soluciones que ya hemos desplegado y ofrecido a varios clientes .

Conclusiones

Como siempre , espero que las mejoras sean de su agrado . No dude en comentar acerca de estas propuestas o sugerir mejoras . Todo es posible ... simelo piden .

Apache Bloodhound 0.4.0 listo para descarga

Después de una votación inicial en la lista de difusión ​bloodhound-dev@incubator.apache.org los ​miembros del IPMC han ratificado la decisión de liberar la ​versión 0.4.0 del sistema de gestión de incidencias ​Apache™ Bloodhound . El ​anuncio oficial deja constancia de la aprobación de los siguientes miembros

Branko Čibej	mentor	+1
Greg Stein	mentor	+1
Christian Grobmeier		+1

Una recomendación importante para los despliegues existentes es actualizar el plugin ​ThemeEnginePlugin a la ​versión 2.1.3 o ​superior.

Ahora bien .... ¿qué es lo que incluye la versión 0.4.0?

Edición de tickets in-situ

Como es de esperar esta versión trae nuevas funcionalidades . En primer lugar la interfaz de los tickets se transforma cuando Javascript está habilitado en el navegador de los usuarios. En estos casos , la modificación de sus atributos se realiza a través de un formulario in-situ . Si el cliente no habilita la ejecución de scripts entonces se sigue utilizando la misma sección Modificar ticket que ofrecían las versiones precedentes .

Imagen de marca

Las páginas wiki de la guía de usuario incluídas durante la instalación (e.g. TracStandalone, TracWorkflow, ...) han sido renombradas . Ahora comienzan con el prefijo Guide/ (e.g. Guide/Standalone, Guide/Workflow, ...) . También se han modificado ligeramente los textos de los mensajes de error y algunas partes de las páginas del sitio (e.g. el pie de página) con el fin de facilitar la conformación de una imagen de marca personalizada . Esto es posible mediante la configuración de las opciones application_full , application_short, footer_left_postfix, footer_left_prefix, footer_right en la sección labels del fichero de configuración trac.ini. La siguiente figura ilustra cómo funcionan estas opciones .

Creación rápida de tickets

Hace unas semanas la revista ​TuxInfo publicó su ​número 54 conmemorando sus cinco años de publicación ininterrumpida ( ¡ Felicidades ! ) . En uno de los artículos abordé la solución inicial para especificar la descripción en el formulario de creación rápida de tickets. Ya es posible hacer este tipo de cosas en la versión 0.4.0 , aunque la forma definitiva es un poco diferente a la que expliqué en aquel momento. Además se ofrece la posibilidad de configurar los campos de los tickets que se mostrarán en el formulario, así como el orden en que aparecerán .

Lo que se viene …

Antes de finalizar le dedicaré unas líneas a explicar en qué estamos trabajando en este momento con vistas a la próxima versión .

En primer lugar , es una prioridad completar la arquitectura multi-producto . Me encuentro trabajando actualmente con ​Jure Zitnik en la rama ​bep_0003_multiproduct con vistas a tenerla lista para finales de febrero o principios de marzo , a más tardar (<= suelo ser así de optimista, sí ...) . Hay grandes expectativas alrededor de este tema , ya que es una de las debilidades que siempre se le señala a Trac y por consecuencia Bloodhound .

Como consecuencia de la reciente publicación de las versiones ​1.0.1 y ​1.1.1 de Trac . Muy próximamente se debe decidir cuál de ellas será distribuida con Bloodhound en el futuro inmediato . Por otra parte ​Ryan J. Ollos junto con Steffen Hoffmann preparan otras mejoras en el plugin ​AccountManagerPlugin , una pieza escencial en el funcionamiento de Bloodhound . ​Matevž Bradac y ​Peter Koželj trabajan en mejoras a la interfaz de usuario , especialmente orientadas a que se adapte a las diferentes resoluciones de pantalla (i.e. responsive layout) .

Una de las adiciones más prometedoras en la versión 0.4.0 es la búsqueda avanzada . La misma se desarrolla en paralelo y por el momento se ofrece como una extensión opcional . Aunque es funcional , todavía es una versión inicial . ​Andrej Golcov se encuentra mejorando y añadiendo otros aspectos . Sin embargo, no me detendré a ofrecer muchos más detalles porque este será el asunto que trataré en un artículo que publicaré próximamente .

Pronto habrán dos demos online : uno con la última versión estable y otro con la versión más reciente en el repositorio (i.e. HEAD) . Si está interesado le invito a ​descargar Apache™ Bloodhound 0.4.0 (incubating) , a que lea el próximo número de la revista ​TuxInfo y queden a la espera de una nueva versión con muchas nuevas herramientas . Como siempre , espero que las mejoras sean de su agrado . No dude en comentar acerca de estas propuestas o sugerir mejoras . Todo es posible ... simelo piden .

Google+ Ripples y Diagramas de Flujos, mirando la web desde Google

Recientemente  Google ha cerrado varios servicios  e.g. Google Buzz. Todo parece indicar que los esfuerzos se han dirigido a potenciar otros servicios más establecidos, en gran parte debido al hecho de que han publicado otras nuevas funcionalidades y mejorado las facilidades existentes. Notablemente me llamaron la atención los avances en el área de visualización de datos en gráficas. Hace tiempo ya que estaban disponible varios gráficos complejos como  Intensity Map y  Motion Chart. Sin embargo le sugiero que continue leyendo este artículo si desea estar al tanto de las nuevas ideas hechas realidad por Google. Al menos a mí me impresionaron mucho a medida que las fui descubriendo. Si Usted es de las personas que necesita visualizar datos de maneras suigeneris, le recomiendo  suscribirse mediante RSS para estar al tanto de nuevas noticias sobre este tema.

Patrones de interacciones sociales con Google+ Ripples

 Google+ es una red social de reciente creación. Muchas de sus características todavía están en desarrollo, y ya muestra potencialidades enormes. Tal parece que Google estaba muy al tanto de la respuesta a la pregunta ¿Qué es lo que no le gusta a los usuarios de Facebook?. Más allá de las comparaciones entre ambos sitios sociales, en este contexto se ha creado una de las gráficas más geniales que he visto en mucho tiempo, llamadas  Google+ Ripples. Estos no son más que un grafo que ilustra la historia de publicaciones sucesivas (shares) de un mismo mensaje, enlace, video, o cualquier otro contenido.

Como dicen los que saben una imagen vale más que 1000 palabras. Por eso los invito a observar  10 ejemplos de Ripples célebres. Entre ellos se encuentra la  figura de la Luna por Ron Garan,  la importancia de RSS por Felicia Day y el  post de Sergey Brin acerca de Steve Jobs. Me gustan mucho también  uno que trata acerca de la extensiones populares de Chrome y  este post compartido por Vic Gundotra.

Se pudiera pensar que son garabatos inofensivos, pero los posts más populares pueden llegar a representar tanto tráfico que las distintas ramas toman dimensiones impresionantes y un aspecto muy parecido al de un  fractal. Desde un punto de vista más práctico se pueden utilizar para ver los patrones de distribución y dispersión de las noticias .  Ryan Crowe escribió  un análisis acerca de esta tecnología que trata de presentar la idea de que los Google+ Ripples pueden ser un medio para expandir su alcance e influencia en  Google+.

Diagramas de flujos de visitantes

Las herramientas de análisis de caminos de navegación a través de un sitio han tenido tradicionalmente sus puntos bajos en cuanto a usabilidad se refiere. Por lo general se encuentran más y más tropiezos a medida que se aumenta el nivel de detalles de la segmentación.  Google estuvo al tanto y puso todo su espíritu innovador junto con su probada calidad y experiencia de desarrollo de visualizaciones para crear nuevos enfoques que ilustren el flujo de visitantes. Con el objetivo de lograr que los diagramas sean más intuitivos y útiles recientemente en el  Web 2.0 Summit se ha anunciado que los usuarios de  Google Analytics pueden utilizar los llamados  Flow Visualization.

Este tipo de gráfica es utilizado fundamentalmente de dos formas diferentes. En primer lugar se tiene los Flujos de Visitantes (Visitor Flow). Los mismos representan el flujo de visitantes a través del sitio considerando las fuentes de tráfico (otras dimensiones al parecer también son posibles). De una forma íntegra se puede tener idea de todo el viaje y el punto exacto donde abandonaron el sitio. Este tipo de visualizaciones permite tener idea de la efectividad de decisiones importantes como el uso de una promoción determinada. Hermosas telas de araña ... ¿verdad? ;)

Por otra parte se ofrecen los Flujos de Objetivos (Goal Flow) que son muy parecidos a los anteriores pero consideran en su representación los objetivos de navegación definidos por el usuario del servicio. Inicialmente se pueden utilizar los objetivos definidos por URL , pero próximamente se espera añadir los eventos y otros tipos de objetivos. Su utilidad se puede ejemplificar con el entendimiento de los siguientes aspectos :

• El volumen relativo de visitas hacia el sitio segun la dimensión seleccionada.
• La frecuencia con la que los visitantes abandonan los diferentes caminos de navegación.
• Dónde y cómo los visitantes transitan por cada paso hacia un objetivo definido.
• La forma de las interacciones entre los usuarios y el sitio.

Conclusiones

Desde Google nos llega una nueva ola de buenas ideas. La presión de otros actores en ramas tradicionalmente dominadas por la compañía, e.g.  la combinación Yahoo! + Microsoft , y el cambio de CEO han contribuido al ajuste de su estrategia y la mejora de los servicios de puntería. Las visualizaciones mencionadas son abarcadoras, sintéticas y muy interactivas. Es posible enfocar varios caminos y ver información sobre nodos y conexiones específicas. En pocas palabras, impresionante lo que ha logrado  Google con sus creaciones más recientes.

Le invito a  suscribirse mediante RSS si desea conocer nuevas y útiles formas de visualizar datos . Si Usted conoce alguna otra o tiene alguna opinión que sea de interés, no dude en dejar su comentario; serán bienvenidos.

Google Analytics Blog: Introducing Flow Visualization: visualizing visitor flow

Pentagramas para la web

¿Que tal si se pudiera escribir música en una notación como la que se muestra a continuación y que fuera representada visualmente cómo muestra la figura? Mohit Muthanna ha implementado la noción de pentagrama utilizando el elemento canvas de HTML5 (algo que Internet Explorer no implementará). La versión actual es reciente aún, y todavía necesita un DSL para escribirla. Jono de Mozilla trabajó en un simple DSL basado en texto que resultó muy interesante porque permite hacerlo con solo modificar el texto en un elemento textarea. Si desea conocer los detalles continúe leyendo hasta el final. Le invito a suscribirse mediante RSS si desea estar al tanto de otras noticias del mundo de la informática, y las tecnologías web.

score {
  title: Hip Tune
  artist: Hip Person
  bar { v8 C4 D4 E4 F4 (C4 E4 G4) } 
  bar { v8 C4 D4 E4 F4 (C4 E4 G4) } repeat 3
}
 

La API luce actualmente de la siguiente forma:

function VexNotationDemo1(b) {
    b = new Vex.Music.Artist(b, {
        scale:0.9, width:900
    });
    var c = b.CreateScore(),
        d = b.CreateScore();
    b.DrawScore(c);
    var e = GetBar1(b,c);
    b.DrawBar(e);
    e = GetBar2(b,c);
    b.DrawBar(e);
    e = GetBar3(b,c);
    b.DrawBar(e);
    e = GetBar4(b,c);
    b.DrawBar(e);
    c = GetBar5(b,c);
    b.DrawBar(c);
    b.DrawScore(d);
    c = b.CreateContinuingBarFrom(c,d);
    b.DrawBar(c);
    d = GetBar7(b,d);
    b.DrawBar(d)
}
    
function GetBar4_2(b,c) { 
    c = b.CreateBar(c);
    var d = c.AddLine();
    d.AddNote(b.CreateNote({keys:["f##/4"],duration:"h"}));
    var e = [];
    e.push(b.CreateNote({keys:["a##/4"],duration:"16"}));
    e.push(b.CreateNote({keys:["f##/5"],duration:"16"}));
    e.push(b.CreateNote({keys:["f##/5"],duration:"16"}));
    e.push(b.CreateNote({keys:["f##/5"],duration:"16"}));
    e.push(b.CreateNote({keys:["f#/4","a/4","f/5"],duration:"16"}));
    e.push(b.CreateNote({keys:["f#/4","a/4","f/5"],duration:"16"}));
    d.AddNotes(e);
    e = b.CreateBeam(e);
    d.AddBeam(e);
    e = b.CreateNote({keys:["db/4"],duration:"32"});
    var f = b.CreateNote({keys:["f#/4"],duration:"32"}),
        g = b.CreateNote({keys:["db/4"],duration:"32"}),
        h = b.CreateNote({keys:["f#/4"],duration:"32"});
    d.AddNote(e);
    d.AddNote(f);
    d.AddNote(g);
    d.AddNote(h);
    b = b.CreateBeam([e,f,g,h]);
    d.AddBeam(b);
    return c;
}
 

SVG podría ser también una buena opción para hacer esto. En cualquier caso sería genial tener un control que generara el audio a partir de la partitura, no creen?

Comparación de sistemas de control de versiones (a.k.a.VCS o SCM)

En esta breve entrada quería invitarles a que visiten el sitio http://versioncontrolblog.com , sobre todo si están tratando de decidir cuál sistema de control de versiones utilizarán. Allí es posible ver una tabla que compara las funcionalidades de los sistemas que se seleccionen teniendo en cuenta varios criterios como.

• Commits atómicos
• Soporte para seguir copias de ficheros y carpetas
• Duplicación remota del repositorio
• Control de acceso
• Posibilidad de trabajar en un único sub-directorio
• Interfaz web
• Disponibilidad de interfaces de usuario gráficas
• ... mucho más ...

Espero les sea útil el consejo ;o)

Robots activos para Google Wave: introducción a la versión 2 de la API

Los robots son una parte importante de la API de Google Wave, y se han convertido en una herramienta aún más poderosa. Recientemente Google ha puesto a la disposición de los programadores la versión 2.0 de la API de robots. En esta caso se incluyen varias nuevas prestaciones útiles :

Basado en el anuncio oficial en inglés.

• API de robots activos : En esta versión los robots pueden interactuar con el servicio sin tener que esperar por una acción iniciada por los usuarios. Por tanto se elimina la necesidad de utilizar la API de tareas programadas (a.k.a. cron API, cuyo uso no es recomendado en lo sucesivo), puesto a que se puede actualizar la ola (wave) cuando cambie el estado del tiempo o cuando el precio de las acciones esté por debajo de un límite determinado. Se puede encontrar más información en la documentación de esta API.
• Contexto : Los robots pueden especificar con mayor precisión cuanta información necesitan para reaccionar ante la ocurrencia de un evento. Si solo se necesita modificar el contenido de los blips y es preciso utilizar el ancho de banda eficientemente, entonces se puede especificar el nuevo contexto SELF. Si se necesita conocer toda la información que pueda aportar el contenedor (i.e. wavelet) entonces se puede utilizar el nuevo contexto ALL. Para más información se puede consultar la documentación de los contextos.
• Filtros : De manera similar, con esta nueva versión es posible especificar un subconjunto de todos los eventos disponibles, de acuerdo a las necesidades del robot. El servicio solo notificará estos eventos, por lo que todos los demás pasarán inadvertidos. De esta manera se podrá utilizar racionalmente el ancho de banda. Más información está disponible en la documentación del filtrado de eventos.
• Reportes de errores : Los robots son capaces de indicarle al servicio que desean recibir errores sobre operaciones fallidas. Para más información se puede consultar la documentación de los reportes de error.
• Proxying-For : Los robots pueden indicarle a Google Wave que realizan una acción en nombre de un usuario diferente. Para ello debe utilizarse el campo proxyingFor. En casos como el del robot Buggy, que facilita la integración con el gestor de incidencias de Google Code, esto quiere decir que la ola (wave) puede ser actualizada haciendo referencia a un usuario que realizó la acción original, por lo que puede que no pertenezca al conjunto de cuentas con acceso a Google Wave, sino que abarca usuarios más allá de sus fronteras. Más detalles pueden ser consultados en la documentación de esta funcionalidad

Para comenzar a sacar provecho de estas nuevas características en los robots, se pueden consultar los consejos básicos y es preciso descargar las nuevas librerías para Java y Python. Las mismas están actualizadas con las mejoras hechas al protocolo de base del servicio, cuya especificación ha evolucionado para abrir las puertas a la implementación de librerías similares para otros lenguajes de programación.

Si se desea tener un ejemplo como referencia para mejorar, actualizar o comenzar un nuevo robot; se puede visitar la galería de ejemplos. Allí se pueden encontrar los robots Stocky, Submitty, y Twitter-Searchy, que ilustran el uso de la nueva interfaz de programación.

Finalmente, se experimentará el uso de Google Wave para llevar a cabo las discusiones acerca de la nueva API. Para ello se ha implementado un robot que facilitará las conversaciones. Para conocer más detalles acerca de cómo participar en estos debates se puede consultar esta página.

Google Wave Developer Blog: Introducing Robots API v2: The Rise of Active Robots

Sobrepasa las 1000 descargas el módulo TracGViz (>300 desde PyPI)

Entre los plugins para Trac que he implementado se encuentra TracGViz. Recientemente este módulo ha sobrepasado las 300 descargas desde PyPI. Esto es solo una fracción del total debido a que es posible descargarlo desde Softpedia (518 descargas para Mac y 203 descargas para Linux), o desde WareSeeker (12 descargas). En total serían 1055 descargas considerando las 322 desde PyPI. Pero, quién sabe, quizás hay otros sitios que ofrecen similares facilidades. De todas formas estas cifras (note que solo hablo de la versión 1.3.4 ;o) ya son suficientes para sobrepasar mis expectativas. Para más detalles, por favor lea esta corta entrada y consulte el sitio del proyecto.

Este plugin permite aprovechar los beneficios de la tecnología conocida como Google Visualization API para enriquecer la wiki de Trac con mini aplicaciones de todo tipo. También permite que los datos que se manejan en un proyecto sean visualizados o procesados en sitios web ubicados más allá del dominio del sistema de administración de proyectos. Como efecto secundario se extiende la API de RPC de Trac facilitando acceso (crear, leer, ejecutar) a los reportes, datos acerca del código fuente y sus versiones, más los detalles de los eventos registrados en lo largo de la vida del proyecto.

Actualmente (i.e. hasta la versión 1.3.4) una estimación optimista indicaría que sólo se pueden satisfacer alrededor del 10% por ciento de los casos de uso posibles para esta tecnología de Google. Sin embargo pronto estará lista la versión 1.4.1 y su utilidad aumentará hasta cubrir alrededor de un 80% por ciento, especialmente varias de las tareas más comunes. Las mejoras introducidas aportan nuevas facilidades para los usuarios, permiten utilizar cualquier visualización para mostrar los datos acerca del proyecto y ofrecen nuevas perspectivas de integración con otros sistemas. Varias pruebas demuestran que su funcionamiento es estable.

Una demostración más práctica será presentada próximamente en este blog. Por tanto, mi consejo es que siga los noticias que se publican acá. Espero que les sean útiles ;o).

Ubuntu sustituye GIMP por F-Spot

En el encuentro bienal Ubuntu Developer Summit (UDS) que se llevó a cabo en el mes de noviembre del año 2009 en Dallas, Texas Canonical ha anunciado que removerá el software GNU Image Manipulation Program (a.k.a. GIMP) de la instalación de Ubuntu. Ryan Paul participó en el proceso colaborativo para planificar la futura versión 10.04. De más está decir que para muchos va a ser chocante y controversial, pero hay quienes creen que las razones para hacerlo son válidas. Si continúa leyendo podrá conocer los detalles. ¿Será cierto que esto indica que Ubuntu está madurando como una distribución para usuarios finales?.

¿Cómo funciona el UDS?

Ubuntu sigue un ciclo de desarrollo de seis meses que sigue el ritmo de GNOME. Al principio Canonical organiza eventos que reunen a su propio equipo, miembros de la comunidad y líderes de proyectos de software libre relevantes. En este marco se determina un calendario dirigido a debatir características específicas o detalles técnicos. Los cambios propuestos a la plataforma se describen en páginas conocidas como blueprint y se publican en Launchpad. Durante la confección los participantes toman sus notas con ayuda de Gobby, un editor de texto colaborativo. Por tanto los que deseen participar de forma no presencial pueden consultar este documento y unirse al canal de IRC de la conferencia o a un canal de audio en tiempo real que permite escuchar los debates.

¿Por qué se prescinde de GIMP?

Está de más decir que hablamos sobre una de las aplicaciones paradigmáticas del entorno de escritorio de GNU/Linux, convirtiéndose en una alternativa muy seria para personas con un perfil profesional de procesamiento avanzado de imágenes. Exactamente estas fortalezas son precisamente la causa de su próxima desaparición de la instalación para escritorios del sistema operativo. ¿Contradictorio, no? Pero resulta ser que la gran cantidad de posibilidades que ofrece implica cierta complejidad en la interfaz de usuario y en su uso que se dice que resulta intimidante para los usuarios inexpertos. El tiempo de aprendizaje ambién se estima como elevado, debido a su estructuración en forma de plugins. Como es de esperar, también utiliza una cantidad sustancial de espacio en el disco. Su talla resulta ser especialmente problemática para Ubuntu debido a que el soporte utilizado para su difusión es el CD.

Además se considera que ofrecer una herramienta profesional de edición de imágenes es un objetivo que va más allá de los propósitos de Ubuntu, que prefiere una herramienta simple y ligera para edición de imágenes. En el análisis llevado a cabo no salió a relucir ninguna forma práctica de lograr que GIMP satisficiera ambos requisitos. Los desarrolladores de la herramienta que expresaron su opinión acerca de este tema están de acuerdo con el plan presentado. Resalta Sven Neumann, autor de The GIMP Pocket Reference, quién dijo:

That is pretty much in-line with our product vision. GIMP is a high-end application for professionals. It is not the tool that you would advise every user to use for their casual photo editing,"

Realmente a mí me gusta GIMP, pero de más está decir que no domino ni el 5% de las herramientas que incluye. Quizás haya muchos más como yo, y eso sea una de las motivaciones para dar preferencia a una alternativa más ligera y dejar a un lado opciones de poca utilidad para la gran mayoría de usuarios. Ahora, ¿cuál será la tan añorada herramienta ligera que se distribuirá?

El acertijo del sustituto

No parece que haya una cantidad muy abundante de aplicaciones a considerar para la sustitución. Sin embargo F-Spot ha sido identificado como una de las posibles alternativas más viables para mantenerse en la distribución oficial. Entre sus bondades se encuentran opciones básicas de edición (e.g. recortar y ajustes de color), y efectos simples como corrección de ojos rojos. Sus desventajas son que estas posibilidades se encuentran dentro de su modo de administración y, por tanto, se encuentran junto a otras opciones que nada tienen que ver con el procesamiento de imágenes. Afortunadamente, la reacción ha sido muy positiva. Después de conocer los planes de Canonical, Stéphane Delacroix empleó una hora y media para hacer las modificaciones pertinentes. Poco después fue posible ver en su blog los cambios en F-Spot. Entre sus comentarios encontramos que:

I plugged the main F-Spot editors inside the single view mode. And that worked quite well (...) Of course, F-Spot editors are nowhere close to Gimp's, and don't even aim to. But they cover 90% of your daily usage and are (probably) simpler to use than Gimp. And even more, you can write (read contribute) some additional ones in very few lines of code.

De esta forma se incorporan los editores al área de visualización y esta aplicación se convierte en un serio candidato para el remplazo, a pesar de que todavía faltan ciertas funcionalidades simples. El sistema se vislumbra sólido y parece que es lo suficientemente flexible como para incorporar estas mejoras.

El destino: desde el repo GIMP te mira :o)

Es preciso comprender que esta decisión no implica que nuestro querido GIMP desaparezca de los repositorios de Ubuntu. Lo podremos seguir instalando desde los repositorios sin muchos contratiempos (a no ser que obtener el repositorio sea en sí mismo la mayor parte del problema ...). A pesar de que no será instalado en las nuevas estaciones de trabajo dónde se instale la versión 10.04, el software estará disponible mediante el Ubuntu's Software Center y será distribuido con Ubuntu Studio, un producto derivado que se concentra en aplicaciones para multimedia. Los usuarios actuales no deben preocuparse pues al migrar hacia la nueva versión se mantendrá la copia anterior de GIMP.

Otras decisiones

Otros temas fueron considerados también, entre ellos otros candidatos para sustituir a GIMP. Fueron mencionados Shotwell y GThumb. Otra decisión fue mantener la herramienta EOG y no sustituirla utilizando ... F-Spot. Sin embargo habrá una opción (quizás en un menú ;o) que permitirá editar la imagen directamente utilizando F-Spot.

Otro debate de importancia fue el de la inclusión de una herramienta ligera de edición de video. En este sentido se produjo un debate acerca de añadir Pitivi. Sin embargo, todavía hay ciertas oportunidades para mejorar su madurez y su utilidad, sobre todo considerando que se trata de un LTS. En sentido general se consideró una aplicación muy prometedora, y hubo una respuesta a todas las dudas que tardó muy poco. La adición de Pitivi al ecosistema de Ubuntu contribuye notablemente a medida que los dispositivos handheld con cámaras se hacen más populares.