DEV Community: Adevinta Spain

Cómo construir tu propia data platform. From zero to hero.

Gustavo Martin Morcuende — Fri, 09 Jun 2023 20:08:41 +0000

Introducción

Este artículo es el resultado de la ponencia presentada el día 28 de abril de 2023 en la Salmorejo Tech. Las slides de la presentación pueden encontrarse en el siguiente enlace: slideshare.

Con esta ponencia se buscaba explicar a una audiencia con conocimientos básicos de tecnología, las distintas herramientas que se pueden emplear para construir una plataforma de datos.

La ponencia comienza con una configuración sencilla, que prácticamente cualquier persona del mundo de la informática puede entender. Termina con una configuración compleja, donde sin entrar en muchos detalles, sí permite a la audiencia hacerse una idea de qué herramientas se requieren para implementar la solución.

Diferencia entre el mundo operacional y el mundo analítico.

El mundo operacional es donde encontramos las típicas aplicaciones de frontend y backend. En este mundo no es estrictamente necesario guardar históricos de información. Aquí estamos más interesados en guardar lo que el usuario necesite para realizar sus operaciones y estas operaciones pueden caducar con el paso del tiempo. Además, en el mundo operacional, guardamos grandes cantidades de información personal como pueden ser el email, teléfonos de contacto, direcciones, etc, etc. Esto es así porque los necesitamos para contactar con el usuario. Por ejemplo, para enviarle un pedido.

En el mundo analítico lo que se quiere es guardar tanta información como sea posible. En muchas ocasiones historificada. En este mundo también, no es estrictamente necesario guardar datos personales, por ejemplo el email. Aquí no necesitamos contactar con el usuario, y por tanto no necesitamos conocer su email real, pero sí que puede que estemos interesados en saber cuántos emails distintos se han utilizado en el sistema a lo largo de los años.

Es en este mundo analítico donde implementaremos nuestra plataforma de datos.

¿Qué es una plataforma de datos?

Una plataforma de datos es un conjunto de aplicaciones, herramientas, bases de datos que permiten la adquisición, el almacenamiento, preparación y gobierno de datos. Es una solución completa para el procesado, ingesta, analizado y presentación de datos generados por una empresa.

Ver links:

¿Quiénes son nuestros usuari@s?

Antes de seguir adelante implementando una solución tecnológica, tenemos que identificar los usari@s que utilizarán dicha solución, así como sus necesidades de negocio.
A continuación listamos los casos más típicos de usuarios que podemos encontrar para una plataforma de datos.

Data engineer.

Se enfoca en el diseño, construcción, mantenimiento y gestión de infraestructuras de datos.

Implementación y gestión de sistemas de almacenamiento de datos (bases de datos, almacenamientos en la nube, etc, etc)
Asegurar que los datos estén limpios, organizados y estructurados de manera adecuada para que puedan ser utilizados de manera efectiva.

Data analysts y data scientists y machine learning engineers.

Data scientist: utiliza técnicas estadísticas y de análisis de datos para extraer información útil con el objetivo de mejorar la toma de decisiones y la eficacia de una empresa.
Data analyst: recopila, procesa y analiza datos para ayudar a las empresas a tomar decisiones informadas. Su trabajo es proporcionar información relevante y accionable para impulsar el crecimiento y el éxito empresarial.
Machine learning engineer: desarrolla y optimiza modelos de aprendizaje automático para resolver problemas empresariales complejos. Su trabajo es construir sistemas que puedan aprender y mejorar a medida que se exponen a más datos.

Solución simple.

Ahora que ya sabemos quiénes son nuestros clientes podemos empezar a plantear soluciones. Como se anticipó en la introducción, iremos del modelo más simple al más complejo.

En esta solución, el mundo operacional y el mundo analítico comparten la misma base de datos.

Observamos que todos nuestros usuarios comparten el mismo sistema. La plataforma de datos utilizará como sistema de almacenamiento la misma base de datos que el resto del sistema operacional.

Para pequeñas y medianas empresas, esta puede ser una solución de compromiso, donde no se quiere añadir la complejidad que supone añadir sistemas de almacenamiento específicos para el mundo analítico.

La plataforma de datos no necesitará proveer de un sistema de almacenamiento especial.

Ventajas: sistema más simple de mantener.
Inconvenientes: acciones realizadas en el mundo analítico (por ejemplo sacar datos en un dashboard) pueden afectar a operaciones como pueden ser la compra de un producto desde el frontend porque el sistema de almacenamiento es compartido.

Herramientas que tendremos que proporcionar

Base de datos

postgresql, mysql, oracle, etc, etc
esquemas
tablas
gestión de permisos

Aplicaciones

Leen tablas de la base de datos, realizan una transformación y escriben los resultados en otras tablas.
ETL, extract, transform, load

Dashboards

Diagramas donde se muestran datos de interés

Machine learning

MLFlow
Kubeflow

Ejemplo de aplicaciones que podemos usar

Base de datos, por ejemplo PostgreSQL.
Aplicaciones como Apache Airflow para el desarrollo de ETLs.
Dashboards como Qlik y Tableau.
Para machine learning por ejemplo podemos proporcionar Kubeflow.

Gobernanza

Gran importancia tendrá la definición y aplicación de reglas específicas para estandarizar nombres de las tablas, bases de datos, de procesos, etc, etc.

Además será importante crear reglas de utilización de las herramientas ofrecidas por la plataforma de datos. Recordemos que al final, detrás de la tecnología hay personas.

Debemos evitar que se haga un mal uso de dicha tecnología, para ello la gobernanza será fundamental.

Solución intermedia.

En esta solución observamos que el mundo operacional ahora es mucho más complejo.

Esta solución es necesaria cuando queremos evitar que procesos del mundo analítico afecten al mundo operacional. Además, el mundo operacional está compuesto por diferentes sistemas. Queremos tener todos nuestros datos analíticos en un único lugar para de este modo poder analizarlos y transformarlos de una manera sencilla.

La plataforma de datos necesitará proveer en este caso de una base de datos propia y de herramientas que permitan la extracción de la información almacenada en los diferentes sistemas del mundo analítico.

Ventajas: acciones realizadas en el mundo analítico no afectan al operacional porque el sistema de almacenamiento no es compartido. Todos los datos analíticos están recogidos en un único lugar.
Inconvenientes: mayor complejidad y costes.

Herramientas que tendremos que proporcionar

En esta solución las herramientas a proporcionar son las mismas que en la solución simple, pero ahora tenemos un nuevo tipo de base de datos, el Data Warehouse y aplicaciones que nos permitirán consumir información de los sistemas operacionales. El resto de las herramientas son las mismas que las que se explicaron en la anterior solución.

Data Warehouse, por ejemplo, AWS Redshift.
Aplicaciones como Apache Airflow para el desarrollo de ETLs.
Dashboards como Qlik y Tableau.
Para machine learning por ejemplo podemos proporcionar Kubeflow.

¿Qué es un Data Warehouse?

Es una base de datos centralizada que integra muchas fuentes de datos.
Permite aislar los sistemas operacionales de los analíticos.
Queries lanzadas desde el sistema analítico no afectan al operacional.
Permite reorganizar la información de forma que sea más fácilmente analizable.
Proporciona un único modelo de datos.
Permite mantener un histórico de información que el operacional, por no necesitarla, puede borrar.
Permite integrar múltiples fuentes de datos en un único lugar.

Modelado específico, esquema en estrella.
Compuesto de tablas de hechos y de dimensiones.
Tabla de hechos: sucesión de hechos, alto número de registros.
Tabla de dimensiones: descripción de los hechos, pocos registros y muchos atributos.
Permite la optimización de las queries en modo lectura.
Permite queries más simples, sin necesidad de múltiples JOINs como podría suceder en un modelo normalizado de entidad-relación.
Permisos vía GRANTs en tablas.

¿Qué es AWS Redshift?

Es una solución de Data Warehouse implementada por Amazon Web Services. Sin ningún esfuerzo, en la nube, podemos crear nuestro propio servidor.

En la captura de pantalla superior, se muestra la interfaz gráfica que permite crear y configurar AWS Redshift.

¡Cuidado! Nunca uses la interfaz gráfica para crear y mantener tu infraestructura en la nube. Usa siempre infraestructura como código. Con esto consigues que tu infraestructura sea reproducible, automatizable y fácilmente mantenible por cualquier persona en tu equipo u organización. Para ello hay diferentes soluciones como pueden ser CloudFormation, CDK, Terraform y muchas otras.

A continuación, documentamos un ejemplo de código Terraform que permite crear de forma sencilla un cluster AWS Redshift serverless.

  1 resource "aws_redshiftserverless_workgroup" "serverless" {
  2   workgroup_name       = var.name
  3   namespace_name       = aws_redshiftserverless_namespace.serverless.id
  4   base_capacity        = var.base_capacity
  5   security_group_ids   = var.security_group_ids
  6   subnet_ids           = var.subnet_ids
  7   enhanced_vpc_routing = true
  8   publicly_accessible  = var.publicly_accessible
  9   tags                 = var.tags
 10 }
 11 
 12 resource "aws_redshiftserverless_namespace" "serverless" {
 13   namespace_name       = var.name
 14   admin_username       = var.admin_username
 15   admin_user_password  = var.admin_user_password
 16   db_name              = var.db_name
 17   iam_roles            = var.iam_roles
 18   default_iam_role_arn = var.default_iam_role_arn
 19   tags                 = var.tags
 20 
 21   # https://github.com/hashicorp/terraform-provider-aws/issues/26624
 22   lifecycle {
 23     ignore_changes = [
 24       iam_roles
 25     ]
 26   }
 27 }
 28 
 29 resource "aws_route53_record" "serverless" {
 30   for_each = toset(var.route53_record_zone_ids)
 31   zone_id  = each.value
 32   name     = "redshift-${var.route53_record_name}"
 33   type     = "CNAME"
 34   ttl      = 30
 35   records  = aws_redshiftserverless_workgroup.serverless.endpoint.*.address
 36 }

Solución avanzada.

En esta solución aparecen dos nuevos elementos: el Data Lake o Lakehouse, y fuentes de datos de tipo JSON, AVRO, XML o cualquier tipo de API.

Esta solución la implementaremos cuando tengamos que guardar grandes cantidades de datos no estructurados como pueden ser eventos generados por el Internet de las Cosas.

Ventajas: podemos guardar datos no estructurados en grandes cantidades.
Inconvenientes: mayor complejidad y costes.

Herramientas que tendremos que proporcionar

En esta solución las herramientas a proporcionar son las mismas que en la solución intermedia, pero ahora se añade la necesidad de implementar un Data Lake o un Lakehouse.

En nuestro caso, y porque estamos usando las herramientas proporcionadas por AWS en la nube, el Lakehouse se implementará haciendo uso de AWS S3.

¿Qué es un Data Lake o Lakehouse?

Es un sistema de almacenamiento de datos masivo y barato.
Se utiliza para almacenar grandes cantidades de información en su formato nativo, sin necesidad de que los datos estén estructurados de una manera particular (JSON, XML, logs, etc)
Los datos pueden provenir de diferentes fuentes, bases de datos, sensores, registros de máquinas, APIs, etc.
Permite aislar los sistemas operacionales de los analíticos.
Se utilizan sistemas distribuidos como AWS S3 de Amazon o HDFS (sistema de archivos de Hadoop)

¿Qué es un Data Lake o Lakehouse implementado en AWS S3?

En Adevinta, implementado en AWS S3 (en Amazon Cloud)
Puede verse como un sistema de archivos con carpetas
¡Pero no es un sistema de archivos!
Los archivos se llaman objetos.
Podemos usarlo mediante el Hadoop File System, Apache Spark, etc, etc.
Permisos vía IAM Roles.

¿Cómo podemos usar el Data Lake o Lakehouse?

Para poder usarlo existen aplicaciones como Apache Spark. En la captura de pantalla superior, se muestra un notebook ejecutando código Apache Spark que permite leer un archivo comprimido en formato gzip y mostrar la información que contiene.

Conclusión.

En esta ponencia hemos presentado diferentes soluciones para construir una plataforma de datos. Desde la más sencilla hasta la más compleja. Otras soluciones son posibles, pero todas ellas tendrán piezas muy similares a las aquí discutidas.

Ahora ya solo queda que tú también montes en tu empresa tu propia data platform y logres ese ascenso o mejora laboral que te mereces.

How to build your own data platform. Episode 2: authorization layer. Data Warehouse implementation.

Gustavo Martin Morcuende — Sun, 04 Jun 2023 23:05:20 +0000

Introduction.

This article is the second part of the episode about building an authorization layer for your data platform. You can find the whole list of articles following this link: https://medium.com/@gu.martinm/list/how-to-build-your-own-data-platform-9e6f85e4ce39

In the previous article we talked about how to implement the authorization layer in the Data Lake, in this second part we will be talking about the same but in the Data Warehouse.

