Programa y llora

Desde hace meses estamos, en mi empresa, inmersos en un proceso de valoración de los puestos de trabajo (VPT) que componen el departamento de informática donde trabajo.

Básicamente se trata de adecuar los salarios a las tareas, responsabilidades, habilidades, capacidades, etc. que ponemos a disposición de nuestros usuarios/clientes.

Tengo que comentar, antes que nada, que trabajo como programador para la Administración. Sí, soy funcionario, pero... esto no es óbice para que tenga sentimientos!!!

Siempre me ha gustado el término "programador". Es un término lleno de romanticismo, pero hoy en día... poco valorado. Bill Gates, Paul Allen, Steve Jobs, Larry Ellison, Linus Torvalds, Richard Stallman, etc. seguro que se sienten orgullosos de decir que son, simplemente: programadores.

Pues en mi empresa, tras esta valoración realizada por una empresa consultora en RRHH de prestigio, de la zona donde trabajo, hemos decidido cambiar el término "programador" por el de "Técnico Medio en Informática". Triste, muy triste, pero... nos hemos visto obligados.

El resultado del informe, que esta empresa realizó, nos "dibuja" como profesionales con una iniciativa en la misma línea que el resto de los trabajadores de la "casa", sin un especial interés por estar formándonos continuamente (parece que no lo necesitamos para desarrollar nuestro trabajo), el grado de influencia de nuestros errores es bajo, tampoco realizamos un trabajo que requiera un gran esfuerzo mental y, además, es bastante fácil que cualquier persona con una experiencia similar a la nuestra se adapte al puesto y realice las mismas tareas que yo realizo y de forma adecuada.

Vamos que casi somos un fraude.

