Archive for the ‘proyectoradio’ Category

Developer mode – ON

Sábado, 4 \04UTC octubre , 2008

Pues eso, que he vuelto a poner el modo “developer” y estoy escribiendo algunas funcionalidades nuevas para ProyectoRadio. Cuando estén más maduras las comentaré con muchas ganas por aquí, mientras tanto me sumerjo de nuevo en el fascinante mundo de C# y .NET, que estoy mucho más oxidado de lo que pensaba :(.

Anuncios

Nuevo título del blog

Sábado, 14 \14UTC junio , 2008

Después de haber cambiado la imagen de la cabecera del blog, me he decidido por fin a cambiar el título.

He pasado de “ProyectoRadio (y otras cosas…)” a un mucho más realista “Otras cosas… (y ProyectoRadio)”. El motivo está bastante claro. Cuando empecé el blog dedicaba mucho mucho mucho de mi tiempo libre a un proyecto personal de desarrollo software: “ProyectoRadio“. Esto generaba muchísimas ideas y contenidos para el blog y el título original estaba totalmente justificado.

De un tiempo a esta parte, he empezado a dedicar mucho más tiempo a otras cosas en mi tiempo libre, últimamente me ha dado por la fotografía, pero bueno, no exclusivamente. Así que si echáis un ojo hacia atrás en el blog veréis que hace ya bastante tiempo que no publico nada de ProyectoRadio. Esto no quiere decir que de vez en cuando haga cositas pero ya no al nivel que las hacía. Así que me ha parecido justo (y necesario) cambiar de una vez el título del blog.

Aplicaciones profesionales

Domingo, 3 \03UTC septiembre , 2006

Como las personas, las aplicaciones profesionales, además de serlo, tienen que parecerlo (1).

Da igual que se escriban en C o python, para Unix o para la Web, la máxima (1) debe cumplirse. Ya no es solo un criterio de usabilidad, si no de imagen. Y es que somos tan buenos haciendo software como lo parecen nuestras aplicaciones. Si tienen mala pinta uno se puede dar por perdido.

Esta reflexión tiene un claro origen. La interfaz de usuario de ProyectoRadio. Hace poco escribí un post un poco más técnico sobre las interfaces gráficas y muy relacionado con la apariencia y comportamiento de estas. Desde hace un tiempo voy, poco a poco, modificando la UI del software para ir consiguiendo que esta sea un poco más profesional cada día. Además, de rebote, voy consiguiente usabilidad, que no es poco.

El core de la aplicación es todo un sistema de objetos asociados a los conceptos de Project, y ProjectItem. Es un sistema escalable, flexible y muy genérico. A día de hoy, por ejemplo, crear un nuevo tipo de cartografía, método de propagación o importador es tan solo un problema de heredar de una clase apropiada e implementar unos métodos necesarios. Pero toda esta funcionalidad y flexibilidad no garantiza absolutamente nada con respecto a las sensaciones que un usuario pueda tener delante del soft.

Así pues, me he decidido a invertir cierta cantidad de tiempo en reescribir parte del código de los controles y los Forms de usuario. Además estoy escribiendo pequeñas herramientas para tareas que pueden ser tediosas, como conectar redes de forma masiva o reposicionar puntos en el mapa.

Todo esto para conseguir que además de bien diseñado por dentro, el software lo esté por fuera.

Exportar con AODL

Domingo, 3 \03UTC septiembre , 2006

Hoy he acabado otra de esas funcionalidades para ProyectoRadio que tenía pendientes en mi ToDo desde casi el primer día, o bueno, desde el día que hice el exportador a Word. Tachán, aquí presento El exportador a OpenDocument (Text ). Eso sí, originalmente la idea era exportar a Open Office, pero por el medio se especificó el estándar OpenDocument.

