1. A new way to run prod services locally

Abstract

Description

I got sick and tired of having this problem, so I built a new go app, of course! Called microplane, it allows automatically starting and stopping services on your development machine, allowing you to access them via a single configurable TLD, and automatically handles routing requests so all of your services can be accessed on ports 80 and 443.

Additionally, microplane sets up standard observability and process management stacks, so your local development environment can be as productive as production as possible.

Go made it so easy to build a lightweight control plane for localhost.

Notes

^ back to index

2. Building a bank in Go using Encore and Temporal

Abstract

Description

Notes

^ back to index

3. Graphical Errors

Abstract

Description

Stack traces are useful to the developer, but not useful to the user of a program. What is more important to the users is arguably the steps that led to the error. These steps are often linear, however in deep learning applications they are not necessarily so.

Using Gorgonia as a background for motivation, this talk will explore the notion that errors are formed/bubbled through actions that form a graph. What are the best ways to handle errors that is both useful to the end user and the developer?

Notes

The rough outline of this talk is as follows:

1. Errors are values.
2. Linear errors, stack traces and compositionality.
3. Background to the problem (deep learning applications have errors accumulate/bubble in a graph).
4. Introduction to the notion of “graphical” errors.
5. Compositionality of “graphical” errors.
6. How to be useful to both the end user (i.e. the users of the library) and the developer (of a library)

^ back to index

4. Go Is A Good First Language to Teach Programming.

Abstract

In recent months, I’ve had the pleasure of accidentally running a natural experiment in teaching programming to two people who have no tech background at all.

In this talk I shall summarize my teaching methods and outline why Go is actually the best first language to teach programming.

Description

• On Programming vs Coding
• How Humans Learn
• The Accidental Experiment
  • The Set Up: A Natural Experiment
  • The Two Participants
  • The Two Methods of Teaching
• Why Go Makes A Good First Language
  • Syntactic uniformity.
  • Types and Data
  • Ritual is good for learning, bad for understanding.
• On Forgetting Our Pain
• Some Lessons Learned

Notes

I’ve been teaching two women who have no prior tech background how to program for 1.5 months (as part of a 3 month program). By sheer chance this allowed me to do some natural experiments - to teach one traditionally, and to teach the other with the help of ChatGPT.

At the point of writing this, the participant who is learning via ChatGPT is sorely lacking in a lot of understanding while the participant receiving traditional teaching is blazing ahead, having written her first A* pathfinding algorithm by the third week.

Here’s the full table of contents:

• On Programming vs Coding Here I talk about the differences between programming and coding
• How Humans Learn ~3 slides on how the human brain works when it comes to learning
• The Accidental Experiment
  • The Set Up: A Natural Experiment
    • Two-fold purpose of learning: learning-to-an-understanding vs learning-to-be-productive
    • Teaching each participant multiple programming languages: Go, APL, Haskell, Python, JavaScript, Clojure
  • The Two Participants
    • The Stay-At-Home Mum
    • The Project Manager
  • The Two Methods of Teaching
    • Montessori with human teacher (Montessori here refers to “student-led”, not daycare)
    • Montessori with AI teacher
• Why Go Makes A Good First Language
  • Syntactic uniformity. (Go is remarkably syntactically uniform, only less uniform than Lisp or APL)
  • Types and Data (How to teach types and type systems)
  • Ritual is good for learning, bad for understanding. (This concerns the role of practice, as in physically typing out the code in learning)
• On Forgetting Our Pain
• Some Lessons Learned

^ back to index

5. Man Bites Dog: A Journey of LLMs and What Comes Next (and Why Go is Poised To Be At The Centre of The Next Tech Revolution)

Abstract

LLMs like GPT-4 have gained popularity recently, raising questions about their capabilities and general intelligence - mostly written in Python, seemingly leaving Gophers out in the cold.

However, that couldn’t be more false. In this talk I’ll explore where Go can go in an LLM-filled future.

Description

• On Language
  • Grammars and Vocabularies
  • Sublanguages
  • Facets of language: syntax, semantics, pragmatics
• What do LLMs Learn?
• Why do LLMs perform so well?
  • A primer on language learning (Gold’s theorem, etc)
    • LLMs memorize the world.
    • Why memorization is good, and when do we need it.
    • Why memorization is bad, and when do we need a model to not memorize.
• So… we code more Python right?
  • Some Go example of LMs
• What Next?
  • What is the next tech revolution, and why?
  • Where Go excels, where Go fails
• What Go needs to survive in the brave new world

Notes

I’ve been writing LLMs before they were even called LLMs. In one of my earlier presentations in GopherConSG, I’ve even showed an example of a conversational agent that understands mathematics better than GPT-4. I think I am qualified to talk about LLMs.

The next tech revolution will be in programming languages and databases (not necessarily vector databases), and I think Go is more than well-poised to be at the centrestage once more. This is the main reason why I start my talk explaining the power of languages.

^ back to index

6. Switching Disciplines as a Tech Lead

Abstract

Description

Technical leaders come in many different flavors, but most have been honing their craft for a long time. They rely on years of hard-won expertise to guide and uplevel their teams, shaping a teams technical choices in addition to team culture.  

I was in that boat up until a year ago, having spent nearly a decade doing build engineering on iOS applications. Then, I threw myself into the unknown by switching to service development on a product team in an entirely different part of the company, with the expectation that I would immediately step in as the new team’s tech lead.  

So far, that change of disciplines has been successful, but it’s also been an incredibly challenging year. Learning the technical details of how to build services while simultaneously mentoring and guiding the more junior members of the team (who actually have more domain experience than I do) has required a lot of effort, testing all of the tech lead muscles I had built up in my old role.  

