Disqus - Latest Comments for bretthoerner

Re: IDE's Are a Language Smell

Brett Hoerner — Sun, 28 Oct 2012 16:13:24 -0000

Raganwald said (I believe in this talk http://www.infoq.com/presen... ) that (paraphrasing) "any feature your IDE has is something your language should be doing to begin with." I think a big thing Scala, Haskell, Clojure, etc have going for them is pretty solid REPLs.

Re: The Cloud is Not For You - David Cramer's Blog

Brett Hoerner — Sat, 02 Jun 2012 18:28:03 -0000

Well, Heroku is one (big) level up the abstraction stack from EC2. EC2 has just about as much insight as Softlayer (if not more).

Cost vs Performance of 1 machine will never be in the cloud's favor, and I agree I may be in the 1%. I think at the Disqus level you would win with Direct Connect [1] for big fat Postgres instances and a bunch of Cloud workers/webs.

[1] http://aws.amazon.com/direc...

Re: The Cloud is Not For You - David Cramer's Blog

Brett Hoerner — Sat, 02 Jun 2012 18:16:00 -0000

The elastic computing part is underrated and I disagree that it has to be infrequent. I autoscale webservers and (more importantly for our business) what we call "analyzers" that take input streams in realtime and apply all kinds of complex rules to them to source material. At Disqus I guess these would just be considered 'queue workers', except our demands scale from very low to very high *every day* and hits random unexpected peaks when things happen around the world.

The equivalent of what we do for Disqus would be sleeping through the news of a new iPhone announcement - thanks autoscale! :)

I guess my point is: we pay a tax per machine to run on EC2, but autoscale saves us more money (especially in human time) because it scales down at night and up for peaks (even big events) without paging me. Not every business has this need... but "the cloud" (I still hate the term) is awesome when you do.

Re: PyCon Minisite Feedback

Brett Hoerner — Wed, 07 Mar 2012 14:13:29 -0000

Disqus??? FEH

Re: http://thecallus.com/post/18286319232

Brett Hoerner — Mon, 27 Feb 2012 20:42:40 -0000

Pretty cool blog, man.

Re: Standalone Heroku Postgres’ Unanswered Question

Brett Hoerner — Thu, 15 Dec 2011 10:29:41 -0000

Isn't Heroku 100% EC2? So wouldn't purchasing a standalone Heroku Postgres instance in the same availability zone be exactly like being in the same DC (latency and partition-wise)?

I think of it *exactly* like RDS but for Postgres. I don't think people outside of EC2 would/should want to use it.

Re: MattDeBoard.net

Brett Hoerner — Mon, 28 Nov 2011 13:03:18 -0000

I just constantly degraded him, to be honest. http://en.wikipedia.org/wik...

Re: The Riak Recap Blog

Brett Hoerner — Wed, 10 Aug 2011 12:04:52 -0000

DISQUS is hiring backend developers that want to work on projects at scale. We use Riak, Redis, Postgres and lots of Python.

http://disqus.com/jobs/

Wow, this comment is pretty meta.

Re: Embed Test

Brett Hoerner — Tue, 09 Aug 2011 17:14:43 -0000

testing riak sessions

Re: Embed Test

Brett Hoerner — Tue, 09 Aug 2011 16:37:51 -0000

gfreg

Re: Redis at Bump

Brett Hoerner — Mon, 18 Jul 2011 14:30:22 -0000

Related, as Bump's post urged me to write this: http://bretthoerner.com/201...

Re: Django at Scale slides | Brett Hoerner's blog

Brett Hoerner — Mon, 27 Jun 2011 15:50:52 -0000

25/26: The race problem I cited is because we used to delete. Imagine another user in transaction + miss on cache you just deleted = select old value from DB (transaction) and then set it. Wouldn't add almost always fail for the update DB/update cache scenario?

28: Yeah, avoids hitting memcached again in the same request. The example is a very active page and multiple gets of same key per request. It's not about speeding up a single user's response - it's about the fact that simple bandwidth to that one memcached server can make it unavailable.

31: We use pgbouncer, I'm sure for good reasons that I know nothing about. :)

34: Yeah, I thought it was. It turns out we hacked his into the model metaclass and made some other changes.

