All right, so let me first recap a little bit of what happened last time. So we introduced the notion of what it means for an affine scheme over a ground field K, this ground field is always assumed to be algebraically closed of characteristic zero. So when I say scheme, I will mean a derived scheme and we'll always be talking about derived schemes of what I call almost a finite type. So let me not go into the definition of that. So we define what it means for such F as to be quasi smooth. And what it meant is that if we take its tangent fibers, so they will live normally in non-negative comological degrees and we want that, so these comologies be zero for i greater than two. So in this case, we can define point by support of coherent sheaves. So if F was a coherent sheaf, and again when I say that I mean bounded complex with coherent comologies, so an S is a point. So we defined the singular support at S of F as follows. So we said that in our circumstances, the commutative algebra, SIM of the first cohomology of our tangent fiber, acts on, butte is a graded algebra where the generator sits in degree two, acts on this graded vector space and this is just the support. So support of this graded module over this graded algebra. Yes. And so the support lives in the vector space dual to vector space, which we took the SIM, and so it lives inside. So, well, take H1, the tangent fiber dual, i.e., it's the minus first cohomology of the cotangent fiber. So that was our point-based definition. And as Le Mon asked, so how do you ever get a handle on this? It's so theoretical, but so in a minute I'll give you kind of a couple of practical definitions of this thing. Let me just finish this, recapitulating the story. So we defined a classical scheme, SIM of S, to be spectrum over the classical scheme underlying S, so kill all the lower cohomologies, spec SIM of H1 of TS. So this is the tangent sheaf, you consider it's H1, it's a coherent sheaf on the classical S, take its SIM, and so set theoretically that looks like the union over all points of these guys, of minus first cohomologies of the cotangent fibers. And then we said, okay, so we have these point-wise supports, so to F we can assign singular support of F, which is a subset in the SIM. So the proposition is that it's closed, is a risky closed. So in the next talk I will give yet a different definition of singular support, which will make such claims obvious. So for now I'm just stating it. And so there was one essential result that I quoted last time that said the following, that so the singular support of F is contained in the zero section if and only if F is perfect. So singular support really detects the measure of imperfection of S. Okay, so now consider an example and a very kind of hands-on definition of singular support, and then I will give yet another definition of singular support. Okay, so here's another example. So let U be a smooth variety equipped with a function. And say this function is non-zero, so let's take the zero set of this function. So this is your, it's a hypersurface, and it's given as a complete intersection, so this is a classical scheme, but it's also quasi-smooth derived scheme. We said last time that locally compete intersections are exactly those quasi-smooth derived schemes that happen to be classical. So let's say in this case what sing of S looks like. Well I gave a general criterion, well the general description of sing S in these circumstances. So we're looking at the, well co-differential of this map, so it's kind of D F star. Of course the cotangent bundle to A1 is A1, so this is really a map from OS into this vector bundle, and so it's the kernel of this map, i.e. it looks as follows. So at a given point, so at a given point it looks as follows. It's zero if D F at S is not equal to zero and is one-dimensional if, so the function is degenerate at this point. And so there is not much room for singular support, well according to this theory what you have is that, so well all I can say is just to restate this in this case, that singular support at a given point will be zero if and only if F is perfect, only the risk and neighborhood of this point. So in the case of hypersurfaces singular support is either zero or everything. Okay let me say non-zero, be non-zero and then if and only if is not perfect. So non-zero means that excluding empty set and zero. I'm saying that you will hit this k if and only if you're actually are imperfect at that point. Imperfect zero is perfect. All right so now what I want to generalize this example, well to the general situation, so we said that in general a quasi-smooth scheme can always be fit into a Cartesian square where U and V are smooth classical schemes. So the Cartesian square is taken in the derived sense. So and parallel to this, so sin of S is the kernel of the map from T star V restricted to S to T star U restricted to S. So this is the dual of the differential.  So let me introduce a piece of notation. Let me call this straight V the tangent space to this curly V at the point. And so what you see is that this always sits inside V star times S. So very concretely the singular support will live in the S times the dual vector space well to the cotangent fiber to mar V at the point. So now very concretely I want to say when an element here belongs to the singular support. So let me take psi an element of V star and want to say when a pair S, psi belongs to the singular support of a given sheep. So here's a procedure kind of that is due to Drinfeld and you may so there's some vague analogy with vanishing cycles. So its analogy is really vague but well okay so here's what you do. Well here let me rewrite this again. Now choose a function on this V whose differential at your chosen point is psi. So this is my H and this is my F. So DF at my point is psi. Okay and so vanishes at the point. So let me denote this V prime. Let me denote this by the preimage by S prime. So this was my old point and this is my S. So if you wish S was the set was the set of zeros of the map H and S prime is a much larger closed subscheme. It's the set of zeros of the composed map. Okay. H? None. Absolutely none. Yeah the two guys are smooth and H is absolutely everything. No you mean these guys? No the S prime and S are derived. So S and S prime are derived. Well F so S well but in fact yeah both guys are derived but note that note however that S prime is a hypersurface because S prime is zeros of this composed map. It may happen that this map is zero but it's okay. We're still in fact when we discuss this hypersurface situation it's just as well applicable to the case where the function was zero. Why not explain things in coordinates? We got just a collection of functions in some coordinates. You know it's extra notation. Let me do it and then maybe I'll let you do it because I'll get confused when I write coordinates but so all I mean is just create this diagram and S prime is hypersurface. Let me denote this closed embedding by I so and here is the theorem is that so this belongs to the singular support if and only if the following happens. So you had your coherent sheet here take its direct image you get a coherent sheet here and what you want is that this guy be imperfect. So pardon in the neighborhood yes so it belongs to this if is not perfect on S prime only the risky neighborhood. So if you regard perfection as an analog of the property of ellatic sheaves being lease then you can detect singular support by this property but not on the initial scheme but on a kind of a bigger guy the hypersurface. I don't know stuff and in the drive things can be complicated. No no no it's no it's no complications here it's just under closed embedding nothing happens there. So it's kind of so it's a morphism of spaces with a DG difference or the ring something like this. You take us the naive directive. Yeah it's absolutely yeah it's direct images direct images to have a map of rings and you just it's a forgetful functor under the map of rings. Whatever you use if you simply show a representation okay nothing happens. Yeah so this is the most naive functor so no no complications here. All right so so now I'm facing well it's not a dilemma so I'm I want to give you yet another definition of single support which is very calculable. It's it's a little bit complicated so please bear with me and if you don't like it just erase the next five minutes from your memory. It may not be so nice. Well the order of proofs is not as presented. You can prove this I'm not giving the theorems in the order in which they're proved and to prove it all you have to start with yet another definition which I'll give which I'll give next week. So kind of the ultimate definition is via Hockschild co-chains. I just don't want to throw them at you right now but we'll do it next week. All right so okay so here is them so let's call it the Drinfeld definition and I'll give you a Kozul definition. So we will we are still in this situation so this is a situation of complete intersection and so now introduce an object that has already appeared I call it gv. It's point times point over v. We've seen this guy before and we even said that so co of this gv g was modules over the following algebra. So let's say perfect modules. v I remind you is the tangent space to this curly v at the point. Okay so now just notice that well it's a group void over the point kind of by definition you draw. Now group voids over a point are groups so it's actually a group object in the category of derived schemes and moreover this group object acts on our on our S. So namely you can draw this diagram you can draw yes so I have tacitly passed to our new world so we have this infinity category of derived schemes in that in this category the notion of a group object. Yes S is our S. Yes I'm referring to this picture so if you wish this group void that acts on a point lifts to a group void so there's both squares a Cartesian acts lifts to a group void on S and in other words we say that this group acts on S the group gv acts on S and let's denote by act the action map. Now here is what you do and remember I said that single support is a subset in v star times S. You start with an object on S you lift it by means of the action to here and then you apply this well this is this equivalence is what I call casuality along the second variable the first variable so you go from here to a module and then you take its support. So the theorem is that singular support of f equals the support of well casuality applied to act upper star of f as a subset inside S times v star. So when you actually need to compute something you use this definition. So if I were to see it the first time I would be completely baffled or how do you what is this action how do you compute these things so maybe don't worry about it right now I just wanted to give you a perspective how to compute things okay. Do you have an example of non zero support just a case that we can see. Oh yeah we saw this example right. Yeah so we saw it at the end of last time and I'll come back to it in a moment yeah. So classical ski. Yes I have a single hypersurface I take a hill shield off point which is not perfect. Yeah yes. No but where you get a cone in your dimension I mean because here it's is of zero. Yes we saw the example of this particular remember last time of this guy and so we said that this category is equivalent to this and so for example if you take the skyscraper you will get the module which equals the entire algebra it supported everything. So there is all the cone. Oh and then you can so then there are all the intermediate cases take any object here. No but there is no constraint on the cone. Absolutely none take any any object take pick a cone pick any object supported in it apply the inverse equivalent and you and you got it. Okay so so in the next talk I'll well I'll give the ultimate definition of single support and prove various properties. So these to prove these properties it's inconvenient to stay with coherent sheeps and so this is the next step that I want next procedure that I want to apply. So we said that if C was a co-complete triangulated category you can define the subcategory C with little c of compact objects. So the claim is that in most of the practical cases this subcategory retains basically the same information as C and in fact there's an inverse procedure that I will explain right now the only problem for the inverse procedure that well you really have to abandon the old world you cannot stay with in the world of triangulated categories you need to work with dg categories. So if you start with a dg category c0 you can produce a new one it's called the end completion so basically so I'll characterize it uniquely in a moment basically what you do you add all the direct sums and cones and direct sums and cones. A little circle to distinguish notationally c and c so like this is a small. So functorially it's characterized as follows so if you're given c0 well this end circle c0 will be co-complete and when you talk about functions between co-complete categories you can talk about those functions that take direct sums to direct sums these functors are called continuous so continuous functors from this end completion to an arbitrary target co-complete category c are the same as well let me call funct yes co-complete well co-complete completeness is the property of the triangulate level just you have direct arbitrary direct sums and this should be an equivalence in the world of yes again so these are yes these funct form a space and it's an equivalence of spaces again and this depends on your model functorially in c so so we have two operations one is going from a co-complete category to the subcategory of compact objects and another from a small category c0 to the end completion so i want to explain in what sense these two procedures are inverses of each other they're not quite inverses but almost so to give an object in the end completion is it always something of the form like the inductive limit of some filter system yes well the filter system is not a strict one but with a higher the dg yes so it's a it's a filtered co-limit but the category of indices is a higher category yes you need to higher categories as the index as the indices to create all these limits yes okay so i want to say in what sense these operations are do mutual inverse so here's the definition it's a very very important one a co-complete category is said to be compactly generated if the following happens if you take the subcategory of compact objects and look at what is right orthogonal to it so all the objects such that home into them from compact guys are zero compact generated means if this orthogonal is nothing so if if an object is right orthogonal it receives no home from compact objects then this object is is zero so this definition i believe is due to thomason and there was a beautiful paper of thomason's where it's used okay so so the theorem is as follows so if it starts with arbitrary co-complete category you take the subcategory of compact objects and take the end if it map back to c is fully faithful and let me say a prime is an equivalence if and only if c is compactly generated so most categories that you encounter in practice are compactly generated and so it tells you how to reconstruct c from compact objects and b so in the opposite direction the map from c not to the following so if let's take the end completion of c not and let's take compact objects there it's not an equivalence but this functor realizes as c not car do you guys know what car means carubi yeah it's the carubi completion of this add all the images of all that importance okay so our co of s is like the c0 and i will really want to consider ind co of s which is by definition ind of co general can say that ind of this category c0 is the same as functors from opposite right okay let me give an exercise exercise number one it's a it's a great exercise in fact it follows from something that's already written on the blackboard that you can describe it very very concretely as follows as maxim says these are functors from take c0 take its op these are vect vect is our the category of vector spaces but in the dg world so complexes of vector spaces so for some reason i want to pass to the end completion so why so in fact i am interested in coherent objects why do you bother to incomplete so it's well the reason is that it just so happens that it's much more convenient to work with this incompletion the analogy is so imagine yourself an ancient greek and one day someone came to you and said oh let's introduce negative numbers but why do you care a lateral negative number well it's an abstraction we're interested to count our apples but so kind of you want to account for the fact that five minus seven is eight minus ten or something and you don't want to keep to be keep writing this all the time it's and it's the same kind of thing that ind co buys you you're in the assumption of c0 the exercise one what is none just a small category small dg category over over k over k yes we are and uh and from the dg category it's complicated story so what but you have to know what it means five c0 well yes so it's a world of dg categories and functors between them and they also form a dg category so somehow the inductive system of xi well roughly should go the factor presented by it yes all from y to x the limit of all from it's very close to brown's representability theorem so this this thing but these are the naive dg functors right no no it's the same thing to you okay yes so it's functors in our world so let me by the way give an example of the situation so if c is a mod where a is an algebra so c is compactly generated so if i want to find the regular statement so we should go to the reference as you mentioned like yes you should so for this you should go to it's luri's books five five point four and five point five but you did not open it no i opened it and unfortunately i opened it so this is an example of a compact generated category by the way let's prove it who who knows the proof so why is it the case that no objects here are right orthogonal to compact guys which one is over for an associative algebra i think from a yes okay we have a good student here so here is a compact object namely a itself home from a is the forgetful functor so home from a is the forgetful functor from a mod to vect this functor is conservative therefore nothing gets sent to zero so you don't need to look at all compact objects there's one compact object is enough so particularly if you apply point a prime of this theorem you obtain that ind of perf of s maps isomorphically to quasi-co and now we're introducing a new guy i call it ind co this which is if you wish well i just definition it it's not something that you know a priori it's just a new guy so let me play a little bit with this so we have this ind co and we have the old quasi-co and first i claim there's a canonically defined map i call it psi of s so all the definitions on the blackboard let's play a game so who will define this map for me yeah you know it so somebody who doesn't hasn't seen this before would you be able to define this map for me just just using the stuff on the blackboard no that's not true co does not map to compact objects in quasi-co yeah co is not contained co is compact objects in quasi-co is perf co is not contained so but you don't need compact i don't need compact object yeah apply this with c0 is co and c0 is and c is quasi-co we want a function in this direction but we do have a functor from co to quasi-co just embed so this is your psi okay yes well it's construction so we have this functor let me just say that so so observation is that ind co has a t structure such that this functor psi is t exact and not only and defines and it defines an equivalence from ind co s plus to quasi-co s plus so these are well usual notation things that's um bounded bounded below so the only difference between these two categories is somehow minus infinity and you can wonder how can this be relevant so i said at the beginning it's all about divergence of spectral sequence so it's really kind of details of our categories are different and everything else is similar and you can ask how is it possible that this is of any use i mean what's the more precise about this so when you say bound from below you have there is some bound on the commodity sheet let me say at minus and okay are you working with a fixed bound or you're saying no are you taking in of co no no plus means the following plus is i can say it's it's an equivalence on these guys for every n and so our sorry equivalent everything is equivalent the tails are different offer sorry can you ask okay so you take first so you take co s then you take bigger than negative minus m and then you take ind of this no no no i don't take ind so plus means it's just the naive union of these guys for all n that's what plus means when you write ind co s is the situation of parentheses i'm sorry for the nothing no no no ind co no when i define ind co i don't refer to any t structure when i write co i said it last time co means bounded complexes with coherent homologies yeah so when i define ind co i don't refer to any t structure yeah i claim that it has a canonically defined in t structure which is in fact uniquely extended from the t structure on co you can say that so ind makes sense not just in the triangulate context ind makes sense in just general in infinity categorical context and it's completely true it's true that this is the ind completion of co greater than equal than minus m in the sense so ind makes sense always it's it's a general procedure in infinity categories ind makes sense always categories okay okay next question to the audience again for those who haven't seen it before i want to function the opposite direction who will give it to me don't be afraid what come on okay michael says perf go so michael says this quasi co is ind perf int co is ind co map perf to co and in the extent is that what you're saying yes or no no no no no no no no no no no we have witnesses here okay i think we said that so i'll define i call this function xi and xi is just well it just embed into co and then in the extent okay let's consider an example i'll give you a digit derived scheme s is spec k of generator xi xi lives in degree negative two i'll give you an object here which is just the structure shift o and you want to send it to itself kind of but it's not coherent it lives in infinitely many homological degrees you're right so it's it's it's not gonna work like this it's not coherent so s is not the structure shift is not coherent so definition s is eventually co-connective if the structure sheet has finitely many co-homologies so for i large so example well example zero anything which is classical is eventually co-connective but what's important for us is quasi smooth guys are this is exercise two so remember quasi smooth schemes can be locally written in this cartesian products and using that you should be able to exercise two this is a counter example this is not a counter example this is a guy which is not eventually co-connective so this notion of eventual co-connectiveness is useful so let me just state one thing well kind of tautological but makes one appreciate more so you have a map of derived schemes only only then it's yeah i'll go back to that in a moment i just want to so let f be morphism between these derived schemes again we are almost finite type then then f is a finite torque dimension if and only if it's fibers so you should think of the failure of eventual connectivity is the failure of having finite torque dimension prove this that quasi smooth are eventually co-connective so let me go back to these functors so the claim is that they're mutually adjoint form an adjoint pair and b is that this psi guy is fully faithful of just eventually co-connective the condition that the psi exist and so this is actually a very important point you have this pair of adjoint functors with this being fully faithful this is called the situation of co-localization so psi allows you to view quasi co is sub category here but psi allows you to view it as a quotient category and you use these both points of view all the time so it's a sub but at the same time it's some kind of coarsening so it's actually quotient of this by by something which is also very explicit and a lot of mistakes are made by so when you I mean the world of the word quotient fully faithful means that a funk so a funk to define a map between mapping spaces well homes before were sets now there are the home between two objects now is a space functor is fully faithful is this map of spaces in this is an isomorphism well isomorphism in the category of spaces which is homotopic equivalents but did you say when you have to see yes eventually co-connected okay even more explicit than that no but you say quasi co so that so that's a module yes so this is something so this is something we know and yes let me just say one more thing so that let me just say one more thing so I said that this is the quotient of this it's a very dear quotient by something let me tell you let me tell you it's a quotient by what so the kernel of psi is all those objects such that remember we had a t structure so this t structure here is degenerate so there are our objects that all of whose columnologies are zero in this t structure but the objects are non-zero so for that reason this this kernel is some kind of phantoms and and again you can go back and ask how can these phantoms be relevant but in a moment I'll give you in a concrete example for example here's a question how do you feel a phantom like I want to I give you an object in the kernel I want to can I produce a number out of it like something very tangible and we'll do it in a moment so it's actually possible to like really get a handle on this kernel by definition in this situation the kernel is right orthogonal to the essential image of this now hi is in the sense of that that is no I said that this category has a t structure so it's hi with respect to that the t structure that I said existed on intco that came on interpreted as a as a quasi-coherency from the classical classical scheme and then they say zero as a quasi-coherency from the classical scheme because as far as I understand that maybe I'm making it for any thing with your categories like quasi-co or co you can associate chromology shears which are actual quasi-coherent or coherent shears on the classical scheme oh no the sing no no I'm just so just to avoid missing let's make so if I've got a class something you call or call s yes so I as far as I understand so it is some differential graded thing you know but the its chromology it has chromology shears which are classical all s quasi-coherent or coherent modules yes okay now is it the case that the t structure in question has to it does not relate to this in other words it it well in some sense it is related to this this t structure is the in the extension of the t structure on co which is the one you said so in other words is it enough for something in intco can one just associate a h i which is a classical absolutely and say that this is zero is the same is it is your condition and does this one is zero is a classical quasi-coherency or is it something yes it is and moreover the answer to your question is already contained here I said that so offer is asking this is a very good question so yes ask can I think of this individual cohomologies as really coherent shears in the abelian category here's how you do it you apply this function psi you go here and take cohomologies and we said that psi is t exact so it's the same thing as take cohomologies upstairs so the answer is yes the only thing that there are objects there all of whose cohomologies in this sense are zero and yet the objects are non-zero so these t structures what's called non-separated now suppose that I want to observe tomorrow's infinity to plus infinity so can you have so I don't see why that if the h i is zero and the limit for the sequence of coherence so you you want to produce a counter-example of something tell me of what and maybe I'll help you because you somehow you meant the pathology got is in minus yes yes I'm saying that this functor is an equivalence every time you're bounded from below I'll give one more example you'll see maybe you'll see okay so here's a question to ask if I were offered I would ask can you give me an example of an object in the kernel is that what you're asking yeah but all there's no pathology of the plus infinity but maybe the next question is to produce an example I'll give you one I'll give you an example in a moment okay let me do this example and then we'll make a break so as I said there's one example that I find particularly illuminating and it's when s is my favorite point times point over v i.e its spectrum of sim v of one and so here is the complete picture so int cove s is isomorphic now you take all modules no perfection condition so int cove is all of this thing quasi co as we said last time is modules with support at zero so our xi well it's just the tautological embedding and this functor is the right adjoint and it's taking how do you call it comology with support so something it's the right adjoint like if you have a variety in the sub variety close a variety there's a functor adjoint to the embedding of the full category if she's set theoretically supported in your sub variety so take a comology with support and that's that's the right adjoint that's what it looks like so for example here is an example of an object that lives in the kernel of this psi s so if you take v to be one dimensional then we are dealing with sim it's polynomials of eta degree eta is two not to be confused with that psi where degree was negative two so a typical module will be chi k of eta eta inverse so this is a typical guy that will vanish under this functor so what is the relation what is the factor from co as if you expect to see the minus oh this is our causule duality from last time say it in the moment so causule duality let me call it our home from the skyscraper by definition there did start life as modules of your theory algebra but then you apply causule duality and you look where they go to as module symmetric algebra they go not all modules but this kind of modules is it similar to in the sga there is something why you you have the quasi coherent shift that you embed into all the shift and there is an adjoint quasi all she's meaning all she's meaning not quasi coherent not quasi coherent it's not the same but it's it is we mean if that's some similarity what does that work is actually completely degree zero consider scheme let's have closed subset that's the shift support on subset just degree zero or we can put this in the same destruction but i want to finish this hour by something tangible so let's be in this example but now let's consider categories of modules equivalent with respect to the action of gm by dilations so we can consider int co of well it's our s and well you can take it's either the quotient or it's equivalent to the kernel of psi gem equivalent so our phantoms and the claim is that this is equivalent to quasi coherent sheaves on the projectivization of this star so it's something very very concrete if you want it to a number well it's not exactly a number but it's a coherent it's actual quasi coherent sheaf on something classical so eg if the dimension of v is one then the above quotient so the kernel psi if you consider the gem equivalent category it's just vect so here if you wish you get kind of numbers so it's a really kind of tangible way to quantify the difference so let me finish by giving the following definition so let n be let s be quasi smooth and let s be a conical subset in sing so then we have the following categories so we have int co we have quasi co which is in ind perf but you also have something in between that i denote int co n and that is by definition ind co sub n where this was defined last time as coherent sheaves with support on n so this is by definition ind co and this was theorem but an easy one in perf and as before we have these embeddings because the corresponding categories of compact objects just naturally embed each to each other and now it's a general theorem of luris that these functors always admit right adjoints so so this int co is what is the category of interest and it's connected to the more classical category by this pair of adjoint functors and so the bigger category of int co by a pair of adjoint functors and again it's very easy to make mistake so because you can think of int co in two different well four different ways sub quotient sub quotient and you really have to make sure that you know are you thinking it as a sub or as a quotient or something okay so let's make a break and we'll continue we are interested in ind co on the stack of local systems and I thought that I should well say something about that first I should say what it means to be int co of an algebraic stack and so and also how is loc sis an algebraic stack yes now on everything is derived and that causes some troubles I mean okay so int co of an algebraic stack may be a little bit boring but let me go through it nonetheless so first of all for this and for many other things we don't want to restrict ourselves to let me first talk about quasi co so I want to define what it means for quasi co when y is an algebraic stack but it really makes no sense to restrict ourselves to algebraic stacks what we want to take y is an arbitrary pre stack and what that means it's a completely arbitrary functor from affine schemes I mean derived affine schemes to group oids well exactly I want representable functors to be well I want my schemes to be among pre stacks now home between schemes is an infinity group void because we're in infinity category so you've got to include in the entire call it spaces therefore okay so what does it mean to have quasi co on a pre stack well naively what you want to say is for every s kind of for every s point little y of y you want to attach so to specify an object of quasi co on the pre stack so to every s point little y of y you want to attach an object of quasi co on s thought of as the pullback and every time you have s1 goes to s2 so let's call this little y let's call this f let's denote by y1 the composition to every situation like this you want to attach an isomorphism between f upper star of f s2 y2 with what you've got on s1 itself and of course every time you have a three-fold comp two-fold composition so let's it be f and g it'll be y3 what you're gonna have so it'll be f upper star g upper star f y3 okay let me write it once and for all so on the one hand it'll be so our datum for this composition identifies it with f s1 y1 this is f upper star f s2 y2 and then so we have these maps now we're so therefore the two circuits to go from here to here these are maps between objects in the higher category you want to space specify a homotopy then you want something for four objects then you give up and that's how homotopy is right but yes i do what i do i put my hand on luri's book and i do and i say this none none just pre-sex so what i say is this well it's exactly as i'm at the saying so there is a functor from affine scheme's opposite to well dg cat this functor is s goes to quasi co i have to believe in the existence of this functor then you have the category of affine schemes over y so it pairs s comma little y there's a forgetful functor forget the map to y so you've got the functor from here to here and then then you define quasi co of y say this word it's limit let's call this functor quasi co so limit over this category of indices of this functor and it's an object in dg cat so this is one of the things that the theory of higher category is good for no what what's the precise event it's this is one of the reasons it's good that this theory exists you don't have to think about it definitely just write it and never think about it well but then there are questions of how do you compute it so for example you can take y to be an algebraic stack and you can compare this definition with one in the book of the morning so what is true so remark that if y is algebraic what you know is that well there is always a t-structure kind of for any pre-stack there is a t-structure so this is definition on this bounded below part you get what you always did on the entire category i have no idea and there is no reason to believe that they are the same i don't understand exactly so if you have a user of the bright stack or even the scheme i mean so you have some group or it is a small group you represent it so you can say the usual i'll say the moment okay so you just consider shapes and those things but here you allow anything that maps yeah and you allow to consider some shapes without the the full exactly you don't request that that that when you have full backs or do you request this so that if you have s s1 to s2 isomorphism in the right sense of course yes but then so i circumvent the question of how you homotopy glue by writing this the problem is it's like a magic as same as what i don't know no the usual is usual scheme of course you'll get the same thing but even algebraics on the algebraic stack i don't know what their definition will give it minus infinity your goal is to to do something on luxis yes the local system on a curve g local system so what is the problem you cannot stay classical in some i won't be able to so i will get there in yeah um no but at least this the stack is classical no it's for p1 it's not we'll get h2 yeah we'll see that in a moment so it's true if the group is semi-simple the curve is genus greater than two then the stack will be classical in this case however when you want to prove something about it you go through luxis borrell and that is never classical no but at least you can understand the statement yeah no but i mean so you can give this definition even you can restrict yourself to classical schemes and i will still give the same definition the problem gluings persists so this definition is you can do it in the derived setting or in the classical setting so can you in general derive stuff so the usual stack can be represented by some simplification of object of the algebraic spaces so yeah yeah okay can one derived stack can it be represented some kind of simplification of derived you mean derived art in stack yes yeah so by definition so let's say when i say algebraic stack i mean one art in stack and those are this you say the same words you just cover by derived schemes in the same and then it's just exactly the same as in the classical theory but there are different ways to generate stack you can also call it a higher stack so do you you're considering i will i will say in the moment okay maybe maybe it's a good point to say it so definition so let me be slightly more restrictive than general so an algebraic stack algebraic derived stack is a pre-stack with the following properties such that first of all it satisfies etal descent and two there exists a derived scheme s equipped with a smooth map with a schematic smooth map so schematic means that if you base change it by a scheme you get a derived scheme so i'm skipping so properly i should have i should start from algebraic spaces so i don't yes yes uh surjective schematic smooth surjective okay so you are not and so this is the so i've not followed exactly the literature i know that some people even in the real world but then what is the general definition of derived stack is it like what you have written these are the right spaces so do they consider more general like higher okay here's the system of definition that i like i define other pre stacks so first of all when i say when i say derived stack i impose descent condition say etal descent condition and then so okay let's call these guys derived stacks and now there is a notion of k art in stack these guys are defined inductively as follows so for for k equals negative one so i mean they're very so let's say for k negative one derived art in k stacks are derived schemes and then you proceed by induction so each time so if you so why is a k art in stack if it admits a map from the derived schemes such that this map is such that the fibers of this map are k minus one art in stacks that means that if you base change it by another derived scheme this fiber product well you want this map to be so yeah yeah so you want this to be a k minus one art in stack and by definite and then by induction it makes sense to require that this map be smooth and surjective so it's kind of inductive definition uh Gabrielle is it that reasonable scheme to define the the pre stacks are evaluating spaces yes what what means this uh infinity group odds and then so this is a reasonable scheme of definitions so what we'll be dealing will be algebraic guys algebraic is is k art in for a k equals one and here i gave well i don't like the scheme of definitions i just did it for brevity i normally i should require this map not be schematic but the fiber should be algebraic spaces but i'd require something stronger i should for aesthetical reasons i should actually do first algebraic spaces then then algebraic stacks but here i just i skipped so how do you but it seems that there is only you only go from zero to one when you pass from one of the right spaces to stack it is unstable so but you know you said first minus one to i i here i skipped but i should we proceed i think it's pretty clear now or do you do you still have a question so the true scheme of definition is as follows define derived schemes define derived algebraic spaces and then define what derived one art in stack and then by induction and then by induction i mean you can start the induction from minus one already so you just have this minus one that i've skipped and at zero you get the right spaces yeah maybe so it starts from zero yes so derived derived algebraic spaces you require the map to be et al but et al desans is it complicated to define no no it's just a usual it's the usual yes but the only thing that so let me just say it just convey the spirit of things so et al desans means the following that if you have a so this is um so there is a notion of et al map between affine derived schemes then you form this check nerve and and then you require that y of s so this is a group void the infinity group void then you have this this is a co-simplicial infinity group void you take its limit over the category delta and you're required to this map so it's limit in the category of infinity group voids i.e spaces and you're required to this map be an isomorphism in the category of spaces so that's the definition it's a little bit frightening but i mean it kind of you one has to follow one's nose i mean there are it's difficult to give a wrong definition here i just proceed for what for coherent sheaves or for these guys no i mean yes however i wanted to say one thing and so it's going back to offer a question so we've got this general definition of quasi co so observation let y be algebraic so initially for an arbitrary pistachio i took all s's that's as over the protests that you took all all schemes mapping to y but while you break one can consider one can replace by by smaller category so one can take the limit one can replace the limit so here we took over the category of all affine schemes over y opposite but so you can consider another category that maps to this index category you can consider affine schemes let me call it smooth over y so it's a full subcategory here and you have a limit over the category and another category maps to it this limit maps to the smaller limit and the claim is that this limit will be it'll be an isomorphism so you don't it's enough to consider all these schemes that map smoothly but even more so you can take smooth over y but you can take a non full subcategory there you require that the map between the schemes themselves be smooth so you don't need so not only these s's map smoothly to y these f's between the s's are also smooth and it's it's going to be the same the limit the map between the limits will be an isomorphism and you can also work with a strict strict meaning without degeneracy yes and that's yeah i mean the map between s and the classical classical now when you say the double smooth so you are smooth over s in the the height sounds yes smooth over and then furthermore in the middle thing i allow arbitrary maps between the s's and the ultimate ultimate thing i'm between them no in degree zero smooth means smooth smooth so great question smooth over point we had this definition it means classical and smooth no so it's like there were two questions here if you have a map between art in stacks it may make sense to talk about a map being smooth you mean cover enough so you can reduce the question of smoothness of maps between art in stacks to question you can test it by a certain map between schemes it doesn't mean schematic even so you can say you can talk about the let's forget derived algebraic geometry you can take an just classical algebraic stack it makes sense for it to be smooth over a point yeah so that's what i mean when i say smooth that means in this sense okay smooth over why is in the sense which is more general than what you say in the definition yes but if i if i stick to algebraic spaces uh algebra to this definition any map from a scheme so in this definition any map from a scheme to my stack is already schematic so that's why i gave this definition so in this definition any map from a scheme is already schematic therefore it's kind of definition of what it maps what it means for this map to be smooth is automatic it's already a schematic map when i say scheme i mean derived scheme derived schematic yeah yeah so no let's say schematic is schematic if you have one guy which maps something which is schematic yes it doesn't mean that in the other one right for the other one you don't get that's true sorry my bad requires schematic diagonal not it really doesn't matter here so okay let's let's let's do the proper definition let's do it by induction so in this case it will be an algebraic space and then it makes sense it makes sense to say what it means for a map of algebraic spaces to be schematic to be smooth okay now but if you have two two classical schemes a map between them is a smooth oh it is it map is in smooth then it's smooth it's a classical definition let me answer Maxime's question what it means for a map between derived schemes to be smooth so so so well we are in finite type definition f is smooth if and only if if it's fibers in the derived sense are classical classical smooth schemes note that I'm taking fibers in derived sense so therefore flatness is absorbed already and as Maxime says it means that after etal base change you just etal locally smooth means that you're crossing with an the usual an all right I'm very glad that you didn't this didn't put you to sleep but on the contrary I thought what people just oh my god algebraic stacks okay so now let me let me define intco I will only define it for now for algebraic stacks or k-art in stacks the reason is that will enhance the formulas but for now we can only we can only do this namely if you have a map between schemes what is f upper star I wanted to map from and if the map is smooth this is easy to say what it is it's just you take if the map is smooth or more generally a finite or dimension you could do f upper star it maps co to co and it does even only if the map is a finite or dimension and then you extend and if the map is not a finite or dimension there is little theorem that tells you that it's actually impossible to define in it with any reasonable properties so pardon in each sense it's it's the same as here so so the intco is a functor out of the category of affine schemes and smooth maps between them and then so let me give you a preview so f upper star will actually fail for arbitrary morphisms what will happen what will exist as f upper shriek so intco is good for f upper shriek and we'll talk about it in detail next time and there's a there's a theory with a lot of content with this upper shriek so let me i want to test the level of alertness i'll write a theorem which one of which points will be false i want to see if anybody will catch me pardon a dual of inco a dual in the sense so everything every functor has to have a dual a dual in what sense luri sense i mean we'll we'll we'll we'll talk about so i kind of let me do it for the for our current goal this this is good enough and then we'll okay so let me also say that you define perf same thing perf of s um you define define co of y so proposition again this is defined for algebraic stacks who is happy and who is not i define separately intco as that limit or i can define co as the limit and then take the end of that yeah for schemes it's okay for stacks it's completely false all of it okay so let me tell you when this is true so what you really need is so why is quasi-compact affine stabilizers so in this case it's known okay so this is this statement makes sense for arbitrary pre-stacks it's completely false for arbitrary pre-stacks so let me say what is true so for this statement i mean this only makes sense in for infinite type i mean we only define co in finite type almost finite type this you can define in general it'll be completely false so let me say what is true uh so let y be quasi-compact with affine stabilizers so in this case let me call it b prime it is true that perf of y is contained in quasi-co so that much is true that this perf is guys as i defined here are actually compact and i want to say that it's in the the functor well actually it's sorry it's an equality so then i can ask if it's true that end of perf of y is in equivalence and i don't really know it's certainly conjectured there's something lurking in the back of my mind that i recently saw a paper that proved that do you guys does anybody know so under some mild conditions so it's certainly conjectured this is true but it's not known it's true in many many cases so in many cases you can explicitly prove it in particular for lo axis and stuff like this but i don't think it's known in general so there are there are some pitfalls so geometric point yeah it's kind of yeah it's really similar it's enough perfect global perfect yeah it's true for schemes so this is this is wonderburg for algebraic stacks it's just not i don't think it's known finally what is the statement of the proposition so b is false b is false this is true so this is true this is true this is unknown you put proposition before yeah no see this is true this is true this is unknown so let me just separate it like this i just i just wrote it this way to kind of again to draw your attention that it's not such things are not for granted to put you a usual scheme and result result derived and result stuck so i'm not sure what are you saying because it's difficult to find after global perfect complex it's a non-trivial theorem it's it is it is wonderburg quite it's separated yes then it's true no uh in general meaning you wrote the inclusion yeah so inclusion yeah inclusion is false for arbitrary pre-stacks so to have the inclusion yeah yeah so even if you have take the following scheme infinitely many disjoint unit infinitely many points all will not be compact there already there so quasi compactness is nest is kind of essential all right oh wow i'm really behind okay so let me finish with a few definitions so let y be algebraic stack or if you feel comfortable with k art in stacks you can do it k k art in stack yes everything is derived and always assuming almost a finite type locally and all this means is that the schemes by which you smoothly cover are most of finite type so definition y is quasi smooth if for every little y which is a k valued point so we have the following h i of the tangent fiber is zero for i greater than two greater equal than two just notice that if you're dealing with k art in stacks the cohomology will live from degree negative k to infinity so negative case case if if if y is a k art in stack i'm sorry so if algebraic stacks it'll be from minus one to infinity so from minus one to zero this is these cohomology responsible for automorphisms and from zero to infinity like in the case of schemes for singularities so we're interested to bound the singularities we don't care to bound the automorphisms so this is quasi smoothness equivalently y is quasi smooth if for every scheme s that covers y smoothly every such that f is smooth s is quasi smooth so quasi smooth meant means that if you cover by a smooth scheme that scheme must be smooth so you define sing of y in the same way it's a classical k art in stack define the same way it's a kind of spec relative spec of sim of the tangent shifted cohomologically by one and you notice the following that if you have a scheme mapping smoothly oh sorry h1 i'm sorry just as before you'll notice that in this case what is it it's one art in stack usual one art in stack well it's k art in stack and art in stack if y was an an art in stack it's classical and art in stack so it's it's it's it's a schematic over over y so if the situation where f is smooth if you pull back the sing of y to s you'll recover sing of s maybe i should have said in general that if you have a smooth maps smooth smooth map between quasi smooth schemes that in general sing of s2 over s2 with s1 is sing of s1 a smooth map doesn't change the first cohomology of the of the tangent so it's most in the sense of yes it's so we have a notion if you have a k art in stack it makes makes sense to for a map from from a scheme to that to be smooth and the compatibility of sing is for a smooth map of of which compatibility this of sing with the sing is defined for for art for quasi smooth for quasi smooth art in stack art in stack and the compatibility with pullback is for a smooth map of quasi smooth art in stack for a smooth map you mean here no the sing the sing s2 for s2 s1 and sing s1 is it for a map which is smooth for f which is smooth from a scheme to an art in stack that is also true it's also true so if you have a smooth map of if you have a smooth map of art in stacks the sing is just pulled back quasi smooth maps in which that's the only case where sing are defined so the the sing's pulled back yes so quasi smoothness is a property locally smooth topology in every possible sense in h1 kind of h1 of the tangent if you take the tangent downstairs take it h1 pull it back it will be h1 of the tangent upstairs because h1 sees only the singularity so let me in the remaining one minute um so let me give kind of our crucial definition so let's fix n the risky closed conical in sing of y and because of these isomorphisms upstairs we have a well-defined ns in sing s for every s mapping to y and we define int co of sub n of y to be the full subcategory inside int co y equal to the same limit over the same index category but now you'll be taking not entire int cos but in co sub s you just limit well take the limit of subcategories and full subcategories and it'll be full subcategory in the limit that means that for each test map like that yeah i take the subcategory there and one can again ask the same treacherous question is it true that the category is compactly generated and the answer is b double prime sometimes you always have the inclusion one direction and sometimes the category is compactly generated by that in particular it will be true for low cys basically every time you see a global complete intersection that will be true by the way note that this question is a particular case of that question take n to be zero so if we if this was the answer was positive the answer would be here positive as well again we don't know but in most practical applications it's true all right i ran over time and i still haven't finished my program for the first talk


