A Revolutionary Programming Pattern that Will Clean up your Code: Coroutines in C++tutorial: 90 minutes
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.
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)
ACCUworkshop: 90 minutes
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
Archipelagos in Gitpresentation: 15 minutes
Archipelago: Island chain, is a chain, cluster or collection of islands.
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)
An 'Island' is considered to be synonymous with a fork/branch or fork/set of branches
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
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 Operationstutorial: 90 minutes
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 Concurrencytutorial: 90 minutes
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 Exampleworkshop: 360 minutes
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 Programmerkeynote: 60 minutes
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 frameworkexperience report: 15 minutes
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 DSLcase study: 15 minutes
Braindump - How to leave your Knowledge when leaving your Jobcase study: 15 minutes
Building Learning into Team Lifeworkshop: 90 minutes
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, Saferkeynote: 60 minutes
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 Trickscase study: 15 minutes
Coding Without Wordspresentation: 90 minutes
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++14tutorial: 90 minutes
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 Computerworkshop: 90 minutes
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.
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!
90 minutes experiential learning session
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 Dockertutorial: 90 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 .
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.
Design For Testability: What, Why and Howtutorial: 90 minutes
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 Mattertutorial: 90 minutes
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 Structurespresentation: 90 minutes
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
Evolving Software: A Fusion of the Developer and Evolutionary Algorithmsworkshop: 90 minutes
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.
Fizzbuzzaloozatalk: 90 minutes
From Cluster Zero to a Quantum Universepresentation: 90 minutes
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 MVCpresentation: 90 minutes
Hands on Machine Learningworkshop: 360 minutes
Will require laptop and some knowledge of Python (and ideally numpy)
Hardening your code: Techniques to boost confidence in your code.tutorial: 90 minutes
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
History and Spirit of C and C++tutorial: 90 minutes
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 bagtutorial: 90 minutes
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 Mergetutorial: 90 minutes
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 programmingtutorial: 90 minutes
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.
How we test software at Unity Technologiescase study: 90 minutes
The purpose of this talk is to share our experience with everyone who is interested.
In the Toolbox - Live!tutorial: 90 minutes
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 Ownershiptutorial: 90 minutes
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 Shippingcase study: 90 minutes
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.
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 bugstutorial: 15 minutes
Large-Scale Scientific C++ For Casual Coders: Why You (Should) Carekeynote: 60 minutes
Learn from the mistakes of others…keynote: 60 minutes
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 approachestutorial: 90 minutes
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 Closuretutorial: 90 minutes
Lessons from the OuLiPoinvestigation: 90 minutes
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 engineworkshop: 360 minutes
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.
Professional tips and tricks
Unity installed on a laptop
Making the Case for Reviewtalk: 90 minutes
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 testingtutorial and case-study: 90 minutes
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
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 Ctutorial: 90 minutes
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
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 Complexitypresentation: 90 minutes
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 Xcase study: 90 minutes
Premature Optimisation Workshopworkshop: 90 minutes
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 thyselftutorial: 90 minutes
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 optionstutorial: 90 minutes
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
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 TDDpreconference tutorial: 360 minutes
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 Codetutorial: 90 minutes
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 overratedpresentation: 90 minutes
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
Seeking Simplicitytutorial: 90 minutes
Spocktacular Testingpresentation: 90 minutes
Spreadsheets for developerstalk: 90 minutes
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
Talking to the suitsworkshop: 90 minutes
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 sanitizerstutorial: 90 minutes
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 Multithreadingtalk: 90 minutes
The Most Misunderstood Features of C - Explainedtutorial: 360 minutes
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-uptutorial: 15 minutes
Thriving in a Polyglot Worldtalk: 90 minutes
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 Pythontutorial with lots of lovely concepts and code: 90 minutes
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
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 Skeletonpresentation: 90 minutes
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
What's wrong with sprint retrospectives and how to fix themworkshop: 90 minutes
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.
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 testingtalk: 90 minutes
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?