The Changelog: Software Development, Open Source - Node.js and Server-Side JavaScript (Interview)

Episode Date: April 6, 2010

Adam and Wynn caught up with Felix Geisendörfer to talk about Node.js, server-side JavaScript, and JSConf 2010.

Welcome to The Change Log, episode 0.2.0. I'm Adam Stachowiak. And I'm Winn Netherland. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at thechangelog.com or for a real-time view, check out tail.thechangelog.com You can also head over to github.com

forward slash explore where you'll find some trending repos, some featured repos, as well as all the audio podcasts from this year's podcast. If you're on the Twitter, you can follow Changelog Show, not The Changelog, and I am Adam Stack. And I am Penguin, P-E-N-G-W-Y-N-N.

Awesome episode today. Talked to Felix Geisendorfer from Transloaded about Node.js, our favorite server-side JavaScript framework. Nice to see the streak has been kept alive. Kept alive at 20. Some awesome mind-bending JavaScript. Speaking of mind-bending JavaScript,

we'll be at Texas JavaScript June 5th in sunny Austin Texas and let's not forget we're heading to Red Dirt RubyConf back up to the OKC Coco up to the OKC Coco actually I think it's at the convention center the actual conference but I'm sure we'll stop into the Coco and see all the

compadres there that's May 6th and 7th open Oklahoma City great episode this week should we get to it? Let's do it. Hi, we're joined today by Felix Geisendorfer from Berlin to talk about Node.js. Felix, why don't you introduce yourself to the audience, let them know who you are and why they should care. All right. My name is Felix Geissendorfer, and I currently work a lot on Node.js,

which is why I'm on the show. I previously did a lot of work on CakePHP, and, yeah, I started using Node for a project of mine where, like other technologies, we're really bad fit, and maybe we can talk about that a little bit well it's kind of hard to to think that anybody that's caught a single episode of the changelog would not know what node.js is at this point but for those uninitiated folks that maybe this is their first episode why don't you give a little background about node.js and you know what problems it aims to solve? Okay, sure.

Well, Node, pretty much one description I read was it's the first server-side JavaScript implementation that you actually would want to use, which I think is a nice and simple explanation. A slightly longer version goes somewhere along the lines that you can do things in parallel with Node really easily because it sits in an event loop. So instead of just like writing your code line by line and seeing it executed in this order, you get callbacks for everything. So if you want to start

1,000 HTTP requests or answer 1,000 of them at the same time, it's not a big deal because it's all event-based. And that makes Node kind of special from most platforms where this stuff is definitely possible, but really cumbersome and not really efficient. So Node was created by Ryan Dahl, I guess. Right. How did you get involved with the project? I got involved with Node around June last year. I saw it a little bit earlier than that and thought it looked kind of neat.

And then I was doing a lot of work that involved worker queues. And I was writing those worker queues in PHP and PHP daemons to process a queue. And it was really messy. And I was remembering Node and how it was really easy to run comment line scripts in parallel with it, which is what I was doing a lot at that time. And so I tried to use it, and it worked pretty well initially. But I hit issues, and so I just started contributing. Because what actually made it really easy is that most of Node's API itself is in JavaScript instead of C++.

So people can contribute easily. I think it's kind of funny that we've actually I'm not sure if you actually noticed this, but this is going to be the next point release. The last point release was Chris Wanstra from GitHub and Felix gets to be episode 0.2.0 and that's

Node. We've been talking about Node for such a long time. It's been like a streak, so we finally get to episode 20 of the changelog and finally have someone on to talk about Node. How fitting. It's been like a streak, so we finally get to episode 20 of the changelog and finally have someone on to talk about Node. How fitting. It's actually even more fitting. The next big release of Node is also 0.20.

Wow. Yeah. It's an important release because it's going to bring some API stability. Let's talk about how you got started in, I guess, in open source and in Node.js. What got you on this kick,

and what got you excited about it to get started with it? Well, my story programming goes that I started fairly early. My dad gave me a C64, where all I wanted to do was play games. But if you guys know some machines, you had to type in like three comments to load the disk and start it all up. And I got interested in that that's like visual basic on that afterwards on the pc uh got internet but even after that for a long long time i was really

