Planet

La base de datos actual a sufrido diversos cambios con respecto a la inicial, de todas formas aquí les mostramos como fue nuestro primer boceto y como nos enfrentamos al problema de lograr convertir esas ideas en tablas que nos fuesen útiles.
Para realizar la conexión con la base de datos a través de Mono usamos una de sus librería en conjunto con la librería de SQLite3, la librería de Mono es “Mono.Data.Sqlite.dll” y se encuentra en la carpeta donde se instalo Mono mas concretamente en esta ruta “Mono-2.2\lib\mono\2.0″ con añadir esta última librería a las referencias de nuestro y soltar la librería de SQLite3 en la carpeta donde estemos ejecutando nuestro programa podremos realizar la conexión la base de datos.

Al principio este blog iba a ser para comentar el desarrollo de eOPSOA y discutir decisiones de diseño, explicar como trabajo... etc. Sin embargo, y debido a que casi todo el tiempo que tengo lo dedico a diseñar y programar, apenas he escrito nada sobre el desarrollo. Eso de dejar que el código hable por uno mismo está bien, pero hay veces que uno usa herramientas o tiene truquillos que quizá sean interesantes, y que quizá sean interesantes para los demás.Como comenté antes, la metodología de trabajo que sigo es una adaptación de RUP. Tengo marcadas unas iteraciones, y en cada iteración hay una serie de tareas que tengo que realizar. Normalmente lo que suelo hacer al principio de cada iteración es modelar los requisitos funcionales y realizar el diseño para esa etapa usando Rational Rose y Rational Requisitepro. En los directorios /management/trunk/analysis_design y /management/trunk/requirements podrás encontrar los artefactos. Además, otra tarea que realizo es esbozar la UI, que es de lo que os quiero hablar. Luego le presento todo eso a los tutores del proyecto, y con las correcciones que me hacen refino todo y ya me pongo a programar. Hasta ahora no había subido al repositorio los esbozos de la UI, pero a partir de ahora los iré metiendo en /management/trunk/ui_sketches. Al principio usaba papel y boli, pero el problema que tiene es que al final siempre terminaba perdiendo los esbozos, y como que no tengo scanner difícilmente iba a poder enviarlos por correo. Estuve buscando herramientas de prototipado de interfaces, y la herramienta que más me gustó, y que vengo utilizando, se llama WireframeSketcher, y es otro plugin sobre Eclipse. Como nota friki decir que utiliza EMF y GMF, es curioso lo que se puede hacer con estas herramientas :-). La lástima es que es software propietario, pero el autor no tiene problemas en dar licencias a aquellos que se pongan en contacto con él y participen en un proyecto de Software Libre. Además ha comentado varias veces que en un futuro cercano tiene pensado sacar una versión gratuita más o menos funcional, y quién sabe, quizá hasta termine liberando algo. El ritmo de desarrollo es brutal, y poco a poco se van añadiendo funcionalidades que lo hacen un software muy útil.Las dos imágenes anteriores se corresponden al prototipo que hice, y a la pantalla final que resultó. Aunque quizá la paleta de controles de WireframeSketcher es un poco pequeña, al menos en mi caso es suficiente y se ajusta bastante bien a los controles que ofrece JFace/SWT. Y ya para dejar de hacer spam comentar que la ventaja principal que le veo respecto a otras herramientas de prototipado como Pencil es que es muy sencillo y rápido de usar, se integra con Eclipse, y que funciona realmente bien. Además que aunque sean en blanco y negro, salen los esbozos mu bonicos si O:-)Por último, he subido en el área de documentación de la forja una serie de PDFs que usé para estudiar los prototipos de interfaz de eOPSOA que he estado haciendo.

A pesar de que consideramos que esta fase ya la hemos superado veo de interés plantear aquí los problemas e inquietudes que nos fueron surgiendo a lo largo del desarrollo de Ideldes.
Para lograr encarrilar el proyecto decidimos realizar una serie de reuniones (no digitales) en las cuales planteamos diversos puntos de vista e intercambiamos opiniones, la verdad es que fueron de mucha utilidad, sobre todo para tener los objetivos y métodos más claros. Estas reuniones no fueron únicamente realizadas entre los miembros del proyecto sino que contamos con la ayuda y el apoyo de una Intérprete profesional de la Lengua de Signos, Tamara Corral para solventar aquellas dudas más complejas sobre el correcto uso e interpretación de la Lengua de Signos.
De momento llevamos 2 reuniones hechas y vamos a exponer aquí los resultados obtenidos de su realización:
Primera reunión: (Con Podcast)

