Noticias sobre mis proyectos

viernes, 14 de junio de 2013

Tutorial de LD_PRELOAD, segunda parte

man ld.so

Un artículo previo mostraba cómo remplazar una función de la librería estándar de C con una versión personalizada. Esta nota explica lo que es preciso hacer para invocar la función original desde la nueva función.

Comencemos por recordar el ejemplo presentado anteriormente. Todo consistía en un programa llamado prog.c que invocaba la función fopen.


#include <stdio.h>

int main(void) {
    printf("Calling the fopen() function...\n");

    FILE *fd = fopen("test.txt", "r");
    if (!fd) {
        printf("fopen() returned NULL\n");
        return 1;
    }

    printf("fopen() succeeded\n");

    return 0;
}

¿Cómo hacer entonces una función que pueda remplazar a fopen y al mismo tiempo sea capaz de invocar la función fopen de la libraría estándar de C? Veamos el código de myfopen.c.


#define _GNU_SOURCE

#include <stdio.h>
#include <dlfcn.h>

FILE *fopen(const char *path, const char *mode) {
    printf("In our own fopen, opening %s\n", path);

    FILE *(*original_fopen)(const char*, const char*);
    original_fopen = dlsym(RTLD_NEXT, "fopen");
    return (*original_fopen)(path, mode);
}

Como se puede apreciar la librería exporta la versión personaizada de la función fopen. Prestando atención se puede constatar cómo se obtiene la referencia a la función original pasando el símbolo RTLD_NEXT a dlsym. Es muy importante definir el símbolo _GNU_SOURCE para tener acceso a RTLD_NEXT en dlfcn.h. De esta forma se coninua la resolución del símbolo en cuestión en el orden de búsqueda a continuación de la librería actual. La compilamos de la siguiente manera:

$ gcc -Wall -fPIC -shared -o myfopen.so myfopen.c -ldl

Al ejecutar el comando de ejemplo en cuestión con ayuda de la variable de entorno LD_PRELOAD, esto es lo que se obtiene:

$ LD_PRELOAD=./myfopen.so ./prog
Calling the fopen() function...
In our own fopen, opening test.txt
fopen() succeeded

Este truco es realmente útil para cambiar el funcionamiento de partes del sistema o depurar detalladamente ciertos detalles. Le invito a suscribirse mediante RSS para que no se pierda los próximos artículos de esta serie.

jueves, 30 de mayo de 2013

MetaModel y BeanShell propuestos para Apache™ Incubator

Apache™ Incubator

Es posible contabilizar más de 100 proyectos en el ecosistema de la Apache Software Foundation. El Apache™ Incubator es el punto de partida en el camino a convertirse en un proyecto oficial de la fundación. Recientemente se han propuesto dos proyectos interesantes. La primera propuesta que quería mencionar es la de BeanSheall, uno de los lenguajes de programación utilizado para escribir macros en Apache™ Open Office™. Este último ya es un proyecto oficial de la fundación; razón por la cual se podría justificar la incorporación directa a este proyecto en vez de pasar por todo el proceso de incubación. Quizás se justifique más incorporarlo en Apache™ Commons debido a que este proyecto ha estado relacionado con Apache™ Maven y Apache™ JMeter desde hace varios años.

La segunda propuesta es MetaModel; un framework muy interesante que provee una interfaz común para acceso, exploración y consulta de diferentes tipos de fuentes de datos. Entre los objetivos iniciales del proyecto se menciona establecer vínculos con otros proyectos de primer nivel como POI, Gora, HBase y CouchDB. Resulta interesante saber que estas dos tecnologías podrían incorporarse próximamente al ecosistema de la ASF, por lo que les invito a suscribirse mediante RSS a este blog si está interesado en conocer más acerca del futuro de ambos.

miércoles, 29 de mayo de 2013

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

GSoC 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.

lunes, 27 de mayo de 2013

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

KnockoutJs banner

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 />

KnockoutJs tutorial 1

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 …

KnockoutJs tutorial 2

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.

miércoles, 15 de mayo de 2013

