2.16, so we'll get started. Hi everyone, I'm Kath Tornwall, and I'm going to be talking about painless test-driven development with Elixir and Phoenix today. So right now, I'm working at Everything But The House. I've been there for about a month. You can find me on the internet as kTornwall, pretty much everywhere. And how many people do not currently use test-driven development in their day-to-day work? Or maybe not familiar with what it is? Okay, so yeah, there's quite a few people. So I want to do a quick introduction to that, just in case you're not familiar with what it is. So what we do with test-driven development is start the development of our features by writing a test. And then the key piece of it is that you write the minimum amount of code to make that test pass. And that's really like the secret sauce because what ends up happening is you're not writing a bunch of code handle extra cases or code that might not ever be hit by tests that could cause unexpected consequences. Another amazing feature of test-driven development is you inherently get an automated test tweet. And having worked on several very large projects, this is critical. So I started out as a C++ developer and we did not have many automated tests. We needed like a QA ratio of like one QA person to maybe two or three developers. So it gets expensive very fast. And we didn't have that tight feedback loop that you get with test-driven development, which makes life so much better. I was actually really surprised. I only started doing test-driven development about a year and a half ago. It was the first time it was introduced to me. And I like immediately fell in love with it. So if the words didn't make sense, I tried to make this diagram for a class I was doing with women who, oh, excuse me, women who code. So this is kind of my day-to-day process of developing in Elixir and Phoenix or Ruby on Rails. I start by writing a failing feature or acceptance test. And that means running a test in your browser and having the computer click through the elements for you. And checking if everything looks okay. Writing the minimal amount of code to make that feature pass. Number three is me checking work with my unit tests. So if I'm writing some kind of service or piece of functionality that's a little complicated, I like to write tests that don't interact with the browser. So that's what unit tests are. And use those to check my work, keep me going in the right track. And then once the feature test pass, you've got a really good time to refactor your code. And so it lets you clean up everything that you feel like you did wrong before. And definitely me and probably one of my pairs at my last job as a consultant, at a consultancy. We definitely would write some pretty interesting code to start out with. And then we'd come back and make it something awesome and really easy to read. This quote kind of sums up test-driven development for me and how I feel about it. And kind of backs this entire story of painless test-driven development for me. I get paid for code that works. Not for tests, so my philosophy is to test as little as possible to reach a given level of confidence. By Kent Beck, who's kind of a big deal. He's like one of the main proponents behind test-driven development and agile development. So he's kind of cool and knows what he's talking about. So yeah, that's why I've kind of described why I love test-driven development. I make sure to use it all the time because actually I don't get anything done without it. I can get really distracted and it's something that just keeps you moving forward, especially after you spend time looking at cat gifts and don't remember what you were doing. Or if you dance along with the cat in check and then you, so what are you all doing here and why, what's going on? No. But yeah, a lot of people don't like writing tests and it's because it's super painful if you're not coming at it the right way. So what are some of the issues that people run into? Especially with Ruby, but even with Elixir now, there are so many tools. So I've took this from awesome Elixir, so that's just what's on that repo. It doesn't fit on the entire slide and you probably can't read it from the back of the room because the text is so tiny. Nightmare sometimes. It's also really hard to find test files. So right now my current job, I'm working in a monolith app and there's a ton of folders and being new to the project, I can't find anything. It's actually really hard to navigate find the file and then once you get in the file, where is my test? Some of these are hundreds and hundreds of lines long and it makes it not developer friendly. Acceptance test, the ones that interact with the DOM. Often require knowledge of the DOM to understand what is going on. So I've got an example of that that we'll come back to in a second. And I don't wanna debug my tests. This was probably one of my biggest gripes getting started because I didn't understand how to write good assertion messages and I would need to go debugging into the test to figure out why it was breaking and that just is frustrating because then I have to debug my code after that and no one wants to do that, you don't got time for that. So how do we fix these problems? After writing all of these slides, I kind of ended up at the conclusion that we wanna do a couple main things. Keep it simple, make it easy to understand and this will result in eliminating some major pain points in your testing practice. I do have a demo app that I've made to demonstrate some of these things. You can find it on GitHub along with my slides here and it's a little application all about my favorite game, League of Legends. So I had a lot of fun writing it and there should hopefully be some good test examples and if my presentation doesn't seem done, this is the reason why. I may have been playing a little too much this week. So the first problem I talked about was how many tools we have available to us. How do we fix that pain point? So it turns out just make sure you only include what you absolutely need to start with when you're coming into a project. The minimum viable tool set that I was able to come up with for my Phoenix projects is X-Unit, which is built into the language and then Hound. You don't need anything else to start with. At that point, you've got everything to click around, do your tests. Great, when you need to add tools is when you start feeling pain of certain, whatever issues that you're running into. Am I duplicating too much code? It's time to start thinking about those kinds of solutions. So one probably very common example and I do end up pulling this into most of my projects is using a library called X-Machina. It generates models for you. Like Factory Girl in Ruby on Rails. It's the same kind of thing. I'm also really interested in generating reasonable fake data for my tests. So it's like pseudo random to help catch any unexpected errors. Errors like full names, addresses. Oh, five-digit zip codes versus nine-digit zip codes. That was a big deal one time. A tool called Faker can help randomly find these kinds of things in your test. You can tell it what kind of data you're expecting and it will generate something reasonable for you. So when you watch your tests run, you still see things like John Smith as a user's full name. Next, if you can't find your tests, we can definitely work on making that easier to understand by trying to generate, create a system of organizing your test files. My favorite way to organize my tests is to match the directory structure of the files in my actual code base so that there's kind of this one-to-one correspondence that's super predictable and I get really confused sometimes. For acceptance tests, they're kind of special. They go into their own folders and for me, as a personal preference, I like to match my Phoenix routes because that's my mental map of my system but a lot of my coworkers really prefer using the actions as their file names or basing their directory structure around the models in the system and it's just what works best for you and your team. Either way, it works. You just need to come to one conclusion and not try to mix and match. Otherwise, you'll both be confused. Long test files are also a big problem once you're dealing with more mature applications but it's easy to break this down and I was working with a friend on this trying to understand how we could do this better. As I was actually writing my talk proposal, he ran into this issue and what we did, came up with was that you can actually break up these modules and make a folder with that name and then put test files inside that folder that describe the piece of the module that you are testing and that was a really smart way to kind of break everything up for us so that we could find the test that we needed to work on and not have some kind of monolith test file for a really big module. As an example, in my app, I have a library to interact with Riot's API for League of Legends and in the actual code, it's just one big file with get this, get that, get that but there's a lot of different edge cases here and configuration options possibly. So in my test, I ended up making a test just for getting champions from League of Legends and it's a really easy and understandable way to help break up your files. If you feel like you're spending too much time building up your test data, we can make it simpler by utilizing libraries for factories and the helpers. So like I said before, Xmakina is one of my go-to libraries because a factory girl, we used it all the time in Ruby on Rails and it works really well with or without Ecto so a simple function call will be insert, puts it straight into the database for you, handles all of that without any extra lines of code but it also gives you an option to just build the object without interacting with Ecto which can be really important. If you don't need to interact with the database, don't do it, it will make your test slower. So it's a really convenient way for defining one function to do a lot of different things. Another great thing is factories can act as documentation for what your models might look like if you've got a property called name. What is it? Is it a full name? The first name is green name, no one knows but your factory will probably tell you if you're using reasonable test data. So an example of factories that I've got, I keep it in my support directory under test and I have one named for each model and it's simple, it looks just a plain, we return a plain object using a special name that Xmakina is looking for and I can say this is champion one or something so I'm not using faker in this, I was playing around to see how sequences worked out and my test to maybe reduce the number of dependencies that I had and so I can generate unique names in that way and I feel like this is a really easy way to understand what kind of data that you're looking for in your app especially with more complicated applications that have large domain. Helpers, helpers are absolutely awesome. When there's complex scenarios that you need to configure, absolutely vital to kind of move that logic into its own little area. For acceptance tests in the browser, the one I need in pretty much every single application I've written is sign in. You want to be able to actually click through the browser, sign in your user, authenticate but you don't want to write that in every test because all your tests are gonna be with a logged in user pretty much so the helper we run pretty much all the time. It can also be local to maybe a test if you want to build a specific character in League of Legends to test in your browser or something, you might want to name it build Annie. An example for my friend's application is he was working on a football app and they are dealing with games actually in progress and if you can imagine the data model for that, it's super complex, you need to know each play, the game, what teams are there, what's the record, this and that and he needed to run several acceptance tests on this model. It would be very strange to write a factory for that so he has a helper to do that for him. So acceptance tests, I don't know how many people have written a lot of acceptance tests but they can be really hard to understand the code base I'm working on in right now. It's just like a bunch of CSS selectors in the test and I don't get what's going on and I have to like look at the DOM at the same time that I'm looking at the test to be able to understand that but we can make it way simpler. To start with this, I like to write the test that tells your user story the way that they would and that's why I absolutely love writing acceptance tests which I feel is maybe not the norm. So I started out really wanting to go into design and I really love user experience actually and I lean more towards programming because of my math background but I still have a passion for that so they should just tell your user story what are they going to do in this application and if you write these tests this way a good suite of acceptance tests will document how you would expect users to interact with your application and that is amazingly useful when you're bringing on new team members to a larger app. So as an example of what something interacting with the DOM might look like in an acceptance test I've got searching for a summoner. So if you go to my app, we're starting at the main page. We're going to type in a username and it should pull up the result. If you read this, we've got insert a summoner, navigate to slash, okay home page, fill field, search input, okay. Click the submit, okay, yeah, I get it. Current path equals summoners and we're looking for some element. That doesn't mean anything. Really, without looking at the DOM how are you supposed to understand what is going on? Make it easier to understand and there's something called page objects in Ruby on Rails concept there. In Elixir, we don't have objects so page modules which James thankfully corrected me several times before I submitted this presentation otherwise he said people wouldn't make fun of me. So page modules encapsulate interactions with the browser. It can be a whole page, common forms across the application, like a user sign up or a sign in or just the header to check if the user is logged in. This gives you great advantages. If you make changes to the DOM, the code only needs to be changed in one place which makes your tests so much less brittle. It's actually, it's really exciting and I get so excited about this. Functions in a page module could be actions interacting with the DOM or assertions or checks that are inspecting the DOM to see if we have the right data. So examples of functions would be things like visit to visit a page, view mastery which would be clicking on the masteries link here so I could say view mastery. Fill form which is really great for complex forms. One function call and that's the only place you're dealing with all of that logic in your test. Function names can be, functions can be assertions and usually we try to end those functions names with a question mark to make that distinction really clear. Something I have on pretty much every page module is current page so I know I'm in the right spot and then I might be looking to see if I've got certain data, like if I've got the right mastery on my page. I had an example but we will just go to the code. So that test, that was the summoner's test. Here's the code, I've got the code with the, without the page objects at the top and this is what it looks like when you add in page objects. So insert summoner name, same as before but home page visit, I don't have to think about where that is anymore, it's just the home page. And then home page encapsulates searching for a summoner by just making a function for it. We have got asserting that we're in the right place and then we can just say does it have the summoner? We're not interested with how the page object is figuring that out, we can just read it in kind of as natural languages programming gets, at least. So if we want to look at the page object, pull that up. So we've got just a simple module, I've got a module that I'm kind of acting as a base class in Ruby that's holding some common functionality like sign in and it includes the hound browser helpers. So that's all built into this object already and then you can see navigate to a summoner page, actually kind of a complicated string that really simplifies that and then it's got kind of the same DOM interaction but hidden away from the acceptance tests. Next, sometimes tests don't tell us why they're failing but we can totally eliminate this pain point by writing better assertions and this is something I struggled with a lot when I was starting out in test driven development. Assertions can be more than checks. If you think through the assertions that you are writing you want to make them so that they give you very easy to understand errors. So when you've got a long accessor chain maybe more applicable to Ruby but you could do it in Elixir you can use intermediate assertions to tell you which object is null a little more easily than if it just fails somewhere in the middle of this longer query. You can also check that you're on the correct path of your URL before looking for an element when you're on the total wrong page. That's probably the one that's the most helpful because acceptance tests take forever to run. So let's see, an example of this would be I've got, so like my show test. You will see this in every single acceptance test that I write now. Always check that I'm on the right page before I check for any more details about that page. Sometimes making meaningful assertions can seem really hard. So I was struggling a lot with this current page idea. I really liked it on a project I was working on but every time it failed it says expected truthy got false. But boy, where am I? I don't understand. So after really struggling with this for a couple months I realized I can make a custom assertion. XUnit provides a way to prevent custom messages on failing assertions. And I can leverage this to give me the information I need to understand why my test is failing. So now I can make current page say incorrect path expected summoners to be this. And then I realized, oh, the query string isn't in the current path object. Okay, that's easy, my test is just wrong. And so how I ended up doing this was adding a macro to the base page object. So I've got that in support helpers, page helpers. I thought, oh no. Never fear. You put it in the wrong place. Okay. So I put it in my acceptance test helper. That's correct. Sorry, I got totally lost. That's what search all is for. So I've got it as a def macro, assert current path does quotes. We grab the expected path as our assertion and then we can assert current path which is provided by hound equals expected path. And then the second argument to assert is a custom message which I crafted to actually give me the information that I've always wanted out of this assertion. And it's made my life so much better. I can't even believe it took me this long to try to think of how to fix that problem. Kevin probably hates me now after suffering through that on the project with me for three months. So that was how I kind of solved a lot of this main playing points in my tests but there's so much more that you can do with Elixir and I've got a couple other tips and tricks. Mix test has some really, really awesome options. If you run mix help test, you can see all of the cool things that they've been doing. My friend told me about trace one time which gives like this really nice test output even though it doesn't support asynchronous tests. I saw him running it and I was like, are you working on a different project? Like I thought you were working with Elixir. He's like, no, just look at this, it's sweet. So if you run mix test trace, it's gonna show me line by line what tests it's running currently and how long it's taking and I really like having all that extra information because you can kind of see what's taking longer than other tests and what's currently going on instead of just dots which always make me feel really nervous. So also there's a stale option introduced in Elixir 1.3 which runs only test files that have changed since you last ran stale tests and this is using something called I think Xref to determine what modules are used in a test and it's a really awesome option especially if you are doing test-driven development because it's going to find interactions that maybe you weren't thinking of when you were writing your code and running your tests before so that like random tests over off in the corner that fails when you like are like, yeah, I got it, it's done. Now it will run with this. So, huge help. I've also been using a lot of filters in my tests and before the stale change came in I was using a lot of the at tag current to mark which tests I was running with test-driven stuff and I haven't tested this but I'm pretty sure that stale's not going to interact well with your feature acceptance tests in the browser because they're not directly linked to any of those modules so this is something that helps me really drill into what I'm currently working on. So yeah, if you run mixed tests only current drills right down and it really helps speed up our process instead of trying to pick out the line numbers because the line numbers can change for your tests and then it runs who knows what. Another thing that I've been doing and this might sound weird but hear me out I've been limiting use of setup blocks. So things like sign in. Great, that's definitely belongs there because you're gonna be doing that for every single test but I've been setting up my models inside of like the test statements and I've found that way more enjoy to be a way more enjoyable experience. It's clear what the current context is and it's easier to create only what you absolutely need for that test especially if your factory as long as you keep your factory is nice and clean too. It can be really hard to figure out okay well I've deleted this model from this test I need to go delete it from my setup stuff and then like getting everything correct out of the context I was struggling a lot with that it was taking me more time to refactor my tests than I thought it should. So I started doing this and I've actually been really happy with that practice. Another thing which is super awesome with Elixir that you definitely can't do with Ruby is asynchronous browser testing. Ecto2 had some big changes that made it really easy to run asynchronous browser tests with Hound and Wallaby which I think was discussed in the last hour session. It literally cut test time in half on the consulting project I was doing in Phoenix and Elixir because we had some very intense acceptance tests. If you're interested in learning about it my friend who was working on that project with me wrote a blog post link will be on the slides on GitHub but I love to demo this because it looks so awesome. So what's going to happen is we're spinning up as many Chrome browsers as my computer has cores and it's running tests all at once. So even I've only got about 20, it says 23 tests and it will finish super fast compared to running it without that. I think that I have some API tests going and I think that was going a little slow but it's been very exciting to see that change in particular because I could actually run the whole test suite in my project whereas it was getting to the point where like, we'll run the feature test once in a while it's just taking too long and then we could run them all the time locally. It was literally like a life changer. Let's see, I also have things that I didn't remember on the slides. If you're interested, doc tests. I have no experience with them so I didn't feel super comfortable writing about them but it's really awesome. You can find it on eluxirling.com. Org, I think. So what they are is you write IEX statements in your docs and it knows to check that the return value matches what you would get as output in IEX and that helps keep your APIs in line and I think that is it. Any questions? We need a runner so thank you. So I'm not too experienced with TDD but I'm very interested in it and one question I have always had is what do you do after you're done with developing all the features? Do you go and write even more tests to ensure that you got all the coverage or is your testing kind of done at that point? Yeah, that's a really good question. So I kind of go back to that Kent Beck quote. I only want to write as many tests as make me feel confident in my code. So I try to write those upfront because it's going to make me write the interface, write the function calls that I need to make in my code. So when I write my interface first as a consumer it ends up actually coming out much nicer and it's exactly what I need because I wrote it as the consumer first. Can you give us some examples of when TDD hasn't worked for you? So yeah, that's a really interesting question. Definitely we don't use TDD when we're spiking out experimental stuff as far as when we don't know how something works we're not going to start writing tests because it's such an unknown. Other than that, I can't think of anything. Can you go into a little bit about what your designers give to you and then how do you write tests from let's say user storage or what do you base your testing off of when you write your acceptance tests? Okay, yeah, so as a consultant we were actually interacting directly with the clients and trying to understand the functionality that they needed. So a lot of it was actually us coming up with those solutions. Now I get cards and Trello and it's like still try to come up with, okay well this is what's going to solve that story for them and the test names end up being very similar to what you would get in a Trello card like user signs in or something like that and then the test itself it's me trying to pretend I'm the user going through those steps and writing down kind of the verbs of what I'm trying to do. Like I visit this page, I click this button, I sign it and I fill in the form, I click submit and then check that I'm signed in. So I think, does that answer your question at all? So the user stories are pretty much complete when you go to write your tests and then you just kind of mimic those as best you can. Yeah, pretty much and if they're not complete I end up writing them myself. There's someone in the back, sorry to make you run. I was very interested in diving into some of those tests. Actually ran some issues that said it needed the riot secrets in order to, but it didn't have the structure of what it actually needed. Oh yeah, so in the repository and I totally shouldn't show you this but I will and reset my keys. So I made a file called riot secret and those are now my old API keys. So that's the file you need. I'll make sure I add a template on the GitHub directory so that's clear. Perfect, thank you. Anyone else? Well thanks for coming and I hope you get to use this.