• Estudiamos y probamos el SDK de Microsoft para ver que nos podía proporcionar.
• Nos planteamos a grandes rasgos  como iba a ser la interpretación de los signos (como realizar la abstracción del mundo real a código): era importante para nosotros saber detalles significativos sobre la lengua de signos ya que nuestros conocimientos sobre el tema eran nulos.
• Librerías externas que nos pudiesen facilitar un mantenimiento futuro y un desarrollo presente de la aplicación (NHibernate, Log4Net, SQLite…).
• Planteamos la solución de guardar la posición de los dedos como una diferencia entre su posición actual y un punto de referencia (otro dedo “guía”) para que un signo fuese igual siempre con independencia de la zona en la que haya sido capturado. Por ejemplo: ha de ser reconocido el signo tanto si es hecho en las coordenadas (0,0) de la imagen como en la (200, 120).
• ¿Por dónde empezamos a programar? ¡por el tejado no! jajaja
• Nos dimos cuenta que estábamos bastante pillados de tiempo y optamos por una metodología ágil SCRUM.

Principales problemas:

• Como analizar los movimientos y pedir a un sistema de persistencia que comprobara si ese signo existe.
• Dudamos del rendimiento que nos pudiera dar la aplicación al tener que realizar tantas consultas al sistema de persistencia para realizar la comprobación del signo.

Segunda reunión: (Sin Podcast)

• Encontramos otro problema al enfrentarnos a la posibilidad de realizar signos mediante movimientos. Nos planteamos utilizar un lenguaje semi alternativo por las complicaciones que esto pudiese suponer en un principio.
• Tamara nos ilustra sobre la lengua de signos y nos hace darnos cuenta que no todo es tan fácil como pensábamos , debido a que la traducción literal de los signos tienen una formación sintáctica escasa, ya que se omiten algunos significados para hacer más simple la interpretación y es aquí donde nos enfrentamos a uno de los problemas más interesantes ya que no seremos capaces de deducir el contexto en el que se está hablando para encuadrar el conjunto de signos para realizar una traducción fidedigna de lo que se desea expresar.

PSD: “Ahora empieza lo complicado”, llevar todo esto a código
PSD2: Agradecer tanto a Tamara por su apoyo y profesionalidad como a Javier Azcuna por su aporte musical al podcast.
Enlaces | Tamara Corral | Javier Azcuna

planficiacon_pfc
Aquí os dejo la planificación que me he propuesto con cara al concurso y que cumpliré a raja tabla, debido a que he estado programando a la ligera y luego tiene consecuencias nefastas , y encima que uno hace su proyecto de fin de carrera y libre, tiene doble responsabilidad y no debo subir cualquier cosa, ya a partir de ahora me pondré serio con el proyecto
Reitero que a pesar de esto pondré una versión operativa del juego como una rama del proyecto (rama que mejor olvidar y que será un borrador de lo que quiero conseguir)
Me tengo que poner las pilas antes que me absorban  los exámenes de Junio.
Un saludo a todos.

Si habéis echado un vistazo al SVN durante esta semana, habréis visto que ha tenido bastante movimiento y que ha sido debido al fruto de una nueva colaboración en el proyecto.El caso es que Estela me ha echado una mano para internacionalizar eOPSOA. Por ahora la interfaz está traducida al español y al inglés, y dentro de muy poco lo estará también en francés. Que lujazo ¿no? :-P¡Muchas gracias Estela! :-)

Después de alrededor de 4 meses de desarrollo, estoy orgulloso de publicar la versión 0.1.1 de eOPSOA. Esta release no se puede considerar para producción, porque carece de la mayoría de características que pueden hacer eOPSOA útil para el analista. Sin embargo la intención es que se testee, para corregir los pequeños fallos que pueda haber de los cuales no sea consciente.Para descargar eOPSOA tienes tres opciones:

1. La opción recomendada, que es usar el Update Site para Eclipse. Te gestionará él solo las (pocas) dependencias que tiene el proyecto de forma automática y no dolorosa.
2. Desde un fichero con un update site fuera de línea. Lo podrás encontrar en el área de descarga de la forja de Molinux.
3. Si eres desarrollador, o valiente, descargar la última versión del repositorio SVN.

Las características de la versión 0.1.1 son las siguientes:

• Soporte para la caracterización de los programas a certificar, permitiendo la edición, guardado y recuperación de los documentos checklist, glosario y de visión. Estos documentos se cargan desde plantillas XML, de tal forma que la adaptación a nuevas revisiones de estos documentos sería inmediata.
• Soporte para la descripción de los actores del sistema.
• Soporte para la especificación completa de Casos de Uso. Permite especificar los actores involucrados en el UC, las precondiciones/postcondiciones, los flujos básico y alternativos, y las relaciones entre los distintos UC.

Una característica que no se había planteado originalmente, y que creemos que puede ser interesante, es la forma en la que definimos los flujos básicos y alternativos de cada UC. Los flujos están compuestos por pasos, y estos a su vez pueden estar compuestos por pasos. Los pasos se pueden marcar como de entrada o de salida, y asignarles variables.Para la siguiente iteración se va a trabajar en el soporte de pruebas: definición de escenarios, integración con algunas herramientas de testeo funcional y de calidad de código... etc. Si alguna vez habéis trabajado testeando funcionalmente una aplicación, estaréis de acuerdo conmigo en que definir los escenarios y todas las combinaciones de variables es un auténtico rollo. Aquí entra lo que he comentado antes de la decisión de diseño que se ha tomado al implementar el soporte de UC. Vamos a intentar que hasta cierto punto la generación de escenarios sea automática, utilizando la información "extra" que hemos pedido al realizar la definición de los UC.De cómo se implemente el soporte para los Tests de Pruebas va a ser crucial para la utilidad (o inutilidad) de eOPSOA. Próximamente escribiré de cómo estoy realizando esta tarea y de los problemas que estaré encontrando :-)

Eclipse, además de un IDE para Java fantástico, es también una plataforma para el desarrollo de aplicaciones. Estas o bien pueden ser plugins (como el que estoy haciendo yo), o aplicaciones RCP como pueden ser Cool Imaging Project, de unos compañeros que también están compitiendo en el CUSL (saludos!!). El caso es que al ser Eclipse al 99% modular, se presta a ser extendido. La Wikipedia tiene un artículo muy interesante sobre Eclipse, en developer.com hablan de su arquitectura, y en el libro The Java Developer's Guide To Eclipse (muy muy recomendable) hay muchísima más información. Como a veces lo más sencillo es una imagen, he tomado prestada una imagen de ese libro que es representativa de la arquitectura de EclipseQuizá el componente más usado de Eclipse es JDT, porque de un modo u otro todos los que desarrollamos sobre Eclipse lo utilizamos. Pero con la tendencia actual de ver a Eclipse como un framework de desarrollo de aplicaciones han aparecido proyectos alrededor que son muy interesantes, como por ejemplo BIRT, Mylyn, DTP... si, todo son siglas ;-)Uno de estos componentes que me está siendo especialmente útil es EMF, que responde a Eclipse Modeling Framework Project. En plan rápido, EMF es un framework para el modelado y gemeración de código para construir herramientas y otras aplicaciones basadas en un modelo de datos estructurado. Desde la especificación de un modelo descrita en XMI, EMF proporciona herramientas y soporte para generar un conjunto de clases Java para el modelo, además de clases adapter para soportar la visualización y la edición del modelo. Como imagino que esta descripción tampoco es muy útil, y hay sitios donde pueden explicar con más criterio que yo en qué consiste EMF, voy a intentar explicar porqué es útil para mi proyecto.Imaginemos que estamos desarrollando una aplicación en la que hemos identificado un modelo de datos relativamente complejo, y que debemos ser capaces de serializar y deserializar desde XML. Por ejemplo este, descrito en UML, y que modela parte del soporte para Casos de Uso que tiene eOPSOA:Este modelo se podría implementar sin problemas en Java, pero sería una tarea cuanto menos dolorosa. Y si a esto añadimos el asunto de la serialización/deserialización en XML, listeners, adapters... etc., nos podemos dar cuenta que no es un asunto trivial.Si desarrollamos un plugin para Eclipse, una aplicación RCP, o simplemente una programa Java, nos puede resolver la vida. Entre otras muchas cosas, con EMF podemos hacer:

• Describir el modelo de datos a alto nivel. P.e. podemos usar un diagrama de Rational Rose, un diagrama UML, XSD, interfaces Java anotadas... etc. para construir un fichero ecore con el modelo de datos de nuestro sistema.
• Con el fichero ecore, podemos generar un fichero genmodel que a su vez puede ser usado para generar el código Java que describe nuestro modelo. Crea además un editor en línea de comandos y otro gráfico como plugins de Eclipse. Todo eso sin tener que escribir una línea de código ;-)
• Con el código que hemos generado, podemos serializar/deserializar nuestro modelo a XMI y XML, tenemos relaciones entre objetos, notificaciones, notificaciones inversas, adaptadores... etc. Todo ello como he comentado out-of-the-box, solo con la descripción a alto nivel de nuestro modelo y sin escribir (casi) una sola línea de código.
• Podemos manipular el código generado, y si en un futuro hay cambios en el modelo, se puede recargar y regenerar el código, respetándose nuestros cambios.
• Podemos usar los ficheros ecore y genmodel anteriores para crear un editor gráfico (en plan pinchaiconos, copiar y arrastrar) con GMF.
• Y bueno, muchas cosas más que no sé ni creo que vaya a necesitar en un futuro cercano, pero que parecen cosa fina oiga.

A mí al menos, me ha resuelto la vida. Si le echáis un ojo a mi SVN, el plugin org.uclm.eopsoa.core es prácticamente un modelo EMF un poquito grande, y todo el código Java que me genera automáticamente. Si queréis comenzar con esto hay bastante información disponible en Internet, pero lo suyo es comenzar mirando la documentación de EMF, leer la guía para programadores, e intentar hacer los tutoriales. Hay una chuleta de referencia que viene muy bien, y si sabes que te vas a pegar mucho han sacado hace poco la segunda versión del libro EMF: Eclipse Modeling Framework. No es barato pero cubre mucho mucho mucho más de lo que puedas encontrar en Internet, y es extremadamente útil.No sé si os habré convencido, pero para terminar voy a comentar algunas cosas que he aprendido durante estos meses usando EMF:

• En los tutoriales apenas se comenta, pero la forma más cómoda para crear un modelo EMF es editando el fichero ecore con el editor. Muestra un árbol con los elementos, se pueden añadir/eliminar nuevos hijos, y manipular las propiedades en el properties view. Las interfaces Java anotadas son útiles porque proveen de una perspectiva más cercana a la que podemos tener los programadores, pero es mucho más fácil meter la pata y se pierde flexibilidad. Además, que si tu modelo EMF es un poco complejo es un rollo recordar las 80 anotaciones que quizá te hagan falta.
• Procura tener tu modelo EMF lo más limpio, expresivo y rico posible. Si te ves modificando mucho código autogenerado, suele ser señal de que necesitas trabajar más tu modelo.
• El nombre de los atributos va a tener mucho que ver en cómo se va a generar el fichero XMI/XML de persistencia del modelo. No te agobies demasiado si alguna etiqueta queda algo rara; mejor tener una API cómoda para trabajar. Y si alguien tiene que usar tu XML, siempre podrá usar a su vez EMF y entonces te agradecerá las decisiones que hayas tomado.
• NUNCA, NUNCA pienses que no vas a tener que regenerar el modelo (y el código) y muevas paquetes, cambies nombres a clases sin que se entere EMF. Suele pasar cuando en tu proyecto usas una convención de nombres de interfaces/clases distinta a la que genera EMF, y con las facilidades de refactorización que provee Eclipse puede ser goloso liarse la manta a la cabeza, y moverlo y cambiarlo todo de sitio. Pero aunque no quieras, tarde o temprano vas a tener que modificar tu modelo, y al final tendrás un pisto y perderás tiempo.

Espero que este post haya sido útil, si alguien quiere comentar lo que fuera es bienvenido :-)

