Made with 🧀 in Madison
http://soundcloud.com/andrewmcmahon/wrecking-ball-heart
It’s worth reading the full description on Andrew’s blog, but here’s an excerpt that I especially liked.
We weren’t making an album, and like the early days there was no label in place to release it. Just friends in a space playing music.
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.
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.
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.
http://youtu.be/9ysvwH30j3o
The first of a series where I talk about setting up a local environment to develop for WordPress.
I don’t use MAMP like many other people do, but instead run everything in an Ubuntu virtual machine with VirtualBox. There are a few things we need to do to make this setup practical, like give ourselves a local address to connect on and set up a shared folder between the host and guest OS. Then we’ll set up Nginx with PHP-FPM and MySQL so the server is ready to go for WordPress.
In the next video, I’ll download and install a development version of WordPress along with some plugins that make development much easier.