I've finally murdered that big bad Hydra! Can't wait to see what's beyond it! Oh, oh joy. Hello everyone, I'm Philip Madness and this video is a short exploration of a few of the features I really liked and some of those I disliked in Hades' latest patch, the Chaos Update. Let's take a look at the big changes first. And this one is a favourite. Zagreus' model has been updated with some really nice shading and generally better 3D work. Several other models are also improved and I believe so is a number of attack animations and objects. It's just looking better and better this game. Now to the 3D artists joining the studio from what I've heard, I can only guess that we will be seeing even more impressive 3D animation and models in the near and distant future alike. Now for the main course, this update introduces to Chaos, the primordial originator. Chaos is interesting even if I feel like they decided to go with a rather cliched choice of voicing him. That's right, they did that whole Echoy Mowy. That's all primordial and varying human beings in all games, movies and TV get at some point or another. The idea that Chaos is an actual personification so, instead of a super primordial, scary destructive energy, is something I am into. He, or is it it? refers to the other gods questioning whether the Olympians have forgotten about him, it, and throwing all kinds of shade in Zeus's direction in particular. He's also kind of Zagreus's adoptive grandparent, while account of being Nix's father, and Nix, i.e. Knight, is the goddess who took care of Zagreus all his life. Ergo, that's the connection. Of course, you know that in Greek mythology everyone is connected with everyone in familial bonds, or bonds of hatred, one of the two, but mostly it's just blood. Plenty of blood. Anyway, not far the daughter do, doesn't have the greatest relationship, but cares seems to have turned a new leaf as intent on helping Zagreus, though his motivations used to be something along the lines of, I want to see what happens. Rather than some sincere desire to help our favourite Zagreus get out of Hades, there are also several new types of enemies. The most annoying of which is a big-ass stone head that flies into the air and tries to turn Zag into a pancake, which I don't have to appreciate in the least, let me tell you.  Whether it's a positive or a negative experience though, that is for you to decide. Hint, it's a positive experience that the game is so much fun. One new change I dislike, everyone or so, proper Hades will decide to challenge Sunny Boy on not getting hit. What is otherwise a completely normal reward will turn into a piece of onion that heals one HP, even if you get so much as a single point of damage from lava. Especially later on in Asphodias, not getting hit can be really challenging. It will be sweet if we were to get an additional reward, like gold, a health pickup, maybe a dessert, maybe some burgers with that onion, anything really, to make this sort of challenge at least a little bit more worthwhile. One last thing I particularly enjoyed, several new room types have been added, meaning that there is even greater variety. In detailed rooms you'll be battling through. I'm hoping they add more and more of those with each major update, because it's fun to not go over the same 10-15 varieties I've at this point learned by heart. PS, last time I made a mistake. I said that the first set of levels was called Hades proper and the second was called Akron respectively. I was wrong, sorry about that, the proper names are Tartarus and Asphodias. At any rate, that's my take on the KS update and only with a few days to go before the next big update hits. I've actually been working on this for a while, or rather I've been meaning to get to this for a while, but January, surprisingly busy month.  But anyway, thank you guys for watching, listening and hopefully you enjoy this to the fullest. I'll see you next time, if you enjoyed this, please share, like, subscribe, ring the bell. As people keep saying, I don't get it, but, ah, he does. I'll see you next time. Bye!


It's a win-win for everyone because what we've done, we had our duty weapons prior to this for approximately 10 or 11 years, and so we replaced Air Smith & Wesson duty weapons with New Glock duty weapons. I've been with the Department for 18 and a half years, and this is the first time that we have ever had new patrol rifles. The exact amount of the check was $42,343. How this come about is the West Virginia Secretary of State Office has come up with a program that we were made aware of a couple years ago where they can turn your seized and forfeited guns into money. How the process works is they actually auction the guns off for you. Some of these guns, you know, just set in storage or in a locker somewhere for 20 years before Chair Smith was actually made aware of this program, like I said, probably two years ago. With the financial state that Mingo County is in now, I mean, without this, it wouldn't be possible.


The integration of renewable energy and optimization of energy used through modern technologies like IoT are crucial for sustainable energy transitions and mitigating climate change. IoT can improve energy efficiency, increase the share of renewable energy, and reduce environmental impacts in energy systems, particularly smart grids. Enabling technologies such as cloud computing and data analysis platforms are discussed, along with challenges like privacy and security, which can be addressed through solutions like blockchain technology. This survey provides an overview for energy policymakers, economists, and managers on the role of IoT in optimizing energy systems. This article was authored by Nasir Hossain Motlak, Masa Mohamedrazii, Julian Hunt, and others.


