martes, 16 de marzo de 2010

Primeras pruebas

De forma muy rapida, que he conseguido un hueco durante el trabajo para poder hacer esta entrada (perdonar por las faltas, pero no quiero cambiar el mapa del teclado ahora).

Este fin de semana termine de implementar el componente MGWindow, y de realizar algunas pruebas sobre el componente MGEntry (desafortunadamente no he podido empezar con los componentes MGComboBox y MGCombo, prefiero empezar a hacer pruebas ahora sobre lo existente, aun asi, espero tenerlo implementado a final de la semana). Las pruebas han resultado exitosas, considerando que he tenido que corregir algunos pequenyos bugs, pero con el tiempo que me ha tomado (alrededor de una hora) se puede considerar un exito :). Tambien quise probar el componente MGWindow, pero creo que antes lo hare con los paneles y una vez lo tenga, probare con MGWindow (mucha funcionalidad es comun, con lo que no importa mucho el orden).

Algunas conclusiones: Que pobre es MonoDevelop. A pesar de tener ya un desarrollo encima de seis anyos, el IDE es muy muy pobre y pesado. El trabajo realizado me podria haber tomado un 60% menos de tiempo con otro IDE (Eclipse, por ejemplo) que tenga a Mono plenamente integrado (No, el plugin para desarrollar C# en Eclipse no me sirve. Solo es un plugin de sintaxis de codigo).
He visto que se puede generar codigo en Java y que sea compilado para generar bytecode capaz de correr en Mono, asi como usar las librerias Gtk en Java. Podria ser una consideracion a tomar en cuenta en caso de que antes de Semana Santa haya desviaciones de tiempo y no sea posible seguir adelante, aunque mi objetivo es desarrollarlo en C# (por el simple hecho de que quiero profundizar en este lenguaje).
Segundo, sobre C#, he estado leyendo en foros que no tiene covarianza (espero traducirlo bien) de tipos. Supongo que los que vengan del mundo Java, como yo, les sonara.
Cuando implementas una Interface, puedes cambiar el tipo de retorno de uno de los metodos implementados por un tipo de clase derivado del tipo definido en el metodo del interface. Pues en C# no es posible, por decision de seguridad, hay error de compilacion. He tenido que hacer un "apanyo", pero no es ni mucho menos bonito, legible, y por supuesto practico (aunque para mi framework lo es) en terminos globales.

Actualizacion: he encontrado un plugin para Eclipse: Improve C#. Parece que esta bien en cuanto a la sintaxis y ejecucion, aunque echo en falta un plugin para correr pruebas de unidad con NUnit. Esta tarde lo probare, aunque no creo que utilice Eclipse. Debido a malas experiencias previas, prefiero desarrollar todo en un mismo IDE.

jueves, 11 de marzo de 2010

Perfilando la primera parte

Buenas a todos.

Después de varios meses con sobresaltos y algún que otro problema, ya voy consiguiendo algo palpable.

Después de haber estado desarrollando el framework durante febrero, ya tengo concluido las clases que componen el núcleo, algunas clases para el tratamiento de errores y validación, y también he implementado FixedContainer, HBox, VBox, LayoutContainer y también he implementado el componente GTK Button y Entry. Como anotación de relevancia, he añadido en todas las clases el prefijo MG, para así distinguirlos de las clases extendidas del framework GTK. Aún tengo planeado realizar alguna otra implantación durante este fin de semana (como Window, ComboBox y Combo).

Una vez realizadas, podré empezar una serie de pruebas (en verdad he ido probando varios componentes durante la implementación, aunque de forma muy trivial), realizando pruebas unitarias, y pruebas de integración de todos los componentes dentro de una pequeña GUI realizada para estos menesteres. Las pruebas en las que estoy interesado son, por orden de prioridad, la respuesta de los componentes a una actualización de la vista (reflejar cambios del modelo en la vista), viceversa (actualización del modelo con datos extraídos de la vista), llamada y comportamiento de los componentes hijos dentro de los widgets que correspondan a instancias del framework, cumplimento de las normas de validación (bien por expresión regular o bien por métodos encontrados en una instancia de un tercer objeto).

Una vez hecho esto, espero que termine antes de Semana Santa, podré realizar posibles cambios en el diseño, o continuar mejorando el sistema de eventos internos del framework ante cambios en modelo y/o componentes. Después de Semana Santa, una vez acabados estos pasos anteriormente descritos, espero seguir haciendo más componentes y llegar a finales de abril con una serie de nuevos componentes.

Este fin de semana, una vez vaya acabando los componentes previstos al comienzo del post, volveré a publicar otro nuevo post con novedades y anécdotas.