[nodejs] NodeConf 2015

Hey Everybody :) It's about that time again. NodeConf 2015 is our most ambitious event yet. We have a 2 day speaking event at the Fox Theatre in Oakland, CA and a 3-4 day un-conference (NodeConf Adventure) back at Walker Creek Ranch. All in early June, so just a few months away. We've announce

Re: [nodejs] @indutny :: Well done! #heartbleed

Fedor is a HackStar :) On Apr 16, 2014, at 10:39AM, Jorge Chamorro wrote: > > > :-) > > -- > ( Jorge )(); > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Maili

Re: [nodejs] Module API design for both promises and callbacks

module.exports = function (cb) { var promise = wrapThisCallbackInAPromise(cb) return promise } Always observe the standard callback patter for the function you export. Always export a function as your module's API. -Mikeal On Apr 14, 2014, at 9:20PM, Andrew de Andrade wrote: > So at work

[nodejs] NodeConf 2014

We opened up over 100 new tickets to NodeConf today. While a few of the lodges sold out there are still several left :) http://nodeconf.com/ -Mikeal -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received t

Re: [nodejs] What is Node.js doing to prevent another Heartbleed style bug in Node core or dependent libraries?

JavaScript doesn't allow you to write fancy 3 letter macros that make it kinda hard to notice where the memory offset is coming from :) That helps us out a little at the JS layer. On Thursday, April 10, 2014, Forrest Norvell wrote: > Write or find an embeddable TLS implementation that somehow ma

Re: [nodejs] Why is my streaming word counter so much slower than a non streaming version?

There's a pretty simple rule to follow here: - If your working set fits in memory, pull it in to memory. - If your working set does not fit in to memory, or you require concurrent working sets which will cumulatively not fit in memory, use streams. It is *always* faster to do transforms and mani

Re: [nodejs] Re: advice on a newcomer, how's the market for nodejs devs? Is it a good field to find remote type jobs/contract?

On Mar 4, 2014, at 4:44PM, Alexey Petrushin wrote: > - Usually companies that use Node.js are small or small departments in big > companies, and it's harder to get h1b visas than with let's say Java because > of the small size they can't afford it, especially long waiting time for > approval.

Re: [nodejs] callback hell on steroid

http://callbackhell.com/ On Feb 11, 2014, at 10:42AM, Reza Razavipour wrote: > I have a node.js, express really, app that needs to make SOAP calls, > asynchronously of course. > > In this case, I make a soap call and I get a count. Once i have the count, I > have to loop and make a series of

[nodejs] JSFest

. Evolution of Experience is curated by Mikeal Rogers. Monday, March 10th Main Event: Scaling Up and Down Can the tools we use to build a new website in half a day also help us add features to an established application that deploys to millions? Find out what people are doing to start fast and