Apache™ Bloodhound 0.6 : Bootstrap handlers

Apache™ Bloodhound

Rumbo a la próxima liberación de la versión 0.6 de Apache™ Bloodhound en este artículo comienzo una serie con el objetivo de presentar las diferentes características que marcan pautas con respecto a las versiones precedentes . Explicaré brevemente su utilidad y funcionamiento. Estimo tener tiempo también para redactar algún que otro tutorial . Espero que me perdonen si no logro satisfacer todas las expectativas . Comprendan que todavía hay muchas cosas por hacer y estoy increíblemente ocupado . Tod@s l@s interesad@s en estos temas pueden mantenerse informados del desarrollo de la serie . Solo deben suscribirse mediante RSS .

Hasta el presente la arquitectura que me robó tantas noches de sueño ha probado satisfacer el 95% de los requisitos que se plantearon inicialmente . Para conocer los detalles , empezamos por el principio ...

¿Qué son los bootstrap handlers?

Una aplicación web consta de múltiples funcionalidades , secciones y opciones de navegaciones. Por lo tanto todo framework de desarrollo de aplicaciones web contiene un subsistema que se encarga de seleccionar el componente (e.g. clase) responsable por procesar las peticiones HTTP que se envían hacia el servidor. Trac y por consiguiente Apache™ Bloodhound no son la excepción . En las versiones anteriores (i.e. Bloodhound<0.6 ) el manejo de las peticiones web de ambos gestores de incidencias lo realizaban exactamente las mismas clases exactamente de la misma forma.

En pocas palabras a partir de la versión 0.6 de Apache™ Bloodhound el manejo de peticiones web varía un poco ... y para mejor :) . El siguiente diagrama muestra cómo es que todo esto se lleva a cabo.

Bloodhound bootstrap handlers explained

El primer actor que interviene en el lado del servidor es siempre un servidor web e.g. Apache httpd , Nginx , tracd, ... en fin , cualquier servidor que sea capaz de correr sitios implementados con Python. Posteriormente , de ser necesario, se ubican los frontends (gateways) responsables de adaptar las tecnologías del servidor web (e.g. CGI, FastCGI, ...) al estándar WSGI . En todos los casos se llega a la función trac.web.main.dispatch_request , el punto de entrada del manejo de peticiones web de Trac . Hasta este punto Bloodhound solo introduce cambios menores relacionados con el middleware de autentificación de tracd ; nada en especial.

A partir de este punto aparecen las diferencias . El algoritmo de Trac funciona de la manera siguiente:

  1. Trac determina la configuración de los directorios donde están los environments,
    estableciendo si se corren varios dentro de una misma carpeta o uno solo .
  2. Trata de extraer del camino de la URL el nombre del environment al que va
    dirigido la petición e.g. si la URL fuera http://dominio.com/env/something/else
    entonces el camino de la URL sería /env/something/else y el primer componente
    seria el nombre del environment (env en el ejemplo).
    • En caso de no conseguirlo e.g. si la URL fuera http://dominio.com/
      entonces muestra un índice de los proyectos disponibles.
  3. Se instancia el environment al que va dirigida la petición.
  4. Se crea un objeto del tipo trac.web.api.Request
  5. Se utiliza el resto del camino e.g. /something/else para determinar dentro
    de ese environment la instancia de la interfaz trac.web.api.IRequestHandler
    que es responsable de procesar la petición y dar
    una respuesta al cliente.

