Okay, so let's get this started. So to start off with, if you have not added yourself to the attendees list, please do so. The meeting notes are listed on both on the GitHub page and there's also been posted to the chat window. So welcome to our network service mesh meeting. And so as always, we begin with agenda bashing. So is there anything that anyone would like to discuss that is not on the agenda? I'm gonna take that as a no. So let's jump straight into events then. We have KubeCon EU in Barcelona, Spain. So the call for papers is closed as of January 18th and we have multiple submissions in. March 5th is the notifications and the announcement should occur in March 7th. So KubeCon itself will be held in May 20th through 23rd. So my recommendation for first time conference goers is to book early because those hotels fill up pretty fast. And very often they'll also have accommodations listed that are officially set up between the conference and some of the nearby hotels. We also have a co-located event at KubeCon EU. We have the final mini-summit, which will be on May 20th. The location will be in Barcelona, but the final location in Barcelona is to be determined. And there are no call for papers yet listed as far as I know. We also have Mobile World Congress coming up at the end of February, February 25th through 28th. This tends to be more demos on stands as research provider centric. So the entity use cases are more interesting. If you have a booth there and are willing to showcase Nettbrick Service Mesh, let us know and we'll see what we can do to help you put together something that's successful. We also have the Open Nettbricking Summit ONS North America in San Jose on April 3rd through 5th. The call for papers is also just closed recently. We'll see what the schedule is. And actually the February 5th looks wrong for notifications because we need a little bit more time than that. So I'll double check the dates on that. Yeah, program committees, that's a really aggressive review timeline, especially for something this size. Yeah, they're asking for program committee to actually turn in their time on February 10th. So that's why I'm surprised with the deadline. So I need to check up with them and make sure that they have that correct. We also have FOSDEM, which is also gonna be streamed live on February 2nd and 3rd. And actually is that correct? Sorry, there's FOSDEM streaming and then there's, it looks like there's multiple conferences listed and under, yeah, sorry. Yeah, so we have FOSDEM streaming live on February 2nd and 3rd. We have upper side conferences, NPLS, SEM, MFV in Paris on April 9th through 12th. The deadline was sometime late last year. So, but it'd be interesting if you are conveniently located to check that out. We have Container World 2019 and we actually have a network service talk, network service mesh talk in Container World being put on by Prem from Luma Networks. Yeah, I'm excited about that and yeah, the talk got accepted. Yeah, thanks for bringing in. Cheers. And so we have Service Mesh Day. Call for Paper is going to close on February 8th. This is conveniently located near Mesa. I will definitely be putting on a talk for that. And we have KubeCon in, CloudNativeCon open source summit in China in Shanghai, which will be from June 24th to 26th. So if someone wants to travel to China and bring the word of network service mesh there, then February 15th is your deadline. So are there any announcements that anyone has to make? I should have asked this before. Are there any events that we missed that would be good for the list? Okay, so in that scenario, let's jump into the pull-request template. So Nikolai, you have the floor. Yeah, so quickly. Yeah, we have, I have put this PR where I propose this new template. Yeah, so the final version after the two remarks that I fixed here looks like this. The purpose here is to improve our PR messages and have some better structured and better looking git history. And yeah, that's it. So I suggest that, okay, we don't go into details here now. The PR is, I don't remember the number, but it's there, the link is there. So if someone has any objections, ideas, suggestions, just put them in the PR and then we will do merge it in a couple of days if nothing major shows up. Yeah. So I mean, one of the nice things about a PR template like this is it kind of makes you think about things, right? So like, I can't tell you how many times I have pushed a PR where I probably should have changed documentation. And if someone just said, have you changed the documentation like we do in the checklist, I probably would have. So it moves some of these things front and center. Okay. So the other thing that I wanted to quickly, just kind of update in form, announce was about, we had a quick chat with it and so I have proposed this a long time ago to start having a separate examples repo. So I have something going on this PR, which I call proxy NSC, which is essentially a HTTP proxy, which also has an SC on the other side. So I will start by trying to push this example in this new repo and then we can share it and see how it works. So it integrates with the main repo, how the integration testing can be done and all these things. So this is kind of where, what is going to happen in the next days, I hope. So maybe by next Tuesday, we will have this new repo and with some initial feeling of how it looks like to have a separate examples. Cool. That's it. If folks have comments on any of that or questions. So does that mean we're extracting out the examples directory in their network service mesh to its own repository or is this something that's new? So for the first initial version, it will be just the new examples that I am, I have a new example and I will just put it in a separate repo and see how this works. And if this goes well, we can discuss if we want to move some of the already existing things there or we should keep part of them in the current repo. But at least I think that for the future, all the new things that we want to do probably should go in this new repo. I mean, new things, meaning new examples, new use cases. Yeah. Yeah, so it'll take a little time and there'll be a little bit of adaption because among other things, we're going to figure out the CI as we move the examples. Yeah. It gives us a place for them to live. All right, so let's go over the... Or is there anything more that we want to say on this or should we move on to the specifications board? I'm fine on my side. If someone here's any comments. All right, so there is a brand new board that go ahead and open it up. And so the purpose of this board is to start tracking, to start to make it easy to find what discussions are going on within Network Service Mesh in relation to architectural changes or specifying new features or to also be a place for the community to ask for help on revealing things that the community may want to do. So for example, if you take a look at the spec in progress and if you click on that spec, so this is attached to an issue and on the right, you see a Google document that's embedded in. So the short description of what it is and there's a Google document. And inside of this Google document is where we can discuss what that specific feature is. Now, the reason it's a Google document and not being discussed directly within the issue at this point is that the Google document is a bit easier for people to collaborate with and look at things in a long format without having to worry about markdown or worry about how GitHub. So GitHub is not really optimal in this space, but what the idea is is that once we have enough feedback here and people are generally happy and we reviewed and we as a community have reviewed it and this is something that the core team wants to incorporate, we will take this document, convert it to markdown and we will then commit this into a to be determined a directory within the network service mesh project that that'll just then. So the idea is that this then becomes part of the documentation of what that specification is and the end result should be a document that the community can then rally around in order to implement new features where it should be very clear not only what the feature is but what is the path to reach that particular feature. And so if there's any changes as we learned during the implementation is as we know, specifications don't always meet reality then the ask is that by that time we'll have the markdown in the GitHub repo and then we can iterate on that for the details. But the main idea is to drive the community towards being able to reach or try to understand to be able to ask questions, poke holes in an easy way. And if you want to get a review of something you're proposing so suppose that you have a firewall network service endpoint that you want to expose or you want to create a network service endpoint that exposes your firewall to be more exact then you could also ask questions in that board create the Google document in the same format the end result though will not be any markdown in the repository because that belongs to a third to a third party project and that project and then decide what to do with that documentation. So are there any questions around that? So some of this quite frankly is an attempt to get a little bit more transparency which I think is good in general.  And so my hope is that we can get these to a place where folks can sort of pick up something like the readiness probes and do that, right? Which would be super helpful because right now our integration tests are doing the only thing they can do which is scraping logs to determine when the NSMD and the VPP agent data plan are up and going. And so there's a lot of little details like this that can be broken into bite-sized chunks that people can work on. Yeah, so our hope is to try to make it as easy as possible for people to contribute and this is also a nod to the fact that some contributions are not necessarily for on the coding side but also on the design side. So for example, if we have something that's related to SR IOV, like I'm pretty sure Ian would have a lot to contribute in that space. And so then that would allow somebody, if Ian does not have the time to implement such a thing, it would help instill that knowledge in somebody who can potentially pick it up. And we do have folks, I know we do have folks like I know Daniel, you're super interested in getting the SR IOV, sorry, not the SR IOV, the SRV-6 remote mechanism in. And quite honestly, I know you're super busy, you're not gonna have time to code that yourself. But if we can get that worked up as a spec that somebody can follow who wants to go write code, that gets to be super easier for people to pick up and get done. And I think the same thing holds for some of the stuff, Jeffrey, I know you care a lot about MPLS. And although I think you're a little more prone to write code than Daniel is, but you're probably wondering where do you start, right? And so we could help shake some of that out as well. Does that make sense to folks, especially the folks in the community who are looking to pick up a shovel and write some code? Makes sense to me. And then OGSI, you've something to pick up and work on as well. And hopefully some of these are things that you'd be comfortable with. Yeah, absolutely, because so basically, now there's one thing I wanna ask a quick question is that actually, so now we are discussing about adding those as RV6 or something like that. So what we are planning to do is that we're gonna, like say to implement those like VNF functions, or basically we just like encapsulate those things and try to route things to our app pod. So I'm still a little confused about that part. Yeah, so there are sort of two sets of things here, right? The things that are within the purview of network service mesh are that you want to remote mechanism, basically an end cap to get from A to B, right? Thing to carry all two or all three payload. That's the stuff that network service mesh deals with. So when we say something like SRV6, we're actually talking about a super simple, almost stupidly simple thing in network service mesh where instead of using the excellent to carry your packet or frame from a client to a network service endpoint, you could use a SRV6 or you could use MPLS over Ethernet, UDP, GRE, whatever they in that next, right? So these are all within the purview of network service mesh. Now, there's a ton of interesting stuff that somebody might write into a network service endpoint for a CNF that does much more complicated things with MPLS or SRV6 than we're ever going to do. And part of what I think Frederick intended with this specification process was say you wanted to write a network service endpoint that did some complicated MPLS thing. Then you, in that case, you might have, you might say, okay, well, I know that I want to do this thing and I actually want to do this thing over here in my own repo, but it would be good to get advice from the network service mesh community on what they think might be an optimal way to do it. And this gives you a venue in which to go and actually start that conversation and basically say, look, I'm building some complicated SRV6 network service endpoint. I'd like some advice about how to make that work optimally with network service mesh.  So if you don't feel comfortable or you don't want to or you feel you already understand what's going on, then you don't have to post here. So it's not a gate. It's something where people can ask for advice like I'm a newcomer or I have some complicated thing and I want to make sure that I'm thinking of this in the right way. So I would like feedback, here's my stuff. Yeah, I personally not at all a fan of hard gates. I think they end up being problematic but I'm a super big fan of transparency and I'm a super big fan of having a well-defined venue for people to get advice if they want it. Hey, Ed, could I ask a quick question? Just I've been trying to like wrap my mind around like network service endpoint versus just, you know, NSM in general and stuff. And so when we talk about wanting to do something interesting with like say SRV6 or MPLS, et cetera, where I get a little bit like fuzzy on like where the network service endpoint lives versus, you know, just the data plane that I bring to the picture, whether it's SRV or VPP, whatever. Am I writing my network service endpoint to call and configure say potentially like VPP so that way I've got some intelligence living inside of this network service endpoint that this then programming my data plane or is VPP living inside of this network service endpoint and then I'm actually just hard coding in this functionality into that network service endpoint itself. Yeah, so generally speaking, your network service endpoints would bring their own data plane whether that's VPP or something else. So say for example, that I, you want to go right and Daniel I'm gonna embarrass myself here so be kind that I wanted to write an SRV6 network service endpoint that did some complicated routing on SRV6 headers, right? So it understood a lot about them and I was pushing information into it about my physical network because I wanted particular SRV6 headers added to my payload, right? So a packet comes out of a client and I want payload to have SRV6 headers not the thing that gets it to the network service endpoint. In that case, one way to approach this would be to write the network service endpoint and the SDK is super helpful for this by the way and my network service endpoint would have its own VPP that processes the packets when they get delivered and does whatever the more complicated network behavior is. Network service mesh is only about I think network service mesh is managing virtual wires between things, right? And so you get one end that plugs into the client you get another end that plugs into the network service endpoint once that packet arrives at the network service endpoint then you have all kinds of interesting processing you could do with it. There is literally no end to the creativity of network people in this dimension. Got it, so really I'm just gonna set up my service chain then, right? And then that network service endpoint is where once I wanted to leave this cluster this is the final end cap that I'm gonna stick on this. Or any number of those. Yeah maybe I can explain it a way as in the next instance I don't wanna burn a network service mesh call on segment routing V6 but one notion of segment routing V6 is the service programming aspect. So you create a mesh of services to address the function you wanna create and you assign them using local fields or IPv6 addresses. So if you look at this if I can create a mesh of services using IPv6 addresses using SRV6 but I still need to program the control to make it happen so where an SM comes in it's easy to say I wanna create a mesh so that the workloads know what to request and what to get. And then I can translate that back into SRV6 at end point so I know how to data plane to make it stick together. So I get the kind of a control plane for what the service discovery and how to mesh those services together. So there's a really a good tie in service programming versus the network service mesh. That explains a bit better. No, that's absolutely exactly what I would expect. And so does that answer your question, Jeffrey? It does, I just, but reading through the documentation and stuff it's been a little bit fuzzy on me like kind of where the actual like CNF logic lives like if it lives in that end point or if the endpoint is just some dumb forwarding plane that I'm stacking services behind and then using an SM to stitch it to it and that kind of clears it up for me. Yeah, would you be willing to help at least start some documentation that might make that clearer? Because if you're having that confusion lots of other people are and it's super helpful as people figure things out if we can get documentation on it because you will not be the last one to have this question. Yeah, no, I think that would be good. Like, and I'm definitely willing to help with that. Just have some of you smarter people kind of make sure that my information is correct I would agree like, the gets great but like when I go there and I'm reading about Sarah and her story book adventures and stuff like if you really wanna start building this out in your lab and you're coming in from just ground zero there is definitely like an exponential climb that you have to make before you hit that plateau and things start to make sense. Yeah, and we really wanna make that easier and you have an advantage right now that the Buddhist refer to as beginner's mind and that's a super helpful advantage in these scenarios. Yes, so guys just one thing, just wanna clear it. So actually the NSM plays the roles of wiring between does it connects between like say the first part the app part to some certain VNFs or to actually connects between those VNFs? Like say, just to... They can actually do both, right? Oh, okay, cool. If you connect your client to AVNF or CNF in this case, Cloud Native Interfunction or even a VNF that's writing outside of a cluster because network service mesh can actually interoperate with VMS and physical networks, right? So it connects your client to a CNF or VNF and then but it can also connect to CNF or VNF as part of a chain to another CNF or VNF and so you can build out in a sort of Cloud Native policy based way super complicated graphs of CNFs if you want and network service mesh will dutifully provide the virtual wires to connect them point to point to each other and then inside those CNFs that you're building what we call the network service endpoints you would then have whatever it is you're going to do to the package and there's an infinite variety of those things you might choose to do to the package. That's much clearer, thanks so much. So we see really good question to have raised. So something that I would like to do as well in regards to the architecture is if you think about this documentation and this in this way, the documentation it's the spec itself is also documentation and vice versa. So what I would suggest is we start to specify more formally specified what network service mesh is through the specifications board as well we just happen to have running code but this also gives us the opportunity where to work out like not only where things are but also to fill in any holes that we have because we can always change the code to match the specification if we have any design changes that occur. So what I'll start to do is I'll start with some of the more simple use cases and we'll say what does it mean to be an NSC what is the relationship between an NSC and an NSE? And I think if we start off with those and progressively work our way up the chain we'll get down to like what does it mean to be a remote mechanism? What does it mean to be a data plane and so on? So I think we can drive that documentation through the same board and the end result is marked down as because it's exactly the same process and that would give us the ability to discuss like does this wording make sense? Do we need to specify this out more or is this too complex or so on? So I think this would be a good way. So would you be willing to help participate in that style of discussion? I would say the only other piece of that, Frederick, is both overarching like spec for this and those individual components, right? Like I think when I go to the git right now and I'm reading through things, I mean, I kind of piece it together in my mind, reading through Sarah's adventure. But I think, especially when you guys move away from the technical community and all these different vendors start trying to productize this and put it in front of executives is fundamentally there needs to just be like network people because this is who we're kind of catering to. We like pictures with circles and squares and lines connecting them, right? Like having blocks.  I mean, once again, we like the OSI model, right? Like I mean, when we start talking about like making this consumable by the network people because once this gets more mature, less and less code focused people are gonna use this and more and more like network consumers are gonna take this and they're gonna go and just grab a network service endpoint. So there needs to be like very clear like representation of all the individual components and then how all those Lego pieces fit together as far as the documentation goes. So once really smart people like you have like written 80% of the code and it's like in some usable format, some end consumer can go and say, I'm gonna grab these Lego pieces. This is how they fit together and I'm just gonna put this into my network. Yeah, that's excellent advice. So one, that sounds like correct. One of the things I would strongly, strongly, strongly suggest to you guys as you dig into this. You've got folks like Fredrick and Nikolai and myself and others on the NSM IRC channel all hours of the day and night. So don't hesitate, jump on the IRC channel, focus and say, this part is confusing to me. Could you help me understand? Cause we would be delighted to do that. True. I don't know if the line is right word. So there's something above delighted. It's not strong enough. So yeah, so I think what I'll do then is for the documentation of specifying what's there, perhaps what we should do then is not start off with an individual component, but we start off with a high level. These are the major components and we can set them up as like the overarching document that you can say, what is network service mesh? And if you wanna drill down, then you can click on the link and then it'll say, well, what does that in this, what does that network service clients really do? You then you can drill down on a network service client. And then see the relationship and talk about the interactions. Are you familiar with model based systems engineering? I was a very long time ago. I can refresh myself on it. I mean, it's not something we have to employ, but just something like that concept, right? Like, like what you were just describing is we basically need like a high level architecture document, right? That you can put in front of people to say, you know, this is what an SM is like, like I said, I'm gonna keep picking on Sarah because I've read her like four times trying to puzzle this out in my mind. And like Sarah is really good at explaining to me, you know, how NSM might make my life easier, but then like when I'm ready to take that next step, like, you know, I've only just got these very vaguely abstract associations in my mind on like what NSM is versus what the demon is versus what the end points are, you know, when you start looking at CRDs and Kubernetes, like if we don't have like a sound explanation right off the bat, there's like lots of people who like literally they're tummy drops of their, you know, knees when you, your CRDs. So like saying like, no, this isn't a scary thing, you know, and this is how it fits into all of this, I think.  Like if you want to get all the way to where you've clicked all your into the network service endpoint SDK, then so be it. And if not, you know, you stop it later too, but at least you have conceptually an idea of what problems this is solving and how you might potentially employ it. Yeah, and this is where your contributions are so critical, right? So if you go look at the network service mesh deep dive slides, right? This was my attempt to try and do that. Clearly it's not sufficient for purpose, right?  And that's something that is super easier when you come at the problem for beginners mind. Sure. I'm also interested in that part. So maybe I can help try to figure it out. Since this is also, I mean, during the process of learning to fully understand of what NSM really kind of rose what NSM really plays. Yeah, and it's going to be a progressive thing because the thing with network service mesh is it is unbelievably powerful, right? And so it's the kind of thing that you wrap your head around in layers, right? So like layer one is sort of the Sarah thing. How do you make my life easy, right? And then layer two is okay. So how do you understand how the pieces fit together? Because among the things we could do in network service mesh, even beyond what we've sort of specified for Sarah is network service mesh could be used to request network services from physical networks. So it provides a super easy way for somebody who's just writing a workload to ask for something that may be a super complicated thing that happens in the physical network. It can be used to give you a way to get back to VIMS as well. It can be used with PNSMs to do all kinds of interesting hinting in your physical network. Or even like we've got a spec here for create PNSM, right? We've sort of come to realize, do you guys remember the create verb that we talked about in some of the talks in passing? I do. Yeah, so imagine being able to have a network service endpoint created on demand at the scope that you wanted. You know, maybe you would prefer it to be on the same note as your client. The PNSM lets you do that in a very simple way. And we have done just a terrible job of documenting the space of possibilities and they're super exciting. So if you guys are willing to sort of help sort of do that documentation in progressive layers in a way that makes sense to you, that will make sense to a lot of other people too. Hey, I'm here. So I can also pitch and also I'm preparing few slides for the container world talk where in my intent is essentially to sort of give a one-on-one so that if people are not familiar with service mesh or network service mesh and how all of it plays together. So I can probably work with Jeffrey to define it in fact, when we started we, in fact, created a use case document just to showcase how network service mesh would play out with the use case. Probably we may need to have a simplify it or we can probably relook at it. Yeah. Excellent. So I appreciate you guys being willing to jump in on this. It's super, super important. And as I said, it helps tremendously the work that you're stepping up to do. Sounds good. Yeah. So Jeffrey, I'll probably connect with you and also with others who would be interested. Yeah. Yeah, probably. Yes. Cool. Shall we move on next? Yes. So, Nikolai, you have the floor for the 2019 roadmap brainstorm. And I want to remove myself on that at this point because I've said everything I wanted to. Yeah, okay. So I don't think that we had anything added since the last couple of times. So I would propose at this point that we define, start kind of converging into at least the first deadline or first milestone. So I'm not sure what would be the right format to actually fix this, but we should figure out the milestone name and we had some comments here about same verse, same verse and things like that. But at least the proposal that that is here and today where we seem to agree is that it would be announced at KubeCon.U. KubeCon.U. It would be the very first official release of NSM. And yeah, I don't know how we can go through this list of features, but I think that the most important thing that we should be able to demonstrate is stability. I mean, somehow to demonstrate that this is a project even with the very basic features that we can offer in the beginning. It's something that is very reliable, something that can play well in a larger environment. And it started also working on this proof of concept for Google Cloud, so things along those lines. No, I think this is why in addition to sort of Sember, and I think Sember is sort of a universal goodness. It also gives us the opportunity to pick a release code name because release code names are super fun. And so we need to figure out some really cool code name for the first release, but I think the timing you proposed is actually correct. We want some kind of a release going into KubeCon in April, 2019. And I think you're right that the most important things are sort of stability and resiliency, meaning, and when I say resiliency, what I mean is I had a slide where I was in one of my talks where the whole slide was just pods die because they do, right? The entire design in Cloud Native is that, and it's not just the pods die, pods restart, right? And being able to show that we can kill off the various pods in the system and stuff keeps working with at most a small blip in network connectivity, right?  But if you kill off other components, then you shouldn't get a network connectivity blip, but you should be able to have the system recover to the correct sort of state and move forward. So that seems like the most important thing in my mind. And then after that, there's a lot of other cool stuff that we could do. And part of that is going to depend on people's interests, but I would almost say after resiliency, usability becomes a big matter, right? So things like the mutating admission controller to make it easier to use network service mesh. Okay, I mean, I think that the bigger question that we should answer now is, what would be the right format to fix these things and start having a dashboard where we can track and kind of, because, so February ended essentially. So we have, okay, sorry, January ended and February started. Don't scare me like that. Don't scare me like that. Yeah, sorry, sorry. Okay, so essentially we have February, March and by sometime April, we should kind of start fixing things into the release. So that for the KubeCon UU, we have something that has been tested for at least a couple of weeks before we go there. What might be good would be to put together a project board with things that are on the critical path to that release because I don't want to give the question that we can't do other things because we can, but it also gives us focus to sort of capture the things that are most important for getting to that release, the things that have to happen. Yeah, it's also probably worth this because I think if we want to have a release branch or everything is done in the master branch, I mean, this is some kind of different release strategies. So the question is, are we fixing this within this goal? I mean, this or next week or how are we going to proceed with that? So I think there are a few things that we effectively have agreed on in this call. I think we've agreed that we want to do a release going into KubeCon a year. I think that anybody have a problem with that or anybody have other ideas? Okay, cool. So I think we've agreed on that. I think your proposal of a 0.1.0 release semver is probably quite reasonable. I think we have an open question that I'd encourage folks to brainstorm on sort of a codename for the release. I think we have a rough notion of sort of stability resiliency followed by usability as being sort of the primary critical path objectives for that release. And I think we've agreed that we want to do a project board to track the critical path for that release. Does that match up with the things that seem like things we've sort of agreed on so far? That much is my view. So we focus on like what are the primary things for the release? And that doesn't mean that the community is locked out. If there's something that's very important to you that you want in and are willing to work towards it, we won't say that's not part of the release as long as the architecture has been accepted by the community and by the core development team. So if you have something that's on the roadmap or something you want to pull the trigger on earlier, like don't say, oh, that's not on the roadmap. So I won't do it and wait till later. But other than that, yeah, I think that's a good approach. The other thing I would suggest you talked about pulling a release branch, my experience has been, there are a bunch of different ways to do it. But one way that works really well is that you basically do all your work on master up until a point where you pull a single throttle branch and the point of the throttle branch is just hardening and bug fixing. And then you basically do the rest of the work for that release for hardening and bug fixing on that throttle branch. And this has the benefit that it always keeps master open because you've pulled your throttle branch. So somebody wants to do something a little risky, they can do that in master. And so that may be one good way to look at this. And then we would just need to figure out at what point do we need to pull that throttle branch? For actual releases, I think that we should make use of tags. And that's because the entire go ecosystem is, and tooling is based upon tags, semantic versioning, so. I'm usually in favor of that, usually. Cool, so it sounds like we have a plan there. Nikolai, would you be willing to start putting together the board and a sort of a concrete proposal for when you think might be a good time to pull the throttle branch? Yeah, yeah, I can do that. So about the proposal, should I do it here in this doc or from the brand or okay, okay, I'll figure it out, okay. Yeah, I trust you, you'll figure something good out. The specification board, no. Yeah, yeah, sounds fun. Okay, is there anything else that we wanna talk on this or should we jump towards monitor metrics? Cool, yeah, I'm having to talk about monitor metrics and we have Matthew on the call, which is also good because I think he's the one who's possibly most excited about them in the immediate term. And what this really comes down to is right now we have this monitor connections and monitor cross-connect calls that we make. And all they really do is basically say, give you information about the states of connections and cross-connections, and this is how the move with Skydive is building out the topology. But it's super useful to have metrics. And so one of the things that I've been bouncing around and chatting a little with Matthew on the board about is sort of what metrics do we wanna report in network service mesh? And my initial thought for this was interface stats because from that you can derive a lot of stuff, right? From if you're getting the interface stats updates periodically you can use them to derive information about throughput and all kinds of other things. So do you have some people like to say about this? Do we have Matthew if he was here earlier? We do not have him. Oh, okay, cool. I didn't see him. You wanna say a few things? I totally agree that we need these kind of stats and something that would be really interesting or so would be to have the delay of the packets. But this is the thing that we can deduce from the flows by observing the flows going in and out from the wiring. And also I was thinking about developing a dedicated Skydive pod for VPP. So I think I would have the same metrics that you are going to provide me, nobody. Cool, question. Matthew, would you be willing to do the metrics spec? Yes, if you want. Cool, okay, cool. So I've added that to the spec board. If you could pick that up and start an issue in a Google doc so we can get that hashed out. Hopefully we have that hashed out. We can talk about it next week, if not before. And then we can start executing on getting new metrics. I like the latency metrics idea a lot. One of the things I think we may have to do is do this in two steps because interface stats are relatively easy. For latency, we would need something like IOAM and we can absolutely do that. It's just a little more work. Does that make sense? Yes, it does. Cool. Or there may be something simpler actually that we can do than IOAM even. It's really a matter of, you know a lot about the kinds of technology, you're a network guy, you know these kinds of technologies. So I'm super open to sort of things we might do to measure the latency across these different L2L3 connections. Yes, okay, I will write some ideas about that in the spec. Cool, that was basically a complicated discussion. Cool, so we have a few more minutes let's go over the Envoy spec. This is a first draft and it's covering a proof of concept for Envoy, not the hardened version that we wanna settle on. And so the proof of concept, so for those of you who are unfamiliar with Envoy, it's a open source edge and service proxy. So basically it's a proxy that you then can apply a configuration to and then it does whatever that configuration is. It works primarily at the L4 layer and L7 layer, mixture of L3, L4. And so typically the deployment is a Docker image. You can build a binary from source, it's not necessary to run from a container, but the container is the most common way. So Envoy is the thing that actually ends of deriving interesting, the interesting networking part of projects like SDO and Ambassador. And so there's a series of different features that you can perform inside of it, such as chorus filtering, fault injection, you can bridge DRPC or you can write Lua bridges or so on or Lua scripting rather. So there's a quite a significant amount of interesting things that you can do within Envoy to implement something that's of interest to you. It's also incredibly fast. It also supports things like live upgrade of the binary without dropping connections. So basically Envoy though falls straight into being a network service. So you can ask for Envoy as a network service and at least that's what the world, we believe the world should look like. And so the application could request for an application proxy of its type that it wants. And so the initial version should be entirely written with current interfaces. So basically you have a kernel interface coming into Envoy and then the kernel interface to get back out. Actually in this scenario, we might even just use a Kubernetes Network Inc and not even bother with the network service client at this point to get back out of Envoy. So in this scenario, there's a couple things that we'd have to add in here as well. So first one is create the deployable Envoy deployment. So the pods don't need to be created on the fly. So in other words, assume that we have an NSE that is being created. We have the create PNSM later on that will help with deploying this on the fly at a pod level or node level. We're gonna run the pod as privileged to start off with and in the long run we don't want it running as privileged. But in the short term, we need to add in some IP tables which will require some privilege. And what the IP tables does very specifically is it injects what's called a redirect role into IP tables. So a redirect role does two things. First is the redirects all incoming traffic to your local host to a specific port. So all the traffic coming in from one port is now redirected to Envoy. And then Envoy then uses one of the IO Cuddle commands to work out for each TCP IP stream. What was the original destination so that it can then do something intelligent with bad data that's been lost from the stream. So once that's correlated and then Envoy can then do whatever it needs to do in order to work. So in the initial version, the pod will need to have some privilege. Ideally, we'll be able to extract this privilege and remove it and have something else own it that is that's more trusted or even better would be a fine way to have Envoy modified so it no longer requires privileges. But we're not that's out of scope for this proof of concept. So we're going to create the idea would be to create a network service endpoint which can accept an L3 connection. Technically you do L2 as well but for the proof of concept, we'll focus on L3. So once we have a network service endpoint created then we should verify that that works. Then we need to create a new network service endpoint. We also need to create a new Envoy network service endpoint pod image. So what this means is you take the original Envoy which what's been released by Envoy and then we add a layer on top of that which injects the network service endpoint binary. So that way when you run it, it doesn't run Envoy directly instead it runs our network service endpoint which then acts as the unit for Envoy. So the Envoy network service endpoint will both receive requests coming in and simultaneously control the Envoy process. I will expect that out more. I was in the middle of writing this and didn't have time to finish that. And the last part was ignoring the network service client side. So how do the packets get out? In this case, we just use a default Kubernetes networking to communicate back out in the initial proof of concept. In the long run, we want to actually have a network service client in there as well. They can make the type of request that you want out and wire them together. Or we make use of the network service wiring that was coming down the road later on. I will add an image on here because it's unclear. It has to, like said with some of the ideas, it makes a lot more clear if I have the image. So I'll create one. So we're running out of time and I will comment here for the last part but essentially with SDK it should be pretty easy to just start the connection downstream or upstream. But probably the proper way, as you said, Envoy is, you don't need to restart Envoy to update this configuration. So just, you can just update the actual configuration of Envoy with the new IPs that you get from the NSC and it will just work. I will write it. Yeah. You guys, this would allow. So first, the issue of community is talking about how would they move Envoy from being a sidecar container to being a sort of a separate pod. They're currently calling it a metapod. The nice thing with the service mesh is we're getting, we're moving in a direction where we could do this very cleanly. The second thing is your Envoy basically acts as an ingress to your application service mesh. And you can imagine a situation where you have a pod and it's got the application service mesh for the communities cluster. There's a separate application service mesh it wants to be part of that ties to your corporate internet. And then you might have a third network service, your application service mesh that you would want to be participate in that ties to some kind of a partner network, right?  And so at this point, then you've got three different application service meshes you want to participate in. And by using the strategy with network service mesh, we could actually wire you to all three and you would get the correct behavior. And that ends up being super, super powerful. Okay, I guess that we are out of time now. Yeah, it's very good meeting. Yeah, so the same. So again, thank you everyone for attending. We'll be available on IRC. Next meeting is same time next week on Tuesday. Definitely looking forward to continuing this conversation on Envoy where we'll have it more specced out at the time. And with that, let's close it out and you all have a good day. Thanks. Thank you. Bye. Goodbye. Bye bye.