Along the way, I have learned that being a lead developer is less about knowing the arcane (“this method is O(n^2)” or “this is the order you need the columns to be in the MySQL index” or “I know the docs say X, but it doesn’t work. Trust me, I’ve tried.") and more about being willing to reason about complex systems and approach problems with an open mind. My job isn’t to write perfect code or prevent other engineers from introducing bugs–I’m there to ask questions and assume that with enough effort and determination, we can solve whatever problems are at hand.

Notes

^ back to index

7. CockroachDB : a groundbreaking project built on Go that revolutionizes distributed databases

Abstract

Description

Ladies and gentlemen, distinguished attendees, and fellow enthusiasts of the Go language,

It is an honor to stand before you at GopherCon Singapore, a gathering that showcases the innovation and versatility of Go—a language that transcends boundaries and empowers us to create exceptional solutions. Today, I am thrilled to delve into a topic that encapsulates the very essence of Go’s impact: “Unveiling the Power of Go: A Journey Through Distributed Systems and the Impact of the CockroachDB Project.”

The Ubiquity of Go: A Language of Evolution

In an era of multifaceted technological landscapes, Go has emerged as a unifying force—a language that seamlessly traverses domains, from microservices to embedded systems. Its inherent concurrency model, performance efficiency, and strong standard library have made it a staple for developers aiming to build robust and scalable software.

1. CockroachDB: Revolutionizing Distributed Databases

As we embrace the world of distributed systems, one project stands out for its groundbreaking impact—CockroachDB. This distributed SQL database built on Go has transformed the way we think about database scalability, resilience, and global data consistency. Inspired by Google’s Spanner, CockroachDB brings the promise of a distributed, transactional database to organizations of all sizes.

2. The Use Case: Achieving Global Consistency

Consider a scenario where a global e-commerce platform processes orders from customers spanning various regions. Ensuring consistent data across multiple geographies is a formidable challenge. CockroachDB rises to this challenge by providing strongly consistent transactions, even in the face of network partitions. With its ability to scale horizontally and maintain data integrity, CockroachDB enables businesses to expand seamlessly into new markets.

3. Importance to the Community: Scalability and Beyond

CockroachDB embodies the ethos of the Go community—simplicity, performance, and reliability. Its architecture is a testament to Go’s ability to build robust systems that cater to real-world needs. The project showcases the importance of a distributed database that can scale effortlessly as traffic surges, all while ensuring data integrity and compliance with SQL standards.

4. Architecting Resilience: Go’s Concurrency Model

One of Go’s defining features is its concurrency model, embodied by goroutines and channels. CockroachDB harnesses this model to manage data distribution, replication, and failover gracefully. This approach enhances both performance and fault tolerance, ensuring that distributed transactions remain consistent in the face of failures.

5. Future Visions: Shaping the Distributed Landscape

CockroachDB’s journey has only just begun. As it continues to evolve, it will influence how we design, deploy, and manage distributed systems. Its ability to handle complex transactions across vast geographical distances opens new avenues for global applications, underscoring its role as a trailblazer in the world of databases.

In conclusion, dear colleagues, GopherCon Singapore is a celebration of innovation, and the story of CockroachDB exemplifies the transformative power of the Go language. As we navigate the distributed landscape, let’s remember that Go’s strengths in concurrency, simplicity, and performance are not just attributes; they’re the bedrock of remarkable projects that shape industries and drive progress.

Thank you for joining me on this journey of exploration and discovery. Together, let’s embrace the power of Go and its boundless potential to redefine the world of software engineering.

Notes

Technical Requirements: For an effective presentation, I’ll require a projector and screen setup to showcase slides and live coding examples. A reliable internet connection is essential for accessing online resources and demonstrating real-time interactions. Additionally, a microphone and sound system will ensure that every attendee can hear and engage with the content.

Expertise and Relevance: With several years of hands-on experience in Go development across diverse domains, I am well-versed in the intricacies of the language and its applications. My track record includes successful project implementations, contributions to open-source Go projects, and deep insights into best practices and optimization techniques. Having faced challenges firsthand, I bring a practical understanding of the nuances and solutions needed in real-world scenarios.

Community Engagement: I am an active member of the Go community, having delivered talks and workshops at various conferences and meetups. My engagement with the community has enriched my knowledge and understanding of common pain points and emerging trends. This enables me to tailor my content to address the audience’s needs directly.

Value Proposition: My presentation will not only provide attendees with an in-depth understanding of Go’s power but also equip them with actionable insights and best practices that can be immediately applied in their projects. With a blend of technical expertise, real-world experiences, and a passion for sharing knowledge, I am confident in delivering a presentation that resonates with the audience and leaves a lasting impact.

In conclusion, my presentation is designed to engage, educate, and empower the audience, aligning seamlessly with the themes and goals of GopherCon Singapore. I am excited about the opportunity to contribute to the event’s success and share valuable insights with fellow Go enthusiasts.

^ back to index

8. WASI Support in TinyGo vs Golang v1.21

Abstract

Description

Notes

As an experienced developer who has worked extensively with Go and WebAssembly (Wasm), I am well-versed in the subject matter. My background includes practical hands-on experience with Go’s WebAssembly support and a previous talk on [redacted].

My knowledge of Go and WebAssembly and my communication skills make me the ideal person to speak on this subject. I can effectively convey the concepts, demonstrate practical examples, and provide insights into leveraging Go’s WebAssembly System Interface (WASI).

^ back to index

9. Generics in Go - A language design perspective

Abstract

Description

1. Why Generics?

We’ll start the talk by understanding why Generics exists in programming languages. We’ll discuss its role in writing reusable, type-safe code and explain this with practical examples.

2. Go Before Generics

We’ll explain with code examples how developers used Reflection before Generics and how it lacked the compile time safety that Generics provides.

3. Language Mechanisms Supporting Generics

The heart of our talk will be a deep dive into the language mechanisms that support generics in Go. We’ll explain the following concepts with examples:

• Type parameter list: We’ll discuss how these are similar to the ordinary parameter list but for types.
• Interface Type: We’ll see how and why interfaces were extended in Go to enable generics.
• Type Inference: We’ll touch upon the different types of inferences that occur in Go and how they contribute to the flexibility and power of generics.
• Type Sets: We’ll discuss the concept of type sets, a new meta-type addition in Go.

4. Best Practices and Gotchas

Finally, we’ll end our discussion by exploring the best practices and gotchas with generics. We’ll learn how to effectively use generics to write efficient, type-safe code and what pitfalls to avoid.

Notes

This talk is suitable for people with an intermediate level of knowledge in Go. This talk is technical, but we’ll include code examples to simplify the concepts.

[redacted]

^ back to index

10. Feeling the Text: Exploring Emotions with Go, VADER, and ChatGPT

Abstract

Description

This talk is all about understanding sentiments using Go and VADER, and then taking it to the next level by seeing how ChatGPT adds its own twist. We’ll make it fun by focusing on real-life stuff like social media posts and app reviews.

Agenda:

1. Getting Emotional: Let’s Start Feeling:

   • Explaining what sentiment analysis is and why it’s exciting.
   • Quick intro to Sentiment Analysis in Go

2. Feeling It with VADER: Understanding Emotions:

   • Learning about VADER, a tool that helps us understand feelings in text.
   • Understanding how VADER figures out if text is positive, negative, or something in between.

3. Emotions on Social Media: What’s Everyone Saying?:

   • Seeing how Go and VADER can help us understand what people are feeling in tweets and posts.
   • Finding out how these tools make sense of all those hashtags and emojis.

4. App Reviews Speak Louder: Emotions Behind Reviews:

   • Diving into app reviews and learning how to detect emotions in them.
   • Using Go and VADER to figure out if people are happy or frustrated with apps.

5. Battle of the Bots: Go, VADER, and ChatGPT:

   • Revealing what Go and VADER think about sentiments in text.
   • Throwing ChatGPT into the mix and seeing what it adds to the emotional conversation.

6. From Emotions to Insights: Making Sense of It All:

   • Turning emotions into useful information about what people are saying.
   • Sharing cool things we can learn from analyzing feelings in text.

7. What’s Next for Emotions and Text?: Looking Ahead:

   • Thinking about where emotions and text analysis are headed.
   • Imagining how Go, VADER, and ChatGPT will shape the future of understanding emotions.

Notes

I have worked as a mobile developer for more than a decade, am a trained writer and published my anthology and presented at the Singapore Writers Festival. I have transitioned to golang a couple of years ago.

Why I’m the Best Person for This:

Creative Writing Expertise:

As a creative writer, I’ve honed the skill of delving into the nuances of emotions and crafting narratives that resonate with readers. This talk isn’t just about technology; it’s about the stories emotions tell. My writing background uniquely equips me to communicate the impact of sentiment analysis beyond code—how it breathes life into words.

Mobile Development Experience:

Having ventured into the realm of mobile development, I’m acutely aware of the pivotal role sentiment analysis plays in user feedback and engagement. The insights we’ll uncover have a direct impact on app development. My background in mobile apps ensures I can relate to developers grappling with real-world challenges.

Transition to Golang:

With my transition to Golang, I bring a fresh perspective on integrating sentiment analysis into the programming landscape. Golang is renowned for its simplicity and efficiency, making it an ideal candidate for natural language processing tasks. My journey from mobile development to Golang reflects the conference’s theme of evolution and growth.

Storytelling in Tech:

Technology isn’t just about lines of code; it’s about the stories we create with them. My ability to weave engaging narratives bridges the gap between technical concepts and relatable experiences. Attendees will not only understand how Go and VADER work but also feel the impact of their insights.

Practical Insights from Diverse Sources:

My background allows me to draw insights from diverse sources—be it social media’s fast-paced posts or the thorough feedback within app reviews. The ability to analyze and convey emotions from these sources in a relatable manner sets the stage for an informative yet enjoyable talk.

In summary, my journey as a creative writer, mobile developer, and Golang enthusiast positions me as the ideal person to dive into this topic. I’m not just bringing technical expertise; I’m infusing it with storytelling finesse, a deep understanding of user engagement, and a fresh perspective on Golang’s capabilities.

^ back to index

11. Go ahead and let your code say what you mean

Abstract

Write code is hard, reading code is harder. Peter Norvig noted once that “code is not read, it’s de coded”. Patterns, best practices, style guides, all hint at this problem.

In this talk I’m going to present some ideas to increase the readability of the code that I write.

Description

I will spend around 5 minutes on each of the following topics related to readability

• Basic readablity ground rules; replace if with return, constructing structs once using helper functions to avoid temporaries,
• UnmarshalJSON and custom types to prevent unstructured JSON from leaking complexity throughout your program.
• Addressing the “two arguments of the same type” API problem
• Generic algorithms to replace repetitive nested loops.

Notes

^ back to index

12. exposing gRPC services in kubernetes environment

Abstract

Description

What is gRPC and its importance in kubernetes

gRPC is an open source, high performance Remote Procedure Call(RPC) framework with HTTP/2 as the underlying protocol. gRPC is used widely for communication between microservices, because of its high performance and ability to support bidirectional communication. Exposing gRPC services is an important part of using gRPC framework in Kubernetes.

How could gRPC services exposed to internal and external clients

Currently (until this article written), we have three kind of resources that could expose a gRPC service to external clients:

• Ingress in networking.k8s.io/v1. This is a mature resource, with the widest support in kubernetes clusters. As gRPC requests specifies paths, methods and headers containing metadata, ingresses does not have a unified way to define match criteria of the methods and headers. So this method requires implementation specific annotations and is not portable.
• HTTPRoute in gateway.networking.k8s.io/v1beta1. HTTPRoute in gateway APIs is in beta maturity and would be GA soon. It has a stable and consistent interface of specifying hosts, paths, methods and headers of HTTP requests, so it provides a unified way to define match criteria in specification of gRPC requests.
• GRPCRoute in gateway.networking.k8s.io/v1alpha2. The API specification matches gRPC requests in a more precise model, and shielded the details of the methods and headers under the hood, which are all the same through all gRPC requests.

How did Kong Ingress support the methods using golang

Kong Ingress controller(a.k.a KIC) is an open source ingress controller writtenin golang, that supports all the three methods above to expose gRPC resources. KIC supports standard implementation of ingress, and also provides multiple annotations to satisfy the requirements of matching gRPC requests. KIC also supports the “next generation of ingress” – the gateway APIs in a leading position. Now KIC passes all core conformance tests until gateway API 0.7.0, which is among the leaders of being conformant to gateway APIs. For HTTPRoute, KIC supports all match criteria in its match rules, which could perfectly support requirements of matching gRPC requests, and passes all core conformance tests related. For GRPCRoute, KIC also supports all its matching rules and satisfies the requirements of routing traffics of gRPC requests to the correct service.

Notes

^ back to index

13. Data Integration: Building Systems for Swift Client Servicing in Go

Abstract

Description

About the Talk

The [redacted] project was started to address the challenge in unifying data from multiple Government agencies as a data aggregator and provide a consolidated view of citizens’ data through a web-based frontend application and backend APIs, with the goal enhancing the efficiency of providing social assistance-related guidance to citizens in need.

Refer to article: [redacted] for past press release.

Since the inception of the project, the demand for data from [redacted] has notably surged, particularly through the backend API channel. This surge has spotlighted several challenges and areas of improvement for [redacted] as a data aggregator:

1. Differences between API specifications and actual responses received from agencies
2. Ability to fulfil surge in demand for [redacted] data

To support [redacted]’s role as a data aggregator, the development team was required to write backend logic to integrate with each agency’s API and such activities can be laborious. There can also be inaccuracies in API specifications that are caught much later in the development phase of API integration. On top of these challenges, the increase in demand for [redacted] data also required the team to be able to respond quickly to such requests.

Thus, this talk is going to focus on the areas of improvement, system design, and also the Go-based libraries and tools within the ecosystem that can propel us forward in fulfilling these enhancements.

Outline of Presentation

The presentation will be divided into the following segments:

1. Introduction to [redacted]
2. Problem: Surge in demand for data from [redacted]
3. Solution: API documentation and validation
4. Solution: Customised API for clients

The introduction segment will cover the key points mentioned in the ‘‘About the Talk’’ section, including the gaps in retrieving and viewing citizens’ data in a single view that led to the start of the [redacted] project. This segment will also give a high-level overview of [redacted]‘s infrastructure, including how it is powered by a cluster of Go-based microservices.

The convenience of [redacted] being able to allow public officers to view citizens’ data in a single view also led to a surge in demand for data from [redacted], and the side effects of this surge will be covered in the “Problem: Surge in demand for data from [redacted]” segment, which will focus on the following problem areas:

1. Differences between API specifications and actual responses received from agencies
2. Ability to fulfil surge in demand for [redacted] data

The problem areas will be discussed in the “Solution: API documentation and validation” and “Solution: Customised API for clients” segments.

The “Solution: API documentation and validation” segment will cover the usage of OpenAPI and Go libraries such as kin-openapi, oapi-codegen to document agencies APIs and how to validate them. The aim is to not only validate agencies APIs through OpenAPI, but to also develop a central data dictionary that can be referenced by the [redacted] team and clients who want data from [redacted]. A quick demo of how kin-openapi and oapi-codegen work could be included in this section to help the audience better understand the solution.

The “Solution: Customised API for clients” section will then build upon the OpenAPI solutions and central data dictionary mentioned in the previous segment, and touch on clients who not only need [redacted] data, but also data that is tailored to their needs. This segment will introduce Benthos to the audience and touch on how Benthos can be used to customise APIs to suit client needs, yet ensuring changes made will not impact other existing features or APIs used by other clients. A quick demo of how Benthos works could be included in this segment to help the audience better understand the solution.

Conclusion

A recap of the Go libraries and tools used in solutions to address the problem areas will be done during the conclusion segment. An illustrated high-level view of the combined flow of how the solutions mentioned in the previous segments work together will be presented in this segment as well. Caveats and things that developers should take note of when using the above-mentioned Go libraries and tools will be mentioned in this segment as well.

Notes

^ back to index

14. Golang Concurrency - Locks, Lock-free, and Everything in Between

Abstract

Description

Outline

• Introduction
  • Challenges of traditional lock-based programming.
  • Need and benefits of lockless programming in terms of performance and scalability.
• Strategies/techniques for addressing challenges of traditional lock-based programming ( explain each strategy with golang code )
  • Reader-writer lock.
  • Lock hierarchy.
  • Lock sharding.
  • Async processing.
• Designing Lock-less data structures
  • Transactional memory - Atomic operations.
    • Is this truly lock-less ? How does it work ?
    • Memory sync primitives in golang
• Case study and examples
• Testing and Debugging
  • Testing methods for lockless code, which includes detecting race conditions etc
• Performance considerations
  • How to benchmark concurrency testing code
  • Benchmark numbers of all techniques above
  • Trade-offs in terms of complexity, performance, and resource overhead
• Best practices and pitfalls
• QnA

Notes

^ back to index

15. Three techniques for building high performance parsers

Abstract

Description

This talk presents three techniques to build a high performance JSON parser

• Efficient buffering to reduce copying
• Reducing allocations through API design
• Inlining and “outlining” to reduce function call overheads

[redacted]

Notes

^ back to index

16. Build AI applications with LangChain and Atlas vector search on GitHub codespaces.

Abstract

Description

I want to explain how to build an AI application for Go developers. Go developers can use LangChain to connect AI services and store all the embedded data in MongoDB Atlas. Go developer can build the search application using natural language processing (NLP) and Atlas vector search to find all similar documents on MongoDB Atlas.

My Outline

• What is LangChain?
• What are MongoDB Atlas and Atlas vector search?
• What are GitHub codespaces and Dev containers? *Let’s get the demo.

Key takeaways

• How to develop AI applications and test them on GitHub codespaces?
• How to create a Dev containers template for Go.
• How to use Atlas vector search features on MongoDB Atlas.

Notes

^ back to index

17. Connecting the Dots: How Automated Tests Can Sensitively Improve Your Security

Abstract

Description

Running an application through a comprehensive pipeline provides developers with a unique opportunity to explore the various branches of its execution flow. By leveraging the power of a syscall profiler, which monitors syscalls during test execution, a seccomp profile can be generated based on the syscalls employed during this pipeline run.

The crux of this approach lies in the symbiotic relationship between test coverage and the resulting accuracy of the generated seccomp profile. As test coverage expands, the seccomp profile becomes increasingly precise, allowing for more effective security measures. Consequently, writing comprehensive tests not only ensures robustness in the application’s functionality but also significantly reduces its attack surface, thus elevating the overall security posture.

Notes

^ back to index

18. Incident Prevention 101: Empowering Software Engineers to Mitigate Risks

Abstract

Description

Incident prevention is an essential part of software engineering. No matter how well-written your code is, there will always be errors. The key is to handle them in a way that minimizes their impact.

In this talk, I will start by discussing the significance of errors on user experience and software reliability. Next, the risks that can be introduced into software systems with three main reasons: changes in the system, external factors, and unpredicted events. Let review specific reason to identify the risk in your development process. Finally, the most important part is practical strategies that can be implemented to prevent incidents. Deep dive into these strategies will cover four main factors of modern software development: development, architecture, deployment, and observability.

By the end of this talk, you’ll better understand how to prevent errors from causing incidents in your production applications. So take advantage of this opportunity to learn how to improve the reliability of your software.

Notes

I am an experienced backend engineer with expertise in Golang and Ruby. I have successfully delivered various massive projects, including [redacted] and [redacted], which now handle millions of requests per day globally with world-class standards. Having witnessed the impact of errors on system reliability and user experience firsthand, I have honed my skills in handling incidents ranging from low-severity glitches to critical issues. This invaluable experience has given me expertise and practical strategies that have been proven successful in real-world scenarios.

In my experience, error handling is one of the most critical aspects of software development. Errors can cause various problems, including system crashes, data loss, user frustration, and in the end it cause incident in production system. Therefore, mitigating risks and preventing incidents are crucial in modern software system nowaday. In my talk, I will share my own experiences and knowledge with incident prevention that I gained from reality of many caused incidents. “Incident Prevention 101: Empowering Software Engineers to Mitigate Risks” would be covered topics such as:

The significance and risk of error in software system

• Highlight the impact of errors on user experience and overall satisfaction of software
• Explain how errors can compromise the reliability of the software system
• The importance of planning for the risk of outage

Identify the risk from software development

• Three main reasons why risks can be introduced into software system during development process:
  • Changes in the System
  • External factors
  • Unpredicted events
• Provide examples of specific risks due to each these three reasons
• Share my horrible story of handling incident overnight (optional)

Build strategies for incident prevention

• Explaining 4 main factors can be used to build strategies for incident prevention:
  • Development
  • Architecture: discuss specific about Golang
  • Deployment
  • Observability
• Discuss specific strategies can be implemented for each factors
• Discuss how software engineers can implement these strategies

[redacted], I had a pleasure of contributing to Gopher community in [redacted]. The success of event is not only motivated me to become a speaker but also ignited a strong desire within me to contribute to the software engineering community. Recently, I achieved a significant milestone of becoming speaker at [redacted], a prestigious conference renowned within the Ruby community.

I am enthusiastic about the possibility of adding value to this year’s GopherCon SG through my talk on incident prevention. This topic holds immense potential to empower attendees with invaluable guidance, enabling them to fortify their software’s reliability. I believe that my proposed talk aligns seamlessly with the needs of the Gopher community, offering practical strategies tailored to their software reliability challenges.

Thank you for considering my talk proposal. I look forward to sharing my expertise and insights with fellow developers at the conference.

^ back to index

19. Building APIs the Design-First Way with Go

Abstract

Discover how Go empowered us to build an API-driven file transfer solution:

a) API design-first approach with Go modules for seamless design and implementation. b) Build with efficiency and scalability in mind and how Go natively supports it. c) Explore the collaborative role of Gin web framework.

