I'm recording this the Friday before Emberkons. Unfortunately, of course I couldn't come to Portland as I did at the past five years or so. First time I was speaking and first time I'm not actually there at the same time, which is unfortunate, but I guess this is kind of a special situation obviously. So I don't have proper recording equipment here, but I hope this is gonna be gonna be good and let's get started. So welcome to my to my bonus conf talk decorators in debt. I'm Marco, I'm from Germany, specifically Bavaria, where people sometimes look like this. I am the founder of Simplabs. We're a web engineering consultancy with digital products for companies around the world. And we also have teams to be more effective with Emberk deliver better quality in a shorter time maybe and just sort of to get the most out of Emberkons. And you might know us from our open source work.  We also sponsored the Ember project such with people writing for the Ember times. For example, we did a lot of work on the website with people on the learning team and so on. And we co-organize Emberfest, which is Europe's Ember conference obviously. And my notes here, I brought stickers. I didn't actually bring them, obviously. I think I sent 800 to Portland, which I don't know, maybe now in the Tildor office and maybe we can distribute them some other way. But here's how the sticker looks for this year and the dates for this year are gonna be October 15, 16. We don't actually say what the host city of the conference is.  I think it worked pretty well in the last years. And yeah, let's see whether somebody can guess this year's host city will of course reveal it soon. But I guess at the moment it's not even clear whether everybody will be able to travel anywhere in Europe in mid-October. Hopefully, yes, but we will hold off a bit until the situation smooths a bit more. So I have some opening story for the talk which doesn't really work anymore. I'm still gonna do it though because I couldn't really come up with anything better. So this is actually like I said in the beginning, it's the first time I speak at EmberCon. And the joke that I wanna make is that it's the first time that I'm speaking and I almost didn't make it to Portland. Now of course I actually didn't make it to Portland but let's sort of go through the story because besides Corona, there's actually another reason why I would almost not have made it to Portland if Corona hadn't happened at all. And that has to do with this thing, the electronic system for travel authorization, short ESTA, which is what all of the non-Americans or Europeans are sort of, I don't really know to who it applies, but everybody from Europe has to sort of go through this system sort of to register with their passport number and so on before they can go to the S, right? And then that gets approved and then you can go into the country without a visa. And in order to go through this, you have to answer all kinds of questions. One question is, have you ever violated any law related to processing using or distributing illegal drugs? Which I don't know, this might be the one where like many people would actually lie, I guess. There's also other questions. Like, do you seek to engage in or have you ever engaged in terrorist activities, espionage, sabotage or genocide, which I guess or hope most people can actually honestly didn't answer negatively, right? But there's also a new question since I think summer last year and that is have you traveled to or being present in Iran, Iraq, Libya, North Korea, Somalia, and so on after 2011, after March 2011? The problem is, here's a picture of me in North Korea in 2012.  And I should say this is not actually sort of me expressing my support for the regime. It's just something that you're sort of expected to do when you're there. So I answered that new question honestly and not surprisingly, my travel to the US was not authorized. So now I need to get a visa, which is actually a good thing because now I have a 10 year visa and I don't have to go through Esther anymore. And somebody told me I would have been able to sort of immigration take like a faster lane or so, but I might find that out next year. And getting the visa was really easy. The person at the embassy found it pretty convincing that I went to North Korea for a vacation. But yeah, having the visa doesn't help me now, of course. And of course, it's not really up to me sort of to judge US policy, but I'm not sure it's fair that I need a visa because only because I have been to North Korea once because here's me and my guide in North Korea, that's Mr. Kim. Obviously in North Korea, you cannot do anything without a guide, right? And the guide is not actually a guide, it's more like a person that's watching you, right? And they are being watched themselves, right? But the thing is I don't seem to be the only one maintaining relatively close relationships with North Koreans, right? So it seems a bit like there's different rules for different people here. Although I will admit that I did not fall in love with Mr. Kim over beautiful letters, but just over beers as people do. Yeah, it's like maybe a bit of double standards here. So anyway, I thought this might be a good opening story for the talk. Now, as I said, sort of it doesn't work anymore really because now I'm sitting here in Munich, but so having added that story to the talk, I thought like maybe there's a way sort of connecting the talk's main topic, which is obviously not North Korea, but JavaScript decorators, like connecting the two topics a bit, right? And having sort of a JavaScript decorator slash North Korea talk. And then I was thinking about how I could do that. And the first thought I had is just this statement, which sounds pretty nice, right? Decorators are the North Korea of JavaScript, but what does that even mean, right? It's basically just a budget statement that sounds very good, but it means nothing. So unfortunately, there will be no more North Korea content in this talk, just because I couldn't find a proper way to get it in. But back to the topic, and I wanna start with some theories. So the theory behind something like JavaScript decorators is attribute-oriented programming. And the idea behind attribute-oriented programming is that it is a program-level marking technique that allows you to mark elements in your program to indicate that they maintain specific, application-specific or domain-specific semantics without leaking all of the details of those semantics into your core logic, so to say, which then increases abstraction and reduces complexity, right? And many languages have had similar concepts for quite some time. For example, in Java, you have attributes like deprecated, which allows you to mark a specific thing in your code, like a class here as deprecated. Of course, you could also do more sophisticated stuff. So here's an example from Hibernate, which is a very popular object-relational mepper in Java. And here you see we use the entity attribute and the table attribute, ID attribute, and so on to sort of define how the mapping from instances of the employee class to a particular data-based table should work or other way around as well, of course. But the thing here is we're not leaking any of the details, like any of the sort of internal mechanisms of this mapping into the application core, right? We keep it relatively clean because we just sort of attribute the elements with the respective attributes without sort of revealing how those work internally. This concept doesn't only exist in Java, though. There's also a similar concept in .NET. So here, for example, we're using JSON property attributes to define how instances of a particular class, in this case, the API error class are serialized to JSON. And again, without leaking any of the details of the serialization process sort of into our application code. When we compare this to what we have in Octane, then it's obviously similar, right? So here we use the track decorator to mark the count property as track. So the template we ran was when it changes and we use the action decorator to make the increment and decrement methods work as actions. So again, without leaking any of the details of these decorators or the concepts behind them into our application code, right? We just say the count property should be tracked. We don't care about how that works internally or what tracking even means sort of. That's not a concern of our application, but that's a framework concern. So there's no point sort of leaking any of the details of the concept of tracking or the concept of making a method available as an action or work as an action into our application code. So we wanna hide all of that and we do hide all of it behind that decorator. So this is how JavaScript decorators fit in to sort of the general concept of attribute oriented programming. So you add attributes to the code to express additional semantics while hiding all of the details. But later we will see there's actually a fundamental difference between JavaScript decorators and attributes in other languages. We will look into that more detail later sort of on the surface, it's sort of the same thing and it's meant to serve the same purpose. The insights sort of are a bit different, but for now we can ignore that. So then you might ask, are decorators ready for use? And the answer is it's complicated, unfortunately. And again, I wanna share some background here. So as most of you know, or everybody presumably TC39 is the group that defines the ECMEL script standard and that's JavaScript. It's an international group of people with various backgrounds sort of that represent different interest groups like larger companies, browser makers and so on, but also sort of the viewpoint of the average JavaScript developer sort of which I think was one of the main motivations for you that cuts like obviously, as you know, one of the sort of inventors of Ember to join TC39 because I think that his motivation sort of was to make sure that the average JavaScript developer's viewpoint sort of was recognized in TC39 as well and not only the interests of larger companies or browser makers because sometimes those could be pretty different of course. So that group of international people discusses ideas for additions and changes to the spec or I guess in reality, it's really additions only because you cannot change anything in JavaScript and it's basically an additive spec because changing anything would break existing code and websites. So each new thing that they discuss goes through five stages. In stage zero, the thing is basically just an idea for a new language feature. So anybody could have that idea and then when you find a TC39 member to bring it to the group, then it would get discussed there, right? At that point, the idea would usually be pretty vague. There's no indication of whether it'll go forward at all or maybe like it's being discussed for five minutes and then immediately rejected for some reason or whatever, right? The next stage then is stage one where you have a written proposal with proper description, examples and so on, discussions of semantics and there's a TC39 member that champions the idea or the proposal. So stage one means that TC39 is willing to examine, discuss and contribute to the proposal but there are still major changes to be expected, right? At that point, it's still relatively vague and there's no indication of whether it'll make it into the spec eventually or if it makes it, whether that's gonna be a very different form maybe but if it's not rejected then the next stage would be stage two and at that stage, the proposal must have a formal syntax definition, description should be complete, there should be, or there need to be, I think, two experimental implementations. One will usually be bevel unless the feature cannot be transpired to current JavaScript sort of. I think that was the case with proxies because there's no way sort of to make the underlying mechanism of proxies work with current JavaScript. Obviously, experimental implementations can, of course, be in browsers as well behind feature flex or whatever. At stage two, a proposal can still be rejected. It's relatively far in the process but there's still no guarantee it'll make it. The next stage then is stage three at which point the spec text needs to be complete there need to be two fully compliant implementations. Again, one of them would usually be bevel and at this point, the proposal can be expected to be added to the spec and changes should only be made when critical issues occur and that's why stage three is sort of the important stage because at stage three, you can expect the thing to be added to the spec eventually in only slightly modified form. So stage three proposals are pretty okay to use in general. Why everything before or below stage three is not really okay to be used because there's no guarantee it will actually make it to the spec and there's no guarantee that if it makes it to the spec it will be in the form that, in its current form sort of, right? So yeah, stage three is the one that you wanna keep in mind because that's sort of when you're building on relatively solid ground sort of if you're using something in stage three. The next stage is then stage four which is basically just like a stage that something goes into while it's sort of waiting to be added but it's already decided that it will be added, right? So of course, now the question is where are we with JavaScript decorators? And first problem is there's not one but actually two proposals. Second problem is one is in stage one and the other is in stage two and obviously that means that none of them is final or complete, right? The stage one proposal is basically deprecated sort of that's not going to be continued and the stage one, the stage two proposal is in stage two which means it's not done, right? It might still change relatively significantly. So let's look at some more details of those two proposals. First of all, the stage one proposal which basically defines decorators as simple functions, right? You would just write function that receives the element that you're decorating and then you can modify the element which is very simple, right? But it has major implications with respect to performance because you're actually modifying the class or the method or the property or whatever. So you're changing the shape of things sort of which is always very bad for browser engines to optimize, right? So there are major performance implications. There are also major tooling implications because you cannot actually statically and you cannot actually statically analyze those decorators, right? If a class is decorated with a stage one decorator you cannot really know what that decorator does. So you might not know for sure which methods that class has, right? Or whether the methods are actually as you see them in the class body or whether the decorator does modify them and then like the actual methods on instances or on the prototype will actually be different from what you're seeing, right? So that's of course a major problem. It's well in particular for tooling, right? So the stage two proposal solves the performance and tooling problems by basically defining decorators as first-class language elements and sort of limiting them much more but it's not ready yet. They're major changes to be expected. So it's not even really clear how exactly that's going to look, right? So coming back to my previous slide here in reality, decorators are not the North Korea or JavaScript but sort of the anti-North Korea of JavaScript because nothing is regulated and everybody can do what they want basically because there is no official regulation or specification. So the question is what do we do? The old thing is deprecated and the new thing is not ready but in EMBA we need something that works well with native classes because the old macro methods that we've been using for computer properties, for example and so on, they don't really work well with native classes. You have a bunch of options using them with native classes. So it's not impossible to use them. I think there might be some edge case whether actually behave differently but it's not impossible to use them. It's just not nice at all. So for example, if you had a person class with a first name and last name, and by the way, all those examples are, I think, taken from the IFC that I think Melanie Sumner wrote, I'm not 100% sure but the examples have her name obviously so let's just assume she wrote it. So if you have a person class here with a first name and last name and you wanna define the typical full name computer property, right? Like full name must be sort of the hello world of computer properties, I guess. Then with a native class, you could define the class first and then on the prototype, define the computer property, which is obviously not what you actually wanna do in your application. The alternative is you sort of mix like new native classes and the old M object model and you define the class as an extension of sort of an anonymous class here that where you use the old way sort of extending from M object, this works but it's obviously also not really nice, right? The best solution is obviously with decorators, right? Where you just define a proper native class with two fields and one getter and you just decorate the getter with the computed decorator here, right? So the question is how do we get that when the decorator's proposal is not ready really? And the answer is we just stick with the stage one proposal for now. This is what the TC of 39 Champion Group recommends because although the specification is not ready, decorators are already widely used in the JavaScript community and Ember is actually relatively late to the party here. So projects like Angular also have used decorators for years now. So there's a lot of pressure and also there's commitment I think from TC 39 to make the final decorator proposal so that it will allow to do the, to make the final decorator proposal so that it will allow for doing the same things with decorators that you can also do with stage one decorators. So that means you will very likely not have to change your usages of decorators, right? The decorators will only have to change internally to solve the performance and tooling problems but that also means that you do not want to write your own decorators here because why sort of, why usages of decorators will not have to change the internals of decorators will change a lot potentially. So when writing decorators, you are building on pretty unstable ground, right? If you only use the decorators that Ember provides, then obviously Ember sort of shields you from all of the internal changes that might or will probably have to be made at some point, the computer property, the computer decorator and the track decorator will continue to work the same way that would just be implemented in a very different way internally. One thing though is that in app code, you would usually, but there's usually not such good use cases for decorators anyway, because as we saw in the beginning, the purpose of a decorator is sort of making something available while hiding all of the details of that, right? Which is usually not something that you wanna do in an application, right? Because in an application, you don't wanna sort of hide parts of the code from the engineer because all of your application code as a whole sort of is being maintained by your project team and so on. So you don't wanna introduce black boxes, right? It is however, of course, something that has a lot of value for frameworks like Ember or maybe even for add-ons.  So let's look at the stage one proposal in more detail. We will basically ignore the stage two proposal for now because it's unclear how it's going to work eventually. So we will focus on the stage one proposal. And like I said, the stage one proposal defines decorators as simple functions that modify the element that they're decorating. And that is also coming back to a previous point. That is that main difference between JavaScript decorators and attributes in Java or .NET because while attributes in Java and .NET only add metadata sort of to the elements that they're attributing, JavaScript decorators actually modify these elements, right? So with a JavaScript decorator, you could actually modify a class, for example, where an attribute in .NET will only add metadata to that class so that at runtime, you could reflect over that metadata and sort of do certain things then, right? So that might of course be different in the stage two proposal, but for now that's really the main difference that a JavaScript decorator will actually modify the thing that it is decorating. And doing that though is relatively simple. There's basically two cases. That's the case where you are decorating a class. And in that case, the decorator is a simple function that receives the class constructor as its argument. You could also of course decorate a class member in which case the arguments for that are the prototype, the name of the member and property descriptor for the property you are decorating. And I wanna show you some concrete examples to make that a bit clearer. I have created a little example app so you can find all of the code on Gitter. And let's look at the first one. So here we have a simple mbar route, right? We just load some data from an API endpoint. We don't care about the details, of course. And now let's assume we wanna benchmark that, right? We wanna like have something in place that allows us to benchmark the execution time and maybe report it somewhere or whatever. But of course we don't wanna sort of have all of the benchmarking code as such in the route, right? We wanna hide that because it's not relevant to the application really, right? Let's say we wanna like make a benchmarking add-on or whatever. So a good way to do that of course is to use a decorator as we're doing here, right? We're just importing that as any other thing sort of in JavaScript and then we're decorating the model method. And as I said, before the decorator using the stage one proposal, the decorator is just a simple function that takes the prototype, the property name and the property descriptor for the property we're decorating as arguments. And what we're doing here is we're simply remembering the original value of the property descriptor, which is the original implementation of that method. And then we replace it with a wrapper, right? And here what we're doing is we stop the time when we start execution, then we call the original method. We stop the time when that ends and we lock that to the console. In reality, you might be logging into some sort of API or whatever, and then we return the result that we got from the original method, right? So we do not change the original method. We also don't change the signature of the method because the method that we are replacing the original method has the same signature, right? We're just adding our stuff sort of before and after the original method. And that also means, of course, that the original model method doesn't even have to know that it is being benchmarked or that it is wrapped with something else, which is the point of the decorator, of course. Another example is this one here. So let's assume, besides benchmarking the model method, we also wanna require users to be logged in to have access to that route at all. And by the way, this is a sneak preview sort of of what a version of MSimploth, which we had simplified to maintain, without Mixins can't look like, right? You can use Mixins with native classes like relatively easily in Ember, but it's not really great, right? So in the current version of MSimploth, you would just mix in the authenticated route Mixin into this route that you're defining here. But with a decorator, it's even a bit nicer and sort of has more modern look as well. So what we do here is we just import the authenticated decorator and apply it to the route class. And again, the decorator is a simple function that takes the class constructor as an argument. And we do a similar thing here to what we did before. We remember sort of the original implementation of the classes before model method. And then we replace it with our own method. And what we do in that method is we get a session or the session service. We check whether the user is logged in. If it's not the case, we just transition them somewhere else. In this case here to index probably make more sense to transition them to the login route. And if they are logged in and there's an original implementation of before model, we just call that, right? So again, we are adding sort of relatively complex logic with a very simple mechanism. And we are hiding all of the details. We don't change the original before model method. So I think this is a very nice example for how decorators are actually a pretty good way of making functionality in add-ons available for EMBA applications. Obviously those examples are sort of made up. They don't really have any sort of real value. It's just for illustration purposes here. So I also want to look at two examples from EMBA itself. And if we look at this piece of code here from previously, again with component that has a track property called count and then two methods that we decorate with the action decorator. So we can actually call them as actions from the template. So how does this work? And first of all, let's look at the tracked decorator. And this is not really the code from the Glimmer code base. It's sort of the essence of the code, right? But here you see that we have a function here that takes the prototype, the property name and the property descriptor as arguments, right? Because it's a stage one decorator applied to a class member. And what it does is a very similar thing to what we saw before. It replaces the original property with in this case here a getter and a setter. We can ignore the getter, that's not so interesting. But the thing of course about track properties is that whenever a tracked property is modified then the template re-renders, right? And you see how that works here in the setter where whenever the property is set the property to change callback will be called which is sort of an internal callback in Glimmer which sort of triggers a re-render, right? So that is basically how the tracked decorator in inside of Glimmer works. It just replaces your original property with sort of a wrapper property that will make sure that whenever the property is set and internal callbacks sort of in Glimmer is called which will then trigger a re-render. Next, let's look at action. And as you all know, the main thing about actions is that they are closures that are already sort of pre-bound to the correct context, right? So you can just call them as a function and they will be running with the correct disbinding, sort of, right?  But sort of one of the main things that the action decorator does is it just, it binds the method you're decorating and assigns it to a hash of actions, right? And that allows you then to use like the method as an action from the template. So this is decorators in Ember. They are a great way for abstracting logic that is non-essential to your application but that is maybe only essential for the framework or only essential for some other system sort of you're using. But there's no stable spec which means you don't want to write your own unless you have lots of time and lots of willingness sort of to potentially rewrite lots of the internals of the decorators you're writing. And that's all that I have. Thanks. Unfortunately, I can't take questions. Unfortunately, I can also not talk to people sort of after the talk or in breaks or whatever but we'll repeat all of that I guess next year in Portland or at Ember Fest in Europe this year. Thank you, bye-bye.


Do you like Game of Thrones? I do. I also like Yerma Girls, Castle, Veronica Mars, Web Therapy, Buffy the Vampire Slayer, Harry Potter, Miss Marple and The Secret of Monkey Island a lot. All of which, in my opinion, really are great fictional stories. So what is this course all about? Many of you asked before. Storytelling of course. But what is storytelling? Easy, you might think. It's all about telling a story. But what does that actually mean? How would you define it? What is it that immediately comes to your mind when you think of a story? We ask every single one of our guest lecturers how she or he would define a story. But here is a quick peek into what they said. So to answer what is storytelling, I think we need to think like what is a story? So if you think of a story as being basically a synchroence or pieces of information that we as humans try to find some relevance between, we're looking for these connections.  So a storyteller would take pieces of information and then control the delivery of that.  Storytelling uses a language, a language not me being la-la-la-la-la-la, but it can be a film as a language, an expression like dancing, or you could also have poetry as a form of storytelling music, like rap music or any type of music. There are very, very many ways to even define what story is. It can be a moment, it can be the whole story of the universe. It can be a very fragmented approach, episodic, it can be one plotline. As you see, while I'm telling all these definitions, I think there shouldn't be a definition of story. Every writer should define that, him or herself. Of course it sometimes depends on the medium. Is it dramatic storytelling? Is it storytelling in a novel? Is it for a young child? So the audience sometimes defines what storytelling is, but that's how far I would go. I think the best types of storytellers understand what's going on inside the audience's head, like what pieces they're trying to connect and what work they're doing, so that everything is not just laid out as an easy kind of explanation, but they leave these strategic gaps so that we are almost obliged, so we find ourselves diving deeper into this story to find those connections and understand the relevance where it is, even if sometimes there isn't any relevance, we are looking for it. The only definition everybody seems to be able to agree on is that storytelling consists of both the telling and the story part, the ideas that are shared, narrated and presented by the storyteller. This course will be about both the structures, elements and concepts necessary to create a story and also the people, the tools and the channels that eventually tell these stories. The story and on the other side the telling, that's about both. Only if we explore and understand the functionalities, so to say the MO, the mode of operation, the work of both sides of storytelling, that are tightly interwoven, we will be able to analyze their relations and dependencies and possible changes in storytelling in general over the years. To be able to research tools, structures and content alike, my team and I have invited a whole network of professional creators, executives and scientists to share their experience in storytelling with us and therefore with you. Some of whom you've just seen already, Konjeja Funke, Robert Platten and also Maria Graustrenze. In the following weeks, we'll have a look at how they define and deal with storytelling themselves and what good storytelling means to them. This course is called the Future Storytelling. Obviously, apart from any time-travelling participants, nobody knows what the future will hold. However, we can very well analyze, understand and contextualize stories and the media up till today to see where we have already been and might be heading, which is why we start our next unit with a quick look into the past.


