Consultant, Trainer, Writer, Editor of 97 Things Every Programmer Should Know

The Error of Our Ways

What happens when things break? What happens when software fails? We regard it as a normal and personal inconvenience when apps crash or servers become unavailable, but what are the implications beyond the individual user? Is software reliability simply a business decision or does it have economic, social and cultural consequences? What are the moral and practical implications for software developers? And when we talk of 'systems', are we part of the 'system'? What about the bugs on our side of the keyboard? In this talk we will explore examples of failures in software and its application, and how they affect us at different scales, from user to society.

CEO @ Zerocracy, Author of Elegant Objects, Creator of eXtremely Distributed Software Development

How Much Do You Cost?

We all want to make more money, being programmers, senior programmers, architects. How to get more money doing the same amount of work and spending the same amount of time is always a big question. There are a number of key points, which you have to pay attention to if you want to boost your profile as a software engineer and increase your salary or your hourly rate. At the presentation we will go through all of them, illustrated by practical examples and real CVs I’ve been getting over the last five years from over 300 programmers.

CTO @ Codecentric, Fellow, Speaker, Nerd, Consultant

The 7 Quests of Resilient Software Design

Resilient software design is around for some years meanwhile. Still, there seems to be a mismatch between popularity and progress - while patterns and libraries are quite well known for a while, only little progress in terms of creating better robust applications seems to be made. In this session we will examine the probably biggest obstacles and pitfalls on our way towards creating resilient systems. You will learn what they are, how you identify them and what you can do about it. After all, it is still a long way to become a resilient software designer...

Developer Advocate @ Hashicorp, author of Building Microservices in Go

Nomad: Scheduling Applications at Scale

Tools like Docker and rkt make it easier than ever to package and distribute applications. Unfortunately, not all organizations have the luxury of being able to package their applications in a container runtime. Many organizations have virtualized workloads that cannot be easily containerized, such as applications that require full hardware isolation or virtual appliances. On the opposite end of the spectrum, some organizations deploy workloads that are already static binaries such as Go applications or Java applications that only rely on the JVM. These types of applications do not benefit from containerization as they are already self-contained. To address the growing heterogeneity of workloads, HashiCorp created Nomad – a globally aware, distributed scheduler and cluster manager. Nomad is designed to handle many types of workloads, on a variety of operating systems, at massive scale. Nomad empowers developers to specify jobs and tasks using a high-level specification in a plain-text file. Nomad accepts the job specification, parses the information, determines which compatible hosts have available resources, and then automatically manages the placement, healing, and scaling of the application. By placing multiple applications per host, Nomad maximizes resource utilization and dramatically reduces infrastructure costs. The flexibility of Nomad’s design brings the benefits of a scheduled application workflow to organizations with heterogeneous workloads and operating systems. This talk will discuss the pros and cons of running in a scheduled environment and includes a series of live demos to supplement the learning experience.

Lead Application Architect @ Huddle, Founder of the London .NET user group

TDD, Where Did It All Go Wrong

Since Kent Beck wrote the book on TDD in 2002 a lot of words have been dedicated to the subject. But many of them propogated misunderstandings of Kent's original rules so that TDD practice bears little resemblance to Kent's original ideas. Key misunderstandings around what do I test, what is a unit test, and what is the 'public interface' have led to test suites that are brittle, hard to read, and do not support easy refactoring. In this talk we re-discover Kent's original proposition, discover where key misunderstandings occured and look at a better approach to TDD that supports sofware development instead of impeding it. Be prepared from some sacred cows to be slaughtered and fewer but better tests to be written.

Developer Advocate @ Google Cloud Platform, Groovy Language Lead

Machine Intelligence at Google Scale: Vision/Speech

The biggest challenge of Deep Learning technology is the scalability. As long as using single GPU server, you have to wait for hours or days to get the result of your work. This doesn't scale for production service, so you need a Distributed Training on the cloud eventually. Google has been building infrastructure for training the large scale neural network on the cloud for years, and now started to share the technology with external developers. In this session, we will introduce new pre-trained ML services such as Cloud Vision API and Speech API that works without any training. Also, we will look how TensorFlow and Cloud Machine Learning will accelerate custom model training for 10x - 40x with Google's distributed training infrastructure.

Head of Engineering @ WIX