So this is something to have some caution around because you don't just go willy-nilly and send Kundalini up your spine and go and say, I'm going to open my Alta Major Chakra. That's actually dangerous. There is some order of business, if you will. And you really want to work through the heart. And so what we're putting into practice is not only just our conscious focus on the Alta Major, but also doing this with the right intentions.


Hello everybody, thank you for joining us. We have Karthik with us with this talk on CubeMe, this Kubernetes best practices. I think Karthik, you're good to go. Yep, sounds good. Thank you and welcome everybody. Thank you for staying late today. We're gonna talk about some Kubernetes stuff. This is gonna be like a fast kind of session because I was trying to cut down on points but then I thought it would be important to actually have them in there. So I want touch on the presentation bullet by bullet. I'll put the presentation in the link for download and you can just take a look at all the points specifically from that point of view. So welcome, my name is Karthik Gekwad. You can find me on Twitter at iteration one. I used to work at Oracle until a few months ago in their Kubernetes and Cloud side of the house but I recently joined a company called Verica and I'm the head of cloud native engineering. So I'm still doing a lot of Kubernetes stuff. So I mentioned, I was on the managed Kubernetes team for Oracle, then developer relations for Oracle Cloud. I've done a ton of stuff with respect to DevOps and Kubernetes, I have a course on Kubernetes and cloud native stuff on LinkedIn learning and all of this got started because I had a very popular Hello World Docker container on Docker Hub. So I've been kind of in the ecosystem for a really long time. One quick thing, if you wanna learn more about chaos engineering Verica or does the O'Reilly book Chaos Engineering written by Casey and Nora, you can actually get this book free, the PDF version of it because everyone keeps asking us, what is chaos engineering, blah, blah, blah? So you can get the book at verica.io, you know, slash book. So today we're gonna talk about Kubernetes and I get beginner questions about Kubernetes a lot and I think it's the best way to frame this conversation is to do it around three things, development and the architectural portion of Kubernetes and how you like deploy applications, DevOps and then if there are agile folks or management kind of folks in the talk, we could talk about enterprise transformation and how that plays a role. I already see questions. Okay, great. If you have questions, you know, yeah, you can put it in the discuss section. I'll get to it at the end and if not, you know, just find me in the lounge and we can talk about stuff. So let's take a look at development or architector specifically, whenever we talk about Kubernetes and building applications, at least talk about microservices and if you don't know what microservices are and if you're not sure kind of where to start with microservices, one thing I would recommend is take a look at the 12 factor app design. So this has kind of been around for eight, 10 years or 10, 12 years, I think, at this point in time and it's 12factor.net and it's built on some of the principles when Heroku was doing development for software design and deployment. They were like, hey, we should follow some of these principles to make our development and deployment lives a lot easier not just for development engineers but also like for the DevOps side of the house. So if you're working in really large companies it actually really helps out because you can bring the whole team kind of together. I had like a couple of more slides on that but I kind of hit them but they'll be in the slides specifically about what is 12 factor, et cetera in the notes. So let's move on to design patterns. When people talk about Kubernetes and if you've never used Kubernetes before the probably the place to start is it's called the Kubernetes deployment and deployment, there's many constructs in Kubernetes. So there's deployments and pods and services and when you look at it the first time this can be really overwhelming but I think like 70 to 80% of everything that people deploy in clusters that I've seen have been surrounding deployments. So it's the most common Kubernetes object that are used for applications that run inside of Kubernetes and deployment is basically like a specification you can think of it as a specification and in that specification it's used to create a replica set and then the pods is associated with that. The pods are actually the containers that package your application and those are the things that run that but the question that I get most often is hey I have this monolith application I'm trying to run this in Kubernetes and I don't know how to do that can you tell me more about the architecture? So if you take the specific use case in mind you kind of have two choices. So a good way to think of this is either you can take your big application and use a single deployment model or you can take your application and then if you have like developers that can help you can kind of break it up into do a multi deployment model. So what does this mean?  So if you're taking like if you have this one big Java file like a war file and it has all the different portions of your application you can take that and deploy it as a single unit or the multi idea is to kind of break it up before you bring it into Kubernetes and then run those as separate applications that might work together either like via HTTP or some kind of communication between all of the different components. So this is like analogy in the Java world is if you have like many war files for your app you would kind of deploy them as deployments in Kubernetes. Kind of moving on when you start running Kubernetes production it gets confusing. So when you have multiple deployments equals multiple pods and then when you're trying to deploy everything in once one common state that I've seen a lot is when pods take a while to actually come online and folks are like, wait, I thought everything is supposed to run in a timely manner what happens, but you end up in this weird state of like things actually not working or not running, et cetera. So what do you do? When you're building your YAML, your deployment YAML there's a couple of probes that you could use for this. One is called the liveness probe and the other one is called the readiness probe. I kind of think them more as health checks. So the readiness probe is where the user defines health checks that tells Kubernetes like when the container is ready to go and serve requests. So you can have like all the startup stuff that it needs to do if it needs to like configure talking database make the state ready, et cetera that the readiness probe will wait for the container and not start the deployment until all of those checks pass. And from a liveness probe perspective it's a health check to indicate whether like a container is running or not. So over time you can kind of check like an endpoint or run a script, et cetera to make sure that the container is still running okay. If that fails and Kubernetes will kill the container and spawn like a brand new one I put a link to the docs but this is something that people forget a lot initially. So it's kind of like a best practice to take a look at it. And then also when you're working with multiple deployments it's better to have like a version endpoint for your pods of containers. So that way you both like what actually running one strategy that I've started following over the past like five years or so is to basically be able to tie whatever's running in your production back to your source control. So I recommend like if you're using GitHub or something have a get hash that's deployed in your version endpoint. So you can say, okay I'm sure that I have this version of my code running in my production system. So you have some kind of tie back to whatever you have in your source control because typically what happens is you'll deploy these multiple times and then you won't really know what you're actually running in production. So it's kind of like an important thing from that standpoint. Let's kind of move on to a different section that I also get a lot of questions on which is authentication authorization. Basically there's two things in Kubernetes. There's the authentication portion and the authorization portion. If you've never dealt with this in Kubernetes probably the most important thing to realize is the idea of a user doesn't really exist in Kubernetes. So if you're in AWS or something like that and if you're trying to like use your AWS user inside a Kubernetes ecosystem like there's no like easy way to like plug those two things in, you kind of have to do all the management yourself to do that. So basically, but that being said there's actually many ways to be able to authenticate. So that's kind of nice. And there's a bunch of ways you can kind of take a look at the docs for which way might suit your specific use case the most because there's kind of different ways and enterprises have different ways of doing that. But the most important thing is make sure you actually pick an authentication for your cluster because if you don't pick an authentication section you can't actually pick an authorization strategy and that's actually ends up being more important. And a lot of applications today actually expect you to have like an authorization strategy for your cluster. So if you don't have anything then things start to fall apart. In terms of like what to pick for authorization there are different modules for it. And probably like the only thing to talk about here is there's two big ones in the ecosystem. There's attribute-based and then there's role-based. Activity-based was like the first model that they had created so you end up finding like a lot of documents, et cetera for that. But truth is everyone has kind of evolved and actually ends up using RBAC. So use that as your standard versus something else like versus A-BAC or something like that. You can also use multiple authorizers together but there's very like small subset of use cases for that. If you want to learn more you can come chat with me in the lounge after that then I can tell you some stories on using webhook and RBAC together. So logging and monitoring, this topic ends up being very important to the DevOps folks and how do you kind of go about that? You know, you can actually run a QPCTL command called QPCTL logs and you can follow logs, et cetera. But we all know from experience that you never catch the issues at the time. You're actually trying to find like past issues. So how do you look at log files beforehand? So think about logging and monitoring early on before you go into production with Kubernetes. And more importantly, the thing that's essential is to tell your engineers how to actually use the tooling. So how to actually debug and monitor because otherwise there's this time gap of, okay, we're in production, oh, something went wrong and hey, there's a problem with your code and then nobody knows how to use EFK or Prometheus or Datadog or whatever tool they're using. So yeah, basically like more time friend to play with the tooling gives you lesser time to actually debug productions. So in terms of like specific recommendations or tools, et cetera, if you're going to open source route, there is the EFK, which is the elastic stack, Cluenty and Kibana for logging. You know, if you're in an enterprise, you already use Splunk or you use Sumo Logic or something that those have adapters to Kubernetes. Same thing for monitoring and observability. If you're doing it from an open source point of view, Prometheus and Grafana are like the two major ways, but if you use something like Datadog or any other tooling, those have like see, that has Kubernetes plugins as well. So all of this stuff wouldn't really exist without containers. So what are some best practices? Containers are based on images. So from an image perspective, the smaller the image, the better. So there's less things for an explorer to attack and also like from a practical basis. If you have a, you know, a one gig image that has like all of the Java JDK, et cetera in it and everything that you need. And if you don't need it, like why actually push that and pull that every single time. Also, this is more specific. Don't rely on the tag. A latest image yesterday might be different from what is today. It might be different from tomorrow. So you might not know what version you're actually running with. So it's better to tag it with a specific version that you're operating with. And also like consider using a private registry. So, you know, you're, it's a lot of like company IP that you're storing. So, you know, enterprises have different concerns for data storage.  So, you know, if you're in the cloud, a lot of every cloud provider has their own registry that's a little bit more secure than using Docker Hub. So, you know, consider something like that. So moving on to the DevOps side of the house. The most common question is like, should I install my own Kubernetes or should I use a managed service? What do you do? So pros and cons, from a cons perspective, it's not 100% customizable. If you're using, you know, like EKS or, you know, Azure Kubernetes service, there might be hidden costs.  So there might be like hidden costs like that. But from a pro perspective, you are not, you don't have to care about the control plane management. So the provider handles that for you, there's a lot less maintenance that your DevOps team has to handle. And you're actually spending more time with your applications and the nodes that support the applications versus, you know, like, oh, why is, you know, why is to bled down on a specific node, et cetera? So moving on to what are different strategies for, you know, depth test production. I think I have two more minutes to go. So I'll kind of go a little bit faster. But I think there's two primary strategies. It's either use different namespaces in a single cluster or different use different clusters for depth test production. Most folks that I talked to, like I think two years ago, a lot of people would use, you know, different namespaces for depth test production inside one cluster. This was because it was actually really hard to, you know, create a Kubernetes cluster. But I think most people have kind of evolved to using multiple clusters for, you know, one for dev, one for test, one for production, et cetera. So there's like separation of concerns and it's become like really easy to, you know, be able to create clusters, especially if you're using cloud. So that's my recommended approach for enterprises, especially if you're using, you know, any of the big four cloud providers. The con is that you do have more environments to manage, but I think that outweighs the benefit of, oh, I broke development. And as a result, I also broke production. So tagging nodes, all of these things, you know, when you're running your workloads, you run them on nodes. And if you have like multiple clusters and if you have three node cluster and if you have like five different clusters, you already have 15 nodes. So, you know, Kubernetes has a concept of tags. So use those tags to tag the node. So when you look at your AWS screen, you can at least know like what nodes came from what cluster, et cetera, that you can, I have a link to the docs over here, but, you know, more importantly, just remember to tag your nodes. And then from a pipeline perspective, consider using a pipeline. So, you know, I can talk about this more in details when, you know, it's folks that are interested in the lounge, but you can kind of accomplish all these four things using CICD tooling, you know, we at Verica, we end up using serve tag behind the scenes to do a lot of this work. So you can kind of like, you know, follow a similar infrastructure. And then from a transformation point of view, I think the big thing is like, where do we start? How do I do this? So my recommended approach for folks that are new to the Kubernetes ecosystem is like, get some experience with Kubernetes first.  Like, make sure it actually works with your workloads, you know, take an application, either split it apart or run it as a single thing, convert that into Kubernetes. And then take that application and, you know, promote it to run in a production setting and then understand how to do the DevOps stuff behind the scenes for that because, you know, it's easy to build something for Kubernetes, but it's harder to figure out, you know, when things go wrong, how do you manage that? And then, you know, once you're comfortable with one app, you know, you can add multiple things in there. That's how like most folks, you know, take a look at this. And also from a high level, like know your team, every organization is a little bit different. So build your cloud native transformation around your teams. If you're very DevOps heavy, you know, you can do a lot more things from that standpoint. And so, but organize into like development DevOps and SRE teams to kind of use the different, you know, the different facets. Also leverage the community for Kubernetes and cloud native is really big. So leverage open source technologies where it makes sense. And you can take a look at the landscape on cncf.io. So have, I guess, I am out of time. Thank you so much, Gayate, for being with us.


The Linux Foundation is a fraudulent organization.  Most of them are using Macs and they're using proprietary software such as the software from Adobe to create their presentations and reports and things like that. And it bothers me that you have people that work at the Linux Foundation and most of them are not even using Linux as their operating system. And I'm not just talking about GNU slash Linux which they really should use that but even the proprietary operating systems that use the Linux kernel. I mean, these guys are not running Chromebooks and they're not running Android devices. No, they're all running Apple products.   They don't even use their product. A couple of years ago, the president of the Linux Foundation, Jim Zimlin was spotted using a Macbook to give some presentation or something and that caused quite a stink but a lot of people just kind of brushed it off. Maybe that was a one time thing. He probably has machines that run Linux but he just happened to have his Macbook that day or something but no, this is a recurring theme because just yesterday I came across a Twitter post that basically took a screenshot of the Linux history report. So there is a Linux kernel history report that the Linux Foundation puts out, I think every month or so. Anyway, this guy downloaded the PDF of the report and was checking the about information of the report and it shows that this was created on a Mac using some Adobe software. Matter of fact, I can show you guys this on my computer. I downloaded the report myself and if I open it in my PDF viewer here and let me go to properties, I will get this window that pops up and look at this. This was created by Adobe InDesign 15.1 on a Macintosh. They created the 2020 Linux kernel history report published just a few days ago, probably August 2020. They created this on a Mac using Adobe software. Now again, we probably shouldn't be shocked at this because it's long been known that the Linux Foundation is dominated by corporate interests, business interests. This is not a foundation that's out there fighting for free software or open source software or digital rights, digital privacy, things like that. That's not what this organization is about. It's all about business, it's all about making money. And if you look at the Platinum members, which is the highest membership of the Linux Foundation, you have companies such as Facebook, Google and Microsoft and those three companies really dominate the Linux Foundation and dominate Linux development because those three companies are heavily invested in Linux. Google makes several operating systems that use the Linux kernel. Of course, Microsoft does a lot with Linux, with Azure and the Windows subsystem for Linux and all of that and Facebook probably has millions and millions and millions of Linux servers. So they have a lot invested in seeing Linux developed but Facebook and Google and Microsoft and all these corporate interests, VMware and Intel, they are pushing for Linux development in certain directions, directions that benefit their companies. They want, what Microsoft is trying to get things put in the Linux kernel that benefits Microsoft, that benefits the Windows subsystem for Linux and things like that, they're not interested in helping the broader Linux ecosystem. That's not what Microsoft is interested in. That's not what Google is interested in. That's not what Facebook is interested in. And all three of those companies have seats on the board of directors of the Linux Foundation and it frustrates me that they are using the name the Linux Foundation. I don't care necessarily what people do but they're putting it out there. We are the Linux Foundation. So many of us in the Linux community would assume that they are ideological and is out there standing up for open source and doing what's right, but they're not. These guys don't care about Linux. They don't care about Linux at all. They don't care about Linux as a desktop operating system or even a server operating system. Much of the work that goes on actually in the Linux kernel these days, much of that is really for Android and increasingly Chrome OS because of Google's influence, you know, pushing things in that direction, which brings me to this point. I wonder what Google, who is so heavily invested in Linux and the Linux Foundation, I wonder what Google actually thinks about all these people with the Linux Foundation using iPhones and using Macbooks, right? It's like, hey, we're giving the Linux Foundation all this money to help develop the Linux kernel because we need it for our operating systems but the people at the Linux Foundation, they obviously don't care about Google's operating systems. They also don't care about the GNU slash Linux operating systems.  They've got all the i-devices, it's crappled all the time at the Linux Foundation. What bugs me even more is the guys at the Linux Foundation obviously don't care about open source software at all. They don't care about the open source movement, right? They're not trying to change hearts and minds because if you were, you would be using open source software. These guys are using Adobe software, proprietary garbage software to create their reports and PDFs and presentations and images and everything that they do at the Linux Foundation is done almost entirely on proprietary garbage and they're not running open source software at all and that should just raise all kinds of red flags especially those of us in the Linux community and I'm talking about everyone, not just people that have a platform such as me because we all are on social media and everybody has some kind of platform to speak on and we all need to start calling out the Linux Foundation for their hypocrisy because this is complete and total BS that you have Linux in the name because they're milking Linux, right? Having Linux in the name, having the Linux trademark as part of the Linux Foundation, they're just milking that because they know they've got so much of the Linux community fooled because we think they're ideologues. If you wouldn't call yourself the Linux Foundation unless you really believed in Linux unless you really believed in the open source movement when all these guys, all they're about is making money. So this has angered me enough that I think what I'm going to do is I am going to email these guys and let them know what I think. So if you go to the Linux Foundation website at linuxfoundation.org and find their contact information you will see they have a general contact email at info at linuxfoundation.org and I'm gonna email these guys and I'm gonna let them know what I think and I think all of you guys, if this bothers you you should email them and let them know what you think. Let them know what you think about folks at the Linux Foundation using proprietary operating systems and not just proprietary operating systems. They're using proprietary operating systems that don't even run on the Linux kernel and they're using proprietary garbage software like the Adobe products to do basic work, you know, PDFs and presentations and things and they're doing this not just for work at their house or whatever. I mean, this work is being done for the Linux Foundation. That PDF file that somebody created on a MacBook using Adobe, that was done as work for the Linux Foundation for a Linux Foundation report. These people are not even invested in Linux and I think we have to start calling them out on it. Now, before I go, I need to think a few special people here. I need to thank the producers of the show. I need to thank Michael, Gabe, Corbinion, Mitchell, Devin, Fran, Hakami Channel, Chuck, Claudio, Donnie, Dylan, George, Kellogg Devils, Lewis, Paul, Scott and Willie. These guys, they are my has-eared patrons over on Patreon. They are the producers of this episode. I also need to thank each and every one of these ladies and gentlemen. These are all my supporters on Patreon because this channel is supported by you guys, the community. If you'd like to support my work, look for DistroTube over on Patreon. All right guys, peace.