Okay, I'm going to level with you. I did not want to make this section. I didn't want to make this section because it's a bit more advanced than what this course was really meant to cover. But inevitably somebody out there is going to say, hey, how do I connect C++ to QML? Can you explain that? And then we have a very long, exhaustive conversation. So I thought I would just add this section, which is going to go over the high level of how C++ and QML can integrate. So some disclaimers. QML lives on top of C++ and Qt. You can expose C++ classes to QML and vice versa. However, C++ is an advanced topic and we will not be covering it in this course. It's actually a prerequisite for this course to already know C++ and Qt Core. So if you're one of those folks going, I don't know C++, but I want to connect QML and C++ together, I would highly advise you to stop, go learn C++ and Qt Core and come back. Alright, C++ and QML communicate via signals and slots. If you already know Qt and Qt Core, you know exactly what that means. But yes, it means that all the goodness you've learned in Qt Core, you can actually use in QML. Everything under the hood is a signal and slot. There's no extra technology you have to learn. It's actually building upon what Qt is already built on. It's actually really cool. So we're going to open the main CPP file and we're going to explain what's going on. I've already dumped a lot of comments in here and I'm just going to walk you through it. So here are the includes and it's pretty standard for any application. But we have the QGui application, the QQML application. Notice the double Qs. That kind of drives me a little bonkers. But the QQML application engine, this is what actually loads all the QML scenes. So again, disclaimer, C++ advanced topic, QML lives on top of C++. This is the main entry point of the application. Notice I said the application. This is actually a C++ application loading a QML file. So in effect, you are making a C++ app. You just have a nice QML GUI. All right, the Qt Core application, we're going to set the attributes and we're going to basically say enable high DPI scaling. High DPI scaling is for devices, for example, cell phones, Chromebooks, things of that nature where you have high DPI visual displays. The application class, the QGui application, this is your actual app. And you can see down here, this is the event loop. So basically, we create the app, we do some configuration, and then we go into an event loop, meaning the application just runs and runs. So let me demonstrate that. So as soon as you see this window, bang, everything's loaded and now we're in the app loop. We're just waiting for the user to close the app and then it would come right here. So everything in between, we call this configuration, but actually for QML, this is the heart of your application. The QQML application engine, this is the actual engine that loads the script up and makes everything function. It loads it up using a, you guessed it, QStringLiteral, QResourceContent, main QML, meaning it basically just loads a string, this guy, out of the resource file into the engine and then runs it as QML. So in effect, it acts almost like a virtual hypervisor, if you will, or a sandbox loading the QML on top of Qt. Then we're just connecting some signals and slots and we're basically saying, hey, make sure that the object and the URL equals the object URL. A little bit confusing, but basically what they're doing here is they're saying make sure the engine loaded this correctly and if it didn't, then hey, exit with status negative one, meaning something bad happened. Very, very into this, we're going to say engine, go ahead and load the URL. If there's a problem loading that, you guessed it, signals and slots are going to kick in, it's going to say QQOR application exit negative one. So if you ever go to run and app and it goes like that and then immediately just disappears, check your app output, make sure nothing blew up and check the app exit status. If it's negative one, you know you've got some sort of problem. What's up, everybody? This is Brian. I hope you enjoyed this video. It's part of a larger series out on udemy.com called QML for Beginners. The QML for Beginners course assumes you know absolutely zero QML. You're just starting off and it's designed specifically for Q5. I will rerecord the entire series when Qt6 comes out and just know that it's over 100 videos and 13 and a half hours of video on demand. I'll put a link below so you can get a highly discounted rate and before you dive in, just understand it covers a lot more than what I can put into this list. Everything from what's QML to animations to C++, integration, JavaScript and on and on and on. But one of the requirements up front is you have to know QQOR. You should have some C++ under your belt and be very familiar with Q5. In case you have none of that, I do have some courses for QQOR Beginners, intermediate and advanced out on udemy as well. Hope to see you there.


