Design Patterns

The design patterns were created to be used, but at what cost must be followed?, when is appropriated brake it?, it's a complicated thing, specially when you wanna have well documented softwares and extensible.

Herramienta para Diagramas de secuencia

Hoy me cansé de las herramientas pussy (aka ide-all-in-one-use-just-the-mouse) y comencé a utilizar una herramienta a lo menos poco usual, pues consiste en que el diagrama de secuencia lo programas, es decir, escribes la logica del diagrama y la herramienta se encarga generar la gráfica :) con eso me olvidé de esos problemas malditos de 'quedó un poco corrido', 'quedo desalineado', etc..

Una muestra del primer diagrama que hice y me tomó solamente unos 10 minutos, entre cranearme la lógica del diagrama de secuencias y aprender la sintaxis (que por cierto un muy pequeña)
con el siguiente script

Usuario:Actor
x:ViewMainWindow ":ViewMainWindow"
y:y ":ControlMainwindow"
z:z ":Project"
a:a ":ControlSaveFileDialog"
b:b ":ViewSaveFileDialog"

Usuario:x.Abrir Proyecto
x:models=y.open_project()
y:a.ControlSaveFileDialog()
a:path=b.ViewSavefileDialog
y:path=a.get_path()
y:z.new Project()
y:models=z.get_model_list()

Para obtener como resultado esto otro


Definitivamente una herramienta que apunta a la productividad.

100% recomendada, el sitio de la herramienta es: http://sdedit.sourceforge.net

A pesar de que está en Java con swing, me gustó caleta :) quizás podria algún día reescribirla en pygtk xD e integrarla a mi herramienta case :D alguien se anota para esa feature :P

holy shit

This is one of the most biggest class diagram that i have done, and still is growing, because there is a lot of properties and methods that still i must define.

If somebody have some paper, book, article or anything about recomendations of how to define a plugin architecture, please let me know, i am looking for related information to improve the quality of the plugins architecture of my case tool, but the lack of material is impressive, so i am trying to imitate the architectures defined in other software tools (like media players)

listeining: am ende der stille, lacrimosa

Un repositorio de buenos papers

Hoy investigando acerca de los RDBMS para mi proyecto de título fui a dar al portal de la ACM y resultó ser un lugar increiblemente bueno y que debido a que se requiere un registro (gratuito y de pago) para acceder a los contenidos no aparece en los resultados del papá de los buscadores.

Les recomiendo que visiten el sitio y busquen temas que les interesen, por ejemplo yo me bajé "The Relational Model for Database Management" de Edgar Codd, además busqué por el topico 'case tools' y aparecienron muchos papers de todo tipo con información interesante, como por ejemplo Why are CASE tools not used?" de Juhani Iivari

Escuchando: Night Train from Back To The Future OST

Cosas que un desarrollador debe saber

Es habitual que cuando uno aprende a programar (ya sea educación formal o autodidacta) en lo que se pone énfasis es en el lenguaje, es decir, la controles de flujo, las iteraciones, etc. Luego cuando uno domina eso y comienza a desarrollar programas más grandes y comienzan a aparecer errores difíciles de encontrar lo que uno instintivamente hace es comenzar a poner print's (printf(), writeln, etc.) de la variables de interés, luego cuando son problemas más complejos y que hacen uso intensivo de cpu y uno busca mejorar el rendimiento (algoritmos golosos, dividir para conquistar, programación dinámica, etc.) nuevamente se echa mano a los print's y más o menos calcula en que parte se tarda más en pasar el flujo (los más avezados imprimen la hora y los aún más avezados hacen un difftime), PERO ¿por que mierda, los profesores, no nos dicen que existen herramientas para hacer lo mismo?. Yo en la universidad nunca le escuché a hablar a un profe del profiling, de usar un debugger, etc.

Pues bueno aquí va un pequeño esbozo de en que momento usar que cosas:

Si tu programa tiene errores y hace cálculos absurdos, lo que debes utilizar es un debugger, con eso puedes hacer lo mismo que con los print's (pero sin contaminar el código con print's) y muchas otras cosas más, como por ejemplo cuando tu aplicación se va de sgfault puedes imprimir el stack, puedes ver los valores que habian en las variables antes del segfault, puedes poner breakpoints (un breakpoint es un punto del código donde se queda en pausa el código y puedes comenzar a ejecutar step-by-step o hasta el siguiente break, etc.). Traten de hace eso con solamente print's XD. La primera vez que usen el debugger les quitará harto tiempo en aprender las cosas básicas (en especial si usas gdb como los machitos, aka sin-gui :P), pero a largo plazo el beneficio es enorme. (si usas python te puede interesar ver Introducing the pydb Debugger)

Si tu programa ha crecido y comenzó a ponerse un devorador de memoría y/o cpu, pues entonces haz profiling de tu aplicación :) y el profiling es aplicable también a la red (en caso de que tu software haga uso de ella), los datos obtenidos los podrás graficar y análizar los casos en que tu aplicación se pone lenta etc. (si les interesa el tema les recomiendo el video Linux.conf.au Profiling Desktop Apps)

Eso fue el consejo del día de hoy :P

PD: se dice que el profiling en linux es algo limitado debido a la falta de hooks en el kernel, pero eso no me consta empíricamente :P
PD2: más información en wikipedia: Performance analysis y Debugging

Han visto una interfaz más mala?

El otro día tuve que borrar a una persona de mi lista de contactos de msn messenger desde el Messenger Live (o algo así, la aplicación oficial para msn) y obtuve esta horrible ventana de diálogo


la primera opción está horriblemente mal redactada, se presta confusión con facilidad, por favor niños, no hagan esa estupidez con sus interfaces, felipe te aconseja xD

OMT++ la nueva moda

Este semestre ya ha terminado de reventarme los timpanos la palabra "metodología OMT++", en mi universidad se ha convertido en una de las metodologías fetiches de profesores y memoristas, casi todas las personas que conozco han usado OMT++ en el desarrollo de su proyecto de título, este semestre a mi me ha tocado meterme a hacer cosas con esta, y me he dado cuenta de las razones que han hecho que todos la amen :P pues la razón es que es sencilla y fácil de hacer para los que no somos muy amigos de la redacción de largos documentos.

En ayudantia del profesor Andrés Rice nos dijo que el tipo que la habia desarrollado trabajaba en nokia y se llamaba Ari Jaaksi, pues me puse a investigar acerca de él y O_O gran sorpresa, él tiene el cargo 'Head of Nokia's open source software operations' y más aún, está intimamente ligado al desarrollo de la Nokia Internet Tablet, y aún más allá este año será speaker de la Guadec (Gnome Users And Developers Europe Conference)

Estándar ESA

Pues en la universidad actualmente estoy en el ramo 'calidad de software', pues bueno aquí nos tocó desarrollar una pequeña calculadora financiera (el software no es lo más relevante), pero la parte importante es que el proyecto debía ser desarrollado utilizado el Estándar ESA (Europe Space Agency), el estándar tiene la intención de _no_ dejar nada en el aire, dejar todo absolutamente detallado, sin cabos sueltos.

Imaginen que para esta calculadora de 2000 líneas de código en lenguaje C (asi que imaginen que si fuera python serian como 500 lineas) se requirió hacer 5 documentos (URD,SRD,ADD,DDD y SUM) que en total deben de haber sido fácilmente unas 200 páginas (después que le pregunte a mis compañeros de grupo dejaré los docs disponibles).

Por lo tanto la lección es que hay muuuucha documentación y los empleados son reemplazables debido a que como todo está absolutamente documentado el proyecto no está amarrado a las personas, pero creanme que si el proyecto no va a durar menos de 2 años no es bueno meterse en algo como esto.

UPDATE: los documentos de la tarea que me tocó hacer están disponibles en mi sección de documentos, los documentos no están perfectos (como toda tarea :-\) pero tampoco están horriblemente malos, usese con precaución ;)