Re: [nodejs] Re: Web Scraping Frameworks for Node.JS? (e.g. like Python's Scrapy)

I wrote spider for this but I haven't kept up with maintaining it: https://github.com/mikeal/spider If you end up using it and have improvements to make i'll add you as a contributor. -Mikeal On Jan 20, 2014, at 10:44AM, Tim Killian wrote: > Someone has already mentioned using cheerio, and I

Re: [nodejs] State of the art for request isolation in http servers?

The core team built domains specifically to tackle this problem. http://nodejs.org/api/domain.html Forrest and Domenic did a session about them at NodeConf last year, their materials are here: https://github.com/mikeal/nodeconf2013/tree/master/pkg/domains If you analyze the code you're workin

[nodejs] Re: [npm] Re: The Next Phase of Node.js

TJ works at Joyent, he has for some time, and was hired specifically to work on node core stuff. On Jan 15, 2014, at 10:12AM, Felix Geisendoerfer wrote: > Thanks for the update Isaac, and best of look with your new venture. > > I've been a bit out of the loop, as I'm not doing much node dev at

Re: [nodejs] npm package mutability

For reference: 9768 packages lock 24538 dependencies in 57515 different versions of those packages. https://gist.github.com/mikeal/8090801 (will work as soon as I can publish npmetrics, currently getting allocation errors). -Mikeal On Dec 22, 2013, at 5:46PM, Mikeal Rogers wrote: > &

Re: [nodejs] npm package mutability

On Dec 22, 2013, at 4:45PM, Alex Kocharin wrote: > > 23.12.2013, 04:36, "Mikeal Rogers" : >> >>> * allow aggressive caching, reducing the cost of the npm registry and >>> making npm use faster for most use cases >> >> this isn't

Re: [nodejs] npm package mutability

That's a good question. To my knowledge everyone agrees that shrinkwrap should include the hashes. On Dec 21, 2013, at 12:20AM, Alex Kocharin wrote: > I wonder why it didn't make it to master. > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wik

Re: [nodejs] npm package mutability

cosystem even if it makes the future a little better. We can only really entertain strategies that make current and future packages less prone to these problems without the potential to break existing ones. > > Rich > > > > > On 19 December 2013 23:49, Mikeal Rogers wrote: &

Re: [nodejs] npm package mutability

nothing will ever break? :) > > > 20.12.2013, 03:42, "Mikeal Rogers" : >> First off, if someone version locks they are already doing the wrong thing. >> Saying "make my package ignore bugfix releases" is almost always the wrong >> thing. In this case it's bet

Re: [nodejs] npm package mutability

On Dec 19, 2013, at 3:21PM, Alex Kocharin wrote: > It resulted in huge node_modules folder checked in (with binary deps because > nobody cared), they weren't updated at all (and were outdated for like a > year). this just requires some diligence and using dedupe often. > And the worst thing

Re: [nodejs] npm package mutability

ecify ~1.2.3, and > receive your 1.2.4 with a bugfix. But they don't even though npm specify "~" > syntax by default. Why do you suggest to replace 1.2.3 (if it's broken or > something) with a different version dependent explicitly didn't want to see > in

Re: [nodejs] npm package mutability

ver again. > It'll mess up things. I like to see how npm v1.3.19 is missing from registry > for example. > > > 20.12.2013, 02:27, "Mikeal Rogers" : >> That leaves all of the other packaged already published and relying on a >> specific version brok

Re: [nodejs] npm package mutability

.com/posts/nodemodules-in-git.html -Mikeal On Dec 19, 2013, at 2:37PM, Brian Lalor wrote: > That’s a terrible idea. The simplest reason it’s a terrible idea is that > binaries built for one platform will be checked in. ie developing on OS X > and deploying on Linux. > > On Dec 19,

Re: [nodejs] npm package mutability

+1 On Dec 18, 2013, at 12:41PM, Tim Caswell wrote: > If you want this level of static dependencies you can check in your deps into > node_modules in your git tree or use git submodules in there. Git does > guarantee that the thing you point to can't be changed because the hash *is* > the has

Re: [nodejs] npm package mutability

blish) would make the npm registery an even better > place. > > > On Thu, Dec 19, 2013 at 2:43 PM, Mikeal Rogers > wrote: > There have also been security issues where old packages were shipped with > sensitive information that needed to be ripped out. > > On Dec

Re: [nodejs] npm package mutability

There have also been security issues where old packages were shipped with sensitive information that needed to be ripped out. On Dec 18, 2013, at 5:07PM, Forrest L Norvell wrote: > I agree that packages should rarely be changed, but in practice if there's a > major bug or the packaging gets to

Re: [nodejs] Re: Learning NodeJS: what's important?

I think it's best to ignore all of this advice and just dive in. You're going to get a lot of opinions about what other people think is important and may not actually be important to you. The things I think are important are very unlikely to be what matter to you. The best way to dive in and le

Re: [nodejs] Learning NodeJS: what's important?

http://nodeschool.io/ On Dec 16, 2013, at 4:51PM, Orthoducks wrote: > I'm trying to learn NodeJS. My background (most recently) is writing web > applications in PHP, with some JavaScript mixed in. My objectives are (1) to > learn to write simple web applications in NodeJS, (2) to be able to re

