z2024 Training Day - SoCraTesUK/socrates-uk GitHub Wiki
The training day is organised around two tracks. Mix & match on the tracks is encouraged!
09:30 - 09:45 : Welcome
09:45 - 10:45 : TDD game with Cyber-Dojo, by Jon Jagger
10:45 - 11:00 : Break
11:00 - 12:30 :
- Track A: Learn C++ by example, by Fran Buontempo
- Track B: Functional FizzBuzz, by Duncan McGregor
12:30 - 14:00 : Lunch
14:30 - 16:00 :
- Track A: Intro to Systems Thinking, by Diana Montalion and Andrew Harmel-Law
- Track B: Refactoring beyond the commit by Duncan McGregor and Nat Pryce
How you deliver a refactoring that cannot be delivered in a single commit
16:00 - 16:15 : Break
16:15 - 17:45 :
- Track A: Ensemble/Mob facilitation by Clare Sudbery
- Track B: High-level design: a test-driven approach by Jason Gorman
Jon Jagger
Fran Buontempo
Let’s write some C++ to play rock, paper, scissors.
We’ll get our computer to make a random choice and accept our choice and see who wins.
I suspect we need 90 mins, and people will need a laptop with suitable tooling - IDE, or editor and compiler. I can share links if needed.
Outline: orienteering
-
Begin - 30 to 45 mins, getting the basics:
a) Output, starting with “Hello, world!“.
b) input and validating input,
c) writing a function,
d) C++’s maybe type (optional) which means using a template.
By this point we can read a number in and do something with it, or notice a number wasn’t provided. We have learnt about the main function, compilers, the linker, some basic syntax and have a brief glimpse at templates. We’ll realise there are different versions of C++ and know to check if ours supports what we need.
-
End: let’s make a game, 30 to 45 mins,
a) We’ll only allow rock, paper, scissors now, so learn about class enums.
b) We’ll use C++’s random numbers to generate a computer turn
c) We need to decide who won, so we’ll need a function to check and will discuss testing
d) We’ll use static_assert to write a few tests, learning a bit more about compile time computing
Finally, we can play the game and discuss extensions. We’ll also reflect, thinking about how to start learning something new.
Learning outcomes:
By the end of the session, we will be able to write a small C++ program, using input and output.
Starting with basic syntax, we will move on to advanced features, like templates and static_assert.
We’ll think of the general questions to ask when learning a new language or revisiting one you forgot.
We’ll also have a game we can play, which might not be a learning outcome, but is a result and might spark other ideas for follow up discussions.
Duncan McGregor
There's a lot we can learn from the simple FizzBuzz kata. In this workshop we'll work together to practice Test Driven Development and refactoring, before expanding the scope and exploring testability, correctness, error handling, actions, calculations, and data.
Diana Montalion 
Systems thinking expands your capacity to do difficult things. In software systems, relational complexity is increasingly difficult. Cross-functional thinking is difficult to orchestrate. Changing entrenched organizational patterns is difficult. Thinking in systems … is difficult.
Peter Senge has demonstrated that we blame the wrong things (events, situations or processes) for our systemic problems. W. Edwards Deming says that 94% of the time, the system is to blame for performance issues, not the individual parts of the system, Jay Forrester discovered counterintuitiveness: most organizations “fix” systemic problems by inadvertently making them worse.
Donella Meadows said, “We’ll go down in history as the first society that wouldn’t save itself because it wasn’t cost-effective.” In this workshop, you’ll learn why systems thinking is difficult to master. What are the blockers and challenges?
You’ll learn a few core practices that will expand your skillset. Using the Iceberg Model, we’’ll dive into the root cause of recurring systems problems. You can use this approach whenever you want to develop an impactful recommendation,
Nat Pryce 
Duration: two hours
Audience: software developers.
Prerequisites: experience with Kotlin and SQL a bonus, but not required.
With modern tools refactoring is very easy. Maybe too easy. It’s easy to make a change to our code that has a widespread impact across or beyond our codebase. It’s easy to disrupt the work of other team members. It’s easy to break code that depends on ours. It’s easy to bring systems down when we deploy our refactored code.
We can categorise refactorings by how easily the change to our code can be propagated beyond our local workspace:
Mono-commit
- Affects a single codebase and built artefact.
- Applied by one atomic commit.
Multi-commit
- Creates wide-spread change in a single codebase & built artefact.
- Applied in a sequence of commits with expand/contract to reduce disruption to team members.
Multi-deployment
- Cannot change all affected code in a single atomic commit.
- Requires multiple deployments with expand/contract to avoid downtime and breaking dependent systems.
In this session we explore the safe delivery of multi-commit and multi-deployment refactorings, through a mix of brainstorming exercises and hands-on ensemble programming.
Clare Sudbery
Jason Gorman
