Saturday, March 11, 2017

WeDoTDD.com has Launched!!!



On August 24, 2016, I launched an awesome new website WeDoTDD.com.  


It took me 10 sold months of very hard work (without pay) to both code and hold initial Google Hangout interviews with industry leading programmers and companies who TDD every day..it's their bread and butter.  The outcome is WeDoTDD.com which I'm very proud of and happy that it's out there to promote and help people learn about Test Driven Development.  I'm still heavily working on it, with a list of new features I'd like to add in 2017 as well as continue to grow the list of companies.

The site lists teams that truly practice disciplined Test Driven Development and stories behind exactly how they do that, benefits, and a lot of useful information behind each team and company and to how it's been a success for them and their end users or clients.


Amongst some of the greats interviewed include:


  • Uncle Bob Martin of CleanCoders.com
  • James Grenning, who Wrote the Test Driven Development for Embedded C book
  • J.B. Rainsberger, who wrote JUnit Test Recipes
  • 8th Light, who started the formal "Software Craftsmanship" movement
  • Pivotal, who has been practicing TDD since 1999 and is helping companies such as AllState and Bosch transform their development teams to disciplined XP/TDD shops
  • Menlo Innovations, who has been doing TDD for over 15 years, and has trained many developers on TDD in Michigan
  • Pillar Technology, who has also been doing TDD for a very long time
  • promptworks, whose CEO and team was trained by Uncle Bob Martin on TDD
  • Codesai, whose CEO wrote the first TDD book for Spanish readers
  • Codurance, who has a huge influence in the Software Craftsmanship community in London, as well as helps spread TDD and other XP principals and practices to its many clients
  • CJ Affiliate, who just recently sponsored the Software Craftsmanship conference in Los Angeles and whose teams also practice disciplined TDD
  • Cucumber, the BDD framework by Seb Rose whose teams practices TDD
  • and many more great interviews up there and many more to come 
    • We have over 30 companies in queue taking the interview as we speak, just waiting for them to complete theirs so that we can list them on the site!  The list just keeps on growing
These companies continue to help others adopt TDD by pair programming with other developers and their clients.  TDD is flat out continuing to influence and grow in our industry.  Finally some real uses cases to prove it.

The time for debating TDD is over.  The proof is here, it's being practiced, and it's growing.  We no longer need to be producing studies, there is just too much proof that it's working, more and more companies are adopting it, etc.


More about the goals and purpose of the site can be read here.

Monday, February 15, 2016

Watch Those YouTube Programming Videos Faster!


I wasn't aware of VLC media player, I'm sure it's been around a long time but a few days ago I was having a conversation with another dev around watching videos and he mentioned that he watches videos faster by speeding them up.

I never really thought about doing something like that.  I mean it seems so obvious of a thing to do, and would save me so much time as a developer.

So now I watch videos on code much faster with VLC.  You can stream in any video from YouTube or other sources and speed up the video so those presentations can take 1/4 or 1/2 the time to listen to now.

What I like about VLC is the interface an menu is so simple and straight forward to use too.

Here's how to do it
  • Install VLC and open it
  • From the file menu go to Open Network and paste in a youtube vid url

  • After it opens, go to PlayBack in the file menu and increase the speed!  Awesome!


Save yourself a lot of time and use VLC.

Monday, February 1, 2016

Setting up OBS with Audio Output in Mac OS X





OBS (Open Broadcast Software) is a free streaming software option used for streaming stuff on twitch.tv and a slew of other sites out there.

I'm using SoundFlower for a bunch of different things like recording streaming music, and also for streaming audio playing through my desktop to twitch.tv and other live coding stream sites.

Here is how to setup OBS to stream audio playing on my MacBook pro.  So if you're on a site like livecoding.tv or similar situation where you are streaming and want to share audio you are playing you can.

1) Install SoundFlower which is now on GitHub as a new guy took it over so that's where you can get the installs now
2) Open Audio MIDI Setup on the Mac OS X
3) Add a new aggregate device and select Built-in microphone and Soundflower (2ch)

4) Add a new Multi-Output Device and select Built-in Output and Soundflower (2ch) and change master device to Soundflower (2ch).
(Note: If you don't select Built-in Output then you're not going to hear a thing through your speakers or headphones.)

5) Open OBS and go to Settings and in the Audio section select Soundflower (2ch) as your Desktop Audio Device and set Mic/Auxiliary Audio Device to your Built-in Microphone or if you're using an external mic, select that.

