The panelists discuss zone.js with Brian Ford.

Special Guest: Brian Ford.

 

  Do your paychecks actually say Google at the top, or is it so big that they outsource even the payment of your checks to somebody else?

  Oh, I don’t know [chuckles]. I have direct deposit. I don’t…

  [Laughs]

  Hey everybody and welcome to episode 110 of the JavaScript Jabber Show. This week on our panel, we have Joe Eames.

  Hey there.

  Jamison Dance.

  Hello friends.

  I’m Charles Max Wood from DevChat.TV. And we have a special guest and that’s Brian Ford.

  Hello.

  So, we brought you on today to talk about Zone.js or Zones.js. 

  It’s Zone.js.

  I looked at it, but somebody said Zones somewhere. Then I got confused.

  Yeah.

  We first got to talk about Brian, though. Who is this man?

  So, I work at Google on the AngularJS team. So, I get to open source stuff fulltime. And one of the many open source projects that I’ve been working on is Zone.js. So, that’s what I’m going to talk about today. It’s something that we needed for Angular 2.0 but it was also something that we think is generally useful. So, it’s a microlibrary by itself. 

  So, I haven’t been following Angular 2.0 super closely, but I feel like there’s a theme of it being composed of a lot more integral chunks compared to Angular 1 where it’s a library and you use it all together. Is that true?

  Yeah, that’s totally true. It’s not like when we sat down to do Angular 1 we were like, “Hey, you know what would be cool? Is if we just wrote a ton of code and put it into a single JavaScript file and then you included that.” At the time, the JavaScript landscape was very different. And it wasn’t totally obvious whether CommonJS or AMD or what the situation was going to be around that. Node was just starting to get popular. And things like Browserify weren’t around. I don’t know. RequireJS might have been getting started around there. But the long story short is the tooling wasn’t necessarily that great when we started Angular 1. And so, it was [inaudible] expensive for us to build the thing that we wanted to and also split it up in all these different parts. 

  Sure.

  So, because the story is different now, it’s obvious. Why wouldn’t we just make a bunch of small libraries and then assemble them together?

  Yeah. That was a tangent. I just wanted to talk about it before we started talking about one of those small libraries.

  Oh yeah. [Chuckles] Yeah, I think this is an important point, because the JavaScript community is very much so against these big frameworks. But I think that’s kind of silly. At the end of the day, you’re going to assemble a lot of little parts together to make something big. And so, if you want to make something big, you should also expose little parts because code reuse is awesome. And we should have some more of that. 

  So, what exactly does Zone.js give you? I kind of got it and I kind of didn’t got it. So, maybe you could explain it to me and then I’ll really got it. [Chuckles]

  Then you’ll really got it. 

  I wasn’t sure at first. 

  [Chuckles]

  The last one let me know it was a joke. [Chuckles]

  Yeah. Zones, they do a lot of things. But the general idea is that it lets you have these hooks into the JavaScript VM at the asynchronous entry points and exit points. So, what this means is if you think about asynchronous programming, you have I guess what I’ve been calling them as tasks. So, your VM queues up all these async things and it does one of them synchronously. And then when it’s done, it goes and it looks in this queue and it pops the next thing off and does that. And what zones let you do is know when a task is starting and stopping and then attach behavior to it. It’s super abstract. But what it means is that you can execute some JavaScript before and after any sort of async event or any sort of async action happens in the web browser. 

  Oh, so you can hook in. So, an event handler is about to fire, but before it does you can hook into that and execute something.

  Yeah, exactly. And where this comes into play is let’s say you have some code and for this code you want to change the behavior of window.alert or something. So, that’s fine. You can set window.alert = myfunction. And then you run your code and then at the end of it you can set window.alert back to the original value that does the annoying alert box thing. The problem is, if you have asynchronous code, you can’t just patch the window and then un-patch it because the asynchronous code that you’re registering, let’s say you do a setTimeout, all of that will miss the patching. 

