In this episode of the Stack Overflow podcast, Joel and Jeff discuss reverse proxies, the pitfalls of self-support communities, and designing for engagement.
- It is my intent to attend the London and Cambridge DevDays, if my passport comes back in time. Speaking of which, is there anything funnier than a baby’s passport picture?
- We officially disabled the built in ASP.NET Session state, so as to set ourselves up for multiple Stack Overflow servers. Fortunately, we don’t need a lot of shared state, but we were using it in a few places. We created a small database table to store the small bits of per-user state that we need.
- I take an inordinate amount of joy in deleting code from our project. Nothing is more satisfying!
- To switch over to multiple servers, we need some kind of load balancer. We chose HAProxy, but we also had to configure tproxy (transparent proxy) support so that the IP addresses arriving at the web servers are not all the same.
- For now we’ll be load balancing using a simple hash of the incoming IP address. Depending on which hash you get, you may end up on a different server, but you’ll stay on that server as long as your IP address is stable. This is a fairly crude form of balancing, but should be sufficient.
- It’s incredible how aggressive Google’s indexing of our site is; it regularly pulls down a gigabyte of compressed text from us per day, and it wants to do even more. One of the primary motivators for adding a second server is to reduce the traffic load enough so that we can “unleash” google via webmaster tools.
- A belated welcome to our newest and third site in the trilogy, Super User — it’s for any general computer software or hardware questions, but we’ve already had to disallow videogaming questions.
- How much overlap will there be between our public websites, and the sites launched through the Stack Exchange service? But remember, the software (however great it may be) is the easy part. Building a community is the truly difficult part! To succeed, that’s what you should focus on.
- Joel discusses the shifting meaning of “Beta” — it’s been contorted into “the first five years of a product”. But there is an art to the classic beta, in terms of releasing in a staggered fashion to fresh testers who haven’t seen it yet.
- Google’s self-support model is often unsatisfying because it is community driven, yet the community is powerless and has no real stake in developing the product. They’re given padded rubber rooms to bounce around in harmlessly. That’s not a good way to build community.
- Google needs a lot more evangelists out there interacting with the community and bringing messages back and forth to the mothership. This is something that Microsoft does extraordinarily well, but Google does not seem to “get it”.
- A brief discussion of some key changes to (hopefully) increase engagement between question asker and answerers. The goal is for answerers to be able to quickly scan a question and see if they’re dealing with someone who cares, or not.
- The default votes answer sort order had a flaw: the sub-order was relevant! We now use random as the sub-order to the votes sort, to minimize any effect of the sub-order. Answers will now appear in random order if they have the same number of votes. Answers should be voted up because they’re inherently good answers, not because they happen to accidentally be on top at that particular moment.
We answered the following listener questions on this podcast:
- Nathan Long: “Is it valid to discuss iPhone and Blackberry questions on Super User?” This has been discussed on meta.
- Brian Kelly: “Is there any formal organization for potential candidates to meet employers at DevDays?”
If you’d like to submit a question to be answered in our next episode, record an audio file (90 seconds or less) and mail it to [email protected]. You can record a question using nothing but a telephone and a web browser. We also have a dedicated phone number you can call to leave audio questions at 646-826-3879.
The transcript wiki for this episode is available for public editing.
Comments