Tengo en mi casa un Pentium III de 800 MHz con 128 MBs de RAM. Es de César y la vamos a utilizar para el proyecto. No tiene lectora de CD y no tiene soporte para bootear por la red. Les muestro en este post lo que tuve que hacer para instalar Ubuntu Server en una máquina así, de esta forma si lo tienen que hacer se ahorran trabajo.
El otro día necesitaba saber bien cómo funcionaba el método Remove de la clase StringBuilder en Mono. Entonces hice lo siguiente:
miltondp@wasabi:~$ csharp
Mono C# Shell, type "help;" for help
Enter statements below.
csharp> using System.Text;
csharp> var a = new StringBuilder("Milton");
csharp> a.Remove(a.Length-1,1);
Milto
csharp> a.Remove(a.Length-1,1);
Milt
csharp> a.Remove(a.Length-1,1);
Mil
csharp> a.Remove(a.Length-1,1);
Mi
csharp> a.Remove(a.Length-1,1);
M
csharp> a.Remove(a.Length-1,1);
csharp>
Si, funcionaba como me lo imaginaba 
Esta shell para C# está disponible en la versión 2.2 de Mono.
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.
Uso meld para realizar comparaciones entre archivos o directorios. Mercurial, al detectar un conflicto, busca en el sistema algún programa gráfico para resolverlo, mostrando las diferencias y así poder realizar el merge.
La idea es que en los tres paneles de meld, a la izquierda tengamos la versión de base, en la que se basan (valga la redundancia) nuestras modificaciones y las de la otra rama, en el medio nuestro archivo, y a la derecha el del otro. Trabajamos con la vista del medio, realizamos la fusión y guardamos los cambios al finalizar. Así resolvemos el conflicto.
Sin embargo no es ese el orden en el que aparecen los archivos en meld cuando trabajamos con Mercurial. Buscando en la ayuda de configuración, he encontrado estas opciones que podemos utilizar en nuestro ~/.hgrc, y así resolver este inconveniente:
[merge-tools] meld.executable = meld meld.args = $base $local $other meld.priority = 1
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.
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.
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.
Hace unas horas César envió un mail a un grupo de gente a la que le gusta discutir estas cosas. Él hacía referencia a éste post, en el que habla sobre un tema que habíamos tocado ya en una de nuestras discusiones: los diálogos de GNOME no tienen botón “Aceptar”, ni “Aplicar”, ni “Cancelar”… simplemente un “Cerrar” y listo. Vean, éste es el diálogo para configurar el proxy:
