Node.js on the Road: Q&A

Node.js on the Road is an event series aimed at sharing Node.js production user stories with the broader community. Watch for key learnings, benefits, and patterns around deploying Node.js.

Question and answer session from Node.js on the Road, Lisbon.

SPEAKERS:
EMCEE: Nuno Job @dscape
Founder & Principal, YLD!

TJ Fontaine @tjfontaine
Node.js Project Lead, Joyent

Ben Acker @nvcexploder
Senior Software Engineer, Walmart

Rudi De Sousa @rudids
Head of Web, British Gas Connected Homes

Luke Bond @lukeb0nd
Senior Consultant at YLD.io

The question is, if you're a frontend developer how can you actually ramp up to be a Node developer, what are the differences, and how can you make sure that you have the proper training and you can do the migration, or you can assess if you're already a developer that would be qualified to do a good engineering and you're not getting your company into trouble, or even worse, making it look like this is not a suitable technology when in reality it would be?

So, can I just comment on it? I don't want it to be taken out of context, all people are welcomed to Node including frontend developers, that's not the message I want people to take away from that. The point I'm trying to get there is, again, going back to what I was saying around engineering, alright? So, when you run the client, when you're running on the client, as a perfect example, this is just client-server basic stuff, right?

When you're on the client, you have to think about one person, one machine, and you'll get very lucky, and you can do lots of dumb stuff because it doesn't affect you, right? And then like people, we're all creatures of habit, you then go over to Node and you'll take some of those habits with you because that's just what you do.

And then you don't take the time to understand things like scaling, the way CPUs work, this concept between multithreadedness to single threads, what the event loop does, all that kind of stuff, and then you do the same thing, and then it's like poof! and you don't know why. And it doesn't mean you're a bad developer; it just means you've made the assumption that JavaScript here is JavaScript there and that's what I don't want people to do.

As to how you get there, work with us, with all of these people, and I don't know if you guys got anything else.

I was going to
say that if you haven't been introduced to the Nodeschool.io tutorials, they're fantastic and can give you good, they provide a good example of some of the gotchas in Node, how to use Streams, like Learn You Node for Great Good provides you a good idea of the basics of Node, those are all good, and I'd also like to say that, I also think that there should be more tutorials.

If you are a Node developer, write some and post them and get them hosted so other folks can learn, so that we can all help each other, so that we can just continue to help our group to grow.

Just, I want to add
quickly on that is that when you guys are learning, you're going to learn stuff that we're not considering any more, in our kind of work because we start thinking about, I don't know, scaling and deployment and all sorts of stuff, and then we might forget to do the tutorial, it's going to be really helpful to someone who's just starting out.

So just because you're starting doesn't mean you can't write a tutorial. When you figure out something, document it. Use markdown, write it all down and start a blog somewhere, use Ghost as it's written in Node. And then publish it. You'll get trolls, and they'll give you trouble, and they'll tell you you're wrong, but screw them, ignore them, come talk to us, we'll help you out.

Yeah, I absolutely agree with that, that's one of the things that we, for the documentation around Node is that we can't wait for it to be perfect, and that's—the contribution process works like that. So like, get some documentation out there in the ecosystem and we can all collaborate together on making it the best documentation so that everyone's successful with Node.

And that's the feedback loop, it works for Node core as a project and it will work for the documentation and the websites and all of those things together. The community is fantastic, we can be very constructive, so all of those things that they said.

OK, so I'm going
to lead with another question.

We all know what Node core is or at least most of us, we can just skim the documentation and understand what's there, but at the same time it kind of, it means different things to different people. One of the things is this batteries not included approach of the Node core. It's just the core. The rest that is built around can be built by the community, whoever wants to build it and that's great, so Node just focuses on enabling the community or the companies to be able to achieve the results. So my question to TJ is going to be, what is Node core to you and what do you want it to be, and I think that's especially interesting because then we can contrast with the answers from the industry on what is Node core to you, what is important to you and what do you want it to be?

Yeah, so Node core for me is the team that's working on the software that you guys use that's known as Node. So we're a team that are trying to get feedback from everybody and figuring out what is working for you, and I want to be able to—Node is a thin veneer over top of the operating system and providing a common way to interact with all those things, but there are things that we can provide inside of Node core. It's a constant battle between micro and monolithic frameworks.

Java and .NET are perfect examples of monolithic frameworks where we're just going to give you everything. For Node core, it's about providing the things we see everyone using all of the time. In some cases, V8 makes those decisions for us. Promises, for instance, but they're not, not everyone uses Promises so we can take that as an opportunity to be like, okay we can provide an alternate control flow mechanism.

Which we do, I call it Streams.

But that's a whole other thing. But I mean, so Node core is thin and a small and important group of people who work on it but it's the community that is built on top of Node core that makes all of it. So Node core is an important piece of this but it's not the only piece of the project, and we just need to be responsive to the community's needs, so.

And what do you see Node core being in the future?

I think Node core, because
we're at this inflection point, where we're seeing larger companies and enterprises adopting it and trying to move from Java into Node in a lot of cases, the core is going to be comprised more of desires from larger companies, and so Node needs to be able to include what works for those larger companies without stomping on all of the ethos that we've already had.

So with, for instance, Walmart recently hired Chris Dickinson to work full time on Node because since Walmart is so heavily invested in Node, it's important for them to be able to have a resource that they can go out and work with on getting their features and their bugs working effectively. It's not necessarily Walmart buying a seat at the table for Node.

So what ends up happening, is that Chris was already a member of the community, he's got a long track record, and those contributions are what determines him being able to be a part of the core team. So anybody in the community can end up being on the core team, but companies like Walmart have the ability and the resources to pay for people to work full time on Node, and so what I want to be able to do, is facilitate those companies and the community as well to continue to contribute in that way.

So people can, so <span class="STsearchMatch">Fedor</span> started at NodeJitsu, now works at Voxer and is able to focus mostly on Crypto and our TLS layer. That's great. So we can have people who focus on a sub system, maintain that, keep that going forward, and respond to the community as they need those things. So if a company, or a set of companies have a feature or subsystem that is important to them, they can donate resources in the form of someone in the community to work on that subsystem, and then it kind of works out for all those things.

So, as we have sub systems in core, those are where we can add people to the core team.

You guys have anything to add,
what is Node core for you as a user?

[xx]
I mean when I was first starting with Node and people used to say I'm playing with the Node thing, what is it like, I told people we talked about it, people at Sony, what I would just say it's like V8 with like system calls that you can make for like IO, and I remember thinking that was really cool, and for me that's always been where it's been in my mind I think of it as, so I kind of like the idea it stays relatively small.

I wholeheartedly concur, I like the "standardized thin veneer over the operating system," sums up my feelings about it.

I'm sitting next to
three people far more intelligent than me so whatever they say.

It is a thin veneer but I mean, so for instance,
just like HTTP is something that's really hard to get right so it's difficult to provide only zero batteries, like there has to be a little more to it, so where it makes sense we add those things. So if HTTP/2 ever becomes a real standard and adopted in the ecosystem, you could see things like HTTP/2 being included in core, but being developed, Fedor already has a module, because he's a beast. He has a module for just, I mean he and substack and TJ Holowaychuck just poop out modules all the time.

That's not the right connotation. They iterate really quickly and produce a lot of modules. So speedy's already working in the ecosystem, and as that proves out and as HTTP/2 becomes a standard, then Node can just work with <span class="STsearchMatch">Fedor</span> on bringing that into the core. So as things like that are identified that are working, that everybody needs, then it's a clear win for Node to bring it back in.

That's interesting. Andy, Rudy, Luke, is there anything that you guys ever thought like, we wish that was in Node core and it totally isn't?

No. Good choices TJ, then.

There is
something that I think would be of value to the enterprise especially, and that is Node core running on the JVMs. And I know this is a topic of debate and I'm going to tell you why. It sounds like a crazy idea, but when you do have these big enterprises with massive investment in infrastructure and deployment mechanisms and all this kind of stuff, and they put all this effort involved in the JVM, it'd be an easier sell to get them to think about that, and then evolve that conversation further, try to improve it, and then eventually just dump the JVM element if you want to or whatever, but it's a whole return on investment thing for big companies.

You've got a massive data center, you spent a lot of money, and then suddenly you're just like throwing the baby out with the bathwater, and all that stuff, you don't need it. In particular things like web server licences. In a way I think it would be an interesting experiment. I don't know. These guys will probably tell me all the reasons why it's a bad idea, but that's just me.



I won't say it's a bad idea.
I'll say that it's difficult to do. So, there's a path forward on that, and I think it's important, especially from an internet of things, that's word bingo, I love it. As an internet of things embedded devices world, there are a lot of devices out there designed to work really well with the JVM today so you could actually just kind of like, if we could abstract the way our run times sits, we can put it on the JVM, if you go ahead and put Node in a whole bunch of places where it can't go right now.

So that's a fantastic opportunity and I'd love to be able to do that. The difficulty with that is, Node's asynchronous. Node's a thin veneer over operating systems, but sometimes Node does not behave the same way between all operating systems, and events happen in different orders in different operating systems.

Everybody's tried to do scalable, non blocking IO in a slightly different way mostly, and so sometimes events come in different orders and Node tries to paper over as much of that as possible such that your applications work regardless of where they get put. You take away libuv and V8 and then just smack it all on top of the JVM, you have a different set of—a different platform that it's now targeting that Node has to be able to go out and support.

So it's a question of, we can enable people to do that, the question becomes then how do module authors, are they able to support that in that environment and people who built the ecosystem, can they also support in that environment. So I think it's very interesting and there are paths forward for it; it just needs to be done in collaboration in such a way that we can all support it going forward.

It's a great answer. Well one thing that makes us software engineers, instead like as Mark says that's professionals that really makes the change is when we change our conversations from what's the cool way to do this and how can this be done in a creative way, which is very important our creative process, but we change that to how can we fulfill requirements.

We don't have to stop the creativity. It's still very important to be able to fill those requirements, but it's a different challenge. For Walmart, we have to be able to have 400,000 concurrent connections. Well, they were having 400,000 concurrent, so I'm guessing a million. That's where they said so they know that they can hold the traffic, but the question we got from Tom is for Ben: what tools and methods did you use to provide insights into making sure that you can fill the requirements up ahead?

OK, first of all, I think that that's one of the things that I've loved about Node, is being able to solve problems that it seemed that there were folks would try to shoehorn into JVM solutions, like Java solutions that already existed being able to solve certain things. So, earlier when I mentioned adding in the proxy layer, one of the things that we did was add in, we have a whole bunch of monitoring stuff that we added in, so we'd be able to monitor traffic everything down to event loop delay. So we were constantly monitoring all of the hardware for stuff that was happening like, just straight OS stuff like, CPU usage, memory, all that junk, and monitoring everything that's going on with Node, and that's when we would use those and then do load testing.

That's how we would establish what kind of numbers that we would need for machines going into heavy traffic. Does that make sense? Oh! good? Yeah, so there's a module called good that just snaps into hapi that automatically just sends that stuff out. We pipe that stuff into all those graphs that I showed Eran tweeting from, those are in Splunk, so we have, hapi is sending stuff to, hapi is—statistics on happy are being gathered by good and also on the machines, and that's all being pipped over into Splunk and we're looking at it there.

I had something else just a second ago.

Can I ask a quick question?

Certainly.

So we
used to use Splunk at Sky, this is going to be just dumb, it used to become a source of entertainment for the execs, every time we mentioned the word, Splunk, we got a similar reaction. It's because Splunk is telling us, and they laughed and giggled like little school children.

There's a lot of words especially in the names of our open source libraries that get a lot of laughs. Nipple. And I'm just looking at the floor so my face doesn't turn super red.

Sorry, I derailed this entire conversation for no reason whatsoever.

Back to scaling Node. But
yes, we mostly use those tools. We've used New Relic also as a tool before the New Relic 1 release came out, we used that and some of our test stuff at Sam's, and it was really useful also, but most of our stuff is just from the internal analytics plug-in that we have for hapi.

Hopefully that answers the question. If you were looking for something more, let me know, and I can elaborate.

Can you just read the question?
Because we have a questions on like, just like event loop, It's about this. OK, go.

[audience inaudible]

OK.
So the question is about how the deployment is made at Walmart, and what's the process, and if they're seriously just running Node's index.js in production.

Yes.
Alright, that's not the total answer. So poop takes a core dump. So if there's an exception that causes everything to go down poop, poop grabs that, then it takes a core dump, and then we're able to analyze that and see what happened. Also we've utilized MDB and other services.

We run on SmartOS, and so quite often if something goes wonky, we take those and send them over, and MDB is used, and there's much rejoicing. Everybody is happy. I don't know what that means, but for the most part, specifically, there's a hapi binary that ships, so we don't have a central server, so there's not an index.js. And all that hapi thing does is call a js file that resides in hapi, loads from that configuration.json that I mentioned earlier combines that with the all the plug-ins that have been loaded by NPM, and starts hapi.

So it's literary just executing Node on our behalf.

Yeah, so Lloyd talked it
a little bit about it before. I'm going to highlight some of the things that we do in SmartOS that I think you guys might actually be using, I'm not sure. You guys used to do deployment with just Bash starting Node, right? OK, but then there's also this technology called SMF (Service Management Facility) that actually is a part of the kernel to handle launching processes and keeping them running, and identifying when they're flapping and how to do back-off and all that kind of stuff. Do you guys have a local software Load Balancer?

OK, can you talk a little bit about that architecture there? Because that's kind of what he was kind of alluding to. From the front door down to where the Node process is, how that does that actually look like?

Yes, it's running on a—like, we've got a butt ton of servers running behind a load balancer. So when a request comes in, it'll hit the load balancer, it'll go through Apache, and then it'll hit the Node services. So that's ultimately how it's running, and even we're using PM2 to do management of certain processes on new stuff that we've got out, but that's, I don't know what more.

That's good, that's good.

Also get with me
in a little bit, and I can provide, there is, Eran Hammer, my boss has done, has put up a gist that basically shows our entire network typology and everything that's running on it. So I can provide that to you, and that might—that will sound a lot smarter than I am looking right now.

He always does, he always does.

I just want to say like,
it's common to have a hardware load balancer at the front door, a software load balancer on the logical machine and then multiple Node processes for the logical cores in the environment. So however you—that's generally the service oriented, like, you can horizontally shard on the machine, and then you can horizontally scale it across multiple machines, and that's a lot, sounds like what you guys are doing with an offline leg and an online leg. It's often the pattern that we see with Node.

Since Node is single threaded, you want multiple processes to actually take care of the multiple cores on a machine, but then you want to be able to scale out. That may be sufficient for what you're looking for, but if you have multiple logical machines you would put a hardware, or even a software load balancer in front of it, a load balancer at two levels there is where we normally see that.

[inaudible audience]

Does Joyent
do that transparently for you? So I going to put my sales hat on and say Joyent is an infrastructure as a service provider. That is a functionally that I would normally put more towards a PaaS and there are a lot of Node PaaSes out there. One of them in particular that Nuno mentioned at start of it is NodeJitsu, who actually do run on top of Joyent infrastructure. So NodeJitsu is one of the premiere Node PaaSes out there and they do a lot of that kind of management stuff so they do it on top of the same technology and use that kind of facilities to do that.

I mean, I don't know if you noticed but while they are answering I'm like itching all over because I can't answer, but I'm like, I must talk. But Rudi does a lot of that for me but anyway one of other things that I will add, is that it's always, just like you do functional tests, you do unit tests. I mean, integrating your performance requirements into your CI and CD setup is something that you can and should do.

It's something that lacks a lot of tooling, but having understanding over your programs, and how like certain realistic performance tests that try to mimic what happens on your website at least to some level, and analyzing what's happening to your program. That's something that I think you should do, and that's before it's in production, and it's a sensible thing to do. Mostly because—and the reason I care so much about the topic—is it will help people go and feel safe deploying even when they don't have the skills that Walmart has. They will still be able to do it because they followed the process that enabled them to figure things out before being in production.

So, sorry. I was just itching for that.

I have to add something to that.
Again back to my whole point of my talk around being a good software engineer. Do that to get you going, but don't then just assume that you'd never have to understand how that works, and they go, oh! someone else is going to do it.
So I can just ignore that part because then they're not doing what I said, and you're not an engineer.

I am going to add
one of my questions if I can do that, for Ben, which is I think is very interesting. One of the main challenges that people have, is like how do I build a good team. It's always hard to find good engineers and build a good team, and in Node.js, it adds a little bit more, mostly you might think that technology is a good fit and you might understand from a high level concept it's a good fit, but then you have to start a team and you still don't understand the technology, but you have to build this and you're building a really serious project like Walmart for Black Friday, so what was the approach that you had to get your team? How were you so successful setting up such a great team?

You're going to look at the floor now but…

No, I think the
original team of just a few of us, Eran was doing Node at Yahoo and was brought over by Ben Galbraith and Dion Almaer who are pretty notorious for creating really good teams, and then I don't know how I ended up on that team, but Wyatt (who spoke at LXJS) he was brought on to the team because he just kept, like he was issuing PRs like mad on hapi.

Like here, this needs to happen and this needs to happen, and over here this needs to happen also, and we're like OK man we'll just start sending you a paycheck, that's cool. Van was another, he was very involved in the Node community or in loads of Node projects and Node knockout in San Francisco and he come on early too, and that was the original team.

Since, I think the most, the more useful answer will be how we went from 4 to 20 in the past six months, and that's straight up community involvement. Getting like, being involved in the community, I try and help out a lot with the community up in Portland and Seattle. Eran does a lot, he speaks a lot at different conferences, and just reach out and be involved with the community so you can get to know some of the people that are there, and then once you know them and you've seen things that they've done, then you're looking for people, you either have a group of people that you can invite to come work with you, or they will know people that you can invite to come work with you. So when Eran was like, hey! we need folks on Twitter, people just started emailing him like crazy and sending stuff in so.

