 I'm Clint Finley with Silicon Angle. We're here live with theCUBE, which is our live streaming show. We're in San Francisco today at the first Node Summit, which is an event dedicated to the new programming platform called Node.js, it's based on JavaScript. And I'm joined with two leaders from the Node.js community. We have Michael Rogers who organized a previous Node.js event called NodeConf. He's also the CEO of Pouch. And we also have Nuno Job, who wears a lot of hats. He does biz dev for Node.jitsu. He also has his own startup called ExpenseCat. And so in addition to all this other stuff these two guys are doing, they've recently started a firm called the NodeFirm. And we were the first to report on it at Silicon Angle, but I'll let you guys talk a little bit about what the NodeFirm is and why you felt it was needed. Sure, so we have this big problem in Node right now where adoption's just too much. Like it's just a rocket ship, right? It's a good problem to have. Like way too many people are using Node all at once. But it means that adoption is like by far outpacing available expertise. And it's just, it's not, you're not going to be able to hire enough people that really know Node well to build any new product nowadays really. You know, there's maybe three or four companies that have a lot of really good leaders from the Node community. And there's just not really enough other ones to go around. So what we started to think about was like, could we devise services for companies that have a great product team, have really good developers, they're just not that comfortable with Node yet. They're really good, they've been writing JavaScript forever or they've been writing Ruby forever and they're fantastic developers. But they're really just going to make a lot of early easy mistakes when they're taking on Node because they're going to bring a lot of the baggage from their other languages with them. So we created the NodeFirm so that a bunch of the leaders in the community could sort of sign up and do really sort of small bite-sized consulting kind of stuff where we don't write code for you and we don't leave it with you without the expertise to really maintain it. What we do instead is we offer some training services like just one day on-site trainings. We'll come in and advise you on any key decisions that you're going to make or if you want to use Node or you think that it's a good fit or it's not a good fit. We'll do code review, architectural overviews, little things like that that can really help you steer you in the right direction when you're sort of new with Node and eventually get your team to the point where they're the experts in Node and you don't even need our services anymore. But since you already have a full-time job, and you've got another startup, and everybody at the Node firm, which includes Tim Caswell, who are some of the other names that are... I mean, Isaac Schluter, author of NPM. We've got Chris Williams, who does JSConf, and he's also a founder at Safer Aging. Right, so all these guys, I mean, you guys clearly don't need the money. No, no. You're taking up a lot of extra time. It's easier ways to make money, yeah. So why are you doing it? So I think that we have time because our companies are committed to Node, and the success of Node is our personal success. So what we're trying to do is really to capture all this involvement in Node and funnel it in a way that just makes the ecosystem thrive. So our companies are behind us, and they want us to do that because it's good for Node. And they understand that the expertise they're lacking, as Michael said. So it's not like we're competing or doing services that other companies would do. We're actually creating something that doesn't exist and there's a real need for it. So our companies are behind us, and they see this as an excellent compliment. They actually are pleased that we're doing it. So the support from the community has been really great. Yeah, I mean, and everybody on that list writes open source modules in Node that a lot of people use every day. Most of the people on our list are actually known for writing really big Node modules that people use a lot. And just like doing that open source work and sort of putting value into the community, we also still have this problem where new developers are coming to it from these companies and we don't have a way to get to them and help them be successful with Node. And so what we really want to do is create a place where we can do that, where we can offer those kinds of services. And these people in the community, they're dedicated to Node. They're dedicated in their free time to Node, and they're dedicated enough to take a day off from work and go and do this other consulting thing if it's going to help people do better with Node. What sort of clients would you expect to have? I mean, are you thinking large enterprises or startups? So I can tell you like the kind of approaches we had so far. We already have like five to 10 emails of companies that are really serious about getting our services. And they're dramatically different to be surprising. For instance, we had talks with people that are trying to port a Facebook application that they run on PHP because they think that the streaming model is going to really help them deliver more music in real time. Or we have a large blogging network from Chile that might be interested in talking to us and actually migrate their things to Node, and they want to know that they can do it right, that it actually works, so they can get our expertise to actually know, so does this work, and how do we do it? How do we pull it off? So we think that enterprise will be more interested in this, so maybe telcos or energy, but we're at this point, not sure, but those are the kind of companies that are right now reaching out to us. Companies that want to migrate to Node, and they recognize that there is this gap, and they're like, okay, you're leveraging the gap that I was really afraid of. Please come here and help me do this. Your team can help us. Yeah, we've had a few people already make a comment, like, this is exactly what we need, actually, and I think we are going to stretch the scale between startups and enterprise, I think. I think we're going to get a few big customers that really want us to go in and do a training for like 30 people so that they can all learn Node, and then we're also going to get a lot of startups that really need architecture help or early code reviews so that they're not doing things that just aren't kind of best practices. But I think that the key difference here between our services and what you might hire traditional consulting services for and what we wouldn't fit into that is you need to have a development team of your own. Like, we're providing services that invest in your team. We're not providing the team for you, we're not writing the code for you. So, a lot of traditional consulting services go to people who have a great idea for a product or they might have a great design or they might have great content, but they don't have any developers, and so they hire a consulting firm to do that, and that's not what we're going to do at all. Do you have any precedent for this type of firm, like with any other language? I mean, it seems like a pretty novel idea. Not a lot of other languages, but I think some of the services that we provide are a fraction of what other consulting services have done in the past. Particular smaller consulting companies that tend to be involved in really early technologies, you know, like Boas Center's a very good friend of mine at Boku who runs like a very successful consulting firm and they're doing everything from WebGL, HTML5 games to, you know, like phenomenal new stuff with Backbone and they were one of the first people to sort of do stuff with Node and with Couch and they really like to invest in really new technologies and take really exciting contracts and they take longer term contracts, that's their business, but every once in a while they will do a training or, you know, they will just go in and do one day of onsite something for somebody because, you know, they get that opportunity, but they can't really specialize in it or only do it because, you know, they want to employ those people full time and they want to take on that other work and it's a lot of work to negotiate with companies who want to pay you to come in for a day, right, and having a lot of overhead in that negotiation and that billing process to do it, you know, hundreds of times a month or possibly is just not what they want to do, you know, like Boas definitely does not want to spend all this time doing, you know, accounting work. So a thing like, you're right that this is a novelty, but it's in a novelty in the sense that the community is running this. It is not necessarily a novelty in enterprise. If you look at enterprises that sell very well to enterprise markets, but because they are in such a tip top of the enterprise, there's not a lot of developers that know how to do that kind of technology. Well, those kind of companies, software companies normally provide professional services that look a lot like these to get people ramped up. So that exists a lot in the industry. It's just that normally there's like a big company that actually owns the technology that does these kind of things. And here you have kind of the inverted ways, like the community, the actual experts are scattered across different companies and the companies just agree that it's in everyone's benefit to actually go and still help the customer succeed, even though it's a technology that is still emerging. You mentioned one of the things that you, I would be able to help people out with are avoiding common pitfalls. What are some of the pitfalls or scenarios that you've seen a lot? I mean, certain things that you think would be really obvious by using the API a lot, really simple things, you know, like when I create a new API that takes a callback, it needs to have the standard callback parameter, you know, one error and one success result callback. And a lot of people, you know, they still won't use those in their own code. Like they'll use them constantly when they're using libraries, but then when they write their own code in their own API, they'll just, they'll never give it an argument or they'll pass it null when there's an error. And that's a really, really bad pattern to try and do. You can't mix and match that very well with the core API. You end up swallowing errors when you don't mean to. And you know, most importantly, you're not able to use a lot of the value that's being created on top of Node in the user community because you're not following the same patterns. A lot of other patterns that you see is that people end up rewriting things because they just didn't know about a library that's out there. You know, a lot of, I think, a lot of our early advisory stuff is gonna be telling people about D-Node or, you know, telling people about Socket.io and how you can integrate that with Redis and do sort of distributed real-time stuff. A lot of people just aren't comfortable enough knowing that these things exist and end up trying to go and rewrite them when there's a really good one that's really battle tested and being used across a bunch of companies in production that they just don't know about because it hasn't been big enough for their people to see it yet. Okay. Did you have anything, Adam? Yeah, there's also companies that wanna be more involved in the community because they feel like it's safer for them if they're heavily involved in the community and understand what's going on. And I think this kind of skill will complement what they have. They feel like they can do it but they feel like it would be good if they had an entry point to the community where they feel really safe. For instance, if they're doing a private NPM store, if they can talk to Isaac, well, Isaac can actually listen to them and help them not only set that up but he can only maybe reason about something that is missing on NPM that would allow people to have more private registries. So they can get that engagement point that they need in the community because these are open source modules. So they can hook up to open source modules that they could never do because they were just open sourcing some handle on the internet. Now they can meet this person and talk with them. So that's also something that people are, at least they told me that it looks very interesting about the node firm. Yeah, and we also hope that eventually a lot of this, the feedback that we get by having these new relationships with new startups and enterprises, we want to feed that information back into the community. Like I run a bunch of meetups and we're going to keep doing even more. I run a conference for node. Knowing what problems people are running into the most is going to be the best content to have at events like meetups and conferences and stuff like that so that we can start to spread this knowledge more. I mean, like one of the goals of the firm is that eventually any company that we work with won't have to use our services, you know? And hopefully in the future, like you won't even need services like this because the community will be so grown and involved that you can hire really good people and that everybody's connected. Okay, so node's been around for, seems like three years now about and this is the afternoon or the second day of this event. So there's certain things that we've probably heard a lot over and over again by now. So I'm kind of wondering what do you guys, what common misperceptions are you guys tired of hearing about? What errors are there in the community that you would like to interview, set people straight? Wow, so much. I think like one of the biggest things that I've heard over and over again is the event model. It's all about the event model. And I really think that most of the people that are talking about that are thinking about the event model from a different language. Because we have these asynchronous IO patterns in node, but when you're in node, when you sort of internalize the node way of doing things, the way that you think about the problem is actually like all IO is in callbacks. And all events are actually, when you call a mitt, that's like a blocking and memory operation and all the listeners have to do something right now and then you're gonna move on and do something else. And so events in node actually are this thing that's not entirely asynchronous. Like yes, when I add a listener to it, it's gonna happen sometime in the future, but calling that event is actually not deferred until later and doesn't enter into the event loop. Ah man, now I'm trying to think about a lot of other things that I have problems with and I should probably not get into too many of them. Yeah, I mean like, I think what I'm excited about is that people start focusing on problems that node can solve really well. Network problems that have like high traffic and that can really help companies like do businesses that they can't. I've already heard stories about companies that are trying, they have huge Java stacks and they just can't deliver as much information as they need to because of the impedance of all these huge frameworks. And node is just such a lean way of getting your network programs to deliver so much information. I'm super excited about that. So sometimes I don't get very excited when people go like and are doing something that versus it's very CPU intensive or it's just very huge case that you should just use a patches to serve static files, because it's already there and it's very solid or engine X, so that's kind of it. I think that the only other thing that I would bring up is that because the focus of the conference is on getting a lot of people in the business world and the venture capital world comfortable with node and understanding node, knowing about node, all the focus is on core and sort of like what node offers in core and as a technology and how that changes things. But there's an order of magnitude, more value being created right now on top of node in the module community and things like we have the best package manager that I've ever used across any language or platform before. And people haven't really mentioned it that much. This is like one of the reasons why I've heard people come to node is because this package manager is so nice and NPM is just amazing. And NPM has enabled us to build all these other great new modules like Socket.io, like Express, like Dnode. They solve all these amazing problems and we haven't spent a lot of time talking about that to some end. Well, we have to take a break now but thanks a lot for your time guys. Thank you. Good luck with the node frame. Yeah, thanks.