So, you’ll start at the top and you’ll synchronously patch, run some code, then queue up some async even, and then un-patch. And then the async code will run and it won’t have the patched window.alert. So, what zones let you do is it lets you do this patching or do this sort of thing, but before and after every single async task. So, you can make sure that anything that happens within a certain, I’ve been calling it an execution context, but basically anything that happens within some block of code, regardless of it fires off asynchronous things, it all has the same behavior.

  So, it also sounds like you can create a zone around a group of asynchronous things. Is that correct?

  Yeah. It’s transitive.

  So, it’s not just every… there’s not a separate hook for every asynchronous thing. You can group things together and say for this set of event handlers…

  Yes.

  Do this kind of preprocessing or whatever. It sounds like you could get some of the same benefits that domains in Node give you where you can get better error handling and stuff like that.

  Yeah, yeah. So domains, the solve some of the same problems that zones are trying to solve.

Domains, I think that they only really gave you this error handling ability.

  Yeah. 

  So, zones let you, they wrap the same things. But it gives you error handling, and you can also augment behavior. So, you can accomplish exactly the same thing that you would with domains with zones. But then zones also, they have a couple of little benefits I think over domains.

  Well, one of them is probably people use zones, which is a benefit over domains. [Laughter]

  Well, I don’t think anyone’s really using zones yet. I’ve been trying to con someone into doing something interesting with zones so that way I know that it works.

  [Laughs]

  I guess that’s what Angular 2.0 is. [Chuckles]

  Yeah, one long con.

  Yes.

  To make your library get used.

  [Chuckles] I need those GitHub stars so bad.

  [Chuckles]

  I don’t know. So, the interesting thing is Zone.js doesn’t run in Node right now. There’s a separate project called just Zone by some of the guys at StrongLoop, I guess are working on it. And I’ve been talking with them so we can try and align APIs. But it takes two totally different implementations to get this to work in the browser versus in Node.

  Can you talk a little bit about how it works? Because this seems like voodoo magic to me. I didn’t know that it’s a way to hook into stuff like this.

  [Chuckles] That’s exactly right. It is basically voodoo magic. So, the way that it works is it actually wraps all of the APIs in the browser that might do something asynchronous. 

  Okay.

  That’s how you get the [inaudible].

  So, that’s why the implementation is different in the browser versus Node.

  Yup, exactly.

  Okay, that makes sense. It sounds super easy when you say it like that. [Chuckles]

  Well…

  All you got to do…

  It’s a lot of really mundane work and a lot of testing things that are difficult to test. So, the good news is that I’m pretty happy with the state of the library now and I’m confident that it works. But it took a really long time to go through all of the different APIs in the browser. It wasn’t entirely a manual process. I extracted some of the, shoot, words are escaping me, the IDL out of Chrome, out of Blink rather, that describes all of the interfaces to the DOM and between V8 and the browser itself. And form that, you can get most of the information that you need and generate the code. 

  That does seem like it’d be hard to test thought, because you would just test that it worked for a thing that you know that you already put in there. It’d be hard to test for it not working on something you didn’t know about.

  Yeah, exactly. That’s difficult. So, I’ve been working on a couple novel approaches to testing other things. But I think at the end of the day, I really just need other people using the library, because if there is some browser that exposes some API that does something asynchronous, then you have a

hole in zones and things leak out and do weird things.

  Now, how does this differ from an observer pattern or something? Because with observer pattern, I guess you’re catching events. I don’t know, maybe you can explain it to me.

  Right. This is a much lower level than the observer pattern. It’s difficult to explain. I guess it lets you do meta-programming but on asynchronous code. The sort of things that you’d use the observer pattern for, zones solve a lot of interesting problems around profiling, for instance. Or I guess in the case of Angular, one of the cool things that it does is it lets us know when we need to check for changes and then re-update the UI of a web app. The observer pattern can solve the case that zones tries to solve for Angular, but it’s not as transparent. You have to make calls into something yourself, whereas with zones, in one spot you’re specifying at the end of some async task, I just want to run this code. And it doesn’t matter what the task is or how I get there. It’s just at the end of some work that the VM is doing, I want to do something else.

  How do you specify which? Do you just say anytime you do any work or can you specify any time you do this particular work?

  That’s an interesting question. So, there are a couple of different ways that zones let you do this. So, there are a couple of hooks. So, there’s before task, after task, I think. So, you get hooks into before, after, and then when you enqueue and dequeue a tasks. So, an example is let’s say you do setTimeout and you pass it a function. Before this function runs, it will run the before task hook. Then, it will run the original function that you passed to setTimeout, and then it will run the after task hook. So, then enqueue and dequeue are when you call setTimeout, it will fire that hook. So, that allows you to augment this original function or maybe do some sort of reference combing like thing. And then dequeue is if you either call clearTimeout or if after the task asynchronously runs, then it’ll run this dequeue hook. 