I know that Ben doesn't think that this is a very different way to do recruiting, and he's thinking this is normal but in reality this is a complete shift from the "send me 100 resumes that I'm going to statically analyze for key words and then I'm going to profile people and the best sales guys will be hired as engineers because, well they're sales guys so they can sell themselves much better than we can."

Sorry, I can't say that. That's a fundamental shift, and people will say that doesn't scale, but in reality there's meetups all over and they are more like a hive. And there's a lot of these places, and you can identify the people that can really help you and another thing that I think is fantastic about Ben's answer is that being a professional doesn't mean that you can't be involved and you can't participate in a community. You don't have to be serious all the time and that's how we identify the best people, to serve something like Black Friday so I think that's fantastic.

Rudi, do you agree?

Just a quick comment
because this is a big point for me, so I got two experiences of this. At Sky, being the company they are and the pressure that comes with working for a company like that, we went from two people to—and this was a wide range of technology, this is not all Node—we went from two people to, I think, 120 within about four months. And that meant my entire—you can picture what my days were like right, they weren't fun. And you talk about how you build a team, you don't. You just don't, it doesn't exist, there is no perfect team. Sometimes you get lucky and you find a really good one, like I have now with guys at British Gas, but you don't always get it right and this applies to everything, just fail often and fail fast.

Just get going. The best thing you can do is get going, and then when it's not working, be open and honest. Don't be destructive to another person. If they're not working out on the team—they might be great developers or whatever, but team dynamic doesn't work out or things go wrong, don't be destructive and put them down. You just say, look it's not working in the context of this or whatever and edit the team and find someone else and repeat that pattern until you're comfortable and very productive.

You don't just fall into a team. The community definitely helps but it is a lot of hard work, trust me.

Anyone else?

Nope.

OK, cool. Another
question we have. We talked a lot about migrating from Java. I actually see a lot of people running PHP and migrating to Node too very frequently, but what if you get into a scenario, this is Alan's, elaborating a little on Alan's question, what if you get into a scenario that you're actually called in but they're already running Node and it didn't go so well, and you have to quickly go there and show I need to debug this app, it's already in production, I need to help them but I also have to show that these errors were not a fault—Node's fault. How do I debug that and how do I help the customer or my new company figure this out and go over that hump?

Basically, the first thing to do is try to get the thing working obviously, if that's what you're there to do, make sure that's fixed, because that's going to get you a lot more brownie points. But then when it comes down to it, don't go nuts, don't bite off more than you can chew. If they're nervous and they don't know what to do and they're like a bit sceptical, don't go in there and go, yes just throw all that stuff away, and let's rewrite everything in the Node and it will all be okay, and the Parrot AR Drones will come out of the window and save your soul, and like, don't do any of that, just find a tiny thing within the stack that you think is going to be most beneficial, and isn't going to be in their face like 24/7. So like an example of this, is if you're working for an e-commerce site, don't suddenly go, I'm going to rewrite your payment engine in Node.

Because even if you are going to do a great job, they're going to freak out and they are going to tell you get out.

Why do you say that, it's so good with numbers, JavaScript.

I only need 53 bits of precision.

But find something else,
something to do with module around the way the content's managed, or figure out a cool way of storing markdown in GitHub and then converting it on the fly on the server and popping it back up and making that whole process more efficient for the marketing guy who wants to sell a little micro service. Find things like that and then show them how awesome it is and how quickly you can turn around and then after a while they go "here's the payment module, go make that."

Yes. I'm going to add, also on if you get into this environment, somebody is already trying to running Node, they didn't execute the best at it, don't freak out. I had this experience where I had to help a company that was launching a service built on top of Node, and they were not doing so well on day of launch, and they were kind of freaking out, and really all I did was just like helped them take a breath, and have them start reading the error messages.

I know it sounds crazy, but sometimes you actually have to read the standard error output from Node if it died, and then we just walked through getting some of the major bugs that they were hitting by reading those error messages, and then the service was up and running, and everything was going better forward for them. They had a lot more faith in Node and in what they had written once they saw how to get past that pain point of right now.

Then they did identify shortly after that architectural problems, but I agree, you can't freak out about that and tell them and turn around and tell them you have to rewrite all of this that just went wrong. You have to get a transition plan for them. You can be planning for the future of what the ideal state actually should look like, but you need to figure out how that transition is going to happen.

Further tooling for debugging and all that kind of stuff, there is a ton of stuff out there that people are working on and have done. If you're debugging memory problems, there's a module that I know that Walmart has used, I know a lot of people in the ecosystem have used, it's called heap dump. It's reasonably effective at what it does but you have to know in advance to take a snapshot of the memory.

