Mercurial Queues: una aplicación simple

Hace un tiempo comencé a leer un poco sobre esta extensión de Mercurial: Mercurial Queues (Mq). ¿Para qué sirve? Bueno, imagínense que tienen una instalación de WordPress con ciertas modificaciones que le han hecho. Supongan que la versión del CMS que están usando es la 2.6.5. Quieren actualizar a la 2.7 pero sin perder los cambios, y que la migración sea sencilla. Bueno, Mq les permite mantener estos cambios personales como parches, que pueden aplicar, modificar, quitar, reordenar… De esta forma, con una serie de pasos, pueden actualizar fácilmente el código “de fondo” (o sea, de WordPress 2.6.5 a la 2.7) y reaplicar esos parches sobre esta nueva base. En este post pueden ver el ejemplo desarrollado.

Continuá leyendo Mercurial Queues: una aplicación simple

Agregar números de página a un PDF

Tengo un libro en PDF que no tiene los números de página, y como lo voy imprimiendo de a poco (por miedo a imprimirlo completamente y dejarlo tirado), con el objetivo de abrochar al final todas las páginas o encuadernarlo, hay riesgo de que algún día se me caigan todas las hojas o se me despapele y no sepa cómo ordenarlo rápidamente.

Intenté agregarles el número de página con OpenOffice.org, usando el plugin pdfimport. Parece que el funcionamiento consiste en convertir el PDF a un documento de Draw. El problema es que no encontré, por lo menos en forma directa, cómo agregar un pie de página en esta aplicación.

Me encontré con una solución que explica cómo hacer todo con un script (usa pdftk) y un poco de OpenOffice.org. No se si es la solución más rápida, directa y obvia, pero ahora mi PDF tiene los números de página.

Mercurial vs Subversion: branching and merging

Hace un tiempo vengo estudiando este sistema de control de versiones distribuído, hecho principalmente en Python, y que lo utilizan algunos grandes proyectos como Mozilla, OpenJDK, NetBeans, etc. En este post, quería compararlo con Subversion, con respecto a mantener distintas ramas de desarrollo.

Aclaro que si bien no tengo una experiencia real con ambos sistemas en el tema, como la podría tener algún desarrollador de un proyecto grande de Software Libre, leyendo los manuales, viendo los ejemplos y utilizándolo en pequeños proyectos con pocos desarrolladores uno puede darse una idea de cómo son las cosas a gran escala.

En muchos lugares se habla de las bondades de los sistemas de control de versiones distribuidos. Una de las ventajas que tienen (entre muchas otras), según se dice, es la facilidad para manejar branches, donde se mencionan las deficiencias de Subversion para manejar varias ramas de desarrollo.

Este post puede servir para alguien que esta pensando en alguna herramienta de versionado, donde se esperan utilizar varios branches en el proyecto, como para poder ver de forma sencilla cómo manejan esto ambos sistemas. Esa “forma sencilla” de verlo podría significar también una divergencia importante con la práctica. Así que si piensan que algo es incorrecto, los invito a dejar un comentario.

Continuá leyendo Mercurial vs Subversion: branching and merging

Bisecando con Mercurial (o encontrando changesets con bugs)

Hace un tiempo vengo leyendo y estudiando Mercurial, un sistema de control de versiones distribuido. Sin embargo todo lo que se es teoría, ya que mis amigos (con los que podría probarlo) no quieren dejar Subversion. Pero bueno… sin decir quiénes son, y al saber que ellos leen mi blog, sólos se darán cuenta que están en el error 🙂

A grandes rasgos (y según lo que yo entendí y veo más notorio), la gran diferencia entre los sistemas de control de versiones centralizados como Subversion o CVS y los distribuidos como Git, Mercurial y Bazaar, es que los primeros imponen más restricciones que sus pares distribuidos. En Subversion por ejemplo, si accedo a mi repositorio vía Internet, y en algún momento no tengo conexión, entonces no puedo hacer commits. Si quiero ver los logs de algunas revisiones o realizar otras operaciones que no sean updates o commits, necesito acceder al repositorio central, lo que es más lento.

En los sistemas centralizados hay un servidor central, y varias copias de trabajo, una por cada desarrollador. En los sistemas distribuidos puede o no haber un servidor central con el repositorio, pero la diferencia es que todos los desarrolladores tienen el repositorio completo, no una copia de trabajo. Es decir que cada persona posee la versión actual más toda la historia del proyecto en su computadora, lo que permite operar en modo offline. Esto puede parecer ineficiente, pero de hecho no lo es: los grandes proyectos de Software Libre como Linux, NetBeans, OpenJDK, Mozilla, y en un futuro GNOME también, usan estos sistemas, ya que ofrecen grandes beneficios (especialmente para los proyectos Open Source). Imagínense hacer commits, crear branches, etc, sin necesidad de conexión. Y cuando termino mi trabajo, luego de revisarlo bien, ahí recién puedo subir todo, o sino decirle a mi colega desarrollador que actualice su repositorio desde el mío.

