Las murallas infranqueables de vim

En estos días he tratado de mejorar mis habilidades con vim porque, honestamente, no paso de ser un principiante. Lo digo basado en lo que pude aprender en este video grabado en una conferencia europea de Ruby On Rails. Hay varios mensajes claros. En general es un hecho que el desempeño de un programador aumenta muchísimo a medida que le resulta intuitivo el uso de los diferentes comandos de vi, especialmente si se construye un .vimrc que permita reducir el número de teclas utilizadas para realizar las acciones más comunes. Es por eso que no es una ciencia exacta. Algunas personas hacen ciertas cosas más frecuentemente que otras. Pero esto no basta, hay que coneguirse un buen teclado. Empiezo a pensar que los teclados que traen las computadoras y laptops frecuentemente no son apropiados para los programadores. Interesado en estos temas hice mis búsquedas y descubrí las respuestas de varios misterios.

Las teclas hjkl

Son disímeles las reacciones de las personas cuando conocen que en vi los movimientos del cursor se hacen con las teclas h (izquierda) , j (abajo), k (arriba), l (derecha). Algunos no se explican semejante barbaridad. Otros (casi siempre simpatizantes de Unix y/o GNU/Linux) inicialmente piensan que fue una decisión inteligente para disminuir el desplazamiento de las manos. Puede ser que haya algo de esto, quién sabe. En realidad el caso es que ​Bill Joy creó el editor de textos vi utilizando la ​terminal ADM-3A. Si observan la figura se podrán dar cuenta de que en ese (antiguo) aparato el desplazamiento se hacía con esas teclas. Más allá de que fuera una decisión inteligente o no, el comportamiento de vi fue algo natural (para la época). Después llegó vim y el resto es historia ... ;)

A continuación una foto de cuerpo entero de la terminal dónde se creó vi

A continuación aparece el teclado completo. Fíjense en la posición de la tecla ESC y se darán cuenta de las razones por las cuales se utiliza para cambiar de modo.

La huella de este terminal no parece limitarse a estos hechos. Si se presta atención a la tecla Home en la esquina superior derecha quizás comprendamos porqué es que la carpeta home de los usuarios de Unix (GNU , ...) es referenciada con el símbolo ~.

No son pocos los detalles interesantes relacionados con vi. Es un editor de texto que no deja de sorprenderme. A todos los interesados en conocer todos los secretos de vim les respondo parafraseando ​un poema de Nogueras

(...) vi tiene sus arcanos
vi tiene sus secretos
vi tiene sus «comandos infranqueables» (...)

TuxInfo 61 : Instalando Apache™ Bloodhound 0.7

Unos pocos días atrás se ​anunció el ​número 61 de la revista argentina de software libre ​TuxInfo. Este volúmen incluye mi más reciente artículo acerca de Apache™ Bloodhound titulado Instalando Apache™ Bloodhound 0.7. Estructurado en forma de tutorial explica paso a paso el proceso de instalación de la versión estable más reciente de este sistema de gestión de incidencias prestando atención a los dos motores de bases de datos recomendados: SQLite y PostgreSQL. En próximos espacios repasaré las particularidades del proceso para crear una instancia con MySQL. En mi tiempo libre también confeccionaré más tutoriales acerca de otros temas muy interesantes relacionados con las posibilidades que ofrece el ​soporte multi-producto incluído por primera vez en esta versión, así como las mejoras en la navegación del sitio y las poderosas herramientas que añaden varios plugins que estamos desarrollando en estos momentos. Si estos temas son de su interés le invito a ​suscribirse a este blog y a seguir los desarrollos en ​olemis @ Bitbucket y ​olemis @ Github.

En los últimos dos días se reportan unas 515 descargas de la revista. Todos quieren saber acerca de las noticias más recientes del software libre. No se pierda esta oportunidad de estar actualizado.

​Descarga gratuita de TuxInfo 61

Tengo el inmenso placer de compartir el espacio de la revista con otros colegas que han escrito los siguientes artículos:

• Instalando Apache™ Bloodhound 0.7
  
• DEB Libre – Tus paquetes DEB en un solo lugar
  
• GNU/Linux no es gratuito, es libre
  
• Falcon Pro… y sus trucos
  
• Instalando Google Play en una Coby Kyros
  
• Elementary OS – un GNU/Linux sencillo y elegante
  