Welcome back folks. Dow industry is down 20 in Essex, up 52, S&Ps are up 8. Let's get over to our man, Mr. Fred Ernest. Fred is the president and CEO of Vistagold. I happen to own Vistagold. Vistagold is building shareholder value with one of Australia's largest and most advanced undeveloped gold projects. There's no doubt about that, man. Welcome back, Fred. How are you doing? Very well, Tom. How are you? I'm doing great. I'm doing great. Well, you know, I saw the news release you put out on May 25th, so tell us a little bit about that news release. Yeah, really quickly, you know, we have an agreement with the Northern Territory government whereby they have retained the environmental liability for the project site up until the point in time that we make a definitive investment decision. That was renewed. That agreement is now valid through the end of the year, 2029. And we're really excited about it. I think it's a demonstration of the outstanding relationship that we have with the Northern Territory government. I can see that. I can see the context of when you're actually negotiating with other companies. I expect that's really important, right? Absolutely. You know, just having runway, knowing that there's, you know, the comfort zone of being able to advance the project, go through the studies that need to be undertaken without having the government, you know, breathing down our back is certainly a huge advantage for companies that would be looking to partner with us on Mt. Todd. Sure. Now, Fred, does this have to do with that, you know, at one time, you know, this was a mine, right? And then so is there water in the mine? What does this have to do with? Does this have to do with a legacy issue from a long time ago? Absolutely.   I see. We get a lot of water and, you know, the government looks at it from the point of view that these are things that need to be reclaimed. We look at it as, you know, this is infrastructure and things that we'll be able to utilize. And to reclaim them as part of the mining operation will be part of our bond. So the government maintaining that liability up until the point in time that the decision made to develop the project is a tremendous advantage to us. Wow, that is really cool because when I read that, I really didn't get that. I got the aspect of, I thought it had something to do with the licensing that you have that much more time in order to make a deal with someone else. So that's a lot bigger than that. That is really cool. It's both. Yeah. It's really big. Yeah. So let's talk about the mine. I have the presentation because I know you come up with another presentation on the first. And so I have your presentation up here. I mean, this is, there's a lot of infrastructure here, Fred. There's a tremendous amount of infrastructure. You know, we mentioned the tailing storage facility. It has capacity for the first 80 million tons. That's roughly a third of the reserves of the project. There's paved roads to the site, power lines and natural gas pipeline. And we plan to use that pipeline to generate power with our own power plant, allowing us to generate power for somewhere between a quarter and a third of the cost of buying it from the grid. You know, there's just many things that were built and paid for by the previous owners and operators of the project that we're able to take advantage of that give us, you know, cost advantages and time advantages. We just don't have to take the time to build some of these things. Yes. And, you know, the bottom line is that, I guess, when we're talking about when this mine was operating versus where we are now, I mean, we have gold that's running at 1979. I suspect when, you know, when you guys had come into this project, I believe gold was like it bellows, right? It was like 280 to 320 or something, right? The mine operated in the mid 1990s, it shut down in 1997, operated again for a year in 2000. In that period of time, the gold price was in the range of a low 260 at a high, you know, 380. I mean, we're in a tremendously different environment today than what those operators faced in their day. You know, it's amazing Fred and folks. I started the gold report in 1998, I think. And Merrill Lynch had one of the best commodity desk, and they were shutting it down. Whenever the gold was 282, because I got into a 252, but it's so weird that that happens a lot. Merrill Lynch had one of the best commodity desk in Europe. They shut it down. They opened it back up like six years ago. But it's like, it's wild that that's what does happen at severe lows, right?  Yeah, it happens. It happens a lot, Tom. It happens in a lot of industries. You know, it's really a credit to those who are persistent and have the foresight to buy things when they're cheap and to buy things when nobody else wants them and to hold on to them because they're the people that actually realize the tremendous value creation. No, I agree. Someone told me a quote, and I'm sure most of us know it. You make money buying at the lows. It's not the selling. It's really making the money buy-in right, right? I mean, that's what it comes down to. So that we have the project now where, you know, at the 1979, things are still tight, you know, interest statewide, but it's going to get intriguing here, Fred, because, you know, the way that the Fed fund rate is looking right now is that we won't go up in rates in June, and, you know, we'll see what happens in, you know, the rest of the year. But I'm sure that that's another maybe more wind at your back if, in fact, these rates have topped out. Would that be correct? Yeah, we believe so. We believe so, Tom. And, you know, the other interesting thing is that the gold price typically lags some of the other indicators. Yes. While we have a really good gold price today, we believe that there's strong reason to believe that in the coming year, two years, three years, that we're going to see tremendous increase in the gold price, which will drive considerable value creation for VISTA shareholders. No, I can see it, because what happens, folks, is this, is that when the rates top out, it doesn't mean inflation's topping out. So that's when everyone's going to go into gold. They don't have much choice at this time, Fred. We had a couple of banks go down, right? And then all of a sudden it's like, OK, we got to bring things a little bit slower, you know? So it's really intriguing. And so they, I'm sure you're still out there, you know, looking at all these different companies looking at this project. Yes. You know, there are companies that are still undertaking due diligence. We continue to knock on doors to sign confidentiality agreements. And we'll see where this goes. I love it. Well, listen, it's always a pleasure, Fred. You have a great one. Safe one. We look forward to having you on again. All the best, Tom. Thanks, Fred. Have a great one. Have a safe one. Stay right there, folks. We'll come right back.


