Welcome, winter! We're cozy in this little nook of time between holidays, and are happy to be back in front of our mics. You can listen below or read the transcript.

We're back in action! Listen to this month's episode below or read the transcript online.

We cover a few topics:

• Our community survey is out! It's the first time we've done a wide push to get advice and feedback of this sort, and we appreciate everyone who fills it ...

Part of our work to make Exploit: Zero Day easier for us to maintain and update was making a job editor for ourselves. Previously, we'd been creating jobs (the storyline missions for the player) using the Django admin interface, which is very nice but makes it difficult to have a ...

Listen to this month's episode below or read the transcript online or as a PDF.

We talk about:

1. "Still Waters Run Deep", the Rosette Diceless one-shot (now two-shot) that Melissa ran on September 30 (embedded below);
2. Some work Gregory is doing with Lita and artificial intelligence of ...

This month, we talk about the ongoing Exploit: Zero Day job editor development, the dropped "The Majesty of Colors" trademark application, our infrastructural/devops change away from Compass, and the upcoming Rosette Diceless one-shot session on September 30.

Give a listen below or read the transcript online or as ...

This is the fifth part in a series on applying devops principles and practices to game development. You can read the first post in the series, and see the entire series under the devops in game dev tag.

In our post on what the devops philosophy is, we wrote about revisiting workflow annoyances periodically. Sometimes you get more time and/or money. Sometimes you learn of an easy way to solve a problem.

There's something that got a lot easier for us recently: chatops.

"Chatops" is a trendy word for a subset of devops that focuses on streamlining work using extensible chatbots (e.g., Lita, Hubot, and Errbot) in team communication tools (e.g., Slack, HipChat, etc.). We use Lita on Slack, so I'll stick with those as concrete examples.

As a simple-but-nice examples, you might ask Lita to run an automated build for you, and it will connect to Jenkins and run the build you ask for. You don't need to leave Slack open a tab, log into Jenkins, find the job you need, and run it.

Something really important that well-implemented chatops provides is the ability to add context-appropriate information to conversations that are already happening.

We have about 12 different sites or parts of sites that could have outages and two of us to manage them. Some of these have been up for years, and some are newer. Some applications require special installation or debugging, and some must be on differently-configured servers.

When one of those goes down, we both need to know how to diagnose and fix it as soon as possible. So how do we manage that?

This is the fourth part in a series on applying devops principles and practices to game development. The first post in the series is here, and the entire series can be found under the devops in game dev tag.

In our post on retrospectives, we wrote about taking note of lessons learned (good and bad) after emergencies or breakpoints in your project—after you deliver a feature, or at the end of a sprint or some unit of time. But how do you know what a good breakpoint is? How do you actually incorporate what you've learned in a retrospective into your future work?

Through effective project planning.

(This is part 3 of a series on applying devops principles and practices to game development. The main post is here and all posts can be found under this tag.)

In our post on devops philosophies, we emphasized the continuous process of learning and revising, and said that a good place for that to happen is in retrospective (or post-mortem) meetings.

So what is a retrospective?

(This is part 2 of a series on applying devops principles and practices to game development. The main post is here and all posts can be found under this tag.)

If nothing else about this series proves directly useful to you, take this one thing home:

Don't get stuck in a local maximum.
—Michael DeHaan, creator of Ansible

Keep moving and keep improving.

Very often, we find a system for ourselves that works and stick with it. We just get used to things that are initially annoying or rough, even if we know there might be a “fix” for it. As a result, we accept failure in some areas, telling ourselves “that's just how it is.”

We shouldn't just accept those irritants and move on. We should continuously reassess whether those need to continue to be rough spots.