Learning Spring Boot, with Greg Turnquist (Ep. 85)

Episode 70 · 36:02 · SRT · archive.org · all Tanzu Talk

Well, we actually have recorded an episode already this week, so we don't have any news, but we've got just another guest on to talk about. I forget when it came out, but the second edition of his Spring Boot book, Learning Spring Boot, I think it's called. But why don't you introduce yourself, guest? Ah, hello, everybody. My name's Greg Turnquist, and I'll throw it out there. It's Greg L. Turnquist, because there's actually another Greg Turnquist, amazingly, that writes software, and so I have to put that on all my books. What's the L for? L is for Lee. Lee. Very nice. Is Lee short for anything, or is that just its own thing? Not to my awareness. I'll have to look up the origin of that name. I never thought about it until now, but that's kind of a weird name, Lee. I mean, we all take it for granted, but I wonder where it comes from. I mean, you know, not that it reflects weirdness on you, just words, right? They're crazy. Am I right? What's your middle name, Coté? Richard. No, it's not. It is. Yeah. Get out of here. I never thought about that either. Obviously, I don't think about middle names very much. No, it is Richard. Michael Richard Coté Jr. The name that was so good, it was used again. Wow, our merger continues to succeed here. This is amazing. Yeah. I have a little belt buckle I got from my dad that says MRC on it, but sadly, it's from the era where belts were like, you know, two centimeters wide, so it doesn't really fit on anything that I have. It's also gold, which I've been told is not my color. I should not wear gold. Are you a silver man? I guess so. Yes. Silver. Got it. Maybe when I retire, I'll ease into that. You know that look that people have where suddenly they're just like, I'm going to wear a lot of turquoise? I wonder if that would pan out. I could see that. I could see that. Yeah. I mean, yesterday's podcast, it's the member's only jacket and the pressed pants and the gold

buckle. Yeah. Yeah. Gold buckle, some turquoise, maybe get a bolo. Next thing you know, I'm like that Langmuir guy. How do you say it anyways? It's solving crimes in Montana or Tucson or something. Well, so back to the topic at hand. So the second edition, when did this book come out? Probably about 12 days ago. 12 days ago. And you have a video companion with it? Like, is that right? Well, I have a video. Companion's kind of loose. I contracted to do this book and the video at about the same time, but the video came out about a year ago and it's against, the video is against boot 1.5. The book is against spring boot 2.0 with the extra wrinkle that the whole thing is written with the project reactor paradigm. And there's just nothing else on the market like that today. Cool. Yeah. I mean, that's gotta be wild to be writing a book about technology that's not yet shipped, right? Because boot 2.0 is not released yet. So how do you, how do you go about doing that besides the fact that you have lots of insider access? Well, now you're looking at the reason it took me to write over a, over a year spent writing a book that for my publisher, they typically turn around stuff in six months. So, um, it's actually released against spring boot 2.0 M5. Cloud in it. It has spring clouds, eventually M3 milestone release on it. And all that stuff, all the different, uh, tools that stuff you probably talked about in past episodes, it all works together pretty nicely. Like spring security, spring framework, spring data, spring session, reactor. That's cool. Who is, who'd you write this for? I mean, who is the target audience? Uh, um, um, well, oh, uh, I wrote it for, um, basically, you know, are you, you know, if you're already familiar with Java to some degree, uh, you know, this book is for you. If you've used spring in the past, I think you'll find it really handy as well. Well, there's, I've gone to conferences and ran into people that were absolutely familiar

