Categoría: Arquitectura & DevSecOps

Como comenté en la anterior entrada estoy leyendo el libro Clean Code. Bueno realmente son dos, uno más técnico, más de código y otro, que todavía no he empezado, que parece más filosófico. No se porqué Amazon los ha juntado en un único libro, me parece un poco más incómodo.

Siempre me ha interesado el tema de la calidad en el código, tan ignorada hasta hace poco, así que este libro al principio no me aportaba mucho, porque expone conceptos que ya conozco, pero poco a poco va mejorando.

Me ha resultado especialmente interesante el capítulo sobre la documentación que estoy leyendo. A pesar de lo que pueda parecer de que va a proponer documentar todo, no lo hace. Propone que mejor que trabajar en explicar, es decir documentar, un código complejo o difícil de entender, lo que hay que hacer es trabajar en hacer que el código sea autoexplicativo.

Comparto con el autor el planteamiento de que hoy día los entornos de desarrollo permiten hacer tareas que antes no se podían. Me explico.

Antiguamente cuando se trabajaba con IDE que eran poco más que un editor de texto con resaltado no era posible hacer refactorización, es decir cambiar el código para que siga haciendo exactamente lo mismo, pero de forma más eficiente u ordenada. Tampoco se había generalizado el TDD, que te permite cambiar el código y ejecutar todas las pruebas para comprobar que funciona todo. Así que cuando conseguías hacer que tu código funcionase no tocabas ni una coma, que ya se sabe: «Si funciona no lo toques»

Tampoco estaba tan extendido el empleo de repositorios de código, con lo que volver a una versión anterior era más farragoso.

Pero a día de hoy todas estos temas están superados, el problema es que seguimos con muchas de las inercias de cuando había más limitaciones.

Me resulta parecido a utilizar Windows 8 que a pesar de su nueva interface la he seguido utilizando como las versiones anteriores…

Me parece muy recomendable para cualquier programador, sobre todo los más noveles, el leer el libro Clean Code

Hace ya una semana que se celebró el BilboStack. Un acto realmente interesante, con algunas intervenciones incluso con gente en los pasillos.

Hubo una intervención que me gustó especialmente, y eso que fue un substituto de última hora. Fue sobre la deuda técnica que expuso Rodrigo Corral. No es que las otras intervenciones estuviesen mal, todo lo contrario, es que esta fue la que más me hizo reflexionar.

Nuestra profesión tiene un componente muy importante de sector servicios, es decir tenemos clientes que nos piden cosas y nosotros se las hacemos. No muy diferente de lo que puede ser, por ejemplo un pintor, al que si un cliente le pide que le pinte la casa de naranja, independientemente de sus gustos se la tiene que pintar de naranja.

El BDD y AngularJS están muy bien, pero al final, lo primordial es hacer un trabajo de calidad y para ello hay que involucrar también a los clientes. Si para tener poca deuda técnica hay que invertir un poco más al principio, salvo que el cliente lo entienda y asuma, no vas a tener muchas posibilidades de «tardar más» y hacerlo mejor.

En esta línea me pareció muy oportuna la pregunta que le hizo un antiguo compañero de trabajo, sobre como evangelizar sobre la deuda técnica.

Estoy leyendo un libro de Clean Code que recomendaron y una de las cosas que dice el autor y con razón es que a nadie se le ocurre decirle al cirujano antes de una operación que no hace falta lavarse para desinfectarse y que se meta al tema rápidamente, y eso que el paciente es el que paga la operación. Aparte de que el cirujano se negaría en redondo a hacerlo. Pero en este sector los técnicos no tenemos ese grado de autoridad.

Quizá a estas reuniones tendrían que asistir los clientes más que los técnicos.

Hace unos días Javier Garzás publicó una entrada en su blog sobre el probable futuro del desarrollo de software, que me parece muy interesante de leer. Y me parece muy interesante porque viene de alguien que tiene contactos con diferentes sitios, con lo que te da una visión más amplia que cuando estás enfrascado en tu negocio o cliente, con sus particularidades propias.

Yo añadiría otro futuro, que me inquieta, porque lo he vivido en el pasado. Me explico. Cuando yo empecé en el mundo del desarrollo lo que se llevaba era el hacer webs más bien publicitarios y comercios electrónicos.

Hoy día muy pocas empresas, por no decir casi ninguna se plantea el realizar su portal o su comercio electrónico totalmente a medida, básicamente porque hay multitud de paquetes para hacerlo. Tanto paquetes para construir portales o comercios electrónicos pequeños, como grandes.

