To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/DreamsofCode . You’ll also get 20% off an annual premium subscription.

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.

> 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.

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!

i feel like this video was made just to show off the keyboard with the amount of shots the keyboard was in

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.

I thought TDD stood for "try driving drunk" and I thought, why would anyone do that? now I know, its way better

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.

@dreamsofcode You need to introduce us to your Moonlander. I wanna know everything. Your cables (Kingscables?). You modifications. Your platforms. Spill the beans! :D

"Wake up babe, new dreamsofcode vid just dropped!"

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 :)

absolutely love the way you describe how you're using tools like when you specficially said telescope. It's very helpful.

I feel like it doesn't make any sense to run the spinning wheel in parallel because it doesn't give you any information about state of the main thread. The spinning wheel should have been incremented after every operation in the main thread so user can see if the main thread is still doing something.

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

I love this format, being along for the ride and trying to guess what’s coming next is so fun

really nice well explained and edited video. will be surely applying that pattern in my next go project

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!

Great video as always, but finishing the spinner and then using git to store the code instead of actually using the vcs and committing in the red, green, refactor process would have been a better way of utilizing git

With the amount of money Brilliant has spent to shout at me from yt videos, I feel at some point I will be obligated to try them.

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!

Nice video to see some real world examples for go programming. Thanks Elliott! Also, I really like your dotfiles and nix config :), I hope you will do a Video on that topic soon, I had some major mental breakdowns settings up nixOS ^^

One way to avoid having to handle so much edge case logic is to implement 2 types: Spinner and StartedSpinner. Spinner only implements Start() and returns a StartedSpinner. StartedSpinner only implements Stop() and returns a Spinner. By implementing this way, you eliminate the edge cases entirely, since the consumer is physically incapable of creating invalid code.

The package with the keep upright sign exactly up side down is my kind of humor

the timing of this getting uploaded while i had your CLI stream playing on the background haha

This is like fizzbuzz enterprise, except the irony is gone.

0:42 wow that wallpaper is absolutely amazing, where would i be able to find it?

Great walkthrough, if not one of the best on how writing test driven code works!

Oh I love that you opened with a shot of your gear on your desk !

I think the most important part of TDD and writing just enough code to get the test to pass, is to make sure the test is sophisticated enough to ensure the added code isn't just trivial or hacky.

Very nice but I have a few small critiques with how you used some of the go primitives. Typically the context is passed in at a higher level outside of the component or you return a cancelFunc when running start/init. This moves all the power to the caller which is a good thing when concurreny is involved. Same idea goes for the stop function. You typically shouldn’t use the ctx cancel function here because you have all the struct data and can clean it up / stop it yourself. Just use a doneCh and then you don’t even need to bother with mutexes. Overall stuff like this is an excellent way to play around with the concurrency primitives. But sometimes it’s simpler to use one of them instead of all of them.

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?

I feel like there are too many subjects in this video: how to make a spinner (and why some things don't work), how to do tests, and how to do all the details in Go. I was interested in the spinner-aspect, but was completely overwhelmed by the Go-stuff (don't know the language). The test-concepts you touched on were also interesting, and could deserve a more higher-level video. In the end, I don't know what I saw you all do. You shared a story about how you struggled and succeeded coding something, but I don't really know what were the exact problems were with the spinning aspect, and how you solved it. I would love 2 more videos about the spinner and the test, where you go talk more abstractly about those subjects (no/minimal programming-language used), because I'm really interested in both!

Nice video as always ! I worked with Go daily at my job for 2+ years and I personally wouldn't use a Context in such a case. Contexts are nice when you need to propagate state and cancellation events through a chain (or a tree) of related function calls. If you only need the cancellation part, just use a channel (that's what Contexts use under the hood anyways). The same advice applies if the thing you're trying to achieve has a small, well defined perimeter (like a single struct in your case). You could also get so your spinner to stop properly with a single channel, I wrote a simple example for those interested: package main import ( "time" ) type foo struct { stopCh chan struct{} } func (f foo) start() { tick := time.NewTicker(time.Second) go func() { for { select { case

amazing video, but the fact that you only made a single git commit at the end made me shiver :D i prefer small commits, even if they are work-in-progress - gives me peace knowing i can always revert back and branch out and etc. safely, and no work is lost

