speaker 1: Well, hello everyone. I am radollav, CEO of haxsoft. The way we position ourselves is your development partner beyond cold. And I'm coming all the way from Bulgaria, from Sofia to Prague. It's not that far, actually, sand a half with a plane, but we are located in Bulgaria and it's my first time in Prague. And to be honest, for the last two days I've drank more beer than the last two months. Apparently it's a thing here. I asked the waiter that whether should I order a beer for lunch? And he was like, just brought me one. And it's actually a great honor and privilege to be talking at europython. Actually, this is going to be my fifth talk at the europython. It started way back in 2017 in Rimini. After this, Edinburgh, as they say, Basel and dubli ting. And this is actually indeed a great privilege, because every time I need to do a talk for europython, I try really hard to prepare and give and provide value for all of you. So it's worthwhile your time. And actually, last year in Prague, I was about to give a talk about keeping Django up to date, but unfortunately I couldn't make it. So come our vpof engineering did give the talk on my behalf, and he did a fantastic job. And this year, I'm here and go of the stock again, practical, pragmatic, provide value. And one more thing make you think about things. If you walk out after 45 minutes thinking about the topic that I'm going to present you, then my job is done. And as a context of this talk, we've been building software products for the last ten years or so, primary to spython and Jango. And we've seen a lot of things and worked with a lot of clients. And there .
speaker 2: are actually .
speaker 1: several different versions of this talk. Initially, I was thinking about doing a live demo or to be safe that things are not going to fail, show snippets of cobut. One morning I woke up, fortunately, and I was live demam o is going to be boring. And there is a bigger story that I want to rant about. And I think it's going to be of more value to all of you here. So it's rather going to be a more general talk oriented or software engineering and software craftsmanship, and it's also going to include Jango, but you will see when. So what are we? At least this is how we at hasoft back home define ourselves. We are kind of a cross section between software engineers and software crafpeople ople. And for example, for me, that's why I love doing this job so much. And I love running a company that does software development because sometimes you need to be doing engineering job and sometimes it's a craft. And the mixture of it makes it really, really appealing. And what I've seen for the last, let's say, few years is that we as software engineers and software craftpeople ople have taken a more idle role. This is bad because it's generated by chaggpt, is basically the last time I'm going to use it to generate images for slides. Wasted too much time. It should say requirements, but it couldn't get it. So we kind of reduced ourselves to waiting for the requirements to come so we can start working and start producing software. And the standard line of thinking, or at least from our point of view and talking to people, is requirements are pushed down and only then we start working. And for like the last ten years, we did a lot of different software projects. And one thing that we learn is clients always come with either they think they have an idea what they want to build or they have a set of product people. And product people are extremely important. And I'm not throwing shathat. Anyone is just going to be a little bit ranty. But so far, I haven't seen a project that starts with a clear idea and won't undergo changes during development. And there's a fun anecdote that happened to us last year. We started a new project. It's a new product, a new client that came with around 30 pages for specification. We extended it by doing initial talks to kind of like 50 pages. And the client was, this is all there is, trust me. I mean, what more do we want to what more do we want to to do? And of course, given our experience, we were quite doubtful. But the thing is, you cannot express this doubt straight away because you want to work with this client and you want this client to actually be paying you and working for you for a long time. And for the first month, we were slightly diverging from disdisorder is. And by the end of the second month, the initial specification was like of no use because we moved we pushed the product forward, not by doing more specification, but by building something and evaluating it as we go. And yet this initial specification saved us a few months. And this is quite important. And so far, my worldview has it's all about iteration. I was thinking how to put a game of thrones quote here, like, chaelos is alder, the climis all there is like software development is a chaos, and iteration is all there is. And so far, iteration is like the only thing that helped us ship meaningful software with users on production that made money for the business and was actually being we had this conversation internally about what are the tools if we want to move a product forward, like we want to build a software product that's actually being used. And usually if we talk about the product team, we have engineers, qas product folks, ux ui folks and so on and so forth. And usually the answers are, well, we need wireframes screens and designs. We need product requirements. We need to be talking to the users. Yet there is a fourth two that is as powerful as the other tree, and we are not using it as much. And this is my talk today. And of course, this 42 is actually sitting down and building a prototype, a proof of concept or a spi solution. And I want to use this specific terminology because it describes the intent of what we want to do. And we found out throughout our experience that this is just as powerful as the other tools. And as software engineers and crossspeopwe can build something usable, something clickable, something that's actually working, get feedback from it. And that's extremely powerful. Yes, you can get feedback from wireframes. You can get feedback from designs, but sometimes you really want na get feedback from something that's actually working and being cused. And this is extremely powerful. And I don't I'm not sure we are using this tool as much as we need to. And in fact, the way I see it is when we start developing, the requirements kind of fold and fall into place. Like in quantum terms, if you observe a particle, you force a state for that particular particle. And this is how I think about sometimes you need to force those requirements into cobecause. You cannot be hand wavy with the coyou can, but it's not going to end up well. You need to be quite specific. And again, this is quite powerful. So sometimes you need to build something in order to figure out what needs to be built. And this is a diagram that we show to a lot of our clients when we start a new project or when we join an existing team. And we need to help them with whatever needs to be helped. And what I say, Hey, we usually start with some kind of whole fidelity wifriends, like something thrown around just to confirm this is what we are building, right? And this is like the target market. And this is those are the outcomes that we that we want to achieve outside of make a lot of money. Like this is those are the software ter outcomes that we want to achieve. And then we usually move and make a step towards actual software, some kind of a proof of concept that's clickable and usable, and we can get feedback from it. And once we get feedback, it might be a good idea to once again, step back from coding and do some more wireframes like you screenshots from from the existing software and then once again, do an iteration and build it as a proof of concept again, again. And at some point, the end goal, or at least what we try to communicate, is we need to find the source of truth for the thing that we're building. It might be a pretty big system with tens of engineers and hundreds of engineers, and then this will consist of many smaller parts that we're going to focus on. But we need to find a stable ground, a like solid foundation, or, as we say, a source of truth, which we can iterate on top of it. Because if we iterate on an assumption, then we are we're going to go a few steps down the road and suddenly we cannot move forward because we've made too many assumptions. And this is to share my experience and to encourage all of us to be more proactive software engineers and cratpeople ople, because we can use our knowledge and skills to push the product forward. It's not only the job of a product person. We can also do this. And the way I see it here is we can have some kind of a rotational leadership for who pushes the product forward. Sometimes it's going to be the product folks, and they have their foot in the business as well, and they need to make product decisions based on the business insights, and that's important. Sometimes it's going to be the ui and the ux folks because they can have a good idea and they can sketch something quicker so we can talk and decide what we're going to do. But sometimes it's us, the software engineers and the software across people that, Hey, let's build this and evaluate it after it. And this, at least for me, it's a good thing to have. So where was I? Now, when we talk about building proof of concept, so everywhere cpoc is going to be a proof of concept, just a short version. We usually think we need to hack something together, or at least, again, I'm sharing my worldview. This is what I thought for quite a long time. I need to hack something together. All bets are off. There are no limits. I have been given a Green light to do a proof of concept. And we tend not to use our primary tools and strengths like, Hey, we need to do a proof of concept that we are going to throw away after this. Great. Let's use go. And again, I'm not throwing shade at any technology. I'm just sharing experience from my my own career. Let's use go or let's use rust or something else. Let's see what note has to offer. And here comes the most important slides of the entire talk. Why are we building this proof of concept? Why are we doing this prototype? And we need a clear answer in order to know what kind of decision we need to make about the technology. And this is a conversation that I'm having quite often with the folks that I work with, either on the client side or either. On our side, we agreed that for the next two, three weeks, we going to build a proof of concept, okay? And this proof of concept is to push the product forward so we can make better decisions. After this, why do we want to use something that we have not as much experience with? And we are going to be spending quite a lot of time just figuring out how to run things. So if the answer is to push the product forward, then it's better. And those are the next slides to stick to comfort. Yet this does not mean that we should always stick to comfort and always avoid new things. But sometimes we need to build something in order to learn something new, and this is just as important. And sometimes we need to build something with a different technology to get a new perspective. If we build something with, for example, rust, we might get a different perspective of building the same thing that we could have done with just Python. And this is really, really important to be discussed and for everyone to be aware. Why are we doing this right now?
speaker 2: And if we are not focused .
speaker 1: on the why, we might really easily get distracted. And I'm sharing this to someone who's guilty of that distruction the line. This looks like a Husko angle is not a good line. Like if you are chasing to push the product forward and to develop a software for the business, then stick to comfort. Sometimes we do need to get the Husko ango and see what we can learn from it. So again, if we are to push the product forward, stick to comfort. This is if I can like aggregate my experience for the last around almost is going to be 15 years soon. This this is going to be it. And a more cynical look on things. I don't know if you have heard this or said this, the best piece of software is the one that you don't have to build, because if you build it, you need to maintain it. And it opens a lot more work to be done over a longer period of time. And sometimes if we can avoid building a software and get paid for it, then that's really, really the sweet spot. So a short article by Dan McKinley, choose boring technology, is something that resonated with me some time ago when I read it. The slides are going to be shared. You can check it after this. But the general idea is that sometimes we need to choose boring technology that just works because our goals are to build something that pushes the product and the business forward. And that's okay. And we should not get drawn into chasing the new shiny thing every time because this opens a lot more work that needs to be done and maintained by someone else, usually not us, down the road. And this really resonated with me, and I highly recommend you reading it. You might not agree with everything, which is completely fine. It's just something that I usually share around our internal channels. And of course, I don't want to throw shade on things. If there is a team that's comfortable with Django and there is a team that's comfortable with, for example, php and huavel, then those teams, given the context, should stick to comfort. And we've had this during our work, sometimes distinis on php, and we are maintaining it. There's a really, really big urgency. Need to rewrite it, but it's not worth at the moment. It does not make business sense. And of course, there's the meme that you can pretty much run doon everything. This is the YouTube video for how many potatoes does it take to run doand? That's the idea for that. You can build everything with anything. And comfort should be determined by context and by the team that you are in and that you have. All right. And the second most important slide is we need to make a distinction between time spent working on the framework and time spent working on the proof of concept and the product. And what I mean by this, if we are to pick something new because we have the urge for it, and we are curious, and we will find joy in using something new, we might find ourselves spending quite too much time working on the framework. How are we going to do migrations? How are we going to deploy it? How are we going to run tests? How are going to or where are we going to put the application code? How are we going to model our data? And all of this is really how to say, I love doing work like this because I find it challenging and rewarding. But sometimes it's not pushing the product forward and it's not bringing the notorious business value. And we need to be aware. And every time we are moving towards pushing the product forward and we catch ourselves spending time working on the framework, we kind of stop and say, Hey, we want to do this. Let's find other ways to do this, because it's interesting. But now let's focus on working on the proof of concept, because we want to get to a place where things are validated, we got the feedback, and we can move forward. And Jango mentioned the combination of Python and Jango is great for building proof of concepts that can push the product forward. And I would even say in the Python ecosystem, it's for me. Of course I'm biased. One of the best options that you can pick Python. I had few slides to tell you why Python is great at the europython conference. But Carol, the keynote speaker from yesterday, did a great job, much better job than my slides explaining why Python is a good choice. So if you haven't watched the keynote, go and watch the keynote. I believe the recordings are going to be posted to epython YouTube channel at some point. So Python is great. Python is very pragmatic, and that's why we're using it. And Jango by itself is a mature. And when we use the word mature and technological context like this is a mature tech, we often mean this is boring in a on, like we don't want to hurt someone's feelings. Like when someone say, Hey, jungle is a mature framework. It usually means jungle is a boring framework. And being mature framework, it can actually reduce your time spent working on the framework, because a lot of people over a lot of years have spent time working on the framework. So we can take the framework and build a proof of concept with it, which is something that I realized like last year. And with Jango, we can figure out the data model. Now we going into more technical stuff, I have time dream. We can figure out the data model. We can figure out the actions between our entities. If we are to sit down and make a more generalized, more abstract concept of building software, we usually have a data model, and we usually have certain actions between the entities from the data model. And when we combine all of this, and when we include, like various other systems that we communicate with, we have a piece of software that we can use. And with jungle, we can figure this data model out. We can figure the actions between the entities and we can actually show something that can be interacted with. The biggest problem when working with non technical clients is that they need to be shown something because showing a proof of concept running on a terminal, they're like, I believe you, but have no idea what you're showing me. And at the core of our product, we have a data model. And usually, again, this is something from experience, this data model that models the software that we want to build is expressed via a relational database. Now we can, of course, use other databases. But here Jango goes hand in hand with a relational database. So we stick to comfort, which gives us a relational model. And I want to draw some distinction between those two things. Jango or m is quite good at expressing a relational model because it's tied to its object relational mapper. It's tied to a relational database and we express a relational model with the Jango orm. And I'm not sure with how many other different frameworks have you worked with, but Jango migrations are a blessing and kudos to all the folks that created this stable, mature piece of software. I had the chance to work with quite a lot of different migrations frameworks. And sometimes it's just pain. You have to endure to this pain, but it's pain. And it's not necessarily .
speaker 2: that you need to .
speaker 1: read the code, but this is an actual example of something that we are building for the Bulgarian it ecosystem. We are curating entry level positions because this is currently a problem in Bulgaria. And we started with some wirefriends, but then we decide, Hey, let's just move to cot and let's just prototype. And this actually helped us figure out we need to what we need to build. And we were writing Django models that are not clean. I'm not going to put this in a slide for a talk for how to do Jango models well or stuff like this. It's not clean and we don't want to do it clean. We want to do something that will help us figure out what the product is going to look like, and only then we going to clean things. Yet the data model is not always closely mapped to the relational model, and sometimes the data model fits really well. So we are building something that's that big of a not as complex, fits really well within the relational model, and we are really happy about it. There's a certain happy feeling about the data model fitting really well with the relational model. And then the Jango model that we have is our data model, but that's not always the case. Sometimes we are building a proof of concept in order to figure out the data model of the product that we are building. And sometimes it doesn't fit really well with the relational database structure. Like the thing that we are modeling does not follow one to one with how we will do things in a relational database. And when this happens, implicitness steps in. And what I've seen a Young from experience is people start asking questions, why do we want to do it like this? And we get pretty defensive and we're like, let's not make this product decision because this product decision doesn't fit really well with our relational database structure as if it needs to fit. And again, when this happens, we should not try to force the product to fit our relational database structure, but rather, Hey, okay, this is how far I can get with jangle models, and I will model whatever comes out as a relational database structure. But let's not limit ourselves because this is the only tool that we have. And for example.
speaker 2: we were debating a lot.
speaker 1: should we use a graph database? It turned out it solves a problem that we had really, really, really well. And it fitted also well with the relational structure in the jangle ram. And we did a small abstraction working on the framework, but this small obstraction helped us continue building. Yet some of our data model doesn't have to fit in our gengle models. And we can use other tools that Python provide, and that's why I'm talking about Python and Jango, to describe that specific part of the data model. Now this is a personal take. Python has enough typing capabilities in order to describe a data model and the relations between it. And I would not say not enough, but rather if we want to go full TypeScript and make a beautiful set of types with generics and obstractions in our tylayer, it's a bit harder to do it with Python. And I think that's a good thing because it stops us from spending time working on the framework because we really love how this type system turns out. And that's actually really good. And I am a really big fan of how do you pronounce the name of this library? In Bulgaria, we say attorso, it's the attributes, the attributes library. I'm a really big fan of this. Now there is more than one way of doing this, and you can use whatever way works for you and whatever you feel comfortable with. Yet whenever I feel that the data model is not going to fit really well with the database structure, and it's too early to think about the database structure, I just start creating plain old Python classes and use the typing system and the define the creator from atbufrom, the attributes library. And this works really well because it gives us an interface how our data model is going to look like and how the actions between those data models is going to look like. And if you haven't tried building software like this, I highly recommend it because you detach from, I need to keep it relational, and then you can figure out how to make it relational. Now. And this is another diagram that we usually show around internally, the data model. Sometimes it fits really well with the relational model, but sometimes we need to also have a layer of code to describe the actions between our data model. And then in this layer of code, we can use the Jango orm as an implementation detail, and it can then communicate to the relational model. But the general idea is that data model sometimes fits well, sometimes doesn't fit well. Python gives us the tools to describe it and use jangle orm as an implementation detail. Okay, okay.
speaker 2: Rodo, what about ui?
speaker 1: So far, so good. Well, I haven't cracked this yet. The sentence, when you are talking to a non technical client, Hey, check this working prototype and don't mind how it looks. It's not working really well, because especially if the client is not technical, they will only focus on how it looks and not if the behavior should be something that we are validating right now and it is the correct behavior. It's a really hard thing to tell your client, I haven't cracked this yet. Good. Jango has a built in admin. And sometimes this is all dui that we need. It's actually styled pretty, I think, nicely. It's blue, it's White that it looks okay. We can team it. We can add some. We can add different looking fields to it, and sometimes we can just extend the Django admin and build our entire app there. And we've done this. It sounds a bit exotic, but of course, I cannot show you the actual screenshot because we will get sued. But we've done an entire production app where the ui is in Jango admin. And we were just using the looking feel, the Jango admin, and everyone was happy like this. This was everything we need, all we needed. Nothing more was needed. We were going to do a full react TypeScript, single copage application like the big guns, but it wasn't needed at the end. It was working. The clans were happy. And of course, something to keep in mind. The Django admin closely follows the relational database structure. And sometimes if our data model doesn't fit really well, it can be confusing, but it's quite flexible. And what I recommend is going to be included, and there are other good materials as well. There's is something called Jango admin cookbook that we share quite often. And the other thing that we read quite often is hakiberita's block on Jango admin. Again, I'm sharing to notice those are the best resources out there, and you should only follow those resources, but rather, those are the resources that we refer to most often when we have to extend and build on top of junguadmin. They work fine, and I believe there are other resources that can be used. I was really debating if I need to put a Drake meme after the whole Kendrick think, and it's kind of a weak meme now, but we will go for it. Now, the other thing is, when we talk about ui jungle templates, they sometimes do not Spark joy. Let's put it like this. And if the full power of TypeScript and reacts sparks joy, then we might be tempted to go down this road. Yet jungle templates are simple and boring, and sometimes this is all we need. What we kind of invested in is, Hey, everyone should know at least some basic tailwind. So when we have to style something, we can use Jungo tailwind, which does all the compiling, entry, building of the css and so on and so forth, so we can build prototypes that are looking at least somewhat decent. It's not going to be a nice ui ux, but it's not going to be the default html style, which is hard to follow. And of course, if you like the react way of building components, I'm a big fan of it. It really resonates with how I think about building qi. There's Jango slippers and there Jango cotton, and there are other similar tools that kind of give you the concept of a component Jango using Jango templates, which may solve your does not Spark joy issues with Jango templates. So make sure check it out. Okay, Rodo. So I'm going to use stairwind. I'm going to get some good templates. Everything's going to look fine. But what if I need a multi select or some kind of basic interactivity that does not like require a Full Page refresh? Oh, now, now, this is a big paragraph. But if you are pushing towards something that needs to if you need to push the product forward on the ui ux side of things, you will most definitely not be using Django, but you will be using the proper tools for this. And it's important to say, but if multi selecting some interactivities all you need. Few years ago, if you had asked me, I would say use jQuery again. I'm biased. I've done a lot of jQuery programming and it just works like send an ajax request or bind the clihandler and show something when something is clicked. And I know how to do it. And I know how to do it fast. Yet the folks that were not learning or working as software engineers back in the days when jQuery was a thing, now there's something that's called htmx and alpine js. And for me, and again, this is a slightly reduced and perhaps slightly cynical interview, is they are jQuery replacement. Whenever I need to use jQuery, I can now use htmx and alpine js. And it's actually neater. The interface and Jango htmx is pretty quick to set up and it's extremely powerful. And if you and I highly recommend this YouTube channel, it's linked in the slides, book bytes, 39 videos on Django htmx and alpine js. You if you spend the time watching this, you might find yourself using this powerful set of tools that can allow you to continue building proof of concepts, only sticking with Jango and only going to react or whatever you use. We use react and types the full power reacting TypeScript when you need it. So highly recommended. Htmx and alpine js are great for whenever you need jQuery. You can now use htmx and alpine js. And of course, the evergreen ink forms have never been crispier, jungle crispy forms. We've built a lot of Salter with this. It uses bootstrap. If you like bootstrap, you can use this. So a few more slides and then we'll have time for questions. Again, why is the important question here? And this is the talk that I woke up and decided that I want to give, because if we want to push the product forward, then perhaps simple and boring technologies that we are familiar with and we are productive with and we can use, not necessarily sparks joy, but might be a better decision to push the product forward. Sometimes we need to do something to learn something new and get a new perspective, because this helps us grow, and this gives us a much, much better idea for how to do something. I remember few years ago was reading some random game programming thing, because I don't know why, was a bit tired of something else. And I read about a concept that resonated. And then we used used this concept in a user interface that we were building. I was like, okay, this turned out to be a good investment of my time. So sometimes it's important to get a new perspective, but the why should be discussed. And when we make a decision, we should stick to that decision, at least for some time. For us, Django turns out to be quite powerful, and we enjoy using it. Of course, if you validate your concept, you can continue building on top of it. You can throw away it. This is another decision that needs to be made. But for us, Jango is really, really powerful for validating ideas, building proof of concepts and pushing a product forward and iterating on top of it after this. And of course, we do use other things, most notably njs. When we think it's necessary, when we think it's in, it will improve the overall direction of the software that we're moving towards. Yet we went to our phase where everything, every new project was using something new and shiny. We learned somehow the hard way that this is not necessarily the best strategy and decision. And that's why we still love Django. We still use Jango, and that's all. Thank you for listening. I hope this was valuable for some of you. It will make you think about things. I am radolph from hacksoft. We do have a Django style guide that our worldview for how Jango should be built. And I think we have a few more minutes for questions. Thank you.
speaker 3: Thank you very much reddo for your excellent talk. I have something small for you.
speaker 1: Oh, thank you.
speaker 3: If we have any questions, please move up to the microphone.
speaker 4: Yes, go ahead. Thank you for your talk. It definitely made me think and I'm gonna to take a lot from it. My previous company, we switched from spa to rendering everything in Jango, which was really great for iteration speed, but we found that the templates weren't so great. So we end up using html builder where you could functionally build out the dom tree in Python directly, so leveraging typing and being able to test it better. Do you have any experience with that?
speaker 1: I would agree that even with slippers and cotton, it's still not like the tool once. If you have used react and the tools there, you would expect more. But if we need typing and if we need more control, then we will go to react. This is the decision that we've made so far because TypeScript is prevalent in our company. But I believe people are working on the framework towards that. And we will have ten plates that will Spark joy soon, but that's our experience. Thank you, Nick.
speaker 3: Another question .
speaker 5: over there. Hello. Thank you. That's been a great talk. I want to ask just a simple question. You mentioned htmx and alpine js. Have you tried hyperscript instead?
speaker 1: Hyperscript was the thing that you used in order to .
speaker 5: extend ctmx. Yeah, I feel like like it does the same job as alpine jais basically, but it's in more tune with htmx in the way that it's like only html kind of thing. So have you tried it?
speaker 1: Just so I will be honest, when we decided we were going to use for some project htmx, we were using it with alpine js altogether because those were the resources that we watched. And we never gave this hyperscript like a goal because alpine js just worked fine for the cases that we had. So if there is someone in this room with more experience, I would be also happy to hear more. But at least for us, this is what worked, resonated, made sense, and we never looked back.
speaker 5: Right? Thanks.
speaker 3: All right. We also have a remote question from Christian back. What are the challenges you have experienced .
speaker 1: in prototyping ui and ux on top of Jango? So the biggest challenge is look and feel, especially when you are working with, for example, a startup or scale up. And the non technical business folks, they cralike they want something to look good. And this is usually the biggest challenge. But then we work closely with the uiux folks and make sure we implement it after it. But look and feel, I think it's the hardest challenge. Yeah.
speaker 3: thank you. Another question over there from the mic.
speaker 6: Hello, thank you for the great talk. I enjoyed listening it. Probably I'll repeat the previous questions, but I'll ask aniamaze most of the questions coming from ueye because probably we are most of them on the backhand side. Again, might be a repetition, but where does htmx fit into this scheme?
speaker 1: I need to input some data, click a button, and I need the table beneath the form to change without a Full Page refresh. That like this is usually where you start using htmx. Or I need a model because a lot of you iux revolves around model. Then you combine it with alpine js for JavaScript on click do something or change the value of a variable where the model is going to be opened based on the state of that variable is very closely to how you will do things with react. And this is where we use htmx and alpjs when we need interactivity and when we want to avoid Full Page refreshes. So the general flow feels much better.
speaker 3: Thank you very much. Do we have one more .
speaker 2: short question?
speaker 3: No, I think that's it. Would you give one? Thank you to rado once again.