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.

TJ Fontaine @tjfontaine
Node.js Project Lead, Joyent

Gary Borton and Alex Vernacchia @vernacchia
Software Engineers, ExactTarget

Kevin Decker @kpdecker
Sr. Mobile Web Architect, Walmart

Reid Burke @reid
Senior Software Engineer, Platforms, Yahoo

Do you guys use Node to terminate TLS?

No, we do not.

OK, so what I
will say is that there aren't a lot of people who do terminate that, and some of that is just for good design purposes because the normal way I suggest people go to production with Node is a software load balancer on the logical machine and then a number of Node process per logical core, and usually that is what's handling the termination at that point in time. The other reason is that traditionally our performance hasn't been that great, we're getting a lot better, and if you're interested in that, I'd love for you to try 0.11 and give us some feedback and see if it's working for you better or not.

Cool, questions? Don't be afraid. TJ is not that bad

Yes Sir.

Stand up would you?

[xx] specific question about Yahoo, how
did you get in terms of processor how did you get [xx] to be a primary focus enough [xx] generally one of the products where we [xx] try to help everyone down the road, but you guys are [xx]

Yeah it always
has been, so you're question is about how it came to be that way?

So, yeah this may or may not answer your question, but yeah when I came to work on the team I work, this team's charter is to make tools for other engineers, and so yeah Yahoo is a big enough place we have thousands of engineers, and so it's really important that we have—we keep them as productive as possible.

There's a lot of things that we use that are open source that a lot of people understand. We don't have to reinvent the wheel, but there are a lot of things that only are problems at Yahoo. And so, my team focuses a lot on things that are kind of common. We look around the company, we talk to a lot of different people, and we see where common problems are; and then we work with them we don't just make our own things, we work with them to understand what they need. We sometimes will extend something they already wrote that's kind of something that they needed, and we kind of make that better for other people. Like my project that I work on right now is actually something that we needed for ourselves. My team needed it because we are the team that also maintains YUI and so since it's foundational, everything inside of yahoo to this day like we had to have a way for us to make sure that changes that are being made to it when we have such a small team don't break anywhere from IE11 all the way down to IE6, and so that's something that I worked on for a long time and as a result of that, though, which was successful like we have green builds and it's amazing, we made a tool that we are actually going to integrate with another team that's working with like CI stuff so anyway, I don't know if that answers your question like we basically—there's a lot of group at yahoo that just focused on developer needs, and that's really because developers are productive and we are going to have a lot better products.

Hi, I actually have a question, TJ you might be able to answer this, as Node is really going into more and more production environments and going into larger and larger organizations, how is it actually impacting your vision for Node, the future of Node, and then for you guys, within your organizations, is it becoming easier to convince people to use Node?

So it's a huge change for the Node project. We're at an excellent inflection point, where we're trying to maintain all these people who are coming in who need consistency and need stability from the project and need to have a vision of where it's going forward. And we need to be able to communicate that vision.

So part of what—when Node was a scrappy little start-up kind of project that everybody was playing with, it was easy for everybody to break things and just keep going with it, and be like, oh well, I guess we updated Node and it's broken again. Them's the breaks. But now we need to be able to go out there and say here's what we're doing in this release and here's why, it's because we have specific feedback from the people in the community who needed these features, and it needs to be data driven, and so having the enterprise and people who can consume at the scale that they do, has been incredibly helpful for Node.

So yeah, it's like an avalanche effect. Once we started, it just rolled from there and once we proved it was viable and we could support it in production, everybody was kind of on board since it makes a lot of people's lives easier.

We sort of had the
resistance at the start, but then once you do something with it the manager says, "that's really cool what else have you got?"

Eran and David have been kind of champions and then Walmart and Yahoo. Have you ever seen any sort of resistance to it in any capacity?

There was certainly a lot of it in the beginning, but I mean frankly since the Black Friday that Eran did very publicly, a lot of that resistance has gone away so we're all-in on Node right now.

Yeah at Yahoo there
was no one event that like really had Node start to replace legacy platforms or hosted applications, but I think it's—what kind of started it was Yahoo used Node a lot in the beginning for things that run on like typically on your computer, right?

