The keynote I gave remotely at ACCU 2011. Over the last 50 years we've seen a lot of computer languages. From procedural languages, to structured languages, to OO languages, stack languages, logic languages, and even graphical languages, and languages based on the game of life. We've seen so many different languages, and different types of languages, that we need to ask ourselves a question: Have we seen them all? Are there any more types of languages that we haven't seen? Or have we completely explored the language space? And if we have, then isn't it time we pruned the menagerie of languages down to a manageable few -- perhaps even one? Other industries have done this? Why not us? Others disciplines have brought their notations down from dozens to one. Electronics, Chemistry, Biology, Mathematics, etc. And the benefits they reaped by doing so were significant! Perhaps it's time for us to follow suit. If we did choose a language, what kind of language would it be? What features would it have? What syntax would it follow? What paradigms would it conform to?

Get ready for something very different. This ain't no screen cast. This ain't no talkin' head lecture. This is an Uncle Bob Video! This is like watching Uncle Bob on stage, but more so. This is high content education that will hold your attention and stimulate your thoughts with its impactful and energetic style. Indeed, this is the remake of the original, brought up to the standards we've learned after two and a half years! So hold on to your hats and prepare yourself for a radically different kind of educational experience. In this video Uncle Bob shows why Clean Code is so important. He answers the question: Does Clean Code Matter? And he answers it emphatically in the affirmative! He explains how bad code leads to the downward spiral of The Productivity Trap. He describes the various ways and forms of Code Rot. And he concludes by answering the question: What is Clean Code? So don't wait. This one is almost a freebee. It's job is to convince you that you, your co-workers, and your managers will want (and need!) to see the rest. And besides, you don't really want to miss the astronomy lectures, do you?

Working on the web server leads to periods of befuddlement followed by periods of productivity. This episode might be a little painful to watch as Micah and I stumble around trying to make this multi-threaded web-server code work. You'll watch us miss obvious things that you see right away. You might even be moved to leap up from your seat and shout at the screen. Still, in the end, we solve the threading problems and make a lot of progress on our little web server. After three tomatoes, we can see our way clear to the end. Working on multi-threaded code is always a challenge. TDD helps a lot with correctness; but imposes it's own complications too. If you've always wondered how to do TDD in a multithreaded environment, you can watch us do it here.

We solved all the race conditions in the last episode; so in this episode things go much more smoothly. There are a few tests left in order to finish the web server. We write them. And then we find that they weren't quite testing what we thought they were testing. We quickly finish getting our little web server running, and then start using it to send simple "Hello, World" messages to the browser. This forces us to investigate the high level structure of an HTTP Response; and make sure that our little web server delivers that structure. Once we can reliably communicate with the our browser, we begin working on delivering the Front Page to the browser. Along the way we discover that tests sometimes don't test what you think they do; and that sometimes the best tests are visual.

Uh Oh. We just got a call from the customer. They want a demo -- in an hour! Are we ready? Do we have enough to show? Can we cobble something meaningful together in the nick of time? How do you deal with pressure? How should you behave when time is short, and there are obstacles ahead? In this video, we solve a number of technical issues and prepare for a live demo with the customer. You'll watch us confront unexpected roadblocks, and confusions. You'll see how we respond. You'll recognize the emotions and the temptations. You'll watch us stumble through the minefield. All the while solving the problem of getting real data on the screen in our minimal web server environment.

Tunnel Vision. We all get it. We get so focussed on what we are doing that we lose the bigger picture. We get so frustrated with the time it takes to arrange all the fiddly little details that we begin to take shortcuts. This happens a bit in this episode. It's not a disaster. We recover quickly. But still, you can see it happen. Another interesting occurrence in this episode is the identification of a bug from the subtlest of symptoms. It's actually quite remarkable that we saw it. And then there's the function we thought was a constructor; but wasn't. And then there was the unexplained malfunction that we fixed with a magic word. Yes, this one is fun. It's a bit embarrassing; but it's fun.

