ACCU 2015 Sessions

Conference 2015

A Revolutionary Programming Pattern that Will Clean up your Code: Coroutines in C++

tutorial: 90 minutes
In this talk, I will present a number of difficult problems that often result in convoluted state machines which are difficult to maintain and to test. Among these problems are complex syntax parsers and messaging protocol implementations.

I will explain what coroutines are and how they can be applied to each these problems. We will review generators and async operations in C# and give an overview of coroutines in the Boost library for C++. The session will be accompanied by samples for each concept presented.


Detailed Description:

Presenting Two Problems (15 minutes)
The first problem I will present involves a parser which pulls data from a file. What happens when the data cannot be pulled from the source but rather is pushed by the source? Typical solutions include: rewrite the parser as a state machine, or run the parser in a thread with a queue of data between the producer and the consumer. The first solution inverts the parser logic and makes it difficult to follow and therefore difficult to maintain. The second solution is wasteful in system resources and incurs the overhead of context switching between threads.

The second problem I will present is that of implementing business logic that is combined with asynchronous operations (for instance, asynchronous I/O). A common pattern is to handle the logic in the completion routines of the asynchronous operations. Like the rewrite of the parser, this forces the programmer to adapt the business logic to a state machine, making it difficult to read and difficult to maintain.

Introducing Coroutines (15 minutes)
I will give an overview of the concept and cover including symmetric and asymmetric coroutines. I will also talk about fibers and the difference between fibers and threads, and generators. A demo in C# of generators and the async pattern will conclude the introduction.

Coroutines in C++ (20 minutes)
After explaining how coroutines can be applied to the two problems I introduced, we will dive into the boost classes that support coroutines in C++. This overview will begin with a reminder of Lambda Expressions in C++ and closures. Then I will present the relevant libraries and their relationship with each other: Boost.Context, Boost.Coroutines, Boost.Asio. In particular I will present the io_service class and how it helps managing coroutines.

Applying Coroutines to our Two Problems (15)
In this part we will apply coroutines to each of the problems introduced at the beginning. I will demonstrate two alternative approaches for each problem.

Concluding Notes (15 minutes)
Before concluding, I will address two important considerations when using coroutines. Speed and robustness. We will demonstrate that boost's context switching is very fast, that exceptions are handled safely and that stack unwinding works reliably. In conclusion we will compare and admire the cleanliness and readability of the coroutine solution compared with the legacy solutions.

Questions and Answers (10 minutes)

ACCU

workshop: 90 minutes
This is by way of a request on behalf of the ACCU Committee, for the allocation of a 90 minute session, preferably on the Friday. Tentatively I would like to split it into two and have one session on discussing the suggestion put forward by then for the future of ACCU and one on writing for the ACCU magazines.

Exact details and the best way to do the timesplit I'm still working on, but if there was at least one other track that was doing 15 min sessions at the same time, it would mean that there were other session to go to for people who just wanted to attend only only one part of the split session.

All unicorns were once horses (and some were donkeys before that)

presentation: 15 minutes
One of the most widely held beliefs about DevOps is that it applies “only for startups and unicorns”. We think of all the success stories from Google, Amazon, Etsy, and Flickr and conclude that all the best-in-class companies were born as “unicorns”, with DevOps in their DNA. However, when we look at the paths these companies have forged a different story emerges. A story of ambition, commitment, and determination to overcome real and difficult barriers in technology and culture. The truth is that all unicorns were once horses - and some were donkeys before that. This presentation will bust common myths about Continuous Delivery and look at what it takes to transform a donkey to a market-leading unicorn.

Archipelagos in Git

presentation: 15 minutes
Island: Any piece of subcontinental land that is surrounded by water.
Archipelago: Island chain, is a chain, cluster or collection of islands.

Assumptions:

  • Reviewing code is a worthwhile activity
  • No one wants to review and/or merge code as their fulltime job
  • No one person should bear all that responsibility anyway
  • Existing, nonconceptual approaches to the problem of managing the movement of code are quite weak
  • Communication is always required and goes a long way to solving many of our problems, but we can't all communicate with everyone all the time on a medium large team
  • Metaphors help understand intent
  • Sometimes code will need to be shared between teams; it isn't always possible to divide up work by features (although appropriate interfaces help with this)

Basics:

  1. An 'Island' is considered to be synonymous with a fork/branch or fork/set of branches
  2. An archipelago is identifiable as a number of islands which are “close” to one another
  • Created as a concept to help medium to large teams manage sharing of code between areas of related work and to ease merge pain
  • Merging is always difficult; it's a difficult job. Archipelagos don't solve merge problems, but they do simplify them and provide conceptual assistance
  • Islands in an archipelago are related to one another purely by virtue of their proximity to one an another. If a fork/branch is close to another, it makes sense to consider it part of the same archipelago
  • Pull requesting to the owner of the archipelago simplifies the merge you're dealing with and still allows everyone interested in that archipelago to be party to what's going into it
  • Pull requesting the entire archipelago to “wherever the release is going to be made from” helps collate like­ areas of work for reviewing purposes

Advanced

  • Archipelagos can be near or far away from each other ­ sometimes they will want to merge between each other, but this is not particularly desirable unless you combine
  • How do we know when to create an archipelago?
  • Feature files / executable specification, where does it fit in?
  • Realisations from actual use with several teams totalling 20+ developers


Asynchronous Operations

tutorial: 90 minutes
Doing many things concurrently is often necessary when dealing with high throughput systems. Using one thread fear each work item generally doesn't work too well as threads require substantial resources. On systems where work items frequently need to wait for completion of other operations, e.g., for input to bcome available scheduling operations asynchronously provides a scalable approach. This presentation demonstrates uses of components proposed to be included into C++ standard (ASIO, corroutines) to provide concurrent processing without [much] use of threads. Although some programming approaches need to be adjusted when using an asynchronous formulation the code can stay reasonably simple to follow.

For a future version of C++ different approaches to deal with concurrency are discussed. This presentation shows the different approaches under discussion which are useful for asynchronous processing, primarily implementations of coroutines and executors. The presentation shows how these facilities can be used in the context of the ASIO implementation for addressing networking. The different approaches are not, yet, part of the C++ standard but whatever concrete approaches will be used they are bound to be fairly similar to those under currently under discussion.

Atomic Counters or A Lesson on Performance and Hardware Concurrency

tutorial: 90 minutes
If atomic<int> is good enough for you as a shared counter, then this session is not for you. However, if you're concerned about performance and scalability of parallel tasks that use shared objects, this session will explore the performance and scalability issues of atomic<T> and possible solutions to overcome these issues.

Intended audience: This talk is for programmers and designers who care about performance scalability in a parallel world. Though examples will be in C++, the issues and solutions apply to other programming languages as well.

BDD By Example

workshop: 360 minutes
In this workshop, Seb will provide a practical introduction to using examples to specify software. You will learn to break down complex business requirements with your stakeholders, using examples in their own language, giving you the tools you need to explore their ideas before you even write any software.