isolated from the programming world and uh then a friend of mine introduced me to cake php i was doing web development stuff at the time and i realized that i just had been reinventing the wheel i mean i i did my own kind of framework i didn't call it that but it was really messy compared it was like let's use that um at the same time rails obviously was big and i looked at that but i couldn't get it to run on my windows machine back then so that's where that decision was made for me um it wasn't really like a wise technology kind of choice. So then I started blogging about like what I was doing. And I was blogging a lot about CakePHP and how it sucked.

And like, I guess a year into that, the people on the CakePHP team finally had enough of that and gave me a chance to contribute. And they were like, listen, if you're just like saying what's bad, why don't you come on and help fixing it? And I was really interested in that and started working on CakePHP and plucking about that a lot. Our little plug, I'm now doing it together

with my partner Tim. We've written like 400 entries. Actually, I think that is an important part why open source is fun for me because if you start writing about it, you also get a lot more feedback instead of just like doing commits. So they're not really visible

to anybody who's not deep into the project. So what source control system are you guys using for KikPHP? The longest time it was subversion. They now switched to Git. I'm not actively involved with the project anymore. I still do a lot of work with it, but I'm at the point where it really does everything I need.

I don't hit any bugs with it. And going forward, the next technology I'm going to heavily invest in is going to be Node and JavaScript. You know, that's interesting though with more and more projects going over to Git. Git just makes it so easy to fork a project and apply patches to a project. It's almost like put up or shut up

if you've got criticism of a particular project, right? Yeah, and I guess because people can do it without asking for permission first they can like go ahead fork and do stuff and point it out to the world whereas with subversion you could write a patch and email to some mailing list but it wouldn't really get a lot of eyes on it and well it's also a bigger barrier because you'd have to be like i when i was using subversion i would never email patches around.

I knew how to use Subversion, but I didn't care much beyond that. That's quite the leap from PHP to server-side JavaScript. PHP is on every Unix machine and half the Windows machines on the planet. Google, the V8 engine that powers Node, not so much. Talk a bit about how does someone get it set up with Node and the installation process and how do you get up and running? Sure. Installing Node is pretty easy if you're on a Linux and Mac machine. If not, and you're not really like a Unix hacker who can pull off like a CYG install and fix all the issues you might hit, don't try it. I wouldn't try it with Windows yet.

If you're on a Linux machine or Mac, you can just download the source. The description on how to do that is on the website. Then you type in configure and make install, and it's a pretty painless process. So there's no external dependencies, and I haven't heard of a build error on the mailing list for the last two months or something. So now that you've got Node set up, it's pretty easy from that point on. You just create your first JavaScript file, call it my.js, and then you call up the Node binary, which is now installed in the comment line. And you're saying Node, my.js, and the JavaScript code gets executed. If you're doing a server, which is going to be a long-running process and you want to deploy it, you're going to need some way to demonize it. Node might do that in the future, but for now you're going to have to use

like a Ubuntu upstart script or whatever your platform has for that. But really running locally is very easy. Deploying is easy as well, but you need a little bit sysadmin skills for that. For those developers out there who are, I guess, primarily client-side JavaScript hackers, maybe even some really deep ones, what is the biggest difference between client-side JavaScript hackers, maybe even some really deep ones, what is the biggest difference between client-side JavaScript coding and server-side with Node? A few things. Speed.

Everything is placing fast with the browsers, unless you look in Google Chrome, which is the engine that Node uses, V8. Things can be sluggish. Another big difference is that you can use a lot of new JavaScript features that people are avoiding right now because they're not going to run in everybody's favorite browser like Internet Explorer. So V8 is headed for a full ECMA 5 compatibility, which is a new proposal or standard for JavaScript

that got accepted a little bit ago. And so you can use all of those functions that V8 currently implements. It means like array has a native for each method filter. What's really cool is you have a standard JSON parser and stringifier and a few other goodies.

I think getters and Setters. And there's actually a page in the Node wiki which describes all the cool features that are available. Google Node and V8, I think. Those are definitely the biggest differences.