No sé si alguno se acordará de algunos años como estaba el panorama en GNU/Linux. Yo comencé cuando la cosa iba más o menos bien, allá por el año 2002, y mi primera distribución fue una RedHat 7.3. Por aquel entonces estaba comenzando el tema de las conexiones de banda ancha (aunque realmente no eran tan anchas... ONO ofrecía por aquel entonces 64 kbps) y aunque poco a poco se iba haciendo hueco Internet en casa, no éramos tantos los afortunados internautas. Decía que mi primera distro fue una RedHat 7.3, y aún recuerdo cómo descubrí lo que por aquel entonces se llamaba dependency hell cuando intenté instalar algún que otro RPM suelto que encontré por ahí: el Compu's Messenger (el abuelo del AMSN actual), los infames drivers binarios de la NVIDIA, el JRE 1.4 de Sun, algún que otro juego... etc. Era una gracia eso de tener el modem de 56 kbps y ver como un paquete depende de otro, otro de otro, otro de otro... y después de descargar 60 megas de paquetes descubrir que has liado tal pisto, que no hay otra solución casi que reinstalar de 0 el sistema. Qué tiempos aquellos, luego descubrí Debian y su bendito apt-get; fue entonces cuando descubrí el cielo. Pero eso es otra historia.Todo lo anterior venía a cuento porque parece mentira, y en pleno año 2009 algunas cosas no han cambiado tanto, y si no andas con tiento te puedes encontrar con el mismo problema. No sé si lo habré comentado antes, pero Eclipse es modular 100%... en realidad todo está descompuesto en n-mil plugins. Eso tiene sus ventajas, y a la vez sus desventajas. Quizá su mayor desventaja es la instalación de plugins nuevos, que como no tengas cuidado te puedes encontrar con el problema que he comentado antes: un infierno de dependencias. A partir de la versión 3.2 (creo) Eclipse introdujo un componente muy interesante llamado Update Manager, donde se añadían Update Sites desde los cuales te puedes bajar plugins y features, y con un poco de buena suerte se calculaban las dependencias de tal forma que no tuvieras que sufrir la tortura de resolverlas a mano. Versión a versión ha ido mejorando la cosa y en la versión 3.4, aunque es lento como el infierno, es prácticamente usable.Aprovechando que el proyecto está avanzando poco a poco, y que ya hay algunas cosas que se pueden ver, pensé que quizá sería buena idea montar un Update Site para distribuir de forma rápida el proyecto, y que quien estuviera interesado probara el software no sufriera tortura. Quién sabe, a lo mejor así alguien se anima a rellenar algún que otro bug report... no sé. Hablé con la gente del Centro de Datos de la ESII (gracias Juan Carlos!!! :-)) y han sido tan majos de proporciarme un sitio donde poder ir colgando el Update Site. La URL es http://eopsoa.albacete.org, a que mola ¿verdad? ;-)Bueno, para ser sincero no he colgado todavía nada, pero por ahora he escrito un HTML guarro donde describo de forma somera el proyecto, y las instrucciones para descargar las fuentes y los binarios. Cuando termine un par de cosas que estoy implementando lo subo, palabra O:-)He estado pensando en el estado del blog y del proyecto, y creo que no he sido capaz de describir muy bien de qué va mi proyecto. En parte ha sido por desidia mía, pero por otra parte también es verdad que estoy que no me cojo el culo... por eso he pensado que lo mejor sería colgar la prememoria del proyecto que envié cuando inscribí el proyecto en el CUSL, y que aquel que esté interesado que le eche un ojo.Y nada más por ahora, dentro de poco escribiré otra entrada donde intentaré comentar el estado del proyecto, y de las ideas que tengo para el futuro, que creo que pueden ser interesantes.Happy hacking!!

