So I'm going to get started. This is a pretty dense talk, so I need every minute I can get. If you go to my website, it's just my name.com. It'll have the slide deck. And if you wanted to follow along, there you can. But this is a pretty dense slide deck, so I'm going to go pretty quickly. So following along on the web would be great. Here, let's get started. So first, I want to tell you a little bit about myself. My name's Mike Appiezi. I'm a software consultant. I work at QuickLeft. QuickLeft is a mobile and web application company. I live in Boulder. I've been here for about three years. I love it here. I'm very excited to be at Rocky Mountain Ruby with you guys, presenting to you. I'm also really nervous because I know a lot of you guys, so I hope I do well. I wish myself luck. So building a complex domain is a difficult thing to do. And this is the book, Domain-Dorm Design. This was written in 2003 by Eric Evans. And it's a pretty dense book. Eric is the guy that pioneered this concept. And because he did pioneer the concept, this is the de facto book on the subject. So if you haven't read it, I highly recommend it. So how many here know what domain-driven design is? Good. It's about 30%. How many here have tried to use domain-driven design in a Rails application? Great. So probably, I'd say, 20%. This is interesting. So we're going to be building a Rails application using domain-driven design principles. So first, let's get some basics out of the way. What's a domain? A domain can be a doctor's office where you have doctors and patients and record keeping in between. A domain can also be a new idea, such as Twitter, which is a microblogging service with tweets, followers, and follow-ins. A domain can be anything, like even be collecting really cute cat gifts. So the point is that a domain is a subject matter that you're building software around. So I'm glad. Let's get that out of the way. So why does DDD exist? Well, let's look at an example. Say we're building a Rails application, we have a few models, and we have a small team, two developers, and we're really productive. We're training out future after future, and we feel awesome. That's kind of what made Rails popular in the beginning. Kind of feel like this guy. So over time, your Rails models get bigger. You have maybe 5,200. Your team also gets bigger, maybe quadrupled, and you begin to slow down. There's more defects than they used to be. Training out features becomes more difficult, and a lot of us have felt this pain. As a consultant, I see a lot of client applications that have gone through this where it's a big monolithic Rails app, and it's hard to rationalize it, and it's hard to get anything done. So we end up feeling like this turtle. So the point of domain-driven design is to address the fact that software becomes complex quickly, and to create structure to address that. So what this talk is not about, there's a lot of topics on DDD, and I just wanna make sure I set up expectations with everybody. It's not about a custom architecture for domain-driven design. It's not about design patterns specific to domain-driven design, such as repository pattern, and it's not about advanced topics such as what a bounded context is. Custom is expensive. If you're a startup, there's a reason startups like Rails, because it's fast. So we don't necessarily wanna go custom right away. We may have not even proven our market. We might just throw away the app in the end. So you gotta be very conscious about when we do these custom things. They're all great, but there's a time and place for it. We are gonna talk about is taking domain-driven design principles and applying it to a Rails application, and we're gonna talk about how to structure your Rails application in a way that will allow you to transition to a custom architecture later down the line. We wanna move fast. We want Rails to be fast, and we wanna be productive, and we wanna hit the ground running. So what is this? Anybody? Yeah, Rails. What does this tell us about our domain? Nothing, perfect. So we're gonna try to fix this. We're gonna talk through seven topics. The first one being how do we go about defining the domain and what that process is like.  And then we're gonna talk about relationships, why they're important, and why they're not important. And we're gonna talk about aggregates, data access, value objects, and domain services. We're gonna talk about what all of those things are and how to implement them in a Rails app. So first, we need a domain. So let's pick a domain that we can build a Rails application around. I'm gonna pick the iOS app store. It's something that we're all familiar with. And let's pretend that Apple executives for name Scott came to me and he wants us to build this app store for him. So we're gonna sit in a comfort room together with a whiteboard, and we're gonna start brainstorming the ideas of what this app store is. So he's like, yeah, obviously we're gonna have apps. Developers can create apps. Any developer can, and they'll be able to submit several versions of an app. So as they make iterations, they create versions, and they can add one to six screenshots. And obviously there's customers that are gonna be purchasing this app, and customers are gonna install specific versions, and customers can leave comments on a version of an app. Okay, cool. So we kinda did this brain dump with Scott. We just let him get everything out of his head. We don't interrupt and we just draw it all out. And then we take a step back and then we start looking at this and refining it. So we're giving him a visual that we can work on. So I start asking about developers. I'm like, well, it's the only developers that can create apps. Well, what about companies like game companies? Could they create apps as well? Yes, yeah, companies can create apps as well, okay. So I put those two terms down there because the word developer wasn't enough to capture that concept. And I asked him, is there any difference between a developer and a company as far as how they create apps? He says, no, they're pretty much the same. They do the same thing. Can we think of a better word than developer or company that encapsulates both of those concepts? And I suggest, well, how about seller, right? They're both selling their apps. And he's like, yeah, seller will work. Cool, so we're gonna use seller. And then we look at version, and when he was talking about this, he was using the word version in release interchangeably. And I just threw down the first word that I heard. But I'm thinking about versions, and they have version numbers. And it's kind of awkward to say a version has a version number. It's kind of redundant. So maybe the release is the right word. So I talked to him with that and he's like, yeah, release is a better word. And I look at comments. I'm like, what else are you gonna leave on comments?  And he said, yeah, we're gonna leave ratings. Okay, well, comment's not gonna suffice. How about the word review? They can capture both the concept of comments and ratings. Cool, so we've refined our domain and we went through this exercise of thinking about the language we're using and making sure that it's accurate for the domain they were trying to build software for. So to talk a little bit about the finer points of communication, there that we just demonstrated, there's two sides. You have your domain expert who's supposed to know about how your domain works. And then you have the software expert who's supposed to know how to build software for a domain. And you go through this iteration of, you go through iterations of brainstorming, drawing, diagrams, speaking out assumptions. It's very important to use natural language, speak out, because he's gonna brain dump on you so you have to fill in the gaps with language and then let him correct you when you're wrong and then you keep refining language. The two responsibilities are your domain experts are looking for things that are awkward or not just right for the domain. And then your developer is looking for things that they're using two terms to describe the same concept because when you build software, you can't use two words to describe concept. So we're defining a bigotus language and Martin Fowler describes it the best, I think, a common rigorous language between developers and users and the need for it to be rigorous since software doesn't cope well with ambiguity. So from your user to your product owner to your domain expert, to your tester, to your developer, to your designer, to your developer, all the way to your code, you wanna ensure one consistent language across the board. If you don't do this, what happens is you're gonna create a fragmented language. All the people in your team are gonna start doing translations to each other because we're not using the same language. Things are gonna get confusing. More worrisome is that your code is gonna start having different fragments of language and if you can't understand your domain and communicate, how are you supposed to build it? So if there's nothing else that you get out of this presentation, this is the most important thing. Make sure you have one language across the board. So if you make a change in your user interface and you're presenting something to your user and you made a change to terminology, then you need to make sure that everybody else in the team uses that terminology and you also need to refactor your code to update that terminology. It's the only way to make sure that you have control of a complex domain is to make sure that it's communicated efficiently and everybody understands it properly. So refactoring your code is very important. So we're gonna talk about relationships. We're gonna go back to our diagram again and we're gonna look at the relationship between an app and a customer. We're looking at the purchase relationship and I'm gonna show you what it looks like in Rails. We have on top, we have the app, inherits from ActiveRecord and it has many customers to purchases. Below we have customers, it has many apps through purchases. So we're questioning which one of these are really valid and if one of them isn't. So I'm looking at the customer has apps through purchases and it makes sense that a customer needs to know what apps they purchase, right? So if they wanna redownload it later, they need to get a list of their apps and they can select something to download. So that relationship sounds legit. Now what about apps? Do they really need to know about all of the customers that purchased it? And you might for statistics or I'm sure you could come up with a reason but this is gonna be our MVP and we wanna keep it pretty limited. There's no reason for us to get a listing of all the customers that created an app or that purchased an app. So we're gonna nix that, cool. And also we're gonna look at install kind of in a similar fashion. Does our server and our domain model need to be able to link a release with the customer and know exactly which releases customers installed? I have that same tone so I thought it was me for a second. So one way we can get around keeping this information is that all the releases or all the apps will be installed on a customer's device. So we can easily send a list of all the apps with the versions to the server and then the server can then look at the apps to figure out which versions have new updates and then send us back the apps that have updates. So in our domain model, we actually don't need that relationship either. And what about customers and reviews? Do we want customers to be able to view a list of apps that they reviewed and to look at the reviews? And not an iOS developer, so I don't know this for sure but I don't think that iOS has a mechanism for you to look at the reviews. So we don't need that either. So what we did here is we really distilled our domain down to just the relationships we need. And the benefit of that is we decoupled things that didn't need to be coupled. And we've then, whatever relationships are left, those are the important ones that actually matter to the domain. So when we're looking at an application and we look at a relationship, we'll know that has a specific purpose. That's there because it needs to be not just because it can be. All right, let's get into aggregates. And finally, we're gonna get into some code. Taylor, we're this guy. We're gonna submit a new release of an app. And let's just walk through this real quick. There's a big chunk of code here. So we're gonna create a new release. It looks like we're passing in a version number. So we're creating a release object. And then we're creating several screenshots and we're adding those screenshots to the release. And then we're setting the status of the release to submitted. And then finally, we're adding the release to our app. So what's a better way of handling this? This simple answer, and I'm sure you guessed it, is put it into a method. So we're gonna put it into a method called submit release. And the method name is going to describe the domain behavior that we're trying to represent. Also that the method is on the app. The app is in control of the release and the screenshots and all that because it makes sense, right? An app has releases and all those things. So it should be in control of managing the complexities of that. It's also simpler. Notice that we have a string. That's a version number. We don't have to worry about creating the release object and passing in the version numbers. We can just use a very short way of representing that. So it makes this very easy to look at at a glance if you're looking through code. And it also makes it easy to use. There's only one place that you can submit a release from is through this method. So that complexity will always be managed within that method. And now we're starting to see what an aggregate looks like. So in our example app is our aggregate and underneath it is responsible for managing things like the release, the screenshot and the review. And everything that you wanna do with screenshots, releases, reviews has to go through the app. So you wanna have a method on the app that manipulates those. You never manipulate them manually. And the reason you do this is you're decoupling the small subset of models from the rest of the system. And if you do this over and over again, you have all these small aggregates that then control their own complexities and then you're kind of breaking up your system into smaller components. So if we look at our app, we start seeing that we're building out all these different domain behaviors. We have submit release, approve release, flag for abuse, mark as staff favorite. And it's also explaining to us how our domain works, what's important to our domain. I can now look at this and get an idea of, oh, this is what's important to the domain and here's all the things I can do. It's awesome. All right, let's talk about the other side of aggregates, data access. We'll look at another example here. So I have an app and I'm looking for apps, so I have a Wear Clause, it's just a standard Active Record Wear Clause. I'm looking for apps that are less than a week old and have been purchased more than 10,000 times. So great, that's what it does, but why? It's very frustrating when I see code like this, like, yeah, I know what you're doing, but why are you doing it?  So what's a better way of doing this? It's really simple, Rails gives it to you, you should use it. It's called Scopes. The scope gives a name to the query that you have. Now we know that the meaning of this query is new and noteworthy. We want to know what the new and noteworthy apps are in the App Store. Another cool thing is Figleaf, Avdegrim created it and basically what it can let you do is privatize all those Active Record Methods, like the Wear Clause, so that you can't actually use it outside of the app.  Now obviously developers will find a way to get around it if you want to, so this is not enforcing anything. It's a reminder, right? This is really, you can do whatever you want with great power comes great responsibility. So if we look at our app again, we have all the different ways we can access data. So why is the app important to us and how are they important to us and what are the different ways that are important? And we also have our behaviors down there to tell us the things that we can do with it. So we're creating one expressive point of entry for our aggregate and something else to note, aggregates are the domains only point of entry for data access. So if you want to get to release information or screenshots or whatever that is, you're always going to go through your app. So you only need data access on your aggregate. And that's pretty cool and I'll show you why. So if we structure our sub folders and our models folder like this, so you can't actually have a folder and a model with the same name because modules and classes are the same constant and all that business. So I'm using the plural for apps and then in there we have our app and then those are all the other objects that the app is in control of. And if we look at this, now we know where all our aggregates are. That's pretty cool. The first layer of our models directory shows us where all our aggregates are. Now we can look at the behaviors. We know what to look at to figure out where we retrieve data. And now we know what to look at when we want to make changes or add a feature. Cool, so the last piece we're going to talk about are value objects. And this is actually the most difficult part to talk about and the most lengthy. So I'm going to try to roll through it pretty quick. So there's two types of domain objects. There are entities and value objects. An entity is a thing. So this is the simplest way to describe it. An entity is a thing and a value object describes a thing. Let's look at an example. Say we have our entity as a customer object and our value object is a name object. So if I'm a customer, my name's Mike Aviesi. Okay, so if you, if my cousin is also a customer and his name is Mike Aviesi, we're still two unique different things, right? We have our own life cycles. We create counts at different times. We can deactivate our account. Just because our attributes are the same doesn't mean we are the same. And those are the, that's what makes an entity. It's unique, independent. It's an attribute that has a life cycle. It can change state. It's a complex thing that we're trying to represent. Now value object on the other hand, it just describes a thing. So if I am a customer object and I have a value object that's name and it has Mike Aviesi and I plop it on me. And if I take that and throw it away, create a new name value object with the name Mike Aviesi and plop it on me, doesn't make a difference. No, it doesn't make a difference. And that's what makes value objects unique. So because it doesn't make a difference, we can just throw them away and recreate them. And because we could do that, we can make them a mutable. Mutable is a really cool thing. And that just means that you can't change it after creation. So the reason a mutable is cool is because let's think about an entity, right? It can change state. You can create an entity or you can create an entity through a constructor and it sets up an initial state, has behaviors, those behaviors can change the state. But a value object, it only has one method. It's constructor and that constructor creates the state and then it's done. So they're very simple in terms of how they're built. They're very easy to think about. The other thing too is you're sending a value object through series of functions. Nothing can accidentally change its value. Where an entity, if it's a object that can change, those functions could change the value and then you get these weird side effects and value objects essentially can make your code safer. Also value objects don't reference anything, right? It's just an attribute that you use to describe something else. And the whole point of me bringing this up is because value objects avoid the design complexities of entities and that's a really good thing. If we have a hundred models and we can identify say 40% or 30% of them that should be value objects, well then we've identified things that will have simpler creation. They won't have side effects so they're less error prone and they won't be related to anything else because they shouldn't be. So we're reducing the complexity of our domain. We don't wanna unnecessarily add complexity to our domain. So what's what in our example of an app, aggregate? So all aggregates are entities, that's an easy one. There's this complex thing that builds things and it can change state. A release also has like a life cycle, you can create it and then when there's a new release there's no longer valid screenshots. Now to answer this one, we have to think about screenshots. Do they have a life cycle? I mean through the release I guess they do. Are they important on their own for any reason? Not really, it's just another way to add a description to a release. So those are actually value objects. And then if we look at review, let me do a little time check here. Okay I have about five minutes left so we're gonna have to go through this. So if this is a review on Amazon you can look at a list of reviews, you can edit them, people can comment on them. That would be an entity in Amazon. But in our app store we don't want any of that, it's just MVP, we want people to just create a review and if they wanna update the review then they just create a new one and behind the scenes we delete the old one. So we get to treat it as a value object. All right so what does the value object look like? It's just a plain Ruby object. It doesn't inherit from anything especially active record. And it has a constructor taking the attributes, it exposes the attributes as read only methods and it overrides equal equal and to make Ruby happy for fast comparisons in certain situations. I'll let you look this up. We need to alias eql and then we also need to define hash. So that's what a value object looks like. Another good thing for value objects are factory methods. So if you think about a string it has the method up case. What it does is it takes the original object and it transforms it into a capitalized version. So this is a very natural thing for value objects and those are natural behaviors. So we're gonna have one here that's next major version. It news up a new value object and then increments the major version. Cool so the tricky part that is hard to get a focus on or hard to understand to do is how do you persist value objects? So we're gonna talk about three ways. One is inline on the entities table. Two serialize on the entities table and three is in its own table and we'll go through each one of those. So inline on the entities table. We have a release and we're looking at the version number value object and we have a release table that has three attributes for major, minor, and build and that's where we wanna store those values but we want our domain model and our models to be separate objects. So how do we do that? So it's really simple. You create a writer method called version number. It takes in a version number value object and then all it does is take the attributes from your value object and assign them to your release attributes. And on the way out, reading out the version number, you're going to new up a new version number value object and pass in the attributes for the release. So that's how you expose value objects through a release. Another thing you can do is hide the attributes on the release, the version major, version minor, and version build because we wanna access versions through our version number methods, so we wanna hide those. Our second example, we have screenshots, it's an array and we want to be able to save those to one column called screenshots on the release table and we're gonna do the same thing except we're gonna use a JSON serializer and we're going to serialize the data into our release attribute and then deserialize it out of our release attribute. This is a very basic example. If you're using an array and you wanna be able to pop things on, you're gonna have to get a little bit fancier but this works, right? This is the basics of what you need. And third, if you wanna store a value object on a zone table, we'll look at review as an example and wot, wot, wot, we have to inherit from ActiveRecord. Kind of sucks but we're gonna try to do the best we can. So there's this really cool method on ActiveRecord though called read only bang. And what it does is when you call that method, it kind of locks your model so that if you try to change attributes and save it, it won't let you, it will raise a read only error. But it's kind of awkward because it still lets you set the attribute so you can still set the attributes and then you try to save it and then you get the error. So we're just gonna do a little thing here. We're gonna create, we're gonna override all the writer attributes and actually ActiveRecord is using method missing but just for simplicity. So we're gonna create all the writer attributes and then we're gonna raise error if anybody tries to use it as a reminder, hey, this is read only, don't use this. And we're gonna wrap that into a method called immutable. And then after we save the record, we're going to make it immutable. So that way you can change it during creation but once it's saved, you're done. It doesn't change anymore. And also in find, when we retrieve it from the database, it's also gonna be immutable so you can't change it. So it forces you to throw it away and create a new one when you actually need to make a change to the value object. And we're gonna implement equal equals again the same reasons. So last, let's talk about domain services. So we talked about aggregates. Aggregates have their own little world of complexity that they're controlling. What if you need to process a transaction between two aggregates? Well, what do you do? One aggregate isn't allowed to reach out of itself and affect anything else, right? So we need a third party to handle that for us and that's where domain services come into play. So let's look at an example. Say we wanna gift an app. We needed to do two things. We need to charge the gifter that's purchasing the app and then we need to assign access rights of the app to the giftee, right? So our customer object is an aggregate and even though we're just affecting two customer objects they're still independent aggregate instances. So they're still not allowed to reach over into each other. So we're gonna use the domain service to handle the strength action. So simply again, the domain service facilitates a transaction between two aggregates. So our model, something like this, we have a customer and it has purchases. We need to expand that a little more to separate the concept of purchasing and actually being able to use an app. So we're gonna introduce another model called accessRate and we're gonna take a look at in code what a domain service looks like. And it's gonna be a simple Ruby object. Its name describes the behavior that the domain is trying to fulfill. It doesn't inherit from anything and then it's gonna have an execute method. So it's just one operation. We're gonna take in all the things that we need to make this happen, this transaction happen. So we'll take the app, the giftee and the giftee, the giftee and the giftee are our customers and we create a purchase record for a giftee and we create an accessRate for a giftee and likely you'll wanna use database transactions and whatnot but you get the idea of how to structure these. So let's look at our Rails directory again. We can create a services folder that has all these domain services and now we get to see all of the cross-aggregate transactions. All of these cross-aggregate transactions. So in summary, we talked about how to continuously refine the domain with the domain expert. We talked about how to insist on having you pick up this language for seamless communication across your team. We talked about constraining relationships to only the ones that you need. We talked about creating aggregates to manage complexity and express domain behaviors and we talked about expressing the domain's intent through well-defined data access and we talked about creating value objects to eliminate unnecessary complexity and we talked about creating domain servers to express transactions between aggregates. So if we look at our Rails directory again, we started out with this. It just tells us it's Rails. And now we have this that actually tells us how our domain works. So over here, we have our aggregates. We know all the entry points of our application. We know where to retrieve data and we know where to enact domain behaviors. And we also know all the services and what domain behaviors are cross-aggregate transactions. So now we actually have a Rails application that expresses our domain. Thanks for listening. Again, thank you for a quick left for sponsoring me. We're hiring, so if anybody's interested in working at Quick Left, it's a really fun culture, come talk to me. And a special thanks to Paul Reiner, a virtual genius. He's been kind of a DDD mentor for me. I'm on the internet and I am also trying to find a few people to mentor. So if anybody's interested in mentorship, it doesn't matter what you want to learn. You could be an ultimate beginner or you could be advanced. If you're advanced, then maybe you'll be my mentor. And so go on my website and go to the mentor section if you're interested in that. So now, questions. Yeah, so the question was can I expand on how value objects keep us out of trouble? So it's really simple. You're boiling down an object to something that's extremely simple. So it's hard to mess it up, right? If it can change, then you can change a state. Then you gotta manage a state that changes. And you might have domain rules around, okay, if you have this, then you have to have that. So a value object allows you to put all those in one method and then you're done. It's just that one method that controls it. And the other thing is when you pass that value object through functions, it can't act, those functions can't accidentally change it. So you won't get these weird side effects. Whereas if you have an object that you can change, it went through 10 functions. And then when it came out at the end, it's different. And you're like, oh, God, why is this different? What happened? Oh, where did it happen? So, and it also doesn't have relationships. So you're not coupling it to anything. It's a good question. Oh, yeah, the question was how do you translate this for a API? And you mentioned that. It feels like it's more of a MVC type of thing. So I think it works perfectly fine as API. And I've used it several times that way. You're really just, as an API, you're really just getting to the nuts and bolts of how your domain works. And then you make changes in your domain and you do things and you just create your domain to represent that. In fact, I think it's actually easier. No? Okay, great. Thank you guys.


