Good morning evening afternoon wherever you are welcome to is that even the second stage of this amazing app modernization day modern app development actually so yeah would suggest it's like 3 30 ish p.m. in Germany right now but it's definitely earlier in other places in the world my name is Marcus and I'll be births at us host today so getting you all ready for an amazing keynote by a lifelong developer advocate Mr. Burr Sutter himself is gonna present everything you probably always wanted to know about becoming the developers developer I'm already pretty excited so I'll be hanging out in the background watching the chat there's not a lot of housekeeping that we need to do I just encourage you to use the chat feature if you have any questions reach out Burr also shared a couple of links already make sure to join the definition slack if you have any questions he also shared his slides so if you want to follow along live please feel free to do so and here he comes Mr. Burr Sutter well hello hello hello all right good morning fantastic I hope everyone's excited because we got a lot of fun things to talk about today and we're going to basically hit you with a lot of funny images a lot of fun slides maybe in few demos but talk to you about all things let's call platform engineering platformers product being the developers developer that's part of it so I'm going to be watching the chat feel free to throw comments there I'll try to hit them as I can and we're going to move really fast as I said I'll probably drop some URLs into the chat and let's go into screen share though so actually I'll give you a survey in a moment so look for that survey share screen here let's get this one okay okay okay so you now you should see my nice big unicorn there so we're going to talk about becoming the developers developer the idea being that there are developers who develop for developers hopefully that makes some sense right developers who develop for developers I know it sounds kind of funny but you'll make sense as we get through the presentation so let's dive right on in here boom boom boom boom we get the mouse on the right spot okay one thing I'd like to mention though is when it comes to dev ops or specifically dev nation and the icon that we use there we gain we came up with that icon for a reason so I like thinking in terms of dev ops right you've heard that from me before and some people might think of that as dev greater than ops some people might think that as ops less than dev hopefully they don't think that way but I've heard things of that nature but what about dev raised to the power of ops right that's what I like to think about there so that's why I have that little carrot there and that is what became part of our dev nation icon right so that just keep it in mind for people here for dev nation today that was why that was there that's a little bit of history and I think we're going to talk about dev sec and ops today all right so let's talk about your journey to awesomeness you've seen this kind of slide from me before but we're going to focus a little bit more today on what it means to be a platform engineer offer platform as product and think about what it means to offer an IDP and all the elements that might go into that we're going to talk about a lot of things in a fairly short period of time and this is not meant to be a deep dive into any one of these areas it's more a high level set of ideas that hopefully will inspire you to go do more things now we're going to have a little survey here let me copy and paste the survey URL into the chat so you can either grab that QR code off my screen I'm also going to put it here in the chat there we go you should see it there I don't see anyone on our public slack but you know for anyone on our public slack was that there also and so if you're on the dev nation slack you now have that link if you're in this session you have the link also jump on that item right there and then you're going to be answering a couple simple questions for me okay so let me get out of here and show you what this thing looks like as you respond there we go so let's go here so we just need a few people to answer the questions our goal is to better understand her audience is and for those people who are in fact managers claim it own it be proud of it right I'm in management these days myself not necessarily a day-to-day program any longer and that could probably be a good thing looks like we have a lot of architects here I love that word architect because it can cover so many different roles within an IT organization nobody claiming the business analyst role and surely there's got to be another somewhere in here meaning you know I don't like any of these roles I think they don't really fit me very well but please put that into the session it'll have don't give me a better feel for who we have with us today and also I think for our developers or ops or architects you're going to see some things you like in today's session our loan security person here do not feel that you're all alone right we're going to talk about some security things and hopefully hopefully you'll find that I I got it right for the security person you can tell me if I got it wrong and you can do that via the chat feel free to yell at me and chat as we go throughout the session okay you can see we have a pretty good crowd here now let me ask you one more question there's another question on a little survey and I want you to think about this for a moment because I find this to be a massive challenge within an IT organization so when I go out and speak to large customer organizations when I go out and speak to large entities I'm talking to big branded guys right that you know the Fortune 500 the S&P 500 the global 2000 they will tell me that once they once they discover what what it means to make a developer wait right they have developer wait time well here's the scenario a new developer was just hired they got their laptop they got their VPN they got their access to the system how long or how many weeks does it take for them to become productive or let's say you're a developer already working at the company right how long does it take for you to get access to a computer access to a virtual machine you file a ticket and you wait right so think about that for me and let's go to this next slide here if it will go there we go so I'm just kind of curious to know for anybody who has to request from central IT how long does it take to get access to a virtual machine access to a computer basically because if I have a great idea and I want to build my next generation cool thing and I might need a virtual machine with that Kafka running on it or maybe I need access to a Kubernetes or OpenShift cluster or maybe I need access to whatever resource I file a ticket and I wait and I wait and I wait how long does it take you to wait and I'm just kind of curious to know what that is for the audience here and you can see we have some people saying less than a day I'm wondering if those are people who actually are the VMware administrators and the big organizations you know who have access to those virtual machines as the as the ad bins the cluster ad bins as an example and it's funny too we see some people here at 10 plus days I've actually found that many corporations are in that three week plus world right one actually told me six weeks so I make this point because this wait time that we're talking about here any wait time at all if it's longer than let's say 50 seconds or longer than let's say an hour or two the problem is you have people who need access to resources sitting on their hands and waiting would that be their getting started experience as a new hire or I have a new idea where the business has come to me with this amazing idea and I want to start on it right now so wait time is part of our traditional IT world and I think that's highly problematic okay so KVM there Christian fantastic so if you got access to KVM you can launch your own virtual machines rather rapidly but I do wonder Christian if you work for big old corporation you know how many VMs can you launch without them noticing and or asking you to wait for them okay so thank you for that information that just kind of gives me a little feel for what we're doing in our world let's get back into our little presentation and get rocking here okay so let's talk about the world of dev versus ops you notice my little programmer here on the on the left hand side my programmers rocking the headphones and at 445 on Friday they think they can just check their code into their get repo get commit get push and their high five in each other they're out the door they're heading for the pub at 445 on Friday while the ops person often Friday night if you work in a big bank or maybe out throughout the weekend has to figure how to make that thing run and I have had this personal experience working with a production team both the development side and the operation side I was the owner I own both sides of that equation and I had to get the system up and running the new changes in production by Monday because that's when the business started back at their jobs now this is eons ago before we started 24 by 7 businesses but that concept bothered me greatly the idea that the development team just thought they could hand off whatever garbage to the ops people and the ops people have to suffer accordingly and that had to change and in this specific case I actually brought all the developers in on Saturday and this only had to happen a couple times by the way so in order to help the developers understand empathy we brought them on Saturday where they just simply watched the operations team struggle with the deployment of their code base into production you do that two Saturdays in a row the developers write vastly better code and this taught me a valuable lesson this is actually 20 plus years ago right they taught me a valuable lesson when dev understands some accountability and has some empathy for their code running a production where it sees real business value they fundamentally change their ways they write better code so I'm one is thinking about that basic concept can developers write better code once they understand having said my accountability some responsibility and seeing what it looks like in a production environment because in many organizations it might look like this right the ability push code to production might be this amorphous blob much like you've heard the story right before I think it's the Greek story where I forget the fella's name to basically kept pushing the stone the boulder uphill and it kept rolling back down on them and crushing them so push the boulder uphill roll back down and crush them that idea here was what I what inspired this image and I like to think of software development not as a nice boulder right boulder would be awesome that has structural integrity software is like this amorphous blob of stuff with a gang of people trying to get it over the finish line push it uphill and you can see right here we have this person standing in this direction and you might be thinking well who is that well I know what some of you are saying right now you're screaming at your laptop you're yelling at your microphone that's the security team or that's the operations team the compliance team right Sisyphus there you go thank you Joseph right so you you have the idea as to who's pushing back who is basically saying this cannot go this shall not pass it's not Gandalf by the way all right how about this person up top here you might be looking at this person going wow okay they're on top of the thing they're on top of the game here but they're facing their own direction ah that's our architect we had so many architects earlier right so we know our architects they're on top of their game well hopefully they're facing the right direction most often than not but they're trying to surf the blob we're trying to ride the wave hoping to get over the finish line and make this magic happen and how about this person down here at the bottom well this in fact if you actually are from my world of dev sec ops dev ops that is my operations person so I'd like all the developers here to think about who is being crushed under the enormous weight of this blob that we've created all right so yep so you can see right there where someone's in that situation you basically are feeling that pain now here's the part that's really funny about this to me if we are successful at pushing that blob up the hill and into production once we have to do it again in three more months in three more months again and again and again and those three months in deployment intervals why they seem long at this point in time they're actually fast by javie standards we used to be six months twelve month deployment intervals but still it doesn't matter what the deployment interval is the problem is it's inhumane we have to do this again and again and again so think about that it's not fun because what we don't want anymore is the concept that the developer can throw their stuff over the wall and hit the other person in the head this is no longer the fun way to do things the developer and the operations team have shared responsibility from this point forward they have to go hand in hand to deliver the software to production together now I want you're thinking about security now right we're going to talk about dev sec ops more today and guess what there's a third party in our love triangle so think about that for a second there's not just these different development teams that run and are out there associate with different lines of business and there's not this central it ops team or platform team responsible for the infrastructure there's also the security compiling and compliance team the people that are basically producing all these controls they use the term controls they use the terms evidence they have people taking photos with their smartphone of people's laptops to show that people did a certain task we're you know they're kind of living this weird world they have their own weird language but they are part of the equation and we have to embrace them we have to include them and also teach them English because I have noticed whenever you speak to them they speak almost like they have their own jargon and it's still related to the software that we build an architect which I think is very interesting so let's talk about dev second ops for a moment and this is actually important and a subtle message that I want you guys to pick up on here okay so if you think about developer right the developer the security officer the security compliance engineer right the ops engineer the dev ops engineer whomever you how are you titled those folks and there are definitely more than three people in the equation but those two C's three whatever the three of them have to articulate and think about a problem they probably all have their own unique right their own unique way of thinking about that problem in other words we might all be looking at the same thing and if you've seen some of my other presentations I love talking about the five blind men and the elephant right if you've ever heard that metaphor or seen that parable this is the same problem it's all about communications and the idea here is that we form different images in our head based on hearing the exact same words we can all interview the same user and come up with a completely different conclusion we can all read the same document and come up with a completely different idea an image in our head and so that's a very important point and I want us thinking about that because these folks have different motivations they have different incentives developers want to rock out their innovation knock out new capability here's new feature new feature new feature operations of course values stability resiliency reliability they want to make sure this thing doesn't just get ripped down by you know just simple load of all the people coming in and hitting the system and then a security team wants to make sure hackers don't camp out in your code base and run their crypto miners on your infrastructure or steal all your data right that's an important aspect of this also so how do we actually get more collaboration on these folks how do we actually get it so that they have the same image in their head with greater collaboration a shared understanding and shared responsibility this is tricky and the ultimate goal is to make it so they all love each other now you might be thinking this is a very funny image how in the world can we love these people they're not like people well I've had this discussion with developers and architects before I actually had someone challenge me years ago bird you don't understand I can't deal with that person over there they always tell me no they never will let us do anything innovative and interesting and introduce a new software a new open source capability whatever might be and and I'll say wait what was the last time you took that person to lunch and you can tell I had blown their mind their face was like shocked like what do you mean take the person to lunch and I said they're human too and I bet they eat lunch or at least they eat food so maybe you can have food with the person and act like they're human and that was a game changer I could tell that moment they're like oh they are human yes these these folks are humans and they behave like humans they just use different jargon all kinds of funny nomenclature they'll talk about computers and talk about software which I always think is interesting because it's still software and computers I don't know why we have to have funny jargon but the point is we actually all want the same things is so important so important okay all right let's keep going the ultimate goal here is to have shared goals share responsibility dev sec and ops all working together as a unified team to push that boulder up the hill by the way I didn't mean here that dev is pushing security team just pushing the ops team that's not really what I was going for the goal here was that they would all be working together there's also that free ebook there that you want to get access to and if you have access to the slide deck you have access to all the links by the way I published a slide deck URL in the chat earlier but you want to make sure that you can get access to everything and we have been using our our our our research tools to basically discover more information about app security developer gilly observability consistent configs so if you go get that free ebook you'll see where our UX research team has specifically sat down with developers interviewed them and platform engineers by the way to understand better what their shared responsibility model looks like what their underserved needs are and what that means to live in this new dev sec ops world so there's a savannah they're published the deck one more time feel free to grab access to the deck and then go download that free ebook okay so here's the ebook cover make sure you go grab that get a copy of that right there you can see call in dash and marcus all worked on that marcus as you saw earlier in our introduction go grab that book it'll give you some really nice information about how to secure the software supply chain or the needs therein when it comes to dev sec ops a quick history lesson and we'll keep moving pretty fast here because we don't need to spend time on the all the history for some of us here we've lived through this history in my case i live through more than this history but i think it's pretty interesting to understand that java in the case of for those java folks out there it was back in 1996 and htp 1.1 was 1997 so think about that for a second we've been building htp based applications since nine you know actually before that htp 1.0 back in 95 you know we've been building web-based stuff for a while red enterprise linux over there in the year 2000 okay so so many things have happened the agile manifesto in 2001 i actually found myself quoting the agile manifesto to someone just this year so yes it was a document published in 2001 but people still don't know what it means and sometimes we have to talk about it with them so look at all these amazing things that happen in our journey to becoming cloud natives you can see where spring boot happened and docker and microservices and kubernetes and all that came to a massive big conclusion in 2015 at that moment is when redhead launched redhead open shift specifically based on kubernetes and we showed the world these things called containers and pods we launched a thousand containers and launched a thousand pods live on stage and that link right there will get you access to that demonstration but that's from 2015 it's 2023 eight years later what has happened in the last eight years and i think it's important to think about so over the last eight years we introduced some new things like helm and spinnaker and istio and git ops was born git ops by we works in 2017 argocd born in 2018 the accelerate book where we learned all about the dora metrics over in 2018 those four key metrics of course by thoughtworks they recommend the trial of them but now we're talking about things like team topologies the trialing of platform engineering the adopting of platform engineering so a lot has happened since that 2015 moment okay and so we i just wanted you to think about that and by the way i mentioned corkis here that was born in 2019 some of you just saw some of that today for the first time but this is an example of all the innovation that is occurring and you should note that it's occurring ever faster than ever before okay so let's talk a little bit about what thoughtworks says about these things they're talking about applying product management to internal platforms they're talking about trialing platform engineering teams so in other words there's these new phrases that are showing up in our vernacular right this concept of platform engineering this concept of product management around the platform and this is super critical and for many of our architects and developers this is the space you might want to play in going forward at least if you work for a large organization that it serves a large number of developers and i think it's important for us to be thinking about it and talking about these things and some of you might know that i have spoken to many of you over the over the last couple months about these specific topics i know christian and i spent some time together wolf gang and i spent some time together so perhaps some of you and i have already talked about say these same things because what our goal is now is to practice platform as a product so it's more than just platform engineering platform and what do we do to create the developer experience it is about actually productizing it thinking in terms of being a product manager and what it means to deliver that product to our user base okay so what is the platform all right a digital platform is a foundation of self-service apis tools services knowledge and support all arranged as a compelling internal product we're going to break this definition down and show you some very interesting things about it okay so we're going to get into this so apis tools services and knowledge this is so critical self-service apis tools services and knowledge so right here i tried to identify maybe some of those apis and tools that we're talking here and services that we're talking about now in your platform you don't have to do all these things you might have to do some of these things and you of course have to choose tools across the software development life cycle that meets the needs of your organization you can see right here based on the stack that some of these things are lower level like we need to figure out what our compute network and storage look like our infrastructure looks like are we using kubernetes and namespace as a service or does everybody get their own kubernetes or does everyone get their own virtual machines how do we deal with configuration management etc and then the very top of the stack is something like backstage the portal all right the portal being the user interface that people would engage this entire layered cake of opportunities here but it should be noted that right away this is not a trivial thing to go do organizations have been working on this for several years i've and then again if you've spoken with me over the last several months i've spent time with some of the world's largest organizations talking about this stack and the way they've implemented parts of it within their organization so much has happened within the space uh and burr still has hair and that's true i still have some hair left on my head it's getting grayer by the day okay all right all right so let's get into this i want to kind of do it from this perspective all right so think about the pipeline think about what it means for the decoder to write some code and get it all into production right so we've been talking about that a lot today and the reason i focus on this topic is because i'd like to tell all the programmers out there the developers those programmers i talked about those developers right depending how you think of it the if you write a bunch of cool code it doesn't matter how cool your curly braces are and how great your semicolons are and what your spaces versus tabs are and how elegant your algorithms are and the fact that you use go rust or c sharp or java or javascript the issue is until it runs in production it adds no value so it is value less until it makes it to production and serves the need of the organization was meant to serve whatever that might be so let's talk about that for a second and think about the pipeline okay so the developer is going to be doing their edit save refresh if you've seen a corkis presentation these days you've seen edit save refresh write a low code save it the id control s refresh that browser boom we see that java code now running instantaneously it's kind of like magical because we're not used to seeing that in the java universe maybe if you're javascript or python you're a little more used to that sort of behavior but the idea of edit save refresh edit save refresh fresh using your favorite id using your favorite tool like intel aj or or maybe you have another jetframes id or you have vi or emacs it doesn't really matter notepad plus plus it's still pretty popular i think okay all right and so you're gonna run the test you're gonna run your debugger you're gonna do a get commit and get push right so think about that get commit get push it's like the magical moment because you think i'm ready i'm ready for the world to see my creation i built this amazing thing got my curly braces semicolons all sorted out and the world should see it so this point the next phase kicks in the pipeline kicks in a web hook kicks in maybe it's all based on your git lab or your github but the web hook kicks in kicks off the pipeline and it runs your jengens your azure dev ops your tecton right whatever it might be your rennet trusted application pipeline and it's going to do a get clone it's going to do a maven clean compile test it's going to run those same tests that you ran on your laptop in some cases it's going to compile in a package it's going to create the fat jar if it's a java application and this is of course maven if you have an npm install or you might have a pip install things like that and it might even run check style it might even run sonar cube so you're going to wrote a series of tools within the pipeline to do the basics of checking everything out seeing that things are okay as an example and that's part of what people think of as the development stage then there might also be an integration phase or a performance testing phase soak test smoke test phase but typically we might use selenium we might scan things with sneak we might use cucumber for additional you know testing we might push to repository maybe that's our artifactory by jfrog or maybe it's quay but we're going to basically do all these things in the context of the pipeline and then of course when we're ready to roll it out and employ it we might update a get ops repo we again might have a web hook associated with that we'll do a get clone maybe but argo is going to basically do a diff and sync and it's going to basically move those bits into that production environment by syncing what it sees in the get repo into what is the live running system so argo is a key piece of that and of course we have our monitoring solutions like for metheus cabana and pager duty and data dog and we're going to basically just ensure that everything's all good everything's all green we're going to have our different analytic tools to identify that okay so it's important to understand who owns what the app developer kind of owns these things like the edit save refresh the right they have their laptop they run their local test they run their local debugger they use get command line or get gooey from their visual studio code or intelligent so they have a lot of control over those kinds of things including what goes in the palm xml or the package json or the requirements.txt and then this other group of things right is often negotiated or collaborated with uh with the platform team the platform engineer the architect the security influenced aspects of this the security team wants to say hey run the sneak scanner or run the you know uh sonar type you know scanner whatever the scanner it is that they've selected so all these things happen within the context of the pipeline that glues all this together but it's actually a collaboration of multiple parties working together so one of us all thinking about that because it's important to understand it's not that the developer controls everything and it's not that the operations the platform to be able to control everything or the security team it's a collaboration where we all work together okay also let's not forget about our end users out there those accountants and nurses and bank tellers the people who use this stuff at the end of the day i think we tend to forget that as an industry and i know i often forget it as i'm out there talking with developers and operations folks and security people so like at the end of the day what matters are are the end users who wanted the thing right whatever the organization is are they benefited and positively impacted by the change that you made you fix the bug you close the back door of the security flaw you added a new feature did they have a positive experience we've got to forget uh remember that more often okay so let's talk more about self-service and some support ideas compelling internal product there's some interesting ideas here now in order to be compelling and self-service we got to know for whom who is our target and i think this is so important because if we're platform people who is our customer so our customer if we think about it and we understand the book team topologies a great book and i have a whole group of book recommendations at the end we would basically say that they stream aligned team is the customer of the platform team the stream aligned team is the team that's producing the value that lands on the end user mobile smart application smartphone application right it's the mobile app that lands on the smartphone it is the api that they consume in a b2b business business sense it is the web based application that the refresh in the browser and see the change based on what was changed them so the value stream aligned team is a customer of that platform team and so let's talk more about those platform people because let's understand who our customers are a little bit better so if you look at the annual survey from 2021 the Kubernetes annual survey you'll see that the Kubernetes ecosystem is claiming 5.6 million developers and 31 percent of all back-end developers that kind of blew my mind when i saw that statistic so they're estimating that they've already penetrated the market of 31 percent of all back-end developers that's kind of amazing to me and we'll see some other numbers in a second to show that that's actually a fairly deep penetration when it comes to the technology adoption lifecycle so developers feel like they're they're learning that Kubernetes thing they're knowing what a kube control api dash f is they know what yaml is they know what deployment service and pod is that's interesting to me because at the end of the day what we really need to do for that value stream aligned team is reduce their cognitive load so let's think about cognitive load for a second now this is an important slide that we should talk about for a moment for those folks who've been around the block a little while and i'll tell you a little story right i actually started back in the days of wiffle see that wfl there not the jcl the jcl was for the cool kids that's job control language they had the expensive ibm mainframes the company i worked for didn't have that kind of money we had the inexpensive unisys mainframe and we had wiffle wfl workflow language but at the end of the day it was all cobalt or some derivative of cobalt for gl generation language and there was a built-in ide right inside your green screen terminal and you had a terminal and you worked on that it was mostly batch-based applications as a matter of fact if you were a programmer back in this time frame you might actually write some code and that would spin up a tape drive write it to a tape drive you would then carry the tape drive to a little set of cubby holes because the cubby holes were where you would input the tape drive just lay it there with some instructions maybe some written instructions for the operations team who wore white lab coats and sat in a really cold room that might actually gas them with argon in case there's a fire and they work with these machines that were the size of you know wash machines and refrigerators and they would load that tape and they would run your program and this is all just to debug your code by the way and then they might give you a big green banded paper report out the other end and put it back in the cubby hole and you know the the next day you come back get your tape back get your green banded paper back and know if your application worked or correctly or not that was how you're in a test now some of you are a little bit motor schooled not you're thinking wait I had I actually had punch cards well I am a little bit I'm talking post punch cards here okay so the idea is that things have changed dramatically for the developer the days of actually building a tape and running and getting a paper report just to run a test and a debug right is changed dramatically but it has changed in such a ways that it's so complicated now if you think of the person in the modern era has to know something about what serverless is and of course they have the cloud they got this Kubernetes thing they got Node.js and Java you might be learning Go and Rust and Python because you're doing a little data science right you got to figure out what to do with gRPC at this point and View React and you know Next.js and Angular there there's an amazing amount of things to be learning at this moment in time and it is a bit overwhelming I imagine just looking at the slide right now it's giving some people a little anxiety as they think about being overwhelmed themselves okay so Mark there has basically been part of the Wiffle language also so there you go so I actually had this question came that came up in an email thread and I know it's too small to read on the slide that's why you have access to the slide deck and this was a basically the summation of an email conversation that I had with a group of people within Red Hat and some people were asking why is it so damn complicated why is it so hard and I had to think about it for a second but this was our response and I kind of put it right here on this slide because I think it's super important for us to understand why is it so complicated because 20 30 years ago when we built applications and software developers those applications went to our brother and sister employees right in other words we built apps for employees of about one to five users at a time about 20 years ago the average user count per application was a little bit more than one user okay so that the world was one user per application instance back in the day primarily because we ran everything on desktops we did this thing called client server right we basically had microsoft office and access and fire uh fox pro we basically use things one user application right one user and maybe we had five users if we had a multi user system in the new world we're living in right we have an application that basically is using ai real-time video streaming to do a tiktok dance move analyze it real time for a million users or consumers with their smartphone so the world has changed dramatically and because of that dramatic change of user count user volume and also a tax service and security concerns because guess what if you're making an application available to the world at large via tiktok and the api well that's got a different security profile than if you were just giving it to a single employee within your business within your organization and on your vpn so we have to constantly figure out how to relieve that cognitive load relieve that pressure because we're always improving we're scaling we're more better securing making things more reliable and reusable okay now look at this for a moment this is the kubernetes ecosystem again why is it so complicated why are there so many things i might have to learn and i know there's just far too many i can't learn them all i don't have time to learn all these things either so we at redhat try our best to basically educate you on the ones we think are important and are interesting to us so we do that sort of thing hopefully and curate this for the rest of you okay now cognitive load can be overwhelming i like this particular set of animated gifts it's like uh there's just too many things happening at the same time so now we got to reduce cognitive load but let's talk about compelling and this is actually the most important part part the platform you create for all the other development teams to be that developer's developer to be the architect is to make it compelling and i think this is super critical and this part i want to focus on for the remaining part of our session this part that super excites me if this is not obvious so digital platform but all the self service api's tool services knowledge and support arranged as a compelling internal product internal product and it's got to be compelling because it's not mandatory no longer are you going to be the draconian boss who says you must use this tool because we say so you must use this capability this portal this uh this ci solution this task this uh security scanner because we say so because it needs to be compelling because what you want is a greater solution that makes the developers ever happier and ever more productive and we as a whole work well together so i want to talk about this thing called the technology adoption lifecycle the tlac the talc i call it technology adoption lifecycle a lot of people may not have heard of this but it's an important element that was invented i think back in the 60s at this point i came to learn about it back in the early 90s based on the book called crossing the chasm if you never read this book i highly recommend it there's a bunch of other book recommendations later in the slide deck but this was one of those moments uh where i read this in early part of my career i also took a bunch of classes around tqm and learned the deming model for manufacturing back in the early 90s between this book and learning about deming and total quality management and how the Toyota process worked i taught me a lot about how i think about software fundamental game changers for how my brain worked at the time so i like thinking about this technology adoption lifecycle a lot and it breaks down into these major categories from innovators early adopters early majority late majority and laggards now i'll tell you right now you as a large audience here on the public internet have not i've not really given this presentation outside of red hat before so there's going to be some things in here that might be controversial and i want you guys to yell at me and chat if you feel i've offended a group or not or someone like that uh you know it'll be interesting to see how people react to what they're about to see so if you believe that the technology adoption lifestyle does have this five buckets if you will and there is this bell curve of where the majority sit versus the people at the uh the various ends it's important to think about what psychographics motivate these people what might they do how might they behave and who in my organization that i'm seeking to serve might fit these things the fit these uh psychographics fit these characteristics so like the ubergeeks the hardcore innovators the some of the folks right in this chat right now you might go out the github find the source code and you're happy to get cloned and build from source to use that new component that new library that new capability and check it out you might even fork that project on github you might even start your own project on github but you know how to go direct to github and and direct to source to understand better what that capability might use you would actually read the sources to learn the api you might look at the read me file the markdown file but by default you can also dig into that go code and i've had to do that myself or dig into that java code or that javascript code to understand it and you might also be a little bit of a disruptor you might be a change agent you might be a catalyst and you tend to work at dot coms or startups or maybe you're an innovator within you know the big bank or the big insurance company but you're an innovator you're a super ubergeek okay now what about the early adopters now the early adopters are still going to be looking at some of those same things but they would prefer to download a zip file or npm install or basically you know use a go module while they can certainly go to source they you know would just rather consume the thing that's already ready for them to consume maybe they brew install it on their mac or they basically use chocolately and install it on their windows machine or they might use a sass based api and they'd like to have documentation they'd rather not have to go to the source code and figure it all out they'd rather read their markdown file that nicely lays out exactly how they should get started and what they should do and what this capability involves that's a key element of it they will participate in forums they will also contribute and write and speak at different conferences like at this one today right now they work as consultants or maybe they work in vendors maybe they work for red hat as an example and i like this when i put this one on here they own their own laptop this is a lesson i learned many years ago if you're a professional software developer operations person architect etc etc you should never be beholden to your employer for computing hardware let take that crap and toss it off your desk because we all know that the the uh the stuff that they give you at your corporation is normally junk and five years old or three years old that's true red hat by the way too we give a lot of crap to our people go buy your own real good hardware and keep it where that be desktop building your own little lab building your own data center buying your own macbook if that's what it was required because they won't give you one buy your own hardware if you fall in this category of early adopter then there's the early majority now the majority is where we get the meat and potatoes of the people right this is 34 percent as you read the crossing the chasm we are now crossing the chasm right and getting to that majority and these folks want tools they want wizards they want examples and tutorials they want patterns and practices they want obvious productivity gains and they might go to the conference given by the talk given by the early adopter they might actually read the books and blogs written by that early adopter and they might even go to a user group and they might even deliver a brown bag lunch within their organization okay could be could be a thing that they do now let's look at the late majority so the late majority tends to move when the boss is sold the late majority will always use google and go stack overflow to copy and paste they would prefer our formal training class okay they might want a mentor who can they find to be a mentor for them and they tend to adopt a technology when it starts to impact their career in other words they're not going to be super proactive they're going to learn that thing called java now because you know what their Pascal skills are running out of gas they'd like to keep working for a little bit longer so so even though they made a good living for the last 20 years on Pascal now they're learning java for the first time because they'd like to keep working for a little bit longer before they retire so if you're a java person you might be thinking now i gotta learn a little go or a little ruster a little python or something else or a little java script so it the point is that they tend to be motivated when they're forced to be motivated this person by the way it's the same person that the boss okay think about this in your old office before the pandemic we had all our cubicles we had our chairs the boss might actually print out a blog or print out an article and leave it on our chairs so when we came in the next morning we might find that article and go oh the boss wants us to look about look at this new technology or new technique or new idea like continuous integration for the first time now the laggards of course they demand training so the late majority they'd like some training formal training laggard say i need training if you don't train me i won't move as a matter of fact i love the training because it gives me a week off from work okay i love the brown bag lunches because i get free lunch give me that free pizza that's an awesome thing so i make i make these points because guess what i have no problem talking to you guys here in this conversation about these things because you are not laggards if you are here you're probably not late majority if you are here because you would not be here if you had the attributes of a laggard even like majority you are here and therefore you're probably early adopter early majority okay but this is important because if we build platforms we build tools we build capabilities this is true of red hat or true of anybody out there in the platform engineering game you have to understand the audience you have to sell to okay i like refer to this concept of pathfinders and builders i put them in two big groups to make this a bit easier the pathfinder as a pre are the influencers you must motivate that you must capture if you can and you if you have them in your organization if not you get to be the pathfinder for your organization and then the builder are the people the worker bees the people who have to bang out that code you know kind of that nine to five experience if you will doing the work they're given here's another way to think of this if you worked in a manufacturing organization there are the engineers who designed the productization pipeline meaning the people who designed the assembly line make sure all the tools are in the right location make sure all the blueprints make sense that's the engineer and then there are the assembly line workers the people come in every day and punch out the square peg into the square hole you've got to have both types of people to be productive and successful in today's world okay so the pathfinder you got to think of them as your marketing target the builder is your production target your product target you have to build tools and capabilities for the average builder while at the same time making sure the pathfinder to be successful all right so think about it like this though we're not talking about unicorns here we're talking about horses all right i like this little book and i thought the image was great go get it go that link there and get you a copy of the book to read it to your child now this this developer game is important to understand because there's 31 million developers according to idc as of 2022 now this number used to be 20 million i've been saying 2020 idc up the number on me i want paying attention so it's 31 million that's a lot okay and it's grown from 20 to 30 just in the last few years and it's expected in the next few years to grow to 48 oh my wow so where are all these people coming from it's like they're coming out of the woods here and everybody wants some new ai train model they want some new you know web based api they did a web app they need something they need a mobile app well it turns out that growth is coming out from uh coming from the low code or no code world so that might impact the way we think of our platforms too am i building for the command line developer the hardcore developer with vi emacs skills who knows how to write that java code or i'm building for the person who likes to point and click and that's could be a very way a very different way of thinking about it okay all right so how do you do this how do you figure out who your users are and how do you speak to them this is important you got to think about how to build a collaborative environment around apis and your entire ecosystem should be api driven your entire platform infrastructure should be api driven because the goal is to make this plug and play customizable very reusable and they in turn your developers are going to build apis themselves so this important thing to understand another thing that's important to understand when it comes to being the developer's developer is you need three additional roles if you're a platform team without these roles you're going to struggle all right so one is a product manager who it owns this platform this platform as product and wants it to be awesome for their customers otherwise known as application developers right might be the low code might be the high code i like low code versus high code might be the vi versus emacs it might be the you know point and click it doesn't matter the product manager basically wants to learn their customer base and make sure their product is awesome for their customers the ux person this is the person who's going to be doing that research and understanding exactly what the user experience ought to be they might be a design person might be a research person might be all the above and then here's the developer advocate the person who's going out there and evangelize make sure those golden path templates are awesome the documentation is awesome that you can get on board it and they're right there in the slack channel with you every day to say hey guys here's how you do our new cool thing i'm here to help well this can all be one human it's a little hard for one human to do all these things but it can be one human and but these roles are important when it comes to understanding what it means to have that platform all right so here's an example for senior product manager for developer platform and i just put this in here you can see into it as a company more and more big organizations are hiring product managers to be associated with their internal platforms so if you don't have this person yet you really ought to find this person perhaps it's you right now in this call you can volunteer to be that person and take yourself on a whole new career career trajectory all right if you're going to be a product manager though you got to at least understand a couple basic things read the book by um read the book here at sv svpg right this is a guy named kagan he basically talks about the four risks the four risks include feasibility usability viability value so is it technically feasible meaning can we even engineer this thing is it usable can the user even consume it all right can they even do what they need to do with that api that web application that mobile application whatever it might be can they read the readme file and the markdown uh the markdown readme file and the github repo is it viable can we afford to do this as a business can we invest with all everything we need to invest and the most important one and the hardest one is does it add considerable value considerable value to offset the cost whether that be the learning curve or dollars associated with that new innovation that you hope to put out in the market so think about this for a risk and one thing i'll tell you and we got to wrap up here in a few moments and you feel free to throw questions at me in the chat i do see those things going by in real time i also see some of the stuff happening over there in slack looks like jack there responded to my mentee meter uh sounds like a brand name for lie detector that's a good one good one jack okay so here's a little special sauce i'll give you when it comes to being that great product manager being that great platform engineer being that platformers product person i want you to think about this basic thing focus on the story and i'll tell you a secret for those folks who are still with me and didn't get bored at this point in time the story is so important and it has to do with this very simple thing a human cannot protect themselves from a great story your program since birth to receive great stories let's let's talk about the first second i learned about this by the way with a lady named nancy duarte she wrote several books i learned about nancy duarte because at redhat we once paid her a hundred thousand dollars to consult with us to teach us this basic principle i didn't learn she wrote it all down in books which i didn't ask people hey let's just go read the books so that's what we've done she got this basic idea of the hero's journey which was identified by joseph cambell and his book and these links are all here very important you can actually then go find the uh the george lucas link there is actually where george lucas the guy who invented star wars thanks joseph cambell for the invention of his book because there would be no star wars without joseph cambell so the idea of the hero's journey is a powerful concept is programmed in all of us at a dna level you as a human when you watch and hear these stories cannot protect yourself from them all right so it's important to understand a basic thing here when we are the platform team we are the product management team we're the developer advocate whatever we are we're not the hero of the story we are the mentor all right so let's kind of dive into that a little bit so one thing when i interview people and i've often used this before some people here in the chat might also remember this i ask people do you love lord of the rings or do you love star wars or which one which story do you know better did you did you watch lord of the rings did you watch star wars and people will pick one or the other there's always the occasional person like i hate all fantasy and sci-fi i don't do any books okay for for those people do no books and no movies i don't know what to do with you there's gotta be something else that you like like knitting or something but the idea here is pretty straightforward are you luke or obi-wan kanobi are you luke or are you yoda and this is an important understanding of the role if we're building a platform if we're the product management team we're the platform engineering team we're the platform as product team we're yoda we're not luke okay that's an important idea as a matter of fact we're not frodo we're gandalf frodo has to carry the one ring to mordor okay and put it in the volcano and destroy it to save the world gandalf provides mentorship tools and ideas and education and encouragement just like obi-wan kanobi did just like yoda does so that's an important element you know and star trek doesn't have as much of this idea right so dj maddie there star trek doesn't have as much of this idea doesn't tell this kind of cohesive story though i bet it's in there someplace i have to go find it uh if i at some point there's some other examples in the slide deck you can have access to like rocky and karate kid so how do you understand those developers those those uh luke skywalkers those yoda sorry those um those uh frodo like people how do you basically think about them well they are creators they are the people who can do this magical thing by putting their fingers on a keyboard typing in what looks like arcane gibberish to the rest of the world like just this weird sing you know sometimes english with curly braces and semicolons or weird spaces if it's python right or maybe it's capitalized or not capitalized no one even knows what the heck we're typing but that ability to put fingers on a keyboard and type out stuff and make it run is the magical superpower we're talking about here and the way we think of it when we are developers you're thinking i made this thing i created this thing my favorite is i bent it to my will i made that damn thing work it didn't work at all but that script that bashell script that i wrote works now it does what it's supposed to do my answer will play book does what it's supposed to do it doesn't matter what the technology is if it's a playbook if it's a bashell script or a piece of java or go code it's the same idea it didn't exist in this world i typed it in with my my fingers and magic is now happening and even when i go out and talk to children about these basic concepts i talk about being the producer not the player the creator not the consumer because think about the little kids you know these days they're all playing on their tablets and smartphones you give them when they're two years old they're playing you know whatever the current game is fortnite etc and i talk about being the maker be the builder because that's the magic is when we can do that sort of thing all right so your ultimate goal is to empower energize educate and enable you got to figure out how to make those creators excited you might offer something like this which is a dev rel way of thinking of the world what is the developer advocate to they want to make sure that those people those developers that you're working with can get on board easily they have a golden path they have newsletters and getting started they have video tutorials they have an faq whatever it is you're making sure they are ready and i'll just show you this one little thing real quick and that is we have a a let's go here i'm going to actually give you this url so this is our online little example of a portal okay and you can see right here so let's i'll put that there so this is backstage as a portal and this is janice this is specifically our version of it and you can see i can basically come in here and say i want a template for a new ansible job or i want to use i want to create a dotnet front end application with ci i want to know js with ci the idea is that you offer these templates to your developers so they can get started easily remember i talked about that developer and that wait time how long are they waiting before they can be productive how long are they basically sitting there on their hands waiting for a virtual machine or trying to figure out how many days or weeks it takes to making their first pull request with code that matters with this sort of tool the portal allows them to basically find all the documentation figure out what they need to know get started rapidly that is the magic of the portal and that sits atop the stack that we talked about earlier so this is what people are all excited about this concept of golden path templates of course there's things like docs and apis and other aspects okay so let's that's just a quick little thing there are other things that i could show you when we talk about securing the software supply chain that includes the runtime side of it with things like acs which is now available to cloud service or maybe you're interested in our new red hat trusted application pipeline i'll give you that url also if you hit me up on slack we can get you approved and into that system but that is a brand new software as a service we have out there today and of course you can do some really fun things with it like run things through a salsa compliant pipeline uh and of course there's a lot of things a lot of capabilities there all right i know we're nearly out of time here so let's kind of wrap things up okay so let's remember a bunch of key things we talked about today in a very short period of time hopefully it was kind of fun but i want you thinking about focusing on that team focusing on all those folks that are involved in the creation of software because it is a team effort we need the developer who can do the magical typing thing we need a security and compliance officer who's going to make sure that we build things that are more secure more compliant and actually adhere to all the rules of the industry whether that be cis kubernetes cis docker pc i dcs right think about all those compliance requirements we have today in a big enterprise they are critical they are important and most importantly they should be shifted left and automated we've got to think about our ops team whomever is responsible for qa project management peos right product owners everybody's involved with this and by the way my dba there even though they look like a zombie it's because they love the walking dead it has nothing to do with the fact that i think they are the walking dead they love the walking dead so i like to basically make the point we are all geeks together and you can take these geeks to lunch you should and spend some more time with them all right so it's all about continuous improvement here is a list of phenomenal books that i'd recommend these are all fantastic books and so marty kegan inspired for how to be a product manager along with trisa torres and continuous discovery habits of course everyone should have read accelerate devops handbook investments unlimited the phoenix project lean startup so if you have to go back in time and i wouldn't recommend that so like going all the way back to crossing the chasm though that's a pretty interesting one but if you want to just go back about 10 15 years check out lean startup check out the phoenix project there's also the scrum book is fantastic i went through the scrum book again recently and i just realized how great it is but all these books will help you better understand what it means to build better software within your organization and help you achieve your goals your outcomes uh with your dev teams your product teams your platform teams and that is the end of my story and i finished up just in the nick of time i believe let's see if there are any specific questions we think i first of all i need to do something that we usually don't get to do in these kind of virtual settings man that was awesome i really enjoy your presentations and speaking of all the chat comments everybody else did too so you delivered as usual um last call for questions folks uh anybody you want to like jump in here if not um burr do you still code like i know that what you've been doing the last couple of months but uh do you still go these days i primarily write documentation on what coders want use cases and diagrams but i still will write a little bit of code and i still have a lot of fun writing some bash shell scripts as an example too because you got to automate all these kubernetes things so just a little java code a little bit of javascript code is the world i try to uh be close to wonderful perfect um i i can only extend what everybody said in the chat so thank you so much for your amazing presentations all the amazing work you're actually doing um everybody else go check out all the links and all the books and all the free downloads especially on developers.redhead.com um our next sessions will probably start around let me take a look 10 30 a eastern time which is like 4 30 p uh central european summertime and uh i did take a look through the stages that we have so like you can go and pick your your stage but if you want to have a couple of recommendations so one is definitely a must which is the hitchhiker's guide to application connectivity by marc so you can't let that slip um and just because i'm highlighting a couple this is because these people bribed me um so just to let you know right so another one is quacas for spring developers so if you really want to go deep into quacas make sure to go to the java and app modernization stage and listen to eric um whom else did i find here oh yeah we also have something about fuse eight so if you're interested in like more specific topics uh also available to you and we'll have a ton of stuff around modernization coming up including a lot of open chats and breaks so check out all stages and make sure to enjoy the rest of your day er thanks again so much thanks everybody for being here and see you in a next session yes thank you so much you guys have a great day


I welcome you all to this lecture in the course Introduction to Paninian Grammar. In this lecture, we continue introducing the overall contents of the course and first we try to understand what do we mean by systemic approach which we shall be focusing on in this course. There are lists or lexicon which are part of the system of Paninian grammar. These lists, lists of words, lists of lexical items in a language, they form the core part of the grammar, the Paninian grammar. These lists or the lexicon, they are arranged in a particular manner and they are governed by certain principles. These principles and these arrangements are made in such a way that they feed into certain rules, thereby explaining the usage that is part of the language. Also these lists of the lexicon is annotated. The items in the lists, they are annotated. These annotations help trigger certain rules. These annotations act as conditions for the rules to apply. Now with this much background, let us look at the textual approach. Here is an important list or lexicon called Dhatupatha. This is a list of verbal roots. Dhatu is a verbal root, patha is the list. On this slide, there is a screenshot of the first page of the book that is referred to in this course and this page displays the Dhatupatha of Panini as ascribed to Panini or Dhatupatha. And here is a list of 48 verbal roots appearing on this particular page. These are also known as bhvada-yaha because at the beginning of these 48 roots appears the verbal root bhu. Bhuv sattayam. This is the entry in the list. There is number 1 given over here followed by the verbal root bhu followed by its meaning sattah. Sattah means existence. The verbal root bhu generally denotes the meaning to exist. This is the meaning of this entry. Now after this entry of the lexical item, there is some instruction, some annotation. Udhātah paras maibhāshah. Now this line tells us something about the verbal root bhu and additional information. This annotation triggers certain kinds of rules to apply with respect to the verbal root bhu. Let us try to understand what this annotation triggers, what it stands for. So, this first word udhātah refers to the vowel in the verbal root bhu and the metalinguistic marking is that it is udhātah. What is the meaning of udhātah and so on? We shall see it later on right now. Just let us understand that udhātah is a mark noted on the verbal root bhu. This triggers the operation of addition of augment e after the verbal root bhu as part of certain kinds of suffixes which are known in the Panangian grammatical tradition as ārdhadhātuka suffixes. For participle suffix t, after the verbal root bhu, bhu plus t, there is no augment but in some other cases this augment will come. Now the word paras maibhāshah in this list, paras maibhāshah. So, the word udhātah triggers the operation of the addition of the augment e after the verbal root bhu as part of some suffixes. When we derive the verbal forms of the verbal root bhu which denote the future tense like bhavita or bhavishyati, the augment e which is added after bhu that is triggered by this word udhātah. Now the next word is paras maibhāshah. This word triggers the operation namely that a certain set of suffixes only are to be added after the verbal root bhu which are otherwise known as paras maibhāshah suffixes. So, we get the forms bhavati, bhavata, bhavanti, bhavasi, bhavata, bhavatha, bhavami, bhavavaha, bhavamaha as against bhavate, bhavete, bhavante. These are not what are actually used in the language. So, the word paras maibhāshah over here indicates that only ti taha ante are added after the verbal root bhu and not te ite ante. This is how this list is arranged together with some annotations, some instructions. This is how the dhātupādha is arranged. Next we come to the list of nominal roots also known as ganapātha. And here you have one more screenshot explaining some examples of ganas. For example, atha ganapāthaḥ prathamod dhyāyāḥ. And here are two examples of the ganas which appear in the first chapter. The first one is sarvādīni sarvanāmāni. This sutra appears at this number in the text vayākarana siddhānta-kaumudi and the ashtādhyayi number is 1127. And here there are some 35 words listed in this gana and the sutra says that the words in this gana, 35 words, they are to be termed as sarvanāma. Pronouns. These 35 words are sarva, vishva, ubhā, ubhāya, dhātara-dhātama, anyātara, itara, tvatva nema samasimha, urvaparāvara dhākshana, tarāparādhārāṇi, vyavasthāyāṁ, asaudnyāyāṁ, svamadnyāti dhanākhyāyāṁ, Āntaram bahir-yogopasam vyanayohu, tyad tad yad yad yad yad yad madas ekad vi yushmad asmad bhavatu kim, 35 words. They trigger some operations in order to generate some specific forms, like sarve, sarvasmai, sarvasmāt, sarveshām and sarvasmin as against rāmāha, rāmāya, rāmāt, rāmanām and rāme. This is how the list of nominal roots will trigger some operations. And on this page, you also see the second gana, namely the svārādhi gana, which is termed as avyāya. Then we also have the metarules, known as paribhāśa-pātha. On this screenshot, you have a list of 30 metarules stated on this page. And this paribhāśa-pātha begins with the paribhāśa, vyākhyānato vīśeṣa-pratipatir nahi sandeha dalakṣanam. And so on. These metarules help understand the functioning of the overall system of panini's grammar, which takes the input from the lists that we have seen earlier, and then the rules that are triggered by those lists. And then we obviously apply certain metarules and then derive the desired output. We also have an important type of text, which is called shikṣā text or paniniṣa-shikṣā, as you can see on the screenshot. Shikṣā texts are primarily the treatises on phonetics. They describe, among other things, the process of speech production, which is also shown with some underline on this particular page, which is part of this screenshot. And we shall study these verses in detail later on. Apart from these lists and these texts, which trigger the application of rules. In this course, we shall also study certain other supplementary aspects of panini and grammar. They are listed on this particular slide. The first amongst them is the teaching and learning of panini and grammar, very important one, because we have said that this tradition continues till today. And we hope that it will continue also in future. This tradition continued from 500 BCE onwards, primarily as part of an oral tradition. The text being memorized and transmitted from one generation to another orally. Then at some point in time, it was also written down and it was also part of the written tradition. In this process, we observe that several scholars, they became part of this tradition. They contributed to the development of panini and grammatical tradition. We shall take a note of these scholars. It would not be possible to go into the details of the contributions of these scholars in this course. We may do that in the advanced course. The other important topic that we shall be studying is about the words in modern Indian languages, which can be better explained by using panini and grammar and also the process of derivation of sentences and words. Let us look at these aspects in some more detail in this lecture. So, teaching and learning of panini and grammar, it continues till today in different styles. The first one is the traditional Parthasala style. And even in this traditional style, there are various schools, various ways. And of course, the university style. And we know that there are separate universities focusing only on the teaching and learning of panini and grammar. There are 15 known Sanskrit universities in India. The curriculum of whose has panini and grammar as an integral part. The degrees that are awarded in both these systems are like MA and PhD in the university style, as well as for example, Vyakarana Chudamani, Vyakarana Ratna and so on in the traditional Parthasala style. There are various approaches in the traditional style notable amongst them are Kaumudi style in which the panini and grammar is taught in the form of a rearranged text, rearrangement done by the Vyakarana Siddhanta Kaumudi. And then there is another style called Kashi ka style in which the panini and grammar is taught and learned in the sequence in which the sutras appear in the text of Ashtadhyay. Kashi ka or Kashi ka vritti is a commentary on the text of the Ashtadhyay. This commentary is the oldest surviving complete commentary on the text of Ashtadhyay. And the current traditional style of teaching and learning of panini and grammar continues in this way as well. Along with these we shall study the newly formed method which is termed as Pumbai method which combines the features of both Kaumudi as well as Kashi ka. This will be an important part to know about the current panini and grammatical tradition. As far as the oral tradition of the panini and grammar is concerned, we have already said that this text of panini and grammar was committed to memory primarily because it is a part of the Vedic lore. It is considered as Vedanga. It is also considered as the main Vedanga, mukham vyakaranams pratham. And therefore panini and grammar got transmitted from one generation to another and continues to be transmitted even today in the same fashion. There are several features of this particular transmission which we need to study. Those features are methods of memorizing the text of Ashtadhyay. There are various methods. One of the methods taught to me by my teacher about which I shall be talking later on is the Faisutra method. Faisutras as a unit. We also note that the current transmission of the panini and grammatical tradition is marked with the features of both the Vedic tradition as well as a non-Vedic tradition. Thus it can be considered as a wonderful confluence of both these traditions. There is another important aspect in this transmission and that is that of a Pushpika, a colophon of a sort in which the numbers and the sutras they are interwoven in a wonderful style. We will talk about this later on. In this oral tradition there is a unique place of sutras with same shape. For example, Atashchopasarge appears twice in the Ashtadhyay, first in 3-1 and then in 3-3. The meanings of this sutra appearing in these two places is different. So, there has to be some precaution that has to be taken in order to remember these sutras distinctly in these two distinct places. This forms an important feature of the oral tradition of the Paninian grammar. Then there are scholars who have contributed to the development of Paninian grammar. There are traditional scholars and the lineage of these scholars. These scholars have composed commentaries and sub-commentaries on them. For example, the Kashi Kabratthi which is a commentary has two important sub-commentaries known as Nyasa and Padamanjari. These sub-commentaries are commented upon by later scholars and we have Tantraprabipa, a commentary on the Nyasa and Makaranth, a commentary on the Padamanjari and the tradition continuance. We also note that the text of Ashtadhyay got rearranged in the course of time from 12th century CE onwards and reached a refined state in the form of the text called Vayyakaranasiddhanta Kavmudhi which has dominated the curriculum of the Paninian grammar in tradition as well as university style education. These scholars developed the Paninian grammatical tradition with their contributions. We shall take a look at the major contributions of these scholars in this course. Apart from the traditional scholars we also note that there are several modern scholars who have contributed in the development of Paninian grammatical tradition and they have composed their texts in English primarily explaining the Sanskrit texts. There are traditional scholars in modern age who have contributed in terms of texts written in Sanskrit. Some of them have also composed texts in English. They have also contributed in terms of ideas. Then there are some modern scholars in modern age who have contributed in English, French, German etc. We bow down to all these scholars and acknowledge their contributions in the development of this unique tradition. Then there are some scholars who have developed some computational systems modeling Paninian grammar. We bow down to even these scholars as their contributions have developed this particular tradition. Then in this course we shall study the pre-Paninian grammarians. The grammatical activity known to Paninian grammar, the background of this grammatical activity namely the Vedic era and of course the corpus on which the Paninian grammar is built. The corpus from which the Paninian grammar is built. We shall study this aspect as well. Apart from the Paninian grammar we also have non-Paninian grammarians who composed their texts. There are other systems of Sanskrit grammar pre as well as post-Paninian. They are considered as non-Paninian grammars. These are traditional Sanskrit texts and there are some modern texts written in modern languages which can be considered as non-Paninian grammars. They are also very important for a student to understand the importance of the Paninian grammar. Another important aspect is the words in modern Indian languages and the Paninian grammar which will be a topic in this particular course. We must realize that Sanskrit is considered to be a historical stage of many of the current Indian languages. As an effect we see that lots of words in the modern Indian languages are borrowed directly from Sanskrit. There are some other words which are borrowed with some modifications and so on with the phenomena like meaning retention, meaning change happening in the modern Indian languages. So examples of words in modern Indian languages which can be better explained using Paninian grammar will be a topic of study in this particular course. We also observe that certain words are coined in the modern era utilizing the generative aspect of Paninian grammar. In this regard we invoke the articles 344 and 351 of the Constitution of India which gave directives about the development of vocabulary in Hindi primarily and also modern Indian languages. Taking inspiration from these articles the government of India established CSTT the Commission for Scientific and Technical Terminology and this commission has brought out more than 70 volumes of vocabulary to be used in Hindi and the general methodology that is followed in producing this huge amount of vocabulary is based on the generative aspect of the Paninian grammar. This becomes an important point of study in this particular course. Then we also study the process of derivation of sentences and words. As we shall see the term Vyakarana assumes the segmentation and then using these segments the higher units get derived. So derivation of words from roots using the rule based system and then derivation of sentences from those words once again using the rule based system is an important topic that we shall cover in this course. We shall also study the principle of compositionality which functions in three levels in the Paninian grammar Artha, Shabda and Swara. The Paninian grammar is composed of the sutras not all sutras are equal they do perform different kinds of functions accordingly there will be different types of sutras. So different types of sutras are composed to meet different requirements of the system. What is the philosophy behind such formulation? This is the question we shall ask and try to address. In other words what makes one type of sutras different from the rest and we shall try to address this question with some examples of sutras. What would be the prospective questions? Say for example decode a particular sutra follow some methodology and decode it. Then other very important type of question is given some data analyze it and form on your own rules to explain those data and then tally the rules that you have formed with the rules formed by Panini and try to see what is the difference and try to understand the methodology used by Panini. What is important is the conceptual clarity. I must also introduce a practice that I am going to follow in this course. In every even lecture I am going to introduce the benedictory verse of this statement also known as Mangala Charana found at the beginning of celebrated texts in this Paninian grammatical tradition. On this slide we find the very first verse which is generally recited at the beginning of the study of Paninian grammar. I shall recite it for you. What this means is salutations are to that Panini, the great Panini who after having obtained the initial 14 sutras from Lord Shiva constructed the entire grammar. What these 14 rules or sutras are we have noted them down in the previous lecture. Salutations are to that great Panini. This is the Mangala Charana that is generally recited at the beginning of the study of Paninian grammar and we have also recited it now. There is another practice that I am going to follow in this course. After this Mangala Charana I am also going to recite 5 sutras at the beginning of each Pada or sub-chapter in the text of Ashtadhyayi and in this lecture I am going to begin with the first Pada in the first Ashtadhyayi and these 5 sutras are Vraddhiradayic, Adengunahan, Ekogunavraddhi, Nadhatulopa, Ardhadhatuke, Nithicha, I repeat, Vraddhiradayic, Adengunahan, Ekogunavraddhi, Nadhatulopa, Ardhadhatuke, Nithicha. We will continue doing this in each even lecture. Here are the references and I thank you for your patience. Thank you.