Re: [nodejs] Throwing your developers under the bus to appease liberal Social Justice Warriors? Absolutely Disgusting!

This has to be a joke. If it isn't a joke... it might be even funnier than if it were a joke. On Dec 10, 2013, at 7:06AM, hemn soll wrote: > We will spread awareness about your treachery towards your developers and > contributors just to appease these nut case communists who go around altering

Re: [nodejs] any speed difference w/ promises vs callbacks

There has actually been a lot of movement on this lately so I'd say the perf differences are a giant question mark. The last numbers anyone did showed some pretty bad numbers for promises but I know they've done a bunch of perf work lately so it might be better now. On Dec 13, 2013, at 4:35AM,

Re: [nodejs] how to best develop two related modules simultaneously

I'm the one who made isaacs write npm link back in the day. I was a fan of linking (manually and w/ npm) but after a few years of living with node's module system I stopped using it. All my repos are checked out in to ~/Documents/git, if I'm developing two simultaneously I just do require('../m

Re: [nodejs] node.js needs a new home

On Dec 10, 2013, at 2:21PM, Mark Hahn wrote: > I hope anything we switch to also supports email. That's a given, GitHub issues support email so I assume this new thing will too. -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Post

Re: [nodejs] node.js needs a new home

On Dec 10, 2013, at 12:47PM, Mark Hahn wrote: > I and many others refuse to join google+ I'm with you on that :) GH === GitHub :) -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message bec

Re: [nodejs] node.js needs a new home

GH is suppose to have a new feature soon that should let us kill the mailing list while maintaining a forum for the positive (and without doubt some of the negative) uses of the mailing list. I've got no love for Google Groups. On Dec 10, 2013, at 11:48AM, Rick Waldron wrote: > FWIW, I also pr

Re: [nodejs] Re: Ben Noordhuis's Departure

On Dec 9, 2013, at 12:38PM, Ben Noordhuis wrote: > On the contrary, it's 100% accurate. The reason I stepped down is not > because of the Twitter brouhaha, I was unmoved by that. It's because > I feel I can no longer trust Isaac to do the right thing and that > makes working together impossibl

Re: [nodejs] Re: Ben Noordhuis's Departure

On Dec 9, 2013, at 9:13AM, Jorge Chamorro wrote: > stepping over the guy who is in charge of libuv and pissing him off No part of this is accurate. -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received th

Re: [nodejs] Re: Ben Noordhuis's Departure

e Chamorro wrote: > On 09/12/2013, at 06:46, Mikeal Rogers wrote: > >> I don't work for Joyent. >> >> (...) >> >> If you want to take comments out of context to support some kind of Joyent >> vs. StrongLoop world view it would be more effective t

Re: [nodejs] Re: Ben Noordhuis's Departure

I don't work for Joyent. I'll continue to speak for myself and I'll continue to laugh about comments as absurd as "equality nazi." You have to laugh at the trolls, otherwise they win. If you want to take comments out of context to support some kind of Joyent vs. StrongLoop world view it would b

Re: [nodejs] Re: Ben Noordhuis's Departure

On Dec 7, 2013, at 9:57PM, Darren DeRidder wrote: > @isaac "First of all, to characterize Ben's departure, or the whole recent > drama, as being over pronoun usage, is a radical oversimplification." > > I'm glad to hear this admission but the fact remains Joyent characterized > things this wa

Re: [nodejs] Re: Ben Noordhuis's Departure

How about we start assuming that individuals are responsible for their own actions rather that shills for their current employer. Pretty much everyone we're talking about has a career and credibility extending much farther back than their current employment. -Mikeal On Dec 6, 2013, at 12:46PM,

Re: [nodejs] HTTP Server Concurrent Requests

Back then we spent a good amount of time debating whether or not this mattered. I remember that Ryan was particularly enamored with pipelining. What it really comes down to is that pipelineing is almost never faster than a keep-alive pool. The reason is that the client has no idea how long each

