SoCraTes UK 2017

During 15-18 June I participated at the SoCraTes UK 2017 (Software Craftsmanship and Testing) unconference which took place at Wotton House Wotton House in Dorking. This post is a summary of how I experienced it.

Thursday, 15th June

The evening was spent pairing with Iulian Ghionoiu on the Roman Numerals kata with 2 twists: we wanted to use property-based testing (we tried Kotlintest for Kotlin) and to evolve the requirements for the conversion (as though the final version of the Roman/Arabic numbers hasn’t been discovered yet). The evolution meant starting with only I’s (scratching a piece of wood or carving a line in the stone?). Then, we tried to imagine what problems that representation presented before coming up with solutions. The problems were:

• countability (ten I’s carved next to each other blur into each other when trying to count them) -> solution: introduce new symbols that look different like V (note that V here stands for one and can be placed at any position)
• additivity (even though we have a visually different character, we still have to spend time counting each single one) -> solution: make some symbols stand for more than 1. At that point V could become to mean 2, 3, 5 etc. Generally the more people had to count, the more symbols they need
• comparability (even though we have relatively short ‘roman’ numbers due to characters representing different values, we still can’t compare them easily) -> solution: introduce order of symbols so that it’s obvious at one glance two representations are the same (like. IIXIX == XIIIX, so let’s write them as XXIII or IIIXX)

We were pleased to find out that one of the hypotheses behind the origin of roman numerals was similar to our reasoning and states that the system was neither additive nor subtractive in its conception, but ordinal.

One other fun twist was that we were test-driving 2 functions simultaneously (convertRomanToArabic() and convertArabicToRoman()) by starting with the property-based test, which locked them to have to change at the same time:

convertRomanToArabic(convertArabicToRoman(x) == x

Friday, 16th June

10:00 in Azalea - Alistair Smith - Help me model my domain (DDD)

• core domain, support domain, generic domain - focus on core
• ubiquitous language is shared with all parties. But there will be internal things that you have to name that your users/business won’t get to see

11:00 in Azalea - Oliver Nautsch - Consumer Driven Contracts (CDC)

• instructions and code
• ask your clients what they need (some people don’t like it)
• format: code first + then discussion (was effective in Oliver’s experience)
• that project used CDC because they were splitting a monolith
• they also used some integrated testing after running CDC but not too much (testing pyramid)
• their integrated tests were quick (things were orchestrated with Kubernates)
• 3 ideas how to share CDC in an organisation: 1) Check in directly into Provider’s repository 2) Have Provider download the latest zip of your pacts from artifactory 3) Have Consumer build automatically commit in the Provider’s repository

12:00 in the garden - Aki Salmi - Opinions about opinions (being opinionated)

• it’s not emotions to suppress, it’s attachment to opinions
• listen to body language to see when emotions arise (at which point I stop listening)
• try to make it win-win (rather than compromise, or pushing your own opinions)
• try thinking in terms of pros and cons (and trade-offs) rather than right or wrong
• even if you have heard arguments of the other camp (e.g. outside-in testing vs bottom-up), still listen to your vis-a-vis to understand why their opinion is particularly important for them in this very context
• listen to their opinion first, rephrase their opinion with your own words
• things just are (they’re neither right nor wrong)
• Aki runs training in organisations on “how to listen to others”
• opinions are a quest to understand the other person (so that they get the experience of being truly understood)
• what if my opinions don’t matter to anybody… except of me?

14:00-16:00 in Wotton 2 - Johan Martinsson - Bugzero (hands-on)

• refactoring sources of potential bugs away (not actually bugs - yet)
• instructions under: https://github.com/martinsson/BugsZero-Kata
• blog post: 5 steps to Mistake Proof Software Design
• blog post: It’s not a configuration issue. It’s a design issue
• book: Usable Software Design by Alexandru Bolboaca
• talk recording: #BugsZero - Agile Singapore Conference 2016 by Arlo Belshee
• I was pairing with Ivan and Rainer
• Three steps works: 1) Identify weakness of design. 2) State what the potential bug is. 3) Refactor the code to prevent it.
• what techniques are available to make things more DEV-UX-friendly?
• Ivan’s automated IDE refactoring

public void printStuff(int place) {
  System.out.println( "I was at " + place );
}

We wanted to push System.out.println up the call stack (that is make the printStuff return the String)

public void printStuff(int place) {
  System.out.println( textValue(place) );
}