And then it kind of grew from there, so I think it's really great that Node has put a big priority on not just will it work well in a server environment but also on a client environment, so it really grew from there and we built more libraries, and once we had that and it was production certified, and then people started using it, and it's been great, for the things we use it for.

Next questions. Yeah please stand up.

Just curious if at
Joyent, if you guys know if coming down the line we can expect an improvements in like the Node debugging, because in my experience debugging client side JavaScript code through browsers, that debugger is seamless, but whenever I debug using server side, that's usually pretty slow and I've made my way around it and I can do a lot of print lines and what not but [xx].

Yeah, so
are there things in the pipeline to help debugging around Node and I think you highlighted the point I mean it was theirs that the fact that Node is a asynchronous is usually doing all these asynchronous events in play at the same time, makes it really difficult from a debugging aspect to be able to like, I'm just going to track this one request as it's happening.

That makes it a particularly difficult experience. So Node itself has a built-in debugger that you can use to attach to the Node inspector which gives you the front end kind of experience but it's still not quite the same thing. What we've done from a tooling aspect, we're not the only ones developing touring around this, but Joyent has developed touring around MDB which was mentioned a couple of times up here and Dtrace the ability to either from postmortem analysis, come in from a core file, and say show me the state and show me where it was, and I can ask questions about the state and reconstruct it and know the results, or from Dtrace be able to ask questions of the running process, and be like, I want to trace this portion of it, and that's kind of why we are adding the dynamic tracing into Node in 0.12, so you can instrument your own code in a way that's not quite print line or console logging, so much as it is being able to get analytics around your application, because it's often about the aggregate information.

But there are a lot of people excited about that, because basically you want to know how do I run Node, how do I keep it running, and how do I find out what it's doing while it's running, and those are the three most common questions I've heard on the Node on the Road stuff, and so everybody is working hard on making that better for the end user.

Yes, sir.

[audience question]

That's a question for you man.

I come back to Ohio all
the time, I'm from here so

I told you TJ is
my best friend, he comes all the time. Locally, you guys, we do Node meetups every month in Cincinnati and Node meetups in Indianapolis. We manage both of those groups.

Not only that but Modulus is actually working on having a weekly open office hour, open happy hour where you can come hang out with us, talk about technology, have a couple of drinks but really stay engaged in what we're doing and we want to really stay engaged with what you're doing, because nothing is more important than the community and as TJ talked about earlier, TJ how important contributions from the community?

They are incredibly important. I wouldn't be able to do it without all of you. I fill like we're on a PBS or NPR kind of thing…

He spends most of his time…

Powered by viewers like you.

TJ spends most of his time jet setting around the country, so he doesn't work on Node that much, but when he does it's great. Other questions.


I don't
think that we really get that exact target.

We use a lot of different services honestly. For most of our data crunching we used Hadoop and Java, so we don't do a lot of that kind of thing with Node.

So I
think, basically—you touched on it. Here's how I will tell you how to solve it. Make a different service that does the CPU bound thing, and then shunt it off to that and push it off to that, or have a pool of workers that you can distribute those tasks to.

That's basically the standard model for how to do it. Another way is depending on what it is you're interacting with, a binary module, and then interacting with threads at the native layer, there have been conversations, and JavaScript as a language and V8 as a run time, have been adding ideas that potentially in the future for Node make it interesting to have thread-like models in JavaScript, so in the future there will be a way to do something like that probably, but for right now, push it off to a separate service, or a separate process that can manage that on its own.

That was a great
question. Yes, sir.

I'd like to know if anybody is
using queues. I noticed that the queue packages aren't very well supported I guess.

When you say queue we're talking ordering
mechanism or we're talking queue like promise libraries? Mesos Queue, so like AMQP, stuff like that. You guys using AMQP?

That's not true Walmart.

myself am not using it.

I don't use it, but
we don't use Node for that, we use something else for that, and typically like was already said we interface with that other service in the ways I've already described, yeah. Or something else, we have also—depends on really what service is being used, but sometimes we do something that's native, we have a native binding for something that's used across many different things, different languages or platforms at Yahoo or HTTP. It depends on what it is.

Joyent uses AMQP through its orchestration layer. It's one of the things that we do. Walmart does, even though Kevin doesn't exactly use it himself, Walmart also uses AMQP under the hood, and there are other people who do other kinds of message libraries, so like there's a ZeroMQ binding out there that people use as well. So it's all about what you want to use, how you want to approach it but there're plenty of people who are using Node as messaging layer and then subscribing to Pub/Sub kind of queue mechanisms.

It's our bread and butter. I think.

Yes sir.

Do you guys use and specific metrics? [xx]

Did you
guys use metrics to prove that Node was a viable thing?

Yeah, so in our
first production app it actually used New Relic to monitor all this, and then we kind of switched to a product called Nodetime which we use now which is kind of like the AppDynamics product.

But yeah, it gave us all the information necessary in order to prove that we could do this, and as long as we do our jobs well, I guess, like errors and everything like that guess it went pretty well.

How much did New
Relic or Nodetime, how did it impact the performance of the application that you're using?

Did it impact it?

The first couple of versions of New Relic, it did impact it a little bit and then from there it got better and then, Nodetime, we started using it after all those problems. So it doesn't really impact what we do much and we're able to actually do all this without a lot of overhead.

I think that what they
are highlighting there is that when you're going to get metrics about Node, or anything about your application, do your best to not observe that from inside the process because you have the observer effects.

So you actually want to be looking for platforms, and products that actually help you get that information without changing the performance of the application.



Are any of you using ES6 features or harmony?

Only personally. Not at work, no.

In production, we don't use
anything that requires the harmony flag. We're just not yet comfortable with that.

We are, but not with Node so, yeah.

And you are on the standards committee now right?

That's right.

How do you feel about—I
mean how fun is it working with harmony standards committee?

It's very fun.


Yes sir.

So you guys talked about [xx]. When would you definitely not want to use Node?

Really good question.

When should you not use Node?
I can't figure out why anyone would ask that question. I think one of the easy things is I get to pick to pick on JavaScript a lot, so if like what you were looking to do is like a financial software that needed to do a lot of high precision math: probably not the right language, and therefore Node is also not the right fit for that, unless you're going to shunt it off into a binary module or something like that. Up and until the language supports a way to do that kind of stuff, but then also really CPU bound work is not something that you actually want to do in Node more often than not, I mean V8 is pretty awesome and sometimes you're like, this is going to be really bad, I'm just going to put it in Node and it's going to turn out and then V8 is like oh actually I got that for you, no worries. But other times it's actually a problem. I think what I've mentioned here with the guys and then in the mixer beforehand is like write code that you want to maintain, so if you are comfortable with Node try it in Node and if it works it works. If you're comfortable with some other language or some other environment, write it in that. Don't force yourself into Node just because it's the hot new thing.

Which it is.
TJ is the hot new thing. I actually have a silly question for you guys and I want an opinion from everybody. I'm not a Node expert, but I want to build something with Node.js. I want to use MongoDB and Redis, or maybe one or the other, right. What project should I pursue or what should I try to do with it so it's not exceptionally difficult for me and it doesn't frustrate me, but I can see the benefits of it?

Oh wow, don't look at me first.

If you're
not comfortable with using Node, obviously there's a lot of open source projects out there that do use it, so I would say probably just start small, like don't shoot for the moon and say I want Mongo DB and Redis right away. Do the standard Hello World app and then and go from there.

So I would actually say like, a lot of people use Node for web servers right, but that's not the only thing that it can be used for, so I mean everybody has this Express set up and the stuff that they use on a regular basis, but for someone starting maybe that's not the best way to actually go. Like Gary said, you can run a command line too, you don't have to start a server, so why not just start there, and just go from there I guess?

I look at it—find something that you're interested in doing, so if there is some kind of website that really thought that what it did, try and implement it on your own, or just from the sheer, like, if I wanted to re-implement the service, how would I do it? Maybe you're like, I don't like Reddit, or Hacker News, which Hacker News doesn't like us.

So go out and try and implement something that you use on a regular basis in terms of Node, if you're just trying to get your feet wet with the ecosystem.

