Hi everyone, Joe for Jaspy's CaseBrakes.com coming at you with 2016-17 Panini Select Soccer. One box, random country, break number two. This is only the second box of a fresh case we popped open yesterday. So if you wanna keep running this back, we certainly can. We're gonna go by this checklist, there's a checklist link right here. We're gonna go by that checklist. There you go, yeah, nice checklist here. Link is in the description if you wanna check that out. Three hits per box. Prism and numbered cards. 32 countries involved right here. And I know it says only numbered cards, Relics, Autos, and Inserts will ship. We will also ship Lionel Messi and Christiana Ronaldo-based cards to whoever gets Portugal and Argentina.  And let's randomize each list. Names and countries six times, two and a four. One, two, three, four, five, and sixth and final time. After six, we've got Rick Serrano all the way down to a couple Kalims. Two and a four, six times for the countries. One, two, three, four, five, and sixth and final time. After six, we've got Croatia down to Bosnia-Herzegovina. So let's show you what you got here. So Rick Serrano, you have Croatia, Caleb with the United States. We'll send you Pulisix too, obviously. Rick Serrano with Mexico, CJ Monroe, Iceland, Josh, Brazil, Rick with Poland, CJ with the Netherlands and England. Are we sending Rashford's too? Third 30 bucks a piece? Marcus Rashford? All right, well, Marcus Rashford's will go too. Caleb with Uruguay, CJ also has Montenegro, Josh with Chile, Robert with Russia, Caleb with Spain, Martin you got Turkey, Josh with Colombia, you also have Wales mix up, Joseph with Austria, Josh Melton with France, Robert with Argentina, CJ Monroe with Sweden, Martin with the Ukraine, Rick with Romania, Caleb with Portugal, Martin with Ireland and Northern Ireland, you got both. CJ Monroe with Cote d'Ivoire, Martin with Germany, Rick Serrano with Slovenia, Joe Carmos with Hungary, Rick with Belgium, Caleb with Italy and Bosnia Herzegovina. Let's sort by column B by team, let's box these up, center these up. Let me know if there's any trades, we'll have a little short trade window, that's what we're looking for, one autograph, two memorabilia cards per box on average. No, no deals, mix up, are we trading? Anyone else here trade Rick Serrano maybe? I think he's trying his first soccer break. Maybe not, trade window going once, trade window going twice. All right, TWC, trade window closed, let's print, let's rip. All right, mix up, I don't have a lot of leverage for trading. Well, let's see if we can still get you something. Anything crazy happen in soccer today? I'll tell you something crazy that happened. Leo Messi is gonna stay with Barcelona. Not because he wants to, but he's kind of forced to, he doesn't want to go to court with the pandemics all going on, a lot of courts cases are backing up and there's not a lot of open courts going on.  So he's like, well, I guess I gotta say, I'm sure he'll be a professional about it, he'll play hard, it's just the way he's built, but I think he loves the club, loves the fans, but maybe not the way the end of his career has been going. So, looks like he either gets transferred in the winter transfer window, right? Otherwise, I think he leaves on a free at the end of this current, I guess, upcoming Premier League or Premier League, La Liga season, the 2020, 2021 season, by the time that's over and around next May, no transfer fees, nothing. But then you're like, Joe, isn't Lionel Messi's transfer fee like clause? Isn't that like at 600 million pounds or something like that, which is just outrageous? It is outrageous. I don't think anyone's gonna pay that. So is that just it? Barcelona doesn't get anything back and that's it. I don't know. You think Messi goes to the States first? I feel like Lionel Messi, you don't think he'd go to Italy? Maybe not. Maybe Italy is not for him. Maybe he'll come to the States. Are you guys poaching all of our female soccer players? All right, there's Adrián Ramos for Bruxa Van Dortmund. This will go to whatever, what country is he, he usually says on the back, blanking on where? Colombia. So this will go to Josh Melton. But yeah, I feel like Messi wants to reunite with, there's Polpogba, maybe reunite with, there he is right there. Reunite with Pep Guardiola in Manchester City and then maybe move. Oh, there you go, Micsub, there it is. There's Lionel Messi right here, Argentina. That makes the most sense, Robert Throne, yeah. So maybe he does go with Man City, reunite with Pep Guardiola next summer, right? Place for a little bit there and then maybe moves on to NYCFC, also owned by Manchester City. There's Luca Madritch, great performance in the last World Cup for them, 110 out of 249, nice, that goes to Rick. Well, I guess then who fills the Messi space next year is Coutinho still stay there? Oh, there's my guy, Steven Gerrard. Stevie G. Woo, Jersey and autograph, not in his Liverpool shirt. But in his England shirt, the three Lions, 25 out of 35, C. Jim Monroe with England. It's coming home, it's coming home, it's coming, football's coming home. All the Steven Gerrards retired. Coaching though, future Liverpool boss. There's Doris Mertens. And I thought that might have been a Silverpall, Pogba, but it's Pogba, does he stay? His club, Pogpogs are for France Le Bleu, going to Josh, Alvaro Morata, and we've got Chicharito, Javier Hernandez for L3. 57 out of 75 with my L.A. club, L.A. Galaxy. L.A. Galaxy, Rick Serrano with L3, Mexico. What about, isn't Thiago Silva on the move? Or am I thinking of Thiago Alcantara? Or are both Thiagos on the move? What going on right here, not going on? There's Javier Pastore, 24 out of 99. There's Marcus Rashford. Also for the three Lions, C. Jim Monroe. Javier Pastore is an Argentinian that goes to Robert Throne. And there's Neymar. Where's Neymar going? There's select few Neymar. Is he going anywhere? Back to Barça maybe? This one's for Brazil, that's for Josh Melton. Wow, Brad, is that right? So that LeBron James, 2018, 2019, Playoff Contenders, Hall of Fame, Crack Dice out of 25. Someone's trying to sell it on eBay for $4,000. That's pretty nice. There's David Silva. But hey, even if it's half that, right? There's Angolo Conte, what's on the back here? I feel like a relic in the back, I think. Tony Cruz, we've got, it's Jal Matinho. Piece of his Spain shirt going to Caleb. Wait, no, Portugal? Portugal, sorry. Caleb, still has Portugal too. He has that whole Iberian Peninsula there. All right, there's Silver Sergio Guero, Luis Suarez making a move to Italy, right? Youve? Bobby Woods, 73 out of 299, Caleb. Arturo Vidal, and reveals another Adrián Ramos. Right, do we get two of these in the same box? All right, another one for Argentina. Yes, Bradley, I'm going to be adding another box after I finish this break. Yeah, this is only the second box of a fresh case. And I don't think any have been sold on the personal box side of things. So, there's Gonzalo Iguain. So yeah. No, nothing more current, soccer-wise, I'm afraid. These boxes have been going for a lot on the secondary market. All right, there you have it. One box, Ren country break number two of 2016-17, Pani select soccer. I don't think we've seen like, Polisix yet. So, maybe time to hunt him in the next box. Thanks for watching. I'm Joe for jaspyscasebreaks.com, and we'll do some more footy with you next time. Bye-bye.


