[15 de 97] Elige bien tus armas, renuncia a ellas de mala gana

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:

"Elige bien tus armas, renuncia a ellas de mala gana."

Richard Monson-Haefel.. 

Richard Monson-Haefel. es el autor de los libros: "Enterprise JavaBeans (Ediciones 1-5)", JMS y es considerado un experto en el ambiente empresarial con java.
Fue arquitecto líder en el proyecto OpenEJB y en el contenedor EJB utilizado en Apache Geronimo; por si fuera poco, es miembro del JCP.

Su sitio web: http://www.monson-haefel.com

[NT. El título original del axioma es: Choose your weapons carefully, relinquish them reluctantly]

Aquí parte importante del axioma:
As a seasoned veteran of software design and implementation, every architect is armed with an array of weapons they’ve used with repeated success. For one reason or another, these technologies have found favor and bubbled to the top of our list of preferred solutions. Most likely they’ve earned their rightful place in your arsenal by defeating fierce competition. Despite this, a barrage of new technologies constantly threatens their position. [...]


To justify the risk involved with selecting new technology its benefits should be a quantum leap forward. Many new technologies claim such advancement but few deliver it. It’s easy to look at new technology and see technical advantages but those benefits are often difficult to sell to stakeholders. Before you decide to blaze a trail with new technology, ask yourself how the business will benefit from this decision. If the best outcome from a business perspective is that no one will notice, rethink your decision.


One last thing to consider is future relevance. [...]. Great technologies don’t always win. Trying to predict the winners early is a gamble that doesn’t yield a large payoff. Wait for the hype to die down and see if the technology settles into a space of usefulness. You’ll find many just go away. Don’t jeopardize your project for a technology that doesn’t have a future.

---

Apenas leía el axioma, irremediablemente recordé las discusiones que se daban en los inicios de este siglo sobre qué distribución Linux era más efectiva o eficiente; irremediablemente me transporte a las discusiones acaloradas (en aquellos ayeres llamadas flames) que surgían en los foros o incluso en los canales IRC.

Iban, como decía, desde distribuciones linux:

• "Debian es para hombres",
  
• "la gente educada usa Suse",
  
• "Suse es para niñas, Debian para antisociales, nada como Slackware"
• "Los hackers de verdad usan RedHat"
• etc
• etc
  

Hasta:

• Sistemas operativos:
• Linux vs Windows
• Lenguajes:
• Java vs .Net
• Frameworks:
• Struts vs JSPs a pelo
  

Debido a los mecanismos de la memoria que permiten recordar relacionando, pensar en linux me hizo recordar el  CONSOL 2002, dónde participo Ismael Olea; su platica fue sobre el proyecto LuCAS, durante la plática mencionó como los desarrolladores que utilizaban herramientas más raras eran vistos como los más poderosos o relevantes, decía ( palabras más, palabras menos): "mientras más rara es la herramienta, pareciera que es más útil y de mayor eficiencia o al menos más impactante".

Y (nuevamente escudándome en las formas de trabajar de la memoria) eso de herramientas raras me llevo a imaginarme que a veces nos gustaría tener una caja de herramientas con cosas tan excéntricas como las que encontramos en nuestro juego de rol favorito (en mi caso Diablo II: Lord of destruction)




Cerremos los ojos he imaginemos que nos han enviado a una misión especial y nos toca terminar una aplicación por demás compleja; cual nigromante, nos gustaría hablar con los cuasi zombies sistemas legacy's y darles vida para hacerlos interactuar con nuestro código.

Pero, para bien o para mal, ahora, con tantas y tan distintas tecnologías debemos olvidarnos de tener herramientas esotéricas y mejor seguir la técnica del paladín.
El objetivo ahora es tener herramientas:

• buenas,
• bonitas,
• efectivas en combate.
• Y que puedan ser fáciles de intercambiar.
  

¿No creen?

Regresando al axioma (y después de este curioso ejercicio de vinculación de recuerdos), yo me quedo con estos fragmentos:

• Antes de decidir adoptar una nueva tecnología preguntate cómo se beneficiará el negocio con esa decisión, si en el mejor de los casos nadie(de nivel gerencial) se percatará del cambio, reconsidera tu decisión
• Es importante reconocer los costos asociados a las deficiencias (que pueda tener) la nueva tecnología (seleccionada)
• Las grandes tecnologías no siempre ganan. Tratar de predecir prematuramente en una apuesta tecnológica es algo que no produce grandes ganancias.
• No pongas en riesgo tu proyecto con tecnologías que no tienen futuro.
  

Hace un tiempo(previendo este post) abrí un debate en debug_mode=ON con el título:
Selección de armas para un proyecto,  y preguntaba: ¿Cómo seleccionamos nuestras armas para nuestros proyectos?.

Aquí un resumen  de los comentarios:

• Venkman:
• Elegir un lenguaje o plataforma depende de lo que se vaya a hacer, como punto de partida[...]valoro que haya estabilidad, buena documentación disponible, una comunidad activa [...] y que la gente hable bien y hable mal de la "herramienta/arma"
  
• gimenete:
• Creo que lo que más valoro últimamente es la agilidad.Para elegir el lenguaje de programación también suele pesar mucho la agilidad. Un lenguaje que conozca me da más agilidad. A veces me creo herramientas propias cuando creo que las que hay no solucionan mis necesidades[..]
  
• danilat
• Para mi tiene bastante peso el dominio de un arma, por que te hace sentirte más seguro[...]También creo que en muchos casos de creación de estas herramientas(herramientas propias) se peca de NIH.
  
• amuino
• Lo principal es la familiaridad con la tecnología[...]A la hora de elegir entre varias opciones, no te comento nada nuevo... el criterio para Open Source sería el de actividad  y velocidad de respuesta a dudas/errores.
  
• GreenEyed
• Depende un poco del proyecto a realizar y sus circunstancias. Si el proyecto es importante y el tiempo no sobra, los experimentos con gaseosa y en casa.Si el proyecto no corre tanta prisa o no es tan crítico, entonces si que me gusta introducir cosas nuevas[]
  

Para ver el hilo completo da click aquí.

Con todo esto reafirmamos que, nada esta escrito sobre piedra, no existe fórmula única en este tema, nuevamente apelamos a la experiencia generada y compartida a lo largo de nuestros años de desarrollo.
<autopromoción>En el podcast no 55 de javaHispano, al final de  la emisión, hacemos una pequeña reflexión sobre el tema</autopromoción>

Me gustaría revivir este debate, y antes de que dilbert nos conmine a iniciar con una sonrisa la semana, me gustaría volver a preguntarles:
¿Cómo eligen sus armas?





Saludos !!
RuGI
Isaac Ruiz Guerra.

Posted at 09:52AM sep 26, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[9]

[14 de 97] Una linea de codigo funcional equivale a 500 de especificaciones.

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:

"Una línea de código funcional equivale a 500 de especificaciones."

Allison Randal. 

Allison Randal Es arquitecto en jefe y principal desarrollador del proyecto Parrot.
Con más de 25 años como programadora, ha desarrollado de todo, desde juegos hasta herramientas de análisis linguisticos pasando por websites, compiladores y demás.

[NT. El título original del axioma es: One line of working code is worth 500 of specification]

Aquí parte importante del axioma:

Design is a beautiful thing. A systematic, detailed presentation and review of a problem space and solution reveals errors and opportunities for improvement, sometimes in a startlingly dramatic way. The specifications are important because they provide the pattern for building. Taking the time to think through the architecture is important, both on a macro level with an eye for interactions between components and on a micro level with an eye for behavior within a component. 

Unfortunately it's far too easy to get wrapped up in the process of design, enthralled by architecture in abstract. The fact is that specifications alone have no value. The ultimate goal of a software project is a production system. A software architect must always keep an eye on this goal, and remember that design is merely a means to an end, not an end in itself. An architect for a skyscraper who ignored the laws of physics to make the building more beautiful would soon regret it. Losing sight of the goal of working code spells serious trouble for any project.

Value the team members who work on implementing your vision. Listen to them. When they have problems with the design, there's a good chance they're right and the design is wrong, or at least unclear.  It's your job, in these cases, to modify the design to meet real-world constraints by working with your team members to determine what works and what does not. No design is perfect from the start; all designs need to be modified as they are implemented.

If you're also a developer on the project, value the time you spend writing code, and don't believe anyone who tells you it's a distraction from your work as architect. Your vision of both macro and micro levels will be greatly enhanced by the time you spend in the belly of the beast bringing it to life.

Para este axioma iniciaré con una anécdota,  y compartiré dos refranes que según una encuesta, forman parte de los 150 refranes más utilizados en este país del águila devorando a la serpiente, todo esto con el único fin de contextualizar la reflexión del axioma y evitar lo más que se pueda una mala interpretación.

Va la anécdota:
Hace ya varios años, estábamos a punto de liberar una aplicación sencilla a producción: el objetivo de la aplicación era poner a prueba el uso de una herramienta para la creación de flujos de trabajo, está demás mencionar el nombre de la herramienta. Honestamente, la herramienta era muy buena para construir flujos básicos y escenarios no tan complejos, su único punto débil era la complejidad requerida para meter código personalizado en algún punto del flujo.
Para no hacer el cuento largo, ocurrió lo siguiente: la aplicación funcionó de maravilla en los ambientes de: desarrollo, integración, y QA, pero, al momento de llegar a producción, la ingrata (sí, ingrata) herramienta no lograba procesar adecuadamente un stream de bytes que contenía una imagen. El mensaje de error (como siempre muy descriptivo en este tipo de herramientas) decía algo más o menos así : el stream no es válido.

