paul

62 ms·

631.
by paul 18y ago
Which parts don't I know well?
632.
by paul 18y ago
Part of knowing a tool is knowing when it's inappropriate. A rewrite in ANY language to "fix" a problem that you don't understand is generally a mistake. Doing things the needlessly complex way doesn't make you a better or manlier programme
633.
by paul 18y ago
This may have been a fun and interesting project for you (and a great way to learn the unix utils), but I wouldn't recommend that other startups follow this path. Rewriting something in C should be the last thing you do, not the first. The
634.
by paul 18y ago
Because real estate always goes up? The "houses are the greatest investment ever" myth is amazingly persistent.
635.
by paul 18y ago
Actually, SUP allows sites to point to a SUP feed hosted elsewhere, so small sites can easily contribute to a shared SUP feed hosted elsewhere. I'm going to write some to provide this shared SUP on top of AppJet as soon as I get a chance. I
636.
by paul 18y ago
The problem is that you still need to poll every single feed. SUP allows you to instead poll a single url. See the "update" note at the bottom of http://blog.friendfeed.com/2008/08/simple-update-protocol-fe... for more details.
637.
by paul 18y ago
Exactly
638.
by paul 18y ago
The SUP feed is designed to be very compact. The SUP feed on FriendFeed ( http://friendfeed.com/api/sup.json ) is only about 8 bytes per entry after gzip. If a service had 10 updates per second (which is faster than Twitter, for example), t
639.
by paul 18y ago
No, Gnip is a complementary service and will likely consume SUP. SUP is intended to make it easier for feed publishers to expose information about which feeds have been updated. Without this information, Gnip can't know when feeds have upda
640.
by paul 18y ago
SUP is conceptually similar, except that instead of pinging a handful of well known feeds, SUP producers declare where their updates are available. Also, by using SUP-IDs instead of urls, the SUP feed is smaller, publishers can keep feeds p
641.
by paul 18y ago
See http://blog.friendfeed.com/2008/08/simple-update-protocol-fe...
642.
Simple Update Protocol: Fetch updates from feeds faster(blog.friendfeed.com)
14 points by paul 18y ago|1 comments
643.
by paul 18y ago
Thanks for the suggestion -- it'll go out with the next push.
644.
by paul 18y ago
This is a great example of why it's important to actually determine the root cause of a performance problem before making any decisions about how to fix it. Performance problems are very often something stupid and not at all what you would
645.
by paul 18y ago
Available at http://beta.friendfeed.com/
646.
by paul 18y ago
The biggest risk (and most likely outcome) with any tech startup is financial failure. The smart strategy is to do things that will boost your odds of success. Hoarding equity is rarely a good way to do that -- you will most likely end up o
647.
by paul 18y ago
But due to the replication delay, that would mean losing data on the primary, and a long delay on bringing the old primary back in sync with the new (since they have effectively forked). Therefore they would only switch the the secondary if
648.
by paul 18y ago
Actually, these are really interesting problems. Multi-homing isn't an issue for most startups though (not that this is true multi-homing since their second DC is read-only, meaning that they can't really survive the loss of the primary).
649.
by paul 18y ago
Even worse, he's writing blog posts in English! (the same language used by millions of semi-literate people)
650.
by paul 18y ago
I wonder if Alabama and Nevada (states with licensing laws) have better spaces than the other states. I'd guess no.
651.
by paul 18y ago
The GET side of REST is usually reasonable and non-controversial. It's the other verbs where things get crazy, with people arguing that you should PUT comments to a document instead of doing a POST to /addcomment (because add comment is a v
652.
by paul 18y ago
The thing is, there's nothing wrong with doing REST-RPC hybrid. The reasonable parts of REST (like making things stateless, using http error codes, etc) are just as reasonable with RPC, and often RPC is the right way to approach an API (bet
653.
by paul 18y ago
Oh yeah, that's right, since jdk1.5. It used to be StringBuffer.
654.
by paul 18y ago
Part of the problem with these REST discussions is that the definition of what is being discussed keeps shifting. The reasonable bits of REST are, well, reasonable, and generally non-controversial. Most of what he describes in this post is
655.
by paul 18y ago
His StringBuffer example is also wrong (the java compiler would automatically use a StringBuffer in his example).
656.
by paul 18y ago
Perhaps, but it still reads like a "kicking the dog" post to me. (also, I don't know if he'd agree with points 4 and 7) BTW, I think the reason his writing annoys me is because startups ARE difficult. The people attempting them have enough
657.
by paul 18y ago
What are his reasonable points? That startups are hard? Everyone says that. If you took out all the insults, hate, and swearing, there wouldn't be much there, and it certainly wouldn't have as many votes as it does (because it would just be
658.
by paul 18y ago
Poor Ted. He spent all that time trashing other people's startups, and now he has to cope with his own startup problems. It must be Paul Graham's fault. Perhaps PG's advice isn't all perfect, and maybe it's not for everyone, but the fact is
659.
by paul 18y ago
I think you're reading too much into the word "typical". It might be better understood as "example" or "typical of what is often found in a datacenter". Notice that all of the actual measured data in that paper is normalized to a value betw
660.
by paul 18y ago
I wouldn't make any assumptions about Google's servers. Public info is generally some mix of inaccurate and out-of-date.

More ›