061 JSJ Functional Reactive Programming with Juha Paananen and Joe Fiorini

by woody2shoes on May 31, 2013

Panel

Discussion

01:20 – Joe Fiorini Introduction

01:42 – Juha Paananen Introduction

  • Software Developer at Reaktor in Helsinki, Finland

02:30 – Functional Reactive Programming (FRP) vs Functional Programming

04:25 – Declarative Programming

05:55 – Map and Filter

07:05 – bacon.js

09:10 – Mapping and filtering event streams

10:40 – Asynchronicity and Promises

14:28 – Using FRP

20:02 – Ember.js and FRP

22:04 – MVC frameworks and FRP

24:35 – Learning FRP

25:49 – Where did FRP come from?

29:07 – Going beyond visual media

32:18 – Wrappers

33:31 – How to build things with FRP libraries

Picks

Next Week

Dojo with Dylan Schiemann

Transcript

MERRICK:  How come nobody acknowledges when I talk? What about that?

JAMISON:  That’s a deeper problem than a microphone.

[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.] 

CHUCKHey everybody, and welcome to Episode 61 of the JavaScript Jabber Show. This week on our panel, we have AJ O’Neal.

AJ:  Yo, yo, yo. Coming at you live from Iowa.

CHUCK:  Again?

AJ:  Oh, I guess I was there last time, huh? It’ll be New York soon.

CHUCK:  We have Jamison Dance.

JAMISON:  Howdy, guys.

CHUCK:  Joe Eames.

JOE E:  Hey there.

CHUCK:  Merrick Christensen.

MERRICK:  What’s up?

CHUCK:  I’m Charles Max Wood from DevChat.tv. This week, we have two special guests. We have Joe Fiorini.

JOE F:  Hello everyone.

CHUCK:  And Juha Paananen.

JUHA:  Yeah. Hi everybody. Juha Paananen.

CHUCK:  Thank you for straightening that up for me. We’re going to have you guys introduce yourself real quick, since you haven’t been on the show before. Joe, why don’t you start us off?

JOE F:  Sure. My name is Joe Fiorini and I am an Interaction Developer at Designing Interactive in Cleveland, Ohio. I do a decent amount of JavaScript development every week. I’ve discovered Functional Reactive Programming three or four months ago and it’s changed my world.

CHUCK:  Awesome. And Juha, do you want to introduce yourself as well?

JUHA:  Yeah, why not? I’m Juha. I’m from Finland. Helsinki. I’m a software developer. I’ve been doing that stuff for something like 15 years. For the last five years, I’ve been working for a company named Reaktor. It’s the best software consulting company in Finland, at least, maybe the whole Europe. I’m an old dog in Java development, but the last five years or so, I’ve been learning a lot of new tricks. I master Functional Programming, at least to some extent. For the last two years, maybe three — no, two years, I’ve been learning Functional Reactive Programming. It’s also changed my life.

CHUCK:  Awesome. So, what do you mean when you say Reactive Functional Programming, or Functional Reactive Programming as opposed to just Functional Programming, which we’ve talked about on the show before?

JUHA:  Okay. A few weeks ago, you had this show about Functional Programming. I listened to it and it was very good. I liked it very much. If you know what Functional Programming is, then FRP is a bit easier to explain. What Functional Programming does to lists and other static data structures, the FRP does the same thing for events. So, you can apply Functional Programming tricks to events. You can lift your abstraction level a bit higher. You don’t have to deal with individual events, but instead you can deal with event streams and you can apply things like map and filter and combine to those streams of events. That will make your programs much cleaner and much more functional. Like, not so many variables, not so imperative.

JOE F:  I like to think of Functional Reactive Programming as almost like types for your asynchronous operations. Just like you can take two numbers and add them together, or take two strings and add them together, it allows you to perform operations on two asynchronous processes, no matter what they are. It could be responding to a DOM event and then taking the value that you got from that DOM event and converting it to something that you then send over an AJAX request. But it’s all in one really nice functional composed stream as opposed to stringing together a bunch of callbacks.

MERRICK:  Sounds awesome.

JAMISON:  I have a friend who’s really into Functional Reactive Programming. And he keeps trying to describe it to me. Lots of the things that he says about it, he talks about declarative programming a lot where you’re describing the relationship between objects or events or operations somehow. And then whenever they change, it kind of reevaluates some computation on the fly for you. So, you just describe relationships and the result comes from those relationships. Is that an accurate description of it?

