Leanpub Podcast Interview #32: Nick Sutterer
published Jun 10, 2016
Nick Sutterer is a Sydney-based software developer and popular conference speaker, with a particular interest in open source frameworks and software architecture. In this interview, Leanpub co-founders Len Epp and Peter Armstrong talk with Nick about his career, about his book, and about self-publishing on Leanpub.
This interview was recorded on April 26, 2016.
This interview has been edited for conciseness and clarity.
Len: Hi, I’m Len Epp from Leanpub, and in this Leanpub Podcast I’ll be interviewing Nick Sutterer.
Nick is the author of the Leanpub book Trailblazer: A New Architecture For Rails. The book helps you build a complete Rails application using Trailblazer, a thin layer on top of Rails Nick built that brings a high level application architecture, decent encapsulation of the new code structure. In Nick’s own words, “The book takes you for an adventure trip from Rails code jungle, to the Trailblazer beach, and involves building a complete Rails application using all of Trailblazer’s goodies well, exploiting the Rails way where it helps.”
Based in Sydney, Australia and originally from Germany, Nick is a software developer and popular conference speaker, with a particular interest in open source frameworks and software architecture. He blogs nicksda.apotomo.de and you can follow him on Twitter at @apotonick, and you can also find Trailblazer on GitHub at github.com/trailblazer.
In this interview, we’re going to talk about Nick’s professional interests, his work building Trailblazer, his book, and at the end, his experience using Leanpub and ways we can improve it.
Just before I start asking questions, I want to say that we’re joined today by my Leanpub co-founder, Peter Armstrong. He’s going to be asking some questions later on. So, welcome Peter.
Len: I usually like to start these interviews by asking people for their origin story. I was wondering if you could tell me how you got interested in software, and specifically what led you to build Trailblazer?
Nick: It all started with computer games. I was one of the lucky kids who had access to computers really early. So we’re talking about the early 80’s. I was playing black and white computer games, and I really got intrigued by the idea of making my own games. So that’s how I got into programming. Of course, I’ve never managed to write a game. But I started playing around with HyperCard on really old Apples, and moved on to C++, and 15 years later, ended up with Ruby. That was a nice development.
Len: I found a talk online, I think it might have been in India, where you said that you wouldn’t be a programmer if it wasn’t for open source. I was wondering if you could explain why that is?
Nick: Wow, so you actually watched my talks, so that’s great. As I said, I started programming following this idea of writing computer games. I was maybe ten years old, and you are not going to write a computer game when you’re ten years old. So I kept playing with lots of languages, and I think I started Perl, and I got intrigued by this idea of object oriented programming encapsulation - even though I did not have any idea what real encapsulation looks like in an actual program.
I was also reading about TCP/IP Illustrated, and this taught me a lot about layering. So I learnt a lot about like - this layer isn’t supposed to know about the other layer. So, I kind of saw the similarity to object oriented programming, and I started playing with a widget framework written in Perl. Of course, not a single company on this planet is using it. But that was when I had my first feedback from actual users or people trying it.
By that time, I was still working as a Perl/PHP web dev. But I wasn’t really loving working on other people’s products only. So the open source stuff gave me gave me some kind of new direction and motivation to keep working in the web environment. And it’s absolutely true, if I wouldn’t have discovered Ruby, and if I wouldn’t have discovered all the problems in Rails that I was trying to solve, I probably would’ve ended up in a different discipline. Something probably like a game developer working for some awesome company, and working on Assassin’s Creed 500. Who knows if that would’ve been the better choice?
As soon as I got into Ruby, and I had this little bit of experience from that Perl project, I started working on open source. And people started actually using it. That was amazing. It’s still amazing. I got feedback - people telling me, “Hey, I forked your project and looked at it”, and I was like, “Oh, this person’s so much better than I am.” And this is how I kept doing what I do for the last 10 years.
Len: It’s really interesting the experience that one can have, if you get early feedback on things from people using it, and what a motivator that can be.
About Trailblazer. I was wondering if you could explain a little bit about what it is, and why you built it. What problem is it solving?
Nick: So Trailblazer, if you have a superficial look at it, it only adds technical complexity to a framework that is already complex, like Rails or Sinatra or whatever. The goal is to add abstraction layers on top of the existing primitive - primitive not in a bad way, but it is primitive on the MVC stack.
So what Trailblazer basically says is: Writing or architecting complex web applications, and that’s what we all do every day, is a complicated task, and having two or three buckets for all our code - M, V, and C, and we don’t put code into Views so we only have M and C - two buckets for complex apps is not enough.
We need more layers to structure code to know where to put certain requirements, to know where to put implementations, and to make it also a bit more straightforward how to test specific functionality.
So what Trailblazer does is - it says, “Use Rails or use Hanami or use Sinatra or whatever” - as what I call an infrastructure framework. It gives us all the task generators, it gives us routing, it gives us HTTP endpoints, also known as controllers. And on top of that, introduce additional abstractions, like deserialization, validation, callback objects and all this kind of stuff.
The additional layers streamline our everyday task of writing functions for web applications. And then, again, go back to the original stack, and use whatever persistence layer is desired. It could SQL, it could Active Record, it could be a Hanami model or ROM, or whatever. We basically give them abstractions from HTTP till persistence layer.
It was a little bit chaotic in the early days of Trailblazer, because we didn’t really know how to communicate what we are doing. But now that we have this word called “high-level architecture”, if people ask me, “What is Trailblazer?” I say, “High level architecture.” And then they either run away and say, “That’s weird.” Or they say, “What is a high level architecture?” And that’s exactly the same abstraction layers that we provide- here’s a bit more layering, a bit more structuring, more components to actually implement your web request. And that’s what Trailblazer does.
Len: Fantastic. I think Peter probably has a couple of questions he’d like to ask about that.
Peter: Sure, so when I was reading the introduction in the first chapter of your book, I found myself agreeing with a lot of your parts of your descriptions and the problems that exist in Rails. So I was wondering what you’d say the main problems of Rails that Trailblazer addresses are?
Nick: So the thing is, I never wrote Trailblazer or the gems–so Trailblazer’s only a collection of a lot of gems I’ve written in the last ten years–I never wrote them just because I wanted to write gems and feel great about being an open source developer who doesn’t get paid for a job anyway. It was always tackling a specific problem and so - I mean I could go into details of all the gems now, but Trailblazer is solving the problem of, “Where do we put a specific kind of code?” So Trailblazer has a bucket for any kind of implementational code snippet you have. So we have buckets for authorization, authentication, for callbacks decoupled from models and for rendering JSON documents, for de-serializing documents, for validating object graphs.
So we have a handful of buckets to put your code into. That is a problem in Rails I’ve seen in hundreds of apps being solved in different ways. So every big project has a different architecture. And there’s zero conventions beyond how to name table names, and how to name controllers. Because that’s what Rails conventions are. They are really primitive.
We give them a strong, high-level and really opinionated structure for their code and their implementations.
Also Trailblazer is solving the problem of testing in a really different way than Rails. So when I arrived, [looking at] pure Rails applications, I always found myself wondering, where do I test stuff? Is that an action, is it a controller test, is it a view test, is that a model test, is that a unit test, is that an integration test?
In Trailblazer we go a completely different way. We say: Decouple all the business logic into specific objects. We call them operations. So all the business logic from deserializing the incoming data to persisting - whatever you want to do - is happening in an encapsulated object in an operation. So we only have unit tests for operations, and we have integration tests to see if the controller wiring works. It’s always really clear when you write a new feature, what to test, and it’s also way faster, because you don’t have to do everything via HTTP tests.
The funny thing is, that wasn’t really planned. But it turned out to be a great feature that a lot of Trailblazer developers love, that we really have a distinct way of saying, “This is what you have to test, and this is how you test it.” And that’s it. So no thinking, “Oh, what should I do? Should I go write another model test? Or should I write another controller test?”
For example, we don’t have controller tests at all. We have integration tests, and that’s it.
The third thing we solve is, that people learn a bit more about object orientation. Because since we introduced all those layers, and all those layers are basically implemented as Ruby objects, people learn, “Okay, this is how object oriented design was originally intended”.
Rails is absolutely misleading you when it comes to object orientation. Just because we have model objects, or we have the controller object, doesn’t mean that this is object oriented. By introducing smaller objects with a limited scope of jobs, people learn, “Okay this is actually probably closer to what object orientation means”.
I’m not saying that we are doing everything right, and everything is the best and Martin Fowler will read Trailblazer code and will say, “This is exactly what I thought about object orientation”. No. But I think it’s closer to the original idea, and the benefit is that you have a really quick understanding of what the app is doing, because every object is only doing one thing, and has, probably has, only one public method. And there’s no way to screw up internal state.
That’s what lots of people told me, is that they after working with Trailblazer, they started to feel what a good object design looks like. Whereas in Rails, you only know, “I have a model, and my model has 500 methods, and that’s called object-oriented design”.
Peter: Right. So Trailblazer is an architectural style, but it’s also a collection of gems. So for someone who’s brand new to Trailblazer, can you give a high level overview of the different gems, but also, I’m more interested in understanding when you realized that you were creating Trailblazer? I mean, you started with one gem and then moved on. I’m curious about how it evolved in your mind, about what you were doing?
Nick: That’s a nice question. I’ll start chronologically, and it’ll all make sense. Once I started writing Rails [apps], I wanted to have a reusable sidebar view component or something, and I couldn’t find anything like that. They told me, use partials and helpers and controller and blah, blah, blah. So I was basically spreading the logic across the entire stack, and I didn’t feel right. I wanted to have a reusable, encapsulated component I can reuse in every Rails controller action, and have my sidebar rendered.
So I started working on that gem called Cells, which introduces what we call “view models” into Rails. It basically gives you components, and the component, all it does is, it’s an object, and it can render a template, and it can execute arbitrary code. So basically it’s a partial, an encapsulated partial. The partial doesn’t have access to the rest of the stack. And so that was the view gem called Cells. Cells is part of Trailblazer, but it doesn’t have any wiring to Trailblazer. It works without Trailblazer, and that’s good, because it’s the most popular actual view replacement of - actually the only replacement for Rails. So lots of people use Cells in thousands and hundreds of thousands of projects.
That was my first gem, and I realized, if there is interest in this kind of stuff, then it can’t be all too wrong to work on alternative patterns in Rails. So I worked on a lot of other gems, and they were part of Trailblazer, including Representable and ROAR.
They’re basically a document parsing and document rendering library. You can grab a document and parse it into an object graph in Ruby, and you can grab any Ruby object or an object graph - nested objects - and render that into, let’s say, a JSON document. That is another gem I was working on. That’s helpful if you write document APIs, like JSON APIs or XML APIs. I know no one’s writing XML anymore, but people still have lots of questions about how to render and parse XML. But that is, again, something completely decoupled from Trailblazer - helping you with rendering and parsing documents in Ruby.
After that, I started working on Reform, which is basically saying - we don’t want to have validations in our models, because sometimes I have a form that might incorporate two or three models, or something that is not even a model at all. And I still want to have validations, I still want to define my fields. So Reform, basically it says, “I’m a form, tell me what are my fields, tell me what’s my nesting, and tell me what are my validations? I’ll help you do the validations, and I’ll help you write those validated data - hashes, or whatever, back to whatever models you want me to”.
So we took the validation out of the model layer in Rails, and put it into a separate validation layer. And so we had views, we had rendering, parsing of documents, and we had Reform, the form object.
And that’s when I started to realize, hmm. The way I wrote controllers in Rails changed, because I was always using the form object, I was always using a new component. And in document APIs, I would always use the representers from ROAR Representable. So I came up with a concept called “Operation”, which is now the central notion in Trailblazer, which is what wraps your business logic. And so Operation is in the Trailblazer gem.
How did I name this “Operation”? The gem name Operation is already taken. I could just start a new framework, like a meta-framework… Whatever, what do I call it?
I was looking on my desk, and there was an old newspaper, and it said like, “Blah, blah, blah is a trailblazer.” And I’m like, “Hey wait, Trailblazer’s a cool name.” So I named the gem Trailblazer, put in the Operation pattern. Only the Operation gem, like the operation pattern was the only thing in the gem. And so the Operation, Representers connects form objects and connects your persistence layer. It’s just an orchestrating object.
Once this gem was there, and the Operation pattern became more and more clear as wrapping your business logic, and orchestrating to all the other stakeholder objects - new things popped up, like policy objects and callback objects and all this kind of stuff. But the main road was really Cells, and then Reform, and once we had Reform, we needed a place to orchestrate it - how the form interacts with the outside world. And that’s where Operation came from, and that’s how Trailblazer kind of started. Then, on top of that, lots of other things were added.
Peter: Cool. I have one more question, and this is a really selfish one.
Nick: Yeah of course. A lot of people do that actually. In my current project, we do the same. We have React front ends, and we have a Trailblazer back end. The only thing we do not use is the Cells gem, the view component gem, because that is supposed to render HTML. You can even use Cells with React. It kind of helps. What you do is, you leave out the view layer, and you still use the deserialization, validation, the persistance layer - all that stuff that Trailblazer structures in your Rails, or whatever.
What we had, and it’s pretty cool actually is, we had this back end in Rails, and we started to port certain actions or certain functionalities into Trailblazer operations. So the controller would only delegate or despatch to an operation directly, without any logic in the controller, because that’s what Trailblazer wants you to do.
Eventually, we could kind of swap the underlying framework. So we could say, “See you later Rails”, And we started using another framework called grape. So we swapped the underlying framework, because Trailblazer allowed us to decouple all our logic from the actual framework. But we still use Trailblazer in a React backend, basically. That answers your question I hope.
Len: Is there a specific intended audience for your book, Trailblazer? Or is it just for anybody who might be interested in learning the framework?
Nick: I didn’t really know who was supposed to be the audience. When I started writing the book, it turned out that the audience for Trailblazer is, all levels of developers. We’ve had people who’ve been around for 15 years checking it out and using it or not using it. We’ve had people who just started Ruby five days ago, and they were intrigued by the idea of layering. And just because there’s more technical complexity doesn’t mean that it’s more complex. The opposite is the case.
The book tries to propagate that on every one of the 308 pages. We are walking people step-wise to master the technical complexity, as people call it. But technical complexity doesn’t mean it’s harder to understand. The opposite. You have smaller objects, easier and nicely layered implementation components that make it easier to understand how software works, and not harder.
So the audience - and it’s really interesting. If you’re on the Trailblazer GitHub channel, you will have people from all kinds of companies, from all kinds of environments. It’s really interesting. We don’t have like a target audience. We try to target everyone. And that’s working; when I check the book and the readers, there’s all kinds of readers, which is great.
Len: Your book’s been quite successful, and I was wondering if there’s anything special that you did in order to achieve that? Obviously, besides writing a really good book and having an existing community already on GitHub, was there anything else that you did to promote it?
Nick: Just in case you didn’t notice, I have the coolest book cover in the world.
Peter: So who did the art for the cover and the cartoons inside?
Nick: There is an artist, his name is Josh Bourne. He’s American, but he lives in Berlin, anh he’s best friends with one of my best, oldest friends. They’re both artists, and they share the same studio in Berlin. I was originally asking my friend, but he was busy. So he told me to get in touch with Josh, and this was just the best thing ever. We would start with little emails. He would send me scribbles and stuff, and the outcome was we have the best book cover, in my opinion, and lots of cool illustrations in the book, and stickers. His style just fits the whole trailblazer project. So that was a lot of fun.
I don’t think the book cover is actually what makes people buy the book. I think it’s driving more people away because it looks really unprofessional. The thing is, I have a huge community of people using one or two of my gems. Those people were excited when they heard, “Okay there’s some umbrella project starting”. And I think that’s what makes people buy it.
The other thing is, we haven’t really started any marketing campaigns. So I think we could do way better. But I’m pretty sure that Leanpub has a lot of tips and pointers for aspiring authors, how to sell their books in a more successful way.
Len: It’s a bit of a dark art, right? One of the things that we’ve noticed is that already having a community built around the subject that you’re writing about is a really important factor in that.
On that note, one thing I noticed is that on your landing page for your Leanpub book, you have a little note saying, Email me for a 50% off coupon if you’re in a country where the US exchange rate is really expensive. I was wondering, did people ask you for that, or is that something that you just wanted to do on your own?
Nick: Both. I got a lot of emails from people saying, “Hey man, I really want to read your book, but I live in”, I don’t know, Ukraine or in Poland or, not Poland, but Brazil. “And $39 is equal to what I earn in three days”, or “My lunch in a week.” I mean, because I don’t have the currency exchange rates on top of my head, I’m not a hedge fund banker.
So that made me think, I’ve got let’s say two or three people per week asking me, and I don’t have a problem [with this]. I don’t do this for money, I do this so people have happy software architectures, and go home happy. And of course, some dollars is nice. So I put this on the page.
Since I’d put this note on the page, it has increased. I get even more emails from people asking me, “Hey, please - I’m from Vietnam, I can’t afford this. This is like seven lunches. Can I get a coupon?”
So it kind of works, and it’s pretty cool actually, because I can totally see that people in the US don’t mind 39 bucks, or people in Australia, because, I mean, a six-pack of beer in Australia is $20, so - you know what I mean? But if the exchange rate is not that good, you have to help them. I mean, I don’t know about the plans of Leanpub, are there going to be different pricing tiers for different countries, or - ?
Peter: It’s interesting. We’ve kicked that idea around. We try to do things that let authors have as much control as possible, in deciding how their book is sold and presented. For example, we’re based in Canada, but we have to charge VAT for our EU customers. That’s tricky, because we have this minimum and suggested price, but then VAT gets tacked on.
So, if you have a nice happy like $9 or $19 as your book minimum price, then it turns into like $26.40 in the EU or in random EU countries with all their different prices.
So we were thinking, “Hey, should we allow authors to say, ‘My book is this price in the EU.’ Or, ‘Hey, my book is this price in like Western world, but cheaper say in developing countries.’” So it’s interesting for us to see this, because we though, “Hmm, maybe this should be a larger feature.”
The flip side is that one thing we don’t like is the idea that the world should be split up and only books should only be available in certain countries… We like the idea that you publish a book on Leanpub, and it’s available in the whole world. As opposed to lots of publishers who don’t even make their books available in lots of countries. We want to make sure our books are available everywhere. So we’re exploring the idea, is the short version.
Nick: I can totally see how hard it is, because you don’t want to make it a regional, localized… I mean, if you start doing like, “Where are you from?” “Ukraine.” “Okay your price is this and that”, I mean, this makes it a bit odd.
Peter: And people will get upset, because they’re on a VPN, say. So someone’s like, “Why did the price change?” And it’s like they were in an incognito window or a VPN, and they saw one price, because we thought they were in the US. And then they went to the checkout page, and we realized, “Oh you’re in Ukraine”. Or you’re in England, and so we stick on the VAT, because we have to charge it based on two or three criteria.
And then it’s like, we’re not changing the prices, this is just VAT being applied. But if people think that things are moving under their feet, they get really upset sometimes. Sometime in the next few weeks, we’re going to be shipping our new storefront, which will handle this a bit nicer, I think. It’ll avoid some of these problems around VAT when it gets shown. But yeah, basically people want to think that the price is fair, regardless of where they are…
Len: It’s really interesting for me as well, because one of the things that’s very important to us, is establishing a connection between an author and a reader, and choosing how much to pay is one of the cool ways that that starts to happen on Leanpub. So it made me happy when I saw your little note. Like, “Email me for a coupon for half off if it’s too expensive”. It was just great.
On that note, in your book, you suggest to people that they’re free to email you any time. And you said earlier in this interview that when you got interested in programming, partly it was feedback from people and getting things out there that helped encourage you. I was wondering if you’ve been emailed by readers asking you questions about the book, or asking you to add things, or even typos, or anything like that?
Nick: Oh yeah, in the early days, especially before I published the book. What was interesting was - and that’s one of the many reasons I love Leanpub - I could push out my book without being finished, and people would start reading it. I had more than 500 readers before the book got published, and that was great. It was a different thinking - now it’s published, now I have less feedback via email, I have more feedback on the official chat channel.
Before it was published, people would really email me. I had so many people telling me, “Hey, on this page you have this and that syntax error.” Or, “We don’t understand what you’re trying to say with your semi-English.” And also lots of people asking me, “Hey, so you said I can email you. So sorry for being blunt and emailing you, but do you think it’s a good idea to use Trailblazer like this and that in our current company?” Actually people used that a lot.
I don’t know if it’s related to the publishing or to the chat channel we have now. Now most people just join the chat channel, and it’s incredible to see the activity on this channel. It’s so good to see that your stuff is actually being discussed by people other than yourself. I think people still feel this urge to participate in discussions with the author and other people, but now they use the official channels.
But I still get lots of emails of people telling me, “Hey, by the way thanks for writing this book”. Which is awesome. I mean, I haven’t had that in 10 years. I’ve been doing open source for 10 years, and you get an email every year, someone says, “Hey thanks for that gem”. And now you get lots of people supporting you and telling you that they like the book, or they find chapter seven pretty great, but chapter three sucks. Which is still better than no feedback at all. It’s incredibly cool.
Peter: It’s funny, I found that with my first book, Flexible Rails. I found that basically the better and the longer the book got, the less feedback I got. The book ended up being over 500 pages, but I found I got the most feedback when it was a couple of hundred pages, and I had real inflection points. I had to decide - should I put REST in the book or not?” I mean this was back in 2006, right? So yeah, if people see that you’re making this effort, and a community actually forms around the book, then you can get really good engagement from readers. It’s really cool.
Len: I actually have just one more question. When you were using Leanpub, or when you’re still using Leanpub, is there any one thing that if you could have your dream feature for us to build, or dream problem to fix, what would that be?
Nick: So - the process was already pretty cool when I started. I think someone kept helping me when I had questions, because you have this helpful like chat-to-one-of-our-people dialogue things. So a lot of problems got sorted by that.
My dream feature would be positioning images in flow text. Because you have to preview, and “Ahh shit, the resolution is fuzzy”, or whatever, or blurry. And then I had to play a lot with width settings. So if you had some way to position that in a “what you see is what you get editor”, or something. I know it’s a terribly hard feature to ask for. But that was the only real problem I had, was position. It wasn’t even a problem. I would just use float left, width 30% or something, and it’d work. But it took me like an hour or something to figure that out when I had that problem the first time.
Other than that, I don’t know. I’m more than happy with how Leanpub works. I mean and also it’s bringing this whole publishing thing to a new level. I don’t know how many new authors Leanpub has created in the last five years. How old is Leanpub?
Peter: We just turned six. We launched in April 2010, so yeah, we’re in Grade One now.
Nick: Happy birthday.
Peter: Yeah probably we need a cake or something.
Len: So yeah, we’ll thanks very much. Is there anything you in particular wanted to talk about or say before we go?
Nick: How many people work for Leanpub? I’m just interested in how the company looks like.
Peter: 5. We’re bootstrapped.
Nick: 5. That is great.
Peter: We’re a little bootstrapped startup, we’re self-funded, and we’ve been at this for a while. We’re technical book authors, right? So we built Leanpub basically like, myself and Scott founded it, and then Len and other people joined. And we’re trying to create the best way in the world to write, publish and sell books.
We’ve been, to date, focused so much on the writing and publishing aspect, and the selling and community stuff is underdeveloped. But where we’re going is, we’re going to be doing a lot of work around that. So we’re really interested in how books like yours have evolved, and where we could try to improve things in terms of community, or in terms of mobile. Right now for example, we don’t even have an Android app. But that’ll change. Reading on iOS will get better. So yeah we’re really excited, we’ve seen like thousands of authors use Leanpub…
So we’re super happy about how it’s gone.
Nick: I know so many people who started writing on it. I think when it comes to community, I think it’s wiser to integrate existing stuff like GitHub is trying, because you still have this comment on this book or something…. No one, I mean you don’t even see that it’s kind of like there. So I think I had like three comments. So I think integrating existing communities is the way forward.
One feature that would be cool to have - testimonials sortable.
Peter: Oh, manually ordering them?
Peter: Okay, that’s a good feature. Yeah. Right now it’s kind of random.
Nick: Right now it’s ordered by created at.
Peter: Yeah, yeah, yeah. I think we didn’t do anything, and that’s what you get.
Nick: The feature itself is great, it’s so much more authentic, genuinely, when you really have photos of people like, “Hey we use it and it’s great”. Or “we read it”. So that’s a cool feature.
Nick: Keep it coming!
Len: Thanks very much. This is obviously motivation for us as well.
Just before I go, I wanted to say, I think you’re the 6th Australian I’ve interviewed for these podcasts.
Nick: But the first without an Australian accent.
Len: Well that’s right. (laughter) I just wanted to remark upon that. It’s really interesting that some of our more successful authors have had this cluster who are living in Australia or come from Australia.
Nick: It must be the environment, the blue sky and the sun. So we don’t want to go out, because it’s too dangerous - you get sunburned and all that kind of stuff. You have to do outdoor activities, we don’t like that. So we go home and write books.
Len: Great well thanks very much Nick, we really appreciate it, and thanks for being on the Leanpub Podcast, and for being a Leanpub author.
Nick: Thank you guys for making Leanpub, it’s a great thing to do. Everyone should be using Leanpub.
Nick: Thank you.