We built a standing desk!

I’ve been interested in having and/or building a standing desk for years. It probably started with this article in Wired. The main reason for not getting one, however, was having invested in a corner desk piece with an extension for the purpose of housing two workstations side-by-side, one for me and one for my wife. We already had something, and I didn’t really want to build something new that wasn’t at least using the thing we had. It was, after all, perfectly functional.

2 workstations, one really big desk
See how functional it is?

When health and lack of exercise became a concern, I switched from what I still consider to be the best computer chairs in the world (Herman Miller Aerons) to exercise balls with the idea that it could also help my posture. Pro Tip: Exercise balls do not help with your posture. Only you can help your posture by making a choice to stand (or sit) straight. Excercize balls keep you from slouching, it’s true, but I end up hunching forward instead.

Then came all the doomsaying articles about how sitting for 8 hours a day is killing you. And this brought the discussion of a standing desk back onto the table. The only question was how.

I looked at a lot of DIY standing desk setups. I knew I was going to do some kind of IKEA hack, but IKEA has changed their catalogue around since the Expedit was the go-to line for DIY standing desk hacks. We recently redid our living room/TV area with Kallaxes (which seem to have replaced the Expedit), so I decided to go with that. Now, Kallax is either a 4 square by 4 square wall, a 2×2, a 2×4 or a 1×4. In a perfect world, we could do a 2×3.

All the Kallax things...
All the Kallax things…

This, of course, isn’t a perfect world and so we make do with what we’ve got. Even though a 2×2 Kallax is a little narrow for 2 monitors (one of them being a 27″ iMac), the alternative (a 2×4) would have been far too wide for the space we were going to put it in. The base is a Lack coffee table. For the keyboard trays, I just used the ones on the old desk, then didn’t put in the middle divider in the top shelf in the Kallax, snipping off the top of the dowel and hammering the stub back into the hole, then used the existing screws to screw the slider into the top of the Kallax. It sticks out a bit in back, and the tray is just a bit too wide to slide into the Kallax, but you don’t really notice it much.

We got two chairs for the standing desk partially for the kids to be able to use the computer and for whenever necessity requires sitting. We got the Franklin bar stool which isn’t hideous but is a tad low for the tray. The whole IKEA trip (2 Kallax, 2 Franklin stools, 2 Lack coffee tables as well as a bunch of miscellaneous stuff we got while we were there) was about $250.

I did a ton of research in terms of heights and proportions and where things should be for optimal ergonomics, then compared all that with IKEA’s online catalog to get an idea of what the possibilities were. The base was really the hardest part to figure out, and we just happened to stumble on a Lack that was the right size when we were in the warehouse. Since I already knew the measurements we just grabbed it and it seems to have worked out pretty well. I considered getting a mount for the monitor(s). Except my Acer secondary monitor doesn’t have mounting brackets, so that’s a no-go. I could mount the iMac (heavy as it is), but I don’t really think I need to. I thought maybe I’d need to have it hanging over the side more so I’d need more space, but with the two monitors at an angle like they are, it seems to work out with the space i have.

I’m now into day 2 of actually using the standing desk. I find that I move around more (which, you know, is good for someone who doesn’t move around much because they are coding all day), especially if there’s danceable music playing. My legs and feet are sore, of course, but that’s to be expected and it’s not anything untolerable. I also expect that, as I get more used to the new setup, my body will be more accustomed to standing and I won’t be as sore at the end of the day. It’s certainly better (for my health, if nothing else) to end the day sore from standing than to end the day stiff and unable to move from sitting.

The other bonus (and the reason why we did the Kallax + Lack for these two desks) is the extra storage space. All the crap that was just randomly all over the desk was either thrown away, put into storage, or found a home (with room to spare). I might end up getting monitor stands at some point for the two KRK monitor speakers currently under the keyboard tray but for now, this works. The boom for my microphone is mounted to the back of the Kallax and comes down over the second monitor when I need to use it, and I think it actually ends up being positioned better than the way it was before when it was coming from the side of the desk. I can’t tell you how much I love that boom. It’s all kinds of perfect.

Full specs:

Kallax shelving unit (slightly modified) – $34.99
Lack coffee table – $19.99
Franklin bar stool -$34.99

Mic & boom (in case you’re wondering):

Rode Podcaster – $229
Rode PSA1 Swivel Mount Studio Microphone Boom Arm – $99

Making theme options modular

Today I submitted version 1.1 of Museum Core to the WordPress theme repository for review. Originally this was going to just be a simple update with some bugfixes, but I had thought of a way to make it easier to build child themes that include some options settings from the parent theme (Museum Core) without having to include all of the options from the parent. It started out with this ticket I created on GitHub.

