From 7935fa6da0a7f5cd5d95d49976b1abd725eb9af1 Mon Sep 17 00:00:00 2001 From: Milan Schwarz Date: Fri, 30 Jan 2026 15:46:20 +0100 Subject: [PATCH] typos --- README.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/README.md b/README.md index 80aa1ed..e8fa7da 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,7 @@ Theatrical Players Refactoring Kata ==================================== -The first chapter of ['Refactoring' by Martin Fowler, 2nd Edition](https://www.thoughtworks.com/books/refactoring2) contains a worked example of this exercise, in javascript. That chapter is available to download for free. This repo contains the starting point for this exercise in several languages, with tests, so you can try it out for yourself. +The first chapter of ['Refactoring' by Martin Fowler, 2nd Edition](https://www.thoughtworks.com/books/refactoring2) contains a worked example of this exercise, in JavaScript. That chapter is available to download for free. This repo contains the starting point for this exercise in several languages, with tests, so you can try it out for yourself. This repo was forked from https://github.com/emilybache/Theatrical-Players-Refactoring-Kata What you need to change @@ -10,33 +10,33 @@ Refactoring is usually driven by a need to make changes. In the book, Fowler add Automated tests --------------- -In his book Fowler mentions that the first step in refactoring is always the same - to ensure you have a solid set of tests for that section of code. However, Fowler did not include the test code for this example in his book. I have used an [Approval testing](https://medium.com/97-things/approval-testing-33946cde4aa8) approach and added some tests. I find Approval testing to be a powerful technique for rapidly getting existing code under test and to support refactoring. You should review these tests and make sure you understand what they cover and what kinds of refactoring mistakes they would expect to find. +In his book, Fowler mentions that the first step in refactoring is always the same - to ensure you have a solid set of tests for that section of code. However, Fowler did not include the test code for this example in his book. I have used an [Approval testing](https://medium.com/97-things/approval-testing-33946cde4aa8) approach and added some tests. I find Approval testing to be a powerful technique for rapidly getting existing code under test and to support refactoring. You should review these tests and make sure you understand what they cover and what kinds of refactoring mistakes they would expect to find. Acknowledgements ---------------- Thank you to Martin Fowler for kindly giving permission to use his code. -Thank you to Emily Bache for creation of this kata. +Thank you to Emily Bache for creating this kata. -How to Practice the Kata in group/mob session by GIT push/pull handover +How to Practice the Kata in a group/mob session by GIT push/pull handover ==================================== -In the following steps one from the group will fork the repo, add collaborators, each of you clone the forked repo and you can start the Kata in common Mob session! +In the following steps, one from the group will fork the repo, add collaborators, each of you clone the forked repo and you can start the Kata in a common Mob session! Fork this repository ---------------- -Fork this repository by clicking on the fork button on the top of this page. This will create a copy of this repository in your account. +Fork this repository by clicking on the fork button at the top of this page. This will create a copy of this repository in your account. ![image](https://user-images.githubusercontent.com/695210/116807686-c82d6780-ab34-11eb-8221-87b4f4e7adfe.png) Add collaborators ---------------- -Go to your GitHub account, open the forked repository, click on the _Settings_ menu item, click on the _Manage access_ and then click the _Invite a collaborator_ button. Add all the software craftsmen, who will collaborate on the Kata with you. +Go to your GitHub account, open the forked repository, click on the _Settings_ menu item, click on the _Manage access_ and then click the _Invite a collaborator_ button. Add all the software craftsmen who will collaborate on the Kata with you. ![image](https://user-images.githubusercontent.com/695210/116807745-1c384c00-ab35-11eb-923d-b11475181c06.png) Clone the repository ---------------- Clone the forked repository to your machine. 1. Go to the GitHub account with the forked repository, open the forked repository, click on the code button and then click the copy to clipboard icon. -2. Open a terminal and run the following git command: _git clone "url you just copied"_, where "url you just copied" (without the quotation marks) is the url to this repository (your fork of this project). +2. Open a terminal and run the following git command: _git clone "url you just copied"_, where "url you just copied" (without the quotation marks) is the URL to this repository (your fork of this project). For example: `git clone https://github.com/this-is-you/first-contributions.git` @@ -44,29 +44,29 @@ For example: ![image](https://user-images.githubusercontent.com/695210/116808298-5525f000-ab38-11eb-808c-f0070253e89d.png) -Practice the Kata in common Mob session +Practice the Kata in a common Mob session ---------------- -1. New driver pulls all the previous changes and start sharing his screen +1. The new driver pulls all the previous changes and starts sharing his screen 2. You enjoy the mobbing -3. When limit is done, the last commit is created +3. When the limit is done, the last commit is created 4. All commits are pushed to the common repository -5. Drivers are switched and new driver starts with the point 1 (pull + sharing his screen) +5. Drivers are switched, and the new driver starts with point 1 (pull + sharing his screen) Get feedback on your Mob session ---------------- * get feedback on your code -> just create a Pull Request (or send a link to your public repo with all the changes) and contact us -* get feedback on format of the session -> just contact us and describe, how we can help you +* get feedback on the format of the session -> just contact us and describe how we can help you **Contact info:** * Milan Schwarz -> milan.schwarz@gmail.com Best practices ==================================== -* Do as small as possible commits, so you can easily revert the changes if you go a wrong way anytime +* Do commits as small as possible, so you can easily revert the changes if you go the wrong way anytime * Switch Driver regularly -* I recommend to start with 7 minutes for switch a Driver (and experiment with that during the next session) +* I recommend starting with 7 minutes for switching a Driver (and experiment with that during the next session) * Experiment with navigators (e.g. just one can navigate or everybody navigates) -* Have a fun and learn something new from others! +* Have fun and learn something new from others! -Do not hesitate to mention your activity and provide link on your code during job interview in YSoft! +Do not hesitate to mention your activity and provide a link on your code during a job interview in any company! ====================================