Embedded - 280: Reginald P. Theodore Johnson

Episode Date: March 8, 2019

Chris (@stoneymonster) and Elecia (@logicalelegance) talk about design patterns, conferences, and Molotov cocktails. Wrapper /  Decorator  / Facade Observer aka subscriber/publisher (caveat) Delegation and Dependency Injection Model View Controller (very important if somewhat dated UI pattern) PyFlakes is a static Python checker KiCAD Conference is in Chicago on April 26-27, 2019 BangBangConWest 2019 is over but the videos will be up soon including the one Elecia noted about liking things (which was done by Lynn Cyrin). Embedded.fm Patreon

Welcome to Embedded. I'm Alicia White here with Christopher White. And this week it's just us. We've already been talking for like a half an hour. We're trying to prepare for this show, which means it's going to be a train wreck. I actually suggested we started recording about 15 minutes ago when it was clear, we were going to fumble through things.

And I thought you all would like to listen to that, but he's like, no, no fumbling. We're going to sound like totally smart, like totally smart, like totally smart. Yeah.

Uh, so what are we talking about? Why are we talking about it? Why are we talking about something else? If you want, I can... Okay, so I have design patterns on the list because a lot of people were interested in that. And they won't be once we're done with this.

And then I have a bunch of Python things because I've been doing a lot of Python coding. And then there's something about this kai cad conference thing i believe it's pronounced i don't know key cad conference thing ki cad uh and then we went to bang bang con and we did that was like six months ago it was like a week ago all right and then we have a few random listener questions all All right. Including coffee mugs. Okay. Let's do it.

So what are we going to start with? Well, are we going to start with design pattern? Let's get that out of the way so I never have to hear about it again. Well, I mean, I have to deal with this stuff at work. So this is like double work. Work. Okay. It's not like a double hamburger either it's like

double work uh yes design patterns what are and aren't they uh okay i'm gonna go to wikipedia for this because it wasn't too bad uh but i'm gonna break it up a bit a general reusable solution to a commonly occurring problem within a given context in software design. It's not a finished design that can be transformed directly into source or machine code. It's a description or template for how to solve a problem that can be used in many situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system. Did that make it totally clear for you?

It's pretty abstract, and I don't really like the best practices term. Yeah. There's a lot of negative baggage associated with that. Well, okay, so it's not code. Right. It's not an algorithm. Right. It is not... It doesn't code. Right. It's not an algorithm. Right. It is not...

It doesn't do any computation. It's structural. It's architectural and structural. Yes. But it also doesn't have anything to do with your source code guidelines. Architectural. That's such a hard word to get your head around. I mean, if we were talking about true building architect, architecture, it wouldn't be, is this a movie theater or a home?

That's too big. That's just too separate. That's not what it is. Would it be a flying buttress? I just got to say flying buttress on my podcast. Yeah. Or is that too specific? Actually, no.

A fly-in buttress is used to hold up the arches, I believe, in Gothic architecture. And there weren't any other ways to hold up the arches. They didn't have that down yet. And so the fly-in buttresses are a good design pattern because it is a solution to a common problem implemented in many different ways and it is a well-recognized thing it's not like if i go somewhere in spain and see a flying buttress and then i go someplace in france and see a flying buttress i can tell that they're the same thing doing the same function even though they may be decorated entirely differently. And that is what design patterns are in software, too.

It's the idea that we can talk about software using a common language because there are common problems. Well, they're emergent, too. people didn't sit down and say, okay, let's spend a couple of years in our small office with a whiteboard and think about software and then write down a bunch of things that we think people ought to do. It was observing things that people did commonly and then trying to formalize those. Things that people did commonly in many different tactical ways. But trying to say, okay, you know what? People do this thing often. Let's give it a name, and let's give it a template structure,

and we can show example code and various things. And then we're going to call that a pattern. In the preface for the Gang of Four book that we've talked about before, the Design Patterns book, they say very specifically, design patterns capture solutions that have developed and evolved over time. They aren't the designs people tend to generate initially. So both of those things are, as you say, it's emergent. There's some tension there. They aren't the designs people come up with initially.

Well, if it's something that's going to be obvious, you don't really need to talk about it. You don't need to talk about bricks in architecture. That's pretty obvious. The reason I don't like the best practices language is that tends to have the management consultant kind of... Vibe, yeah. Yeah, like, oh, well, you know, some, some person has a roadshow, they give a presentation to you and they charge you $10,000 to tell you how to do best, best practices for software development.

That's not really the same kind of thing. I don't like it because it would be easier to say design patterns are cheating at your job. I mean, that is, that is a far more appealing thing. And I also think that best practices tend to be thoughtless. It's like, oh, just do this. Or you don't get to do that with design patterns. Design patterns, you don't flip through the book and then choose one and start writing your code.

You should be familiar with them enough to design your code and then notice, oh, you know what? This looks like I'm heading this direction. I can do this more formally as a blah pattern. And I can do it more formally and I can look at the blah pattern directly and see if there's something I'm missing. You know, is there something that everybody else tends to do that I'm going to forget about and need to implement later as a tack-on when if I think about it now, it'll be easy? Yeah, and on the other hand, people have thought a lot about these things. They are used in a lot of places. And so any kind of bugs or misapplications of them have been kind of dealt with. So if you, if you do understand them and you kind of have them in your toolkit as you're designing software, you'll be able to piece things