And so, what that means is you can know how many asynchronous tasks are queued up. You can also run something just before and after. The common case for that is a timer for instance. If you want to time the CPU time for some block of code that does asynchronous things, you want to use before and after task. If you want to know how many asynchronous tasks are running at any particular time, you can use the enqueue and dequeue task hooks to figure out that, “Oh, there are this many things that might fire at some point,” or, “There are no more pending tasks,” for instance.

So, we can go on and do some other things.

  You’ve already mentioned how Angular uses it to keep track of when to sync data to the DOM.

What other kinds of things could you imagine being built on top of this? It seems like such a powerful building block. But it’s the first time I really understood it, so I’m just trying to rack my brain to see what awesome stuff you could make with it. So, it’s kind of the error handling thing you’ve talked about.

  Yeah, I think the big wins that you can get from using something like Zone is you can measure in a much more fine-grained way things that your browser is doing. So, I see it being really helpful for profiling tools, for instance. One interesting that you can do is because you just run some block of code within a zone, you can say for instance, what is the cost when the user clicks on this one particular button? And to measure that, you only need a single line of code with zones. And you can really narrow down on just this one particular call or this one particular click event or something. 

And then you can measure all of the things that result from it and just focus on that, whereas if you’re using the Chrome Dev Tools which are fantastic, you’ll see a lot of noise in there. When you have a big application, a lot of times you’ll be syncing something in the background. Or you’ll have some server push event or something. There are lots of little things happening. And it’s hard to just debug one part of your application that might be slow in isolation, without tearing it apart or putting lots of timers or lots of measurements throughout the code in a bunch of different places. And that’s really error-prone. And so, I think zones will be really cool for that sort of application.

  So, I think I’m getting where this works. So, you call zone.fork to set up your context, right?

  Yup. And that’s where you specify these hooks that I was talking about earlier.

  And then call .run and you wrap the function that actually is doing the work?

  Yup. So, you could think of that as that’s where you might bootstrap your web application. Or if you’re trying to profile something, you could put whatever it is that you’re profiling inside of there.

  And then when you want to execute it, do you just call…

So, run is the thing that executes it.

  Okay, so it just does the function in that context?

  Yup, exactly.

  So, if you were going to, I don’t know. So, you could wrap this in another function that effectively sets up the context around common tasks?

  Yeah.

  Is there a way to save the context and then insert it?

  Yes, yup. When you call zone.fork, it returns a new instance of the zone. And you can run that zone multiple times. And that’ll have, that’ll keep the context of it.

  Okay. So, if you call it myzone, then you can call…

  Yeah.

  You do myzone = zone.fork, you give it all of the callbacks, and then you could do myzone.run this thing, and then myzone.run this other thing. And it does all the fancy stuff?

  Yup, exactly. That’s exactly right.

  Once you have code inside of a zone running, can you break out of the zone and have it execute outside of the zone?

  So, that’s something really interesting that I’m discussing with Bert from StrongLoop. He’s working on a Node implementation of this. And in his implementation, he has this thing called agate which lets you do that. I don’t have any particular use case for such a feature. But I’m trying to work with him and think of what are the ways that someone may use a feature like this and what are the ways that we can expose it in such a way that it doesn’t break any of the guarantees that zones give you?

  Right.

  So, right now the answer is it’s definitely possible to do something like that. One way that you could do it is you could keep track of the default zone that has no hooks on it. And then you set up your zone, you run that zone, and then somewhere inside of that zone, you can do the original zone that has no behavior.run. And that breaks you out of it.

  Gotcha. Yeah, I can imagine, if you were doing, if there was some sort of a profiler, you’re doing some kind of profiling, then there might be some kind of work that you didn’t want to be timing. You wanted to time everything else.

  Right, yeah. Yeah. Actually, I’ve been thinking about this case. What if you had something called, I don’t know. I’ve been working on this. It’s like an accept zone or something like that. So, you specify the behavior and you call zone.run but it only has this behavior for everything outside of the area that you run. And it basically uses this technique that I described where it keeps track of the original zone and then flops the two the other way.

  Right, right. Well, what’s cool about it though is not just that you could use it for profiling or for Angular, but it’s a building block. So, somebody somewhere out there is somebody who needs this and doesn’t know how to do it. And you’ve never thought of their problem. But it’s just a great little building block. 

  Yeah. I’m hoping to see more clever applications of zones. I think it took me a while to get the API to where I like it. But I’m still not totally content with it. And I think that I’m at the point where I need more interesting use cases besides the profiling and then couple of things that I want to use it for with Angular, in order to get it the rest of the way there. So, I’m eager to see what other things people come up to do with it.

  Right. So, how long have you been working on it? 

  That’s a good question. So, the famed father of Angular, Misko who I work with, talked me into writing this. So, it’s a feature that existed in Dart. And Node has domains. And there’s a lot of prior arc on it. So, I started on it, I want to say a couple of months ago. But I’ve been working on it on and off between other things. Somewhere there’s the GitHub history that actually tells you when I started. It looks like, oh man. It’s been a long time. So, I guess maybe September I really started getting into it. 

  Well, you talked about it at ng-conf in January. So obviously, it was before that.

  Yeah, that’s true. I have no concept of time lately. [Laughter]

  It’s just, I don’t know.

  It’s a flat circle.

  Yeah. Sometimes I get some issue on GitHub for a repo or something that I don’t even remember when I made it. I guess that this is the same case for zones now, too. [Chuckles]

  Right. So, what was the impetus that drove you to build zones?

  It was mostly just that we could really improve the API of Angular 2. And if you’ve written an Angular 1 app, you know or you may have encountered a case where the UI doesn’t update because Angular doesn’t know that it needs to cause changes. And so, we have an API that tells you, “Oh, you can tell Angular to check for changes.” But it’s really ugly to have to put that in your code whenever something asynchronous is happening. 