Want to use a sled to maximize your lower body gains? Watch this. Our next caller is Pete from North Carolina. What's up, Pete? How can we help you? How are you guys doing? Good, man. All right. Well, again, I do want to thank every thank you guys for everything that you provide. Just give you a little background in I am 62 years old. I am a former physique competitor. Got a diagnosis of non small cell lung cancer in June. So I had to put all that stuff on the back burner. So just wanted to thank you guys again for talking about how talking about how food makes you feel because as a physique competitor, you always like measuring all the other stuff. And when I found out that diagnosis, I started to go off the deep end a little bit, but started to reel it in a little bit because of a lot of the things that you guys have provided. So getting wanted to thank you for that. Appreciate you and remission.  Um, I am taking an oral chemotherapy. So I'll be on that for years. Okay. They tell me anyway. So we'll find out. It's a learning process. All right. No. So my question is you guys have mentioned a lot about using the weight sled and I was just wondering what workouts for the weight sled would look like, uh, whether you would do it, let's say if you were doing maps, anabolic, if you would do that on the trigger session days, would you alternate, you know, between like heavy and light sessions, would you push for distance? Would you push for time of also, you know, if you had a recommendation as to what type of weight sled one might buy for their house? No, great question. Okay. Fun question. Yeah. So with maps and a ball, here's how I would do it. I would do it on the trigger session days and I would spend about 15 to 20 minutes pushing the sled. Wow. You would do trigger days on the other days. Yeah. This will be fun. We're going to be different if you do it on the days of foundational days, then I would do a couple sets, two or three, I guess, sets of the sled before you move into your squats. But otherwise you can do them very frequently and I would do, like I said, 15 to 20 minutes, uh, on, on those trigger session days. And what you want to focus on, if you do it that way is technique form and connection. Um, so you'd be pushing it for 50 yards or so. And the goal is to get with a nice, deep, full, full step, push all the way through, move to the next step, push all the way through something along those lines. And the goal is really have good technique the entire time. A nice, consistent cadence. Um, and I guess they keep it around 50 yards. If you want to go heavier, you can go heavier with a shorter distance, but you want the intensity. If you do it in that way, I want the intensity to be about moderate. Okay. So the, the idea is you want to feel it a little bit, but really you're just trying to slowly get better at it. And little by little, you can add, uh, resistance to it. Sal, remind me maps in a ballock is, uh, back squats, front squads, deadlifts for the three and for the three, right? Usually. So my, uh, my recommendation will be a little bit different and, uh, none, neither one of these is right or wrong. It's just, I think whatever you enjoy doing or what you're more like. So I have a tendency still after all these years of training and knowing better and knowing my body to, uh, especially when it comes to squatting and deadlifting and, uh, I, I overreach, I like to push the weight. I like to get after it. And, uh, even though I know better, uh, I tend to, and I tend to flirt with the overdoing it a little bit line a lot. And I love to use the sled when I do that. So let's say it was a, uh, you know, back squat day. And I decided to put on probably more weight on the bar than I should have or do an extra set or, you know, do more reps than what's programmed. And, and then the next day I'm feeling it. So when I hit the next workout where it's probably front squats in anabolic, I actually replaced the front squats with driving the sled that day. Um, and then I can go a little more intense than what Sal's recommending. So Sal's recommending on trigger, which if I, if I do on trigger days, that means I'm assuming that I'm training my legs the other three days a week, I'm probably going to do it, uh, significantly light and easy. And it'd be more like speed work or like slow mobility driving the sled. And it's more almost, and I'm thinking like recovery. I'm not thinking about moving some serious weight on sled. But if I use it in replace of a leg exercise in anabolic, I can actually kind of push the weight a little bit more and I can get away with pushing heavy weight and it doesn't quite do as much damage as say the front squat or the back squat will do it. So that's how I like to use it. And I, and I use it with any of our programs, uh, cause most of our programs have, you know, at least three days a week of leg training. And I do train my legs pretty hard and I tend to overreach there. And when I do the next leg routine, I replace whatever leg exercise I had initially set up for now sled driving that day. Yeah. So I've done a bit of both. And, um, so in terms of the intense way that I've applied it and really try to build up work capacity. Something like you'd see in map strong, um, you know, as a great fit to incorporate heavy sled pushes, heavy sled, drags, uh, and that's all, you know, within those, those type of in between workouts. Um, and the work capacity sessions, I should say, um, but in terms of like how I use it frequently, it's more like low to moderate intensity and that way I'm just building up a lot of volume. So, uh, you know, in between, it's just such a, it's such a valuable tool to, uh, so there's two different types of sleds I would recommend. So there's one's more like a prowler sled where you have the handles where you can push, uh, and then there's also like a sled drag, uh, like a fat boy sled rogue provides, for instance, uh, where you could actually like get a harness and then drag it backwards, drag it, you know, laterally, uh, and you're able to get a lot of those types of stimulus and movement for your legs that you don't really get, uh, because you don't tend to train a lot in different planes of motion. So this is going to build up volume, uh, with that, which is going to get your secondary muscles, your stabilizing muscles to respond better, uh, with your lifts. And also it's very recuperative. If you keep the intensity low, uh, to, to, to drive blood flow and to get, you know, that healing process to really, uh, you know, accelerate. So that's pretty much how I use the, the sleds. And now we didn't address. He asked, um, as far as like the distance or whatever. So I, you know, I use like a, if it's really, really heavy and, and, and I think of it like you're almost like you're doing like walking lunges. So if I'm doing like walking lunges, I'm going to do, you know, 10 and 10 on each leg. So whatever that distance is, I don't know. It's probably like 40 yards, I just say 40 years about the gauge that I've tried to kind of prescribe. But yeah, it's, it can vary depending on the space that you have.   So it's like doing 10 and 10 on each side because you're obviously alternating as you push a sled. So I'd kind of keep it on that. If I, I'm going to do, uh, and how I decide like the load is if I'm going to do like a shorter distance, just like say the 20 yards down and I want to go as heavy as I can, I'm going to go really heavy and I'm only going to go there. If I'm doing more recuperative work, like kind of sound just, I'm going to go a much lighter load and I'm going to go there and back, right? So, so that's kind of how I decide on the distance or how many reps I'm doing is based off how I'm using the tool. Am I using it more towards a recuperative day and get like a volume builder, kind of like what sound just saying, or if I'm replacing a leg day training session, which is how I use it more often, I'm going to load more and I'm not going to go as far as distance. I'm going to really try and move some weight. Thank you. Yeah, no problem, Pete. Thanks for calling in. Thank you very much. I appreciate it. Yeah, the sled is super versatile, isn't it? Yeah, you know, it's like a million and one. Yeah, nobody was nobody was wrong and there's it's a preference thing. I just I love using it to be able to add volume and frequency and not have a lot of damage. I love and I do do sometimes just my whole leg workout. And that's like what you do, like if I feel overrun, you know, like I overdid it, then I'll do that. But it's it's such a versatile tool that and you can do it so often. If you do it right, you can do it so often to get great, great gains from it. Yeah, yeah, it makes it fun.


