Tom Hombergs, Author of Get Your Hands Dirty on Clean Architecture

Hi I’m Len Epp from Leanpub, and in this Leanpub Frontmatter podcast I'll be interviewing Tom Hombergs.

Based in Sydney, Tom is a Senior Developer at Atlassian, which is the company behind the software issue-tracking product Jira, amongst many other things.

Tom writes regularly about software development on this website at reflectoring.io, and you can also find some of his popular conference talks on YouTube.

You can follow his on Twitter @TomHombergs, and again, you can check out his work at reflectoring.io.

Tom is the author of the Leanpub book Get Your Hands Dirty on Clean Architecture: A Hands-on Guide to Creating Clean Web Applications with Code Examples in Java. In the book, using hands-on advice and examples, Tom discusses how you can use the Hexagonal Architecture style of software development to help keep development costs down throughout the life of an application.

In this interview, we’re going to talk about Tom'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 Tom for being on the Leanpub Frontmatter podcast.

Tom: Thanks for having me.

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 first found yourself becoming interested in software?

Tom: I grew up in Germany. In the introduction, you said I'm currently based in Sydney. It's just been four weeks. I grew up in Germany in a big metropolitan area in Western Germany, and went to school, went to university there, and I studied Computer Science.

I got in touch with computers in the 80s. My dad is an electrical engineer, so he tinkered around with computers and electrical stuff ever since I knew anything. He had a Commodore 64 when I was five or six, something like that. So I got to play games on the Commodore, which was very fun to do.

I remember the old tape cassettes. I don't know if you know them? You had this tape cassette where you had to forward to a certain spot, and then you could play the game that was at this spot on the cassette. Yeah, it's gotten a little easier nowadays.

Actually my first lines of source code that I wrote were in Basic on the Commodore, when I was 10 years old. We had a PC back then already, I think, and I tried to copy a game I was playing on the PC. So I started to program - I think it was a football manager program? But I didn't get very far.

Then came the PC age. I had a PC starting with a 286 - only for playing, no programming until I was 18, when I started to actually program in earnest. A couple of school friends and me organized these big computer parties. I don't know what the word is in English - everybody takes their computer, brings their computer, and create this big network and play games.

Len: I think I used to call them LAN parties.

Tom: Okay, it's the same word in German then - LAN parties, with 100 or 200 people, so pretty big. I started programming a tournament management intranet application, where everybody could enter the results of their games, and it would automatically pair up teams against each other. That was my first real contact with programming. And then it was just a matter of - yeah, I didn't even think about it - I just enrolled for Computer Science at university.

Len: I've got one or two questions to ask you about that. But before we do that - when I was researching for this interview, I actually came across a sort of funny coincidence. I recently interviewed someone, an American Leanpub author, who, when he was in high school, spent a year in Germany. That really changed his life, and he wrote a book partly about it. And I see on your LinkedIn profile that you actually - you went from this heavily populated part of Germany, to Illinois, for a year in high school. What was that experience like?

Tom: Yeah, it was not so populated there. It was pretty rural. I wasn't used to that, so it was a little boring for me, being 16 years old and not having a driver's license, and not getting around so much.

But I still think it's a great experience. I think every - if you have the opportunity to do this, which I had - it was kind of expensive, we have to pay this organization - there's this student exchange organization. But my family covered it all.

If you have this opportunity, I think everyone should take it. If you can get out of your country, out of your surroundings, out of your environment for a year - it only makes you a better person. You just learn so much. Even if it's - when I was there, I was pretty bored actually. But in retrospect, it was worth every day of it. And so - yeah, I can suggest everyone who has the opportunity to do that.

And this is - part of that experience made me and my family go to Sydney, which we just did a couple weeks ago. So that was kind of the origin story to today. I don't know if we if we would have made this decision if I hadn't had the experience of being overseas for a year.

Len: As someone who's moved around a fair amount myself, I can say one of the interesting paradoxes of - not just travelling, but living in more than one place - is that you learn about where you come from. You learn to understand where you're from a lot better when you go live somewhere else. And there's also something very unique about being a foreigner. People relate to you differently than they do to other people. It's something that I very much enjoy.

And so, you studied Computer Science in university - I have actually a very specific question, which, if you've listened to a couple of episodes of this podcast, you might be anticipating. But one thing I like to ask people, if they've studied Computer Science in university formally some years ago, if they were starting out their career now - hoping to go on the same trajectory - would they study Computer Science formally, and spend all those years and all that money again? What would you answer if I asked you that question?