Alexander's Vera versus Thomas Martin Etcheverry is the fourth men's quarterfinal for the French Open for 2023. And both guys weren't expected to get this far in the tournament. Etcheverry started the tournament off against Draper in the first round. And after winning the first set, Draper was unable to continue Etcheverry winning 6-love-1-love retirement. In the second round he take on the 18-seat Diminor. And after a close second set, he get through in straights 6-3-7-6-6-3. In the third round he take on the 15-seat Chorridge. And again after a close second set, he get through in 3-6-3-7-6-6-2. In the fourth round he take on the 27-seat Nishioka. And again after a close set, he win again in straights 7-6-6-love-6-1 to advance to the quarterfinals without dropping a set. Vera went into the tournament as the number 22 seed and would take on Harris in the first round. And after a couple of close tie breaks, Vera would win in 3-7-6-7-6-6-1. In the second round he take on Mulchan. And this is by far Vera's easiest match getting through in straights 6-4-6-2-6-1. In the third round he take on Tiyafo, who'd been very impressive beating Carrots of along the way. And after dropping the first set, Vera was forced to fight, narrowly avoiding 5 sets, getting through in 4-3-6-7-6-6-1-7-6. In the fourth round he take on the 28-seat Demetrov. And again an easy win for Vera, getting through in straights 6-1-6-4-6-3 to advance to another French Open Quarter Final. These two have actually never faced off before, but Etcheveria has been having the best season of his career. And he's a very very accomplished clay quarter, making a few finals this year. And Vera of course is on the comeback, finally getting to the later rounds of the biggest events. So the experience might be with Vera, but Etcheveria has the form. Etcheveria is going to win this one, he needs to pretend like he's not in a big quarter final. He's been so good, not just this week, but for the entire clay court season, playing so well over the last couple of months. So he needs to use that experience and use that clay court knowledge that he has to move Vera around. But Vera is going to win this one, he needs to use his experience. He's so good at this level, we know he's been in the top 10 for so long and he's been doing many quarter finals of slams. So the moment won't scare him as much as it will scare Etcheveria. He's going to get off a good start and try and overwhelm Etcheveria with the moment. This is such an interesting matchup because both these guys weren't supposed to make it this far. You know, Medvedev, Sinner were in this part of the draw and they both lost. But I'm going to go with Vera based on experience here. I think this could be a four or five set though, because Vera hasn't had that long match yet. I know he had kind of a long match against Ciafo, but he hasn't had a five setter yet. And Etcheveria hasn't dropped a set either, so something's got to give. I reckon it might be Vera with five, but let me know down in the comments below. Who do you think is going to win this one?