We are right now at the 17th hole, TPC Sawgrass, Island Green. Sir, we're famous. You've got 100 tries to hit that green. How many are going on? Seven. I think seven would be my lucky number. Uh, 12. Favorite number? I don't know, out of 100? Yeah. 10. Probably about 20, maybe. Realistically, probably like five. I think I could probably put 50 on. I think I could go half. I'm confident enough to make that shot. 75 out of 100. 17. I would like to say all, but probably 40, I would say. I would say about 99.


So when we, at the Communist Manifesto for Personal Finance, tell you to invest in a stock market Index fund You probably think to yourself How can they tell us to invest in the stock market? Don't they realize that will make us complicit in capitalist oppression? Do they even believe in socialism? First of all, we believe in Marxism as much as any communist in China Second, let me ask you one question Do you buy groceries? Yeah Do you pay rent? Global pandemic, not withstanding, yes I do Do you work at a job where your labor increases your employer's revenue? I guess Wouldn't you agree that doing any one of these things already makes you complicit in capitalism? Well, we have to do those things If we want to survive working, buying groceries, and paying rent are all necessary functions So is investing As we've explained before, if you don't invest your money, you fall victim to Inflation Meaning, the money you save will slowly decline in value So if you don't put your money into an asset that grows in value over time, like the stock market You'll find yourself caught in an endless cycle of wage slavery until the day you die All the while, you'll still be complicit in capitalism Okay, but you realize there are poor and working class people who are already caught in an endless cycle of wage slavery How can you tell us to invest in the stock market when millions of Americans can't even afford basic necessities? This is a valid point There are many Americans who can barely afford to survive, let alone retire We agree 100% But we must ask the question If A, you're a middle-class socialist who can afford to invest And B, already complicit in capitalism, how are you helping the poor and working class by not investing in the stock market? Well, I take the money I'd be investing and give it to charity Okay, but if you're a bourgeoisie socialist, or as we like to call you, a You can probably afford to give to charity and invest at the same time Also, if you're a Marxist, you realize charity doesn't solve the problem of inequality If anything, charity perpetuates inequality because it enables systemic injustices to continue So even if you give away most of your money, you're still complicit in capitalism Basically, you're setting yourself on fire and not even keeping other people warm Yeah, well at least I'll still have my Marxist principles What does that mean? It means I can sleep at night, knowing I'm not one of those bourgeoisie capitalists who invest in the stock market Bourgeoisie capitalists like Karl Marx Exactly, just like Karl Marx What? Yes, Karl Marx, our socialist prophet, not only invested in the stock market, he speculated in the stock market He probably got the money from his partner Friedrich Engels, who owned a textile factory Wait a minute, are you telling me that the founders of modern socialism were not only members of the bourgeoisie, but one of them was a capitalist pig?