I’ve been reading Eran Hammer-Lahav’s intelligent posts on microblog scalability, and now I’m concerned about my own “microblog” site, Picofiction.
Similar to social networks, social updates, social messaging, social… Like many social web sites—amongst our weaponry…—Picofiction lets you “follow” your favorite authors, displaying all their posts along with yours.
I handle this very naïvely: everything is offloaded to the database. There are three tables involved here, one of users, one of posts, and one of follower/followee bindings.
Here’s the basic structure of this query:
SELECT post_id, post_body, post_date, post_type, user_name AS author_name, user_id AS author_id FROM posts LEFT JOIN users ON posts.author_id = users.user_id WHERE author_id = 'CURRENT_USER' OR author_id IN ( (SELECT followed_id FROM followers WHERE following_id = 'CURRENT_USER') ) ORDER BY post_date DESC LIMIT PAGE_START,20;
Here’s where I need help: this works great on a single database, but it does not scale horizontally.
Since this horizontal scalability is such a hot topic right now, I’m asking for ideas. I’d like to put in the infrastructure before there is a need for it.
Eran points out that caching is not as simple a solution as we’d like to think. What do you cache? How do you keep caches in sync?
Does anyone have experience with MySQL Cluster Servers? It seems like the best way of scaling is to make the process as parallelizable as possible. The database then handles the parallelization, so the less I can do in the program the better, right?
A debate has cropped up over “designed by” links, those (hopefully) little links a designer puts on a page to take credit and get themselves some traffic and customers.
On the one side, Pat Dryburgh argues word-of-mouth is superior to self-advertising: “If the design is good enough, they will ask my clients, and if they like me enough, then they will tell people about me.”
In rebuttal, Sophia Lucero at wisdump.com claims your “designed by” link should be like a Louis Vuitton logo: “Your brand should never hurt your creations, it should enhance them”.
To me, there is an issue of “ownership” to consider. If I put my name on something, I take responsibility for it as much as credit. My name means “I did this, I’m proud of it, and I want to be associated with it.” I think we’ve all done work we’ve left our names off, because we were rushed or a client demanded changes in spite of our best advice or… well, you get the idea: we weren’t proud of it.
So what do you do? Are you a “designed by” designer? Do you stick to code comments? What if you’re a back-end developer?
Edit: I should link Chris Brogan’s series on personal branding. It definitely applies to this question.
The premise of Design Patterns is that similar problems have similar solutions. In the same vein, I propose this Work Pattern a set of common steps I use when I create a web site, and maybe you can use, too.
My first step is usually to create an un-styled outline of a “typical” page. I fire up my editor, fill in the basic XHTML, and then go to work inside the <body> tag.
Most sites have this fairly common structure: header, content, footer. And just for fun, let’s throw in navigation between the header and the content. It’s pretty easy to represent this in XHTML:
<div id="header"> </div> <div id="navigation"> </div> <div id="content"> </div> <div id="footer"> </div>
This is my first skeleton for >90% of the sites I design. It’s a very standard document. Sometimes navigation will be inside the header, but most often it goes like this.
Now you have to start thinking about what elements will be on the page. On this site, a blog, I used “articles” instead of “content” for the main div. I also added two side bars, and I knew that inside the articles div I’d want, well, articles.
<div id="header">
<h1>Page Title</h1>
</div>
<div id="navigation">
<ul>
<li>Link 1</li>
<li>Link 2</li>
</ul>
</div>
<div id="articles">
<h2>Recent Articles</h2>
<div class="article">
<h3>Article Title</h3>
</div>
</div>
<div id="theblog">
<h2>Sidebar heading</h2>
<p>Sidebar paragraph</p>
</div>
<div id="theworld">
<h2>Sidebar heading</h2>
<ul>
<li>Sidebar</li>
<li>list</li>
</ul>
</div>
<div id="footer">
</div>

I won’t bore you with more code examples; I think you get the idea. I make an outline. I know at this point that my source is nice and valid, and that it will make sense when I turn off the stylesheet. I use semantic names for everything.
It’s not very pretty, but I now have a workable XHTML document, with a properly-nested outline, and most of the important elements. Good for me, because now I can start to style them.
Now, I know what visual elements will need to go on the page. I know what page elements I need to style. Now I’ll start creating a style sheet.
My first style sheet will contain a few basic HTML tags and the elements of my document. I could probably write an XML-to-CSS generator with how strict I am with this step.
Ok, one more code example:
body {}
h1,
h2,
h3,
h4,
h5,
h6 {}
a:link {}
a:visited {}
a:hover {}
#header {}
#header h1 {}
#navigation {}
#navigation ul {}
#navigation ul li {}
#articles {}
#articles h2 {}
#articles div.article {}
#articles div.article h2 {}
#theblog {}
#theblog h2 {}
#theworld {}
#theworld h2 {}
#theworld ul {}
#theworld ul li {}
#footer {}
One of my favorite things about this is it’s almost impossible for a mistake in one section to mess up anything else.
But obviously there’s a lot in there I can combine, can shorten. Almost anything that’s true for #theblog will also be true for #theworld in this case, so DRY, and keep things together as much as you can. But, when you’re just starting the style sheet, this is a good place to start.
As I’m going, I add a lot to the style sheet. I also add a lot to the XHTML template. Pixels get tweaked left and right and I swear at IE6, of course.
Once I have a complete, or near-complete, mock up, it’s time to start building templates for your CMS of choice. This is mostly copy-and-paste work at this point. Your #header and #navigation go into the header template. #footer goes into footer. #content goes in the content template.
See how easy that is?
Then you get to go through and actually add the template mark up. Whether it’s Smarty or PHP or ASP doesn’t really matter, you just replace your dummy text with the right tags.
I love this process, but there is one thing you really need for it to go smoothly:
You need to know what kind of content you’ll have. When you’re redesigning your blog, or building an in-house site, it’s pretty easy to know. When you’re working for a client, you may need to twist some arms to get this information. (I love this A List Apart article for advice on communicating with clients.)
One final thought: use comments. Any time I create a div, I wrap it in comments like this:
<!--begin #articles --> <div id="articles"> </div> <!-- end #articles -->
I usually use the CSS selector because it’s specific, so #articles, .article, and so on. These comments—which I left out here to save space—have saved me so much time and effort compared to relying on indentation that I can’t imagine working without them.
I didn’t set out this process as a way to streamline my work, but rather, as I started noticing patterns that worked well, I started thinking about the process. Much like Rails, which was already running Basecamp before it was a framework, I’ve been using more-and-more-polished versions of this work flow for months.
Maybe you’ll find it helpful, maybe not. Maybe you already have a “system” in place. If you do, what is it?
“If you wish to be a success in the world, promise everything, deliver nothing.”
If you want to remain the standard-setting body for the web, promise new recommendations, never deliver. Read the rest of this article »
I wanted to put something specific in the title, like “Speed up your service” or “Reduce server load” or “Limit database calls” or… You see why I chose “Better Living.”
Memcached is a memory caching system with an obvious name. It allows you to store basically any data that can be serialized into a giant, memory-resident hash, then retrieve it with its unique key.
Imagine not querying your database on every request, and you only begin to get a sense of how useful this is.
Let’s go through a simple, single-server setup. Read the rest of this article »
Follow Me