Otra vez estoy aquí escribiendo unas líneas, y lo primero que quería decir es que muchas gracias a todos, sois gente de p$%& madre :-). No me esperaba que entrara tanta gente y que me diérais tantos ánimos, gracias!!!! Todos me han hecho mucha ilu, pero sobre todo los de Ramón y Miguelillo, que están ambos en Inglaterra (uno en Londres y otro en Cranfield); muchas gracias gambiteros por sacar un ratillo y hacerme una visita :-)Bueno, al turrón. Perdón por saltarme el post que había prometido los dos domingos pasados, pero he estado pringando al máximo para ir sacando esto adelante, y el comienzo se está haciendo un poco durillo. Voy a intentar comentar brevemente qué he estado haciendo estas dos semanas de atrás.Metodología y planificaciónLa metodología de desarrollo que estoy siguiendo es RUP, que junto con UML constituyen la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. Es un proceso iterativo, de tal forma que en cada iteración, y según el estado del proyecto, hay una serie de tareas que se deben de realizar como pueden ser definición de requisitos, realizar análisis y diseño... etc. Una de las ventajas que tiene RUP es que es adaptable a la realidad de cada proyecto, y como en este tengo tan poquito tiempo haré más hincapié en las fases de diseño y de implementación.Dicho esto, he planteado que voy a realizar 5 iteraciones, y he marcado unos objetivos para cada una de ellas. Y sobre estas iteraciones y sus objetivo, he planteado una planificación de lo que debería ser mi trabajo en estos 6 meses de desarrollo. Está realizada con un programa que se llama Planner que bueno, no es perfecto pero es bastante usable.Configuración del repositorioUna de las razones por las que tenía muchas ganicas de que comenzara el CUSL (aparte de porque estoy motivado) era porque quería contar lo antes posible con un control de versiones para ir subiendo cosillas e ir organizándome mejor; llevo usando regularmente SVN desde hace un par de años, y estoy más que contento con él. El caso es que después de que me abrieran un proyecto en la forja de Molinux, ya pude comenzar a meter mano al repositorio, que es lo que quería.Un proyecto software produce muchos artefactos o productos: documentación, especificación de requisitos, diagramas UML, código... etc., y la mayoría es posible que vayan evolucionando según vaya avanzando el proyecto. Es interesante entonces meterlos en el control de versiones, y para ser mínimamente organizado es necesario definir un layout del repositorio. Si le echáis un ojo al repositorio de eOPSOA veréis la siguiente configuración:

• code: en este directorio iré subiendo el código fuente de la aplicación. Dentro hay otros tres directorios trunk, branches y tags. No es obligatorio pero es una práctica común dentro del mundo de Subversion; muy brevemente se podría decir que en el directorio trunk se realizaría el desarrollo de la rama estable del producto, en el directorio branches se podrían crear ramas paralelas de desarrollo, sobre todo para añadir características nuevas que no podrían ser muy estables, hasta que maduran lo suficiente como para volver a trunk. Y en el directorio tags se podrían ir creando puntos interesantes, como por ejemplo la revisión que marca la versión 1.0 del software.
• management: aquí iré subiendo los artefactos que se vayan generando, como por ejemplo el subdirectorio analysis_design que contendrá el modelo de Rational Rose de diseño, planning donde irá la planificación del proyecto, requirements el modelo de requisitos de Rational RequisitePro... etc.
• y por último, proof-of-concept, que será algo parecido aun cajón de sastre, donde iré subiendo ejemplillos o pruebas que crea que puedan ser útiles.

Estado actual, y trabajo para esta semana...Teniendo una planificación, y un repositorio, tenía las herramientas que me hacían falta para empezar a trabajar y crear cosas útiles. Por algo habré hecho ¿no?, aparte de no escribir en el blog... :-P. A estas alturas puedo decir que he finalizado la primera iteración ¡bien!, y tengo lo siguiente:

• Tengo especificados los requisitos funcionales (casos de uso) para la primera y la segunda iteración. Me falta generar documentación, UML sobre todo, para describir la activación de los plugins en Eclipse, estructuras de datos y demás.
• He creado el esqueleto/armazón/stub de los dos módulos que voy a desarrollar por ahora. Por ahora hacen algo muy básico: básicamente se limitan a registrarse en Eclipse, definen una perspectiva, una naturaleza y crean proyectos (vacíos), pero es un comienzo. Sobre estos dos plugins iré construyendo el resto de funcionalidades.
• ¿He dicho que estoy aprendiendo un huevo sobre Eclipse? ;-)

El trabajo que se plantea para esta semana que entra es el siguiente:

1. Especificar los modelos EMF para el asunto de la gestión de los documentos que necesita OPSOA para caracterizar el software a certificar: el documento de visión , el glosario y un checklist.
2. Crear una serie de formularios para dar soporte a la edición y posterior persistencia en XML de los modelos anteriores.

