Certified (en Español)

Arquitectura Java EE y Spring Framework

2010-12-27T13:13:00.005-05:00

Hace unos meses -en mi anterior trabajo- realizé una presentación al equipo sobre fundamentos de arquitectura y su relación con Spring Framework. La presentación es fundamentalmente teórica así que van a encontrar poco código; y consideré compartirla dado que estamos en campaña de resucitar el blog xD.

Saludos, y hasta otra!

Arquitectura y diseño de aplicaciones Java EE

View more presentations from Carlos Gavidia.

GWT para novatos

2010-12-23T17:46:00.002-05:00

GWT - Una introducción

View more presentations from Carlos Gavidia.

Me encargaron en el trabajo realizar una charla introductoria sobre GWT para el equipo. Después de leer durante algunos días -dado que soy un novato en la materia- preparé la presentación que adorna este post. La pongo a disposición de los interesados.

Saludos, y hasta otra!

Spring Community Day 2010

2010-11-24T11:06:00.001-05:00

Creo que debo empezar esto post disculpándome por la ausencia prolongada: He andado tan ocupado últimamente que hasta se han reducido mis horas de sueño. Sin embargo, prometo encontrar espacio para actualizar el blog y evitar que se llene de telarañas. Palabra.

Luego, quería invitar a los lectores peruanos al Spring Community Day 2010 que organiza la comunidad Spring Perú. Habrá ponencias técnicas, presentación de casos prácticos, espacios de discusión y el infaltable coffee break (además, este blogger tendrá a su cargo una charla sobre Spring Web Services xD).

El evento se realizará el 27 de Noviembre (este sábado) en el Campus de la UPC. Para ingresar es necesario colaborar con 10 soles que serán destinados íntegramente a financiar una Misión de Navidad para los niños del Asentamiento Humano San Alvino.

Están todos cordialmente invitados.

Cohesión y el principio de responsabilidad única

2010-10-01T15:09:00.001-05:00

Imaginemos que nuestro siempre creativo usuario nos solicita un proceso que genere cierto reporte Excel con información de base de datos y se lo coloquemos en un servidor FTP para que lo pueda descargar luego. Dado que -para variar- quiere el reporte para ayer, construimos la siguiente solución apresurada:

Diseño improvisado

Terminamos, el usuario lo prueba, mira que es bueno y nos felicita.

Pasan unos días y el mismo usuario nos pide una aplicación para que pueda colocar algunos documentos PDF en el mismo servidor FTP. ¿Por qué no utilizamos a nuestra clase AdministradorDeReportes junto a su método enviarArchivoFTP()? Podríamos hacerlo, pero nuestra clase para poder ser compilada depende también de POI y de JDBC lo que le daría una carga extra de 5 megas a nuestro sencilla aplicación para PDF's. Esto pone en evidencia que nuestro diseño original tiene algunos problemitas.

La cuestión es que nuestra clase AdministradorDeReportes tiene la responsabilidad de conectarse a base de datos, de generar un archivo Excel con esta data y de colocar el archivo en el servidor FTP; y si uno quiere reutilizar este componente pues no le queda otra que adquirir el paquete completo de responsabilidades que esta clase posee. ¿Y si queremos otra clase que genere el mismo reporte en HTML en un browser? Sería bastante conveniente utilizar el método obtenerInformacionBD ()de AdministradorDeReportes, pero una vez más tenemos el problema que esta clase tiene dependencias que no necesitamos (ni el API para conexión a FTP ni la generación de Excel). Dado que es obvio que nuestro diseño inicial tiene problemas, corregimos y planteamos lo siguiente:

Después de recapacitar, planteamos esto

Con esta nueva solución, la aplicación para transferir archivos PDF solamente debería utilizar la clase ClienteFTP sin la sobrecarga del resto de API's que no necesita; y si se requiere el reporte HTML que planteábamos sólo dependeríamos de la clase ExtractorDeDatos. Este diseño tiene la peculiaridad que nuestras clases están bastante especializadas y tienen una única responsabilidad específica: Por ejemplo, la clase ClienteFTP se ocupa de la conexión con el servidor FTP y nada más. Es esta especialización lo que nos da bastante flexibilidad para la reutilización, que es lo que trata de decirnos Robert C. Martin con su Principio de Responsabilidad Única:

“Nunca debe de haber más de una razón para que una clase sea modificada”

Si vemos nuestro diseño inicial, la clase AdministradorDeReportes debería modificarse si es que se requieren datos extra en el reporte. Esta clase también debería modificarse si quieren que el reporte Excel tenga otros colores. Y si quisiéramos optimizar la conexión con el servidor FTP nuestra clase AdministradorDeReportes también debería pasar por mantenimiento, por lo que tenemos un ejemplo bastante claro de como violentar este principio. Ahora, en nuestra versión mejorada del diseño hemos transferido estas responsabilidades a las clases ExtractorDeDatos, ClienteFTP y ReporteadorExcel; de modo que cada cambio que mencionábamos ahora impacta solamente en una clase de nuestro programa.

Casos de uso y descomposición funcional

2010-09-16T19:01:00.004-05:00

Imaginemos que estamos capturando requerimientos para una página web que tiene que incluir un foro. Hablamos con el usuario líder, y nos cuenta que es necesario que el administrador del sistema esté en capacidad de bloquear el acceso a los usuarios que repetidamente muestren un comportamiento inadecuado en el foro (escriban en mayúsculas, resuciten threads antiguos, utilicen palabras malsonantes y otras exquisiteces de los foristas). Después de la entrevista vamos a nuestra oficina, iniciamos nuestra herramienta CASE y aplicamos la técnica de casos de uso según lo que nos enseñaron en la universidad para producir este diagrama:

Diagrama construido con StarUML

Esta primera versión tiene algunos inconvenientes. Por definición, un caso de uso debe producir valor para los actores con los que interactúa (según Kurt Bittner) y no creo que el Administrador encuentre mucho valor a la tarea de "Buscar Usuarios" o de "Mostrar Información de Usuario". A menos que se trate de reportes -y no es el caso- el Administrador del Foro no va a entrar a nuestra aplicación sólamente a realizar una búsqueda o a consultar información de un usuario, sino lo que desea es estar en capacidad de bloquear a los usuarios rebeldes. Por ahí ya tenemos problemas.

Ahora, tal vez nuestra intención inicial de agregar tantos casos era para poner en evidencia que para bloquear a un usuario es necesario primero buscarlo, luego mostrar un formulario con su información básica, después ingresar los motivos por los que se le va a bloquear para finalmente realizar el bloqueo. Si ese fue el caso caimos en otro error, dado que los casos de uso no "invocan" a otros casos de uso y mucho menos se comunican entre ellos. Realizar esto es intentar convertir los casos de uso en funciones, lo que nos lleva al problema de la descomposición funcional: Descomponer un problema en partes pequeñas y aisladas entre sí, que trabajando juntas nos proveen de una funcionalidad del sistema.

La descomposición funcional de casos de uso hace que estos pierdan contexto, como el caso de uso "Asignar motivos de bloqueo" que no tiene sentido sin el resto de casos de uso del diagrama. También está el tema del valor para los actores que mencionábamos al inicio, el mismo caso de uso "Asignar motivos de bloqueo" no le va a servir al Administrador si es que el usuario al final no termina bloqueado.

Ahora ¿qué hacemos para no caer en esto?. Navegando me topé con un documento de Kurt Bittner en el que nos sugiere tres cosas:

Centrarse en casos de uso que provean valor real a los stakeholders. En el caso de nuestra administrador, buscando usuarios no gana mucho.
Limitar el uso de "includes" sólamente para representar descripciones comunes entre caso de uso. Y usarlas con muchísimo cuidado.
Limitar el uso de "extends" sólamente para agregar comportamientos opcionales a casos de uso existentes que por si mismos generen valor. Personalmente, no me gusta mucho utilizar esta relación.

Entonces, sabiendo esto borramos nuestro primer borrador defectuoso y lo cambiamos por este mucho más simple y elegante:

Este diagrama también lo hice con StarUML

En la especificación de caso de uso ya podemos explayarnos describiendo el flujo deseado. Recuerden que un modelo de casos de uso es principal y mayoritariamente texto. Eso sería todo en esta entrega, hasta otra!

No hables con extraños, o la Ley de Deméter

2010-08-10T19:25:00.000-05:00

Imagen: Autorretrato con Sombrero de Paul Gauguin

Desde los primeros cursos de orientación a objetos de la universidad he escuchado que al programar se debe procurar siempre "niveles bajos de acoplamiento y altos de cohesión". Recién ahora que estoy ojeando The Pragmatic Programmer de Andrew Hunt y David Thomas el tema del acoplamiento me ha quedado claro y quería compartir con ustedes mis hallazgos.

Es más fácil entender este concepto si vemos un programa que no lo aplica. El libro propone este ejemplo:


   public void plotDate(Date aDate, Selection aSelection) {
   TimeZone tz = aSelection.getRecorder().getLocation().getTimeZone();
   ...
   }