And if you have an API that sometimes is synchronous and sometimes asynchronous, then that’s a whole additional mess because you have to either make it always async or conditionally check whether or not to inform Angular to check for changes. And it’s something that we know developers using Angular don’t understand well and shouldn’t really have to understand. And so, we thought really hard about how we can just get rid of this because it’s just not something that developers should have to worry about.

  Right.

  So, I’m an Angular newb. I thought zones is how Angular already worked. I thought that it already had code to basically check after every possible asynchronous thing happened whether data has changed or not and then update the DOM. Is that not how it currently works?

  Right. That’s partially correct. If you look inside of the code for, for instance $http, which for the uninformed is Angular’s HTTP service, it’s like $.ajax if you come from a jQuery background, inside of there, there’s code that lets Angular know, “Oh, you need to check for changes.” Inside of for instance, $queue, there’s code that says, “Oh, after some asynchronous thing happens, you need to check for changes.” 

It’s when you start writing your own services or if you use some third-party library that does asynchronous things outside of Angular’s scope that you need to inform it about this. For 90% of the time, you really don’t have to worry about manually informing Angular. It’s just when you start doing asynchronous things outside of Angular and writing your own services that this becomes a problem. 

  Okay. But those are all built on some kind of setTimeout or XHR API. And then with zones…

  Yes.

  You know to wrap those so it will catch all the cases.

  Yup, exactly.

  Okay.

  Exactly. And then cool thing is that when we do that it means we can take all of these services that before we had to put these Angular-specific calls in and we can just publish them as general modules that don’t need to be at all Angular-aware. 

  Sure. That makes a lot of sense.

  Yup. 

  You’re talking about zones handling asynchronous stuff?

  Mmhmm.

  So, when you call something and then it has a callback that happens as a result of something that comes in, and there may be a whole chain of callbacks that happen, all of that happens within the zone. And you’re after, I don’t even remember, after function was it?

  After task.

  After task, that happens after all of the callbacks have been run?

  No. That happens after each individual task, so each individual asynchronous task. The before task and after task will fire multiple times usually within one run of a zone. If you want something that informs you when all of the things are done, there’s an API that Zone.js exposes called a counting zone. And so, what the counting zone does is it keeps track of all of this enqueuing and dequeuing that happens. And so, that can let you know when there are no more possible asynchronous things that will come out of some particular zone. 

  So, it does reference counting basically, with asynchronous operations?

  Yup, yeah.

  That’s cool.

  Yup, yup.

  So, each of those callbacks gets basically enqueued as a task? Or am I misunderstanding that as well?

  Sorry, which callbacks? [Chuckles]

  So, I run something in myzone.run. I give it a function. Let’s say I do an HTTP call that has a callback that causes another callback to be called. So, you have a couple of these. Do those just each get enqueued then within the zone?

  Yeah. Those will all run in the same zone. So, one important point with zones is that they’re transitive. So, anything that happens asynchronously and within that asynchronous task enqueues some additional asynchronous task, that next task that’s enqueued will also still be in the same zone. 

  Right.

  This is just super cool. I think it’s just sweet. 

  Now, is there a way of tying this to events?

  Yeah.

  Or having it trigger events?

  Yes. You can extend a zone with whatever functionality you want. You can have a zone that uses these different hooks and then ultimately fires off some tasks. There’s some discussion with Node, on the Node side of implementing zones, about whether a zone should act like a promise, essentially. So, you could do zone.run and then it does the reference counting thing and it knows when all of the asynchronous tasks are finished. And then it calls then, and then you could even do another zone. And you could even use it for something like control flow. I think that’s something that would probably be more useful on the Node side of things. 