• ... y una revisión de una ultrabook Dell XP13 con GNU/Linux.
  

También se comentan noticias como :

• Google y Motorola lanzaron oficialmente el Moto X, el primer smartphone de bandera Google directo.
  
• Debian cumplió 20 años de vida
  
• Ubuntu volvió a apostar por Firefox como navegador preinstalado
  
• Jean-Baptiste Quéru, el máximo responsable de Android Open Source dejó su cargo.
  

Apache™ Bloodhound 0.7 listo para descarga

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

Matevž Bradač	binding	+1
Andrej Golcov	binding	+1
Anze Staric	binding	+1
Jure Zitnik	binding	+1
Olemis Lang	non-binding	+1
Gary Martin	binding	+1

Una recomendación importante para los despliegues existentes es actualizar el plugin ​ThemeEnginePlugin a la ​versión 2.2.1 o ​superior. Para los usuarios de la versión 0.6.0 es muy importante actualizarse a esta nueva versión, pues se han eliminado varios errores importantes. Algunos de ellos están relacionados con fallos detectados al configurar las notificaciones.

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

Productos

Para instalar varios proyectos en Trac es necesario crear varios entornos de administración en carpetas separadas en el sistema de archivos y desplegar varias bases de datos independientes. Los productos de Apache™ Bloodhound permiten lograr resultados similares usando el mismo entorno de administración y compartiendo la base de datos. Cada producto permite asignar permisos para los usuarios y configuraciones de forma independiente.

Hace unas pocas semanas se publicó el sitio ​http://blood-hound.net . El despliegue todavía está en proceso de mejora, pero ya muestra resultados muy alentadores. En primer lugar este caso demuestra que es posible publicar varios productos en varios sub-dominios pero con todos los datos almacenados en una misma base de datos. En este caso cada sub-dominio (i.e. producto) está dedicado a desarrollar un plugin o grupo de paquetes con un fin específico. Se logra así una mayor flexibilidad pues cada uno funciona de forma relativamente independiente pero al mismo tiempo se pueden compartir recursos. Por ejemplo, se puede conectar un mismo repositorio a varios productos. Los usuarios y sus sesiones también son globales. El sistema también facilita mecanismos de búsqueda que ofrecen resultados en múltiples productos.

Todo esto tiene un gran número de implicaciones que trataré de ir explicando poco a poco en este blog.

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 .

Las versiones futuras se verán beneficiadas por las mejoras que se vienen realizando en la infraestructura de pruebas. La idea fundamental es poder ejecutar la suite de pruebas bajo diferentes configuraciones. Como consecuencia se espera mejorar a corto plazo el soporte para otros sistema de bases de datos e.g. MySQL y otros servidores web e.g. nginx. Esto también permitirá detectar rápidamente los fallos que se puedan introducir al hacer cambios y ajustes, evitando así recurrir en los mismos problemas ya detectados.

Plugins desarrollados en blood-hound.net

Uno de los objetivos a corto plazo consiste en mejorar la compatibilidad de los plugins para RPC y autentificación OpenId. Se trabaja también en una solución generíca de visualización y análisis de datos. Todo esto será presentado próximamente en este blog. No dude en ​suscribirse mediante RSS si está interesado en seguir de cerca el desarrollo de Bloodhound y su comunidad.

Conclusiones

Es preciso mencionar que hay dos demos online : el primero desplegado en ​https://bh-demo1.apache.org con la versión más reciente en el repositorio (i.e. nightly build) y el segundo ​https://bh-demo2.apache.org con la última versión estable. Si siente curiosidad Usted puede utilizarlos para familiarizarse con Bloodhound. No hace falta ni registrarse ni tener un usuario. Si después está interesado le invito a ​descargar Apache™ Bloodhound 0.7 , a que lea los próximos números 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 pide .

La estrategia de Oracle en el segundo trimestre del 2013

Al cierre del segundo trimestre del año 2013 ​Oracle está agitado. Repentinamente se han suscitado una serie de eventos que, al menos a mí, me llaman la atención. Sin más preambulos comienzo la historia. Le invito a ​suscribirse a este blog para estar al tanto de otras noticias interesantes acerca del mundo de la informática.

La confrontación en al área del hardware

Este realmente es un capítulo en retrospectiva que permitirá entender mejor la historia (más reciente) que viene a continuación. Después de la ​adquisición de Sun Microsystems Oracle heredó la competencia que esta compañía sostenía con varios rivales en el sector del hardware. Uno de ellos resulta ser ​Hewlett-Packard. En el año 2011 ​Oracle anunciaba descontinuar sus desarrollos para Itanium. De más está decir que Intel y HP hicieron sus declaraciones al respecto ... en fin todo un culebrón. Se rompían así relaciones de negocios y líneas de cooperación que duraron más de 20 años. Este paso era de esperar pues Oracle contaba con la línea de hardware SPARC (RISC). Sun llegó a ser el mayor distribuidor de servidores RISC e Itanium en el mercado Unix con una participación estimada del 41.3% del mercado. Además HP ya en ese momento utilizaba casi toda la gama de procesadores Itanium en sus servidores Integrity Unix , sus soluciones NonStop y OpenVMS. La otra cara de la moneda era que las aplicaciones de Oracle eran el software más frecuentemente utilizado en la plataforma HP-UX (Unix). Este sistema operativo también era otro motivo de competencia con las soluciones basadas en Linux y Solaris que otrora fueron el motivo de otra disputa entre Sun y HP por la definición del futuro de Unix.

La historia continúa. Mark Hurd ex-CEO de HP fue contratado para el cargo de Presidente de Oracle. En los primeros días de junio de este año se presentó en el ​Dell Enterprise Forum para anunciar la alianza estratégica con ​Dell. El pacto consiste en llevar el software de sistema y aplicaciones negocios de Oracle al mercado pre-instalado en los servidores Dell de plataforma x86. De más está decir que el archirrival de Dell en el negocio de los servidores x86 resulta ser: HP. Se ha virado la tortilla (omelette).

Una ... ¿sorpresa?

Para continuar, el día 24 de junio 2013 anuncian una alianza estratégica con ​Microsoft. Si alguien me hubiera dicho esto en los tiempos de la ​adquisición de Sun Microsystems no lo creería. Después de este evento ambos gigantes quedaban como competidores directos en no pocos sectores. Además de todo esto las tecnologías y enfoques de ambos son notablemente ortogonales, aunque existen puntos de contacto.

En una conferencia de prensa se reunieron Steve Ballmer y Mark Hurd para anunciar esta nueva alianza. La misma consiste en que Oracle certificará y dará soporte a sus aplicaciones, plataformas y bases de datos para ejecutarlos en la plataforma Windows Azure y en los entornos de virtualización Hyper-V. Las distribuciones de Linux de Oracle también serán cerificadas para Hyper-V. Todo esto viene acompañado la posibilidad de que las licencias ya expedidas para Windows Server serán válidas también para Windows Azure. Microsoft, entre otras cosas, ofrecerá una versión completamente certificada de Java para Windows Azure. Para los usuarios que no posean licencias de Oracle en este momento Microsoft añadirá en la galería de imagenes de Windows Azure servicios de infraestructura con configuraciones que incluyen la base de datos de Oracle, WebLogic Server y Java.

Algunos productos de Oracle ya tenían una presencia notable en Windows, así que hasta aquí todo relativamente bien ... Lo más llamativo para mí fue que también se ofrecerán en Windows Azure instancias pre-configuradas de la distribución de Linux de Oracle con aplicaciones pre-instaladas de la misma compañía.

Aplicaciones empresariales en la nube

Recuerdo que hace un tiempo atrás ​Salesforce.com fue una de las compañías que más temprano y con mayor decisión desarrolló sus productos sobre la plataforma Google App Engine. Fue todo un acontecimiento mediático del momento. El día 25 de junio del 2013 se da a conocer ​una alianza por un período de nueve años durante los cuales la compañía estandarizará sus propuestas para correr sobre la base de datos, el sistema operativo Linux, la implementación y plataformas de Java y los servidores de base de datos Exadata ... de Oracle. Estos dos gigantes en el sector de aplicaciones empresariales también han acordado integrar la solución CRM de Salesforce.com y otras aplicaciones en la nube con Oracle's Fusion HCM y aplicaciones ​SaaS de Oracle en el sector de las finanzas. Salesforce.com adoptará todas estas tecnologías de Oracle en su infraestructura para desarrollar su propio negocio. La historia y el presente recogen la lucha en el campo de CRM entre estos dos actores de la tecnología y el software. Incluídas están varias declaraciones controvertidas como las de Larry Ellison (CEO de Oracle) en el Oracle OpenWorld 2010 cuando expresó que ​Saleforce.com no era una compañía de cloud computing.