6) Open sound and set the output to Multi-Output Device
Now just start a recording to verify it's working before you start to stream live and the mp4 that's created locally should now be playing whatever audio you were streaming.


Here's a YouTube vid showing it actually does work that I recorded.

Saturday, December 26, 2015

Installing the AWS CLI - Short Version



Once again, this is a very quick and dirty shortened version of their docs.  A lot of this is straight from AWS docs but I've cut out all the clutter and documented how to make the install go smoothly as there are some errors you'll probably most likely run into.

I'm using the AWS CLI for working with/communicating to the Amazon EC2 Container Service so that I can start to create docker images and containers in order to push to my EC2 Virtual Server.


Installing AWS CLI

Verify Python is installed

Type python --version at the command-line

if it's not installed I have homebrew  so I installed it with brew install python

Verify Pip is installed

Type pip --help at the command-line

you should see this:



if not, then install it with sudo easy install pip

Install the AWS CLI using Pip

Type sudo -H pip install awscli --ignore-installed six at the command-line

Notice 2 things:
  • added the -H or else you'll get a permission error like this:         
  • added --ignore-installed six at the end because there's a bug with the aws cli install in that aws tries to uninstall six (python) which is already installed in OS X EL Captain so when aws tries to uninstall it (in order to install it), it blows up due to permission errors to those files it's trying to uninstall six 

Verify AWS CLI Installed Properly

Type aws help.  

You should see this (type Q to get out):
























Monday, December 21, 2015

Setting up Amazon EC2 Tools for Docker in OS X - Short Version

From Amazon Docs: Amazon EC2 Container Registry (ECR) is a fully-managed Docker container registry that makes it easy for developers to store, manage, and deploy Docker container images.

The EC2 Tools therefore allow you to interact with the EC2 API though your terminal through a special set of bash commands for EC2.  I'm then going to be deploying a new personal site to Amazon via Docker Container to my virtual AWS Ubuntu server via the Amazon EC2 Container Registry.

This is a very quick and dirty shortened version of their docs.  A lot of this is straight from AWS docs but I've cut out all the clutter and more importantly also added a little more about the IAM user creation where I include some screen shots because if you don't give the user permissions, you won't be able to authenticate when EC2 tries to make calls on behalf of your user's AWS Key & Secret.

Download the EC2 Tools
Run this in terminal:
curl -O http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip

Extract the Tools
I extracted them here but you don't have to to it here necessarily:
sudo unzip ec2-api-tools.zip -d /usr/local/ec2

Install Java
First verify if you have Java Installed or not:
which java
If it's present you'll see:
/usr/bin/java
If not then install Java.

Set Environment Variables

$JAVA_HOME 
This will allow EC2 to find your java install location

First, manually set it
We will manually set it by running it explicitly in terminal.  But..after this it'll be in your bash profile so you no longer have to worry about manually setting it anymore:
export JAVA_HOME=$(/usr/libexec/java_home)
(when this environment variable is accessed, the /usr/libexec/java_home will return the filepath to the java install on the fly.  If you want, try it out yourself, jsut run /usr/libexec/java_home in terminal)

Set the environment variable in your bash_profile
Set it in your .bash_profile so that it sets it on startup every time.  
Open your bash profile in /users/[yourusername]/.bash_profile
Now paste that export JAVA_HOME line above in your bash_profile

Test the Environment Variable
Now close your terminal then re-open it and run this to verify that the environment variable is working:
$JAVA_HOME/bin/java -version
it should return its version info, example:
java version "1.7.0_55"
OpenJDK Runtime Environment (IcedTea6 2.4.7) (7u55-2.4.7-1ubuntu0.12.04.2)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)

$EC2_HOME
This variable specifies where the installation of the CLI tools lie.

Manually Set it
To set it, put in the path to the folder where you extracted the tools tool earlier:
export EC2_HOME=/usr/local/ec2/ec2-api-tools-0.0.0.0 
(if you extracted it somewhere else, change the path above.  Replace the 0.0.0.0 with your version of the CLI tools)

Set the environment variable in your bash_profile
also, copy that line to your .bash_profile

Replace your $PATH variable in your .bash_profile with this line:
export PATH=$PATH:$EC2_HOME/bin

$AWS_ACCESS_KEY, $AWS_SECRET_KEY
We need to tell AWS how we're going to authenticate calls when we use EC2 tools.

Create a new IAM User
First, create a new IAM user account if you don't have one where you know the key and secret for it.

Click on your profile and select Security Credentials. 