private String textValue(int place) {
  return "I was at " + place;

Now printStuff can be inlined which will push System.out.println to the caller and leave textValue in the class.

16:00 in Azalea - Julian Harty - TDD with content

• how to test systems which correctness depends on the data, given production data is sensitive and cannot be used by the development team
• e.g. do long names from the database render gracefully in the GUI
• e.g. handling Cyrillic, Arabic, Chinese etc. characters
• e.g. performance of queries might depend on the data shape
• a solution might be “Clean Door + Dirty Door” (IBM Bios table of interrupts), where the Clean Door team (having access to production data) can run algorithms prepared by the Dirty Door team (development team) which will characterise the production data, e.g. longest name, what encodings are used, distribution of first names (apparently one third of European first names start with “j”), etc. Then the Dirty Door team will implement a data generator which matches the production characteristics.

17:00 in Wotton - Retrospective

• useful when learning a programming language -> Exercism (should teach idiomatic solutions)

18:00 in Wotton - Esko Luontola - Lightning talks

• auth0 - few lines of code to get sign ins for free

18:00 in Wotton - Lightning talks

• asking important question on HipChat and getting no answer? Why? Because I didn’t explain why it’s important.
• why am I asking the question? What the cost of them not answering the question is? What could I do if I don’t get an answer?
• e.g. “I need to make decision by Friday for the meeting. But if you don’t give me the answer till then, here’s what I’m going to do”
• provide context for people + respect their time + provide TL;DR (expand gradually)

21:00 in 1877 (posh) - Werewolf

Saturday, 17th June

10:00 in Aster - David Green - Titanic Death (predictions with machine learning)

• online course (12 weeks) is available at coursera
• machine learning - simple maths that predicts the curve and calculates the cost function (how far is the guess curve from the reality) and then does the “gradient descent” to minimise the cost function
• data for Titanic passengers: https://www.kaggle.com/c/titanic/prospector#877

11:00-13:00 in Wotton 2 - Sandro Mancuso & Pedro Santos - Designing Microservices

• identifying microservices from business rules
• applications were derived from user journey
• tool for sequence diagrams: https://www.websequencediagrams.com
• workshop started by group drawing sequence diagrams at the service level (start with the browser)

title List of product Flow [QUERY]

Browser->+Content: getPage()
Content-->-Browser: SPA

Browser->+GetProductList: get(country, numOfProductsToRetrieve)

GetProductList->+ProductCatalogue: get(country, numOfProductsToRetrieve)
ProductCatalogue->-GetProductList: [ ProductInfo{PID, basePrice, ExtraInfo} ]

GetProductList->+Availability: get([PID])
Availability->-GetProductList: [ {PID, quantityAvailable} ]

GetProductList->GetProductList: Satisfy numOfProductsToRetrieve

GetProductList->+Pricing: get([PID, productType, availablity])
Pricing->-GetProductList: [ {PID, price} ]


GetProductList-->-Browser: numOfProducts * {productInfo, price, quantitytAvailable}

Browser->+Content: getProductContent()
Content-->-Browser: Images, Videos

Microservices have a huge cost (you can’t even experiment with it like with a single codebase) so let’s stress test our design:

• what would happen if Price Service goes down?
• how many HTTP calls do we have to make per single user request?
• when I’m in Spain but want to deliver to London, how does that impact things I’m adding to basket?
• can I deal with multiple delivery companies?
• … if these things cause ripple effect across multiple applications and it’s EXTREMELY hard to change these things with microservices
• … if a microservices in the sequence diagram does only 1 thing, is its existence justified
• … perhaps I could merge microservices based on the availability (they both have to be up together in order for the whole webapp to be usable)
• … if Sales and Promotions are done by different people, putting them in one microservice might mean that the team in charge won’t have easy access to one of the groups (Conway’s Law)

Sandro Mancuso & Pedro Santos did this in the past in a real project:

• first discuss with business people and different teams, what are the main features (it might take 3 hours to come up with 12 bullet points)
• draw sequence diagrams for these features ,with vertical blocks being just concepts (rather than applications) -> just to get understanding how it works
• extract bounded contexts and then group them by first- and second-level (ex. below)

First-level (public) bounded contexts -> Second-level bounded contexts
-----------------------------------------------------------------------
Catalog -> Media, Product, Tax, Pricing, Availability
Delivery -> Availability, Distribution
Order -> Mailer
Cart -> Promotions
Payments
Customer

• should Tax bounded context be a microservices, or just a component within Pricing Service?
• if in doubt, keep them together (perhaps later extract when they grow)
• different “channels” (web, mobile, etc) you might be getting different first-level bounded contexts
• if company has already microservices (and they’re struggling with them), just do this exercice as though you were starting from scratch (perfect scenario) and then compare current design with the perfect and see how you can evolve there

14:00 in Azalea - Ian Russell - Strategic Domain Driven Design

• https://github.com/lscc/socrates-uk/wiki/Strategic-Domain-Driven-Design
• domain -> subdomains (core, supporting, generic)
• bounded context
• ubiquitous language
• context map -> shared kernel, anti-corruption layer, customer-supplier

15:00 in the garden - Aki Salmi - How to make a safe space

• Finnish hiking society mentions 4 types of safety: physical, spiritual, social, psychological

16:00 in 1877 (posh) - XP Cards Dionatan Moura - Extreme Programming Playing Cards

• made by Industrial Logic - link
• game master plays a Problem Card on the table
• players try to act by presenting a Solution Card or a Value Card
• discussion follows what’s the best response to the Problem

17:00 in Wotton 1 - David Heath - Liberating structures

• website and book
• how to facilitate meetings so that everybody gets a voice
• we tried: 1-2-4-all and impromptu networking
• David Heath mentioned other techniques: 15% solutions (small contributions add up if done by many), TRIZ (fixing bad things), troika consulting

23:00 in Bay - Sandro Mancuso - Mob Programming

• kata: KatacombsOfDoom - github

Sunday, 18th June

• hiking to Leith Hill
• Riccardo Novaglia pointed out there’s a game similar to Werewolf and it’s called The Resistance

Some Interesting Sessions I didn’t participate in

Johan Martinsson - Accelerated Learning

• decks
• learning to differentiate concepts by a machine-learning-like technique
• e.g. how to differentiate between two kinds of sparrows that we don’t know anything about. Instead of conscious learning, we’re presenting our brain with a big sample of images of each kind and the right answers. At some point the brain will figure out what the difference is (sometimes even without being conciously aware of it)

Matthew Butt - Church Bells

• apparently the sounds produced by church bells in England are algorithmic. The sequence of notes is constantly changed by swapping the position of each two adjacent bells (or otherwise) so that each iteration results in a new sequence. The trick is to come back to the original sequence with each iteration being unique.

Next year

• take a rucksack to carry around a laptop and a charger

Thanks to

• Matthew Butt for his fantastic facilitation of the event
• Johan Martinsson for explaining his Accelerated Learning session at the dinner
• Riccardo Novaglia for being superkind and offering me a lift to London
• all the participants for the sessions, conversations and lots of fun