PBS_2024_09_14
An audio podcast where Bart Busschots is teaching the audience to program. Associated tutorial shownotes are available at https://pbs.bartificer.net.
Automatic Shownotes
Chapters
Long Summary
In this episode of Programming by Stealth, co-hosts Alison Sheridan and Bart Bouchard are back after a hiatus, eager to tackle some engaging concepts around restructuring and understanding their ongoing project, XKPassWD. This installment, the 170th in the series, lays the groundwork for a deep dive into the Model-View-Controller (MVC) architecture—a foundational principle in software development that separates concerns within an application.
We reveal that this episode involves no lines of code but focuses instead on building a theoretical framework to better understand the structure behind the code they'll discuss in future sessions. The pair reflects on their experiences, noting that while they've previously explored many development tools like Webpack, Jest, and Git, it’s essential to understand how these components integrate with MVC to be able to effectively navigate the large codebase of XKPassWD.
Bart highlights the synergy between their podcast and the XKPassWD project, where listeners are encouraged to contribute or learn alongside them. They discuss how the contributions from the community have moved ahead of their teachings, creating a moment of realization that understanding the arrangement and purpose behind thousands of lines of code requires insight into their structure. The conversation emphasizes the importance of having a logical organization in programming to avoid confusion as projects grow complex.
Alison and Bart dive deeper into the MVC framework, explaining its three core components: the Model, the View, and the Controller. The Model contains the business logic and data representation, focusing on "what" an application does. The View concerns itself with the presentation layer, defining "how" the application looks. In contrast, the Controller acts as an intermediary, directing user inputs to the Model and updating the View accordingly. This separation of concerns enhances maintainability and scalability—a crucial aspect for any developing project.
The hosts also draw parallels between MVC's effectiveness in software organization and traditional business structures, likening components of MVC to roles within a company. They argue that, just as certain departments are tasked with distinct functions, so too should code be organized logically to avoid chaos. By the end of the episode, they passionately argue that understanding MVC is critical, as it empowers developers to minimize complexity and navigate their codebases more efficiently.
Setting the stage for future discussions, where they hope to unravel the folder structure of the XKPassWD project, Alison and Bart express enthusiasm for the upcoming episode featuring Helma. They aim to translate the MVC principles discussed today into actionable insights that will help them and the audience better manage and understand their code. While they acknowledge that the learning process can feel nebulous initially, both acknowledge that the journey of connecting theory to practical application is where true understanding unfolds, paving the way for deeper exploration in future installments.
We reveal that this episode involves no lines of code but focuses instead on building a theoretical framework to better understand the structure behind the code they'll discuss in future sessions. The pair reflects on their experiences, noting that while they've previously explored many development tools like Webpack, Jest, and Git, it’s essential to understand how these components integrate with MVC to be able to effectively navigate the large codebase of XKPassWD.
Bart highlights the synergy between their podcast and the XKPassWD project, where listeners are encouraged to contribute or learn alongside them. They discuss how the contributions from the community have moved ahead of their teachings, creating a moment of realization that understanding the arrangement and purpose behind thousands of lines of code requires insight into their structure. The conversation emphasizes the importance of having a logical organization in programming to avoid confusion as projects grow complex.
Alison and Bart dive deeper into the MVC framework, explaining its three core components: the Model, the View, and the Controller. The Model contains the business logic and data representation, focusing on "what" an application does. The View concerns itself with the presentation layer, defining "how" the application looks. In contrast, the Controller acts as an intermediary, directing user inputs to the Model and updating the View accordingly. This separation of concerns enhances maintainability and scalability—a crucial aspect for any developing project.
The hosts also draw parallels between MVC's effectiveness in software organization and traditional business structures, likening components of MVC to roles within a company. They argue that, just as certain departments are tasked with distinct functions, so too should code be organized logically to avoid chaos. By the end of the episode, they passionately argue that understanding MVC is critical, as it empowers developers to minimize complexity and navigate their codebases more efficiently.
Setting the stage for future discussions, where they hope to unravel the folder structure of the XKPassWD project, Alison and Bart express enthusiasm for the upcoming episode featuring Helma. They aim to translate the MVC principles discussed today into actionable insights that will help them and the audience better manage and understand their code. While they acknowledge that the learning process can feel nebulous initially, both acknowledge that the journey of connecting theory to practical application is where true understanding unfolds, paving the way for deeper exploration in future installments.
Brief Summary
In this episode of Programming by Stealth, co-hosts Alison Sheridan and Bart Bouchard explore the foundational Model-View-Controller (MVC) architecture as a theoretical framework for their project, XKPassWD. They discuss the importance of understanding MVC’s components—the Model, the View, and the Controller—highlighting its role in enhancing maintainability and scalability. By drawing parallels between MVC and business structures, they illustrate the necessity of logical code organization. The episode sets the stage for future discussions on applying MVC principles to navigate complexities in coding effectively.
Tags
Programming by Stealth
Alison Sheridan
Bart Bouchard
Model-View-Controller
MVC
architecture
XKPassWD
maintainability
scalability
code organization
Transcript
[0:00]
Welcome Back from Hiatus
[0:00]Music
[0:07]It's that time of the week again. It's time for Programming by Stealth. And this is installment number 170, recorded September 14th, 2024. I'm your host, Alison Sheridan. And of course, I'm joined by your co-host, Bart Bouchard. I hope you enjoyed your summer, Bart.
[0:23]I enjoyed most. I enjoyed the parts of it after I had all of my health issues, which is, well, you were away on holidays. Luckily, I got to enjoy that. Yes, I did. And I was going to say I need to blow the dust off my microphone, but it's been so long since we recorded, my microphone died and this is a whole new microphone.
[0:41]Well, thank goodness for that. You fought with that for a long time with the cables and we thought it was a cable. I'm wondering whether there were perfectly good cables in the bin.
[0:51]I think the cable that was built into my old boom arm that I cut off, I think I should have thrown the mic away.
[0:59]Well, I'm excited that for the very first time we warned the audience that we were going on hiatus because we've done it every single year. But this is the first time we said, you know, we're going on hiatus. Well, I'm back from Africa. You're back from some holidays, except for standing in for me. while I was gone on the Nosilicast, but I think we're ready to hit the ground running. We've got some interesting stuff that I've been itching to learn about coming up here.
[1:26]Yeah, so we're getting a little meta today, I guess, to some extent. So there is a total of zero lines of code in this episode. And in some ways, I am now laying a foundation so that Helmer can come in and build a house on top of it in the next installment. So... One of the things we decided, God, it feels like forever ago, it must be two or three years now, where we said that we were shifting the show to focus on rebuilding XKPassWD. So we learned about Webpack and Jest and ESLint and Git.
[2:03]And we learned about so many developing tools and stuff. And it's basically all of the pieces we need to build XKPassWD. And the two have kind of been a synergy with each other because if you want to put the skills we learn here into use you can contribute to the project and if you want to contribute to the project but you don't have the skills you can join the podcast so they really do feed off each other quite nicely at the moment but the work by the community which has been amazing to watch has managed to get ahead of us by us i mean the the show and so to sort of each individual single line of code is written in a language that we have done together on the series and yet when you zoom out to what is now many thousands of lines of code in the beta version of xkpasswd wd their arrangement is alien so on the zoomed in level it isn't alien but you don't ever like if you want to solve a problem and you're faced with a starting point you don't start on the zoomed in bit if you knew where it was you wouldn't be intimidated by the giant wall of code.
[3:22]And that's an issue and it's kind of something that has the tendency to happen with any project when it gets big. And basically, the code is arranged in a structure that we haven't discussed. Its shape is logical, but the logic is alien to us, which means it's just a giant big wall of intimidating looking files.
[3:47]Yeah, I've had a little trouble participating because I go in and I'm like going, I don't know where anything is anymore. So now I'm going to, we're going to start learning that, right?
[3:56]Right. So, like I said, the individual atoms we've already got, right? So we have learned about HTML, CSS and JavaScript, what, a decade ago? Oh my God, probably is a decade ago. We've looked at Bootstrap and jQuery, which are very much the brains of the beta version of XKPath. There's a bootstrap page and all of the when you click things happen is done with jQuery so those are very much at play here and in terms of the technology to power it it's tested with Jest it uses ESLint it's documented with JSDoc there are mermaid diagrams in the documentation, and the whole thing hangs together with Webpack and all of it is safely versioned in Git and we've We've covered all of those technologies, but there's two things that make the beta version go that we haven't covered. The first of those is GitHub Actions, which is what, when you hit commit, the webpage appears on the internet. And it is the code in the project, but it gets published at beta.xkpass2bd as a full website. And that's done with GitHub Actions. And we will definitely look at those in some detail, but I'll be 100% honest.
[5:14]Helma basically went, I'm just going to plumb this in using all the standard tools that GitHub gives you, which happens to be GitHub Actions. And I was like, okay, cool. And we will learn it and I'll be top of the class going, excuse me, teacher, help.
[5:31]Maybe you and I are both students at the time when she teaches us.
[5:35]Yes, and basically there's nothing exotic going on. Basically, I don't yet use GitHub to its full potential, and Helma does use GitHub like someone who uses GitHub. I use GitHub like it's Git, and Helma uses GitHub like it's GitHub. And I have known for years I need to get better, and I haven't.
[6:01]You know but one of the one of the benefits uh that the um viewers listeners learners along with us could see is i don't know if you y'all have noticed but at the bottom of the page you can step forward and backwards through the lessons and i've always wanted that where we could because i'd be looking i'm looking for something and i know we talked about it in bootstrap and i'm in 123 and I want to go to 124. I've got to go backwards out to the index and backwards and drill all the way down and scroll and blah, blah, blah. And we had a learner, and I wish I could remember who it was, who actually coded, hard-coded in all of those for several of the lessons to show us how it could work. And then Helma took it and she did I believe the GitHub actions are part of what's making that magic happen here. So we're the beneficiaries of it, but it's we've sort of got the wizard behind us making it go.
[6:57]Yeah, so basically before the theme handled it, so as of two weeks ago, the theme is now handling it because I've updated our theme so that it now has like the authors and the date and stuff, and it does the next and previous as part of the theme. But until before it did it as part of the theme, there was a GitHub action that ran, and it edited the markdown after you hit commit as if we had manually typed the links. So it was a GitHub action that was firing to do that. And that GitHub action has now been turned off. And the links are done by the theme, which is probably better because it means we can organize stuff around it. Now it behaves like WordPress. But for a very, very, very long time. But she did.
[7:39]Do the magic in the background using GitHub actions before. Okay.
[7:44]Absolutely. And so basically a listener contributed a script, which we could run manually in our desktop and then commit. And why do we run it manually? Why don't we just make GitHub do it? And so the scripts that worked manually then worked magically through GitHub Actions.
[8:01]I'm searching for the name of who it is because I like to give credit. If in the middle of the recording I yell out the name, that's what I'm doing.
[8:10]Perfect so the other piece then the other so the two pieces we're missing is how github actions work which we will come to later and the reason the individual lines of code that all make sense are now in a shape that we don't understand and that's because they are structured using a framework um which i would sort of describe as a scaffold so instead of randomly piling up things you hang them on a scaffold and then you can build the site without everything falling over in a heap when you get to a critical size of features um but right now that scaffold is indistinguishable from random noise so we let's explain the theory and the next installment helma is going to say so that theory is applied exactly this way in the xkpasswd code base okay and the the the model is called the model view controller or mvc and it's a.
[9:23]I won't call it a dinosaur because that makes it sound old in a bad way it is one of the most well-established frameworks out there for building a graphical user interface where things can happen in any order so if you're working on the command line it's really easy to have stuff happen because you type one thing you hit enter the computer does something and it tells you an answer you type something else and hit enter nothing can happen out of order right everything happens in the same order but on a gui like there are an infinity of ways you can click buttons and things and the interface always has to do the right thing and that's hard and to make that not break you need to have a structure and the structure that has sort of won the day because it works is mvc.
[10:15]But I'm actually going to zoom us back a little bit before I explain the M, the V, and the C. And I'm just going to tell you a little story about why we do this. Because code organization is the kind of thing that student me 30 years ago scoffed at. Because it doesn't scale linearly. linearly so the amount of scaffolding you need for a small project is almost the same as the amount of scaffolding you need for a massive project and the examples you get in class are always small projects and so what you get in class is 70 of my code is scaffolding and 30 does something and so you leave thinking frameworks are silly because they're wasting my time all this.
[11:08]All this overhead,
[11:08]Right? All this overhead. Why don't I just do the fun part and ignore the scaffolding? And that works really well for little projects. And then the first time you do a big project, then you realize why you have all that scaffolding. And the thing is, on a big project, the same size of scaffold becomes 50-50, then 25-75. And on a proper big project that I've been I have been involved in projects using MVC, that are I think it was 200,000 lines of java code when we were all done and the scaffold might have been five percent but it's the same scaffold it's the same size of scaffold so it looked silly when I started the project and I thought I was wasting my time but I was a student and the master told me, you must use this scaffold. So I diligently did. And six months later, I bought him a coffee. I went, you told me so. You were right. Thank you. But it honestly took me a while to realize that it wasn't silly.
[12:15]So like I say, there's a lot of resistance to these things because it looks like so much work and every example you get makes it look like you're wasting your time, but they actually solve a really real problem. So to understand why, let's imagine a world where we don't.
[12:30]So if you build a project without a scaffold in the short term, you will shoot ahead. You will make massive progress and it will look like things are going great. But as the code gets more and more complicated and you want to start doing a simple thing like i want to add a third button here well you end up having to make a change in about 20 different parts of the code base and they're not in any sort of logical structure so the only person who really knows where anything is is the person who wrote it because it's just like a weasley house in the harry potter series it looks like it's got these odds and ends stuck onto it and you don't quite know how it doesn't fall over and you end up with a function called update v update interface that is 500 lines of javascript and if you want to change one thing you have to do it at the top and then about three quarters of the way down and then near the end and if you miss one of those three things then when you click the button only half the page updates or something it doesn't update the validation but it does update the setting or it doesn't update the thing at the bottom that says how many characters your password will be or basically the interface does something inconsistent because you only fixed two out of three things and you didn't know about the third because it's not in any logical place it's in some random point in a massive big file.
[13:56]And before you know it the only person who can edit the code is the person who wrote the code And then in a real world organization, that person leaves.
[14:05]So is this really just a convention? You call it a scaffold, but it's a convention. Like I'm going to put this here and I'm going to put that there, but everybody's agreed this is a good convention.
[14:17]Convention seems as good a description as any for, it's a philosophy of design, a design pattern. These are all words people use to describe these things. But it's really.
[14:27]Just like what folder you put files in.
[14:31]That is a perfect example of the kind of thing. Right. Yeah.
[14:33]So, you know, but I mean, that's all it is. Yes.
[14:38]Okay. Yeah. So it's where you put files and how you call them. Right. What, what classes you make and what functions you make and how they talk to each other.
[14:50]That's different than what folders you put stuff in.
[14:53]Yeah so i guess it's like conventions.
[14:55]For the the classes too
[14:59]Naming so don't fixate on naming it's job convention so think of it like an org chart so if you want to build a company you have lots of ways you can organize your humans, and with this kind of like with mvc you basically say this code has to do a lot of things, and we break that into pieces and we say that this class is responsible for this thing and this other class is responsible for this other thing. So you're separating the work that has to be done by the code into sensible chunks based on these three concepts we're going to talk about in a minute called the model, the view, and the controller. So we have lots of lines of code that have to do different things and how you choose to assemble those lines of code is the framework you're using. How do we break up the labor? How do we divide this? is it an organizational structure is it some sort of hierarchical structure i think org chart is probably the best analogy allison so you have all of these humans they can all do things, you have 5 000 of them what do you do chaos ain't gonna work right so you got to organize them somehow and there are all there are books written right about what is the right way to organize humans and there are books written about what is the right way to organize code and one of the ways that has worked supremely well is MVC.
[16:26]So this, all right, so the last thing I sort of say before I go into MVC is that there is no single right answer, right? There has been no oracle who has come down from on high and said, this is the way to write code. Just like no one has ever come down from on high and said, this is the right way to run a company. Or this is the right way. Actually, no, there is someone who came down and said, this is the right way to organize books in a library. He was called Dewey. And we really like his decimal system. But other than that, very few things are so well defined. But one model that has stood the test of time is Model-View-Controller, or MVC, which breaks the work of your code into three chunks, Model-View and Controller. And it's kind of funny how everything that's old is new again. And I often have people joking at me that, you know this whole cloud computing thing that you think is so modern you hip young person you do know that's just the main frames we had when i was growing up in the 70s right i said yeah you're kind of right.
[17:26]Well, in the 70s was the first time that computers went from being sequential, like in series, right?
[17:35]Computer do this, chunk, chunk, chunk, chunk, chunk, here's the answer. Computers do this, chunk, chunk, chunk, chunk, chunk, here's the answer. So the computer was completely in parallel, and everyone's writing their code on the assumption that you tell me to do something, my program will do it, then it will ask you for input, then, you know, over, back, over, back. And then we invented the GUI. and now instructions could come at random times and not only could instructions come at random times but the brain of the computer had to represent its state in a visual way so if you have a spreadsheet that exists in memory as a series of ones and zeros and it exists on your screen as a grid of numbers and if what's in memory and what's on your screen are not guaranteed to be the same it is the world's most useless spreadsheet imagine not being confident that excel that if excel said three the dot xls file actually contained a three like imagine if you could not be confident the screen represented reality that would be a mess and in the old serial world, if you took that code and tried to put it into this, anything can happen in any order world, it just broke. And the way people discover that you could make it not break was to break the code into three pieces, the model, the view and the controller. And that's where MVC came from.
[19:02]And in the early days of the internet, it was like a command line. You would type in a URL and you would get a page and that page might have a form on it. And until you hit submit, submit nothing happened and when you hit submit the entire web page went away all the stuff in the forum went to the server it calculated an answer and you got a whole new web page, right and the whole internet was like that until we had what we now call web 2.0, or javascript and now we have these interactive apps like if you go into gmail now you can have multiple tabs and you can be writing an email in one tab and you can be viewing five emails in other tabs and you can do all these things at once. And there's like an address book and a chat client that is all happening at once, all on the one page. So that is the old world of the GUI meeting the old world of the command line. And the answer computer scientists settled on in the 2000s was the answer from the 1970s. They reinvented MVC. They just went back and started with the same answer from before, which I'll be honest, I thought it was all new and hip with web 2.0 until I started to do my research and I was like, oh, this is older than me. I was born in 1980. This is literally older than me.
[20:26]In, right, so yeah, let's start over complicated things. I've said, if you're reading the show notes, I've said exactly the same things in a completely different order, but I think I've said all the same things. So let's get specific here.
[20:42]So it's about responsibility, right? We have lines of code that do different things and we need to organize those into buckets of responsibility. Responsibility and those three buckets are the m the v and the c and that's what determines where the you know where the code goes and so the three areas of responsibilities the three divisions within our corporation are model which is the what of your app so if it's a spreadsheet spreadsheet, the model is the grid has to be stored somehow inside the computer. And all the things you can do to that grid have to be represented inside as functions. So you can sum two cells. So there has to be some code written that can sum any two cells. You can average cells. So there has to be a function somewhere to average cells. So how I represent the spreadsheet and what is actually meant by some average pivot table is also represented by functions. And those two together are the model. They don't know how it looks on screen and they don't care. They are about the what.
[22:06]So I have a grid of numbers. I can multiply, I can divide, I can. Maybe I have...
[22:14]It's not the how?
[22:17]What on the how, correct, the what on the how, right? It's the thing the app does, not how it looks.
[22:27]I mean, if I've got my little time adder app and it's adding time and there's a function in there that adds time, would that go in the model?
[22:35]Yes. Okay, time adder, that's a lovely simple example. Well, okay, that would be described as business logic.
[22:43]I don't know what business means in this. That's a very corporate-y kind of a phrase there, Bart.
[22:48]Yeah, it's the doings. Okay, so let's use your time adder. That's a really good example. It's nice and simple. I was racking my head for something simple. So time adder is simple. So your time adder has to have a time and some stuff you add to it and how you do the math. Right? So those things are your model. I have a time. I have a change. And I have how I do that change. That's the model. With a few times.
[23:20]You add the two times together.
[23:22]Okay, but your model is two times and the logic to do the hard work, which took you a lot of figuring out how to make that wraparound, right? That wasn't trivial, right? That was a lot of lines of code. And that logic, that representing the information and manipulating it, doesn't really care whether it was on a command line interface interface, a shiny, gooey app, or a web page, the actual logic is the same.
[23:50]Right.
[23:51]So that's what makes it the model.
[23:54]But that's the how. That's not what the app does. That's the how the app does it. It's not what?
[24:00]I would say yes. I would say yes. Okay. Yes, it is both. Can I change the notes to.
[24:06]Say what and how?
[24:08]Sure. Sure.
[24:10]Okay. Yeah.
[24:11]I mean, if that makes it easier to understand, absolutely 100%, right? But the key point is, it's about the information your app works with and the changes your app can do to that information. So with the time matter, it's saving the dates. do you save them as a single date variable or do you break them into pieces do you save it as a time zone three digits okay how do you break it apart and then what functions are you going to provide so that together is the model and if you write that model as one piece then you could take that same model and turn it into a command line thing that you turn it into say a text expander snippet that it will take you know if you drag or something in um hazel that can do javascript right yeah so the model doesn't care where let.
[25:05]Me ask the clarification then uh because you you use the word business logic i think you just mean logic
[25:10]This is yeah yeah okay so you you'll see why the term business logic exists when we get to the to the other letters in the mvc so it's the it's the logic of the model right because there's another piece of logic right when you decide to add a gui there's a whole other piece of logic about how the buttons connect to each other but that's completely different logic buttons.
[25:41]Connect to each other
[25:42]Right so if you right so maybe.
[25:46]If you keep going in your in your story and and i'll come back and see if I understand why you would use the word business. Because business to me means a company. It means...
[25:56]It's the work of the app. It's what the app is trying to do. So if the app is a time adder, its business is adding time. If the app is a password generator, its business is generating passwords. If the app is a web cart, its business is online commerce. It's what the app is trying to do. It's the problem to be solved, to put it in allison words. What is this app trying to do is the business logic so yeah if you're trying to add time then adding time is your business if you're trying to generate passwords and generating passwords is your business if you're trying to make a fun game then that's your business right it's the what yeah, So that's the first piece. And then we jump straight to the complete other extreme, which is what it looks like. So we have what it does and then completely separate is the what it looks like, which is called the view, which is the one part of MVC that no one has any trouble understanding. The view is what it looks like. So the view, the code for the view doesn't know how. So the code for the view makes a text box which will display a date, but it does not know how you add those dates. It doesn't know anything about anything that's going on under the hood. Its job is to make it appear.
[27:14]All bootstrap and CSS would be in the view. Exactly. What about all the accessibility stuff would also be view?
[27:23]Yes, definitely. That's about how it looks, right?
[27:25]Because that's what it looks like to a screen reader.
[27:28]Yes. Okay. Yeah, exactly. So the view is the presentation and the view code should not know anything about how it does anything because that's the whole point of separation of responsibilities. The legal department never does engineering. The view never does the how of the app, the business logic. I'm sorry to use that word, but that is how it's described.
[27:53]I've looked it up and everybody says they call it this business logic. What business is your app in what is it what is it trying to do i got it okay yeah so i think i got view and i think i got model now we got it you're going to convince me i'm going to understand controller
[28:08]Right so you now have two very very different things at the extreme back end of the app is the model of what it does and at the extreme front end is the view how it looks but the view has buttons in it and the model has functions something has to wire those two together when i push this button here here, do this piece of the business logic. When I push the generate password button, generate a password using this information. Well, the information's in the view, so the controller has to get the right information and then hand it to the model. The model does its work, hands the controller back the information, and the controller says to the view, show them that password, or show them the result of the adding. So the controller sits in the middle, handing information over and back between the view and the controller. Sorry, between the view and the model. So the controller sits in the middle.
[29:06]Okay, what kind of code goes in there?
[29:12]The problem with the controller is it's the amorphous bit in the middle. So it tends to be a little bit of everything because it obviously has to talk some JavaScript because how else can it talk to the business logic, which is all in JavaScript in our case. And it has to be aware of the HTML because you've pushed a button to make, to tell.
[29:35]Let's say we're using mustaches to create buttons on a page. Where's the mustache go?
[29:43]So the mustache's view, that's about how it looks, right? The mustache is going to make it look like something, but it doesn't do anything.
[29:50]Yeah, it's creating it.
[29:53]It's creating the view, but it's still creating the representation.
[29:56]And the code that gets run when you push a button that the mustache created goes in the model.
[30:04]No where's the control no no the right it ends up in the model right but at the moment in time when you push the button how the handover between the two happens is the controller, right so.
[30:19]You so the model doesn't know about the button
[30:24]Right exactly the model only knows I have two dates.
[30:29]That's horrible. I hate that. I don't want to do it, Bart.
[30:34]You think you hate it, but it opens up some amazing possibilities. It came about for me.
[30:41]But it explains why I can't figure out where anything is in XKPastWD anymore. If the button doesn't
[30:48]So the button.
[30:48]The equation doesn't know where to apply itself.
[30:53]Okay. So the bits you're not going to have any trouble with are the model is about how you make passwords and the view is about how the webpage looks. And something has to plumb those two together. It's the misc, right? It's the cream in the Oreo, right? It's what is it? I don't know. It's not cream. I don't know what it is, right?
[31:16]Can we stick with a simpler example? Since I absolutely do not know how XHPAS WD works anymore, it is a complete and utter mystery to me, so I can't talk to that as the example. If we looked at my little time adder, just for the audience who hasn't been living and breathing my silly little app, is you type in numbers into hours, minutes, and seconds, and it adds them. That's all it does, but the spreadsheets can't do this, so this is a lapse time adding. So when you lift your finger from the keyboard there's a key up command when you finish typing a number it calculates uh and and types out at the top how much the addition is so there's logic that says on key up run this function are those in two separate locations now in okay so the controller have to be telling it to do that okay
[32:10]So the on key up would be the controller. So when you lift your key, the controller gets told, ah, the view has just, something has happened in the view, right? The user using the view has lifted their finger up. You're the controller.
[32:22]Using the view. Yeah.
[32:23]Yeah. So you're the controller. This thing has happened in the view. Your job is to make that do something with the model.
[32:32]Okay. So you're removing, that I think is in the HTML right now. I haven't looked at my code in a a while.
[32:39]Well, the HTML is going to say on key up or something, and that's going to name a JavaScript version. That JavaScript version is in control.
[32:49]No, that JavaScript is in the model because that's what it's supposed to, that's it doing something.
[32:56]Ah, okay. So if you're after bigger, right, but you haven't used the model view controller. So if you had done it in model view controller, you would have a class called time adder, which only knows how to do the business of your adding. And you would have the view, which is just your buttons. And then you would have a function sitting between the two that when you click the button, the function goes and calls some function in the class that does the work.
[33:27]Yeah, it's actually not a button. It's literally the human lifting their key that makes it happen.
[33:32]Okay, well, it's an event.
[33:33]Sorry, an event.
[33:35]Right.
[33:35]An event.
[33:36]Yeah, the event handler. Yeah, the event handler is the controller. It's like an event has happened. It's the controller's job to do something. And what it chooses to do has been put into the model so that the so that the controller doesn't know any house and it doesn't really know what it looks like it just knows that i have i respond to events and i plumb them into some brains, all right it just sits in the middle receiving the events and dealing with them, So if you think about it a little bit further back, right? So you land on the web page and it tries to load. Well, actually the controller comes first because the controller says, oh, what am I? Oh, I'm a web page. I need to have a model, new password generator, new time matter, whatever, right? And it now makes a model. And it says, oh, I need a web interface, new web interface, and it builds the view. And all those event handlers come to it right because it built everything so it's in the middle because i made the model i made the view when the event happens it's me and i know to connect it over here so it's just sitting in the middle it starts off with an empty screen and says model view you tell me when you do something i'll tell you what to do it's.
[35:03]A middle man
[35:06]Middle person i don't know yeah we have to disparage men what is the correct term for middleman these days because i've gotten used to saying allow list and block list, and active passive and adversary in the middle i've gotten very good about these things but i don't actually know what you put what you put in there yeah anyway yeah a broker sitting in the middle a.
[35:29]Broker yeah a controller is actually a pretty good word
[35:32]Controller is a pretty good word right and that's what it does but i always like to start with the view the.
[35:38]Diagram that i drew of our uh solar system because we now have solar panels and a battery and the grid and there's a controller in the middle that's going okay if the sun is shining and the battery's not full then take the energy first send some to the house once the house has been satisfied then send the rest over to there and it's that little traffic cop in the middle that's that's doing all the controlling.
[36:04]Okay. That's it exactly.
[36:06]So I have a feeling I won't understand it the first time I try to look for it, but I'm with you so far.
[36:12]Right. But yeah, so that is what you're trying to do, right? Whenever you're thinking of a piece of code, you're thinking yourself model or view. And if the answer is no, no, then it's probably controller.
[36:23]Right. If it's not obviously the what, and it's not obviously how it looks, it's the controller sitting between the two. Okay. That's how I work with it. Right. It's A, B or MISC. MISC is a controller. And there's actually a lot of really good. So, okay. So model view controller, this does not have to be a one-to-one. So if you imagine the modern Gmail, right? It's not the Gmail when I was young, which just did email. Now there are at least three models in Gmail. Email there is email brain contacts brain calendar brain there's probably chat brain as well isn't there i haven't i'll be honest i haven't logged into the gmail web interface well but i think they added a chat interface in there at some point and then renamed it 50 times i don't even know what it's called these days um right but it's it does three things email contact calendar so that That means there's three models there. How do I do email? How do I do contacts? And how do I do calendar? And they're very different things. So you'd have completely different teams of developers.
[37:30]And there'd be separate classes, right? An email class, a contact class, and a calendar class. And so you can have, on a complicated app, multiple models. Now, for xkpasswd, we do not need lots of models because all we're doing is making passwords. For the time adder, you don't need lots of models because all you're doing is adding time. But if you were to make an Allison's time utility portal that lets you add time, change between time zones, I've run out of ideas now. I'm sure there's something else you could do with time.
[38:03]That does make sense, but yeah.
[38:05]Right, but imagine you made it do two things. Well, then you'd have two models because it now does two things, right? If you made it into a more generic thing. So big sites will have multiple models because they do multiple things. The view then, also, you can have multiple views because if you have email logic, you probably want to have an email view. You and if you do calendar logic you want some calendar views and then you probably have one overall view that just has like a placeholder it says big picture wise left sidebar right sidebar left sidebar is view number two and right sidebar is view number three and their separate class is called sidebar and main page owner i don't know i'm making this up as i go along now but the view could be broken like like on a wordpress theme or whatever right you could the view could have little sub views that do different responsibilities so i haven't looked i don't know what helm was going to tell us next week but i wouldn't be at all surprised if there was a view for the configurations because there's a list at the top of all the presets so that's probably one view of presets and then there's like a big view where you can change all the different parameters like you can how many words do you want that that's going to answer.
[39:22]The question i'm looking There's passwordview.mjs, presetview.mjs, and settingsview.mjs.
[39:29]Okay, well, so there are three views, which are going to match.
[39:34]So those are all, and there's a controller for each one of those too, but not the, there's no, I thought view would be HTML, but it's not.
[39:47]Right, so a jQuery allows us to make HTML appear, right? We can say jQuery.
[39:53]That's not in there. That stuff is not in there, and that's what can, maybe we're getting ahead of ourselves. We're getting ahead of ourselves, right? There is an index.html that does have the HTML. But if I look at like password view, I don't see anything in there that looks like it would build buttons, for example.
[40:13]Okay, well, I definitely don't want to get into that level today because that's, Helma is going to explain that next week and I don't want to, I don't know the answers. So I'd just be making stuff up, which is dangerous. Okay. And I also want to make sure that Helma can teach us on a blank slate. I don't want to, I don't want to bias myself because I'm going to be learning next week too. So, but the key point is, so there are multiple views is the answer to the first thing. So you can have multiple views. The other thing you can do with multiple views is they can really be very different. So do you remember before the iPhone, mobile phones technically could go on the internet for a very loose definition of the word internet and they used to be www.yahoo.com because we went to yahoo in those days and there was m.yahoo.com now they had the same information, But they looked completely different. So actually, in the MVC world, you had two views, a real web browser view and a silly mobile phone view.
[41:18]You don't have to go back in time, Bart. There's still websites I go to where I have to request desktop site because functionality is not there. That's still there today.
[41:28]That's a good point. Yeah, I guess it's become less important. No, you're right. Actually, there are still sites that do that. So, yeah. So that's two views, right? The model is the news. they don't have different news right there isn't someone hasn't wrote the article twice.
[41:41]There's two views of the one model the model being used it's not the world's most complicated model, so you can have you know multiple of each basically and the controller can the controller is very much like a management in a company you're going to have a master controller who starts when the page loads right the page starts up there is a controller in charge that's going going to build everything but that controller can delegate and say you're responsible for making the password part of the page work you're responsible for the presets part of the page and you're responsible for whatever else you said right so you can start to say we're going to have a controller who's only handling this piece of the page because otherwise my code would get too complicated so that you can delegate within the controller controller can have millions if we want of a better description. But ultimately everything breaks down into model, view, and controller. So there are some really big advantages to this because it's going to give you, if you want to do, if you have a problem to be solved, it's going to tell you where in the code base to go look. I need to make this button bigger. That is in the view somewhere.
[42:59]I need to add an extra field to our description of currencies. That's in the model. I need to change how we calculate the interest. That's in the model. I need to add a confirmation step before this button actually changes something. Well, that's in the controller. And if there isn't already a view for making a confirmation, then we need to go and make a view for making a confirmation. But the controller is going to say, okay, right. Confirmation view, do your thing. right so the controller is is where that plumbing change is done i need to add a new feature well that's three pieces of work what does this new feature do to the model what does this new feature do to the view and how do i need to connect the two parts of the new feature together, and the great thing is you can actually have three different developers working on each of of those three pieces, because your new feature is basic.
[44:00]Is there a standard naming convention, so I know looking at a project, this is the view, this is the model, and this is the controller?
[44:08]There's no universal standard, no. There's no universal standard.
[44:13]So then how do you know?
[44:15]So that is, oh my God, does that depend? So there are development platforms that are very, very, very opinionated. So if you're using something like the Django framework in PHP, that is spectacularly opinionated. It lays down the law like railway tracks. You must name them like this. You must put them in this folder, right? And so the model must be exactly here in a file named exactly this. And then in my, so when I was doing MVC many years ago, it was in Java, not JavaScript. And the class structure was very clearly laid out. We had to do things as very, very specific way. JavaScript is a very loosey goosey sort of thing. So in JavaScript world, it's very much by convention. So the important thing is that Helma has been consistent in where everything goes. And the reason this absolutely positively is a game of two halves is because there is a naming convention. I don't know what it is. And that has to be captured in these show notes and probably in the documentation too.
[45:30]Yeah, I think this is part of it. But, for example, there's lots of index.html's. They're all over the place. And I don't know which one is. There's some under dist. There's some under source.
[45:47]Okay, I can help a little bit.
[45:49]I find them sprinkled about.
[45:51]Okay, I can help a little bit. So source is the code. Dist is what the GitHub action makes from the code. So that is the published web page. That is what comes out. That is the compiled code for one of it. It's an analogy.
[46:09]But the code is in lib.
[46:12]
Exploring GitHub Actions
[46:13]Okay. So I'm not going to, I don't want to do Helmer's job next week. There is a really good logical reason for this. And these pieces make sense because the model is the JavaScript library that we want to have completely separate, not to be intertwined with the web page. And that model is going to become a completely separate Git project that is just the brains. So it is in lib so that it's separate from everything else.
[46:48]The model is under web, not under lib.
[46:52]Okay. I don't want to... I didn't do the folder structure. I promise you there is a logic.
[46:58]Okay.
[46:58]And that's why there's a part two.
[47:01]Right. But one of the things I've been asking for since I stumbled across this shocking change to the code, and I've talked to Helmo about this, is I want a diagram. What are all these folders? What do they all mean? What are they for? What what points to what there's there's nothing we we don't have if there is no known structure of the way model view controller works or required or you know rigid structure that's okay but i need a map agreed
[47:32]That is that is that is what i am hoping we have as the output of the next week Either we have the information that we can write a map together, but at the very least, the show notes will be a description of that map and then how we shorthand that map into a diagram. That's part two, right? Part one is get the information. Part two is distill it.
[48:00]
Understanding MVC Framework
[47:57]I tried myself, but I didn't understand how it worked.
[48:01]Right, exactly. Right, which is why the theory today is the foundation we'll build on next time. and then the result of proving we actually understood it is that we should be able to diagram it and Helmut should be able to tell us we're not wrong. Like, we're the students. If we can diagram it at the end of the next installment, then we've understood it. Remember, I don't know how it works yet either. I know what MVC is, so I'm halfway ahead of you. But I don't know the exact structure here, so I'm very much looking forward to the next installment as well.
[48:35]Well, I also know that Helm is going to have listened to this, so she's going to know if she doesn't get me to that point. There's going to be, teacher!
[48:44]Exactly. But, you know, now that we have this idea of the three pieces, the folder structure is... Imagine trying to explain the folder structure that follows a philosophy you've never heard of. That's a hill that I don't know how to climb.
[48:56]Yeah.
[48:59]So that's why we broke this into two, right? So this is the concept of the pieces.
[49:09]
Wrapping Up MVC Concepts
[49:04]And next week we get to say that the model is these files in this structure. And the controller is this bit here. And the view is this piece here. So at least we now understand the three pieces. And then next week we get to see how those three pieces map to the folders in that GitHub repository. okay, all right so I think that sort of apart from the fact that I've noticed I can't spell the word implemented but I'm assuming you've already fixed the show notes and you push that to get but the very last sentence is now bright red shouting at me okay, by the way a little bit of.
[49:48]Do you have a final closing
[49:51]Well basically so what I'm hoping The outcome I'm hoping for from today is an understanding of why code gets put into a structure in the first place and what the M, the V and the C are trying to achieve.
[50:09]Yeah, I think so. I'm not bought in, but I can live with it. Waiting until I learn.
[50:19]Learn yeah and so this sets us up then to see how the actual code in a very very real example ties into the theory which is what we've looked at today right.
[50:32]Right well good
[50:37]It's, you know.
[50:38]We're kind of finishing without a bang here,
[50:41]But I think it's kind of hard to have a bang, right? Because one of the things I remember from being a student, the theory of software engineering. It was it always made perfect sense at the moment in time it was coming out of the lecturer's mouth. And then I went home and it started to become very, very, very fizzly and vague and like smoke sort of evaporating away. Way and the only way it ever comes back together is to start writing code but it's really hard to write code at first because you don't really understand it and the only way to kind of get there is to keep pinging back between the theory and the code and the theory and the code and the theory and the code and i wish i could say and tada it'll make perfect sense tomorrow but it won't, but it will make more and more sense the more you use it and i think probably the where it started to make sense for me was when I had an actual code base and an actual problem to solve and someone to hold my hand from I want to make this thing do this instead of that, and I have 5,000 lines of code here where do I begin and walking through one of them, helped me and then over time I took the training with self and you know set off but But yeah, I don't know. I mean, that's how I learned. It was, and it was, yeah.
[52:07]Well, I'm glad we have a practical example with X8PathWD. She's got quite the challenge ahead of her to explain this to me, I'm afraid. I wish her the best of luck.
[52:20]And I would say, you know, practice. And as we do, as we have problems to solve, we'll work through them, you know, actually they might make very interesting tidbits here on PBS, working through some of these kind of things maybe pick a single issue and work through it together, Anyway, step two is definitely the how this theory applies to that code, because I need that more than anything else.
[52:50]Right. I do want to make one correction. As we've been saying, next week it should be in two weeks. And I don't know that we've technically scheduled that with Helma. So we did a lot of stuff while I was in Africa and reading on no internet three days at a time and stuff. So when we see you next time, the subject will be model view controller with Helmer.
[53:15]I keep meaning to say next time, and I keep getting it wrong. And you think after all these years of being a biweekly show, I'd have stopped saying next week, but no.
[53:25]All right, do a search replace all in the audio file.
[53:29]Yes. Oh, AI, do that for us. You can't. Okie dokie. Well, until next time, whenever that is, happy computing.
[53:39]If you learn as much from Bart each week as I do, I'd like you to go over to let's-talk.ie and press one of the buttons over there to help support him. He does 98% of the work here. I'm just the stooge that listens to him and asks the dumb questions. If you go over to let's-talk.ie, you can support him on Patreon, you can donate via PayPal, or you can use one of his referral links. I really hope you'll go over and help him out. In the meantime, you can contact me at Podfeet or check out all of the shows we do over there over at podfeet.com. Thanks for listening and stay safe.
[54:14]Music