Tom: Actually in Germany we don't - or at least, didn't have to pay money for college back then. So that was not a concern. Actually I don't know if I would have chosen it otherwise, but in retrospect - yes, I think I would do it again. You don't learn software development in Computer Science, at least not the software development you actually do in a company as a software developer - your projects and deadlines - I didn't even learn real coding skills. Yeah, we had some classes on programming languages. But you only learn that by doing it.

I still think it's worth at least having a couple years of university - a Bachelor's degree, for example - just to get mature. Because I don't think if I would have started working at a company when I was 21 or something around that, I think, a couple years later. I was a completely different person, like having learned how to get along at university. And I think much of it is learning to learn - getting to know yourself, to be able to know, "How can I learn stuff best?" It's very important, especially in software development. Because you have to learn new stuff all the time.

I don't necessarily think that you need a very long study, like a Master's degree. I did a Master's degree - but I don't think I would do that again. I would just, with my Bachelor's degree, go into a company and start working there.

What I would suggest anyone thinking about doing software development, is - while studying, start a job - a side job as a software developer. Because this is the way you actually learn it. Like two days a week, something like that. I did it, and I'm very glad I did it. Because, it's just a matter of signing a contract then, to get hired.

I stayed in the company where I was a software developer as a student, and I was there for 12 years. So that went pretty well. And it's a major recruiting channel for companies actually, at least where I come from. So, long story short, is - yes I would study computer science again, but I wouldn't do a Master's degree.

Len: Thanks very much for that really great answer. It's interesting - one thing I've noticed, asking so many people from so many different backgrounds, who went to university, didn't go to university, the same question over the years - one of the things that seems to decide the balance is if a person relates to their university education - as you described, it's learning how to learn, and personal development. Versus, people who see university as job training. And so people who are like, "Well, I took all these classes and I never use them in my life now." Well, that's the kind of person who's often like, "I wish I hadn't gone," or, "I wouldn't do it again." But there is this very stark dividing line between the way people relate to higher education, and even high school.

Tom: I haven't used much of what I learned at university. So actually, the things I learned at university - some of them, the basics around software development and some - we had some psychology, we had Media Science. It was interesting, but much of it I haven't used since.

But that's not the point. The point is getting to know yourself better to learn stuff, that's what I've been doing since, in my job.

Len: Yeah, and undertaking a multi-year self-directed project with an uncertain outcome, where you're being evaluated along the way, all the time in an irreversible way, is actually much harder than most jobs. That's one of the things that I always like to point out to people who like to draw a sort of cynical contrast between university and the real world. It's like, that's actually a lot harder than a lot of things that we do in our professional lives.

Speaking of which - you eventually got into writing, and I wanted to ask you how you got into that? You're a blogger and you're also a conference speaker, and you've got this book now. How did you find yourself getting going with writing?

Tom: I started my first blog, I think, something around 10 years ago? It turned out to be three blog posts, and then I never touched it again. I think many people writing start like that. Before that I really didn't like writing much. Even in school, I didn't understand why we would have to write essays and stuff like that. I didn't see the benefit in learning that.

But after my first blog didn't go so well - I just dumped it, and then I restarted it - I think three years ago? Actually, it was a project with a couple of my colleagues. We came up with the name "Reflectoring," which is a mixture of reflection and refactoring. I think that that's what the name is supposed to mean. I don't really remember, but I guess it's that. But it turned out that I was the only one actively writing articles.

So it became my blog over time. The first year, I just kind of wrote about random stuff, and not so many people wanted to read that. And then one and a half years ago, I started focusing on in-depth technical how-to articles around the Java programming language and the Spring framework - and that attracted a lot of visitors.

And of course, I'm - that's a part of the motivation. If people read what you're writing, that keeps the motivation up. I've been motivated since, and I keep growing my readership and have been trying to regularly host blogs - technical how-to's.

What I found out is that it's just doing it regularly in two weeks, one weeks intervals, that is actually the magic to keep it running. You have to get into a habit of doing it. I'm still doing it. It was a little hard while writing the book, what we're going to talk about later, I guess? But I managed it, and I'm very happy that I did. I like writing very much nowadays. I couldn't have thought of it five years ago, I hated writing.

Len: And so you worked for the same company for about 12 years, and then you've just recently moved to Sydney. How did that come about, and how have you found the move? I know that you're drenched in smoke right now from bush fires, if the news is correct.

