Categoría: Arquitectura & DevSecOps

Hace unos meses empecé un proyecto personal para ir introduciéndome en el mundo del BigData/NoSQL y la nube.

Era una Prueba de Concepto (PoC) con intenciones de ver la viabilidad de la idea.

Lo hice con un planteamiento muy Google, es decir, la nube de Google y los frameworks de Google, con el GWT a la cabeza.

Pero últimamente estoy planteándome otros escenarios no tan «radicales» y que sean un poco más una evolución de los planteamientos ya conocidos. Sigo creyendo en que hay que seguir a los mejores pero también sin pasarse de frenada. Aunque me gusta mucho el planteamiento del GWT, no se que le veo, quizá un poco complejo de entender, sobre todo con el soporte de los históricos y las diferentes vistas.

Existe otro planteamiento, que en vez de ir a un modelo de componentes como GWT o JSF utiliza el planteamiento más tradicional del MVC, estilo Struts, vitaminado en la parte de presentación con librerías como jQuery o AngularJS.

La parte MVC es más conocida y el planteamiento de AngularJS me parece muy interesante como para hacer una prueba de concepto.

Además creo que es labor de un buen arquitecto plantear una solución acorde al problema, y no tanto dejarse llevar por modas o fanatismos tecnológicos.

Sigo con mi cruzada anti interfaces en proyectos normales Java con un consejo.

Si has hecho una interface y solo tienes una clase que implemente esa interface, quizá debieras reconsiderar si realmente necesitas una interface.

Dejo algunas reflexiones:

El recurso más utilizado para justificar estas prácticas tienen cierta relación con la adivinación. Pongo una interface y así en el futuro puedo cambiar la implementación.

Pero pregúntate. ¿Que posibilidad hay de que en el futuro se cambie esa implementación? ¿Cuanto te va a suponer de coste hoy esa flexibilidad futura? ¿Es previsible que tu organización cambie, por ejemplo de Oracle a MySQL?

Probablemente te des cuenta de que estás pagando un sobrecoste a día de hoy sin tener ninguna seguridad de que en el futuro lo vayas a recuperar.

Si aun así ves que es probable que pueda cambiar, hazte otra pregunta. ¿Necesito tener las dos implementaciones a la vez?

Lo normal es que no. Así que incluso con el empleo de la interface vas a tener que abrir el código para codificar una nueva implementación. ¿Que diferencia hay con simplemente coger la implementación vieja y cambiarla? Tienes una gestión de la configuración para no perder la versión vieja.

Si aun así en el futuro necesitases la interface y varias implementaciones, los entornos de desarrollo actuales soportan la refactorización y una de ellas suele ser el sacar interfaces de clases.

Así que ten en cuenta, a las interfaces les gustan las multitudes.

En las últimas entradas he hablado sobre el cacheo de datos con memcached y de ciertas flexibilidades en arquitecturas que no me gustan.

Pero con respecto a estos dos temas si hay una flexibilidad que me gustaba, aunque no he podido ponerla en práctica, por incompatibilidades de producto o más bien versiones de producto.

Uno de lo problemas que tiene el empleo de memcached, y otras soluciones similares, es que debes codificar el acceso a la caché. Eso implica que si quieres cambiar de opinión tienes que modificar el código y pasar por el consiguiente ciclo de pruebas.

En cambio con tecnologías como hibernate y JPA es posible hacer que ese cache sea transparente a nivel de código fuente, simplemente indicando en el fichero de configuración que tablas quieres cachear.

Esto permite cambiar de opinión con mucha mayor facilidad y cachear o descachear ciertas tablas según va evolucionando el uso de la aplicación.

En general me revienta las aplicaciones que tienen el doble de clases, una para la interface (llamemosla aaaaa) y otra para la implementación (dichosa aaaaaImpl). Cuesta horrores seguir el código. Y ni tan mal si ponen las dos clases en el mismo paquete, así están juntitas…