Copy the Key and Secret and also download the file that contains that for future reference





Be sure that the user also has a policy set 
(note: you can also setup groups) 

Your users must have appropriate permissions in order to auth API wrapper calls you make from OS X terminal to the Amazon EC2 API or AWS API, ect.  

Click on users, and then click attach policy and then select the Administrator policy for your user:















Explicitly Set them
Now go back to your terminal to set the AWS_ACCESS_KEY and AWS_ACCESS_SECRET environment variables by running this in terminal:

use the access key and secret key from the user you created above below
export AWS_ACCESS_KEY=your-aws-access-key-id
export AWS_SECRET_KEY=your-aws-secret-key

Set the environment variables in your bash_profile
copy and paste those 2 lines into your bash_profile.

Verify the CLI Tools Work

verify it works by running a command, so run this:
ec2-describe-regions
you should then see this:





Here's what your .bash_profile should look like
example (I've x'd out my real key values for the sake of this blog post):


Sunday, November 15, 2015

What It's Like Attending a Code Retreat



   (pic I took after code retreat ended @ 8thLight)

Yesterday, I attended my first code retreat in Chicago.  I wondered why I didn't look into doing this before.  Probably (and ironically) because I was too busy trying to practice TDD at home  or at work :).  I say ironically because that's exactly what you do in a code retreat, you TDD!

So going to a code retreat was one of the best things I've done yet and will continue to do so.  I have attended user group meetings, stuff like that which are great, and you talk a lot of code and meet a lot of people but where and when do you actually get a chance to pair with other people and continue on your journey to become a better craftsman?

The difference between a meet up and a code retreat is you really feel like you've gained a lot more when you go to a code retreat IMO.

I figured it had to be worth the time.  After all, yesterday was National Code Retreat Day. After all, Corey Haines will there and a bunch of Software Craftsman.  I realized that this is something I should have been going to years ago.

A Bit About 8thLight

The code retreat was hosted by a great company, 8th Light.  

If you are not familiar with 8th Light, are you familiar with Uncle Bob Martin?  Well, he's the Master Craftsman at 8th Light, and his son Micah Martin is the founder of 8th Light, while Paul Pagel is the CEO of 8th Light.  What better place could you be for a code retreat. 

8th Light's core lies in practices such as TDD and pair programming.  Also 8th Light has played a big role in defining and pushing Software Craftsmanship throughout the world, including a most recent Conference @SCNA which is an event that they run which started years ago.

Here's the breakdown of what I saw in terms of "People"


   (picture borrowed via Corey Haines Twitter Post)

remember these are only my best guesses / ball park:
  • Approx 40 developers total
  • A handful of 8th Lighters.  I don't know, mabye 6?  My guess is that most are already in good hands by working at 8th light to begin with so might not make sense to see a lot of them there
  • 35% of the developers hadn't done TDD before
  • Corey Haines was there..and I personally got some great advice about outside-in vs. inside-out that I'll talk about in my next blog post
National Code Retreat Day

check out #gdcr15 on twitter for chatter and pics.
Yesterday was Global Code Retreat Day.  This happens every year.  

The idea of a code retreat started with Corey Haines (@coreyhaines ).  He hosts the national code retreat website and data store where these retreats are registered, and all the info you need about a code retreat.  

Corey also has a nice video on CleanCoders.com where he BDD'd some of that site or at least used that site as the basis for teaching outside-in test driven development in that video.

There were 143 code retreats yesterday running around the globe yesterday and that number has been increasing year after year.  

Don't Fret it

Even though I am fairly decent at TDD (so I think ;)) I am always looking to improve and have room to improve.   So even knowing a bit of TDD, I was a little apprehensive the day before, as I've only been coding .NET and lately all Node.js which I plan on continuing on with.  JavaScript is my passion (for the time being at least), however there are other great languages out there such as Go, Clojure, Ruby that I'd like to play more with.  I know there's a crap load of Ruby. 

I was thinking how the heck will I be efficient at a code retreat coding something like Ruby, or Go, or Clojure if I've never played with it yet?  I thought if I don't find a pair who does JavaScript, will I be a bottleneck?  And when the retreat started I found I wasn't the only one who had those thoughts.

So what did I do on the way there? In my SUV, I listened to a YouTube vid on Ruby and realize how freakin nice and easy that language is.  Which means I'll probably now play with it much more just for the sake of being diverse as well.  Node.js is great and all, but Go, Ruby, and Clojure are just as awesome.  Some might argue though Ruby is going bye bye (I'm sure I'll get hit over the head by some for saying that:)).  Doesn't mean I wouldn't code in it or enjoy coding in it though.

