Okay, so Yehuda gave us some vision Ed gave us some technical details and Usually the part that's missing is this so what now I? Don't know about you, but that's always been kind of like I'm a little bit OCD and that's always been my Problem with conference inspiration is that I never feel like I have any actionable steps What do I do next though? What do I go home and talk to my boss about what do I go back to work and implement? I never really feel like I have a clear picture. Well, sometimes I do but in general I don't feel like I do so That's what we're gonna talk about right now in case some of you are having that feeling Okay, yes, so that was Yehuda That was Ed and that this is me so Can are you brave enough are comfortable enough for your hand? Do you are you thinking that were you thinking that as we were going through these things? Yes, okay good First I think it's important to review how ember works because ember doesn't work like our peers There's not a single company that owns us ember We own us It's a collaborative effort Completely unless we show we all show up and we all participate it doesn't happen What does that really look like what can it really look like so? It could look like somebody submitting a PR on a weekend to help get some doc shipped It could look like somebody donating to ember on open collective It could look like a company donating 20% of their employees time to work on open source it could look like a company helping to Sponsor a major initiative to get a big piece of work done. It could also look like a Company sponsoring their product Sponsoring us by letting us use their product at note at no cost to us So the role of the core teams so now we talked about how ember works now Let's remind ourselves. What's the role of core teams? Well the core teams are here to define our vision and to facilitate progress and To lead the work and make space for the community to join What about the community? What's the expectations there? Well, we want you to participate in the RFC process and submit PRs to help the implementation go and help write docs to try out new features and tell us what happens and a lot more there's a lot more to it than just that but those are the things that are sort of These are the things you can do as a community member We all have to participate and we all have to do the work and that work takes different shapes and different forms But ember only really works when all of the ember users pitch in to help make ideas happen Sometimes it might feel like core teams aren't saying much and we might not be our bad We might be heads down shipping things. We might be busy raising kids We might be dealing with a global pandemic and there might be a lot of stuff and it might just be a quiet time Maybe taking vacations. I don't know. We try to have lives But here's the thing You do not have to wonder You don't have to go on Twitter and say oh, I think ember's failing because blah blah blah If you don't think progress is being made if you don't think there's as much Movement as you think you would like to see guess what? you get to ask and You could even take a picture of this slide In case somebody tells you you can't ask because I'm telling you right now You can ask these are the words. These are some of the words you could use if you don't know what words to say We want you to ask because we want to be able to Tell you what's been happening and sometimes we just hyper focus and forget So how can you get involved some places you can start you can visit the new contributors channel in discord I just made it today because We had some ideas and one of them was How can we funnel new contributor energy because discord might be overwhelming if you're not used to discord So I'm a gamer and I've been on discord since like day one of discord. So to me It's like just use it. It's a big deal But for other folks, they've given us the feedback that it might be a little overwhelming So here's a place where new folks can go that want to start contributing but don't know how Start a conversation at work Hey, we use open source We all have to contribute to ember to make it work What can we do here at work to support the thing we use at work? Make sense, right and If that conversation doesn't go well or if you need ideas on how to have that conversation Or if you want some core team members to have that conversation with your boss Then reach out and let's schedule a call. Let's help figure out. What is the best contribution path forward for you and your team? You can also help join the players project So this is the URL for the players project. We're trying to project manage it right out of the open You can see what's in progress what's been done what needs owners still You can DM me on discord if you want to join the players team. Maybe there's something that you feel like you could really own This is an opportunity for anyone here that wants to to become involved and this is also how you can keep track and In closing I'll say this Ember works the best when we all participate The core teams are here to do heavy lifting, but they can't do all the lifting I've really tried honestly.  We all have to participate in this community For this open source JavaScript framework that we love and there's a ton of ways to do that My DMs are open Reach out to me. Let's get everyone involved and let's make this great idea happen Thank you


So, we are basically building a social real time game shows like multiple game shows. So, when we talk about the stress testing we first need to understand like every system has their capacity limit. When you are running any production system at some point of time that production system will like come under the stress because of the traffic which is coming and then starts responding slow showing errors more than reacting in a unpredictable way which we don't want. So, stress development development help us to keep check on their development all the time. So, if you are not doing stress development development you are doing prayer development development where we are praying that your system will never fail. So, when we talk about like load on a system or stress on a system we first need to understand how is our traffic coming. We need to describe our traffic like in our case because we are running a game show all that traffic comes at exactly a single point. So, that generates huge amount of stress and because people everyone want to enter the game show they like try to fetch all the information which is required to enter the game show and they hit our server a lot. So, which like similarly similarly you can describe your own traffic that what is your peak load like at what time in our system is your system ready to handle those kind of load. So, then like you need to understand the limits of the system because without understanding limits you won't be able to optimize your code. Then you need to understand like on different loads how the system is performing so that you can identify bottlenecks.  So, understanding the bottleneck and then fixing the bottleneck is most critical part. So, when we talk about scaling a system it is not about just increasing the number of subwords it is about identifying the bottleneck and actually going and fixing that particular bottleneck. So, that you can your system is end to end ready to table. Like whenever we talk about like stress table development like we need to understand how to start what is our baseline like let us say I have a server and I can easily handle a thousand requests per second. Is it your right thing like is it the max protec energy. So, we first need to identify the end points on which our users can generate load of the system or it can actually create stress on our system. Then once we have the identified our like base like end points then the second thing is like benchmarking results. When we talk about benchmarking results we need to benchmark it with some baseline. Now how to identify the baseline. So, the first thing to go set up a empty server more like let us say you are running a node share server with your own like set of code. So, the simplest thing you can do is have a empty node share server with a simple endpoint. It does nothing it just take interest return a response simple okay response. Now with this you can start generating node of that system with a given set of system configurations and you can identify your baseline that a empty code share server which has a simple rest in here returns okay can maybe generate like twenty thousand request per second. So, that will be a kind of baseline on which you can then start thinking that okay now my server which is doing some task how it is performing. So, then the next step like obviously is to start generating node on your server and then measure in terms of baseline. That gives you an idea that okay from the baseline how far I am. Like can I even reach the baseline like so that gives us a more like mental order in which we can work with. So, with this we can find bottlenecks we can optimize our code we can test again and then we can optimize. So, this is a whole next cycle which we can do. So, to give you a like bigger picture. So, this is more like a final version which we want to achieve every time. So, we never want to generate node on our production system because at the same time even users are making request on the production system. So, we make it exact technical production. So, we know like how our production workload like perform when we are running our test workload. So, the configuration of systems need to be same. Second is we need to simulate like we need to have clients, lot of clients who can actually go and generate similar kind of node. So, let us say you are having like a app maybe iOS or Android app. So, you need to simulate a similar kind of behavior and have similar like same number of apps generated or maybe more like a simulation of that. The third thing which is very critical is plan your test. Now, when we say plan your test it becomes critical because you need to have moderately user behavior. Like one of the thing which we does is you can have a proxy and like play through your app and then identify how the app is actually performing with the help of proxy. So, we use Charles proxy. What it does is we then we play the mocking user behavior. It exactly gives us how our APIs are doing. Like what is the first API or the second API. So, that we can exactly submit and make our own test plan. The fourth step is start the test. So, we try to simulate the test at the same time on multiple devices. What it does is it actually try to simulate the production environment with like multiple clients sending the request at the same time and generating stress on our server. So, we know how our server is actually performing at different venue. And then finally watch for results. So, in our case we use new running. We also have some internet dashboard which actually help us identify how many requests we are serving. What is the latency like which user is actually behaving like what is the app's latency. So, before like step this development methodology we were actually like even sending request like taking 60 second to actually giving the response to the user and which is like not a ideal behavior for a user. So, why we do it? So, once upon a time like we were we are just a start up we like keep developing features and so many features and you are very happy. You are like okay our app is ready now we want to see scale. Like we want to experience what happens in scale terms. And the unique part in our case is we send a notification to all of our users and everyone comes at the same time. So, even though like in our past we developed a lot of games and all of their games we worked with millions of users. In this case even with less number of users our system like apps, tablets, respondents, they slow. All the latency of each user entering the game show was very high. They were completely done over we are not able to enter the game show. And then we were like we don't even know how many users we can handle them. So, the first thing which we decided is for like remove the bottlenecks. First optimize the most critical weekends so that we can give user that initial the initial experience to its best what we can achieve. So, the next question is how we did it. So, it's not that on the one day like we started and we reached to a final stage where we are generating load on the system and now our system is performing in a super awesome way. We went into stages where I gradually to meet as a story like how we started and all. So, enough. So, first thing like when we started it is our first request. We wanted to optimize so that we can handle like huge number of first requests because everyone can make initial request for our server which is more like a different request. Like the user want to get their data with which it knows the initial information to enter a game show. Then we thought let's try to create a stress on our server. So, we used jmeter to actually jmeter to say a pool which is like a batch of jmeter open source can go and use it. So, we used it and hit our A theory like a thousand times at the same time. And when we started we started from our local system. So, we had a developer had a laptop he used jmeter and he started generating load then he went to the library saw the logs and then identify code it's actually happening that we have huge amount of users coming at the same time our system is not performing as it is even the single response time can reach to 60 seconds on the code when lot of people come at the same time. So, then we actually went inside like added logs, added timestamps and then identified what is the critical piece what is the critical section which is actually taking the most time and then we try to make part of the things as soon as optimize the code, identify all the things which we needed and then we read on the same test action. Now, this thing like for a starter this thing is good enough we are able to generate some amount of load we are able to get a request but we cannot achieve like everything in this setup. So, the limitation is what is there is no how much is tested environment. Everyone is running on their own laptop every laptop is different. Second is this. So, a single instance for single machine cannot generate infinite amount of load. Every system has their own capabilities and when you start generating like when you start making infinite request from the system it is going to generate it with time because of the limitation of the instance. So, another thing is sharing test code in itself is hard because like I have my own stress test code someone or another have their own stress test code he want why he send them on Gmail or maybe share using Dropbox or somewhere. So, eventually there was no standardization plus the coordination is hard because even at such a critical time all your major workforce like work to just try to identify bottlenecks and fix on it. So, multiple people started and load at the same time and the final result is not accurate. So, the standardization is very important and coordination is very important. Plus it is a very many process I need to go actually when the test and tell everyone that ok I am running the code. So, automation so obviously like we thought let us move all the steps at a single place. So, we will move it to a version the code system which is they can have it in jet lamp we are using jet lamp. Then instead of having our own local instance we move to a single stress test server. So, we said this is our server from where we are going to generate it. And everybody in the company can go to the same server and start generating it. It is good like now we are at a much better place everyone knows where the script like load generating scripts are everyone can go there and generate load. It was like really good cause other developers who are new to this they can go and start generating it. We achieved a lot of stuff like we came to a place where our all the stress test code is standardized. But the problem is again what happened like one day I ran it and I started generating load at the same time there was another worker who again went to the same machine and started generating load. So, the problem is coordination become like coordination is still a problem because multiple people can come and start generating load on the single system. So, you need to communicate you need to post on Slack that okay I am there to start the test no one else should start the test. Again like there is no automation because I need to go as such to a stress test server and generate load from there and again we are limited by a stress test instance capability. Like now they mean like they are easily able to identify the problem. If we automate this thing and we tell everyone in a single place that okay now stress test is started don't go and start again. So, if they are able to identify where button is from there they can start it and even they have capability to start it then it will be like great. So, we move to a version where we actually use Jenkins for doing the same thing. So, now we have a stress test instance we actually configured it Jenkins you can talk with now Jenkins it clones stress test code on that particular instance and run test from there. Now we are like in a good state when everyone can go and start testing from Jenkins. So, even testers they want to do this. So, now because eventually our ABA is like developers want to empower other people who can go and do all those things. So, now the only problem which stays with us is we can only generate limited amount of load in our like simulated production environment. But that limited amount of load is not good enough. We want to reach to the end of our system. So, we know at any point of time how much stress we can handle. So, for that we knew that now we need to handle the problem where we can instantiate many instances while even like costing check because other problem is let's say developer comes he spawn like ok today I am going to generate load from 100 instances. I am going to generate infinite load so like everyone will be proud that ok I generate the most load like I know our system also such a thing. So, for this like we use Terraform it is very easy to use say infrastructure as a code it simply with combined infrastructure as a code but it is not limited to infrastructure as a code. You can even have like pass as a code or SAS as a code even you can it supported by many provider it is written in like it uses a check of configuration language you can even use JSON but I find it easier to use so it is written in code and for all our like stress client instance we use NWSC instance. So, like I am assuming everyone is aware of NWSC instance. So, let's go deep into Terraform and understand how it works because without understanding Terraform it is really difficult to directly go and create instances and all those things. So, first thing Terraform can be support more than 70 providers which are officially documented on their website but community support is like more than 100 and as you can write your own like provider if you want. If you have your own custom setup where you want to use Terraform you can write your own provider because they have a code point here and then there are a lot of providers. So, like before going to talk about commands you can directly go and show it in the code. So, in this case what I like I have used modules so I will go into one of the one of the module. So, let's say I went into a VPC module so what this module does is this module generate a complete network for me. Now, with this module I will generate a VPC a public subnet, security group I will give access to my like whatever access like security device like for the CLI's routing device and like setup update it. So, whenever we want to write a module or module in itself is Terraform code. So, whenever we want to write our own Terraform code we need to first specify what provider you want to use. So, that when we are actually running our code it knows that ok these are the like ABI each one we use it can download any dependence. So, in case of providing ADM class it is going to download ADM class CLI which internally we make all the AWS tools. Now, we write like we define what resources you want and all the like required information regarding the source. So, when we write the complete Terraform module Terraform code what it does is internally create a dependency graph with this dependency graph it gradually goes and identify what task I can do in parallel and what task I can do sequentially and start provisioning the structure. In our case what it does is provisioning like the network and inside that we have to introduce like instantiate resources like instances. So, I directly go and like simply run Terraform in it what it does in this case it already I mean it will say that I will download it. Now, other small commands are validated. So, if you validate your code and this point of time it will tell is there any like syntax error that you have done. Now, we have a code right, but you can't understand if we directly run our production system the problem is we don't know what is going to happen we don't have any kind of visualization so, it gives a command plan with this we can exactly see what is what is the plan it is more like a real world mapping of what is going to happen on the production system. So, now in this case it has provided some IP addresses because I already told you that your CID and CID have block IP addresses <IP_ADDRESS>.1.6 but there are so many which are computed because as of now at this point of time it doesn't know what their value is going to be we might provide it sending from some other resource or it would have computed based on the code configuration. So, these all these information will be computed when we actually apply it before that just to show you and show you the command graph Terraform graph. So, what it does is a complete dependency graph. In this format it is not very humanly but what you can do is copy this and post it to any cloud visualization it will actually show you the graph. In this case it is very complex thing everything is in parallel most of the things are in parallel which don't have dependency. So, what it does is it itself it identify dependencies based on the like if you use any resource argument in some other resource or you can also define your own dependency with the help of just like there is a dependency which you can define anything else. So, let's what I will do is I will apply it on my local my own AWS account. So, it will generate a instance. Meanwhile we say let's go slides because it will take some time. Yeah. So, I already talked about in it it is to create your workspace where you are going to actually work at the multiple parts. Then validate it help validate your code. Plan will give you a exact execution plan which is due to one of your production system. Apply it and actually apply it then I think in every like Terraform code we are going to define some variables which are called dynamic variables which we can inject either from like environment or environment variable or to our own code so that the main code and variables are separated then we can also define our outputs because in some cases we might take some output from one of the parts of the code and use it in some other part of it. So, in my case I have multiple modules. So, in for one module I have only networking. It provides all the networking details which can be used by instances and then I use it.  They are also. So, how they manage they are like how Terraform is different from other like providers. You can also provision infrastructure using Ansible but Terraform keeps state. So, it's state is a real-world mapping of how your infrastructure is. So, if you have a state file you can exactly see like you can tell how my infrastructure is provisioned on actual universal. By default store the state in local. So, in our case we have storing state local in Gentiles using the job number. So, that way it is unique. But you can because of the problem is it also contains sensitive information like let's say I am a resource and creating a user ID it will keep the state file I am access key and security which is like you don't mode that. So, you can use a mode back end which store this information security. So, one of the thing which you can use for free is S3 plus DinoD. So, DinoD is used for locking. So, that when multiple people run it prevents security. And then when others like secure partners then we are doing it locally. It takes the complete state from the back end and store it in heavy. It doesn't store it in hardware. So, that it will get common access. Modules are more like reuse of the code. So, in our case like I have a network module and I have an instance module. So, now if anyone want to work on by for creating a complete network layer they can use my module. They can go take the module and directly use it. We don't. So, it helps in reuse of the modules. You can. So, there are many modules which are already there. So, there is a paraffin registry where there are already pre-existing modules. You can directly go use it. But there are a lot more on JCOM. You can directly pull them from there. And you can specify the input parameters of the module and use the parameter from module to another module. So, let's come to our final version. We automated everything with Jenkins. So, now there is a single base from where we go. We run our test base. Paraffin is useful for generating modules. In our case like it's everything is not tested using Jmeter because everything is not in SKA. There are some code which is in this batch of it. So, we use our custom code, but we use a command named it. What it does it runs some specific script at a particular time. You can go. And our test code is in simple, single repository which is as I told. So, we know like if something is failing on the code side, we know who did it and now it is part of our release process. So, before everything is running. So, at that before it is we know ok now our critical data are failing and the time we are actually explaining it to all the Indians. We are actually generating load with the exact same scenario which happens in production. So, in our case codes we used are Jenkins, Taraffin, it means Lamar, Jmeter, custom scripts and custom client apps like we store our own with third party API which we are using. And we have internal dashboard to identify how much time it takes. We use neuralink to see latency, load and all those things. I think this is important because these are the learnings which we got during the complete this process. When it is in Taraffin, always do plan before applying. Because if you apply, you won't even know what you did to it. Code can fail and all those things you will be able to identify at the back stage. And once you are done destroy everybody want the same cost. Like in our case we initially started with on-demand instances and that instance is still learning we are spending a lot of money even though we are learning. So, how Taraffin is different from like if you know about cloud formation, they do same task cloud formation for AWS Taraffin's loads and loads. What it does is Taraffin will take the approach where it keeps states. So, let's say our Taraffin code fails. Maybe because like AWS which happened with us, like they wanted to spawn 400 instances once. Now we won't have that much money. We don't even know why they didn't. And we suddenly saw it fail. So at that point of time, go fix the problem or destroy whatever infrastructure we have created because it keeps, like it don't go and don't impact everything. Test on stage before production. Just test locally or like somewhere so that you are sure your code is working as expected. Jentin is the one people who will apply because we won't want anyone to go create infrastructure for us. One easy way is to have your own access key which has permission to run this code and put it on Jentin's or like some way by environment. And don't let anyone else re-app those kind of questions. Do small and critical changes because you don't want to write a lot of code and then you realize there is no tournament. So, like I told you on your instances they are costly. So we don't know what instance or they are very cheap. Like they are like one fifth of the cost and then they are much cheaper than that. Yeah, so just to give me an idea use Jenkins so we can provide custom scripts like which can be downloaded on the instance. You can provide time like after which you want to run your code because you quite want developer or tester to be ready so that they can go to a tournament and like see. We can use old instances like old instances that created from some other Jentin jobs.  So, for now we may keep it normal so that like tester have the capability that they want to go and fetch some information from like those clients and then these are custom parameters which extra data we want to use on our server. So, we send all these information to our final stress inspector and set it up with our planning and then after like specified time we start running them too. So, in case of jpentry we use their own internal client server order, but for our own custom scripts we have our own custom code which is the type. So, this is just a sample of like instance in this case it is only 15, but we at times went 400 to 100 depending on like how much we will go and the analysis is an example of neural link dashboard where we are actually seeing like what is there on the dashboard. So, yeah we have our Terraform code so it asked me so every time it runs it ask for a client, but you can force it. So, when they are running it on Jenkins we do not want anyone to actually go and manage the ideas and all those information. So, we forced it. So, every time like code is run it is actually forced. And one of the reason for that because we know that this code is performing as it is. So, now what Quotitini does is to create these things and we can actually go and see what are our inputs currently generated to generate it. So, I created a VPC internet because I want to come up with some that routing cable and all those. Yeah. So, in this case one is on demand instance one is spot instance. So, if you go and see spot request we already generated a spot request. So, in case of spot yeah. So, we already requested a spot instance which we got and we provided the maximum price same as that of on demand price. So, in the worst case like we get this spot request because now pricing it and it will suddenly handle the cost. So, yeah once it is done like still waiting for the consensual reply. Now I can show you the state file it has it is more like a replica of real world like whatever we are actually seeing. And once I am done I can destroy it. So, everything is automated you can go to this data thing and take the code and try it yourself it already have like on use and also if you reuse it slides are available at this lecture if you have anything I have put anyone have any questions. Yeah. So, Jmeter is running so, in Jmeter we have a like server client model we run it from Jenkins it is a machine itself. But we can have a separate machine also. So, it is more like just now we will do a server client model before that you are running like directly copy code on all the instances and running client there. Because we were not seeing the Jmeter response, we were initially seeing unique response which is actually government dashboard. But now to get better understanding we started doing it on from like Jenkins machine itself who actually connect to all the instances and running client there and so that we get the data. So, that is currently transitioning to a better system where we have like if something fails we can see that in single place. What are they doing actually? So, what happens is when they are running the Jmeter instance SSH can get copied on all the machine. Now that instance has actual SSH access on all the machines. It goes there you SSH copies file because we have given generic you are also more like you can use your own box you are using some other S3 world. It downloads that file from there on the complete setup which we already done in script. Like you can use ensemble or you can even use telephone like provisioning everything. It does a complete setup. Now after like with the help of KT2 we actually go and run everything after like T time and then like actually you got what you want to do. Yes. Okay. So, I am going to use cloud formation now because you know I started with Terraform it's super easy to use but the major difference which I have come right about is Terraform keeps so when if something fails on cloud formation it holds it goes to 0 state but what Terraform does it keeps the state where it is. So, you need to actually go fix that code in a priority and it keeps a real world copy so even if you go on your influence line to do something like you go and delete half of the instances and then the next time you run them like it try to map both the things or like if you removed something from the code because Terraform mode is also versioned but yeah I don't have like in that detail about cloud formation but provisioning infrastructure. If anyone have any question I think I have Praveen like he is my colleague so you can ask him or me. Thanks. Thank you Mithish. I have this track here but if you are interested in lightning talks or any other tracks you can go to main auditorium you can propose your lightning talk over there and this is opportunity you can grab it. Thanks all for coming in general.


What's up everybody? JC for jacobyscasebreak.com 1920 panini mosaic solo one pack break number 23 random teams just sold out This is to help fill up Pikachu number 7 of NT basketball where we have a 15 team random number block That's $600 a spot So you're paying a fraction of the price of $60 spot to get a spot in there and we're giving away three random number block spots So the way this works guys We're gonna randomize because we're names and teams distribute the hits out of this pack break and I just remember No, veteran base commons will ship in that and then of course at the end of the break We'll get a new dice roller randomizer for the 30 customer names that bought in and top three numbers one two and three We'll win a spot each in the $600 15 team team random or sorry random number block for Pikachu number seven of NT basketball So let's do the break first Let's roll it And we got a three to two five times. Good luck Team's a name source or teams and customer customer names and teams first two three four build a five five Robert done a Joshua one two three four five Blazers done the Sacramento Kings Robert the blazers down with the nice Josh with the wizards Eric with the bucks got the heat Mike with the Hornets Robert With the Grizzlies Mike with the Clippers Robert with the Jazz Zach with the T-wolves Mike with the Nuggets Stephen K Have the pelicans that Paul you got the magic Anthony of the Mavericks Eric with the cows Ryan with the Knicks Josh with the Suns Anthony the Lakers Robert with 76ers Ryan with the Pistons Robert the Pacers Right with the Thunder down with the Rockets Mike with the oars Eric with the Spurs David with the Hawks as well as the Raptors Robert the Celtics Mike with the Bulls in Joshua with the Kings There you go all right guys, so I'm just gonna close the trade window of course and Let's print and rip this one pack break and then of course in a separate dice for a randomizer Let's give away some spots in the team rather number blocks Also, okay, you never know man, I did a blaster box yesterday and I hit a Zion hollow And I don't think Matthew was expecting it. So I know it's only four packs or three packs Maybe you get a Zion silver or something. All the fame Oscar Robinson silver And It's Agnes Holford wrong rookie Stephen K. God damn it. Sorry about that man. All right, there you go Big sell up up, but just have a chance to get some spots in the R&B That's a good thing. Let's go guys Top three get a spot in the R&B Roll it six and a five eleven times. Good luck one two three four five six seven eight nine ten Eleven times Ryan Stephen K and Ryan. Wow, there you go 11 times and what do you know Stephen K last bomb module strike the game? 11 times So Ryan Stephen K and Ryan congratulations guys Both of you are in the break. Although Ryan got two spots I couldn't say three of you both of you are in the break now And they went to fill up one more mosaic cell which is on the website and still at 30 left And that will pretty much unlock picker team number seven Appreciate you guys. Jasper's case for example