JUHA:  Well, it sounds pretty good to me, at least. I think the declarative approach vs kind of imperative is the one of the things that really rocks there. I like the spreadsheet analogy. When you use a spreadsheet application like Excel, you can define the contents of a cell using a formula. In that formula, let’s say C1=A1+B1. In that formula, the A1 and B1 are not static values but they are dynamic values. They are kind of signals. Whenever any of those values change, the value of the C1 cell will change. So, you can write a formula and it will be automatically reevaluated when it has to be.

MERRICK:  You mentioned that there’s a lot of use of things like map and filter, et cetera, from the functional world. Are those really even related to the map and filter you find on list events or are they just used for consistency’s sake?

JUHA:  Well, they are the same thing. If you have a list and you use map on the list, you will get a new list and each of the values in the original list will be piped through that function that you gave to map. The same thing applies to event streams. When you have an event stream and you apply a map function there, you will get a new event stream and all of the events in the original stream are piped through your function. So, it’s precisely the same thing as map for lists.

MERRICK:  Awesome.

CHUCK:  So, I have a very serious question here. If I were going to pronounce FRP, is it furp or frup?

[Chuckles]

JOE F:  I don’t know. I’ve just always said FRP. [Chuckles]

CHUCK:  Okay.

JUHA:  Yeah, maybe FRP.

MERRICK:  So, can you guys give a little bit of a pulse on the landscape? I know there’s the Reactive Extensions and then there’s Bacon.js. What kind of FRP libraries do you recommend for people who want to get started with this in JavaScript?

JOE F:  I can say this so Juha doesn’t have to. Bacon.

MERRICK:  There you go.

[Laughter]

JAMISON:  Is Bacon Juha’s thing? Did you create that?

JUHA:  Yeah. That’s correct. Myself, I started with the Reactive Extensions and that was something like two years ago when my friend introduced it to me. It made a lot of sense. It’s a great library. But there were some misuse and some things that I didn’t quite agree with or understand. Then I had to make my own. Rx is good and Bacon is fantastic. There are some others, too. There’s a library called Flapjacks but I’m afraid it hasn’t been maintained for some time. It might be considered dead. But I’ve only heard good things about it, besides it being not updated recently. But yeah, I recommend Bacon, of course.

JOE F:  As I was getting started in FRP, I looked at the Reactive Extensions and I found them to be lacking in a lot of documentation. When it’s a concept as new as this, not having a lot of documentation hurts. Bacon had a decent amount of explanation behind all the different things you can do. The difference between an event stream versus a message bus versus all the other bunch of different types in it that inherit from event stream that you can do cool things with like property listeners and other things. They weren’t very well documented in the Reactive Extensions that I found were extremely well documented in Bacon. My recommendation would be just poring through his readme and the wiki if you want to learn more about it.

MERRICK:  Awesome. Just wondering if it’s similar to, you find a node, how you can pipe these events around using read streams and write streams. Is there any correlation there? I’m just curious what is an event stream? How can you map and filter these things?

JUHA:  The interface for an event stream is quite simple. There is a subscribe method just like in any kind of event-emitting object. So, you can subscribe to the stream and then you will get all the events through your callback. So, that’s the same thing as with many other libraries. And you can always wrap any event-emitting object into an event stream. There’s a bunch of different adaptors in the Bacon library so you can easily take, for instance, jQuery events or Node callbacks. Probably, you could quite easily wrap a Node.js stream also into an event stream. What the Bacon event stream adds on top of those event sources is that it gives them a uniform interface and you can then apply these. You can combine these streams and you can apply maps and filters and flatMaps and all kinds of things on top of that. Does this at all explain it here?

MERRICK:  That’s exactly what I was looking for. Thank you.

JAMISON:  You talked about it earlier in a way that sounded like it’s another alternative for dealing with asynchronicity, similar to callbacks or Promises or the streams in Node. Is that a good way to think about it? I always thought it was a way to abstract away asynchronicity. Maybe that’s the same thing. But it was just a new connection that this is another way to handle asynchronous things.

JOE F:  I think I agree with that. Mostly that it is a different way to handle asynchronous events but it’s also a nice way to abstract away that control flow that you have to implement manually in JavaScript using conditionals or looping.

One thing that makes, especially with regards to Promises, because I’ve actually played a little bit with trying to use Promises in the way that you would use a message bus in something like Bacon where I just want to be able to trigger an event and then listen on that event somewhere else in my app without having the two objects depend upon each other. What I learned was that Promises are actually write-once. So, when you resolve a Promise, you can’t resolve it again which makes it impossible to listen on a Promise multiple times. Whereas with an event stream, you can subscribe to an event stream and you will constantly be getting callbacks. Does that make sense?