Re: [nodejs] Ben Noordhuis's Departure

On Dec 4, 2013, at 11:30AM, Alex Kocharin wrote: > Yeah, I noticed how node is breaking from this tradition and losing > developers for no reason because of that. Nice damn job. > The break in tradition is done in order to appeal to people who have traditionally not engaged in open source be

Re: [nodejs] Ben Noordhuis's Departure

On Dec 4, 2013, at 11:16AM, Alex Kocharin wrote: > The issue in that in opensource it's customary to base all commits on > technical reasons. This opinion is clearly not shared by the project. To build and engage a community of humans there are human factors you must consider. Those are not

Re: [nodejs] Ben Noordhuis's Departure

With respect, Ben explained his personal reasoning for his actions. He didn't apologize or even acknowledge the hostile way he decided to behave publicly and privately. Ben's contributions, which are numerous and appreciated, also don't excuse toxic behavior in an open source project. The people

Re: [nodejs] Re: Ben Noordhuis's Departure

HN, well known for its polite and productive discourse. On Dec 4, 2013, at 8:58AM, Darren DeRidder wrote: > "respect our wishes"? Really? After you call someone who speaks English as a > second language an a-hole on your corporate blog and push one of the most > valued contributors out of the

Re: [nodejs] Re: node.js needs a new home

Just a few things. When you want to comment in regard to Bryan Cantrill's post on behalf of Joyent it doesn't make you sound more definitive to state your opinion as some sort of overwhelming consensus when it is not. I agreed with Bryan and have nothing to do with Joyent. Many others feel the

Re: [nodejs] Re: node.js needs a new home

I wrote about this in greater detail: https://gist.github.com/mikeal/7738226 A foundation can't help us deal with these issues with regard to the explosion in users and ecosystem, it could only attempt to alter the process around core which is not a very important issue. -Mikeal On Dec 3, 201

Re: [nodejs] Cachemere - Server side file caching engine which efficiently serves static files (keeps the preprocessed/gzipped version in cache so no need to recompress).

ions you have with most web frameworks so it's an advantage to be somewhat incompatible. > > On Friday, November 22, 2013 11:14:43 AM UTC+11, Mikeal Rogers wrote: > You might want to have a look at jaws > > https://github.com/mikeal/jaws > > You also probably want to st

Re: [nodejs] Cachemere - Server side file caching engine which efficiently serves static files (keeps the preprocessed/gzipped version in cache so no need to recompress).

You might want to have a look at jaws https://github.com/mikeal/jaws You also probably want to start storing this stuff in isaacs' LRU. https://github.com/isaacs/node-lru-cache -Mikeal On Nov 21, 2013, at 3:06PM, Jon wrote: > This is a tool I wrote which helps create efficient Node.js file s

Re: [nodejs] Re: request package syntax error with NODE_DEBUG defined

that was committed, it's in master. are you sure it's in the version you're running? On Nov 14, 2013, at 2:31PM, Reza Razavipour wrote: > it turns out to be a bug, that was fixed but never committed. > > https://github.com/mikeal/request/commit/b8cf8743b66d8eee4048561a7d81659f053393c8 > > >

Re: [nodejs] Node crashes in OS X mavericks - dyld symbol not found _xmlBufContent

hrm... mine is working. % node -v v0.10.13 On Oct 23, 2013, at 10:25AM, Alberto Ricart wrote: > I upgraded my machine to OS X Mavericks last night, and to my surprise, node > crashes. Reinstalling node does not fix the issue. > > $ node -v > dyld: Symbol not found: _xmlBufContent > Refer

Re: [nodejs] Is it a right thing to do, to use Node.JS as a TCP Server?

is the string utf8 or ascii? and is it ever decoded in to a string by the application or does it just proxy as a buffer? notice that while the answers to these questions dramatically change the performance characteristics they are entirely irrelevant to the performance a real application you're

