wulczer

Nope, we push changes to clients.

The exact workflow is: the initial data is pulled over HTTP, the code connects to our server over WebSockets and after that no more requests are made. The real-time updates are pushed over the WebSocket connection.

If you have any questions, I'll be here all day ;)

Also known as Poor Man's Profiling (see http://poormansprofiler.org/ or http://webcache.googleusercontent.com/search?q=cache%3Apoorm... as it seems the site's down).

It's a pretty good technique, actually.

What? A join requires all of your data to be in memory? I've sure as hell seen databases that executed queries with joins and the data was not entirely in memory...

  Example A field accepts a username. A good regex would
  be to verify that the data consists of the following
  [0-9a-A-Z]{3,10}. The data is rejected if it doesn't
  match.

I guess then that pg won't be able to sign up for your service... Nor will donfernandovillaverde79.

Also see the Mandelbrot set in SQL: http://wiki.postgresql.org/wiki/Mandelbrot_set

Erm, so if things are fast it doesn't matter and if things are slow you should write a whole new service, put a HTTP interface into it and use that? Not sure I buy that :)

Disclaimer: I wrote an async DB module for Twisted/PostgreSQL and it did not turn out to be all that complex.

That sounds wrong. You need async database access so that while you're waiting for a query to finish, you can still process other requests.

Imagine an app that receives an HTTP request every second. One in five of these requests requires making a query that takes 3 seconds to complete. The rest is serviced immediately. You don't want the long request freezing your entire server and preventing the fast requests from being serviced.

Raphael is for generating SVG, so you can draw anything with it. Oh, and multiplayer browser games were possible long before Node.js appeared, there's no new magic there.

A short, probably biased and not 100% precise answer would be: no, you don't need to look for a commercial RDBMS.

The real answer is: always evaluate options. Make sure the solution you choose supports everything you need and that you will be able to learn how to use it or hire people who can. Without knowing what your requirements are it's impossible to say, but in the vast majority of cases, PostgreSQL will be as good as Oracle, MS SQL Server or DB2.

If your evaluation indicates that you need to pay for one of these, double and triple check it... and only if you're 100% sure that's the case, shell out for a commercial RDBMS.

Here's the presentation from last year's PGCon, it's not exactly easy to follow, but has some hints on how this can be used:

http://www.pgcon.org/2010/schedule/events/227.en.html

The problem is not having to update tons of records, the problem is seeing one day, after 2 years of having the app in production, that the listing shows that employee X works in department Y and her boss is Z, but Z is not the head of Y. Bugs happen and referential constraints go a long way towards keeping your data clean.

ipfw :o)

Probably not, Python's reload has its fair share of caveats. There was an effort in Twisted to provide robust reloading support for Python modules[1], but I think it's a bit abandoned.

That being said, we are using reload() with manhole to update code. You just have to be extra careful and know what you're doing.

[1] http://twistedmatrix.com/documents/11.0.0/api/twisted.python...

Twisted has semi-decent documentation, see

http://twistedmatrix.com/documents/current/api/twisted.html

http://twistedmatrix.com/documents/current/core/howto/index....

http://twistedmatrix.com/trac/wiki/Documentation

It's not as comprehensive and shiny as the core Python docs, but along with the tutorials and examples, it's actually pretty decent.

A typical usage of volatile, and one that bit me many times is using longjmp, for which the man page says:

  The values of automatic variables are unspecified after a call to longjmp() if they meet all the following criteria:
  · they are local to the function that made the corresponding setjmp(3) call;
  · their values are changed between the calls to setjmp(3) and longjmp(); and
  · they are not declared as volatile.

I've had bugs that made me go half-crazy before someone reminded me that you have to use volatile in these situations.

I think #define volatile is by far the sneakiest.

The rest would probably be found quite quickly, but omitting volatiles could lead to hard to detect bugs that will only manifest themselves under specific circumstances.

Yep, you can disable individual warnings with pragmas (http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html) so if I add

  #pragma GCC diagnostic ignored "-Wunused-parameter"

to the C file, I get warningless compilation even with -Wextra. you can also do push/pop to store/restore the warnings reporting options.

I don't get any warnings with -Wall and I get a "unused variables argc and argc" with -Wextra.

Changing main's signature to int main() eliminates all warnings at -Wextra.

Interesting, I just tried compiling this with gcc 4.4.5 and got no warnings:

  #include <stdio.h>
  #define ADD(x, y, z) \
  do { \
  z = x + y; \
  } while (0)

  int main(int argc, char *argv[])
  {
      int z;
      ADD(1, 3, z);
      printf("z = %d\n", z);
      return 0;
  }

If your compiler complains about the do{} while (0) construct in macros, I'd be inclined to treat it as a bug and complain to the vendor.

A common idiom to use here would be for(;;) {...}

Right now it's more useful for uncovering bugs, I don't think anyone would recommend running Postgres compiled with clang on a production system.

For more info about performance, see http://pgeoghegan.blogspot.com/2011/07/could-clang-displace-...

A piece of fun trivia. What is currently the PostgreSQL codebase used to be written in Lisp, and was subsequently ported to C.

You can still recognize Lispy idioms in many places, there's abundany usage of the List structure, functions called lcons and list_head/list_tail and a NIL constant for an empty list.

See the anecdote at line 77 in a README file: http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=...

We used IPython's parallel processing features at (first (take-right jobs 2)) for load testing. One machine would run ipcluster and people who were not doing CPU or network intensive tasks would fire up ipengine that connected to the ipcluster box.

By doing that they would volunteer their machines to the cluster pounding away at the big server that was being tested.

EDIT: fix my Scheme

The last time I had to rewrite an SQL query because it was too slow (5 days ago) I definitely used the knowledge taught to me in my CS course.

GStreamer is another option. While support for some formats is provided in GStreamer by using ffmpeg, it has independent implementations for many formats and a very different architecture.

Sounds a little like apps in Djangoland. Maybe someone who knows both frameworks could confirm.

If you're looking for blogging software for hackers, look at http://wingolog.org/software/tekuti/.

From the page:

  Tekuti means "I'm telling you" in Oshiwambo.
  It is weblog software written in Scheme, using Git as its persistent store.

'Nuff said.

It's MIT licensed, so not proprietary. Did you mean to say "third-party"?

I think it's Wikipedia because "walkman" has a much longer history as a brand name, from cassette players to cell phones.

I remember times where back where I lived "walkman" was a plain noun meaning "any kind of portable cassette player".