Me gustan mucho este tipo de formatos, están totalmente especificados y estandarizados. Así, cualquiera puede coger esa especificación y escribir un programa que sea capaz de editarlos. OpenOffice implementa estos formatos como el formato predefinido para sus documentos. Como además soy usuario habitual de OO en mi trabajo y de forma personal, pues mejor aún.

Basándome en el párrafo anterior, muy hábilmente podría haberme bajado las especificaciones e implementado la funcionalidad necesaria para poder exportar desde ProyectoRadio hacia este formato. Pero aún más habilmente, google me ha ayudado a encontrar una librería (AODL) que lo hace por mí.

AODL es una librería para .NET que permite crear, abrir y editar documentos de texto (.odt) y de hoja de cálculo (.ods) de las especificaciones OpenDocument. En principio está escrita para .NET 1.1 pero yo la he enlazado desde .NET 2 y funciona sin problemas. Su licencia es LGPL y su funcionamiento bastante sencillo una vez se le coge el truquillo.

Hoy, en un par de horas, he escrito un exportador que es capaz de escribir documentos ODT con tablas e imágenes para exportar redes de radio. Aquí tenéis un ficherito de ejemplo. Este fichero es el resultado de exportar una red de prueba mediante el nuevo plugin que he escrito con AODL. Está recortado para que no ocupe en exceso. Me gusta porque está escrito con estilos y luego es fácil cambiar la apariencia del documento de golpe.

Lo que no he conseguido es introducir un salto de página. Supongo que será cosa de darle un par de vueltillas más. A ver si un día con algo más de tiempo escribo un pequeño tutorial de como trabajar con AODL.

Aquí tenéis una pequeña captura de pantalla de la herramienta de exportación con el exportador a ODT seleccionado.

OdtExporter Espero que os guste :).

Interfaces gráficas en entornos multihilo

Jueves, 31 \31UTC agosto , 2006

ProyectoRadio está implementado completamente sobre la plataforma .NET 2. No es que me guste más o menos que otras, pero como comenté en mi post sobre C, C# es un lenguaje que me parece muy potente y la plataforma permite desarrollar proyectos bastante complejos de una forma asequible.

La naturaleza del software requiere hacer tareas pesadas o largas. Por ejemplo las simulaciones de coberturas, la importación o la exportación de datos, la carga de mapas, etc son tareas que cuando se ejectuan tienen el control del programa durante un tiempo bastante importante.

La naturaleza de las aplicaciones .NET con interfaz gráfica de usuario Windows.Forms es básicamente la misma que la de la API de Windows nativa, solo que muy organizada y bonita. Las aplicaciones son del tipo “orientadas a eventos”. Esto quiere decir que existe un hilo de ejecución único asociado a la aplicación que está siempre dormido. Cuando la aplicación recibe un evento: Click en un botón o desplazamiento de una barra, el sistema le envía un mensaje que la función principal ejectua (todo esto de forma oculta claro) y llama a la función apropiada para manejar ese click.

Lo que el programador escribe son las funciones asociadas a los eventos. Cada control de usuario puede tener unos cuantos eventos. Por ejemplo un control de tipo Button tiene el evento Click. En C# se pueden asociar funciones a eventos de tal forma que si nosotros queremos gestionar el evento de Click solo hay que asociar una función al evento y cada vez que se pulse el botón se llamara a nuestra función. Bien.

Hasta aquí todo parece fácil. El problema veradero viene cuando asociado a ese handler o función asociada a un evento hay una operación muy lenta o costosa. Ejemplos un poco más arriba. Si no se hace nada y sin más se ejecuta la operación, el hilo de ejecución, que es único está entretenido operando y haciendo cuentas costosas y por tanto no retorna del evento, y por supuesto no puede atender más eventos del sistema, por mucho que estos lleguen. El resultado es bastante conocido, la interfaz de usuario (UI) se queda “como bloqueada” y si movemos la ventana fuera del escritorio y la traemos de nuevo se queda blanca. Normal, no se está gestionando el evento de repintado :).