Tom: Yes, actually this morning, I'm driving with a bus to work every morning, and I drive over the Harbor Bridge in Sydney - I'm with the bus. And when you drive over the Harbor Bridge, you see this dense smoke in downtown Sydney - which is kind of scary. I didn't know about the bush fires before we came here, perhaps that would have been a showstopper. But we're here now.

I'd been working at adesso in Germany - which is a consultancy, for pretty much all my professional life before that. I already said that I started there as a student developer and got into software development, Java programming. Then I took some more responsibility, did architecture work. I shaped the projects, worked with the team on the architecture, and led the development of a couple of developers.

I did a quick two-year detour in project management, because I thought, "I have to try it, otherwise I can't say if I love it or hate it." I know now that I hate it. So I got back to software development and architecture, that's been the work I've been doing the last couple years in Germany.

And then an Atlassian recruiter contacted me. In Germany you get recruiter messages over LinkedIn or [?], there are different platforms every week. So I didn't respond, actually - I didn't even think about it. Because it was for a position in Sydney after all, and I'm never going to Sydney - it's the other end of the world. So I didn't even reply to him.

But he kept nagging me two or three times. And then I said, "Okay, it's Atlassian - it's pretty cool." I knew Atlassian pretty much my whole career, because we were using their tools.

And so, I got in contact with him, did a video conference, and he set up these interviews. Then, I had actual interviews - coding interviews and culture interviews, three interviews in total.

After the first or second interview. I thought, "Well they - it's kind of fun." I liked what they were telling, and I thought they liked me pretty well too. So I talked to my wife. My wife obviously knew that I was talking to them, I couldn't keep that secret from her.

But then we decided in about a week's time - if I get an offer, we would do it. The main reasoning behind that is we wouldn't - we didn't want to ask ourselves in five years' time, "What would it have been like if we had taken that offer and gone to Australia?" That's the main motivation behind it. And basically risk-free, because Atlassian covers all the relocation costs and it's been a pretty smooth relocation, actually. And we can come back if it doesn't work out, any time.

I'm pretty happy with that decision right now. My wife would probably say otherwise currently, because she has the harder job. I'm already in a routine every day, and she's at home with the kids getting them into school - and that's probably the harder job.

Len: Thanks for sharing that story. I've got just one or two sort of funny questions about that. One is - I know you've been tweeting about it, but what's the biggest change that you've found in your day to day life, moving to Sydney?

Tom: The biggest change is probably the work culture here. Because, first of all - there's only 38 hours a week, which is kind of standard in Australia - if I get it right? In Germany it's always 40 hours and plus, so it's pretty relaxed here. Everyone is doing sports or some other activity at lunchtime. So I've been going running with a colleague here, every now and then, which I would have never thought possible at my job in Germany. So yeah, it's very relaxed. I'm still trying to cope with that - and especially only working 38 hours a week - that's what I have to get used to most.

Len: My next question is just kind of personal, but I spent a few weeks doing job training in Sydney once, and while I personally really like snakes, and really hate spiders. And I remember talking to some Australian friends of mine before going, and asking, "Is there anything I need to worry about?" And they're like - I won't do the accent, but the answer was typically, "No, unless you see a funnel web spider." And I was like, "What do they look like?" And they go, "Oh don't worry, you'll know when you see one." Which to someone who doesn't like spiders, is kind of the worst answer. I know it's kind of random, but was the animal life -?

Tom: Yeah. We haven't encountered any spiders other than the normal ones we would have in Germany too, yet. But yeah, that was - actually a lot of discussion before we moved here. Because there are these videos on YouTube about these giant Huntsman spiders, which are - yeah.

Len: Yeah.

Tom: I'm not going into detail.

Tom: I know what you're talking about. I remember talking to another Australian friend of mine, and he's like, "Oh yeah, you just put them in a jar and take them outside when you find one behind a painting on your wall." I'm like, "I would be terrified."

Tom: Yeah - they don't use a jar, because it's too small. So you have to use a bowl or something to capture them. We haven't encountered one yet. But yeah, I don't know what will happen if we do. I asked pretty much everyone here, "Have you seen a Huntsman spider or a funnel web spider?"

And they said, "Well, yeah, you will have Huntsman spiders sometime in your house, and you just take it out." Like you said. And the funnel web spiders, actually - you don't see them, because they burrow into holes and - only if you were actively looking for them, will you find them." So that's what I'm told. I haven't seen one yet, but we're still - we have yet to see kangaroos and koalas and the wildlife, so we're looking forward to that. That's the bright side of it.

