In our previous video, we talked about the idea of symmetries, symmetries of a mathematical set of mathematical objects. And symmetry always leads to the idea of groups, that if we collect together all the symmetries of an object, this always forms a group. But I told you that the context matters, right? If we look at it as just a set, that's the symmetry type. If we look at it as a geometry, it's a different symmetry type. If we look at it as an algebra, that's a different symmetry type. And so I want in this example to play around with the mathematical object R to the N, right? Because Euclidean space is a beautifully complicated mathematical object with a deep interplay between algebra and topology. So for example, as an algebra, you could call Rn a vector space. This is something we study extensively in linear algebra. Rn is a vector space with vector addition and scalar multiplication. When we give the dot product to Rn, it becomes a so-called inner product space, which is an even stronger algebraic object. But this inner product leads towards the geometry of Rn. With the dot product, we can discuss lengths and distances and angles. This makes Rn into a metric space, for example. We can talk about distances, distances and lengths, right? A metric space forms a topology on Rn by which we can start discussing things like convergence sequences, Cauchy sequences, completeness, compactness, limits, derivatives, et cetera, right? And so based upon the focus we have on Rn, that'll determine what type of symmetries are we talking about. Are we talking about algebraic symmetries? Are we talking about topological symmetries? Or maybe we're talking about both, right? Because like I said, the geometry of Rn can be defined using algebra. And you can probably go the other way around as well. You can use the topology, you can use the geometry to define the algebra of it. And so these things interplay with each other, so maybe we want symmetries that measure both. So the symmetry type of Rn depends exactly on what type of object we're studying for a moment. So if we view Rn as a vector space, what does that mean? Well, a vector space has two, it's an algebraic object that has two operations. So there's the first operation which we call vector addition, which this is a binary operation, meaning that we're going to take two vectors from Rn, we take two vectors from Rn, we combine them together, and this produces a third vector from Rn, and it's vector addition, it's a binary operation. We also have the notion of scalar multiplication. When scalar multiplication is not a binary operation properly, because with scalar multiplication, you take a scalar from R, you combine it with a vector from Rn, and this produces a vector R from Rn, right? And so this object against not technically a binary operation, this is what we might call an action. To be more precise, this is what we call a ring action, because the set of scalars is a field. And so it's acting on this module over here. But we have this, you don't necessarily have to worry about exactly what this is, but we have this ring action that is we're combining, we're taking together a set with another set. These are not necessarily the same sets anymore. And we combine together to give us one of the two sets we started off with, okay? So we have this action in play here. But this is still an algebraic structure here, again, not a binary operation properly, but the two things are very important to the algebraic structure of Rn, okay? So the symmetries of Rn, when we view it as a vector space, need to be permutations of Rn, which preserve the vector structure, namely vector addition and scalar multiplication. Maps that preserve vector addition and scalar multiplication are just, what we call in linear algebra, linear transformations, linear transformations. That is, these are exactly the functions on Rn that preserve these maps. So if we're looking for a map from Rn back to itself, we need a function which let's say, if you take two vectors, we'll say u plus v, this needs to equal t of u plus t of v. That would preserve the vector addition. So we just pause there for a moment. It needs to be a group homomorphism with respect to vector addition. But we also need that if you take t of R times v, this is going to equal R times t of v. So remember, scalar multiplication, you take a scalar times a vector and you get back a vector. So what this transformation needs to do is that if you take a scalar times a vector and then you act by the map, this is the same thing as acting by the map, which produces a vector and then you scale by that value. And so we need that this, that the transformation, it's a homomorphism with respect to the group operation of addition, but it also needs to be homogeneous with respect to this ring action that's in play.  That needs to be a permutation, right? So the, the automorphisms of Rn are going to be those linear transformations, which map the vector space back into itself and you see one to one and onto. And this produces, in fact, a symmetry group we're already quite used to. We get the so-called general linear group, GLN of R, right? This is going to be a set of all, and it's going to give us all of the n by n matrices such that a times a n versus equal to the identity, right? They'd have to be non-segular matrices. So the general linear group, right? It has to be, every linear transformation, you could show this in linear algebra. Every linear transformation can be represented by a matrix multiplication, by matrix multiplication. And if you're going from Rn to Rn, that is, if you're looking for, you know, you're looking for some transformation that goes from Rn to Rn, it's a permutation. Well, matrix multiplication will send you from, if you have an m by n matrix, excuse me, m by n matrix, this will send you, this will be a map from Rn to Rm. So you need the number of columns and rows to be the same so that it becomes a map from Rn to Rn. And so every linear transformation can be represented as a matrix. If it's going to be one to one and onto, the associated matrix has to be non-segular. And so we get the general linear group. So the general linear group is the symmetry group of Rn if we view it as a vector space. Well, what if we switch our focus and we start focusing on the inner product space structure of Rn? Well, in addition to the, in addition to addition, right? So we have the vector addition that we had before, right? We had the scalar multiplication from before. That part has to be the same, right? So we, so because an inner product space is a vector space, but in addition, there's also this bilinear form of which we call the dot product, which we also use a dot. But I mean, scalar multiplication is usually written as a juxtaposition. Well, the dot product is actually written with a dot. The dot product looks like you have, you have a vector times a vector, but then it produces a scalar. So again, the two sets that you operate on, that the product is actually not belonging to that set. Like I said, this is what's commonly referred to as a bilinear form. We can give the details of what that definition means later, but that's, that's what's going on here. If you just take the first two operations, we get a linear transformation like before, right? But then when we put this together, we need, we were looking for bijective maps on Rn, that preserve vector addition, scalar multiplication, that'll make it a linear transformation. But then we also need, we need it to preserve this dot product structure. And so we get, actually, if we want something to preserve the dot product, it's got to look something like the following. You can represent it like a matrix. We need that ux dot uy is equal to x dot y. We need, we need to find those matrices that preserve the dot product in addition. Because, because if you're a matrix multiplication, we'll preserve addition and the scalar multiplication. We've talked about these before. This is exactly the orthogonal matrices, right? So we need an orthogonal matrix in this setting, which the set of orthogonal matrices is exactly what we called previously O of n, the orthogonal group. So the orthogonal group is the group of symmetries of Rn when we view it as an inner product space. It'll preserve vector addition and scalar multiplication because they are non-singular matrices, orthogonal matrices are, but also presumes the dot product because they're orthogonal matrices. We, that was a property of orthogonality we saw previously. Now from, from the inner product, we can define lengths and norms and distances and angles. Orthogonal matrices preserve all of that. We've mentioned that before. And therefore, the orthogonal group is the symmetries of Rn when we view Rn as both geometric and algebraic. So if, if Rn is both a geometric and algebraic object, then O n is its symmetry group. If you view it just as an algebraic object, you've got the general linear group as its symmetry group. Well, what if we only want to view Rn as a geometric set? Geometric structure, what we call from topology would be a metric space. Now a metric space is going to be a set equipped with what's called a metric function, where D would be a map from Rn by Rn.  And so again, this is what we call a metric. It has a similar shape to what we called the bilinear form earlier. It has different axioms like we need the positive definite condition, we need the triangle inequality, we need symmetry. And so if we are looking for distance preserving maps, then we get what we call an isometry. So an isometry, as the name suggests, it means same measure, same distance. Isometries are those maps which preserve distance. So we'll be looking for, we'll call it sigma here, for permutations on Rn to itself, such that the distance between two vectors, so sigma of say x, sigma of y, this needs to equal D of x comma y. So we want the distance between two vectors to be preserved. Now with regard to the orthogonal group, right? We had our orthogonal group earlier. The orthogonal group has essentially two types of matrices inside of it. You have rotational matrices, which are going to correspond to those orthogonal matrices with positive one determinant. And you also have reflection, reflection matrices, these are going to be those orthogonal matrices whose determinant is equal to negative one. Now in this setting of the metric space, where we don't care about the algebra, we only care about the geometry. Then we of course get a lot more variety on what we can get. Like just think about pictures in the plane, for example. If we wanted to rotate around the origin, right? That would be an example of an orthogonal transformation. We could also reflect across a line that goes through the origin, right? Those types of reflections would also be orthogonal reflections. But we have other others that we could put into play here. So for example, we could rotate around any point in the plane. It doesn't necessarily have to just be the origin. We could reflect across any line in the plane. And that reflection would be acceptable as well. Now I'm just drawing pictures in R2, right? But imagine the higher dimensional analogs of these type of things. Another possibility that you get is you get the idea of translation, right? So what if you have some point right here and you translate it by some fixed value? We'll call that vector v. In which case then you translate every point by that same fixed value. So we get these translation vectors. Now, unlike rotations and reflections, this translation could not be an orthogonal matrix. Because orthogonal matrices, which give us linear transformations, they are additive group homomorphisms. The identity of a homomorphism has to go to the identity. But a translation, as long as you're not translated by the zero vector itself, it'll move the zero vector. So translations could never be represented by an orthogonal matrix. But reflections and translations like reflections and rotations, they only are going to be orthogonal matrices if they're either around the origin or through the origin. But I want to mention here that in some respect, we can actually create, it turns out, orthogonal matrices and translations are all we need to talk about the isometries of Euclidean space. So think about the following idea. What if we have some point that we want to rotate around? So we have some point space that we're rotating like so. What we could do is we could first translate that point to the origin, okay? Then while we're at the origin, we could rotate around the origin and then we could translate it back, right? So we have like a minus V, which V is the location of this point right here. And then we could add it back here.  This is what we described earlier as conjugation. Conjugation is what we're talking about right here. So for example, if you have some type of rotation, you know, rotate around the point V, well, this is just going to look like you translate by negative V, then you rotate around the origin and then you translate back by V for which these two translations are inverses of each other. So this is translation by V, rotate around the origin and then translate by V inverse. Again, that's what conjugation is all about. And so what I claim is that using reflections rotations, which those together, if we do them with respect to the origin, those are orthogonal matrices. If you've been throwing translation, this captures every type of isometry. And to describe the symmetry group, that is, we want those isometries distance preserving maps that don't necessarily preserve the algebra. Then it turns out the symmetry group of RN is going to look like the following. We're going to form a set, which we call E of N, which as a set, it's going to be RN times O N. And the way we're going to think about is the following way. O N captures rotations around the origin and reflections across the origin. I should say across a line through the origin. So in some respect, the orthogonal group captures the important rotation and reflections that one can perform. RN, we can actually identify it with the translational subgroup, right? Because like we were doing earlier, we can identify translations with a specific vector in space. So this RN, we want to think of it as the translation of the plane. And so as we were saying earlier, every rotation and reflection could be described as a conjugate. So every rotation and reflection in the plane, for example, is just a conjugate of an orthogonal matrix with respect to translation. And in higher dimensions, analogs to this hold true as well. And so you want to think of this RN right here as the translations and this right here as reflections and rotations with respect to the origin. So this as a set is going to just be RN Cartesian product O N. But in terms of multiplication, we're going to come up with a different rule. So if we have say two vectors U and V inside of RN, so we think of these as translation vectors, we're going to have two matrices A and B inside of the orthogonal group. Then we're going to find our operation in the following way. So circle will be a binary operation from EN times EN to EN.  And so this is going to be an element of EN. Let's convince ourselves of that. Well, since A and B are orthogonal matrices, their product will be orthogonal. And this then the second factor works. How about the first one? Well, we need to get a vector in RN for which if you take a vector V and you times it by any matrix, you're going to get a vector in RN. And if you add two vectors together, you get RN. So this does in fact check out. I mean, it's a binary operation, but this is form a group structure. If it's a symmetry group, it should be. And one could argue that this thing is associated by arguing this is in fact the symmetry operation. But there's a little bit more detail that one would go into. Now, the easiest way to argue that this is in fact a group, particularly associativity is the hard part, right? The identity is pretty easy. You could check out that the zero vector combined with the identity matrix. This of course is an element of EN and it'll be the identity. You can from here derive what an inverse would look like. Associativity is kind of hard, but it turns out that the main argument here is you're going to... One introduces what's called a semi-direct product. That's actually what this thing is, a semi-direct product. So we might actually denote EN here as the semi-direct product between RN. So it looks like a cross, but there's a line over here and ON. And so the difference here is that unlike a direct product, which is actually just a special case of a semi-direct product, a semi-direct product is a direct product with a twist, right? You'll notice in the second factor, you just multiply the two things together component-wise. If this was a direct product, we would want to just take U, U plus V, but the things you add this twist to it. So instead of taking U plus V, you can think of it as U plus the identity V, but instead of the identity, we get some other vector of the matrix here. So you add together the vectors, but there's a twist to it first. And so hence we have a semi-direct product. It's a product between groups, which can be... It adds sort of like this non-commutative flair. Even though the sum of two vectors is abelian, we've added sort of like this non-abelian component, this twist, this action comes into play by the matrix. And so as you study more about semi-direct products, you would see that this is a very standard group construction that one gets quite used to. So let me kind of give you a special case of this. This right here is what's referred to as the Euclidean group, which is why we called it E of N. And that's because it's the symmetry group of the Euclidean geometry, Rn. In the special case where we have, say, R2, right? So this is the Euclidean plane. In that case, E2, this of course would be the semi-direct product between R2 and O2, like so, for which it turns out that every isometry in E2 can be classified in the following way. You're going to get rotations, which every rotation in the plane can be factored as a conjugate of rotation around the origin with respect to the translational vector associated to the center of the rotation here. You can write every another type of isometry here as you get reflections, which you can get reflection across any line in the plane for which if that line doesn't go through the origin, you can factor this reflection as a conjugate of reflection through the origin with respect to some translation. So like I was trying to say earlier, if you have some type of reflection, you could translate this to the origin, reflect across that line, and then translate it back. So every reflection can be then factored as a conjugate of an orthogonal reflection with translation. So translation also is in play here. And it turns out that you can show that the only other type of isometry in the plane is what's called a glide reflection. A glide reflection is actually just a combination of a reflection and a translation. You want to think of it in the following way. Think of it as like walking along the beach and looking at your footsteps. So if you take like an asymmetrical object like J, if I were to translate it and then reflect it, you're going to get something that looks like this following. And so that's what the glide reflection does. It's this combination. It's when you translate and reflect and they're perpendicular to each other. So the axis of translation is perpendicular to the axis of reflection. And so then if you repeat this process, you get what looks like footprints along the sand. And it turns out that in E2, every isometry can be written in one of these four types, rotation, reflection, translation, and glide reflection, which from a group theory point of view, glide reflection is just, of course, combining these together. And so basically from a group point of view, we're saying that every isometry on the plane is generated from translations, rotations, and reflections, which that becomes obvious by this statement right here. And that statement is also true as we go into higher dimensions. If you move to, for example, E3, every isometry is generated from rotations, reflections, and translations, but you can get some more exotic things. In addition to these, you get things like screw translations. You can translate along the line, but you're kind of rotating around the line. You get some fun stuff in higher dimensions. We're not going to delve too much into that right now. The Euclidean group is a pretty fun group when you start looking at it from this geometric perspective. And sometimes it's considered one of these classical groups we had introduced previously. It's not a matrix group proper because it's a semi-direct product between these, between this translation group, which is Abelian with this matrix group. But some people include it in this list, in the list of the classical linear groups. And so I want to present maybe one more example in this video here. What if we think of Rn just as a topological space? So we don't even worry about distance preserving. We just want continuous permutations. That is, if things were close together beforehand and then you take the permutation of Rn, things are still close together. Even though distance could be distorted, shapes could be distorted. We just want things to be close. That if you start off being delta close, then down guarantee that you're epsilon close after the fact. What about just continuous permutations? The topological space is sort of a weaker geometry. It's sort of like the weakest form of geometry for which calculus is still possible because the notion of a limit still exists. So if we want continuous permutations, we actually get what's called the affine group. The affine group. The affine group is formed in the following way. It's very similar to the Euclidean group. We'll call it f of n. And this is going to be Rn, semi-direct product. Whoops. It'll look like semi-direct product with the general linear group, GLN of R, in which case multiplication will look like it was just a moment ago with the Euclidean group. So if you have U, A, circle, V, B, then the product will look like U plus V with a twist time and then A times B right here. And so I want to point out to you that the Euclidean group can be viewed as a natural subgroup of the affine group where we're just removing the assumption that this is an orthogonal matrix. So distance preservation isn't necessary anymore. So if you think about these things, like if you take one of these affine maps, what that means is something like the following. If you take U, A, and you times it by the vector X, what this is going to do is this is going to give you U plus AX right here. And that's to say that X will translate, X transforms into U plus AX. So you do some type of linear transformation to the vector. That's going to be with like around the origin and then you translate by U. And that describes what we call an affine transformation, an affine map for which isometries are special types of affine maps. Isometries are those affine maps that preserve distance. So it preserves the metric structure. The affine group, it's also a semi-direct product. It just preserves the topology, just preserves continuity. So let's see, in addition to the, in addition to sort of like the isometries we had before reflections, translations, rotations, we also get like stretches, compressions, dilations. So things can get distorted. Like you can get, you can stretch things out. You can compress things down. That's a possibility because that'll change distance. You also get something like a shearing map. That's kind of an interesting thing where if you imagine like your shape is kind of like this stack of like cards on like a deck of cards. If you were to push it, then this would translate into some type of shearing map of some kind. So things kind of like lean a little bit. A shearing map can take like a square and it can change it into like a parallelogram like so. And so that's an example. Distance is not necessarily preserved, but things are still continuous in the action. The nice thing about shearing maps is that shearing maps actually still preserve area even if sometimes they're called transvections. A transvection will preserve area. So like the area here is the same of the square is the same as the area of the parallelogram. Of course, if you're stretching or compressing things, dilation will not preserve area. So those things will be lost. Parallelism can still be true when you do a lot of these things. Things that were parallel before will still be parallel after the fact. And so the affine group preserves all of the topological structure of RM. So the last thing I want to ask here is the special linear group, asymmetry group, right? We went through all the algebraic geometric in combination of RM. How do you view SN, SLN of R as a symmetry? Can it be done, right? I mean, if it's one of the class of groups it should be preserving some type of symmetry. What do we know about the special linear group? We're talking about all those matrices whose determinant is equal to one, right? So these are going to be affine maps, but they're determined equal to one. What's the geometric interpretation of that? Well, it can be shown here that if you're determined as equal to one, that actually implies that we're going to have area preserving, area preserving linear transformations. Area, it preserves area, area preserving maps. So like we talked about earlier with metric spaces and we got the Euclidean group, the Euclidean maps are all those that preserve all the symmetries. They preserve the distance function. Well, what if we want to preserve the area function? So if we preserve the area of this thing, so it's like the area of some type of shape we'll call it S needs to equal to the area of say sigma of S where sigma is this permutation in play here. And so all of these classical linear groups are in fact, symmetry groups of Rn when we take the right perspective. Are we trying to preserve algebra? Are we trying to preserve geometry? Are we trying to preserve both? And what parts of the algebra? Do we want to preserve just the vector addition in scalar multiplication? Or do we want to preserve the dot product as well? Do we want to preserve the norm? What parts of the geometry do you want to preserve? Do you want to preserve the distance between points? Do you want to just preserve the area? Or do you want to preserve maybe just something weak like continuity and we just want sort of a weak nose and things that were close are still going to be close again. And so we can get all of these asymmetry types if we want to, like we could talk about, oh, Rn translation would preserve area. So we could take Rn semi-direct product, the general linear group, right? Like so, so we could take this group which preserves which would preserve area together. The SLN of R here would be those permutations that preserve area and preserve the vector structure of addition and such. So yes, symmetry depends on perspective. What structure are we trying to preserve? And if we do that, we get these different types of symmetry groups. So I hope that these examples on Rn can give you an idea of what symmetry is all about. We're looking at groups that preserve structure of a set and the types of groups we care about depends on the type of structure on the set.