Description

We searched for a language that could support API design-first approach, offer efficiency and scalability in implementing API servers and enable a swift learning curve.

Enter Go and the Gin web framework, which perfectly met our needs:

• Automated code generation from OpenAPI specs
• Request/Response validation capabilities
• Seamless middleware integration
• JWT token handling and Cloud-native services integration
• Concurrency support
• Robust unit testing support
• Support for Continuous Integration and Deployment

Notes

[redacted]

We have developed this file transfer solution as API-driven and Cloud-native.

I have been involved in,

• Design and development from POC to the Product,
• Most of the engineering decisions.
• And Implemented the APIs using Go and Gin web framework along with the team.

^ back to index

20. Go Concurrency Techniques for Self-Healing Applications

Abstract

Description

Monitoring health of distributed systems is never easy. There is often a lot moving parts, and plenty of opportunities for failure - just because two systems are connected doesn’t mean they are behaving as they should.

At [redacted], we run applications at a massive scale. We take steps to ensure we are resilient against failure at all levels of our infrastructure. This includes Kafka, which we use for critical workflows such as sending time-sensitive emails and alerts. We learned a lot about keeping our applications that leverage Kafka healthy, so they can always be operational. Application health checks are notoriously hard to implement: What determines an application as healthy? How can we keep services operational at all times?

To achieve this, we implemented our own Intelligent Smart Health checks. This has allowed our services to be much more self-healing, meaning there is much less manual intervention required. Before we used to get paged when applications got stuck, which also led to different incidents that had a customer impact.

After coming up with an approach for our smart health checks, actually implementing it was a challenge in itself. Each application container has multiple processes running concurrently, and state needs to be shared across them. This is where concurrency in Go really shines.

I will talk through some common Go concurrency techniques we used when implementing our smart health checks, along with best practises, common patterns and trade offs between approaches. Some examples include:

• Channels - To safely share state between go routines in high throughput environments
• ErrGroup/WaitGroup - To wait between a set of concurrent operations & handle potential error scenarios gracefully
• Sync package - Mutexes & sync.Map - To allow access to share resources
• Context - Ensure all processes are gracefully closed & shutdown

This has had a significant impact on the uptime of some of our systems, as well as the quality of life improvements for our on-call engineers.

Notes

I have been building and maintaining distributed systems in Go for many years. Over time, I have faced a lot alerts and incidents during my whilst on-call and have been burnt in the past by the lack of application health monitoring. By implementing the techniques described in this talk, PagerDuty alerts in our team have reduced by roughly ~50%. This talk is a great way to highlight the value of Go’s concurrency model, as well as showing how it enabled us to quickly improve the work/life balance of our engineers.

[redacted]

[redacted]

^ back to index

21. Revitalizing Data Pipelines with Go with Profiling

Abstract

Description

Hello fellow Gophers! Have you ever grappled with data pipelines that don’t quite align with your preferred Beam Runner? It’s a common struggle. However, let me assure you that Go is ready to assist with its dynamic trio: reflection, interfaces, and the emerging star, generics.

In our discussion, we’ll explore how these features in Go can revitalize your data pipelines, ensuring they seamlessly integrate with any Beam Runner you deploy. We’ll delve into the adaptability provided by reflection, the versatility of interfaces for diverse data scenarios, and the efficiency brought by generics.

Yet, no journey is without its obstacles. Performance bottlenecks can arise when least expected. Worry not! We’ll share insights on utilizing profiling to identify and overcome these challenges effectively.

Join us for a captivating session. We’ll exchange experiences, insights, and perhaps some light-hearted moments, as we delve into enhancing the efficacy of our Go pipelines. If you’ve navigated through bottlenecks in the past and have insights to share, we’re keen to hear. Let’s engage in a productive dialogue and drive our code to new heights. Looking forward to our interaction!

Notes

^ back to index

22. Keeping myself alive with Go

Abstract

As a type 1 diabetic, keeping myself alive is a daily P1 incident with runbooks that are constantly out of date.

Like all systems, having good monitoring is essential to ensure uptime (or as I call it, staying alive). In this talk I will discuss how I have evolved my o11y using Go & other tools.

Description

In 2020, I was diagnosed with Type 1 diabetes. Truthfully, until diagnosis I had no idea what it was. Type 1 diabetes is a condition in which your body does not produce insulin. Insulin is used to balance the amount of glucose in your blood. If you have too much glucose in your blood, you can go into a coma and, in extreme cases, die. If you have too much insulin in your system, you can seizure and, in extreme cases, die.