And welcome to day two of Google I.O. My name is Zach Cook, and I'm a product manager on the Chrome team leading our web payments effort. A special thank you for coming out and joining me at 8.30 AM, which is very early. And of course, a special thank you and welcome to everyone on the livestream, as well as anyone that's watching on YouTube later. I'm really happy to be up here today talking to you all today about how we think about the future of web payments and how we're trying to really help users, both our users and your users, your customers, have pain-free checkout experiences on the web. But I thought I'd get started by giving a refresher on why we care about this space at all. I think it stems from the fact that the web is better than ever. You've probably heard it over and over again from Rahul's keynote to all of our web track sessions that the web is really amazing these days. You can build fast, rich, app-like experiences and they're really compelling. And that line between what is web and what is app is more blurry than it's ever been. And we think this is an incredible opportunity. And things like WebGL and Polymer and service workers all have these are all tools that can help you create these incredible experiences. I think personally my favorite example of how far the web has come is the fact that you can literally circumnavigate the entirety of the Earth's surface directly inside of a browser tab these days. So this is Google Earth running inside of Chrome and to me it just kind of blows my mind that you can do this on the web. If you don't recognize this, this is actually where we are right now with that shoreline amphitheater which is the beautiful white tent where all the keynotes are and then of course we're in the back parking lot. But it's a very nice parking lot. So really incredible stuff. But when you look at all this amazing progress there's one area that seems obviously behind and that's the way we buy things online because despite all of this great progress this is still what most checkout flows look like. It's the same questions, the same form fields, the same multi-step process. It's like for all this great innovation we're still stuck here. And I suspect this is very similar to the way checkout forms first worked when they launched. In preparation for this talk I did a little bit of research and I discovered that the first online transaction was made in 1984 in someone's home by a 72 year old woman named Mrs. Snowflake which I think is just an incredible piece of fairly worthless trivia. But I think that very little has changed in those years even though it's 2017. And I think the stats reflect that we need some change here. Long checkouts continue to be one of the leading causes of card abandonment out there. And it makes sense. Here's a question for you. Has anyone in here on a mobile device ever abandoned a transaction because the process was too long or cumbersome? You can raise your hand. Oh my God, that's way higher than the stat by the way. So that's amazing. And me too.  Maybe I do, maybe I don't. The point is that there's a lost opportunity to give users a really great experience here and to convert at that moment. So we're quit literally losing money. Despite these challenges though, mobile commerce is huge. I mean, mobile commerce in the US alone this year is expected to exceed $150 billion. That's all the more impressive when you consider the fact that mobile websites still convert about a third lower than their desktop or laptop counterparts. So we have a lot of work to do and a huge opportunity here to really better the lives of our users. And so every good platform out there, whether it's apps or the web, needs a good payment solution to succeed. And so it became obvious to us that the web needs a better answer for payments. And that's what I'm here to talk to you today about today. And in that sense, I actually have really good news. It already exists. Last year at Google I.O., a couple of my colleagues were up on stage and they announced that we were working on this new API called Payment Request. Well, I'm happy to report that not only did we say we were going to launch it, we actually launched Payment Request in September of last year. So what is Payment Request? It's an open, built into the web, designed to be fast and secure, ready to be used today, API for transacting on the web platform. We're gonna be talking about all of these different components throughout our talk today and I'm really excited to just dive right into it. But first I should clarify something. Payment Request is not a processor. We're not trying to make the browser a processor or a gateway or another new entity in the system to move money from point A to point B. We think the industry has already done a great job of actually filling this service. Great players like Stripe and Braintree and Vantive and we love the work that they're doing. No, we're focused on users. We're focusing on taking that user experience that seems stuck in legacy mode and moving it out of that into a much more faster streamlined experience. So we thought about designing the Payment Request API. We had two goals, I think, primarily in mind. The first is that transactions on the web should be seamless and we have to start with the status quo. So we have to take the existing world, oftentimes the world of credit cards, CVCs, billing addresses, all those complicated things from a UX perspective and we have to make them better. The second thing is we have to think about security and how we can improve that and I don't just mean things like HTTPS because of course we should always have HTTPS everywhere. We're big advocates of that. But I mean we should be forward looking and say how can we bring more secure forms of payment like tokenization directly into the web platform? So how can we unlock opportunities for players like Android Pay and Samsung Pay and future tokenization technologies to have a home directly in the web platform? So high quality secure payments become first class citizens of the web platform. Now I could talk about this all day long but I'm gonna just go ahead and jump to a demo and show you what this all looks like. All right, so it's gonna jump over to the wolf vision here, all right. So as I mentioned, payment request is alive and ready today. So you don't have to wait to start implementing and we actually have a number of really great merchants implementing one of which is Kogan.com. It's a little blurry, but hopefully you guys can get the idea. Kogan is Australia's largest retail company and they've implemented payment request and it just so happens that Chrome also has an office in Sydney. Now I've never been there but I'm gonna operate under the assumption that one day they will let me go to Sydney and I'm gonna give myself a gift on arrival that will be waiting at the Google office for me. And so I'm gonna buy something that everyone I think needs, of course, USB-C adapters, super common. So I'm gonna add this to my cart and it's now added to my cart as you can see and I'm gonna hit the checkout button. And so you see here like this, the sort of standard thing happens. I'm on Kogan.com. The shopping cart loads up. I've got my list of items I'm about to purchase. I have delivery estimates and I hit the checkout button. And here's payment request in action. So instead of going to the traditional checkout flow at this point, a payment request sheet slides up directly from the bottom. We've got the merchant name, their HTTPS URL with a lock icon. We've got the Chrome logo in the bottom left so users are aware of where this data is coming from as well as a bunch of other information as you can see. So first you see we have a total amount of money being requested. So you see right now, it's Australian dollars for five dollars and you see that I already have a Visa credit card default selected there. And the only thing I have to do is choose a shipping address. This makes sense because of course it's a physical good so we have to ship it somewhere. So I'm gonna tap on and choose and you see here that payment requests already knows my most frequently used addresses. So you see the first one there, my number one is my main office in our San Francisco headquarters. And then the second one actually is our Sydney office. What this tells you is this is not the first time I practiced this demo. So Chrome has stored and saved my address here. So I then tap on this address. And what's happening when I tap on that is we take that address and we send it behind the scenes to the merchant so they can then use that address to dynamically populate the set of available shipping options. So you'll see they default selected free shipping for me but if I tap on that, I can also select express shipping. Now in this case, I have no idea when I'm gonna go to Sydney and pick up my little converter here. So I think standard shipping will be fine for me. And then I hit the pay button. And you'll see the only thing that I have to do is input a CVC. Now because this is a live transaction and something should be kept secret from the world, I am not going to show my CVC number to everyone. But you can trust that I just typed it in and now the transaction is running behind the scenes. We've taken that data, we bundled it all up and we've sent it behind the scenes to Kogan. And as you can see, the transaction is successful. Yay, I love when demos go well. So that's amazing. What, thanks. I think what's really cool about this is that I didn't have to type in anything except for my CVC. We had all my data stored. It was all ready to go. All I had to do was confirm it, off it, and get it over. So that's the kind of seamlessness that we're talking about bringing to the web. Now, I know that we are really focused this year on the mobile web track. But the reality is that, oh, we need to ship back into demo mode because we still have, there we go, perfect. Again, we've been on the mobile web track and that's the big focus for us at IO. But we all know that users still love buying things on their desktops and on their laptops. And we thought that we should bring the same great experience into these platforms. So here you see, I have a shop loaded up on my Mac and Windows, or sorry, Chrome running on my Mac. And I'm gonna tap the buy now button. And as you can see, a new payment sheet, optimized for the desktop experience comes down from the top. And what's great here is you'll see that my same information is available. So I choose an address. You'll see it's got my same addresses that you saw on my mobile device because I'm signed in and all that data is sinking across all of my instances of Chrome. In this case, I'm just gonna ship to our Spear Street office. You see that methods are still dynamically calculated. So we offer free shipping inside of California. But you can see, just as a demo, if I do decide to ship somewhere else, shipping dynamically changes to $10. And in this case, my 8605 visa is also there present, the card I just used to make that last transaction. But in this case, since I can't hide the screen, I added a test card that I'm gonna go ahead and use to facilitate payment. So I do the same thing, tap on pay, insert my three digit CBC, hit the confirm button, and the same thing happens. So your order has been successfully placed. So really great, and I'm really excited to say that we are bringing payment requests to all Chrome platforms very soon. So really nice. So we can pop back over to Slides. Can we pop back over to Slides? I feel like we'll get there. Excellent. Okay, so now you've seen payment requests in action. I wanna help you understand a little bit how it works. Now, I won't go into too much depth here because we already have a lot of great resources, but I wanna give you the core idea of how this whole process works. A payment request is a JavaScript API, of course. It's built and baked into the web platform to create these experiences. This is what you saw there. All was natively Chrome-rendered UI. And the first thing you have to do when you wanna create a payment request is you have to tell us how you can get paid. We call these supported methods. And there's two types of supported methods that exist inside a payment request. The first one are things that are baked into the standard. In this case, we have something called basic card. Basic card is a great fallback mechanism, and it's your way of telling the browser, hey, if it looks and feels and functions like a piece of plastic in someone's wallet, it probably maps to basic card. So it's your way of saying, I accept any of these forms of payment. I don't show it here, but there are ways to get more nuance in this as well. You can say, I only accept debit cards or I only accept credit cards from these three networks. Oh, that's totally possible. The second thing you can pass in are supported methods that we call proprietary methods. These are identified by URLs. And in this case, for example, if you wanted to leverage the great new stuff that the payments team announced yesterday around Google Payments, this is how you tell the browser that, hey, I support any of those Google payment methods. And so there's a proprietary system built in here so that every entity in the payment space can actually participate freely in the payment request ecosystem. It's the job of the browser to look at the ways a merchant can get paid and the way that a user can pay you and match those automatically. And that's what allows us to offer that great rich experience where things are default selected. So all I have to do is confirm and pay. The second thing I have to pass in are details of the transaction itself. There's only two required things here. You have to pass in a label, like purchase amount, for example, and you have to pass in an amount of money that you're looking to get paid on. In that sense, there's a currency code. This could be US dollars or, as you saw on our demo, Australian dollars and a value. And we use that to render the appropriate amount on the screen. You can also pass in an optional set of display items. These are things that show up that basically inform the user about how that total amount of money was reached. These are totally optional, but we really recommend them because it helps the user explain how that total amount of money was reached, things like subtotal, taxes, shipping costs, et cetera. And the final thing you can pass into payment request is your completely optional set of additional information you might need to complete your transaction. So when we saw the Kogan demo, you saw that what they had done was they requested shipping true. This basically tells the browser, hey, if you have addresses stored, leverage those so the user can select them.  So when I tap an address, we take that address, we bundle it, send it to the merchant so they can dynamically calculate shipping options and there's a way in the API to then update us on the set of available options. So it makes a really robust, rich experience. You see, you can also request things like email, phone, and name. Email, for example, was also in the Kogan demo because that's utilized for a new customer like me who had never purchased to be able to send an email transaction receipt. Again, all these are entirely optional. The only thing you have to have in a payment request is an amount of money and a way that you can get paid, at least one way to get paid. Something that we, oh, and now you have to put it all together, of course. So quite simple, you just construct a payment request so you pass in those three components that we just talked about. And then whenever you're ready to actually show that payment sheet, you call .show. And .show is the function that says, hey, actually slide up that payment sheet and facilitate payment. At that point, that returns back a JavaScript promise and you're just gonna wait. And at some point, you're gonna get back a payment response. And that payment response is just a JSON object that contains all of the data that you requested and that you need to facilitate the transaction. So if it's a credit card, you're gonna get things like card number, name, billing address, even a CVC to run it through. If it's a proprietary form of payment, you get all of the data for that particular form of payment. So Android Pay is also supported on this. So if you got an Android Pay response, you would be able to parse that response and pull out that tokenized form of payment and send it off directly to your payment processor.  And that's your way of telling the browser, hey, I'm finished with this transaction, go ahead and close that payment sheet. That then also returns back a promise that will resolve when that payment sheet is completely closed down. And that way, if you have great UI, bits that you wanna flip or whatever, you can do that all seamlessly without the closing of our animation. And that's it. As much as it takes to actually get that great experience, we just showed on kogan.com. Now there's one other API I want to mention, or one method, which is Can Make Payment. Can Make Payment is an API that allows you to ask payment requests if the user has a form of payment already active and ready to go before calling.show. So if the user doesn't have anything set up, you'll get back false. If they have something set up, you'll get true. We think that this API, along with that set of optional information at the end there, that third component, allow payment requests to be really flexible and they can work into all of your different flows. And so it's really nice to be able to, you can just use it as simply as a payment mechanism just for a credit card, or it can facilitate the entire transaction flow, including shipping address and names and emails and phone numbers. And we have merchant shipping, all different variations of this. Now as I mentioned, one thing that we're really happy to announce today is that we are coming to every single Chrome platform. We announced Android last year and now we're happy to announce that it's coming everywhere. That's Android, Linux, Windows, Chrome OS, Mac, as well as even Chrome for iOS. And so for users that are synced, all of that data is stored and synced across all your devices. So the minute I sign in from one to another, all that data is there and ready to go. There's a theme here with payment requests, which is let the browser help you. We've got this data stored. Our users trust us to store it. What we want to do is share it with you. All we need is user consent to do so. So in some sense, think of payment requests as a way for a user to grant consent to share this data with you seamlessly and easily. Now something else I'm excited to announce is that we also have support for all Google forms of payment built right in. So if you went to the keynote yesterday with Shridhar and Polly, you saw that we're building this great new payment experience where all of your forms of payment in Google are grouped under a single application. All this is going to be built and seamlessly work inside of Chrome and with payment requests, where most of the heavy lifting is actually done by us. So you'll pass in that google.com slash pay identifier and you're going to get all the benefits of the Google payment ecosystem built right in and access to those hundreds of millions of fobs, which we think is really compelling. And as you can see, it's a really nice experience built directly into Chrome. Something else that I think is also incredible is the fact that payment requests now also work seamlessly with AMP. So if you're not familiar, AMP are accelerated mobile pages. They're basically incredibly fast loading pages that load virtually instantaneously. So in this GIF on the right hand side, you'll see a live example of this working on one of our partner sites, portero.com. You'll see that it all starts from a search. You search, you tap on a result and that page loads basically instantly. So user can very quickly go from searching to seeing the entire product information. They then tap that buy button directly on the product page and the payment request sheet slides up. All the information is there. You're ready to transact. So the entire experience from front to back can be done in like less than a minute. It's really amazing. AMP has seen incredible success. And so if you haven't yet looked into AMP for your product pages, I would encourage you to check it out. And if you have AMPed your product pages, I would really encourage you to look into leveraging payment requests to just facilitate that transaction right there on the page. Now, I know I'm talking about a lot of Google here, Google Chrome, AMP, which is an open standard, Google Payments. But one thing that is really great today to be able to announce is that this API is a cross-browser API. We talked about openness, right? And openness means that it should work everywhere. And so this is really great. Edge has launched. Samsung Internet has launched. Chrome has launched. And Firefox is in development and launching soon. So we've seen a lot of movement in the industry, which we think is really incredible. Woo. Yeah. Thanks. I think this tells you that there's a commitment in the industry to solve this problem and to really make web payments compelling and to give users on every platform independent of their browser choice a great checkout experience. And so it's been great working with all these players inside of the W3C. And of course, as I mentioned, this is available now. This isn't just vaporware. It's not something that we're launching soon. No, payment requests exist. And we already have a number of great merchants literally around the globe shipping integrations. So you've got Wego. You may have heard already. They're based in Southeast Asia. We've got Kogan in Australia, JD Sports Nivea, players from Europe. We're really excited and thankful to all these early partners. And these are just some of the merchants that are shipping payment request integrations right now. We also recognize that we want to bring, well, not recognize, we want to bring the benefits of payment requests and seamless transactions, though, to all merchants independent of size. And one way to get that reach is to work with these great channel partners, people like WompMobile, who you saw in the AMP demo, WooCommerce, BigCommerce, Mobify, Weebly, Shopify. By working on these guys and building payment request integrations right in, we can bring these benefits directly to all merchants, even those in the long tail. Because everyone should be able to give their users stellar experiences. And so we've been really happy to work with all these great guys. Now, I realize that this can be overwhelming and that checkout flows are complicated. You're like, Zach, this all sounds great, but you have not seen my checkout flow. I've got guest checkout flows. I've got registration. I've got sign-in. I've got coupon codes. I've got all this stuff. And I realize that it's a big ask to go from not using this new thing to leveraging this new thing. So I want to throw out a potential place to consider getting started. And it starts with a challenge. And the question is to go back and ask yourself, what percentage of your transactions, especially on mobile, have only one item in the cart at checkout? So go back, run your numbers, and figure out what percent of transactions have only one item in the cart at checkout. And again, focus on mobile. I think you'll be surprised at how high it is. We ask this question to our partners all the time, because we're curious. And it's always higher than what we expect. But we've been amazed to see that it's up to 80% sometimes of checkouts that only contain a single product. But if that's the case, why are we still stuck to a legacy system? It's like, the way we walk into a physical store is I grab my cart. I walk down the aisle, I add items into my cart, and then I go up to the front, and I check it out, and stuff like that. And that's the whole process. And then we brought e-commerce into the world. And we thought, eh, we'll stick with the same model. We're going to go ahead and have virtual aisles. And the user will have a virtual shopping cart. And they're going to walk the aisles and add items in. And then they're going to click on that shopping cart to review and check out. And then our form factor's got smaller. And we're like, ah, we'll keep the same model.  And so the flow ends up looking like for up to 80% sometimes of your users are on a product page. They're having to tap on the product, add it to cart, go find the cart, click on the cart button, review the cart, and hit the checkout process. And you just think, man, maybe we can optimize this. And so here is my recommendation or something you should consider to get started, which is consider a payment request as a buy now button that you can add directly to your product pages. It's a way to pretty simply get started. You can leverage tools like Can Make Payment and Request Shipping and Request Email Address to facilitate that entire transaction right there on the product page. So just as an experiment and see how it performs, I think it's worth giving users, especially those that only want to make a single fast purchase, the option to do so. And again, with all the tools like Can Make Payment, you can do so in a way where you can have full control over the system. So they don't have a seamless experience built in. That's fine. Skip it and go to your legacy flow. But we think there is a really great opportunity here to have an impact and drive up conversions. And then later, if this proves successful, you can consider how to leverage payment requests in your default checkout flow as well. Now, we've talked from the very beginning about openness. And when we first announced payment requests, we said that it was never about just making Google forms of payment easier. Although, of course, we care about that. But it's recognizing that for a true openness means that everyone should be able to participate in the ecosystem. And so one of the things that we're really, really happy to announce today that we've been working on for a long time is that we're officially opening up payment requests so that third-party payment application providers can participate directly in the ecosystem and show up in that exact payment request sheet. Because the reality is that the web is global and payments are global. And if we want to have global scope, we have to open it up so that everyone can participate freely. And we think this is really great. But to talk a little bit more about this, I want to invite up a couple of my colleagues from the W3C's Web Payments Working Group who we've been working on this with. From Alipay and Alibaba, let me welcome to the stage Max and Jaja to talk a little bit more about this. Hello, everyone. I'm Max, and I lead the International Centers work for the Alibaba Group. Hello, everybody. I'm Jaja. I'm a senior engineer from Alipay, which is a company of any financial source group. Before getting started, let me see a quick show of hands. How many of you have ever heard of Alipay? Whoa. OK. So how many of you have ever used Alipay to make a transaction? Oh, not bad. So mobile payments are very popular in China. For example, Alipay is used for online shopping, taking taxes as supermarkets and lots more. And we can use fingerprint, face detection, and other biometric authentication methods. It's very secure and convenient. Alipay is not only popular in China, it's also a global brand. When we were considering to bring Alipay into the global market, we found that mobile web is the popular venue for people doing online shopping. We wanted to bring the good user experience of native Alipay directly into the web ecosystem. And we see that the Payment Request API standard is the best way to do this. We joined W3C and the Web Payment Working Group to work with Google to make sure that the Payment Request API standard can also support native payment app. So updating your native Android app to run instead of Payment Request API actually is quite simple. You just need to add your Android Manifest XML file to response to the payment intent. And add metadata which specifies your payment master's name. For example, for Alipay is alipay.com slash WebPay. Your payment app will then receive the payment request through this intent and should reply with the correct response for your particular application. But as you can imagine, in working native payment app from browsers has security challenges. For example, if there is a phishing attack and a fixed Alipay installed on user's phone, we don't want the browser to open up that fixed app. So how do we prevent this in the standard? So also, let's see a couple of manifest files located on the payment provider's website. This can contain a variety of useful information used to verify the authenticity of the payment app. The first is what we call the payment method manifest file. This is downloaded by the browser using the payment method identifier information, which for us is alipay.com slash WebPay. The browser does this by issuing an HTTP link header request, which points to the location of the payment method manifest file on alipay.com. Instead of this payment method manifest, we can then define the location of our second manifest, the web app manifest. This is where we define the information about our application itself, including the package name and the fingerprint information. What is important is that only alipay has control over this manifest file. And when the browser tries to invoke payment app, it will first download this manifest file and verify the signatures match. Let's look at the demo and see how this works. So all the demo is real. So in the first demo, the merchants support multiple payment methods. And when the user clicks buy button, alipay can show up as one available payment method. And if the user selects alipay, the native alipay app will be opened up, and the user can use their fingerprint to do the authentication. It's very convenient and secure. So in the next demo, the merchant only supports alipay. So the merchant can even show a pay with alipay button. And with just one click and within several seconds, the payment could be finished. It's very convenient. And I think that will help you to spend your money more easier. Cool. So we are currently working hard with Chrome team to bring this feature into production. So if you are a developer, you can use this feature in Chrome, in alipay, in UC web, and hopefully in more browsers in the near future. Alipay is a world-leading third-party payment platform. We have supported more than 18 currencies, including USD, Hong Kong dollar, URL, Palm, Japanese yen, and so on. We are continually improving user experience and security, so technology, innovation, and implementing industrial standards. Welcome to the joint payment ecosystem. Thanks for being here. Thank you. Awesome. Thanks, you, Max. And thank you, Jia Jia. I think it's really exciting to see an industry like this evolve, and we're really happy to be a part of it and really pushing for openness on the web. As they mentioned, I'll just quickly recap. There are just three actually steps to get started integrating your application today. One, you'll define your identifier. For google.com slash pay, that's what it is. For alipay, it's alipay.com slash web pay. Secondly, you'll make a few updates to your manifest file in your Android app, as well as some functions to handle those things. And then finally, you'll set up some manifest on your web server, so you can be confident that Chrome is opening the right application. So really simple, really great. And I'm happy to announce that we're already working with some really great partners. So you'll expect to see Samsung Pay coming into Chrome, Alipay, as you saw just in the demo, as well as SquareCache, and a number of others. So I think you're going to see a lot of evolution in this space over the next three to six months. Now, I recognize there's a bit of irony here, which is that we are on the web track, talking about how great the web is, and how amazing it is. And then I'm up here saying, our first integration is with native Android apps. This is for a couple of reasons. One is because we do think that there are great experiences that can be built with native applications. You get access to things like fingerprints, so you can have biometric authentication, and it makes great experiences. The second thing is just a little bit easier to get started. But I have great news, which is that we are actively working on pure web app support. So you get all the benefits of the web, like no installation, immediate availability, and global reach. And so web apps can be full first-class citizens inside of the payment request system. We think this is actually really compelling. We recognize that users love to pay with certain brands, but don't necessarily have those apps installed. That's OK, and we're fully working and committed to bringing that support. And today, I'm excited to announce that we are working with PayPal to actually build out this experience and bring PayPal's web app directly into the payment request experience. So look forward to sharing more about that over the next few months. Now, again, we talked about a lot today. There's a lot of code samples, a lot of overviews. So we have a lot of great integration guides that are out there that you can reference. We've got payment request guides. We've got how you can get started integrating your Android payment application. And we also have a great code lab that you can run through, which will help you get familiar with the payment request system. So I encourage you to check those out. As well as after this, we do have a mobile web tent, which is just around the corner out this door to the left. So I would encourage you to stop by, say hello, see some of these things in action, and ask the hard questions. So thank you so much, everyone. It's been a pleasure to be up here today. Hope to talk to you afterwards.


