What was the real story behind it? Well, sorry if the troubles goes like this. It took a very long time. Is that here? Yeah, sure. I read about Bitcoin. It wasn't until 2012, and I had just moved to Taiwan. I quit my job at a law firm, and I wanted to take a year and study Chinese and kind of have some fun before I went back and figure out what to do for a career. Bitcoin was maybe like $20. And I didn't invest, so I was trying to figure out what to do. And the only place to buy it was this shady exchange in Japan that I didn't trust. 2013, the price went away, it spiked for like $150 because there were bank runs in Cyprus, and people were getting their money out of Cyprus by just buying Bitcoin. So this is the time to buy. And the price came back down for like $100 just under, and I threw like half of my money I had at the time in. And I was really regretting it.  I could have made all this money had I just chanced it on this shady exchange in Japan. Then I was in. And it turns out I was right about the shady exchange in Japan because less than a year later, I had lost everything. Right now, if companies want to have an exchange in Japan, they have to get a license from the FSA. And then even then, if they want to list any new tokens, they have to get permission for every single one. And when China banned ICOs last year, China had the most activity in the world, and they all wanted to come to Japan. And then they quickly gave up because they realized it was impossible. And now it's even harder. The communication issue is surmountable because you can just hire people who speak Japanese, right? But the real issue was it's not clear. Everything has to go through FSA. And FSA decides whether or not they can list a particular token, who knows how long that takes. Even in Japan right now, a lot of people want to invest in ICOs. And a lot of companies want to raise money in ICOs. And they just won't let Japanese invest because they don't want to get in trouble in Japan and the regulations are not clear. And same with the US. And same with China. Need to keep people safe, but also need to make sure businesses can operate. This is actually a great opportunity for Japan. That's what I want to talk to the legislators today about. Because Japan is like seated between the US and China and has to figure out a path to develop its economy further. So it's the world's third biggest economy, but it still has a lot of issues to grow. And so cryptocurrency could be a great strategy. The US and China are not really clear enough. Japan is, they could track a lot of business. But if it's not, it's all going to be. I think I have more friends here than almost anywhere else. Even more than in New York City? Ah, I don't know. I have a lot of friends in New York City, but I haven't been back. I have more friends in the crypto world, I think in Japan than maybe anywhere else. I met most of them here. Actually in 2014, I came here and everyone had lost money there. And we all became friends and we're still friends to this day. Hello. I would never expect that years later I'd be like in Tokyo and going to the theater and the courthouse and all these things. We have to be aware of these things. We also have to be aware of these things and we have to be aware of our big differences in our business. At the same time, we have to be aware of the differences between the two. As a matter of fact, how can we use the word, the word, to communicate with people? If we don't think about it, we have to think about the system of the world, and the system of the money, the system of the IPO, we also have a very big and meaningful impact on things like that. I think it's a very important issue. I would like to say this again, to the world, and to the world, to the world, to the world, to the world, to the world, to the world. I would like to ask for your understanding. New York's New York. The three functions of money in the classical economic textbook that you have studied can be distinguished, but only sovereign back currencies have the three attributes. With all the attributes of a sovereign currency, What is it that has created the interest for Bitcoin and other cryptocurrencies? It is the creation of computers and nobody has the responsibility for crypto assets. There is no government who has a foreign exchange policy. There is no central bank that has a monetary policy linked to that. If you are so full of time, you cannot be an instrument of payment or you need a account. Security laws in the United States are intended to, in all over the world, are intended to benefit individual investors. But what if these investors do not want the protection of those laws? The reality is what we found is that a number of issuers did not even exist and they have been some frauds. It is not something that I would attribute to the Bitcoin or anything like that. I just attribute it to the way those transactions that were unregulated eventually ended up. Who determines what is money? Do people determine what is money or do governments? And if it's governments, why should government have this power? You are the proof exactly of what I'm saying.  You're entitled to do that. The reality is a sovereign currency is the privilege of a sovereign. And that is decided by the sovereign. Long before governments existed, people chose what was money. And right now young people are choosing to put their trust into cryptocurrency. It's worth examining why they are doing this. Money was issued by dukes, marcuses, princes and kings. That's exactly what Japan does for the young. That is the tradition where the sovereign takes responsibility. The model you are promoting is a model where there is no authority who can make sure that the way it develops is in the interest of the country. And I think that is where I am absolutely clear. There is only one currency per country and it is essential to the economy of that country. Trying to say that it's one and the same and that the people have to decide on the currency doesn't, in my view, serve well the economy. Long before, money was issued by governments and kings. People used seashells and other commodities as money. And in the end, governments can issue currency, but people can choose which to use. That's why many people choose to use the US dollar and not the Simbaway dollar. That was great. I knew he didn't even wait for a transfer.  I'm like, a mission accomplished when he got pissed off and said that. But look, that's the point is to have a discussion. He wanted to have a discussion about particular policy and not about what underlies the whole policy. And that's really the discussion that we need to have. Absolutely. It really made the whole thing very interesting. It was a great idea to actually bring you along because that really created this whole mapping. I'd love to do more of that. So I guess what we need to hear in Japan is to address and educate the Japanese politicians and bureaucrats. I didn't know what to expect walking in to the conference. I didn't know he was going to be there. I just thought I was going to be giving some remarks on my thoughts about Japan's legislation and where it should go. And once he started giving his talk, I quickly realized the direction things were headed. He was very biased. There was so much more I wanted to say, but there wasn't enough time. Saying that Bitcoin is just used for money laundering and all that type of stuff. So is cash. There's a lot more money laundering going on with cash and there's no distributed ledger to track it all through. So the other interesting thing I raised to him that he didn't want to discuss after the whole discussion we had was that the reason for the US's position is largely because initial public offerings are at like a 20-25 year low. This is because regulations too strict and there's a lot more private capital so people don't need public markets. And the SEC wants to fix this and a long come ICOs which threaten the entire model. I think I had a very unique vantage point because I spent so much time in Japan. I understand as well as anyone why Japan passed regulation. I don't know what Japan's going to do, but it's also a long shot that Japan's going to pass some legislation that's meaningful because other countries are doing the same thing and frankly I think they'll make it much easier for people to do business there. What multi-pass is pretty good. I think Bahamas and Cyprus are also looking at pretty good legislation, talking to them about it. People are free to go and invest where they want to. So if you're an investor in Japan why would you, what you should be doing is you should set up a company someplace in Hong Kong for $1,500 and do all your trading through that and then to pay zero tax. If you trade as a Japanese person you'll pay 55% tax, like why? It's a no-brainer. I think if countries like Japan don't take a forward-thinking approach they're just going to push all the cryptocurrency activity to other places and the internet will let that happen very easily. But what I wanted to tell the legislators too is that it's a great opportunity for Japan because Japan has a lot of issues facing its economy and how to grow it. It's the third biggest economy but seated between the US and China. Both the US and China have sort of rejected cryptocurrency for different reasons. China for to prevent capital flight in the US to protect its IPO market. And so that leaves Japan with a great solution. If they embrace cryptocurrency they can catch the wave and the US and China would miss out and give them a lot of bargaining power. So that's kind of the message I want to deliver to legislators. I think Japan though to their credit is doing a lot more to try to understand it and allow it to exist. But the current legislation is just not doing that at all. It's pushing business away. So I think they understand this from the talks I've had with a few legislators. They know it's not working. The question is what to do about it. And the other question is Japan, I've learned from Mt. Gox. The government and legislature in course move very slow. So once they get something in place it can be quite powerful. But for Japan the question is whether they can get it in place in time. Everyone's already setting up in Malta and other places. So if they do something they want to make sure it's done right and according to the process which takes time. I mean I don't fully understand the government in Japan. I think it's quite unique. But I do know some things from my experience. And any solution is just going to take time. Please subscribe and hodl.


My name is Jeffrey Hussain, and I work for Netflix. I am the architect of FALCOR, which is Netflix open source data platform, some of you may have heard of, and I'm the Netflix representative on the JavaScript Standards Committee. So a lot of you out there are probably familiar with ES6, which is the most recent version of JavaScript. And today we actually have a really good browser support, at least for the major desktop browsers, for ES6. So things are looking good, and the time is right to talk about the future of JavaScript. Now, this is the last time you're going to hear me talk about versions of JavaScript. Used to be titled ES6, is now called ES2015, and going forward, we're going to be releasing a new version of JavaScript every single year. So ES2015, 16, 17. Now, the reality is, these versions don't really matter. In fact, what matter, because what's basically going to happen is, at the end of every year, whatever features are ready and mature enough, we're going to put in the spec and they're going to make it in the language. So what actually matters with regard to the maturity of future JavaScript features is this maturity stages. So in order for me to responsibly talk with you about future versions of things coming down the pipe in JavaScript, given that they're not really done yet, given that they're not really baked, is to talk about maturity stages. So as features make their way through these maturity stages, we sort of say to the community, hey, these features are getting more and more mature, and they're getting more and more baked. And by the end of the year, whatever has made it to stage four makes it into the language spec and gets shipped. Now, the reason why versions don't really matter so much from my perspective of you, JavaScript developers, is that you can start using some of the features I'm going to be talking to you about today, just by using Babel, for example, which does compilation from new JavaScript features and future versions to the existing versions of JavaScript supported by your browsers. So some of the features I'm going to be talking to you today, you can actually go away and use right away by using something like Babel. And as you can see, Babel actually has this little piece here where it supports multiple stages. So you can just say, hey, look, I want to use this stage four feature or this stage three feature. And you, as developers, are accepting the risk that if you use a stage four or stage three feature, it might change by the time it actually makes it into the standard. So later, the version, the more mature it is and the more likely it is to not change. Now today, I'm going to be talking to you about a very specific question that is very important to me as a developer. I think a lot of JavaScript, people on the JavaScript committee, stay up at night thinking about, and that's how we can make asynchronous programming easier for you. Now, obviously, JavaScript is a single threaded programming language, right? And we do a lot of UI programming in JavaScript. And in order to make sure that our UIs are responsive, we need to make sure that we write asynchronous code, right? Because if we write code that's synchronous and synchronously makes a network request, it blocks and then our applications are not responsive to users. So starting in ES 2015, ES6 now titled ES 2015, we introduced this notion of promises to make asynchronous programming easier for you as developers. So promises are very simple. Promises are an object that represents a value that you'll eventually get asynchronously. And to consume them, you simply call the then method and you pass two callbacks. One callback, the first callback gets called if the promise succeeds with a value, and the second callback gets called instead if the promise errors. And then you get that error. So promises have a very simple API. And in ES5, you could take your functions that were synchronous and rewrite them asynchronously using promises. So here we see we have two sequential operations. One to get the symbol for a particular stock. And then once we've got the symbol for that stock, we make a follow up request to get the price. Now, if we were doing this synchronously, things would block. So we don't want to do it synchronously. We instead, in the new version in ES6, we have these functions return promises, and then we chain these sequential operations using then. So that's great. If all you're doing is do this, then do that, then do that. But some functions, well, they're a little more complicated than that. So here's an example of a function that's a little more complicated. What if we might try one service to get the price for a stock, but then if that fails, we want to try another service, and we want to retry it multiple times. This particular function is a little bit more complicated than the one we saw before. And it's not immediately obvious. It's possible. But it's not immediately obvious how we would take it, and we would convert it over to use promises. So we're not entirely clear how that would work with promises. We'd take some thinking, probably some recursion in there. So what we on the JavaScript committee have been asking ourselves is, look, why does synchronous programming and asynchronous programming have to look so different? I mean, there's no difference if a function returns a value or it delivers it to you in a callback. Why should you as a developer have to mangle your code just in order to change in which direction data is flowing? So that's why we have a very big feature coming in a future version of JavaScript called asynchronous functions. And these are stage four maturity level, which means they're very mature, and it's probably OK for you to go and start using them right away. So here we have that original function getStockPrice with its loop and its try catch. And here is how you would write the same function asynchronously in an upcoming version of JavaScript. So here I'm introducing the async function concept in JavaScript. So notice that this code is nearly identical. The first thing you'll notice that's changed is we have this async keyword. And then we take all of these functions that now return promises, and all we have to do is put the await keyword in front of them. Now what happens is that although this code looks synchronous, at runtime, JavaScript is going to suspend the execution of this function until this promise resolves and then resume at that point. What that means is that we don't have to worry about callbacks, and then notice that this function now has no callbacks whatsoever, and JavaScript worries about executing our code sequentially after the async function resolves. So that means we get to use all of the control flow constructs that we know and love, while loops, try catch loops inside of asynchronous functions, and we don't have to think very hard about how to turn our code inside out. So what that means is coming up in a future version of JavaScript, I think the big story for future versions of JavaScript is symmetrical support for synchronous and asynchronous programming, and that's a beautiful thing. So that's great, and it's great that we can do all the same things with async functions as we can do with regular synchronous functions. But you know what, we have an additional concern when we're worrying about asynchronous functions, and that's cancellation. Asynchronous functions, unlike synchronous functions, tend to run for long periods of time. And for those of you developing user interfaces, we know that sometimes users are fickle, right? They open up a form, and then they see a loading bar, and they get bored, and they hit the stop button, and if they decide to cancel the operation, we want to just stop doing anything, like whether it's make future asynchronous requests. We don't want to do that anymore, and we want to be able to cancel and stop just like the user has told us they want to do. So starting in a future version of JavaScript, we're going to have a new notion called cancellation tokens. A cancel token is actually a very simple concept. It's really easy to understand.  One is the actual cancellation token, but then the other is a cancel function. So let's pass this cancellation token to our asynchronous function, the one that we just saw, getStockPrice. So as we see, we just pass it as another parameter to the function. Now if later on, while getStockPrice is doing its work, making a request to resolve the stock name to a symbol, then making a follow-up request to get the price, if we decide, you know what, I don't want to do that anymore, and we cancel, we just invoke the cancel function, and what that does is it causes the token to cancel, and then our getStockPrice function, whenever it finishes some asynchronous operation before going forward, it's gonna check that cancellation token, and if it sees that the cancellation token is canceled, it's just gonna throw, and because it's throwing, it's never actually gonna invoke our callback here, and it's effectively gonna cancel, and that's how cancellation tokens work. So now let's see what this is like for the person actually writing the getStockPrice function, because they have to accept this cancellation token. So let's take a look at what getStockPrice now looks like. So here's the async function we saw earlier using the new async keyword, and here's what it's gonna look like to write an asynchronous function that supports cancellation. So as you can see, we accept the cancellation token, and then after every await statement, we just go cancel token, throw if requested. In other words, if somebody called that cancel function that we saw earlier, this is gonna throw at this point right here, and effectively the rest of this code, notice that getSymbolPrice will never get executed, and therefore we save a whole network request that we need to make because they wanna cancel that function now. So that's a lot of boilerplate, as you can see, if every single time we have to write a wait, we have to write cancel token, dot throw if requested, it can add up, it's a little bit of extra boilerplate. I think most of us wouldn't wanna write that boilerplate. Part of the promise of asynchronous functions is you don't have to write much more code than if you were writing synchronous functions. So how do we accomplish that? Well, we add a special contextual keyword called await.cancelToken, and this effectively replaces the code that you saw earlier. So these two pieces of code are actually equivalent. And so now with that done, we can see that we can actually support cancellation in our asynchronous functions by adding only one extra line of code. So hopefully that's clear to you. Cancellation tokens are pretty simple, right? They're just a shared object that you pass around between your asynchronous functions. And if you cancel one, it's the responsibility of that asynchronous function to throw and stop executing. So asynchronous functions, I think, I hope a lot of you are excited about it because they're pretty great, right? For those of us writing a lot of async code and probably a lot of us are using promises already, by the way, can I see a quick show of hands? Who's using promises out there? A lot of people, right? So this is pretty powerful syntax that you can just use out of the gate. Now that's great, but there's also other types of functions in JavaScript. Some of these other types of functions were introduced as well in ES6 or ES2015. One of those is the generator function. Now just a quick show of hands, I'm curious, how many people use generator functions? Or it may be indirectly, some of you use them in libraries, right? So fewer hands, but it's a very powerful type of function. So a generator function, basically it's a function that returns multiple values. So a generator function can return multiple values and when it's finished, it'll just tell you, hey, I'm done. So here's an example of a generator function in ES2015. So in the old version of JavaScript, if you wanted to return multiple numbers, you'd probably just create an array of numbers and return it. So notice here, this is a little bit different. We see this yield keyword and this yield keyword looks a little bit like a return and that's a good mental model for thinking about how yield works. It's sort of like a function with multiple return statements. And what it does is it allows you to return multiple numbers but instead of collecting them all up in an array and then returning them, you can return them progressively on demand as the consumer requests them. And that turns out to be a pretty powerful thing. So here's an example of how you use a generator function.  And I think some of you are probably familiar with the concept of iteration. It's been around in computer science for a long, long time, 20 years, possibly longer. So you get an iterator and then you call next and then you get back this pair, this pair of values. One is the value that you, the next number that you requested and the other is a Boolean saying whether or not there's any more data. And so it turns out, yes, we have more data. So I'm gonna call next again. And once again, we get another double, a little pair that says yes, here's your number and yes, we do have more data. So we call next again. And so finally we get a pair of the value and then the done property is now true. So we know we're done. And that's how a generator function works. It allows the consumer to pull values out progressively of a function and effectively lazily evaluates that function. So under the hood for those of you who are curious about how yield works, one way of sort of figuring out, intuitive how yield works is to imagine how you would write that iterator yourself if you had to. Well, you'd probably have to set up a state machine. So as you can see here, the first thing is this little example, this Fibonacci sequence, which is of course the ubiquitous programming example. We return a iterator. So you can see here that's that outer object with the next method. And then if you keep calling it, each time you call it, this function checks what state it's in. So it effectively figures out every possible state that the function can be in and then it just keeps moving through those states. So every single time you call next, it moves through the next state and then it returns one of these pairs. So that's all it's doing. It's building a state machine. But iterators are really powerful because you don't have to build that state machine.  It's a little like async functions because you just write your code top to bottom as if that code's executing and every single time the yield keyword comes up, the program might suspend, but then it'll resume from that yield point the next time you call next.  The consumer requests the iterator and then begins sort of pulling values out. And so we get 42, we pull out 39. And finally, we make our last request, we pull out that and we get a pair back that says, okay, 19 and done. And that's how we know we're never supposed to call next again. So generator functions are great, but they have to produce values synchronously. And that doesn't make them very useful for some of our asynchronous streams that we have to deal with. So what are some examples of asynchronous streams of data that we have to deal with in the browser? Well, I can think of one that probably a lot of us have had to work with, which is web sockets. Now, one of the reasons I can't use generator functions for web sockets is because, well, when you get a value from a web socket, it's asynchronous, right? It calls you. And when you call next on a generator, it blocks until it delivers you that value. And so it's kind of unfortunate that we have this nice function in JavaScript for requesting values, streams of values, but we can't use it for web sockets. So what's the solution? So what if we want to create an asynchronous stream of values? Starting in a future version of JavaScript, we are going to have the asynchronous equivalent of generator functions. And this is gonna allow you to do things like work with streams, IO streams of data like web sockets in a much more elegant and fluent way. So here's an example of how we can consume iterators. So earlier I showed calling next, calling next. Well, thankfully in ES 2015, we have a nice syntax for that. It's like a little for loop. And you'll see that we have a similar syntax for consuming asynchronous iterators soon. But here's how the producer looks. So if I want to create a generator function, right? And I want to read data from a file. Now I can actually implement this in node today because node actually supports synchronous IO. I don't recommend you do that because if you use synchronous IO in your web server, you're not gonna be able to serve other multiple concurrent requests while you're reading data from a file. So while this is possible, you probably shouldn't do it, right? So here's what it's gonna look like to do the asynchronous equivalent of this in a future version of JavaScript. So I'll do that again just in case anybody missed it. Right? Not too shabby, right? So all we did, once again, we added the async keyword and we just go await in front of any asynchronous operation. So in node, you could do something like this in the future to write code that consumes data from files and it's not gonna block. Now that's great for the producer. Hold on, I'll just go through this little consumption side. So if we wanna consume this, just like the previous example, it's pretty much the same. We requested asynchronous iterator and then we call next but now notice when we call asynchronous iterator.next, we're actually, instead of getting back a pair of the value and a boolean indicating whether we're done, we're gonna get it back a promise of a pair of a value and a boolean indicating we're done. So I just call then and I log the result.  And we see that the code on the left hand side resumes from where we left off. And finally, I keep calling it until I get my final value. So just an iterator of promises of pairs is kind of the right way to think about an asynchronous iterator. So once again, we'll visualize this process with an asynchronous iterator. We've got a consumer, we've got a producer. The consumer requests an asynchronous iterator from the producer and it requests a value but this time the producer gives a promise to the consumer and then the consumer resolves that promise and gets back a value. And we keep going like that. Now notice at the end, we just go ahead and we return this last value but it always gets wrapped in a promise so even though we're just returning 19, it's still gonna get wrapped in a promise so the consumer doesn't have to worry about getting a value or a promise and that's similar to the way that the promise then method works. If you remember, from your function inside of then you can either return another promise or a raw value and it all gets wrapped up into a promise so we see asynchronous iterator works the same way and so we're finally done, we stop. So we saw what it's like to produce an asynchronous stream but what about consuming an asynchronous stream? How do we consume it? Well in ES6 we added this nice sugary syntax for of so we don't have to write that next, next, next and that while loop, right? So it's a lot nicer to consume data this way from a stream. Starting in a future version of JavaScript we are going to see this. So as you can see, we've got four await, right? And everything else is pretty much the same just sprinkle await through keywords throughout your function and it pretty much just works. So you don't have to think very hard once again the focus is on symmetrical support for asynchronous and synchronous programming. So where are we gonna use this? Well, pretty much this is really appropriate type for any kind of push IO, right? Whenever we've got IO that's being asynchronously handled one such case is obviously web sockets but another case could be node streams and it's quite possible in the future both of these types could implement the asynchronous iterable contract which means you can use four await on them inside of asynchronous functions. Makes sense? So there are some streams that are not very patient. They will not wait for you to be ready and request another value from them. Now perhaps the most notable example of such a stream in the browser is event target the event target API which I think a lot of us in the room know better as add event listener, remove event listener. The thing about DOM events is they don't particularly care whether we're ready for them or not. Whenever somebody moves that mouse or whatever the DOM loads it's gonna call our callback right away and we have to react to those callbacks. So asynchronous iterator isn't really an appropriate API for that type of thing, right? Asynchronous iterator is for when the consumer's in control, right? When you wanna decide when to pull the next value. So we need another type for these push streams. So here's an example of some push streams, DOM events, set interval, right? Which calls a callback every few seconds, right? Set timeouts actually probably not as good an example. That's probably something better for a promise because it always calls you once. So the interesting thing about the web is that there's no standard observable interface. We have an iterable interface which is now standard in the latest version of JavaScript but we have no standard way of observing data. So you have a lot of different APIs which can push you and call callbacks but there's no one interface to capture all of them in a consistent way. So here we have another proposal for an observable interface in the upcoming version of JavaScript and that's currently at stage one. So I'll tell you a little bit how it works but I think you're gonna start to recognize a pattern as we go through it. First of all, here's what the interface looks like. It's actually two interfaces. We have the observable interface which accepts an observer and an observer is really like a batch of three different callbacks. It can push you a value. It can push you an error or it can push you a completion message. And the idea behind an observable is it's really to take the iterator contract that we showed you earlier and kind of flip it inside out. An iterator, as we saw earlier, you can keep pulling values out until finally you get that little pair that says you're done. And another possibility is that when you call next on that iterator, just like when you execute any JavaScript function, it could throw. And so there's really three semantics that that iterator supports which is give me a value, tell me whether I'm done or not and possibly throw an error. And so what we're doing on the committee is we're trying to take all the same semantics that you have in the iterator contract and we're turning them inside out for the observer contract. And so instead of you calling next on an iterator, you provide the observable with an observer and it calls next on that observer and pushes the data to you. So the difference is really about pulling data out which you do with an iterator or pushing data at you which is what's done with an observer. So let's see what that looks like. So we actually have, as I said, these two interfaces that work together. So let's visualize it. So let's pick up where we left off with iteration. So we have, we still have a consumer and we still have a producer. But now the producer is going to be the observable and instead of a consumer requesting an iterator from the producer, it's going to provide an observer to the observable. It's going to provide an observer to that producer. So we pass in the observer and then the producer actually pushes data at us by calling our callback. So it calls those three callbacks, observer.next pushes it 42 and then it'll just keep pushing. So in this case, notice the big difference here is the producer is in control. Not the consumer. I don't decide when I get the next value. The producer decides when I get the next value and that's how DOM events work and that's how said interval works, right? So we're trying to capture an interface, trying to pick one nice consistent interface for handling this type of interaction. And so the equivalent of giving us a pair with that done, colon, true on it is actually invoking our complete callback. So it's the same semantic. It's handled a little bit differently because it's more convenient to get a special callback for when we're done but it's basically the same three underlying semantics. So one of the nice things about observable is that it actually is gonna support the same mechanism of cancellation that the asynchronous functions we saw earlier are. So optionally, you can provide subscribe with a cancel token because let's say you subscribe up to an event and you decide at some point, you don't wanna listen about an event anymore, right? Today you would call remove event listener but the equivalent of that in the new world is you're just gonna be able to take that cancellation token and then call cancel on that, you're gonna cancel that cancellation token and then the observable is gonna check that cancellation token and if it's canceled, it's gonna unsubscribe for you. So no more add event listener or remove event listener, you're basically just gonna be able to use the same cancellation token you're already using in your asynchronous functions and thread them right down to events. So as you can see, you can call subscribe and pass in this observer object. That's what's right here with the next complete and error functions and then the optional cancellation token. So that's how the observer works and if we were to go ahead and run this, we might get pushed three values in a row and that last value is gonna say done. So that's how you would use an observable. So what are some of the APIs on the web, the web platform APIs that are gonna use observables? Well, we have DOM events and said interval are obvious cases of two interfaces out there that would make sense to be able to use with observables. I think it'd be really nice if this and any future push APIs just all use the same interface because then we can just think about them all the same way. Now, one of the big benefits, so you don't have to write out event listener or remove event listener, so you subscribe to set time out slightly differently. Is this really that big a deal? Well, yeah, it is. The reason why we should have one interface for all these types of push APIs and one interface for all these types of async IO APIs is because of something very powerful, composition. We as developers need to build, need to control complexity and build large projects by taking small elements and composing them together. And one of the really powerful things about these types is that they compose. So here I'm gonna show you an example of what it might look like. Let's say I wanna take a web socket and I wanna look for big price spikes in a particular stock. Well, here's an example of how I could use a library like underscore or low-dash. Somebody could write a library like underscore or low-dash. For those who aren't familiar, these are a collection of functions used to compose types together. Somebody could easily write a library like low-dash or underscore over our asynchronous iterable interface and now all of a sudden, we can create with just a tiny bit of code, a stream that only calls us when a price spikes on a stock. So this is an example of looking for price spikes in the Johnson and Johnson stock and just consuming that data only when we get a price spike. Likewise, you can take observables. I'll just pause for a second to let that... So notice we're here using the filter method on arrays. Just like you can use the filter method on arrays, you can use the filter method on asynchronous iterables and it does the exact same thing. And this scan method, for those of you who aren't familiar with it, it basically behaves like reduce over arrays except it gives you every intermediary computation. So unlike reduce, scan is just gonna sort of keep this stream open and give us every single price spike as it arrives for the lifetime of this web socket being open. So you can perform progressively more powerful computations. And for those of you out there who are familiar with functional programming, you know that this is a very powerful and fluent way of writing programs. And so this is one of the big wins out of having a single standard interface for all of these different data sources. Suddenly it becomes really easy for web developers to compose them together. So in addition to composing asynchronous iterables, this is one of my favorite little examples of what it looks like to compose observables. So imagine tomorrow every single DOM event was suddenly exposed as an observable. So you actually had an object that represented a DOM event and it had these powerful methods like map and take until and merge all. I can actually write a drag and drop event by composing together a mouse up, a mouse down and a mouse move event with just a few functions. Now you don't have to fully understand how this code works, but there are libraries out there already to help you compose together these observables because observables are just a library, so you don't have to wait for this to come out in JavaScript. You can actually use libraries like RxJS or BaconJS, which already exists. Think of them as like underscore for events or low dash for events for those of you who are familiar with this. And it's actually a really powerful way of building asynchronous programs. So this is just an example of a tiny little spice of code to write a mouse drag. So I'm gonna wrap up here. I actually have more, I honestly, I had a lot of stuff to talk about with ES6, but I only had 30 minutes. But if anybody has any questions about future ES6 features, I may actually have some slides about them. But I'm gonna wrap up at this point because I'm pretty much at the 30 minute mark and just give you my tweet handle there, which you can follow. And I talk about a lot of TC39 stuff. Now, if you wanna start using these features, make sure to check out Babbel. I'm curious, how many people are using Transpillation out there already? Okay, so the good news is you can use some of these features already and some of you may indeed already be using them. And you can also check out es-discuss.org, which is where the TC39 goes to engage with the community and talk about these features. If you wanna use these features and come back and express your opinion, tell us where those pain points are, that's really valuable to us on the committee. That's one of the reasons why we on the committee love Transpillation.  Cool new JavaScript features that with backwards compatibility in all the features, how do we avoid becoming overloaded if we like C++? So JavaScript fatigue, who's heard the term JavaScript fatigue, right? Oh yeah. There are a lot of people out there who might be, especially, you know, we see some of the stuff coming out, right? With these frameworks, we've got language features, how do we avoid being overloaded? Well, the reality is, you know, when you're learning about abstractions like this, right, I think personally, writing that example we saw earlier with async functions is a hell of a lot less complicated than using callbacks to do it. And my personal opinion is that a lot of us are just familiar with what we already have. And yes, we will have to learn a new thing. But personally, I would much rather use the syntax that we saw today than try and build programs as a mess of callbacks. So I think most of the features we've introduced today are gonna make JavaScript developers' lives easier. Yes, you will have to learn things. And a lot of people have a lot of anxiety about JavaScript because look, it seems, I think to some of us, like JavaScript's moving really fast because for a long period, it was completely dormant. Basically, it didn't change for almost 10 years. And now all of a sudden, it's changing, it's changing. And I'm here to tell you, it will continue to change.  There's more and more features that are gonna get added to JavaScript. And that's what happens with languages that people use to solve real problems. We're gonna continue to evolve that language. It really doesn't profit anybody for that language that people are using in an active way. And we see the way the web's changing so quickly to just set it in stone. The reality is you're gonna have to learn more about it. It's an evolving, changing, living language.  I think it's gonna keep moving. I think that's a great thing. Which leads me neatly into a question that's been asked multiple times, actually. With the new version of ECM script, JavaScript coming out every year, will we ever be able to avoid an intermediary transpilation stage? I could give a more diplomatic answer to this, but no. You'll be transpiling forever. And the reality is, do we care?  How many people's build step is actually hitting F5 in the browser? Very few, right? I really, the reality is we now have source symbols in JavaScript, which means that after you compile or transpile your JavaScript, you can even debug the JavaScript inside of your browser in the original form in which you wrote it. And that's really the right move here. The right move here is to continue evolving the language, starting to use the features now immediately with transpilation and providing great tooling support for allowing you to debug those features. So increasingly, transpilation feels less and less intrusive. So you'll be transpiling forever and we should be happy about that. I don't really, I don't think it's actually disrupting people's build process very much. In my experience, it's people who don't have a really good build process are the ones who are concerned about this. And my advice is get a good build process. I'm tremendously excited by your talk actually, because it feels like there's real joined up thinking in TC39 now, like with the composability, reusing the same syntax, et cetera, and addressing real problems, not just syntactic sugar stuff. And that's really exciting. Could you repeat the place where people can go and talk to TC39 and give feedback, please? Yeah, absolutely, it's esdiscuss.org, right? And so one of the great things, as I mentioned earlier, about so many people using transpilation is that you can try stuff out and you don't like it. If you don't like it, feel free to tell us, right? We can take the criticism. And that's part of the idea behind the staging process. Before transpilation, actually, those of us on the committee were in a very difficult spot. When we designed a new feature, we had to go to browser vendors and we had to say, hey, can you guys kind of try this out? And it turns out browser vendors are really busy. They've got a lot of things on their mind and they're doing a lot of things and they don't want to spend a lot of time implementing some feature that might eventually make it into the language spec, right? Because then usually you also had to rely on developers or users to actually turn on this compatibility flag because instead of just unleashing new features under the web where people like to take dependencies on them, browser makers wanted to put them behind this compatibility flag. So people had to go into some config menu and turn them on and web developers, likewise, didn't want to use some feature that most people wouldn't even have available to them. So transpilation kind of breaks that cycle and it allows you to use new JavaScript features in a very low risk way and also provide us with real feedback about the ergonomics of that feature. So transpilation's been huge, I think, for the committee and I think it's gonna be huge for the web. I want to reiterate as well because I've been active in the HTML and the CSS spec and I'm deputy CTO of Opera, the browser. Tell us what you need, tell us what you think because there's a million problems to be solved in browsers, in HTML, CSS, and JavaScript. We need your feedback to tell us which of those million problems we should prioritize. Please tell us your feedback is really important. Last question is one from me because I have MC rights and I can ask a question of my own. Great. If you couldn't wave a magic wand and spec a JavaScript, a new from scratch just by yourself, would it look anything like the JavaScript we have now? No. No. Very diplomatic. Could you expand a little bit on how that differ? You know what the reality is, JavaScript, the lion's share of JavaScript was actually delivered and designed in about 10 days by Brenner Dike. Honestly, the fact that JavaScript works as well as it does when it was designed in 10 days is an incredible feat. And I don't think you'll find many people in the industry who say JavaScript's perfect, it's a great language. But personally I gotta give a lot of respect, I got a lot of props to Brendan Eich who did a hell of a lot better job in 10 days than I did. Now, there's a lot of JavaScript haters out there, people who think JavaScript's not a great language, particularly those who come from other languages who some people might say are better. And I have this to say, frankly things could have gone very differently. For those of you who were around when I was 10 or 15 years even, writing browser applications, just with a slight twist of fate, we could all be talking about VB script right now. So just counter-checking, things could be a hell of a lot worse, right? So there's that one point. I think JavaScript is an imperfect language and the reality is the reason why we're gonna try and continue to evolve it and the reason why you see people using things like ESLint rules for example, and a lot of us have read Doug Crockford's JavaScript the good parts, is the idea is we wanna find the core of JavaScript that's really good, right? Then we wanna build on top of that core and make that core easier and easier to use and make it so smooth to use the good parts of JavaScript because there is a really good language embedded in there somewhere. Beyond all the terrible parts, the automatic implicit type conversion and automatic semicolon insertion, things that we never would have done had we designed JavaScript today. There's actually a beautiful and elegant core to JavaScript. And our job is to make users, make it easier to use that core because we can't take features out. We cannot break the web. So those features are gonna be there forever but at some point they're gonna look like fossils because you wanna use them. You'll wanna use the cool new hotness, right? It's not about taking features away, it's about making it really fun and easy to use the good parts of JavaScript and building on top of them. So unfortunately, JavaScript will continue to be a very imperfect language and there's a lot better languages out there you can design personally, I think Elm is a way better language than JavaScript. I'd much rather write most of my code in Elm, right? But you know what? I think we're gonna find a great core in there and I think we're gonna make it very usable for the vast majority of developers. Excellent. Thank you very much. Jaffa, Jaffa is saying, ladies and gentlemen.


expense for year one it also equals the depreciation expense for year two so those two added up would be the accumulated depreciation prior to the accumulated depreciation or the depreciation expense calculated in year three meaning we can also see it in this table as well it's the 193 125 so then we have that information and we're going to then subtract that out that gives us the book value prior to this so the book value prior to the current period is going to equal the cost less the accumulated depreciation prior to this period and once again it's the same number that we calculated up here but you just want to make sure that you have something set up where you're calculating this number out then we're going to multiply that times the double declining rate and the double declining rate is still this 50 percent so we're going to multiply it times 50 percent and so there we have this once again I could underline here we're going to multiply it times 50 percent so now we're looking at these two numbers here this and this and that will give us the depreciation for year three so I'm going to put my cursor here and do this calculation this equals the book value before this time period times the double declining rate gives us the depreciation for year three if we look at there our little worksheet up here then we are currently on work three uh year three depreciation is going to be what we just calculated but they could also ask what is the accumulated depreciation or the book value and in order to do that we're going to take the cost the cost will be the same so the cost will be equal to this 257.5 like so and that'll give us the 257.5 that does not change the accumulated depreciation would then be calculated as the prior year's accumulated depreciation plus the current year's depreciation expense or you can think of it as all three years so far in this case depreciation expense we add them up it comes out to 225.313 then how do we calculate the book value it equals the 257.5 less minus the 225.313 and that gives us our current book value if we look at that in context of a journal entry and our accounts remember we're on year three now we have our book value before this transaction all of our prior year year two has been closed out to year three equity account and therefore we're saying that we earned this another hundred thousand this year it's just the exact same of our earnings as the prior year and we have not yet recorded the depreciation and therefore if we do that then the depreciation in year three now they have to just we've calculated the number to be this 32188 so there we have the depreciation expense notice the decline in depreciation expense over the year that's why it's a front loaded method an accelerated method and that brings the net income from 100 minus the 32188 to the 63813 then we're going to credit the accumulated depreciation and that brings the cumulative depreciation the contra asset account the asset with a credit bounce up and the net income down for the 257.5 less to 225.313 to 32188 which is what is on our worksheet over here all right let's do this one more time now year four has a bit of a twist to it and this is often very very confusing to a lot of people and the problem is that the accumulated depreciation method is not perfect in its math it front loads the depreciation expense and whatever the final year is which happens to be year four in this case basically just needs to be plugged rather than us doing the calculation as we have done in the past so I'm going to do it the wrong way first to show you what we have done and the logical next step that you would think that we would do for year four so you can see the the imperfection in the math then do what we need to do in order to plug the number in terms of what we want it to be so you would think that the calculation in year four would be the book value I'm going to do this in a kind of short invest method it's going to be the book value from the prior year so it would be the cost less the accumulated depreciation given us the book value we've already calculated that though so I'm going to say that equals the book value up here the 3218188 and then we would multiply that times the double declining rate which we know is 50 percent and I'm going to make notice it came out to one because I haven't changed the cell to be in the terms of a percentage there's the 50 percent and if we multiply that then that would equal we would think the depreciation for year four so let's do that I'm going to say this equals the 32188 times the 50 percent and enter and then I'm going to plug that into our numbers up here and see what happens in terms of our worksheet we would think that the depreciation for year four then under this method should be the 1694 and if we calculate the book value then the cost is the same the accumulated depreciation equals the prior year accumulated depreciation plus the current year expense or if we highlight all four then we got the 241 416 the book value then is 257.5 less the accumulated depreciation and that gives us the 1694 now there's something wrong with this and I'll give you just a second to try to think about there's this what is wrong with that 16094 it's not as obvious as it might be if we had no salvage value but the but if we think about it the salvage value is is the problem here we remember that we said that we think we can scrap this piece of equipment for 20 000 and therefore we have we do not want to take the book value below the amount we believe we can get if we scrap it being 20 000 so what happened here is this depreciation took us to amount below the salvage value now this again it would be a lot more apparent if we didn't have a salvage value if we just thought that the equipment would be worth nothing at the end because this number would then be negative which makes absolutely no sense it doesn't make us any sense to say we have a fork left on the books which is worth negative 10 000 that doesn't make any sense all we're trying to do is allocate the cost if we say that the the floor is the salvage meaning we want to bring it down to the salvage then we have to stop at the 20 000 and this method because it's double declining is not perfect meaning the math just doesn't work perfectly and that's okay because it's just an estimate anyways and uh we don't need to be perfect it's just an estimate so we are going to just plug in the final year so it does kind of what we want it to do we just plug the final year so then we got to think about okay well i'm going to delete this and i'm going to go back down here i'm going to do it the way we have to do it any final year if it's a seven-year property it's going to be happening in basically year seven that we'll have to do this kind of plug calculation here's one way we can think of it we're going to start off with the cost again which is 257.5 and then i'm going to say less the salvage value and the salvage value remember from the problem was this 20 000 so this is where the salvage value comes into play 20 000 and now of course i've made it a percentage so i'm going to go back to the home tab the numbers group and i'm well actually i'll just go to this tab i'll format paint it and i'm going to turn it back into a number format and 20 000 be careful of the sales formatting of course anytime you work with these and that's going to be the amount to be depreciated so i'm going to take this calculation it's going to equal the 257.5 less minus the 20 000 and we get the 237.5 why are we doing this because basically if i want 20 000 left that's what we want to be left with then over the useful life of four years we will have to depreciate 237.5 why because the cost 257.5 less the 237.5 equals the 20 000 so over the useful life this is what we want to depreciate now if we subtract out the depreciation for all prior periods as of this point we had year one depreciation of 120 750 plus years two's 63 3475 plus year three 32188 that's the accumulated depreciation as of this time period once again we also calculated it in this format here meaning prior years accumulated depreciation plus the current year and that means that's what we've done so far so i'm going to put some underlines here we'll say this will be an underline here and then we're going to do the underline here and that will give us the the depreciation for year four that we need in order to leave us with the salvage of 20 000 hopefully and we'll so we'll double check that so this equals the uh what we want to depreciate over the useful life less what we've done so far prior to year four and that gives us the 12 i'm going to put an underline under here and we'll double that here and now let's go back up and see if this does what we want to do well what do we want to do leave us with a with a book value equal to the salvage of 12 20 000 all right so let's do that we're going to say in year four the depreciation we calculated to be now the 12 188 we know that if we calculate the book value then that's the cost less the accumulated depreciation cumulative depreciation is the prior years accumulated depreciation plus the current year's expense or just highlights all four years of depreciation if we add up the depreciation 237 5 then uh if we subtract this out the equals the cost less the accumulated depreciation is going to equal what's it going to equal hopefully 20 000 and it does so now we're left off with that 20 000 what's going to happen in year five absolutely nothing we're not going to depreciate anymore but what if we're still using the equipment still not going to depreciate it because we're not going to depreciate it below what we believe we can scrap it for and uh if it's if it's a significant amount we may have to adjust the estimate and say well the estimate was wrong and re-estim- adjust it what we will not do is depreciate it below the salvage generally or below zero of course uh we weren't we're not going to have a negative value of an equipment we'll now record the depreciation expense our normal journal entry is going to be down here so once again the depreciation expense for the current year is going to be this 12 188 and once we hit enter it'll record this amount here and it'll bring net income down like so and note the trend here note that what is happening to our depreciation expense it went it was way higher in year one it goes down in year two down in year three down in year four that's the idea of an accelerated method and note what that does to net income if all else is equal meaning if we say that we are only factors are going to be that we have the same revenue each year of 100 000 and the only factor being depreciation and look at that factor then we're going to say that that created actually a loss in year one it created income in year two and income increased in year three and an income increased in year four if we looked at the straight line method and we said that depreciation expense is the only factor then it resulted in a same net income over the time period and it's up to you to decide whether that's appropriate or not because the question is did we really get more value out of the depreciation of the equipment in year one then in year two was it more productive for us in year one than in year four so if we record the credit then what's going to happen when we hit enter this amount will go up bringing the book value down we're back in balance here if we still have the the equipment purchased for this amount less the accumulated depreciation leaving us with the salvage being the 20 000 what's going to happen next year in year five we're not going to record anything because we have depreciated it down to the salvage value


This is stock number 10429, we are here at Summit Automotive in Fond du Lac, Wisconsin, your new and used Jeep and Wrangler headquarters. Today we are checking out this super clean, low mileage 2015 Jeep Wrangler Unlimited Sahara. This vehicle has the 3.6 liter V6 motor, has been fully safe and inspected by our service shop, has a fresh oil and filter change, all the fluids have been checked and topped off and this Jeep is 100% ready to go. Bright white is the color, we shoot all of our videos in 1080p, 60 frames per second, so if you have HD capabilities on your computer tablet or smartphone device, turn them on right now because it is like you're right here looking at the Jeep with me and definitely your best way to check out the vehicle quality and condition wise before seeing it in person. It has some very heavy-duty rock rails with step pads, moto metal, painted and polished aluminum rims and if you want to check out more pictures of this Jeep in the upper right hand part of the screen is a link right to our website. As Nitto Trail Grappler 35x13.5R20 LT tires with about I'd say 80 to 90% of the tread left has a rough country suspension lift kit on it and you can see that's a pretty substantial lift, probably like a four or five inch lift kit on here. Has some XRC heavy-duty bumpers as well as fenders, has a Smittybilt XRC 9500 pound winch with a metal cable, hoods in pretty nice condition, does have a high mount jack, an LED light bar and you got those XRC fenders there, pretty nice condition. Passengers side rim, no scuffs or scrapes on that and as you go down the rest of this side of the Jeep you can see just how clean the body is, how reflective and mirror like that paint is. We take these HD videos so if you are far away or even if you're close by and just cannot make the trip down you can still see the Jeep, hear the Jeep and have confidence in the vehicle that you're looking at before you even get here so that when you get here there's no surprises or you'll have a really good idea of the condition and quality of the vehicle before you get here so they can make a smart buying decision from the comfort of your home. In fact we offer a Summit Auto Fastpass option on our website in the upper right hand part of your screen where you can apply for financing, get pre-approved on this Jeep, even see payment quotes or appraise the trade all right from the comfort of your home. That's in the upper right hand part of your screen, back tires have just about as much tread as front tires and that frame and under body looks really good. Coming around to the back has an XRC rear bumper as well, matching spare tire. Those tires have all the tread left so you can see that compared to the ones that are on it so lots and lots of tread left on those tires. That's why I said about 80% rear gate opens up nice and easily. Sometimes with these big rear tire carriers they do not always open up very easy that one's nice and smooth rear bumpers in nice condition so this thing's got a lot of extras on it has a pump on it I guess you could say it also has a storage compartment has a I believe it's a bikini top in here so it's a nice lockable storage compartment and not a lot of room back here does come with the soft top as well that's the original soft top that comes with the vehicle we could not install it with this box back here so and have the hard top on so that's why it's just laying back here got some Smittybilt bags back here as well that gate shuts nice and smoothly and this rear gate shuts nice and easily as well this is where you hook up your air compressor or your hose for the air compressor down this side the hard tops and excellent condition as well no scuffs or scrapes on that color matching hard top and this back room no scuffs or scrapes on there either down the rest of the side of the Jeep very nice and clean it does come with heated power mirrors inside the Sahara package gives you the brown leather interior you get these Sahara Sahara logo stitched into the back rest no rips or tears on those seats and it does come with weathertech floor mats as we hop inside the vehicle here you can see that this one only has 8,500 and 34 miles outside temperature and compass display comes with a leather wrap steering wheel that's in really nice condition cruise controls on the right and information center controls on the left audio controls on the back of the steering wheel this one has the 430N radio with AMFM and Sirius XM radio capabilities it also has the factory navigation you also have a hard drive on here where you can store music and pictures and that's 28 gigs worth of hard drive space power window buttons climate control down here you have your heated seat buttons stability control downhill assist there is your gauge for your compressor in the back and 4x4 shifter on the floor as well as your automatic five-speed transmission passenger side seat and floor mat are an excellent condition and the front hardtop pieces are in great shape as well get the auto-dimming mirror this is the original windshield no rock chips or anything like that on there that's in really nice condition we'll take a look at the back seats and see that this back seat is in nice condition and the other one is in just as nice of shape have a factory floor mat back here you can see the rest of that soft top is back here as well we'll take a quick look under the hood I would personally like to thank you for checking out the video today and hopefully from this HD video you'll have been able to tell just how clean this Jeep is all the way around inside and out under the hood we have the 3.6 liter v6 pentastar motor engine base very clean runs very smooth it does have an AFE cold air intake this Jeep has been fully safety and inspected by our service shop has a fresh oil and filter change all the fluids have been checked and tapped off the vehicle has been gone through mechanically 100% and is 100% ready to go to see more pictures of this Jeep or one of our other 450 new and used cars trucks SUVs minivans Wranglers half-tons three-quarter tons one-tons you name it we got it go to our website www.summitauto.com full pictures and descriptions of every single vehicle from two locations all at summit auto.com and if you'd like to check out more HD videos you can go to youtube.com slash summit auto remember to like subscribe and share on this video and all the videos that you see there in fact any second you will see link to subscribe to our YouTube channel on your left a link to more Wrangler videos like this one on your right if you have not been to our website on the bottom link to this vehicle on our website click those checks out and we really look forward to helping with this super clean 2015 Jeep Wrangler unlimited say hero. Thanks again.


Hello, welcome. I'm Sifu David and today we're gonna do the Bruce Lee speed punching exercise with a candle flame punch You're probably wondering why I'm wearing this face mask is to make sure that you guys know that I'm not blowing out the candle I'm actually just using the air force and pressure that's created from my fist So stay tuned. I'm gonna show you exactly how you can do that how you can train it Why we train it so that you can have even more powerful and faster punches just like Bruce Lee


I'd like to make some comments while Ratio gets set up. We're planning this year after the close of each quarter to bring a report to the council and let you know how we feel we're doing comparing our revenues to our expenses that we've put in our budget. The other thing you're going to see today is Ratio is going to show you the gap projected for next year and one of the things we're going to be doing is keeping the council up to date but we want to begin working on that gap now and try to get the revenue lines and the expense lines on top of each other so when we bring you the budget we won't be bringing it to you with that large gap if we can solve that problem. So we'll be doing this quarterly and update on where we are on our budget. So Ratio? Ratio. One of the members of City Council, Ratio Porter, the budget officer. Thanks for that introduction, Tom. This is the first of several quarterly reports that we'll be doing this fiscal year to highlight the results for the budget and also the results for the year. What we'll try to cover today real quickly is the strategic approach we'll take to the reporting that we currently do as well as we'll review the budget update for FY2011 and then we'll give a preliminary review of the budget gap for FY2012 and we'll spend just a few minutes talking about capital planning. As you know, we like to take a different approach towards the budgeting process this year and Tom alluded to this earlier. We spend an awful lot of time, spend six to nine months every year discussing the real tough decisions for the budget, the reductions that are necessary, the cuts that we have to make and the layoffs that may be impending and those oftentimes very difficult decisions. What we want to try to do going forward is not spend so much time focusing on the negative impact but also give the Council better information on what we are doing as a city. There's 6,000 employees that work here day in and day out providing services for the residents and we think we owe it to the Council and to the residents to do a better job of reporting what we are doing. Again, it's easy to focus on the 100 layoffs we had last year, the services that are getting eliminated or reduced. We want to try to do a better job of providing this Council and the residents more information throughout the year. So what we want to do is provide a quarterly report and every quarter as Tom mentioned, we'll come to you and give you financial update on where we stand. We'll also let the departments give you an operational update, some things that they're working on in their organizations that demonstrate their ability to deliver services throughout the city. And the other thing we want to try to do going forward is provide better information on capital programs. We haven't done a real good job of giving this Council updates on the various bond programs or critical capital campaigns. We want to try to do a better job of that going forward. On the financial updates we'll talk about, again, the FY 2011 update and we'll also talk about the preview for the 2012 and then our operational. Each department has various goals and objectives that they're working on and we feel we owe it to the Council to give you that information throughout the year. Oftentimes we try to cram that information into a budget retreat and we'll hold you up for two whole days and departments, right before you can give you all this information, it's difficult for you to try to process all that information and understand what that means for the budget. So we want to try to make sure we give you that information year round. As we move into the FY 2011 budget gap, if we look at just the revenues, we look at the revenues we started out with for FY 2011, significant changes we've seen already in revenues. One particular decline in revenues on auto power and towage and storage fees, as you know, we moved that location from the previous location to a new location and we're just not able to process as many vehicles as we originally planned so as a result of that, that revenue is down and it will be down, we anticipate for the rest of the fiscal year. We've also seen a reduction in traffic fines of about $370,000 in talking to courts. We've actually written fewer citations this year than we have last year so that's actually a good thing that there are fewer citations but the downside is we have fewer revenues and we had originally budgeted it. In addition, there's some other revenues that are down compared to the budget as well. There is one significant bright spot and you see the sales tax improvement. In our packet today, there is an IR on sales tax collections. For the month of December, we collected the highest sales tax ever in the city of Fort Worth. The highest sales tax ever in the city. Again, the highest sales tax we collected, $1.3 million more than we collected last year. Through the first three months of this fiscal year, just the first three months of this year, we're already $2.3 million ahead of where we budgeted in sales tax. So if those trends continue, sales tax will really be a positive impact for the city going forward. Again, we're 9% higher than we were last year, 9% ahead of budget. So again, sales tax really are pretty strong and it's in a lot of different categories and we can provide more detail on those categories. But on the revenue side, there are some shortfalls in our revenue that we're anticipating, but there's a pretty significant increase in our sales tax. We're forecasting sales tax to be pretty flat going forward, but that's conservative. We do anticipate sales tax to be significantly higher as new through the rest of the fiscal year. On the expenditure side, there are some expenditure changes that we've seen since the adoption of the budget. During the budget process last year, we were actually in the process of negotiating our electricity contract. That contract was finalized a few months ago. That yields a savings of $1.2 million. Additionally, we have some personnel-related costs. There's some positions that hadn't been filled. So there's some savings that the departments are actually capturing now in the budgets that are positive. And there's some other savings that we're seeing as well to the tune of $601,000. So all told, about $2.6 million with fewer costs that we're anticipating this upcoming fiscal year as opposed to the original budget that was adopted again in September. This slide is intended to give you an overview of the entire general fund. And I'll start at the very top here, the adopted budget. And as you know, the adopted budget for revenues for the general fund is $522 million, and the expenditures were $531 million. There are some reductions that this council didn't want to impose last year. We didn't want to close all the libraries. We didn't want to deactivate fire companies. There were some other reductions that the council chose not to take. So to offset that, we used excess fund balance. The decision made last year to use excess fund balance to the tune of $9 million to fund those critical programs that this council felt were important. Since the adoption of the budget, there have been some supplemental appropriations that this council has approved. $2.6 million of additional revenue, and there's also $17 million worth of additional expenditures that this council has approved in supplemental appropriations. And that uses additional $15 million of the excess fund balance. And we just talked quickly about the changes in the revenues and also the changes in expenditures. All told for the fifth of the year, based on the results through December, we have revenues of about $522 million, expenditures of about $546 million, which means we're going to use about $24 million of the excess fund balance. As of now, we have $35 million of excess fund balance available. So we have the funds to cover the supplemental appropriations that were approved, and the funding of the critical expenditures that were identified in Lash's budget. So again, we have $24 million of use of fund balance, and we have about $35 million of estimated excess fund balance to cover those costs. That leaves a remaining $11.2 million of savings in our fund balance, if you will, to cover future costs of future needs. This slide here shows the city-wide view of selected funds. You'll see again the journal fund. We'll focus on just this column here, the source and use of fund balance. Again, we talked quickly about the journal fund, $24.4 million of fund balance that we'll use, but again, there's $35 million of excess fund balance that we have available. On the enterprise funds, again, water, sewer, and those other funds, they're going to actually contribute to their fund balance to tune about $3.6 million, and their fund balance hadn't been calculated at this point. On the insurance funds, they're going to use about $1.8 million of fund balance, and this is in large part to workers' cost claims. They're definitely higher than we had anticipated. Now, although they're going to use $1.8 million of fund balance, they have $7.9 million available to use. Insurance funds, not a significant change. On the CCPD, or Crime Control Prevention District, they're anticipating using $1.7 million of their fund balance. As you know, much of that is to purchase the vehicles that were part of their budget last year. Again, they still have an excess of $6.1 million to cover that. Now, culture and tourism, they're doing some renovations at the Will Rogers and some other facilities to make up the facilities what they need to be. And they also have $12 million of excess. So, all told, the property's either within budget, the funds are within budget, or they have the available excess fund balance to cover the shortfall. This chart here, as we shift towards FR 2012, you were to call this chart last year. At the start of the budget process last year, we were anticipating a $73 million gap. It's a venture line growing significantly, and a revenue line not as significantly. We were anticipating a $73 million gap in the first year that rose to $100 million here, and ultimately to $142 million in the out years. Based on the decisions that the council made last year and some of the changes in the assumptions, we were able to close the FY20 budget gap. In large part, there's still use of fund balance here. We were able to close that budget gap, significantly bringing the old red line down to the new red line, and their green line of revenues up slightly, so the gap is now $31 million. It's a pretty dramatic reduction in the gap, and it stays pretty steady till FY 2015. What I'm going to do now is walk you through real quickly what gives rise to this $31 million gap so that we're all clear on the gap. Again, FY 2011, we adopted the budget, and we're assuming we're going to use $9 million of fund balance. We can total revenues of $522 million, fund balance of $9 million, and we had $531 million of expenditures, so that was a balanced budget with the use of fund balance. But with some everything else stays the same. We assume revenues stay the same. Initially, if we assume the revenues stay the same and expenditures stay the same, then we're $9 million. There's a $9 million delta. We've got to make up that $9 million delta going forward. Moving into the FY 2012, we start with $9 million that we've got to make up that's part of the expenditures. Here's some costs that we knew we were going to have last year, above and beyond the 2011 budget. The police and fire contract, we knew health insurance premium was going to go up about 12%, the fund retiree health care over 20 year horizon. That's that impact. And these are costs we knew above and beyond the budget. There are also some non-recurring costs that we won't see in FY 2012 to Super Bowl. We won't have another Super Bowl expenditure next year. We also won't have any election next year. We won't have the state legislative session next year. So those costs in FY 2011's budget we won't see again next year. So the baseline, if you will, the starting point is $23 million budget gap for FY 2012. In addition to that, what could happen or are likely to happen in FY 2012 that add to the gap? We've talked a little bit about sales tax. We anticipate sales tax revenue to continue to be strong as we move through this fiscal year but also through next year. There's also some incremental property tax revenue that we're anticipating. So about $7 million more than we adopted this year in additional revenue that we'll have. Now the recommendation made last year by the mayor's task force to move one penny of the tax rate from general fund to debt service to increase our debt capacity to deal with transportation issues. If we do that, they cost the general fund about $4 million. The next item here, $4.8 million for pay increases. General employees didn't receive a pay increase in the current budget year. There's actually a 3% pay reduction last year and it's the thought at this point that we need to begin to make some allowances, if you will, for pay increases for general employees. Police and fire both have their contracts but there also should be some consideration if you will for raises for general employees. This next item is just a placeholder for things that we don't know about, whether it's the state legislator or just new costs that we may have, whether it's park land maintenance, those kinds of things that we may incur in FY 2012. There was a decision made last year, a recommendation made last year to continue transferring costs from the CCPD fund to the general fund. That impacts about $1.2 million, almost $1.3 million in inflation and other costs. We're looking at which is significantly better than a $100 billion gap, which we were facing before we made those changes. A $31 billion gap is clearly better than a $7 billion gap that we saw last year. This last item on here is police and fire training facility. I believe you've been brief on that and the impact on that number, the impact on FY 2013 could be about $5.7 million going forward. The challenge, and Tom mentioned this earlier, how do we begin to tackle this $31 billion problem? So August and come back with recommendations that are oftentimes difficult and challenging and oftentimes painful. And the goal this year is to begin dealing with that as it goes throughout the fiscal year. We've already identified there's an estimate of about $11.2 million of excess fund balance that the council has that we could use to address FY 2011's 2012 budget gap. Additionally, the Aviation Fund will be reimbursing the general fund for fire services that have been provided throughout the city. That amount is not determined at this point, but there could be a potential source of funds that come through the general fund from the Aviation Fund. The other critical point and what staff will spend some time on over the next few months is identifying savings in the FY 2011 year to build into this, to add to these $11 billion. It'd be great if we can come back to this council, I don't think it'd be great. I think it's what we'll do. We'll come back to this council in August and say the budget has been closed, the gap has been closed, and here's what we've done to do so. So we'll create savings throughout the year and we'll manage those critical cost drivers. Whether it's vacant positions or there's contracts that hadn't been finalized or entered into yet, we'll do those kinds of things to make sure that we begin to build a savings that equates to about $31 billion so that we're not talking about draconian drastic budget reductions that we've seen before. In addition to that, and while this is critical, we'll also continue to make sure we revisit how we're doing with our services or our goals. Council has strategic goals and we're going to continue to revisit those. We want to make sure our programs are prioritized, our services are prioritized correctly, and we'll also make sure that we're effective in delivering those services to our residents. Those things that aren't effective, that aren't efficient, they could be candidates for reductions. Capital plan, I'll spend just a second on this one. We want to make sure we do a better job of reporting on the capital. We haven't done a good job of that, but we owe it to this council and to the residents to do so. In addition to the five-year forecast for the operating side, we want to have a five-year forecast for the capital side. We'll take all the departments' needs and their issues and their critical area and develop a way to evaluate how we fund those critical areas using all the sources of fundings we have available to do so. We also want to improve the reporting on what we're currently doing. Last slide here, I'm trying to brush quickly. To the timeline again, we've given you the first quarter report and again, on average we're about balanced for most funds. We want to come back to you in May and give you a second quarter report and it says where we are, budget versus actual, how we anticipate finish the rest of the fiscal year, and also give you an updated and hopefully a lower budget gap for FY20-2012. Again, now as we stand here, it's 31 million. The recommendation, when we come back to you in May, hopefully that number will be lower. Maybe 20 million dollars or 10 million dollars based on some things we're able to do this fiscal year. Then we'll come back in August with the city manager's proposed budget and it'll be balanced. We would have created some savings, created some opportunities, made some reductions during this current fiscal year so that when we present the budget to you in August, it is a balanced budget. We'll have a retreat, obviously in August and the budget is scheduled to be adopted in September. There are obviously a lot more meetings that will take place here. I'm just going to give you a highlight on some of the critical reporting dates and then we'll come back in November with the fourth quarter report and tell you how we finish FY20-11 and move into FY20-13.