What if you could recharge your electric car in under 10 minutes? About the time it takes to stop at gas station. The overall goal of this research is to develop methods that allow us to accelerate battery testing but without degrading it a large amount. When batteries are charged at a very fast rate, it puts greatest strain on the battery which causes a degradation on their overall life. The main bottleneck with advances in electric vehicle batteries is testing times. Starting from the laboratory to an actual deployment in an EV can take years. The method we've developed is a machine learning technique to reduce testing times by about 98%. So typically it takes about a couple of months to finish an experiment in this case and we were able to reduce that time down to four days. We've done this, I think, through a variety of different approaches. One is to accelerate the test itself and then the other is to accelerate the entire process of generating those tests and determining what tests to run. So instead of testing hundreds or possibly millions of combinations, we test just a few and use a machine learning algorithm to determine what the outcomes would be on all the others. The method is very general and it can be applied to many other cases that involve time-consuming experiments. So there are basically two components to the research. The researchers wrote a program that based only on a few cycles of charging would figure out what's the lifetime of a battery and the other component of the research was an algorithm which figures out which charging protocols to test and when. So this is an exciting academic and industrial collaboration between Stanford, MIT and the Toyota Research Institute. The Stanford groups were focused first on experiments, providing the data. At TRI they've helped with the design of the data collection pipeline and the cloud infrastructure. The group at MIT was mostly involved in making early predictions. The current work improves the efficiency of the optimization. The exact details depend on the optimization problem. But broadly speaking, we are reducing the number of experiments to the bare minimum needed to reach a conclusion. The specific goal of this research was to optimize fast charging. Can we charge a battery in 10 minutes and what's the best way to do that? The data that is being processed for these machine learning algorithms is being packaged into cycles. We take each time we charge and discharge the battery as a distinct unit and we both clean and standardize that data. There are substantial variations in performance from one battery to the next, which makes it difficult to apply traditional optimization methods. However, there are machine learning algorithms that are specifically designed to address problems of this nature. It also helped us identify novel charging protocols which we did not know existed that could help us charge a battery much faster. Using a data pipeline is the best practice for data at scale, especially as scientific experiments start generating more and more data. The volume increases. This becomes a much more important practice. I think one of the reasons this was not done before is that it really required a lot of interdisciplinary collaboration between and the expertise both in the machine learning world and what kind of algorithms we should use for this particular application. And a lot of expertise in terms of like battery technology. This provides a better way to do science and experiments in the future as science becomes much more data intensive. This provides the ability to utilize that data in an optimal manner. How come we use AI and machine learning optimal experimental design, the kind of technologies that we've just talked about, not only to optimize for something but actually help us come up with a better understanding of the physical processes. The next steps for this project are to apply this method to much more challenging problems, problems in manufacturing of batteries and problems in real world use cases like when do you charge your battery or how long do you keep it charged. We learned a lot through this process, both about the application of these algorithms and also that the algorithm found that delivering the highest current in the middle of the charge actually results in batteries with the longest lifetime.


Hello everybody Nervous little back here with another video This isn't Okay, so like I'm gonna keep saying that these aren't speed paints just because they're not my normal You know kind of style of a speed paint But they are technically speed paints so This is just a redraw So okay, so for this version The fairy that you see right there was actually a redraw of another drawing which I'll put like right here right here Okay, you see that good, right? but So that that was a redraw of itself But because it was so booty I decided to do it again Because I feel like I have sort of the skill level to do it again, but I Mean that was really good for when I first started and I don't know I I really liked it at the time and now that I don't I It's like oh well, I guess I didn't like it, but I mean When I was younger, I didn't really and I don't think I really ever have As as Different as this is usually with the art community. I don't think I've ever severely Judged my work When I and when I was younger, I kind of took Solace is that the word that I'm looking for I kind of took solace in the fact that I thought that I was a good drawer and I think that's kind of what pushed me to continue drawing and so I Know a lot of artists that do generally put themselves down with their art and stuff and I sometimes don't think that's a good idea like I know friends that'll I know friends that'll sit there and like I hate this like in the middle of their drawings over and over and over again and okay I'm kind of a hypocrite with this because I do do that sometimes too because there are times when I genuinely hate what I'm drawing but I know for some people they they struggle with Continuing to find motivation for drawing and then they tell themselves that they're a crap artist And then they kind of put them down and then they don't want to draw anymore. That's not the case for everybody I do know a lot of people that they They will Take comfort in the fact that they know that they're not good and that there's still room for improvement Like I knew a lot of those last year and a lot of those this year. I mean in terms of school Where they would they would insult themselves and that's what made them want to draw but then I noticed that there's a problem with people who who Are constantly insulting their art and can't ever see the good in their art and kind of lose the motivation to draw And I think that might be part of it is that They find that their art is so crappy like even okay this here's where I'm going with this though Is that if you genuinely think that your art is crappy? I Understand because that's kind of hard to not believe about yourself like if you genuinely don't like your art Then that couldn't be a problem that makes you not want to draw so my recommendation my unwanted advice is basically You look at your drawing right and you think it's absolute crap case So you look at it and you got to be like this is this is the stuff like even if you don't believe it You just got to tell yourself you got to be like yep. This is good and if that's not the case then just Look at your art and say it's okay. There's still room for improvement and I can I can still improve because I think a lot of Beginning artists will look at their art there There are that isn't as good compared to their favorite artists and they give up because they're like, okay Well, I'm bad at art. I don't think I can Continue to do this because it's not easy. I'm not good and that's part. I think that's part of being an artist is kind of Continuing and for some reason their way for some reason for some people their ways of continuing is different than others Some people will find that it's good to insult themselves Because they genuinely think that their art is bad and so they they tell themselves that and then they're like, okay But I can still get better and I think that's a good mindset to have if you're if you're gonna Constantly critique your and this isn't to say this isn't to say that you should never think your art is bad You should never like try to fix your art or critique your art I do think that's very important is to notice what's wrong with your art and improve upon that But to constantly tell yourself well my art is crap. I'm such a crappy artist. I don't do well. I'm bad at shading I'm bad at line arting or whatever. I think for maybe some people. That's not always the best So, yeah, that's my Unwanted opinion that literally nobody asked for but I decided to put out anyway, so I hope you guys Enjoyed that little commentary I Just with this with this drawing. I actually did lining not lighting a lighting not Lighting not lining ha ha Wow, I'm a terrible person. Look at me being a hypocrite again But anyways point is I decided to do lighting and I hope this came out Okay, because I decided to use like really light blue in comparison with the other colors And I'm not really sure if I blended those correctly and kind of hoping I did But the other one didn't really have any she wasn't her colors weren't really interacting with her environment at all And I don't usually have interacting environments So this time I decided to sort of challenge myself and like actually do something like that so I Hope that turned out okay, and I'm nearing the end of the drawing. So like I referenced the old picture a lot In terms of color and stuff, but I think I darkened this one a lot just to make it look a little bit better I don't know what the bad things are but okay So this is the old drawing right here the one that is like yucky in from 2013 and this is the new one nice and Sort of pretty colored that's always grand.


So, today I'm going to talk about reporting MySQL bugs and maybe you are wondering why. I work for MariaDB Corporation and it's actually a technical enough conference so I would expect that of all the talks that I've suggested here, people would pick up something else like something about InnoDB, something about MariaDB or something about using GDB to study hashes, user variables or whatever. But they picked up or might talk about bugs and I think that's because people care to get contribution to MySQL and at the very beginning of this conference my colleague from Foundation told you that it's actually not easy to start contributing to the code but it's really easy to start contributing by reporting bugs and problems you have with MySQL. So, maybe that's the encouragement to divide the audience. If somebody wonders why me is talking about bugs, there are historical reasons for that. I worked at the bug verification team back in MySQL and was involved in bugs processing from both sides before the bug is accepted as real. So, the member of that group and then later at defining priorities for bug fixes. I stopped doing it at MariaDB but I'm still interested in this stuff so I have a blog that is called MySQL entomologist. I have MySQL bugs as my nickname on Twitter and everything so I'm watching bugs. Right now I'm interested as a community member in finding new stuff that was found not working well and at the same time historically I also try to care about the way bugs are processed, about the proper procedures that were once set up and I think partially they made MySQL popular. The fact that there is a public bug database and it's processed consistently. It's not like you put thing there and it's forgotten for four decades. No. And I would like to make sure it's still the case. So, it's not the first time I'm trying to represent this topic. It's the first time when I have more than 5 or 10 listeners about it and in such a huge audience and in 20 minutes. So, it's a bit hard but the agenda is quite typical. Nothing new here. I will just add a couple of words about reporting to MariaDB as well so that those people who work with MariaDB or who believe that MariaDB can do something useful to common code or for MySQL in general, still can get involved. So, my main message is simple by the way. Report bugs in public. You have these great public bugs database available for more than 15 years. So, it's a collection of interesting stuff. Some bugs are fixed. Some not. Some include walk arounds and comments explaining how people think when they solve MySQL problem. So, I say report bugs in public and I say this also specifically and not only to community users. I tell these to customers as well. To Oracle support customers, to MariaDB support customers. The fact that you can report your problem that may be a bug or not to your organization that you paid money for and they can deal with it privately with you is not a replacement. It's an option. It's a good option to have and you may get a solution but it's not a replacement to reporting a real bug in public. For two reasons. First of all, public bugs database is searchable. So, you contribute to community. We are all feeling out public founded and public, it's like writing at Wikipedia explaining stuff there. We are building a knowledge base and the fact that it's publicly available also help in a way that if your support provider fails for whatever reason, do not want to fix the problem or do not reply fast. By making your bug report public, you attract attention to other support providers, to other engineers, to community members who can solve your problem faster than your support organization. That would be not your problem. That would be your great result. It would be a problem maybe if your support organization, if they are not fast. But you should do it. Here are the links to public bug trackers to MySQL forks I care about specifically MySQL itself and a bit different software used by both Percona and MariaDB. We work on bugs in JIRA but these are still public bug trackers and I encourage you to use them. These slides are already available. Whenever you see on my slides anything underlined, it's a link so you can click and I care specifically for the link to work at the moment of writing. So, the talk was titled how to create useful bug report. I say report whatever problem you have. That's what people do. But if you just complain, something does not work for me. Or if you do not try to create your bug report as useful one, chances are high that it will hang around and be forgotten and you will not get any useful feedback. Neither from Oracle, for example, nor from other community members. So, what's a useful bug report? Historically, I highlighted many, many features of what should be a useful bug report. But for the purpose of this talk, I highlighted one. So, you should clearly state what your problem is. Not that MySQL hangs clearly in a way that it can be understood what the real problem. Not that you are badly affected. Not that it does not work. But you should try to explain what you did, what you expected and why and what you got. And then, in a useful bug report, surely you can provide a lot of additional information. You can do your own research and it's appreciated. But it's not mandatory. If you already can explain what your problem is, why you expected something and got something different, it's a good start. Then, the best you can do is just cooperate with those people who will try to ask you additional questions. So, it's already useful. Also, do not omit necessarily important details. Like, for example, I see a huge problem right now that, for example, Oracle does not mark real regression bugs. It means something worked before, but stopped working, worked in some older version, but does not work like before. These regressions are like not highlighted. Even though in bugs database there is a quite popular tag for this and it's called regression. So, do not omit this important detail like something worked for me in older version, but does not work in current one. This is important. If you tested more than one version, put it and got different results. Put it in your bug report. So, these are important details. That's like a message for you. What else? I told you it's a public bug database. It's searchable. So, what's really annoying for people who work on bugs is to get the same reports again and again and again. I don't know. Workbench crashed on specific VGA card or whenever I have a table without primary keys, row-based replication is slow. There are probably 100 reports like that. Row-based replication is slow. It starts like that. And very soon we can find out that there were missing primary or unique keys and recently there are some features to overcome this problem. But that's it. Whenever you have a problem, before you report, try to search at the bugs database. Try to use Google specifically put it onto bugs database. Try to use whatever search means you have. Another important thing, so duplicates is something nobody likes. Another important thing is surely to read specific instructions because depending on what kind of MySQL software and where you report, you may get some additional suggestions or guesses or best thing to have. In case, for example, of MySQL workbench, you should put some details about hardware that it helps you to generate in a special report. So do not omit that stuff because it's key of a key importance. And again, one old historical message from me on bugs is that every who report bugs would read a recruitment, how to smart questions at least once and try to follow the general guidelines of how to discuss problems, how to try to get help from geeks, from open source developers. It truly applies to MySQL as well.  Just put it side bugs MySQL.com and whatever keywords you have. If you have a crash, you will get a stack trace in the airlock. Try to put some interesting unusual items from there. Not the entire stack trace. It would not help, but some function names. For example, closeFRM. Search for bugs and closeFRM. For example, MariaDB, if you prefer, you may go to another site and you will find quite specific heats about known problems. Please also do not ignore search tools. People don't like them searching in MySQL bugs database that is implemented in form. Bugs are split into categories. You can search for fields like SAIN name. You can put version here and you can get results faster than you do via Google. You will get hundreds of pages of bugs to review. While we are bug system specific search, you may get way less results. And I always say, if you use Google, please check carefully at least three, five pages or 30, 50 first heats. You probably know if it's some new feature, there is no point to look for a bug that is five years old. But otherwise, do not look only for three, five first roads. So what's also great? It's great to see what your problem is. Ideally, your bug report should get enough details for anyone in the clean environment. They are not on your hardware to reproduce exactly the same problem using the steps provided. So clean environment matters here, because if some crash happens only in production five months after the restart and not before, it's great to see, it's good to see a stack trace and whatever, but it's not yet a repeatable bug. The bug is that it's not repeatable is something that nobody will ever know is it fixed or not. It stopped happening, but we don't know how it happened. We never reproduced it. We do not have test case for it. So the fact that some work around happened, it's no longer happening or some company stated it's fixed because of some additional new feature or some other development or covered by some unknown bug and should work now. It's not something you can rely on. So I have listed some tools that first few like DB Deployer that was already presented or Sandbox helps you to create those environment specifically for trying to reproduce your bug before reporting or in the process. So the fact that something happens in production and doesn't happen in clean environment is an important fact to include in your bug report and that's what I would like you to do. The more you know your operating system, the better you as a developer, the more tools you can and will use to prove your point. So in the bug report, you should prove your point that there is a problem, not stated. So in some cases for crashes, I told already that we need core dumps, we need backtraces from core dumps. You cannot put the entire core dump into the bug. It might be gigabytes in size, but you can put backtraces. So some useful tools, the more you know them, the better. Now you should understand, you reported the bug and it doesn't get fixed fast. You should understand what state it is in and why. So it's a brief slide explaining basic most important states for my SQL bug. So it starts as open, then ideally somebody assigns it for analysis, then eventually if it's found to be a real bug and a person assigned knows how to reproduce it, it end up as verified. And at this moment in case of Oracle MySQL bug, it goes out of your DARS, community knows nothing what happens in between this verified state and eventually closed bug, closed state that you can see in release notes or whatever else. Because in case of Oracle, the real work on bugs happens in private database. And we know nothing about it. On the other hand, you still can see some public states that are important for you as a bug reporter. If the bug is verified, you know it's accepted as real. If the bug was already reported, you would see it as a duplicate. If there is some question to you, you will get need feedback status. And the bug that got no reply for 30 days and need feedback status automatically becomes no feedback. And these are true for gotten bugs until somebody will add some comment to complain. That's it. So these are all highlighted final states. You should probably not insist more after the bug ended up in some final state. So the decision is made. If you have new argument, add them. But these are final decisions about the bugs. So this more or less applied to MariaDB and to Percona as well, who use Jira in Jira. Depending on project, you may have different statuses. And actually, status is quite specific there. So all they are highlighted. So the bug is formally starts as open. Then it's usually formally confirmed. Then it's in progress. Then after the code is created, it's in review. If somebody stopped working and there is no progress, it will be stalled. And then it will be closed. What's interesting in Jira, the bug can be closed for different reasons, because it's a duplicate or because it's fixed. So a typical user of MyScaleBug database, if he opens Jira, or maybe a bit confused about bug statuses. But you should use a combination of bug statuses, so-called resolution field, and also depending on the project, there could be some labels, tags, and whatever. For example, explaining that we need feedback. It's a special tag, in case of MariaDB. It's strange, but it's real. On the other hand, you can click on tags and find all similar bugs. So it's also interesting. Given the time, I usually try to show examples of useful and useless bug reports. So there is an old collection, but gold is blind. I've recently liked three new. I just encourage you to click on each and every bug report. It will be opened. My comments, you know, what's good in case of hanks and crashes is good to get backtraces. In case of regressions like happened here, it's good to highlight this fact, and do not hesitate to report bug again if it's reappeared. And provide steps. Do not think that really what you need for a good bug report is MTR test case or docker image with all the commands that can be executed with building, adding data, starting virtual machine, starting replications and everything. It should be enough, and this example shows, to show the real point of the bug. So do not accept it as like a formal demands and if something is missing, it's no way. As for useless, I actually had a huge list of useless bug reports. Some of them ended up with a lot of fun. And with year after year, I understand that there are really very few useless bug reports. Because even if you do not state your problem quite well, eventually in comments, you can see a good example of studying the problem. You know what? It's called free support, and you may get free support. You are not entitled to it, but you may get free support in bug database. You should not abuse it, but you may get it. So there are really very few useless bug reports. I would like to add one statement about not useless, but a bit dangerous bug report based on discussion we had just today. So please take extra care to the information you put into the public bugs database. Do not put your IP addresses, user names, passwords, all stuff that belongs to you, and even more for example to your customers. In case of Oracle bugs database, there is an easy-to-use option to hide comments private. The bug may be marked as security, and almost any engineer can do it. In case of JIRA, it's way more complicated to hide some information as soon as it was publicly available, because of all the version controls and all change carefully tracked. So be careful not only with adding correct precise and needed information, but with information that may be confidential and not strictly needed to understand what the bug is. The last probably slide for today is the following. Okay, you reported great bug. It's repeatable, but it's not fixed, or even not processed. It still stays open. What you can do? First of all, if you got any request for feedback in the process and you are not replying, you are the problem. So please cooperate. If people ask maybe even repeatedly, please cooperate when it's reasonable. If you cannot, if you do not understand the requirements, if you are not happy with them, add your comments. Do not sit silently and pretend that some magic should happen to your bug report. No. If it's real bug, try to involve other people, colleagues, the more comments from different people you get, they may help to understand. They can create a test case for you and it adds value to your bug report. Do not open new and new bugs with the same titles. Try not to, you know, curse and everything. If nothing helps, if you know somebody and you already met a lot of developers here, or MySQL people, Oracle people, MariaDB people, try to talk to people in private and get some internal escalation. If it does not work, that's probably nobody in Oracle is happy about what I'm saying right now. Discuss bugs in public. If you have your blog, blog about it. Unfortunately, we do not have Jean-François Ghani here, but he is quite efficient with doing it in a polite way, in a useful way, but he's blogging about some replication bugs and they got fixed. If you have a support contract, surely open an issue. Surely. If you do not get free support, use your resource. And if nothing works, you know, just tell me. That's why I have my blog posts and everything. Sometimes magic happens. I will not tell you how it happens, but it happens. If you need to know other people whom you can ask, whom you should care about when you see their comments, please, in case of Oracle, it's almost shastry. He processes, preprocesses like 50% of all bugs reported and he participates, participates in important role in setting priorities for bug fixes as well. So follow his comments. In case of MariaDB, there is one person, Elena Stepanova, who used to be a single person QA. Now there are many more people involved, but she makes real decisions about bugs. You've seen Sergei Golubchik, surely he makes decisions about bugs. You've seen a lot of people with a number of commits. So these are developers who make things happen. So if you get in touch with them, please do. In case of Prokona, we have Sveta Smirnova here, who somehow involved in setting priorities. We have Lovrinas in a role similar to Sergei Golubchik and we have Royal, who is again a king of QA and he cares a lot. So if you would like to discuss specific bugs, we can still do it outside. Thank you very much. I hope I'm not that much out of my time. What you should do once again, please report bugs in public. When you see a bug, like my wife did, make some document recording of what it is about and report it. Praying Mantis is a huge, nice bug and it would be really great to see it here. So you do not make MySQL worse, but by explaining the problems of, or you found in public. If it's useful, MySQL bug report and almost all of them useful, you help community to gain more knowledge, experience and you may get your real production problem solved even for free, fast. If not, well, you will be notified. Thank you.


The Goddard LiDAR, Hyperspectral and Thermal, GLEHT, Airborne Imaging System combines LiDAR, Optical and Thermal data to provide a unique platform for measuring plant species composition, biomass and carbon stocks, as well as plant growth. This system has been successfully deployed on multiple aircraft platforms and has been used to collect over 6,500 square kilometers of data for NASA-sponsored studies. This article was authored by Vong Lai, Paul M. Montesano, Kenneth J. Ranson and others.


Suspense and The producer of radio's outstanding theater of thrills the master of mystery and adventure William M. Robeson Take a deep breath and let it out slowly and once more No, this is not a Caprice. It is a thoughtful precaution Fill your lungs well now For you will be holding your breath for the next 30 minutes as you live through the long night With Frank Lovejoy a tale well calculated to keep you in United 404 this is Rockford Tower maintain present altitude until further advised over Delta 318 this is Rockford radio go ahead Delta 318 Control tower 90 feet up in the sky over Rockford Field waiting to go on the night watch And you'll listen to the babble of voices that fill the crowded room in an endless series of requests Request for altitude change request for landing permission request for the weather Here is the nine o'clock weather low straightest clouds over the entire Mississippi Valley spreading out over the central states Visibility two miles ceiling 2,200 feet and lowering steadily smoke smoke haze and fog and a ceiling getting lower every minute You look out through the tinted glass windows into the misty night and you think of the strangers overhead in and above the clouds and You wonder if they too feel the hush as the long night begins You wonder if the strangers with a throb of engines and a harsh rasp of many voices in their ears can feel the stillness You look around the tower room you look and you listen to the voices And you're glad every time a ship touches down safely on the long light lines Okay, brother Ken, you can have it for me. It's been a long day traffic been heavy and started sort of slow But it's building up. I got three converging on the outer marker and two inbound on the range It's all here on the board for you. Yeah, okay, we're beginning to stack up over Chicago, but that's their worry Yeah, and they can have it. Yeah. Well, happy landings. Yeah, it's a long time Hello TWA 70 this is Rockford. We have straightest cloud ceiling of 2,000 visibility under two miles smoke haze and fog on the ground Five inbound inside the 20 mile range one conveyor and two DC sevens outbound on the red 70 requesting change of flight plan to land your field instead of Roger TWA I'll notify Chicago and clear you in give us a call when you pass the Milburn Hills Rockford out If Chicago a call Mike tell them their flight 70 is terminating here Hello Beachcraft and nine one four five seven this is Rockford town I've been homing on your range and apparently my automatic direction finder isn't working right. I think I'm lost Stand by four five seven Check the flight file. Will you Mike see if he's on it? Rockford if you are please give me a call. This is Rockford. We're reading you fine beach hold on a second Find anything on a mic? No, there's nothing here Ken. No flight plan. Okay Hello Beachcraft and nine one four five seven this is Rockford tower. What seems to be the trouble with your idea? I don't know exactly Rockford. I'm not too familiar with this equipment But I don't think it's working right because I've been changing from one range to another just like I was told to him They ought to have been somewhere over Minneapolis long ago, and I'm not All right Beachcraft will work something out for you. Where are you flying from? Indianapolis headed on a direct flight to Minneapolis That's right Rockford. I set my automatic direction finder just exactly the way I was told to when they installed it Did you make any visual checks against what your ADF showed? I'm sorry. I didn't get that Did you check your course when you passed over the airways rain stations by looking at visual ground objects like Signs on the top of oil tanks telling you what city you were over anything like that No, I'm afraid I didn't I thought my ADF was working, so I didn't think about anything else Okay, now. What was your last known position last? Well I'm trying to think I Guess the last time I positively knew where I was was when I departed Indianapolis. What time was that about? 530 maybe 545 530 Verify that time that would be more than three hours enroute. You should be well out of my range Yeah, I know but I've been circling for more than an hour Trying to make the ADF work and looking for Rockford. What is your remaining fuel supply? Well, I guess there's no use kidding myself. I think I've got about 45 minutes Maybe at the very best an hour Well, here is the situation the weather here is solid overcast at 600 visibility one mile in smoke and haze Do you see any towns rivers highways that you can identify? Beachcraft did you say you were on top? At what altitude 457 take a good look around you are there any breaks in the overcast Can you see any holes any thin spots in the area at all? Are you an instrument pilot? I mean are you checked out on instruments? Do do you have instrument training?  You reach for a cigarette as you punch the mic button and do the next thing that must be done Rockford Tower to all planes working this frequency. We have an emergency repeat. We have an emergency Please maintain radio silence on this frequency until further notice out a Rockford Tower to Beachcraft and 91457 Come in 457. Okay, Rockford Tell me how did you get on top? I'm straight out to five thousand and later while I was trying to get the ADF working I found myself on top It just happened. Yes. Are you familiar with range orientation? No, I don't know anything about that either. I'm just a businessman with a new airplane I know only enough about the radio to tune in the stations. I Know I'm lost though and need help these gas tanks aren't getting any forward. Yes. I know 457. I understand Sure you understand, but he doesn't he knows he's lost and he needs help he understands that But he doesn't know what the odds are on getting him straightened out and over the field and then getting him down through that solid layer of clouds You fight down a sudden urge to push the microphone button and scream at him To tell him that nobody forced him into an airplane. He hardly knew how to fly Nobody forced him to take off on a long night cross-country and weather suitable only for experienced professionals But you know, there's no time for hindsight. There's hardly any time for hope So you push the black button and you try to sound calm Hello 457. This is Rockford Tower. Now listen to me carefully. Are you reading me? Okay? Yeah, hello Rockford. I'm hearing you fine loud and clear. All right now I'm going to try to get a fix on you, but Before I do I want you to know what the situation is I'm sure I can find you. I'm reasonably sure I can get you over the airport before you're out of fuel I am not sure though that we can get you on the ground.  No, no, I don't understand. I've lost them about gas and I don't understand why we're wasting time talking about it You get me over an airport and then we'll worry about getting on the ground. All right, but you understand this It's my job to help find you. It's my job to help you find the airport and I'll do everything I can to get you on the ground But flying that airplane through those clouds will be the hardest thing you've ever done in your life Do you understand that? Okay, I understand What are we going to do? Now we're going to orient you by radio and bring you in over the Rockford Airport. I Will tell you what must be done, but you have got to do it. I can't fly your airplane for you.  Yeah, okay, Rockford. I understand You know the standard procedures for range orientation you run over every step of them a million times for just this kind of emergency That's one of the reasons you're up here in this modern Tower of Babel on these long nights But you've got two strikes against you on this one Time you read the clock at 9.07 and a fool in an airplane I'm Mike. Yeah, I can get your cargo control center on the horn I have some to set up an alert of all facilities within a hundred miles Are you better get him to clear all altitudes in the area below six thousand feet? Okay, we'll do you know I don't know whether to try to get him down through the clouds now and then try to bring him in or Whether to get him over us on top and then let him down where we won't lose radio contact if he gets too low Well, it's souped up all across the valley Ken you might get him down through it But if he's too far out he'd have no chance of getting here under the ceiling. Yeah, yeah And if I don't get him started it's something he'll be out of fuel anyway, and it won't matter I'm gonna bring him in on top. Okay. I'll check whether very closely Ken if I hear of any breaks. I'll give it to you Good. Thank you Hello four five seven.  Is that clear? Yeah, I understand. Okay Now I want you to listen very closely to my range signal put everything else out of your mind listen and describe Exactly what you hear Is that the range? That's right. What does it sound like? Okay, four five seven now. Is it loud or soft? Okay, that's the end quadrant Now I want you to tune to the Madison, Wisconsin range and tell me what you hear Okay, wait a minute I've got the Madison range. What does it say? It's just like the other only backwards Did I did I that's right? I Can hardly hear it, but it's there. All right. Yeah, okay four five seven.  You'll light another cigarette and push the black microphone button hard Now listen carefully four five seven. I'm going to run a check procedure on you I want you to take up a northeast heading Turn your volume down as low as you can and still receive my range signal At the very moment you detect the change in signal strength either higher or lower advise me Hello four five seven can you hear me? Do you hear me Beachcraft four five seven? I read you now. I lost you for a second, but I hear your range signal now Did you get all of my last transmission? I think I can do it my gauges indicate empty tanks. There's some gas left. I know but I have no idea how much Do you know where I am? I'm quite sure of your direction from me, and I believe I know how far out you are within say 20 miles If what you've told me is correct. I estimate you have 30 minutes fuel remaining I believe your gauges are indicating normally now try to concentrate on doing just what I've told you to do I don't want you to think I'm ungrateful and I Realize you can't afford mistakes But I can't last much longer.    I Want you to listen closely and describe any change in your signal?  That's fine. That's good now listen carefully Turn your volume down a little more And when you no longer hear that other signal and when the continuous tone is loud and clear And when you hear nothing but the continuous tone At that time I want you to turn right to a heading of nine three degrees magnetic. Is that clear? I Yeah, I think so you think so you've got to know so When you hear nothing but a tone when there's nothing but a loud buzz in your ears I want you to turn right to nine three degrees on your compass. Do you understand me? Yes, I understand Turn right to 90 to nine three degrees on the compass when I hear a loud tone. That's correct The tone is strong now. I don't hear the other signal Nothing, but the tone shall I yes turn right turn to nine three degrees and advise Advise when on course when on nine three degrees advise Of course now on ninety three. All right good Target control center has everything cleared on the six thousand there monitoring the calls to okay, Mike. Thanks a lot. What's the time? 940 straight up 940 that's 12 minutes to make it in Hello four five seven You're approaching the range now. You're almost over the station the range is about two miles from where I'm sitting The signal you hear will continue to increase in volume until you cross the range At that time it will fade out quickly for a moment. You may hear nothing then it will increase again rapidly Now at the very instant your signal fades I want you to make an immediate left turn to a heading of four or five degrees Magnetic take that heading and advise understand Mike get on the phone and alert the local police and fire departments Tell them what we've got and to be on the lookout for a fast move Get all the lights on on the field the runway markers when we get him down through this He won't have any time to spend looking for the field. Okay, we'll do that is if we get him down through it You'll add another cigarette you watch the clock on the desk You try to keep your mind clear to think ahead to think of everything that can possibly happen And the waiting is worse than anything yet You keep reaching for that microphone wanting to call him to ask him why he doesn't tell you he's over the range And you know he hasn't called you because he isn't over the range yet And you wait and you wait And then it comes loud and clear Roger four five seven you're doing fine now come left to four five Straight and level hold it until I tell you different. I'll call you back.  This is rockford. You're over the field. I hear you clearly Start a 360 turn immediately and orbit in your present area Beginning of 360 For god's sake tell me what to do this engine is ready to quit You snap a look at the clock 946 5 maybe 6 minutes more if you're lucky 6 minutes At the outside to get him lined up properly for a straight in approach to talk him down through 4 000 feet of solid clouds 6 minutes to bring off a miracle You'll waste 15 precious seconds debating the best way to do it All along up to now you've planned it this way A good steady full-scale power approach knows up a little flaps down just enough power on exactly right Your mind has told you that this was the ticket the only answer With a good steadier plain no turbulence to speak of well trimmed and hands off he might just make it he might But suddenly you're not sure Maybe if he could pull his power slower down trimmer slow and steady a touch of flaps that might be the answer That might do it It would save precious gas if he missed his approach or he goofed up in the clouds He could get back on top for another try maybe You push the microphone button hard and try to sound calm 457 I hear you plainly. You're circling the airport. There isn't time to talk this out You'll have to do exactly what I tell you the first time and do it right. There simply isn't time enough Oh, wait a minute. Do you have shoots? Do you have parachutes aboard? No no parachutes All right, uh 457 we'll have to do it this way now listen to what I have to say you don't have to talk just listen Come around to a due west heading due west As you do start slowing her down Slow her down and trim her up for a power approach a normal power approach.  Don't talk to me bring her around head west with the power on Slow her down flaps down to approach position trimmer up make her steady Advise when you're headed west and slowed down 10 15 20 Where is 25? 457 are you there 457? I'm trying to get her steady I'm trying to do what you told me. All right 457. Don't talk advice went on course I'm on 270 now slowing down I know you don't know all we can do is try down to 80 now Flaps down and power on Roger continue trimming her trimmer down good Adjust your power and trimmer until she's descending at a steady 500 feet per minute. That's 500 per minute Trimmer good.   She will fly. She'll fly better than you can now listen to me When you are eastbound hands off She will descend slowly into the clouds after you're in the clouds do not touch the controls I don't think I then don't think do as I tell you Now when you get in the clouds everything will change for you You will think the airplane is all wrong that it's doing everything that it shouldn't do If you leave it alone, it will start a slow spiral to the left But I don't think it'll be enough to do any harm until you've broken out under the ceiling Now whatever it does you will think it's going to the right or up or down or even spinning But it won't be doing any of those things unless you make it do them Now don't touch it Now are you eastbound? I'm eastbound.  But I take your hands off now Okay Hands are off Now let her have it let her fly herself Ken the ceiling's on the 600 feet that doesn't give him much time to recover and get his bearings when he breaks out But it's all we can do.  Let's try it with the power off this time You may lose your engine before you can get no use rockford It's just no use I can't do it I was fine until I got into those clouds I just couldn't sit there and do nothing I just couldn't I know I can't do it again Listen, there's time. There's time for another try Forget it The engine just quit That's it rockford. Well, you can still do it. Forget it You're wasting your time I just want to say Hello four five seven Hello Hello beach. Hello four five seven He can't hear you his hands floors to the mic Yeah You better hit the crash button Roger A rockford tower to all planes awaiting landing instructions The emergency is over Normal radio procedure is now in effect Rockford Over and out In which frank lovejoy starred in the long night adapted by sam pierce from the atlantic monthly story by lowell d blanton Listen Listen again next week when radio is outstanding theater of thrills brings you another tale well calculated to keep you in Suspense suspense is produced and directed in hollywood by william n robson Included in tonight's cast were stacey harris byron kane court falconberg sam pierce and jack crucian The original musical score was composed and conducted by paul barron Sound patterns by ray kemper and bill james With jack benny and his gang back on the air each sunday. There's just no excuse for a frown Later on today and every sunday get in on the fun on the lighthearted jack benny show It's always a joy to hear Stay tuned for five minutes of cbs news to be followed over most of these same stations by indictment