Por fin puedo decir que ha terminado el semestre, despuí©s de 2 semanas extras, ha terminado. El fin fue bueno, no excelente. Ahora a seguir con los demí¡s planes.

Maí±ana sabrí© si fui aceptado en el curso de Verano. Si no es así­, no importa, lo mí¡s probable es que haga mis Residencias Profesionales en un lugar local así­ que no habrí¡ sufrimiento por el rechazo del curso de verano. Hay dos escenarios en cuestií³n a si soy o no aceptado, el primero es que sin duda apoyarí© notablemente a la comunidad, y el otro es que estarí© mí¡s metido a la U este duro, caluroso y corto mes. Cualquier escenario me conviene, terminar es la prioridad.

Hay algunas cosas que tengo planteado hacer, muchas relacionadas a MonoUML, una idea que esta dí¡ndome vueltas y vueltas por la cabeza es una que me menciono Katia 'KFC' Caní©pa, de una aplicacií³n que actua como 'mentor' mientras vas realizando tu modelado, llamada WayPointer, por los demos se ve muy interesante, posiblemente serí­a un componente extra para nuestro proyecto, algo de IA no caí© mal. La documentacií³n debe estar terminada lo mí¡s pronto posible, yo siempre peleo que la documentacií³n es lo mí¡s importante (y aunque estí© al usuario no parece importarle y no la lea hay que hacerla) así­ que hay que marcar las trazas necesarias para esto, Jacob Cervantes ha bautizado este componente como MUDoc, osea MonoUML Documentor, una cosa interesante tambií©n. Ademí¡s voy a comenzar a hacer la parte de Forward Engineering: Documentation, ¿Quí© bonito serí­a hacer un modelado en UML y que a partir de este se genere el cí³digo en X lenguaje (cosa que ya esta :D) y que ademí¡s te genere una bonita documentacií³n en Docbook que tenga los famosos links entre objetos que tengan relacií³n (como las clases), los comentarios escritos (owned comments), ademí¡s de una captura de cada objeto, por ejemplo, si es un diagrama de clases una captura de ella, y demí¡s cosas (estoy abierto a sugerencias), cosas cí³mo esas hacen verdaderamente productivo al Ingeniero de Software, pensar en sentarse a programar sin antes haber plasmado una solucií³n implementable ya no sirve, pensar la solucií³n mientras se programa es ineficiente. Tambií©n hay que mejorar la usabilidad de MonoUML, hay varios dií¡logos que necesitan un retoque, corregir los bugs, mejorar el rendimiento, hacer la documentacií³n MonoDoc y demí¡s cosas que salgan.

En resíºmen, si que hay cosas que hacer y falta mencionar todos esos proyectos de ganancia, los "laborales", ademí¡s como que siento que Mono Hispano necesita un retoque grí¡fico... ¿no?

Back to posts