A more useful depiction of the error would be to somehow calculate the bias in the Alexa population (my guess, tech investors are the only segment of the population using the Alexa toolbar, which is incredibly ironic).
Huge error bars on a near zero estimate don't mean a whole lot except that the experiment producing the data is flawed.
Also incredibly ironic. These people are just seeing what they want to see and creating buzz within their own community rather than measuring something useful.
Assuming "calculating the bias" is a well posed question (and I'm not convinced it is) then measuring that bias is a noble goal for alexa engineers. Surely this is a multi-phd-thesis kind of problem though :)
As the author pointed out, the domain was registered five days after his site launched. The domain was registered in bad faith. The owner is now soliciting the author for an offer on the domain name. According to Wikipedia, cybersquatting is 'registering, trafficking in, or using a domain name with bad-faith intent to profit from the goodwill of a trademark belonging to someone else.'
Agreed. Whats being missed here is this:
Registering a domain you think will be profitable in the future : enterprising.
Registering a variation of a domain that someone else just registered because you think you might be able to extort some $ out of them : rotten. No cookie for you.
I expect Matt will have more personal bad experiences, but the most well-publicized one goes approximately as follows:
- Aaron applies to YC, starts Infogami with a co-founder who drops out (presumably because of Aaron's special interpersonal sparkles).
- Aaron launches Infogami, with a promise of a new feature every day.
- Aaron complains for a long time about how he doesn't have a co-founder, and then merges with Reddit.
- Aaron abandons Infogami (pissing off all its users, including me), and then proceeds not to do anything at Reddit, to the chagrin of the Reddits, who just effectively gave him a bunch of their stock. Aaron nevertheless has time for nauseatingly many melodramatic blog entries.
- Reddit gets bought, and Aaron gets an equal share of the spoils.
- Aaron cries in the bathroom (literally), and then quits Wired, the acquiring company, by just not showing up to work. (And posts a suicidal blog entry, and proceeds to delete it.)
- Aaron does an interview in which he claims to have been part of Reddit from the beginning, pissing absolutely everyone off.
Mine wasn't that bad, but it did involve me being told I had an apartment in Cambridge locked up, only to find less than two weeks before Y C began that I didn't.
I think thats a great reason for the Reddit guys to be pissed off at him - I just didn't realize anyone on this forum has had personal interactions with him.
Agreed, so what if his startup fails and he doesn't release a feature per day as he promised? That's what startups (usually) do. They fail. Shouldn't hold that against him personally.
As far as the reddit guys go, there's a reason you're not supposed to do a startup with your closest friends. Aren't you supposed to hate your partner to some degree by the end? I know I did... But I understand that to be normal so I just relax and don't let that anger bother me outside of work.
What I find amusing is that, barring personal interactions, I put Matt and Aaron in the same category - they both have annoying and arrogant internet personas. The only difference is that I believe Aaron is a very talented programmer. The only thing I believe about Matt is that he is an above average poker player. On a personal level, both of them are irrelevant to me.
Good for them. If you're pissing people off, you're probably doing something right.
The funny part is, for most people here, Aaron and Matt aren't reading your blog -- but you're reading theirs! This is like a Denial-Of-Service attack against their competition by inducing them to waste time they could be spending on their own startup instead reading about someone else's.
Id software was a master at this. Everyone was so busy playing Quake, Quake II, etc. that they weren't working on their own games. Did you know actual celebrities are horrible at recognizing other celebrities? They are too busy making movies to read celebrity gossip magazines.
Most of what I said was inferred from the Reddit discussion resulting from the aforementioned interview, and most of the content in that discussion came from people who were actually involved. So, maybe I inferred wrongly; which things weren't true?
Right - this is what I'm about to try to implement (and I think I'd trash the entire queue if a response isn't returned within some timeout limit and display a subsequent error message). I don't know if this is the best practice though and as this seems like a pretty generic AJAX problem, it feels like there should be a pretty generic solution...
I'd like to implement a note-taking system, with an auto-save feature (say, set by a timer). If the requests that go out to the server are received out of order, the wrong state will be auto-saved.
Right - so this would amount to creating queue? Nevermind, I see what you're saying... This is a very specific instance of something pretty general though. Lets say the user edits a note and then deletes it. Do I have the delete action wait for any saves that went out complete first? As the system gets more and more complex it would be something of a pain to try to work out dependencies every time I want to add a new feature.
Yes, queue up the deltas, then only send the full set of deltas every time the timer fires. This will also prevent you from hammering your server with a stream of requests backing up.
Now, lets say I want to stay away from auto-save... The app I'm working on will actually be a widget on the side of the main site and so I'm not confident the user will pay enough attention to know if his/her info has been saved before they navigate to another page. In this case, can I still avoid a queue? I'd want every action a user takes (adding a note, editing it, deleting it) to result in a server request and some spinny wheel notification that the request is being processed. By the way, thank you both for your help!
You don't need a queue.. Just issue the commands as the user makes them. Each command should be separate from every other command, so that order doesn't matter.
I think order does matter - lets say a user types in 'hello' and then saves the note, then quickly changes his/her mind and types in 'hello world' and saves the note. Now the backend will save the version of the note which it receives last, which could be 'hello' depending on network lag.
You should probably use some kind of versioning so that when you receive version 123 and the version in the database is 121, you won't commit 123 until you receive #122.
If the user deletes the note and the server receives the delete request before other modification deltas, simply ignore the deltas that arrive after the delete command.
In my opinion it's a lot more simple to solve this kind of problems on the server side of a web application.
How does one abort the previous request unless a queue is being kept track of? Also, there could have been a few other requests made between the first save and the second save. Its definitely possible I'm just not understanding how XMLHTTPRequest objects work - please do explain if you think that is the case.
Also - I'm not necessarily using XMLHTTPRequest, I'm leaning towards dynamic scripting as my site will need this widget to run across several different subdomains - dynamic scripting doesn't have a lot of the nice status functionality that XMLHTTPRequest does...
When a user needs to save their note
If the note is already saving
Set note.saveAgain = true
else
Start the process of saving the note
When the note has saved
If note.saveAgain == true
Set note.saveAgain = false
Start the process of saving the note again
That doesn't require a queue. It also only saves the most up to date version.
No, you don't wait. You delete it immediately.. If the delete command arrives before the edit command, the edit command will simply fail, which is fine.
Huge error bars on a near zero estimate don't mean a whole lot except that the experiment producing the data is flawed.