Authorization layer.

You can see in this diagram the Lakehouse with its metastore and the Data Warehouse. We already talked about the authorization layer for the Lakehouse in the previous article. Now it is the turn for the Data Warehouse.

Because we will be using Amazon Web Services with AWS Redshift, we will be implementing this layer using Lake Formation.

Processing layer.

Human users and processes will be the ones accessing the stored data through the authorization layer. Machines and processes like Zeppelin notebooks, AWS Athena for SQL, clusters of AWS EMR, Databricks, etc, etc.

The problem with the authorization.

Data engineers, data analysts and data scientists work in different and sometimes isolated teams. They do not want their data to be deleted or changed by tools or people outside their teams.

Data owners are typically in charge of granting access to their data.

Owner — consumer, relationship.

A data consumer requests access to some data owned by a different team in a different domain. For example, a table in a database.
The data owner grants access by approving the access request.
Upon the approval of an access request, a new permission is added to the specific table.

Our authorization layer must be able to provide the above capability if we want to implement a data mesh with success.

Data Warehouse, AWS Redshift.

The Data Warehouse is implemented on the top of AWS Redshift. Not many years ago a new service was released by Amazon called AWS Redshift RA3. What makes RA3 different from the old Redshift is that, in the new implementation, computation and storage are separated. Before having RA3, if users needed more storage capabilities, more computation had also to be paid even if computation was not a problem. And in the opposite way, when users needed more computation capabilities, more storage had to be paid. So, Redshift costs were typically high.

We will be using AWS Redshift RA3. Here you can find some useful links that explain further what are AWS Redshift and AWS Redshift RA3:

Data Warehouse, AWS Redshift RA3.

Amazon Redshift data sharing allows you to securely and easily share data for read purposes across different Amazon Redshift clusters without the complexity and delays associated with data copies and data movement. Data can be shared at many levels, including schemas, tables, views, and user-defined functions, providing fine-grained access controls that can be tailored for different users and businesses that all need access to the data.

Lake Formation can be integrated with data sharing.

For further information visit the following links:

Authorization, Federated Lake Formation.

Using Lake Formation with AWS Redshift RA3 we can manage the permissions across different accounts from only one central account in a federated way. We are delegating permissions to other accounts but we keep the control of them.

Authorization, implementation.

In order to implement federated authorization with AWS Redshift RA3 you can follow the next steps:

AWS Redshift RA3, producer account:

CREATE DATASHARE producer_sharing
GRANT USAGE ON DATASHARE producer_sharing TO ACCOUNT ‘FEDERATED_GOVERNANCE’
ALTER DATASHARE producer_sharing ADD SCHEMA producer_schema

AWS Redshift RA3, consumer account:

CREATE DATASHARE consumer_sharing
GRANT USAGE ON DATASHARE consumer_sharing TO ACCOUNT ‘FEDERATED_GOVERNANCE’
ALTER DATASHARE consumer_sharing ADD SCHEMA consumer_schema

AWS Redshift RA3, main federated account:

Through Lake formation console, allow access from consumer account to producer_sharing. You can see a screenshot about this configuration down below.

With the above configuration, the query from the consumer account will only see the column brand_id.

Conclusion.

In this article we have explained how you can implement an authorization layer using AWS AWS Redshift RA3 and AWS Lake Formation.

With this authorization layer we will be able to resolve the following problems:

Producers and consumers from different domains must have the capability of working in an isolated way (if they wish so) if we want to implement a data mesh with success.
Producers must be able to decide how consumers can access their data. They are the data owners, and they decide how others use their data.
Fine grained permissions can be established. At column and even if we want, at row level. This will be of great interest if we want to be GDPR compliant. More information about how to implement the GDPR in your own data platform will be explained in future articles.

Stay tuned for the next article about how to implement your own Data Platform with success.

I hope this article was useful. If you enjoy messing around with Big Data, Microservices, reverse engineering or any other computer stuff and want to share your experiences with me, just follow me.

How to build your own data platform. Episode 2: authorization layer. Data Lake implementation.

Gustavo Martin Morcuende — Fri, 02 Jun 2023 21:43:39 +0000

Introduction.

This is the second episode in the series about how to build your own data platform. You can find the whole list of articles in the following link https://medium.com/@gu.martinm/list/how-to-build-your-own-data-platform-9e6f85e4ce39

Remember, a data platform will be used by many teams and users. Also the data to be stored could be coming from many and different sources. Data owners will want to set permissions and boundaries about who can access the data that they are storing in the data platform.

In this episode I will explain how you can add these capabilities to your data platform. Also I will introduce the concept of data mesh, and how you can use the authorization layer for implementing the workflow between data consumers and data owners that you will need for creating a successful data mesh.

Authorization layer.

Our authorization layer will be on the top of the storage one. In this way, users and applications willing to use the stored data will need to do it through this layer in a safe way. No data will escape from the storage layer without authorization.
For implementing this layer you can use different solutions like Unity Catalog from Databricks, Lake Formation from AWS, plain IAM roles also from AWS, Apache Ranger, Privacera and many others.

For this article, and because we are working with Amazon Web Services, we will be implementing this layer using IAM roles and Lake Formation.

Processing layer.

The problem with the authorization.

Data engineers, data analysts and data scientists work in different and sometimes isolated teams. They do not want their data to be deleted or changed by tools or people outside their teams.

Also, for being GDPR compliant, to access PII data, big restrictions will be required even at column or row level.

Every stored data needs to have an owner, and in Data Mesh, data owners are typically in charge of granting access to their data.

What is a Data mesh?

Taken from https://www.datamesh-architecture.com/#what-is-data-mesh

The term data mesh, coined in 2019 by Zhamak Dehghani, is based on four key principles:

Domain ownership: Domain teams are responsible for their data, aligning with the boundaries of their team's domain. An authorization layer will be required for implementing those boundaries for some team.
Data as a product: Analytical data should be treated as a product, with consumers beyond the domain. An owner-consumer relationship will exist, where consumers require access to products owned by a different team.
Self-serve data infrastructure platform: A data platform team provides domain-agnostic tools and systems to build, execute, and maintain data products.
Federated governance: Interoperability of data products is achieved through standardization promoted by the governance group.

Owner - consumer, relationship.

A data consumer requests access to some data owned by a different team in a different domain. For example, a table in a database.
The data owner grants access by approving the access request.
Upon the approval of an access request, a new permission is added to the specific table.

Our authorization layer must be able to provide the above capability if we want to implement a data mesh with success.

Data Lake.

In this section we will write a brief recap about what we explained in previous article: https://medium.com/@gu.martinm/how-to-build-your-own-data-platform-f273014701ff

AWS S3.

Notebooks, Spark jobs, clusters, etc, etc, run in Amazon virtual servers called EC2.
These virtual servers require permissions for accessing AWS S3. These permissions are given by IAM Roles.
We will be working with Amazon Web Services. As we said before, because the amount of data to be stored is huge, we can not use HDD or SSD data storages, we need something cheaper. In this case we will be talking about AWS S3.
Also, in order to ease the use of the Data Lake, we can implement metastores on the top of it. For example, Hive Metastore or Glue Catalog. We are not going to explain deeply how a metastore works, that will be left for another future article.

When using a notebook (for example a Databricks notebook) and having a metastore, the first thing that the notebook will do is to ask the metastore where the data is physically located. Once the metastore responds, the notebook will go to the path in AWS S3 where the data is stored using the permissions given by the IAM Role.

Direct access or with a metastore.

We have two options for working with the data. With or without using a metastore.
With the metastore, users can have access to the data in the Data Lake in an easier way because they can use SQL statements as they do in any other databases.

Authorization, direct access.

Consumers run their notebooks or any other applications from their AWS accounts and consume data located in the producer’s account.

These notebooks and applications run in Amazon virtual servers called Amazon EC2 instances, and for accessing the data located in AWS S3 in the producer’s account, they use IAM Roles (the permissions for accessing the data)

S3 bucket policy

For example, for being able to access to the S3 bucket called s3://producer, with the IAM Role with ARN arn:aws:iam::ACCOUNT_CONSUMER:role/IAM_ROLE_CONSUMER, we can use the following AWS S3 bucket policy in the s3://producer bucket:

Direct access

Here, we are showing an example, where from a Databricks notebook using the above IAM Role and running in the consumer account, we are able to access data located in the producer’s account.

Can we do it better?

With Glue Catalog as metastore, data in S3 can be accessed as if it was stored in a table with rows and columns.

If we use tables instead of the direct access, we can grant permissions even at column level.

Lake Formation provides its own permissions model that augments the IAM permissions model. This centrally defined permissions model enables fine-grained access to data stored in data lakes through a simple grant or revoke mechanism, much like a database. Lake Formation permissions are enforced using granular controls at the column, row, and cell-levels.

Authorization, Lake Formation.

For using Lake Formation we will need the following elements:

An application running in some machine in an AWS account. For example, an AWS EC2 instance where a Spark notebook will be executed.
A shared resource between the producer and consumer’s account. In this case we are sharing the S3 bucket called producer.
An IAM Role with permissions for using the producer’s bucket.
Two AWS Glue Catalogues as metastores. The one in the consumer's account will be in charge of forwarding the table resolution to the metastore in the producer’s account. Both metastores are also shared between the two accounts.

The catalogue in the producer’s account contains all the required information for translating the virtual table to its physical S3 location.

In the below screenshots you can see the Lake Formation configuration for the Glue metastore located in the producer’s account.

First you can see the table and database where the producer’s table is located. You can also see that we are sharing the specific table with the consumer’s account.

Database: schema
Table: producer

In the above table we can configure access permissions. For example, we can decide that we will be allowing only the use of SELECT statements from the consumer’s account and also the only column that will be shown is the one called brand_id.

Now, from the Spark notebook running in the consumer’s account we can run SQL statements against the table located in the producer’s account.

Because we only allowed access to the column called brand_id, the consumer will only see values for that column. Any other column will be hidden.

Conclusion.

In this article we have explained how you can implement an authorization layer using AWS IAM Roles and AWS Lake Formation.

With this authorization layer we will be able to resolve the following problems:

Producers and consumers from different domains must have the capability of working in an isolated way (if they wish so) if we want to implement a data mesh with success.
Producers must be able to decide how consumers can access their data. They are the data owners, and they decide how others use their data.
Fine grained permissions can be established. At column and even if we want, at row level. This will be of great interest if we want to be GDPR compliant. More information about how to implement the GDPR in your own data platform will be explained in future articles.

Stay tuned for the next article about how to implement your own Data Platform with success.

I hope this article was useful. If you enjoy messing around with Big Data, Microservices, reverse engineering or any other computer stuff and want to share your experiences with me, just follow me.

Cómo me organizo con trabajo y familia numerosa

Jorge Castro — Tue, 20 Dec 2022 00:24:49 +0000

“Explica las cosas de manera que hasta un niño pueda entenderlas” ― Richard Feynman

TLDR

Para aprender necesito recopilar, procesar y organizar información.

Con una mezcla de configuración de mis redes sociales, Getting Things Done (GTD) y la creación de mi cerebro digital, he encontrado mi forma de seguir aprendiendo con un trabajo exigente y familia numerosa.

Si quieres saber cómo lo hago tendrás que seguir leyendo.

Índice

¿Por qué sigo aprendiendo?
Mi contexto
¿Cómo me organizo?
Para mantenerme actualizado necesito tener fuentes de conocimiento
¿Cómo organizo todo lo que aprendo?
¿Qué son notas atómicas altamente enlazadas?
Vale, ya he recopilado mucha información, pero ¿cuándo aprendo?
¿Y esto es suficiente?
Estas son las herramientas que uso para organizarme

¿Por qué sigo aprendiendo?

He pasado por muchos roles que necesitan habilidades y conocimientos diferentes.
He trabajado como Backend, SRE, Tech Lead, Engineering Manager y últimamente disfruto trabajando como Machine Learning Engineer en Adevinta.

El desarrollo de software es una profesión que aunque estés 2 años en un mismo rol y en una misma empresa, necesitas adquirir nuevos conocimientos, herramientas y habilidades.

Nunca me había parado a pensar cómo me mantengo actualizado.
Pensarlo me ha hecho ser consciente de que sigo un proceso y he intentado estructurarlo para poder explicarlo.

A lo mejor alguna cosa te sirve.

Ten en cuenta que mi forma de aprender está muy influida por mi contexto.

Es muy posible que si tuviera un contexto diferente aprendería de forma diferente.

Mi contexto

Mi prioridad son mi mujer y mis 4 hijos.

Yo elijo utilizar la mayor parte de mi tiempo en disfrutar con la familia y esto me deja muy poco tiempo para aprender.

Llevo muchos años buscando la mejor forma de aprender.
Todo lo que te contaré ha ido naciendo de muchos años de prueba, error y ajustar las cosas hasta que me han ido funcionando.