MERRICK:  Yeah. They’re a little bit [inaudible] to handle.

JUHA:  I would say that the property object in Bacon is a bit like a Promise. So, just to introduce a couple of concepts. In Bacon.js, there is the event stream which describes a stream of these things, events. Then there is a thing called a property and it’s the same thing as a signal or a behavior in some other libraries. This is a concept that is a stateful thing. You can use a property to model, for instance, mouse position, or some status of a button, or the current number of bullets in a shooting game. It’s a value as a function of time.

The property is a lot like a Promise in the sense that it either has a value or it doesn’t have a value and you can do the same as with Promises that you can fulfill the Promise or you can push the value to a property and then it will have a value and everyone who’s interested in the value of the property or the Promise will get the current value. But the difference between the property and the Promise is, of course, that the property can have a changing value. So just like Joe says, it suits better the situations when some values change, while a Promise only can have one value.

JAMISON:  Sure. That makes a lot of sense.

MERRICK:  Do properties give you the arrow propagation that you find in Promises?

JUHA:  Yeah. They do. With Bacon.js or any other libraries, you can compose these streams and properties in many ways. But no matter which way you choose, all the arrows will go through the chain. So, if there’s an arrow at the source, it’ll get the same arrows through the final stream or property.

MERRICK:  Awesome.

JAMISON:  So, it seems that we’ve talked a little bit about the idea of Functional Reactive Programming. Can you talk about where you have maybe used it in practice and how it’s helped you solve problems?

JOE F:  This is the area where I’ve still been trying to work it into my workflow. But the one place where I’ve really used it the most so far, I have a couple of different, actually. One is a project that I’m working on that I needed a way to, like I mentioned before, essentially I wanted a message bus. So, I wanted an object where I could just declare properties that were really simple event streams where from one object I could push to them, and then from another object I could listen for a value, and just do that over and over and over again. Essentially, like I said, a message bus type of object. And what I found was that doing this with an event stream led me to a really, really simple, very small implementation that worked pretty well for my app.

The other place where I’ve been using them, and this is actually not necessarily JavaScript-related but definitely FRP-related, is a Mac app that I’m working on. I’m using a library called ReactiveCocoa that has this very, very similar implementation to Bacon written in Objective-C. So, I’m using that to essentially, if I have menu items that need to be disabled or enabled in response to an event, instead of having to have some sort of lookup or have some extra methods where I can check if this thing should be enabled and if it is then I can go ahead and enable it, I can just have an event stream that says, “When this thing happens, then one of the things I want to have happen is to enable. Another thing that I want to have happen is to actually run a process.” So, it’s been really nice for allowing me to keep all that code right together in one place rather than having to have it spread out throughout an object or two.

MERRICK:  Sure. So what kind of projects would you think using FRP, it would really excel? Do you think any kind of app would benefit from trying to implement something like this for their events or think that there are certain projects that you should use this?

JUHA:  Nowadays, it seems like I use Bacon.js to solve almost every problem. The hammer analogy. But I think when you write a complex user interface, there are a lot of events. You want your user interface to be really fluent instead of traditional, old school form kind of thing where you press the submit button and then you get to see the errors. So, if you want your UI to respond to every keystroke and display all error mess it sees and validate this, indications in the UI while the user is typing their inputs. Say, the submit button of your form, if you want to enable and disable that continuously while the user is typing input to input fields. That kind of situations reactive programming is very nice because you can compose information from different sources easily or assign different side-effects to that. So, complex UIs would be one.

MERRICK:  Awesome.

JUHA:  One place, at least. There are many others.

JOE F:  What I’ve realized is I think it’s good. You can use it in just about anything. I don’t really think it would be overkill. The downside would be when you have to work on a team. So, there’s a really great example of two doing MVC implementation of Bacon. It’s really great for figuring out how Bacon works and what’s going on. But it’s also, if you don’t understand Reactive Programming in general, it’s fairly tough to wrap you head around until you really understand it. If you’re working on a team where some of the team needs to write some JavaScript but isn’t quite at the level of learning that they’ve learned a whole lot about FRP, I think that could get a little bit difficult. There might be room to abstract out some of the concepts so that it’s not as hard to look at.

MERRICK:  Sure.

JAMISON:  It seems like it applies to almost every abstraction. You’re choosing the value of the abstraction hoping it’s better than the cost it takes to ramp up to learn it.

JOE F:  Yeah.

JUHA:  Yeah, I agree. I agree.

JOE F:  Yeah, definitely.