together with more confidence because you'll say, Oh, this is this. And I know that it has these advantages and it solves the design patterns that are in these books tend to be object oriented and they tend to try to, a lot of them tend to solve problems that came out of object-oriented languages. Yeah, the overuse of object inheritance and just the whole overuse of object-oriented programming. Yeah, so that's another aspect of it, is like this is a better way

to use your language features than maybe people started initially using them, which can give you better software. But you do have to understand them. That's the thing. You can't just flip through the book and say, oh, I'm going to do this and plug in some code and I don't know what I'm doing.

And Christopher Speck said a few days ago or about a month ago, best practices are not a substitute for independent thinking and understanding. If you reach for so-called best practices before fully understanding your situation, you're buying snake oil. Now you have two things you don't understand. I believe the response to that was, I don't know what snake oil was, so now I have three things I don't understand.

The other quote that applies to design patterns, if you don't know what you're doing is I'm telling you Molotov cocktails work. Every time I had a problem and I threw a Molotov cocktail, boom, right away I had a different problem. Thank you, Jason. Yeah. All right. So let's, let's get, we've kind of established what, what these are. I still want to go a little bit more on what they aren't. All right. So let's get... We've kind of established what these are.

I still want to go a little bit more on what they aren't. All right. The names. They have names. Like we talked about the command pattern. Yeah. And how it was used to solve a problem dealing with commands. If you have a command parser, you do not have a command pattern.

It doesn't work like that. If you have a command parser, you do not have a command pattern. It doesn't work like that. If I have a strategy, I don't have a strategy pattern? Exactly. If you have a state machine, you don't have a state pattern unless you look at the state pattern and make sure they match. The command pattern is not solely used for command parsers. It's used for other things. Command parsers definitely can be made in such a way that they're not using the pattern at all. So the names can get confusing because you get so used to, oh, I've heard of the state pattern, and I know how to make a state machine,

so therefore they're the same. No, they're not. No, they're extremely specific. And they tell you, even if you avoid the object-orientedness of it, they tell you how to set things up. And if you're just using the name and not doing it, then you're losing the goodness of the pattern. You're just using the name and realistically, you could call it Fred and nobody would care. Okay, and so I want to talk about circular buffers, which is totally not a design pattern.

But when I say circular buffer, most of you, certainly Christopher, knows immediately what I'm talking about. Many of you, and probably Christopher, know that I almost certainly mean something that is of length power two. That's where you hack into the RAM controller and you wire it so the two addresses return the same result. So back to circular buffers, you know that it doesn't matter what is in the buffer. I haven't specified whether I'm using ints or floats or structures. It's a circular buffer, but we understand what that is. Okay. A circular buffer isn't a design pattern, but it's kind of like a slightly more tactical version. A design pattern is a higher level than that, but the goal is the same, that we can talk

about it the same, that you can talk about it the same. That you might know that there's a first and last problem in a circular buffer, and in a design pattern you might be told this is a common problem, so it's something you should check for. Is that a good analogy? I've been working on analogies all day. I would say the design pattern is not a computational algorithm. It doesn't produce results. And it is not a data structure, though data structures can be built with them or next to them. But it is not a linked list. It is not a B-tree.

It is not that kind of thing. So, yeah, I think it's time to get into examples because we're giving a lot of non-examples. I think it's the easiest way. No, but... It's just to find everything it isn't. Yeah. Okay. Which one do you want to start with?

Okay. So, when he, like, shook his head and shrugged at me. Sorry you didn't see that. I see it a lot. Okay, so you have a new processor from some vendor. It's an ARM processor. And you formerly worked on ST-micros, and now you have an Atmel micro that's, again, Cortex-M something.

And you look at it, and their register sets are entirely different. You're going to have to learn everything from scratch. But then you start looking more, and they have this CM-Sys thing, which is an ARM layer that wraps all of the lower stuff. And it's a hardware abstraction layer. And so instead of looking up the register for everything, you can just put in GPIO set something and it works. That CMSIS layer is called a wrapper. I mean, a lot of us just call it a wrapper because that feels like a good word. It is sometimes called the adapter pattern, sometimes called the facade pattern, that you are providing a layer that looks the same between different things.

And for us, for embedded engineers, providing a layer between different hardware is what we're talking about. But if you were working more in the software space, it might be providing an adapter layer between different browser interfaces. You're just going to nod through the whole show? No, I told you I didn't know anything about the adapter pattern. Oh, okay. So I thought I was going to let you run that one. I mean, I know about it in the way you're describing it now, but I have never used it formally. And so what does knowing about the adapter pattern give you?

I'm flipping through pages to actually look this up in the book instead of making you use whatever I have in my memory, which may be not that great. Do you want to use that book or the friendly book? Okay, so we have two books here. We have Design Patterns, Elements of Reusable Object-Oriented Software from the four people who wrote it. And then we have the Head First Design Patterns from a whole bunch of other people who read it. The Head First Design Patterns is a thicker book, but it's much friendlier. And they use examples. You were talking about examples with me earlier.