of the swamps of southern Louisiana. It's like real Cajun country down there, really rugged. These people are one with the swamp. And I went on this kind of touristy boat tour with a Cajun tour guide. And we saw just a ton of gators, right? You can look at these guys. You see, most of them are, like, pretty big. They look pretty tough. They were pretty cool to see. But the best part of the tour was the grand finale. The tour guide turns around. He reaches into this cooler. And he takes out this little baby two-foot gator. He was adorable. And the tour guide says to us, so we take these guys out of the water when they're just about this big. And we use them for the tours. We rotate them. They don't have to do the tours every day. But we can't put them back into the swamp until they're, like, at least four feet long. Because if we put them back before then, they're very much at risk of getting eaten by the bigger gators. Not that the bigger gators are, like, they're not cannibalistic. But that's just in their nature.  So once the guides catch a little gator, they stick with him, and they let him grow. And they introduce him to life as a tour centerpiece until he can swim by himself without fear. So why am I telling you this? Well, because this narrative perfectly frames the phase of a junior developer's life that I'm going to cover in this talk. If you think of the baby gators as junior developers, and the big gators as confusion and anxiety that can sometimes become so overpowering that they crush ambition, and the swamp tour guide as a mentor, I think you'll have a pretty good sense of the scope of what we're talking about. It's the time between being really, really, really small and being just big enough to get by on your own. And just like with the gators, this is a really critical time in a new developer's life. Because if they don't get the experiences and the training they need, you could lose them. So we're going to talk about how to be just tough enough on your little gator to help them grow, and we're going to talk about how to be a tough little gator on your own. So welcome. I hope you will enjoy it. Who am I? Quick bio. My name is Alice Natola. I'm a Rails developer here at Constant Contact. I studied a little bit of computer science in college, didn't major in it. After I graduated, wanted to be an actress. I went to theater school for a year, did a bunch of other stuff, planned birthday parties for the children of the 1% for a while. Finally decided it was time to come back to programming. I enrolled in General Assembly, which is one of the major developer boot camps in New York. Did that last summer. Started as an intern here in October and came on full-time in January. So that is my background. Now, a little bit of honest talk here. I'd be willing to bet there are a few people in this room who don't really think that training junior developers is a really important topic. You just really don't care about UIs or puppets, so you thought you'd come to this, right? Is there anybody? Be honest. Be honest. Please be honest. Please be honest. OK, we got one guy. We got one guy in the back. I might have a truly enlightened audience here, but either way, if you're not being honest and you really don't think this is an important topic, I'm about to convince you. So according to the US Bureau of Labor Statistics, the projected growth for software developers between 2012 and 2022 is 22%. That's a lot faster than the average, which is 11%. And that's awesome. That's great for us, right? So how are all of these new jobs going to be filled? Well, obviously, they're going to be filled with all of the people coming out of colleges and boot camps right now, right? OK, except there is one little problem. I did a little bit of investigative journalism. Went to Glassdoor.com. I did a job search for junior software, 8,874. Senior software, 89,451. That's an order of magnitude larger. Indeed, 16,000 for junior software, 116,000 for senior software. Career Builder. Junior software, 1848. Senior software, 12,042. And finally, Stack Overflow Careers. Junior software, 1600. Senior software, 1700. Well, it's different. Why is that? Well, this part drops into speculation, but I'd be willing to bet that the companies that are posting on Stack Overflow are more tech savvy. They're more likely to be software as a service companies. In general, they are more heavily invested in delivering quality software. And they're the ones that are hiring juniors and seniors at about the same rate. So why do you think that is? Because junior developers are good for your team for a lot of different reasons. They challenge more experienced engineers to clarify and refine their knowledge. And because practicing communication makes your team stronger. I was on a panel at Launch Academy recently with people at a lot of different levels of experience in the industry. And this one quality kept on coming up, that what they're looking for when they hire is not just a really great engineer, but someone who can communicate. Because as an engineer, you're going to be in a lot of positions where you need to communicate with people who might not be as familiar with technology as you. And mentoring is a great way to practice that. Finally, people do their best work when they're treading water. In the best case scenario, you can challenge everybody on your team all the time. But that's a lot harder to do if everybody on your team is really experienced. Junior developers make that goal a lot easier to achieve. So I get why a lot of people don't want to do this. Training is really hard. It seems like a risk because it takes a lot of time. But it doesn't really need to be that hard. We're going to go through three phases of the process. The phases are based on the noobs' comfort level. I'm going to refer to it as noob, because that's a lot faster to say than junior developer. And each phase covers advice for both the mentor and the noob. Now, you'll notice that these phases have no time estimates, because everybody is different. And you might even be getting somebody on your team who's at phase two or even phase three. So I'm not going to say you need to be in this phase for this amount of time. And one thing I want to point out is mentors. All of the noob advice can be helpful for you too, either because it's something you can encourage your noob to do or because it's something you actually don't do yourself. Phase one, learning to swim. So this phase looks like you know some basics, but you've never been in a large code base before, which is a really different skill from pushing out homework assignments in school. All in all, you don't have any experience working on a team making software that people actually use. For mentors. For the best case scenario, you can assign the noob a dedicated mentor. This should be somebody who's already a pretty good communicator and somebody who actively budgets time for the noob and will stick to that. Now at New Relic, they estimated that their onboarding time for new people was about six months, but then when they started doing this, that time dropped to three months. And that's a lot of time and money saved. So this is a really good process. But I want to make it clear that for the rest of this talk, I'm not assuming you have done this. You don't need to be a dedicated mentor to use any of these tips. You can step in and be a good mentor at any point in the process. So remember how important communication was? We're gonna talk about a template for that. Overall, when you are communicating with your noob, you wanna provide a framework for learning without spoon feeding all the answers. I'm gonna compare it to something you probably already know, the template method pattern. So say you have a class developer and that class does stuff. Debug, learn pattern, learn quirk of design. Some of those methods are defined in the developer class, but some of them are defined in the junior developer class which inherits from developer. Looks like this. And if you take a look at the methods that are defined in developer versus junior developer, you will find that they reflect an important guideline for what you should share with your junior dev and what you should let them figure out on their own. You fill in anything unusual or unique to your application and they fill in pretty much everything else. But I wanna make it clear that this is not a passive process by any means. The developer class, like you see, is defining the order and the framework for gaining the knowledge. They're just not filling in all the blanks. So let's drill down a little bit deeper. Never assume knowledge on the part of the noob to get a sense of the person's initial level maybe on their first day. You wanna quiz them a bit, but the language you use here is really important. You don't wanna ask something like do you understand nested resources? Instead ask how do nested resources work? Prompt an active response so that you start to get it back and forth and you can get a real sense of what their initial experience level is. If your noob doesn't know some fundamental things, have him go read about them. And if he has it covered, go ahead and start him on some simple assignments. Now, one thing that I think a lot of mentors forget in these early days is that their guidance shouldn't just be restricted to the technical realm, right? It's really important to introduce the team process and even tell your noob stuff like who on the team is working on what. That will help them when they have specific questions know who to go to later on. Because every minute that your noob spends wondering what they should do next or who they should talk to or if it's appropriate to ask this question is a minute wasted. And finally, be honest about your own limitations. If you're busy or you run out of patience, just let them know politely. And if you're confused, just go ahead and say so. That helps your noob get a frame of reference for what is actually confusing and what they just don't know enough about yet. Like, your noob might not even know that it's weird for logging statements to cause errors in production. So tell them that. Important, pair programming is critical at this stage. It's not optional. It's mandatory. And I think that's probably all I need to say about that. So phase one for noobs. Obviously, you need to be acquiring knowledge at this point. But the question is, how do you get the most bang for your buck? So the next thing that I'm going to tell you, if you're not familiar with it yet, it's really going to change your life. It's the single most important step you can take in going from being a passively smart person to a brilliant person. And this is what it is. Metacognition. Metacognition is your brain's skeleton key. I know the marketing is really bad. It sounds like kind of a scary word, right? But all it is is very active control over the processes involved in your learning. I like to refer to it as tightening the feedback loop with yourself because the idea is you want to develop a program that gets deeper and deeper and more specific as you practice it until it's on the level of like seconds, like a seconds long feedback loop. Like, did I just understand that? Am I going to go back and read it again? What do I do next? At this stage of the journey, you don't need to worry too much about the specifics of what programming knowledge you should gain. You can let somebody else worry about that for you. But the most important thing you can do for yourself now or really at any time in your life is develop conscious metacognitive skills. Metacognitive techniques can be divided broadly into three categories. There's planning and approach, monitoring the process as it goes along, and then evaluating the outcome. Now you'll notice as I go through this talk that a pretty large fraction of the tips for noobs fall under this umbrella. And there are a lot of different techniques that you can use. I recommend you research it on your own. But I'm just going to share a few that I have found helpful in my own experience. Set goals and expectations. And I like this Eisenhower quote. Plans are useless, but planning is indispensable. Because it doesn't matter if your goals change or your expectations come crashing down in the middle of the process. The point is that you might not even notice that things are going wrong unless you had an initial expectation to compare to. Now people do tend to do this for really big things, like something expensive, like starting a developer boot camp, or something risky, like an acquisition. But people overlook the fact that this is really useful for small things, too. It could be something as small as reading a book or checking out the documentation for a gem that you're about to use. The point is that you make the goal clear to yourself at the beginning so that as you're going through it, you can very quickly and easily check in with yourself about whether you're getting what you need out of the process. And to that end, it's best if you actually write the goal down, because you crystallize it explicitly in your mind. And then it makes it easier to go back and evaluate at the end. Empower yourself with curiosity. So new developers, especially if they're working in a large code base for the first time, they can often fall into the trap of feeling powerless against the code in front of them. Sometimes it's because they just don't know where to start. Or sometimes it's because they're making a lot of progress and suddenly they run up against a totally arcane error message. And it's important in the face of this kind of confusion to start out very early, reframing it in your mind as an opportunity for exploration and play. For me, hacker culture has been a really important inspiration in this regard. And I have noticed that there's a trend, particularly in the bootcamp community, to use the term hacking to refer to any kind of programming, especially programming done quickly. And I think that habit needs to be dialed back. Because if you occlude the definition of the term hacking, you're missing out on what it really means, which is something very specific and very, very useful. So obviously, everybody's going to have a little bit of their own take on the hacker mentality. But I like this one from Wallace Wang's book, Steal This Computer Book. He breaks it down into three phases. Stage one is curiosity. And at this stage, the hacker just wants to know everything about a system. He's not comfortable with just absorbing what's put in front of him. He wants to go and discover new possibilities on his own. Stage two, control. This is where the hacker gradually learns to control and manipulate the system through experimentation and play. And then stage three is conscious intent. Now that the hacker understands the system, he can set a goal for himself. And he will pursue it with relentless determination until he achieves it. That phrase, relentless determination, that's straight from the book. And I think it's really interesting that relentless determination doesn't come into it until stage three. Because the first two stages aren't about brute-forcing the work. They're about approaching it with a sense of joy and fun. Another thing I really like about this definition is that it has absolutely nothing to do with computers, right? So lockpicking is hacking. Social engineering is hacking. But spending the weekend guzzling free pizza and Red Bull while you bang out an app that helps people find cupcakes isn't hacking, which brings me to the next pitfall. Going mad with false power. A lot of new developers get wrapped up in the thrill of just writing a bunch of code. They're like, oh, I use Rails to build a blog in 15 minutes. I'm an awesome developer. No. That's one of the things we love about Rails. It lets us get a lot done without necessarily having a ton of deep technical knowledge, and it saves us from ourselves a lot of the time. But it can distract from the importance of thinking deeply and critically about code. So that's why if you're a new developer, even if you're not specifically interested in information security, I think it's still important to have your own version of the hacker mentality in mind. You don't ever want to let yourself feel powerless against the code in front of you, but at the same time, don't get swept away with the excitement of awesome tools. Having a mentality that leads you with curiosity and play will help you balance between these two extremes. Now we're going to get real specific. Memory palaces. So this is a neat trick that I've started to practice lately. It is an effective technique for encoding information into long-term memory. How effective is it? Well, it's been around for thousands of years. Cicero described it in his book, Day Oratory. So that says something about how useful it is. And how does it work? Well, I think the best way to explain is by way of examples. So let's say you wanted to memorize some handy array methods in Ruby. You start by imagining your childhood home. There's probably a common path you would have taken through your childhood home, like maybe from the front door through the living room, up the stairs, and into your bedroom. So imagine you open the front door to your childhood home, and you find that it's been co-opted as a set for a game show called Rotate That Array. And the host implores you to spin a wheel for the chance to win a brand new array. This is the Rotate method. But you're finding this whole game show thing really annoying, so you just yell drop array dot length, and the whole wheel disappears. That's the drop method. So you leave the host in tears over the ruins of his beautiful set, and you go up the stairs to your bedroom to find Romeo and Juliet in an embrace. But sadly, they're being pulled apart by two giant ampersands, and they're holding on to each other so tightly that as they're being pulled apart, their arms fall off, and all that's left in the end is a pile of arms. This somehow is the intersection method.  So it works by imagining a familiar place and a walk through it. And you add imagery representing what it is you want to memorize. You have to make the images as weird and outrageous as possible so that the memory actually sticks with you. And the traditional way is to use a familiar place, but I think it's also pretty fun to try using an imaginary place that has physical characteristics that represent the concepts that you're trying to memorize. So either way, choose your own adventure. There we go. So that's all for the metacognitive techniques for this phase. There is one more thing I want to mention about phase one. There is one thing you can do, even if you have no experience at all that will immensely boost your usefulness to your team. And it's this. Use the product. You might work in something like payroll processing where that isn't really feasible, but to whatever extent you can find some way to use the product for something that actually means something to you. It's likely that a lot of people on your team don't do this, so doing it will give you special insight that other people on your team might not have, even if they're experienced programmers. So summary of phase one. As a mentor, provide a framework for skill acquisition without spoon feeding. Be honest about your own limitations and pair program. As a noob, metacognition, and some other stuff that is not as important as metacognition, because if you get one thing out of this talk, it should be that. Phase two, touring the swamp. So this phase, it's different from phase one in that in phase one, you might have felt like you were just groping blindly through a totally unfamiliar landscape. But in phase two, the path is clear and the stumbling blocks are pretty well defined. You can work independently on small things, but you still need guidance pretty often, and you usually have a rough idea of what to do next, less often how to do it for mentors. So this is a transitional period. It's difficult to rigidly define what needs to be done. You can't plan it out ahead of time, so the theme of it is improvisation. And just like in theatrical improvisation, there are guidelines you can follow to make sure that the scene progresses. What you should not do is simply assign whatever happens to come up. I mean, there's gonna be a well-defined set of work that your team has to do at any given time, but the art is in how you delegate it. It's just like how a good improv performer can take a really boring prompt and turn it into something funny and original. You can take whatever set of work your team is given and turn it into a program that actually helps your noobs learn. Here's your objective. Keep your noob's head just barely above the water. Kinda like how decorators add functionality to an object at runtime. You improvise to add new functionality to your noob. Pay attention to what your noob has worked on in favor assignments that are harder or dissimilar. And if you don't remember what your noob worked on, just go ahead and ask. It's better than guessing what'll be right for them. One way you can help your noob stay challenged is to train her to look at her code with a pessimistic eye. You wanna ask questions like what could go wrong? What assumptions have we made that might sometimes be false? What would a null input do? Does this open any attack vectors? There might be times when the only work you can assign to your noob is stuff that seems a little easy on the surface. And this, aside from being a critical skill for any developer to learn, is a great way to add depth and complexity to stuff that might otherwise have seemed too simple. Noobs, if you are not lucky enough to have a mentor who can help you with this, it is obviously something you can train yourself to do, but this is one that I think is better acquired with a little bit of guidance. So while you're staying aware of providing your noob with a valuable challenge, there's one thing you should never forget, encourage. This could be something as simple as just saying good work, but another really good way to encourage is to tell your noob when his code has been deployed, because this tells your noob that his work matters and it also helps to familiarize him with the workflow if you have a team that, you know, where your process is a significant gap of time between writing code and deploying it, like most teams are that way, but not everyone. But telling your noob when his code has been deployed tells him, no, your code is not just being swallowed by a dark void. Sometimes it can feel that way when you don't have much experience. So the next tip, this is difficult to apply gracefully, so please take it with a grain of salt, but don't let your noob be a wuss. There's a senior engineer on my team who if I ever say something like, oh, I can't review that PR, I don't understand it, he'll just be like, since when are you such a wuss? And I really need that, but it's difficult to apply unless you know that you're gonna come off as having good intentions, so be careful. Phase two for noobs.  Be a code entomologist. You're probably gonna be debugging a lot at this stage, so whenever you fix a bug, think about what it was that you got hung up on when you were trying to figure it out, and through that develop a taxonomy. You wanna generalize the bug you saw as part of a larger category, and then think to yourself, how could I have figured this out faster? Now I'm just gonna throw out a couple examples of bugs that are in my taxonomy.   Now this may sound obvious, but once I learned to step back and smell that this was what was going on, I haven't gotten deep into a rabbit hole with something like this ever since. The next is the framework gotcha. Component of the framework you're using works in a way you didn't expect, or maybe it worked that way in the last version. The principle here, it doesn't matter what your classifications are, it just matters that you come up with them yourself. You wanna notice when you're deep in a rabbit hole, take a step back and compare what you're seeing to previously encountered bugs. And part of that is just going back and thinking to yourself, where is my understanding actually lacking? Because I can say from experience that the top one, when I step back, smells completely different from the bottom one, right? Because I do know, like I can tell when my understanding is complete and when there's stuff that's missing. And if you follow that scent, it'll make it much quicker to debug. Have opinions, even if they're wrong. This is like an amped up version of clarifying the goal before you start a process, because the important part of the idea is you don't have to be right. Every opinion has an emotional component to it, but it shouldn't just include how you feel, it should also include what you think. Like if you're trying to develop an opinion about the testing framework that your team uses, it's not just like, is this framework awesome or lame? Is it easy to read and write? Is it expressive? When you're trying to do something new that you haven't done before, how easy is it to just guess the language that you need? Because the easier it is to guess the language, then probably the better written the framework is. This can be a tiring habit to develop, it's not easy. But if you train yourself to do it, you'll gain a much better understanding of the philosophy of the tools you use, and you'll be able to use them better. You will learn faster and you'll remember things longer because you have an emotional connection to the material. And finally, it also opens you up to great opportunities for conversations with people who know more than you. Because if you disagree with someone, they'll be interested in talking to you. On the note of being wrong, review others' code even if you don't feel qualified. Thoughtful exchanges are never a waste of time. And you shouldn't worry about senior devs not appreciating it because they do appreciate having their work critiqued as long as you come at it with good intentions. Finally, for this phase, I think it's important to find an independent project around this time. It's the ideal time to do this because you're not as inundated with responsibility as you will be in a few months. And a personal project is okay, but you're gonna have a much richer experience if you build something for your company or your team because you'll have potential collaborators. You'll be able to actually test it and get feedback.  Using the product, as I mentioned in phase one, can help you get ideas for this. But if you can't really come up with anything that's kind of dependent on the product, an internal tool is always a great option. For ideas, just think about what would help your team be more effective, faster, more knowledgeable, or maybe make it easier for them to communicate throughout the day. Phase two summary, as a mentor, your objective is to maintain the correct level of challenge and your tactics for that are to improvise and to add depth. And while you're doing it, don't forget to encourage. As the noob, catalog what you learn from bugs, invite opportunities to be wrong and start working on an independent project. Phase three, swimming free. You still have a lot to learn in this phase but you can work independently most of the time. Your progress is gonna be mostly self-driven here and this, I think, is the best indicator that you're in phase three. Pairing sessions feel more collaborative than instructive. So as a mentor, the question is, how do you help a noob get from phase two to phase three? So it will happen with enough time but I think the best and fastest way to do it is through a rite of passage. In other words, an initiation. Initiation is one of the grand narratives of human existence. It doesn't matter who you are, you are familiar with some version of it. It's present in every mystical tradition and even in a lot of mundane traditions. Like Christians call it Dark Knight of the Soul. For Native Americans, it's a vision quest and for Frat guys, it's Pledge Week but the theme, the story is always the same. It's a difficult ordeal that when you pass it provides access to a new and higher state of existence. Initiation rituals do run the gamut in form but there's one that I think really perfectly captures the spirit of being a mentor. And this one comes from Joseph Campbell. So in the tribes of New Guinea, the young boys are raised to live in fear of these masks that the older men wear during their rituals. They see these as the gods, quite literally. And once the boy hits puberty, starts to get a little out of control too much to handle, the men, the older men one night they put on their masks and they go and they kidnap the boy, they take him to the woods. He's petrified, he thinks he's been taken away by the gods. And then he's forced to fight one of them, one of these men in these masks that he's feared all his life. So the fight, you know, he doesn't go easy on him but in the end the mentor does let him win. And then here's the really important point. He hands him the mask and he says, here you are, a representative now of the society that shaped you. So how do you be a good mentor? I think you have to fight your noob, let him win and then hand him the mask, right?  What makes an initiation? Well the first part is that it wouldn't be trivial for someone at a higher level. You have to set up a meaty challenge but at the same time it should be achievable for a noob. That's part of letting him win because every initiation needs to end in a victory or it's not really an initiation at all. Next, some initiations are solitary like the vision quest but one of the reasons I like the New Guinea ritual as an example is that it's not solitary. It's face to face and I think that's what you're looking for here. The mentor should have a very active role in the process. And finally it provides demonstrable and preferably quantifiable value to the team or the company. This to me is part of handing over the mask because it's saying you now have real responsibility and you've delivered demonstrable value back into the community. Now you are representative of the team that helped shape you. So by way of example I'm gonna talk a little bit about my right of passage. You might be familiar with the famous saying there are only two hard things in computer science, cash and validation and naming things. My right of passage involved naming cash keys so that they could be invalidated. The quote's not true by the way, there are a lot of hard things in computer science but let's stick with it for now. I'm gonna go pretty fast here because the point is just to show the complexity but if you are interested in more of the technical details feel free to find me after the talk. So our architect noticed that Redis was becoming a performance bottleneck in some cases and he wanted to switch our Rails caching over to Memcache D. Memcache D is faster and among its many optimizations it does not allow wild card matching. This was the way we used to invalidate our cache but now that asterisk was bad. So we had to get rid of it. What I needed to do was build predictable keys based on a set of attributes and each of these attributes could have a set of potential values, right? Sort type, request type, account ID, there were a few others. So when the cache is invalidated for a given account we had to build all possible keys and delete each one even if they didn't necessarily exist. That might seem a little crazy but of course it's much faster than a wild card match which forces a sequential search over every key value pair in the store. But then what if we added a new sort type later, right? The code shouldn't have to change so we can't hard code those potential values. So what do we do with them? Well, we store them in Redis. I thought we were trying to reduce the load on Redis while we are. So we had to add a thread safe key value cache in the controller. If the value existed in the class level cache then it was already in Redis so we didn't need to store it again and test all of this. So this was really difficult, took about three weeks, ended up being a 900 line pull request and finished it, cheered myself on for a little bit, forgot about it after a few days but then a week or two later our architect sent out this email where he showed before the deploy of those changes that was our response time after it went down significantly. So this was really like what sealed the deal for me and making me feel like I had really contributed and I was like a real engineer now. One more note on this process. I don't think that this was, I don't think this was set up for me intentionally or anything but if you do set up something like this intentionally for your noob, I don't think you should tell them it's an initiation. Part of why this process helped me so much was that everybody on my team really showed that they believed in me by treating me pretty much like a regular engineer. After the initiation, keep up the same communication style as before but a lot more hands off. A lot of the responsibility is off you now which we're gonna talk about in phase three for the noob but one thing you should do is introduce the noob to new ideas and if there are particular things she's interested in find resources and elaborate on them and help her kindle that interest. Phase three for noobs. Keep working on your independent project or start one if you haven't already. Start to code in your spare time if you haven't yet. If you've gotten to this level you might be surprised to find how easy it is to actually just go home after a day of work and start coding. It's a lot more difficult than phase one but by the time you get to here it won't be that hard. This is the routine that works for me. Directly after getting home whatever time of the day that is 15 to 20 minutes of meditation and then 45 minutes of creative time. Cap it at that unless I feel like I'm really on a roll. Creative time can be writing or coding or drawing but it can't be reading because the purpose of this is to shift your mode from a mode of consumption to a mode of creation.  And I just feel like I have to put in a disclaimer because I love Sandy and pooter is an awesome book but at this point you should have read pooter two months ago have those principles hardwired into your head and you need to read stuff that threatens to make your head pop off, right? I've actually found it not particularly easy to find challenging texts in the Ruby and Rails realm. A lot of stuff has like beginner to advanced beginners chunks punctuated by a few things you don't know but I do have a few examples that I think are really good resources for this kind of head twisting stuff. The first one is Crafting Rails Applications by Jose Velim, he's on the Rails core team and this book is about sort of recipes for things you can do with Rails that you probably wouldn't do on a daily basis and as he goes through the book you get a pretty good introduction to Rails internals too. Next is Ruby under a microscope. I haven't actually read this book but I've started it about 10 times which I think is a testament to how difficult it is. It goes deeper into the C implementation of Ruby and how it actually works. And finally, Tenderlove's blog is great. Tenderlove is famous in the community for being so damn funny but people overlook what a good programmer he is and there's a lot of stuff on his blog that is really sophisticated and he's also very, very good at explaining it so keep up with this one. Go to conferences, especially hacker conferences but that's my bias take. Really I think you should try some events that are outside the scope of what you do at work. And on that note, learn a new language especially one in an unfamiliar paradigm. I think that C or a purely functional language are good choices at this point because you can just go learn Python later. It's not gonna be that hard. Teach yourself design patterns. Design patterns are the most important thing they don't teach you in boot camp, right? They're also one of the things that separates a CS undergrad from a boot camp grad so if you don't know them yet, learn them. They're a very high return on investment for your time because they are easy to understand. You can probably walk into work and start using them tomorrow and they just make you a better person on the whole. I recommend this book, Headfirst Design Patterns. It might be a little confusing if you don't know Java but their approach is so good that it's totally worth it and by the way their approach is based heavily on metacognition so there you go.  Phase three summary. Mentor, set up an initiation once that's over broaden the scope. Noob, invite further initiations, learn design patterns and then be a mentor. So what did we learn? Here's a pro tip if you didn't listen to any other words in this talk you only need to get what's on this slide. In the first stage, metacognition.  Mentor at stage one, open all lines of communication with your noob, take an active role in determining his level of knowledge and be honest about your own limitations. In the next phase, the noob can apply their metacognitive skills to the challenges that the mentor poses to them and finally when the mentor feels the noob is ready set up an initiation once that's over it's on the noob to invite new challenges on her own. So in closing, as your mentor of the moment I want to assign a little bit of homework to be handed in any time before the end of your life but preferably like tomorrow. The process of learning and the process of teaching are deeply intertwined. So please take a moment, a few moments to meditate on this very important quote and see where it takes you. A true initiation never ends. Robert Anton Wilson, thank you. This is my references list. It's not an MLA format, sorry. This is really great, thank you.  I mentioned some of it. Obviously part of it as a new developer is don't feel powerless, don't feel afraid to ask questions is a big one. And as a mentor just don't ignore, don't let it go. I think that's the important thing. Actually I would say maybe the one thing is don't let your noob be a wuss. I know that's hard to apply but really don't let your noob be a wuss. Yeah, I would say nothing that I didn't cover in the talk. Yeah, you mentioned conferences. I was wondering what were some conferences that you as a noob found valuable and what about them did you find valuable? So this summer I went to Hope which is a hacker conference in New York and I went to DEF CON which is the largest hacker conference in the world. It's like 10,000 to 13,000 people in Las Vegas. I know hardly anything about information security yet so I was just going to these to sort of like break open my head and see what would happen. And what I found really valuable about them is the extent to which the people there own the technology that they work with and how they're totally unsatisfied to leave anything as a black box. There's also just an extraordinary streak of self-empowerment in that community that I find hugely inspiring and I think is something that you can apply to any aspect of your life. Others, I mean yeah, so the hacker conferences were big for me. Those are the ones that I've been to that are not in the realm of Ruby. I went to RailsConf 2 and it was okay. Hey, great job. I've got a sort of unorthodox question because I think right now a lot of people talk about noobs and imposter syndrome, right? Feeling like they don't belong but the beginners that I encounter that I experienced the most are very successful beginners and they're sort of like king of the noobs and so they tend to be filled with all this false confidence while they talk about their imposter syndrome and I don't know how to talk to them about how they aren't quite the hotshot that they think they are without just totally bursting their bubble and destroying their entire ego. So can you please do that for me? I would say don't tell them, show them. Have them go read. Have them go read the source code of a very complex gem, something like that.  Why don't you learn C? Like can you go learn C for me? You have something like that. Just up the scale for them. A lot of the reason that new people, and this is interesting because when I was first like interviewing for positions when I came out of General Assembly there was this one guy who was interviewing people who was hilarious, he was so brutally honest and he'd ask me a question when I was answering he'd go staring me in the face like literally like that and he was like the problem with all of you is that you have way too much false confidence. So yeah, that's a common problem. But I think the best way is to show them the scope of what they're really dealing with. I mean you can do that in any number of possible ways but I think just recommending new reading resources and having them read source code that's very advanced. You don't have to tell them straight up. You don't have to, they'll figure it out. All right, that's our time for now. So thank you again, Ellis.