Además tengo una opinión bastante impopular:

Todos tenemos 24 horas al día.
Cada uno elegimos en qué las dedicamos.
Menos respirar, y unas cuantas horas de sueño, el resto del tiempo decidimos de forma consciente en qué lo invertimos.

Cuando quieras me lo rebates por Twitter o Mastodon y lo discutimos 😜

¿Cómo me organizo?

Para tener mi cabeza despejada y organizada utilizo GTD - Getting Things Done. Tanto para lo personal como lo laboral.

Si no conoces GTD no pasa nada.

Te dejo mi definición y un par de diagramas que lo resumen muy bien. (El site de dónde copié los diagramas ya no existe.)

Para mí, GTD es una metodología que me permite descargar y organizar todo lo que tengo en la cabeza de una forma que sé que en cada momento voy a tener disponible lo siguiente que necesito hacer y no voy a perder nada de lo que quiero conservar para el futuro.

Pasos de GTD

Flujo de GTD

Que las apariencias no te engañen.

Usar GTD no es sencillo.
Yo tarde 3 intentos (a lo largo de 2 años) en conseguir que me funcionara.🤯

Durante el post nombraré varias veces la Bandeja de entrada (Inbox), así que te explico cómo la uso:

Es donde apunto todo lo que quiero sacar de mi cabeza.
En mi caso la tengo centralizada en una carpeta en Todoist.
En esta Bandeja de Entrada apunto cada idea, nota, tarea, link interesante, pensamiento, curso que me interesa, video, etc. todo aquello que quiero sacar de mi cabeza pero que después quiero hacer algo con ello.
Apunto todo lo que se me ocurre, incluso cuando estoy fregando cacharros, limpiando la casa, doblando la ropa, etc. Cosas mecánicas que me permiten parar de hacerlas, apuntar y seguir con la tarea.
Esta Bandeja de Entrada debería procesarla varias veces al día, pero lo normal es que solo consiga hacerlo 1 vez al día. 🤷 (Y desde que llegó mi 4ª hija, una vez cada 2 días...)
Intento que quede vacía y organizada para garantizar que voy a volver a esas tareas cuando sea necesario, sin tener que estar pensando continuamente en ellas.
Cuando se me acumulan cosas sin procesar en la bandeja de entrada no miro nuevas cosas hasta que la proceso.

La bandeja de entrada es solo el punto de entrada a GTD.
Sin el resto de la metodología solo sería una lista infinita de cosas y no me serviría para nada.
Para explicar el resto de fases de GTD harían falta muchos posts.

Aquí te dejo una introducción.

Para mantenerme actualizado necesito tener fuentes de conocimiento

Siempre busco la forma de conseguir información con el mínimo esfuerzo.
Tengo muchas fuentes de conocimiento, y siempre que puedo me "aprovecho" de los algoritmos de recomendación.
Además dejo que Google me conozca para que me muestre lo que yo quiero ver y evitar un poco la procrastinación.
Mi objetivo es minimizar el tiempo que necesito para conseguir la información para continuar aprendiendo.

Actualmente mis fuentes de conocimiento son:

Medium pero solo el Daily Digest
Twitter (pero una par de veces por semana)
Google Noticias (cuando me apetece porque también me ayuda a desconectar)
Youtube
Libros (En los pocos momentos que tengo para leer)
Cuando quiero profundizar en un tema busco en Google y leo libros que me han recomendado o que ya tengo pendientes de leer.

1. Medium Daily Digest

Deja que Medium trabaje por ti.
Yo no voy a Medium, Medium y sus subsites vienen a mi.
Tengo 2 cuentas de correo en las que recibo cada día el Medium Daily Digest
En cada cuenta recibo temas diferentes:
- Temas tech, desarrollo de software, ML, etc..
- Temas de productividad, management, mejora personal, etc..
Puedes refinar las recomendaciones y cambiar los topics que sigues.
Muchos días solo leo el subject de los Daily Digest (suele ser el título del primer artículo). Si no me interesa ni lo abro.
Si abro el mail, leo como máximo el título de los 3 primeros artículos del mail.
Es la forma de no recopilar información infinita, porque si miras hasta el final, siempre encuentras algo que te llama la atención.
¿Y qué hago si me interesa el título de alguno de esos artículos? Pues lo mando a mi Bandeja de Entrada.
¡Importante! Si te interesa algún link y no quieres que afecte a las recomendaciones de esa cuenta:
- Copia el link desde el email
- Edita la URL para quitar los ítems del source para que Medium no te lo trackee.
- Ábrelo en una ventana de incógnito o usa DuckDuckGo por si estás logado en Medium con la otra cuenta (Yo suelo estar deslogado siempre)

2.Twitter

La mayoría de cuentas que sigo están relacionadas con mis intereses.
Dejo que Twitter haga su magia..... ¿Por qué? porque lo miro muy poco, un par de veces por semana.
No me interesa ver el último comentario de las cuentas que sigo.
Me interesa ver "lo más destacado"
Cualquier link o tweet que crea que luego me va a servir o que quiero hacer algo con él... A la Bandeja de Entrada.
Me pierdo muchas cosas, sí, y no pasa nada.

3. Google Noticias

Google puede ser tu amigo si lo personalizas y le das tiempo...
Puedes modificar la personalizacion de Google sobre publicidad y sobre tu actividad.
Así cuando en tu móvil Android deslizas a la izquierda y vas a Google noticias, verás cosas que te interesan de verdad.
Y si algo te interesa... A la Bandeja de Entrada.

4. Youtube

Lo puedes poner de fondo mientras cocinas, doblas ropa, friegas los cacharros, en el coche como si fuera un podcast.
Tengo 2 listas de videos:
- Una con temas que puedo poner en el coche para solo escuchar. Son temas por los que tengo curiosidad, videos que lo que cuentan no sé si me aportará algo pero tienen buena pinta. Si hay cosas interesantes que quiero apuntar, cuando paro el coche, añado el video a la Bandeja de entrada con algo como: "Repasar video para apuntar concepto XYZ".
- Tengo otra lista con el resto de cosas que quiero ver y que necesitan atención plena para tomar notas o asimilar conceptos.

5. Libros

En casa me suelo levantar el primero y durante la semana aprovecho el desayuno para leer un poco de algún libro.
Otro de mis rincones de lectura es el baño.
Leo muy lento porque las ideas que me parecen interesantes del libro las intento convertir en notas atómicas altamente enlazadas. Luego hablaré de qué es esto.
¿Esto quiere decir que cada día me levanto antes y en el desayuno leo libros? No, algunos días leo algún artículo, otros programo algo, muchos no hago nada...
Depende del día, el tiempo que tenga y las ganas que tenga ese día de hacer algo.

¿Cómo organizo todo lo que aprendo?

Tengo implementado GTD en una cuenta de pago de Todoist.
En mi caso solo con Todoist no es suficiente.
Tomo notas atómicas altamente enlazadas de todo lo que aprendo, pero Todoist no me sirve para hacerlo.
Para las notas he tenido que crear mi cerebro digital.
Llevaba años usando OneNote para volcar todo lo que aprendo o todo lo que luego quiero volver a consultar.
En los últimos meses he cambiando a Obsidian y poco a poco estoy migrando lo que tengo en OneNote.
(Sí, he probado Notion y no es lo que yo necesito)
Las principales razones para el cambio a Obsidian son:
- Su sencillez para crear notas atómicas altamente enlazadas.
- Tener las mismas funcionalidades en móvil y en escritorio
- Tener control total sobre mis notas. Son markdowns y puedo guardarlos y leerlos como yo quiera.
Para organizar mis notas uso varios de los principios de Zettelkasten.
Si no conoces Zettelkasten este video lo explica muy bien y muestra una posible implementación en Notion. Tomar Notas de esta forma me ha Cambiado la Vida | Zettelkasten con Notion.
Este otro video te puede ayudar a entender Zettelkasten de forma visual: Cómo tomar notas para siempre | Método Zettelkasten explicado con ejemplos visuales.

¿Qué son notas atómicas altamente enlazadas?

Son la base de Zettelkasten.
Son notas tomadas con tus propias palabras
Son atómicas porque solo hablan de un concepto. No tienen porque ser cortas, pero cuanto más breves mejor.
Son altamente enlazadas porque creas notas con referencias cruzadas con otras notas que a su vez tienen referencias cruzadas a otras notas, etc..
Por ejemplo, este post sale de copiar cosas de muchas notas atómicas. Notas sobre GTD, Aprender haciendo, Práctica deliberada, Zettelkasten, como priorizar....
Este es el grafo que tengo actualmente con notas enlazadas y cada día va creciendo

Vale, ya he recopilado mucha información, pero ¿cuándo aprendo?

Cada semana "me comprometo" como mínimo a usar 2 fuentes de conocimiento, ya sean artículos, capítulos de libros, videos.
Los selecciono en la revisión semanal de GTD
- Selecciono 1 fuente sobre Machine Learning. (Ahora estoy aprendiendo sobre modelos de difusión como Stable Diffusion. Si te interesa el tema, estas son mis notas de lo último que he aprendido)
- Selecciono 1 fuente que me apetezca de las que tengo recopiladas, sea de lo que sea. Desde videojuegos, crianza, jardinería, magia, etc. Cualquier cosa no relacionada con la primera fuente. (A no ser que me apetezca leer más cosas sobre lo anterior 😅)

¿Y esto es suficiente?

Pues no. Esto solo sirve para leer y tomar notas de nuevas cosas o profundizar en lo que quiero aprender.
Leer y leer sin practicar a mí no me funciona.
A mí lo que me funciona es aprender haciendo (learning by doing), sobretodo usando práctica deliberada
Para explicarte cómo aprendo he creado este otro post con todo el detalle

Estas son las herramientas que uso para organizarme

Todoist - para implementar GTD.
Obsidian - donde estoy creando mi cerebro digital.
Google Calendar - para todo aquello que tiene día y hora concreta.
Drivesync - para sincronizar Google Drive desde Android (solo sincronizo el vault de Obsidian).
Photo compressor - para comprimir las imágenes que guardo en Obsidian.
Voiceliner - para crear notas de voz exportables a markdown.
Gestor de archivos Plus - Para copiar los markdown de Voiceliner al vault de Obsidian.

Cómo sigo aprendiendo con trabajo y familia numerosa

Jorge Castro — Wed, 07 Dec 2022 23:14:57 +0000

“Nunca vas a aprender todo lo que quieres.

Nunca vas a leer todo lo que quieres.

Nunca vas a ver todo lo que quieres.

Y no pasa absolutamente nada.

¡Acéptalo y vivirás más tranquila!” ― Jorge Castro

TLDR

Si quieres llevarte una sola idea, aprende haciendo (learning by doing) pero haciendo práctica deliberada.

Si quieres saber como llego a esa práctica deliberada con un trabajo exigente y familia numerosa... Tendrás que seguir leyendo.

Índice

¿Por qué sigo aprendiendo?
Mi contexto
¿Cuándo leo cosas nuevas?
¿Y esto es suficiente?
¿Qué es eso de la práctica deliberada?
¿Qué es eso de aprender haciendo?
¿Y si quiero aprender soft-skills?
¿Y cómo aprendendo en mi día a día?
¿Cómo sigo aprendiendo cuando solo tengo 30 minutos libres?
¿Y si solo tengo 5 minutos libres?
Resumen

Para aprender tengo que recopilar información y tenerla siempre disponible y a punto. Tengo mi forma de organizarme y de capturar información para aprender. Si te interesa el tema puedes leerlo aquí

¿Por qué sigo aprendiendo?

El desarrollo de software es una profesión que aunque estés 2 años en un mismo rol y en una misma empresa, necesitas adquirir nuevos conocimientos, herramientas y habilidades.

Nunca me había parado a pensar cómo me mantengo actualizado.
Pensarlo me ha hecho ser consciente de que sigo un proceso y he intentado estructurarlo para poder explicarlo.

A lo mejor alguna cosa te sirve.

Ten en cuenta que mi forma de aprender está muy influida por mi contexto.

Es muy posible que si tuviera un contexto diferente aprendería de forma diferente.

Mi contexto

Mi prioridad son mi mujer y mis 4 hijos.

Yo elijo utilizar la mayor parte de mi tiempo en disfrutar con la familia y esto me deja muy poco tiempo para aprender.

Llevo muchos años buscando la mejor forma de aprender.
Todo lo que te contaré ha ido naciendo de muchos años de prueba, error y ajustar las cosas hasta que me han ido funcionando.

Además tengo una opinión bastante impopular:

Todos tenemos 24 horas al día.
Cada uno elegimos en qué las dedicamos.
Menos respirar, y unas cuantas horas de sueño, el resto del tiempo decidimos de forma consciente en qué lo invertimos.

Cuando quieras me lo rebates por Twitter o Mastodon y lo discutimos 😜