This workshop is for everybody involved in the process of developing software, so please bring product owners, testers and architects along. As well as describing what BDD is (and isn't), we'll spend a lot of time practicing collaborative analysis to make sure that our stories are appropriately sized, easy to read and unambiguous. We'll develop a 'ubiquitous language', explore the workings of the Three-Amigos meeting, and really get to grips with the slippery interaction between features, stories, acceptance criteria and examples.

Before the day is over, we'll also take time to discuss:

  • How BDD relates to SBE, ATDD and TDD
  • Approaches to the cost/benefit trade-off of test automation
  • Where BDD fits into your existing development process
  • The benefits of 'living documentation'


We'll use pens, cards and other bits of paper, so you won't need to know any tools in advance, or even remember your laptop!

Becoming a Better Programmer

keynote: 60 minutes
You've come this conference to improve your skills. You're here to learn: to learn new technologies, to learn new techniques, and to fuel your passion by meeting like-minded people.

Becoming a better programmer means more than just learning new technologies. It means more than practising techniques and idioms. It's about more than passion and attitude. It's the combination of all these things. That's what this session will look at.

Pete Goodliffe, author of the new book Becoming a Better Programmer, unpacks important mindsets and techniques that will help you improve as a programmer.

You'll discover specific tools that will help you review your current skillset, and you'll learn techniques to help you “become a better programmer”.

Bootstrapping a BDD framework

experience report: 15 minutes
We all know from Kent Beck that the best way to learn a new language is to implement a test framework with TDD using the framework we're just implementing.

When I wanted to learn some Go I decided to implement a so called wire server in Go for the cucumber BDD framework. The acceptance tests of the wire server are being implemented by using cucumber with the wire server itself.

I will present how I started the BDD and TDD cycles and what was involved in bootstrapping the development. I will talk about the experiences I made and how my decisions influenced the BDD and TDD cycles for the better or the worse.

There will also be a short introduction into the ecosystem of the project, including free hosted and public accessible continous integration etc.

Bootstrapping Boost.Test using a macro DSL

case study: 15 minutes
When we start writing a test, it's useful if the testing framework can initially help us in separating our Arrange, Action and Assert steps. This session will look at how we can extend the Boost unit test framework to provide both Spec- and Behaviour-style DSLs with a handful of simple macros and a logging extension.

Braindump - How to leave your Knowledge when leaving your Job

case study: 15 minutes
There comes a time in every employee's career when they consider moving on. How can you make sure that the knowledge that you've accumulated in your job is not lost? This short talk offers some thoughts and concrete tips.


Building Learning into Team Life

workshop: 90 minutes
When we make time and space for learning within teams, the products and services we build benefit from new ideas and innovative solutions. Team members also tend to find work more satisfying and enjoyable, which helps company recruitment and staff retention. Many us struggle when it comes to practical ways to encourage people to keep learning at work. It can help to build in time for learning, exploration and discovery into team/organization process but how can you get started? Perhaps more challenging, how can you keep learning initiatives going without taking on the admin yourself?

Come to this workshop to hear some practical ideas of how you can get learning built into your team process. We'll talk about a variety initiatives including: Lightning Talks, Tech Academy for new starters, Coding Dojos, Conference Club and Gold Cards for research.

C++: Easier, Faster, Safer

keynote: 60 minutes
Over the past five years, the prospect of developing large software projects in C++ has changed dramatically. We have had not one but two new language standards. An amazing array of new features are available today that make the language more elegant, expressive, and easy to use. But that isn't the only change in the last five years. LLVM and Clang have helped kick start a new ecosystem of tools that make developing C++ easier, faster, and safer than ever before.

This talk will cover practical ways you can use the tools we have built in the LLVM and Clang projects. It will show you what problems they solve and why those problems matter. It will also help teach you the most effective ways we have found to use all of these tools in conjunction with modern C++ coding patterns and practices. In short, it will show you how to make *your* C++ development experience easier, faster, and safer.

Clean Coders Hate What Happens To Your Code When You Use These Enterprise Programming Tricks

case study: 15 minutes
It is all to easy to dismiss problematic codebases on some nebulous idea of bad practice or bad programmers. Poor code, however, is rarely arbitrary and random in its structure or formulation. Systems of code, well or poorly structured, emerge from systems of practice, whether effective or ineffective. To improve code quality, it makes more sense to pick apart the specific practices and see their interplay - the cause - than to simply focus on the code itself - the effect. This talk looks at how a handful of coding habits, design practices and assumptions can systematically balloon code and compound its accidental complexity.

Coding Without Words

presentation: 90 minutes
C++11 added some new facilities, for example lambdas and tuple, that let you program without needing to name things.

I'll take a look at both of these, starting out by an overview of what the offer and then focussing on the strengths and weakenesses of using facilities like these.

In what ways are they 'better' or 'worse' then the alternative ways of solving the problem (and What are the alternatives anyway).

The talk will require knowledge of C++ but I'll try to make sure the new features are explained briefly for those who are not familiar with them.

Compile-time Computations in C++14

tutorial: 90 minutes
While in the past C++ provided compile-time computation only very clumsily using templates with value parameters, C++11 introduced the constexpr keyword and allows functions and constants to be computed at compile time. It even introduced a new category of types 'Literal Types' that can be used in such compile-time computations. C++14 further relaxed the restrictions on constexpr functions to allow all reasonable statements that make sense at compile time. As long as at compile-time the computation path of a function remains within these limitations regular C++ can be used in constexpr function. However, when exploring/exploiting the compile-time computation features, one will recognize there are limitations and compile-time impacts can be really severe.

The tutorial covers many kinds of compile-time computations available in C++14, from constexpr functions and constants, literal types, variable templates, up to variadic templates using std::integer_sequence for string processing. It also gives a glimpse of the potential future standardized features, like user-defined-literal template operators for string literals. The tutorial also shows, where C++14 still has limitations in supporting compile-time computations and what you might need to do, to sidestep them.

Writing concurrent programs using Test Driven Design on a Human Computer

workshop: 90 minutes
Parallel Human Computer

Session objectives:
Understand concurrent systems problems and solutions. Learn how you can apply Test Driven Design to concurrent code. Experience how a parallel computer works and is programmed. Discover how simple rules and collaboration can solve complicated problems Intended audience and prerequisites This session is relevant to developers, testers and architects and everybody who's interested in organisation, communication, emergent behaviour, solving puzzles, simulations, acting and playing. No programming experience required.

Short description:
Being able to work on concurrent problems and systems is becoming mandatory for everyone in IT. But it looks insanely hard and our familiar tools (like TDD) don't seem to work.

Come and play part of our Parallel Human Computer. We'll “program” (teach) you using TDD. Once programmed, you'll solve a complicated puzzle easily by collaborating with the other participants “inside” the computer.

You'll see that it's not so hard and really good fun! And maybe you'll start to think differently about systems.

No computers or programming experience required!

Format:
90 minutes experiential learning session

Long description:
The world around us is concurrent: lots of things happen at the same time all the time. We need to be able to work with concurrent systems to correctly understand and model the world, to create high-performance and scalable systems, to create responsive applications or to make good use of our increasingly multi-core computers. And it's a useful technique to design teams and organisations around simple rules, communication and collaboration.

But, surely, writing concurrent programs using Test Driven Design is inconceivable, because:

It's insanely hard, only accessible to genius uber-nerds
You can only do it well with exotic and esoteric programming languages
You can't unit test concurrent programs
A fortiori, you can't apply Test-Driven Design (TDD) on concurrent applications
It's painstaking and boring work
Normal people like me can't understand it
On the contrary! It's easy and fun. You don’t even have to know anything about programming to play a part in our “Communicating Smart People” simulation!

Our company “Communicating Smart People” (CSP inc) has just created a Parallel Human Computer to solve puzzles. We'd like for you to become one of the parts of this computer. We will use Test Driven Design to teach you how to perform simple tasks and how to communicate with the other players inside the computer.

By the end of the session you'll have solved a complicated puzzle, by each working on a small and simple part of the problem.

After the simulation, we'll explain what you experienced with some simple theory and tools you can apply immediately.

You don't need programming experience or a computer. We just need a few people who want to play and learn.

Deploying your applications with Docker

tutorial: 90 minutes
Docker [1] is an open platform for developers and sysadmins to build, ship, and run distributed applications. Apps can be quickly assembled from components, and the same images can be used by development, QA, and production environments. You can ship faster and run the same app, unchanged, on laptops, data center VMs, and any cloud, eliminating differences between dev and prod. Because of the layered file system used by Docker images, new containers can be booted and brought into service in seconds rather than hours or minutes.

With backing from a wide range of companies from Google to Microsoft and a host of others, Docker is seeing fast and enthusiast adoption as developers and admins are excited about the prospect of repeatable reliable deployment of code from development into production. Originally based on Linux LXC container technology, Microsoft have recently announced partnership to bring Docker to Windows Server [2].

In this session, we'll take Docker for a spin, building an app and creating a Docker image that can be run both locally, and unmodified on a VM or cloud server. We'll learn about the Docker architecture and runtime, how to take advantage of public images at the Docker Hub, and how to run your own private Docker registry. We'll also learn some of the things you need to know to run Docker systems in production, including image management, storage, networking, logging, and service discovery.

[1] https://www.docker.com
[2] http://azure.microsoft.com/blog/2014/10/15/new-windows-server-containers-and-azure-support-for-docker/

Design For Testability: What, Why and How

tutorial: 90 minutes
'To be tested a system has to be designed to be tested' Eberhardt Rechtin, 'The Art Of System Architecting'

Testing is one of the main activities through which we gather data to assess the quality of our software; this makes testability an important attribute of software - not only for development, but also for maintenance and bug fixing.

Design for testability is a term that has its origin in hardware design, where the concept was introduced in order to make it easier testing circuits while reducing the costs of doing so. In this talk I'll show how to translate this concept to the software domain along with the consequences on various aspects of the development activities, both from the technical point of view (e.g., design, code quality, choice of frameworks, etc.), and the product management point of view (e.g., management of team dependencies, delivery time, costs, etc.). I'll provide examples based on real world experience, both for the technical and the management aspects.

Details Matter

tutorial: 90 minutes
When writing a library for general consumption, even the smallest details start to matter, if you do not want to surprise a user with some unexpected behavior.

Alisdair Meredith will share some of the lesser known corners and details of the language that can affect library design, or implementation. In particular, many implementation details risk exposure when writing generic code (templates) which happens to be most of the standard library.

Other topics include why it is important that a type thrown as an exception never throws from its copy constructor, the reference-counted string type hidden in the standard library, and why these two topics are more related than might first appear!

Efficiency with Algorithms, Performance with Data Structures

presentation: 90 minutes
Why do you write C++ code? There is a good chance it is in part because of concerns about the performance of your software. Whether they stem from needing to run on every smaller mobile devices, squeezing the last few effects into video game, or because every watt of power in your data center costs too much, C++ programmers throughout the industry have an insatiable desire for writing high performance code.

Unfortunately, even with C++, this can be really challenging. Over the past twenty years processors, memory, software libraries, and even compilers have radically changed what makes C++ code fast. Even measuring the performance of your code can be a daunting task. This talk will dig into how modern processors work, what makes them fast, and how to exploit them effectively with modern C++ code. It will teach you how modern C++ optimizers see your code today, and how that is likely to change in the coming years. It will teach you how to reason better about the performance of your code, and how to write your code so that it performs better. You will even learn some tricks about how to measure the performance of your code.

Embedded Programming Death Match: C vs. C++

case study: 90 minutes
C offers various ways to represent and manipulate hardware devices. C++ offers additional object-oriented techniques that provide higher levels of abstraction. Many C programmers assert that using C++ objects for hardware accesses is too costly, yet they can offer no measurements to back that claim. This session explains how to actually measure such claims. It also presents results from some measurements that show, at least for ARM processors, that some widely-used C techniques are actually slower than straightforward C++ techniques.

Evolving Software: A Fusion of the Developer and Evolutionary Algorithms

workshop: 90 minutes
The agile principle of iterative software development to deliver working software frequently is well understood and widely practiced. Indeed, the practice of iterative software development has led to the notion of software evolving over its lifetime, wherein software must respond to change and continually adapt and grow. But what if software evolution could itself be performed in software? Well, it turns out that computational evolutionary algorithms have a long and distinguished history, and include such approaches as Genetic Algorithms (GAs) and Genetic Programming (GP). This interactive workshop explains the approach of evolutionary algorithms, and explores the role of the human designer in this evolution, taking software designs as an illustrative example.

The workshop begins with an overview of how natural evolution inspires evolutionary algorithms. For example, the 'survival of the fittest' in nature inspires the use of fitness measures to select candidate design solutions with advantageous genes for reproduction into the next generation.

The workshop then forms small breakout groups to consider what fitness measures might be useful in the selection of candidate software designs in evolutionary algorithms. Findings are shared and discussed around the workshop.

Next, the role of the human designer is explored. After all, software is not sentient and so cannot provide the creative design insights in the same way that experienced developers can. Thus the purpose of evolutionary algorithms is not to totally automate development, replacing the human programmer. Rather, by emulating the evolution, a fusion of human qualitative evaluation of candidates ('the survival of the fittest') and the evolutionary algorithm is achieved.

For a second time, building on the ideas discussed, participants form into small breakout groups and explore ways in which the fusion of human developers and evolutionary algorithms can effectively be exploited in software development. Again, findings are shared and discussed around the workshop.

Finally, the case study offers some signposts to readily available evolutionary algorithm frameworks for developers to take away and hence advance and improve their design and development skills.

Fizzbuzzalooza

talk: 90 minutes
Fizz Buzz. It's a drinking game. It's an educational game to teach kids division. It's an interview question. It's a coding kata. It's all these things. And it can be fun. It can also be used to illustrate different coding paradigms, languages and techniques, from the serious to the jocoserious to the you-cannot-be-serious. This talk uses this simple problem to take you on a bazaar and bizarre tour, from plain examples to provocative examples in common and less common languages, sequential to concurrent, procedural to functional, elegant to ridiculous.

From Cluster Zero to a Quantum Universe

presentation: 90 minutes
In 1979 I started on the design of a cluster of 100000 stars located in a volume of space of a million cubic light years. The density of stars was high at the centre and low at the edge of the cluster. Stars were not uniform nor located at fixed grid points. I implemented phase 1 of the design on a z80 based machine with 32K of RAM. I also implemented a 'spaceship' that flew through this cluster displaying the view.

More recently many games only generate objects when a player observes them. For example rewards for success are often provided as 'presents' whose contents are not determined until the player opens them.

In this talk I will outline the ways that rules can be used to generate repeatable but unpredictable data at the point of use. The size and apparent complexity of a simulated universe is not constrained by the available space for data storage. There are some surprising implications including the possibility that the audience includes NPCs (non-player characters).

Getting started with jQuery and how it works together with ASP.NET WebForms and MVC

presentation: 90 minutes
jQuery is the new favorite of web developers. This lightweight JavaScript library makes developers love writing JavaScript code again! What needed 20 lines of code first is now reduced to 3 lines. Who wouldn't be enthusiastic?! Microsoft showed its love for the library by fully integrating it in Visual Studio. I dare to ask: Should you stay behind? In this session, we'll take a look at jQuery and we'll teach you what you need to know to get on your way. More specifically, we'll look at selectors, attributes, working with WCF, jQuery UI and much more. You may walk out of this session wearing a sticker: 'I love jQuery'!

Hands on Machine Learning

workshop: 360 minutes
A hands on exploration of machine learning algorithms, starting with raw real world data sets and ending with working classification tools. If there's enough interest, we can work on one or more problems suggested by participants, otherwise we can work through some publicly available datasets.

Will require laptop and some knowledge of Python (and ideally numpy)

Hardening your code: Techniques to boost confidence in your code.

tutorial: 90 minutes
Are you worried that your code has a lot of undiscovered bugs? How can you be more confident that your code is reliable? In this session, I will talk about techniques and tools that you can use to reduce the number of bugs/defects in your code base. Code examples will be in C++ and the tools will be C/C++ specific, but many of the techniques apply to other languages as well.

This is an updated version of my talk from CppCon 2014 https://www.youtube.com/watch?v=cg7uFBmUh_Q
Tags: C++, tools, Techniques, Source control, testing
Level: Beginner/Intermediate

History and Spirit of C and C++

tutorial: 90 minutes
To get a deep understanding of C and C++, it is useful to know the history of these wonderful programming languages. It is perhaps even more important to appreciate the driving forces, motivation and the spirit that has shaped these languages into what we have today.

In the first half of this talk we go back to the early days of programmable digital computers. We will take a brief look at really old machine code, assembler, Fortran, IAL, Algol 60 and CPL, before we discuss the motivations behind BCPL, B and then early C. We will also discuss influential hardware architectures represented by EDSAC, Atlas, PDP-7, PDP-11 and Interdata 8/32. From there we quickly move through the newer language versions such as K&R C, C89, C99 and C11.

In the second half we backtrack into the history again, now including Simula, Algol 68, Ada, ML, Clu into the equation. We will discuss the motivation for creating C++, and with live coding we will demonstrate by example how it has evolved from the rather primitive “C with Classes” into a supermodern and capable programming language as we now have with C++11/14 and soon with C++17.

How to diffuse your way out of a paper bag

tutorial: 90 minutes
Many applications in variety of areas from finance to epidemiology use Monte Carlo simulations of stochastic models. This talk will revise the basics of Monte Carlo models, and consider when they are appropriate. In particular, it will demonstrate standard and geometric Brownian motion, showing various approaches to diffusing one's way out of a paper bag. Programming one's way out of a paper bag gives a concrete, if frivolous, application to otherwise potentially abstract concepts.

This talk will (hopefully) show animations in C++ and avoid too much detailed mathematics. It will build up from a very simple model, considering possible extensions to more complicated approaches on the way. People with a deep background in Monte Carlo simulations, e.g. in low discrepancy numbers, may be bored. The aim is to give a simple introduction to the topic. A brief mention of std::rand and std::random may be made.

How to Merge

tutorial: 90 minutes
As we benefit from the increased flexibility and power of source control tools, we find branching cheap and easy.

But having more branches means that we need to merge more often and now we are faced with the prospect of resolving merge conflicts on a more frequent basis.

Some developers, even those very experienced with a single window of code, seem to lose their nerve when faced with side-by-side diffs, 3-way merges and other complex visualisations of a 'simple' merge. The session aims to explore best practices for merging.

  • What to merge and when
  • Who should be merging
  • What an ideal merge should achieve
  • Conflict markers - the manual merge
  • Using a merge tool - the assisted merge
  • Breaking the rules - when a merge isn't intended to retain all changes for all sides

We will be using Git for our examples but much of the information will be applicable to other source control systems, even legacy centralised systems.

How to name things - the hardest problem in programming

tutorial: 90 minutes
Developers can get better at their craft by learning from the great writers who mastered theirs. Writing software isn't the same as writing a novel, but there are parallels. Besides, advice from writers is better because writers have been struggling with their craft for many centuries, not just a few decades. It's better-written as well. This talk shares great writers' best advice for coders: Stephen King on refactoring, Anne Rice on development hardware, Hemingway on modelling with personas, and Neil Gaiman on everything.

This session first explores the similarities between writing and coding, and uses writers' advice to identify different kinds of avoidable bad naming in code. Some class, method, and variable names are so bad that they're funny, but you've still seen them in production code. The second part of the session explores practical techniques for working on better naming, including renaming things. Renaming is even harder because it includes naming things plus other hard things. The final section goes back to writing. The next step after finding better names in code is to write better comments in code, which is almost as hard as naming is.

The surprising thing about naming things well in code is not that it's hard, but how easy it is to accept bad names. This is a hard problem that's worth working on, because although you can't make the naming problem go away, you can learn to write much better code regardless of which technologies you use.

http://hilton.org.uk/presentations/naming

How we test software at Unity Technologies

case study: 90 minutes
We are making a cross platform game engine used by millions of game developers worldwide. The engine supports 16 platforms and on each one of them it should work like a charm. This talk is about the tools, practices and processes that we are using to deliver top quality game engine to the market.

The purpose of this talk is to share our experience with everyone who is interested.

In the Toolbox - Live!

tutorial: 90 minutes
As a general rule we should strive to use the right tool for the job. If you find yourself installing an IDE on a production server just to search your log files for a particular piece of text, then you've probably chosen the wrong tool.

The modern IDE can be an excellent tool for day-to-day developer duties, but we do not solely write code; we also have to do analysis, testing, support, etc. For these we should be looking at more focused tools, and occasionally we may need to build our own.

Sometimes the right tool is not readily accessible and we have to weigh up whether (ab) using the wrong tool may in fact be the more efficient choice.

This session takes a look at a variety of both command-line and GUI tools that have proved to be useful to the speaker time-and-time again. Most of the examples will come from the areas of build automation, testing and support with a few wildcards thrown in for good measure. Text editors will not be discussed for obvious reasons.

Readers already familiar with the C Vu column 'In the Toolbox' should find familiarity in the subject matter without an overwhelming sense of deja vu.

Investing Upstream: The secret to smooth Scrum Sprints with effective Product Ownership

tutorial: 90 minutes
It's great when teams reach delivery maturity with execution at speed and high quality. It's no surprise that there's so much emphasis on doing Sprints well because that's the heart of Scrum.

Paradoxically though, the secret to making it work well is actually investing time and effort upstream of Sprints to ensure that the Product Backlog is prioritised and broken-down into small items, that User Stories are well formed and that the Scrum team doesn't meet items for the first time during Sprint Planning.

This ties in with solving the very difficult challenge of effective Product Ownership. Often the very people most valuable to the Scrum team are also the most valuable to the wider business, creating a conflict over their time. Many teams struggle with an absent Product Owner or one who is not sufficiently senior to make quick decisions.

The Scrum Guide says little about how to implement effective Product Ownership and how to get the Product Backlog into good shape. Most Scrum training focuses on the Sprints, so also misses this bigger picture.

Join us on our journey through a series of examples anchored in practical experience as we explore a range of tools and approaches to solve these problems. We'll learn how to make Scrum function well in a way that meets both the Scrum team and Product Owner's needs.

Just Keep Shipping

case study: 90 minutes
Launching is no longer the end goal, it's just the beginning.

The adoption of the internet, mobile devices, and digital software delivery are becoming ubiquitous.

Software companies all over the world are shifting to a model where software is a service, not a product.

There is a customer expectation that the value of the product will improve over time without any effort on their part. Your competitors applications update to have the all latest features automatically in background. Do yours?

Keeping a service running successfully means juggling a variety of often conflicting demands.

Your customers expect you to tell them whats coming, and deliver on that promise.

You need to be able to react quickly to unexpected opportunities.

You need to be able to fix problems as soon as they are found.

You need to be able to do all this, continuously, without burning out your team. You don't get to crunch then take a two week holiday anymore, because your next update is next week.

How?

In this no-holds-barred talk, Thaddaeus will share some of the lessons learnt by the CSR team in balancing these requirements. Whether they are planning for a first release, or already working on updates, the audience should come away with a better understanding of what it takes to keep a product live, without losing all their customers or hair.

Kill the mutant - exterminate bugs

tutorial: 15 minutes
Mutation testing has been around for years, but it's only recently that performant tools (such as PITest for Java) have become available. I'll cover what it is, why it's useful and how it relates to coverage. By the end you'll understand how killing mutants can help you deliver better code.

Large-Scale Scientific C++ For Casual Coders: Why You (Should) Care

keynote: 60 minutes
This keynote will introduce the use of C++ for storing and analyzing petabytes of C++ objects at CERN, and more generally in High Energy Physics. Many hundreds of developers, including physicists with limited software skills, have contributed to a code base of > 50 million lines of code that has a lifetime of more than 40 years. Axel will talk about the approach taken in order to provide robust and efficient code, including how novices 'conquer' giant interface worlds. He will present a few of the 'tasty' projects that have proven to be useful for people who don't smash particles on a daily basis, for instance their C++ interpreter and a massively scalable web-based file system.

Learn from the mistakes of others…

keynote: 60 minutes
. . . you won't live long enough to make all of them yourself.

Having worked in a wide variety of fields (and some buildings), including embedded software, helicopter aviation, technical theatrical production, education, and (building) construction and maintenance, Alison still finds it amazing that very different people in wildly different areas often fall into very similar pit traps.

In this talk, Alison will be examining some less-than-stellar occurrences in non-software fields and drawing out some ideas that will hopefully make software development a little less painful. Join her for a light-hearted point-and-laugh session, and learn some fun facts about random stuff.

Less is more - an introduction to low-fidelity approaches

tutorial: 90 minutes
This session will demonstrate some key techniques that help decompose large problems.

Decomposing problems is a key skill that all software developers need, but we're often not very good at it. Whether it's stories that take longer than an iteration, or features that can't be delivered in the expected release, we've all seen the problems that tackling an over-large problem can cause.

We'll work through two detailed examples to demonstrate the value of delivering small, low-fidelity pieces of work early rather than prematurely focusing on fully-polished final versions. One example will walk through development at the implementation level using TDD, while the second will work through an epic, taking it down to stories that can be implemented in one or two days.

By the end of this session, you'll see that small IS beautiful, and understand just how small, small can really be.

Lessons From Closure

tutorial: 90 minutes
The SOLID design principles have been around for quite a while. Most developers have heard of them and many use them as guidance for their work. What few realize, however, is that the two most important principles: Single Responsibility and Open/Closed can be detected and measured using historical data from source code repositories. In this tutorial, Michael will present data from several projects and show how various patterns in code thwart closure and how change coincidence can be used use to identify and untangle nascent responsibilities.

Lessons from the OuLiPo

investigation: 90 minutes
The OuLiPo is a literary collective of mathematicians and writers whose interest is in applying algorithmic constraints to works of fiction. A simple example is the lipogram, a text which avoids any use of a particular letter. A more sophisticated example is Richard Beard's novel 'Damascus' in which the action occurs during a single day, and where every noun used in the book can be found in the Times newspaper published on that day.

It's no coincidence that the OuLiPo's origins overlap with those of the electronic computer. Early computers proved capable of cracking puzzles which had long eluded mathematicians: for example, in 1959 a program running on an UNIVAC 1206 discovered a Graeco-Latin square of order 10, a construct Euler had conjectured impossible some 200 years earlier. The OuLiPian writer Georges Perec combined this square with a knight's tour of a 10 by 10 chess board to create the algorithm which powers the book Donald Knuth considers perhaps the greatest 20th century novel, 'Life A User's Manual'.

As software developers we too form a collective whose members are both writers and mathematicians. This talk will discuss the OuLiPo in more depth, investigating some remarkable parallels between their work and our own, and will consider what lessons we can learn from them.

Making a cross-platform game from scratch with Unity game engine

workshop: 360 minutes
Every programmer once had a dream of making a game. At this workshop the dream will come true. Using a free edition of Unity game engine, we'll create a fully functional game and will deploy it to web or mobile device.

Each attendee will be given a project containing everything needed to create a game. Workshop is split into modules. Each module covers certain area of game development and contains excercises. Be completing the modules attendees will create important game assets. Finally using these assets we'll assemble the game.

Audience: Beginners

Learning points:

  • Unity basics
  • Animation
  • Physics
  • AI (basic)
  • Game UI
  • Scripting
  • Professional tips and tricks

Requirements:

  • Basic C# or JavaScript
  • Unity installed on a laptop


Making the Case for Review

talk: 90 minutes
Software development is a young (some would say immature) profession, and a lot of what we do as software developers is guided by anecdotes, intuition, and received wisdom. The topic of reviews, however, is a bit different, and we've actually got a substantial body of research that tells us something important: reviews improve quality, reduce delivery time, and save money without slowing development teams down. Given what we know about the efficacy of reviews, it would be surprising to still find development organizations today that don't use them. Yet we do. In this talk I'll present some of what we know about reviews. We'll look at questions like:

  • How long should a review be?
  • What kinds of artifacts can be usefully reviewed?
  • How is the time spent in reviews accounted for in terms of quality or ROI?

Some of the answers to these questions can be very eye-opening!

Along with the 'harder' economic and software-oriented benefits of reviews, I'll also spend some time looking at some of the social and team-oriented improvements they can provide. All of these elements build upon one another, of course, so it's useful to have high-level or holistic sense of what reviews can do for your organization.

Ultimately, my goal is to convince you that reviews probably should be part of your everyday development practices and to help you find the best ways to use them.

Mock objects in functional testing

tutorial and case-study: 90 minutes
Mock objects are great. They simplify testing enormously and are crucial for unit testing. There are many mocking frameworks available for many languages. But most of them are designed only for unit testing. Don't you wish you could use them in functional testing where the system under test, instead of being controlled from the test code, executes in its production-like environment and interacts with other systems in other processes or other servers? You want to test that the configuration for your service/program/whatever-you-call-it is correct and actually communicates via network, message queues etc.

This talk describes how to use some tools available and methods for creating your own framework for letting your system under test communicate with endpoints that mimic an external system that is accessed through different inter-process methods.

These methods are particularly useful in service-oriented-architectures where a component executes in its own process or JVM. We need a test environment that is close to the production environment which unit tests cannot provide but is lighter than the full system test environment and can be executed during development time like unit tests.

The talk draws from the authors experience in the Java world but the methods are general and can be used in an environment.

Modernizing Legacy C++

presentation: 90 minutes
C++ is a programming language with a long, storied history spanning over three decades - four if one includes its C ancestry. The C++ language has undergone many changes during that time, compiler technology has advanced substantially, and computers today are very different from the computers of decades past. But despite all of these advances, there's an awful lot of C++ code in use today that looks like it was written in the 1980s. In some cases, the code was written in the 1980s and it's still in use; in other cases, it's recently-written code that just doesn't use modern style.

In this talk, we'll discuss some of the problems with legacy code, and review some practical techniques for applying principles of modern C++ to gradually improve the quality of legacy code and improve maintainability and debuggability. We'll show how some very small changes to code can yield huge benefits.

'New' Features of C

tutorial: 90 minutes
The first international standard for the C programming language was C90. Since then, two newer standards have been published, C99 and C11. C99 introduced a significant number of new features. C11 introduced a few more, some of which have been available in compilers for some time. Curiously, many of these added features don't seem to have caught on. Many C programmers still program in C90.

This session explains many of these 'new' features, including declarations in for-statements, extended integer types, compound literals, designated initializers, restricted pointers, anonymous structures and unions, alignment support, and static assertions.

NoEstimates does not mean 'no estimates'

tutorial: 90 minutes
The #NoEstimates hashtag has been generating a lot of heat in software development circles for the past couple of years, but what does it really mean? It's time to find out.

When Woody Zuill first started using the hashtag he sparked a debate that has caused tempers to flare and blood to boil, but Woody himself doesn't think that estimates are inherently bad:

If our response every time we reach the end of a project is to say 'we must produce better estimates' then we're in a cycle of continuous 'no improvement'

In this session we'll cut through the #NoEstimates rhetoric and sketch out the dysfunctions at the heart of software development that gave rise to the hashtag in the first place. We'll investigate some possible ways that we can turn this around, so that we can improve the outcomes for customers AND development teams. We might even find out how to use estimates effectively.

The Cucumber for Java Book - Seb Rose, Matt Wynne & Aslak Hellesoy Now available from the Pragmatic Press - https://pragprog.com/book/srjcuc/the-cucumber-for-java-book

On Chosen Complexity

presentation: 90 minutes
Complexity is an inherent part of our projects, so rather than denying we better get on top of it and start to surf. This session presents 10 laws of complexity, 10 rules how to cope with complexity, and gives application hints in the workshop part.

Surfing requires practice though, and a solid understanding of the water dynamics you'll experience. The mechanisms how people, actions, and organizations contribute to complexity are the core of this talk. The key concept is 'chosen complexity': all those factors we contribute ourselves to increase the overall complexity. Plus many techniques how to get to grips with the adverse influence factors.

Portable Code - the trials of porting Total War from Windows to MacOS X

case study: 90 minutes
For nearly fifteen years Creative Assembly's Total War franchise has carved out a fanatical following amongst Windows gamers. A real time strategy game of considerable complexity, think Risk meets table-top warfare, the code base is on its third iteration. Throughout development the Microsoft tool set has been used, a quite relaxed compiler amongst its peers. In 2011 the decision was taken to branch out to a new audience: the Mac user. This required the code base to be ported to a different compiler, and it was only then that the nature of portable code was truly discovered. In this presentation, Tom and Guy will tag-team their way through the history of the Total War programming team and the code base iterations, the journey through not two but three compilers, four IDE's and more 'standard' implementations than they care to think about, the despair engendered by Clang's Two-Phase Name Lookup, and the relief at the unearthing of Premake. Along the way they will discuss 64-bit programming pitfalls, unity builds, fostering communication between a programming team of two, writing portable code, and persuading a large development team of varying levels of skill to write portable code as well, in addition to maintaining, publishing and enforcing suddenly expanded coding standards. Delegates will take away a renewed vigour to write standard-compliant code and to test builds on multiple compilers, and additional insight into how to do so.

Premature Optimisation Workshop

workshop: 90 minutes
'Premature optimisation is the root of all evil', Donald Knuth told us in 1974. He was talking about the perceived trade-off between optimising performance and keeping code readable and maintainable. And we all know that we shouldn't even try optimising anything without measuring if there's an actual bottleneck in our product first. Or do we?

Making something faster, even at the micro-level, doesn't always mean that readability suffers. There are a lot of improvements that make code both more readable and better-performing, turning what might be called premature optimisation into just another healthy refactoring. And although some developers like to label almost all forms of optimisation as premature, this depends on a lot of factors, and designing for performance might actually be important for the product you are building. Let us also not forget that optimising, even prematurely, can be a lot of fun!

In this workshop we take a look at examples of optimisations that make sense to both the reader and the end-user of code, and delve a little bit into when to design for performance. We also let ourselves go and prematurely optimise the heck out of some (C++ and Python) code, so make sure to bring your laptop if you have one!

On reflecting on runtime or Program, know thyself

tutorial: 90 minutes
In a language not renowned for its reflection capabilities we struggle to give programs a view of their own static properties. So what then of runtime? Can a program know what it is doing, or why it is doing it?

Is there a model of cause and effect that can be applied to executing C++ code?
Can we build a MEP (Meta Execution Protocol) to allow a program to inspect its own runtime behaviour much as we might build a MOP (Meta Object Protocol) to inspect objects and classes?
If programs can become aware of their own and other program's intentions what does this make possible?
With Promises and Exceptions, C++ is gaining the ability to reify execution flow. But something is missing. 'Intentions' seek to capture the intent of executing code, providing the missing context in which Promises and Exceptions make sense.

This talk will cover:
The evolution of the ideas behind Intentions.
Intentions: a technique to reify the intent of executing code.
Implementation techniques for Intentions in serial, parallel, and distributed programs in C++.
Opportunities for using Intentions including: error reporting, capturing execution flow, and system provocation testing in the spirit of Netflix's Simian Army.

Footnote for Android developers: These Intentions are not those Android Intentions you were looking for.

Project DIY hosting options

tutorial: 90 minutes
SourceForge was a cool idea in its day, but now second generation web based project hosting sites are all the rage. The Big Daddy is GitHub, but others like Bitbucket provide attractive alternatives.

So, you like the ease of use, or the Pull Request way of life, and you'd love to host your work project on one of them. Sure, you can get a private commercial subscription. But do you too have a management that aren't that keen on hosting all their valuable source code outside the company, on a machine probably based in the US? And who knows? Post-Snowden, they may have a point.

In this session I'll look over the current state of the art for in-house project hosting, focusing in particular on the open source options.

Psychology 0101 (or 7+-2 things about psychology)

interactive session: 90 minutes
While software development focus often on the used technologies and prescribed processes and strives to be an exact and repeatable activity, it is ultimately a human endeavour. And through this is subject to the quirks of human behaviour and psychology. Instead pure rational behaviour we knowingly or unconsciously deal with emotional, motivational, trust issues, with concentration, and communication deficits, with biases.

All these are not unique to software development and there exists models and tools which help to understand and address many of these issues.

Starting from the hierarchy of needs, the Dunning-Kruger effect, the Dreyfus model of skill acquisition, flow, system 1 and 2, magic numbers and coloured hats, as well as multi sided messages, comfort zones, we'll see were we get. The session will contain 'experiments' and happily incorporates the sharing of anecdotes and interactive participation.

Raw TDD

preconference tutorial: 360 minutes
Looking around at the blogosphere, OSS repos and conferences, it might be easy to assume that test-driven development is all about frameworks - unit-testing frameworks, mocking frameworks and frameworks for dealing with frameworks. You can learn - or reconnect with - TDD from first principles without using frameworks as your starting point. What makes TDD effective is focus, clear progress and expression of intent; frameworks do not typically change what is possible, simply what is convenient. This workshop is intended to (re)introduce TDD to C++ programmers, while also showing-by-doing what a testing framework typically involves.

There will be slides. There will be discussion. There will be coding. There will be pairing. There will be coffee. There will be fun.

It's best to bring a laptop, but we'll be using cyber-dojo, so don't worry about IDEs, editors and compilers of choice. Guru-level C++ is not necessary, and pairing means that as long as half the attendees have a laptop and at least half the attendees are C++-comfortable, there will be sufficient resources and know-how to get the most out of this workshop!

Refactoring Legacy Code

tutorial: 90 minutes
Every programmer has to face legacy code day after day. It might be ugly, it might look scary, it can make a grown man cry. Some will throw it away and try rewriting everything from scratch. Most of them will fail.

Refactoring legacy code is a much better idea. It is not so scary when you take it in very small bites, introduce small changes, add unit tests. When code is refactored and unit tests are added, changes to functinality can be introduced.

We will take an open source c# project and will refactor it showing step-by-step examples of the techniques.

This session is full of tips and tricks you can start applying immediately. Although the code is in C#, the same principles can be applied in any language

Referential transparency is overrated

presentation: 90 minutes
The expression 'referential transparency' itself is already confusing and subject to interpretation, according to whether you're in the context of natural, functional or imperative languages. In any of those contexts however, referential transparency is generally regarded as a Good Thing ™. In computer science for example, it helps to reason about programs, prove them, optimize them, and even enables some paradigms such as normal order (lazy) evaluation.

In this talk, we claim that referential transparency is overrated because it also limits your expressive power. We demonstrate some neat and tricky things that we can do only when referential transparency is broken, and we explain the language constructs and techniques that allow us to break it intentionally, both at the regular and meta-programming levels. Such tools include duality of syntax and syntax extension, mixing of different scoping policies, intentional variable capture and free variable injection, lexical communication channels, anaphoric macros.

Please fasten your seat belts, as we're going to explore mostly uncharted territory. Whether these techniques are considered extremely powerful, extremely unsafe, or extremely bad style is a matter of personal taste. In fact, they are probably all of that, and much more . . .

Safety: off. How not to shoot yourself in the foot with C++ atomics.

tutorial: 90 minutes
If you're writing multithreaded code, it is tempting to use atomics to optimize the inter-thread synchronization and access to shared state. However, this is not always easy, and can all too often lead to code that appears to work but is subtly broken. I will show tools and techniques for using atomics safely in C++, as well as discussing scalability and lock-freedom.

Seeking Simplicity

tutorial: 90 minutes
What is simplicity and why do we value it so much? How does it relate to complexity? When is complexity good and when is it bad? How does simplicity differ from ease? As we examine these questions we'll find that the situation is not quite as simple (!) as it might first appear. In the course of the discussion we'll come up with a mental model for framing problems that we can apply to many things - but we'll particularly look at how we can apply it to our designs and code. We'll also look at how some programming languages help us more than others in our drive towards simplicity.

Spocktacular Testing

presentation: 90 minutes
Spock is taking over from TestNG and JUnit as the unit/integration/system test framework of choice for Java and Groovy developers. Spock is a Groovy-based framework, tests are written in Groovy, but any JVM-based codes can be tested using it.

Spreadsheets for developers

talk: 90 minutes
Spreadsheets are often dismissed by developers for not being 'proper programming'; but that is not true. Since I have shown that spreadsheets are Turing complete you have no excuse to diss them any longer. In this session, I will implement various algorithms in Excel to show you its power and elegance.

After all, spreadsheets are 'live' and functional, so they have everything going for them. Furthermore they are very fit for TDD and rapid prototyping.

Reasons for attending this talk:

  • Just as learning a second natural language is healthy for your brain, so is leaning multiple programming languages. Thinking about familiar problems like sorting or shortest path in a strange environment like spreadsheet formulas is like a workout for your brain.
  • Next time you are in need of a quick calculation or prototype, do not have to waste time configuring a server and deploying your code. Surely not for everything, but for some problems, spreadsheets are really suited and this talk will teach you about how to handle those.
  • Being emerged in the world that many of your colleagues and clients live and breath will make it easier to understand them.

Don't fight spreadsheets any longer, but learn to love them!

Stepanov's litmus test in a scary, heterogeneous world: does C++ still pass?

case study + presentation: 90 minutes
Some time ago, Alexander Stepanov proposed a litmus test: if a programming language can be used to implement max, swap, and linear search generically, it has potential. C++ passes with flying colours; the <algorithm> header could not exist otherwise. However, if we move outside of the walled garden of the traditional CPU and the C machine model, things are far less clear. It is not immediately apparent how to write a generic max in C++ and go on to use it on a GPU or an FPGA; in fact, to a first approximation, it appears as if that is an unachievable goal. This presentation brings some clarity in what is still a confusing area. I will start from the current C++ standard, explore currently available solutions, and figure out what is required to pass Stepanov's test. Along the way, I will prove that it is neither hard to write code for heterogeneous accelerators, nor is it feasible to ignore them as a target for our programs. At the end, after seeing that the best we can do is say 'perhaps C++ still passes, but not without effort', we will have a solid understanding of what it takes to write generic libraries aimed at heterogeneous accelerators. When we exit the room, odds are that we will know what to request from the ISO C++ committee when it comes to C++zw and processor heterogeneity.

Talking to the suits

workshop: 90 minutes
As technical contributors, one of the biggest challenges we face is how communicate with our business stakeholders. This fun hands-on workshop will be performed in groups, working through case studies to develop skills in:

  • how to explain the technical details of our work,
  • how to convince stakeholders of the need of internal quality improvements, and
  • how to justify our estimates.


The best way to find bugs hiding in your spaghetti is to feed it to sanitizers

tutorial: 90 minutes
C, and C++ require special attention from programmer. Compilers, and static analysis tools help revealing hard-to-detect problems in source code, and they can generally ana- lyze one translation unit at a time. Static analysis tools may not diagnose effects of other translation units, information obtained at run-time, and dynamically loaded modules.

Sanitizers enable compiler to instrument the code. Instrumented code will call certain handlers, if certain events happen at run-time. Problems such as certain types of un- defined behavior, data races, uninitialized read from memory, and memory leaks can be found by run-time sanity checks. Sanitizers are about an order of magnitude faster than Valgrind-based instrumentation. Both Clang, and GCC contain sanitizers that can de- tect broad range of issues. The purpose of this presentation is to showcase sanitizers in LLVM ecosystem. The presentation will be in 3 parts. In the first part, Clang CodeGen - front-end action that generates code for a valid AST - will be shown. The second part will explain how sanitizers are used in code generation, and how each sanitizer works. The third part will be demonstration of some sanitizers.

The Dos and Don'ts of Multithreading

talk: 90 minutes
Multithreading is a popular subject and we've all been led to believe that we need to write threaded programs as single-threaded performance hits a ceiling. However, multithreading is no panacea and may cause more problems than it solves. This talk, suitable for programmers of any level and language, seeks to describe some of these problems and also how to avoid them through appropriate design choices.

The Most Misunderstood Features of C - Explained

tutorial: 360 minutes
Most programming languages have dark corners. C seems to have more than its share. Almost all C programmers struggle to some extent with parts of the language that they don't quite understand. (C++ programmers struggle with many of the same features.) That which you don't understand could be hurting your productivity, reducing the quality of your work, and taking away some of your fun.

This tutorial explains some of the most misunderstood features of C, including linkage, incomplete types, tag names, lvalues and rvalues, declaration syntax, const, pointer conversions, type names and abstract declarators, arrays vs. pointers, and string literals. The insights you'll gain should help you be a better, more productive, and happier programmer.

The stand-up

tutorial: 15 minutes
Will this talk be a set of awkward one-liners, a lament of misplaced Agile practices, or a discussion of the perils of our sedentary lifestyles (and what you can do about them). The answer might shock you!

Thriving in a Polyglot World

talk: 90 minutes
In the past, systems were often largely written in a single language (*). Integrating components written in different languages was relatvely hard and uncommon. Now, interfaces between languages proliferate, wildly different languages run the same virtual machine and are frequently tightly integrated.

Being monolingual is a no longer an option for most software developers.

I plan to address some of the practical effects, and philosophical implications of this situation, and draw parallels to multilingualism in natural languages.

(*) with maybe a bit of SQL and some system scripting for administration

Understanding Transducers Through Python

tutorial with lots of lovely concepts and code: 90 minutes
Transducers - a portmanteau of 'transform reducers' - are a new functional programming concept introduced into the Clojure programming language. Although transducers are actually pretty straightforward in retrospect, wrapping your brain around them, especially if you're not already a competent Clojureist, can be challenging.

In this session, we introduce transducers by implementing them from scratch in everybody's favourite executable pseudocode, Python. We'll start with the familiar staples of functional programming, map(), filter() and reduce(), and derive transducers from first principles. We'll work towards a set of general tools which work with eager collections, lazy 'pull' sequences, and 'push' event streams. Along the way we'll cover stateful transducers and transducer composition, demonstrating that transducers are both more general, and more fundamental, than the functional programming tools baked into Python and many other languages.

By the end of this session, not only should transducers make sense to you, but you'll have a recipe for implementing transducers in your own favourite programming language.

Value Semantics - It ain't about the syntax!

presentation: 90 minutes
When people talk about a type as having *value* *semantics*, they are often thinking about its ability to be passed to (or returned from) a function by value. In order to do that, the C++ language requires that the type implement a copy constructor, and so people routinely implement copy constructors on their classes, which begs the question, 'Should an object of that type be copyable at all?' If so, what should be true about the copy? Should it have the same state as the original object? Same behavior? What does copying an object mean?!

By *value* *type*, most people assume that the type is specifically intended to represent a member of some set (of values). A *value-semantic* *type*, however, is one that strives to approximate an abstract *mathematical* type (e.g., integer, character set, complex-number sequence), which comprises operations as well as values. When we copy an object of a value-semantic type, the new object might not have the same state, or even the same behavior as the original object; for proper value-semantic types, however, the new object will have the same *value*.

In this talk, we begin by gaining an intuitive feel for what we mean by *value* by identifying *salient* *attributes*, i.e., those that contribute to value, and by contrasting types whose objects naturally represent values with those that don't. After quickly reviewing the syntactic properties common to typical value types, we dive into the much deeper issues that *value* *semantics* entail. In particular, we explore the subtle *Essential* *Property* *of* *Value*, which applies to every *salient* mutating operation on a value-semantic object, and then profitably apply this property to realize a correct design for each of a variety of increasingly interesting (value-semantic) classes.

Walking Skeleton

presentation: 90 minutes
A Walking Skeleton has been described by Alistair Cockburn as 'a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.' It is also the theme of the popular book 'Growing Object Orientated Software Guided by Tests' by Steve Freeman and Nat Pryce.

In this session Thomas will start with a clean development environment and develop a walking skeleton for an application. The skeleton will evolve and parts will be added as we gather more and more knowledge about the system we are building.

This will demonstrate how Acceptance Test Driven Development (ATDD) and Test Driven Development (TDD) can be used to drive the development of a Walking Skeleton, keep it running, and grow it incrementally.

What's an ABI and why is it so complicated?

tutorial: 90 minutes
The Application Binary Interface (ABI) for software written in C++ is much more complicated than the equivalent for C. In addition to obvious properties of the architecture such as instruction set and calling conventions, and details of how standard library types are defined, a C++ compiler has to care about details such as how name mangling, virtual functions and exception-handling are implemented. In your own code, the One Definition Rule means that the full definition of inline functions and template may become part of your program's ABI. This session will look at what depends on the ABI, what in your code affects your program's ABI, and what doesn't affect it. We will also look at recent changes in GCC's C++ standard library and how changes to the ABI were managed.

What's wrong with sprint retrospectives and how to fix them

workshop: 90 minutes
Do you often find yourself struck with a sense of deja vu in the retrospective meeting at the end of a sprint? Do you spend your time arguing about things to START, STOP or CONTINUE every single time? Perhaps you feel like you are just highlighting the same old problems, which never get fixed? Has the team rebelled completely and decided that retrospective meetings are a waste of time?

The drive to inspect and adapt is one of the most important aspects of agile software development. A great way to bake this approach into your process is by having regular retrospective meetings that engage and challenge the team to solve their own problems and make things better. However, these meetings can be difficult to run well and drive improvement. In fact, many teams sleepwalk through sessions, treating them as a box-ticking exercise that signals the end of the iteration.

Maybe it's time we tried a bit harder to make sprint retrospective meetings work?

In this workshop, Chris and Mike will explain exactly how to put together an awesome sprint retrospective. They will offer insights and tips from their experience of running sprint retrospectives every two weeks, as they try to keep each one fresh, relevant and engaging.

Attendees will try novel activities that can be used to gather information and challenge team members to consider problems from a new angle. They should leave the session equipped with new techniques to apply at the end of their very next iteration.

Presentation History
This workshop will be based on a well-received session we gave at the Agile 2014 conference in Orlando, Florida, the details of which can be found below:



What we talk about when we talk about unit testing

talk: 90 minutes
These days unit testing is considered sexy for programmers. Who'd have thought it? But there is a lot more to effective programmer testing than the fashionable donning of a unit-testing framework: writing Good Unit Tests (GUTs) involves (a lot) more than knowledge of assertion syntax.

Testing represents a form of communication and, as such, it offers multiple levels and forms of feedback, not just basic defect detection. Effective unit testing requires an understanding of what forms of feedback and communication are offered by tests, and what styles encourage or discourage such qualities.

What styles of test partitioning are common, and yet scale poorly, are uncohesive and are ineffective at properly expressing the behaviour of a class or component? What styles, tricks and tips can be used to make tests more specification-like and scalable to large codebases? How do we choose between scenario-based and property-based test cases?


Advertisement



Your Privacy

By clicking "Accept Non-Essential Cookies" you agree ACCU can store non-essential cookies on your device and disclose information in accordance with our Privacy Policy and Cookie Policy.

Current Setting: Non-Essential Cookies REJECTED

By clicking "Include Third Party Content" you agree ACCU can forward your IP address to third-party sites (such as YouTube) to enhance the information presented on this site, and that third-party sites may store cookies on your device.

Current Setting: Third Party Content EXCLUDED

Settings can be changed at any time from the Cookie Policy page.