An interview with Josh Long
  • June 19th, 2019

Josh Long, Author of Reactive Spring

1 H 7 MIN
In this Episode

Josh Long is the author of the Leanpub book Reactive Spring. In this interview, Leanpub co-founder Len Epp talks with Josh( about his background, his thoughts on the Silicon Valley tech sector and homelessness in San Francisco, how the experience of being an American abroad has changed in some ways in recent years, Spring, his previous books and his work creating videos, his latest book, and at the end, they talk a little bit about his experience as a conventionally-published and as a self-published author.

This interview was recorded on June 3, 2019.

The full audio for the interview is here: You can subscribe to the Frontmatter podcast in iTunes here or add the podcast URL directly here:

This interview has been edited for conciseness and clarity.


Reactive Spring by Josh Long

Len: Hi, I'm Len Epp from Leanpub, and in this episode of the Frontmatter Podcast, I'll be interviewing Josh Long.

Based in San Francisco, Josh is a developer advocate for the Spring framework at Pivotal.

A popular conference speaker and creator of some pretty great screencasts, he is also the author or co-author of over six books, including the O'Reilly book, Cloud Native Java: Designing Resilient Systems with Spring Boot.

You can learn more about Josh on his website,, subscribe to his podcast, A Bootiful Podcast on Apple Podcasts and anywhere else you find podcasts, and you can follow him on Twitter @starbuxman.

Josh is the author of the Leanpub book Reactive Spring. In the book, Josh introduces readers to the implementation of reactive programming in the Spring ecosystem.

In this interview, we're going to talk about Josh's background and career, professional interests, Spring and reactive programming, and his book, and at the end, we'll talk a little bit about his experience as an author.

So thank you Josh for being on the Leanpub Frontmatter Podcast.

Josh: Thank you so much for having me, I appreciate it.

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 became interested in technology?

Josh: Sure. I am from Los Angeles, California - a sprawling city in the southern part of California. And there I was lucky enough to have - I'm 35, so I'm of the generation where computers were starting to proliferate in the schools and so on - in public schools, you didn't have to be blessed to get access to a computer.

So I got to play with them a lot, and I was pretty interested in graphics and, how do you automate some of the things that we did in the analogue world? That eventually led me to programming.

Long story, but circumlocutiously - I ended up programming COM on Windows, to automate certain tasks that I was doing. From there, it was a long, dizzying array of other languages. I worked in a number of different startups and found one technology that was particularly useful and I got pretty good at it. Not great at it, mind you - but okay, right?

And then here we are. Somebody hired me, the company Pivotal - the Spring team, they hired me, because of my familiarity with that technology.

Len: One question that comes up often on this podcast, because so many people that we interview are software engineers and in careers like that, is - did you study computer science formally at university or college?

Josh: No, no. I've been doing it since I was young, early teens, right? I've just been very lucky. I mean, I did start down a path, but I never finished studying it formally, because I didn't need to. I was able to get a job, I was able to be productive in industry. That's not to say that that should be all people's path. Quite the contrary. I think you should never discard the value of a good education.

That said, I was lucky - and there's that word, "lucky," that I didn't need it to be able to land on my feet.

Len: You mean you were lucky that you got your first job, even though you didn't have a degree, or -?

Josh: No, I mean, more to the point, I was lucky that I was able to acquire the skills that would make me qualified for the first job that I got. I wouldn't have been able to acquire those, had a string of things happened.

First of all, computers had to be cheap enough that my dad could bring one into the house for his small home business. And I could tinker with that. I wouldn't have been able to get good at computers if these public school systems didn't have one or two of them sitting in classrooms in Los Angeles in the early 90s. In some classrooms - I can't speak to all of them - but the ones I was lucky enough to be in.

I wouldn't have had the opportunity had anybody discouraged me, or actively gone out of their way to make it so that I didn't get a chance to use that computer. Because I was pretty - I was easily cowed, I wouldn't have wanted to make people unhappy or whatever.

I remember my dad had this really nice laser printer he used for invoices and these kinds of things. It was a laser printer, and I remember trying to print the slides or the notes for a presentation I was going to do on a screen projector in class. You used to have plastic slides that you'd put on top of a screen projector. Well of course, I'm an idiot - so I put this plastic slide -

Len: Oh no.

Josh: Into a laser printer, and I try and print. And you know what? The first half of that page came out just fine. But the rest of it melted inside the printer, so like - yeah, it wasn't great. And again, my dad could've gone either way. He could've been very angry with me and been completely upset with me, which would've been completely reasonable. Especially given how expensive a laser printer would've cost at the time. But he didn't.

Len: I'm a little bit older than you, but I still have memories of the first computer that came into the house, and that being a special event. But I never personally got interested in programming. Do you remember what it was that got you interested in that? For a lot of people, for example, it's making a game, or they see a parent doing some coding, and then they sort of get hooked.

Josh: So, isn't this weird? My mum has, or had - rest in peace - she had a dear friend name Bobby Lee, and in the late 80s, she was the technical support person for our family. She'd come over, and she had a family and kids of her own - but she'd come over and she'd help my dad with his computer. Her work was that she spent time writing documentation for technical software. She was a documentation writer for software. And she was using something called Ventura. It's now owned by Corel, but it used to be - if you wanted to do long document publication, then you did it on specialised software.

So Adobe used to be called Aldus FrameMaker, or maybe it was Frame? I think it was FrameMaker, and then it eventually became Aldus and Adobe FrameMaker. And there's another one called, Ventura, and that's owned by Corel now. She used that quite a bit.

I was fascinated by this idea that there was a discrepancy between the way you - like, I learned to use Borland WordPerfect. And then that became Novell - and I was fascinated by the idea that there's this discrepancy between the thing you would use to write a document, a book, a page, a study - whatever, versus the way you would actually design a long document like an encyclopedia or catalogue, or whatever.

That sent me down this rabbit trail, where I was just trying to soak up anything I caould learn about design software. Eventually, I discovered you could actually automate this stuff. So if you wanted to take these tools that were purpose built for long document publication - if you wanted to really make them do interesting things, you'd have to connect them to it anyways.

So I ended up going into this sort of C++ and Basic world with Visual Studio 6. That was fun, but by that point I had learned Python and I had learned Java, and Java, I couldn't figure out how to make that work with COM. But there's a language called Python, and you could use that to talk to COM. I just remember being very fascinated with that possibility, in the mid-to-end of the 90s. I had done other stuff before - and of course at the time, contemporaneous with all that, there's the web and JavaScript and PHP - I did CGI and C Code. I did Bash. Trying to set up servers, these kinds of things. So it all just kind of fell on me by accident, and then away we went.

Len: Thanks a lot for sharing that. It's so interesting to hear the different ways people get into programming. It's often a mixture of timing and home life, and even geography often. I've interviewed people where being very isolated is what led them to computing.

So, one of the more fun features of this podcast, is that I get to interview people from all around the world. And one of the things I'd like to ask them about - or two of the things I like to ask them about, are, what's the tech sector like where you are? And the other one is - often the person might have local knowledge of something that the rest of us have read about in headlines, that I can ask about. And so I'm not going to ask you about what the tech sector's like in San Francisco, because I think we all--

Josh: What tech sector?

Len: Well I mean, normally when I'm asking this question it's for people and places where there's not really all that much going on. So it's a -

Josh: There is nothing going on here, my friend. Nothing.

Len: Yeah, that's what I've heard, it's a wasteland.

Josh: Nothing going on. It is a wasteland.

Len: But one thing that people probably have read about is homelessness in San Francisco.

Josh: Yeah.

Len: I was wondering if you would be willing to talk a little bit about that yourself? Is this is something that you encounter day to day, and what do you think makes it such a hard problem to address?

Josh: Well, good question. I live in San Francisco. And San Francisco, strictly speaking, is far away from Silicon Valley. But because of the soaring prices of that area there, we see a lot of people moving into San Francisco, that would've otherwise just been happy to live in Silicon Valley. So it's weird to think of San Francisco as being the cheap place to live, but it is. Because there is this sort of burgeoning tech sector-ish -

By the way, I'm not really all that impressed with the Silicon Valley tech sector, just between you and me and your listeners. I have always wondered what we could do if we put our minds to things. But, and I speak to technology users all around the world every year, 600,000 plus plane miles a year - talking to people in six out of the seven continents. People are amazing everywhere, and I reject this idea that there's anything intrinsically interesting about Silicon Valley. The only thing you'll find that's unique to Silicon Valley, is that they think they're the only ones doing this stuff. Which is preposterous.

But because there is this sort of aura of excellence or whatever, people think they're excellent here. There's this influx of people that go to Silicon Valley for jobs. And of course, it's very expensive in the cities that surround Silicon Valley. Because remember, these are all suburbia, cities that that sprouted a long time ago. And they weren't meant to be like full-on cities, they were just little bed and breakfast communities. And eventually, these giant companies started forming out of garages in the region. And so they set up their campuses, they set up their little headquarters nearby.

That's still very true. These giant campuses - we've had the Googles, the Facebooks, Apple - all these companies are in what are otherwise very boring areas of California. There's nothing - they're just flat, there's no skyscrapers, there's nothing there. It's nice blue skies, but these cities don't want to be major burgeoning metropolises. They don't want skyscrapers, they don't want an airport - all that kind of stuff.

So as a result, the prices of things down there - since there's a lot less supply and an increasingly greater amount of demand - the prices of homes in Silicon Valley have skyrocketed. And that has pushed people to the fringes. And when I say the fringes, I mean San Francisco, which is a little weird to think about. Even some of the tech companies have set up satellite offices here in San Francisco, just to accommodate people who would rather live here, where it’s cheaper, or maybe they just prefer the locale, or whatever. And so we now have a growing population of people here in San Francisco.

There's also a good many people who are buying properties as speculative investment instruments here in San Francisco. And so there's a large number of people who are buying from overseas. They're trying to move money out of the auspices of their respective governments. So they use real estate here in the Bay Area as an instrument, so to speak.

Both of these things are contributing to a situation where we've got sort of artificial inflation in real estate here. I think San Francisco's a nice place, but it's not that nice. There's something else pushing the price up beyond its intrinsic value.

The results of this has been, unfortunately, that people that could otherwise afford to live here, can't. And also, because we are very tied to the ebb and flow of the economy - because nobody wants a new iPhone, when you can't afford your mortgage. So we have a lot of people that - Oh, and also, we're a fast-moving sort of industry. So we have a lot of people that are just being phased out of their industry. It's hard to pick one particular thing.

But for whatever reason, and I expect that tech is a big part of it, but it's not the only part of it - for whatever reason, there's a lot of people here that are on the streets. In absolute numbers, it's not a huge number. I think - what is San Francisco? More than, it's just a little bit more than a million people, I guess - last I'd heard, I haven't checked. So we're not a huge number. But because San Francisco's only seven miles by seven miles, you are going to be confronted by that number every day. You're going to see people on the streets. There's no place you can go to sort of avoid them, they're just there. It's just a daily reminder, because it's a very small, small city.

Los Angeles, where I come from, on the other hand, has a real homeless population problem. Every year, there is about 250,000 people - and it's not the same people, it's different people sometimes - so it's 250,000 people that have slept on the street at one point or another, but not all year.

Every year, there's 250,000 or so people in Los Angeles that sleep on the streets in LA. Which is crazy. That's a quarter of the population of San Francisco, if you think about it. We don't have anything close to that. I reckon the number is closer to 10,000 at the highest, or whatever? Maybe I could be wrong, but it's not very high here in San Francisco.

So the homeless people, I think, most of the time, you're going to find are pretty harmless. There's two types of homeless people, as far as I can tell. And I've had incidences with homeless people here in San Francisco. I'm sure everybody can give you a story where they've seen somebody avail themselves of the street to go to the bathroom, or something like that. It's just really sad, because there's two kinds of homeless people here.

There's the first type, which is, basically like you and me - we could have one bad month, our company could fold. We could lose our job, we're living in overpriced residence, and we can't afford to make the mortgage for a couple of months. And then, one thing leads to another, and next thing we know, we're sleeping in our cars. But of course it's hard to get a job, whatever - a cascade of bad things, and the next thing you know, after six months, you're on the street. That could happen to a lot of people.

When the economy recessed in 2008, that happened to a lot of people. It happens to a lot of people all the time. And it's just awful. Because these people are not - nobody chooses to be homeless, or very, very few people choose to be homeless. These are people that - they deserve dignity, and they deserve our help. They deserve to prosper as the rest of us do. But just a series of bad luck. And so these are people that don't want to be there. Given the opportunity, a lot of them would happily sort of get out of there if they could.

And the other kind of homeless person is the kind that I would say, maybe need help. These are people that are maybe in the prongs of a drug addition. And they can't help themselves. Or maybe they've got some sort of issue, some sort of health issue, and they can't help themselves. In which case, we should definitely help them. These are people that can't help themselves for whatever reason. So we can't help them either.

So it's just really - I mean the homeless situation, it kills people like me. Because, I mean - sure, it kills anybody who thinks about it for a minute. Because these are people - both classes of people, they can't help themselves. Or they want to help themselves - if they could, and if they can help themselves. It's not because they don't want to, it's just because they don't know that they should.

So yeah, I think, as much as the fact that we've got these two pretty bridges - these are two things that people identify San Francisco for. I think the homeless thing, it's a tragic marker of our small little city - and I don't know how to fix it.

Len: Thanks very much for that great explanation - and in particular for drawing attention to the relative size of the problem for so many people in Los Angeles, compared to San Francisco.

Josh: That number is per year, so it's not the same. Like on any given night, it's maybe 80,000 or something like that - it's much smaller, but still way, way - heads and tails way, way bigger in absolute numbers than San Francisco. It's bigger in percentages too. It's not the same thing. It's just that we are confronted with it here. In Los Angeles, it can take you hours and hours and hours just to get from one side of the city to another.

So you can - there's like skid row, where all the people are in tents and in tentments. And that's just kind of out of the way. If you’re in Beverly Hills, you're not going to see these people in tents very much. It's entirely possible to live a life [in Los Angeles] where you never see a homeless person, if you want to. Whereas in San Francisco, it's just - it's so small. It's so small, you can walk the whole thing in a few hours.

Len: I've been to San Francisco a few times, and I've had similar experiences to the ones you mentioned. Thanks a lot for sharing that.

My next question, as we approach talking about the work that you do at Pivotal or before Pivotal, is about traveling. So, you travel a lot.

Josh: Yes.

Len: I believe recently you were just in Spain?

Josh: Where was I? Spain - yeah, I came back on Thursday from Spain. That sounds right.

Len: Okay, great - I'm glad I got that right. I lived in the UK myself for a few years, and traveled around Europe a bit. And even though I'm a Canadian, because of my accent, I know a little bit about what it's like to be treated as an American when you're traveling.

I was wondering if you've noticed a change in the kind of questions you're asked when you're abroad now? Or in the way that people relate to you when they find out or think you're American?

Josh: Oh, interesting question. 2016 was a strange year. I presume you're referring to the recent change of government, and how did it affect us?

Len: Yeah, just to give a little bit of context - I moved to the UK in 1999, but I started university there doing a doctorate in October 2001.

Josh: Yeah, oh.

Len: And so it was a very charged time.

Josh: Yes, sure.

Len: Particularly with respect to being American. And actually, it was thinking about that experience that led me to ask you about this.

Josh: So, okay - If you get into a taxi or an Uber or whatever it is, MyTaxi or Yandex or whatever or DiDi - and if somebody's talkative, in most of Western Europe - if they're talkative in Asia and if they speak one of the languages that I speak, then, if somebody detects that I want to, that I'm interested - or that I'm not in the middle of something, let's put it that way, and they're feeling talkative - the conversation will inevitably sort of wind its way to politics.

People in the UK, as you know, are frustrated by Brexit. I think over there, there's a bit of sympathy that they feel for those of us going through the current government. In 2016, a lot of the people on the tech circuit, a lot of the people that are speakers out there - like myself, I tend to lean - I'm pretty progressive. I wouldn't call myself conservative. And I think it's pretty fair to say that a lot of the people that I tend to frequently see on the circuit, they tend to lean left of center as well.

So when we saw each other for the first time after 2016, after November - I just remember all my European friends, and all my friends from South America, and my friends from Asia - all of them were just - they were just - they came over to me like someone had died. It was the most surreal thing. I remember the election happened, and then I got on a plane and had to go somewhere. But then like, four or five countries later - I was in Belgium for this amazing conference called Devoxx. It's one of the bigger sort of Java-sphere conferences.

And there I was - I saw dozens of people who came to me like they wanted to talk, like they wanted to offer me condolences or sympathies or something. That was surreal. And it was the same sense that we had right after Brexit. A lot of people were just shell-shocked. They couldn't believe that that had happened. They'd gone to bed and woken up to a completely different world. So yeah, that is different.

Len: It's funny you say that about waking up in a different world. For people listening who might not know, American elections are a really big deal abroad, in a way that the elections of countries that aren't close by, usually aren't.

Josh: Yeah.

Len: I remember going to bed in London early in the morning after Gore won Florida, to wake up to a different world. I remember also, I was in Paris for the 2004 election. And the streets were packed, man. Like, people were out. It was an important event. And I can only imagine what - that was under very different circumstances, let's put it that way. I can only imagine what it must have been like to have been abroad around that time.

Josh: Up until the last two years, if you had asked me, I would've said that most of Western Europe, most of Canada, most of South America, most of Asia - they're left of center people - way, way, way left of center, relative to someone in the United States. And even the conservatives. Like, a Canadian conservative is pretty - same thing for the UK, it used to be true at least, that a right of center somebody, would still be center, relative to the United States politicians.

But now, the last couple of years have changed all that, hasn't it? You've seen what's happened in Hungary, you see what's happened in Turkey, you've seen what's happened in Poland. You've seen what almost happened in France when there was issues with Emmanuel Macron's email. You'll recall that. What else? Brexit of course, that's pretty famous. Italy. Oh my goodness, Italy. Rodrigo Duterte taking over, taking power in the Philippines. I mean, what a crazy few years it's been. So I no longer know where people - where I expect people generally line up.

Len: Thanks for sharing that. Just to close that off, in particular - I've interviewed quite a few people in Europe about this - these issues come up, in particular, with respect actually to conference organizing, and people who are frequent speakers. Because people who are accustomed to organizing conferences in the UK, are curious about what impact Brexit might have on travel there.

Josh: Oh dear.

Len: Like from other European countries and things like that. And so just a bit of scuttlebutt that I believe I heard, was that tech conferences are being - are more likely to be staged in Europe proper now, rather than the United Kingdom.

Josh: That wouldn't surprise me. It's interesting. I think the European Union, one of the benefits of that was that it there was less friction to just going to your next door neighbor’s state, and going to a conference. But I don't remember people - like if you asked somebody in the United States to fly to the other side of the continent, that's very unlikely. But they will do it. There's no reason not to do it. It's as easy as it can be. And with the European Union, you have basically the same benefit there. So I don't know if getting rid of that friction - or rather if increasing friction there, making it harder for people to move from one place to another, will foster a movement of people to those other places to participate in conferences - or if it'll just end up isolating the English. I don't know? I have no idea. It's just a very scary thought.

For me, I work in the Java community, JVM community. And in the UK, you've got - it's a financial center of the world. And so some of the most interesting tech - going back to this idea of like, Silicon Valley is not the only place where interesting things are - some of the most interesting stuff technologically is being done right there in London. In the UK in general, but London is just amazing. You can't believe all the people doing amazing things. High speed training, machine learning and analytics, big, high-scale web apps. Just incredible stuff, all borne of this need to build to be a better financial center. And I'd hate for that vibrancy to be diminished in any way because of things that are essentially not related to what they're doing.

Len: Yeah, I can't help but agree. People who listen to this podcast will know what I'm about to say. But I used to be an investment banker in London, myself, and I thrived there in ways that I never could in Canada. And to see all kinds of things threatened by what - I mean, if you're on the side of things where it's a ridiculous mistake, to contemplate not just the ridiculous mistake, but also the consequences, is quite depressing.

Josh: Yeah.

Len: You mentioned being part of the Java community. I guess that's a good opportunity to segue into the next part of the interview, where we talk about your work.

So, you are a Developer Advocate for Spring?

Josh: Yes sir.

Len: I was wondering if you could talk a little bit first, about what a "Developer Advocate" is - for those listening who might not know?

Josh: I'm a developer advocate for the technology called Spring. In my capacity, I do my level-headed best to bring feedback from the community to the engineering group. I advocate for them to the engineering team. And then vice versa, I advocate for the engineering group to the community. I try and bring what we are doing, what we are working on - the latest and greatest, to the community. And how I do that is how anybody would do that. It's sort of up in the air. You can write blogs, you can do podcasts, you can do videos, you can speak at conferences, you can write articles, you can write books.

Me, I try and do all of that. And there's other ways to get the job done, I suppose. I know some people who do a very effective job just writing blogs. Never leave home, never been on a plane - that's fine, works fine. I know a lot of people who are just amazing webinar runners. They just do amazing webinars every few days, every week or whatever - and that's their entire vehicle.

But I just try and do a little bit of everything. So I've got a podcast, I've got a screencast, I've a weekly blog. All the stuff is weekly. I've got a blog I do every week, I've got books - seven books now, or sorry - six books, I've got one more coming out. I also work on the projects, I work on the code. Feedback to the group.

A developer advocate is ideally somebody that can help connect the community with technology, and make it so that the community wants to connect with that technology. The thing is, people don't trust code. They don't trust software. It's cold, it's sterile, it's clinical. People trust other people. So hopefully I can be the friendly face that helps them find their way to a solution.

And because I'm not a salesperson, I have no vested interest in propagating this technology onto somebody - I mean, I get paid one way or another. So I have no sort of vested interest in that. And so because of that, I think people are happy to talk to me, and I'm certainly very, very happy to talk to them, and see if I can sort them out if they have questions - that kind of thing. It's hard to give a good answer. And I should know better too.

Len: I think that was a pretty good answer. I sprung it on Josh, for those listening - he didn't know I was going to ask him about that.

My understanding of it, and just - for the record - I'm in and around tech all the time, but I'm not a technical person myself. I've interviewed one or two other people who are advocates on the podcast. And my understanding is that - you've got something, in this case - Spring, like a framework that a team of people have developed and are developing. And you want someone to go out there and tell people what the benefits are of using it. And then, very importantly though - you want someone bringing the message back the other way, from people who are using it, to the team that actually builds and maintains the frameworks.

Josh: Right.

Len: So that they understand. So it's actually a really important - I think you used the word "bridge?" That's a very important metaphor. There's messaging, there's talking going both ways. And having someone who understands the interest on both sides, is really important.

Josh: Exactly, yeah. I'm at my best when people feel like they can talk to me. So my Twitter is - my direct messages are right open, my email's If you're using Spring and you've got questions, or if there's something we can do to help, let us know.

Len: Thanks for that - on that note, what is Spring?

Josh: So this one's even harder to answer. Spring is a software framework built on Java, but it serves any number of different languages on the JVM - including Groovy, Kotlin, Scala. And it's a framework. A framework is a thing that calls your code, instead of you calling it. So basically, you write your code and terms in this framework, you write the minimum required to satisfy the thing that needs to be expressed in terms of the framework. And because it's the thing that actually stands up your code and assembles the running application out of the bits that you plug into it - because it has that sort of birds-0eye view of every moving piece in the system, it can do things for you.

And so, that's the foundational piece. We call that mechanism, that arrangement I just described - where the framework actually stands up your code, your objects, your code, your classes - and puts them into motion. That framework is doing so through a pattern called "inversion of control." And inversion of control, in turn, promotes better code. It promotes object-oriented code - where you have nice, clean encapsulation of ideas. That, in turn, promotes testability. So Spring, at its core - is this thing that hopefully produces better coded results in less code, and better code.

That is the foundational piece, and on top of that we have a number. We run the gamut of technologies that you can build on top of that, that serve particular verticals. So if you want to do integration, we have this technology called, "Spring Integration." If you want to do security, we have a product called, "Spring Security." If you want to talk to a NoSQL data source, we have a product called, "Spring Data." If you want to do batch posting, we have a product called "Spring Batch."

And if you want to build web apps, we have a product called "Spring Web Flux." If you want to - it's ever important to be clear about that - if you want to build any kind of application, there might be a framework you can use. And these things congeal nicely if you know how to do that. But a lot of people don't want to have to play the role of gluing these things together. So we have a project called "Spring Boot." Now, Spring Boot is an opinionated take on the Java ecosystem. It allows you to take the idea of a framework even further. At this point, you're writing just the absolute bare minimum. The actual business logic is differentiating business logic.

And then Spring Boot helps you sort of configure all the rest of the stuff. And this has proven very productive. So Spring Boot is really what's, these days, I think the vehicle by which most people consume Spring. It sits on top of all those projects - starting with Spring at the very foundation, and working its way up.

Spring Boot is an opinionated approach. It's like Ruby on Rails. But instead of just being limited to web apps babysitting databases, we can also support microservices and messaging and integration and [?] and web services and security - everything else. It's not just a web app babysitting a database.

Len: Thanks for that. That's a great explanation. You reminded me, you've got a great passage in your book, where you set the context very well, where you talk about Ruby on Rails. I was wondering if you could talk a little - I'll quote you back at yourself.

Josh: Oh dear.

Len: And then ask you if you could maybe explain. Because it not only will give you an idea of the actual history that we find ourselves in right now, how things are changing, but how important these platforms are, in what they do.

Here's the quote: "Now, closer to 2020 than 2000, Ruby on Rails is optimized for the wrong thing. Most applications are not web applications babysitting a database any more. They’re client-service based architectures."

Could you talk a little bit about what Ruby on Rails is and why it was so important when it came out at the time - and why you're saying it's optimized for the wrong thing now, given how things have changed in the last 15 or so years?

Josh: So the original use case for Ruby on Rails was that, if you were trying to build an application, a web application that talks to a database - then you are building an application that has a forum. You have forums, you have user interface elements, you have layouts, you have templated layouts. And these things have business logic that you invoke by posting, or rather, the browser sends a request to the server by triggering a page refresh. And that was the very, very beginning. That was like 2004, 2005. And the response would come back, and the page would be re-rendered, with a new state of the page.

This was right before the sort of very dynamic behavior that Google, I think, first made famous with Ajax. With Ajax, you have this convention - it was a bit of a hack, if I will - but it worked. What they did, was they found a way to send data to the server, without actually triggering a page refresh. And you can do it through JavaScript. So suddenly, I could leave the page alone. The page wouldn't flicker, it wouldn't change, it wouldn't refresh. But behind the scenes - when the page is moving, when the page is loaded - there's logic that's talking to your server.

So suddenly you've got a client, which is HTML 5 - or sorry, HTML and JavaScript based client application running in the browser. And then there's a server, which is the API to which the client made requests. And this is different, because you're not rendering the user interface necessarily from the server - the user interface is now updating on its own, based on data it's getting by making connections to that server. And so really, a lot of the original work that was done in Ruby on Rails was - I want to do all of the logic in the server, including the rendering of the page itself - the template, the markup, all that stuff.

And as we've moved more and more from that model - where now we have eight data API's, we're actually just talking to API's that have their - we talk about rest. Restful APIs. These things give us access to data. We code that data as JSON or XML. Hopefully we're using something like Hypermedia. And the data comes back, and the client then uses that data to then redraw the page. But we're not actually refreshing the browser page itself, we're just using JavaScript to update it in place. And now we also have Andriod and we have IOS, and we have smart TVs and Rokus and Xboxs and your Tesla and Ford cars.

All - everything has an SDK. Your video game console, all these different things have a software development kit that you can use. And these things are also in turn, not refreshing themselves based on some sort of user interface that they downloaded on the first view. They're instead loading the user interface, and then subsequent calls are just going back to the server. This is very much a client-server architecture. So we don't have one user interface anymore. It's no longer sufficient to say that I have just a desktop based browser for my interactions over the web. Everything is on the web.

And so Ruby on Rails really - it wasn't built for htp API's. It was built for htp pages, user interfaces. It's gotten much better, to be clear. But a lot of the magic that it did in the very beginning, a lot of the things that - a lot of the assumptions - the optimizations that it made possible in the very beginning, that allowed it to be so phenomenal as a way of getting an idea from concept over to customer very, very quickly. Those assumptions don't quite hold up in this new world.

So a lot of people that used Ruby on Rails, are moving to things like - or they moved, rather - years ago, to things like Sinatra, which is just a rest API. So you can have Sinatra just by itself, an ORM of some sort? And people are stripping down all of the machinery that Ruby on Rails gave you, and while you can do rest APIs with Ruby on Rails, it feels a bit heavy to have all that extra stuff as well. Which is no longer needed.

Len: Your book is called Reactive Spring, I wanted to give you an opportunity to explain to those who might not know what reactive programming is.

Josh: It's a new solution for an old problem. As we've moved increasingly to this client-server sort of world, and as more and more data's being conducted over the network, we see that people are being increasingly confronted with more requests to their servers. And the result of that, is that you've got bytes being conducted over the network. So the way we do input and output traditionally on a JVM, is synchronous, it's blocking.

So what that means is - suppose I want to read data from a file, the traditional approach, the one most of us, I'm sure, were taught in school, is, you sit there, you ask for a input stream to give you the bytes from a file. As the bytes come in, you process them. But while you're waiting for the bytes to arrive, you're sitting there on the thread on which that request was made, waiting for the bytes to come back. As they arrive, you process them. More come, you process them. But you're sitting there on that thread. The problem with this is that not all things are files on the local SSD file system. Some things are data being sent on their wire, over the network from far away. There might be a failure downstream. There might be, whatever - and the result is that you can't assume that those bytes are going to be there instantaneously.

And so we have this situation where we are sitting on threads, blocking those threads, basically. Waiting for actions to happen. Waiting for data to arrive - and not doing anything in the meantime. And if threads were cheap, if they were free on platforms like the JVM - then this would not be such a big problem. But in point of fact, they are very expensive on a JVM. And they're expensive in a lot of platforms actually. Because any platform that has native operating system threads, will face this issue. So we have to program in - a way to design software that doesn't block.

That allows you to think about data in terms of streams of data. And its needs are asynchronous streams of data. So you can say, "Hey, this data's not here right now, but I can hold onto this thing and I'll get a reference - I'll get that data when it's available." I'll be given a callback. And when you move to that callback centric approach, the result is that you can say, "Hey, I want that data," and then get off the thread immediately. But as soon as you're off that thread, you're not waiting for that data to arrive, you're not sitting there blocking though - you're just expecting a callback at some point in the future.

The natural result of that, is that you get lots of callbacks. And so, callback-centric code can be very, very tedious to kind of untangle. If you've ever done JavaScript no digest programming - circa 2010 - that can be very tedious.

So, reactive programming is a way of working with asynchronous streams of data, while avoiding some of that complexity, that sort of intrinsic complexity. It gives you a standard way of describing that kind of data, and it gives you operators for working with that kind of data - to filter, to flatten out, to do this kind of thing. And because it's asynchronous, it maps nicely to asynchronous IO. Which in turn, gives us this opportunity to not stick around and monopolize threads that don't need to be monopolized. We can get off those threads and allow somebody else in the system to reuse them.

Len: Moving on to the last part of the - unless you want to continue.

Josh: One last thing. It gives you better scale. It allows you to do more with the same hardware. Per transaction - it might be a little bit slower than synchronous, blocking, non-reactive code - but you can handle a good deal many more users per computer, basically. And so the results of that is that either you can handle more users - or you can reduce your data center bill. You can reduce the number of servers to handle the same number of users.

Len: So you've written or co-written a lot of books. And you've produced a lot of content in video form as well.

Josh: Yeah.

Len: I wanted to ask you - how did you get into the project of your first book?

Josh: So, most of my life has just been really good luck. I - like anybody who says that software is skill and whatever, that's just nonsense. It's luck.

So, the first book - what happened? I spoke at some Java user groups about a topic, and then I wrote eventually for a web portal called - that used to be a fairly active gathering hole for people in the Java community - gathering place, watering hole. And that led to me being invited to speak at a little Java conference that they had called The ServerSide Java Symposium - TSSJS.

And then from there, because I was on that list of fairly visible, fairly popular conferences - more things happened. Then eventually somebody asked me if I wanted to speak internationally. I was like, "Oh well, yeah - could do." So I went and spoke internationally. And eventually that gives me more visibility. And somebody finally came to me and said, "Hey, we see that you're doing this stuff with Spring and ecosystem. And there's this legendary book by this guy named Gary Mak, who's in Macau in China. And Gary wrote this book, which is just a fan favorite and people love it. But he needs to step back a little bit, and we're looking for someone to take the reins. Would you be interested?"

And, I'm an idiot. Let's be very clear about that. So I said, "Yes." Now Gary did a very, very good job, and I did - well, I did something. I finished the book. I did my best. I really did my best, and I think the result was okay. Actually it was great. But it was my first - well actually, no, that's not true. That was the second book. That was his book called Spring Recipes. But before that, somebody had reached out to me and asked me if I wouldn't mind writing another book. And so I did it in cooperation with him. So this guy - this poor Gary, he's the greatest, just absolutely great.

He let me write this book. And we worked on it, and it was a book about - like, wouldn't it be great if we had a way to talk about the recipes that you could use to handle these sort of different use cases that go above and beyond what you would see in most books? It was sort of like in-depth nerd wish fulfilment for me. Like, I wish somebody would talk about Spring integration, which at the time was fairly new and nobody was really - there's no book on there, out on it yet - I wish somebody would talk about batch posting and big data and data grids. All these things that you could do with Spring at the time, but for which there had not yet been really interesting coverage. Certainly nothing in the order of a chapter or two of each of these topics.

So I said, "What about a book that just assembled all these kinds of things together?" And so we wrote that book, and like I said, that was okay. That one, I'm very proud of, but that was definitely my first attempt.

And then the second book - at that point, Gary - ever the gentleman, ever the patient type, he'd mentored me, he was very kind and very happy to answer questions and all that stuff. He let me take the helm of his big book, Spring Recipes, and that book, that came out - it began, again - because we had such a solid foundation. Because he did such a good job on that first edition. There was just so much there to work with. And all I had to do was update it and add a few hundred pages. And the book was great. I think - not in any part because of what I did. But it came out very nicely.

Len: Thanks for sharing that story. It reminds me of one or two other people I've interviewed who say - people who are young developers, people starting their careers - saying, "Get yourself out there."

If the kind of stuff that Josh does sounds like the kind of stuff that you'd like to do, get yourself out there. Go to meetups, give little talks.

Josh: Absolutely.

Len: Doesn't matter where you start, you have to start somewhere.

Josh: And remember, if I can do it - you can definitely do it. Truly. And I'm happy to help too.

Len: Speaking of things that you do, you've also made videos, including a series, I believe for O'Reilly, that's on Safari - is that right?

Josh: Oh one or two, yeah. Let me see. So first things first, before I start selling stuff. You can go to There, I do a screencast every Wednesday, where it's just me at a keyboard for 20, 30, 40, 50, 60 minutes - looking at one aspect of the ecosystem, one corner of the ecosystem. At this point, I'm fairly well known for doing just all live coding demos. I don't do slides most of the time, just because I feel like if you're going to show software, then just show software. Why bother with the extra one-directional hop between the listener and the concept with a slide.

And so I do these live screencasts, and they're on YouTube, and I do them every Wednesday - and I hope people will consume them. There's got to be 60 or something like that already. But I also do these longer, in depth - longer sort of - What's a good word? Longer sort of, classes, if you will. And these are on Safari. There's like six of them, seven of them? I don't know? Eight of them? Something like that. There's a lot of them now. On all sorts of different topics. And these tend to be far longer. They tend to be four or five, six, seven, eight hours, and on interesting great stuff, which is - one with Rob Winch, the leader of Spring Security - introducing, guess what? Spring Security. Security's super important. If you want to, if you care about application security, you should use Spring Security. It is the most widely used security technology on the JVM by far. It's been used by more applications than anything else, to secure those applications. So, yeah, please check that out.

There's all sorts of other videos - there's a whole bunch of them. And if you have a Safari subscription, it's like Netflix, it's an all you can eat buffet-style subscription for technical content. If you have that access, you can watch all eight of them or whatever it is - including Spring Boot, Spring Cloud, Microservices - all that stuff for no extra cost.

Len: I've got a sort of specific question about that to ask.

The question I have is, how is the soup made when it comes to those videos? I know O'Reilly did a pivot a few years ago to focus on - I'm calling it a pivot; they started perhaps putting more focus than they had in the past on the creation of videos.

Josh: Yeah.

Len: What's it like? I mean, does a helicopter arrive and fly you to Hollywood, or like do you do it from home - somewhere in between?

Josh: Somewhere in between. So I work with - my publisher is Pearson Addison-Wesley. And so I do the livelessons videos. But they, interestingly - they used to own part of the Safari online portal. It's a technical marketplace like Netflix. And they were co-owners of that with O'Reilly. I think at some point they sold it back to O'Reilly. But they still are one of the major producers of content on that channel, if you will. And so when I do my videos, I go into a studio in San Francisco or in New York, or - I guess there's one in London, I haven't done that one yet.

And I film. It's just me or my co-presenters. And a lot of times I do these with my co-presenter. I love to hang out with people on the Spring team. And so I go into the studio with people I invite from the Spring team - to do this with me. And it's usually just us in front of a hot green screen for two or three days filming. And yes - you sweat, yes you're tired. But you get to hang out with people you like, and you learn from them. And it's only three days, and so - yeah, it's a lot of fun, I guess is the answer.

Len: You mentioned your publisher, and one of the things I was looking forward to talking to you about was why you've decided to write your latest book on Leanpub?

Josh: Oh, I'd always wanted to. So we mentioned one book, I did a few books with Apress. I did a book with O'Reilly. Actually, I did two books with O'Reilly. So it's not like I haven't written a few books before. And it's not that I needed the leg up, it's not like nobody else would publish me. It's just I wanted to have this is my sixth book, so I figured I could take control of the process and I can be my own editor. Or I could manage that timeline myself. I wasn't under anybody else's deadlilnes, basically. And I really wanted control over the feedback loop.

I'm a software engineer. I really like being able to make a change, hit "git push," and see that change reflected almost immediately in the continuous integration environment.

And so, Leanpub has two modalities. One is you can actually work with their sort of pre-canned publishing pipeline, which is fine. You basically work on a - what is it? Dropbox, I guess, or I guess you can do a Git repository as well. Either way, very interesting options.

But what happens is that you make a change, and then a few minutes later - as soon as possible, Leanpub puts out a PDF and EPUB and all that stuff for you. I don't know what those options are.

The other option is that you can bring your own assets. And in this case, Leanpub doesn't really care how you produce those artifacts, how you get a PDF or a MOBI or Kindle or whatever. And I thought that was very interesting.

I love Asciidoctor, and Asciidoctor's completely programmable. So I've used Asciidoctor. I love writing books in Asciidoctor. It's just a very nice system. Plus my books tend to have lots of code. It's not a storybook, it's a technical book where I'm including snippets of code. So I need to do pre-parsing on the book before I can arrive at the final artefact - the final manuscript, basically. And so having the ability to program that pipeline, and then just have that generate a PDF and an EPUB and Kindle and a MOBI and all that stuff - which I can then periodically log into Leanpub and then upload as my latest updates. That automatically happens though. And generally it's all that stuff, every single time I do a "git push."

The result is that I get instant feedback, I can run my tests before I publish the book. I can make sure that the quality of the code is up to snuff. I'm able to write a book like I write software, iteratively. I get fast feedback. And I don't expect that everybody will want to exert full control over this part of the lifecycle.

But if you're a technical publisher, I think you might. I actually ended up writing a lot of software for this process, based on the amazing Asciidoctor project. And thanks in no small part to Dan Allen and the people over there who are working on this stuff.

And so as a result, I actually have software that I use that is open source. If you'll indulge me, I'll share it with your listeners - that they can use to then publish their own book, okay? If they want. If they want to exert more control over this, if they're programmers. The process you've got is great. It's already very good. I'm not trying to discourage that.

So if you go to, there you'll find a Maven project - it's open source. You can throw away my travis build, and you'll - I won't explain it to you all right now, but the point is, if you run that process, it'll generate the artifacts for you, if you comply with the project. I'll make sure there's documentation in place by the time any of your readers find it.

Len: Thanks very much for sharing that. We love hearing directly from authors about the systems and processes they have set up. And our authors love hearing from other authors about their innovations and their approaches as well.

Just to explain very briefly, Leanpub has a number of different writing modes directed at different types of people. We've got one for writing genre fiction - so it's just in the browser, basically WYSIWYG. Then we've got Google Docs, so you can write in Google Docs, if you're familiar with that, and you love using all their collaboration features and all that kind of stuff. And then the canonical thing is writing in plain text, in Dropbox or Bitbucket or GitHub.

But - as you could tell from Josh's impassioned description of his workflow that he built himself - a lot of authors have their own way of doing things. And so we built something called the "Bring Your Own Book Mode," which is what Josh is using. This means you just upload PDF, EPUB or MOBI files to Leanpub, and they're instantly published and available to all your existing and future readers. So there's no friction when it comes to updating your book.

Josh: Right. And I love that.

Len: And yeah, we want to respect the fact that- like, we're opinionated, we understand. Basically every good book author is opinionated too, and so we - it was funny, because it's like, ultimately, to satisfy the most sophisticated users, we built the simplest feature - which is like drag and drop a file.

Josh: Love it.

Len: But there you go. Of course, when it comes to publishing in progress, we've got all kinds of other features. And you've decided to publish this book while it's in progress, you've published it before it was finished, and there's sections marked "to do," and you've got your email address in the book saying, "Email me with feedback." What's that experience been like for you so far? Was it something you were excited to try or scared to try?

Josh: I was excited, because - I mean, first of all, a lot of the other publishers out there want to get early feedback. They want to get people excited about the book. I love the way that Leanpub does it, but it's not unique to Leanpub to want to get feedback, and to want to get people excited about the book. So I knew that that was something I wanted. But the fact that I can go out there, and have something out there, that people can try, and it's just built into the platform - people expect to give feedback to that. The whole point of Leanpub is that you have this iterative process, and you can get it out there.

And for me, it was really - because the only person I signed a contract with this is myself, I told myself, "I want to finish this book." But if it doesn't happen, then - nothing ventured, nothing gained - I guess? It will happen. But you don't know if it's worth doing until you've gotten it out there. And with most publishers, there's no direct feedback, there's no validation of what you've done until months later. You don't know. Well with this, you put it out there and people start buying it immediately. There's just this tsunami where people are just, "Oh, that sounds great, I'll have that."

Just getting that validation is great. And because it's an iterative platform - the thing I'm talking about in this book is changing. At some point I'm going to have to pin it down and say, "This 1.0, and I'll work on 1.1 next. But right now it's changing fast enough, that I'd like to be able to get it out there and get people excited about it" - knowing that I might have to change it soon. So Leanpub is really great for that sort of agile, iterative process. I love that.

Len: It's really interesting - you touched on something there that - we don't really talk about it too much, and it wasn't necessarily something that we were like, that was really kind of top of mind when Leanpub was created. But one of the biggest problems that writers have is motivation. Not desire, there's all kinds of desire to have the book done and get that Nobel Prize. But actually sitting down and typing it out, isn't always that easy. And actually this process of publishing a book before it's finished, turns out to be pretty magical for getting that motivation, for at least a few authors.

Because you've got somebody who's like, "Hey, I've found a typo on page five." You can fix it by the time you reply to them.

And then they're like, "Oh and by the way, that section that you haven't finished yet, when's that going to be done? I can't wait."

You're getting positive feedback, and you know there's someone out there who has a genuine - not just desire, but like, need for what you're writing. And when you know that, it changes your attitude towards like, "Well, what should I do? Should I do some more Twitter for the next half hour, or should I maybe bang out that section?" And if you know that there's someone out there waiting for it, they can really make a difference.

Josh: And actually, that's a great point. I can solve - even though the book isn't done, I can solve the problem that somebody else is having right now. I can - like, they may just need that one chapter. They're willing to buy the book for that one section that is novel to them, that teaches them - illuminates something they didn't otherwise understand.

And the other thing is, people ask me, "Is this book going to cover X, Y, Z?" on Twitter or other channels. And I say, "You know what? I wasn't planning on it, but it seems like there's a common enough interest that I'd love to do that." So I have the benefit of being able to market these things myself.

That's the other thing that I think is really great about this. I spend just thousands of hours in front of audiences all around the world every year. And so the first thing I do in all my presentations, is I talk about this book I'm writing, called, "Reactive Spring," right? And so people go to the URL and they buy the book and whatever. They know it's coming, and they bookmarked it. People ask me about it on Twitter. It's got it's own Twitter handle @reactivespring. As long as you're willing to open the door, people will go through it. They want to talk to you as much as you want to talk to them. And that's great, it's just great.

Len: The other thing that I didn't mention - actually, people find this a little bit surprising when we say it - but another thing that can happen when you launch a book after you've written,s ay, 20% of it - is nothing at all. Because you've written something that might be excellent, but just no one happens to be interested in. And in a conventional publishing process, that means years of your life have gone by, potentially, before you realise, "There might be an interest in something else I could've written, there's just no interest in this particular subject that I chose to write about, and the way I chose to frame it." One of the biggest successes in a Leanpub book is when someone stops writing it, when they otherwise would've spent maybe - like literally, maybe years working on something that was bound to not really achieve the goals that they were aiming for.

So if you decide to self-publish a book and you drop it and turns out there's really not that much interest - if you've published early, there's a silver lining to that cloud, a very serious one as well.

The last question I always like to ask, is - if there was one thing on Leanpub that we could build for you, or one thing we could fix for you - can you think of anything you would ask us to do?

I'm not sure. Let me think about that. I can't think of anything. Because, again - you let me solve the problem. I was able to scratch my own itch. I'm a software engineer, I was able to scratch that itch - and your platform let me do that. That's one of the things I really wanted, was the ability to have input into that. The thing I would like to solve is the production pipeline. And you did it for me.

There's other things that I really appreciate, like the very generous royalties for use of your platform. That's appreciated, obviously. The fact that I retain the rights to the book, so I can publish it on - so I can distribute it through other things as well. I'm not foreclosing on that opportunity. What do you think, what is the thing that other people say, I wonder?

Len: What do other people say?

Josh: Yeah.

Len: Usually it's often quite specific. I mean actually - probably the most common answer is, "Mmm, I can't really think of anything right now. Because everything just kind of worked." And that's not me boasting. I mean, Leanpub's been around for years, and we listen very closely to the needs of authors. And so unless you're doing something unique to your project that hasn't come up for us before, things will probably run smoothly.

But actually, collaboration is something that comes up a lot.

Josh: I see.

Len: As you said, the sort of raison d'être for Leanpub is to help authors get feedback early. And there's a great deal more that we could do around that. Like, say, interacting in the Leanpub website or app itself - you can imagine various communication channels or changelogs you could have, or people submitting requests for changes there in a more formal and structured way.

And readers interacting with readers as well, is another thing. So building that community kind of stuff, is just this whole dimension of Leanpub that is almost - there's a foundation there, but there's a great deal that we could build. And that's something that does come up pretty often.

Josh: I look forward to trying it, obviously - I'm a big fan.

Len: Great.

Well thank you very much Josh, for taking the time today to talk to me and to all of our listeners. And thank you for being a Leanpub author.

Josh: It is my pleasure, thanks so much for having me. Thanks for the great conversation.

Len: Thanks a lot.

And thanks as always 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. Particularly iTunes is helpful for us. And if you'd like to be a Leanpub author yourself, please visit our website at Thanks.

Podcast info & credits
  • Published on June 19th, 2019
  • Interview by Len Epp on June 3rd, 2019
  • Transcribed by Alys McDonough