It's all coffee shops? Some of it. It depends. The examples vary depending on the pattern. But sometimes the idea is that you're running a coffee shop or you're building a coffee shop server and you have to do, like you have drinks and their coffee and their tea and they can have marshmallows or whipped cream. And so you have to build a whole model of what everything is. And then they all cost different things and they use this analogy that's relatively understandable to help you through the patterns. Whereas the hard book, the Gang of Four book, is just a wall of text with occasional UML drawings.

Yeah, it's a very serious academic text. It is. And they do add, I mean, they do have examples. Consider, for example, a drawing editor that lets users draw and arrange graphical elements, lines, polygons, text, etc., into pictures and diagrams. The drawing editor's key abstraction is the graphical object, which has an editable shape and can draw itself. I feel like we're going to talk about the adapter pattern. No, that is this is the intro to the adapter pattern. Okay, then. Maybe use the friendly book.

Okay, so in their description, the editor defines a sub shape and a line shape for lines and a polygon shape for polygons, and blah, blah, blah. And these all provide the same interface. And you could do that through inheritance, or you could do that through NC. You could just do it with a, this is the interface.

And if you are running on different hardwares, you compile it with different things. This is what pound defs are for. It's like inheritance through pound defs. That's really a bad idea. I think I just broke my brain. Anyway, so it's the idea that you're wrapping things in code so that you have one interface even though underneath you may have different implementations. Yeah, and that's different from,

you could do that with inheritance where you end up with a base class and then with certain functions that need to be filled in and then subclasses that add on to that. But inheritance is kind of gross and bad in a lot of cases. So this is another one of those patterns that kind of gets away from that. Right?

Yeah. By doing things slightly differently and not having things inherit from base classes. But that's an object-oriented thing. I do want to distinguish as we go that some of these can be done in C without object orientedness. And that they aren't. Or at least in spirit they can be done that way. And that

sometimes they fall under things that have nothing to do with object orientedness. Like having the wrapper be for different hardware. That is not language-specific. That is just what happens. So in this book, there's the intent and there's the also known as wrapper for adapter, the motivation, why you're doing this, what it applies to, and then it goes into the UML diagrams and the structure and the participants, blah, blah, blah. And then the consequences. And some notes on implementation. And that contains some gotchas.

And then they give some sample C++ code, which of course you can just page over, man. Well, especially since that book came out in... Forever ago. I was barely out of college. 1994? Yeah. You weren't out of college. Was it 94?

I thought it was. Maybe it was 98. I thought it was 98, but what would I know? Copyright 1995. No one's right. Well, okay. So we weren't out of college. Christopher's right.

Well, I was sort of right. I was right-ish. Right-er. Yeah, so C++ and other languages have moved on from that. So the implementation, I would be careful using that book's direct code examples. Yes, and Wikipedia has all of these. There are more patterns. There are newer patterns and a lot of more modern languages, Java, Swift,

what have you. Indubitably Rust. Rust is not object-oriented. Yes, but it's the best thing ever. Kind of know about patterns and have not baked them into the language exactly, but they expect things to be done in a pattern-y way, and there's

features of the language that encourage that. So C++ came before the design patterns. Yes, and C, of course, did also. But it was the only popular object-oriented language at the time. So at the end of this chapter, there's related patterns. And one of the related patterns to the wrapper or adapter is the decorator pattern. And this one I actually saw recently or have been thinking about implementing recently. I have PIC32 and we run FATFS, which is an embedded FAT file system. It has a specific way of handling the files such that they can't just be used with

the standard IO F open style interface. I have to do a little more in order to implement those. Now, if I decide I want to implement things that can then look just like F open and all of the other functions that you get in the standard library. I can, I just have to be a little smarter about it. And so I can make a decorator pattern that adds intelligence. It's a wrap, it's a wrapper, but it's a wrapper plus some extra goodies that make it so that you can, uh, do some underlying things.

And Christopher doesn't agree that that's what the definition is. I'm fine with the decorator pattern, but we can't just talk about it like that. Why? Because we haven't defined it at all. You were talking about the adapter pattern before. I know, and when I look in the page on decorator, it says also known as wrapper. So what were we talking about adapter?

It also says also known as wrapper. Okay, that's the show, folks. I hope you enjoyed learning about design patterns. And you know, the thing is, this isn't easy. This isn't obvious to us. I read this book a couple of years after it came out. I read the Head First Design Patterns book less than a year after it came out. So I've done this twice, and I care about this stuff.

And I don't use it every day because I work in embedded systems, and it's not really all that obvious all the time, but it's here. Okay, here's the headfirst resolving this dilemma. Okay. Remember the decorator pattern? Okay, this is in opposite order, sadly. We wrapped objects to give them new responsibilities. So you take a drink object and then you add a topping, a member that's a topping object.

