On YouTube
210 JSJ The 80/20 Guide to ES2015 Generators with Valeri Karpov

01:56 - Valeri Karpov Introduction

02:17 - Booster Fuels

03:06 - ES2015 Generators

05:47 - try-catch

07:49 - Generator Function vs Object

10:39 - Generator Use Cases

12:02 - Why in ES6 would they come out with both native promises and generators?

14:04 - yield star and async await 

17:06 - Wrapping a Generator in a Promise

19:51 - Testing

20:56 - Use on the Front-end

22:14 - The 80/20 Guide to ES2015 Generators by Valeri Karpov and Tech Writing

Picks

Why and How Testing Can Make You Happier (Aimee)
Pitango Gelato (Aimee)
The Primal Blueprint by Mark Sisson (Chuck)
The Primal Blueprint 21-Day Total Body Transformation (Chuck)
acquit (Valeri)
nightmare (Valeri)
now (Valeri)
The 80/20 Guide to ES2015 Generators by Valeri Karpov (Valeri)

Special Guest: Valeri Karpov.

 
[This episode is sponsored by Frontend Masters. They have a terrific lineup of live courses you can attend either online or in person. They also have a terrific backlog of courses you can watch including JavaScript the Good Parts, Build Web Applications with Node.js, AngularJS In-Depth, and Advanced JavaScript. You can go check them out at FrontEndMasters.com.]

Hey everybody and welcome to episode 210 of the JavaScript Jabber Show. This week on our panel we have Aimee Knight.

Hello.

I'm Charles Max Wood from DevChat.tv. Quick shout-out for React Remote Conf coming up in about a month. We also have a special guest this week and that's Valeri Karpov.

Thanks, Chuck. As Chuck mentioned, my name is Valeri Karpov. I'm formerly MongoDB. I now work doing Node for a small startup called Booster Fuels. They do on-demand gas delivery. And I'm here to talk about my new eBook, 'The 80/20 Guide to ES2015 Generators'.

So, I have to ask because I'm having this vision of a tanker pulling up outside my house. Gas deliveries?

Yeah. We focus primarily on large corporate parking lots. So, we wouldn't be able to fuel you up at your house.

Aww.

Corporate parking lots tend to be a little bit more controlled environments.

Gotcha. So, people just pull in and you fuel the fleet.

More or less. The general idea is you go, you drive into work in the morning. You pull out your phone, you tell us where your car is and that fact that you want it to get fueled up. Over the course of the day somebody comes, fuels it up, and when you're ready to go home from work you've got a full gas tank, windshield wiped, and you ended up saving money on gas because we actually undercut local area gas stations.

Oh, that makes sense. So, we brought you on today now that we've talked about gas, is generators. And not gas generators but actual ES 2015 generators. Do you want to give us the high-level view of what they are?

Sure. At a conceptual level a generator function is a function that can pause its execution and resume executing at some later point when somebody else tells it to start executing. In the book I discuss, I defined them as functions that allow reentry. So, when you return from a function the function is done forever. The stack frame is gone for good. With a generator the function can yield and then it can pick up where it left off at a later time.

So, does it get allocated on the stack then or does it go on the heap as an actual object?

So, a generator function is effectively a constructor for a generator object. So, that technically goes on the heap. But I don't really know the exact details myself. But I imagine it has something to do with how closures work. I don't really know the particular details on how memory management works for generators.

Okay.

Okay. That's really interesting what you just said, because when you create one you don't call new on it though?

No. It's a… so, a generator function is something that you call to get back a generator object. So, it's technically not a constructor. You don't have to call it with new.

Okay, okay. So, I was just making sure. Because when you said constructor… because I know the stuff I've looked at you don't call new on it. But if it's a constructor I was like, “Well, wait a minute. Now I'm really confused.” [Laughs]

Yeah, sorry.

Yeah. But…

Incorrect terminology.