Good morning Okay, I want to start Just by saying thank you because so Jim freeze. I don't know how many Concerts I've been in a new organize a lot he is tireless and taking a risk and organizing yet one more brand new one with a new group of people and You know a whole series of challenges. I'm just really impressed And as you'll find out he runs a great conference. He has a lot of Detail that is really really nice. So I just want to say thank you to Jim for organizing this So this is Steve jobs. He actually fought to have it think different. I can't stand that. It's got to be Please Listen the publisher Okay, so I think that if you don't Keep reviewing your thinking. Well, there's a story in business that if you're not growing your dime I think it's the same mentally. I think if you're not growing mentally if you're not thinking use things If you're not challenging yourself, then basically you're stagnating your dying in your head So I think it's a kind of a duty to keep challenging ourselves to keep trying to find new ways to do things in my own career I've been through a number of transitions. I'm gonna start off my first program. I used to be basic And I really really enjoyed that. I Went to some early old languages. I did all sorts of stuff. I keep changing paradigms as it goes along But at the same time I have been doing all the development of various kinds. How many people here are Younger than 40 years old.  I got into a little rock because it was like easy to do after a while you learn it and it becomes Instinctual it becomes passive and that's how you that's how you go and One of the things that I Really love about this last 18 months has been that Elixir has changed the way I think about programming Not just in terms of life. It's a functional language. It's actually changed my conception of what it means to program now the problem is I would love to explain that to you I'm gonna try to explain that to you But it's not easy because it's kind of like how I think about stuff and Lord knows how I think about stuff is weird So I'm gonna do my best to explain it to you However, what I'm not trying to do is to sell you on my way of thinking that's not what I'm doing at all Instead what I want to do is just to show you an example of a way in which the language and the environment Have a profound difference on how you think about what you do All right, so wish you luck That point goes to say good luck Dave Okay, all right, so Quite a bit of background how many people here have you know done coding in elixir All right, that's the majority good So I'm not gonna sit here and give like an introduction basic lessons in elixir I think a few things just to sort of you know cement the ideas first idea is that We have pattern matching And pattern matching is pervasive in elixir So All right, let's really say a equals sine one you're not assigning a to one You're challenging elixir to try to find a way to make that true and it can make it true by associating the value one with a If I have a tuple CD and I try to match that against two three Obviously you can do that by associating two with C and 3d and so it goes There's a few less common forms of pattern matching So for example, we can have the binary join there elixir join to rest matches in some rocks Well, the only way of making that true is if you set rest to be the world rocks So it's quite subtle the kind of pattern matching you can do and of course the pattern matching of the lists Allows you to match either a literary or a list of the fixed number of elements like I do in the third example there Or you can match a variable length list by matching the head and then the tails the head is a single element And the tail is then the rest of the list So pattern matching applies there It also applies here So for example, I can say go to open a file and that's going to return a tuple That says either okay, and here's the file or error, and here's what we're wrong So I can do pattern matching on that using a case statement Not very exciting there, but that case that does all the same pattern matching like you do previously And we have pattern matching in functions, too We're all familiar with pattern matching in named function sorry in name functions But you also do it in anonymous functions anonymous function and have multiple heads Inside the function body and each head has a pattern match so here if the first parameter is the F and plus then that first one's going to match otherwise it is times the second one's going to match And then if here's a more common form with name functions All right, so let's just review So pattern matching Let's just match based on shape and content It allows us to destructure data that is look inside Competitive data or structured data and extracting matches individual elements and Loosely you can say it's recursive in that you can actually match things inside a match That's going on So this is a very very powerful facility And I'm about to draw a parallel between it and something else that we're all familiar with I want to just like beat the horse to death first I Think actually almost every time I stood up in this room. I had Fibonacci on the slide somewhere So Fibonacci is the Horio Chestnut of pattern matching on other things the cool thing about Fibonacci Here's a specification of the mathematical specification of Fibonacci right Fib zero zero one is one Otherwise it's n minus one and plus I said minus two Okay, so that's not a big deal and That very conveniently maps into elixic hope So here we have our module fit that has a function called fit There are three hands or three heads to that function if you pass to zero and return zero That's the long one otherwise it returns Whatever and so if you call I look for this fit 10, I guess that's 55 Okay, so nothing dramatic there So there are many ways of expressing that in elixir You could express that like this You can have one function a head Rather multiple ones and then inside that you can use a case table again more pattern match But we just have now control structure inside our function in reality In terms of executing code My understanding is that those two are identical and inside the Virtual machine those two are actually the same code. I it's mapped from one to the other It's very different at the soul slow You can also choose to write it like that Which might be how a ruby ball or whatever you think so if you look at those three Which of them best captures? the idea of Fibonacci the first thank you I think the first one the rest of them are perfectly valid the rest of them work perfectly well, but to me When I write that first one it mirrors the specification It mirrors what I'm told to do and I think that's important from two sides It's important from the developer side in that I have a clear and transparent path from what I want to do to Express it what I want to do But I think it's also clear and probably more importantly clear from some future readers point of view Because if they read that it's kind of like look like Something they can understand something that they can tie into in this case the Fibonacci specification so I think that this way of expressing things is Well expressive it's clear it's concise and it says what we want to do so I have been trying to work really hard over the last Six months to write programs as if they were Specifications and that has made the dramatic difference some of what I've heard now then just give you a few more examples and You know, they're not gonna be Specification with the list okay number entries in the list well an empty list has zero entries on the other list has One for the front of the list and then the length of the rest of the list And of course the Implementation of that the recursive implementation just follows that's fair Literally line-of-line So the length of an entry list is zero, but if any other list is one plus the length of the tail Absolutely nothing surprising Man our favorite Mac function one of the lines of function to every other list Okay, so the map of an empty list is the empty list Mac on the list of the head and the tail is you apply the function to the head and then you append the map of the tail Again, nothing that's really scary there any implementation You know trivial Okay, so these are going to like trotted out and you'll see people I'm probably guilty myself doing blog posts and tutorials that have these kind of examples It's not okay, so what? So let's try doing something just a little bit more complicated. Let's say we have a List of values in this case that numbers click at the end And we want to run the length in code them So that we're gonna look for sequences of the same value and replace those sequences With some kind of remission. So here if I have three twos in a row I'm going to replace that with a tuple with two that's the value and then three which is the repeat count This is not rocket science, but it's a bit tricky think about sitting down and coding that in your regular like a movie or a job or a seashell or whatever you might be doing Let's think of the things that you would have to think about You'd have to think about all these special cases in particular. There's the end of the list problem Right, you're going to be able to deal with that special case Did you hear me hit the end of the list and as an experiment? I sat down to try coding this off in Ruby and sure enough I actually had a bug in the first limitation. I had to go back and fix it. All right So this is where I want to get into the star of that kind of revelation I had so My input is a list and there are two special cases In that list the first special case is if the two first the head and the second element of that list are the same And just a pattern match. I represent that by just saying a name saying quote variable there Means it's going to be the same value So that will only match a list that has two identical ones at the start And what I want to do is to replace those two with a tuple that has the value of a whatever that might be and a two The other special case I've got is if I've already got the tuple at the start of my list And the next element is the same value as the value I've got in that tuple Then I'm going to replace those two elements with the same value, but n plus one Yeah, so you can see that operating here is our list One nothing special so it gets coffee, but now look we've got two twos at the start of the list So we're going to replace them with a tuple But now we have a tuple whose value is two and the next number is also two. So now I'm going to replace that with two three Now nothing special. There's no matches. So that just gets copied down Three gets copied down. Oh, we've got two of those guys now So we can form a pair of those two Etc etc. Okay, so that's how it's going to work. So how do we code that? Ever we need to generate a new output from an input We're going to need some kind of value to put that into or we don't have state You just like sticking to Vincent's variable. So the common pattern is we're going to have a helper function So to end code on list, we're going to call underscore encode That's our helpful function and we're passing it the output list So the idea is they're going to transform the input list list into that output list That's what happens when we finish when the input list is empty We need to just basically return the output list and as is often the case Whenever you're recursing on the head, you're going to have to reverse the output list This is where it gets interesting Here's our pattern match to say if the input list has two identical elements at its head And then any kind of arbitrary tail Then we're going to call ourselves again replacing those two elements with the tuple a comma two All right So we're not generating anything in the output yet. We're just moving stuff in the input list We have an input list that contains a tuple which is a repetition of the value a And the element following that is also that a Then we replace those two in the input list with a and plus one last case is Okay, anything else we just copy to the output list. That's all we have to do that just work That's just an implementation effectively from the specification They just work for us time the interesting little side effect here How do you know that this particular program will always terminate? It's actually pretty easy because if you look here are our three significant patterns To a different elements to pull an element or just some random element in all three cases of recursion We remove That pattern from the list and replace it with something shorter So in all three cases our input list is going to shrink in size so we guarantee you There's all sorts of cool side effects when you start looking at doing it this way Let me show you another example. This is actually Where I've got all of this like inspiration from if you like Because when I start learning a new language, I have little exercises I do Little things that program you know, obviously the first one is always a whole other world And then I'll get into like different stuff So I'll like co-dot binary chops and this kind of stuff if I really really really want to get into a language my courage I Won't be able to my current favorite way of doing it, but it's anything but favorite To implement a lockdown puzzle And the reason I do that is that lockdown is the ugliest worst specified For the special case thing you can think of to try to pass Right. I mean to give you a clue the canonical markdown implementation is basically the regular expression from hell You know, so it's really tough to find ways Tidally to Breakdown markdown and so as a result It's a great way of challenging yourself when you're learning a language to try and find nice ways of expressing things And this is what glue your way when I was coding the links now This is probably my fourth Elixir markdown implementation. It's the first one. I actually finished because the first one actually felt Yeah, that is okay And this is actually the least on heads as earmark, but anyway Let's imagine you're pausing market. So one of the many many long down rules use that word like it is that Before heading will be a blank line some text a Line of underscores and another blank line. Okay, so that's a particular style of lock down Hey Let's assume that the first thing that you've done is taking your input and divided it into lines and done some Normalization like I'm stripping blacks, maybe or maybe not depending So we have an input list which is a list of lines well Here's a rule That recognizes a markdown header And this is actually not quite like this because I have some stuff in there, but I mean fundamentally That's what I've got my markdown, but so to pass a list whose head Consists of a black line a title a line that starts with underscores and another black line Where the title has a length? So then you replace that in the input with or sorry you actually generate that into the output by having That has a title. Yeah, so what about just done here? I've used pattern matching to pause some syntax Extract out the information I want and then generate an output set pretty cool pretty cool another example Uglier, but I mean just to show you stripping HTML comments This is a little two-state state machine written purely with pattern matching So it's switching back and forth between being outside of comment and inside of comment And we're recognizing our comments start and stop just using a pattern Again really really cool enough of those point of this first part is that you can think of pattern matching in every single context you use it as a form of parsing Now sometimes it's trivial like you know a Matches with one. Well, okay. That's a trivial pile. This is just saying I have a single element But sometimes it's way more complicated Sometimes it could be a mockdown syntax or it could be error codes returned by father over it could be anything but pattern matching can't be considered to be a Kind of pause our code that uses it is consuming stuff During that pass during that pattern match is consuming it and it can choose to generate outputs from it or It can choose to modify its future behavior by updating its inputs instead That's what we do when we're doing our own length in coding. We were pushing back onto our input list a To pull if we found two elements the same at the beginning so we can consume input we can modify input and we can generate output and Because we can look into lists or other parameters, whatever We look at it I'm not a positive expert, but I'm thinking this is probably something like LL and Awesome, but why is that a big deal? It'll tell you later So we're gonna come back to that second thing I want to talk about is functions Now we all know That a function is something that transforms data So the plus function takes two things and has it together and the sign function takes something and does a sign on it, etc So wow, okay, that's not direct But obviously there are bigger functions more complex functions as well so for example if we were writing some kind of web servery kind of thing and We get session data come in. We're gonna go through some lookup function to find out who our user is or whatever else might be the case Or if we have like a shopping cart and some payment information Then we might want to take both of those things through a function called checkout to generate an order That's not normally how we think about Functions, but this is wasn't only how I thought about functions I tended not to think about checkout as being a transformation from one stuff one thing to another thing I just thought about it as being something I did So my second revolution is this idea that I want to think about everything as a transformation Everything as being taking my inputs moving into my outputs and along the way getting closer to where I want it to be and that's Really useful because you can do really cool things with function Now as you know functions to pose so if I was doing say Anagrams then I'd want to be able to find the signatures of each of my words in the classic way of doing that Is you take the letters in the word and you sort them so if you have cat C. A. T. Then the signature would be a C. T.  So here we have we generate these code points because it's new TFA That's obviously where we're going to be And then we sort when we join them and you know being sort of like, you know Programmers would say the way they've always been variables We don't want to use and we might be tempted to rewrite that like this Is that we've lost We've lost the ability to see what's going on in terms of functions because we have to go read this From the inside out think about someone and you're trying to explain to say your brain mode and you're trying to explain what this does Okay You say okay, so what you actually have to do here is you have to go along and Find the last function call in this and you recognize the last function Because it's going to be the thing just in front of the last opening round bracket Now what follows that is going to be the parameters for that function Okay, that's easy So you're going to go and you're going to get that word and you're going to pass it to the code points function And it's going to change the value now What are we going to do remember that last open parentheses now? We're going to skip backwards keep going to another one right and we're going to take whatever the value is code points And we'll pass it to so again explaining like this and extend like this and either we give up or she walks out Right because it's crap. It's really complicated. It's unnecessarily complicated. It skewers what we're trying to do and so elixir Among that a whole bunch of functional languages allows us to write that instead Okay, so we can pipe a value through a function and Then we can pipe the result of that through another function etc etc as much as we want So here our word is being transformed by code points That is being transformed by soul that is being transformed by John Obviously the pipeline is nothing more than some syntactic shoe Right all it is is a transformation from that form into the previous one And yet it is a profound difference to the way we write code come back to the idea of a shopping cart and Check out being a transformation of a car payment into an order So you can imagine that we're expressing that here in a pipeline And we can think about our code Purely in terms of transforming data purely in terms of functions if you start doing that It also changes the way you think about program so It allows us to express all of our work in terms of transformations We're no longer telling the machine what to do We're describing what we want done And that's actually subtle, but it's a big difference We're separating our data and our functions and we're looking at our code in terms of the flow of data and the Transmutation of data by lots of different functions And that allows us to code way way closer to the actual problem in there. So two things We have the idea that that is actually is a form of pausing And we have the idea that functional programming is a series of transformations So what does that get us to? Well, it gets us. I don't know is the answer But I want to try and show you where it's got me and this is where I'm gonna get into the kind of like, you know They was crazy. So Forgive me. Let's start with a simple function that looks like this Okay, so we're getting some kind of response probably like the GDP response just given the numbers And it's got a code and a message if the code is 200 we do nothing if it's 404 we say not found if it's 500 we do something else Okay Perfectly valid function No one could criticize that Does one thing relatively straightforwardly? No problem at all But let's think of it instead in terms of pausing and transformation we could rewrite it Like this now what we have is one function Actually equivalent of top function here one function Where to respond appropriately given whatever that code is but you're going to say oh Well, that is clearly a better way of writing it in the first form No, you're not because it probably isn't at this point, but this is all part of the build-up. Okay, so trust me So what we've done is we removed logic for the body of our function and instead turn it into a very very trivial part All right. We're pausing an HTTP response By matching different things in our function heads All right, we've replaced imperative code with pausing That's the whole point of this slide or writing all these deaf things So just as I go to save myself time. I actually wrote a little macro called a deaf My god, I love the fact that I got a language where I can do that And so that's actually off in the next if you want to use it. It's called multi-dev But it basically does the same thing if you say M deaf forms once it just generates those three function heads Okay. Now it's getting a bit clearer. I kind of like that. So here's a slightly more complicated case Again perfect in reasonable code. We want to read a line from a file. So we're going to open the file I'll find that open returns a tuple that says okay, and it's some kind of device I own for me And which basically we can read from it. Otherwise, we're gonna have some kind of error.  So maybe it should be But I don't know but I want to think about my world in terms of pausing and transformation So here my first step is to say well the return from file.open is something that I can pause And so I'm going to split that out I'm going to say that to read a line I am going to call my little helper method on this little line and pass it the result of opening a file And then in my helper method I have a pass to say it's okay. I'll do one thing if it's not okay I'll do another thing Okay So here again, I've replaced imperative logic with declarative pass But I can take that step further and make it obvious what I'm doing By using a pipeline to show the transformations that are taking place The transformation is I'm taking a name and then transforming it into the first line of a file with that name And by writing it like this I'll make that explicit So I have my transformation going that way. I have my pass Going down This is getting interesting at least to me Excuse me for doing this This is actual code from IEX. It's the code that loads the .iex file Which is the one that does all the initialization if you want to customize your colors and everything else So what it does is you can pass it explicitly the path to your IEX file in which case that's the one that it loads Otherwise it's going to go and look for either a .iex in your current directory or in your home directory yeah so The first of all says if you give me a path then the only candidate is that path Otherwise I'm going to take all of the you know known names and expand them into a full path name And then I'm going to find the first one of those candidates that actually exists as a file If I can't find one then I'm going to return the original config Otherwise I'm going to merge in that new IEX file into the config that gets passed in again An okay function a fair amount going on in there, right? I've had to write or somebody has had to write You know some if statements and some conditionals and blah blah blah right? Can we do that differently? We could do it using transformations and pauses So it's a little bit like taxi x.iex file We the fundamental thing we want to do is to take a path We want to go and use that path to find the possible IEX files find the first one that exists and then update our config from there That's pretty straightforward Yeah expresses a transformation like that. It's really obvious what we're doing I think it's easier to read putting on with if statements Now to get our IEX files we're parsing our input And it's a trivial parse our input could either be a name or it could be nil So if our input is nil we're going to return the list of possibles Otherwise we're going to I should have got to expand it all Otherwise we're going to find the path And then to find the first we just use the existing code and then finally We're going to pause the response of finding that first one if we find it We're going to merge it into the config if we don't find it We're not Again, we're replacing imperative logic With pattern matching and transformations In beginning to see a pattern here. I think that this is worth exploring My current lockdown parser is I think it's about 1200 lines It has a total of I think it's 11 Imperative statements in it And some of those also do with how I mean I could probably hear a little bit if I really really wanted to I think it heard a little bit It turned out to be actually I think Nice total means there was imperative statements So Once I've worked this style out once I've worked out that this is how I wanted to do this It would believe how much simpler it got How much easier it was to do I needed to add I I released the first version and then I wanted to add table support And it was just The modularization that comes from the cars was so beautiful I just said okay to recognize a table I have to parse a line to recognize one a table has to have Two successive lines to have the same number of vertical bars So I can do that as a parse the whole thing just fell out It was like half an hour's work I was expecting that all the day is what I thought about It's a phenomenally fun way of coding on all sorts of scales For example Maybe we're writing some kind of back-end service rest service And we're doing some kind of site that does You know deals or coupons or whatever else okay, so I'm a particular user Or I'm doing on behalf of a particular user And they come in through some kind of rest of the whole tokens So if we go find the user and then for that user I have to find their local offers You know the ones that are around them and then the kind of national offers like chain stores that are giving me discounts or whatever else And then I have to get those responses Merge them and send them back down as a response to my rest interface All right, so this is kind of relatively straightforward stuff when you want to serve So I want to think about this now Not imperatively, but I want to think about it in terms of transformations and parts. Oh, I'm just making it interesting I'd like to make those two asynchronous All right, so I'm going to send out the two response the two requests to find the local offers And then we can vote to come back before I send a response down So it's going to look something Like that all right this next slide is I'm going to say all these slides this one is ugly, but I still like to think about it a bit Because I would express all of that Using pattern matches and you're using a few simple transformations. I'm just showing the pattern batch part there I'm not going to show the actual functions that do it, but let's assume it looks something like this My response comes in my request comes in And the little front end thing converts that into a map Where it says get offers and here's the authorization total Okay, and this is going to probably go get handled by Some kind of gem sort of component somewhere this signal how to make these things so the first thing that's going to do is match on that particular map Actually value And the first thing it has to do is find the user so it's going to respond by saying, okay So now what I'm doing is getting offers. I have a user so it's going to look up the user from the call and stick it into that map So now we have a map of the two elements in it One's the one's the request type one is the user. So now we have a different pattern match So I'm going to come in now with a second pattern match. So we're just looping around calling ourselves trying to pass this response And we've made our input more complicated. We've added things to our input just the we did with the run length encoded thing Here we've added the user to our input So now we match that now we're going to call two functions async get local and async get national And they're going to go off and do their business We're not going to do anything else. We're not recursively calling ourselves at this point They go off and do their business and at some point they send The responses back into our server and our server is going to use those to update its state update its input Now and if the national comes back and says hey, there's an error Then okay, we're going to throw the whole thing away just to respond to the error Similarly if local comes back and says there's an error They're going to throw it away Otherwise we just need to pattern match the case where we actually have national data and we have liquidator at that point We can send the response back if I could work out the time and whatever else I would love to see Some kind of server implementation Based on those kind of principles. It's a server implementation where it's declarative Where the rules are obvious What we code is what we wanted to do and not all of the little kind of details of capital coding Now This is not new It's One of my one of my real pet peeves is that it's an industry we have no memory Or we keep reinventing things that we've done before Um But this goes back to the 1960s total programmers Used to use decision tables Which will come with varying State machines again in the 60s are varied on this And gluttonous limba blackboard system and all the others like that are also varied in that you put data into the system And then you pattern matched In order to generate an output So this is not new. This is nothing, you know, totally radical, but for me It is for me. It's a different way about thinking when I'm writing code And I am finding that incredibly powerful once you think about things this way You get all these extra benefits too It's easily made in parallel Um, effectively you're writing a dsl I mean if you think about that previous slide with the maps that's could be considered to be a dsl But you could wrap that in a really nice little dsl a specific time just as far as you can get really long to do You get for normally granular reuse Because each function I mean typically when you're writing code this way every function is one line long So if you want the ultimate granular reuse, that's it If you're into testing clearly you're easier testing Right because you can put around everything that I say is one line long. You can test just that one thing Really nice and easy to do And you also get control of error handling. I think Bruce you're going to talk about your pipe Like this right? Oh, okay Um, but I mean you can actually start codifying error handling when you heard of things as a part of us Then there are easier ways to handle errors You can also start thinking about error recovery I mean the parser literature is full of ways of handling error recovery in a graceful way We can start using that in our code Yeah, it's kind of interesting. I'm not saying throw away your statements I'm saying I have And I'm saying it's really interesting For me personally to have done that And I'm having a blast exploring or re-exploring what it means to partner I don't think I'm advocating this as a universal solution for everybody that wants to code But I'm saying the kind of changes that have Is ruled to me have been so beneficial and so refreshing. I would like everybody else to experience change too Do it for yourself find ways for yourself To think about things differently I think One of the biggest benefits of elixir is that it is a breath of fresh air for developers It's the ability to have a fresh start We can think about things in a different way and I think If we do that the most important, I mean if you like we are Around which this is going to stop forming. Okay, the 105 people in this room Are you know the start of something and we get to set a lot of the direction Right, what if something is so young and so small That every little input is going to be significant. We get a chance to do that And that's fundamentally exciting So Here is my plea Some of you may come From the Ruby community Please, please do not give us another rails It's easy right rails works rails is cool. Okay, so but Linux doesn't have a rails therefore we need to do Well, L rails or something. No you don't right That's boring. That's being done and it doesn't solve a problem Maybe you come from the early on community and you see this as a way of A bit easier syntax for creating the same applications you'd be creating with us Again, I would say please don't do that This is the opportunity we all have to throw away a whole bunch of stuff. We've got a free Restock, you know and that is so cool. So instead of reinventing the past Let's use what we have here. Let's use the power of what we have here to invent a new future All right, let's think of cool things we can do with this opportunity And let's make a difference And then while we're doing that, let's just remember to have fun So, thank you very much


