02:39 - Hongli Lai Introduction

03:08 - Tinco Andringa Introduction

03:23 - Phusion Passenger

06:13 - Automation

08:37 - Parsing HTTP Headers

12:44 - Meteor Support

15:37 - Future Added Features?

17:12 - Passenger Enterprise

20:03 - Concurrency and Multithreading  

23:33 - Setting Up on a Server for a Node.js Application

25:06 - Union Station Monitoring Tool (Union Station Teaser)

Picks

Emily Claire Reese: Playing Catch-Up (Jamison)
Jason Punyon: Providence: Failure Is Always an Option (Jamison)
Active Child: You Are All I See (Jamison)
FFmpeg (Chuck)
YouTube (Chuck)
Developers' Box Club (Chuck)
Ruby Remote Conf (Chuck)
DevChat.tv Kickstarter (Chuck)
Dash (Hongli)
In the Balance: An Alternate History of the Second World War by Harry Turtledove (Hongli)
phusion-mvc (Tinco)
Union Station Teaser (Tinco)
Radio 1's Live Lounge (Tinco)

Special Guests: Hongli Lai and Tinco Andringa.

 

Hey everybody and welcome to episode 149 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance.

Hello friends.

I’m Charles Max Wood from DevChat.TV. Before we get started, I want to make one quick announcement and that is that I’ve put up a Kickstarter campaign. It’s for some Rails tutorial videos. However, the main reason I’m doing it is to give people an opportunity to support the show. So, if you want to go over and see what I have to offer there, that would be awesome. I’ll have a link in the show notes. And I should also have it up if you go to DevChat.tv/Kickstarter. You can check that out. We also have two special guests. We have Hongli Lai.

Hello.

And Tinco Andringa.

[Chuckles] Hi.

I’m sure I didn’t say that right. But that’s okay. Do you guys want to introduce yourselves?

Yeah, sure. My name is Hongli Lai. I am the author behind Phusion Passenger which is an application server for Ruby, Python, and Node.js/io.js applications. And Tinco Andringa is an employee within the same company.

Yeah.

Our company is Phusion. And Phusion Passenger is currently our main product. And with this product we hope to make web application deployment a much better and easier experience.

And I’m currently working on a new product as well. It’s a monitoring solution basically built as a single-page app. And we’re going to be launching that in a few months. And it’s very JavaScriptheavy. So, I hope to talk to you about that. [Chuckles]

Very cool. Now, I’ve known you guys for a while because Phusion Passenger is something that I’ve used to a while with Ruby. But now when you install it, it actually comes up and gives you options for Node.js, Python, and something else, I think.

Yeah, Meteor.

Meteor, that’s right. So, I’m really curious. What does Passenger offer you that just the regular fire up the server for Meteor or whatever, what does it offer in addition to that?

Well for one, it streamlines the experience. If you put a Node.js, io.js, or Meteor application in production, then there are lots of setups that you have to do, lots of let’s say boilerplate tasks that you have to do. For example, you have to start the server somewhere. And then you have to create an Nginx proxy. You have to configure maybe a monitoring script to ensure that your application keeps running when it crashes. You have to set up init scripts to make sure the application starts when the system starts. So, there are a lot of redundant steps in there if you want to put an app in production. And Passenger automates that.

If you are from the Node.js or io.js world then you are familiar with for example Forever or PM2, Passenger is like a combination of the responsibilities of Forever or PM2 and Nginx and init scripts and Cluster altogether. So, before you had to do five or six different steps and boilerplate configuration files everywhere. And if you use Passenger, then it’s a streamlined experience that is completely integrated with Nginx. And so, you just use your Nginx configuration. You say passenger_enabled on. And then Passenger auto-detects everything and makes Nginx act as if it is an application server for your application. And this just makes everything easier and also brings a lot of management benefits.