35: Right, just normal locking pain. Booleans are just the most common and easiest to fix. Certainly no silver bullet for other needs. We often add brand new tables... :( But we're moving to sharding now, so alters are easier ... but code is harder. :)

Re: | Brett Hoerner's blog

Brett Hoerner — Mon, 13 Jun 2011 10:42:11 -0000

Only because it's across the street from us. I prefer Bouldin (linked above) to both.

Re: | Brett Hoerner's blog

Brett Hoerner — Mon, 30 May 2011 14:04:52 -0000

Red River isn't far, it intersects 6th. :)

I figured "the streets around 6th also have bars and are often better for actually lounging in with friends" covered it, thinking of Bull McCabe's as my personal example. Elysium seems too niche to mention in a general list.

Re: MattDeBoard.net

Brett Hoerner — Sat, 07 May 2011 09:57:06 -0000

lolirl at the graph

Re: [Poll] If we switched to Livefyre for comments…

Brett Hoerner — Thu, 05 May 2011 20:52:00 -0000

@Alaukik you type @ and start typing a name like "Benjamin."

Re: [Poll] If we switched to Livefyre for comments…

Brett Hoerner — Wed, 04 May 2011 16:06:12 -0000

Benjamin, we don't limit premium services by views. The $19/mo plan should work for you, and also provide analytics and more. If you're having issues enabling a plan please let us know.

*Goes back to developing Disqus on Ubuntu*

Re: [Poll] If we switched to Livefyre for comments…

Brett Hoerner — Wed, 04 May 2011 13:31:36 -0000

@Benjamin Humphrey : Disqus added @mentions, for what it's worth. :)

Re: MattDeBoard.net - Latest work

Brett Hoerner — Tue, 22 Mar 2011 16:50:59 -0000

I FORGOT MY YUK PASSWORD.

Re: Redis at Disqus | Brett Hoerner's blog

Brett Hoerner — Mon, 28 Feb 2011 10:29:01 -0000

We generate the keys ourselves. If a user visits /analytics/ then we know what forums they have permissions to see, and we're able to use the list of forums to generate the keys. If they visit /analytics/myforum/ then we only need to fetch data for "myforum". Using the `keys' command would be pretty hard with dates anyway, if they asked for Feb 1 - Feb 4 I'm not sure how I'd avoid doing at least 4 calls to `keys' per stat.

I hope to do a follow up with code as soon as time and motivation align. :)

Re: Redis at Disqus | Brett Hoerner's blog

Brett Hoerner — Fri, 25 Feb 2011 14:02:00 -0000

We did, but the problem was that Redis wouldn't stay anywhere close to the bounds we set. Plus there is no advantage in using Redis over Membase in the case of naive (data structure-less) K/V storage.

Re: Redis at Disqus | Brett Hoerner's blog

Brett Hoerner — Tue, 22 Feb 2011 14:25:06 -0000

Sure, but we actually haven't had to tune much of anything. This is random conf from one of our shards, apologies for random order, I just grepped out the default comments and sorted/uniq'd it: https://gist.github.com/839193

Re: Redis at Disqus | Brett Hoerner's blog

Brett Hoerner — Tue, 22 Feb 2011 14:20:12 -0000

We use Flot and some other tools. My coworker DZ replied in more detail here: http://news.ycombinator.com...

Re: Redis at Disqus | Brett Hoerner's blog

Brett Hoerner — Mon, 21 Feb 2011 19:05:23 -0000

There's a lot more discussion on Hacker News: http://news.ycombinator.com...

Re: Redis at Disqus | Brett Hoerner's blog

Brett Hoerner — Mon, 21 Feb 2011 18:25:50 -0000

It's not easy, actually. The short answer is that we don't add capacity (because we've only needed to once, and we have tons of room to grow now). The long answer is that I have a switch I can flip that starts incrementing/adding data to a whole new cluster of Redis nodes while it still updates the old ones. We can then backfill all data to the new nodes and when they're setup, flip a switch to read/write only from/to the new nodes. It may sound a bit weird, mostly because it is. Moving sets of random keys from one node to the other while you're expecting live reads/writes is a huge pain, so I just punted on the problem.

It really helps to plan ahead here. What's nice about Redis is that each running (software) server is very, very cheap. When we had to expand the first time, we just put up way more nodes per server than we expected to need. Say you have 5 servers and put 8 nodes on each. They're all splitting the server's resources by 1/8 (effectively), but your code can logically treat them like 40 servers. Now as they grow you can just move those existing (logical, software) servers to their own hardware without changing your hashing at all. In other words, you'd have to fill 40 physical servers worth of RAM until you really feel more pain about having to add new nodes.