So it now has a new responsibility. It's a drink with toppings. It's not inheriting, but that's what decorator does. You wrap objects and objects. And in my file system... Nope, nope, I'm headed there. Okay, go ahead. Now we're going to wrap some objects with a different purpose to make their interfaces look like something they're not. Right. That's the adapter. So your fat file system is the adapter because your interface is going to be something it's not. See, I still think the CMSIS is the adapter, and my file system, because I have to add stuff to it,

is the decorator. We can adapt a design expecting one interface to a class that implements a different interface. That sounds like what you're doing with the FAT file system. See, I always think of adapters as pretty one-to-one. And it's just like changing the format of the... I think APIs is pretty much adapters. Okay. And Decorator is a structural framework.

So how about those circular buffers? Yeah, let's go back to circular buffers. I hope people are still listening. I hope that they understand that this is, A, it's not easy. B, it's not obvious. Well, these were not the patterns I wanted to start with. To be fair, these are...

Okay, what patterns do you mean? No, no, I'm just saying we're not perfectly well-versed in these. I thought I knew them. You do. You do. What is happening over there okay uh what okay so what patterns do you i thought we should start with something simpler

especially than rappers it's just changing names and stuff okay go ahead so obviously it's not because there's two of them and they mean different things. But the same thing and we can't decide which is which. Okay, okay. Do you disagree? No, I don't. Yeah, I don't disagree. I mean, people can read these

themselves and decide where they apply. But then you're going to go to the observer pattern and I'm going to have to explain that it isn't really the subscriber publisher pattern even though it kind of is and it sort of isn't. Why isn't it? Okay, tell me about the observer pattern. Observer pattern is where you have an event-producing object or a thing. I'm going to use object loosely, even though it can mean a struct in C or a loop in C, something that produces events.

So you have some entity that produces events, and you have other entities that want to consume those events and take action on them. And you may have more than one. And so you have basically an API where interested parties can register with the event-producing party, and it will send messages. Message method is not defined.

It could be actual messages. It could be function calls to notify those people, those entities. And the concrete example, I always go for the concrete examples here, is you are a newspaper producer. I want a newspaper delivered to me every day. I subscribe to your newspaper and your newspaper comes to me every day. And that is the observer pattern or it's the publisher subscriber pattern, which makes a lot of sense with that. So is there a publisher subscriber pattern? I've never, of sense with that. Is there a publisher-subscriber pattern? I've only seen it referred to as observer formally. See?

Well, in the Gang of Four book, it says also known as dependence and also known as publisher-subscribe. There you go. But on the internet... Well, the internet's bad. It said there's a difference between publisher, subscribe, and observer in that the observer calls everybody and says, hey, I have new information for you. Publisher, subscriber is more like the robot operating system

in that it sends the information out, it posts it, and it doesn't care who listens to it. Somebody else is in charge of setting up the listener system, the subscriber system. And so it's a push versus pull sort of thing. I guess so. Don't you think that's an important distinction? I mean, that would change how you implemented your whole memory system and your code and it would have different error functionalities, error things.

It just seems like they should be different. I think they're different, but I think the pattern is not necessarily different. It's still the idea. I think the pattern sits above that. I think that's an implementation detail. Okay. But again, this is... I mean, it's still connecting receivers with a sender, whether it's an intermediary or not.

And whether it's push or pull doesn't matter to you? I don't think it matters to the pattern. It matters to me when I'm implementing, certainly. Okay. So some people say that the publisher subscriber is the subscriber is in charge of getting the data and the publisher is just in charge of putting it in one place and the observer collects all of the subscriber

information and sends it directly, maybe through callbacks. And so you can see how closely they're related. And you can see how Chris and I don't really quite agree. It's not that we don't know what these are. It's that... I feel like we're not selling these very well. Nobody can agree. The whole point of them is to try to agree on common definitions.

But we can agree on the big things. Yeah. And the big things of this is a good way to handle asynchronous information, especially when you have multiple different receivers i mean okay don't redesign that from scratch from for yourself at least read about it yeah uh okay do you have other patterns you want to talk about um yeah there's a couple more i mean the single hand pattern comes up a lot right and i know people don't like it, but in embedded stuff, it's pretty useful. Yes, and if you want to know what the singleton pattern is in its most stripped-down form, it's a global variable. Kind of, but it's a global... No, okay. It's not, though.

Okay, tell me. It's a global object, but that you can access without having to expose like a global... It's not exposed as a global variable. Okay, the Gang of Four book summarizes it as a creational pattern. We haven't really talked about creational versus structural versus behavioral. We're not going to. Ensure a class has one instance and provide a global point of access to it. One instance and only one instance.

So if you have, for example, an object which is a device driver for your I2C bus, you want maybe a whole bunch of people to be able to access it. And you may even want a whole bunch of people to admit it. So that somebody actually does. But you don't want it instantiated multiple times. And this guarantees there's only one in the system and everybody knows how to get to it. And it's not getting to it via a global variable

that everybody includes in header. The class itself provides a method to say oh i exist and here's my here's my instance yes so it's not a global it's a global entity but it's a global entity with access control yes okay anyway useful for device drivers and things that map to hardware where i know i have one of this. Yeah. Yeah. And it is one that is more object-oriented to me because it tends to be a problem that comes up more with objects.

