Clean Code - Uncle Bob / Lesson 4

↓↓ ENGLISH DESCRIPTION ↓↓
"Coding Better World Together" is a set of master lessons from the famous Uncle Bob (Robert Cecil Martin), where he gives us a broad vision of the importance and future of Software in today's society.
In this fourth lesson, Uncle Bob introduces us to a software development methodology oriented through testing. This is the Test-Driven Development (TDD), a practice with a long learning curve, but with significant results to generate a more robust, safer, more maintainable code and with greater development efficiency.
Among other things, Uncle Bob shows us his point of view about the evolution of software to this day and its bright future.
↓↓ DESCRIPCION EN ESPAÑOL ↓↓
"Coding Better World Together" es un conjunto de lecciones magistrales del famoso tío Bob (Robert Cecil Martin), donde nos brinda una visión amplia de la importancia y el futuro del software en la sociedad actual.
En esta cuarta lección, el tío Bob nos introduce en una metodología de desarrollo de software orientada a través de pruebas. Se trata de el Test-Driven Development (TDD), una práctica con una curva de aprendizaje prolongada, pero con resultados significativos para generar un código más robusto, más seguro, más mantenible y con una mayor eficacia en el desarrollo.
Entre otras cosas el tío Bob nos muestra su punto de vista acerca de la evolución del software hasta nuestros días y de su brillante futuro.
0:00 Opening.
0:51 Honest Estimates / What is the chemical formula of water?
7:16 Selection, Secuence and Interaction / No innovations have been made in the software for decades.
13:48 The Hardware has gone crazy!: comparison between the innovation level of hardware and software today.
17:33 You to say "No".
21:40 Test-Driven Development / TDD rules.
36:14 Our code is a document / Double entry Bookkeeping.
40:22 About inheritance / Mutation Testing.
43:48 Demo of Test-Driven Development.
1:12:23 Some tips to learn and practice Test-Driven Development.
1:15:03 Questions and Answers.
↓↓ OUR MODEL OF SOCIETY ↓↓
- mutualwelfare.org
↓↓ NUESTRO MODELO DE SOCIEDAD ↓↓
- bienestarmutuo.org
↓↓ OUR CRIPTOCURRENCY FOR MONETARY FREEDOM - NUESTRA CRIPTOMONEDA PARA LA LIBERTAD MONETARIA ↓↓
- unitycoin.net
- PRESENTATION: unitycoin.net/presentation/
↓↓ OUR PAYMENT FRANCHISE - NUESTRA FRANQUICIA DE PAGOS ↓↓
- sbmlibre.com
↓↓ OUR SOCIAL PACT - NUESTRO PACTO SOCIAL ↓↓
- e-nation.org
- PRESENTATION: e-nation.org/presentation/
↓↓ OUR SOCIAL NETWORKS - NUESTRAS REDES SOCIALES↓↓
- Facebook: / unitycoin
- Twitter: / unity_coin

[@jaymandell6034]

I wish they would show the screen as he's writing/talking

[@abstractapproach634]

Totally agree, in one of the earlier ones he was asking for an analysis and instead of showing code it showed uncle Bob drinking water?!

[@TranscendentBen]

H2O. :)

[@gajbooks]

Again, captured from a livestream quite clearly. Blame the people editing the capture on-site, not the channel.

[@abstractapproach634]

@@gajbooks i don't see where anyone specified who's at fault.

[@gajbooks]

@@abstractapproach634 I've seen some other comments actively disliking the video because of this, which they have every right, but... Come on. I listened to this series as a podcast and lost no information.

[@FranciscoMNeto]

Beautiful lecture, abysmal editing.

[@aimafirm]

With all the comments everywhere on youtube, it can't possibly be that hard to realize that one should show the code being written and not the presenter.

[@maxfun6797]

Tbh, you don't need to see the code to understand the subject.

[@ryanvogel5895]

@@maxfun6797 You do need to understand the subject to edit the video. You might not need to see the code, but others might need or want to.

[@ugochinwokonko4373]

@@maxfun6797 Ǹj

[@yapayzeka]

this dude is legend

[@mahdimotamedi6812]

Yes Really I Want to meet him One Day

[@PaulSebastianM]

Reminds me of George Carlin... Another legend. The George Carlin of software comedy.

[@wolverine9632]

"Hey, this video isn't syncing properly with the audio!" "Can't you just scale the video to match it?" "Nah, I'll just cut out parts every now and then to resync it."

