The Rogues talk to Ryan Stout about the Volt framework.

Special Guest: Ryan Stout.

 
RYAN:

Okay, got it.

Yeah, pray to Mandy. She does live in the sky and she will answer your prayers.

Hey everybody and welcome to episode 193 of the Ruby Rogues Podcast. This week on our panel, we have Avdi Grimm.

Hello from Pennsylvania.

Jessica Kerr.

Good morning.

Coraline Ada Ehmke.

Hi there.

David Brady.

My poop doesn’t stink, and if you want to find out stick around for the picks or if you desperately want to know that’s when you should start fast forwarding.

I’m Charles Max Wood from DevChat.TV. And I kind of want to really quickly dedicate this show to somebody who got me started on this career path. My grandfather was an engineer and did some work on the space shuttle and some other things. And he passed away last week. He was the person that took me under his wing and introduced me to electronics and math and engineering. And that’s what got me started at an early age heading toward this career path. So anyway, it’s kind of a weird thing for me, but anyway I’d like to dedicate this episode to Tennyson Smith.

We also have a special guest this week, and that is Ryan Stout.

Good morning. Thanks for having me on the show.

Do you want to introduce yourself real quick?

Yeah, I guess a little background. So, I’ve been doing programming forever, like you said, since I was a kid. And recently I’ve been working on a project called Volt that some of you may have heard of. It’s a Ruby web framework and a client-side framework all written in Ruby. So, we can dive into that in a minute if you want.

I saw the movie about Volt the other day.

Does it use the Ohm gem?

Does Volt use the Ohm gem?

Yeah.

No, that just…

Oh, okay.

It just introduces resistance. Stop it.

Oh, I [get it], yeah.

Ha-ha-ha-ha.

Yeah, but volt plus ohms, or volts times ohms, divided by ohms?

Divided by ohms.

Divided by ohms is current. So anyway, alright we’ll stop. [Chuckles] So anyway, do you want to give us a brief overview of what Volt is?

Yeah, so I guess a good way to think of it is we’re trying to rethink how you build web applications. Back when Rails came out, what you were doing was basically spitting out HTML. And now we’re in a place where we’re building entire MVC apps both on the client and server. And so, what we’re trying to do is eliminate a lot of the duplication there. And then once we do that, we can get some nice benefits. So for example, what we do with Volt is we actually compile your Ruby code to JavaScript using Opal, which is basically a Ruby to JavaScript, they call then transpiler. But it takes your Ruby code and maps it to JavaScript so that you can run it in a browser. And so, we use that to let you write your models, your controllers, your views all in Ruby. And then it runs both on the server and the client.

And so, some of the benefits of that are once you have where you’re sharing models on both sides we could do things like automatic data syncing where your models, as soon as you change them on the client it automatically syncs it back to the server. And then we’ve got rules you can set up to say, “Okay, go ahead and sync this up to all of the other clients that are listening to the data,” and things like that. So, a good way to think of Volt is it’s both a frontend framework and a backend framework together, and then has all these things to make it so you don’t need to build a REST API just to sync data to the client, for example.

We’ve seen this kind of thing in JavaScript, right?

Mmhmm.

With Meteor, they’ve got…

Yeah.

There are a couple of other ones that I’ve heard rumors of that I haven’t really looked at or tested out. And the dream with these is that you can share code between the frontend and the backend. Is that really the case with Volt?

Yeah, it is. it’s interesting too because what ends up happening is I find that you’re actually writing probably about 70% of your code on the client. And it really just runs on the client. And then longterm we’re going to do things where you can render ahead of time on the server to get faster page loads and things like that. But it’s nice because, especially for your models where all of your business logic is, you can write that once and then share it. You don’t actually end up needing, your views don’t necessarily need to render on the server. Aside from the quick load it doesn’t really give you a benefit to have Rails-y views. It’s more of how you do frontend bindings and things like that.

And then like I said with the models, it’s great to be able to share. We can do things like real-time validations where you’re using the same validations everywhere. And then you get the benefit of as you type, you can see the errors in the fields and things like that.

You’re accomplishing a lot of that using WebSockets?

Yeah, so the actual data syncing is WebSockets with some fallbacks. And that lets you push the data back out. And then Volt gives you these reactive bindings for the DOM. So, whenever your model changes it’s going to automatically update the page.

I thought the simultaneous syncing to multiple clients that you demonstrated in your RubyConf talk was really cool. How does Volt deal with conflicting changes to different clients?

So, at the moment it’s a last write [weighted] strategy which is obviously not ideal. The ideal solution I think as far as long-term is operational transform. There is actually a JavaScript framework that I would say is mostly dead right now but called Derby that does operational transform on your models. So, whenever you change one of your, some property in the model, it’s almost like you’ve got a Google Docs style real-time editor in that field for example. So, if two people make changes at the same time, there’s version tracking built in. And it’s able to merge the changes based on, they call it I think, what do they call it, something intent. Anyway, there’s a whole science behind operational transform. We haven’t implemented that yet just because it’s quite a bit of work.

There’s actually a JavaScript library called ShareJS. And there is a Ruby port for the backend that somebody did. But it’s a little out of date. And so, when we do get to that, we’ll have to decide what the best [inaudible] for that is. The nice thing is the algorithms are fairly well understood. It just takes a lot to build them and then make sure they’re tested and everything. So, I guess right now if two people are typing into the same field with a live binding, they are going to overwrite each other’s changes.

The one thing I would say too is that I think Meteor really tried to pitch itself as a real-time framework. And it almost hurt it a little bit in that most people aren’t building real-time apps, at least from what I’ve seen. And so, one of the things we’re trying to do with Volt is really make it so that it’s also good for CRUD and the things that you would use, maybe Angular or something like that for.

So, that simultaneous multiple client updates isn’t the use case you’re aiming for. It’s just a side benefit that happens?

Yeah, I think people are going to start using that more and more. One of the things that’s interesting though is you have these situations where you have some validations on your model. Your model has to be in some sort of state before you want to pass it around. And so, the way Volt deals with that is you can, your models basically sync automatically as soon as you change a property on the model. But what we do is if you don’t want to sync it right away, you can grab what’s called a buffer on it. And a buffer won’t actually sync until you call save on it. And so, that gives you a nice way to do form validations and things like that, because you don’t want… it makes it so that you can make sure the model’s valid before it actually goes and syncs it to everybody.

So, you have the option of taking control of when the syncing happens.

Mmhmm, yeah. But the models themselves are inherently syncing as you go. So, you kind of decide, “Oh I’m going to bind this field to the model directly,” and then you get the real-time updating or, “I’m going to bind it to a buffer,” and then when they hit submit it’s going to sync back. And so, it changes the pattern of, if you think of handling forms, you don’t actually need to do an Ajax call or anything. You just save the buffer back to the model when all the form data’s ready. And the buffers will give you the same kind of validations that you get on the models, if that makes [sense].

What are the limitations on things that you can do with models in terms of translating them from Ruby to JavaScript with Opal?

So, Opal’s actually, I don’t want to say shockingly good at it, at how compatible it is with Ruby. There are a couple of things. It doesn’t have immutable strings, which you probably shouldn’t be doing anyway. There’s actually a pretty short list. I’m trying to think of one. Some of it, there’s a couple of things where, so they do number type. They have one number type instead of, you know, there’s numeric and then everything inherits from there so you don’t have Fixnum and Bignum and things like that. Really, it’s actually surprising how little you have to spend thinking about, “Oh, in Opal I’ve got this limitation or that limitation.” They have all the things that you can do in Ruby. You’ve got method_missing. You’ve got all the module stuff. And it’s pretty impressive if you’ve used it.

Now, what version of Ruby is it emulating?

I think they’re doing most of Ruby 2 specs. They just added keyword args.

Oh, okay.

Yeah. And they just actually pulled in the MRI specs, too. So, they’re starting to try and pass all those as well.

You said that this tested against Ruby specs in your talk. And I thought you said it was passing against them.

It’s not all, not all of them.

Okay, okay.

Sorry if I didn’t make that clear.

I was going to ask you, how do you pass Ruby specs if you don’t have mutable strings? And I was completely prepared for you to say, “Well, under the hoods, they copy the string every time you mutate the string,” or something like that.

Yeah, no. They’re actually just having some that they’re disabling. And they’re just saying, “We don’t port this.” They do a pretty good job especially of saying, “We want to support as much of Ruby as we can,” and then if something is just horrendous on performance they don’t do it. So, they’re trying to make it where you can do almost everything you can do in normal Ruby. But then, it’s not going to blow up on your performance-wise.

Let’s talk about how Opal does math for a minute.

Mmhmm.

Because I saw that passing in a string that contains hash minus…

Yup, so that’s an interesting one. So, out of the box yeah, they’re doing method calls for addition, subtraction, things like that. They have a flag, compiler flag that you can set for what they call inline operators. So, that’s actually just going to use the normal JavaScript addition, subtraction, things like that. If you have heavy math stuff, I would actually suggest if you’ve got a bunch of heavy math stuff and you only need it on the client side, you can do inline JavaScript. That’s probably the better way to do it. But you could also enable the inline operator flag, they call it.

Okay, so skipping over the fact that I find the sentence, doing lots of math with JavaScript, to be hilarious just in and of itself… [Laughter]

Why would you not just enable inline math all the time? What do you lose? Do you lose debugging ability when you do that?

You lose the ability to override the plus and minus on Fixnum.

Oh, okay.

On numerics, I think.

Mmhmm, okay.

Yeah, which I guess most of the time that’s not a big deal.

Wait, so what you’re giving up is the ability to monkey-patch one of the core types?

Right. Yeah, exactly. [Chuckles]

So, let me go back to my original question. Why would you not just enable this flag all the time? [Laughter]

Yeah, yeah exactly. And the Opal team may know, they may know more about it. That’s kind of from what I’ve seen. I haven’t had any projects doing a ton of math in JavaScript yet, so I haven’t really looked into it that much.

Well, I have a really good idea. Go play with floating point math in JavaScript for a while.

Yeah. [Chuckles]

And then come back and tell me how that worked out for you.

I was going to say, play with any other type of math in JavaScript until you figure out that it’s actually using floating point behind your back.

That’s right. [Chuckles]

And now, a lot of the browsers have, they actually do have typed arrays where you can do, you can specify integers and things like that, I think. I could be wrong on that. But I’m pretty sure Chrome and Firefox and maybe Safari have it now. So, you can do, there are ways to do integer math and things like that.

That’s good news.

But not as easily, obviously.

Yeah, because floating point math turns out to be just as spooky as it sounds.

So, I’m curious. Does the fact that it’s tightly linked JavaScript on the client and on the server, does that just imply that we’re talking about single-page apps here? Or is that an orthogonal kind of consideration?

So, the way we do it is actually, you basically build apps as what we call components. And so, components are these almost self-contained parts of apps that you can reuse. And then components can depend on each other. And basically what you can do is you can say, “This part of my app renders with this component.” And then that component will include other components. And so, you can have, some of this is still a work in progress, but you can have multiple components that are individual single-page apps within your app as a whole, if that makes sense.

And so, the way we do moving between state in the apps is just with URLs. And so, you might have where part of your app is on, one set of URLs loads up one single-page app and then another set, when it goes to render a template or a URL it’ll say, “Okay, are these routes within this component?” And then if they’re not it’ll actually just do a normal request.

Oh, okay.

And so, what we try to do is make it so that you don’t have to load up your entire app as a singlepage app, because what I found at least is after a while you’re sending every template or all the code for your entire app. And really, there are sections of your app that aren’t going to get hit that often. And so, you might as well make those as a separate single-page app, if that makes sense.

Mmhmm. Yeah, definitely.

I think I get it. So, a component is just a section of the page that you use. You can think of it as not the entire page as an application but each little bit?

Yeah, a component’s almost… so, they’re similar to if you’ve used React components. So, they’re sort of, you can render their contents as a template or a tag. So, you end up where it can be anything from a field with error messages to the blog pages, or anything in between, if that makes sense. So, you have where it’s, you can package up a specific part of your app and then use it from inside of another component. So, you get…

I’m curious.

[Inaudible] nested components.

I’m curious what got you interested in this basic problem and what led you to start making the Volt project.

Yeah, that’s a good question. Yeah, so I’ve been thinking about, I’ve been doing heavy frontend apps for a while I guess. So, my first job out of college in ’05 was doing really big heavy frontend JavaScript apps. And then we were doing Java on the backend. And then I’ve been doing Ruby development for a while and seeing how, especially now that we’ve got, a lot of people are using Angular or Ember, you really are doing too apps. And at least for me, you’re duplicating a ton of code on both sides. And so, anytime you’ve got a ton of code duplication, there’s some lowhanging fruit I think to improve workflows and improve the way we do things.

And I think especially for me, I do mostly freelancing. It’s myself and my brother. We have a really small shop that we have. And I see if things keep going the trajectory they’re going, we’re going to lose the ability as a single developer to be able to build an entire app. So, people are starting to specialize a little bit where I’m just a frontend person or I’m just a backend person. And I think specialization’s fine. But personally I want to be able to easily build an entire app myself. And so, I just see that coming and would like to just try and steer things a little bit in the other direction. [Chuckles]

So, I definitely see and I’ve heard other people speculate that in another few years most of the frontend stuff is actually going to be written in a transpiled language. It’s not going to be written in JavaScript itself.

Yeah.

Though ES6 does give you some nice features. And as it gets adopted things will be better, I think. But the thing that I’m really wondering about, and I’m going to go back to one of the points you made, and that is the code sharing between the frontend and the backend. How much can you do sharing frontend versus backend? And where does that fall down to start with? And then I’ve got another question after that.

Okay. Yeah, and as far as right now it’s pretty good. You can do, like I said most of your controllers and views, we do a thing called tasks which are basically a way to call backend-only code from the client. So, there are cases where you might have something like you don’t want to load, you’ve either got security issues or something where you don’t actually want to load the data on the frontend. So, you might have, it’s too big to process on the frontend. And so, we use tasks for that to basically, from the frontend you can call a method on a task class. And then it’ll return a promise to tell you when it’s done and give you back the results and things like that.

So I would say, the sharing code I think is important. And there are a lot of things that you’re duplicating. For me the biggest thing is just model business logic. But I think the other big benefit is you’re not learning a separate, you don’t need to be thinking in two frameworks at once, if that makes sense. And then the other big benefit is the automatic data synchronization. You can eliminate, I think I mentioned making all these REST APIs just for syncing data. And then it lets you have just a lot less code because everything’s all in one place, if that makes sense.

Yeah, that makes sense. So, if I’m writing a Volt app and I have, model logic is the example you keep bringing up. And I think it’s the most obvious one.

Mmhmm.

You have validations and you have certain ways that certain data is handled. And so, if you can handle it the same on the frontend and the backend and only change it in one place, then you get all the benefits of having DRY code. How do you write that? Is it just tasks? Or can you create a user class that actually has the validations and crap in it that does all the work, and then you just include it on your frontend and your backend?

Yeah actually, so tasks are only used when you don’t want something to be on the frontend. So typically, you would make, like I said you could do a user model. And then it’s similar to Rails. We have validates email and validates… and so those, they actually get checked when a model gets synced back to the server. They get checked on the client-side and then they also get checked on the server-side. So, you can be sure that it’s following that.

We also have permissions that are sort of still on the master branch. But it should be out hopefully this week. So there, you can say on create if this is owned by the current user then allow them to edit these fields. And those again, run on both sides. So, it knows who you are and it’s checking that you can write all this permissions logic. And we actually put that in the model as well.

That kind of raises a security question for me. You’re exposing your business logic through the JavaScript that gets loaded. Does that raise any issues?

That’s interesting. You know, I haven’t thought of it that way. I guess without it, you get the security through obscurity, right? [Chuckles] Yeah, so maybe you do lose a little bit of that. But I guess I would say it is checked on the server-side. So, aside from them being able to see some of who can do what, it’s sort of like if you mess it up then either way, they were able to get it. It just might not have been as obvious, if that makes sense. So, ideally I think actually I personally like having the permission logic in the model because then it’s very strict as to, you can’t make one controller where you accidentally forget to check some permission and then something gets through. It’s always there at the model level.

That makes sense, yeah.

Yeah. Well, and most people, they’re not going to go look at the JavaScript. And if it’s minified, then they’re not going to go and untangle it either.

Mmhmm.

So, you’re really only looking at people who are in it to try and make some trouble for you anyway.

Yeah. And I think either way you want to get that right.

Yeah.

You don’t want to be depending on obscurity to keep things safe.

Yeah. One other question I have is you mentioned that it all runs over WebSockets. And most modern browsers actually don’t suck at WebSockets now. But even a year or two ago some browsers really had problems with them. Is this something that you just tell people, “Look, you’ve got to have a modern browser”? Or do you use polyfills or what?

Yeah, we’re actually using SockJS at the moment, which is a JavaScript library that does WebSocket and then falls back to [all the], so they have JSONP and all the way back to polling. There are all these intermediate steps. We are actually switching how we’re doing that. But ideally we want to support back quite a few browsers. So, we’re always going to have a couple of fallbacks I think to make sure that works until 99% of people are running a browser with fallbacks.

Right now, Volt is targeting IE10 and above. But there’s basically one thing that you have to include to go back to IE8 and then everything works. The Opal guys actually, I don’t know why, they must have some project that they depend on. They actually target IE6 which is kind of crazy. [Chuckles] And all the way forward from there. Did that answer your question?

Mmhmm. Yeah, whenever I hear IE6 I’m always like [speaking in Gollum’s style], “We hates it”.

Yeah.

Yeah, somebody’s paying them to do that.

“My precious”.

Yeah, yeah, exactly.

Yeah.

Yeah, because they’ve got, I know they have some bigger projects on it. And they, yeah they’re on staff for somebody. And so, I think they need that as a requirement.

I noticed that you said your goal in building Volt was to enable one person to be able to build an entire app.

Yeah, and I guess I shouldn’t say that wasn’t a goal as much as that was my driving force behind it. Hopefully that is something you can do with Volt. But I don’t want to pitch it as it’s something for one person to use. We’ve tried to do a lot of things to make it really good for large teams to use as well. I’ve worked on both sides. So, right now I’m freelancing. But I’ve also worked in bigger teams and hopefully seen both sides of that.

Okay. So, that was more the inspiration than a goal.

Yeah.

And when you talk about eliminating the overhead of the REST APIs for syncing data, as an enterprise-y developer I hear increasing coupling.

Mmhmm.

There are benefits to that. You totally reduced overhead. You maintain uniformity. And yeah, you increase the size of what can fit in one person’s head. In the past I’ve observed that such things, the tradeoff is that you decrease potential for modularity, for hard boundaries that you can really define the API, which is those REST APIs.

Mmhmm.

That you don’t have to build. So, that brings me to the question that I’ve been itching to ask since the beginning of the call, which is what are the limitations? When should you not use Volt?

That’s a good question. So, I think just to address the first part of your question, right now you do get the model syncing for free. We’re working on an easy way to take those models and expose them as a REST API. And then for, if you’ve got some other third-party thing or something that you want to consume that.

And then the other thing, if you look at what Meteor’s done. They actually have a defined protocol that’s basically for real-time syncing of data APIs. And so, we may try to work that in or we may, depending on, I haven’t looked at it enough. But if it’s good we’ll probably just implement it. If it’s not we may try to do something similar.

But I guess to your question of when should you not use Volt? I would say right now if you need something really production-ready, we’re still definitely a work in progress. I think you’re right. For very large teams, that boundary I think is good. And I think there are projects where, especially once you get to a point where it’s so large that you’re going to have people who never see the frontend so they’re entirely focused on one little element of the backend. Then Volt at this point is probably not a good choice for that.

But I do think the thing too is that more and more apps are very heavy frontend. And I could be wrong in that. Or there are a lot of things where it makes sense to do it as a frontend, have frontend templates rendering things and handling certain things. And people aren’t doing that yet but it would make more sense like that. So, I think for any of those, Volt is a great choice. Does that [inaudible]…

Yeah, yeah. It also answers another question I had, which another of the disadvantages of shared code between the server and the client is that the server and the client have different limitations and priorities.

Mmhmm.

And when you couple those, you’re in a sense limiting both of them by the restrictions of the other.

So, I guess let me talk about one example and I can tell you how we handle that. So, one example is checking uniqueness. So, when a model saves and has a unique validation on it, you want to run that on the server, right? You can’t be sure that it’s going to pass on the client because of the lag, right? And so, the way we do that is our validations can actually, the whole validation and saving stack will return a promise. And so, it will test all of the validations that it can on the client.

So, if all you have are validates email, validates links, validates format, it’ll test all those on the client and then return immediately, because it knows when it goes to save it that it’s going to pass. However, if there’s one like a uniqueness validation which can only be tested on the server, that promise isn’t going to resolve right away. It’s actually going to wait until it hears back from the server that it did save. And so, you kind of get, I think in a lot of ways that gives you the benefits of both, the best of both worlds, because you’re able to get that instant feedback when it’s possible.

That’s cool.

So, it’s coupled by default but you can decouple it if you want to?

