So, welcome, Kristi and Michael. Hello, everybody. I'm Kristi Wilson. I'm a senior developer at Demonware, and I'm the team lead of the Test Tools team. And I'm Michael. I'm also a developer at Demonware, where I focus mainly on test automation and general quality stuff. And we're also from Canada, by the way. So first, a bit about us. We're both from Demonware. We work in the video game industry. We do online services for those video games. And if you want to learn more, come see us in the vendor area afterwards. Today, we're going to take you on a journey. It is one of the many tales in Commander McFluffles and the quest for quality. Today's tale, once upon a system test. There are many stops along the commander's journey. The tale starts in 2011 at Demonware, where testing needed improvement. Before the commander could improve testing, the commander had to learn what testing was. With that newfound understanding, the commander could understand some tomes containing best practices for system testing. And the commander picked up a couple allies along the way. Pi test and Dockerpi. Before we go, we want to give you some practical takeaways that hopefully you can use right away, that are tailored specifically for people who do more development work or more operations. So on with the story. So we're going to start the commander's journey by going over the current state of testing at Demonware. So back in 2011, we had just a gigantic, monolithic platform. I mentioned that we did services for online games. What I didn't mention was that it's actually one gigantic service. And in order to test our features in this gigantic service, we would do things like test and production or test manually in our local development environments. And we even tried to ease the burden of spinning up new test environments by making really complicated bascripts that were really unmaintainable. Now it's 2016, and Demonware has caught up with the microservice craze. So instead of having one monolith, we have a whole bunch of microservices with complicated dependencies between them. The sad thing is it turns out it's actually easier to test the monolith than it is to test the microservices. So to deal with this additional complexity, we now have a team dedicated to test tooling. And instead of relying on just unit tests, we have unit integration and system tests. So to go on with commander's journey, next they had to find out what testing actually was. But we actually found it very difficult to define testing in that way. So instead, we're going to focus on why we do test instead. So why do we test? First and foremost, we test in order to increase our own confidence that our software actually does what we expect it to do. When we write a test, we're actually codifying the intended behavior of our application in code. And so we can go back, and it's a good way to see as our software evolves how it's supposed to work. And also, as we continue to run these tests, we can easily catch bugs that maybe are reintroduced as time goes on. We also want to clear up some common misconceptions about testing. Some people think that we test in order to find all of the bugs in our software, but it's actually pretty much impossible. No matter what you do, there are going to be some bugs that you don't find. The only bugs you're going to find are the ones that you already know how to look for. Yeah, so to illustrate this, you see behind the commander there is a pink bug with a bleeding heart. For those of you who don't know, that's the Heartbleed bug. And as Christie was saying, it's unlikely that we'll actually be able to catch this bug before it affects us, just because when we write our tests, we already have the bugs in mind. And as you can see, it's conveniently placed behind the commander's gaze. Another misconception about testing is that testing improves the quality of the software. The tests themselves don't actually improve the quality of the software. By the time you run the test, the software already has whatever bugs it's going to have. If you want higher quality software, the place to do that is during the requirements gathering or the design. But testing gives you information about the quality of your software. And software that isn't tested is usually viewed as lower quality because there's less information available about it. So time for example. Suppose we have a simple service. Let's say it's a cat matchmaking service to go with the cat theme. And the goal of the service is to help cats find other cats to play video games with. So the cats themselves will talk with the service using a client library, and the service itself will store state inside of a database. So how should we test this? As we alluded to before, ideally you have at least these three types of tests. Unit tests, integration tests, and system tests. So unit tests. We're going to use unit tests to provide almost 100% coverage of the library and the service itself. Unit tests are the fastest tests to run, they're the easiest to write, and they're the easiest to maintain. So we're going to cover pretty much everything with unit tests. We're going to shoot for 100% coverage. We're probably not going to make it because it's not really reasonable, but we're still going to go for it. We also have some integration tests. In this case, they will test the interaction between the service and the database. Because up until now, we've been testing each of the components of our service in isolation. And now the system tests, which is the main thing that we're here to talk about today. So system tests test the entire system from the perspective of the end user. They're the most valuable tests because they actually use your system the way the user does, and they're the most likely to find bugs. On the other hand, they're the hardest to write, the most complicated to run, and the slowest because of all the setup that's required. So for our cat matchmaking service, we're going to rely mostly on the unit tests and the integration tests to do our coverage. We test all of our tiny, well-factor components with unit tests. We cover the gaps between the service and the database with the integration tests, and then we add just the sprinkling of system tests, just a couple happy path tests, and maybe a few error cases. So with the commander's new found knowledge of testing, they were finally able to decipher those ancient tomes that they just found laying around. The tomes were riddled with phrases like ship it and docker docker. While the commander was taken aback by this arcane terminology, our intrepid hero carried on anyway, and in the process learned about some best practices for system testing, so the best practices. The first one is that you should be giving your tests a fresh test environment, like whenever they run. This will help avoid dependencies between your tests. So for example, it should not matter what any individual test does because you get a new environment for each test, right? And as we'll see in a bit, if you have a dockerized environment, it makes it even easier to achieve this ideal of having a fresh test environment. It's also important to make sure that your tests can easily run both on your build servers and locally. So you want them to be on the build servers so that the continuous integration is making sure that they work over time, but you have to make sure that if there's a problem and somebody needs to debug something, they can really easily run the test locally as well. Another important detail is to restrict the environments that you support. If you start using docker, you might be under the impression that docker runs the same way everywhere, but it actually runs very differently, say if you're using Ubuntu or if you're using something like the docker beta for Windows, it actually behaves quite differently. And then if you allow people to use all of those environments, you end up supporting a lot of obscure problems that are just specific to their environments. So it's more best practices. As I mentioned, your test should be running on a fresh state, but they should also be cleaning up after themselves, right? Because for everything that your test leaves running after it's completed, it just puts extra burden on the person actually doing the testing, and will probably make them less likely to run your test in the future, or want to run your tests. Additionally, your tests should both fail fast and informatively in order to reduce the time it takes to identify a problem and also to react to it, overall tightening the dev cycle. Just a quick note about Glue Code. If you're writing really well-factored tiny bits of functionality that do one thing and do one thing well, at some point, you're going to have to bring all those things together somewhere. We often refer to this as Glue Code. So this example code here is just using a bunch of other modules and calling into them. If you've written unit tests before, you know that if you want to unit test this, you have to create a whole bunch of mock objects, and then you have to sort of model these complicated dependencies between them. The test that results from that is often very hard to write, it's really hard to maintain, and it doesn't really add anything. So for this kind of code, we recommend skipping the unit tests altogether and just covering it with system tests. So as the commander went along their journey some more, they came across two allies that promised to help make system testing a lot easier to do. The first ally was PyTest. So for those of you who don't know, PyTest is an alternative Python testing library. This is in contrast to the built-in unit test library in the Python standard library. You'll see that when you write tests with PyTest, you'll find that there's less code overall, they're very minimal, but also PyTest comes with a lot more features built in by default. However, they are optional, so you can use them whenever you'd like to or if you'd like to. The main thing we'll be talking about today is PyTest fixtures. In PyTest, a fixture is simply a nice way of defining some setup and some teardown logic for some state that your test requires. And PyTest will ensure that the setup and teardown are called in that order for each of your tests, which is very important. And as we'll see, when you system test, you generally need to set up a lot of states, right, because you might have a really complicated application that you're testing. So, time for example. So on the left here, we have two green boxes. These are the setup and teardown for the fixture, and on the right, there's a test. I mentioned that PyTest will make sure that setup is run before your tests and teardown after your tests. And by default, it'll actually do this for every single test you write. So it makes it very easily, easy to achieve that clean state ideal. You can also change when PyTest will call setup and teardown. So in this example with the yellow fixture, the setup, instead of being called before each test, it's actually called once before any of your tests are run, and teardown is also called once after all your tests are run. And you can even actually combine these two together to create something more complicated setup if your application requires it. And now a little bit about Docker. At Demonware, our services are fairly hard to set up and run. So to make this easier, we put them into Docker containers. When we started to write tests that use these containers, at first we wrote complicated bash scripts that did the setup and the teardown, but it wasn't very maintainable. So then the commander found their next ally, Dockerpy. So Dockerpy is a Python library for using Docker. The interface, however, has a one-to-one mapping with the REST interface, so it's a little bit clunky, and I'll demonstrate what that looks like. So in pseudocode, I'm gonna show you some code that you would use with Dockerpy to create a client object, pull an image, create a container, start a container, and then remove a container. If you've used the Docker command line at all, but you know that steps two through four are usually just the Docker run command, but you don't get that same convenience with Dockerpy, and you have to be more explicit. So first, we're going to create the Docker client object. Also, if you're interested in using any of this code, there's a link at the bottom of all of our slides that goes to a GitHub repo that has all the example code in it. So especially when the examples get a bit longer, if you actually wanna take a look at it in more detail, just go to that URL. So with this example code, right off the bat, you can see that this would only work on a system that has Unix sockets. So restricting the environments becomes pretty important. The other caveat is that we're passing this flag to automatically detect the version of the server so that we don't have to keep the client and server in sync. Next, we're going to pull the image that we want to run. On the Docker command line, if you don't specify a tag, it'll default to the latest. The Dockerpy does not do this, and instead it will actually pull the entire repository. So you have to be explicit about the tag you want. Another caveat is that the Dockerpy will often not raise exceptions in cases that you think it would. You think if it failed to pull the image, it would raise an exception, but actually you have to parse that out of the response yourself. So that's something that's important to be aware of. Then we're going to create a container. The important detail here is that we're adding a special label to it. So what we do with our tests is we add the same label to all the containers that we start in our test, and then we can do some fancy things like dumping the logs from all the containers after the tests are over. Then we start the container, and then when we're done with it, we stop it and remove it. Yeah, so time for more concrete example of Dockerpy and PyTest working together. So I've replaced the generic set up and tear down in the green boxes with create container and delete container. And an even more concrete example, suppose that we have a web service which is indicated by the yellow box here that has no state by itself. It stores a state in the database somewhere. So we want to test that. So we'll spin it up once because it has no states, but it does store its states inside of two database containers, Redis and MySQL. So we're going to have a second set of fixtures which get set up and tore down for each individual test that will give us new databases each time. Here's an example of a simple PyTest fixture. This does what Christie was describing earlier. It creates the Docker client, starts the container, and then it tears down the container at the end. The main thing to note here, if you can see it, this is also in our repo is the yield. In the yield, we actually are returning the IP address of the newly started container. And it might not be apparent here, but we're actually able to use that IP address inside of our tests that uses this fixture. PyTest also has a very elaborate hook system which lets you modify the default behavior of PyTest. And we actually use this to dump the logs of all of our containers at the end of the test run. So this particular hook is the log report hook which is executed whenever PyTest wants to dump the test report somewhere. And in the event that the test run has failed, we'll actually want to go through each of the containers that have our special label and we'll dump out all of the logs from that to send our output. And we were pretty impressed by this. So if you've used Docker at all, you might be wondering about Docker compose. Could you use Docker compose instead? It seems like it gives you very similar functionality to what we're doing. So yes, you can. And it works really well, especially if you want to use exactly the same setup for every single test that you're running. So if the cluster of services you're running for each test is the same, Docker compose makes a lot of sense. If it's dynamic, if you're doing things like changing the volumes that are mounted or changing the port mapping or doing anything more complicated than something like Dockerpy, it makes a bit more sense. If you do decide to use Docker compose, it still fits in really well with PyTest fixtures. So you can have a fixture that does the Docker compose up and then does the Docker compose down. And then you can also use Dockerpy to inspect some of the containers and get information out of them if you need it. So this is another example of what that would look like. So this is a fixture that does a Docker compose up, then yields the IP address of one of the containers that started and then tears down the cluster. Again, the example code is up in our repo if you're interested in using it. We also encountered a few important gotchas along the way. One of them is that Docker has no notion of a service actually being able to receive requests. So sometimes tests will fail because the service in the container is actually still starting. So you can get around this by having an executable inside all your containers that you can call from the outside that says whether the service is ready for requests. And you can use backoffs. And there's a couple of Python libraries, backoff and retry, which make this really easy. It's also important to make sure that your containers start up as quickly as possible. Something that we've kind of learned the hard way. The slower the containers start, the slower the tests will run and the slower people get feedback on their code and the slower your development time will be and this will lower the overall quality of your software. So time to wrap it up sort of. So the commander has had a long and arduous journey but has gained a lot of knowledge along the way. So next they'd like to share with you some of the takeaways they've gotten for both the Dev and Ops perspectives of testing. So you might be thinking that was kind of cool, but what do I do with it? So we're hoping that we can give you some specific things that you could try when you're back developing. So if you do more development work, it's really cool to know how to write tests and writing tests is great, but sometimes it's also even more important to know when not to write tests. If you're going to use system tests, use them sparingly. That being said, if the next time you have a feature to develop, try some test-driven development. Try starting with a system test. If you don't have any system tests with the software that you're working on, try introducing one for each piece of software that you own. Make sure that it can run with as little setup as possible and that it runs as quickly as possible and then add it to some kind of continuous integration system. If you already have tests, take a critical look at them. Do you actually need all the tests that you have? Are some of them retesting functionality that the unit and integration tests already cover and can you remove them? And can you make them any faster? And the same things to apply to, do you opt-minded focus out there as well? First of all, you want to know why not to write system tests. So for example, you probably do not need them if you want to just test some one-off scripts, right? Because by their very nature, you do not care whether these one-off scripts keep working into the future. In contrast, if you do have tooling and other scripts that do need to work in the future, then yes, you should definitely have system tests. And you should start by having at least one system test which will exercise enough functionality in your tool to prove to yourself that it works. And as well as with developers, you should also run these regularly so they keep giving you value. Generally, for ops tests, they're like two categories. The first one is tests that involve services that you can run. So for example, before we had a fixture that starts with my SQL container, that's something that we can run locally. And for that, we recommend using something like the commander described earlier, which is PyTest and Dockerpy. Now, for tests that require things that you cannot run, like those in Amazon Web Services, for example, you can still use PyTest, but there are some questions you should ask yourself first. So for one, is it feasible to have a short test in this external environment? Is it gonna cost you a lot of money? And also, is it easy enough to clean up after yourself in this external environment so you don't run up excess charges or anything? And if you're comfortable with your answers to the questions, then yes, you should definitely run tests for these types of tools, but use them sparingly. So in conclusion, system tests are great. Definitely write system tests. Don't write too many system tests. If you have services that you can run in containers, try checking out PyTest fixtures with Dockerpy and or Docker compose, it works really well. So as the commander's tail comes to a close, they are very content with all the knowledge that they have gained across their journey and they're looking forward to bringing that knowledge back with them to their own castle. Thanks for listening. Time for questions. Hi, thank you for the talk, very interesting. I have a lot of questions, but I will try to do just one. When do you test?  Do you have dedicated environments? Do you test? Do you do system tests in the developers' machines? All non? Yeah, because for us, usually we try to test as much as possible. So while you're developing the feature that you're working on, you will run the tests. Ideally, you would catch any failures in the unit test stage because they're faster than system tests. But definitely, we want everyone to be running these tests all the time. And we have them run in bamboo, for example, all the time just to make sure that they're run. But ideally, your developers would also be running them too. So we have a team that's dedicated to our build infrastructure. So we've been using mostly bamboo. And we run all the system tests in bamboo on bamboo agents. And we're slowly migrating over to Jenkins now, using agents that run more in the cloud. But we're trying to make sure that these tests will run on developers' machines as well. Do you have more questions for the demonware booth later? Hi. So I'm interested in what's your ratio between unit tests, integration tests, and end-to-end tests. That would be the first part of the question and the second part. Why not only use end-to-end tests? OK. You want to do the first part? OK. So the ratio, I would say, so it depends on, this is more of an ideal that we're going for with most of our new software. We also have a lot of legacy software that is not, it's basically all unit tests that aren't really unit tests. But what we're aiming for is we'd have, say, like hundreds or even maybe thousands of unit tests to a handful of system tests, like 10, or less than 50 system tests to 1,000 unit tests, something like that. Basically aiming for that 100% coverage and then just testing some of the client-facing end points with the system tests. And for the second part of the question, which I believe was, why do you not just run system tests? So as you've probably seen, to spin up your entire software stack, it's very expensive a lot of the time. And it reduces the turnaround time for when someone's actually working on something, right, to test it and make sure it works. So that's why you want to use system tests sparingly, although you are right in that. They give you the most benefit because they actually use your software the way it will actually be used. So that's pretty, that's the bottom line really, is how much speed do you want to sacrifice? And usually what we'll do is we'll have more unit tests in order to catch things as early as possible because those are really fast to run before we get to system tests. The other thing is it depends on how many paths there are through your software. So if you have a lot of like branches and then those have branches, then covering all of that with system tests is basically impossible because of the number of cases you'd have to cover. But if you use unit tests for those code modules, you can make sure all of that stuff is covered and it might be completely infeasible with system tests. But some software is better suited for system tests, like we also write some software specifically for like automating, like testing and deployment. And for some of that stuff, we have pretty much only system tests and no unit tests at all. So it really depends. Hey, thanks for your talk. One question regarding data fixtures. So you spin up the containers, but how do you manage getting the data into those Percona or whatever you use for data stores to then be able to test the flow? So I think what we usually do is we have one fixture which spins up the database container and then a second fixture which depends on that fixture which will actually insert the data into it. And you can do that pretty easily with PyTest. So pretty much you just use Python to insert the data before you actually run your test. Right, so in our example fixture, we had it just yielding the IP address of the container, but before that you could do some other setup if you wanted to. And then some other, we can, if that is not fast enough, in some other cases we build, we have like a base image that has the database in it and then we will regularly build images on top of that that have the data that we need for the test in it. And then the test will just start the container that has the data it needs already. Thank you. I got a question. Have you tried this approach with virtual machines in non-dockerized environments, like background, vSphere? So are you asking if we've used it without Docker? Yes. I don't believe we have, although I don't see any reason why it wouldn't work. It just might be more expensive to spin up a whole new virtual machine versus a Docker container, but you could easily plug in something like Vagrant, I guess, in place of DockerPy in our examples. Or like Bottle for EC2. So I have a system that's actually pretty similar to that and I have this like small technical problem. My fixtures automatically download any images that you need. And I have this problem that you run tests and then nothing happens for like 30 seconds. Can I write a plug-in, pop up, turn my fixtures into a PyTus plug-in so I'm able to just pop a message? Yeah, because it's all of your streams, so that's the way? Or did you do something like that, actually? Or... I think your team did that, right? So we've also had that problem. I don't think we have a great answer for you. In some, a lot of cases, we have the logic so that if the image wasn't pulled, we pull it, and then we have, on our build agents, we have a previous step that will always pull the latest image, so it's not, and then we assume that when people are running it locally, they've sort of done the pulling themselves if they want the latest image. It's not a great answer, though. I think there's a lot of opportunity for somebody to write a really good library for using Docker with PyTest test fixtures. So if there was something like that, that would be great functionality to provide. But yeah, I would recommend looking at the hooks. There might be something that you can add, or maybe just output from the fixture itself, because you can always output anything you want.  Thanks. Any more questions? We got time. Thanks for the talk. It was very enjoyable. And my question is, how would you approach a situation when you have a kind of system you described earlier in the presentation, when it's a giant monolithic with very poor coverage, and it has only few system tests, but with very fragile? How would you solve the situation? Oh, you say the tests themselves are the fragile part? Sorry? You said it's fragile. Is it the system that's fragile, or is the tests the first? No, the systems are fragile because they're based on some hard-coded information. I guess for that, I guess you would start with system tests because you can use those to easily verify that your thing is still working. I guess that doesn't really address the flakiness. That's sort of an ongoing issue in the whole testing space. But if you start with system tests, you can test based on actual customer requirements. And then as you start to refactor and improve the rest of your code base, you can start writing unit tests and integration tests for those. But start with the system tests so that you know that your software is still overall working. For the monolith that we mentioned at the beginning of the presentation, what we have is we still have all of the legacy tests, which were kind of like a weird mix that would reach straight into the internals of the system and call things. So what we're trying to do for new services is we're kind of kind of isolate all of those old tests. And then for new things, write unit tests and write integration tests and write system tests. So kind of like slowly transition over to that and delete the old tests as we go. But it's not an easy solution. Hi, me again. So I'm interested in how do you handle tests that have a lot of dependencies and are extremely flaky? So are you just repeating the test if they fail like three times and then say, hey, that really failed? Or do we have some other cool strategy? So that particular strategy you mentioned of rerunning the test when it fails has actually caused us a lot of problems. So several years ago we started doing something like that. And because of that, the problems with the tests have kind of been mounting up over time. So at the moment, we're actually at kind of a crisis point where we have to do something serious about it because we've been ignoring these flaky tests for so long. So I would recommend trying as hard as you can to remove the flakiness, like change them to be as deterministic as possible. Often you can achieve that by going with the unit tests, like try to figure out how you can write unit tests that remove the, whatever it is that's flaky. Like it might be a random element or something about the file system or something time related. So use unit tests to control that part and remove that from the equation and then that sometimes makes the test a bit more dependable. But I would say definitely not the rerunning of the tests. Yeah, though there is actually a pie test plugin for rerunning tests automatically. So you could do that, but try this approach first. Last question. Thank you for the talk. I'm interested about the organizational way of testing it. How many tester developers do you have compared to the developers that are working on the project and how do they, I mean, interact, they jump? Yeah, so in general, I think we try to have the developer writing the new feature, actually writing the test as well, because they are the experts on the feature. I think in some cases we have tried to pair programming where someone else will write, let's say, the system test because that's less dependent on the internals and more about the general feature requirements. But usually we do try and have the same person write most, if not all the tests. We have about 120 developers in the whole company or engineers in general. Michael is the only one who is explicitly software engineer in test, and then I'm on the test tools team and there are four of us all together, so we work on the tooling specifically, and then Michael's trying to help some of the teams that have larger testing concerns. But in general, we're trying to encourage people to all be skilled in writing tests so they can write their own tests and deal with their own problems. Okay, so thanks.