I understand it meant to be an educational video about TDD and how to approach to coding projects, but it's a lot of code for such simple task. It's basically few lines of code in any verbose scripting language.

this is a cool introduction to golang's concurrency pattern

Great video, I know nothing about Go but I would definitely recommend moving the git step to the start!

Thanks for taking us on that journey. going back to paper is shown seldomly and jet so effective. When you ended with "now I did git init" I was a little surprised. Every time you hit "green" and after each "refactor" my brain did a "git commit -am '!sqash init'" Maybe I'm just too bad at rolling back my changes manually or maybe there is something I'm not seeing. Could you explain why you did the init at the end and not at the start? (esp. no commit after each step)? thanks again =) edit: Already answered in another comment: Git was added as an afterthought.

Thanks for the look into a cool project, and a great intro into TDD :D

Thank you, I followed you along, it was a big fun for a Go-newbie. couple of moments: 1) it didn't work for me on FrameRate 20 - it was too unstable. It wrote at about 30ms rate. 2024/07/03 18:55:52 Before Start 18:55:52.834 2024/07/03 18:55:52 Writing frame: - at 18:55:52.835 2024/07/03 18:55:52 Writing frame: \ at 18:55:52.865 2024/07/03 18:55:52 Writing frame: | at 18:55:52.897 2024/07/03 18:55:52 Writing frame: / at 18:55:52.928 2024/07/03 18:55:52 After Stop 18:55:52.943 tests are ok on FrameRate 200 for me. 2) once you use s.Stop() just before defining it, which is a bit confusing, but ok

I need to know your whole OS Setup

Would be nice to see a video on configuring NeoVIM for java

Seeing you and primeagen flaunt their ergonomic keyboards is temping me to check one out (although mechanical keyboards are a little bit overrated imo), so what keyboard is that?

Ok, I'm a total noob and didn't understand why you used such complex (for me) ways to accomplish a spinning cursor that can be stopped. So I started writing this my way with as little code as possible just to make the visual spinning the same as yours. Then I adopted the concepts that I, more or less understood and made the spinner struct, constructor, and composite option. Because I didn't know anything about the context package I didn't want to use it. So I made a label to get out of my ticker.C loop. Now I had it almost working. I had spinner start, spinner stop that both worked and looked visually the same. But for a reason that is still not clear to me, when I used: case

This might be the first time I've ever left a comment on a video having only watched 15 seconds of it but... This is one SICK Moonlander setup. Makes mine look like a scrub made it...

I have to admit, I've never written a spec of go, but I still learned a lot from this video! Keep it up, @DreamsOfCode

This is a really good demonstration of TDD, although my one complaint would be that the first test should have been written once you’d come up with the design but before implementing anything, even if you were calling not yet defined functions.

Nice vid! Wonder if there's a way of mocking the ticker in order to not have to sleep in the test.

Nice work. Showing the final spinner a few more seconds would be appreciated, though.

Great video!, it would be cool a video about programming books/resources recommendations

Love the new filming style!

This was a blast to follow

What is that keyboard you are using? 0:20

I had once tried to do so in python at the start of my career to have a visual indication of process running. My god the multithreaded implementation it required had my head spinning like the progress bar. I quickly discovered tqdm and stopped pursuing implementing what's already out there

If there are multiple threads in the application than the Start funcion is racy with itself. The spinner can be started twice at the same time, e.g when both execution contexts (threads) check isRunning and loose the processor right beforr the s.lock.lock(). After that, the code inside (and after) the lock, which includes starting and configuring the Spinner, is executed twice. To fix it You can just add a check isRunning -> return when you already have the lock acquired. Edit: commas PS: I am not familiar with the golang execution model (can there even be multiple threads?) so this comment only applies if multiple execution context can call (or rather execute) the same function on the same object at the same time.

Loved the video and the showcase

your keyboard looks cool! which model is it?

liking this video format a lot

"ctx" being used for "context" is such a hard thing for me to internalize as my work has burned ctx to mean Citrix and I hate it

I feel like this is an example of why tests are not as important as actually making sure your code runs as expected, as you're writing it -- even though your tests passed, there was still a serious bug in your example implementation. The tests could have been added when they were necessary; instead, you arguably spent more time fiddling with tests, rather than iterating rapidly on a solution to the bugs that would've appeared, simply using your example implementation. I'm in favor of the approach: get it working as expected, refactor (or rewrite), write tests, fix any edge-cases, write final tests.