Now, we are just reducing the tire pressure, we're just going off-road into a very sandy area. Putting down the tire pressure what we had on the tarmac surface, hopefully we will make it through the sand.


Welcome to our lecture series Math 4230, Abstract Algebra 2 for students at Southern Utah Universities. This is the first lecture in our series, and if we haven't met before, my name is Dr. Andrew Misildine. Like I said, this is Abstract Algebra 2. If you're not quite familiar with many notions like groups and rings from Abstract Algebra 1, I would recommend you go towards the previous lectures in the series Math 4220. In our first semester of Abstract Algebra, for which this is the first lecture of really semester two in Abstract Algebra. In the first semester, our series focused primarily almost entirely on groups. We did talk a little bit about rings, mind you. But honestly, our discussion of rings was really to just lead to the idea of a group ring. So why are groups so important that we focused almost an entire semester on it? Well, I mean, honestly, if it was just to me, I would say because they're cool. They're awesome. What else do we have to say? But the viewer might need a little bit more convincing than just they're dope or something like that. So really, the importance of group theory comes from the fact that groups are ubiquitous in mathematics and in science even. I mean, they're everywhere, which of course, this is a result of how they interact. That is, this is how groups interact with other objects. That is to say groups are important because they act on other sets. So our very first unit in this lecture series, particularly lecture one here, is going to talk about the idea of a group acting on a set or so-called group action. So this first video is going to introduce us to some important vocabulary we should be aware of with discussion of group actions. So we're going to have a group G in consideration here, but we're also going to have a set X. For which this set X, we don't suppose necessarily any algebraic structure on it. It's just a set. I mean, there could be more to X than that, but for the moment B, X is just a set and G is just a group. We define a so-called left group action, or when it's clear from context, we'll just call this a group action. But as there is a possibility of a right group action, which we'll define in just a moment, a left group action from the group G on to X is in fact a map. It's a function of the form G cross X towards X. So the domain is the Cartesian product of the group G and the set X. And then the co-domain is just the set X right here. Now, we will often denote the image of the ordered pair G comma X using a symbol like the following G dot X. And there's a lot of different notions that people use when it comes to describing a left action. There's no universal symbol that everyone uses. In our lecture series, we'll primarily just use the symbol G dot X to denote the image of G comma X for a group action. But some people will use like a little circle, like kind of like function composition. Some people use like a little triangle G triangle X for which the triangle points towards the element being acted upon and it points from the group element which is acting entirely. Another common one is you use a superscript on the left. So superscript G X. This isn't a very common one, I think mostly just because it's extremely tedious to typeset that symbol in latex. It's possible, but it's really annoying. And honestly, probably the most common notation people use for a left group action is just the juxtapositioning of G and X. So they're next to each other with no further symbol whatsoever. And in my professional literature, that's how I would write it as well. In this very first lecture, I'm going to stick with the little dot here because the group action itself kind of acts like multiplication, but we don't want to confuse this with the group multiplication. So until we have a little bit more maturity, a little bit more experience on group actions, I do want a solid symbol to help distinguish between what is multiplication of the group and what's the action of the group on the set. This can get particularly confusing when the set we're acting on is the group itself. So again, we're going to use that symbol to help us out here. So getting back to the definition, besides that aside there, a left group action is a map from G cross X into X denoted as G dot X. And it satisfies two axioms, kind of like when we defined a group. It's not just good enough to have a binary operation. There have to be axioms associated to that binary operation. Now the first one, we're going to call it the identity axiom. You'll recall that a group, by definition, has an identity element. The identity axiom for group action tells us how does the identity element of the group interact with this action? So if you take any element X inside of the set X, then the identity of the group, we'll typically call that E, the identity acts on the element X by doing nothing. The identity element does not change the elements you're given. And that kind of makes sense. I mean, when it comes to group multiplication, the identity doesn't do anything. So with regard to group actions, the identity also has that property there that the identity acts like the identity function. And then the next axiom, there's a lot of different names that you could give to it. We'll call it compatibility. Some people call it homogeneity. Some people call it associativity, which that can get a little bit dangerous, but it does kind of act like an associativity axiom. But let's call it compatibility because we have the, for the group, its multiplication is already in play here. But now we're introducing this new function that kind of looks like a binary operation, doesn't it? You take two things for the input and that gives you a single output that kind of feels like a binary operation. In fact, the symbol we're using to denote the group action resembles multiplication. But of course, with our group multiplication for G here, we'll use juxtaposition there. So there won't be any confusion about whether we're multiplying the group or we're acting with the elements there. So again, one should be very cautious, but a group action itself is not a binary operation because the two sets in the domain are not necessarily the same thing. We could have it be the case that G and X are in fact the same set, but in general, that's not going to be the case. And so it's not a binary operation in the normal sense that we don't just take two elements of a set and produce a third element of the set. So one needs to be careful when we talk about combining these things that we actually get something that makes sense. So first of all, it makes sense to talk about the element G dot H dot X because if you look at just H dot X right here, the group action says that if you take an element of the group and an element of the set and you combine them together, they give you an element of the set. So H dot X belongs to capital X there. Therefore, H dot X as an element of capital X is something that G could act upon. It could act upon this element right here. So what we see on the left-hand side is that we have that H acts on X and then G acts on whatever H did to X there. So G acts on the element H dot X. This makes sense in terms of the composition of functions with respect to this action. In contrast, we should be very cautious with things like the following G dot X dot Y where here G is an element of G and X and Y are elements of the set X. We have no meaning what X dot Y is. This would be complete nonsense. So we want to be cautious about things like that. We can't just have arbitrary combinations because the G's and the X's are different potentially. But what compatibility does for us is that those left-hand side makes sense. You act by H then you act by G. Compatibility says that this is the same thing as acting by the product G times H. The product of G and H acting on X is the same thing as H acting on X and then G acting on that. And so the two axioms together give us a so-called group action. Now, when it came to defining a group, we actually took on three axioms. One was very similar to this identity axiom, which we call the identity axiom. The associativity axiom is very similar to the compatibility we have on the screen right here because compatibility has to do with, if you have three things, you have a G, an H and an X, how do you do with it? What do you do with these things? Well, in some regard, you can associate this way and in some regard, you can associate this way. So again, compatibility looks like an associativity axiom, although associativity really only makes sense for groups, right? A binary operation, I should say. Clearly, there's non-group binary operations that are associated. That's the definition of a semi-group. But we don't have an axiom for group actions. We don't take on an axiom about inversion. What do inverses do with a group action? We'll actually be able to prove that later on. We don't assume an axiom because we can actually prove things about them later on, but I get ahead of myself. So just again, in summary, we have this group. We say that it acts on X here and X is then, if it's equipped with a group action, it's often called a G set. So X is the G set because the group G acts upon X. And so I want to take a quick moment and talk in general about the idea of a left action. This is not going to be an official definition. We need to worry too much about going forward here, but in general, a left action in an algebra is a map of the form A cross B and it maps to B. So same thing like we saw before, where loosely speaking, I'm going to say that A and B are so-called algebras. That is, they're sets with some type of algebraic structure to it. There's some operations there. We can call multiplication, subtraction, addition. It doesn't really matter, but there's some operations in play which have some properties. Those could be associativity, commutativity, distributive laws, what have you. We're not going to necessarily nail them all down. But these two algebras don't necessarily have to be the same category. Like in this situation of a group action, G is a group. It has an associative binary operation with identity inverses. That's a category of algebras, groups, right? A set is essentially an empty algebra. That is, there's no algebra structure attached to it, but you could think of it as an algebra in sort of like a null sense, all right? But in linear algebra, for example, we often deal with the idea of scalar multiplication. With scalar multiplication, you have your vector space v. You act on it by a field. Oftentimes, this is the field of real numbers or complex numbers, but if you have a vector space, you could take any field whatsoever. And this produces a vector. So if you take a scalar times a vector, this produces a vector. This is an example of a left action. Of course, in vector spaces, things are commutative. So left versus right, that distinction doesn't really matter. Again, I'll get into that in just one moment. But in linear algebra, this idea of scalar multiplication, it's not a binary operation. We don't take two vectors multiplied together to get a vector. We take something different, a scalar and a vector, for which without scalar multiplication, a vector space is really just an abelian group. And when it comes to what do we multiply by? Well, you take a field, which is a very, very well-developed ring, lots of stuff going on there. We can also talk about the idea of an R module, which is kind of like a vector space, but we no longer require the scalars be a field. It could be an arbitrary ring. These are all things we'll talk about later on in this lecture series, future lectures. Stay tuned for those. And so there's a lot of rich theory in this idea of actions. Algebraic sets act upon other algebraic sets, including just plain old sets that have an empty algebraic structure, like a set. Of course, in this chapter, we're going to focus on the idea of just group actions. But we'll often just call it an action for short, because there's no other confusion. But this idea of an algebraic set acting on something else is very widespread in abstract algebra. Group actions, of course, is a good introduction to that. All right, now finally, I keep on talking about right group actions, right group actions. Will it be a right group action by analog? You would take some type of map X cross G, and this produces X like so. And in which case, you have the similar axioms, excuse me, for the action. So we require that X dot E is equal to X. So the identity basically doesn't do anything. We have to be a little bit more careful on the compatibility axiom, because in that situation, we're looking at X dot H, like so, dot G, like so. What do we want that to be? Acting by H, then by G. Well, we want that to be the same thing as acting by HG, like so. In which case, that's what we look like. You just got to flip everything around. It's basically the same type of stuff. Similar notations. We can use a dot notation for a right action. We could use a circle notation for a right action. Like I mentioned earlier, there's this little triangle that people sometimes use. The triangle always points towards the set and points away from the group element. It's not pointed the other direction.  So sometimes you use the direction to emphasize that we go into the left or the right. We aren't really going to worry about that in this lecture series. A juxtaposition is another popular notation, but actually in the literature, I think the most common notation is to use a superscript, which is very easy to put into LaTeX. X to the G there. For our purposes, we're just going to focus on left actions. If there's really no advantage to it, it's just sort of like in the road of life. If we have run across a fork, do we take the left road or we take the right road? We're just choosing to take the left all the time. This is a convention that showed up in our previous lecture series about left cosets versus right cosets. It really doesn't make much of a difference in the most part. Just be consistent left versus right. But like I said, with that by action, sometimes there are situations we have the left and right interacting. And so in that situation, it's important that we do have as an option, but for us, we're going to stick with left actions. Check out the next video or two to see some properties and examples of group actions.