La clase que contiene al método plotDate está altamente acoplada, dado que su estructura actual depende de otras tres clases: Selection, Recorder y Location. Esto nos pone en una situación delicada, dado que un cambio en cualquiera de esas tres clases tendría impacto en nuestro programa. Por ejemplo, si Location hace que el método getTimeZone sea privado, nuestro método tendría que redefinirse, y lo mismo pasaría con modificaciones a cualquiera de las otras clases dependientes. Es por eso que se recomienda mantener los niveles de acoplamiento mínimos (es decir, depender del mínimo número de clases) para evitar que las ocurrencias del resto deshagan nuestro trabajo. Si bajamos el nivel de acoplamiento de clase de arriba, nos quedaría algo así:


   public void plotDate(Date aDate, TimeZone aTz) {
   ...
   }

Ahora nuestro método espera que le llegue una instacia de TimeZone como parámetro y ya no la obtiene desde un objeto Selection. De este modo hemos reducido las dependencias de tres a una clase (sólamente TimeZone ), siendo responsabilidad de la clase cliente la obtención de la instancia de TimeZone que necesitamos. Esta clase cliente nos puede invocar de esta manera:

   plotDate(someDate, someSelection.getTimeZone());

El libro menciona que los síntomas clásicos de un programa altamente acoplado son que los cambios más simples impactan en componentes que no deberían, y que los programadores se resisten a darle mantenimiento al sistema por miedo a echar a perder algo.

Descrito al problema, ahora toca describir la solución.

La ley de Deméter -inventada en 1987 en la Northeastern University - tiene como objetivo el minimizar las dependencias entre las clases de un programa dado, previniendo el acceso a objetos externos para consumir sus métodos. En resumen, la ley establece lo siguiente:

Cualquier método de un objeto debe invocar solamente a los siguientes métodos:

Sus propios métodos
Los métodos de los objetos que ha recibido como parámetros
Los métodos de los objetos que posee como atributos
Los métodos de los objetos declarados como variables locales

Con esto aseguramos el mínimo de dependencias posibles. Los dejo con una imagen extraída del libro que ilustra el concepto:

Imagen tomada de The Pragmatic Programmer de Andrew Hunt y David Thomas

Hasta otra!

Código vicioso

2010-07-26T15:02:00.002-05:00

(Imagen: El Fumador de Vincent Van Gogh)

El que una aplicación funcione no significa siempre que esté bien construida, y es frecuente que detrás de una bonita y funcional interfaz de usuario se encuentre un pandemónium de líneas de código. Los americanos les llaman a estas joyitas de la programación "code smell" que vendrían a ser "Cualquier síntoma en el código fuente de un programa que nos indique la presencia probable de un problema mayor" según Wikipedia.

También en Wikipedia encontramos una pequeña lista de defectos famosos. Les listo algunos que me parecieron interesantes y frecuentes:

Código duplicado: Es el producto de una de las más antiguas y populares técnicas de programación: el "copy-paste". A la larga representa un problema serio ya que los cambios que se realicen en una sección de código deben ser replicados en el resto de archivos donde hemos "reutilizado" esta funcionalidad. Para evitarlo podemos extender la clase, o simplemente encapsular esta funcionalidad en un método que sea invocado por los que lo requieren.

Clases extensas: Las convenciones de código en Java recomiendan que las clases no debe exceder las 2000 líneas. Si ese es el caso, probablemente tu clase esté haciendo más de lo que debería violentando el principio de alta cohesión. Las clases deben tener responsabilidades especializadas, y si nuestro programa cuenta con Objetos-Dios que hacen de todo es que tenemos un serio problema de diseño.

Envidia funcional: Sucede cuando una clase utiliza en exceso los métodos de otra clase. Imaginémonos una clase ClaseEnvidiosa que tiene un método calcularPromedio(). En calcularPromedio(), invoca al método obtenerNumeroDeCursos() de la clase Estudiante. Luego, invoca a obtenerCalificacion(int i) de Estudiante varias veces para sumar todos los valores obtenidos y al resultado dividirlo entre el número de cursos que obtuvo anteriormente. Finalmente, invoca a setPromedio(double d) de Estudiante y le asigna el valor calculado. Se observa que ClaseEnvidiosa invoca en exceso a los métodos de Estudiante desde el método calcularPromedio(), cuando lo más práctico es que el método calcularPromedio() se encuentre en la misma clase Estudiante.

Complejidad artificial: Utilizar en exceso patrones de diseño cuando es suficiente con un diseño sencillo. Recuerdo una aplicación donde el controlador Struts invocaba a un Facade, que a su vez invocaba a un BusinessDelegate que mediante un EJB hacía uso de una clase DAO que finalmente invocaba a un procedimiento almacenado. Y lo único que se hacía en cada capa de la aplicación era pasar los parámetros a la capa inferior, hasta llegar al DAO que era el que realmente hacía el trabajo. ¿No era más sencillo contar con un Facade y que éste invoque al DAO directamente?

Clase ociosa: Cuando una clase hace muy poco. Por ejemplo, una clase con un sólo método que es invocado solamente por una clase. Tampoco hay que llevar lo de alta cohesión a extremos y para estas situaciones recomendaría que la funcionalidad de la clase ociosa sea absorbida por otra clase más robusta.

Wikipedia señala más, pero esas son las que he encontrado (o he incurrido xD). Hasta otra!

Pereza, impaciencia y soberbia

2010-06-14T11:27:00.004-05:00

(Imagen: Fé, esperanza y caridad. Esculturas de Manuel Tolsá en la Catedral de México)

Larry Wall es conocido en el medio por ser el creador de Perl y por ser el autor de Programming Perl, el libro de referencia de este lenguaje.

En este libro, Wall le sugiere a los lectores que desarrollen las que -según el- son las tres grandes virtudes de todo gran programador: Pereza, Impaciencia y Soberbia.

El programador perezoso detesta hacer lo mismo dos veces, es por eso que procura siempre que el código que produzca sera reutilizable. Asimismo, el programador perezoso procura documentar siempre para evitar la molestia de tener que explicar sus programas al resto del equipo.

El programador impaciente no soporta estar mucho tiempo sin hacer nada. Es por eso que los programadores impacientes siempre están construyendo programas que quizás no necesiten ahora pero que con certeza necesitarán en el futuro.

Por último, los programadores soberbios no toleran ser criticados. Para evitar críticas y burlas, los programadores soberbios producen código de calidad de modo que sólamente reciban elogios por su trabajo.

Voy a tener que tomar esto bastante en cuenta al momento de buscar personal. Tal vez deberíamos poner un anuncio que diga "Se solicitan desarrolladores perezosos, impacientes y soberbios. De no cumplir los requisitos, favor abstenerse".

Hasta otra!

Errare humanum est

2010-06-09T16:40:00.016-05:00

(Imagen: Geek and Poke de Oliver Widder)

Nadie es perfecto, ni siquiera los programadores, y mucho menos los programas que hacemos. Es por eso que son necesarios nuestros amigos de control de calidad, para decirnos - con cortesía- que nos hemos equivocado pero solicitando con insistencia que arreglemos lo que detectaron. Sin embargo, la gente de control de calidad tampoco es perfecta y sucede con frecuencia que nuestros errores (o bugs, en argot del programador) llegan hasta el usuario final, que suele reaccionar muy mal cuando algo no funciona como quiere:

"Estimado Perico: Nada en el sistema funciona como me dijeron que iba a funcionar y no puedo trabajar con un sistema en estas condiciones. Cuando trabajábamos con el sistema en Cobol no teníamos este tipo de problemas."

Correos de esa naturaleza llegan a la bandeja de los desarrolladores, incluyendo a Jefes de Proyecto, Gerentes y demás interesados entre los destinatarios. Ahora, si el programador es novato y la gente de calidad es despistada este tipo de correos puede crecer en número y frecuencia; dejándonos con la bandeja de entrada llena y muchos bugs sin control.

Es por eso que todo equipo de desarrollo necesita una base de datos de bugs para tener control del estado de la aplicación: saber cuánto hemos reparado, cuánto nos falta reparar y quién está haciendo ese trabajo. Puse base de datos en negrita porque dada la importancia de esta tarea no podemos confiar en hojas excel ni archivos txt (aquí donde trabajo lo hemos intentado y hemos fracasado rotundamente). Ahora en la empresa estamos empezando a usar Bugzilla para el control de errores, y nos está yendo bien: es bastante completo y además es gratuito :D.

Quería comentarles también que gracias a la recomendación de un compañero de trabajo -asiduo lector de este modesto blog- llegué a un artículo de Joel Spolsky sobre sistemas de reporte y control de incidencias. Les listo algunas ideas que me parecieron interesantes:

Un buen reporte de bugs debe tener 3 partes: Pasos para reproducir el bug, resultado esperado y resultado real. Por lo general los usuarios mandan correos poco descriptivos ( del tipo "¡nada funciona!", o con un screenshot y el asunto de "Arréglalo"). En el sistema de reporte de errores (como nuestro Bugzilla) se debe registrar toda la información necesaria para que el programador pueda hacer su trabajo.

