Jeff Terrell: Okay sorry for the delay.
Jeff Terrell: i've been a little bit behind if you haven't noticed already i'm just trying to get stuff deployed actually what I would have been ready earlier but somehow I just forgot to actually push the commit.
Jeff Terrell: These changes anyway, here we are a little bit late, but here nonetheless hope everybody had a good weekend today we're going to talk about architecture and simplicity today's actually Monday night Wednesday issue to know.
Jeff Terrell: what's going to play some music, but that ran out of time, so that's you, it was a good choice because we're going to talk about how components are stuck in the middle of a system so it's going to play stuck in the middle, with us dealer school Oh well.
Jeff Terrell: In case you didn't see grades are up to date as of Friday i'm probably not going to be keeping those up to date, like every day but i'm going to aim for like weekly having them up to date.
Jeff Terrell: I haven't actually gotten any emails about the great it's so maybe actually got it right, this time, they didn't even make any mistakes might be the first time ever, but if you do have any questions or anything obviously feel free to email me.
Jeff Terrell: Some of you may be chomping at the bit to get started on your project and hurry up and start coding already, and maybe you feel like all of us.
Jeff Terrell: Different assignments are just getting the way of actually getting real work done if that's you, you can start coding it's not it's not too early.
Jeff Terrell: But if you don't feel that way and you're focused on the assignments that's totally fine stay focused on the assignments, they will guide you in the things that I think are important in working on this project.
Jeff Terrell: So if you if you haven't thought about coding, and now you're stressed out because I mentioned that don't worry you're doing fine.
Jeff Terrell: Remember quiz two is going to be on Wednesday.
Jeff Terrell: Okay, as far as assignments, I think all of you know that assignment through the user stories were do this morning, so hopefully you get those up on your website Raj I assume is busy looking at those over and grading them.
Jeff Terrell: I sign up for is due next week that's the clickable prototype, and that is a for tough assignments that might be some significant amount of work for you you've been warned about that, before, but some you know, hopefully you're making good progress on that.
Jeff Terrell: Some of you might have actually started already in your project with a clickable prototype for your client created so lucky you.
Jeff Terrell: But some it might still be worth prototyping the things that are you're going to add.
Jeff Terrell: OK, the next assignment after that is apple's reflection, one which is pretty easy and needs to know what clicking for me.
Jeff Terrell: assignment, six and seven are do October 4 the following week and today i'll be doing my best to equip you for those assignments, and then next lecture, I will start a quickly new for assignment ain't the walking skeleton, which is a bigger deal.
Jeff Terrell: The only five assignment.
Jeff Terrell: Okay.
Jeff Terrell: So any questions about assignments or announcements or anything else so far that i've talked about nothing.
Okay.
Jeff Terrell: we've got more people in slack today and fewer people here interesting hope everybody's feeling healthy and everything.
Jeff Terrell: Okay architecture concepts well today we'll talk about architecture concepts will talk about just diagrams in general and give you some examples of diagrams that might be helpful, but also in a.
Jeff Terrell: way of thinking about diagrams to decide whether it actually makes sense for your project or not to add this diagram or that one.
Jeff Terrell: And we'll see architecture diagrams different examples of architecture diagrams and listen to some.
Jeff Terrell: Well we'll discuss some tips on what makes an architecture diagram good.
Jeff Terrell: And then, at the end of lecture we'll talk a little bit about simplicity and what that means, and why that's important for some of the choices that you make about your architecture.
Jeff Terrell: let's talk a little bit about concepts here just to lay the foundation.
Jeff Terrell: was actually a fun I didn't intend, but anyway so architecture is going to describe the structure of a thing it's not going to necessarily get into all of the details of.
Jeff Terrell: You know what it's made of or or different things like that, but it has been talked about the structure of the thing and that's pretty important when you're starting out and you have choices to make about.
Jeff Terrell: You know what technologies to use and how different pieces of your project are going to relate to each other.
Jeff Terrell: The thing being described in this case is a system with multiple components.
Jeff Terrell: And when I say system What I mean is a combination of multiple things working together towards a shared purpose for each thing can affects the others Okay, so this is.
Jeff Terrell: We see examples of this, all the time.
Jeff Terrell: And I think it's worth digging into this definition, a little bit so multiple things working towards a shared purpose, so the system as a whole has a single purpose that all of its component pieces work together to do.
Jeff Terrell: And all the pieces can affect the other pieces and in fact should affect some piece or other otherwise there's no point in that component being in a system.
Jeff Terrell: i'm before I do the examples i'll skip down to the bottom, a component is a part of the system, this is classic engineering speak if you did any sort of engineering anywhere electrical engineering industrial engineering civil chemical.
Jeff Terrell: Maybe not I don't know probably so chemical.
Jeff Terrell: petroleum engineering I don't know there's all kinds of different engineering and all of these are going to be talking about systems and components and so it's a pretty abstract way of talking about this, but it absolutely applies to larger software applications.
Jeff Terrell: And so yeah component is a piece of that system and a component necessarily interact with at least one other component.
Jeff Terrell: right if it's going to be working towards a shared purpose, along with its other components, then it needs to be interacting with at least one other component otherwise there's no point of it being part of the system.
Jeff Terrell: Okay, so, for example, the electrical system of a house is a system.
Jeff Terrell: So, think about the pieces of the electrical system of a house.
Jeff Terrell: You got some source coming in, maybe a power line coming into the House you've got a breaker or maybe a panel of different circuit breakers.
Jeff Terrell: you've got wiring in the House plugs.
Jeff Terrell: devices and appliances plugged into those plugs is that lets.
Jeff Terrell: You got switches light switches dimmer switches maybe all those things work together.
Jeff Terrell: One of the ways that you can notice that things work together, even if you don't get into the details of how this is actually implemented a house is Have you ever noticed your lights Deming when some high power of clients kicks on.
Jeff Terrell: plug the vacuum cleaner and or something like that, and the lights kind of flicker a little bit.
Jeff Terrell: Well it's drawing a lot of current and it's it's drawing a little bit of current away from the the lights, or maybe voltage i'm not quite sure, but anyway, you can tell that they're connected, because you can see effects like that, if you really pay attention.
Jeff Terrell: Another example kind of analogous example that instructors everywhere have used to describe electricity is water and water pressure.
Jeff Terrell: So the plumbing system of a house or even have this whole building we've got how many how many sinks and toilets do we have in citizen.
Jeff Terrell: And they're all connected right there's a single I assume a single source of water coming into the building.
Jeff Terrell: And it's not even just water it's pressurized water right we've got a high pressure on that water, so that it can go up hill to get to maybe the level three bathrooms and things like that.
Jeff Terrell: um.
Jeff Terrell: And in a similar example so when a toilet flushes so I go around my.
Jeff Terrell: My office I take my water bottle around the corner and there's a little sync there and i'm feeling my water i'm there.
Jeff Terrell: And sometimes I noticed the water pressure just drops for just a second and I My suspicion, as if that's, why not toilet somewhere in the building flushes, but I have noticed that happen.
Jeff Terrell: And these are examples of systems right this again a combination of multiple things.
Jeff Terrell: toilets sings pipes some sort of pressure riser thing working towards a shared purpose or each thing can affect others that the faucet handles you know if that's a component of the system of the plumbing system.
Jeff Terrell: Another example would be any sort of living organism right how many different pieces make up our bodies like lungs liver heart.
Jeff Terrell: digestion respiratory rate respiration circulation blood and just you know bones and muscles all these different things are working together.
Jeff Terrell: In that case, it's a little bit less discreet, I mean I guess the organs can be pretty discreet, but some things like respiration or circulation are much more.
Jeff Terrell: Circulation I guess it's the biggest example, or the nervous system that's.
Jeff Terrell: All the way throughout the body you can't really separate out just the nervous system from the rest of the body you can't make a cut and say this is where the nervous system ends, and this is where everything else begins, but it's still, this is a component of the system right.
Jeff Terrell: Okay.
Jeff Terrell: So when you think that large about the entire project that you're working on and the application that you're working on.
Jeff Terrell: there's a lot of different things that your client will want you to accomplish this semester, and part of the what you've been wrestling with as you've got assignment three.
Jeff Terrell: has been to figure out, what are the need to have sort of a nice to house, you know let's prioritize these things a little bit.
Jeff Terrell: Even among the need to have there's still a large set of things.
Jeff Terrell: That you're going to try to do this semester.
Jeff Terrell: And we've seen this principle of decomposition in a lot of different places in in you know you've seen that in your major.
Jeff Terrell: different classes you learn about how to do, maybe object oriented modeling of some sort of a problem to figure out, what are the.
Jeff Terrell: classes, that I can create to tackle one piece of this problem, and so you decompose the problem into smaller pieces and then you write code to do those things right.
Jeff Terrell: So if y'all have done decomposition already, this is nothing new, but we're going to do the same thing here, and specifically the.
Jeff Terrell: The sort of abstract space that we want to partition up here is responsibility and I don't know, have you all heard of this like maybe in for one class or something like that, like this instructions ever talk about decomposing responsibility.
Jeff Terrell: Or maybe something else i'm curious, because I think responsibilities are particularly helpful way to talk about it i'm not seeing anybody kind of not at that so maybe this is new year.
Jeff Terrell: yeah when you think about what are the, what are the set of responsibilities that we need to accomplish here dividing those things up into smaller responsibilities can be really helpful.
Jeff Terrell: And that can give you a sense of where you're going to start to make.
Jeff Terrell: partitions make cuts between your different components how you're going to slice up this responsibility into chunks and assign each chunk to a component.
Jeff Terrell: So each component is responsible for at least one thing, it may be just one thing, but at least one.
Jeff Terrell: And each component might depend on others to do their part, so, for example.
Jeff Terrell: You might have a web APP and you're depending on the database thing up and running and the backend thing up and running.
Jeff Terrell: And if those things fail, those are separate components from the front end, but if those things fail the funding is going to be able to work as well.
Jeff Terrell: So that doesn't mean that storing database is a front end concern that just means that the front end depends on the back end and on the database.
Jeff Terrell: And, in some cases, you have.
Jeff Terrell: Cross cutting concerns and technical, in most cases, you have crossed my concerns meaning.
Jeff Terrell: You can't take a user story and say this component of my system is going to be responsible for this feature or this user story at the APP.
Jeff Terrell: it's not usually how it works in some cases, it does, maybe see if you have a user story about a user needs to be able to authenticate and you have a.
Jeff Terrell: section of your system component in your system is all about authentication so that does work, sometimes, but a lot of times you're going to say, well, I need to be able to.
Jeff Terrell: Follow somebody that's a user story and you're not going to have a component of your system that's responsible for following usually.
Jeff Terrell: Maybe it's like a sub sub component, like some function within a module within whatever but.
Jeff Terrell: at a higher level when you're thinking about the system and you're thinking about the primary components in that system you're going to have one of those components be.
Jeff Terrell: The follower or the thing that starts following users you're going to have something like the database or the Web service or the front end or these bigger things that apply to a lot of different stories, a lot of different features.
Jeff Terrell: And if you want to once you have the components figured out of your system if you have five or six or seven components in your system.
Jeff Terrell: You can actually dig into those a little bit deeper and decompose those further, and you can dig into one of those and decompose that further and eventually get down to the level of lines of code.
Jeff Terrell: But for the purposes of your architecture diagram assignment of course you don't need to do that.
Jeff Terrell: Okay, all this is pretty abstract I know it's it's kind of abstract it's a little bit hard to talk about some of this stuff in an engaging way, because it is abstract.
Jeff Terrell: And I would, I guess, maybe it'd be useful to talk about examples, but there are a lot of different examples for different projects like some people, some of you are working on a weapon a web APP or a mobile APP or whatever, but.
Jeff Terrell: Anyway, we'll get through the abstract stuff will see some diagrams here in a minute so that'll help it feel more more concrete.
Jeff Terrell: Okay, once you have partitions your space of responsibility up into different chunks and you have kind of defined what your components are.
Jeff Terrell: Then you need to start defining kind of what are the interactions between these components and it's not the case that every component has to interact with every other component.
Jeff Terrell: But each component does me to interact with at least one other person and otherwise it doesn't need to be in the system at all.
Jeff Terrell: So you need to start thinking about what are the interactions between neighboring components which components, need to be connected and interacting in some way if they are interacting what does that interaction look like and then a high level, you could just say like.
Jeff Terrell: Data flows from here to there from this component to that component, so the database, for example, you might say, yeah I I fetch data and I store data and at a high level that's good enough.
Jeff Terrell: If you want to get more specific about exactly what the interactions look like you can define an application programming interface, you know afford the term API i'm sure.
Jeff Terrell: This is not just like an API service like you can go off and I don't know interact with Google maps or something like that.
Jeff Terrell: That is an API and Google maps has said, you know here is how you can interact or, if you want to you know write a Bot for slack or or.
Jeff Terrell: write a Twitter Bot, or something like that yeah you can use the API for that postings and you need to go learn the diamonds there specified in enough detail that you can know what you how you need to write your code.
Jeff Terrell: But it's not just external API is that we're talking about here anytime i'm a component of your system is interacting with another component of your system that's an API.
Jeff Terrell: Somehow one component needs to talk to the other and it's a program or a piece of a program talking to another program or a piece of a program.
Jeff Terrell: So that's not a user interface that's an application programming interface, but it is an interface, and because we're talking about a program using that interface it's an API rather than a ui user interface.
Jeff Terrell: and talk picking about api's thinking about these interactions between the different components can help you understand.
Jeff Terrell: Where are the boundaries, where should the boundaries between these different funnels and there can be some negotiation of this right.
Jeff Terrell: Maybe you have somebody on your team, who is going to do the front end, you know somebody else is going to do the back end and you start thinking about okay exactly what is the API going to look like and you realize.
Jeff Terrell: i'm doing the front and I don't really want to be computing all the stats you know you have some sort of a statistics you know, maybe it's it's displaying.
Jeff Terrell: charts and graphs of some analysis of some data, the back end could simply serve the numbers up.
Jeff Terrell: And let the front and do all the statistics and grouping and everything needed to do to prepare the data for charting.
Jeff Terrell: Or the back end could do all of that, and just give even an image, or maybe just give the actual data points that need to go into that that chart.
Jeff Terrell: So those negation of those boundaries are negotiable, you can say, well, I don't want the front end to have to do that, I think that's more of a concern or maybe you say the other way, like well, I really think the furniture do that because the back and always trying to store numbers.
Jeff Terrell: You can fine tune these things.
Jeff Terrell: One thing i'll notice that if you define it in advance and again if the is kind of the next level of detail beyond just describing at a high level what the.
Jeff Terrell: interaction is, if you define an API you're talking about the particulars of how this interaction is going to take place, what are the messages that go back and forth, and what, what are the function names and how many parameters as each one has that kind of thing.
Jeff Terrell: If you define that up front, one of the neat things that happens is you can implement both sides of the API In parallel, the component that serves that API and the component that uses that idea.
Jeff Terrell: Right let's take a poll Where are you with respect to your architecture choices.
Jeff Terrell: enable this poll here.
Jeff Terrell: polivy.com slash Jeff terrell.
Jeff Terrell: Okay, so it looks like the most popular answer here is we've talked about it but haven't made most of our choices yeah.
Jeff Terrell: that's totally fine that's good place to be.
Jeff Terrell: For where we are in the Semester, some of you really don't have much of a choice on your project, so you actually have talked about it and made most or all of your choices already you're ahead of the curve.
Jeff Terrell: You thought about it but haven't discussed it much 14% and haven't really started thinking about it, yet 9% and and that's okay like I said the architecture decisions aren't do for like.
Jeff Terrell: Three weeks, I think, so you have plenty of time to so be thinking about this and discussing it with your team.
Jeff Terrell: For a bit longer.
Jeff Terrell: Any question about kind of the concepts that play in architecture.
Jeff Terrell: Okay.
Jeff Terrell: Once you explain it to our diagrams all right.
Jeff Terrell: um I think the last part was probably kind of dull, because it was so abstract, but I think this will be a little bit more interesting.
Jeff Terrell: Alright, so diagrams can definitely be useful right, I mean we've seen examples of diagrams that have a lot of information.
Jeff Terrell: i'm not, this is not something I consider myself to be very good at, in fact, I think the last couple of times that i've taught the course I think many teams have kind of struggled with.
Jeff Terrell: What what are what what kind of architecture diagram am I supposed to create was supposed to look like, how do I know what good is and i've gotten a little bit of feedback from mentors actually some people some mentors actually have.
Jeff Terrell: helped their teams learn how to think about architecture diagrams and give them them them some resources on how to create good architecture diagrams.
Jeff Terrell: And i've learned from that that's one of the neat things about this course, from my perspective, is that I get to learn from mentors and shore up some of the things that I don't understand as well.
Jeff Terrell: But this is newly expanded material, this is kind of what i've been working on this morning and why i'm a little bit late but um.
Jeff Terrell: But yeah so within a diagram, including the architecture diagram that you'll create for assignment six i'd encourage you to weigh the value against the cost.
Jeff Terrell: So the value is for one thing you get to clarify your own thinking, and this is a significant advantage of creating an architecture diagram even if you create it and throw it away.
Jeff Terrell: Sometimes just for this reason alone it's worth taking the time and making the effort to create a diagram.
Jeff Terrell: You have some fuzzy notion of what you're trying to do, or how things are going to relate, and if you take the time to actually specify it in a diagram you realize Oh, you know what I hadn't thought about how.
Jeff Terrell: The front end is actually going to interact with this other API that's that's a good point I need to think about that or different things like that just clarifies you're thinking.
Jeff Terrell: Another guy you, and this is the main value that i'm The main reason i'm requiring an architecture diagram from you, for assignment six is that well designs diagram can have a rich and rapid communication of some ideas.
Jeff Terrell: So you will be showing your architecture diagram when you do your midterm presentations.
Jeff Terrell: will be showing it when you do your tech talk to be showing it when you do your final presentation at the end of the Semester.
Jeff Terrell: And so, this is something that you'll throw up on the slide on the in the front of the class on the projector, and this will help everybody in the room, you know rapidly get on the same page with you about what your project is and what technologies are paying us.
Jeff Terrell: So it's a very.
Jeff Terrell: quick way to communicate a lot of a lot of stuff.
Jeff Terrell: And one of the people, one of the recipients of an architecture diagrams and can benefit from having it made is you future you you create it and you forget some aspects that maybe you haven't worked on oh yeah right that's what we're using the back end okay.
Jeff Terrell: But way all of those values against the cost of the diagram one is that they can be difficult to create, are we not too difficult, but you need to learn, maybe, how to use some tools or maybe you need to think about how to design a good architecture diagram we'll talk about that and.
Jeff Terrell: I will say that you can even just create it in PowerPoint or something like that plenty of architecture diagrams are created that way, the thing that you might not think about is.
Jeff Terrell: How do you maintain the diagram once you've created it.
Jeff Terrell: And it's not just a case of you know okay now i've made some change and I need to change the architecture diagram and change it, the actual changing.
Jeff Terrell: The diagram probably would not be hard as long as you had appropriate access to the source material, but the hardest part sometimes it's just remembering to do it.
Jeff Terrell: You created it and then you went off and forgot about it and changed your mind about something that actually affects the diagram.
Jeff Terrell: And now you come back and realize oh that's out of date, or maybe you don't ever realize, and so that just stays out of date and what happens if somebody comes along and looks that diagram but it's no longer accurate to what you did.
Jeff Terrell: might actually have negative out you.
Jeff Terrell: might set people off on the wrong path and be more harmful than helpful.
Jeff Terrell: Some new developer comes on a project some new 523 team next semester takes over your project and looks at the diagram that you created, but it has all the wrong technologies listed, because you changed your minds.
Jeff Terrell: Probably is a more harmful than helpful diagram at that point, how do you remember to update your diagram if it's out of date.
Jeff Terrell: Okay you've decided that the value is worth the cost let's look at some examples of diagrams that you might find useful in your project.
Jeff Terrell: And this will give you some ideas for things that you might want to do here's a cake diagram y'all seen stuff like this before.
Jeff Terrell: Like diagram.
Jeff Terrell: yeses and noes okay um cake meaning like if you have a layer cake multiple layers of ideas you're kind of emphasizing the layers in a diagram like this, I don't know how well, you can read those things from back there but.
Jeff Terrell: The bottom layer is technical infrastructure, the second layer is technical application services, and you have examples of each one of those things.
Jeff Terrell: Third layer application architecture and information architecture and then business architecture with things like it and operations and sales and marketing on on that top layer is an example, you might find that useful.
Jeff Terrell: here's another example, this is kind of like the networking stack a fella taken and networking force and seeing the.
Jeff Terrell: Different people are different models like a four layer model of networking or five layer model or seven layer model, this is similar to that you've got like a transport layer session layer the device layer and application layer and presentation layer
Jeff Terrell: And then you have examples of each one of these things, and these layers you have some some things that kind of cut across in different kinds of events cut across multiple layers.
Jeff Terrell: here's another example I don't really understand a lot about this example, I think this might have to do.
Jeff Terrell: is probably actually.
Jeff Terrell: Go look at the source to figure out what this is, but I have something to do with the semantic web or something like that.
Jeff Terrell: But it goes, all the way from xml is the bottom layer, which is a way to represent data xml schema specifies all kinds of data you'd be representing rdf say anything about anything and then rdf schema ontology.
Jeff Terrell: that's like the study of meaning logic and proof and then trust.
Jeff Terrell: So it seems like a pretty interesting set of concepts there I don't really understand how those things relate this diagram.
Jeff Terrell: I guess will help you understand that the layering of this and we have layers and our Apps right like we we build on lower level technologies to build higher level technologies.
Jeff Terrell: There are various examples, probably that you can think of that i'm not going to go into it, but yeah so this could be something that you find useful for your project.
Jeff Terrell: i'm not going to require you to build a cake diagram or any of these other diagrams that we're talking about.
Jeff Terrell: i'm merely giving them to you as examples of something you might find useful, and you can evaluate for yourself whether there's enough value there and communicative ability compared to the cost of having something like this and having to maintain it.
Jeff Terrell: The only thing you have to create as an architecture diagram and i'll i'll show you examples of that a little bit.
Jeff Terrell: there's a swim lane diagram.
Jeff Terrell: Right swim lane diagrams emphasize the handoff of work between different components, or maybe different parties different different types of users in your process or something like that, so why not be able to see this very well, especially from the back there, but like.
Jeff Terrell: This is the pizza place and.
Jeff Terrell: Just people in the room, can see my hands or my mouse cursor but people over some cannot, I believe.
Jeff Terrell: Anyway, the top layer is the service layer which includes.
Jeff Terrell: Items forget ticket and deliver pizza customer, this is about building pizza second layer is prep which includes assemble tools and chopping veggies start to coat pizza with olive oil.
Jeff Terrell: Add pepperoni and cheese plate, the big pizza things like this, but there's different interactions so maybe there's a dough station, and you have to get the dough.
Jeff Terrell: Once you get to do that goes to storage and you need to get extra go, then you can come back after the prep layer and start to coat pizza with olive oil, maybe you need to get more olive oil from storage so Peter what olive oil.
Jeff Terrell: And tomato sauce this is from the stone alright, the fridge has pepperoni and cheese in it oven needs to be the thing that makes the pizza, and so this diagram concisely conveys how different stations of work are interacting with each other.
Jeff Terrell: similar kind of thing, maybe oriented a bit differently, is a service interaction diagram, so this is emphasizing interactions between components I struggled to find a good example of this online a lot of them were like.
Jeff Terrell: I don't know in domains that made no sense to me and I didn't want to try to explain, but I tried to print, something that was reasonably.
Jeff Terrell: understandable to to this audience.
Jeff Terrell: So here we have like these, these vertical bars are the different components of the system.
Jeff Terrell: We have three components here a student seminar and, of course.
Jeff Terrell: And the student says to the seminar enrolled students in the parameter here is a student.
Jeff Terrell: And so that comes over to the seminar, and you can see from this rectangle in the middle, how long the middle thing is thinking about this kind of the extent of that particular request.
Jeff Terrell: In order to answer that request the seminar has to ask the course is this through the eligible and passes a parameter of a student.
Jeff Terrell: Good, of course, to answer that it has to go back and talk to the students and get seminar history.
Jeff Terrell: So, then, the student returns, the seminar history and then, of course, to figure out what it needs to figure out and it returns eligibility status that seminar to answer the is student eligible or fast.
Jeff Terrell: And then, finally, the seminars able to return to the students say what the enrollment statuses.
Jeff Terrell: there's a lot of information right.
Jeff Terrell: Can you see how this breaks down the overall responsibility and two pieces starts to partition the responsibility space.
Jeff Terrell: You can clearly see what components are going to be involved, and you can even see the api's or the service interaction diagram even has an API.
Jeff Terrell: function names and parameters.
Jeff Terrell: there's a lot of good information here.
Jeff Terrell: Okay questions so far.
Jeff Terrell: Okay.
Jeff Terrell: let's talk about architecture diagrams.
Jeff Terrell: So it should be set a picture's worth 1000 words Ellis probably heard that before.
Jeff Terrell: And what i'm going to talk about now is basically what you'll need to know for assignments six everything that I talked about before you know evaluate the pros and cons of diagrams.
Jeff Terrell: It still applies to architecture diagrams, but in this case you don't have a choice about whether to create it it's just one of the assignments, that you have to create for the course.
Jeff Terrell: So the goal is to visually document, the composition of the system at a high level.
Jeff Terrell: What components are there, what are they responsible for.
Jeff Terrell: Which components talk to each other, your application diagram should have all of these things on it.
Jeff Terrell: The target audience for this is your mentor your future decks or any future deb's on this project me and even your classmates as you show this in class in your various presentations you might show this to your clients your client might care might not care.
Jeff Terrell: um it should include at least names hopefully also icons have chosen languages frameworks or any significant libraries.
Jeff Terrell: In having the icons I can in the names can actually convey a lot of information so somebody who's familiar with.
Jeff Terrell: django you know if you just had the django logo and the django on there somebody familiar with django would be able to understand a lot about your project just from knowing that you're actually using django.
Jeff Terrell: same thing with a lot of these other things like there's a good example of a architecture diagram that will see hat, it was using tensorflow.
Jeff Terrell: And this isn't the framework this isn't a service it's a library, I think I think I have that right and but it's a pretty significant library it matters that they're using that that has a big impact on their project, and so it makes sense to include that in the architecture diagram.
Jeff Terrell: Now, if it was a.
Jeff Terrell: Simple little library that just did one thing that wasn't really all that important yeah maybe don't include that we don't want to distract from the High Level picture fair detail to avoid distracted from high level picture so probably, this would not be the place to have API information.
Jeff Terrell: You might say little bit at a high level about what kinds of interactions these different components are having to specify API level details that's too much you don't want to distract from the High Level view.
Jeff Terrell: An extra rule of thumb for your application for for your architecture diagram is if the system becomes unavailable or degraded by something becoming unavailable like you know by some components that component should be in the dire.
Jeff Terrell: So, if you think about your application as a whole okay what things could fail.
Jeff Terrell: That would make my application become unavailable or somehow this the quality would become degraded so now.
Jeff Terrell: I guess the hosting service if that goes down I break.
Jeff Terrell: If the if the APP store goes down my mobile APP nobody can find my mobile APP.
Jeff Terrell: If Amazon web services goes down my back in crashes, you know these kinds of things.
Jeff Terrell: I mentioned that this is an art.
Jeff Terrell: This is not a science, this is something that you learn in this class that.
Jeff Terrell: Honestly, is kind of hard to learn without just getting experienced that and that's one of the main things you get from this core system experience is how to effectively communicate with different types of people in a software project.
Jeff Terrell: How do you communicate with teammates effectively, how do you communicate with clients effectively.
Jeff Terrell: And maybe even mentors so.
Jeff Terrell: The purpose of the architecture diagram is as a communication device and learning how to do that well really more of an art than a science, just like a clickable prototype and your ui kind of stuff you know yeah there are some principles, you can learn about doing it well.
Jeff Terrell: it's not like you it's not like there's no such thing as effectiveness, there is, but it's more of an art and your thing is you're dealing with humans.
Jeff Terrell: you're not dealing with logical systems you're dealing with emotional creatures.
Jeff Terrell: And we all have our own experience, our own history and our own things that makes sense to us our own visual you know things that we understand or don't so that's kind of why this is more of an art.
Jeff Terrell: Okay i'm gonna throw some tips that you got six tips here for creation of your architecture diagram.
Jeff Terrell: If I remember, I will post these on the assignment six right up as well.
Jeff Terrell: But i'm going to read these and then we're going to see five examples of architecture diagrams from last semester.
Jeff Terrell: You might even know potentially some of the people who created some of these diagrams I don't know but um.
Jeff Terrell: we're going to look at ways in which these diagrams.
Jeff Terrell: succeed, maybe ways that they're confusing or they don't succeed.
Jeff Terrell: But here are my tips.
Jeff Terrell: I recommend, including a user icon for potentially several if there are different roles or classes of users, so clearly indicate.
Jeff Terrell: How are people interacting with the software that i'm creating.
Jeff Terrell: Maybe there's a difference between admins and regular users, maybe so maybe you have a different user icon for each one of them, and maybe they interact with different pieces of the front end.
Jeff Terrell: But having a user icon clearly indicate how the users are interacting with your system.
Jeff Terrell: These are tips, by the way, these are not ironclad rules there might be good reasons not to do this, but these are things to consider, as you create your application type and maybe you'll have a good reason not to do it.
Jeff Terrell: Over to use arrows and label them either with birds or nouns to explain the interaction.
Jeff Terrell: So you might have.
Jeff Terrell: An arrow between your.
Jeff Terrell: Back end and in your database.
Jeff Terrell: And you could label it with a verb to say fetch data.
Jeff Terrell: or store data or you can label it with a noun to say.
Jeff Terrell: Data or user records or different things now, you might go into more or less detail about what kinds of data transfer there so nouns or verbs can each make sense.
Jeff Terrell: Number three, this is just a general design role put related things near each other, you might remember from when we talked about a little bit about design principles to talk about the crap principles consistency repetition alignment proximity come over this, this is the p proximity.
Jeff Terrell: which by the way, is useful in language to good at least, at least for English that's the only one, I can really speak to you for English good writing involves putting related words next to each other instead of far apart it's one of the Rules of style that you might learn.
Jeff Terrell: So, but related things near each other.
Jeff Terrell: Number four feel free to group related things together with the label, for it makes sense, so you might have like a bigger box that you draw around multiple components to saying you know this whole thing is the front end or this whole thing is the authentication piece or whatever.
Jeff Terrell: That can make sense in some cases, just to explicitly name a group of components.
Jeff Terrell: number five indicate when there is a single resource, or when there's multiple have some type of resource so.
Jeff Terrell: If you put pages or screens in your diagram maybe you will maybe you want, and probably going to have multiple of those and so you might have.
Jeff Terrell: You can imagine like icon per page, but then, just like a stack of them, you know that would be a clear visual way to indicate that there are multiple of these things.
Jeff Terrell: But probably you're only going to have one database and so probably doesn't make sense to have like a stack of databases, have a single icon there.
Jeff Terrell: And then finally number six indicate where code runs or where services live.
Jeff Terrell: So is this stuff running in the browser of a user device.
Jeff Terrell: Is it just running directly on the mobile device as an APP.
Jeff Terrell: Or maybe it's running in the cloud somewhere, for example, for your back end, you probably have that running in the cloud somewhere.
Jeff Terrell: And this also gives you a way number, the rule of thumb about you know if something can lead to degraded or unavailable service for your APP.
Jeff Terrell: You should indicate that in your architecture diagram, this is a way to do that right and have a have a cloud or something around all the backup opponents and say.
Jeff Terrell: You know, Microsoft azure or something like that indicate it backwards down the whole APP can be effective, this is part of the system.
Jeff Terrell: Questions about this.
Jeff Terrell: Okay.
Jeff Terrell: Right let's see an example.
Jeff Terrell: Take a minute and just look at this example, think about what you like or don't like and I have my own thoughts here to proceed to hidden those until you've had a chance to look.
Jeff Terrell: back even see the letters, the words here.
Jeff Terrell: yeah.
Jeff Terrell: No.
Jeff Terrell: mixed bag okay kind of small.
Jeff Terrell: So how how effective is this architecture diagram and conveying the architecture of the system at this team created last fall.
Jeff Terrell: On the right or wrong answer here, but just think about that, like do I feel like I understand this system by looking at this diagram.
Jeff Terrell: You know, maybe.
Jeff Terrell: Maybe i'm kind of familiar with how I know Java, I know have your back end and maybe even their javelin orange juice juice on how to say that.
Jeff Terrell: Maybe maybe i'm familiar with these technologies, and so, seeing that on the slide i'm like oh yeah Okay, I know I know how that works, obviously I don't know how to pronounce few servers.
Jeff Terrell: And then, would you be I know of that I don't really know a lot about it, but I still listen that there.
Jeff Terrell: Is all in aws.
Jeff Terrell: notice, we have some arrows that are actually labeled so request for data is a zero from the Java code back then to dynamo db Davis, and the arrow going the other way, so it's response with data.
Jeff Terrell: So it's kind of Nice.
Jeff Terrell: You have requests and responses between the front end and the back end and the back that was groups, you know, are these groups of cycling, and so they were soc service.
Jeff Terrell: And there's a couple of different pieces of top between the typescript code to the front end and react native framework.
Jeff Terrell: there's a mention of the framework between us here.
Jeff Terrell: So there's some things I like about this indicates, where the backend lives, a question yeah.
we're.
Jeff Terrell: Good question we don't know from the diagram what the APP is doing, I don't see that's Okay, I would say we rely on other things to learn what the purpose of the APP is, and this is really just about describing a system it's good question.
Jeff Terrell: yeah.
Jeff Terrell: yeah it does mention a framework so eventually react native framework, this is going to be a pretty significant.
Jeff Terrell: choice for how the front end code looks so I make sense that that would be mentioned here.
Jeff Terrell: it's not really clear what some of the arrows mean.
Jeff Terrell: I guess actually most of them are labeled but this one here in the bottom middle, how is the back end related to the javelin framework for the maven frame around think nathan's a framework anyway so maybe there's a little bit of confusion there.
Jeff Terrell: So just kind of visually boring right just kind of you know monochrome black and white.
Jeff Terrell: A lot of words it's not really very visually interesting, which is okay it's not like you have to be.
Jeff Terrell: super engaging in the way that your diagram looks you don't, but it can be nice.
Jeff Terrell: Remember we're trying to communicate with humans and humans like pretty things so if you have a choice between making it pretty and not that might might help.
Jeff Terrell: It consider this diagram example.
Jeff Terrell: Trying to think about it, look at the diagram before you read my commentary on it and see see what you like or don't like see if you get a good sense of how this what the system is.
Jeff Terrell: Right, this is probably really hard to read it says sweet Stat a practical DIY stats for educational electro chemistry, this is like a hardware device.
Jeff Terrell: You feel like you have a decent understanding of the system from looking at this.
Jeff Terrell: Can you think of anything that you would improve.
Jeff Terrell: So worthwhile exercise yeah.
Jeff Terrell: yeah what's actually going on the APP.
Jeff Terrell: All we really know is that it's sending experiment settings receiving a few data points and sending experiment data, but we don't really know much about what's happening here.
Jeff Terrell: yeah it's true and maybe that's Okay, maybe you know, this is a choice to make like how much detail, do you go into, and I did say you don't want to overwhelm.
Jeff Terrell: The consumer of this diagram with too much detail, lest you lose sight of the High Level picture so maybe that was a deliberate choice, but yeah I am kind of curious you know what's what's inside there.
Jeff Terrell: It turns out, in this particular case, actually had a page to their architecture diagram that they go into more detail on that, but.
yeah.
Jeff Terrell: yeah when you when you look at a diagram like this.
Jeff Terrell: This will help you prepare you for assignment six think about how would I improve this.
Jeff Terrell: Not only help you grapple with with what's here and how to actually create this on your own.
Jeff Terrell: So I like that we have labeled arrows here, which gives me a clear sense of what the interactions are, this is not API level details, but it is again just a high level view it's somewhat high level interaction looks like.
Jeff Terrell: Our logos that's cool so that's one reason why this actually looks more visually interesting draws me in a little bit more.
Jeff Terrell: I really liked the fact that they mentioned ble is a pretty important part of their project, because the suites that board only communicated via via bluetooth low energy.
Jeff Terrell: And a big part of their work that semester was figuring out how in the world they were going to connect their mobile APP to this board through bluetooth low energy learning how to use that Protocol and use that API on the mobile device.
Jeff Terrell: i'm pretty sure this is flutter anybody confirm that is that the flyer logo yeah okay great oh personal seen this.
Jeff Terrell: that'd be nice to see flutter here not just see the logo people who know the logo great, but like i'm I wasn't sure.
Jeff Terrell: I at least had an idea if you didn't have an idea you just be like what is your logo, there are no.
Jeff Terrell: And yeah as part of that over here, no there's no detail about kind of what's going on inside the front end of the APP.
Jeff Terrell: Are there any frameworks being used, I guess, I guess flutters a framework so maybe having a word, there would be helpful to get a sense of what was there.
Jeff Terrell: Are there any different components within the front end them as we were talking about I don't know.
Jeff Terrell: Okay third example again try to ignore this stuff on the left and focus on what's on the right.
Jeff Terrell: Let me walk through this because that's really small.
So.
Jeff Terrell: Is it says front end this big rectangle says running inside the front end it says html javascript react and react native.
Jeff Terrell: arrow going over here says image and this is tensorflow says ml model tensorflow the arrow coming out of that hexagon says interpretation goes back and directing the front end.
Jeff Terrell: This the front end going to the backend says anonymous image slash location data on the back end going back to the front end says confirmation.
Jeff Terrell: And the back into the database at the bottom says data to be stored in the database is on fire face.
Jeff Terrell: What do you like about this, what do we not like is this effective do we feel like we understand the system.
Jeff Terrell: Probably helped you could actually read that which probably a lot of you in the room cannot.
Jeff Terrell: certainly better than nothing right, I mean.
Jeff Terrell: You know there's a front end and back end, we know that we're using tensorflow there's some machine learning going on.
Jeff Terrell: Even kind of have a sense of what the inputs to the machine learning algorithm on.
Jeff Terrell: images.
Jeff Terrell: And interpretations, we know that the APP is hosted on firebase.
Jeff Terrell: good to know.
Jeff Terrell: probably still some questions, but I think this is all right, as far as an architecture diagram goes, I think there are things that we could improve but.
Jeff Terrell: it's definitely good start, I like that the arrow labels are really clear.
Jeff Terrell: get a pretty good sense of what's actually being sent between these components from the labels on the arrows.
Jeff Terrell: there's again no real detail about the front end details what's what's inside the front end so if I broke that component up and looked at it, what would it subcomponents be what would those interactions be.
Jeff Terrell: But again, maybe that's okay.
Jeff Terrell: same thing for back end.
Jeff Terrell: Is this a deliberate design choice not to include those details because it laziness.
Jeff Terrell: could be.
Jeff Terrell: Or maybe maybe it's deliberate maybe trying to go into detail, there were just distract from a high level view.
Jeff Terrell: that's about this one.
Jeff Terrell: Okay.
Jeff Terrell: Okay number four.
Jeff Terrell: So i'll just leave this one up here and at this point i'm just going to say you tell me what you think this is actually going to be an upload full on full everywhere.
Jeff Terrell: So let me.
Jeff Terrell: start, let me activate this and then i'll come back to the page, what do you think of this one very specific look at it, try to understand what's going on, you get a feel for what the system is looking at this diagram and.
Jeff Terrell: Put your specific thoughts in the in the poll, and if you see another thought that somebody else created feel free to upload our and instead of saying the same thing yourself because that's how this kind of works.
Jeff Terrell: I don't think that you'll get credit for interacting with this, because I don't think poll everywhere tells me if you just voted.
Jeff Terrell: So.
Anyway, yeah.
Jeff Terrell: yeah, what do you think.
Jeff Terrell: Oh sorry one note about this.
Jeff Terrell: In the visual language of flow diagrams.
Jeff Terrell: rectangles mean a processor procedure in parallel grams mean data, so if you notice that you have two different shapes here that's why.
Jeff Terrell: The recording will get this maybe two minutes for you all to kind of consider this and if your feedback.
Okay.
Jeff Terrell: it's a bit clutter yeah interesting yeah there's some.
Jeff Terrell: This is probably one of those examples where.
Jeff Terrell: there's maybe too much detail and you miss the High Level picture, maybe, maybe not.
Jeff Terrell: It looks like a lot of your thought it was kind of cluttered thorough but there's a lot going on too many words was too busy visually noisy, so a lot of similar kind of thought they're.
Jeff Terrell: busy over specified a few things too complex seems like a pretty common and shared widely shared a thing in.
Jeff Terrell: Parallel parallel grams and rectangles could be more visually distinct.
Jeff Terrell: readability on the arrows is tough.
Jeff Terrell: clearly separated each component and draws clear boundaries for each also has detailed descriptions for each component when I I got cut off, I guess.
Jeff Terrell: yeah text heavy logos are helpful yeah logos distract from clarity.
Jeff Terrell: different opinions, and you can see why this is an art right look at the diversity of opinions, we have here.
Jeff Terrell: One piece of art is going to be more effective, for some people, and less effective for other people.
Jeff Terrell: Some would say it's not even about effectiveness it's hard but either way.
Jeff Terrell: you're going to have different opinions on this spending under your talk to you, I actually really like this one.
Jeff Terrell: There is a lot of detail here, I think, part of it's hard for me to sort of separate myself from like I remember this project from last year.
Jeff Terrell: And so, when I saw excavating opening to town, I was like oh yeah that project, and I already knew a lot of and so maybe for that reason, when I saw this I wasn't over one by details because I kind of already knew the bigger picture, where these details fit in.
Jeff Terrell: But I actually liked this one yeah maybe a little bit cluttered busy but I thought the icons were really effective the logos to say.
Jeff Terrell: I mean, some of them, maybe not as helpful like html CSS is probably a given javascript is maybe a given, but the be maybe for bootstrap that might be good to know.
Jeff Terrell: I find ginja.
Jeff Terrell: Old site files.
Jeff Terrell: I like the words on the arrows.
Jeff Terrell: And one thing that I really liked about this is the separation, the grouping of the whole architecture into two separate chunks there's looks like a total of.
Jeff Terrell: 1234 different.
Jeff Terrell: processes or procedures and four different data sources.
Jeff Terrell: So maybe eight different components, depending on how you count it for this whole system but it's grouped into two main groups.
Jeff Terrell: In this diagram I thought did a really good job of separating them out.
Jeff Terrell: Most of the work was actually.
Jeff Terrell: In the generation of new site files and once that was generated it just got posted in that refined served up to users, and so this arrow here from the left to the right that says generates it kind of connects the Left Group to the right group was really the central output of.
Jeff Terrell: The whole project.
Jeff Terrell: yeah your mileage may vary, but I, like this one.
Jeff Terrell: Okay let's do this same crap thing with this one, what do you think of this architecture diagram example, this is another one from last year, let me open this poll.
Jeff Terrell: And we'll do two minutes.
Jeff Terrell: Okay, what did what did you think of this.
Jeff Terrell: Nice and simple not descriptive enough clear yeah again variety of opinions.
Jeff Terrell: It describes protocols and technologies but could do more to explain what is being sent or received or processed feedback.
Jeff Terrell: Maybe more description, but the flow is clear yeah we're bland okay simple visually boring.
Jeff Terrell: boring.
Jeff Terrell: Like that they make clear the different roles of users yeah definitely agree with that.
Jeff Terrell: You got an admin user and radio station user and then you also have a finance user I really liked how this actually.
Jeff Terrell: showed how this user was just getting emails, but that was kind of neat.
Jeff Terrell: So there is an email service and block here and API is telling the you know service what emails to send those different data collection service it's a Python script.
Jeff Terrell: To database, so that I like this tiger and I thought this did a good job, one thing that I wasn't sure about was where's this hosted.
Jeff Terrell: This on aws or azure or Google cloud or Carolina.
Jeff Terrell: Carolina cloud works or something like that.
Jeff Terrell: I don't know and I can't tell from here so that's one thing that I would say is missing, but otherwise I think it does a pretty good job telling you what the architecture for this system is.
Jeff Terrell: OK i'm going to spend the last 10 minutes or maybe not even quite that talking about the virtue of simplicity.
Jeff Terrell: Okay, so let me take a step back here for a second you have technology choices to make some of you do anyway, maybe some of you have already made them, maybe some of you.
Jeff Terrell: don't have the liberty to make choices about which technologies you're using in your project, but for those of you who have technology choices to make.
Jeff Terrell: How do you make those choices, what do you value we talked about how there's a lot of different things that you could value.
Jeff Terrell: And we talked about ease is something that makes a lot of sense you take the thing that you understand already or that you think is going to be easy to use and be productive with, and there are good reasons to choose that.
Jeff Terrell: Because you're more likely to be able to get something done this semester, if you stick with something that you already know.
Jeff Terrell: it's a known quantity you don't have to find a learning curve, etc, however, there are reasons why simplicity might actually be pretty important to consider, as well as you're making technology choices, and I want to talk a little bit about that.
Jeff Terrell: i'm stealing a lot of this from simple made easy, which is a talk by rich lucky he's one of the technologists that I.
Jeff Terrell: greatly respect and look up to and get a lot from his talks he created closure my favorite programming language.
Jeff Terrell: um so yeah and he said, I think it really kind of deep thinker and clear thinker so anyway, if you have time, this is a really neat talk.
Jeff Terrell: The word origin for simplicity comes from one folder or one brave.
Jeff Terrell: And the idea of simplicity is yet unity, having things be for a single purpose or a single single concept.
Jeff Terrell: i'm going to go a little bit faster the ideas it's not so much that you just have one instance of something but it's about you have just one concept in view here.
Jeff Terrell: This is about like the lack of interweaving of multiple concepts together Okay, so if it's simple it doesn't have multiple concepts in it just has a single concept.
Jeff Terrell: After this complex complex means your time multiple different concepts together in a single thing, so a system is complex.
Jeff Terrell: necessarily because it is composed of multiple.
Jeff Terrell: components.
Jeff Terrell: That would be complex so simple and complex or or offsets that simplicity interesting easy is relatively easy depends on what you know.
Jeff Terrell: Number easy we saw last time is.
Jeff Terrell: The word origin comes from at hand, like it's near to you, but that's relative to where you are right, simple, is an absolute thing is it a single concept or not.
Jeff Terrell: Now that actually answer that question you, you know that might be open to perspective and debate but it's more of an absolute perspective and an easiest.
Jeff Terrell: Their main reason why simplicity is superior to ease.
Jeff Terrell: Is understanding its ability to be understood.
Jeff Terrell: It turns out, people have done research on this, how many concepts, can you hold in your mind at one time, and this question has a lot of application to you as a program.
Jeff Terrell: When you're writing code and you're thinking about Okay, I need to follow this API, and this is my data model i'm dealing with these kinds of records here.
Jeff Terrell: And I need to use this this class, because any of us out API you're saying you're holding all these different things in mind at same time and trying to.
Jeff Terrell: combine all of them into the code that needs to be what you need to do and more concepts, you have to juggle in your head at one time the harder it's going to be to actually write your code.
Jeff Terrell: So if you're dealing with complex things.
Jeff Terrell: If you, you know you're using some other class that does something, but you kind of have to keep in mind Oh, but I can't use it this way and.
Jeff Terrell: Oh, I have to be careful about this that might occupy three of your seven slots right there just with that one other class that you're interacting with.
Jeff Terrell: much better to have some sort of a classroom module or function that only takes one of those slots, so that you can use it and you'd be more productive.
Jeff Terrell: So the key idea here is the complexity undermines your understanding of what you're doing.
Jeff Terrell: Human brains are finite and it's easy to work with simple things and complex.
Jeff Terrell: debugging is kind of an implication of this.
Jeff Terrell: Richard he asks what's true every bug well it's past the type checker it's past the tests and yet it's still a bug in your system.
Jeff Terrell: And so, when you get down to it, a lot of bugs you're just going to have to understand what you're doing.
Jeff Terrell: So you figure out what the bug is and figure out how to solve it really comes down to just how much do you understand and.
Jeff Terrell: Is there some sort of a gap in your understanding that you need to go fill so that you can understand the source of this box and fix it and again complexity interferes with understanding.
Jeff Terrell: and so on.
Jeff Terrell: For debugging purposes again it's better to have simple things that complex, even if they're using even if you're already taking the time to learn them and they're at hand might still make sense to gain things that are simple in nature, rather than complex in nature.
Jeff Terrell: give you some examples of things that are simple.
Jeff Terrell: don't have much time left, I saw simple right unity of purpose.
Jeff Terrell: unity of mechanism there's one thing happening it's it's you use this For one thing, and there's only one mechanism and this whole this whole tool.
Jeff Terrell: that's a simple tool.
Jeff Terrell: hammers most simple it's actually kind of a combination of two different tools right you got the hammering side and the cloth side to pull the nails out so it's a relatively simple but I mean, I guess, technically, it would be a complex tool because there's two different things happening.
Jeff Terrell: relatively simple.
Jeff Terrell: I don't even know what this is but it looks pretty complex.
Jeff Terrell: To NATO page holds water level indicators so sort of gardening thing that occurred tomato plants on a.
Jeff Terrell: Farm Bot is complex.
Jeff Terrell: it's a whole system for automating wiring that's complex computers probably got Apps.
Jeff Terrell: Like control this.
Jeff Terrell: Is computerized machine here.
Jeff Terrell: This is a simple tool but it's Compostable check this out unity of purpose you didn't get mechanism but it's Compostable there's this kind of it's kind of a poly morphic tool right.
Jeff Terrell: it's a single tool but there's like a there's an interface that it has at the end of this handle can plug different things into the interface it's kind of cool.
Jeff Terrell: it's kind of simple.
Jeff Terrell: kind of not, but this is probably a lot easier to wrap your head around then pharma say.
Jeff Terrell: unity of purpose and mechanism, and so you understand when and how to use them.
Jeff Terrell: A complex physical tools, sometimes you got to read the manual you might not know what's going on debugging requires understanding you're probably not going to compose a complex tool, if anything else.
Jeff Terrell: there's one.
Jeff Terrell: I have wrestled with the mower much like this, many, many times and over that I have a nice to have would just break all the time it was so frustrated in.
Jeff Terrell: My head to dig in and understand more about the system and I ever wanted to win it was great I had to go and figure out what's wrong and how to fix it.
Jeff Terrell: unity of purpose right it's promoting your art.
Jeff Terrell: So you know when you need to visit so that's good at least but knowing.
Jeff Terrell: What goes wrong, how to fix it doing debugging on it that's hard and actually it's not all together super easy to use, you have to kind of learn how to use it.
Jeff Terrell: When do you choke How long do you choke when you start the knower.
Jeff Terrell: I might depend a little bit I don't know not real confident I know the answer that.
Jeff Terrell: So yeah Ruby on rails is a classic case of easy, but I would argue, not simple, this is kind of becoming a pass a technology, these days, but years ago it was very, very popular and it was easy once you get your head around and find that learning curve, but it was not simple.
Jeff Terrell: Ruby on rails yeah.
Jeff Terrell: Often, is called rails quote from a cheeky emphasizing ease gives early speed, but ignoring complexity will slow you down over the long haul.
Jeff Terrell: And i'm at a time you'll.
Jeff Terrell: See you on Wednesday.