Okay. Well, thank you. I think the KCA is a fantastic resource. If you guys have been on the website, the national website, tremendous information source and links, and then local KCA chapter as well, whether it's something people are interested to participate or just want links to resources. I know that would really be a great point of contact to help out. Okay, I'm not live here. So my understanding, and Kerry's going to come back at the end to wrap things up, that yes, the materials from today will be posted to the KCA website. And I think also video of the presentations as well. So I think you can find everything. There will be a delay until it's all processed and ready to post. She can tell you what that timeline looks like. So I so thankful for everyone coming out today. I don't want to spend too much more time, but just a couple items at the end here I wanted to to pass along. So something I thought to present to this group, perhaps it's it's late for people already diagnosed, but something that we are excited about bringing forward on our campus here is what we call a multidisciplinary clinic approach to patients coming into our system that are newly diagnosed with an apparent kidney tumor. And the faculty you met today, the point man for urology will be Dr. Gore, the radiation oncologist Dr. Zhang that spoke today as well. And the format for this would be a first clinic appointment for a patient would meet with specialists from each of three different disciplines, meto urology surgeon, a medical oncologist and a radiation oncologist all in the same afternoon. And those physicians as well in real time as part of the afternoon will review the outside if it's outside pathology, whether it's biopsy or nephrectomy if it's been done and review radiology studies and then present to the patient a plan of action, what's going to happen moving forward and having coordination so that follow on appointments with whomever the patient should see next are taken care of at that point in time. So I think it's I think it's it's something that we do for other diseases and I think it's going to be excellent for kidney cancer because a big portion of our patients need to see medical oncology, need to see urology, might need to see radiation oncology and we waste so much time just making referrals and waiting for our colleagues to see patients. So I think it's going to be a great a great opportunity and I think that's going to be very well received. So no just these core core folks so cancer centric assessment, nephrology care may be very relevant to patients but that they're not going to participate in the actual cancer therapy per se. Other ancillary supports, nutrition, things like that are not right now intended to be embedded but depending on interest and common referrals we make we can always pull in another type of service if we think that's going to be relevant but this would be the starting folks. It's been done for years for example for breast cancer many breast cancer patients need surgery and then radiation and then medical therapy, chemotherapy and so pulling them all together into a single daily single-day assessment get all those recommendations all at one time and build out the treatment plan as was very well received in that context and so building on that experience and a little copycat from our group. And so the last thing I just wanted to throw out we'd love to hear any feedback positive or negative we do plan to try and make this an annual event moving forward and as you're thinking about what you heard today if there's things on your mind that you wish we talked about shoot us an email or give a call and let us know and we'll keep that in mind for next year's program. Each year would be you know a novel set of speakers and we can try and tailor it if there's strong interest in a specific direction. So I put contact information up here many of you are in our network if you have phone numbers the nursing line or emails or our scheduler whomever you regularly contact shoot them a note they'll pass it on to me if you don't have our contact information Samantha lepides contact is here she's my administrative person that really pulled us all together it made it happen so she'd be the best point of contact. And then the last thing I wanted to point out I have had some patients that were very interested in what's happening on our campus in a very detailed way there is the opportunity for those that are interested to come to our campus to tour a research lab or other facilities that you're interested in and get a much more in-depth presentation and discussion with folks on our campus a lot of the more basic research wasn't part of today's talk we're really trying to focus on what's the patient experience right now things that are in the research lab today would be several years off before it would come to some sort of fruition that might impact patient care but if you want to look under the hood and see what's going on the our development folks would be the liaisons to set that up for you to meet you here on campus to give you a tour help you meet folks that you thought were doing things that you found that were very exciting there are opportunities on our campus there's something called scientific lunch where different faculty members and this would go beyond the context of kidney cancer give talks to to an audience of people from off our campus that are interested to hear about science it's meant to be for a lay audience it's a free event but just learning the calendar and seeing who's talking again our development folks would be the ones to give you that information so I invite you once again to reach out and make contact if you're not sure who to get hold of these would be the people that you could contact directly but reach out and contact me and I'll hand you off to those folks and help you set that up I know that's not for everybody but it is something that we're excited about we think about kidney cancer every day and we have our nose in projects and research we're trying to work on and if somebody's interested to learn more about it it's really we're very excited to hear that and be more than happy to talk to you so that's that's all I wanted to pass along to wrap things up I do want to pass along a few thank you's KCA that that brings this program together care you met today but also Stephanie Shirley that doesn't come out for the program but does most of the coordination for us to set it all up the faculty that you met today Julian art that are the glue that run the local KCA chapter and certainly all of you patients that are in our network patients from other networks and their families and lastly people not here today but Samantha Jesse Kaston Laisa some of you know my my scheduler for the clinic volunteered to reach out by email and try and contact as many of our patients as she could to remind you of this program so I certainly appreciate all their help to bring this together