Now, the ticket evolved from that first sketch of an idea, and I ultimately abandoned the concept of using actions and remove_action to change what options get used. But the current approach is, I think, a pretty powerful way to approach theme options development so that things can be reused or abandoned in child themes and it isn’t something that I’ve seen other people doing. (To be fair, this is actually what’s described in the WordPress Codex, but I haven’t seen it in action on very many theme options pages, or any tutorials talking about how one would go about writing a theme options page, so I thought it was worth writing about.) And it reduces my entire theme options down to this code:

So let’s take a look at what we’re doing in ap_core_do_theme_options

First of all, I’ve pulled out all the code and put it into a new file called option-setup.php. This handles all the stuff that was previously where the _do_theme_options function is now but everything has been pretty drastically rewritten. First we have ap_core_do_theme_options which looks like this:

If you’ve tried or are currently using Museum Core, you’ll already know that the theme options page sports some tabs. So the first function we’re calling in _do_theme_options is the tab setup. This is a pretty straightforward function that just spits out the html needed to set up the tabs. The real meat is in the next three functions. We won’t look at every single function, we’ll just dig into the main highlights so you get an idea of what’s going on. Let’s peek at ap_core_general_settings which handles the, wait for it, general settings tab.

ap_core_general_settings looks an awful lot like ap_core_do_theme_options, with a bit of HTML thrown in to set up the table that’s going to hold the actual options. That uniformity is intentional, the idea is that you can swap functions in and out however you want. You can use your own modified version of ap_core_general_settings in your child theme, or you can do away with the tabs and just put all your options straight into ap_core_do_theme_options. Or you can mix and match options from the various settings tabs and create your own tabs, it’s up to you. Let’s take a look at what an individual option looks like now.

That’s got a bit more heft to it. But it’s still pretty basic. All I did here is pull the table row from the original theme-options.php and added it to this function. I’m using output buffering to store all the php/html as a variable and echoing the variable at the end which is what gets sent to the function calling this function (in this case ap_core_sidebar_option). I’m also calling the defaults and options from the database so our values are loaded and stored. This is done ad nauseum for each setting, so each setting gets called separately and can be isolated, grouped, cut out, whatever as needed by a child theme.

So what happens when I want to build a child theme and use some of these options? Here’s an example:

First what I’m going to do is start with a new theme options function. I’m keeping the 3 tabs from Core, but I’m adding a 4th tab. Since Core only supports 3 tabs, and I’ll need to set up the title for the fourth tab, I’m doing my own tabs. We’ll start by setting up the tabs. Remember, you don’t have to use the tabs at all; if you just want all of your options on the Theme Options page, you can just cut out the tabs function and then they’ll display normally, one on top of the other.

The two things that are changed are highlighted by the fact that the textdomain (‘museum-core’, ‘my-theme’) has changed. We don’t need to change the textdomain of the other tabs, because, assuming the text was translated in a language file, those would already be covered by the existing translation in Core — only the new translation strings need to be added (of course, none of this is necessary, really, if you don’t care about localization of your child theme). We changed “Typography & Fonts” to “Font Stuff” and added the fourth tab, “Custom Tab”. So far, so good. This is what it looks like:

20120511 8bgrj593pymrskawg7me5dky7y.medium Making theme options modular

Now that we’ve got the tabs, and we’ve added the options pages that we’re pulling from Core, it’s time to create our new settings page. We’ll do this really minimally and just add one option. We won’t add a bunch of function calls (although we could), we’ll just put our option straight into the new my_custom_theme_settings function. It looks something like this:

Now, in order for this to be actually functional, we’d need to define some new options for our theme so we could store them in the database, this is just meant to be an example and illustrate how we’re able to still pull functions from the parent theme and mix them into our custom theme functions. Here’s what that new tab looks like:

20120511 gjd8g2p9m9dw3a397wykaxw78g Making theme options modular

To summarize, what I’ve got is a modular way of calling individual settings that can be swapped in and out at will and replaced with custom settings (or not) however you want. If you have any thoughts or questions, feel free to post in the comments. If you’d like to dig into the source files, you can grab the latest version of Museum Core from GitHub. You can also take a look at the complete code from this tutorial on GitHub. And if you want to take a look at the files on your computer and hack them up, you can download the source files used to create the child theme in the screenshots here.

New look for jazzsequence.com (again…)

So, the jazzsequence.com redesign is still on (or at least planned), but I figured, since I just got a theme hosted in the WordPress.org themes repository, I might as well make it, you know, my theme so that at least one person is using it live, right? So here it is: Museum Core. I’ve also disabled WPTouch so if you’re looking at it in a mobile browser, you can see it in all its responsive glory.

I’m really excited about this theme. Not just because it’s badass and not just because I spent over a year developing it. Those things, too. But because…wait, no, it’s pretty much because it’s badass. I learned a lot through the whole process, particularly the theme review process, and it took over a month of revising and revising to get this (my first (accepted) submission to the repository) actually hosted on WordPress.org. It’s no small feat. It requires dedication, the ability to take criticism, and willingness to adhere to WordPress’ (high) standards. I don’t say that to pat myself on the back. I say that because it’s effing hard. Okay, yeah, and to pat myself on the back. A little bit. But possibly WordPress says it best on their page about why you would want to host your themes on WordPress.org:

The goal of our themes directory isn’t to have every theme in the world, it’s to have the best.

That’s their words, not mine. I certainly wouldn’t call my theme the best. But it’s damn fine (if I do say so myself) and I’m going to stand behind it and show it off for a little bit by making it the theme for my website. I’m allowed to do that. If you want to download it, go get it here: Museum Core.

SublimeText — I think I’m in love

I’m not one to gush about text editors. Pretty much they do their job and that’s about it. I respect the amount of work that goes into something like, say, OpenOffice.org Writer, but I wouldn’t say I’m in love with any particular aspect of it (except, perhaps, that it’s free — as in beer — and open source). My main reason for switching from Dreamweaver to Notepad++ was economical, but also to get away from the code that Dreamweaver liked to automatically insert into documents. For the most part, I was only using the source editor anyway, so it seemed a waste to use an application with a graphical editor that I never used and Notepad++ filled the gap nicely.

About a week ago, I found SublimeText 2. After using it exclusively for my web development projects for this past week, I can tell you I am never going back to anything else. Here are a few reasons why:


SublimeText 2 with Soda package, Monokai Soda color scheme, and Meslo font

Okay, so it’s pretty superficial of me to put aesthetics above everything else, but try and tell me that you aren’t like me and the first thing you do when you open a new program that has any kind of customization abilities isn’t find the perfect theme that works for you. SublimeText comes with 22 different color schemes and each one can be hacked if you so desire. You can download new color schemes. You can use any font installed on your system by adding a line to a configuration file (easily accessible through the Preferences menu). And thanks to a package (we’ll get to packages in a minute) called Soda, the entire UI can be customized in a smooth light or dark scheme (without Soda, the sidebar is not customizable).


You can extend the functionality of SublimeText through packages. Each package is based on a GitHub or Bitbase repository and repositories are checked for updates everytime the application is loaded. Functionality enhancements include things like bracket highlighting, PHPdoc capabilities, autofilling, support for various languages like javascript and HTML5, you get the picture. With PackageControl (which can be installed via an internal console just by copying and pasting the command in the readme file on the GitHub repo — pictured right), you can easily install new packages into Sublime without having to worry about where they need to be saved — everything is handled automagically.


When I was using Notepad++ and Dreamweaver, my window usually opened with approximately 8,000 tabs for various projects in different states of being worked-on. Navigating between them usually involved using the arrow buttons to scroll through to the beginning or to get a list of the open tabs via the Window menu. More often than not, I would try to open a file only to find that it was already open, hidden somewhere behind tab number 6.753. In Sublime, you can create discrete “projects” by adding a directory (or multiple directories) to a project. This could be a WordPress theme, an entire website, a bunch of related plugins you’re working on, or any other variation (pretty much just listing the sorts of things I use this for). Rather than having every file for every project you are actively working on open in a unique tab, you can easily switch between projects and have the last-opened tabs in that project there for you when you go back to it. Meanwhile, the directories (and files therein) that make up your project are listed in the sidebar, making it easy to open any file in that project. Not only that, but single-clicking on any file will open a “preview” of that file without actually opening the file. Meaning if you just wanted to look at something but not change anything, you don’t need to open the file and then close it, you can just click on it to check it out and then go back to what you were doing. Now that I use projects, anything I was doing before just seems clunky and unsophisticated.

Fully featured trial version

Don’t you hate it when you are using a “Freemium” or “Shareware” app and it does everything you need it to do except one tiny little thing that makes it completely useless without actually purchasing it? Like saving, for example? One of the things that instantly earned my respect was that installing SublimeText 2 let me do everything I needed to do without purchasing. After a certain number of saves, a pop up would appear asking me if I wanted to purchase, which could be easily clicked away and I was back doing whatever I had been doing. Some genius thought that programmers might be more interested in getting work done and that, after seeing just how good Sublime is at assisting them in that very task, they would be more inclined to pay for something they had been using for free.

Well, that genius was right. Despite the fact that I could have gone on indefinitely without paying the $59 for a single user license and just gotten an occasional notice to buy, I chose to actually purchase the application because it’s so damn good at what it does. I haven’t regretted that decision. The guys who make Sublime, well, sublime deserve to benefit from what they have created, which is an elegant IDE that is forward-thinking and extensible without a lot of bloat. Just hours after I installed a bunch of packages, I was already using most of them and felt the coding process suddenly become fun again.