with spring framework, but still had not dipped their toes into spring boot yet. And they're kind of like, you can do all that with boot. Wow. So it's like, here you go, grab this book. It's very practically oriented. So we don't, you know, dive into real deep esoteric stuff, but instead let's put together a practical application and run with it. Yeah. I mean, give me your boot pitch. So for that person that you bump into at a conference who says, yeah, yeah, I like spring framework. I love dependency injection. You know, I don't need your, your highfalutin opinionated framework stuff. I mean, give me the boot pitch. What does that add to a developer who's maybe even new to spring, but let alone someone who maybe uses spring framework, but hasn't tried it yet? Well, I think Phil Webb has said it best. You can think of spring framework is like a handful of ingredients and spring boot is like a pre-baked cake. So here's a cake and in, in 30 seconds, you can have a cake and right in front of you. And then what do you want to do? You want to tweak the frosting. You want to alter how many layers it has. Do you want to swap in an alternative recipe for the cake itself? You know, start putting in your own stuff and the, the defaults back away automatically. And it just, you know, boom, you're, you're working with operational stuff, right, right off the, right off the assembly line. So give me an example. Yeah, yeah, exactly. I was going to say for like a web app. So, right. We're building, I'm building a restful web service. What does boot give me that I wouldn't just have out of the box when I start using spring framework? Okay. Well, you start off with the, if you go to the website, start.spring.io, it's basically a checklist. And you say, I want, I want rest on the backend. I'm going to use MongoDB and I'm going to pick out spring data. And what it's going to do, it's going to hand me a running app and I can go in and start defining the domain objects and the controllers to connect it all together. And I don't need to think about like, uh, you know, do I need to wire a servlet container or do I need to connect it to Netty or do I need to define view resolvers and all the stuff that you use to connect all these components together?

Instead, you start writing the operational stuff and boot is auto wiring the rest of it for you out of the box. And, and so, so, uh, go, going on the other end of the, uh, the abstract scale, where, where do these opinions come from? I mean, if it's like an opinionated way of, of packaging things up, how do they, uh, how do they evolve and how do they get decided on and put in there? Uh, well, there's actually a, you know, there's a dedicated team within the spring, within the entire spring team called the spring boot team. And, um, they've, they formulated a lot of opinions, but the, the boot team and the whole spring team is actually very open to user feedback. And so we get a lot of, uh, opinions suggested by the user community, people that are deep, deepened involved with working with MongoDB or there's other third party toolkits. Um, in fact, we've recently added support for like Microsoft Azure to do some, uh, some of these, you know, you say opinions, we call these auto configurations or, you know, a boot looks at your class path and says, oh, I see that you have spring MVC on the class path. I'm going to assume you want to use that and pre-configure some components. But if it sees these particular, like Azure based components on the class path, um, it can sit there and start to auto configure things on your behalf. So there's a lot of internal and external contribution to that. Yeah, I guess, I guess there's some, uh, there's some fine needling to be done between the, the, uh, the semantics of the word opinion versus convention. Right. And, and like the sort of, and, and then further on default of how, how you would do things. But, um, I mean, that definitely seems like one of the primary advantages is, uh, uh, having, not having had to think about convention if you want and, and getting things, uh, getting things wired up, but so, so anyway, as, as, as another question, like, well, I presume when you're writing a book like this, you have to sort of think about, um, what are the difficult parts about this technology that I need to educate people about? Like what, what are ways I need to change their thinking so that they understand how they're

doing things? You know, unless it's just like a straight up manual, which probably is not, but like, are, are there some of those things where like ways you have to think differently, uh, or, or in, in a good way or bad way, if you're, you're doing sort of like a, uh, boot led application? Well, I think more often than not, which you kind of run into, and this is what I try to put into my books, uh, is that, uh, you, you come upon a decision. Well, boot's got boot in this situation. Um, you know, you may have a certain boot may have a pre-configured opinion, but the idea is you can step in and say, well, I want to do it a different way. What's the trade-off? Cause everything, you know, software is built on trade-offs. So I try to write into the book and say, here's the default opinion. But maybe you, you need to do this other situation. Here's how you can get in here and just tweak this one part of the configuration. And here's one, here's a reason why you may want to entertain doing that. Why maybe the default's not the best answer, uh, for that situation. And so, you know, I try to give them, I try to give them trade-offs so they can evaluate that. Cause not every, you know, example that I'm going to put in my book is going to fit the reader's needs directly. That makes sense. So, so it's sort of like walking through the, uh, the trade-offs. I'm just repeating what you said, but no, no, that makes sense. And, and, and I suppose, I suppose, uh, you know, in the book you give examples of like, if you were to do things this way, it would imply this, uh, this, this path of nastiness to go down versus this other path of nastiness. Choose which path you want. Well, I, I try to minimize usage of nastiness when I write spring apps, but, uh, yeah, now I can throw you, since we've been talking abstract, I can move to a little bit more concrete, the examples that are in the book. Yeah. Yeah. Um, and, and I can do that by, uh, citing a, a, a familiar person that we all are, must know, Josh Long. So, you know how Josh Long travels around to conferences and when he gets up and does a presentation, what's the first thing that he does at any of these presentations? What does he do with the audience? I think he takes a selfie picture, right? Figure out who's on the Twitter.

