Gtk+: trabajando con TreeViews

edicion-treeview1

Este post puede ser útil para los que utilicen el widget TreeView de Gtk+ (no importa el lenguaje mientras haya bindings), y necesiten activar por código celdas en modo edición. Hay algunas cuestiones a tener en cuenta.

Para el Proyecto Final de Carrera estamos desarrollando un sistema de nivel operativo, con funciones de facturación y demás. Necesitamos manejar un TreeView con campos editables, y al finalizar la edición de uno de ellos es necesario dar el foco a otro campo en modo edición, listo para que el usuario comience a cargar datos sin tocar el mouse.

Continuá leyendo Gtk+: trabajando con TreeViews

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)

Resultado de las elecciones

La semana pasada no sabía si postear esto… quería esperar información precisa del Emilio, pero decidí publicarlo hoy:

El jueves pasado, como indicaba en el post anterior, se realizaron las elecciones para Consejeros Estudiantiles en la UTN, tanto a nivel local como nacional. Nosotros presentamos una lista, Pensamiento Sistémico, que logró la mayoría de los votos, colocando 2 consejeros en los 3 puestos disponibles en el Consejo Departamental de Sistemas, así que es una gran alegría para todos los que estuvimos directamente involucrados, tanto como las personas que nos apoyaron con su voto, a las cuales les doy las gracias.

También hay que agradecer a aquellos que nos dieron una mano en el momento de las elecciones como fiscales, controlando que todo se desarrolle con normalidad. Y por último a Carlos Ignacio Feck, el apoderado de la lista, que trabajó mucho para que todo esto sea posible.

Por lo que entiendo, quedamos como consejeros titulares y suplentes:

  • Titular: Milton Pividori. Suplente: Luis Ignacio Larreteguy.
  • Titular: Matías Fabricio Gareli Fabrizi. Suplente: Sergio Del Castillo.

De todas formas esta semana se informará bien en el Emilio, y lo importante es que vamos a tener voto en el Consejo para llevar adelante nuestras ideas, así como aquellas de los alumnos.

Bueno, ahora hay que asumir esta responsabilidad y moverse para hacer nuestro aporte a la carrera y a la Facultad. Estos días voy a dejar como comentario en este post los datos para el contacto, ya que todavía nos estamos organizando con esto.

Elecciones en la UTN

Hace unos dos meses formamos un grupo de estudiantes y hemos presentado una lista para participar como candidatos a las elecciones por Consejeros Estudiantiles en la UTN, únicamente por el Consejo Departamental de Sistemas, que será el próximo jueves 12 de junio. Hasta último momento estuvimos decidiendo si participar o no, y finalmente lo hicimos. Hemos preparando un documento de presentación de nuestra lista, además de información acerca de los órganos gubernamentales de la Facultad y otras cosas que generalmente ningún alumno conoce, y que nosotros hemos aprendido en estos últimos meses. Dicho documento es el siguiente:

Presentación

Somos un grupo de alumnos de la UTN – Facultad Regional Santa Fe, estudiantes de Ingeniería en Sistemas de Información, que llegando al final de la carrera con varias ideas que se podrían incorporar a la misma, hemos decidido participar como candidatos para Consejeros Estudiantiles por el Consejo Departamental de Sistemas, que se eligirán el próximo jueves 12 de junio.

Hemos conformado una lista llamada Pensamiento Sistémico, la cual es totalmente independiente. Por el momento somos 6 alumnos, de 3er, 4to y 5to año de la carrera:

  • Carlos Ignacio Feck.
  • Luis Ignacio Larrateguy.
  • Matías Fabricio Gareli Fabrizi.
  • Milton Damián Pividori.
  • Sergio José del Castillo.
  • Leonardo Bórtoli.

Estructura gubernamental de la Universidad

Resumiendo la estructura gubernamental de la Universidad, decimos que existen cuatro niveles de gobierno: El Consejo Superior Universitario (que lo integra, entre otros, el rector de la UTN y es el máximo nivel de gobierno de la Universidad), el Consejo Directivo (formado por el decano, docentes, no docentes, graduados y estudiantes; es a nivel Facultad), los Consejos Departamentales (que lo integra el Director del Departamento, docentes, graduados y estudiantes, y donde se discuten cuestiones relacionadas con la carrera) y finalmente Materias Básicas. Como hemos dicho antes, nosotros nos postularemos por los cargos de Consejeros Estudiantiles por el Consejo Departamental de Sistemas únicamente.

¿De qué se encarga el Consejo Departamental, en nuestro caso el de Sistemas? Se discute y decide sobre la política académica de la carrera Ingeniería en Sistemas de Información. Entre otras cosas, esto incluye los planes de estudio y la administración del presupuesto del Departamento.

¿Qué se vota? ¿Cómo? ¿Cuándo?

Se realizan las elecciones de Consejeros Estudiantiles a nivel local y nacional. El día es el jueves 12 de junio. El voto es obligatorio. Para emitirlo, es necesario identificarse llevando en el día de las elecciones: la Libreta Universitaria, el D.N.I. o la Cédula de Identidad.