Kellyanne Conway has coined the term alternative facts, which has brought a lot of controversy to U.S. politics. I'm Pauline Jing and I'm here at Revolution Books in Berkeley to hear their perspective on the topic and where they believe the country is coming. So Revolution Books was founded upon the idea of New Communism. Can you briefly tell us what that is and how that can affect the future? Sure. Well, New Communism is sort of like what Marx did in his day only for now. It's a whole theory and methodology of how humanity can advance beyond capitalism to a whole world where we transcend wars in nations and the oppression and domination of one gender by another and one nationality by another. This is possible. It's based on a scientific understanding of reality. And it's something that, you know, Bob Vakian who developed this has laid a pathway where we can follow it. So this is at the heart of our story. A big part of what's going on right now is that the Trump regime is a fascist regime. And they're implementing it all with their hammering in the place as best they can. Though there's been very powerful opposition, nonetheless they continue to hammer into place a fascist program of social transformation, moving beyond the rule of law. You listen to their Trump spokespeople. It's like, you know, the courts have no right to question what the president does in the realm of national security. For example, Trump is 100% right. We played that film, right?  But this is part of the problem which also points to the danger that we face. Because, for example, a small thing, how many people attended the inaugural? Trump claims the biggest inaugural in all of history anywhere in the world. Complete nonsense. There's pictures that show that that's not even close to the... He persists. This is what Hitler did. And this is what fascists in general do, which is people are more sort of in resistance, but they're not seeking to oust the regime. They don't understand the need to oust the regime. They don't understand it's a fascist regime in a full sense and draw the conclusions from that. And that's what we choose fascism as working on. How to develop that understanding and help develop the kinds of organization that can actually lead people to confront the regime and force it out. And as the circumstances develop. Thank you so much for joining us. I'm Paulina Ching and this is CalTV News.


