I based it on real situations that I found over time, like, how do I do this? How could I use technology with Django, with other technologies such as Redis in order to build a recommendation engine, for example, I thought many people would have the same questions, so I thought, okay, it would be great to teach Django and at the same time showing this different real world use cases that could apply to many different domains. Hello and welcome to the Pibytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Baldeboz. If you're looking to improve your python, your career, and learn the mindset for success, this is the podcast for you. Let's get started. Welcome back, everybody, to the Pyewites podcast. This is Bob Baldebos. And today I'm not with Julian. He is attending family and doing other stuff. He has FOMo because I have a very special guest today, and that's Antonio Malay. Antonio, welcome to the podcast. How are you doing? Hello, Bob. Thank you for having me here today. It's a pleasure to be at Pilot's podcast. Pleasure is ours. Thanks for joining. Yeah, we have a lot of stuff to discuss. We'll get into it, but, yeah, maybe for people that don't know you yet, maybe you can introduce yourself to our audience. Sure. Well, I'm Antonio Mele. I'm CTO of Nucoro. We build a technology platform for financial institutions that allows them to build detail, savings and investment products for their clients. Awesome. And you're also the author of. Yeah, I'm the author of Django four by example. So this is the fourth edition of my book, and I try to teach Django by example, just as you do with py bytes, with Python close to our hearts. Yeah. And I was honored and happy that you guys reached out to have me do the forward of the edition that just came out. Right? Like last month or so? Yeah, only. Yeah, last month. End of. End of August. Yeah, exactly. Great job. It's a 700 page, very intense, and we'll get into that a little bit, but yeah, maybe first of all, so you're not only author of the book and Django Inside out, you're also new Coro. That's correct. Yeah. So maybe tell me a bit about what you guys do and how your day to day looks like. Sure. So Nucora is a technology platform for financial institutions. We try to democratize access to investing by building the tools that the banks and asset managers use to create a scalable business model for the investment products and that allows them to lower the minimum investment for clients to get a wealth management service. If you have ever invested or got some that you saved that you wanted to invest, you will see that there are not so very good products out there and the bank always tries to sell you their funds, et cetera. And also access to private banking is very difficult to get because it's basically reserved for high level individuals. And that's why we create these tools for allowing the financial institutions to automate the whole process and then offer a service that the average Joe can use in order to invest and make the money grow, just as clients of pride banking solutions do. Interesting, interesting. So you guys saw a market need and jumped in and automated and made it accessible to anybody, right? Basically there are many things coming out in this space. It's amazing because you see there's a lack of automation. There are asset managers managing billions of funds and they are doing it with a couple of excel spreadsheets and sending orders manually. So you see there's a lot of room for improvement there. And also making it accessible to everyone so that everyone can invest like $200 and bit by bit add some more to their portfolio and doing a planning for retirement, et cetera. So I think it's super, super interesting helping also people with their achieving their financial freedom and that's what we work on. Awesome, awesome. So how did your role change over the years? Because you're a co founder, right? Did you also go a bit more from the coding side to the more operations business side of the process? Yeah, well, it changed a lot. And you know, in a startup you have to do a lot of different things together, different roles depending on the moment. And as we started, my role has been changing from one phase to the other one. When we started Nukoro, we were like, I think three back end engineers at the time. And we initially created a robo advisor for the UK market. This is an automated investment management service and we built a platform from scratch. So with this platform we need to build functionalities to manage investment accounts and all the other feature related to investing, like tracking performance, doing all kinds of forecasting calculations. And then we also get integration with brokers and custodian banks. This is where the money sits in order to reconcile investment account information, et cetera. And at the beginning I was coding every day using Python, Django postgres redis. We use Django rest framework a lot, and we came up with the first functional versions of the platform and then I moved over to managing and growing the team. I spent a lot of time doing interviews, hiring engineers, and I think we have built a very solid team. We have an outstanding technical team now of more than 20 engineers right now. And then I move over to product, working with product defining features, dedicated, a lot of effort aligning business and technology. And I think this, yeah, this has been the evolution of my role. And of course they're setting up the operations function, setting up the security function. Banks have very high security standards, so there's a lot of work related to cyber threat detection, infra management, I think I did a quick course on security topics as well. And then. Well, I currently divide my time between product engineering, defining new product features, working on the roadmap, and also sales on strategic deals. So I don't code anymore at Nucor, but I do code on my own projects as well. Nice, nice. Sounds a lot on your plate and pretty varied, so that's cool. So you mentioned Django. Not surprisingly, I don't think that's coincidental because I. You already were doing Django before, right. And I think it might have had an influence, your experience on what the stack looks like. And so I was wondering, we have actually two questions, but we might as well combine them, right? So how did you get into Django? I mean, why did you pick Django as a framework as opposed to other frameworks like flask or whatever? And how do you use it at the company? Is it like a monolith or are you moving into more like a microservices architecture? So yeah, it's actually two questions, but yeah, I'm firing the both questions your way. Perfect. So I found Django back in 2006, I think so, yeah. I kept using it from then until today, basically, and I felt in love with it. I remember at that time I was coding websites in PhP and I was on my second year of university and I was looking for Ruby on rails tutorials at the time. Ruby on rails was getting popular back then, and I saw a comparison between Ruby and Rails and Django in some blog, and I really liked what I read about Django. And I saw like, for example, Ruby and Reyes was taking this more monolithic approach where the project was the application itself, whereas Django had this project and apps were approached where you could have different applications that you could use radius in different projects. And I really liked that. So I started working with it. And that's one of the things I really like about Django. Then some others are the MTV pattern, where the controller is the framework itself. I really like the way Django has been designed. And I know it might be a bit overwhelming at first because the framework provides you with so many different tools. Like you start using Django, sometimes you start building a functionality and you realize, oh, this is something that framework provides me. So then, so it might feel like it's a very big framework, but on the other side you get to pick and choose what you want. And you can always choose, I want to use this part of the framework or not. And you have the full backend system for storage engines, database, etcetera. And then you have this flexibility, you don't have to buy everything. It's not like other frameworks where it's all or nothing. And you have the flexibility to decide what you want to use, the framework where you want to do something different. You can build your own backends, you can build your own database routers. So I really like that approach. That's what amazes me as well. With Django. Yes, it makes a lot of decisions for you, but it also lets you pretty free to write your own code. It seems to hit a sweet spot there, right? Exactly. It's a perfect balance, I think, between functionalities and flexibility, batteries included, but with flexibility. Do you use it at the company? So we have built different apps that provide these features. We cover the end to end investment journey for an investment product. So from client onboarding to portfolio creation, portfolio management, executing trades, et cetera. And that's why we divided functionality into multiple apps. So some apps provide core functionality and other apps are dependent on them. But then we have other apps that are more standalone and provide other functionalities that are not so tied to the core applications. But the logic is clearly divided into different apps, and each app exposes a set of API endpoints and generates certain events, because we have built a generic event system based on Django signals, so that we not only provide a rest API, but also an event driven API where you can define webhook endpoints to receive your notifications. So we use general rest framework a lot, and we also built a notification system so that events trigger notifications to end users that are sent through different channels with priorities. And then we use as well websockets, for example. We took advantage of ASCII as well, and asynchronous capabilities built into Django and the recent versions in order to provide front end applications with real time events. And yeah, that's more or less how we use it on the core. Nice. That sounds actually a lot like microservices architecture, like different services and they communicate with each other through restful rest APIs. Nice. Yeah, we don't deploy them as microservices, but we'll keep this person and we're now separating certain services. We are starting to migrate into a more microservices like architecture. But the design pattern of project and apps has been very helpful for not building too much complexity and being able still to isolate the different functionalities. So you talk about the Django structure of one project and multiple apps. So would this be multiple apps living in one Django project, or are there multiple Django projects with each other? Are you finding in practice that you would reuse an app among projects a lot? I've not really seen that much. We're not doing that much, but we like to keep the function. So there is one full Django project, and in each app we're building certain functionalities so that we can potentially launch that app as a microservice later on. So we kept the science simple so that we can then decide which apps make sense to separate from that main deployment. Makes sense, yeah. Okay, cool, cool. So to shift gears a little bit, going back to the django and you teaching Django. So Django, and there's been around for quite a while, there's a lot of resources and books. So what made you decide to write a Django book? Tell me about the story. What motivated you so well? I was writing, I come from writing many tutorials. I remember many years ago, I was writing PhP tutorials and Delphi tutorials back then. And I also wrote some Django tutorials at Django es, which is certainly not online anymore. But then at some point I got a request from my editor to write a book about Django. And they also wanted a very practical book. So I thought, okay, this is something I would really love to do. And I took the opportunity and created an outline of the features that I wanted to showcase and examples that I found in my career, because I want to make it super practical and real world examples. So I based it on real situations that I found over time, like how do I do this? How could I use technology with Django, with other technologies such as redis, in order to build a recommendation engine, for example. I thought many people would have the same questions, so I thought, okay, it would be great to teach Django at the same, and at the same time showing these different real world use cases that could apply to many different domains. So it was a combination of publisher actually reaching out and wanting to have a practical book. But yeah, that form of teaching also resonated with you. And then at that point you already had a lot of projects from your experience you could actually use. Right. So it was a nice combination there, right? Exactly, exactly. Nice, yeah. And that's of course close to our hearts, building practical projects, because you can teach this in a very theoretical way. But yeah, you have to build something to really grasp it. What really stands out from the book is all the related stuff you managed to pull in cash. Redis Docker. Yeah. It's not just a django. Right. I remember one of your first podcast episodes was about tutorial paralysis. I know you love the topic. Yes, I talk a lot about that. Yeah. And I think, I also think the same. There are so many tutorials out there, but it's just something very specific. I mean when it comes to something different, you don't know how to, how to build, how to continue right after tutorial. So I, in the book I try to explain some more simple things, then some more complex stuff, and also integrating them with other technologies, and then I think it feels more easy to understand how you could build different things and gives you more options. And that's why I tried to not building as a simple tutorial for the nice case scenario, but also trying to solve problems that you would face in the real world. Yeah, yeah. And with that additional complexity you cover so much more. For example, in chapter six there's this whole, what was it? Bookmarking? Widget. Yeah. Which, okay, we want that widget, but yeah, here we have to stop the python. We cannot solve this with Python anymore. So you introduce a whole bunch of JavaScript there as well. Yeah, yeah, it's a really cool app. That was a big challenge because at some point I was like, I'm not writing a book about JavaScript, right. So I have to keep the JavaScript as a JavaScript code, as simple as possible. I'm not, not starting explain a lot of different, a lot of different concepts about JavaScript, et cetera. So it was challenging itself, trying to keep it as simple as possible. And for example, in all the examples I also skip anything related to CSS, et cetera. I provide the static files for readers to download them, add them to their project, so that I don't spend half of the books playing CSS and adding CSS styles everywhere. So I always try to keep it simple and easy to understand and try to find the right balance. I'm also focusing on Django, but as well, like you said, whenever there's something where you need another tool or that's what happens also in real life. Right. So I try to do my best covering all the real scenarios. Yeah, yeah, no, I think you hit a really good balance there. You definitely explain a lot and explain it well, but not everything. Right. There's definitely also sometimes a little bit of an exercise to the reader to, to figure stuff out, but that, you know, that's what happens in real world developer life. Right? So yeah, going back to the challenges. So one challenge then is to scope the book, to not go to explain, but not to go into too much details. Although the JavaScript on chapter six is quite ample and the book overall turns into 700 pages, I think you get to this critical 900 page limit that you cannot really go over. Yeah. Another challenge I can really see, which it did really well, is keeping up to date. Right. Because Django has gone from 1234 in relatively short time and yeah, you managed to get a fourth edition out there. You introduced Django channel, so you're keeping up really with the developments of the framework. I guess that's a challenge as well, right, to keep the book up to date and kudos because I know you put a lot of effort into that. Yeah. What other things about the process of writing a book poses challenges, I think. Challenges you said, because Django developers kept doing releases faster and faster. So that was a bit of a challenge for me. But as well, it's an opportunity to learn about new features. And for example, as mentioned, Django Channels was something I really wanted to dig into and I took the opportunity when I was updating the book and adding more, more content to it. So I think it's also good to take advantage of the new versions and then learn something, something new and then show it to other people as well. But yeah, there are many challenges because, for example, I use a lot of different third party applications, third party apps, packages, and then you realize, okay, that package is not compatible with the new Django version. So either it might be compatible just before you publish the book, or maybe not, and you need to create a fork and fix it, or sometimes there's something that is deprecated and you want to find another solution, but then the next chapters build stuff on top of the functionalities that you created with that package. Right? So you try it, you have to dependency hell, right? Exactly, exactly. So you have to find the best solution so that it adds value to the reader and it's up to date, it follows the new, the newest trends and you're explaining something that is useful. Right. So that's always a challenge. Yeah, I think you mentioned this before to me, like with the Docker chapter, the deployment chapter, the last chapter, when docker compose and different services depend on each other. So for example, you can only launch the web one when the db one is available, otherwise it will crash. I was reading that chapter this morning and I think you found a creative way to solve that. Is it readyscript? Yeah, this is this batch script to, that's pretty to wait for the other service to start and then use only start service when the other one is already running. But yeah, the problem is like how do you explain that in an easy manner and you don't get into more complexity and more in depth explanations about all the topics and then losing the focus on the main topic. Right. But that's also something you probably didn't anticipate. Right. So you're writing this chapter, supposedly docker compose just going to work and then oops, it's not. And then you have to find a workaround and plan for that. Right. There are many, many things like that you feel like, okay, this chapter is easy because I just need to update this and that and the rest makes sense, et cetera. And then you find something that you didn't expect and have to deal with that and still making the chapter, not adding 100 more pages to the chapter and still providing a good solution. Right? Right. Yeah. Cool. So yeah, there's quite some complexity in the book. I mean a lot of comes from your experience doing this work for quite a while. Right. But yeah. What is your approach to learning new technologies? Any tips there? How, yeah, you can learn faster as a developer? Well, I think you always need a challenge. Like I always learn new technologies when I needed them. So I didn't learn Django for the sake of, okay, I need to learn a python Webfrong. I had certain needs for developing web applications and then I came up, said okay, with Django and Django makes sense to solve these problems. Right. And fits well for those problems. I think you always need a challenge and if you don't have one, you can come with one very easily and then using a technology that makes that you think makes sense to solve that problem and you will find out whether that's the best option or a different one. So not just learning for the sake of it, but coming with, approaching it with program and asking yourself, okay, whenever you see something and you think how do they do that? And then you start digging into how to build that kind of functionality and you see some comments about this with that technology, some documentation, then you start learning about the technology itself. And I think one of the most important things is to understand how all the different modules are coupled together. Like for example, with Django might be overwhelming at first sight, but then if you get to understand how Django processes requests and how the user models that the user is in you, you render a template with a context. If you understand basics, then everything else will be much easier to understand. If you are just copy based code, you will not know what's going on behind the scenes. But yeah, I think you always have to approach it with real problem that you need to solve and then you will really understand why that tool allows you to solve that problem. Yeah, because with the documentation, or even your book for that matter. Right. Sometimes it's hard to really grasp the topics if you don't have that real world exposure. So yesterday actually, somebody asked me like, how do you study a book like that? Right? And I'm more like, well, usually it's like a combination of building apps and ideally something that you care about. You have some skin in the game, some motivation, and that's just beyond what you're capable of. So that poses a challenge. And then I read these books kind of in tandem, right? Because when I play with it a little bit, it makes way more sense when I then read it. Right, but there's that playful element to. It needs to be there. But yeah, I guess in your case it's far beyond that because you also, to really understand the technology, do you read a lot of source code? Do you debug libraries or is there any advanced stuff you need to do to really get to that point? So I like to read source code to see how things are really built and many times realize, okay, they took this decision or that decision and you understand how they set up the whole application. I really like that because then, for example, if you look at the Django packets and you say, okay, that's a cool way to have this flexibility to build one on another backend. And then you dig into it and you see how they actually build it and the dynamic reports, et cetera, and then you can apply to other, to other real world scenarios, right? And for example, the way I still use my book as well as reference, because sometimes I forget things, right. And I think you should read the book, understand it, do the examples, etcetera, and then build your own stuff. And then you can always use it as reference when you think about something, okay, there was something in the book about this, and you read three, four pages and you get the inspiration that you need to solve your problems. That was similar to something else that was featured in the book. Yeah, awesome, awesome. A question we totally skipped. I'm going to ask it now. Class based or function based views? This is a hot topic, that's why I bring it up. So I love function based views because historically, well everybody used fashion based views in Django and I think class based views have a lot of advantages as well. But I think it depends on the case, right. Because sometimes like for example if you use Django rest framework where you have to create crack views around models, there is super useful to use class based views. But then maybe you need to build a specific view that is very, that has a lot of logic or it's not something you would reuse probably then you can build a function based view for that, right? So function based views, one side, they're more explicit, right. Because you can't follow the cold flow, whereas with class based views you might end up with class six or eight mixings and then it's really difficult to follow the code flow, right? Yeah. Talking about reading source code, that's what I always have to end up doing with class based views to go to the source to see what the full inheritance tree is, you know? Yeah, exactly. And when you work in a large engineering team and you're working with class based views, it's very easy to start having hundreds of mixings for different things. And sometimes you find a mixing that is very similar to a different mixing than somebody else built. So you have to be more careful with that. And of course it makes sense that you can use inheritance a lot and you can take advantage of of that. But it's true that then you get to some other cases where you say I need this view where I have forms and another form that depends on the previous form being validated and you know, and that's very specific, like do you create a class view for that or a mixing that you will reuse, but then you find another case that is slightly different so you end up with four different mixings or you build specific views for that. So I think it's easier to learn with function based views and then if after then learning using function based views to switch over to class based views and then you understand where they fit and what you can then use them for, then you can use both and in each case decide what's better, right? I think, I think that's the best approach. Yeah, yeah. I think it's important to learn about both of them, but in practice I'm definitely inclined towards the function based, like explicit. Explicit is better than implicit, right? Exactly. I think class based views, I'm not a very big fan because it's difficult to, to keep them readable. Right. You start adding mixins and it is super difficult to follow the execution flow. Yeah. Because in python you can do multiple inheritance, but then yeah, you need to have the order of the parent classes correctly with the mixins and it's very easy to switch them around and then get undesired behavior. Yeah. Okay, cool, cool. Yeah. A couple of more questions. What adjacent skills are important for a Django developer? There are many in your book, but yeah, maybe you can list out two or three non negotiable skills for the Django developer. Okay, so I think you should know about databases. Like you should understand what happens behind the scene when you use the Django Orm, how many times you end up with thousands of queries just to get some basic information, just because you don't know what's going on when the queries are being executed, etcetera. So understanding how the lazy execution of queries work, when you can force it for set, where is it to execute and what happens? In the sense, I think it's very, very important then I think it's very useful to understand redis as well. I think Redis is being used by many people just as a cash, cash solution or as a key value store, but I think it's like a swiss knife. You have a lot of different data types that are not so commonly used, but are very useful for many use cases. So I think it's a very good combination using also redis with django and as well celery, because whenever you have to work with synchronous tasks, that's something that comes up very quickly when you start building applications and being able to create tasks and having workers to execute them, et cetera. That's also very useful. And of course, understanding HTML JavaScript, I think it's very useful when you understand the full stack that you're working with, and you might be an expert in Python Django and just understand the basics of JavaScript, but then you understand how your APIs will be used and you will understand the struggles of front end user using data and transforming it, etcetera. So I think it's very useful if you also understand the rest of the stack as well as configuration options for deployment, et cetera, optimizing the django settings for performant server deployment, et cetera. Nice, nice. That's good to know. To focus on these maybe APIs as well. As you mentioned, using APIs. I think that might be a good one as well. Exactly. I see a lot of. Yeah, it has to be. You have to learn about APIs, know how to build how to consume APIs both. And then when you know how your API is used, then you can provide better functionalities to it. Right. Like for example here at Nucoro we built, for example, we used processql and non relational data fields in order to allow to store additional fields to an entity. And then we wanted also to allow to filter by those fields to do search lookups, et cetera, the API. And then you provide a lot of flexibility around your data model. And for example, that was something we discovered by using our own APIs and finding out what we would need in different scenarios. So I think understanding how your APIs will be used is very important. Awesome. So any new features coming in? Django and or python and or the ecosystem and or the industry overall, you can pick. What are you excited about where we're going with all this? Well, I want to play more with asynchronous support in Django. It's been added to the OrM and I have some examples with channels in the book to create a chat server. But I want to dig more into asynchronous execution and build some other stuff. I think that's really interesting. And then working in finance, I'm very interested in the adoption and evolution of blockchain technology, cryptocurrencies. That's more in the tech space, not so much in the python space, of course, but I think it's something that still is infancy and I find it very interesting. I also want to dig more into that, building a simple blockchain with Python and using it for different purposes. Yeah, that's quite fascinating. Definitely want to look into blockchain a bit more as well. It seems a very interesting technology. Yeah, there's a lot of buzz around it nowadays. Right. But under a lot of projects that probably will disappear in the next few years. But I think there will come many use cases will come up that are very useful for where blockchain fits very well. Awesome. So lastly, is there a recent win you want to share on the podcast or a book you're currently reading that you want to recommend? Okay, I will share a book I started reading how to be a stoic. I got personally more interested in the statism topic and I know you talk a lot about mindset as well. I think Julian loves it in this podcast so I hope to have more things to comment with Julian. Yeah, that's right, Ali. All right, awesome. We will link that book in the show notes. Yeah, any final shout out before I let you go? And thanks for sharing all this. This has been awesome. It was great to be at the Pivise podcast. Thank you for having me here today, Bob. And I'm pretty impressed with what you're doing with the PBM program and getting everybody to learn python in a very practical manner. So happy to be here and join you today. Pleasure is ours. And yeah, we're very impressed as well what you're doing in this space and your book. Everybody should check it out. Django by example, fourth edition, we'll link it below, will give you a very firm grasp of Django. So yeah, thanks for writing it, thanks for keeping it up to date, and thanks for sharing all this wisdom today with us on the podcast. Really much enjoyed. Have a good day. Cheers. We hope you enjoyed this episode. To hear more from us, go to pibyte friends, that is Pybit es friends, and receive a free gift just for being a friend of the show and to join our thriving slack community of python programmers, go to Pibytes community. That's Pibit es community. We we hope to see you there and catch you in the next episode.