Nuestras propuestas

  • Un mayor contacto entre los Consejeros y los estudiantes, habilitándolos a los últimos a una mayor participación en la toma de decisiones dentro de la carrera de Ingeniería en Sistemas de Información, además de la posibilidad de realizar preguntas, plantear dudas, solucionar inconvenientes con cuestiones relacionadas con el cursado o exámenes por ejemplo. Se verá la factibilidad que haya en organizar reuniones periódicas con los estudiantes interesados en participar.
  • La creación de un Grupo de Investigación de Software Libre, que pueda formentar el uso de este tipo de aplicaciones, que ofrezca alternativas libres a las herramientas existentes para la realización de trabajos prácticos en el cursado de las distintas materias, así como la organización de distintos eventos relacionados con esta filosofía.
  • Enseñanza del uso de herramientas que conducen a buenas prácticas en el desarrollo de software, como sistemas de control de versiones, herramientas para realizar pruebas de unidad (unit testing), seguimiento de errores y automatización de prácticas como la integración continua.
  • Reuniones informativas sobre las actividades de investigación que se realizan en los distintos grupos de la Facultad, motivando a los alumnos en la participación de los mismos.

LaTeX: Paquete listings

Desde hace un tiempo que vengo usando, para incluir archivos de código fuente en documentos LaTeX, el paquetes lgrind. El problema es que no se actualiza más (última versión de 2002).

Hace un tiempo tuve la necesidad de incluir código fuente en C# en un documento de un TP. Gracias a un desarrollador de GNOME he encontrado el paquete listings, en el Planet GNOME.

No sólo sirve para incluir archivos de código fuente, sino también para ficheros de configuración por ejemplo. Es realmente muy util. Pueden bajarse un manual aquí.

Un ejemplo simple:

\begin{lstlisting}[frame=single]
class X {
     string my_string;
     int    very_important_value;
}
\end{lstlisting}

Se pueden setear varias opciones, como “frame”, que dibuja una caja alrededor del código. También se pueden incluir archivos completos con el comando “\lstinputlisting”. Aquí un ejemplo.

Mono/.NET: No importa el lenguaje

Una de las cosas que vamos a probar en el trabajo práctico de implementación de Administración de Recursos, es qué tan cierto es eso de que Mono/.NET es independiente del lenguaje.

Bueno, estuve haciendo unas pruebas con Python y C#. Hay una implementación de código abierto (bajo la licencia de Microsoft Ms-PL) del intérprete de Python escrita en C#, que permite ejecutar estos programas compilando el código Python a CIL (el código intermedio). También tiene una consola, como Python, y es posible utilizar toda la biblioteca de .NET. Se llama IronPython.

Esta implementación, en su versión estable actual 1.1, tiene compatibilidad con CPython 2.4.4. Esto significa que un programa escrito para ser corrido con Python 2.4.4 puede correrse también con IronPython 1.1. Sin embargo no es que podemos correr cualquier cosa hecha para Python con IronPython: un juego que utiliza el módulo PyGame no funciona (por lo menos yo no pude).

Les voy a mostrar un ejemplo en el que desde Python creo una clase que hereda de otra creada en C#. Sip, ¡esto está muy bueno!

Continuá leyendo Mono/.NET: No importa el lenguaje

Visualización de árboles de búsqueda usando LaTeX

En el trabajo práctico número 1 de Inteligencia Artificial, tuvimos que programar un pacman para que actuara en un ambiente donde había enemigos y alimento. Debíamos utilizar alguna estrategia de búsqueda.

En este tipo de estrategias, para encontrar una buena acción a llevar a cabo, el agente genera un árbol. El nodo principal representa el estado inicial del mismo. Por ejemplo, dicho estado indica que está en la posición (X,Y), con una cantidad determinada de energía y el conocimiento de N celdas. El agente aplica las acciones que son posibles en este nodo (estado), y así genera más nodos, que serán los hijos del primero, por cada una de las acciones aplicadas. Esto representa la expansión del nodo principal.

Así el agente va expandiendo nodos. Una vez que lo hace con el nodo principal, tiene que elegir otro. Y aquí es justamente donde difiere cada estrategia. Por lo demás, son idénticas. Algunas de las formas de ir eligiendo los nodos podría ser por profundidad, amplitud, o costo uniforme. En esta última existe un costo por cada acción, y la estrategia elije el siguiente nodo a expandir según cuál tenga el menor costo. Otra estrategia es la avara, la cual en lugar de utilizar un costo para los nodos, usa una heurística, que indica qué tan lejos del objetivo está, entonces toma una decisión según la acción que más lo acerque al mismo.

Volviendo al tema del post, en el trabajo práctico teníamos que mostrarle a los profesores que nuestro código funcionaba correctamente, es decir, si habíamos elegido la estrategia de amplitud, entonces la lista de nodos expandidos tenía que tener un orden de acuerdo a la misma. Una forma de hacerlo era escribir un archivo XML que vaya indicando cómo se forma el árbol y qué nodos se eligen. Pero es un poco tedioso leer un archivo así.

Continuá leyendo Visualización de árboles de búsqueda usando LaTeX