Programadores e interfaces de usuario

Hay algunos brillantes, pero en general casi todos los programadores que conozco son(mos) muy malos diseñando interfaces de usuario. Esto tiene varios motivos, creo:

• El programador tiende a ver la funcionalidad, no el uso.


• El programador no tiene la formación adecuada (ni el interés(?)) acerca de usabilidad ni diseño. Quizás tampoco la formación adecuada en programación de GUI's


• El programador, casi por definición es vago. Gastará el mínimo tiempo en el diseño del interfaz

También hay algunos aspectos que dificultan que un interfaz sea armonioso y usable: los continuos cambios de especificaciones, la indefinición de funcionalidad y de diseño:

- Eso... uhmmm... déjalo también configurable
- Ya, ¿pero dónde?
- Ya le encontrarás un hueco...
- Con tantas opciones ¿no será un poco difícil de usar?
- ...

De todos modos lo que a mi me parece adecuado es que el programador programe un interfaz de usuario diseñado por un diseñador conjuntamente con el cliente, o al menos validado por éste. Si no hay más remedio que diseñarlo por lo menos intentar no hacer el diálogo. En ese mismo enlace hay consejos sencillos sobre lo que no hay que hacer. El ejemplo del GUI de wget es espeluznante... :)

La misma entrada en BP

Communicating Sequential Processes (CSP)

Hace unos días leyendo una noticia de Slashdot me llamó la atención un comentario en el que se hacía referencia a "Communicating Sequential Processes" (CSP), que según la wikipedia inglesa es un lenguaje de descripción de patrones de interacción en sistemas concurrentes (que dicho así todo seguido suena casi peor...) Según la propaganda ayuda tanto a especificar correctamente el modelo de concurrencia como a verificarlo y depurarlo. Tiene una página oficial, Using CSP en la que se puede descargar el libro Communicating Sequential Processes de 1985 en pdf. Además existen implementaciones para usarlo tanto en Java, JCSP, como en C++, C++CSP. No he tenido tiempo de estudiarlo con tranquilidad, pero lo dejo por aquí por si resulta interesante. Si alguien lo ha estudiado o usado puede ofrecer su opinión al respecto...

La misma entrada en BP

Un vistazo a C++09

Acabo de ver referenciado en OSnews:What's Coming in C++ '09 un artículo que resume las últimas decisiones acerca del nuevo estándar de C++: C++09: A Glimpse into the Future. Como decía Ion Gaztañaga parece que la x de C++0x se despeja: intentarán que sea en 2009. Por lo demás, lo que se viene hablando por aquí, rvalue-refrence, conceptos, deducción de tipos en las inicializaciones (¡que bien!, usar auto, ver "Un vistazo a C++0x" por Bjarne Stroustrup), delegación de constructores...

La misma entrada en BP

Enlaces varios (IV)

En la linea de cantidad sobre calidad, ración de enlaces apresurados:

• What Makes A Programming Language? ¿En que escribimos? ¿Adonde va nuestro código? ¿Son lenguajes? ¿Frameworks? ¿Patrones? ¿Hacia donde vamos? No responde a todo, por supuesto, pero a veces las preguntas son más interesantes que las respuestas ;)
• Miguel de Icaza sobre El pacto de Novell con Microsoft y sobre la liberación de Java. Queda muy políticamente correcto, pero me gusta lo de que esto no es un juego de suma cero. Agitados para él estos últimos días :)
• Patronitis: N. fem. Dícese de la enfermedad propia de programadores que consiste en querer aplicar patrones de diseño a todo.. Una de los síntomas de creer haber encontrado la dichosa bala de plata. Hay quien opina que los patrones de diseño son síntomas de defectos en los lenguajes de programación Bueno, seamos prácticos, usemos lo que tenemos a mano, pero con criterio...
• Recopilación de los mejores artículos de 2004 según Joel Spolsky accesibles en la web Best Software Writing I (la lista de 2005 sigue abierta)
• Behind the Scenes of Objective-C 2.0 ¿También Objective-C evoluciona?

La misma entrada en BP

Análisis estático de código: flawfinder

Gracias a una entrada en el valle del viento helado de Drizzt, "Algunos enlaces de seguridad", he conocido la existencia de flawfinder, un analizador estático de código (C/C++). Te da alertas de código potencialmente inseguro, sobre todo de la utilización de funciones y prácticas con largo historial de vulnerabilidades. No añade nada que no debiéramos saber ya, pero siempre es diferente saber que tal o cual práctica es potencialmente peligrosa y otra es verlo en tu código ;)

Por dar alguna información más acerca de este tipo de programas en la propia página de éste vienen enlaces a otros similares: splint, cqual.... si hubiese seguido la bitácora de fernand0 como se merece, me habría enterado hace un año: " Análisis estático del código fuente y seguridad"

La misma entrada en BP

Concurrencia y librerías reusables

Vía Thinking Parallel: News for Weeks 43 and 44 / 2006 me encuentro con un extenso artículo acerca del impacto de la concurrencia en las librerías: Concurrency and the impact on reusable libraries.

Es algo sabido que el diseño de las librerías debería tener en cuenta si su uso va a ser concurrente. Y debido a que los tiempos están cambiando es muy probable que lo sea. Si nos damos cuenta a posteriori necesitaremos usar muletas :)

La misma entrada en BP

Linux event handling

Escribe Ulrich Drepper en "Linux event handling":

El código multihilo es absolutamente necesario para avanzar. Todos los procesadores crecen horizontalmente, porque tienen cada vez más contextos de ejecución (cores, hyper-threads)

Hace un repaso a los problemas que se encuentran los programadores a la hora de abordar el tema y propone un interfaz de gestión de eventos (para linux) que se adapte a la situación. Algo está cambiando, efectivamente y no sólo en los lenguajes de programación...

La misma entrada en BP

Noticias sobre Ruby 2.0

Vía Lambda the ultimate: Ruby 2.0 News me entero de lo que se va cociendo en el desarrollo de la nueva versión de Ruby, Ruby 2.0. Parece que no va a soportar temporalmente(?) continuaciones ni green threads. Hay distintas visiones sobre el tema: "Ruby Might Be Sucking Less?" (anteriormente titulado "Ruby Sucks?") y Two Excellent Things for Ruby at Microsoft

Actualización: En More on Ruby Implementations se habla de las distintas implementaciones de ruby y de lo que se hace para evitar su balcanización...

Actualización2: Parece que otros no son tan optimistas con esto de las diferentes implementaciones del entorno de ejecución de ruby. En The Impending Ruby Fracture de David Pollak se repasa el tema. Para él, si sigue todo como hasta ahora, dentro de dos años habrá incompatibilidades entre ellos. Espero que se equivoque...

La misma entrada en BP