Speakers

A journey to Postgres Productivity with Go

We will begin our journey by taking a look at a few different reasons why you would want to use a persistent data store, a relational database, and finally why you should just use Postgres most of the time. Having established what it’s used for, we will begin looking at the myriad of ways that the Go community has developed for working with databases, and Postgres in particular.

Practical fuzzing in Go

Fuzzing is a commonly used technique among security engineers to find bugs and vulnerabilities in code. Its effectiveness has been proven over time to the point where some projects and companies have mandatory fuzzing coverage. The most common issue with fuzzing is that it is seen as a low-level arcane practice that does not apply to memory safe languages or that only hackers can use.With this session I will explain what fuzzing is, why it is useful and how to apply it to your code. I will provide detailed instructions and examples to get the attendees up and running to make their code more robust, correct and trustworthy.

Gopls for Go Tooling

You have had challenges with your development tools being inefficient and slowing you down. In this session, we will cover how we ended up in this situation and the promising future Gopls is working toward to enable higher productivity

We’ll look at the recent history of tools we have been using in Go development and the challenges we faced with them. We will then look at how Gopls is designed and why it is worth exploring.

Pie to Go: Automatically Translating Python Source to Idiomatic Go Code

Manually converting source code in one language to another is laborious. Existing approaches, often dubbed “transpilers” the JavaScript community, are insufficient for this purpose as they (1) produce code intended for machines, not humans; (2) work in the direction of going from stronger type systems to equivalent or weaker type systems.

This talk presents an approach that addresses both of these concerns. I will present how we successfully converted a project of several thousand lines of dynamically typed Python code into human-readable, fully typed, idiomatic Go source code. The program is built entirely in Go and consists of a Python parser, a static analyzer that does full-program analysis to understand what type(s) each Python object may be, and an output stage that converts this representation into idiomatic Go code.

The talk will show the audience how the program works and how to overcome the challenges of going from dynamically typed Python source code to fully typed Go source code. It will give the audience a better understanding of parsing source code into ASTs, how to analyze them and rewrite them to perform modifications, and lastly how to use Go’s excellent source code formatting to output properly formatted Go source code at the end.

Using Interfaces in Go

Most people find it difficult to fully grasp the concept of interfaces in golang and how powerful they can be, because the way interfaces are thought to newcomers in Golang is fundamentally flawed. Most people who pickup golang do so from some other languages and extrapolate knowledge of what interfaces are from there, when in actual fact, the concept of interfaces in these two couldn't be any more different. This talk will touch upon how interfaces are particularly different from interfaces in other languages, how that makes it more powerful and how they can be used to build better services simply by understanding the concept behind interfaces.

A Tale of Breadth-First Search

One of my passions is optimizing different algorithms. It might seem that those fancy fast algorithms you see are a spark of imagination and “just happen”. In practice, the way you get to them is much more incremental. For every good idea, there are at least five that failed.

One fundamental way of optimizing algorithms is:

• Measure
• Make a few hypotheses why those things in the profile are slow
• Formulate few solutions to each of the hypotheses
• Try all promising solutions (and observe for more hypotheses)
• Keep the best solution (if there is one)
• Keep the second-best solution around, just in case
• goto 1

In this talk, we’ll demonstrate and explain the principles. We’ll take a basic “Breadth-First Search” implementation and incrementally make it 2x faster on a single core. Then we’ll take these principles to multi-core and squeeze out further 2x. These improvements are accompanied by failures along the way.

The attendees will end up with a clearer understanding of how algorithms are developed and optimized.

Applying Proper Security Practices With JWT

Applying best practices when building your authentication system with JWT, can help minimize or totally eliminate any damage that may occur in the event that your application is compromised. Implementing JWT with proper security practices helps avoid major loopholes that may be harmful to your application. Using JWT for application authentication systems have proven to be very efficient and help save resources. One of the reasons for the popularity of JWT today is the straightforwardness towards its implementation. Many things come for free while implementing authentication with JWT, one of which is the signing algorithm used.

Controlling Distributed Energy Resources with Edge Computing and Go

With advancing technologies, energy distribution model has changed from being centralised to being distributed. We created a platform for distributing and running IoT apps, written in Go, on edge devices to monitor and control distributed energy resources such as photovoltaic and battery systems.

Better APIs with Shareable Validation Logic

Validating data at various points, like in clients and servers, is desirable. But keeping validation logic in sync between, say Go code and OpenAPI is prone to errors and toil. CUE addresses this issue with the ability to convert and combine various formats. This allows for some cool and exciting rewriting capabilities, such as generating a single documented OpenAPI spec from various sources and automated compatibility checks. It addresses the issue that validation logic can often not be consolidated into one place or format.

The demonstrated abilities are based on experience from the Istio pipeline and the author’s research into composing CRD schemas for Kubernetes.