You ever hear of Butterfly P flower tea you ever wonder if it might be good for low-carb keto or carnival people Hey there and jrude22.com here with another low-carb keto carnivore chat and today it's about this product I found it's called a Butterfly P flower or a blue Butterfly P flower tea Can't remember how I found I think they had something to do with some benefits and health benefits And it might have been low-carb too. I got it from Thailand. I bought it online There's a link in the article here and in my blog post on njrude22.com The coolest thing about this tea is and I think this is the most fascinating thing is that it's color changing tea When you brew this you get a little steeper thing. I forget what they're called, but I this metal mesh thing I shove a couple of these dried flowers into the mesh and I steep it for you know 10 or 20 minutes And it's blue and you can see from the color here. It's blue and this is not very good Picture you're excited steeped it for a long time. So it turned really dark blue But you add some citrus juice like lemon juice for instance and it turns purple. Whoo It's really cool. It's like a magic and if you don't want to use it for its supposed health benefits It's a fun mixer for drinks when you're making drinks You know, I should have brought my drink out But if I sometimes when I make myself as I put a little splash this in there make some blue or purple It's also fun to show your kids like wow. How cool is that? It's neat on that aspect alone Apparently this I guess they can prove that this has good vitamins and minerals such as calcium magnesium potassium zinc iron manganese and sodium I didn't put this in my show notes here But I think this might be good to drink for a hangover as well. So if you ever have a hangover I'm gonna try it tomorrow when I'm hungover. I'm gonna drink. I have one sitting in the fridge now In fact, that's the picture you see in this video. I'm gonna drink it tomorrow morning first thing Instead of having my coffee.  I have heard about antioxidants for a long time I I has anybody ever proven that they work. I don't know Here's what some of the benefits are and they like I'll rattle off a few here like the antioxidants They can fight off free radicals. Also is apparently anti-inflammatory Inflammations, I don't I don't know. I guess if you're just bloated, I don't know I have a swollen knee and it's also supposedly supposed to help with fatigue Like and this is for people suffering from chronic fatigue. I don't have chronic fatigue.  So I don't know It's also anti-diabetic. It's supposed to regulate blood sugar levels If you're low carb or carnivore, you're not going to need any anti-diabetic Properties in anything and it's also supposed to be good for stress and anxiety if you're stressed out or if you have trouble sleeping It's supposed to help you relax a little. I don't know about that as well And if you're asthmatic, it's supposed to help with that and also if you ever have a cold and it helps respiratory problems Which I think it might be something worth considering considering this considering considering This whole big crisis that we're having now It might be good to have if you get the flu this year and they also say it's good for your hair and skin I mean we have nice hair and skin already. I don't know if it's just getting better. It's staying the same Don't know it's supposed to have a good effect on the stomach if you have an ulcer Apparently they use it to treat ulcers worldwide. I guess it's one of these homeopathic or whatever these homemade things I don't know. I think it's a neat drink and I can't say if these claims that are made are true They have studies out there and apparently they did it and they said it it worked. I don't know It doesn't really have much taste. You have to add or lemon to it to have any taste I just think it's fun to have and if they're in the small chance that these things these wonderful things They say about this tea are true. It's fun. I think I paid 15 bucks I got three of these bags. It took a month to get them from Thailand and I'm still on my first bag It took three over three months So like three bags will last you almost a year if you drink one one or two Big things a day. So I think it's worth it. Give it a shot I mean you'll see the link in my my article in and below this video too. It's like 15 bucks It'll last you a year. It's and it's a lot of fun So if you like this video, please hit the bell in the subscribe and look at our other videos Then I'll see you next time


