simontabor

What does this do that calm.com doesn't do better?

it really, really isn't

Apologies for the lack of support on the chart, SVG rendering is terrible in Firefox.

If you click on the 'Day' view and then 'Show only Mavericks' you can clearly see a rise from 0.20% at 7pm yesterday up to almost 10% at 5pm today. The other lines have had a slight decrease, but yes it does look like Mountain Lion users are upgrading fastest. I'd be surprised if Leopard/Tiger users upgraded quickly as I'm sure they'd be apprehensive of updating their old and potentially fragile kit.

I still don't think you get the idea. Using 'the old lemon man jumped high as a pokemon' across multiple services may be secure from someone trying to hack just you, but it's much more likely that one of those services will leak your password (security flaw of some kind) and will therefore compromise your password across every service.

You could easily just use 'servicename||this is my secure password' as your password, but it's still obvious what the pattern is to anyone who obtains that password, rather than getting 404fC7C426Cb6cD694E6C2Ee828c133fA771AcC8. You should be able to leave your password and email address in public places without anyone being able to have any significant effect on your security (they might gain access to one service).

I may do, it's not too difficult for people who care about it to just take it out - I'd actually rather people take the code, remove tracking if they'd like, edit colours/whatever and make it their own. It's more the concept that I care about (never ever send your main password over the wire)

That's a decent idea, appending/prepending the service name to the hash would probably help.

Yes, but it's by far the lesser of two evils. You can easily take a substring of the generated password.

How would you randomise the length of the password in a repeatable + secure manner?

Sounds like you've misunderstood the purpose of this.

I usually just use a single password across most services, so they all know your password, even if you trust them not to store it in plain text. It's infinitely more secure to use something like PW, never entering your main/master password into any other services and then have a generated hash that really means nothing to anyone (can't be decoded or anything stupid). The length factor here makes very little difference, and only you need to know that you use 40 character password (yes, 40, which I bet is longer and more secure than your current password(s))

It's a repeatable SHA1 hash, what more do you want?

Probably didn't make it clear enough, it's repeatable so you'd use Twitter as the service and whatever password you usually use (master password), it'd come back with a hash and you use that as your Twitter password. Whenever you need your Twitter password, you repeat the process.

https://github.com/simontabor/pw - it's got node-webkit so there's a mac app in that repo and should also work on Windows + Linux nicely (this is simply to take it out of the browser where it's easy to lose tabs and put it in a clean, small window)

Basically, it's for efficiency reasons. Some of our sites have well over 40 pageviews per second and updating the numbers that frequently would put a huge amount of load on our servers and also crash the browser or make it go incredibly slow.

We also like to use the very same API that's available to our users in the Now and Trends dashboards as it encourages us to ensure response times are quick and that everything we track and display can be used programatically in custom integrations (such as the trending section on http://carthrottle.com).

Hope that answers things :)

We monitor if the page is focused or blurred, so you can get both metrics in real-time.

We get a lot of questions at GoSquared (https://gosquared.com) as to why their engagement metrics (and visitor counts) are so different between GA and GoSquared.

Pinging all visitors to check their still online is our solution, rather than making a guess/estimate - this means that sometimes GA reports about 10 visitors online when there are actually more like 100.

This is especially true with HN posts where most people only visit the one page and then leave.

Thanks for the great post :)

There's no server side code at all for this - we're planning on open sourcing our labs section as well soon (and doing more labs projects, of course)

It's way more accurate than necessary... like seriously crazy

nginx doesn't support websockets quite yet, so no, but will do soon - http://trac.nginx.org/nginx/roadmap

Very unfair to be using a t1.micro instance, they're only meant to give very short bursts of power and don't give any dedicated hardware (so giving the hardware specs is pointless).

Do a new benchmark comparison vs a m1.small and it'd be interesting. I bet the small wins by an absolute mile.

Looks like it (also http://bgp.he.net/ip/128.30.52.200). Collateral from Anonymous apparently taking down MIT, I guess

The question mark was unnecessary, yeah - of course I checked to make sure before posting

Does anyone have any news on W3.org and mit.edu? I'm currently left assuming it's an attack after Aaron Swartz's death, which is pretty saddening.

W3.org still appears to be down https://news.ycombinator.com/item?id=5052503

As said in the post, Capistrano is a good option but we found we much preferred deliver, it was easier to setup and meant we didn't need ruby dependencies on node.js apps.

We also used to SSH into our servers and do everything manually. Crazy times.

They're MIT, will be adding the license in a bit

k's thank you for this feedback! I'm on my phone at the moment but I'm going to get back with a detailed reply as soon as possible, we've made a lot of difficult decisions and your feedback covers a lot of it.

Sorry! We're working on improving all areas of the site at the moment.

We've got it so that the image 404's and we listen to the image error event to fade the G in or out.

Nope - you have to sign up and add a picture to Gravatar, it doesn't fetch it from other services/networks.

Possibly, but you don't usually try to login before signing up... right?

Good point - the reason for it is we wanted it to be entirely independent of our users db for security/privacy reasons (and simplicity!)

I'd forgotten I added that easter egg. Ha!