En la práctica los pasos (2) , (3) y (4) son un poco limitados . La razón por la cual Apache™ Bloodhound introduce los objetos llamados bootstrap handlers es exactamente poder implementar algoritmos personalizados para realizar estos pasos. Como consecuencia los pasos anteriores varían de la siguiente manera :

  1. Bloodhound determina la configuración de los directorios donde están los environments,
    estableciendo si se corren varios dentro de una misma carpeta o uno solo .
  2. En la variable WSGI trac.bootstrap_handler se busca una
    definición de entry point (e.g. package.module:object.attribute)
    con el módulo y la referencia al objeto bootstrap handler
    • si no se encuentra dicha instancia se utiliza trac.hooks.default_bootstrap_handler
      como valor predeterminado.
  3. Se ejecuta el método open_environment() del objeto determinado en el paso anterior.
    Como resultado se obtiene :
    • El nombre del environment incluído en la variable trac.env_name
      del entorno WSGI
      • Nótese que el procedimiento puede ser completamente diferente a los pasos
        (2) y (3) de la secuencia anterior
    • El environment debidamente inicializado
      • La implementación predeterminada en trac.hooks.default_bootstrap_handler
        analiza el camino de la URL de manera similar a cómo se hace en Trac .
        La diferencia más notoria consiste en el hecho que las que comienzan con
        /products/ se asocian a environments de un producto
        e.g. http://dominio.com/env/products/P1/wiki/TitleIndex se procesaría
        en el contexto del environment del product P1 en el environment env
        mientras que la URL http://dominio.com/env/wiki/TitleIndex es procesada
        por el environment env (global) directamente.
  4. Se ejecuta el método create_request para obtener un objeto
    del tipo trac.web.api.Request o equivalente
  5. Se utiliza el resto del camino e.g. /something/else para determinar
    la instancia de la interfaz trac.web.api.IRequestHandler dentro
    de ese environment que es responsable de procesar la petición y dar
    una respuesta al cliente.

Variantes existentes de bootstrap handlers

El framework Routes , inspirado en Ruby on Rails , se ha convertido en el estándar para este tipo de enrutamiento de peticiones . En un proyecto que será publicado próximamente se están preparando unas variantes que permiten el uso de este framework para implementar bootstrap handlers para Apache™ Bloodhound. De especial interés resultan los casos en que se utiliza el encabezamiento HTTP Host para identificar los environments a partir del dominio al que va dirigida la petición e.g. http://dominio.com/wiki/TitleIndex para el environment global y http://P1.dominio.com/wiki/TitleIndex para el environment del producto P1 . Otro campo de aplicación es la integración con otros frameworks e.g. Pylons , Turbogears 2 , ...

Conclusiones

Apache™ Bloodhound ofrece una versión mejorada del mecanismo que facilitaría tanto despliegues similares a los de Trac como otros basados en sub-dominios , más parecidos al dominio edgewall.org (i.e. babel.edgewall.org, genshi.edgewall.org, trac.edgewall.org) . Todo esto es posible gracias a la arquitectura multi-productos ; que ha probado satisfacer el 95% de los requisitos que se plantearon inicialmente para Apache™ Bloodhound .

Solo me queda invitar a tod@s l@s interesad@s en estos temas a suscribirse mediante RSS a este blog para estar al tanto de las mejoras que propone este gestor de incidencias .

jueves, 25 de abril de 2013

Intermezzo #1

... y entenderás que algo anda mal cuando lo que quieras olvidar sean los momentos felices ; cuando todas las preguntas que importen empiecen con ¿por qué no ...? ; cuando el cubo vacío se te llene de nada hasta que te engorde el orgullo ; cuando a mitad del camino tengas mil pasados y ningún futuro . Pero estarás peor cuando escribas en abril lo que debías decir en agosto porque febrero no existe .

miércoles, 24 de abril de 2013

Breve tutorial sobre LD_PRELOAD

man ld.so

¿Sabía Usted que es posible remplazar por completo las funciones de la librería estándar con copias personalizadas? o.O Este corto artículo trata un tema que, de ser bien utilizado , puede resultar muy poderoso . Podrá conocer lo que se logra con la variable de entorno LD_PRELOAD en GNU/Linux . ¿Qué cosa es ese bicho? No muerde :) . Le invito a seguir leyendo este artículo y suscribirse a este blog mediante RSS para estar informado acerca de temas avanzados de programación y uso de los comandos del shell de los sistemas Unix .

LD_PRELOAD en acción

A modo de ejemplo vamos a cambiar la función fopen y utilizar nuestra propia copia . Lo mismo se puede hacer con otras funciones e.g. printf , scanf , ... Comencemos con un programa simple (prog.c):

#include <stdio.h>

