javisantana.com · rss · rss resumen semanal

Micro

Esto es un pequeño blog (2 minutos de lectura por post), sin ruido, sin distracciones donde escribo las cosas que me gustaría leer. Recibe un correo cada fin de semana con las actualizaciones y "comentarios del director"

Licencias de software

Hace unos meses me escribe de una empresa para echarles un cable para entender si Clickhouse tenía sentido en su plataforma. Para los que no me hayáis escuchado hablar de Clickhouse (y es raro) es una base de datos analítica, no muy conocida, que tiene la mejor tecnología de datos que he visto en años, desarrollada por Yandex, el Google ruso (y este dato es importante para el devenir del post)

Los rusos son gente hecha de otra pasta a nivel de desarrollo. Mi impresión es que son así de bestias por su formación matemática heredada de la cultura que se forjó en la unión soviética (*) (a la fuerza, pero no entraremos en el cómo). Y este párrafo es pura percepción personal probablemente influída porque últimamente hablo con algunos rusos muy listos, pero seguramente sean tan buenos como los españoles :)

Si echas un ojo al software que usamos todos los días hay algo ruso de por medio. Usas postgres? algunos índices están hechos por rusos, nginx? Creado por un ruso, usas Google? El algoritmo de indexación lo creo un tal Sergey Brin… coge cualquier gran proyecto open source, mira las contribuciones y siempre hay rusos. Compáralo con las españolas (teniendo en cuenta que Rusia tiene 3x población)

Al tema, esta empresa de la que no diré el nombre, pero con un equipo técnico de los más interesantes del panorama startup español, baraja resolver el problema con Clickhouse (entre otros) con un criterio exclusivamente técnico: buscan arreglar el problema con la mejor solución. Pero a la semana del primer correo me escriben de nuevo diciéndome que algunos de sus clientes les habían comentado que usar Clickhouse es un “no” por ser ruso (también hablaban de software chino) y por tanto su proyecto tendría que ir por otro camino con la consecuente consternación del equipo.

No soy abogado y seguro que tienen razones legales o de cualquier otro tipo buenísimas para hacer eso, pero también sé que esos clientes deberían buscar asesoría técnica inmediatamente.

Lo habitual es que cuando tienes una empresa de VC detrás estén muy preocupados por un “exit”. Una de las cosas que podría joder un “exit” es la propiedad intelectual del código, imaginate que has usado código de vaya usted a saber quien y cuando vendes tu empresa reclamen su parte, por eso una de las cosas fundamentales que miran es si tu código usa librerias con licencias virales (cómo GPL) o restrictivas. O incluso uses código sin licencia de un menda de GitHub (ahora entenderás el porqué mucha gente pide en tantos repos poner la licencia). Aquí hay una lista de cosas que un VC suele mirar en una due diligence

Pero no veo que “liability” podría causar un software, código abierto, con licencia Apache 2 por mucho que detrás esté Yandex. Detrás de todo gran producto open source hay una gran empresa. De hecho el modelo mongo o elastic es mucho más peligroso ya que son empresas con grandes cantidades de dinero VC que viven exclusivamente de ese software (al contrario que Yandex), y ya sabéis, cuando empiezan a apretar las ganas de ganar dinero el VC ya no es tan divertido y a veces se estira demasiado la cuerda (que se lo digan a meetup.com)

Pero cabría la posibilidad de que estos rusos metieran, ordenados por su gobierno, unos caballos de Troya en su código. Podría, pero la historia reciente nos dice que es más fácil que llegue por un módulo npm o un ataque dirigido (que se lo digan a Everis) y que no hace falta que sean rusos. Podría ser un “huawei” pero no, el código está disponible y no hay un control global, no hablamos de un despliegue para analizar datos en la NSA (he estado leyendo a Snowden últimamente)

Aún me pregunto qué puede pasar por la cabeza de esa gente. A mí me daría mucho más miedo pensar que mi startup tenga los passwords en 1password después de la ronda de $200M a que parte de su stack sea un software open source, escrito por unos rusos brillantes fuera de la politica de la gran empresa donde fue creado (si no es imposible que hubiesen construido algo de tanta calidad). O quizá me preocuparía más que tengan que ir a por una solución cloud, de peor calidad (**) por la cual quizá tengan que doblegar en unos años (que se lo digan a los bancos con HP, IBM u Oracle)