Type 1 diabetees is an auto-immune condition and there is no cure. It is not the death sentence it once was, but it does means staying alive is a daily challenge. For example, every time I eat something, I have to evaluate how many carbohydrates are in it, and inject artificial insulin in a ratio that can vary depending on tons of factors. Sometimes this ratio is 1:10, sometimes as much as 1:20. How do I know which ratio to use? Truthfully I don’t. There is always an element of “inject, hope for the best, monitor and correct later”.

The way diabetics monitor themselves varies, and I am fortunate enough to wear a Flash Glucose Monitor on my arm. The monitor on my arm monitors my blood glucose minutes and the data on a graph on my iPhone. I can set alerts for if it goes too high, and too low and then I can set corrective action. Perfect!

There is a problem though. What if I go too low whilst I sleep? What if I don’t hear the alert? What if there is a sudden and huge change? What if I am just not capable of taking corrective action? This is a problem I faced, and I turned to Go to help me solve.

In this talk I will:

• Talk about how I “hacked” the device on my arm to send the data to a system I wrote in Go so I could extend the functionality.

• Why Go was a great choice of programming language for this particular task (low latency, productive, great library support, easy to deploy).

• How I ingest and process this data (including the challenges around data quality or missing data).

• How I then publish it to Prometheus, view it in Grafana and set up a Pagerduty escalation schedule to ensure that if I am asleep (or worse) someone near and dear to me gets alerted and can help me take corrective action.

I will wrap up by sharing some key takeaways which include:

• Reiterating why GO is a great programming language for this use case.

• Discussing some of the challenges that came with this specific application (for example, managing data “misses”, particularly anomalous results and the need to build in resilience as I do not want the PD call to fail).

• Explaining how I think my condition has made me better at my job, and how my job has made me a better diabetic.

• Share that although life gives us challenges, being able to code really is a super power that can help us overcome them.

Notes

I have spent many years working on distributed systems using Go and as a fairly new type 1 diabetic, I feel this talk is a great summation of all the things it is to be me.

I also really hope this talk will give me an opportunity to raise some awareness of what type 1 diabetes is whilst being entertaining, informative and fun. Health tech is a growing market and more and more people are choosing to wear Continuous Glucose Monitors to try and improve their energy levels. I therefore think this talk will be very interesting and relevant to a large proportion of the audience.

This talk will be accessible for Go engineers of all levels, including beginners. I will do my best to balance narrative with code and perhaps even a live demonstration to ensure it’s particularly compelling.

^ back to index

23. Beyond Unit Tests: Elevate Your Go Code Quality with Property-Based Testing

Abstract

Description

Introduction

Embark on an exploration that transcends the conventional boundaries of Go unit testing. This talk delves into the paradigm of property-based testing, a sophisticated technique poised to redefine code quality assessment. As we navigate this territory, we will illuminate the significant impact that property-based testing can have on enhancing the reliability and robustness of Go applications.

Outline of the talk

Rethinking Assumptions

Incorporate property-based testing to challenge assumptions that underlie your code. Unlike unit tests that target specific scenarios, this technique generates diverse inputs to test a broader range of conditions. Property-based testing empowers developers to write more resilient and adaptable software by exposing code vulnerabilities rooted in these assumptions.

Defining Properties of your code

Shift your perspective from input-output validation to specifying properties your code must uphold. These properties encapsulate high-level behavioral expectations, guiding the generative testing process. This shift fosters a deeper understanding of code requirements and encourages more comprehensive testing, ultimately enhancing reliability.

Uncovering Edge Cases

Property-based testing systematically explores the vast landscape of potential inputs, revealing edge cases that traditional tests often miss. By encompassing a broader spectrum of scenarios, developers gain insights into how their code behaves under various conditions, resulting in more comprehensive bug detection.

Generative Testing

Embrace generative testing, a core aspect of property-based testing. Developers can efficiently validate code behavior across various scenarios by automatically generating inputs based on defined properties. This approach detects issues more effectively and supports more comprehensive regression testing.

Conclusion

As this talk draws closer, attendees will recognize the transformative potential of property-based testing in fortifying Go code quality. By embracing this approach, developers gain a toolkit to expose vulnerabilities, challenge assumptions, and elevate their code to new heights of reliability and performance.

Notes

Technical Requirement (What we assume the audiences are aware of)

Unit Testing

While not a prerequisite, attendees acquainted with unit testing principles will find it easier to grasp the presented concepts. We’ll build upon this foundation to explore the revolutionary territory of property-based testing, enhancing attendees’ understanding of its benefits.

Importance of Code Quality

The talk’s core theme revolves around improving code quality through property-based testing. Attendees who recognize the pivotal role of code quality in software development will appreciate the practical insights shared during the presentation.

“Less is More” Philosophy

By showcasing how property-based testing focuses on core properties rather than exhaustively testing every possible input, we’ll emphasize the “less is more” approach to testing. Attendees who appreciate the elegance and efficiency of this philosophy will find resonance in the concepts discussed.

Why I think I am the best person to speak about this

Expertise

I’m well-equipped to deliver an insightful talk on property-based testing with several years of hands-on experience in Go programming and software quality assurance. I’ve actively integrated property-based testing into our development process at [redacted], leading to tangible improvements in code quality. This experience uniquely positions me to offer practical insights, real-world examples, and strategies for successfully implementing this approach in Go projects.

Value to Attendees

This talk bridges the gap between theory and practice, offering attendees a comprehensive understanding of property-based testing’s impact on code quality. I aim to provide actionable insights that attendees can readily apply in their development workflows. By sharing successes and challenges encountered during our adoption of property-based testing, I hope to inspire fellow Go developers to explore and embrace this powerful testing paradigm.

Interactive Engagement

I’m committed to fostering an interactive and engaging session. Questions are highly encouraged for this talk. Attendees can expect to leave with a solid grasp of property-based testing’s benefits and practical steps to begin implementing it in their projects immediately.

^ back to index

24. Gopher-ize Your Microservices with gRPC: Building Cloud-Native Applications with Production-Grade Excellence

Abstract

Description

Creating high-quality, scalable, and maintainable Cloud-native applications is a critical component for ensuring the performance and reliability of our systems as stakeholders.

This session delves into the realm of building applications with production-grade excellence using Go and gRPC communication with a move towards HTTP 2.0. Go’s strengths in building high-performance, cloud-native applications are examined.

We then dive into the heart of the session: gRPC. Participants will discover its power in generating server and client stubs for multiple languages, enabling seamless communication between services. It also handles fault tolerance and idempotency we need in a scalable system.

Performance being a critical aspect for us as stakeholders, we explore how gRPC outperforms other protocols like REST with JSON or XML. It also helps us leverage ProtoBufs and HTTP/2 over TLS, ensuring efficient data serialization and header compression resulting in a highly performant system.

Attendees gain insights into overcoming challenges and maintaining SDKs for client-side communication in gRPC, establishing it as a robust choice for both internal and public-facing services.

Lastly, we present a practical approach to building a scalable system using Go gRPC microservices. Automation and CI/CD pipelines integrated into a Kubernetes environment offer hands-on experience in deploying production-grade systems.

Notes

^ back to index

25. Hardening Go Currency, Using Formal Methods Of Verifying Correctness

Abstract

Description

Description

Introduction

When you want to write programs, you start with a blueprint or a rough sketch of what you want the behaviour of the program to be, not really caring about how you will be implementing it, this is a great practice in general, especially when you can conceive of all the possible routes your program can take and are clear about what you want it to achieve. But what if you’re building critical or complex systems?

Go provides support out-of-the-box to build concurrent and distributed systems. These are notorious to build and test, and very quickly you realise that there is a need to specify that it works correctly for every possible condition it can encounter.

For this, you need tools to check your blueprints, and to think about your programs scientifically. To specify “precisely”, the best way is to build mathematical models of your programs, to define unambiguously What your program should do, before you implement the How, and TLA+ is an example of such a way of describing your designs.

It uses math, and a language built around it to Formally Specify your system’s behaviour and do an exhaustive sweep of all possible states your system can be in, and verifying that your program runs correctly as defined by your specification every time.

Describing your systems formally can do more than just ensuring your critical system is designed correctly, for already existing systems, you can find subtle bugs that could not have easily been found by simple testing and it also provides a great way of documenting and explaining your system in the most precise way possible without ambiguities.

Outline

• What is the need to model your program? [1 mins]
  • When you start writing a piece of code, you have a rough sketch of ‘What’ you want it to do
  • As the complexity of your program increases, especially with concurrent or distributed systems, that rough sketch needs to be promoted to maybe a blueprint, or a functional definition of its behaviour
    • We also quickly realise that there is a need to design the system in a way that it can run correctly for every state that it can be in, this is especially important when designing critical systems.
    • How do we ensure that our system is designed in a way that it doesn’t crash or reach incorrect states?
• Let’s look at Concurrency, tools for which are provided natively by Go by means of Goroutines and channels [1 mins]
  • These are multiple systems, that are running independently, and have a shared global state
    • Non-deterministic: Two executions of the same program with the same input can produce different results
    • Example: Writers and Readers from a single queue, results can differ with just changing the order of who writes and who reads from the shared queue
  • Even with a simple monolith architecture, with just a frontend, a backend and a database, there are two points of concurrency.
• Let’s design a simple banking system [4 mins]
  • In a system where Person A can transfer money to Person B
    • Bank needs to check if Person A has sufficient funds
    • Deduct amount from Person A’s bank account
    • Add amount to Person B’s bank account
  • Just in this simple system, one step may not finish before the other starts -> Races, Crashes/Partial Failures
  • Can writing Unit Tests solve this issue? For this particular example, if number of simultaneous transfers is N, the number of unit tests to write is (3N)!/(3!)^N - Huge for such a simple system!
• Alternative? Formal Specifications [2 mins]
  • Programs can be modelled in a number of ways: Turing Machines, Automatas, Programming Languages
  • But all of this can be described in terms of a State Machine
    • This means describing your program as a set of “behaviours” where each behaviour is a ‘sequence of discrete steps’
    • This requires us to define the initial state of the system, and the next state of the system
    • You can have multiple next states for a current state (modelling Non-Determinism)
    • TLA+ gives us the framework to do this
  • TLA+ is a language that lets you write specifications formally, “formal” specs are needed if you want to apply tools to them.
    • For example to run model checkers to verify the correctness of your specification by running it against all possible executions of your program, and verifying that it always executes ‘correctly’ as specified by the model.
• Let’s look at a sample spec, to see what it looks like in the context of TLA+ [3 mins]
  • Define some language specific terminology
    • Extends, Constants, Variables, Init State and Next State
    • A toy example that shows the formal spec for Euclid’s algorithm (after defining what Euclid’s Algo does in English rather than Math)