int main(void) {
    printf("Calling the fopen() function...\n");

    FILE *fd = fopen("test.txt","r");
    if (!fd) {
        printf("fopen() returned NULL\n");
        return 1;
    }

    printf("fopen() succeeded\n");

    return 0;
}

En pocas palabras solamente invocamos la función estándar fopen y chequeamos el valor de retorno . Vamos a compilar y ejecutar .

$ ls
prog.c  test.txt

$ gcc prog.c -o prog

$ ls
prog  prog.c  test.txt

$ ./prog
Calling the fopen() function...
fopen() succeeded

Por otra parte compilamos una versión personalizada de la función fopen y la distribuimos por separado :

#include <stdio.h>

FILE *fopen(const char *path, const char *mode) {
    printf("Always failing fopen\n");
    return NULL;
}

Llamamos a este fichero nullfopen.c y lo compilamos como una librería nullfopen.o .

$ gcc -Wall -fPIC -shared -o nullfopen.so nullfopen.c

Ahora ya estamos listos para modificar LD_PRELOAD :

$ LD_PRELOAD=./nullfopen.so ./prog
Calling the fopen() function...
Always failing fopen
fopen() returned NULL

Como se puede constatar se remplazó fopen con una versión que siempre falla . Este truco es muy útil para depurar aplicaciones o remplazar ciertas partes de libc u otra librería que utilice la aplicación . Un uso práctico notable es el comando tsocks , utilizado para dotar las aplicaciones con la capacidad de conectarse a través de un proxy .

Espero tener tiempo pronto y escribir otro artículo acerca de la mecánica interna que hace posible los resultados que se obtienen con la variable LD_PRELOAD . Si está interesado en conocer más acerca de los sistemas Unix le invito a leer otros artículos sobre comandos y suscribirse a este blog mediante RSS para estar al tanto de nuevos temas . Si tiene preguntas no dude en dejar un comentario . Todo es posible simelo pide ...

lunes, 22 de abril de 2013

Cambiando contexto de usuario con sudo y chroot

chroot

Supongamos que desea ejecutar un comando dentro de un chroot como otro usuario. ¿Cómo se hace? En este artículo exploraremos el camino para lograrlo . No es algo evidente . Por tanto iré explicando paso a paso pues lo más importante es familiarizarse con los comandos de los sistemas Unix y entender porqué se hace lo que se hace cuando se hace. Si desea conocer acerca de otros comandos le sugiero leer también otros artículos acerca de comandos Unix . Si este tutorial le resulta interesante le invito a suscribirse a este blog mediante RSS . ¿Listos? ¡ Comenzamos !

Comenzamos echando un vistazo a man chroot . La sinopsis dice que el modo de uso es