Los bugs deben ser responsabilidad de una persona. En otras palabras, en todo momento debemos saber quien se está haciendo cargo del bug. Inicialmente puede estar asignado al Jefe de Proyecto, que puede derivarlo al Desarrollador Perico que luego lo asigna al Desarrollador Paco debido a que el error era en el módulo que él desarrolló. Siempre se debe conocer al responsable del bug, de modo que podamos echarle la culpa cuando persista el error xD.

Sólo el que reporta el bug puede cerrar el bug. Porque sólamente el que registró el bug sabe a ciencia cierta que es lo que estaba mal. Una vez que el desarrollador termine de construir la solución, el registrador del bug (que puede ser personal de Control de Calidad o Usuarios finales) debe dar el visto bueno. Caso contrario, a continuar con las reparaciones xD.

El sistema de registro de bugs debe ser masivamente usado. Para esto, Spolsky nos da algunos tips: Si eres desarrollador, sólamente repara bugs que te han asignado por el sistema. Si eres personal de Control de Calidad, sólamente reporta bugs por el sistema. Si eres Jefe de Proyecto, asigna bugs a tus desarrolladores por el sistema. De esa manera dejaremos de usar excel y emails para pasar a algo más organizado.

En todos estos puntos Bugzilla nos va a ser de ayuda. Ojalá nos funcione: si le funcionó a Facebook y a la NASA creo que a nosotros nos puede ser útil xD.

Hasta otra!!

A propósito del Pair Programming

2010-06-04T11:17:00.005-05:00

(Imagen: Geek and Poke de Oliver Widder)

Programador: Entonces, estamos de acuerdo. En las líneas pares alineamos mediante tabs, y en las impares con espacios en blanco. En las sentencias "if" abrimos llaves en la misma línea, y en los bucles "for" lo hacemos en la línea siguiente. Ahora... ¿Cómo hacemos con los bucles "do" y "while"?
Nota al pie: Programación en pareja

(Traducción libre)

Sobre cómo el pair programming no siempre es una buena idea (y la necesidad de establecer convenciones de código).

El Síndrome del estudiante

2010-05-29T23:57:00.005-05:00

(Imagen: Piled Higher and Deeper de Jorge Cham)

Érase una vez un proyecto de software, y érase también un jefe de proyecto que estaba elaborando su cronograma. Como era un buen jefe de proyecto, siempre consultaba a los desarrolladores antes de realizar estimaciones:

- Dime Perico ¿Cuánto te tomaría construir este componente?

Perico sabía que componentes similares le habían tomado un día. Pero Perico estaba aún en la universidad y necesitaba a veces algunas horas de trabajo para avanzar ciertas tareas. Siendo consiente de esto, Perico respondió:

- Jefe, este componente como mínimo me toma dos días

El jefe de proyecto entonces agregó a su cronograma la actividad "Construcción de componente", la asignó a Perico y le colocó un tiempo de dos días. Sin embargo, recordó que el proyecto era para un cliente nuevo cuya plataforma no le era familiar al equipo, y mucho menos a Perico. El jefe de proyecto lo pensó mucho, y al final le asignó cuatro días al componente de Perico, dado que uno nunca sabe lo que puede pasar.

El Jefe de Proyecto hizo esto para todas las actividades del proyecto, y le entregó el cronograma al Gerente de Desarrollo. El Gerente observó el cronograma y se sorprendió del poco tiempo del proyecto. Además, históricamente los proyectos de nuestro Jefe de Proyecto siempre se atrasaban, por lo que como medida preventiva le agregó un día a todas las actividades. Hecho esto, le hizo llegar el cronograma al cliente, junto con el costo del proyecto.

El cliente recibió el cronograma. Le pareció un tiempo prudente, y por tratarse de un cliente importante el costo no significaba ningún problema para él. Aprobó el cronograma, firmaron lo que tenían que firmar y el proyecto empezó a caminar.

Cuando a Perico le hicieron llegar el cronograma, lo primero que notó fue que para hacer un componente -bastante simple a su criterio- le habían asignado cinco días. Perico tomó esto con bastante alegría dado que la universidad le estaba consumiendo bastante tiempo. Siendo lunes, Perico pensó:

- Voy a estudiar los cursos de la universidad hasta el martes, y el miércoles comienzo a hacer este insignificante componente

Y así lo hizo, estudió mucho hasta el martes y el miercoles comenzó con el componente. Hizo lo que siempre hacía cuando se trataba de esos componentes. Al finalizar el miércoles lo tenía listo, para alegría de Perico y del Jefe de Proyecto.

El jueves desplegaron el componente en los servidores de prueba del cliente; y como el jefe de proyecto había previsto, no el componente no funcionaba como debería.

Se lo hicieron saber a Perico, y se pasó todo el jueves tratando de descubrir porqué el componente funcionaba en su computadora y no en los servidores del cliente (que usaban un software que ni Perico ni el Jefe de Proyecto habían visto antes).

Perico leyó todo el jueves y también el viernes. Más o menos a las ocho de la noche ya tenía una idea de lo que tenía que hacer, y eso implicaba hacer el componente de nuevo. Con mucha verguenza, Perico le confesó a su jefe que necesitaba dos días más. Con más verguenza que Perico, el Jefe de Proyecto le informó de esto al Gerente de Proyectos, quien se enojó bastante pero se sorprendió muy poco: Los proyectos de nuestro Jefe de Proyectos siempre se atrasaban a pesar de lo holgado de su cronograma.

¿Les suena familiar? A mi me ha pasado un montón de veces, y es un ejemplo clásico del Síndrome del estudiante (no creo que sea necesario explicar el porqué del nombre xD) : Las personas empiezan a dedicarse al máximo a las tareas asignadas recién unos días antes de la fecha límite. Esto lleva a un desperdicio de la holgura que uno pueda considerar al momento de estimar tiempos de tareas. Fue descrito por Eliyahu M. Goldratt en su libro "Cadena crítica".

El Síndrome ya lo conocía por experiencia propia, pero me lo presentaron formalmente hoy en el curso de Gestión de Proyectos Informáticos. Cuando el profesor nos diga el antídoto, se los hago saber.

Hasta otra!!

El amigo elegido

2010-05-11T20:02:00.001-05:00

Una vez trabajé con un programador que disfrutaba viendo programar a los demás. Podía observar por horas a su programador objetivo sin que este tenga la más mínima idea de que su código estaba siendo escrutado al milímetro. Eso sí, si no entendía alguna línea de código o detectaba algún bug no tenía ningún reparo en interrumpirte, lo que llegaba a ser molesto si es que esto sucedía muy a menudo.

Me acuerdo de esto debido a que hace un tiempo en una reunión de la empresa mencionaron que tenían planes de implementar una política de pair programming. Esto implica que vas a ser observado mientras programas, y vas a tener observar programar a alguien: dos desarrolladores construyendo el mismo código en una sola estación de trabajo.

Son pocas las ocasiones en las que he tenido otros ojos -aparte de los míos- sobre el código que produzco. Las que más recuerdo son la del programador voyeur mencionado al inicio del post y una funcionalidad bastante compleja que nos encargaron a dos programadores bastante novatos (que éramos entonces). Era tan difícil y nos causó tantos problemas que le llamábamos "El Cuco". Fue necesario juntar lo poco que los dos sabíamos para sacar el requerimiento adelante, y nos pasábamos bastante tiempo conversando sobre el código que uno de los dos escribía.

Valgan verdades, durante el desarrollo del Cuco aprendí bastante, y si algo le debo reconocer al Pair Programming es que es una manera eficiente de distribuir el conocimiento entre desarrolladores. Por otro lado, en muchas ocasiones el programador sigiloso me hizo notar errores que tuve que corregir y no llegaron a producción, por lo que la calidad de lo desarrollado aumentó.

Ahora, si vemos el vaso medio vacío, hay gente que por su personalidad trabaja mejor sola y no va a aceptar de ninguna manera que les pongas un compañero al costado (ni aunque se trate de Allison Stokke).Además, si pones a programar a tu desarrollador Senior junto al Junior a largo plazo vas a tener otro desarrollador experto, pero a corto plazo estás perdiendo software de calidad que el desarrollador senior podría estar produciendo en vez de andar de profesor. Esos costos deben evaluarse. Y... ¿que pasaría si pones a trabajar juntos a dos desarrolladores senior? Podrían construir software maravilloso, como podrían terminar peleando y acusándose mutuamente de incompetentes (por lo general los buenos programadores son bastante orgullosos).

Definitivamente, si dos programadores van a trabajar juntos sus personalidades deben ser compatibles para que se toleren mutuamente 8 horas al día (que en nuestro sector por lo general suelen ser muchas más). Jeff Atwood en su blog postula que todos los desarrolladores deberían tener un amigo programador (el les llama coding buddy), con el que se tenga la confianza suficiente como para compartir código y aceptar sugerencias. También menciona que debe ser una persona con un gusto por la programación similar al tuyo, y al que respetes y sobre todo admires profesionalmente. Ahora, se espera que una persona con estas características trabaje contigo, caso contrario Atwood te recomienda renunciar. Este sistema del "amigo programador" sería algo así como un pair programming informal y de mutuo acuerdo.

