All right. Seems like we're at time. So welcome. Thanks for coming. This is, data processing is made of people. A case study in role empathic API design in Sahara. And that word empathic is really sort of the core of what I want to talk about today. Fundamentally, this is a talk about user experience and user stories in OSS infrastructure. So what are we doing here? To start out, so a little story, I started my career not as a software engineer, but as a nurse. And one of the first things that I did in nursing school was open my textbook to the first chapter. And I saw a figure that looked a little bit like this. It said, one of the most important virtues to have as a nurse is the ability to show empathy, to understand what another person is feeling or thinking. And one of the ways you can demonstrate empathy is by placing your hand on someone's shoulder. C figure 4.2. And so I've created sort of a copyright safe version. I didn't want to actually use the picture of legal ramifications and whatnot. But I mentioned this for two reasons. The first is that empathy is a really hard virtue to talk about without sort of getting very sickly, sweet, very quickly. We all know how important virtue empathy is. We all know how important it is to connect with another person, understand where they're coming from, and respond to it appropriately. But to talk about it in depth is hard to do effectively. And secondly, it's very obvious why a nurse needs empathy. That's very core to that job. But at the same time, I'm going to argue that empathy is really at the heart of what software developers do as well. And that in the end, we are only possibly doing our job as well as we are able to be empathic to our end users. And we're going to get more concrete about it, though, than figure 4.2. So moving on, the problem that we're going to be talking about fundamentally revolves around the idea that building a very clean, intuitive user experience in OSS infrastructure products in which you're trying to tie together many, many backends, many implementations of the same use case is very hard to do in a user empathic way, in a way that lets the user know where they are and what to do next. Secondly, we're going to talk about user stories, which are a traditional, agile approach to dealing with this problem. And then we're going to talk about a solution to the problem that occasionally works, did for one use case in Sahara this cycle. It's going to have a little to do with empathy, and we're going to use a Liberty feature in Sahara as an example of it. And then we're going to have a conclusion. So in case you're not terrifically familiar with Sahara, who isn't really familiar with Sahara? Luigi, get your hand down.  So a few people. Cool. So Sahara fundamentally has two major portions. API v 1.0, the cluster management API, allows you to create templates, which allow you to sort of reproducibly create big data processing clusters, whether these are Hadoop, Spark, Storm, or any of the various distributions of Hadoop, Hortonworks, MapR, Cloud Era. We have plugins for all of those data processing engines, and you can spin up any of those clusters using Sahara. Then we have an Elastic Data Processing Engine, which allows you to actually create templates for your jobs once you've created them, store them in Sahara so that you can run them on data over and over again using a more limited set of configuration values. And that's a lot of what we're going to be talking about today. Today, primarily, we're going to be talking about EDP. And we're specifically going to be talking about the bit right between Create Job Template there, where you're solidifying the job that you've written, putting it into Sahara in a reproducible way, and then the step where you actually run it. That's a critical flow arrow, and we're going to be talking about why in just a few minutes. So you might want to be here. Hopefully, if you're an OpenStack ATC, you're very much the target audience, and you care about UX, you care about your user sanity, you want to write APIs that are going to make people feel at home and like they know where to go next. And you want to compare notes with me because we did something that I think is cool and that people might want to know about and might well be reproducible in other projects. If you're a Sahara customer or you're interested in potentially adopting Sahara in the future, you will learn about a new feature that will make it easier for organizations to run EDP jobs reproducibly and efficiently. Or you're just a really huge UX geek, and you really like to talk about Agile, and that's great, and you should come talk to me afterwards and we'll geek out forever and it'll be fabulous. All right, so how are we doing for time? We're doing perfectly fine. So the problem that we're addressing. So we'll first go to the concretion. Sahara allows you to create these job templates that encapsulate this reproducible big data job. They map to specific jar files, which you've written. You may have written them in Java, in Pig, in Hive, StormSpark, et cetera. They allow configuration per run. So when you write a big data job, there are a number of configuration parameters that you can bake into it to make it more usable in various circumstances. So the challenge that the Sahara team had prior to liberty was to create a configuration scheme that was broad enough to allow you to run any of these different types of jobs, which have very different ways that each of them likes to be configured, different ways that information likes to be passed to them, and to do that as simply as possible. And we succeeded, right? There was a solution, as of Kilo, that had three basic categories of configuration parameter that you could shove into a job. They were configs, which is sort of an engine that's processed by, or a dictionary that's processed by the engine. An example of that might be the number of mappers in a Hadoop job, right? That gets processed by the engine itself. There are params, which is another dict that gets processed by the job itself. So these are named arguments that you pass into the job that you have written into your job specifically to make it more reusable. And then finally, there are arcs, which are also processed by the job and take the form of a list. So these are only referenced positionally by the job itself. And as you can see, different engine, or different job types, Java MapReduce, TypePig, et cetera, can use different sets of these. There's also a complication with input and output data sources. Some of these specifically take top-level input-output data sources as arguments to the job. Some don't. It worked. And this is fundamentally what it looks like as of Kilo when you're trying to run a job. You've got a main class. Here, this is a Java job type. So this stuff up here, the main class, the Java options, these check marks, these are fundamentally UI sugar. There's nothing in the API to express these. But we built these into our UI because we know that these are things that Java jobs need. And it was nice to have them here. But if you're using the API itself, there really aren't any rails to keep you in place. And what you have is you have these little buttons down here for configuration arguments. So just a pop quiz. If you're trying to run Terogen, the basic example of a Hadoop job, who knows what to put into those fields to run Terogen? There are some people in this room who probably know. But they don't count because they work on Sahara. So this is hard. This takes a fair amount of specialized experience to know what to do. And you can figure it out. It's not the end of the world. You can look at the Sahara documentation for a while. You can look at the job that you're running. And you can figure out what to map. But it takes time. And it can be a little aggravating, even if you already know what's happening. So there are a few assumptions that we made as a team that made this a pretty good solution. And I want to be clear that these are valid assumptions. There's nothing wrong with any of these statements, really, or at least not deeply wrong. When you're wrapping multiple back ends, exposing the deep utility of those back ends, trumps ease of use, that's true. You want to enable your power users to use all the features of your back ends. Otherwise, they're going to hit a wall and they're going to go somewhere else. We're writing software for experts, fundamentally, on OpenStack. OpenStack operators are professionals. If they hit those walls, they're going to stop. So we have to give the full feature set. And finally, the last assumption, and this is a really basic software assumption that's incredibly important to keep in mind all the time. And bit us in this case is that the simplest thing that can possibly work is usually the best solution. And that's absolutely stunningly true. That'll never stop being true. But we'll get to a caveat. And this solution was a great start. Because in the end, what we're doing with Sahara and other OSS projects in OpenStack is pretty hard, right? These abstractions that we're creating, Sahara for data processing engines, Trove for databases, Block Devices in Cinder, there are a lot of implementations of these. Each of them has its own unique features. And creating a proper abstraction that can actually deal with all of these at the same time is a legitimately difficult task. Making it easy is even harder. But nonetheless, that is fundamentally our challenge. We are here to unlock the entire market through cloud infrastructure. The upside here is that if we actually do, the world gets better. We commoditize cloud infrastructure. Many different companies can get in on the game. It's better for the whole market if we can win this fight. And making it easy enough that it's widely adopted is a huge part of how we get there. So this is a real challenge. It's a hard one, but it's unambiguously a good one. The bad news is that it's not always really possible, right? In this Sahara case, we could make a pretty UI for each engine. And in fact, we did, right? We put in as much sugar for the Java job type as we could to make that easy to run. But fundamentally, we don't know what your job needs. You haven't written it yet. We can't know what parameters you're going to want to pass in. We can't know what arguments you're going to want to pass in. There's no way that we can actually create your UI for your job and make it usable. You have to provide those values. We can only build pipes for you to use. The question that we haven't asked yet, and the critical question for this talk, is who are you? And we're going to be talking about that next. We've been saying you a lot, but who you are actually matters very deeply in this case. So we're going to be talking about user stories now. I say congratulations on attending the Least Bleeding Edge Hocket Summit, because fundamentally, this concept has been around for a long time. The Agile manifesto happened a while ago. User stories have been around. But they are very seldom actually properly used. There's a place for user stories in our templates. And there's actually an OpenStack summit channel called User Stories. And it's about user experiences with OpenStack. But I've very seldom seen the term User Stories within the OpenStack community actually map to what the traditional Agile user story is. So we're going to talk about that now. So an admission, I am impressed that this talk was voted in. It was really interesting to me. And it's incredibly important. But it's not the most exciting hip thing happening right now. As I say, you should all be at some presentation about containerizing bare metal to just go. But seriously, since you're all still here and nobody's walking out the door yet, this is a user story. Sort of the Agile classic has three parts. The first is as a, and then you define the role of the user that you're talking about. I want to the feature and so that the value. So an example of that, as a big data framework user, I want to create a job template so that I can launch my job repeatedly with various configurations. Sounds pretty good, right? That's a fundamental user story. No, that was terrible. That was just an awful user story. A big data framework user is not nearly specific enough. We need to get a lot more concrete about that. Because in the end, there are a few different categories of people who are interested in using these frameworks. So you've got someone who actually needs data first off. Someone who's actually going to make decisions based on something that they can't see yet because they have too much data to actually parse through it and make the decision that they need to come to. We have a data scientist who writes algorithms and spends all their days thinking about algorithms, thinking about the best, most efficient way to process the data through. We have a job developer who takes those algorithms, actually writes code, stores those jobs in Sahara, hopefully, because Sahara is just great, and a cluster operator who actually then runs those jobs and maintains the clusters on which they run. Any number of these people in any one organization may well be the same person, right? Especially in small organizations, you are legitimately going to have job developers who operate their own clusters and data scientists who write jobs or just job developers who develop their own algorithms and don't have a data scientist backing them. That's perfectly valid. But any number of these people may be wholly separate. And in the case that they are separate people, you really need to think about who this person is and what they know. So it's important to remember that UX isn't actually one size fits all. The job developer knows how to configure these job types, knows how to write them, knows how they're configured, knows what the jobs themselves want in order to work. And at least at first, before documenting it, that job developer is the only person on Earth who knows how to configure the job that they just wrote. No one else knows. They probably, and I was this person, so I can tell you, I didn't know the paths in the cluster that my jobs were eventually going to run on. That wasn't my domain. I sort of knew Hadoop administration. I was OK at it, but only sort of came into pinch hit. And usually, as a developer, we think that our code makes sense. We wrote it that way for a reason, hopefully. And we imagine that what we've written is naturally intuitive. We're frequently wrong. As developers, I think the experience of every developer sort of speaks to that, how often what we intend is misinterpreted. But we keep going anyway. The cluster administrator, on the other hand, knows cluster administration like the back of their hand. They know how to make the cluster sing. And they're the only person on Earth who knows the minute-to-minute data flow on that cluster. And the relationship with the job developer is probably punctuated by frequent complaints that the jobs aren't documented well enough. The jobs are probably documented on some wiki somewhere, which is constantly sort of sinking into lack of maintenance. And usually, the cluster operator is right. And communication with the job developer becomes somewhat of an onerous task. So right here, there's this role transition. The job developer is going to register their binaries, create a job template. The cluster operator is going to be configuring the cluster, launching it, probably running the job. And right there, there is a change between people, a change between skill sets. And it's easier for us as developers of OpenStack who know the whole flow and think about the whole flow to imagine that, OK, everybody has our own knowledge. And everybody is going to be able to map these things through effectively. Because of that role transition, that's really not true. And if we wrote two different user stories for those two different people, we'd end up with a very different set of requirements, which would end up with a very different implementation in the end. So that's fundamentally what happened here. So let's recheck our assumptions from earlier. When wrapping multiple backends, exposing that deep utility, not letting people hit a wall of expertise. Trump sees abuse. That's still true. There's still nothing untrue about that, so that's great. We get to keep that one. We're building infrastructure, and our users are experts. That's true, but our users have different sets of expertise, which we've just unveiled. No one's going to be expert in everything. We like to imagine the superhuman user who knows development and knows cluster operation and knows the whole picture, and can bear the weight of the world on their shoulders. But that person seldom exists in real organizations or in the world itself. And it's silly to expect that. Fundamentally, the purpose of OpenStack is to make this stuff easier, not to only allow the best of the best to run it. And finally, the simplest thing that can possibly work is usually the best solution. That's true. But the question that we're asking now is, who is the solution actually simplest for? Is it OpenStack devs? Is it the tech underlying this engine? Or is it the end user itself? So what's simplest for them is the real question. So now we're going to get into what we did to actually address this problem in this use case. So what we created was an interface map or a tool that allows you to create a method signature effectively for your job. So when you register a job template, you can now, with that job template, register a number of arguments. So in this case, this is Terogen, what we took the pop quiz on earlier. It has an example class, a number of rows of data to create. Terogen happens to create massive amounts of data for load testing of Hadoop clusters. Usually you run TerraSword on it to benchmark. And Terogen itself does some nice benchmarking for you too on map only stuff. So rows, output path, it's going to need somewhere to actually write the data to. And finally, a mapper count. Maybe we want to adjust the number of mappers involved. We talked earlier about args, configs, and params. You can give them a mapping type. So these three need to be args. They're in that order. Configs, the mapper count is a config that gets shoved into MapReduceMapTasks. They each have a value type. Each can be required or not required. And you can give each one a default value, if you like. So this is now, we've taken the task of configuring the job away from the cluster operator. The cluster operator doesn't have to care as much about figuring out how the job needs to be configured. We've pushed that back to the job developer. Because the job developer, on average, is going to be doing the job template create task. And they're going to know. They're going to know exactly what their job needs. And they're going to be able to define a schema. So now, when the cluster operator does this, the job launch config, all they have to do is this. Job ID, et cetera. And then they pass in an interface. They can have rows, mapper count, output path. Because the example class had a default value, they don't have to provide it. And it provides a nice semantic view. And in the UI, it gets even more semantic, as we'll see in a few minutes. So this is fundamentally what you do to create an interface. This is horizon. So you select a value type for each argument. You can name them. You can give them a description so that the cluster operator has a good idea of what actually goes there. It can be as verbose as you like, being verbose is friendly. That way, you don't have to maintain that wiki, which always falls over. Give them a mapping type. Give them a location value type. Tell us whether it's required and provide a default value if you care to. And that's fundamentally the feature. So we are, in fact, putting a schema in our schema so that you can define a job interface while you define an interface. And that's fundamentally what this is. All we're doing is building a DDL. We're building a data definition language. It's not exciting, tech-wise, but it's fantastically powerful and useful at those transitions between roles. There didn't actually have to be any change to the engine here. That's what I like about this solution is that fundamentally, because we had already created a solution that allowed any use case to be filled, allowed the args and configs and params to pass all the way through to the job, in any case, all we had to do was sort of bolt on a translation layer on top, an additional pipe by which the job developer could provide information and the job operator could take it, use it, and have a much simpler interface and an interface which spoke much better to their knowledge of both the jobs that are running specifically and the engines that are powering them. It's really the job developer's job to know what PIG wants, what Hive wants, what Java wants. The cluster operator shouldn't care about that. They should care about HDFS. They should care about keeping the cluster running. So it does require dev effort, of course, but it also fills doc requirements. So there's good reason for the job developer to want this too. Maintaining that wiki is annoying. They need to do a lot of onerous communication and it can get problematic. Creating this allows them to define that schema once, have it be machine validated as well so that easy errors in job configuration can be catched early by Sahara and we can stop them before they hit the cluster and take up time, which is expensive. So the takeaway here is that we were right earlier. We can't know the jobs config schema. You haven't written it yet, but we can give you tools to describe it. We can give you tools to communicate. And that's fundamentally where the empathy piece comes in here. By thinking about what the job developer needs, by thinking about what the cluster operator needs, we've actually found a way to put ourselves in both of their shoes fundamentally by allowing them to put themselves in each other's. We have empathy all around. This is just a big triangle of empathy between the OpenStack Dev and these two people. So fundamentally, humans here win. So we did a pop quiz earlier about this job. Asked whether we could run it. Not many people said yes. How do we feel about this job? There's an example class. It has a default value that's pre-populated with pterogen. Data rows to generate says, if you mouse over the little question mark, this number of 100-byte rows will be generated. Gives you an output path, which defaults to an HDFS path, and has a number of mappers field. Could people run this? Matt can't. But Matt's a manager now. So that happens. All right. So I did see some head shake yes, though, so that's good. So the summary and takeaway here is know your user's roles. Look for those inter-role transitions in your flow. And this is hard. You have to either have real-world experience with organizations running your tech. If you don't, you really have to go and actively pull them and ask for that feedback and really act on it and internalize it. And then ask, OK, within the flow that I'm imagining we're going to create, does each user actually have enough information and have enough knowledge and expertise to do what they need to do? If you can, you give it directly to them. But in this case, we couldn't. But we could still, and the simplest thing to do can be to leave that dynamic. But sometimes building tools to help them communicate is really the right answer. And pure dynamism like we had before with args and configs and params, it was good. It did what we needed, but that's a last resort. Generally, you really want to build more communication tools than that. So all right, good. We're doing well for time. A few closing thoughts before we open for questions. There's this fallacy that we've already talked about of the power user and sort of the super user who knows everything. And as developers, we sometimes get sucked into this idea, OK, I'm really smart, right? Great minds think alike. Other people who are pretty smart must think like me, must understand my code and what I'm imagining things are going to do here. And therefore, whatever I write, because I'm pretty smart, anybody who's sufficiently bright should be able to understand. And this is not great. I don't think it's actually what happened with the original Sahara team. Things, there were time pressures as well. But there's a little bit of, well, this is good enough. And people who are smart enough will be able to figure it out. That's a frequent part of any development process I've ever been involved with. And it is a little bit distressingly common in OSS sometimes. There's a little bit of almost macho culture in OSS that would really be better to resolve. I've talked about the word empathy a fair amount. And I actually really like that word. I think it's important. We talk a lot in software about user focus and about customer focus. And I don't think that they're adequate. Both imagine the user itself as business resources as cogs in some machine. They're not. They're people. And speaking and creating flows that allow them to do their job well, it doesn't matter just technically. It matters morally. Fundamentally, these virtues, making complexity accessible, enabling structured, clear communication, empowering everybody who use our products, those are some of the fundamental virtues of the software engineering craft. And anybody in this room who is a software engineer, I hope takes those very seriously and thinks daily about how to do these well. Fundamentally, engineering we think of as this heavily corporatized thing sometimes, but it's a mission as well. We do good work. We do good things. We make things possible that weren't before. And that virtue of empathy is fundamental in what we do. Because especially in OpenStack, we do need to win. This infrastructure does need to be democratized. It's not OK to allow there to be a handful of technologies owned by a handful of people and not allow the infrastructure of the world to be anything more than that. And to commoditize cloud, we really do need solid UX. That's the way we're going to attract users. And what we're doing is fundamentally important. So if you're a developer in this room, this is a how to contribute talk. I know some people are here because they're interested in Sahara as well. But fundamentally, I wish to exhort you. As a closing, I have made a lot of fun of this presentation in terms of it's not the newest thing in the whole world. At the same time, I am really heartened that it was selected. I'm heartened that for how to contribute presentation, we're doing pretty well for audience. The stuff that we're talking about in terms of user stories, role awareness, human empathy, this is really important for us to succeed as OpenStack. And I'm very glad that we actually talked about it here. So thank you. If you voted for this. And thank you for coming if you didn't. And just thanks. So one very last note before I close for questions. This is how to contribute talk. It really didn't fit. And in fact, there wasn't really a track that fit at all. When I was looking at the various tracks in OpenStack Summit, there really isn't a category for developers talking with each other about lessons learned about best practices. And that's understandable. OpenStack Summit is fundamentally a marketing exercise as well. And there's nothing wrong with that. That needs to happen too to get people excited in our product because we need to win. At the same time, I've been running around Japan for like a week and a half before now. And especially coming from the US, Japan is sort of an exercise in sacred geography and sacred ground. And this is our sacred ground as developers. This is where we come together and collaborate and talk about how we're going to make more things possible in the future. So it might be cool to actually have a track for this kind of thing to happen from here on out. All right. So any questions before we close? Being new to Tokyo? Oh, I see. Sure. Tokyo and Japan in general, in the United States, everything is, we destroyed a fair amount of our history. And things are pretty new. There are few places that we consider important to ourselves as a people. But walking around the city of Tokyo and walking around Japan, in general, you get a very deep sense of how deeply the history and traditions of the Japanese people map to specific places in the world around them in a way that's wonderful and fascinating and different. Sure, we're getting a little philosophical here. But OK, we got a little philosophical. So it's turned about as fair play, right? No, that's cool. Yeah, when I say that summit is sacred ground, yes, I suppose that it's both geography and time. But this is a place that's important to our people as open-sack developers, probably as important as they get. And next time sacred ground will be in Austin and in Barcelona. But we take it with us where we go. Thank you. Yeah, and any other questions? Mm-hmm. So right now, Sahara's UI is in contrib in Horizon, right? So it's not in the core panels. It's in the contrib path. It may move into its own repository in the near future. It was in its own repository in the past. It may be there again. But for right now, it's in contrib. And those panels are all under the jobs. Everything we talked about was under the jobs panel. Yeah. Please. Sure. Yeah, that can be a problem. It's documenting the documentation feature. Yeah, absolutely. So I mean, I have some documentation patches in the Sahara EDP guide. If you take a look at them, I'd be perfectly happy to receive feedback. They're pretty explicit, I think. But yeah, they're there. Sure. Yeah, absolutely. A lot of this presentation comes down to the idea that documentation is really important, which is, we say it all the time, and nobody likes to do it. And I don't know. I kind of like writing documentation. It's very peaceful. Not all the brain has to go into it at the same time. Any other questions? I don't know yet, right? So one of the big things that I want to tackle next cycle, personally, is our image generation process, which currently is difficult. It takes a bit of a super user to do it well, or at all, sometimes. And admittedly, it's a process which often you're going to do once, and then you're going to be able to use Sahara for a very long period of time. And it's something that's put on the administrator of OpenStack fundamentally, rather than on the end user in a public cloud. So it's been deemed good enough, especially because the Sahara community itself can frequently generate images, publish them, allow them to be used, and offload that from the end user. But especially as we have more and more configuration options, we're going to need to allow users to create their own images. The matrix is just going to swell to a point at which we can't possibly support everything anybody could want. So that needs to be cleaned up. Yes. Yes. Sure. Well, I've actually talked with some of the places I worked at before Red Hat, before OpenStack, about, hey, you want to hear the good news about OpenStack. And a lot of them are adopting cloud. At the same time, they don't have the resources to take on their own cloud administration right now. The more we can reduce that bar and allow people to start running their own clouds, or at least to create enough public clouds that there's better competition, there's a better market, the better things get. And that absolutely will depend on OpenStack operator UX. The more we can push that bar down, the better we do. Period. Just absolutely, yes. And that's the beautiful thing about what happened with this specific feature is we had already created the really dynamic thing that let you do anything you wanted to. And we built on this nice translation layer on top of it. That previous layer still exists. And you can still use it. So we kind of get the best of both worlds, right? We get the deep config. We get the user experience with a nice pretty UI for the operator, and all's well. So yeah, I think both concerns are valid. You still have to allow the full feature set to stand. Are we out of time? I think we are. So all right, thank you all for coming. I've enjoyed talking. I hope you've enjoyed the presentation. So thank you.


