Rapid Prototyping & Proof of Concepts: Django is all we need
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 131 | |
| Author | ||
| Contributors | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/69496 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EuroPython 202427 / 131
1
10
12
13
16
19
22
33
48
51
54
56
70
71
84
92
93
95
99
107
111
117
123
00:00
Rapid PrototypingProof theorySicState transition systemCodeSoftware developerPlanningMultiplication signComputer animation
00:45
Process modelingFinitary relationMultiplication signProcess (computing)Computer animationLecture/Conference
01:30
Hand fanSoftware engineeringClient (computing)Context awarenessProcess (computing)SoftwareSoftware developerDemo (music)CodeMixture modelRevision controlCross section (physics)Video gameComputer animation
03:17
Electric generatorMultiplication signSoftwareSlide ruleMedical imagingSoftware engineeringComputer animation
03:50
Software engineeringSingle sign-onPoint (geometry)MathematicsProjective planeClient (computing)Line (geometry)Set (mathematics)SoftwareLatent heatProduct (business)Different (Kate Ryan album)View (database)Web pageStandard deviationSoftware developerComputer animationMeeting/Interview
05:00
Product (business)Client (computing)Multiplication signProduct (business)FeedbackQuantumProtein foldingSoftwareMereology10 (number)Physical systemTouchscreenDecision theoryProof theoryProcess (computing)Data conversionSource codeUsabilityPrototypeNetwork topologySoftware engineeringRight angleProjective planeChaos (cosmogony)Game theoryIterationPoint (geometry)Software developerParticle systemTerm (mathematics)State of matterLatent heatDiagramOrder (biology)View (database)BuildingCodeComputer animation
11:07
Product (business)Proof theoryLimit (category theory)Product (business)Multiplication signView (database)Order (biology)Slide rulePrototypeEntire functionSoftware engineeringMoment (mathematics)Context awarenessDecision theoryRevision controlSoftwareBuildingPerspective (visual)Client (computing)Line (geometry)Data conversionRight angleFrequencyAngleHacker (term)Shared memoryComputer animation
16:58
Software frameworkProcess modelingCorrelation and dependenceYouTubeDeterminismBuildingData modelProduct (business)Combinational logicSoftware frameworkObject (grammar)SoftwareProof theoryFocus (optics)Computer configurationCore dumpHuman migrationMultiplication signAbstractionClient (computing)Slide ruleCartesian coordinate systemCapability Maturity ModelPhysical systemGroup actionProcess modelingPosition operatorWordRelational databasePoint (geometry)Row (database)Theory of relativityDifferent (Kate Ryan album)Axiom of choiceProcess (computing)Object-relational mappingStability theoryDatabaseRadical (chemistry)FeedbackContext awarenessCodeSoftware testingFrame problemLevel (video gaming)PrototypeComputer animation
23:46
Relational databaseOrder (biology)CASE <Informatik>Process modelingRelational databaseData structureData modelDecision theoryProof theoryInjektivitätFitness functionProduct (business)Computer animation
25:37
Process modelingMulti-agent systemAbstractionData structureDatabaseGraph (mathematics)BuildingSoftware frameworkData modelScripting languageSocial classDiallyl disulfideHand fanGeneric programmingSet (mathematics)Physical systemType theoryMereologyProcess modelingOrder (biology)Library (computing)SoftwareMultiplication signGroup actionAttribute grammarTheory of relativityInterface (computing)BitComputer animation
28:18
Process modelingCodeFitness functionData modelImplementationGroup actionDiagramObject-relational mappingComputer animation
28:59
Dynamische GeometrieSystem administratorClient (computing)Data structurePrototypeRelational databaseMobile appProduct (business)Cartesian coordinate systemWeb pageData modelEntire functionBitBlock (periodic table)Materialization (paranormal)Fitness functionField (computer science)Goodness of fitSingle-precision floating-point formatBlogComputer animation
31:37
Port scannerTemplate (C++)Power (physics)View (database)PrototypeProduct (business)Point (geometry)Software engineeringInteractive televisionDefault (computer science)Hand fanInterface (computing)Web pageKeyboard shortcutConnectivity (graph theory)Computer programmingGoodness of fitMultiplicationQuery languageSelectivity (electronic)Computer animation
34:53
View (database)BuildingInterface (computing)Drag (physics)Sorting algorithmDrop (liquid)Euclidean vectorAerodynamicsPower (physics)VideoconferencingSoftware bugProof theoryMultiplication signPower setYouTubeType theorySlide ruleSource code
35:25
YouTubePerspective (visual)Form (programming)Multiplication signDecision theoryBootstrap aggregatingMusical ensembleSoftwareUser interfaceElectronic program guideSlide ruleBitStrategy gameProjective planePhase transitionWeightGame theoryRandomizationProduct (business)Computer programmingDirection (geometry)BuildingProof theoryComputer animation
38:23
Template (C++)Software testingNetwork topologyIterationType theoryDirection (geometry)Lecture/Conference
39:11
Software frameworkGame controllerDecision theoryTemplate (C++)Lecture/Conference
39:52
Projective planeTunisOrder (biology)Right angleCASE <Informatik>Process (computing)Remote procedure callExtension (kinesiology)Lecture/Conference
41:01
Web pageForm (programming)Table (information)Process modelingoutputFront and back endsNumbering schemeLecture/Conference
42:36
Data acquisitionProcess modelingInteractive televisionVariable (mathematics)State of matterDataflowWeb pageLecture/ConferenceComputer animation
Transcript: English(auto-generated)
00:04
Well, hello, everyone. I am Radoslav, CEO of HackSoft. The way we position ourselves is your development partner, Beyond Code. And I'm coming all the way from Bulgaria, from Sofia to Prague. It's not that far, actually. It's an hour and a half with a plane.
00:21
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 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
00:42
to be talking at EuroPython. Actually, this is going to be my fifth talk at EuroPython. It started way back in 2017 in Rimini, after this Edinburgh, as they say, Basel, and Dublin, I think. And this is actually indeed a great privilege
01:03
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.
01:22
So Kamen, our VP of engineering, did give the talk on my behalf. And he did a fantastic job. And this year, I'm here. And go of this talk. Again, practical, pragmatic, provide value. And one more thing, make you think about things. If you walk out after 45 minutes thinking
01:42
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 10 years or so, primary tools, Python and Django. And we've seen a lot of things and worked with a lot of clients.
02:02
And there are actually 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 code.
02:20
But one morning, I woke up, fortunately. And I was, live demo was 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 toward software engineering and software
02:41
craftsmanship. And it's also going to include Django. But you will see when. So what are we? At least, this is how we at Hacksoft back home define ourselves. We are kind of a cross-section between software engineers and software craftspeople. And for example, for me, that's why
03:01
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
03:21
is that we, as software engineers and software craftspeople, have taken a more ideal role. This is bad because it's generated by ChatGPT. It's basically the last time I'm going to use it to generate images for slides. Wasted too much time. It should say the requirements, but it couldn't get it.
03:40
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.
04:03
And for the last 10 years, we did a lot of different software projects. And one thing that we learned is clients always come with either they think they have an idea of what they want to build, or they have a set of product people. And product people are extremely important.
04:21
And I'm not throwing shade at anyone. It's 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 is a fun anecdote that happened to us last year.
04:40
We started a new project, a new product, a new client, that came with around 30 pages of 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 do?
05:00
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 this is all there is.
05:21
And by the end of the second month, the initial specification was 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.
05:42
And so far, my world view is all about iteration. I was thinking how to put a Game of Thrones quote here, like, chaos is a ladder, the climb is all there is. Like, software development is a chaos and iteration is all there is.
06:00
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 used. So we had this conversation internally
06:22
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,
06:42
we need wireframe screens and designs. We need product requirements. We need to be talking to the users. Yet, there is a fourth tool that is as powerful as the older tree, and we are not using it as much. And this is my talk today. And of course, this fourth tool is actually
07:03
sitting down and building a prototype, a proof of concept, or a spike 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
07:21
that this is just as powerful as the other tools. And as software engineers and cross people, we 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.
07:41
But sometimes, you really want to get feedback from something that's actually working and being used. And this is extremely powerful. And 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,
08:03
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 code because you cannot be hand-wavy with the code. You can, but it's not going to end up well.
08:22
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
08:41
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 wall fidelity wireframes, like something thrown around just to confirm this is what we're building, right? And this is the target market, and those
09:02
are the outcomes that we want to achieve outside of make a lot of money, like those are the software outcomes that you want to achieve. And then we usually move and make a step towards actual software, some kind of proof of concept that's clickable and usable, and we can get feedback from it.
09:21
And once we get feedback, it might be a good idea to once again step back from coding and do some more wireframes, like use screenshots from the existing software. And then once again, do an iteration and build it as a proof of concept, again, again.
09:41
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
10:01
that we're going to focus on. But we need to find a stable ground, a 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 going to go a few steps down the road,
10:21
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 craftspeople, because we can use our knowledge and skills to push the product forward.
10:42
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 is going to be the product folks, and they have their foot in the business as well.
11:03
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.
11:21
But sometimes it's us, the software engineers and the software craftspeople 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,
11:43
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 world view. This is what I taught for quite a long time. I need to hack something together. All bets are off.
12:01
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.
12:20
I'm just sharing experience from my own career. Let's use Go, or let's use Rust, or something else. Let's see what Node has to offer. And here comes the most important slides of the entire talk.
12:41
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.
13:01
Hey, we agreed that for the next two, three weeks, we are 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
13:21
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,
13:41
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,
14:02
why are we doing this right now? And if we are not focused on the why, we might really easily get distracted, and I'm sharing this with someone who's guilty of that distraction. The line, this looks like a Haskell angle,
14:21
is not a good line. 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 Haskell angle and see what we can learn from it. So again, if we are to push the product forward,
14:42
stick to comfort. This is, if I can aggregate my experience for the last, around almost, it's going to be 15 years soon, 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,
15:01
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.
15:24
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.
15:40
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,
16:00
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.
16:22
And of course, I don't want to throw shade on things. If there is a team that's comfortable with Django, and there's a team that's comfortable with, for example, PHP and Waravel, then those teams, given the context, should stick to comfort.
16:40
And we've had this during our work. Sometimes, hey, this thing is on PHP and we are maintaining it. There's a really, really big urge and need to rewrite it, but it's not worth it at the moment. It does not make business sense. And of course, there's the meme that you can pretty much run Doom on everything.
17:03
This is the YouTube video for how many potatoes does it take to run Doom. And 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.
17:22
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,
17:41
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 way 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 we going to,
18:01
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.
18:22
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
18:41
because we want to get to a place where things are validated, we got the feedback, and we can move forward. And Django mentioned, the combination of Python and Django is great for building proof of concepts that can push the product forward. And I would even say in the Python ecosystem,
19:02
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
19:22
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 EuroPython's YouTube channel at some point. So Python is great, Python is very pragmatic. And that's why we're using it.
19:42
And Django, by itself, is a mature. And when we use the word mature in technological context, like this is a mature tech, we often mean this is boring in a non, like we don't want to hurt someone's feelings.
20:04
When someone say, hey, Django is a mature framework, it usually means Django 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
20:22
so we can take the framework and build a proof of concept with it, which is something that I realized last year. And with Django, we can figure out the data model. Now we're going into more technical stuff. I have time.
20:40
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.
21:03
And when we combine all of this and when we include various other systems that we communicate with, we have a piece of software that we can use. And with Django, 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
21:23
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 I 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,
21:43
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, Django goes hand in hand with a relational database, so we stick to Comfort,
22:02
which gives us a relational model. And I want to draw some distinction between those two things. Django ORM is quite good at expressing a relational model because it's tied to, it's like object relational mapper, it's tied to a relational database
22:20
and we express a relational model with the Django ORM. And I'm not sure with how many other different frameworks have you worked with, but Django migrations are a blessing and kudos to all the folks that created this stable, mature piece of software.
22:44
I had the chance to work with quite a lot of different migrations frameworks and sometimes it's just pain. You have to endure through this pain, but it's pain. And it's not necessarily that you need to read the code, but this is an actual example of something
23:02
that we're 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 wire frames, but then we decided, hey, let's just move to code and let's just prototype.
23:20
And this actually helped us figure out 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 Django 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
23:40
what the product is going to look like. And only then we're 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. We are building something that's not that big of a,
24:04
not as complex, fits really well within the relational model and we're really happy about it. There's a certain happy feeling about the data model fitting really well with the relational model and then the Django models that we have is our data model.
24:23
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
24:42
with how we will do things in the relational database. And when this happens, implicitness steps in and what I've seen again 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,
25:01
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,
25:22
but rather, hey, okay, this is how far I can get with Django 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, we were debating a lot
25:42
should we use a graph database. It turned out it solves a problem that we had really, really, really well. And it fit it also well with the relational structure in the Django ORM and we did a small abstraction working on the framework, but this small abstraction helped us continue building.
26:04
Yet, some of our data model doesn't have to fit entirely in our Django models. And we can use other tools that Python provides and that's why I'm talking about Python and Django to describe that specific part of the data model. Now, this is a personal take.
26:23
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
26:41
with generics and abstractions in our type layer, 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.
27:01
And that's actually really good. And I'm a really big fan of, how do you pronounce the name of this library? In Bulgaria, we say attotursu. It's the attributes library. I'm a really big fan of this.
27:21
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,
27:41
I just start creating plain old Python classes and use the typing system and the define decorator from the attributes library. And this works really well because it gives us an interface. How our data model is going to look like
28:00
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
28:21
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 Django ORM as an implementation detail
28:43
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 to use Django ORM as an implementation detail.
29:00
Okay. Okay, Rado, what about UI? 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
29:22
because especially if the client is non-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 clients. I haven't cracked this yet.
29:40
Django has a built-in admin and sometimes this is all the UI that we need. It's actually styled pretty, I think, nicely. It's blue, it's white, it looks okay. We can team it, we can add different looking fields to it and sometimes we can just extend the Django admin
30:03
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 Django admin
30:22
and we're just using the looking field of the Django admin and everyone was happy. This was everything we needed, all we needed. Nothing more was needed. We were going to do a full React TypeScript single page application like the big guns
30:42
but it wasn't needed at the end. It was working, the clients 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, and it's going to be included
31:04
and there are other good materials as well. There is something called Django admin cookbook that we share quite often and the other thing that we read quite often is Haki Benito's blog on Django admin. Again, I'm sharing, notice those are the best resources
31:22
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 Django admin. And 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
31:42
after the whole Kendrick thing 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, Django templates, they sometimes do not spark joy. Let's put it like this.
32:01
And if the full power of TypeScript and React sparks joy then we might be tempted to go down this road. Yet, Django templates are simple and boring and sometimes this is all we need. What we kind of invested in is hey,
32:20
everyone should know at least some basic Tailwind. So when we have to style something we can use Django Tailwind which does all the compiling and rebuilding 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
32:41
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 Django Slippers and there's Django Cotton and there are other similar tools that kind of give you
33:03
the concept of a component using Django templates which may solve your, does not spark joy issues with Django templates so make sure to check it out. Okay, Rado, so I'm going to use Tailwind.
33:20
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 require a full page refresh? Oh, now this is a big paragraph but if you are pushing towards something
33:42
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-select and some interactivity is all you need, few years ago if you had asked me,
34:02
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 click handler 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
34:22
or working as software engineers back in the days when jQuery was a thing, now there's something that's called HTMX and AlpineJS and for me, and again, this is a slightly reduced and perhaps slightly cynical point of view is they are jQuery replacement.
34:40
Whenever I need to use jQuery, I can now use HTMX and AlpineJS and it's actually neater, the interface. And Django 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, bug bites, 39 videos on Django HTMX and AlpineJS.
35:03
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 Django and only going to React or whatever you use, we use React and the full power of React and TypeScript
35:22
when you need it. So, highly recommended HTMX and AlpineJS are great. For whenever you need jQuery, you can now use HTMX and AlpineJS. And of course, the evergreen thing, forms have never been crispier, Django crispy forms, we've built a lot of software with this.
35:41
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,
36:01
then perhaps simple and boring technologies that we are familiar with and we are productive with and we can use not necessarily Spark's joy but might be the 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
36:22
and this gives us a much better idea for how to do something. I remember a few years ago, I was reading some random game programming thing because I don't know why. I was a bit tired of something else and I read about a concept that resonated and then we used this concept in the user interface
36:43
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
37:02
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, Django is really, really powerful for validating ideas, building proof of concepts
37:20
and pushing a product forward and iterating on top of it after this. And of course, we do use other things, most notably Next.js. When we think it's necessary, when we think it will improve the overall direction of the software that we're moving towards. Yet, we went through our phase
37:43
where 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 Django. And that's all.
38:00
Thank you for listening. I hope this was valuable for some of you. It will make you think about things. I am Rado from HackSoft. We do have a Django style guide that's our worldview for how Django should be built and I think we have a few more minutes for questions.
38:20
Thank you. Thank you very much, Rado, for your excellent talk. I have something small for you. Oh, thank you. If we have any questions, please move up to the microphone. Yes, go ahead. Thank you for your talk. It definitely made me think
38:41
and I'm gonna take a lot from it. In my previous company, we switched from SPA to rendering everything in Django which was really great for iteration speed but we found that the templates weren't so great. So we ended up using a HTML builder where you could functionally build out the DOM tree
39:00
in Python directly. So leveraging typing and being able to test it better. Do you have any experience with that? I would agree that even with Slippers and Kotlin, it's still not like the tool. If you have used React and the tools there, you would expect more but if we need typing and if we need more control,
39:25
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 templates that will spark joy soon.
39:42
But that's our experience. Thank you. Another question over there. Hello, thank you. That's been a great talk. I want to ask just a simple question. You mentioned HTMX and AlpineJS. Have you tried Hyperscript instead?
40:02
Hyperscript was the thing that you use in order to extend HTMX. Yeah, I feel like it's like, it does the same job as AlpineJS 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 just?
40:22
So I will be honest, when we decided we were going to use for some project HTMX, we were using it with AlpineJS altogether because those were the resources that we watched and we never gave this Hyperscript a goal because AlpineJS just worked fine for the case that we had.
40:42
So if there's someone in this room with more experience, I will be also happy to hear more. But at least for us, this is what worked, resonated, made sense and we never looked back. Great, thanks. All right, we also have a remote question from Christian back.
41:01
What are the challenges you have experienced in prototyping UI and UX on top of Django? So the biggest challenge is look and feel, especially when you are working with, for example, a startup or a scale-up and the non-technical business folks,
41:21
they crave, they want something to look good. And this is usually the biggest challenge, but then we work closely with the UI UX folks and make sure we implement it after it. But look and feel, I think it's the hardest challenge.
41:41
Yeah, thank you. Another question over there from the mic. Hello, thank you for the great talk. I enjoyed listening it. Probably I'll repeat the previous questions, but I'll ask anyways. Most of the questions coming from UI because probably we are most on the backend side.
42:01
Again, might be a repetition, but where does HTMX fits into this scheme? I need to input some data, click a button and I need the table beneath the form to change without the full page refresh. Like this is usually where you start using HTMX
42:23
or I need a model because a lot of UI UX revolves around the 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 the variable.
42:41
It's very closely to how you will do things with React. And this is where we use HTMX and Alpine JS. When we need interactivity and when we want to avoid full page refreshes, so the general flow feels much better. Thank you very much. Do we have one more short question?
43:02
No, I think that's it. Would you give one thank you to Rado once again?