For example, Passenger can load balance requests even for WebSockets, something that is not possible with just the Cluster module in Node.js. Passenger provides management tools so that you can easily see what’s going on. If you just use Cluster or PM2 then it’s very hard to see, “Hey, where are my processes, what are their status, et cetera?” So, by being an application server, Passenger can give you a holistic, integrated experience in production, as I would call it.

So, does it need to plug into something like Nginx or can it be run independent of Nginx or Apache or whatever?

Actually, both. We have an Nginx integration mode. We have an Apache integration mode. And we even have a standalone mode if you don’t want to use Nginx or Apache or if you’re just not familiar with them.

So, help me understand how it automates all of the monitoring and upstart scripting stuff.

Something still has to start Passenger, right?

Yeah. And that is Nginx or Apache. But for the sake of keeping it simple, I’m just going to talk about Nginx during this interview.

So, normally when you put a Node.js application in production, or Meteor or something, then it is a good idea to use Nginx anyway because Nginx is very good at serving static files, something that Node.js is not as good at. Nginx is thoroughly battle-tested. It’s tested when it comes to security. When you’re handling HTTP connections, there are a lot of nuances in connection management that should be taken care of. For example, your connection timeouts should be right. Your buffers should be right. You need to be very secure in parsing HTTP headers. You don’t want any vulnerabilities there, et cetera, et cetera. And Nginx is just very good at those sorts of things.

Node.js, though I’m sure that with enough code you can do the same in Node.js. But it takes a lot of boilerplate code there to do things right. And probably a lot of people don’t do it right. And if you’re just re-implementing things in Node.js, then you’re just duplicating code in Nginx. So, in production it just makes a lot of sense to use Nginx. And if Nginx is already started, then Passenger takes advantage of that fact. So, when you use Nginx together with Passenger, then Nginx will start Passenger. Passenger will start your application. And from the point of view of the administrator it feels like as if Nginx is controlling everything. So, if you stop Nginx then Passenger stops too and all your applications stop too. So, it really feels as if Nginx is managing everything.

And Passenger is this thing that makes Nginx manage everything. It’s an Nginx module.

Sure. So then, the problem is reduced down to making sure Nginx stays up instead of making sure Nginx and your Node application running behind it stay up.

Yeah.

Is that correct?

Yeah, exactly. But Nginx, well actually I have never heard of Nginx going down ever.

I’m sure it’s happened. But yeah, it’s been very stable for me. I don’t have any instances where it’s failed on me either. It’ll fail to start if you have your configuration wrong. [Chuckles]

So, I have one more question about something you said. So, you said that Nginx is a lot better at things like parsing HTTP headers?

Yes.

I feel like that’s something most of the Node web frameworks do as well, if you’re using something like Express or whatever. So, does that mean you’re duplicating effort? How does that benefit you if you’re using Express, which also parses HTTP headers?

Well, it’s actually not Express that parses HTTP headers. It is the Node.js http server module that does that. And the problem is not limited to just parsing HTTP headers. There are a lot of nuances when it comes to connection management. For example, there is the problem which I call the slow client problem. So, if you are on the public internet, then there may be a lot of malicious HTTP clients out there who want to attack your server or who could attack your server if they get the chance to. And so, you’ll really want to implement your connection handling code very well to prevent for example Denial of Service attacks.

What I see in a lot of Node.js applications is they use the Node.js http server without any implementations for timeouts, et cetera. But those are very important when you are connected to the internet. You don’t want to hang onto a socket for too long, because if you do that then you will eventually run out of resources on your server for handling more sockets. So, there are all kinds of problems related to this. And if you really want to implement this well, then that’s a lot of code. But Nginx already takes care of a lot of that. Nginx has limiters on the sizes of headers. Nginx has limiters on how big request bodies may be, et cetera, et cetera. This is why in production it is really a good idea to use Nginx because they have already implemented all that stuff for you so that you don’t have to.

And you are correct that there will be source of parsing your HTTP headers twice because once it is done in Nginx, then Nginx forwards the request to your app. And your app reparses it. But overhead is very low, because in such situations, there’s a local communication going on between Nginx and your application. And the kernel optimizes the source of communication. So, the overhead is so low that you will probably not notice the overhead at all in production.

Okay. So, there’s not some special mechanism for only doing things in Nginx and then it avoids redoing the work. It’s more, you’re relying on the fact that Nginx is very battle-tested.

Yeah, yeah.

As like a first pass to filter out some things.

Yes, exactly.

Okay, that makes sense.

So, I’m wondering then. You’ve talked about the Node http server a few times. Is that what Phusion Passenger wraps over the top of in the same way that it wraps over Rack in Ruby?

Sort of. But you cannot really compare it to the Ruby implementation.

Okay.

Because Ruby is a very different beast from Node.js. What we do in Node.js is we hook into the

Node http library. So, when you have a Node application that starts a server at say, any port, then Passenger will hook into that start server call. And it will set up a connection between Nginx and whatever your application is listening on. And it happens in sort of an auto-magic way.

So, are there frameworks out there then that do things differently enough to where you can’t hook in that way?

It happens sometimes. We have thoroughly documented how our hooking works. And the lowest common denominator in Node.js land is the http library. Everybody uses that. I have not seen any library which does not use that. So, you could say that the http module in Node.js is kind of like Rack in Ruby. There may be some compatibility issues if an application starts two servers, because then Passenger is confused about what to do. But the cases are well-documented, very easy to fix. And it works in 99% of the cases from what I have seen.

Very cool. I’m wondering though, why do you need a different one for Meteor?

Because Meteor does not really expose Node.js directly. When you are using Meteor then it feels like you are using a totally different environment, something that is not a [inaudible] Node.js. They re-implement a lot of stuff. For example, they have their own package manager instead of using npm, et cetera. So, technically a Meteor app is a Node.js app. But from the point of the developer who’s feeling it, it may not feel like that. That’s why we have added special support for Meteor so that it is a little bit more user-friendly for people to use in combination with Meteor, special integration.

So, I’m also wondering. It seems like this is sort of, and this is the thing that I really like about Passenger and some of the other technologies that I use, is that it’s almost automatic. You just pull down the library and you just run it. And then you tell it, okay I’m going to be doing some Node.js apps, maybe a Python app or a Ruby app. So, you just tell it you’re doing all of those. And then it gets everything set up so that you can just configure it in your Nginx or Apache configurations. Are there instances where it doesn’t make sense to use Passenger?

Well, I’m the author of Passenger.

Never! [Chuckles]

[Chuckles] So, of course I’m going to say no. In my opinion it always makes sense to use Passenger. But I have a strong opinion about this, so I may not be the right person to ask that.

Right. [Chuckles]

I guess what I’m asking is, are there things that Passenger isn’t good at that you might want to consider alternatives for?

Not anything that I can think of currently.

Right. And the things that your application doesn’t handle well or as well as Nginx, Nginx just picks up, like static resources.

Yeah, exactly. Passenger handles that automatically. So, it checks if a request is associated with a static file. And if so, then it just lets Nginx handle that. And the request never touches your application.

Right.

So, a concern some users or people who are using at Passenger have is that it’s trying to do a lot, right? So, we promise that it makes your app robust and that there’s no additional thinking required to use Passenger. Some people get the idea that therefore Passenger is super complex and they might want to use something simpler that they can understand better. Like the only thing an app server does is forking a new process and lets you deal with all the other stuff. So, that’s a reason why some people choose another app server. But if you would ask us, is there a rational good reason to do that? Then we say no. But that’s a reason some people don’t choose Passenger.

Yeah. [Inaudible] the internals is documented pretty well in my opinion. We are in an effort currently to make the internals more and more visible so that users can just understand what’s going on, more transparency.

So, one question I have is do you see a future where more of these features get pulled into the individual language platforms? Or you think that there will always be a generalized language agnostic tool that’s better to use as a front? Does that make sense? That’s kind of an abstract question.

I think it’s actually going the other way. With the new tools like Docker and stuff like that, it’s actually going towards languages and frameworks just being as simple as possible, just providing the interface to the developer. And then having these huge platforms developed by people at Docker, Inc. or CoreOS or whatever, that take care of all this. So yeah, I think it’s going the other way. But if Node.js would develop itself further, then yeah. Perhaps.

Hongli, were you going to say something about that, too?

Oh, well Tinco pretty much covers it up. And I thought that there are some tools out there in Node.js land that kind of do what Passenger does, but not as comprehensively I think. Some other languages, they also have something very similar to Passenger. For example, Python has uwsgi. I’m not sure whether I’m pronouncing that correctly. But it’s also an Apache or Nginx module that manages your Python applications. And well it’s kind of similar to Passenger. But when I look at the new languages like Node.js or Go, then the trend is indeed like what Tinco says.

So, I’m wondering a little bit. You have Passenger Enterprise.

Yes.

And we talked about it on Ruby Rogues. I’m assuming that it works in the same way and offers the same kinds of benefits to Node.js apps. Do you want to talk about that for a minute?

About Passenger Enterprise. So, Passenger itself is open source. It’s MIT licensed. And we started, it started as an open source project and we intend to keep it that because we are just fans of open source. But in order to be able to make a living, we also have a commercial version, Passenger Enterprise, which has some additional features that the open source version does not have. For example, it supports rolling restarts. So, the features that I’m talking about are available for all languages including Node.js. With rolling restarts you could deploy new versions of your applications without downtime.

Normally when you deploy a new version, if you shut down the old application and start a new one, then there is a small amount of downtime in between. You don’t want any requests between there to get lost or to be blocked. So, with the rolling restart feature in Passenger Enterprise it will restart your application in the background. And while the restart is happening, it will keep the old version of the application running and let it handle requests while it still can. And this is how it ensures that there is no downtime between releases.

It also supports resource control. And by this I mean that it is able to keep application bugs in check. For example, some applications, they suffer from memory leaks or they suffer from bugs that cause it to freeze. And Passenger Enterprise has features to detect these sorts of problems and restart your application when it happens, in order to prevent your users from getting in too much trouble. And this does not solve the problem at the core, but it will give you some more breathing space. So, these are the main features in Passenger Enterprise.

There’s a full list of features written on the website. If you go to Passenger Enterprise, I mean PhusionPassenger.com/enterprise. But the main gist behind this is you get better features. You get support. And this together helps your application become more robust, helps your application stay up longer, et cetera.

Yeah. So, the normal thing we do, the regular thing we do with Phusion Passenger support is that you send an email to the open source mailing list. But if you are an Enterprise customer you get to send emails to our premium email account and they’ll be handled faster, or at least reliably. And you’ll get to talk to the developers themselves. So, it’s a pretty good support deal.

So, I’m really curious. You talked about concurrency in multithreading stuff a little bit, or I think you mentioned it. Can you talk about some of the advantages of that?

Multithreading. Well actually, multithreading is not applicable to Node.js because Node.js is singleprocess, single-threaded with an evented I/O model.

Oh, okay.

The multithreading is only applicable to Ruby.

Oh, okay.

But when it comes to Passenger, Passenger actually does something that is a little bit related, and that is multiprocessing. Because Node.js is single-threaded it cannot use more than one CPU core per process. If you want to use multiple CPU cores then you have to spawn multiple processes.

And people usually do that using the Cluster module. And the Cluster module is really great because it spawns multiple processes and load balances requests between them in order to be able to use multiple CPU cores. But the problem with the Cluster module is you have to write boilerplate code in order to use that. And the Cluster module does not support WebSockets.