If you're writing straight C, you just pass in I squared C1 or I squared C2 either as a structure that has information or as a pound def that ends up telling you which piece of hardware you're using. And so it is more of an object-oriented problem because if you were doing a truly object-oriented system, you might be creating a whole bunch of objects. And if they're all trying to instantiate an I2C object, and it all

goes to the same place, you can't fight, fight, fight. No good. And so the singleton alleviates that problem, but it's a problem you don't have outside of object-oriented languages. Yeah, but people

tend to not like the singleton in more modern code. Because it's a global variable. Well, it does have some of the issues with global variables, yeah. And I think there are other ways to do that that are a little bit better. But dependency injection, I think, is one of the ways of getting around it. Ooh, tell me about dependency injection. I think, is one of the ways of getting around it. Ooh, tell me about dependency injection. I'm cutting that. Dependency injection is a gigantic term for passing in your dependencies when you initialize

something. So if something depends on... You have to use it without, you have to explain it without the word dependent. Well, dependent is kind of important. So if I have a thing, an object, that needs a database, and it needs to look things up in the database, when I create it, I pass the database into the constructor,

the reference to the database. And so it has a little variable inside it that says my database, and when you call init with database, it says my database to the database. And so it has a little variable inside it. It says my database. And when you call init with database, it says my database equals the database that's passed in. And then from then on, it can use it. That's it. It's funny.

That sounds like so complicated. The dependency injection is like this magical mystery thing. But people do much stupider things to connect things up is the point. Yeah. And this is like in C, if I had, I don't know, let's go back to an I squared C driver, but I didn't know which one I was using. I didn't know if it was I squared C1 or 2. And I had a single interface that implemented all of them,

but I implemented two objects that carried those interfaces. And I just passed in to my IMU object, use this I2C bus. This is all very what, this is, I mean, if you're using Arduino, this should sound a little familiar, actually. Dependency injection is passing in... Your dependencies. Your functional dependencies.

Yeah, yeah. And it's usually an object, so it usually has both data and functions. It can't be just context. It can't, actually, you know, that's a really good word to use because in a lot of embedded systems, it's like the first variable you pass in is context. Yeah, and that's a common way to get rid of global variables is instead of having a file with a bunch of global variables at the top, the first step is to make a structure called context and you stick all your global variables in there and instead of having people just be able to grab it from the stack or bss or wherever you've got it uh you pass it around when it's needed to the functions and so a lot of code i've written in the past even before knowing about design patterns many of the member functions or the constructors were had an argument with context and you pass it in and so you kind of hand that around and it's almost always a pointer yeah and

usually you have a fill context or it just happens during a knit and you can have different ones and you can get more sophisticated and you know eventually you end up with the same problem you have global variables where you've got a hundred element context structure and time to pare it down and split it up and stuff but well and a really good example of this is the file pointer yes yes exactly in f read yes nobody nobody thinks about what's in that no it's just a it's just a black box but you're yeah it's the same thing you're passing around that's dependency injection so quit being afraid of those words. And it can be opaque to the user. I think that's one of the best parts about it.

Here's this thing. Oh, this is the file reference handle. The file reference handle is actually a way to get at a huge amount of data that the other thing needs, but there would be no other way for it to keep around and be specific. But that's not a design pattern, dependency injection. Is it?

I don't know. Was this the one we were looking for before the show started and we couldn't find whether or not it was a pattern on its own? It is a technique. It's a technique. So it is not a design pattern, but it is a technique whereby you can get around some design patterns that people don't like anymore. Actually, it says, here it is, the dependency injection design pattern solves problems like how can an application be independent of how its objects are created?

How can the way objects are created be specified in separate configuration files? That's a good one. And how can an application support different configurations? The nice thing about this, where you use the example of the I squared C, is I can pass in a fake I squared C. Right, and it's really useful

for unit testing. Right. Whereas if you hard code everything, you're kind of out of luck if you want to mock something. So that's apparently a design pattern. God, the term is so just... The problem is, I think colloquially design pattern is used for all kinds of things.

So many things. But then there's the design pattern, capital design patterns, which people talk about, which they mean from the book. And so it's never clear which people are talking about. And then there's newer design patterns that have come after the book that aren't in the book, but are just as big and capital I important in software development. You were looking for a delegate pattern.

I'm like, no, that doesn't exist. And yet we sort of found it. Do you want to talk about that one too? Yeah, well, that's, it's, this is something that happens in C a lot and it's sort of related to kind of observer, but not really. It's sort of related to adapter,

or decorator, but not really. It's basically just having a callback. So I have one entity or object that does something, but it might have five subtasks it performs, but it doesn't know how to perform them. And so you provide other functions from another object that perform those things. So as an example, in a UI, let's say you have an object which knows how to draw tables. So at its most basic, you provide it with a list of cells, and it goes through that list of cells and draws text. But let's say you want to add an icon to each of the cells. That's a fairly ill-defined thing. You don't want to put that functionality directly in the table object. But what you can do is you can say, okay, the table object will have a delegate