A la fecha no han vuelto a mencionar de nuevo lo del Pair Programming en mi compañía. Hasta entonces, sigo programando como el Llanero Solitario xD.

Hasta otra!

A propósito de la Ley de Brooks

2010-04-29T12:22:00.005-05:00

(Imagen: Dilbert de Scott Adams)

Jefe: ¿Cuánto demoraría tu proyecto si le agregamos dos personas?
Dilbert: Añádele un mes de entrenamiento, un mes por la complejidad generada y uno más para controlar el drama
Jefe: Pero después de todo eso...
Dilbert: Ellos serán tan productivos como esta reunión.

(Traducción libre)

Definitivamente, Dilbert en tres viñetas dice mucho más que mi post xD.

En busca del programador perdido

2010-04-26T20:08:00.008-05:00

La entrevista de trabajo en la que me fue peor fue para la empresa en la que trabajo ahora. Las entrevistas a las que estaba acostumbrado eran con señores enternados de mediana edad, que me preguntaban sobre lo que había estudiado, lo que mejor sabía y lo que había hecho. Convérsabamos unos minutos, me contaban lo que haría en caso de ingresar y me despedían con una sonrisa. En algunas ocasiones me tomaban un examen técnico escrito, y en el peor de los casos un test psicológico (que es todo un rollo que ya contaré). Sin embargo esa vez, fue diferente:

-Hola Carlos, mucho gusto. Necesitamos que hagas un mantenimiento a una tabla. Tienes una hora.

Me dijo en ese entonces el que sería mi jefe, un ingeniero un poco mayor que yo vestido de forma casual. La IDE que tenía que usar era el IBM RAD, que nunca había visto antes; y tenía que conectarme a una base de datos Informix, cuya existencia me enteré el día de la entrevista. Mi futuro jefe me ofreció una clase de Conexión a Base de Datos, que cuando agregué al IDE estaba llena de errores de compilación. No tenía internet, y como me había dicho, tenía solamente una hora.

Depuré la clase de conexión y comencé a construir el mantenimiento con mis casi inexistentes conocimientos de IBM RAD. Cuando la señorita de recursos humanos me dijo que el tiempo había terminado, sólamente tenía listo el registro y la eliminación. Salí bastante triste, dado que un amigo mío me había recomendado y había hecho un soberano papelón. Para sorpresa mía, me llamaron a los pocos días, por lo que asumí que fue el lobby de amigo lo que me había hecho ingresar. Después me vine a enterar que mi mediocre examen fue uno de los mejores (y que no entré a la empresa por tráfico de influencias) por lo que me había hecho merecedor del puesto.

Pasó el tiempo, y de evaluado pasé a evaluador. En efecto, ningún postulante podía hacer el bendito mantenimiento, ni siquiera un solo método operativo. Relajamos un poco el asunto y dimos hora y media de tiempo. Nada, ni siquiera el EAR desplegado. Cambiamos a Oracle -un DBMS más popular por estos lares- e instalamos IDE's a gusto del postulante (Eclipse y Netbeans). Ninguno podía terrminar. Cuando habilitamos el uso de Internet ya las cosas comenzaron a mejorar; pero aún así nos topábamos frecuentemente con programadores que no pueden hacer el mantenimiento de una tabla de 5 campos.

Jeff Atwood -en su artículo Why can't programmers... program?- señala que en USA se vive una problemática similar, y que buscar un programador competente se ha hecho una tarea difícil. Señala que emplean muchas horas entrevistando a gente que no tiene la más mínima noción de lo que es programar. En ese mismo artículo cita a Isram, que en su blog propone el siguiente problema a los postulantes para verificar sus habilidades:

Escriba un programa que imprima los números del 1 al 100. Para los múltiplos de tres imprima "Fizz" en vez del número, y para los múltiplos de cinco escriba "Buzz". Para los números que son múltiplos de tres y cinco escriba "FizzBuzz".

Según el autor, la mayoría de graduados de ciencias de la computación demoran más de 15 minutos en la solución o simplemente no pueden hacerlo (tal vez por eso en Estados Unidos en desarrollo de software tercericen tanto) . Por otro lado, Joel Spolsky sostiene que en toda entrevista a desarrolladores se debe exigir codificar. Parece sensato, y yo creo que si le hacemos caso nos aseguramos el descartar a los que no puedan con la pregunta FizzBuzz xD.

Hasta otra!

Etiqueta para programadores

2010-04-19T15:45:00.013-05:00

Recuerdo que en la universidad existía un curso electivo de "Protocolo", donde te instruían en las buenas maneras en el comer y el actuar. La evaluación final era asistir a una cena de gala en una embajada y no hacer quedar mal a la profesora xD .

Citando a Frieda Holler, la etiqueta tiene que ver bastante con el respeto, y saber como comportarse demuestra consideración con los demás. Y así como es necesario ser educado a la hora de comer, hay que saber también ser correcto al momento de programar. Codificar de manera ordenada y clara es una muestra de respeto hacia el programador que va a dar mantenimiento a lo que has construido. No indentar, por ejemplo, puede ser considerado una malcriadez.

Ningún profesor en la universidad me mencionó que existían convenciones de programación, así que en mis primeros años era bastante salvaje al codificar. Cuando entré a trabajar, el código desordenado -pero funcional- que en la universidad me hubiera valido un 20 era devuelto por el área de Arquitectura indicándome que indente, que comente y que siga los estándares. De rechazo en rechazo fui ordenándome de a pocos y ahora ya guardo ciertas formas con el código fuente.

El listado a continuación es un extracto de Java Code Conventions, que siendo publicado por Sun Microsystems puede considerarse oficial. Ojalá les sea de ayuda, y les sugiero programen siempre pensando en el desarrollador que va a dar mantenimiento a su código (de modo que no te eche maldiciones xD). Dicho esto, comenzamos:

Los archivos Java con más de 2000 líneas -incluyendo líneas en blanco y comentarios- deben evitarse.
Las primeras líneas de un archivo Java deben contener comentarios de entrada, de preferencia en este formato:

/*
 * Nombre de clase
*
 * Versión
 *
 * Aviso de Copyright
 */

Dentro de una clase las primeras variables en declararse son las variables de clase (estáticas) y luego las variables de instancia. Dentro de cada categoría, primero deben colocarse las variables públicas, luego las protegidas y por último las privadas.
Un archivo Java debe tener la siguiente estructura:

Documentación de clase/interfaz
Declaración de clase
Variables de clase
Variables de instancia
Constructores
Métodos

Una línea de código no debe exceder de 80 caracteres. Las líneas que excedan esta longitud pueden dividirse de esta manera:

function(longExpression1, longExpression2, longExpression3,
         longExpression4, longExpression5);

En la caso de sentencias condicionales:

if ((condition1 && condition2)
        || (condition3 && condition4)
        ||!(condition5 && condition6)) {
    doSomethingAboutIt();
}

Y para sentencias ternarias:

alpha = (aLongBooleanExpression) ? beta
                                 : gamma;

Los comentarios deben utilizarse para brindar información adicional que no está explícita en el código fuente.
Los comentarios no deben estar delimitados en cajas hechas de asteriscos u otros caracteres.
Los comentarios en bloque deben usar al inicio de cada archivo java y antes de cada método. Un comentario en bloque debe estar separado del resto del código por una línea en blanco. Todas las líneas de un comentario en bloque comienzan con un asterisco (*). Por ejemplo:

/*
 * Este es un comentario en bloque
 */

Se pueden usar comentarios cortos de uno línea indentados al mismo nivel del código fuente. Si el comentario no puede estar contenido en una sóla línea, debe utilizarse el formato de comentarios en bloque. Un comentario de una línea debe estar precedido de una línea en blanco. Así:

if (condition) {
    /* Acciones para la condición */
    ...
}

Los comentarios de documentación describen clases Java, interfaces, constructores, métodos y atributos. Cada comentario de documentación se encuentra delimitado por /** ...*/, y debe aparecer justo antes de la declaración:

/**
 * La clase Example provee...
 */