JUHA:  Like I told, it’s like when you have a hammer, everything looks like a nail. Now, it’s native to me nowadays to use event streams and properties for every problem. I’m not saying that they are the only solution or the best solution, but they are quite applicable to many things, especially if you like Functional Programming in general. They are very nice. I have to say that I don’t get MVC frameworks very well. They are not the tool for me.

JAMISON:  Actually, I was googling some stuff to prepare for this and I saw that Joe, you had some Ember articles on your blog. Have you used Ember with FRP at all or do you think they’re pretty separate domains?

JOE F:  I haven’t yet. I don’t know for sure yet. I think that there could probably be some benefit. But Ember abstracts away so much of the asynchronous work that I think it would have to be implemented somewhere in Ember itself. I don’t know that there would be much of a use for it outside of that.

MERRICK:  Yeah, because Ember, if you call a method, you’ll invoke it. And they also defer everything down to their run loop. So, I bet you’d be fighting Ember a lot if you try to bring in something like Bacon.

JOE F:  Right. Well, Ember is a, we mentioned declarative earlier. I look at Ember as almost a declarative framework for describing your UI behaviors. And even though there’s a lot of areas where you have to write some actual imperative code. But anything that’s declarative is going to, by its nature, is going to abstract away the implementation details of what you’re doing.

MERRICK:  Yeah.

JOE F:  I think that Ember probably could get some advantage from event streams, but I think it would be in the framework itself. I don’t think there’s much that you could do with it outside of there.

JAMISON:  Sure. That makes sense.

JUHA:  I haven’t looked too much into Ember, but what have I understood is that Ember actually is quite reactive already. You can define these bindings and then you can make computed bindings. So, you take one binding and apply some function to it and then you get another binding. It’s already kind of FRP.

JAMISON:  Okay. That makes sense. That actually helps me understand what FRP is a lot more. Thanks.

JOE F:  Something that I’ve been thinking about is what would an MVC framework look like implemented with FRP?

MERRICK:  That’s what I’m trying to figure out, too, because FRP seems very side-effect-driven.

JOE F:  How do you mean side-effect-driven?

MERRICK:  Oh, so well obviously, I have very little exposure to this. But it seems like as you’re streaming these events, you’re just wiring them together with these callbacks and they could potentially be calling, causing side-effects throughout the event stream. You map it. You filter it down based on the value or something. You convert it. You’ll probably get rid of the empty ones and then once you have that, you finally do what’s assigned, which is the end goal. But I suppose you could just manipulate the model layer at that point and then have your bindings propagate. I don’t know. I don’t know how they would play together.

JOE F:  So, one of the things with event streams is that I think this is what you mean by side-effect-driven, but you’re not modifying anything, it’s just returning new event streams all the way down. I think the view would have, if it was an MVC framework, the view would have to be doing exactly like you said, mapping over DOM values in response to events and converting them to something valid and then passing them down. Maybe the controller would have messages on it that the model would just be listening for values and save them or retrieving.

MERRICK:  That sounds interesting. And that article on the Nullzzz blog that I posted a link to kind of touches on how you turn it into more of a model-driven implementation. I think you wrote that, didn’t you Juha? Did you write the Bacon MVC implementation?

JUHA:  Yeah. One of them, yeah.

MERRICK:  Cool.

JUHA:  I wrote the one that, the dozen views in the MVC framework. Then there was one implementation that used Backbone models. I think that was very nice.

MERRICK:  Very cool.

JUHA:  At least, with Backbone, it seems to be pretty easy to combine Bacon event streams. It seems like that might be a way to go.

MERRICK:  Awesome.

JAMISON:  This is really cool because I’ve heard these words before, a lot. And they never really sunk in until now. So, I think it’s finally starting to make sense to me what it is.

MERRICK:  I seriously feel like I’m talking about mapping the human genome or something.

[Laughter]

MERRICK:  I feel like such an idiot this entire show.

JOE F:  I felt the same way when I was learning it. I read a lot of blog posts. I’ve actually been, it’s been a while, a little too long now. I’ve been trying to learn Haskell. And you want to feel stupid? Try to learn Haskell.

[Laughter]

JOE F:  Actually, I feel like I’ve learned more about Haskell trying to write functional JavaScript than I have trying to actually read about Haskell because the concepts are so different. I completely understand and it wasn’t until I started looking, just trying it myself and just playing with more asynchronous-heavy apps that it really started to sink in.

MERRICK:  Yeah, it’s not so much the functional side that warps my mind. It’s this idea of declaratively mapping something that’s so behavior-driven. It’s so event-driven and you’re mutating all these things based on it, but it doesn’t exist yet. You don’t really have a data flow. It’s like an eventual data. I don’t know. It’s just mind-melting.