Scientists, we need water to test. Scientists, hold on.  Scientists hands in your lap. Scientists, I need you to look at this clay and I need you to think. Make a hypothesis. Remember, you're wondering, you're thinking about your prediction if it's gonna sink or float, then you're gonna think how you're going to make it happen. So think in your mind, what is my hypothesis? Tell your science partner at your desk, what's your hypothesis about the clay? What's your hypothesis? So over here, what's your hypothesis going to be about this clay when I bring the water? I believe that hypothesis is it will float. When? I put it in the water. Excellent. Now tell Soraya, so I'm noticing that this is covering it. I really want you to think about that. When I put the clay in the water, I think it will sink. My hypothesis is it's gonna sink. So let's turn that into a hypothesis. Scientists, stop looking, listen. I know you're excited to touch your clay and play with the clay, but put it down. Now I'm gonna bring the water to your tables.  Brittany, I want you to share your hypothesis with us. All scientists are being great listeners. My hypothesis is I think the clay will sink when I put it in the water. Are you ready to test her hypothesis? Yeah. She thinks it's gonna float. I heard a couple of other hypothesis that they think it's going to sink. Wait till I bring you the water and then you may take your clay in one friend at a time. Put your clay inside the water. I was right there. Oh man, I was wrong. I was right. Automatically. It was sink.