Rather than cutting calories day in and day out, what if you instead just ate as much as you wanted every other day, or for only a few hours a day, or fasted two days a week, or five days a month? These are all examples of intermittent fasting regimens. That may even be the way we were built. Three meals a day may be a relatively novel behavior for our species. For millennia, our ancestors may have only consumed only one large meal a day, or went several days at a time without food. Intermittent fasting is often presented as a means of stressing your body in a good way. There's a concept in biology called hormesis, which can be thought of as that which doesn't kill you makes you stronger, principle. Exercise is the classic example where you put stress on your heart and muscles, and as long as there's sufficient recovery time, you are all the healthier for it. Is that the case with intermittent fasting? Or Twain thought it was? A little starvation can do more for the average sick man than can the best medicines and the best doctors. Not just a restricted diet, but total abstention from food for one or two days. But Twain also said, Many a small thing has been made large by the right kind of advertising. Is the craze over intermittent fasting just hype? Many diet fads have their roots in legitimate science, but over time facts can get distorted, benefits exaggerated, and risks downplayed. In other words, science takes a backseat to marketing. At the same time, you don't want to lose out on any potential benefit by dismissing something out of hand based on the absurdist claims of overzealous promoters. You don't want to throw the baby out with the baby fat. Religious fasting is the most studied form of intermittent fasting, specifically Ramadan, a month-long period in which devout Muslims abstain from food and drink from sunrise to sunset. The effects are complicated by a change in sleeping patterns and also thirst. The same dehydration issues arise with yom kapoor when observant Jews stop eating and drinking for about 25 hours. The most studied form of intermittent fasting that deals only with food restriction is alternate day fasting, which involves eating every other day, alternating with days consuming little or no calories. In contrast, we burn about a 50-50 mix of carbs and fat, but we usually run out of our glycogen or our carbohydrate stores within 12 and 36 hours of stopping eating. At that point, our body has to shift to rely more on our fat stores. This metabolic switch may help explain why the greatest rate of breakdown and burning of fat over a three-day fast happens between the hours of 18 and 24 of the 72-hour period. The hope is to reap some of the benefits of taking a break from eating without the risks of prolonged fasting. One of the potential benefits of alternate day fasting over chronic calorie restriction is that you get regular breaks from feeling constant hunger. But might people become so famished on their fasting day that they turn the next into a feasting day and overeat? I view 8 more than twice as much as you'd normally would than that presumably would defeat the whole point of alternate day fasting. Mice-fed every other day don't lose weight. They just eat roughly twice as much in one day. That non-fasted mice would regularly eat in two. That is not, however, what happens in people. Randomized a fast from 8 p.m. the night before to 8 a.m. the next day, fasting for 36 hours only led to people eating an average of 20% more the day after they broke the fast compared to a control group that didn't fast at all. How would leave them with a large calorie deficit equivalent to a daily calorie restriction of nearly a thousand calories a day? This particular study involved lean men and women, but similar results have been found amongst overweight or obese subjects, typically only about a 10 to 25% compensatory increase in calorie intake over baseline on non-fasting days. And this seems to be the case whether the fasting day was a true zero calorie fast or a few hundred calorie so-called modified fast day, which may lead to better compliance. Some studies found study subjects appear to eat no more or even less on days after a day-long mini-fast. Even within studies, great variability is reported. In a 24-hour fasting study where folks ate an early dinner and then had a late dinner the next day after skipping breakfast and lunch, the degree of compensation at the second dinner ranged from 7% to 110%. This means some got so hungry by the time supper rolled around that they ate more than 24 hours' worth of calories in a single meal. The researchers suggested that perhaps people first try test-fasts to see how much their hunger and subsequent intake ramps up before considering an intermittent fasting regimen. Hunger levels can change over time, though, dissipating as your body habituates to the new normal. In an eight-week study in which obese subjects were restricted to about 500 calories every other day, after approximately two weeks, they reportedly started feeling very little hunger on their slashed calorie days. This no doubt helped them lose about a dozen pounds on average over the duration of the study, but there was no control group with which to compare. A similar study with a control group found a similar amount of weight loss, about 10 pounds over 12 weeks in a group of normal weight, meaning overweight on average, individuals. For these modified regimens, where people are getting prescribed 500 calories on their quote-unquote fasting days, a researcher found that from a weight loss perspective, it did not appear to matter whether those calories are divided up throughout the day or eaten in a single meal. Instead of prescribing a set number of calories on fasting days, which many people find difficult to calculate outside of a study setting, a pair of Iranian researchers instead came up upon a brilliant idea of unlimited, above-ground vegetables. Starchy root vegetables are relatively calorie-dense compared to other vegetables, but vegetables that grow above the ground, including stem vegetables like celery and rhubarb, flowering vegetables like cauliflower, leafy vegetables like… well, leafy vegetables, and then all the fruits we tend to think of as vegetables like tomatoes, peppers, okra, eggplant, string beans, summer squash, zucchini. So instead of just prescribing a certain number of calories for their fasting days, subjects alternated between their regular diet and helping themselves every other day to an all-you-can-eat-above-ground-vegetable feast along with naturally non-caloric beverages like green tea or black coffee. After 8 weeks, subjects lost an average of 13 pounds and 2 inches off their waste. The same variability discovered for calorie compensation has also been found for weight loss, though. In a 12-month trial in which subjects were instructed to eat only one-quarter of their calorie needs every other day, weight changes varied from a loss of about 37 pounds to a gain of about 8 pounds. The biggest factor, differentiating the low-weight loss group from the high-weight loss group, appeared to be not how much they feasted on their regular diet days, but how much they were able to comply on their fast days with the calorie restriction. Overall, 10 out of 10 alternate-day fasting studies showed significant reductions in body fat. Small short-term studies show about a 4% to 8% drop in body weight after 3 to 12 weeks. How does that compare with continuous calorie restriction? Zero calorie alternate-day fasting was compared head-to-head to a daily 400 calorie restriction for 8 weeks. Both groups lost the same amount of weight, about 17 pounds, and in the follow-up check-in, 6 months later, after the trial ended, both groups had maintained a similar degree of weight loss, still both down about a dozen pounds. The hope that intermittent fasting would somehow avoid the metabolic adaptations that slow weight loss or improved compliance don't seem to have materialized. The same compensatory reactions in terms of increased appetite and a slower metabolism plague both continuous and intermittent calorie restriction, and the largest longest trial of alternate-day fasting found that may even be less sustainable than more traditional approaches. By the end of the year, the dropout rate of the alternate-day fasting group was 38% compared to 29% in the continuous calorie restriction group. Though to date, alternate-day fasting regimens haven't been shown to produce superior weight loss. For the individuals that may prefer this pattern of calorie restriction, are there any downsides? We'll find out next.


