Test Driven Development: Antipatrones

Que no tenga tiempo actualmente para escribir no significa que no lo tenga para leer.

James Carr nos muestra una lista de antipatrones a evitar cuando nuestro desarrollo es orientado a pruebas: TDD Anti-Patterns Catalogue.

Advertisements

¿Cuál es tu rol en un proyecto software?

  1. Gestor de proyectos es aquel que piensa que nueve mujeres pueden traer un bebé al mundo en un mes.
  2. Desarrollador es aquel que piensa que toma 18 meses traer un bebé al mundo.
  3. El empresario es aquel que pretende que una sola mujer puede traer nueve bebés al mundo en un mes.
  4. Cliente es aquel que no sabe por qué quiere traer un bebé al mundo.
  5. Manager de marketing es aquel que piensa que puede traer un bebé al mundo incluso si no hay hombres ni mujeres disponibles.
  6. El equipo de optimización de recursos piensan que no necesitan un hombre ni una mujer, ellos traerán un bebé al mundo con cero recursos.
  7. El equipo de documentación piensa que a ellos no les importa si se trae un bebé al mundo, ellos sólo documentarán nueve meses.
  8. El encargado de SQA es aquel que nunca está contento con el proceso de traer un bebé al mundo.
  9. El tester es aquel que siempre le dice a su mujer que ese no es el niño definitivo.

Adaptado de Michael Sync.

Marzo: Mes de los fallos en PHP

Promete traer cola… Mensaje de Una Al Día, Hispasec:

SecurityFocus publica una entrevista con Stefan Esser, fundador del proyecto Hardened-PHP e impulsor del PHP Security Response Team, que ha abandonado recientemente. Durante años ha contribuido al desarrollo de PHP y considera que el núcleo de programadores de este lenguaje no está concienciado con respecto a la seguridad. Por ello ha decidido crear el mes de los fallos en PHP.

Stefan Esser es un profundo conocedor del código fuente PHP y un investigador muy concienciado con la seguridad. Aunque desarrollaba el núcleo de PHP desde 2001, en 2004 fundó The Hardened-PHP Project, un proyecto destinado a tratar de forma responsable la gran cantidad de fallos de seguridad que estaba encontrando en el código PHP. Esser se quejaba del modelo de desarrollo del proyecto, donde se incluían nuevas funcionalidades sin tener en cuenta el impacto en la seguridad. Terminó por dejar de confiar en el producto que él mismo desarrollaba, cuestionó el trabajo del resto de desarrolladores, fue duramente criticado por la revelación pública de problemas de seguridad y finalmente, sin apoyo y ante la pasividad de sus compañeros, abandonó su puesto.

Esser opina que el código de PHP ha crecido demasiado rápido, que existen problemas de regresiones y que el PHP Security Response Team mira hacia otro lado. Afirma que este grupo fue capaz de confesar en público que no conocía problemas de seguridad en PHP cuando él mismo había reportado más de 20 errores sólo dos semanas antes. Es por este motivo que no piensa en que la revelación pública de estos fallos pueda considerarse “no ética”.

El mes de los fallos en PHP tiene como objetivo que los usuarios y especialmente los propios desarrolladores del código PHP tomen conciencia de que existen muchos fallos en el lenguaje. La fama de PHP en cuestión de seguridad es nefasta, principalmente por los “despistes” que comenten los programadores que lo utilizan como herramienta. Esser se centrará en errores específicos de PHP, no en los problemas comúnmente asociados con las aplicaciones construidas con este lenguaje (como pueden ser los fallos de inyección SQL o Cross Site Scripting) que pueden ser achacados a la gran masa de usuarios de PHP más que al lenguaje.

Aunque esta fama no es “justa” según Esser, sí que existen problemas asociados con el propio lenguaje que son completa responsabilidad de sus creadores. Algunos fallos han estado ahí durante años y si no es de esta forma, nunca saldrán a la luz ni se preocuparán por solucionarlos. Esser dice conocer muchos más de 31 errores, por lo que es probable que publique más de un problema de seguridad al día.