abof.com is Aditya Billa's online fashion retail brand and if you open abof.com right now on your mobile it looks something like this. So before we stepped in, before me and my team stepped in, abof.com was your regular old website. It was powered by something called IBM WebSphere Commerce which is a traditional web framework in the sense that it renders some HTML on the servers, sends it down the pipe to the user and then on the front end some JavaScript added on to enhance the user experience. And WebSphere Commerce uses the dojo toolkit to actually build the JavaScript with it. But because abof.com was a very, very fast growing website when we stepped in and a lot of teams had worked on it over the past couple of months, there was a lot of jQuery code that was also present on the front end on abof.com. And because of this, because of this mismatch of technologies and because of different frameworks being used on the front end, they ended up with a huge payload on the front end which actually degraded their front end performance quite a lot despite the fact that their back end was blazing fast, it was really fast. So let's look at some numbers. When we stepped in earlier this year around February or March, it took about 20 seconds before something showed up on the screen on a CG connection if you went to abof.com. And that's a lot for an e-commerce website. That means most of the visitors who come to your website using a slower connection are just going to bounce off. When we stepped in, by we, I mean Alaris Prime and some folks from ActiveSphere who are one of your sponsors today. When we stepped in, we rewrote the entire website as a single page application using React. And once again, let's take a look at some number, but before we do that, I'll just use my computer to control this. So before we do that, let's, I'm going to define a term. I'm going to define a metric that we use to measure performance. And this metric is called time to first paint. And to understand time to first paint, I'm just going to show you a video. So let's quickly look at how a page on abof.com loads. So this is, this is the page you get if you go to women's dresses on abof.com, right there. At around three seconds, when you start loading your page, something gets painted to the screen. And when I say time to first paint, this is what I mean. Time to first paint is the time from when your user makes a request to your website to the time when he actually sees something on the screen. And time to first paint is a really, really important metric, especially on e-commerce websites, because this is what decides if your user is going to stay on your website, wait for your products to load, and actually interact with the website, or if the user is going to get bored and bounce off. So throughout this presentation and throughout this talk, and in fact throughout this entire project we did at abof, time to first paint is what we looked to optimize. Our goal throughout this entire process was always to get something on the user's screen as quickly as possible. Now let's take a look at abof's numbers. Let's take a look at what abof's numbers were before our teams stepped in and after our teams stepped in. So when we stepped in, abof.com would, on a 3G network, on a mobile phone would take about 20 seconds to load. After we stepped in and after we optimized the website and rewrote it to rewrote it in react, we got the time down to some 2.2 seconds, 2.6 seconds. That's about an order of magnitude improvement.  That time comes, was initially some 27 seconds, but after we were done with the website and we delivered the react rewrite, that came out to be about 9.4 seconds. So once again, that's about three times faster. And a quick comparison video with a bunch of other e-commerce websites in India. These are slow motion videos taken on a 3G network. And so the video is a little cut off here, but on the top left corner, you'll see abof.com loading. And on the bottom, you see Flipkart, you see Amazon, and you'll see Jabong and Coves as they start loading. So I'm just going to play this video real quick. So once again, at around three seconds, you see that abof.com has something on the screen while nothing else is loading yet. Let's just continue this video for a bit. And around four seconds, you see Jabong loads, Flipkart is loading. And around nine seconds, you'll see that ABOF has now finished loading, and everything else is still loading. Flipkart is at 13 seconds now. Where's Flipkart? Guys. All right. So if you want to take a look at this comparison video, you can go to that URL. It's available on YouTube. You can take a look. This was taken about three months ago. I think Flipkart recently pushed some optimizations that has actually made them really, really fast. And Ankit talked about it in the morning. So that's really great. I'm glad everyone's paying attention to their performance. All right. So let's talk about how we went about doing this, how we went about optimizing ABOF's performance. So ABOF was a ground up rewrite in React. And while doing this rewrite, we followed three main principles throughout our development process. And these principles are number one, be impatient. You want to start painting to the user screen as early as possible, as quickly as possible. You want to get something there. You want your user to start interacting with your website as quickly as possible. Principle number two is be lazy because we are in India and we have to optimize our websites for low-end Android devices. We're talking Moto Gs, but we're also talking devices by MicroMax and Lava Mobile, white-label Chinese devices. And these devices don't always have the latest web browsers or the fastest processors. And they're also on flaky 3G or 2G networks or what's called LiFi, which is a Wi-Fi connection that's actually really, really slow. So on the device itself, you want to do as little work as possible. Principle three is set quotas for everything you do, for every computing resource you have at your hand, whether it's the number of network requests, your bandwidth, CPU time, memory, the number of DOM nodes your device can handle, you need to set baseline quotas for everything. And a good strategy for doing this is to begin with the kind of devices you're targeting. Once again, ABOF's customers are, let's say a typical ABOF customer uses a Moto G to visit the website and visits the website using a CG connection. So you already have two constants here. You have a mobile device and you have a network type. Using this, you can set up some quotas that you can, some limits that you want to not hit during development. You could say that your payload size is never going to go above, say, 100 kilobytes. That's all the JavaScript you're ever going to load. Or you can say that the number of DOM nodes you're going to put on the device are never going to exceed, say, 5,000. And once you set these quotas, it's important to make sure during the development process that you're testing to see that you're never going shooting above the quotas. So that was rule number three. I'm going to quickly talk about my tech stack. As I mentioned before, this entire project was powered by React and the React ecosystem. But by and large, the tech stack doesn't matter. If you're building a front-end app, all the principles I'm going to talk about are going to be more or less the same. And they're going to be more or less applicable across frameworks. But still, let's take a look at the tech stack we used. So we evaluated four front-end frameworks across five criterias while we were doing the project. And the main competitors were React and Angular. And the five criterias were rendering speed, payload size, availability of tooling, and whether we could render on the server or not, and community size. So React pretty much checked most of our checkboxes. Angular 2 failed at mainly payload size and the availability of tooling. The framework was pretty immature. And View and Riot, they're newcomers to the front-end framework game. And our main issue with these frameworks was that there's not enough community for us to pick it up. But as I said, the framework by and large doesn't matter. So if you'd like to talk frameworks, I'd be more than happy to answer your questions afterwards. But for now, let's just move on. And when we used React, we also bought into the React ecosystem. And we used Babel to compile our ES6 and some ES7 code down to ES5. We used Gulp to automate our tasks, WebPacks for bundling our code and optimizing our code. And WebPack is a really, really, really powerful tool. If you guys haven't checked it out yet and if you guys haven't used it in a project, I highly encourage everyone to test it out. In fact, if there's one tool out of all of this that you should learn, it's WebPack. And we used Redux for managing our data.  But more or less, we stuck to what you see on the screen right now. We actually hand rolled a lot of code for ABOF instead of using an available library. Because in a lot of cases, third-party libraries give you more features than you actually need and you end up downloading more code to your user's device than you actually need to do. So remember, be lazy. Let's take a look at the architecture of how the entire ABOF.com website is structured. And look at that. Let's look at this really bad diagram. So the interesting story about this diagram is that I was looking at my emails when I was preparing this presentation and I saw that we had actually sent this diagram to the folks at ABOF at the beginning of the project to explain to them what we were going to do. So this is our professionalism in display right here. Okay, so let's look at what happens when you load ABOF.com on your mobile device. If you follow the arrows that are labeled with the Roman numeral 1, you'll see that your client makes a request to a load balancer. And the load balancer forwards the request on to a Node.js server that's in the top-right corner, a Node.js server that's powered by a CoA.js, which is a web framework similar to Express. And the Node.js server actually is running your entire React app as a universal application in the backend. A universal application is a front-end application that can also be run on the back-end on Node without actually pulling up a web browser. So the Node.js server is actually running all of ABOF.com, everything you see on the front-end, on the back-end inside of Node. And as soon as the request hits the Node.js server, it renders some initial HTML for your user to see and sends it back to the load balancer. To render this HTML, once again, follow the arrow down to WCS, which is IBM WebSphere Commerce, which comes with the REST API. So to actually put together this initial HTML page, the Node.js server makes a request to WCS, collects all the data it needs, puts together the HTML page, renders it on the back-end, sends it back to the load balancer, and it's delivered to your client. Once the page is loaded on your client, all further requests are, if you look at Roman num num numeral 2 here, all further requests to build the page and to load more products or filter products or search or whatever, are directly going through the load balancer to WCS. So the Node.js server is no longer in the picture. And the good thing about this entire architecture is that the initial server that gets sent back from Node.js is actually cached in the load balancer. So most of the time, in fact, it gets cashed in our CDN. So most of the time, if you go to aboff.com, you're not actually even hitting our infrastructure at all. You are just pulling down some HTML that's being stored on a CDN. Only when you start looking at page number two, for example, do we actually make a REST request to the API to the aboff.com API and start loading further products? So for aboff.com, we have a very specific page which builds up the page, builds up the listing page for a product step by step. And throughout this presentation, I'm going to use that URL as an example. So if you guys want to follow along, you can load that up in your browser, load that up in your DevTools and follow along with me. And let's take a look at these three steps very quickly. Let's take a look at these three steps visually before we actually start digging deeper and talking about them. Stage one is when we render the HTML on the server or Node.js and send it down the pipe. And this is our be impatient principle in effect. So if you go to aboff.com and turn off all JavaScript, you will see something that looks like this. This is the initial HTML that gets rendered on the server and sent back. So if you can see that it has a header, it has some filters, some sorting information and a list of products. If you scroll down, you'll see that there are about 12 products on this page. There are no images. There is no interactivity because there is no JavaScript. You can't actually use a filter. You can't actually sort by popularity. You can't do anything. But because this page loads so fast because even on a slow 3G connection, this comes down in about three seconds, your users are going to begin interacting with the website pretty much immediately. And this gives your user a very specific feedback. This says, okay, something is happening. This website is loading. You have come to the right URL. And this feedback is very important when you want to prevent your user from leaving your website. You'll hear about perceived speed. So this is something that's part of improving the perceived speed of a website. Stage two is loading the JavaScript. The JavaScript will, once a JavaScript loads, it will add interactivity to the website. And then go on to load images, account information, for example, what your username is, what your email is. If you added something to the favorites, that's when that stuff gets loaded. If you have something in your cart, this is when that stuff gets loaded. And when the JavaScript loads, your page is going to look something like this. So now you see we have a hamburger menu on the top left, top right, my right. Yeah. And we have filters. We have popularity. We have all the product images loaded. And if you are paying very close attention, you'll see that we've also loaded the font. That's also something we do using JavaScript. But there's some stuff, some information that still hasn't loaded.  So when you open the hamburger menu, you'll see that the top area of the hamburger menu says, hi, guest. We still haven't loaded the user's account information. We still don't know who our user is. And the reason we defer loading this account information and we defer putting this in the initial payload is because you want to keep the initial payload really small. We don't want to show the user anything that's not necessary. This is secondary information that the user is going to probably interact with, say, five seconds or 10 seconds or maybe even 30 seconds after the page is loaded. So we don't really need to load it immediately. Once again, be lazy in effect. And if you wait a couple of seconds, you'll see that the user's account information is now loaded. Now, instead of saying, hi, guest, it says, my ABOF and clicking that will take you to your user profile. If you look at the top right, you'll see that there's a heart icon with a badge saying three. That means the user has added three things to favorites and there's a cart icon. There's nothing in the cart yet, but if you had added something to your cart, you'd see a badge there as well. So this is information that gets pulled in after the initial page is loaded, after all the images are loaded and after all the JavaScript, all our React components have essentially been initialized. The third and final stage of loading is when we load everything else. Everything else that's an add-on. So for example, third-party scripts. ABOF uses a third-party service called MeTail to add some additional functionality to the website. So this is when that third-party scripts get fetched. This is when Google Analytics get fetched. And anything else that might not be core to the user experience, this is when it gets fetched. So once again, you will observe this only if you throttle your Chrome DevTools to a really, really slow speed. If you see down there on the bottom left, there's a gray bar saying see how it fits. This is the MeTail script being loaded. And that's how an ABOF page is built up slowly, one by one, by sending down essential information first and then pulling in all the auxiliary information that's required for the page later on. And now let's dig deeper into each of these stages. Let's take a deeper look at what's happening behind the scenes. Starting with HTML. So to begin with, why load the initial HTML first? Why go through the pain of setting up a Node.js server, Node.js service somewhere in the backend and getting it to render your website? Well, the reason is that your browser will start painting to the screen as soon as it receives a little bit of HTML and CSS. So if you want to optimize your time to first paint, which is what we wanted to do for ABOF, the best strategy is to send down a small chunk of HTML and CSS down to the user as soon as possible because you want to improve the perceived speed. You want to give your users the perception of speed, even if your website is not actually fast. So sending down this initial chunk of HTML makes it feel like something is happening and it assures the user that he's typed in the correct URL, that his network is not down, that his mobile phone is still working and it just makes sure that the user stays around for the later stages of loading. And here's something really interesting. This is a small video of a website loading in Chrome. This is a new tab page and let's quickly take a look at what happens when you actually type in a URL into the URL bar and hit enter. Okay, so let's take a look at that once more. So as soon as the URL is typed, the loading indicator is different and as soon as the browser receives the first byte of data from the server, the first byte of HTML, the loading spinner becomes different and this is how most web browsers work. This is how loading indicators in most web browsers work, whether they are mobile browsers or whether they are desktop browsers. So what you ideally want to do is make that loading indicator go clockwise and dark as quickly as possible because that's the point where a user will know that the website is loading correctly and this is something we actually optimized for. We wanted our loading indicators to be clockwise and fast. We didn't want them to be anti-clockwise and slow. So for abof.com, we load the first 12 products. We render the first 12 products on the server and we send them down the wire. Depending on what kind of website you have, whether it's an e-commerce website or whether it's a web app, this is going to vary for you. For a lot of websites, loading, say, 50 products is something that works for them. For some websites, loading one or two products works best for them. This is something you will have to A-B test and figure out for yourself. Now we've looked at the how, the why of sending down HTML down the wire initially. Let's take a look at how we do it. This is a term you might have heard. This is called universal rendering or isomorphic rendering, which basically means that a web application that is intended to run in the user's browser on the front end is designed in such a way that it can also run on the back end without a browser, without a DOM, inside Node.js. And instead of rendering to the DOM, it can produce a string of HTML that can then be sent down the wire. That is called universal rendering. And if you guys are not familiar with React, there's a bit of React knowledge that's required for the best of the sections, but I'm gonna explain everything as quickly and as best as I can. A React application is basically a tree of components, a tree of UI components. And this is what the tree looks like for abof.com. In fact, if you open abof.com in Chrome and look at the React DevTools, this is the tree that you'll see. And each component inside this tree looks something like this. This is once again an example from actualabof.com source code. I hope nobody sues me. This is a component called badge. And as you can see, a component is basically a function that takes in some parameters and returns jsx. jsx is on line nine, there's a span tag. And jsx produces a virtual representation of what your UI is supposed to look like. So this code, when you actually render this component using React, this doesn't actually produce anything in your browser, it doesn't give you a DOM. It just produces an object hierarchy telling me that a badge is made up of a span and the span has certain properties. So just take a look at this screenshot on the top right next to the heart icon, there's a three. That's essentially what a badge component is doing. There's a library called React DOM that takes this virtual representation of a badge or any other component, or in fact your entire tree of components and puts it in the browser. There is another library called React Native that takes the same tree, the same virtual representation of your UI and puts it on a phone. And in the same way there is React DOM comes with a utility function called render to string which accepts a render tree, a UI tree as an argument and gives you a string of HTML. And this is how we render a React app on the backend because a React app is completely, completely divorced from the browser's DOM or any of the browser's API, we can run it anywhere there's a JavaScript runtime. So we run it on node and we use the render to string function that React DOM gives us to render our component tree to HTML and then send it down to the user. It's a little bit more involved than that, but this is something I'd be happy to talk about outside after the talk. And I can actually show you exactly how we set this up with node.js and with co-order.js. For now let's talk about stage two which is loading the JavaScript and then loading all the auxiliary information. Once again, why do we do this? Why load all the auxiliary information like account information or information about the user's bag? Why load it later on? Why not just send it down with the HTML initially? Well, this is why. When somebody comes to a webpage listing dresses or listing jeans or listing clothing, they want to look at clothing. They want to look at dresses and they want to purchase dresses or purchase whatever you're selling essentially. They don't want to look at their account information. They don't want to look at their favorites. This is all auxiliary information that's not needed at the time the user is coming to your website and every bit of auxiliary information you add to your webpage is going to add some extra costs. So you need to prioritize your user's intent. For every webpage you build, for every webpage you're optimizing, you need to figure out what is the one thing that the user is coming to this page for? What are they doing? And because of this, it's not very useful to load all the user's account information, profile information on first load. So we loaded asynchronously afterwards after the react components have been rendered, after the entire page is functional and the user can already interact with the website. And so an interesting scenario that happened to us after we built abof.com was, so the first stage of the project was just building the listing pages, listing pages and the homepage. The second stage of our project was actually optimizing the checkout flow. When you actually go to your cart and check out a product and go through the steps to actually order a product, that was the second stage of the project. And at that stage our priorities were completely reversed because for a checkout flow, you cannot proceed with checkout unless you have a user's details at hand immediately. You need to show the users what his cart looks like, what his addresses look like, what his username is in fact even. So our priorities in that case were completely reversed. We had to, we began with loading the account information and the cart information and then we loaded everything else. So once again, you have to figure out whether or whenever you're optimizing your web app what the user's intent is. At a very high level, let's take a look at how we load the JavaScript essentially because when we are rendering things on the server, we're rendering the first 12 products and sending it back to the user. We know that the page number one of our product listing has been loaded. We know that 12 products have been loaded and we have the details of all those 12 products in our browser somewhere. So how do we know how does it react when it runs on the front end after all the JavaScript has loaded? How does React know the state of the web page? How does it know what has already happened, what has already been rendered to the browser and what still needs to be rendered? How do we figure that out? Let's take a look at that at a very high level. First, React takes over. React runs and it essentially, it knows the root element where our app is being rendered and it takes over, it takes over that root element. And how it does that, if you open abof.com in your DevTools and just take a look at the Elements panel, you will see a script tag that has this huge, huge chunk of JSON that you can see on the screen. If you format this correctly, you'll see that this is what it looks like. This is a variable called initial state. Everything that happened on the server, the details of everything that happened on the server while rendering the initial HTML are present inside of this somewhere. You can see that there's information about the cart, there's information about the environment, there's entire product listing there. We know what our breadcrumbs look like, we know how many products we have, we know everything. This is the information React uses to take over the page, essentially. And this is where you need to know a little bit about Redux. This is something called a Redux reducer. And this basically takes care of our state. This is the magic source that takes care of our application state. And this is a reducer for one of our menus, our navigation menus. As you can see here, there's an initial state here that looks completely empty in the beginning. This is line nine. This is where the app starts. This is the menu, by the way. And this is our menu component. And if you look at line number 31, 32, and 33, you'll see that there's a static function available in there called prefetch. Now this static function has nothing to do with the browser once again. This is just a function that makes a rest call. So on the server, when we are pre-rendering our code, we call this prefetch function on our component that needs some data fetched. And this prefetch function will then fill in this initial state, which will be serialized as JSON, send down the wire with the page on our initial render, and then this will let React take over the page. And once React takes over the page and React is running, it then fills in the blanks. It pulls in product images asynchronously, pulls in account information, love products, bag items, site photo. If any extra information it needs, it will essentially render the page. And our components have been designed in such a way that if a component's initial state does not contain the values it needs to render itself, it will make a rest request. So if we want to pre-render a component on the server, all we need to do is define a prefetch function on that component, and that function will be called on the server and the initial state will be filled in. So when the component is rendered on the front end, it just won't make the request it needs to make to get its data because it'll already have its data. But on the front end, if you leave that initial state blank, which is to say you leave out that prefetch function, your component will make the required request on the front end and fill in its data. Okay, step three, everything else, which includes third-party scripts, analytics, and whatever else you might want to add as an add-on to the web page. Once again, why? Why do we want to render, why do we want to delay loading all these things? Well, progressive enhancement is a loaded term. It means a lot of things. It is generally referred to as adding an extra feature to a web page after it has loaded, adding an optional feature to a page after it has loaded. But in our case, we consider things like analytics as optional features as well, because analytics are really important to your business and it's really important to do user measurements, but honestly to a user and especially to a user who is already on a limited device, on a limited connection, to a user, analytics is just a roadblock. It loads down, it slows down your loading process. So you need to have some respect for users and some respect for the kind of devices and networks they are running on. And progressively load whatever third-party analytics that you need to load. So in our case, after everything is done loading, after React is loaded and all our components have fetched the data and everything is done, after the entire website is functional in all respects, only at that point do we go ahead and actually make a request to load the Google Analytics script that starts collecting data on the page. And only at that point do we start loading the third-party service we use, which is Meetail. But analytics are important and I want to take a couple of minutes to quickly talk about analytics. So when we built ABOF, when we built ABOF and we shipped an initial version of the code, we realized that we were losing a lot of analytics events and that was because we were deferring our analytics script. We completely forgot that a ton of analytics events happened on the front end while the page is loading, like your DOM content loaded event, for example. And all these events have some triggers attached to them inside of Google Analytics that let the business team measure things. So what was happening was we were losing a ton of analytic events. And how we solved this particular issue was when the page was loading, when the website was loading, if our analytics events weren't loaded yet, we simply queued them up. If our analytics script wasn't present and analytics events were happening, we just queued them up. Now this required some extra work, working with the business teams to figure out what kind of events they were interested in. But it was totally worth it because we sped up the loading time by quite a lot. And to do this, we built a Redux middleware for essentially queuing all our analytics events. And I'm going to quickly, very quickly run through this because we're running low on time. This is a Redux middleware that will quickly check to see if an analytics script is loaded or not. And if there's no analytics script loaded on the page when a particular Redux action is happening, this will just put the Redux action in a queue. So if you look at line 16, you will see there's a capture analytics event function that's called for every single event that is happening on the page. And over time, as your page builds up, you will end up with 20 or 30 analytics events inside of an array, which will then, if you look at line nine up there, as soon as your analytics script loads, your Google analytics script loads, all these events will get pushed into Google analytics. And that's how we handle the problem of actually making sure that all the analytics were being captured, as well as making sure that the analytics script was being deferred and being loaded as late as possible in the loading process. All right. So this is how a page on abov.com loads. This three-step process is why everything is so fast. And this is a general strategy that we have applied to all our other projects, which is pretty much breaking up the user flow, breaking up the loading of a page into primary data, which is the data you want to show to the user immediately. Secondary data, which is data which might be useful, but the user will interact with it later on. And third-party scripts and add-ons and progressive enhancement. And whenever we build something, we make sure that the primary data is visible to the user as quickly as possible. And that's why abov.com is so fast. There's something I haven't covered yet in this talk and something that is a talk of its own, which is app performance. We know how to load an app really fast. We know how to make it really fast. We know how to optimize the time to first paint to be as low as possible, but we also need to keep the app fast, especially for abov.com, which is an infinitely scrolling grid of products. As soon as you reach page 10 and you have 120 products loaded inside your screen, things start to get slow. And that was something that we spent a lot of time optimizing, especially on slow devices. So that is something I would really love to talk to you about. So if you want to talk about app performance, you guys can meet me outside. Testing load times is, we've already had talks about this, but I'll just tell you the tools we used. We used web page tests, page speed insights, and just loading the web page on different mobile phones, on different networks, on different Wi-Fi connections, just to see how it works. And if you've been to 12th main in Indira Nagar on a Friday night, you know how bad networks get. So you should probably go get a beer and go there with your phone and open the whatever website you're testing and try it out there, because that's the best way to test performance. Yeah. All right. Testing app performance, test on real devices, best thing to do, questions. Yeah. Hi, uncle. Yeah. Thanks for the great talk. I'm a little concerned because are you saying that time to first paint is the only thing that you considered when you're saying fastest e-commerce website?  So yeah, that's a great question. So for this talk, I concentrated mainly on time to first paint. The time to first interaction is something, would be something around a second after time to first paint because the JavaScript payload is so small. It's about that much. Yeah. On a 3G network that loads reasonably fast. And at that point you start to, you are actually able to, so because you have about the first 12 products loaded and because you have a lot of data already loaded on the page, time to first interactivity is pretty low. The React stuff mainly pulls in the images and it mainly populates the menu. So that's something that's a trade-off we made, essentially. Yeah. Did you face a problem of memory leaks? We did, yes. So how did you go about? How we did it is that we did not, but how one would do it. I think we did what we made sure that while building a React code, we were not re-rendering, we didn't need to. I can talk about that in a bit, like details about that. Basically there's a function called should component update with tells react, whether a particular component should re-render or not. We, that for all our popular components, especially the infinite scrolling grid, we were running falls from that method unless we actually wanted to re-render it. And another thing we did was make sure our DOM nodes, the number of DOM nodes we had was as low as possible. But if you are building an infinite scrolling grid, and this is something how I would have done different, is you probably want to recycle your DOM elements, which is to say that instead of loading new elements for every single product you load, have maybe 20 elements, 20 DOM elements to represent all your products. And as the user scrolls through the website, reuse those DOM elements. You don't want to increase the number of DOM elements. But besides the DOM, we didn't have any JavaScript memory leaps because the JavaScript portions of the website are not very complex. Yeah. Yeah, yeah, yeah. Okay, the question is, we're using something called visual website optimizer. Why are we using that? That's a, I think that's an SEO tool. So that's something we did not add. I think that's a business tool that the folks at ABOF used to, I think, figure out the hotspots on the webpage where people are interacting and stuff like that. I think it's a company based out of Delhi, right? Yeah. Yeah. Can you hear me? Yeah, I can hear you. My question is on the queuing of the Google Analytics events. You said you built your own middleware to queue the events. Right. Google Analytics. Oh, right. So why did you choose to do it again on your own? Okay. So the question is that Google Analytics itself lets you queue events. Why did we choose to queue events in a Redux middleware? That's a really good question. So a lot of these events that happened on the front end actually happened with us in the case of ABOF on the backend when we were doing our initial render because we were rendering the first 12 products on the server side. There were a couple of events that needed to be handled on the server. Now this is something that can be fixed with a different analysis strategy, but the business team at ABOF at that time could not overhaul their analytics strategy. So we had to be backward compatible with everything that the old website had. So essentially this was one of our page load events, which for us became time to page render on the backend. So all those events had to be queued up in the backend and then they were sent down the wire in the initial state to the front end and then we put it in Google Analytics queue. So this was kind of a hacky solution to a problem that could have been avoided, but we had to be backwards compatible, essentially. Thanks. Yeah, so you have the static HTML render from the server first and then react takes over and then replaces that. Exactly. Which if the state is same, it's going to be exactly the same. But even my boilerplate react application, I often got warnings saying that your server render is different from a client render and get that huge bunch of red text that says that reacts rendering it again. So have you experienced that and how do you make sure that it doesn't happen? I have experienced that, but I've only experienced that during development. If you actually run it on production, this sort of stuff usually doesn't happen. And I think the reason for that is if you change the markup return from one of your components, change the structure of the markup return from one of your components very drastically. For example, if you're using returning a span in one of the components and suddenly that span is replaced by another component that creates a completely different tree. I think that's when this particular behavior happens. But this will happen when you are rapidly changing code. This doesn't happen if your code is not changed. So for the most part, you don't have any visual difference between what's been rendered in the initial static HTML and what comes after react takes over, right? Right. It's perfectly the same. Yeah. Okay, thanks. Yeah.