Re: [nodejs] [ann] JavaScript Unconference

Awesome! You should send a pull req to https://github.com/mikeal/node-meatspace with the dates :) Also, if you run in to any problems organizing your conference log an issue and there are a bunch of organizers that can offer support. -Mikeal On Oct 9, 2013, at 5:26AM, Robert Kowalski wrote:

Re: [nodejs] How to prevent disasters caused by the callback getting called multiple times?

where this is a concern you should just use once. the request 3.0 branch is doing so, as are several other projects i've written, and it works quite well. https://npmjs.org/package/once -Mikeal On Oct 1, 2013, at 10:51AM, Oleg Slobodskoi wrote: > The answer depends on the reason why the callb

Re: [nodejs] PowerLinux (PowerPC aka PPC) early (unofficial) version of Node.js

Great work! On Sep 3, 2013, at 11:41AM, Andrew Low wrote: > Hi folks, allow me to introduce myself. I'm Andrew Low and I work for IBM. > I've been building runtime technology for almost 20 years, over that time > I've built Smalltalk VMs (http://en.wikipedia.org/wiki/IBM_VisualAge), Java > VM

Re: [nodejs] Re: Mongo vs. Couch vs. LevelDB ?

I would phrase this differently. As you write your own database using node.js and LevelDB you can host it pretty much anywhere that you can run a node.js program. Its deployment and management is identical to how you manage your node.js application. This means that you avoid most of the pain tha

Re: [nodejs] Mongo vs. Couch vs. LevelDB ?

CouchDB, MongoDB and every other database you've listened other than LevelDB are traditional "big black box" databases. They store data in a predetermined format, they give you an API to get it out and to index it in a declarative manor. LevelDB is a database engine, very small, and in the node

Re: [nodejs] Best practices managing node dependencies?

90% of all the releases I do of my modules are for bug fixes. Staying up to date, for the most part, means being *more* stable, not less. The difference between Apache releases and the node ecosystem is that we have roughly 1000x the level of engagement around publishing and releasing. It would

Re: [nodejs] Re: The Future of Programming in Node.js

There will always be people who don't like a particular decision in the core API. There are problems/bugs that are being fixed and there are others that are unlikely to change in core because they would break compatibility (which node can no longer tolerate). In the end, all of this mailing li

Re: [nodejs] Future of asynchronous programming in node

or not? > > Tell me which of these is a constructor that must be called with `new`: > > a() > b() > c() None of them, they aren't capitalized. This is a trick question right? :P > > > Rick > > > > > > On Tue, Aug 6, 2013 at 2:54 PM, T

Re: [nodejs] Future of asynchronous programming in node

of this you see a function call? Only the function > definition looks different. Tell me which is these will yield .. > > a() > b() > c() > > On Tue, Aug 6, 2013 at 2:54 PM, Tim Caswell wrote: > > > > On Tue, Aug 6, 2013 at 4:47 PM, Mikeal Rogers wrote: > I

Re: [nodejs] Future of asynchronous programming in node

It is the *exact same* hazard as the code you posted, I don't think it is any *more* of a hazard at the language level. The difference is that the pattern in the function code below is basically never seen in node.js code and it has been *possible* to write it since node's creation. Could be th

Re: [nodejs] Future of asynchronous programming in node