Me desmotiva mucho cuando el dinero puede a la razón. Tal vez en este caso estas empresas tengan poderosas razones pero solo se me ocurre algo tan oscuro que pueda entrometerse en estos temas: la política, empresas del gobierno y al hilo por la “opinión pública”. Como en cualquier tema últimamente puede mucho más la información superficial, posiblemente hidratada con algún que otro bulo, que la capacidad para buscar fuentes de información veraces y con criterio. Si alguien dice que el software ruso es malo, lo será.

Por mi parte seguiré usando software ruso, chino (mirad la lista de contribuciones a tensorflow) o español, si hay una cosa bonita en el software es que nos pone a todos al mismo nivel, no importa si es alemán, español o ruso, escrito por un hombre o una mujer, un alto o un bajo, lo instalas porque te funciona y resuelve un problema.

Bonus track

Estos días estoy escuchando el podcast de inteligencia artificial de Lex Fridman, el amigo no es el más dicharachero, pero las conversaciones son interesantes. Concretamente me ha encantando la primera media hora de conversación sobre lenguajes de programación con Jeremy Howard, fundador de fast.ai

(*) echa un ojo a la lista de matemáticos rusos Especial mención a la cantidad de mujeres en la lista.

(**) Clickhouse está fácilmente 3-4 años por delante de cualquier tecnología cloud hasta que llegue lo nuevo de Google, Procella.

· #

Los fundamentos

Día a día nos pasamos en la oficina de Tinybird (amablemente proporcionada por Google Campus) discutiendo sobre cachés, índices de base de datos, optimización de lectura en función de la compresión, como funcionaría el sistema en distribuído en función de que datos… nos gusta entender como funciona incluso aunque no sea totalmente necesario.

El 99% de negocios les importa poco ese tipo de cosas, y así está bien, con saber que instalando el framework y usando su API lo tienes solucionado o usando la receta es muchísimo más que suficiente. Hay cientos de miles de negocios que no saben lo que corre por debajo de lo que usan y así debe ser. A nadie se le ocurre tener que saber como funciona un coche para poder conducirlo. De hecho la humanidad no avanzaría si esto no fuese así, nos basamos en el conocimiento que otros ya concentraron.

Pero eso no evita que no tengamos que volver a los fundamentos de vez en cuando. El otro día di un taller de fundamentos de visualización de datos. Mucha gente al principio esperaba empezar a usar “ponga aquí su herramienta” pero no. El curso era de cuales son los conceptos básicos de percepción humana para entender como representar los datos. Por ejemplo, saber que un pie chart es una aberración en la mayoría de casos se entiende perfectamente explicando las bases y 2 ejemplos.

La diferencia entre enseñar a hacer visualización de datos y enseñar los fundamentos es como dar el pescado o enseñar a pescar. Aprender a aplicar los conceptos requiere tiempo, repensar mil veces, equivocarse otras tantas hasta que eres capaz de interiorizarlos y de asentarlos en base a sacar la esencia de cada ejemplo.

Pero no creo que nadie pueda hacer nada realmente bien sin entender las bases. Nadie puede hacer bien ML sin entender las matemáticas que lo fundamentan, no se puede conducir bien sin conocer principios de física de un coche y no se puede hacer bien una query a la base de datos sin saber como funciona por debajo. El problema es que es mucho más sencillo y da más beneficio usar las recetas que en la mayoría de veces funcionan. No habéis visto esos departamentos de marketing ó desarrollo haciendo todo exactamente como viene en el manual sin pensar realmente lo que están haciendo?

Así que cada vez que veo alguien que se entretiene en mirar qué hay debajo, especialmente en el mundo del desarrollo, me da una señal de que esa persona posiblemente sea una buena candidata a ser unos de esas soñados “10x”, de las que en un momento de los delicados te va a sacar del agujero, de las que saben que siempre hay una buena solución (y saben el porqué a veces hay que escoger la mala)

Nunca en mi vida me he arrepentido de haber invertido tiempo en entender como funciona algo, de hecho es posiblemente las mejores inversiones a largo plazo que he hecho. No hay que ser un 10x para hacerlo, ni si lo haces no te convierte en superhéroe, pero necesitamos gente que lo haga.