If you saw some of the examples from Ben, he was running Node with --abort on uncaughtException, and that's a mechanism that Joyent—that Dave Pacheco worked on and added into V8, and added upstream to V8. So this is how Joyent also runs all of Node in production. The idea is that when you get—when Node throws an exception and you weren't expecting it, you get a core file, and you can then go back, and then inspect the state, and then reconstruct it. You have the whole stack trace, you have all the objects, you can work through all of that information and fix the real problem and not just try catch around whatever threw right then, or maybe throw on domains and be like oh! well I just handled that, see, problem solved. It's very important that when an error happens you know why it happened and how to fix the real thing and not treat the symptom but get the cure for it.

So all of that that's there that works on SmartOS and on you can use core files from Linux and do that, and I'm working on making it more approachable so that you can just do core files as a service really. Just upload the core file and get a report back. Sometimes some of the syntax in MDB is arcane. It's important to be able to have that but it's not always the most approachable for some people, so there's a lot of tooling that everybody's working on.

Is it heap or he?

That module is heap, the question was, it's H E A P D U M P. Keep in mind that if what you're trying to debug is a memory leak, you're going to get a large representation that you're going to then take and then load into Chrome. Chrome does not like one—Node processes can be 32-bit, 1 Gig, 64-bit, 1.5 Gig.

You're about to try and load a 1.5 gig file into Chrome, just keep that in mind. The opportunity to use MDB as a streaming, it's all streaming so it's not loading the whole file into memory as you're doing it, and really when you're talking about server side, there's much more to it than just the JavaScript heap.

There's actually all of the Node C and C++ memory that's being used. If you have a binary add-on, it may have C and C++ memory that it's allocated. So you actually need, potentially need a wider view of the whole system memory and not just the JavaScript objects.

On your question for Nuno,
I'd say that same as what Rudi was saying earlier about basics of software engineering principles and things like this, if you're going in to help someone who is in that situation, the problem solving hasn't changed now that Node's come around. It's the same kind of steps that we all take through when debugging anything in production, but also this on the more personal side of it, whether that be personal or business, it's kind of like when you have, say a friend at work who has some problem and you go over there.

You don't go over and shout at them, and chuck it all away it's all a load of crap, or you don't want to say it's all Node's fault. Things aren't that simple, and this is just like, you just treat the situation the same as you would. In that situation, I guess, be helpful, constructive, real, like the message we're sort of talking about here as LXJS
as well.

Cool. Yeah, one of the things I see is
that it's good to follow a process if you have a problem. Oh! dammit, okay. No, just follow a process using two good people that understand Node, tried to understand some clues, go from there, and then when you figure out the problem, make a test to make sure that it doesn't get repeated.

[TJ] Please add test, always add test, everything needs a test.

Something interesting,
I don't know if you all have noticed any of this, but when TJ talks there's a voice that he has when the microphone's here, and then there's another one when it's touching his beard. So, look for it. I've been calling it beard voice.

That's beard voce.

Is this working?

Yes, it is. And so [xx] is a guy that does fantastic community work in London, and his question was, one of the things that is very important is how to get involved in the community, but also how to get involved, how does the Node ecosystem work? Both for companies like, how can companies get more involved into Node? Understand how Node works underneath, like having a transparent view of how it works, and also like how can they be included? I see that from a company perspective. I know that all he sees that from a perspective of people that are involved in the field working with Node. What is the process, TJ? How do you describe, like how does Joyent work with all the other companies that do this?

All the communities all around the world, so many people. What is the process? How do people get involved? How do people get involved in that conversation?

So the first and foremost way that we found companies getting involved with Node, is actually through the GitHub issues, and a lot of times it's difficult to know that they're actually coming from an organization because they're just coming in though their personal GitHub account, and smacking us in the face with a pull request because we made a mistake.

So that happens and you start seeing the same name pop up over and over, and over again, and then you appreciate that. So it's sometimes not always straightforward until you meet the person in person, and it's like, oh! you work at Walmart? Thanks for all those bugs Walmart! But they were all coming in under your personal account, you didn't have like @Walmart as associated with your name, so it's difficult to understand that.

But then other companies have come to Joyent and asked us, we really enjoy working with Node. What can we do for you? And the answer is always, always the same, participate in the community. First and foremost, if you're not participating in the community, we can't, everybody needs to understand who you are and why you want this thing.

So New Relic wanted to improve—wanted to have an agent for Node, and so they were working heavily with the community, working with Trevor, working with a whole bunch of other people to get features in there, and I spend a ton of time with Forrest when he was there and with Jacob Groundwater.

