[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]