My name is Fabian Dodge. I'm an engineering manager at Redhead and upstream I'm working on the Kuvert project And that's why I'm more than happy to be here with Ryan And we're going to speak about I'll kind of do you in the about Kuvert Which is part of open chip virtualization and we're not going to speak about open chip virtualization It's specifically right now, but about a different use case of Kuvert. So Ryan. Sure. Hi. I'm Ryan Halasey I work in Nvidia and Nvidia's cloud division specifically focused on building the infrastructure for GeForce now So we're going to talk a little bit about that So what is GeForce now? So probably some people in the crowd have heard about it or use the service So it's a it's a service that Nvidia offers for streaming games in the cloud And so if you wanted to fire it up and you wanted to play a game This is a service you can use and play and like a desktop like experience So if you're like me who's got like a 10 year old PC sitting on your desk that you really love and you New game comes along like cyberpunk and you really wanted to play on a 3080, you know And you get RTX and get 60 FPS Well, I you can use GeForce now if you wanted to instead of changing that desktop that you really like for whatever reason Because cards are expensive, you know So GeForce now is a cloud gaming service you can get that desktop like experience for for streaming all sorts of games and Just to give you a little picture of actually what this looks like There's data centers all over the world and we have about 30 plus maybe almost 40 now data centers and you know in your local your local region So what I also want to talk about as the infrastructure behind this so GeForce now is We're actually faced with the problem a few years ago and the the original architecture for GeForce now It's very VM based is focused on you know, the monolithic model we create VMs and we Provide those as our control plane and we have our workloads that run in VMs and we wanted to move to a more microservice based approach and The issue was is we how do we do this? We only want to go to Kubernetes you want to we know we want to use containers How do we move how do we do this without completely abandoning our investment? And so this is where we actually looked at adopting Qvert and so the next generation of The GeForce now infrastructure is actually based on Qvert and Kubernetes so we took that previous investment where we had our VM based approach and we Brought them forward to actually run those those workloads and on some of our control plane on on Qvert And now we have containers and now we have this ecosystem Which is microservice based for some of our services and we have also our traditional VM based services that we continue to run and so this kind of gave us that nice easy on ramp to Transitioning into this new worlds of microservices So how even more details about this like we have a we have a device plug-in that we use like this is device plug-in Is we actually ship around as part of the GPU operator and all and all them This is a device plug-in is how Kubernetes exposes you know how you attach GPUs for example to a to a guest So we use that heavily We have for we use DPUs for network offloading some performance reasons security reasons a lots of good stuff you get with DPUs we we use Throughout our dentist centers for local storage. We have a bunch of NVMe drives So we that we use so we don't use like In any sort of cloud storage we have we have local storage and then for scale-wise So I have here like a 40 data centers. It's 30 to 40 data centers worldwide Hundreds of nodes per cluster and then thousands of virtual machines and pods that we have inside of a cluster And so we actually use the upstream lease of Kubernetes. So we're actually making our way to 126 now and For Qvert we have a fork that we we do we have a bunch of reasons we do this and mainly it's because a few things that we needed to customize with CPU pinning v2p pinning a few things that we needed to do to make it so that we can consume it We use zero five zero and we're eventually making our way to two zero five nine Cool. Thank you very much, Ryan Right so before I proceed How many of you actually know what Qvert is or had their hands on it? Mmm, that's a nice ratio for the hands that have not been lifted a short reminder So Qvert Qvert is an extension to Kubernetes and Kubernetes is helping us to run containers so orchestrate containers and with Qvert You're able to take your legacy your 20 years old legacy. So VMs From OpenStack from wherever you want it actually over to Kubernetes as well and run it there natively alongside containers Why is that helpful? Right, we believe that it's helpful because you can use Kubernetes. It's a single control plane, right?  If you think of OpenStack, if you think of vSphere red at enterprise virtualization Or OpenShift Kubernetes then all of them have their model, right and by converging the workloads on one platform There's a mental mental reduction for you to think about more fancy things than a platform And you have your assets running on the same platform, right? So it's easier to connect them and to make the transition right like you did at NVIDIA, right? They said we need an opportunity to keep our legacy, right? Our investments still give us the room to evolve and that's what we want to enable all of you As I suspect that many of you've got VMs to yeah to to gain the same benefits from Kubernetes that You know, all right While NVIDIA is using Qvert directly with their own on-premise diploma of Kubernetes We have points of points of contact, right? So we are on the redhead side are using Qvert as part of OpenShift virtualization And some of the problems that NVIDIA is one of our community members has run into is interesting to us as well So the first point that is what became relevant is actually scale, right? So we saw that you run a lot of data sense with a lot of VMs and a lot of notes actually Far more notes than we usually run with OpenShift So there was this scale initiated upstream to to add all the The details right all the metrics all the tunings the small code changes that you need in order to really trace Can we run that many VMs? How do we run them? How well do they run them? What about regressions in an upcoming release, right? So we created the scale in the Qvert community initiated by NVIDIA and Through our collaboration. We were able to to add this regression testing to the Qvert release process Which is helping us on both both sides So one one part of it was these face transition metrics in order to see how long does it actually take to launch a VM, right? It can be vastly different depending on the use case the different storage providers different networking providers all of them If they are on timings But with these metrics you are able to trace that down and to see where do we spend the time? System D or system CTL blame. I think is the note local variant of it We also had an opportunity to to collaborate on the on the networking side of the house, right? So Qvert provides Two mechanisms to connect your VM to a network one is by default a VM is connected to the pod network So that it can speak to every part on your on your control plane You can limit the access or control the access to the VM using network policies like you can control it to pods as well Now you can use it with services and ingress everything, you know And on the other side Qvert also supports attaching multiple interfaces using multis and Our collaboration primarily focused at that stage on the pod network, right? So to make that efficient to make sure that the latency is low. There was some State problems with the bridge networking that we had for the pod network in Qvert and that's where we added like production ready code to Qvert a Major change that is actually reflecting also in Qvert's maturity status is Qvert's release cadence, right? Qvert's been out since 2016 and by now we think it's time to To signal that we're major. I mean we're used in production not only at NVIDIA, but also in other places and So we are aiming to get to a v1 release So one preparation in order to get to v1 was to align our release schedule to Kubernetes Before we had like a monthly release schedule, which is pretty hectic, right? It's hectic for developers to write code But it's also hectic for customers or adopters because you always chased right to to deploy a new update, right? Because Qvert releases are also not supported forever, but only for like like a year or half a year So we try to reduce the number of releases in order to provide Well-tested stable and supportive for a year Releases in preparation for this v1 release these releases are now aligned to Kubernetes So that usually you get a Kubernetes update and a few weeks later the Qvert releases following Why do we follow Kubernetes? because We align a Qvert release to a specific Kubernetes release right so that you know this is a match And if you choose a specific Kubernetes version, then it should be really clear to you What Qvert version do I need to to use or to choose in order to have the perfect combination of both? By the way, Qvert and Kubernetes is not enough Because in Kubernetes you have a lot of freedom about what is my storage provider? What's my networking provider? So there are more degrees of freedom than only Kubernetes right from a Qvert perspective There are more degrees of freedom than only Kubernetes like it also depends on what is your storage provider? What's your network provider in order to understand? What is my the maturity of the overall system and what is the functional scope of the overall system like? CSI providers that can support snapshots or they cannot write so their differences between them Alright, but that is not where our collaboration ended So something that's coming up is Ovi and Kubernetes so OpenShift for a while was delivering the OpenShift SDN to connect the pod network and But we see that this is not sufficient for all use cases We we want to see that we provide a more modern experience for networking in OpenShift Not only for pods but also for networks and we saw a point of alignment to use OVN for it I mean OVN is well known from the OpenStack side of the house or the OpenStack project So we focus on writing an operator or a CNI plugin to support L2 overlay networks with multis for Kubernetes and for Cuba as well including all the fancy stuff like multi network policies and services to tie into all the other features like ingress and load balancers At the same time but not surfaced in in GeForce now is our joint collaboration on the GPU operator so NVIDIA is also creating I think graphics cards and other kind of accelerators and You can use them in OpenShift as well NVIDIA provided or has all the domain knowledge to to empower those cards and we jointly created a GPU operator To make it easy to actually get these drivers to the hosts where they need to belong in order to slice you and video GPU up and allocated to your container or your VM There's also some opportunities for future calibration for example the dynamic resource allocation, which is just surfacing in Kubernetes itself There is more CPU tuning we can do to increase the performance of our workloads and Ultimately last but not least is also the support of them for ARM not only for the control pane, but also for workloads. I Think that's roughly the scope of our talk. I think we are on time And we will be happy to hear any questions about cubert NVIDIA or OpenShift Wonderful. Thank you for the questions already Yeah I think we can repeat the question then is loud or you shout the question was if UDP was implemented for Kubernetes as well because Kubernetes is HTTP based So how the heck do we get UDP traffic in and out of the VMs? So we have we have dedicated interfaces for for specific for game traffic, so we we don't we don't use the Kubernetes network specifically for For using for streaming the any of the game traffic will use external Knicks for this stuff So we will attach them and and that's how we'll we'll offload to the DPU and then we can stream that way So we don't we don't need to implement it By the way, that is also why we collaborate on OVN Kubernetes up here, right? It's because it's for late to network traffic, right? We we acknowledge that Kubernetes is HTTP based and HTTPS obviously, but there's more than just HTTP So it robust layer to solution is is what we need, right? We want logically defined networks We don't want to physically bridge that to some switch So the the question was are we as NVIDIA contributing its changes to upstream or are there changes that are Downstream that I haven't been contributed or kept internal So the there there are changes that we do have internal What we try to do is we look at the changes We see and we see that if there's if there's value in the community like if we like for example We've got a way of doing CPU pinning that is very specific to our use case And this this is and this is exactly what one of the things we keep downstream It's very specific to our use case So we this kind of thing doesn't really make a lot of sense for us to push to the community Now maybe someday like when Kubernetes has expanded the way it so does CPU pinning Maybe there'll be like a way we can plug it in But it's just not that way today. So those examples are Cases where it just doesn't make sense But there are a lot of cases where it does make sense for us to push our use cases and have them support in the community There's there's tons of these that we have we've worked on I mean I can name a whole bunch of mine like he was talking about the with with scale We are scales pretty large larger than I think most people out there So we've done a lot of work to actually find you know take our work and bring it upstream our experience And and try and find bugs within the community like we found numerous on bugs and we bring them upstream We talk about them and we develop them in the context of our scale And then we fix them in the community. There's a number of these like I think another good one We did was like VM pools Where you know, this was a new API that was created out of the nearer where we based on how we do our scheduling of our of our work for workloads We want to have pools of of of different VMs and kind of the way you think about this is like you know Like warming right like if you think even in the VDI use case like you want to have warm sessions available to Allocate at a time and so the idea was that okay Well, there could be an entire API that could be done in Cuber to actually handle this exact use case And so that was actually one of some of the work We did to create this new API for called VM pools and there's new me as others and I'm probably not remembering half of Them but but so the answer question is whenever it makes sense like it's something that Alongs the community that we want to have you know support in the community that others could use we try to push it there In the case that it doesn't We hold on to it and continue to maintain it until maybe the time comes that we can or maybe doesn't We've got a few minutes. Oh Since the demo was recorded I didn't get the I think there's a question if there's maybe a discount on gforce now in order to allow the audience to oh, yeah Okay, well, I mean yeah, I There is a free tier if you want to try it, you know, yeah Yeah, if you want if you want to try it, there's like I think you can there's like you can play for two hours or One hour. Okay, see someone Yeah So yeah, but yeah, and you can try it and you can go run on Cuber. Yeah Okay, it's a good question. So while there are Active workloads with people streaming a session gaming. Are we doing live migration of their active game their session? the answer is no and There are various reasons behind it So if I've been talked about bridge networking one of the things that there's there's sort of a gap here And actually being able to do live migration without any interruption. Well, okay There's a few there's more gaps than just bridge networking But one of them is specifically with bridge networking way It's it's we don't have the ability to support my great live migration with bridge There's also problems with if you can imagine with physical devices and how you actually live migrate with a physical if you're passing through a physical device So yeah that we don't today But there may be in the future with some VGPUs and maybe what's a little bit more work on on on being able to do bridge Networking we might be able to do in the future, but so not today Thank you very much for the questions We sadly only have a few seconds left before we get in kicked out But in case you're more curious feel free to to stop by and catch us somewhere and thank you very much for your attention


So yeah, good morning, everybody. My name is Patik, and I'm from Hackenat. We have a small envelope for you in the bag with a sticker and a card. Please check it out. And this talk is about test-driving JavaScript. And as I was thinking of making the presentation, I thought it would be better if I just do a little bit of life code. Because we had a small test-driven JavaScript chat on Twitter. And it was very obvious that a lot of people wonder, where do they get started with testing? What do they test? And so I thought it would be nice to walk through a little bit of code and see how we test at our company. And maybe you guys can take some ideas back. So this is the first time I'm doing any kind of life coding. So if things go wrong, please bear with me. If you see any errors in the code, help me out with it. So what we're going to do is, at our company, we love Stripe. And it's a very nice payment processor. How many of you guys have heard of Stripe? Cool. So we're going to build, I'm going to clone their idea and build a competitor here, right here, with you guys. And we'll start with the JavaScript. You'll start with the important bits. So what we're going to do is we're going to build a small class, a card class, which can take a credit card number. And it can tell me whether that credit card number is valid. And then another charge class, which can take the credit card instance and an amount and charge it. And we're going to test drive this whole thing. We're going to drive this through tests. So let's get started. And as we test drive this, I'm going to introduce you guys to the concepts of Jasmine and testing in general. So typically, the way you describe these tests or specs, as we call them, is you start describing the behavior that you want. As Sunil was saying, it's like code that describes what you want to achieve. So we'll start with the describe. And I'm going to call it Stripe with a y. And that's going to take on Stripe. And can you guys see the code? OK, cool. So first, we'll describe the card class. So we'll say Stripe.card. And we'll start describing this. And so tests inherently contain every spec has an expectation. It's like, what do you expect? So the simplest thing I expect this class to do is that I expect Stripe.card to be defined. That's it. It's the simplest spec I can write. I expect this object, basically, to be defined. And I have a test runner set up here. Or I had it set up here. OK, that's a good start. So all right, there's a comma here. So it says, hey, Stripe is not defined, actually. So let's go ahead and define Stripe. And what we'll do is we'll just make it a function. It still says Stripe is not defined. Last time I checked. So let's just view page source and see if it does pick Stripe.js. OK, CoffeeScript. So it has to be window.stripe because CoffeeScript wraps everything in an anonymous function. OK, so sorry, I have to wrap this in it. It should be defined. OK, thank you. So expect undefined to be defined. So let's just go ahead and define Stripe.card once again. So this spec passes. So if you want to get started with testing and you've been stuck, just start with the simplest spec. The simplest spec being if things are defined. So that's how when you're starting off testing and you find it hard to get started, just do very simple things. OK, so now let's do the next thing and describe the behavior and initialization. So we'll say describe initialization. And what we'll do is we'll say if you don't pass the card any arguments, it should throw an error. So we'll just define a small behavior like that. So we'll say expect and we'll pass it a function. So we'll say new Stripe.card to throw. And it can say expect a card. So now let me run this test. And OK, I'm sorry again. Sorry, it should throw an error if no card indentation. So it says expected function to throw an exception. And so let's add just that behavior. So what we'll go ahead and do is we'll say, say options, say throw expect a card, unless options, all right? This works. So now we have one more spec. Let's go ahead and make sure that if we do pass, actually, I skip the step over here. Because according to test driven development, when you're getting started, especially what you should do is you should take baby steps. So I'm going to remove this unless. And my spec still keeps passing, as you can see. So I've actually written as little code as I need to make this spec pass. So now I'm going to go right and say it should not throw. And just give me a second. I'll take out my phone so I can keep track of time here, actually. So let me know 15 or 20 minutes before the talk's getting over or something. So it should not throw an error if card is passed. And now I'm just going to copy this over and say expect new card if, let's say, card number x, x. And in Jasmine, you can say not to test the not expectation. So now this will test that it should not be throwing an error. Once again, it says it expected it to not throw an error, but then an error was thrown. So this is a typical red-green refactor cycle. You always start with a failing test, and then you move on. So now I'm going to put this condition back. And as you can see, it passes. So this is how we go about building our classes, whether we are working on DOM. We start with the smallest step, and then we incrementally build it from there. Now, I would test drive more. I would make sure that things are being properly stored. But I'm going to skip a few steps here just because we have limited time. So what I'm going to do is I'm actually going to start storing the number here. In an instance variable, I'm going to say number is equal to options. And I should actually change this to number because you are initializing a card. So number is options.number. And I'm only going to accept a number for now. We can accept CVV and expiry, but we're not going to do that. Now, one of the most common things you do with a card is you want to make sure that the card is actually valid. It's a valid credit card number. So we're going to write that behavior. So we're going to write the behavior for validation. And we're going to say it should return false if card is invalid. Once again, a very simple spec. And what I'm going to do is I'm actually going to initialize a new card. So I'm going to say card is equal to new stripe.card. Number, let's say xxx, or 1, 2, 3, 4. 1, 2, 3, 4. Now I expect. And when you are test driving this code, you should go about as if you already have the class and the functions that you need, assume that they are already there.  So one of the cool things about writing tests is that it guides your implementation. It tells you what to actually implement. So I'm just going to pretend like I actually have a function called valid number already there. And when I call it, I expect this to be false since this is a invalid card. So I'm going to say it says undefined is not a function because we haven't defined this. So since this is an instance method, we're going to go ahead and define this on the prototype. So we're going to say dot prototype equal to, and we're going to say valid number. And I'm just going to return false. That's it. Because our test expects to make this test pass, I just need a false. So I'm going to go ahead and something is missing. OK, cool. As you can see, this is actually life code and not just lip-syncing. So now my test passes because I returned false. And so let me go ahead and write another spec. And I'm going to say, so I'm going to copy this over. And I'm going to paste this. I'm going to say it should return true if card is valid. And what I'm going to do is I'm going to use the golden test credit card 4242. And I expect this to be true. So I expected false to be true, so it is true. So let me just go ahead and once again just write the simplest thing that works. So I'll go ahead and say, if at number equal to 4242, sorry, programming 101, then return true, else return false. Now everything works. But of course, this is not the correct implementation because you have more cards than that. But the problem is that we cannot actually, I don't want to write the test for checking for cards because it's very complicated. It's beyond my capability. So what I did was I went ahead on the internet and I found a small script or a small function. This is actually a very efficient way of checking for credit cards. And there's something called, and it helped me with the pronunciation. It's I think LUN test or LUN test. But a card to be valid has to pass that test. So I found a library which does this for me. And I just want to go ahead and actually use this. So what I'm going to do is I'm actually going to describe the implementation here. So one of the ideas in testing is that if you are using a well-tested library, then you don't need to test it again all over. What you need to do is you need to make sure that the right calls are being made to the library. And if the right values are being written, then your code works as expected. And the way we achieve this in most of these frameworks or libraries is by the use of mocks. So we can use, and what mocks do is you can say, hey, this is my object. And I expect it to get this method. And when it gets a method call like this, return this value. So for example, in case of our credit card test, we need to check two things. If we give it a valid credit card, it should return true. And our function itself should return true. If the valid check fails, then we should return false. So there are two parts. So we'll have to write two tests. And what mocks do is they make your test predictable. So for example, if you were making a network call and you actually made a network call to the server, your test is still not very predictable because server could be having some issues or whatever. So you mock these calls so your test can be sent down a very predictable path. So that's what we are going to do here. We're going to test the implementation. We're going to make sure that our lunch check is called, and it works properly. So I'm going to describe that. So I'm going to say it should return true if lunch check returns true. And I'm going to go ahead and use a mock. So I'm going to call it a mock. And I'm going to say synon. I'm going to need some help with the syntax here. So synon.mock. And the library I want to mock is the one I downloaded from the internet, lunch check. Now I can say mock.expects. So I expect this mock to get a method called check. And when it gets that method called check, for this specific test, I want it to return true. So I'm assuming, let's say I pass a credit card and my tester says that this is true. This is a good card. I want to see that my code can take that result and do the right thing. I don't want to actually go ahead and make. I know the library already works. So mock.expect check returns true. Now I'm going to go ahead and initialize a new card again. So as you can see about these tests, we don't share every test builds up its own state and then discards it so that the tests don't have any dependency. This is the way you should be testing. So I'm going to build a new card. And I'm going to say card.validNumber. And I'm going to put this expectation that expect card or validNumber to be true. Since I'm forcing my library to return a true, I expect my function at swell to return true. So expect card or validNumber to be true. So one of the things you can do with mock is once you set up a mock, you run the test that actually would use the mock, and then you verify the mock. So you can ask the mock to verify that whatever expectations we had given it work. Because if the mock will actually throw an error and your test will fail, if those expectations have not been met. So we're going to go ahead and say mock.verify. And you should restore the mock. So this gives your next test a clean slate. The function is still not mocked. So you must restore things before your test is over. So let's run this. So this says expected check once, and the check was never actually called. And that's because we haven't written the code. So let's go ahead and write it. So now I'm going to replace this. And I'm going to say, if luncheck.checkNumber, if this returns true, then return true. So I expect it undefined to be false. I'm not sure what was expected to be false here, actually. I thought so. Let me check that. So we're passing it a valid card number. Sorry. Elsecase. Oh, OK, OK, OK. That's a good catch. Thanks. Cool. So everything passes. Now I would go ahead and actually repeat this test. And I would go ahead and write a case for it returning false, and then my function returning false. But I've pushed this code to GitHub. You guys can go ahead and read it. So just to take more questions, I would skip that step now. And I'll refactor this code. And I will just say, that's it. The return value is the value that I need. My test still passed. So this is the other thing that once you have a red, green refactor, once you have a green, only then you go back and refactor the implementation. You don't start refactoring it while your test is still red. So that's where tests help you as well. So now we have a valid number check. Let's go ahead and start describing the charge class because that's a little bit more interesting. So what I'll go ahead and do is, so I'll say describe try.charge. And once again, I would be doing the test for it throwing an error if no arguments are passed and stuff like that. But I'm just going to skip that for now. So I'm going to go ahead. And start actually charging the cards. I'm going to say it should call a success handler if the charge succeeds. And since I have skipped over a few steps here, I'm just going to go and write the basic charge class right here without the test for now. So I'm going to say charge equals, and the way I'm going to initialize this, I'm going to say options at card equal to options.card at amount equal to options.amount. And I wrote a small controller here, so let me see it expects card number. All right. And so that's the initialization. Now let's write this spec. So first of all, I need a new card. So I'm going to say at once again, I'm going to copy over my card from here. At card equal to new stripe card. Now I'm going to create a new charge. Instance a new stripe.charge. I'm going to say card is at card and amount is 10. And the way I want to charge this card is I want to do atcharge.create. So this should make an API call and create the charge. But before I do that, one more thing I want to do is I want to define a success handler. So since this is an Ajax call, I want to pass it a success handler. And when the charge succeed, that handler should be called. And that handler can then notify the user that the charge has been successfully created or do any of the other things. And so in this test, what I want to make sure is that at some point during my test, this success handler was called. At this point, I don't really care what it was called with or what it retires. I just want to make sure it was called. So these libraries provide you with something called, I'm using Synon.js for mocking and stuff. These libraries provide you a spy. What a spy does is it will tell you can ask the spy whether you've been called or not. So we'll just go ahead and create a spy. Once again, I'm going to use my help to create a spy.  And I'm going to give it a name, success callback, so that when you assert spies, it's going to say, hey, success callback spy was not called. So now I want to do a charge create, and I want to pass it a success handler. And success handler is add success callback. But since this will be making a network call, and I don't want it to actually make a call to the server, I want to mock the network request. And when I started doing tests in JavaScript, this was like the really cool part for me, that you can fake XHR requests and force them to go the success way or the error way and easily test your error handling or the success handling. So let's go ahead and create a new server. So once again, I'm going to take some help here. So I'm going to do synon.fakeServer.create. Synon gives you something called respondWith. So you can say server.respondWithPost, whenever you get a post to slash charges. One second, sorry, I should have copied the whole thing. So what you can tell it is that whenever you get a post call to slash charges, then return with a 201. 201 is a standard status code for something created. And with something like, here it would be charge colon 10, that, hey, your charge was created, and maybe it can say amount. And the amount was 10, all right? And then I go ahead and create the charge. And at this point, the fake XHR is actually going to block on, my test is going to block on this network call until I go ahead and say addServer.respond. And the way I want to test this call is I want to say expectSuccessCallback, which was a spy, to have been called. So these are matches with Jasmine provides you, and you can download custom matches. You can write custom matches as well. So in this test, all we are saying is, as we wrote here, should call a success handler if the charge succeeds. I want to test that my success handler has been called here. So now let's go ahead and run this test. This is probably a like, undefined is not a function because we have not defined the charge. So we'll go ahead and define charge.prototype.create. So now this is defined, so this should no longer complain about that. Expected success callback to have been called. Clearly, we haven't written any code, so the success callback hasn't been called. Once again, I'm not a JavaScript ninja, so I'm actually going to go ahead and copy some of the Ajax calls. So I'm going to go ahead and paste this. Now, six lines will uncomment. So what we are doing here is we are making an Ajax call to slash charges. We are stringifying the data. So we are going to say add card.number. Amount is amount. These are the instance variables that, sorry, we had just set up here. It's a type post. The content type is application.json. And here is the options. And on success, what I want to do is, if options has a success callback, then just call that callback. So it's a very simple standard Ajax call. And let's go ahead and run the test. Cool. All right. Thank you. Cool. So my success handler has actually been called. And now I'm going to go ahead and write one more thing. I'm going to do is now, since this is red green, I'm going to extend this test out a little bit more. And what I'm going to do is, like a success handler, I'm also going to define error handler. I'm going to say an error callback. And I'm going to give it the name error callback. And I'm going to say, I also expect the error callback to not be called, to not have been called. So I want to make sure that the success handler is actually called, and the error callback is not called. But I'm also going to change my method invocation to also pass the error callback. So let's go ahead and run this. And it keeps working. So since we haven't actually written any code. Now let's go ahead and write. I'm going to extend this out a bit so you can see this. Let's go ahead and write another test for when the charge fails. But before we do that, we're going to, again, create a card. And we're, again, going to do all of that stuff. So let's go ahead and refactor this test itself. So once again, we are refactoring the test only when everything is green. Please don't refactor anything when things are red. So Jasmine provides you with these setup helpers called beforeEach and afterEach. So if you want something to happen before every test, and remember, this will happen fresh every time a test is run. It's not shared. It's not that the state is built and reused across tests. Before every test, it will go back and run the beforeEach and set up a clean slate. So we'll go back and move some of this stuff, like up to creating the fake server over here. So we're going to set up the server. One more thing we are going to do is we're actually going to move the restore into an afterEach. So after the test has been run, Jasmine will go ahead and run this. So we're going to do the respond. Sorry, not respond, actually. Let me go ahead and fix that. Server.restore. I should have done that in the last test, but server.restore. And let's make sure that our test still keeps running. Nope, it doesn't run, because respond with not read property, respond with of undefined. Interesting. So I'm creating an add server here. Add server.respondWith. Oh, sorry. So beforeEach, you just pass it a function. It's a function that you pass a function, and it runs it. So our test keeps passing. So we have refactored this now, and our test is still green. So now we're in a good shape to go ahead and write an error handler. So we're going to copy this whole thing over, go ahead and paste this. And now we're going to change this to it should call error handler if the charge fails. And as you can see, we are still using a valid card. So we are using a valid card number. We didn't change that. And it doesn't matter, because the only way to make this test predictable is to have the network call always return a failure in this case. And the way to return failure is to do a 402. So Stripe does the same thing that if your request has all the valid parameters. But something still goes wrong, which means the charge could not be created or whatever. It returns a 402. So we'll also return a 402. And this is optional. We can change the response to be error colon cannot charge card spend lesser. Cool. So that's it. Now we're going to create another, and we're going to do server.respond, and we'll say expect success callback to not have been called. But the error callback should have been called this time. So we're going to go ahead and run this unexpected cannot. So let's go back in cannot, cannot is from here. Double quotes, thank you. Cool. So it says expected spy error callback to have been called. And that's why it's nice to name your spies, because they can tell you which one actually failed. So error callback to have been called. It hasn't been called. And we can go ahead and fix this test by simply adding an error handler, which invokes error callback if it's present. Let's go ahead and run this. And as you can see, this works. So if you notice, we have still not gone to the browser to do any real testing. So let's go ahead and do a little bit of real life testing here. Since all my classes and files are included here, I'm just going to do it in the console.  So let me create a card here. The card is 1, 2, 3, 4. And now I can say, is card a valid number? It says length of undefined. Sorry, I should have changed this to number. I'm refactoring between my practice sessions and here. Card or valid number falls. Now let's pass it a valid card. Let's pass it 4, 2. Oops, sorry. Once again, yeah, I got it. It's number. Card or valid number, it's true. So this works. Now let's go ahead and create a new charge. So a charge is new. Stripe.charge, card is card amount is 10. And now I'm going to go ahead and actually create this charge. It should have logged a network request, which means that something has not been restored. So yeah, after each has to be. Cool, good catch. So let me reload this. So this is what happens if you don't restore your mocks that they actually still keep interfering with the rest of your tests. So let's go ahead and repeat that. Let's make a card. Let's make a new charge. Let's do a charge.create. And as you can see, it returned a network called 201. And I've written a very simple server. What it does is it returns, except for this card number, anything else, it will return a 201. So this charge succeeded, but we didn't pass it a success call back so that it doesn't matter. Let's actually do that. Yeah, so here we'll just do a success colon, a small function, console.log cardcharged error function. This time I'm going to close my brace early. Console.log card not charged. Cool, so as you can see, the card was charged. Now let's go in my controller, I have a simple test for if this is a card number, just return a false. So I'll go ahead and create a new card with this number. And I'm going to do, once again, I'm going to say a charge is new charge. And charge.create with these handlers. And as you can see, I got a 402 back and the card was not charged. So as you can see, to me, the coolest thing is that I could do this testing, real life testing, only towards the end. And it saved me countless, it actually saves you over a large project, literally dozens of hours in a week to not have to go through this manual grind. And now we have a simple credit card class and a simple charge class, which we test through. So it helped us guide our implementation. As you can see, the implementation is extremely simple. It is also providing us a safety net, and it is saving us from repetitively testing manually. So I hope this is pretty much the talk I had. I hope this has given you a little bit of idea of what test-driven development is. There are a lot of great resources on the internet. Go ahead and Google for them. You can tweet to us. You can ping me on hack and act. And hopefully you guys are excited about testing, and you'll start testing a little bit more. If you have any questions, I would be happy to answer them. Hey, so I'm a fan now of test-driven development. Thank you. Apart from Jasmine, are there any other TDD frameworks or libraries you might recommend? I think there's Mocha. I'm sure Chai, as somebody said, I'm only half a programmer. I enjoy coding, but I don't code full-time. So I don't go about exploring a lot of tools. I find Jasmine nice. I already have some comfort with it. I just keep using it. But I think Mocha and Chai and a few others, you can probably post it on scroll back and ask people for other recommendations. Thank you. Hey, hi. This is Nishchit. Two questions. One is regarding TDD, right? So in Jasmine, is there any way where you can actually feed in those test mock data, right? You had a mock response. So can we feed it from some JSON files or something like that? So for example, if you are using Backbone, which is what we use a lot, there's this concept in testing called factories. And what you can do is, so let's say you have a user object. Now you can create a user factory, and you can say, give me a new user, new fake user, and it will have an ID incremented and things like that. So you can go ahead and, unfortunately, I don't have internet, but you can find these factories. If you're using it for Backbone, I've written one in open-source.it on supportbees.github. So you can find it there. There are some other tools like that. So we've also written some helpers which can create, using those factories, you can say, I want to test a user index call. So give me a response with three users in it. So it can reuse this factory and create those responses. So there are tools like that. You can also over time write a little bit like that yourself. So what do you mean is, within this test spec, we can actually call some JavaScript things which actually help you with this kind of test data. It's called fixtures and factories. You can just Google for that. And second thing I had is, as Sunil was also telling, right? So we all, at some point of time, tried doing TDD, and not specifically in front end, I also tried in Java server-side unit testing and all right. At some point of time, it becomes very difficult to follow and be disciplined with these things. So what are your experience, I mean, some tips, if you want to give us? I think the way I've seen most people pick up test development, if I think about it, is to actually pair a program with somebody who's already fluent at it. Because then you sort of get to see that, oh, hey, it's helping me actually be faster. Like, for example, for me, now if I'm writing any serious project, I actually cannot do without testing. But it's like learning a guitar, to play a guitar, or anything else. You have to get over that initial hump and get to the point where you can see what the point is. It's like running, right? When you go for your first one, you're like, what is this big deal with this? So it's something like that. So I would recommend just find somebody whom you can pair up with a little bit, and then sort of learn from that. Thank you. Pratik, hi. OK. Hello. So some of the folks in ScrollBack were asking, I mean, they could not follow very clearly because it's coffee script, and they weren't very familiar with it. Could you show them the generated JavaScript? OK, sure. I'm just going to have to load it up here, because I don't know if this is even being compiled and put in a file. But here is the spec. If you can make out anything. It's basically these functions. So describe is a function which takes another function. In that, you can nest either a describe, or you can nest it. And it is what actually is an expectation, which throws an error if it is not met. So this is sort of how it looks. This code is up on GitHub. Just go to pratikdayal, github.com, slash pratikdayal. It should be one of the last updated repository. Github.com, slash pratikdayal. OK, and a second question is, I mean, the syntax is similar to Mocha, but you're using Jasmine, right? If you've used Mocha also, how do you think they compare? Never used. Hi, Pratik. This is Ritesh here. He's a friend. I can hear you. Oh. Right in the front here. OK, cool. I have a question related to the Jasmine test cases. So we also use Jasmine. So I just wanted to know a little bit more like how you test your web services. So do you mock, or really you call the services? And what you basically test, like the methods, or what you should test and what you should not test? Yeah, so it's kind of like this. If you've done any backend testing, then especially in Ruby, which is what I have done. If you see, we create actual in Rails, for example, you create a user model. And then you do a save to the database and then see if it works well. I mean, you can mock that call, but most people don't do it. So you're actually talking to the real database. So unfortunately, in JavaScript, if you want to talk to an API, we don't do it because it's not recommended. So we mock our Ajax calls, all of those. And we do write integration tests using Cucumber and Capybara, which exercise the whole thing from the front end to the back end. But for Jasmine, we mock everything. As we said, we've written some helpers. Once again, they are open source. They are on support V's GitHub. They really help us mock very fast. In fact, one of the problems with this testing is that you can, let me see if I can show you that code. It's a little bit of an effort to do this setup and restore and these things. So for example, what we have done is we've written these helpers, like sb.testing.testwithmox. I expect the class date to get done now, which should return 1, 2, 3, 4, 5, when a ticket list.fetch is fired. So you can use helpers like this which make your life much simpler. So you can do it much faster, actually, that way. So just try to understand your domain and write helpers which help you test faster. As you're going out, as you're refactoring your code, keep refactoring your tests as well. And just keep writing reusable methods and stuff. Thank you. Sure. It quickly becomes really painful. So what are your advice when you're testing DOM interactions or events happening in the DOM? Actually, I've had quite an OK time testing DOM. So for example, let's see if I can load up something. So for example, we have these tests for rendering and clicking. You add a label to a ticket list, and then it should change the URL on click and find an event. So we expect the navigate to get an argument with the right URL when the view subject is clicked. So you can actually test. That is the thing. If you are not able to test, that's probably an indication that you are doing too much in that function. You're doing too much in that module. If you keep it small and nice and sweet and use events to talk between the DOM elements and things like that, you will be able to actually test. So one of the things is if you're starting testing and you find it very hard to test, then that's probably a reminder that you're writing code which is too tightly coupled or just doing too much. So sort of treat it as that as well. But otherwise, and in fact, Jasmine provides some people have written jQuery helpers on Jasmine, so expects to have this class, expects to. And it's pretty easy to actually do it. Hi, so how do we test third party libraries like CK Editor in Jasmine? You just, as I said, you assume that the library works well and you test that your function is initializing those things right. That's it. And that's why I said, in the end, you need to have integration tests using Kappybar or something which will actually insert some characters into the CK Editor. And then so that's sort of what we do at support. We have cucumber which launches an actual Firefox and goes to at least all the happy parts. Cool. All right, thank you folks. See you over the tea break.


