[nodejs] Re: Just started used node, is something like this possible and how?

2013-11-06 Thread Floby 
maybe not *what* you are trying to do, but definitely *how* :)

On Monday, 4 November 2013 21:29:37 UTC+1, Matthew Sudol wrote:
>
> @Floby - termkit looks cool but that's not really what I'm looking to do.
>
> @Mark - thanks for the info, i've got a handle on exec now, all that's 
> left for me to do is figure out a way to 1 - 1 map my client side in the 
> browser to the spawned bash script (which runs until I tell it to stop) - 
> the bash script is going to receive PINGs from the browser and return PONGs 
> - my goal is that each browser that connects to node spawns that bash 
> script in its own process and then they start talking to each other.  I 
> think I've got a good handle on it now.
>

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Re: Just started used node, is something like this possible and how?

2013-11-06 Thread Angel Java Lopez 
Matthew

English is not my language, so I'm a bit confused.

In your first messages, you wrote:

"client (web browser) -> connects to node app, with socket.io -> spawns
child process that runs an application on the host  -> application sends
message back to node app (unix sockets?) -> node app returns message to the
client that spawned the process -> client and application are now sending
and receiving messages to each other.

In this application the "app" could be something as simple as a bash script
that just echoes back whatever messages was sent from the browser as part
of a form input."

Mark Hahn mentioned child_process exec
http://nodejs.org/api/child_process.html#child_process_child_process_exec_command_options_callback

I didn't try it. But the limitation is that the stdout is given at the end
of the process (I guess) and you need the output at any new line (maybe),
meanwhile the child process could run for hours. And then send the child
process output (a line?) back to the client that remotely spawned the child
process. Maybe you need
http://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_options
to listen to the output, not at end. (take into account that some programs
don't give the output while running, only at end; I see C programs without
calling flush())

Why now you are using require('net')? Where is the spawned process? Or you
have ONLY one external process to attend all the clients?

Angel "Java" Lopez
@ajlopez



On Wed, Nov 6, 2013 at 5:57 AM, Floby  wrote:

> maybe not *what* you are trying to do, but definitely *how* :)
>
>
> On Monday, 4 November 2013 21:29:37 UTC+1, Matthew Sudol wrote:
>>
>> @Floby - termkit looks cool but that's not really what I'm looking to do.
>>
>> @Mark - thanks for the info, i've got a handle on exec now, all that's
>> left for me to do is figure out a way to 1 - 1 map my client side in the
>> browser to the spawned bash script (which runs until I tell it to stop) -
>> the bash script is going to receive PINGs from the browser and return PONGs
>> - my goal is that each browser that connects to node spawns that bash
>> script in its own process and then they start talking to each other.  I
>> think I've got a good handle on it now.
>>
>  --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[nodejs] Re: What do people do for versionizing node modules within git?

2013-11-06 Thread Will 
For the Googlers of the future that reach this thread: the answer depends 
on the nature of your project.

   - *Do** track* `node_modules` in your repo if you are deploying an app.
   - *Do not** track* `node_modules` in your repo if your project is a 
   reusable package meant to be consumed by other projects.

See this post for an 
explanation as to why this is the best practice.

Also, it's a good idea to register *all* dependencies in your 
`package.json`: a dependency can be any git repo, not only ones published 
in the npm registry.

On Sunday, December 4, 2011 3:56:52 PM UTC-5, deitch wrote:
>
> You are building an app, it has dependencies on lots of modules that
> you install via npm. But versionizing those in git seems redundant.
> What do people here do? Do they keep node_modules as tracked part of
> git? Or do they put it in .gitignore, and if so, then how do you know
> which versions and dependencies you have?
>

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] What do people do for versionizing node modules within git?

2013-11-06 Thread Brian Lalor 
On Nov 5, 2013, at 11:25 PM, Will  wrote:

> For the Googlers of the future that reach this thread: the answer depends on 
> the nature of your project.
> Do track `node_modules` in your repo if you are deploying an app.