• That’s a lot of theory, let’s try to define our own spec for an incorrectly written down program that deadlocks because of poorly written Go code [6 mins]
  • During the talk, of course I won’t reveal this, we will have a simple program that uses channels to read and write data using go routines, with a subtle bug that causes it to deadlock
    • We write a simple spec for this using the knowledge from the previous slides, and define what the conditions of our program is to run “correctly”, one of which is to not deadlock
    • The TLC Model checker will show a deadlock that it caught, we can then expand this and see what exact steps led to this deadlock from the model checker, and amend the spec, and therefore the program
    • We show that this now is verified to execute correctly using the model checker
  • Sure, this is just a simple example, but this is just a simplification of an actual error that was found in the very popular Gops library, this issue was raised here: Github Issue Link
  • Hillel Wayne then demonstrates the bug with his TLA+ spec for the implementation and finds the deadlock condition with the model checker, and then fixes the bug by making changes to the spec, and therefore the actual implementation here (explain briefly)
• To drive the point home, that this is not limited to just modelling toy systems, but real systems, here is what Amazon engineers had to say, and the also wrote a paper about how they used formal methods at AWS. [1 min]
  • They used TLA+ in 10+ large, complex real-world systems
  • In every case, TLA+ added significant value by preventing subtle, serious bugs that could have reached production
  • And also gave them enough understanding and confidence to make aggressive optimisations without sacrificing correctness of their systems

Conclusion

We covered quite a bit, and just one talk isn’t enough to convince or completely outline this way of thinking about building systems, but there are some takeaways that I think are important.

• What do programmers need to know about thinking about your code in this way? [1 min]
  • Everyone thinks they are thinking, but if you don’t write down your thoughts you can really go wrong
  • There is a need to think before coding, or more clearly, the need to Write before you code
  • Any piece of code that someone is likely to use or modify, needs to be specified in some way
    • That someone can be you next month
    • There is importance in specifying everything your code does and if required, how it does it
    • You should always specify your code “above” the code level, in terms of states and behaviours or input/output behaviours.
    • Thinking mathematically provides a rigorous way of doing this, in precise terms and being as unambiguous as possible.
• Why write formal specs? [1 min]
  • Even if the above talk doesn’t apply to you, and you never write complex critical systems, learning to write formal specs helps you write informal specs that you need to write anyway
  • We learn to write programs by writing them, running them and then correcting the errors
  • We can learn to write formal specs by writing them, running them against a model checker and then correct errors
  • Writing specifications not only provides a rigorous way of defining and verifying your designs, it also provides a great way to find bugs in your systems
    • Disclaimer, this is not the intended purpose of writing a formal spec, writing a formal spec is hard work, it requires thinking in a way that isn’t intuitive to most programmers as we are generally used to implementing the ‘How’
    • Though we can find subtle bugs because the Model Checker can run an exhaustive param sweep against your spec, and run all possible executions, the cost of writing it is still high as seen in our example above
    • It’s always better to write the spec first and then focus on implementation
  • Writing formal specs provides a great way to explain your design precisely, and document it in the most clear way possible as the set of behaviours your program can execute given the current state
  • TLA+ may or may not be the best formal language for you needs, and that’s why there’s multiple other languages available, but starting to write formal specs is a great way to practice thinking about your systems mathematically.

Notes

^ back to index

26. Go and FedRAMP: Boring!

Abstract

Description

In this talk, you will learn what FedRAMP is and why FedRAMP. Then you will learn how Go+BoringCrypto helps you to achieve FedRAMP compliance in your Go-powered cloud services. And you will also learn the Go landscape for FedRAMP, i.e., the available options for you to achieve FedRAMP compliance.

Introduction

1. What and why FedRAMP?

   1. FedRAMP is a United States (US) government standardized approach to security authorizations for cloud service offerings
   2. Why we want to enroll? More profit → Achieving a certain level of FedRAMP allows us to sell our cloud services to the US Government

2. FedRAMP and Go+BoringCrypto

   1. Technically, FedRAMP = FIPS (Federal Information Processing Standard) plus others.
   2. The others are more towards processes, i.e., ensure backups are appropriately configured, change management processes etc.
   3. FIPS is a set of rules that outline the basic security needs of cryptographic modules.
   4. Go+BoringCrypto is one of the options to satisfy FIPS requirement.

Go+BoringCrypto

1. How it helps?

   1. Go+BoringCrypto is a Golang (yes! our beloved Golang!) that uses crypto module from BoringCrypto.
   2. Go+BoringCrypto uses a FIPS Validated encryption module. Refer to BoringCrypto FIPS 140-2 Non-Proprietary Security Policy.
   3. Go applications that are compiled using Go+BoringCrypto will be FIPS Compliant.
   4. Being FIPS Compliant is one of the requirements to achieve a certain level of FedRAMP compliance.

2. What is BoringCrypto and how Go uses it?

   1. BoringCrypto is a cryptographic library which provides FIPS 140-2 approved cryptographic algorithms to serve user-space applications.
   2. BoringCrypto exposes a C-language API, and the Go applications will be the user-space applications that consume it.
   3. Go uses it via goboringcrypto.h, example aes.go.

3. How do Go apps use Go+BoringCrypto

   1. Build our Golang application with Go+BoringCrypto
      1. Use GOEXPERIMENT=boringcrypto flag.
      2. Need to enable CGO.
      3. Supported OS/Arch combinations: linux_amd64, linux_arm64.
   2. Verification (will show a small CLI-based demo on how to use and verify it)
      1. Use go tool nm lists
      2. Or by importing crypto/tls/fipsonly
   3. Caveat
      1. The Go application still needs to ensure that it uses FIPS approved cryptography, as mentioned in Approved Security Functions for FIPS 140-2.
      2. Reason is: Go+BoringCrypto does not prevent a Go application from using non FIPS approved crypto, such as MD5.

Go Landscape for FedRAMP

What are the available options other than Go+BoringCrypto?

1. Red Hat Enterprise Linux (RHEL) go-toolset

   1. It is fork of Go+BoringCrypto.
   2. Available as Docker image, however the container should run on a RHEL host with FIPS enabled (which means you will need to pay some subscription).
   3. Starting point: Red Hat Developer Portal: Is your Go application FIPS compliant?

2. Microsoft’s fork of Go+BoringCrypto

   1. Repository: microsoft/go.
   2. microsoft/go use OpenSSL as its FIPS cryptographic module.
   3. The Go app needs to run in an OS which has a FIPS-compliant OpenSSL.
   4. microsoft/go supports more OS/Arch combinations: linux_amd64, linux_armvl64, linux_arm64, windows_amd64.

Conclusion

We can use Go+BoringCrypto for our Go app to achieve FedRAMP compliant Go app. Moreover, there are other options like RHEL’s go-toolset and microsoft/go.

Notes

Why are you the best person to speak on this subject?

I have been actively working with Go for the past 3 years, and last year I did research on FedRAMP, FIPS and Go. The outline of the research is reflected in this proposal description.

Technical requirements of the talk

I will use PowerPoint and will need to switch to my Terminal to do a small demo.

^ back to index

27. Bugs Light Year Away With Fuzz

Abstract

Description

In the process of building software, we usually write test cases to determine if different features within a system are performing as expected. We write multiple test scenarios trying to cover most edge cases but there is a possibility we might still miss a few. To err is human, but this could lead to security vulnerabilities, a programmer’s nightmare.

Traditional testing methods like unit tests, often fail to simulate real-world scenarios and unexpected inputs, leaving potential security risks undiscovered. And security vulnerabilities are one of the root causes of cyber-security threats.

Fuzz testing solves this critical problem of discovering unknown bugs and flaws in software applications.

Fuzzing is a process of finding defects & vulnerabilities in which system under subject is repeatedly injected with invalid, malformed and unexpected inputs. It can reach edge cases which humans often miss.

By identifying and addressing these issues early on, fuzz testing helps improve the overall security, stability, and reliability of software systems, mitigating the risk of costly breaches and system failures.

With the release of v1.18, Go has finally added Fuzzing or fuzz testing as a part of its standard toolchain. It is included in Go’s testing library since it is a form of test only. And what is great about this feature is that you don’t need to be a security expert to write the fuzz tests.

Think of fuzzing as the ultimate form of unit testing.

Join me in this talk to explore more about the concept of fuzz testing, its significance in improving software security, and how it can be effectively utilized within the Golang ecosystem.

Notes

Outline

• Bug in my own backyard

While working on a project, my team faced a serious issue which we were not able to catch on time. We could have avoided that issue very easily if there were Fuzz tests in place.

• What the Fuzz?

We are generally used to writing unit tests, integration tests etc. for our software applications, but what is this fuzz test thing?? Is it like unit tests ?? Let’s take a look at exactly what fuzz testing is and what’s the hype about.

• How to Fuzz?

Now that we know what fuzz tests are, let’s checkout how to fuzz test your golang application. We will take a function which generally is unit testable and will try to write fuzz tests for it Live and will see it helps us find any new unknown bugs which we didn’t realize exists

• How does Fuzzing Work?

As important as it is for us to know how to write fuzz tests, it is equally important to know how the fuzzing process works internally and how the fuzzing engine is optimized to generate seed corpus entries to find branches in our code to increase test coverage.

• Unit Test vs Fuzz Test

Now that we are familiar with both unit tests and fuzz tests, we will try to understand what sets both apart.

• What to Fuzz & Why?

When dealing with unit tests we define what will be the input to a function under test and what is the expected output for that certain input, but the same is not the case with fuzz tests. Here we will take a look at a few cases which makes writing fuzz tests worth it.

• Bugs Fuzzing can identify

Unit tests are great for verifying individual units of code, while fuzz testing excels at exploring the input space and finding unexpected bugs, making it a valuable tool for improving software security and robustness.

• Tips to write fuzzable code

To fully utilize the benefits of fuzz testing, we need to ensure that we follow the best practices. We will explore some ways to ensure that fuzz testing is done efficiently and how to write code which is easier to fuzz test.

Why should you select this talk?

Even though fuzzing was possible before Go 1.18 with the help of third-party fuzzers, now being included in the standard toolchain, it is expected to be used a lot with other utilities from the testing library. Since fuzzing is still a new and untested feature in Go, people will explore it in the coming time and what is better than a talk to get started. Along with that, I have a good understanding of the topic that attendees of any level would be able to connect and benefit from.

I have presented a few talks on fuzzing in [redacted] and [redacted], so I have few things to share with the community, how my experience has been with the features, it’s good parts and also the bad parts.

[redacted]

^ back to index

28. Bridging the Security Tool Gap for Go

Abstract

Description

Notes

• Have been working on Go ever since its inception.
• Developed the first refactoring tool for Go.
• Expert in static analysis to detect security problems.
• Worked on Go in the academia (in research projects) and in the industry (in tools).

^ back to index

29. High performance regular expressions using re2 and WebAssembly, no cgo required

Abstract

Description

