Lozzer

I'd add Let over Lambda (LOL) to that list.

If you belive Wikipedia https://en.wikipedia.org/wiki/Atomic_radius then the atomic radius of Helium has never been measured, but it is predicted to be smaller than Hydrogen.

I think you'd enjoy the book "The Newtonian Casino".

Metadata operations on partitions can be very fast. One simple example is date based housekeeping. Deleting a month of data will be quite intensive on most databases, whereby dropping a partition from the table is effectively instant.

Partion switching is also fast. Say you have a summary table that is rolled up by month, but you want to recalculate the summaries every so often. You can build a month into a new table and then switch the new table for a partition in the summary table.

http://www.catb.org/esr/structure-packing/

Firstly there are vastly more positions in Go. Secondly, it's very hard to evaluate a Go position, especially at the start of the game when there are few stones on the board. In chess you can get a long way using a simple evaluation (K=99, Q=9, R=5, B=3, N=3, P=1).

The last one might be heped by trace flag 4199. You can apply it to individual queries with option (querytraceon 4199):

https://blogs.msdn.microsoft.com/psssql/2010/09/01/slow-quer...

I expect you have enough hardware to factor widely deployed primes. Compound numbers might be a different story.

Didn't wear a seatbelt and headbutted the person in front, snapping their neck. Sucks to be them, I guess. But at least you stuck it to the man.

design

I thought https://gist.github.com/anonymous/cfe03f2ddb0052b38081 was kind of neat, as you still have to solve the puzzle a bit after using it.

Admittedly in the UK, but the ISP I use don't have a problem with people running servers: http://www.aa.net.uk/

For a lot of RDBMS, transaction semantics can be later with different transaction isolation levels. There levels like repeatable read which work in this way, but the default level is usually weaker.

If you're watching live (or nearly live) broadcast on iPlayer, you still legally require a license: http://iplayerhelp.external.bbc.co.uk/help/playing_tv_progs/...

    CTRL + V
    CTRL
    T

If you're parsing from a real time feed, then that's fair enough. But if not $now isn't appropriate.

Funnily enough if you buy Tesco's electrical goods online and pick up at store you don't get a paper receipt. The security guard (through lack of training) wasn't keen on letting me out without one.

I had a go at something similar for the Facebook version a couple of years ago. My main goal was to stop playing the game, but it was also an excuse to try Clojure. At the time it absolutely thrashed my best scores, though I'm sure it won't work with the updates the developers have made since then.

I think it was the first thing I wrote that drove home the power of having a REPL for exploratory programming:

https://gist.github.com/490689

He referenced a previous talk about the GIL:

http://blip.tv/rupy-strongly-dynamic-conference/david-beazly...

More likely HURD

We have a legacy database we support that creates a new dynamic stored procedure (with the same body) every time it performs a particular operation. How you can have enough knowledge to do this, but not to use a single procedure is beyond me.

Have the counter-parties insuring Greek debt paid up?

I don't think governments are going to be bailing out advertisers just yet.

No, because you would reasonably requests with different parameters to return different pages.

Sounds like your network is suffering from http://www.bufferbloat.net/ .If your OS supports traffic shaping, you can probably fix this by limiting the upload speed there to a fraction under your actual bandwidth. E.g in Linux by using the tc command.

It's probably irrelevant, but maybe http://www.method-combination.net/blog/archives/2011/03/11/s... will help

From the first line of the man page for yes:

yes - output a string repeatedly until killed

I've used an offset mortgage to keep a large cash reserve, but to pay off real estate if I'm not using it.

That's for personal stuff, not sure if there are corporate options.

I estimate by considering an optimistic, pessimistic and normal value for each task. I then have a spreadsheet that does a modicum of statistical analysis to give you times against probability that the task will be finished.

Some of the benefits I find are:

1. Getting into the pessimistic mindset helps produce better estimates

2. Tasks with a large spread are things you aren't really clear about, and are an obvious target to be attempted first

3. Giving a range of values to the person asking for the estimate seems to help them remember it is an estimate.

I think you mean hashing rather than salting.