And this is the advantage that Passenger brings. Passenger also supports something similar to what the Cluster module does except it does not require any boilerplate code. So, if you have an app then most of the time it just works. You just tell Passenger, “Hey, I want to serve this application using six processes. Go do whatever is necessary,” and Passenger just does that without you having to modify any code in your app. And even load balancing between WebSockets just works.

Because with the Cluster module, the Cluster module itself does not really understand http, so it’s a little bit difficult for it to load balance for example long-polling connections and WebSockets and those sorts of things. But Passenger supports sticky sessions between processes. And Passenger itself understands http. And that’s why it is able to do that kind of stuff.

So, maybe if I could summarize the problem, the issue is that things like WebSockets or longpolling connections, they need some state maintained across connections.

Yeah.

And with Cluster you’ll just get [shunt] to a random process. It might not be the same process as was originally serving your WebSocket, right? Is that accurate?

Exactly, exactly. That’s what the sticky sessions feature in Passenger does.

So, it just keeps track of which WebSocket connection is going to which process?

Yes.

Okay.

That’s awesome. Can it do that across servers? So, if you have a load balancer in front.

No, not [inaudible] ones. If you have a load balancer in front then you have to configure the load balancer to stick certain clients to a specific web server.

Okay.

So, this is currently outside Passenger’s scope.

That makes sense.

I think you can get them to cooperate, though, can’t you?

Yeah, you can. Passenger’s sticky sessions is implemented in terms of cookies. So, what we could probably do is to provide documentation at some point in the future about how to configure for example Nginx or HAProxy to do this as well. It isn’t that hard. It’s just that the hardest part is on the local machine. If you want to have sticky sessions on a per process basis without entering into some sort of maintenance boilerplate [inaudible] with different configuration files, then Passenger just makes your life a lot easier.

So, let’s say that I was going to set this up on a server for a Node.js application. What are the steps for doing that?

First you have to install Ruby, because Passenger is partially written in Ruby. The core server is not. It’s in C++. But there are command line tools that are written in Ruby. These command line tools are not performance critical, which is why they are still in Ruby. But on most systems, it’s just an apt get install away or a [inaudible] install away. So, it’s very easy. And then you extract the Passenger tarball. You run the installer script inside it. And the Passenger tells you, “Hey, you need to paste two lines in your Nginx configuration file.” And then you’re ready to go.

And then when Passenger is installed, you just write an Nginx virtual host configuration. You point the virtual host to your application’s root directory. And then you say passenger_enabled on inside the Nginx configuration file. And then Passenger knows, “Hey, the root directory of this virtual host looks like a Node.js application. So, I’ll go serve it.” And then that’s pretty much all you have to do. And Passenger under the hood will set up all the connections and set up process spawning for you, et cetera. And if you are on for example a Debian system then it’s even easier. Then you don’t even have to install Ruby or extract tarballs or something, because we provide Debian packages.

Yeah, I love using the Debian packages. It’s super convenient. And it sets everything up even more automatically for you.

Tinco, you mentioned that there was a monitoring tool you were working on that was a pretty JavaScript-heavy application. Do you want to talk a little bit more about that?

Oh, sure. So, the product we’re building is called Union Station. And it’s basically, we started the project because we had Passenger. And Passenger is able to monitor your app. It has a lot of metrics built in. So, we made a SaaS solution for monitoring web applications. And mainly Ruby applications at the moment, but we are also writing code to monitor Node.js applications. And the past year and a half we have focused on the frontend o fit. And we started in Polymer. I saw you had a talk about Polymer as well about a year ago I think, or a half a year ago. And it’s been a lot of fun.

You’re still using Polymer today?

Yeah, yeah. We built our own little framework. It’s actually going to be my big, ‘we’ll do that later’. But we didn’t go with all the standard components Google made. We just took the technology, so just Polymer itself, and we built our own single-page app infrastructure on it, our framework on it. So, we have our own page-switching system. And we have, we’ve built everything on Polymer. And we don’t use any other JavaScript framework. We don’t have jQuery or Angular or anything else.