Other than that, I think there's also a lot of similarities. If you're used to handling click events, like on click, so same ideas apply a lot in Node because you have events, like your connection coming in or some data finishing, writing, or sending, and you get a callback, and you just deal with the callback. So everything in Node is asynchronous, and a lot of things in the Clyde sites are asynchronous as well.

When you look at, I guess, kind of where Node is going now, it's still sort of fresh and young, right? What are some of the new things that are happening with Node, like any web frameworks or any specific templates that are coming out difficult moment to join the scene because since Node 0.1.28, there's been a lot of backwards compatibility breaking changes. Those are a little painful because everybody has to update their applications. But they're really nice because some of the things that are enabled by them. I guess the biggest deal is that one concept that's really important to note is streams, streams of data. Like you're having a read stream

of files that you're reading in or TCP connection or standard out, or you have a write stream, like standard in or an HTTP connection you're writing to or TCP connection or standard out, or you have a write stream like standard in or like an HTTP connection you're writing to or TCP your file. And with a standardized interface, Node will be able to build abstractions to that or users will be. So you can say, take the stream that's coming in here and pump it into this other stream

and automatically handle buffering and all kinds of other issues you might encounter so that's a place where the api is changing a lot another thing is features being added there's unique support for units unix sockets was added inter-process communication is a big thing on the agenda as well because with with Node, you only have like one thread. So if you're running out of CPU power, you need more processes to split it amongst multiple cores. And so you would start multiple Node processes that communicate. And I guess buffers are a big deal as well. you notice working on a native buffer object which allows you to directly address memory chunks similar like you would do in a low-level language like z

and so you would get a buffer of a fixed size and you you would operate on that basis and on strings which note has previously used but which are not really efficient you know one of the things that i hear quite a lot in the same context as Node is just how fast it is. Can you give the listeners any idea just how fast Node.js is and what types of tasks it does well? Yeah. Node is very fast in, like, hello world benchmarks, which are often used for comparing technologies, simply because you have a really like low or fast pass between like a connection coming in and Node being able to handle it.

That's by design and that's an advantage over a lot of things. In terms of numbers, so they're really rough numbers, but I guess on a machine where you would install Nginx to serve a static file and Nginx would get like 20,000 requests a second, I guess Node is somewhere in the responses sent by Node are dynamic. So in terms of having a dynamic web server, there's not a lot of stuff that's faster than Node that is not written completely in C or C++. Most dynamic scripting languages will be a lot slower. So do you see Node shining, I guess, coupled with something like WebSockets?

Is that really where the sweet spot is? Depending on what you're doing, it is. Everybody who is excited about real-time web technologies should definitely have an eye on Node. I think it's a very excellent use case. I've done a lot of long polling kind of stuff with Node, which is also nice because with like a PHP script, you really wouldn't want to send an HX request,

which hangs for multiple seconds until the answer becomes available. With Node, that kind of thing is really efficient and you don't have to worry about thousands of those requests just hanging in there um yeah so web sockets are definitely a big big area where node will shine talk for a minute about promises and and do opinions on those oh that's yeah that's a big thing I actually left out in the API changes. Node removed promises. For those of you who don't know what promises are, essentially whenever you called a function that was asynchronous,

you would get an object returned, which we would call the promise. And you could then call methods on this object, which would notify you when things happen. So you could say promise at callback, and you'd be notified when this promise has been completed, or there would also be an error handler, so you could handle errors. This is completely gone from Node now, because everybody had an opinion on how to do it better or not, and there was at least three threads on the mailing list with close to 100 messages. And so Node removed those.

We are now using simple callbacks where the first parameter is either null or say error object if an error occurred. And this makes a bunch of things easier. You mentioned the do library. The do library deals with scenarios where you have multiple asynchronous things happening at the same time. You have the callbacks for those, but you want to group them. You want to wait for all of them to finish. Or you want to do all of them in sequence and handle the event where something goes wrong in between. Node doesn't really come with any abstractions for that. And do looks like a really, really nice way to deal with those.