All right. Thanks, AJ. Well over 150 Brainerd students from eighth grade and up were in the weight room today getting in a great workout for a great cause. On this week's Northwoods adventure, Anthony Scott explains why today's workout was extra special. Lifting weights to raise money. That's why the Brainerd High School weight room was packed today as the 29th annual Sertoma liftathon was taking place. A lot of these kids have been working hard for this event and it's great to see so many kids that want to help raise money for local charities and as well as helping themselves and their team with their strength game. Students found family members and friends who would pledge money for them to lift weights and then a member of the Sertoma club would reach out to that person to collect donations and each year the liftathon raises about $15,000. It goes right to Sertoma and then they divvied up. They have commitments with the soup kitchen, kinship partners, camp confidence, growing county united way to name a few. At the Sertoma liftathon students had six attempts to complete a bench press, a squat and a clean. I was I was expecting it to be kind of hard and scary but it was really easy at the end you know they made it really fun. Students were competing to see who could have the most pounds per ounces which takes your best lifts from the three events and divides the total weight lifted by your total body weight to get your final score. It's not just the person who has the biggest bench press or the biggest person, it's the person who's the most athletic and well-rounded for their size. And the top male and female are awarded an $800 scholarship in Steve Nunnick's name, the man who started the strength program at Brainerd almost 50 years ago. I think raising the money for charity is awesome for all the things in Brainerd and then the scholarships are there but I do it just to lift and to do my best and I'll perform myself and lift everyone so. The kids that have been working hard to get ready they have tremendous gains especially in strength and also in their confidence so we just want to keep it going for them. The liftathon was another huge success with more students participating this year than in the past five years and that only raises the bar for the next liftathon. Reporting from Brainerd for this week's Northwoods adventure, Anthony Scott, Lakeland News. Good event they've got going on there. If you enjoyed this segment of Lakeland News please consider making a tax-deductible contribution to Lakeland PBS.


The rapid growth of technology has had a significant impact on the socioeconomic development, labor market structure and educational services in many countries. This has created a demand for highly skilled programmers who are able to continuously improve their skills throughout their lives. In order to meet this need, individuals must possess strong motivation to self-improve, which can be optimized by developing certain qualities, morals and ethics. This paper examined the current state of motivating students to self-improve, identified problems that impede progress, and proposed solutions such as integrating motivated learning into general education and professionally oriented courses, creating an environment conducive to learning, and providing teacher training in professional development. This article was authored by Larissa M Petrenko, Irina P Vareva and Andrei Pekilnyak.