You typically need, because you
are probably building something already, whether it's an app or a website or something else. And so how I got started with it, how Yahoo got started with it again was DevTools, and so that's something some people might overlook.

They're like, oh I can make this app, but yeah, I'd start there, because you probably already need something done for your app already, and since it's really easy to get started with, have your engineers install it. It's an easy dependency, simple. Yes.

I'd say that was my gateway as
well, was using JavaScript to create our front end build tooling, and you can throw Mongo in there if you want, but I don't think it's helpful.

Guys more questions? Yes sir.

Just one question.
I was curious how selective you guys are about the npm [xx] so I was curious how selective you are, and how [xx].

would say make sure that you know everything that you're pulling in. It depends on who the author is, and how strict they are or what level versioning you want to do.

Sometimes if it's a developer time build tool, you're fine with a relaxed versioning that's basic [xx], but anything in production you may want to look more towards a more restrictive set of versions. But generally know the code that you're putting in, which is actually a benefit of having some of the smaller libraries because it's very easy to consume a one file substack module.

Yeah that's a really good question I'd like to answer it a little bit more about what we do at yahoo. So like I said, we have something that's built on top of NPM, and we have a registry counterpart to that, and so we have a whitelist and so if you're going to use something in production, it goes through and actually we have, it goes into our bug queue and then its reviewed and if it's anything that does—there's about a dozen people that volunteer their time, there's no team that does it it's just people.

Will go and look at something and just do a sanity check. Is this thing licensed really well. Like is it, having that defined, that's really important, you have to make sure that isn't really just another version of something that's in five other places that's already being used. If there's anything that's security-related we defer it to someone that knows—a security reviewer that can look at that and be more than just us taking a look at the code and making sure it's something that we want to have in production, and so yeah we do look at all the code that comes in that we use in production. And then another thing is we have a lot of scrutiny for what goes into prod but something that YNPM does, is it makes sure that the things that are kind of our whole build pipeline does, is it makes sure that nothing, there's no way you can manually install anything that's not there. So you can't just put like a github tar url, or a tarball or something else.

It has to be coming from our registry, and so that means that like what we noticed is we started doing whitelists for everything and that was bad because a lot of people, so many people, there's a lot of request for things that are probably OK for use on your local machine, or in your CI environment but not for production, and so we really try to focus our time because we can control what goes into production and not, it's like see if we can prune out dev dependencies, right.

So dev dependencies don't have to go through that same process. That's quite as expensive if you will, like it takes longer to keep—so that developers can just use their stuff locally, or before production itself.

There was a little bit of talk about CI and CD. How do you guys maintain consistency
between your build servers and like your deployment servers. So like when Node .12 finally comes [xx]

How do you keep consistency between your build servers and your deploy servers?

Yeah, so we have, just basically
you can think of them as containers and so we wind up testing—we don't just install a Node version, we have a container that has a Node version plus the OS, right as like one thing. So that same snapshot then is what winds up—so we wind up testing on a very similar—plus there's also typically a stage where you're not just running test in a VM, you're actually—you deploy the thing to a preproduction environment then test that thing, that's where it's not in the same space.

You guy's have any?

I mean as far
as locking down like our runtimes between build and production environment, I'm not sure that we're there yet. I do know that in the runtime in our production and Q&A environments is controlled by our PaaS.

A PaaS is a very valid way to handle that kind of conversation. So, coming in the future for Node, just so you can talk about beyond 0.12 even.

We're going to add bundling as a first class feature ,so if you actually chose to deploy your application this way, you could just point Node at the package.json of your application at top level, and then compile it all into a single binary and then you can distribute that single binary to your server and then run that binary, and then just go to town with it. So that's an option that's going to coming in the future.

I've been looking for use cases for Node. Lets say I'm just trying to see, do you guys publish like where can I find information about the impact of Node in a production environment or just in general?

So there are all
kinds of places that collate that information. I'm looking to change the blog for Node.js to actually keep use cases from companies like Walmart, Yahoo, Paypal, etc. ExactTarget if you guys are interested [wink,wink,nudge,nudge].

That's some of the places that we do that. Other companies, Joyent has done some work with companies on use-cases that they put out as publications.

No, but that's a really good idea.