So, so I had this idea two years ago for a SpringOne demo of, I wanted to get up and demo the software stack of spring. And the paradigm was, let me take a picture of, let me take a selfie and upload it to the app that I'm demoing to the audience. So basically in the book, we build, build a social media app where you get to upload pictures, um, and made comments on them. And I call it spring-a-gram. No trademark. So throughout, it's also partly inspired because there's this hilarious movie called The Interns where they're trying to come up with an app and the guy like says, I've got this great idea for an app. You upload a picture on your phone and then somebody, the other guy tries to tell them that's Instagram. And he goes, no, my idea is different. When it's absolutely not different, but, um, so in this one, you know, I, I go through the book and actually chapter by chapter, we build up this, uh, spring-a-gram app because you need things like you need a front end web page. You need to write stuff into the database and the MongoDB in this example. And we need things like web sockets and we need messaging. And I even expanded it into a microservice-based solution in one of the chapters. But it's all real realistic type application versus, um, uh, something you kind of. Yeah. I noticed in all of that, I mean, it wasn't just building the app, but you looked at testing strategies. You talked about deployment, things like that too. So do you feel like you covered a good life cycle? If I'm a Spring Boot developer, I'm trying to learn Spring Boot, you're trying to show me some of the right ways to do some test-driven procedures and how do I package this thing up and run it on different types of runtimes? Was that something you wanted to do is make sure you got that end-to-end story figured out? Uh, exactly. You know, that's, I really wanted to show here's how to start from the beginning from our start.spring.io and, um, carried all the way to the end to deploying it to, uh, of course, Pivotal Cloud Foundry.

Naturally. So one of the other things I noticed, obviously you mentioned, you did a lot with reactive here, and we've talked a little bit about reactive on the podcast so far, but as you look at Spring 2, you know, what are the things that step out for you in, in Spring Boot 2? Like, is it the reactive, are there other pieces? I mean, it's first, our audience here, who's going to start hearing more and more about Spring Boot 2, especially at SpringOne platform coming up, you know, give the sneak peek. What do you think are the real headlines for, for Boot 2.0 and which ones did you cover in the book? Well, the, you know, part of the biggest stuff in Boot 2.0 is that it jumps up. It's, it's based off Spring Framework 5, which is our latest major release of the Spring Framework. And with that comes everything being re-based on Java 8. The previous version of Spring 4 was based on Java 6, which is now Java 6 and 7 are both end of life, and people are now talking about Java 9. So the big thing is we get to jump up to Java 8, and there's a lot of new programming paradigms right there to take advantage of, like stream APIs and, you know, method handles and a lot of stuff that feeds towards functional style programming, which then if you jump into Project Reactor, Project Reactor is based on Java 8. And that's where we get really deep into this, you know, functional programming style, you know, a reactive functional style. And to be specific, it's really the reactive streams spec that we're talking about here. There's a lot of different reactive programming paradigms out there that's been around for decades, but the one we're really diving into is the reactive streams spec that comes with back pressure. So there's been, you know, there's a whole bunch of new APIs that the Spring team has probably spent over a year on, maybe two years. Because I remember Nexus in 2015 talking with Rawson, who works primarily on Spring MVC stuff, and he was, we were talking in the car driving to a jug meeting about reactive stuff back then.

And they were like, you know, we need to do a lot of analysis on this and make sure we come out with a good, a good approach to it instead of just throwing something out there to the community. And I think they've done a fantastic job at that. Yeah. And you feel like with the Spring Boot and Spring in general, again, that you're putting some opinions on that, on how the right way to do, or at least a good way to do reactive programming outside of what you could override later on? Absolutely. You know, one thing that's definitely gone into Spring Boot, too, is that, for instance, you're like, well, I want to use MongoDB. And I keep going to MongoDB because it's one of the data stores that we support that actually also supports the reactive streams spec. I see. So you get to pick a dependency of, I want Spring Data MongoDB or I want Spring Data MongoDB reactive. I get to pick one of those two options with boot 2.0. And from there, you know, the boot's going to automatically configure up and hand me the components to talk reactively to MongoDB. And I, you know, then I can run with it from there. So maybe using your, um, your, um, your Instagram killer app, which, you know, good, good luck. That's, that's a good market to get into, uh, maybe narrowed down to conferences. I have a feeling that conference software has really big margins based on how little they update it. But anyhow, like, you know, just like explain why I'm trying to avoid saying what, but explain why you would choose to like do, do a reactive thing. Like what, what would the reactive style be like in reference hopefully to your application? What would make you choose to do things that way versus, I don't know, unreactive things? What would that be? Passive? Uh, well, I guess they'd call it a blocking. So the big thing is, well, you know, what is, what is reactive? And reactive means non-blocking asynchronous APIs. And, you know, the real thing is, is while, while the file is being uploaded, you know, in this case, let me, well, the use case is, um, somebody is going to go to the webpage. They want to upload an image.

After the image is uploaded, we need to store some of the information in MongoDB. And some of it's just going to be a stored file. And then we're going to send the hand, the user back a redirect to go back and look at the image. So retrieve it and display it. And then also then later on, they can add, you know, comment on it just like any social media platform. So to do that reactively means that, um, everything is being like, you know, uploading the file is done in an asynchronous way. And that is there's, while, you know, I, you can start the upload process, but if the system's going to interrupt it, don't, don't hold up threads or other resources waiting for the operation to complete. While you're writing data to MongoDB, uh, you don't need to hold up the resources. Instead, you can say, Hey, Mongo, I've got the data here. Let me know when you're ready. In the meantime, I'm going to go over and do this other stuff and not waste resources, hang in here, wait, come back to me. Right, right. It's sort of like internally, metaphorically, the little, uh, the little Tron people who are running the computer, they can go get a cup of coffee while they're waiting. They don't have to like, uh, block and stand there. I don't know. That's how I think of things, I guess. And, and so, um, so, so am I right to think that like, if you are doing all your reactive stuff and then whatever, whatever this serverless business is that comes along, there seems to be a pretty, uh, structural overlap between these two things. Cause you know, I was, uh, I was talking with some, there were ISV people, if you will, not an enterprise who is figuring out stuff to do with serverless. And we were talking through various scenarios and it seemed like, uh, it's pretty much very similar to, to, to what you're just describing, except without any orchestration on top of it. It's basically just the holes you shoot your asynchronous things down. Uh, I don't know what would be on top of that, but I mean, I mean, is there like, what kind of overlap is there between these, uh, these two, uh, exciting areas of, of development? Well, you know, you know, you have a overlap there's, there's, you know, this is not the only toolkit that's out there that does reactive streams or that does asynchronous non-blocking operations.

There's a lot of things. And so, um, one thing that Rosson had explained to me and that has become evident with what they, with what the spring team has released is that we don't want everybody to say, hmm, am I going to write this app in a classic spring sense? Or do I have to go write this in a completely new paradigm? Do I have to throw everything that I learned away and start over again? And I would find that frankly off-putting. And so they spent a lot of effort to where, you know, you can define your web controllers and your data repositories and stuff the same in either, in either paradigm. And it's really when you get down to the nuts and bolts that you need to, you know, alter the way you're going to actually do some of these operations. But the way you declare your spring, you know, whether you write a spring MVC blocking controller or you create a spring web flux non-blocking controller, they can look virtually identical. But still, you know, one's going to leverage the classic servlet runtime container and the other one can leverage NETI's asynchronous reactive container. So when you think about that, I was going through your chapter on testing and thinking about that. I mean, do you think with reactive or even dependency injection where there can be at least a sense of a little more unpredictability, does it change how you approach testing and writing tests when I've got auto configuration happening? Things that can feel like black box or reactive apps where things are calling back later than I expected. How do you think about testing when you don't just have this kind of procedural blocking sort of application with hard-coded references, you know exactly what you're referencing to? Do you find that that changes or it's just kind of a different, you know, a couple of different things? Well, you know, as somebody whose first job assignment in this industry was testing other people's code, there's a lot of different ways to slice testing. And I tried to go into a lot of detail, granted that whole books have been written on testings, so I wanted to try to go, hey, you know, some things you need to test are very small, like unit tests.