for drawing an icon. And when I set it up, I will say, my other object that knows how to draw icons will implement that for you, and you hook those function pointers together. And so now the table object, when it's going through the list, will say, oh, here's my thing, I know how to draw text, and do I draw an icon? Yes, because my delegate's filled in, and it's this guy over here, and I'll call him. And then it comes back.

The guy he calls draws the icon, and then it comes back, and then it continues on. So if you think about it, it's really kind of a list of functionality that your object can provide, but is not specified. And when you set things up, it wants to point to some other, some other delegated object to do it. So that, that's not a great explanation. Can you do with coffee drinks?

I mean, cause so far it's like there are functions and they do functiony things. And maybe there's a function pointer that sometimes gets called and sometimes doesn't, and it can point to different things. Is it sort of like... It's another way of getting away from inheritance, first of all. So instead of having table with icon, subclasses from table,

table just has a function pointer that says draw icon, or not even draw icon, draw extra stuff. I don't even care what it is. And when I instantiate my table, I say, hey, the draw extra stuff, that's in this class over here. And you go ahead and call that. And don't worry about what it does. It's just going to draw the extra stuff. And so you don't have to have a specific subclass for every kind of extra stuff you might draw. And so if we were making coffee, if I have this right, I have a make coffee object.

Yeah, yeah, you got it. And in order to make coffee, I have to get cup, pour drink, add topping, and charge. So have a price for it. Yeah.

And then in the delegate pattern, I... Add topping might not be populated. Add topping might not be populated. Add topping might not be populated. Poor drink might come from the coffee pot. It might come from the hot tea. It might come from making a smoothie, but how,

and so the deli that's delegation is being able to say, I have these five things or four things I need to do and what I'm actually going to do with them. You know, not your problem. How do I instantiate that? If it was inheritance, I would know how to instantiate it. I would say, okay, smoothie. It depends. It depends on what you're doing. So sometimes you might pass it in, in the constructor. Oh, okay. So I might have a drink class, and then I have this drink pointer that gets passed in through dependency injection. Yes. Yeah, yeah. I mean, the easy example is the topping. Topping is the thing that we're going to delegate.

And so your init says, you know, init drink with topping provider colon whipped creamer. Okay. And the whipped creamer class knows how to add the topping to the drink. But the drink class, when it gets to the time, says, oh, here's my thing, I'm going to call this, that was passed into me. And so if I do this right, I can just get a whole cup full of whipped cream. Yes.

Gross. Gross? Okay, so as maybe you noticed, I definitely am a proponent of whatever the pattern is, try to make it as physical as possible. If you can make it out of Tinker Toys, you've got it. If you can make it out of Play-Doh. These things are so thinky and hard to understand that if you can make it with a coffee thing or make it something you can explain to your kids or, you know, your stuffed animal. But you can see why these are not just best practices.

No, and there's things we argue about. They don't provide you necessarily with a cookie cutter, well, here's what you do. You have to understand this is a pattern and it can be applied in many, many ways for different situations. And they're, they're much higher level and more abstract than best practices I'm used to, like, you know, semicolons at the end of lines or, you know, keep, keep functions to one page or less or, uh, you know, yeah. Yeah. So I think just encouraging people to read the books and maybe do some do some research it will make you a better developer because you'll be able to talk to people who

do know this stuff you don't necessarily need to internalize all this or believe in all of it not asking you to believe not asking you to believe uh But there's definitely, I find some of these ridiculous. I, you know, yes, absolutely. Looking through the headfirst book, you know, maybe half of them I think I look at and go, you know, that's really useful and I should remember that. And know it when I see it and maybe apply it in designs in the future. And maybe half are like, okay, that's weird. And maybe it's useful for something. And maybe it's useful for something that I just don't understand or haven't encountered. Yeah. I have a whole rant about the flyweight pattern and fonts, but I'm not going to inflict

it on you today. Maybe another time. Do you want to talk about the model view controller, which is not a design pattern in the design pattern books? No, it isn't. There's a lot of UI design patterns that came pretty recently, I guess, recently, like that in the last 20 years.

Well, this is older than 20 years. Yeah. So you're going to encounter other design patterns, as I was saying, that aren't in the book. And if you ever do any UI stuff, model, view, controller, model, view, view, model, model, view, view, model, coordinator. But things that have model view, those tend to be UI things. So one that's very, very, very common and that Apple uses a lot and other people used a lot that's sort of falling out of favor, but it's a good starting point, is model view controller. And that's a separation of

responsibility kind of pattern, rather than when you design a UI just mishmashing everything together in one place where the data that provides the, that you're going to use to draw the UI is in kind of the same code as the, that ui is in kind of the same code as the that draws it is in kind of the same code that handles events and you know the kind of code i'm talking about you've all seen it where you have just maybe one function that does everything yes oh absolutely and it's it is you know it's the function that puts the pixel on the screen, knows where the pixel should go, and knows how to move the pixel for the next screen. And it's all just one function. And it isn't super mathy.