So it's a lot of time individually working with those companies when they have an idea for something that they need to do to provide around Node, and figuring out how can we do that for the broader ecosystem. So the first thing I tell companies who want to participate with Node more directly, is that it's not a Joyent question, it's a community question. Come to the community and start working with the community and start providing resources that you have.

You don't need to give those resources directly to anybody other than if you want to hire somebody to work on something that you have a need for. And that's the way I like to encourage it, because that's when it becomes the most transparent. It's most transparent when nobody is passing money around for anything, it's just like come here and do the work and everybody can collaborate on the work product that you have.

So, it's an exciting time, and we're actually getting—Walmart as I mentioned before, hired Chris Dickinson for specifically that purpose, and I got to work with Eran on when he was identifying who's out there, so make sure that we're going to make, they have the best opportunity to make an impact on core, and that's fantastic.

Paypal's also working with that. Progress Software, they're looking at getting people to participate in core as well for they want to improve the debugger, the source level debugger experience. So people come to me and ask about it, and it's just like OK, well let's look in the community, who's doing something already that way, and let's go talk to them, and figure out if they're going to be a good fit for you and a good fit for the community.

I'm going to go to the more common questions that I'm sure you've heard a million times. So. I'm just going to kind of group them. So for instance, the tooling that is in SmartOS, like when is MDB going to come to Linux because people would like that, or things like, what does Node 1.0 mean to you and when is that going to be, up to what the latest changes that you've made by removing the CLA, what is that going to do for the community, why is that good?

OK, so I want to
touch on the CLA as a first step. I don't know how many people even knew that Node had a CLA, and knew about news that Node removed the CLA?

OK, so good, so the CLA is a way that previously we kind of—hi phone— previously the CLA was a mechanism that you signed to say, hey! by the way, I don't hold any patents—any patents I hold on this it's not my fault, and I'm going to contribute this code and it's not. [inaudible audience] CLA's a contributor licence agreement which is not about anything other than, mostly around the patents that may or may not be held around the code.

We inherited a CLA that's pretty much right out of V8 from Google, and we just were like, hey! V8's doing this, we'll do this. It's mostly used as a tool if a project at some point in time wants to relicense itself. So like we may at one point time be like, OK, we decided we don't like MIT.

That's not going to happen. We love MIT, but we decide we don't want to do it, we want to release it under a new license, or we wanted to start dual licensing it. So the CLA offers the copyright holder to be able to do that kind of a mechanism. Since Node's never going to not be MIT, we decided we don't need to have a CLA anymore, so we don't have to worry about who actually around these patents. Also, most of the things that happen in Node and JavaScript in this part, not really patentable because it's not that interesting, the runtime, V8, Google, they certainly have claims that they can make around that stuff, we're just using straight operating system thin veneer so it's pretty straight forward, there's no real need for Node to have a CLA. The benefit is, we get to get contributions from anyone and anywhere now without them having to have a conversation with their legal department about it.

And so it's mostly a stumbling block for people working inside of companies. Part of the reason why we think we were seeing some of the people only contribute from personal accounts because they're like, I don't want to talk to my companies legal department because that seems like it's going to be pain, I'm just going to do it personally. So, by removing the CLA, they can say, I'm actually from XYZ company and I'm going to contribute to you.

And here it is, bye. That's great. So, we're trying to do that, we're trying to add that and continue to facilitate that.

Node 1.0.

So
with those contributions we're hoping to get Node to a fantastic place to call it 1.0, it's kind of depressing to have to have the conversation about a 1.0 and version numbers, I mean, I can just move the decimal place if that's going to make more people adopt Node, but I don't think that's really about that, and I do think it actually is about the tooling around that, and so we'll move that conversation in, people want to have confidence in Node.

I don't necessarily think it's about 1.0. So there's a lot of people working on tooling. MDB and DTrace are key to how I debug Node as a core team member on a day-to-day basis. That's all built into SmartOS/illumos, which comes from a Solaris heritage. MDB is really big in deep into that all ecosystem, as a piece of software, it's all open source but it's not easy to pull out of Illumos and then bring to Linux.

Canonical tried, they got about two or three weeks in and they said, we don't want to do that. So if somebody wants to do that, it can happen, it's just not happening on from our resources because it takes time and effort. DTrace, on the other hand, works on FreeBSD and OS X as well as SmartOS, and on FreeBSD Fedor got it to work, got the UStack helper, you don't have to know what that means, but got the UStack helper to actually work there as well, so a lot of the demos you see us do around DTrace, you can actually do on free BSD if SmartOS is a little bit too different for you, but that's where we kind of fall in from like we've built the tooling, it's all open source, it's all out there, Joyent writes an operating system and that's where that tooling happens to come from, it's part of the ecosystem of that. Core files from Linux actually can be brought over to MDB wherever MDB is running, so you can actually run Node --report on uncaughtException and do postmortem analysis on those core files without having to run Node on SmartOS. You just have to run MDB on SmartOS.