For the configuration I would've used Functional Options pattern instead of having a config type.

You explained TDD better than my professor at college ❤

Great video on TDD. I feel the "context" approach is a bit complicated for this kind of project. Btw what kind of cable are you using to connect your moonlander? - looks nice and practical

What's the model of your keyboard ?

Wow the presentation is soo good

oh you mean a "throbber" ? that's what it's called. gl with this info.

Which window manager are you using?

What about the Start->Stop->Stop edge case

Very interesting. Thank you.

Client: I want a nice spinner to show feedback when something is loading 🤔. PM: Easy peasy, you’ll have it by this afternoon 😎. Developer: Absolutely, no problem 😏.Two weeks later...Developer: Here's the loading spinner 🥺Client: But… it crashes on loading for edge cases 😟. PM: Wait, what? 😳 Developer: Yeah… and it only works on certain terminals 🤕. Client: This is not what I asked for 😤. PM: We’ll fix it, no worries 😬.Developer: Thinking "Okay, let’s refactor. Time to implement TDD, use coroutines, manage contexts, and handle asynchronous implementation..."Several weeks of complex development later...Developer: Alright, I think I’ve handled all the edge cases. Here’s the spinner 😓.Client: Great! So it shows loading feedback on all terminals now? 😊. Developer: Yes, and it also handles various edge cases, different environments, and integrates smoothly with the entire system 😤.PM: Fantastic, well done team! 🎉Client: Perfect, now could we add a color change when it loads successfully? 🌈Developer and PM: 😳😵Spinner: still spinning in the CLI "I tried my best 😢🌀."

what keyboard is that?

Best anti-TDD video I've seen so far

What keyboard are you using?

the fact that the commit came after the app was done... Do we all do that?

I already hear my ex-colleague screaming and calling meeting because this is not how you are supposed to do TTD. You need to follow enterprise patterns as laid out in 5 academic papers he kept quoting.

New keyboard ????

@dreamsofcode can you make a video on youe terminal and how we can make one of our own? Im a student and i am sure toms of other students dont know this stuff, the very little makes it confising how to do such stuff

Great video as always boss

I did not get the last part about making the spinner thread-safe. In the Start method the locking is done around context creation and done channel instantiation. So if the Start method is called simultaneously from multiple goroutines they are going to skip over isRunning check and then create same context and done channel. I would wrap the isRunning check in with a lock because I do not see how the spinner can be used from multiple goroutines. Am I missing something?

Great video!

Cool wallpaper!

Ngl, at first i thought you were on a cockpit, then realised it's just your setup....

I'd love to be a CLI designer. I have ample experience in MUD coding. But alas it's not an actual job

Well explained video. Can you share your tmux config?

i rly love the start window animation. Is that a copmositor or just video editing?

17:25 Wait, only setting up VC _now_? Every time you switch phases in TDD, you should be creating a commit.

Hi I would like to learn how you make your videos. Can you guide on what tools and softwares you use?

What theme is that?

"Little bit confused" we have all been there..

It's called a throbber

they're also called throbbers, fyi :))

while the presentation is top notch, some minor complaints about the TDD shown here: - lots of code written before the test - test tests implementation details not behaviour/intent(which should drive the design) - you skipped the red in red-green-refactor altogether tdd should drive the design and not be a implementation validator. as a result you should end up with a better design that is as a side effect also easier to test. so tdd should be better called test driven design imo. do not want to sound overly pedantic here but i reread "tdd by example" recently, so it was fresh in my mind.

it would be interesting to see this done in haskell

Is that a moonlander? How are you finding it? I’m using a custom kyria split keyboard at the moment and keep eyeing up the moonlander 😄

Curios to know how long the entire process took though 😅

Where do you show the visual of what you coded/were trying to code?

It's called a "throbber" not a "spinner". 😂

Hi Can you give me the link to the keyboard you are using.

one of the worst cases for tdd (graphics is prob worse). you can just visually check if it spins correctly, but you can't check that the sequence you wrote to buffer renders as expected in the terminal.

should of just added a jif