Norma EN 301 549 - Requisitos de accesibilidad

Hola a todos, se ha publicado recientemente la EN 301 549, norma europea sobre requisitos de accesibilidad en la contratación pública de productos y servicios TIC en Europa. Habrá que prestar atención a esta norma europea de usabilidad, especialmente de cara a contrataciones públicas.

La norma está disponible para descarga en:
http://www.etsi.org/deliver/etsi_en/301500_301599/301549/01.01.01_60/en_301549v010101p.pdf

La doctrina del comentario

Hoy voy a hablar del comentar o no comentar el código, que parece que se está convirtiendo en una doctrina.

¿Qué es lo que ocurre? Vengo observando un tiempo la tradicional defensa del comentario como algo necesario, pero que hay que controlar en tamaño (nº de comentarios respecto al código), forma (estándares), etc.

Por otro lado, está la defensa a ultranza de la total ausencia de comentarios. Ojo, porque aquí sí que se suelen excluir los comentarios JavaDoc o NDoc que suele haber al principio de las clases y que se utilizan principalmente para documentar el código. Esto, menos mal, parece que nadie lo pone en duda (o al menos, no he identificado un grupo que esté por la labor de eliminarlo).

A continuación, veremos algunos argumentos o doctrinas que la gente utiliza en sus blogs en internet, y que me parecen interesantes. No los copio aquí para ensalzar ni tampoco ridiculizar a sus autores, sino sólo para intentar entender este tipo de argumentos y poder entender de qué hablamos. El objetivo no es tanto quitar la razón a los que están en contra de los comentarios, sino más bien entender el porqué de su postura, y tratar de ir un poco más allá. Yo de momento, sí me declaro abiertamente defensor de comentar el código, aunque luego hablaremos de con qué matices (mmm veo que de aquí tengo material para otro artículo de enfermedades del software: la "comentaritis"). Siempre creo que "menos es más".

Frases en contra o a favor de los comentarios que podemos encontrar por la web:

• Usar comentarios va en contra de mis principios.
• los comentarios son siempre "el patito feo" del código fuente, cuando en realidad son tan importantes como el resto
• comentar antes de programar, es lo que todo programador debe hacer. No puedes lanzarte a programar sin saber lo que quieres lograr.
• al desarrollador por lo general no nos gusta "perder el tiempo" comentando y mucho menos documentando
• si lo he hecho yo, ya sabré porqué lo he hecho
• los comentarios en el código son algo completamente inútil que no hacen más que entorpecer y causar problemas
• Cuando el código es modificado, tenemos que modificar también los comentarios, pues corremos el riesgo a explicar algo que no es lo que estamos haciendo. Ya bastante trabajo resulta mantener un código para también tener que mantener un paquete de oraciones.
• Provocan problemas culturales, ya que muchas veces los comentarios están en un idioma diferente al que es capaz de leer el desarrollador actual, o en la mejor intención de hacerse entender, el "escritor" dejó una lista de oraciones sin concordancia, sentido, y con cientos de faltas de ortografía y errores gramaticales.
• El que un comentario parezca necesario es signo de que el código no es lo suficientemente claro. Un buen código debe siempre explicarse por sí mismo sin necesidad de un "bastón" (o comentario).
• Reducen la claridad en el código. ¿Alguna vez han visto un método con 50 líneas de las cuales menos de 10 son de código y lo otro es todo un tratado científico? Yo sí, y resulta un verdadero dolor de espalda descubrir las líneas reales ejecutables entre tantas palabras
• Esta técnica de crear métodos para aislar secciones de código y dejar bien clara su función es extremadamente útil para aumentar la claridad. En vez de tener un módulo con 500 líneas ejecutables, podemos dividirlo en varios métodos cuya responsabilidad esté bien delimitada. El resultado final será mucho más claro y flexible.
• los comentarios son la prostitución de las incapacidades de un programador.

¿Qué radicales son algunos de los comentarios, verdad? Y no es para menos. Por desgracia, es frecuente encontrarse programadores poco experimentados en los equipos que acaban sufriendo de "comentitis": lo llenan todo de comentarios por su inseguridad y falta de método. Aquí os recomendaría los que a mi modo de ver son dos libros indispensables tanto para programadores que se creen experimentados, como para los que empiezan. (Creedme, nunca seremos suficientemente experimentados, y lo que es peor, el paso del tiempo, la destreza se pierde). Los libros son:

• Code Complete, de Steve McConnell
• Clean Code, de Robert C. Martin

Dejaremos para otro día unas recomendaciones sobre qué y cómo comentar, y porqué. Ahora vamos a dar un breve repaso a algunos consejos para evitar que nos afecte:

• No podemos controlar todo lo que hacen los demás. No podemos exigir que respeten nuestra forma de trabajar si no respetamos la de los demás. No todo el mundo tenemos el mismo nivel técnico.
• Si algo te molesta, dilo. Pero ten respeto por las personas y su trabajo. Además, te encontrarás con que quizás a ese programador le obligaron a hacerlo así, o quizás era su primer trabajo (todos hemos tenido un primer trabajo, y un segundo trabajo).
• Controla tu ego. No puedes imponer a todo el mundo trabajar como te gusta. Porque se trata de eso: tu gusto.
• No confundir lo anterior con normas de codificación. Si el proyecto o la empresa (o el cliente), tiene unas normas de codificación, hay que seguirlas. Peor que ver código mal hecho, es ver código hecho de dos formas distintas en función de miembros del equipo disciplinados, y los "libres y ajenos a toda norma".
• las normas de codificación, y sobre todo, las relativas a los comentarios, han de ser muy simples. Un comentario no es tan importante como para perder tiempo con 200 páginas de normas y un curso intensivo de 3 días.
• El comentario no nos va a dar de comer: el código sí. Dicho esto, no significa que debamos ignorar y eliminar los comentarios. Si cada palabra clave o sintaxis del lenguaje que no nos gusta o "nos parece" poco útil se eliminara, os aseguro que entre unos y otros, sólo dejaríamos en el código líneas en blanco.
• Todos dejamos código basura. (unos más que otros,es cierto). Pues también hay comentarios basura. Y contra ambos hay que luchar.
• En tu empresa, en tu proyecto, adopta una forma de comentar simple y efectiva, minimalista. Usa sólo lo imprescindible y haz que todos lo adopten. Si trabajas solo, ten en cuenta que tu código o lo pueden usar en otros proyectos, o ya se está integrando en otros proyectos. Recuerda: hazte respetar respetando tú antes la forma de trabajo de los demás.

¿Estáis de acuerdo? ¿O sois defensores de los comentarios? ¿O abogáis por su más absoluta erradicación?
Por cierto, habrá que acuñar el término "Genocida de Comentarios", si esto llegara a ocurrir ;)
Y bueno, creo que ya vale para una entrada un tanto improvisada.
Un saludo a todos.

Ética e Ingeniería del Software

Fuente: http://www.asme.org/

Recientemente, en el blog de Javier Garzás he leído un post donde se propugna algo que llevo repitiendo hasta hartarme desde el primer post: que debemos comportarnos profesionalmente, de forma ética.

No somos charlatanes, patanes de feria que vendemos lo que nos convenga en función del beneficio que nos proporcione. En lugar de eso, damos al cliente lo que necesita en cada momento, maximizando su satisfacción y nuestro beneficio a largo plazo. Porque creemos en que la relación con nuestros clientes se cimenta en una confianza mutua, y ésta sólo puede realizarse a largo plazo.

Esta forma de pensamiento la he visto como eco en algún otro post. Me hace mucha gracia, que Javier afirma: "una metodología no es un equipo de fútbol, ni un partido político, ni una religión". Sin embargo, leo por doquier en la red continuas llamadas talibanistas a defender la religión del bloguero de turno:

• Metodologías ágiles
• Software libre
• CMMI
• Integración continua
• <Pon aquí tu práctica/metodología/marco de trabajo>

El pensamiento que defiendo es similar al promulgado por Alistair Cockburn hace ya unos años:

"Estoy cansado de la gente que es de una escuela de pensamiento y que rechaza las ideas de otra escuela de pensamiento. Tengo hambre de gente que no le importe de donde vienen las ideas, que les importe sólo lo que significan y lo que producen. Así que se me ocurrió esto del “juramento de no lealtad”.
Esto significa el fin de afirmaciones como “eso no está bien – no es ágil / orientado a objetos / puro / etc.”, en vez de discutir sobre si la idea (ágil o tradicional o impura o lo que sea) funciona bien en las condiciones del momento."

Por desgracia, hay gente que incluso afirmando defender estas ideas, confiesa sus prejuicios y reticencias al respecto de ciertas formas de trabajar: "metodologías", "prácticas", "marcos de trabajo"...llamadlo como queráis.