Yeah, but the idea is similar, right? That it's effectively a factory for generator objects.

Yes, exactly.

And the difference is yeah, it's more implicit when you're talking about a factory than when you're talking about a constructor.

Yeah. And what makes generators really exciting in my mind and what really got me into them was the library Co by TJ. Basically a flow control library, lets you write async code without any callbacks, without calling .then, without having to really worry about promises or anything like that, and also gives you consistent error-handling behavior. So, you can use try/catch to catch asynchronous errors as well as logical errors. So, you can use try/catch to say catch errors that would occur from say, I don't know, undefined variable as well as errors that would occur if say, an HTTP request couldn't reach the particular URL.

Yeah, but how do you actually use, I don't know if I quite follow that. So, I understand try/catch. I've used several languages that use it more heavily than I've used it in Ruby or JavaScript. But I'm wondering. So, how does try/catch play into generators or vice versa? So, [how do you use] a generator to manage error states or things that are thrown?

So, a generator object has two functions on it, or more functions than that probably but there are two that are really important, which are .next and .throw. So, when a generator pauses its execution using yield the function that's interacting with the generator object can call .throw on the generator object. And within the generator function that will look like the yield statement threw an exception which then you can handle with a try/catch.

A try/catch inside of the generator you mean?

Yeah, a try/catch inside of the generator function. One of the things that are necessary to distinguish here is a generator function which defines the logic flow for how a generator works and then an actual generator object which is an instantiation of the generator function that you could call next and throw on. So, next will resume the execution wherever it left off and throw will resume execution but also trigger an error so you can do a try/catch. So fundamentally, how a library like Co works is let's say a generator function yields a promise. What you can do is take that promise, do .then on it and then resume the generator's execution when the promise has resolved. Or if the promise errored, you'd do a .throw on the generator.

So, what you get back is an iterable, correct?

So, a generator object is an iterable but… no, a generator function is an iterable but a generator object is not.

Okay.

So, I think the classic example that I see for generators is something like the Fibonacci sequence where effectively you're putting out a series of numbers. And so, when you call .next you just get the next number in the series. I'm a little bit confused I guess in the distinction there between the generator object and the generator function if I'm getting an integer back from some of these.

So, a generator function is the function star declaration, right?

Mmhmm.

That creates a new generator function. And to create a generator which is the common name for a generator object, you call the generator function.

Okay. And then once you have the generator object that's what you're calling .next on in order to get the next number in the Fibonacci sequence?

Yes, exactly. Now actually, a very interesting example that I go into a lot of detail in my book [is] about the Fibonacci sequence. So, the nice, neat thing about generators is it also lets you separate the scheduling of when code runs from the actual logic itself. So, one particular example that I go into is an asynchronous Fibonacci computation. So, let's say you want to compute the billionth Fibonacci number without blocking the event loop. With generators or if you wrote the Fibonacci logic with generators you'd say yield any time you compute any number. It's very easy. You just put generator.next in a set interval. And now you're basically computing the next Fibonacci number on say every iteration of the event loop or every second.

Yeah, but if you need the millionth one is there a way to skip next 1,000 or 1,000th next or something like that?

Yes, but if you write the Fibonacci computation logic, the actual logic that does the actual for loop for computing the Fibonacci sequence, and it yields every time it computes a new Fibonacci number you can compute the Fibonacci sequence however you want. You can compute it in a set interval computing a new Fibonacci number every second. You can say compute a thousand and then wake up in another second and compute the next thousand, so on and so forth. So, the scheduling of when you compute the next Fibonacci number is actually completely independent of the logic of actually computing the Fibonacci number.

Right, and that's ultimately the power of generators, right, is that your logic and the state that's involved in executing that logic is tied up in the generator. And the timing is just whenever you come around and say next.

Yeah, exactly.

So, where do we see people using this? You mentioned the Co library. What are some of the other applications for generators?