Kitty Hawk 1903 the success of the Wright brothers put America at the leading edge of aviation The National Advisory Committee for Aeronautics for 75 years the NACA NASA team has continued to fulfill this mission to supervise and direct the scientific study of problems and solutions of flight Dramatic advancements have been made in reducing drag and increasing speed For instance in 1947 more piloting the X-1 Chuck Yeager broke the sun barrier for the first time and the X-5 proved the variable sweet wind could fly The X-15 tested from 1958 to 1968 was the first aircraft to fly 67 miles high reaching 4,500 miles per hour it came back to an aerodynamically controlled land Inside the cockpit control panels once a myriad of dials are being consolidated into easy to read monitors enabling pilots to fly better and safer Also helping the piloter flight simulations For a while the only way to get the feel of an aircraft was to fly Flight simulations show how an aircraft will perform without leaving the ground Together with wind tunnel testing and computational fluid dynamics engineers and pilots have the best information possible before actual flight tests Aeronautical improvements like these have led NASA to a blending of air and space Case in point, the lifting body concept Half spacecraft, half aircraft A lifting body achieves aerodynamic lift from the shape of its body alone Lifting bodies were precursors to NASA's successful space shuttle Flight experience from many programs has led to the planned X-30 also known as the National Aerospace Plane This research vehicle will be a true aerospace machine taking in a fucking air breathing aircraft and accelerating to 17,500 miles per hour into low earth orbit NASA's world-class aeronautics program 75 years of continued achievement in air and space


It's going on everyone Sam here with late in sports cards ripping two boxes of 2022 tops a dynasty Formula one racing hobby for Terence C. So good luck here Terence. Let's see what we can get out of here for you, buddy 2022 tops dynasty F1 racing See something nuts Nick Schumacher ten of ten. That's an awesome patch on that too. That's so cool Congrats on that Terence nice Mick coming your way Starpatch is nasty for haas Nice Mick will take that for sure congrats, buddy There you go Terence Box two One of ten that is Christian Horner nice one there principle for Red Bull With the Red Bull patch on it to congrats on that patch is awesome. That's so cool. Congrats on that there Terence There you go, buddy got a ten of ten and a one of ten got both both ends there Very nice. Congrats on that again Terence. Thank you as always for the support man. Do appreciate it. We'll get them right out to you, buddy