Unit tests should not run aground of any kind of react, either blocking or non-blocking. It should be below that level because when you talk about blocking, now you're talking at a higher level and involving a container of some sorts. So some things you need to write unit testing, but you can easily overlook, hmm, I tested all these units, but I forgot to test what happens when you put them all together. So that's why we also need integration testing. I need some sense of end-to-end testing or test-to-thread of testing. So in boot 1.5 and earlier, they had the ability to spin up an entire embedded instance of Tomcat for one test case and test stuff like that. But then they added a third option called a slice, saying, you know, in this case, I want everything to be mocked out except the data layer. I want to talk to a real database in this case. Well, let's let everything else be mocked out. So you can really – I think it's very well managed, and even the reactor team has a test library to assist with saying, well, in this case, we need to actually test a reactive flow, and I need to simulate that at this point, it's going to wait a whole hour virtually before it does the next test step. Got it. Okay. Yeah, I'm just curious as to how we think about that with our developers. And I guess kind of related to that, you talked a little bit about tooling in the book as well. You look at dev tooling. I mean, do you have kind of a must-have for Spring developers, whether they're getting started or more advanced when it comes to IDEs, when it comes to sort of dev tooling or other sort of framework components that you like to latch on? I mean, what makes a good Spring dev experience in your mind? Well, I – you know, one of the modules that I thought was the coolest addition was when Spring Boot added the DevTools module, which, you know, that was a few releases ago. And that's something that sits there and watch it while you – it's – you just add this one dependency, and it sits there and watches your app. And if it detects a save or a refresh of the project, it just automatically relaunches the application context.

Instead of restarting the entire app, it just restarts essentially the user code that you wrote, and so it does it very quickly. And also they hooked in integration to Live Reload, which is an independent library that it's all built around the premise of I've got a web page in the browser, and I need it to automatically click the refresh button for me as soon as it detects there was an update. And that kind of stuff to me, that just speeds up the clock cycles of I'm going to go update this template. Let me see a refresh on the web page. I'm going to update this service. I want to see it refresh on the web page without having to jump back and forth and click a bunch of buttons and stuff like that. Now, in addition to your soon-to-be industry-leading conference selfie-sharing app, like, do you know off the top of your head? And maybe you know too, Richard, like, do you know some good examples of, like, applications people would know that, like, are basically boot-led that do a lot of the things we've just been talking about? The most stuff I hear about is people like Matt Stein that are in the field all the time, and they keep coming back. And I couldn't put my finger on it until I think he stated one time in an email, and it's like – he's like, I can't believe the amount of acceptance out there in the community that's been received based on make everything a boot app, a self-contained boot app. I don't think we could have predicted the success that has happened in microservices with the fact of make every single microservice a boot app because then you have this common paradigm of here's a JAR file. It does one thing, and it does it well, and with the Spring framework, you can then link to the – in Spring Cloud, we can link to the other microservices. We can run 50 copies of this, two copies of that. Everything is connected and talking and integrated, and it just seems like the boot paradigm to me is almost bigger, in my opinion, than certain other things like Docker. Shots fired. There you go. So, I mean, in your mind, when you do – a couple questions left, but when you look at something like boot for everything, I mean, boot's not lightweight per se, right?

It's not like running a 32-meg Node.js app somewhere, and now you're going to get a lot of power in exchange. But what do you think or what do you say that's sometimes the concern that, like, you know, a Java app – and maybe it's a Java app, it's not a boot app – but that Java isn't always the best fit for microservices because it has a larger footprint. What do you kind of say to that challenge? Well, I don't know because I've been hearing that for I don't know how many years. I remember – I think when I met Rod Johnson in 2008 at the – what was then called the Spring Experience Conference, and I chatted with him. He said back then, you know, it seems popular to criticize Java, and it seems like that popularity has not faltered yet. It seems like – what's this most recent survey? Was it from the people behind JRebel had commented that, like, one out of two Java developers are using Spring. And it's like Java is, like, one of the most – like, the industry standard language. So to sit there and say, but your JAR files aren't small enough or something sounds kind of, like, kind of petty or, you know, not a very well-rooted thing. It's – I think a lot of people demonstrate their support for boot by downloading it. How many millions of downloads a month of boot are happening? Yeah, it's crazy stuff. So it seems like – This, you know, this works. This works for people solving problems. So what else do you need? Absolutely. Yeah, I mean, sometimes it's nice to have crazy high density, but at the same time, computing has gotten cheaper, and sometimes fighting over a gig of memory or 500 megs, sometimes that's not worth the productivity benefits. So then I got another abstract question, especially given your background, Richard. So I've been – you know, I was never a big Microsoft.net developer back when I did real work. But my perception – Sorry to hear that. But my perception of that community was that there was a lot of things built in, that you had sort of like a unified stack with a – I don't know, opinionated ways of doing things by virtue of it being not – at the time when I was doing it an open community and things like that.