Humming ominously as it courses through the bloodied blades of grass, the whispering wind flows across the field where the bodies lay. With a wet face, the Centurion gazes across the field where thousands of his comrades had been. Where men stood, nervous with anticipation, their hands trembling as they were wracked with fear, they are now pitched over, dead, rotting, bloated and cold.  To win a battle. Hi there viewer! If you enjoy my content, please consider liking the video and subscribing to help the channel grow. Enjoy! So, Tilo was in Naples. His siege victorious, he was finally in the city. He was seen as a conqueror, but also a magnanimous hero to the people of Naples as the victory he achieved came without the spilling of blood. Instead, Tilo was able to secure the Byzantine surrender by offering clemency, keeping true to his word, not a man of the Neapolitan garrison was harmed. Now, Tilo was eagerly awaiting the arrival of a messenger. After taking the city, he had sent an envoy to Justinian, directed to offer peace terms. The stipulations were that Tilo would keep Italy with autonomy, but in a subordinate and supportive role to Justinian. It was a generous offer that Tilo hoped would bring some relief to the Italian people. He sat still for a moment, contemplating the offer. Had it been generous enough? Justinian's ambitions might preclude him from accepting any offer aside from full annexation. It may not be enough. Suddenly, his thoughts were interrupted as a commotion broke out in a group of nearby soldiers. Tilo rushed over to see what was going on. It was the envoy. They had arrived with a letter bearing the seal of Justinian. This was it. Tilo eagerly opened the letter with anticipation. His heart pounding away. As the moments passed, the Gothic troops watched as their king's energy died down, his disposition going from eager and excited to firm and composed. Tilo's peace offering was swiftly and utterly rejected. There would be no peace. Disappointed but not entirely shocked, Tilo knew he would have to decisively win this war. And so, he and his army set out on the next phase of their campaign. Their target, the Eternal City herself, Rome. In Constantinople, Justinian knew the situation was bad. His generals had been disorganized and thoroughly incapable of making any progress in defeating Tatila. Now, with his loyal force, Tatila was on the march to Rome. What was the point of it all if they couldn't even keep control of Rome? Finally, in the wake of his commander's ineptitude, Justinian relented. He knew what he had to do. Even though he did not trust him, Justinian knew his current commanders in charge of the Italian campaign were not going to get the job done. So, he called on Bellisarius to return to his previous position and finish what he had begun almost ten years ago. He returned the property Theodora had taken and the general was given some ships and some men and sent back to Italy with his new orders. Defeat, Tatila. After the next year, the famed general arrived in Ravenna to assess the situation. Unlike his last campaign in Italy, this time he only had a few thousand troops under his command. A shockingly insufficient force. Even with his newfound position, it seems Justinian still held some resent after all. And while Justinian most certainly did still hold some suspicions, the reality is that Justinian likely couldn't have given Bellisarius a large army even if he wanted to. The plague had completely destroyed the manpower pool of the Byzantine Empire and they needed troops all over. At this point, they would continue to be at war with Persia for another few months and they still needed most of their forces in the east. Even after the troops was signed, the Byzantine-Persian relations would continue to be antagonistic and they would need to keep troops in the area to ensure Castro couldn't freely march across Syria as he had before. The troops Justinian had scraped together for Bellisarius were already from the bottom of the barrel. For now, the hopes were for the military genius of Bellisarius to compensate for the lack of men. Unfortunately, this would not be the case. Even for Bellisarius, there's only so much you can do with such few men. What ensued was a frustrating multi-year stalemate with neither side being strong enough to take on the other. The Tyla would take a town only for Bellisarius to take it back a short time later. Troops would skirmish, but the armies would never meet for a pitched battle. Each side would send raiders to harass the other, attacking supply lines and burning the countryside to prevent the other army from foraging. As time went on, the war became uglier and uglier as both armies resorted to plundering. Civilian casualties were mounting, yet no progress was being made. The city of Rome in particular changed hands three times, much of it being destroyed and as population more diminished than ever due to the constant conflict. After almost five years of this futile struggle, Bellisarius knew he had to get more troops and he started thinking of ways to do just that. He didn't think he could convince Justinian because of the trust issues between the two men, but he thought of Theodora. Even though they had a strained relationship, Bellisarius' wife was very close with Theodora. Perhaps the Empress could convince Justinian to see reason. Yes, Theodora, that was the way to go. Bellisarius would leverage his wife's relationship with Theodora to get the troops he needed. However, a short time later, Bellisarius received a letter that was most unwelcome and most certainly unexpected. Theodora would not be helping him secure more troops. The reason for this, you see, is because Theodora was dead. She had most likely died of cancer a short time before Bellisarius' wife had arrived. After rising from the lowest depths of the social ladder, the Empress had spent 21 years on the throne. She had been highly influential and involved in politics, playing a key role in the administration. She had been a fierce advocate for women, had kept the Emperor from fleeing during the Nica riots, and in spite of the discord between her and Bellisarius, had kept things running while Justinian was sick. While she had died, her legacy lives on, and people today can still see her menacing countenance peering down at them from the Basilica of San Vitale in Ravenna. Justinian was completely and utterly heartbroken. While Theodora had serious differences in opinion to Justinian, and while she had at some point taken actions that harmed the Empire, Justinian and Theodora had genuinely loved and adored each other. After her death, Justinian could never bring himself to marry again, even though he would live for another 20 years. Instead of receiving reinforcements, and in the wake of his failures in Italy, Justinian, at the prompting of Bellisarius' wife, made the decision to recall the general. Setting aside his distrust, the grieving Justinian greeted the general with open arms, the two of them catching up and reconciling their relationship before the fame general announced his retirement from military life. For the rest of his life, Bellisarius would play a small role in politics, before briefly coming out of retirement 10 years later to fight one last battle against the Hunnic army that had crossed the Danube. In this battle, Bellisarius proved again for the last time his ability to win battles while being significantly outnumbered. While Justinian was distraught at the death of Theodora, not everything was bad news. The plague had died down in much of the empire that had been afflicted over the past several years. At last, there was some light at the end of the tunnel. There was room to recover, and recovery is exactly what happened. Justinian's emergency tax increases and budget cuts had been responsible for keeping the empire solvent. While some of these measures had been harsh, they were effective, and the empire was in much better shape financially. While it's difficult to imagine life ever being normal, after all that's happened, with the plague dying down, some degree of normalcy returned, and the empire got back to work. However, as they did so, it became apparent that yet another problem had presented itself. Across the countryside, the mass death had created considerable labor shortages. There were huge swaths of arable land simply waiting to be cultivated, but not enough people to actually tend to the fields. The rich landowners who controlled this land were dependent on its agricultural production in order to maintain and expand their fortunes, and as a result, an intense battle for labor began between them, with landowners trying to outmaneuver and outbid each other for farm labor. The wages for poor farm hands quickly got out of control as the poor were able to demand much more than they could prior to the plague. As wages increased, prices did too to compensate. Suddenly, there was a new economic issue on the empire's hands, wage and price inflation. Justinian attempted to stop this by enacting a wage limit, but, like others who tried to do such wage and price controls, it was more or less completely ignored. This wage war marked the beginning of a general agitation across the Mediterranean for more peasant rights, a process that would continue for centuries. Nevertheless, farm work and agricultural production gradually improved, and people were finally able to again put food on the table. In the wake of the mass death, famine, and economic collapse that preceded it, this agitating for higher wages seemed like a much easier bullet to take. Regardless of their new issues, things were looking up for the Byzantines and at least the country was getting back to work in whatever capacity it could. Meanwhile, across the Persian border, the plague had taken root and was causing a degree of devastation that the Byzantines understood only too well. In the wake of the catastrophe unfolding in Persia, the king of Lausica saw an opportunity to revolt against Persian rule. Wait, hold on, I know just what you're thinking. The Lausic king? Didn't that guy literally invite the Persians into his country just a few years ago? Wasn't he literally petitioning Kostra to go to war with Justinian so that he could be with the Persians instead? Well, yes, viewers, you got that right. The same king who had just revolted against the Byzantines seemed to have a bad case of buyers or mors and became discontented with his new Persian overlords. Now, he wanted to revolt against the Persians and go back to the Byzantines. Like, dude, we really don't care who you're going to prom with. Just make up your mind already. But in all fairness to the Lausic king, his kingdom was situated as a proxy state between two world powers who could both crush him. He needed to maintain some kind of friendly relations with at least one of them to prevent the other from doing just that. But he also needed to limit infringements on his kingdom's autonomy. Lausica was precariously balanced between a rock and a hard place, and both powers tried curtailing the rights of Lausica at any opportunity, so it makes sense why the Lausic king was constantly on the lookout for a better deal. Nevertheless, the king was now begging Justinian to take him back and send an army to kick the Persians out. With the Byzantines recovering and the Persians now worse for the wearer, Justinian felt obliged to reopen the war with Persia. However, this time they would do their best to make sure all the fighting was done in Lausica. There would be no repeat of Castro's raids in Syria. With that, Justinian ordered his forces into Lausica to support the rebellion. Unfortunately, the same issues plagued the Byzantine forces that had during the invasion of Armenia. The Byzantine commanders were not unified, disorganized, and most certainly not of Bellosarius's caliber. Even in the Persians weakened state, they were still more than a match for the Byzantines, and what ensued was another bloody stalemate, which featured a series of failed assaults on fortified positions. The Byzantine forces would attempt to besiege a Persian fortress, only to have it broken up by a reinforcing army. The Persians would then launch an offensive of their own, only to be defeated and pushed back.  Personally, when reading these accounts and when hearing the stories of these wars in both the east and the west, my mind would continually drift to imagery of the First World War, a force of men led by incompetent commanders assaulting fortified positions over and over again, only to be repulsed each time, the area and communities around becoming more devastated with each attack. On the occasion they were victorious, it would be at a horrific cost as thousands of men who had family, friends, dreams, and passions lay dead in a field, all for a few hundred yards of land. The folly that is war would be humorous, or not so horrifyingly tragic. Nevertheless, Justinian felt compelled to continue his wars and realize his ambitions for storing the Roman Empire. The biggest problem for him was that he just couldn't find a general who he felt was both competent and trustworthy. He truly felt that he was balancing on the edge of a knife when it came to his military leadership, and he did not want an ambitious general to set themselves up as emperor. In his handling of the war effort, his first priority was to get the ball moving again in Italy. It had been years now since Tila had retaken most of it, and Justinian wanted to finally put the Ostrogoths down. Justinian realized that his policy of dividing the commands of his armies was not going to work, and began to look for another solution. But finding a good general was easier said than done. Justinian tried a couple options that for one reason or another just didn't work out, until finally, almost three years after Belisarius had retired, Justinian found his man, Narciss. The reason Narciss was the solution is because Narciss, as it turns out, was a eunuch, and an elderly one at that. Because eunuchs cannot have children, they were seen as more trustworthy, so Narciss had been involved with the government for some time. If you remember back to the Nica riots, Narciss was the one to bribe the blue team to leave the hippodrome before the massacre, and he had served as a general for a brief stint in the first Italian campaign. Justinian felt that Narciss, in his old age, and with no prodigy, was unlikely to revolt against him, and was comfortable giving him a supreme command. So that was it. Narciss was appointed commander, and as the Byzantine recovery continued, Justinian was able to scrape together a force of around 30,000 men for him, which included a lot of mercenaries and allies from outside the Empire. Almost 10 years after the pandemic began and nearly 16 years after the war in Italy began, Narciss set out to finish what Balasarius had started. With his new army, Narciss marched up and around the Dalmatian coast and into Italy. After reaching Ravenna, Narciss travelled south towards his target, Rome. He witnessed the legacy of the Roman Empire personally as his army marched to the eternal city using the old Roman highway system that had been in use for centuries. The roads. It seemed as though they were representatives of the thousand-year-old Empire facilitating Narciss and calling out to him as he marched to restore Rome to its rightful place within the Empire. His army was strong. He knew Tatila could not simply ignore him. He would be drawn out and forced to face the Byzantine army. At a town called Tagene, the two armies met. Tatila saw that he was clearly outnumbered and needed to think of something fast. He had a couple thousand reinforcements on the way, but they were still a ways away and Tatila was vulnerable. The Byzantine army had infantry deployed on a nearby hill and its main force was positioned between the hill and a forest. They had the numbers and the high ground. He had his cavalry try to surprise the Byzantines and overtake the hill, but they were easily beaten back. After, he tried to open a dialogue with the Byzantines, pretending to negotiate terms all the while preparing an attack, but Narciss was always on guard and did not budge. Realizing this wouldn't work, Tatila tried delaying the Byzantines with other antics until the reinforcements could arrive. Finally, they did just that and Tatila felt much more comfortable in his new position, but he wanted to wait until the best opportunity to strike. After some time, he noticed some movement in the Byzantine camp. It looked as though they were preparing to eat and rest. This is my best chance, Tatila thought, as he ordered his troops to mount their horses. Adrenaline, surging through his body, he ordered his cavalry to charge towards the Byzantine center, with himself leading the way. The horsemen were bolstered with confidence as they followed their leader into battle, but as they charged, their confidence was abruptly sapped from each man as they saw movement on both of their flanks in the forest and on the hill. Byzantine archers were filling the flanks, they had trapped them. Tatila had miscalculated and it was too late to change course. As soon as they saw the archers, Tatila's cavalry force was met with a flurry of arrows. The horsemen left and right, horses and men were struck, stumbling and collapsing underneath themselves. It was a slaughter. The Gothic cavalry force was decimated and they routed. Narcies ordered his army forward, and when the rest of the Gothic troops saw what happened, they scattered. Tatila's entire army disintegrated before Narcies' eyes. It's not clear what happened or when, but Tatila was found among the dead. The Gothic king had been killed in the battle. Narcies had won a complete victory. With victory in his grasp, Narcies continued on to Rome. The sacred city would soon be his, marking the fifth time Rome had changed hands during this war. He would fight one last battle against Tatila's successor, but it was futile. The Goths had been vanquished. Though it was the end of the war, it was just the beginning of the occupation and Narcies would spend another 8 years mopping up the remaining Gothic forces as they continued to resist in a regular fashion. In the east, the deadlocked conflict in Lausica continued even after Tatila's death. Time and time again, Persian and Byzantine forces would clash, each of them attacking each other in turn. Finally, a huge Persian force was defeated by the Byzantines as they attempted to capture the Lausic town of Vassis. Out of time and out of supplies, the Persians had to retreat from Lausica before the winter set in, giving over control to the Byzantines. Eventually thereafter, Castro sued for peace and recognized Lausica as a client state of Justinians in exchange for a small annual sum of gold. Breathe, inhale, hold, exhale. The emperor watched as the birds flew over the sea. Now at peace, finally victorious after a near 30 years of constant war, the emperor felt as free as the birds overhead. He had visited these walls many times, and now he felt almost as if he were as old as they were. As his other companions had come and gone, as Theodora had lived and died, as the empire's enemies had raided and pillaged, the walls had been his companion through it all, protecting him and keeping his enemies away. The one time the walls had failed him was perhaps the most crucial. The one enemy the walls did not keep out nearly brought the empire to its knees. Woe to those touched by the plague. What could have been had it not struck? On next week's episode, join us as our series comes to an end. What happened after the wars? Were the Byzantines able to hang on to their conquests? What was the full impact of the plague? To find out, tune in next week to Contagions. Be sure to subscribe to stay tuned and like the video to help the channel grow. Over on Patreon, your host Sean Sharp will be regularly posting content that delves deeper into some of the subjects we would like to explore further but don't have time for on the YouTube channel. Go check it out and become a patron for more content and to support the channel. That's it for us today, we'll catch you next time viewer.