forward we are going towards the fireside chat where we will talk about Indian gaming companies going global. Chairing this session is Dr. Anurag Bhattra Chairman and Editor-in-Chief Exchange for Media Glue and we have with us Mr. Sai Srinivas, Chief Executive Officer and Co-Founder of MPL. A very welcome gentleman. Hi Cathy, thank you so much. Great to be here. Lovely to have you here. Just give us a moment. I think Dr. Bhattra is also here. Let me welcome somebody who is really in the news for the right reasons. Let me welcome Sai Srinivas who is the CEO and Co-Founder of MPL. I don't have to explain to our viewers what MPL is. Sai, first of all, let me start by asking you how have been your last 12 months personally and professionally. I know the gaming numbers have gone up, the gaming business has done well but tell us overall how it has been the last 12 months. Firstly, thank you so much A.B. and thank you so much E4MT for inviting me. The last 12 months has been quite a roller coaster to be honest. The gaming industry has leapt forward by about a couple of years in probably six months. On a personal point it's not easy to practically stay indoors for so long but hopefully with the vaccine rolling out and more people getting it we can all get back to offices in full strength and pick it up where we left off in 2019 I guess. Okay, let me start by asking you today gaming is becoming mainstream. It was sometimes on the fringes. It was something you did for leisure. Today it's not no longer leisure, it's becoming a mainstream activity. You pursue it like a career. You pursue it as like a serious hobby. You also use a gamification in education. You use a gamification in almost every sphere of life is growing. So tell me where do you think gaming is headed and give us a sense of where it will be in three to five years through some numbers that you can share with our audience. Of course. So firstly maybe the reason why gaming is becoming mainstream is that in all honesty gaming has always been in some way mainstream. It's just that now thanks to the access of internet and thanks to mobile phone penetration it's just becoming more and more accessible. Also the beauty of gaming is that games are probably the only format of content that do not have a language. For example, a game of pool can be played by an American, can be played by a German, can be played by an Indian and they might not know each other's language but they can still play the game. But you know you can't, you honestly can't say the same about any other format of content. Be it a movie, be it a video, be it the audio, be it text. I think it's universal language. That's the reason why it's also so easy for anyone to pick it up. Now that's honestly the reason why I think it will be even faster than some of the other content formats out there. Now to answer the other question that you asked, where is this headed or where are we going? I think what's going to happen in a couple of years from now is that there is going to be a platform or whether that's MPL, whether that's someone else that only time can tell. But there is going to be a platform where massive global tournaments will happen. For example, you take a simple game like chess. In two years from now, and in fact a year and a half from now, it's not far-fetched to think that a player who's playing out in New York in US can compete with a player playing out of Saapolo, compete with player playing out of Delhi in India. In massive online tournaments where there are a million or people playing, imagine this tournament, there are a million people playing, first round 500,000 get eliminated, second round 250,000 get eliminated and then eventually you have quarterfinals, semi-finals and finals. Not only is the scale of the tournament quite immense, but imagine the situation maybe where you and I are playing the quarterfinals of a tournament like that. I'm reasonably certain that a significant bunch of folks from across the world would also want to see the live broadcast of how the game between you and me is going on because we've eliminated a lot of people to get to the final eight. I think that is the future of digital sport or in other words that is the future of esports. It is going to be heavy mobile driven because most people can access computing only through mobile. Of course PC and console led the esport revolution and started with them like many other things in the world, but as and when it gets into developing markets and gets into more people's hands, it's going to be mobile that's going to lead that revolution and that's the only way you're going to get competitive esports into the hands of three to four billion people across the world if not the whole of seven billion. That's how I look at the future and that one million is just a placeholder. These tournaments can be as high as 5 million, 10 million, 12 million. It's just the limitation is just your imagination. Practically every person who understands chess can play a tournament of chess online using their mobile phone, but imagine if a similar tournament were to be held offline. It's just impossible to even accommodate more than 10,000 people offline and that's the beauty of online digital sport and hopefully we realize that future sooner rather than later. Absolutely Sai, the esports India are poised to grow and you clearly said that the beauty is that the access to the games is through mobile and that is bringing more and more players and viewers both into the ambit. Now let me talk of homegrown games. How do you think the homegrown games are doing in India and what do you see the potential for the homegrown games becoming really big? I think two points. Firstly there are a lot of incredible homegrown game developers who are doing pretty well in India. There are also homegrown game developers who are making games for global audiences and who focus on making games for western markets out of India. It's a different ball game that we still not have or still not had a AAA level game or should I say a world class AAA level game come out of India and I think this is just a matter of time. It will happen and the reason why it takes time for that to happen is that a game at the end of the day, the closest analogy that I can think of is a movie. To make a high budget movie the market has to grow. The domestic market has to grow. To make a high budget movie the person who's putting in that money needs to be confident that they will be able to eventually break even on the investment. So as the market grows the appetite of local game developers will also grow and you will see larger than incredibly large AAA level titles come out of India. But one thing is for certain, most of Indian game developers or Indian games will be mobile focused. I'm not saying they won't be console or PC focused but almost nine out of ten developers are going to build games for the mobile phone. Okay, now again, Exchange for Media is a business community for marketing, advertising media. Now, as I said, gamification is becoming part of every market year's plan because if a lot of millennials and a lot of consumers are using games as a way to express themselves or spending so much time on gaming platforms either participating or viewing, then clearly the marketers would want to leverage that. Tell us what are the things that marketers can do to leverage gaming? Sure, I think the first thing that marketers can do to leverage gaming is to actively participate in sponsoring or participating in large-scale e-sports tournaments. So for example, just take the example which we took, right? If you're running a tournament for a million people and hopefully another million or two are going to watch that tournament, that is at least two to three million eyeballs glued to that tournament, right? And in a way that's really, really targeted communication because that audience which is playing the tournament as well as viewing the tournament, for those folks, there's no better way to reach out than by sponsoring that tournament. And the cost of sponsoring these tournaments is significantly lower because it doesn't involve a lot of physical infrastructure. If you are sponsoring a physical tournament, then it always involves a lot of infrastructure and obviously that it costs a little higher. And it also becomes an easy way for marketers to actually target specific audiences. For example, different games have different types of audiences, right? Like depending on the kind of audience you want to go after, you can pick and choose and sponsor the tournament which is being held in that kind of a game, right? If you're looking at a more male-dominated audience, then you may want to go for a more male-dominated game which has a more male-dominated user base. You're going for a female-dominated game. There are games which are extremely female, skewed towards a female audience. So that's the advantage of sponsoring these four tournaments. And I think a lot of the marketers should definitely start spending time and, in fact, more importantly, spending some amount of money understanding the space because eventually the marketers who do understand the space are going to get a significant head start over the other folks who will not spend time understanding it, but then would want to understand it once it becomes fully, you know what I mean? Yeah. So Sai, again, let's talk of one of the things that we talk of is you talked of gaming does not having a language barrier. It does not have a geographical barrier. Now, the growth of internet in India happened on the back of Indian language content growing. Yeah. Now, do you think that gaming in Indian language is the next big frontier because clearly that may bring in a set of audiences that have never been introduced to gaming? Of course. I think more than gaming in Indian language frontier, I think like our honorable Prime Minister said, games build on Indian stories. I mean, if you look at Japan, there's so many games that they've launched built on their stories, stories that have originated from their land. In India, in fact, we are a land we've got so many stories, right? And every game one way or the other is telling a small story. It's a very simple story. In some cases, it's a very simple story. In some cases, it's a very in-depth story. I think more than language, I think games that are built on stories which are very, very familiar to Indian audiences will tend to do well, right? And I think more Indians come on line. There will be studios that will focus on building some of these games. Fantastic. Now, again, gaming and if I may say, esports in India is also creating new set of jobs while machine learning, artificial intelligence are taking away some of the jobs, but they're also creating a set of new jobs. Similarly, gaming is creating a set of new jobs. Give us a sense of the kind of jobs that are being created and what is the future for people who are looking at careers in gaming? Sure. See, I think this is one such industry, especially competitive esports. India and Indian platforms will be eventually net exporters, right? You will see a lot of Indian companies actually exporting the platforms to other parts of the world. What this does is that it directly creates, it directly builds a class of workforce, which is focused on IP creation. India historically has been extremely good in services, but the advantage of building this ecosystem is that it focuses a lot on IP creation. And the advantage of IP is that IP can, IP is like digital property, right?  And that creates a lot of value back for the Indian ecosystem, right? And in terms of kind of jobs it's going to create, it's going to create a lot of jobs, apart from the core aspects, which everyone knows about like engineering, product management, etc. It's going to add a lot of value to the creative ecosystem, right? Today, if there's a storyteller, most storytellers in India are either working in the film industry or related industries, right? Storytelling is one of the most critical aspects of game development, right? In fact, copywriting is a critical aspect of game development. In fact, most of the creative folks who are working in, say, film industry or the OTT industry, a lot of them will find a lot of relevant jobs in the gaming industry as well. So that entire pie is going to expand and expand quite significantly. Designers, creative writers, artists, animators, that entire space and for all practical purposes, India has always been good at this by the way. A lot of the work that happens on a lot of these top-class Hollywood movies, a lot of that work actually happens in India. There are a lot of artists in India who are actually contributing to that. So it's only going to increase the pie for all of those people. I mean, the sector itself, I think, will easily create about 50 to 60,000 jobs in the course of the next two to a half years, easy. And most of these jobs are going to be built around IP development. And the fact and the advantage with IP development is that it's not like a service where once used, the value of 50 roads, right? IPs value only keeps, it only keeps getting better and better. So that's the advantage of building jobs in the sector. Now, clearly as the e-sports audiences, players in the domain grows globally, what do you think is the role that Indian e-sports companies will play on a global level? I think the number one thing that Indian e-sports companies should, the role that we should play on a global level is that we should fundamentally define what e-sports means for our country, what I mean by that is, I fully acknowledge and understand that the western world has run e-sports on PCs and consoles and so on and so forth. But let's be honest, in our country, the number of people who have consoles or PCs is very few. And denying the opportunity for the rest of the 2-300 million people to participate in a competitive tournament just because they don't have a PC or a console, I think is ridiculous. I think the first thing that we should do is we as a country should enable the participation of the larger audience who even have a mobile phone, they should be able to participate in a competitive e-sport. And if you look at the global e-sport audience, by the next 2-3 years, easily about 30 to 35 percent of that audience is going to come from India just because of the sheer size of our country and the sheer size of consumption in our country. Now, 30 to 35 percent of consumption of any industry is coming from one geography. And I think the onus is on that geography to increase participation and at the same time build out clear regulations and create regulations which make it inclusive for users and players to participate. Fantastic. Now, clearly, Sai, when you see an Indian gaming company doing an IPO, it augurs well for the sector. That means the sector is something that has tremendous promise. So tell us, when you look at your contemporaries, you look at other players, what are the kind of thoughts that come to your mind? And tell us, how does Nazara's IPO augur well for your sector? And do we see companies like yours aiming at listing at some stage? Firstly, let me tell you that we are all standing on the shoulders of giants. It's folks like them who've put in the hard work and done a lot of incredible work because of which our lives are significantly easier. Back in 2001, 2002, I mean, I could only imagine how hard it must have been for the entrepreneurs then to even talk about gaming and explain to investors what gaming is. It is so much more easier today thanks to the work that these folks have done. So first and foremost, it is the success that some of us enjoy and some of the next set of entrepreneurs are enjoying is a lot of that credit actually goes to some of these folks. In fact, some of the folks from Nazara and some of the other folks also who work really, really hard to bring that recognition to that industry. Now, as far as our listing is concerned, I think maybe at the end of the day, every company eventually at some point wants to be listed. That's the eventual dream that any entrepreneur would have.  I think it's a little far-fetched for us to talk about listing at such a young age. I think we still have a long way to go. We still have a lot to learn from the likes of Nazara and from the likes of many other peers or sorry, contemporaries, if I may add, who listed. But hopefully someday, we would also love to be on a similar brand and list them here. Fantastic. Now, let's talk of the trends that are shaping these. If you had to make two or three predictions for the future of gaming, what would those be? Two or three predictions for the future of gaming. I think gaming in India is going to make more money than Bollywood does or all the film industry does. I think that I am certain of. In any country where gaming has become mainstream, it eventually makes more money than all the other entertainment sectors combined. It's true about US, it's true about China, it's true about many other developed economies and India is heading in that direction. The second prediction that doesn't mean that those industries won't grow. Those industries will also grow. It's just that gaming has this nature of the market size of gaming usually grows much more faster than some of the other ones. I think the second prediction that I'll say is that esports is going to be a part of Asian games. It's already a part of Asian games. Esports is also eventually going to be a part of Olympics. I think India and Indians will probably be on, if not the first, at least in the first three or four countries who will win a lot of medals in the Olympics. As long as esports across the globe recognizes that access to the sport is the most important thing. That doesn't mean that you create non-inclusive parameters such as only a person with a PC or a console can participate in it. If we provide the access to our countrymen and if 300 million people are competing in a tournament maybe, I am reasonably certain the person is going to come out on top. It's more or less going to be in the top two or three in the world. Our number one job is to provide access and the number one job is to ensure that these esports which are getting recognized by these global sporting events, they also ensure that they are allowing people with the access to the right kind of devices to increase the reach for the sport. Okay. That's very hardening and I think for a long time we've done well in sports but we fell short of winning medals except in shooting or in boxing or in athletes. I think the addition of esports to the Olympics and the Asian Games will really help in boosting the confidence of the Indian sporting and esporting community and really it all goes well that they're being included and Indians will do well. I want to ask you what are the plans of MPL over the next 12 to 18 months and what are your priorities? I think the first priority is to most clearly and certainly host large-scale tournaments in India. For example, last year in October, November, December we hosted this tournament called College Premier League where in 150 colleges participated in a national level tournament across the country and it was the first attempt. It was in fact the beta. This year we are aiming to host the same event with about a thousand colleges participating. I think first and foremost our goal is to host large-scale digital tournaments where people can participate from any part of the country in India and capitalize on India and ensure that Indian developers earn a significant amount of money from our platform. Secondly, our second priority is to take our platform to as many countries in the world as possible. We're already there in Indonesia and we're seeing really good traction there. Our goal is to hopefully take our platform to more Western economies and India and eventually take Kanjima product out of this part of the world to say more developed regions. I think that's something very few people have done. It's a very hard task and I hope we will be able to do a reasonable job of it. Sai, when you're building this incredible company and you're on this journey, who are people who are your role models and you look up to? I think my role models have always been sportsmen, to be honest. I think there are other entrepreneurs as well across India and across the world who are incredibly good role models but for me it's always been sportsmen who are my role models. For example Virat is in fact my role model. I've always been a huge fan of his and when we actually didn't sign him up it was a bit of an unbelievable moment for me and the reason why I say Virat is a role model for me is because the way the man changed himself and the way he kind of changed himself to achieve the to become the sportsman he has become and the way he shaped an entire country to believe that we can be world leaders and we can also be the kind of athletes that back in the day we used to see from Australia, we used to see from South Africa, back in the day we used to say why can't an Indian field as well as say in South Africa team or an Australian team and I think I think what Virat did was that he made everybody believe that not only could you do that but in fact you could go a level further and be better than anybody else in every way possible and for me I think that is one I've never seen an athlete inspire someone and inspire a country as much as he has. Apart from that of course the other sportsmen like Ronaldo and Nadal who are incredibly incredibly amazing as well and yeah in terms of business folks I think Indian entrepreneurs I mean a lot of Indian entrepreneurs I mean the founders of Flipkart, the founders of Infosys, like I said Virat standing on shoulders of giants they've all done a lot of good work and it's because of their good work that you know we have we have such a vibrant depro system so yeah these are some of the folks I really really look up for. Thank you so much Sai we exchange for media wish you luck in your endeavor to grow the e-spots domain in India and to build MPF to the next level so I'm sure with somebody like you leading it the goals and objectives you've set for yourself and for MPL will be achieved all the best to you congratulations on growing MPL and e-spots in India and I look forward to the next few months and years with anticipation because I know that you'll be able to do a great job at being a poster boy for this industry thank you so much all the best back to you back to you


