GO: With Intensity
9. Introduction (Free)
By Jonathan Oliver & Mike Whatcott, 3m

It's just another normal day at SmartyStreets. Jonathan, Founder and CEO, is sitting in their kitchen, eating his bowl of Lucky Charms. Then up walks Mike Whatcott, senior developer and with a problem.

Smarty Streets provide a cloud-based address verification service. If you have a mailing list with a bunch of addresses that you aren't sure of; then you can pump those addresses into the Smarty Streets API, and get back a list of addresses in mailable form, with an indication of whether they are deliverable, vacant, inactive, etc.

Mike's problem is that the field support team need a tool that will take a CSV list of addresses and produce a CSV list of validated addresses.

This video series shows Jonathan and Mike working together, to produce that tool in the `GO`` language.

8. The Pressure is On!
By Jonathan Oliver & Mike Whatcott, 1h 14m

OK. There is one hour left. After that hour Angela and I are driving to the airport to get on a plane. So the guys are feeling the pressure. What's more, the fatigue from the last episode is still evident.

And so this episode begins with the final cleanup of the EOF troubles they had in the last episode. Then, with only 50 minutes left, they opt to write an integration test to help them wire the system up.

This was the right thing to do. What's amazing to me is that, given the pressure they were under, they did not try to just guts things out at the end, and write a main function that ran everything. The temptation must have been enormous. And yet they stuck to their disciplines, and wrote that integration test.

And it's a good thing they did; because, as you'll see, they find some subtle errors that would have been hard to find without it.

Unfortunately they also make a clumsy error in one of their mocks and, for at least the third time in this series, rip up their code trying to debug something that wasn't actually broken. Fatigue and pressure were taking their toll!

OK, no spoilers. You'll have to watch the video to see if they have a happy ending. But, what a journey, eh? 8 hours. 24 Tomatoes. And they've written an entire application, beginning to end, using TDD, Refactoring, Pairing, Simple Design, Integration Testing, Collective Ownership, and... Well, if you watch the Clean Code videos, you know.

And what an interesting language. I'd never seen GO used before. I was quite impressed at the execution speed. Those tests just flew! I also thought the language itself was nicely constructed, approachable, and easy to get running.

I have to say I was deeply impressed by Jonathan, Mike, Cami, and the whole crew at SmartyStreets. Good programmers. Good people. Good company.

7. Can You Spot the Bug?
By Jonathan Oliver & Mike Whatcott, 1h 3m

You'd think the Reader would be the easy one, wouldn't you. After all, they've done the Verifier and the Sequencer and the Writer. How hard could the Reader be?

Pretty hard I guess; because our dynamic duo got all bolluxed up a couple of times here.

First, there's that silly bug they inadvertently added to the code in the first tomato. (Can you spot it?) Finding that bug took them most of the second tomato, and caused them to butcher a lot of perfectly good code in the process. Oh, they got it all back and working but -- well, it was embarrassing.

Then there was the whole problem of the EOF. Somehow they instinctively knew that the EOF was important; but they didn't think through just why it was important. And so they chose a convenient shortcut, and wrote a bunch of code based on that shortcut, only to realize that the shortcut blocked the real need. So they had to back out their code and redo it.

In fact, in this episode, the number of times they had to back out incorrect solution is pretty high. Perhaps they were getting tired.

Programming when you are tired is a losing proposition. Even the most experienced programmers get fatigued.

In the end, however, all is well. The Writer is nearing completion, and all the other major components are complete.

6. Starting the Writer
By Jonathan Oliver & Mike Whatcott, 1h 3m

Jonathan returns from his meeting, and Mike quickly walks him through the Sequencer. Then they start working on the Writer.

Once again, notice how careful they are about testing. Notice how the design of the Writer improves before any of the Writer code is written, simply because of the effort they put into the tests.

These three tomatoes are pretty straightforward; but I want you to pay special attention to they way they refactor and clean up the tests. They remove redundancy wherever they see it.

Notice also the discipline they use with their mocks. They aren't afraid to write their own. They seem to have no need for a mocking framework.

5. Starting the Sequencer
By Jonathan Oliver & Mike Whatcott, 1h 4m

Mike and Cami return, in this episode, to finish up the Authorizer and then begin work on the Sequencer. As they proceed through this, notice how diligent they are about refactoring the tests. They clearly understand that clean tests are essential for keeping the production code under control.

In the second tomato they have begun the logic of the Sequencer. At first, everything goes quite well. They get the first few tests cases to pass without a problem. But then things start to go wrong, and they begin to flail.

They seem to recognize this, and so they do something quite astonishing. Rather then pressing on towards a brute force solution that seems wrong, they start cleaning up the tests. That is the mark of true professionals. When they are confused by a mess, their first reaction is to clean it. The tomato ends with a nice clean set of tests that fail.

Something happened during the break. Somebody got an insight! So as the third tomato begins, the flailing is over. They know what to do.

This is common in PDD (Pomodoro Driven Development). Many technical problems are solved during the five minutes or so away from the keyboard.

It all comes together easily, and the third tomato ends with nice clean code, clean tests, and a working Sequencer.

4. A Non-Vacant Test
By Jonathan Oliver & Mike Whatcott, 1h 9m

A ton of interesting stuff happens in this episode.

First, having finished the request and the response, the team is now ready to deal with the "gold" -- the analysis of the response. This, it turns out, is just an interesting problem of combinatorial logic.

At first this logic goes as you might expect. But then something fascinating happens. The team starts to refactor the tests. And as they clean up the tests they find that it's easier to write more tests. And as more tests get written they find that it's easier to clean up the production code, which allows even more test cases which... There's a lovely example of the positive feedback of TDD/Refactoring.

And then, in the third tomato, Jonathan gets a text and has to leave to go to a meeting (he is the CEO after all). Mike could continue without him. There's no rule against that. But, instead, he decides to take the opportunity to teach someone who is less experienced with the language.

Enter Cami.

Now watch how everything changes. Mike goes from agressive collaborator to patient teacher. Cami's no slouch. She revs up to speed pretty quickly. Still, Mike is much more experienced. So the gentle teaching continues as the pace increases.

Watch how this affects Mike's code. Mike's code gets more deliberate, more explanatory, and even cleaner than before. The act of teaching improves the teacher!

3. Building the Response
By Jonathan Oliver & Mike Whatcott, 1h 5m

Having constructed the request in the last Episode, our plucky team now focusses on mocking out the Smarty Streets API. They build a FakeHTTPClient that accepts the request and produces a valid, if canned, json response.

Watch carefully has these two extremely experienced programmers focus on the periphery of the problem, rather than "going for the gold". They make sure all the mechanics works properly, and all the error handing is managed. They are methodical. They are diligent. And they are very professional.

2. Draining the Queue
By Jonathan Oliver & Mike Whatcott, 1h 6m

Having gotten themselves on a good trajectory, our intrepid team now focuses more on the guts of the problem. In this episode they build the request that will eventually be sent to the API. Bit by bit they assemble the URL and the arguments that will be pumped into the Smarty Streets API.

I want you to notice how diligently they maintain the separation of concerns. They keep the construction of the address separate from the construction of the URL and authentication, which they keep separate from the HTTP protocol. Indeed, that separation, using the Decorator pattern, is the primary driver of the design of the Verifier.

1. A Good Trajectory
By Jonathan Oliver & Mike Whatcott, 1h 9m

It's just another normal day at SmartyStreets. Jonathan, Founder and CEO, is sitting in their kitchen, eating his bowl of cereal. Then up walks Mike Whatcott, senior developer and with a problem.

SmartyStreets provide a cloud-based address verification service. If you have a mailing list with a bunch of addresses that you aren't sure of; then you can pump those addresses into the SmartyStreets API, and get back a list of addresses in mailable form, with an indication of whether they are deliverable, vacant, inactive, etc.

Mike's problem is that the field support team need a tool that will take a CSV list of addresses and produce a CSV list of validated addresses.

This video series shows Jonathan and Mike working together, to produce that tool in the GO language.

This first episode begins with a quick design session at the whiteboard, the establishment of their test environment, and first halting steps of the code.

Pay very close attention to the design they are creating on the board. See if you can spot the Chain of Responsibility pattern, and the Decorator pattern? Try to notice how they adjust their design for testability. They move fast, I know, but see if you can follow along with them.

Oh, and don't forget to download the diagram I created from the Extras link. It'll help you keep track of what they are working on.

These guys are expert TDDers. They know how to write tests, and when to use mocks. They refactor mercilessly. Watch how carefully they follow the TDD and refactoring discipline. Also watch their expert pairing technique; and their ability to keep the big picture while focussing in on the minutia. (Think globally, act locally). And notice how they complete each other's sentences. Clearly this is not the first time they have paired together.

0. Why Go?
By Jonathan Oliver, 5m

Why would a company, like SmartyStreets, choose a language like GO for the development of their high-volume, high-throughput, cloud-based application? Jonathan Oliver, founder, CEO, and a senior developer explains the rationale behind their choice.