colinhowe

I do a similar thing. I also have a variety of objects under my desk at different heights so I can rest my feet in different positions and do whatever feels comfortable.

My desk isn't adjustable (atm) and one of the biggest (but unexpected) benefits of standing at my desk is that it tires me. After two hours or so I am forced to go have a sit down _away_ from my computer. This helps my productivity more than trying to take regular breaks when sitting as I find it harder to waste the time browsing the internet or simply skip a break.

Cool looking app. Passed it on to some designer friends.

I think the price point is probably right - a lot of Apple products are expensive and I believe the Apple owner mindset makes these folks more willing to part with their cash for good things.

This doesn't address any other possible causes:

  * population growth
  * biofuels
  * climate change
  * increased demand for 'expensive' food such as meat
  * corruption
  * the effect of 'fair trade' on food prices 
    (fair trade wants them to go up so farmers get more)

Banks may be speculating that the prices are going to go up - but they will have reasons for this speculation. Once the price gets too high then banks will likely also start speculating that the price will go down.

I often think that you should track vacation but track it against a minimum. Some talented folk actually need forcing out of the building.

If fusion ever becomes feasible they should drop the word "nuclear". Given the current level of fear around nuclear power the possibility of people exploiting the naming similarity is worrying.

This gave me two awesome ideas - thank you!

1. Hash the results as you say to try and find queries that could benefit from being cached 2. Graph the change in a queries performance over time - useful for spotting queries that were fast due to a small table and are now becoming troublesome

I'll start looking at these in the next few nights :)

This will group up queries from lots of different requests (and things like Celery) - not just queries. Also, due to the frequency being controllable this could be used in a production system (it is being used in ours).

The idea is to help you find your trouble spots - DjDT is amazing once you know where they are :)

First read from each edge would be two reads. One to get the data from the central S3 repo, one to serve to the end user. But, that's not double... after the first read for each edge the additional read is no longer needed.

This would have been more awesome if the clusters had an address and handled the sharding for you.

As it stands, getting a memcached server up and running is so trivial that this probably isn't worth the extra cost for anyone on a small scale and already using things like chef or puppet.

This seems a little far from the truth. What if someone needs to fix an urgent live issue? You can't always work async. Sometimes things need to get done, now. E.g. issues on a production system that are breaking the site for everyone.

Sadly, people often think that everything needs to be done now and I think forcing less meetings on people helps that happen.

I've had it running for about five hundred concurrent. I purposefully made it something you have to checkout yourself so that it's trivial to add filters in if you want to limit what you're seeing.

I don't think people were exposed to Chrome versions in the same way. I have no idea what version of Chrome I am running. I wasn't even aware that they had crept up major versions for a long time... in many ways this is ideal - I don't want or need to know 90% of the time :)

I'd laugh so hard if someone knocked an equivalent up in C and it was faster...

You could store hashes of various small combinations, e.g. hash the 3rd, 5th and 6th characters and then test against that. Then nothing needs storing in plain test. You don't even need to store the hash for the whole password either.

Agree with the post but it's ignoring the countless number of people who decide to write their own library for X that adds nothing beyond what anything else already does.

Don't reinvent the wheel. Do invent a new type of wheel with more awesome.

It strikes me that Larry Page shouldn't be making this decision about bonuses at all. It should be up to the head of social to make the call about how he wants to motivate his folks. One of the biggest complaints you hear in large organisations is that they don't get to reward their people how and when they want to. Larry Page just made this a problem for Googlers, big time.

I guess the intent behind this law is to make it easy to get to the other accounts on different services that a user might have due to people using the same password for lots of things.

So, upon receiving a request for this you could generate a random password and give that to them (as well as set the user account to this password). They have no way of proving that this isn't their password :)

I've been wanting to make this for ages. Very pleased to see it made!

Would be awesome to have a notable offenders section. A chrome plugin that hooks into this would also be cool: "This site has rubbish password security. Don't use your usual passwords"

What if you log all sent e-mails?

The "best" is way overengineered. I doubt this error-handling will even work. If the program fails to print "hello world" using puts then it is very likely to fail on fprintf to stderr.

Exactly, knowing that Mongo isn't one of these (or at least doesn't appear to be so far) is a comfort :)

Perhaps I wasn't clear... it's not a fault at all, in fact MongoDB is behaving exactly how you'd expect and hope when the dataset gets too large. I just couldn't find anything out there to confirm this :)

Awesome :)