Len: Yeah, oh there's many wonderful -

Tom: No problems with snakes or spiders.

Len: Many wonderful happy animals in Australia as well as the like scary comic book ones as well.

So, moving on to your book, and getting a little bit technical - I've interviewed a couple of people who've written books about software architecture before, but I've actually never really asked the question, what is software architecture? Imagine you were explaining it to someone who's never heard of it, and they know programmers write code that makes programs run, but what is software architecture?

Tom: I think I would explain it like this. Software architecture is giving structure to the code you're coding. So your programmer writes code - and this can be good code, it can be bad code. And the structure of the code can be good or bad as well. If you just randomly write code and put it all into one source code file, this is not going to be very easy to read, and easy to understand.

So part of software architecture is structuring your code into components, and taking care of the dependencies between the components - one component uses another, and this one uses another again. This is software architecture in a general sense.

But then you also have - and this is what my book is actually about - the software part, the coding structure part of things. Other definitions of software architecture include the more - yeah, it includes system architect systems.

So one system calls another system, and works with the dependencies between the systems. This is like on a larger scale. But my book actually has this approach of structuring your code into cohesive modules, and yeah, that's what the book is about.

Len:Yeah, I've got a couple of questions about that - including what hexagonal architecture is about. But before we do that, can you talk a little bit about layers?

Tom: Ah, layers.

Len: What are layers, and what's your problem with them?

Tom: This is actually one very common architecture you'll find in most of the projects, is layering your code. So, you have several layers of code. One layer calls the next.

For example, if you have a web application, you will have one layer of code files that interface with the browser. They take the calls from the browser, they transform it into objects, and pass it on into the so-called business layer.

And the business layer is where the actual code that runs your business is. All your business rules, like pricing, or whatever you will have in your particular web application.

This is the business layer, which contains the business code - the rules of your business.

And then there usually is a so-called persistence layer, which allows the business code to interface with the database, to store data, to retrieve data.

And it's very common to have these three layers separated - because they each have their own responsibilities. The web layer interfaces with the browser or with other systems. The business layer does the actual business logic, and the persistence layer interfaces with the database - translates it into the database, and into SQL and back. This is what you typically find in web applications.

I've done it like this for about ten years, and I got a little frustrated with it. Because the layers always tended to erode pretty quickly. Especially the business code, in the business layer - it always tended to be intertwined with the persistence code that actually calls the database.

Sometimes you have a requirement where you change a certain aspect of your business rules, but then you would also have to fight with the persistence around that. Instead, I would like to have a very clear responsibility of the business layer only for your business rules. I would like to be able to change this business rule in the business layer, without having to think about database issues. Stuff like that. And this wasn't possible.

So this is when I read Robert Martin's book Clean Architecture, which describes with a very high-level approach, how to avoid this.

And the approach is to put your business code into the middle of things, and not have dependencies to, for example, your database. You do it the other way around. So your database, your persistence layer has dependency to your business layer, and not the other way around. This makes your domain, your business code, the center of things. You can change anything in your domain code you wish, without having to think about the database.

This is not possible in all circumstances and in all applications - but for the normal web application, it is possible.

But the book Clean Architecture is actually very high-level. So I was still frustrated with it. I didn't know how to actually work code into an architecture like this. So I researched further and stumbled upon hexagonal architecture, which is a concept by Alistair Cockburn. I think it's also ten years or even a older than that. It's a little more concrete.

But I still wasn't satisfied with it, so I decided to try it out myself and play around with code a little. I created an example application, and I thought, "Okay, this is worth writing about." So I started to write the book about a year ago, I think?

Len: It's really interesting - one of the things you're talking about is the difference between, let's say the idea of like layers, where it's like, you can imagine sheets of paper, one on top of each other - as opposed to like an onion, where there's something at the center of things, and then things are outside of that.

One of the things that you've written about and you were just talking about, was the concept of dependencies. And this is a really important concept, particularly if you're - I mean, it's an important concept for all software, but particularly if you've been working with third-party clients and things like that, in consulting roles - where all of a sudden a requirement changes on you, and your, if you haven't structured your dependencies properly - something over here can break something over there, when it shouldn't. And this is a lot of what doing software architecture is about.

Tom: Yeah, exactly. Software architecture is basically managing dependencies, that they are going into the right direction, and that you don't have too many of them. And yeah, that's exactly what this architecture approach I'm describing is about.