Hello, I'm Matthew Clark-Davison, author of Doubting Thomas.  Anne Packer said, a wrenching professional crisis becomes the occasion for a man to reckon with everything that made him who he is, the loves of his past, his family, and the very job he's in danger of losing. Is it possible, she asks, to emerge from such a moment with hope and an open heart? That's one of the questions that I was exploring as I was writing the novel, and I'm also a huge fan of the San Francisco Public Library. In fact, the novel is partially set in San Francisco, and I worked on the book in title character Thomas' Neighborhood Branch, which would be the Golden Gate Branch on Green Street. I'm thrilled that the library carries the book, and it's electronic version two, and I hope that you'll enjoy. Doubting Thomas, by me, Matthew Clark-Davison.


I would say I'm a bit of an accidental entrepreneur. I was living in New York at the time working for the UN, eating out a lot, eating a lot of healthy food. And when my husband and I were thinking of moving back to Vancouver after we started a family, we noticed that given what an active and healthy city Vancouver is, there just weren't that many awesome salad places. So we thought we would start one. So I really kind of envisioned a salad focused restaurant that kind of married beautiful aesthetic with healthy food. I was really inspired by natural light and a lot of natural materials. Pretty much kind of how the Dunsmeer space looks like today. We wanted the menu to be very focused on salads. And so in order to do that, we wanted to make sure that the menu had some crowd-pleasers like a kale-ceaser, like a field cop, but also some more unique items. Like for example, the Singsons Coconut Chicken, which is a collaboration we did with a local Top Chef Canada finalist or some great plant-based and gluten-free options. So Vancouver is actually quite a small town and I really do make a concerted effort just to try and be connected with what's happening in the food community. There's always exciting innovation. And we try and source also a lot from local suppliers, whether it's Canadian grains by the company Flourist or our kombucha from Culture Craft Kombucha or local company Tempe. As we've grown, we've been able to give them more business and also see them grow as well. And I think we've been very proactive at Field & Social to really cultivate long-term relationships. The social part of Field was very intentional from when we started the business. It was in our initial business plan. We always wanted Field to be more than just a salad place and it's reflected in the design and the communal tables that we have in our shops. And with the events that we hold for the community. So whether that's pop-up brunches or dinners that we've held with local chefs, whether it's flour-making workshops, we really try and host a lot of cool events, especially with the creative community. So giving back has been really important. And so whether it's with our team members providing those opportunities for growth so that we can really see them grow with the company for many years has just been a really enriching experience, I think, for our team and also the brand.


