Version Control Themes with Git

http://youtu.be/B9Qny9cU1Ws

I really like being able to deploy my current theme to production from my local environment. I can test locally and then deploy to the live site when I’m ready.

Some people like to keep all of WordPress under version control. I don’t think that’s useful unless you’re a WordPress developer. You’re unnecessarily tracking changes to WordPress and your environment. I like to keep each theme and each plugin in it’s own repository. They’re separate projects so they should get separate repositories.

I constantly go back to this great tutorial when I have to set up a bare git repository on a production server.

Speaking for Yourself

As always, Merlin’s advice can be generalized to many different jobs. Whether you’re a freelance photographer, graphic designer, writer, speaker, etc., I think lots of people have a problem knowing their “price”.

As Merlin says:

This part sucks and is nearly impossible to get any good at for a year or five, but it’s something you simply must tackle with increasingly less fear and hesitation.

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.