I think Co is the 80/20 of it. Co really does a very good job of letting you do good flow control right now in modern JavaScript. People always talk about async/await but on the other hand I spent a good portion of last year working on a MongoDB ODM based on Object.observe. So, I know very well firsthand what happens when you rely on a stage three TC39 proposal, because well…

Just because it's a stage three doesn't mean that it's ever going to be in the language. So, if you use Co you get the same behavior as async/await with slightly different syntax. Actually, transpilers that transpile async/await pretty much compile down into Co, which is kind of funny. But yeah, so that's the most important use case. That's actually the one that I've used most often. The only other use case that I really see is the ability to break up long-running computations, which is another interesting thing in JavaScript. Because well, since JavaScript is single-threaded, at least before generators, there was really no good way for you to say, break up a really long-running calculation that would block the event loop in a very good way, like calculating the billionth Fibonacci number. Now with generators you can.

Before we go a lot further and to give people context, I think one question that is commonly asked, so why in ES 6 would they come out with promises, [inaudible] promises, and generators? What is the use case for having both?

They're not necessarily competing proposals. They're very much complementary, I think. For instance, what generators are about for me is primarily Co and the web framework Koa. That's the big use case that I see. But those don't really work as well without promises because the thing is, in order for Co to work you need to be able to yield an object, some sort of object. And that object needs to be able to encapsulate the state of an asynchronous operation. And that's why promises end up being a very nice fit for how Co works. When you yield a promise, Co is smart enough to do a .then on the promise and resume execution whenever the promise has resolved or errored. And with an old style callback you couldn't really do that because you didn't really have an object representation. There are other asynchronous objects that you can use like a thunk. But thunks aren't quite as clean as promises in terms of error-handling.

So, to make sure I understand too, I'm not sure if this is something with just generators like the spec or a Koa thing, but I should also be able to yield to another generator. Is that correct as far as the spec or is that just a Koa thing?

Not necessarily unless you use the yield star operator. But in most cases you don't have to do that. Co is actually smart enough to take… to let you yield on a generator function.

Okay, okay.

So, internally what Co does is say, okay if you yielded a generator function I'm just going to wrap that in a call to Co itself and pretend that it's a promise.

Okay. So, what does yield star do? And that's native, then?

Yield star is native. And Yield star basically takes in, I can't remember if it's a generator function or a generator object or both. But general idea is it takes in a generator and basically yields everything that that generator would. So, if you do yield star Fibonacci of five, that's the same as saying “Okay, yield the first Fibonacci number, yield the second, yield the third, yield the fourth, yield the fifth.”

Okay. And then we talked a little bit a minute ago about async/await. So, do you think that async/await is something valuable or better than generators? Or do you think that there's no need for it?

I have yet to really see a use case where async/await has an advantage over Co and yield. I'm not saying that it doesn't exist because I haven't used async/await that much beyond a simple hello world example. My current argument is just Co and yield works with the current established JavaScript spec. it works with ES 2015 with no transpilers or anything. Whereas async/await you would need to transpile it and you don't have any idea if say the proposal's going to get withdrawn or changed at any point in the future or if the proposal will ever get into the language at all anyway.

Yeah. What about people who get really fired up about this stuff? [Laughs] Say I have promises. Those are working just fine for me. Is there, other than it's better on the eyes, are there specific benefits? Well obviously too, you can't necessarily do the exact same thing. But if you were using generators just for in place of promises do you think there are other added benefits there?

I think probably the biggest advantage is a common error-handling. Well, common error-handling. So, when you have say a bunch of operations with promises you always have to remember to say .catch them. You need to… that gets a little bit messy after a while. With Co if you're yielding promises you can do a nice little .catch at the very end of your Co call because what the Co function actually returns is a promise. So, then you can say I've written a bunch of logic. If it crashes at any point, catch it with this error handler. Which actually ends up saving me an awful lot of headache these days because well yeah, I occasionally forget to do .catch on a promise or something like that and it just goes wrong. People often complain about people misusing promises by not specifying .catch or not specifying error handlers.

