jasondavies

> The current theoretically best max flow algorithm uses, at its core, an SDD solver.

Does anyone know how this improvement in solving SDD affects the complexity of the current best max-flow algorithm [1] i.e. (N+L)^(4/3) ?

[1]: http://web.mit.edu/newsoffice/2010/max-flow-speedup-0927.htm...

I've come across the same problem. I was working on some ancient code purportedly released under a BSD license. However, it contained code from Numerical Recipes!

Here's a good page encouraging everyone to boycott them: http://mingus.as.arizona.edu/~bjw/software/boycottnr.html

Cool. Opera already supports Greasemonkey-style user scripts [1], as does Google Chrome [2].

They're handy for writing simple browser hacks e.g. injecting additional links into certain pages.

[1]: http://www.opera.com/docs/userjs/examples/#greasemonkey

[2]: http://dev.chromium.org/developers/design-documents/user-scr...

That's a tricky one. I haven't tested this, but I think you should be able to listen for the 'load' event on each of the script elements that you inject, and patch document.write differently each time.

Let me know how you get on! I plan on doing something like this soon for some of my sites that have AdSense (another document.write culprit).

I just emailed you but I got a bounce, "address rejected".

The last problem was really simple in Python. I was all psyched up for a big bad end-level boss! Still, it was fun to play.

LABjs is a useful JavaScript library that lets you load JavaScript on-demand and specify dependencies: http://labjs.com/

Good point, but you'll still benefit from using async script loading if you have multiple third-party scripts loading at the end of your page. If the Twitter script is included before the others, and it lags, it will hold them up too.

Warning: while the above async loading code works for Twitter, it won't work for any JavaScript containing calls to document.write() as they'll append the data to the end of the page depending on the browser (or even replace the whole page!)

All is not lost though, as you can patch document.write to do the right thing and write to an element's .innerHTML or equivalent. If you are a JavaScript API provider though, please take heed and don't use document.write(). I'm looking at you, PollDaddy!

The 10x speed difference is impressive, but they do list some caveats in the benchmark:

* AsmXml does not copy attributes and text unless necessary (when it includes entity or char references), so, if you need a zero terminated string, you must copy the value first.

* On the other hand, it does more work since it also decodes attributes (O(1) access time), saving a lot of time to the caller of the library.

I'd be interested to know whether it would still be that much faster than a C library that had the same tradeoffs e.g. no copying of attributes/text unless necessary.

I also wonder if it's worth it for existing C libraries to incorporate hand-optimised asm from this library (only when targeting x86 of course) if it provides much more benefit than the above tradeoffs.

Recurly for recurring billing (http://recurly.com/) (they just added support for VAT, ideal for us in the UK, and they support SagePay UK as a payment gateway as well as PayPal)

Unfuddle (http://unfuddle.com/) and github (http://github.com/) for bug tracking.

JungleDisk (http://www.jungledisk.com/) for off-site backup. Uses your S3 account to store encrypted backups.

Server Density (http://www.serverdensity.com/) for monitoring

UserVoice (http://uservoice.com/) for customer feedback

JungleDisk does encryption and you only have to pay for S3 usage after the one-off license fee.

Someone should write a JavaScript -> CoffeeScript converter. Shouldn't be too hard, I might actually do this myself when I get time.

Breakdown for http://www.jasondavies.com/ over the past month:

Safari: 4%

Internet Explorer: 5% (!)

Mozilla-compatible agent: 6%

Chrome: 20%

Firefox: 65%

I'm still waiting for OS X to add support for TRIM: http://en.wikipedia.org/wiki/TRIM_(SSD_command)#Operating_sy...

I've grown to prefer:

    var foo,
        bar,
        baz;

It seems less cluttered. You can of course introduce errors through copy/paste/reordering, but I think it's a reasonable tradeoff. I agree about comma/semicolon-first being strange though.

There are some cool Babbage-related meccano models here: http://www.meccano.us/

One of them is a "barrel" for the Analytical Engine: http://www.meccano.us/analytical_engine/index.html

There are also fully working models of the Difference Engine e.g. http://www.meccano.us/difference_engines/rde_2/index.html although I think they had to make some modifications due to the limitations of Meccano!

It's caused by Twitter's insufficient escaping of URLs, specifically a rogue quotation mark character can be injected after the @ symbol and thus you end up with something like <a href="URL@" onmouseover="insert XSS attack here">...</a>

So this attack won't work on other sites that escape URLs properly.

Is it really necessary to change one's password? I've logged out and logged in again to make sure I invalidated my old session cookie. Hopefully that's sufficient.

Also check out R-Node, a Web front-end to R with Protovis. It's still alpha but worth taking a look.

http://www.squirelove.net/r-node/

http://gitorious.org/r-node

http://www.r-statistics.com/2010/04/r-node-a-web-front-end-t...

Here's Google's cached copy: http://webcache.googleusercontent.com/search?q=cache:2fmfGIe...

“That is the way with wise people – they are so wise and practical that they always know to a dot just why something cannot be done; they always know the limitations.”

I think it's more because air bubbles are squeezed out as the glacier moves, making it clearer than fridge ice which usually contains many air bubbles.

http://en.wikipedia.org/wiki/Blue_ice_(glacial)

Unfortunately the colour spectrum is unfriendly to those of us with red-green colour blindness: it's hard to differentiate between positive and negative percentage changes without looking at the tooltips. Aside from that, nice treemap.

It's the top "watched/listened" story on BBC News right now. Hurrah for free publicity.

This is what happens on the Dragon's Den. The Dragons are much more likely to invest in someone who can prove that they can make a small success on their own, and who has the balance sheet or sales statistics to prove it.

Even if someone has a stellar product or service, if they have only sold a meagre amount to friends and family in two years the Dragons start to get tetchy and either ditch them, or ask for a huge chunk of the company in return for their investment.

Of course, I'm sure the Dragon's Den isn't necessarily much like the real world, but it's interesting to note the things they look for.

I think there is a typo in the expansion of 1/89:

>>> 1/89.0

0.011235955056179775

Which appears to be the same as the Fibonacci sum...

Thanks!

> But SRP is totally irrelevant in a browser context, because any technique you can use to safely deliver SRP code to the browser can be used just as easily to safely exchange passwords directly. SRP will be relevant when browsers bake it in.

If you read the conclusion, this is why I ripped out the SRP stuff :-) Can't wait for TLS-SRP to hit the browsers.