Bonus track

Relacionado con lo anterior esta charla donde explica como muchas de las cosas que damos por asumidas sobre el rendimiento del hardware actual, no son ciertas y solo basta con mirar lo que hay debajo. En esa línea el famoso You are doing it wrong del creador de Varnish.

· #

El complejo del corporate

He sido muy muy crítico con el corporate durante mi vida profesional, lo sigo siendo, pero últimamente al mismo tiempo trato de entender el porqué están donde están. Después de todo no se consigue facturar cientos o miles de millones de un día para otro por un golpe de suerte.

El corporate sigue teniendo cosas malas no, malísimas: software de pésima calidad (la mayor parte de veces externalizadas) miles de personas que no saben nada y a las que lo de la transformación digital les suena a chino los cuales están normalmente “amparados” por convenios laborales (a pesar de ello bajo ningún concepto eliminaría). Desde el lado startup es lo único que se ve y la razón por la que se menosprecia a la gran empresa.

Pero ojo, Facebook, amazon o cualquier otra empresa gigante (bueno, y cualquier startup de 200 personas) son tan corporate como el más corporate español. No nos engañemos, tienen la ventaja de 20 años menos de legacy, pero los problemas convergen cuando hay muchas personas haciendo lo mismo.

Pero no he venido aquí a hablar de lo que todos ya nos hemos quejado, quiero hablar de esa gente que son los que sacan adelante el trabajo, los que, a pesar de miles de reuniones absurdas son capaces de crear software y hacer esa herramienta que todo el mundo usa y que todo el mundo quiere sustituir por “lo nuevo”.

No hay vez que hable con alguien que trabaje en un corporate español que no te cuenten la historia de un proyecto increíble, que todo el mundo usa pero del que no se habla con orgullo, siempre son “unos cuantos scripts ahí corriendo”. Y aquí es donde fallamos, esos “scripts” que dan servicio a miles o a veces millones de personas son el comienzo de algo. Pero nos quedamos ahí, en cuanto tenemos una solución que funciona tendemos a pensar que es mala. Y lo siguiente es pensar en mantenerla ahí y luego ya haremos el megaproyecto que lo haga “bien”. Esos megaproyectos casi nunca salen bien y finalmente se termina haciendo otra solución que tampoco cumple para no quedar mal. No nos damos cuenta que no es posible hacer algo “bien” sin tener experiencia previa?

Echad un ojo a la historia de React y veréis que empezó como “unos Javascript para resolver una parte”. Pero no se quedaron ahí, avanzaron, lo dieron cariño y han hecho de React un standard. Es un caso especial, pero fijaos en los miles de ejemplos que estos neo-corporates sacan todos los años, dan charlas sobre ellos… ahora, cuantas charlas habéis visto de “"”ponga aquí tu corporate favorito español”””, creéis que son tontos y no son capaces de hacer nada decente, o que realmente falta ese empujón para creerse que haces algo bueno, digno de ser expuesto (y de paso mejorar la empresa en todos los sentidos)

Como en la mayoría de cosas en la vida la perseverancia es lo que hace a algo ser bueno, necesitamos ese cambio cultural que haga que dejemos de pensar en que las cosas son para salir del paso y pensemos que el dorado llegará y pensemos que el dorado se construye, que esa gente que ha construído esa solución que te ha sacado del apuro seguramente haya aprendido y pueda iterar. Y cuando termine la siguiente iteración pueda iterar de nuevo y tal vez generalizar y seguramente empezar a hablar de ello públicamente.

· #

Cómo elegimos la tecnología en Tinybird

Creo mucho en que la mayoría de empresas de tecnología deberían empezar con un servidor de 30€ al mes, con un stack basado en PHP (o unos ficheros HTML y algo como firebase) y en el que el equipo técnico, trabajando mano a mano con negocio, vaya editando directamente en producción hasta tener market fit. Rompe absolutamente todas las buenas prácticas, pero es interesante recordar dos cosas:

1) Tarde o temprano tirarás el primer código (así que cuanto antes mejor)

2) Lo que importa es validar que el negocio tiene sentido no que eres el que mejor arquitectura tienes. Un buen técnico se define también por saber cuando NO invertir tiempo en algo.

Así que todo lo que diga en las siguientes líneas cógelo con pinzas porque ni yo sigo mis propios consejos.

