Retro - HackMD

# Retro ## 29 May 2025 Links: - [Storybook Vue Tutorial](https://storybook.js.org/tutorials/intro-to-storybook/vue/en/get-started/) - [Tutorial repo](https://github.com/chromaui/learnstorybook-code/tree/vue) Useful Commands: Run storybook app: ```bash npm run storybook ``` Run project: ```bash npm run dev ``` ### Like - Like having notes so we remember what we were doing. +2 - Like that we had a failing test to start from. +2 - It took less time to get back into how storybook worked. +2 - Liked that we started using Typescript to try it out. ### Learn - Typescript forces you to add types that don't always help. +2 - The IDE doesn't always seem to help you with the types. ### Next - Finish our 'PureTaskCounter' (rename next time from 'TaskCounter') - Make sure all of our components are connected - Investigate how it would work with mocking the interaction with a real back-end - Suggestion: Focus again on Component-Driven Development (Where is the TDD part?) ## 3/04/2025 Links: - [Storybook Vue Tutorial](https://storybook.js.org/tutorials/intro-to-storybook/vue/en/get-started/) - [Tutorial repo](https://github.com/chromaui/learnstorybook-code/tree/vue) ### Like - We built our own component +2 - We liked working with the tests +2 - We built things up step by step this time - The Storybook play 'with interactions' is a powerful way to introduce tests ### Learn - Javascript, HTML and Vue fundamentals are gone +2 - ### Next - Try to build a small component ourselves in the same way as the tutorial - Fix the error: ```javascript expect(within(<div#storybook-root>).getByTestId("add-task")).not.toHaveProperty("disabled", true) expected <button …(2)></button> to not have property "disabled" with value true See the full stack trace in the browser console. ``` - Suggestion: Repeat what we did but this time in Typescript - Investigate how it would work with mocking the interaction with a real back-end - Suggestion: Focus again on Component-Driven Development (Where is the TDD part?) ## 27/03/2025 Links: - [Storybook Vue Tutorial](https://storybook.js.org/tutorials/intro-to-storybook/vue/en/get-started/) - [Tutorial repo](https://github.com/chromaui/learnstorybook-code/tree/vue) ### Like - Partially liked division between Pure component and the one with state. - Following the tutorial. +2 - Fast feedback in Storybook - The way of testing is very different from what we're used to. It opens up possibilities for really testing the UI. - Forces you to make your components more independent (with Storybook) ### Learn - 'Play function' of Storybook (but how does it work with an actual backend instead of an in-memory store?) ### Next - Check if we've finished the [tutorial](https://storybook.js.org/tutorials/intro-to-storybook/vue/en/screen/)? - Try to build a small component ourselves in the same way as the tutorial - Suggestion: Repeat what we did but this time in Typescript - Investigate how it would work with mocking the interaction with a real back-end - Suggestion: Focus again on Component-Driven Development (Where is the TDD part?) ## 13/02/2025 Links: - [Storybook Vue Tutorial](https://storybook.js.org/tutorials/intro-to-storybook/vue/en/get-started/) - [Tutorial repo](https://github.com/chromaui/learnstorybook-code/tree/vue) ### Like - Something completely new that we have never looked into +2 - Like that with Storybook you have to think about the states of your components +2 - We can see that it can help us with TDD approach (even though we're not there yet) +2 - It's a bit like Example Mapping / Specification by Example (but then for components) +2 - TDD will involve moving between the states among other things +2 ### Learn - Nelis really dislikes front-end syntax (deep nesting, it looks messy) - The existence of Storybook and the idea of 'Component-driven development' is interesting - When following a more complex tutorial, it's good to park your project and follow the tutorial loyally before returning to the project +2 ### Next - Finish following the Tutorial (Start from [Composite Component](https://storybook.js.org/tutorials/intro-to-storybook/vue/en/composite-component/), section 'Build out the states') - Then try to TDD our own new component ## *Goal:* Explore testing Links: - [Paul Hammond video: Component-driven development](https://www.youtube.com/live/jBkEz-Azsak?si=F9weLQ9vgbkSIKvN) - ### Like - Discussion on how to test +2 - Good that we have links and notes +2 - ### Learn - Because we coupled our component with pinia it feels strange. +2 - Script setup vs the explicit setup (syntactic sugar) - the .ts extension as part part of the import call causing problems ### Next - Continue to work on TodoApp - TDD(ish) an AddTask component - Look into using callbacks instead of coupling Pinia to our components - Agree to watch the Paul Hammond video ## 11/12/2024 *Goal:* Explore testing Links: - [Vue.Js Docs](https://vuejs.org/guide/introduction.html) - [Pinia Docs](https://pinia.vuejs.org) - [Project Repo](https://github.com/Accolade76/vue-todo) - [Vitest Documentation](https://vitest.dev/guide/) - [Test Components-Crash Course](https://test-utils.vuejs.org/guide/essentials/a-crash-course.html) - [Pinia Test Component](https://pinia.vuejs.org/cookbook/testing.html#unit-testing-components) ### Like - Able to make progress in 1hour (setup a component test interacting with the store) - Good experince with the ecosystem so far. - Works good that there is the person as a driver for the entire session. makes the search work easier. ### Learn - Make Component tests with store is really verbose. The setup of the wrapper is confusing - Webstorm is behaving strangly with vitests failures ### Next - Give a try to Visual Studio Code with Vue/Vitesse plugins - TDD(ish) an AddTask component ## 04/12/2024 *Goal:* Start setting up project and adding first features Links: - [Vue.Js Docs](https://vuejs.org/guide/introduction.html) - [Pinia Docs](https://pinia.vuejs.org) - [Project Repo](https://github.com/Accolade76/vue-todo) ### Like - It was easy to get started in Vue.js (there was good scaffolding) +2 - So far the set up was easy to follow ### Learn - Vue.js looks a bit more structured than React - Nelis forgot a quite a bit about vue.js ### Next - Start using tests (vitest) ## 25/06/2024 Pivot to Vue.js project (after struggling with Actor framework in Rust) ### Like - Research together - Moving away from Rust for now (no direct use) ### Learn - Better to have a concrete goal to work towards - Setting up an Actor is not that hard (in Rust) - Not all learning goals work well in a group? --> Learning the fundamentals of a language. It would be better if one of us have a basic understanding. With Rust we struggled a lot because non of us master the basics. --> Lot of basic tutorials as an alternative (alone) ### Next Build the vue-todo app (to learn Vue, testing in front-end and Pinia) ## 05/06/2024 ### Like - Like study together (take time to read) - Study different codebases and took time to understand (syntax) parts we did not understand. - Study existing codebases --> See how people typically do things - Question some of our assumptions: is Hexagonal / xxx the correct way for rust? ### Learn - move, lambda, - Actor model - Studying together worked well - Why? -- Less delivery oriented - less impatience -- goal was study itself -- Less research in the background ### Next https://actix.rs/docs/actix/actor ## 14/05/2024 ### Like - Reading together +1 - Kept going with trying to understand ### Learn - Box -> A new construct which is a reference to the heap - Trying to understand DI in combination with Rocket might not have been the best idea --> First tryout the example before diving into own code? - Retrofit DI into Rust (while it is not intended) - Maybe we fail to understand the ownership deep enough for DI ### Next time - Read about the Box? - Reimplement the solution with a different web framework (not rocket) ## ? ### Like - Research together where peole help to point things out in the documentation - Trying to learn (although it fails for now) - Struggling together ### Learn - Editors can pose a real challenger in fluent development (for example, autorun that moves focus) - Dependency inject and ownership is hard - Not knowing the language (in something like Rust with new concepts like ownership) makes it hard to follow. - Understand the concepts, but hard to articulate in concrete things to do. ### Next time - Switch without asking who wants to take over - Try to introduce a struct (App) that owns the dependencies? - Continue with Business logging ## 8/04/2024 ### Like - Looking at logging - Research together (bit together, bit in the background) - Change configuration through environment variable - Playing with the TODO app, payed off. With a REST api you explore a whole other side to the language ### Learn - We criticise the big frameworks, but they also have a lot of nice features (like easy log setup) - Nice to have a standardized environment that just works :-) - Study the 'feature' in one language speeds up the learning in the other language. Often tools / libraries are similar, or the principles are similar. ### Next time - Business logging - Handling exceptional situations and log it appropriately - Add database abstraction (like repository pattern) - Log format - like json for datadog? ## 26/03/2024 Working on https://github.com/supernelis/rust-todo-rest ### Like - Able to get the code so clean +2 - Learning modules and files, explore - Less conflict ### Learn - We are unsure it is idiomatic (use of modules and files) - Module visibility pub(crate) - Flow worked: maybe frequent switching might make figuring something out harder. Maybe switching is needed to improve the dynamic. (we only switched 1 time) - Someone who is silent might be a moment to suggest a switch. ### Next time Add more capabilities (like logs) Add database abstraction (like repository pattern) ## 13/03/2024 Working on https://github.com/supernelis/rust-todo-rest ### Like - Research together (on project structure, on tests) - Easier than expected - Tests help us to just try things - Change of direction to structure in files - module visibility of rust is very powerfull ### Learn - Jumping around to much / or are instructions not clear - Need to keep the same thing in same pane - Blog posts might be outdated --> Might lead in wrong direction. Always double check with the rust book - Refactoring for RustRover not always that great --> Obvious thing still need manual changes. - Need to think more in advance, might disencourage refactoring because it is more cumbersome - Compiler is source of truth vs Rustrover - Refactoring is so basic, but often not well supported. - Driver: it is really usefull to have the intent explained - If the intent is not clear, other people might want to try their idea because the direction is not clear. - Please vocalise the intent ### Next time Continue Mine for conflict? ## 7/03/2024 Working on https://github.com/supernelis/rust-todo-rest ### Like - Starting from the failing test - Dive in the implementation (not only the tests) --> Saket - More progress today - as we added functionality - Rust compiler warnings / errors is good to understand what is going on ### Learn - Hard to write a failing test --> Determine the next step? - Different backgrounds / missing parts of the implementation makes it hard for someone to follow - Rust output is really verbose --> Not always obvious as you might miss it. - The IDE still needs some work - What todo when someone gets stuck? -- Switch ? --> Might lead to passive looking -- Step by step advice -- Make more explicit that you need help? -- Briefly research together? -- Switch more often so not 1 person is responsible for the full design? - Switching --> Maybe to long ### Next time Continue Natural switching --> Give it a bit more time to learn more. Mostly on red. ## 27/02/2024 Working on https://github.com/supernelis/rust-todo-rest ### Like - Switch on green works well --> Note that switch needs to be even smoother. --> Harder to decide when to switch --> Might be more context based - From strict to loose form -> Less experienced to more experienced - End on a red test (hope it helps to get started again) ### Learn - Lifecycle keeps on surprising us - Trait --> Experiment more - Probably Rust might not be easily understandeable for the all developer - A lot of things are implicit, and you have to understand them to work with them (like lifecycle and ownership) - Show and switch --> The person who knows navigates. As soon as it is shown, you switch so the other can also navigate and learn. ## Next time Continue with todo app Switch on green ## 01/02/2024 We switched to the todo app: https://github.com/supernelis/rust-todo-rest ### Like - Switched to todo app, because we learned more syntax and concepts - Trying the IDE capabilities - Good interaction (without formal structure?). We learned to keep a todo list and wait for appropriate time - Zoom annotate function ### Learn - Lifetime declaration - Rust scope is harder than the first reading reveals - Rust testing setup is harder with beforeall - Learning the new library for the test_context - Comment how to handle "And" in git comment --> Just use two lines in the git commit ## Next time Continue with todo app ## 23/01/2024 ### Like - Back to ensemble again +1 - Rust is pretty easy to install - Learning rust - Switch on red--> Just take care to move to red fast enough ### Learn - Even with a long break, it worked pretty well - Dedicated driver to get to know the syntax +1 - Getting started fast because we preinstalled a bit things - Refactor on red? --> Got lost - Double check as driver before you take initiative - Difficult balance to check documentation in details vs just trying ### Next time - Rust advent of code finish day 3 ## 27/4/2023 ### Like - Red test, so clear where to start - Focus more on domain language + testnames - Give time to the navigator to experiment (sometimes just try) - We get better at explaining what we are planning to do - Experimenting with the switching (long interval, everyone just got one driver/nav) - Handover goes smooth (push, pull) ### Learn - Hard not to influence the navigator +1 - Good to have a reminder about what we are focussing on ### Next time - Continue to focus on learning DDD implementation ## 27/3/2023 ### Like - Small refactor on green (introduce account) - Loosing Saket in the discussion --> Move him to driver so we are force4d to explain more -> Will be forced because otherwise will not be able to do it. - Discussion about design - Still small refactorings (Move logic to InMemoryAccountRepository instead of using fakes). We added mostly design today. We might have needed the fakes to be able to make the design. ### Learn - Cannot compare objects in DDD if they are an entity and agregate - We faked to much in the beginning. If you already know the direction, why not building the design already? --> Point of discussion! Maybe it was overdoing postponing the design. Maybe there is a relation with https://en.wikipedia.org/wiki/Transformation_Priority_Premise. Better strategy: fake -> Test on repo, instead of using the fake in a lot of tests. - Optionals - IntelliJ key combos - DDD gap - We did not add a lot of tests? Mostly because we faked a lot. - DDD imposes the design, so there is less need for discovering the design? - Still difficult to take the small steps sometimes. Especially when it is obvious. ### Next time - Failing test ## 21/3/2023 ### Like - Switch pretty smooth - Discussing the approach a bit more +1 - Less impatience, maybe because we do not use the timer. - Not changing the test and implementation at the same time - Searching for a small step - Drive the implementation with tests (no cheating) - Intellij environment, simple setup ### Learn - Even for us it is not easy to see the next small step - Test first is not enough for design --> Sence for design / practice through katas? - Switch on green does not make the cycle the same size - With longer turns, the navigator need to express intent even more ### Next time - Keep switch on green ## 28/2/2023 ### Like - Exploring DDD concepts from ground up (in code) - Better excercise, smaller, clearer (with domain picture), better starting point by focussing on the domain - Focus more on design, less on TDD. ### Learn - Could start a kata from a modelled domain for DDD, so you can focus on the implementation patterns. - Know the concepts (vaguely), and I apply them, but I cannot explain them clearly (Nelis). - TDD can be cluncy when you are working towards a know design? Sometimes feel artificial to work around this. --> Maybe do a few error cases? - TDD alone is not enough, you should also learn to design properly. ### Next time - Focus on some error cases to drive a real implementation, e.g. Ensure that if you register 2 accounts, they have a different ID - Add rotation next time (Nelis to prepare) ## 6/2/2023 DDD kata https://hackmd.io/@pierodibello/HyIHeV1BY Matteo, Saket, Nelis ### Like - A bit different than the usual kata - A very clear constraint that is not trivial todo, need to think hard - Busy with a concrete code thing ### Learn - Command / CommandHandler / Repository - I know the concepts, but cannot explain them without a bit of googling. Need to refresh theory behind it. - Looking for the advantages? - Most people consider DDD = event sourcing, but is not true - Not the best kata to introduce domain driven design? ## 26/9/2022 Trying out learning hour: test doubles Matteo, Saket, Nelis ### Like - Focussed on a topic (clear subject, more bounded scope) - There was a structure in the session - Learning through experience - might be an idea just to start and then the theorie? - A bit of theory helps to be guided to a particular topic. ### Learn - Even with 3 we have to ensure there is clear roles - A learning hour needs some deep preparation (also trying the kata) - Need to make background line yourselve - Do not understand the start of the session (with the link). To much info, while excercise was only about stub. You could get lost. - Depends on the experience of the participants what you need to prepare - Excercise is limited in time: this format may not be suited for ensemble approach. - Setup time is not easy, might only work in company with shared setup. - Hard to use cyberdojo (with a hack) - Do you save time with this prep -- Need to make own material anyway? ### Next time Another learning hour? ## 22/06/2022 Experiment with Haskell, day 3 of advent of code With Cloud 9 IDE + Zoom for call Matteo, Saket, Nelis https://github.com/supernelis/haskel-advent-of-code-experiment Using mobtime, 3 min (because of multiple screens) ### Like - Cloud 9 IDE works nicely - We can use our keyboards (less frustration) +1 - We finished Part 3 of advent - Finally looked into separating test and production code in Haskell ### Learn - 3 minutes is very short if you have to do screen share +2 - It's annoying not to have automated refactor +2 - It's annoying to set up Cloud 9 every time ### Next time - Set up a bash/hs script and put it in the repo so we can run to start - Increase rotation time to 5 min - Refactor - Day 3, Part 2 ## 6/4/2022 Experiment with Haskell, day 3 of advent of code With Pop as tool in full screen Matteo, Saket, Nelis https://github.com/supernelis/haskel-advent-of-code-experiment Using mobtime, 3 min (because of multiple screens) ### Like - Learn details of Haskell datatypes - New tool (hoogle) - Struggled +2 - Build up vocabulary in the tests (not sure I'm much wiser in Haskell (Saket)) - Nice attempt to learn this way (but need to study more) - Tried a bit to E2E approach (rows to column) ### Learn - Start understanding the language != knowing the base functions it provides +1 - Easily loose the small step approach... Need to take smaller steps{} - Struggle more to express intent (when we are struggling ourselves) ### Next time Implementation in tests and then extract the function Pop and differences and in keyboard? Switch to visual studio code sharing again? ## 31/3/2022 Experiment with Haskell, day 2 of advent of code With Pop as tool in full screen Matteo, Saket, Nelis https://github.com/supernelis/haskel-advent-of-code-experiment Using mobtime, 3 min (because of multiple screens) ### Like - Good rhythm +1 - Starts to be more natural in Haskell (7 sessions) +2 - Pattern matching (ComplexSubmarine ), it made it easy to extend for part 2 day 2 - Refactor to executeInstructions2 (make second version used by first, then inline). It was harder without IDE, but still usefull. Note that there are many languages wihout refactor tools, but these remains usefull. - Just experiment - Rename a lot ### Learn - Embedding of creation makes it hard to change - Still miss IntelliJ keys - We always proceed bottom up as an ensemble. Would it make sense to start with a E2E test? ### Next time Next day (day 4): try to start from E2E test ## 31/3/2022 Experiment with Haskell, day 2 of advent of code With Pop as tool in full screen Matteo, Saket, Nelis https://github.com/supernelis/haskel-advent-of-code-experiment Using mobtime, 3 min (because of multiple screens) ### Like - Good rhythm +1 - Starts to be more natural in Haskell (7 sessions) +2 - Pattern matching (ComplexSubmarine ), it made it easy to extend for part 2 day 2 - Refactor to executeInstructions2 (make second version used by first, then inline). It was harder without IDE, but still usefull. Note that there are many languages wihout refactor tools, but these remains usefull. - Just experiment - Rename a lot ### Learn - Embedding of creation makes it hard to change - Still miss IntelliJ keys - We always proceed bottom up as an ensemble. Would it make sense to start with a E2E test? ### Next time Next day (day 4): try to start from E2E test ## 24/3/2022 Experiment with Haskell, day 2 of advent of code With Pop as tool in full screen Matteo, Saket, Nelis https://github.com/supernelis/haskel-advent-of-code-experiment Using Mobster, 3 min ### Like - Actually have a session +2 - Charted out the options (for the complex type) - Pushed away delivery pressure, but found way to learn - Comming back to the code, just try things - Git helps us to experiment +1 - The tests help us to do search and replace in a safe way. - It was hard to restart, but without tests it would have been horrible without... ### Learn - Unsure what we did differently? Seem to have missed a step in between? --> We need to stay on the same page, maybe write a test to prove the learning. - Even without tests the small refactor techiques are usefull (story of access database code) ### Next time Continue ## 10/2/2022 Experiment with Haskell, day 2 of advent of code With Pop as tool in full screen Matteo, Saket, Nelis https://github.com/supernelis/haskel-advent-of-code-experiment mobti.me 3 minute rotation ### Like - Trying to introduce the buildSubmarine factory function. Gave us a new challenge: a bigger refactor. +2 - The discussion about whether or not to duplicate code, etc. its more interesting when we disagree than when we agree. +2 - Forced to take smaller refactor steps due to missing IDE. - It was nice to do a roll-back +2 - We are willing to try things out and explore. +1 ### Learn - Miss the IDE ### Next time - When we switch, if its red then we revert to green. - Maybe see Matteo work out injecting different functions into the Execute function. ## 3/2/2022 Experiment with Haskell, day 2 of advent of code With Pop as tool in full screen Matteo, Saket, Nelis https://github.com/supernelis/haskel-advent-of-code-experiment mobti.me 3 minute rotation ### Like - Command type, is nice. What about value being an Int? +2 - Cleaning up the old / redundant tests - More discussion during the retro! ### Learn - Almost all of us did not talk to much - if we do not know where to go we do not ask? - Should we as a group always progress to the unknown? The highest risk feature? --> Not so sure if this is required! Sometimes it can be usefull to work on smaller issue... - Is it ok to take a journey in your head? I think it is ok if the rotation is small? - Tests not failing for the right reason? Be more strict on checking why they fail - Wait until someone asks for help before you jump in? - It is easier to be silent if the interval is only 3 minutes. - Because it is such short time, we do not ask so much questions? This might force you to be more proactive. - Little interaction between the navigator and the MOB. Might also be more difficult in unknown domains? - The dynamic not interacting might be harder in inexperienced MOBs or during interviews. ### Next time - Look into reduce instead of foldl - Type of value? Constraint? ## 18/1/2022 ### Useful Links Experiment with Haskell, day 1 of advent of code With Pop as tool in full screen Matteo, Saket, Nelis https://github.com/supernelis/haskel-advent-of-code-experiment mobti.me ### Like - Lot better than last time by being more intentional (+2) - Be explicit when to change direction - Stricter with the turns, the timer worked better - Defaulted to action faster - Deconstructing a list in Haskell calls for recursion! ### Learn - Driver wanted to do something else? Move the mouse? Especially if you do not know where to go it can be usefull if the driver chimes in? If the driver knows what to do, and the navigator does not? - Trying to be explicit when to cut in 'can I suggest something'. Still need to be better. - Look on your own? is that ok? As long as you merge the discussions again, it is ok! Attention points: should be short, maybe be explicit about it so people know you are not following anymore. ### Next time part 2 of day 1 ## 12/1/2022 ### Useful Links Experiment with Haskell, trying to start advent of code With Pop as tool in full screen Matteo, Saket, Nelis https://github.com/supernelis/haskel-advent-of-code-experiment ### Like - Marker to indicate to the driver to avoid misunderstanding - Struggled +2 ### Learn - hspec is to much to start? Easier with a simpler test runner - hard to start this MOB, pretty fast we moved to expressing intent again - When we are struggling, we suddently changed direction +1 - Divide the world in pure and inpure functions, IO String vs String - Shoehorn what we know into Haskell instead of reading the documentation (because of TDD?) - Start with a smaller step without the IO? ### Next time continue ## 7/12/2021 ### Useful Links Experiment with Haskell, trying to start advent of code With Pop as tool in full screen Matteo, Saket, Nelis https://github.com/MondayMorningHaskell/Testing http://learnyouahaskell.com/starting-out#babys-first-functions ### Like - Able to run a test - Favored doing over to much discussing (example project) - Dove into a new language, something new for all of us. Have to learn to group learn. ### Learn - Having a sandbox that is already setup helps - 3 minutes was hard today, it caused a lot of interuptions in the flow --> Is it because we are unfamiliar with the subject? Same level of ignorance? - More problems during learning to stay within the rotation / driver navigator. -- Having an idea and wanting to help? -- Wait with suggestion until there is a pause or until a question is asked (let the navigator struggle) - Haskell was a bit simpler to get started (probably due to the playground). ### Next time - Start with an empty haskel; unit test project setup ## 30/11/2021 Kata: https://github.com/supernelis/deviceDriverMockingKata With Pop as tool Explore mocking vs home made test doubles Matteo, Saket, Nelis ### Like - Retro document helps to get started again. - Tests help us to understand where we are. - Having the 3 tests next to each other, comparison of structure. Made the intent clear. - Reading out loud as navigator (better than before). Helps to orient. Helps to understand intent. Helps to switch. Forces doing together. Allows to catch up. - when-jest library ### Learn - Slower start after a long time. - Mobster was annoying remote (combined with pop?). It broke the flow every time. - Switching between windows is annoying when sharing a part of a screen. ### Next time - Cypress (UI test) vs other tests in a javascript app (Vue? React?) - Functional language + testing - Advent of code ## 5/10/2021 Kata: https://github.com/supernelis/deviceDriverMockingKata With Pop as tool Explore mocking vs home made test doubles Matteo, Saket, Nelis ### Like - 3 minutes works - focussed more in reading together. Not well yet, but seems to work. - Going back to the intent before continuing - Going through the process several times makes it easier to follow what we are trying todo - Doing research together worked better. ### Learn - Not explicit who is going to read - As soon as there is an error, I want to solve it and cannot shut up. - Driver noticed he was taking initiative, stopped and asked for next instructions. - Interupted less this time +2. - Still not sure if I want to use a framework or library. - For now: I like sinon more? - Homemade testdoubles: the hard part is comming up with good concepts for the homemade test doubles. - Link with Trip service kata? ### Next time - READ: the navigator is reading out loud - Work a bit more with Jest. ## 29/9/2021 Kata: https://github.com/supernelis/deviceDriverMockingKata With Pop as tool Explore mocking vs home made test doubles Matteo, Saket, Nelis ### Like - Kept searching for a better solution, not giving up. +2 - Rotation not kept strictly, but still have organic collaboration? - Tests in simpler with mocks, as we did not have to introduce something like 'memory', i.e. concepts not in the domain. - Duplicate the test, focus on learning mocks vs ### Learn - Sinon documentation is really bad - 3 minute timer might not be the best when doing research? Or are we are not used to do research together? - Override the navigator several times, be more strict on navigator research? - Pop had lag. ### Next time? - Focus research together next time (like 1 with sinon, Jest?). - Be more strict in driver / navigator. Wait for help questions? - Reading out loud? ## 7/9/2021 Kata: https://github.com/supernelis/deviceDriverMockingKata With Pop as tool Matteo, Saket, Nelis ### Like - We raised struggle to whole team (mask lookup). - Task oriented, quite fast once everything is in place. Nearly boring. - Maybe the tests would be better with a mocking framework? ### Learn - Makes sense from ensemble perspective to go slower and lookup things together. To speedup the team, not the excercise. Long run vs short run. - Need to get the intent as driver to understand what I'm doing. - Array in javascript sucks (new .at(-1)) ### Proposal - Redo kata with mocking framework --> Sinon? - Ask for intent explicitly when confused Ideas for next katas: - React testing? - Elixir kata? - Functional programming? ## 1/9/2021 Kata: https://github.com/supernelis/deviceDriverMockingKata With Pop as tool Matteo, Saket, Nelis ### Like - Pop experience was nice, smooth, not in our way - 5 min to remember what we did --> Easy after two months to understand the problem - 3 minutes works out well, no pressure to say my mind - Succeeded in expressing intent more ### Learn - Using constants to clarify tests --> Do earlier to ensure everyone can follow ## 24/6/2021 Kata https://github.com/goerge/DeviceDriverMockingKata/blob/master/JavaScript/test/devicedriver_test.js Matteo, Saket, Nelis ### Like - Nice smooth pace - Like the refactoring in the kate - Console log fix --> Exactly at correct time - Question: should we commit? And option to say no. ### Learn - Keycombinations - Express more intent --> Short time forces that everyone is on the same page - To big step? To much discussion? - Still hard to express intent - Commit often: if there are more unknown. If there are trivial renames / remove lines less pressure to commit often. - If you have an idea, there is mostly a natural point where you can introduce it. Throwing it out there when you thing about is might lead to chaos. Wait for the correct break. - BeforeEach - ### Next time - keep 3 minutes - Focus on expressing intends over doing - Take notes on likes / learnings / ideas - ## 17/6/2021 Kata https://github.com/goerge/DeviceDriverMockingKata/blob/master/JavaScript/test/devicedriver_test.js Matteo, Saket, Nelis ### Like - Wrote down examples when in doubt +2 - Smooth handover - it was a bit harder, tripped over ourselves by not extracting the constant for READY ### Learn - If you do not control dependency even debugging is hard (nanotime) - Refer to you as decision in the past (trying to be thoughfull and always use we) - Observation Saket: Takes longer to get into where we are in the code - We went to fast into the next test, to eager to cover all the cases. - Sloppy in the debugging, not phrasing hypothesis and test that one --> Lack of being explicit about the hypothesis - Mental note: as driver not take to much initiative ### Next time - STOP and ask explicit for refactors / something that bothers us - 3 min - same kata - More explit with naming of magic numbers ## 10/6/2021 Kata https://github.com/goerge/DeviceDriverMockingKata/blob/master/JavaScript/test/devicedriver_test.js Matteo, Saket, Nelis ### Like - Discussion about the testing we had (to action vs expressing intent) +2 - Machine relatively easy to setup - Handover easier, state inconsistent, less need for docker - Pace that everyone could follow ### Learn - X-large is better as default instance - Terraform configurable for java/javascript? - Remember more then I though I would - Codebase was relatively easy because of dependency injection () - The 'shortest branch to deepest branch' order of covering code really helps iwr -useb https://raw.githubusercontent.com/JayBazuzi/machine-setup/main/windows.ps1 | iex iwr -useb https://raw.githubusercontent.com/JayBazuzi/machine-setup/main/javascript-webstorm.ps1 | iex ## 25/5/2021 Kata on AWS machine Matteo, Saket, Nelis ### Like - Machine was more reactive (xlarge) - 3 minute switch helped to be on the same page - decision as group: kept direction - "I do not see the pattern yet, so I will continue" -> taking smaller steps - Better at signaling intent (+2) - Less interupting each other - Idea not in the current line of thought, keep (temporary) to yourself to not interupt - Setup with virtual machine (feels more local passing the machine) +1 ### Learn - Reminded to take action over analysing to much - What is the optimal point of refactoring? Is it worth it? - Size? - Clarity? - Would it make sense to use an online code editor? - IDE? - Online research? Need browser share, time track, ... ### Next time ideas - Keep 3 minutes (for kata) - Issues with setup - Password for anydesk - Check out + push the project - Intellij first time setup ## 11/5/2021 Kata Nelis, Matteo, Saket ### Like - Went smooth, ok this type of setup. Usable for coding dojo. - We listened to Saket and not take over. - Learn how to setup the MOB machine (terraform script) - No switch time ### Learn - Checkout the code in advance with IDE open so we do not loose time +1 - We do not always express our intent where we are going - Difference between talking to oneself and asking for help: make it more explicit. - 3 minutes makes you want to go fast (cutting corners in expressing intent) - Ask clarifying question if the direction (and why) is not clear - Concept of Optional in Java - Why was not clear from the beginning - Challenging to see the smaller steps ### Next time idea - Keep 3 minutes - Focus on expressing intent and ask for intent - Continue with the kata ### What is not well setup - IntelliJ java version (indexing) - checkout the project ## 4/5/2021 Play with terraform to improve terraform Nelis, Matteo, Saket ### Like - Interesting to see powershell - Pretty easy to add the feature we want +1 - Setup of machine is easy - 3 minutes rotation: forces to collaborate more. Changes are not yours, but by the team +2 - Setting makes switching very easy ### Learn - When struggling: maybe stop and ask why. Maybe then you will see alternative. - Just make it work (not pretty in one go) - Struggle if you do not know the basics ### Next time ideas - CODING ## 27/4/2021 Play with terraform to improve the script and support multiple machines Nelis & Matteo ### Like - Really easy to scale from 1 machine to multiple machines +1 - Like the like & learn over + and - (helps to stay positive) +1 ### Learn - Nelis prefers real programming languages over DSL who are often inconsistent in the way they do things (foreach vs for in output) - Output loops terraform - Always want more once it works ### Next time ideas - Run script on login instead of instanciating the machine? - Manually accept people on anydesk (done) - ## 20/4/2021 - Setting up a Windows Server 2019 on AWS EC2 (following script by Jay Bazuzi and Llewellyn Falco) before the session - continuing the Refactoring to cleaner code to test out the machine - Rerun script on Nelis machine Nelis, Saket, Matteo ### Like - Setting up the machine before the session helped, only 7 minutes to be at start state. - Script worked also on different machine (Nelis) - Level of clarity we can get in the code is improving ### Learn - Restart required (powershell) - We need to reduce our timer, because we see it as our refactor. We maybe did not work as in a group flow. - Probably we do not explain our reasoning well enough - Might even be more important for people you do not know - We have the tendency to co-navigate, maybe we can better segregate the roles. - Limit to how far you can go with automated refactoring. There is also a limit to the patience to do it super consistent. ### Next time ideas - Try prep on account Nelis and see how far we get (give it 30 min). - Same kata for now - Shorter time for handover (3 minutes) - try to get into a group flow - Be more concious about he driver / navigator, let the driver check with the Navigator. - Multi machine setup (public events) ## 15/04/2021 Setting up a Windows Server 2019 on AWS EC2 (following script by Jay Bazuzi and Llewellyn Falco) and continuing the Refactoring to cleaner code to test out the machine ### Like - smooth switching, more than zoom or git handover +1 - Intellij made a bit easier to switch to Windows - Everything is pre-installed (except the jdk setup in Intellij) +1 ### Learn - Mac to Windows, you lose all the automatism with the keyboard - terraform is not waiting for the powershell script - basic possibilities terraform ## 29/03/2021 Setting up a Windows Server 2019 on AWS EC2 (following script by Jay Bazuzi and Llewellyn Falco) Nelis, Matteo, Saket ### Like - Liked the Jay/Llewellyn script, it's just one command in the end. +2 - Liked the scripts on github raw. It's an ingenious way of running things without having to clone. +2 - It works. It's exceptional that it works. +2 ### Learn - Jay and Llewellyn started from a manual approach and then went towards automation. +2 ## 25/03/2021 Refactoring to cleaner code - java version of session of Falco and Jay Nelis, Matteo, Saket ### Like - Meaning of concepts + variables names. Big steps without understanding the code. Now start to understand. - Discussion about same level of abstraction and make algorithm visible. - Small steps (roll from inner to outer) +1 - Notation for commits makes us more aware of the size of the steps. ### Learn - Extract parameter object +2 ## 15/03/2021 Refactoring to cleaner code - java version of session of Falco and Jay Nelis, Matteo, Saket ### Like - Side track looking to the page (ArlosCommitNotation) - Discussed with context where notation is usefull (ArlosCommitNotation) +2 - Switched (better then last time) ### Learn - Static to non static refactor in IntelliJ +1 - Provable undo as safe refactor +1 - Sharing on zoom does not work very well, especially the keyboard gives trouble. ## 07/03/2021 Refactoring to cleaner code - java version of session of Falco and Jay Nelis, Matteo, Saket ### Like - Back to chatting - Trying to follow a new way of refactoring that we do not understand. ### Learn - No gitduck +2 - Instructions are less clear without the voiceover - Go from C# to Java makes it harder to reproduce - Boring switching (such small forced steps) +2 - Setup of environment is key to automate repetitive tasks (e.g. automated tests always runs) - Prepared just right - Convention (r-) seemed usefull in the session, maybe less afterwards. ## 28/1/2021 Playing with a Pact implementation of wallet and signup service in ruby Nelis, Matteo, Saket ### Like - We fixed the rubocop remark by doing something totally different - Switching goes smoothly - 15 min rotation worked well - Asked to express intent before giving instructions +1 ### Learn - Expected to_json would be easier in Ruby (but it wasn't) - Don't ignore/reflect and think about tool messages - Don't need a branching tool - We don't really need mob.sh tool to switch (the main added value would be that it provides an easy structure for branching, switching and timing without you having to think about it) - Switching projects frequently makes it difficult to follow at times (Saket) - Matteo didn't touch the keyboard: is a good exercise for explaining his thought process ## 12/1/2021 Playing with a Pact implementation of wallet and signup service in ruby Nelis, Matteo ### Like - Something working +1 - Not to complex to get there - Small steps towards goal (except split controller) - Liked that person that does not know the language drives the whole session - Not mind navigating all the time (less attached to the keyboard) then a few years ago ### Learn - You have to read the documentation all the time (by convention in ruby) at least in VSCode - Rubymine provides more format - ## 8/1/2021 Playing with a Pact implementation of wallet and signup service in ruby Nelis, Matteo, Sake ### Like - Liked more then other languages / katas we did. It is a lot simpler. (S) - Navigate goes smooth - Relatively fast to setup ### Learn - Ruby gems and install - ngrok.io? cool - buildup of the app - It is easy to test the sinatra app ## 7/1/2021 Playing with a Pact implementation of wallet and signup service in ruby Nelis, Matteo ### Like - received feedback, less boring then working alone - 1 pom was enough to setup the ruby environment (understanding of ruby eco system) - Used the test to scaffold the solution before implementing it - Learn some Ruby again - Ruby has a simpler syntax, less boilerplate in the syntax ### Learn - Picture helped to explain the context of the system - Ruby is more different from the other languages then I remember - I miss the IDE, VSCode leads to a lot of typing - Default to action lead faster to the solution in mind then to continue to argue - Learning to observe a bit more before you start influencing the design and ask questions later - Static is used a lot in Ruby? Because it can be easily stubbed, everything is an object. - Where do the variables in the 'block' come from. The DSL part of ruby can make it obscure. ## 30/12/2020 What did we do? Code review of a kotlin notifier app Nelis, Matteo, Saket ### Like - Discussion and see a bit of Kotlin - Discussing about architecture styles in different projects. Interesting to see that non standard. Diverse implementation - Concrete project to talk about (concrete) - Review of existing code ### Learn - Kotlin is still more verbose then ruby - Hexagonal architecture and clean architecture - Hackmd - Gcloud - More and more confused about hexagonal architecture because all the examples are inconsistent regarding naming. - The configuration package is the place where the wiring could be (main) - Like hexagonal architecture more then clean architecture because it is a bit simpler - Domain driven design: