Michael Herman was the co-founder of RealPython and now runs TestDriven.io. He has deep professional experience with both Flask and Django which we discuss along with static sites, microservices, and which framework makes sense for beginners.
Will Vincent 0:06
Hello, and welcome to another episode of Django chat. In this episode, we're joined by Michael Herman, the founder of test driven.io. I'm Will Vincent joined as always by Carlton Gibson. Hi, Carlton. Hello, hello, and Michael. Hey, Michael. Hello. Thanks for having me. Yeah, happy you could come on. So the title of this episode is going to be from flask to Django because you've spent a number of years writing production level flask code and recently switched over to Django. So we're gonna spend a lot of time talking about that switch and differences you've seen between the two frameworks. But first, can you give a quick background on who you are and how you got into programming?
Michael Herman 0:41
Sure. I'm a engineer slash educator from Denver, Colorado, and yes, I am the founder of test driven IO, which I will talk about in probably just a bit. So my backgrounds I started web development in the late 90s, competing with a friend in Missouri We were building PlayStation websites and eventually moved on to the LAMP stack and got into hardware during high school. my undergrad years is spent at University of Missouri, started in computer science, moved to philosophy ended up getting a business degree. After undergrad moved to New York, got a job at Yahoo, ended up getting transferred out to San Francisco, quit Yahoo, got a master's degree started working at startups got into a lot of Python web scraping testing. And that's what led me to co found real Python with another friend of mine. So real Python is a
Will Vincent 1:43
what's a Python tutorial site right there. That's what it was initially when you were involved.
Michael Herman 1:48
Yeah, so yeah, real Python. I started as like a Kickstarter, basically for teaching practical Python learning by doing experiential type learning Python. This was back in 2011. We ended up kickstarting two other courses, a flask web development course slash web fundamentals course and then a more advanced Django course. And so, again, the philosophy behind it was learning by doing experiential learning. There was nothing really out there at the time in terms of beginner courses that had that experiencial learning philosophy. And so, yeah, we kick started real Python. I got into Morens tech education that way, taught full stack JavaScript for a couple years at a boot camp called galvanize.
Will Vincent 2:40
And that was in Denver.
Michael Herman 2:42
Yeah, that was in Denver.
And so after galvanize, you had to deal with a bunch of imposter syndrome, can I build anything other than just a basic crud app? So I went back into the industry focus mostly on flask development and at the same time, Started test driven.io which focuses on teaching mid to senior level developers how to build, test and deploy micro services to AWS.
Carlton Gibson 3:11
wowza. Got a big tail. So what we're using back in the 90s, you said you started off? Was that Perl or PHP? Or what?
Michael Herman 3:20
geo cities?
Carlton Gibson 3:21
Mo goods? Yeah, trumped up PHP.
Michael Herman 3:27
Just straight HTML and CSS. Yeah. Good. tables.
Will Vincent 3:30
Yeah. Good. So maybe. So let's talk about test driven, because that's built with Django. And maybe, what was that process like? So without, you know, going too deep dive into flask? I mean, for listeners don't know, it's a micro framework with Python. What kind of struck you and you'd use Django before but I think had been a couple years since you'd use it on a large project. Is that right? Yes. How did how did you choose Django and how did you find that transition to be
Michael Herman 4:00
Yeah, so I mean Django, it allowed me to move a lot faster than with flask. So I wanted to, you know, build a full stack web application with server side templating. And so with all the pieces there that you get from Django out of the box, I was able to move a lot faster with Django over flask. Well, you said you'd been doing full stack JavaScript development, as well. So you've been using, presumably, some kind of micro framework in the JavaScript world like, express, express or
Will Vincent 4:32
write Express?
Michael Herman 4:34
Yeah, instant. Yeah, node and express. Yeah.
Will Vincent 4:37
So did you give that a thought to do to use them, I guess to get to Carlton's point?
Michael Herman 4:42
Well, I did have a transition back to Python after galvanize. So yeah, I did teach full stack JavaScript, worked on the dev team there and that was a big Rails app and they had some micro services and though to express that I worked on but after, after leaving galvanize, I worked for a company And that was all flask. And so I got back in the flask that way. So really the decision for test driven kind of came down to flask. First Django for me,
Carlton Gibson 5:09
right? Because you're in the Python mindset at that time.
Will Vincent 5:12
Yeah, yeah. So when you started with Django, do you recall, had things changed since you last use Django cuz they've been a number of years? Did you have a sense that there'd been a bunch of changes, like migrations and stuff? Or had you use those before you switched over to JavaScript in flask?
Michael Herman 5:29
Yeah, not much had changed, actually. Yeah. South. The old migration system, you know, is now into the, in the core. Yep. Which is nice. But I was already familiar with how the ORM worked in the data models and whatnot, so there wasn't that too many changes. And I think that's really nice. With Django, it's, it moves a little bit slower than I would say, some other Python frameworks, but because of that, it's it's, it's much more stable. Mm hmm. Like the core o RM operations. have been unchanged forever, right? So you know, if you if you know how to build a model and you know how to filter and you know how to do those core operations, that's the same from from day one, to now. And so and there's all this other stuff that you didn't know about, not that you didn't know about. But there's all these annotations that all this search now and when did that appear?
Will Vincent 6:19
So given your background in teaching, now that you're fully in the Python world, when if someone comes to you and says they want to learn web development, but they haven't worked with a framework before? How do you think about the choice of flask versus Django, which often comes up for that for that beginner?
Michael Herman 6:35
Yes, it sort of depends on the end goal I made if I would say it regardless, in general, regardless of whether someone's wanting to learn flask or Django, I generally start or I recommend that they start with flask. So flask is just a great tool for learning web development fundamentals in general, like HTTP, routing, that sort of thing. And those things are common. You know, across all web frameworks. So I think also, one thing that I often overlook is that the source code for flask is much smaller. It's much easier to read. And so diving into the source code of flask is really nice. You can see what's going on behind underneath the hood.
Will Vincent 7:21
Yeah. What about for API's? Are you using an API with test driven? Or are not at this stage?
Michael Herman 7:30
I have a couple endpoints. Yeah, but behind wouldn't call it. I wouldn't call it an API.
Will Vincent 7:34
Have you done I just wanted to ask, you know, flasks, especially for you know, what, how do you build an API endpoint flask can do that in a couple lines of code. Yet Django rest framework is very elegant. I just wondered if you had a chance to play around with DRF. Recently versus doing it kind of raw with with flask.
Michael Herman 7:54
I have looked at DRF. So one of the courses on the test Serving site is a Django course that deals with Jango channels sold asynchronous, fun and angular on the client side. So I'd kind of dive deep into DRF to really understand what was going on there, especially with the authentication.
Will Vincent 8:18
Sorry, are you for local development? Are you using Docker these days with test driven? Yes, yeah. And how do you find that had you? Because I think you'd been using that at work beforehand, or even, you've been using Kubernetes. Is that correct?
Michael Herman 8:32
Yeah. Yeah. So yeah, Docker, you know, it just simplifies the development process. Yeah, there's definitely you know, hurdles in the configuration and 12 factor with settings and whatnot, dot m files versus hard coding, right, you know, environment variables in the Docker compose file. But you know, once you sort of figure out how Docker is working, and figure out how that you want to Get those environment variables inside of your container, then it just makes the process a whole lot easier.
Will Vincent 9:05
Yeah. And are you? What are you doing for deployment? You've used a host of services that we've talked about offline before.
Michael Herman 9:12
Yeah, I'm using Heroku. So it feels like 2014.
Will Vincent 9:18
And are you deploying with with containers on Heroku? Or you're just doing it like Percy file away? So yeah, right now just using get and the slug compiler. So I am in the process of moving everything over to the Docker deployments. But right now I'm just sticking with the slug compiler. And then, and then so why did you make that choice? Because clearly, you know how to set up a server and do it, you know, on a VPS if you wanted to what, how did you think about that choice of using Heroku or you know, a platform as a service as opposed to Infrastructure as a Service given that you have experience with both?
Michael Herman 9:54
Well Heroku gives you everything out of the box. It gives you logging and monster monitoring. If you can set up a cron like jobs, all these different services that I would have to set up and manage and up, up, grade and maintain my own Heroku just all does that all for me, so I can just pass it Django and green unicorn or whatever, and then set up all those different extensions. And, you know, I'm good to go.
Carlton Gibson 10:24
Yeah, that's good. That's the saving, right that, you know, it's all very well, maintaining, I don't know, you chrome file, your crontab file, but like, that's not the most fun in the world now. And it doesn't take long per se, but there's what that job and then there's the other job, and then there's the other job, and then there's the other job and all those add up to more than your Heroku.
Will Vincent 10:44
So how did you what was the process for you know, prototyping and then building and I know you're still working on test driven. Can you talk about how you sort of prioritize features and you know, again, because I think this is a trap sometimes when you go from working in a production environment you, it's easy to want to over optimize everything because you're just familiar with it. But there still needs to be some sort of process to getting to this optimized point across the board. And maybe we can talk about some of the optimizations on Django site. But do you recall kind of what was the kind of the MVP? And then how you layered on complexity? Because I think you you initially had what a Jekyll site before. So you weren't starting from scratch with the test driven domain. Right? You already you knew you were going to have traffic?
Michael Herman 11:26
Sure. So yeah, I did start with a Jekyll site, just a static site generator and was selling the course is just a PDF. And I wanted to move to more of like an interactive, you know, web application where the end users instead of downloading a PDF, and then you know, never coming back again, always have to come to the website and login and go through the website. It's, it's more interactive for them. And it's also, you know, customers will continue to come back and I can upsell them and whatnot. So, yeah, I basically wanted to port over the main function. analogy from Jekyll and then from there I needed to add on, you know authentication, author authorization and then some sort of payment provider to, you know, handle
Will Vincent 12:09
payments. And then what are you using for the payment provider? So I'm using stripe for that I had you thought about because I get these days with Braintree as well I think stripe with the two Was there another one you considered at all? Or was the stripe the the one you thought you'd go with?
Michael Herman 12:27
Yeah, so you know, there's stripe, there's Braintree. There's a whole there's a number of different startups that have been built on top of stripe, right? So I was thinking of, you know, sort of abstracting that out. So I did initially start with one of those gumroad and that was I was using that when I was just selling the PDF but now that I'm not selling a digital download anymore, I moved away from gumroad
Will Vincent 12:51
got it and then for for email because you must have both transaction and potentially marketing emails. Did you set up Sort of any async process for that? Or maybe you could talk through how you said, how you set that up in a Django context?
Michael Herman 13:07
Yeah. So I do have, you know, transactional emails for password or email confirmation. And also, you know, for others other sorts of things. So, yeah, I'm using Django our cue, the extension for Redis queue. And so to get the process out of the request, response handler, just puts the job into the queue and then have a separate process constantly looking at the queue is their job is their job. There's a job of grabs the job and then sends it to send grid and then sendgrid will send out the transactional email.
Will Vincent 13:44
Got it? Carlton, I've dominated the discussion. Are there any questions that come to mind for you?
Carlton Gibson 13:49
Yo, just on the queue choice, I mean, like, so the big beast in the room is salary. Right. And I just wondering why you chose our queue over Sorry. I'm You know, I've got my own views there. But I'd be interested to see what you've got to say,
Michael Herman 14:05
I've used our queue pretty extensively the past like three or four years, and I was just familiar with it. I haven't touched celery in a little while, I didn't really need all of like the robust like, scheduling and retrying that I know that you get from celery. So it was just sent basically sending transactional emails. I have a couple other things I'm using queue for But yeah, I mean, just from a functionality standpoint, I didn't need everything. Yes. Celery gave me exactly.
Will Vincent 14:35
Okay. Brilliant. And what about, again, because I think this is a great chance for listeners to go through the list of, you know, building out from scratch, a Django site, you know, with the knowledge that you have was there, you know, testing. So, how did you find, I guess doing tests with Django? Because it's been a little while and then are you using any additional services as well to test your application?
Michael Herman 14:57
Yeah, the testing pyramid has really changed. For me, the past few years, so testing pyramid, you know, most of your tests are going to be unit tests and you have some functional tests. And then at the very top of the pyramid you do a bit of and then are browser based testing. So a testing tool came out a few years ago, years ago called Cypress. And that's for browser based testing. And so it's really actually good for testing out, you know, asynchronous type single page applications. So I would say Selenium is great for server side templating type applications and page refreshes, it doesn't handle all the asynchronous type stuff really well, Cypress handles that really well. So what you get out of the box with Cypress is basically, in the end tests are browser based tests that are a whole lot less finicky, and a lot easier to write. And so because of that, the testing pyramid is for me, I write mostly browser based tests and unit tests. I kind of steer clear of like a lot of the functional tests at this point. Interesting,
Carlton Gibson 16:00
the what would you call a functional test in that context then because, you know, obviously, like running a browser automation, that's obvious. And then unit test, you're probably, you know, testing individual bits of logic, and how would you what would you call a functional tests? And how would you run them?
Michael Herman 16:15
Yeah, I guess a functional test in I'm probably what I'm meeting more is like integration tests. Okay. So like, just if you have to hit a database, or you have to test like multiple functions, or, you know, multiple views or whatnot,
Carlton Gibson 16:29
various components working together.
Will Vincent 16:32
Yeah. So related to testing, I assume you're using some form of continuous integration as well.
Michael Herman 16:40
Yeah, so I'm using semaphore ci for them.
Will Vincent 16:42
And then why did you choose? choose them? I guess,
Carlton Gibson 16:45
is that a hosted service? Is that
Michael Herman 16:47
Yeah, Yes, I was.
Will Vincent 16:48
Okay. Because there's what these days there's there's some before there's Travis or circle. I think GitHub has their own one and data maybe get lap has their own. What was it about semaphore that stood out to you? I'm not sure I don't remember other than you have to pick one and you know, right. But are using it just I deployed using it for deployment as well. Right? Not just Can you talk about just the pipeline of incorporating it, I guess in the project?
Michael Herman 17:15
Yeah. So yeah, I'm using it for both ci and CD. So continuous integration and continuous
delivery, slash deployment.
Yeah, I guess in terms of the reason why I picked that is the way that I'm running my Cypress tests in, in the CI environment. So I'm not running the Cypress tests inside the Docker container running the Cypress tests outside the Docker container, and then you're testing against the Docker container and for or the web application that's running inside the Docker container. So for whatever reason, I couldn't get that to work exactly right on Travis circle, and I could get it to work on some for I have been meaning to maybe switch over to get lab just because I like having the The source code and ci CD and whatnot built in to get lab and get lab has faults for secrets as well. So I like that, you know, one stop shop type platform. So eventually I'll probably move over to or move over to get lab. But for right now semaphore is just working for me. And so there's not really a reason to switch. No. And once you get one of these things going, it's really easy just to keep it going. Right. Sure.
Will Vincent 18:26
Yeah. Yeah. And then are you doing? So local production? Are you using a staging server as well?
Michael Herman 18:35
Yeah, I do have a staging environment. Yeah.
Will Vincent 18:37
And then just for maybe, since you're a former educator for listeners who aren't familiar with that flow, could you talk about why why you would set up a staging server and how that how that flow plays out. So you do a local change? And then, you know, then what happens before it gets to the live site?
Michael Herman 18:53
Sure. So yeah, I do a form of like the feature, branch workflow, sort of like a get Flow type approach. And so you know, I create a new feature branch, I make some changes locally, I test it out locally, I do a commit, push it up to GitHub, that'll trigger some before. So before then, you know, run ci. And if it's on for, if, if it's running against just a feature branch, it won't actually do any sort of deployments to staging or prod. But as soon as I do a merge request, another
Will Vincent 19:32
merge to master
Michael Herman 19:35
merges develop, another build will kick off. And then as soon as I merge that into develop, that's when another build will kick off. And as long as that passes, then it'll deploy to the staging environment. So the reason why I do that is I just want a place to be able to test it out on Roku. And just to make sure that what's happening on my development environment locally is The same as or as as close to what it will be when it's in production.
Will Vincent 20:07
Right? And then. So then do you manually go and check before committing to production from staging? Or how do you make that leap?
Michael Herman 20:17
I'll do some like manual tests. I mean, everything is really covered by Cypress to that point. So I don't really need to worry about it too much. But I'll just do like one last visual check, or you know, if it's a blog post or something like that, I'll have I'll send the link to the blog post author and you know, they can take a look at it before it goes live. So just little things like that. I like to be able to view it before it goes live.
Will Vincent 20:37
Right. And so are you. You mentioned authors, test driven? What started with just you right, but now, what's what's kind of the master plan, right, because I know you have another course on there. And are you you're adding blog posts by other contributors as well?
Michael Herman 20:53
Yes. So test driven is starting to scale I am starting to bring on more content creator So whether that's tutorial authors or course producers so the other course on there right now is written by a friend of mine Jason parent, he is writing another course right now. It's basically the the current Jango channels course with react instead of Angular. I'm breaking up the large monolithic course the microservices course by myself right now. So that's going to be like four or five different courses hopefully by the end of the summer onboarding a couple other course producers right now as well. So just looking to scale that out. I'm doing some design work right now with some other companies and and yeah, hopefully the platform will have a couple more courses and have a nice makeover by the end of the summer sounds Oh, go.
Will Vincent 21:51
And then are you still gonna stick? Do you think to the per course pattern or how do you you know, as a content creator, how do you think about it? Cuz I think about this obviously all the time as well subscription versus kind of pay as you go, given that you're now building out a platform,
Michael Herman 22:07
haven't really thought too much about that. Probably just continued use pay as you go. I setting up subscriptions, that's gonna be a lot of development work. So yeah, I'd say, if I wanted to go that route, it probably be, you know, three to six months worth of development to change that workflow. Oh, wow. Okay. Well, also, I'm not working on test driven full time. And yeah, that's part of the reason why that would take a long time.
Will Vincent 22:33
Got it? I guess. So I think there's maybe a couple more things just on the stack itself. Again, I think it's such a great chance to look at a newly built stack. What are you using for? I don't know for DNS, are you using Heroku or using something special to handle DNS?
Michael Herman 22:50
So it's a combination of, it's actually Frankenstein together. I hate DNS. So it's a combination of dreamhost CloudFlare Heroku and nella phi was in there for a bit. And I got nullify out of there. So I'm using CloudFlare Heroku and dreamhost. This is just for resolving your your hostname, right? Yes. Right? Well, okay.
Will Vincent 23:18
Well, so why, you know, why do you have three like what, what what was not working that caused you to add these all in, right? Because if I'm you know, I'm a new developer and I read, you know, one of your tutorials or Django for beginners, I just I can put a site up with SSL on Heroku. Problem solved, like what's not solved when you're actually at a production level,
Michael Herman 23:38
because I bought the domain name through a different company and then started with nullify deploys, and then went to nullify DNS and then wanted to move to Roku. And so I transfer the domain name once and screwed up DNS for about six hours. transferred it back. It was Yeah, I don't know. If you want to go down this route, but it was it was definitely a nightmare.
Will Vincent 24:02
Yeah, no, just at a high level, I think
Carlton Gibson 24:04
it's just but when Dennis goes wrong, it really goes wrong. Right. Yeah,
Unknown Speaker 24:07
it's
Will Vincent 24:10
fair enough. Well, speaking of. So monitoring, right? Are you using any sort of, you know, it's app specific monitoring or uptime monitoring? There's a whole, you know, suite of tools for that. Are you using any of those as well?
Michael Herman 24:25
Yeah, for uptime monitoring, I don't remember I'm using the uptime robot or something like that. The platform doesn't really go down at this point. So which has been nice I think I've gotten like one email in the past like six months about the site like going down but it was immediately back up. So might have been a false negative but or something other. Yeah. So yeah, uptime robot, using combination of New Relic, century and log injuries and you All that comes from the Roku add on Roku add ons, and then post Postgres and Redis. Yeah. So are you doing some kind of APM
Carlton Gibson 25:12
application performance monitoring? With?
Michael Herman 25:16
Yeah, I'm using like new New Relic, right, I guess New Relic is handling that. Yeah.
Carlton Gibson 25:20
And that gives you like a breakdown of the request time where it's spent in different parts of your code and things like that.
Will Vincent 25:28
Actually, Heroku gives you a lot of that information, does it? Like the straight Heroku dashboard will give you a number of nice key metrics like that for logging, because we were meaning to do an episode on logging on the podcast. We haven't yet what like how deep are your logs? What sort of stuff are you logging, right? Because this is sort of an extra step on top of your tests. Or can you talk through how you how you thought about logging, in terms of building out the you know, Django side?
Michael Herman 25:56
Yeah, whenever I'm doing a try, accept or try, catch That's generally I'm throwing the logger in there, you know, certain things like, you know, transactions in terms of stripe payments, some throwing logger in there. Let's see where else, it's kind of I haven't really thought too much about that. And that's, you know, definitely something there's a backlog for tickets to clean up the logger. Going back to the application performance monitoring, I'm using scout for that. That just hit me. So that's another add on that you get from Roku. And century is used for like the exception monitoring. So that's that's anytime an error is thrown bubbles up, then century will catch that and
send me emails and whatnot.
Will Vincent 26:45
Yeah, so it's quick. I mean, it's quite a lot of just for, you know, listeners to get a sense of all these tools, you know, for on the spectrum, a relatively straightforward application you're using, you know, well over a dozen tools third party tools, right, either free or paid. To help you monitor and process just pretty standard web app flows, emails and all the rest.
Michael Herman 27:07
Yeah, and I am on the free tiers for all those monitoring services, they come out of the box with Roku, and see Roku just allows me to be able to just focus on my application not have to worry about infrastructure at all. I would say Heroku gets expensive, quick, but I'm a single person development team. I'm not gonna hire a DevOps person anytime soon. So I'm happy to pay whatever they tell me.
Carlton Gibson 27:32
Yeah, that's a great question. Right? That's that because, you know, what's your hourly rate? What's your How would How much would it cost you to hire a developer to to do these things? How much do you save and these platforms are the services the the sort of the you do the sands You know, that's quite expensive, but all the things you don't have to do or what did you save and you know, we talked to Tom Dyson, and you know, he made the comment, you know, these from them. Yeah, and wagtail thing and he The point that, you know, the if you really do the maths and you include the dev developer time, you can scale these things quite a long way before they they become an economical,
Will Vincent 28:09
and I believe, towards Xbox, which, you know, major, major agency, they use Heroku for most of their client work, actually,
Carlton Gibson 28:18
yeah, for exactly these reasons. Yeah.
Michael Herman 28:20
Yeah. I mean, that's one of the reasons why Python came into existence was like to optimize for the development time.
Will Vincent 28:26
Yeah, you know, exactly. So I, there was one other thing I've noticed on your site you have for search. This is relevant because time suppose episode comes out, it'll be announced that I'm giving a talk at Django con on search. Can you talk about how you went through that process of search? And because search is such a deep field and you've got a nice search implementation? How did you go about that? I
Michael Herman 28:51
think from the end user perspective, it may look nice, but it's very, very janky. So I'm not doing anything Fancy in there. And actually, I haven't looked at that code in like three or four months. So
Carlton Gibson 29:03
I've, for me, it's kind of interesting because you know, this this kind of pressure, Oh, you've got to have Elastic Search or whatever, you know, you don't have to have electric search a lot of the time, you know, the, you can do it with your database. And for a lot of sites, that's actually good enough.
Michael Herman 29:17
Yeah, I'm really just doing straight filters on like the content itself. And so I guess it is doing a very janky flavor of Full Text Search, but I'm not taking any advantage of any of like the full test, full text, full text search features that you get from either Django or Postgres.
Carlton Gibson 29:36
Well, okay. Interesting. Got it. And yet, from the end user perspective, it's quite effective.
Will Vincent 29:43
Yeah, well, it works fine. Is it just an end user? You know? I don't you know, nope, no complaints.
Michael Herman 29:49
It's Yeah, it's a very, very basic search. I have complaints.
I'm a bit close to it. But yeah, I mean, it's a just a very, very basic search. There's not really any word to it. So if you search for Docker, and really it's just going to like sort that based on like the date. So, you know, there might be a blog post with 15 instances of Docker, there might be a blog post that comes, you know, after that, that has one hit for Docker. And it's going to, you know, sort that based on the date. So it says,
Carlton Gibson 30:20
I've been like concerned about how many different instances of Docker showed up showing up. So it's a very, very naive search. Okay. But you know, that mean, if it's good enough for the size of the content that you've got, and it says the users and that's not I think this is really interesting, just because it's a problem that we see all the time in technology. We're always tempted to gold plated, we're tempted to do the thing, which is the absolute best engineering standards when it's a lot of times it's not needed.
Michael Herman 30:50
Yeah, given an unlimited amount of time. I would definitely, definitely focus on it. And I do get a lot of emails. people asking not directly about search, but in indirectly in the sense of like, do you talk about this in the course? Or do you talk about, you know, that and or where do you mention? Blah, blah, blah? And in my head, I'm like, we'll use the search. And then I'm like, well, the search isn't all that great. So maybe I shouldn't tell them that.
Will Vincent 31:15
Okay, yeah. That is nice, I guess versus, uh, well, I guess you can search a PDF as well. I was gonna say you can point them to search and they can, if they have the course they can search through and find it, though. I guess if they don't, if they haven't purchased the course they only get what the first, the first couple parts or chapters. They don't get the full thing. So that would probably be why they would ask you that question.
Unknown Speaker 31:36
Yeah, that makes sense. Yeah.
Will Vincent 31:38
Yeah. So something else you're involved in, which we haven't mentioned yet is your conferences. I mean, you speak a lot. But then also, pi Colorado is coming up this fall, which you're involved with. Do you want to speak by that at all?
Michael Herman 31:52
Yeah, so pi, Colorado is early September. So that's September 6, seventh and eighth. The normal the main conferences good To be the seventh and eighth, that's Saturday and Sunday, and then there's a workshop day. that's similar to the Python workshops that's going to be on Friday, the sixth. So I'm the Program Chair. So I am organizing all the talks, all the speakers and all the workshops.
Will Vincent 32:16
Wow, that's quite a bit of work.
Michael Herman 32:18
Yeah. And so the next weekend, I'm actually getting married. And so I'm kind of September is gonna be a little crazy for me.
Will Vincent 32:25
Yeah. And do you know, are you gonna be able to attend Django con, which I think is later, later that month?
Michael Herman 32:32
I don't know. Depends on what things look like maybe mid September? Yeah, probably not going to make a decision on that for a while.
Will Vincent 32:40
So we've talked a lot about Django, maybe just to circle back to what we started with. What you've worked with so many different frameworks. You've mentioned flask, rails Express, how do you think of, you know which one to choose? Like, what are some cases where, you know, flask is very well suited to something versus rails or maybe express or there's some examples that come to mind where you would pick a specific framework for a specific task? Or would you start with a language?
Michael Herman 33:06
Yeah, I mean, I would start with definitely the language and figure out, you know, which which language you're going to be coding in. Because if you're in, you know, if you're coding Ruby, you're probably not going to want to use Django, but not sure how to answer that question. But yeah, I mean, some of the some of the use cases that I look for, in terms of last year's Django, I look at probably project size, I look at the type of application. Also look at the the size of the team. Let's say the application type is is is a big one. So you know, website versus a web app, versus a web service. And I know that not everything is is cleanly bucketed, you know, into those three different things. But let's say a website is is just static generated. A web app is a full stack, web application. It could be you know, single page application and it could be something thing is server side templating. And Web Services just could be just just a basic RESTful API. So I like to think think in terms of those buckets. And so if it's a website, that's just static generated, probably not going to use Django for that. So if it's a web app, Django, you know, is great for that. I think the jam stack over the past couple of years, the JavaScript API's markup, sort of the natla phi stack, the serverless type type stack is kind of eating away into sort of Django is dominance as a as a web application framework. And then sort of a web service. I like to use either Django or flask for that.
Carlton Gibson 34:45
Yeah, I've built. I spent a lot of time playing with static site generators and even jam stack types things. I found myself constantly coming back to Django. Why? Because every time I was like, oh, now Your web form. And now I know natla phi does this kind of thing now, but it's like, oh, now I need a web form. And now I need all that now. And it was like always the case where I just had saved myself a little bit of time, setting up my Django app and writing my first template view by just slapping up HTML page. But then I had to go and retrofit it all every time. And it was like, You know what, I give up on that and found myself more and more dislike, I'm not going to experiment with this static site generator for this project, because it's just gonna cost me time in the mediums. Well, apparently you I mean, that's also given that you know, Django so well, once you know any exactly whatever framework it is, you can kind of make it do what you want. And then yeah, do you need to read, you know, relearn the wheel? No, exactly. And using like, you know, an alternative micro framework. It's like, it's always more time for me digging in the docks. To learn the other API then is to just use Django, but again, I guess that's familiarity.
Michael Herman 35:54
Yeah. Yeah. I mean, that's, that's a good point. I don't I don't think it's ever a good it's ever a good time. When you're when you're working on a project to experiment with something new, just go with it you're familiar with it's, it's easy, it's a lot easier to estimate how long it's going to take to complete something and, you know, maybe dabble here and there and some with some toy projects outside like a, you know, a project that you're doing for work or freelance or whatever. But that's a good time when to like spin up like, hey, how can I actually recreate, recreate, like this full Django web application using nella phi or flask, right, and serverless and whatnot. So it's always worth giving every new framework around and seeing what it does and seeing it's the way he approaches things. Because he, you know, makes you a better developer overall, because you know, different approaches and different styles and Yeah, exactly.
Will Vincent 36:44
Well, so maybe as a concluding point, the title of your course is microservices. With what flask react Docker, how do you think about microservices? You know, when do you because I know you worked with us professionally, but in terms of free or For test driven, did you think about a microservices approach? Or where do you? How do you how do you think about micro services? Just to give you a broad question, when appropriate, like what are the what what, what do they? What problems do they solve? And what problems do they cause? Because, you know, they're typically used in larger companies. You don't necessarily usually see a startup, go with microservices.
Michael Herman 37:24
Yeah, I mean, to relate that back to Django and flask, the the 2018 JetBrains, developed Python developers survey came when that came out. flask was actually slightly head in terms of popularity in Django. And I don't know if that's, you know, just because that's, you know, JetBrains users in general, but I would say that's more of the web development industry and the trend toward the smaller frameworks to microservices and the serverless platforms the past four or five years or so. And, you know, I guess going back You know, directly to your question microservices, I mean, they're, they can be good. They're not, they're not like gonna fix. You know, like, if you have a lot of problems in your company, if your development. If your development teams are very siloed, it's not going to fix that by any means. You definitely need to address some of those softer skills first, but microservices can help. It can help scale certain pieces of your application that get a lot of traffic that can help with you know, isolating, you know, bits and pieces of your application to deep decouple it from other processes and whatnot. So that can run independently, it can be scaled independently. So I know microservices is kind of a it's obviously a trend these days and you know, there's a lot of you know, questions about it and you know how to go about it and micro, micro front end frameworks or whatever like has been a trend on Twitter the past like week and that's the Is bonkers to me, but maybe next year This time, we'll be talking more about, you know, micro web micro front end frameworks or you know, whatever people are called micro front ends, I think is the term.
Will Vincent 39:11
Yeah. Yeah. But the sort of the guide Oh, sorry,
Michael Herman 39:15
I was gonna say so like the problems that you have with micro front ends in the same micro services, micro back ends or whatever. Is that the core state? So how do you how are you maintaining state across those applications if you if you need to, and you know, ideal world, you want to have to do that you could be able to scale and deploy all those things. And you wouldn't have to worry about shared state, but there's going to be a certain amount of shared state, and that's a huge problem. Well, and I think you you had said at some point, Michael, that you thought one of the things about micro micro services is that it shifted the complexity away from the individual developer kind of upper level to the
Will Vincent 39:55
I guess the maybe the sorry, the Site Reliability engineer. Do you recall saying that? Is that something you want expand on? Because I thought, yeah, you can you can quote me on that? Well, it's, I, it struck me when you mentioned that because it did seem like you do have this issue of, if you, you know, it doesn't necessarily solve the problem, but it moves it from the hands of an individual engineer, who may have, you know, who knows how many years of experience they have maybe kicks it up in a large site, where you do have entire teams around Site Reliability and deployment. And, you know, they can maybe are forced to handle some of those issues, rather than giving that power to an individual engineer who can do something silly in a monolithic framework setting.
Michael Herman 40:35
Yeah, I mean, smaller code bases are easier to work with. And so if you break apart your monolith into smaller code bases, you're gonna have in theory, you're gonna have less bugs, you're gonna be able to move faster product likes that developers like working on, on things like that. But then the problem is function calls now become network calls. And so you have to deal with that. At that. Infrastructure level. So you're shifting that complexity away from the individual developers more towards the DevOps, the sysadmin, the SRP team
Will Vincent 41:09
well, so as we come to the end here, we've talked a lot about how you build test driven with Django and your thoughts on flask. Do you have any concluding thoughts on, you know, developers looking at, you know, flask, or Django? And how to think about that choice?
Michael Herman 41:22
Yeah, I think that you really need to look at sort of the application type versus time that the amount of time that you have to develop something, and there's gonna obviously be some trade offs there. Think about what you can absolutely not compromise on and then base your decision on that. And based on that, sometimes you'll choose Django other times you'll choose flask, and that doesn't make one better than the other. I mean, they're really used to achieve the same things building web applications, they just have very different approaches or the means are different.
Will Vincent 41:56
Yeah, exactly. And I goal of this podcast is not to just relentlessly beat the drum on Django, but to try to be honest and open about its strengths and why people choose other things and just let people have that choice but at the same time, not fall into the trap that I think a lot of beginners see experienced developers do, which is just to say, it depends all the time. So I appreciate that you've been, you know, sort of backed up the choices you've made and building out test driven Because ultimately, a choice has to be made your many choices even for a basic website.
Carlton Gibson 42:27
Yeah, like you go to a database, you got to choose your web server, you've got to choose your hosting, you've got to like these. You gotta choose your language, you've got it.
Will Vincent 42:37
Anyway, at some level, you know, it just becomes you just choose what you're used to, as we've mentioned before, but it's also worth knowing what else is out there and also having if someone says, Why did you use x y, Zed say, Oh, well, you know, sometimes it's good to reevaluate your decisions because things, frameworks do change. New features are added. But hopefully Django will just stay mature and just keep getting more and more awesome.
Michael Herman 43:00
Yeah, Jango definitely decreases the amount of decisions you have to make same with a Roku.
Will Vincent 43:05
Yes. Yeah, any
Carlton Gibson 43:06
any opinionated thing it gives you gives you some guide rails and like, you know, give you rails. So,
Will Vincent 43:12
yeah, and especially if you're a solo developer in a small team, you you, you don't have the luxury of making all those little decisions. So, thank you so much for joining us. If listeners want to reach out to you what's the best way, Michael?
Michael Herman 43:26
So Twitter is probably the best way at Mike Herman. You can also reach me via email at Michael at test driven.io.
Will Vincent 43:34
Great. Well, thank you so much for taking the time and it's been really educational to hear how you've built out test driven with Django.
Carlton Gibson 43:42
Yeah, thanks for coming on the show.
Michael Herman 43:43
Yeah, much. Appreciate it. Thank you. Okay. Bye.