Hi, I'm Leonard Waters, and together with Jan van den Herderwegen, we will present our work titled, Dismantling DSD-AT-Based Immobiliser Systems. This work was a collaboration between the Centre for Cybersecurity and Privacy at the University of Birmingham in the United Kingdom, and the Coastal Research Group at the Keeleurven University in Belgium. Jan is going to start his presentation by explaining what an immobiliser system is exactly, and how it is used to prevent thieves from stealing your car. So, what exactly is an immobiliser? It is the main anti-theft measure in any modern car. Before they were in place, a criminal could so-called hotwire your car, which is when they touched the ignition wire and the main voltage line, and then that would start the car. Now, with immobilisers in place, when the key fob is inserted in the ignition barrel and turns, the immobiliser cryptographically authenticates the key fob and only when it has been previously paired to the vehicle, then it sends on a signal to other ECUs or control units in the car, which then finally can start the car. Since the immobiliser is the main component of this system, we decided to look more into what exactly it does and how it does this. To achieve this, we've looked at immobiliser ECUs made by Toyota and ECUs made by Kia and Hyundai. This is the Toyota DSTAT immobiliser ECU opened up. So, as you can see, there's the pin headers here, leading on to various components in the car. There's a small e-promptrip containing several bytes of data, and then finally there's the main immobiliser microcontroller here, which we have desoldered on this breakout board. We will explain later why. One issue we encountered with this particular PCB is that the serial number printed on the chip did not match any of our Google searches. That was because it was a serial number of the manufacturer that made the immobiliser ECU and not actually the chip number. So we had to kind of narrow down from all data sheets online based on the pinouts, so the voltage pins and the ground pins, and then finally also the resonator here, which helped narrow it down finally to the ReneSAS 78K0 microcontroller, which is an 8-bit microcontroller. So this ReneSAS chip exposes a bootloader interface, which communicates over simple serial protocol UARTs here, and by pulling this pin high on reset, we can make the chip enter a boot mode, which exposes certain functionalities such as rewriting flash sectors or erasing the chip or separate flash check sectors. However, it also incorporates a protection mechanism to prevent exactly that, and since this protection bytes with each bit indicating a separate level of protection was completely set, we had to resort to voltage glitching, which is a technique where we control the voltage line, and by inserting small glitches or anomalies in this voltage supply, we can, for example, skip the instruction where it checks the protection bytes. So our setup for this is as follows, we're using the giants of which you can find the source here to insert the glitches, and then we use a raspberry byte to interface with the bootloader on the one hand, and on the other hand to control the giants through USB. So through this bootloader interface, we were able to send a command which sets a new security byte, so where we can disable all security bits, and by inserting a glitch when it checks that this byte is allowed, we managed to revert the security bytes. So that gave us right access to the chip, and then finally, we could override the boot sector of it, and with a simple program that just dumps the firmware over UARTs, and then finally, we obtained the immobiliser firmware. Once we had this immobiliser firmware, we were interested in finding out more about DSD80, of which little is publicly known. So it's a successor of DSD40, also manufactured by Texas Instruments, and a immobiliser shifer reverse engineered and attacked by Bono et al in 2005. They showed that with a cluster of FPGAs, they could brute force a 40-bit encryption key. DSD80 is based on the same authentication protocol, namely the immobiliser generates a 40-bit random challenge, and then sends it on to the transponder, which in turn calculates a 24-bit signature and a 16-bit block-checked character based on a shared secret key. This secret key is split into 40-bit chunks, namely key left and key right. So this is the result of our reverse engineering efforts. What you can see here is the standard DSD40. So a 40-bit challenge response register is initialized with the 40-bit random challenge, and then the cipher runs for 200 rounds. In each round, a round key is put along with the challenge response register through a fysal function F, which consists of several lookup tables, F, G and H, and then finally results in two bits, which are subsequently fed back into the challenge response register. The round key is derived from two key registers, which are both 40 bits. So key left and key right are both LFSRs with depth bits on these positions. So every round, these shifts by one bit, and then the round key is just derived by taking 20 bits of the left key and then 20 bits of the right key. Unlike DSD40, where only every three rounds, the round key is added in the ST80 that's done every round. Once we had this DSD80 cipher reverse engineers, we wanted to see whether we could practically attack these DSD80 systems. The result of this is two attacks based on weak secret key generation and several attacks based on transponder configuration issues. First of all, we noticed that Toyota mobilizers read out the serial number and two separate pages from the transponder memory, and then put this through some function, which then finally generated the 80 bits secret key. This was then put along with the 40-bit random challenge in the ST80 and resulted in a response. Since this is quite a strange setup, we decided to look more into how exactly this key diversification works. So we reverse engineered this key diversification procedure from the immobilizer firmware. Every DSD80 transponder has this particular memory layout, namely there's a transponder ID, then there's several pages of user data, which you manufacture and program, and then, of course, there's also the 10 bytes encryption key. We found that the immobilizer initializes a 40-bit state with three bytes of the serial number and then two 1-byte pages of the transponder, which are all publicly readable, so they're not protected, and then puts this through a proprietary cipher, which finally spits out the 80-bit encryption key. The only entropy in this cipher comes from a secret stored in the firmware, which is basically 15 bytes. And, of course, the initial state, but that doesn't add any entropy since it's all publicly readable information. So we realized that the secrets are identical across all firmers we looked at. So actually, once you know the proprietary cipher and these secrets, that means that all you need is the transponder ID and these two pages, and then you can derive the 80-bit encryption key from that, completely breaking the security in Toyota DSTAT immobilizers. The security analysis for Kia Hyundai immobilizers was slightly different. First of all, since the STM8 microcontroller, which controlled the immobilizer ECU, was unlocked, we were able to just connect to the debug interface and read out the flash and eProm memory straight away. Immediately, we realized that the DSTAT keys were stored in eProm, and after dumping them, the immobilizer firmware of several ECUs, we realized that four bytes in the secret keys are always the same. So that reduces the entropy from 80-bits to 48-bits. Then after further investigation, we realized that the three remaining bytes from key rights are just the inverse of the bytes of key left, further reducing the entropy to 24-bits, which is easily brute-forceable offline. So again, all we have to do is wirelessly communicate with the transponder ones, from which we can get two challenge response pairs, and then finally brute-force the 24 remaining bits to obtain the 80-bits encryption key. Now, Leonard is going to explain the transponder configuration issues we found and also several side-channel attacks on DSTAT transponders. After looking at manufacturer-specific vulnerabilities, we also want to cover general issues that can occur with these DST immobilizer systems. As Janus touched upon earlier, each keyfab contains a transponder chip with eProm pages that stores certain information. These pages are used to store configuration of the transponder and the cryptographic key, but they can also be used to store manufacturer-specific application data. For example, some manufacturers will use these pages to store information about your car's maintenance schedule. Each of these transponder pages can be individually and as far as we can tell irreversibly locked. This means that the data stored within these pages can no longer be overwritten. As it turns out, not all manufacturers lock these pages properly, which can lead to some interesting scenarios. For the first scenario, we assume that the manufacturer correctly configured the keyfab to perform DSTAT and that the key has been configured and locked. However, we will assume that the configuration page was left unlocked. In this scenario, an attacker can use these misconfigurations to their advantage by communicating with the keyfab over low frequency. You will first override the configuration of the transponder, such that it performs DST40 instead of DST80. As it turns out, the transponder will now produce a DST40 response to provide a challenge and will use half of the original DST80 key to do so. This means that the adversary can recover the DST40 key in a few seconds using a lookup table, after which he can revert the configuration of the transponder to DST80. He can now obtain some extra challenge response pairs to brute-force the remaining 40 bits of the key. In the second scenario, we will assume that the manufacturer left both the configuration page as well as the page containing the cryptographic key unlocked. The adversary can again modify the transponder's configuration to force it to perform DST40 instead of DST80. As with the first scenario, he can now recover 40 bits of the full 80-bit key using a first lookup table. After doing so, he can also override this 40-bit key to a known value. The ability to override half of the key allows the adversary to use a second lookup table to recover the second half of the key. To that end, he will change the configuration back to DST80, enabling him to recover the second half of the key. Knowing both halves of the key, the adversary can also reprogram the transponder, leaving no trace of his interactions with the keyfob. While some of these scenarios might sound artificial, we found that the second iteration of the Tesla Model S keyfob to be vulnerable to this exact scenario. Finally, we consider the worst-case scenario from an attacker's perspective. The manufacturer locked both the key and configuration pages. As it turns out, certain DST transponder packages contain an SPI interface to which you can still ask your transponder to confirm DST40 operations instead of DST80, even if the transponder is configured to perform DST80. If the adversary has short-term physical access to the keyfob, this scenario can thus be considered equivalent to the first scenario. The adversary can recover the key in two halves. The first 40-bit key can be recovered using a lookup table, and the second half can be brute-forced. Depending on the package type that is used, the adversary requires a few extra steps. A discussion on the exact steps that would be required is provided in the full paper. If all else fails, an adversary might want to apply side-channel analysis to recover the transponder key. In the paper, we cover both the differential power analysis attack, as well as a profiled attack on the key loading procedure. In the interest of time, we will only cover the profiled attack during this presentation. Our goal for this attack is to profile the secret key being loaded from the non-volatile storage to the DST-hardware accelerator. We observe that the key is loaded byte-by-byte on each invocation of the cipher. The strategy is thus to create a profile for each key byte from many side-channel measurements in which the cipher is invoked using different secret keys. During the attack phase, the goal is to recover the secret key using the generated profile and a few side-channel measurements. Most works which target key loads cover artificial scenarios or only consider the worst-case scenario in which the profile device is also the device under attack. In the case of the DST transponders, this worst-case only occurs when the key is left unlocked, a scenario we have previously shown to be vulnerable to a downgrade attack. In this work, we target a real-world device and consider the portability problem in which the profiling device and attack device are different. Difficulties in attacking a different chip during the attack phase stem from variations in the chip production process as well as variations in the measurement conditions. Before building a model, each trace is subjected to a pre-processing methodology. Each trace is aligned to a reference trace on the peak marked by a red diamond. Because all of the measured transponders use an unstable internal clock, it is difficult to perform alignment, especially across multiple target chips. To obtain aligned traces, we extract the marked peaks from each trace and stitch together new artificially aligned traces. While this step might not be strictly necessary when using convolutional neural networks, it is necessary to be able to apply more classical methods to identify the leaking samples. Additionally, it allows to significantly reduce the data complexity. After obtaining artificially aligned traces, we are able to identify regions of interest in the power measurements. In blue, we see the average trace for six different transponders chips. Light blue zones indicate the variation between the means of those six different devices. As can be observed, we identified regions of interest for each of the key byte values, as well as the distance between consecutive key bytes. In orange, we can see that there is at least some information regarding the intra-device difference. These areas were kept as part of the trace in the hope that they would help our model to generalize to unseen devices. Let's first explore the single device scenario in which we train a multi-layer perceptron model on a single device. Afterwards, we evaluate the model's performance when attacking that same device. Finally, we try to use that same model to attack a different transponder chip. The exact details on the used model and the training strategy are provided in the paper. Accuracy and loss are often not the best metric when evaluating a machine learning model in the side channel context. Therefore, we evaluate our models after each epoch by computing the mean rank over 256 attacks, one for each label using 50 traces. Each plot contains three lines. In green, we have the mean rank obtained on the training set. In orange, the mean rank on the validation set. And as you can see, in most cases, both the green and the orange line overlap, indicating that our model generalizes well for the same device. In blue, you can see the mean rank when trying to classify traces from a device that was not part of the training set. From these plots, it is clear that it would be trivial to attack the device that was profiled. However, using the same profile is unlikely to yield good results on a device not used during the profiling phase. In the multiple device scenario, the idea is to create a profile for the family of transponder chips instead of a profile for a single transponder chip. We train the same multi-layer perceptron model on traces from five distinct transponders. And initially, we evaluate this model by attacking traces coming from the same set of five devices. Finally, we try to attack traces from a transponder, which was not part of the training set. This experiment is repeated six times, each time using traces from a different transponder as the attack set. In total, we used six million traces, one million traces with random keys for each of the transponder chips. The details on the used multi-layer perceptron model, as well as the training strategy are provided in the paper. In orange, you can see the mean rank when attacking a transponder chip, which was part of the profiling set. In contrast with the single device scenario, you can see that certain target values are more difficult to attack. Nevertheless, the information gained from these could still be useful when using an optimized key enumeration strategy. In blue, you can see the mean rank when attacking a device, which was not part of the training set. This clearly shows a tremendous improvement over the single device model in at least six out of the nine targets. We provide additional details in the paper, but it turns out that using as little as 10 traces, we could reduce the entropy of the secret key from 80 bits to a brute-forceable 41 bits of entropy. Additionally, we are confident that this attack could be improved upon using several different strategies. From these experiments, we conclude that profiling a family of chips can help to tackle the portability problem, and that this technique allows you to mount a side channel attack on a key transfer in a real-world device. To conclude this presentation, we want to provide you with an overview of all of the vehicles we know are affected by the attacks detailed in this paper. The model names in bold are the vehicles or their ECUs that are evaluated during this research. We contacted all of the affected manufacturers and provided them with a personalized report. Tesla was able to resolve the downgrade attack by pushing an over-the-air update that allowed users to service their own key fob. Finally, we hope you'll enjoy reading the full paper. We believe it contains something for everyone interested in hardware security. We demonstrate a practical fault injection attack that allows to extract the firmware from a commonly used automotive microcontroller. We publish the full details of the proprietary DSD-80 cipher, for which there are currently no public cryptanalytic results. We also reveal that even without a cryptanalytic attack, we can bypass the security provided by many of these systems by exploiting weak key diversification and downgrade attacks. Additionally, we provide a differential power analysis attack, as well as a profile attack on the key being loaded into the hardware accelerator, all of this while taking portability into account. Feel free to contact us should you have any questions or join us for the discussion during the virtual chess 2020 conference. Thank you for taking the time to watch this presentation.


