Bueno, despues del congelamiento del proyecto sufrido el año pasado debido a muchas razones (aunque ninguna sirva de excusa) me dispongo otro año a intentarlo de nuevo. Otra vez concurso con GConta 2.0 en el Concurso de Software Libre Universitario, y por su puesto, otra vez utilizandolo para obligarme a terminar de una vez por todas el dichoso proyecto de fin de carrera (último escoyo para conseguir el título de una vez por todas).

Esta vez voy a intentar hacer bien las cosas, así que desde el principio me centraré en la documentación, para que después no me pille el toro a la hora de entregar el proyecto. Para esto he decidido realizarla en Métrica 3 (mas o menos lo que me permite el tiempo y mi paciencia) . He encontrado una página de la Consejería Superior de Administración electrónica! de Métrica 3 para tontos, solo les ha faltado la portada:

Bromas malas a parte, la verdad es que la página lo explica todo bien clarito, por lo que me he animado a utilizar el gestor de tareas del proyecto para gestionar las Actividades y Tareas de métrica 3 mientras documento y construyo la aplicación.

Esperemos que este año tenga mas tiempo y ganas que el año pasado. La verdad es que animos no me faltan, y más aún cuando ya hay gente que se ha ofrecido a ayudarme (desde bolivia nada menos) , además de informarme que la versión de gconta 1.0, ha sido utilizada para cursos de contabilidad en la universidad. Si es que este tipo de recompensa personal te aumenta el karma y es lo que te hace enamorarte del software libre. Gracias a todos a los que me apoyan.

Bueno, basta de charla y a trabajar. Y se me olvidaba, suerte a todos en el concurso

Si en el post anterior comentaba las dependencias con MonoDevelop, debido a que GConta usaba el modelo de plugins de éste, resulta que ayer, casualidades de la vida, se ha liberado Mono.Addins, que viene a sustituir al framework de plugins de MonoDevelop. Encima sale después de mucho tiempo estudiando el código fuente de MonoDevelop … :’(

Mono.Addins es un framework para crear aplicaciones extensibles, y librerías que extiendan las funcionalidades de estas aplicaciones. Esta basado en el código de MonoDevelop (que estaba basado en el código de SharpDevelop), simplificando algunas cosas y eliminando la dependencia de MonoDevelop. De hecho se tiene previsto migrar MonoDevelop (la parte de gestión de los plugins, etc) a Mono.Addins. Es de agradecer que junto a la liberación de este framework se incluyan también documentación de cómo utilizarlo, ya que en MonoDevelop era inexsistente (y la que había estaba muy anticuada).

Así pues, comenzaré a pasar la aplicación a Mono.Addins ya que no hay que realizar grandes cambios. Además como dije antes, se elimina las dependencias con MonoDevelop del todo. La idea detrás de Gconta, es crear un framework para el desarrollo de aplicaciones de gestión orientadas a la Pyme. Como ejemplo, de uso de este framework, está el propio programa de contabilidad que viene a sustituir a gconta 1.0. Las dependencias quedarán así:

• MonoDevelop.Dock: Pasa a llamarse Gdl.Dock, que es la implementación en C# de gdl, una librería creada por la gente de anjuta, para permitir el reordamiento de widgets.
• Mono.Addins: El núcleo para la gestión de las extensiones.
• GConta.Core: Esta es la parte más importante ya que contiene el modelo y la implementación de una API para el acceso a la información contable de las empresas. Mediante esta API se podrá crear cuentas, apuntes, consultar asientos, clientes, etc
• GConta.Core.Gui: Contendrá algunos elementos gráficos para facilitar la creación de las aplicaciones, como ventanas de progreso, alertas, etc. Mucho de este código se basará en MonoDevelop.Core.Gui.
• GConta.Contabilidad: La implementación de la aplicación de contabilidad (finalidad última del proyecto) usuando el framework de GConta.

Esperemos que no haya mas cambios en las dependecias!

El proyecto sigue adelante (aunque lentamente). La plataforma MonoDevelop, realmente no estaba preparada para la creación de otras aplicaciones graficas. Es decir, el control de las perspectivas y la definición de las barras de herrmamientas y las vistas, forman parte de MonoDevelop.Ide. Es por eso que parte de estas funcionalidades las tendré que portar a GConta.Gui. Aunque de estos detalles hablaré mas adelante. Por ahora las dependencias con MonoDevelop son las siguientes:

• MonoDevelop.Core: Contiene la funcionalidad básica para la carga de plugins, y la creación de los arboles con las extensiones.
• MonoDevelop.Gui: Contiene algunas ventanas utilies, como ventanas de progreso, información y asistentes.
• MonoDevelop.Components: Principalmente, contiene las barras de herramientas ajustables, ademas de clases para facilitar la construcción de estas y menus.
• MonoDevelop.Dock: Contiene la funcionalidad de las vistas, pudiendo ordenar y desacoplar los Pads (o vistas), ademas de poder guardar la disposición de éstas (layout o perspectivas).

Pronto habrá avances gráficos, que es lo que la mayoría de la gente quiere. Hasta que se pueda cargar correctamente los Pads y menús mediante los correspondientes Addins, dejo un prototipo de pantalla de GConta, para que se haga una idea de la información adicional que las vistas pueden proporcionar.

Por otra parte estoy intentando configurar Ibatis.Net con SQLite de forma que sea fácil la creación de empresas, pero teniendo en cuenta que en un futuro se pueda utilizar otros SGBD, o un incluso otra capa de persitencia como NHibernate, para ello voy a usar la implementación del DAO que viene con Ibatis.Net. Seguiremos informando!

Bueno, escribo para decir que el proyecto sigue vivo, aunque no lo parezca. He estado como la mayoria de participantes liado con los examenes (además del trabajo…). Pese a todo seguía con la investigación de la plataforma de MonoDevelop y el desarrollo de GConta. Iré subiendo información con forme la vaya pasando a limpio. Como anticipo dejo un diagrama de clases, sobre el paquete MonoDevelop.Core.

Lo más interesante de este diagrama, es la clase Runtime, y sobre todo el AddInService, donde reside toda la magía de las extensiones, ya que es ésta clase la que se ocupa de cargar dinámicamente los archivos .dll de las extensiones, y se ocupa de mantener actualizado el arbol de extensiones.

Uno de los objetivos de este proyecto, también era aprender C#, y sobre todo, desde el punto de vista de un desarrollador java. Es por eso que también estoy confeccionando una lista de “cosas extrañas” a los ojos de los javatos. Como por ejemplo, la palabra clave params.

public void UseParams (params int[] list);
...
UseParams(new int[4] {4, 5, 2, 1});
UseParams(1, 2);
UseParams(5, 6, 7);

Ahí podemos ver un ejemplo de uso de params. No será un revolución pero desde luego que más simple sí que queda.

Hoy durante el desayuno me he llevado una grata sorpresa. En uno de los multiples diarios gratuitos aparecía un noticia (micro noticia) sobre nuestro concurso de software libre, este es el recorte:

El diario es www.metrodirecto.com en la edición de sevilla. La verdad es que 94 proyectos son muchos proyectos, esperemos que lleguen muchos a la final, y sobre todo el mio!

Ya voy teniendo idea mas completa de las funcionalidades que ofrece el núcleo de MonoDevelop, así como el ciclo de vida de los plugin y los servicios que estan disponibles, como Operaciones asincronas, Monitores de progreso, Persistencia de propiedades etc.

Pronto mostrare otro video (esta vez con voz) con un plugin que permite ser extendido!. Se creará un plugin que será extendido por otro plugin :), esto será el pan de cada día de esta arquitectura.