Por otra parte, más esperado fue el ​acuerdo con Netsuite concretado el 26 de junio del 2013. Larry Ellison es el pricipal accionista de NetSuite. Oracle integrará sus aplicaciones y servicios en la nube para ​HCM con el ​ERP de NetSuite.

La repercusión directa de estas dos acciones apunta a hacerle frente a la competencia de SAP en el terreno de aplicaciones empresariales.

Conclusiones

Realmente en el 2011 veía muy lejana la visión de Peter Katz (CTO de PKA Technologies en ese momento) cuando mencionaba con respecto a la competencia de Oracle que después de comprar a Sun estaba en una posición de dar soporte a IBM y ayudar a Microsoft y Red Hat considerando a estos tres últimos como ganadores desplazados. Todo esto se ha concretado de manera acelerada después de conocer los detalles ​del resúmen del año fiscal de Oracle. A la lista se suman Google, HP, SAP ... y no me extrañaría que otros. Oracle tiene una visión clara de sus perpectivas considerando sus fortalezas actuales.

Tres días, tres alianzas. Nada ... que si le añadimos a todo esto una historia de amor y un poco de efectos especiales Hollywood y O'Globo tienen suficiente material para dos películas y una telenovela.

Tutorial de LD_PRELOAD, segunda parte

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.

Apache™ Bloodhound 0.6 : Bootstrap handlers

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.

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 .

Breve tutorial sobre LD_PRELOAD

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

Cambiando contexto de usuario con sudo y 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

Brython migra de Google Code hacia Bitbucket

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 .

¿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

• El repositorio oficial ​olemis/brython @ bitbucket (mercurial) creado con ​hgsubversion
• Un mirror ​olemis/brython-git @ bitbucket creado con git-svn y que se mantendrá sincronizado usando ​hg-git

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 .

Apache™ Bloodhound : Progreso del soporte multi-producto

En artículos anteriores les había mencionado que una de las líneas de trabajo más prioritarias para las próximas versiones de Apache™ Bloodhound es la arquitectura multi-productos . A continuación les presento una línea de tiempo que ilustra el progreso que se va haciendo en esta dirección.

Espero que sigan el desarrollo de esta funcionalidad y que les sirva este gráfico para estimar cuando estaría listo el soporte multi-producto para Apache™ Bloodhound .

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 .

Tuxinfo 50: Apache™ Bloodhound un fork de Trac

Con mucho placer recibo la noticia de la publicación del ​número 50 de la revista ​TuxInfo. Realmente hay que destacar el esfuerzo que realiza todo el equipo y los colaboradores para mantener estos resultados . Se necesita mucha constancia y dedicación. Estoy hablando de medio centenar de ediciones que han logrado familiarizar a muchos usuarios con las características , ventajas y desventajas del uso del ​software libre . Este hecho coincide apróximadamente con el anuncio por parte de la ​Apache Software Fundation de la publicación oficial de la ​versión 0.1.0-rc1 de Bloodhound. Decidí escribir un poco acerca del tema para que todos pudieran conocer mejor esta herramienta de administración de proyectos. Este es el principio de una serie de artículos. Si desea estar al tanto de los detalles le invito a ​suscribirse mediante RSS

¿Qué es Bloodhound?

​Bloodhound es la propuesta de la ​Apache Software Foundation (ASF) como herramienta de administración de proyectos. Su desarrollo parte del archi-conocido projecto de código abierto ​Trac. Anteriormente ya he publicado en la revista algunos artículos sobre esta aplicación web y ya les había hecho algun ​comentario sobre Bloodhound. La idea central consiste en construir una variante mejorada de Trac orientada a facilitar su uso en entornos empresariales y soluciones llave en mano.
A continuación les muestro un esquema de la interfaz de usuario . Las líneas rojas solo resaltan las distintas partes y no aparecen en el diseño .

La explicación y el resto de la historia aparecen en el artículo . Si está interesado en saber, le invito a ​descargar TuxInfo 50 .

Estado actual del proyecto