Yeah, on the MDB
thing, I'm relatively new to it did the DTrace workshop the other day.

But seems one of the things pretty cool cool about, is that I compare to say something like GDB, when you stop and you look at something you can see like JavaScript code, so it made me wonder if is there any work on the kind of V8 side of things, perhaps as in Google for providing some sort of debugger that can do that at least?

So we upstreamed a bunch of code to V8. A bunch of code, it's a Python script because their build system's Python, that actually goes through and adds a whole bunch of extra symbols to make it easy for MDB to attach and be able to browse through that address space. And so that's the work we did to make it in there, and that's the functionality in there is like, so what ends up happening, is we stick a whole bunch of symbols inside of V8's build system, and then when the process dies, all those symbols are actually in the heap space, and then MDB finds those symbols, and then makes assumptions, and then walks all the address space. That could all be done with LLDB or GDB or another tool that knows how to inspect address space information and interpret cores.

So it's not unique and all the code's opensource, so somebody could do all of that, it's just time and effort to do that. What I did—I mean, we also have, Joyent also has an object storage like S3 but has compute built in, so you can like upload the core file to it and then run a job directly on that, so it's like really automated kind of way of like actually just give me a report about the core file, so it's a little bit more straight forward to just be like, oh! give me this report and everything is going to work. I don't have to actually port a giant piece of software over here, I can just kind of like use this service, but there.

Cool.

I have no
idea for how long we've been doing this. I have a sense that we might be like just in time to actually go out and you can ask the questions in a more interactive fashion, and just everyone see what you're doing. So I'd like to close with just asking you all if there is anything else we didn't cover that you think is important, we're not going to talk about it right now but things can engage, people can engage with you outside, like so Internet of Things, I call people things now. Jonathan Lipps' talk was about this. If there's something that you feel was missing that people should know and that you want people to engage with you after, and finally if there's something that you just want to share, a personal plug so we can wrap it up.

I'm going to start with, Streams are the best. Nodes best control flow library is our flow control library, which is Streams. So if you haven't learned Streams, play with nodeschool Streams adventure, and start having fun. I can give you all kinds of keywords that will make you happy. If you're a functional kind of person and you like Monads or something like that, it starts to look like that.

If you like Unix shell pipelines, it looks a heck of a lot like that, but it's fantastic for the extract, transform, load kind of processes that are a lot of what you do with your applications. It's like, I've got this data source, it needs to go to this data sync in this particular format. That's a lot of what these implementations do, and you're like, I don't want to put 4 gigs of it into memory all at the same time, and that's where Streams is beneficial.

So if you want to learn more about that, you can talk to me about some of those fun things.

Check out the, I mean, if you
all want, check out the opensource libraries we have from Spumko labs from Walmart, hapi being the flagship one and Oceanario de Lisboa has loads of Cephalopods and they're awesome, cuttlefish y'all.

I'm going to end
on just a thought that I just want to, we've had a lot of stuff about community and great LXJS, and it was awesome.

It's something that we covered briefly during LXJS but I want to reiterate this point. It's been really awesome seeing Ben brought his wife over and there's a whole bunch of people starting to make us not just a community but like a little more family driven community type stuff, and that's cool for me because like I said in my presentation, remember what, more importantly like other people that aren't necessarily part of the community that you think will benefit, in particular, females. They are way, way too pushed off to the side, and that's not just a like, I've got one more girls involved in development because it's like I want to hang out with them. It needs to be a balance to bring this whole team together to make this really efficient, we want to be a strong community, you can't just be it by just having a group of guys sitting in a corner and being miserable.

And that has a lot to do with the way that you guys approach the subject, and you guys involved and, so I just want you to bear that in mind, bring other people. People that are going to benefit us, and don't just come yourself, bring other people and bring out lots of females because we're really short, and various things like that.

You get my point.

It's not sinister, it's actually, we're
trying to.

It's kind of sinister.

Not it's not sinister.

No, it's not at all, I'm joking.
But you get my point. I'm not going to go any further. That's my thing.

Rudi starts really beautiful and then it
just goes to very practical very fast, like, woah.

That was a very utilitarian
statement and I appreciate your utilitarianism it's just, we don't want to run them off in that statement.

OK all, thank you all for coming, and it's been lovely. I hope you had a good time and see you outside.
:

Sign up now for Instant Cloud Access Get Started