And then, you know, as I've been paying more attention to the way that, like, spring-based Java stuff has evolved, it seems like kind of similar to, right or wrong, that perception I had of the .NET world. So first, like in the .NET world, do they have a lot more of these – historically, are there a lot more, like, opinions and defaults baked into it? And too, like, I don't know, to you who knows these things, like, does it feel similar between these two or is it still vastly different? That's an interesting observation. I mean, I think there was more baked in because there was a smaller community outside, if you will, because it was an open source, right? So more had to be in the product because you weren't going to bolt on as many things potentially. So, yeah, as a .NET developer, you had a lot of crazy great things just baked in to help you build web apps and background apps and all these sort of fun things. Now, as it's become a little more open, you have a lot more of a package ecosystem, too, of bringing things in to leverage. But I wouldn't really call it super opinionated. There were still lots of ways to do the same things. You didn't get shoved down one route or another. So I think Boot is still unique in that. But, Greg, interested in your thoughts on – do you see a similarity there? Are they still kind of on different strategic paths? I actually had somebody that used to work for me that knew both Java and .NET, and he would – his joke was to sneak into my cubicle and try to install a .NET app without me seeing it, where from his machine over the network, he could command the CD-ROM drive to open up on my machine while – and I'd be like, what is that? And he would also change the screen wallpaper and stuff. And it took him, like, five lines of code with .NET because of all the pre-baked APIs. That's true. It was very opinionated for Windows, very easy to talk to Windows. So at least that was something that was definitely made very simple. Yeah, yeah. I mean, that's kind of when I start hearing about pre-baked APIs, I kind of think of that paradigm. And I'm like, I think of, well, is that all that you can do? And when I see people look at boot and say, oh, I don't know, is that a little too much black magic in there and stuff?

And that's why I try to, in the book, make a point of showing, you know, well, here's what's happening. In fact, there's excerpts of code about here's the auto configuration, and this is all that it is. It's not that complicated. And, in fact, let's go write our own auto configuration and register it, and you can make it, you know, its own first-class citizen. And there's actually companies out there or OSS communities that are publishing their own third-party boot auto configuration options. So I think it's much more extensible and, you know, write, you know, do what you like options when you're talking about boot. Now, I can't comment on .NET for current sake, but so that had to be about 10 years ago, but that's my take on it. If I can just offer a suggestion for the third edition of your book, you might want to incorporate opening CD-ROM drives somehow into there. I think that would be great. Maybe integrate with the local operating. It reminds me of a joke way back when we played on one of our coworkers. We were, like, you know, at a startup, so we were in some big, ugly room of some cheap space we had rented, all of us. And every day for about a month, we would, like, move our friend, let's say our – it was our friend. Our friend's desk, like, an inch closer to another desk. And, you know, so it's kind of imperceptible. And I remember one day he came in and finally noticed it, and I think he just, like, lost it. He just got very upset at that prank. So it sounds like maybe you were much better at receiving pranks of having your CD-ROM drive open. Big fan. Yeah. Moving the desk by an inch. Well, so, I mean, I think that's a pretty good overview there of the book. I mean, I assume the book's available everywhere, right, where fine books are sold. Oh, yeah. Yeah. Yes, go to Amazon right now and get your copy. Learning Spring Boots, second edition. So how long do you think it takes to go through the book? Well, it took me a year to go through it, but I don't want to say that that's the story for anybody. Yeah. Well, I think writing it's another story.