JAMISON:  Yeah. I totally agree with that. This isn’t an idea that came from JavaScript, right? This seems like one of those old computer science ideas that someone from the 50’s thought up and then it took us forever to actually realize it was awesome and use it in production. Do you know anything about where this idea of Functional Reactive Programming came from?

JOE F:  I just posted a Stack Overflow post actually, that speaks to that. It came from a paper, I think in 1998. Juha might be able to speak on this better than I can.

CHUCK:  Holy cow! Yeah, there’s quite a bit there.

[Chuckles]

AJ:  I’m not convinced that it didn’t come from the Twitter Anywhere API.

[Laughter]

JAMISON:  What? I don’t get that joke.

CHUCK:  I feel smarter just having scrolled through this.

JUHA:  Where did this FRP come from? I’m not sure which article you’re all talking about, but it might be Conal’s article.

JOE F:  Yeah, that’s the one.

JUHA:  That resulted to a certain Haskell library. It might have been called just Reactive, I think. There’s a lot of effort in libraries for Haskell already and some of them are fairly old. Then there is a library called Reactive-banana. I think possibly the one that’s most maintained in the Haskell world. That’s also one where I drew a lot of influence from into my own library. I wrote Bacon first for Haskell, of course. There’s this Reactive-bacon library that I wrote something like two years ago in Haskell and that’s helped me grasp the concepts and the types defined in that library. I don’t know if I could have done the same without doing it in Haskell first because its type system really helps you. Haskell is cool.

The roots are probably in Haskell. But if you think about spreadsheets, I think spreadsheets are FRP already. You can do FRP with Excel. I’m not sure if it’s implemented with an FRP library, but the idea is the same.

JAMISON:  Where you declare these formulas and then when you change the data, they just update their calculations. That’s really cool.

MERRICK:  Can I just make a side note? That Conal document has some really creepy animations on it.

[Laughter]

JAMISON:  It’s like the ring tape for programming.

MERRICK:  [inaudible] animated [inaudible]

JAMISON:  Oh my, gosh.

MERRICK:  I’m not making this up, dude. Like horribly clipped out kids’ faces just being animated in arbitrary ways.

JOE F:  Are we all going to die in seven days?

JAMISON:  Yeah, that’s what it feels like. A fly crawls out of my computer.

MERRICK:  All I’m saying is you can’t un-see it. So, if you [inaudible]

JOE F:  I think it’s a little girl who died in an event stream.

MERRICK:  It seems like it.

[Laughter]

JAMISON:  She haunts it to this day. This model catches on for further tutorials that use animations. I’m just making that as creepy as possible.

CHUCK:  So, it looks like from Reactive-banana and some of these, that what they’ve done is they’ve actually been using this for graphical GUIs and stuff. You’re talking about the same kind of thing with the DOM. Are there applications for this that go beyond a visual media?

JUHA:  Yeah. I’m sure you could use FRP on the server side. I haven’t done much of that so far. I’ve written one bot for a competition where you had to write bots that drive certain kind of vehicles in an imagined environment. You had to write some kind of artificial intelligence for that. I used event streams and properties to define that. I think it’s very nice. I guess in any application where you have inputs from many sources on the server side. For instance, if you were writing the server side of this Skype application, then you might benefit from an FRP implementation because it would make it easier to compose and combine inputs from different sources. Technically, it’s pretty easy to wrap any kind of inputs in drive event streams in a Node.js environment. But that’s something I don’t have too much practical information yet. Maybe my next server side application will be written in Bacon. Then I can tell you more.

JAMISON:  It seems like it’d be a good fit for just responding to HTTP requests, where you just define some relationship between a URL and then some computation happens. I don’t know. I haven’t done it yet, so I’m making this up.

JUHA:  Yes.

MERRICK:  It seems like it’d great for the I/O stuff in Node.

JOE F:  So, I just actually posted a link to substack’s GitHub. He has a project called stream-handbook that is using Node streams which I don’t know the actual implementation and how Node stream is different from event stream. I think somebody asked about that earlier. But it sounds like very similar, the same concept. So, he has a whole write up on using Node streams to do different things like reading from files, creating HTTP servers, all that kind of stuff. And it looks very similar to what we’re talking about here.

JUHA:  I think Node streams are still lacking those mapping and filtering and flatMap and combining capabilities. That’s something that you could add with FRP. You would be able to compose information from different sources on a higher level.

JOE F:  So, would you say FRP is taking the stream concept and then making them small composable functions?

JUHA:  Yeah. I would say that.