Regular expressions are the workhorse of security firewalls, for example the standard OWASP Core Rule Set executes dozens of very complex expressions across the content of HTTP requests and responses. Go’s standard regexp library can execute these fine, but performance drops due to the complexity of the expressions and potentially large input size. RE2 is a mature, C++ library for regular expressions that is widely used and even the inspiration for Go’s regexp package. RE2 tends to perform significantly better for these complex expressions.

To take advantage of the maturity and performance of RE2, many languages provide wrappers for reusing the library. For Go, we may turn to cgo to similarly wrap RE2 to bring it to Go developers. However, cgo introduces limitations such as requiring a C toolchain for building, possibility for incompatibilities with different libc versions, and limited platform support. Indeed, many popular Go applications are built with cgo disabled to ensure broad usability and we would not be able to bring RE2 to these applications if using cgo.

Luckily, C++ code can be compiled to WebAssembly using LLVM and loaded in Go applications using the pure Go runtime, wazero. go-re2 takes advantage of this to provide RE2 to any Go application in a package that can simply be require'd without any additional tooling. The compiled, platform-agnostic Wasm binary is included in the package and will execute on any platform that Go supports. go-re2 provides the same API and is a drop-in replacement for regexp - most applications would just alias the regexp import to go-re2. The same tests as regexp are run to verify compatibility in all except for a couple of minor corner cases. Wrapping RE2 with cgo is also supported with a build tag for use cases where the tooling can be prepared for it.

There is more overhead in calling functions in a WebAssembly binary as opposed to using cgo, but for cases like security firewalls with complex expressions, this overhead is not significant vs the performance of evaluating the expression. The same benchmarks as the standard regexp package show that for simple expressions and small inputs, the standard library performs better due to this overhead. But for complex expressions or large input, go-re2 performs, sometimes orders of magnitude, better, even though there is overhead for calling into Wasm. When running the OWASP firewall test suite, go-re2 outperforms for all cases except empty input.

• Overview of WebAssembly and using it in Go with wazero
• Explain LLVM’s WASI target and how to compile C++ libraries to WebAssembly for use in Go
• Show the build tooling we developed for external dependencies like RE2 and common techniques needed to get existing C++ code to compile to Wasm
• Explain patterns for writing libraries that wrap Wasm that can be required and support both pure Go and cgo modes

At the end of the presentation, audience members should have an understanding of how to develop a Go library that wraps C++ compiled to WebAssembly, unlocking an ecosystem of existing code that can be of use in Go applications.

Notes

^ back to index

30. Comprehensive monitoring of go application without code changes.

Abstract

Description

Notes

^ back to index

31. Unleashing the Power of WebAssembly System Interface (WASI) in Go

Abstract

Description

The WebAssembly System Interface (WASI) is gaining popularity as a compile-once-run-anywhere target for the developer and cloud-native applications. WASI is a system interface that provides a standardized way for WebAssembly modules to interact with the underlying system, regardless of the specific operating system or architecture.

In this session, we will delve into the WebAssembly System Interface (WASI), investigating its existing support in Go. Furthermore, we will explore the newly introduced WASI support in the Go toolchain, highlighting the advantages it brings to Go developers.

To reinforce the covered concepts, we will conduct a live demonstration of WASI support in Go.

By the end of this session, attendees will have a comprehensive understanding of the WebAssembly System Interface (WASI) in Go.

Agenda:

1. Introduction to WebAssembly System Interface (WASI)
2. Overview of Go’s Existing WebAssembly Support
3. Overview of WASI Support in the Go Toolchain
4. Live Demonstration

Notes

As an experienced developer who has worked extensively with Go and WebAssembly (Wasm), I am well-versed in the subject matter. My background includes practical hands-on experience with Go’s WebAssembly support, as well as a previous talk on [redacted].

My knowledge of Go and WebAssembly, combined with my communication skills, make me the ideal person to speak on this subject. I can effectively convey the concepts, demonstrate practical examples, and provide insights into leveraging the WebAssembly System Interface (WASI) in Go.

^ back to index

32. Using Kubernetes APIs to do leader election for applications

Abstract

Description

In the rare cases where an application would need to ensure that only one of its many replicas would need to operate a certain operation at one time, we would kind of need to probably resort to including a leader election mechanism in the app. With the leader election mechanism, this would ensure that operation can continue carrying on even as the replicas die and get replaced.

The following talk covers a example implementation of how leader election can be done by utilizing Kubernetes APIs, with demonstrations on how the applications would continue working even as the applications replicas die off and get replaced.

Notes

Topic involves covering how such an application that deals with leader election and how it can be “slightly simplified” by using Kubernetes APIs. This was demonstrated within the company with the following page within this Github repo: [redacted]

A blog post on this topic will be released end of August [redacted]

^ back to index

33. Go low latency patterns

Abstract

Description

In today’s fast-paced digital landscape, optimizing the performance of applications is paramount, especially for performance-critical paths. In this talk, we will dive deep into the world of Go low latency patterns, exploring the techniques, examples, and explanations for writing efficient, high-performance code in Go.

As a seasoned software engineer with over a decade of experience, I currently work with an algorithmic trading company where every microsecond counts. Drawing from my firsthand experiences and empirical analysis, I am excited to share valuable insights and best practices with the audience.

• The talk will begin with an introduction, highlighting the challenges and significance of low latency in modern applications. We will then explore Go’s memory access and garbage collector to understand how they impact the overall performance.
• Next, we’ll delve into essential tools for memory and performance profiling, providing attendees with actionable strategies to analyze and optimize their projects effectively.
• A critical aspect of achieving low latency is avoiding unnecessary memory allocations. In a dedicated section, we will discuss techniques to minimize memory allocations for performance-critical paths, leading to faster and more responsive code.
• The Go standard library offers powerful tools like object pools, designed to optimize memory usage. In this talk, we will compare the utilization of Go’s standard library for object pooling with custom implementations, empowering attendees to make informed decisions for their specific use cases.
• Additionally, we will explore hacks and optimizations that can be employed to further reduce memory allocation and boost performance.

In conclusion, attendees will gain a comprehensive understanding of crafting performance-critical code with care, emphasizing the importance of thoughtful design and execution. By the end of the talk, developers will be equipped with the knowledge and tools to create high-performance applications that excel even in the most demanding environments.

Join me in this informative session to unlock the power of Go low latency patterns and elevate your projects to new levels of efficiency and speed. Let’s make every millisecond count!

Notes

Relevance and Target Audience

The talk is designed for an intermediate audience with prior knowledge of profiling garbage-collecting and memory model in Go. Attendees should have some understanding of Go programming concepts and be familiar with performance optimization challenges, making them well-prepared to absorb the insights and techniques I’ll be sharing.

Why I’m the Best Person to Speak on this Subject

As a technical lead at an algorithmic trading company, my expertise lies in crafting high-performance applications for the financial industry. The company’s success is a testament to the effectiveness of the low latency patterns I’ll be presenting, and my 10+ years of software engineering experience have equipped me with valuable insights into performance optimization.

^ back to index

34. Designing a Disk-Based Key-Value Store in Golang

Abstract

Description

Abstract

This talk will explore the design and implementation of BarrelDB, a disk-based key-value store in Golang based on the Bitcask paper by Riak. Attendees will gain insights into the architecture, benefits, and limitations of BarrelDB, and how to use it in their own projects.

Talk Description

Introduction:

1. Brief introduction to Bitcask and it’s history.
2. Designing BarrelDB, a Golang implementation of the above mentioned Bitcask paper.

Outline:

1. Understanding Bitcask: An overview of Bitcask, its design principles, and why it’s a suitable model for a disk-based key-value store.
2. Designing BarrelDB: Detailed walkthrough of BarrelDB’s design, explaining how it adheres to the Bitcask API. Discussion on the decisions made during the design process.
3. Benefits of BarrelDB: Discussing the advantages of BarrelDB’s approach, such as low latency, high throughput, predictable performance, and crash-friendliness.
4. Limitations and Workarounds: Addressing the main limitation of BarrelDB - the requirement for all keys to fit in RAM. Exploring potential workarounds, such as key sharding.
5. Using BarrelDB: Demonstrating how to use BarrelDB as a library in Golang projects. Highlighting a super simple and minimal Redis-compatible server implementation.
6. Performance Benchmarks: Sharing performance benchmarks of BarrelDB, showcasing its efficiency and speed.
7. Future Improvements: Discussing potential improvements (like enabling cluster support using Raft) and features for future versions of BarrelDB.

Notes

I am an experienced Go developer with a deep interest in database systems and performance optimization. I have spent considerable time studying key-value stores, specifically the Bitcask model used by Riak. This exploration led me to design and implement BarrelDB, a disk-based key-value store in Go.

My talk is based on first-hand experience and includes practical examples and demonstrations. I believe this will provide attendees with a clear and applicable understanding of the subject matter.

^ back to index

35. The curious case of your IDE

Abstract

Description

Description

How does my editor know what I want to type? Is that some black magic? But If you write code, you know it’s not magic. There is definitely something clever happening under the hood. Did you ever wonder what that is? I did some work to solve that puzzle and I have some answers for you. And you guessed it, this Talk summarizes what I found and it is pretty interesting!

Since we are software developers, we probably will have a follow-up question. We have a lot of editors which need basically the same fundamental functionality. How does it work across editors? Does each editor have their specific implementation?

Us Gophers are united by the love of Go, but let’s be honest, we do have our preferences when It comes to our code editors/IDEs. How does Gopls the Go Language Server work with all of them?

Oh, wait, what is a Language Server?

That’s a lot of questions. I promise I’ve answers to all of them!

Agenda

Here’s what you can expect to learn in this Talk. I hope I made you curious enough to hear me out :)

• Introduction (2 Mins)
• Language Server Protocol (5 Mins)
• Gopls (5 Mins)
• Let’s build a Language server (Live Demo) (8 Mins)
• Conclusion (2 Mins)

Notes

Why me?

I work for a company called [redacted]. I’ll quote what we do from the website below.

Autogenerate production-grade APIs on all your data

[redacted] I’m a Senior Software Engineer who is leading the developer experience team and closely working on the Authoring solutions for [redacted]. We have been building a language server for our use case and have been using Gopls, the Go language server as a reference. That’s what prompted me to submit my talk.

I was pretty stoked to learn about how the language servers work under the hood and I assume there are some curious heads who’ll feel the same.

Can you count on me to deliver?

I’ve spoken at [redacted] in the past. That was my first Talk. After that Covid hit and I haven’t spoken in a public event yet. But I’ve been an avid participant in internal talks and workshops which unfortunately is not publically available. So I’m not rusty and I think I do a pretty good job delivering what I promise.

^ back to index

36. Simplifying technical onboarding for remote workplaces

Abstract

Description

Premise