[@camilohernandezruiz2776]

I just replicated the example in Dart. I learned a couple of things: 1. You must have an intermediate level of using the language. 2. Every testing environment is pretty much the same. Still, the conventions used by the Dart test library and the different Exceptions-related objects are different than those used in Jest, so you gotta know them all as well. 3. The KISS principle is the most important one. Don't advance too much further, every time you write something, run the tests. Keep refactoring and running at the same time until the all tests pass. This is the moment when you use all your brain. I also collected every tip/rule Uncle Bob explained about TDD in this video: 1. You are not allowed to write any production code until you have first written a test that fails because the production code doesn't exist. 2. You are not allowed to write any more of a unit test than is sufficient to fail - and not compiling is failing. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. 4. Engage as few brain cells as possible, you will need them later. Keep it simple! (KISS) Don't do too much too fast. 5. Try to avoid the core (the golden behavior) of the problem until it is unavoidable. Save the most important feature of it for as long as possible. 6. If you think some code you just wrote is a wrong solution... prove it! Put it to a test. 7. You are not allowed to make the production code more specific than the tests. The tests and the production code must move in opposite directions. Every new test you add makes the test code more specific, more constrained. Everything you do to the production code must make it more general.

[@unitycoin_original]

0:00 Opening. 0:51 Honest Estimates / What is the chemical formula of water? 7:16 Selection, Secuence and Interaction / No innovations have been made in the software for decades. 13:48 The Hardware has gone crazy!: comparison between the innovation level of hardware and software today. 17:33 You to say "No". 21:40 Test-Driven Development / TDD rules. 36:14 Our code is a document / Double entry Bookkeeping. 40:22 About inheritance / Mutation Testing. 43:48 Demo of Test-Driven Development. 1:12:23 Some tips to learn and practice Test-Driven Development. 1:15:03 Questions and Answers.

[@abstractapproach634]

You can tell your a programmer, you spelled sequence wrong. I think, unless I'm missing something.

[@-parrrate]

"Secuence" -- Sequence "Interaction" -- Iteration

[@GauravSehrawat8888]

Probably pin this comments?

[@JavierRuizGonzalez]

Don't you love when a lecturer shows that they are able to actually put the theory in practice? Also, you can feel how knowledgeable is a guy by counting the number of times he mentions other colleagues. Thanks for these sessions, to the organizers and to the editors!

[@robrick9361]

Yes cause implementing a stack is super difficult. Pushing and popping can be confusing, they both start with p, super difficult to get right.

[@HeikkiKetoharju]

This was the best demonstration of TDD I've seen to this day. Really inspiring!

[@TheChillBison]

Here's another good one: kzbin.info/www/bejne/aJOUp5adlL2GiJo

[@devincustodio2258]

dear uncle bob, youve been an amazing source of happiness since i discovered you last week

[@CPalanysamy]

This video made all the difference when it comes to understand TDD. Thank you uncle Bob

[@jamesnewton6139]

to Uncle Bob: amazing lecture, these principles are absolutely required, to produce good code. however, to make this a 1000 times better, if you have the power and see this, get the video editor to re-edit and show the code. Extremely frustrating to watch you talk about details of code and write something, but nobody can actually see it.

[@georgestampolidis9511]

Revisit this a year or two later

[@ivangloff]

What do you mean? It’s still frustrating. The demo at 45:30 is a good example.

[@ivangloff]

@@a.luckyy The contents of what is not being shown is irrelevant.

[@ivangloff]

@@a.luckyy It isn't, otherwise I would not complain. And it is not relevant. Nice that you hired a producer. Next time hire one that will do the job properly.

[@GongonHD]

Some of my key take-aways: Avoid switch statements that cause a lot of dependencies. (That might hurt the open-close principle) A function should only do one thing. This means: when you can seperate a part of the function into another function it does more than one thing. By doing this you do not get a sea of lots of tiny functions because you will start to properly name them, put them into classes and modules automatically. Variables likes 'isWebPage' that say what the content of the var, are great. Making the code work is only half of the job. Refactoring so it is clean and easy for others to read is the second half. Programmers are slowed down by needing to understand others code. And if it is not clean and easy to understand this really piles up. Clean code does not pay off in the short run but definetely in the long run.

[@wolverine9632]