MERRICK:  Is there any wrapper? I know there are wrappers for jQuery and all these kinds of things. Is there any wrapper for Node streams for Bacon.js?

JUHA:  I’ve been thinking about writing such a wrapper on it. It shouldn’t be too hard. The problem is that I don’t need it. The Node streams, they have this interface where you can say stream.on and then some event-like data or error, I think. There is a general adaptor in Bacon that you can use to wrap any so-called on events. I think it was from event emitter. So, you could easily wrap a single event on a Node.js stream into an event stream. But if you want to make a complete adaptor for Node streams, you would also have to deal with the error events, I think, in the Node stream. But it should only be something like five or ten lines of code.

MERRICK:  Awesome.

CHUCK:  That’s really, really cool. Are there any other aspects of this that we haven’t touched on that we should go over?

JUHA:  Well maybe, how to actually build things with FRP libraries. But that’s something that’s kind of hard to explain on the radio. It’s like trying to describe a painting on radio. You should see it.

CHUCK:  Are there any videos on that?

JUHA:  They took a video from the MLOC.JS conference where I was presenting Bacon.js. It was a conference in Budapest, Hungary. There is a video of that. I’m not quite sure if it’s any good. I haven’t watched it all the way. I can’t watch myself. But I can look up the URL to that and you can just try yourself.

JAMISON:  It seems like this is a really good episode to read the show notes and follow some of the links in there because I’ve just been browsing them as we’ve been talking. They’re really good. At least for me, it took several times bouncing off this idea to understand it a little bit more.

JOE F:  When I was first getting started, I read some of Juha’s blog posts. I think he links to them from the Bacon.js readme. Those are really good, too. I actually think we may already have one in there. But he has some blog posts where I think he explained the concepts decently well. And I’m not just talking up Juha.

[Laughter]

JUHA:  Thank you.

CHUCK:  Awesome. Alright. Well, let’s go ahead and get into the picks, then. AJ, do you want to start us off with picks?

AJ:  Yeah. So, there were some stuff I picked at the very end last week that didn’t get into the show and I’m trying to find the links to it right now. I’m going to pick this slide show slide I’m looking at right now, though. It’s on the Functional Reactive Programming. It’s pretty cool stuff. Come back to me in just a second.

CHUCK:  Okay. Jamison, what are your picks?

JAMISON:  So, I have three picks. I haven’t been on this show in a really long time, actually. So, these have been building up for a while. One is this presentation from Valve talking about how they do the AI in Left 4 Dead. It’s really fascinating because if you’ve ever played that game, the AI is really good. They dynamically changed the difficulty of levels and the levels are kind of pseudo-randomized. So, they’ll change where weapons caches are and change where enemies spawn and it all reacts to how the player is doing. So, if it’s too hard, [inaudible] just to make it easier, stuff like that. So, that was a really interesting read.

Another one is a blog called ProgrammingIsTerrible.com. I just stumbled across this and I really liked this guy’s writing style and thought he had some insightful things to say about software development in general.

And the last one is one that everyone talks up and I’ve heard it pointed out dozens of times. I just never got around to watching it. It’s a video by Rich Hickey called Simple Made Easy where he talks about the difference between making things simple and making them easy and how they sometimes conflict and how we should prefer simplicity to easiness because that leads to less complexity overall. It’s really good.

He’s the guy that is the benevolent dictator for Clojure, so he definitely talks up Clojure a lot. But it’s still a great talk overall, even if you’re not a Clojure user, which I’m not. I still got lots out of it. Those are my picks.

CHUCK:  Yeah, he gave that talk or a version of that talk at RailsConf last year. It’s pretty good. Joe, what are your picks?

JOE E:  Alright. So, for my first pick, I’m actually going to pick my AngularJS Fundamentals course that I’ve just released, kind of a shameless self-plug, over on PluralSight. I’ve been working on this course for three months with Jim Cooper. And we produced six hours of screen casts about the very basics of using Angular. Really had a fun time doing it. I learned a lot. But it’s a great way to really get a start to using Angular. So, I’m going to pick that.

A little bit more plugging, as well, I’m speaking at two conferences this year that are coming up. Open Source Bridge in Portland is coming up at the end of June. I’m going to be talking about test-driven development with Angular there. And then also, That Conference which we mentioned before. I want to pick it again just because it’s got Bacon. We talked a lot about Bacon today. That was pretty much my take-away from the conversation, was Bacon.

[Laughter]

JOE E:  That Conference. I’ll be speaking there about Angular. And they have a lot of Bacon.

And for my last pick, I’m going to pick Star Trek: Into Darkness. Possibly the best Star Trek movie ever.