We just use Polymer and a very lightweight JavaScript central app utilities file.

So, do you want to talk about the decision to use Polymer? I think that makes you pretty unique, I’d say. [Chuckles]

Yeah, I think so too. It didn’t really take off as fast as I had imagined. [Chuckles]

But yeah, so about a year and a half ago we started thinking about how we should start developing this new frontend. At that moment Angular was really, really taking off. And I looked at Angular and I looked at Ember. And I looked at the other solutions. And I thought Angular would be the most modular way of building apps. But I thought it was very ugly. I was going to use a bad word, but I don’t like Angular at all. It looks so ugly. And there’s so much weird stuff going on. I didn’t like it at all. And I liked Ember, but Ember was not really made for that type of application, because it’s a monitoring application or an analytics application.

So, the user’s mostly clicking around looking at stuff that’s coming at them, right? No forms, no interaction. So, we thought it was too heavyweight for that. And Polymer came out two weeks before I started this. I looked at Polymer and the cool thing about Polymer is that it’s all future web standards. So, it’s HTML5 and it’s all based around the new createElement function and custom elements.

Web components.

Web components, exactly. And yeah, it has this kind of ASP.NET code-behind sort of feel, which probably sounds horrible but it’s actually pretty nice that you can define a component. Like for example we have a gauge and a gauge that shows percentage, like it would in your car console, right? And I can just type union station gauge in my html and then say what value it’s bound to with the mustache syntax. And it will automatically update the gauge with JavaScript animations in D3, real-time whenever that value changes. So, it’s a lot like Facebook React and Angular’s two-way updating system. But it’s all plain html from the user side. So, I think it’s very elegant. And I managed to convince the other developer that’s working on it. And yeah, we totally drank all the Kool-Aid and then some. [Chuckles]

The core benefit of Polymer I think is the fact that it’s based on the web components. So, I have a lot of experience with desktop applications. And one thing that I’m used to with desktop applications is that I can abstract way certain controls on the screen. Like if I want to have a

complex control that has a lot of logic behind it and maybe some components, then I can write a class for that that completely abstracts away the internals. But with the web, without web components, that’s not really possible. There are all kinds of leakage in there when it comes to abstraction. But with web components you can encapsulate everything inside a single component. And it will act as if it is a single tag. For example, you could write a date picker which has complex logic in it. And it would just be a single tag and it would contain all the JavaScript that’s needed instead of you having to write more JavaScript to define events to do stuff or something.

So, it helps you encapsulate things, basically.

Yeah, exactly. So, it makes your app much more composable. You can reason about it from a top down [inaudible]. Like if you look at something then you know that there’s not something else outside that is mixing with it, et cetera. So, everything is really inside it.

If you look at the index.html of Union Station, then it’s just like 80 lines or something. And the 80 lines are just a list of the main components of the app. So, all the pages and the routing, that’s all in the index.html. And then the implementations of all the pages are in separate html elements. And those html elements, they have their own definitions. And in those definitions you can see all the components that they consist of. So, for the developer, there’s your app/element directory. And inside of those are just all the elements separate of each other. You can namespace them and use them as you like.

So, I was going to ask if you would still choose it today. And I’m going to guess the answer is yes, because you sound super excited about it, still.

[Laughs] Yes, yes, although I’ve been really digging Facebook React as well. So, that’s also a very cool technology. So, maybe today because Facebook React is so popular, everyone is going for Facebook React at the moment, I think. That may be a very good argument to choose Facebook React. But yeah, I’m definitely very satisfied with picking Polymer. And at first, when we first started, it was really in beta. You should definitely not use it in production.

So, it broke every month and we had to refactor stuff. And it wouldn’t work on all the browsers and stuff like that. But we just had a little bit of faith. And I don’t think that’s, maybe not a very good idea if you have a tight deadline or whatever.

