wulczer

It's very interesting to see hard data that confirms a general feeling I get when comparing walking down the streets of SF and of NY.

That feeling is one of the few things that makes me still prefer New York to San Francisco... I hope that gets fixed soon!

PostgreSQL also uses longjmp to implement TRY/CATCH macros:

https://github.com/postgres/postgres/blob/master/src/include...

Just as fast (and that means pretty fast). Comparing to MongoDB might not make sense, if you're running it with no fsyncs (I don't know much about MongoDB, so maybe it is possible to make it fsync data).

There was a good talk about using Postgres as a key-value store at PGcon 2010, see http://www.pgcon.org/2010/schedule/events/219.en.html and http://www.scribd.com/gavinmroy/d/31669670-PostgreSQL-and-No... (especially the classic photo of DBAs running with scissors)

The underlying syscall and libc function are called pipe2.

From the linked blog post:

  Do these results have any real world value?
  
  Probably not. (...)

Kind of sums it up. It's fun to play around with web frameworks and draw some bar charts, but please don't take this seriously. And definitely don't say "X is slower than Y" because of this.

Things like that always remind me of this great quote by Tom Lane (source: http://en.wikipedia.org/wiki/Tom_Lane_%28computer_scientist%...):

  On idiotic benchmark comparisons "Try to carry 500 people
  from Los Angeles to Tokyo in an F-15.
  No? Try to win a dogfight in a 747. No? But they both
  fly, so it must be useful to compare them... especially
  on the basis of the most simplistic test case you can
  think of. For extra points, use *only one* test case.
  Perhaps this paper can be described as "comparing an F-15
  to a 747 on the basis of required runway length".

Not quite there, but at least it was a start:

http://en.wikipedia.org/wiki/French_Republican_Calendar

If you're referring to PHP's PDO, it's not an ORM and you're still exposed to all the syntax quirks if you have to support several databases.

We found that Debian-packaged uWSGI is missing one param in uwsgi_params so you should use this instead:

    location / {
        uwsgi_pass <xxx>;
        include uwsgi_params;
        uwsgi_param UWSGI_SCHEME $scheme;
    }

Without the UWSGI_SCHEME part, Django's Request.get_absolute_uri will return URIs starting with 'http' even if your site is served over HTTPS.

For the record, the title is misleading and Andrew Dunstan (the guy whose blog this entry links to, a major PostgreSQL contributor and one of the people involved in having a JSON type in Postgres) clarifies:

http://people.planetpostgresql.org/andrew/index.php?/archive...

Your point is valid, of course - developing specialized software requires a specialized platform. But what I wanted to say is that even developing a web app (and that's what I do these days) I sometimes need to use Wireshark.

Sure, there was that guy that used an iPad, a wireless keyboard and a Linode as his PC so it's viable. But I think that's an exceptional case and it's more common to need quite a lot of supporting tools to develop things.

And of course, you know, our designer can work with just a notebook (as in: a paper notebook) :)

I'm not sure I agree with the final point

  All you need these days to build great things is a
  browser, a text editor, and the programming language
  or tool of your choice.

Even when developing web apps there's sometimes need to use a network traffic analyzer, a debugger... Not to mention a plethora of tools for reading/analyzing/parsing log files, graphing benchmark results, generating test SSL certificates and a lot of other things that are not equally available on all platforms.

And there's another consideration: if you're deploying your software on Linux it's just plain easier to develop it on Linux as well.

I guess I'm looking from a startup founder perspective...

If you choose an unknown technology because you have solid reasons to believe it will bring a substantial advantage to the product, which will offset the loss in productivity, then sure. If you choose it just so that your team will be motivated and you willingly take the productivity hit for that, I find it difficult to understand.

It's not the technology choice, it's the reasons that seem weird to me. It's probably because of the runway length they have that they can venture into unknown territory for no reason other than trying things.

I'm reminded of Asana and Lunascript - a fun experiment you can afford when you have lots of money in the bank, but not something I'd see as practical.

Oh my, I can't believe my eyes:

  Our developers bleed all over MongoDB, WebSockets, CoffeeScript and Node.
  But at least they’re having fun. And in today’s tight job market,
  great programmers have a lot of sway on what they’re going to be working on.

So is the job market so bad you have to bribe engineers by letting them use tools they're apparently not proficient or efficient with, just so they'll come and work for you? I find it so insane it's not even funny anymore.

Sounds like a weird reason to switch the language and framework used for your product. Blocking libraries block just the same in Node and in Twisted. Why not just stop using the Django ORM or more generally, stop writing code that blocks the main thread for long periods of time?

The problem of the main thread waiting on a response from the database is easily solved without rewriting all your code, which incidentally will have the same issues, since there's no new magic there.

If your software is a giant, ugly hairball because you wrote it in a hurry (I know I did this many times!) don't blame it on the language or framework. What I'm wondering is: Python/Twisted/Django rank equally or similarly on all the points from the list, except for Team Experience, which has to be much higher with the old stack than with a completely new technology and set of tools. This makes me think that there was a "play with shiny things" point after all.

I'm curious, when you change the schema on the fly, the app code has to deal with both versions, right? I'm afraid this means you shift the pain instead of blowing it away.

The parent of the post I responded to argued that Linux has not "won the software deployment war". I happen to agree with that and I believe that throwing out a few examples of technology companies that do deploy their software on Linux is not a convincing argument.

The way my GP alleged that no big companies use Windows as a platform came off as snarky and represents what I think is a skewed, SV/web-startup centric point of view.

Yeah, those other companies like Walmart, UPS, Boeing... you know, the ones based outside of Silicon Valley, deeply entrenched in the real world.

Actually, there's quite a few companies that offer professional PG support, there's a list on the official PostgreSQL page:

http://www.postgresql.org/support/professional_support/

There's talk about making partition management easier, but I doubt it's going to be present in 9.2

You can look at PL/Proxy that makes some things related to partitioning across multiple machines easier.

Automatic interpolation of variables into string literals is a bad idea IMHO.

Couple that with variable hoisting (function scope) and hilarity can ensue when variables defined further down a function influence the value of another variable that looks like it just contains a string literal.

Let keyword: good. The function scoping of vars is gruesome.

Default arguments: good. Clearly useful and already used a lot with the if (foo === undefined) foo = 'default' pattern.

Non-strict destructuring: bad. It's neither destructuring-bind nor pattern matching... If I destructure a 3-list to 2 vars, I want it to fail, dammit!

Multi-line strings: good, obviously.

Templating: hello, PHP! I thought we already know better.

List comprehension: useful.

My humble opinion: it's hopeless. A mix of useful and terrible features means it'll still be made out of "the good parts" and the awful rest.

Cloud or not, if you're writing serious software (and by that I mean software that depends on fsync succeeding) you'd better expect system calls to fail and have code to handle that.

My first thought was: "oh my God, I'm a n00b!"

My second thought was: "no, I just think I disagree with him".

Comments in the code are good. They help the next person that touches that particular part of the project understand why it's coded as is and why it wouldn't be a good idea to code it differently. Commenting a counter increment with "increment the counter" is silly. Commenting it with "it's safe to increment it without taking locks, because the caller already took them" is useful.

The most beautiful codebase I've ever seen is PostgreSQL and the comment density in its source tree is quite big. Take a look at https://github.com/postgres/postgres/blob/master/src/backend...

Would you say that this code has been written by a two-year-old? Or rather that it's been written by a responsible adult that cared about the integrity of future coders' tonsures and wanted to save them some heavy head-scratching?

Wasn't very successful, 3 points and 0 comments: http://news.ycombinator.com/item?id=3059460

I found it with hnsearch, by the way.

Actually, the ideal thing to happen would be for PL/Python to somehow become a shared library that provides the typecasting routines, but I'm afraid that's a very big task and difficult to get accepted upstream. It's sad that PL/Python already includes all the code you need to transform Python lists to Postgres arrays, bools to PG bools and so on and every project like this one has to duplicate all that logic.

BTW: in my approach I opted for passing the entire Qual node as a string (using nodeToString) and my plan was to write a Python parser for that format that takes a string and returns a Python object. Not sure how hard that will turn out.

Crap, I'm working on something exactly like this :D Was about to upload it to Github just today, but still wanted to fix a few things.

Yours looks quite more finished, one thing that would be very useful is handling Python to Postgres type conversion, like PL/Python does. After that, the next step is caching I/O functions for the duration of the scan, which PL/Python also does.

Nice to see that the idea made sense for more than one person, hope Multicorn will rock!

Amen. There's already a well-proven and quite expressive DSL for accessing data stored in a relational database: SQL.

I see that this has been submitted before, so I'll just mention it here: http://thoughts.j-davis.com/2011/09/25/sql-the-successful-co...

Ooops!

Sure, you'll have yours today. You had a bit of rotten luck, as precisely on that day we turned down the flow of invites.

Sorry to keep you waiting ;)

This photo of two of the founders when they were 12 years and 60 pounds younger should explain it http://dl.dropbox.com/u/18461275/Ducksboard-founders.jpg

Go, Anaheim Ducks!

We have plans to make an interface that's less bling-heavy and more power-friendly, but it won't hit production anytime soon.

Another way is to simply write your own visualisation. If you're interested in getting early-alpha-unstable-omg access to the read APIs (HTTP and WebSockets), shoot us an email to hello@ducksboard.com