Welcome to the Clean Coders Java Case Study. This is Episode 1. Over the next weeks and months, Micah and Uncle Bob will re-implement the cleancoders.com website in Java before your very eyes. You'll see them applying all the principles, patterns, and practices that you've been learning in the Clean Code series. But instead of learning about those principles, patterns, and practices, you'll see how they use them in real life. The first episode is entitled Getting Nothing Done because in this episode they use the first acceptance tests in FitNesse to set up the infrastructure and facilities they need to start getting real stories implemented. They do finish one story; but it's the story of the null case. So get ready for some fun and education and you watch these two seasoned professionals work together to create a web system in Java.

Welcome to the Clean Coders Java Case Study. This is Episode 2, part 2. Make sure you watch part 1 first. This episode picks up right where part 1 left off. So Micah and I worked for a couple of hours getting our first acceptance tests close to passing. We wrote lots of unit tests, and made a load of progress. We also encountered several interesting problems. Chief among them was to create a mock database (The Gateway) that behaves enough like a real database to make our tests meaningful. There's more work to be done on that; and you'll see more on that in Episode 4. But for the moment we managed to figure out how we would deal with unique identifiers for all the data being stored and fetched through the Gateway. We split this episode into two parts, each about an hour long. There's a lot of stuff going on in each one, so take your time and watch carefully. You'll be the third member of our pair. Notice, how the pairing is working. Watch how we toss ideas back and forth, and help each other when we get stuck or tired. The dynamics are fascinating. We reviewed this episode later and found a number of interesting discussion points; so Micah and I recorded some commentary and interspersed it along with the video. It's quite amazing how this little batch of code could raise so many design and architecture issues.

Welcome to the Clean Coders Java Case Study. This is Episode 2, part 1. So Micah and I worked for a couple of hours getting our first acceptance tests close to passing. We wrote lots of unit tests, and made a load of progress. We also encountered several interesting problems. Chief among them was to create a mock database (The Gateway) that behaves enough like a real database to make our tests meaningful. There's more work to be done on that; and you'll see more on that in Episode 4. But for the moment we managed to figure out how we would deal with unique identifiers for all the data being stored and fetched through the Gateway. We split this episode into two parts, each about an hour long. There's a lot of stuff going on in each one, so take your time and watch carefully. You'll be the third member of our pair. Notice, how the pairing is working. Watch how we toss ideas back and forth, and help each other when we get stuck or tired. The dynamics are fascinating. We reviewed this episode later and found a number of interesting discussion points; so Micah and I recorded some commentary and interspersed it along with the video. It's quite amazing how this little batch of code could raise so many design and architecture issues.

Boy! All we had to do in this episode is sort one field and add another. And yet we stumbled and fussed all over the place. We even got derailed once by using the Java-6 documents instead of the Java-7 documents. Sheesh! Watch Uncle Bob in the first half of the episode. He doesn't want to touch the keyboard! What's up with that? He just sits there and grunts imperiously while Micah does all the work. With all the load on Micah, he starts to get tired too. By the end of the first tomato they're both so knackered that they can't remember how to make the sort function work. What a difference a break makes. The energy comes back in the second tomato and is running high in the third. I guess all programmers go through periods where they just don't feel up to coding. There are some interesting technical surprises in this episode. For example, there a classic case for inheritance that we eventually bail out of and use an enum instead. And we find some interesting issues with SimpleDateFormat. We also dig a bit deeper into the FitNesse fixtures such as Decision Tables, Query Tables, and Ordered Query Tables. By the end of the episode, you'll see that the code is starting to get pretty messy -- despite the refactoring we've done along the way. And that set's the stage for Episode 4 -- But then I don't want to give too much away.

Knock knock. Who's there? No, not yet. Let's do this later in the episode. No, not yet. Let's do this later in the episode who? No. Stop. ... Oh rats. In this episode we change directions entirely; and we announce a contest! The episode begins by reviewing a big refactoring that Uncle Bob did off line. It's pretty cool, and you aren't going to want to miss it. Then we announce the contest that you can participate in (See Below). Then we take the whole project in a brand new direction. We begin to write our own simple web server. We got frustrated looking at all the other web servers out there, and decided it would be a better use of our time to write our own. Have you ever written a web server? Its simple; and it's fun! Watch how we do it here; and listen to the rationale we present.

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.