That it would work out, but it worked out. And now it’s a very stable product. And yeah, it works on all browsers. And we had very little trouble with it. Yeah.

Well, we just don’t use their UI library. We’re not using the Material Design stuff.

Mmhmm.

Very cool. Well, I know that we all have a hard stop coming up, so let’s go ahead and get to the picks. Jamison, do you have some picks for us?

So, I have three. My first pick is a blogpost called ‘Playing Catch-Up’ by someone named Emily Claire. Yeah anyways, she’s a web developer that started getting into development later in life, which resonated with me because I didn’t start writing code until I was a freshman in college. And she talks about this feeling she had of being so far behind everyone else because she had spent a large percentage of her life not writing code. And it seems like lots of people in this industry grew up on computers. And it can feel like you’re behind all the time. And there are all these things you don’t know that other people know. It’s not a feeling I’ve seen expressed a lot. But she talks about how we decide that other people are experienced and the ways that we signal that to each other. And how sometimes the signal that you are smart and know what you’re talking about is you have a lot of Twitter followers or something, which is totally wrong.

You can know nothing at all about what you’re talking about and still have lots of Twitter followers. So, it’s a blogpost about how you can catch up and also how you can identify and signal expertise.

It made me think a lot and I really liked it.

Cool.

The next post is called ‘Failure is Always an Option’. It’s about Stack Overflow’s or Stack Exchange’s attempt at inserting machine learning in their platform. And they did a lot of work to figure out the right models and get their math and ML side right. And then they went to actually implement the technical side. And they just blew it. They screwed up horribly [chuckles] many times over and over again. And the main theme was they decided their existing tools couldn’t handle it. So, they picked something they weren’t experienced with. And then ran into roadblocks and slowdowns because of that, where they really should have been able to just look at the problem and design their solution in a way that would fit their existing stuff. There’s always room for fitting new technologies into your stack. But I feel like we focus a lot on that as developers. And it’s interesting to hear another example of someone who tried to just use the new shiny everywhere. And it didn’t work out.

And then my last pick is an album called ‘You Are All I See’ by a band called Active Child. It’s like choral electronic music. I think the guy who makes it was in a boy choir so he has this beautiful falsetto voice that sings along. It’s interesting and I enjoy it a lot. Those are my picks.

Cool.

Alright. I’ve got a couple of picks here. I’m going to pick two things that I’m not working on. And then I’m going to pick a couple of things that I am working on. So, the first thing that I’m going to pick is FFmpeg, which is a utility that converts audio and video formats. I’m working on getting all of the episodes of all of the different shows that I’m involved with up on YouTube. So, what I’m doing is I’m taking the album art and using FFmpeg to basically loop that across the audio to make a video, and then uploading that to YouTube. And it’s working out pretty nicely. I am going to get show notes and things like that up into YouTube as well for each of those shows. It’s probably going to take a little longer. But overall, it’s been pretty awesome. And I’ve already converted several of the videos. The real work is going to come in tagging them and updating the titles and stuff, because it doesn’t pull that information off of the video.

But anyway, I’m also really liking YouTube. So, I’m going to pick YouTube as a platform to put stuff out, not as a timewaster. Though there is some pretty fun stuff on YouTube. [Chuckles]

And then a couple of things that I’m working on. One is DevBoxClub.com. And that is, it’s a box full of interesting stuff. I’m hoping to include a tech book or a t-shirt or something else of that nature in it along with just other interesting or useful stuff for developers. And so, if you’re interested in that, you can go sign up at DevBoxClub.com. I’m probably going to do the first box in April or May. And I’m only going to do a run of 50 on the first one just to see how it goes and to see how much work it is and see how my pricing is compared to how much work it is. So, if you’re interested in getting such a box, and I’m going to try and make them as awesome as possible, go check that out.