El encargado de ese fragmento de código se negaba a realizar cambio alguno pues indicaba que el código había pasado sin problemas todos los ambientes y no tenia caso poner en riesgo el entregable completo; además de que, la única manera de encontrar la posible falla era agregando código para "loggear", lo cual  iba en contra de las "mejores prácticas" del uso de la herramienta.
Doy mi palabra que, como ocurre en las películas, durante la discusión para encontrar como solucionar el problema tuve un flashback  y llegó a mi mente, cual albatros estrellándose en mi frente,  la noción de que el EOF en algunos lenguajes se podía substituir por la constante -1.
La solución:  se agregó un -1 al final del stream. Con eso la recuperación del stream funcionaba bien en todos los ambientes.

¿Por qué en el ambiente de producción no funcionaba el código original? nadie logró dar una explicación totalmente convincente, el asunto fue que, con esa "maniobra" todos vivieron felices para siempre (bueno, realmente vivieron felices en lo que les cambiaron la herramienta por otra mas popular)

Van los refranes:

• "Ni muy MUY, ni tan TAN"
• "Ni tanto que queme al santo, ni tanto que no lo alumbre"

Va la reflexión:
¿Entonces? todo lo que hemos reflexionado sobre: diseño, patrones, integración continua, etc,etc... ¿Está demás?
La respuesta es, por supuesto que no está demás,  al contrario la idea de todas estas reflexiones es tratar de  analizar y compartir los axiomas del libro para poder, entre todos, mejorar nuestros procesos de desarrollo de software y, de ser posible, reflejar esas mejoras en nuestra vida diaria. ;)

Creo que Allison lo explica en estas líneas(parafraseando):

Tomarse el tiempo para pensar en la arquitectura (de la aplicación) es importante: tanto a alto nivel, para poder visualizar las interacciones entre los componentes; como a bajo nivel, para poder ver el comportamiento dentro un componente.
Desafortunadamente, es muy fácil envolverse en el proceso de diseño, cautivados por la (definición de la) arquitectura (muy) en abstracto.
{...}
El objetivo final de un proyecto de software es (llevar/poner) el sistema en producción.
Un Arquitecto de software siempre debe mantener claro ese objetivo, y recordar que el diseño es simplemente un medio para tal fin, no el fin en sí mismo.

Entiendo que, esas líneas podrían orillarnos a calurosas reflexiones filosóficas o incluso (pro/anti) maquiavélicas pero, creo que de momento, podemos abstraernos a un nivel no tan alto. XD

Cómo ya hemos dicho, y seguiremos diciendo, el truco será siempre, encontrar el sabio equilibrio.
Discutir y compartir opiniones seguramente nos ayudan a tener un mejor criterio para decidir y alcanzar este equilibrio, así que, como siempre.... agradezco desde ya sus valiosos comentarios.  ;)

Saludos y buena semana a todos!!!



---
RuGI
Isaac Ruiz Guerra.

Imagen tomada de: http://en.wikipedia.org/wiki/File:Lewis_Hine_Power_house_mechanic_working_on_steam_pump.jpg

Posted at 12:05AM sep 06, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[3]

[13 de 97] Hacer commit y correr, es un crimen.

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:

"Hacer commit y correr, es un crimen."

Niclas Nilsson.

Niclas es cofundador de la empresa factor10 y es editor en la comunidad de arquitectura en el sitio InfoQ.
Su blog es: http://niclasnilsson.se

[NT. El título original del axioma es: Commit-and-run is a crime.]

Aqui parte importante del axioma:

It's late in the afternoon. The team is churning out the last pieces of the new feature set for the iteration, and you can almost feel the rhythm in the room. John is in a bit of a hurry though. He's late for a date, but he manages to finish up his code, compile, check-in and off he goes. A few minutes later, the red light turns on. The build is broken. John didn't have time to run the automated tests, so he made a commit-and-run and thereby left everybody else hanging. The situation is now changed and the rhythm is lost. Everybody now knows that if they do an update against the version control system, they will get the broken code onto their local machine as well, and since the team has a lot to integrate this afternoon to prepare for the upcoming demo, this is quite a disruption. John effectively put the team flow to a halt because now no integration can be done before someone takes the time to revert his changes.

This scenario is way too common. Commit-and-run is a crime because it kills flow. It's one of the most common ways for a developer to try to save time for himself, that ends up wasting other peoples time and it is downright disrespectful. Still, it happens everywhere. Why? Usually because it takes too long time to build the system properly or to run the tests.

This is where you, the architect, come into play. If you've put a lot of effort into creating a flexible architecture where people can perform, taught the developers agile practices like test-driven development and set up a continuous integration server, then you also want to nurture a culture where it's not alright to waste anybody else's time and flow in any way. [ ...... ]

Invest time in making the system fast to work with. It increases flow, lessens the reasons for working in silos and in the end makes it possible to develop faster. Mock things, create simulators, lessen dependencies, divide the system in smaller modules or do whatever you have to. Just make sure there's no reason to even think about doing a commit-and-run.

---

Sí, ¡¡¡ es un crimen !!! y quizá no en el sentido legal de la definición, pero sí en un sentido moral.

Me desviaré un poco del tema principal del axioma para comentar (y quizá externar algunas ideas a manera de terapia) algunas reflexiones que surgieron durante una plática con Javier Castañon durante la 8a reunión de las comunidades SpringHispano, JavaMéxico y Grails-MX.

La plática en general trataba sobre administración de proyectos y,  durante la charla, Javier mencionó tres puntos que considera primordiales para que se pueda gestionar adecuadamente un equipo de trabajo:

• Comunicación
• Transparencia
• Rendición de cuentas.

Seguramente lo que se comentó durante esa charla servirá para más reflexiones, pero, en esta ocasión, retomo solo ese comentario.

De los tres puntos mencionados, considero el primero el más importante; el tema de la transparencia me parece también importante, pero, quizá por razones de supervivencia, creo que a veces y sólo a veces es necesario quedarse con algo para uno mismo (Sun Tzu tiene la culpa de que piense así ) y sobre la rendición de cuentas no tengo mucho que decir... para nadie es secreto que considero altamente probable la existencia del  karma   ;)

La transparencia puede verse en este ejemplo justo en el momento que el build se rompe y le llega a Jhon y al líder del proyecto un e-mail indicando que su commit ha roto el build. La rendición de cuentas llegará el día en que se haga pública la lista de "quienes han roto mas veces el build"; pero, parece que el ejemplo del axioma podría bien servirnos como  ejemplo de qué es lo que ocurre cuando la comunicación falla (Jhon pudo haber avisado que tenia un compromiso y, haber hecho el commit y las pruebas con tiempo).

Independientemente de las reflexiones que salgan del axioma, creo que situaciones como las que se comenta arriba ni siquiera alcanzan la primera agravante de ley (premeditación), y mucho menos llegan a las otras dos (alevosía y ventaja), cuando cada elemento del equipo tiene la conciencia, responsabilidad y compromiso; primero, con su trabajo y, si quiere, después con el equipo.

---

A propósito de temas relacionados con  la administración de proyectos, hay un post (con todo y fe de errata) de José Manuel Beas llamado:  Liderar mediante el ejemplo. De lectura recomendable.

Ahora sí, retomando el axioma... Nilsson deja muy claro el porqué debemos considerarlo un crimen: "rompe el flujo de trabajo de todo un equipo" y miren que mis lapsus pesimista me hace pensar que ese efecto puede ser el menos complicado, quizá no sólo se altera el ritmo de trabajo, sino que  incluso pone en riesgo una fecha de entrega (sí, ya le metí drama al asunto XD ).

Nilsson  menciona que, probablemente el tiempo o la "ruta/mecanismo de ejecución" de esas pruebas hacen que el "sospechoso-en-potencia" decida, con el objetivo de ganarse unos minutos, omitirlas.

¿Qué hacemos entonces para evitar caer en estos escenarios que (perdón por la insistencia y el drama pero, como decimos en México: cada quien platica, según como le fue en la feria.) pueden tener efectos serios en todo el equipo del proyecto?

Nilsson lo tienen claro; tener una "cultura de pruebas" puede ser el inicio de la solución; a mi parecer: ya no pensemos siquiera en  automatizadas, el sólo hecho de comenzar a crear la conciencia de que debemos probar adecuadamente nuestro código antes de hacer commit puede ser un excelente inicio.

En estos momentos, con las facilidades que nos dan algunas herramientas de integración creo que tenemos solucionado parte del problema.

Resumiendo:

El problema.
1. Hacer commit (sin hacer las debidas pruebas) es un crimen ya que mata el flujo(de trabajo de todo el equipo).... y en casos un tanto desafortunados puede generar efectos secundarios más complejos.

Parte de la solución:
2. Crear una cultura de pruebas y un  ambiente de desarrollo/construcción/despliegue (recomiendo este interesante post de Julio Cesár Pérez Arques sobre un ecosistema de software)  que permita que el desarrollo y proceso de build sea ágil y seguro.

