substack

The plan is to support other test styles like jasmine and qunit through npm modules: http://testling.com/docs/#using-npm

Support for conflicting dependencies in npm is an amazingly great feature because once a piece of software works you can update little pieces of your application without worrying about whether upgrading a dependency will break some sub-dependency somewhere. If your dependency graph has upwards of 50 nodes in it as some of mine do, this is a very big deal.

Hey thanks! The business of making the web a little less terrible and a little more reliable is a great space to be in.

Testling is our newest product here at browserling, so we definitely know how to make tunnels work. We just wanted to get testling launched quickly is all; tunnels are coming soon.

Right now, you do need a public IP for t.createWindow(). We have ssh tunnels in browserling already but they don't work with testling just yet. Stay tuned.

I think one of the biggest benefits of testling right now is that you don't have to install anything outside of curl to start using it.

We pretty much have what you're describing already, except we use node.js-style require()s with browserify instead of AMD. You can write really simple unit tests and just execute them with a curl one-liner or you can write more integration-style tests for an existing app with t.createWindow() and t.submitForm().

Yep you can use it both ways. To drive an existing page around you can use t.createWindow() and t.submitForm(), which give you a new window object and a jquery handle bound to that window object. http://testling.com/docs/#an-example-test

I suspect that people who don't "get" pointers (#4 in the article) actually have a much harder time with the pointer declaration and manipulation syntax in C than actually understanding how pointers work and what they let you do.

For instance, in C the * character is used both to declare a pointer and to dereference one and they can be stacked to dereference nested structures. Then & references a variable memory location but is also used in method signatures to change the semantics of calling a function into pass-by-reference. To complicate & further, & is often seen alongside const declarations, which are a whole other thing that people have to keep in their heads.

On top of all of this, * and & have their own operator precedences and associativities that you have to memorize, which is a whole discussion about binary versus unary operators and precedence tables. And I didn't even mention [].

I really don't think that people fail to comprehend pointers because their mental models need updating nearly as often as they just haven't fully internalized all the hoops that C makes you jump through to mess with pointers.

You have to roll this yourself right now with a connection pool of stream objects. I'll probably build this out as a separate module.

It's handy if you want to map ports or host:port combos to subdomains so they all can share the same port on the same server.

I guess what I was saying there isn't the whole story, since bouncy uses node's http parser directly to handle splitting up keep-alive requests. What I meant was more that bouncy sends data over a tcp stream instead of simply passing the request object through to an http client request.

This software fills the same niche that something like HAProxy or apache virtual hosts fills right now. Bouncy is great for when you have services on your internal network or on different ports and you want to map them to subdomains.

As I just mentioned elsewhere this thread already, browserling is rolling out exactly this service really soon! Here's a sneak peak: http://browserling.com:9088/

We at browserling will be releasing something perfect for that in a week or so! Sneak peak: http://browserling.com:9088/

Haskell is great for pure algorithms like that.

As for jumping in too quickly? I was a pretty heavy haskell user for about 3 years.

I gave haskell a shot as some of my earlier github repos indicate: https://github.com/substack. I even wrote my blog in haskell with happstack, since snap hadn't gotten popular yet.

Haskell is very hard, but even after 3 years of pretty intensive use, I never really felt productive with haskell in the same way that I've felt in other languages. Anything I did in haskell required a lot of thinking up-front and tinkering in the REPL to make sure the types all agreed and it was rather time-consuming to assemble a selection of data types and functions that mapped adequately onto the problem I was trying to solve. More often than not, the result was something of an unsightly jumble that would take a long time to convert into nicer-looking code or to make an API less terrible to use.

I built an underwater ROV control system in haskell in 2010 which went well enough, but I had to tinker with the RTS scheduling constantly to keep the more processor-hungry threads from starving out the other ones for CPU. The system worked, but I had no idea what horrors GHC was performing on my behalf.

Later I built the first prototype of my startup with haskell, but the sheer volume of things that I didn't know kept getting in the way of getting stuff done in a reasonable time frame. Then we started to incrementally phase out haskell in favor of node.

I write a lot of node.js now and it's really nice. The whole runtime system easily fits into my head all at once and the execution model is simple and predictable. I can also spend more time writing and testing software and less time learning obscure theories so that the libraries and abstractions I use make sense.

The point in the article about haskell being "too clever for this benchmark" sums up haskell generally in my experience.

Reading the section on ruby reminds me of the things that I take for granted in node.js right now owing to the long history of package management and module systems that it builds upon.

It's super nice having the dependencies specified by semvers in a package.json and installed locally in a project node_modules directory so that libraries can't step on each others toes.

The "Don’t use Bundler version X with RVM version Y" can be specified directly in the package.json and concurrent versions of module dependencies even work without incident in the same project.

Presumably by modifying `require_paths` and therefore changing how `require` behaves.

Native apps in webOS are written in node.js:

https://developer.palm.com/content/resources/intro_to_hp_web...

I don't see how it's specious to prefer javascript syntax over python syntax for asynchronous code. It's an aesthetic consideration and so it's less about the fact that you can have the same sorts of functionality and structures in both environments and more about which style people prefer.

I really don't understand why whenever somebody switches to node from python people pounce on them like this, as if people aren't allowed to find a particular syntax annoying?

There's a link to heatmap.js in the article.

It's handy for whipping out gdb to investigate segfaults at least.

For context, see http://blog.nodejs.org/2011/07/11/evolving-the-node-js-brand...

Oh I forgot to mention in the article, but I'm also using burrito for node-detective (https://github.com/substack/node-detective) to find all the require()s in a javascript file. Using detective made browserify (https://github.com/substack/node-browserify) much easier to use.

> To do that the dependency module IDs must be extracted from the module text via static analysis, but that's fairly easy since module IDs are specified to be string literals. A simple regex is usually good enough, but using one of the many JavaScript parsers is safer.

I did exactly this for browserify, yet another node-based browser-side require() bundling system. Another benefit of this approach is that you can use modules made for node just by require()ing them in your browser-side javascript, so long as your static analysis bundling is recursive and the modules can be `require.resolve()`'d by node.

Actually in node at least modules can export functions directly, just assign a function to `module.exports` and when you require() that module you'll get a function back. Plus you can add attributes to that function since functions are also objects.

And the nodeconf slides are at https://gist.github.com/958556

Javascript compressors can intelligently remove blocks that general purpose stream compressors can't, like dead code or comments. Also because they understand the AST they can move code around to a limited extent to make the final output shorter.

Automatic compression isn't in there yet but you can compress the bundles using the "filter" option, which just takes a function that transforms the bundled source.

Isn't this what perl6 grammars set out to solve?