El primer hito del proyecto ha sido la liberación de la ​versión 0.1.0-rc1 y la redacción de una simple ​guía de instalación que pueden utilizar los usuarios interesados en poner a punto una instancia del sistema. Esta acción fue avalada en primera instancia por una ​votación en la lista ​bloodhound-dev@incubator.apache.org . Los resultados se muestran a continuación

Mark Poole	+1	binding
Joachim Dreimann	+1	(non-binding)
Olemis Lang	+1	(non-binding)
Greg Stein	+1	binding
Ethan Jucovy	-1	(non-binding)
Hyrum Wright	+1	binding
Gary Martin	+1	binding

Posteriormente en una segunda votación realizada en la lista de discusión ​general@apache.org se ratificó la decisión al reunir los tres votos de los miembros del IPMC a favor de dar luz verde al anuncio oficial .

¿... y entonces ...?

Hasta ahora la participación en el proyecto ha representado una grata experiencia profesional que me ha permitido diseñar nuevas ​APIs dentro de Trac, expandir mis horizontes y conocer nuevas tecnologías. Destaco el caso de la librería ​Bootstrap de ​Twitter que ha sido utilizada para construir la interfaz de usuarios. ¡Impresionante! Espero poder tener tiempo para compartir mis descubrimientos con Usted en este blog, así que le invito a ​suscribirse mediante RSS si es que desea enterarse.

El futuro de Bloodhound en la ASF

En el futuro a corto y mediano plazo hay ciertos hitos que quisiera mencionar porque pueden impulsar el desarrollo y despertar el interés de otras personas dispuestas a participar y formar una comunidad. En primer lugar la instalación del sistema en el ​sitio de reporte de incidencias de la ASF permitirá añadir paulatinamente a Bloodhound como una alternativa al ​uso de JIRA. Además de este software comercial de la compañía ​Atlassian existen otras opciones basadas en aplicaciones de código abierto que son utilizadas por la fundación. Estas son Bugzilla y Scarab. Segun ​un mensaje enviado a bloodhound-dev todo parece indicar que ya comienza a haber interés en usar Bloodhound por parte del proyecto Apache^TM Steve.

Integración con Allura

La segunda gran oportunidad es la integración con el proyecto ​Apache Allura^TM . Aunque el nombre no les sea muy familiar estoy casi seguro que lo deben conocer. Este es el sistema que desarrolla ​Geek.net y que todos vemos en funcionamiento en el sitio ​Sourceforge.net. Su incorporación al proyecto ​Apache Incubator^TM es reciente. De hecho el sitio del proyecto ​Allura en Sourceforge.net todavía no ha sido migrado hacia los servidores de la fundación.
Esta aplicación web integra dentro de un mismo sitio un conjunto de herramientas de soporte al proceso de desarrollo y ofrece una plataforma unificada de administración. Todas estas razones la ubican como un competidor de ​GForge y otros sistemas similares , pero en este caso avalado por las tremendas credenciales que le otorga su uso en uno de los más grandes sitios de hospedaje de proyectos de código abierto.
Allura es un sistema extensible. Existe una ​API para integrar las herramientas y hacerlas trabajar de forma coordinada. En este contexto Bloodhound pudiera ser una de las aplicaciones que se pudiera integrar a esta plataforma. De hecho , ya había pensado acerca del tema desde el pasado año cuando escribía ​una nota de presentación de Bloodhound , en el momento que se concebía la idea. Por aquellos tiempos SF.net ofrecía instancias de Trac a los proyectos mediante su iniciativa ​Hosted Apps . Después de la increíble reacción inicial de la comunidad , este intento probó no ser sustentable a largo plazo. En el caso específico de Trac les puedo mencionar que el ​plugin para XML-RPC no era funcional. Recibí muchas peticiones de amigos que conocían que yo participaba en el desarrollo y mantenimiento del plugin. Se repetía una y otra vez que no lograban integrar la instancia de Trac desplegada en SF.net con el ​conector para Eclipse Mylyn . Solo pude orientarlos hasta llegar al punto en que no quedaba otro remedio que la intervención del proveedor de servicios; algo que no sucedió hasta donde tengo entendido. Al parecer no fue tarea fácil tampoco integrar las otras aplicaciones que se ofrecieron. Esto llegó hasta el punto crítico que motivó el ​anuncio del retiro del plan Hosted Apps.
Sin embargo, ahora que ambos proyectos coexisten en el marco del proceso de incubación de la ASF existe la posibilidad de que se concrete un conector de Bloodhound para Allura. La idea fue mencionada en un ​mensaje de Greg Stein a bloodhound-dev . Si prestan atención a la ​lista de proyectos en incubación es posible apreciar que Greg Stein es ​mentor en ambos casos.
Todos los detalles los podrá conocer Usted aquí en este blog. Aproveche la oportunidad de ​suscribirse mediante RSS para estar informado acerca de los acontecimientos . Si se decide a ​descargar e ​instalar Bloodhound , pues mejor. No dude en hacer cualquier tipo de pregunta . Simelo pide seguro que haré un poco de tiempo para responder sus inquietudes.

