@CielMC
> Im gonna use TDD - Test passes - Had to run the app anyway to find problems I feel like this the main problem with TDD, you can’t anticipate problems you don’t know, so you necessarily has to break it manually first, at which point I don’t see how this is different from just writing tests and writing regression tests. TDD feels like fighting yourself, “do the minimum to make the test pass” okay, just print a backspace in the stop function. But you know damn well that’s not what you want to do, why not just do it the right way to begin with? And in addition to that, the test themselves have no guarantee of being right, as you have shown in your video, what now, write regression tests for the tests? Tests are just code and code will fail. This is what I don’t get about TDD, it seems to add so much unnecessary overhead and fluff. I support writing tests for every functionality, even during the development process and not just after it, but I feel like TDD is just not it.
@luengelke
Nice walkthrough of TDD in Go! To be nitpicky: your frameRate should correctly be called frameDuration. "Rate" implies a number of frames per unit time, so the inverse of your value.
@mementomori8856
I love that you added how you came up with a solution and also the ones that didn't work and why they didn't instead of jumping to writing the working solution!
@chadyways8750
i feel like this video was made just to show off the keyboard with the amount of shots the keyboard was in
@sweetbabyalaska
I learned Go entirely self-taught from reading source code on Github and I've picked up pretty much all of these conventions and patterns, but I was unable to put a name to any of it. This video helped all of that finally click.
@the_primal_instinct
Wish there were more detailed videos like this one. Usually development project videos describe the process the author went through in very broad strokes. On the other hand, development streams being unedited makes it very inconvenient to watch them. The format you're going with is the perfect one.
@typecraft_dev
I thought TDD stood for "try driving drunk" and I thought, why would anyone do that? now I know, its way better
@threee1298
I love this format, being along for the ride and trying to guess what’s coming next is so fun
@a_maxed_out_handle_of_30_chars
I had always wondered about the loading animation and now I've a good idea about it's working. Will try to implement it at some point. Thank you :)
@noisetide
What is that keyboard you are using? 0:20
@socks5proxy
absolutely love the way you describe how you're using tools like when you specficially said telescope. It's very helpful.
@Redyf
"Wake up babe, new dreamsofcode vid just dropped!"
@1ups_15
With the way you've implemented your spinner, what happens if you write to the stdout while the spinner is spinning? Won't it disappear and replace the last caracter that was output?
@rafaeltab
Seeing all the mistakes, and the iterative approach to TDD really helps. When I do TDD I write all tests first, then write all implementation, but writing a test first, then writing a piece of the implementation might actually work better. Ill give it a try!
@ustav_o
really nice well explained and edited video. will be surely applying that pattern in my next go project
@synnveolsdatter-bh9qc
The longer I watch the more I want your vimrc 😅Nice video! My dad keeps recommending Go to me and it looks fun so I might give it a try, the pacing and really everything about it make it really nice to watch as well!
@JohnoScott
Oh I love that you opened with a shot of your gear on your desk !
@ScriptCoded
Great walkthrough, if not one of the best on how writing test driven code works!
@Tresla
You could also return a "done" channel from "Start()", which would be closed in a defer inside the work goroutine. That way, you can still use context, but you can wait on the returned "done" channel for work to be completed, after cancellation, before continuing. I much prefer this way, as it doesn't require any state, and can be implemented in just a regular function. No need to have it be a method on a struct. It's also easier to avoid race conditions (because of the lack of state).
func DoWork(ctx context.Context) (done <-chan struct{}) {
doneCh := make(chan struct{})
go func() {
defer close(doneCh)
for {
select {
case <-ctx.Done():
return
default:
// Do some work
}
}
}()
return doneCh
}
@dreamsofcode