There's so much invaluable information in these lectures. Test-driven development was a completely foreign idea to me, but interestingly, when it was first mentioned in Lesson 3, my brain clicked and I _sort of_ saw it inside my mind. I was thinking of the fact that I always have introduced new structs/classes by definition first, followed by implementation. My reasoning was that, "If I design the blueprint first, it will be easier to implement." But I realized this is backwards from what it should be. I should attempt to create an instance of the object, and when that fails, then and only then should I add a declaration for the class. Now I add a call to the non-existent member function, and only after it fails to compile do I implement the function. This way I will automatically develop the class interface in the way that makes the most sense, adding everything as needed, rather than creating an entire implementation before realizing that interacting with it is a real chore. Turns out, this isn't exactly what Uncle Bob meant, but it's well on the right track.

[@headoverbars8750]

Man... I struggled to wrap my head around this discipline until the demonstration. I have seen many demos but non clicked like this. Game changing Book/Series the demonstration for TDD was icing.

[@TheInimicus]

I watched this lessons 3 times now, and everytime I learn something new.

[@rushi7312]

During previous videos of the talk, I was very attracted by the idea of testing everything you do. But as a beginner programmer this was really overwhelming lol.

[@GerbenWijnja]

I like to think of this flow of test driven development as continuously proving that there are bugs. Prove that's there's a bug (a.k.a. missing or broken feature) with a test, then fix it. Then prove another bug, and fix it. Until you can't think of any other bugs.

[@igorbolotnikov975]

Very nicely put!

[@Matheus.Richard]

Which resembles the previous talks where he talked about science proving things.

[@hanswoast7]

@@Matheus.Richard Yes and no. Scientific hypothesis cannot be verified or proven, only falsified. But if you fail to falsify them in a myriad of ways, you can assert these hypothesis "good enough". That's when a scientific hypothesis receives the great honor to become a scientific theory.

[@Matheus.Richard]

@@hanswoast7 that's what I was refering to. You can't prove your code is 100% right, only that it isn't wrong.

[@alext5497]

@@hanswoast7 that seems to translate to code fairly well. I don't see the contradiction

[@moganmark]

An absolute legend, thank you for posting

[@samuellourenco1050]

Loved the way he wrote a correct code just based on tests and expected behaviour.

[@manishm9478]

My teammates are all exceptionally good at debugging. It took me until I was 10 months into the job to realise this was why I'd had so much trouble trying to do TDD, or pair programming, or continuous delivery - the code was too monolithic and tightly coupled for TDD, and the team had grown so used to this they just gave up and debugged everything. I fully agree with Bob that debugging is not a desirable skill for a developer, because by the time you need it you've already failed to engineer a good system.

[@milanmidzovic6841]

I don't know anything about programming but I enjoy his lectures.

[@fluffydeveloper]

44:15 Bob: *singing* The subtitle: don't eat it eat it eat you know

[@Sinebeast]

Those digressions at the start are really cool :)

[@OleguitoSwagbucks]

44:16-44:19 Video Editor that did that cut, thank you so much, I love you

[@BenjaminBK]

Seriously, the "director" responsible for choosing the scenes for this whole task deserves a raise. Either he is a genius and does not show us what Uncle Bob shows on the screen, so the YT viewer starts to think "what should I see" and starts using their brain, or he is so occupied by his sidejob he has to do while this is recorded that he fucks up that much. If none of this is true, get him a new job and find someone who has more than two braincells and does not put uncle bob on view while there is something shown on the projector

[@mechpeanut]

I think the reason that the test driven development, at least how uncle Bob demonstrated, requires multiple iterations of - fail the test, intentionally make a buggy implementation to pass the test, and add more tests to make it fail again - multiple times is to strengthen the quality of tests first until the code owner reaches to a point where the owner truly believes a buggy implementation is no longer capable of fooling the tests. Then the rules allow the owner to write real production code to make the test passes. At this moment, what we end up with is a strong test suite that can significantly boost the development velocity all the way down the road. And I believe that's the spirit and rationale behind the scene. (Thoughts popped in my head at 1:04:44)

[@mechpeanut]

On the other hand, the problem with this approach is that it cannot be measured. If it cannot be measured, it can only be promoted from a cultural perspective. And if we do that, most likely this is ineffective because it does not scale. Why does it not scale? Because we cannot provide automation support (CI/CD) for unmeasurable thing. So at the end of the day, this principle is probably gonna be something that we can only keep it to ourselves. But still, a very interesting testing methodology indeed!

