Paul's Down-Home Page

I’ve gotten a lot of questions about my job, so I thought it would be a good idea to explain more about what I do, mainly because we’re looking for more people who can do this kind of work.

My official title is "content author." That means that—you guessed it—I write content for our Digital Tutor. The tutor is a complex piece of software that provides students with the same experience as sitting side-by-side with an expert human tutor. We’ve proven in both lab tests and real-world use that we can take average students—not just superstars—and help them gain real expertise, not just paper-MCSE-style book learning. Our students gain expertise far out of proportion to students who study with normal methods, especially because we can do it faster than traditional solutions. (If you want to know more about how we do that, e-mail me; much of our methodology is secret sauce.)

There are two important parts to my job title. The content part means that the tutor uses several different kinds of material to help students learn. Some are the traditional items you think of when you think of computer-based tutoring: lectures, graphics, animations, and so on. Others are unique to our product. For example, we have guided activities (e.g. "First open a command prompt and type ‘telnet’. Then…") where, at each step, we can see what the student’s doing on a live Windows network and give them guidance where needed.

We also have free-form exercises, where we give the student a real-world exercise ("Your new boss is complaining that his computer is slow. Go fix it.") and offer help, but only when the student asks for it (and only as a Socratic dialog, never as prescriptive help.) These, in a word, are awesome. They’re fun to write, challenging for students, and a key part of what makes our solution so effective… but I digress.

The author part means that I create the content using our own language and toolset. However, I have engineers who work very closely with me to make sure that whatever features I need get implemented. It’s a great partnership because I’m free to focus on what I do best, not worry about how the system will figure out what a student is pointing at, or what they just changed in AD, or whatever. The engineers do that (and we need some of them as well, come to think of it!)

What makes a successful content author?

• Deep knowledge of at least one significant aspect of IT: networking, Windows, Active Directory, etc. When I say "deep", I mean that you need to be able to talk about this stuff at any level from "ooh, shiny" down to 500-level details of internals.
• Solid teaching experience, the more the better. Whether 1:1 or in groups, you have to be able to effectively impart what you know.
• Excellent written communications skills. Many of our existing content folks are published, though that’s not a requirement.
• A desire to work on something that can, quite literally, change the world.

Are you a good fit? If you’re interested, see our jobs page and fill out the online application. That will get you into our system, and we’ll take it from there. If you have questions, I’ve set up a formspring page so that you can anonymously ask ’em.

After my previous post on OS X Server, I got a lot of good feedback from the Mac Enterprise folks. It was very helpful as I dug deeper into getting our room full of Mac minis into coherent shape.

For example, I learned that you can turn a shell script into a double-clickable executable by changing its extension to “.command”. That means that having a shell script run at logon becomes trivial, which in turn made it super-easy to start our complex Java app when the captive student account logs in. Score one for the good guys.

In regards to my complaint about binding machines to the domain, I learned (courtesy of James Relph) that you can in fact do it just like Windows does:

Regarding binding machines to the domain, just go into Server Admin > Open Directory > Settings > Policies > Binding and tick “Require authenticated binding between directory and clients”. That will ensure that when a client is joined to the domain it will ask for a domain admin account and create an associated computer record in the directory.

I learned how useful the Apple Remote Desktop “kickstart” app is, too, for setting up various aspects of ARD without manual intervention. Sadly, I also learned that there’s no way to easily apply an existing ARD task to a different set of machines, though the MacEnterprise folks helped with a couple of workarounds.

Some of the rough edges I noted earlier have disappeared as I’ve learned more about what I’m doing. One piece of excellent advice that I received is never to trust the GUI. Odd, given that Apple is supposed to be masters of all things GUI, but absolutely true. Often what you see in the GUI of the various admin tools is only loosely related to the actual status of the machine or component you’re looking at.

There are a few more serious problems lurking, too. One is that automatic logon just flat out doesn’t work if you specify an Open Directory account as the target. This is annoying, but it’s not the end of the world. Worse is that Apple pretty much leaves disaster recovery and repair up to oral tradition. There’s very little documentation on how to properly back up and restore a Mac OS X Server system. I can tell you from bitter experience that using Time Machine to back it up will only preserve files that aren’t open at the time of the backup, meaning you’ll lose your Open Directory database. Oooops. Apple doesn’t document anything about the best (or even worst) method of replacing a failed OD server, which is a real shame.

I still have a lot more to learn, including how to use the systemsetup and scutil commands, and how to tame launchd to make it do what I want to. One of these days I’ll probably feel like I know what I’m doing…