The talk will demonstrate several conversions, including JSON schema, OpenAPI, and simple tricks in CUE itself.

Field Report: Building a game engine for 300 defcon hackers to smash

We wanted to host an event we had not seen before: a narrative-driven capture-the-flag (CTF) game that would immerse the players in it’s story. Since no platform existed that would facilitate the kind of direct, ongoing player interactions we wanted, we set out to build our own game engine.

We created a platform that enabled players to receive game information, objectives, hints, and scoring, from a semi-automated/interactive entity known as their “Handler”.But these were no ordinary players: with our booth at DEFCON 26 and a $10,000 grand prize on the line, we had 300+ of the best hackers on the planet motivated to beat our game however they could. This is the story of how we built the game engine that would bring the vision to life, and lessons learned from surviving the onslaught.

A Young Lady's Illustrated Primer to Technical Decision-Making

Over the last few years we’ve seen an explosion of complexity, in everything from polyglot storage to composable infrastructure, containerization and microservices, config management vs immutable infrastructure. Until recently there was a set of widely accepted best practices for running in the cloud. But now every element of your stack is a never-ending rabbit hole of possibilities and questions. What’s an engineer or architect or manager to do? And where does golang fit in??

Solid technical judgment is more important than ever. You can’t anticipate every problem, but you can identify and head off many of them in advance. We’ll talk about how to identify and prioritize where to be boring and where to innovate; how to choose a language based on use case; when to rewrite and when to double down; how to select a golden path of technology that will scale as your team does … and how to correct course when you’ve made a wrong call.

Error handling and Pitfalls in Distributed Go Applications

CockroachDB has seen a relatively large amount of bugs in 2018-2019 due to improper error handling, in turn stemming from Go’s “idioms” (community recommendations). Close inspection has revealed that previous Go best practices turn into outright bugs and code complexity when the code is distributed and error handling spans a network. The various problems have been identified in the CockroachDB RFC here. The talk will summarize the main findings and generalize them to other Go projects beyond CockroachDB, as well as present the general design directions behind the general-purpose ‘errors’ library aiming to become a drop-in replacement to Go’s standard errors package in distributed Go apps.

Error handling and Pitfalls in Distributed Go Applications

More than five years ago, sync.Pool was added to Go’s standard library to help gophers alleviate the pressure on the Garbage Collector by providing a convenient way to reduce allocations. Since then, many have adopted it and multiple talks and posts have been written about the topic.

In this talk, we go into a slightly deeper dive than usual with a mischievous mindset. The implementation of sync.Pool benefits from a tight coupling with the Go runtime. Let’s explore some unexpected ways in which we could benefit from sync.Pool special place in the Go ecosystem

Come for the Language. Stay for the People

Communities exist for all sorts of things. It may be a sports club, a religious group, a political group, or a social activity. A community can be around a shared interest, or shared desire to learn something new. A community can be location specific or spread around the globe. The Go community is a number of these; it is spread around the globe, with strong local representation. It is forged around a shared interest and a desire to learn. But what makes a community successful? Thinking about a traditional village community, the sort I grew up in, we will consider what makes those communities thrive and become desirable places to live and then apply those lessons to the Go community and see what we can learn. The aim here is to realise that we can all be Go community contributors and we all have a responsibility for the community and its success.

schedgroup: a Timer-Based Goroutine Concurrency Primitive

Go provides first-class support for concurrency primitives such as goroutines, channels, and select statements. In addition, the Go runtime provides excellent support for high-resolution timers. By combining these primitives, we can create powerful new ones that take advantage of Go’s concurrency and runtime timer facilities.

This talk will introduce a timer-based concurrency primitive called a “schedgroup”: short for “scheduler group”. The schedgroup.Group API mimics the familiar and simple sync.WaitGroup from Go’s standard library. The key feature of the schedgroup.Group type is its ability to efficiently delay or schedule the execution of goroutines according to user-specified time values.

While prototyping the schedgroup package, several different designs were explored, each with differing advantages and disadvantages:

• a minimal implementation which creates a timer per goroutine for scheduling tasks
• a timer-polling approach which checks for scheduled tasks in a queue at a fixed interval
• an event-driven scheduler approach which uses a priority queue and signaling with channels

This talk will demonstrate the strengths and weaknesses of each prototype, building on top of each previous iteration until we reach the final design and implementation of the package as it stands today. During the presentation, attendees will learn about concepts related to Go concurrency and runtime timers, including:

• blocking and non-blocking channel send/receive operations within a select statement
• patterns for implementing context cancelation in concurrent systems
• troubleshooting and prevention of goroutine deadlocks
• efficient use of Go’s time.Timer APIs for tracking elapsed time during operations
• implementing a time-based priority queue with Go’s container/heap package