Yeah.

With Co it makes it an awful lot easier to just define a catch-all error handler for your entire say REST API routes or your entire Redux middleware handler or whatever.

So, I get the idea of maybe wrapping a promise in a generator and we've talked a bit about that. I'm curious though why you would wrap a generator in a promise like what Co does. I'm looking at Co right now with its example. What does that give you? Because it seems like, I think about the generators as kind of an ongoing stream where I can… or an ongoing place where I can keep going back and getting more stuff, more values, more whatever out of it. So, if I go back to it, if I wrap it in a promise, the promise seems like it's a one-time deal where I call .then on it and it resolves and I'm done with the promise.

Yes.

So, how do the two resolve themselves together that way?

So, a generator doesn't necessarily have to be infinite. It can terminate after a certain period of time. And the point of wrapping, of Co wrapping its generator function in a promise is essentially that when you're writing a generator function that you want to pass into Co what you're doing is you are basically yielding promises and then resuming execution when that promise has resolved. So, it lets you write very simple, clean code where you say, “Okay, yield superagent .get to make an HTTP request to Google.com. I assign that to a variable like const google_homepage_html. I manipulate the HTML and I'm done. And say, return it.” Now, Co gives you a nice, neat wrapper around that where you could say, “Okay, I'm going to write all of this logic that's going to yield a bunch of promises and then at the very end I'm going to get back the final return value of my logic.” So, I guess it's a sort of different way of thinking about generators. It's a way of… Co necessarily is more about…

It's about workflow.

Yeah.

It's not about managing a stream or series of values.

Yes, exactly. It's more about coordinating and composing asynchronous code than it is necessarily about generating values.

I think there's an article that I read that I felt like worded this really, really well. And it was by @getify or Kyle Simpson. But he says when you yield, it's like you're making a request. And then when you call next then you're getting a response.

Yeah.

Like, think of it that way.

Yeah.

Yeah.

And again, the big part of chapter two of the book or the point of it is to build you up to writing your own Co from scratch. Co itself is not a terribly complex library. And actually, you can pretty much implement your own in about 50 lines of JavaScript. Just I feel like it's one of the best ways to learn generators is to really understand at a deep level how Co works.

So, one thing I'm also wondering about with generators in general is testing. So, I think when we talk about asynchronous programming people's heads explode when they go, “Okay, now I'm going to test this. Wait, what?” So, how do you get around that? Do you use some of the same techniques you use for other asynchronous programming? Are there specialized tools or techniques for testing generators?

I actually find Co to be an absolute godsend for testing. And that's actually where I first started using it was integration testing for my APIs. So, when I say, create an Express app and I have an API to say get all logged in users right now, when I… using Co and something like say superagent or whatever HTTP client you prefer, it comes really easy to just do things like, “Oh, okay. Let me insert a bunch of data into the database using a yield. And then I'm going to do a superagent .get on the route that I'm trying to test, make sure that I got back the correct results, wipe out the database, go onto the next test.”

Gotcha. One other thing that I'm seeing here is that it says on Co, the ultimate generator-based flow control goodness for Node.js. So, is this not well-suited for the frontend?

Actually, it works just fine if you pipe it through Babel. At Booster we actually have a couple of cases where yeah, we use Co in frontend code. It was initially written for Node.js but that was before the rise of Babel and the rise of transpilers for ES 2015 into ES 5.

So, that's really interesting. Can you talk about that more? Because I am only familiar with it being used on the backend.

I think right now our primary use case involves just Redux middleware in our mobile app. Our action creators use Co to build up a promise that can then be handled by the Redux middleware. So, do things like, “Oh okay, load the current user. And if we [inaudible] the current user, let me do this thing. Otherwise let me do this thing.”

Okay. Is that something that you guys have built yourselves or is there actually a library out there that you can use?

