Alright, thanks everybody for making it out. Today we are excited to have Alex Guidemann back from Davidson who will be talking to us about the restricted numerical range of the digraph Laplacian. Thanks Alex, take us away. Thank you so much for having me. Despite the unusual circumstances here, I will warn you this is my first like research presentation that I've done over Zoom. So let me know if I have any technical problems. So first question, can you see my slides right now? I don't have videos up so can someone audibly? Yep, we see them. Alright, so let me know if I run across any technical problems. Alright, so today I'm going to talk about the restricted numerical range of the digraph Laplacian. So I'll explain what all those words mean as we get to them. But I do want to mention that this is collaboration with Thomas Cameron, who was a visitor at Davidson with me last year, but now works at Penn State. And a lot of this is motivated and the first part of this will be content from Michael Robertson's senior thesis that we co-advised, which I'm very happy to say that he got accepted for high honors for. Very exciting work and good work by Michael. Like I motivated this this entire project. So all the all the graphics that I'm going to show you today are coded by Michael here. So the general outline of the talk will be first, I'm going to give you quick definition of what a reminder of what the Laplacian is and kind of my my standards for how I define it and then a defining of the restricted numerical range, as well as the motivation and some properties and kind of some first kind of trivial unsatisfying characterizations, but kind of the natural ones that should be true if this were a good tool. And then I'll go on to the meat of the talk, which is characterizations of digraphs that have singleton or real restricted numerical ranges, such as regular tournament graphs, K and floating stars, and this this notion of three balanced graphs, which which we defined. And then I'll end with a what's next where where do I see this research going and what we're working on currently. So first up the Laplacian and its restricted numerical range. So instead of copying pasting this in front of every theorem of the talk, let this statement be prefixed in front of everything I say, gamma will always be a finite, simple, unwitted digraph, always on in many vertices. And L will always be its Laplacian matrix. So simple meaning no multi edges, no loops in the graph, and only considering unwitted digraphs for these characteristics. The convention we take as the Laplacian is the diagonal matrix minus the adjacency. So the diagonal being the out degrees, everything we do here is directed. So in particular, the eigenvalues of this matrix exist in the right half plane. This is the convention that's that's diff. The alternate convention is to take a minus D, in which case the eigenvalues land the left. We're doing the convention that it's D minus a. So I don't know if there are any graduate students on the call who haven't seen graph plush before. So just a quick example and a quick explanation of how they're constructed. So in the the directed graph case, how do you just define a graph Laplacian? I'm not I'm starting my numbering at zero just in case Jordan multi watches this at some point. Starting at zero, I look at this graph and I say, well, where do the edges outward from zero go? So zero goes to four. And that's the only edge that zero that leads zero. So I go to the zero throw here. And in zero throw, I put a negative one in the fourth position, where this is 01234. One goes out to zero to four and three. So in the one row, I got to the zero position, the fourth position and the third position. And then on the diagonal of this, I put the the sum of the out degrees. So there's one edge leaving zero. So one here, there are three edges leaving one, so three here, and so on and so forth. So in particular, by the Gershgorin matrix theorem or some other similar theorem, the eigenvalues of this thing are going to live in the right half plane, because I'm taking a positive matrix of diagonals, and perturbing it by some small number of off diagonal entries. But for the most part, the values are going to rest near one, three, three, three and one. Alright, so the study of spectral graph theory is is the study of the eigenvalues of these, these matrices, so Laplacian and other related matrices. Beyond just the the eigenvalues themselves, I'm also interested in kind of the structure of the eigenspaces. So the numerical range is a tool analysts use that captures more than just the eigenvalues, it also kind of captures the geometry of the eigenspaces in some sense. So it's defined as all the inner products of x star ax for all complex vectors of length one. So this is kind of like the image of the unit all under this kind of quadratic form here. So there's a lot of research done on how the the image and how the shape of this numerical range kind of reflects the combinatorial structure of the matrix that I plug in here. But we're not talking about just general matrices. We're talking about graph Laplacians in particular. So graph Laplacians, because those rows always sum to zero, always have one particular eigen vector, which is the vector E, the vector of all ones, which will always land at zero, right? So if I take L of E, this gives me every entry of that output vector the row sum in that position. So all the row sums are zero. So this is always going to output zero. So particular zero is always an eigenvalue of the graph Laplacian. And I can kind of see it in this picture here. So this is the numerical range of the graph on the previous page. I can see that star, these stars denote the eigenvalues, this eigenvalue zero lies in the numerical range here. So either is the all ones vector? All ones, correct. Okay. No problem. Yeah. And feel free to stop here to have you have questions. Please do. So because the graph Laplacian always sends e to zero, somehow that that zero in the numerical range is not really important if I'm trying to characterize the structure of the graph. This is something all graphs, all graphs do. So this this zero right here kind of distorts the picture and adds extra noise to it. That's not really necessary. So kind of our idea here is to compute the numerical range, but kind of avoid this vector e. And the way we're going to do that, we're going to define the restricted numerical range is the exact same definition. But instead of plugging in all vectors in my complex space, I'm only going to plug in those vectors that are perpendicular to e. So I'm going to try to avoid that eigen space and avoid that eigenvector. And this kind of cleans up the picture a lot. And just this example. How does this picture reduce it actually turns the restricted numerical range into the triangle that connects these right most eigen values. So actually most of the numerical range, all this like circular part is kind of just extra noise that is not really specific to the structure of the graph. So we can cut that out and get rid of it and kind of look at just the the principal part, so to speak. So this is in retrospect, kind of like the most important motivation for our definition that I can think of is that because all all eigen, all graphs satisfy L of e is zero, we cut that out to kind of ignore this commonality between all graphs and focus only on the differences between them. So that's the motivation in retrospect. But that was not the original motivation. The original motivation for this definition is actually the right connectivity is there's kind of two different competing definitions for algebraic connectivity of a directed graph. This is kind of the one that that motivated this work. So the algebraic connectivity is defined by who is the same inner product, which is reminiscent of the numerical range, except in this, we're only considering real vectors. So not all complex vectors, but only real vectors, and again perpendicular to E and of length one. So the algebraic connectivity would defines as this alpha as the minimum overall vectors. And then there's this related parameter beta, which I don't think has a name to my knowledge. At least we just called it beta. And it's defined as the maximum. And these alpha the betas generalize the algebraic connectivity of undirected graphs, in the sense that a lot of the theorems that Fiedler's definition worked for in the undirected case. This alpha and this beta work for in the directional case. So things like biosection with maximum directed as a parametric number. And as we was specifically interested in rates of network synchronization, and detecting how amenable a graph is to being synchronized, whatever whatever that means. So that's the the definition of who there's a competing definition, which is interesting, which I'll apply some context to later. The other definition is the second smallest real part of the Eigen values. So if I go back to this picture here, here are my Eigen values, the second smallest real one would be the number two. So in this case, the other kind of definition for algebraic connectivity would be this number two. And that's that's more analogous to how Fiedler originally defined it for undirected graphs. It was the second smallest Eigen value. Now because we're directed, we need to make sense of what second smallest means. So we make sense by saying the second smallest real part of all the Eigen values. But that that is different from this alpha and sometimes they agree sometimes they don't. I think alpha is always smaller than the second smallest real part of the Eigen value. But that'll we'll have some context to that here in a second. So this was the original motivation, trying to figure out how we calculate these alpha or a directed graph. So some initial properties. So the first is the numerical range, the restricted numerical range is itself an actual numerical range. So if I define q to be an orthonormal matrix, these columns are all orthogonal to e. And I kind of sandwich L I conjugate L by q transpose q. I compute the numerical range of this in minus one by n minus one matrix. It agrees entirely with the restricted numerical range of L. So this isn't quite too important for this talk, but it's kind of one of the fundamental tools for proving things in the paper is that instead of looking at L in kind of like in by n matrix space, we projected down to n minus one by n minus one matrix space. And this is probably only relevant for for Dr. Angelakis on the call. This orthonormal matrix whose columns are all orthogonal to e is pretty much a direct parallel of the of my dissertation work. Those generalized Gelman matrices. So kind of somehow we're taking the traceless matrices that orthonormal form for that. So it's kind of direct parallel with what we did in my dissertation. This the second property is that it's invariant under reordering the vertices. This better be true if it's going to be worth any salt. It needs to be invariant under ordering so that graph have some morphisms somehow don't mess it up. So that indeed is true. The eigenvalues of L are contained within the restricted numerical range, except for that that zero associated to E. So somehow it it we're not losing the structure as we translate down to the restricted part, we're keeping the eigenvalues true. In fact, more is true that these eigenvalues of L are still the eigenvalues of QTLQ. So we're like keeping the actual eigenvalues themselves. We're not losing structure as we as we restrict them. And then how does all this relate to algebraic connectivity? Well, it relates precisely in the sense that the minimum real part is equal to alpha, and the maximum real part is equal to beta. So even though we only took real vectors and we're taking complex, the minimum real part of ours still agrees with with the minimum over just real vectors. So this was our original motivation was that point forward. So what I want to talk to you today, it's about some of the following pictures. So oops, dismiss. So if we were to look at these three graphs, kind of as a set here, and look at just the spectrum, and ask which of these have similar structure, or I guess which two are more like instructor, or to look only at the eigenvalues only at these red stars, perhaps I'd say the bottom two are the most similar. Because they both have, I mean, I can value zero on two, I can value zero on three, perhaps ignoring multiplicity, I'd say these two are most similar because there's two eigenvalues, whereas the third, the top one has three. If I were to say, okay, well, let's look at not only the eigenvalues, but also the structure of the eigenspaces, ie look at the numerical range, I still might say the bottom two are more similar, in that their numerical ranges are ellipses, whereas the top is more of this baseball diamond looking thing. What I hope to convince you in this talk is that the restricted numerical range provides a more robust description of what's actually going on between the two. And in fact, the top two are more similar than the bottom, in that their restricted numerical ranges give me a real line. Whereas the bottom one gives me just a singleton point. And that one that gives me a singleton point is actually very, very special, and has a very completely characterized structure. Whereas the top two don't necessarily have a characterized structure, or I guess I shouldn't say that they have a characterized structure, but I can't necessarily name the exact graph. So I can tell you what the structure of the graph is, but maybe not named the exact graph. And that'll make sense when I get to the actual characterizations. But all three of these also share similarities in that the restricted numerical range is completely real. So there's some underlying structure that all three of them share together that make sure this restricted numerical range is real. We can contrast the pictures like this, where the restricted numerical range becomes, say a polygon or a vertical line. And we'll talk about that toward the end of the talk when I'm talking about what kind of the future work is. And then just so I don't accidentally convince you otherwise, I don't want to convince you that restricted numerical ranges are always very nice pictures. Sometimes you also get nastier things like this, where the restricted numerical range is not a polygon at all, but has some curvature in it. So and sometimes the restriction numerical range and the numerical range don't even change, especially if the graph is disconnected, won't even change when I when I do the computation. This the second picture is also important. I want to clue us in whenever I take the restricted numerical range, I drop the zero eigenvalue, it is very possible. And indeed, often the case that when I when I take out the zero eigenvalue, I'm not just making a straight line, not a polygon between the eigenvalues. And perhaps there's a curved part that that drops this alpha this minimum real part below the minimum real part of the second smallest eigenvalues. So here this graph right here is an example of where the second smallest real part of the eigenvalues is strictly larger than that algebraic connectivity alpha that this has a curvature to it that drops that that left part down. So try to hold this little picture right here in your mind for about three more slides. I'm going to recall it here in a little bit. So first characterizations are kind of the ones we expect. So just a quick remark, the empty and complete digraphs are fully characterized by their Laplacian spectrum, if we include multiplicities here. The spectrum of the empty graph is just zero multiplicity in. And the spectrum of the complete graph is zero. And then in multiplicity in minus one, so not too difficult to see that. And as an immediate corollary of that, well, sort of immediate corollary of that. The restricted numerical range clearly characterizes these as well, where the restriction numerical range is the point zero, if and only if it's empty. And it's the point in, if and only if it's complete. So really the only thing that needs to be shown in these proofs is that the numerical range or the restriction numerical range don't really have like, maybe a circle around this point, there's no noise to mess it up. But the eigenspaces of these two graphs are very well behaved. So I'm not going to have any of that noise to mess up these pictures. So that's kind of the first characterization that's, I know it's satisfying in the sense that I would hope it to be true and it is true, but it's not very satisfying in the sense because it's kind of like, okay, well, obviously, that should be true. A more satisfying example, a more satisfying characterization following. So first, we proved that a directed cycle is characterized by its Laplacian spectrum. So if I have a spectrum which is exactly one minus these roots of unity, that happens if and only if I'm a directed cycle on those inverses. So one direction of this is really obvious. If I have a directed cycle already, using standard, just matrix theory for cyclic matrices, you can find the eigenvalues of it directly to be these roots of unity. What's more complicated is the other direction. If you assume you have these as the eigenvalues going backwards to show that it's a directed cycle, takes a little bit of elbow grease, you have to first prove that it's, well, the way we did it, we proved that it was first regular. And then from regularity, it follows pretty immediately that it has to be a cycle. But that took a little bit of elbow grease and a contradiction for that. And then from from this characterization on the spectrum, we get the following characterization on the restricted numerical range, and indeed also the numerical range itself, which I don't have written here, but there's a picture. So a graph is a directed cycle, if and only if it's restriction numerical range is a polygon with these vertices. And actually that happens if and only if the numerical range is a polygon with these vertices plus zero. So here's a cycle on five vertices, it's written in this kind of non standard way because the computer generated it. But here's a cycle on five vertices. And it's kind of very pleasing to me that the numerical range is also kind of a cycle on five vertices. It's exactly this Pentagon. And then if I cut out zero, it's still a polygon on these four vertices that have exactly these coordinates for their their points. So again, the characterization in one direction of this is pretty immediate. If I have a directed cycle, I know it's eigenvalues. I also know that this matrix is normal. And as a normal matrix, it's numerical range is guaranteed to be the convex hull of its eigenvalues. So immediately I have this picture, I know it's the convex hull of its eigenvalues because it's normal. But what I don't know is that when I restrict it, I don't get that that curve right here. So remember on the previous slide, I said, hold that picture in your mind, it's possible to have a curve between these two points. But what's preventing that is the following lemma, that if L is normal, then I'm guaranteed to have a convex polygon as the output for the restricted numerical range. So if I have a normal graph, it's it's restriction numerical range is always going to be a convex polygon. I'm not going to have that that curvature in here. So a nice corollary of that is that if L is normal, then it's algebraic connectivity, and its second smallest real part eigenvalue will agree because it's just going to be either a straight line here, or or a vertex like this. So that was the only difficulty in this direction of the proof, more satisfying, but still kind of the I would say kind of obvious example, because we know exactly the eigenvalues of this. So now, now I want to get into kind of the the meat of the talk. Oh, before that, here's here's a nice corollary, just relying relating all this to the alpha and beta values. So as suspected, the empty secret digraph has algebraic connectivity zero. And also this beta value zero complete has alpha beta in and directed cycle has alpha and beta given by these values. So one great advantage of using the restricted numerical range was kind of how easy it was to prove, especially this third point here. We'll also proved these formula in a different form. His had bunches of signs and and cosines in it. So I presume maybe use some for your analysis or something like that to actually prove this formula. But ours we get directly from the eigenvalue using a relatively straightforward way. So kind of an easier way to prove at least this third point. Alright, now the actual meat of the talk, the the characterizations. So as we saw the empty graph and the complete graph has singleton restricted numerical ranges. The question I want to ask now is what other graphs have singleton numerical ranges? So the first theorem is if it's a singleton, it must indeed be an integer. And that integer has to be between zero and one. So the fact it's between zero and one is not too surprising. These are kind of like natural eigenvalue bounds. But it has to actually be an integer. I can't have non integer singleton numerical range. So I go through a proof here, which has a lot of details I'm skipping. But the reason I'm going through this proof is because something very unexpected pops out of it that I want to claim as another theorem afterward. So let me go through the details of well, let me go through this proof skipping the details to see kind of some unexpected thing that falls out. So if K is an integer, it's relatively straightforward. So the sorry, I'm skipping ahead of myself in the talk. I'm trying to prove as an integer here. Ignore that suppose it's not, we're going to try to get a contradiction. So because numerical range is a singleton point, both alpha and beta are equal to that K value. Now this alpha is the algebraic connectivity. And it introduces itself in some lower bounds on how connected a vertex must be like alpha is a measure of I need at least this much connectivity at every vertex. Beta on the other hand is a maximum. It tells me at most how connected each vertex can be in some in some complicated inequalities. But what happens within these inequalities, if they're equal, it needs to be bounded by below by at least in some amount and above by at least some amount. These inequalities become very tight. In fact, they become equality. I get exactly this expression that the out degree of every vertex has to be K minus the n degree over n minus one. So the details of this aren't too important. Other than the fact that if I look at it, K is not an integer. The out degree is an integer. And this fraction is less than one. So K is not an integer. The degree is an integer. And this fraction is less than one. So from that, if follows, that the out degree is actually the floor of K. I'm taking I'm taking the out degree, adding something less than one and getting K. Well, then that must mean that the out degree is the floor of K. And this holds for every vertex. So every vertex has the same out degree and that out degree is the floor of K. So if I were to write my graph Laplacian, all the out degrees are the floor of K. So my Laplacian has all floor of K on the diagonal minus whatever the off diagonals are. And then I can introduce the restricted numerical range by computing these inner products at a very specific set of vectors. So the vectors I'll choose are one over root two in the I spot, negative one over root two in the J spot. So this guarantees their perpendicular to E a division by root two just means that it's length one. So K is in the numerical range. This inner product is in the numerical range and the numerical range is only K. And then I just do a direct computation of the form and I get this equality. And this is where something really unexpected falls out. So I've got integer. Sorry, I've got non integer equals integer minus fraction. So I've got non integer equals integer minus fraction. So if this fraction had a i j equal a j i equals zero, in other words, this fraction wasn't here. I'd have integer equal non integer contradiction. So they can't both be zero. If I'm on their hand, they were both one, then this would be one plus one over two. So that's minus one. So I'd have non integer equals integer minus one. That's again, contradiction. So what's following from this equation is the fact that either a i j is one and a j i is zero, or vice versa. So either there's an edge from i to j, or there's a j edge from j to i. But I can't have both edges and I can't have neither edges. So in other words, I must have a regular tournament graph. So regularity comes from the fact that all the degrees are the same. And the tournament graph means either i to j or j to i for all pairs of pairs. So from this, this assumption that alpha equals beta, and then some inequalities of Wu, and then some, I don't know, clever choice of vector here, you get that it has to be a tournament graph. Just definitely some details I skipped here. But the coolest kind of tourism of this proof is that if I had a regular tournament diagram, that happens if and only if the numerical range is a vertical line segment. So this is where alpha equals beta. And in fact, some details that I omitted, the real parts equal to n over two and then has to be all. So kind of an unexpected thing that fell out of this proof was a characterization of regular tournament diagrams. So if I computed the numerical range of this thing, and I saw it's in a vertical line, then I know that everywhere in this this graph, every edge is present, it's a complete kind of complete graph, where every edge is directed in only one way. And moreover, it's regular. So if this thing has two going out of it, it also has two going into it. So nice characterization of regular tournament graphs. And now the question is, okay, what if it was an integer? So this is not an integer. What if it was an integer? So what if I had a singleton integer restricted numerical range? For that, we introduce a new definition. As far as we can tell, just the analog of a join, but in the case. So a directed join between digraphs, we define as the union of the verdict vertex and edge sets. And then we also join in the sense that from i to j. So for every i in the initial, in every j in the final, I also add that edge. So here's some examples where the white is the gamma, and the gray is the gamma prime. So here I'm taking an empty graph on five vertices, and I'm joining that onto a single vertex six. Here I'm taking the empty graph on four vertices, and joining that onto the complete graph on two. Here I'm taking the square, this bidirectional square, and joining it onto the complete graph on two. And then a special kind of directed joint. So this is directed joint in general. But a special kind of directed joint is what we're calling the K imploding star. So the K imploding star is when I take the empty graph on n minus k vertices, and directly join that onto the complete graph on k. So for example, this is a one imploding star, I'm taking the empty graph on five, and it imploding onto six, the complete graph on one. This is a two imploding star, I'm taking the empty on four, imploding on the complete on two. And this is not, this is a directed joint, but it is not a K imploding star. So I've got a one imploding star, a two imploding star, and a non example. And this definition of K imploding star is precisely the graphs that have singleton numerical range. I almost said that it's integer, but if it's a singleton numerical range, it has to be integer. So these are precisely the graphs that have singleton numerical range. And their numerical range is the K that is involved. So if I look at this graph, a computer's restricted numerical range, I get the number three out and just the number three. I know it's a three imploding star. And I can kind of see that in the picture here. Zero, two and three, it's kind of the heart of the star, that's the complete K three. And one and four are imploding onto that star. And this is one of the nicer characterizations we have, precisely because of the following reason that these are not characterized either Laplacian spectrum, Northern numerical range. So if I look at these two graphs, and I can compute their Laplacian spectrum, they have identical spectrum, including multiplicity, they have the same multiplicity. So they have identical Laplacian spectrum, they have identical numerical range, but only this left one will have a singleton restricted numerical range. This right one will not, it'll have some noise around it, so to speak. It'll have more of a circular picture. But I wish I had a picture here. I'll add that to my slides later. So this is kind of the first punchline. This restricted numerical range. It provides new techniques to characterize more graphs that this just the spectrum or just the numerical range, do not provide. And to relate this all back to alpha and beta, we have the following corollary, alpha and beta are the same, only for if and only if for K imploding stars in regular tournaments. And in fact, it's a K imploding star if only if alpha and beta are integers between one and in, and it's regular tournament if only if it's in is odd, and they're equal to in over two. And this mesh as well with the empty and complete pictures. So a zero imploding star is the empty graph, because I have zero kind of core of the star, and an empty graph imploding onto that. But there's nothing there to implode on. So it's still the empty graph. And in the imploding star is the complete graph. The heart of the star is still all invertecies, and nothing implodes onto it. So so kind of the vacuous zero and end end points still fit well into that definition there. So that section dealt with singletons and kind of unsurprisingly gave us vertical lines out. The last thing to deal with for this talk, at least are the real restricted lane numerical ranges. So horizontal lines. So the section's a little shorter. So the definition that we introduced to kind of describe these graphs, we began with three balanced. I don't know now in retrospect, if that's the best name, but it's the name that's already published paper. So I guess we have to stick with it. So we call a graph three balanced. If for any three vertices, the following equation is true. So in other words, if I look at the weight, the ij plus jk plus ki, that gives me the same as reading it backwards, i k, kj, j i. So it's kind of easier to see in the picture here. I pick three vertices, say two, three and six. And I sum the weights of the edges as I go around that triangle. So if I go from two to three, that's plus one, three to six, that's plus one, six to two, that's zero. There's no edge there. So going around this way in the triangle, I get two. That's going to be the same as if I traverse the triangle backwards. So two to six, I get plus one, six to three, plus zero, three to two, plus one. So going around this way is two as well. So pick any three points, going around the triangle one way gives the same total as going around the other way. So actually all three graphs here, these directed joins are all three balanced. So again, the directed joins here are the whites joined onto the gray. So maybe another quick example, one five and six, if I go one to five, five to six, six to one, I get two. And if I go backwards, I get two as well. And it also works for this time, like two to one, one, three, three to two, I get zero, but I also get zero the other way. So this is what we call three balanced. And there's a reason I have directed joins here, and that'll be more clear in a second. So the theorem is that the numerical range is real. So it's a real line, if and only if the graph is three valid, kind of a quick idea of the proof how did this come about. So these points in the numerical range for perpendicular e are going to be real, perpendicular to e are going to be real, if and only if they're going to be real on a basis. So it's kind of natural, you want to check this to be true for all points. So instead check it's true for all points in a basis. The trick here is showing that the basis actually extends that if it's true on the basis, it will be true everywhere. And kind of this quadratic form, it's a little tedious. But it turns out to be true just requires a lot of coefficients and and summations to show it. But that's the gist of it is it's going to be real, if and only if it's real on a basis. And then the part where three balance pops out is just choosing a specific basis. So the specific basis we choose is to fix k and define the basis as E i minus E k. And really, I should put this over root two to make them length one in the next calculation. This should be over root two. But it's again those vectors one in the i spot negative one in the k spot. So these are perpendicular to e. And it's easy to see that they're they're spanning them up in the entire e perp space. And then I just evaluate this equality on the basis. And I get this condition, which after a quick rewrite is exactly the three balanced condition. So I put this here, just kind of get an idea of how we're proving things with the restricted numerical range is often case just choosing a clever basis to get the properties we want to kind of fall out of it. But three balanced isn't necessarily the nicest thing to do that be hard to look at a graph and say is it three balanced or not? But luckily, we have another characterization. The graph is going to be three balanced, if and only if it's the directed join of two i directional digraphs. So if I take two graphs that only have bi directional edges, in other words, if I goes to J, then J also goes to I. So all arrows are multi bi directional. The directed joint of those two will be three balanced. And that's actually if and only if. So correlated that numerical range is real, if and only if it's a directed joint of two bi directional. So looking at these pictures, it might be hard to kind of figure out what's joining on to what. But I think here 123 is in is joining on to zero and four. So 123 is this complete triangle. And all those are joining on to zero four. Here 123 is my bi directional graph. It doesn't have to be connected. One is I got a just an edge and a disjoint one. But all three of these form the first graph is joining on to k to the second graph. So that's our if and only characterization of real lines. So this kind of leads into the question of what's next. So thus far, what we've done is show that they're restricted numerical range is a pretty robust tool to characterize digraphs. And indeed, it can characterize some some things that are not characterized by just the spectrum, including multiplicity. And specifically, what we've done so far in this first paper is characterize degenerate complex polygons. So things that are single points, things that are horizontal lines, and things that are vertical lines. So that influence ours directed joints of bi directional and regular tournaments. So those are kind of our three degenerate polygons for restricted numerical range. This leads into the natural next question. So in the sequel, which we're working on now, we investigate the next question, which digraphs have non degenerate complex I were to compute the restricted numerical range, which of those have polygons, that they don't have this kind of nasty curvature that may make that alpha algebraic connectivity strictly smaller than the second smallest real part I can value the two different definitions of algebraic connectivity. And we have pretty much I'm convinced we have all characterizations done, we have sufficient proofs for everything. And the necessary proofs I can say so far is after hundreds of hours computing and running trying to find non examples on the computer, the computer can't find any. So we have sufficient proofs in one direction. And I'm fairly convinced that they're also necessary proofs. But we're still working on the necessary direction for most of these. Actually, for most of these, I should say, in some of them, we also have the necessary condition for a lot of random extra assumptions. So for example, we have the necessary conditions, if the number of vertices is prime, or more generally, if the number of vertices is square free. So like these things lead me to believe that it's necessary always, because these structures really shouldn't depend on the number of vertices in general, right? Having a directed join between two things doesn't really seem like it should depend on, well, do I have seven vertices or eight? So I'm kind of convinced they're necessary, we're just still this leads us to asking the next few questions, which we hope to work on in the current and in future papers, which digraphs have negative algebraic connectivity. So it's possible that that alpha value was zero, if you're not a polygon, it's possible that zero eigenvalue happens here, maybe it has multiple, multiple multiplicity. So when you take the restricted that zero still appears, and there's some curve some noise cut out around it, that forces that restricted numerical range into the left hand plane. So it's perfectly possible to have a negative algebraic connectivity, which has some consequences when talking about, say network dynamics or something like that. A really interesting question to me is, are all digraphs that are characterized by the Laplacian spectrum also characterized by the restricted numerical range? So is this restricted numerical range truly a more robust way to characterize things? Does this this idea about say the K imploding stars being characterized by one and not others? Does that have a converse with something being characterized by the spectrum but not to restrict to numerical range? We guess the answer is no, but it would be nice to have a proof of that. And then the final thing is, how does this all relate to network synchronization? So who kind of his original motivation for the algebraic connectivity was to describe the synchronization of algorithms on on networks. So what does alpha value actually means? So there's this alpha value, this beta value, a related mu value. There's all these different values that kind of tie into convergence rates and such on networks. How does all this, this, this nuance about the restricted numerical range, when it's polygon, when it's not tie into all of that. So that that would be some some future work after this current paper. And with that, I'll say thank you for your attention. Hopefully I didn't talk too fast. Thanks, Alex. If we could all thank our speaker, then we'll open it up for any questions. Yes, I have a question. So do you know anything about what the restricted numerical ranges, maybe, yeah, numerical range for a random diagram? So randomly, if I were to just compute random things, more often than not, it will not be even a polygon. It will some strange shape. So these these polygons we're finding are very specific structure, which may or may not be. So I'm still trying to convince myself that in a network that represents kind of a real life thing, maybe like, one of the assumptions physicists often make are matrices are all formation. But if you take a random matrices, it's definitely not going to be formation. It would be nice if all networks that are constructed fall into the category of being polygon, for example, because it would be really nice if that alpha value oftentimes agrees with the smallest real part of the spectrum. Because that has a lot of consequences, they describe subtle, subtle differences in like convergence rates and such of real life works. So it would be nice if the structure was overarching enough to be consistent with real life examples. But mathematically, speaking, if you take a random thing, it's most likely going to be one of these, one of the first kind of pictures, where it's kind of one of these like guitar pick looking things. Probably I'm asking because I don't know if you know that there's this whole class of open questions about is it true that with high probability, a random graph is characterized by its spectrum? I think this is open for I know it's open for adjacency, I think it's open for Laplacian. And it says, I wonder, of course, like, does this numerical range business characterize most graphs? Or if you know anything about that? My gut feeling is that if it's true, the spectrum, it will be true for the numerical range. More likely to be true for the numerical range than it is the spectrum. But my guess is that they're both still open. I don't know how often the numerical range itself is employed in graph theory. I've seen several papers in a disjoint but I don't know if I've seen it for characterizations, at least in the survey papers I've read. And definitely the restricted numerical range should be more robust than that. Even this example in here, it characterized where the numerical range did not. That would be an amazing thing to show. Thank you, Alex, for the talk. I wanted to ask you, this reference of who, when was that done? That was 2005, I believe. I see. So that is when the definition of algebraic connectivity was formed? For directed graphs, yeah. For directed graphs, okay. For that definition, yeah. There's also the concept of the second smallest real part. I'm not sure when that one was formed. That one's kind of the more natural extension but perhaps doesn't have the nice properties you'd wanted to have. Thank you. It was nice seeing you. Do we have any other questions for our speaker? Okay, in that case, thanks everybody for coming. Thanks again, Alex. And have a good day, everybody. See you all around. Thank you.


