Category Archives: Desarrollo De Software

Abstracciones imperfectas

All non-trivial abstractions, to some degree, are leaky

Joel Spolsky

El desarrollo de software es como…

¿Qué es el desarrollo de software?

  • Es una ciencia (David Gries, 1981)
  • Es un arte (Donald Knuth, 1998)
  • Es un proceso (Watts Humphrey, 1989)
  • Es como tener un coche, siempre tienes que arreglar cosas (P.J. Plauger, 1993)
  • Es como conducir un coche, siempre tienes que ir haciendo pequeñas correcciones (Kent Beck, 2000)
  • Es un juego (Alistair Cockburn, 2002)
  • Es como un bazar (Eric Raymond, 2000)
  • Es como la jardinería (Dave Thomas & Andy Hunt, 1999)
  • Es como rodar Blancanieves y los siete enanitos (Paul Heckel, 1994)
  • Es como cazar hombres lobo o ahogarse con dinosaurios en una hoyo de alquitrán (Fred Brooks, 1995)
  • Es como construir un edificio (la mitad de la industria, 19xx)

Posiblemente muchos tengan parte de razón, aunque con la última comparación es con la que estoy totalmente en desacuerdo. Si tuviese que quedarme con una, escogería la de la jardinería. Queda muy cursi, pero es la realidad.

En definitiva, diría que el desarrollo de software es como crear/cuidar un jardín atestado de fauna (incluidos hombres lobo y dinosaurios) que evoluciona según las leyes darwinianas a un ritmo diez millones más rápido del normal (menos los dinosaurios, que están en huelga) y el cual es visitado por turistas españoles que les gusta crear hogueras y practicar sexo al aire libre, a la holandesa.

Web Services really sucks

Show me the interoperable, full and free implementations of WS-* in Python, Perl, Ruby and PHP. You won’t see them, because there’s no intrinsic value in WS-* unless you’re trying to suck money out of your customers. Its complexity serves as a barrier to entry at the same time that it creates “value” that can be sold.

Mark Nottingam

Este tipo no es un cualquiera (like me), trabaja actualmente en Yahoo, anteriormente en BEA y participó (ojo al dato) en el working group del WS-Addressing. Los Web Services, WS-*, han muerto desde hace tiempo (SOAP & family), menos mal que tenemos RESTful Web Services.

Don’t call us, we’ll call you

No nos llame, nosotros le llamaremos. También conocido como el principio de Hollywood. ¿De qué narices estoy hablando? Es obvio, de uno de los principios de la programación orientada a objetos.

En un sistema se suelen tener diferentes niveles de abstracción, diferentes capas o diferentes subsistemas unos por encima de otros; según el contexto se usaría un termino u otro. Este principio básico nos dice que los niveles superiores (el jefe en Hollywood) llamarán a los de abajo (los actores piltrafilla), pero no en el sentido contrario. No nos llame, nosotros le llamaremos.

Este principio aunque pueda parecer simple es mucho menos obvio de lo que se cree. Un simple hola mundo o derivados ya lo viola, pues un hilo de ejecución se hace cargo del flujo del programa, ahí estamos violando el principio, pues estamos dando la vara llamando a todo Hollywood para que nos dejen actuar. Los ejemplos más claros donde se puede ver cómo se aplica este principio son en los conocidos patrones de diseño Observer, Factory Method, Strategy, y sobretodo, el más evidente, el patrón Template Method. Explicaré brevemente con un ejemplo práctico este último para poder visualizar en él el principio de Hollywood.

Read More …

Me pone un debugger con patatas, por favor

He leído este post donde un desarrollador que ha asistido a una charla de Jim Weirich (creador de rake) habla sobre los debugger en general y sobre el poco soporte de un debugger en ruby en particular. Parece ser que algunos piensan que no tener soporte para un debugger es una feature:

Asking why Ruby has weak debugger support is like asking why a dolphin doesn’t have gills. Ruby has weak debugger support because Ruby programmers shouldn’t be using a debugger. Ruby supports TDD and BDD better than any other language except possibly Smalltalk. Debugger support is for languages that you can’t run tests against gracefully.

WTF? ¿Un debugger es para lenguajes en los que no se pueden ejecutar tests fácilmente? Una leche. Un debugger es una herramienta para el desarrollo, punto. Si tu lenguaje favorito resulta que no tiene (aunque ruby tiene), no te inventes teorías o intentes convencer al resto de programadores de otros lenguajes (que si tienen debuggers) que tienes razón. En definitiva, no me llores. Lógicamente ha habido muchas respuestas frente a argumentos tan inconsistentes y frágiles, como la estupenda respuesta cuando tus herramientas apestan….

La ausencia de un debugger no es una característica, es una importante y significativa carencia en tus herramientas

También hay que reconocer que usando TDD, o simplemente pruebas, deberíamos anticiparnos y detectar bugs, y un debugger debería de ser innecesario. Pero prefiero tener la opción de poder usar uno cuando quiera, que su carencia. El ansia que es muy mala, cuanto más, mejor, ¿no?.

Actualización Abril 2008: Meses después se podría considerar que hay herramientas más que suficientes como para debuggear aplicaciones ruby con bastante facilidad. No tan bien como lenguajes como C o Java, pero si decéntemente.

Curso online sobre Java y Web Services

java logo En JavaPassion.com Sang Shin, evangelizador de tecnologías Java, ofrece cursos online gratuitos sobre diversos campos Java. Estos cursos consisten en una serie de contenidos preparados por el propio Sang, tareas a realizar para enviárselas y un foro para comunicación de problemas, preguntas, comentarios, etc… Tiene un curso sobre Java en general, posiblemente no muy útil para cualquiera que haya programado ya en esta plataforma, pero un filón de oro para quien quiera aprender y comenzar en Java; otro sobre AJAX, un tanto ambicioso y demasiado disperso en cuanto a temario para mi gusto; otro sobre J2EE que parece realmente interesante, aunque bastante duro, pues toca muuuchas cosas, pero muchas; y, finalmente, otro de servicios Web.

Pasado mañana, viernes 24, comienza el curso sobre servicios web, no parece que haya que dedicar mucho tiempo, no porque trate pocas cosas, sino porque tiene una duración bastante larga. Así resumiendo, los temas más importantes que se tratan son:

  • JAXB y JAX-WS: nuevas apis de java para XML Binding y Web services, la primera la uso hasta para hacer el café y la segunda no me gustó nada cuando la probé, y no soy el único
  • SOAP & REST: REST powah, muerte a SOAP.
  • Otros modelos SOA: BPEL, JBI, Open ESB.
  • Seguridad, gestión y rendimiento en servicios Web

Al final, si has enviado todos los ejercicios y participado activamente en las discusiones, te da un diploma. Te podrías hacer el diploma con Gimp, si, pero no sería lo mismo y lo sabes ;). Por las impresiones de gente que ha cursado otros cursos, parece que malos no son. Una lastima no haber conocido la página antes (por ejemplo cuando me tocó aprender Java).

Por mi parte, dentro de dos días comenzaré con las primeras transparencias. Muchas cosas las conozco, pero sobre todo los últimos temas creo que serán bastante interesantes.

Actualización Abril 2008: ya terminó hace unos meses, y tengo mi diploma :).