Michael Zanatta, Co-Author of Modern IT Automation with PowerShell: Modern Automation with PowerShell

Len: Hi I’m Len Epp from Leanpub, and in this episode of the Frontmatter podcast I’ll be interviewing Michael Zanatta.

Based in Brisbane, Michael is a PowerShell expert and a popular author, speaker and streamer, and co-founder of the Brisbane Infrastructure DevOps User Group.

You can follow him on Twitter @PowerShellMich1 and check out his profile on LinkedIn, and you can follow him on Twitch at PowerShellMichael.

Michael is the author of the Leanpub book Modern IT Automation with PowerShell: Modern Automation with PowerShell.

In the book, Michael and his co-authors a The DevOps Collective help readers learn about PowerShell automation tools and techniques with professional-grade practical examples.

In this interview, we’re going to talk about Michael’s background and career, professional interests, his book, and at the end we’ll talk about his experience using Leanpub to self-publish his book.

So, thank you Michael for being on the Leanpub Frontmatter Podcast.

Michael: It’s a pleasure, thank you.

Len: I always like to start these interviews by asking people for their origin story. So, I was wondering if you could talk a little bit about where you grew up, and how you found your way into the career you have in tech?

Michael: Yeah, so it’s an interesting story. I grew up in far North Queensland, a little town called Mareeba. I picked up computing off my father. Back in the day, my father was studying information technology. So, our house was one of the few houses probably in the town that had a coax network and we had our own little kids’ computer, and we basically played around with computers.

It wasn’t really until grade nine where I showed an interest in computing. Then from grade ten, I actually learned VBScript, and continued scripting with VBScript, until 2012.

That was in my second job. I started in my career in IT in 2010, and I finished writing with VBScript, and learned PowerShell in 2013. So yeah, it’s a bit of a journey.

Obviously if you kind of take a bit of a step back, I was always interested in computing quite young, and then growing up, after grade nine, and started seriously getting into computing.

One of the key things I used to do, and I kind of think back, it was just the eagerness to learn everything I could possibly get my hands on. What I used to do as a child, is, I would actually sit down and go through every command executable within the System32 directory, to understand what it did.

One of the things is that, my father actually taught me DOS. I actually was quite fluent in the command line, and being able to understand and navigate it. I was quite comfortable in it. It was soon after that, I did some batch scripting within that.

Then, it kind of just took off ever since from that. Throughout school, I always showed a keen interest in computing, and did very well in that, and studies within that. And obviously just progressed.

My first job was, any sort of first job in IT, I compare it to your first-year apprenticeship, where you’re essentially sweeping floors. I was just doing help desk work. Then kind of had the opportunity to progress into systems administration, which got me exposed into a little bit more of scripting side of things. I actually wrote a few scripts for the organization.

Then after that I actually met a really, really influential friend of mine, good friends to this day. He’s a trainer at Cloud Guru and when I met him, he gave me the scripting challenge that I needed to do. I was writing in VBScript, and he’s like, “No, you’re not going to write in VBScript. You’re going to write in PowerShell.” He taught me PowerShell. Then from that, we just fed off each other’s enthusiasm. He was a stickler for best practice, and he was an excellent mentor, and still is to this day.

I just essentially progressed my PowerShell skills, and got it to the point where I felt that I was comfortable enough to be called somewhat of an expert. I don’t like to use that term somewhat, mainly because I believe that we’re always still learning something new.

But at the same time, though, just getting my skills to that point. Then getting really involved within the PowerShell community. That was one of the interesting, I met some really, really cool people in there, and got involved within the PowerShell Conference Book Volume 2, where I was an author, and then unofficial editor. Then in Volume 3, I was a senior editor.

Then we decided that we didn’t want to write another PowerShell Conference Book, and we wanted to write something that was a little bit more, it was - the PowerShell Conference books were a little bit too advanced for a lot of the wider community. We wanted to write an intermediary book, where essentially it provides some of the key fundamental steps that can bootstrap you into that more advanced state. And that’s pretty much where I’m at today.

Len: Thanks very much for sharing that. I’ve got some more specific questions I’ll ask you about your book, and the subject of that and stuff like that.

But just to begin with, it’s interesting, over the years, this podcast has become a bit of a time capsule. Because so many Leanpub authors are people who write programming books, and things like that. It’s become a bit of a time capsule of eras in learning how to program.

I believe you were coming of age in the early part of this century, in the aughts. What resources did you have available, other than your father, to learn, and just hacking away like you did, what resources did you have available to learn? Did you have paper books, did you have the internet?