La tecnología acompaña a la empresa

La mayoría de las decisiones tecnológicas que hemos y estamos tomando vienen dadas por la experiencia en CARTO, sobretodo la última fase que viví que fue el cambio hacia B2B. Así que, dado que Tinybird es una herramienta también 100% B2B, de bajo nivel (plataforma) y orientada a trabajar con datos hay una serie de cosas que tuvimos en cuenta antes de arrancar(*):

  • La integración es una parte del negocio (como una gran parte del negocio B2B) así que el producto se piensa desde el API
  • Es posible que necesite correr onpremise.
  • En cuanto al equipo, el tipo de perfil técnico no es el típico programador de framework, este producto necesita de gente que le guste el bajo nivel y saber como funcionen las cosas, así que de entrada nos olvidamos de seguir las (en la mayoría de veces absurdas) corrientes del desarrollo “moderno”
  • No tenemos un equipo de 10 personas, así que tenemos que usar tecnología existente.
  • El equipo de ventas y marketing es posible que tenga que ser tirando al lado técnico (igual que soporte). Dicho de otro modo, tiene más sentido tener “tech evangelist” haciendo pruebas de concepto y escribiendo post técnicos que gente llamando a puerta fria.

Algunas de las decisiones

Aquí algunas de las decisiones, sin un orden muy definido, la mayoría de ellas bastante dogmáticas.

Nada de servicios externos. El onpremise es algo que va contra el “sentido común” de un producto SaaS pero a veces ciertas empresas no quieren (o pueden) sacar datos de sus servidores. Y Tinybird es una herramienta que en muchos casos tiene que vivir cerca del origen de los datos. Piensa en tinybird como un nitro para tu base de datos actual, así que tiene que colocarse allí donde haya que acelerar. Esto nos da una ventaja competitiva con respecto a Big Query o Redshift (además de otras muchas que iré comentando en siguientes entregas)

No usamos ni un solo servicio externo, todo funciona en un portátil sin conexión a internet. De hecho una cosa que te permite no depender de servicios de amazon/google/azure es que puedes montar tu producto sobre hardware de verdad. Otro ejemplo de esto es Algolia que decidió usar servidores “de verdad” y aquí explica muy bien las razones. De hecho el poder hacer esto añade una capa de seguridad (nosotros separamos los datos de los clientes de forma física) también muy bien acogida por el corporate. Y obviamente todo mucho más barato que en la nube.

Tenemos que empezar a perder el miedo a explicar que debajo de nuestros servicios hay servidores y recursos finitos cuando los servicios son basados en recursos.

Lo más sencillo posible: relacionado con el anterior, nada de kubernetes nada de miles de servicios. No significa que en la parte SaaS no podamos usarlos, pero evitándolos siempre que se pueda. La aplicación tiene el código para el aprovisionamiento, deployment, tareas como backups y mantenimiento y toda la parte de frontend.

Obviamente solo un repo (salvo una extensión que haremos open source), no creo que tenga sentido tener más de un repo salvo que casos muy específicos, al final tener diferentes repos, aunque suena muy bien, se convierte en un problema de gestión añadido y de integridad de tu sistema.

Todo concentrado en gitlab: repo, tickets, CI, testing. La documentación es el mismo repo. También tenemos el CRM y el blog en gitlab.

Número de dependencias mínimo, es preferible invertir 2 días de trabajo y saber lo que está pasando a usar la dependencia que encuentras en github. Solo usamos dependencias que o bien conocemos o bien hay poco riesgo de que sean un problema por no conocerlas. Se pide perdón cuando haces un commit con una dependencia nueva.

Ahora mismo la aplicación se instala con pip install tinybird.whl y se ejecuta con un tinybird_server. No necesita balanceador, es un solo proceso corriendo en la máquina, punto. Obviamente tenemos un balanceador para tener alta disponibilidad, pero no sería necesario.

Tampoco usamos base de datos al uso, el volumen de usuarios que esperamos no es algo, así que usamos un sistema basado 100% en memoria y almacenamos los datos o bien en disco o en redis (si hay HA). Para la parte analítica guardamos todos los eventos que se producen en la aplicación (obviamente en clickhouse para analizarlo con nuestro propio producto) De esta forma cumplimos con todos las requisitos de trazabilidad que suele requerir el corporate.