No es que esté en contra de este tipo de prácticas de IoC, que te dotan de más flexibilidad. De hecho he construido aplicaciones usándolas que mis compañeros de proyecto valoraron como muy buena idea.

Lo que me parece es que se están usando indiscriminadamente. Si, es otra entrada de arquitectura web y CRITERIO.

En una ocasión tuve que meterle mano a una aplicación, relativamente sencilla, pero que no me gustó nada como estaba hecha. Estaba realizada con spring y los consabidos Impl, muy flexible todo. Solo tenia un defecto, en mi opinión. Que donde realmente el usuario necesitaba flexibilidad, (recordamos: objetivo aportar valor al cliente) porque cada año cambia el funcionamiento, era para pegarse un tiro, absolutamente inmantenible. Solo un dato, para hacerse una idea, métodos de 17.000 líneas de código. Si, has leído bien y no, no se me ha colado un cero.

Pues eso CRITERIO.

En la entrada anterior hable sobre lo que es memcached y como su uso puede ayudarnos a agilizar una aplicación guardando datos en memoria.

Esto suena de maravilla, pero siempre hay un reverso tenebroso que quiero contar en esta entrada. Es una entrada sobre un concepto fundamental: CRITERIO

Me explico, si empezamos a almacenar datos y más datos en memcached para que vaya todo más rápido nos encontraremos que o tenemos una cantidad ingente de memoria RAM disponible o va a llegar un momento que memcached va a llegar al límite que hemos fijado y va a proceder a descartar.

Toda la gracia del memcached es cachear una información que es costosa de conseguir para que la siguiente vez que se necesite no tener que volver a pagar el precio de conseguirla. Pero si hemos saturado la memoria y el memcached ha tenido que eliminar contenido, nos saldrá más caro, porque tendremos que ir a la caché, ver que no está (que consume tiempo) e ir a la fuente original.

Hay que cachear con CRITERIO.

Tengo últimamente un poco abandonado el tema de la arquitectura de aplicaciones web, básicamente porque últimamente se han dado situaciones que me han hecho plantearme o recordar cosas más relacionadas con el otro gran tema del que suelo hablar, que es la industrialización.

Pero hoy me ha llegado un email de mi proveedor de hosting, bueno ahora es más cool llamarlo nube, y tenia una entrada en su blog sobre memcached.

Para los que no tengan muy claro que es memcached, aparte de leer el citado blog, decir que es un software que almacena en memoria datos. Podríais pensar que eso no es nada nuevo, una simple tabla hash de java almacena datos en memoria.

Y en esencia es lo mismo, pero memcached es una hash vitaminada, muy vitaminada.

Las ventajas que nos aporta son las siguientes:

– Se puede poner un límite al empleo de memoria, es decir si en una hash de java metemos datos sin parar nos quedaríamos sin memoria. En memcached en cambio cuando llega al límite marcado empieza a descartar.

– Se puede poner un límite de tiempo, es decir a diferencia de la tabla hash de java en la que una vez metido un valor nosotros tenemos que borrarlo manualmente o ahí se queda de por vida, en memcached podemos decirle el tiempo que queremos que se mantenga y el solito lo borra una vez pasado ese tiempo.

– Se puede compartir y esta es una de las principales diferencias con una hash de java. La hash de java vive en la memoria de la máquina virtual, así que el acceso es muy rápido pero solo puede acceder a ella el código que se ejecute en esa máquina virtual.

Si tienes por ejemplo una aplicación de ventas de libros con varios servidores y decides cachear todos los productos, cada servidor tendrá una copia del catálogo de productos.

Es decir un acceso muy rápido pero poco eficiente en el uso de los recursos.

Memcached en cambio es un servidor. Eso quiere decir que es un poco más lento, pero aprovecha mejor la memoria.

Estaba esta tarde mirando un reloj que tengo mecánico y automático. Es decir de los que hay que darle cuerda o llevarlo en la muñeca para moverlo y se de cuerda el solo. De esos que el segundero camina seguido no a saltitos como los de pila.