Michael: I didn’t have any of that. My father basically gave me some Microsoft CHM files that Ed Wilson worked on. Essentially it was the fundamentals. He found some examples on the internet, where they had like a little collection of scripts where they could do different things with the WMI, and things like that. That was how I learned to write code. For myself, it was the baptism of fire.

But it’s funny, because I learned to write VBScript in grade ten. By grade twelve, I was incredibly fluent in it. One of the projects we worked on, was VB.NET, within class. Making the step was just a no-brainer. I still didn’t fully understand the fundamentals, in terms of how to structure code in the way that’s maintainable, or what I would call “maintainable.” There was no testing back then. That was something that had to come after time. But from a learning perspective, it was just some sheets of paper, and essentially trial and error.

Len: That’s really interesting. I can imagine the excitement of getting something to work under those circumstances as well, must have been a special thrill, right?

Michael: It was. The biggest highlight for myself, there was two big highlights, but the one that I had in school was, when I was in school, I wrote this really, really rudimentary program. It was in VBScript, which essentially acted like a client server, so you could actually send commands to the server, and it could do things. It was not pretty, to say the least. But it worked. It was such a thrill to see that work.

The other one which I wrote was like a chat program, like an MSN Messenger. Obviously these kinds of languages are not multithreaded. I had to invent my own means, to be able to have a multithreading implementation. Again, it wasn’t good, but the thrill of it was, to see it work.

Then I was like, I thought, “Hey, let’s see if I can write some encryption for it.” So I, again, write some, I didn’t know what encryption was. I didn’t know how to access the libraries to be able to just basically encrypt a string. It essentially was, write something myself.

I would probably use the term obfuscation. It wasn’t encryption, it was more obfuscation. Essentially, it would just obfuscate the string. The way that it essentially worked, is you could actually have multiple concurrent sessions with different users talking to each other on the same server. It was, for being a kid, you’re like thinking, “This is actually really, really cool.” So, even to this day, I think it was really cool. I could probably rewrite it in a way that would be a lot better. But at the end of the day, it’s -

Len: That’s a really great story and,

Michael: There’s something there.

Len: I really like the passion, that one can have when one’s learning these things, the magic of being able to do it.

Michael: That’s exactly right. Nothing is more satisfying than to have the satisfaction, to see the project come to life.

It’s funny, it changes throughout time. Within, I wrote on my LinkedIn a very, very long time ago, it was probably in 2015, I wrote an article on essentially a systems administrator rudimentary Pixel Aimbot for Battlefield 4.

I did it as a proof of concept. Can you do something like this? I took some of the learnings that I had from VBScripting, and PowerShell. Being able to use the language, it made things, it allowed me to get things done a lot easier.

But it worked. Not great. It wasn’t a solution. But the concept worked. Seeing the program run in the background, and then literally the console, just immediately goes to a person’s head.

It’s just that remarkable piece of engineering. Thinking, “Hey, I’ve actually managed to do that,” and then overcome so many obstacles. I think, fast forward to today, especially with this book, I’ve been working on this book, we’ve been working on this book since 2020. It’s just that thing, being able to actually just keep pushing forward. Then the excitement of actually seeing that you’ve managed to create something so extraordinary, so -

Len: I’d like to hear more specifically about the book, and the process about how it came about, a little bit later on.

But before we do that, just moving on, in your, in the stages in your career. You learned a lot in high school, and stuff like that. Then you reached the point, where it’s time to, this sort of path, right? Where it’s like, “Get a job, or go to university.” I’m just looking at your LinkedIn profile here. I gather you sort of went and got a job. Is that right?

Michael: It’s very interesting. I went and did an advanced diploma in Information Technology. My high school score wasn’t good enough to go straight to university. I actually think that was a blessing in disguise. The reason why I say that, is because, I went and did an advanced diploma, and towards the end of it, I thought, “Is this something I really want to do?” I thought long and hard about it.

I thought, “Should I go and do something else?” I thought, “Hey, maybe I should just go and -“ I wanted to go and do electrical engineering within the army. That was something that piqued my interest for a bit. Then, essentially, I realized that this was something I’m truly passionate about, and something that I needed to do. Essentially, if I was to be able to continue to pursue it and get to that Nirvana, I’d be able to, I’ll never have to work a day in my life. I still see that, in a sense that, I get to do what I love, So I never work a day in my life. I just get to go to work and play around with PowerShell, and teach people about it, and make people’s lives easier. That’s what I’m passionate about.