Identificando números primos con expresión regular en Perl

Como puede resultar raro que una expresión regular tenga algo que ver con los números primos quiero aclarar algo : este artículo no es una broma. Las  expresiones regulares provienen fundamentalmente de la rama de la teoría de compiladores y son el bloque fundamental de muchos lenguajes de programación. Esto se debe en primer lugar a que son utilizadas por el analizador sintáctico del lenguaje. Además hay librerías para trabajar con expresiones regulares en la gran mayoría de los lenguajes de programación (de alto nivel ;) . Estas expresiones están relacionadas con las  máquinas de estado y algunos  autómatas simples. Otra historia muy diferente son los  números primos, los archi-conocidos guardianes de gran parte de los secretos más celosamente guardados de la  teoría de números. A continuación trato un tema de esos que evidencian las extrañas conexiones entre la informática y las matemáticas y que me dejó sin palabras cuando supe del truco recientemente por primera vez. Antes ya he otras curiosidades similares . Recuerdo ahora por ejemplo el  artículo publicado anteriormente acerca de los  números de Fibonacci. La vida es bella ... y los números y la informática todavía son capaces de sorprendernos. En caso que Usted desee estar al tanto de curiosidades matemáticas semejantes, les invito a  suscribirse mediante RSS.

Los hechos

Para ir directo al grano, la expresión regular es la siguiente :

perl -lne '(1x$_) =~ /^1?$|^(11+?)\1+$/ || print "$_ is prime"'

¿Puede darse cuenta de cómo funciona? Más adelante ofrezco una explicación, pero trate de descifrarlo Usted mismo. A continuación les presento lo que ocurre cuando se ejecuta (es preciso teclear el número que se desea comprobar y pulsar la tecla Enter para que el comando facilite la respuesta ;)

$ perl -lne '(1x$_) =~ /^1?$|^(11+?)\1+$/ || print "$_ is prime"'
1
2
2 is prime
3
3 is prime
4
5
5 is prime
6
7
7 is prime
8
9
10
11
11 is prime
127
127 is prime
1009
1009 is prime
1234577
1234577 is prime

Con números grandes el comando puede tardar un poco en dar una respuesta. Sea paciente ;)

¿Cómo funciona?

En primer lugar el número es convertido a su representación unitaria mediante (1x$_) . Por ejemplo el número 7 es convertido en 1x7, que es 1111111 (o sea 1 repetido 7 veces ;). En términos generales la idea consiste en aplicar posteriormente la expresión regular que aparece en el miembro derecho a esta cadena. Si se encuentra una coincidencia el número es compuesto sino es primo.

Explicaré a continuación cómo funciona la expresión regular. La misma consta de dos partes ^1?$ y ^(11+?)\1+$. La primera reconoce el número 1 y la cadena vacía. Ambos casos se considera que no son números primos. La segunda determina si dos o más 1s repetidos llegan a conformar una parte del número. Si este es el caso entonces el número es compuesto sino es primo.

Dos ejemplos

Veamos cómo es que funciona todo con los números 5 y 4.

La representación del número 5 es 11111. La expresión (11+?) reconoce los dos primeros dígitos (i.e. 11). La referencia \1 se instancia al mismo valor (i.e. 11) y la expresión regular en sí se expande a ^11(11)+$. La misma no puede aceptar cinco números uno, por tanto falla. Sin embargo, como se utilizó +?, se inicia el mecanismo de backtracking y reconoce los tres primeros dígitos (i.e. 111) . La referencia \1 se instancia al mismo valor (i.e. 111) y la expresión regular en sí se expande a ^111(111)+$. Tampoco tiene éxito ese intento. El proceso se repite para 1111 y 11111, que tampoco aporta una coincidencia. Por tanto la expresión regular en el global no devuelve coincidencia y se concluye que el número es primo.