schedgroup: a Timer-Based Goroutine Concurrency Primitive

Go provides first-class support for concurrency primitives such as goroutines, channels, and select statements. In addition, the Go runtime provides excellent support for high-resolution timers. By combining these primitives, we can create powerful new ones that take advantage of Go’s concurrency and runtime timer facilities.

This talk will introduce a timer-based concurrency primitive called a “schedgroup”: short for “scheduler group”. The schedgroup.Group API mimics the familiar and simple sync.WaitGroup from Go’s standard library. The key feature of the schedgroup.Group type is its ability to efficiently delay or schedule the execution of goroutines according to user-specified time values.

While prototyping the schedgroup package, several different designs were explored, each with differing advantages and disadvantages:

• a minimal implementation which creates a timer per goroutine for scheduling tasks
• a timer-polling approach which checks for scheduled tasks in a queue at a fixed interval
• an event-driven scheduler approach which uses a priority queue and signaling with channels

This talk will demonstrate the strengths and weaknesses of each prototype, building on top of each previous iteration until we reach the final design and implementation of the package as it stands today. During the presentation, attendees will learn about concepts related to Go concurrency and runtime timers, including:

• blocking and non-blocking channel send/receive operations within a select statement
• patterns for implementing context cancelation in concurrent systems
• troubleshooting and prevention of goroutine deadlocks
• efficient use of Go’s time.Timer APIs for tracking elapsed time during operations
• implementing a time-based priority queue with Go’s container/heap package

Going Driverless at Einride: How We Developed a CAN Library for Go

On May 15th 2019, Einride’s Pod become the first cab-less electric truck to drive on a public road. A surprising amount of software running in this vehicle is written in Go.

I will give the audience a look into the software development of a driverless vehicle, and how Go can be applied to great success. The talk centers around a key problem we had to overcome at Einride to use Go for vehicle software development, namely CAN communication. I'll showcase the Open Source library we developed (https://pkg.go.dev/go.einride.tech/can) and share some learnings on leveraging the standard library, the runtime poller, and a code generator inspired by protocol buffers and gRPC.

The audience will walk away knowing more about driverless vehicles, the CAN protocol, the CAN-Go library, and an experience report from applying Go to a new domain.

How to Structure Your Microservices

Most of us have been happily writing monoliths for years, then not so happily struggled to refactor those as they grew. Then we heard the magic word: microservices.

But what exactly are they? How small should a microservice be? And are they really that good?

There are definitely pros and cons to this approach, and unfortunately many people seem to have had a pretty bad experience overall. Microservices are not easy to get right. But it is possible, and I want to show you how.

When I was considering my next career move back in 2018, I wanted to work for a company which does microservices well. Building a fully-licensed bank with over 3 million customers, written entirely in Go, using over 1500 microservices with 99.999% uptime seemed like a decent enough challenge. If you can make that work, and get the regulators and customers to trust you with their money, you must be doing something right. I wanted to know the secret sauce.

So this talk is about the lessons I’ve learnt so far on how to design microservices well and make them work for the team, at scale. I’ll talk about the key rules to follow and how to break down problems into the right set of individual services. We’ll walk through designing and implementing a simple API endpoint using microservices to demonstrate how to build small, consistent, understandable and extensible services which together form a powerful and resilient system.

The point is not to say that microservices are better or worse than monoliths. The point is to show a set of best practices for building successful microservice architectures, based on my experience. We’ll talk about:

• the benefits of having homogenous services, with example structures
• deciding when something should be in its own microservice
• orchestrating and testing microservices
• designing with typical networking and reliability issues in mind
• safely introducing changes affecting multiple services with no downtime
• code ownership and allowing large teams to make changes safely and independently
• designing extensible, not flexible systems which grow and scale well over time

Writing open source tooling using AST

At Brankas, we needed the ability to define types and GRPC service definitions in a way that made it easier for internal Go developers, this tool became Gunk. Without the AST package, Gunk would have been nearly impossible to build. In this talk, I will be exploring the AST package and how Gunk uses it under the hood to be the amazing tool it is.

Field Report: Building a game engine for 300 defcon hackers to smash

We wanted to host an event we had not seen before: a narrative-driven capture-the-flag (CTF) game that would immerse the players in it’s story. Since no platform existed that would facilitate the kind of direct, ongoing player interactions we wanted, we set out to build our own game engine.

We created a platform that enabled players to receive game information, objectives, hints, and scoring, from a semi-automated/interactive entity known as their “Handler”.But these were no ordinary players: with our booth at DEFCON 26 and a $10,000 grand prize on the line, we had 300+ of the best hackers on the planet motivated to beat our game however they could. This is the story of how we built the game engine that would bring the vision to life, and lessons learned from surviving the onslaught.