Last class we had stopped at turbojet engines with after burner and water methanol injection we this we understood how these things work right and why thrust augmentation is needed now let us look at where all are these turbojets currently being applied okay where do you think they are applied then they are not so much in use in fighter aircraft very very few fighter aircrafts use it so they are basically used for cruise missiles and then supersonic transport the supersonic transport was the concord that was using it okay and very few military aircrafts use it most military aircrafts currently use a low bypass turbofan we look at what a low bypass turbofan is and why they use that a little later okay now we have understood how thrust is developed right in a turbojet and we have described we have derived that equation all that we have done now what is the Mach number range of a turbojet what range of speeds can it go up to any idea it is it goes up to 3 sometimes okay Mach number of 3 and it can go from 0 to Mach number 3 altitude it is known to go to very high altitudes is not a problem the Mach number is not a problem so we should have stopped here technically right it fulfills all our requirements of flying faster and higher so why are there other engines okay one of the key things here is that the specific fuel consumption of turbojets is very high and therefore people started to look at whether there can be an alternative in terms of reduction of SFC okay now the next generation of aircraft engines was the turboprop engines the idea behind a turboprop is very simple people had piston engine plus propeller earlier now they had a turbojet now in a turbojet the turbine produces sufficient power to just run the compressor and there is scope for extraction of more work from the fluid which we would in a turbojet allow to go through the nozzle so that you get the required thrust now what you can also do is not let it go through the nozzle not let it expand through the nozzle but take out as much work as you can in the turbine itself okay then you have a lot more of shaft power which you can use similar to what a piston engine was doing and connect a propeller in front okay that is what is the turboprop engine so if you look at it if you look at the turbojet engine as a box let us say this is the turbojet engine then you attach a propeller in front you get your turboprop engine okay that is the essential idea of a turboprop engine and if you take a look at this figure here you will see that this entire thing is a turbojet engine right with a centrifugal compressor and you have a turbojet engine now if you attach a propeller to in front of it then it becomes a turboprop engine the power to drive both the compressor as well as the propeller should come now from the turbine that is you should extract sufficient work out of the fluid so that it runs both the compressor and the propeller okay so that is a turbo prop engine it is possible in a turboprop engine to distribute the power obtained from the nozzle and the power obtained from the propeller optimally okay but if all the power is supplied only to the propeller then it becomes what is known as a turbo shaft engine all the expansion of hot gases then it becomes a turbo shaft engine turbo shaft engines are used in helicopters right so these are now the performance of this turbo prop engine is in between that of a turbojet and a piston engine plus propeller okay so it is more more fuel efficient than turbo jets and it can fly at higher altitude and speed compared to a piston engine plus propeller typical altitudes at which turboprops can fly are 5 to 8 kilometers and speed is around 750 kilometers per hour okay yeah okay good question see let me look at the thrust equation that we derived in the last class now if you remember our thrust equation this was our thrust equation now as I said this portion is larger compared to this portion this portion is a very small point now if you look at this portion you can look at it as mass flow rate into velocity differential if we assume f to be very small compared to 1 f is typically around 0.3 0.3 to 0.1 so if you assume this then you can rewrite and if you assume that exit pressure is equal to ambient pressure then this goes to 0 and you can rewrite your thrust equation as so mass flow rate into velocity differential right between the flight velocity to the exit velocity of the jet fine this is how thrust is obtained now there are two ways of getting the same thrust here one is if you get the same thrust by increasing this part right that is one way or you can get to the same thrust by increasing the mass flow rate through the engine okay now what is done in a turbojet is that you increase the velocity differential V e is much greater than V a and therefore you get a high thrust now you can get the same thrust by having a smaller V e- V a but a larger mass flow rate in a few classes from now we will be showing why if V e- V a is large you will get a lower efficiency we have to discuss something known as propulsive efficiency which we will talk about a little later in the course and then I will be able to show you why if this is large you will get a lower efficiency okay so what is done in a turbo prop engine is to get to the same thrust you are now pushing through a larger mass flow rate but with a smaller velocity increment remember the velocity increment is something similar to what we discussed in piston engine plus propeller so you have V a and V e here and this differential is not large but a large mass flow rate is passing through the fan and therefore you get the high thrust okay and not through the a large portion of this therefore it becomes more efficient okay but turbo prop engines also have a limitation the limitation is they cannot go beyond a forward speed of something around 0.7 Mach number although this is more efficient there is a limitation that you cannot go beyond 0.7 Mach number now this limitation comes about because of what happens at the fan tip okay now you want it move out to be more efficient so you want a larger propeller so that you pass through a larger mass flow rate through it right so if you increase the diameter now you are increasing the diameter and the rpm that it rotates at is typically around 2500 rpm the propeller rotates it if you are increasing the diameter then what happens to the speed at the tip the rotational speed that also increases right so in addition to a forward component it has two components one VA and one is you so the combination of these two which is the actual velocity that the blade tip sees might exceed Mach number one when the forward speeds are around somewhere around 0.7 okay when that happens there is a shock structure that gets formed at the propeller tip and that reduces the efficiency of the propeller very much and therefore you will not be able to get the required thrust okay so therefore you cannot operate it beyond this forward speed so what is done is you do not want to reduce this diameter because then your mass flow rate through it will be small so there is a limitation that you cannot go beyond 0.7 Mach number okay now we had taken a look at how the piston engine plus propeller performs like if you remember in the previous class two classes back I looked at what are all the numbers SFC and other things right if you remember what is the definition of SFC we had defined SFC for a turbojet engine for a turbo prop engine it is slightly different it is m.f per unit power that is produced okay so the unit will be what will be the unit if you have this in watts what will be the unit what is what per second what second so either you can leave it as kg per second that or you can put it as okay so this is the SFC for definition for the essential idea is we want to compare the power that is developed by the engine and not look at what is the final thrust that is delivered the final thrust that is delivered is a function of the propeller characteristics so we would want to take it out and look at what is the SFC without the propeller being involved okay and in the last class I had defined what is SFC for a turbojet engine okay now in addition it is the shaft power it is not the power generated by the turbine but it is the power that is available that is power generated by the turbine minus the power consumed by the compressor and what is available for doing useful work okay now there are also other parameters that we had looked at that is power to weight ratio okay now what does power to weight ratio tell you it should be higher or lower what is desirable if it is higher than the weight of the engine that you need to carry to deliver the same power will be smaller okay and power to volume is it tells you what is the size and therefore a higher value would be desirable because it reduces drag okay fine now let us look at the comparative stats between a turbo prop engine and a piston engine plus propeller what I put together in this table is the ones in the black are piston engine plus propeller and the ones in red are turbo prop now notice that for the same power level we can compare 2600 and 2000 nearly the same power level look at the mass of the engine that is required it is a dramatic reduction right and therefore consequently you have the power to weight ratio of the power to mass ratio is something like 7.5 for a turbo prop whereas it is around 2 for a piston engine plus propeller so it makes this power to wait it reduce the weight of the engine dramatically now if you look at power to volume right it is a very small number for piston engine plus propeller around 0.3 whereas it is around 6 maximum in the case of turbo prop engine so it not only reduces the weight of the engine it also reduces the size of the engine so power to weight and power to volume of turbo prop are much more superior to that of piston engine plus propeller and that is the reason why you would not find piston engine plus propeller operating in a large number of applications these days they are very much restricted to either a unmanned aircraft or 2 to 4 seater aircrafts and agricultural aircrafts okay and most of the large passenger applications has been taken over by turbo props okay because the drag is less as well as the weight is much more smaller why does this how does this happen why is it that you are seeing this we go from one to the other and you reduce magic why do you think is this happening what is your reasoning week now also reduction gear was there through part of it is correct the other part that you are missing is if you remember that we derived for the power of the piston engine plus propeller you will discover that it is directly proportional to the RPM right and I told you that if you look at Enfield bullet and the current day pulsar other vehicles you will find that the RPM is higher and therefore the power to weight will be much more right and a very similar thing happens here the RPMs of gas turbine engines are much higher than RPMs of piston engine plus propeller okay it is typically in the range of 20,000 and if you go for a smaller micro turbines it will be in the few lack RPMs go to few lack RPMs very large gas turbines operate at a reasonable RPM of around 10000 so it is much larger than typical IC engine RPMs and therefore you find that these two are smaller in addition it is a larger mass flow rate that is going through the engines right and you can add more fuel and therefore you find this advantage being there and as I said because of this phenomenal advantage the IC engine or the piston engine plus propeller lost out and you are only left with turboprops and turboprops have an application and you have turboprop engines being used in large military and civilian transport this is mostly restricted to cargo okay large military aircrafts anything comes to mind India recently acquired something from the U.S. C-130s right they acquired very recently a large number of aircrafts something similar is Antonov very large aircrafts for military transport and civilian cargo transport only because if you are looking at cargo it does not matter to cargo that it has to sit for a large number of hours in the plane but if you are looking at passenger transport because you have this restriction on forward speed of point seven the time taken will be much larger for longer haul flights right so therefore you tend to use turboprop engine in medium medium range passenger transport so you won't find it across continents but inside countries and side continents you will find this for passenger transport right okay now the next generation of engines came out of turboprops primarily to address this limitation okay this was the limitation with turboprops SFC wise it is very good but I cannot go beyond point seven Mach number so we want to have the best of both words can we do with good SFC as well as go to higher Mach numbers what was available was only turbojets at that time which was very high SFC so the next generation of engines that came about was what is known as turbofan engines now what was the problem with turboprop engines it was only point seven Mach number and that restriction was because at the blade tip right now if we assume this is this box is the basic turbojet engine and this was our turbo prop engine the trouble was that because it is rotating at high RPMs and you have a large diameter at the blade tip the Mach number was exceeding one and the forward speeds was point seven so the idea was why not reduce forward speeds ahead of this fan and a simple way to do it is put a diffuser in front of it right if you put a diffuser in front of it what happens is irrespective of the flight Mach number you can control what is the flow speed upstream of the propeller or the fan right so that is the essential idea of a turbofan engine so you have a part of the flow that is going through the fan and going through the this is known as the bypass duct and this is known as the core so you have one part of the flow that is going through the core and the remaining going through the bypass duct okay. If you look at this figure here you have what is a turbofan engine notice that you have an intake upstream of this and you have fan blades that are mounted on the same shaft as the turbine blades and the low low pressure compressor and the high pressure compressor stages are mounted on a different shaft that is connected to the high pressure turbine here high pressure turbine here right so the advantage with this kind of an engine is called two spool engine because there are two shafts concentric shafts the advantage of this two spool engine is you can control the rpm with which you rotate different parts of the compressor the low speed compressor can be operated at a lower rpm and the high speed compressor or the high pressure compressor can be operated at a higher rpm okay and that is the advantage of this and you have this fan here and there is a nozzle that and the flow goes out through this essentially this is something similar to the concept that we discussed earlier that thrust large thrust can be obtained either with an increase in mass flow rate or an increase in velocity differential what is done here is again a large portion of the mass flow rate goes through the fan and the velocity differential is very small there right there is more like a propeller and therefore the velocity differential is small so you get better performance typically the fan pressure ratios are around 1.4 to 2.2 and with this arrangement you can go up to very high Mach numbers right and still obtain the same with a lower SFC turbojet engine okay and which is why turbojets are hardly being used in any military aircrafts as well as civilian aircrafts right if you look at civilian aircrafts I had said earlier in the class that they mostly use a turbofan engine this is the reason now you can define parameter called a which is known as bypass ratio a is equal to air passing through to the air passing through for engine okay so what is a for a turbojet engine plane turbojet engine there is no bypass duct right as I shown here this is the bypass duct a part of the flow passes through the bypass duct part of it flows through the core engine core engine is still the turbojet engine right if it is only a plane turbojet there is no flow passing through the bypass duct and therefore a is equal to 0 for turbojet engines now you might ask me why is this that you still insist that velocities are very small velocity differential is very small right a large mass flow rate with a smaller velocity differential is what I said you can have this nozzle also choke the pressure ratios allow you for that and yet I say that this is so the reason is if you look at this flow that is going through the bypass there is no heat addition anywhere right and therefore the temperatures of the gases is lower so if it is choked even then we know that right so if the temperature is a lower then the velocities will also be lower a large portion of the flow is going through with a lower velocity a small portion of the flow is going through with a larger velocity overall you still have a very low velocity differential and that is how this produces higher SFC okay and typically alpha for military aircrafts will it be large or small alpha values for military aircraft okay you are right if you look at any military aircraft most military aircraft do not have their engines on the wings okay their engines are fitted into the body they are in the body itself right because you do not want a large drag whereas civilian aircrafts you will hardly find anything engine being fitted to the body engine is always outside okay so military aircrafts the engine is fitted into the body and you would like a smaller alpha because that will mean smaller frontal area also okay so typical values are between 0.321 and alpha for civilian aircrafts is around 6 you can use a large alpha here because the engines are no longer fitted on to the body it is outside and the typical Mach numbers that some of the civilian transport aircrafts look at is around 0.8 to 0.85 they are not very high Mach numbers they do not go beyond the speed of sound okay so therefore you can look at a large value of alpha in fact G uses even larger value of alpha G engines go for typically G 90 engine has a alpha of around 9 which is very large the reason they give for this is that if you look at the drag component of the engine for the nasal drag as it is called and the drag component coming from the main body of the aircraft the drag component coming from the nasal is very very small compared to the main body of the aircraft and they say that it is only in the second digit that it matters so you can go in for a larger frontal area here right alpha increasing means you are going in for a larger frontal area they say if you increase alpha you are going to increase you are going to decrease SSC right so therefore that is the advantage that they are looking at although frontal area is increased drag is increased they say it is not too much compared to the overall drag whereas the advantage that you get in terms of SSC is much much more so they go in for this alpha of around 9 so what we need to remember is alpha higher means larger frontal area larger drag for the same like we are fitting as simple fan in front of the turbo jet if we remove that fan and we run the turbo jet is turbo jet has more thrust for turbo fan when we work out some more details I will be able to show that fan will have much larger thrust for the same if you look at for the same fuel that is consumed same amount of fuel that is consumed but the turbo fan will have a larger thrust which is which will which will be obvious in terms of SFC so if you look at the data that I put together here in addition to what we had in turbo jets there is another additional parameter alpha coming in here right this is alpha and you see that alpha ranges between 4.9 to 2.4 to even smaller smaller ones are for military aircrafts there is an additional advantage in a military aircraft military aircrafts do not want to use turbo jets because there is a other advantage that you can get with turbo fan low bypass turbo fan any idea what that is no yes that is not a lot of it is another advantage that is yeah that is a by-product I would say more to do with propulsion let me tell you that the advantage is look at this if you in most civilian engines you do not mix the two streams right whereas in a military aircraft you can mix the two streams and pass it through a same nozzle okay what does that mean your additional air that is coming in into the afterburner right and that additional air you can add additional fuel and burn it so the increase in the afterburner thrust that you can get with the afterburner on is much more with a low bypass turbo fan and that is a significant advantage in a military aircraft you would want this you would want a large ratio of thrust when the afterburner is on to when it is not on so and therefore military aircrafts have been tending to use a low bypass ratio turbo fan for this reason also okay now coming back to this table here if you look at all these engines the top few are military aircrafts and the bottom ones are civilian aircrafts G EC FM 60 Pratt & Whitney engines okay and this is the Russian engine notice that SFC here is different from the SFC that you saw in terms in the with regards to turbojet okay and if you compare SFCs fans are typically between 16 to 24 Newton second whereas it was around 30 30 what was it 31 to 36 milligrams turbojet so there is a difference in SFC it is almost half the SFC that you get with turbojets and therefore it is quite obvious that you see these in civilian aircrafts more and the other advantage that I talked about for its use in military aircrafts is that you can get a higher afterburner thrust okay but you would also probably notice here the thrust to weight ratio would be lower compared to a turbojet engine right and so also the thrust to volume it is a larger volume larger larger frontal area it has so the thrust to volume and the thrust to weight are different from the turbojet engine it is larger than turbojet engine okay and what are the applications of this where do you think these are applied civilian civilian transport okay we will stop here and continue in the next class in the next class we will look at what are ramjets and how did they come about and further go into what is cramjet okay thank you.