After the advanced diploma, it was going to be a trip, I would have to go into university. I thought about that, and I thought, “Do I want to go and spend another four years studying?” This is something, especially from my perspective. This is, again, my opinion. Within the industry, is that, the relevance that the universities are essentially teaching, and what is provided, is not necessarily what’s aligned to what the industry’s having. And it just kind of, in our specific area, it means that, you can essentially go and get a diploma, and go and get a job. There’s nothing wrong with that. The degree adds a little bit more to it.

Some organizations will be wanting to hire a specific degree. But most people don’t. Essentially, what they’re looking for is industry certifications, and skills associated to that. And that’s one of those things that, for myself, it’s, I think I could’ve, a formalized study could’ve made it a little easier for myself. But at the same time though, I’m a bit of a stickler for going the extra mile. of, Working a little harder to get somewhere. I think that adds, from that perspective, the adversity, is something that I actually enjoy.

Len: Thanks very much for that explanation and that story. Without me having to ask you, you answered a version of a question that comes up on this podcast a lot. Which is like, there’s a matrix of “went to university,” “didn’t go to university,” “regret,” “don’t regret.” I’ve talked to people all over.

For a lot of people, particularly, I think if their passion is to do the work, getting out there into the world and doing it, is the best thing ever. Four years in university can seem like just sort of delayed time.

But I wanted to draw attention to something that people might not know about. This is a way of getting to ask you a specific question. But the industry certifications that you mentioned are incredibly rigorous and difficult, for people who don’t know. It’s not easy to get these kinds of certifications. Maybe we’ll get to talk a little bit more about what that experience is like a bit. But if you could, for example, for our audience listening, I’m sure you get this question at the pub table, or the in-laws, or whatever. But what does a systems administrator do?

Michael: I think the role’s actually changed over time. As a systems administrator, back in the day, the job was essentially to manage the infrastructure. They weren’t creating anything, they were just managing the infrastructure. I also know that systems administrator, in different, it can be different in different roles.

So, for instance, I know that in one role, it can be, “You are an engineer.” Which essentially is, you’re creating stuff. With that other systems administrator, it’s purely just maintaining systems, ongoing systems. I’ve grown up through that systems administration infrastructure process.

As you become more senior, generally speaking, you generally transfer into this engineering process. Then, obviously from that, the architecture. I’ve just taken a side detour to specialize in automation, and then go into that area. I’m stepping away from more of the infrastructure, and working in a little bit more of the dev space.

That’s something that I’ve always wanted to do. I always wanted to work within both worlds. Because I think that both worlds, realistically, have a lot to offer, especially towards each other.

Oh, so there’s one thing I kind of, just quickly wanted to take a quick step back to, with regards to my diploma, was that, one of the things, of what I still do, is I actually have a really close working relationship with the teachers there. I occasionally will go there out of my own time, and just go and talk to the students about PowerShell, and all about IT life, and what to expect. Just offer some basic nuggets with regards to that, and just tell them some funny stories about thing that I’ve done, that are really quite silly.

And the other thing, which is really quite cool, is to be able to sit down on the industry panel, and be able to sit there and to be able to review the course curriculums, and be able to actually say, “Okay, this is the emphasis that we want to be able to place on, provide a lot more guidance around that specific area.”

That’s something else that I work on. It’s something that I thoroughly enjoy as well. One of the things I am planning to do, is, once I do get the final paperback version, I’ll sign it and actually, well, once I’m finished reviewing it, sorry, I will sign it, and I’ll send it to those teachers as a thank you, for what they’ve done for me, and obviously, just return that favor.

Len: It’s really great to be able to give back to the community that way. Especially sort of share things with people, that you wished you’d known at the time thing. Maybe sort of like out in the field cutting edge stuff, that maybe the teachers aren’t themselves fully up on it, because that’s just not what they’re doing.

But just for people listening, when we’re talking about infrastructure and architecture, we’re talking about computing, IT, hardware architecture and infrastructure and code, and things like that.

I was wondering if you could, then, in that context - basically this is like the work that makes everything just go, right? The magical work. To those who don’t understand how it works, it’s like, why can you go on the internet and do all these crazy things? Well, it’s because there’s people out there who are making it all work. That evolves over time.

I was wondering if you could talk then, in that context, about what is PowerShell? Imagine you’re explaining it to someone who doesn’t know how to program, or anything like that, what are you working with when you’re working with PowerShell, and what are you trying to do?

Michael: PowerShell, the best way I’d like to describe PowerShell to anyone, is, it’s an automation language.