¿Cuándo leo cosas nuevas?

Si quieres entender cómo recopilo y uso mis fuentes de conocimiento puedes leerleerlo aquí
Cada semana "me comprometo" a usar 2 fuentes de conocimiento ya sean artículos, capítulos de libros, videos.
Ahora mismo tengo 2 grupos:
- Selecciono 1 fuente sobre Machine Learning. (Ahora estoy aprendiedo sobre modelos de difusión como Stable Diffusion. Si te interesa el tema, estas son mis notas de lo último que he aprendido)
- Selecciono 1 fuente que me apetezca de las que tengo recopiladas, sea de lo que sea. Desde videojuegos, crianza, jardinería, magia, etc. Cualquier cosa no relacionada con la primera fuente. (A no ser que me apetezca leer más cosas sobre lo anterior 😅)

¿Y esto es suficiente?

Pues no. Esto solo sirve para leer y tomar notas de nuevas cosas o profundizar en lo que quiero aprender.
Leer y leer sin practicar a mí no me funciona.
A mí lo que me funciona es aprender haciendo (learning by doing), sobretodo usando práctica deliberada

¿Qué es eso de la práctica deliberada?

Es practicar de forma consciente los temas que quieres mejorar.
Tienes que ejercitar aquellas cosas que necesitas y se te dan peor.
Necesitas total concentración y esfuerzo con el tema.
Los demás temas que quieres aprender no existen.
Normalmente hace falta repetición. Tienes que practicar de forma sostenida durante un tiempo.
Eso implica que tienes que tener muy claro a qué vas a renunciar para hacer esa práctica deliberada de forma sostenida.
Y por supuesto, tener fuerza de voluntad y constancia para cumplirlo.

¿Qué es eso de aprender haciendo?

Siempre aprendo más si lo aplico en algo práctico, ya sea algo para casa, para el trabajo, dar una charla, un taller, etc. Algo en lo que pueda aplicar lo que estoy aprendiendo.
Intento seguir el siguiente proceso:
- Me hago las siguientes preguntas: Si tengo que explicárselo a alguien que no sabe del tema ¿Qué le explicaría? ¿Cómo se lo explicaría? ¿Por dónde empezaría la explicación?
- Divido lo que quiero aprender en partes pequeñas y manejables.
- Recopilo mis fuentes de información
- Busco la forma de recibir feedback lo más inmediato posible de cada una de las partes que he dividido. Por ejemplo, código funcionando, llevar una conversación con la técnica que quería aprender, etc.
- Y me planteo continuamente cómo podía haber aprendido mejor y más rápido.
En realidad estoy aplicando mi propia variante de la técnica Feynman.
Lo bueno de aprender haciendo es que a medida que avances irás encontrando nuevas dudas y problemas de los que aprender.

¿Y si quiero aprender soft-skills?

Exactamente lo mismo.
Aprender haciendo y práctica deliberada.
Por ejemplo, quiero mejorar la escucha activa.
Tu práctica será utilizar de forma consciente alguno de los principios de escucha activa en la siguiente conversación que tengas con otra persona, ya sea tu pareja, tu hijo, un amigo o una persona de tu equipo si eres manager.
Y cuando lo hayas practicado piensa en cómo lo podías haber hecho mejor y vas mejorando poco a poco.

¿Y cómo aprendendo en mi día a día?

Aquí empieza lo difícil.
Te toca saber priorizar de verdad...🤷‍♂️
Durante X semanas solo me centro en un tema.
Lo difícil no es elegir el tema al que me quiero dedicar, lo difícil es decidir a qué voy a renunciar. Por ejemplo, no veré esa serie que tantas ganas le tengo, o no jugaré ese nuevo juego que tiene buena pinta, o no aprenderé sobre este tema que también me interesa hasta dentro de un tiempo...
Algunas noches, cuando las fieras se van a dormir, en lugar de ponerme una serie/peli/juego, pruebo cosas que me han parecido interesantes de lo que he ido aprendiendo.
Otras veces me levanto 1 hora antes para programar o probar algo que llevo días dándole vueltas.
Esto quiere decir que aprendo muy pocas cosas y muy lento. Es algo que tienes que asumir y vivir con ello.
Si intentas aprender a un ritmo que no es sostenible con tu vida, acabará afectando a tu salud, a tu familia y a tu trabajo.
En vacaciones siempre intento hacer como mínimo un curso (Codely, Pluralsight, Udemy u otras plataformas) y aplicar lo que aprendo del curso:
- Por ejemplo, las últimas vacaciones hice varios cursos sobre bash y Mac en Codely (cada día intentaba ver un capítulo del curso en varios ratos que iba teniendo) y de ahí he creado la template para configurar el entorno para desarrollar proyectos de Machine Learning.
- Para aprender Node.js me hice un scrapper de precios de PortAventura (y antes de la pandemia nos íbamos a PortAventura con todo incluido y hotel de lujo a precio de los "baratos").
- Para aprender Python hice una template de despliegue de modelos de Machine Learning.
- Para aprender Obsidian estoy creando mi propio cerebro digital.
Tienes que buscar algo que te permita aplicar lo que quieres aprender de forma práctica.
Y si lo vas a aplicar en tu trabajo, que sea en una prueba de concepto o fuera del camino crítico de tu negocio. (Qué nos conocemos... 😜)
A veces me propongo explicar ese tema a otra persona o dar una charla o escribir sobre ello, así me obligo a tener fechas y a pensar muy bien que necesito aprender en el tiempo que tengo para que lo puedas explicar a otras personas.

¿Cómo sigo aprendiendo cuando solo tengo 30 minutos libres?

Si tienes poca disponibilidad también puedes aprender.
Aprenderás lento, pero si eres constante puedes aprender igual.
Cuando voy a tener muy poca disponibilidad troceo mucho lo que quiero aprender y elijo cosas muy concretas para practicar.
Por ejemplo, si quiero aprender testing en legacy code:
- En mis primeros huecos disponibles recupero posts o capítulos de libros que tengo guardados sobre el tema.
- Si creo que sigo necesitando más información, en los siguientes huecos busco nueva información sobre el tema.
- Después voy leyendo/viendo, tomando notas y decidiendo qué tema concreto practicaré.
- Por ejemplo, decido practicar "Approval Testing"
- En los siguientes huecos busco ejemplos que podría implementar para practicar "Approval Testing"
- En alguno de los huecos preparo el entorno y el ejemplo
- Y a partir de ahí... ¡A practicar!
Es un proceso lento. Con otro contexto podrías hacerlo en una tarde, pero si no tienes una tarde, poco a poco puedes conseguir los mismos resultados.
La clave está en:
- Trocear mucho lo que quieres aprender.
- Ten siempre todo preparado suponiendo que sólo vas a tener 30 minutos libres:
- Si son libros, a la vista y marcados por dónde ibas.
- Si es desarrollo, el IDE abierto y preparado.
- La documentación, tutorial o video en el punto para empezar.
- Seguro que en 30 minutos te da tiempo a practicar ese tipo de test que querías, esos atajos de teclado que necesitas o ese refactor que no dominas.
- Sumando pequeños aprendizajes puedes llegar a resultados extraordinarios
Como dice Tony Robbins
- No importa lo mal o lento que vayan las cosas, sigues estando muy por delante de todos los que ni siquiera lo intentan.
Esta forma de aprender hace que empiece algunos temas y entre parón y parón ya no tenga ganas de continuar con ellos.
Para mí eso significa que ese tema o no es tan importante como creía, o no lo necesito tanto como esperaba y no pasa nada, a lo mejor lo retomo en un futuro, o no.

¿Y si solo tengo 5 minutos libres?

Si solo tienes 5 minutos libres es que estás priorizando otras cosas por delante de tu aprendizaje.
O cambias las prioridades o asumes que solo podrás leer alguna cosa de vez en cuando.
Para solo leer sin tiempo de práctica, mejor usa esos 5 minutos para descansar y desconectar, que te hace falta.

Resumen

Para aprender vas a necesitar motivación, pero la motivación se te va a acabar. Lo que de verdad necesitas es mucha fuerza de voluntad y constancia.
Asume que no puedes aprender todo lo que quieres y no pasa absolutamente nada.
Elige un tema, sólo un tema y durante un tiempo enfócate solo en ese tema.
Recopila información relacionada con el tema durante un tiempo: capítulos de libros, cursos, tutoriales, podcasts, lo que creas que te ayudará para empezar a aprender.
Organízate la información para tenerla siempre accesible de forma rápida.
Elige algo práctico donde aplicar lo que vas a aprender y usa cada minuto que tengas para aprender usando práctica deliberada.
Ten tu entorno de aprendizaje siempre a punto y listo para continuar donde lo dejaste.
Parte del aprendizaje es organizar todo lo que has aprendido, ya sea código bien ordenado en GitHub, resúmenes, notas bien estructuradas, etc. Esto te ayudará a consolidar el aprendizaje y te permitirá consultar ese tema de forma muy rápida en un futuro.
Antes de pasar al siguiente tema descansa unos días, semanas o meses.
Y por último, vuelve a empezar...

How to build your own data platform. Episode 1: sharing data between environments. Data Warehouse implementation.

Gustavo Martin Morcuende — Tue, 06 Dec 2022 00:27:50 +0000

Introduction.

This article is the second part of the first episode about how to build your own data platform. To catch up, follow this link: https://dev.to/adevintaspain/how-to-build-your-own-data-platform-4l6c

As a short recap, remember that for creating a data platform many parts are involved. For this first episode we are only focusing on the component that we called storage layer. In the storage layer we could find the Lakehouse or Data Lake and the Data Warehouse. In the previous article we talked about how to share data in the Data Lake, in this second part we will be talking about the same but in the Data Warehouse.

Storage layer.

You can see in this diagram three different elements:

Data Lakehouse: we already talked about it in the previous article.
Metastore: also we explained it in the last article. We will talk about it more deeply in the coming articles.
Data Warehouse: many times you will need to implement star schemas for creating data marts. Here, users can find meaningful data for creating dashboards, machine learning products or any other thing that users require. In this case, the Data Warehouse will be implemented on AWS Redshift.

Current situation (environment isolation)

Remember that if you want users to create data products as fast as possible, you will need to create at least one environment where these users can mess around with the stored data. In this isolated environment they will be able to break and change as many things as they want. Our production environment must be isolated from this and other environments because we do not want to break productive processes.

The problem with data.

We want users to be able to work with huge amounts of data in an easy and fast way, but we want them to do that in isolated environments from the productive one because we do not want them to break anything.

Data Warehouse, AWS Redshift.

All the environments have the same components but isolated one of each other.

Since the release of AWS Redshift RA3, because storage and computation are separated, users can decide if they want to increase either their storage or computational capabilities and only pay for what they need.

We will be using AWS Redshift RA3. Here you can find some useful links that explain further what are AWS Redshift and AWS Redshift RA3:

Data Warehouse, Redshift RA3.

With Redshift RA3 storage is located under the component called Redshift Managed Storage located in AWS S3. As you can see on the above diagram, compute nodes are separated from the storage.

You can find more information about RA3 in the following link: https://aws.amazon.com/blogs/big-data/use-amazon-redshift-ra3-with-managed-storage-in-your-modern-data-architecture/

Data Warehouse, integration and production environments.

In the integration environment we work with data as you can see in the pictures below.

In the production environment we have the exact same system but isolated from the integration environment. In production we find the exact same statements.

Data Warehouse, sharing data.

AWS Redshift RA3 includes something called data sharing. With data sharing we can access with read only permissions to Redshift data located in other Redshift servers and even in different accounts or environments.

Data sharing provides instant, granular, and high-performance access without copying data and data movement. You can query live data constantly across all consumers on different RA3 clusters in the same AWS account, in a different AWS account, or in a different AWS Region. Queries accessing shared data use the compute resources of the consumer Amazon Redshift cluster and don’t impact the performance of the producer cluster.

Data Sharing.

With Data Sharing, we can configure the AWS Redshift in the integration environment for accessing the storage of the AWS Redshift located in the production environment.

You can find more information about it in the following link: https://aws.amazon.com/blogs/big-data/sharing-amazon-redshift-data-securely-across-amazon-redshift-clusters-for-workload-isolation/

Data Sharing, implementation.

In order to create a data sharing between the integration and production AWS Redshift servers, you can follow the next steps.

AWS Redshift RA3, production environment, statements to run:

CREATE DATASHARE meetup_sharing;
GRANT USAGE ON DATASHARE meetup_sharing TO ACCOUNT 'INTEGRATION';
ALTER DATASHARE meetup_sharing ADD SCHEMA schema;
ALTER DATASHARE meetup_sharing SET INCLUDENEW = TRUE FOR SCHEMA schema;

AWS Redshift RA3, integration environment, statements to run:

CREATE DATABASE meetup_pro FROM DATASHARE meetup_sharing OF ACCOUNT 'PRODUCTION'
CREATE EXTERNAL SCHEMA IF NOT EXISTS pro_schema FROM REDSHIFT DATABASE 'meetup_pro' SCHEMA 'schema';
GRANT USAGE ON SCHEMA pro_schema TO schema;

With the above configuration, when using the pro_ prefix in the integration environment, we will be accessing data located in the production one. This access is read only, so we can not modify that data in any way.

Conclusion.

Through this article we have covered how to resolve the following problems in a Data Lake implemented in AWS S3:

Users (data engineers, data analysts and data scientists) need to work in pre-production environments with the same amount of data as in production.
We want to have different and isolated environments: integration, production, etc.
Users need to work with the data in the easiest possible way.

Stay tuned for the next article about how to implement your own Data Platform with success.

I hope this article was useful. If you enjoy messing around with Big Data, Microservices, reverse engineering or any other computer stuff and want to share your experiences with me, just follow me.

How to build your own data platform. Episode 1: sharing data between environments. Data Lake implementation.

Gustavo Martin Morcuende — Tue, 29 Nov 2022 01:06:07 +0000

Introduction.

Data is the new oil. Companies want to make the most of the data they produce. For achieving this goal, there is a need for systems capable of consuming, processing, analysing, and presenting massive volumes of data. These systems need to be easy to use, but they also need to be reliable, able to detect problems and store data correctly. These and other issues are intended to be resolved by Data Platforms.

It is not an easy task to build a Data Platform. Multiple skill sets are needed, from infrastructure and programming to data management.

This article is the first, of what I hope will be a longer series of articles where we'll try to unravel the secrets of how to build a Data Platform that allows you to generate value-added products for your users.

What is a data platform?

We can discover definitions of what is a data platform just using our preferred web search engine. For example, I found the following definitions:

A data platform enables the acquisition, storage, preparation, delivery, and governance of your data, and adds a security layer for users and applications.
https://www.mongodb.com/what-is-a-data-platform
A data platform is a complete solution for ingesting, processing, analyzing and presenting the data generated by the systems, processes and infrastructures of the modern digital organization.
https://www.splunk.com/en_us/data-insider/what-is-a-data-platform.html

So, a data platform is a place where we can store data from multiple sources. Also a data platform provides users with the required tools for searching, working and transforming that data, with the goal of creating some kinds of products. These products could be dashboards with useful insights, machine learning products, etc, etc.

What is a data platform? Very simplified diagram.

In this diagram we can find all the basic components that create a data platform (we are not trying to describe a Data Mesh or a Data Management Platform, those things will be left out for other future articles) You can find the same components with other names but same functionality in other diagrams describing other data platforms. In this diagram we can find these components:

Data Sources: databases, REST APIs, event buses, analytics tools, etc, etc.
Consumption: tools for consuming the data sources.
Storage: the place where the consumed data will be located.
Security layer: component in charge of providing authentication, authorization and auditory.
Processing: programs or tools that will enable us to work with the stored data.
Data Catalog: because the amount of stored data will be huge, we need a tool that will make easy for users to find the data that they need.
Tableau, Qlik, Kubeflow, MLflow, etc, etc: data will be used for some goal. Typically this goal could be to create a dashboard with meaningful diagrams, create models for machine learning and many other things.

This first article will be focusing on the storage layer, so from now on, we will talk only about that component.

Storage layer.

Of course, the storage layer is the place where the data is stored. Because the amount of data to be stored is huge, we can not use HDD or SSD data storages, we need something cheaper. In this case we will be talking about AWS S3 because we are working with Amazon Web Services. For Azure, you could use Azure Data Lake Storage Gen2. If you are working with Google Cloud, you could use Google Cloud Storage. It does not matter what storage you use as long as it is cheap and can store a huge amount of data.

You can see in this diagram three different elements:

Data Lakehouse: it is the evolution of the traditional Data Lake. Data Lakehouse implements all the capabilities of a Data Lake plus ACID transactions. You can find more information about Lakehouses in this link.

Usually in a Data Lakehouse or a Data Lake you can find different zones for storing data. The number of zones that you can find depends on how you want to classify your data. How to create and classify the data in your Data Lake or Lakehouse is a complicated matter that will be treated in a future article. The Data Lake is the first place where the consumed data is stored. Sometimes it is just meaningless raw data.

Data Warehouse: many times you will need to implement star schemas for creating data marts in order to make easy for users the use of the stored data. Here, users can find meaningful data for creating dashboards, machine learning products or any other thing that users require.
Metastore: data is stored in the blob storage, if you want to use this data as if it was stored in a traditional database we need an element for translating schemas and table names to folders and files in the blob storage. This translation is made by the metastore.

This article does not try to deeply explain how the above three elements work. Those explanations will be left out for other future articles.

Current situation (environment isolation)

If you want users to create data products as fast as possible, you will need to create at least one environment where these users can mess around with the stored data. In this isolated environment they will be able to break and change as many things as they want. Our production environment must be isolated from this and other environments because we do not want to break productive processes. Different and isolated environments will exist. These environments contain the same processing and storage layers but these layers are isolated in their own environments. So notebooks in the sandbox environment can not break data stored in the storage layer from the production environment.

The problem with data.

Data engineers, data analysts, data scientists and data people in general who work with big data require huge amounts of data in order to implement, develop and test their applications. These applications could be ETLs, ELTs, notebooks, dashboards, etc, etc.

In a healthy system, these users should be able to work in a safe environment where they can be sure that they do not break anything that already works in production when trying to implement new solutions. We need to create isolated environments. These environments could be sandbox, integration, production environment, etc, etc.
The problem with having different and isolated environments is that, in no productive environments, the amount of data will probably be much lower than the one that will be generated in production.

So now, we face the following problem: we want users to be able to work with huge amounts of data in an easy and fast way, but we want them to do that in isolated environments from the productive one because we do not want them to break anything.

The solution 1.

Remember that we have data sources, and those data sources must be connected to our different and isolated environments. We could ask those data sources to send us the same amount of data as they are sending in the productive environment.

The problem with this solution is that, in many cases, those data sources have their own no preproductive environments and it is impossible for them to generate the same amount of data in the rest of the environments as in the production environment. Also, they will not be willing to connect our own no preproductive environments to their productive ones because we could break their environments.

This solution in many cases will not work.

The solution 2.

Another solution could be as simple as implementing a job for copying data from the storage located in the productive environment to the no productive one. For example, a Jenkins job.

The problem with this solution is that copying huge amounts of data is not fast and also, the job can break easily for multiple reasons (not having the right permissions, the right amount of memory for moving all the required data, etc, etc)

This solution does not ease the development of new applications because the copying process is slow, sometimes will not work, and data is not immediately available.

The solution 3.

What our users need is to have access to data generated in the production environment from the tools running in the no productive environments. We need to provide a solution where applications like notebooks running in for example the integration environment can access the storage located in the productive one.

This solution will work in all cases. This is the solution that we are going to explain in this article focusing on the component related to the Data Lake. In a next article we will explain the same solution implemented in a Data Warehouse.

Data Lake, AWS S3.

Notebooks, Spark jobs, clusters, etc, etc, run in Amazon virtual servers called EC2.
These virtual servers require permissions for accessing AWS S3. These permissions are given by IAM Roles.
We will be working with Amazon Web Services. As we said before, because the amount of data to be stored is huge, we can not use HDD or SSD data storages, we need something cheaper. In this case we will be talking about AWS S3.
Also, in order to make easy the use of the Data Lake, we can implement metastores on the top of it. For example, Hive Metastore or Glue Catalog. We are not going to explain deeply how a metastore works, that will be left for another future article.

Data Lake, integration and production environments.

In the integration environment we have two options for working with the data. With or without using a metastore.

In the production environment we have the exact same system but isolated from the integration environment. In production we find the exact same two options.

As you can see, the metastore allows us to use the data located in the Data Lake as it was a normal database. Also, we can see that the metastore does not store data but the metadata that allows us to find the real stored data in AWS S3. With the metastore, users can have access to the data in the Data Lake in an easier way because they can use SQL statements as they do in any other database.

Data Lake, sharing data.

When users run their notebooks or any other application from the integration environment they need to have access to the production data located in the storage zone of the production environment.

Remember that those notebooks and applications run in Amazon virtual servers called Amazon EC2 instances, and for accessing the data located in AWS S3 they use IAM Roles (the permissions for accessing the data) We can modify the IAM Role in the (for example) integration environment in order to allow EC2 instances to access data located in the productive storage zone.

IAM Role configuration.

For example, for being able to access to S3 integration and production folders we can configure the IAM Role in the following way:

Any application running on a machine with this IAM Role can read data from production and integration and can only modify the data located in the integration environment. So the productive data is not modified in any way.

Applying the solution.

Once we have applied the above configuration in the IAM Role, users have direct access to the data located in the productive environment, for example from the integration environment.

Can we do it better?

With this configuration users, from for example their notebooks, can access the productive data and work with it without being able to modify it. But, we know, by means of a metastore, users can access the data even in an easier way. So the question is: can we use metastores with this solution?

We will see how to do it in the next section of this article.

Data Lake, sharing data. Waggle Dance.

Waggle Dance is a request routing Hive metastore proxy that allows tables to be concurrently accessed across multiple Hive deployments.

In short, Waggle Dance provides a unified endpoint with which you can describe, query, and join tables that may exist in multiple distinct Hive deployments. Such deployments may exist in disparate regions, accounts, or clouds (security and network permitting).

For further information follow this link: https://github.com/ExpediaGroup/waggle-dance

Now, when asking for some table from the integration environment, and based on some configuration, the Waggle Dance living in the integration environment decides if the metastore to be asked resides either in the production or integration environment.

For example, this configuration could be based on some prefix. In the below example, the pro_prefix. When using this prefix the data to be retrieved will be located in the production environment instead of the integration one.

Conclusion.

Through this article we have covered how to resolve the following problems in a Data Lake implemented in AWS S3:

Users (data engineers, data analysts and data scientists) need to work in pre-production environments with the same amount of data as in production.
We want to have different and isolated environments: integration, production, etc.
Users need to work with the data in the easiest possible way.

Stay tuned for the next article about how to share data with AWS Redshift and many others that will follow about how to implement your own Data Platform with success.

I hope this article was useful. If you enjoy messing around with Big Data, Microservices, reverse engineering or any other computer stuff and want to share your experiences with me, just follow me.

Rózsa Politzer/Péter La madre fundadora de la Teoría de la Recursividad

Wanda Delisio — Thu, 19 May 2022 12:03:43 +0000

Cuando postergas algo y tu terapeuta te recomienda que empieces por hacer una pequeña tarea y eso te lleva a dar un paso más y otro y otro… Y de pronto aquello tan grande que querías evitar lo has resuelto a base de dividirlo en pequeñas porciones.

Eso es a lo que Rózsa Péter dedicó toda su vida: La recursividad.

Las funciones recursivas están detrás del motor de búsqueda de Google y también de Google Maps, del Trading, de los modelos de Machine Learning, de juegos como el Apalabrados o el mítico Buscaminas, de métodos de ordenación como MergeSort, etc.

Rózsa Politzer (luego Péter). Nacida en Budapest (Hungría), 1905. Matemática. Madre fundadora de la Teoría de la Recursividad. Práctica, puesto que es quien aplica por primera vez la recursividad a la computación. Gran comunicadora, porque nos lo explica en su libro “Recursive Functions* in Computer Theory”.

*Las funciones recursivas son funciones que se llaman a sí mismas durante su propia ejecución.

Nace en el seno de una familia **judía **de clase media-alta.

Empieza a estudiar Química porque su hermano mayor está estudiando Medicina y su padre decide que así, Rozsa, podrá ser útil para su hermano… Pero su destino era otro.

Al asistir a una conferencia sobre las series de Fourier* descubre su vocación y es inspirada para crear lo que luego serán los algoritmos recursivos.

*Herramienta matemática básica del análisis de Fourier empleado para analizar funciones periódicas a través de la descomposición de dicha función en una **suma infinita de funciones sinusoidales mucho más simples**

Durante este cambio de vocación sufrió el ahora conocido Síndrome del impostor:

“Cuando comencé mi educación universitaria, todavía tenía muchas dudas sobre si era lo suficientemente buena para las matemáticas. Entonces un compañero me dijo las palabras decisivas: no es que yo sea digno de ocuparme de las matemáticas, sino que las matemáticas son dignas de ocuparse”

Con 22 años se gradúa en Matemáticas. Empezó su investigación de posgrado sobre la teoría de los números pero al enterarse de que ya estaba probada con anterioridad, se retiró y se dedicó a la poesía durante un tiempo. La literatura alemana de Goethe y su amiga dramaturga, Béla Lay, tuvieron una gran influencia en ella.