[@lionelleroux1132]

I would love a pair programming session with Uncle Bob

[@prajwalpradhan661]

He really got me interested in TDD.. What a great lecture.. Thank you so much for this

[@Name-lt2tz]

after I tried tdd, I am interested in it only in few cases. In most of cases from my experience it is waste of time. Code changes so much, you do not even know how it should work, and for everyt thing need to write tests and throw them away once you find that way written code will not work. For writng stack class as he did, maybe it is ok. BUt how often we write simple things like this? Most of the time things are so complicated so thats why we do not even know if this will work.

[@Dethas1991]

@@Name-lt2tz That's why you need a clean code, to create correct abstractions that are easily testable. Every complicated problem can be deconstructed into few simple ones.

[@harpywraith9017]

My favorite stand-up comedian

[@StefanH]

The problems I have with testing code is once you start interacting with other systems. GUIs are probably the most common example, but as soon as you start interacting with other people's APIs, it becomes increasingly harder to test. The best solution is to mock those external APIs in your unit tests, but it's way harder to do that, and try to emulate their backend. It's by no means impossible! I just find that the most difficult bit when I write code, which often interacts with other systems.

[@Qrzychu92]

For that there is a solution, but beware, we are slosing in on CorporateFizzBuzz :) You put an abstraction over the external system. In your unit tests, you mock the abstraction. You test the abstraction with integration tests, or even system tests against a real system.

[@Sahuagin]

that's cool how being "stupid" on the implementation side forces you to come up with more creative tests

[@Dalendrion]

It kind of makes me think of emergent behaviour. Many agents with stupid simple rules, working together, result in some emergent behaviour. Boids have three rules. I call them attract, avoid, align. And they start behaving in interesting ways. Tests also have three rules. Arrange, act, assert. And as a flock, they too have some interesting behaviour.

[@TheNewton]

Some good meme material in this series like his coder stance jutsu.

[@jackofnotrades007]

Man, I wish I could do this kind of development in my interview coding rounds...😅.

[@vasylstolyarchuk6226]

The best men uncle Bob.

[@MalgosO]

I want the introduction to be 50 minutes, this guy is amazing

[@sagarjoshi8444]

Can we refer manual tets cases from QA and write aut or integration test for it, is it a good practice ??

[@dimitarkarazapryanov9710]

Well, the water dipole negative charge is on the Oxygen atom's side. Anyway, it's always refreshing to learn something unexpected during those lectures. :)

[@dmitripogosian5084]

Yep, it is funny how you can invent what seems an easy explanation, and then get the result that is opposite to what really happens

[@snky1987]

The only terrifying thing is that there is millions of us (programmers) but still only couple of thousands will see these videos :scream: :D

[@zandark88]

Its terrifying that you think other programmers should watch this

[@fabs4058]

@@zandark88 please enlighten us further with your wisdom

[@Detroit_Playa]

I’m just finally starting to take programming serious and watching this hopefully I can start off doing it the right way

[@TheJP100]

Smart guy, this lecture taught me more than I would like to admit. The camera should show whats important to the viewer however and who ever made the decision to show Bob ALL THE TIME when the focus was supposed to be shifted to his work, should 100% stop working as camera-douche and apply for a simpler job!

[@elbanj]

For some reason I imagine he also rocks on the electric guitar.

[@Ozzah]

21:49 - I'm curious what you guys think about TDD for greenfield projects. Specifically, projects where scope/requirements are likely to change. If you need to implement a small to medium feature inside an existing project, TDD sounds like an amazing idea. What happens when you're starting a new and highly complex project with lots of parts, lots of requirements, lots of code, and you can expect that you will re-write the code 3-4 times by the end of it, not because the code is bad, but because the requirements/scope has changed. In this case, I see TDD as less useful and more of a waste of time, since you are writing tests for code that will end up being culled anyway. The only thing that Bob said that would seem useful in this case is that writing tests in TDD mode is more fun than having to write tests at the end.

[@peddfast]

You're describing the exact point in time you want to use TDD. TDD particularly excels when the specifications change and you have to rewrite code. Rewriting code with TDD is like writing code with TDD, except you can be sure that most of the system still works if you do large changes. Tests are specifications of what you want the code to do. If the specifications changes, you change the tests. If you have to rewrite code with existing coupling, it would be very beneficial to use TDD. If you've ever spent a long time on a greenfield project you will likely notice that maintainability and extensibility goes down the drain the more code you write. Uncle bob explains in one of these videos the fear of writing code some developers experience with long running systems. I have myself been involved in long running projects where the parts that were written early without tests are the no mans land of the code, it's were you dread to go in fear of destroying the system.