Yeah, yeah, in a lot of ways. And you can go in and say, “Here’s the logic I want to run,” when you’re running validations or something. And you can say, “Only run this. This one is serverspecific.”

Mmhmm.

And then it…

Yeah, I really love the idea of using promises for that, because you can basically then just count on getting your response when it’s ready.

Yeah. And honestly, there’s almost no other good way to do it. [Chuckles]

Which promises library are you using?

So, Opal actually has one built in.

Oh, okay.

Or that they include as a library.

I have a follow-on to Jessica’s question about the decoupling of things. It seems like Ruby web development seems to be moving into two separate families right now. There’s the backend farm out of SOA, service-oriented architecture. That’s the Montagues. [Chuckles]

And the in-browser JS app people are the Capulets.  And what I want to know is if we bring Volt and SOA together will it result in a tragically romantic double suicide? [Laughter]

Yes, I read a book once. Don’t act so surprised.

That’s a great question. So, we’re trying to do, if you’ve taken a look at the way we do components, I see a lot of apps where you build them and you think, “Okay, at some later point I’m going to pull this out and I’m going to stick it in a gem or something and then I’m going to reuse it.” And so, what we try to do with components is basically make that the default start workflow. Because I find when you go to pull something out later, you’ve already coupled it.

Yeah.

You may not realize what you’re doing, but you’re already coupling it. And so, Volt is really, we try to build things and try to have it help you build things in these components where they’re these isolated parts that can easily be nested together. And what you’re able to do with those components is really easily stick them into gems. So, I think Rail had engines, or has engines and I think they just didn’t quite take of the way everyone had hoped they would. I think there was a little bit too much complexity there. And maybe it was just easier not to do it, right? And so, we’re really making it with Volt where it’s harder not to do it is the goal.

And so, we’re able to do two, we haven’t done this yet but long-term we’d like to be able to take it where you can take those components and then run them as services as a separate app, right? So, since your component, if I have a blog on my page and this is just a simple example, but all of the things needed to run that blog except for the user are going to be within the blog component. And so, your models and your views and templates and things like that. And so, that’s a super simple example but having that where you could easily farm that out and run it as a separate service.

And then what I’d like to do is use something like some sort of distributed event bus so that you could easily tie in multiple services even in different languages or whatever real easily. Again, longterm probably ways off. So, I think components are the first step towards a service-oriented architecture. We haven’t done any of the work for that yet. But I think we’re laying the foundation for it.

Ryan, I am a strong proponent of test-driven development. How on earth do you test a Volt application?

So, we do two things. Around the server-side it’s pretty easy. On the client-side we actually, Opal supports RSpec. So, we just, our tests are on RSpec and we run RSpecs both against the MRI version and Opal. And then we also do some integration tests with Capybara to test, to make sure the browsers are actually doing what they’re supposed to. And some of that code is just a little easier to test as an integration test. So, it’s a mix of running things in Opal and then also running everything, doing some integration tests with Capybara.

One thing that I’m wondering here as you’ve been talking about Volt, you’ve said, “Well, we’d like to add this and we’d like to add this and we’d like to add this and we’d like to add this. Do you feel like Volt may at some point become a little bit too big or a little bit too complicated?

It’s kind of funny actually. I feel like part of it is you guys have just happened to bring up most of the things that we want to add. [Chuckles] Yeah, I think some of that will end up as third-party gems and things. I don’t think, especially compared to Rails, right now Volt is actually fairly simple relatively speaking. So, if you think of doing both a Rails, say a Rails and an Angular app or a Rails and an Ember app, which is sort of what Volt tries to give you is everything you would have in there, we’re much simpler.

I haven’t looked at the line of code count. But last time I looked, I think we’re less than 10,000 I want to say. So it’s not a huge codebase at this point. And we kind of, we’re trying to, it is a little bit batteries included. We do want to give people most of the things they need out of the box. But there definitely is that fine line of if you have too many things, then you’re just adding this complexity that nobody needs and isn’t benefitting anyone.

But I think too, the other thing is since we can push some of the complexity of DOM updating and syncing and all that into the framework, as an end user you’re not really, the actual surface area of the APIs is pretty small. And I think we as developers don’t want to maintain a massive app. But I think for the average user, the most important thing is the API surface area. Does that answer your question?

Mmhmm.

I’m curious about the persistence story. Does Volt have an opinion on that?

So, right now we’re just using Mongo. And the reason for that, I’ll give the little disclaimer asterisk [chuckles]. The reason for that is that in order to do some of the query stuff we basically need to have a query parser, a full query parser that can understand. We can look at a query and look at a document and answer whether or not that document matches that query. And so, for us Mongo was the easiest thing to get started with because their query language is really easy to parse.

The next step after that is actually, we’re working on a data persistence API where basically anyone can implement a couple of things and then you’ll be able to build your own adaptors. We’re doing things a little different from a lot of other frameworks. We’re not actually shooting for database agnosticism. But we’re shooting for supporting multiple databases. So, at least for me I feel like the complexity of having all the data stores have the same API is going to be pretty high. But if we do it this way, we’ll be able to really easily make it so, “I want Postgres,” or, “I want RethinkDB,” or something like that. And it’ll be pretty easy to add those. Whereas if we’re trying to abstract over all the details of all of those, it’s going to get a lot more complicated.

So, at least right now that’s the plan, is to do a data persistence API so that anyone can implement adaptors. And not just for data stores, even for things like I have a news feed that updates and I need to push it whenever new things come into it. So, we’re trying to create a real nice abstraction that you can implement to provide any data that you can query and store and update.

So, I just realized I had a paradigm shift just now. I was thinking of Volt as just this chunk of Ruby that you can manipulate and anywhere Ruby can go, it can go. If you point a web browser at it, it does magic. But this sounds like it’s a much more closed off maybe ecosystem. For example, I was about to ask you, so can I deploy this to Heroku? And now I realize that’s almost laughable, right?

No, actually you [inaudible].

You can? You can?

Somebody did it, got it working on Heroku, so yeah.

Wait, wait, wait, wait, wait. It has been done.

Yeah.

Not, you can, okay. There’s a big difference.

No, you can. It’s in the docs.

Oh, okay, okay. Okay.

Yeah.

So, the proof of concept has been done and somebody has documented this is how you actually do it.

Mmhmm, yeah.

But you would have to connect to a Mongo server somewhere.

Yeah, so you have to add…

Not to Postgres.

One of the Mongo extensions. And then everything else runs as a Rack app.

Okay.

You have to have Rack. At the moment it has to be thin because of the SockJS implementation.

But we’re making it so it’ll support any Rack server with the Rack hijack API.

That is awesome. And I guess of course you could just push it up to Heroku if you didn’t care about transportable persistence, right?

Yeah.

Can you use in-browser storage?

Yeah.

And it’s just like your personal app?

Yeah. The way we do it in Volt is you take all of your models and they have different ways to access them. And each way has a different persistence. So, you might say I want to load up my post model. But you’ll say store.posts and that will get the ones that are stored in the database. Or you might say LocalStore.post and it does a local store. Or you can even do parameters or cookies. And then basically the idea is that all these different places to persist have the same API. So, you can use them all through your model API.

Yeah.

And I think it’s hard to explain that really quickly. But if you go and watch my RubyConf talk I go into a little more detail on that.

Yeah. You can use the parameters as storage engine? So, I can just have a thousand-character URL as my database?

[Chuckles] You could. You wouldn’t want to. [Laughter]

Oh, I would want to.

[Compress] that puppy.

Yeah. [Chuckles]

I would want to. [Chuckles]

Yeah. Yeah, so if you never touch the store persistence, the store area, then it won’t even try to connect. It won’t even try to keep a connection open or anything. So, if you don’t want to use Mongo and you just want to use LocalStore or something, you can do that.

I love the idea of separating out models from persistence. That’s one of my biggest gripes with Active Record in Rails, is that your model by default is a persistence object.

Yeah.

And any business logic you add to it violates SRP.

Right, yeah, yeah. And the nice thing too, it’s funny because the thing I get all the time is people will run all the tests without the integration tests. And they’ll be like, “Your tests aren’t working.” I’m like, “No, they are working. They just run in a sec.” [Chuckles] And everyone’s like, “How is that possible?” I’m like, because we don’t touch, for most of them we don’t actually touch Mongo. [Chuckles]

Awesome.

Yeah, so it’s kind of funny. So that’s, I think one of the huge benefits too, is that we’ve abstracted persistence away from the models so that you can run all your tests with the in-memory store and the performance is great.

How do you pull that off? How do you pull off, you’re doing stuff where a change in one place can propagate to somewhere else but you’re shooting for an amount of separation it sounds like from the data store. Does that just imply that you’re only going to get that transparent instant update across multiple clients if they’re all talking to the same server?

So, yeah right now you have to be on one instance of it, which is not ideal obviously. What we want to do actually is include some sort of distributed event bus to run the syncing between everything. We could do something Meteor does, what’s called oplog tailing in Mongo. But that’s very implementation-specific. Ideally we’d want something where those changes can be propagated to all the listening clients. And so, we’re working on doing Faye integration. And Faye has where you can sort of, you can use Redis as the event bus.

And then longer term I’d like to do, on JVM there’s Vert.x. I don’t know if anyone’s seen that. And it is a mix of a web framework, it’s almost a mix of a web framework and an actor framework. And it has this nice persistent mostly fault-tolerant event bus that you can use. And it has SockJS connections to the client built-in. And so, with something like that, you can go and have the when the data saves it can say, “Okay, which outstanding queries are affected by this. And then of those, which models have changed? And what do we need to sync back?” And so, we’re doing that now but only on your current instance. So, you can’t, again it’s still a pretty early project. But at the moment, you’re limited to running once instance, I guess.

Okay. But I guess the flipside of that is that you’re not coupling it directly to some data store notification [inaudible].

Yeah, all of that will be abstracted away into the data provider API. So, the data provider API will basically have when things get changed you’ll be looking at queries and which queries were affected. And so, when things change the data provider API, it’ll call into the data provider API and be like, “Okay, tell me which queries need to change and what needs to be updated.” And so, some of that will get pushed into the data-provider-specific implementations.

It sounds a lot like Volt, on the scale that at one end is less magic, more work, and at the other end is more magic, less work. Volt is towards the more magic end of the scale. Does that ever worry you, just maintaining all the things under the covers?

You know, I think it sounds like it’s more code than it is. I actually think in a lot of ways, especially if you look at Rails there’s a lot of things in there to handle things like nested attributes for and strong parameters. And I think, so the analogy that I use is it’s like packing a suitcase where you keep cramming things in there. And it gets harder and harder to fit what you need. And so, I think what we’re trying to do is dump the suitcase out and start over. And in a lot of ways, we can get rid of things that other frameworks that have been around for a little longer have to maintain.

And so, for us because we’re starting from the point of using the same code on the client and the server, we don’t need a bunch of things that other frameworks need. Or we can push them out into third-party gems and things like that. And so, as a developer on Volt it’s actually really nice because we can, the overall complexity I think is fairly low actually compared to a lot of frameworks. Obviously not something as simple as Sinatra, but compared to the frontend frameworks too where I think our implementation’s pretty simple. And it sounds more complicated than it is. And maybe, I guess the thing that worries me most actually is just too much magic for the end user. I don’t want it to be like I don’t understand what’s going on here. And so, that I think we’ll have to watch for that, obviously.

Mmhmm.

But yeah, I’m not super worried about it as a developer. Like I said, the codebase is actually still pretty small. So, I think it just sounds, especially since it’s so different from how a lot of other frameworks do things, it sounds more complicated than it is. And once you dive in, you’ll see. Our current Mongo data provider API implementation’s a hundred lines of code or something. It’s not that big.

Mm. Nice.

At what point are you going to consider Volt 1.0?

You know, I had hoped we’d be there already. We’re definitely not. I think some of that depends on how much time I get. And we have quite a few other contributors who are ramping up now. So, it depends on how fast things go. There are a couple of things I’d like to get out and a couple of APIs I’d like to stabilize. I would like to get the data provider API out the door and then also get Faye integrated. The Faye integration’s pretty close.

Yeah, we’re at like 0.8.something right now. I think hopefully maybe the next three months or something, we’ll see where I think we’re kind of ready to call it 1.0. And I guess I would say some projects really wait forever for the 1.0. And I think for me it’s more just when we decide to stabilize the APIs. I think we’re going to keep adding features and changing around some internals and stuff. But the public-facing APIs, once they’re stable then I think we’ll call it 1.0 and put it out there.

What’s been your experience as the leader of the open source community around Volt?

It’s been great, actually. I think, I’d always kind of hoped that the project would get some people involved. But it’s actually been great. Actually, before it was even ready I had it up on a GitHub repo. And I was like, “Okay, well I’m not promoting this, so no one’s going to see it.” And Matz actually tweeted about it and we got tons of traffic from that. And I was like, “No, no, no. It’s not ready.” [Laughs] But you know, it was one of those. It was probably good actually, because we got some people in there early.

And we actually use Gitter a lot. If you’ve seen Gitter it’s like an IRC replacement that integrates into GitHub. So, we use that. And there’s always somebody on in the Gitter chatroom. And so, that’s been I think really helpful to be able to, as a developer, as a main contributor on a project, to be able to say, “Hey, what do you guys think of this?” and immediately get the feedback and make sure things are going in the right direction. So, it’s been really nice to have the larger community. And then recently we’ve been getting a lot of contributors. There are a couple of people who are doing one day a week on it and things like that. So, it’s been really great to have all that.

Is the project at all beginner-friendly?

Yeah, I think. So, it’s interesting actually. We have a surprising number of people who come into the Gitter chatroom and are like, “I’ve never done Ruby. I just built blank.” And so, none of those projects are super complex at this point. But I’d say at least to a certain extent it is. I think if you’ve never done web development it might be a little tricky. But in a lot of ways it’s actually almost more how people expect web development to work, if that makes sense.

