Creating non-renderable "implicit" spheres, cones, cubes

Not sure how I didn't know about these until recently. The names sound so passive-aggressive. . .

createNode implicitSphere -n "name";
createNode implicitBox -n "name";
createNode implicitCone -n "name";

Each of these commands basically creates a non-renderable object (sphere, cube, cone) that has a very basic shape node (no components) and a transform node. You can still go into the shape node and change color using the drawing overrides and all. Doubt I'll be using them all the time or anything, but cool to know they are there if ever you should need them. 

Note on "distanceBetween" nodes . . .

A kind fellow named Maarten sent me an email asking about the distanceBetween node when using objects that have frozen transformations. More specifically, that it didn't work correctly after freezing the tranforms. Absolutely correct and I should have mentioned it in the video.
Basically once you freeze transforms on an object you sort of "reset" the matrix that the object lives in. As far as Maya is concerned internally, these objects now all live at 0, 0, 0, despite the fact that their pivots might be any old place.

Since I don't know much (read: anything) about matrix math, I'm not sure exactly what the technical description of what is happening is, but you're probably familiar with the results. If you're not, try this: create a cube, rotate, scale and translate it. Then freeze tranforms on it. Now look at the manipulator handles for the rotates (in local mode) and the tranforms (in object mode). Not only have the values in the channel bar been reset to 0's and 1's, but the object no longer has any idea of it's own orientation relative to the world. So any values relative to anything else in your scene are gone, thus things like distanceBetween (and loads of other stuff) don't really work any more. There are a bunch of little tricks you can use (sometimes) to pull out some information about the object, but things like world space position and orientation are kind of messed up. You won't run into this with things like joints very much, as you're probably not freezing them, but depending on how you're doing things elsewhere, this could be something to be aware of.

Some notes about this:
a) This is yet ANOTHER reason why it's smarter to "group freeze" or "group orient" your controls or anything else that you care about the position/orientation. By grouping an object at the origin on creation and then moving the group, not the object, you avoid the need to freeze transforms on anything.
b) When you're modeling for rigs, you DO want the freeze the tranforms (usually) but it's probably better to wait until you're pretty well finished with the model, THEN clean it up (freeze, delete history, etc). Most of these objects will end up being controlled by other things (joints, etc) anyways, but it's nice to have older versions of the file that have the orientations, etc (even better if you use groups here too, but let's not get too fussy)
c) in the ordinary course of events it's, of course, totally fine to use the standard measure distance tool, with it's UI component and locators and all. When you actually want to see the values, it's actually easier to use this method because of the visual feedback it gives. I'm guessing that this freezing business is why these tools don't measure the objects directly, but instead use the locators.
d) if you have frozen objects (whose world space matrix has been messed up at some point) and you still want to use the cleaner method of the "distanceBetween" nodes, you can just create some null groups (one for each object) and point constrain them to the objects. Then you can either delete the constraints and parent the nulls under the objects, or leave the constraints and stash the nulls away somewhere in the outliner. Then you just hook up the nulls to the distanceBetween, just like you would any other objects. A bit cleaner visually than using locators, but you could use those too if you want.
Anyways, thanks to Maarten for pointing out the omission!

Dealing with smoothing in your character rigs

Was literally thinking about whether to include this topic in another vid and someone emailed me and asked me about this specifically. Weird!
This video sort of quickly goes through some ways to deal with how to include various smoothing levels in your rig, from lo poly proxy geo to highly smoothed for rendering.
Here's the code I use in the video:
1) for grabbing ALL polySmoothFace nodes in the scene and connecting them to your master control in the rig scene (note you should change any appropriate names, obviously, to ones you're using):
{
string $smooths[] = `ls -type "polySmoothFace"`;
for ($each in $smooths){
    connectAttr master_CTRL.hiPolyLevel ($each + ".divisions");
    }
}
2) for changing the smooth state of any selected master control objects (probably best to use this as a mel button on your shelf, and of course change any names/values to what you want):
{
string $sel[] = `ls -sl`;
for ($each in $sel){
    setAttr ($each + ".loPoly") 1;
    setAttr ($each + ".hiPolyLevel") 0;
    }
}

Creating stretchy joint chains

Been meaning to do this tutorial for a while, but never got around to it. Some fella named Jeremy Parrish did a tutorial on this subject that I saw recently (http://vimeo.com/29466144) and did a few thing differently than I would do.
1) I now use the "distanceBetween" node in rigs. Easier, cleaner.
2) WHAT we're measuring makes a difference. So a bent leg, for example, needs to be measured differently than a straight leg. Subtle, but important distinction that needs to be looked at depending on your model.
3) by measuring the leg joints that are being stretched (or any static, constant measurement), you have issues with scaling. These can be solved (as Jeremy shows), but that may, in fact, create some weaknesses in your rig that can pretty easily cause problems.
So here's a vid where I walk through a stretchy leg the way Jeremy shows and then with a few modifications.

creating a nice clean distance node using "distanceBetween"

Here's another neat little node, called the "distanceBetween". As you might guess, it measures the distance between of two selected objects.  What's nice about this is that you don't get the extra gunk that comes the measure tool, like locators and UI stuff, which one typically doesn't need in a rig.
The only tricky part here is that in a DAG hierarchy you can't really use the translate attributes as the measure inputs because those don't reflect world space distances. So you'll need to hook up one of the pivots for each object and then use the "world space" attributes for each object into the respective input matrices of the distance node. Huh? Just watch the video and I'll walk through it.
The basic code for the node itself is:
shadingNode -asUtility distanceBetween -n "name;

BTW, here's the code I used in the video for creating this distance node . . . You can just copy it into your script editor and make a quick mel button for it. I've added just a quick dummy check to make sure there are 2 tranforms selected.
{
string $sel[] = `ls -sl -tr`;
if (`size($sel)` != 2){
    error "please select 2 transformable objects to measure";
    }
string $name = "distance";
string $dis = `shadingNode -asUtility distanceBetween -n $name`;
connectAttr ($sel[0] + ".worldMatrix") ($dis + ".inMatrix1");
connectAttr ($sel[1] + ".worldMatrix") ($dis + ".inMatrix2");
connectAttr ($sel[0] + ".rotatePivotTranslate") ($dis + ".point1");
connectAttr ($sel[1] + ".rotatePivotTranslate") ($dis + ".point2");
}

Dealing with Double Transforms

Double transforms are probably the single most frustrating thing to deal with when you're first learning rigging. What can be even more frustrating is when these issues pop up after it seems like you've got a perfectly working rig and you just want to clean it up in the outliner!
Fortunately, the issues are almost always in one of a couple of relatively simple categories and you get accustomed to dealing with them fairly quickly. This is a video talking about some of those basic scenarios and some ways to address them. Hopefully enough to help get you started in solving some of the more complex issues you may run into down the line.

Maya/Rigging: Dealing with Double Transforms from zeth willie on Vimeo.