Yo no tengo ni idea de lo que es un data lake pero la definición se me parece a algo así: tira aquí todos los datos y ya veremos.
Pinta bien, si algún día necesitas no sé qué dato para hacer machine learning, ahí está, lo coges y lo usas.
Ahora, me pregunto: si es complicado mantener tus datos de producción, cómo demonios se mantiene mínimamente organizado, y por tanto usable, toda la cantidad de datos que genera una empresa.
Los datos son como el cuerpo humano: las partes que no ejercitas son grasa y esta pasa factura a largo (y a corto) y necesitas ejercitarlo para que funcione bien
Pero imaginemos que el data lake es perfecto:
Me cuesta ver como alguien que no está acostumbrado a los datos pueda abrir Tableu, engancharlo ahí y sacar “insights”. A un desarrollador, en teoría más cerca de los datos, le cuesta trabajar solo con los datos de producción…
Me pregunto, no tiene sentido que la exposición de los datos sea también lo que llamamos “producto”?
Twitter es una maravilla, te permite hablar con gente y todo ese rollo que nos hace humanos. Pero:
Lo que escribes se va, aunque no tenga fecha de caducidad.
Lo que escribes es de twitter, cosa bastante justa porque ellos ponen la pasta.
Así que qué mejor que un repositorio donde almacenar esas cosas que, a veces, no entran en 200 y pico caracteres y que quiero que permanezcan.
Menos ruido, más contenido.
Esto es micro.
Cuando desarrollas un producto digital a menudo surge la necesidad (bueno, a veces surge sin haberla) de tener un API. Un API no deja de ser una forma clara de quitarte marrones de encima. Tú no vas a poder hacer toda la funcionalidad para todos los casos de uso, así que tiene sentido que otros la hagan por ti.
Por otro lado:
Después de la obvia pero necesaria introducción, os dejo aquí una serie de cosas que he aprendido durante 7 años diseñando, desarrollando y manteniendo un API (con millones de peticiones diarias)
Si algo he aprendido en todos estos años, es que desde el mismo momento que un cliente desarrolla algo sobre tu API acabas de meter tu libertad entre barrotes. Recuerdas todos esos “lo dejamos así y ya lo cambiaremos”? Bien, no los vas a poder cambiar porque siempre hay algún cliente usándolo.
De ahí que tengas que tener un versionado del API desde el primer momento. No entro en el modelo técnico, da igual como lo hagas, pero hazlo.
Stripe tiene una serie de blogposts muy muy buenos sobre el tema, uno de ellos en su blog oficial y el otro en el blog de brandur del que deberías leerte cada artículo si estás desarrollando un API
Relacionado con el versionado:
La documentación es producto. La documentación no es una cosa que está ahí y la revisas de vez en cuando.
La mejor forma de que una documentación sea producto (desde mi punto de vista, como todo lo que escribo aquí) es que sea una parte más del código, es decir, se testea, se despliega, se hacen code reviews. Por ejemplo, la documentación de airtable es viva, de hecho te dan a elegir con qué “tabla” ves los ejemplos de la documentación.
Por otro lado la documentación debería tener: introducciones, guías, tutoriales, ejemplos, documentación del propio API, FAQ, tags en stackoverflow, listas de correo, grupos de google… Recuerda que ahora la gente no programa, busca el ejemplo más cercano a lo que necesitan y los modifican.
Usa el sistema que quieras y más adecuado para tu caso de uso pero, salvo casos muy concretos, nunca dejes usar tu API sin pasar por un paso previo para obtener una credencial. Echad un ojo al cristo que ha montado google con el api de google maps que al principio no necesitaba ningún API key
Aquí la tendencia es a hacer REST (y a discutir qué es REST y qué no lo es) pero a veces no encaja. Es cierto que da cierta familiaridad al desarrollador que lo está usando pero a veces tu modelo no encaja con REST, no fuerces la máquina, usa lo que encaje.
Hacer clientes para python, javascript, ruby, rust, go, java…idealmente, si puedes hacerlos porque tienes recursos, hazlos (si no, mejor poco y bien que mucho y mal):
Por contra:
Mucha gente adopta la técnica “open source”. Los saco open source y la comunidad los mantiene. Tiene sentido pero también me causa ciertos dilemas morales.
No olvidemos cosas con OpenAPI, Postman, RunKit, CodePen y compañía que siempre ayudan.
“Hemos creado un API para que lo use nuestro UI, publicamos ese API o creamos uno nuevo bien hecho”. Pasa en las mejores familias, lo habitual es que el interfaz sea un caso muy específico de tu API así que podría tener sentido tener un API paralelo.
Mi experiencia es que el API expuesta para el UI es API pública aunque no esté documentada, sobre todo porque seguramente hace algunas cosas que los desarrolladores quieren.
Por otro lado hay veces que tienes que tener más de una vista del API para diferentes clientes. Por ejemplo, es común tener un api diferente para móvil que para desktop depende del caso de uso.
Los errores deberían ser accionables y sinceros:
Más allá de los errores, que son fundamentales, los warnings suele ser muy informativos para avisar de ciertas cosas.
Si tu API no tiene límites te va a dar muchísimos problemas en cuanto tengas cierto tráfico. Siempre hay un cliente que hace alguna burrada y como estamos en entornos donde se comparten recursos, vas a morir.
Aquí hay un problema y es que en general no sabemos cuanto es capaz de tragarse nuestro backend (que este es otro tema para tratar largo y tendido) pero marcar unos límites mínimos sobre:
Buenos ejemplos son, por ejemplo, el de github o mapbox
Por otro lado esto te permite, no solo poner tener un SLA, sino que harás que tu equipo on-call duerma mejor y además les darás razones a tus comerciales para hacer upsell.
Los SLA son básicamente los padres por varias razones:
Y obviamente para medir el SLA tienes que poder medir cuando estás caído.
Cuando llegas a un nivel necesitas poder tomar decisiones en función de lo que está pasando y para eso tienes que tener analítica. El problema es que la analítica suele ser complicada porque si tienes varios millones de peticiones al día en unos meses ya necesitas algo serio.
Por otro lado los clientes empiezan a querer tener dashboards y métricas de uso (sí, deberían tenerlas ellos, pero no las van a tener y además puedes cobrar por ellas) y los desarrolladores y soporte ahorrarán horas y horas intentando saber qué pasó hace 1 día con el cliente XXX.
Da igual lo que uses, kibana, cloudwatch recuerda que:
Si estás en este punto tal vez te interese hablar con nosotros.
Si conoces algún API que creas que sirva de referencia y merezca la pena poner aquí, enviame un tweet, un correo o una pull request y cuéntame la razón.
Por último, obviamente estas cosas no se implementan de la noche a la mañana, ni todas aplican a todos los casos, ni lo que está aquí es todo lo que hay, de hecho, de la parte más importante, la del diseño del API, ni he hablado.
Los odio, y no porque me parezcan malos, los he usado, los uso y los usaré por el resto de mis días como programador. Un framework no deja de ser una forma más o menos cerrada de resolver un problema donde la mayoría de los casos de uso más o menos comunes han sido simplificados. Nada tienen de malo y mucho de bueno.
El gran problema viene cuando el framework es el foco.
Cuando la gente piensa que su carencia de conocimiento la puede paliar con un framework, cuando da igual el negocio que modeles, el framework es el santo grial, crees que cualquier problema complejo lo vas a solucionar con el framework. Uso react y redux y con esto todas mis condiciones de carrera se irán.
Y parece que sí porque te da un modelo con el que trabajar, cuando comienzas cualquier proyecto lo básico suele ser muy parecido y los retos son más bien sencillos. El framework te da ese subidón de “lo estoy partiendo”, “voy a toda leche”, te enamoras de él.
Pero pronto se acaba la alegría cuando empiezas a modelar el negocio de verdad y ves que el framework es una pequeña ayuda, entonces intentas apalancarte en el framework como forma de solucionar todo, y termina por ser el que marca todo: tu arquitectura, tus herramientas y hasta el cómo contratas.
El CTO o lead developer se ve acorralado porque sus desarrolladores dicen que XXX es mejor que lo que estamos usando ahora. “Si usasemos XXX todo irá mucho más rápido”. Todo vale si el desarrollador está feliz, de otro modo se irá a la empresa que sí usa XXX. No te preocupes, no tardará en salir la voz que no entienda que la cultura de empresa pasa por no hablar de frameworks y sí de problemas y soluciones.
No irá más rápido, no será mejor, lo que pasa que volverás al primer paso donde los problemas sencillos se adaptan bien a lo que el framework te da.
De mientras todas tus ofertas de trabajo ya tienen “empresa YYYY busca personas para desarrollar en XXX”. Ya todas tus conversaciones son sobre el último plugin o el fork del framework. Toda tu tecnología está basada en XXX, Todos tus desarrolladores quieren ir a “XXX Con” en SF, donde todos los mayores expertos se reúnen para enseñar las maravillas de XXX (ellos sí son listos, sí tienen una ventaja al crear la tecnología). Las voces que comentan lo complicado que es hacer algo con el framework son rápidamente acalladas, todas las bondades que hemos vendido se irían al traste.
Toda tu estrategia tecnológica, de adquisición y mantenimiento de talento se ha basado en usar un framework. Toda tu estrategia se ha basado en usar algo que todas las empresas tienen disponible.
Los que se vienen por un framework se irán por otro.
Un buen desarrollador no mira al framework, mira a la forma de resolver los problemas con el framework, lo entiende, sabe cuando y como usarlo, entiende que la tecnología avanza y que su código funcionando en producción de forma robusta, resolviendo problemas dejará de usar algo novedoso (cosa, por otro lado normal en absolutamente todas las industrias. Debemos ser los únicos que no nos sentimos orgullosos de nuestro pasado)
El buen desarrollador usa un framework porque sabe lo que hay debajo, no para evitarlo.
Una buena empresa es buena porque se enfoca en resolver el problema por el que le pagan y eso incluye desde el CEO hasta el desarrollador.
Empiezas a desarrollar tu producto y pasas por las siguientes fases:
El problema es que piensas que tienes tiempo infinito. Si el tiempo es finito, qué sentido tiene tener un sistema que solo crece?
Mi teoría es que cualquier herramienta que en una empresa permita generar contenido libremente y sin una estructura definida va a ser un problema en algún momento. Ejemplos: mail, wikis, tickets, documentos, slack…
En cualquier caso, este post de Joel on Software, Software inventory es básicamente lo que cualquier empresa debe recordar todos los días. No he visto nada hasta la fecha que sintetize mejor las reglas para tener un buen proceso de desarrollo de producto que ese post.
De hecho, como el tiempo es limitado hubo alguien que pensó en que alguien debería tener un rol para priorizar, llamado el product manager, que en mi opinión es fundamental, sobretodo para descartar más que para añadir (que suele ser lo habitual) y no solo en el momento de creación de tickets/features, si no durante el proceso de desarrollo de las mismas.
No hay solución, sobre todo si vas a muerte y no tienes tiempo de hacer tareas de mantenimiento. A quién le gusta revisar los tickets, ver si las features planteadas tienen sentido? Lo que NO es la solución es buscar una herramienta que solucione un problema de base, está bien buscar una herramienta que te ayude mapear tu proceso a lo digital, pero esa herramienta no va a solucionar un problema que está en las personas, esas son las que debes entrenar.
Pero claro, para que una persona sepa discernir entre algo que tiene sentido registrar y algo que no debe tener una visión más allá de la “siguiente tarea”. Cuando transmitir los objetivos de forma clara no se hace entonces se habla de que hay “problemas de comunicación”, pero eso es para otro post.
Uno de mis sueños es algún crear un sistema de tickets/mail donde se tenga dinero y cada cosa que pongas cueste dinero (se podrían implementar usando blockchain, lo mismo puedo levantar una rondita), tampoco iba a solucionar el problema, pero por lo menos haría visible el problema para todos.
En cualquier caso, si vas a pasar a Jira, por favor, integra el repositorio de código con él, no se te paso por la cabeza el “duplico los tickets que necesite” o hago las referencias manualmente. E invierte tiempo con el equipo, sea Jira o sea un fichero CSV.