Many engineering teams around the world had to suddenly embrace remote work during COVID lockdown. Processes had to be built for almost all aspects of the remote workforce for the organization. As expected, there were a bunch of challenges along the way, and not a lot of guidelines or quality resources available.

As a senior member of the team and a part of the hiring panel, interviewing and onboarding engineers remotely consumed a lot of my time and effort and became a challenge quickly. In this talk, I discuss these challenges and the solutions we implemented to efficiently onboard new team members and help them be productive quickly.

Approach

Challenges

• How to get new team members quickly acquainted with:

  • the product and offerings
  • the technology stack
  • the tools used by the team

• How to track team productivity?

Solutions

• Introduce our technical onboarding experience
• Talk about the Technical Onboarding Document
• Building a knowledge wiki for the team
  • Runbooks for incident handling
  • Guidelines for coding practices, testing, on-call, code reviews and deployment
• Using Go interfaces to outline entire service components for understanding how current systems work
• Exercises for implementing toy architectures for the above interfaces using Go for better understanding

Conclusion

Wrap up the discussion with key takeaways and take questions from the audience, if time permits.

Notes

Why me?

• As a senior member of the engineering team and part of the hiring panel, I experienced the pain of remotely onboarding new team members firsthand
• Took the initiative to improve the technical onboarding experience for the team
• Built a process and structure to simplify it for the rest of the teams in the organization
• Saw the impact in action when I started leading my own team as an engineering manager
• I’ve been working with Go for over 5 years now and would love to share my learnings on building productive teams with the Go community
• Here’s my LinkedIn profile: [redacted]

^ back to index

37. An optimisation saga with Go

Abstract

Description

Premise

As an engineering unit, we track a metric closely: a ratio of our Team’s revenue to our cloud operations costs. Anticipating financial uncertainty due to COVID lockdowns, we optimised our cloud costs without compromising system performance. This talk is about the concepts we leveraged to achieve the same and our learnings.

Approach

Our internal services are written in Go and heavily use AWS SQS for asynchronous message processing, Postgres for persistence, and Redis for caching. I’ll briefly talk about common optimization concepts like database indexing, connection pooling, and long polling for SQS.

The talk’s core is about the following 3 concepts, which I’ll explain with short examples.

1. Reducing network round-trips for data store interactions

• Introduction to the concept of combining independent commands to the data store
• Introducing Redis Pipelining and SQL query batching with an example
• Impact (reduced network round trips, reduced load on the data store, and cost savings)

2. Batching SQS payloads for cost efficiency

• Leveraging Golang primitives like channels and buffers to batch SQS payloads for reduced cost
• Briefly touch upon future work to compress payloads
• Impact (cost savings)

3. Probabilistic data structures

• Briefly talk about probabilistic data structures (Bloom Filters in particular)
• Talk about our use case of efficient existence check for an entry in a large dataset
• Impact (performance, cost, reliability)

Conclusion

The audience will have the following takeaways:

1. Network round trips are costly, and can be reduced for certain kinds of data store interactions by combining them.
2. Batching payloads for managed messaging queues like SQS is a nifty way to save on cloud costs.
3. Probabilistic data structures can be leveraged wherever approximate answers are acceptable for querying large datasets in real-time

Remarks

• I presented this talk in [redacted] Golang Meetup June 2023 and it was very well received.
• Talk Recording: [redacted]
• Slide deck: [redacted]

Notes

Why me?

• I led the team efforts on the performance optimization and cost-saving exercise
• Built a knowledge wiki to help the rest of the teams in the organization achieve similar results
• Been working with Go for about 5 years now, and would love to share my learnings about creating robust distributed architectures with the Go community
• Here’s my LinkedIn profile: [redacted]

^ back to index

38. Towards Modern Development of Cloud Applications

Abstract

Description

Service Weaver is a programming framework that makes it easy to write, deploy, and manage high-performance distributed applications in Go. Service Weaver improves application latency by up to 15x and reduces cloud costs by up to 9x compared to a typical deployment in the cloud using microservices.

1. Programming Model

The developer writes the application like it’s a traditional, single-process Go executable that runs on the local machine, that is modularized into logically distinct components. The runtime will take care of cloud configurations and integration with the cloud provider (e.g., breaks down the components into a set of connected microservices, monitoring, tracing, logging).

Benefits of this programming model

• The developers can focus solely on writing their application code (e.g., don’t have to setup networking endpoints, to create network stubs, to do service discovery);
• The developers can modularize their code without paying the performance overhead caused by over-splitting into microservices;
• The developer can change the network topology of their application easily and dynamically;
• It enables the runtime to provide optimized runtime solutions and enable new usecases;
• It enables the runtime to run the same application binary in any cloud environment.

2. Runtime

Manages the execution of an application (e.g., colocate components, assign them to OS processes, replication, resource management, authentication, etc.).

Provides different plugins that enable to run the same application binary in any distributed environment. Out of the box, Service Weaver supports three runtime plugins:

• Local runtime, which runs the application as a set of OS processes on the local machine;
• SSH runtime, which runs the application across a set of machines using SSH;
• GKE runtime, which runs the application as Pods on GKE;
• Kube runtime, which runs the application on vanilla Kubernetes;
• Easy to write new plugins for AWS, Azure, other clouds.

What runtime enables

• Birds-eye view into the app - leads to smarter scaling, placement, co-location decisions;
• Because all components run at the same version - it enables the implementation of highly-efficient serialization and transport protocols;
• Provides affinity based routing embedded in the application itself - easy to create stateful applications and route requests to different component replicas based on load information;
• Same testing, profiling, debugging experience on the local machine as in the cloud;
• mTLS support with zero config.

3. More details about the talk

We will talk about our own experience developing cloud applications, and also key findings based on conversations with various infrastructure teams at Google.

The way people write cloud applications today is very cumbersome, hence it slowdowns innovation and hinders applications’ performance. We argue that the key reason for this is the way people organize their application code around different binaries and run them independently as microservices. Instead, we believe that (1) people should just focus on the application business logic, and split the code at logical boundaries based on the business logic; and (2) let the runtime deal with the execution challenges (e.g., how to split into microservices, how to connect them, resource management, etc.).

We will walk through our framework that uses a custom transport protocol, and custom serialization, through our Go code generator, and how easy is to run/test/manage/debug the applications both locally and in the cloud. We will also talk on how we leverage open source projects like Kubernetes, Prometheus, Perfetto, Jaeger and Open Telemetry to deploy and instrument applications.

Notes

[redacted] gave multiple talks at various conferences and events.

We would also like to organize a workshop if that would be an option.

^ back to index

39. WebAssembly beyond the browser

Abstract

Description

WebAssembly (Wasm) allows you to compile native code and run it in a secure and performant way in the browser. The WebAssembly System Interface (WASI) started enabling Wasm to run outside the web browser in environments such as edge computing and cloud microservices. Docker has also recently announced support for Wasm, allowing it to be used as a lightweight alternative to Linux containers.

Whether Wasm will replace containers remains to be seen but it’s definitely worth learning more about it. In this talk, I’ll introduce Wasm, the terminology and landscape around it, and its current state as a server side technology. We will also look at some demos in Go and tools for working with Wasm on the server side.

Notes

^ back to index

40. Facilitating Innovation in a Post-COVID19 World: Cultivating a Climate for Paradigm Shift

Abstract

Description

Notes

^ back to index

41. Bringing Data to L.I.F.E. and Life to Data

Abstract

Description

Notes

First of all, to elaborate a little bit more on the above “promotional teaser” description of this session, here is a high-level outline that forms the framework for my presentation (an acronym formed by the word “LIFE”), the four pillars of relevant data:

1. Legacy
2. Integrity
3. Fervency
4. Efficiency Secondly, here are the learning objectives for this session: The participant/attendee will…

^ back to index

42. The power of saying "I don't know"

Abstract

It’s something we all struggle with, admitting we don’t know something. But I’m here to show you the power of saying “I don’t know” to people.

Saying “I don’t know” doesn’t have to be the end of a conversation, in fact it can be the start of an entirely new, exciting conversation.

Description

It’s something we all struggle with, admitting we don’t know something. But I’m here to show you the power of saying “I don’t know” to people.

Saying “I don’t know” doesn’t have to be the end of a conversation, in fact it can be the start of an entirely new, exciting conversation with learning opportunities for all parties.

We will talk through scenarios where we don’t feel comfortable saying it, ways we can feel comfortable saying it, and the good things that come from it.

Outline/structure of the Session Why we don’t say I don’t know Why we should say it How to say I don’t know to clients How to say I don’t know as an expert How to say I don’t know as a leader A deep (and revealing) discussion on the underlying reasons why we feel afraid to say “I don’t know” to people.

Notes

^ back to index

43. My job as a software engineer is not to write code

Abstract

Many software engineers are lead into the false assumption that we are hired to write code.

This talk challenges that perception and discusses the real reason we are paid to turn up to work every day.

Description

Many software engineers are lead into the false assumption that we are hired to write code.

This talk challenges that perception and discusses the real reason we are paid to turn up to work every day.

It is all about recognizing that as software developers we are not hired to write code, we are hired to solve business problems.

My belief is that it’s important for developers to realise that, as it helps inform their decision making.

Notes

^ back to index

44. How to communicate anything to anyone and see a real impact

Abstract

Everyone thinks they are a good at communication, but how many times have you been at an event talking to someone you really didn’t want to?

They didn’t go into the communication with the right mindset and the right preparation

After this you’ll know your communication sucks and how to fix it.

Description

Abstract: Everyone thinks they are a good at communication, but… how many times have you been at an event talking to someone you really didn’t want to talk to? Been sold to by someone who didn’t get that you weren’t interested?

These are examples of bad communication and they all have a few things in common, they weren’t efficient and they weren’t effective.

They didn’t go into the communication with the right mindset and the right preparation

Also, sorry to say it, but your own communications probably suck too. But after this workshop you’ll have a leg up on your competition: you’ll know your communication sucks… and you know how to fix it.

Outline/structure of the Session: Bad communication, and why it happens What’s the right mindset to have What’s the right preparation to do Examples of efficient and effective communication I will take you through my number 1 and number 2 rules for efficient and effective communication.

Notes

^ back to index

45. Debugging Difficult Conversations - Or "How not to chicken out"

Abstract

Description

Over 80 percent of programmers found that learning to handle Difficult Conversations lead to finding better solutions to theirs problems.

Being able to participate in, and even drive, Difficult Conversations means we can resolve the challenges of our relationships with other people, but it also means we can earn their trust and respect. When we are able to engage truthfully and respectfully with the people around us we can improve our relationships with them and smooth out the inevitable bumps on the road.

This talk will teach you:

• What Difficult Conversations are and what happens when you ignore them
• Why having Difficult Conversations can be beneficial to you, your team, and your career
• A framework to help you prepare for Difficult Conversations