Además, debido a la Gran Depresion, Hungría se alía con la Italia fascista y la Alemania nazi para incrementar su comercio. Eso provoca un giro a la derecha en las instituciones y Rózsa, al igual que otras personas, recibe presiones para cambiar su apellido judío por uno “más húngaro”. De ahí el cambio de Politzer a Péter.

Con 27 años presenta en el ICM (International Congress of Mathematicians) la “Teoría de las Funciones Recursivas”.

Con 30 años obtiene su doctorado cum laude y con 31 presenta una ponencia en el ICM titulada "Sobre las funciones recursivas de segundo paso".

Justo en ese momento que su carrera estaba despegando el gobierno húngaro pronazi prohibía ejercer la enseñanza a todas las personas judías. Así que sólo puede dar clases particulares.

Es entonces cuando se interesa por hacer llegar las Matemáticas al común de la sociedad y empieza a escribir "Jugando con el Infinito. Exploraciones y excursiones matemáticas". (Quizás ahora lo llamaríamos “El infinito explicado para dummies”)

Lo publica con 38 años y es una de las mejores introducciones a este tema y a todo el campo de las matemáticas. Al dividir su libro en 3 partes:

El aprendiz de brujo
El papel creativo de la forma
La autocrítica de la razón pura

Péter desarrolla su material en 22 capítulos que suenan casi demasiado atractivos para ser verdad: jugar con los dedos, colorear la serie de números grises, volvemos a atrapar el infinito, etc.

Con 40 años consigue por primera vez trabajo de profesora, ya que hasta entonces debido a la influencia nazi no le había sido posible.

Con 46 publicó “Recursive Functions”, el primer libro específico sobre las funciones recursivas.

Y cuando cumple los 50 vuelve a la universidad donde estudió, pero esta vez como profesora. Donde se gana el cariño del alumnado que la llama la “tía Rózsa”.

Con 68 años fue la primera mujer miembro de la Academia Húngara de Ciencias.

Durante los años 60 se empiezan a utilizar las funciones recursivas, en las que ella trabajó, en los lenguajes de programación.

Ella recoge todos los resultados conseguidos en su libro “Recursive functions in computer theory” que se publica 6 meses después de su muerte por cáncer en 1977.

P.D.: Si vas a usar la recursividad en tu código, en nombre de la tía Rózsa, recuerda siempre agregar una condición de salida. De lo contrario entrarás en un bucle infinito. De lo contrario entrarás en un bucle infinito. De lo contrario entrarás en un bucle infinito. De lo contrario entrarás en un bucle infinito. De lo contrario entrarás en un bucle infinito. De lo contrario entrarás en un bucle infinito. [...]

First steps to functional programming with Kotlin

ArnauG — Tue, 22 Feb 2022 15:33:06 +0000

All the code in this post is in:

ArnauG / MasterMindSolver

Exercise to resolve Mastermind code solver

In functional programming all the elements can be understood as functions and the source code can be executed by sequential calls of functions. On the other hand we do not assign values independently. A function can be imagined as a variable of the program. It can be reused and always return a result (it has no side effects).

These are the main characteristics of functional programming:

Uses Immutable data.
Focus is on: “What you are doing”
Supports Parallel Programming
Its functions have no-side effects
Flow Control is done using function calls & function calls with recursion
The program have not state
Supports both "Abstraction over Data" and "Abstraction over Behaviour".
It’s easy to combine with imperative programming

Now stop writing and let’s get down to work. To exemplify how to transform a procedural code to functional code I am going to codify a MasterMind solver. Mastermind is a code-breaking game for two players. A code is made up 4 coloured pins and their position. I will use 6 colours (that we will represent with letters from A to F) to choose from and the same colour can be repeated multiple times:

ACDF
AABC

The game play is as follows:

The second player (the one that is guessing) sets out a series of pins in order to guess the code. The first player (that defined the secret code) then provides some feedback to the player in light of how close they are to the correct combination.

The feedback is as follows:

Number of pins that are both the right colour and position
Number of pins that are correct in colour but in the wrong position

Examples:

Secret:  AABC, Guess: ABED, Result: rightPosition: 1, wrongPosition: 1
Secret:  AABC, Guess: ABAD, Result: rightPosition: 1, wrongPosition: 2

Now I am going to show a possible solution using procedural programming:

data class Evaluation(val rightPosition: Int, val wrongPosition: Int)

private const val TOTAL_MASTER_MIND_POSITIONS = 4

fun evaluateGuess(secret: String, guess: String): Evaluation {
  var guessList = guess.toCharArray().toMutableList()
  var secretList = secret.toCharArray().toMutableList()
  var removed: Int = 0
  for (i in 0 until TOTAL_MASTER_MIND_POSITIONS) {
    if (guess[i] == secret[i]) {
      guessList.removeAt(i - removed)
      secretList.removeAt(i - removed)
      removed++
    }
  }

  var rightPosition = TOTAL_MASTER_MIND_POSITIONS - secretList.size
  var wrongPosition: Int = 0

  removed = 0
  for (i in 0 until secretList.size) {
    var currentChar = guessList[i - removed]
    if (secretList.contains(currentChar)) {
      secretList.remove(currentChar)
      guessList.remove(currentChar)
      wrongPosition++
      removed++
    }
  }
  return Evaluation(rightPosition, wrongPosition)
}

In the first part of the code “right position calculation” we check position coincidences and remove the corresponding characters from each array. Then looking at the size of the resultant array we can calculate the number of coincidences. In the second part we do a similar approach passing each time through the remaining secret array.

Now we can start with a functional approach, kotlifying (use kotlin colections api to solve the problem) a little the code. In the code below we can see a possible solution:

// secret: ABCD, guess: AFED
fun evaluateGuess(secret: String, guess: String): Evaluation {
  return secret.zip(guess)
    //[(A,A),(B,F),(C,E),(D,D)]
    .filter { it.first != it.second }
    //[(B,F),(C,E)]
    .unzip()
    //[BC,FE]
    .let {
      var rightPosition = TOTAL_MASTER_MIND_POSITIONS - it.first.size
      generateEvaluationWithNumberOfAppearances(Evaluation(rightPosition, 0), it.first, it.second)
    }
}

private fun generateEvaluationWithNumberOfAppearances(
  evaluation: Evaluation,
  secret: List<Char>,
  guess: List<Char>
): Evaluation =
  guess.firstOrNull()
    .let {
      if (it == null)
        return evaluation
      var position = secret.indexOf(it)
      var secretMutable = secret.toMutableList()//Kotlin list interface not allow mutability
      var wrongPosition = 0
      if (position >= 0) {
        secretMutable.removeAt(position)
        wrongPosition++
      }
      // Flow control using recurrency
      wrongPosition +=
        generateEvaluationWithNumberOfAppearances(evaluation, secretMutable, guess.drop(1)).wrongPosition
      Evaluation(evaluation.rightPosition, wrongPosition)
    }

To resolve the first part of the problem we use the kotlin api extension for collections. Those are very useful and give the developers a powerful tool to manipulate them. Let’s see what’s going on.

// secret: ABCD, guess: AFED
fun evaluateGuess(secret: String, guess: String): Evaluation {
  return secret.zip(guess)
    //[(A,A),(B,F),(C,E),(D,D)]
    .filter { it.first != it.second }
    //[(B,F),(C,E)]
    .unzip()
    //[BC,FE]
    .let {
      var rightPosition = TOTAL_MASTER_MIND_POSITIONS - it.first.size
      generateEvaluationWithNumberOfAppearances(Evaluation(rightPosition, 0), it.first, it.second)
    }
}

In the second part I choose a different approach to walk through some of the main characteristics of the functional programming paradigm as mutability and Flow control using recurrency. We can see in the example below that the level of abstraction is very similar to the procedural example.

private fun generateEvaluationWithNumberOfAppearances(
  evaluation: Evaluation,
  secret: List<Char>,
  guess: List<Char>
): Evaluation =
  guess.firstOrNull()
    .let {
      if (it == null)
        return evaluation
      var position = secret.indexOf(it)
      var secretMutable = secret.toMutableList()//Kotlin list interface not allow mutability
      var wrongPosition = 0
      if (position >= 0) {
        secretMutable.removeAt(position)
        wrongPosition++
      }
      // Flow control using recurrency
      wrongPosition +=
        generateEvaluationWithNumberOfAppearances(evaluation, secretMutable, guess.drop(1)).wrongPosition
      Evaluation(evaluation.rightPosition, wrongPosition)
    }

To finish I want to show another example that combines imperative and functional programming given us a more elegant code :

// Code extracted from coursera course Java to Kotlin
fun evaluateGuess(secret: String, guess: String): Evaluation {

  val rightPositions = secret.zip(guess).count { it.first == it.second }

  val commonLetters = "ABCDEF".sumBy { ch ->

      Math.min(secret.count { it == ch }, guess.count { it == ch })
  }
  return Evaluation(rightPositions, commonLetters - rightPositions)
}

As we can see using Kotlin API we have a huge versatility that can help us to introduce functional programming with a very little effort. And learning to use this powerful programming language gave us awesome results.

Bibliography:

1.- https://www.coursera.org/learn/kotlin-for-java-developers
2.- https://es.wikipedia.org/wiki/Programación_funcional
3.- https://en.wikipedia.org/wiki/Mastermind_(board_game)

Cómo hemos desarrollado nuestro modelo de Product Discovery en Adevinta Spain

Víctor Solà — Wed, 16 Feb 2022 09:20:50 +0000

En Adevinta Spain llevamos dos años invirtiendo en mejorar todos los procesos relacionados con una de las fases más clave del desarrollo de un producto digital: la fase de descubrimiento, en inglés Product Discovery. En este artículo explicaré el porqué de esta inversión estratégica, los detalles de lo que estamos haciendo y lo que hemos aprendido durante este proceso.

¿Cómo trabajamos en Adevinta Spain?

Desde hace ya algunos años tenemos una cultura y metodología propia de trabajo: PEAK (Prioritization, Empowerment, Alignment, Knowledge). Es un marco que nos ayuda en el día a día a tomar decisiones, organizarnos mejor y tener más visibilidad y autonomía. Si te interesa entender mejor qué es PEAK, te recomiendo que veas esta charla.

Como muchas otras empresas de desarrollo de software, dentro del marco de PEAK, desarrollamos nuestros productos digitales de la siguiente forma:

Trabajamos en equipos de producto multidisciplinares (perfiles de producto, diseño, análisis de datos y desarrollo).
Nos organizamos en equipos con una misión clara.
Definimos objetivos y hacemos seguimiento de métricas de forma trimestral para alcanzar esos objetivos (OKRs).

Nos enfocamos en intentar mejorar de forma continua nuestros productos y la forma en la que trabajamos. Por ello, en el área de producto hemos invertido principalmente en 2 grandes iniciativas ligadas a la mejora constante:

Scrum Revamp: iniciativa para mejorar y estandarizar cómo utilizamos el framework de Scrum dentro de los equipos de producto.
Product Discovery: iniciativa enfocada a ayudar a los equipos de producto a entender mejor qué es lo siguiente que deben desarrollar para poder lograr sus objetivos e impactar sus métricas asociadas.

En este artículo nos centramos en explicar esta segunda iniciativa.

¿Por qué creímos necesario invertir en Product Discovery?

Poner a usuarios y clientes en el centro del desarrollo del producto forma parte de nuestros valores en Adevinta. Como organización estamos convencidos de que la forma de tener éxito a largo plazo es tener el mejor producto y, para lograrlo, creemos firmemente que el camino correcto es poner el foco en las necesidades implícitas y explícitas de nuestros usuarios y clientes.

Intentamos ser lo más eficientes posible. Queremos invertir nuestros recursos en desarrollar aquellas cosas que nuestros usuarios y clientes necesitan y no desperdiciar recursos por el camino. Pero no somos perfectos.

Hace unos años, cuando analizamos cómo veníamos desarrollando nuestros productos, nos dimos cuenta de que teníamos algunos problemas que nos alejaban de esta visión:

Diferencia en los procesos: no todos los equipos trabajábamos de la misma manera la fase de descubrimiento. Utilizábamos metodologías y herramientas distintas y dedicábamos un volumen de recursos bastante desigual en función del equipo.
Poca alineación con las necesidades de nuestros usuarios: a menudo nos encontrábamos desarrollando funcionalidades que no estaban alineadas de forma clara con una necesidad de usuario o cliente.
Poca exploración de posibles soluciones: debido a algunos sesgos cognitivos (que todos padecemos), algunos equipos se enamoraban de la primera solución que les venía a la mente para solucionar un problema u oportunidad. No explorábamos más opciones.
Foco en la funcionalidad en vez de en la necesidad: muchas veces nos focalizábamos en entregar funcionalidades en vez de entregar valor a usuarios y clientes.

Con el fin de solucionarlos, decidimos empezar a trabajar en una iniciativa que nos ayuda a conseguir los siguientes objetivos:

Establecer un marco de trabajo estandarizado entre los distintos equipos de la organización para la fase de descubrimiento.
Conseguir que una mayor parte de los desarrollos estén focalizados en solventar necesidades de nuestros usuarios y clientes.
Explorar múltiples posibles soluciones para un problema u oportunidad, y no quedarnos con la primera idea que nos viene a la mente.
Rebajar el nivel de incertidumbre de nuestros desarrollos. Estar más seguros de que lo que estamos desarrollando va a impactar a nuestros objetivos y métricas asociadas.
Reducir el desperdicio de recursos de desarrollo. Validar posibles soluciones antes de desarrollarlas por completo y descartar ideas de forma más rápida y económica.
Facilitar la innovación y la diferenciación.

¿Cómo empezó la iniciativa? El piloto de Dual Track

Para empezar, establecimos un grupo de trabajo heterogéneo, con perfiles de diversas áreas de la empresa (Producto, UX, Agile Coaches), para definir el marco de cómo queríamos que los equipos trabajaran en la fase de descubrimiento. Invertimos tiempo en aprender de lo que se estaba haciendo en la industria, lo que estábamos haciendo internamente y, sobre todo, en definir nuestro modelo futuro sobre la fase de Product Discovery.

A esta iniciativa piloto la llamamos Dual Track, con la intención de ayudar a los equipos a entender que hay 2 tipos de trabajo que suceden de forma simultánea: todo aquello que hacemos para entender qué debemos desarrollar (Product Discovery) y todo aquello que hacemos para desarrollar (Product Delivery).

Cuando tuvimos desarrollado el modelo de cómo queríamos trabajar la fase de descubrimiento, empezamos con formaciones a 3 equipos de producto. Las formaciones consistían en explicar el modelo, los beneficios y algunas técnicas en detalle a través de sesiones teóricas y prácticas. Estas sesiones las organizaban y dirigían nuestros perfiles de Research Ops.

Realizar el piloto nos permitió detectar muchas mejoras, tanto en el contenido de las formaciones como en la interacción entre los perfiles de Research Ops y los equipos.

Extendiendo la iniciativa a todo el grupo Adevinta

Esta misma necesidad de mejorar el conocimiento sobre Product Discovery que teníamos en Adevinta Spain, se detectó a nivel de todo el grupo Adevinta en el momento en que nosotros estábamos finalizando nuestro piloto. En base a esta necesidad, empezamos el desarrollo de una formación más global. Tomando de base los contenidos del piloto de Dual Track y complementándolos con la visión, el conocimiento y las experiencias de otros compañeros del grupo Adevinta.

Todo este trabajo acabó cristalizando en un curso sobre Product Discovery que os voy a detallar a continuación.

Nuestro curso sobre Product Discovery

La formación se compone de un curso online que se consume de forma autónoma y de sesiones presenciales donde se pone en práctica el contenido teórico. Las sesiones prácticas permiten a los equipos practicar las distintas técnicas aprendidas durante el curso, siempre trabajando sobre retos reales con los que el equipo de producto está lidiando en ese momento. Todas las sesiones prácticas son conducidas por un discovery coach que facilita y prepara la sesión.

También hacemos seguimiento del progreso del equipo a través de una plantilla que mide la madurez en distintas áreas de la fase de Discovery. El equipo rellena la plantilla justo antes de empezar la formación y otra vez a los 6 meses de haberla finalizado. Este sistema nos permite comparar la evolución y medir el impacto que ha tenido el curso en los distintos equipos.

El contenido del curso es el siguiente:

Módulo 1: Product Discovery basics
En este módulo hacemos una introducción a los conceptos más básicos:

Qué entendemos por Product Discovery y cuáles son sus distintas fases.
Qué entendemos por Product Delivery.
Qué es el concepto de Dual Track.
Cómo participan los distintos perfiles de un equipo multidisciplinar en la fase de Discovery.
Cómo incluimos la fase de Discovery en nuestras rutinas de Scrum.

Módulo 2: Alineamiento y captura de oportunidades
En este segundo módulo explicamos la importancia de estar alineados a nivel de equipo de producto para poder realizar Product Discovery de forma correcta y cómo podemos capturar y priorizar oportunidades para la consecución de nuestros objetivos. Algunas de las cosas que contamos en esta sección son:

Cómo funciona el framework de OKRs y cómo nos permite como equipo saber en qué nos debemos enfocar, cuáles son nuestros objetivos en un período de tiempo determinado y cómo vamos a medir el impacto en esos objetivos.
Qué es una oportunidad para un equipo de producto y cómo la diferenciamos de una solución. Cómo escribir una oportunidad de forma correcta.
Cómo podemos capturar oportunidades para nuestro equipo de producto. Tipos de fuentes de información sobre oportunidades para equipos de producto. Diferencias entre investigación cualitativa vs. cuantitativa y entre investigación actitudinal vs. investigación sobre comportamiento.
Cómo mapear las oportunidades de un objetivo específico a través de la técnica del Opportunity Solutions Tree. Esta técnica, creada y popularizada por Teresa Torres, es una de las técnicas clave del curso. Puedes aprender más sobre ella en este enlace.
Cómo priorizar las oportunidades a atacar primero. Qué factores se deben tener en cuenta cuando estamos priorizando oportunidades y cómo combinarlos.

Hay 2 sesiones prácticas en el módulo 2; la primera consiste en construir un opportunity solutions tree con un objetivo y key result del equipo. La segunda consiste en hacer un ejercicio de priorización de oportunidades para ver qué oportunidad atacamos primero.

Módulo 3: Explorando oportunidades
En el tercer módulo hablamos en detalle de cómo explorar una oportunidad y cómo adquirir conocimiento para poder plantear soluciones más efectivas a posteriori. Algunos de los contenidos en el módulo 3 son:

La técnica del Opportunity Canvas. Esta técnica, originalmente descrita por Jeff Patton en este artículo, nos ayuda como equipo de producto a mapear todo lo que sabemos sobre una oportunidad y, más importante, todo aquello que no sabemos y sobre lo que queremos investigar antes de lanzarnos a pensar en una solución. En Adevinta hemos construido nuestro propio Opportunity Canvas en función de nuestras necesidades.
Cómo seleccionar qué técnica de investigación es más adecuada en función de las preguntas o dudas que tenemos sobre una oportunidad.

La sesión práctica del módulo 3 consiste en construir un opportunity canvas para la oportunidad priorizada al final del módulo 2.

Módulo 4: Ideación y generación de hipótesis
Una vez tenemos la información suficiente sobre una oportunidad empezamos con la fase de ideación de posibles soluciones. En el módulo 4 hablamos de:

Qué es ideación y qué no cuando la realizamos en el contexto de Product Discovery.
Cómo articular un taller de ideación en un equipo de producto.
Distintas técnicas de ideación divergentes para crear múltiples posibles soluciones, como por ejemplo el “How might we …”, “The worst possible idea” o “Heaven and hell”.
Procesos para seleccionar opciones y priorizar soluciones a validar en la siguiente fase, como puede ser el “Combine and refine” o la técnica ICE de priorización.
Cómo definir hipótesis como fundamento para la experimentación.

La sesión práctica del módulo 4 consiste en realizar un taller de ideación, practicando distintas técnicas para generar soluciones sobre nuestra oportunidad priorizada anteriormente. El taller de ideación es una de las sesiones que recomendamos hacer de forma presencial.

Módulo 5: Validación
El módulo 5 es el último módulo de nuestro curso sobre Product Discovery y en él hablamos sobre cómo validar suposiciones sobre nuestras soluciones antes de desarrollarlas por completo en la fase de Product Delivery. En este módulo hablamos de:

Qué es una suposición y qué tipos de suposiciones existen.
Cómo balancear entre riesgo y time to market.
Cómo detectar y mapear suposiciones sobre nuestras soluciones y cómo priorizar cuáles hay que validar.
Técnicas de validación en la fase de Discovery, como por ejemplo el smoke test, el concept test, el concierge test o el extreme programming spike.
Cómo utilizar la técnica del Validation Canvas para organizar tu fase de validación.

La sesión práctica del módulo 5 consiste en completar el validation canvas para coordinar qué experimentos vamos a realizar como equipo para validar suposiciones sobre nuestra posible solución antes de pasar a la fase de delivery.

Qué hemos conseguido, aprendizajes y próximos pasos

A día de hoy han pasado por el curso más de 53 equipos de producto y, en total, hemos formado a más de 700 personas en todo el grupo Adevinta. Hemos progresado mucho pero todavía nos falta formar a varios equipos y seguir mejorando nuestros procesos. Además, hemos iterado de forma continuada la formación, introduciendo mejoras y nuevas técnicas sobre todo gracias al feedback que nos han proporcionado los asistentes en las diversas olas en las que hemos ido desplegando el curso.

El curso sobre Product Discovery no es un fin en sí mismo. Lo que pretendíamos con esta iniciativa era realmente impactar en cómo los equipos trabajan en su día a día haciendo desarrollo de producto. Hemos conseguido establecer unos mínimos comunes en cómo y cuándo los equipos deben hacer Discovery y hemos introducido ciertas técnicas que ahora los equipos utilizan de forma habitual.

Durante este proceso hemos aprendido mucho. Algunos aprendizajes clave y consejos:

Definir un marco metodológico para equipos muy diversos, con experiencias previas diferentes y madurez desigual no es tarea fácil. Se necesita tiempo, voluntad y, sobre todo, soporte a nivel ejecutivo.
Una formación es un producto que necesita iteración. En nuestro caso ha sido clave lanzar un piloto y aprender sobre el mismo antes de lanzar la formación a toda la organización. También la recogida de feedback continuo y la iteración del contenido nos ha permitido elevar el nivel del curso de forma constante.
Incluir a perfiles variados en la definición del modelo y en la creación de los contenidos de la formación ha enriquecido el contenido. Nos ha costado más tiempo pero al final ha sido más fácil que los equipos incorporen los aprendizajes.
Las sesiones prácticas son clave. El aprendizaje se produce a través de la práctica en situaciones reales de desarrollo de producto. Combinar teoría como base y práctica nos ha permitido que los equipos integren las técnicas de forma más rápida.
El acompañamiento es esencial. En nuestro caso el guiar las sesiones prácticas y hacer seguimiento y acompañamiento al equipo a través del perfil del discovery coach nos ha ayudado a que la formación no se vea como un esfuerzo puntual sino a provocar el cambio real en la forma de trabajar.

Agradecimientos y enlaces de interés

Para montar nuestro modelo (y también nuestro curso) de Product Discovery nos hemos inspirado en artículos y modelos ya existentes en la industria. A continuación os dejo una selección de algunos enlaces que nos han inspirado y que creo pueden ser interesantes para profundizar más:

Dual Track Agile by Marty Cagan
Dual Track Development is not Duel Track by Jeff Patton
Introduction to modern Product Discovery by Teresa Torres
Product Discovery, a Practical Guide for Product Teams by Tim Herbig
Opportunity Solutions Tree: Visualize your thinking by Teresa Torres
Opportunity Canvas by Jeff Patton
Design Kit Methods by Ideo.org
Forming Experimental Product Hypotheses by Chris Compston
Idea Validation - Much More Than Just A/B Experiments by Itamar Gilead

El desarrollo del curso de Product Discovery habría sido imposible sin el trabajo incansable de Alba, Ari, Austin, Julia, Liz, Simmone y Tarra.

En futuros artículos compartiremos más detalles sobre nuestro modelo y sobre cómo estamos aplicando algunas de las técnicas clave de nuestro curso de Product Discovery.

La foto de la portada es de Nobel Mitchell en Unsplash.

Data Platform: Qué es y cuáles son sus retos

Adevinta Eng. — Fri, 28 Jan 2022 12:43:26 +0000

¿Qué es un data Platform?

Data Platform es un producto clave en nuestra cultura data driven, como acelerador tecnológico para poder gestionar el dato como activo, y yendo más allá incluso como producto. Una Cloud Big Data Platform que debe dotar a nuestros usuarios de una infraestructura como servicio y herramientas de autoconsumo de la información en todo su pipeline de datos. Y todo ello acompañado de una cultura del dato como producto y una gobernanza computacional federada. Sí, hablamos de Data Mesh, y ahí tenéis bastante literatura de la mano de su creadora, Zhamak Dehghani.

Liderando un equipo Data Platform en Adevinta Spain
Adevinta Spain es un grupo de marketplaces líder en España formado por 6 marketplaces, que reciben a 1 de cada 2 internautas españoles cada día.

Como PO del equipo producto Data Platform en Adevinta Spain, mi misión es liderar la visión y estrategia del producto, con un equipo de desarrollo compuesto por Big Data Engineers, DataOps y Machine Learning Engineers.