El objetivo:
3. Asegurarnos que; del lado del proceso de desarrollo/construcción/despliegue del producto no exista nada que permita o incentive ese apócrifo pensamiento: "Haz commit y salte corriendo".

¿Se nos ha pasado algo?

Bueno, dejemos.... una vez más que Dilbert nos haga iniciar bien la semana.






---

Saludos a todos!!
RuGI
Isaac Ruiz Guerra.

Posted at 02:43AM ago 23, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[7]

[12 de 97] Evita las buenas ideas.

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:

"Evita las buenas ideas"

Greg Nyberg es actualmente un consultor independiente de JEE con 18 años de experiencia diseñando, construyendo, probando y poniendo en producción aplicaciones transaccionales de grandes volúmenes. Es el autor principal del libro: Mastering WebLogic Server (Wiley).

  Aquíparte importante del axioma:



Good ideas kill projects. Sometimes it's a quick death, but often it's a slow, lingering death caused by missed milestones and a spiraling bug count.

You know the kinds of good ideas I'm talking about: Tempting, no-brainer, innocent-looking, couldn't-possibly-hurt-to-try sorts of ideas. They usually occur to someone on the team about halfway through a project when everything seems to be going fine. Stories and tasks are getting knocked off at a good pace, initial testing is going well, and the rollout date looks solid. Life is good.

Someone has a "good idea," you acquiesce, and suddenly you are re-fitting a new version of Hibernate into your project to take advantage of the latest features, or implementing AJAX in some of your web pages because the developer showed the user how cool it is, or even re-visiting the database design to utilize XML features of the RDBMS. You tell the project manager you need a few weeks to implement this "good idea," but it ends up impacting more code than originally anticipated, and your schedule starts to slip. Plus, by letting in the first "good idea," you've allowed the proverbial camel's nose in the tent, and soon the good ideas are coming out of the woodwork and it becomes harder to say no (and the camel is soon sleeping in your bed).

The really insidious thing about "good ideas" is that they are "good." Everyone can recognize and reject "bad" ideas out of hand - It's the good ones that slip through and cause trouble with scope, complexity, and sheer wasted effort incorporating something into the application that isn't necessary to meet the business need.







Debo confesar que este axioma me parece de entrada pesimista, pero, revisando la lista de axiomas del autor, veo que deben ser tomados como axiomas de "cautela y advertencia" (probablemente le ha tocado participar en proyectos muuuy exigentes o críticos)

Su otro axioma ya lo habíamos platicado:

• [4 de 97] Lo Perfecto es enemigo de lo suficiente.

Y, retomando el comentario, creo que son axiomas de cautela ya que, si no los tomamos con las debidas reservas, pueden ser hasta contraproducentes.

Iniciemos la reflexión.

Hace algunas semanas atrás en una presentación(disponible en slideshare) de Sergio Acosta titulada: "Por que Scrum no funciona". Justo en la diapositiva 100, Sergio comentaba algunos puntos interesantes sobre cómo se desarrolla el software en la NASA y, cómo sus procesos limitan la creatividad de los programadores.



Creo que Nyberg se refiere, en su axioma, a (este tipo de ) las buenas ideas que generan la creatividad necesaria para generar niveles de incertidumbre que un proyecto no puede tener dado su nivel de importancia.
A todos nos queda claro que el más mínimo detalle que se salga de control en una aplicación espacial puede tener consecuencias muy costosas.

El axioma de Nyberg incluye una breve lista con ejemplos:

• "Wouldn't it be cool if …" Really, any sentence with the word "cool" in it is a danger signal.
• "Hey, they just released version XXX of the YYY framework. We ought to upgrade!"
• "You know, we really should re-factor XXX as long as we are working on ZZZ …"
• "That XXX technology is really powerful! Maybe we could use it on …"

Y me permito compartir un par de anécdotas que me han ocurrido en los últimos años.

Struts 1.0.x a Struts 1.1
Supongo que le pasó a más de uno, cuando Struts era el rey, muchos tratábamos de mantenernos en la más reciente versión; recuerdo que una vez alguien actualizó la versión (sin avisar) y nos llevo casi media mañana darnos cuenta que los Action no hacían forward ya que, un método perform dejó de existir y ahora requeríamos invocar a execute.

int a byte
Debo confesar que esta es mía XD, era el 2002 apenas tenia un par de años programando con java (ocupaba en su momento a el otro rey de la época: JBuilder) y me tocó darle mantenimiento a una aplicación que tenia algunos problemas de validación, mi labor era construir nuevas piezas y no corregir dichos problemas.

En una ocasión, vi un fragmento de código que podía lanzar una excepción por recibir un valor superior soportado por  la base de datos; me pareció buena idea ajustar dicho valor en el respectivo Bean a byte(era int); justo en ese momento me piden hacer commit de mis cambios y yo sin problema accedí a hacerlo (total es solo un campo, pensé, además evito un error en la capa de datos y hago que la aplicación se ahorre unos 3 valiosísimos bytes)..... sólo pasaron unos segundos para que la oficina pareciera fiesta de celebración de independencia (recordaran que JBuilder emitía un sonido parecido al de una leve explosión cuando, al compilar, encontraba errores), los errores de compilación que se generaron por las "quejas" de los métodos que recibían el int( por omisión, un literal entero es de tipo int y debe recibir un casting para poder "verlo" como byte;al igual que un literal decimal es double y  no float)  no se detuvieron hasta después de un par de minutos..... resultó que ese diminuto Bean era el parte del core de la aplicación y, no habían hecho el cambio de int a byte precisamente porque afectaba demasiadas clases y, nadie había querido cargar con la responsabilidad de modificarlas.

Seguramente ustedes tendrán también anécdotas para compartir ;)

Entonces ¿Definitivamente no tomamos en cuenta las buenas ideas? Por supuesto que debemos tomarlas en cuenta. Ahora mismo me encuentro en un proyecto del cual no estaríamos tan cerca de terminarlo con cero bajas, sino fuera por las buenas ideas y los aportes de cada uno de los integrantes del equipo.

Siendo sinceros este axioma puede parecer alarmista, pero, como bien dice la semiótica, en el ultimo de los casos, el contexto da el significado.
A manera de defensa del axioma, pienso que debemos tomar en cuenta el contexto de una aplicación para poder aplicarlo o no.

Así que; salvo sus experimentadas opiniones, según lo que yo sé y a riesgo de equivocarme, la frase:

Evita una buena idea

  Debería quedar así:

Evita (implementar) una buena idea ((en proyectos críticos|siempre) (sin antes hacer exhaustivas pruebas de [integración|impacto|regresión]))

Y miren que de integración ya hemos hablado ;)

En fin, como hemos venido comentando, el secreto de hacer mejor las cosas es adquirir la experiencia suficiente para poder saber: hasta cuando y hasta dónde.
¿No creen?

Dejemos que Dilbert nos incite a iniciar bien la semana.


Saludos a todos!!!
---
RuGI
Isaac Ruiz Guerra.

Posted at 11:58PM ago 09, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[6]

[11 de 97] Tambien tienes que saber de hardware.

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:

"También tienes que saber de hardware"

Kamal Wickramanayake. 

Kamal Wickramanayake es un arquitecto de software que vive en Sri Lanka. Está certificado en TOGAF por el Open Group.

[NT. El título original del axioma es: You have to understand Hardware too]

  Aquí parte importante del axioma:


For many software architects, hardware capacity planning is a topic that lies beyond their comfort zone, yet it remains an important part of the architect’s job.  There are a number of reasons software architects often fail to properly consider hardware but they mostly have to do with a lack of understanding and unclear requirements. 

The primary reason we neglect hardware considerations is that we are focused on software and tend to ignore hardware demands. In addition, we are naturally isolated from hardware by high-level languages and software frameworks.

Unclear requirements are also a factor as they may change or may be poorly understood.  As the architecture evolves hardware considerations will also change.  In addition, our clients may not understand or be able to predict the size of their own user base or system usage dynamics.  Finally, hardware is constantly evolving. What we knew about hardware in the past does not apply today. 

Without hardware expertise predicting hardware configurations for systems to be developed is highly error prone. To compensate some software architects use large safety factors. Such safety factors are generally not based on objective assessments or founded in any methodology. In most of the cases, this leads to excessive infrastructure capacities that will not be utilized even in periods of peak demand. As a result, clients' money is wasted on more hardware than a system will ever need.

The best defense against poor hardware planning is to work closely with an infrastructure architect.  Infrastructure architects, unlike software architects, are specialists in hardware capacity planning and they should be a part of your team.  However, not every software architect has the luxury of working with an infrastructure architect. In such cases there are some things a software architect can do to mitigate errors when planning for hardware.

Hardware capacity planning is as important as software architecture and it needs to be given a first order priority whether you have an infrastructure architect on hand or not.  Just like an architect is responsible to establish the links between business demands and a software solution, she is responsible to envision the links between hardware and software.
 

A riesgo de equivocarme, creo que una de las cosas que hacemos en nuestros inicios en este peregrinaje evolutivo, es que, pasamos por alto cuestiones de bajo nivel, y, escudándonos con la abstracción, dejamos los temas relacionados con el hardware para "alguien más".

Voy a iniciar este post compartiendo una anécdota para ejemplificar un poco lo costoso que puede ser que pasemos por algo que:  lo efímero y etereo de nuestro código requiere bases físicas, tangibles, medibles  y sobre todo, algo que se nos olvida constantemente,  limitadas.

