Tenía un viejo amigo al que en una ocasión de entrevista con una consultora informática le preguntaron: «Deme usted un ejemplo de patrón» y él respondió: «Una clase Java o una mesa…» El entrevistador puso mala cara y pensó: «Por listillo, pa casa…» No le pidió que lo argumentara y como quería hacer sangre prosiguió con el cribado mientras le miraba con recelo: «Cuénteme usted un ejemplo de broker que no sea una cola de mensajería» El payasete respondió: «Vosotros…» Fin de la entrevista.
Para la siguiente oportunidad mi amigo se aprendería todos los patrones de diseño de la mítica Gang of Four que emergían desde hace tiempo con fuerza, junto con la posterior irrupción de UML, para ir acotando las soluciones artesanales y algo románticas propias del inicio de la informática.
Ordenar el caos… Eso intentaban los pioneros. Lo aprendieron de la naturaleza, que mientras aumenta la entropía, de algún modo quizás también intenta ordenarla sin éxito. La naturaleza creó al hombre y este a las máquinas, que aprenderán también a reconocer patrones y a fabricar ellas mismas otras máquinas.
Al fin y al cabo el universo es determinista, al menos en la realidad cotidiana, por tanto la mente humana no podría funcionar sin patrones, sin estereotipos, sin etiquetas. Cualquier concepto aleatorio escaparía probablemente al aprendizaje. Sin algo estático, inmutable, la mente no podría formar prejuicios, no sería funcional. Si todo estuviera cambiando todo el tiempo, no seríamos capaces de reconocer nada.
Un ejemplo claro de patrón es el lenguaje, clave en el pensamiento. En el absurdo de que hubiéramos inventado un idioma que cambiara cada nanosegundo, nunca podríamos comunicarnos o acaso pensar en él. Necesitamos algo fijo, que se repita, lo que nos ofrece una solución a la comunicación y a poder pensar en algo en términos simbólicos. Obviamente todos los lenguajes son así, incluidos los de programación pero existe también la problemática de hablar entre distintos lenguajes, igual que ocurre con los naturales.
La informática es uno de los lugares donde los patrones son mas evidentes. Hay muchos ejemplos de nuestro afán por alzar patrones en el software y en el hardware, que nos pueden contar algunas historias:
DSL y GPL
Un lenguaje de propósito general como Java ofrece flexibilidad, una solución para múltiples problemas. Un lenguaje específico de dominio como SQL es más potente que el anterior pero solo para tratar con un dominio muy concreto, en este caso, las bases de datos relacionales.
Sería ideal tener lenguajes y modelos de datos para dominios más complejos, que modelaran un banco, una teleco o el clima, .. pero es un patrón muy complicado en la mayoría de casos y más si intenta abarcar algo heterogéneo.
Más «fácil» es alcanzar el común denominador si lo que se busca es una solución global. En el matiz de la concreción está la diferencia. ¿Hasta donde ordenar la incertidumbre?, ¿hasta donde debe llegar el patrón?
Servicios SOAP/xml y APIS REST/json
SOAP es un protocolo para comunicar dos procesos diferentes por medio de mensajes en un lenguaje de marcado común, el xml. REST es más abstracto, lo denominan estilo de arquitectura, quizás conceptualmente el propio core de Internet. Ambas se «crearon» en torno al año 2000.
«Simplificando la reflexión»: En aquel entonces se necesitaba una forma de comunicar sistemas diferentes y distribuidos. ¿Por qué no se enviaron inicialmente los datos por la conexión http simplemente? Era mejor tipar los datos para que ambas partes supieran qué enviaban y recibían, que operaciones realizaban, para adaptarlo fácilmente y sin ambigüedades a sus sistemas así que definieron un interfaz propio para cada servicio con WSDL y XSD. Aumentabas también la seguridad ya que definías qué podía llegar y cómo.
Esto sirvió en una época de poca distribución, con empresas comunicándose, pero con la explosión de los móviles y demás dispositivos, la integración con los browsers y el concepto de la Internet misma, no era manejable en términos de velocidad o complejidad.
El protocolo sobra. A tomar por $#&#? Mandas por http un mensaje json (o cualquier otro: el cielo es el límite) que es texto plano como el xml pero resulta ser mas liviano para anotar la misma jerarquía.
Este patrón era mas general, mas maleable, no necesita añadir librerías de parseo ni de gestión de protocolo, ni gestionar el versionado de estos.. el interfaz es único y universal, común a todos los apis y la implementación, el mantenimiento y la ejecución es más rápida.
¿Pero que pasó luego tras el primer api (y de lo que indudablemente eran conscientes)? Los mismos problemas y necesidades que vio la gente que diseñó SOAP para empezar a acercarse a este: Interfaz con wadl o swagger, tratar la seguridad con https, acotar y controlar la información que entra y que sale..
Albert Einstein, que parece ser que era un tío muy listo y que no se llevaba muy bien con la física enana, decía algo así como: «keep it as simple as possible but no more«.
Es difícil identificar la complejidad esencial (la que tiene un problema per se) y la accidental (la que tiene la solución que se implementa). ¿Hasta donde etiqueto, hasta donde controlo, hasta donde dejo grados de libertad? Y después, puedes darte cuenta de que necesitas ser mas específico o al revés.. Un pasito para alante, un pasito para atrás.. ¿Un marinero que quiere ser patrón y un patrón que quiere ser marinero?
Google Android y Apple Ios
Cualquiera que haya desarrollado o al menos haya visto el código de una app para Ios y una para Android puede notar algo claro: Las de Apple son mas restrictivas, mas complejas, tienen requerimientos y reglas más exagerados de estructura, de nomenclatura, incluso de despliegue en su store. Apple siempre tuvo fama de excelencia, de seguridad, hasta de elitismo, tanto en su software como en su hardware. Es probable que sea cierto que sus productos sean los «mejores» pero ¿a qué precio?
Google apuesta más por soluciones flexibles, por estándares más abiertos, más accesibles y sencillos. Es probable que se traten simplemente de estrategias de ambas partes para que lo suyo se establezca como estándar de facto.
Es curioso que Steve Jobs siempre fue muy open-minded y luchaba contra los dogmas en la Universidad de Stanford, pero los productos de Apple son todo lo contrario. ¿Quizás abierto en la idea y no tanto en la implementación? Al final, detrás de la búsqueda de los mejores modelos, cuando se trata de dos empresas gigantescas, puede que haya un razonamiento guiado más por el interés y la competencia.
WordPress
Durante años los programadores implementaron portales webs handcrafted repitiendo millones de veces las mismas operaciones. Coste, tiempo y esfuerzo en reinventar la rueda..
Con los años se empiezan a generar patrones de patrones, cada vez más complejos, fruto de la experiencia y surgen los gestores de contenidos CMS y en concreto Wordpress. Temás como gestión de uris, la navegación, taxonomías, maquetado, validaciones, autogestión de CRUDs, SEO, integración con e-commerce y todo lo imaginable y deseable en una página web puede resolverse vía core o vía plugins.
La simplicidad a todos los niveles es la clave de que sea una de las herramientas o frameworks más exitosos a nivel mundial. Tecnologías simples y muy conocidas en su core LAMP kind-of, configuración vía interfaz de usuario avanzado con formularios, extensión de funcionalidades simple, rápida y flexible así como lo es la propia instalación o el despliegue.
Quizás se acerque bastante a un gran arquetipo. No es patrón pero tampoco es marinero. Su núcleo tiene el denominador común y luego tiene multitud de plugins, widgets, templates.. para extender sus capacidades. Su propia sencillez ha provocado que las adhesiones de usuarios y programadores a su sistema hayan contribuido a mejorar cada vez más la plataforma.
Se puede argumentar que es trivial crear un arquetipo sobre un dominio fácil, delimitado y muy manido, que vale para lo que vale, incluso dentro de los CMS. Puede que sea cierto en parte, pero independientemente del sistema a crear, conceptualmente puede ser un buen sitio donde mirar.
Aún con todas sus posibles bondades, es necesario la participación de un experto (y como en cualquier tecnología mutante y en continuo crecimiento, tres vidas para dominar un poco todo lo que implica) y en muchas ocasiones, modificar código, maquetado, modelo, etc… Como suele pasar en muchas ocasiones con el software (y WordPress es casi la antítesis de esto) lo que se intenta hacer general al poco tiempo termina siendo ad-hoc.
Los enchufes del IOT
El Internet de las cosas no despega… Entre el sensor y la nube existen acoplamientos imposibles de hardware, redes wireless, middlewares y protocolos varios…
Todo empieza en el hardware, igual que hace varias décadas empezaron los computadores estándar y de ahí para arriba. Pero tanto abajo como arriba hay problemas… Posiblemente el aislamiento de fabricantes, el querer imponer un estandar o una dispersión propia del inicio al no saber la dirección. Plataformas más prototípicas y divulgativas como Raspberry y Arduino tratan de evangelizar al respecto y sensores como los grove (plug easily and play) hacen fácil la vida pero cuando entras en soluciones comerciales esta vida se complica.
Ensamblar el hardware indio puede a veces ser cosa de chinos o conocer el input y el output de cada sistema. De ahí subimos a las decenas de redes wireless y de sensores. De las clásicas bluetooth, WIFI o Zigbee, surgen 25 más, cada una de su padre y de su madre..
Luego, los protocolos de comunicación: Primos hermanos de sus hermanos mayores (que se sabe que estandarizaron) pero adaptados para constrained devices: COAP punto a punto como una suerte de http RestFull pero mas libiano y sobre UDP pues la entrega garantizada puede no ser necesaria, MQTT sobre TCP para el publish/subscribe y apis sobre websockets bidireccionales para evitar el push del servidor y el polling del cliente..pero parece que no son estándares aceptados totalmente.
La M2M era más fácil en los tiempos de la domótica… La cosa se empezaba a complicar con tantos elementos a todos los niveles. ..
La española Libelium lo intenta mejor que nadie en el hardware ofreciendo algo que intenta abarcar toda la parte dura y OSGI lo intentó más arriba, pero sus ideales de piezas desacopladas plug´n play y autodescubribles no salían gratis… Por si fuera poco, aparecerán encima o debajo o al costado otros 300 servicios multicolor, 50 middlewares y 350 plataformas de cloud..
Uy uy uy… stop, stop!! Esto es un jari! 502 Bad gateway! Sueltas las tres cositas que sabes del tema y empiezas a saltar de un nivel a otro sin sentido, sin continuidad, disperso… Concreto en algunos protocolos y luego el acabado así? 404! No hay conexión!
Existen infinidad de enchufes que no entran en el agujerito del otro.. Cambias de país y el que tienes ya no vale… <no plug 🙂 no play>. La interoperabilidad y compatibilidad entre sistemas es esencial y si en vez de dos tienes dos millones, mucho más. Cuando reina el caos y no hay estándares medio comunes, se hace imposible funcionar y acabas integrando en una adaptación suicida hasta el fin de los días..
Robótica: Diego Costa
Simeone vio claro el perfil, el tipo de jugador que necesitaba arriba para el tipo de su equipo, el tipo que encaja en el tipo .También es necesario siempre tener una referencia aunque no sea perfecta. Es el punto de partida y el foco para decir: «Esto no está tan mal y aquello se puede mejorar así..» Sin referencia no hay nada que criticar, ni nada que progresar. Los patrones son también antipatrones o semipatrones hasta que llega otro.
Este texto mismo es muy imperfecto, tiene fallos en las reflexiones, no hay conclusiones, es caótico, espeso, asevera cosas que no son ciertas del todo, a veces más concreto, a veces más abstracto, intenta ser conciso pero divaga, es pretencioso.. pero algo es: intenta ordenar el caos. A pesar de todo, acabo de leerlo y no entiendo nada…
Blanco o negro, 0 o 1. ¿Habrá algo entre medias? Una lógica difusa en esas pequeñas cosas que están entre otros sitios en nuestra cabeza y que durante décadas no consiguió comprender ni el mismísimo Alberto. También ahí intentamos encontrar el patrón, aunque sea solo probabilístico, pues mas allá no alcanza…
Mi amigo, el de la entrevista del principio, me dijo una vez: «Si tuviera que estar seguro de lo que digo para poder decirlo, estaría siempre callado…» Menos mal que somos impulsivos marineros.
Por cierto, por si alguien lo intenta, no metáis esto en un compilador… da error.