Journey from Monolith to Microservices and DevOps by WIX

Wix.com started the journey toward DevOps and a microservices solution about 5 years ago when we switched from a monolithic application to a microservices-based system—a transition that took two full years to complete, with many lessons learned along the way. Today, Wix successfully operates over 200 microservices on a battle-tested production environment. In this talk, we will cover why Continuous Delivery and DevOps are important requirements for microservices, discuss guidelines for a good microservice architecture, explain why YAGNI and KISS are important and how operational concerns (DevOps) affect the design of a microservices architecture, as well as give some recommendations on the best way to transition from a monolithic to a microservices architecture.

Machine Learning Researcher, PhD @ University of Cambridge, Microsoft MVP

Exploring StackOverflow Data with Machine Learning

When you’re stuck while programming - who you gonna call? StackOverflow! It’s an invaluable source of daily help to many. Interestingly, you can also download the entire data dump of StackOverflow and let machine learning loose on the dataset. In the talk I’ll look at what we can learn from the crowdsourced knowledge of developers worldwide. Meanwhile, you will also learn about ideas behind some machine learning algorithms that can give us insights into complex data - and also how does it all relate to cancer research! I will use a combination of statistical computing language R with functional language F# to show how you can easily access and process large-scale data the functional way.

iOS developer, GraphQL enthusiast & educator

REST in Peace - Modern API Design with GraphQL

GraphQL is riding the hype wave right now. Yet many developers don't understand how they could benefit from it or where it fits into their stack. I'll introduce core concepts and give a practical demo how you can use GraphQL with React & Apollo. I'll also outline major advantages of GraphQL so you can convince your manager and developer friends to use it in your next project.

Software Engineer @ Joyent, ex-Software Engineer @ HashiCorp

An Introduction to Chaos Engineering

Chaos Engineering is methodology that experiments on a distributed system in order to build confidence that the system will work well in production. Essentially, we experiment by trying to break our system to uncover system weakness. In this talk, Paul will cover the basics of Chaos Engineer, give some case studies of companies that currently do this in production and give an introduction to some of the open source tooling that currently exists so that you can maybe try this at your company. Paul will also show that, by following good infrastructure management practices, that you can recover and scale the system when necessary, easily!

Team Leader & Senior Software Engineer @ Allegro Group

Mid-sized Building Blocks & Hexagonal Architecture

Do you know why the default scope in Java is package-private? Because that's what designers thought should be the most popular scope. Is that the scope you most often see? Probably not. Somehow Java devs became crazy communists-capitalists, recognising only private and public access, and preferring public everywhere. And so our projects look like a lawn right after snow melts: full of shit laying in public. Hard to put into your head. Hard to reason about. Entanglement instead of encapsulation. People even register every possible class in an IoC container, because FU (nctional) programming, that's why. You wanna find something in my code? Google it. Or how about inheritance? James Gosling asked in 2001 about what he would do differently if he had a chance to recreate Java, said he would probably remove class inheritance. We are in 2016, having lambdas, defaults on interfaces, AOP and other tricks, but young developers still prefer to just add another abstract class to your code. Gonna be fun navigating those seven layers of hell when you read it. Ok, maybe it's not THAT bad, but it's not much better either. The problem of course, is that we all start with tutorials, which cut corners for brevity. And we don't pay attention to those small problems till they hit us hard. Let's see how we can make our situation a little bit better, using Domain Driven Design, package-private scope, sensible packaging structure, and CQRS on microservices. Because it is actually easier, than not doing it. Real life project examples included.

Software Architect @ Zalando

Scaling Architecture @ Zalando

Zalando introduced Radical Agility last year: an organizational concept which fosters autonomous teams. By building your organization on autonomous teams, you may wonder how architecture works takes place in such an environment - especially with a separate architecture team. Architecture should not become a bottleneck. In this talk I show, how we try to achieve shared understanding regarding architecture across our organization by facilitating architectural principles and forming guilds. You will hear about our most important guidelines, why we have them and which technical challenges arise by them.

Cloud Technology Architect at ThoughtWorks, author of Infrastructure as Code

Implementing Infrastructure as Code