Esto me ha traído bastantes problemillas. A primera vista la solución parece fácil. Usar un hilo de ejecución paralelo para ejecutar la tarea pesada. La idea es tan sencilla como demoníaca. Esto es fácil en C# y .NET. Hay una clase asociada a un hilo o thread de ejecución. Sin más que instanciar uno de estos objetos, pasarle una función de ejecución y lanzarla ya tenemos un hilo ejecutándose en paralelo al hilo principal. Bueno, pues bien, ahora nuestro hilo principal, después de lanzar el hilo pesado retorna del gestor del evento y la interfaz sigue respondiendo como es debido. Claro.

Ójala fuera todo así de fácil. Si estamos familiarizados con los sistemas paralelos y la programación concurrente rápidamente vamos a ver un problemilla: Hay que garantizar la coherencia de los datos. Esto quiere decir básicamente que todos los datos que necesite el hilo pesado ejecutándose en background no se modifiquen, o lo hagan de forma coherente, por el hilo principal de ejecución. Esto implica que cualquier pulsación de botón, desplazamiento, etc no modifique los datos importantes. Formas de garantizar esto existen, claro. Una de ellas es sin más haciendo una copia de los datos (shadow) y que estos sean los usados por el hilo de background. No creo que sea la ideal. Tenemos otras como usar mecanismos de interlocking. Ejemplos hay variados: Mutexes, CriticalRegions, Semaphores… lo que sea para bloquear al hilo principal de modificar los datos del hilo pesado. Hay que tener de nuevo cuidado de no bloquear la UI en uno de estos mecanismos.

Además de estos problemas evidentes y muy conocidos, la UI presenta otros problemillas cuando se usa en un entorno multihilo. Solo se puede acceder o modificar los valores de los controles, incluyendo su repintado, desde el hilo donde se crearon. Así, si se llama al constructor de un boton en el hilo principal, que será lo común, cualquier acceso que se haga desde el hilo secundario a este botón: Ver su estado, deshabilitarlo, etc… lanzará una excepción muy bonita y nos obligará a salir de la aplicación con toda probabilidad.

Me imagino que es una forma de proteger la implementación de los controles sin necesidad de complicados mecanismos de interbloqueo pero es una putada. Si te das cuenta que desde el hilo de la tarea pesada es necesario modificar o acceder a la UI, para dar un poquito de feedback o para actualizar una vista, pues cuidadín.

Alternativas a este problema hay muchas, pero principalmente dos: Una alternativa sencilla para problemas sencillos es usar un BackgroundWorker. Este tipo de objeto es una careta a un thread e implementa funciones útiles. Está pensado para el problema que yo planteo así que una vez arrancado el hilo principal retorna y la interfaz sigue funcionando. Cuando desde el hilo pesado hay que dar feedback se llama a una función del objeto BackgroundWorker (GiveFeedback()) y un evento se lanza pero en el hilo de ejecución que creó al BackgroundWorker. Problema resuelto, el feedback se puede dar en el hilo correcto sin más problemas. Lo mismo pasa para cancelar o para terminar el hilo.

El problema a esta primera solución aparece cuando los objetos que se gestionan en el hilo pesado son más complicados y el feedback no es tan sencillo y requiere modificar múltiples vistas. Otro problema es cuando los objetos modificados en el hilo secundario tienen sus propios eventos que pueden ser gestionados por parte de la UI. La solución a este problema puede ser bastante sencilla si se piensa desde un principio.

Allí donde la UI esté asociada a un evento de un objeto y que provoque un cambio o acceso a la UI es necesario comprobar el contexto de la llamada. Todos los controles, bueno realmente todos los objetos heredados de Component implementan una funcionalidad para evitar el problema de los hilos inapropiados. La propiedad InvokeRequired indica si es necesario hacer malabarimos para actualizar la UI. Retorna false en caso de que el hilo es el correcto y true en el caso que el hilo desde el que se llama sea otro diferente a la de creación. De nuevo los controles tienen una función, bueno una pequeña colección de ellas, que permite invocar la ejecución de una función en el hilo correcto. BeginInvoke() e Invoke() son las más importantes. Ambas funciones van a lanzar la ejecución de la función que le indiquemos como parámetro pero en el hilo correcto.