En monodevelop se pueden definir aplicaciones (IAplication), mediante la herramienta mdtool. Por defecto arranca la herramienta IDE, que es el entorno de desarrollo, pero podemos ejecutar cualquier otra. Para obtener un listado de las aplicaciones registradas podemos hacer:

mdtool -q

Con la herramienta mdtool setup dir-link se pueden agregar directorios personales para plugins ademas de instalar manualmente los addins. Esto es bueno para no “ensuciar” la carpeta de addins de monodevelop, además de no necesitar permisos de superusuario para probar los addins.

Cuando busque una solución a la publicación web (mediawiki + plugin para exportar estaticamente?) subiré un par de chuletas que me estoy haciendo, sobre trozos de código útiles para monodevelop, y trozos de código de .net para javatos :D.

También comentar que al fin he podido utilizar gconta como proyecto por lo que tengo un motivo mas para esforzarme, así que andaos con cuidado

Sigo inmerso en el analisis de gconta, y mas o menos, ya he decidido en que componentes se va a dividir y que librerias voy a utilizar. Por ejemplo para el acceso a datos voy a utilizar iBatis, con el correspondiente patrón DAO, para independizar el acceso. Esta parte es un poco mas compleja, ya que los addins deben cooperar y deberían utilizar el mismo método para la persistencia que tenga configurado el DAO …

Lo que sigo buscando es un generador de informes para mono, para los documentos que se tengan que generar. Creo que iTextSharp es demasiado bajo nivel, ademas me gustaría permitir que se modificaran facilmene las plantillas. En java me interesaba mucho jooreports, que era una librería para generar los informes en formato OpenOffice. Para ello se creaba un documento .odt, se extraía el archivo con el contenido (content.xml) y se editaba directamente este archivo con un lenguage freemarker, para marcar donde agregar los datos.

