Facebook: Building the WordPress plugin

WordPress developers will be familiar with many of the problems described here.

I’ve been thinking about this quite a bit lately — writing open source software (where you have a whole variety of environments to support) will be entirely different from working at a company like Facebook (where you probably know more specifically what the servers will look like). Each is going to have his own challenges to think about. Once you get used to developing with certain challenges in mind, it’s probably not obvious what new challenges there will be in a different context.

Spinlocks in Webkit

When I got my first Mac a little over four years ago, the first thing I did was install the nightly build of Webkit. Since then I’ve used a host of different browsers, but recently came back to Safari. This article reminded me why I was using the nightly builds of Webkit back then. It’s noticeably faster and I doubt TCSpinLock is the only reason.

Yes, we really did achieve a 3.7X speedup on a garbage collection benchmark by removing a call to sleep().

Why sleep()?

The original TCSpinLock was benchmarked against ten threads running on four CPU cores. In this environment, one thread could monopolize a CPU core, while the thread holding the lock didn’t run at all. Sleeping a little bit was a simple way to guarantee that the thread holding the lock got the CPU.

Why not just use the standard library locks?

Our spinlocks take advantage of a critical optimization: Knowing they’ll be held for a short time. Since spinlocks never sleep, they recover from contention as quickly as possible. As the profile showed, standard locks are much more conservative, and they may even idle a CPU core.

Using LESS as a Live CSS Engine

It generally just seems like a bad idea to trigger processing of LESS (or SASS) with a page load. Honestly, CodeKit does so much more than just compile your stylesheet into CSS that it doesn’t even seem worth it to me. You should still be generating minified CSS and Javascript as well as optimizing your images. Plus the syntax checking I get on my Javascript. Not to mention all the cool stuff it does with my browser. I’d still be using CodeKit even if I didn’t have to worry about compiling SASS.

Andrew Powers:

One of the coolest things about implementing LESS inside of the framework is that we’re able to dynamically control colors and typography based on user selections. This allows us to design things well, while still giving users the ability to customize colors and type.

Since WordPress 3.4, there is a theme customizer built in that allows you to dynamically control colors and typography based on user selections. Otto has a couple of really good articles on how to use it. The first, How to leverage the Theme Customizer in your own themes, is a good introduction to the customizer. I was happy find that there’s even Javascript that reloads the page within the customizer if you choose a new color so you don’t have to save it and manually reload to see what it will look like (possibly only in 3.5 and up).

Users are able to actually add their own LESS in the admin options panel. They can use common variables for the background color or main fonts.

If your users want to write custom code for their theme, don’t add a textarea to your admin panel that allows them to write code, encourage them to write a child theme — it’s what they’re here for.

Develop for WordPress Locally: Install WordPress

http://youtu.be/v0HJV7t6F-E

In this video I show how to grab the latest development build of WordPress from the subversion server with git-svn. Then we get a copy of the Developer plugin which shows us lots of other stuff we can do if we’re going to develop on WordPress.

Links