For my codes that I'm writing with Node, I usually haven't used do yet because whenever I had some needs that I needed to abstract, like multiple things going on and group them, I was using like an integer counter as a private variable to keep track of it. And that worked really well and gave me more flexibility than any abstraction would. So I guess if I would have this problem more often, then I would definitely go with do because it looks really nice. And do is from our buddy Tim Caswell. It was in episode 017. Yep. And they built the blog howtonode.org.

I'm not sure if he's running Do in that framework, but the open blog still fascinates me. Along those same lines with libraries like Do, what's the state of package management or library sharing in the node ecosystem um basically nobody's really using package management yet and by nobody i mean most people who are not some creators of package management software for Node. There's Isaac, who's working on NPM. And there's TJ Huchak, or do you guys know how he's pronounced? Anyway, he's working on something called Kiwi. He's also the creator of Express.

And I really haven't invested heavily in those yet because with Node's API still moving, those things will break. And when I need to deploy and make package management part of my deployment process, that's really just another hassle to worry about at this point. So I'd say once the API settles down, both NPM and Kivi will be really interesting to follow. So TJ's got another project called Express, Express.js, that aims to be a Sinatra-like DSL for creating apps on top of Node. Have you played with this at all?

Sorry. Express. No, I have not played with it. Oh, sorry. My throat. I might have to get a glass of water in a second. Sure, no problem. Anyway, let's try Express. Express looks really nice. It seems like TJ is putting a lot of work in it. I have one big problem with it.

It's taking this idea of one language, namely Ruby and Sinatra, and tries to emulate it kind of one-to-one in Node. I think most projects taking this route are not really going to feel natural in Node because all these Ruby or Python or whatever projects were written with a different programming style in mind. Another big problem is creating DSLs in JavaScript. JavaScript does not really lend itself nicely to create domain-specific languages, just because you cannot easily define symbols and function names and mix them into the local scope without polluting the global scope. And so Express, as far as I know, pollutes the global scope with global methods like get and other methods.

And I think that is really something that people should avoid in JavaScript. If it wasn't for that, I would really recommend Express because it looks TJ puts a lot of work in that. But I have a problem with anything that pollutes the global namespace in JavaScript, just because it's a bad practice that we should all try to get away from. Pretty much every time Wynn jumps on my project, I don't have jQuery defined properly. He yells at me, so I'm used to that. So you haven't played with Express, but what about Fab?

It's another pure JavaScript DSL. I guess everybody's got a Sinatra fetish these days. What about this one? Fab is one that I actually have played with, and I think it's really going an interesting path. Rather than

trying to ban JavaScript to look like a DSL, it's pretty much on every function call it returns a function call. And so you get like a really long list of like function calls, but you can indent them and the parameters are then like taken into account. And it kind of looks like a definition of the sitemap of your website. You really have to see it to get a picture of it, but it looks like Lisp.

What is really interesting about it is that it really focuses on streaming. So every node that you kind of have in your tree that defines your site is like a little application that can stream data up to the next node or down from the previous node, and you can alter the data stream.

And you can also change the type of the data stream. You could take JavaScript objects like JSON downstream and then convert them into actual JSON strings and in the next application G-SIP them. And it's really nice to see how you can create really reusable stuff with that and just chain it together in interesting ways. Yeah, that's interesting. The two, I guess, initial reactions that I've got to looking at this is it looks a lot like jQuery,

which it says right there on the homepage, in the chaining events. But in the other approach that you just mentioned, having these horizontal aspects, it sounds a lot like in the Ruby world, what we call rack middleware, where you can just, you know, have different levels of your application kind of latch onto the responses and requests.

Right, right, exactly. And there was a lot of discussion in the node and also the common chess community on like a standard for this. I think, what's the Rack standard called? Help me out, guys. I mean, either way there's some sort of standard that

governs how Rack works and how the objects look that it passes around. And what's really not been part of the discussion until Node came along was how to do this with streaming data. I think with Rack, you always have a finished message and you pass it on to the next middleware. Right, right.

And then it deals with that. But with Node, you actually have the ability to take half a message and pass it on. And the application needs to be able to deal with that every step of the way. And that is, I think, something that Fab solves really elegantly and where it's going a little bit beyond of what Rack might do in the Ruby world. Interesting. So it mentions here on the Fab homepage