My name is Sid and I work with a company called Playware. And Playware has been a brand since 2005. We've been doing a lot of stuff in serious games. We're essentially a serious games company. It has been a personal dream of mine to build VR, AR applications ever since like Holodeck. And that's one of those things that I've always wanted to do. And I got to do that. Actually, I got to do that pretty early. In 2007, we started building this. This is a 4DI lab. It's a 350 degree immersive cave environment with multi-touch screens. In 2007, we actually had to build our own touch screens. There were no touch screens in the market. So there's 45 square meters of interactive touch screens. It's still one of the largest touch screens in the world. We've done, we did, we sort of up the ante in 2005, 2009. What we did is we allowed students to actually connect to these touch screens with their mobile devices. And at that time, it was basically those netbook kind of things. And you could control an avatar that was on the screen with your device acting like a controller. So there were up to about 40 avatars on the screens at the same time. Again, this was part of the Future Schools project. We had a lot of funds. Singtel and NRF and a whole bunch of other people with a lot of money were backing it. So if I've seen a little cynical throughout this entire conversation and ouch, then I apologize. So I've been doing this for some time now. Yeah, and we sort of started doing big touch screens. I don't know if you've been to the Indian Heritage Center. Actually, this is not really a big screen now compared to what I just showed you earlier. But this is like the newer generation tech in terms of touch screens. And now you can basically look at historical Singapore and navigate. And this is very consumer tech. I love this project. This is a very weird project. It is a camera-based interaction. Basically, people were praying to something I made. I'm that awesome. I'm kidding. But it was pretty awesome. Just carry on. Yeah, we moved into, when VR came out, we moved into VR very quickly. And we started doing stuff with Oculus. We started doing stuff with Samsung VR. We started doing stuff with Kinect and Rumolive and stuff like that. I'm just going to show you a very quick video, not to bore you, but just to earn the chops of actually going on to say what I'm going to say in this talk. This is actually no audio. So this is the Rumolive. And basically what you can do is you can project across different kinds of screens. And you can recognize different types of objects. And depending on how you interact with the various objects, you can show different kinds of information on the various screens. And now this could be in the real world or it could also be in the virtual world. It still suspiciously looks like touch screens. But nobody cares. It's VR. This is something that we've done with some hospitals. And it's extremely disorienting. This is something that we've done with WDA. It's extremely disorienting. Just common thread going forward. There's a whole bunch of stuff. The guys just put together this video just today. So yeah, this is more interesting. You can actually, we have an authoring tool that can let you set up different kinds of content. And you can embed text files, picture files, video files, and again continue to interact with it through gestures and touch and such like and so on and so forth. This is the technology that Microsoft calls Rumolive. It's really cool in terms of the fact that it doesn't require much. It just requires a projector and a connect. It's not so cool because it requires a lot of work. This is something with Oculus we did for standard chart bank. It's actually a Formula One race simulator. And it worked along with a driving rig. So it had some haptic feedback. There was a seat that shook. There was a wheel that you moved and that moved the car. And you were sitting in with the Oculus headset. And it was supposed to be like you were driving. Most of the people who were driving were bankers and they didn't know how to drive anyways. So we didn't put collision into the cars. And so you could just basically drive through most of the stuff except the stuff. And then AR and things like that. So, so players have done a lot of projects. It's basically basically one of those serious games companies we've been doing this for a long time. And I guess you picked up on the fact that I'm not very happy about the state of current we are. This is what it promised, right? So no man's sky. I could basically essentially experience it, right? That was the whole idea. When we started moving away, where's Jonathan? Jonathan, Jonathan, Jonathan. Yes, when we started moving away from K systems the idea was that you would be able to wear this headset and then you won't need the multiple thousand dollars of investment in infrastructure that we used to need to make you feel like you were in this kind of a world. It's supposed to feel something like this, right? It's a really happy user. And he's like, oh my God, I'm in this virtual environment and it's beautiful and this butterfly. It's really touching and it's like the headset is not even there. I don't know if you've actually used Oculus or anything else. It's very much there.  The thing hits against your eye.  Had mucusy eyes and he's rubbed his mucus all over the lens. And then when you wear it, it's already like, it's unhygienic as anything. It's nothing like this. Like it never is like this, right? I've been waiting for that aha moment. We've done, I don't know, how many projects? We've done over 40 projects and all kinds of fields in serious games and we've been waiting for this. One person goes, doesn't happen. It just doesn't happen. And all the other things that you think about, right? There was going to be this beautiful thing that we are going to be able to do that you don't have to go to meetings anymore, right? You go to VR meetings. Like, I mean, as if you really, the most interesting thing about a meeting is the fact that you get out of your chair, but you didn't need to do that anymore, right? And soldiers are going to be having to use this and they're going to become really great warriors because they know how to fight.  And it's not a good sight. And let's not forget, what lies beyond, right? You're going to march forward. It's not happened, it's not happened yet. I wish it does. It hasn't happened yet, right? And so, sorry. This is what actually VR feels like, right? I don't know how many of you have actually used VR kits of all types. You have a massive blood pressure drop, sorry.   By the way, those of you who don't know that, that's Ian, Ian, sorry.  The first very successful Kickstarter campaign for an actual beautiful game. It's a beautiful game. Please go look it up. And Ian, thank you. And in your honor, that's the slide. Thanks. Okay, sorry. But actually, this is what VR feels like, right? So you get blood pressure drop. You get heart flutters. You get all kinds of different nausea feelings. You get vertigo. You get many, many different things. You have disorientation. Your eyes focus is lost when you actually take off the headset. That's a whole new set of symptoms that come in. And pretty much it doesn't make a difference which headset, which manufacturer, what device you're talking about. Most of them actually create this kind of feel. Now I actually put my trust very strongly into things like HoloLens and Magic Leap and this whole bunch of new stuff that promises to overcome some of those issues that VR seems to have today. I don't know what's gonna happen. I don't know if you guys have seen this. There's something potentially associated, whatever, factors associated with simulator sickness. This is an old study. None of these issues have been addressed. Not one of these issues have been addressed. In current VR technology, not one. It's very telling. This is stuff that's been around since before these hardware started getting manufactured. This has been around since before Oculus got a $2 billion valuation from Facebook, right? And there's a whole bunch of different kinds of issues and all of these exist today, right? Not to mention, of course, a whole slew of other problems that arise from the fact that the equipment is uncomfortable, the technology isn't actually up to speed and the experiences are subpar. Okay, so end of rant. I hope basically we don't end up like complete junkies because I think if we are going to, literally, you were talking about, Jonathan was talking about the fact that they actually decided to let people stand in one place.  If it was those people that tried to move, they would have fallen down, right? That's the problem. The tracking isn't good. The issues, there are a lot of issues with hardware. There's a lot of very subtle but very powerful signals that get mixed up, right? Now, what does this mean as developers? What does this mean as developers? What does it mean for you? Okay, here's what I think it means. Unlike Jonathan, actually I would usually encourage every one of you to go back and try to develop something for VR because I think the issue is not just with how we expect the technology to move because what we are trying to do currently is we know what games look like, what experiences look like, what interactions look like, what user experience looks like today. And we are trying to just sort of pull them all into VR for some reason, right? We're just trying to throw them all whole soul into that, you know, it'll just fit somehow. Something will stick, right? It doesn't. What we need to do is we need to start thinking about VR in a completely different way, completely new way, right? We need to think about these experiences, this content, this storytelling in a much more intimate way. You mentioned a locked room. I think that's a good idea, right? We are not there, we are not there yet. Right now we are sitting in malls, right there in the most exposed space there is, right? But how is this going to move? The only way it's going to move is if developers, if game developers, if experience developers start pushing content, thinking about content, thinking about designs that fit this paradigm, this usage paradigm, right? And why do I think that'll work? There's only one guy really actually, one of the very few people in the world was making money with VR, right? You can be that guy, okay? Thank you. I'm supposed to ask questions. I don't know if you want to, but yeah, I'm sorry, people ask questions. Yes? Because of VR and AR, when we look at VR, there's no environment in front of you, so you mentioned people getting motion sickness and stuff. Would it then be better to push forward more into AR content to VR? I personally, as a player, as a company, we are placing all our bets in AR.  I think the idea of VR is awesome, but till we actually get away from this issue of isolation, right? I don't think we can actually make very realistic. And even if it did, right? Even if face, just imagine, Oculus that completely real, right? You could wear Oculus, I could stand right here, wear Oculus, and in fact, completely real.  And you know what'll happen? Yes? What do you foresee are the most important innovations to motion control? That must be made really in the next one year. I actually, personally, I'm a designer. I believe that the most important innovations are gonna be all design-related. We are gonna set new standards for how you do storytelling with VR, and that's going to come across this, it'll just basically, mainly hugely either circumvent or completely make redundant most of these questions of trying to make the refresh rate or something as fast as a human body can react. I think that reflexive speed is gonna go away. That's, I think, that's my honest opinion. You wanna give him one? Yeah. He asked a question. Yeah, I like to know is what is the take on the, like the supplement equipments for VR, like the Omitrix system that they were having, and then there's a Europe version which is much cheaper, and I think that that would actually improve enhanced experience for VR. I actually kind of gave away my answer in this part, right? Microsoft actually has this technology called RumoLine. It's free. You can download it. It needs a projector and it needs a connect, and you're good to go. You can actually overlay all kinds of information into the real environment, and you can project a virtual environment into the real environment, and it's quite good. Best of all, it is a key technology, so it doesn't actually require you to learn new skills as a human body, right? And you can actually continue to interact with it just like you would with everyday life objects. And it actually works quite well, and I think the next thing that's gonna come very quickly, I'm really excited about the Oculus, sorry, not Oculus, the HoloLens and other AR headsets, which I think will make this thing that we think of as VR really possible, because you'll be able to scan the real world. Apart from the actual headset, how important do you think other accessories are in terms of your VR?  I don't think you need anything else to die, right? So I think the point is redundant. The point is everything else is very cool, but if you can't feel, even if you're standing still, if you can't feel comfortable in an environment, then there's no moving beyond that. Say fine, go straight. Yeah. Say fine, what I need to tell you. Some of the things that Jonathan just mentioned, right, you can't actually put a leap in front of it and then try to do hand tracking because it doesn't feel real, right? You wanna do this and that, not just this, right?  So I think one proper awareness of the human body. We work in the serious game space. So we spend a lot of time thinking about posture, body language. We think a lot about emotion. And so we're using, again, in cave environments, we're using camera vision to measure things like, are you engaged with something? Are you feeling stressed? What's your, we actually measure things like heart rate. We measure things like EEG, EMG, ECG. And so we try to get a much more holistic look at the user. It's not just about what he's trying to do, but where he is at in his emotional state because that helps us either increase or decrease the tempo of the VR application. So that's one of the things that we are trying to do, right? So I think gesture control, of course, full body motion control and all of those things help, but yeah, after a certain point. Thank you so much. I'm here for some time. If you have more questions, you can please talk to me later. Yeah, thanks. Yes, I have to ask, does he get,