capability. This is the place that you want to be. This is ideally the final destination. Congratulations. You're out of burnout and you're back to business. You have a stable routine.  Work-life balance is awesome. You're like, hey, look at me. I'm out of the burnout. I'm excited. I'm ready to get back to it. I'm doing well. I'm getting my job, get my cash, get my dollar. My symptoms have cleared up.  I can actually focus and enjoy things. I've got clear head, but what's that? More work? Sure. I'm doing good. I can handle that. I can take some of my rest time out. I can replace that with another productivity related thing. Capacity. The place that you don't want to be. The place that you're setting yourself up for failure and burnout once again. Congratulations. You're taking on as much as you possibly can.


Democrats call on Biden to give Ukraine F-16 jets. U.S. President Joe Biden's fellow party members are pressuring him to make a decision on sending F-16 fighters and long-range missiles to Ukraine. Members of Congress from the Democratic and Republican parties called on Biden to supply Ukraine with long-range ATA CMS rocket artillery and modern F-16 fighters, the Hill Agency writes. The present could be key in the defense of Ukrainian people and any offensive push against Russian positions, the lawmakers argue, and some U.S. military leaders agree. The agency notes. The Hill names the leading figures in the Democratic Party who are putting the most pressure on Biden. These are Jason Crowe, Richard Blumenthal, Sheldon Whitehouse, Jared Golden and Mark Kelly. Despite the calls, the news agency notes that the White House has not yet changed its position refusing to supply Ukraine with ATA CMS and F-16s. But the U.S. pledge in January to provide M1 Abrams main battle tanks to Ukraine earlier this spring after months of opposition from the White House has given calls for optimism that the administration may come around to providing even heavier weaponry, writes the Hill. Ukrainian Foreign Minister Dmitry Kuleba asks Ukraine's friendly countries to speed up the decision to train Ukrainian pilots on F-16 fighter jets. According to him, Ukraine needs not only air defense systems which its friends have already shared with it, but also combat aircraft. We need aircraft to cover our combat brigades, which will go on the counter-offensive. We need combat aircraft to protect the Black Sea and our coastal territories, Kuleba said.


So welcome all of you to probably your last session for this conference. Yeah, later there will be of course like a closing session but if you wanna go to Dewey's, feel free to go to Dewey's. Yeah, maybe the room there is quite full. Anyway, so I gonna talk about the HTTP Wonderland in PHP. So what I want to cover in the talk is a little bit of history how HTTP, like what the idea of HTTP actually is, a little bit of how you deal with it currently in PHP, how you deal with it probably in duplicate and how to deal with it in the glory future. So a quick summary or question, like who of you are like of typical developer back-end-ish or front-end-ish? Okay, so pretty much everyone, all right, that's good.  Okay, so first, a few words about me. My name is Daniel Wiener, I'm a core contributor. I'm working with the, as you see with the duplicate people, with the people contributing there. I work for Tech One, coinciding. And I also work for Chapter Three. And in general, I'm a really curious person. That means that I got sidetracked and tried to find out about a particular technology and I will suffer from doing it because it will lead or steal so much time. And that's why I'm kind of interested in that talk because I did a lot of research going on with how you can properly use HTTP and PHP and how you can design your application around that. Anyway, let's start it with HTTP. So what HTTP stands for is written down here. It's the Hypertext Transfer Protocol. So a protocol is way how computers or general stuff communicates with each other. Transfer is because it transfers data from one computer to the other one. And the interesting one is actually the Hypertext. You know all the Hypertext. HTML is a typical Hypertext. It's a document with some links between pointing to other documents. But it's not the only Hypertext you can think of. You probably all use Windows at some point and their help system is also a Hypertext because their help system in Windows has links to other help systems. So HTTP allows you to deal with Hypertext in general because like one primary entity of HTTP or one thing you can use there are URIs or URLs in general and with them you can refer to different documents. So here's another example of a Hypertext. Anyone know what this screenshot is about? Anyone know that game? Just curious. Yeah? Exactly, that's Moost. So it was a game in the 90s and you see a 3D graphic but that's all fake because it's pre-rendered graphics and it's basically a render that was kind of an island where maybe you see some water on the left side and it was a pre-rendered game basically and that game consisted of multiple images with layers on top of that but these images have been connected using kind of URLs. So there was a thing called Hypercard which was like a stack of images connected to each other and you could build something like that pretty easy over HTTP as well these days. So HTML is really just a special case. Another example is a thing called Halljason. Halljason is a common format how computers communicate with each other so like if you want to export a user you can do it via Halljason because the other computer also knows how to read in Halljason. So yeah, don't think that HTML is the only thing that's actually just a special case. A little bit of HTTP history. So here you see kind of one of the first computers which is what's called a next computer. This is in CERN so the collider is there and a guy called Tim Berners-Lee invented the web back in 1989 and his idea was that it should be easy for people to document what they do like and to write documents about their work at CERN and their research and his primary idea was that idea of linking documents together because that actually makes information helpful. Then there has been a couple of steps in that process how HTTP was constructed like all of you use probably HTTP 1.1 these days but that came out like this year a new version of it which is the 2.0 version. Maybe you have heard of it but there are a couple of misconceptions about it. So for example, people said that encryption is built into HTTP 2 but that's actually not true. It's just the case that every browser requires it but you could still use your little Raspberry Pi and talk with your foot over HTTP without encryption. But for user stuff like your browser it should be secure. That's what people like Firefox think. So here's a basic model how HTTP works. There's someone doing a request. So here you see not that popular browser anymore. Sending a request to a different server in this but it's always just computers to computers. It sends a request and that server tries to answer that request with a response. And so what is in that response? So here you see a command line tool called Curl. You might have heard of it. You can basically give it a URL or any kind of thing but you can for example ask for the tuple.org homepage and by default it will give you the HTML which is part of tuple.org. But HTTP response and request contains a request of more than just the HTML for example. Here you see the HTTP header and a response is separated into two pieces. This first the header which is meta information about what is requested or what is sent and then there's the actual content. Like in the blue you see the actual content called body and there you see the HTML. And in the header there's, there are quite a lot of interesting information. For example cookies are stored in there or also stuff like the content type which explains what kind of data do I send? Like also information like is that, was that response cached or can the browser decide that this response is cached? So that example is used for images so that if you go to a page and click to a link you don't want to download the site logo again. If you want to see that kind of information because it might be helpful for debugging purposes you can use curl-i and that will print out just the header but in general I would recommend to play a little bit around with curl. One question bit is the URL. That's basically the resource. What do I want to fetch? And that consists of a little bit more. So here you see a split of what is possible inside a URL. So a URL is split up in the scheme. Here's HTTP but it could be also HTTPS for for example secure connections. Then it's the authority which is basically the host like tuple.org but also authentication data like the username and the password and other stuff like the network port. And then that's the path which is slash user slash one which is interesting because in Drupal like in six and seven it was always like user slash one without the slash at the beginning. So for example if you install Drupal in a directory it was the path in Drupal was user slash one always but HTTP doesn't know about that. It thinks of slash slash my directory slash user slash one and that's kind of a thing which people struggle in Drupal eight that distinction between what HTTP defines and what PHP thinks about it and what especially Drupal thinks about it. And there are other stuff like the query parameters. So we have seen the header but what can be in the body? In the body it can be the HTML but there could be also form data. So if you click on the submit button on a page additional data will be sent to the server. But you can put in pretty much everything. You can even stream videos over it if you really want to. Yeah. So we have seen a quick overview of what is possible inside HTTP itself how it looks like a little bit. But we can then also have a look like how we deal with it in PHP which all of us at least somehow used. There are a couple of ways to do that. Here you see the old way like or the way how PHP does it itself without any kind of abstraction on top of it. I call it the number zero cause it's basically how you start. You might have seen something like that. So there's a couple of information exposed for you in PHP but it's all in the global namespace. So here for example you see underscore get queue and that's basically referring to the path in the URL. It's not entirely obvious why it's named like that. Because in HTTP we talked about the header. We talked about the body. We talked about the query parameters and here's underscore get. It's kind of odd. It's the language here is totally different to HTTP which is a problem for people new to it and it's a problem if people are used to that and then go to other program languages. Yeah, you can do other stuff here. It's not that important but I'm wondering whether you have seen that friend. Anyone have seen that friend? Cannot modify header information, headers already sent.   What does that mean?  I mean it's a freaking pain because that error is basically impossible to debug. Yeah, what? All right, so what happens is that as you've seen before, the HTTP message consists of two elements. It consists of the header, then an empty line and then the body. And the thing is once the headers are sent out, you cannot send additional headers. It actually says in the message cannot modify header information, headers already sent. So everything which is before the first empty line are the headers and in case you send out the body, at least a piece of it already, you cannot do anything about it. So the problem here is that in PHP, the way to send something to the body is to say print body or print whatever string you want to send out. Once any kind of code is doing that, like print an empty string, I'm not sure whether you have seen that. Or print like a debug statement or print an error message. Once that done, the header cannot be modified anymore. So if you do it, every code which deals with the header has to be executed before the first print statement. And that makes it really hard to architect your system because if any kind of code can call out to header or to print, your entire application has to be structured in a way that it cannot, that no print statement is executed before. And that's really a big problem. This global state, it's just bad architecture. So yeah, let's summarize some problems again about PHP, the way how PHP deals with HTTP. So it's a global structure. It's a global state, like pieces interacting with each other without knowing of each other. It's that causes, for example, things like random bugs. It causes code, which is incredible how to write tests for in a proper way. Or at least causes really slow tests because you need to use HTTP rather than just call out a code and check the response of that code. And I even consider that this is not really an API what PHP exposes to us. It's rather, yeah, no words. All right, so of course many people saw the problem. And so one approach is to define additional abstractions on top of that, what we have from PHP. And one way is to use an existing library. Here's a list of some of those. You see SEND, you probably heard of SEND as the inventors of PHP or somehow the people which maintain PHP partly, it's an open source project, but there are many people which are paid to contribute in SEND. And but SEND also has a PHP framework. And that framework has its own HTTP abstraction. Another one is GASL, I will talk about GASL more. It's later, but it's basically an HTTP client. Similar to CURL, actually GASL uses CURL under the hood. It's about, yeah, being able to ask in your PHP code another web server about data. Another interesting example is OAuth server PHP. That thing, you think, yeah, I wanna write a library dealing with OAuth, yeah, let's implement HTTP abstraction because my domain in my library is OAuth, so I need to write HTTP abstraction. That's just one that you have to take care of that in your library, so what they did is to write an abstraction over HTTP library. So you have this additional level, they don't provide an HTTP library, but rather they provide a web power and yeah, it makes things really hard to deal with if you don't have a common foundation for every project. Another common example is Symphony HTTP Foundation. This is a thing which people kind of criticize a lot. It's also used by a lot of people. Here's a list of them. Some CMSs, SS28, maybe a third of that, PHP, BB, can't tell there are a lot of people using it. Why are people using that? That's an interesting question, I think. I think the primary reason is actually not that it's good. It's rather that it came out at the same time as Composer came out. And Composer came out, it is a project to manage packages in PHP and because HTTP Foundation is a package, you can use it really easy using Composer in your own project. So also Drupal just has an entry in their Composer file and fetches then HTTP Foundation. I'll try to give, here's just a code, how you deal with things in the same way how you saw before. What is interesting here, I think, is that you see request query, request request, request server. It's kind of similar information to what you've seen before. Like, so underscore get is like request query. Request request is like underscore post. And request server is like underscore server. One thing which you see is certainly is that it's object-orientated code. You have the request object, and then you can get the query object out of that, then you can ask the query object about things. How does that make things easier? I think it becomes way more obvious if we go to sending data out. So here you see a way how you create a response. So you say, okay, I wanna have a response. I want to set that particular header and I want to set that particular body. So what is the improvement over what we've seen before? The improvement is, for example, that you cannot get the headers already sent thing if you print out stuff. Because the sending out of the entire HTTP message is done when the response sent is executed. So basically the code flow afterwards is then like you have this response object and people put stuff on that. They expand the body message over time. They add additional headers over time and once the system is ready to send things out, they send things out. So that typically you have just one place in your application which sends out data. But that additional abstraction also potentially helps a little bit with the writing specific codes. Here you see an example how you can create JSON. You just create the PHP array and then you create a JSON response and then you send the data out. That additional thing also has a huge impact on people who write tests because you have those objects. You have input which is the request and you have output which is the response and your tests can just look at those objects and see whether they are constructed in the proper way. Let's build an application. So we have basically everything what we need. We have an HTTP request, there's our response, our application and then there's a response. So here you see an example. Request is coming in from the left side. We create a request object in PHP. Then we have our application in red in the middle and that sends out a response. But the interesting thing is that this architecture allows us to really easy put things on top of that. There's an architecture style which is used in quite some languages which is called middleware and middleware basically is like an onion. You see the application as the core of the onion but you have additional layers around that. So here for example you see the logging layer. In that logging layer you create a request, lock with which URL was accessed and then send out, then ask the application for the response, maybe measure the time, how long it needed, additional logging and then pass out the response to the next level. And you can do that with multiple levels. So for example page caching is implemented in that way in tuple eight. So you have this middleware which is really lightweight because that middleware just needs basically a database connection for the cache and that's pretty much it. So caching looks at the URL, checks, asks the database, do I have a cache entry? If there is a cache entry, directly serve the response from it because the cache entry contains the response otherwise asked the next level in my onion. That's the logging, okay. Next level and then logging then ask the application how to create the response. And then the caching is that layer around. So once the response is then created by the application the response bubbles up to logging, bubbles up to caching and then caching can use that response and create a cache entry. And that makes it actually really interesting because we are here talking about HTTP abstractions. So you theoretically could replace, like for example you build the application using PHP but then you realize logging is too slow but then you could build this logging layer using whatever entries or something or whatever. You can basically rip out parts in your PHP code and replace that with other things which also talk HTTP. It's really interesting people these days to actually build even the application via that style. Yeah, I will talk a little bit more about middlewares later because it's also used when, you could also use that when requesting data via HTTP. So I'll give, I mean much like another entity is asking you about your response, you could also ask another entity about some data. And the example I want to present is SCASL which is an HTTP client library. So here I want to do, here is an example, how you can, what do I get here? I get the tracing data for a particular issue on Tuber.org. So you have an URL and you have a client. That client object contains the logic how to send out an HTTP request and pass the response. So we can get the data and in the result we have an object we can deal with again. For example, get the status code or get the body out of it. So we have similar kind of objects here as well. We have a response object much like we created response object before. So you could think that you could share code between those systems and you could just learn HTTP things once. So once a request, once we learn about responses and that's all you need. Here's an example how to send out a form. Yeah, there's nothing special about it. But SCASL is actually pretty cool project because it also allows you to send asynchronous data. So asynchronous data means if you say like client get it doesn't have to directly query the other server but rather it can just make a promise that you will do it. So here's an example which is called request async. So you say I wanna get example.com and when this is done, so then, when is it done? Then I want to do something and in this particular case you just want to manipulate the response but you can do basically everything here. But with that kind of architecture which is for example used in JavaScript pretty much everywhere, it allows you to like for example bike operate on these kind of things or just create the request and then don't care about it anymore and by that architecture you can speed up your code a little bit by not necessarily execute what you need. SCASL is pretty cool because it allows you to set a couple of additional options. So for example you can do like a request which gets you a cookie and then you can like you can post to do with using the login form that gives you a cookie and then you can post another thing which gives you an issue and it can keep track of state for example. But you can also say things like yeah I want to deal with redirect, so if Tool.org decides you want to redirect to a different page it can keep track of that internally but there's many many things like presented to you out of the box like logging, history, you can build your own but there's also a really interesting thing which is called SCASL service and that allows you to integrate SCASL into whatever API service like GitHub and allows you to provide those abstractions in the domain language of that particular API and then you don't have to care about SCASL but SCASL is handling everything internally and it makes it easy to write those API webpods for GitHub for example or your own site. So we have seen, I'm sorry, we have seen the response object here as we have seen the response object in Symphony HTTP Foundation. So the question is why those are two different things. Why do I have to learn about HTTP again? Like for example the author of SCASL invented like all the things like response query, it dealt with things like query parameters, he worked on all that kind of stuff and then he realized I do exactly the same as the guy from SEND Foundation, not SEND Foundation, SEND Framework, why can't we work together? And there's one group which is called PHP FIC which is the framework group which, framework compatibility group, no, interaction group, anyway, they're working on things called PSR which are, I forgot, it's the PHP standard recommendations and there are a couple of them. One for example is the way how, in which directory is your classes exist. So PSR 7 is an idea to provide request, response, and all kind of those objects in an abstract way so that everyone can speak, so every tuple, symphony, send, word press, CASL, whatever, can speak in the same language together. It was quite a success because many, many people adopted it already, tuple 8 adopts it already, symphony adopts it already, et cetera, et cetera. So let's have a look what's inside there. You see there's a response, a request, that's typically what you think about it, there's a message interface which is kind of a more abstract thing, there's server request, yeah, and there's your interface which I will talk about later. So here's a little bit of sample code, sorry for that all kind of code, but here's a really sad thing you see here, let me show you that. Where's the mouse? Anyway, okay, so there's one way to create a request, it's using Gaffle, so you pass in the method, so get opposed, the URI, and some additional headers. Or you create a request using a library called dirac-tools, not sure why anyone invented that name, but it's the way how send deals with HEP, and there you pass in the URI as first argument, and the method as second argument, and then the body as third argument, it's the thing is that these objects are bound to a particular use domain, because Gaffle usually don't have to deal with bodies because Gaffle most of the time just sends get requests, so it doesn't make sense to have a body. But it's sad because now even you have these abstractions, you need to relearn specific things over again. Anyway, one interesting thing is that those objects, unlike symphony, are immutable. What means immutable, immutable means they cannot change at all. So here you see an example, you see request with header, and what with header does, it copies an existing object and modifies just that particular header entry and creates a new object with basically a copy of everything beside that one small change.  And yeah, it's kind of an academical discussion, sadly. Yeah, immutability, it's coming from functional programming in which you don't have any kind of state. The interesting thing is that at least in the functional programming world, that helps you to parallelize your computations, for example, because nothing is interacting with something else directly. But you could really argue that in PHP it doesn't make sense because PHP just have a different mind model. And yeah, but people have chosen it, but it also helps you to deal with the things. Anyway, here's an example how to deal with URLs in PSR7. So we can create a URI object, say I wanna have a different path and I want to have a query parameter and after that you can cast it to a string and use it. That's actually kind of a cool API compared to pass, how it's called pass URL which gives you an array with some entries but not always the keys. And afterwards if you want to manipulate it, you can manipulate that array and then you need to reconstruct the URL afterwards which is really hard, but you could for example in your projects just use that particular class to manipulate URLs. If we talk about immutability, so with path creates a new object and then that new object gets a function call with query which also creates a new object and this is then stored in the URI variable afterwards. Yeah, you can like it if you want. Anyway, here's an example of PSR7 middleware. It's interesting because here you don't get a request and response is sent out but rather you get passed in a request, you get passed in a response and you get passed in a next callable. So that next callable is basically in the onion, the more inner layer. So like the logging middleware gets the application as next. But you can also see that you get a response here and the reason why it's there is that's the only way how to manipulate objects by sending it continuously through the nested world. This kind of structure is used now by a couple of projects. It's maybe a good idea for you to check it out just to have a little bit of fun. Anyway, yeah, that's what it, if you want to evaluate it, here's the URL. That's more important, I think. This is a couple of cool podcasts and documents you might wanna listen to. For example, the first one is about HTTP2, like one of the inventors of it. Change log is also really interesting. And come to the sprints tomorrow if you have time. All right, that was it. Any questions? Hello. Hi, yeah, thank you for the session. One thing about PSR7 is do you have any good practical example that I could use today, for example, because it's been kind of theoretical for me at this point. So that would be great. I've maybe not really mentioned it, but Gaffle in the version six is using PSR7. So if you use Gaffle, you already deal with it. I cut it that out how to deal with PSR7, for example in Drupal. But in Drupal, you can pretty much also return a PSR7 response or ask for a PSR7 request and internally Drupal converts the normal HTTP foundation objects to PSR7 objects. So that's one way to deal with it. Another way to deal with it is to play around with those kind of frameworks. They are really lightweight frameworks, like Relay, it's built upon a different architecture than MVC, which is more suitable for the web or the Slim Framework would seem to be one of the fastest PHP frameworks ever. So that's one way how you could learn more about it. Does it answer your question a little bit? Yes, but for example, could I use a middleware to integrate the CDN, for example? Yes, I mean, in a CDN, you probably want to deal with setting additional headers, right? Yeah, you can write a middleware in PSR7, so I'm not sure whether there's some out there for specific CDNs, but you could write a middleware which manipulates the response object. Yeah, that was exactly so. So something like that you could use it for today. Yeah, I mean, today, what means today for you? I mean, if you deal with Superlate, for example, or if you deal with Symphony Framework, you could write such a thing in that project. I mean, if you click especially on Stratility, so those slides will be online and they are all links, and Stratility is a middleware framework. It's basically the thing which defines those middlewares using that particular function signature above, and that kind of project has a couple of examples already, and then probably there are links to other people implementing exactly that interface there. Yeah, so for example, if I had a CDN, it would probably be a good motivation for me to create such middleware and then give it away for free so people could use it with WordPress Drupal easily, so that's sort of framework or application-independent way. Yeah, exactly, yeah, that was a good word at the end. Middlewares are independent from your application. Here you see this logger, and logger is just a PSR3 object. PSR3 is a PSR about how to deal with locking in a framework-economic way in PHP. Yeah, thank you.