Many thanks to our sister Sabine for that meditation. Before we get into our community agreements, I just want to remind you that there's a conversation lounge for you to have conversations to, or a break to take from this conversation, just to take kind of, you know, good care of yourselves. Now let us remind ourselves of the community agreements that have guided our time together all week. We want to speak to be understood and listen to understand to the extent possible, given this virtual platform. We want to be present and engaged. We want to value our time together and to create the space for meaningful conversations. We want to remind ourselves that challenges only lead to solutions. And again, we want to take good care of ourselves and each other. And by joining this space, you're opting into screenshots. I wanted to give you, so first thank you and welcome to day three of SoCAP Spectrum 2020 convening. Again, Spectrum's vision is to gather business leaders, entrepreneurs and thought leaders, cross sector practitioners and investors, together to address the urgent needs of access, inclusion and impact across capital markets with intention and authenticity. Yesterday we focused our intentions on inclusion, on Tuesday we focused on access and today our focus is on impact. We've had two wonderful days of conversation together. And as we've sifted through the themes and threads, what was not lost on me and I hope not on you is what we need to name as foundational to this struggle of access, inclusion and impact for entrepreneurs of color. That is structural racism and a white supremacy culture. Over the past couple of days, it has come up in different ways and in different forms. And I just want to express a couple of things that have been on my mind as I've listened to the different conversations. We were encouraged to look at the structural roots of access at the intersection of racism and the economy.  There were conversations about visibility and separation, narrative and how the inability to see one another drives the solidification of preconceived notions, biases in our policies and decision-making. That that has bearing on access to capital and inclusion and that we need to develop new tables. So narratives, networks, policy changes came up over and over and over again. There was conversation about power sharing and how people of color share power a lot but that that is not reciprocated specifically by those who hold more power than those who don't have as much but share anyway. Structural racism is foundational. So what do we mean by structural racism? All right, so that's too big of a question to answer in the 15 minutes that I have to share with you but I'll try to put it in a nutshell. Tima O'Koon's piece around white supremacy cultures offers a list of characteristics of culture but to understand structures, one must acknowledge America's DNA is in patriarchy, capitalism and colonization, thus racial hierarchy of a human value. It's connected to colonization. And this is a much longer and complex conversation again but it's necessary. And so for the sake of time, I just wanna share a few things that we all know about capitalism. It necessitates exploitation and often philanthropy, the nonprofit industrial complex acts as stopgap remedies in the public and private sectors appear to be transformational but in actuality, they act as temporary sad to those wounds, those wounded by the harms of a dehumanizing system. When we're saying that structural racism is foundational and that's the reason why we're having such a difficulty for instance, getting capital to entrepreneurs of color, what we're actually saying is that we need a fundamental structural shift to the DNA of our country, not only by tinkering inside the systems that are only designed to provide sad. We keep asking, how do we get capital to entrepreneurs of color? It's not hard to give away money. I was a funder, it's just not. The difficulty lies in the mindsets that inform policies, practices and processes that are in place to create those barriers. We normalize those barriers as things like credit worthiness or rubrics of success or the networks that folks are connected to or the industries that are hot in our growth industries and the list goes on but people make up those rules so that's what the encouraging part is because people made the rules, the rules can be changed. There is a through line about mindsets, networks, policies, narratives and the connections that between those mindsets that are the everyday mundane expressions of racism and dehumanization and they lead to the moments that we find ourselves in today. I've been talking to a lot of folks across the country about the connections between COVID-19 and George Floyd and this conversation here today that we've been having all week is no different. There is a connection. Can you see that connection? It's not a far walk. It's not a different hymnal. They're from the same playbook. How is it that you get from a mindset that doesn't allow you to give capital and expend capital in communities of color to the depth of a human being and a system that protects those who do the killing, right? Those are all connected. So when Sarah Ebelhardt says native people need to be seen, they are invisible. When Erica says we're being pigeonholed around particular conversations and discussions. When we talk about lack of networks and separation, when we talk about race as a risk factor in and of itself, we talk about the lack of family and friend equity that Sharice talked about yesterday. I mean, think about it. Black people on average make about $10.50 more than when we were enslaved. Think about that. So what will it take? Sounds like nothing but to do it. Just do it. Invest in entrepreneurs of color with the same regard that we invest with white people, particularly white men. We just believe that they can be successful. And even if they fail, it's okay. Failure for them is not only an expected but a feature of learning in the brand of their entrepreneurship. Earlier this week, there was conversation about how to leverage white allies. And Keisha shared it again at the top of the hour. And I shared with her that one of my white allies suggested to her white comrades to focus their energy and efforts on spending down their privilege because they couldn't possibly spend it all down. So in this season, where allies are trying to figure out what to do, I would offer these thoughts. Be intentional. Be anti-racist. It's not enough to be racial neutral or race neutral. Develop a set of anti-racist strategies across your bodies of work. Policies, processes, structures, the segments of your organizations. Heck, your friendships, right? Develop those anti-racist strategies. Particularly as it relates to access to capital for entrepreneurs of color, develop structures of accountability. Chicago Beyond talked about noticing and relatedness as powerful tools to transform in the direction of racial equity. Develop those metrics and mark increased capital to communities of color. Invite communities of color to hold you accountable, like real accountability. Afford entrepreneurs of color the same level of opportunity. Account for their situatedness as entrepreneurs of color. Account for their histories in this country and how they're tied to these systems. Support entrepreneurs of color exclusively white spaces. If you go up and you don't see people of color, what actions will you take to change that? And in the same way, if you show up and you're the only person of color, what responsibility do you have to bring someone else along? There was also the work that our brown brothers and black brothers and sisters need to do. Not because we're at fault for this system, but because we must make sure that we remain whole from the negative impacts of it. We must be on guard for the ways that white supremacy culture are internalized by us. I too affirm our value in the same way that Julio got us started on Tuesday morning. I affirm our worth as a people and our ancestors left us the blueprint of love and strength. We are enough. We do in fact matter. And Jay Bailey challenged us because we matter, we ought to invest in our community, not just white folks, but we ought to invest in our community. Yes, white supremacy structures and culture, they're alive and well, especially in this space. And we all must do our part to dismantle it. And now today, we turn our attention to impact, how we move those with capital and power to think and act differently, more equitably to people of color, particularly entrepreneurs of color, such that more capital is deployed in their direction. I wanna welcome to the stage and turn our attention to our first lightning bolt of the day, Michael O'Brien.