This is not as solved a problem as Mikeal and others would like to think.  
>From an operations perspective, doing *any* compilation on deploy is a 
terrible idea.  It’s a HORRIBLE idea.  It’s a product of developers who are 
ignorant of deploying applications repeatably and at scale.  The only thing you 
should be deploying is binary packages, compiled for the target you’re 
deploying to, preferably in a system package (deb, rpm).  Your production 
systems shouldn’t even *have* gcc on them, and that’s required if you have to 
run “npm rebuild” for a deployment step.

npm’s dependency resolution and loading model is excellent, but if “npm 
shrinkwrap” — the only tool in the suite that’s supposed to help solve the 
floating transitive dependency problem — doesn’t do the job, then it needs to 
be fixed.  Checking dependencies into source control is a hack.

npm’s model has greatly simplified the way I do deployments.  Ruby’s gems suck, 
Python’s less onerous but still kind of a pain.  It’s amusing and painful to 
watch the Fedora folks try to bend node dependency model to fit their archaic 
packaging standards (do yourself a favor and just don’t use anything 
node-related from EPEL).  npm needs to adopt the Maven central repository’s 
roach motel contract: packages check in, but they never check out.  This 
combined with a reliable way to lock down dependency versions and and 
compile-once binary deployment packages means never having to run “npm install” 
or “npm rebuild” on a production box, no matter how old your application is.

--
Brian Lalor
bla...@bravo5.org

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] What do people do for versionizing node modules within git?

2013-11-06 Thread greelgorke 
@Brian: i think what you describe isn't npm's issue. if you have a 
deployment beyond simple apps, then you need another tool and another 
process that fits it. shrinkwrap helps you with managing dependency 
versions, not dependencies. if you have need that level of deploymant 
safety, take maven or ant or whatever you like, let your CI server do pull 
the repo to your target, do the npm install/rebuild and pack it as tar or 
debian package or whatever, put it into your private repo. even java 
projects use rpm or dpkg for production installations. not maven

Am Mittwoch, 6. November 2013 12:34:28 UTC+1 schrieb Brian Lalor:
>
> On Nov 5, 2013, at 11:25 PM, Will > wrote:
>
> For the Googlers of the future that reach this thread: the answer depends 
> on the nature of your project.
>
>- *Do** track* `node_modules` in your repo if you are deploying an app.
>
>
> This is not as solved a problem as Mikeal and others would like to think. 
>  From an operations perspective, doing *any* compilation on deploy is a 
> terrible idea.  It’s a HORRIBLE idea.  It’s a product of developers who are 
> ignorant of deploying applications repeatably and at scale.  The only thing 
> you should be deploying is binary packages, compiled for the target you’re 
> deploying to, preferably in a system package (deb, rpm).  Your production 
> systems shouldn’t even *have* gcc on them, and that’s required if you have 
> to run “npm rebuild” for a deployment step.
>
> npm’s dependency resolution and loading model is excellent, but if “npm 
> shrinkwrap” — the only tool in the suite that’s supposed to help solve the 
> floating transitive dependency problem — doesn’t do the job, then it needs 
> to be fixed.  Checking dependencies into source control is a hack.
>
> npm’s model has greatly simplified the way I do deployments.  Ruby’s gems 
> suck, Python’s less onerous but still kind of a pain.  It’s amusing and 
> painful to watch the Fedora folks try to bend node dependency model to fit 
> their archaic packaging standards (do yourself a favor and just don’t use 
> anything node-related from EPEL).  npm needs to adopt the Maven central 
> repository’s roach motel contract: packages check in, but they never check 
> out.  This combined with a reliable way to lock down dependency versions 
> and and compile-once binary deployment packages means never having to run 
> “npm install” or “npm rebuild” on a production box, no matter how old your 
> application is.
>
> --
> Brian Lalor
> bla...@bravo5.org 
>  
>

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] What do people do for versionizing node modules within git?

2013-11-06 Thread Alex Kocharin 
 Why do you think compilation on deploy is a horrible idea? Is it because of a big compilation time, or are you unsure that compilation will produce the same results on all hosts?   06.11.2013, 15:34, "Brian Lalor" :On Nov 5, 2013, at 11:25 PM, Will  wrote:For the Googlers of the future that reach this thread: the answer depends on the nature of your project.Do track `node_modules` in your repo if you are deploying an app. This is not as solved a problem as Mikeal and others would like to think.  From an operations perspective, doing *any* compilation on deploy is a terrible idea.  It’s a HORRIBLE idea.  It’s a product of developers who are ignorant of deploying applications repeatably and at scale.  The only thing you should be deploying is binary packages, compiled for the target you’re deploying to, preferably in a system package (deb, rpm).  Your production systems shouldn’t even *have* gcc on them, and that’s required if you have to run “npm rebuild” for a deployment step. npm’s dependency resolution and loading model is excellent, but if “npm shrinkwrap” — the only tool in the suite that’s supposed to help solve the floating transitive dependency problem — doesn’t do the job, then it needs to be fixed.  Checking dependencies into source control is a hack. npm’s model has greatly simplified the way I do deployments.  Ruby’s gems suck, Python’s less onerous but still kind of a pain.  It’s amusing and painful to watch the Fedora folks try to bend node dependency model to fit their archaic packaging standards (do yourself a favor and just don’t use anything node-related from EPEL).  npm needs to adopt the Maven central repository’s roach motel contract: packages check in, but they never check out.  This combined with a reliable way to lock down dependency versions and and compile-once binary deployment packages means never having to run “npm install” or “npm rebuild” on a production box, no matter how old your application is.--Brian Lalorbla...@bravo5.org --  --  Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en   ---  You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.



-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
 
--- 
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] What do people do for versionizing node modules within git?

2013-11-06 Thread Avi Deitcher 
When a package goes to a production system, it should be ready to drop in.
You should have versionized binary artifacts stored that can be dropped
anywhere. The binaries should be literally identical across all similar
systems. Otherwise reliable deploy and support are nearly impossible, and
small variants can mean your tests ran against a non-identical binary,
making deploy unreliable.

I consult on business ops in tech, deploying anything that isn't 100%
binary identical across all instances is big trouble (which, of course, led
to some good consulting revenue for me to fix :-) ).

However, if you have CI with a compilation stage, your best practice might
be:

a) Do not include node_modules, just package.json in version control.
b) Do not deploy to production, but rather to your CI system, which does
the build and creates a packaged up artifact, versionizes and stores it,
and runs all your integration tests.
c) Deploy to prod (or dev or UAT or whatever) from the artifact, so you are
guaranteed identical.

The problem is many devs on a small scale (which is what most startups are)
build locally and then push directly to your PaaS via git, jitsu, etc. I
don't have an easy solution for the above, although some of those CI
offerings (circleci, etc.) are reasonable solutions.

Personally, I think how those PaaS use your package.json to rebuild
node_modules is bad practice.



On Wed, Nov 6, 2013 at 4:43 PM, Alex Kocharin  wrote:

>
> Why do you think compilation on deploy is a horrible idea? Is it because
> of a big compilation time, or are you unsure that compilation will produce
> the same results on all hosts?
>
>
>
> 06.11.2013, 15:34, "Brian Lalor" :
>
> On Nov 5, 2013, at 11:25 PM, Will  wrote:
>
> For the Googlers of the future that reach this thread: the answer depends
> on the nature of your project.
>
>- *Do** track* `node_modules` in your repo if you are deploying an app.
>
>
> This is not as solved a problem as Mikeal and others would like to think.
>  From an operations perspective, doing *any* compilation on deploy is a
> terrible idea.  It’s a HORRIBLE idea.  It’s a product of developers who are
> ignorant of deploying applications repeatably and at scale.  The only thing
> you should be deploying is binary packages, compiled for the target you’re
> deploying to, preferably in a system package (deb, rpm).  Your production
> systems shouldn’t even *have* gcc on them, and that’s required if you have
> to run “npm rebuild” for a deployment step.
>
> npm’s dependency resolution and loading model is excellent, but if “npm
> shrinkwrap” — the only tool in the suite that’s supposed to help solve the
> floating transitive dependency problem — doesn’t do the job, then it needs
> to be fixed.  Checking dependencies into source control is a hack.
>
> npm’s model has greatly simplified the way I do deployments.  Ruby’s gems
> suck, Python’s less onerous but still kind of a pain.  It’s amusing and
> painful to watch the Fedora folks try to bend node dependency model to fit
> their archaic packaging standards (do yourself a favor and just don’t use
> anything node-related from EPEL).  npm needs to adopt the Maven central
> repository’s roach motel contract: packages check in, but they never check
> out.  This combined with a reliable way to lock down dependency versions
> and and compile-once binary deployment packages means never having to run
> “npm install” or “npm rebuild” on a production box, no matter how old your
> application is.
>
> --
> Brian Lalor
> bla...@bravo5.org
>
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>  --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "nodejs" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/nodejs/mqVj8f47P

Re: [nodejs] What do people do for versionizing node modules within git?

2013-11-06 Thread Matt 
>From an ops perspective, having gcc/clang on a live server is considered a
security weakness. It's a bit of a dated philosophy, but it does prevent
hackers with shell access from compiling random binaries on the box.

Also yes, compile on deploy can be a bit slow. I don't have a personal
problem with it up to a few servers, but if I was deploying to 10s+ of
servers I would try to use debs/rpms for the extra features they offer.


On Wed, Nov 6, 2013 at 9:43 AM, Alex Kocharin  wrote:

>
> Why do you think compilation on deploy is a horrible idea? Is it because
> of a big compilation time, or are you unsure that compilation will produce
> the same results on all hosts?
>
>
>
> 06.11.2013, 15:34, "Brian Lalor" :
>
> On Nov 5, 2013, at 11:25 PM, Will  wrote:
>
> For the Googlers of the future that reach this thread: the answer depends
> on the nature of your project.
>
>- *Do** track* `node_modules` in your repo if you are deploying an app.
>
>
> This is not as solved a problem as Mikeal and others would like to think.
>  From an operations perspective, doing *any* compilation on deploy is a
> terrible idea.  It’s a HORRIBLE idea.  It’s a product of developers who are
> ignorant of deploying applications repeatably and at scale.  The only thing
> you should be deploying is binary packages, compiled for the target you’re
> deploying to, preferably in a system package (deb, rpm).  Your production
> systems shouldn’t even *have* gcc on them, and that’s required if you have
> to run “npm rebuild” for a deployment step.
>
> npm’s dependency resolution and loading model is excellent, but if “npm
> shrinkwrap” — the only tool in the suite that’s supposed to help solve the
> floating transitive dependency problem — doesn’t do the job, then it needs
> to be fixed.  Checking dependencies into source control is a hack.
>
> npm’s model has greatly simplified the way I do deployments.  Ruby’s gems
> suck, Python’s less onerous but still kind of a pain.  It’s amusing and
> painful to watch the Fedora folks try to bend node dependency model to fit
> their archaic packaging standards (do yourself a favor and just don’t use
> anything node-related from EPEL).  npm needs to adopt the Maven central
> repository’s roach motel contract: packages check in, but they never check
> out.  This combined with a reliable way to lock down dependency versions
> and and compile-once binary deployment packages means never having to run
> “npm install” or “npm rebuild” on a production box, no matter how old your
> application is.
>
> --
> Brian Lalor
> bla...@bravo5.org
>
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>  --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Re: What do people do for versionizing node modules within git?

2013-11-06 Thread José F . Romaniello 
We do not version node_modules for our deploying apps but we use shrinkwrap
and packaging all deps in CI after running all tests using
http://github.com/carlos8f/bundle-deps. This little cli utility move all
dependencies to bundleDependencies.