Going everyone Caleb here with late and sports cards next up box number 54 of these sports card Almanac for Julian H Let's get it going. Thanks so much No idea Rob, it was early. Yeah, no idea. Sorry if it was recent. I probably at least have an idea Yeah, it was really early. Yeah China remember No, like crazy 69 or 42 though or anything like that Here we go. Thanks again Julian Those are always giving the first choices we're on a run of bowman right now First bowman blue wave auto Carson Williams. You go number to 150 rays Nice one there Congrats on that Julian H. Not too bad if you bowman hits in a row. Thanks again, man. Appreciate it J. Julian


Hello people, I'm Ginny Metherill and I'm a fourth-generation witch and today I'm going to look at something a slightly different I have done several readings recently for my clients with these kippa cards, the old-fashioned 1700s divination cards and so it seemed a good opportunity to get them out and give my watchers and subscribers a reading. As you can see they're individual events so sad news and occupation, the good Lord and I normally pick three cards for a reading so let's try and find them. The way I choose as I hold the question in my mind what is going to happen from the majority of my YouTubers and then I'll choose the cards accordingly. I spread them out and then I try and feel what is hot beneath my palm and here I can feel one this one or Sometimes I feel them hot beneath my fingertips, but it's just where the palm or my fingers suddenly change in temperature And that's how I choose my cards. However, other people choose them in many different ways So we've got a journey, a meeting and the main female And I would like to sit with my cards for a while, but in this case I think the main female is you. This points to the watcher. This is your card and represents you. Next up we have a journey. Journeys don't necessarily mean a physical journey And third we've got the meeting. I don't think this is the right way round actually I think we need to move them into this order So we have a main female you and this meeting is the meeting between you and me It's a meeting of minds this and the journey is the journey of discovery That you will go on through this meeting of minds This obviously is only half the story, so I need to choose a few more and again I'm going to say what is the outcome of this journey And holding that thought let's choose my three cards and again I'm using the same technique of wherever the temperature just feels different under my fingers palm and in this case hot and these are the home Lots of money always a lovely card to see and a marriage So my thoughts about it are as follows I think the first code we need to look at is the marriage This is not necessarily a romantic marriage But a partnership and it can be a partnership of minds a partnership of education a partnership of thought And so you are going to come into some form of partnership This is going to be done from the pleasure of your own home And if you put your mind to it bring you a lot of money Come and join me and we can explore this together