$ chroot /new-root-path`

Bien , ya podemos ejecutar un comando dentro de un chroot como root . ¿Cómo hacemos para que cambie de usuario? Para eso está el comando su .

$ chroot /new-root-path su - user

Por ahora todo bien . Ya logramos ejecutar su dentro del chroot como user , pero ... se nos presenta un prompt interactivo . Al leer la documentación de man su la sinopsis dice

$ su - user cmd

¡Perfecto! Combinandolo todo nos queda :

$ chroot /new-root-path su - user sh

Sin embargo todavía nos quedamos dentro de un shell interactivo . ¿Como nos deshacemos del prompt? Al leer man sh aparece la opción sh -c "command args args..." , que lanzará un shell no interactivo y ejecutará el comando con ciertos argumentos . Exaxtmente lo que se buscaba . Combinandolo todo nos queda :

$ chroot /new-root-path su - user sh -c "command args"

Podría parecer que ya está todo bien , pero hay un detalle . Si el usuario tiene un [entorno personalizado] entonces el mismo no se inicializará automáticamente . Hay que hacerlo manualmente .

$ chroot /new-root-path su - user sh -c ". ~/.profile; command args"

Esto hace lo que se pide :

  1. crea un chroot en /new-root-path
  2. ejecuta el comando con ciertos argumentos en ese contexto
  3. devuelve el control a la sesión activa del shell

Pero ... bueno ... como no es aconsejable estar trabajando como root de forma cotidiana , ejecutamos todo esto con sudo

$ sudo chroot /new-root-path su - user sh -c ". ~/.profile; command args"

De esta forma es posible ejecutar ejecutables de fuentes desconocidas y codificar en un entorno seguro .

Si desea conocer otros trucos relacionados con comandos de Unix la inviación esta hecha para que se suscriba a este blog mediante RSS

lunes, 25 de marzo de 2013

Brython migra de Google Code hacia Bitbucket

Brython

Este artículo es fundamentalmente para informarles a los seguidores de este blog que el desarrollo de Brython se ha migrado desde Google Code (i.e. svn) hacia Bitbucket (hg + git) . Pero bueno ... ¿qué es Brython?

Brython está diseñado para remplazar a Javascript como lenguaje de scripts en el lado del cliente . Para nadie es un secreto las límitaciones de este lenguaje que desde mucho tiempo ya domina en el ámbito de los lenguajes de script para los navegadores web . Este es el bloque fundamental para confeccionar la gran mayoría de las páginas web dinámicas. Sin este tipo de lenguajes la Internet sería ... bueno , como al principio . Esto quiere decir no tan divertida y útil como es ahora sino más bien orientada a un grupo reducido de personas con aplicaciones prácticas limitadas . Nada de mapas , ni de chat web , ni de hojas de cálculo , ni ...

Desde un punto de vista un poco más técnico Brython es una implementación de Python 3 adaptado al entorno HTML 5 . En consecuencia ofrece una interface a los objetos y eventos del DOM .

La galería muestra unos cuántos ejemplos , desde la creación de un documento simple hasta funcionalidades más complejas incluyendo drag-and-drop y navegación 3D .

A continuación les muestro el código completo de una página ...

<!doctype html>
<html>
<head>
<meta name="description" content="Brython">
<meta name="keywords" content="Python,Brython">
<meta name="author" content="Pierre Quentel">
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<script src="brython.js"></script>
<title>Brython</title>
<link rel="stylesheet" href="brython.css">
</head>
<body onload="brython()">
<center>
<table id="banner" cellpadding=0 cellspacing=0>
<tr>
<td><a class="banner" href="index.html">Home</a></td>
<td><a class="banner" href="tests/console_en.html">Console</a></td>
<td><a class="banner" href="gallery/gallery_en.html">Gallery</a></td>
<td><a class="banner" href="doc/en/index.html">Documentation</a>
<td><a class="banner" href="https://bitbucket.org/olemis/brython/downloads" target="_blank">Download</a></td>
<td><a class="banner" href="https://bitbucket.org/olemis/brython/src" target="_blank">Development</a></td>
<td><a class="banner" href="groups_en.html" target="_blank">Groups</a></td>
</tr>
</table>
</center>
<div style="text-align:center">
<img src="brython.png"></img><br><b>browser python</b>
</div>

<script type="text/python">
import time
import math
import datetime

sin,cos = math.sin,math.cos
width,height = 250,250 # canvas dimensions
ray = 100 # clock ray

def needle(angle,r1,r2,color="#000000"):
    # draw a needle at specified angle in specified color
    # r1 and r2 are percentages of clock ray
    x1 = width/2-ray*cos(angle)*r1
    y1 = height/2-ray*sin(angle)*r1
    x2 = width/2+ray*cos(angle)*r2
    y2 = height/2+ray*sin(angle)*r2
    ctx.beginPath()
    ctx.strokeStyle = color
    ctx.moveTo(x1,y1)
    ctx.lineTo(x2,y2)
    ctx.stroke()

def set_clock():
    # erase clock
    ctx.beginPath()
    ctx.fillStyle = "#FFF"
    ctx.arc(width/2,height/2,ray*0.89,0,2*math.pi)
    ctx.fill()
    
    # redraw hours
    show_hours()

    # print day
    now = datetime.datetime.now()
    day = now.day
    ctx.font = "bold 14px Arial"
    ctx.textAlign = "center"
    ctx.textBaseline = "middle"
    ctx.fillStyle="#FFF"
    ctx.fillText(day,width*0.7,height*0.5)

    # draw needles for hour, minute, seconds    
    ctx.lineWidth = 3
    hour = now.hour%12 + now.minute/60
    angle = hour*2*math.pi/12 - math.pi/2
    needle(angle,0.05,0.5)
    minute = now.minute
    angle = minute*2*math.pi/60 - math.pi/2
    needle(angle,0.05,0.85)
    ctx.lineWidth = 1
    second = now.second+now.microsecond/1000000
    angle = second*2*math.pi/60 - math.pi/2
    needle(angle,0.05,0.85,"#FF0000") # in red
    
def show_hours():
    ctx.beginPath()
    ctx.arc(width/2,height/2,ray*0.05,0,2*math.pi)
    ctx.fillStyle = "#000"
    ctx.fill()
    for i in range(1,13):
        angle = i*math.pi/6-math.pi/2
        x3 = width/2+ray*cos(angle)*0.75
        y3 = height/2+ray*sin(angle)*0.75
        ctx.font = "20px Arial"
        ctx.textAlign = "center"
        ctx.textBaseline = "middle"
        ctx.fillText(i,x3,y3)
    # cell for day
    ctx.fillStyle = "#000"
    ctx.fillRect(width*0.65,height*0.47,width*0.1,height*0.06)

canvas = doc["clock"]
# draw clock border
if hasattr(canvas,'getContext'):
    ctx = canvas.getContext("2d")
    ctx.beginPath()
    ctx.lineWidth = 10
    ctx.arc(width/2,height/2,ray,0,2*math.pi)
    ctx.stroke()
    
    for i in range(60):
        ctx.lineWidth = 1
        if i%5 == 0:
            ctx.lineWidth = 3
        angle = i*2*math.pi/60 - math.pi/3
        x1 = width/2+ray*cos(angle)
        y1 = height/2+ray*sin(angle)
        x2 = width/2+ray*cos(angle)*0.9
        y2 = height/2+ray*sin(angle)*0.9
        ctx.beginPath()
        ctx.moveTo(x1,y1)
        ctx.lineTo(x2,y2)
        ctx.stroke()
    time.set_interval(set_clock,100)
    show_hours()
else:
    doc['navig_zone'].html = "On Internet Explorer 9 or more, use a Standard rendering engine"
</script>

<p>
<div style="text-align:center;padding-left:15%;padding-right:15%;">
Without a doubt, you've seen a clock like this in demos of HTML5
<p><canvas width="250" height="250" id="clock">
<i>sorry, Brython can't make the demo work on your browser ; 
<br>check if Javascript is turned on
<br><div id="navig_zone"></div></i>
</canvas>
<p>
However, right click and view the source of this page...
<p>It is not Javascript code! Intead, you will find Python code
in a script of type "text/python"
<p>Brython is designed to replace Javascript as the scripting 
language for the Web. As such, it is a Python 3 implementation 
(you can take it for a test drive through a web 
<a href="/tests/console_en.html">console</a>), adapted to
the HTML5 environment, that is to say with an interface to
the DOM objects and events
<p>The <a href="gallery/gallery_en.html">gallery</a> highlights a few 
of the possibilities, from creating simple document elements 
to drag and drop and 3D navigation
</div>
</body>
</html>

... nada de Javascript \o/ .

¿Qué que es lo que hace? Solo use su navegador web preferido y consulte esta página para ver el ejemplo en acción .

Brython @ Bitbucket

¿Por qué la migración hacia Bitbucket? Bueno ... quizás este artículo les proporcione las respuestas . Es sobre Github pero no hay nada más parecido a ese modelo que Bitbucket, con la ventaja de poder tener a git y mercurial en un solo lugar. Google Code se queda un poco atrás .

Por el momento existen dos repositorios

Esperamos que este cambio sea beneficioso para la comunidad ya que todos podrán aportar al proyecto con mayor facilidad. Sus contribuciones serán bienvenidas ... especialmente simelo piden .