Esta iniciativa se antoja especialmente preocupante. A diferencia de las anteriores, se centra en un sólo producto, las aplicaciones suelen estar expuestas por web y en el supuesto de que los fallos descubiertos sean “sólo” aprovechables en local, esto también podría poner en peligro a servidores de hosting compartidos que se basan en este lenguaje. PHP es uno de los lenguajes más populares en servidores web de Internet y el número de aplicaciones expuestas, tanto en local como públicamente, programadas con él es literalmente inabarcable. Según la propia php.net, 20 millones de dominios, y 1.3 millones de direcciones IP lo usan, lo que supone, según nexen.net, un 34% de páginas web. Un toque de atención que sin duda causará un gran revuelo y mantendrá ocupados a millones de administradores durante el mes de marzo.

Las leyes de la física aplicadas a la industria del software

Primera Ley de Newton (Principio de Galileo)

En la ausencia de fuerzas, todo cuerpo continúa en su estado de reposo o de movimiento rectilíneo y uniforme respecto de un sistema de referencia Galileano.
O bien,
Todo desarrollador continua chateando o reenviando emails hasta que se le asigna trabajo.

Segunda Ley de Newton

La variación del momento lineal de un cuerpo es proporcional a la resultante total de las fuerzas actuando sobre dicho cuerpo y se produce en la dirección en que actúan las fuerzas.
O bien,
El número de cambios hechos en el software es directamente proporcional al sueldo recibido y toma lugar a una mayor velocidad mayor mientras más cerca esté un hito.

Tercera Ley de Newton (Ley de acción y reacción)

Por cada fuerza que actúa sobre un cuerpo, éste realiza una fuerza igual pero de sentido opuesto sobre el cuerpo que la produjo. Dicho de otra forma: Las fuerzas siempre se presentan en pares de igual magnitud y sentido opuesto.
O bien,
Por cada virus, existe un poderoso antivirus, y después de la salida al mercado de ese antivirus otro virus más destructivo aparece.

Primera Ley de la Termodinámica (Principio de Conservación de la Energía de Lavoisier)

La energía ni se crea ni se destruye, sólo se transforma. La cantidad total de energía en el universo permanece constante.
O bien,
Los bugs no se introducen o eliminan del software, sólo se transforman. El número total de bugs de un sistema permanece constante

Principio de Incertidumbre de Heisenberg

No se puede determinar, simultáneamente y con precisión arbitraria, ciertos pares de variables físicas, como son, por ejemplo, la posición y el momento lineal (cantidad de movimiento) de un objeto dado.
O bien,
Mientras más precisa sea la fecha de finalización del proyecto, la calidad de éste será mantenida de un modo menos preciso.

Maven works!

Después de haber pasado verdaderas calamidades en el proceso de construcción de mi Proyecto Fin de Carrera, y haber sido animado (y entrenado) por Manu Recena, por fin he integrado Maven2 en MaCMAS (no sin antes tener que cruzar un par de correos con Manu).

A continuación enumero un poco algunos detalles que considero interesantes.

  • Si bien el utilizar Maven2 desde el principio invita a tener perfectamente estructurado un proyecto, el caso de integrarlo en una estructura existente es algo problemático. No obstante, el POM nos proporciona métodos para definir nuestra estructura en caso de no ser la de por defecto, aunque con algún dolor de cabeza.
  • La sintaxis del POM es sencilla. Hace poco tiempo, pretendí hacer lo mismo con Ant. Sinceramente, no le dediqué apenas tiempo porque sabía que tarde o temprano pasaríamos a Maven2, pero a mí me ha parecido mucho más sencillo e intuitivo implantar Maven2 que hacer lo mismo con Ant, y con mucha más potencia.
  • El que Maven2 se base en XML para el POM me ha facilitado mucho la vida. El POM lo he escrito con VS2005, y gracias a tener definido el XSD del POM, he tenido en todo momento autocompletado y documentación mientras lo escribía.
  • En un mundo ideal, todos usamos Maven, por lo que manejar las dependencias entre proyectos es sencillísimo. Sin embargo, en el mundo real™ aún no es de uso generalizado. Esto me ha llevado a tener que escribir algún bat y a hacer algún hack en el POM para manejar mi dependencia con ArgoUML. Sin embargo, la dependencia con junit se maneja en tres líneas.

Aún habrá que refinar algunas cosillas, pero la verdad es que quedo tremendamente satisfecho con el resultado obtenido.

A partir de ahora, mvn compile, mvn package y mvn site entre otros harán mi vida más fácil. 😀

Bugtracking

Me:
haces click y peta
ta to a medias

Other:
esa frase ma gustao
ponla en tu blog
haces click y peta
jajajajajaja
deja solo move el raton