class Example { ...

Los comentarios de documentación no deben colocarse dentro de un método o una definición de constructor, dado que Java asocia los comentarios de documentación a la primera documentación después del comentario.
Se recomienda utilizar una declaración por línea. Entonces, es preferible utilizar esto:

int level; // nivel de indentación
int size;  // tamaño de la mesa

que esto:

int level, size;

Colocar las declaraciones sólamente al inicio de los bloques (un bloque está limitado por llaves). No se debe esperar a declarar las variables justo antes de utilizarlas. Así:

void MyMethod() {
    int int1;         // inicio del bloque del método
    if (condition) {
        int int2;     // inicio del bloque "if"
        ...
    }
}

Tratar siempre de inicializar las variables locales al momento de declararlas.
Utilizar siempre llaves para sentencias condicionales (if). Evitar este formato:

if (condition) //EVITAR!! UTILIZAR LLAVES!
statement;

Cada sentencia switch debe incluir la condición default. Dentro de default, utilizar break es redundante pero evita errores en caso se agreguen nuevas condiciones. Cuando no se requiera incluir break en un case, agregar el comentario /* falls through */:

switch (condition) {
case ABC:
statements;
    /* falls through */
case DEF:
statements;
    break;
case XYZ:
statements;
    break;
default:
statements;
    break;
}

Los nombre de clase debe ser sustantivos, donde la primera letra de cada palabra interna comience con mayúsculas. Utilizar palabras completas y evitar acrónimos y abreviaturas:

class Raster;
class ImageSprite;

Los nombres de los métodos debe ser verbos, la primera letra del nombre del método debe estar en minúsculas. La primera letra de cada palabra interna debe estar en mayúsculas:

run();
runFast();
getBackground();

Las variables declaradas como constantes deben tener nombres en mayúscula, y las palabras internas deben estar separadas por guiones bajos (_). Así:

int MIN_WIDTH = 4;
int MAX_WIDTH = 999;
int GET_THE_CPU = 1;

No hacer las variables de instacia y de clase públicas a menos que se tenga una buena razón.
Evitar hacer referencia a variables o métodos de clase desde objetos. Usar para esto el nombre de la clase.

classMethod();             //OK
AClass.classMethod();      //OK
anObject.classMethod();    //EVITAR!

Recetario IBM 669

2010-04-12T11:42:00.013-05:00

Hace unas semanas obtuve la certificación SOA de IBM de SOA, así que ahora puedo poner en el resumé que soy IBM Certified SOA Associate. En realidad, no creo que la forma en la que me preparé sea un ejemplo a seguir -por eso la demora en el post- pero igual la comentaré para que sirva de referencia a la gente que se lo quiera tomar más en serio.

Comenzó Marzo y con él la temporada de certificaciones gratuitas en la empresa en la que trabajo. En esos días andaba bastante ocupado con un software en producción bastante problemático, por lo que si quería certificarme tenía que ser en algo que no me demande demasiado tiempo (de preferencia, algo que ya conozca xD). Opté por la de SOA porque mis fundamentos de Web Services están bastante sólidos -modestia aparte xD- y un par de compañeros ya tenían la certificación así que podrían facilitarme orientación y material. Programé la certificación para fin de mes porque parecía un tiempo razonable.

Como siempre, revisé lo que la gente de Javaranch recomendaba para la certificación. Muchos coincidían en que SOA for Dummies de Judith Hurwitz era un buen punto de partida, así que me conseguí el libro y lo revisaba cuando podía. Como todo libro For Dummies, era bastante didáctico, elemental y bastante bueno para un novicio como yo. Encontrándome ya por el capítulo 10 caí en la cuenta que ya faltaban dos semanas para el día D por lo que necesitaba enfocarme más en el examen y en los temas en los que me iban a evaluar (el libro de Hurwitz es bastante amplio, y no contiene exactamente lo que IBM evalúa). Recurrí nuevamente a JavaRanch donde me recomendaron SOA Fundamentals in a Nutshell, un documento IBM de 34 páginas especialmente orientado a la certificación. Lo leí completo, con lo que tuve una mejor idea de qué es lo que IBM espera que uno sepa.

Revisé también la web del examen y me percaté que aún me quedaban muchos objetivos por cubrir. Entonces, era necesario revisar las lecturas que IBM sugería. El listado era inmenso, e incluye Redbooks, artículos de DeveloperWorks y cursos en línea. Dado que no disponía de mucho tiempo -ni ganas, que el tema de SOA no me emociona mucho- revisé solamente esto:

Best Practices for SOA Management (Capítulos 1 - 3)
Understanding SOA Security Design and Implementation (Capítulo 1)
WebSphere Service Registry and Repository Handbook (Capítulo 1)

Ya con esto me quedó más claro que es lo que IBM entiende por SOA. Ahora que ya tenía más confianza me puse a buscar mocks para hacerme una idea de cómo era el examen (y desistir si es que estaba muy difícil xD). Una vez más por Javaranch me topé con un grupo Yahoo de prepaparación para el examen SOA, donde estaban colgadas algunas preguntas de ejemplo. La mayoría de preguntas eran "de opinión" y a mi parecer eran bastante relativas; por ejemplo "¿Porqué la característa X es importante?" o "¿Cúales son los beneficios de utilizar Y?". En los documentos que había leído no se encontraban exactamente estas definiciones, pero tenía ya el suficiente conocimiento para hacerme una idea y responder a estas preguntas de acuerdo a mi criterio. Para sorpresa mía, parecía que mi criterio coincidía con el de IBM xD.

El 31 de Marzo me acerqué a New Horizons a dar mi examen. Como ya me habían anticipado los mocks, las preguntas "de opinión" eran mayoría, y las respondí con lo que me dictaba el sentido común. Las preguntas técnicas fueron poquísimas, y casi en su totalidad eran sobre temas de Web Services. Terminé el examen, y en el reporte de Prometric decía que había aprobado.

Eso sería todo. Espero les sea de utilidad.

Hasta otra!

How-to: Crear un Servicio Web JAX-RPC con IBM Websphere Integration Developer

2010-03-29T18:47:00.017-05:00

Una nueva sección en el blog! Dejamos temporalmente la retórica académica para bajar al llano. En esta primera entrega trataremos de dejar funcionando un servicio web en un servidos IBM Websphere Application Server (a partir de ahora WAS), haciendo uso del IBM Websphere Integration Developer (a partir de ahora WID) para facilitarnos las cosas. Dicho esto, empezamos:

Existen dos "enfoques" en la creación de Servicios Web: Con el enfoque ascendente, comenzamos con la construcción de las clases java y es base a estas clases que la herramienta nos genera la interfaz WSDL del servicio web. Si es que conoces mucho Java y poco XML, esta es tu opción. Por otro lado, en el enfoque descendente empezamos por definir la interfaz WSDL y es en base a este documento que la herramienta nos genera las clases Java en las que incluiremos la funcionalidad que necesitamos. Si es que te llevas bien con XML, este debe ser tu enfoque. Personalmente no es mi caso, pero es lo que utilizaremos en este tutorial xD.

El primer paso es definir una biblioteca donde crearemos nuestro documento WSDL y demás artefactos XML que podamos requerir. Vamos a File->New->Library, y le ponemos un nombre bonito a nuestra biblioteca :

Con la biblioteca creada, podemos empezar la construcción de nuestra interfaz WSDL. Uno de los puntos fuertes del WID es que puedes crear este documento siendo un total analfabeto de XML. Lógicamente ese no es nuestro caso, pero definir el WSDL mediante Wizards es más rápido y menos propenso a errores (además, XML no es de mis tópicos favoritos xD).

Entonces, comencemos con esto. Un servicio Web ofrece una serie de operaciones a sus clientes, y cada una de estas operaciones tiene parámetros de entrada y de salida. Empezaremos definiendo la estructura de nuestros parámetros de entrada, mediante Business Objects del WID. Clic derecho en nuestra biblioteca->new->Business Object. Le ponemos un nombre a nuestro objeto de negocio, y si queremos le asignamos una carpeta en la biblioteca:

El Business Object que hemos definido nos servirá para encapsular los parámetros de entrada que necesitará una de las operaciones de nuestro servicio web. Mediante el WID, asignamos como campos del Business Object la información que necesitamos como entrada a nuestra operación (Y hasta ahora, no hemos visto una sóla línea de XML) :

El WID nos permite definir el tipo de dato de cada campo, así como el número de ocurrencias y otras cosillas más. Pero, ¿que está haciendo el WID tras bambalinas? Pues toma la información que le entregamos y convierte nuesto colorido diagrama en una definición de esquema XML. Si no me creen, hagan clic derecho en el Business Object ->Open With->Text Editor para que puedan verlo con sus propios ojos:

Una definición de esquema XML puede ser utilizada para definir tipos en un documento WSDL, pero eso ya lo veremos luego xD. Ahora, es necesario crear otro Business Object que represente el resultado de la operación que definiremos luego. Procedemos de manera similar que con nuestro parámetro de entrada:

Ahora tenemos también una definición de esquema XML para los resultados de nuestra operación. Por si acaso, las definiciones de esquema XML son un estándar independiente y bastante complejo: soporta herencia, tipos compuestos y agrupaciones de diversa índole que pueden transformar nuestro modesto diagramita de un Business Object en algo mucho más monstruoso. Para efectos de simplicidad y compatibilidad se recomienda mantener nuestros esquemas sencillos, en el desarrollo de web service las incompatibilidades ("Mi cliente no soporta eso que está usando tu servicio") son pan de cada día.

Tenemos definidos los parámetros, el resultado, ahora estamos listos para la interfaz. Clic derecho en la biblioteca->New->Interface. Le colocamos un nombre y le asignamos una carpeta:

Tenemos ya la interfaz de nuestro servicio web, y necesitamos agregarle las operaciones que va a soportar. Definimos una operación de solicitud-respuesta (la otra opción son las operaciones de una vía, donde el cliente no espera una respuesta del servicio), le asignamos un nombre y asignamos como tipos de entrada y de salida instancias de los esquemas XML que hemos definido en los pasos anteriores. Deberían ver algo así:

Una vez más, es momento de la pregunta:¿Y qué está haciendo en realidad el WID? Pues está construyendo un documento WSDL para nosotros, haciendo referencia a los esquemas XML que definimos anteriormente. Para los incrédulos, pueden hacer clic derecho en la interfaz->Open with text editor:

Como ven, tenemos un WSDL convencional con elementos "import" que hacen referencia a los esquemas XML que ya teníamos. Pero,si ya han visto un WSDL antes, se habrán dado cuenta que le faltan dos cosas importantes: el elemento service y el elemento binding. Para terminar nuestro WSDL, necesitamos crear un Módulo de Mediación en WID. Seleccionamos File->New->Mediation Module. Le ponemos un nombre, seleccionamos Next y hacemos referencia a la biblioteca (Library) que habíamos creado antes:

El WID nos muestra un diagrama de ensamblado con un solitario Flujo de Mediación al medio. Es momento de agregarle a ese Flujo una interfaz, que es el WSDL a medias que tenemos en nuestra biblioteca: Clic al Export->Add Interface y ya:

Ahora que nuestro Flujo de Mediación tiene ya una interfaz, podemos generar el Export. Clic derecho en el Export->Generate Export, y predeciblemente seleccionamos "Web Service Binding". Escogemos SOAP como estándar de mensajería y HTTP como medio de transporte. Terminado esto, se observa que ha aparecido un nuevo elemento en nuestra biblioteca, bajo la categoría de Web Service Port: ese es nuestro WSDL completito. Vamos a echarle un ojo dándole clic derecho->open with->XML Editor. Lo primero que salta a la vista es que mediante un elemento import hace referencia al WSDL incompleto que creamos al inicio. También notamos que ya se han incluido los elementos binding y service, y que aún no hemos redactado una línea de XML :D

Con esto damos por terminado el tema de WSDL, para construir la aplicación Java que hará todo lo que nuestra interfaz dice (en teoría xD). Primero, necesitamos una aplicación Web Dinámica: Seleccionamos File->New->Other->Dynamic Web Project. Le ponemos un nombre al proyecto, un nombre al EAR que la contendrá y sobretodo seleccionamos donde pensamos desplegar nuestra aplicación. En nuesto caso, optamos por nuestro viejo y fiel WAS 6:

Y el WID generosamente nos proporciona la estructura básica de una aplicación Web en Java. Ahora se viene lo bueno: clic derecho en el proyecto Web->New->Other-> Web Service para configurar lo que será nuestro servicio Web. Lo primero es el tipo de Servicio Web, para esto JAX-RPC (que es la tecnología que usaremos) nos da dos alternativas: usar un Java Bean como Endpoint o un EJB. Por simplicidad usamos el primero, y como ya tenemos nuestro WSDL preparado el desarrollo va a ser Descedente. Por lo expuesto, seleccionamos "Top Down Java Bean Web Service". Al tratarse de un desarrollo descendente seleccionamos el WSDL que teníamos preparado, y le indicamos una vez más que desplegaremos en un WAS.

Seleccionamos siguiente. El WID nos muestra una casilla, que nos permite asociarle un paquete específico a un namespace determinado (caso contrario WID creará los paquetes, y no lo hace con estilo xD). Obviamos este paso, seleccionamos Finish y el WID se encargará de generar todo lo necesario para que podamos programar.

Echémoles un ojo a parte de lo mucho que ha generado el WID para nosotros. Observamos la interfaz del Endpoint (llamada también SEI: Service Endpoint Interface) que contiene las operaciones que nuestro cliente puede invocar mediante SOAP (en nuestro caso, sólo una). Como lo establece JAX-RPC, la SEI hereda de jax.rmi.Remote, y todos los métodos declaran la excepción java.rmi.RemoteException. También, el WID nos ha generado la implementación de esta interfaz -también conocida como SIB, Service Implementation Bean- que es donde irá la lógica de implementación del servicio.También está por ahí el descriptor de despliegue del servicio web, y los archivos de mapeo del JAX-RPC, pero por ahora dejémoslo ahí xD.

Ahora, veamos si es que no les he mentido y si es que este servicio funciona. Al momento de generar el servicio web, el WID ha colocado el WSDL y todos los XSD (definiciones de esquemas XML) necesarios dentro de la carpeta WEB-INF/wsdl. Clic derecho al WSDL definitivo-> Web Services-> Test with Web Service Explorer. Esta herramienta también la he visto en Eclipse, y es una forma bastante práctiva de ver si tu servicio funciona o no. Seleccionamos la única operación de nuestro servicio -notar que nos muestra un formulario para el ingreso de parámetros- y le damos Go. Si es que en la parte inferior aparece algo similar a la estructra de respuesta que hemos definido, es que hemos triunfado. Eso sería todo, por lo que declaro terminado el post más largo de la historia de este blog. Hasta otra!!

PS: Un agradecimiento a Carlos Lazo, que fue el que me ilustró en estas lides xD

El test de Joel para equipos de desarrollo

2010-03-15T17:22:00.013-05:00

(Imagen: Sidney Nolan - The trial)

Hay muchas señales que nos indican que un equipo de desarrollo no está funcionando como debería: muchos bugs, programadores trasnochados y cronogramas incumplidos son algunos de los más importantes. Joel Spolsky -en su blog - intenta formalizar esto un poco más y propone un examen de 12 preguntas para saber que tan bien -o mal- se desempeña un equipo de desarrollo. Aquí se los presento (y pór favor, no se depriman si reprueban xD):

1. ¿Utilizan software de control de versiones?

Siempre las primeras preguntas son las más fáciles xD. Afortunadamente, no me ha tocado trabajar en un proyecto donde no se utilicen estas herramientas. La más primitiva -pero eficiente- que he utilizado es Microsoft Source Safe en una de sus versiones primeras (y no se integraba al IDE); ya más adelante me topé con el CVS y el SVN (que trabajan de maravilla con Eclipse). Las ventajas de estas herramientas son muchas -mi favorita es que te permite detectar quien malogró tu código xD- y los costos son mínimos: los más populares son software libre, y sólo necesitarías una PC que te sirva como servidor. No hay excusa para no usarlos.

2. ¿Pueden generar un ejecutable en un sólo paso?

En el caso de aplicaciones J2EE, implica qué es lo que tienes que hacer para tener el EAR listo para el despliegue el producción. Mientras menos se tenga que hacer, mejor (dado que se reducen las posibilidades que metas la pata xD). Aquí uno podría ayudarse en scripts de Ant, aunque ahora las IDE's ya ayudan bastante (i.e clic derecho-> Exportar a EAR. C'est fini)