It's not new by any means. Clean architecture and hexagonal architecture have been around for ten years or so. But yeah, it's exactly that. You don't want your external dependencies, like the database or the web, to have influence on your business code. Because the business code is what runs your business, and what makes you money, hopefully. And you don't want to - if the database needs some upgrade, you don't want to have to upgrade your business rules - because some database changes, you don't want that.

Managing dependencies is the best way. The magic key word is "dependency inversion principle," which is one of the SOLID principles which I think also come from Robert Martin, also ten years or so back. So, you invert your dependencies. You don't let your business code depend on your persistence or database code, but you invert it, so it's the other way around.

Len: It's really interesting, you actually just reminded me of an old memory. I had a job in London in 1999 with a relatively new company that involved, developing some software to report on mergers and acquisitions around the world. It was very new, and at one point - well, relatively frequently the software that we were using to develop this database would break down. And then we're all just sitting there twiddling our thumbs, and the managers are like, "This is all money going down the drain." So it wasn't as bad as like an automotive plant going down, but it was pretty bad when that would happen.

And one time - after this had been going on for a couple of hours, one of the lead developers came over to me, and, with this very sort of like portentous look on his face, and he said, "The thing is that - the boss has been complaining about who broke the software for the last couple of hours and he's really angry, and I'm sorry to tell you that the person that he's angry at is you." I didn't know a thing about programming, but I knew logic, and I just exploded and said, "What the f are you talking about? If I clicked a button in a user interface and that broke the software, that's not my fault and I think you should go back in to explain to the boss what the real problem is here."

And it sounds - I mean things are a lot more sophisticated in the software world since 20 years ago, but I'm just using this as a real-world example of how - if you don't manage dependencies properly when you're building software, it has real impact on people. It's not just sort of buggy code or something like that.

Tom: Yeah and also, if you don't know your dependencies, you don't know who to blame for some error, right?

Len: Right.

Tom: So if you have your dependencies and know them, you can tell the guy who inserted the error to fix it. That's actually one effect of managing dependencies as well.

Len: And what is hexagonal architecture?

Tom: It's pretty much the same as the clean architecture approach I talked about earlier, it's just a different word for it. It's a different shape. You had talked about the onion earlier, which is kind of a thing Robert Martin uses to - he explains his clean architecture in circles. So you have your business code in the middle, and then you have layers surrounding this, with the dependencies always pointing inward.

Alistair Cockburn used another, different geometric shape, obviously - he used the hexagon. Which - I don't think there is a real good reason why he did that, other than, I think he said, he wrote in a blog post that he used the hexagon to show that a software component can have more than four sides, but he could have used any other shape.

So it's just that the hexagon is in the center of things. This is your core application, your business rules or whatever you call it.

And then on the outside of this hexagon, you have adapters that talk to your application, or that your application talks to. But it also makes use of the dependency inversion principle, and it's pretty much the same as Robert Martin explained in his Clean Architecture book.

Len: And if there were one thing you hope that every reader of your book would take away from a reading of it, what would that thing be? I know it's very distilled down when it's a whole book -

Tom: I think the one thing is that you don't have to do everything with the same architecture style. So what I've done the past couple years when I've done architecture work, is I created layers. And I didn't do it because I actually thought about it, I did it because everyone did it like this. This is pretty much the thing that readers should take with them, that there are other options - and there are other options beside a hexagonal or clean architecture as well. This is not the solution for every application out there. But just having options is a very good thing. Because otherwise you might get stuck with your big ball of mud.

Len: Moving on to the last part of the interview, where we talk about your experiences and as an author. Can you talk a little bit about why you chose Leanpub as the platform to write this book?

Tom: I don't really remember when I stumbled upon Leanpub. I think it was because I've seen some other people from the software development community in Germany published there, but I don't remember who it was. I didn't have a real idea what the book would be. Well, I knew what the book would be about, I didn't have it all structured yet. I didn't have a complete idea of the contents of each chapter, and things like that. So I didn't want to approach a real publisher, because I knew that if I did that, I would have to pitch it, and I would have to do some work up front and really sell the idea.

And I didn't want to have any deadlines, so this is when I came across Leanpub and just started writing. I don't think at first that I did have the goal of actually finishing and publishing it, this only came after I created one, two, three chapters.

And then I picked up - so at first it was very slow going, one chapter every month or so. Then sooner or later, I finished two chapters a month. So I increased the pace somewhat.