And it knows where the pixels are coming from, from some data somewhere. Yeah, it's all one function. That's really hard to maintain. It's really hard to change, update. You can't change how things look because it's all tied together deeply. You can't change how events are handled because it's all tied together deeply. And you can't change what the data does because it's all tied to how you draw things. So a model view controller is a pattern by which you separate all those things.

And you separate it into three surprise things. The model, which has the data that the UI is going to represent. And this should have no UI stuff in it at all. It's your database. It's your table of names. It's your whatever. But that's just data. You have the view, which is the code that does the drawing. It's responsible for laying out the view. It looks into the model or gets updates from the model, maybe via delegation, maybe via the observer pattern. See, these patterns can intertwingle. But the view talks to the model to get its data to draw. And then the controller

is what sits between the user and the data. So when the user types something, the controller is what sits between the user and the data. So when the user types something, the controller handles that event, updates the model, which updates the view. So the controller is kind of the event handler. So in the very nice Wikipedia diagram, you have the user using the controller to manipulate the model to update the view which is then presented to the user.

So you push a button, the controller handles it, adds one to the number that it's supposed to be showing, sends that data, that number, to the view which pulls it out of a font bucket and pops it on

the screen. And that's Model View Controller. The great thing about this is you can change the model. Let's say your data's the same, but you change from SQL to grumbly... Postgres? Postgres. Postgres, or NoSQL.

You change the underlying database. Now you just have to change the model. As long as your interface is the same to the view in the controller, those things don't care and you haven't broken anything. You could change the view. Oh, I want this to run on a totally different LCD. Totally different platform. Totally different LCD.

Totally different UI library that looks different. As long as you've done your interface the same or interface well, you can rip that piece out and replace it. Same thing with the controller. Well, I have a touchscreen, I have a keyboard. Yeah, you may not even have to update the controller much if you have a really good view, because you may have named the events. Yeah. You know, pushbutton X doesn't depend on whether X is a touchscreen or X is an actual button.

Yeah. And as you might expect, people have gotten tired of this pattern and have replaced it with other things that get more and more complicated. But it is so good to know about because it says separate into these three things and you won't regret it. And that's kind of one of the core things about design patterns is separating responsibilities. And separating them in good ways yeah and making it so you can refactor things without having to tear everything apart so and it's based on experience of lots of people and not just thinking hard not just thinking hard i mean experience and thinking hard okay Not just thinking hard. I mean experience and thinking hard. Okay, I'm done with design patterns. Yep, please let us never do that again. And for everyone who asked, you're to blame.

Yes, indeed. Let's see. We should do KiCad for sure. Okay, let's do that. So there's a conference in Chicago. Chicago, Illinois. Yeah, Illinois. Yeah. Oh.

It is April 26th and 27th of 2019. That's this year. Okay. It is put on in large part by Chris Gamble, who we've had on the show a number of times, although he is on the Enemy podcast. Why do we keep calling it that? It's fun. It's a rivalry.

I don't know. Anyway, it looks like he's doing a great job putting this conference together. We sponsored it. And there's a lot of, if you look at the speakers, there's a lot of speakers who sound very interesting, and you don't have to be a KiCad person. Some of the talks are general design talks and cool stuff.

So it's a hardware conference. It's a hardware conference by way of KiCad. Yeah. So I think that's pretty cool. And you might learn whether it said KiCad or KiCad. I don't know. Whatever. And we have one ticket to give away.

Okay. Christopher is in charge of giving it away. Reginald P. Theodore Johnson, congratulations, you've won. If your name is in fact Reginald Johnson, you don't even have to have the middle initial P, and you are going to be in Chicago in April and can go to the conference, the ticket is yours. If you are not so named or not available for those dates, and you would like a ticket, send me an email. Just say you're available, and I will push you in a random number,

and someone will get the ticket. But don't just enter if you're available and I will push you in a random number and someone will get the ticket. But don't just enter if you're not sure. Conferences. We went to Bang Bang Con. Yeah, that was interesting. It was different. It was weird. It was cool. It was all those

things. It was all those things. It was cold. It was also cold. It was just so weird in California. Not their things. It was cold. It was also cold, which is so weird in California. Another fault, but... And they were planning on normal weather, which would have been perfect if it hadn't been kind of cold. But yeah, lots of 10-minute talks about very random things, some of them quite serious, and some of them kind of da kind of dada in their well i did this thing and i don't really know why but isn't it cool and yes they were cool but i don't

know why they did them uh which i think is the spirit of the conference in some ways like oh i reverse engineered the language system for this rpg from 1992 that only ran on some hardware that no longer exists? Or what was another one that was super cool? Oh, I implemented fractals in SQL. Yeah, things like that. I mean, there were things like that, but there was also a talk from somebody who's going to be on the show, Simon Porter, talking all about how they figured out where, what's the name of the... The Pancake Kuiper Belt Object. The Pancake Kuiper Belt Object, whose name completely escapes me now, that New Horizons flew past. Yeah.

And how they found it and how they figured out how to set their trajectory. And it was a really hard problem. And I really wanted that talk to be about five times longer. Well, and poor Simon was having lunch. And so he was stationary. And I completely, like, I forgot to say hello. I forgot to say, how are you? I forgot to say, good job.