I'm sure Isaacs has said as much several times: - Core won't be changing dramatically (i assume this includes moving the entire stdlib to an alternate IO pattern) - node.js takes v8 "as is" (i assume this means we won't be disabling features in the language just because a few people complain abo

Re: [nodejs] Future of asynchronous programming in node

nc threads like this. The only feasible solution would be for the > BDFL to choose something and demand it. > > On Mon, Aug 5, 2013 at 4:51 PM, Mikeal Rogers wrote: > Potentially, yeah, that would be great. Although I think asyncSomething is > more likely to take off since ending in

Re: [nodejs] Future of asynchronous programming in node

t uses generators could start with async, like asyncDoit, or more > reasonably, some convention like ending with a dollar sign: doIt$. > > On Mon, Aug 5, 2013 at 4:26 PM, Mikeal Rogers wrote: > > On Aug 5, 2013, at 4:16PM, Jake Verbaten wrote: > >> The only confusion

Re: [nodejs] Future of asynchronous programming in node

On Aug 5, 2013, at 4:16PM, Jake Verbaten wrote: > The only confusion is knowing whether your using generators for async flow > control or whether your using them to generate iterators you iterate over. > Once you learn to only use the first type in synchronous fashion and only use > the second

Re: [nodejs] Future of asynchronous programming in node

ntrast to fibers which don't follow your terrestrial > rules). Thus you're not going to run into the case where innocent client code > is waylaid down the stack by a generator. The only functions that need to > worry about reentrancy are those that are explicitly marked as func

Re: [nodejs] Future of asynchronous programming in node

I don't think you understand what I'm saying, I'll try to be clearer. Callbacks that use node's standard callback interface are resolved exactly once. From the point at which they begin to when they end the author can assume that any code they are running is the *only* code running in the VM and

Re: [nodejs] Future of asynchronous programming in node

Your points don't match the data that we have. The most commonly used flow control library in npm is one that manages callbacks, async. There are plenty of people that don't use callbacks, and that's great, but "every knows" is kind of outlandish considering all the data we have does not agr

Re: [nodejs] Future of asynchronous programming in node

y/likely be occurring in a later turn of the > eventloop. > > Andrew Gaspar > > > On Mon, Aug 5, 2013 at 1:53 PM, Mikeal Rogers wrote: > > On Aug 5, 2013, at 1:51PM, Tim Caswell wrote: > >> It doesn't >> >> >> On Mon, Aug 5, 2013 at 1

Re: [nodejs] Future of asynchronous programming in node

On Aug 5, 2013, at 1:51PM, Tim Caswell wrote: > It doesn't > > > On Mon, Aug 5, 2013 at 1:32 PM, Mikeal Rogers wrote: > I don't see how generators are going to change how actual async programming > happens in node.js, at least in ES6. > > It doesn&#

Re: [nodejs] Future of asynchronous programming in node

There is a discussion about promises for ES7 and there is work on a spec for a promise interface as part of the DOM. No promises in ES6, at least no more than you already have in the hundreds of promise libraries you can use today :) -Mikeal On Aug 5, 2013, at 11:43AM, Christopher Probst wrot

Re: [nodejs] Future of asynchronous programming in node

I don't see how generators are going to change how actual async programming happens in node.js, at least in ES6. Generators in ES6 are "shallow," they cannot yield until some time in the future when IO is done. Generators could be combined with some kind of promise interface, along with a new k

Re: [nodejs] You're going to have to rewrite it anyway

On Jul 8, 2013, at 1:18PM, Timothy J Fontaine wrote: > Presuming of course a neutral api can be agreed upon. taking JSAPI is a good direction in that it's probably easier to agree on something that isn't being written from scratch. the decision can be binary: we either take this API or we don

Re: [nodejs] new project - simpleio

now what you would need to make it > usable for your usecase. > > On Monday, July 8, 2013 9:31:21 PM UTC+2, Mikeal Rogers wrote: > Interesting. > > I'm basically using engine.io as a simple stream. I've written several > modules for the features that I need on top

Re: [nodejs] new project - simpleio

socket.io with engine.io inside but I aborted it > after some basic design problems in terms of interaction with storages. > > Am 08.07.2013 um 18:11 schrieb Mikeal Rogers : > >> I too had issues with socket.io but have found engine.io to be quite >> pleasant. Did you

Re: [nodejs] new project - simpleio

TBH we had too many unresolved issues with websockets even in clients that support them and only enable long polling anyway. Other people I know have done similar things for production sites. On Jul 8, 2013, at 12:13PM, Oleg Slobodskoi wrote: > I haven't used sockjs, but from what I can see: >

Re: [nodejs] You're going to have to rewrite it anyway