En definitiva, con un sistema distribuido puedo trabajar con menos restricciones que con uno centralizado.

Continuá leyendo Bisecando con Mercurial (o encontrando changesets con bugs)

Zaspe# 0.1.0 released!

Estos días me hice un tiempo para publicar una versión un poco más usable de Zaspe#: ahora es posible generar reportes. Sin embargo la funcionalidad no es todavía muy configurable. Hay muchas mejoras que se pueden hacer, pero eso llevará tiempo.

Los reportes que se pueden realizar son de personas y asistencias (aquí y aquí tienen ejemplos). Éstos se producen en formato PDF. Lamentablemente no hay una forma de imprimir los reportes directamente, por lo que puede ser complicado para usuarios inexpertos.

Al final, estoy utilizando iTextSharp para generar los PDFs, no MonoReporter, que si bien actualmente puede generar reportes básicos, decidí por el momento utilizar algo ya hecho y maduro. Con MonoReporter (que utiliza GtkPrint) sí podría imprimir el reporte directamente, o ver previsualizaciones. Pero bueno, será algo a hacer más adelante.

Continuá leyendo Zaspe# 0.1.0 released!

Un servidor web en 30 líneas de código

Interesante este post de Oren Eini. Es un código escrito en Boo (lenguaje tipo Python para .NET):

import System.Net
import System.IO

if argv.Length != 2:
	print "You must pass [prefix] [path] as parameters"
	return

prefix = argv[0]
path = argv[1]

if not Directory.Exists(path):
	print "Could not find ${path}"
	return

listener = HttpListener()
listener.Prefixes.Add(prefix)
listener.Start()

while true:
	context = listener.GetContext()
	file = Path.GetFileName(context.Request.RawUrl)
	fullPath = Path.Combine(path, file)
	if File.Exists(fullPath):
		context.Response.AddHeader("Content-Disposition","attachment; filename=${file}")
		bytes = File.ReadAllBytes(fullPath)
		context.Response.OutputStream.Write(bytes, 0, bytes.Length)
		context.Response.OutputStream.Flush()
		context.Response.Close()
	else:
		context.Response.StatusCode = 404
		context.Response.Close()

Y ejecutando el comando:

$ booi prueba.boo http://localhost:8085/ ~/Escritorio/

tenemos funcionando un webserver localmente. Me acuerdo como en una de las charlas de alguna de las jornadas Python en Santa Fe el disertante hacía algo similar. La verdad, muy útil este tipo de código.

Zaspe# 0.0.3

Ayer vino Sebastián a casa. Mientras tomábamos unos mates me comentó que en un evento en el que participó utilizó Zaspe#. Si si, ¡Zaspe# tiene un usuario! 😛 En realidad, quizá unos cuantos, ya que en la página de download del proyecto figuran 80 descargas al día de hoy. No no, no fui yo quien realizó las descargas para hacerles creer que algunas personas tienen algún tipo de interés, al parecer, de verdad lo tienen 🙂 Quizá al probarlo se dieron cuenta de que todavía le falta bastante, si bien es posible registrar personas, eventos y llevar las asistencias. Lo más importante, que me comentaba el Seba, son los reportes, algo de lo que carece.

Esta aplicación me sirvió más a mí para aprender Gtk con Mono que al usuario que en un principio me había pedido este desarrollo.

En fin, Sebastián me mencionó algunos bugs que tenía la versión 0.0.2, de lo que era consciente, y ya estaban corregidos en trunk. Por lo tanto, decidí realizar este release. El proyecto está bastante parado, el problema, como dije, son los reportes. Hubo avances con MonoReporter, pero todavía nada suficiente como para poder generar listados de personas, de eventos, asistencias, etc.

MockObjects con Rhino.Mocks

Cuando escribimos tests de unidad, intentamos testear una única funcionalidad. Esto muchas veces es bastante difícil, ya que generalmente necesitamos apoyarnos en otras clases distintas para cumplir con el propósito de la testeada, y terminamos probando, al final, otras cosas. Y si fallan estas clases “base”, a veces es difícil rastrear cuál es el error.

Por ejemplo, supongamos que tenga un método RegistrarAsistencia(int, int), que registra que la persona asistió al evento (los argumentos serían los IDs). Este método inventado, tendría como dependencia la clase ControladorPersonas y ControladorEventos, para levantar los objetos necesarios y realizar el registro. Pero esto (levantar los objetos Persona y Registro), a nosotros, no nos interesa probar en el test de unidad, sino verificar que el método RegistrarAsistencia realmente funciona, registrando que la persona asistió al evento.

Otro ejemplo podría ser algún método ImprimirFactura, que toma los datos del formulario, e imprime la factura. ¿Cómo podemos escribir un test de unidad para esto?

Una solución viene de la mano de la técnica de MockObjects, y Rhino.Mocks es un framework para .NET.

Continuá leyendo MockObjects con Rhino.Mocks