about using it as a CommonJS library. What's your experience with CommonJS and how does it play into dealing with Node? I'm not very involved with CommonJS itself, but since we're in the JavaScript server side world, we're talking a lot to the people that are pushing CommonJS. I think the Node standpoint is we look at everything that CommonJS puts out there

and if it looks nice, we consider adopting it. is we look at everything that Common Chairs puts out there. And if it looks nice, we consider adopting it. But mostly Node is driven by implementations. Ryan always says implementations should drive standards. So if there's something that's really hotly debated, and the scope is limited, I guess Node is the kind of library that goes ahead and starts an implementation, tries to look how that feels, and then takes it from there, rather than defining a big standard up front.

And so the common chance people are probably a little frustrated with Node from time to time, but at the same time, it's an interesting discussion between defining standards or implementing something and deriving a standard out of it. We've got a couple of questions coming at us from the IRC channel. One is a pretty good one. I actually think I've had this one in the past too. It comes from a fellow. I'm not sure how you're going to pronounce this. His Twitter handle is ETHNT. I'll let you try to butcher that one since you're good at butchering names.

His question is in regards to production environments, he doesn't really want to take the time to learn Node.js, but his question is if there's any hosts out there that have Node.js already on them that he could deploy to, and if there's any you could recommend.

No. I am not aware of any Node-specific hosting at this point. I think most people have a dedicated server or virtual machine that's a SSH into configure Node, compile it, and then push the applications to. And it's pretty much a manual process at this time. It would definitely be nice to see something like Heroku for

Node in the future, but I think it's a little too early for that. Before we go too far away from the discussion we had earlier, too, we were talking about TJ and Express and all that, but he's also got a library called JSSpec, and it deals with testing your code and whatnot. How does that play into

Node, and how does Node deal with TDD and BDD setups? That's a good one. With testing stuff, I find DSLs to be more compelling because I can see how they make the tests easier to structure and easier to read. I still disagree with what JS spec does in terms of exporting global objects. I think it's messy.

I think it exports a describe method and an is it method and all kinds of things. Node itself, what Node does is, initially it was using the test suite from V8, which is called ms or mjs unit and um now we're using the common js uh testing module or their specification which is pretty much a module called assert and it just has like assert equal or assert deep equal and a bunch of assertion message which uh throw an error so you

write your test as like a plain javascript file and if one of your assertions throws an error node exits with an error code of one and so if you automate like your test suite you just check if one of your tests has an exit code of one um for a project of mine, I'm also using just the asset module. I kind of like the purity of it, just like doing the minimum I need. And like a library on top of Node, which might again break with the compatibility if Node changes API, is really just another headache for me to worry about. My personal guideline for any third-party libraries with Node is, unless they have full unit test coverage and look really well written, I try to avoid them just because it's another part of the software I don't control and Node itself is moving fast. In general, I might like to have something like JSSpec if done a little differently in the future, but I'm also

not sure if we really need it. That's because JavaScript itself lends itself nicely to unit testing. If you need a mock object of something, you just define a JavaScript object and you attach methods to it, or you take the original object

and you just replace a method, and that all feels very natural and very easy in JavaScript. But the jury's still out. I don't think a lot of people in the past had to deal with testing stuff that's asynchronous. It really changes how tests look, because its indention level goes a lot deeper than it would go for test suits, usually. Usually you just have one, like, indention level with assets lot deeper than it would go for test suits usually usually you just have one like indention level with assets maybe an if statement but um asynchronous testing is still

pretty new land and uh i i stick with the purest form which is using the asset module on node right now but going forward who knows what comes up you know in the changelog, Adam and I are big Haml and Sass fans, and so I think we've covered multiple ports of Haml to JavaScript, both Haml.js and JSHaml. I've seen Sass.js. What are you using for your markup?

I would imagine Mustache would be suited for this sort of thing. What do you use in your projects? Well, my main project does not output any HTML. So it's a problem I don't have. For some client consulting I did, I actually set up Mustache because I think it's a nice approach.