I was just like, okay, now you're going to be on a podcast. Are you ready? And instead, he was taken aback a bit. But I think in the end, he's okay. And he's on the schedule. And yeah, there were a lot of talks that were just, I like this thing. Here's why. Well, the opening keynote was an entire talk about all the things I like.

And it was really good. I enjoyed it because it made me start thinking about things that I like. And I came up with things I didn't expect. Yeah. But it was exhausting. And I was tired after one day. Ended up watching the second day on the live cast. And you went the second day.

I went for most of the second day. It was an exclamation point sort of thing. Yeah. People who believe in exclamation points. Yeah. But, yeah, I encourage you to go to, I think there's one coming up in... New York. May in New York.

So, check that out. And I think it's not expensive. It's like a pay, pay what you want sort of thing or minimum something. It's pay what you want. Actually. So if you're broke, you can,

you can still go. You just have to manage to get a ticket. Yeah. Um, this is not huge. So I don't know if the New York one is, it's probably somewhat bigger, but this wasn't this was

a few hundred people not thousands okay uh let's see um well i have some python things i can rant about or we could close up the show and i could go fix those python things well if you want to rant about the python things in the hopes of having people help you. But if you don't want people to help you, then... All right. Well, one thing from BangBangCon. There's this thing called PyFlix. And it's a static Python checker. And it's really easy to run,

really easy to use, download, pip install. And it looks through your file. It says if you have any imports you're not actually using. It says if you have any variables you're only using once or that aren't otherwise defined. Now, for me, it's often in my error handling that I will forget or that I don't have access to a variable that was in a different function or I will misspell a variable. And I won't know until the error case happens. And then I get an exception instead of the thing that I actually wanted, which was why that error case happened. And so PyFlix tells you a lot of that stuff.

And it's a single file thing, so it won't look between files. It's not going to tell you running slow. There's also PEP8, which tells you if you're conforming to the PEP8 standards. I guess there's a PyFlix8, which may do the same thing. There's also Pylint, but PyLint was big and it looked like a lot of configuration. And I have to admit, PyFlex was just enough for me. I'm working on a small project, not a lot of people, nobody wants to add any overhead, but I am tired of misspelling Python variables. So it was something I learned at the conference. It was in the last five minutes I was there, and somebody told me about PyFlix. It was pretty cool. Okay.

And then Python profilers. That's probably a whole show. Okay. I know nothing about Python, except I've used it to manipulate files and text, but I'm about as far from a proper user of Python as you can be? I have a system that is robot operating system, TensorFlow and GStreamer on a TX2. And I want to do baselines so we can figure out how much bigger our TensorFlow things can get. How much bigger our algorithms can get. And the built-in C profile, which is the Python built-in profiler, can't do threads.

And I have threads. So I got YAPI, which does threads, but it only does standard threads. It doesn't do G streamer threads so i tried to get pyflames because it's called pyflames sounds cool uh and it's a statistic instead of deterministic uh profiler which i know we've talked about on the show so i'm not going to go into it and i can't compile it because it's for so someday soon i will either have a blog post or an enormous rant about how hard it is to profile python and all i want to do is just i mean so far top has given me the best result that's not good no so yeah if anybody wants to talk about python profilers i'm all over that as in over okay uh he's giving me like the nod like and he's gone back to playing with his phone so somebody's

chatting with me it's my manager so you know i probably should talk to him time for me to read winnie the pooh thank you to everyone who's listening. Thank you to our Patreon supporters. We really, really do appreciate you. It's amazing how much easier it is to send microphones to people when you're paying for them. And how nice it is to chat with you on Slack. It's a lot of fun. So now we have winnie the pooh aha said poo rum tum tiddle a mum if i know anything about anything that hole means rabbit

he said and rabbit means company he said and company means food and listening to me humming and such like rum tum tum tum. So he bent down, put his head in the hole and called out, is anybody home? There was a sudden scuffling noise from inside the hole and then silence. What I said was, is anybody home? Called out Pooh very loudly. No, said a voice and then added, you needn't shout so low. I heard you quite well the first time. Bother, said Pooh. Is there anybody here at all? Nobody. Winnie the Pooh took his head out of the hole and thought for a moment, and he thought to himself, there must be somebody there, because somebody must have said nobody. So he put his head back in the hole and said, hello, rabbit, is that you?

No, said rabbit, in a very different sort of voice this time. But isn't that Rabbit's voice? I don't think so, said Rabbit. It isn't meant to be. Oh, said Pooh. He took his head out of the hole and had another think, and then put it back down and said, Well, could you very kindly tell me where Rabbit is? He has gone to see his friend Pooh Bear, who is a great friend of his. But that is me, said Bear, very much surprised. What sort of me? Pooh Bear. Are you sure? said Rabbit, still more surprised.

Quite, quite sure, said Pooh. Oh well. Then come in. Embedded is an independently produced radio show that focuses on the many aspects of engineering it is a production of logical elegance an embedded software consulting company in california if there are advertisements in the show we did not put them there and do not receive money from them at this time our sponsors are Elegance and listeners like you.