mjijackson

I was curious, so I actually ran both of the servers from the article on my little MacBook Air. The results are below.

First, go:

    $ ab -c 100 -n 10000 http://localhost:8000/
    This is ApacheBench, Version 2.3 <$Revision: 655654 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/

    Benchmarking localhost (be patient)
    Completed 1000 requests
    Completed 2000 requests
    Completed 3000 requests
    Completed 4000 requests
    Completed 5000 requests
    Completed 6000 requests
    Completed 7000 requests
    Completed 8000 requests
    Completed 9000 requests
    Completed 10000 requests
    Finished 10000 requests


    Server Software:        
    Server Hostname:        localhost
    Server Port:            8000

    Document Path:          /
    Document Length:        1048576 bytes

    Concurrency Level:      100
    Time taken for tests:   10.085 seconds
    Complete requests:      10000
    Failed requests:        0
    Write errors:           0
    Total transferred:      10489017384 bytes
    HTML transferred:       10487857152 bytes
    Requests per second:    991.62 [#/sec] (mean)
    Time per request:       100.846 [ms] (mean)
    Time per request:       1.008 [ms] (mean, across all concurrent requests)
    Transfer rate:          1015729.90 [Kbytes/sec] received

    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        1    2   0.8      2       6
    Processing:    21   99   5.6     98     137
    Waiting:        1    3   2.7      2      41
    Total:         25  101   5.6    101     139

    Percentage of the requests served within a certain time (ms)
      50%    101
      66%    102
      75%    103
      80%    103
      90%    105
      95%    106
      98%    108
      99%    112
     100%    139 (longest request)
     

    $ ab -c 100 -n 10000 http://localhost:8000/
    This is ApacheBench, Version 2.3 <$Revision: 655654 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/

    Benchmarking localhost (be patient)
    Completed 1000 requests
    Completed 2000 requests
    Completed 3000 requests
    Completed 4000 requests
    Completed 5000 requests
    Completed 6000 requests
    Completed 7000 requests
    Completed 8000 requests
    Completed 9000 requests
    Completed 10000 requests
    Finished 10000 requests


    Server Software:        
    Server Hostname:        localhost
    Server Port:            8000

    Document Path:          /
    Document Length:        1048576 bytes

    Concurrency Level:      100
    Time taken for tests:   15.765 seconds
    Complete requests:      10000
    Failed requests:        0
    Write errors:           0
    Total transferred:      10487558651 bytes
    HTML transferred:       10486808576 bytes
    Requests per second:    634.31 [#/sec] (mean)
    Time per request:       157.653 [ms] (mean)
    Time per request:       1.577 [ms] (mean, across all concurrent requests)
    Transfer rate:          649639.92 [Kbytes/sec] received

    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        0    1   1.7      1      11
    Processing:     2  156  34.7    159     272
    Waiting:        1   47  29.7     42     136
    Total:          2  157  34.7    161     273

    Percentage of the requests served within a certain time (ms)
      50%    161
      66%    174
      75%    182
      80%    187
      90%    198
      95%    209
      98%    221
      99%    227
     100%    273 (longest request)

> I can't wait until all the current methods of creating web apps are obsolete.

Please, don't hold your breath.

Can anyone from Stripe confirm that this box is not rooted?

Aw, sad. The server seems to be non-responsive.

Read this if you're stuck on level 3: http://destroy.net/machines/security/P49-14-Aleph-One

> 1) Every artist who's made an online release of their content in a desirable format (without DRM, etc) has seen sales in proportion to their general popularity. Every single one, without even one exception.

That's not true. Radiohead pulled the plug on their In Rainbows experiment after only 3 months in 2007. They decided to go the more traditional route instead. Why would they (an incredibly popular band) do something like that if sales were truly in proportion to their popularity?

Radiohead tried a similar experiment to Louis C.K.'s back in 2007 with their album In Rainbows. But after 3 months they decided that the online sales weren't working out and that they should pursue the more traditional avenue of selling CD's out of retail stores. Two similar stories with vastly different outcomes.

I say that it's similar because both are well established acts in the entertainment industry, releasing their work unencumbered by DRM (or other encryption) via a website. As I see it, the main differences are (in very general terms):

- Radiohead said that fans could pay whatever they wanted for the album, Louis C.K. charged $5 - Radiohead are a band, Louis C.K. is a comedian - Radiohead tried it in 2007, Louis C.K. in 2011

Of these 3, the most significant difference that I see is that Radiohead didn't set any price tag on their work while Louis C.K did. By some estimates more than half of the people who downloaded In Rainbows did so without paying a penny for it. Louis C.K., on the other hand, charged $5 right up front. The price tag was so low that it was a pretty easy decision for most who bought it, but it was there nonetheless.

I think that speaks volumes about setting customer's expectations appropriately, an area in which the software industry traditionally shoots itself in the foot. Ask your customers to pay something. If you have something of value, they will.

tl;dr: If you think that

  var output = Sugarless(input)(
     sanitize          
   , trim             
   , truncate, "", 200   
  );

  var output = truncate(trim(sanitize(input)), 200)

> Which is exactly what the fat arrow does in Coffeescript.

Except when there's a regression in the compiler, and then it doesn't.

https://github.com/jashkenas/coffee-script/issues/1842

It's all good though, because "Pull requests are always welcome." :P

Glad to see that http://wastm2released.com/ was updated to reflect this announcement! Congrats on being so close Allan!

"If you are worried that women don’t feel capable of doing whatever they want, you can stop worrying."

This comment from the article gets at the heart of what the author is trying to say. Behind the desire to single out women as a group that needs a special invitation to pursue a career doing startups are two assumptions: 1) that women actually want a career doing startups and 2) that they do not feel empowered to pursue that course on their own.