It's a long walk. Good morning. As Hannah informed you, my name is Libby Barker. I'm a senior project manager at Human Made. And I'm Mike Sealander. I'm a senior engineer at Human Made. And incidentally, Mike and I met for the first time at WordCamp Europe in Vienna two years ago. So we're really excited to be back for this presentation. So thanks to you all for being here. Over the next 30 minutes or so, Mike and I are going to be sharing with you an experience of a project that we recently delivered, which was a collaboration with Tech Crunch to build a decoupled WordPress application with a React front-end. This seems to be, may I use yours? Thank you. So over the course of our talk here, we're going to touch on a few key aspects of the project. First, we're going to do a little bit of an introduction about the partners who are involved. We're going to talk at a high level about the business opportunity that Tech Crunch had and why our approach, which we'll then follow that with, was specifically chosen for this project. We're then going to look at some of the features that we built out specifically for Tech Crunch to meet those business needs and to work within the context of the architecture that we determined as a team. And then finally, we're going to be sharing with you some of the technical solutions and open-source libraries that we've developed as a result of this project. So to get started, let's look at who all was involved. HumeMade's relationship with Tech Crunch actually also began in 2016 when Nicole Wilkie, Tech Crunch's head of product, approached us with an exciting redesign opportunity that they wanted to pursue. For those of you or anyone who is unfamiliar with Tech Crunch, they are a leading publisher of startup and venture capital news based in Silicon Valley. And not only are they reporting on this space, but they're important influencers in it as well. They run a series of events. The flagship one is called The Swrupt that are held all over the world. And they are an important opportunity for startups that are already established or just starting out to create networks and identify funding opportunities. Tech Crunch has been a longstanding user of WordPress. And actually to that end, they're hosted on WordPress VIP, which is a great hosting solution for enterprise clients that need to be able to host at scale. For this particular project, Tech Crunch wanted to do something that would be innovative, cutting edge. They loved their work with WordPress, felt it was the foundation of their editorial workflow and the product that was supporting their business. But they wanted to do something that was going to really embody that philosophy of innovation that's such a core part of their mission. So we're obviously very excited to get involved in anything innovative and cutting edge. So we were eager to get started. When we begin any project, it's important for us not just to come in with a technical understanding, but a business understanding of our clients' needs as well. We want to, at the end of a project, deliver something that's not just a great code base, but something that's going to embrace longevity and help our clients to pivot and grow as their markets change. So as senior PM, I was brought in pretty early to work through these with Nicole. And we wanted to just touch on a few of them to hopefully help clarify some of the choices that we would make later. So in Nicole's own words, TechCrunch wanted this redesign to be ambitious. As we touched on at the beginning, for this project, they chose to pursue a decoupled WordPress application. TechCrunch wanted to leverage the inclusion of the WordPress REST API into core to use this as a platform for exploring WordPress as a foundation with JavaScript front end. This would do two things. It would allow them to continue using the CMS that they felt most comfortable with, and that was that foundation of their product. But it would also give them the flexibility through the JavaScript front end of being able to pivot and incorporate new features in a quickly changing environment, such as venture capital. It also was a great opportunity for us in collaboration with TechCrunch and their development team to look at how we could refactor their existing code base, which had grown over the years, to best support this type of product and create a really lean, powerful solution. For any publication considering a redesign, or really any product considering a redesign, considering how you will improve user engagement through your changes is one of the most critical questions. To accomplish this, TechCrunch worked with a design agency called Work&Co to deliver a design that was focused on fluid interactions that would apply well over a JavaScript front end. The hope was that this approach would embrace a native app experience that would deliver to the end readers a continuous flow of content, a really immersive reading experience that would keep them on the site longer. And while, of course, the end user is the one who's seeing the final product, user engagement of the people building and delivering the product to the end user are just as important. So as part of our reconsideration of how the CMS would be used in relation to this approach, we wanted to take an opportunity to also think about how this would impact the editorial team as well as the other business teams operating on the product as well. So with that approach in mind, it was time for our team to really dig into the technical approach that we were going to pursue with this project. And to speak to that, I'm actually past the conversation to Mike. Thanks. So as Libby mentioned, the client wanted something that was extremely interactive, extremely engaging, and they wanted this website to feel like it was a mobile application, even if you were on your desktop. So basically, they wanted the user to never feel like they had left the website, even if they're doing full page navigations. So for example, you're popping in and out of an article. They don't want the whole site to disappear as you're transitioning between those pages. They want everything to feel fluid. They want to be able to replace small parts of the component, small parts of the application in time as we're going. So we knew from the get-go that we wouldn't be able to use a typical traditional WordPress templating approach. So there's just too much page transitions. There's too much jank. There's too much going on between those pages, and you're really pulled out of that experience. It doesn't feel fluid. It doesn't feel like you're a part of the application the whole time. So we wanted to go with a JavaScript framework to handle the front end of the website. And at this point, it should be unsurprising that we use React.js for this. React.js is a JavaScript library that is built specifically to create engaging and interactive UIs. So it's a component-based model that allows us to swap out small parts of an application really fast, really performantly, and the user sees almost no transition in most cases. So it gives us a lot of power and a lot of flexibility on the front end. Now, WordPress is still a first-class citizen in this architecture. It still handles all of the administrative side. We're still handling all the data through it. Editorial sees it. We're still using the REST API and such, because TechCrunch had used WordPress for almost 10 years. So it was always going to be a really strong part of this. However, when you're building a React or View or Angular application on top of WordPress, usually what you would go with is a fully decoupled or headless approach. And what this means is that WordPress is stored on one stack, or it's served up from one stack. So you have PHP and Apache. That's all served on separate servers. And then React or View or another, your front end of the site would be served on a completely different stack. And they only talk to each other over the REST API. And this architecture has a lot of benefits. But for us, we wanted to go with a slightly different approach.  And what this means at the base, at its core, is that WordPress still handles some of the templating.  But we're using WordPress to preload and hydrate some of this data and preload some of the templates so that the user sees something almost instantly. And we have a lot of advantages in the simplicity of the stack, because everything is served from the same servers. So our React bundle is served from the same servers that WordPress is handled on. We're not having to deal with and handle a completely different stack to serve that up. So to give you an example of what this looks like in practice, because all this series is great, but you kind of want to actually see how this works, this is what you would see if you went to techcrunch.com today without JavaScript enabled in your browser, or if your browser is just really slow, like if it's really throttled. And this is a very Spartan, simplistic view of the website. All we have here is a couple of posts. You can actually click through all of this so it's fully navigable, you can use it like you would a normal website. But it's very simple, it's very Spartan. And this is all served using WordPress templating. So we haven't gotten to React, we haven't gotten any JavaScript at this point. And this has two advantages, this really simple view here. The first is that we're not duplicating too much effort in recreating what we've created in React and all the templating and the views in JSX on that side. So we're not duplicating that too much in WordPress templates, so there's low duplication of effort. But even more importantly, this very small return allows us to get this to the user almost instantly. This is very aggressively page cached and VIP does an excellent job of serving this out via their edge nodes and they have a CDN to serve this out very quickly. So as a user, you're gonna see this view almost instantly, so the perceived performance of this page is going to be very, very quick even if it's not the full experience. And while this is loading, while WordPress is serving this, it's also giving React a little bit of time to load in the background. Because our React bundle ended up being really big, this is a very complex website with a lot of components in it. So we're serving almost 300 kilobytes just for the React bundle and the routing and the componentry and such. And that can take one to two seconds to load. And when that actually loads up, what you get is a view similar to this. Now you have all these extra things on here, you have navigation, you have a feature island and you have advertisements and these extra pieces that you get with any functional website. What's important to note here is that this view here, this river, the posts, is almost identical to the view that we had before. So as a user, this feels like React is progressively loading up more into the website, even though it's actually going in and wiping out everything that WordPress has handled. So it feels very smooth, it feels very fluid and from this point on, React handles all of the routing, all of the animations, the transitions, all the content and it only goes through the REST API to get what it needs. So to look at this architecture a little bit again, just a tiny bit closer, we have WordPress and this serves as a base of our application. It's hosted on WordPress VIP and that serves data into React. We hydrate or preload some data in there when we handle all these templates or when we're loading up the page. And then React takes over and as long as you stay in that tab in your browser even though you're navigating through several pages, React is the only part of this application that you see from now on and that's where it becomes effectively decoupled because it only goes through the REST API for the rest of its data. We also use Redux for our state management and React Router for our animation routing needs and then we also use Webpack to build it.  Thanks. Right, so once the architecture was in place and this is the key delivery for the first part of the project or deliverable, I should say, it was time for us to start considering the kind of features we were going to build out for TechCrunch in this environment to make sure we were meeting those business goals that we talked about earlier. The first one I wanna talk about is the River experience which I'll get to in a moment but is that kind of core reading experience for anyone landing on this site. And this is the experience that is the underpinning of that native app experience that TechCrunch wanted to create. As Mike mentioned, in order to do this, the experience needed to be consistent across the site, needed to make the user feel that they were never off a single page. So the River is termed such as the idea that when a reader enters TechCrunch.com, they should feel that they're immersed in a current of content or a river of content and they're being propelled very fluidly from one piece of content to the next. I'm just gonna demonstrate what this looks like here. So you scroll through, this is the home page, driving the user through all the latest posts but as you'll notice, we click into startups which is a section page, that experience is exactly the same. Only it's targeted to readers who wanna know specifically about startups and funding or in this case, for a topic page, readers who wanna know about the WWDC last week. This information is all targeted but the experience is consistent regardless of where you are on the site. This kind of continuous flow of content and consistency so heavily rooted as part of the experience also led to some other considerations that we needed to take as a development team. The first was how we would develop wayfinding for readers. While it's great for them to be in this river of content, they also needed some ways to navigate it. So there are a couple of little details that I just wanted to point out as part of this experience. I'm entering a single article here and at the top right, it's a little subtle but you can see the progress indicator demonstrating exactly where you are on the read. The check mark, a subtle change of background which may be too late to see before the article snaps shut. I actually wanna just point out that snapping shut behavior because it is, again, very understated but it's actually really important in terms of the reading experience. You'll notice when the article closed it actually dropped me right back to where I was before. Right back in the river, at the top of the content that I haven't yet read. There's a change in the title color, it's grayed out, kind of encouraging me onto the next piece which I have now a clear indication that I haven't read but that maybe I should. There's also posts of interesting challenges for the editorial team as well. For editorial teams working within very specific strategies, they need ways to distinguish content. Whether it's featured stories or sponsored posts, how can they differentiate or highlight certain pieces? One example that I wanted to, where we wanted to talk about, is developing stories. Developing stories was very interesting. It was unique to the redesign, actually. It had not existed as a feature before the redesign and it was an opportunity for the editorial team to really leverage the river experience and the native app experience of the new product to better tell a story, a more engaging story for the reader. So I'm just gonna pull up another little video here. The idea behind developing stories is that TechCrunch's editorial team is remote. They're not working in the same office or co-located though. But they found they were often reporting on stories about the same topic across a number of days or weeks, but they're all referring to the same subject. So using that river continuous flow of content experience to guide them, we came up with a solution to help them target these stories to readers more effectively. The developing story groups related but autonomous articles under a single heading and a teaser text on the homepage. And as an administrator or an editor, when you go and create new posts, you can very easily assign these to this group or unassign them as you need. Play a little video. So as I click into the story here, you'll notice, again, that river experience is persistent. The articles are in reverse chronological order. So for someone who's dying to know about the electric scooter saga in San Francisco, they can turn to their trusted reporter, TechCrunch, for the latest information that's always up to date. Even go back further, learn the genesis of this problem. However, you also have the ability to enter a story individually. And the story retains its autonomy. This was an important piece to get right because TechCrunch generates a lot of brand loyalty through their social presence. In order for users to share stories within a developing story, they needed this individuality of the story to create entry points for other people through social networks to enjoy the content as well. So when we're talking about user engagement, it's kind of impossible to have that conversation without also talking about ads and analytics. Ads are obviously an important revenue stream for any product. But we couldn't deliver this in the way that we would have done with a traditional WordPress website. We faced a couple of constraints as a result of the architecture and business needs of this project. The first is that React is not compatible with that traditional method of delivering ads. So we needed to find a solution for how we would approach that. Additionally, we were requested by the client to use their proprietary ad system, which is part of a larger network of sites. And that in itself presented some parameters we needed to work around. So actually, to talk about the specifics of how exactly we did that, I'm going to once again. To Mike. All right. So like Libby mentioned, ads and analytics rely on basically a very traditional model of web pages and web applications. So usually, when you integrate most ad and analytics platforms, they expect a consistent and stable set of DOM elements of contextual information, such as that. So basically what they expect is you have an element with this ID on the page. You put some information in the window object. You tell the ad script where to put an ad similar with analytics. You load up a page. You give it some information. It sends off info. And you load another page. Does the same thing. Loading the page does the same thing. So this relies on stability. This relies on everything staying the same. But when you're building a single page application, everything is always changing. The contextual aspect of it is not going like the contextual aspect of a page is not going to change when you go into a post. Because the entire page is still there, all the DOM elements have potentially changed. And you have to control how that context flows, how it runs, where the elements go, where you want it, et cetera. So React and View and Angular and all of these, they completely blow those typical expectations out of the water. And you have to do a lot of custom work to actually make them make analytics and ads work as they're supposed to work as they're expected. So what we did for this project is we decided to hook into Redux, which I mentioned earlier was our state flow management tool for React. And Redux has a singular data flow, which allows us to hook in at very specific points and know that when an action in Redux has fired, and an action in Redux is somewhat actually very similar to actions in WordPress, when a certain action is fired, we know we have the data that we need, we know we have the elements that we need, and we know where those elements are. So we had to write a lot of wrappers around the ads and analytics scripts that we received, and when an action is run. So for example, when a user pops open a post, that entire page is still there. We just have extra elements. But when that's done loading and when it's all there, we know we have the information we need. So we send off analytics, and we load ads in very specific spots using wrapper components in React. So the big takeaway for us with this was the fact that you really have to evaluate what your traditional legacy tools are going to do in this kind of situation, because they're probably not gonna work as you expect. There's gonna be subtle issues, subtle changes, and subtle differences that you have to evaluate. The next feature that we wanna talk about is events. And Libby mentioned earlier that TechCrunch does not just have an editorial team. If you've used TechCrunch before, you've probably been reading their articles, looking at what they've shared on social media, reading through the news on startups, but they have a whole other side that's incredibly important to their business, because they're not just about journalism. They're about increasing the overall startup space, increasing venture capital, connecting people together, and they do this with events. And events have a very different editorial need and a very different visual need, because when you're looking at news on the TechCrunch site, you're interested in the most recent, most ongoing articles. Like you're probably just gonna read that homepage or maybe search for something very specific. So it's gonna be an ordered list. It's gonna be relatively static the way that it's set up. But events need to be customized for each and every single one. So we had to build a view that kept the branding and kept the same kind of componentry, the same feel that we have with the rest of the website, but GiveEditor is a lot of control over how this works. So you can see here, this is an event that is coming up, I believe. And we have this navigation on the left-hand side. So the branding stays consistent. We still know you're on this TechCrunch site.  So all of these blocks on here are controlled by a customized page builder in the backend. And editors can go in and change out any of these. They can add, remove, delete, change out the content of them, customize any single aspect of this. So they have full editorial control over this on a very, very granular level. And every event is gonna end up a little different because everyone has different needs, different locations, et cetera. And in this same vein of needing a lot of customizability, these events also need different information depending on what stage you're in because they're very time-focused, very time-based. If you're in this view, which is the pre-event view, you need to have information about what's upcoming on the event. But if the event is ongoing, alternatively, we want users to be able to go on and feel like they're a part of this event. So we display a live screencast of what's going on. You can see what sessions are coming up so you know when to tune in, what to see, et cetera. And you can see the news actually rolling in. And the beauty of using React for this was that we were able to use the same components across the board, across all these different views, just in slightly different orders with a little bit different control. So the reusability and extensibility was really, really solid with this. And then similarly on the back end, you'll recognize the feature island that we have from the home page. And this just shows different news and different screencasts and different views of the event. So you can keep engaged with the brand as you're going. So we're able to use React to create really reusable and really interesting interfaces, even though we have completely different needs for different editorial sides of the company. So it was obviously really exciting to watch these and a number of other features take shape in the weeks leading up to launch. And when we did deliver the project this past March, we celebrated first. And then we took a step back and started to assess what actually the lessons we learned from this project were. What were we going to take forward with us to our next project, to our colleagues, and back to the community as well. As a result of this project, there are a number of open sourced or now open sourced libraries that we developed. And we wanted to share those with you today for anyone who's interested in pursuing a project of this nature. And to speak to those, I'm actually going to ask you. So like Libby mentioned, these are kind of the epilogue to our project. This is our gift back to the community with some of the things that we've learned. And I'm only going to share three of these, but there's quite a few... There's a couple more that we can also talk about. So if you want to come up and talk to us about these projects or any other further ones that came out of this, feel free because we'd love to tell you more about them. We're only going to talk about three of these today. All of these are going to be available on GitHub and we'll have links to the resources at the end. And we're just going to talk quickly through some of the challenges that we encountered and how we solved them through these open source tools. So the first issue that we encountered or for one of the first and biggest challenges we encountered was there's a large disparity between the way that WordPress expects a development environment to function and how Webpack, which powers React and Vue and these other single-page applications, expect a development to... expect a local development environment to behave. So WordPress expects a very static set of resources. So you give it a URL of a script you want to serve. It looks for that script and tries to load it and that's the end of the story. It's very simple. It's very static. But Webpack is going to serve all of its resources from its own development server on your local machine and the name of those are going to change. The context is what's going to change. It allows you to do things like hot reloading the page so you don't have to manually refresh it, do component swapping, change out styles granularly and very quickly. So you need some kind of bridge between these two different systems. And so we built a small drop-in tool called ReactWPScripts. And ReactWPScripts is built to expect a Create React application. Yeah, Create React. Yeah, Create React. So it's built very specifically for this setup but you can modify it to use in almost any Webpack situation. You drop in this tool, so it's library, you put it in your Moop plugins or your plugins and instead of on-queuing in your local, you use our own on-queue function which looks for a Webpack manifest file and then it feeds those resources in and allows you to really smooth out and speed up your development environment and make sure everything is working quickly and as it should. And it really will improve developer happiness when you're working on the single-page applications on WordPress. So the next challenge that we wanted to address was actually a pretty universal challenge and that is the issue of documenting API data when you're writing it and the friction between wanting to actually write that data and spend time on building the website versus documenting it. Because documentation and API data is extremely important because you have to have some form of contract between your backend and your friend and developers so that when they're working jointly because that's usually how this situation works, they know what data to expect, how it's supposed to be formatted and everything but it takes a lot of time to write this documentation. It's very frustrating as a developer to not be writing something and have to go into some Word doc or something completely separate and write that. So we wanted to create a tool that automatically created this documentation for you and we created a tool called Restplane and it's available to be included as a plugin. You install this plugin and you get a UI that looks something like this and this hasn't been customized. This was just installed on our website and automatically scraped all of our endpoints and you can see here that this has all of the endpoints available to us on the left and we can click into one and we can get context about each of these endpoints and extra information and all of this happens really automatically so all you have to do is install this plugin and your product owners, your developers, anyone who needs access to this information has it and you can easily use it. So the last challenge that we wanted to talk about was the issue of pulling Rest API data into Redux. Now, when you're doing this, what happens frequently is that every time you have to add a new piece of data, a new endpoint, something new that you want to put into Redux, there's a lot of replication of effort. So you have to call out to Rest API, you have to normalize this data, you have to create actions to hook into it, you have to reduce this data into the appropriate formats and such and it's a lot of work, there's a lot of steps here and it's not hard work, but you don't want to replicate this every single time you're doing it and it also creates an opportunity for slight inconsistencies to sneak into the system. So we created a small tool called Repress and what this does is it takes over a small piece of your Redux store and you tell it what your Rest API URL is, which should be in your application already, you tell it what kind of data you want to fetch if it's a custom post-hyperterm, et cetera and it goes out to WordPress, it fetches that data and then it will put it in your store in a consistent manner and it just reduces the amount of work that you have to do when you're pulling all this data in to manage all of this.  Right, so I know we're very close to the end but before we go I do just wanna acknowledge the full team that was part of this project, Mike and I are merely representatives. Leading this was Frank Klein, Senior Engineers Robert O'Rourke and Catam White were an integral part of this project as well and we of course had the help and consultation of Joe Hoyle, our CTO and Ryan McHugh, our Director of Engineering. Incidentally Rob, Catam and Ryan are all here this weekend so if you have questions for them about this project I encourage you to pull them aside, especially Ryan. And as Mike mentioned, these are the links to the open source libraries we discussed today. If you have questions about these or anything else as he also mentioned there are a few other pieces that we couldn't include but would love to talk to you about. You can find here I after the presentation and of course on Twitter. So that does bring us to the conclusion of our presentation and we thank you all very much for your time this morning. Fantastic. So we have some time for questions. I should imagine that you are burgeoning with questions in the audience there, desperate to get them in. So first of all, can we find our mic runners? Where are you there and there? So who's got questions for us please? Awesome, in the middle there, thank you. So switching to this approach from the WordPress classic approach, what sort of SEO challenges did this bring in and is there any tip on how to tackle those challenges? We didn't encounter too many issues because what we found is that Google will load up the website and it will follow links and index those links but it won't necessarily follow those links in JavaScript in most cases. I think there are situations where it does but it didn't end up affecting us at all. So on that preload in WordPress in our situation we're loading up all of the metadata and all of the SEO information available and then in follow on requests as you navigate through the application we're overriding the title and I believe maybe the meta description and a few other small pieces within the application using wrapper components. If you're gonna go server side rendering and node there's a lot of libraries that you can use such as Helmet and some other ones if you're really worried about that but we didn't really see any knock-on effects from Google rankings in this and they're very important to take on so, yeah. Good question, right, who else? More questions in the audience there. Okay, Gentleman in the Green just behind you. Very keen. Hello, thank you for the insightful presentation. I would like to ask you more about your stack on, I understand you're running webpack also on your live machine and server serving. So what are you using as development and also in production? For development tooling, you mean? Yeah, okay, thank you. So what tooling we're using for development? We use a tool called chassis which serves up a WordPress environment with a few additions on there. It's a tool that Ryan McHugh and Bronson, Bronson, can't remember his last name. Bronson Quick. Thank you, Bronson Quick. So a couple of our developers created this local development environment so that handles all of our WordPress and we're using webpack to serve this up on the local level and it creates a development server that we feed in using that React WP scripts. Is not too much more to it? Maybe we should catch up a little later and I can actually show you what we have if you're more interested in seeing what it looks like. But it's actually pretty standard. It's very similar to what you'd get on a live environment just with the addition of webpack. Serving those assets in and everything else is the same React tooling that you'd get in a production bundle and the same code that you would see on the production site, so thank you. Brilliant, thank you. Gentlemen, just next to you, awesome, that's convenient. Thank you, thanks for lining that up. I wanted to ask, because you said you have a semi-decapowed environment. So I'm interested in how such a large site as TechCrunch is scaling. Can you tell us more about the scalability of your architecture? I'm sorry, can you repeat the last part? I'm interested in the scalability of your architecture because you said it's serving the PHP and JavaScript on a single server. So I'm wondering how you scale that for a large website that's serving thousands of requests per second. Yeah, so we had the benefit of being backed up by WordPress VIP and all they do is serve enterprise websites at scale. So we had the advantages there and basically everything is cached really aggressively at the server level. So even the REST API requests are cached for, I believe, 30 minutes and they're served out to edge nodes which means you get the closest response to you and so the React application, even though it's really large, it's all served client-side. So I mean the scalability of that really depends on the user machine but on the server side, it ends up actually being a little bit easier because that initial page render is cached very aggressively. We're doing a lot of things behind the scenes with object caching certain aspects of external resources and things like that and so it scales very well because TechCrunch gets a lot of spikes in traffic. They, a lot of their business model revolves around instantaneous news, the social sharing aspect of that, virality if you will and so they get large spikes in traffic and it handles it really, really well. So really most of it comes down to writing really solid code on the PHP side making sure that you're handling your caching really appropriately and that everything is cached at the object cache level, page caching level and we're cd-ending all the resources out, the images are handled via VIP's file service which is very similar to like Photon or you know, Cloudinary, something like that. Does that answer your question or help provide context? Yeah, yeah, thank you. Okay. Fantastic. Gentlemen at the front here. I'm interested in how much you use the built-in APIs and how, what custom APIs you had to build. Okay, so all of the APIs that we use were customized. So post page response, any of those guys, added some extra data into it. We actually ended up creating a lot of custom endpoints additionally. So there's a lot of third-party data that's feeding into TechCrunch. For example, they had a spinoff company called CrunchBase which provides information about all the companies and all the people that they talk about and we had to pull that in, store it temporarily in WordPress and then serve it out via an API. So all of the API endpoints have been customized and additionally something we didn't talk about is that we had to do some workarounds with authentication and comments. We created menu endpoints for that external information, added information to posts and any custom post types that we had. So our usage of it was extremely customized and we used the core of it. So I mean, we're still using the title you get, we're still using the content you get but we're just providing a lot of ancillary information on top of it. And that was part of why wrestling was so important for us because everything ended up being customized except for the very basic information. Fantastic. I'm gonna take one more, maybe two more questions. You were really enthusiastic then. Can we go for the tap in the front because that was super enthusiasm and then we'll take your question, so in the green and then we'll finish up. Hello, my name's Tom. I imagine on this kind of project, like that's a lot of unknowns, right? We haven't built many sites like this and so as we're coming up with these features we don't really know how we're gonna actually build them. How, I'm wondering like when you're project managing a site like this or when you're talking to a client, how you handle just that amount of unknown. How do you keep kind of a client calm when you don't really know how we're gonna build the site? How do I keep the client calm? I find asking a lot of questions. There are a lot of unknowns, especially if the point of contact or the client that I'm working with has a lot of other stakeholders to report to and they may be facing unknowns themselves about what those stakeholders are all across. But the more you can ask questions and look for those opportunities for that kind of flag or indicated question, it helps them feel heard. I think the most important thing about any kind of client relationship is making sure that they feel heard and that regardless of what happens they're not alone in the project and that they may be unknowns to both of you, but that together you're going to be able to figure it out. We use agile project management and a bit of a variation of agile on this project, but that encourages the kind of breaking down of a feature into very small components and taking them very small steps at a time until those unknowns become a lot more clear. That can be a little challenging because sometimes you get a little in the weeds or can't see the big picture, so making sure that you're able to kind of communicate both of those needs, the minuscule and how that's going to turn into the end project. And keeping the client in the conversation, that's how I approach this project on every other one. Cool, thanks. Good question because I wanted to ask that. So I really miss set expectations there and I'm really sorry but we're out of time, so train me on setting expectations there with the audience. But you are going to be available at the happiness bar and they're really lovely, so do come at the end. I'm so sorry that we didn't go to answer your question. So can we please give it up for Mike and Libby who have done an amazing job. Well done, guys. Thank you. Thank you.