Hace un par de años me encomendaron realizar una pequeña aplicación de escritorio que tenia que ser distribuida mediante JNLP, la tarea parecía sencilla (iluso de mí) sólo se trataba de manipular en promedio unas 20 imágenes y agruparlas de una manera amigable, estaba a punto de terminar cuando el encargado de proyecto me dijo:

-"Espero que ya te hayan comentado de la restricción que tenemos con las maquinas-cliente"
 -Lo primero que pensé fue: "Sabia que no sería fácil".
-"¿Cual restricción?" pregunté.
-"Los equipos solo cuentan con 256MB en memoria RAM" argumentó.
- No pude evitar reírme,  cuando me dice:
-"No, no te rías, es en serio"

A partir de ahí, una tarea sencilla se convirtió en una tarea algo compleja y llena de pruebas, certificaciones por parte del cliente y cambios en la manera en que manipulaba los BufferedImage :P

Y, aquí el punto es que, no sólo importa conocer las condiciones actuales del hardware sobre la cual se ejecutará nuestra aplicación, sino que además cuales serán las previsiones que debemos tomar para el crecimiento de nuestra aplicación.

Aunque suene más filosófico que técnico, debemos aprender a crecer (o ¿aprender es crecer?); y en ese viaje seguramente nos toparemos con los términos: Escalabilidad y Capacity Planning.

Así que, me permito compartirles estos enlaces que considero pueden ser útiles:

• Diseñar para favorecer la escalabilidad.
• Documento del sitio MSDN con teoría sobre la escalabilidad.
  
• Fundamentos de escalabilidad.
• Breves conceptos sobre la escalabilidad.
• Estrategias para la escalabilidad  de aplicaciones
  
• (PDF)Presentación del  SG06.
• Martín ha tocado el tema constantemente.
• Dos blogs en español sobre escalabilidad.

Y, hablando de Capacity Planning, uno de los libros que más se están moviendo en amazon es el siguiente:







The Art of Capacity Planning: Scaling Web Resources (Paperback)
by John Allspaw (Author)





Seguramente, como hasta ahora, sus comentarios enriquecerán este post.  ;)  pero, en lo que llegan, Dilbert tiene cosas que decir:



Buena semana a todos!!!
---
RuGI
Isaac Ruiz Guerra.

Posted at 11:24PM jul 26, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[18]

[10 de 97]. Comparte tus conocimientos y experiencias

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:

"Comparte tus experiencias y conocimientos."

Paul W. Homer

Paul es desarrollador de software, escritor y fotógrafo ocasional, tiene varias décadas como desarrollador y lucha constantemente para construir sistemas más complejos.
En los últimos años ha orientado su atención hacia la comunicación con sus compañeros; esto incluye un libro auto-publicado.
Es alguien interesado en hacer crecer esta industria.

Su blog: http://theprogrammersparadox.blogspot.com

  Aqui parte del axioma:


From all of our experiences, including both success and failure, we learn a great deal. In a young industry like software development, disseminating this experience and knowledge is vital in helping sustain progress. What each team learns in its own tiny little corner of the world is possibly influential across the globe.

Realistically our fundamental knowledge base for software development, that is, the knowledge that is absolute and theoretically correct, is small compared to what is necessary to successfully develop a project. To compensate,we guess, rely on intuitive judgments or even pick randomly. In that, any major development project generates empirical evidence into what works and what fails. We're gradually working through the permutations, which we want to apply back to industry as a whole.

The act of discussing something always helps to show its weaknesses.You don't really understand something, until you can explain it easily. It's only by putting forth our explanations and discussing them that we solidify the experience into knowledge.

Ultimately, we are human beings so not everything in our minds is correct; not every thought we have is reasonable. It's only when we accept our flaws that we open up the possibility of improving. The old adage about learning more from failure always holds. If our ideas and beliefs do not stand the test of a debate, then it is better we find out now, than build on it later.

We really want to share our knowledge and experience to help the industry progress; we also realize it helps ourselves to understand and correct it. Given the state of so much of our software, it is clearly important for us to take every opportunity to share the things we know, what we think we know, and what we've seen. If we help those around us to improve, they'll help us to reach our full potential.


Elegí este Axioma por dos motivos, el primero es que complementa las reflexiones que hemos hecho semanas recientes y el segundo, estos días he andado algo  inspirado ;).... Como luego decimos: me curo en salud por lo romántico o idealista de este post, pero, cuando ando inspirado ...ando inspirado XD.

Son varias las cosas que  hacen que crea que este tiempo que vivimos sea especial, y, más allá de que:
a) Nos toco un año de tres ceros  (¿alguien tiene alguna anécdota de ese año?),
b) Quizá nos toque ver el cumplimiento de algunas profecías,... al menos en cine (soy de la idea de que algún niño travieso escondió el resto del calendario jeje)
c) Estamos aprendiendo a ver más allá de lo evidente;

Lo que realmente hace que esta época sea especial es que... sencillamente:   es la que nos ha tocado vivir.   :)

Reflexionando en otro sentido, y a propósito del axioma, también son varias las cosas que hacen que crea que la mejor manera de crear sinergia  es compartiendo.  Según lo que yo sé y a riesgo de equivocarme: compartir es el secreto para muchas cosas.

A este tenor, me quedo con esta parte del axioma:

Queremos realmente compartir conocimientos y experiencias para ayudar el progreso de la industria[...] Si ayudamos a mejorar a los que nos rodean, (probablemente en respuesta)  nos ayudarán a alcanzar nuestro máximo potencial.

Es mucho aún lo que nos falta por avanzar pero, lo importante es comenzar a hacer cosas.

Aquí dos propuestas:

• Escribe:
  
• Si tienes un blog técnico, mantenlo vivo, si tienes cosas que decir: crea uno, si no encuentras documentación en nuestro idioma sobre alguna tecnología: escribe algo, responde en los foros que frecuentas, alimenta un wiki,etc
  

• Participa:
  
• ¿Tienes oportunidad de estar en un User Group? participa; ¿Puedes reunirte con algunos colegas para compartir experiencias? hazlo.

En pocas y efímeras palabras, debemos: crear y compartir.

Son 97 los axiomas del libro, nos falta reflexionar de muchas, muchas cosas; mucho de conocer las "tripas" de las aplicaciones, mucho de toma de decisiones y de aceptación de consecuencias, mucho de qué: no debemos hacer...en fin. Esto es apenas el inicio.

Que les parece si esta semana la iniciamos con un poco de reflexión:

Una montaña cubre con su sombra una pequeña aldea. Por falta de rayos solares los niños  crecen raquíticos.
Un buen día los aldeanos ven al más anciano de ellos dirigirse hacia los límites del pueblo,
llevando una cuchara de loza en las manos..
- ¿A dónde vás? - Le preguntan.
Responde
- Voy a la montaña.
- ¿Para qué?
- Para desplazarla
- ¿Con qué?
- Con esta cuchara,
- ¡¡¡ Estas loco !!! Nunca podrás.
- No estoy loco: sé que nunca podré, pero, alguien tiene que comenzar.

Prólogo (fragmento)
Cabaret Místico. Alejandro Jodorowsky.
1a Edición.México. 2008
Ed. Grijalbo.

Que sea una buena semana para todos.

RuGI
Isaac Ruiz Guerra

Posted at 04:53PM jul 19, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[7]

[9 de 97]Aprende de los arquitectos tradicionales.

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:

"Aprende de los arquitectos tradicionales"

Keith Braithwaite. 

Keith Braithwaite es conferenciante  del XPDay que se realiza en Londres.Después de muchos años como amateur,  en 1996 entró de lleno al desarrollo de software. Actualmente mantiene su blog y conserva  el historial de sus presentaciones.

[Nota: el título original del axioma es: Learn from Architects of Buildings, pero creo que al ocupar la palabra tradición, le doy el peso/tiempo adecuado al axioma] Aquí buena parte del axioma:



“Architecture is a social act and the material theater of human activity.”—Spiro Kostof

How many software architects see their role as exclusively, or primarily technical? Is it not rather that they are the conciliators, go–betweens and arbiters of the warring factions among the stake-holders? How many approach their work in a purely intellectual spirit, without giving proper weight to the human factors of their job?

“A great architect is not made by way of a brain nearly so much as he is made by way of a cultivated, enriched heart.”—Frank Lloyd Wright

What more strongly marks out the architects in your organization: raw intellectual horsepower and vast capacity to recall technical minutia, or taste, refinement and generosity of spirit? Under which tendency would you prefer to work?

“A doctor can bury his mistakes but an architect can only advise his client to plant vines.”—ibid

Is the "maintenance" of "legacy" systems anything more than pruning those vines? Would you, as an architect, have the intestinal fortitude to scrap a piece of work that had failed? Or would you cover it up? Wright also said that the architect's best friend was the sledgehammer. What have you demolished recently?

...................

"No person who is not a great sculptor or painter can be an architect. If he is not a sculptor or painter, he can only be a builder"—John Ruskin

Does artistry play its proper part in your architecture? Is the assemblage of components to make systems informed by a painterly concern for shape and texture, with a sculptural sense of balance and implied motion, of the importance of negative space?
And finally, no gloss is required on this comment, a sure remedy for the software architect's most damaging syndrome.
"It seems a fantastic paradox, but it is nevertheless a most important truth, that no architecture can be truly noble which is not imperfect."—ibid