So let's just go over this picture problem. I know these ones are semi-annoying sometimes, but it's good to every once in a while do them. So this question asks, well, label each picture as one of these choices, okay? So obviously since we have five choices in six pictures, one of the choices can be used more than once, or at least one. Okay, so if you guys want to help me, you're more than welcome to. So what I would do is just look at these choices and try to measure them, right? So we've got first choice is a gaseous compound. So a compound is two or more elements stuck together, right, bonded together. So we're assuming I guess maybe we should write this here. That blue is one element and orange is another element. So we've got one bonded together. Looks like we've got here is a gaseous compound. You can see here we've got a gaseous compound, but it's in a mixture with this other thing, okay? Same thing here. We've got that gaseous compound, but it's inside of the picture. Okay, so that one looks like the only one. So a mixture of two gaseous elements. So remember an element is just one atom by itself or it can be a diatomic element where it's got two atoms of the same type of atoms stuck together, two or more, okay? A diatomic or a polyatomic would be more. So let's see what we've got here. Well, here we've got single atoms by themselves, but again they're in the mixture of that compound. Here we've got single atoms, but they're in a mixture with other single atoms, so obviously not at one of those is the case, but up here it looks like we've got atoms of the same type that are bonded together, so like a diatomic element. So we're looking for a mixture of two gaseous elements, so this one would be it. Sorry about that. I forgot what we were looking for, okay? So a solid element, of course, solids don't fly around, so the only one that makes sense for that one would be the one where all of the atoms are stuck to the bottom of the container. So a mixture of a gaseous element and a gaseous compound. Well, here, right, we've got that gaseous compound that we found earlier, and we've got a gaseous element, okay? Here we've got just two gaseous elements, but here we've got a gaseous compound, right, that we found earlier, and we talked about diatomics being elements, so this one and this one would both be represented by d, okay? Or can be representations of d, I should say. And then what's left is just the gaseous element, and it looks like the only one that can be d is that one because everything else up there. These ones are mixtures, and these ones are pure substances, but this one's compounded, of course. So let's just identify that since we've got the video rolling. These ones over here, these are all mixtures. You can see we've got one type of thing mixed with another type of thing. One type of thing, one pure substance mixed with another pure substance. All of these other ones, these are all pure substances. Even though this is atoms of two different types of elements, they're combined in the same ratio as everything else is in that same container. So this is like a pure material like carbon monoxide or something. Is there any questions about this one? If you're reading on chapter four, you guys probably have this nailed down. Okay, thank you.


