During the Great Twitter Migration of 2022, I spun up my own Mastodon server, hoping to cultivate a community of fellow voiceover artists. I had an account with Vultr, so I provisioned a fairly beefy VPS with 2 vCPUs and 4GB RAM, plus 40GB of block storage for media, for $25/month.
Meanwhile, I had a small media and file server at home with a third-generation Core i3 and 4GB RAM. It worked well, but was due for an upgrade.
Three months later, I am still the only user on my Mastodon server. So a couple of weeks ago, I ordered a refurbished ThinkCentre M900 Tiny (6th-gen i5, 16GB RAM, 256GB SSD) for $127. This past weekend, I migrated Mastodon from Vultr to my home server.
When I initially installed Mastodon in the cloud, I installed it directly on the host; on my home server, I wanted to run Mastodon in Docker containers. Mastodon provides instructions for migrating an installation to new machine, but they assume a bare-metal install; it took me a few attempts to find the right commmands to:
Create a mastodon user in the Postresql database inside the container;
Get the database backup from the old server into the container;
Create a new empty Mastodon database owned by the mastodon user; and,
Run pg_restore inside the container to restore the backup.
Once I had migrated the database, installing Mastodon itself was fairly straightforward. There are a number of goodguidesonline for installing Mastodon using Docker Compose.
But when I tried to start it, the Web container complained that it couldn’t connect to the Redis container. After extensive trial and error, I discovered that everything worked if I disabled UFW, the firewall on the host. It turns out that Docker does not play nicely with UFW, and requires low-level configuration changes to iptables. Since I had to configure iptables anyway, I simply uninstalled UFW and used iptables directly.
Next problem: I use port forwarding on my (ISP-provided) router to get traffic from the Internet to my home server. The router doesn’t support NAT loopback (hairpinning), so devices on my home network could not connect to my Mastodon instance using its public URL.
The solution was to deploy a private DNS server on my network that routes internal requests for https://voiceover.actor/ to my server’s private IP address, and forwards other queries to my upstream DNS servers.
Finally…success! Mastodon is running happily on my home server, using an average of about 2% CPU and 25% RAM, and saving me $25/month compared to hosting in the cloud. My new server will pay for itself in 6 months!
When I was very young, my family went to a theater to see the MGM epic, How the West Was Won. It’s a long film (2 hours, 44 minutes), so it included an intermission.
As we were leaving the theater, my parents asked my grandmother how she had enjoyed the film.
“Isn’t it a coincidence,” Grandma replied, “Debbie Reynolds was in both movies.”
Good morning, and welcome to Acme Widgets Sales Training. I’m Becca, your trainer; over the next 8 hours, you will learn all about Acme Widgets and how to sell them.
[Slide 1 (of 147): About me] First of all, let me tell you a bit about myself. I joined Acme 5 years ago as a customer service representative…
[Slide 2: Agenda] Here’s today’s agenda: First, “What are widgets?” We’ll spend some time on the history of widgets. Next, we’ll talk about the story of Acme and how we got into the widgets business…
Raise your hand if you’ve been there: several hours of “training”, consisting largely of the instructor reading his or her slides to you (or an e-learning course in which the narrator reads the text on the screen), followed by a quiz to make sure you got it. The course objectives promise that after attending the training, you will “know” or “understand” or “be able to explain” something.
Why is so much corporate training so bad? And if you are responsible for developing or delivering such training, how can you improve the lives of your victims (and, let’s be honest, your own life: nobody enjoys delivering ineffective, mind-numbing training)?
The History of Training
Haha, jk. Seriously, how did corporate training get so bad? I can think of three reasons:
We (trainers and instructional designers) are afraid to push back against bad ideas from stakeholders. All too often, someone decides training is the solution to a performance problem; they request a course, and we dutifully create one. That’s our job, isn’t it?
"Doc, give me antibiotics!" Doc: "Okay!" Is this a good doctor? Of course not. "L&D, give me a course!" "Okay!" Good L&D? Nope.
Even when training is a valid approach, stakeholders and subject-matter experts frequently demand that we include far too much content. They want us to teach students everything they know (never mind that it took them years to attain their expertise). If we object that there’s not enough time to effectively cover so much content, stakeholders reply that “at least the students will be exposed to the material”, as if they can somehow learn by osmosis.
You can’t teach people everything they need to know. The best you can do is position them where they can find what they need to know when they need to know it. — Seymour Papert
To be truly valuable to our organizations, we must be more than simply course designers or instructors; we must become performance consultants. Don’t create a course just because someone requests one; don’t allow stakeholders to dictate content or instructional approach. Instead, ask why stakeholders think they need a course; what do they want the training to accomplish? If you agree that training is warranted, you recommend the best ways to achieve the stakeholders’ objectives.
Of course, you may not feel confident standing up to stakeholders due to…
Lack of formal training. How many of you have received formal education as a trainer or an instructional designer? Yeah, me either. Many of us fell into this role because we were subject-matter experts in some other field. (I was a software developer with social skills.) Some training manager saw our potential and asked, “Hey, do you want to be a trainer?”
If you do get formal training, many degree programs cover instructional-design models from 40 or 50 years ago (I’m looking at you, ADDIE and Bloom) without teaching you how to adapt them to today’s learners and rapidly-changing subject matter.
This is all we know. We know our training could be better, but “tell-then-test” is how it’s always been done. (It kills me that university instructors are called “lecturers”.) What else is there?
Here are three ways to create training that learners and stakeholders love, and that effects real change within your organization:
Start with a goal
If you’re going to spend time developing a course (and ask people to spend time taking it), the training should have a specific, measurable goal. I like Cathy Moore’sAction Mapping process:
Start with a measurable business goal, then figure out what learners need to do in order to reach it. Identify the minimum information learners need in order to perform the desired behavior and include only that information in the course. If you must provide additional reference material, link to it as an external resource; don’t force-feed it to learners as part of the course.
Perfection is attained, not when there is nothing more to add, but when there is nothing left to take away. — Antoine de Saint Exupéry
Lean, focused training saves your time during development, and ensures that you don’t waste learners’ time: Every moment they spend with your training moves them closer to your goal.
Quick: Think of your favorite scene from a movie or TV show. Why do you remember that scene? I’ll bet it provoked an emotional reaction – excitement, surprise, laughter, romance – the first time you saw it. People remember (and are moved to action by) experiences that engage their emotions. How can you apply this principle in your training?
A great way to get people emotionally involved is to tell a story, a realistic scenario that helps learners see how the training relates to them.
For example, I began a course on service-oriented architecture (SOA) with a story about Linda, a software developer, and Bill, her manager. Linda wants to use SOA on her current project; she believes the long-term benefits are worth a bit of up-front investment. Bill thinks it’s a nice idea, but there’s not enough time in the schedule to try something new.
The conflict between Linda and Bill invites learners to choose a side and helps get them emotionally involved. Try to think of a story with a plot and characters to which your learners can relate.
For more excellent ideas on creating a memorable message, read Made to Stick by Chip and Dan Heath.
Make it practical
If your goal is to teach people how to do something, your course should include interactions that allow them to practice the desired behavior. By “interactions”, I don’t mean a multiple-choice quiz or matching terms with their definitions. Learners must be able to practice what you expect them to do on the job, including the ability to make mistakes and see the consequences of those mistakes. Dr. Michael W. Allen recommends a model that he calls CCAF: Context, Challenge, Activity, Feedback.
Context is the setting in which the learning takes place. It includes the story you choose to set the scene as well as the visual design of the course, which should be immersive and reflect the learner’s day-to-day work environment as closely as possible.
Challenge refers to creating a desire in the learner to complete the course successfully, a sense that something personal is at stake. Ethan Edwards explains:
When the learner makes forward progress equally, whether an answer is correct or incorrect, he or she learns that it does not really matter what one gives as an answer… If there is no real chance for the learner to fail, then failure or success is a matter of indifference. And if the performance required of the learner seems pointless or irrelevant, there will be little motivation to work toward that end.
The learner must know that success is possible, but that it’s not necessarily guaranteed without some mental effort.
Activity is the physical action the learner must perform to achieve success. Ideally, the activity should mirror as closely as possible what the learner will actually do on the job. The goal is to demonstrate mastery of a skill, not simply the recall of information.
Feedback is the information we communicate to the learner in response to his or her actions. Telling the learner whether he or she completed an activity correctly is just scratching the surface. Instead, you can show the learner the consequences of his or her actions (intrinsic feedback). Or you can give the learner a challenge at the beginning of a lesson, then use feedback after an activity to present the associated content. By tailoring the content to the learner’s needs (as demonstrated through the activity), the instruction takes less time and becomes more relevant, and the learner will be more receptive to it.
For more information on the CCAF model, download this free e-book from Allen Interactions.
Be the change you wish to find in your couch cushions
By starting with a specific, measurable goal, engaging the learner’s emotions, and making the training practical and relevant to the learner, you will greatly increase the appeal and effectiveness of your training.
Have you experienced a memorable training experience (good or bad)? Do you have questions about how to apply this article? Please leave a comment below.
In which I switch to Jekyll and figure out how to post from my iPad
It all started with a tweet.
Last summer, a colleague asked for recommendations of WordPress alternatives; I replied with a link to this article. At the time, I had been running this site on Movable Type for over 10 years; the article piqued my interest: Did I really need a full-fledged content-management system? Did I need to keep shelling out $10 a month for a web host with a database server?
I decided to give Jekyll a try. The Jekyll documentation includes a handy script for importing posts from Movable Type. I found a Bootstrap-based, Medium-esque theme that I liked, and Manuel Gruber (no relation to Hans) has an awesome post explaining how to have Wercker (a free continuous integration service) rebuild my site and deploy it to Amazon S3 whenever I check in a change.
Within a few hours, I had a fast, good-looking site running on modern software, and my hosting bill from Amazon is less than a dollar a month. I recently upgraded to Jekyll version 3; at the same time, I added an archive page to surface older content on the site.
Authoring on the iPad
Now that I can create a post simply by editing a Markdown file and committing it to a Github repository, I wondered if it’s practical to post from my iPad. (You may recall that I struggled with this several years ago.) This post is evidence that it is indeed: I authored it almost entirely on my 9.7-inch iPad Air 2 (I cheated a bit and created the image thumbnails on a Mac).
There are several capable Github clients in the App Store; I chose Git2Go because of its attractive UI and reasonably-priced ability to access private repos. My first step in writing a new post is to create a draft branch and clone it to the iPad.
Textastic gets rave reviews and integrates nicely with Git2Go: I can create a new file in Textastic and export it to my local repo, or create an empty file in the repo and open it in Textastic for editing.
My one complaint is that my (older) version of Textastic doesn’t support Split View in iOS. It’s a bit tedious to have to switch to a separate app to look up a link (or use the anemic Slide Over mode), but I’m not sure it’s worth an additional $10 to upgrade to the latest version.
What about QA?
At this point, I could commit my changes and merge the draft branch with master; my Wercker process would kick off and automatically publish the post to my site. But I’d prefer to preview the post in a browser and correct any issues before I push it to production. I have several options:
Manuel Gruber uses two S3 buckets, one for QA and one for Production. When he commits to his draft branch, Wercker publishes his site to the QA bucket, which is accessible at a secret URL. I considered this approach, but Wercker takes several seconds to publish the site; that would quickly become annoying if I wanted to make several changes;
Aerobatic offers automated continuous deployment of Jekyll sites. It works with Bitbucket, where I host my code (free private repos!), and it will host up to two sites free of charge. But the free tier only allows five deployments a day; I can see myself easily blowing through that trying to fine-tune some CSS;
What I really want is the same experience I get while working on my laptop: open a Terminal and execute jekyll serve, then point my browser at localhost:4000 and preview the site. I thought I had found the perfect solution: Codeanywhere spins up a container and runs your code in the cloud; the container is accessible via SSH. But alas, it chooses a random SSH port each time it starts a container; there’s no way to see what that port is in their mobile app, and their web application doesn’t work correctly in mobile browsers. ☹
I was ready to resign myself to merely writing on the iPad and waiting to publish until I got back to my desk, or using RDP to launch Codeanywhere on my home computer and finding the secret SSH port. But then it hit me: AWS!
If I set up an EC2 instance with Git and Jekyll, can I start it from my iPad, pull the latest code from my repo, and use an SSH client to run jekyll serve? Yes!
Then I can point my iPad browser at [ec2-instance-name]:4000 to preview the post:
Now I can write, preview, and publish posts wherever I am when inspiration strikes…as long as I have my iPad with me. And an external keyboard. After writing this post on the iPad, I’ve learned that trying to do real work makes that 9.7-inch screen feel really small; maybe I need to upgrade to the large model. 😉
This week I attended a workshop in San Francisco called The Art of Storytelling with McSweeney’s. The course description promised that I would learn “How to craft persuasive stories for a variety of business contexts” and “Applied exercises to make your storytelling skills stand out in business settings.” While the workshop was enjoyable and inspiring, there was nothing business-y about it; it was more about defying conventions and subverting expectations to create more interesting, entertaining stories.
For example, the instructors explained that most stories answer the basic questions who, what, when, where, and how: Who are the main characters? What happens to them? Where does the action occur, and when is the story told? How will you choose to tell the story? By playing with one or more of these parameters, you can tell an otherwise conventional story in a more interesting way. They cited several clever examples from McSweeney’s:
“She’s been in there a long time. I hope she’s OK!”
I sat motionless in the women’s restroom stall, hiding my shoes, desperately hoping that concerned woman wouldn’t ask me if I needed help.
Why was I in a women’s restroom?, you ask. Fair question.
I was 21 years old; my family was on a road trip from our home in Portland, Oregon to Northern California. We had stopped for breakfast at a Denny’s restaurant somewhere along Interstate 5. After breakfast, I had said, “Let me just use the restroom, and we can get back on the road.”
I went into the stall and closed the door. A few minutes later, I heard a woman come into the bathroom. I thought, This woman is in the men’s room; maybe I should say something. I decided not to; we couldn’t see each other, so no harm done.
A moment later, another woman entered the restroom. Wait, two women? Must be me. I figured I would just wait until the place was empty and make my escape.
Unfortunately, it was the morning rush hour: one woman after another came in to powder her nose. (At one point, my mother was in the stall next to me. I briefly considered alerting her to my presence. I ultimately decided against it; she’s a screamer.)
Aside: When I was four years old, my father took me to a baseball game at Dodger Stadium. He took me to the bathroom, and from the stall I said, “Daddy?”
“Yes, Philip?”
“I love you.”
All the burly dads in that restroom chuckled and said, “Aww, he loves his daddy. Isn’t that sweet.”
Back at Denny’s, my father went into the men’s restroom. There was someone in the stall, whom he naturally assumed was me. (As far as he knew, I only used men’s rooms.)
Later, when I told my father what had happened, he said, “You don’t know how close I came to saying, ‘Hey, you in there: I love you.’ It’s a good thing I didn’t; I would have had to say, ‘Sorry, the guy I love is in the ladies’ room.’”
Eventually, the ladies’ room cleared out and I was able to sneak out undetected. (No, I did not wash my hands.) To this day, over 30 years later, whenever I enter a public bathroom, I always check for a urinal.
During the workshop, I thought about other ways I could tell this story: How about a Denny’s PR piece about how they were at the forefront of the gender-less restroom movement? ☺
I had a good time and definitely learned some new ways to enliven my stories; I’ll have to think a bit about how to apply these techniques at work.
Imagine two teams: The first (“Team Monica”) begins a project with a kickoff meeting, followed by meetings with stakeholders and subject-matter experts, and a recurring weekly meeting to discuss progress. The team creates various artifacts along the way: a project plan, process and procedure documents, wireframes and prototypes. Finally, after months of discussion and dozens (or hundreds) of pages of documentation, the team delivers its final product. Hopefully, it accomplishes its goals and satisfies stakeholders.
The other team (“Team Phoebe”) has an initial meeting to assign deliverables to each individual, then gets to work. With fewer meetings and less process, they are able to deliver much more quickly (weeks instead of months); with less up-front planning, however, there is some duplication of effort and inconsistency among deliverables.
Which team would you say is more effective?
If the teams are building something ephemeral (software, documentation, training content, etc.), as opposed to, say, a skyscraper, then count me squarely on Team Phoebe. Though its output may be less consistent, the team produces results much more quickly. Team Phoebe can produce a second iteration that incorporates feedback from actual users in less than time than it takes Team Monica to release version 1.0 (which will itself likely require revision; to paraphrase Helmuth von Moltke, “No plan survives contact with the enemy.”)
None of this is new, of course: In software development circles, there is decades-old tension between proponents of Waterfall and Agile methodologies; instructional designers have begun moving away from process-heavy ADDIE toward more iterative, learner-centered techniques. But the debate is far from settled; somehow I keep finding myself the lone Phoebe on a team of Monicas.
I recently came across this presentation by Justin Searls that resonates with me. The whole thing is good, but I especially enjoy the section in praise of small teams beginning around slide 65. Some highlights:
Consensus corrects for the team’s needs; feedback corrects for the users’ needs. Sadly, time spent gaining consensus costs you in feedback, because consensus and feedback compete for the same resources.
“How can we build something this big with a small team?” is exactly the wrong question. [We should be asking,] “How can we build something this small and start failing or succeeding?” If Small Thing™ is wildly successful, then the team can grow organically; if Small Thing™ is a spectacular failure, then at least it was a small thing.
How do you find a Small Thing? Simplify the idea so much that one person can build it.
That’s my dream: to be part of a team that empowers individuals to create Small Things without a lot of up-front process, gets them into the wild as quickly as possible, and incorporates user feedback to improve them over time. Who’s with me?
Recently, a colleague of mine started a new job. For the past several years, she had been a corporate learning and development manager; now, for the first time, she would be responsible for training IT people. She asked me if I could recommend any publications or other resources devoted to IT training. Here’s how I replied:
Hi, Mary: Congratulations on the new job! It sounds interesting and challenging.
I am not aware of any resources (publications, blogs, etc.) specifically about IT training. The principles of effective training are the same for IT as they are for any other field:
Focus on the learner. Make the training relevant and practical: What should the learner be able to do (not know) after attending the training?
Avoid information dumps. If the information is available in written form (documentation, etc.), there’s no need to present it verbally. Instead, the training should focus on practice: tasks the learner will need to perform back on the job, practice finding information in the documentation, etc.
Look for alternatives to instructor-led training. This is especially important if you’re a one-person show and you need to scale: The fastest way to develop a class is to not develop it; a document, screencast, or job aid may be sufficient. You can typically create these much more quickly than an instructor-led class, and once created, they can be used and re-used without requiring any more of your time.
I have found the following resources valuable in learning these principles and selling them to stakeholders:
http://info.alleninteractions.com/. This blog is mostly about e-learning, but I like their ideas about moving on from ADDIE, and their Context, Challenge, Activity, Feedback (CCAF) method to keep training focused on the learner.
Imagine that you’re an auto mechanic. After working as a mechanic for many years, you take a job training other mechanics. You get to work in the field you love and the trainees seem to like you. Life is good.
Then your employer is acquired by a larger company. They see the word “trainer” in your title, so they assign you to their training department. The problem is that their trainers are driving instructors; nobody on the team really understands what you do. They ask you to pitch in and teach a driving class now and then, but you still spend the majority of your time training mechanics and your bosses mostly leave you alone, so you stay.
The plot thickens: Your team is reorganized, and you get assigned to a manager responsible for dispatchers. At the same time, the company begins hiring fewer mechanics. Now there’s less demand for you to train mechanics, and the focus of the team shifts to dispatching: “We have two dispatchers out sick today. We need all hands on deck to answer the phones!” Your mechanic skills are underused and becoming obsolete, so you decide to move on.
When you give your two weeks’ notice, your bosses suddenly realize that you perform a critical function that no one else on the team knows how to do. They ask you to document everything you do, and they send driving instructors to attend your mechanic training so they can deliver it (or teach it to someone else) after you’re gone. Yeah, right.
What can we learn from this cautionary tale? If you have an employee who performs a critical function:
Make sure you understand that function and appreciate its importance;
During one-on-one meetings, ask the employee if they’re satisfied with their job. If not, ask what changes he or she would like to see to make it more satisfactory;
Don’t wait until the employee gives notice to try to find and train a successor.
Teaching a class and need a countdown timer to display remaining break time? In the past, I’ve used Microsoft’s (formerly SysInternals’) free ZoomIt utility, whose primary function is to enlarge portions of the screen, but which can also display a break timer. But maybe you don’t need the zoom functionality, or you’re using a PC on which you can’t install additional software. In that case, just visit Google and search for “timer 10 minutes” (replacing 10 with the length of your break). Voilà!
Interesting: “On June 20th 2013, we decided that our 4-day work week at Treehouse wasn’t insane enough so we went further: We removed all Managers… We give all employees 100% control of their time and let them decide what they work on each day.”