Son relojes que adelantan o atrasan un montón y hay que preocuparse de darlos cuerda o ponerlo en hora, pero me encanta ponérmelo de vez en cuando y escuchar el tic-tac. Sin nada de electrónica ni electricidad, es una cura de desintoxicación.

En el mundo de los relojes lo tienen muy claro. La funcionalidad principal de un reloj es dar la hora y lo demás son complicaciones. Y así se refieren a ellas, sin medias tintas ni nombres rimbombantes… com-pli-ca-cio-nes.

Pero claro tienen una ventaja sobre los informáticos. Relojes se llevan haciendo desde hace mucho antes que programas de ordenador y nos llevan mucha ventaja.

Hoy día se empieza a extender el concepto de KISS, que ya he tratado en alguna entrada. También ciertos principios o filosofías como el Lean de fabricación esbelta, que aboga por eliminar los desperdicios.

Antes de ayer terminé el curso sobre agilismo que impartía Javier Garzás.

Me ha resultado muy interesante, ya que me ha permitido asentar algunos conceptos y entender la motivación de algunas cosas que conocía del agilismo.

Desgraciadamente en los entornos en los que me he movido profesionalmente se estila más el ciclo de vida clásico. Mucho por inercia, y mayormente por la imposición del modelo de contratación de los trabajos.

Pero poco a poco si que se ve que se va introduciendo el agilismo, o por lo menos ciertas prácticas ágiles.

No creo que el agilismo sea para todos los proyectos, ni el ciclo de vida en cascada lo es, pero si creo que en determinados tipos de proyectos es útil.

También reconforta el ver que ciertas prácticas que has ido empleando de manera más o menos intuitiva están recogidas y se fundamentan con estudios más académicos que la pura intuición o lógica personal.

Me viene a la memoria una imagen de una responsable de proyecto de un cliente que ante la duda de como tenia que funcionar un aplicativo nuevo que estaba substituyendo a otro viejo, en vez de consultar la documentación, y era un sitio muy burocrático en ese tema, prefirió investigar el código fuente del programa viejo, simplemente porque no se fiaba de la documentación.

La industrialización del software está muy ligada con la metodología que se emplee y creo que es muy interesante para las personas que estén en entornos de ciclo de vida en cascada empaparse un poco de otras formas de organizar el trabajo.

En una ocasión me encargaron un proyecto, no muy grande. Era un equipo de dos programadores más el jefe, pero como este no tenia conocimientos de tecnología Java entre yo como especialista.

Así que monté el proyecto con una visión más a largo plazo de lo que se suele hacer.

Sabía que íbamos a tener que entregar el diagrama lógico y físico de la base de datos, así que en vez de hacer las modificaciones de las tablas directamente en la base de datos y al final del proyecto documentar utilizamos una herramienta de modelado de datos para hacer los cambios, generar el script y rehacer la base de datos con ese script. Cuando tuvimos que hacer la instalación en el cliente ya teníamos el script hecho y perfectamente validado. Cuando tuvimos que entregar la documentación de la base de datos, también ya la teníamos y perfectamente actualizada.

Para la gestión de las tareas en vez del típico excel o emails utilizamos un gestor de tickets, que nos permitió tener muy controlado todo el trabajo que se iba realizando y el pendiente de realizar.

La lección que sacamos de esa experiencia es que si dedicas un poco de tiempo al principio del proyecto a construir unos pilares sólidos al final del proyecto te dan sus beneficios. El proyecto no se desvió por esos motivos, si por otros.

Fueron medidas sencillas de aplicar con un muy buen resultado. El problema es que a veces la gente se obsesiona con el «si hacemos esto mejoraríamos a largo plazo» y acaba cayendo en la sobreingeniería. Que es tan mala o incluso peor que el hacer las cosas chapuceramente.