What Ended Up Happening?

The host of the retreat ended up encouraging everyone to find partners who programmed in the programming language you are most comfortable with.  Well for me, that's Node.js at the moment and I really didn't wanna do .NET TBH :).  Luckily, a lot of people do JavaScript obviously so it wasn't hard to find pairs that day.  

The host also recommended though to try one language you're curious about and purposely pair with someone who knows a language you don't.  So I found a fella who codes at Sumaritan Ministries.  They do TDD there as well.  They're into a lot of CoffeeScript so he drove during Ping Pong and I implemented to make some of his tests pass.  CoffeeScript is pretty elegant, so it was a lot of fun to work with.

What ended up happening is that most the time devs came and used my existing Node.js test setup with WebStorm, and we coded Mocha.js + Chai.js tests so I was right at home with it and they liked that too.

45 Minute Sessions, then Switch Pairs

You can't get any better than this.  Being able to pair with multiple people on one day.

You bring your laptop.  8th Light already had huge Mac Monitors, and most all had Macbook Pros there so we just hooked up to the monitors, add a couple extra keyboards to each monitor so we can both have a keyboard and you're off pairing.

For me, I love to pair.  I love to TDD all the time.  And what's great about a code retreat is the following:

1) You're practicing by doing a code Kata together with your pair, very simplistic and small scoped segments of code
2) You're doing TDD the whole day
3) You rotate pairs every 45 minutes
4) You delete your code after every 45 minutes and start over with a new pair
5) If you don't like the code you wrote with a previous pair don't worry, you are forced to scrap any code you wrote anyway

Which provides a lot of pluses:

1) With the next pair, you are expected not to think back necessarily how you just implemented production code with the last pair, but encouraged to rethink how to approach the problem, and with new constraints dictated by the code retreat format
2) Any embarrassing code, is gone :).  It's like starting fresh, meeting a new person again, and starting from scratch with your ideas and theirs
3) You learn a lot both code but also approaches to Test Driven or clean code and get a chance to utilize different test frameworks
4) You aren't just shaking hands and having one casual conversation like you would at a meet up, you're having many conversations and your'e coding with people.  This is networking at its best
5) You get to share how you code and share ideas and also gain insight and other ideas from people since they have their code running on their laptop as well
6) The point of a code retreat is not that you can finish the problem.  In fact they design it so you can't!  Nobody finished the Conway's Game of Life Kata Yesterday, not even close.  
7) Everyone there had passion to learn, that's important

What's the Goal?

The point of the retreat is that you slow yourself down a bit and learn.  You don't rush.  All the things we should be doing in our jobs that many employers don't encourage but should be.  And you therefore learn how to become a better coder as a result.

You focus on clean code, simple design principals, and TDD. 

You learn about the 4 Rules of Simple Design   It's the total opposite of a Hackathon..just was looking for lately.

You continue practicing TDD with people who have different experiences and levels of doing it.  

What If I don't know TDD?

Fortunately I got lucky and was able to learn a ton from some guys at 8th Light who I was able to pair with at a previous company for a few months.  However, most people don't get that stroke of luck.  And I call that a huge stroke of luck because as far as I was told at the time, 8th Light doesn't usually go to .NET shops at least not as much (anyone correct me if wrong).

And even so I still have a lot I can improve on and learn as stated earlier.  Before that though, I was like everyone else, trying to self teach myself TDD and it's not easy at first. 

So the best advice I can give any programmer is that: Pairing is the way to go.  By paring,  you work with people who know it well already and want to share their knowledge.  And so I felt that I learned 2 years of proper TDD and design in just 4-5 months.  I didn't learn everything by any means but enough to really make a dent in the way I program and deliver code.

Mentoring!

So the format of code retreat facilitates the concept of mentoring.

Not everyone is a TDD master at a code retreat.  There are always a handful of people looking to be engaged in the retreat, and so what do we do?  Those who know TDD pair up with those who don't. Mentoring!  And it's so nice to see devs who have a passion to learn it just as continue to strive to get better and better at it myself as well.

If you do not know TDD but have a passion to learn, this would be a great place to start if your current place of employment doesn't TDD or if you are trying to self teach.  It's better to learn from others with TDD, you'll bridge that gap quicker and learn the right ways to TDD.