JAMISON:  Awesome.

CHUCK:  Oh, really?

JOE E:  Oh my, gosh. It was so awesome.

JAMISON:  High praise.

JOE F:  Yeah. It was great.

JOE E:  You know, in its day, maybe Wrath of Kahn was better. But nowadays, it’s a pretty dated movie. So yeah, Into Darkness was awesome, really enjoyed it. I actually spent three months prepping my kids, having them watch some episodes of the original series, the second and fourth movies, then this last reboot, the Star Trek movie from a few years ago. And then finally, Into Darkness. They’re 15, 14, 10 and 8. Mostly they complained and then when it was all over, they were really, really happy and loved the movie. So, it was pretty funny.

CHUCK:  So Joe picked indoctrination along with everything else.

MERRICK:  Yes.

JAMISON:  It’s a brainwashing.

JOE E:  Successful parenting. You can use it on your kid’s iPad/iPod.

CHUCK:  Nice. Alright. AJ, what are your picks?

AJ:  So, I’m definitely also going to pick Into Darkness. I don’t want anybody going in there thinking that it’s an amazing movie because anytime you do that, it turns out that it’s not as amazing as people tell you it is. So, I won’t tell you that. But I will tell you it’s pretty amazing.

[Laughter]

CHUCK:  Thanks. I appreciate that. I think we’re going to go see it tomorrow.

AJ:  And also, there’s this site called ServerBear and if you’re looking at VPSs, it allows you to compare all of them in these nice little charts. So, when you’re looking for just a cheap little ditty to put something up on, you can check it out on that site instead of googling and looking through the cheap VPS host forums and yada…yada…

JAMISON:  Oh man, that’s a gateway to spambots. That’s what that is. I’ve done that before and it’s no good.

AJ:  So, I like ServerBear. Even the new ones, like DigitalOcean is on there. You can sort by different parameters like you can sort by how much hard drive space you get or CPU or memory. So, I got this one project I wanted to have a lot of hard drive space for. So, it was kind of cool to be able to look at that.

The thing I talked about last week, the OverClocked ReMix, I failed to mention that you can download all of the songs, as well as listening to it on the radio portion of the site. You can download all the albums on the actual OverClocked ReMix site.

Then the RainWave site, which is the one that adds the music streaming stuff, it’s actually a Python backend. And it’s all on GitHub. So, if you are interested in how that media player works, it’s available.

CHUCK:  Awesome. Alright. Merrick, what are your picks?

MERRICK:  I have two JavaScript picks, one really random pick. So, I’m going to start at the random one and that’s this guitar amp called the Mesa Boogie Lone Star Amp. It’s just [inaudible].

JAMISON:  Oh my goodness. You have one of those?

MERRICK:  I do.

JAMISON:  I didn’t know you played guitar. We have to geek out about guitars though, some time. Sorry.

MERRICK:  We do. I love that amplifier so much. I’ve had it for actually about three years. Most of my guitar equipment, I get jaded about because it doesn’t sound as good as people I listen to. But that’s really just me being bad. But the amp, I’ve not ever gotten jaded to. I love that thing.

[Laughter]

My other pick is a project called backburner.js. What it is, is it’s the run loop for Member.js rewritten. And Ember’s actually using backburner.js. So, if you’re interested in deferred execution and how Ember can optimize all their bindings. If you’re doing a for loop and you’re changing the model 100 times, they’re not going to update your UI 100 times. And that’s this run loop concept they have, which I think would do tremendous things for about any Backbone application.

The last thing is we’ve been internationalizing our app. There’s a project called messageformat.js from Alex Sexton and it’s just terrific. It’s just a wonderful internationalization solution and it supports pre-compilation. It’s fast. It supports gendering, pluralization, all that kind of stuff. So, those are my picks.

CHUCK:  Awesome. I guess I’ll go next. So, I’ve got a couple of picks. I was in this situation where I was working on some client stuff and I got everything set up for their project and I was getting ready to do some work. My wife came in and said, “I’ve got to go run an errand. You need to go downstairs and be with the kids.” Well, my Mac Pro doesn’t exactly transport downstairs very well, so I took my laptop and I went downstairs. I spent all the time setting everything up again just in time for her to come home so I could go back upstairs and get back to work on my Mac Pro. And then, a few minutes later, I got a call from another client, so I switched gears and got into gear and got things going for that client and then she came in and I had to go back downstairs again, and so I went through the whole thing again.