Freemarker tampoco esta para mono, con ikvmc se puede convertir los .class en una .dll y poder utilizarla en el proyecto, pero quizás implemente un subconjunto de freemarker y jooreports, y me cree mi propio generador orientado a openoffice. Seguiremos informando.

Despues de estar jugando con la arquitectura de monodelop, creando vistas, layout, comando … y despues de trastear tambien con vnc2swf, me he decidido a crear un tutorial de como crear un plugin con monodevelop. Despues de probar con Xnest, vnc2server, tightvncserver, x11vnc, lo mas estable (al menos para mi) para crear los screen cast es grabar el escritorio actual utilizando vino como servidor de vnc.

En el video se muestra como crear un addin, explicando un poco el formato del archivo addin.xml, la configuración del proyecto con monodevelop, y como instalar los plugins en monodevelop. El plugin solo es un ejemplo, no sé si sera de mucha utilidad

En un post anterior se habla de un cliente svn estático, gracias por el enlace ;), era justo lo que necesitaba para tener también la pagina web en el svn y actualizarla facilmente.

Al fin tengo acceso a la shell de la forja, para poder crear una pagina web un poco más decente, después de que me arreglaran los fallos al crear mi cuenta en los servidores de la forja.

Como tengo acceso a varios ordenadores, y no me gusta recordar distintas contraseñas, utilizo la autenticación con clave publica/privada. Hasta ahora todo los usuarios de mis ordenadores era el mismo, pero ahora para la shell de la forja tengo otro distinto. Además no me gustaba tener la misma clave privada para sf.net y para forja.rediris.es.
Así que generé dos clave privadas. Pero para la autenticación se necesita especificar a la hora de acceder que clave privada se va a usar, por lo que para acceder a la forja tenía que poner algo como esto:

ssh csl-gconta@csl-gconta.forja.rediris.es -i ~/.ssh/id_rsa_rediris

Así para cada ordenador que me conectaba, necesitaba especificar el usuario, el host y la clave privada, a veces el puerto … Como soy muy vago, me creé un bash para esto, aunque me parecía un poco cutre, así que me puse a leer el man de ssh, y encontré lo que necesitaba. Mediante el archivo ~/.ssh/config, se puede especificar alias, de la siguiente manera:

# Lineas para acceso a la forja
Host forja
HostName csl-gconta.forja.rediris.es
User csl-gconta
IdentityFile ~/.ssh/id_rsa_rediris

# Lineas para acceso a sf.net
Host sf
HostName shell.sourceforge.net
User pepe
IdentifyFile ~/.ssh/id_rsa_sf

Las opciones son bastantes claras. Ahora cada acceso a mis ordenadores, los tengo configurados de esta manera, por lo que para acceder tan solo necesito:

ssh forja

o para sourceforge:

ssh sf

Aunque al final del todo, me di cuenta que la shell de la forja, hace un chroot jail, por lo que la cosa está bastante limitada. Sin php, ni python, ni perl, ni acceso a base de datos. Los comandos son bastantes escasos, aunque se entiende que se quiera evitar que los usuarios curioseen el sistema sin necesidad.

Resumiendo, que me quedo sin mediawiki, ni Trac para gestionar el proyecto. Abrá que volver al html puro y duro. Al menos podré utilizar el servidor para subir algún que otro screencast.

Este finde para que no se diga que no me esfuerzo en el proyecto, he buscado un experto contable con gran experiencia, para tener una sesión de BrainStorming. Bueno, realmente no era un experto, sino una experta, y no he tenido que buscar mucho (las ventajas de tener una novia diplomada en empresariales …).

Así que nos pusimos manos a la obra (sesión de brainstorming, mal pensados) y estuvimos soltando ideas sobre que cosas podría llegar a tener una buena aplicación de contabilidad. Después sacamos una serie de palabras claves, sobre las cuales desarrolar las ideas:

Cuentas, Libro de Iva, Asientos, Libro de Iva, Facturas, Libro de Iva, Clientes, Libro de Iva, Informes, Usuarios y Perfiles, Libro de Iva … y por que dije que parara. Aunque noté que ella insitía en algo.

También se da uno cuenta de qué es lo importante en una aplicación o mejor dicho, le intenté vender la moto de que la aplicación es nueva, de que la arquitectura interna va a cambiar, de que será más extensible, C# nuevo lenguaje y plataforma mono, etc. Lo único que me preguntó es que si iba a seguir teniendo los mismos iconos. Así pues, confirmé que en efecto, iba a tener los mismos iconos y alguno más! y ya pareció convencerle la idea.

Esto del marketing no es lo mio. Así que resumiendo para los no informaticos: el gconta más el ansiado Libro de Iva, y por supuesto, repetando los iconos! como no!!