I'm pretty sure there are Redux middleware for promises libraries or a library out there that does, that gives you a Redux middleware for handling promises. We actually wrote our own. I don't know off the top of my head. It's a very simple thing to do.

So, in an attempt to allow you to sound humble, I'm going to ask you about your book.

Oh, okay.

That way you don't have to bring it up yourself. But anyway, I'm curious. What are you hoping that people get out of the book? Is it generally what we've talked about here on the show? Or are there other things in the book that people are going to learn that we just don't have the time or the proper medium to actually demonstrate in an audio podcast?

Yeah. The focus of the book is to give you a very clean, concise guide to generators as defined in the ES 2015 spec. And in order to build you up to having a good understanding it walks you through building your own version of Co, of Koa which is sort of a web framework Express-like thing based on Co, and Regenerator which is Facebook's transpiler that transpiles generators into ES 5 code. So, basically build out a quick proof of concept for Co, Koa, and Regenerator over the course of about five chapters. And once you're done with that hopefully you have… you're pretty much an expert on generators or at least comfortable enough to use Co and Koa in production.

And is Koa just a backend framework?

Yeah. Imagine Express but using generators for middleware. So, instead of doing say, instead of calling next as a function you do yield next and you get the same result.

Yeah, I think we did an episode on it a long time ago. We should probably revisit it.

Yeah. Koa is a very powerful library. The book primarily focuses though on Koa Compose, which is the npm module that enables Koa to use generator-based middleware. So, the yield next paradigm.

Gotcha.

And I think the other pretty interesting thing about the book is that I built it as an experiment in how to scale test-driven tech writing. Because actually, the book is fundamentally in its uncompiled form it's literally just a Mocha test suite and a bunch of Markdown files. So, I actually wrote it using basically writing tests first then writing a bunch of Markdown to explain the tests and then compiling that all into a nice little, neat PDF.

You'd be surprised how many other tech writers, programming writers I know that have a similar setup one way or the other. And effectively yeah, that's what they do. Can you yield from a generator more than once in a single .next call?

No, because .next executes until the next yield statement.

Okay. So, I can have multiple yield statements then in my generator and it'll just go down the line until it hits them all?

Yeah, exactly. The neat thing about generators is that you can say, you can wield within a for loop. And with Co actually it makes it very easy to do things like retry if something failed, because you say, wrap it in a while loop while this request hasn't succeeded, try yielding it. If it fails, retry. Otherwise, break out of the loop. It lets you use the old synchronous style paradigms with asynchronous code.

That's actually really slick. Because you just call .next and it tries again. Yeah, I really like that. Until you get an actual value out of it. It's not, “Oh darn, it failed.”

Yeah.

Huh.

Yeah. One of the reasons why I really wrote this book was it was just… it was difficult to make junior devs comfortable with things like, oh okay, if say yielding in a for loop or yielding in an if statement in a generator function and passing that into Co. They for some reason always think like, “Oh, this can't possibly work, can it?” And the long and short of it is yes, it does work.

That actually brings me to another question. So, this book is so nice but do you think there should be any fear that it's abstracting so much that you're not really understanding very clearly what it's abstracting.

That's what the book is for.

It's a [inaudible] library. You could very easily understand what's going on there if you either read my book or just go dig into the source code. It's not particularly complicated. Just the general idea is pretty simple. I don't really think it abstracts away too much. And that's one thing that I actually really like about it, is it's a simple enough abstraction where you can just grok it in an hour. But it's also sufficiently powerful that it really changes how you would write asynchronous code and makes things an awful lot cleaner.

Yeah.

So, how long is your book?

It's exactly 50 pages.

I was going to say, it sounds so simple. I was going to say, if it's like a 500-page book we're missing something. But yeah, 50 pages, that makes sense with where we've gone here.

Yeah.

That makes a lot more sense, yeah. [Chuckles]