But I guess you – how many times did you say in writing the book you ended up reading the book? Oh, my goodness. I've probably read each chapter three or four times. I think I would go – at a certain point – now, this is a tip for any author. At a certain point, you've got to stop reading it because every time you read it, you're going to find a mistake. Now, that's true. You have to realize when it goes to press, there are mistakes in there, and you have to let it go. Yeah, yeah, yeah. Yeah, that's a nice moment of calm when you just decide that, like, screw it. I'm done with this thing. That's enjoyable. A little nerve-wracking maybe. Well, then you also write some other books, right? Yeah, this is actually the fourth book that I've written. I wrote its predecessor, Learning Spring Boot, and just that's the first edition, and that was based on Boot 1.1.6, which is now an antique, I guess. That one was really popular. That was the first book that hit the market that was on Spring Boot, I'll say in English. I think somebody beat me in Japanese, putting out a book, but I'll say in English. And that was real popular because that came out – I think I signed the contract, like, only weeks after Boot came out back in 2013. So – and then before that, I wrote a book called Python Testing Cookbook that actually people are still buying today, amazingly, back in 2011. And then you write some fiction books too, right? Yes, that is correct. I've actually written a – I've written a novel. It's sort of a YA speculative fiction thing, and it's slated to be published next March. Oh, you know, I was looking through your books and thinking, like, I guess – I've come across a lot of people at Pivotal, well, which is to say two, who, like, write fiction books. But two is a lot more than the zero that I've ever come across. I wonder if there's other people inside Pivotal who write fiction on the side. Or maybe their job is the side and the fiction is the main table or whatever. But it's an interesting phenomena to see.

Yeah, well, I can tell you my first cube mate that I had at my first job ever was – he was actually a graduate with a degree in English. And so working on software was just his day job. He was actually a wannabe author. And so back then, self-pubbing was a whole different thing 20 years ago than it is today. Yeah, yeah. Seems like it's a lot easier nowadays to do. So it is. And I actually provide assistance to – my wife's actually an author and has published seven novels. And so half of them are published with small presses. The other half are self-pubbed. Well, that's interesting. So when you're writing – when you're writing any type of your books, do you, like, hole yourself up in a little hobbit hole somewhere? Like, how do you, like, pay attention to it? Or do you have – do you not have that problem? Can you just, like, write and be interrupted all the time and everything's fine? How do you set up the environment to get stuff done? Well, I would typically – my best writing would be I would write at night when everybody was asleep and no one was disturbing me. And when I found out that that paradigm is absolutely required when you're recording video. Oh, yeah, yeah, yeah. Because I've – we got – I have three kids. They're eight, six, and three. And so there's just no way I can sit there and write a tech chapter with five – you know, an interruption every five minutes. Yeah, yeah. I've noticed that the kids are not very good at trusting that this concept of could you just wait? They're like – and basically their answer is always no. I can't. They'll wait about 30 seconds, and that's what they – that's what waiting is. Yeah, yeah. They don't practice the asynchronous sort of thing. Very highly synchronous, these kids. Lots of blocking required. Well, that's great. That's a good overview of it. And, you know, I'm always – I'll have to go get a copy myself to read through it, and then maybe I'll – you know, I always try – as I try to do here, I try to get people to explain to me what reactive and backflow is. And I think so far you've given me the most simple explanation. You just basically expanded it out into a bunch of words that I already know, which is great.

But it would be even better to see an example application. And, you know, just as a side note, I've been looking at several example applications recently. And, yeah, you know, it's really easy to have a simple application be as complex as you want it to be, which sounds a little weird, but it also means that, like, if you think your application is overly complex, it's probably pretty normal, right? Like, everyone gets upset about how complicated their apps are. But you look at all these applications, and they have a lot of things running around as well. So the sort of, like, mean, if you will, of complexity seems pretty ordinary across projects. I don't know if that's true or not. But anyways... Well, I think it's a good microcosm of real software development. It's like you just start with something simple, and it keeps expanding and getting more complex to solve this and that and the other for sure. Yeah. All right. Well, great. Well, thanks for being on. Well, as always, this has been Pivotal Conversations. If you want to get the most recent episodes or peruse the back catalog, you know, maybe it's late at night, and you've got time on your own, and you don't need to write or make a video. You can just sit there and listen to old episodes. You can go to SoundCloud.com slash Pivotal Conversations. And every Thursday or so, we post formal show notes at Pivotal.io slash podcast. And with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.