The speech processor test device shows if your RONDO 2 is working correctly or not. Switch on your RONDO 2. Place the flat side of RONDO 2 under the speech processor test device. Speak into the microphone. The indicator light should flicker to the rhythm of your voice. If the indicator light doesn't flicker, adjust the volume of your voice. If it still doesn't flicker, completely charge your processor. Switch it on, then speak into the microphone again. If your RONDO 2 still isn't working or for immediate assistance, contact your CI Center.


All right, let's take a look at this so I'm checking your email So this is looking all pretty cool I got some minor notes here and there and some of the posing stuff and some of the timing That you have here and I'm gonna look at your test, which I thought was actually really cool But I see your concerns, but still I want to go through it So the major thing I see here is that and it's throughout the whole shot is I feel it's just a bit too low Right from the get-go the head is so low kind of looking at the shoe I think it would be good if at the very beginning you were a bit more relaxed, maybe a bit more like this I'm sure my scribbles are helping and then so now you have somewhere to go you go from this C curve to The reverse here you can really curl up and pull which I think is cool. Just that way we see Maybe the face is also kind of towards us. I mean he could also Almost kind of look at her and have a bit of a smile like alright. I'm ready and then he starts Hissing into this which it wouldn't really add much. I know I know we're concerned about The length of the shots, so I think just that beginning Shouldn't be too bad on your pole here to be careful. This is such a fast pole, which is technically fine But then as you go back here Hey, we're stopping a bit in the straight line and also mimics this pole I think pose wise it would be cool if maybe you're going From this back into a bigger pole very slightly this way Into that and then you can relax into this currently it feels like you're pulling really hard and it's kind of Locks in in this pose where I feel like it would overshoot and go out a bit this way You can't really stop his momentum that quickly That so instead of doing Arm out and going this way I would go further back arm out and then go into this Same thing here where we're getting a bit too low. I think it continues See that we're really low and if you start looking at silhouettes It just ends up being a bit too overlapping in spots especially through here. It gets kind of muddled So I think he has really long arms. I think you could get away with Maybe that hand goes a bit below me but cheated a bit But they can still stretch that arm and bring that shoulder lower Just so we have a bit of a clear view of what's going on here. So I know how far you can Cheat his leg but something where it is that there's more negative space between arms and the chest at least And then at the end you can go down But even here you could stay like this But then have his head up like that that way we can see his face and you can do kind of a one of those It's been drawing drawing skills, but you know like clenched teeth as he tries to lift this and then it could be Here and then when you do this The head will be already up here. Is this all one move home and Yeah, it's one big move. I was gonna say then it will be Here with a smile because it's for the camera, but no ignore that note because it is one big move But speaking of which That big move here, especially those two frames that once you spline this this is such a huge move Let's pretend you want it to be that big It will go from here and then a couple more frames your body will be over here Like if you have that much speed in your backwards move, it's gonna Take a while for momentum to settle and then to reverse right now that reverse is really really fast so This move and that immediate recovery here. It's just a bit too much and kills the weight right there That's all cool. The only thing is Careful, I notice it's just stepped and we're gonna have some more breakdowns, but a the ankle is broken here but also your knee is It's it's kind of bent towards the camera So we're kind of missing the actual shape of the leg and it's also in front of the other leg Giving us if you do a squinty test or silhouette test when you push seven on the keyboard without lights In my eye, then you have this that weird stump And then we end up being fairly straight throughout there's a bend here, but just looking at those poses here and They feel a bit too Just too straight on but I know this is just step so with breakdowns it might get better, but just be mindful of frames like this funky Goes over there Even here if you're this far at that speed leaning this far over It feels like you want to go a bit further with your roots and then go up So it does kind of work that type of arc meaning you're Here right you have all that move and see and now Imagine you're splatting this out.  I like that slow drop and bends where he's all You know a bit more straight and confident and as the confidence erodes because of this I like that it's also visually reflected in him bending and being less secure in his pose. That's pretty cool That's cool. You can probably push out that knee potentially just a bit more That leg may be here again my drawings which if they help but just bigger so still a bigger negative space between those two legs And then just timing wise. I would go and see You probably just have a little bit more of a break through here break as in a bit of a pause Bit of a slower move through here so that this is your big explosion So it's what's going on fast pause fast and right now? It's a bit one continuous thing kind of it's kind of there He's kind of push it. I would just start go if you're moving here into this and Wait with this this big move I will keep it within this family here where just a bit less a bit more contained and then suddenly that last explosion out of his arms And as it explodes again, it might pull him a bit more Meaning that he might end up You know body wise he will be here This means that it will potentially here Bigger pull from the fish All right That is that looking at this now what I really like is this This is super cute And I like how he looks at him you could even pat the pet little fish here Maybe little caressing he's completely unaware what's going on what that means for the fish or something, but it's such a cute Character is that I can email you but is that the character? There's a rig that where a kid turns into werewolf It's old old the rig. I'm sure if he unearthed that old rig And I don't think it distracts because he's fairly quiet So if I look at the kid here, right? I see this. This is super cute Look at both of them. I'm looking at the guy looking at the guy. He pulls Gets the fish and that little getting out of the way I think it's not too bad and the thing is you can have more steps Right through here, which would kind of distract from that scrunchie silhouette So it ends up being here so that this has no overlap Otherwise, it looks like he's gonna hit the kids face So you can use those quick moves while he's a bit more scrunched in then the kid stops and then he starts to live So there's a good back-and-forth and audience attention Handoff that's a term This was weird. That's the whole thing where I went like what was he going to tackle the dad You can start biting the legs like a little zombie And yeah Coming out of here. That was the only weird thing, but it's cute with the For the pose But then if you push that or if you go for that I'll push this where he gets on his toes and tries to really get into Frames, you know, it's the cameras only this high maybe puts I would actually keep both arms And he's trying to pull himself up like I would push that moment in terms of cuteness and connection And if you keep it and I know you're saying that you might not keep it But He might react a bit too soon and then yes, the question is what he's going to do. I like that. He's trying to catch him I think that's really cute What would you do? I mean he will get away and then the case just kind of by himself You know it's disappeared and the kid goes mm-hmm and runs over then jumps in the air For a pose and then you see a flash and then you freeze frame and just have the kid in a funny pose Which in a way you could almost this is gonna be way too complicated and I know I'm adding complications, but imagine He's also concerned about the camera. So he's he doesn't go this far He was kind of go around so he comes out here So that by the time the guy is here the kid is here and when the guy falls you have the fish You got the dad in the air and the kid jumps in the air with a high five or like a thumbs up And then the photo and then freeze frame and that way you can see all three in a crazy pose I know this is adding a ton of stuff, but I Have to imagine anyway That's just an idea. Why not? But I really really like this. So let's email. Let's talk this out. I'm curious I would love for you to not abandon this idea, but it's obviously your shot and I know it's it's long But I just love that little kid So cute this little Fur hat thingy So, yeah, let me know this email. Let's see what we can do with this. All right. Thank you All right There's an email you can sign up you can start whenever you want you can submit whatever you want You get 16 submissions either way like and subscribe would be awesome. All right. Thank you