Las tareas no parecen tampoco muy complicadas, y el asunto de la persistencia en XML no es complicada porque aunque lleva más trabajo definir los modelos de los documentos con EMF, merece la pena porque se encarga el mismo EMF en serializar y deserializar el modelo en XML.El principal problema con el que me enfrento ahora es el siguiente... que Eclipse es muy grande, y muchas cosas dependen de otras para realizarlas. Por poner un ejemplo, para hacer el formulario que he comentado antes, debo implementar la interfaz IFormEditor del API de Eclipse, porque realmente estoy realizando un editor. Bueno, pues para comprender el asunto de los editores, antes debo estudiar también las views, y para las views necesito conocer anteriormente el tema de las JFace Viewers... ahí es na. El API es enorme, hay muchas cosas que dependen de otras, y a diferencia del API de Sun (que es la que conocía hasta ahora) que es más restrictiva en cierto modo, y te "guía" a la hora de realizar las cosas, esta es mucho más flexible. Puedes hacer lo que quieras a tu aire... pero lo primero, posiblemente tardes más, y no se integre bien con la plataforma, o directamente no te funcione. O lo haces a la Eclipse way, para ello debes estudiar y mirar código de los demás, y eso también lleva tiempo y por desgracia no es algo de lo que me sobre actualmente.Me está ayudando un montón un libro que compré en eBay hace un par de semanas, se llama The Java Developer's Guide to Eclipse. Es un libro muy muy bueno, yo diría que fundamental si se está comenzando con el asunto de la creación de plugins/RCP para la plataforma Eclipse. Es un mostrenco de más de 1000 páginas, escrito por ingenieros de IBM que estuvieron/están trabajando en Eclipse. Entre historias de cambio euro/dolar, y gastos de envío me costó algo más de 40€, pero sinceramente creo que vale cada uno de esos euros :-)Bueno, nada más por esta semana, un abrazo muy grande a todos :-)Happy hacking!!

Parece que por fin han comenzado las actividades del II Concurso Universitario de Software Libre de Castilla-La Mancha, suscrito en el III Concurso Universitario de Software Libre Estatal en su modalidad local.Lo primero presentarme: me llamo David Castellanos Serrano, soy estudiante de Ingeniería Informática en la Universidad de Castilla-La Mancha, y durante este curso estaré ocupado con algunas asignaturas, y sobre todo con mi Proyecto Fin de Carrera. Mi PFC trata sobre el desarrollo de una herramienta que de soporte a un marco metodológico de certificación de calidad de Software Libre llamada OPSOA (OPen SOurce Assessment), y que han desarrollado dos profesores de aquí, y que dan la casualidad que son los tutores de mi proyecto.Mi participación en la III CUSL es presentando mi PFC, y el proyecto se llama eOPSOA. Así a grandes rasgos, y completando lo que he escrito antes, es implementar una serie de plugins para Eclipse para soportar el marco metodológico OPSOA. El año pasado también estuve apunto de participar junto con mi grupo de una asignatura en otro proyecto, pero nos quedamos fuera por el entorno que usábamos (VS C# puagh!).Comentando por encima algunas cosillas técnicas del proyecto, que a todos nos encantan: el lenguaje de programación será Java 6, estará licenciado con la licencia EPL, usaré la plataforma Eclipse y sus n-mil frameworks y librerías (SWT, JFace, EMF, GMF, CNF... etc.). ¿He dicho que me encantan las siglas?, pues lo digo ahora ;-)Desconozco quién será la audiencia de este blog, posiblemente se limite a mi novia, algunos amigos (hasta que se aburran) y algún que otro despistaillo incauto que pille. La idea que llevo yo es intentar al menos hacer una entrada semanal, posiblemente los domingos por la tarde. Intentaré comentar qué quiero hacer la semana siguiente, qué tal se me fue la anterior, y según cómo me vea de tiempo a lo mejor comento algunas decisiones de diseño y de implementación que voy tomando según avanza el tiempo, ya veré.Pues ahí queda todo, nos vemos este domingo ;-). Mi ocupación de esta semana es aprender un poquillo sobre cómo gestiona Eclipse el asunto de los proyectos: workspaces, natures, navigator...Happy hacking!