And I think I was using Jan Lennert's implementation of it. Haml, I like. I used Haml a little bit in Ruby before. I'm just not convinced of the quality of Haml.js implementations out there yet because most people think, hey, it's easy to parse a syntax, but then it turns out it isn't

and you have to debug a parser or compiler, which is not fun. So Mustatch is what I use right now and which I find good. So if you're not returning a front-end markup, what are you returning, JSON objects? Yeah, the project just has a web service API and it's all REST and JSON. So what sort of projects are you working on with Node.js?

The main project that got me into Node and that I'm still heavily working on is called Transloaded. It's basically a service for people who want to outsource their file uploading and video encoding and don't want to deal with that on their own boxes at all. We give them a jQuery plugin, and their form submit events are high-checked, and we take their files to our machines, we show an upload progress bar, and then we encode the videos and upload them to S3. Where Node really shines here is that a lot of the stuff we do is call up comment line scripts once we've received the upload.

So we have, at any given moment, like 20 or 30 comment line tools running side by side, and it's all just one node process managing them and handling the events. With any other kind of technologies, we would have to write like workers who, where we'd have one worker working on one comment line tool execution because that's usually a plucking process.

The other thing where Node is really nice is file uploading. One of my earliest contributions to Node was actually a multi-part parser, which has now been replaced by a better one at iSIG Road. And so in Node, you can actually receive a file upload and handle every byte as it comes in. It's a stream of data, and you can choose to write it to disk or first inspect it before you write it to disk. And that is nice to us because we can kind of look at authentication information.

That's one of the form fields that's being submitted to us. And if this doesn't match, we can abort and upload, which might take an hour for a big video, and notify the user of a problem right away. And that kind of flexibility is what I really enjoy in Node, and I guess why I started using

Node initially. So you're going to be speaking at JSConf coming up, right Felix? Yep. Got your topic picked yet? Yeah, the topic is called NodeDirty. NodeDirty is like a fun project that just came to me one day. I was thinking about what kind of stuff

you could do with Node. And one thing I came up with, you could write like a key value store because it seems fashionable these days. And I started playing around with a few ideas and what came out of it is called no dirty and what it basically does is it tries to not do the things that all the other databases being relational or no sql suck at and that usually is abstraction. Abstraction itself is not bad. It just means that you have to learn some sort of interface and some sort of, like, thinking model to access your data.

And I think that's really a barrier to your data rather than, like, helpful unless you know it really well. And this other thing is networking. I guess the more decent data stores out there have decent networking code, but where they still fail is that a typical application has to send multiple requests over the network to generate its page or whatever it's doing with the data, and then aggregates its results and compiles them to some HTML on the client side. And I think the networking is a really big bottleneck,

especially if you go for high write performance. And so what Node-Dirty does, it does no abstraction, and it does no networking. So all you get is a little database object with a get and set method. Whenever you set a key and a value, it's directly written to an append-only JSON file. It's just new line separated JSON. So that's really simple about it. And you get a callback. The callback fires when the data has been written. But even before the data has been written, it's already in memory. So if all you care about is having the data in memory, you could return to the client that it's done right away. Or you could wait for the disk persistence.

So that enabled something that most data stores don't allow you. They either go for full consistency or they give it up for eventual consistency or all kind of ways you can spin the cap theory. And with Dirty, my hope is kind of that you can choose what model applies the best depending on your situation and current data set. And people would use it to build their own databases that are actually applications. It would be applications that directly contains a business logic and use something, either Node-dirty or something like that, as an underlying mechanism. I think that's a really interesting use case for Node because now you can write all your business logic in JavaScript

and just provide a nice JSON interface, REST interface, that answers business questions rather than abstraction questions, rather than like doing a query or some sort of mapper to use. You just directly ask your database a business question, which I think is what databases should answer. And all the abstractions happen internally. So your current query API is basically a get by ID or a filter where you essentially pass it a function much like you would if you were filtering an array

in JavaScript or jQuery, right? Right. The filter thing is just to get people started. It's once you get into millions of records that won't perform anymore for a few reasons. One of them is Node just has a single thread. So if you filter over a million records,