As an ecosystem node.js has far less compiled addons than any of its contemporaries (Python, Ruby, etc) which is probably why most of us have heard way less about the pain of API changes in v8 for module authors as we have about streams2. That said, compiled modules are still growing, and sizab

Re: [nodejs] You're going to have to rewrite it anyway

+1 to all of this. I think you implied it but maybe never explicitly declared it: does this mean node.js is going back to shipping with its deps and not allowing linking the way that some Linux distro's have demanded? This is all the right direction, IMO. node.js should provide the best platfor

Re: [nodejs] new project - simpleio

I too had issues with socket.io but have found engine.io to be quite pleasant. Did you try engine.io and come to similar frustrations? On Jul 8, 2013, at 6:01AM, Oleg Slobodskoi wrote: > Hello there :) > > I have recently started a new project after lots of frustration with > socketio. Simple

Re: [nodejs] Re: Client/Server side Router

i think mapleTree will work with browserify. On Jul 4, 2013, at 10:40AM, daslicht wrote: > > My motivation is to create a simple graceful degrading hijax "Toolkit". > > > Essentially like the approach from derbyjs but without using derby. > I'd rather start simple from ground to have 100% con

Re: [nodejs] Is it a right thing to do, to use Node.JS as a TCP Server?

Could you please post the code for this benchmark. Also, being a "dynamic" language does not mean certain operations are slower or faster, it just means that the optimizations that need to happen for something to be fast live in a vm rather than a compiler. On Jun 21, 2013, at 1:09PM, Kaveh Sha

Re: [nodejs] Re: Best practices for token-based authentication in REST API

OAuth 1 is a pain in the ass but mostly secure and consistent across implementations. OAuth 2 is fairly easy and inconsistent across implementations as well as being very insecure. The author of both specs is a node developer now and has left the standards world to do this stuff "right" :) htt

Re: [nodejs] Cookie auth performance...

what module are you using to parse the cookie? any sample code? On Jun 3, 2013, at 3:32PM, Michal Kruk wrote: > Hi > I am writing a web application in node and i stumbled upon a big performance > issue with express signedCookies with those turned on even if there are no > cookies to parse,

Re: [nodejs] Module naming

In the earlier days of node, when isaac and i were first putting up the registry, we did think about the problems that come with a single global namespace. In the end it was still a better decision to go with a single global namespace for the following reasons. 1. Manufactured Scarcity. The "la

Re: [nodejs] Re: Synchronous code with node.js for utility scripts

I would put it like this: People are writing concurrent applications. Basically, people who used to write Rails apps are writing servers now. This is harder. The hardest part of concurrent programming is understand and managing state mutations. We all hate dealing with threads in C right? Ther

Re: [nodejs] How to Firmly Establish your Reputation

can someone tell me how SEO works with node.js apps. my reputation depends on it. On May 21, 2013, at 2:07PM, Luke Arduini wrote: > the sequel could be called "how to spam a mailing list with irrelevant > discussion" > > On Tuesday, May 21, 2013, José F. Romaniello wrote: > you should write a

Re: [nodejs] Re: what are the merits / demerits of require.extensions?

On May 12, 2013, at 3:20PM, Brad Carleton wrote: > If I distribute all of my code as javascript, I just don't see why in my own > personal environment whether dev or on the server, that I wouldn't choose the > first option there. Especially, if from my viewpoint, "coffeescript", > "typescrip

Re: [nodejs] Re: Our Contribution To Node Community, Introducing NodeJS Console

Yeah, I didn't want to make any security issues public before he had a chance to fix them. On May 9, 2013, at 2:45PM, Jorge wrote: > On 09/05/2013, at 21:18, Kushal Likhi wrote: > >> Hi, Great thanks for the feedback. >> >> • Security updates as mention

Re: [nodejs] options for private npm registries?