I've seen some stuff from
Walmart. You guys are pretty vocal about what's going on. Does Yahoo maintain it. Does somebody actually write about it or keep track of them?

Yeah, check out there's a Yahoo engineering Tumbler and you can just search for it and you talk a lot about not just Node but lately Node's been featured on there a couple of times last year, so very cool, yeah.

Yes sir.

I was wondering if you guys would all recommend a process manager. Like what do you use to fire up Node instances, keep them running, [xx].

we use—our PaaS does it all for us. If Node's instances go down, it starts it right back up and then we can scale right from there, so it's actually pretty easy for what we do just with the product we use.

We use bash.

That was—apparently the PA does not like bash.

So right now it's just bash
with a load balancer in front. If one goes down, we actually just leave it down right now, we're working at doing automated collection of cores and logs so we can restart them, but we have a large number of servers in front of it, so if one goes down outside of the middle of black Friday, or even the middle of black Friday, we don't really care that much. But our ops team is looking at ways to making us much better situation.

Yeah, in production at Yahoo, Node
always sits behind the load balancer, and there's always two logical hosts behind those or more. And then behind that, there could also be different colos, and so a common thing, no matter what platform at Yahoo, we want to make sure there's a consistent way you can check the help if something's up and it's still running, and if something ever goes down it's automatically taken out of the rotation by the balancers. So that's how we handle it in prod and then locally on the box there's something that runs external that's not in Node that watches Node and makes sure that it keeps running.

What is that something?

Yeah, that something for us is proprietary, but… Which is why I didn't talk about it, but that's the idea right. So what I would say though is be careful in writing it in Node, and we have done it both ways with Node and without, and it's, I think really I kind of like the simplicity of just using bash and let's, like it really doesn't have to be that difficult or that hard. A lot of operating systems provide—SmartOS provides a way to restart—whenever I need to use SmartOS for anything just personally, I wind up just, it just restarts things if they ever crash.

So that's great. There's an option that turn that on as a service and there's other, like no matter what flavor of Linux or whatever you decide to use. Probably a way you can tell it to restart on a crash and then rotate out cores, if you're dumping them, or whatever else, so even though it's like what we do is special, like it's not really that complicated, so I think it get's more interesting when you have like different hosts and other things, and that's why our load balancer just checks, and makes sure that all that stuff's up, and will just remove it if it's not up or under-performing, so that's the idea.

I want to augment just a little bit to that, just like do what feels comfortable for your operations team. So opting in to the operating system's solution for that is usually good. Like systemd, upstart, on SmartOS it's called SMF. Those kinds of things are actually good. Usually the operating systems will provide mechanisms to handle that.

On SmartOS part of that process management is built into the kernel, because there's always the question of who watches the watcher, and in that particular case, that's why they made this decision that way. So it's important, like when you are making those decisions, whose going to supervise these processes? What level of consistency and reliability do you need from that mechanism?

That's great advice.

Thanks Reid, I'm glad we brought you along.

[audience question]

The question is what's going to destroy Node?


Is there any sort of
vision that's starting to blossom.

So there a lot of
people out there building and—so what would make Node, what might happen externally that targets Node that might prosper? OK, there are a lot of people out there doing very interesting things, and I will highlight a couple, well at least one in particular.

There's a company called LineRate that was bought by F5, and they sell a switch that is FreeBSD with Node smack in the middle of it, where you can do layer 7 switching based in terms of JavaScript. You can either just write a web app in your switch so you can have really, really low latency for some reason that you really need that, or you just want to extend your switch in terms of JavaScript, and that's one of the ways we are seeing people is taking Node into an embedded environment and exposing JavaScript and our common and APIs and our abstractions, that people have found themselves successful with and are using it in all kinds of ways, from an embedded perspective. And another thing is Node has had a huge impact in JavaScript back in the proper community, so we were created out of the JavaScript community to be server side JavaScript and then we created our own abstractions to fill our needs and those things are coming back out to the front end, so there is work around the streams API that's influenced by what Node has done from streams, so its kind of a give and take. It may not necessarily be that people are building off of Node and being a huge big thing around Node, so much as Node as being a positive influence back on everybody else.

Yes sir.