3. ¿Integran el código diariamente?

He visto con frecuencia la mala costumbre de esperar hasta pocos días antes del pase a producción para integrar el código construido por los programadores del proyecto. Cuando esto sucede, se obtiene una versión bastante inconsistente de la aplicación (faltan clases, algunas clases son sobreescritas, otras se repiten, y muchas atrocidades más) que lleva días estabilizar. Para evitar esta pesadilla, es mejor realizar integraciones diarias y subsanar las inconsistencias al instante: de ese modo dividimos la molestia de integrar en porciones más digeribles xD.

4. ¿Cuéntan con una base de datos de incidencias (bugs)?

Después de un pase -a pruebas de usuario o a producción- lo natural es que empiezen a llegar correos con errores a subsanar. Si se trata de un usuario insistente, puede llegar a llamarte y si es un usuario con poder puedes tener al gerente esperando a tu costado hasta que se solucione el error (me ha pasado). Es importante que las incidencias que lleguen estén centralizadas para evitar 1. Que se reporten como incidencias temas que ya han sido resueltos 2. Que ningún error quede sin ser atendido. A los usuarios les gusta llevar bastante este control mediante hojas excel, lo malo es que estos documentos son tan manoseados que se llega a tener 5 versiones simultáneas del mismo documento (esto también me ha pasado). La solución ideal es una base de datos de bugs, que según Joel debe tener esta información:

Secuencia de pasos para replicar el error
Comportamiento esperado (lo que debería hacer y no está haciendo)
Comportamiento actual (lo que el software hace y no debería hacer)
Responsable (el que crucificaremos si esto no se soluciona)
Estado (si el bug se eliminó no)

5.¿Se corrigen los errores antes de desarrollar nuevas funcionalidades?

Otra cuestión que he visto con frecuencia. La gente de control de calidad envía un voluminoso listado de incidencias, que es derivado al trainee mientras los desarrolladores siguen produciendo más código defectuoso. Como deben de haberles dicho muchas veces en la universidad -y Joel nos lo recuerda- mientras más te demores en corregir un bug más te va a costar hacerlo (en tiempo y en dinero).

6. ¿Se está al día con el cronograma?

Esta es difícil. La estimación en software es un arte oscuro, y me siento medio chamán cuando me piden que estime cuando me demoraría desarrollar la funcionalidad XYZ. A veces me liga, y a veces no. Sé que existen metodologías formales, pero por dejadez no he profundizado mucho en ellas y me remito a mi experiencia para estimar. Según RUP, si estimara en intervalos de tiempo más pequeños (iteraciones) en vez de intentar estimar el proyecto de porrazo la calidad del cronograma aumentaría. Suena bastante lógico, pero aún no lo he intentado xD.