Hello, I'm Leonard Diggins and I'm a candidate for re-election to the Arlington Select Board. My motivation to run for re-election remains the same as it was three years ago when I ran for my first term. First, I like learning just about anything, whether it is something completely new or a deeper dive into a familiar topic. Second, I like using that knowledge to take on big and complex challenges. And third, I love collaborating with people. I'll add a fourth motivation this time. That is, I love policymaking. I like taking a solution for a particular set of circumstances and generalizing that solution so that we can apply it to a broader range of circumstances in an equal and as necessary equitable manner. Most, if not all, solutions to complex problems involve trade-offs and I eagerly dive into the effort to find the balance that does the most good and minimizes negative impacts. Arlington is a wonderful town in a great region and with nearly 100 functioning boards, commissions and committees, it scores high on the meat of civic engagement. We have so much potential and indeed we are turning that potential into action. I am particularly excited about the young Arlington collaborative which we're in the process of launching. Leading the effort to create it was the most rewarding activity of my first term. Why? Because instead of setting it up as primarily an advisory committee to a select board, as is the transportation advisory committee and the bicycle advisory committee, I along with my colleagues on the select board put forth a warrant article asking Tom Meadie to create a study committee to determine whether and how to create a youth and young adult advisory board. The result is a young Arlington collaborative with a structure of which I can take only a small part of the credit. Its structure makes it one of the largest official bodies in town other than town meeting and it has capacity become the most inclusive and diverse group in town. There is nothing like it in the Commonwealth and I hope that Arlington will soon become a leader in showing the good things that can happen when youth and young adults become more involved in the government and their communities. Now, I've dwelt on a young Arlington collaborative because it elucidates my leadership style. I don't approach issues as if I have the best answer solutions. I approach problems thinking that I have ideas and my expectation is that any good idea that I have will become brighter with the input of others rather than dragging you to a destination or pushing you on to a certain course of action. I prefer to be side by side with you and changing ideas about how we can move forward together as we create more effective solutions, a stronger sense of community and a greater sense of belonging. Now, I have priorities such as one, creating more sustainable and affordable transportation and transit options. Two, working with the community and staff to develop a strategic plan for responsibly increasing new growth and three, making it possible for Arlington to develop more housing of all types, especially housing with those way below the average median income and those seniors who no longer want to or are able to physically live in their large and often older homes. However, the issues I take on ultimately depend on the needs of the community at any given point in time. I can make decisions though and when the time comes to lead, I do. Our form of government works best when every decision is not treated as a plebiscite. As leaders, we are at our best when we assess the quality of each argument and opinion rather than a number of times or how widely that argument is made. I have and I will make decisions, but I will evaluate and reevaluate those decisions. I will not hesitate to change my mind, should I encounter new arguments that guide me to different conclusions. Sometimes it's necessary to change course in order to ultimately reach our goals. Sometimes the direct course is not the most effective course and often slow and steady will prevail in the end. I am proud of the effort that I put in during my first term. I am grateful for the opportunity to have met and connected with so many more people than I would have otherwise over the last three years. I have been tremendously impressed with the residents and staff of Arlington and indeed all of my colleagues on this life forward as I've come to have a greater appreciation for how much we all deeply care about community and work on this behalf. I hope that you elect me for a second term and that we continue working together side by side to plot Arlington's path towards a more vibrant, inclusive, sustainable and truly amazing future. Thank you.