It essentially has two features. It has the feature of the actual scripting side of things. Where you are able to get stuff done. PowerShell, from that perspective, was implemented so that systems administrators can get stuff done quickly. What I mean, “get stuff done,” “Hey, you need to change 1,000 users, you need to remove, you need to change, there’s 1,000 users that you need to change a password to.”

In PowerShell, you can do that in one line. It’s really built on the PowerShell pipeline. That’s the key thing that makes it so powerful. Is the fact that you can essentially take object data, and literally hand it to different commands. It’s not just a string, like a bit of string data. It’s a full .NET object that you can pass.

The other thing, which is really powerful about the scripting side of things, is it has access to the .NET library. You can essentially write pretty much whatever you can do in C#. You can, pretty close, can do in PowerShell - there’s a lot of out of the box, there’s a lot of functionality that you can have at the fingertips. Which, if you compare to batch scripting and VBScripting, it’s light years ahead of that.

The other facet of PowerShell, being an automation language, is its ability for infrastructure as code. In PowerShell we call it “desired state configuration.” The whole concept of desired state configuration, is its ability to be able to prevent what we call “configuration drifts.” Think of it as, you’ve got this computer, you want to make sure that that computer basically keeps everything that it needs in a specific way, without things being changing.

Think of it as if an update comes down, or somebody jumps on there and makes a change, desired state configuration will recognize that change, and essentially it draws from the starcraft battlecruiser. It just makes it so. The concept is that it just puts it back. Essentially it just sees it’s out of configuration, and then brings it back into configuration, it just makes it so. That’s really the key thing.

That’s the two facets of PowerShell. To draw a little bit on from that infrastructure as code side, is that the infrastructure as code, that expands into other, obviously other technologies. You know, Puppet, Chef, Ansible. Those kinds of other tools out there. It essentially takes two cool pieces of technology, and makes them one, and makes it just a really, really great language to learn, to just get stuff done in a way that basically makes everybody’s life a lot easier.

Len: It’s interesting you mentioned that. Making people’s lives easier. I mean, well we had a big reminder in Canada not too long ago, when one of our major national telecoms providers went down for service. You didn’t realize how easy it was to like make a payment with your debit card, until like that, I’m not going to name the company, but like their service went down nationwide. Now, you couldn’t even call 911, which isn’t supposed to be able to happen, from some phones. You couldn’t walk into the store and pay with your card anymore.

There’s not only that you were inconvenienced by that, there’s the poor business that’s not making any money that whole day. Then multiply that by a whole country, and you’ve got a really big problem.

I don’t remember exactly what happened, and maybe it wasn’t along these lines. But it could’ve been along the lines, where like, some update was being done. Words like “configuration” are easy to say. But the reality underneath it is incredibly complex and evolving.

You can imagine a machine with a million different gears that need to fit together. But each gear is different and has its own basically width for the teeth, and stuff like that. If the update coming in doesn’t match that setting, as it were, to put it in a very cartoonish way. You can muck up the whole thing.

The work being done behind this, is just really important, the stakes are high.

Michael: It’s one of those things that I’ve always found within systems administration. It’s often a thankless job, it’s a job that, it’s really hard to justify resources for. Because the concept is that, “Well, the product is always, it’s still working, why should I invest more resources into it?”

It’s something that I’ve seen being addressed in a variety of different ways throughout my career, and within different organizations. It’s something that, I think, I’ve come to realize that it’s really, it comes down to an organizational philosophy, and how much it’s willing to invest.

When money is being invested, things just don’t break. The things is you can do really, really cool things. Where you can build a lot of really cool automation on top of it.

I’ll draw back to one of the places I used to work at with my really, really good friend. We had the opportunity, and it’s a very rare opportunity, to be able to build a new domain structure from the ground up. So, we decided that, oh, he decided that. This was even before I was there. I got to review the document.

But essentially, the idea was to build everything from the ground up, with automation in mind. The architecture across everything was built for automation.

When we did that, what happened was, once we had our infrastructure up and running, and it was all running smoothly, then when we stuck that automation on top, it just plugged in so smoothly. We automated everything. Because we had this amazing platform to do it, that had everything made available to us.

So, we built our own self-service portal before there were self-service portals. We had many, many script servers that could fix things that we didn’t have, that we couldn’t have done without it. It was one of those things, that, it just made IT life so much easier. That investment was key to the success and the longevity of that system.

Len: Was that recognized? Did you guys get like big bonuses and promotions?

Michael: It was a non-profit, so no.

Len: Okay. But I just bring it up, because you did mention the thankless job. This work is something, my clever formulation is, it has “invisible success.” Like if you succeed, it’s supposed to be the success that no-one notices, right? It’s like fire codes.