So go!  I can tell you right now from my first experience at the retreat you have nothing to sweat.  So what if you don't know it.  The worst case would be, you'd be the one writing the code to make the test that your partner writes pass.  So they'll write the tests, you'll see how that's done, and you'll immediately start seeing the benefits of TDD, trust me.  Even if this is your first time seeing and doing it with them.

We're all In It Together to Share & Learn

The environment is friendly at a code retreat.  Nobody is stuck on themselves, and everyone is very open and listens well to each other.  It's a give and take, and it works very well.

Those of you who are new to TDD.  Devs who do TDD are generally very nice.  I have yet to meet a fellow pair programmer doing TDD who wasn't.  Devs who do TDD do not going to think badly of you if you don't know anything, they want you to learn and succeed.  This is part of Software Craftsmanship.  If anything they're Software Craftsman which means they want to mentor people.  

Software Craftsmanship

See..that's the entire mindset that the Software Craftsmanship movement is all about which people are embracing more and more.  Devs who TDD have already embraced that fully so you're in good hands.  See the Software Craftsmanship Manifesto for more info on what formally defines a software craftsman in terms of this particular movement to better our industry.

Where Do I Go From Here?

Well currently I'm looking to land myself onto a culture and team that is very into TDD already...it's where I belong and have wanted to be for a while now.  Finding those teams is hard.  They exist, but for me in terms of Chicago, they're not in the Suburbs.  They are typically downtown.  So looking there for employment is the best place if you're in Chicago and want to find some Software Craftsman doing TDD.   TDD is just not prevalent yet in the burbs of Chicago. 

I am working on things in the meantime

Eventually I'll expose info that's going to help many people find shops like this, events, people, you name it.  I hope to get that done in the next year or so.  Once that site is running, I'll post a blog post about it and I'd like your feedback.

so, if you or your team does TDD, please follow @WeDoTDD on Twitter, highly appreciate it.


Saturday, September 5, 2015

Learning The Clean Architecture and Applying it While Doing BDD

The Clean Architecture



Uncle Bob Martin's Clean Architecture is one that I am aspiring to model my applications and Services by currently.


I realized that after thinking about it, when I was pairing with a couple 8th light guys in the past at a previous company, that they were implementing some of the Clean Architecture in our Web Service code.  At the time, I was not aware of the Clean Architecture Model (Onion).  I was defintely aware of creating layers and did create layers such as Repository, Business Objects, and all that.


But I realized that how I was doing that prior, wasn't quite clean.


So I am suggesting that if you really wanna build your architecture in a very simple and decoupled manor, I'm advocating The Clean Architecture model.  It very much mirrors the Hexagonal Architecture Model.


So if you would like to venture off learning more about it, then I suggest going about it in a certain fashion, and to go through these resources in a specific order below.  This order really helped me understand Applying the Clean Architecture (patterns, layers, etc.) along with incorporating that while you TDD the actual implementation.


Here's the order I suggest (my prescription).  There is specific content in here that piggies on one another.


Make these worth your while:

  • Set aside true quiet time away from kids or whatever..in your man cave if you have one
  • Watch each video in full.  Yes unfortunately this takes time and dedication.  Take a Saturday to do it, do it at night for 2-3 hours;...whatever you have to do to find time to watch each of these in full.  If you wanna learn, you gotta sacrifice.  But these resources are truly great ones below, you won't be sorry
  • Concentrate.  Listen to everything said very carefully, and definitely take notes..I always go back to my notes, I don't wanna re-watch it 100 times because I forgot everything
  • It'll take you weeks to get through all these but seriously watch them all, again the order here is important

First, Understand Clean Architecture



Then Understand Hexagonal Architecture 

  • The watch Decoupling from ASP.NET - Hexagonal Architectures in .NET - nevermind that this is titled .NET, Ian keeps things applicable and terms are not really geared toward .NET so this is a good watch for anyone .NET or not
    • A deep dive into truly understanding Hexagonal.  And Ian explains it like no other

Then Understand Keeping Things Simple

  • Then watch Rails Conf 2012 Keynote: Simplicity Matters by Rich Hickey
  • Then watch Keynote: 8 Lines of Code - which talks about how you really keep code simple, and the fact that you do not need to always use frameworks which can actually make things more complicated or totally unnecessary if you design your code in very small modulars.  (BTW, This is also is a big reason why I left .NET.  Microsoft pushes shitty frameworks, horrible xml driven frameworks, and more garbage down your throat when you just need simple, clean, decoupled code which means you end up not needing all those heavy frameworks Microsoft tries to push down your throat)
  • Then read Corey Haines's book 4 Rules of Simple Design 