Hi, my name is Peter Jackson-Main and we're going to be doing a herb walk here today. We're here in this beautiful location in West Sussex, Woodsland Farm. There are meadows, there are woods, there are running streams, there's all sorts of wonderful habitats for plants, but particularly for medicinal plants. And the one thing about being interested in herbal medicine and medicinal plants is that a walk in nature becomes so much more than that, there's a whole new dimension here. And one of the really important things that I want to get through to you is how easy it is to find these plants. This is natural medicine for the people, so to speak. It's all over the place. Even as I'm standing here amongst almost a carpet of dandelions, normally we would walk through them and not think about them. But today we're going to think about them and we're going to look at them from that point of view. This is what nature provides us with for our healing and for our health problems. So we're just going to strike out and see what we can find. So I like to just really take in this intense yellow of these flowers. They are truly beautiful, very uplifting. And interestingly enough, one of the ways in which they can help to uplift us is by addressing liver congestion. Yellow is very much a colour that's a signature for plants that have an action on the liver. And dandelion is one of the best liver dredgers, as we call it. It's able to clear out the months of accumulation. And I like to think of it, you know, coming up in the spring after we've been eating the heavier, more carb-rich, fat-rich foods over the winter and helping us to just clear the residues of that out of our system. So it's the root we use, we use mainly for that. But the leaf is also a really, really useful medicine and a food. A dandelion leaf is a very good addition to a salad. It's very nutritious, high amounts of minerals particularly. Now the root is more known for liver detoxification. The leaf is an extremely good diuretic and you may know that the French name for the dandelion is piece en lit, which literally means wet the bed. So the idea is this is a pretty powerful diuretic, so it acts on liver and kidneys in fact. The leaf is also quite a good bitter, so if you eat it in a salad, it's quite a good thing to have a bitter green salad before you eat the main part of your meal. That sort of gets the gastric juices going and helps you to digest things better as well. Now we all know of course the dandelion clock, the way this plant seeds itself. Just pick this seed head here, there we go.  This is a method of propagation, a plant propagation called anemocoria, which just basically means movement through wind. And of course the wind is what comes along, it disperses the seed head, seeds go all over the place and the result is a field like this, with so many in you can't count them.


