02:00 -  Introduction

02:23 - Clearwater

03:51 - How an App is Typically Structured

05:39 - Persistence and Wiring Up to the Backend

06:49 - Why Clearwater Was Created

08:26 - How does it compare to prevalent JavaScript frameworks?

11:23 - What problem is Clearwater aiming to solve?

14:30 - Debugging

16:39 - Use Cases

20:33 - The Future of Clearwater

21:59 - Maintaining Clearwater

24:39 - What is success?

25:23 - Using Clearwater with a System Like Volt

Picks

Contributor Covenant (Coraline)
Kaleidoscope (Coraline)
LEGO Ideas - Lovelace & Babbage (Coraline)
Freelance Remote Conf (Chuck)
Ruby Remote Conf (Chuck)
RushMyPassport (Chuck)
Primula Cold Brew Glass Carafe Iced Coffee Maker (Jamie)
JRuby (Jamie)

Special Guest: Jamie Gaskins.

 
[This episode is sponsored by Hired.com. Every week on hired they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on Ruby developers providing them with salary and equity upfront. The average Ruby developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with a company or deny them without any continuing obligations. It's totally free for users. And when you're hired, they give you a $2,000 signing bonus as a thank you for using them. But if you use the Ruby Rogues link, you'll get a $4,000 instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept the job. Go sign up at Hired.com/RubyRogues.]

Hey everybody and welcome to episode 246 of the Ruby Rogues Podcast. This week on our panel we have Coraline Ada Ehmke.

Coming to you as a non-smoker for the first time in 20 years. Awesome.

Woohoo!

Nice.

I'm Charles Max Wood from DevChat.tv and this week we have a special guest, Jamie Gaskins.

Hello from Baltimore.

Now Jamie, it's been what, a few months since we talked about Clearwater on readthesource?

Yes. I think that was back in October.

Do you want to introduce it for the people who aren't familiar and introduce yourself as well?

Oh, absolutely. So, my name is Jamie Gaskins. I am a software developer at OrderUp which is a part of Groupon here in Baltimore. And we develop a food delivery service. So, Clearwater is a frontend Ruby framework. And when I tell people about that, they usually go, “What? Ruby on the frontend?” And really, what happens is that your Ruby code gets compiled into JavaScript. And what Clearwater does is provides some sort of structure to allow you to hook into the browser rendering using a virtual DOM. And it kind of gives you a small DSL to use, similar to React's components, but in Ruby.

So under the hood, you're using Opal for the JavaScript transpilation?

Yes. It uses Opal, any of the latest versions.

Cool. So, what exactly are you adding on top of Opal to make the magic happen?

It provides a component mixin that you can pull into your components, that makes these objects that you create, turns those into renderable components. It also has routing built in. So, you can take the URL path and use that URL path as a navigation path through this routing tree that you specify. And that sort of thing works kind of similarly to the Rails router or if you've ever used Roda.

Right. We had a discussion about Roda on the show before.

Yes, yes. I remember. Fantastic, fantastic framework. It also provides an application wrapper to wrap up the components and the router into a structure to work together.

So, you've kind of given us some hints with the router and the component. Can you walk us through how a typical app is actually structured?

Sure. So, you can go with anything from a minimal app which doesn't have any routing so you can just leave off the router, and all you have is just the application which has a reference to one of your components. And when you call app.render, it's just going to render that particular component into the DOM based on any of its current state.

It sounds a little bit like React.

It is. A lot of the concepts are very, very similar. It uses a virtual DOM. And because it uses a virtual DOM your entire UI is declarative based on its current state. At any point you can just call app.render and what you see on the screen will be what you wrote in your app, based on the URL and the current application state.

A lot of JavaScript frameworks are sort of pulling at the idea of MVC in exactly how they're modeled on the frontend. There are some variations there. How would you describe the Clearwater breakdown in those terms?

I don't know if it really follows any of those patterns. It started out as an MVC framework. But once I started playing around with several of these different frameworks that use components like Ember and React, I realized that what I was actually doing was taking those… I was actually using views as components.

Right.

So, I ended up removing the whole view and controller from it and just went all-in with components. Because it ends up… that's how I view the UI structure, is this particular list is its own thing. For each element in that list, each one of those is a component sort of thing, kind of break the structure down into smaller and smaller bits as you go through.

Right, that makes sense. How does wiring up to like a backend Rails application work in terms of persistence?

There's no real structure for that yet. I wrote a gem called GrandCentral to kind of go with it. And what that does is it works similarly to Redux for state management. But it has a few extra niceties for things like using promises so that you can post some data to your data or fetch some data from your server and it'll use these actions or events or however you want to call it, GrandCentral calls it actions, to adjust your application state. And you can kind of feed some state in there for when you are fetching to say, “Hey, we're loading this data.” When it comes back you flip that bit back and then say, “This is the data that we got from the server,” and then inject that into your application state. So, it's not like Backbone or Active Record or any of those things to communicate with another server for the canonical state. It's just like at the moment, we're just kind of using simple Ajax requests and promises.

Got it.

So, assuming there aren't enough frameworks for the frontend out there in the world…

Why create another one?

This originally started when I first found out about Opal. And I was like, “Awesome. I can use… I can write Ruby code that runs, that gets executed in my browser.” And I wanted to create something for it. Because at the time there really wasn't a whole lot for it. The ecosystem was really dry. So, I sat down one day, started playing around with an idea for an app. And my wife and I worked on it for a little while. And I realized, I was like, “I can do this in Ruby.” And I had some ideas for how to do it. And it was really interesting being able to inject things into the DOM. I

actually learned a lot about how the DOM works by building this. It's pretty interesting.

So, it started out as a hobby project?

Yes, it did. Yeah, so it started out as a proof of concept. I wanted to see if I could make something in… to be able to write Ruby on the frontend with Opal to run a full application. Because there wasn't anything out there. And this proof of concept just started getting better and better. And eventually it got to the point where I'm like, “This could be a real thing.” So, I mentioned it at the local meetup, did a presentation about it and I showed people. And some people really liked it. Some people saw Ruby in the browser and thought, “This is such an abomination.” And these are probably also the same people that don't like CoffeeScript.

Yeah.

And that's fine. If you don't like it, you don't like it. But I think it's really amazing. I think it's really great that it not only works but it works really well.

So, that spawns a few questions for me. We'll stick to the technical aspect for just a minute.

Right.

You said it works really well. How does it compare to the prevalent JavaScript frameworks of the day?

Well, as far as Ember goes, I haven't used Ember for a while but I've heard it's getting really good, but I did check and check against the size of a couple of different applications. Like a pretty typical TodoMVC app versus something that's even a little bit larger, that has a bit more [inaudible]. And it turned out it was actually, it was a smaller payload than the equivalent Ember app. But that…

Payload meaning?

So, minified and gzipped JavaScript payload.

Gotcha.

So, it was a bit quicker to transfer over the wire. But that was a while…

Which is a big deal for mobile, by the way.

Oh, totally. Absolutely. Not only that, but also a smaller payload is not only fetched faster over a mobile connection but it's also mobile processors are significantly slower.

Mmhmm.

So, a large JavaScript payload takes longer to parse and execute. I've also benchmarked it against React, because React, everybody's like, “Oh, it's the fastest thing now.”

Super popular, too.

Very, very popular. And absolutely, React is, it is very fast. It's fast enough to do just about anything you need it to do. But Clearwater is faster, which was really fun to notice. It's really just a matter of the virtual DOM that lies underneath it is just faster than React's. Everything else is pretty much the same.

Can I ask really quickly? Because it seems like I know some people are going to come in and they're basically going to say, “Okay, well if Clearwater is faster than React then how does it stack up with features?” and things like that…

That may have other concerns in that virtual DOM that may slow it down.

Right. That is actually… when I first found out there were lots of other different virtual DOM implementations other than the one that Clearwater uses, I started looking at them and I'm thinking, “Maybe I could make it even faster.” But the problem is they don't have the same features that the virtual DOM library uses, that Clearwater uses. So, things like being able to access rendered DOM nodes. That's something that is important. So like, if you need to render a Google Map or something like Highcharts or something like Charts.js, some other thing that requires [you] to pass in [a rendered] DOM node. That's not something that you [can] do in some of these faster virtual DOM implementations. But you can do it with Clearwater. I actually just merged that functionality in last week.

Building on top of that actually, I just want to mention that that work there, merging that in, was part of our road map to 1.0. I'm trying to build up enough features to release a 1.0 beta. Well, I did just release a 1.0 beta last weekend. But also, working towards 1.0 to make it… to show that it's production-ready.

So, I'm still not clear on what problem you're trying to solve with Clearwater. Is it just to write cool stuff in Ruby on the frontend? Or is there more to it than that?

That's… okay, so that's kind of how it started. It's kind of how it started out, was being able to write in Ruby. It doesn't really solve any problems that aren't already solved by something like React or Ember. I honestly don't know about Angular. I'm sure Angular solves the same problems. I think a lot of them do solve the same problems. It does have routing built in, which React doesn't. Which is a little interesting. It's probably more along the lines of something that Rubyists are more likely to use. Like a lot of people use Rails, specifically because it comes with the batteries included. Everything that you need is all in one package. And Clearwater's not all in one. For example the state management like I mentioned earlier is kind of broken out into its own gem right now. But the fact that routing comes built in is a big thing for me. Like I don't have to try and piece together all these things that aren't really built to work together.

Other problems are just that when I first started using React and Ember as a matter of fact, I wasn't really sure how… like when I rendered something into the DOM with a React component, the next time it renders is it the same component instance? Or is it rendering a new instance of that object? I don't actually know. And so, with Clearwater what you actually do is you just, as the content of your DOM nodes you actually just pass in a component instance. Like myComponent.new, foo.new, bar.new. All it has to do is respond to render. If that component responds to render and returns virtual DOM nodes then you have…

A legal component essentially.

Yeah. It's going to call render. It's going to take that virtual DOM node that it returns, and it's going to render it in place of where you put that object.

Now I have to ask. When you say it has to return a virtual DOM node, usually when I see this, and I've actually seen it in React as well, you either wind up essentially writing a view in JSX or you have inline HTML of some kind. So, when you talk about actually returning a DOM node is it an object or is it a string or is it something else?

Good question. So, the way you construct virtual DOM nodes with Clearwater is you include this Clearwater component mixin. That's the easiest way to do it. It's not necessary but it is the easiest way. So, that gives you methods like div, span, the p tag, all those HTML tag names are methods. And you pass in, you say like 'div' and then your attributes like ID foo, and then your content is an array of child content, child nodes basically. And so, that kind of mirrors what HTML tags look like where it has the tag name, key/value pairs as attributes, but in Clearwater it's just a hash, and then an array of other nodes. So, if you have a div that has a span and a p tag and whatever else, then you put that inside of an array in there.

So, whenever I hear about transpilers the first thing that my brain goes to is, how impossible is this going to be to debug?

So, what's the debugging story?

Debugging is actually pretty good. For the most part, if you're using something like Rails or anything that uses Sprockets, it's going to pop up an error on compilation. Like during your Sprockets pipeline, the asset pipeline in Rails. It's going to pop up an error saying, “This is a syntax error.” Once you fix it, if you have some sort of exception raised inside your Ruby code, what that does is it's going to pop up as the… inside your JavaScript console and show you that the Ruby exception that it has. And then inside that stack trace it's going to show Ruby files. Because when Opal compiles your code, it gives source maps. It also provides source maps with it. And if your browser supports source maps which any browser made in the past three years or so has some level of source maps support, then you're not going to see JavaScript files. You're going to see Ruby file locations. If you do want to see the compiled code that's also possible. It's not terrible actually, to look at. But it is a whole lot easier to find where the bug is if you're looking at the Ruby code.

Right. That sounds right.

Yeah, and I have to say that you know, it's a similar story for other transpiled languages like Dart or CoffeeScript or TypeScript which is one that I've been playing with lately. Yeah, a lot of times they spit out JavaScript where you can kind of see the parallel well enough to actually figure out, “Okay, this is over here in this class,” blah, blah, blah, and go fix it. And with source maps if for some reason it does something a little bit tricky or a little bit fancy, then yeah the source map takes you right back in, in your development tools, into the original code.

Exactly. So, just like with CoffeeScript you might have to go in and sometimes debug the compiled JavaScript. I haven't messed with TypeScript at all. But I've heard great things about it.

So, one other thing that I'm wondering about, and this is just me kind of spitballing a little bit, but are there things actually out there written in Clearwater that people could go and look at or play with or actual production apps that people can go, “Oh, look. See, that's written in frontend Ruby.”

Not yet. So, we're using it at OrderUp on a couple of things as like a test bed. So, we can see what it's like. So, the other people that I work with can see what it's like and get a feel for what the code is like and all this stuff. But right now the only things I've got that are public are a TodoMVC application.

Well, a TodoMVC is at least something, right?

It is.

Because people can look at it and see how it goes together and then decide if that's something they want to do in their code.

Right.

I do have to say though, that I am usually suspect of frameworks and libraries that don't actually have some production use out there.

Right. That's totally understandable. And that's one reason I'm trying to get one of our frontend tools at work, something consumer-facing, ported over to Clearwater so that we can kind of have something to show off. Because I don't have any personal, anything personal that's really big enough, complex enough to show off. But a lot of our apps at work are very complex. And porting some of those things over to Clearwater has been, has actually guided a bit of the design of Clearwater itself.

Yeah, that's actually pretty common and that's why I'd like to see it kind of come out of that place where it's, yeah where it's basically been used in production. Because then the use cases built into it, it's, “Hey, we had this problem to solve and we used this tool to solve it.”

Right. One of our more complex apps is, I've got a proof of concept of it using one of the more performance-intensive tasks. And the current app is written in, it was originally a Backbone app but we started porting it over to React.

CHUCK: Uhuh.

And we never actually finished it. So, some of it's still Backbone. But we're having a bit of a… it's starting to get to that point where our volume is making it so that we need more performance out of this app. And so, when I ported it over to Clearwater it rendered at 60 frames per second. And…

Oh, nice.

Yes. It was absolutely great. So, because it does things like… actually this is another really nice thing. So, multiple render calls. If you change your app state you just call app.render. And if you call it multiple times, it'll coalesce multiple render calls into a single render using request Animation Frame and it throttles it down to once per animation frame. So, that's actually a problem that we had, was that some of these Backbone calls are not asynchronous. They're triggering synchronous renders. And that's something that the React components in there help out with a little bit. But still too much of it is Backbone and it's causing performance issues. But on Clearwater it doesn't.

So, what sorts of apps do you envision people building with this? Is it anything that you could build with regular JavaScript? Or are there specific use cases that you've kind of been targeting?

I've actually been trying to make it as generic as possible. So, everything from the smallest, simplest TodoMVC sort of thing, all the way up to some of the more complex stuff that does include routing and requires some more complex state management, which is why the GrandCentral gem came out of that.

So, I think it's really interesting that we're talking to you now, Jamie. I think the conversation we're having now would be very different from a conversation we'd have in like a year. And I'm really interested in the life-cycle of open source projects. And I think that we're catching you pretty early. Clearwater is not yet 1.0 and you have a couple thousand downloads on RubyGems. What do you see the future of this particular open source project looking like? And what are you doing to prepare for it?

That's a fantastic question. I'm not sure I have a complete answer yet. But I'm mostly just kind of handling things as they come up. I've put in a lot of effort to make Clearwater as generally useful as I can. I would like to see more people using it and contributing feedback. I've gotten quite a bit of feedback. People are using it in… somebody is embedding it in an Electron app, which is a use case I hadn't anticipated. But I did work with them to make that a little easier for them. And…

You're probably at a pretty unique place where you can afford to give one-on-one attention to individual users…

Oh.

CORALINE: at this point in time.

Absolutely.

That's a luxury, for sure.

[Chuckles] That's definitely the best part about having an early stage project, is that there's not so many people that it's overwhelming to talk to each individual.

About how much of your time in a given week are you spending on Clearwater, would you say?

Between the code itself, trying to write up documentation for it, also been trying to put together some screencasts, probably close to 20 hours a week at home.

I think that's an important thing to know for other perspective open source developers, is the kind of commitment that you need to make to it to make a project successful. I get asked all the time. I do. I've got 25 Ruby gems and I get asked all the time like, “Well, how much time do you spend on them?” And it's like, “Well, it depends.” And I don't really feel like I can advise someone who is really excited about a new project and is kind of worried about what is the time commitment going to be like? I'm always interested to hear what other open source developers' experiences are with that.

It's definitely interesting. I remember thinking, “Oh yeah, I'll just open source this and I'll get all this help.”

And it turns out that's not actually what happens a lot of the time. You still end up having to do most of it yourself, which was a little surprising, a little disappointing. But it also makes it a lot of fun later when you look back on it and you say, “Yeah, this is actually really good and really fun to use. And I made it myself.”

Yeah, it's a good sense of accomplishment from it. Do you anticipate getting to the size where you're going to have a team of core maintainers?

I think that would be a lot of fun. I'm not a hundred percent sure that's going to be necessary. One of the reasons that React and Ember have such large contributor bases is that they need… they're implementing all the stuff themselves. Like React implements its own virtual DOM. It implements, they hired the developer of Babel. It's pretty much everything is their own. Whereas Clearwater uses the virtual DOM library which actually provides… it's another open source library that provides a lot of the underlying functionality. So really, it's just kind of a… I wouldn't say it's a thin Ruby layer. I think the component DSL is a thin Ruby layer on top of that. But I don't think there's a whole lot more that… there's not a whole lot more to it than that. I guess it's not… like the majority of it is the interface between your Ruby code and the DOM.

Right.

So, if you go to the project page on GitHub it actually shows that two-thirds of the project is the vendored version of the virtual DOM library that we're using.

Right. So, what does success in this project look like to you?

Success would just be, I would like to get people more comfortable with using Ruby on the frontend and not be so worried about transpilers. But also, I would like to see people writing simpler code using things like Clearwater. And these components are very… intended to be very simple. And I don't think every framework really kind of tries to optimize the [sensible] thing. They're trying to optimize the easier thing a lot of times, easier on the developer in the beginning. But there's nothing that says, “Just write this Ruby object,” or, “Just write this JavaScript object.” And that's what you get.

So, I'm trying to remember the name of the full-stack Ruby platform that's out there, that's Ruby on the frontend and the backend.

Oh. Volt.

Volt, that's it.

Yes.

So, do you foresee Clearwater being used with a system like Volt? Where maybe it gets packaged up with some tweaked around version of Sinatra or something, or something that works similarly to Clearwater on the backend?

I think it's totally possible. Because I've actually got a pull request open for server rendering. And being able to integrate with the server to render something on the server but also even share code between the two, like not just specifically for rendering but being able to do things like RPC, Remote Procedure Call, some kind of things to make it easier to do like Coraline mentioned earlier persist stuff to the server and fetch it back. I think that would be a good integration.

Yeah, the idea of universal or isomorphic, I don't know who makes up these names…

JavaScript is gaining in popularity. And it definitely with some performance increases that are interesting. And so, yeah.

Indeed.

I really like the idea.

A lot of these things are probably things I haven't even thought of yet. There's a lot going on in the Node.js community around server-rendering a React app or an Ember app.

Mmhmm.

But I'm not even sure yet what the possibilities are with Ruby. Because this is all still pretty new. We're kind of like still feeling some of this stuff out, like getting some inspiration from the Node community on how they're doing this stuff. But at the same time, it's a little different because we don't have… like the browser doesn't run Ruby natively. So, there are limitations.

Yeah, I am also wondering since it kind of came up was, in what ways does Clearwater take advantage of the JavaScript world? And in what ways does it take advantage of the Ruby world?

Since it kind of lives in both.

So, if you need something that's provided in JavaScript you kind of have to wrap it yourself, unless there's a gem out there that already does it. So for example, for some of our work at OrderUp we use WebSockets, specifically pusher. We use Google Maps. And I've already released an Opal pusher gem to kind of give you access to things that are coming back from pusher. So, pusher updates for live updates of your current app state from the server. Google Maps, that hasn't been extracted yet. But it's something that I'm looking into. As far as other things, having to wrap everything that you use that's in JavaScript, it's a little frustrating in the beginning. But once more things are out there, there are Ruby bindings for these things, then I think that will go a whole lot smoother. But yeah, like I mentioned earlier it's still pretty early in the whole Ruby on the frontend sort of thing.

Well, I don't think I have any other questions. Do you, Coraline?

I think I'm good.

Alright. Well then, let's go ahead and get to the picks. Coraline, do you have some picks for us?

I do. I have three picks today. The first one is Contributor Covenant version 1.4. By the time this episode goes live, Contributor Covenant version 1.4 should be live as well.

Nice.

And Contributor Covenant has been adopted by about 14,000 projects. There are some big names which you can find on the ContributorCovenant.org website. The important thing about version 1.4 is there's a lot of controversy about a provision that was introduced governing behavior of participants outside of official project spaces. So, I've added some language to clarify that scope in the new version. Some people also thought that it was very prescriptive and didn't provide any positive examples. So, I have added examples of positive behaviors that should be encouraged in a welcoming and inclusive community. And basically looked at a lot of the other thoughtful and constructive criticism around Contributor Covenant and Codes of Conduct in general and tried to address those in a new version. So, it's greatly revised, greatly cleaned up. Translations should be starting up by the time this goes live. So, if you've looked at it in the past and had issues or you've used it in the past you should take a look and see what's different.

My second pick is a tool called Kaleidoscope. I may have talked about it before. It's a really powerful OS X diff tool. It works on text source code, images, and folders. It makes it super simple to review and merge changes. It has different views so you can look at things in a fluid layout or a block layout, move things left and right between versions. Beautiful and intuitive UI. Image diffs are pretty cool. You can have a two-up mode or one-up mode or split or an overlay. It integrates with Git. I have it set up as my Git diff tool. It is a little bit pricey but I find it really worthwhile. I love looking… I love using Kaleidoscope and it makes reading diffs so much easier than the built-in command line tools.

My final pick is something kind of fun. I grew up with Lego. I know a lot of people grew up with Lego. And I still have a good collection of Lego now. There is a process for suggesting new Lego sets. And someone has come up with this great idea for an Ada Lovelace, Charles Babbage Lego set. So, as we all know Ada Lovelace was the first computer programmer. And Charles Babbage designed a mechanical computer called the Difference Engine. So, this Lego set celebrates their accomplishments. And it's also a fitting tribute Ada Lovelace in her bicentenary. It's a monochromatic brick palette which evokes a Victorian atmosphere. And the engine itself is decorated with cogs, chains, and pistons which give it sort of a steam punk aesthetic. The coolest thing about this Lego set proposal is that the Difference Engine model itself, has the capacity to house a Raspberry Pi which is just amazing. So, not only will kids get excited about the history of computing but they can actually build a case for their computer out of Lego, which is just awesome. The way the process works is that a proposed Lego set needs 10,000 votes. And they have to get these votes in a certain amount of time. So, the Ada Lovelace needs 2500 more votes to be approved. So, I will provide a link in the show notes. Please go and vote for it. I think it's an awesome thing. And it would be great for kids everywhere.

And that is it.

Awesome. I've got a couple of things I'm going to throw out there. The first one is I am doing a couple of conferences that are interesting to this audience in particular this month and the next month. The first one is Freelance Remote Conf. You can get tickets at FreelanceRemoteConf.com. Ruby Remote Conf is next month. So, go check that out as well. The Call for Proposals is still open. And I am definitely interested in hearing all of your speak. So, please do that.

Secondly, I'm going to be in Amsterdam. I'm probably going to do a meetup on the 17th of February. This will probably come out right before then. So, if you are in Europe and Amsterdam is within reach, then feel free to come out. I don't have the details up yet. I will probably email the mailing list for the shows, which means if you go to RubyRogues.com and you sign up for the emails every week that tell you that a new episode's come out, you get an email with the picks and the show notes in it, I'll probably send an email around to everybody who is on that list. And that way, if folks are there then they can come. I'm going to be there for the NG-NL conference which is an Angular conference. So, if you're going to that then definitely look for me.

And then I don't want to be completely self-serving but… so, one of the things that I had to do yesterday was actually get my passport. I had a passport. I couldn't find it. So, I had to get a new one and I had to get it rushed. There's a company out there, RushMyPassport.com. They've been working out pretty well for me. So, I just followed all their instructions. If you expedite a passport through the State Department, it takes three to five weeks. And at this point it is three and a half weeks before the conference. So, that wouldn't exactly work for me.

Apparently the way that it works is that travel agencies can push through rush orders for passports. And so, the travel agency has essentially set up some kind of deal where they use their… they get a certain number of passports they can push through every so often. And so, any of them that they're not using I guess for their own clients they make those available to other people. So anyway, so I sent all the stuff yesterday and I should get it on Monday. So, it'll take about a week total from when I mailed the application to get my passport. And that way I can book all my travel and make sure that I'm ready to go. So anyway, I thought I'd throw that out there in case somebody else is running into the same thing.

Jamie, what are your picks?

Aright. So, I've got two picks. First is, I drink a lot of coffee. And one of my friends at work introduced me to cold brew coffee recently. And I have absolutely loved it. So, for my birthday last year my wife got me a cold brew craft to brew my own cold brew at home so I don't have to go to Starbucks and spend four bucks on coffee all the time. So, that was really interesting. I'll have a link to that in the show notes. It's 30 bucks. And brew all your cold brew coffee at home. It's fantastic.

My second pick is we ran into some performance issues at work on the server-side. And this particular process is multi-threaded, runs the same code over and over in a loop. And so, we were trying to figure out like, what are we going to do? So, what we ended up doing is used… we took that app and ran it on JRuby. It's not something that we could do on everything. But that particular app kind of really spoke to JRuby's strengths which is true multi-threading and the optimization of code run in a loop. So, that was really interesting and really alleviated a lot of the problems that we saw, the performance problems that we saw. And so, my second pick is JRuby.

Awesome. If people want to know more about Clearwater, what you have going on, what should they do?

Right now the best thing to do is you can check out the Gitter channel which is Gitter.im/clearwaterrb/clearwater. I'll have a link in the show notes for that as well. Also, the GitHub repo, we've got some open issues. If you want to contribute code or just chat about things that you see, concerns that you have, absolutely open an issue. Talk to me. Let me know what you think.

Alright. Well, we'll go…

It's been great talking with you, Jamie. Thank you so much and best of luck with Clearwater.

Thank you very much for the invitation.

Alright, well we'll go ahead and wrap up and we'll catch you call next week.