Finally Get into the BDD 

This will apply some of what you learned above to actual code.

After you've watched and read the previous section, now is the time to understand proper BDD and applying the concepts above.



    Optional but a good Resource for later when you have time after all the above: Start Doing Real World TDD Now!.  This blog is by Eric Smith.  He's a developer I had the privilege to pair program a bit from 8th light, and he runs their training program at 8th Light, their Apprentice program.  

    I probably learned more in 5 months with Eric and another 8th Light Consultant that would have taken me 2 years to learn.  Honestly while the list above is awesome, the best way to learn BDD IMO is to pair with seasoned TDD'ists.  Get 8th Light to come into your company for a few months, year, whatever.  The benefits are exponential for your team and your company as I have experienced myself with these guys.

    Yes this is a lot to read up on and watch but I guarantee it'll help bridge the gap much sooner.

    Hoping this helps others as it has helped me bridge the gap with Clean Architecture, Hexagonal, Ports, Adapters, and how to approach this and separate this while doing test driven.

    Thursday, September 3, 2015

    Testing the Koa.js Response Context through koa-controller


    Today I was test driving some new endpoints for my Node.js REST API.  I decide it was time to add koa-controller so that I could manage routes better and also map them to controller actions.

    koa.js

    I'm using koa.js for building out our new REST API in Node.js.

    koa uses generator functions.  When you create a koa route, like anything, you can grab the request context and set the response context.

    koa-controller

    koa-controller adds in support for matching routes with controllers and actions.

    A koa-controller receives the koa request context and then in your controller action, you can process the context.  And then set the context's response data, etc which koa uses to send back the http response.

    With this middleware, I had created an initial action function as so in my controller:

    (I apologize for shitty blogger and the lack of formatting below.  I'm working on moving this blog to some other platform)

    module.exports = {
        find: function *(){
            var response = this;
            response.statusCode = 200;

            _gateway.find(function(foundData){
                if(!foundData || Object.keys(foundData).length === 0){
                    response.body = null;
                    response.statusCode = 204;
                }

                response.body = foundData;
            });
        }
    };

    problem is, how can my test get back the koa context to test whether my controller did what it was supposed to?  Right now, koa-controller passes back the context automatically.  But I wanna catch it for testing in my unit tests.

    You can't just do a return response and we want to keep our functions async anyway and use callbacks (ideally promises) along with generators not because "it's cool"...but because it's necessary and also required by koa in the first place to be using generators for this.

    Technically I should mock the koa context because I'm not testing koa; I wanna be testing  the logic I wrote in my controller only.  That'll be next.  But I wanted to figure out how I'd get the context back regardless first.

    Generator Functions Save the Day

    Since my action function has to be a generator function for koa-controller, that means I could use yield to return the context if I'd like.

    That also meant making my callback function a generator or else this wasn't gonna work.

    So here it is with yield and the callback generator function

    module.exports = {
        find: function *(){
            var response = this;
            response.statusCode = 200;

            _gateway.find(function*(foundData){
                if(!foundData || Object.keys(foundData).length === 0){
                    response.body = null;
                    response.statusCode = 204;
                }

                response.body = foundData;

                yield Object.create(response);
            });
        }
    };

    notice I simply added * to _gateway.find's callback function.

    Now you're probably wondering why I created another object here instead of just doing a yield response; 

    Well koa-controller is handling returning the koa context so when I tried that, it was conflicting with koa-controller core code.  

    So what I had to do is simply clone the context and return it.  Now it's independent of whatever process was handling the real context prior to this.

    My Mocha.js Test

    I use mocha.js for my BDD.

    So now I can can test the context's values that came back from the controller's find action function:

    it('should return no country when no country exists', function(done){
        var countries = {};
        countryMockGateway.setCountries(countries);
        countryController.gateway(countryMockGateway);

        var koaResponseContext = countryController.find().next().value;

        should.not.exist(koaResponseContext.body);
        koaResponseContext.statusCode.should.equal(204);
        done();
    });

    ES5

    With ES5, you can easily clone which was very hard to do prior with simply Object.create().

    So the next time your architect tells you "We don't need to be using new stuff like ES6, that's overboard", you can tell him he's full of garbage.  I didn't have an architect who did that where I"m working but I have in the past.  So here's a good use case for testing and using generators and cloning to easily accomplish what would have probably been a tangled mess of code to do the same thing prior to ES5.