Al igual que Ibon,  siempre he creído(y mencionado cada que puedo; ya sea en una conferencia o en el vino de los Viernes) que esto es apenas el inicio; que, comparándonos con otras disciplinas, estamos aún en pañales... y justamente esa frase es la que guardo en mi mente de una conferencia del  Dr Adolfo Guzmán Arenas a la cual tuve la oportunidad de asistir. Era el año 2001 y dijo algo más o menos así:

"Admiro mucho  a todos los que decidan seguir estudiando y se decidan por impulsar  con esos estudios {lo que se ahora se llama} la ingeniería de software. Y los admiro por una sencilla razón: estarán abriendo camino {.....} Por si no se han dado cuenta {en muchos sentidos}nuestra área está en pañales."

Señores...este "ambiente" en que nos movemos  ¡¡¡No tiene más de 100 años !!! y eso aún tomando como referencia a la computadora Colossus construida en 1943 y no a la mítica ENIAC construida en 1947, (según datos de la wikipedia), y, si de construcción de software hablamos pues creo que apenas y llegando en safe tenemos 10 lustros o, como decimos en México: un tostón de años.

Bueno, retomando el axioma, y las citas que ahí aparecen, me pareció interesante poner un par de ellas de arquitectos con los cuales compartimos el idioma:

"No permitas que el análisis te domine." -Luis Barragán

"Me gustó siempre hablar de arquitectura como divertimento; si no se hace alegremente no es arquitectura. Esta alegría es, precisamente, la arquitectura, la satisfacción que se siente. La emoción de la arquitectura hace sonreír, da risa. La vida no." -Alejandro de la Sota.

                    Y cierro este citario con una clásica que me ha parecido suprema dado lo que hemos estado reflexionando:

"A fuerza de construir bien, se llega a buen arquitecto."-   Aristóteles.

Quizá parte de todo este interés hacia la arquitectura tiene mucho que ver con la cercanía personal que tengo con arquitectos y por el hecho que, creo,  la  arquitectura tiene mucho de filosofía y otros valores humanos con los cuales me identifico..... también es cierto que me hubiera gustado ser médico, pero bueno, esa es otra historia (por mientras cada que puedo aplico el: primun non nocere).

Gracias a esa cercanía con la arquitectura tuve la oportunidad de conocer un libro llamado: Eupalinos o el arquitecto.
El libro reproduce una interesante conversación hipotética entre Fedro y Sócrates.

Bajo el manto protector de la difusión libre del conocimiento, transcribo un fragmento que me pareció adecuado para la reflexión de este axioma:

FEDRO:
Un día, querido Sócrates, hablaba de estas mismas cosas con mi amigo Eupalinos.

-Fedro, me decía, mientras más medito sobre mi arte, más lo practico; mientras más pienso y obro, más sufro y gozo como arquitecto; me siento más yo mismo, con una voluptuosidad y una claridad siempre más ciertas.
Me pierdo en mis largas esperas;  me vuelvo a encontrar por las sorpresas que me causo a mí mismo; y por medio de estas graduaciones sucesivas de mi silencio, progreso en mi propia edificación; y me acerco a una correspondía tan exacta entre mis deseos y mis potencias, que me parece haber convertido la existencia que me fue dada, en una especie de obra humana.

A fuerza de construir, me dijo sonriendo, acabo por creer que me he construido a mí mismo.

SÓCRATES:
Construirse, conocerse a sí mismo. ¿Son éstos dos actos?

Eupalinos o el arquitecto.
Paul Valéry. 2a Edición 1991.
Facultad de Arquitectura. UNAM.

En fin, creo que está claro que no importa el camino ya avanzado, tenemos mucho por aprender.... que  sea juntos, y , de ser posible con una sonrisa:





¡¡¡ Buena semana a todos !!!

---
RuGI
Isaac Ruiz Guerra.

Posted at 11:44PM jul 12, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[16]

[8 de 97] Programar es diseñar.

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:

"La programación es un acto de diseño"

Einar Landre. 

Einar Landre es un profesional del software con 25 años de experiencia como desarrollador, arquitecto, administrador y consultor.

Aquí buena parte del axioma:


Kristen Nygaard, father of object-oriented programming and the Simula programming language, used to say: Programming is learning. Accepting the fact that programming or more precisely software development is a processes of discovery and learning and not a process of engineering and construction are fundamental to bring software practices forward. Applying the concepts of traditional engineering and construction on software development does not work. The problems have been documented and commented upon by leading software thinkers for more than 30 years. As an example, In 1987 Fredric Brooks JR stated in the "Report of the Defense Science Board Task Force on Military Software" that the document driven, specify-then-build approach lies at the heart of so many software problems.

So where should the software industry go and look for improving their practices? What about the industries involved in production of sophisticated mass-market products such as cars, pharmaceutical drugs or semiconductors?

In the article “What is software design?” Jack Reeves suggested that the only artifact of software engineering that satisfied the criteria for a design document, as such document is understood and used in classical engineering, is the source code. The manufacturing of the software is automated and taken care of by the compiler, build and test scripts.

By accepting that carving out source code is an act of design, not an act of construction we are in a position to adopt useful management practices that are proven to work. Those are the practices used to manage creative and unpredictable work such as developing a new car, a new medical drug or a new computer game. We talk about the practices of agile product management and lean production such as SCRUM. These practices focus on maximizing return-on-investment in terms of customer value.

For the software industry to capitalize on these practices we must remember: Programming is an act of design, not an act of construction.

Voy a iniciar la reflexión de este axioma listando, a manera de recordatorio,  los siguientes  principios de diseño.
Este listado esta basado en el material de estudio de la especialización: Patrones de diseño e interfaces de usuario gráficas  de la Universitat Oberta de Catalunya.

    * Bajo acoplamiento
    * Alta cohesión
    * Ley de Demeter
    * No repetición (Don´t repeat yourself)
    * Substitución de Liskov
    * Segregación de interfaces
    * Inversión de dependencias.

Cuando leí el axioma, mi primer pensamiento llegó a la lista anterior, y creo que esto refleja que:  cuando pensamos en diseño, en la mayoría de los casos evocamos los principios de diseño de software y pasamos por alto el concepto principal que incluye la oración: el diseño.

Creo que uno de los principales problemas que tenemos al momento de diseñar software es que, en nuestro afán de pasar a la codificación y sentirnos en terreno seguro, obviamos  algunas cosas.

Así que ahora, me apoyaré en la tercera acepción (de la vigésima segunda edición de la RAE) de la palabra diseño;

3.  m. Concepción original de un objeto u obra destinados a la producción en serie. Diseño gráfico, de modas, industrial

Y para terminar de llenarnos de conceptos, una definición que aparece en la página 24 de la segunda edición en español del libro "Análisis y diseño orientado a objetos con aplicaciones" de Grady Booch:

Como sugiere Stroustrup, "El propósito del diseño es  crear una estructura interna (a veces llamada  también arquitectura) clara y relativamente  simple."

Recalco pues, que según mi percepción y a riesgo de equivocarme,  buena parte de las complicaciones que tenemos para diseñar es que no logramos darle un significado profundo y amplio a la palabra.

Buscando referencias sobre este punto encontré una entrada en un blog con el título ¿Qué es diseñar?  y la reflexión del autor, creo, nos señala un poco el camino sobre lo que debemos tener en mente cuando nos topemos con esa palabra.

Diseñar es elegir, elegir es renunciar.

Podríamos complementarlo así:

Diseñar es elegir (según nuestros conocimientos y según el escenario), elegir es renunciar (a otras posibles soluciones, asumiendo que quizá no estemos ofreciendo  la solución perfecta, sino,  la más adecuada)

Diseñar pues exige algo más de lo que en ocasiones (en principio) podemos concebir.

¿No creen?

En lo que, (como decimos en México, evocando los teléfonos de moneda del siglo pasado que recibían monedas de 20 centavos, para afirmar que no hemos entendido algo), nos cae el veinte. Dejemos que Dilbert nos dé su opinión    XD







Buena semana a todos!!!

RuGI
---
Isaac Ruiz Guerra.

Posted at 05:01PM jul 06, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[12]

[8 de 97] Programar es diseñar

8 de 97] La programación es un acto de diseño.

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:

"La programación es un acto de diseño"

 

Estoy teniendo problemas técnicos para publicar este post,   espero resolverlo pronto :)

Saludos y buena semana a todos.

Pues tuve que hacer un nuevo post :S    http://weblogs.javahispano.org/rugi/entry/8_de_97

RuGI 

Posted at 10:59AM jul 06, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[1]

[7 de 97]Aprende un nuevo lenguaje

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:

"Learn a new language"

Burkhardt Hufnage. 

Burkhardt Hufnage es arquitecto de software lider en LexisNexis. Recientemente participó en el JavaOne del 2008 con el tema "building better user experiences".


To be successful as an architect, you must be able to make yourself understood by people who don’t speak your native tongue. No. I’m not suggesting you learn Esperanto or even Klingon, but you should at least speak basic Business, and Testing. And, if you aren’t fluent in Programmer, you should make that a top priority.

...
Neither group understands how the other thinks, or what half of the words they use means. This leads to mistrust and miscommunication. It’s a basic psychological principle that people are more comfortable with those who are similar to them as opposed to those who are different from them.

