Really loving this! Thank you! Tried practicing it the other day. Two hangups I've been trying to figure out that I would love to learn the answers to: 1) for envs/workflows that don't support or encourage tests in the same file, do you need to abandon TCR on autosave or are there strategies for approaching that? 2) what does your workflow look like before you push to a remote repository? rebase and squash with a useful commit description? Hopefully I will learn the answers as the series continues :)
I don't see how things would be much different. This was basically a micro example. You should simply execute a different script (ie. your tests). If any of those tests fail then your version control system should reset your (local) version to the previous. That should reset every (changed) file in your project -- which should just affect the one your working on, ideally. Rebasing and squashing and whatnot seem much more like project-specific choices. One could utilize TCR regardless of upstream tools & policy. It's probably most appropriate, in general, to squash & rebase when pushing upstream. Ideally, upstream commits are atomic (not micro) and can be described as a specific feature or a specific fix -- not just some random, unnamed commit, of course.
This is the first time i have seen code that calls / returns a subclass instance from the base class. I don't know why but that never crossed my mind as a valid option. I like how the code turned out and I can see this approach being used for complex builder classes.
So much brilliant suggestions from Kent Beck get - CRC cards, design patterns, XP, Agile SD, TDD .... Is TCR his new stroke of genius? We'll see in a few years ;-)
This technique makes you move in very small steps and it is very productive. But I'm confused about working with repository. If you make real commits after each small change, it will become impossible to track the history of the repository or apply Conventional Commits. In the video, commits were created for each save. What if we do `--amend` after each save, and when there are enough changes, then give this commit a name, push it and create a new one? If we make hotkeys, it will help solve the problem without increasing the step
I just wanted to say THANK YOU. I have been playing with TCR for a week and I love it! It really gets me into flow. However, for compiled languages it is a bit tricky. My strategy so far has been to write a generic test that consumes a test case in json, so that once the test is compiled, I can add test cases under a TCR loop. Any thoughts?
I didn't know he's a TH-camr. I imagined him as a retired wise man.
This is interesting, I should try it.
Really loving this! Thank you! Tried practicing it the other day. Two hangups I've been trying to figure out that I would love to learn the answers to: 1) for envs/workflows that don't support or encourage tests in the same file, do you need to abandon TCR on autosave or are there strategies for approaching that? 2) what does your workflow look like before you push to a remote repository? rebase and squash with a useful commit description? Hopefully I will learn the answers as the series continues :)
I don't see how things would be much different. This was basically a micro example. You should simply execute a different script (ie. your tests). If any of those tests fail then your version control system should reset your (local) version to the previous. That should reset every (changed) file in your project -- which should just affect the one your working on, ideally.
Rebasing and squashing and whatnot seem much more like project-specific choices. One could utilize TCR regardless of upstream tools & policy. It's probably most appropriate, in general, to squash & rebase when pushing upstream. Ideally, upstream commits are atomic (not micro) and can be described as a specific feature or a specific fix -- not just some random, unnamed commit, of course.
This is the first time i have seen code that calls / returns a subclass instance from the base class. I don't know why but that never crossed my mind as a valid option. I like how the code turned out and I can see this approach being used for complex builder classes.
So much brilliant suggestions from Kent Beck
get - CRC cards, design patterns, XP, Agile SD, TDD ....
Is TCR his new stroke of genius?
We'll see in a few years ;-)
6:40 - six lines are little too much to risk !
This technique makes you move in very small steps and it is very productive. But I'm confused about working with repository. If you make real commits after each small change, it will become impossible to track the history of the repository or apply Conventional Commits. In the video, commits were created for each save. What if we do `--amend` after each save, and when there are enough changes, then give this commit a name, push it and create a new one? If we make hotkeys, it will help solve the problem without increasing the step
You could do that, or squash before merging, or just go straight to production.
That's a whole lot of new tricks just to get TCR working. Someone needs to write those up!
Check out the next video
I just wanted to say THANK YOU.
I have been playing with TCR for a week and I love it! It really gets me into flow.
However, for compiled languages it is a bit tricky.
My strategy so far has been to write a generic test that consumes a test case in json, so that once the test is compiled, I can add test cases under a TCR loop.
Any thoughts?
How long are your compile times? I just recompile at each "test" run.
First time I see TCR, I need to try it, seems to be really funny. It really force you to think carefully.
Did you share the way you automate that in further videos? git hooks or something like that?
What editor is he using?
VS Code