Bufff, esto es todo sobre UI y multithreading que no es poco. La verdad es que puede dar verdaderos dolores de cabeza sin no se diseña desde el principio con cuidado.

Novedades en ProyectoRadio

Martes, 29 \29UTC agosto , 2006

Pues pocas 🙂 Estoy reestructurando el sistema de importacón y exportación para hacerlo, por este orden: Más eficiente, más usable y más flexible. Enseguida nuevos mapas, clutter y asociación de redes y coberturas.

Tengo ganas de escribir un post sobre el poder de reflection para implementar plug-ins y nueva funcionalidad. A ver si mañana desde un teclado de tamaño razonable…

Hablar sobre uno mismo

Domingo, 27 \27UTC agosto , 2006

Hoy he dedicado parte de esta tarde a hablar sobre mi mismo. Bueno, no realmente si no de proyectoradio. He aquí la entrada: ProyectoRadio. Está escrita como una página fija del blog, así que siempre estará ahí como referencia cada vez que, como es habitual, hable de mi proyecto favorito :).

Editando que es gerundio

Miércoles, 23 \23UTC agosto , 2006

Por fin. Me ha costado. Llevo pensándolo desde casi la primera línea de código de ProyectoRadio. Voy a dedicar esta entrada a uno de los controles que más he deseado introducir y que a la vez más he retrasado: El editor de textos.

Hoy he dedicado un par de horas a crearme un pequeño control para editar textos enriquecidos (Rich Text Format). El otro día, discutiendo con un amigo, decidimos que los items del proyecto deberían tener todos unos comentarios asociados. Esto es especialmente útil en casos como el proyecto general y los enlaces. Cuando se está diseñando una red o una cobertura, es útil poder introducir unos comentarios que queden en el proyecto, que se puedan exportar o guardar. Así en futuras referencias al proyecto siempre se pueden entender porque las cosas se hicieron así.

Nada más acabar la discusión, introduje el concepto de comentarios a algunos de los ítems del proyecto que consideré más oportunos. Ayer publiqué una foto de la vista de una red de radio. En el cuadro asociado a los comentarios se puede ver lo que había, un simple control de texto sin más.

Pero como desde el principio le llevo dando vueltas al hacer un editor un poco más avanzado, que permita hacer dos o tres cositas como cambiar fuentes, centrar, negritas… pues hoy me he lanzado. El resultado es este (click en la imagen para ampliar):

El nuevo editor

Hey, estoy contento, muy contento con el resultado. Ahora ya puedo asociar este control a todas las vistas y añadir edición de comentarios de forma seria a todos los items del proyecto que merezca la pena sin que me dé pereza. Además, solo con actualizar el control, actualizo todos los sitios donde se usa.

Me gusta.

What about Trac?

Martes, 22 \22UTC agosto , 2006

Hoy he dedicado parte de mi jornada laboral junto con Rafa a nuestra labor de gestión. Ya había comentado que habíamos llegado a la conclusión de que la gestión era nuestro punto más débil. Por este problema somos menos eficientes e ideas que son muy buenas e importantes se pierden en el limbo de las ideas.

Para ello nos hemos creado nuestro nuevo servidor de gestión. Parece que matemos moscas a cañonazos, pero no. Ya existía pero lo teníamos un poco desatendido. Así las cosas, nos hemos instalado un disco duro nuevo, una Ubuntu para servidor, subversion (a falta de probar git), ejabberd, y… TRAC.

Después de hacer unas pruebillas hemos decidido que TRAC va a tener una oportunidad como nuestra herramienta de gestión de proyectos. En principio es una aplicación web bastante potente, si se le añaden los plugins apropiados. Permite navegar por el código en el repositorio, integrar la documentación de doxygen… y sobre todo:

– Tiene un wiki, que para documentar viene que ni pintado.

– Tiene un blog, que para el histórico de reuniones de diseño, discusiones importantes y otras cositas biene de perlas.

– Tiene foro, que no lo veo tan útil salvo para desarrollos más ubícuos que el nuestro.

– Tiene un sistema de tickets para documentar bugs, mejoras, ideas…

– Permite cierta planificación en base a roadmap, milestones y algo, digo algo porque está por ver, de diagramas de Gantt o cronogramas.

De momento a mí me gusta y confío en sus posibilidades. Me gusta principalmente porque documentar en SVN es un engorro y al final no se hace. Planificar en planner es bueno, pero luego los archivos acaban en el SVN y es lo de siempre. TRAC reúne las características que creo que necesitamos, además de un blog que espero que le saquemos el partido apropiado.

Estoy pensando que necesito un servidor para mí. Tengo que mover los hilos pero es que de verdad empiezo a echarlo de menos. Como dije ayer, desarrollo ProyectoRadio el 90% yo solo y eso implica que no tengo problemas de sincronismos de versiones y la gestión pues me la quedo yo. Cada día se hace más imperioso un sistema de control de revisiones, no por nada, si no para tener un poco más organizado mi sistema y sobre todo para poder tener diferentes líneas de desarrollo organizadas. Quiero un TRAC personal y quiero tener una máquina silenciosa 24×7 en la habitación pequeña. Ya os contaré como van las negociaciones.

Sé que tengo pendiente la nueva página fija del blog hablando de ProyectoRadio, pero hasta entonces, aquí un par de fotos de la criatura.

Espero que os gusten.

Foto de la criatura.

Otra fotito del nene

El día de la vuelta o como gestionar un proyecto software

Lunes, 21 \21UTC agosto , 2006

Después del mal trago del accidente de tren para acabar el día, he de decir que hoy ha comenzado siendo mi vuelta al currele. Al final, estas cosas son siempre igual, me lleva pasando desde que tengo memoria. Ya podía ser domingo cualquiera o el primer día después de vacaciones, pero siempre de la misma forma. Me gusta dormir y me gusta acostarme tarde, conclusión clara: acabo desplazando mi horario. Así pasa lo que pasa, llega el día antes de volver a la rutina y la rutina no viene a mí. En este caso no viene en forma de sueño que sería lo apropiado, así que el lunes irremediablemente cara de sueño y alto riesgo de poca productividad.

La verdad es que hoy hemos llegado a una importante conclusión, que no es poco. Necesitamos mejorar nuestro ninvel de gestión en la ingeniería de software. Esto supongo que nos pasa a todos los que nos dedicamos a esto. Empiezas tú solo y como los ocupas pues te autogestionas. Los problemas aparecen cuando tu equipo crece, tus usuarios crecen y las necesidades del diseño hacen que te disperses. En este instante empiezan a perderse ideas buenas, empiezan a relegarse funcionalidades importantes, empieza a desmadrarse el árbol de versiones del proyecto… Conclusión necesitamos parar y dedicar un poco más a gestionar y menos a desarrollar.

Supongo que esto se puede aplicar a ProyectoRadio. Al final, el principal trabajo de ProyectoRadio lo hago yo y esto trae la tentación del okupa. Me doy cuenta de que el proyecto es mucho más grande de lo que jamás pude imaginar y mi hasta ahora eficaz metodología de planificación de recursos y de gestión de tareas puede que no sea suficiente.

Tengo bastantes ganas de hablar de ProyectoRadio, al fin y al cabo es como un hijo para mí y todos los padres están orgullosos de sus hijos. Yo no soy menos. Creo que me voy a hacer una página independiente en el blog y así siempre me puedo remitir a ella, digo yo.

Mañana más.