024 JSJ Strata.js with Michael Jackson

Download MP3





JAMISON: Nobody to offend from there; so, you are okay making fun of East Texas. MICHAEL: [Laughs] I wasn't making fun. I was just… JAMISON: The scorpions were like, “Hey man, it’s not so bad. Come on.” CHUCK: [Laughs] [This episode is sponsored by ComponentOne – makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to wijmo.com and check them out.] [Hosting and bandwidth provided by the Blue Box Group; check them out at bluebox.net.] CHUCK: Hey everybody and welcome to episode 24 of the JavaScript Jabber show. This week on our panel, we have Jamison Dance. JAMISON: Hi guys! CHUCK: I'm Charles Max Wood form devchat.tv and this week we have a special guest and that's Michael Jackson. MICHAEL: Hi everybody! CHUCK: So Michael among other things is the author of the Strata.js library. Do you wanna introduce yourself real quick Michael and then tell us about the library and what it does? MICHAEL: Sure. So, I've done quite a few things with JavaScript in my career. I'm currently actually at Twitter; I'm an engineer at Twitter working on our front-end. We are even using Node a little bit and Strata a little bit, but I guess we can get into that later. But yeah, so I'm an engineer; a lot of JavaScript, a lot of Ruby in my history; I publish a lot of open source stuff, so that’s cool. So yeah, that’s me. CHUCK: Yeah. Somebody actually requested that we talk about StrataJS and so I went looking for it. It was kind of funny because I looked it up on GitHub and I'm like, “Oh, I now that guy.” [Chuckles] So, it was nice; I could just reach reached out to you and go, “Hey, do you want to come on the show?” MICHAEL: I was really happy to be here because I love getting on and talking about this kind of thing. It’s just fun to talk with other people; get feedbacks, see what they think and also kind of let other people know about it. CHUCK: Right. So what exactly is Strata? MICHAEL: So, if you’ve done any web development at all since about 1980 or so, we've kind of had these web kind of frameworks if you will; and Strata is a kind of a framework in that same vain for NodeJS; and it kind of takes a more traditional approach, where it kind of takes the Rack approach or the WSGI approach. If you are a Ruby or a Python programmer, you'd be familiar with those libraries. CHUCK: Okay. Cool. So, I'm a little curious; how is it different from Rack or WSGI other than the fact that it’s written in JavaScript? MICHAEL: So like I said, it is very similar to those. So the fact that it is written in JavaScript and specifically on Node, make it so that the whole thing is evented, right? So you are never blocking inside a Strata app. You can also do streaming with WSGI; it’s a little bit more tricky with Rack, but it’s possible to kind of simulate streaming. But the reason I wanted to sort of take those good ideas and combine them with Node is because Node has such awesome I/O handling, right? Everything is non-blocking; nothing blocks. So that makes it so that you can handle a ton of simultaneous requests without dropping any of them and still kind of have this traditional kind of web app architecture. CHUCK: And does use the same… what is it… the reactor pattern? MICHAEL: Yes. Well, I'm not sure what the pattern is called, I guess we’d call it ‘The Middleware Pattern’ these days; that’s kind of the most common word that the developers have for it. So, the reason I called it ‘Strata’ is because Strata, if you look for example like a rock phase and you sort of… if you’ve ever gone hiking in the mountains for example… you guys are from Utah, I always used to love to go Zion. Anyway, you go hiking in the canyon there and you see all the different layers of rock up on the side and that’s really kind of what a web app is like using the middleware pattern; you basically have the core of your app and then you wrap it with these various middleware that do various things to the request on the way in and the response on the way out. CHUCK: Right. And so… oh, go ahead. JAMISON: I was going to say, I think the main implementation of this that lots of people are familiar with Node is Connect, right? It’s using Express a lot as well. How is this different from Express and Connect or is there some relationship between them? MICHAEL: There's no relationship at this point. JAMISON: Do they have like fork or something or they are just separate implementations of a similar pattern? MICHAEL: Exactly. They are separate implementation of similar pattern. The approach that I wanted to take was to provide an abstraction on top of the objects that Node gives you; so Node gives you… when you set a basic HTTP server and you handle a request, it will give you this request object and this response object and then you can sort of manipulate them, read properties off of them and write to the response, etcetera. And the approach that Connect and Express took is to add sort of a very minimal layer on top of that, right? It  was , “Okay, we’ve got this request the response object,” and what we really wanna do now is set up a chain of callbacks, a chain of functions; sort of an execution path through our app so that we can manipulate this request and build our response and send it. The goal of Strata was to sort of abstract the way Nodes request responds objects and provide you with more of a traditional kind of server environment. So, if you’ve ever done sort of any programing in like Apache or Engine X or even CGI programming, you'll be familiar with the common server environment variables; things like your server name and the path info and the query string, the request times, these sorts of things. And so the goal of Strata was to sort of take those requests and response objects that Node gives you; put a layer of abstraction on top of them, that give you this more traditional environment and also give you -- what I believe -- is a cleaner API for building things like middleware. CHUCK: Right. But they all work the same in the sense that you kind have kind of a base app, I guess you can call it and then you have layers of middleware that you stack on top and basically what it does is it starts at the top of the pile and works it all the way down to the base and then comes all the way back out, so that basically, on the way in, things can modify or handle the request; and on the way back out, they can modify the response. MICHAEL: Absolutely, yeah. It’s the same kind of pattern; just a different implementation and different API. JAMISON: So, I mean, connect explicitly call next in your middleware to pass it on to the next layer and it looks like in Strata, you kind of only call your callback if you need to apply it. So, there's no next to call; it just kind of goes through the whole stack each time. Is that right? MICHAEL: Yeah. So, you have two different kinds of objects in Strata really and they really just functions is objects; but one is an app and then another one is a middleware, okay? An app, a Strata app is just a function that takes two arguments; it’s got the first argument is the environment, which basically just this big bag of state that you pass around through the request and response cycle; and the second argument is the callback; and that’s just a function that you use to send the response. And so, a Strata middleware is basically an app, so you can call it in the same way; but it’s also got a reference to another app that’s downstream, what we say. So when you all a middleware, it can choose to, for example, send the response if it wants to. For example, if you have a piece of authentication middleware that and you are not authorized, it can choose to cutoff the response at that point and send you a 403 or something saying, “Hey, you need to ‘off’ first before you go further.” Or if that authentication middleware deems that, ”Yeah, everything is great; we do have the right kind of off.” Then, it can call it downstream app, right? So a middleware is an app plus a reference to another app that’s downstream. And it’s really nice building things in this way because the separation of responsibilities is very, very clean. And in middleware land, right? If a middleware has just one job and that’s all that middleware needs to do, and then the interface is the same between all apps in middleware, so that regardless of what is downstream or what is upstream, you know exactly what to pass -- what arguments to pass. CHUCK: Right. It really does sound a lot like the approach that people take with Rack and things; except it kind of has an implicit return instead of specifying the callback. Does that change the nature of the apps at all? That you can specify the callback so you can actually have the stack do something different than just straight up and straight down? MICHAEL: Yeah, absolutely. So in Node land everything is done in a callback pretty much; whether using the callback pattern explicitly or whether you are using kind of this event listener pattern; everything is done on a callback. And so Strata, when I build Strata on top of Node, I thought, “Okay that’s probably the best way to build this thing because that’s the most familiar interface to people.” So, I'm sorry I forgot what your original question was; I kind of got going off about the callbacks. CHUCK: Well, I was just wondering how it changes things to explicitly specify callback. Basically, because in Ruby in Rack, I mean you basically count on the fact that it’s going to synchronously return when it’s done? MICHAEL: Yeah, right. So in Rack, the body of your response… so you have to like synchronously, for example, determine the status in the headers, right? The body is this thing that you can call ‘each’ on. So in that way, you can kind of fake streaming a response to the client, right? So, every iteration of ‘each’ could yield a chunk of the response to for example; in Strata it’s much more explicit the fact that the whole response is deferred, right? You get that callback and you just call it whenever you are ready, right? There is a time out middleware in fact that will let you sort of if in case your app kind of goes haywire and hangs and you don't end up calling that callback within a certain amount of time, it will call it for you and just cut the response short. But basically, that’s the idea is that, you don't have to decide right now what the response is going to be synchronously in line because you’ve got a lot of things to do, you know? You need to go connect to the database with some data; you might need to render a template. When all of that stuff is done, then call the callback with the response and everything. Another feature that is really nice about Strata is that I built it when Node was on the 0.4 release and that's when streams were kind of making their in way into Node core. The stream is one of the core primitives of Node; basically, everything that you get in Node is a stream; whether it’s a request or response, these are all kind of sub classes of the stream class. And so Strata was built with that in mind so the Strata body that you pass back in a Strata app and in the Strata response, can either be a string, which is basically like you rendered a template, right? Here’s the string. Or it can actually be a stream; so your own event emitter that just yields bytes to the response as necessary and if that’s the case, then you will automatically have streaming response instead of sending it all at the same time. CHUCK: Right. One other thing that I was kind of leaning or looking at before is the fact that if you can specify the callback, you can actually change the shape of the middleware where it’s not a linear, down linear backup and like it is in Rack. MICHAEL: Yeah. Although it might get a little bit tricky; I don't know what you mean by change the callback; do you mean… you certainly don't wanna give it a different signature, right? CHUCK: Right. No, what I mean is… JAMISON: Different kind of skip layers, right? CHUCK: Yeah. MICHAEL: Yeah, right. CHUCK: You can skip around in the stack. MICHAEL: Absolutely. You could do that; yeah, if you wanted to. CHUCK: You make it circle back on itself a couple of times and then finally exit. MICHAEL: Yeah. I think the most… JAMISON: I think that’s how my brain works. CHUCK: [Laughs] MICHAEL: Is it? JAMISON: Yeah. It just kind of go in circles for a while and manage its exits. CHUCK: Like a dog chasing its tail? JAMISON: Yeah. CHUCK: I have days like that. MICHAEL: Yeah, I think we all do. That’s why we love JavaScript and Node, right? CHUCK: Yeah. So one other thing that’s kind of interesting about this, does it change anything the fact that everything is a callback -- that it’s asynchronous? MICHAEL: Well, it just makes it easier to sort of reason about streaming, I think in my opinion at least. So you know, I do a lot of Ruby as well and so, you know, you can kind of mimic streaming. In fact, in recent releases of the Sinatra library, they’ve got this stream class; if you’ve done any development in Ruby you’ve probably heard of Sinatra; it’s this tiny library for writing minimal web apps and I really like it. Anyway, it got this stream class that you can use to sort of fake streaming, right? Anyway, the authors will probably get mad that I said that its fake, but you are not doing anything sort of asynchronously, right? You are just doing things synchronously, but you are giving them sort of an async interface.  And that to me gets a little bit confusing anyway; what I like is just to… like I say, “Okay, either I'm going synchronous or going asynchronous,” but you know, it’s easier to reason about it if I know which land I'm in from the beginning, right? CHUCK: Mh-hm. MICHAEL: So what I like about Node is they just said right from the beginning, everything is asynchronous. There is a tiny module for example that all have sync appended to the name and that’s for doing things synchronously; but other than that, everything is done asynchronously. So you kind of going into Node, if you are programming Node, you are like, “Okay, I get it; it’s asynchronous.” So you know how you think about your programs. JAMISON: Yeah, people complain a lot of times about the nested callbacks and stuff, but I think that’s one of the things they do really well; they make it really explicit when stuff is going to happen later. So,  what you see is what you get, pretty much; even though that can be complicated to follow the logic, at least you know that, “Okay this takes the callback, it’s going to do something asynchronously, it’s really explicit.” MICHAEL: Well, yeah there’s been a lot of sort of complaints from people who are doing Node or maybe not like the Node core but kind of this community that’s just sort of dipping their toe in the water saying, “Eww, look at the callback spaghetti! There's this callback, calls another callback, passes another callback.” And the truth is when I've been writing my Node apps, it can get that way; you have to be very, very disciplined though; you have to be very disciplined about… like I was talking about earlier about the separation of responsibilities, you know, if I have a function that takes a well-defined set of arguments and does one thing, it’s kind of like the old Unix philosophy, there's one thing very well and then just sort of pipes its response with some other function, right? Then, I think you can maintain some sanity in your programs. I've seen some examples whenever somebody wants to show a bad example of the callbacks; usually they say, “Well, let’s make a bunch of calls to the database, so we'll make five calls to the database and since they are all being done asynchronously, well then we do… we sort of next them all in callbacks.” That’s not really necessary; like you have different things like flow control libraries that you can use to mitigate that problem. But in reality, I haven’t found that to be a really, really practical... I haven’t found that to be too much of a problem for me just because I keep most things that I'm doing very well defined and very well separated, right? So it’s not like a 80-line method that’s a bunch of callback spaghetti;  it’s like, you know, one method that has its specific responsibility, calls another piece of code that has a specific responsibility; but I don't end up with an unreadable mess. JAMISON: I think that’s definitely a skill. I mean, you’ve been doing Node for a while now; did you start writing code like that or did you have the struggle against the callback spaghetti that other people have had too? MICHAEL: Yeah, you are right; it is a skill. It took a long time to kind of figure that out. I remember one of the talks that really kind of changed the way I thought about web programming is a talk that I've heard at Mountain West Ruby Conference back in 2009 by Jon Crosby and he was talking about Rack; and before Rack, the only servers that I have ever really used were like Apache and EngineX, you know? And he is talking about Rack and when I heard that talk, I went through it and I read through all the source code of the Rack library and I really wanted to understand what it was that we are talking about and what made it work. And when I saw how the code was structured; that every piece of middleware had this very clear responsibility, it was one of the things that kind of… it was kind of like a big light bulb came on in my mind and I was like, “Wow! This is really how… this is kind of the principle of an encapsulation applied to web apps, right?” Nowadays, I feel like we build apps that are big, you know, like lots of times we'll build like for example a Rails app, right? We'll take Rails, we'll fire it up and we'll say we’d like to keep this thing going fast. And we'll build all of these functionality into the Rails app; we've got our admin panel on our Rails app and we've got our API is built right into that app and maybe even like workers using something like delayed jobs or something; these are things that we built into our rails app. (Sorry I'm talking too much about Ruby. I'm old Ruby guy.) Anyways, you think about, if that were a class, right? If what were a class, how would you feel about that class being able to do all those types of different things, right? For example, if I gave you a class and I called it ‘ kitchen sink’ and you could call any method in my whole app on that one class, you would probably tell me to go refactor that class because you would say, “This is not well defined,” right? “There's too many things going on here. I don't know how to think about this class. I don't know what an instance of this class does. An instance of this class really does a hundred things and all I want to do is be good at doing one thing, right?” And so if that’s what we think about our objects, why don't we think about apps in the same way? Because our apps are really just an accumulation of a bunch of objects sort of working in harmony. So why don't we think about our apps like, “Okay, this app does this one thing or this middleware does this one thing and then we sort of end up piecing them all together, right? To form something that’s much greater. And if there's a piece of it that’s misbehaving, we can easily remove it from the stack without affecting the integrity of the rest of the app or without affecting our ability to reason about the rest of it. Does that make sense? JAMISON: That makes a lot of sense. You kind of answered the question already; I was going to ask you, do you think… it seems like this pattern has been around for a long time, do you think when we are like programming with our minds you know, we just like think thoughts and computers interpret them that those are just going to go through the stack-based middleware; is this pattern going to be around forever? MICHAEL: I think it will, yeah. I think it’s proven to be at least… I mean you can see for example in the Ruby and the Python communities; it’s completely revolutionized the way that they do web development. And so that was kind of the big indicator when I came to Node I thought, “We’ve got this awesome platform, does really well with... it does a lot of things really well; it does IO handling really well, it reaches out to beginners really well… not beginners, but beginners to intermediate programmers who maybe JavaScript is kind of a language that they are kind of familiar with and so they easily get started with that.” And so you know, Node has all these great strengths going for it and what I wanted to do was sort of draw from the experience of these other communities and bring it this cool new platform, right? So that we could kind of learn from the past but also be living in the present, right? And just a response to your question, it being sort of an established… I mean-- JAMISON: This came from Perl originally, right? Hasn’t it been around since like the 90s? MICHAEL: I mean, yeah. I mean, it’s a pattern that WSGI copied from CGI, which has been implemented in all of our languages, basically. You’ve got CGI in Perl and wherever else; also Apache and EngineX kind of followed the same kind of pattern. And so I can’t think of really any other… I can’t think of any website that I go to these days that doesn’t use sort of this middleware pattern at the core, right? Even here at Twitter, when you make a request to twitter.com, it goes through our Rails app which is built on top of Rack, right? So it’s a pattern that I believe is here to stay. CHUCK: So, if you have another question about the pattern, I'm going to change the topic, so… JAMISON: I do have one more question about it. What do you think its weaknesses are? Where is it not the best to use? MICHAEL: Are you talking about the middleware pattern in general? JAMISON: Yeah, I mean maybe Strata specifically, but just in general. MICHAEL: Honestly, it’s the best pattern that I found for doing stuff like these. I have to think about that one. JAMISON: The answer is ‘none’. CHUCK: [Laughs] So I know that in the Ruby community, there were some issues I think with the stack depth -- the call stack depth -- because it effectively calls down to the next depth, calls down to the next depth or the next middleware and so you can get a really deep stack of stuff and it can slow it down some. JAMISON: So maybe a few. If you stack your things up too high, it will be weird. Sorry you were saying. CHUCK: Yeah. But with the asynchronous nature of Strata in Node, I don't know if that’s really an issue because you are effectively just saying, “Okay, I know who to call next; I have this callback.” And so you just asynchronously give that callback what it needs to do its job and just kind of move on from there; and so it doesn’t actually develop a deep stack like that. MICHAEL: I mean, that could get out of hand. But again, that’s kind of the programmer’s responsibility, right? CHUCK: Yeah. MICHAEL: Make sure that your middleware stack doesn’t get huge, right? And so in theory, I agree that it could happen; in practice, it hasn’t happened a whole lot with me; that may have happened to people who are like building Rails apps and so Rails kind of adapted this whole middleware philosophy in Rails 3 and so everything in Rails is a middleware now; most of the things in Rails are middleware. And so they might have layered on a lot of middlewares and kind of… and so that maybe where that problem is coming from. But yeah, I mean that could be a problem for other developers too though, if they don't watch it. I guess maybe that’s one of the weaknesses is that it just requires some discipline, right? It requires thinking, right? You got to sort of know what you are doing and you can’t be afraid to say… to go back and refactor and sort of pay down your debts. CHUCK: Yeah. So I have another question for you and that is that with at least in Ruby, I mean not a whole lot of people are writing Rack apps directly; I mean most people are writing Rails apps or Sinatra apps or Padrino apps or you know, some other framework that was written either based on Rack or you know, moved its whole basis over to Rack like Rails did. Do you see other people building frameworks on top of Strata.js? MICHAEL: Absolutely. It’s kind of been a pet project of mine that I haven’t really got pushed out yet but I have been building kind of Sinatra-like thing on top of Strata. So Strata really is at this point, it’s just a big, beautiful work course; it does kind of all the kind of nasty hard things for you. Like, Strata for example, version 1 shipped with version support for things like multi park parsing which is like… it’s just something that you don't wanna have to re-implement in your framework. You know, you ship for things like doing logging, doing caching, serving static files and building obviously your middleware chains. It shipped with doing things like routing; Sinatra and Rails-style routing. So it kind of did all of these sort of mundane things where you are sort of like, “Okay, okay I get it. I need some routing in my app; I need to handle session cookie securely in my app, right? I need to do all these things in an HTTP app,” but that has nothing… in of itself, there's no intrinsic value there. I haven’t built anything when I built that because those are sort of the basic building blocks of every app. Those are things that the basic things that you need to build any app at all. And so, what Strata does is it sort of gives you all these tools; it’s this great toolbox. And then you have the ability to say, “Okay, I'm going to write a 200-line JavaScript library on top of this or 100-line or whatever,” and it’s going to be really small, you know? Like Sinatra and it’s going to give me like the really sweet sugar, you know? The really nice kind of ways to define things; ways to easily handle errors within the context of the request and like do all of these nice high-level things that Strata has intentionally omitted from you. You know, like I said, I've got this library that I've been working on kind of in my spare time, but at the moment I didn’t wanna release it because I feel kind of a great responsibility when I do publish something and that is that I really wanna maintain it and make sure that its good for people in the future to use; so I don't wanna push out too many projects because so then I'm maintaining too many things and I fear that they might fall behind. But I would like somebody to build something of top of Strata and then show me and maybe we could work on it together and I could contribute there, but that would be a lot of fun. CHUCK: Yeah. I'll go ahead and write JavaScript on Jails. MICHAEL: Do it! Do it! [Laughter] CHUCK: I just wanted to get Jails in there. Anyway, MICHAEL: It’s calling it ‘bullet’ and it will be like your bullet train, you know? CHUCK : Oh, there you go. MICHAEL: The bullet trains are really fast. Anyway; that’s the name; You can have it if you want to write JavaScript library and call it ‘bullet’.  CHUCK: [Laughs] Well, I’d learn a lot doing it, that’s for sure. Yeah, I don't  have a lot of time. I mean, I spend most of my time maintaining the podcast and stuff, so. JAMISON: So, are you guys using this at Twitter? MICHAEL: Yes we are. Absolutely. JAMISON: Do you wanna talk about what you are doing with it? I think that will be cool. MICHAEL: Yeah. For sure. So right now, we are not using it for anything public facing yet; so we are using internally for a number of things. Probably the main thing that we are using it for is our web team  wanted to mock out some of the aspects of our API and some of our CDN; they wanted to mock that out in the dev environment for people who are developing against our app and running tests and things against it and you know, they need to kind of be in that environment and to kind of have that mock. And so, that’s what they used it for. So, I say ‘they’; I'm not on the kind of… this was kind of like the web team that works on kind of the infrastructure -- the core infrastructure here at Twitter. … of our product teams but I've been working with them to kind of keep Strata updated and put the things in that they feel like they need for their use cases. So yeah, we are using it there. I've also seen some various engineers kind of hacking with it. We have this thing that we do every quarter called ‘hack week’ and its really cool because you take an entire week and build something that you always wished existed at Twitter but for one reason or another, didn’t exist. And so, we actually have this team who have spun up internal apps and built them on Strata; whenever somebody wants to use Node, I'm always here to help them and couple of them have chosen to use Strata, which is great and its always fun to work with people like that. So, the future of Strata is pretty secure I feel like because we've got a lot of great engineers here who like to use it and were pushing forward with it and using it internally. I think it’s just a matter of time before we find some good production uses for it. Our main prod team is kind of a Java-Scala shop; that’s what our main application services team is using; and so it will probably a tough sell for those guys because they kind of… I don't think they’ve … yet but we'll definitely be using it web land. JAMISON: Just a little bit different, that this architecture. MICHAEL: Yeah. Exactly. You know, it’s hard to kind of get things through… bleeding edge of Node and you go and talk to your sys admin and say, “Hey, you wanna install this thing? They just released it yesterday!” You know, they kind of look at you a little bit funny, so… So you got to be a little bit more slowly than that but... CHUCK: Well, cool. Is there anything else about Strata that you wanna talk about before we get into the picks? MICHAEL: No. I mean, just I would love it if people give it a shot; you know, we've got a little bit of traffic going on in the mailing list and things like that. I'm always open for pull requests and I try and stay on top of the issues and the mailing list and things like that, so feel free to reach out if you got any questions about it, then I'm more than happy to help. CHUCK: Awesome. All right. JAMISON: The docs are pretty good too, I just wanna say. They’re pretty readable. MICHAEL: Thanks, man! JAMISON: It doesn’t have the problem where there are no docs, and it also doesn’t have the problem where they are just a wall of text that don't actually tell you what you want to know; so they are nice. MICHAEL: Thanks, man. I was trying to make it that I way, I was trying to make it so that it was like a book and I plan on expanding on that even in the future, but I wanted it to be just like a book, you like an O’Reilly book where you sit down and you are like, “Okay, what do I wanna do? You know, Okay I wanna do this,” and you can even kind of skip around sometimes in the chapters and you know, once you kind of get the feel for how the core of it works, you can skip around and just read the parts that are explain something that you specifically wanna do. CHUCK: Oh, there you go. ‘Strata: The Good Parts.’ MICHAEL: Yeah. [Laughs] CHUCK: All right. Well, let’s go ahead and do the picks. Did I warn you about picks? MICHAEL: Yeah. You did. I have a few things in mind. I don't know what this crowd is like if they are sick of hearing about tech stuff and wanna hear about other stuff but I got a few things in mind, for sure. CHUCK: Okay, cool. Why don't you start us off then? MICHAEL: So, my favorite website these days is Uncrate. Have you guys been to Uncrate? JAMISON: No idea. CHUCK: No. I've heard of it but… MICHAEL: Uncrate.com it’s like a… JAMISON: Oh, no. This is one of those sites that’s going to make me spend money, huh? [Laughter] CHUCK: It’s good for you, Jamison. JAMISON: All right. I just opened it up. The second thing on there is an Audi R8 $170,000. MICHAEL: So they do put some stuff … on the website, stuff that it’s like, “Yeah, right.” I mean, I saw a boat or a yacht on there one time it was like this 20 foot yacht and I was like, ”Yeah, that’s not anywhere in my near future.” [Chuckles] But some other stuff is really, really cool. You know, I just love the kind of variety of stuff on there. They have a lot of cool tech gadgets and I mean, go click on the tech tab and they’ve got like apps for your iPhone and cool little like attachments for your iPhone. One of the cooler things that I saw was this… they have like… have you ever used a Go Pro? JAMISON: No. I think I've heard of it but I don't know what it is. MICHAEL: It’s a little camera that you can mount on your bike. JAMISON: Oh, yeah. They are like helmet bikes. MICHAEL: You can mount it on your helmet or on your bike or whatever. You know, they had one of those kind of it was called the ‘Mophie Outride’, which was… it’s just sort of this attachment for your iPhone that turns your iPhone to a go pro. You know, which I thought was cool. Anyway, a website I'm definitely spending too much time on, Uncrate. JAMISON: If time is all you spend on it, you are getting out. MICHAEL: Yeah. [chuckles] CHUCK: Yeah. I went and looked at it and it was like, “Okay, yeah not a big deal.” And then you pointed out the tech tab and now, I've lost my whole morning. JAMISON: [Chuckles] MICHAEL: It’s dangerous. CHUCK: [Chuckles] Yeah, tell me about it. I love how the first thing on there is a scale model, 1:1 scale model of a 1959 Aston Martin. MICHAEL: Yeah! Isn’t that awesome? CHUCK: It’s way cool. JAMISON: That’s cool. MICHAEL: Years’ worth of quality time right there. CHUCK: There you go. It doesn’t look like it has an engine block in there though, so. JAMISON: Maybe they sell that out separately. CHUCK: Yeah. I'll just put it out on my lawn and it will look really nice. JAMISON: No, you got to take the tires off and put it on cinder blocks. CHUCK: [Laughs] No, that doesn’t work for me. It might work for my in-laws but… JAMISON: [Laughs] Are your in-laws JavaScript programmers? CHUCK: No. JAMISON: Okay. CHUCK: If my father-in-law heard me say that, he’d just laughs his head off. JAMISON: [Laughs] CHUCK: Mainly because he has many cars up on blocks on several different pieces of property. JAMISON: [Laughs] CHUCK: He might actually make some of them run someday. MICHAEL: That will kind of light his fire. CHUCK: Yeah. If he gets mad, I'll just take him golfing; it will all be okay. Anyway, you sounded like you had more than just one pick, Michael. MICHAEL: Oh, yeah. I got to tell the stuff that I'm in to these days. Another thing that I really like to do is play guitar; I don't know if you guys are musicians at all but I know a lot of coders have like other creative pursuits sometimes; you know, between martial arts and doing music or whatever. So this is the thing that I do is music. And something that I've been really getting into lately are these guitar pedals; these MXR Guitar Pedals made by Dunlop. And I'll shoot you the links here but basically, these whole family of guitar pedals that are just like really, really good sounding. I just got a new telecaster last week, so I've been kind of rocking out and my favorite pedal is the carbon copy delay pedal; you can do all sorts of kind of spacy sound effects kind of like the U2 guys and stuff like that. So, if you are into playing guitar and you like to try out some cool effects, go check out the MXR line over at Dunlop because they’ve got some really cool stuff coming out of there. JAMISON: Lots of these are kind of the classic ones too; I think the carbon copies have been around for a while like the flanger that’s been around for a long time too. I play guitar or probably better to say, “I used to play guitar,” and I had kind of a little pedal collection. MICHAEL: Yeah, yeah. JAMISON: So, they are sweet stuff. MICHAEL: So I think you are right, I think they had been around for a while. I've never been much of a pedal head myself, but… JAMISON: Oh, man. If you talk about money things, there's an infinite black hole for your money if you get into that. MICHAEL: I used to buy these amps that would just have like a fatty preamp on them and you would be able to tweak them to your hearts’ content and get whatever sound you wanted out of them. And recently, I just thought, you know what? Forget that. Why don't I just get like a fender twin or something that’s got some really good clean channel and then I can get all these boxes and make whatever sound I want with the boxes. So, anyway that’s my new approach. When you think about it, guitar pedals are kind of like middleware, right? JAMISON: [Laughs] That’s so true. Do one thing well, stack them up. MICHAEL: Yeah. See, this is one of my core philosophy with life. CHUCK: [Laughs] All right. Jamison, what are your picks? JAMISON: One of them is the Tmux book, I think it’s called ‘Productive Mouse-free Development.’  It’s really short; I played around with Tmux before but I never got really into it because there are always a couple little issues that stopped me from being comfortable like I was than just the terminal and this book solves them all and gives me a  lot of cool stuff on top of it. So, Tmux is sweet and this book is a quick read and it helped me find the best way to use Tmux. It’s great. Another random pick, I might have picked this one before but it was a while ago and I finally finished it and it’s the book ‘Gödel, Escher, Bach’ and the more I talk about it, the stupider it sounds; so I'll just say that it’s the best book I've ever read and just completely blew my mind like several times. It’s kind of like the nonfiction book about intelligence and philosophy and AI and stuff; you guys should all go check it out. It’s a bit difficult to get through at points; he talks about some mathematics so you'll read 50 pages an hour sometimes and you'll read one page in an hour some other times, but it’s definitely worth it. It’s a great book. Those are my picks. CHUCK: Awesome. All right. I've kind of been in this crunch trying to get a whole bunch of work done and I'm not sure what exactly to pick. There is one thing that I've really been impressed with and I'm not sure if I picked it before; I was using Things; it’s an app for your Mac that kind of helps you manage your GTD or ‘getting things done’ stuff and anyway, I decided to try OmniFocus because so many people have been telling me to use it and OmniFocus is by far the way to go; it’s got an awesome iPad and iPhone app and then it’s also got the Mac app. the thing I really love about it is not just that it’s nice to use to track all your tasks, but it has like import plugins for everything. And so, you can hit a keyboard shortcut to pull up something just to put a task in, just during your work flow. It also has a plugin for Chrome, so if I'm on a website and I need to do something with it, I just click the little button and it slams it into Omni focus for me. I mean, it’s just super nice and I've really enjoyed having it and it just kind of gets all your stuff out of the way, so that if something comes up and you are like, “Yes, I need to handle this,” you just do it and it’s done. Anyway, so I guess my pick this week is OmniFocus for the Mac and for the iPad specifically. MICHAEL: Can you make your own plugins for it? I mean like you said you can sort of plugin anything. CHUCK: I don't know. Let me see if they have… MICHAEL: If you could like put your GitHub; kind of integrate that, because I do a lot of work on my GitHub, right? And so, a lot of stuff that’s on GitHub for me are to-dos, right? So I have these integrations and I see that the SeattleRB guys have made an OmniFocus GitHub gem here that lets you sync your GitHub to-dos into your OmniFocus. CHUCK: Oh, that’s cool. MICHAEL: Yeah. So there you go. CHUCK: Huh. I'm definitely going to have to look at that. MICHAEL: Yeah. You know what I mean? Like if there's somebody opens a new issue on one of your repos, one of your to-dos is go check it out, right? CHUCK: Yeah. But the other nice thing about it is that they provide a syncing service for OmniFocus, so you just create an account with their syncing server and you just sync everything up. So that will be way cool to be able to pull that in and just have it wherever I'm managing my to-dos. MICHAEL: Yeah, for sure. So it will sync across all your devices; that’s cool. CHUCK: Yeah. Well, I don't think there's anything else we need to go over and I don't have any other picks. So, thanks for coming on the show, Michael. MICHAEL: Hey, thank you guys for having me, really. JAMISON: It was great to talk to you. CHUCK: Yeah. This is one of the guys that I really enjoy talking to. We've been to several conferences together and wound up chatting over lunch and stuff and chatting to users groups and Michael is a smart guy. MICHAEL: Thanks, man! I appreciate that. I'd happy to chat anytime you want. CHUCK: All right. Sounds good. MICHAEL: Okay. Great. See you guys. CHUCK: All right, we’ll see ya. JAMISON: See ya.

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.