Zebra wood. Yeah, it looks like a zebra. Oh, I'm cool. Zebra wood. Should we talk about the painting? Let's do the painting. Under everything that is, you know, geometrical, I put a sort of a chaos underneath. And then out of the chaos, I try to find, you know, relations. This is 72 inches by 96. It's oil on canvas.  Every four, I put, you know, the geometric, you know, structure on it. So this is going to be the base, basically. To a certain degree. I mean, this would be the base, but I wanted it so, you know, that the chaos is actually the painting. So this is, so, so I basically, you know, switch myself around. You know, I thought the other way around, like the opposite way. So what is it? What is it? You did this with brush, every stroke? Well, different size brushes. No, it's one size brush. This is sort of a tool that I use. It's made out of silicone. Oh, so you're drawing with this. And I cover the whole canvas with a layer of, you know, thick, let's see, paint. It's oil paint and it has, like, it's a monochrome. This is a monochrome gray. And I wait for it to dry just a little bit. And then I just begin, like, in one corner. Bam, bam, bam. And I go over here. Then I take another one, because I have two. And then I do parallel, you know, motions. Like this. Everywhere. And I don't stop until I think it's, you know, finished. And it usually takes, this one took me, like, you know, two and a half hours. Including with the base, including with the base. Not with the base. Just the lines. Just the lines, two and a half hours of constant emotion without taking a break. Two and a half hours I had my music on. So, you know, that would help. I would step back, you know, check it out. But now it's all, I know when it's finished. Okay, cool, cool, cool. What it does, so this is the one painting you've been walking on. You said you liked that one. Do you want to bring this one? Let's bring that one over. Okay, this one's also finished. Many people don't like it. I love it. Hold on, let's move the camera. Let's see that I'm going to bring it over here so we can see a good size on it. Okay, should I start? Yeah, yeah, yeah, go ahead there. Okay, this is this painting based on the golden rectangle. And the golden rectangle here is sort of like here. Okay, that's the golden rectangle sort of in there. But I made it bigger, you know, to fit. And so the golden rectangle is basically, you know, the darker part. Oh, okay, yeah, yeah. And I actually painted, you know, three golden rectangles on there before. I covered everything up with gray and with a blue gray. Each segment separately, different. Each golden rectangle differently, different color. Like a different color.  And then I took an oil stick, which is also like sort of oil painted. I'm his oil paint.  I was like thinking about, I mean, here's the golden. Oh yeah, right there. Small version of it. What do you call this? Did you call this TV? This is called TV because when I, you know, watch TV, I feel sick. I just, all the voices, all the voices. Chaos.   That's what you love it. Yeah.  This is all noise, basically. It's just noise.  But, you know, I've seen like this with, you know, the title TV, it just works. For me, this is, I mean, it's totally contrary to all my other, you know, work, but I have to do this in order to do the other stuff. To clear your head, to get rid of what you need to get rid of. Like I'm working on, you know, something like this. Okay, so, you know, I mean, that's a contrast. That's a contrast, you know, to this, you know, completely. And it has to be because otherwise, you know, I couldn't do this, I'd go crazy doing this. And if I only do this, I would go crazy doing only that. Because there would be no, you know, no sense in anything. Can we show the painting that you're doing in the, that you did on the, in the other room with the face? No trouble at all.  Let's make sure it shows up. Can you see that? Oh, yeah. Okay, these are, these are all basically, you know, black and grays and dark blues.    I mean... So there's the, like this one you can see, there's like tons of grid patterns on it. Not grid, just chaos in the background. There's chaos in the background. And a grid. Yeah, arches.  See here. And there. I love curves. Here, this is called a transmigration.    I don't know if you can see this, but, you know, this is like a mouth. You know, that's, that's opening. Here's the chin. Here's the nose. Here's the eyes and the forehead.   Yeah, I wish I hope you can see this because when Dirk showed me this, he goes, what do you think about this painting? I said, oh, I love it. It's like chaos. It's like dark and sort of chaos and just there's a lot of different artwork here, right? It stands out from some of the other stuff that he's doing. And then he goes, can you see the face? I was like, what? What face? And he actually pointed around and looked at it for a few seconds and all of a sudden I just saw it and it just blew me away. Right? So I seriously hope you can see it because it's brilliant. And it's oil on wood and it doesn't have a sheen to it because I, because I manage, you know, the colors very well.  So how do you, how do you get rid of the sheen? Well, the thing is I mix all the oil paint with a lot of turpentine and there's no like oil.  And it takes about a, you know, 24 hours, you know, to dry so I can do the next layer, you know, the next day. So, so, so this is basically, you know, five or six or seven, you know, layers. So is each layer a different color? Or do you mix it up? Well, I mix it up usually. You mix it up usually. Because there's a blue here, you saw that.  Okay. Or before, you know, and then it gives that. Okay. So these are like basically three of the paintings you've, or four of the paintings. This one, the grid one is still active. Like this one is, you're still working on it. Yeah.  But these ones basically, these three are done. Yeah. Yeah.  Since that time, you've gone through doing something that's just like chaotic. So you switch up between sort of organized and chaos.  Let's check it out. What kind of art? Op art? Like op art. What's op art? Well, you can show it. Let's see. Okay. This is a canvas. This is a canvas that I folded.  Basically, I mean, that's what it looks like from the side. So canvas folded. Canvas folded and then mounted on wood and then painted with oil. Mounted on wood back here. Oops. Let's bring it down here. I'm going to take this closer to the. So mounted on wood. And just hangs like this, as you can see. So it gives you the illusion of, you know, something going like this way and something going down. And you gave it cuts? Well, the cuts are the, you know, this was basically just one long piece of canvas that I had over from stretching here, the big one. Oh, okay, okay.  I don't like to throw things away. So I like to keep everything. And this is, you know, I painted it first. I made it really long. And I cut it in half and I put a section here and slid one and into the other. Oh, yeah. And I flipped it.  Oh, it's the other side. It's the other side. Exactly. Ah, that's cool. Again, you're working with optical illusions, basically. It's a total like optical illusion. That's why I call it off art. Off art. Off art.  Like it was off art. Oh, it just like pops out optical illusion. Optical illusion. Okay. Optical illusion. Off art. Okay. Okay. Like the contrast, you know, to this and to that, because, you know, that's what it's about experimenting, you know, finding new boundaries. Yeah.  I'm doing it over or trashing this, trashing this. Well, I mean, this I was going to throw away, but then I, you know, painted the lines over it. Yeah. And then I just, you know, started to put, you know, lines over it. Just layer it. And now, you know, it's beginning to take shape. Yeah. Okay. Cool. I don't know, you know, what it is. I don't know what this is. Let's take it. Let's take a look at some of your structures. Let's take a look at some of your structures because your structures are here. Let's do a different. Okay. I'm going to put this. Okay. We're going to change the camera and take a look at some of the sculptures basically there because it has been working on at the same time that he's been working on these paintings. Right. So there's a lot of, he's gone ballistic. He's just going crazy with the artwork and putting stuff together. Okay. So angles, angles. How are we going to do this?