at 11 61. The Barbadian has a real shot at a medal. Sabrina Dockery has had full start issues over the last year. She looked very comfortable in qualifying though has run as fast as 11 33 this season. Dorset in the final last year for the Bahamas. She returns this year as well. She starts this final in lane number seven on the outside in the number eight symphony Patrick of Trinidad and Tobago 1182 in qualifying final of the under 20 girls 100 meters. This could be fast Terry. On your marks. It should be indeed. I can see Ter along being pressed by Dockery, Dowdy, certainly Niles should be in the mix-up. Final of the under 20 girls 100 meters off they call. Dockery got a brilliant start for Jamaica. Ter along is up well too. Dowdy is running well. Niles tries to come forward. Ter along and Dockery. Ter along and Dockery. Dockery creates the upset. 11.22. That is a sensational performance from Sabrina Dockery. So often the bridesmaid. Now she is the champion. That came out of nowhere or maybe it didn't. 11.33 coming in well beaten at the Jamaican high school championships and she now knows she's not just a champion but she has smashed her lifetime best. 11.26 down from 11.33 and this young lady just keeps getting faster. Wow. And it looked like a very interesting race in third place as well because the young lady from Antigua and Barbuda just have sneaked into that bronze medal position she's looking around to see. Has Dowdy finally done it? Has Dowdy finally gotten on the podium for Antigua and Barbuda. The Jamaicans are 1-2. We know that 11.26, 11.32. Ter along is real gracious in defeat here. Has Dowdy finally gotten bronze? Yes she has. 11.64. Chialena Dowdy up to so many fourth place finishes. Finally will be on the podium as the Jamaicans celebrate the 1-2. What a final. Niles gets left off the podium for Barbados. A nine nurse delivered in the on the 17 category. But you can't help but be happy for Chialena Dowdy for getting the bronze medal here tonight. Here's another look at it. Terrific start from Sabrina Dockery. She flew out of the blocks. It wasn't a bad start from Ter along. This is where Ter along would usually go away. But Dockery didn't allow it this time. And Chialena Dowdy learning from the experiences of the last year finds a way to fight off Niles off Barbados and snatch the bronze medal. What a moment. What a race. Just a brilliant start from Dockery in particular. She came out of the blocks like a bat out of hell and took control of the race very early on and never relinquished it despite a very, very stiff challenge from Ter along. 11.26 for Dockery. 11.32 for Ter along. 11.64 for Chialena Dowdy. 2.100 of a second ahead of Chialena Niles off Barbados. 11.66. Positive 0.3 meters per second. The wind speed. Let's find out what Gerard Marseille is up to.