Like, if fire codes are made and followed and maintained, things don’t burn down. But the person who prevented it from all happening, doesn’t, hopefully get, like in a way, you don’t want them to get recognized, because you want it to just be a part of life that bad things don’t happen, and that good things can happen. It’s interesting that in a way, you can be the most important people at the company, and not regarded as such.

Michael: Yeah. It’s one of the things that, to draw on that, I recently gave a demo to a company I’ve been doing some work for. The whole concept is, they have a service that you can be able to run PowerShell scripts via the website. I wanted to be able to take infrastructure as code, and their website, and potentially marry them together. I explained it to him. I said, “I’m going to demo you the process that it’s going to take to create a new virtual machine, and it’s going to be remarkably boring.”

That’s because all the automation that’s been under the hood to make it remarkably boring, to make it mundane, to make it look like an iPhone, where essentially, it just works. The automation and the logic that has to go behind it to make, to get it to that point, essentially, that’s the cool part, that’s the part where you’ll be able to actually write that piece of code, to be able to do some incredible things with it, to make mundane automation. Where a person doesn’t even think twice. They think, “Oh, okay, I need to create a new virtual machine, next, next, next.” That’s not something for them that is quite special.

But then for the people that actually know it, under the hood, it’s a completely different thing. It’s the problem-solving that is required.

Another good example, just taking an operating system, for example, is that, it has to have the ability to be able to communicate with a variety of, just some different hardware devices, and be able to effectively communicate with them.

Recently, I’ve been looking at buying a little KVM switch for my computer here, and for my work laptop. I’ve been really diving into the detail spec of display port. I’m realizing that the spec is remarkable. It’s actually a very, very interesting piece of technology. But then actually looking at the challenges that people actually have to make, for instance, within a display port cable, to be able to -

A good example is display port compression. Where, essentially, the bandwidth is, if you’ve got, let’s say a 4K panel at 120 hertz, the bandwidth that’s available on that display port cable is actually not possible for you to be able to do that. What they will do is actually natively compress the data that’s being sent to your screen. Then, essentially the monitor will decompress that, and display the image. You can squeeze in a lot more bandwidth on that wire. There’s things like overdriving the cable a little bit. It’s just really, really quite interesting. Especially seeing the nuances that things have to go through to just make things like just work. That’s exciting.

Len: Earlier on you drew a connection between making things like that work, and making things like a book happen.

Just moving on to the next part of the interview to talk about the book, Modern IT Automation with PowerShell: Modern Automation with PowerShell. Just very briefly, I was wondering if you could talk about who the book is for? Who’s the intended audience?