I have a question about module discoverability.
One of the things that I've noticed like for example [xx] three or four different modules that are more or less the same thing and it's kind of hard to tell, which one's good which one's bad, and I ended up actually rewriting my code three times because the first two modules I tried didn't quite work out. So I guess my question is what's a good way to figure out which module I should use [xx].

Trial and
error, it really comes down to that. Like for the most part I have re-written the code four to five times because I couldn't find the right one. I haven't found a good way. If you do, let me know, it would be great.

It's a
popularity contest which is unfortunate, but if I see there's a particular module from a group of people that I trust and I know their code, like Michael or substack, I tend to opt for whatever they have implemented. Outside of that if they're just completely random, I don't know anything about the maintainers, I may look at the NPM install logs and things like that and see which ones are popular. The other metric I tend to look at is the last time a commit occurred. If something is not actively maintained, it could be that it's complete, or it could be that it's abandoned, and its hard to tell.

I'll add one heuristic, which is check the test directory. If it's present, good, and then if it is, then also read the tests. If it's easy to read, if you can choose between different ones, if it's easy to read it's typically—that combined with everything else I've said, is a good heuristic. But it's trial and error.

I think the only other thing
I would add on top of that is actually look at the code, because it may, with open source, it may be that you are accepting that as a dependency that you're going to pick to maintain going forward, so if you look at that code and you don't like the idea of maintaining that in the future, then don't pick that as a solution. So the nature of open source, every dependency that you pick may be yours to own going forward, because it may end up being abandonware, so if you have an aversion to coffeescript and it's coffeescript, you probably don't want to do that.

OK, you and then Matt. No you, you come on.

How do you feel about full stack frameworks like Meteor?
How do you feel about full stack frameworks like Meteor?

I think they are cool. I mean, I have only used it in personal projects, and we have even brought it up at our company, but I think it's cool what it's doing, and I mean I would love to use it later.

I'd say just like anything else, there is a right time and place for tools. I haven't been able to use Meteor or anything similar for my own projects. The main reason for that is the scale that we have to deal with and also the legacy systems that we have to integrate with.

We have some systems that are 10 years old, that unfortunately are kind of important. So it's based off of your environment and requirements.

Most evolution at Yahoo happens incrementally, and so even for new projects that are typically built on existing platforms. So, yeah, that's not just limited to Meteor, but why not just replacing like something wholesale.

I mean, I
want people to be successful with Node in any way. Meteor is a little bit of a different beast than some of the other ones that are out there, but build software that you want to maintain and stacks that you want to use.

It's the best advice I can give anybody, and I'm excited to see more of them come out, because a lot of people want to approach Node like it's Rails, and that's not what I would tell you to do, but if that's what you want then you should be able to find those kinds of solutions.

We'll do Matt and then you sir.

[audience question]

Are any other organizations using a private registry?
We are actually getting started to bring one up, yeah, so it's on our list of things to do because we have security concerns also, so hopefully we'll be able to mitigate those with our own registry.

It's hard to do I
can't really comment more than that.

We, Joyent maintains a
private registry insofar as we have we have an internal git that we use for our private modules that are not public.

I mean that's the way we handle it, I mean also you could—Node doesn't really care how the module gets on disc so long as it gets there, so sometimes it will be a module that is delivered in alternate mechanism like a tarball that gets unwrapped and put into the Node modules directory. So sometimes they happen in different ways.

So probably the wrong crowd, but being a Java guy, have any of you looked at [xx] implementing Node on the JVM.

Have you looked on implementing Node on a JV?

No. Not since Rhino.

Wow, and that's a throw back,


looked at it. What I want is for people—this kind of go back to the idea like Node as the common tongue for a lot of people, insofar as JavaScript is the common language of the web, Node's APIs being a common way to speak to each other would be an awesome thing. What scares me about some of those approaches is that they don't always end up being as compatible with Node as they could be, so what I would want from those communities is to be able to work with us on getting an environment that makes it easier to target different runtimes.

So if we can get an abstraction that's right for Node, that we can support and maintain for other people, then it's really easy for us to support anything. It could be the JVM, it could be Spidermonkey, it could be JavaScriptCore all those kinds of things. So we're looking to find a way to embed Node's APIs in a sensible way that helps all of the community, is what I would like to see.