So, there’s a lot of things in web development where if you were just thinking of it as, “Here’s my fat client,” you wouldn’t think, “Okay, every time something changes I’ve got to go and handle the event. And then I’ve got to go and sync that into a model and then push that over this specific API.” There’s extra complexity there that for a beginner at least we don’t have. And so, they can just more easily put something together, I think. But yeah, at the same time it’s an early open source project. So, I think our docs are pretty good. But there’s some holes in there where people would be, “”Hey, what’s this?” And I was like, “Oh yeah, that doesn’t make any sense.” [Chuckles] So, we’re always working on that, too.

Alright. We have any other questions about Volt?

I have a slightly obscure one. So, one of the things that Volt does is it gets rid of the whole REST client, REST server, da-da-da-da-da. Is there still REST under the hood? And if so, are you taking advantage of any of the other hypermedia extensions of REST?

Yeah, so it’s actually not REST under the hood.

Okay.

Like I said, we’re working on an easy way to make a REST, take your models and expose them as a standard REST API.

Mmhmm.

And hopefully that one’s actually pretty close to being done, too. But that would be more for a thirdparty consuming it or some other piece of JavaScript or something. Volt itself actually just uses, SockJS gives us a message-passing API. So, we can say, “Send this message to all the clients,” “Send this message to the server.” And so, we just use that under the hood.

I think I mentioned Meteor has, because part of the thing is with the live updating you’re not actually pushing all the data all the time, right? So, there’s the initial fetch. But then it’s from version blank to version blank, this data changed. And then it’s query-oriented. So, you’re actually making your queries on the client. And then those are getting sent to the server and it’s getting you back data. So, I think the benefit of that too is from the browser perspective it’s nice to be able to form a query without needing to create a specific endpoint for it, if that makes sense.

Yeah.

And then for things like pagination or something like that, it’s really neat because we can actually just, you can do reactive queries. So, you might say, “My query is load all the posts where limit to five pages.” And then the skip or the starting one can be bound to a parameter’s model of the current page. And then if the current page changes, it’s automatically going to update the query. And the query’s going to go fetch the new data. And then the list of posts on the page is going to update. And that’s great, because all you have to do is make a link to a new parameter value. And then everything automatically updates through that whole cycle. And if you’re interested in that, there’s a blog, a video on that that I had done.

Yeah, absolutely. I love the fact that Volt is one entire enclosed ecosystem. But I also start thinking about this in terms of, “Man, I want to be able to write a native iPhone app that can leverage some of this.” And I realize that’s not Volt’s primary purpose. Volt is basically saying, “We’re going to give up a lot of these general functionality things in order for one slick specific functionality.” But it does make me want to say, “Well, if I want to put a different client on this, how do I do this?”

Mmhmm, yeah.

And I realize that the whole point of Volt is, “No, we’re giving you a client. Stop trying to make other clients happen.”

Well, and I wouldn’t… actually I’m not I’d say that. I think my take on it is the web side of it should be really easy, right? And so, if you start with web and then you want mobile, then I think it makes sense to go ahead and build a REST API into it. Or, we may do, Meteor has I think they call it DDP which is their own protocol that they had made. And there are clients for it in Objective C and in all these other languages to do the sort of querying. And you want to be careful with the protocols because I think REST really took off because it was super easy to implement a client in, right? So, it’s a balancing act of, do we want to try and fit the live updating and the querying in there, or do we just want to stick with REST for third-party consumption?

Long-term goal actually, again this one is the definitely way too ambitious side of things [laughs]. But it would be really great if someone or possibly me or someone else was able to take your Ruby code in Volt and your models and controllers and then also do something like RubyMotion integration where you could still get the live syncing and then you’d be writing code to tie to the native UI widgets and things like that. That’s not something we’re really thinking about much right now but we’re keeping the door open for that as a possibility. But I think you’re right. I think shortterm we definitely need some sort of easy way to make a REST API or some other protocol to do the updating.

Yeah. And to be fair, this is self-serving of my own personal insanity which is that I’ve got a bug up my brain right now about HATEOAS which is beyond REST.

Mmhmm.

And you can’t have HATEOAS if you don’t have REST to begin with.

Right, yeah exactly. Yeah, so I will say we’re, of the three branches I’m working on right now one of them is the REST API branch. So, I may run that by you when we get there. Because I’ve seen a couple of talks on HATEOS.

I’d love to.

And I don’t know enough to actually make sure I’m doing it all correctly. [Laughs]

As near as I can tell, it’s REST plus action verbs. That’s all it is.

Okay.

It’s REST plus verbs.

Okay. I’ll read up on it again before I finish that branch up.

So, sort of in the same vein, I haven’t seen enough Volt code to know. Is it possible to have a semantic core to your application that is Volt-agnostic? Or does Volt dictate in terms of conventions or things that you include into your models or stuff like that, does Volt dictate a connection between your business models and the framework?

That’s a good question. It is pretty opinionated so your models are, you could go ahead and take your models and use them outside of Volt. You’d have to pull in quite a bit of stuff to do that. There’s a group of people who have legacy Rails apps for example. And they’re working on a project called 3rdrail which is their attempt to get Volt running inside of Rails. And so, they do have it where everything boots and then you actually, the way they’re doing it right now is that Volt loads up your Rails pages on the client-side.

And so, it’s definitely doable but I would say at this point that’s not really our focus. We are thinking of most of the apps at the moment are going to be full Volt apps and you’re going to be working with the Volt models because they give you persistence and the reactive updates and things like that. The most common question I get is, can you pull out the reactivity part and reuse it elsewhere? And so, I just haven’t done it yet. But that should be pretty easy to do.

Yeah, I guess it is difficult isn’t it to, if you are working with reactive stuff…

Yeah.

It’s difficult to completely separate that from the models.

Yeah, because basically the models need to be triggering those change events when they get changed.

Right.

And so, we have a thing you can include, a module you can include in any class and then trigger your own changes. Or you can make your class depend on something like we have a reactive hash and a reactive array that will automatically update, that will trigger those updates. But Volt does a couple more things where when you save an array into a model, it goes ahead and replaces with a reactor array. And so, nested all the way down it can keep track of all those changes. So, it’s one of those. You could use it outside of the Volt models but I don’t think it’d be worth it. I think you’re better off trying to make those as service wrappers or something like that, you know?

Right.

Service objects.

It seems like it’s a weak point in Ruby just across the board, is the idea of having business models that are able to notify you about things that happen to them, particularly in a recursive way. One of my fields which is a string had some data inserted in the middle. That kind of thing, there’s no standard for it in Ruby.

Yeah. And I think, you know there may be a few languages that deal with it a little better. But I would say it’s just a hard problem in general, as far as making sure that you’re… JavaScript is someday going to get the object observe, so we may be able to use that under the hood or something. But really, I think the way we’re doing it is pretty good. You save your data and then it gets wrapped up. And as far as from end user’s point of view, you’re just accessing it kind of the same way.

Actually, I think the advantage that Ruby has over a lot of languages is that Ruby has universal access principles. So, it’s actually great because people, you can’t just go in and fiddle with something outside of the getter and setter. And so, you see a lot of JavaScript frameworks where they have to use .get and .set to actually trigger so that updates to data is a method call. And so, it’s really nice in Ruby and Opal because we get that for free.

Yes, definitely. It’s interesting because that actually hits on a question that I didn’t get a chance to really get in earlier when it seemed more appropriate, which is just, is Ruby compelling enough to want to use it on top of another language, with the impedance matching that that implies?