All right, so much football on today's show, but it's time to talk some cricket now. Jamaica have one hand on the cricket West Indies Super 50 Cup, after remaining undefeated following the penultimate round of fixtures, which concluded earlier on Monday. All 16s were in action, and here's a look at all the results from the three matches. Where do we start? We start with Jamaica taking on the Wynwood Islands, Jamaica winning this one by three wickets. The Wynwoods 175 for nine. This match was reduced to 45 overs per side, Pearl Etienne top scored with 58, Janelia Glasgow got 38, Chanel Henry career best figure 6 for 31, Vanessa Watts 1 for 22, and Jamaica in reply. They were cruising at one stage 176 for 70s where they finished 36.1 overs, Rashad of Williams with 72, Natasha McLean got a run of all 50, and Gilbert 2 for 40, the pick of the Wynwood Islands bowlers. So maximum points there for the Jamaicans as they take their fourth victory from as many matches. The Leewood Islands and Barbados, this was a very good match, a high scoring one. The Leewood Islands 255 for five from their 50 overs, Hector with 56, Amanda Edwards with 55, and in reply Barbados 256 for five, Kaishona Knight getting 88, it was quite a fabulous knock. Aliah Elaine scored 59, 2 for 48 for Sharnisha Hector falling for the Leewood Islands. Barbados getting victory by five wickets, and in the days of the game Trinidad and Tobago versus Ghana, Ghana batting first 156 for eight from their 50 overs. This was at Connery, Chamain Campbell, the West Indies mid-loader batter getting 52, Shabika Ghaznabi 33, Kirishma Ramrak again among the wickets for the TNT team 3-4-26, Leanne Kirby 2 for 24, and Trinidad and Tobago in reply, bowled out for 95 in just 42 overs, a fourth straight defeat for Trinidad and Tobago, and Ghana getting their third victory now. Samar Ramnath top scored with 24, Trinidad and Tobago, Manasar 5 for 15 for Ghana, and Lachman 2 for 24, a 61 run victory for Ghana in that encounter. And yeah, Lance and Mariah, this women's super 50 cup, we've seen some good cricket, we've seen some bad cricket, we've seen some indifferent cricket, today I thought was one of the better days for the tournament, I thought I saw a lot of quality cricket and a number of the batters came to the party as well, high scoring game Barbados versus the Leewood Islands, Natasha McLean getting a half century, Rashana Williams getting a half century and victory for Jamaica as the Jamaicans close in on the title. Yeah, I have to say I have been really impressed with what I've seen from the Jamaican woman cricketers, to be very honest they've been great both with the bat and the ball also on the field, they've really come together as a unit and I think that is the reason why we're speaking about them being undefeated so far with the leadership of Stephanie Taylor who she also has contributed with both bat and of course with the ball, we had Shadeen Nation coming to the party, they had Rashada Williams stepping up when necessary, today I was also very very happy to see Natasha McLean, she is somebody that has shown a lot of promise and of course she's been inconsistent and I'm happy to see her back today getting that half century and I'm hoping that we can see more of that from her not to forget Chanel Henry, she is a player that I have the opportunity to of course speak to a bit more because she and my sister Karishma, they are really good friends and you know whenever they're in West Indies camp and stuff I'd have a quick word or two with Chanel, to me I feel really really good to see how she has grown as a player from when she started to now and to the point where Chanel now is a person that you will expect to come to the party a match winner and for me you know the Jamaican team really really well deserved, Barbados as well, Barbados as well they have been really good in this competition even without Haley Matthews and I think that is something that should be commended because many people felt as if Barbados would have been a push-over seeing that their skipper Haley Matthews was not so Kudos to Kaysia Knight and her entire team for of course really playing competitive cricket now whether Trinidad and Tobago Red Force is concerned I am so disappointed I have to say I'm disappointed with the batting performances of the ladies because I felt as if even when the bowlers came to the party there was never a good competitive score for Trinidad and Tobago and to me it's something that they would have to go back now and talk about as a team and see how they can improve they are youngsters that can be promising in the future but as of now they have to work on that. Lance? Yeah I agree with you the 0-1-4 record that the TNT team has put on the board at the moment is for me the most surprising development in this women's Super 50 tournament because they have been for a long time one of the best teams in regional women's cricket and their feeder program has appeared to be better than most you know young teenagers getting into their their team and doing well so I think this was completely unexpected to lose all four of their games so far the TNT team so hugely disappointing for them I quite like the advances that the windwards have made and a lot of their mid-lord of players Pearl Etienne, Janelia Glasgow, Nerissa Crafton getting a lot of runs consistently through the tournament so I and they gave Jamaica a really big run for the money today so I like the fact that the windwards have shown some improvement because for many years the women's cricket in the Caribbean has been dominated by Barbados, Jamaica and Trinidad and Tobago they have been perennial champions shared over that period of time so when you see Ghana beginning to improve and the windwards showing marked improvement obviously the Leavers have a lot of work to do although they were outstanding today against the Jamaican team and when it was the Barbados team that they played against today 255 they scored against Barbados Barbados have West Indies bowlers in their setup so and they were unfortunate because there was a runout that wasn't given a Barbados batter was run out if you look back at the replay that she was run out but the umpires didn't didn't see it that way so the Leavers would be disappointed with that but hugely impressed with how the Leavers played today against Barbados because scoring 255 against the Barbados team for the Leavers would have been something that was hard to anticipate yeah and of course when you look at the table Jamaica will play Ghana in their final match on Wednesday and based on how things look we haven't gotten the updated table yet but I suspect that Ghana will need to win that match with bonus points to leap from the Jamaican so Jamaica very very close to lifting the title and a significant difference from what we saw last year because last timeouts to Farnay Taylor didn't complete the tournament but they got just two wins they were second from bottom in the table so a lot of improvement made on the part of the Jamaicans and the top players have come to the party Stafany Taylor Shadeen Nation, Chanel Henry we saw today Rashadah Williams we saw today Natasha McLean the players with West Indies experience showing their quality in regional cricket and that's what you want to see ideally I would love to see some more of the younger players not just on the Jamaica team but across the board coming to the party in this tournament but you have to give credit to those who have they have utilized their experience and they have really done well I'm a big fan of Chanel Henry by the way Lancet Moran I think I said this last year that I think she is the type of player who is the future of West Indies cricket because of her all-round athletic ability she's able to hit the ball she can ball well and she is a very good fielder and I think and I have to be careful how I say this but I think over time a lot of the women who have played for the West Indies have not been athletic enough and I think for West Indies women's cricket to move forward in the way that we wanted to you need more athletic women and for me Chanel Henry is one of those and because she has the ability to do everything well on a cricket field then I think that she is really a massive part of the future of West Indies women's cricket yeah the athleticism is something that is important Ricardo you just mentioned it because I've said for many years on this this show a part of the Australian strength apart from their technical quality is their physical fitness and the athleticism in the Australian team I saw those girls when they were on tour in Barbados about six years or so ago I was staying at the Acro hotel on some other business and they were staying there as well sure and I saw them and they were just they were just a picture of physical conditioning you know and I can't divorce that from their success yeah very much the case tell you what Lance and Mariah let's print into a break we want to get to six o'clock quickly so Lance can go do some other business