Yo, de momento, voy a intentar que me publiquen el libro Programa y llora (de la Editorial O'reilly) y, así, comprobar si puedo ganarme la vida mejor de este modo ;-)

Cambiando el estilo visual de una aplicación Flex

El estilo visual, por defecto, de una aplicación Flex es bastante bonito: ventanas con esquinas redondeadas, sombras, degradados, transiciones, etc.

Si bien, al final todas nuestras aplicaciones parecerán iguales. Esto puede ser bueno para los usuarios, que llegan a reconocer, a la primera, una aplicación y por intuición ya saben como manejarla... pero, para los desarrolladores o creadores, esto, hace de su tarea de creación algo aburrido y tedioso.

Para modificar el estilo de los componentes Flex de nuestras aplicaciones podemos hacer uso de CSS (sí, una cosa menos que aprender) y así cambiar la forma y color de nuestros botones, grids, selectores de fechas, etc.

Es tan fácil como poner al principio de nuestro documento mxml la siguiente línea de código:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Style source="myStyle.css"></mx:Style>
</mx:Application>

Aún así, nos queda el trabajo de diseña un estilo propio y bonito... pues aquí viene en nuestra ayuda la siguiente aplicación (desarrollada íntegramente en Flex y de la que podemos ver, incluso, su código fuente): Style Creator

Visualmente podéis editar el cómo os gustaría que quedasen vuestros componentes Flex y finalmente pulsar el botón "Download CSS", que os descargará el fichero CSS a utilizar en vuestra aplicación. Espero que disfrutéis de ella,

Integrando Flex con .NET

Piensa en una aplicación web "enriquecida" sin acceso a información corporativa (bases de datos, servicios web, otros recursos corporativos, etcétera).

Es como pensar en un huevo sin yema (queda muy soso).

Para desarrollar este tipo de aplicaciones, con Flex, teníamos que:

• Desarrollar servicios http o servicios web y manejarlos directamente desde Flex.
  
• Acceder a objetos remotos mediante el Live Cycle Data Services (LCDS), que es un producto de pago (creo que $20,000 US por CPU) de Adobe y que además funciona como una aplicación sobre un servidor de aplicaciones J2EE (tipo JBoss, Tomcat, Apache-Geronimo, Glassfish, etc.)

Hace meses Adobe liberó un nuevo producto, llamado BlazeDS, que ofrece acceso gratuito a alguna de las características de LCDS, como acceso remoto a Java usando el protocolo AMF.

Este producto, BlazeDS, también funciona como una aplicación sobre un servidor J2EE.

Parecía que solo íbamos a poder acceder a nuestros recursos corporativos desde una aplicación Flex si disponíamos de una plataforma J2EE... dejando a la plataforma .NET huérfana de estos servicios.

Pues esta importante carencia es la que viene a cubrir FluorineFX:

• Flex, Flash Remoting (RPC)
• Flex Messaging (parcialmente)
• Flex Data Services (parcialmente)
• Soporte de protocolos AMF0, AMF3 y RTMP
• Servicios de navegador
  
• Generador de código basado en plantillas (sintaxis similar a ASP.NET)
• Fácil integración con Adobe Integrated Runtime (Adobe AIR™)

Parece que ya tenemos yema para todos nuestros huevos!!!

Elementos de colaboración de equipos

He encontrado una tabla periódica de elementos de colaboración. Son los 74 elementos de colaboración identificados para mejorar tu equipo de trabajo, la productividad y la creatividad.

Ver más en:

http://www.mindquarry.com/community/articles/elements-collaboration

Estos patrones (o elementos) están agrupados en 4 categorías:

* Gente
* Herramientas
* Software colaborativo
* Métodos

Propongo no documentar

Ya no se recomienda la documentación de los elementos que intervienen en un proyecto fuera del propio elemento.

Unos cuantos miles de los nuevos filósofos/pensadores que han surgido alrededor del proceso de desarrollo de proyectos software están de acuerdo conmigo. Es en serio.

Cada parte de un proyecto (programas, modelos de datos, etc.) debe estar autodocumentada. Si documentamos un elemento fuera de éste... lo más normal es que, pronto, la documentación quede "desalineada" con lo documentado. Fundamentalmente, por lo costoso de mantener dos cosas tan alejadas (la técnica y la documentación) a la vez y alineadas.

Ya ha quedado demostrado empíricamente que la documentación no conlleva ningún beneficio y además tiene un coste importante. Lo que ahora está de moda es la "agilidad" y la documentación no aporta nada en beneficio de esta "agilidad".

Además, a los programadores no nos gusta documentar, es un hecho, así que dejamos esta aburrida tarea siempre para el final (cuando ya nos viene "pisando los talones" un nuevo proyecto mucho más interesante) y por ello no nos la tomamos en serio y la "salvamos" como podemos.

Y ¿qué hay peor que algo no documentado? Algo mal documentado.

La siguiente pregunta refuerza más lo que digo ¿cuántas herramientas de ayuda a la documentación de proyectos software conocéis, de memoria, que mantengan versiones actualizadas y que no estén ancladas en técnicas de los años 80? (no vale decir el word, la excel o el notepad).

Actualmente, casi todos los nuevos lenguajes de programación permiten al programador autodocumentar mientras programa. Parte de esta documentación tiene "coste cero" porque hay herramientas que extraen información del propio código y generan la documentación. Así para que alguien tenga una versión actualizada solo necesita pedirle a la herramienta que se la genere ¿chachi, no?

Lo que creo es que: deberíamos esforzarnos en hacer las cosas lo más sencillas posibles, autodocumentadas/autoentendibles, utilizando "modos" conocidos y aceptados por todos. Que todos tengamos las habilidades suficientes para entender esos "modos" de forma natural (sin depender de otros elementos), que esos "modos" estén escritos (no documentados) en la forma de un reglamento básico (que dice cómo se deben hacer las cosas) y que, además, este reglamento básico se alteré lo menos posible a lo largo del tiempo.

Y, por supuesto, que todos sigamos ese reglamento básico, nos guste mucho o poco, como si fuesen mandamientos divinos (no se cuestionan... se acatan, simplemente).