083

083 JSJ FRP and RxJS with Matthew Podwysocki


Panel

Discussion

01:01 – 061 JSJ Functional Reactive Programming with Juha Paananen and Joe Fiorini

02:49 – Matthew Podwysocki

05:12 – Functional Reactive Programming (FRP)

07:01 – FRP vs Reactive Programming

09:31 – RxJS

21:15 – Reactive Programming and Backend Code

25:07 – Using Reactive Programming

35:09 – The Future of RxJS

Picks

Next Week

Node with Mikeal Rogers

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  CHUCK:  Hey everybody and welcome to episode 83 of the JavaScript Jabber Show. This week on our panel, we have AJ O’Neal. AJ:  Yo, yo, yo, coming at you so live with a brand new 2005 Subaru Impreza Outback. CHUCK:  Jamison Dance. JAMISON:  [Chuckles] Hey guys. I’m in my brand new bathrobe. CHUCK:  Very nice, very nice. I’m Charles Max Wood from DevChat.TV. And this week, we have a special guest and that’s Matthew Podwysocki. MATTHEW:  Hello everyone. Thank you. Thank you for having me. Glad to be here. I was really excited to hear the recent show on FRP and it was a great overall explanation about Functional Reactive Programming except for one part. It ended up just being mostly about Bacon instead of actually FRP, which is cool. But there are a lot of interesting things going out there in the general reactive world that I think are fairly interesting and not just FRP. But I think Reactive Programming in itself is taking off in its own way very recently. JAMISON:  I’m sorry. MATTHEW:  Go ahead. JAMISON:  No, go ahead. MATTHEW:  I was saying is that it’s picked up a lot of momentum, at least I know in the Java community and everywhere else, with Netflix releasing Rx Java. And so that’s having people being able to, for the first time, really write decent reactive-style programming in Java and on the JVM where they have bridges to Clojure, to Groovy, Scala, et cetera, and even beyond that. Then the folks at GitHub, who tend to be Rx fans themselves, went out and created Reactive Cocoa, which are bindings in a way that it takes a lot of the Rx concepts and maps them directly over to Objective C, which is all very fascinating. So, it’s kind of this coalescing of all of these things at once. And then on top of that, Erik Meijer and Martin Odersky and company are doing a Coursera course on Reactive Programming starting, I believe next month in November, that promises to be very, very interesting, about Reactive Programming in general. Not just FRP but just Reactive Programming in general. I think it’s a very, very interesting time. CHUCK:  So before we get too far into this. First off, I was wondering if you could just introduce yourself really briefly so people know who you are. MATTHEW:  Alright, sure. Sorry. So, I am Matt Podwysocki. I am with Microsoft. I’ve been there for seven years now. I’ve been kind of floating all over the place working with F# early on. And then I started to really get more into the JavaScript side of things because earlier in my career, I had been a JavaScript guy doing healthcare websites, but not HealthCare.gov, earlier in my career, before I joined Microsoft. And then Chris Williams, who’s the organizer of JSConf, he and I used to run a lot of the DC developer communities. So he and I got to know each other quite well and I kind of caught the bug from him on JavaScript. So, what turns out is that we were talking a lot about Node, especially in the early days, say in the 0.2 timeframe/0.1 timeframe wherein us, fine folks using Windows machines were fairly ignored unless you wanted to somehow compile in Cygwin. And sure enough, I would crawl over broken glass and sure enough compile it, because I was that excited about JavaScript on the server. So I worked throughout Microsoft and trying to build enthusiasm for Node. And that turned into a large investment with MS Open Tech, which is a wholly-owned subsidiary of Microsoft which does nothing but cool open source stuff, and able to partner with them and really get Node kicked off. And it’s really spread like wildfire throughout the company, in our Azure mobile services, our Azure platform, and a lot of other places around the company. So, it’s really kind of cool. So for my primary role, I really just work a lot on the Reactive Extensions team in partnership with MS Open Tech. We open sourced all of our Reactive Extensions work back last November timeframe. And since then, it’s been kind of catching up and finding out what the community’s using and so forth. So it’s an exciting time. I’m really excited about where the community’s heading, where the libraries are heading, et cetera. CHUCK:  That’s really cool. The next question I have for you is could you briefly refresh our memories as to what Functional Reactive Programming is? Because we haven’t really talked about it for a couple of months, I think. MATTHEW:  Yeah. Well, Functional Reactive Programming is the idea — the way I like to describe it is what you’re talking about. You’re talking about dealing with — well, let’s see. Conal Elliott describes it one way. Everyone describes it kind of a different way. That’s really in Functional Reactive Programming, what you have are concepts of arrows and so forth. Hold on, let me think here a little bit. That to me, it’s just basically a way of describing or building blocks on top of regular functional programming. So you have lists, then you have map filter, map reduce, et cetera. And what Functional Reactive Programming tends to do on top of that is add concepts such as events being these first-class objects, like a list is, that you can compose over as well. And so, it’s kind of viewing these collections rather over time. So instead of, say, a normal collection like an array where you do map filter for each, so really what it’s about is about this notion where you have a time-based action, a time-based component into this functional programming. And the reactive part really comes down to events. So, what you’re talking about is events over time with a really nice composition model that you would use for arrays and so forth, in JavaScript. JAMISON:  So, you talked a little bit in your intro about the differences between FRP and RP. You mentioned them. MATTHEW:  Yeah. JAMISON:  Can you go into more of the differences? Because I haven’t actually heard of just regular Reactive Programming. I’ve only ever heard of it as Functional Reactive Programming. MATTHEW:  Yeah. Well, Reactive Programming is just for talking about data flows, dynamic data flows. So, it could be where you have flow logic and so forth. One really basic concept that I think everyone would get about Reactive Programming is Excel. There’s not really a functional aspect to it. When I update cell A1 and B1, I expect C2 to change just because I have a formula in there that says react to either of these two changing and I can sum both of them together in the third cell. So, it’s the idea that you’re reacting to changes in the other cells and then it gets propagated to your final result cell. JAMISON:  So, it almost seems like the functional part is more of an implementation detail? MATTHEW:  Yeah. JAMISON:  And the reactive part is the core of the idea. And then you can use functional programming to compose these reactive things if you want, but you don’t have to. MATTHEW:  Exactly. That’s exactly it. JAMISON:  Okay, that makes sense. CHUCK:  So, one thing that I’ve seen with this. I think somebody was showing it off with, I want to say it was with EmberJS. Somebody was showing me that. And basically the way that it works is that this Functional Reactive Programming comes in where you make an AJAX request back to the server and then it does all the DOM updating and stuff when the response comes back. And so, it reacts to getting data from the server effectively. MATTHEW:  Absolutely. Yeah, that is absolutely describing Reactive Programming at its core, is that it’s kind of a data flow where you are reacting to an asynchronous operation such as an AJAX request. And sure enough, something gets updated automatically through one piece or another. It’s kind of like the Excel example that I gave before. And like I said, the FRP notion is the combination logic or kind of the higher order operations that you can do on top of them, like the maps, the filters reduced, throttles, et cetera. So, it’s kind of an addition to. JAMISON:  Sure. So, you mentioned RxJS specifically. MATTHEW:  Yeah. JAMISON:  And you talked a little bit about its differences from Bacon. Do you want to talk a little bit more about RxJS? MATTHEW:  Sure. JAMISON:  What it is and how to use it. MATTHEW:  Yes. So RxJS is an offshoot of — well, I would say it actually goes way back to about 2007, at least the inception of it, for a project called Volta. And what Volta was, was a way of basically doing tier-splitting of your application so that I could write it once. And based upon my target, I could write it as a Silverlight app, I could write it as a Flash app, or I could write it as an HTML 5 JavaScript app, all using the same single codebase. And what we found is that there are certainly interesting things about that. For example, the idea of first-class events and basically, we were like, “You know, dealing with events are a pain, especially when you’re going across different implementations.” And so, we wanted a way to generalize it into a single form and say, “You know, we came up with this thing in .NET,” was that you could build these higher versions like map filter, reduce, et cetera, on top of generic collections without modifying the underlying collection. So it’s fully immutable, goes through the chain, and be lazily evaluated. And we’re like, “Well, this could apply easily to events.” So sure enough, that’s what we ended up calling it, is what earliest linked to events. And in 2010, Jeffrey Van Gogh and myself started writing RxJS which was a pure JavaScript port of Rx itself. And there were, of course, a lot of mismatches in terms of threading and mutexes and so forth. But what we found is 100% of the concepts map over very, very well to JavaScript. So whether you’re doing callbacks or you’re doing AJAX requests or events, we were finding some really, really neat possibilities. So, we were trying to create some really cool examples to do that. So, let’s just cover some of the basics of what Rx really is. And so, everyone’s pretty familiar with the iterator pattern, Gang of Four where you can get an iterator and then you can move next. And it’s kind of a pull sequence where you’re pulling items from a collection and you don’t really get anything until you call next. And each language has its own way of doing that, whether it’s Java, .NET, ES 6 generators, and so forth. And what we found is that the subject observer pattern in the Gang of Four book was kind of a way of talking about push-based collections but in a way. So, we genericized that a little bit and said, “You know what? Really, the iterator pattern and the subject-observer patterns are really duals of one another.” They’re pull collections and the observables are push-collections. So, what we have are two main core concepts. We have our consumer, which is our observer, and that has three main methods: next, onNext which basically will give you zero to infinite values based upon how many things you have in your collection, and then optionally, you have an onError which happens zero to one time, and an optional completion which happens zero to one time, with either/or if the sequence terminates, with an error or with a completion. Then on the other side, what we have is the observable which is basically the producer of data. And its core only has one main method, and that’s subscribe, which everything else is built upon. And what subscribe does is basically it runs through the existing source and you can then compose it with other things. And it takes in that observer. And what it hands you back is a handle, or what we call a disposable in which you can call dispose and it will stop the observable sequence in its tracks. And not only that, it will stop the observable sequence, it will also do stuff such as if you’re binding to events and such, it will automatically clean up all your event handles for you. So you have no dangling events at all. And it’s also pretty useful for things like AJAX requests and so forth. When you want to cancel it before it’s done, just call dispose on the subscription and if it’s not done yet, it will try to cancel it. So it’s those kinds, the two pieces there, the observer and the observable. And then what we added on there was the functional reactive aspects to it in which we added the higher order operations such as map, filter, reduce, and so forth. But reduce is really hard to do on infinite sequence as observables may be. So we added a thing called scan, which is actually just an increment that you get. You get a new reduction and so forth. And time is also a really big component of the reactive extensions. For example, if I want to get the last five events, how do I do that? If I want to get the last events in the last ten seconds, how do I do that? So, it’s a lot of offering operations that we have in there. So, you can really do some interesting complex event processing. In one of our demos that we have out there, we have a stock trader demo in which we started pulling data from a stock ticker and we started doing some really complex algorithms on the streaming data, all in JavaScript. And just breaking down, checking for price spikes, checking for a number of things, highs, lows, averages, and so forth. And this is all with one framework. Now the third aspect of it is, so when we say Rx is observable plus linked plus scheduler. So scheduler is really the third part and actually one of the more important parts that a lot of other people leave out, which makes RxJS actually fairly unique in that regard. Which is to say that the how, where, and when aspect of how a query gets executed is all controlled by the scheduler. So for example, we have three main built-in ones: immediate, current thread, and timeout. And so, immediate does what you think it does. If you have a query to execute immediately, it certainly does. Current thread will try to manage it in a queue, all of the things that it has queued up for you. And the timeout will basically use the best available and quickest available way of scheduling something immediately as possible, such as using setImmediate or process.nextTick or message channels or window.postMessage, et cetera. We also have notions of scheduling in relative and absolute time. So for example, if I want to do schedule an observable to fire next Christmas, I can do that all in JavaScript. And then sure enough, this scheduler will go, “Okay. I will fire this event next Christmas.” How do you test something like that becomes very, very difficult. JAMISON:  Do you have to do stuff in mock out of the clock or something? MATTHEW:  Exactly. So what we have is if you look in rx.virtualtime, which is on our GitHub page, we have a notion of a virtual clock. So indeed, you can swap out any of these schedulers at any point and say, “I want to switch from normal time to virtual time.” And so, testing becomes a snap because you no longer have a callback and asynchronous test. We can run it through and deterministically say that at 200 milliseconds, this happened. At 400 milliseconds, this happened. At 500 milliseconds, this happened. And then at 600 milliseconds, you are done. Every single time. And so, if you look at our tests in there, you’ll find that’s exactly how we test everything and how we tell people to test their applications. There’s no asynchronous behavior involved at all. And they’re just able to write deterministic tests about something that’s been wildly hard to do in JavaScript, period, which is to write good tests for indeterminate behavior. I don’t know about you, but I think that’s by default, testing asynchronous code sucks. It’s hard. And things like QUnit try to make it easy by having async test and start and so forth. But still, that holds up your test because now, you’re waiting a couple of extra milliseconds and hoping that your event fires before then and waiting on set timeouts and hopefully set timeout cooperates in time. It’s those kinds of things that RxJS brings to the table. So, we’ve split it out where we’ve got a core of objects. And then we have each individual thing has kind of its own purpose. So for example, RxJS has time-based operators. We have such as timers, intervals, timestamps and so forth. We even have join patterns. So you can say, “When this event and this event happen, produce this value. When this event and this event happen, produce that value.” We also have almost full SQL query-like semantics where you can do group by’s, group joins, et cetera, over time periods, which is really crazy for a lot of things. But it’s fairly useful when you find out. You’re like, “Holy crap, I can do that? I can really do a SQL query over time against, say, a web socket.” And people are like, “Wow, you can do that?” I’m like, “Yeah, you can.” And where we’d like to go in the future is to go even further than that, is to break it down into more of an expression language in that I can take the callbacks that you’re giving me and break them down into trees and then ship them off to other servers. So for example, you could now have RxJS, or rather even on Reactive Extensions in the cloud so that you’re talking to the Netflix APIs or so forth, all serialized, all in JavaScript, altogether. And so, you could do index DB queries the same way. You can do web service queries the same way, without really having to change any of your code at all. It just, through the magic of the Sprima or something like that where you can really go places. JAMISON:  Can you talk a little bit more about that? One of the questions I had coming into this episode was how Reactive Programming fits into backend code. Because I feel like all of the examples that I see are for frontend code where you’re responding to user input and then you have this sequence of transformations wired together that produce some output. MATTHEW:  Right. There is a product that Microsoft ships as part of SQL Server, which we worked directly with them for called StreamInsight. And what that was is like a Hadoop/YARN kind of thing. When what you’re trying to do is really deal with real-time data and being able to react to it in some form or fashion through complex event processing and so forth. So on the server-side aspect of it all, what you’re really trying to do is a lot of buffering and sliding windows of data. For example, if you’re doing a high-volume transaction system for doing stock trading, what you’re going to want to do is you’re going to want to start to do some time slicing and analysis. Say, give me a five-second window, give me a ten-second window, or give me a minute window or a hundred changes, either/or, give me those. And then you can start to break those down into further more concrete things where you can start really performing on a lot of business logic to say, “Okay, the price has spiked here more than 10%. This is good.” Or, “This is dropping through the floor. Sell. Sell. Sell now before it goes down even further.” And not only that, but we’re talking about building APIs that are really, really responsive. And Netflix is kind of leading the charge in that respect. And as is GitHub with their Octokit thing that they just released yesterday, Octokit.net, where they released a reactive version using Rx so that you can basically have these publish and subscribe mechanisms over wide networks and so forth. So, you can model any number of things with Rx and even RxJS in particular to do a lot of really complex business logic where you’re taking in large amounts of data at a time, slicing it, dicing it, and making decisions upon it, and just as well building APIs to expose the data in the same kind of way. JAMISON:  That makes sense. MATTHEW:  So yeah, but that time component is really important because it’s what makes Rx really interesting. Such as the ideas of back pressure where for example, you could be firing all of these stock ticker events and so forth. But what if your end system can’t stand up to that kind of traffic? Because we’re talking massive amounts of data being shoved at you at once. Is there a way to tell the system to back off just a little bit? Or resume, kind of a speed up or slow down or in the Node.js style of pause and resume on streams, is something that I’m sure we’ll be addressing somewhat in the near future. But in the meantime, we have plenty of ways around that, those kinds of things, whether it’s throttling, buffering, et cetera, that will get you around that. But it would be a nice thing to have an async observable where you’re onNext, onError, and onCompleted calls are promises or generators that you can then resolve at a later time when you’re ready. It’s those kinds of things that are fairly interesting as well. JAMISON:  Sure, that makes a lot of sense. Another question I have about this is that is seems like lots of proponents of Reactive Programming use it as the organization for the application. I don’t see lots of people fitting it into Backbone or Angular or Ember. They build an app out of RxJS, not use RxJS inside of some other framework. Is that accurate with what you see? And can you talk about why people do that? MATTHEW:  Well, I think there are a number of things to address. First off, yes, because I’ve seen a lot of that because Rx is all-encompassing in that you can build all of the binding logic that you want to through such things as behavior subjects or replay subjects to get that knockout JS look and feel. To do that, in fact, I’m writing some examples to do that for our QCon tutorial we have coming up and so forth, where you can do some really complex binding. And yeah, so I’ve found that people are doing that quite a bit, some of the people in the community. But in the meantime, I am seeing some people saying, “You know, I would like to really control the scope, for example in Angular, so that I can delay it and make sure it’s unique.” So for example, I have a search string and I don’t want to overload my autocompleter or my type-ahead. So, I add in things like throttling it by half a second, so I’m not going to react for half a second until you stop typing. And not only that, but I’m also going to make sure that when I’m doing something, that the value is actually changed, so really ensuring that something has worked there. So, I’m working on some bindings for Angular directly so that you can turn the HTTP stuff into observables very easily. They’re promises. And just as well, do scope binding and so forth that will allow you to do richer compositions on top of your scope. What I’m hoping to do to really facilitate that is make a smaller core RxJS to allow people so that if they’re using jQuery or Dojo or whatever, that they get the smallest amount of Rx possible but yet the most important pieces because Rx all-compassing, if you look at our documentation, is quite large. But for the vast majority of UI programmers, they only need a smaller subset. So, it’s going to create a smaller core piece of that. And then, people wouldn’t really complain as much, since they’re adding it to Angular. If it’s only another 5k to 10k gzipped, then it’s really no big deal to add it to your application, especially if you can find the right points. I’ve seen it plenty in Backbone and several other places where you’re using a subject, which I hadn’t explained earlier. But a subject is really nothing more than an observer and an observable all in one. And why it’s useful is what if you wanted to abstract over, say a web socket where you have send and receive operations all in the same thing. Well, a subject is perfect for that. And if you want data binding behavior as well where you’re sending a new value in and you want that value bound to something, well then, you would use something like a behavior subject. So, it’s getting those right pieces in there where people are starting to use these smaller pieces of Rx. And I’m working with John-David Dalton, who’s a good friend of mine and I actually got him hired at Microsoft. And he and I always have these late night conversations about how we can make things smaller, faster, better, because he is all things perf. And so, it’s getting to a smaller core, getting it faster, getting it leaner, and making it easier for people to just suddenly go, “Why didn’t I think of that earlier?” So it’s a very, very interesting time because people are starting to fold it into a lot of their applications. And I’m seeing a lot of excitement from a lot of different people. Bacon has certainly taken off. In that, they have a lot smaller core. And we’re certainly getting there ourselves. It was just a matter of finding out what that core really is to be important to most developers. But for people in the Node world, all bets are off. You can use the whole kitchen sink there. And we’re also working on custom builds to say, “Okay, I only want these 15 methods and that’s it. Go.” And so, just building custom Grunt operations to do that. So plenty of things to do, that’s for sure. CHUCK:  So, do you see people using this in the wild? And do you have an example of a website or specific things that they’re doing with it? MATTHEW:  Sure. Actually, there are a — Netflix is using it a lot. I’m not sure how public, what they’re using it for is, other than I know that they’re using it for a lot of their HTML experience. But ChronoZoom, which is a really cool tool for visualizing the timeline of the universe into small digestible chunks and to really start to dive deep into individual pieces of history. That uses RxJS as well to kind of manage all of their events and pulling in the data and so forth. So, it’s really this huge, huge, really interactive website. And we have some samples out there as well, some gaming examples that I’ve done. And I’m working with a few people on integrating it better in their gaming experiences as well. So, it’s definitely spreading around. But ChronoZoom is certainly one of the ones that give you a wow factor when you realize Rx is handling a lot of what they’re doing. CHUCK:  That sounds pretty exciting. MATTHEW:  Yeah. It’s a very fun project. Projects like that have a lot of real opportunity to show off what Reactive Programming can really do for UIs. Because I think people are getting tired of having to register and de-register events manually, keeping track of resources, and so forth. And as your applications are getting bigger and more complex, if I can hand you a collection of mouse movements, isn’t that a lot easier? Or for example, if I want to describe what, really, a mouse drag event is, which is mouseMove.selectMany or flatMap, mouseDown taken ‘til mouseUp, and then suddenly you’ve just described in three lines how to track when you’re dragging your mouse. You didn’t have to have three different callbacks. You didn’t have to have some weird global state hanging around. You, in fact, encoded all the state you ever needed inside this stream. And this stream then you can pass to any method or you can return from any method. And then when people understand that, they’re like, “Wow! That’s a really cool concept,” especially in JavaScript as we start to get into more and more interactive sites where touch is starting to become more of a thing, is now we can start passing touch events around. Now, we can start passing swipe events around. It’s those kinds of things that really open your eyes. CHUCK:  Huh. Sorry, I’m playing with ChronoZoom. [Chuckles] MATTHEW:  Yeah. It’s kind of addicting, isn’t it? CHUCK:  [Chuckles] Yeah. MATTHEW:  And so, it’s all of those things where people can suddenly just realize the potential of promises are great for one and done operations, but there really was no pattern for helping people with events. And this FRP-style or reactive style that we’re doing here really solves a lot of those problems because we handle all of the events-handling and subscribing and unsubscribing for you. All of the state is within the observable itself so you don’t really have to rely on some global state anywhere. And it just flows through magically. It just makes a lot more sense. And especially since we added in the testability aspects into that, it makes it more compelling. And we have a number of bindings. So, if you want to use with jQuery, we have a jQuery binding set. We have an HTML DOM binding set where I wrote my own AJAX stack. Thank you very much. That was fun. JAMISON:  [Chuckles] [Inaudible] of passage. MATTHEW:  It is, where you write your own JSONP stack, yeah. It was good times. And making sure it was compatible all the way back to IE 6 because I’m J. Dalton that way. [Laughter] JAMISON:  It’s like, ‘that’s so [inaudible]’. That’s so J. Dalton. MATTHEW:  Yeah, exactly. So, it was all of that. And then adding on additional things, like adding things to the geolocation API, web sockets, web workers, wrapping all of those things are fairly interesting. And I have done that in our DOM bindings. And so, people can start to take advantage of Rx in their favorite frameworks today quite easily because of that. CHUCK:  Awesome. So, where do you see RxJS going from here? MATTHEW:  Well, like I said, the expression stuff is awfully interesting. We have a sister library to it called IxJS or Interactive Extensions for JavaScript, which is basically the idea is where you have array-like structures but they’re lazily evaluated. So, unlike Underscore and Lo-Dash where when you call map, filter, or even on Arrays, map, filter and all of that are eagerly evaluated each and every step of the way. With Ix, it doesn’t actually fully execute until you call for each on it and then it finally fires everything. And so, we’re able to get a lot better perf for a lot of people who are doing a lot of chaining operations and so forth. And so, it’s building the expression stuff into there as well. Also, I’m looking into making a smaller core for people who really want to have a smaller core. We definitely want to tackle ES 6 related stuff, like generators, promises and so forth. If we can better integrate with promises and so forth, since they’re seeming to become a standard. Node streams, we definitely want to go there a lot more. Although there’s definitely a mismatch between what they do and what we do which could be a whole another show, believe me. And it’s a lot of exploration. We have pretty much a blank canvas in JavaScript. With ES 6 and so forth is evolving so much that it gives us a lot of opportunity to do some really interesting things. Object Observe is another thing. How do we integrate Object Observe, a mutation observer, and all of that, into the core of Rx? CHUCK:  Wow! Sounds like you’re thinking about a lot of things. MATTHEW:  Yeah, yeah. I’m never short of ideas. That’s for sure. CHUCK:  [Laughter] Very nice. Well, we had some technical difficulties getting started, and so this episode’s going to be a little bit short. But some of us have some commitments so we’re going to go ahead and start winding down the show. But thanks for coming, Matt. MATTHEW:  No, thank you. Thank you for having me. JAMISON:  Thank you. CHUCK:  I think I need to go back and listen through this and look up half the stuff you talked about. MATTHEW:  Oh, sure, absolutely. And if you have any questions, you know how to find me. [Chuckles] CHUCK:  Yup, absolutely. MATTHEW:  Yeah, we’re at @ReactiveX on Twitter and @mattpodwysocki. So, you can find me there. And yeah, let’s keep the conversation going. CHUCK:  Awesome. Yeah, that definitely helps because then people can reach out to you and get help, get insight, whatever. MATTHEW:  Exactly. And most of all, contribute. CHUCK:  Yes. Alright. Well, let’s go ahead and do the picks. Jamison, what are your picks? JAMISON:  I only have one pick. I had another one, but it sounds like Matt’s going to have the same one and I don’t want to steal his thunder. It’s an electronic-ish album. I don’t like straight up techno, but I like lots of electronic-tinged music. It’s called Caesura by Helios. And I’ll post a link to it. And I had to look up how to pronounce that word, because it does not look like how you say it. It’s just great, chill, ambient electronic stuff. That’s my pick. CHUCK:  Awesome. AJ, what are your picks? AJ:  Okay. So, I bought a new car. And I’m a tall guy, I’m six foot five. So, one thing that I can’t stand about vehicles is that whenever I get in them, I can’t see out of the windshield because my eyes are up in that blue zone where it’s the sun blocker. So, I’m going to pick definitely the car that I bought, which is a 2005 Subaru Impreza Outback, which I love in every way. But also, while I was going around, I found that the Toyota Sequoia was also big enough for me to sit in. The Subaru Outback, the newer ones, are big enough for me to sit in. The Subaru Foresters are big enough for me to sit in. The Impreza was definitely the best. I just sat in the seat and it was perfect view of windshield. No blind spots. I loved it. And then almost everything else sucked because I couldn’t see out of the windshield. CHUCK:  Is that it? MATTHEW:  So, you’re basically like Dino from the Flintstones where your head was just popping out of the top of the car? [Chuckles] AJ:  Yeah, that’s basically how it works generally. And I hate driving other people’s cars. I hate riding with other people. I hate getting a rental car because I never fit. But Honda Civics, the older ones not the newer ones, but the old Honda Civics from the 80’s and the really early 90’s, those fit me pretty well. And that’s what I had, except that I wanted something a little bit cooler. MATTHEW:  Gotcha. AJ:  Yeah, most cars, I am like Dino. I’m sitting in there and I’ve got — do you remember that commercial taco-neck syndrome from the 90’s? MATTHEW:  Yeah. AJ:  Yeah, that’s kind of how I am in the car. I’ve got my head sideways, mashed up CHUCK:  [Chuckles] AJ:  And my friends are always like, “Oh, my car is plenty roomy. There’ll be no problem,” and I’m like, “Oh, sure.” MATTHEW:  Yeah, my brother’s six foot five and he swears by Audi. AJ:  Good to know. MATTHEW:  Yeah, he’s got an Allroad, which yeah, has plenty of room. CHUCK:  Yup. AJ:  So, one thing I don’t understand, this idea of the electronic seat mover, backward, forward or tilter. Because if you have to still reach the lever, why in the world would they make it electronic where you have to wait ten seconds for it to move back instead of a manual where you just pull it, shift, done. MATTHEW:  Yeah, true. CHUCK:  Alright. Well, I’m going to jump in with a couple of picks. The first one I have is this Bluetooth speaker that I got for my phone. It’s a Jam Pop speaker, really nice. I got the little bit bigger model and it sounds pretty good and it’s just nice for me to listen to music or podcasts while I’m working. The other pick that I have, I set up the IKEA standing desk that you can find off of Lifehacker and put that on my desks. So, I’ve been alternating between sitting and standing. And it’s pretty nice, too. So, what I do is I just use the Pomodoro Technique. And I sit for a pomodoro then I stand for a pomodoro. And anyway, I’ve been feeling pretty good. I’ve also been walking over 10,000 steps every day. And honestly, just be active. It’s awesome. So, I’ll put links to those in the show notes. And we’ll give Matt a chance to give us his picks. MATTHEW:  Alright. So, my picks are kind of selfish, rather selfish picks. But the first one is RobotsWeekly. It’s a little Google Hangout that we do semi-regularly where we talk to really cool people doing stuff in industry with robotics. And talked to some really cool guys so far, like Rick Waldron for Johnny-Five. We talked to Rockbot about some advanced robotics in JavaScript. Daniel Shaw, Kinect Team guys, and so forth. So, it’s been a lot of fun. And I’ll leave it off with RobotsConf, which is a conference for getting software developers into hardware so that they’re not afraid to burn their houses down just to play with an Arduino board. CHUCK:  Very nice. Is there a place where we can get recordings of those Hangouts? MATTHEW:  Yeah. If you go to RobotsWeekly.com, they’re all there. CHUCK:  Awesome. Alright. Well, I think that’s all we’ve got. So, I just want to thank you for coming. We’ll mention our silver sponsor and that is Reg Braithwaite and JavaScript Allongé. Thank him for supporting the show. And yeah, we’ll wrap it up and we’ll catch you all next week.

x