Hoy día se ha pasado en estas áreas de desarrollar a parametrizar un paquete, con algún desarrollo para hacer alguna adaptación. Pero y ano existe el empezar, como dirían los escritores, con una hoja en blanco.

Para una persona que se dedica al desarrollo de software a medida, el paquetizado es una amenaza. Sobre todo porque el software a medida es muy caro y muchas veces de una calidad baja.

Estaba esta mañana probado un servicio/aplicación que ha lazado el BBVA, para manejar dinero con el móvil. Se llama Wizzo.

Me registro, pongo una contraseña un poco larga para que sea algo más segura. Me registro correctamente, pero al entrar me dice que no, que no es correcto. ¿Me habré equivocado? Bueno pues pruebo el recordar contraseña, con la misma clave, me acepta la contraseña, pero al intentar entrar me sigue dando error.

Después de probar unas cuantas veces, saco la vena tester y pruebo con una contraseña más corta… y funciona…

¡¡¡¡ No han validado las longitudes de los campos !!!!

Creo que esta gente del BBVA debiera de echarle un vistazo al artículo de pruebas que no podemos fallar.

Da mucha seguridad confiar tu dinero a una aplicación con unos fallos tan básicos… Esto ya no es deuda técnica, es desprestigio técnico…

En este breve repaso de la evolución de la arquitectura de aplicaciones Web, desde los comienzos muy estáticos hasta la actualidad, quiero comentar porque me resulta interesante el empleo de AngularJS y porque estoy introduciéndome en su uso.

Hemos visto que cada vez se ha ido trasladando más lógica de presentación a la capa en la que se realiza la presentación, es decir al navegador. Con el empleo de jQuery nos podemos acercar mucho, pero no completamente. Lo que nos aporta AngularJS a este objetivo:

La capa de presentación la construimos con javascript y html estático, es decir, ahorramos recursos:
– Al ser ficheros estáticos los puede servir un servidor web, más ligero que un servidor de aplicaciones.
– Al delegar la ejecución de la lógica de presentación en el navegador necesitamos menos potencia en el  servidor, ya que el servidor de aplicaciones no tiene que construir la página.
– Al ser los js y html recursos estáticos el propio navegador los puede cachear, con lo que se reduce el tráfico de red.

Existe una separación más clara entre los roles de desarrollador de la interface y de la lógica de negocio. Esto nos debiera permitir especializar más a los desarrolladores, sobre todo teniendo en cuanta que hay que gestionar la capacidad de la gente. También nos debiera de permitir el poder trabajar dos personas en paralelo la misma funcionalidad.

El estado de la sesión la podemos mantener en el propio navegador, con lo que el servidor se acerca a un sistema sin estado, lo que hace que sea más fácil escalar.

Podemos controlar el historial del navegador, sin que el empleo del botón de atrás nos rompa la aplicación.

Estas características hacen que sea muy interesante el por lo menos dedicarle un rato a introducirse en el empleo de AngularJS para confirmar que tiene la buena pinta que aparenta.

En esta revisión de la evolución de la arquitectura de aplicaciones Web, tal y como yo la he vivido hoy toca hablar de algo que nos acerca mucho a los planteamiento de AngularJS. La explosión definitiva del uso del javascript en el cliente con la popularización de JQuery

Recordemos que fuimos pasando de unas webs muy estáticas a unas webs con contenido más dinámico y asíncronas , pero en el que el empleo de javascript se hacia más complejo, porque se trabajaba a demasiado bajo nivel y lidiando con las peculiaridades de cada navegador.

En este escenario es donde jQuery empieza a imponerse como una solución para hacer más sencillo el construir este tipo de aplicaciones web. Además de aportar una serie de plugins que nos permiten hacer muy fácilmente desde animaciones hasta componentes como tablas paginadas.

El empleo de jQuery nos acerca a tener una lógica de presentación ejecutándose en el navegador.

– Avanzamos en la reducción del trasiego de páginas completas desde el servidor a los navegadores.
– Avanzamos en trasladar el mantenimiento del estado al navegador.
– Avanzamos en dotar a las aplicaciones de una mayor riqueza visual.
– Avanzamos en una mayor velocidad de uso.

Pero este planteamiento de SPI o SPA (Simple Page Interface o Arquitecture o Application) también nos provoca ciertos problemas:

– Tenemos problemas para controlar el histórico, es decir si el usuario utiliza el botón de atrás del navegador
– No tenemos un mecanismo fácil de plantillas y de programación de la página Web, aunque jQuery ayuda, hay ciertas cosas que seguimos teniendo que hacer en el servidor, porque resulta más sencillo y cómodo.

En este repaso a la arquitectura web de camino a soluciones como AngularJS la siguiente etapa después del DHTML fue el empleo de ajax y su correspondiente mofa fácil con el ajax pino…

Recordemos que pasamos de páginas web muy estáticas y muy influenciadas por marketing y diseño a páginas con un mayor grado de dinamismo .

Pero en este planteamiento se seguía yendo mucho al servidor y cada vez que se iba se devolvía toda la página. Había formas de hacer llamadas asíncronas, como utilizando applets o con frames, pero eran soluciones muy rudimentarias hasta que apareció ajax y puso el asincronismo de moda..

El empleo del ajax en estas primeras épocas permitió que ciertas tareas, normalmente auxiliares que hay que ser prudentes con las cosas nuevas, se hiciesen en segundo plano. Tareas como verificar unos datos, recargar combos, actualizar pequeñas áreas de la página, etc.

Se empezó a ganar algo mas de velocidad, ya que no se tenia que ir al servidor y regenerar toda la página. Se fue reduciendo así mismo las ocasiones en que se necesitaba gestionar el estado en el servidor. También se mejoró la percepción del usuario ya que no tenia una ventanita cada dos por tres indicándole que esperase que se estaba trabajando, porque se habia enviado la petición y el servidor le estaba devolviendo toda la página.

Pero había una pega, como toda tecnología nueva, estaba poco arropada, y había que andar lidiando con el objeto xmlrequest a mano, a bajo nivel y pegándose con las peculiaridades del javascript y del propio objeto de cada navegador. Y cuanto más lógica de presentación trasladas al navegador, más código javascript tienes…

En esta serie de entradas sobre la evolución de la arquitectura web, por lo menos la que yo he vivido, conté los inicios, estáticos mayormente, para ir entendiendo porque me parece interesante las soluciones estilo AngularJS.

Todavía muy influenciados por la parte de marketing y de diseño, la siguiente evolución grande que hubo fue el empleo de DHTML, es decir hacer un poco más dinámicas las webs, introduciendo más javascript y sobre todo las capas.

Esto permitía que las páginas/aplicaciones web empezasen a no necesitar el recurrir tanto al servidor. Podías presentar ciertas ventanas de confirmación o de pregunta mediante capas. Existía de antes la posibilidad de hacerlas en javascript, pero normalmente los clientes querían versiones más bonitas, que el cuadro que sacaban los navegadores.

Se había empezado a trasladar cierta lógica de presentación a donde se realiza la presentación, es decir al navegador. Esto hacia, que aparte de tener una mayor velocidad, por no ir a regenerar la página al servidor, la programación fuese más sencilla, ya que no había que mantener el estado en la presentación de esas ventanas.

Pero seguía habiendo mucha lógica de presentación que se realizaba en el servidor.

Hoy toca una entrada de abuelo cebolleta, porque en este proceso de actualización de planteamientos de arquitectura web que me ha permitido mi actual situación laboral, hay uno (AngularJS) que me está atrayendo bastante. Pero para entender el porque me parece interesante ir hacia ahí creo que es importante saber de donde venimos.

Originalmente, estoy hablando de finales del siglo pasado, no se manejaba el concepto de aplicaciones web, sino de páginas web. Es decir lo que se hacia eran páginas con cierto contenido dinámico. De hecho en esas épocas casi tenia más importancia la parte de márqueting y diseño que la programación.

Poco a poco se fue añadiendo cada vez más dinamismo a esas páginas.

Algunas de las características de ese tipo de «aplicaciones» Web:

– La lógica se manejaba en el servidor, porque había bastantes problemas con las compatibilidades entre navegadores, tanto a nivel de HTML como de Javascript. Así que se solía ir a lo seguro que era el servidor.

– Como la web estática empezó como una extensión del marketing de las empresas los clientes/usuarios se habían acostumbrado a interfaces bonitas, pero no había capas ni DHTML nada por el estilo. Así que todo iba al servidor.

– Cada vez que se necesitaba algo del servidor se devolvía toda la página actualizada, nada de enviar cachos. Eso hacia que el consumo de ancho de banda fuese alto. Tampoco era un problema excesivo porque solían ser aplicaciones auxiliares.

– El estado se mantenía en el servidor, porque como hemos comentado cada petición al servidor implicaba la regeneración de toda la página.