And I don’t have that API in Zone.js right now. But it would be super easy for you to add it, for you to add a then function to a zone after run. So you can for instance know that you make a bunch of requests to a database asynchronously and those requests come back and maybe some things are cached and some things aren’t. So, you have to make additional requests. And you keep doing this. And then eventually things settle down and you know, “Oh, I have all the information.” And then you can continue on.

  So, I want to talk a little bit more about this other project that you’re working with a little bit. 

  Sure.

  Is it just the names coincided? Basically, how did the Node one come about? Was it a fork of yours and then modified to work with Node?

  No. I think the timelines are actually pretty similar. So zones, it’s one of the really, I think good ideas and really good APIs in the Dart programming language. 

  Okay.

  And so, this other implementation by StrongLoop is totally separate. We didn’t talk. And actually, I only realized that this was out there when I tried to register my library on npm. 

  Okay, okay.

  Yeah, it looks like zone…

  That makes sense.

  Is the name of it. If you do npm install zone, [chuckles] it’s a little bit confusing. But it looks like StrongLoop started on it in maybe January, totally independently of me. And we have some differences in our API. And I’m hoping we can get it to the state where it’s promises, where there’s a spec or some general idea of how they work. And then you can have different implementations for different environments. 

  Sure. Yeah, that’s what I was going to ask, is how you’re coordinating work between these two parallel and separate projects that are sort of [inaudible].

  Yeah. Right now, they’re two totally separate things. But we’re hoping. I think the implementations will always have to be separate because it just doesn’t make sense to combine them together. But I think we can at least expose the same APIs or almost the same APIs. And then you can write code on top that works well in Node or in the browser. 

  Do you think this ends up in two years with you being on the Zones spec committee? [Laughter]

  I don’t…

  Little did you know when you started this open source project.

  Yeah. [Chuckles] I don’t know. I would really, really, really like for JS VMs to implement this. That way, I don’t have to anymore. [Chuckles]

  That would be excellent. [Chuckles] I don’t know if I want to put myself on a standards committee though. 

  Sure.

  That would be excellent though, if that’s the future of zones. And I think there’s probably a reasonable chance. This isn’t actually the first attempt at an API like this. There’s also asynclistener, which is a Node project. It has a different API. But it’s in the same spirit. So, it lets you know when some asynchronous task is queued up. I don’t exactly know what the state of it is. But I did take a look at it. And it’s a similar idea. So, I would just say there’s a general need for it, for sure.

  But yours is obviously way better, right?

  [Laughs] I don’t know. Of all the solutions, I think mine is perhaps the furthest along without running into some major issue, I think. I remember talking to Forrest who’s, I guess, one of the guys that worked on async-listener. And he said that they ran into some technical difficulties getting a hold of all of the entrance points and exit points in Node. But I’m not sure. I don’t know. I

can’t talk for anyone else. So, I don’t know if mine’s the best. I think it’s pretty good. And I would be happy if someone told me why my library’s awful or something.

  [Chuckles]

  As long as they give me some constructive feedback.

  [Chuckles] So, we’re do you see Zones being when it grows up? It seems like a very nice focused tool. It seems fairly complete to me. Are there directions that you’re actually considering going in?