Hi everyone, Joe for Jaspy's casefrakes.com doing a quick little random number block Randomizer for the Yankees Dodgers, Pillies White Toxin Cardinals for tier 1 picker team 15 Which is happening a little bit later tonight if you're looking for that video So look check our video list for that if you're watching live. Yeah, just got to wait a little bit But we'll eventually get it there Works just like our regular number block breaks, you know what happens with zero with the redemptions also Please note that there are cards that are not numbered in the set including autographs relics base cards All non numbered cards in this block of teams will be randomized to one person as one lot at the end of the break So if all the hits are Yankees Dodgers Pillies White Toxin Cardinals, and they're all not numbered Which which is possible. We're gonna randomize all the names there name on top. We'll get everything with that being said big Thanks to this group people here There are the numbers there. Let's roll it. Let's randomize it five and a five ten times hard ten for names and numbers one two three four five six seven eight nine and 10th and final time after 10 we got David down to mark hard 10 for the teams two three four five six and 10th and final time we got five down to one And of course zero will get any and all redemptions for that group of teams in that tab on the bottom of the screen Including one of one redemptions mark You'll still get live one of ones David will have five a block of numbers all ending in five Brian with eight PJ with two Daniel seven six and four PJ with three Brian once again with zero bill with nine and mark with one I'm Joe and we'll see a little bit later tonight for that tier one. Jasper's case breaks.com