Yeah. Meant to be a very short, targeted, concise guide. Like, you sit down, read it in an hour or two. It's another thing I always hated about tech books was I could never finish a tech book. I always just get about 200 pages in and then I give up.

Yeah, I kind of came to a place with that yesterday. I was talking to a podcast listener and she asked me, “What did people do before the internet to get help?” And I said, “Well you know all those tech books that you see that you can buy that are like 600 pages long?” And she's like, “Yeah.” I said, “Those are reference manuals for a reason. And they were writing those in the late 80s, early 90s, before we had the web and had Stack Overflow and Google and other nice places to look, because that's where they had to find those answers.” And I think we have a lot of carryover from that, where the publishing companies still expect a technical book to be a comprehensive manual instead of a short treatment of a simple topic that gives you the pieces you need to actually go build something, with the assumption that there are good resources for the edge cases somewhere else.

Yeah. That's a fair point. That's kind of a different way of saying what I was thinking as well, which is tech books tend to try to be everything for everyone and not realizing that oh, typically somebody is just going to look up the answer to a question on Stack Overflow rather than going through a book that they had previously read and go into the right page. So, what I think that the future of tech writing can be is that a book would be more of something that's slightly bigger than a blog post but still sufficiently concise that you can read through it and understand what it's trying to get at. So, sort of a consolidation of a bunch of Stack Overflow answers into one readable, digestible format where you sit down for an hour. And it makes it so that you don't have to go find a bunch of different resources yourself. But the key point there is it needs to be something they can digest quickly. I don't really think in the future we're going to be sitting around for about three weeks reading an 'Atlas Shrugged' like [inaudible] tome of an Angular book.

Yeah, I agree.

How old is the book? Because I'm kind of curious what your process was in putting it together.

Oh, the book was released I believe January 26th of this year, give or take.

Okay.

But yeah, the process was generally I wrote an outline, I wrote a bunch of tests, I wrote some Markdown, I played around with a bunch of different libraries to figure out how I could compile my test suite into a PDF. Ended up using a transpiler that I wrote a few years back that transpiles Mocha test suites into Markdown and a browser automation library called Nightmare. It's built by the guys over at Segment, the analytics company. It gives you a very nice ability to render a page in print mode and then compile that into a PDF.

Have you written other things in the past?

Actually, yes. This is my second book. My first book was published by Wiley. It was 'Professional AngularJS'. So, it was Wiley's big tome about Angular.

So, there are some…

So you… I was going to say, you know about those big, long comprehensive books.

Oh yeah, I wrote one. And yeah, I think this new book was meant to address a couple of shortcomings I've found with the end product of 'Professional AngularJS'. It's a great book and a very detailed nitty-gritty guide to Angular. But one thing that we did with that book was we broke it up into individual chapters. So, each chapter was kind of its own digestible chunk. But that ended up being a little bit hard to manage for a book that was as long as that was. Because we needed to make sure that, okay, chapter 8 doesn't rely on anything in chapter 4 or 3 so we don't ask you to go back and say, okay, you need to read that if you want to just learn about say how data binding works. That ended up being a little bit of a mess and I don't think we did as good of a job of that as we would like. The other problem was it was just very old-school because we were writing everything in Microsoft Word. So, I didn't really have say a full test suite for all of my examples from the book. So occasionally, the technical editor would go in and find a glaring bug in the source code and I'd be like, “Oh, oops. Sorry.”

Nice. So, I have one more question for you and that is: are you coming out to ng-conf?

Actually, I don't think so. But I don't really know when it is. I don't watch the CFPs as much as I should.

