-
- ¡Y montaremos una conferencia de Go!
-
- ¡Venga! ¡Y conseguiremos que Dave Cheney participe!
-
- Si claro… ¡Y tendremos sponsors top como JetBrains!
Si hubiéramos tenido que apostar, probablemente nos la hubiéramos imaginado bastante diferente (física, de ámbito nacional, etc), pero la verdad es que ese diálogo (o muy similar) podría extraerse de varias de las conversaciones que tuvimos durante la primera mitad del año pasado, cuándo empezábamos a definir a dónde queríamos llegar con todo esto de Friends of Go.
Ahora han pasado ya unas 72h aproximadamente y lo único que podemos decir es que el pasado domingo todo nos salió a pedir de boca (o incluso mejor). Los que nos seguís en Twitter probablemente ya os habéis enterado, pero por si habéis estado desconectados: el pasado domingo 26 de abril organizamos la GoRemoteFest.
Un solo día, un solo track, ocho charlas de 30 minutos, una MC que lo hizo espectacular (Natalie Pistunovich) y ponentes ampliamente reconocidos, como Dave Cheney, Ellen Körbes o Mat Ryer, entre otros. Y sin olvidarnos de un compañero de lujo con quién sin él nada de esto hubiera sido posible (Idir Ouhab).
Los números también estuvieron por encima de cualquiera de nuestras predicciones: pico máximo de 330 visualizaciones concurrentes y un total de unos 1500 (aprox) usuarios únicos durante la mañana. Además, +300 seguidores en Twitter y YouTube en tan solo unas pocas horas. Eso por no hablar del humo que echó Twitter durante esa mañana así como el chat del directo de YouTube.
Pero, sinceramente, el propósito de éste artículo no es otro que el de que de un vistazo rápido podáis saber de qué se habló en cada una de las charlas que tuvieron lugar en la conferencia (como solemos hacer en todos nuestros artículos de conferencias), cuyos vídeos ya estamos subiendo al canal oficial de YouTube. Y que también iremos anunciando por la cuenta oficial de Twitter.
Así que, sin más dilación, ¡al lío!
Dave Cheney - Maps in detail
El bueno de Dave no fue designado el responsable de abrir la conferencia de forma aleatoria, de hecho, las razones fueron múltiples. En primer lugar, y probablemente la mayor de las razones, fue porqué él vive actualmente en Sídney y esta era la única forma que teníamos de que pudiera participar en un horario relativamente razonable para él. Pero además, porqué era uno de los platos fuertes de la jornada y porqué la temática de la charla requería tener las pilas bien cargadas.
La charla empezó con una explicación sobre qué es una función de map y una función de hash para después mostrar como los maps en Go internamente están implementados con una estructura de hashmap. Posteriormente analizó la importancia de algunas de las características de una función de hash (como la estabilidad, la resistencia a colisiones, etc) así como algunas de las características de los hashmap (como que su coste de búsqueda es O(1)*). Para finalizar, nos mostró las diferencias de la implementación de Go con otros lenguajes populares como Java o C++ y como éste nos consigue proporcionar dicha estructura sin contar con genéricos.
Si queréis entrar más en detalle, podéis revisar este artículo de su propio blog.
Kyle Redelinghuys - Building the COVID19 API
En la segunda charla de la mañana, Kyle nos mostró como iteró (en muy pocas semanas) la API de covid19api.com, de la cual es el creador y actual mantenedor principal para poder atender más de 20 millones de peticiones. En ella nos mostró los diferentes tipos de problemáticas a los que se tuvo que enfrentar durante este proceso y, quizás un poco contra pronóstico, llegó a remarcar que el mayor de los retos fue gestionar la ingesta de múltiples fuentes de datos con formatos y estructuras muy diferentes, incluso por encima del reto de atender un alto muy número de peticiones.
Soportar múltiples formatos, trabajar con datos “en brutos”, escalar un código
MVP y hacer frente a errores como el popular
too many connections
fueron solo algunas de las pequeñas pinceladas que compartió con nosotros. Además, también comentó
que el proyecto está actualmente en busca de colaboradores. Para los más curiosos, entre las tecnologías usadas para el
desarrollo de dicha API nos encontramos con la base de datos Redis, el ORM GORM,
el framework web Echo y el rate-limiter HTTP tollbooth.
Ellen Körbes - The Quest for the Fastest Deployment Time
Después llegó el turnó de la queridísima Ellen, quién nos mostró, en un proceso incremental, como reducir el feedback loop en los entornos de desarrollo desde un orden de magnitud de pocos minutos a pocos segundos. Si bien es cierto que varias de las técnicas mostradas fueron muy específicas, y que se centró en un ecosistema específico (Go + Kubernetes), lo cierto es que llegó a cumplir con lo prometido.
Entre las técnicas que presentó durante la charla podemos encontrar: vendoring, cache layer, la eliminación de los artefactos de debug, glitch, la compilación local de los binarios y el ultimate packer for executables, entre otros. Además también nos recomendó la lectura de ésta serie de artículos sobre como reducir las imágenes de Docker así como nos definió las reglas a seguir para poder conseguir los mismos resultados en otros entornos:
- No confies en el CI para el development feedback.
- Usa una herramienta de MDX (Tilt, Garden, Telepresence, Skaffold, etc).
- Usa cualquier hack, cheat y truco (por “guarro” que sea) que conozcas.
Ole Bulbuk - Tales From Event Sourcing Pastures
A la mitad del evento (y de la mañana) llegamos con la charla de Ole, quién por cierto está buscando trabajo (para aquellos interesados en fichar a una estrella gopher). Durante su charla no llegó a bajar al terreno práctico (y su aplicación en Go), pero no por ello la charla fue menos interesante. En ella fue desde la teória más básica de event sourcing y de CQRS hasta conceptos más avanzados. También nos mostró los beneficios y las contraprestaciones (o complicaciones) de cada una de esas estrategias así como el tipo de proyectos o casos de uso en los que mejor se pueden aprovechar. Finalmente nos contó algunas de sus experiencias personales, como, por ejemplo, la repercusión que había tenido la entrada en vigor del nuevo RGPD con todos los datos almacenados en su event store.
Daniel Martí - What’s coming in Go 1.15
La segunda mitad del evento (y no por ello menos importante), empezó con la charla de Daniel, especialmente interesante para los más curiosos. Consideramos que son pocos los que se dedican a leer “de pe a pa” el changelog de todas las nuevas versiones, así como todas las propuestas o merge requests involucradas. Daniel es una de esas personas tan activas en la comunidad y que además tuvo la capacidad de transmitirnos toda esa información de una forma muy amena: todas las novedades que nos trae la nueva versión de Go 1.15 que será publicada durante el próximo mes de agosto en tan solo 15 minutos.
Esta versión, pese a verse afectada por la pandemia mundial del coronavirus (que ha afectado incluso a compañías tan grandes como Google), incluye muchas novedades interesantes, entre las resaltadas en la charla:
- un nuevo y mejorado linter
- la inclusión de la base de datos de zonas horarias (tzdata)
- múltiples helpers para los tests (
testing.TB.TempDir
,testing.T.Deadline
) - varias mejoras en el analizador de código estático (
cmd/vet
) - las escritura de valores en lugar de direcciones de memoria en los
panic
- ¡y muchas más!
Ya ha publicado las diapositivas de su charla así que os recomendamos echar un vistazo para entrar en detalle.
Robert Laszczak - Let’s build an event-driven application in 15 minutes
Y, por si explicar de forma amena en 15 minutos todas las novedades que traerá la nueva versión Go v1.15 no fuera suficiente reto, Robert protagonizó la sesión más valiente de la jornada: un live-coding para construir una aplicación event-driven en tan solo 15 minutos.
El creador de Watermill nos demostró que sabía de lo hablaba (a la vez que escribía), y en 15 minutos nos convirtió una aplicación síncrona (con peticiones HTTP, que es a lo que estamos acostumbrados), en una aplicación asíncrona basada en eventos por encima de Apache Kafka. Apenas un par de interfaces (una para el publisher y otra para el consumer) y unas pocas líneas de código le fueron más que suficientes para lograrlo.
Nathan Davies - When to choose a mo*@!#th?
Nathan fue el responsable de llevar a cabo la penúltima charla, cuyo resumen en dos palabras podría ser, como ahora está de moda decir: “unpopular opinion”. Pues, si bien es cierto que se centró en un caso real específico (lo cual también se agradece), nos mostró como una aplicación altamente fragmentada en diferentes servicios puede ser fácilmente refactorizada en un único servicio mucho más claro y definido. Su caso nos recordó un poco al de Kyle, pues al tratarse de un sistema de reconocimiento de copias en documentos, también tenía que ingerir y tratar múltiples formatos de entrada.
Sin embargo, nos mostró como con los recursos que nos ofrece el propio lenguaje: las interfaces (para definir los comportamientos de cada uno de los componentes del sistema), los canales (para definir el flujo de información entre los diferentes componentes) y las gorrutinas (para escalar cada uno de esos componentes), podemos construir un único servicio, con una definición mucho más clara y definida que un conglomerado de servicios de los qué, muchas veces, cuesta trazar el flujo de datos y de identificar la responsabilidad exacta (y sus boundaries) de cada uno.
Defer - Mat Ryer
Para cerrar, Mat nos explicó de nivel principiante a avanzado, cómo funciona la sentencia defer
, catalogada por el
mismo Mat como “la mejor funcionalidad de Go”. Cuáles son sus principales usos, los errores más comunes con la misma,
e incluso nos llegó a explicar como está implementada internamente. Además, también resolvió la que probablemente es la
duda más común relacionada con dicha sentencia: ¿se trata el defer
de un performance killer? Todo ello actualizado
con los últimos cambios en la versión más reciente de Go (v1.14).
En definitiva, todos juntos, en comunidad, disfrutamos de una mañana repleta de diversión y conocimiento gopher, de la que el 99% del feedback recibido ha sido positivo y qué, quién sabe, si el próximo año repetiremos. De momento parece que la comunidad lo tiene claro e incluso hay quién estaría encantado de que el evento se realizara dos veces al año.
Así que, ¡veremos qué ocurre el próximo año!