Coming up on DTNS Scott Johnson explains why Sony and Microsoft's acquisitions are more about metaverse than consoles. Central Bank digital currencies spread farther across the globe and a contender for the next big content app is also a shopping app. This is the Daily Tech News for Wednesday two to twenty twenty two in Los Angeles. I'm Tom Merritt and from studio Redwood. I'm Sarah Lane in Salt Lake City in the frog pants studios. I'm Scott Johnson. And on the show's producer Roger Che. There's a longer version of this show called Good Day Internet where we talk about the buzzy TV shows today. You can get that at patreon.com slash DTNS. Speaking of patrons let's thank a few top patrons today they include Vince Power, John and Becky Johnston and Chris Benito. Let's start with a few tech things you should know. In its third quarter earnings report Sony said that it shipped 3.9 million PS5 consoles through the holiday quarter that's up 18 percent on the quarter through the end of twenty twenty one in total Sony shipped 17.3 million PlayStation five consoles three million fewer than at the same time from its release compared to the PlayStation four overall gaming revenue decreased 8 percent on the year to 813.3 billion yen which is about a hundred ten million US dollars. Its image sensor division saw revenue increase though 22 percent to 57.5 billion yen. Space X announced a new high performance tier for its satellite inner sir internet service called Starlink premium coming in Q2. This will use a high performance antenna that can perform better in extreme weather conditions and something pertinent right now offering download speeds between 150 and 500 megabits per second and upload speeds up to 40 megabits per second. The antenna hardware will cost you twenty five hundred smackaroos and service for that tier starts at five hundred dollars a month. Oh wow. I mean it's going to appeal to some people but boy is that not cheap. The company log me in which owns go to meeting and also last past announced that it will change its name to go to the company still plans to proceed with its spin off of last pass into an independent company. They should have called it go to log me in. Oh I see you did. Alphabet earned thirty dollars and sixty nine cents a share in Q4 and revenue up thirty thirty two percent on the year to seventy five point three three billion. Important part of all of that number salad is that beat analysts estimates all of it. Overall ad revenue was up thirty three percent on the year. YouTube ads brought in eight point six three billion missing analysts estimates so a little less than they expected. Cloud revenue a big one for Google grew forty five percent to five point five four billion with the units operating loss down twenty two percent on the year to eight hundred ninety million. So still not making them money but make losing them less than they used to its other revenue segments are revenue up twenty two percent other revenue being all the other non Google stuff. CEO Sundar Pichai said it had an all time sales record for Pixel phones in the quarter. Well if you're following the Apple car which isn't a thing yet but might be a thing in the future this might be interesting to you. The U. S. patent and trademark office granted Apple a patent for a car sunroof. The sunroof uses variable opacity glass to let a driver adjust transparency you know sunny or cloudy or whatever opens in sequence with the side windows rather than being a fixed panel on its own. Yeah intriguing always goes with our normal patent disclaimers of patents don't even usually end up in products but hey maybe this one will. All right let's talk a little more about pop ups Sarah those things that asking me about cookies they always make me hungry and frustrated. Yeah so in Europe these are most often part of the transparency and consent framework. Let's call it TCF provided to sites by the International Advertising Bureau or AIB Europe. Belgium's data protection agency find AIB Europe 250,000 euros saying that the transparency and consent framework tool violates GDPR both in the nature of consent and also the data that it collects. The key contention is that the framework itself shares your preferences with third parties for purposes of knowing how many people choose which options. In addition to the fine the regulator ordered any data collected under the process to be deleted and AIB Europe to issue a series of remedies to come into GDPR compliance and a statement the chair of the regulators disputes chamber said quote the processing of personal data like recording user preferences under the current version of the TCF is not in accordance with the GDPR because of an inherent violation of the principle of fairness and lawfulness. It asks people to give their consent when most of them don't know that their profiles are sold countless times a day to expose them to personalized ads. Now Johnny Ryan who's a senior fellow at the Irish Council for civil liberties says this is a pretty big deal for Europe but it could also have ripple effects elsewhere. For example Ryan says American lawmakers and regulators have often looked at the consent spam if you want to call it that happening in Europe and called it one of the worst consequences of GDPR. Ryan also says that this new decision exposes that spam is a violation of the law and not a fulfillment of the law. Maybe this is far from over though. It's it's pretty clear that AIB Europe is going to appeal the part about data collection. They haven't said they will for sure but they indicate that they will and that's kind of the more damning part of this decision. It's it's the idea that telling you we're going to record your cookie preferences and we might share that with third parties is far from telling you and that could be used as a fingerprint to serve you ads somewhere else when you agree to cookies elsewhere because then we'll know like based on your pattern who you are. It's not exactly personal info but I get what what Europe is saying that that looks like it's going to turn into into a fight. The framework part of it sounds great. We're like oh right when they try to trick you into accepting cookies by making a complicated. It'd be great if that changed but I'm guessing whatever AIB Europe comes up with and submits won't be that much simpler than what we have now. Yeah I can't imagine that they that there's ever a scenario where where cookies themselves are completely removed from the scenario in the same way that other obvious tracking methods are used or other obvious data collection methods are used. I just think it's too universal that genies out of the bottle in a way that even the Europeans who get much more strict on these sorts of issues. I just don't think they do it because there's a lot of arguments that can be made about how cookies are not just important to the internet but maybe required these days and if people want to do business and have an open commerce platform across the web that they can't get that picky there. I don't know it just seems like they can't and maybe that fight will be big enough that maybe they can and maybe all the right people involved can make it happen but I don't see it. Yeah I when I when I was kind of trying to make sense of the story this morning I I was really stuck on this whole like what is personal information versus what is not personal information. Sure somebody may not you know as as as an advertiser that wants to target me in the future they might not get enough information to do that accurately through cookie settings but once people kind of get wind of the idea that this information is being shared and floated around it scares people. Yeah well and the contention wasn't that they shouldn't be allowed to collect it the contention was they weren't making it clear what what's done with it later. Yeah that's a pretty easy fix it's just one that IAB Europe does not appear to want to make because they would rather you not quite know what you're getting into right just makes it easier to collect. And I think this is another example of honestly the right instinct is to say let's force those websites right we all are like yeah let's force those websites to tell us what they're doing with cookies but look what's happened when you write a law they just figure out a way around the law whereas a better way might have been to just promote plugins that block cookies and give you control over it rather than relying on the websites in IAB Europe to come up with this janky way that tries to get around the point of the law and will continue to be an issue I think. We tried to tell them about those plugins they didn't listen. You can still use a plug it so yeah that's true. Tuesday we mentioned multiple tech related policies announced by India and among them was a plan to issue a central bank digital currency or CBDC. The Reserve Bank of India plans to launch the digital rupee on April 1st. And side note yes India does know about April Fool's Day but that's when they scheduled it. It is happening. India plans to follow the launch with strict controls on cryptocurrency so look for that. But they did not give details on the technical aspects of the digital rupee so it's fair to expect this launch is going to be a pilot not an active currency right from the start. But I think I figured it was a good time to check in and see where CBDCs are. We've been following them on DTS for a long time now and so those of you who listen you're up on this. 87 countries are in some stage of development of a CBDC. Nine countries have launched one at this point. The Bahamas was the first. It launched the sand dollar in October 2020. The Eastern Caribbean Central Bank launched something called D-cash in March 2021 and that covers multiple countries. The ECCB as the bank is called operates for eight member countries, seven of which have adopted D-cash. That includes Antigua and Barbuda, St. Kits and Nevis, Montserrat, Dominica, San Lucia, St. Vincent and the Grenadines and Grenada. Of the ECCB countries only Anguilla has not fully launched the cryptocurrency yet. And the most recent launch was the Enera in Nigeria. That was in October of last year. So India, if it did launch on day one, would be the fourth bank to launch one. They probably won't launch. They'll probably go into a pilot like I said. But there are three banks covering nine countries that have launched one. You might say like, wait, I thought China did. China is the biggest currency that's in the pilot stage. Also in the pilot stage are Anguilla for the D-cash, Jamaica, Sweden, Lithuania, Thailand, Saudi Arabia, South Africa, the United Arab Emirates, Ukraine, Hong Kong, separate from the digital Yuan, Malaysia, Singapore, and just at the end of January, South Korea finished phase one of its pilot and started phase two. So those are countries that have a digital currency out there that some people can use, but it's not fully launched yet. Of the rest of the world's biggest economies, Japan, Russia, Australia, Brazil and Canada are in the development stage. So they've got something under development, but it isn't even in the pilot stage yet. And the US, UK, and most of the EU, with the exception of the previously mentioned Lithuania, are in the research stage. That's where they're writing papers about it, but they haven't actually started developing one. So I have a question. The idea of a crypto, and it's not really a traditional cryptocurrency. I don't know if a lot of people know that or not. Yeah, it's just a digital currency. And it may be backed by some of the cool technology that cryptocurrency is benefiting from in terms of security, but it's not quite the same. They're not mining coins or any of that. So is the idea here that if you have a digital currency backed by a government that that automatically, not automatically, but maybe helps ensure that it's less volatile than say, you know, cryptocurrency, as it currently stands, Bitcoin is well, they're gonna be less volatile than that. Yeah, I would say I would assume so, right? Tom, like, is that the idea would be it's only as volatile as the currency it's based on. So a digital dollar in the US would be as volatile as the actual dollar, which is very volatile at all. Israel tied to fiat currencies. Exactly. Yeah, these are central bank digital currencies. Now, sometimes they're issued in a different way. Depending on how how they're operated, there's different developments. But but mostly they are backed one to one by the currency of that same central bank. And the other thing I didn't realize is the the main advantage here isn't blockchain. In fact, some of these in development, don't use a blockchain, they actually use a central database that you may go like, Well, how is that different than right now? And I just, you know, spend money with PayPal, and I never actually see the money. In those cases, every dollar, let's say for simplification, every dollar you spend has a dollar somewhere that represents it. With a digital currency, it wouldn't. And so with a digital currency, you need some extra technology to make sure that that's not replicable, that you can't alter that record that each digital coin is unique from the other, they may be fungible, you know, they may be replaceable for each other, but that it's that you you are safely keeping the number of coins in the system limited and you know how many they are and who has them. Blockchain is very good at that. That's why blockchain is used for this, because it's very efficient, and it's good at handling a unique digital thing. That's why NFTs are popular on blockchains. But some people, some countries are doing it with just a database that they they're trying to say, Well, we'll keep this database distributed, we'll have multiple copies of it, and we'll keep it extra secure. So I was surprised to learn that not all central bank digital currencies use a blockchain, although most of them do because their advantages to keeping that system. But the thing that's similar amongst all of them is none of them need an actual physical object backing them. Yeah, and you need the I guess the important thing here is if you're backed by blockchain tech, or if you're backed by whatever distributed database you're going to use, the point is you cannot make it easily manipulatable. Yeah, you can't replicate that money. The same reason that we keep redesigning our paper money. So it's harder and harder to do. Right. Same thing. So I'm personally ready for this. Let's go. I am too. I really feel like the the the situation where this would not go well, is if this became the only option, and then you have a bunch of people who don't have mobile phones or otherwise aren't able to participate in digital currency, not happening anytime soon.  And it's a real big country and a lot of, a lot of people there. So I, I know that people aren't going to be cut off from cash, the rupee in this, in this case anytime soon. But it is interesting to like, where do we get, how do we get to the point where this is just what money is? And we all remembered, you know, putting things in our wallets. Yeah. And there's lots of ways to do this. If you're thinking about like, well, not everybody has a smartphone. Well, a whole lot more people have smartphones than you, than you might think. There are also ways to use digital cards to handle currency this way. And one of the big advantages to a central bank digital currency is it makes it easier for someone to just have digital currency without having to open a bank account, because opening a bank account requires a whole lot more things like an address and a financial history and stuff like that. You, you can create digital wallets much easier that are secure without having to need to bring in the whole bank infrastructure into it. Hey, folks, what do you want to hear us talk about on the show? One way to let us know is our subreddit. We look at our subreddit every day and see like, well, what are you all interested in? We're going to take that into account, submit stories and vote on them at DailyTechNewsShow.Reddit.com. Game company acquisitions have really out of year in 2022. They're not closed yet, but Microsoft has a deal to acquire Activision Blizzard. Sony has a deal to acquire Bungie. Epic already owns Fortnite. And those three facts led the verges, Tom Moore, and to conclude that we're heading for a platform war, not of consoles, not of hardware, but of virtual worlds. Microsoft, if this goes well, will have Minecraft and Warcraft. Sony might have Destiny. And of course, Epic has Fortnite. Sony backed that up a little on an investor call saying that it plans to launch more than 10 new live service games by March 2026. They're buying Bungie for its expertise and technologies in order to do that. Scott follows this space closely, of course. And now that we've had a few days to digest and hear these comments from Sony, Scott, where do you think all of this is going? Well, it's interesting. When the news dropped about the Microsoft acquisition of Activision Blizzard King, my first impression was, oh, okay, well, they're just doing the let's get everything under one umbrella so we can control as much of the space as possible. We've already got a good install base for our subscription service. And I kind of saw that as the place. And when I would see headlines that would say Microsoft bets big on the metaverse by purchasing ABK, I was taken aback by that and kind of annoyed by it because I thought, well, that's not what they're doing here at all. This has nothing to do with quote unquote the metaverse, no matter how you're defining it. And that's the other problems. No one really knows how to quite define it yet. But I've given that some more thought. And in the wake of the news that Sony is interested in buying Bungie, I'm more convinced than ever that while Microsoft might have taken a scattershot approach to this. And I don't just mean this buyout, but like their Bethesda buy all these separate individual publishers and people that they Bob Mojang is a good example. All those guys, they did that in a way to yes, capture as much with one big net as possible. So you've got all of this meat back here. But ultimately, that does push them forward in being a leader in a potential quote unquote metaverse, whatever that ends up being defined as or what, you know, what we end up getting. And the Sony acquisition, some of the same things were said in different headlines and articles. And I was a little more, okay, interesting. Let's see where this goes, because I actually think the overpaid for Bungie. If you're just going to look at what Bungie is today. Today, Bungie is the studio that made all the Halo games, but they don't own those. Not even the old ones. Microsoft owns all that stuff. So what do they have? They have Destiny one and two. When Destiny one is essentially dead, Destiny two is their active running game. It's a very popular game across all platforms and was like sixth most played game on Sony service, I believe last reported.  But really, if you look at it just as what did they get today, they get a big name with a lot of cred. Everyone loves Bungie and they know how to make great shooters, but they really get one game and then whatever little secret thing that might be working on next, which is called matter. By the way, we don't know exactly what that game is, but there's a lot of talk about that. Anyway, then I started to think, well, OK, well, what if this is a more forward thinking purchase? If you're going to make worlds that are first person, potentially VR, potentially not potentially both like a combination of how I get into this world doesn't really matter what interface I'm using, I'm just getting into it. Who better that to have than somebody who knows how to construct and flesh out these 3D worlds in ways that is really kind of top shelf. And that's Bungie for sure. So now that that high dollar amount doesn't seem as high to me. I think maybe that's what they're investing in. And if they really are going to have 10 live services a game or live games as a service style games slash experiences ready by that date. That tells me that this is a huge cornerstone to that effort and they were willing to pay, you know, top dollar for that kind of talent and the kind of management, the kind of the kind of people they have over there. So if this rumored IP matter got Sony's attention and they probably got it from a few ways. I mean, the only way we know about it is an art direction job posting, which said, are you are see are you on a mission to create games that bond players together into deeply into invested communities? Would you like to work on something comedic with lighthearted and whimsical characters? That'd be a departure for them. But anyway, whatever that all of that means tells us they've got something that's big that social that is potentially aimed to be an answer to things like Fortnite and other, you know, other sort of quote unquote metaverse experiences. I spent the last two weeks in and out of speaking of meta, the actual company metas slash Oculus's world world that they're building called Horizon Worlds. And it's in beta. It's available in Canada in the U.S. I think it's still sort of dependent on who you are if you get access. But I've been in there for a couple of weeks, talking to various people, including some game developers and some folks at meta. And that'll all come out later with some other stuff. But the big takeaway while spending my time in there was that everybody meta included and maybe foremost are really hungry to be the space, not to be the game or not to be the collection of games or whatever, but to be the place where everything happens. And that means games within games, worlds within worlds, connected worlds to other connected worlds within those worlds, literally the metaverse. And it was clear to me how I mean, they really want it. And they're in a good position to, you know, they're in a bit of a lead right now on the VR side. I think they all are thinking this. I think Microsoft wants that real bad. I think Sony wants it really bad. And after talking to a few of these people, including ex Naughty Dog founder Jason Rubin over the week, it's very clear that this is the holy grail and next step for not just tech, but for the gaming business in general.  He's head of play at Oculus, by the way, that's his title. And this is a guy who founded one of the most successful devs of all time. He doesn't even need to be there, but he has enough passion for it. And I could tell in his voice how stoked he is about the idea of this being the place. Now, whether it's their place or somebody else's place, they also said we'd love to see more interoperability between these spaces and places. But this Sony acquisition to bring it back home, of course, all about that. All companies could be like, oh, we hope we hope to have that. We're not going to help you do that. Yeah. I mean, maybe, maybe not. Wouldn't that be nice? I think they need to personally if this is all going to work, but or at least work in the way that the hot the pie in the sky is being described to everybody. Oh, it will. Someone will do it and the companies that resist it will lose out. I agree. If you're not interoperating, you're losing. You're going to lose this because it's just the internet. Yeah. And hearing you hearing you talk, Scott, I really do think that the way this might evolve is people go to games and start hanging out doing other things. I mean, we've seen that in things like League of Legends and World of Warcraft, etc. Where people just they go for the game, but they stick around and hang out and chat and do other things.  They come for the game. They come for the open world, but they start sticking around for other things. And it's when where those other things start to merge with other companies things that it becomes the metaverse will see will see if and when that happens here. But I don't feel like Facebook, aka meta has an advantage on the software side. You have an advantage on the hardware side. Right. If they're going to if they're going to be a player in this, they just need to be the way people access it. Not. I don't think anyone's going to come there. We have never seen people go to Facebook to play games. We've never seen people go to Oculus to play Oculus's games. They go to play games in general. So yeah, I think it's the people with the content, the Microsofts, the Sony's who have the early lead on this. Yeah. And the way I look at it, I don't know if this is if my quote is going to last the test of time, but they all talk metaverse, but they really mean our metaverse when they say it goes back to service point. Yeah. So that interoperability is still a little bit of a far away thing. I think we'll get there. But back to Sony for one quick point, they had a thing for PlayStation three that took on some popularity called PlayStation home and they ended it kind of unceremoniously and not that far into its lifespan. But a lot of what they're talking about wanting to do are a lot of what all of these companies are talking about doing. A lot of those ideas were happening in PlayStation home and it was a lot like for, you know, second life and second life is maybe in some ways the grandfather here. But but there's no doubt in my mind that if Sony has a plan moving forward, it isn't just to match game pass. It isn't just to match some install days or or who owns what developers and how many games are they making? I believe now more than ever this acquisition and others like it are all intended to say, we want to be the next place that people come and hang out regardless of what games are here. That's the platform now. It isn't that box anymore. It's whatever this is and and they all want it. I might watch for Sony Microsoft Epic to partner with a decentral and to partner with one of those more second life, maybe even second life itself, like companies as like, you know, this is our this is our backyard. You may come to play destiny, but you'll head over to the decentral and to hang out and we've partnered and interoperated. Maybe that's where we see the beginning of interoperations because you're basically the big guys right with with these newer companies. You're basically saying the internet, but this and I agree 100% the internet was never going to stay in AOL's backyard. It was never going to stay there, but they wanted it to, but it didn't and they may as well get used to that idea right now or else this is all the lost cause it needs to be there needs to be at least that common public square and we can all run off and do cool stuff, but let's interoperate in that way. And now now you're talking and also that's when core gamers start to listen. All right, real quick. Just just something to keep an eye on live stream stream live stream shopping huge in China, big parts of Asia growing fast in the US. A possible rising star to keep a look out for is whatnot. It's a formerly LA but now Phoenix area startup valued at $1.5 billion is expected to expand its workforce from 120 to 300 people by the end of this year. And to that end whatnot just acquired pastel labs in order to acquire the services of former Pinterest growth advisor Jeff Chang, he'll focus on expanding the creator slash selling side of the business. What not also just hired away lifts head of growth and engineering Ludo Antonov who will become what not's head of engineering. So what is it? What not is a combination of YouTube and eBay for lack of a better comparison or for older folks think of it as QVC meets Twitch creators develop an online live streaming persona that folks enjoy following and then sell them stuff. What not started as a funkel pop enthusiast marketplace but has expanded to people selling all kinds of collectibles, sports and game cards, toys, comics, vintage games, sneakers, vintage fashions, LP, final records, stuff like that. I mean, the idea of this is not unlike when I walk into a physical store and go, I really like the vibe of the store. I'm probably going to get something today. It's the same thing. Sure, it's digital virtual rather, but well, and digital probably for however you're paying for whatever. But yeah, this is the this seems to me like just the the gradual progression of how we all sort of like something how it's presented. How are you selling this to me? And and a lot of folks online have have reaped the rewards. Yeah, you see this stuff like on TikTok all the time, somebody's entire account is dedicated to I just got these in and I'm wearing them now and I love them. And then you have this option to say, well, I'm going to go find those two and buy them. This integrates those two aspects of that and says, oh, you're wearing them right now and I'm buying it right now.  And if you like the creator, you don't mind being sold to. Right? That's that's the key. You're there. You want to be there. Patreon comfy merch hoodie and drinking out of a Patreon. It's true, a lot of people would be like, what? I'm going to sit there and watch somebody sell something to me. What about all the people who watch KVC? You know, Home Shopping Network? I mean, let's let's let's get real here. You don't have to. But if you want to and you like the folks that you're interacting with, I'm using quotes, then this it makes perfect sense. Yeah, one of the next big apps following on from TikTok might come out of this space. Keep an eye on it. Well, we wanted to thank a very special patron today, who has been with us for some time, and that special patron is Lynel Lane, who happens to be my mother. Lynel Lane is one of our top lifetime supporters for DTNS. Thank you for all the years of support, mom. Thank you, Sarah's mom. Yay. I just I mean, we love all of our patrons, but this particular patron is my favorite. It was her turn on the list. We didn't have special treatment. Yeah, there's no yeah, we're not cooking the books here, guys. This is just she's just a supporter, mom. Also, I didn't know that you had supported in that fashion. Thank you so much. Wow. Also, thanks to Scott Johnson for being with us today, Scott. What have you been up to? Oh, man, part of what's been keeping me so busy has been all this VR stuff, but also in a weird way, the opposite. I've been talking about retro games for the last five weeks and doing it on a brand new show called Play Retro. And I am having such a great time. I'm so obsessed with things. I started buying different controllers and reviewing them for how you're going to play your old games, playing those old games and VR, what it's like to grow up in an arcade family. And my dad ran arcades. If any of that sounds interesting to you and you want to get your nostalgia on, check out Play Retro or every get your podcast or you can check us out on the site over at frogpants.com slash play retro. Excellent. Well, just a reminder to everybody, if you want to join us live, if you can, we are live Monday through Friday at 4 30 p.m. Eastern. That's 21 30 UTC. Find out more at daily technewshow.com slash live and we're going to be back tomorrow doing it all again. Just over young. This show is part of the Frog Pants Network. Get more at frogpants.com. I'm in the club. Hope you have enjoyed this program.