Everybody forced here rippin 21 22 prison basketball hobby 12 box full case number two This is a tiered random team style break and you can always find these results at late in sports cards calm Under the results quick link. Thanks for joining everybody and good luck Let's do this one out two one again. This is crazy and judges up Yikes, now we go Let's get started and as always there'll be a recap at the end There's a bones rookie ruby wave Grizzlies Dylan Brooks Clippers blue Eric Bledsoe to 199 Wizards Corey Kispert Silver bowls Tony Kukoch purple ice Mavs Steve Nash to 149 75 years David Robinson for the Spurs I did in that thing where they interview the player. That's like playing in the field. I can't stand that Cav is rookie Evan Mobley Brandon Boston blue way or not red ruby wave Killian Hayes pistons hyper for the Sixers Seth Curry Silver for the Clips scoop Jackson silver widescreen Yanis for the Bucks Well, let's start the break off with a big card Jones and Toscano Anderson Red for the hops on Yaka Okangwu number to 299 Duarte Pacers rookie base Christopher Rockets silver for the Grizzlies Xavier Tillman Hyper rookie Kings Namias Keita fearless Edwards Silver Sixers Allen Iverson blue ice rookie Sixers Charles Bassey to 125 Magic rookie Jalen Suggs Ruby wave Bucks Ray Allen Hyper Jazzes on Whiteside Edwards Giddy rookie for the Thunder silver for the Bucks Brooke Lopez prismatic silver dwelling bead Sixers First auto is going to the Thunder rookie Jeremiah Robinson Earl Xavier Williams Grizzlies rookie Wise Camp Hyper Trey Young mindset for the Hawks Pacers rookie base auto Chris Duarte Okay, go Pacers nice hit Zagorowski silver for the Celtics Aaron Nessmith Hyper for the Wizards Daniel Gafford Nessmith going to be on the Pacers next year from that Brogdon trade Pulsar warriors Draymond Green Orange for the Knicks no one's no well color match to 49 Big big dings on this on a nobie No sooner rookie for the bulls everything else is fine in the pack Ruby wave bulls Kobe Whites blue rookie Pacers Isaiah Jackson a 199 Silver rookie Hornets James book night followed by a mojo heat bam out of bio Nice bam five of 25 75 years bucks drew holiday Rockets rookie Jalen Green Ruby wave bucks Dante de Vicenzo T-Wolves hyper Jada McDaniels Anton silver Raptors Gorin Draguage Silver mindset Trey Young Hawks What's up Kemper Jalen Johnson Trey Murphy the third Red prism Hawks Trey Young to 299 nice color match there Reeves rookie for the Lakers Shengun Rockets Cavs silver Ricky Rubio Hyper Cavs Kevin Love Lewis Lewis Pulsar rookie Raptors Scotty Barnes Big card Raptors will mag that Blue Ice Mavericks Boban Marjanovic to 125 Bassie Silver for the Spurs David Robinson Purple Bulls Lanzo Ball to 99 Clippers rookie Keon Johnson Springer Ruby wave Hatchimora Wizards Trainman hyper rookie Thunder Spurs silver Thaddeus Young Silver prismatic Lebron James Lakers Hornets rookie Bassado Kai Jones Prismatic hyper Lebron James Lakers Followed by Nuggets bassado Jamal Murray Silver for the Heat Duncan Robinson Hyper for the Rockets John Wall Book Knight rookie for the Hornets Rockets who's Monteruba Moody wow Big card 75th anniversary Rockets Jalen Green Boom 31 of 75 Kaboom That is sick S Han we'll get that mag for you What a card man Those look so sick with the teams that wear red Prima rookie for the Spurs Silver Giannis for the Bucks Hyper DeLon Wright Hawks Thanks Kemper Nice bass hit They are on sharp Ruby wave Blazers Larry Nance Red for the Kings Jason Williams Number two two 99 Isaiah Jackson Silver for the Hornets rookie JT Thor Pistons blue Killian Hayes the one 99 Jimmy Butler 75 years Anthony Edwards Kings rookie Davion Mitchell Ruby wave Clippers Kawhi Leonard Hyper rookie Wizards Corey Kispert Cade Cunningham Bass Isaiah Todd Silver Pelicans Devin Booker Steph Livers Banton Hyper Jama Rant fireworks for the Grizzlies Rockets rookie bass auto Josh Christopher Jared Butler King Silver Harrison Barnes Hyper for the Nets Bruce Brown Kaminga rookie for the Dubs Hulsar south extended shooter Mojo Nets Paul Millsapta 25 Home Long Story Scotty Barnes Bass Rack Silver Cavs Darius Garland Blue Ice Mavs Tim Hardaway Jr to 125 Shreve Cooper Hawks Cameron Thomas Nets Ruby Wave Nix Nurlin's Noel Hyper for the Hawks Clint Capella Nope, no mangas or color blast They do have those 75 75 edition or whatever the heck it's called For this year, but Typically no Greg Brown Scottie Barnes Greg Brown Silver for the Bucks Chris Middleton Silver, Donovan Mitchell Fireworks Jazz Jared Butler rookie auto jazz Not numbered We break on a schedule The only flaw of stripping tonight is Case 51 So we break Everything by schedule Raptors rookie Scotty Barnes Silver rookie Nix Miles McBride Hyper for the Southix Robert Williams III Hyper rookie Robert Williams is not a rookie Cooper Thomas Ruby Wave Magic RJ Hampton Blue Ice Nuggets Nicola Jokic out of 125 I think the only one tonight is Case 51 Silver for the Lakers Taylor Norton Tucker Purple Ice Rookie Nets Daeron Sharp to 125 Jaylen Green 75 years Rockets Usman Garuba Moody for the Warriors Danny Green T-Wolves Hyper Jada McDaniels Primo Spurs Book Knight Hornets Silver Clippers Eric Ledso Silver Prismatic Zach Levine Bowles Nets Rookie Daeron Sharp Purple Wizards Denny of Dia to 99 Spurs Rookie Bass Auto Joshua Primo Dosumu Rookie for the Bulls Silver Heat Bam out of Bio Rockets Hyper John Wall Pulsar Spurs Dejante Murray Mavs Tim Hardaway Jr to 199 in the blue prism there Rockets Rookie Jaylen Green Silver Grizzlies Kyle Anderson Andrew Wiggins 75th Anniversary Warriors to 75 Isaiah Livers Banton Ruby Wave Hornets Rookie JT Thor Hyper Hornets Rookie James Book Knight Centering's off top to bottom on that one Lakers Silver Russell Westbrook Silver Fireworks LeBron James Lakers Hornets Auto is PJ Washington Jr Warriors Rookie Jonathan Kaminga Jared Butler Jazz Bucks Red Jordan Diwara to to 99 Ruby Wave Cavs Laurie Markinon Hyper Bucks Chris Middleton Yeah, PJ Washington looked like a guy who was going to be a pretty good forward like a John Collins type Jalen Johnson at least offensively Traemer for the third pelicans Silver Sons Jalen Smith Luca Fearless Silver for the Mavs He's a solid player, but yeah I thought he was going to develop a little bit more Maybe he still will He's pretty young What's up Chris Jason Preston Alperin Shengyun Fearless Hyper Sons Charles Barkley Kings Rookie Auto Davey on Mitchell Solid Hit for the Kings Lewis Silver Nugs Facundo Campazo Hyper Rockets Rookie Bozeman Garuba Prism Dusk is everywhere It makes my face and eyes itchy Springer Charles Bassie Ruby Wave Pacers O'Shea Berset Red for the Kings Rashawn Holmes to 299 I never feel like this when I'm breaking other stuff Clippers Rookie Key on Johnson Silver for the next RJ Barrett Mojo Kings Tyrese Halliburton Nice one Sacramento Rick 25 Walt Fraser 75 years Kispert Rookie for the Wizards Ruby Wave Thunder Shigildus Alexander Nets Hyper DeAndre Jordan Big color here Mobley Cavs Rookie Bass Sixer Silver Tobias Harris Prismatic Silver Blazers Damien Lillard Hawks Bass Auto Christian Leitner Purple Ice Next Julius Randall out of 49 Josh Christopher Thunder Silver Shigildus Alexander Pelicans Hyper Devante Graham Bones Highland Nuggets Rookie Duarte Pacers Pulsar Jazz Joe Engels Spurs Red David Robinson 299 Quentin Grimes Silver Hakim for the Rockets Blue Ice Kemble Walker Nix to 125 Fox Six Rich Jalen Green Silver for the Hornets Rookie JT Thor Hyper Rookie Raptors Scotty Barnes Heck yeah there you go Raptors That's pretty Centering's off a little left to right as it looks I think Great hit there we'll get it magged for ya Not technically a hit boy Pretty much it Ruby Wave Celtics Josh Richardson Purple Ice Spurs 149 Silver for the Knicks Kemble Walker Blue Ice Rookie Grizzly Santial Dama to 125 Pacer 75 Years Chris Duarte Jared Butler Jazz Ruby Wave Lakers Carmelo Anthony Sons Hyper Devin Booker Scotty Barnes Raptors Rookie Kaminga Warriors Pelican Silver Jonas Valenskunis Prismatic Silver James Wiseman Warriors Everything is sold out tonight Stags So next group breaks will be available Tomorrow night 4pm eastern start time Schedules on the site Get it for you right here actually Nets Cameron Thomas Purple Buckstru Holiday It's a 99 Nix Jerry Lucas Bass Auto Keon Johnson Clippers Rookie Silver Rookie Hornets Kai Jones Hyper Wizards Kyle Kuzma Pulsar Nets DeAndre Jordan Fearless Silver Lakers Ampity Davis I know what you mean It kind of says what prism is Singles prices drive up the box prices Trey Murphy the third Silver Bezmack beyond Bo Hornets Black and Gold Sons Starbury Heck yeah man 2 out of 5 nice Starbury Legend right there we'll get that Mag that's sick Aaron Schengun Jaylin Johnson Hawks Ruby Wave Grizzly Santi Aldama Hornets Hyper Kelly Ubrey Jason Preston Iota Sunmu Boles Rookie Silver for the Wizards Thomas Bryant Blue Ice Pacers T.J. Warren Out of 125 Boles Auto Kobe White Edwards Bass in there Anthony Edwards Bass I appreciate it Red for the Blazers Norman Powell Reds to 299 Alright halfway through let's keep it going Purple Ice Spurs Keldon Johnson to 149 Garuba Moses Moody Warriors Silver for the Blazers Robert Covington Hyper for the Pistons Hamidou Diallo Rookie's to be in the back this box Premo and Book Knight No I haven't hit anyone on one some of the other breakers here have Ruby Wave Wizards Andrew Wiggins Ruby Wave's not numbered Purple Zion 99 Pelicans Day Run Sharp Actually I may have I don't even remember I've hit a few black and golds Silver Pistons Sadiq Bey One of our breakers had a Rookie Auto one of one Not the biggest name but that was on release day Red Ben Simmons to 299 Sixers Can't remember who it was Ruby Wave Rookie Hornets James Book Knight Cavs Hyper Jarrett Allen First off the line you get Shimmers Get two shimmer parallels They're exclusive Silver for the Celtics Jason Tatum Silver Widescreen Zion Pelicans Blazer is Ben Macklemore base auto This is Charles Bass Yvonne Thank you I was gonna say I know it wasn't Like the biggest name but They'll probably get playing time going forward Yeah first off the line gets shimmers You get two shimmers there's like blue Shimmer to 30 is the highest number it'll be Hornets blue Alonzo Morning to 199 followed by A Scotty Barnes Rookie Silver Auto Big Hit Raptors What we like to see right there Congrats to Chase D Chase has the Raptors Silver Scotty heck yeah dude We will get that mag for you for sure Make sure you got insurance on that one Centro and Cade Base There we go big hit Let's start heating up now Let's see big cards Whole second half here Silver for the Mavs Dirk Nowitzki Heat Hyper Hero Frans Wagner base rookie Pulsar Hornets Terry Rozier Cavs Blue Ice Jared Allen to 125 Zyre Williams Grizzly's base Silver for the Wizards Montrez Harrell Red T-Wolves Nasreed to 2.99 to the red 75 years Isaiah Jackson Ruby Waves Sixers Andre Drummond Hyper Pistons Jeremy Grant King's Rookie Davion Mitchell Yeah Toquai Silver for the Cavs Laurie Markinon Silver Prismatic James Harden Nets I'm top loading like a beast over here He's quiet cause I'm giving him like 4 cards every pack to top load I have that hyper focus At least this is the last of the prisms tonight Right on Friday Box Rookie Sharif Cooper Cameron Thomas Nets Orange Wave RJ Hampton Orlando to 60 It's RJ A line Greg Brown Blazers Silver Rookie Hornets JT Thor I think we both felt like that at the end of Friday Hyper Bucks Yana Santatakumpo That was Orange Wave to 60 There's Usman Garuba Rockets There's a moody for the dubs Ruby Wave Jazz Joe Engels Nets Red Jason Kidd to 2.99 Lamello Fearless The Error Card Let's see a true goal now, come on now Joshua Primo Spurs Rookie Book Knight Hornets Rookie Silver Blazers Larry Nance Purple Ice Thunder Rookie Tray Mann To 1.49 75 years C-Web Sharp Ruby Wave Sons Deandre Aten Hyper King's Rookie Nimes Keita Also Offcenter taught the bottom there Isaiah Jackson Pazers Silver for the Jazz Hassan Whiteside Silver Fearless Sons Devin Booker Purple RJ Hampton Magic to 99 Cavs Silverado Carlos Boozer Rockets Rookie Jalen Green Silver Rookie Hornets Kai Jones Hyper Heat D Wade Libbers Banton Pulsar Santiago Dama Grizzlies Rookie Nix Red Alec Burks To 2.99 Sixer Silver Ben Simmons Blue for the Sons Defon Marbury 1.99 Yeah it's funny the error on that card makes it more valuable than it would have been without it for sure Kaminga Rookie Warriors Jared Butler Ruby Wave Rockets Usman Garuba The Rookie there Gallinari Hawks Hyper Let's do fairly well unless it's like a really really big card that's messed up but error cards do pretty well Scotty Barnes Raptors Silver Tebow's Malik Beasley Silver Prismatic Deer and Fox King's The redemption is gonna be a Zion Williamson Flashback Signatures Pelicans There he is some hit there guys gonna have a bit of a comeback play of the year next year Rats Pelicans Remember everybody Group Breaks are sold out for tonight Personals are full for tonight 4pm start time with Group Breaks tomorrow McBride Zagrowski Purple Ice Pistons Kelly Ullinick He's gonna come back and go off to Oak Lake I don't know People got this whole thing because he didn't play for you that he's done Silver Rookie Dallin O'Bance and Raptors Hyper Rookie Thunder Trey Mann Apparently he's lost a little bit of weight but I mean he's ready to go pretty much I think he's gonna be a full participant once like preseason comes along Todd Scope Maxi Claver Mavericks Red for the Dubs Clay Thompson at $2.99 I mean investing is one thing His prices haven't gone down a ton but I mean I'm just saying he's gonna be great on the court Kid Cunningham Rookie Silver Blazers Anthony Simons Blue Clippers Paul George It's $1.99 Colored Match Trevor Lawrence is gonna be awesome dude Wagner Rookie Magic Ruby Wave Rookie Warriors Moses Moody Hyper for the Bulls Alex Caruso Now that he's got an actual NFL head coach We'll see though it's still Jacksonville Grizzlies Rookie Zach Williams Silver Nets DeAndre Jordan I don't play Xion either I just think He's legit I mean Silver Field is Giannis Jon Arant's Redemption Sensational Signatures Mojo Boom Mojo to $25 Big Card Grizzlies A lot of vet redemptions in prison this year Grasted John C We'll get that magged Edward's right there Mojo to $25 Big stuff man It's funny I was thinking there'd be some rookie redemptions But I don't think we've seen any rookie redemptions yet in this A lot of vet redemptions Orange Wave Bulls Alex Caruso Number 260 The Bulls Base Auto Elton Brand Kings Rookie Davion Mitchell Silver Rookie Pistons Isaiah Livers Hyper Wizards Montrez Harrell I don't know if I pulled a Cade Auto yet Sugs Rookie for the Magic Ruby Wave Kings Roshan Holmes Pat Bev to $75 on the 75th anniversary T-Wolves Pat Bev RBI Double for Vasquez Let's go Giddy Rookie Base O.K.C Nick Silver Emanuel Quickly Red Debuck Sons to $299 75 Years Isaiah Jackson Pacers Ruby Wave Celtics Dennis Schroeder Hyper Jwellinbeads Sixers Josh Christopher Herbert Jones Silver for the Hawks DeLon Wright Silver Prismatic Anthony Edwards T-Wolves Does anyone know if Cade is live or redemption in this? I don't think I pulled his auto yet in prism anyway I can't remember honestly We ripped so much on Friday that it's all like a blur Barnes is live and that's big because he's been redemption in most everything recently so Barnes being live is big for the product Primo Rookie for the Spurs Book Knight Hornets Rookie Orange Waves Silver for the Hawks John Collins Nick's Hyper Julius Randall I would imagine prism was made before photogenic Ruby Wave Warriors Andrew Wiggins Alec Burks to $75 Nick's 75th Anniversary Did Giddy just tie the game up? Kings Rookie Davey on Mitchell Silver Rookie Wiggins Thunder Red Dwayne Bacon Nick's to $299 Corey Kisford 75 years He did Hell yeah dude That's his first home run at Fenway since June 14th That's crazy That was his first home run at all Gonna steal two games Ruby Wave Yolkich for the Nuggets Hyper Heat Dwayne Wade Ann Edwards Cade Bass Silver T-Wolves Silver Fielce Blazers Damien Lillard Jazz Rudy Gaye Red to $299 Lonzo Auto Mojo to $25 There you go Chicago Heck yeah dude love Lonzo Bulls with a very nice hits Kevin D will get that mag for ya Sick Lonzo Kaminga for the Dubs Butler Jazz Silver for the Nets Nick Claxton Hyper Rookie Evan Mobley now That is a gorgeous Evan Mobley Big one there Cleveland what a box Second half of the case definitely out doing the first half for sure Jeffrey there you go man we'll get that magged Scotty Barnes Bass for the Raptors Pulsar Pistons Jeremy Grant Warriors Blue color match Andrew Wiggins to $199 go ahead Ron is on Cam Thomas Nets Rookie Spurs Rookie Silver Joshua Primo Purple Ice Raptors Precious Atua Number to $149 Greg Brown Cooper Ruby Wave Jonathan Kaminga I don't know why they don't have color blast in it Warriors Rookie Moses Moody Silver for the Cavs Moses Brown Silver fireworks Debuck for the Sons Grizzlies Rookie Otto Santi Aldama couple boxes left leaving this guy in the game right now he's thrown 90 pitches and he's given up six runs in five innings it must be short on the bullpen arms or something right now Jalen Green Ruby Wave Magic Chuma Okiki T Wolves Red Carl Anthony Towns $2.99 Robinson Earl Silver Rookie Pistons Purple Ice Knicks Emmanuel quickly to $149 75 years Luca Livers Banton Ruby Wave LeBron James Hyper MoBamba Magic LeBron James Celtic Silver Robert Williams the third Silver Dame Prismatic for the Blazers Dosumu for the Bulls Preston for the Clippers Shengyun Rockets Orange Wave Hawks Rookie $2.60 Austin Reeves David Johnson Nugget Silver Facundo Campazo Lakers Hyper Taylor Norton Tucker yeah I mean it makes sense he wants to win he's getting older he's gonna be 38 next season 37 next season Springer Pulsar Bucks Ray Allen Red Rookie Warriors Jonathan Kominga Nice Red 201 out of $2.99 Magged as well Mellow Fearless Second year Lamello Keon Johnson Silver Rookie Hornage James Book Knight Blue Prism Luca that's pretty $4.99 There we go Mavs Trey Murphy the third got Ruby Wave Scotty Barnes Boom Let's go Raptors Chase again congrats bud awesome Scotty will mag that Hyper Warriors Will Chamberlain Jalen Johnson got Silver Pistons Josh Jackson Silver Luca Mindset Nets Rookie Auto Base Wiggins Garza Spurs Purple Tim Duncan to $99 Pelicans Rookie Base Auto Trey Murphy the third Bassie Scotty Lewis Maverick Silver Maxi Claver T-Wolves Hyper Malik Beasley Alright last box got to get something big here good luck everybody Thank you for joining Pacers Rookie Chris Duarte Josh Christopher Ruby Wave Sixers Ben Simmons Orange Heat D-Wade to $49 Six of $49 on the D-Wade Nice Bones Nuggets Rookie Celtic Silver Bill Russell Blue Ice Quentin Grimes Nicks Rookie Colormatch 125 Hawks 75 years to Kembe Matumbo got Corey Kispert Ruby Wave Pelicans Nikhil Alexander Walker Kings Hyper Rashawn Holmes Cavaliers Rookie Evan Mobley King Silver Deer and Fox Silver Fireworks Grizzlies John Morant Giddy Rookie for the Thunder Blue Prism Spurs Dijonte Murray to $199 Pelicans Herbert Jones Toscano Anderson Warriors Silver Spurs Doug McDermott Hyper Clippers Rookie Brandon Boston Jr Come on Black Prism Gold Prism Black and Gold Some more Mojo maybe Zabrowski Pulsar Kings Tyrese Halliburton Purple Nuggets Monte Morris to $99 Silver Nets Rookie Deer on Sharp Red Prism Nets Blake Griffin to $299 Ruby Wave Rookie Jazz Jared Butler He's been doing pretty well this summer Hyper Nets DeAndre Jordan Some of those young guys in the Nets might get some more playing time going forward if especially if Mitchell gets moved about to go into that big rebuild Magic Rookie Jalen Suggs Kai Jones Pelicans Silver Devante Graham Silverfield Aschak Magic Rookie Base Auto Sixers Jaden Springer Magic Rookie Franz Wagner Purple Eyes Hawks Bogdan Bogdanovich Aaron Bain Silver Auto Raptors Thank you very much everybody for joining Grizzlies Rookie Zaire Williams Wise Camp Silver T-Wolves Pat Bev Hyper Raptors Gary Trent We'll do it Definitely had some nice cards Nothing crazy, crazy big We definitely had some big cards in this break Give me just a second We'll do a recap Trash out of the way Prism Dust I'll tell you what It's everywhere Here's all the non-magdottos He had Aaron Bains Jaden Springer Trey Murphy III Santi Aldama Carlos Booster as a Cav Ben Naklomore Blazers Kobe White Jerry Lucas Christian Leitner as a Hawk Davion Mitchell P.J. Washington Jr. Joshua Primo Jared Butler Josh Christopher Jamal Murray Kai Jones Chris Duarte Jeremiah Robinson Earl Red Prism Rookie Jonathan Kaminga Rubi Wave Scottie Barnes Raptors Hyper Evan Mobley Cavs Zion Flashback SIG Redemption Pelicans Grizzlies Jamerant Mojo Auto Redemption Mojo Auto Lonzo for the Bulls Silver Rookie Auto Raptors Scottie Barnes Black and Gold Starbury for the Suns Hyper Scottie Barnes Raptors Crushed 75th Anniversary Rockets Jalen Green to 75 and a Pulsar Scottie Barnes All over Pretty good break Thanks again everybody We've got football for the rest of the evening