7. ¿Redactan especificaciones?

Entiéndase especificaciones como documentos antes de programar (i.e especificaciones de casos de uso). No conozco desarrollador al que le guste documentar, y por ahora esa tarea penosa se la delegamos a los practicantes (trainees), y sabemos que eso está mal y nos sentimos culpables por eso xD. Joel plantea dos soluciones: 1. Mandar a los desarrolladores a cursos de redacción y 2. Centralizar la redacción de especificaciones en los jefes de proyecto. Me quedo con la segunda xD.

8. ¿Los programadores tienen la tranquilidad que necesitan?

Aquí Joel hace énfasis en la necesidad de silencio y de no ser interrumpido (por eso, el a sus programadores les asigna oficinas propias :S). Yo creo que depende bastante de la cultura de la organización. Por ejemplo, donde trabajo religiosamente a las dos de la tarde ponemos la radio para escuchar un programa humorístico radial; y todos trabajamos sin problemas y nadie se ha quejado. Ahora, cuando quiero programar en serio y no quiero ser molestado me pongo las audífinos para escuchar The Vines a todo volumen. Como dije, cuestión de estilos xD.

9. ¿Utilizan las mejores herramientas del mercado?

Empezando por el hardware. No se puede desarrollar software en la computadora que utiliza la secretaria para redactar en Word (y el Messenger xD). Si es que la PC se demora 5 minutos en compilar, lo que va a pasar es que el desarrollador se va a aburrir y va a bajar a comerse un aperitivo. Lo mismo con el software: puedes desarrollar procedimientos PL/SQL con el SQL Developer de Oracle (que es gratis) pero lo harías más rápido y mejor con el PL/SQL Developer (que te cuesta muchos dólares más). La idea es que el desarrollador esté feliz, para que el desarrollador sea productivo xD.

10. ¿Cuentan con personal de control de calidad?

A pesar de lo insistentes y quiquillosos que son, reconozco que son importantes. Ellos detectan errores que nuestro usuario final no verá, y nos hacen ver que a pesar de lo maravillosos que somos... los desarrolladores también nos equivocamos (en raras ocasiones xD). Según Joel, por cada tres programadores debe haber un tester. Creo que nos quedamos cortos xD

11. ¿Se requiere que los postulantes programen durante su entrevista?

De hecho que es la única manera de saber si es que el postulante sabe tanto como dice en su Curriculum, aunque siempre que yo he sido el entrevistado me han ocurrido percances. Varias veces me han hecho programar en IDE's que desconocía (lo que hacía que me demore más) y otra me hicieron usar clases que ni siquiera compilaban. Siempre debe procurarse que el postulente se encuentre en "condiciones ideales" xD.

12. ¿Utilizan el test de usabilidad del pasillo?

Esa es nueva xD. Consiste en hacer que cualquier individuo que encuentres en el pasillo (i.e el encargado de limpieza, la chica de la cafetería, etc) utilice la aplicación que estás desarrollando. Si no tienen la más mínima idea de qué hacer, vas por mal camino.

Ahora, a calificarse. Si tienes 12 (como Microsoft) vas bien, si tienes 11 es tolerable pero si tienes 10 o menos estás en serios problemas (Joel dixit). Por cuestiones de confidencialidad, no les puedo decir como quedó mi equipo, pero me gustaría que ustedes -visitantes anónimos- me digan como le fue al suyo. Hasta otra!

Una fábula

2010-01-28T18:06:00.005-05:00

(Imagen: El Greco - Fábula)

Érase una vez un proyecto de software, y como es muy común con los proyectos de software, estaba bastante atrasado.

A pesar de todas las horas extras que habían empleado Hugo y Paco- los desarrolladores- y las muchas horas extras que emplearían, terminar el proyecto en la fecha acordada parecía imposible. Y los programadores se lo dijeron a su Jefe:

- Jefe, sólamente trabajando 48 horas al día podríamos terminar esto a tiempo

El Jefe , que era el que había hecho la promesa de terminar al cliente, se puso a pensar como solucionar esta situación, dado que parte de su trabajo era quedar bien con el cliente. Fue entonces que tuvo una brillante idea:

- Muchachos, vamos a pedirles a Pepe y Toño que les den una mano.

Fue entonces que Pepe y Toño pasaron a formar parte del equipo de Hugo, Paco y el Jefe. Pepe y Toño eran programadores bastante capaces, pero dado que eran nuevos en el proyecto necesitaban cierta orientación para ponerse al corriente.

Por esto, Hugo se tomó un día en explicarles a Pepe y Toño en que consistiá la aplicación, y los problemas que ésta iba a solucionar. En ese día, hubiera podido avanzar el 20% de lo que faltaba por hacer, pero se dedico a ilustrar a Pepe y Toño.

Paco por otra parte, se tomo un día también para explicarles la arquitectura de la aplicación, los estándares que estaban siguiendo y las librerías que se estaban usando. De no haber tenido que hacer esto, hubiera avanzado un 30% más de los pendientes del proyecto.

Después de estos dos días de capacitación, Pepe y Toño se pusieron a programar. Pero como aún estaban frescos - y Hugo y Paco no eran buenos profesores- dejaron unos cuántos bugs que Hugo y Paco tuvieron que reparar. Esto les tomó un día a los dos, en el que hubieran construido el 50% de lo que necesitaban hacer si no hubieran tenido que reparar bugs.

Llegó la fecha prometida, y para sorpresa del Jefe, el proyecto todavía no estaba listo.

Moraleja: "Añadir mano de obra a un proyecto de software que se encuentre atrasado hace que se atrase aún más". Este es el enunciado de la Ley de Brooks para el desarrollo de Software, propuesta por Fred Brooks en su libro The Mythical Man Month (de 1975!! Desde entonces ya se sabe esto xD). Dicho de otra manera por el propio Brooks, "Nueve mujeres no pueden hacer un bebe en un mes". Casi todos los Jefes que conozco desconocen este principio, así que el objetivo de este post es educarlos xD. Pueden encontrar más en Wikipedia, o en este excelente artículo de Joel Spolsky

Los mandamientos del desarrollo de software

2009-12-04T17:43:00.002-05:00

Buceando en la web me topé con el artículo "Frequently Forgottenn Fundamental Facts about Software Engineering" de Robert L. Glass, en las que el autor enumera los que él considera los "teoremas" básicos a tener en cuenta al momento de construir software, y que lamentablemente parece que nadie considera. El listado que menciona lo realizó en base a su experiencia profesional y muchas de los principios que menciona han sido violentados en mi compañía, y a veces por mi persona. Paso a enumerar los que me llamaron la atención, junto a unos apuntes de mi parte:

Los buenos programadores son por lo general 30 veces mejores que los programadores mediocres. Dado esto, no se debe escatimar en los salarios de los programadores buenos, dado que siempre producen más de lo esperado

En una compañía en la que estuve, empezaron a reemplazar Analistas Programadores (gente con experiencia) por practicantes (novatos o "trainees"), bajo la excusa de reducir costos y aumentar la productividad -más programadores con menos presupuesto-. Lógicamente, un practicante demoraba 2 semanas en hacer lo que un AP podía hacer en un día, así que no creo que les haya resultado beneficioso.

El uso de una nueva herramienta o técnica reduce la productividad de los programadores y la calidad del producto inicialmente. Se obtienen beneficios una vez superada la curva de aprendizaje.

El arquitecto de donde trabajo es bastante "creativo", y constantemente incluye nuevas tecnologías en las aplicaciones que desarrollamos. El documentarnos sobre la tecnología nos toma como una semana, y cuando nos ponemos a desarrollar definitivamente lo hacemos más lento que con tecnologías más familiares. Pero ver cosas nuevas siempre es divertido xD.

El mejorar un atributo de calidad generalmente perjudica a otro atributo de calidad. Por ejemplo, el mejorar la eficiencia perjudica la flexibilidad a cambios de la aplicación.

Se me viene a la mente el uso de procedimientos almacenados en base de datos: disminuyen el tiempo de respuesta pero te hacen imposible el cambiar de DBMS. Como dicen por ahí, nada es gratis en la vida.

La detección y solución de errores representan el 40% de los costos de desarrollo. Por eso es una de las fases más importantes del ciclo de vida del desarrollo.

Yo me arriesgaría a decir que hasta el 50% de los costos.

De un software -que según un programador promedio ha sido exhaustivamente probado- sólamente se han ejecutado el 55%-60% de sus rutas lógicas. El soporte automático, como analizadores de cobertura, puede elevar este número a 85%-90%. Las pruebas al 100% son imposibles.

Es por esto que el personal de control de calidad no nos cae nada bien. Siempre salen con casos que uno nunca pensaba que se iban dar, y que generan un nada discreto mensaje de error. Aunque como se dice por acá, es mejor que lo vea un tester a que lo vea el usuario xD.

El software siempre contiene defectos residuales, aún después del proceso de eliminación de errores más riguroso. El objetivo es minimizarlos en número y en severidad.

Y sobre todo, que aparezcan después que se haya terminado la garantía xD.