nothing will happen until you looped over all of them. So once you go for bigger data sets, you probably want to update some fuse or caches every time the set method is called. I'm currently thinking about either providing an explicit plug-in system to make those things happening or just overwriting the set method and monkey patching it. But I

dislike that a little bit, so I'm still working on that. So no dirty. No dirty, no sequel for the little man. Is that the title of the talk at JSConf? I'm changing the sub-slogan from time to time, but no dirty is the title.

At this point, really, just to clarify that, it's mostly a fun project, and I'm seeing how far it can be pushed. I think it's going to be a nice way to store data, especially for prototyping, especially to keep your moving parts

in the stack low. If it's really going to make an impact for high-performance stuff, I don't know. I'm doing some benchmarks that look very, very promising, but I don't work on high performance site as part of my day job. So I can only go by what all the cool kits publish and what their problems supposedly are. I'll hopefully get some feedback at the conference. And that question was from, I believe, Chris Williams, Voodoo Tiki God on Twitter. Let's talk a bit, before we hit the radar, Felix, about the development scene in Berlin.

What's it like to be a code slinger in Germany? It's pretty nice. I think Berlin has the biggest startup scene in Germany. I don't think it's anywhere near Silicon Valley, Bay Area, but there's a lot of interesting stuff going on. Jan from CouchDB is there and I started hanging out with those guys a little bit.

They started actually a JavaScript user group in their co-working office, co-op. And I did one talk on Node there, and there's been a lot of excellent other talks there. And yeah, I mean, whatever your technology is, you will find lots of people in Berlin to talk with them. There's a lot of events. And as far as the tech scene in Germany goes,

I think Berlin is where it's happening. So I guess the common question we ask to close off the podcast is, what's on your radar in terms of open source software? What's out there, I guess, besides Node that you're just dying to play with that's just got you really excited about open source and what you're doing? My April Fool's was I'm quitting quitting open source but that's not going to happen so um what else is on the radar um i i really am liking ruby i and i would like to do more with it uh i don't i don't have like a uh like client work or any other time that I could spend on it. I really hope that Node will be able to do everything Ruby is being used for right now,

but that's still multiple years off. So if I happen to have some time, I'll definitely play more with Ruby. And I guess any Node projects that come up. But other than that, I'm mostly looking at the JavaScript stack at this point. Cool. And before we close off, you mentioned earlier a startup you're working on.

Can you plug that URL so that the listeners who didn't hear it clearly can go there and check it out? Right. It's called Transloaded.com. That's T-R-A-N-S-L-O-A-D-I-T.com. And I assume you're on Twitter, too, so what's your Twitter handle? Is it Felix E.?

Felix G-E. Well, thanks, Felix, for taking the time on a late Friday evening over in Berlin to chat with us. Really appreciate it. Now we can maybe put the Node.js streak to bed on purpose. Maybe next episode. I don't know about you, man, but I'm going to sleep well tonight knowing that we've talked about Node.js so much. And finally, our second point release, episode 20,

is going to have a full-featured episode of Node.js. It's awesome. Well, cool. Let's wrap there. Felix, anything else you want to mention before we head out? Sure, yeah. I want to thank you guys for the opportunity to speak here. I want to just say that

Node is, like, I'm spending a lot of time on it, but the really big man behind Node is Ryan. He's, like, working day and night to make it awesome, and I guess if somebody who hasn't contributed to open source before wants to contribute to

something, Node gives you the opportunity to use your JavaScript skills. There's a lot of stuff to help out with. Just hop on the IRGC channel, check the GitHub issues. If you need any help with stuff, people are around to help you. We love everybody you need any help with stuff, like people are around to help you and we love everybody's contributions.

Cool. Thanks, Felix. We'll chat at you soon. Yeah. Thanks for having me. Thank you for listening to this edition of the change log. Point your browser to tail.thechangelog.com to find out what's going on right now in open source also be sure to head to github.com forward slash explore to catch up

on trending and feature repos as well as the latest episodes of the changelog Safe in your arms As the dark passion shown Was mine alone Open I'm open All roads to drive Bring it back, bring it back to Open Outro Music