Hace un año que me incorporé a Adevinta Spain y me enfrenté al gran reto como equipo de ser impulsores de la evolución de la compañía a nivel Data. En este tiempo nos hemos acercado más al negocio y los usuarios, porque las soluciones tecnológicas no son más que una respuesta a la estrategia y como tales deben ir acompañadas de personas y procesos.

Y ¿cómo acercar un mundo tan técnico a los usuarios? Pues ese es mi gran reto, hacer entendible lo complejo, entender la tecnología y entender al usuario, hablar ambos idiomas y trabajar como one team para construir un producto enfocado en valor.

El reto es grande porque nuestra Data Platform da servicio a todos los marketplaces con los que cuenta Adevinta en España (Fotocasa, Habitaclia, InfoJobs, coches.net, motos.net y Milanuncios). Y debemos equilibrar el dar un servicio global centralizado, y a su vez dar autonomía a los equipos/dominios de datos. Para no ser un cuello de botella y poder acelerar nuestra cultura data driven. Donde el usuario se preocupe por los datos, y los pueda incorporar en los procesos de decisión y construcción de productos en todos nuestros marketplaces.

El camino está iniciado y ya caminamos juntos tecnología, personas y procesos. Dónde desde Data Platform aportamos las últimas tecnologías Big Data y productos innovadores que puedan acelerar nuestra estrategia de compañía y data.

Nuestra Visión de Data Platform: ¿Dónde estamos hoy?

Pues estamos dando un servicio centralizado a nivel infraestructura a cada uno de nuestros marketplaces y/o dominios de datos, con una ingesta de datos masiva y con un catálogo central de discovery y gobernanza de la información.

Dedicando esfuerzos a automatizar procesos y dar herramientas a nuestros usuarios para que sean independientes, y sean los mínimos procesos los que dependan de nosotros. Porque tenemos la suerte de que cada marketplace cuenta con un equipo potente de Data Engineers, Data Analyst y Data Scientist para la construcción de productos data.

Cada uno de los dominios recolecta las fuentes de datos de interés, utiliza los productos para su ingesta, transforma los datos en las diferentes zonas lógicas de Data Lake y Datawarehouse. Y a partir de ahí, analyst y data scientist hacen su magia convirtiendo el dato en insight, dashboard de seguimiento o modelo de machine learning, que en última instancia convierte el dato en acción para la toma de decisiones y evolución de producto en todos nuestros marketplaces, mejorando el conocimiento del cliente y la experiencia de usuario.

El dominio es por tanto, dueño de su dato y de todos los procesos de transformación del mismo. A través de los cuales genera productos de datos que posteriormente comparte con el resto de marketplaces.

Y desde Data Platform ofrecemos la infraestructura y las herramientas para que los dominios puedan trabajar con los datos.

La infraestructura engloba engine, cómputo, scheduler, endpoints (sqlaas, notebooks, programmatic), networking, deploy y etc. En definitiva lo que el usuario no ve y dota de capacidades para realizar “la magia”.

Las herramientas de autoconsumo, que engloba las capacidades anteriores y aporta esa capa “user friendly” que el usuario requiere para realizar su día a día, preocupándose por el dato y nada más. Aquí vivimos en plena evolución porque la tendencia de democratizar la analítica hace que los perfiles sean dispares y debamos adaptar capas a skills requeridos. Así que, en este punto, hay un mundo por evolucionar.

Visión de Data Platform: ¿Hacia dónde vamos?

Hacia un data ownership asumido 100% por los dominios, donde el productor/dominio es el que gobierna el dato porque es el que lo conoce y sabe evolucionarlo para que su valor sea máximo. Donde nosotros como Data Platform facilitamos la infraestructura, las herramientas y los productos como servicio para que puedan ser independientes y llevarlo a cabo, garantizando la escalabilidad, y acelerando así la construcción de modelos de machine learning y la toma de decisiones basadas en datos. Y donde cada dominio construye y comparte sus productos de datos con el resto.

En esta transición es muy importante equilibrar las tres patas: personas, procesos y tecnología. Es por ello, que avanzamos en paralelo en:

La cultura de la compañía con el dato
La definición de políticas y procesos de data governance
Y en dotar de la tecnología (data platform) necesaria para acelerar la estrategia y acompañar a las personas y los procesos.

Porque solo se puede avanzar y acelerar juntos, no hay otro camino.

Escrito por Marta Díaz

Master en Business Intelligence y Big Data, Diplomada en estadística y Licenciada en Investigación y Técnicas de Mercado. Muy ligada al Gobierno del Dato, es miembro activo de Dama Spain en los Comités “Data Governance & Metadata” y “Data Quality & Content Management”. Actualmente desarrolla su actividad profesional en Adevinta Spain.

ENTREVISTA DigitalES: Juan Carlos Ruiz, un ‘arquitecto’ de páginas web detrás de Fotocasa

Adevinta Eng. — Thu, 27 Jan 2022 09:41:14 +0000

‘CRACKS de la tecnología’ es una serie semanal de entrevistas de DigitalES, a través de las que dan voz a esos profesionales TI que son absolutos genios de la tecnología en España. El objetivo es saber de ellos/as, conocer y reconocer el trabajo que realizan en las empresas en las que trabajan; saber qué les apasiona y qué consejos guardan para aquellos/as que vendrán detrás.

Juan Carlos Ruiz se inició en la programación a los 10 años. Siendo todavía un niño, diseñó un programa de gestión para su padre. Combinaba su inquietud por la informática con una pasión por la arquitectura, el diseño y el arte que aún conserva. Dos décadas después, este joven no diseña planos de viviendas, pero hace posible que muchos millones de personas compren y vendan sus casas a través de Internet.

Trabaja en el equipo de frontend de Fotocasa, el portal inmobiliario de Adevinta Spain, y hoy atiende a DigitalES desde Barcelona, la ciudad en la que siempre soñó vivir.

P.- Trabajar para un portal como Fotocasa, y encima desde la ciudad modernista por excelencia. ¡Te encaja como anillo al dedo!

R.- Desde pequeño tuve claro que quería vivir en Barcelona. Aun hoy, me parece una ciudad extraordinaria y tengo la suerte de que una gran compañía como Adevinta Spain ha decidido instalar aquí su sede mundial, así como la mayor parte de sus equipos de desarrollo web.

En Adevinta Spain, todo el desarrollo se hace in-house. No hay que olvidar que, para un gigante de portales de Internet (Fotocasa, habitaclia, InfoJobs, coches.net, motos.net y Milanuncios), cuestiones como el diseño, la usabilidad y la experiencia de usuario representan elementos esenciales de su modelo de negocio. La Web es el núcleo de su propuesta de valor, y por eso es tan importante que las personas que trabajan con el código sientan el proyecto como algo suyo.

P.- Ese compromiso con los proyectos al que aludes, ¿se promueve activamente en Adevinta Spain?

R.- Yo diría que sí. De un lado, se promueve un clima de trabajo donde la gente esté contenta y motivada, por ejemplo, permitiendo que propongamos nuevas funcionalidades o maneras de mejorar las ya existentes. Eso ayuda a que nos sintamos partícipes de los proyectos y de la empresa. Por otra parte, los trabajadores de Adevinta Spain recibimos continuamente formación sobre el negocio, lo cual nos hace entender mejor las necesidades de la empresa. Yo creo que, si conoces bien el producto, la calidad de tus desarrollos se va a ver muy incrementada.

"Cuando conoces bien el producto, la calidad de tus desarrollos se ve muy incrementada."

P.- ¿Qué hace exactamente un desarrollador en Adevinta Spain? ¿Cómo os estructuráis y organizáis?

R.- Existen equipos por cada vertical de negocio de Adevinta Spain y, por supuesto, recursos y herramientas que compartimos en toda la compañía. Cada equipo, a su vez, **cuenta con especialistas en los diferentes sub-campos en que puede dividirse el desarrollo **web, como desarrolladores frontend, backend, mobile (iOS / Android)… Y como equipo multidisciplinar también tenemos perfiles UX/UI, Data Insight, SEO y otros perfiles que requiera el proyecto. En realidad, todos tenemos una base de conocimiento sobre programación frontend y backend, pero por lo general nos ceñimos a nuestra área de especialización, como buen “equipo full-stack”.

Con respecto al trabajo en sí, aplicamos metodologías ágiles. Concretamente Scrum, que consiste en distribuir todos los nuevos desarrollos en sprints de dos semanas. En quince días, tenemos que ser capaces de programar nuevas funcionalidades y probarlas. Si funcionan, se llevan a Producción y, si no, iteramos o se descartan. ¡Y vuelta a empezar!

P.- El trabajo de desarrollador, en efecto, se ha sofisticado mucho en los últimos años. ¿Cómo explicas a qué te dedicas a personas que no conocen el mundo TIC?

R.- A mi madre, por ejemplo, empecé por contarle que mi trabajo consistía en aporrear el teclado y tomar mucho café. Después, le expliqué que una página web siempre tiene una parte visual, con la que interactúan los usuarios, y otra parte invisible, que es todo lo que hay detrás. Hoy por hoy, mi madre -y como ella, cada vez más personas- conoce la diferencia entre un desarrollador frontend y backend.

También ayuda que trabajemos para portales muy conocidos y reconocidos por la sociedad. Hablamos de 18.8 millones de usuarios únicos, es decir, 19.3 millones de personas que confían en los marketplaces de Adevinta Spain para encontrar lo que buscan. Es emocionante que el fruto de tu trabajo sean servicios que usa tanta gente…

"Es emocionante que el fruto de tu trabajo sean servicios que usa tanta gente para encontrar lo que buscan."

P.- Si tus padres no trabajaban en nada cercano a la informática, ¿de dónde crees que te vino la vocación tecnológica?

R.- Fue algo gradual. Me apuntaron a clases extraescolares de mecanografía con máquina de escribir. [Bromea: “¡Creo que llegué a hacer músculo en los meñiques!”] Después empecé con la mecanografía con ordenador y, a partir de ahí, me fui interesando más y más por la ofimática. Descubrí que podía hacer fórmulas en Excel, bases de datos en Access… El profesor vio que yo mostraba interés y me enseñó los fundamentos de HTML, CSS, JavaScript y PHP.

Incluso le monté un programa de gestión a mi padre cuando tenía 10 años. Mi vocación siempre fue la de arquitecto, pero la informática me gustaba y se me daba bien, y me fui dejando llevar por ese camino. Así que nunca llegué a la Facultad de Arquitectura, pero me gusta pensar que, en cierto modo, he acabado siendo un “arquitecto de software”.

*P.- Al respecto de la salida profesional que tiene aprender programación, ¿qué perfiles son los que más escasean?
*
R.- En España hay muchísimo talento, pero al mismo tiempo, por esa sofisticación de la que hablábamos antes, cuesta encontrar buenos especialistas. Con la pandemia, diría que la dificultad para encontrar programadores es menor, porque el teletrabajo hace posible que busquemos candidatos en otras ciudades, provincias e incluso países de habla hispana.

Después, cada nueva incorporación lleva a cabo su propio proceso de onboarding, que suele consistir en un pequeño proyecto con el que se va familiarizando con el resto del staff técnico y con las herramientas que usamos.

P.- ¿Y cómo los seleccionáis?

R.- En Adevinta Spain hemos cambiado recientemente el modo en que realizamos la selección de personas, precisamente para ser capaces de identificar mejor quién tiene verdadera madera de desarrollador/a. Así, primero intentamos** romper el hielo con el chico o la chica, tomando un café** y hablando de nuestros hobbies o de cualquier otra cosa. Después de un rato, le planteamos una prueba técnica que dura solamente una hora. Nada de pruebas complejísimas de una semana de duración; eso lo hacíamos antes y generaba muchísimo estrés a los/as candidatos/as. Algunos de nosotros expusimos ese problema a nuestros superiores, que escucharon ese feedback y, como resultado, hoy el proceso de captación es mucho más ágil.

Claro está, las pruebas técnicas pueden jugarte una mala pasada. Recuerdo que yo estaba nerviosísimo cuando me tocó hacerla. Sin embargo, intentamos ver más allá y proyectar si esa persona encajaría en el equipo, y durante la entrevista procuramos que esté cómoda. Además, hacemos esfuerzos conscientes por aumentar la diversidad y que haya más mujeres en los equipos de desarrollo.

"Hacemos esfuerzos conscientes por aumentar la diversidad y que haya más mujeres en los equipos de desarrollo."

P.- ¿En qué sueles tú fijarte en las entrevistas de trabajo? ¿Qué consejo les darías a los jóvenes que quieren llegar a ser grandes desarrolladores frontend el día de mañana?

R.- Siempre les pregunto por qué otras cosas han hecho y qué aficiones tienen. Me interesan mucho esos complementos o soft skills. Creo que intereses como el dibujo, la pintura o el diseño te aportan cuidado por el detalle, por el pixel. Y eso, al final, se traslada a la calidad de tu trabajo.