Yeah, yeah that’s a great question. I think too the thing is until, I don’t know if anyone here has used Opal much, but there’s actually a shockingly low additional complexity. So, I would say the complexity of JavaScript’s [warts] greatly outweighs the complexity of Opal. So, Opal’s great. It’s got source maps for debugging. There’s a thing called framework black-boxing now in browsers. So, you can take Opal’s little runtime library and say that I actually don’t want that to show up in my stack traces or in my stepping debugging and things like that.

So, you can almost treat Opal as, it’s very close to feeling like a native language of the browser because of source maps and because of framework black-boxing and things like that. And so, the complexity is actually just considerably lower than I think you’d expect until you get into it. And then it’s actually, it’s really funny because a lot of people I talk to that are using Opal now, they’re like, “I keep expecting it not to work and it just works.” [Laughs] And so, it’s a little bit, I think we’re so used to dealing with JavaScript. And there are what I would consider some broken semantics in JavaScript. And so, you just expect that to work its way up into Opal.

But the great thing I think with transpiling is that that complexity gets amortized into the compiler.

And so, it’s really the compiler developer’s job to handle all of the intricacies of JavaScript. And so, as a developer on my end I just get to write Ruby. And I think Ruby has a lot of nice features that as an end user… it’s also great I’ll say too, to have a standard library. In JavaScript every framework, every library ships with another library to do even things like [inaudible] and map and reduce and things like that. So, it’s really great to have that standardized.

Are there any folks out there that I would have heard of that might be using Volt for anything?

Nothing too large right now. That’s actually one of the big things on my to-do list this year, is to get a really large demo app out the door. There are a couple of projects that are open source I need to put links to. So, one guy did a somewhat large project that was a remote control app for VLC. There’s some guy did a presentation syncing tool kind of thing, but nothing really large.

So, part of me wants to go ahead and take some time. And several of the contributors have expressed interest in this, and build a pretty large demo app so that people can go in and see these are the standard ways that we do things. And here’s what a good app looks like. And here’s where it’s going to save you time, and things like that. So, I guess to answer your question, not at the moment. But hopefully very soon.

Just one last question for you, Ryan. So, between Volt making it possible to write JavaScript in Ruby and ECMAScript 6 I think taking on most of the really cool features of CoffeeScript, is there any truth to the rumor I’m starting right now that

Volt is half of the one-two punch to destroy CoffeeScript?

I think Opal is. I think Opal is actually.

Yeah, okay. [Chuckles]

And I would say, I’ve been following the ECMAScript 6 stuff and it’s interesting because I was in a discussion with somebody the other day and they were like, “Oh, ECMA6 is getting all these things and JavaScript is changing all the time.” And I was like, “Yeah. They’re adding some things. But zero is still false and empty string is still false.” [Chuckles] There’s just all these things where sematic issues with the language that CoffeeScript doesn’t fix.

Right.

And ECMA6 isn’t going to fix.

IE6 doesn’t support ECMAScript 5 yet [forever].

Right, yeah, yeah. And those browsers, it’s going to be a long time before you can do nontranspiled ECMA6. A long time.

Yeah, yeah.

It might be literally a decade before that becomes a thing. So I think, and then at that point it’s like, well if you’re already transpiling, why not transpile some other language, the extra? Especially Ruby’s actually great because it’s close enough to do JavaScript that the debugging is super easy. But yeah, it fixes all the semantic problems for you. And then you get, like I said, a standard library and Enumerable and all these great things that you can use.

I’ll talk to you after the show about an idea I have for an Erlang transpiler. [Chuckles]

I think somebody’s working on one.

Nice. Alright, let’s go and do some picks. Jessica, do you want to start us off with picks?

Sure. The other day I got a cool new coffeemaker and it’s called the AeroPress, A-E-R-O press. And it makes about a double espresso at one time. And the best part is it practically cleans itself. The cleaning is so easy and that’s all I really care about. So, I recommend that. And the only negative is it uses an ounce of a coffee at a time. And if you’re buying Intelligentsia beans at $18 for 12 ounces, that works out to about $1.50 a cup. But hey, it’s cheaper than the coffee shop.

That’s my pick.

Alright.

AeroPresses are great. And they’re made by a frisbee company.

Yes.

Does that mean you can throw your AeroPress around?

Only if someone’s there to catch it.

You probably could, oh yeah, yeah. But I think that means they’re pretty fly. [Laughter]

So, anybody coming out this afternoon for a quick game of AeroPress golf? [Laughter]

Awesome. Alright, Avdi what are your picks?

So, I thought I would pick some newsletters today. I find myself with less and less time to read the tech fire hose these days. A while back I drastically cut back who I follow on Twitter because of that. And I’ve never habitually read Hacker News. I almost never read Proggit anymore. I like to keep up on what’s interesting but I found that the fire hose is not efficient.

So, lately I’ve been getting a lot of value out of some newsletters where somebody else curates the content. And a few of those are first off, there’s Ruby Weekly, which most people listening to this probably already know about. That’s Peter Cooper’s wonderful publication that sums up everything that’s, everything of note in the Ruby world in the past week. He’s got a bunch of other newsletters on other topics. But yeah, I get a lot of value out of the Ruby one particularly.

Another one is Hacker Newsletter. Like I said, I don’t read Hacker News because it’s a retched hive of scum and villainy. But I have to admit that it is a good attractor for interesting tech articles from time to time. and what Hacker Newsletter does is basically it’s a curated set of links where somebody goes through and finds some of the most interesting stories from Hacker News over the past week and puts them into an email and gives you direct links to the story. So, you don’t have to even look at the comments section. So, that’s been pretty nice.

Another newsletter I’ve been getting a lot of value out of is called Web Programming Notes from Mike Subelsky. And Mike is an old friend of mine and he started doing this newsletter a little while back. And it’s just a great weekly curated set of links about programming and beyond. It starts out with programing topics usually but then it goes out into more just humanity stuff, just really interesting reads. He’s a good curator. So, those three newsletters are a nice way to keep up on what’s interesting without being overwhelmed.

And then I will also pick a soap company today. Anywhere you live I’m sure you have a dozen wonderful local soap makers. And normally I would just advocate buying local and whoever is your go-to nearby farmer’s market soap maker. But there’s one in particular that’s close to me that I’ve been really, really impressed with. It’s called Paintbox Soapworks. It’s based in York, Pennsylvania. And she makes some really remarkable scents, stuff that I’ve never really come across from other soap makers. Very distinctive and kind of idiosyncratic scents. And she also has some terrific off the beaten path scents that are specifically oriented towards men, which is something that I don’t usually see a lot of from soap and scent makers.

So, I’ve been using her stuff for a while. She’s got, just as an example one of the scent varieties that I’ve liked is ‘dead leaves on the dry ground’. And it is actually reminiscent of that in a nice autumnal way. So yeah, I’ll put a link to that in the show notes. All her stuff is available on Etsy. So, you don’t have to be near me to get it.

Awesome. Coraline, what are your picks?