Alright. Well, if you are coming out to ng-conf I'm just going to put this out there and then we'll get to picks, or you're going to be in the Salt Lake City area around May 5th, the conference is the 4th through the 6th. We're going to do a meetup, a get-together. So, most of the JavaScript Jabber hosts live here. Most of the Adventures in Angular hosts are coming out for the conference. And there are a few other folks that are on other various DevChat shows that are also local people. So, if you want to come out and meet some of us we will be somewhere in downtown Salt Lake on May 5th. And considering that it's the 21st of April now, I should probably finalize that and tell people where we're going to be. But yeah, so keep an ear out. If you're on the mailing list for any of the shows then you'll get that email. And you can get on those lists by going to DevChat.tv or JavaScriptJabber.com and either signing up to get the top 10 episodes of this show or just sign up to get notified when we have new episodes out.

Fun stuff. I booked my flight yesterday. So, I'll be out there, too.

Yay!

Great, thanks. Looking forward to it. I really look forward to checking it out.

Alright. Well, let's go ahead and get to some picks. Aimee, what are your picks?

Okay. Man, since we've been doing the Microsoft Build stuff I have a bunch. But I'm not going to spill them all at once. I'm going to save them up for the next couple of episodes. But anyways for today, I have one that I found and it's 'Why and How Testing Can Make You Happier'. I love testing. I love working in code that is highly tested. [Chuckles] So, if you are a developer who's kind of like, “Eh, tests” I think that this blog post will help you understand why testing, well like it says, will make you happier, why it's more than just like writing tests, why it can help you in the process of writing the code even if you don't really care so much about testing. So, that's my first pick.

And then my second pick, non-programming-related. If you're ever in the Baltimore or D.C. area I'm addicted to this ice cream. I only eat it on my cheat day Saturday because I try to eat really clean. But it's called Pitango. It's gelato. But they have all these crazy flavors and it's all from cows that are grass-fed. So, it's like healthy ice cream. But oh man, it's really, really good stuff. So, that's it for me this week.

Ooh, I want some healthy ice cream. Actually, [inaudible].

Oh my gosh, it's so good. They have these crazy flavors. They have one that's like black tea and just stuff that you wouldn't really think about normally. It's really good.

Yeah, I'm afraid I've been relegated to sorbets and that kind of thing because I'm [lactose] intolerant, but…

[Chuckles] Okay.

But yeah, it sounds so good. Every time somebody talks about ice cream or milkshakes I'm just like, “Oh.”

It's like, how badly do I not want to feel bad today?

Oh man, this stuff is so good. I'm addicted to it.

I just got to say that I love the fact that cheat day is such an established term now. [Laughter]

Right?

My cheat day is so not what it used to be though. When I was early 20s man, I would go all out.

Now it's like, very mellow.

You talk about early 20s like it's so much younger than what you are now.

I'm not disclosing my age. [Laughter]

Yeah, I am however old you think I look like I am.

I could make an educated guess. But you're a lady and I won't do that to you. [Laughter]

Okay.

Alright. I've got a couple of picks. I've been reading a couple of books. I've decided a while ago I needed to change my health. And I came across this program. And I hate to call it a diet because it really is a lifestyle change. They don't give you some sunset on it. “Do this until you lose a hundred pounds” or whatever. It's 'The Primal Blueprint'. I read the book by Mark Sisson.

Oh, that's wonderful. I've actually been Paleo, Primal since about 2009 and I've actually met Mark on about two or three occasions.

Nice.

Awesome. So, I…

He's a really great guy.

Yeah, I read that book and I read the 21-day start or whatever it is.

'The 21-day Primal Blueprint Transformation'?

Yeah, that one.

I have that sitting on my bookshelf. It's really good.

And then I bought his recipe book but not all the recipes are lactose-free friendly. So, I've been trying to figure out what I'm going to do with those. I'm probably just going to find some substitute like coconut milk or something. Anyway, I've really been enjoying reading those. I was going to start Primal eating this week but I didn't plan ahead well enough and so, I'm working on getting a meal plan together for next week, something that I'm comfortable doing for two or three weeks until I get in the groove and figure out what other things I want to try. Anyway, I'm really looking forward to it and I think it will really help with a number of things. I have type ii diabetes and it's relatively low-carb. In fact, a lot of the things that he talks about are a lot of things that if you go and read some of the literature about diabetes, they talk about the same stuff. It's just that they tell you to count carbs and he tells you not to eat carbs, which are kind of, or grains. So, it's kind of a different view on things and it's pretty interesting.