You know, the red line has been a consistently confusing factor of the One Piece world for many fans, a constant that like circumnavigates the globe. What? And I'm not about to make things any better because in reality, it is also one gigantic subscribe button specifically for the Grand Line Review, allowing everyone who reaches it to receive regular One Piece content uploaded straight into their YouTube feed. And you, my dear viewer, after your long journey of life have reached it. Enjoy. Hello and welcome to One Piece 101, the series that breaks down everyone and everything in the One Piece world and today that statement is being taken on a rather grand scale because we are going to be tackling the massive, massive task of breaking down the literal world of One Piece. And this is far from an easy thing to delve into because one of the greatest features of One Piece is its overwhelming mystery and the kind of endlessly expanding landscape before our eyes. However, after two decades of the series, we do have a very functioning idea of how this world is structured. And first and foremost, I will begin with the fact that One Piece is indeed set on a planet, a planet that is overwhelmingly dominated by water, much more so than our home of earth. Or at least I'm assuming that's where most people are watching this video from. If not, feel free to let me know. Otherwise, for the sake of ease of explanation, we are now going to invoke flat earth theory and smush this planet in order to begin building it. So the overwhelming majority of the series takes place within one particular stretch of water known as the Grand Line, which circumnavigates the globe. So I suppose just imagine a planet wearing a belt or something. This area of the world is extraordinarily volatile, dangerous and highly unpredictable in terms of weather. Thus providing a fantastic location for an exciting pirate-based manga. And at the same time, the Grand Line is populated with potentially hundreds of islands of varying shapes and sizes, some of which could be the area of a small deserted island, whilst others can be the scale of gigantic countries. But in keeping with the fickle weather of the Grand Line, the climate of these islands can vary rapidly, even for relatively neighboring islands. And these climates can be broadly classified into four types, being summer, autumn, winter, and spring. With some of your classic examples, including alabaster as a summer nation, drum island as a winter wonderland and dress-rosa as your spring paradise. However, autumn islands tend to be exceedingly rare in this series, so much so that we haven't actually labelled anything as an official autumn island as of yet, although it is fairly widely speculated that Wano would be an autumn island, given that its heartland is permanently draped in falling Sakura leaves.  And if you were to take one giant step out of the capital and venture into Seiringo, then you would find yourself in the depths of a winter island. And then there are also places like Punk Hazard, which have had their climates artificially created via a serious battle between Lugia double-foot users, as well as currently unexplained aberrations like Rygen Island, which is being perpetually struck by lightning. So there is no really solid classification system at play in this world, and each island will still present its own unique challenges. However, the Grand Line obviously does not exist in isolation, and in order for this stretch of water to be differentiated from the rest of the world, it is deliciously sandwiched on both sides by two thinner stretches of water known as the calm belts. And obviously these lengths of water also circumnavigate the globe, but as opposed to the Grand Line, the weather in this section is as the name would imply, perfectly calm. Beyond calm actually, I'd say nonexistent really, because somehow in these sectors of the world, there are no winds or sea currents, and everything is pretty perfectly still, making it of course incredibly difficult to sail across and actually access the Grand Line, or leave the Grand Line should one so desire. That's far from the most major difficulty of the calm belt though, because it is also the designated breeding area for sea kings, which are the absurdly massive creatures that can be found all over the planet. However, they are highly concentrated in the calm belt, meaning that should you sail into it, your chances of being destroyed or eaten by one are extraordinarily high. That is of course, unless you are an absolute boss of which the series does have a fair few, one of which I'd like to point out being Silver's Rayleigh, the first mate of the former pirate king, who is able to casually swim across the calm belt without any fear of sea kings whatsoever. Also in more modern times, the Marines have developed a method by which to cross the calm belt, which involves lining the bottom of their vessels with sea stone, which I suppose apparently repels the sea kings as if they were zubats in a rock tunnel. In actuality though, the sea stone just masks the appearance of the ships and renders them for all intents and purposes, invisible to the senses of sea kings. Now we have one more pretty big piece to place here, because while the world of one piece is predominantly composed of islands, it does have one crown incontinent, which goes smack bang here known as the red line. And it is a particularly long continent by anyone's standards. And just as with the ground line and the calm belt, it also circumnavigates the globe, just along a different axis. And I suppose you could say that the red line functions as something of a gigantic wall, because it extends 10,000 meters below sea level right down to the sea floor. And while its exact height is still unknown, it is certainly tall enough to be considered impossible, which isn't to say it's impossible to do so because the German kingdom, for example, have developed a technologically savvy way of climbing the red line with their ships. And we've also had at least one example of an individual who has painstakingly climbed up the red line being Fisher Tiger. And he did so in order to get to the one known settlement on this tall continent being the Holy Land of Marijua, which is where the world nobles reside and rule over the rift raft masses from afar. But the existence of the red line also has the effect of creating four more distinct bodies of water in the world, which are known as the four blues, having been divided into north, south, east and west blue respectively. And these probably represent what we would consider average chunks of water that operate very much akin to our real world. There is nothing particularly special or volatile about them, except I suppose you may encounter a sea king on the odd occasion, but otherwise these blues are all quite peaceful and reasonable areas of the planet. The one that we are by far the most familiar with in the series being East Blue, which is where we commenced our journey with one Monkey D. Luffy in the Goa Kingdom specifically. And it is also the home of iconic locations such as Shelstown where we found Zoro, Syrup Village where we recruited us up, the floating restaurant of Baratie, where we found our chef guy, Nami's home of Kokuyashi Village, as well as Log Town where Goldie Roger was executed and many, many more. As for the other blues, we know very little about them at this late stage, other than some scattered kingdoms and random fun facts about who was originally from where. Like for example, Nolan and the Lovnil Kingdom were located in North Blue, whilst Port Gastease was born in South Blue and O'Hara, Robin's home island, was located in West Blue, prior to it being completely and utterly destroyed that is. So they certainly contain great importance to the world and the series at large. However, what tends to happen is that prominent figures migrate from these blues and make names for themselves within the grand line. That's problematic though, because with the map as it is now, there is no way to access the grand line or any of the other four blues actually. For example, if I was to migrate from East Blue, I would either be met with the calm belt or the red line on all fronts, making any form of progress impossible. Before we get to how to overcome this problem though, it's actually very important to completely reshape this map for a second. Now previously I stated that the red line also circumnavigates the globe, which is accurate and wonderful. However, it makes the map that we are viewing incredibly inaccurate. To account for the fact that the one piece world is a globe, this is a bit trippy, but the fight and map ends up looking a little, something like this, which just to avoid any potential confusion because I know it will come up, this does not mean that there are two red lines. It is still one continent and when scrunched up into a ball, this map will become a flawlessly connected globe. Great, with that out of the way, it's now time to point out that the grand line is not in fact a singular stretch of water and due to the red line, it is separated into two distinct areas, one of which is referred to as paradise, whilst the other is labeled as the new world. And the reasoning for these names is that, despite how incredibly deadly and unpredictable the grand line is in general, the first segment is absolutely nothing compared to that of the second. Hence it being known as paradise by all those who have experienced the truly apocalyptic conditions of the new world. And the new world is also very notably the only area of this planet that is not currently under the direct rule of the world government. Instead it acts as more or less a lawless territory, primarily under the command of the four emperors, who are known as the most influential pirates in this world. But back to how we actually access any of these locations, this is where we introduce the concept of reverse mountain, which is a super tall point of the red line in which all four blues meet, and from which they may enter the grand line through the various scattered paths shown here. However, once entering the mountain, you have but one choice, which is to be ejected into the paradise section of the grand line. At which point we encounter another problem because even if you make your way around to the end point of paradise, you encounter the red line again, blocking your path into the new world. And unfortunately getting into the new world is nowhere near as easy as reverse mountain, which actually wasn't very easy to begin with, but you basically have two options. You either need to somehow get over the red line, or you need to go under it. Because there is a segment of passage available, a sort of tunnel through the continent, if you will, which will take one past Fishman Island. But this is important actually, because now we need to discuss the one piece world through a different lens, which is height and depth. Up until now we've mostly been considering things from sea level, which in this case is referred to as the blue sea. But the world of one piece extends far below and far above this concept. Firstly, making our way down, once we reach 7,000 meters below sea level, we hit an area known as the underworld of the sea, which is a position so deep that no light from the surface can penetrate it. So it's very spooky, dark, and full of all sorts of terrifying sea life. But then we can go even further down and at 10,000 meters we hit the sea floor, which is actually known to possess quite an array of civilized life, including the aforementioned Fishman Island, and in an incredible natural phenomenon, light does indeed reach this area of the world via the roots of the sunlight tree Eve, which allows everyone and everything to prosper. But then we can also go in the opposite direction as well and make our way up, and once we've reached 7,000 meters above sea level, we hit the white sea, which is heavily populated by island clouds, which are allegedly created by a particular element, the composer Seastone called Pyroblown, which is a fictional element, ejected into the air by volcanic eruptions, and then it binds with water vapor to create clouds of various levels of solidity. Some of them could be sturdy enough to walk on, for example, whilst others could mimic the properties of water and allow vessels to sail upon them. However, most of the more solid clouds are found once we reach the height of 10,000 meters, which is known as the White White Sea, which is another layer of sea clouds that includes prominent sky islands like Scypia, for example, as well as half of Jaya Island, which was sent up there by the knockup stream, which speaking of the knockup stream is thus far the only way that we have been shown capable of reaching the White Sea levels, which is an absurdly dangerous practice and not at all recommended, because apparently there are other much safer ways of traveling to this area, although none of them have been revealed to us at the time of this recording. But with that, we have the very basics of the One Piece world, and I would like to emphasize that this is not an exhaustive examination. Every new arc in the series tends to present us with new and conflicting information regarding the composition of this realm. And even with everything we do know, there is still an incredible amount of remaining mysteries, the most prominent of which being where is the Hidden Island Velaf Tale, the discovery of which theoretically leads someone to the One Piece and putting them on the path of becoming the next pirate king. And then there's also the entire realm of outer space, which I have decided not to touch on in this video. The rest of short life definitely exists out there as well. So there is an awful lot left to unpack, but I hope that this has provided you with some sort of solid grounding. But what do you guys think? Please leave your thoughts in the comments below or even join my Discord server. And if you're keen for some more videos like this, then please do go and check out some of my other content or even subscribe to the channel for more glorious One Piece business uploaded straight into your YouTube feeds. But for now, this has been the Grand Line Review and I'll see you next time.