Hello again, thanks for joining us for session four of six about building form and placement standards today. Thanks for joining us for the prior three sessions and by now you're becoming an expert in understanding about form based codes. And so thanks for the time today. Building form is the topic of building size with depth height and shape. And you might just say well don't buildings just go from top to bottom and it's it's about how tall they are. And the answer is, well that's part of it, but, but there's a lot more to that answer. You can see here the different sizes and shapes of buildings and so building form standards are a way to regulate and predictably allow different types of forms that are local to your area or that you want to make local. And these kinds of standards, both shape the individual buildings but they also independently and incrementally shape the public room you can see here in the middle of the slide, you can see that the tree line street and sidewalk, being independent individually shaped by each of the buildings. And the reason building form standards are important and purposeful is because conventional zoning, simply just talks about height and setbacks, and leaves it up to the individual project to describe and fill what you see in a in the red outline. And that's all it just says it says you can fill your building all in there, and then come the meetings with the neighbors and the local community, saying well, okay, that's, that's too much, you know, or it's too big. And so it's really helpful in a form based code to have building form standards that speak to the priorities, and, and what's acceptable in the different neighborhoods. So that, that information, then gets summarized into these intense statements that we talked about in the last session, where they're qualitative statements about the building size and whether or not they're attached or detached and the size of the setbacks and maybe the overall number of stories and maybe the ground floor has particular height that needs to be maintained to maintain the physical character in an area, and the kind of frontages, porches, stooped story arts or other other types of frontages that make a particular character. So the first topic we want to talk about here is where the building can go for more formally building placement and setbacks. And so the, the gray area on each of those lots in the example on the screen here identifies where the building can go. That's the buildable area your building can be placed anywhere in that gray area and then outside of that. And what's interesting here about the form based approach is that you do you see the little diagonal band in the area H and I on the on those two examples.  So what I'm saying is that in order to effectively shape the public realm in this particular zoning district. The buildings need to be in that location in the front and side streets to provide that beautiful relationship between the facades on each side of the street and the street trees and then and the street itself and then the sidewalk that you walk on all that. So that's the relationship between the facade, the distance between facades and sidewalk, and how it feels and so that's going to be different, saying a main street versus a neighborhood and so that's a very important aspect of how for base code incrementally shapes the public realm, in addition to the other setbacks that are that are regulated. So if you put a building on there and and through your building size footprint and massing standards, you can start to fill out that allowed gray area that was shown in the previous slide with the allowed building size and footprint. And you can see here. There are issues of pedestrian access and outside open space, as well as the overall footprint of buildings and. And there are options for how to how to do that it might. In one case you might say there might just be a maximum width and a depth of the building footprint and other cases you might say we're going to further articulate that building envelope. That's allowed by the zoning by using building types that have different shapes and sizes. And so we'll we'll be talking about that in session five and just looking at the importance of building placement and setbacks. I can't tell you how many codes. I look at that have a lot of great information about built building form and frontage and streetscapes in the public room, but they don't identify where the parking can go. And so the, the, the example on the right, although you might say well that would never happen in our town and maybe architecturally it wouldn't. But the parking area happens in a lot of modern codes that that don't address the issue of of where the building can go versus where the parking can go. So when you think of a building placement also think of parking placement. And then building height, very important. And, you know, it's, it's, it's like signage you know a lot of cities look at signage in a in a very pejorative way, very negative way, then building height is similarly seen by a lot of regulations. And yes, you don't want a building that's too tall in the wrong place, but you also want to let buildings be effective and have nice tall floors for a lot of light and more of an airy feeling in those floors and so we we found is that instead of only regulating overall height, as you see in D, the item D here on on the screen to also regulate item C, the maximum height to the highest Eve, we found that that that combination of measurements is very effective and if you only had to measure one or you could only measure one we would recommend C of the maximum height to the highest Eve. And all you have to do to really understand the value of this is to go look at a building that complied with the maximum height in the city, but either dug out the height to lower the building below the sidewalk where it's measured or squatted, you know, a floor and you know slotted in another squatting floor into the volume of the building and people look at it and say well that building looks squatty. So, you want to really consider building height. The way that we're talking about here. Again, parking placement we talked about this and why it's important. I don't know of all this. Why does all this makes sense. Because, you know, conventional zoning doesn't look at these individual elements. Again, going back to session one conventional zoning was was never intended to make anything. It was always intended to prevent bad things from happening and determine, depending on what bad means in your community. And so, that's certainly half of the of the questions for the other question is other half of the question is, what are you going to make once you stop what what you don't want. What do you want. And so the form based code coordinates all this into these physical outcomes. And you can see here, these four key characteristics of these outcomes. Thank you very much for your attention today and we look forward to attending the next session.