La representación del número 4 es 1111. La expresión (11+?) reconoce los dos primeros dígitos (i.e. 11). La referencia \1 se instancia al mismo valor (i.e. 11) y la expresión regular en sí se expande a ^11(11)+$. En este caso la representación original sí es aceptada por la expresión regular expandida. Por tanto la expresión regular en el global sí devuelve una coincidencia y se concluye que el número es compuesto.

Conclusiones

Debo dejar claro que no tomo el crédito por haber descubierto este truco. Al parecer fue inventado por  Abigail en 1998. Hay que aclarar que el ejemplo mencionado no es exactamente ni una expresión regular (atendiendo a su definición formal) ni tampoco es un método para verificar si un número es primo. Es simplemente algo raro que se puede hacer con Perl. Le invito a  suscribirse a este blog y así descubrir juntos los secretos de la matemática y la informática.

@Wandisco propone Bloodhound, un fork de Trac

En  artículos anteriores les he hablado de  Trac , un sistema de administración de proyectos que me gusta mucho debido la calidad de su diseño. Soy el autor o contribuyo con  varios plugins. Me atrevería a decir que  Trac es el sistema de este tipo con más instalaciones funcionando en línea. Muchos projectos de software libre lo utilizan, e.g.  Pidgin,  PyAMF,  OForge ... muchos en realidad. También sucede que compañías como  Sourceforge también lo ofrecen en su paquete de  hosted apps .

Estado actual de la comunidad de Trac

Sin embargo en los últimos tiempos el desarrollo de la herramienta no ha sido lo suficientemente acelerado como algunos querrían. Hay algunas razones para haber llegado a este punto. En primer lugar ya  Edgewall (la compañía que gestó el proyecto) no es lo que solía ser unos años atrás. Además  el sitio de la comunidad necesita una actualización desde hace mucho tiempo ya. Todavía funciona con la versión 0.10, en un momento en que ya se está desarrollando la versión 0.13. Hay una buena distancia entre las dos, créanme. En mi opinión también sería muy conveniente que migraran el  repositorio actual basado en  Subversion para utilizar otro sistema distribuido, e.g.  Mercurial o  Git (me inclino por el primero pero todo parece indicar que ya hay una  propuesta de espejos para Git y  otra propuesta para Bitbucket).

Teniendo en cuenta mi experiencia personal también me inclino a pensar que los desarrolladores de los plugin puede que no tengan el apoyo necesario como para dedicarse a tiempo completo a realizar sus ideas. Por tal razón se dedican a hacer otras cosas mejor remuneradas.

Nuevos horizontes para Trac

Recientemente me ha llegado  una agradable noticia. Hay un fuerte interés en el desarrollo y mejora de  Trac. Todo comenzó meses atrás cuando un mensaje fue enviado a las listas  trac-users y  trac-dev. En estos momentos, gracias fundamentalmente a la compañía  Wandisco, esta petición a tomado vuelo y se concreta en una  propuesta llamada Bloodhound. La idea subyacente es integrar el desarrollo bajo la égida de la  ASF en el sistema  Apache Incubator. Esta fundación se destaca por dar vida a comunidades relacionadas con el código abierto. Entre las más destacadas se encuentran los proyectos  Subversion y el servidor  Apache httpd, ambos estrechamente relacionados con  Trac.

La idea que se maneja es clonar el código existente y comenzar una rama de desarrollo independiente , o sea que el proyecto anterior no muere. Por tales razones supongo que lograr una interoperabilidad entre ambos proyectos, al menos en un futuro cercano, es algo que beneficie a ambas partes. En el caso  plugins útiles y exitosos para ofrecer una solución llave en mano. del naciente Bloodhound la idea consiste también en empaquetar varios

Conclusiones

En pocas palabras , estoy muy contento al saber que todo esto está ocurriendo. Espero que la idea dé frutos y pueda salir a flote esta nueva herramienta. Habrá que seguir  la evolución de esta idea para ver qué resulta. Gracias a todos los que la han hecho posible.