 off from work and go and do this other consulting thing, if it's going to help people do better with them. What sort of clients would you expect to have? I mean, are you thinking large enterprises or startups? So I can tell you 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 pour to 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. And 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 or 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. Particularly smaller consulting companies that tend to be involved in really early technologies like Boas Sender is a very good friend of mine at Boku who runs a very successful consulting firm and they're doing everything from webGL, HTML5 games to 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 they will just go in and do one day of onsite something for somebody because they get that opportunity but they can't really specialize in it or only do it because 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 and having a lot of overhead in that negotiation and that billing process to do it hundreds of times a month or possibly is just not what they want to do. Boas definitely does not want to spend all this time doing accounting work. So a thing like you're right that this is a novelty but it's an 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 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 or avoiding common pitfalls. What are some of the pitfalls or scenarios that you've seen a lot? Certain things that you think would be really obvious by using the API a lot, really simple things. Like when I create a new API that takes a callback it needs to have the standard callback parameter, one error and one success result callback. And a lot of people, they still won't use those in their own code. They'll use them constantly when they're using libraries but then when they write their own code in their own API they'll never give it an argument or they'll pass it and know 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 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. A lot of, I think a lot of our early advisory stuff is going to be telling people about D-Node or telling people about Socket.io and how you can integrate that with Redis and do 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 out of it? Yeah, there's also companies that want to 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 couldn't ever 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, or 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 doing, 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, one of the goals of the firm is that eventually any company that we work with won't have to use our services. 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. 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 maybe set people straight? Wow, so much. I think 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 MIT, 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. 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 Nginx 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 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 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, Express, like D-Node, 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 firm. Yeah, thanks. Hi, I'm Clint Finley with Silicon Angle. We're here live on theCUBE, which is our streaming broadcast internet TV show. We cover all the latest and greatest in technology today. We're in San Francisco at the first Node Summit which is dedicated to Node.js which is an emerging development platform. I'm joined today by Arnot Kazimier. He's the founder of Observit. Arnot, can you tell us a little bit about Observit? Observit is a real-time analytics service that's not analyzing your website but your users. So you actually insert one line of code in your page and you can see the user's mouse everywhere on your page and see the clicks and scroll down the page and you see it reflected on your own browser. So it's just like watching over the shoulder of your user. And so would you compile a lot of statistics from this or is this just, you record a lot of the interactions? Sort of, how does the end user who's analyzing the traffic, how do they use it? We were sending all the events to our backend and then you can replay it, just like separate session or it gets aggregated as heat maps. Okay. And so you are one of the winners of Node Knockout, the most recent Node.js development competition. Which categories did you win in? We won overall, solo and utility. So you developed the original one solo all in your own? And solo. Okay. What's your background before starting this project? I'm originally a designer and then I moved from designing to the front end and then when Node started getting extraction, I moved to Node. So you're solving a sort of problem that you would face then as a web developer wanting to know how people are interacting with sites and applications. Yeah, how they're doing on his site and what is working, what is not working. How user are converting on a website as well. How does, how do you use Node.js in this? Our complete services runs on Node.js. We're using Socket.io for the real-time connection between the user and our server. And we're using Node.canvas to generate hitmaps and we're using the queue service from LearnBoost to process all the information in real-time. Is this something that the end user has to opt into or is this something that it just, it just starts getting recorded? It just starts getting recorded. So you have to put a little privacy notes in your page that user might be monitoring. And so this is all done in JavaScript. So there's nothing that the end user has to even download. It's just part of. There's one line of coding in your page and you're done. How old does it perform then? Does it slow the site down? It doesn't slow down the site because we're using WebSockets to send over the information. But of course you have a little performance in because you have to download one access script on your page. Well, what about on the user's end? Is it, does it? You won't feel any latency when you're moving around on a page. Will it increase the CPU usage or anything like that? No, not a bit. Maybe like one, two percent. It's not noticeable. Where are you going with this application now? I know you're part of the node competition here. So are you looking for funding? Do you have funding? We're definitely looking for funding. We're currently just bootstrapping the application. We're just, we're hoping to build it out as a complete service. And by looking for investors, we can just push out the public release sooner. What's the business model going to look like? Will this be sort of a freemium service that people can, you know, you have an entry level tier? Yeah, we have an entry level that's like 100 recordings and then you have to pay for a monthly fee. Okay. What's on your roadmap for the development? Is there any, do you have any longer term vision for what else you want to do with it? Yeah, we definitely want to continue aggregating the data and getting more useful data out of it, like where your users are dropping, so you don't have to follow one session to find out, but just aggregate a few of possible interesting sessions for you. And we want to go mobile. It's the new hot thing, so following touches and relating that as well. Okay, so I want to go back a little bit to your background, because you said you started out as a designer and then you started doing front-end development and now you're doing back-end development with Node. How hard were each of those transitions? From designing to front-end was quite easy because I just always wanted to have my designs pixel-perfect, so you just have to do it yourself if you want the pixel-perfect webpages. And then, yeah, Node came and I just wanted to move on, keep on learning, and with just a smooth transition from front-end to back-end. It's just the same language everywhere which made it really easy to work with. Is the whole call-back model, is that hard to learn? I don't think so. It's just something to get used to, but once you know how it works and what kind of issue you are going to run into, like these funky coal stack trees with nested coal packs everywhere, because if you just know how to avoid it, it's just simple. Were there, as you were developing, observe it, did you run into any big stumbling blocks with Node or did everything just work pretty seamlessly? The only problem that we had was with hosting that are not all supporting WebSockets, so that's something we were bumping against because the WebSockets spec kept changing and changing and not every hosting company can keep updating their stack to support the current WebSockets. Right, and not all browsers. Well, all the major browsers supporting WebSockets now, I know Mozilla took it out for a while, but they put it back in. Opera is supporting it now. Opera is supporting it, Chrome, Safari. Has the development of its stabilized end of the spec? The spec is finalized, so that's great news. But there are always some issues with cross-browser support, even with WebSockets, there are bugs everywhere. So it's just got to be aware of those issues. So that seems more like it's more of a front-end issue rather than a Node.js issue. It's not a front-end issue. Yeah, but you also make sure that your back-end of Node is up-to-date with the different WebSockets protocols. Of course, we've got really old versions of Safari, that's using like the RAV75 and the newer one using the latest WebSockets specifications and you want to support them all to have a great browser support range. Okay, well, that's all the questions I have. Is there anything else you wanted to let our viewers know about? No, they can sign up for a beta on beta.observe.it. And we're rolling out beta next week, slowly. Great, well, good luck with the beta. Yeah, thanks. We're gonna take a break.