Michael: Within the community, we have what we call “the baseline book,” which is generally recommended across for everyone. Which is essentially [PowerShell In A Month Of Lunches](https://www.amazon.com/Learn-Windows-PowerShell-Month-Lunches/dp/1617294160. This book really serves as an intermediary resource. Where it takes the learnings you have from PowerShell In A Month Of Lunches, which gives you the basics. There’s no point trying to re-teach what’s already been taught. They’ve gone through that a fair bit. But the idea is that it takes the key things that we use on a day to day basis, as a normal systems administrator, as a scripter, and be able to actually provide them, Add that content into the book. Essentially it makes the person a better coder and a better scripter.

That really serves as that stepping stone, if they basically choose to go and buy a PowerShell Conference textbook. A conference book, those books are very, very deep dives. In the PowerShell Conference Book the volume 2, one of the authors does a deep dive into PowerShell Tokenizer. Which is a very, very interesting read about how PowerShell actually parses it within C#. The actual C# class itself. A generic reader will just look at that and go, “This is a little bit too over my head.”

But at the end of the day though, it’s just that really great intermediary gap, that serves as the basics, as well as the advanced. It’s really kind of, we try to combine a variety of different things within there, that, within the PowerShell community, it’s common practice. But things like, just testing your code. Things like refactoring your code to, essentially just remove nested statements. Not thinking about writing code differently. Rather than, from a perspective of just, “Write something as an input/output.” But thinking about how to structure it in a way that’s a little bit easier to read. If you come back two months later, are you going to still look at it?

Then just be able to write better comments, things like that. That’s something where I find that it’s really beneficial, especially for other people to grasp that concept. There’s other things in there which I really wanted to place an emphasis on, was PowerShell security.

And one of the key things within the book, is, we do deep dives into constrained language mode. We do deep dives into, what we call, what I call, what we call JEA, or “Just Enough Administration.” It’s really making sure that the concepts are fully grasped. Because, from, obviously within today’s environment, especially with what’s happening with the cybersecurity side of things, this client, those chapters have never become more important and more relevant.

It’s something that I really wanted, I’ve spent a fair bit of time on the constrained language mode chapter, making sure that, and the JEA chapter, making sure that it’s everything that a person needs to know.

But it’s even more than that. It’s also thinking about best practices with regards to that. Thinking like, “Okay, how am I going to implement role configuration within a domain environment, Windows environment? How is that going to look like?” Essentially it’s describing those kinds of architectural decisions that have to be made, to be able to get it to that point. That’s really the approach that we took to that book.

Len: You mentioned community a couple of times. There’s actually a very specific meaning, in a sense to that here, with this project. Where, your co-author on Leanpub is the account for The DevOps Collective.

They’ve got a bunch of books on Leanpub. I was just wondering if you could talk about that? About, how did the idea for the book come about? Was it your idea, and you were already a part of The DevOps Collective? Or did they bring you in? I’m just not familiar with the story myself.

Michael: It’s kind of, it was an idea that I had. But I kind of, I worked on the PowerShell Conference books volume two and volume three. After volume three, I had a chat with one of the senior editors. I thought, “I’m not ready to get off this ride.”

The other thing was, I wanted to write a book that, I think we’ve written enough PowerShell Conference textbooks. What I wanted us to do was write something that was different. We wanted to write, oh sorry, “Conference Book,” not textbook. I always, I don’t know why that word just gets inserted in, it’s not a textbook, it’s just a book.

We wanted to write an actual study resource. We wanted to write something that someone can actually pick up and teach with. It’s an actual resource that it can be used by anybody within an academic’s sense, or within a professional sense.

We sat down, and we brainstormed about it. We brainstormed about this in 2020, me, myself and Steven. We talked about where we wanted to take it, and what we wanted to write. The key thing, what we wanted to do, is, we still wanted to make it, the book, all the proceeds to go to charity. That was one of our key goals.

The other thing which we really wanted to do, was basically write a book that focused, really emphasized on best practices, of what the community was doing. That’s really what we tried to put as much into this book as possible.

And, we, throughout the development of the book, one of the really cool things was that we always take our learnings from the previous Conference books. But we applied the DevOps mentality to our, the book. What we did, was, we essentially, our book was essentially written within GitHub using pull requests, code reviews, we had automatic linting in place.

It really helped the book progress quickly, compared to having a traditional Word document, and having manual merging. Most people that we engaged with were quite familiar with writing in Markdown. It wasn’t a learning experience for those guys.

Where it became a bit of a learning experience for us, was really starting to understand and pushing the limits of what LFM can actually do technically, to be able to achieve what we wanted it to do.

Len: I’d actually like to talk to you about that. We leave this part, where we talk about like the in the weeds of writing and publishing, for the end of the interview. Believe it or not, there are people who skip to the end, to just learn about that stuff. Because it’s just interesting to them.

But, so the process you were mentioning, I mean, for people who are familiar with writing things in plain text, and collaborating with, basically Git and GitHub, if you’re going to collaboratively write a program, you’re going to use those tools. If you’re going to collaboratively write a book, you use those tools.

They’re just amazing ways to write books, which is incredible. But you mentioned LFM. That’s “Leanpub Flavored Markdown.” That’s the sort of older version of Leanpub’s inhouse version of Markdown for books, basically. I was wondering if you could talk a little bit about the specific sort of challenges that you and your team, and I think your colleague, Nick sort of faced with that.

Michael: So, I have to give a massive shoutout to Nick. He is an absolute gun. He solved a lot of our issues. We’ve had these issues throughout the book. These are issues that, what we did, was we approached the book in a way that, when we structured our authoring and our editing, we would weed out as much as we can within our linting process. Then the rest would just have to be weeded out manually.

So, what happened was, the first big issue was margin issues. That plagued us in volume two. Where essentially, if you had a single line, if you had single word code locks within a sentence structure, it can potentially cause margin issues, where the words would actually trail off the edge of the screen. Things like that.

We addressed those post-editing, within the former PowerShell Conference textbooks, just by simply putting, our testing process was literally just holding a ruler up from the side of the screen, and scrolling down and looking for any sort of words that popped outside the margin. That worked, but it was still quite a challenge. The reason why, was because, you could try and hyphenate words. We had processes to be able to force a new line, and things around that. But the problem was, sometimes we just had to rewrite sentences to actually make them fit. That was a really big challenge.

Fast forward into this book, we didn’t have that issue as much. The biggest issue that we had, was our margin issue, was for our annotations at the bottom of a page. They would go off the side of the screen. It was GitHub. We would have to, we would be referencing a specific blob within GitHub’s URL. It’s URLs were incredibly long. It was very, very hard to fit, to break them. Nick actually figured out you can insert HTML into those, into the stream. It wouldn’t break the annotation, but it would allow us to insert spaces, to be able to eventually force Leanpub’s compiling process to create a new line. So, that’s how we got around that. We had to continually go back to fixing those issues. Because we would be changing URLs all the time, and then things would get pushed out of whack there.

The other spacing issue which we had issues with, was within our code blocks. We essentially wrote a piece of code that would look at multi-line code blocks, evaluate the code, look at the length of the code, then it would run a whole bunch of unit tests, other unit tests against them. Looking for specific issues with regards to, I know there was length, there was, oh, I can’t even remember them now. There was a number of different things that we were looking for. But the key things, is that it was, it enabled us to fix entirely all our multi-line code block line issues.

The other thing which we found, which was really, really good, was that, to make sure that if there was an issue, we just shrunk the text for our code blocks by one size. It would give us that little bit of extra real estate if they needed it. It wasn’t something that would particularly be a breaking issue within the book, you’ll just see it slightly smaller, but you wouldn’t see it run off the side of the page. That was something that we did as well.

The index was a really big challenge. That was something that we really, I really hummed and harred about even developing an index. We thought about, maybe, “Do we take the PDF, and then basically republish it after we give it to an indexer to manually index the book?” We decided that we were going to include the index into the build process.

I’m going to talk generally speaking here. Because Nick is the guy that wrote the code, and it’s very, very in-depth, and I haven’t had time to look, I didn’t actually look at the code.

Essentially, the way that it worked, was that it would, then, and Nick can correct me if I’m wrong. But the way that it worked, was, it would go to the latest build on, it would go to the latest preview URL on Leanpub. It would download that PDF. Then it would essentially parse that PDF as an object within C# as a .NET object within PowerShell. Then at the same time, what it would do, is it would go and grab the Markdown, and essentially match the two side by side. Which, if you think about that, that’s quite remarkable.

Then what we did, was, we had a CSV file, where essentially we could write within that CSV file, a specific, like, we could write headings. We’d have three types of headings. Then we would essentially write a regex string that would associate that specific pattern to those items.

You could also, on top of that, exclude specific patterns that were found. If you wanted to narrow the search results that you’ve found, you can also do that in there as well. You would run the script, and it would basically compile an index.

The key thing with the index, was that, and this is something that is quite remarkable, was that, it needed to preserve. It would create a table in Leanpub. That table structure needed to preserve the page. You couldn’t just build a singular table. You had to build multiple tables, because, the sizing of the page, it would just look weird if we compiled it.

So, in the final, the PDF, it’s a really, really interesting process. It’s something that, even to this day, I’m genuinely blown away with by the logic that had to be written. Essentially, you’re de-compiling a PDF, then associating it to a Markdown file. Which is something that, it’s just remarkable. So, hat off Nick. Massive, massive shoutout, and huge thank you. He was an instrumental member in that. He is an absolute regex gun.

Len: Wow, thanks very much for sharing that. We often like to say we’ve got the best customers in the book publishing industry, because they’re programmers, and solve these incredible problems. The sort of -

Michael: We like to solve problems, yeah.

Len: The sort of flip side of that, is that, sometimes Leanpub authors go out and solve all these problems, but then it’s a one-off. Because only they have their solution. So, one thing I should mention, is that, but that’s just amazing, that’s just amazing. And, in Markua 0.30, which isn’t fully implemented yet, but is the sort of successor to LFM or Leanpub Flavored Markdown, we will have indexing support, and, I mean, it won’t be anything like like probably as like kind of, at least to begin with, as fancy as what you guys did, but we do have that concept. Hopefully everyone won’t have to sort of reinvent this very, very complex wheel every time.

Michael: Wheel again, yeah.

Len: Every time. It should just, indexes should just work in Markua 0.30.

Michael: That’s one of the things that we do have. Everyone has taken a bit of a hiatus at the moment. A well-earned break.

One of the key things that we are still going to do is a review in retrospective, on what went well, what didn’t go well, what we need to improve for the future edition.

One of the key things that we have, already on our to-do list, is move off LFM into Markua. At the end of the day, we’re going to need to bite that bullet. It’s not something that I think it’s going to be that difficult to migrate across. I think there’ll be some sort of, there’ll be formatting issues within there. But at the end of the day though, it’s something that we’ve got, if we can write an index, we can address these problems.

I think we have the capability of be able to deal with that. Just have to just get inventive. That’s what we had to do, so, yeah.

Len: Yeah that’s great, actually. The last question I wanted to actually ask you about the book, is you mentioned in passing that the proceeds go to charity.

Michael: Yeah.

Len: They’re going to something called The DevOps Collective OnRamp program, providing scholarships to conferences and training for underrepresented demographics in IT. I was just wondering if you could talk a little bit about that?

Michael: Yes. Every year, when the PowerShell Summit happens, what usually happens side by side with the PowerShell Summit, is, they will do training. One of my friends was fortunate enough to be selected for that OnRamp program. I spent a lot of time mentoring him. It’s just getting them out, getting them into an environment where they can have the best of the best teaching them. They can ask all the questions. From an accommodation point of view, it’s free. They’ll pay for flights. Everything, just to be able to get them into that room, to be able to teach them what they need to know. That’s incredibly valuable. They can walk away with the experience.

But the other really important thing is they get to meet a lot of really, really cool people, to be able to help them along that journey. There’s a lot of people there that are willing to mentor them, that are really willing to just invest as much time and effort into them, to help their career. I think Don Jones used it perfectly. Which is the, in the book called, Be The Master. Is that, the concept of giving back, and the idea of the apprentice and becoming the master. Once the apprentice becomes the master, it’s the master’s responsibility to teach the new apprentice.

It’s the same philosophy that I apply with regards to teaching, investing in our younger generation. Because these guys are going to be the ones that are going to come through, and investing in new and cooler things, that I can’t even possibly have imagined. That’s really what the concept, and why we wanted to, why The DevOps Collective have really put that OnRamp program in place. Is just to help get these people who don’t have access to computers, or who don’t have access to, who are underrepresented. To give them the tools. The bootstrap process to get them into a really good, to get them into a job, and kickstart that career. Who knows? They might be running that in five, ten years’ time. So, and that would be amazing.

It’s funny, because, with my friend, and I’ve spent a lot of time trying to mentor him. He essentially finished an apprenticeship, and they said, “No, we don’t have any jobs for you.” So, I said, “Hey, go and do IT.” We basically livestreamed our PowerShell journey, and it was really informal, in that sense. We really just drove his career forward. I’m really proud of him. He’s doing a lot, and he’s kicking goals.

Len: Well, that’s just great. What a great program, what a great initiative. What a great sort of reasoning behind it, as you said from Don Jones’ book. That this idea of like passing, one obligation you have is passing it along, so someone else can pass it along to their next generation. That’s just amazing.

The last question I always ask on the podcast, if the guest is a Leanpub author, you’ve basically already answered, in a way, which is, if there’s one thing we could fix for you, or one magical feature we could build for you, what would you ask us to do? But in addition to all the problems that you solved yourselves, is there anything else that you can think of, that you would ask us to build or fix for you?

Michael: Apart from all the indexing things like that, I think, it’s a really tough question. Because the one thing that I would like, it’s one of those things that, for myself it’s, you don’t generally encounter these issues until you’re attempting a project. It’s always the review in retrospective of the current issues. To address future issues, it’s going to be really a, we’ve already discussed the review and what we found challenging, and what didn’t work. It’s something for myself, we’re not going to really know until we start to hit those issues.

I think, probably the thing for me, would be, I’m going to have to reiterate it, would be indexing and margin issues. I think annotations, I think it also has issues within Markua. I can’t remember if that’s the case, but that’s one thing as well. And, so that’s probably, I know that obviously Markua has a lot more of the features, which we’re wanting to make use, like exercises and things like that.

So, the future for the book, essentially, is to, what we’re wanting to do with, the idea is that, what we want to do for our second edition, is to actually also write an exercise lab manual with it as well. It’s the two books side by side, and be able to have all those exercises and things like that within that, so it simplifies a lot of the book. So that’s future Michael’s problems.

Len: Well if future Michael ever wants to get in touch with future Len, please don’t hesitate to reach out about any issues or questions.

Michael: No worries.

Len: Or anything like that. I mean, sometimes we might be able to sort of like answer a question that’ll save you a few hours of poking around. If anything like that ever does come up, please let me know.

But Michael, thanks very much for taking time out of your day to talk to our audience about your book, and about your background and your interests in PowerShell and everything. Thanks very much for being a Leanpub author.

Michael: Thank you so much, it’s been a pleasure.

Len: Thanks.

And as always, thanks to all of you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review it wherever you found it, and if you’d like to be a Leanpub author, please visit our website at leanpub.com.