[@canbilgeyilmaz]

Watch his other videos on architecture. If you rewrite code 3-4 times over, that might mean too much dependency in your code - i.e. your codebase should be so decoupled that you only need to change a few things at a time to modify or expand functionality. He does not use inheritance much, if at all. Relies on polymorphism to invert dependencies, etc.

[@Ozzah]

​@@canbilgeyilmaz code is rewritten several times over because we're solving difficult problems, and we need to experiment with different approaches, see how they work in practice, experiment with how they scale, work through all the known unknowns and discover the unknown unknowns, etc. It's not a problem with coupling.

[@daniels3980]

3 to 4 times is not that many, It is not that uncommon for a key method or a sql query to be modified over 100 times in a few years timespan, including code that is written for TDD, and not. Not every method mind you, but some. When you start a new job it is good to query git to find the methods that are changed the most of and have git bring it back in order of the count of the number of changes. Those are often the key methods. This sort of stuff about them never changing is more for school than industry. Otherwise we would be writing Word documents in the same app that was used in Windows 3.1

[@paviad]

I got a question, what if you write a test for a function, and then you end up refactoring that function, and extracting other functions from it. Do you then have to write tests for the extracted functions? Or do you have to write tests for the extracted functions before extracting them? Either way feels like writing test "after the fact" as it were. What is the common practice in this case?

[@BarryMichaelDoyle]

Theoretically using TDD you would write tests for the functions you are going to extract, and THEN you extract them. Initial test won't need to change (if it fails it means the function was refactored incorrectly.

[@AdrianLParker]

@@BarryMichaelDoyle if the function is moved from one class to another, the original test very much has to fail (and could never work). Because the original test is now calling a function in a class which doesn't have that function, and possibly never will, by design. I'm a bit confused by his whole line of thought starting at 1 hour 20 minutes.

[@shapedsilver3689]

I want to t-shirt that says “my tests pass, so damn you!” Lol

[@greenlampshade8909]

Depends greatly on how those tests were developed. "...so TDDamn you!"

[@cedrics7374]

44:02 when he said he’ll do a demo, I almost cheered 🥲

[@AZ-bu7ss]

Thanks

[@redbread6852]

How'd ya code in c++ on Intellij IDEA CE? Is this a Mac/Ultimate feature? The one plugin I found is outdated

[@Chiramisudo]

What's most obnoxious is that this is the best presentation of this lecture I've found, and yet, in a spectacular failure it was uploaded in a mere 720p in an era of 4k. Bob isn't going to be around forever y'all, but his wisdom is timeless. DO IT JUSTICE AND CAPTURE IT PROPERLY!!! 😒😞

[@casperes0912]

"Who else has a problem like that. What other field; What other employment has a problem like that, where they construct documents that are arcane and every symbol has to be correct" Me: "Wizards?"

[@TheNewton]

Print

[@mistalan]

Physicists

[@MrDoboz]

exactly my reaction lol

[@romanext921]

Very nice demo 😅

[@n0MC]

Folks, relax. Yes the videographer should show the screen but you can get the entire content with audio only. I listened to this entire series on a couple of long car rides.

[@ankitsood1088]

Should we write use TDD when writing Acceptance test cases .. ergo should there be a unit test case testing the acceptance test cases or would it be a overkill?

[@MrDoboz]

that's a funny idea. While we are at it, let's write unit tests for the unit test, I mean would you bet your life on the Assert class? I sure wouldn't

[@licriss]

In theory the code itself should validate the acceptance tests, and where the code isnt available but you still need to develop acceptance level tests, you create mocks However some acceptance tests cover such wide and complex workflows that having unit tests for those is valid, this is very uncommon though and you'll often find it under "bad practices" as a claim that the test are too wide, I completely disagree with this but you wont find many references to back up my argument as acceptance testing has evaded deep study for the most part

[@mohammadazeem7228]

1:11:20 i am wondering that you people are laughing while coding... I wish i also could do that! Uncle Bob you're legend ❤️

[@TodorescuProgramming]

that stuff to write a test then write the code makes sense... I mean you're forced to think of functions that take input, produce output or sideeffect ...

