Posts filed under 'SxSW'
This sesssion was pretty much standing room only and I came in 15 minutes late.
I didn’t get to really settle in and pay attention as I’d like, so I’ll have to view the slides later (I’ll link to them because they were really frickin’ great)
This jumps around a bit, as I’m writing from memory.
- They talk about memory leaks in IE, I dunno if the newly released Jscript 5.7 addressed what they were talking about
- There was this very interesting part of the talk where they talk about being able to access dom elements using Xpath.
- Apparently Xpath is faster in situations where you want to get all divs of class foo (for example)
- With Xpath … the engine just goes and gets them, with dom it gets all the divs, then loops around and gets the ones you want
- This can be slow when you’re dealing with a lot of elements
- Dojo and prototype support using XPath … jquery (my darling) doesnt.
- Only Mozilla and Opera support this (Webkit/Safari 3 finally added it) of course microsoft is miles behind … poor poor Microsoft
- They talked about trying to isolate bugs to a line of code if preferable, when sending in bug reports
- gzipping your javascript is better than “packing”
- Make sure to set content headers to cache your javascript correctly
- Computing the width of elements is tough because it is hard to know what dimension you want exactly (with padding? margins? without?
Another great session.
March 11th, 2008

Panelists
Kevin Rose | Digg
Cal Hendersen | Flickr
Joe Stump | Digg
Chris Lea | Media Temple
Garrett Camp Stumble Upon
Matt Mullenweg | WordPress
{Discussion: Kevin seems to be moderating}
- Consensus is that you think about scaling when you get there
- Joe Stump says that it (not worrying about scaling initially) helped them concentrate on building cool features
- Software load balancers suck … Squid is highly recommended
- Pound is good for http load balancing
- Joe Stump says that at 15 million pageviews you should start thinking of specializing servers (images, db, static files … that sort of thing)
- Wordpress uses mainly rented server boxes …. 1000 of them (didn’t know that)
- Cal from Flickr says that engineering time is expensive and that if you can just solve the problem by throwing money at it … then you should.
- They recommend that when your development staff grows past 2 people that someone be appointed to standardize code (underscores vs Camel Case)
- TRAC is brought up by Stump … use it if you
- Lea says to document your code. Its actually a monetary issue, time spent figuring out code is time not coding, if you can reduce that you save money.
- Cal cracks a really great joke “What is this documentation thing you speak of?” … “seriously … just hire people that agree with you”
- Question comes up about remote workers … Kevin says that at one point they didn’t care … they hired a guy from the East to help digg scale.
- Matt says his people don’t see each other for months and they get together usually for social purposes more than anything
- Says they are trying to get to a stage where they have users clustered in certain cities.
{Floor opened for questions}
Q: What bottlenecks do you guys usually encounter
- If its not your db then its your file storage (NFS etc) … Cal concurs … says its almost IO … “With a teeeny bit of foresight … you can avoid that” Love this guy!
- Talking about digg architecture … Joe Stump says digg db has 200 tables but only about 2 are problem children
- says one of them has about 200 million records … and the two get the highest 2 read and write requests
- Stump says that your language never matters … Cal chimes in “Unless its Ruby” … the crowd roars in appreciation!
- PS:not sure where this fits, but there is a discussion about how their admin tools are usually not very well done. Joe says that whenever something goes wrong with digg, they usually check with the Admins first to see if they’ve screwed with anything.
Q:recommended software
- Cal says use Ganglia for graphing, puppet for admin. Lea suggests Unin for graphing. Cal says Ganglia and unin are almost the same. LVS comes up.
Q: How do you keep the community from becoming obnoxious
- Kevin talks about giving the community the tools to moderate themselves, talks about the success of the “bury” option.

Q: About source control
- They do pushes at digg from once a day to 45 times a day, but Rose says officially they’ll be pushing twice a month.
- Joes suggests that when you’re ready to push live, you should freeze your code and create a new branch
- This way when something breaks, you can fix the code in the branch and push it live from there.
Q: asks about what they do when they can’t have a local development environment
- Cal says they can’t support a local dev environments because its just too complex, too many moving parts. They just use dev servers. Everyone on the panel concurs.
- Cal: Talks about how Flickr lives on memcached and Squid, suggests taking a look at Varnish if all your stuff is in memory. Says that they have 32,000 requests per second for images.
- Joe: Says they cache things like user objects containing user data (because users barely alter their info after they first get set up)
- Matt: Talks about the use of output caching … says that if you’re getting 20 million page views then caching pages for, say one second, can take you down to about 8 million or was it 800,000 …
- Joe: Talks about queuing. Says that when a user diggs something, they just cache it for that user so it shows up dugg, but they queue it. So a digg might not get into the databases for a few minutes.
- Digg uses gearman for queuing. Cal talks about a “ghetto queue” of cron and mysql to implement queuing. Joe says that’s “housing projects” bad.
Q: about API’s
- I love Cal! He says that there’s something about something about API’s that brings out the stupidity in people. They just try to suck down all your data as fast as possible … where they wouldn’t try to do that with a regular web page. He says that implementing a throttling system is a good idea, to avoid getting creamed by idiots. Did I mention that I love this guy!
Q: any good documentation for using the tools they recommended
- Answer: A resounding NO. Joe says 90% of what he’s learned with open source is by trial and error.
Definitely Worth the price of admission!
March 11th, 2008
Today was terrible … the weather was nasty (cold and rainy) and I forgot my badge at home.But one of the more interesting panels was the Design Eye for the South By.
In it a group of designers, got together to redesign the current SxSW website. I really loved the concept they came up with, which was to personalize the site for each user and throw in a social networking component to it, sounds cliche but read on …
For example, you’d log in and the navigation would look something like this
PEOPLE | EVENTS | PARTIES
Which really encapsulates the main things you come to SxSW to do
- meet people
- go to events/films/shows
- go to the parties to network
On the events page, you could add events to your schedule. And on the parties tab you could pick parties you were interested in. The parties all came with Google maps too. I thought it would have been cool if they had something like that for the events … to help you find the rooms for each one. But they did the thing for free, so one can’t be picky.
What I really liked was that because of the social networking component, you would login and be able to find people you met and “friend” them.
Then you could view their profiles and see what events they were attending or what parties they were going to be at. Usually (people won’t admit it) that actually affects your choice of the things you’re going to see or parties you’re going to go to.
Of course my imagination started to run wild at this point. Say you were stuck in a sleep inducing session, you could hop online and link directly to a friends meebo chatrooms of his/her session, to see whether theirs was more interesting, and make the gametime decision about whether to ditch your session for theirs.
I also thought It’d be cool if you could just keep your profile and re-use it every year for registration and payment etc …
The whole presentation was very good natured and funny, and the design was very simple but effective.
Hopefully SxSW takes them up on their design offer, because adding events to my SxSW schedule, they way the have it currently, is a pain and a half.
The results of their work will be posted at Designeye.org
March 10th, 2008
Sitting in the 37 signals presentation. They’re going to tell us about the lessons they’ve learned over 10 years being in business.
I’d guesstimate about 1000 - 3000+ people in the auditorium.
Here’s what they say …
- Don’t worry about the unknown:
Point here being, don’t worry about trying to build something that takes care of every single scenario. Do what works now and change later. Optimize for now
- Red Flags:
I didn’t know that half the 37 signals team was remote … apparently 5 of them are based out of Chicago and 5 are other places
They talk about the things we say that can be detrimental to the team … simplified
Only: It’ll only take a few hours right?
Can’t: We can’t launch without it
Need: We really need it.
Easy: Hey Sam can you take care of this by Friday … it should be easy right?
Fast: Can you take care of this real fast.
- Be successful and make money by helping others be successful and make money
- Target nonconsumers and nonconsumptions
A nonconsumer is someone who has a problem but the solutions for the problem basically suck.
This is an opening for you as an entrepreneur to go in and solve their problem.
The upside is that the entrenched players who suck at solving this problem won’t try to fight you on it, you fly under the radar … picking up loose change.
- Question your work regularly
Why are we doing this?
What problem are we solving?
Is this actually useful?
Is there an easier way?
- Fix your copy
The “internets” is inundated with crappy copy writing … that directly affects the way your user views your app.
Consider a rewrite of the site first, before a redesign.
- Err on the side of simple
Start with the easy way first. Use craigslist before Monster. Rewrite just that module, not the entire app.
The longer you sit on something, the less likely you are to launch it.
- Invest in what doesn’t change
What works today and will work ten years from now.
Google invests in speed and better search results. Amazon invests in fast shipping.
For 37 signals, its investing in simple software. What is it for you?
- Share
Share what you know. That way you become an expert and people come to you.
(I had a problem with this one … and think its only true to a certain extent)
- Minimize interruptions (they kill productivity)
Joel Spolsky has talked about this before in one of his posts. But being close to someone gives people the tendency to interrupt each other.
“Hey … check this out?”, “Lets have a quick meeting”
This wastes time and kills productivity … people need blocks of time to work through.
Think of more passive communication like IM or instituting “no-talk” blocks of time
- Roadmaps send you in the wrong direction
They lock you into a path.
“Its OK to think about the future, just don’t write it down”
- Be clear in crisis
People just want to know what is going on. So be open, honest, public and responsive.
- Make tiny decisions
Achievements build momentum. When you make small decisions, you can’t make big mistakes.
- Make it matter
Be passionate about what you do.
Respect your time … don’t waste it on stuff that doesn’t matter.
March 8th, 2008
Woohoo!! First full day of SxSWi.
Missed the morning sessions but got in to see a sneak peak of Expression Engine 2.0 (latest version 1.6).
Its hard to describe, but version 2.0 is amazing, almost everything has some kind of neat little effect on it. Things seem to be organized in a very different (but seemingly more intuitive) way from most other CMS’s. And I mention that it looks gorgeous … completely web 2.0′ed out.
I’ve never been a fan of Joomla, but it looks like the folks from Ellislabs have a winner on their hands.
Its that good.
No word when it’ll be out though.
March 8th, 2008