I published it on Leanpub about half way through, this is one of the things I liked - to create an audience, to publish it even before it's ready. I got some feedback through that and improved the book, and then sometime this fall - well, fall in Europe, not in Australia - I finished it, and yeah, it's a very rewarding experience.

I'm seeing that people actually spend money on what you've been writing. That's pretty cool. And I'm still getting feedback through email, and it's very easy to include the feedback into the book and then publish a new version of it. That's one of the things I like very much.

The book's been published at Packt, Packt publishing. They approached me, and I asked them if they could license the book for me. Which I did, but I told them that I still wanted to have it on Leanpub. So they - usually it's an exclusive deal, but they excluded Leanpub from that. So I'm pretty happy how it worked out.

Len: Thank you for sharing that story, that's really great. Actually, a lot of people think that at Leanpub, we're disappointed if a Leanpub book get gets picked up by a publisher. But actually to us, that's a great success story. Although I do want to say thank you for negotiating to keep the book on Leanpub. Because we like that too.

One of the interesting types of independence that you get from self-publishing is a strong negotiating position, if your book already has some traction. And if you can build traction while you're writing your book, it actually gives you -

This is sort of deep in the lean publishing philosophy. If you want to approach a publisher to pitch them - if you have books that you've written in the past, you can point to those. You can point to your online audience, things like that. But if you're working on a book and you already have an audience for it - that can be a very attractive thing to a publisher, to see that that a book has traction even before it's finished.

Did you invite feedback explicitly from people, or did they just start spontaneously offering it to you?

Tom: I was pretty open about it. In the preface, I put in my email address and invited people to give me feedback any time they see something, and I repeated that in the end. So, the last sentence of the book is, "Send me an email if you find something." And that went pretty well. I'm still getting feedback about once a week or so from a reader about the book. All are worth looking into, some I include in the next version of the book. Some are ideas for perhaps blog posts around that topic, that don't really fit into the book. But yeah, it helps to actually invite feedback. I don't think that I would have gotten that kind of feedback if I wouldn't have included my email address.

Len: It's really interesting - I've been working on Leanpub since 2011, and it's interesting how conventions have changed over the years. It used to be that people were kind of nervous about giving out their email address, to everybody who gets their book. But now it's a completely normal thing. It's understood by the authors to be normal. It's understood by the readers to be normal. And one of the curious things about it, with so much mayhem on social media - people seem to behave themselves pretty well on email, at least when it comes to non-political stuff.

Tom: Now that you say that, yeah, the emails - there wasn't a single spammy email that come through that channel. So I'm pretty glad that I did it. Email is still one of my favorite channels, to be honest. I'm very, very lazy about social media. And here at Atlassian, we use Slack for work, which I find is totally distracting from work actually. I still have to get used to that. So email is actually my favorite means of communication.

Len: It's funny, I think we could do a whole - it sounds like we could have a whole other episode devoted to that subject, because I think I'm totally with you on that. Email has structure to it, in a way that sort of things like Slack don't. We use Slack at Leanpub as well. But the structure and just the nature of the email medium, I think, is better for communicating in most circumstances.

The last question I always like to ask on this podcast is - if there was one thing we could build for you on Leanpub, or one thing we could fix for you that really bugged you - what would you ask us to do?

Tom: I think what bothered me more at the start than it does now, is that there is not a way to have an offline preview of your book. I used the GitHub approach. So I commit my Markdown files to GitHub, and then click on the "create a new version of the book" button on Leanpub, and then it pulls it from GitHub and creates the preview PDF files and MOBI files. And at the start, when I wasn't quite sure how it all worked, it was pretty annoying to always have to push it to GitHub and then click the button on Leanpub; this has a very long turnaround. But once I got it working and I concentrated on actually writing, it wasn't so much of a bother anymore. I think it's a starting thing that could've been better - if I had a version offline, to create a preview offline, some way.

Len: Thanks very much for sharing that - it's very important to us to hear about people's first experience, and what it's like when they're using Leanpub. So for example, if we had like an app you could download that would then generate the book locally - is that something that you would be interested in?

Tom: Yeah definitely, that's pretty much it.

Len: Okay, thanks. I can't make any promises, but we listen very carefully to our authors, because they're all - I mean, one of the really fortunate things about running a SaaS platform that people use to publish technical books, is that we have a technical customers who really know what they're ,doing and also know how to communicate things like that, so that's really great.

Well, thank you very much, Tom, for taking time out of the day to do this interview, and good luck with your adjustment to life in Australia.

Tom: Thank you very much.

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 yourself, please check out our website at leanpub.com. Thanks.