Imagine how the above scenario might change if the architect were able to explain the issues to the business folk in terms they understand and relay the business issues to the programmers in terms they understand. Instead of surprise and mistrust, the result would be agreement and approval.

I’m not saying that learning multiple languages will cure all your problems, but it will help prevent the miscommunications and misunderstandings that lead to problems.


Quisiera abordar la importancia de este axioma desde dos perspectivas distintas, por un lado la que comenta Burkhardt Hufnage, y por otro, algo que creo muchos hemos escuchado con respecto a la importancia de aprender un nuevo lenguaje de programación.

La ventaja de aprender un nuevo lenguaje:

• Como "facilitador" para la comunicación entre distintos "capas", reduciendo con ello el efecto "telefono descompuesto".

Haciendo un poco de memoria, y a manera de anécdota/ejemplo, recuerdo que hace varios años durante un proyecto para un canal de televisión, el usuario, ademas de darnos reflexiones existenciales interesantes, de repente nos hablaba en su "lenguaje" y esperaba que nosotros entendiéramos perfectamente lo que decía:

"Pues bueno, la parrilla de programación esta quedando bien; no se les olvide que requiero un reporte con los targets más solicitados; remarquen  ABC+CD+.

Para las agencias, quiero algo que les recuerde que: compras por CPM no aplican en PRIME TIME .  Ya la próxima semana veremos como meter la conciliación en la siguiente versión."

Los primeros meses del proyecto fueron días en los que teníamos que combinar la codificación de la aplicación con clases express de mercadotecnia! XD

Recuerdo también que en algún libro leí que "para comprender una unidad de conocimiento, primero debemos conocer su terminología básica."

Con seguridad a todos nos ha tocado un escenario similar, un escenario en dónde nos percatamos que, mientras más dominemos el "lenguaje" del cliente evitamos errores de interpretación y nos acercamos más a sus requerimientos. En ocasiones el vocabulario es tan complejo que tenemos que reconocer que requerimos de un interprete para lograr ese entendimiento y es cuando, nos gustaría poder hablar directamente con ellos. Ahora mismo me ha tocado tener que quedarme callado en un par de reuniones para iniciar un proyecto cuyo vocabulario es un poco complejo.

• Como "agente incentivador" para crear escenarios favorables o elementos de respuesta para resolver algún problema.

Para comentar esta acepción del axioma que ahora consumimos, debo evocar un hilo abierto por Vekman en debug_mode=on:
¡Aprende un nuevo lenguaje! ¡Ahora!.

En ese hilo, Vekman nos comparte la Hipótesis de Sapir-Whorf (grosso modo: el lenguaje determina la forma en que pensamos.) y le da más valor teórico a esto que hemos escuchado ya varias veces: debemos aprender un nuevo lenguaje(de programación) cada cierto tiempo para incrementar el número de paradigmas en nuestras mentes y con ello poder resolver mejor los problemas.
(Si quieres algunas ideas de que lenguajes podrías aprender te puede interesar este otro hilo.)

Algo de lo que me he dado cuenta en todos estos años es que, realmente el axioma va más allá de sólo conocer el lenguaje del cliente o incrementar nuestra caja de herramientas laboral, en ocasiones conocer cualquier otro lenguaje, puede llegar a ser de mucha utilidad, no sé, uno nunca sabe y quizá algún día nos toque en un proyecto lidiar con alguien que entiende perfectamente  élfico o incluso (mi sueño se haga realidad) y conozcamos a alguien que hable  sánscrito.

Bueno, la reflexión final es que, nunca esta demás aprender un  nuevo lenguaje (en el sentido amplio de la palabra); así seguramente veremos utilidad a artilugios tan raros como estos:

O al menos entenderemos más chistes:

¿Alguna anécdota o comentario que quieras compartir?  ;)

Saludos!!!
---
RuGI
Isaac Ruiz Guerra.

Posted at 05:41AM jun 28, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[14]

[6 de 97]. Patronitis

Seguimos con los axiomas del libro: 97 things Every Software Architech Should Know
El axioma de hoy dice:

"Pattern Pathology"

Chad LaVigne. 

Chad LaVigne, es un arquitecto que trabaja en TEKSystems, Inc, participa activamente en la comunidad openSource y dirige un JUG en las oficinas de su compañía.

Aquí  el axioma casi completo:


Design patterns are one of the most valuable tools available to the software architect.  Using patterns allows us to create common solutions that are easier to communicate and understand.  They are concepts that are directly associated with good design.  This fact can make it very enticing to demonstrate our architectural prowess by throwing a lot of patterns at a project.  If you find yourself trying to shoehorn your favorite patterns into a problem space where they don’t apply, you may be a victim of pattern pathology.

Many projects suffer from this condition.  These are the projects where you envision the original architect looking up from the last page in his patterns book, rubbing his hands together and saying “Now, which one will I use first!?”.  This mentality is somewhat akin to that of a developer who begins writing a class with the thought “hmmm, what class should I extend?”.  Design patterns are excellent tools for mitigating necessary complexity but like all tools, they can be misused.  Design patterns become a problem when we make them the proverbial hammer with which we must strike every nail.  Be careful that your appreciation for patterns doesn’t become an infatuation that has you introducing solutions that are more complicated than they need to be.

Don’t let your desire to exhibit design pattern knowledge cloud your pragmatic vision.  Keep your sights focused on designing systems that provide effective business solutions and use patterns to solve the problems they address.



Sigo pensando que los patrones de diseño son el primer, o uno de los primeros pasos, para hacer más "exacto" el desarrollo de sistemas informáticos. Lograr , por fin,  transmitir experiencia de una manera mucho más formal y sistemática, han provocado que exista evolución en esta área {para bien de los que nos dedicamos a esto}.

Creo que el axioma anterior se resume en la frase: "No permitas que tu deseo de exhibir tus conocimientos sobre patrones de diseño nuble tu visión práctica."

Esa frase me hizo recordar mucho un famoso artículo que salio en el Java Developer Journal por allá del 2003: ¿Are You Using Abstract Classes, Polymorphism, and Interfaces?, el artículo iniciaba diciendo:
"Si la respuesta es no, tu proyecto necesita mínimamente una revisión de código" (muy recomendable si estas iniciando con algún lenguaje orientado a objetos). Recuerdo que cuando lo leí  inicie una cacería de brujas a mi código y comencé a crear interfaces  y clases abstractas a diestra y siniestra, tiempo después vi que realmente muchas cosas estaban de más (a manera de defensa, al menos me sirvió para comenzar a distinguir cuando elegir una y cuando otra).... ejemplo de exceso.

También recuerdo, y confieso,  que cuando escuche por primera vez  sobre el patrón: Multitón,  lo primero que dije fue: " mmm, cuantas ganas de querer hacer de todo  un patrón".

Decidí hacer esos dos comentarios para mostrar un poco los dos extremos que Chad LaVigne nos trata de advertir: exagerar el uso de ellos o  menospreciarlos.

Según mi perspectiva, parte del problema es que, comparativamente hablando  la arquitectura de software  y los patrones de diseño son conceptos que aún no llegan a un punto estable siquiera en su definición

Fue en  1994 cuando salio el mítico libro: Design Patterns: Elements of Reusable Object-Oriented Software del, más mítico aún, GoF, y ni bien habían pasado 4 años aparece el menos mítico libro: AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis de William J. Brown. Entonces, tratar de llegar a acuerdos y convenciones universales en un tema que no deja de moverse, hace que las cosas se compliquen un poco.

Creo que a lo largo de los axiomas que estamos reflexionando juntos, el común denominador será saber ... ¿Hasta cuándo?, ¿Hasta dónde? ¿Que tanto más?.... esa sensibilidad es la que se adquiere con la experiencia, y, para bien o para mal, la manera más común para adquirir experiencia es con vivencias, y las vivencias transcurren en el tiempo.. luego entonces, nos sensibilizaremos con el tiempo ;)

Martin  tiene claro lo que intento advertir en su artículo: El peligro de los patrones de diseño,  con la frase: "Hay que saber resistirse a la euforia".

Debemos alcanzar una especie de nivel reflexivo que nos permita no caer en estados de euforia o de "autocomplacencia", evitar el , como decimos aquí en México para justificar que no logramos mesurarnos  adecuadamente en algo: "¡¡¡ Total !!!,.. ¿Qué tanto es tantito?"

Quisiera concluir la reflexión de este axioma con un fragmento de texto que reproduce lo que Eduardo Punset menciona en la entrada de su blog:

"Dar {lugar}a la emoción que uno siente cuando esta realizando lo que le gusta no debería de interferir con lo que llaman los procesos cognitivos de funciones ejecutivas, es decir {emocionarse},  no debería interferir con la pericia, con la habilidad {de hacer bien las cosas}"

Blog de Eduardo punset.
"Es preciso emocionarse, pero no tanto."

Y, por supuesto.... iniciemos la semana con una sonrisa :)
Perdón por no traducir, pero, me parece, se entiende mejor en su idioma original... y, no me gustaría evocar el famoso proverbio italiano: «Traduttore, traditore»

