This is a “technical” post that shares insights on a very specific problem.
The content is specific to PostgreSQL, an open-source technology for relational databases that we use (and love) at Alan.
CTE stands for “Common Table Expression”. They are the SQL constructs that allow you to create an “intermediary table” that you can then query later:
You may love CTEs for their readability. Processing steps are exposed linearly, in order, instead of the encapsulated vision you get with sub-queries. Names are first, like defining variables in a normal programming language…
Mais pas de panique ! Surtout, pas de panique. De toute façon, si tu lis ce billet sur Medium, tu es sans doute jeune et fringant, donc ta chance de contracter une forme sévère du COVID est infime.
Ma prédiction: plus que l’Asie ou les US, l’Europe sera la plus touchée par le coronavirus. Ce n’est pas fonction de la qualité des soins, d’avancée scientifique. C’est une histoire de culture.
La Chine était typique dans son premier réflexe d’enterrer le problème, avant de devenir un étalon dans la force de sa réponse — étalon inatteignable par nos démocraties bien pensantes…
For a year, we’ve been working on building the first iteration of the data team at Alan. To decide what to build and how to build it, we first worked on the why.
Why does Alan need a data team? AI is not our core business today. Yet, we believe that Alan will not be able to fulfill its crazy ambitions without a strong data team. So why?
There are generally two types of missions that the data team fulfills: create Insights, and build Products.
Insights are about creating and sharing results, serving three purposes:
At Alan, we make data a core piece of our decision processes.
Data is imported and stored in our data warehouse (Postgres) from many different sources: production data from our applications, third parties (intercom, trello, activity tracking, Hubspot, …), and data from a few tightly integrated actors from the health ecosystem.
Yet, gathering all this data into one place is not enough. Users of the data tend to separately run overlapping analyses. Work is duplicated, errors more likely, and every user creates “local metrics” that are not generalizable and not consistent with each other. …
Built the first version of Alan’s engineering team and infrastructure. Now building Alan’s data community. Likes to ship clean solutions to hard problems.