The author simply isn't comfortable making those assumptions, which point of view is completely valid given the subjectivity of the topic.

Been thinking a lot about this statement, but still not sure exactly what he means by it. I could interpret it a few different ways, and I'm probably over-thinking it. How do you interpret this?

This is a very well-written article. I really enjoyed the "What it is", "Why I like it", "How I'd use it" format. It is much more helpful than a simple list of features.

He's not suggesting forking. He's suggesting spinning up a new process entirely (ffmpeg in this case).

It's not the main point of the article, but I just thought I'd point out that node already does have a WSGI/Rack-style library for folks who like that kind of thing. It's called Strata (http://stratajs.org). Disclaimer: I'm the author.

Even so, this breaks down with JSGI middleware that depends on running in a Java environment. For example, JSGI's gzip middleware uses Java's byte buffers.

Thanks! I think if you dig in and actually write something with if you'll soon see that the differences are subtle, but significant.

Proven to fail? You haven't proven anything. Abstractions can be useful. You use lots of them every day. Node itself is an abstraction.

Parsing multipart requests and saving uploaded files to temporary files on disk. Large request bodies emit data multiple times.

Connect/Express do little more than set up a callback chain for you that passes along the request and response objects it received from node's request listener.

Strata gives you a sane environment modeled after the WSGI/Rack/CGI model, which has been the backbone of web servers for years.

Also, Strata's API matches the WSGI/Rack model. This may seem small, but in practice it's a significant benefit.

Add to that the list of features cited in the release email, including native support for streams in node 0.4.

The Strata spec states that a body may be either a string or a stream. All Strata middleware that needs to modify the body in some way must account for this. It's not difficult to do a "if (typeof body == 'string')".

Strata borrows many concepts from Rack, but not the synchronous part. Instead of expecting your app to return something, Strata gives you a callback that you can use to serve the response when you're ready.

I admit the manual could probably give a better example of streaming a response. For now, check out the static file serving middleware (https://github.com/mjijackson/strata/tree/master/lib/static....). You'll see that the response body is simply a readable stream to the file on disk.

The fact that Strata uses cookies for sessions is just a personal preference, and certainly isn't something that is forced upon you. It would not be very difficult to add support for file or database-backed sessions into the core distribution.

Strata definitely does eat its own lunch. :) You can view the source of the website here: https://github.com/mjijackson/stratajs.org

The Server header reports nginx because it's sitting behind a reverse proxy on Heroku.

JSGI is not able to take advantage of node's ability to serve responses asynchronously because the spec doesn't allow for it. JSGI specifies that the return value of an app must be the [status, headers, body], whereas Strata specifies that the return value of an app is not important and that the app's callback should be used to serve the response instead.

This is an API incompatibility that cannot be ignored. The most developed lib I've seen up to this point to get JSGI working on node (https://github.com/kriszyp/jsgi-node) isn't able to get asynchronous responses working properly. Instead, it just does a body.forEach (see https://github.com/kriszyp/jsgi-node/blob/master/lib/jsgi-no...) to write each piece out to the response synchronously.

Copied and pasted from https://github.com/mjijackson/strata/issues/2.

At this point I'd actually compare it more closely with Werkzeug (http://werkzeug.pocoo.org/).

That's like saying that WSGI/Rack don't do anything more for Python/Ruby than their respective HTTP libraries. When you understand the rationale behind those libraries you'll understand Strata.

The examples use string concatenation for the sake of simplicity. Strata doesn't attempt to tie you to any particular templating library because everyone has their own preferences and there are so many of them out there.

For an example of using ejs with Strata, take a look at the source to the Strata website: https://github.com/mjijackson/stratajs.org

It would be more correct to say that V8 has a 1G memory limit. But node.js actually gives you these nice things called Buffers which, according to the node.js manual, are "similar to an array of integers but corresponds to a raw memory allocation outside the V8 heap" (see http://nodejs.org/api/buffers.html).

Buffers are used all over the place in node, which should mitigate the degree to which this is actually a problem. Even if this bug report stays a wontfix, it won't affect my decision to use node because of Buffer support.

I absolutely agree with this sentiment. This is the "box" that I was referring to above. It represents the limit of that which you are willing to believe, in many cases because you believe that you have already reached some level of understanding which cannot possibly be eclipsed by further investigation.

I also believe that it is at least as important to recognize that there are certain characteristics (for lack of a better word) that each of us possess which are an integral part of who we are.

Your claim that we are nothing presents a serious ethical dilemma, and one which I believe if not understood correctly can have disastrous consequences. Allow me to explain.

Each of the characteristics that I mentioned above directly ties me to a responsibility that I have to some "other". With regards to this other, I am something. It is the very essence of existence. The mere fact that I exist means that I will always have an effect on some other, whether good or bad. Without an other, I do not exist.

To choose to ignore the responsibility I have towards an other is an action. It may have a good or bad consequence, but it is still an action. I cannot avoid acting, as inaction itself is an action with regard to the other.

For example, I mentioned above that I am a father. Now, I could of course choose (as many men do for one reason or another) to simply walk away from my responsibilities as a father. I could decide essentially that I am not a father. But that doesn't change the fact that I have fathered children and that abandoning that responsibility will have some consequence on them. To them, I am something. I am their father, and I can't change that.

To pretend that I'm not a father is simply lying to myself. It's also being very selfish. That's why I say that this belief system can have disastrous consequences when applied broadly. Because if you're not careful it can lead to very selfish behavior.

I am a husband. I am a father. I am a child of God.

There is a fine line between putting yourself in a box that you (or others) create for you and knowing who you are. The classifications that Paul lists in his post are of the first kind. The second kind, you can't really change.