Design Patterns: A Love Story Richard tilted his head to watch the waves push flotsam against the boat hull below. Up and down, the flotsam moved. Up and down. Richard had an idea. “Virginia, my dear”, he said to the blond woman beside him. “We’ve been singletons on this ship for a long time”. “I know, Richard”, she replied. “My mean step-mother, the intercepting filter that she is, denies me time with others.” Richard paused for a moment, to contemplate strategy. Her father, with his pipes and filters, would return soon, and force them to communicate over his message bus. He glanced aft, and saw no one else around. Richard turned his front controller to face Virginia, and looked her in the eyes. She was close now, and Richard could feel his active record rising. “Virginia”, he whispered. “There is no observer in sight. Let us run below deck. I want to peel away your façade, and tightly couple.” “Oh yes, Richard”, she blushed, and leaned towards him. “I want you to give me a dependency injection”. [Author’s note: I’m sorry. I can’t continue. Shortly after typing the words “give me a dependency injection”, I was overcome by a sudden sickness and fell to the floor in convulsions. Let’s just assume the story has a happy ending, and forget this post ever happened. OK?]

Tomado de: http://odetocode.com/Blogs/scott/archive/2005/11/22/2499.aspx

Saludos a todos!!

----
RuGI
Isaac Ruiz Guerra.

Posted at 08:31PM jun 21, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[5]

[5 de 97] Integrar Continuamente.

El axioma de hoy, aparece en la página 40 del libro 97 things Every Software Architech Should Know , y dice:

"Continuously Integrate"

David Bartlett. 

David Bartlett es un entusiasta del software con más de 25 años de experiencia como programador, promotor, arquitecto, gerente, consultor e instructor.
Actualmente trabaja para clientes a través de Commotion Technologies, Inc., tiene un Master en Ingeniería en Diseño de Software y un MBA de la Universidad Estatal de Pennsylvania.
Vive con su familia en Berwyn, Pensilvania, EE.UU.




The build as a "big bang" event in project development is dead. The architect, whether an application or enterprise architect, should promote and encourage the use of continuous integration methods and tools for every project.

The term Continuous Integration (CI) was first coined by Martin Fowler in a design pattern. CI refers to a set practices and tools that ensure automatic builds and testing of an application at frequent intervals, usually on an integration server specifically configured for these tasks. The convergence of unit testing practices and tools in conjunction with automated build tools makes CI a must for any software project today.

The most prominent part of a CI implementation is the build which is usually automated. You have the ability to do a manual build but they can also be kicked off nightly or can be triggered by source code changes. Once the build is started the latest version of the source code is pulled from the repository and the CI tools attempts to build the project then test it. Lastly, notification is sent out detailing the results of the build process. These notifications can be sent in various forms including email or instant messages.

Continuous Integration will provide a more stable and directed development effort. As an architect you will love it but more importantly your organization and your development teams will be more effective and efficient.

Creo que  a estas alturas ya no está en discusión si debemos o no implementar un mecanismo de integración continua en nuestro desarrollo, creo qué lo que debe estar a discusión es "cuándo y de que manera( y que herramientas utilizar)".

¿Cuando? mmmm, creo que si estamos por iniciar un desarrollo debemos considerar seriamente agregarlo desde el inicio, y aún cuando no estemos dispuestos a utilizar una metodología ágil al 100%, muy probablemente aún así nos será útil. 
Si ya tenemos un desarrollo iniciado, quizá la mejor estrategia es ir agregando de manera gradual y discreta el servidor/mecanismo de integración continua hasta que consideremos que el equipo de desarrollo esta listo para recibir la noticia ;)

¿Que herramientas utilizar?
Bueno, para este punto, recomiendo ampliamente una serie de post's de Félix García Borrego:

Eligiendo nuestro entorno de Integración Continua (I).

Apache Continuum. Eligiendo nuestro entorno de Integración Continua (II).

LuntBuild. Eligiendo nuestro entorno de Integración Continua (III).

Hudson. Eligiendo nuestro entorno de Integración Continua (IV).

Conclusiones finales. Eligiendo nuestro entorno de Integración Continua (V).

Quisiera argumentar el porqué, cuando se intenta agregar Integración Continua a un desarrollo ya iniciado, debemos hacerlo de una manera "discrecional".

En primer lugar, y es algo que todos hemos vivido en carne propia; si de por sí llevar un desarrollo a buen puerto es una tarea compleja,  el asunto se puede complicar más si pretendemos hacer que el equipo de desarrollo se líe ahora con un factor adicional de cambio; cualquier hábito es menos doloroso de adquirir si se hace gradualmente, además puede servir para calibrar a todo el equipo y saber que tanto costará después adoptar por completo una metodología ágil.

Y, hay mucho material para intentar entender como manejamos, administramos y nos resistimos al cambio en nuestras mentes,  pero, adicionalmente al cambio, creo que Martín en su post: Integración continua y avergonzamiento público  le dio al clavo a otra razón que evita la adopción de esta buena práctica.

El sólo saber que algo puede poner en evidencia que hemos hecho algo mal, muy seguramente dada nuestra naturaleza,  hará que evitemos ese algo.
Y es que, <comentario_paranoide> a veces pareciera que las prácticas de algunas metodologías se empeñan en violentar la intimidad del desarrollador</comentario_paranoide>, pero, parafraseando a Martín: a mediano y largo plazo se vuelven evidentes los beneficios obtenidos de esta práctica y se demuestra con hechos que; la tranquilidad de todo el equipo puede compensar una "incomodidad" (seguramente temporal) de algunos padawan's.

Si por alguna razón en la práctica no es posible agregar un servidor de integración continua en nuestro desarrollo, existe una técnica manual que puede ayudar mucho:
 Cada cierto tiempo, semanalmente por ejemplo, debemos descargar todo el código de nuestro proyecto desde el repositorio hacia una PC "limpia" y debemos  verificar que se puede generar el último distribuible (jar,war,ear) sin problemas.... {si no hay repositorio de código entonces, creo que alguien debe agregar un item más a su matriz de riesgo. ;P}

Para concluir esta entrada, me gustaría recomendar el podcast número 45 de javaHispano, en él se hace una entrevista a Jose Manuel Beas, Xavier Quesada, Xavi Albaladejo quienes se encuentran detrás de la comunidad http://www.agile-spain.com/ ,dentro de la entrevista, además de darnos un panorama general de las metodologías ágiles, hacen valiosos comentarios sobre la integración continua.

En fin, más allá de los dolores de cabeza que pueden generar introducir nuevas prácticas, tratemos de aprender siempre con una sonrisa  ;)



Saludos a todos!!

RuGI
Isaac Ruiz Guerra.

Posted at 08:02PM jun 14, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[10]

[4 de 97]. Lo Perfecto es enemigo de lo suficiente.

El axioma de hoy dice:

"Perfect" is the Enemy of "Good Enough"

Greg Nyberg. 

Greg Nyberg es actualmente un consultor independiente de JEE con 18 años de experiencia diseñando, construyendo, probando y poniendo en producción aplicaciones transaccionales de grandes volúmenes. Es el autor principal del libro: Mastering WebLogic Server (Wiley).

Siendo estrictos y en honor a la verdad, la frase completa es: "La perfección es enemigo de lo suficientemente bueno" y se le atribuye por igual a Voltaire y a Leonardo Da Vinci.

Aquí un breve resumen (tomado del libro 97 things Every Software Architech Should Know ):

Software designers, and architects in particular, tend to evaluate solutions by how elegant and optimum they are for a given problem. Like judges at a beauty contest, we look at a design or implementation and immediately see minor flaws or warts that could be eliminated with just a few more changes or re-factoring iterations.  Domain models simply beg for one more pass to see if there are any common attributes or functions that can be moved into base classes. Services duplicated in multiple implementations cry out their need to become web services. Queries complain about "buffer gets" and non-unique indexes and demand attention.

My advice: Don't give in to the temptation to make your design, or your implementation, perfect! Aim for "good enough" and stop when you've achieved it.

Remember that application development is not a beauty contest, so stop looking for flaws and wasting time chasing perfection.

Pensaba como iniciar los comentarios de este axioma cuando recorde que en el podcast 33 de javaHispano; durante la entrevista con Eduardo Pelegri (encargado de Glassfish), mientras comentaba sobre la  especificación inicial de los JSP's se le preguntó qué opinaba de esa especificación y como habían llegado a ella:

Y aquí una transcripción de sus palabras.

"Una especificación que sea técnicamente perfecta pero que no tenga  soporte en la industria es inútil.
{...}
Hay que conseguir una especificación que sea técnicamente válida {...}
No es cuestión de que todos digan: 'esta es la mejor especificación que yo podía hacer' sino:
Esta es la mejor especificación que todos hemos podido hacer conjuntamente".
Entrevista a Eduardo Pelegri por Abraham Otero (10:12min)