What does C57-D mean to you? What does it have in common with The Naked Gun? In this episode we struggle for almost two tomatoes with how to manage two very similar data structures. Should they inherit? Should one use the other? Should there be a utility class? Then we start to reorganize the code and move it into packages. And we debate whether the package principles should be applied or not. We also struggle with the fact that we have not properly partitioned the use cases and presentations. And then there's that weird bug... Batman vs. Darth Vader?

So this one is interesting. In the process of fleshing out the CodeCast details page, we realize that we need to parse incoming URLs and build a router that selects the appropriate controllers. True to form, we simply write this ourselves rather than depending upon a framework. Along the way we re-encounter the strange race condition that sometimes causes our tests to hang. We work around this problem, but grow ever more concerned about it. By the end of the episode we have the architectural framework for many of the elements of a web serving system. And we still aren't using a framework.

The the help of Corey Boyle's son (and Corey to some extent) we managed to track down and kill that nasty threading bug. Actually it was a bug in our tests, not in the production code. Indeed, production code would never have exhibited the problem because production code would have been synchronized by sending messages between the sockets. The problem we were having was that the tests bypassed the normal conversations. The Clean Architecture begins to appear. After fixing the bug, we started to break up the silly main program that was putting up the front page. We moved part of it to a CodecastSummariesController, and more to a CodecastSummariesPresenter, and a CodecastSummariesView. We were driven to do this by the need to write a unit test for for the Controller. You'll see this in the video. Every time we tried to add something to the test, we decided to refactor the code a bit more to make it more testable. You might infer that this was caused by a lapse in our TDD discipline. That's not quite true. It was really caused by taking test code and turning it into production code; and then partitioning that code into the desired architecture. Anyway, If you've been wondering where the Clean Architecture was in the last 10 episodes; you'll begin to see it appear here. The transition isn't complete. We've got more to do in the next episode. But it's coming

Everything started fine. We had a nice design discussion on the whiteboard about pulling the taffy threads of our application apart. We even got IntelliJ to show us the UML of the design as it existed, so we could compare it to the ideal. But then, in the transition from UML to code, something happened. I couldn't adjust the speed of my brain properly. My brain was going too fast for the code. And so I started making silly dumb mistakes. We made some progress in tomato 1, but not as much as we should have because we kept having to backtrack due to my brain overruns. So we slowed way down in tomato 2 to try to resync my brain with the proper rate of code. And this worked pretty well. By tomato 3 everything was back to normal. We made some very interesting decisions in this episode. We established a target architecture. We determined the difference between our current design and that target. And we started along a pathway to get from one to the other. -- And we got our brains going at the right speed. And, perhaps most importantly, we engaged The Discipline of D. E (Do Easy).

As we pursue the architectural refactoring of the application, I make a silly mistake in the diagram on the board. And for two and a half tomatoes we don't spot it. Yikes! This doesn't invalidate the work we do. And much of it is good. But it does create a kind of "friction" that we both feel and can't quite explain. This is a reality show. This kind of thing happens in real life. It's frustrating. It's embarrassing. But it's real. And it's educational. And, of course, there's lot of other things to learn in spite of the flub. We talk about mocking tools. We talk about dynamic vs static languages. We talk about refactoring strategies. We talk about big design vs TDD. And, in the end, we have a lot of fun. Because, after all, programming is the second most fun thing in the world!

In this, the penultimate episode of the Java Case Study, we manage to complete one slice through the architecture! Yay! With the right diagram on the board, and the right names in our minds, the pieces start to slip together just like they are supposed to. Oh, there are a few little problems here and there, like forgetting that CodeCastSummaries is a list -- twice. But overall, things flow pretty well. I love it when a plan comes together.

Yes, this is the end of the Java Case Study series. I know, I know. Heartbreaking! But all good things must come to and end. In this final episode we: Clean up the remaining cruft left over from the architectural change. Get all the unit and acceptance tests passing for the first use case. Make sure the first use case appears on the screen properly. All that takes two tomatoes. Then, in the final tomato, we review the whole series. From it's humble beginnings to it's even humbler end. We discuss the 18 months (and 18 hours) that we put into this project, and then project how this project might have continued.