I'm curious, why do you want a private registry? -Mikeal On May 1, 2013, at 2:58PM, Laurie wrote: > Hi, I'm looking into the options for setting up a private npm repository and > the trade-offs in terms of operational and infrastructure costs. So far I've > found: > > * irisnpm.com hosting;

Re: [nodejs] options for private npm registries?

I'd ping https://twitter.com/iriscouch , also Jason watches this list so he'll probably pop in once it's morning in Thailand :) On May 2, 2013, at 10:20AM, Laurie wrote: > Yes, it wont recognize me as signed in. The persona signin process completes > without (visible) error but I still get tol

Re: [nodejs] Provide clone utility method in "util" module

For what its worth i sent about a half a day dealing with json serializing with circular references and copy issues. The solution ended up being removing underscore for lodash and doing _.clone(obj, true); Highly recommended. -Mikeal On May 1, 2013, at 11:26AM, Mark Hahn wrote: > Deep copy:

Re: [nodejs] Provide clone utility method in "util" module

The util module is for common utilities required by *other core modules* not utilities that are useful for node modules outside of core. Node core is crazy small, its not reasonable to think you can build an application without installing additional modules with npm. Many great utility modules

Re: [nodejs] Re: Retrieving values asynchroniously

That's a good response, and a better characterization of the streamline compatibility/incompatibility than I state in my article. I'd like to make on thing clear. While I think that some of your ideas might be better served as a less if not entirely incompatible fork I don't intend to disparag

Re: [nodejs] Re: Retrieving values asynchroniously

On Apr 27, 2013, at 6:46AM, Jorge wrote: > On 24/04/2013, at 23:50, Mikeal Rogers wrote: > >> I feel really bad for people that ask incredibly simple questions on this >> list. > > I feel really bad whenever I read *your* posts dismissing other people's work.

Re: [nodejs] Re: Retrieving values asynchroniously

jective source like npm > stats like Mikeal has done. Or at least a compare/contrast on why I might use > your package. > > > >> >> On Wed, Apr 24, 2013 at 2:50 PM, Mikeal Rogers >> wrote: >> I feel really bad for people that ask incredibly simple

Re: [nodejs] Re: Retrieving values asynchroniously

I feel really bad for people that ask incredibly simple questions on this list. The solution nearly everyone in this community uses is the async library: https://npmjs.org/package/async https://github.com/caolan/async Its currently depended on by 1901 other packages. It's the defacto-standard fo

Re: [nodejs] Streams writev API

h > doesn't need the writev fluff. > > Tim > > On 23 April 2013 14:15, Mikeal Rogers wrote: >> Is there a reason not to just have the underlying libuv *always* writev when >> it has more than one pending buffer to write? >> >> I'm wondering whey w

Re: [nodejs] Streams writev API

Is there a reason not to just have the underlying libuv *always* writev when it has more than one pending buffer to write? I'm wondering whey we can't just optimize this behind the scenes, is there a reason we need to map each stream write a write syscall? -Mikeal On Apr 22, 2013, at 5:01PM, I

Re: [nodejs] hostproxy

pure laziness :) On Apr 20, 2013, at 2:18PM, Arunoda Susiripala wrote: > why not readable-streams use for 0.8 ? > > > On Sun, Apr 21, 2013 at 2:29 AM, Mikeal Rogers > wrote: > Oh yeah, i forgot one detail. hostproxy *only* works on 0.10 :) I used the > streams API ex

Re: [nodejs] hostproxy

Oh yeah, i forgot one detail. hostproxy *only* works on 0.10 :) I used the streams API exclusively to see what it was like. On Apr 19, 2013, at 9:40PM, Matthias Götzke wrote: > It would be awesome if it also parsed the URL.. > > We tried bouncy before , but it is not compatible with 0.10 > >

Re: [nodejs] hostproxy

iday, April 19, 2013 at 10:57 PM, Mikeal Rogers wrote: > >> Time for another log on the "http proxy" bonfire. >> >> I've been poking at this problem a long time and I think I may have cracked >> it. >> >> Node should have the fastest HTTP load bala

  1   2   3   >