[@Name-lt2tz]

interesting idea about extracting to new classes but not writign tests for new clases because old test should still cover. Yes, that should make tests not fragile, but test becomes very complicated. Lot of setup to get till that deep code which you are testing. So looks same as if code would not be extracted - I know lot of setup is required to test big function which is not extracted into small classes.

[@violetjellyfish2089]

Потрясный мужик. Смотрела бы и смотрела)))

[@ViktorEngelmann]

Prolog actually becomes one of the best languages there are... as soon as you really understand it.

[@garryiglesias4074]

Pure C without preprocessor, is the REAL way to go. It's obvious.

[@igorswies5913]

@@garryiglesias4074 wait so you want to keep all code in one file?

[@garryiglesias4074]

@@igorswies5913 Yeah of course, that's the challenge for the "real" programmer isn't it ? (I am sarcastic... I disagree with the idea of "best languages" even if it's "one of"... Language should be/are domain specific, what is good in one situation can be bad in another one. It's always a matter of context.)

[@igorswies5913]

@@garryiglesias4074 I actually made one small project as a challenge where pretty much everything would be in the main function (yes you can declare classes and structs in functions in C++, as well as lambda functions)

[@garryiglesias4074]

@@igorswies5913 I know, I heavily use that for "anonymous callbacks". I program since 1989, and did some "hardcore" stuff when I was a teen, assembly, software renderer (raster/raytracing), dos extender, etc... I've nothing against "dirty hardcore" when it's for fun an practicing... Or some niche situation, embedded systems or exotic hardware. But I will use Haskell if it makes more sense.

[@drhhusain]

disliked ... for editing this video, there is no relation between bob's laptop screen while he is writing the code. it just frustrated me

[@rossgeography]

dubbing is off too

[@GerbenWijnja]

yeah well you can kinda guess what he's writing, so it's ok. In my opinion.

[@gajbooks]

This is captured from a livestream and reuploaded. You're free to dislike, but don't blame the uploader for things they physically don't have access to.

[@GeorgeTsiros]

@@rossgeography at 3:50 it glitches and syncs... i hope it doesn't sync out again later >_

[@kemsekov6331]

As he said. You'll be even more frustrated.

[@unitycoin_original]

Many people just read titles, and dont read all the text of papers, quantum computer is just vaporware. Uncle bob is very clever 13:26

[@avimehenwal]

Can anyone please post the link to uncle bob pair programming with Sandro Mancuso 15 hrs youtube video series he talked about at 1:18:50 ? If they are on youtube?

[@CuriousCritter9]

They are for sale at cleancoders.com/series/comparativeDesign and do not appear to be on KZbin.

[@Daveduddle]

Really nice series! Just one thing where I strongly disagree: there should always be time to learn the stuff you need for work IN YOUR WORK TIME (he spoke about learning TDD in your free time before bringing it to work)

[@pmro]

You know why, go to client and say that You want to learn new stuff during work time so they will pay for it 😅

[@sergiocoder]

@@pmro if you work for a company they should pay for you to learn new stuff if it's related to the job

[@marcdietmann724]

What happens if you build your system on one test that was designed false. Would your whole system be false?

[@THEMithrandir09]

Can anyone link a github repo that does TDD exactly like he describes it around 29:00.

[@paxvostrum4824]

Could anybody recommend lectures like these 6, from Uncle Bob or anyone else as good as him (if there is one 😁)??

[@rajatmalgatti8145]

Is this video an alternative to reading his book?

[@zolv]

Implementing a stack is very efficient. Good luck implementing a Mars lander code using TDD this strict way. See You in year 2134...when You finish implementing the stack.

[@wolverine9632]

See you when your implementation fails because of that one overflowing rounding error in that one counter in that one function in that one class in that one library that controls the gyroscopic sensors.

[@bazooka712]

@@wolverine9632 that is the trade off. As a system gets linearly more complex, the amount of tests become exponential. That is just how things are.

[@TruthNerds]

