Tienes todos los datos de tu empresa en un solo sitio. Nadie en su sano juicio permitiría acceder a todos los usuarios a todos los datos. Esto obviamente no aplica tanto a una pequeña empresa, aquí con dar acceso de solo lectura a una réplica de la base de datos de producción [1] para que la herramienta de BI de turno pueda coger datos es más que suficiente. Eso sí, no llames a esto “democratizar el acceso a datos”, el término sería “anarquizar el acceso a datos”
Porque hoy hay 30 personas en tu organización pero mañana hay 120 y luego 119… me sigues no? Esta es una razón para dejar que ciertas personas vean solo ciertos datos, pero hay otras, por ejemplo simplificar la vida de la gente.
De ahí que tengas que tener un control de acceso (autentificación). Esto es tan viejo cómo que la cueva Alibaba ya tenían un password
Pero ahora podemos hacer algo mejor que tener una sola puerta para la cueva, podemos tener sistemas de autorización robustos:
En este último punto es donde se suele pinchar si la empresa tiene cierto recorrido: es complicado entender que hay actores no humanos, que, de hecho, son los más importantes, porque como dice Vicki Boykis, los humanos estamos para dar significado a los datos, para procesarlos ya lo hacen mejor las máquinas.
[1] Evita como puedas dar acceso a la base de datos de producción, por mucha prisa que tengas.
Una metrica fundamental (*) que cualquier equipo de desarrollo/producto (bueno, en realidad toda la empresa debería estar involucrada aquí) debe medir y mejorar es el tiempo desde que un cliente tiene un problema hasta que ese mismo cliente deja de tenerlo.
Parece una metrica tonta, es facilísima de medir, basta con tener un tracker de issues e ir cambiando los estados a medida que la fases (reporte, evaluación, fix, deploy, test, close). Sí, esto es el peñazo universal, pero también lo era ponerte el cinturón de seguridad al montarte en el coche ahora no puedes avanzar un metro sin él puesto.
Una de esas fases es el deploy, es decir desde que tu código está en el control de versiones, hasta que llega a estar en producción.
Nadie ya discute que ese es un buen procedimiento, que debe estar automatizado y responder a cambios en el repositorio.
Vale, ahora imaginad que retrocedemos 20 años en la época en la que había un servidor FTP donde unos ficheros PHP era ejecutados por apache. O incluso unos scripts corriendo por CGI (las lambdas de hace unos años, para los milenials)
Imaginaos editar directamente esos ficheros en producción, es decir, cuando guardas en el editor la siguiente request ya usaría el nuevo código.
Obviamente hay muchas razones para no hacer esto, pero así se hacia hace años y es el en lo que tienes que pensar cuando tu deploy tarda 30 minutos: el baseline son unos milisegundos, así que todo lo lejos que estés de milisegundos lo estás haciendo peor que hace 25 años.
Digo obviamente pero yo no tengo tan claro que las herramientas actuales de desarrolladores no sean “caballos más rápidos” y no coches como diría Ford. Lo mejor que he visto últimamente en esta línea es esto y glitch, que está empezando de juguete pero “ojo lluvia” que viene de gente que sabe como hacer producto web. Pero este tema da para otro post.
Nos hemos acostumbrado a que las cosas vayan lentas a cambio de unas promesas que, en muchos casos, no son ni media verdad.
(*) Si tienes un equipo de desarrollo mediano (+10) la métrica TTF (time to fix) es un driver buenísimo para mejorar la calidad del desarrollo. Y además si eres CTO te sirve como métrica para poner en el excel para los inversores (que siempre es un peñazo encontrar buenas métricas)
Había visto ya hace un tiempo gente publicando imágenes con el hashtag #pico8 y me habían llamado la atención pero nunca me he parado a ver de qué iba y no sé si es nostalgia pero estoy enganchado.
Básicamente es una consola virtual, con sus cartuchos virtuales con un par de peculiaridades: el developer es first class citizen y las restricciones son muchas, por ejemplo, tienes una paleta de fija de 16 colores, el tamaño de la pantalla es 128x128px (hay favicons más grandes) y un máximo de tamaño de juego de 64kb. Solo hay que echar un ojo al cheatsheet
Y esto hace que como producto sea espectacular. Tiene todo lo que necesitas para hacer un juego (lógica, sprites, mapas, efectos de sonido y música (*)) en el mismo sitio, te permite hacer virguerías, pero te las restricciones te obligan a hacer las cosas super sencillas.
Nada de complicaciones, con esos recursos tienes todo lo necesario, eso sí, crear, modificar y usar esos recursos en el juego es muy muy fácil, así que las limitaciones se convierten en una ventaja.
Cómo plus tiene un halo retro y una filosofía del software noventero preinternet que hace echar de menos la época de cuando el software lo hacía gente en otra liga.
(*) Si te interesa la generación de audio procedural escribí un artículo hace unos 14 años sobre como generar audio en demos de 4kb.
TLDR: nowadays any software service depends on others. The problem is your data ends up being distributed and there is no easy way to join those different sources easily. I’m proposing a “joinable API” to fix that problem.
We have been talking about the vendor lock-in for years, where once you start using a provider it’s nearly impossible to move to a different one. I think the software world is like that no matter the software you use: once your software is running on production changing it is a really expensive and painful task.
Before the explosion of SaaS providers we had data exporting tools so you could more or less get your data in a standard format and import to another system. Today that’s not totally true: try to get all “your data” from your google analytics account. Don’t worry, those providers have tools that can access your data easily.
10 years ago was easy to see a monolithic services running on just one big machine with everything needed in there (user management, accounting, the service itself) today you start a company and the one week later your software is talking to several services through HTTP APIs.
That’s good, you spend your time in the thing you provide more value instead of doing billing code.
Eventually, someone will ask a question like “hey, how many users do we have in our XXXX tier, have signed up 3 times during the last month and also have ….”
So you either 1) use a platform that collects everything or 2) a one that fetches data from all those services and put data in a place you can query. in any case, querying data from a third party services is a pain. Here is the point where a lot of scrapping and “CSV file transfer” horror stories start.
Most of those operations are what we call joins. It’s easy to do when all the data is in the same place but hard to do in a distributed system.
So how do we keep those services and at the same time the possibility of using our data? why don’t we request to our service providers to have a Joinable API apart of full, easy to use and documented data dumps and their regular service API (more on this in this excellent talk)
Let’s imagine you have a regular OLTP database like Postgres, it’d be nice to be able to do:
SELECT * FROM MyTable
JOIN Service('billingservice.com', 'transactions')
ON ...
WHERE date = yesterday() ...
fetching remote data is already supported by Postgres using FDW (and all databases have a way to fetch remote data) but the problem is getting the data from the service.
The service would need to provide:
This is what most of the distributed databases do, it’s not rocket science, a common well-tested pattern that every single service should expose so you don’t have data lock-in.
El modelo de datos cambia sí o sí, básicamente porque modelan la vida real y la vida real cambia. Mucho.
Todas las bases de datos series tienen mecanismos para cambiar la forma de los datos. Es muy simple añadir una columna, cambiar el tipo o el nombre. Hay algunas incluso que el cambio es la constante como las orientadas a documento.
Dado que van a cambiar queremos:
Esto es más o menos trivial a nivel de gestión, lo complicado es saber cuando los datos han cambiado. Parece fácil, pero no lo es, a menudo los desarrolladores cambiamos el modelo de datos, el interfaz del API sin tener en cuenta todos los sistemas afectados.
Hay dos cambios fundamentales (bueno, seguramente más, pero estos son los peores) que se pueden producir en los datos:
En ambos casos debe haber una diferencia clara.
La clave del asunto es no afectar a los sistemas que dependen de estos datos (si es posible). Si por ejemplo, se añade una nueva columna o atributo, es fácil hacer que los sistemas que beben información sean compatibles.
Si pasamos de millas a kilómetros es fácil que la mayoría de sistemas se vuelan locos. Tenemos dos opciones, o cambiar todos los sistemas que dependen de mis datos o expongo mis datos a través de un API en el que pueda multiplicar por 0.62 los datos en millas y por 1.0 los de kilómetros.