The CI script is something along these lines:

npm install
npm test

npm prune --production
bundle-deps
npm version patch $BUILD_NUMBER
npm pack


the result artifact is a npm pack with all dependencies inside. During
deployment we use "npm install module.tgz" and yes this compile native
dependencies.

We never have problems with things compiled differently but it is something
I would like to review in the future. I blame linux distributions for
breaking binary compatibility, this make building everything ahead of time
complicated.

I don't like to version node_modules because:

1- messy commits with tons of file changes
2- if you clone the repo in other platform it will probabily not work
because. native dependencies and binary compatibility

Right now we are in the process of replicating npm in a cloud vm (its
almost finished).



2013/11/6 Will 

> For the Googlers of the future that reach this thread: the answer depends
> on the nature of your project.
>
>- *Do** track* `node_modules` in your repo if you are deploying an app.
>- *Do not** track* `node_modules` in your repo if your project is a
>reusable package meant to be consumed by other projects.
>
> See this post for 
> an explanation as to why this is the best practice.
>
> Also, it's a good idea to register *all* dependencies in your
> `package.json`: a dependency can be any git repo, not only ones published
> in the npm registry.
>
> On Sunday, December 4, 2011 3:56:52 PM UTC-5, deitch wrote:
>>
>> You are building an app, it has dependencies on lots of modules that
>> you install via npm. But versionizing those in git seems redundant.
>> What do people here do? Do they keep node_modules as tracked part of
>> git? Or do they put it in .gitignore, and if so, then how do you know
>> which versions and dependencies you have?
>>
>  --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Implement a Master - Slave relationship?

2013-11-06 Thread Alejandro de Brito Fontes 
Hi, If you want to do something using the LAN this can help 
https://github.com/wankdanker/node-discover (look the examples/master.js 
file)
The first user will be the master and any other user a "slave". If the 
master disconnect it will elect a new master.

Or you can use something like https://github.com/stianeikeland/node-etcd to 
create the same thing but without using the broadcast address (using http 
with less network overhead)

On Monday, November 4, 2013 7:12:08 AM UTC-3, Paul Canning wrote:
>
> In this instance, the "Master" will be essentially "Player 1" and gets 
> assigned, in the Poker example, as the dealer (display for the community 
> cards).
>
> My post is asking more of a "how to" rather then the idea.
>
> Are there any examples of what I am describing? Are there any packages 
> that help implement this kind of multi-user relationship? I will be using 
> Socket.io (or similar) to deal with the data flow over websockets, and I 
> know this has rooms, which will be utilised.
>
> Is there a way to find users automatically on the same LAN?
>
> On Saturday, November 2, 2013 12:04:03 AM UTC, Aria Stewart wrote:
>>
>> On Wed, Oct 30, 2013 at 10:05:43AM -0700, Paul Canning wrote: 
>> > I'm looking to make some small games that can be played over a local 
>> > network (or if the app is published online, private rooms using 
>> socket.io) 
>> > 
>> > Is there a way to set one device, say an iPad, as the "Master" device 
>> > (image the dealer in Poker) and then have the connected clients (people 
>> on 
>> > their own tablet or smartphone) as the "Slaves". 
>> > 
>> > It would mean the Master has a different display to the Slaves (for the 
>> > Poker example, the Master would show the community cards and the Slaves 
>> > would only see their 2 cards). 
>> > 
>> > I'm certain this is possible, but I'd like some pointers on how to 
>> > differentiate the master from the slaves and show different information 
>> to 
>> > either party. 
>>
>> In this context, I'd suggest that you've got two problems: First, the 
>> clients 
>> all have to connect -- if there's no server, that means a shared network 
>> of 
>> some sort. If there is, that may well be where the logic should live 
>> (unless 
>> you're going to invent a protocol for them to talk to each other and 
>> agree on 
>> state. This way possibly leads to madness, since distributed systems are 
>> hard.) 
>>
>> The next stage would be having each client read that shared state and 
>> display 
>> appropriately. If there's a central server, it can arbitrate all that and 
>> only 
>> show clients what they need to see; if there's not, well, now you have 
>> 2N+1 
>> problems, and replication is just one. 
>>
>> The player who's in charge of a game does not neccesarily have to be the 
>> same 
>> machine that runs that game. Servers are nice that way. 
>>
>> Aria 
>>
>

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[nodejs] Re: [opinion-request] Routing Syntax