4:50 I have a comment which is OT, as is the intro. (Don't get me wrong - I love it!) The claim that it's about the ions and not about the dipole moment was at least popularized by KZbinr Veritasium. Just a week or so ago, another KZbinr called Thunderf00t (a British chemist) thoroughly debunked these claims. Well, not entirely, ions do play a role but the dipole moment alone is sufficient, as he demonstrates with substances other than water. As far as I understand it, water autoprotolyzes and is therefore never free of ions, even if it's demineralized, so to show that ions are not necessary, different dipolar liquids are best used.

[@BienestarMutuo]

The extratetrrestrial "that have spaceships with antigravity", say that our understanding of electromagnetism and matter is all wrong.

[@TruthNerds]

@@BienestarMutuo That may well be… but if they started explaining it to us properly, would we be able to understand a word? 😄

[@BienestarMutuo]

@@TruthNerds A good teacher guides you to gain knowledge for yourself. A bad teacher gives you the knowledge and makes you dependent on the teacher. they are a lot more smart that us, but we (the humans) are a lot more powerful (in potency).

[@TheWarTurkey]

Air hi-five to all the other programmers here who program the double-entry bookkeeping!

[@somebodyoncetoldme1704]

couldn't the sound be synced with the picture?

[@Adiounys]

If he is not going to put all those intros finally into some working anti-gravity model or some other cool thing, I will be pissed off...

[@lcppproductions7910]

The only issue with this is that if the compile times are long you're not gonna want to hit compile every single time you make a change. I guess you could change the build target and isolate dependencies so it doesn't take forever, but Idk exactly how this would work with a large system.

[@Follyaxel]

By applying Uncle Bob's other principles like SOLID, especially the Dependency Inversion principle, which allow you to minimize dependencies and thus the classes/components/modules that need to be recompiled

[@alext5497]

Wow. Im actually having a rage reaction at the editing

[@TanelTagavali]

What if, and hear me out here, what if instead of removing the problem of debugging simple things like the minor change you're implementing right now, we instead make it easier to solve that problem? The harder problems of major changes and distant interactions remain in both situations, but if we removed the need to debug the simple things, we no longer have the exercise to learn to solve the bigger problems. What if we could make debugging both the simple and complex things easier? What if we could make debugging easier and more useful than testing? That seems like a better solution than removing the problem in just one situation.

[@AdrianLParker]

But it's not only debugging, TDD can catch logical and business logic errors which compile just fine. Imagine an add function which takes two integers, should return the sum of them, but always returns -1. It's a bug, but it will compile without error

[@TanelTagavali]

@@AdrianLParker That is true. But what worries me are the hard bugs that unit tests can't detect, or that it's not immediately obvious that the behavior is incorrect. I'm also concerned about how hard it is for developers to understand the big picture of what the whole program is doing, and how the system works not just in the ideal case, but also in the weirder cases. It's not enough that we know which values a simple and isolated function returns. Reading the source code or running tests is not enough to understand why things happened, you need a good debugger. Here is what I mean by making debugging easier. It's a small prototype (not fully featured or bug-free), but it should show why I think that a better debugger can do everything that TDD can do, and even more, and better. Even if you don't agree, I would like to know your thoughts. clinei.github.io/codeliteral/

[@victordrouinviallard1700]

The parachute parabolla should be replaced by a submarine one :D

[@mezlo64]

"i'm on a mission to kill all braces" "i want lisp to be the last programming language" yeahh right

[@AdrianLParker]

@1:22:26 I don't understand this. Your test calls a function on a class, if that function is removed from the class during the refactoring process, then your test will fail. How do you refactor your classes, without breaking all of your tests which call the functions in those classes which end up being refactored? Has anyone an example? Unit tests are very tightly coupled to the class methods they test, how could they not be?

[@MrDoboz]

what, you would refactor push or pop out of the code, or what do you mean? also how else would you test a class? You have no way of interacting them other than through it's methods. And if you rename a method for example, the test is a good warning that you may have to rename it somewhere else too. but if you don't need the method for example, you don't need the test anymore either. so then what's your problem?

[@AdrianLParker]

@@MrDoboz listen to what he said at @1:22:26 and then read my question again

[@AdrianLParker]

@@MrDoboz exactly my point, but the video seems to say contrary

[@irmaosver]

You should write your tests on the public methods and not the private methods. That's the implicit part.

[@GRHmedia]

Close but no cigar on the Alpha Centauri comment. 4.1x10^23 not 22.

[@lexxfirecore123]

17:33 estimates cont.

[@RSFeed]

51:56 out thru the nose comes the hot tea flying!

[@RSFeed]

1:00:16 I´m not drinking any more tea untill this finishes...

[@elomoosk5991]

1:21:48 smooth

[@worldshaper1723]

I created a new language called the intuition code. This might be the golden language. I need seed capital. Who should I talk to.

[@unitycoin_original]

Friend, please give us a brief, and please a comparison with the jai language. Thanks. [e-mail] We believe (we can be wrong) that a programming language must have: - composition instead of inheritance - modules instead of encapsulation - first class functions instead of methods - records for mutable state

[@MiseryKira]

Does rly java "compiles"?

[@Kitsune_Dev]

Sound is faster than light

[@jakubk7158]

31:30, 32:30, 36:55, 39:35, 1:24:42 - groups to learn

[@immalkah]

I hate that they don't show the screen while he's working on the laptop much. It is much more useful than just seeing his face. Otherwise great series.

[@Name-lt2tz]

I want to see that experiment with 45 volts :) I do not want to spend money doing that