Notes

^ back to index

46. Athens to Algorithms: Zeno as a Tech Leader

Abstract

Description

In the lightning-fast world of technology, leadership calls for more than just technical prowess. It requires a balance of mind, a mastery of self, and a distinctive approach that can navigate the rollercoaster of innovation and disruption. So, where might we find this kind of wisdom? Would you believe it if we told you that the secret lies in the ancient philosophy of Stoicism, born in the heart of Athens over two thousand years ago?

I invite you to join me on a fascinating journey from the cradle of Stoicism in ancient Greece to the buzzing industry of technology. This isn’t your average talk on leadership; it’s an exploration of the hidden power that fuels resilience, emotional intelligence, and strategic thinking in our tech leaders today. We’re about to unlock an age-old secret and unveil the unseen force that has been driving successful tech leaders around the globe.

Ready to decode the mysterious formula for impactful leadership? Come, and be part of this enlightening journey. The secrets from ancient wisdom await you.

Notes

^ back to index

47. The Art Of Scalable Intelligence: Distributed Machine Learning with Go

Abstract

Description

In this deep dive talk, we will explore the world of distributed machine learning architectures using Go, a powerful and efficient programming language. Scaling machine learning algorithms across distributed systems presents unique challenges, and Go’s concurrency model and robust ecosystem make it an ideal choice for building scalable ML architectures.

Throughout the session, we will unravel the intricacies of distributed machine learning in Go, uncovering fascinating insights and thought-provoking ideas. Finally, we will examine various distributed ML architectures, including data parallelism, model parallelism, and hybrid approaches, showcasing how Go’s lightweight goroutines and channels enable seamless orchestration of distributed computations.

Key takeaways from this talk will include:

• Insight into the unique challenges and opportunities of distributed machine learning architectures in Go.
• Understanding of key distributed ML techniques such as data parallelism, model parallelism, and hybrid approaches.
• Knowledge of scalable ML architectures, including data sharding, model synchronization, and fault tolerance mechanisms.
• Familiarity with the vibrant Go ecosystem for distributed machine learning, including libraries and frameworks that simplify development and deployment.
• Ability to leverage Go’s concurrency model and robust ecosystem to build scalable and efficient ML systems in distributed environments.

Notes

^ back to index

48. Building Cloud-Native Applications with Go and Serverless Computing

Abstract

Description

Serverless computing has revolutionized the way we build and deploy applications in the cloud. In this talk, we’ll explore how Go and serverless architectures complement each other, enabling developers to build highly scalable and cost-effective cloud-native applications.

We’ll start by introducing the core concepts of serverless computing and its benefits. Then, we’ll dive into the specifics of using Go with popular serverless platforms such as AWS Lambda, Azure Functions, and Google Cloud Functions. You’ll learn how to write serverless functions in Go, handle event triggers, and effectively utilize the serverless ecosystem.

We’ll discuss deployment strategies, performance optimization techniques, and best practices for building cloud-native applications with Go and serverless computing. By the end of this session, you’ll be equipped with the knowledge and insights to leverage the power of Go and serverless computing to build scalable and cost-efficient cloud-native applications.

Notes

An expert in Serverless architecture using Golang, have innovated in areas like Canary deployment, Alerting, Concurrency, etc Blog: [redacted]

Have contributed to and hosted Go microservices with 100000+ TPS!

Have build infra automation tools using Go used by 500+ developers, saving weeks of human bandwidth and reducing ETA from days to minutes.

^ back to index

49. Writing a Go logger

Abstract

Have you ever thought about writing a logger instead of using the one in the std library?

Let’s code an idiomatic logger that supports tracing and other custom behaviors out of the box maintaining blazing fast and simple APIs by using benchmarks and profiling as the foundation for our decisions.

Description

Writing a logger can be tricky and performance issues are hidden and tricky to find.

Since I wrote a logger in Go [redacted], I want to share the knowledge I gained out of that by coding a session (inspired by the open-source one I wrote) to show bottlenecks from a performance and design perspective.

The deep dive will be in writing benchmarks for encoding the log entry and profiling the whole logger design to determine where it could be improved.

Notes

^ back to index

50. Exploring Domain Driven Design in Go

Abstract

Description

Notes

^ back to index

51. The internals of the context package

Abstract

Description

Notes

^ back to index

52. Data Radar Maps : A Snapshot of Your Organizational Data Framework

Abstract

Description

The goal of this talk is to share how to quantify the level of maturity of the data framework in your organization. We know that a sound data framework is comprised of several key elements and it can be hard to visualize the state of each of these key elements.

With the novel data radar maps (built during my project with product strategy & design agency [redacted]) I show how we can audit and draft up a true representation of your data framework and track the progress of its growth and evolution.

We aim to fundamentally cover the past, present and future of your data, by doing the following

• Document how data has been stored and utilized in the organization (past)
• How to visualize the present state of maturity of their data framework (present)
• How to improve this level to greater heights leading to more insights and value from the data (future)

The data radar frame is an actionable artifact that can be used to monitor and engage your teams to evolve your data framework, thereby allowing you to boost data-driven decisions and build better products.

Key takeaways from this talk would be

• How to quantify the maturity level of your team’s data architecture
• How to create detailed reports of your data audits (sources, taxonomy, hierarchy)
• What is a Data Framework Radar Map and why it could add value to your organization?
• What are the list of tools, frameworks and best practices to grow your data framework?

You can learn more about me and the work here [redacted]

Notes

^ back to index

53. Go beyond REST: building APIs with GraphQL in Go

Abstract

Description

Notes

I have spoken at conferences across the globe.
Selected as speaker at [redacted].

Previous Talks:[redacted]

^ back to index

54. Blockchain breakthrough with Go

Abstract

Description

Notes

I have spoken at conferences across the globe.
Selected as speaker at [redacted]

Previous Talks: [redacted] I will require financial assistance for travel, visa and accommodation.

^ back to index

55. Go Beyond the Console: Developing 2D Games with Go

Abstract

Description

Notes

I have spoken at conferences across the globe.
Selected as speaker at [redacted]. I have spoken and given talks at [redacted].

Previous Talks: [redacted]

Previous Talks: [redacted]

Talk proposal accepted at [redacted]

I will require financial assistance for travel, visa and accommodation.

^ back to index

56. Boosting your API economy

Abstract

Description

How often have you reused a pre-existing API without any hiccups? APIs are no longer viewed as just a technology product but they are an asset of your organization. They are valuable assets that’ll help you to increase the scope of your organizational services. In order to increase API adaptability and consumption we need to make them available to our community and network in an appropriate manner.

Are you a mid-level developer interested in learning more about API adoption and cataloging them? then you’re at the right place!! In this session, we’ll learn how to efficiently manage your APIs and increase the chances of your API being adopted and reused. We will explore what is an API Catalog, how to build an API Catalog in order to make our APIs reusable and composable.

By the end of the session, you’ll have an understanding of API Catalog, how to build an API Catalog and the perks of building an API Catalog for your organization.

Notes

^ back to index

57. Zero Trust Security for your APIs

Abstract

Description

Notes

^ back to index

58. Who broke the build? — Using Kuttl to improve E2E testing and release faster

Abstract

Description

No one wants to be responsible for breaking the build. But what can you do as a developer to avoid being the bad guy? How can project leads enable their teams to reduce the occurrence of broken builds? In talking within our own teams, we discovered that many developers weren’t running sufficient integration and End to End tests in their local environments because it’s too difficult to set up and administer test environments in an efficient way. That’s why we decided to rethink our entire local testing process in hopes of cutting down on the headaches and valuable time wasted. Enter Kuttl. Connecting Kuttl to CI builds has empowered our developers to easily configure a development environment locally that accurately matches the final test environment — without needing to become an expert CI admin themselves. These days, we hear, “Who broke the build?” far less often — and you can too!

Session Outline:

Notes

In this session, We’ll cover: ● A quick history of our testing challenges and what led us to Kuttl ● The benefits of our new testing approach — easy to configure and minimal investment ● How we combine Kuttl and CI pipelines for more streamlined testing and fewer broken builds

Session Key Takeaways:

1. When and why we decided to rethink our e2e testing practices and our subsequent discovery of Kuttl.
2. Why Kuttl has been the perfect tool for our developers to perform better local integration/e2e testing without the burden of becoming their own CI administrators.
3. A detailed account of how we utilize Kuttl to set up development environments locally that match our final test environment in order to reduce unnecessary commits and minimize CI build breaks.

^ back to index

59. Improving performances of a slow Go logger

Abstract

Have you ever thought about writing a logger instead of using the one in the std library?

If you do so let’s discuss how to make your logger go faster by using benchmarks and profiling as the foundation for our decisions.

Description

Writing a logger can be tricky and performance issues are hidden and tricky to find.

Since I wrote a logger in Go [redacted], I want to share the knowledge I gained out of that by showing some DO and DON’T starting from a slow logger to show bottlenecks from a performance and design perspective.

The deep dive will be in benchmarking for encoding the log entry and profiling the whole logger design to determine where it could be improved.

Notes

^ back to index

60. Gentle Introduction to eBPF and XDP

Abstract

Description

eBPF (Extended Berkeley Packet Filter) is the hottest technology now a day and it makes talking to the Linux kernel far easier without actually changing the kernel itself. Now it is possible to make additional changes to the kernel related to security, networking, and observability.

As an eBPF program is loaded into the kernel, a verifier ensures that it is safe to run, and rejects it if not. Once loaded, an eBPF the program needs to be attached to an event so that whenever the event happens, the program is triggered.

eBPF allows us to collect customized information about how an app is behaving without having to change the app in any way, by observing it from within the kernel. We can build on this observability to create eBPF security tools that detect or even prevent malicious activity within the kernel. And we can develop powerful, high-performance networking capabilities with eBPF, handling network packets within the kernel and avoiding costly transitions to and from user space.

eBPF programming is incredibly powerful, but it’s also complex. For most of us, the utility of eBPF is going to come not from writing programs ourselves but from using tools created by others. There are an increasing number of projects and vendors building on the eBPF platform to create a new generation of tooling, covering observability, security, networking, and more.

Notes

Audience* Software engineers and developers, who are curious about the technology, and want to use it to implement new kernel features quickly, improving the network, observability, and security features of their systems.

Operations engineers who want to understand what eBPF implies, its benefits and risks, and might be hesitant to use existing solutions based on this technology.

Benefits to the Ecosystem* This presentation will help raise awareness of the power of eBPF, which is rapidly changing the landscape of the Linux Ecosystem: Being able to add functionalities into the Kernel through ebpf scripts without needing to wait for the next kernel release or changing the kernel code itself to achieve certain functionality.

^ back to index

61. The High and Lows of Minority Report becoming real

Abstract

Description

Notes

^ back to index