Welcome again to another OpenShift Commons briefing. This time we're going to do some Node.js stuff, and I know you all know that I love Python, but I also love Node. So I'm really thrilled to have the folks from your forum here coming and talking about their experience with OpenShift and using Minishift specifically on creating the development of OpenShift. So I'm looking forward to this and getting some interesting information on what their adventure was, getting it all to work. So Connor Neal is with us, Dara Hayes is with us, Connor is going to introduce who their form is, and Dara is going to do some neat guys, and I'm looking forward to seeing you. Right in. Thanks, Diane. Hi, everyone. So just before we get into the meat of the talk that Dara is going to cover, I'll just kind of introduce the two of us and talk a little bit about Neerform. So Dara is one of our DevOps engineers and he's done a lot of different projects for kind of customers around the world, Europe and the US. I'm actually Chief Product Officer with Neerform and not long with the company. Previously, I was with Red Hat Mobile for any Red Hatters watching this video. I'll tell you a little bit about the company. It was set up only in 2011 and unusually it's based in a kind of tiny little seaside town called Tremor in the southeast of Ireland. And weirdly, this little bit of Ireland is probably node central for most of Europe between all of the node people in Neerform and the guys in Red Hat Mobile as well. So just one of those interesting little quirks of geography. The company itself, it's a little over 100 people but they're spread around the world. It's a very, very distributed organization and really the bulk of what we do is build full stack solutions for large organizations. So a huge amount of what we do is professional services and we work with companies. You'd know people like Condé Nast, McKinsey Consulting, ADP. So I think pretty much every person in the US who gets a paycheck has ADP printed on it and while all the projects that we work on are unique and specific to customers, what we do see is a strong commonality in the tech stack that we've been using kind of recent years. So that's very much things like react on the front end, node on the back end, happy as the kind of web framework, obviously deploying into things like AWS and then using tools like Terraform and Ansible and then kind of getting closer to what we're going to be talking about today, a big focus on containers, whether that's Docker, Kubernetes and as we'll talk about here, OpenShift. But on the other side of what we do, we're heavily involved in the open source, various open source communities, but particularly the node community. We're major contributors to Node Core and in fact, James Snell, who this week just landed HTTP to support or early HTTP to support in Node Core is the technical steering committee director. And finally, that was the other thing we're very well known for our conferences, particularly NodeCon for you, which is sort of the European version of NodeCon. So that's going to be held this year in Tecani in Ireland in November and is sort of one of the highlights of the Node conference season, shall we say. Now on to the briefing itself before I just hand over to Dara. It came about because of a relatively new initiative that we've kicked off inside NearForm. So what we've done is we put together this floating team. They work very much like kind of pathfinders, trying out new tools and technologies. And the idea is people come in and out usually just for a couple of weeks and work in areas where that we're interested in learning more about, talking more about, letting people know what we do and just kind of general communications. It's totally sprint based, so it's once a week. We, you know, everything's done in blocks of a week. You have a demo and a deliverable at the end of every week. And, you know, the work can vary anything from evaluating your DevOps tools. Try it, for example, one of the things working on now is trying out different approaches to some of the React tooling. And really then that knowledge is distributed internally and then externally via blog posts and obviously webinars like this. And what Dara is going to talk about is one of those types of projects that have been done over the space of several weeks by him and several others in the NearForm team. So I'll hand over to Dara now and he'll talk about the nuts and bolts of the session. Right. Thanks very much for that, Connor. It's a great intro. And also thanks everybody for taking the time to listen to us today. My name is Dara Hayes. And as Connor was talking about that sort of working group that we have that kind of does this researchy kind of stuff, one of the things that we did was looked at Minishift and tried to figure out how can we make Minishift into a development environment? That's actually pretty useful for Node.js. And so before I jump into the specifics, I just wanted to talk a little bit about, you know, NearForm's experience with container technologies. So we've been working with Docker for like three years. So we've been using it since Docker was quite young. And back in those days, we did loads of crazy work trying to build like custom tools to deploy Docker. And yeah, they were like the dark ages. But in more recent times, like we're starting to look at Kubernetes quite a lot. We've got a number of people at NearForm now that have real expert knowledge in Kubernetes. We've got a Google developer expert on the subject. And I suppose naturally out of that, we're starting to become interested in OpenShift as a product. So this was just one of the initiatives that we sort of came up with. And so just in case anyone's not familiar with what Minishift is, it's a tool that helps you run all of OpenShift in a single virtual machine on your laptop. So it's a really nice way to get familiar with OpenShift for free. And it's pretty much compatible with, you know, any operating system.  So, you know, it was originally a fork of Minikube. But it really is its own project now with its own community. And so that's what we started looking at. Right. And why did, you know, as a company, why are we getting interested in Minishift and in OpenShift? I suppose, as I said, we have a lot of customers already that are using Kubernetes and we've been speaking with a lot of potential customers as well. And there's, you know, there's a growing interest in OpenShift and, you know, how that can potentially solve their problems. And then again, as Connor said, we kind of do these initiatives to help scale up some people, you know, in our company and help increase awareness of some of the stuff that we're looking at. And then this last point here, like a technical reason for looking at Minishift, we're really interested in this idea of how your dev environment could be really similar to your production environment. So like the idea of running, you know, a full-fledged installation of OpenShift on your local machine where it would be really similar to the way it would be running production, like, you know, in terms of the build process and the deployments and even just the sort of files that we use to define our system, all that kind of, all those resources. The idea that, you know, that could be really similar to our production environment was really interesting to us. So we wanted to investigate that, I suppose. And yeah, so to us, there are a couple of things that actually make a good development environment.  And the first thing really is if you're new to a project, like it should be really easy or it should be relatively easy to get, you know, that software up and running pretty quickly for the first time, right? It shouldn't be a hassle. Like it should be pretty pain-free to get your software running for the first time locally and then to be able to make changes to it. So time to first code. And then on top of that, once you can start making changes to that code, those changes should be reflected instantly. So this was a really big challenge with OpenShift because it's got full-fledged build and deploy cycles. And we wanted to figure out how we can make those changes that we make locally more instant in a running instance of OpenShift. And then lastly, again, on the idea of having your dev environment similar to production, this kind of idea of production parity is really interesting to us. So what we did was we looked at Minishift and tried to figure out how can we have this environment where we looked at it and we tried to focus on the instant feedback loops particularly because we wanted to solve the problem of how can we make changes to our code locally and have them reflected in OpenShift instantly? Because by default, you know, there's a whole build and deploy process that actually takes quite a bit of time. And the end result of our work was this little demo project here where we have a little server running and it just gives you this Hello World message. We can go in and change the code and hit Save. And in our running instance of Minishift or OpenShift, that's reflected instantly. So I hope everyone saw that. I'll leave it play again just in case. And this little five-second GIF here, like the result that you're seeing here actually took quite a bit of work, right, to get to that stage, right? So we've got a little repo here. It's near form for Minishift demo. If you want to go and take a look, you know, and follow along that way, you know, you're totally welcome to do that or you can just sit back and relax and enjoy while I talk about it. So as I said, it took a bit of work. There were a few pieces of the puzzle to get to that solution that I just showed you there. And I'd like to talk about those few bits to take you on like a story of how we got there. So the whole strategy really kind of revolves around using volumes. Anyone that's used Docker compose as a development tool will probably like knows exactly where this is going. The whole idea was that we would get around the build process in OpenShift by mounting the local code directly into a running container. So the idea is that any changes we make locally are already reflected inside the running container. So these are just two small little snippets taken from the file that defines their system. And what we're doing is defining a volume at this folder, which is where, you know, our app lives and it's what's called a hostpad volume. And a hostpad volume is this concept in OpenShift that lets you mount folders on the underlying host that the container runs on. So the result of that is, is we can avoid rebuilding a container when code changes because those changes are already there inside the code or yeah, inside the container. So once we have that, all we need to do is figure out how to do some sort of instant reload inside the running container, right? So we're primarily node, like we're all nodes. So at Neoform, so like we just use this tool that's really popular in the Node community, Nodemon. It's just a simple utility to restart your app whenever changes are made. And what we did was we added Nodemon as a dependency to the app and just added this extra start command that runs the app with Nodemon as opposed to standard node. And then in the spec for the container, we just override the default Docker run command with the new command. So the result of that is the application can restart within a running container whenever changes are made. So to recap, the code is mounted into a running container and we can use Nodemon then to detect any changes when they're made. And that by itself, those two elements really makes up the majority of the actual solution. But there were a couple of snags that we ran into, like a couple of challenges that made this a little bit more difficult. And so I'm just gonna talk about those a little bit. So the first one was permissions. In OpenShift by default, that hostpad volumes feature won't work because your containers don't have access to the underlying file system. And like that makes total sense in a normal real life OpenShift kind of context, but not so much in a development environment. So the OpenShift security model is built around these things called security context constraints. And what they are is these sort of policies that define permissions. And then those policies are attached to service accounts or to users accounts, that kind of thing. And then the other side of it then is a service account. There is a service account associated with all the components in OpenShift. So like the builder, the registry, the deployer and indeed your own containers that you run all run under a service account. And by default, the service account doesn't have a lot of permissions. So luckily there are some baked in permissions already that we can use. So if I just log in here and I can show you. So we're just gonna log in as the admin user. What I'm gonna do first is OCE get a service account. We can see some service accounts here that are created. So like this default service account is what your containers will run with. And then you can do OCE get SCC. This is gonna give me a bunch of different, you know, pre-made policy objects that exist that we can attach to service accounts and to users and stuff. So what we added simply is the host access one and that gives your container. That will, the effect of that is, is that your containers now have access to the file system. So that's just one little thing that you have to do extra. And, you know, it took us a little bit of kind of searching around to figure that out. So then I guess with the volumes, the instant reload and the appropriate permissions, you're in 99% of the way there. And it was only when we showed off our work to another colleague, he came back to us and he told us, there's one more issue that we completely hadn't even thought of. It never occurred to us, but it was to do with native dependencies in Node. So our strategy of mounting your entire local code into the container doesn't really work if you're because of native dependencies. So like, if you mount all your code, including your Node modules, if you're running OSX and that code gets mounted into a Linux container, then any native dependencies are gonna break because they're compiled for the wrong platform.  So if anyone has any suggestions for a better way, I would be so happy to hear those suggestions, but what we did was we installed the Node modules outside of the application folder in the Docker image. And then we just link to those Node modules. So I can just show you what the Docker file looks like. We've got two folders here, bin and lib. In bin, that's where the app is gonna be. And then this lib folder is where the external Node modules folder is going to be. Copy the package.json in there and then we can run npm install. So what that gives us is dependencies in another folder. And then we can use this Node path environment variable and pass in that directory. And what that does is when Node is running, it reads that environment variable and if there's anything there, it knows to also search in this folder for dependencies as well as the other default ones. And then lastly, we've just added this folder here to the path and what this guy does is any like binaries and CLI tools that you've installed as part of the application dependencies will be available on your path. So like Nodemon, for example, you can use Nodemon now because of this. And so it's kind of hacky, like I'll admit. I'd love if there was a better way to do it and maybe there is. But the result of that is that the native dependencies are compiled for the right platform. They're just in another folder. So when we mount in the other code, they're still there.  So that's the one kind of trade-off that you have to live with. I suppose it's not too bad though because as a project matures, your dependencies won't change a whole lot. So yeah, that's all of the elements of how we got it to work. And now I might as well just show you the demo because you'll get a much better understanding, I think. Right, so if we start off with our Hello server, our Hello server is the piece of software that we used to demonstrate this whole thing. It was the guy that you saw on the GIF.  It's built with this framework called Restify, which is just a really minimalistic sort of web framework. And we've got a couple of endpoints. So our root endpoint just sends back this Hello world message. We've got a health check. So OpenShift checks, health checks to make sure your service is available. And then one thing we've done here is we've got this additional health check which uses something called LevelDB, which is like a, it's a database, just a file-based database. But the reason we're using this is because it's actually the Level module is a native dependency. So we just have Level in there just to prove that the native dependencies are actually working as we want them to work. So that's why that's there. So this endpoint will just cause Level to save some data in a database. So we can just tell that the dependencies are working. And then that's the Docker file that I showed you in the slides a second ago. So that's the server. And then what we have is this one file, this manifest file. This manifest file specifies all the objects required to actually get the software to run within our OpenShift cluster. For anyone that's not familiar with this, it's really similar to the way you define objects in Kubernetes. But there's just a couple of extra features. So for example, this file here is what's known as a template file. And what that does is it allows you to pass in parameters and then that renders the file with those parameters. And you can pass in like default values and stuff as well, which is kind of cool. So we've got a couple of parameters here like naming, memory limits, health checks, some environment variables, that kind of thing. And then what we have then is the actual objects. So I can't go into massive detail because about like all the Kubernetes and the OpenShift concepts because that would be a talk in itself, but I'll just brush over it really quickly. So what we have is a build config which defines how we build the application. So what it looks for is, you know, a source to build the application from a strategy of some sort. So we're using Docker and then somewhere to put, you know, the resulting build. So in our case, we're gonna build a Docker image and we're gonna publish it to an image stream tag, which is essentially the OpenShift sort of abstraction for our Docker registry, right? And then what we have is a service. So a service just groups all of our running instances of an application together and exposes them under a single name and it low balances requests to those. Now a service only exposes your application internally within a cluster. So then we use what's called a root, which will create like a publicly accessible endpoint from which we can access the application. And then lastly, we have this big object here called a deployment config.  So that's really the biggest one to understand. Now, as I said, I'm not gonna go massive into detail on that, but I definitely encourage if you're interested in doing this, definitely encourage just to go take a look at it in our repo and definitely re-true the OpenShift documentation because it'll really help you understand what's going on. The OpenShift documentation is actually really good. So that's the manifest, I guess, file that describes the whole system. And then what we have is just a single script that will help us get everything up and running. So this script, it's just a little batch script. And what it does is it does that permission stuff for us that I mentioned earlier. It just adds additional permissions to our default service account for our particular project. It creates a project or a namespace under which all those resources are going to be created. And then it uses this OC process command, which would take the template file and render it with some parameters that we're passing in. And what it does is that just logs the rendered version of that file out to the console, which can be piped into a create command, which will go and create the resources. And then lastly, we've just got a start build command, which is going to tell OpenShift to kick off the first build and we're passing in path to our hello server code. So what I'm going to do is I'm going to go to my terminal. I'm going to, just in case I have the project already running, I'm going to delete it. I'd say I don't have it running, but just in case, I'd like to do it from scratch. All right, so it looks like it's not there. So I'm going to log in. Hello server, just make sure, right? So yeah, so we've got a nice clean slate to start from. So I'm going to get going now, right? So we've got the scripts folder here, which contains that script. So we're going to run that script to create projects. That's going to apply the correct permissions, create a project for us, and then it's going to go and create those resources within OpenShift. And then it's going to kick off the first build. And when that build is complete, that's going to trigger the deployment of our software. So the first build is obviously going to take some time because it's going to go through an entire Docker build process, going to install all the MPM dependencies, that kind of thing. But after that, we shouldn't have to rebuild the whole lot unless we've wanted to change dependencies. So yeah, I'm going to leave that run right now. And does anyone have any questions so far? Are we all good? Chris, there's one hand in the chat and I've got an echo going. I'll let you read the chat. Chris, thanks very much for your suggestion. I'll definitely take a look. Yeah, one thing we didn't look at because I guess to just as a response to Chris's link as well, that's a great suggestion. I suppose because of our strategy of trying to avoid doing builds, I guess we didn't look at the CEI tools and the Jenkins kind of side of thing as much as we could have. So yeah, that's just the order. We should have looked at it, but our strategy kind of involved avoiding building as much as possible, I guess. And so as a result, we didn't get to look at that, the Jenkins stuff as much as we should have. But if it can help, that would be great, definitely. So that's still running. In the meantime, I can actually open up the console, I suppose. So, sorry, one sec. I can open up the mini-shift console and just kind of look at it, mini-shift. It's just a handy little command to open it in the browser. So this is the project that we've just created. My machine is starting to get angry now doing a video call and running mini-shift at the same time. So we can see here, we've got a root. So this is the endpoint that our application will be available at. We can actually see the build is running. So we can go in and take a look. And that's just gonna show us the list of builds. So we can go into this build and we'll be able to see the log of exactly what we're seeing in the console at the same time. You get the point. There's no point in waiting for that to load. But what else can I show you real quick? Sorry, my machine is getting a little bit slow now. But right, so the build is complete and now our first deployment is running. So we can just go in and take a look at the deployment config just to show what that looks like. We can see the command here, the start dev command. We can see the image and see the build it's related to. It's actually running now as well. One thing that I should mention just real quick as well. So we've got the app volume. That's the volume where our local code is mounted. Got this level DB volume, which just creates an empty volume where level DB can write information to. You've got this empty node modules volume and what that does is because we're mounting our entire application code, the node modules folder within the application folder itself is still actually being mounted as well. And node will always take preference for that as opposed to any other ones that you've specified through that node path environment variable. So what we've done as a little hack is just to put an empty volume in the default folder so that it won't see anything there. And then lastly, we have this little volume here. So apparently node man needs a file called config for it to work. So we had to create a file there for it to be able to write to.  That's what they are. So now we can see in the logs, we can see that our server is running. We go back here. We can access our server. So hello world, right?  It's save. We hit refresh. There it is. So we have successfully gotten instant feedback working, right? And it's pretty nice. And if we just go in and take a look at the application again, go down into the running pod and just look at the logs. You can see, you know, node man did its job. It restarted the application. So that's pretty cool. And that's, you know, that's kind of the main thing we worked on. And that's what you'll see in the master branch of the repo, right? But just for this demo or for this talk today, I've actually gone and done some additional work. It hasn't been merged to master yet on the mini shift demo repo, but it's still like to show it to you because I think it's interesting. It expands on what we've done here. So having a hello world server is pretty good, but by itself, you know, it's not that meaningful. So we wanted to do something a little bit more involved. So what I tried to do was to get a database running of some sort and have an application that can connect to a database. So I'm just going to go and show that to you guys. So if I go back into where I was here, if I check out my other branch, I have Postgres. Now if I come back to my editor, what I have now is two new files, as well as the original mini shift demo file. We have two new guys here. We have a Postgres file, which defines some objects to get Postgres up and running. What we did was we got Postgres running from the default Postgres image from the public Docker registry. So we didn't use like an open shift or a Red Hat specific version of the Postgres Docker image. We just wanted to use the vanilla one. So there was a bit of work there. But what we have is this persistent volume claim, which defines like some storage. That will outlive any running container. And then we've got some stuff here to define where the image comes from. And we've got the service and the deployment config very similar to the other manifest, but it's going to run Postgres. And then also what we have is this guy called Users API. So the application is a users API that connects into Postgres. And just, you know, you can list users, create users, et cetera. And so the kind of the manifest file for that is really, really similar to the mini shift demo one. The only difference is just to make things quicker. I was a little bit lazy and I don't have the code included in the repo. I have it elsewhere in my own Git repo. And so instead of building from a source, we're building from a Git. Or instead of building a binary source, we're building a Git source instead. So that's a really nice feature of OpenShift actually is to just run an application straight from a Git repository. And you just tell it Docker. And I've got a specific Docker file here as well, like a different name on that Docker file within the repo. So I'm just going to get those up and running. The first thing I'll do is create Postgres stuff. So let me see. Let's see, create Postgres. That's going to go off and create Postgres. I'll just show that real quick in the console. So Postgres is, we can see this stuff here. And now it's going to start a deployment of Postgres and that should be off any minute now. And now in the meantime, we're going to go and create the application. So I have one tiny other little script here that will just create the application kind of in the same way as the other one. This script is a little bit different from the other one. So they just kind of prove it together real quick, but we've gone up and down to create it and to delete it. So if we just scripts that's user's API up, that's going to go create those objects. So now we can see this user's API guy is starting. What that's going to do is, as part of the build process, it's going to clone down the code from the Git repo and then it's going to start running the Docker build. So those guys are deploying. Should just take a couple of minutes. Again, I'll just check. Does anyone have questions or anything? We're all good. I think we're all good. We're all good. Yeah, we're all good. What I can do is just group these together just to make them a little bit easier to, yeah, my machine is really, really coming on fire now between the call and everything, acting a lot slower than usual. Let me see. I've turned off your video. I think you have your speaker on. Let me just check in here and see the log. Can you see my screen still? Yeah, yeah. So you can see it's being a bit slow, but it's now, it's after cloning the repo and it's just going through the sort of standard build. Yeah, my machine is getting quite slow now. Apologies about this. I might just have to skip past it. We'll give it another second. It's after totally freezing on me now. Yeah, I agree with you, Diane. It is a cool environment for learning node and it's definitely a really cool environment for just learning about OpenShift as well and about how deployments sort of work and the kind of Kubernetes and the OpenShift concepts that are involved. So it's a really nice way to bring those concepts to the local environment, I suppose. And that's kind of cool because then it gets to, like if you've got developers and you've got ops people, it sort of gets the developers thinking along the same lines as the ops people and it gets kind of, at least I would think that it hopefully kind of reduces friction between those teams because we're kind of breaking down the barriers between them. In my own experience, I've kind of found sometimes the developers really don't care about how the ops people get the software running in real life. They just want to be able to run it locally. So it's kind of cool that we have this possibility of an environment, a local environment that's really similar to a production environment. It's, yeah, look, it's being very slow. So I'm actually going to just stop it now. You get the idea, like at the end, you'll be able to access an application that's reading data from Postgres and you can like kill Postgres and bring it back up and the data will still be there. And it's, yeah, it's pretty nice but I'm going to skip pass it now because it's just being too slow. So what I'm going to do is just completely delete the whole thing. We'll see you delete that. I should hopefully free up my machine a little bit. The fans are already after getting quieter. But, yeah, all right. So that's the demo. I'm sorry that the other guy, the other pieced it and really work. I would love if you go check it out, though. You know, it's got a lot of stuff there to look at. And, you know, when we went and did this for the first time, there wasn't a whole lot of material we could actually find online to help us. It was essentially a case of going through all the OpenShift documentation, which is really good but also very extensive and trying to figure out how we can adapt, you know, adapt it to a development environment. Yeah. So if anyone's interested in, you know, trying this out, you know, hopefully some of this can give you ideas as to how you could do it yourselves, you know? So that's the demo. And then this is kind of funny, actually, this idea of what about scaling? One of our colleagues asked us after we demoed this for the first time internally, he said, yeah, how many services can you run?  But there is a way to scale it with some tweaks and we did manage on a single machine to get it up to about 40 or 50. You know, the results vary depending on your machine. I was able to get it up to 40. I have some colleagues that got it up to 50 and even more. So, you know, it has the potential to run quite a lot of services. And I think, you know, if you try to run 50 services on any kind of development environment, you're definitely pushing the limit anyway. So for sure. But just if you're interested, you can run this command OC describe node.  And it'll also give you a figure of how many pods it will actually allow you to run. And by increasing the memory and the CPUs, that will go up. And on top of that, then you can kind of put restrictions in place on the individual containers. Like you can limit the amount of memory that they'll use. And that should be able to help you kind of scale up a little bit more. So, I guess some of the conclusions coming out of it is it does have the potential to be a great development environment. When we first set out to do this, I was a little bit skeptical because the idea of running a virtual machine was a bit crazy to me. But after having a bit of experience with it, I think it is definitely good. It has a really nice UI and like experience. The CLI tool as well is just fantastic. The OpenShift CLI tool. I spoke about this a little bit. I really liked the idea that if we have people using MiniShift as a development environment, you have your people thinking in terms of OpenShift and in terms of deployment and in terms of all those concepts that are there. And I think that that would definitely enable us to break down barriers between Dev and Ops people because you have them thinking on the same page almost, right? So I really liked that idea.  Like the idea that you could have just this one MiniShift installation where you could have potentially have multiple projects going on in there at the same time. And it just becomes this one kind of unified place where you can manage all of your different software projects at the same time. I really liked that idea. I don't know how close we are to actually having it, right? But I really liked the idea. So it definitely has a lot of advantages and it's a really nice tool. But it's not perfect, obviously. There are some issues with it, even you've seen today. It uses quite a lot of resources on your machine. It takes up a lot of battery as well. It drains the battery very quickly. And then there's some more kind of higher level questions and work that still needs to be done. So for example, I just showed you today a single code base and it was a very small code base too, but how would we organize this if we had multiple code bases for one project? So say if we had a project that had 10 microservices, how do we structure our repos to facilitate a MiniShift development environment? And so that's one question we need to ask and we need to figure out. And then the next one would be if we were to have this sort of universal Dev environment, how would we actually coordinate that across multiple projects? And then the other question is, can we turn it into a general solution? So what I mean by that is, I showed you guys some like manifest files today and some scripts to get it all up and running, but they are kind of specific to the one project and they're kind of, they're not perfect either. They're just enough to get the job done, but is there a way we can make those better and use them across projects as well? If we had just a single tool that can help us get a project running in MiniShift, that kind of thing, that would be really nice. And then lastly, what is the pathway from going to a local OpenShift to a production OpenShift? That's a really big question for us, particularly at NearForm. We're actually, we're still very new to OpenShift, but we're actually doing a lot of work now in getting OpenShift up and running and then actually trying to figure out those pathways and hopefully we'll have content on that soon. It is work that we're actively pursuing. So those are some of the questions that still are left on answer for now. We don't have all the answers yet. And the other thing is I'm very aware that there are people listening here today that probably have a lot of knowledge around OpenShift and you'll be really, really happy to hear your suggestions and to hear your contributions if you have any because we've shown you something today, but it can definitely be improved. And if anyone has those suggestions, that would be really good. But once again, that's the link. Do check it out if you're interested. Even just leave some issues or just get in touch with us and give us your feedback. We would love to get your feedback on it. My name is Dara Hayes. Those are my contact details. If you wanna get in touch with me via email or Twitter, Connor O'Neill's details are there as well. Please feel free to get in touch with us. And thanks very much for listening to me today. I'm really honoured to come here and speak to you guys, right? So thank you very much. Well, thank you very much, Dara. A couple of questions or just actually one. Mostly with your laptop, how much memory does it have? Yeah, my laptop, right. So can you still see my screen? No, not at all. Yeah, yeah. About the snap of the snap. Yeah, can you see my screen there now? Yes. So I'm running an early 2015 Mac with eight gigabytes. So it's definitely nowhere near like top of the line in terms of Macbooks go. I have other colleagues that are running much more powerful machines and they were able to run this much more comfortably. I'm still of mind that I'm still aware and kind of conscious of the fact that it does take up a lot of resources and that's just the downfall of running a virtual machine. But yeah, those are the specs there just so you guys know. Yeah, any other questions? There are no other questions. And I have an echo. So some of the questions that you were asking in your conclusions, there are a lot of answers out there. Some of it are Jacob's base. Some of it may be solved with OpenShift IO on premise. There's a lot of different approaches to solving some of them and we'll probably grab you and another time that we can walk through some of them. I think this has been really interesting for me because it's a great way to get your node set up so that you can be almost production ready very quickly. And this is, I'm gonna be trying out myself shortly. So I'm thrilled that you've done this. And I'll see, I don't see any other questions. So thank you really for taking the time to share all of this and we will post this video on the YouTube channel shortly, probably in the next day or so and a blog with the links back to the NearForm MiniShift demo and some of these resources. And we look forward to hearing more as you venture into using this for production ready node application stacks. Absolutely. Thanks so much for taking the time to listen to me as well. Don't need my second time speaking so I'm really happy to share this with you guys today. You're welcome. Thank you very much. Thanks.