I got tired of it and at the same time, a lot of this stuff is way easier to set up in Linux than on the Mac. And so, I’ve actually bought another server at DigitalOcean.com. That’s one of my picks, is DigitalOcean.com. They’re a pretty inexpensive VPS provider. Anyway, I set it up. I installed Emacs. I installed tmux. And those are my other picks. Emacs and tmux.

So now, I’m using a tmux setup where I basically have one window open and that’s the different frames or however you want to think about that. Anyway, I have one window open with Emacs in it. Typically, I have one window open just to the command line so that I can run tests or run tasks or access the database or whatever else I want to do from the command line. And then if I’m working on Ruby, I have Guard open. And Guard runs all my tests automatically and does all this automation stuff. So, it works out really, really nicely.

And then the other thing I’ve started doing is I start a tmux session per client. So, if I’m working on one client’s stuff then I just open that session and I can pick up right where I left off. Then if I need to do something for another client then I just tmux switch session and then I can just go into the other session for the other client or my own stuff. Anyway, it’s been really, really convenient. And I’ll put a link to those things in my show notes along with the Emacs configuration that I’m currently using but modifying.

And then, my last pick is GitLab. If you haven’t looked at GitLab, it’s basically an open source version of GitHub that you can host on your own. It’s not nearly as fully-featured as GitHub. But it’s a nice way if you don’t want to pay for private repos over there. You can just host it somewhere and then do all your Git setup on there. And it was reasonably easy to set up. So anyway, those are my picks. Joe Fiorini, what are your picks?

JOE F:  Alright. I have two JavaScript picks. The first one is Flight from Twitter. I don’t know if anyone here has used that yet. But it’s their UI framework. I don’t want to call that an MVC framework because it’s really not. But after giving it some thought and actually trying to write my own MVC framework, I came to the conclusion that for smaller projects, MVC in general is kind of overkill. There are other things that we can do that might be a little more effective and I think Flight does that really well, especially if you want to do any server side rendering. Flight makes it really nice. So, that’s my first pick.

But I can’t pick a UI framework without also picking Ember because for larger apps, I think Ember really just kills. But I think there’s been a lot of talk on here about that so I won’t go into too much detail. I’ve been using it a lot and enjoying it.

And then finally, I was going to pick Game of Thrones, but I think Joe mentioned That Conference, which I just looked up while we were talking and it’s at Kalahari in Wisconsin, was it? So, I can’t let that go without mentioning CodeMash, which is in my neck of the woods at the Kalahari Resort in Sandusky, Ohio. And it’s a four-day conference in January, in the middle of the winter, at the same indoor water park, where coincidentally, my company actually sponsors a pretty large bacon bar.

[Laughter]

JOE E:  All things have come together.

JOE F:  I think last year we had 25 pounds of bacon and all kinds of toppings and dip and stuff to eat with it. It was amazing.

CHUCK:  You know, it’s going to sell out.

JOE F:  Last year, it sold out in a half hour, I think, for the 1200 tickets.

AJ:  It sells out fast.

CHUCK:  I’ve heard good things about CodeMash.

JOE F:  It’s a fun conference. It’s a multi-track, lots of languages. It’s not platform-specific at all. There are Ruby talks, Python talks, .NET, Java, iOS, some Android, design stuff. There are all kinds of talks there.

CHUCK:  Cool. Juha, what are your picks?

JUHA:  I didn’t actually prepare too many picks but for all those who are into Haskell and monads and stuff, you should check out Brian McKenna’s fantasy-land specification where he defines interface for monads, functors and applicative functors in JavaScript. Monads are cool. Bacon.js implements monads, of course.

Then there is great slide set that I already linked you to. This Philip Roberts’ Bacon.js slide set. It can be found from the Bacon.js wiki documentation page where there are links to some other nice Bacon.js related postings, too. It’s pretty much, Bacon related stuff.

And you talked about the Star Trek movie and I think everyone should see Iron Sky because it’s a Finnish science fiction movie and it features Nazis living on the dark side of the moon attacking earth from there.

[Laughter]

JUHA:  It’s quite far out. But it’s very well implemented. It’s fun.

Then it’d be nice to see you guys in Reaktor Dev Day in the autumn in Finland. So, ReaktorDevDay.fi, I think, would be the URL for that. You’re welcome there. And thank you.

CHUCK:  Awesome. Well, thanks for coming again.

MERRICK:  Yeah.

JOE F:  And thanks for having us.

JAMISON:  Yeah, this was great.

CHUCK:  It really was. It’s one of those episodes where I’m going to have to listen to it four times so I can understand it. But really, really good. Other than that, we’ll wrap this show up. We’ll catch you all next week.

0 comments

Previous post:

Next post: