Hi, I'm Layla, a community experience librarian at West Vancouver Memorial Library. And I'm here to introduce you to the library's new Climate Future Action Toolkit. And this is part of our Climate Future Initiative, which for those that don't know, is an ongoing initiative as part of our commitment to support the community, deepening learning and taking action against the climate crisis. So as part of Climate Future, we have events, so workshops, lectures, film screenings, panel discussions. There's also a climate reading challenge. And now, the Climate Future Action Toolkit. So this is the toolkit, and this little unassuming thing actually opens into this cool sort of accordion. And it is filled with tips and tools for ways that you can take action against climate change. So there's tips for reducing your carbon footprint or greenhouse gas emissions divided into five sort of themes or categories. So there's food, buildings, transportation, stuff and nature. There's also a page called Acting Together for ways that you can engage with others in the community as well as government in order to advocate for bigger changes. And then there's also as part of our reading challenge a curated list of fiction and nonfiction books as well as a list of films that are related to the environment and sustainability that we recommend you check out. And then finally, there's a page here called Climate Commitments. So this is a space for you to, once you look through the toolkit, think about three actions that you're committed to taking and write them down here to remind yourself as you go along. And then if you like, we encourage people to share their commitments with us. You can email it to us or you can submit it online. And we're gonna be sharing community commitments anonymously in order to remind people that we're all doing this work together. And if you do choose to share them with us you'll be entered into a draw to win prizes. So if you wanna grab one of these toolkits it's available in the library at the information desk which is on the main floor when you walk in just to the right. If you can't make it in right now or you wanna save paper, we have a digital version as well.  That page has all the information that's in the toolkit and then some. There's also links to community organizations and other resources. There's lists for the reading challenge and there's an online version of the climate commitments page. So you can fill it out there and submit it to us that way. There's also a list of any upcoming climate future events. So if you want to attend one of these events and you're wondering what's going on that's a great place to check. Another great way to stay informed is if you don't already to sign up for our monthly e-newsletter which we send out once a month to say what's on for the coming month and we'll be highlighting all things climate future in those newsletters. So, you know, grab one of the toolkits or visit the page online, share your commitments with us and stay tuned for more programs and ways to engage. Thanks for watching.


Hi everyone, my name is Xavye and this is the first video of the TypeScript Design Pattern series. In the upcoming videos, I will show you how to use these patterns in TypeScript. To follow along with this series, you will need some basic knowledge of object-oriented programming and TypeScript. If you don't know anything about TypeScript, check out my series about it here. So what are design patterns and why would you want to use them? While many problems in programming have already been solved by others and don't require you to solve them again. Some of these solutions are so generic that they are called a design pattern. The benefits of using design patterns are clear.  Secondly, design patterns help you increase the quality of your code because these patterns were designed with extendability and flexibility in mind. They will also help you avoid common mistakes. And when design patterns are used in teams, it allows developers to quickly understand other people's code because they'll likely recognize some of these patterns. In this series, I'll show you how to use and implement design patterns in TypeScript. I'll show you patterns like decorator, strategy, observer, facade and adapter. I'll also keep adding videos to this series in the future, so make sure to subscribe to my channel so you won't miss a beat. Hi everyone, my name is Xavier and in this video we'll be taking a look at how you can use the decorator pattern in TypeScript. Just one remark before we start. The decorator pattern has nothing to do with the decorator's feature in TypeScript. It's a bit confusing but decorators in TypeScript are basically like annotations in Java. In this video, we will discuss the pattern and not the feature. A decorator pattern is useful for when you want to allow objects to have different options. I'll explain with an example. Let's assume that you're in charge of writing the ordering software for Tesla cars. A customer has to choose between either the Model S or the Model X, nothing too fancy, but these cars have many different options that you can choose. A customer might pick the improved autopilot or the smart air suspension or maybe both. Every option has a different effect on the price. In this example, the options that Tesla give you decorate your car, hence the name decorator pattern. You basically take a base class, say the Model S, instantiate it and then wrap many options around it. This is much better than giving your Model S class a list of properties like has smart air suspension and then calculating the total price by checking if these properties are set to true. So let's dive into the code and take a look at how you can develop such a system with the decorator pattern. Okay, so here I am in Visual Studio Code ready to show you how the decorator pattern actually works. So I've created two classes, the Model S and the Model X class. And both of these have a description and they have a method cost, which returns the base cost of this car. So the Model S costs $73,000 while the Model X costs $77,000.  So let's start by creating an abstract class, car. So we're creating an abstract class here because there should be no instance of car. There should only be an instance of the Model S or the Model X, never just a generic car. Now this class will have a description as both of these cars already have, which is of type string. It should also have a method get description, which should return a string. And the method will look like this return this dot description, pretty simple. And we will also create an abstract, an abstract method cost that will return a number. So now I'm going to go to the Model S and say that this extends the car class and I'm going to do the same for the Model X and say that it also extends the car class. Okay, so next up we will define a class for all of our options that we can choose for our Model S and our Model X. For example, we might choose the Enhanced Autopilot. So for this, I'm going to create a new abstract class and I'm going to call this class car options. And I'm going to say that this extends car. This will be very important later on. So a car option will decorate a car. So we're going to keep a reference to the car that we decorate. We're going to call that decorated car. And I'm also going to say that this should override the get description method, which returns a string. And it should override the cost method, which should return a number. Okay, so that's our class for car options. Now let's create an actual car option. So let's create a class. Let's say Enhanced Autopilot. That's one of the options that you want to offer on our Teslas. And we're going to say that this extends car options. And Visual Studio Code will complain now. It will say that I need to implement some elements of car options here. So I'm going to click on that and it will generate the methods that I need to override. So the first one that I have to override is get description. So I'm going to do that right here. I'm going to say, well, we're going to return the description of the car that we decorate. And then we're going to append the name of our options. So we're going to say Enhanced Autopilot. Okay, now we're going to do the same for the cost here. We're going to say that the cost of this option equals the cost of the decorated car plus the cost of this option. So for example, we're going to charge $5,000 for the Enhanced Autopilot. Now there's one more thing missing. We need to fill in this decorated car property. So I'm going to make a constructor. And this constructor will receive a car, which will be of type car. And we're just going to say this dot decorated car equals car. And of course, we also have to call it super. Okay, so that's it. When we create a new Enhanced Autopilot option, we're going to give it an instance of car, which could be a Model S or a Model X. And then when we ask the cost of this option, we're just going to take the Model S or the Model X that we're decorating. We're going to take that cost and add $5,000 to it. So let's make another one. I'm going to copy and paste this class here. And let's say we also want to offer people rear-facing seats. So I'm going to add rear-facing seats here. We're going to keep the decorated car. We're going to keep the constructor. We're going to keep the description. But now we're going to change it. We're going to say rear-facing seats because that's what this option is all about. And we're going to charge $4,000 for the rear-facing seats. So how do you now use this decorated pattern? Well, we're going to start by creating an instance of a Tesla. So I'm going to say my Tesla equals a new Model S. And now I'm going to say my Tesla equals a option. For example, new, let's say I want the rear-facing seats. Rear-facing seats. And I'm going to pass along my Tesla so that it can decorate my car. So let's now take a look at what it looks like if we run this. I'm going to say console log my tesla.cost. And we're going to log the description of my Tesla. Get description. So let's open up the terminal now. Oops. And let's run the TypeScript compiler on this. And let's also run it in Node at the same time. There we go. All right, so here we can see that my Tesla will cost $77,000. That will be the Model S with rear-facing seats. So that seems about right. Our Model S costs $73,000 plus the $4,000 for the rear-facing seats gives us $77,000. Now let's say the customer also wants another option. Let's say he wants the enhanced autopilot. Well, all we have to do is say my Tesla equals new autopilot, new enhanced autopilot, I'm sorry. And give it again my Tesla so we can wrap around that object. And now if I run it again, our price has bumped up to $82,000 and the description of our car is now Model S with rear-facing seats and enhanced autopilot. So that's a simple example of how you can use the decorator pattern to decorate classes in TypeScript. Now I just want to end the video by showing you the UML diagram of the decorator pattern. Here we have four components. We have two abstract classes. The first abstract class is called component and it has an operation. In my example, this was the abstract car class with the operation cost. We also have the abstract decorator class. In my example, this was the abstract class car options. Then we have concrete classes for both of these. So in my example, the concrete components were Model S and Model X. And the concrete components for the decorator were the rear-facing seats and the enhanced autopilot. As you can see in this diagram, the decorator also keeps a reference to the component that it is decorating. And it also overrides the same operation. So that was it for this video. I hope you liked it and if you did, make sure to subscribe to this channel so you won't miss new videos. And if you want to learn more about design patterns in TypeScript, check out the rest of the videos in this series. Hi everyone, my name is Xavier and in this video we'll be taking a look at how you can use the observer pattern in TypeScript. So what is this pattern about? Well, often when one part of your application changes, other parts need to be updated. This is the kind of problem that you can solve with the observer pattern. Now, if you have already developed a web application, then you probably already know this pattern. You've probably used onClick or onChange handlers to detect when a user clicks on something or when he changes some text in a form. In this video, we'll take a look at how you can implement the observer pattern yourself. So let's get started. Okay, so here I am in Visual Studio Code. And in this video, we're gonna write a weather station. So I've already set up a weather station class and a temperature display class. Now it's pretty obvious that the temperature display should update every time that the weather station records a new temperature. So the weather station has a private attribute temperature, which is of course a number, and then it has a set method for temperature, and then it just outputs to the log weather station new temperature measure, and then it outputs the temperature, and then it also sets the temperature attribute. So that's pretty simple. Now with this example, we call the weather station a subject because other classes can monitor that class. And we call the temperature display an observer because that one observes another object. Temperature display observes changes in the weather station. So we're gonna start by creating two interfaces for subjects and observers. So I'm gonna create one for subject, and I'm also gonna create one for observer. Now a subject needs three methods. The first one is register observer, and we're gonna get an observer object in here. What this allows us to do is it allows our temperature display, for example, to register itself as an observer with the weather station. So the weather station then knows that it should notify the temperature display of any changes. We're also gonna create a method remove observer, just in case that we want to stop being notified of changes in the temperature, and then we're gonna create a method notify observers because if a change happens in our subject, it should notify all its observers. Okay, so that's it for subject. Let's now move over to observer. This one should have only one method that's update. And in our case, when we update, we will pass along the temperature to a subject. So if the temperature changes in the weather station, it will call the update method on an observer class and pass along the temperature. So let's now implement these interfaces. So I'm gonna say that the weather station implements the subject. And this is gonna throw an error because I have three methods that I need to implement. So I'm gonna say implement missing methods. There we go. So here we've got register observer, remove observer and notify observer. So we're gonna implement them one by one. The first one is register observer. Now what we wanna do here is we wanna keep track of this observer that we get here as a parameter. So I'm gonna create a new private attribute for a weather station. I'm gonna call this observers. And this is gonna be an array of observer objects. And I'm gonna initialize it as an empty array. So when someone wants to be notified of changes in our weather station, well, that he calls the register observer with a reference to himself. And all that we're gonna do is we're gonna say this dot observers dot push O. So we're gonna keep track of this observer. That's everything that the register observer method should do. Now let's do the remove observer. If someone wants to be removed as an observer, well, then we first have to look where he's positioned in our array. So we're gonna fetch the index by saying this dot observers dot index of O. So we're gonna look up where he is in our array. And when we know his location, then we're gonna say this dot observers dot splice. And we're gonna take away the element at the index. So that's the remove observer method. Still pretty simple, pretty straightforward. We're just manipulating an array here. Now comes the notify observers. Every time that something changes in our weather station, we should notify all of our observers. So we'll need a for loop. So we're gonna iterate over all the observers. I'm gonna say observer of this dot observers. Just loop over them. And we're gonna call the update method on each observer and we're gonna give it our current temperature. Okay, so that said, there's just one more thing that we need to do. Every time that our temperature changes, we're gonna call the set temperature method. And then we also wanna notify observers. So we're just gonna say notify, we're gonna say this dot notify observer. And actually let's make this plural because there could be multiple notify observers. There we go. And also gonna change it here in the interface. Okay, so that's everything that we need to do in our weather station. Now we can go and implement our observers. So in this case, we have temperature display. We're gonna say that this implements the observer interface. Then it's gonna complain again because I need to implement some methods. There we go. And temperature display has only one method and that's update. So whenever the temperature updates, we wanna do some logic in here, but I'm just gonna fake some logic. I'm just gonna say, I'm just gonna log something to the console. I'm gonna say temperature display. I need to update my display, for example. All right, and then your logic would go here. Now that's not enough. We need to actually say to the weather station that our temperature display wants to be notified of changes. So let's do that right now. Let's create a private attribute here. We're gonna say that we observe a subject. Should be a type subject. And we're also gonna create a constructor in which we're gonna receive the weather station, which is a subject. And we're just gonna keep track of the subject. So we're gonna say this subject equals the weather station. And then we're gonna register ourselves with the weather station. So we're gonna say weatherstation.registerObserver and we're gonna register ourselves as an observer because our temperature display wants to know when changes happen to the temperature. Okay, so that's it for the temperature display. Let's now create another observer. This is the beauty of this pattern. You can have many observers that will be notified when a single element in your code base changes. In this case, it's our weather station. So let's say I also wanna have a fan. So I'm gonna copy paste the temperature display. I'm gonna create a class fan. I'm gonna leave the private attribute here intact. I'm also gonna leave the constructor as is. And then we're gonna change the update method. So the first thing that we're gonna do is we're gonna write some logic in here. What I want is I want the fan to automatically turn on when the temperature is above 25 degrees Celsius, for example. So here I'm gonna say, well, if the temperature is higher than 25 Celsius, then we need to turn on the fan, for example. So we're gonna say it's hot here, turning myself on.  And if it's colder than that, we're gonna say fan, it's nice and cool. And we're gonna turn myself off. There we go. And again, here should come some real logic and not just a console log. Okay, so that's it. Now, how do you use the observer pattern? Well, you just create instances and pass references along. So the first thing that we're gonna do is we're gonna create our own weather station. So we're gonna say new weather station. There we go. And then we're gonna create an instance of our temperature display. Gonna say new temperature display. And we're gonna give it our weather station so it can ask the weather station to be kept in the loop. We're gonna do the same for the fan. So we're gonna say fan is new fan. And we're also gonna give it a reference to the weather station. There we go. And now we're gonna play with it a bit. So we're gonna say weather station. We're gonna simulate a temperature change. So we're gonna say that the temperature is now 20 degrees Celsius. And then we're gonna duplicate this line. And after a while, we're gonna say, oh, the temperature rises to, for example, 30 degrees. Okay, let's now take a look at what will happen. So I'm gonna run the TypeScript compiler to compile this to JavaScript. And then I'm gonna run it in Node to see the output. Now, as you can see, when I say set temperature 20, our weather station says the new temperature measurement is 20. And immediately followed by that, the temperature display is gonna say, oh, I need to update my display. And the fan will say, it's nice and cool. I can turn myself off. That's exactly what we want. We made a change to our weather station and it automatically notified all of the observers that are subscribed to changes in the weather station. So when we set the temperature to 30, the weather station does the same thing. It says that the new temperature measurement is 30 degrees. And this triggers the temperature display and the fan to update themselves. So the temperature display now says, well, I need to update my display. And the fan says, ooh, it's hot here. I'm gonna turn myself on. So this is a simple example of how you can use the observer pattern. So let's quickly recap in what we have learned in this video. This is the UML diagram for the observer pattern. And as you can see, we have an interface for an observer and we have an interface for subject. Then we create concrete observers that have the notify method. In our case, that was the fan and the temperature display. On the subject side, we also create a concrete subject, although that's not shown here on the UML. And that one is responsible for keeping track of all the observers. So it has register observer, unregister observer and notify observers. And you can also see that whenever you call the notify observers method, it should run over all of its observers and call the notify function on each and every one of them. So that was it for this video. If you liked it, make sure to subscribe to my channel. It really helps me out a lot. If you wanna learn more about TypeScript or TypeScript design patterns, check out the next videos in these series. Hi everyone, my name is Xavier and in this video, we will be taking a look at how we can use the facade pattern in TypeScript. This pattern is used to hide a lot of complexity behind a single method. I'll use a home theater system as an example because those can be quite complex to control and set up for a particular use case. So let's take a look at the code. Okay, so here I am in Visual Studio Code and I've already created classes for some of the devices in my home theater setup. So I've created a class for Blu-ray player, for an amplifier, some lights, a TV, and a popcorn maker. Now let's assume that I wanna start watching movie. Every time I wanna watch a movie, I have to do certain things. I have to turn on my Blu-ray player. I have to press play on it. I have to turn on my amplifier. I have to set the volume. I have to set the source of my amplifier. I have to dim the lights. I have to turn my TV on and I have to turn on the popcorn maker and start popping some popcorn. Now that's a lot of complexity and it's also not practical if there are multiple places in my code where I want to start watching a movie because then I would need to copy and paste all these instructions. Instead what we can do is we can create a facade. This is a class that will hide all the complexity behind a single method. So let's do that right now. I'm gonna start by creating a new class and I'm gonna call my class home theater facade. And this class will have an attribute for each of the devices that we want to control. So in my case, it's a Blu-ray player which should be of type Blu-ray player. We should have an amp type amplifier. We should have some lights. We should have a TV and of course a popcorn maker which should be of type popcorn maker. Okay, there we go. Now the constructor of the home theater facade will receive all these devices, an instance of all of these devices. So I'm gonna repeat some of the code here. There we go. And all what we're gonna do in the constructor is we're gonna keep track of these devices. So we're gonna say this amp equals the amp that we got in the constructor. This Blu-ray equals the Blu-ray that we got in the constructor. Okay, there we go. Now we're ready to set up our actual facade. So let's say that there are multiple places in my code where I want to start watching movie. I want to set up all of my devices to watch a movie. Well, in this case, I'm gonna create a method called watch movie. And this method is gonna prepare my entire setup for watching a movie. So what we can do is we can ask the popcorn maker to turn on. And the popcorn maker should start popping some corn. There we go. We should also dim the lights. We should definitely turn the TV on because otherwise we won't be able to watch our movie. We're gonna also turn on the amplifier. And we're gonna set the source of the amplifier to Blu-ray. These are fake methods. By the way, you have to substitute these for your own implementations. And then we're gonna set the volume of the amplifier. So in this case, we're gonna turn it up to 11.  And we're gonna have to start playing the movie. Okay, so that's the facade method for when I want to start watching a movie. And I can do the same for when I'm actually done watching a movie. So I can say, well, public end movie. And then we can do some other stuff like we can turn off the popcorn maker. We can turn off the amp. And we can turn off the TV. And turn off the Blu-ray. Okay, there we go. So now we've actually placed all of this complex behavior in this setup process. We've placed that behind a single method, a facade if you want. So how do you use it? Well, very simple. You start by creating an instance of each of your devices that your facade needs. So I'm gonna start by creating a Blu-ray player, an amplifier, some lights, a TV, and the popcorn maker. And then we're gonna create a new home theater facade. So I'm gonna call mine home theater. I'm gonna say new home theater facade. This will receive all of the instances that we've just created. So with Blu-ray player, some lights, a TV, and the popcorn maker. All right. And now we can call one of the methods in our facade to start watching a movie, for example. Just say watch movie. And the facade will take care of all the complex setup process that is involved in start watching a movie. And the nice thing about this is, is that you can use this single line throughout your code. And you can keep all of this setup code centralized in a single class. That is the strength of the facade pattern. The facade pattern is a really simple pattern, really straightforward, but it allows you to keep your code short and to the point, and it prevents you from having to retype this entire setup over and over again. Also, the facade pattern is very future-proof because if one day you decide to add a device to the mix, then all you have to do is change up these instructions, and then it's changed in all the places of your code. So this was a very simple example of how the facade pattern can be implemented in TypeScript. I really hope you liked this video, and if you did, make sure to hit the thumbs up button or to subscribe to my channel. It really helps me out a lot. If you wanna learn more about design patterns in TypeScript, make sure to check out the rest of these series. Thank you very much for watching, and I'll see you in the next one. Hi everyone, my name is Xavier, and in this video we'll be taking a look at the adapter pattern. This pattern allows you to make different classes with different interfaces to work together without changing their source code. You can compare it to adapters in real life. Say you're traveling from the United States to Europe. If you wanna charge your devices, you will need an adapter to convert the European wall outlet to a US one. In this case, the adapter should implement the European plug and expose the US plug for you to use. So let's take a look at how you can implement that in TypeScript. Okay, so here I am in Visual Studio Code, and I've already created two classes to show you how the adapter pattern works. I've created an iPhone 7 class and a Google Pixel class. Now, the iPhone uses a lightning port to charge while the Google Pixel uses micro USB. So say we want to charge our iPhone with a micro USB cable that we need an adapter to change the port to lightning. So the first thing that I'm gonna do is I'm gonna create two interfaces for each of these devices. So I'm gonna make an interface for iPhone and I'm gonna make an interface for Android devices. And both of these interfaces will receive a method that is tied to their port. So for Android, that will be the method use micro USB. And for the iPhone, we will add a method use lightning. And of course, the iPhone implements the iPhone interface and the Google Pixel implements the Android interface. Okay, so far, so good. So now we're going to define the adapter. So I'm gonna create a new class and I'm gonna call this class lightning to micro USB adapter. And I'm gonna say that this implements the Android interface. So if I wanna make the iPhone compatible with micro USB, then I have to make an adapter that implements micro USB but internally can convert it to lightning. So the first thing that we need to do is we need to implement the missing elements from Android. We're gonna do that right now. There we go. We got a method use micro USB. Now before I implement this, we also need a device. And so in this case, we want to make our iPhone compatible with micro USB. So I'm gonna keep track of an iPhone device. And we're gonna receive that iPhone device through our constructor. So our constructor will receive an iPhone, which is of type iPhone. And we'll just keep a track of it. So we'll say that this iPhone device equals the iPhone that we got in the constructor. Okay, so through this adapter, we can now use the micro USB function, but we need to convert it still. We need to map it to something that the iPhone understands. So I'm gonna say, first we're gonna write something to the console. So we're gonna say want to use micro USB, converting to lightning. Okay, and then we're gonna say this dot iPhone device use lightning. So even though the iPhone is not compatible with micro USB, it only has use lightning, we can make it compatible with this adapter. This adapter will implement the micro USB function and internally translate it to something that the iPhone can understand. Now this example is really simple. We just call another method, but in a more complex code base, it could just as well be that you need to convert some arguments and do more complex setup work. So how do you use this interface? Well, I'm gonna create an instance of the iPhone 7 here. So I'm gonna say is a new iPhone 7. And if I want to charge it with micro USB, I'm also gonna create a charge adapter, which is of course a new lightning to micro USB adapter. And I'm gonna give it my iPhone in its constructor. And now we can ask the charge adapter to use micro USB. So let's take a look at what happens when I run this. So I'm gonna open up the terminal here and I'm gonna run the TypeScript compiler on adapter and simultaneously I'm gonna run it in Node.js. Let's see what happens. Okay, so notice that it says, okay, we want to use micro USB, but we need to convert it to lightning because that's what our iPhone uses. And then our iPhone says, hey, I'm using the lightning port. So what's great about the adapter pattern is that I don't need to change the iPhone class to be compatible with micro USB. I only create a new class, an adapter class that handles all the translations. So in this case, the adapter class handles translating the micro USB code into lightning. And so again, in a real code base, this can be much more complex. You might need to change the order of the arguments or you might need to convert them to other types or you might need to use many classes to accomplish something like this. I hope this simple example illustrates how you can use the adapter pattern in TypeScript. If you wanna learn more design patterns in TypeScript, make sure to subscribe to my channel. Thank you very much for watching this video and I hope to see you in the next one. Hi everyone, my name is Xavier and in this video we're going to take a look at how you can use the state pattern in TypeScript. This pattern is used to keep track of the state of a process. In this video, I'll use an order on amazon.com as an example. Here's a simple diagram showing what the process could look like. It's a bit simplified, but it will do for this example. Each arrow represents an action that the system can take and each box represents the state of the order. It starts when the customer places an order. At that point, we should verify the payment. After it is verified, it moves to the order being prepared state. In these states, the user has the option to cancel but it should not be possible to move directly to order shipped state or to any of the previous states. So let's take a look at how you can implement a system like this in a way that is flexible and future proof. Okay, so here I am in Visual Studio Code and I've already created a simple class for our order and I've given it a constructor, pretty basic. Now our order has a state that can be order being prepared, order shipped, payment pending, canceled order, and so on and so on. So to start with, I'm gonna define an interface for the state. So I'm gonna call my interface state, obviously. And each state is going to keep track of the order it is assigned to and each state will have three methods to move it to another state. So in case of an order, we want to be able to cancel our order, verify the payment of our order or ship an order. So I'm gonna write that down. I'm gonna say cancel order, verify payments and ship order. Now it's very important that all states have these methods. Next up, we'll give our order class a property called current state. And that's of course gonna be of type state. And we're also gonna create a setter that is gonna receive a state. And then we're gonna say this.currentState equals state. And we're gonna create a getter as well, getState, which is gonna return a state object. And this is just gonna do return this.currentState. So now I'm gonna create our first state. So when you place your order with Amazon, your order has a payment pending state. Amazon still has to verify your payment method and charge your credit card. So I'm gonna create that class. I'm gonna create payment pending state. That class obviously implements our state interface that we've just defined. And Visual Studio Code will complain. I'm gonna implement the messing elements. And there we go. We now've got our pending state class. I'm also gonna give it a constructor because here we have an order property, but we need to fill that in. So when we're creating a new payment pending state, we're gonna receive an order object in our constructor. And we're just gonna keep track of this order. So I'm gonna create three more classes of this. You're just gonna copy and paste this. We're gonna implement these methods later on. So we have payment pending. We also have a canceled order state. We also have a order being prepared state. And I'm gonna create a order shipped state. At that point in this state, everything is final. Your order has shipped. You cannot cancel it anymore. You cannot verify your payment anymore. That has already happened. So I'm gonna scroll up and I'm gonna go to the order class. And I'm gonna create four properties in this order class, one property for each of the possible states that it can be in. So I'm gonna fast forward the video, but this is what I'm gonna do. Okay, and in the constructor, we're gonna initialize each of these states. So we're gonna say this.canceledOrder equals newCanceledOrderState. And we're gonna give it a reference of this current order. And again, I'm gonna fast forward the video here. Okay. And when we create a new order, we're gonna set its state by default. That's gonna be the payment pending state. So when we create a new order, we're gonna place it in the payment pending order state. That's pretty simple. So now we can start implementing our actual states. So let's start with the payment pending state. If our payment is pending, we can still cancel it. So we're gonna override this method and we're gonna say cancelling your unpaid order. And when that's done, we have to set the state of our order to the canceledOrderState. There we go. So let's continue on. If the payment is pending, we sure as hell can verify the payment. So we're gonna say console.log payment verified, shipping soon, for example. And then we're gonna copy this line that we're gonna move the state along. We're gonna set the state of the order not to the canceledOrderState, but to the order being prepared state. Now, if our payment is pending, can we ship it? Well, no, because we need to wait until the payment has been verified. So all we're gonna do here is we're gonna say we cannot ship the order when payment is pending. So at this stage, when your order is in payment pending state, you can call, you can ask it to ship the order, but the system will just say, you know, I cannot do that and it will stay in the payment pending state. So let's go to the canceledOrderState. If your order is canceled, you cannot really cancel it again. So you're gonna say your order has already been canceled. And then we're gonna do nothing more. Same thing goes for verify payment. You cannot verify your payment anymore if your order has been canceled. And we also cannot ship an order that was canceled. So we can say order cannot ship it was canceled. So on to the next one, order being prepared state. If your order is being prepared, you can actually still cancel it. Well, with Amazon, you can cancel the order just until the moment that it's been shipped. So we can say cancelling your order. And then we're gonna copy the same line here. There we go. But we're gonna set the state to canceledOrderState. So for verify payment, we cannot really verify our payment because we've already done that at this point. Already verified your payment. And when our order is being prepared, you can of course ship it. So we're gonna say shipping your order now. And then we're gonna move the state along. We're gonna say that the order is now in the order shipped state. So let's now go on to the final order, the order shipped state. If an order is shipped, you cannot cancel it. You cannot verify the payment anymore. And of course, if it's shipped, you cannot reship it again. So these methods should be just empty methods or methods that tell the user that it cannot do any of these things. You cannot cancel, already shipped. You cannot verify payment because your order has already shipped. Whoops. And you cannot ship it again because it has already shipped. So that's basically how the state pattern works. You create an interface with all the methods that move your state along. So cancel order, verify payment, ship order. And then you make a class for each state that your order can be in and you implement all of these methods. And these methods are responsible for moving the state of your order along. So let's now see how you actually use this. So I'm gonna start by creating an order. And so I'm gonna say order new order. And let's just write a message to the screen that says the order state. And then we're gonna display the state. So we're gonna cast it to an object, to any object. We're gonna say order dot get state. Then we're gonna call the constructor and we're gonna echo the name of the constructor so we can see which state the order is currently in. So let me run this code right now to show you. So we're gonna run the TypeScript compiler and then we're gonna run it in Node.js. And there you go. When we've created a new order, our order is in the payment pending state. That's pretty obvious. So let's say at this point, our system tries to ship the order. So I'm gonna say order dot get state. And we want this order to ship. Let's do that right now. Let's compile it again. And now it says we cannot ship the order when payment is pending and the order state stays at payment pending. So it hasn't moved to the shipped order state because that's actually not allowed by our process. Okay, so if that's not allowed, let's do verify payment and let's run it again. And this time you can see payment has been verified shipping soon and the state of our order has changed to order being prepared. Okay, so we can do more stuff but I cannot verify it again. If I do it again and I run it, it will say that my payment has been verified shipping soon but when I run verify payment again, it will say, hey, you've already verified your payment and the order is again in the order being prepared state. So just to complete the cycle, after verifying the payment, we should ship the order. So if I run it now, it will say the payment is verified, we're shipping your order now and the current state of my order is in the order shipped state. Now let's say I want to try and cancel my order now. Well, then it will say that that is not possible because it has already shipped. So you can see payment verified, we're shipping your order and then you cannot cancel at this point anymore because your order has already shipped. So that was it for this video. I hope that this simple example made clear how you can use the state pattern. The state pattern is ideal to keep track of a specific process, in this case, shipping an order to the customer. It's also very flexible because at any time I can add more states to my system and all I have to do is add methods to my states. It's also very secure because I can define what is possible and what is not possible at each given state. So in this example, there is a rule that says once an order has shipped, you cannot cancel it anymore. So thank you very much for watching. I hope you liked this video. Make sure to subscribe to my channel if you want to learn more about TypeScript design patterns. And as always, I'll see you in the next video.


Hi. Good morning, everybody. Yeah, my name is Paul. I work on AMP. And I'm also on the DevRel team at Google. And I'm really going to skip that mostly, right? Unless you literally just arrived, you've heard about progressive web apps. They have to turn your site into reliable, fast, and engaging experience. But what if you built the most amazing progressive web app and nobody discovers it? It doesn't wait long enough until the service worker has installed your app shell to make subsequent loads snappy. Keep in mind that the service worker is awesome, but doesn't hear about all with the first load. Even though the service worker API allows you to cache away all of site's assets from almost instant subsequent load, like when meeting someone new, it's really about the first impression that matters. If the first load takes more than three seconds, then our latest double-click study has shown that more than 53% of all users will drop off. So half of your audience will never, ever get to see your content. Now, in three seconds, let's be real. It is an already brutal target on mobile connections that often average around a 300 milliseconds latency and come with other constraints such as limited bandwidth and establish a signal. And so you might be left with a total load performance budget of less than a second to actually do the thing. It's meant to do, to initialize your site or app. But don't worry, it gets worse. By the way, if you really want to load in under one second, says Rayl, they're writing that number itself from a book on usability by Jacob Nielsen. Is site does more than three roundtips to server? Well, sorry, you probably failed. So don't feel too bad, though. The overall landscape of today's web looks a lot grimmer. The average mobile page loads in about 19 seconds with 77% of those taking more than 10 seconds to load. Now, the crazy thing about the 10 second mark is that at 10 seconds, actually 100% of all your users bounce. So at 10 seconds, no one will ever get to see your site. And then it's 214 server requests, of 50% of which are at related requests. So at first click, that first impression is what matters. We want to get rid of slow loading pages, but also solve runtime performance so you can scroll really efficiently and other usability issues at the same time. And fortunately, we have a solution for it, or we think we have a solution for it. We call it accelerated mobile pages. AMP short for accelerated mobile pages is an ecosystem consisting of a web components library that allows you to declaratively write HTML. We call AMP HTML, because it's both a superset and a subset and AMP caches. Basically, CDNs are more technically correct reverse proxies that accelerate delivery on top of that. And then so you can do it in two ways, actually. You can either just build one, use AMP like a library, build just one page, and you have one canonical page for everything, or you can use a link to MetaTek and the header, and then just generate two pages in your CMS and create one HTML page and one AMP HTML page. But that's really up to you, whatever you prefer. And in that shell, it turns author pages into a highly portable, fast and user-friendly units that platforms like Google, Bing, or Pinterest can safely and quickly embed. And so it's a really rich and growing library of web components. Now, a lot of the baked-in performance optimizations you could probably do yourself if you're an experienced developer. But the AMP cache onto itself is actually a very important component, not just because it's a free, super-fast CDN. The AMP cache works tightly together with the prioritized loading and static layout system of AMP. Documents served from the AMP cache are much cheaper to pre-render, because AMP knows where each page element is positioned, even before any assets are loaded. So allowing you to load the first viewport without any low priority third-party stuff. And the actual site owner won't ever know about the preload, which is another very interesting point. Super important for privacy reasons, as the site could otherwise write cookies and mark the page as seen.  Sorry for putting that image in your head, by the way. So AMP pages are really just HTML and CSS. You can't have any user authored JavaScript on the page. That's one limitation. Instead, a lot of custom elements. And sandbox AMP iframes allow you to still do everything if you want to do something like a crazy animated graph or something that is really custom to your page. And then the AMP open source library is the same everywhere. So it's hosted on one CDN URL and you include it from there. And that means it's evergreen. It's highly cacheable. We can upgrade all AMP pages in less than a couple of days, couple hours maybe, even if we have an important fix to do. And it defines the behaviors for those custom elements and manages rendering and resource loading to optimize performance. Now, the important question that might come up in your head is, do you want to go AMP or PWA? You learned a lot about progressive web apps already in the last couple of sessions. And we've been hearing that question constantly. But in order to be reliably fast, you need to live with some constraints when implementing AMP pages.  So from a progressive web app, you won't get that first click experience. But with AMP, you don't have a custom service worker when it's loaded on the AMP cache. So you can't do anything fancy in there. It means no push notifications, no web app manifest from serve from the cache. And so if something isn't available as a component, you can't just hack a script together, for instance, to support web payments or push notifications. Now, those of you that already read about the individual advantages and disadvantages of progressive web app versus AMP have surely struggled with this question before. And on one hand, now, you have instant delivery, almost instant delivery, optimized discovery. But then, again, no user scripts, and mostly for static content. On the other hand, you have, on the PWA side, you have advanced platform features. Of course, you can build everything you want really, highly dynamic, but it's a slower first delivery. And really, again, the first delivery is highly important. And it's not easily embedded in third party platforms as well as AMP. So what if there was a way to combine those two, to really reap the benefits from both? In the end, what I think is what matters is the user journey. The first hop to your site should feel almost instant. And the browsing experience should get more and more engaging afterwards. Now, AMP and progressive web app are both critical components to make that happen. AMP pages for the first navigation and then your progressive web app for the onward journey. Now, let's first talk about AMP as progressive web app. Because I won't cover this in detail in this talk, but it's important to note that many sites won't ever need things out of the boundaries of AMP. AMP by example.com, for instance, which is an examples page that the AMP team uses to showcase a lot of AMP components, is both an AMP page and a progressive web app at the same time. So it has a service worker, therefore allows offline access and more. And it has a manifest prompting the add to home screen banner. Now, you might have heard me saying, well, you can't have those things, but that only means you can't have those things at AMP when it's served from the AMP cache, meaning the first time you might click on it on a platform like Google Search, you won't get those benefits. But the next time you click out, you actually get it. So once you arrive on the origin, the service worker installs and does a lot of fancy things. So when a user visits ampbyexample.com from Search, then clicks on another link on that site. You navigate away from the AMP cache to the origin. The site still uses the AMP library, of course. But since it now lives on the origin, it can use a service worker prompt to install, et cetera. AMP, by example, uses that technique to do just that. But I had some fun on ampproject.org, at least on a local branch. I thought, what if we already have a service worker intercepting? We insert more random stuff into the page. How about things? I mean, we can pretty much do everything we want in that fetch event, right? How about things that AMP doesn't like? Because the cache doesn't see the service worker. It doesn't really care about the service worker. So we can do pretty much everything we want. So I got a little nostalgic. I'm like, hey, why not throw in some 90s DHMR magic? I found this fancy cursor that I think improves my page. So here we go. We are using the service worker panel. We load the page. And yes, I got a JavaScript animated backdrop and a really fancy cursor. And I think it dramatically improves the experience of our documentation pages. So first, did you got what have I done? Second, please don't do this at home. But it's a technique that allows you to make amendments, change what you can do on an AMP page, just insert more stuff. So now to the more interesting bit. Transitioning a user smoothly from AMP page to Progressive Web App. There are two ways I'm combining two. Steps I personally call AMP up and AMP down. AMP up is the background bootstrapping of your Progressive Web App shell while the user is enjoying your AMP page. And AMP down describes reusing AMP pages as a data source for your Progressive Web App. The basics with AMP up are that the first click will be on AMP page, usually served from the AMP cache. And then any links on our page will navigate to your Progressive Web App. So normally, that second click would still be considerably slower than the instant feeling preloaded first click on your AMP page. But it's a powerful component baked into AMP, the AMP install service worker tag. That without writing any custom JavaScript allows you to install your service worker for your origin. So yes, even when your AMP page is served from the AMP cache, it installs the service worker from your origin, downloads an app shell, and bootstraps your Progressive Web App, which means at the time the user reads your article, your Progressive Web App is already loaded and ready to go. And the Washington Post actually does this. That means while the user is reading your article, yeah, actually, I just said that, it can warm up. The service worker can warm up in pre-cache. When a user now clicks on a link on a page or calls to action at the bottom, your Progressive Web App shows up instantly. And Alex Russell called it this pattern, start fast, stay fast. This is what I call AMP-UP. But now you're in the Progressive Web App. And chances are, most of you are using some HX-driven navigation that fetches content via JSON or some other data backend. Now you can certainly do that, but now you have this crazy infrastructure needs. So you have two totally different backends, one generating AMP pages and one offering an JSON-based API for your Progressive Web App. But think for a second what AMP really is. It's not just a website. It's designed as an ultra-portable content unit. It's also a data format. The AMP team has asked themselves the logical next question, what if you could dramatically simplify back in complexity by ditching the additional JSON API and instead reusing AMP as a data format for our Progressive Web App. We started with a proof of concept many months ago and iterated on it for a while to see if this pattern actually works, rewriting many parts of AMP to make that reality. So how did we do it? Well, of course, one easy model would be to simply load AMP pages in frames. But iframes are slow, and now you need to recompile and re-initialize the AMP library, the AMP JavaScript library, over and over. Today's cutting edge web technology offers a better way for that. And it's called Shadow DOM. In the old world, our worldview was simple. One window, one instance of the AMP library and one document. But in that new world, there's one window, one instance of the AMP library, and multiple documents. So this results in super fast transitions between AMP documents as the library only needs to be compiled once. So you only got the one AMP library compiled once. The process looks like this. The progressive web have hijacked navigation clicks, then does an hijacked request to fetch the requested additional AMP page, and puts the content into a new shadow root, and tells the main AMP library, hey, I have a new document for you. Check it out. And it does that by calling attached shadow doc on the runtime, the runtime, which is what we call the AMP library. So even cooler, we have added a conditional CSS class on shadowed AMP documents so you can automatically hide stuff like headers in embedded mode. So the AMP shadow class does that. And shadow slots, which is coming pretty soon, allows you to insert advanced widgets and functionality into your pages that live in the shadow root in your PWA. And so of course, you can do that last step and the step here. So you can insert and remove things also manually, because it's really your XHR call. By just rexing the source of the AMP page, like I previously showed with the service worker sample. But the keys at the above is really easy for everyone, and the classes also makes it super, super simple. So here's something, finally, after amp up and amp down is like amp sideways, up down, whatever, Konami code, right? So time for an advanced pattern to wrap this pattern up. So we have a pretty good experience now. But if you're in the Progressive Web App, copy a link and share it on Twitter, that link will open the Progressive Web App directly, because you're not on an AMP page anymore. And for a new user who doesn't have a warmed up service worker pre-cache, it won't feel instant. So that problem is also a problem we can solve in the final step of our development journey. Instead of creating a separate URL space for the Progressive Web App. So for instance, pwa.youtermain.com, like we did before, we just reuse the existing AMP URLs to load the Progressive Web App on your site's origin. And so we're doing that by having the service worker simply intercept the navigation request. All we need to do for this is listen for that navigation request in the service worker. And then instead of serving a cached AMP page, we serve the cached PWA shell, which then does an XHR to fetch the requested AMP doc. This means that in just one request, your Progressive Web App will show up along with the requested content. So you got one AMP, one Progressive Web App, and one request. Now best of all, we now progressively enhance our AMP pages with our Progressive Web App. And during that, no matter what, your users will get a super fast experience regardless of AMP or PWA. For browsers that do not support service worker, they simply see AMP pages. And even here, if you think, well, I still want my Progressive Web App, even though it might not have all the bells and whistles, to work on browsers that don't support service worker, and we have a solution for that too. We have something we call fallback or rewriting that literally just landed this week in the latest Canary version, which is sort of our beta channel for AMP. And it means that if you arrive on an AMP page with a non-service worker browser, we will realize that in AMP. And rewrite all URLs, all outgoing URLs on your page by pattern matching based on a pattern that you can select to redirect to a fallback PWA URL. So you can have, for browsers that support it, you just use one URL space. But in browser that don't support it, we'll still go to the Progressive Web App.  It's not as good as having a service worker, but it's still better than nothing. And so now we have, it's time for demos, but this is actually one demo that the AMP team has built. And it's a pretty cool React-based demo for you all to try out and get inspired. But I'm not going to go talk too much about it because I thought it'd be even cooler to show you a real-world example. In fact, the first real-world example that we know of. And that's Mike, who've done a heroic effort in the last weeks to get us to its current state. Please welcome David Bjorklund, lead engineer of Mike, to show you the new Progressive Web AMP experience a lesson learned on the way. Thank you. Thank you. Thank you. Hi, everyone. Can you hear me? Yes. Awesome. So let's go to the demo. Yeah. So I wanted to start with loading an article. So this is an AMP article. As you can see in the source code on the right side, we're using the AMP tags. So if you were to come from search, for example, this would be the instant experience. This is what a user sees when they come to this site for the first time. We've never been able to do it before. So let's go over here and navigate to the menu. So I don't know if you notice what happened here, but when we loaded the menu, we actually reloaded the page. Because we want to take you from our AMP article to our PWA as quick as possible. And in this case, since we've loaded the service worker in the background on the AMP page, it has loaded all the data that we need to show the PWA. And since we're sharing the URL space, the URL is still the same. So we're now in PWA. So I don't want to talk briefly about how we built this. So we set up to do a proof of concept. We gave ourselves two weeks, and we had three engineers that could work on this. And as part of the team, we knew of PWA. We've seen the videos, we read a couple of articles, but we didn't have any hands-on experience on doing PWA. But since we could reuse our existing AMP rendering pipeline unchanged, that really, like, jump-started our AMP journey. Like, it was just a few days into the work that we could, like, we could start working with the fun stuff. We could start working on the service worker. We could start working on all of these PWA features because we had already AMP stuff in place. So that means the event that we had time to work on performance improvements. So, like, we did what a lot of others have talked about today. Like, we made sure that our JavaScript bundle was as small as possible. But it also made us give us time to, like, experiment, to play around a little bit with Eurik's improvements. Like, the menu that I showed earlier where we do this, like, this reload. And it also gave us time to, like, really dig in and try to, like, learn as much as possible about the service worker. So we could, like, we could feel that we could come closer to something as a perfect cache. And, yeah, as I said earlier, it gave us time to implement WebPush. And, like, it didn't end up the time frame that we had, and with the resources we had, we never would have time to do any of this if it hadn't been because of the simplicity that AMP, that Ambedic AMP in PWA gave us. So I want to, when I did the slides, Paul asked me to, like, be honest with you and talk about the pain points. So I went through and I tried to do a list and I talked with my team and we talked about, like, what has this, how has this experience been? But, like, it was actually sweet. Like, it worked, it worked as advertised. Like, of course we had certain pain points to do in PWA, but, like, everyone, that's what we've been talking about for the last few days. When it comes to actually embedding the Ambedic AMP inside of the PWA, it just works as an advertisement. With that, Paul, I'd like to bring up Paul again so you can wrap up. All right. Thank you, David. So wrap up. Now there you got it. We successfully combined AMP with a progressive web app. And now the user always gets a fast experience, no matter what. Your site is progressively enhanced. You have less backend complexity because you just have one data source and profit from the building performance of AMP everywhere even in your progressive web app. And that really reduces the overall investment. Now, before I leave you, keep in mind that this is just one pattern to build sites and what works for everyone. You probably shouldn't build the next Air Horner or Gmail with it, but focus on sites that have a lot of leave nodes, individual sites with lots of static content. By all means, find out if that pattern is the right one for you and feel free to get in touch to discuss. So check out our React-based demo. Check out beta.mic.com to actually see a live experience. And also learn more about progressive web apps on developers.google.com. And of course, more about AMP on ampproject.org. And I really can't wait to see what you've built. Thank you.


Welcome to Digital Asset News, the guitar stories and crypto currency digital assets. And bring them down to bite-sized pieces today. We've got some bullish stories with a twist. First up, Bitcoin could hit one million dollars, says the CEO of Coin Fund. We're going to take a look at what he's talking about and how that might be a little bit out there. Also, billionaires are essentially fomoing into Bitcoin. We're going to take a look at why that actually is and a little piece from Bloomberg opinion, which tells you to stay away from Bitcoin. And why I think they're not too far off. And lastly, I need to answer the question, which is the elephant in the room is, am I still dollar cost averaging or DCing as the price of Bitcoin goes to all-time highs? Or is there a new strategy? And we'll get into all that and take a look at the markets. But first, we've got to do some giveaways. 12 days of Christmas are upon us, thankfully. Great stuff. Also, I want to give a big shout out to Alex Mastiole for taking over the channel for a little bit. We had talked about this a little bit ago just to see if we could pull it off. And it's it's nice to switch things up and maybe another year. So I'll do another thing. I'm not really big on switching too many things up, but I thought it was appropriate, especially for the holiday time. So hope you enjoyed it. I liked Alex's perspective as far as the institutions, because he talks to all those people and I don't. So it's just interesting to hear just another viewpoint from the thousand bird's eye view. Anyhow, so I was talking about today about giving away a trade the chain membership. And the thing about trade the chain is to me, it's like the trifecta. You've got the the FAT and SA. Well, what the heck is that? Well, the FA is a fundamental analysis. That's kind of what we do here. We talk about the stories that are going on, what's going on in the world, the cryptocurrency, the news, and of course all the hype. The TA is, of course, the technical analysis, which I don't get too much into, but the geniuses over there at Market Rebellion talk about it. And it makes a lot of sense and they use both. And Alex here has brought us in the third perspective and that is the sentiment analysis. And that kind of takes a look at what is really going on behind the scenes, the social media, the hype, the tweets, the blog posts, all those little details that really, in my opinion, is what is being a big factor for this entire market. I believe it's emotion. Me and Alex are on the same wavelength and that's why I created trade the chain. So we're going to give away a free membership today. So let's just jump right over into the video that Alex did. And I'll do this quite easily. All I'm going to do is I'm going to swing down a couple of swipes and then, bop, stop. David Wolber, congratulations. You have just won a free trade the chain membership. And let me swing down a couple more times. Bop, bop, bop, bop, stop. And Matin Safi, congratulations. You are our second winner for trade the chain. So David and Matin, if you could just do me a favor, go over to danteachescrypto.com. Click on the contact tab right there. Fill out the form, which is just a contact form. And we will send over, actually Alex will send over, your free membership to trade the chain. All right, let's jump into today's markets. So what we got? Well, we got Bitcoin almost hitting 24,000. That's what happened. It's gone down a little bit. We're at 226, but fantastic run. But there has to be a little bit of a pullback. And I know everybody's saying, but this is different. It's going to keep going. No, it's not. It's not. It does not go all the way up all the time. So we hit 21 and then 22. And I was monitoring my Twitter account, as I usually do. And it was just like, oh, we're going 25, we're going 27, 30,000, 50,000 by the end of the year.  It's not that this game is played. I don't see 50,000 in play by the end of the year. I could be wrong. But here we are with a little bit of pullback, even though it is up 8%. But again, fantastic run. Won't take anything away from it. This is great news for all of us. Ethereum at 644. Wow, that's pretty good. 13% for the week. XRP watch out, a whole whopping 60 cents. Wow, Tether, Litecoin, 13%. Bitcoin cash. You know what? What's down? Cardano? Cardano is down for some reason. All right, sure. Finance coin, all right. 0.4. I mean, not much. That's a stable coin. Whatever. And yeah, pretty much it. So pretty good run thus far. Let's see what happens throughout the week. Now, let's take a look at if we had just invested into Bitcoin by switching over to Bitcoin. That's pretty simple. And let's see if we just would have invested into the King Crypto how we would have done. Well, with XRP, we would have actually been down. We should have invested in XRP, but up a whopping 5%. 3.8 for Litecoin. And yeah, that's about it. So that's the big thing. A lot of times when you just invest in Bitcoin, it's great and things go up. However, there's been chatter of the altcoin season. When is that going to come? I have no idea. And nobody really does. They can give you a lot of good guesses. But I don't know. But this is exactly what happened in 2017. Bitcoin popped off first and then boom, off we went for the altcoins. Now, do I think we are in the parabolic bull run like when we did in December 2017? No, I do not. I think 2021 is going to be the real fireworks. This is just a warm-up. So everybody just calm down. This isn't the first rodeo. Let's see where it all goes. But let's jump into today's top story. So this is a good quick follow-up piece from Bloomberg Technology. They head on the CEO of Coinfund. And Coinfund, if you don't know, it's a blockchain technology investment fund. I've started around 2015 in Brooklyn, New York, and they invest in veteran liquid opportunities within the blockchain sector. Great. So we know where their legion lies. And what they're going to talk about was the actual CIO of Guggenheim, which we had covered yesterday, where this was Scott Minard. He had talked about how Bitcoin was going to go to $400,000. That's what they believed. And on top of that, they had been investing into Bitcoin since it was at $10,000, which is always interesting to me. All these industries are like, oh, yeah, now we're into it. Well, where were you before, guys, when everything was going down? Oh, we were buying it when you suckers were selling. That's what I think is really going on. So it was a good piece, a good information. So it just kind of reinstills the fact that institutions are here. But what Gens is saying is that he's going to shock the world right now with a little prediction. So I want you to take a listen to it and before I even play it, I'm just going to say take this with a grain of salt and we're going to go over this in detail in a little bit. So just take a listen.  We actually spoke with Scott Minard earlier, all to do with the Federal Reserve, but he came out with his eye watering, eye popping viewpoint on where crypto is going. Just take a listen. We made the decision to start allocating toward Bitcoin when Bitcoin was at 10,000. It's a little more challenging with the current price closer to 20,000. Amazing, you know, over a very short period of time how big of a run up we've had. But having said that, our fundamental work shows that Bitcoin should be worth about $400,000. Like, yeah, talk to us about that $400,000 figure. How quickly does he get there, Seth? Well, you know, the way we're thinking about it and my involvement in Bitcoin started in 2012 and Coin Fund was founded in 2015, the way we're thinking about it is if you look at kind of the pattern recognition of Bitcoin's four-year cycles, $150,000 to $250,000 looks like the base case. But here's the thing, it's becoming an institutional asset class this cycle and that strikes me as being analogous to, you know, my background is in equities. When Tesla stepped up from the $25 to $35 range up to $150 to $350,000, and then it consolidated for a while, I think we could actually pull forward the next cycle. See Bitcoin go to $500,000 to a million and then probably consolidate for a few years in that range. But I think we could actually get there in the 21-22 time frame. First, I'm going to ask you a question. If we went to $150,000, would anybody be upset? Would you be upset if Bitcoin had $150,000 in 2021 or 2022? Would you be upset if they had $100,000? And Altcoins also followed it. I wouldn't. I don't think I'd have a problem with that whatsoever. So what I'm going to say next, take that also with a grain of salt, but you have to understand there's a reason why a lot of people who are so heavy into Bitcoin are giving these price predictions. First of all, it's because they have a lot of it. So when you have a lot of an asset, you want that asset to do good because you are invested into it, whether that be emotionally, financially, or both. So with Gin here, he's going to talk about how he can definitely see it. Well, of course he could probably see it because he got a ton of it. There is no difference between this gentleman right here and when you see a bunch of the gold bugs going, you know what? Gold can do pretty well. It's going to be pretty great because, again, they have a lot of it. Now, the technique goes a little bit different. I think Bitcoin is far superior to gold in a lot of different aspects. Portability being one of them, decentralized being the second, also with programmable money, I can go on and on, it doesn't matter. But yes, but you have to understand this is what is going on. So when you hear these types of predictions, do not start to think like, oh, it's going to a million, it's going to a million. Calm down, take a step back. I want to take you down memory lane real quick. Follow me. So I'm going to start off with the biggest scammer of all and his name is John McCaffey. And unfortunately, or fortunately, or I don't want to look at it, John was the one is why I pretty much got into cryptocurrency because I got in around October, November 2017 and I heard this prediction. I'm like, wow, John McCaffey, you know that guy, he's a great guy. He makes that great software. Fantastic. And he's thinking a million. He's a smart guy. I'll follow him. Well, guess what? He never believed it. And he was a big shill and everything else. Now he's in jail somewhere, awaiting arraignment. I don't know. So he made these predictions probably because he had a lot of Bitcoin. And then also he got into a lot of different other business dealings with other cryptocurrencies and took a lot of money from them. And then all of a sudden those cryptocurrencies were awesome. That's just the start. Also, here's another great price prediction. This is from Pomp. I like Pomp. I like his show. I watch his show. He gives predictions. Why is he gives predictions? Probably because he looks at fundamentals and a lot of different factors. And he's not a God. No one's a God. No one can really just pull out these numbers out of thin air and be like, this is definitely what it's going to be because no one's at a crystal ball. So here was his price prediction in 2019. Bitcoin on a grand. Heath will hit $3,000. Litecoin $2,500. And XRP will hit $10,000. That didn't happen. So as a matter of fact, Ethereum hit $140,000. Litecoin is $44,000. And the price of XRP was just about $0.20. And I can use my favorite joke. XRP is paid with a quarter. Can't use it.  Now let's move forward. Here are some great predictions in 2020. Timothy Peterson, manager of Cane Island Alternative. He said that $75,000 would be happening relatively soon. And this was on June 8th. Of course, didn't do that. It actually went down to $9,100. Moving down, I don't know who the other guy is. I don't care. Thomas Lee, this guy is a huge Bitcoin bull. That's a lot into it. He said that Bitcoin will see almost a 200% gain on February 5th because of a break of the 200 moving average. And guess what happened? It didn't go up. It went down by 40%. Of course, this is in March. And these are the things that happened, especially with the everything that happened globally. Then he had a prediction before that, which said that it would be $91,000 by March of 2020. And that didn't happen. So when I hear these types of predictions, I want to be wrong. I want it to go to a million. Believe me. I mean, why wouldn't I want it to go to a million dollars? But I've been around long enough to where I've seen. I've heard a lot of predictions, and some come true and some don't. And I just take a look back at history because I need to know where I'm going. If I want to know where I'm going, I got to know where I've been. And that's where I've been. So to take a little bit deeper dive into that, let's jump forward. All right. This is the Bloomberg opinion. It says all aboard the billionaire is a Bitcoin bandwagon. And we've seen these billionaires come out of the woodwork. We just talked about, Alex just talked about one today. And now we know that other big entities have been investing into Bitcoin a long time ago. Guggenheim being one of them who was buying up Bitcoin at $10,000. So this is a nice little piece where it talks about the super rich can afford to dabble in crypto, mere financial mortals, not so much. So there's two sides of this story. And I'm not going to get into any of it, really. Not in this piece. I'm going to show you exactly what I'm talking about. I just want to go over this first paragraph. It says, now that Bitcoin is top 20 grand for the first time, should you shift your hard-earned cash into digital currencies? History suggests caution should be your watchword no matter how strong the fear of missing out may be. And it goes over some different pieces and somebody is kind of ridiculous. So let's just break into what we know and the charts. I'm not a big TA person, as you may have known, but I'd like to look back at the past. And one of the patterns that I definitely see is this. Having, all-time high, dip, space. Having, all-time high, dip, space. Having, 2020. All-time high, 2021. Dip, 2022. Space or a rebound, 2023. And it starts the whole process over and over and over again. So let me break that down and tell you exactly what I'm going to do as far as my dollar cost averaging, because there is a point where I'm going to have to stop. This is the conservative Bitcoin price prediction. I just took a look at the first, second, and third halvings, and the price increased on each one. So the first halving was in November, 2012, and then when it reached its all-time high, it was December, 2013. So about a year. The day of the halving was November, 2012, and it was 12 bucks. A year later, it was $1,000. That is an increase by about 8,000%. All makes sense so far. Great. The second halving happened in July, 2016. It hit its all-time high about a year and a half later on December, 2017. So when it was actually a halving, it was 650 bucks, and it went up to $20,000, which was on December, 2017. So there's two ways to look at it. The percentage increase, it was 8,000%, then it went down to 3,000%. So about two-thirds, actually, it went down, or a third of this, a third of 8,000, roughly, is around 2,900. Another way to look at it is the all-time high was about 1,000, then it went up to 20,000. That's about 20x. Now the third halving, that just happened in May, 2020. When it's next all-time high, I have no idea. But I'm guessing maybe 2022, maybe 2021, not for sure. But if we take a look at this, one year to a year and a half to two years, that could possibly be what it is. What was the price of the halving? $10,000. So we want to look at increases, 8,000 to 3,000. Decrease this by about two-thirds. You're going to get about 1,000%. So at 10,000 times 1,000%, you get about $100,000. This is why I get my prediction of $150,000, because I just want to be right in the middle. About $150,000 is where I see the next all-time high. And that's a very conservative number. Now let's do this. I call this one the draper. Draper thinks it's going to be around $250,000 to $300,000, somewhere around there. So the same numbers are true. The only difference is that instead of decreasing by about two-thirds or a third from 8,000 to 3,000, it's still the same. But let's say we went from $3,000 and we shot up by about a third to a half. We'd get about a 4500% increase. If the numbers are 10,000 times 4500% increase, we get around 450,000. 450,000, that's where draper is somewhere around there. Okay. Then if we go off on the deep end, I call this the McAfee, which is just crazy, I think. You get this, this, and then, or the one way, you go the opposite way. You get 10,000%, 10,000 times 10,000%, a million dollars. And these are all numbers. You're like, well, no big deal. Let's just hit through a million. Not a thing. Well, wait. Here's the market cap calculator. Let's just break this down. The circling supply is about 18.5. I think it's actually much lower than that because people have thrown away the Bitcoin, but whatever. They're all going to stick to 18.5. Maybe in a year, it's going to be 19 million. Not for sure because they're going to mind some more Bitcoin. Sure. Let's just stick with 18.5 to make things nice and easy. So if we get 100,000, that means the market cap is almost 2 trillion. I can see 2 trillion. Makes sense, right? How about 150,000? We're looking at almost 3 trillion. 3 trillion? Okay. We're kind of pushing some edges, but I'm sure we can do it. We almost hit a trillion last time. I'm sure we could triple that. Now I want to show you the draper. Let's do 450,000. You're looking at 8.3 trillion dollars. Could we do that? I don't know, maybe. But I will just tell you this. The total supply of gold, which has been around for thousands of years, is about 11 to 12 trillion. So we would be three quarters of everything that's in gold right now. Okay, maybe. So let's go for a million. Let's just see what happens here. You're looking all at 18.5 trillion dollars. So you've almost doubled the amount of gold. You've got some other things, maybe in derivatives. You maybe have doubled up some real estate and tokenized something else. You've done a lot of things, and you put a lot of money into it. Could this happen? I don't see it. I just don't see it, and maybe it could. I don't see it in this cycle, but I will tell you this. Bitcoin will do extremely well. I know it. I feel it. I've been talking about it for the last year on this channel. Do I see it's going to go up that much? I hope it does, but I just don't see it right now, especially not in a year or less. This leads me to my very last point. Dollar cost averaging. I got this question a lot because one of my price points was $19.9 for Bitcoin to sell off just a little bit and take some profits. The question was, well, are you going to dollar cost average because you're taking profits? So what's the point of that? It really comes down to this. What is the price point of where Bitcoin will attract to? That's the big question. So again, we have to look at the past. So the first halving was in 2012. This was the all-time high a year later. What I want to know is what was this low point from the actual high point between the first and second halving? Meaning we know it was around $1,000, right? It was $1,000 for 994 on 2013, which is right around here, $1,000. What was the low point right here? Well, to do that, I need to find out all the times and all the dates between 2013 and 2016 between the first and second halving or 2012 and 2016 because I need to find this low point right here to see what that number is. So here we are. I'll take this graph. The very lowest point that I can see. This is 210. This is 172. Let's work with round numbers. Let's say about 200 bucks. So I went from $1,000 to the high and I dropped down to almost $200 in January 2015. That is 20% of the all-time high. So what happened after here? After the second halving. Going back, it was $20,000. I need to find out from the all-time high, which is right around, well, which was December 2017. What was the lowest point between then and now? Because I want to find how much it dipped from the all-time high. Just bring up CoinGecko again. Here it is from 2017 all the way to today. The lowest point that I can see, I thought it was actually in March at $5,300, but it wasn't. We have to go all the way back over here. It was $3,378. Let's work with round numbers. Let's say it's around $4,000. Let's just round up, which is a heck of a roundup, let's be honest. But let's say 4,000. It was a 20,000, went out of 4,000. What is that? 20%. So just like the first episode, we went from $1,000 to $200. That's 20%. The next episode went from 20,000 to 4,000. That's 20%. What's going to happen in the future? I don't know, but I have to take a look at the past and go, well, if we had 150,000, what is 20% of 150,000? $30,000. I believe, and I could be wrong. I hope I'm wrong. I believe after $30,000, I'm going to stop dollar cost averaging, because after that, it's going to go all the way up and come all the way back down. So right now, I'm still going to be dollar cost averaging. I'm putting a little bit less into Bitcoin because I think it's still going to be a little bit more of a correction. But past $30,000, I cannot put anything in until it drives all the way up to 150,000 somewhere around there. And I believe it'll go all the way back to $30,000 based on the history. Now, if I'm wrong, I'm wrong, and I'll be okay with that because I've been doing the hard work just like you've been doing the hard work over this whole time, from all the way here, all the way to here, me and you have been doing dollar cost averaging, especially if you listen to this channel. That's all I talk about. I've been putting in money just little bits here, and not just on Bitcoin, everything in my portfolio, from this, for this, and this, and this, and this, even here, and even here. It was hard. It wasn't easy, but you got to be disciplined. And after I was done, I was like, did I do the right thing? Did I do the right thing? I think I did. I know I did. And here we are. So, all right. So, look, I know that's a bit long. I apologize, but I think a lot of those questions needed to be answered. I just wanted you to be careful. That's all. Again, take predictions with a grain of salt. Nobody's got a crystal ball. But I think we all know where this is going. There's a lot of institutional players in there. We know that they are going to help us stabilize the price point because they're not going anywhere. If they have the same philosophy as Michael Saylor, they're not selling. They're just accumulating. So, we'll see what happens. I think you'll see some pullbacks. You'll see some fun. You'll see some bad news. But again, 2021, I don't think we can lose here. I think it's going to be fireworks. All right. So, that's it. So, thanks for sticking with me through the whole thing. I really appreciate it. If you like these types of videos, there'll be two more that's going to pop up on your left and right. Not sure that YouTube do its magic. And that's all she wrote. So, thanks again, and I'll see you on the next one.


The Federal Ministry of Agriculture and Rural Development, together with Oxfam, have taken the future of agricultural advancement amongst women in Nigeria to the next level. The collaboration this year took the firm of an annual Female Hero Award to deserving and hardworking women to encourage more participation of women in agriculture. Emmanuel Ehejene completes this report. It was a gathering of mostly women who have embraced agriculture as a profession, as well as those who have taken it as a source of daily income to cater for their families. The Mish-eaters spoke glomely about the annual Women Hero Award, while explaining why it is necessary for the advancement of women and the benefit to the nation in general. The Obonga women have served as great ambassadors and representatives of millions of women are different for us. At the community level, as part participants, they have also mobilized women to engage their traditional rulers on access to land. They have also represented the country in places like the African Union, Ekoas and the European Union meetings, including engagement with the U.S. Congress members to advocate for favorable policies that affect them. However, they see a lot to be done by government and the private sector in terms of concrete actions to ensure that the rights and the interests of women, farmers and food and agricultural workers are prioritized and that they have resources that they need for their livelihood. Here, the federal means of agricultural development in an effort and commitment to promote gender inclusiveness, flag off and roll out agricultural imputes to small-holder women farmers as a palliative to cushion the effect of COVID-19 pandemic in the FCT. Can you also mention there are plans out there to donate more farm imputes to our female farmers in the country in order to empower them, strengthen their economic independence and increase their engagement in agriculture, thereby boosting their livelihood and enhancing the drive to full security. In their goodwill messages, representatives of Obonga women appreciated the ministry and asked them for the support and contribution to women. We cannot overemphasize the role of women farmers and the work they are doing trying to feed the nation, but, you know, their livelihoods are still not being improved. So as stakeholders, as governments, what can we do differently to improve the livelihoods of small-holder women farmers? What can we do to encourage them to keep feeding us? Because they take over 70% of the labor force in agricultural production, but little or nothing is being given to, you know, to encourage them in terms of access to farm imputes, in terms of credits, facilities, in terms of storage. So we need to put our hands together. We need to work together to see how these women can have a better and improved livelihood. Twelve outstanding women were selected for the annual Women Hero Award after which three emerged with us.


If you're motivated and you want to come here and you want to put in work and you want to train and you want to achieve something else and be rewarded for it in a way that's really fitting and is absolutely superb, then I would say that MSA and the MSU program on a very large scale is just a fantastic opportunity. The Marine Security Guard Security Augmentation Unit is a command inside of McKessage that allows for us to be able to deploy small, task-organized units in supportive department of state at their diplomatic facilities during times that are pre- and post-crisis. The second primary focus for MSAU involves being able to provide security support for VIP visits, whether it's the President of the United States, Vice President of the United States, or Secretary of State. A Marine that comes to MSAU has a number of opportunities. He or she gets to travel the entire world. In addition to that, a Marine that comes to MSAU has an opportunity to be able to have a significant increase in the amount of training that they would in the normal MSG program. That includes medical training, smartsmanship training, close combat training, in addition to the training that allows them to be able to provide security analysis and augmentation at those diplomatic missions. I think this gives you a unique advantage of not only leading Marines that are highly capable and just as qualified as you in that actual job, but they're your peers. So it kind of gives you that advantage of if you can lead a peer, you can lead subordinate Marines.  I think it's one of those go-to jobs that has been a secret in the Marine Corps for a long time.