I don't know that I buy into the entire premise on Paleo as far as we should eat how Paleolithic humans eat and I think that's why I liked the Primal Blueprint where I didn't really care for the Paleo, is because Mark has done an immense amount of research into the biochemistry and other science behind how our bodies work. And so, when he was talking about how Paleolithic humans didn't have certain types of food, I could see that as an argument. But I feel like if that's the only argument it doesn't really hold water. But then he would go into, he would say when you eat grains it has these chemicals in it that do these kinds of things to you. And it causes this kind of response that has these effects in the body. And it's like, “Oh yeah. Well [chuckles] that's my problem my whole life.” So anyway, super great books. So, I'm going put those…

[Inaudible] Oh, sorry.

No, go ahead.

No, I was just saying he [inaudible] [chuckles].

Yeah. Well, but he talks about… he tows this as a lifestyle. And that's the other thing that I really dig.

Yeah.

Was that it's like, “Look, this stuff isn't good for you even if you're at the right weight and right whatever.”

Yeah.

So, don't eat it.

But at the same time they do offer that. If you have to take a day and cheat on it or if you're traveling and you have to fudge a little bit, then do as you got to do. But yeah, anyway I really like the book. So, I'll pick those and then I'll probably talk about where I'm at here in a month or so. But yeah, I have about 40 or 50 pounds to lose. My diabetes numbers could be better. And that would allow me to get life insurance for my family and things like that, in case I get hit by a bus. So anyway, that was a long-winded pick. Just call me David Brady.

[Chuckles] It's a great pick and best of luck to you Chuck, with your diet.

Yes. Go Chuck.

Well, it's not a diet. It's a living program. If I call it a diet I will fail.

If you've been doing it Valeri, I might shoot you some emails for some pointers.

Sure. I'm always happy to help.

Awesome. Why don't you give us some picks?

So, my first pick, I mentioned my transpiler that compiles Mocha tests into documentation going along with what Aimee said. So, the npm module is called Acquit, like being acquitted of a crime. [Chuckles] It's one of my, just don't write a module without it modules. It's a great tool for just quickly generating lightweight documentation from a test suite. Because ideally when you're writing something you're writing tests for it. So, why don't you just write docs as well? You just put comments inline with your Mocha tests and that all becomes a nice pretty Markdown file.

Number two is the Nightmare module that I mentioned. On npm it's just lowercase nightmare. It's a browser automation library based on Electron and written by the guys over at Segment. Surprisingly versatile browser automation because it only focuses on one “browser” and that's Electron. But it's a great PhantomJS alternative because it can actually spawn up an Electron window and let you see what's actually going on in the Electron window. So, you can actually visualize what your test suites are doing if something is going horribly wrong, which is really cool.

And another thing that I've actually been playing around with a lot of late is this new deployment tool called Now. It's by a company called Zeit, Z-E-I-T. It's basically a Heroku alternative or Heroku killer specifically for Node applications. You just type 'now' and you automatically get a URL to your Node project running in magical cloud land. So, you can pretty easily share little APIs that you're working on, little projects, with other people. And really cool, I'm looking forward to playing around with it some more.

And well, one last pick is my book, ES2015Generators.com, 80/20 Guide. It's really short, really concise, will get you up to speed on generators.

Alright. Are you on Twitter or anything where people can follow you?

Sure. On Twitter I am @code_barbarian. And you can find me on GitHub. My handle is V, as in the first letter of my first name, Karpov as in my last name, 15, one-five.

Awesome. Well, thank you for coming. We're going to go ahead and wrap this one up and we'll catch you all next week.