• 

• 

• 

My wife was kind enough to get me a fancy baking steel 5-ish years ago as I was starting to get more serious about baking pizza. Previously I’d just been using flipped over casserole dishes as ghetto pizza stones.

We moved into a new place a while back where I bought a big fancy oven that’s 90 cm (about 36″) wide. All of the sudden I could potentially bake two pizzas side by side.

Looking at a pizza steel it’s pretty obvious that it’s just, you know, a big sheet of steel. I’d suspected using a big chunk of 6 mm (1/4″) thick steel would work just as well as a pizza steel, and predictably, be a whole lot cheaper.

My small single pizza steel was around €80. My double-sized (66 x 33 cm x 6 mm) hunk of carbon-steel was €30.

To prep it, I filed down the corners with a standard wood / metal file. That took about 10 minutes, and should make it somewhat less dangerous to people and cabinets. 10 kg (22 lb) of steel with pointy edges is a wee bit scary.

Then I just seasoned it with linseed oil like cast-iron or carbon steel cookware, and tah-dah! It worked wonderfully. Arguably better than the pizza steel it replaced. (Probably simply because of sheer additional mass by being double the size.) Pictured are the first two pizzas I cooked with it.

The steel I used was just something I’d grabbed from the German site Blechking, which e.g. for a 33 x 33 cm (single pizza size) you can get a pizza-steel-ersatz for €16. Obviously this is even more exciting if you want to get multiple steels or special sizes to exactly fit your oven. It’s notably non-stainless, low-carbon steel: the same stuff that’s common in professional cookware.

(This post is extremely boring, but written for the benefit of people Googling this exact problem.)

Usually when I buy a new Macbook, I buy the top of the line small-ish model. In 2011 that meant a Macbook Pro 13″ with a 2.7 GHz i7 processor. Since it’s from back in the good old days, when you could update the RAM and disk with aftermarket upgrades, I’ve also swapped in 8 GB of RAM and a 1 TB SSD.

In theory, this should still be a pretty decent little machine. In fact, Apple was selling a very similar model (same chassis) until about 4 months ago. And it should still beat the pants off of a the current non-pro Macbooks.

When I bought my current Macbook Pro, I paid €1200. It looks like my next Macbook Pro will be more than double that, so I’d like to stretch out needing such as long as possible.

However, my Macbook Pro has been underperforming for at least the last year. Compile times on C++ projects felt like they’d gone up, while my machine had gotten noticeably louder (the CPU fan, specifically).

Usually when that happens, it meant that I need to open up my laptop and clean the lint out of my CPU fan exhaust — a pretty easy operation. I did that about 6 months ago, and it did, in fact, make a big difference. Compile times went down by about 20-30%.

But still my machine wasn’t hitting the CPU frequencies that it was supposed to. The fan was revved up too often.

If your 2011 Macbook Pro does the same, then this post is for you.

I eventually stumbled across reports that the thermal paste application on Macbook Pros from 2011 was less than ideal. I have no idea if it was a poor initial application, or simply 6 years of time, but swapping out the thermal paste made a massive difference in CPU performance and fan usage on my laptop.

Compile times for a medium-sized C++ project sped up by 23%. CPU fan usage went down significantly (the machine is much quieter now). The CPU far more frequently hits its top Turbo Boost frequency of 3.2 GHz, while the resting CPU temperature has dropped from around 85ºC to around 70ºC.

Here’s what building the same C++ project before and after looks like:

Note how often the CPU frequency before was below the nominal 2.7 GHz rated frequency (the solid grey line) vs. after.

I followed the iFixit How-To. If you’re seeing similar performance issues with a Macbook Pro from that generation, and are reasonably handy with electronics, I’d recommend the same.

I should add the proviso that my previous laptop was consigned to the recycling pile during a similarly invasive repair operation (though it was also 6 years old). If you’ve considering jumping into this, keep in mind that it’s possible that you’ll break something on the way.

A couple days ago I released a Wikipedia Beautifier for Chrome inspired by Readability. It was my first exploration into the world of Chrome extensions (which turned out to be surprisingly straightforward). There’s still a rough corner or three to round out, but it makes Wikipedia much easier on the eyes. The internet loves it, and I’m sure you will too.

Or, “Why using send doesn’t work as exptected”

So, I’ve been banging away at a Rails plugin the last few days.  One of the things that I initially did was to add an initializer that extended the models from the app to avoid needing to muck-up the model, e.g.:

[project root]/config/initializers/acts_as_foo.rb

SomeModel.send(:acts_as_foo, :bar)

It seemed so clean and elegant. But I noticed that my class variables were being trashed when I tried to access them and was befuddled for a day or so.

It turns out what happens is that Rails reloads all of your models (and, in fact, all classes) for every request while in debug mode. At some level in my brain I knew that, but it didn’t click that when that happens initializers aren’t fired as well, so anything that’s being fired from an initializer that will be trashed on reload won’t be there after the first request. (Though it works in production mode.)

Eventually, after much debugging, it clicked what was happening. But I wasn’t quite content to just burden plugin users by modifying each model. I stumbled across this StackOverflow entry which suggested you could achieve the same by modifying environment.rb’s config block. But really, that just shifted the inelegance around. However, the to_prepare bit set me along the right path.

The elegant solution that I eventually found comes from using the dispatcher:

require 'dispatcher'
Dispatcher.to_prepare do
  SomeMode.send(:acts_as_foo, :bar)
end

And there friends we have it: a way to send something to a model from an initializer that will be reloaded every time classes are loaded, or only once during production mode, and every request in development mode.