Hello, everyone. My name is Reza and I'm a developer advocate at Tigera. Today, I'm going to talk about Kubernetes cluster mesh with open source Calico. I'm going to start with what is project Calico, then show you a demo and walk you through some of the stuff like BGP overview and cluster mesh. Alright, so what is project Calico? Project Calico is a pure layer three approach to virtual networking and security for highly scalable data centers. We offer Calico, a free and open source networking and network security solution for containers, virtual machines and native host based workloads. Calico supports multiple architectures and platforms such as x86 and arm64. So you can basically install it on any environment. This modular architecture make Calico a great choice for any environment and gives you the required tools to be in charge of your software defined networking traffic. As I mentioned, Calico has a modular architecture similar to Kubernetes. And it offers multiple choices that gives you the freedom to tune your cloud environment in a way that will be the most optimal for your scenario. Today Calico offers four pluggable data planes that can be switched on depending on your needs and environment. Standard data plane is based on IP tables that provides fast networking security and compatibility to all environments. Calico EVPF data plane is another data plane created by Tigera, which uses the power of EVPF programs to provide blazing fast networking and security for your environment. EVPF data plane offers capabilities such as complete coop proxy replacement, source IP preservation and DSR or direct service return. If you're running a hybrid environment, you can use Calico for Windows, which is based on Microsoft HNS and can deliver networking and security to your Windows nodes. WPP is the new US data plane for Calico. It was an external contribution from Cisco. Currently it is in its beta phase, which accelerates the networking experience by utilizing the power of user space programming. In fact, EVPF and HNS are some of the foundational technologies that provide networking, security, observability, image assurance and runtime threat defense in our enterprise solutions at Tigera. Our community has more than 9,000 Slack members and 320 contributors on GitHub. There are around 8 million nodes per day, which are covered by Calico, either people testing or they've been running Calico for six years. With that being said, let's get to the cluster mesh bar. Alright, I've got two clusters, two self-managed clusters that I created with Terraform. Don't worry, everything that I'm showing you will be available on GitHub, so you don't have to write down any codes or anything. It's just a QR code that I will share at the end and you can basically go through everything that I'm typing. So, and I've got a cube config file that has access to these clusters. Each cluster has a control plane node and a worker node. Alright, so first of all, throughout this video, I'm going to use dash dash context to switch between these two clusters. So cluster A is a cluster in AWS. It's on US West 2 and cluster B is another cluster on US East 2. Alright, so let's get started. So first of all, I'm going to tell Calico that I want to run BGP in my clusters. Now, in order to do that, I need to figure out an AS number or autonomous number. An autonomous number is more like an ID. It's a way for our cluster to represent itself as a router to other routers. I'm also going to write listen ports. This is going to be the port that BGP will listen on and form BGP connections on. There is node to node mesh, which I disabled. It is enabled by default and service cluster IPs. So this is very unique here because I do want my service IPs to be propagated when routing happens. We'll get to that in a second. Alright, so cluster A is going to be 6501 and cluster B is going to be 6502. Next, I need to create BGP peers. So this step is just to tell Calico that I want to use BGP. But in order to form BGP, I actually need to tell Calico that who's going to be my peer. For that, I can use another unique resource, which is called BGP peer, this is cluster A. So I'm basically telling Calico that use these IP addresses to talk to autonomous number 65002. And I'm going to do this same thing for cluster B. But this time I'm using 6501, which is the autonomous number of cluster A. Now that the BGP peers and BGP configuration is done, we can take a peek at what is happening. We can actually use a binary file inside the Calico node pod. So BERT CL is the binary that can talk to BERT who's doing the whole BGP peering and routing stuff inside the Calico node pod. Now if we look here, we do have two BGP peers, but both are stuck at the connect state. Well, this is because at the moment our two VPCs don't have any routes to each other. Keep in mind that I'm using two clusters in two different VPCs. So first of all, we need to figure out a way to establish a connection, either a VPN or a tunnel or any sort of thing. Now, since these two clusters are on Amazon, we could actually use something called VPC peering. So in order to do that, all I need to do is I need to get the ID of my VPC in the region USVS 2 and the ID of the other VPC in US East 2 and actually use a feature or use something called VPC peer connection. And that will make a request to enable a communication between these two VPCs. Now, since these two VPCs are using different IP citers, I also need to enable some sort of routing. So if there is any device in there that wants to talk to the other VPC, it needs to know where it should go to. So to verify, we could actually do context cluster A, get nodes, a wide, as you can see here, IP addresses are 172.16 to 107. And my cluster B adds 172.17 to 157. So these are slash 16. So the first two octets will never change. All right. So now that we got the cluster names and a VPC connection, let's go make a route. To create a route, all I need to do is figure out which routing table. So here, since I'm using tags, I can go ahead and say, all right, AWS, give me the route table that I have that is using this calico demo tag. And I can store this for cluster A and cluster B to environment variables. After it's done, I can actually go ahead and figure out what was the ID for my VPC peer connection. So here is the VPC peer connection ID. And store all of these in my terminal. So all I need to do right now is to just first, I need to accept the VPC peering connection. That means the previous step that we did with create VPC peering connection is just a request. Somebody needs to grant this request. So here, I'm accepting that request. Now the VPC peering is established. And now I can go ahead and use all the environment variables for route ID cluster A and peer ID to actually tell AWS that I want to be routing between these two VPCs. All right, now that this is done, let's go ahead and take a look at our BGP status again. Well, it's still trying to connect, but it can't. Well, one thing to remind you of is whenever you are using a cloud provider, there is a security group or some sort of rule that is preventing you from talking to other resources. By default, what each cloud provider would tell you is a cloud provider is secure and safe. And that is because in most cloud providers, there is an implicit deny for everything. I need to go ahead and say, all right, I need to enable this flow or I need to enable this communication to happen. So with that in mind, and if you remember, we're going to open the port 179, which at the start of this video, we take a look at it in our BGP connection configuration, and it was for BGP. All right, so here, I'm going to grab the security group that my cluster A is using. I'm going to store that ID into an environment variable. And then I'm going to authorize that security group to be able to communicate on port 179, if cluster B or cluster B cider is talking to it. So the cider is for VPC on the other zone. And I'm going to do the same thing for the other cluster done. So right now, if we take another look at our BGP, all the stuff are established. We can also use show route to see which routes are being propagated. So it's a good time for us to hit another problem. So let's see. First, I'm going to create an nginx workload on my cluster A. And I'm going to use service for it, a node port service. Next, I'm going to use a couple of commands to get that IP address to these services and pots.  All right. So first of all, let's do a curl. It's not happening. And let's do a curl for the service. Now both are not happening. Well, why? If you look, there is a route. So my pod knows where to go. But we need to know this. At the moment, every routing decision happens by our default gateway, which is Amazon. Now, Amazon doesn't know about the stuff that I have in my cluster. So these IP addresses, 1053, 105321, these are not the IP addresses that are inside Amazon Routing Table. Now, a neat trick that we can do with Calico is to tell each cluster that what are the IP addresses that are in the other cluster. And tell it to use encapsulation if it wants to talk to those IP addresses. So in order to do that, I'm going to create two IP pools for each cluster. And one is going to be services that are in the other cluster. And the other one is going to be the pod sider. Now, there are a couple of things that are very important. One is disabled. Now, disabled means I don't want Calico to give its local pods in cluster A any of these IPs. So that's why it's disabled. I also want IP IP mode, which is the encapsulation to be used whenever a traffic that wants to go through that IP address is crossing a subnet boundary. That means if, let's say, 105201 wants to talk to 105300, then it will use encapsulation because these two IPs are in different broadcast domains. So I'm going to go ahead and do the same thing for the cluster B part of the... All right. I'm going to do the same for cluster B here. All right. Now that we got the IP pools in place, let's go ahead and actually tell Amazon that we are using IP pool. Again, I'm going to create another security group that allows IP IP traffic between these VPCs. Next, I'm going to tell Calico that an external entity will send IP IP traffic to it. So be prepared to receive it. And I'm going to do it on both clusters. All right. Now that everything is configured, let's go ahead and run some tests. So I do need the IP addresses for the nginx pod. And I'm going to use my cluster B to actually make a workload and parallel this. All right. So at the moment, I'm in cluster B. I'm on another subnet and I can access the nginx pod. Let's try the nginx service. Now, this is not going to work. Well, because in Kubernetes, a service has a couple of key points or a couple of configurations that we need to be aware of. One is external traffic policy. So by default, external traffic policy is set to cluster, which is going to be problematic for our scenario. And we need to change that to local. Now, if we, again, go ahead, use the same IP address, it should give us some results. And with that, we have communication between these two clusters. That was it. I hope you enjoyed the session. And thank you for viewing.