Yes sir.

[audience question]

So the
question is how do you see Node with the Internet of Things?

We are seeing the start of a huge adoption from people who want to do it, because of the way they are like we can just speak HTTP to a bunch of things and put a REST server on this embedded device. And you have things like the Tessel which is actually it's Raspberry Pi-based, like the idea is just like we're just going to put Node on there with the APIs, and then you just use JavaScript to program this little embedded device. It's fantastic. So we're starting to see it pick up a lot from not just hobbyists from like NodeCopters and NodeBots kind of things, but actual serious companies who are picking it up to put it in sensors, and to go and to use Node as that mechanism because it lowers the development process for engineering resources, like we don't need everybody with an EE to come program these sensors, we can actually go and do it.

We had a Boston company called Koko Fit, where they are a franchise fitness club, where they actually—every one of their fitness devices has an embedded computer there that has Node for two reasons. One to communicate over serial to the actual device to get events out of like how fast your reps are going and all that kind of nonsense, and then actually rendering the results of that back to you, and sending it off to the cloud, so it's like Node is this thing that powers fitness for a bunch of people, which I know I could…

So it's exciting, and there are a lot of people who are using it for all those kinds of things, and being based on V8 and working on ARM makes it really easy for Node to just kind of get dumped in these environment like that, or Atom or Celeron kinds of things with low power Intel also works.

Cool any other questions?

Allright guys well, we appreciate
everybody's time and you coming out. The one thing I will ask everybody on the panel is we'll go this way. What would you want everyone to take away about your use with Node, using Node in your organization or just if they want to get into it?

Yeah, so if
you're new to Node and never used it before, you're probably here because you work with software and know someone who does.

So just start with something that—it's very easy to get started. Just start with something that you probably already planned to make. It doesn't have to be too crazy, and if your needs change, and you find yourself going over to making an application in Node, there's a lot of resources out there. There's a lot of talks that are not from just big enterprises and a lot of resources from people who are at all, kind of, everywhere around the spectrum. So yeah, like I think that just figure out what works for your business, and just for hacking on stuff. I have experimented a lot with NodeCopter kind of stuff and it's awesome. I do that in my free time, and also at yahoo a little bit.

I'd say for
me Node is an amazing thing if you enjoy working in JavaScript. If you like the paradigms of the language, it gives you another vector that you can deploy that language. It's not fit for every task, but we found that many of them are, at least in the web development domain and also the fun crazy hacking domain.

And it's also we are proving that it is ready for production, and it's not this side project that has a couple of people hacking on it, so I think it has a bright future.

Well one of the biggest
boons to using Node for me at ExactTarget, is the rapid prototyping that we can do. So if we come up with a concept we can easily, I mean very, very quickly, we run the generator, we have an app, we've got the proxy in place. So go with the generators. Go to NPM. Look through some of the modules. Sort of experiment and see what you can recreate that is difficult in one language but very, very easy in Node.

Yes I would say, I would actually start with tooling. For the most part, there's always repetitive tasks that you're going to be doing for the most part, and see if you can kind of run it without using some task runner like grunt or gulp or something like that. See if you can kind of go that way, but, other than that, I'd say you really have to kind of evaluate what your situation is, and if Node is a viable path, and if it's not, then don't use it, but if it is, then at it.

Absolutely. Go out there and have fun with Node. That's what I want everybody to do. Go have fun with Node. Thank you I spend all the other time being deep. I just want to be surface level.

TJ is very deep everybody. But yeah go out, have fun, try it and just build cool shit. That's pretty much the point.

You just did the tl;dr
of all that. If you had the answer, why didn't you just answer it?

Guys I'm not the expert. Alright guys, we're going to spend a few minutes around here if you want to say bye to your friends or maybe catch up quickly with these guys, but then we're going to walk over to [xx] which is two blocks that way. Feel free to join us; open bar, pizza. That already sold me. Once again, thanks to our sponsors Joyent and Modulus, I hope you guys enjoyed the night, thank you for coming out.


Sign up now for Instant Cloud Access Get Started