[@arbrimrashiti]

7:10 - Note: Only a glass or two of heavy water might be fine - kzbin.info/www/bejne/jIWvmX6KnpuSfZI

[@sergiocoder]

There is a borrow checker in Rust, isn't it something new?

[@emilhuseynli]

Mr. Robert C. Martin, hope you'll read this some time. The statement about not mapping unit test class to corresponding production class was very surprising to me. Why not maintaining 1:1 mapping? If you extract some new class out of existing production class, isn't it possible also do same thing with corresponding test class? After all, it's unit testing (and classes are units most of the time) so why having a single test class which covers multiple production units? It's very confusing...

[@BienestarMutuo]

Sorry to say, but we just edit the video, this is his blog: blog.cleancoder.com/

[@lucasdarianschwendlervieir3714]

kzbin.info/www/bejne/e4uTZphterKCgq8 This video is excellent at explaining the problem with highly coupling production code to test code.

[@emilhuseynli]

@@lucasdarianschwendlervieir3714 This guy and the company/team where he worked had really issues with writing clean understandable tests which test behaviour and not implementation. Having 1:1 association between production class with corresponding test class has nothing to do with coupling. Extensive and careless use of mocking framework to test every implementation detail - that is coupling and is main focus in that video.

[@lucasdarianschwendlervieir3714]

@@emilhuseynli But if you have 1:1 association between production class and a corresponding test class there are many refactoring steps you could that that would break these tests, and you you have to throw them away and write new tests for the refactored code. If a change in one part of the system breaks another (in this case a refactoring in production breaks tests), that's what I would call coupling.

[@emilhuseynli]

@@lucasdarianschwendlervieir3714 Which refactorings? Rename, move? Both are very good supported by modern IDEs and if you do refactoring to a production class (e.g. move to another package) then IDE will take care of corresponding test class and there's no overhead. If you e.g. split a class into two classes you clearly change behaviour and it's perfectly fine to invest some time to adapt the tests to cover new set of behaviours.

[@hosseinamiri1516]

First, If you are not going to use a switch-case statement, maybe he said in previous videos, please use the if-elseif-else structure to make sure that the compiler and then the processor is not struggling with many if statements when checking relative conditions. Second, writing tests before coding is a good practice when you are a senior developer or at least an experienced one, who decouples every part wisely. As a junior developer keep calm and write tests after you realize what to do. DO NOT KILL YOUR MOTIVATION AT THE BEGINNING BY WRITING TESTS.

[@NadChel1]

They don't write Stacks in production, though

[@user-yd9xy3rb4x]

10:30 Hello from an iOS developer :)

[@rockstarjazzcat]

"No." The period goes inside of the quotation marks. :)

[@rockstarjazzcat]

"Programmer!!!" Lol.

[@krokenstiv8777]

he violated package naming convention

[@wolverine9632]

For everyone ranting about the "camera guy," I would like to point out that there are multiple cameras, and only one editor.

[@csbnikhil]

Rust's Ownership & Borrowing were new, I thought.

[@albertmarashi3666]

They are

[@RaffaeleCastagno]

It's just me or the video is constantly out of sync, and re-synced every now and then?

[@leonardkupper5057]

You’re right. Feels like with every lesson of this lecture the editing becomes worse.. At least the good talk makes up for it.

[@RaffaeleCastagno]

@@leonardkupper5057 seems like the video is slightly faster than the audio, so it had to compensate from time to time. Great lessons tho.

[@alext5497]

A bunch of nerds drooling over best practices and good organization. I love it

[@Elias-dj1ge]

Show the code, will you?

[@wojciechsobiesiak]

grandpa don't bore us, get to chorus he he