Me imagino a varios gurús reunidos tratando de llegar a un acuerdo sobre como debía ser la especificación (mi mente geek los visualiza como una reunión de Ent's), y, me imagino a todos tratando de lograr que la especificación llevara lo mejor de sus propuestas; me imagino también lo difícil que debió llegar a un acuerdo en donde, muy probablemente más de uno tuvo que doblegar a su ego para permitir que las propuestas de otros tuvieran cabida.

Si cada uno de ellos se hubiera aferrado a sus ideal de perfección muy probablemente, la especificación hubiera tardado más tiempo en salir y quizá la historia seria otra.

Creo que a estas alturas, todos estamos conscientes de lo que el axioma advierte: no es adecuado aferrarnos y enajenarnos en conseguir una aplicación o un fragmento de código perfecto y esa búsqueda de perfección nos lleve a perder el tiempo y/o dejar de ocupar ese tiempo en cosas que pudieran  darle más valor a nuestra aplicación.

Veamos otro ejemplo:
Recordemos  que cuando se comentó el caso LinkedIn en jH, salio al tema el uso de JDBC "a pelo", y mientras algunos criticaban la técnica duramente otros la defendían argumentando que el desempeño, en aplicaciones muy grandes, mejoraba considerablemente, también se comentaban cosas como que ya no existía estrictamente hablando una integridad referencial .... No ORM, no integridad referencial ¡¡¡ blasfemia !!! XD

Imaginemos ahora, que hubiera pasado si el arquitecto en jefe de LinkedIn no hubiera tenido la sensibilidad de reconocer que esa técnica era ya suficientemente buena.

Y antes de perderme con los ejemplos creo útil retomar una pregunta que se plantea en el axioma ( y a manera del addendum que comentaba ibon):
¿Hasta cuanto o hasta cuando es suficiente? ¿Cómo saber que ya tenemos lo suficiente?¿Hasta que punto debemos detener esa búsqueda de perfección?
Creo que el principal indicador, y ya lo mencionábamos anteriormente; es el tiempo invertido en la búsqueda de esa perfección.

Si ese tiempo que invertimos en buscar, refactorizar y "maquillar" nuestro código buscando la perfección supera al tiempo necesario para:

• Agregar una nueva funcionalidad a nuestra aplicación.
• Corregir errores de alto impacto.
• Atender nuevos requerimientos.
• Atender requerimientos aún pendientes.
• Corregir errores graves detectados por herramientas como PMD o FingBugs.
  

Es hora de detenernos y aceptar que le hemos dado una solución suficientemente buena al requerimiento que cubre el código.

Me quedo con la última frase de G. Nyberg:

"Recuerda que el desarrollo de aplicaciones no es un concurso de belleza, por lo que deja de mirar los defectos y perder el tiempo persiguiendo la perfección."

A fin de cuentas, nunca daremos satisfacción a todos.... ¿o sí?  ;)



Saludos!!!
---
RuGI

Isaac Ruiz Guerra.

Posted at 08:12PM jun 07, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[4]

[3 de 97]. Controla los datos, no sólo el código.

El axioma de hoy dice:
Control de data, no just de code.
Chad LaVigne

Chad LaVigne, es un arquitecto que trabaja en TEKSystems, Inc, participa activamente en la comunidad openSource y dirige un JUG en las oficinas de su compañía.

  Aquí las partes que considero mas relevantes del axioma (tomado del libro 97 things Every Software Architech Should Know ):

Control de data, no just de code.
Source code control and continuous integration are excellent tools for managing the application build and deployment process.  Along with source code, schema and data changes are often a significant part of this process and thus warrant similar controls.  If your build and deployment process includes a list of elaborate steps required for data updates, beware.

  ....

Database changes shouldn’t create a ripple in your build’s time-space continuum.  You need to be able to build the entire application, including the database, as one unit.  Make data and schema management a seamless part of your automated build and testing process early on and include an undo button; it will pay large dividends.  At best it will save hours of painful, high-stress problem solving after a late night blunder. At worst it will give your team the ability to confidently charge forward with refactoring of the data access layer.

Creo que la culpa de que antaño no le dábamos tanta importancia a todo lo que tiene que ver con scripts de base de datos es que, era una tarea, en el mejor de los casos tediosa, y en el peor algo muy complejo de explicar a los clientes



Pero conforme vamos participando en proyectos nos vamos dando cuenta que, buena parte del éxito de nuestra aplicación esta en función de qué tan bien este diseñada y mantenida por los DBA's.

Y conforme han evolucionado las metodologías y técnicas para el desarrollo e integración de aplicaciones y con el advenimiento de los métodos ágiles, creo que ha llegado la hora de incluir a las bases de datos su merecido  lugar en la foto.

Una de mis peores pesadillas siempre ha sido realizar un update a una tabla de configuración para alterar un registro y cuando hago el commit me doy cuenta que he pasado por alto la sentencia WHERE..... ¡¡¡ Una catástrofe!!!; Afortunadamente el tener scripts de poblado inicial (¿es correcto llamarlo así?)  de dichas tablas siempre te da la tranquilidad de saber que puedes regresar a un "estado correcto" {ocupando un poco terminología de greeneyed-ista  ;)}

Y no sólo se requieren scripts de poblado inicial, por supuesto requerimos los de:

• Creación/Eliminación de tablas
• Creación/Eliminación de procedimientos almacenados (Stores procedures).
• Creación/Eliminación de disparadores(triggers).
• Creación/Eliminación de secuencias
• etc,etc
  

Y hay un tipo de script que a veces dejamos en el olvido; y sí, si has esbozado una maquiavelista sonrisa ya sabes a que  me refiero: los scripts de respaldo para migrar a otros ambientes.
Si aun no te ha tocado estar en un conferencia telefónica en donde todo el mundo esta al borde de la histeria pues no saben que es lo que ha faltado(y hace inoperable el ambiente) de migrar en la nueva y reluciente base de datos recién adquirida (por muchos miles de $), entonces, ten a la mano la siguiente pregunta, toma aire y con humilde autoridad dí:

Hombre ¿No será que se les ha pasado migrar los stores y los triggers?

Si la estadística no falla, toda la línea de mando del DBA guardará silencio y el gerente en turno dirá:

Bueno, revisaremos eso y luego te llamamos.

Esa llamada nunca llega ;)

Pero bueno, regresando al punto inicial,  en estos tiempo en que requerimos ser más que ágiles, es buena idea considerar agregar este tipo de estrategias para tener un poco más de control sobre nuestros desarrollos y permitir, por fin, crear un ambiente de desarrollo más sano y menos estresante.

A todo esto, sólo me queda preguntar:

¿Has tomado en cuenta los scripts de datos para ofrecer una solución integral en tus aplicaciones?

Saludos!!
---
RuGI

Isaac Ruiz Guerra.

Posted at 09:26PM may 31, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[6]

[2 de 97]. Comienza con un esqueleto funcional.

Siguiendo con los comentarios sobre el libro:
97 things Every Software Architech Should Know

El axioma de hoy:

Start with a walking skeleton.
Clint Shank


Clint Shank, es un desarrollador de software y mentor de Sphere of Influence, Inc. una empresa de diseño e ingeniería de servicios.

Aquí un fragmento de su axioma:

Start with a walking skeleton.

One very useful strategy for implementing, verifying, and evolving an application architecture is to start with what Alistair Cockburn calls a Walking Skeleton .  A Walking Skeleton is a minimal, end-to-end implementation of the system that links together all the main architectural components.  Starting small, with a working system exercising all the communication paths, gives you confidence that you are heading in the right direction.

Once the skeleton is in place, it's time to put it on a workout program. Bulk it up with full body workouts.  This means implement incrementally, adding end-to-end functionality.  The goal is to keep the system running, all the while growing the skeleton.

Para mi es una las estrategias favoritas para atacar una integración muy compleja o con un equipo mediano/grande de desarrolladores.
Coincido completamente con el comentario de Clint Shank, en desarrollos pequeños, una sola persona puede realizar todo a su modo y no requiere de este tipo de estrategias.

La idea es sencilla, se debe lograr tener un esqueleto funcional, de extremo a extremo, de la integración que va a realizar.
El objetivo también es sencillo; verificar que ese camino de extremo a extremo sea eficiente ( y descubrir a tiempo las implicaciones que puede tener construirlo/fortalecerlo/modificarlo).

La utilización de objetos y servicios  mock pueden ayudarnos bastante con esta estrategia de implementación. Imaginemos un escenario hipotético (y muy común) en donde debemos realizar la integración de varios sistemas que incluyen unos servicios de muy bajo nivel  (que aun no se han creado), pasando por una transformación de datos(no del todo definida), seguida de un traducción(un poco difusa)  y finalizando con una visualización(aun en diseño).

Nuestro esqueleto haría uso de objetos mock para:

1. Simular la llamada a los servicios de más bajo nivel.
2. Simular la transformación de datos, recibiendo la salida del paso anterior como entrada a este paso.
3. La traducción recibe unos datos válidos pero arbitrarios y devuelve el formato esperado por la capa superior.
4. El componente de visualización únicamente se encarga de visualizar lo que recibe del paso anterior.

Y nuestro esqueleto esta completo.
  A partir de él podemos ir creciendo y fortaleciendo nuestra aplicación sin afectar de manera significativa las capaz superiores, la construcción del esqueleto como mencionaba, nos dan la luz suficiente para saber el costo de modificar alguno de los puntos de conexión (firmas) de cada "hueso" del esqueleto..... y, conocer el costo (no siempre cabe aclarar)  incentiva a  definir puntos de conexión mucho más "desacoplados".

¿Y ustedes? ¿Con cuantos esqueletos se han topado? 
Sólo cuentan los que vemos al inicio del desarrollo,  los que vemos al finalizar el proyecto no cuentan (es más ¡¡¡ Ni los mencionen !!!)

 ;)

Saludos!!
---
RuGI
Isaac Ruiz Guerra.

Posted at 03:20PM may 24, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[3]