Non nobis Domine...
Isaac Ruiz Guerra's Weblog
- Todo
- Internet
- Politica
- frases
- ruby
- ESB
- Libros
- SOA
- Haskell
- Urbi
- 97things
- Humor
- General
- Justicia Social
- Cine
- Java
- TecNo
[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.
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".
"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+.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
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."
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.
¡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[13]
[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:
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.
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.
"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)
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.
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
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:
Para mi es una las estrategias favoritas para atacar una integración muy compleja o con un equipo mediano/grande de desarrolladores.
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.
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:
- Simular la llamada a los servicios de más bajo nivel.
- Simular la transformación de datos, recibiendo la salida del paso anterior como entrada a este paso.
- La traducción recibe unos datos válidos pero arbitrarios y devuelve el formato esperado por la capa superior.
- 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]
[1 de 97]. Para el usuario final, la IU es el sistema.
Cito textualmente:
"For the end user, the interface is the system"
Vinayak Hedge
Esta es la frase con la que Vinayak Hedge participa en el libro:
97 things Every Software Architech Should Know publicado, por supuesto, por O'Reilly
Es una frase que creo todos tenemos ya claro, pero de vez en vez se nos olvida, o de menos, le restamos importancia.
El comentario de Vinayak resalta mucho lo relevante que puede ser lograr una IU altamente funcional, que permita una buena interacción y tenga la suficiente "usabilidad" como para que la IU refleje la totalidad del producto de software.
Y esta frase, tambien, encaja perfectamente en el desarrollo y liberación del sistema en cual participo actualmente.
Al usuario final no le importa si debajo de esa IU estas realizando:
- Transformaciones de excepciones
- Traducciones de mensajes
- Invocaciones a WS's...
Tampoco le importa si estamos
- Apilando mensajes JMS,
- Ejecutando sistemas legacy,
- Gestionando la seguridad
No, a el sólo le importa que su comboBox tenga los valores que espera y que el mensaje de respuesta traiga una descripción que él pueda entender. XD
Y la verdad, no tiene porqué importarle :)
El hacer que todo esto sea transparente para el usuario final creo es una de las mayores satisfacciones que podemos llegar a tener.... pero, debo reconocer que a veces sí que dan ganas de escupxxxx decirle amablemente que debería tomar en cuenta la complejidad de un proceso para reconsiderar sus comentarios poco sensibles a nuestro trabajo.
Todo esto me recuerda un comentario repetitivo de uno de mis maestros durante mis estudios de ingeniería
(la verdad a estas alturas no puedo más que agradecer todo lo que me enseñaron o me dejaron de enseñar, esa singular combinación de omisiones y presencias ha tenido curiosos efectos secundarios en mi desempeño profesional)
Decía:
"Jóvenes, para evaluar la tarea yo parto del hecho de que todos me entregarán algo que cumpla lo que pedí,
si quieren aumentar su calificación... hagan que se vea bonito"
A veces se nos olvida que el entregable es TODO lo que compone la aplicación, a veces nos preocupamos por lo que consideramos "mas importante" durante el desarrollo de un producto de software e incluso en esos casos pasamos por alto muchas cosas, lo interesante de esta frase es que, al menos a mí, me recuerda que no debemos perder detalle de nada..... el diablo esta en los detalles dicen por ahí.
¿No creen?
Saludos!!!
---
RuGI
Isaac Ruiz Guerra.
Posted at 09:29AM may 10, 2009 by Isaac Ruiz Guerra in Java | Comentarios[2]
Oracle Service Bus 10gR3 en Ubuntu 9.04
Recien publicado en debugmode on.
Instalación del Oracle Service Bus 10gR3 en Ubuntu 9.04
Saludos!!!
Posted at 03:29PM may 02, 2009 by Isaac Ruiz Guerra in ESB | Comentarios[0]
jH Podcast 039. Dudas del foro Abril
Pues, se ha publicado un nuevo podcast sobre las dudas del foro.
Aquí los temas que tocamos en esta ocasión:
- Tips JDeveloper
- File en una aplicacion JEE
- cambiar mi URL
- Mostrar etiqueta en control propio con NetBeans
- Configuracion hibernate
- Problemas con las transacciones en JDBC
- JavaCup: Version estable del framework
Espero les resulte interesante.
La noticia completa en javaHispano:
Saludos!!!
RuGI
Isaac Ruiz Guerra.
Posted at 01:14PM abr 19, 2009 by Isaac Ruiz Guerra in General | Comentarios[2]
Breve Screencast con NetBeans. Crear componente.
Hace unos días descargue la versión de prueba de Camtasia Studio., tenía ya ganas de grabar algo y antes de que se termine el periodo de prueba decidí probar con un breve screencast para resolver una duda que apareció en el foro de IDE's en javaHispano.
La duda concretamente era:
He creado un control propio que sólo tiene un JLabel y un JTextArea. Lo estoy utilizando en varios formularios y no tengo problemas con él. Lo que quiero hacer es lo siguiente: me gustaría que en la vista Diseño de NetBeans me aparezcan los formularios con mi control y que el JLabel tenga el Text que le he asignado
Así que, Alfredo, espero que aún te sea de utilidad:
NetBeans 6.5. Creación de componente Swing agregandolo a la paleta de control. from Isaac Ruiz Guerra on Vimeo.
Saludos !!!
RuGI
Posted at 10:14PM abr 12, 2009 by Isaac Ruiz Guerra in Java | Comentarios[3]
REST para desarrolladores Java.
Hoy por la mañana revisando JavaWorld me encuentro con una serie de artículos por demás interesantes.
Es una serie sobre REST.
Y de momento incluye los siguientes:
- Part 1: The REST architectural style
- Part 2: The Restlet API
- Part 3: NetKernel
- Part 4: The future is RESTful
Espero les sea de utilidad.
Saludos!!
---
RuGI
Posted at 01:24AM abr 06, 2009 by Isaac Ruiz Guerra in Java | Comentarios[0]
Paranoia fan...
Sí, soy un paranoide :)
Buen día a todos!!
:D
Posted at 11:58PM abr 04, 2009 by Isaac Ruiz Guerra in Java |
jH Podcast 039. Dudas del foro
<culto_al_ombligo>
Pues, ya esta una nueva entrega de "las dudas del foro".
En esta ocasión junto con Ruben Egiluz platicamos de:
- Comenzar con JEE
- Diferencia entre Facade y proxy
- Procesamiento autmático de anotaciones personalizadas
- FEEDS RSS
- Cerrar Sesion al Cerrar Ventana Navegador
Esperamos le sea de utilidad a alguien :)
</culto_al_ombligo>
Saludos!!
RuGI
Isaac Ruiz Guerra.
Posted at 05:36PM mar 16, 2009 by Isaac Ruiz Guerra in Java |
ESB sin palabras
[Sin palabras]
:)
Tomado del libro :
Enterprise Service Bus by David Chappell
Posted at 12:23PM feb 23, 2009 by Isaac Ruiz Guerra in ESB |
MX. Buscando blogs.
Dentro de las iniciativas de la comunidad java méxico, nos gustaría tener referencias de blog's mexicanos, así que; sí escribes desde dentro de las fronteras de los , nombre oficial, Estados Unidos Méxicanos (o sabes quien es el tri, comes tamales y sabes porqué el 2 de Febrero es dia de descanso), entonces, te agradeceré te pongas en contanto.
Saludos y, que sea un buen 14 de Febrero para todos.
:)
Posted at 09:35AM feb 14, 2009 by Isaac Ruiz Guerra in Java |
Comentando dudas del foro III.
Pues, se ha publicado un nuevo número del podcast de JH. En esta ocasión me ha tocado participar :)
En el podcast comentamos algunas preguntas que aparecen en los foros de jH.
JavaHispano Podcast - 033 - Dudas del foro Febrero (a)
Los hilos que comentamos son los siguientes:
- Crear PDF's con Java
- Id del procesador
- pasar un array bidimensiona a una funcion javascript
- Aplicacion Java y Barra de Tareas(systray)
- Diferencia entre proyectos MyFaces Trinidad, Tobago y Tomaha ...
- JSP DISPLAYTAGS
Espero le sea de utilidad a alguien :)
Saludos...
---
RuGI
Isaac Ruiz Guerra.
Posted at 12:40PM feb 02, 2009 by Isaac Ruiz Guerra in Java |
[debugModeOn]Algo de Haskell
Acabo de publicar un HelloWorld con Haskell en debugmodeon.
Saludos!!!
Posted at 12:18AM ene 27, 2009 by Isaac Ruiz Guerra in Haskell |
MX.Comunidad java.1a del 2009
[10:35 AM]
Estoy en el 4to. encuentro de la comunidad de SpringHispano.org en conjunto con la comunidad de Java México.
El plan del día es el siguiente:
- Sistema de Control de Versiones Distribuidos
- Bazaar por Julio Carlos Sanchez Ortega (Twitter: @thegeekinside) http://www.thegeekinside.net
- Git por Sergio Acosta (Twitter: @scasware) http://stonefreesoftware.com/blog/
- Struts2 por Marco Antonio Muñiz Ochoa (SH: MarkoTona) http://www.linkedin.com/in/marcomuniz
Al finalizar.... la idea es platicar un poco entre todos para hacer comunidad. :D
Ya les estaré contando :)
RuGI
[Update 10:58am] Arrancamos!!!
[Update 11:40]
Julio Carlos Sanchez Ortega (aka @thegeekinside) inicio platicandonos de Bazaar.
Aprendimos que existen varias herramientas distribuidas para el control de vesiones: Bazaar, Git, Darcs ,Git, Mercurial, Monotone.
Ya hablando sobre Bazaar, aprendimos que:
"Es amigable, inteligente, Rápido, Ligero (sacrifica desempeño por usabilidad). Lo cubre el manto de Canonical."
También aprendimos queiene distintas maneras de utilizarlo (Worflows) solo, partner, centralizado, centralizado con commits locales, descentralizado con mainline compartido, desentralizado con revisión humana, desentralizado con revision automatico.
Concluimos esta parte con una demostración de su uso.
[Update 12:00]
Seguimos con GIT con Segio Acosta.
Links interesantes: http://www.gitcasts.com/
Sergio detalla la manera en que GIT guarda la "referencia" de cada archivo.... es una locura!!! XD
Conclusión: Debo aumentar y mejorar mis conocimientos en matemáticas :P
[02:00 PM] break;
[02:55 PM] Toca a Struts 2 con Marco Antonio.
Posted at 10:52AM ene 24, 2009 by Isaac Ruiz Guerra in Java |
Eufemismos de RuGI I
Pues inagurando mi cuenta en http://www.scribd.com.
Espero que al leerlo se diviertan tanto como yo al escribirlo ;)
Eufemismos de RuGI Ver0.8
Saludos!!
RuGI
Isaac Ruiz Guerra.
Posted at 10:51PM ene 14, 2009 by Isaac Ruiz Guerra in Humor | Comentarios[3]
La ultima del 2008.
Pues, a finales de este año logré integrarme a la comunidad oracle hispana., y además de utilizar este post para invitarlos a integrarse, les comparto un par de post que me han permitido escribir ahi:
Como decimos aquí en México: "La última y nos vamos....."
Adiós 2008, ¡¡¡bienvenido 2009!!!
RuGI
Isaac Ruiz Guerra.
Posted at 10:30AM dic 31, 2008 by Isaac Ruiz Guerra in SOA |
