Leanpub Podcast Interview #18: Ryan Bigg
published Aug 05, 2015
Ryan Bigg is a Melbourne, Australia based software developer, writer and blogger. He is the author of the Leanpub book, Multitenancy with Rails, which helps you build a multi-tenanted forum application. Ryan’s next Leanpub book, Debugging Ruby, examines examples of common debugging pitfalls with Ruby code and Rails applications
This interview was recorded on June 5, 2015.
Ryan is a Melbourne, Australia based software developer, writer and blogger. He currently works as a Ruby and Go programmer for Marketplacer, a leading technology and business platform that makes it easier for people to create successful marketplaces. He was named a Ruby Hero in 2011 for his work on the Rails Guides and his contributions to the Ruby on Rails Community. Ryan is also well known on Stack Overflow for his answers to Ruby on Rails questions.
Ryan is the author of the Leanpub book, Multitenancy with Rails, which helps you build a multi-tenanted forum application. He is also the co-author of two Manning books, Rails 3 in Action and Rails 4 in Action. He’s currently working on a new Leanpub book, Debugging Ruby, examining examples of common debugging pitfalls with Ruby code and Rails applications, using cases he’s seen in his day to day work.
In this interview, we’re going to talk about Ryan’s professional interests, his books, his experiences using Leanpub, and ways we can improve Leanpub for him and other authors.
So, thank you Ryan for being on the Lean Publishing Podcast.
Ryan Bigg: No worries, it’s good to be here.
E: Thanks. I usually like to start these interviews by asking people for their origin story. Could you tell me a little bit about how you first became interested in software development and how you became a developer?
B: Yeah sure. I’ve always been interested in computers as far back as I can remember. The first computer that I accurately remember I think was a Commodore 64, we played Paperboy on it. You had to insert the cartridge and type “run” or “load,” whatever it was, and then play the game that way. So I’ve always been around computers. And then dad was doing this kind of invoicing system for his work as a photocopier technician, building it in a language called Clipper. And he found this function of Clipper that listed music. So he came to me with this manual, this big binded manual thing, and said, “Look, this lets you play music.” And he showed me if you type “play 70,” it would pay a note. And then you type ”play 75,” and it would play a higher note. And so we just made music. I was into music at the time and made music using Clipper, and that was my first experience with programming. And then I did HTML and CSS probably when I was 9 and 10, and I’ve been doing web really ever since, and I enjoy it. It’s interesting, you’re always learning new things, there’s always new technologies. Like you’ve got Go coming to the fore now, Elixir. Ruby was the cool kid back before, and now it’s kind of getting to the enterprise-y, “Yeah, everyone’s done Ruby,” kind of level. So yeah, that’s my origin story in a nutshell.
E: And how did you come to be so interested in Ruby on Rails?
B: Between doing HTML and CSS, I went and did a Network Engineering degree. And while I was doing that, to pay for all my little extra purchases around the outside of that - like my parents wouldn’t give me pocket money, I had to work for my living - I was working at a supermarket which paid close to minimum wage, which isn’t so bad in Australia admittedly. But I was doing PHP work on the side of that as well. And I was doing all this contracting stuff, getting paid a lot better than what I was getting paid at the supermarket. So I wound back my supermarket hours and started doing more PHP contracting. And then a friend of mine said to me, “Hey, you should check out this Ruby on Rails framework.” And I watched the initial video with DHH, where it goes, “Whoops” a lot, “and look at all the things I’m not doing.”
E: Yeah I’ve seen that too.
B: Oh, it was just fascinating, because I loved it. And I was like, “This is so much better than PHP.” There’s little containers that you can put your things in, whereas PHP was - you’re just going to chuck all the database logic in the file, all your view logic in the file, all your controller logic in the one file. And Rails gives you these little boxes. And there’s a video by Gregg Pollack and - what’ his mate’s name? Jason something. And they did it, they did it exactly like they had little jars of things. And they’re like, “These are your controllers, and these are your models and these are your views.” That just resonated so strongly with me. Over the next couple of months, I stopped being a PHP programmer and became a Ruby on Rails programmer.
E: That’s great. And you’ve spoken at a number of conferences as well?
B: Yeah, I’ve been around the world, speaking at probably too many conferences. I love the Ruby on Ales conference, which just happened in March this year, and the 4 years before that. It’s a fantastic little conference. And I’ve spoken at Spree Conf, Red Dot Ruby Conference. Trying to think all the conferences. A few, yeah.
E: That’s great. You write on your blog at ryanbigg.com about how much you value the community and how good people are generally that you encounter within it.
B: And so we have those little events, and that’s the kind of community that I really enjoy - going out to these events and spending time with people who are doing very similar work to what I’m doing, and seeing what they’re doing. And seeing how they’re doing it, and learning from that.
E: For people who aren’t maybe familiar with it, what’s the tech community like in Melbourne where you are?
E: So there’s a vibrant startup ecosystem happening there?
B: Yeah, yeah. There’s a huge startup ecosystem here. We’ve got AngelCube, which is run by Nathan Semp– I can never say his name right, let’s just call him Nathan S [it’s Nathan Sampimon - Ed.]. And he runs a startup place, I guess you could call it an accelerator. They all have a bunch of startups in a place called Inspire9, it’s a nice office space that I worked out of, two years ago now.
E: I wanted to ask, you have a great post called “Congratulations” where you you tell a story that seems like there might be some biographical elements to it, about how you got into test driven development and behavior driven development. I was just wondering if you could maybe tell us a little story about how that became so important to you.
B: Oh it’s based on a true story. In 2008, I was working for a company and we developed this learning platform. Before learning platforms were cool for people really, that was the original. You know the classroom students, that everyone builds eventually? Those kinds of applications. We were building one of those, and I changed this part of the application, which had a count of - I think it was maths classes. And the count was wrong, so I changed it. And then the client called my boss, and my boss said, “Hey you changed the count, why did you change the count?” I said it was wrong. And he’s like, “No, no, no. It was right, that’s the way the client wanted it.” And without the tests, we had no way of proving that. We had no way for certain that change was exactly correct or wrong or whatever. And there was much more serious issues past that. One day I removed the Hpricot Gem, which is a precursor to nokogiri. And that took down production when somebody else deployed production the next day, because there were no tests asserting that our code was actually working. There was parts of the code depending on Hpricot that I didn’t realize, and we had an angry phone call from the client. I actually ended up getting fired from that job because I wanted to do testing, and I was arguing for testing. And the boss was like, “No, we don’t have time for testing.” And then when I would break things, I would say, “Well if these were tested then things wouldn’t be breaking as often.”
E: Right. And I remember the second part of the story was that you went to another place.
E: And there you successfully convinced them to use testing, or they already were?
B: They were already using testing. That’s when I was working for Dr Nic, and that’s when I saw the light. Dr Nic, the famous Rubyist from years and years ago - one of the original famous Rubyists. I got to work under him, he’s fantastic. I tell the story all the time. I’d take a feature to him and he’d say, “Does it work?” And I’d say, “Yeah it does, let me show you.” And I’d click “login,” fill in the username, fill in the password, ns click “submit.” And he’d be like, “No, no, no, no,” show me the test. Or he’d ask me to run him through the feature again. He’d pretend like he wasn’t watching or wasn’t paying attention. And so he kind of hammered into me that, “If you’re not testing, you’re doing it wrong.” So I’m just testing all the time now, because I guess it’s kind of like a good form of post-traumatic stress.
B: Being hassled by him and heckled by him all the time has actually improved my craft. So, I guess it’s a net positive.
E: Can you explain, what is behavior driven development for someone who might not be familiar with it?
B: So behavior driven development, my understanding of it is that you want to test that part of your application is working in a specific way. Let’s use the login example again. You want a link that says, “login.” Then you want a form that has a username or an email field and a password field and then a “submit” button at the bottom. You want to make sure that when a person enters a valid username and valid password and hits the “submit” button, they can log in. So that’s the behavior that you’re testing. Before you do any work, you write the test, then you make the test pass, you add the login link, you build the form. And you build all the other associated code around that, and then it passes. And that way if that feature breaks in any way, like if the login link goes missing or the field gets changed, or the underlying authentication logic changes, you have a test that can break if that changes. Also, if you’re building another feature and a bug pops up, you can write another test with that existing framework, and that existing framework provides you that way of writing regression testing. And regression testing I think is the big win of behavior driven development and test driven development, absolutely.
E: I imagine there must be a category of developers who also, in addition to clients and bosses, don’t want to do testing?
B: Yeah there are, there are. And I do try and convert them when I come across them.
E: How would you characterize resistance to testing from the developer’s side?
B: If you asked me this question I think three, four years ago, I would have said, “They’re stupid.” And now I’m just like, “Mmm well, there are merits to it.” There are merits to not testing your code. You can develop the code much quicker, and you can build the prototype. But then I wouldn’t go using that prototype without tests around it. So I’d chuck out the prototype, rebuild it with tests, and assert that it’s actually working correctly. And I try and tell people this, and some of them listen. That’s why I built a book around test and development, I think that’s the only proper way to build an application, is to write the tests. All my books that build applications, so Rails 3, Rails 4 in Action, Multitenancy with Rails - build tests first, and then they build the functionality, because I think that’s the right way of doing this.
E: Speaking of your In Action books, they were published with a traditional publisher. And you have a blog post where you talk about your breakup with them, and how you have great respect for the people there, but it was their tools and workflow that drove you away. I was wondering if you could explain a little bit about what that experience was like, and how important the toolchain must have been for you to make that kind of a decision?
B: They’re bloody muppets. I like the people there. They’re well intentioned, they’re technologically illiterate. That’s how to put it lightly. The tool chain was writing in Docbook, which is XML. And so I was handcrafting XML. So to start a paragraph, or to start a book, you’d have a book tag. And then inside that, you’d have a chapter tag, and inside that, you’d have a section tag. Inside the section tag, you’d have a paragraph tag or you’d have a listing block tag, which contains a - there’s like 3 tags you need for a titlized code example. And writing that was exceptionally painful. But then you had to upload it to their SVN server, which might have had conflicts. So you’d need to pull down the SVN server, which everyone else uses. So you’re pulling down everyone else’s changes at the same time. Then you need to click, you need to login to the Manning website, find your book in the list of all the books they’ve ever published, click on the little book icon, click on the chapter, scroll down to the bottom of lists of revisions that have ever been processed for that chapter. Click on the little radio button at the bottom, and then click on “update.” And that would update it for the editor.
So I got upset with that process I think about two months in, and I built my own review system, which I called “Twist,” because every good book has a twist. And so I built Twist, and I built it overnight. I started about 2 pm that day, and at about 11pm I think it was, I was furiously coding. I was actually angry for the first couple of hours, and then I was just like, “This needs to get done, and wouldn’t it be cool if it did this? And wouldn’t it be cool if it did that?” And I went downstairs at about 11pm and thought, “That’s weird, my housemate’s not here.” He was always forever on the couch, or forever on his dining room table. I’m like, “What’s going on? Like he’s usually here, isn’t it dinner time?” And then I finally see the actual time, I didn’t realize it was 11 pm at that time.
E: Oh wow.
B: I look at the microwave and go, “Holy crap, I’ve been coding for 9 hours.”
B: And I’ve just been in my own little hole for nine hours, and I’ve built this thing and it works. And now I’m bloody hungry. I’m going to have some food and go to bed. So I built that, and people were very happy with it. And that tool is what helped me write Rails 3 in Action. Not Manning’s review tool chain at all. With Twist, I was able to add my own reviewers. They were able to leave Markdown-based comments, and it was just so beautiful to work with that system. I’d never write a book in Docbook ever again because of it.
E: I imagine the reviewers that you brought into Twist responded positively to it as well, probably in comparison to the other - I mean, review systems are kind of primitive, if they exist at all.
B: Yes that’s right. These other reviewers never got to see Manning’s system. Manning wouldn’t let them in, because it gives them access to all the other books. Only authors who are contractually obliged to not share the other books, are allowed access to that system.
E: I’m not sure if there’s necessarily an answer to this question, but why do you think that conventional publishers are so resistant to improving the way that authors write books, and then work with their publishers to produce books? Because we hear this at Leanpub. I’ve had personal experience with it. Leanpub’s co-founders have had personal experience with it. What’s your opinion about why people who ought to be in the business of making books aren’t motivated to make the process of making books better?
B: It’s worked this way forever, and retraining the people to use new systems is going to take too much effort and too much time. Developing the new systems can come with their own pitfalls. There’s always the thing that the grass is greener on the other side. And if you develop a new system, it’s going to be better than the old system. It’s not going to have the problems that the old system - sure that might be true - you’ll learn the lessons from the old system, and you apply them to the new system. The new system’s going to come with problems though. Same as if you rewrite an application, you’re going to learn from the old application. And the new application’s going to come with its own set of issues. I think that they’re resistant to change because it’s a high risk scenario. It involves them having to cut over from the old system to the new system, and they don’t want to invest the time in that at all, because the current system is working okay - they are pushing out books. But they are not pushing out books as quick as they can, and they’re not making the process as painless as they can - and that is mainly what I have the issue with, is that the tool chain gets in the way, makes the authors unhappy, makes them not want to write books. Steve Klabnik, my co-author actually got burnt out on Manning’s tool chain, and that’s why he didn’t finish Rails 4 in Action. And Rebecca Skinner and I had to finish Rails 4 in Action, because Steve couldn’t because of the tool chain.
E: Wow, that’s incredible. I mean, that’s a much less cynical explanation than some people give for why many different companies. One of the more cynical explanations is there’s somebody who sees this new tool chain, and sees that it doesn’t include the type of work that they’ve been doing, maybe for their entire career. That it’s not necessary anymore. And that in addition to the obvious motivation someone might have to block a new technology because it might take their job away - and that’s something to be very sympathetic to - there’s also the aspect of seeing the activity that you’ve based your career on is just now longer necessary, and there’s just something kind of heartbreaking about that.
B: There’s all this typesetting work that Manning does as well. “Rails 4 in Action,” in my opinion, should have been published already. They’re typesetting it so it can be printed. And the issue with the printed book is it’s going to run out very quickly. I think that printed technology books are dead and there should be no need for them anymore. Manning disagrees.
E: That’s interesting. My next question was going to be, how do you see the computer book market evolving in the next 10 years? In addition to what you’ve said about paper technology books kind of going away, for all sorts of reasons, including they don’t match the timelines of technology development, do you see authors making a decision like you did to essentially go independent?
B: Yeah I do, definitely. The big publishers take too much of a cut for the work that they do, in my opinion. And holding back my cynicism on Manning, and I feel it leaking through at the moment, I’m not sure how much I can say on public record, but I was not pleased with them the last time we talked with them.
E: Okay, okay. I mean it’s up to you - that’s why I’d like to talk about the market more generally.
B: Yeah, the market more generally - I think that people are not going to go to the big publishers if they have sense. So I think Leanpub’s going to - Leanpub is amazing for publishing independently, away from publishers. The cut you get is much more reflective of the work you put in. An author, I agree, puts 90% of the work in, and the publisher does 10% of the work - and that’s what the cut should be financially, 90% and 10% plus 50 cents and whatever. I think that’s Leanpub’s cut?
E: Yeah, the author royalty is 90% minus 50 cents.
B: That’s it.
E: And then we’ve got fees and stuff like that, but yeah that’s the royalty rate. We do feel it at least reflects the amount of work that an author puts in, especially if they’re self-publishing and managing all the other processes as well. It’s interesting, I was talking to someone the other day who was saying - he’s an academic, in the sciences, and he went away from academic publishing partly because his academic publisher wouldn’t even do the formatting anymore.
E: Yeah, yeah. He was being asked to do the formatting for his own book. I remember I was at this thing called BEA, Book Expo America, a couple of years ago. It’s the big publishing industry jamboree in New York City every year, and Guy Kawasaki was giving a talk. It was this panel on self-publishing that everyone was a little bit trepidatious to go into - not him obviously, and not people who are into self-publishing, but the regular attendees. And he said, “Look, the last time I spoke with a publisher about publishing my book, they said, ‘So how are you going to leverage your Twitter following to maximize sales?’” And he’s like, “Well what, what do you mean? How are you going to market my book should be the question. Not how am I going to market my book.” And then he went off and wrote a book called, “APE,” about self-publishing. So I’m really glad to hear you say that, because I’m also starting to hear that noise coming more - or signal, sorry I should say, coming more from people who aren’t even technical authors, but people who are in sort conventional trade publication kind of stuff, like fiction and biography and things like that. I’m starting to hear that yeah, people are getting more and more frustrated because publishers are reacting to the changes that have been happening in the world - not necessarily in the most productive ways.
B: That’s right.
E: And it’s in that context that I’m just so surprised that every time, even though I know it’s coming, I’m still surprised that a publisher would damage its authors, like the process you’re describing. And even lose them because they just won’t change their system. I mean, there’s just something so deep…
B: Yeah it felt like Manning didn’t want to keep me around. Even when I was writing “Rails 3 in Action.” It’s more that they wanted to get a book published. And that they didn’t want future - I don’t know how to put it in words properly. It’s like they just wanted the book published, and that was it. But then the contract beholds me to - If I want to write future books following a similar topic, like if I wanted to write a new, “Introduction to Rails” book, for 3 years after “Rails 4 in Action” is finally published…. So let’s say it’s published next month. I can’t publish a new Rails introduction book until July 2018. So in a way, they want me to write the book and publish a book. But then they don’t want me to write another book. They’re not doing anything to keep me there. Because it’s in their business’s best interest to keep me on board and to keep me publishing books through their platform - in my opinion. Just like it’s in Leanpub’s best interest to not piss off their authors, right?
B: Every publishing platform’s business is to make sure they can keep producing - the authors keep producing books, and bringing in the dosh. If you’re doing things to make the authors unhappy and to push them away from your platform, doesn’t that kind of counteract the whole point of the business existing in the first place? Which is to publish books.
E: Yeah you’d think. And we hear this time and time again from people who are like - they don’t go into it vain. They go into it feeling honored or flattered that a publishing company is going to take them on. But by the end of it they feel often like a used product.
E: Or a tool themselves, rather than something that’s respected. And anything you make, that you probably care about in your life - there’s something about a book. It’s a long thing that you care about, probably something that you feel you’re very good at and that matters to you. And then probably something that’s going to fit into your life in a certain way, you’ve been telling everybody that you’re working on this book, and you want to fulfill that claim. Afterwards you can put it in your CV, and it can get you speaking engagements and things like that. To the author, it’s just such an extremely important activity. And then to be - I just think people are surprised that suddenly they’re being treated negatively in that context. Like, “Why would this happen?”
B: It’s like, “I’m trying to help you, and you’re not listening to my advice.”
B: “My advice is to build a better publishing tool, and you’re not doing it.” But it is a huge honor. I was so excited, I remember going over to the supermarket, and immediately after seeing the Manning email, and almost skipping there out of excitement, I was just so happy and radiant. And then it went downhill from there and just - and now I really don’t like traditional publishers. It sounds counter-intuitive to their business entirely.
E: Hopefully moving onto happier things, how did you find out about Leanpub, and why did you choose it as your publishing platform?
B: I can’t remember exactly how I found out about it. This always happens with things. I find out about things, and I’m like, “This is a really good tool.” And then I don’t remember the origin story. I believe somebody - I was raging about, “Rails 3 in Action” at the time. And somebody recommended Leanpub. They’re like, “Why don’t you publish a new book on Rails through Leanpub?” And I was like, “No, I can’t do that because I’m beholden to Manning because of this contract.” And then I came up with the idea of “Multitenancy with Rails,” and I was like, “Wait, I remember Leanpub, I’ll go to them and see what I can do.” I was like, “You guys write with Markdown,” and I love Markdown, Markdown is fantastic format for books. It’s not the best format, but we’ll get to that in a moment. It’s good enough for what it does, and the royalty split was nice, the site was great - much better than Manning’s site. The checkout process - if you compare Leanpub’s checkout process and Manning’s checkout process– Oh my goodness, there is like 15 years of software development difference between the two. I’m not kidding, that’s quite a long time in web dev, in web dev land. And it’s just nice. It’s like driving an old 1986 bullshit car and then I’m in this brand new Lamborghini off the lot. I’ve never driven a Lamborghini, and I don’t hope to, because I reckon I’d wreck it. But it’s just - it’s so nice, it’s - it was like being freed from prison.
E: I assume you used the Dropbox workflow?
B: That’s right, yes I did.
E: It’s where you write in your own favorite text editor on your computer, and then sync to Dropbox, and then click “preview,” and “publish” on Leanpub.
B: That’s right, yeah, yeah. So I write all my things in Sublime. And I’ve tried a lot as an editor. It’s brilliant. Enough vim bindings that I can use. And yeah, it’s neat. And then yeah, Dropbox and publish on Leanpub. And it’s - if I want to publish today, I can publish today. With Manning I can’t do that.
B: And I have to go, “Look, I’ve got these updates, they’re in SVN.” And they’ll go, “Okay we’ll typeset them and we’ll publish them.” And like I said, “Rails 4 in Action,” has been content complete - I didn’t say that it’s been content complete, I said it could have been published in April, but it’s been content complete since April. And so it could’ve been published in April. It’s now June, and it hasn’t been published. Because they’ve been typesetting and indexing and all the other stuff that no one really cares about in a tech book.
E: Yeah, okay. And you wanted to talk about Markdown?
E: Indicating it’s not necessarily the best way in your opinion to write a book?
B: Yeah, my wife’s a lawyer, and she has a great saying that, “three lawyers, four opinions.” And Markdown processing is exactly the same way. You have - Markdown is, you’ve got double, like double pound sign and a heading. And the rest of the content - it can be presented in one way if you use this Markdown parser or another way if you use this other Markdown parser. Or in a completely alien way if you use this other Markdown parser. There’s no really - what do they call it, schema, syntax, reference guide. And I know that Jeff Attwood and his crew were trying to work on one. I have no idea how far that’s gotten. But there is a much better format out there that I found called AsciiDoc, and that is like - it’s like if Markdown was designed not by one guy. It’s like - Markdown was designed using the PHP design technique of - one guy released this library and then everyone used it. AsciiDoc was built with this guy - it was like, “Okay, I’m going to take the good bits from Markdown, and I’m going to put my own stuff on there, and we’re going to work collaboratively, and we’re going to build this format called AsciiDoc. And it presents tables well, does images, and presents these beautiful looking previews with this library called Asciidoctor, which is what I’ve been using for my, “Deep Dive Rails” book, which I’m also publishing through Leanpub. And it’s nicer in ways to work with Markdown and not as nice to work with in other ways with Markdown. It’s kind of a tradeoff. Overall, it’s fantastic to work with.
E: Okay, thanks very much for that and for letting us know. Actually Peter is actually working on a new syntax called Markua.
B: Oh yes.
E: Which is meant to solve some of the limitations of Markdown when it comes to writing books. So it’s basically supposed to be a superset of Markdown, but specifically for writing books.
E: So yeah, hopefully we’ll get your opinion about that at some point and then see what you think. Hopefully it solves some of those problems. But obviously we’re very respectful of the fact that people have different preferences. And we want to accommodate as many reasonable preferences, because writing is such a personal, time consuming thing. That’s why, so for example the first - well one of the most important workflows we have is working in whatever editor you like in Dropbox on your computer. We do have an online editor and we do have a couple of other workflows. But that’s the most important one for us, that people are as happy as they can be. And we want, it’s just like anything else - like, when a carpenter is hammering away with his hammer, he shouldn’t be thinking about the hammer. The hammer should just be an extension of what he’s trying to do - same thing with writing tools and tool chains. On that note, I noticed that in “Multitenancy with Rails,” you include your personal email address in a section at the beginning for feedback, and you invite people into Twist as well if they want to be a part of it. Is that something that you would like - would you like Leanpub to actually facilitate that process?
B: Yeah, I’d love Leanpub to have a review system, that’d be great.
B: PragProg has this - I think it was designed back in 2007 - they have an errata page. It looks very old school, and it’s–
E: I’ve seen it.
B: Yeah, it’s not, it’s not the prettiest thing to look at. What I’d like to see is like, “This thing is wrong with the book.” And you click in, you’re like, “Oh what does this thing mean?” So you click on it, and you’re like - okay. this is the section that it’s commented in. So this is like a paragraph or a code block. And underneath it are all the comments related to it. So it’s like, say that the author’s written a very complex piece of code, and then other people underneath it have commented and said, “No, no, you don’t need to write it like that, you can write it like this or like this.” And then the author can see it like, “Okay, this is the - good way to write it.” And you can have a discussion around how to, how to improve that one little section. And that’s why I built Twist, is that you can have discussions around that little section.
E: Oh okay, so it’s discussions rather than sort of logging errors or something like that?
B: It can be both.
E: Yeah okay, okay.
B: Yeah so, I have these run-on sentences all the time in the book where I have too many commas. And people are like, “Well wouldn’t it sound better if it was written like this?” And then I come back and I say, “Well, this is how I say it out loud.” And I put in the commas where I paused if say - If I pause out loud. And they’re liek, “No, no, no, that’s not good.” And then we talk back and forth and we come up with a proper way of saying whatever it was we were trying to say in the book.
E: Okay, okay.
B: It’s nice that way.
E: What would you think about if we added reviews? Because we currently actually don’t have reviews.
B: Reviews in general, like five star reviews?
E: Well both stars and written reviews, like Amazon-style. If people could actually go - if users could go onto Leanpub and write reviews of books, is that something that you would - if we made it opt-in, is that something you think you might opt into?
B: Yeah, yeah. I’d definitely use that, yeah. Because I think that’s a good marketing technique. And we’ve been talking about this - Marketplace are actually - been talking about having product reviews. And that is, according to my sources, that is how to get people to buy your products. If a product has good reviews from other people - say it has four and a half stars, five star reviews from 30, 50 people, people are like, “Wow this must be good.” Like our microphones, right? We bought our microphones because they had awesome reviews. If it was just like, “Buy this Yeti microphone, it’s $200,” Who would buy that? And then they’re like, “Wow, it’s 5 stars. It’s also all these great features and we love it. It’s crystal clear quality and all that.” The reviews on Leanpub would be a good feature, and I would definitely use it.
E: Okay, okay. Is there anything else about Leanpub that you think we could improve? That’s what we’re here for.
B: Not at this point in time, I’m very happy with it. And all of the new design too.
E: Oh well great, thanks very much, we’re really happy to hear that. That was a long time coming, and we’re very happy that it’s finally out. My last question is that - I see “Debugging Ruby,” your next book, is 40% complete. Do you have a timeline for when it’s going to be finished, or does that matter to you?
B: “Debugging Ruby” is a book that I’m writing really whenever I feel like, or whenever I come across an interesting debugging thing in Ruby.
E: Oh I see, okay.
B: I had a debugging session probably a year and a half ago with a friend of mine, where he was entering a valid username, and a valid password into his login form, and Devise was saying it was invalid. And he would go into the console and he would load up the user. He did like, user find, user authenticate, password’s good. So what was going wrong? Well, if you want to find out, you read, “Debugging Ruby,” that little chapter, “The Devise bug.” And it walks you through exactly what was going wrong in that. And any kind of little interesting debugging stuff and debugging tips. And yeah, so when I think of something to put in the book, I just put it in the book.
E: That’s interesting, we actually had - I was doing a little bit of internationalization yesterday. And we had a really funny thing happen where we got a Norwegian translation so an author can have a Norwegian landing page if they want, if they’re writing their book in Norwegian. And you localize in YAML, right? And the 2 letter code for Norwegian is NO, colon. And so everything was blowing up, and it’s because it was reading it as a Boolean value, rather than a string.
E: Like it was NO. My first instinct when it was breaking was that that’s probably the problem. I’m not a developer, I just do like little things here and there. And one of my colleagues was like, “No it can’t be that, it can’t be that dumb.”
B: Yep, NO and YES are reserved things in YAML and they mean true and false.
E: Yeah, yeah.
B: And nobody knows that, except people who have been bitten by the bug.
B: Maybe I can chuck that in the book?
E: If you wanted to. Anyways, I just wanted to say thank you very much for participating in the Lean Publishing Podcast, we really appreciate it. And thanks for being a Leanpub author.
B: No worries, happy to talk to you today.
B: Thanks Len.
This interview has been edited for conciseness and clarity.
– Posted by Len Epp