Podemos estar convencidos de una cosa, pero no debemos defenderla si no es con argumentos probados, objetivos y no sólo cualitativos sino también cuantitativos. Por desgracia, esta forma de pensar encaja perfectamente en los que yo llamo "indecisos patológicos" o "charlatanes del depende". Sí, ya los conocéis. Me refiero a los que siempre contestan a todo con un "depende" (hasta aquí todo va bien), pero que cuando se les pide algo más de detalle o chicha en su discurso, podemos tener dos tipos de respuesta:

• Verborrea coherente pero carente de fondo y forma, que al final no termina de dar ningún tipo de argumento veraz ni mucho menos objetivo hacia un lado u otro. Esta verborrea de político le viene muy bien a algunos individuos, que incluso les facilita la promoción profesional. Pero lástima de los clientes que acaben con ellos, y mucho peor: lástima de los que acaben en un proyecto dirigido por estos pseudo-profesionales.
• Verborrea que sólo está orientada a alimentar el ego del que escucha. Son los llamados aduladores, los pelotas, que difícilmente terminan hablando del tema, sino que redirigen la conversación a un terreno menos objetivo y relacionado con el proyecto en cuestión.

Al querer escribir yo este post, me he encontrado con otro post bastante interesante. En él, su autor deriva la conversación a la ética informática, y al colegio profesional. Este autor, plantea la existencia de un tribunal de ética. Yo no sé lo que pensaréis pero empiezo a estar harto de tribunales, comisiones, cortes, comités de supervisión, equipos de trabajo, etc, etc. Y estoy harto de apelar siempre a un "ser superior" que nos proteja y defienda.

Es muy fácil: lo único que puede definir el comportamiento ético o no en un proyecto es la documentación. Los criterios objetivos, y la forma en que se basan y defienden, es lo único que puede usarse como valor ético en un proyecto. Pero claro, decir esto cuando la moda es ir en contra de la documentación, ser ágil, y entregar todo de forma rápida (y sin documentación), es poco menos que escupir al viento. Pero no deja de ser cierto. No es posible verificar la ética en un proyecto sin contrastar el contrato, con las decisiones tomadas (y las decisiones, o se documentan...o se pierden). Y es así en todas las profesiones.

Después de todo, en una profesión en la que no hay estándares cerrados, en los que no hay normas internacionales que establezcan la forma correcta de trabajar, todo vale. No podemos a la vez defender que hacer software es un arte, y al mismo tiempo querer crear Colegios, Comisiones éticas que verifiquen el buen hacer...respecto a qué?

En fin...excelentes Alistair Cockburn en su comentario, y Javier Garzás y Jorge Ubeda en sus respectivos posts. Espero que esta pequeña reflexión mía haya podido aportar algo.

Enfermedades del software: Singletonitis

Patrón Singleton en notación UML

De nuevo, una enfermedad del software que a más de uno le va a sorprender. Y sin embargo es muy pero que muy vieja. Al final de esta entrada tenéis unos cuantos ejemplos de fuentes que he utilizado y que me han recordado lo peligroso que es usar patrones sin conocimiento, pero especialmente, el más simple de todos: el patrón Singleton.

¿En qué consiste el patrón Singleton?

Este patrón es el más sencillo, y también uno de los más conocidos y utilizados. Básicamente, su propósito es asegurar que sólo exista una instancia de una clase dada.

Singletonitis, una definición

Bien, dada la definición anterior, el anti-patrón Singleton ha recibido el nombre de "singletonitis": desorden transitorio del programador, que le lleva al abuso del patrón Singleton. Algunos autores van más allá, y definen claramente al patrón Singleton como un verdadero anti-patrón (es más causa de problemas, que solución de ninguno: o como se suele decir, pan para hoy, y hambre para mañana).

En el libro "Refactoring to Patterns", el autor Joshua Kerievsky presenta el término Singletonitis, refiriéndose literalmente a "la adicción al patrón Singleton". Este autor, propone un tipo de refactorización que llama "Inline Singleton", cuyo objetivo es eliminar los Singletons innecesarios en una aplicación.

Hay muchos problemas con el patrón singleton. Demasiados. Algunos de ellos:

• Crea una alta dependencia en el código. Un alto acoplamiento que es fuente de problemas
• Crea problemas con las pruebas y su automatización, especialmente por la alta dependencia del código al tratar de hacer pruebas unitarias.
• Problemas con el multi-hilo y concurrencia.
• Alta probabilidad de crear spaguetti-code, difícil de leer e incluso de debuguear, por acumulación de uno o varios de los anteriores.
• Problemas de reusabilidad. Lo mismo, por acumulación de uno o varios de los anteriores.

En uno de los artículos que he revisado, el autor (Taskinoor Hasan ), ha tratado de hacer una aproximación seria, tratando de dar una solución lógica a los diversos problemas que el autor va detectando en su inocente implementación del patrón Singleton. De tan serio que es el artículo, y la acumulación sucesiva de problemas que presenta, acaba siendo hasta ridículo y divertido.

Del tema de la concurrencia y problemática con los entornos multi-hilo, hay varios artículos que presentan estrategias más o menos eficaces en función de la situación, lo que complica la resolución del problema. Y es que hay que ver lo bonito que es todo cuando en nuestra ignorancia, planteamos un sistema con Singletons creyendo que éstos van a ser instancias mono-uso. Con el paso del tiempo, la experiencia (y la dura realidad), nos van enseñando que al ver las cosas desde un nivel superior, o al tratar de reutilizar componentes, nuestro pequeño patrón Singleton es una fuente de problemas. Además, esos problemas al haber tanto acoplamiento en el código y dificultad de testeo, son complicados de detectar y resolver.

Frases como "esto nunca se va a usar en multi-hilo", tan categóricas, deberían ir siempre acompañadas de un "zas, en toda la boca".

Es duro ver cómo la falta de previsión y el abuso de patrones (patronitis), hace que las cosas se usen fuera de contexto y acaben haciendo todo menos aquello para lo que fueron diseñadas.

Solución: ¿vacuna o erradicación?

No son pocos los autores que defienden la total prevención mediante la erradicación de la causa de la Singletonitis, evitando dicho patrón.
Otros, elaboran complejísimas estrategias para detectar problemas, incompatibilidades, etc. Incluso existe una estrategia de validación dentro del patrón llamada "Double Check Locking", diseñada para evitar que en el caso de multi-hilo, haya problemas derivados de los bloqueos necesarios dentro del patrón.
Yo propongo algo que varios de los autores defienden, y es el uso de otro patrón (que por supuesto tendrá su enfermedad asociada por abuso), y es el de IoC (Inversion of Control).

¿Y tú? ¿Ya has sufrido tu Singletonitis?...

Fuentes:

http://taskinoor.wordpress.com/2011/04/18/singleton_multithreaded/
http://www.antonioshome.net/blog/2006/20060906-1.php
http://pragmaticintegration.blogspot.com.es/2006/02/singletonitis.html
http://www.theserverside.com/discussions/thread.tss?thread_id=42116
http://www.gamedev.net/blog/32/entry-510687-why-are-you-infected-with-singletonitis/
http://msdn.microsoft.com/es-es/library/bb972272.aspx
http://www.teatromagico.net/foro/viewtopic.php?f=4&t=13513&p=454983
Gamma E., Helm, R., Johnson, R., Vlissides J.: Design Patterns: Elements of Reusable Object Oriented Software, Addison Wesley, 1995.
Kerievsky, Joshua: Refactoring to Patterns, Addison-Wesley, 2004.
http://weblogs.asp.net/sfeldman/archive/2008/10/22/singletonitis.aspx

Nueva Norma UNE 16114

Bueno, vamos a tomar un respiro con tanto AOS2012, y tanto agilismo. Hablemos por un día de otras cosas.

Recientemente me ha surgido la necesidad de tratar con esta nueva norma UNE-EN 16114. Esta norma todavía no es una ISO, aunque está previsto que lo acabe siendo en algún futuro cercano. Actualmente es una norma europea, adoptada como 16114, y en España UNE la ha adoptado también.

¿Otra norma? ¿Para qué?

¿Como si no tuviéramos ya pocas normas, verdad? La Norma UNE-EN 16114:2012, fue publicada por AENOR en marzo del 2012 con el objeto de cubrir la necesidad de regular la eficiencia en la prestación de servicios de consultoría de gestión. La Norma UNE-EN 16114:2012 se presenta como una colección de directrices voluntarias aplicable a cualquier tipo de trabajo y cliente.

¿En qué consiste esta norma?

 Proporciona recomendaciones para la realización de servicios de consultoría de gestión incluyendo:

1. cuestiones legales y éticas;
2. gestión, comunicación y evaluación;
3. las relaciones con el cliente;
4. la oferta y el acuerdo;
5. la planificación y la ejecución;
6. el cierre del servicio.

La Norma UNE-EN 16114:2012 no es certificable por terceras partes ya que no establece requisitos que puedan evaluarse para demostrar su conformidad con la norma. Así mismo, la norma no está diseñada para un uso regulatorio o contractual y ni es apropiada como base de ninguna cualificación ni individual ni de organizaciones.

Es decir, que NO podemos obtener un certificado en esta norma, ni para la empresa, ni a nivel personal.

Recientemente adoptada a nivel europeo, todavía no es un estándar Global ISO.

 

Fuentes:

• http://www.aenor.es/aenor/actualidad/actualidad/noticias.asp?campo=4&codigo=22326&tipon=2
• http://www.softwareiso9001.isotools.org/nueva-norma-une-en-161142012-servicios-de-consultoria-de-gestion/
• http://www.icmci.org/?page=17656437
• http://gestionintegra.com/uneen16114/

Buenas prácticas de desarrollo en Sharepoint

Microsoft acaba de publicar un excelente conjunto de buenas prácticas en Sharepoint, en una de sus TechNet Wikis.
http://social.technet.microsoft.com/wiki/contents/articles/8666.sharepoint-2010-best-practices-en-us.aspx

Un enlace imprescindible para los que trabajan con Microsoft Sharepoint, o que simplemente desean conocer lo que difícilmente se encuentra en los libros. Además, como toda Wiki, se actualiza diariamente con nuevos contenidos.

Fuente: El excelente blog de Jersson en Geeks.ms

AADL: un lenguaje de modelado para Arquitectos de Software

Hoy voy a hablar del AADL, un lenguaje para nada nuevo, y que sin embargo es bastante poco conocido. Vamos a revisar algunas de sus características generales:

• Existe como estándar internacional desde 2004.
• Nació como lenguaje orientado a entornos de aviónica, pero actualmente su alcance es mucho más amplio.
• Está promovido por el SEI
• Pretende estandarizar en un lenguaje de modelado, el diseño de arquitecturas (hardware y software).
• Nació para sistemas embebidos, por lo que admite hardware y software.
• Es un lenguaje textual y gráfico.
• Incluye un formato de intercambio XML/XMI que permite interoperabilidad con herramientas del mercado
• Dispone de una extensión para el modelado de sistemas resistentes/tolerantes a fallos.

Puede utilizarse para modelar:

• Sistemas empotrados, como arquitectura de sistema basada en componentes.
• Las interacciones de los componentes mediante flujos, llamadas de servicio y de acceso compartido.
• Ejecución de tareas, sincronización exacta de comunicaciones.
• Plataformas de ejecución, application binding, modelos operativos y configuraciones tolerantes a fallos.

Hay muchos otros lenguajes de modelado, pero éste me ha parecido curioso y me apetecía echarle un vistazo y compartirlo.

Ejemplo.
A continuación, un ejemplo sacado de la página de AXLOG:

system system1

end system1;

system implementation system1.impl

    subcomponents

        p1: process process1.impl;

        p2: process process2.impl;

    connections

        cn: data port p1.outport -> p2.inport;

end system1.impl;

process process1

    features

        outport: out data port;

end process1;

process implementation process1.impl

    subcomponents

        t1: thread thread1.impl;

    connections

        cn: data port t1.outport -> outport;

end process1.impl;

process process2

    features

        inport: in data port;

end process2; process implementation process2.impl

    subcomponents

        t2: thread thread2.impl;

    connections

        cn: data port inport -> t2.inport;

end process2.impl;

thread thread1

    features

        outport: out data port;

end thread1;

thread implementation thread1.impl

end thread1.impl;

thread thread2

    features

        inport: in data port;

end thread2;

thread implementation thread2.impl

end thread2.impl;

Os dejo con unos enlaces en los que podréis ampliar información:
http://en.wikipedia.org/wiki/Architecture_Analysis_%26_Design_Language (Nota: para ser Wikipedia, la verdad es que la información que da es bastante pobre a fecha 5 de Marzo de 2012)
http://www.sei.cmu.edu/dependability/tools/aadl/
http://www.axlog.fr/aadl/presentation_en.html (este enlace sí que tiene bastante información, ya que AXLOG es una firma miembro del comité de estandarización de AADL).