This is just a quick tip, but ever since discovering it I use it constantly. A lot of developers use PHP’s print_r() function to display human-readable information about a variable, which makes it great for debugging arrays and objects (among other things) very quickly. However, you have to wrap the output in <pre></pre> tags otherwise it gets spit out in a jumbled mess and doesn’t display nicely.

echo '<pre>';
print_r($foo);
echo '</pre>';

That works just fine, but you can shorten it up by passing true to print_r()‘s second parameter, the $return flag, and mixing it in with your echo statements. What this does is tells print_r() to return the human-readable variable data instead of printing it to the screen right away.

echo '<pre>' . print_r($foo, true) . '</pre>';

Earth-shattering code breakthrough? Absolutely (not). However, it does turn three lines of code into one and makes it quicker (for me, anyway) to write quick debugging statements and move them around easier.

As an added bonus, you can “queue up” a bunch of print_r()‘s by capturing their output in a variable and then echo’ing it just once.

$debug = print_r($foo, true);
$debug .= print_r($bar, true);
echo '<pre>' . $debug . '</pre>';

Voila, shorter debugging statements that are easier to work with.

It’s been a few years in the making, but I’ve finally moved my blog from shatteredreality.com to mikebranski.com, and I’m working on updating the photography content that was here originally – for now it’s available at http://mikebranski.com/v1/.

When it came down to it, it was just too much work trying to keep three sites up and active and full of content, which led me to update none of them. Far from ideal. It’s also a lot easier to give people one link instead of three and makes it less confusing when they don’t have to try to decide which one they want to visit.

Next steps will be to take my web development stuff over at Left Right Designs and bring that here as well, which will coincide with me getting some of my projects set up on GitHub. Over the next few days I’ll also clean up my blog categories and tags that came over with my old blog and start filling out some of my pages.

Until then, have a look through some of my other posts while I get settled.

Update: For those of you who subscribed to my old feed, be sure to grab the updated link! The old Feedburner one will still work, but you should update yours anyway.

It’s not like I don’t have enough on my plate and I need to find new stuff to keep busy with. Despite that, my list of things I want to check out seems to grow each week. Two things I’ve been wanting to look closer into are 960 Grid System, and Object-Oriented CSS.

960 Grid System (960gs) is a CSS framework that’s – not surprisingly – based on a grid system with a width of 960 pixels. Why 960?

All modern monitors support at least 1024 × 768 pixel resolution. 960 is divisible by 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24, 30, 32, 40, 48, 60, 64, 80, 96, 120, 160, 192, 240, 320 and 480. This makes it a highly flexible base number to work with.

I’ve been using 960 or 970 pixels as a recommended width for sites for the past two and a half years or so, but I’ve never tried working with a grid system. Although I tend to do the development side of things and not so much the design, when I get site comps they’re very often based on a grid of some sorts. That makes me curious to try something like 960gs to see if it speeds up development any, or at the very least, facilitates cleaner, more uniform CSS.

Two of the biggest things that have stopped me from using a CSS framework in the past are extra bloat from unused rules, and having to resort to non-semantic class names. 960gs currently has their CSS file down to 5.4kb, so I guess that trade-off depends on how much CSS it actually saves you from writing.

Object-Oriented CSS (OOCSS) was first presented by Nicole Sullivan at Web Directions North 2009. The first thing that caught my attention was the name, “Object-Oriented CSS.” Definitely not something I had heard of before, I read her slides on the subject and have been interested in pursuing it further ever since.

As stated on her post about it (linked above), OOCSS has two main principles:

1. Separate structure and skin
2. Separate container and content

Hang on, isn’t separating structure and skin exactly what CSS is in the first place? Yes, but she’s not referring to HTML (structure) and CSS (skin). Instead, it’s about having one class that handles the complexities of presentation, then building on that class with additional ones that provide the skin: colors, borders, background images, etc. For further explanation of these two principles, read her follow-up comment, as well as her response to another good question.

Edit: There’s also a great OOCSS FAQ over at GitHub.

Customization is key, so when I had spent a considerable amount of time trying to disable editor resizing in CKEditor and kept coming up blank, it started to get frustrating. Here we have a pretty solid editor coupled with a pretty solid lack of documentation – reminds me a bit of Magento! To their credit, it’s still extremely new and they are working on documentation for it. That aside, I managed to stumble across a post on their forum that led me in the right direction.

Open up ckeditor/config.js and put the following code in there.

CKEDITOR.editorConfig = function( config )
{
	config.resize_enabled = false;
};

Ultimately, I was aiming to disable only horizontal resizing but that feature’s not available yet (can’t seem to find the forum post where a dev suggested they might implement it). The whole reason I wanted to disable resizing in the first place is because as soon as you would start to drag the resize handle, the editor width would shoot out and you couldn’t make it any smaller. Turns out it’s another somewhat hidden config setting forcing the resize width to a minimum amount.

If you want to keep resizing enabled but adjust the minimum width, use the following code instead.

CKEDITOR.editorConfig = function( config )
{
	// Sizes are in pixels
	config.resize_minWidth = 550;
	// config.resize_maxWidth = 700;
	// config.resize_minHeight = 200;
	// config.resize_maxHeight = 500;
};

As you’ll notice, there is also a setting for resize_maxWidth, along with similar ones for controlling the height. Any config settings you put in this file will be the new defaults for all editor instances, and once you know some of the things you can change here, you can really streamline the setup of new editor instances throughout your application.

I carved up Yoda on the right, Cassie did the bats on the left.