Y obviamente esto incluye dejar fuera a los frameworks y toolkits. Usamos las partes que nos interesan de tornado (un framework web muy sencillo) y React. Es cierto que el onboarding técnico se hace difícil encontrar gente, pero es que somos nosotros los que hacemos el framework, nuestro target son precisamente perfiles que les guste saber lo que hay por debajo del framework.

Por otro lado, en mi opinión los equipos de tecnología no escalan bien, este producto está pensado para tener un nucleo de personas muy pequeño (como, en realidad, casi todas las empresas, aunque no lo sepan) y tener los complementos orbitando (tanto en equipo como en tecnología)

La velocidad es clave, así que usamos C++ para las partes críticas (por ejemplo, la construcción de árbol de dependencias SQL o el parsing de CSV) y python para la capa de gestión y partes no tan críticas. Me asombra como la mayoría de las empresas pasan la velocidad por alto pero fijaos en trello, figma o notion

Al hilo de lo anterior y de que teníamos que partir de tecnología existente para acelerar el producto, usamos Clickhouse (una maravilla de la ingeniería). Como ya tenemos una edad para tirarse a la piscina sin mirar si tiene agua, antes de usarla me pegué 1 año estudiando como funcionaba, haciendo pruebas de concepto, probando si era viable contribuir al código, hablando con los desarrolladores y echandoles un cable con el diseño de la parte geospacial. Además, antes de arrancar monté unas charlas y asistí a otras tantas relacionadas con datos para ver como estaba el sector.

El testing: el máximo end to end posible y usando doctest para partes unitarias. Muchas veces la aproximación es prototipo con test mínimos, prueba y luego desarrollo de tests. Por otro lado invertimos más tiempo de testing en lo que consideramos que tiene más valor.

Insistimos mucho en metricar y tener las partes críticas bien medidas. Cuesta poco y así probamos nuestra propia plataforma.

Luego hay otros temas como por ejemplo, no tenemos sistema de usuarios interno, siendo realistas, te ahorras un dolor tremendo en la gestión de usuarios y cualquier empresa va a quererlo integrado con su sistema de autenticación. Quieres además estar integrado con su sistema para eliminar barreras a que más usuarios usen la plataforma.

En general intentamos entender bien lo que usamos, que además sea lo más robusto/probado posible, simplificar todo lo que se puede (teniendo en cuenta que un sistema de datos de por si es complejo) y mantener la burocracia en mínimos pero no tan mínimos que no permita escalar el equipo.

(*) el primer commit es de Febrero de 2018

· #

Fyre festival

El otro día veía Fyre en Netflix, un documental sobre un festival de música muy bien vendido pero muy mal ejecutado que resultó ser un desastre.

A medida que van pasando las entrevistas a la gente involucrada tenía una sensación familiar, la típica de “estoy metido en un agujero del que sé que no se sale”. Los que trabajamos haciendo en vez de pensando en hacer sabemos perfectamente de qéé hablo. Tenemos ese sexto sentido de “esto no se puede hacer” que a veces nos falla pero cuando da fuerte de verdad, lo sabes.

En mi vida he estado en algunas de esas, pero recuerdo dos, una de ellas hace 15 años donde un lunático pensó que se podía hacer un sistema de domótica en un par de semanas y todos fuimos arrastrados allí. La segunda, de la cual fui además parte de los iluminados que vendían el sueño (y posiblemente el más culpable porque sabía que no era posible), fue en CARTO cuando decidimos que en 6 meses se podría reimplementar el 80% de los construído en años y además añadir más features.

Esto no es un consejo para todo el mundo, pero si volviese atrás, en las dos ocasiones, me hubiese ido de la empresa. Aún sufro consecuencias del peaje que pagué por aquello, en ningún caso me ha merecido la pena, ni he aprendido nada (bueno, aprendí que nunca más lo volverás a hacer) y no guardo ni un solo buen recuerdo. Y lo peor, de largo, arrastré a personas al lodazal.

Afortunadamente teníamos un equipo que supo sacar aquello con unos cuantos meses de trabajo (los que hubiese costado en realidad hacerlo) y mucho esfuerzo. Hay veces que lo de tener un equipo que no te mereces es literal.