Are there things that you know you still need?

  I think one of the big things that are important to me is that when you write a zone that gives you some new behavior, that you’re able to easily publish it and then use it in some other project, and then also compose it with other behaviors. One instance of this is the library ships with [a long] backtrace zone that gives you a full-stack trace across a bunch of asynchronous events, which is really cool. I think Chrome Canary just recently added a similar functionality. But the cool thing about having it in Zones is that you can get these long stack traces in IE 8 or IE 9 or browsers that don’t have these sorts of things. And you can also get them programmatically and for instance send them back to the server. But you would want to use this one feature. Maybe you want to have long stack traces but you also want to time some particular thing. And you also want to have the reference counting behavior. 

So, it’s important that you can separate out all of these different concerns but then also have a zone that combines them together. And so, I think that there are probably some unanswered questions around how to do that well. Not too long ago, maybe a month ago, I added an API that tries to make it easier to compose together these different hooks. But I’m still not totally sold that that’s the way to go. So, there are a lot of little questions like this. But I think the big thing is making sure that we can expose behaviors built on top of zones in a really modular and composable way. Because as you’ve seen time and time again in the JavaScript world, that’s really what wins. And that sort of code reuse is really powerful and awesome.

  Here, here.

  Here, here.

  [Chuckles] I was going to say, it’s super cool.

  Everything is awesome. 

  Everything’s great.

  My kids sing that song all the time. “Everything is awesome.” [Chuckles]

  Everything is cool when you’re part of a team.

  So now, this is where Mandy goes back and auto-tunes that, right?

  [Laughs]

  Socks and pants and ties are awesome! [Chuckles]

  Alright. Well, do you guys have any other questions or comments about zones before we get to the picks?

  I don’t think so.

  Are you in the zone?

  Oh, that’s true. We didn’t do a bunch of puns about zones. 

  Yeah.

  I didn’t hear any of those.

  [Laughs]

  [inaudible] smarter.

  That’s alright. I’ve had all of the fun that I can possibly have with zone puns.

  When you get down to where you’ve only got what you figure is a quarter left to finish up the project, will you change name to the red zone? [Chuckles]

  That’s pretty good. I’ll think about it. [Laughter]

  File an issue.

  It’s 20% left, technically.

  Oh, is it?

  Yeah.

  That shows my ignorance about football. 

  Sports ball.

  Let’s end the madness. Joe, do you have some picks for us?

  Me? Oh, don’t do me first. 

  Jamison, do you have some picks for us? 

  I do. I just have one. It’s jest, people have heard of it already. Whatever, it’s cool. It’s the Facebook testing library that mocks out CommonJS requires, which is neat because that’s a thing that’s been a little painful to do in the past. Some part of the reason why we use a dependency injection thing in our code is for mocking out dependencies in test. And this removes that need. It’s a simple tool that does something well. That’s why I like it. It’s cool. That’s my only pick. 

  Alright, Joe. What are your picks? 

  Alright. So, I’ve got three picks today. The first one is a place called Dave’s Dolphin Safari. I recently went on vacation down in California with my family, kids included. And we went to Dave’s Dolphin Safari and went dolphin watching. And it was one of the coolest things that we had done that we did the whole time we were gone, including Disneyland. Compared to Disneyland I enjoyed it much more. 

You get on this very specially specifically designed boat. And they go out and they find dolphins. And they radio around to other ships that may have seen dolphins. And they find you dolphins. Then you go drive and the dolphins are swimming next to the boat. And you can climb down inside and there are windows you can look through and be right there next to the dolphins. And then they also go off and look for whales after they’re done finding dolphins. And so, it was way cool. I really had a good time showing my kids dolphins. So, if you ever go down to LA, take your family to Dave’s Dolphin Safari. You got to book it in advance, of course. 

  So, you basically lived through a Lisa Frank folder cover?

  [Laughs] Yes. My second pick is…

  Wait, wait, wait. You have to wear the bush hats?

  [Chuckles] Those were optional.

  [Chuckles]

  The other thing that was actually really cool is they have a couple of cameras set up. And there’s

a URL and it’s live streamed all the time. So, you can tweet out to your friends that, “Hey, I’m on this boat looking at dolphins.” They could go see you just sitting around on the boat. I don’t know if they could see where the dolphins are. I think they just see you sit on the boat, right? I thought that was pretty funny. 

  I don’t want to look at you, Joe.

  [Laughs] Well, it’s a limited audience.

  [Laughs] Fair enough.

  [Chuckles] Yeah. Supply and demand always vary. My second pick is a company called belVita that produces cookies. Or I think they’re called actually belVita bars. But they’re like cookies. They’re actually really healthy for you. So, they’re a little expensive. But you can pick them up at even Walmart. And I’ve been eating them a lot lately. I’ll eat ten at a time. [Chuckles] No, I don’t. That would be unhealthy. No, I have one just in the afternoon as a snack. And instead of whenever I get the munchies, so I’m actually eating something healthy, but it really tastes a lot like eating a really nice cookie, oatmeal cookie or something. So, I’ve really been pleased with that and it’s helped me to not put on extra weight just because I could get munchies and want something sweet to eat in the afternoon. 

And then my last pick is going to be the Thrawn Trilogy from Star Wars, which was one of the first books ever written. I think in fact the first book from the Thrawn Trilogy, was the first Star Wars novel ever written that wasn’t from actual episodes IV, V, and VI. It was written in the ‘90s or something. And it’s a trilogy. And it’s just an excellent trilogy. So, it actually mixes Star Wars with a good story. So, as anybody who sees all old movies know, that’s not true of all movies. That’s certainly not true of all the books. So, I highly recommend the Thrawn Trilogy for anybody who’s into Star Wars and actually wants to read a good book. And that’s my picks.

  Awesome. Alright, I’ve got a couple of picks. This is a pick that Jamison picked last week or the week before. I’ve been playing Hearthstone. 

  Yeah.

  I’m liking it. It’s kind of fun. And it’s nice because I can play through a game depending on how well it goes. I think the longest game I’ve had is a half hour. But I can play through a game of Hearthstone in between 10 and 20 minutes, which is a nice break for me if I’ve just been heads down coding and I just need to sit there and halfway thing about what I’m doing. It’s really nice. So, I’m picking that. 

I also, I rearranged my office. And for those of you who aren’t aware, I basically sit in a cubicle in my house. My wife found this thing. It’s a fully-modular desk like you expect a cubicle to be. And she spent $90 on it. So, I’ve had it for the last two or three years. And it has these walls that are five, five and a half feet tall. And then on the other side, they’re three and a half feet tall. And the problem that I had was that the five and a half feet tall walls were in front of the window. And so, I’m going to pick sunlight. And I know that some developers start to smoke and turn to dust in sunlight. But I’m liking having a window. So, I’m going to pick sunlight. 

And then finally, I’ve got two books. If you listen to all of my podcasts, I’m sorry because I picked the same thing on all of the shows this week. But I’ve been reading ‘EntreLeadership’ by Dave Ramsey. And it is a terrific book if you’re thinking about starting a business and hiring people and growing it. It’s a terrific book. 

And then the other one is similar to it. It’s Jack Welch who was the CEO of GE. And he has his book, ‘Winning’ which talks again a lot about running a company and stuff. They do cover different subject matter. And then they cover some of the same things. But they’re both really, really great books. So, if you’re looking at doing a startup and building a company and hiring and firing and acquisitions and all that stuff, go pick up those books. And that’s it. Those are my picks. Brian, what are your picks?

  Oh, man. I wish I would have picked sunlight. That’s a good pick. All of mine are pretty nerdy. So, this has been making round on Twitter, but James Mickens has this awesome talk from Monitorama. Words can’t even do it justice. It’s just really funny. It’s really good. See, you should just watch it. I can’t even, nothing that I say will prepare you for it. 

There’s a blog post on the WebKit blog called ‘Introducing the WebKit FTL JIT’ which is really cool. It brought me back to my glory college days of doing compiler optimizations on LLVM. Perhaps not interesting to all web devs, but it’s really cool if you’re interested in how VMs work and how to make things go fast. 

And then in the same vein, there’s this cool GitHub organization/repo called Papers We Love. And again, I think they’re pretty accessible academic papers. And so, if you’re interested in that sort of thing, I think it’s a good way to get your foot in the door reading this sort of things. So, those are my picks. 

  Awesome. Well, thanks for coming on the show, Brian. We really appreciate you taking the time and explaining such a power tool, really, too us. Something we can add to our toolkit.

  Yeah. It was fun. Thanks for having me. 

[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]