2013-11-06 Thread Jimb Esser 
The way I've seen it done in Express.js (or its URLRouter middleware maybe, 
I'm not quite sure where it is now) is like this:
  app.get('/users/:id(\d+)', function(req, res, id) { ... });
  app.get('/users/:name', function(req, res, username) { ... });
You can just put any regular expression in parenthesis in your route for 
how that token can be matched.  Also allows for regular expressions to 
match ".*" to include slashes, etc.  You could probably even use 
Express's urlrouter/lib/utils.js to build the RegExps for you if you want 
to save some work =).

As for multiple URLs serving the same data, we have found it very useful to 
use the  tag in our 
document head, not for any hand-wavy "SEO" reasons, but for the very 
tangible reason of when we (or users) do a Google search for something in 
one of our pages, there is only a single valid result instead of two nearly 
identical results with different URLs.

  Jimb Esser
  Cloud Party, Inc

On Tuesday, November 5, 2013 7:22:56 AM UTC-8, Alex Kocharin wrote:
>
>
> This is how it's done in express.js:
>
> ```
> app.param('id', function(req, res, next, value, name) {
> if (value.match(/^\d+$/)) {
> next()
> } else {
> next('route')
> }
> })
>
> app.get('/users/:id', function(req, res, id) { ... })
> ```
>
> Do something similar. There is no need to add anything to a route, because 
> the name of the param should already imply the type.
>
> If you write "name", it is string, right? Anybody who reads the code will 
> understand that without any explicit "[string]" garbage attached to it.
>
>
> On Monday, November 4, 2013 10:37:28 PM UTC+4, Simon wrote:
>>
>> In my URL routing (express/sinatra-style), I'd like to enable optional 
>> parameter "filters" (like int, hex) while keeping syntax familiar and 
>> simple. The typical syntax for a routing library might look something like:
>>
>> app.get('/users/:id', function(req, res, id) { ... });
>>
>> I'd like to introduce a syntax for catching only numeric ids so we could 
>> have another route for users by name for instance.
>>
>> app.get('/users/:id[int]', function(req, res, id) { ... });
>> app.get('/users/:name', function(req, res, username) { ... });
>>
>> There doesn't seem to be a convention for this, so I've been considering 
>> the following:
>>
>> '/users/:id[int]'
>> '/users/:id(int)'
>> '/users/:id:int'
>> '/users/:id=int'
>>
>> Any feedback on what's a good way to go that will be simple and obvious 
>> to someone reading the code? If a well-known library is already doing 
>> something like this I'll go with whatever the community is using. Votes 
>> welcome..
>>
>>
>>

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[nodejs] Checking for requires that aren't in package.json?

2013-11-06 Thread Jamison Dance 
Are there any tools that will check your node project for require calls
that aren't in the package.json? I want to eliminate the surprises that
happen when a dev has a package installed locally but doesn't put it in
node_modules, and then the code gets deployed and blows up in a different
environment.

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Checking for requires that aren't in package.json?

2013-11-06 Thread Joshua Holbrook 
Sup Jamison,

Give https://github.com/substack/node-detective and maybe
https://github.com/nodejitsu/require-analyzer a shot.

--Josh


On Wed, Nov 6, 2013 at 6:35 PM, Jamison Dance  wrote:

> Are there any tools that will check your node project for require calls
> that aren't in the package.json? I want to eliminate the surprises that
> happen when a dev has a package installed locally but doesn't put it in
> node_modules, and then the code gets deployed and blows up in a different
> environment.
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.