Las mayoría de las tareas de desarrollo de software y de mantenimiento de software son las mismas- excepto por la tarea de mantenimiento adicional "Comprender el producto existente". Esta tarea es de suma importancia, y consume casi el 30% del tiempo de mantenimiento. Por esto, se puede decir que el mantenimiento es más difícil que el desarrollo de software.

Bastante cierto... no hay nada más difícil de entender que el código ajeno. Lo digo con conocimiento de causa, que sufrí 1 año dando mantenimiento a aplicaciones que parecían hechas por chimpancés.

Cuando un proyecto pasa de requerimientos a diseño, la complejidad del proceso de solución produce una exploción de "requerimientos derivados". La lista de requerimientos de la fase de diseño es por lo general 50 veces mayor que la lista de requerimientos original.

Nos pasa todos los días, y ocasiona amanecidas y/o retrasos.

La mayoría de estimaciones de software se desarrollan al inicio del ciclo de vida. Es decir, ocurren antes de la fase de requerimientos y por ende antes de comprender el problema. La estimación por lo general ocurre en el tiempo inapropiado.

Es por esto que los cronogramas de desarrollo son las artefactos más desatendidos e ignorados que conozco. Los hacen por protocolo, pero a la larga nadie los sigue (al menos en mi compañía). Tal vez cronogramas por iteración, como señala RUP, serían la solución.

Esos son los que me parecen más importantes, y creo que si los jefes de proyecto los leyeran nuestros días serían más llevaderos. A ver que opinan ustedes.

Recetario IBM 839

2009-11-21T10:05:00.013-05:00

Este es otro post de Recetario, por lo que podrán inferir que ya obtuve la certificación IBM Certified Solution Designer - IBM Rational Unified Process V7.0. Una vez más, procedo a contarles lo que tuve que hacer para tener este diploma en mi colección.

Si es que son asiduos del blog ya sabrán que venía de obtener la IBM Certified Solution Designer - Object Oriented Analysis and Design, vUML 2 y me encontraba en búsqueda de otra certificación con orientación a Ingeniería de Software y no tanto a Programación. Había pensado en un momento en la Certified ScrumMaster, pero para obtenerla es requisito haber asistido a un curso -bastante caro- antes de poder de dar el examen; así que mejor opté por la muy accesible certificación RUP de IBM: Un sólo examen y sin pre-requisitos.

Había visto un poco de RUP en la universidad, pero eso fue hace muchos años y mi memoria es bastante frágil, así que el primer paso era conseguirme un libro que refresque esos conocimientos que creía ya perdidos. Buceando en Amazon me topé con The Rational Unified Process: An Introduction de Philippe Kruchten, que viene a ser una guía para principiantes -o para jefes de proyecto, según se vea xD- del proceso RUP. Me leí hasta la última página del libro, y creyéndome ya un Dios en RUP me dispuse a probar suerte con los mocks de Elite Certify, solamente para fracasar y darme cuenta que aún faltaba mucho por leer.

Probando con los mocks me di cuenta que el contenido de las disciplinas de RUP (o sea, lo que había visto en la universidad y lo que había leído en el libro de Kruchten) es sólamente una pequeña parte del examen, y que más de la mitad del mismo trata sobre elementos del proceso y de temas de desarrollo iterativo. Recurrí entonces al material del curso IBM Essentials of the Rational Unified Process V7.0, que ya trataba más a detalle el desarrollo iterativo y los work products del proceso pero aún obviaba los elementos del método y del proceso, por lo que seguía reprobando los mocks que intentaba resolver.

La solución una vez más vino de los amigos de Javaranch. Un forista que ya había obtenido la certificación recomendaba la web de Hans Admiraal, así que de curioso fui a echarle una ojeada. Hans es un consultor especializado en RUP, y ofrece entrenamiento -lógicamente a un costo- para poder obtener la certificación que estaba buscando. Como "bonus track", Hans a colocado también un documento PDF donde indica que contenidos del Rational Method Composer había que revisar para cubrir todos los temas de la certificación. Yo tenía instalado el RMC desde que me encontraba estudiando para el IBM 833-834, por lo que grande fue mi sorpresa al descubrir que TODOS los temas de la certificación estaban descritos ahí, y a detalle. Seguí al pie de la letra los consejos de Hans y leí lo que él indicó, gracias a eso ya no tuve problemas con los mocks.

Sintiéndome bastante confiado, fui a decirle a la gente de mi trabajo que quería dar la certificación, que me encontraba listo y que esperaba que al tratarse de un partner de IBM me pagasen el examen - como había ocurrido con los exámenes 833 y 834. Contra todo pronóstico, me dijeron que esta vez no podían afrontar el gasto, y que si quería certificarme los 240$ (200$ del examen y 40$ de gastos administrativos de New Horizons) tendrían que salir de mi bolsillo. Habiéndole dedicado ya tanto tiempo a la certificación, no me quedó otra que aceptar, así que este fin de mes mi salario estará más chiquito que de costumbre.

Programé el examen para el martes pasado, me acerqué a las instalaciones de New Horizons para dar el examen y lo aprobé con una calificación que me deja satisfecho. Ahora pienso tomarme otro descanso, y probablemente al certificación que venga sea la IBM Certified SOA Associate, aunque ahora que no es gratis no estoy tan seguro. ¡Hasta otra!

Demostrar valor iterativamente

2009-11-06T16:07:00.002-05:00

(Imagen: El Greco - Visión del Apocalipsis)

Este principio explica los beneficios del desarrollo iterativo de software. Un proceso iterativo hace posible acomodarse al cambio, obtener retroalimentación y adaptarla al proyecto, reducir riesgos de manera temprana y ajustar el proceso dinámicamente.

Beneficios

Reducción temprana del riesgo
Mayor capacidad de predicción a lo largo del proyecto.
Confianza entre los stakeholders

Patrón

Permitir retroalimentación al incrementar el valor para el usuario en cada iteración
Adaptar los planes usando un proceso iterativo
Aceptar el cambio y administrarlo
Atacar los mayores riesgos técnicos, de negocio y de programación tempranamente.

Anti-patrones

Planear todo el ciclo de vida a detalle, controlar las variaciones respecto al plan (esto puede contribuir al fracaso del proyecto)
Evaluar el estado en los primeros dos tercios del proyecto confiando en la revisión de especificaciones, en vez de evaluar el estatus de resultados de pruebas y demostraciones de software funcionando.

Basado en el navegador de proceso del IBM Rational Method Composer

Colaboración entre equipos

2009-11-06T15:53:00.003-05:00

(Imagen: El Greco - La Sagrada Trinidad)

Este principio resalta la importancia de promover uno óptima comunicación entre miembros del proyecto. Esto se logra a través de una organización del equipo apropiada y configurando entornos de colaboración efectivos.

Beneficios

Productividad del equipo
Mejor acoplamiento entre las necesidades del negocio y el desarrollo y operaciones de los sistemas software.

Patrón:

Motivar a la gente para que realice su mejor esfuerzo
Crear equipos auto-administrados
Promover la colaboración horizontal entre funciones (como analistas, desarrolladores, testers)
Proveer entornos de colaboración efectivos.
Integrar a los equipos de negocios, software y de operación.

Anti-patrones

Explotar a los desarrolladores, haciéndolos trabajar largas jornadas, incluyendo fines de semana
Tener gente altamente especializada equipada con las mejores herramientas para realizar su trabajo, con colaboración limitada entre miembros del equipo e integración limitada entre sus herramientas. Se asumo que si cada uno realiza bien su trabajo el resultado será bueno.

Basado en el navegador de proceso del IBM Rational Method Composer

Disciplina: Requerimientos

2009-11-06T15:33:00.003-05:00

(Imagen: El Greco - Vista de Toledo)

Propósito

Establecer y mantener acuerdos entre los clientes y otros stakeholders sobre lo que el sistema debe hacer
Proveer a los desarrolladores del sistema de un mejor entendimiento de los requerimientos del sistema.
Definir los límites del sistema
Proveer las bases para planificar el contenido técnico de cada iteración
Proveer las bases para estimar el costo y el tiempo del desarrollo del sistema.
Desarrollar una interfaz de usuario para el sistema, centrándose en las necesidades y objetivos de los usuarios.

Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0

Disciplina: Modelamiento del Negocio

2009-11-06T14:48:00.003-05:00

(Imagen: Diapostitivas del curso de IBM)

Propósito:

Comprender los problemas de la organización objetivo e identificar oportunidades de mejora.
Asegurarse que los clientes y los usuarios finales tengan una comprensión similar de la organización objetivo.
Obtener requerimientos del sistema para dar soporte a la organización objetivo.
Comprender la estructura y la dinámica de la organización en donde se va a desplegar el sistema.

Esta disciplina usa un enfoque similar al de desarrollo de sistemas.

El modelamiento de negocio sirve de entrada a la disciplina de Requerimientos, dado que los modelos de caso de uso del negocio ayudan a comprender los requerimientos del sistema e identificar casos de uso del sistema. Sirve también de entrada a la disciplina de análisis y diseño, ya que las entidades de negocio del modelo de análisis del negocio ayudan a identificar clases entidad del modelo de análisis

Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0