Also JS Remote Conf was this last week, or as you’re getting this, about a week and a half ago is when it got over. And it was a tremendous success. I really enjoyed it. I got a ton of positive feedback, learned a bunch of lessons about stuff I can do better next time. And so, now I am working on the Ruby Remote Conf. And so, if you go over there and sign up for the mailing list, then I will be able to let you know when I have things together and tickets go on sale, and all that stuff. I know this is a JavaScript show. But I know there’s crossover, too. So, I’m going to put that out there.

And finally I’m going to remind you about the Kickstarter campaign, DevChat.TV/Kickstarter. If you want to support the shows, if you want to support the effort over here, then go check that out.

Hongli, what are your picks?

So, my first pick is Dash. Dash is a documentation tool for Mac. Dash is a documentation viewer and it supports lots of documentation sets from Ruby to HTML to CSS to JavaScript, even Bootstrap. And anything that you can imagine that is in popular use today. And Dash allows you to view the documentation offline. It is super-fast so it is faster than when you have to wait for the network to load the documentation API. And you can search everything from a single interface. It’s just great. I use it all the time when I am developing, either locally or when I am in a train without internet.

Worldwar: in the Balance’ by Harry Turtledove. So, this is about an alternative history where it is World War II. And then aliens land on earth. And those aliens, they thought that earthlings would be really primitive because they had some probe that was here in 12th century. And they think, “Aha, these lowly earthlings, they throw with spears and what can they do against machine guns?” et cetera. But then they were very surprised to see that humanity has processed a lot in just 800 years, because apparently that is very uncommon among intelligent species in the universe. And so, they were totally surprised. And they thought at first it would be a very easy conquest. But then they find out it is not so easy after all. And it’s a very interesting series of books. What I’m talking about is just volume one and how the battle with the alien progresses and how it has effect on the history and on our technology, et cetera.

That seems really interesting

Yes, I strongly recommend it. Well, I only have two picks.

Darn, that sounds like fun sci-fi. Alright, Tinco, what are your picks?

      Yeah,    I    have    a    few    picks.    First    one    is    a    GitHub repository we made. It’s

GitHub.com/phusion/phusion-mvc. And it’s our Polymer model view controller framework. So, it’s actually what my colleague extracted from the Union Station app. and you can take a look at it and see if you like Polymer. And it’s not really for production use or anything. It’s actually, it hasn’t been maintained in over four months. But it’s more for people to look at. We actually did a roadshow where we travelled across the US. And we showed Union Station to people for feedback, and trying to get some nice, beta customers. And we…

That’s a really cool idea.

Yeah, we presented about Polymer as well. So, this is the tool we used to teach people how Polymer could be used in our style.

And my second pick is UnionStationApp.com [chuckles] which is where you can look at our own implementation. You can request a beta and get a peak on our source code and see how we use Polymer. And maybe if you feel like it, give us some feedback on the app.

       And    my    third    pick    is    not    a    plug.    My    third    pick    is    a YouTube channel.      It’s

YouTube.com/bbclivelounge. We’ll get the URL right. And BBC Live Lounge, I’m a real big fan of live studio recordings. And it’s just all kinds of bands that come of the BBC recording studio and play a cover of someone else’s top hit. And after that they can play their own music. But yeah, the covers are really cool. So, you see Hosea covering Taylor Smith or something, or Swift. [Chuckles] So, it’s just very cool live music.

I have a neighbor named Taylor Smith. Anyway. [Chuckles]

Awesome, sounds like fun. Yeah, and Union Station’s definitely something I want to check out. So, alright, well thank you guys for coming.

Yeah, thank you.

Thank you for inviting us.

Yeah, no problem. Thank you for having us.

I don’t know what time it is over there. I think it’s 9 o’clock in the evening or something.

Something like that.

It is.

Yeah.

But yeah, we appreciate you taking some time out. Catch you all next week.

Yes, [inaudible].