The first thing I wanted to point out is an excellent tutorial on IRC that is hosted on doubleunion.org. I’m seeing among a lot of people that I know a resurgence and interest in IRC. And there are some great communities forming around different interest areas there as well. So, what the Double Union tutorial does is it really gives you start to finish instructions, how to connect, what to do once you’re there. And it’s a really great, very beginner friendly introduction to this venerable technology that’s been around probably since the beginning of the internet almost.

And with that, once you have learned how to IRC, if you are new Ruby developer I would strongly recommend the channel on freenode called new2ruby. It’s ##new, the number 2 and ruby. And it’s intended to be a smaller, quieter place for new and aspiring Rubyists to connect with people who are more experienced and get one-on-one attention for getting  questions answered or getting pointed to resources to help them learn. It’s a really great, very small community that I recommend to anyone who’s new to the field.

Alright David, what are your picks?

Okay. So, before everybody turns off their audio device I have three picks. And I’ll prepare you for this as we go in. I have one pick that’s a joke that’s relevant to the episode. I have one pick that is freaking awesome. And my last pick is both. And the last one is the one that I warned you about in the intro.

So, my first pick is relevant to the show today. There was an April Fools’ joke back in 2008. And I want to say that pragdave, Dave Thomas was one of the people that were involved with it but I haven’t been able to confirm that. And I apologize. There were two people that did it. And I

apologize. I can’t remember who the other person was. And I might be wrong about pragdave, so I might be wrong about both. So, I apologize for misremembering it. All I remember is that it was freaking hilarious.

In the aftermath of all the hype about Ruby on Rails and build a blog in 15 minutes, they released an April Fools’ joke of a new technology called COBOL ON COGS. And you can get to that website at CobolOnCogs.org. It looks like a COBOL program. It looks, you have to see the website. It is this beautiful ultra-retro. They somehow even managed to program the text to flicker like you’ve got a bad varistor somewhere in the back of the electron gun in your ancient CRT monitor. So, absolutely fun and kind of a fun April Fools’ joke.

My second pick is the most amazing piece of technology I have seen in oh gosh, months, if not all of this year and probably the last. It’s called Duet Display. And what it is, is you can use your iPad as a second monitor. You flip open your laptop, you plug in your iPad, stand it up on the stand. You turn on the Duet Display on your MacBook. And then you go over to your iPad and start the Duet Display app. It’s not free. It’s like $15 I think. It’s not cheap. It’s definitely not a $2 app. But it gives you a freaking second monitor out of your iPad. And I am using a high-end MacBook Pro that has plenty of video RAM.

So, I am using the HDMI port to drive a 1080p monitor. I’m using a Thunderbolt video port to HDMI

to drive a second HDMI monitor. I have a laptop open. So, I’m using the laptop monitor. And I have the Duet Display plugged in. I literally have four monitors going at once. It is awesome. I’ve never felt like better about myself as a real-estate baron when it comes to video real-estate. So, Duet Display. They’re @DuetDisplay on Twitter and DuetDisplay.com is where they’re at.

And my third pick, I’ve been thinking about this through the whole episode. And in deference to the fact that we want to keep this show PG rather than PG-13, I’m going to clean this up a whole lot. So, what I’m going to say is my third pick is freaking amazing. There is a product. It is real and it really works. It’s called Poo-Pourri. And what this is, is a scent that you when you go into the bathroom to do number two, you lift up the seat and you spray it on the water. And then you have a seat and you do your business. And the scent keeps the odor from coming back up. And Avdi’s asking me in the backchannel if I’ve picked this before. And the answer is yes I have, because I think I’ve picked the commercials for it because they are freaking hilarious.

Heavy Doody and Poo-Tonium. And doody of course is spelled D-O-O-D-Y. Original scent smells like lemongrass. Heavy Doody smells like sandalwood. And Poo-Tonium smells like fir trees. And I am allergic to fir oil. And so, there’s a really hilarious rant in my Twitter feed about the parts of my body that swelled up and got hive-y when I sat over that.

CHUCK: Geez.

So, it’s a scent that literally tried to kill me. We had to open the windows in the middle of January, open all the windows in the house and air the house out overnight to get all of the fir oil out of the house so that I would stop swelling up and having bronchitis and being sick. They have a no-stink guarantee. I am way, I am very ashamed of how proud I am of the fact that yes, I have defeated Poo-Pourri. All I’m going to say is if you do enough and it stinks bad enough, you can defeat it. But you really have to work at it. And I really was deliberately working at it. And that’s all I’m going to say about that.

Next time, can we have our guest do picks before David? [Laughter]

Before the guest just goes, “My god, why am I here?” [Laughter]

So, that’s all I’m’ going to say about that, which is far, far, far too much. The product actually works. The product is freaking amazing. The lemongrass scent absolutely smells heavenly. And I can’t recommend it highly enough. I think you should get a bottle. And those are my picks.

Make it stop. [Chuckles]

Alrighty. I have a pick really quickly. That is the blogging course by John Sonmez. John is a friend

of mine. But he was also on the show a few weeks ago and we got a lot of good feedback about that show. So, if you’re looking at doing better at marketing yourself as a software developer, he has a course on that. But the blogging course is actually free. And it’s an email course. So, you’ll just get an email every day for a few days, basically walking you through the steps of starting up a blog that can help get you a little bit better known. So, I’m just going to pick that really quick.

Ryan, what are your picks?

Yeah, so I had mentioned Gitter before. And I thought that would actually be a pretty good pick. I know Coraline mentioned IRC. Gitter is kind of I would say is very similar to how people use IRC. But it’s web-based, or there’s apps that are pretty good. And then it gives you chatrooms based on your GitHub projects. So, it’s really nice for teams. It actually, for me at least it meets the needs of something like a HipChat or something like that. You can put code in there and you get code highlighting. AND then you can see on the side all of the stuff going on in your GitHub repo. So, for I think I’m only using it for open source projects right now. But I think any time you’ve got a team and you’re using, you need a team chat, it’s seems like a great product. It’s free for open source projects.

And then the one other thing I want to do as a pick is actually, I’m actually going to give a shout-out to Bozeman, Montana where I’m from. It’s a pretty great town. If you’re looking for somewhere that’s a little quieter but still has a good tech scene and has, a little cheaper to live than somewhere like San Francisco, Bozeman’s great. It was 55 here yesterday. So, [chuckles] I just thought I’d do that as a pick.

And then last thing, I mentioned Vert.x. And Vert.x, if you haven’t seen it, it’s actually I think written in Java. But it runs on the JVM and there’s a thing called Jubilee which lets you use it as a Rack server. And so, Vert.x has a lot of really neat things built in. We’re hoping to do some integration with Volt. But right now, if you haven’t seen it I think it’s got a lot of potential and maybe an up and coming technology in the future.

So, those are my three picks.

Alright. Well, I think that’s all we got. So, thank you for coming. And hopefully some folks can go out and try out Volt. If they want to get a hold of you, what are the best ways to do that?

I’m always in the Gitter chatroom. So, if you go to VoltFramework.com, there’s a link to it on the community page. That’s probably the best way. And thanks so much for having me on the show, everybody.

Yeah, thank you.

Yeah, I appreciate it.

Yeah.

Thank you. You’re welcome.