Cuando hablamos con alguien con cierta experiencia en el mundillo startup y nos pregunta, después de un rato de conversación “bueno, pero qué queréis conseguir con Tinybird”. Hay muchas posibles respuestas standard en el mundillo en el que nos movemos: “venderla”, “hacer de ella un unicornio” o cualquier empresarial-motivacional.
Pero la cara se les arruga cuando dices: lo que queremos es trabajar juntos de la forma que mejor sabemos, hacer algo que las empresas necesiten, crear un negocio sostenible, con una buena base tecnológica que aporte valor y como resultado ganar dinero. Lo que viene después, como en el 100% de las empresas, nadie lo sabe por mucho que nos empeñemos en buscar fórmulas e indicadores para argumentar lo que básicamente viene a ser una apuesta (un muy bien artículo relacionado sobre la inversión).
Quizá deberíamos entrenar el pitch de vamos a liderar el sector de vaya usted a saber pero no hacen falta grandilocuencias ni adornos artificiales para hacer un buen producto.
Al grano, qué leches hacéis en Tinybird? hacemos dos cosas, un producto y el complemento que casi cualquier producto necesita:
Un producto que permite exponer una gran cantidad de datos como un API. Esto es, desde que tienes un puñado de CSV con cientos de Gb exportados de vaya usted a saber donde, hasta que lo consumes un API bien estructurada en menos de cientos de milisegundos.
Consultoría de analítica de datos (usando nuestro producto sobretodo). Leer “consultoría” suele ser sinónimo de “algo estás haciendo mal”, ya sabéis, lo dicen todos los VC (haz producto, tienes que hacer producto) y todo los neo-filósofos te dicen que no vendas tu tiempo, pero no veo mejor método para ponerte en la piel de los demás que entender y ayudar a resolver sus problemas usando tu punto de vista y experiencia. Para mi la consultoría también es parte del producto, por eso estamos diseñando el proceso que nos permite abordar este tipo de proyectos de una forma sistemática.
Por suerte el sector de la tecnología lleva unos años en la gloria a nadie se le escapa que se puede vivir bien si estás dentro del mundillo y no falta trabajo. Esto es, puedes, ahora mismo, trabajar en una empresa con todas las comodidades, un buen sueldo, sin realmente matarte a trabajar y con retos intelectuales interesantes. Es el escenario soñado.
Y así estaba yo, en un corporate, con ciertos privilegios y con una cómoda jornada de 9 a 5. Quien es el iluminado que me manda a mi dejar ese status quo para meterme en camisas de once varas, no me jodas.
Tiene una explicación sencilla. Hay dos cosas que valoro por encima de los privilegios y el dinero: hacer las cosas como yo quiero y poder trabajar con la gente con la que comparto algo más que oficina. Y esto lo he aprendido a base de confundirme unas cuantas veces y darme cuenta que no todo el mundo está hecho para según que sitios.
Dicho esto, nada tengo en contra de los trabajos 9-5 y ni el corporate (no siempre ha sido así) donde he aprendido muchísimo en un año, sobretodo a respetar ciertas cosas que son difíciles de ver pero que los mantienen vivos y coleando (esto lo dejo para otro post)
Por otro lado tengo en mucha consideración a las personas que aprovechan lo que saben hacer bien, y creo que uno de mis fuertes es hacer sistemas que saben hacer bien la digestión de los datos… puede que llevar 10 años haciendolo tenga que ver. Me mataría dejar de hacer algo con lo que he disfrutado y disfruto.
Qué mejor manera de aprovechar lo que sabemos que haciendo un producto que resuelva algunos de los dolores que hemos pasado durante los últimos años y que vemos todos los días en empresas que trabajan de una forma u otra con datos.
Resolver un problema bien, usando la que consideramos la mejor tecnología para hacerlo, haciendolo con un standard alto de calidad y seriedad, guiado por la necesidad de resolver ciertos problemas y provechando al máximo el conocimiento acumulado gestionando datos en empresas por las que hemos pasado. Y además, hacer todo esto siendo lo más feliz posible y divirtiendose con cada milisegundo que optimizas extrayendo información de los datos. Eso es Tinybird.
Y esto requiere una cantidad de trabajo y esfuerzo que a medida que te haces mayor cuesta hacer. Sí, cuesta trabajo, en mi caso sacrifico horas de otras cosas que me gustan, pero hacer las cosas como crees que hay que hacerlas tiene este tipo de cosas. Sarna con gusto no pica dicen en mi pueblo.
Al hilo del comentario anterior sobre la gente que sabe hacer las cosas bien y las aprovecha, estoy siguiendo muy de cerca la creación del Instituo Tramontana, especialmente el programa en dirección de producto que imparten dos buenos amigos.
Pero no es solo el contenido del programa, es todo lo que está alrededor del curso, el espacio la solemnidad del programa, las referencias a libros y contenidos con tantos años como calidad (uno de mis propósitos de este año era no leer libros con menos de 30 años, que como todo propósito, he incumplido) y la dedicación con la que están preparando todo. Os recomiendo seguir la lista de correo de Javier, el directo del instituto, donde va contando algunas cosas relacionadas y otras que no, pero que dan contexto.
Tengo un recuerdo agridulce de los problemas de matemáticas de la escuela: todo lo sencillo que parecía cuando veías a la profesora resolverlo paso a paso pasaba a ser un mar de dudas cuando te enfrentabas al problema tu solo.
Añadía más frustración el pensar que lo habías entendido perfectamente.
Lo que no sabias era que la profesora había hecho miles de veces problemas como ese, tanto que podía hacerlos mientras los explicaba.
Cuando leo un blogpost sobre cómo la empresa X resolvió Y, ya sea usando microservicios, tal base de datos o cuál metodología, y que además el problema se igual parecido al mío, me pregunto si no será mi profesora de matemáticas convertida en desarrolladora. Me pregunto si no será mucho más complicado y no habrán pasado miles de veces por ahí. Y entonces me pregunto si yo tengo tiempo de pasar miles de veces por ahí.
Por otro lado no hay cosa más divertida que enfrentarte a algo nuevo, es realmente la única forma de entender algo que ya has entendido.
En este mundo donde las conferencias se han covertido en en fin (y no como resultado de hacerlo bien) para conseguir leads, en donde la calidad brilla por su ausencia, donde un título “catchy” vale más que plasmar años de trabajo en una charla, da gusto encontrarse con maravillas como esta. Y me ha gustado por varios motivos:
No hay mes que no piense en organizar una pequeña conferencia donde la gente venga a contar la verdad del día a día sin miedos, a explicar cómo hacen esto o aquello, o como resolvieron lo de más allá usando el hack más absurdo.
No es noticia que Carmack es uno de mis programadores favoritos. Gracias a él aprendí muchísimo leyendo el código de Quake (especialmente el 2), escuchando sus maravillosas master class en las quakecon y leyendo maravillas como esta, cuando se fue una semana aislado a aprender machine learning. La forma en la que “locuta” me hipnotiza.
Hace pocos días le han hecho una entrevista en un podcast bastante conocido (que no conocía). La entrevista es tan larga como interesante (puedes encontrar resúmenes por ahí), así que da para hablar de bastantes temas: VR, redes sociales y sus problemas, el tema sobre cuantas horas hay que trabajar, coches, videojuegos… en todos ellos su visión es muy muy sensata aunque creo que el hecho de trabajar en Oculus (comprada por facebook) le hace tener una posición un poco sesgada sobre lo que la cúpula de facebook piensa.
Dejando a un lado esa posición sesgada y que está maravillado con su Tesla… hay dos temas que me han llamado la atención poderosamente:
El primero es cuando habla sobre la cantidad de horas que trabaja. Comenta que él solo puede ser productivo 13 horas al día… últimamente ha habido una gran cantidad de comentarios sobre este tema dando recomendaciones sobre cuanto trabajar. En mi vida ha habido periodos donde he trabajado 10-12 horas al día y no los cambiaría por nada. No es sostenible ni para todo el mundo, obviamente, y cada periodo de la vida tiene diferentes prioridades, pero en mi opinión es complicado ser muy bueno en algo si no inviertes una buena cantidad de horas. De ahí que esté un poco de acuerdo con Carmack aquí sobre que cada uno elija libremente las horas que puede o no trabajar (sabiendo, eso sí, que hay vida necesaria más allá que el editor de código)
El segundo, y más importante, es cuando habla de la velocidad de computación
Las máquinas están empezando a ser más lentas, no en absoluto, pero la velocidad a la que la velocidad crece ha bajado dramáticamente. Y el punto está en que, según carmack, los móviles están llegando al límite de lo que pueden dar.
Como derivada, y esta es la parte más llamativa, habla de un cambio cultural, tenemos que empezar a volver a pensar en el performance. Y no es el único, cada semana veo varios artículos sobre como la web está a rebosar de código que hace que vaya lento en todo lo que no sean móviles de última generación. La gente ya no sabe que pasa debajo del código que hace (React, te estoy mirando a ti) y en general se tiende a pensar que con levantar unas cuantas máquinas más en AWS resuelve todos los problemas. Aquí una charla de otro de mis favoritos, hablando precisamente de como el hecho de que los desarrolladores actuales no tengamos ni puñetera idea de lo que pasa por debajo es algo muy muy malo en un futuro próximo (un poco apocalítico, pero bueno)
No puedo estar más agradecido de haber empezado mi carrera profesional haciendo videojuegos, donde tener que refrescar millones de pixeles 60 veces por segundo hacía que el “performance” fuese un ciudadano de primera.
Hablaré más sobre este tema en futuros post
Este mes de agosto he escrito bastante pero he publicado muy poco, cosas de las vacaciones y que por otro lado dejo madurar los posts unos días para ver si pasan el test de la lectura después de una semana.He avanzado con mi serie de post sobre el data lake, en esta entrega la trazabilidad
Estoy escribiendo esta serie con dos objetivos: 1) Que alguien que se pregunte qué leches es un “data lake” lo sepa 2) Demostrar que un daka lake es una panacea y que no deberías hacer algo así.
Casi todas las bases de datos tienen sistemas para planificar como van a ejecutar una query en base a unas estadísticas sobre los datos. Suelen ser sistemas complejísimos y a veces tienes que saber como funcionan para optimizar bien las queries.
Clickhouse, mi base de datos favorita, no tiene un planificador (tiene algo muy simple, que dicho sea de paso simplifica todo el diseño), no obstante las queries se pueden ejecutar con diferentes parámetros. Estoy usando una aproximación diferente: en vez de calcular estadísticas de los datos y ver cual es el mejor plan, estoy ejecutando los diferentes tipos de queries con diferentes parámetros y entrenando un modelo de ML para luego saber cual es el mejor plan dados unos parámetros. De momento el modelo predice con exactitud el tiempo de ejecución (lo que me ha sorprendido gratamente).
El objetivo es integrarlo en Tinybird para los endpoints que tengas publicados. Publicaré los resultados en el blog de Tinybird
Hay aproximaciónes para usar ML en bases de datos, aquí un articulo brutal de como usar un modelo para sustituir a los índices tradicionales.
Si vas a leer algún link de esta lista, que sea este post de Feli, “tengo cáncer”
Hay dos momentos en los cuales quieres saber lo que está pasando en tu sistema: cuando lo estás integrando y sobretodo, cuando pasa algo malo.
Así que quieres saber qué, cuándo, quién y cómo.
Que ha pasado: alguien ha accedido a un dato, alguien ha metido datos, borrado, cambiado…
Cuándo se ha hecho lo anterior
Quién, que persona o que bot (y quién es responsable de ese voy)
Y cómo: por API, por web…
Pero no queda ahí, además de guardar toda esa información tienes que ser capaz de consultarla. Quién no se ha encontrado con 300gb de logs que hay que investigar cuando hay un problema.
Y ojo, no solo para los datos, también para los metadatos. Por ejemplo, cuando se le dio permiso de escritura a fulanito?
Tan fácil de escribir, tan difícil de implementar bien.
A veces creo que tenemos una capacidad de concentración finita y que cuando llegas al límite tu cerebro dice basta. Esta semana creo que he sufrido una pájara cerebral después de 3 días diseñando un sistema de analítica en tiempo real (con cientos de Gb/s y respuestas por debajo de los 150ms). Ya sabes, esos días en los que te alegras de haber caído en esta profesión y que por otro lado te preguntas si no podrías haber montado algo más sencillo y vivir tranquilamente 🤷🏼♂️
Al tema, esta semana he hablado de:
Hace no muchos años las personas en el mundo del desarrollo tenía que pelearse para conseguir ejecutar su software en máquinas muy limitadas de memoria. Hoy con máquinas 1000 veces más potentes en todos los aspectos, necesitamos cientos de ellas para ejecutar los servicios más triviales (en pro de una velocidad de desarrollo que no es tal). Y lo peor, no hay una buena solución.
Mi apuesta personal es que la mayoría de servicios que usamos (fuera de los google, amazon, facebook…) podrían correr sin problema en una sola máquina si hubiese un poco de inteligencia en como transferimos y procesamos los datos.
Aquí va el post
Al hilo de esto, pintesrest tiene 450 máquinas solo para su parte analítica, un total de $125M/año (imagino que contando todos sus servicios).
En tinybird hemos hecho unos tests con usuarios para entender como otras personas usan y entienden nuestro producto y hemos compartido unos números y aprendizajes en el blog
Una de las cosas que he vivido cuando tienes inversión de capital riesgo es que, como tienes dinero, hay ciertas necesidades cubiertas. Cuando esto pasa, dejas de entender cosas básicas, como saber quien te tiene que dar de comer. De ahí que una de las cosas que hemos decidido al empezar tinybird es hacer consultoría, que es el mejor user testing posible.
A mi me gusta conducir pero es obvio que el futuro no va por ahí (y me alegro en parte). Hay una competición de coches radio control autoconducidos en, adivina, estados unidos, donde hacen carreras por un pequeño circuito. Yo intenté empezar aquí un grupo similar, pero no cuajó (los grupos de react tienen más éxito)
Sin embargo, es super interesante ver como mejoran en cada carrera que organizan y ya están al nivel de un conductor humano. Aquí tienes los resultados y los trucos que usan,