So Matt has been so kind all day and introduced all these lovely speakers, so I thought it was only fair if somebody introduced him today. So fun facts about Matt. If you're familiar with his previous Twitter profile photo, it was a professionally done photograph of his dog Dash, who's the tiniest little mop of a dog. He's very cute. He's our polymer mascot. He's also a terrible driver, and our co-worker Kevin shrieks usually when he's in the car. The shriek that you heard on Chris's video wasn't Chris. It was Kevin, who's at home right now, and he was just shrieking out of sheer excitement. So there you go. Matt McNulty. While you're looking at my speaker notes, PWA is a cool new thing, you guys. We've heard about it. We know our apps should be, well, sure. I'm Monica. I'm not a well-referred Twittering GitHub. That is my Polymone. May it bring you luck in battle. It's a meowing cat. It has a lot of eyes because it's an unchecked Unicode experiment. But PWA, cool new thing. We like PWAs. We want our apps to be PWAs. They should have the native feel. They should work offline. They should be awesome. They should make Jake Archibald really happy. But that's like a really daunting thing to do if you start from scratch. I have an index on HTML. It's really blank. How do I actually get to have a PWA? Would it be nice if we had an element for that? Two years ago, we used to say this a lot. There's an element for that. Turns out there is. And I'm going to tell you how to use all of them and write the least amount of code possible. So here's the thing. I've never actually built an app. And I'm super bummed because Eric Bidleman stole my joke without knowing. Because the joke is I've built single-page apps and they're not what you think a single-page app is. It's literally just an index on HTML with a lot of crappy JavaScript on it. And it's just client-side and has one route and it's index on HTML. That's the kind of things that I normally write. I write a lot of elements. I've worked on other people's apps, but I've never started with a thing. And I was like, I will make an app and it will work offline and it will have a database. So I thought, if I make the most complicated app that I can think of, and it only takes me three days, that means you guys can make literally any app that you can think of in also three days. So I looked at everything that I used every day and I didn't look at any games that I play on my phone because the challenge with games isn't to make them a PWA is to have a game idea and I don't have a game idea. So I looked at Twitter and Facebook and inbox and Reddit and whatever I use. And they're basically the same app. They look a little bit different and they serve different kind of data, but they're the same app. They have the same things in common. They've got users, it's not just me and my cat hanging out tweeting at each other. These users are authenticated and they're not authenticated because we're trying to steal their names and credit cards, they're authenticated because they look at different kind of data based on who they are. I have different Facebook friends that you do, I follow different people on Twitter. The timelines that we see are very different. And that comes from authentication. This data that they look at, it's in the cloud. I don't download the entire Facebook written word to my phone so that I can read it on the bus. I get it from a cloud and when I'm done with it, it goes away. And ideally, this data should also be available offline because if I'm on a bus and I run out of internet, I don't want to make eye contact with a stranger next to me. I don't want to keep staring at my tweets. It should obviously be responsive. It should not look the same on desktop and mobile. It should be awesome. It should be fast because I'm on a bus. If I'm looking at something, it better also not be a 12-minute loading screen. It's got to have routes because you've got to hard code to things. I can link to a post. I can link to a Twitter list. And finally, it should be accessible. And here under accessibility, I'm doing a lot of things. It should be accessible by keyboard and by voiceover and stuff like that. But I think it should also be internationalized. And this isn't a thing we talk about a lot. Here we're in England. Everybody speaks English. I'm Romanian. Not everybody speaks English in Romania. So I would like Romanian users who don't speak English to also be able to use my app. What I didn't write on this slide here was push notifications because at the time, I was like, ain't nobody writing a server. I'm not writing a server. No push notifications because Michael Bly didn't tell me he was going to solve push notifications with Firebase. So maybe in a week we'll have that done. So let's build this up. This is my app. It's called MojiBrag.  Let's try this. Let's try to click on the button. Nice. So this is the app. It's basically like a Twitter Slack clone. Everybody posts emoji things. You can like them. You have different channels. You can create private channels with only your friends. You can create global channels that everybody can read. And every time you type in it, any English that you type gets translated to emoji because, obviously, why not? If there's multiple words that translate to the same emoji, you get to pick your favorite one. This app is also internationalized, which means you're about to see it in traditional Chinese, which is kind of exciting. It's not a language that I speak. All the languages that you saw out there are the languages that the people in the Polymer team speak. So basically I just harassed everybody that I know. And I was like, translate these strings for me. It'll be great. Do less, be lazy. So Steve has said this. Everybody has said this all day. I said it in Google I.O. Do less, be lazy. Somebody asked me on Twitter, Steve said it first. He got it from this weird podcast that he listens to, where it's a man yelling at you to do less and be lazy and be more efficient.  I try to do the least amount of things possible. I am the laziest human being. I enjoy sitting on the couch and getting up when I run out of food on the couch. And this is exactly how I built this app. I looked at all of the elements everybody else wrote, and I took them, and I was like, not writing anything else other than that. And thankfully, the beginning is the Polymer CLI.  You download the starter kit template, which has got everything that you possibly need. Look at it. It looks amazing. It's responsive. It looks different on mobile and on desktop. It has routes. It has three different views that already have different content. You can link to them. I've got two items off the list. Even how a service worker, so my app already works offline. Setting up a service worker isn't that easy. But the Polymer CLI does it for you. It even has a built pipeline, so it bundles all of your things so that you only make one HTTP request for all the bucket of dependencies that you need. This is amazing. I've made so much progress, and all I've done is a copy-paste something from our website. Let's talk about authentication. This was the thing that I was the most scared out of, because previous times that I've tried to look at OAuth in the eye, I can't even pronounce it. This is trauma. It was awful. It was not great. There was many different kinds. And my callbacks didn't work. My tokens weren't right. And nothing ever worked. But you heard my goal, Firebase. Firebase is that knife that cuts through the shoe and also the coke can. You can use it for literally everything. And Firebase and Polymer are kind of magical together, because they both have the same goal.  Firebase app is an element from Polymer Fire, which I will call PolyFire, because that's what it is in my head for some reason. Sorry, Chris. So with this one element, you get like three things off the back. You initialize your connection to Firebase, which gives you, bam, a database, sorted, bam, an auth domain, so that you can actually authenticate with your favorite authentication provider.  You get SSL. You get HTTPS. That's like many step stores being a PWA. And with OneLine, you can actually authenticate. Here, I'm choosing Google to be my authentication provider. And when authentication completes, I get this user property. So I can bind things from this user property. I can bind the avatar or the name somewhere in my app and display it. And if I got an entire app with OneLine and Polymer, I get authentication with OneLine and Firebase. That is the OneLine. This is A plus for lazy. This is how you log out. And every time you change your state, you get a callback. It's on off-state change. And you can respond to this user property. This is amazing. That's it. That's all we have to do for authentication. Problem solved. The next thing I was scared of was databases. So story time. I used to work for a bank.  And they have really scary tables that are indexed weirdly. And you have to do a lot of joins and ordered buys. I don't really know what that means. So the idea that I had to do this on my own was like nobody holding my hand. Not a good idea. Guys, Firebase. Firebase is everything for you. It does a database. And it's a really nice database. And Polyfire gives us elements. Firebase query is, oh, no, no. I wasn't ready. Firebase query is basically like a declarative select star. It gets the entire contents of a query and it puts them somewhere. And app indexed to be mirror is this amazing magical thing that basically proxies that data and holds it so that it can serve it to the application whether your application is online or not. This is amazing because this means you're getting offline data basically for free. And what I mean is this. In your normal situation, you have a database and you have your app. And you get stuff from the database and you show it on your app. And it's really great. The mirror sits in the middle. So you get your data from the Firebase query. You put it in this intermediate mirror. And then you serve that data to the app. This is really great because if your internet connection goes away, you no longer have live data, you can't talk to Firebase to get this amazing new emoji feed. The mirror still has those posts. It can continue serving all of this offline data until the database comes back online and it can get new data from it. And it's really easy to set up. From your query, you're querying from a path and it returns to you some data. And I'm putting it here in a private variable. You can tell because it has an underscore at the beginning. And that's our Polymer convention that if it has an underscore, you probably shouldn't muck around with it. And then from my indexed to be mirror, I'm basically going to index it by this query that I made so that I don't stomp over my data. And then I'm going to take this data that I got from Firebase and put it in this little intermediate place where the indexed to be mirror has to massage it. And when it's done massaging it, it produces this post variable. And this is my persisted data. It's the data that I'm going to use in my application. If the Firebase query goes away, this posts will still be populated and will still continue being used even if I refresh my app. You can debug this in the Chrome Dev Tools in the Applications tab, which is the most useful tab for everything. It tells you why your service worker is misbehaving, why your indexed to be mirror is misbehaving. And here on the left, you're going to have a little entry for indexed to be. I guess it is on my left. And what you actually see as the values are all these queries that I've made. Channels is all my private channels. And then there is a list of posts for a particular channel that super confusing name is the key of a channel. And that's my data. And that's my data. And it's hanging out there in the browser. And it gets updated every time you push new data to Firebase, which is pretty great. So now take a step back. I wrote two lines of JavaScript to sign in and sign out. I copy-pasted some elements from other people's demo apps. And I basically have a real app. It has authentication. It has a database. It has a service worker. It has views. I'm doing really good. I can actually make my app now. I can start thinking about how it works. And thinking about how it works is really important. Because I find that if you think about what an app does rather than how it does it, it's actually really easy to reason about it. And you don't get muddled down with features that you don't need to think about yet. And if you think about features, as Ellie mentioned earlier, features translate really well to web components. So think about this. Somehow, we need to authenticate our user. And once we authenticate our user, we can show them something. And that's something that can aggregate a whole bunch of different elements. It can probably give you the option to look at all of the other emoji posts that people have written. And you can write an emoji post, because that's how we get a list. And once you figure this one out, you can look back at each of these individual elements and figure out what they should actually do. Well, when I look at posts, maybe I should be able to interact with them. Maybe I can delete them. Maybe I can like them. And when I'm writing a post, I definitely have to emulate that. So that's going to be a thing that I'm going to have to figure out. But if you want to figure out what your application does, just look at the features that it needs to do. And once you do that, they translate really easily to web components. That authentication bit is probably going to use something like Firebase Auth, because, you know, that's the one element that we know does authentication. The app is probably going to be like this MyApp element that's going to contain a whole bunch of other elements, like new post, where I'm going to bang on, mash on the keyboard. The list of an iron list is going to show my posts and be really fast. And this is great. I have an architecture now. And I still didn't actually have to implement these elements. I just have to think about implementing them. And this was actually my original architecture for the app. But then as the app was growing, this mess that I've highlighted was super messy and it was growing out of control. And it turned out the auth element was poking at the insides of the MyApp element, which is usually like a code smell and you have to take a step back and be like, probably shouldn't be doing this. So then I reworked it. And what ended up happening is that I have one element, the main one, MyApp, and it delegates to two different views. If you're logged in, it will show you the main screen. If you're logged out, it will ask you to log in. And then the main screen again will delegate to elements that it has. And once you think about your application this way, data comes really easily. As Grace said earlier, or I'm just going to paraphrase if you didn't, properties grow down and events go up. Elements at the leaf nodes shouldn't really be poking up on anything above them. They shouldn't be trying to figure out what data other elements are storing. And things at the top shouldn't be really poking directly at functions at elements below it. They should just pass data through data bindings. And it kind of looks like this. If you think about your main screen and your new post, new post lives inside the main screen. The main screen has some information about what the state of the world is. You might know what channel you're looking at and what channel you're trying to post in. The new post doesn't really know that. It's just the main app that does. So we're going to have a property that is going to come from the main app to the new post. And then when you're done mashing on the keyboard and you press the post button, the new post element will say, hey, I got a post. Does anybody care? Anybody care? Then the main app cares and is going to listen to that event and intercept it and do something with it. Similarly, the main app might know that we have suddenly gone offline and we need to hide some UI. And the new post will have a observer to that property and then do something, like hide its post button or something like that.  If your app doesn't really do that and you find that you're calling too many private or public methods, maybe you want to reconsider and take a step back and think about how you can rewrite it to have a good unidirectional data flow. So let's talk about offline because you saw me there responding to this offline property. One of the big things of a PWA is that it needs to work offline. And as much as I love the dinosaur game, if it doesn't work offline, I really want to look at all of my emoji and I really want to look at my entire list of things. So this is why it needs to work offline. And we have a service worker already. So we know that it does that. The application will load and Firebase will serve the right data. But one thing that we want to consider is that you might want to show different UI based on what your actual state is. If you're, it doesn't make sense maybe to show your authentication screen when you're offline because you can't actually authenticate. You need to speak the server. So the way we do this is with, excuse me, the navigator.online API, which basically gives you a Boolean whether you're online or not. It also fires events online and offline, very creatively named. And you can respond to these events and store the value in a property. Once you have it in a property, you can start binding through it. So your UI can magically show and hide based on what the state of your application is. And this is how you would do it. If I have a sign in button for you to authenticate with your provider and you're offline, this button will just magically go away and you can replace it with a nice informational message that, hey, buddy, can't really do anything if you don't have an internet connection, but let me know when you're back. And MojiBrag does that. On the right-hand side, you see a nice yellow sign-in button that lets you connect to Google. But if you're not offline, if you're offline, you get just a message instead. And this UI doesn't actually need any JavaScript. It's just like binding through that offline property. You can also do this for individual elements in your application. So if you've gone offline, that new post goes completely away and any interaction that you can do with the application is sort of frozen. You can still scroll and read things. You just can't post or modify any of those posts. Amazing. So you have an app. It's like the app that we need and we deserve right now. It does everything that we want. We just have to make it fast because nobody really wants to look at a slow app. We already did things as Steve told us to do. We did less. We used an iron list. We didn't use a DOM repeat that had 100 posts in it. We used an iron list. That's an element that's explicitly made to display a really long list and make them really fast. So that's cool. We were also really lazy because we did not import things if we didn't actually need them. And that's where the import href that you also saw in Steve's talk.  This is part of the purple pattern. I have to mention it. It's basically like Polymer Bingo at this point. The problem is that because I don't have a server, I actually just have the ERPL part of purple, which I want to call Ripple and I want to brand it as my own pattern but nobody's going to let me. And the way that I do it is like this. This is my main app. And I'm importing that sign-in view because if you're signed out, there's no point in me doing all the work to assemble that list and the list of channels and the beautiful yellow background and stuff, whatever I have. I have the moji feed element. So if I'm ready to import it, it's there in the DOM. It can eventually get upgraded. But I'm only going to do that if my authentications stay changed. Remember, Firebase fires this callback for me when I finally get a user. And if I do get a user, then I can lazily load that element. And when the callback, the success callback is called, I can start doing things. I can maybe hide the existing splash screen. I can do something to that other element. You can also do this again for little components in your app. One of the things that MojiBrag lets you do is create a channel. You can create a private channel or a public channel, whatever you want. The likelihood of every user that goes to this app on every instance is going to click on that button is incredibly low. And I know this because the app has been live for like four days and people have only created like five channels. So there's no point in me actually loading the DOM to create a new channel. When I press that button, I'm going to go ahead and lazily import that little DOM element. And I can add a spinner because this loading might actually be a little slow. So you can add a spinner while it's loading and then it appears magically. But don't do any work that nobody asks you to do. Again, this is like a life lesson. Don't do any work that nobody has asked you to do. Nobody's gonna care. The way you're gonna test that your app is really awesome is with Lighthouse. Lighthouse is a cool extension, a Chrome extension that tells you how much of a PWA, your PWA actually is. My PWA was an 88, which was neither good nor bad. It was doing some terrible things. But I was pretty proud. 88 is a good grade. It's not amazing, but you're doing okay. And then I talked to Paul Lewis. And here's the thing about talking to Paul Lewis. At no point in your life will Paul Lewis look at your app and be like, you did good, son, you did great. Paul Lewis will look at your app and be like, your app is slow, make it faster. I'm done looking at your app. So he looked at my app and my app on the slowest connection, the slowest 3G connection in, which is in Dulles, took eight seconds to load.  Here it is slightly faster. This one only takes about six seconds to load. The white part, I can't control. It's the time it takes me to download a byte on that connection. The blue part is the time it takes the browser to upgrade my element. I'm literally staring at nothing while this is happening. And then you saw that elements finally started coming in and upgrading. 5.3 seconds is a long time to look at your phone to discover this is a dumb app that just uses emoji. I could have bailed so much earlier on, but I had to wait for 5.3 seconds because I wrote a shitty app that took five seconds to load for me to figure out I didn't want to use it. And we can do better. Fake it till you make it is part of being lazy. So here's the thing about how the parser works. This is like browser parsing 101. The parser is gonna go through your element. Let me actually show you this screen. As I get to the My App tag, and it's gonna be like, I don't know what a My App is. I don't really care. I'm gonna skip it.  So it's gonna start rendering this content that it actually knows. This is like the second it downloaded this byte. And then later on when it gets to the import, because at some point you imported this My App element.  And it's gonna go created here, and it's gonna stamp over everything that it already existed, and it's gonna replace the content. And this is what I mean by fake it till you make it. While the browser is trying to figure out where your custom element actually is, you're still showing some content to the user. After that two seconds that it took me to download the first byte, I can tell the user, buddy, this is a really dumb application about Emoji. If you're not invested in it, you can like go now, it's fine. And this is what EmojiBrag does. This is the loading screen. This is like plain HTML. It's not a custom element. It's just like that local DOM that I had, I threw on the page. And then when My App upgrades, it changes a loading screen with a sign in button. You as a user don't really know that a lot of magic and like a goat sacrifice happened behind.  I know what it's gonna be for.  And the end result is much better. So when I have the change, so two seconds later, I instantly show you a message and then I upgrade and it also got a little bit faster because I deleted some shitty code. But it was still great. Look, we can do it again. Look how nice, it's like with change. Even though you're on the slowest internet connection in America, you're like sweet, I got something super fast, I feel good about myself. Every other website that I visit on this phone takes like eight seconds to load, but EmojiBrag, this like dumb application with Emoji, is four seconds, it's amazing. Fake your content, people. Give, first paint is really important. First paint is really important when your internet is incredibly slow. First paint is really important if you have to work with Paul Lewis, who's gonna bug you about it until your first paint is gonna be really fast.  Make it better. The last thing we have to talk about is internationalization. And it's not because it's like not important that I left it at the end, is that it's so easy that you can leave it till the end. And here's the story about that. The way you make a button in your application is by typing some letters out. I speak English, I put sign out as my sign out button. But imagine that you didn't hard code your string and instead you bound it to the result of this magical localized function that just took a key. And this key can live in a JSON file. In a language, you have a whole bunch of a list of keys and they represent translated messages. So you would have sign out in English be sign out in French would be the connection. In traditional Chinese, it would be that. And all of this works because of an element. It's called app localized behavior. That's what it does is job is to translate stuff for you. It has like two properties, one of them is a language, one of them is a resources file, or is a resources object, sorry. And the way you do that is by calling this.loadResources and you give it a JSON file.  App localized behavior doesn't care. If you're trying to load the same file multiple times, it caches it for you so that it doesn't actually load the same file multiple times. It tries to like do everything for you. And the result is super easy. All you have to do is just replace all of your hard coded text with, you know, these keys and localized function and ask all of your friends with languages they speak and make them translate 25 strings. And the result is this. This is Mojibrag in English. This is a whole bunch of languages. This is Mojibrag in traditional Chinese. And it's so easy and it's so exciting because in the last four days that I've like had this shipped on Twitter, I received three different pull requests for people adding new languages. They were like, sweet, here's German, here's Portuguese, here's Ukrainian. I don't speak any of these languages, but now this app is available sort of because it only translates English, Mojibrag, but it's a different problem. But now this app is available to a whole bunch of users that I wasn't able to access before. Bringing emoji to the people, that is my job. So what did we do? I can tell you what we didn't do and that's write a lot of code because remember, lazy as developer out there didn't want to write any code. I basically just took all these awesome elements that my coworkers wrote, put them together and wrote a little bit of like HTML and CSS and JavaScript just to make it look not terrible. We used a Polymer CLI to start with a basic application that gave us app layout. So our application was really nice and responsive. It gave us a service worker so our application worked offline. We used Polyfire to talk to Firebase. God bless Firebase, my hero. You got easy authentication. You got an easy database, a little bit of work. We thought about our application as being this collection of elements and the way elements talk to each other is by properties go down, events go up.  Repeat this to yourself, your new mantra.  Make your application faster, make your application faster. We just navigated online to figure out if we're online or not and show conditional UI space on that and make our users feel happy and not click on a button that doesn't do anything because you're not connected to the internet. We made our application fast by doing less and using elements that are fast and try to render less dumb. And we were lazy. We didn't import any elements that we didn't actually need. And finally, we localized things. We translated to different languages with app localized behavior, who just does that for you, which also doesn't have a U in the name because I'm Canadian, English people, you appreciate this. I put a U there for you. At work, they forced me to spell behavior without a U and it's incredibly painful. So I thought in my slide, I can finally win this one back. MojiBrag.Firebaseapp.com is where it lives. If you look at this talk or at the repo, it's open source and you make an app of your own, please tweet at us, please show it to us. We're gonna be very excited. I'm Monica, have a lovely evening.