Infrastructure as Code (IaC) is the "A(utomation)" in the DevOps "CALMS" model. It treats dynamic infrastructure as a software system, which means development tools and agile practices like TDD, CI, and CD can be used. Most development and operations teams are making at least some use of IaC tools such as cloud, Chef, Puppet, Ansible, Terraform, etc. But not many are using them to their full potential. This talk explains some of the core challenges of managing infrastructure in a fully automated way, and shares principles and patterns for addressing them. The talk walks through a number of patterns for implementing IaC tools such as AWS, Chef, Puppet, Ansible, and Terraform, to build a change management pipeline to automatically test and apply configuration to infrastructure. The patterns are not tool-specific, so should be useful for any team using these types of tools. Attendees should come away with an understanding of how concepts such as Continuous Integration (CI), Continuous Delivery (CD), Test Driven Development (TDD) can be applied to infrastructure.

DevOps Process Lead & Continuous Delivery Architect @ Dell EMC, author of Elastic Leadership, The Art of Unit Testing

Team Leadership in the Age of Agile

In this talk Roy explores the three maturity stages of a software team, and how a team leader can adjust their leadership type based on the current phase the team is in. Roy explores common mistakes and techniques team leaders can take to make sure their team gets on the road to craftsmanship and maturity in software development.

Software Developer, Trainer @ ‎Bottega IT Minds, DZone's Most-Valuable Blogger

Refactoring to Event-Sourcing – No Slides, Just Code

Tired of fancy abstractions without actual down to earth implementation? In this talk we will go through some benefits of having event-sourced model on a real example. This is full-time live coding and we will start from a simple Spring Boot based OOP application and turn it upside down with events. Basic knowledge about DDD and/or OOP is welcome!

Technical Lead @ Equal Experts, AWS Certified Solutions Architect

Using AWS Lambda and Azure Functions to Develop Serverless Apps

In this session we will look at how you can develop applications using AWS Lambda and Azure Functions, create a deployment pipeline and monitor your applications written on those two platforms. We will go through real examples of how they are used and share the experience of working with the two technologies in production. The talk will be supported with live demos with tips on setting up a continuous deployment pipeline and working with both technologies.

Founder @ mnogosdelal.ru, ex-Head of IT @ Kaspersky Lab, author of Jedi Techniques

Jedi Techniques of Personal Effectiveness

During the last ten years (at least) I was deliberately thinking about what makes us productive, creative and gives us the effectiveness. I came to several counter-intuitive conclusions: – we're often late because we're trying to save time. - we're uncertain about some things, because we have too much information. - we're too slow, because we try to do them faster. During my talk I'm going to illustrate this in more details and show how it can be explained from the point of view of modern cognitive science as well as ancient wisdom. And of course the way to become more productive will be shown.

Member of Technical Staff @ Docker Inc.

Docker Under the Hood

Docker is a platform that helps developers and ops teams to build, ship and run their applications. It's a complex system made up of a number of components, many of which are open-sourced under the Moby Project umbrella. This talk looks in detail at one of these components, LinuxKit, which is an open-source toolkit for building custom, minimal, and immutable Linux distributions. Docker uses LinuxKit to create the minimal host OS (a container OS) which ships as part of the Docker Desktop editions — in active use by developers all over the world. We will go through how LinuxKit is put together and demo how to use it to build your own, customised container OS within minutes — without compromising on security or usability. This talk will also cover announcements made at DockerCon and how LinuxKit enabled those features and integrations.

Consultant, Trainer @ Pluralsight, Microsoft MVP

Web Application Security Risks: A Look at OWASP Top Ten 2017

Since 2003, the Open Web Application Security Project curates a list of the top ten secuity risks for web applications. The 2017 edition of the list proved to be a major challenge. Originally scheduled for 2016, a first release candidate came out in mid-2017, just to be retracted later. If all goes according to (the new) plan, the final version of the list will see the light of day a few days before the conference. What is still relevant in web application security, which attacks are getting rare, and which new threats are coming up on the horizon? Attend this session to find out!

Software Craftsman and Founder @ Codurance, author of The Software Craftsman

The Long Road

Choosing the next career step in such a diverse and fast-paced industry is not an easy task. But when it comes to our careers, there is no right or wrong. Or there is? How do we know? In this talk we will be talking about different career choices, how can we choose good companies to work for, what we can learn from interviews and selection processes, when should we look for a new job, and how to change our working environment.