En el documental se ve como muchos profesionales abandonan el barco cuando vieron el percal.

Lo triste es que el mundo de software está aún poco profesionalizado y sigue pasando, pero imagino que llegará el día donde los técnicos de este sector seamos capaces de argumentar con algo diferente a rabietas.

Esta semana

Esta semana he terminado mi serie sobre el Data Lake. El Data Lake es algo así como el Fyre festival de los datos, suena perfecto, pero es un trabajo de años, para el que necesitas una cultura de empresa MUY técnica y que incluso así es complicado.

Lo he escrito más pensando en ser una guía para aquellos que estén pensando en centralizar todos los datos que piensen el arco de iglesia que van a montar y si de verdad les da beneficio.

Siempre he pensado que la única forma de aislar lo suficiente a zonas de una empresa es productizar y eso incluye el acceso a los datos. Y dar acceso a Tablau desde fuera de tu equipo/departamento/area a tu base de datos interna no es productizar ni democratizar el acceso a datos, es buscar dependecias externas que limitarán tu avance.

Por aquí la penúltima entrega, las conclusiones y el índice en formato micro libro

Bonus track

Posiblemente ni te interesen los coches ni la mecánica, pero me gustaría que pudiesemos hablar de tecnología con la pasíón que este hombre habla del primer coche tracción delantera que bajó de 9 segundos en el cuarto de milla (un coche de calle potente tarda entre 15 y 17 segundos en hacer 402m)

Tener claro lo que se quiere conseguir, mostrar sin tapujos qué decisiones se tomaron para resolver un problema en vez de darle a la palanca del marketing y tapar lo que realmente es interesante (en el video la limitación del data logger), hablar de los problemas que encontraron por el camino (la suspensión delantera), los problemas que no resolvieron (las roturas de la transmisión en la salida), etc, etc. son las cosas que me gustaría ver en nuestro día a día.

Todo el canal de este señor es brutal si te gustan los coches.

· #

Tinybird, mi visión personal

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.

El porqué

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)

Volvamos al qué

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.

Bola extra: hablando de gente que hace las cosas bien

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.

· #

Las matemáticas

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.

La charla de la semana

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:

  • Corta, concisa, explicando claramente lo que hacen con redis. Por otro lado técnicamente usa redis para algo que tiene muchísimo sentido, es simple y brillante. Llevo usando redis desde 2011 y es difícil encontrar software tan útil, simple y rápido.
  • Es capaz de dar una charla de algo interno sin contar absolutamente nada de lo que hacen. Corporates, ya sabéis :)
  • Fuera hype o títulos gilipollescos.

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.

· #

Resumen semanal: Carmack

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

Qué he estado escribiendo esta semana

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í.

En qué estoy trabajando

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.

Extra lap

Si vas a leer algún link de esta lista, que sea este post de Feli, “tengo cáncer

· #

Brain power

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:

Cloud computing

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).

User testing

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.

Conducción autónoma

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,

· #

Resumen semanal: cómo testear un producto

Data Lake, parte V: Autorización

Nadie en su sano jucio da acceso a todos los datos de su empresa a todos sus empleados.

Estoy escribiendo una serie de posts con algunos de mis experiencias sobre los famosos data lake que es lo que a mi me hubises gustado leer cuando escuché por primera vez el palabro “data lake”. Esta es la quinta de siete.

Cómo visualizar los datos de contaminación de Madrid en menos de 30 lineas de javascript.

O cual es el ciclo de testing de un producto en desarrollo by Santana. En el producto que estamos desarrollando es muy importante que el ciclo de trabajo habitual funcione como la seda.

Y para que funcione como la seda hay que probarlo, depurarlo, volver a probar, sufrir los problemas… y eso no puede hacerlo una máquina, por mucho que nos empeñemos una máquina “no puede” probar algo que un humano va a usar, de ahí que si estás haciendo un producto software, deberías pensar en tener un ciclo de testing manual en el que toda la empresa lo pase.

En este caso lo que hago es hacer un ciclo completo de prueba del producto, con dos objetivos:

  1. Probar que la versión del producto va bien. Intento probar con diferentes casos cada vez.
  2. Poder verme a mi mismo usando el producto. Es igual que escuchar tu voz grabada, nunca es como la escuchas desde dentro.

El video, por aquí

· #