Hey folks, I'm in the midst of a series of videos looking at different approaches people have taken to visualizing global climate change data. In today's episode, we're going to look at something called the Global Temperature Index, which is a measure of the change in temperature relative to a baseline that was calculated between the years 1951 and 1980. One of the visuals that I have found to depict this comes from NASA. If you go to climate.nasa.gov forward slash vital signals global temperatures, I'll put the link down below, you'll find this figure. I thought that this is simple, yet perhaps kind of complicated to generate. And so what I want to do in today's episode is use the data that we downloaded in the last episode to go ahead and regenerate this figure and, you know, perhaps dust off some of those parts of ggplot2 and the theme function that we haven't used in a while. Here in our studio, I have a brand new R script called temperatureindexplot.r. All it has so far is library tidyverse in it. That's basically what we put in every script, isn't it? If you want to get this repository, there's also data that we're going to be using that's in the repository. Go down below in the description. There's a link to a blog post. You know what to do. There's a video across the top that'll help you get caught up as well. And again, if we go ahead and load the tidyverse, we can then go into our files tab. And in the data directory of our project, there's this glb.ts, blah, blah, blah, CSV file. Let's go ahead and view that. And so this opens up a tab in our studio showing us what the file looks like. One of the things I noticed right off the bat is that there is a header line in here that we will want to skip because our column names begin in the second row. One of the other things that I notice is that we have months like January through December, but then there's also aggregated months. So the average between, say, January to December, so that would be like a full year, December to November, December, January, February, March, April, May, June, July, August, September, October, November, you get the point. The final thing that I notice is that there are three stars to indicate positions where there's no data. And so for example, this might be, oh, I don't know, one of those three month combinations. So like December, January, February, right, where we don't have 1879 data. So we couldn't calculate the the average over those three months. All right. So there's a couple of things we need to think about when we read in the data. So again, we'll do read CSV, and we'll get the data out of data forward slash GLB, all that will then use the skip argument to skip one row. And then we'll do na equals and then the character, right. So we can tell read CSV what characters to treat as an A values. This then reads in our data frame as a table. We've got 143 years worth of data, 143 rows and 19 columns. So there's extra columns in here that we don't necessarily want. I want the average over the full year. So to keep things simple, I'm going to go ahead and use this J through D column. So we'll start with a select and we'll do year. And we'll do J hyphen D and this of course gives us our year and our temperature difference. I don't like having that J hyphen D because it just becomes a pain to have to worry about those back ticks. So I'm going to call this T underscore diff equals J through D and I'm also going to do lowercase year equals year. And so now we've got the data that we need to generate our plot winning, right? We're in good shape. So we'll go ahead and do a GG plot. B, S, X on the X axis, we'll put the year on the Y, we'll put the T diff and then we'll add geom line and we get that line plot. This looks a lot like what we had from the website as you can see, although we still have a ways to go. One of the things that I notice is a subtle difference between my line plot and this line plot is that this line plot also has the dots on it. So let's go ahead and add geom point. And the points that we want are from that special series of values from 21 to 25. I want a white fill and a gray background. So we'll do fill equals white and then color equals gray. And my line, I also want to be colored gray. And so now I'm getting a fill that's white and gray because I forgot to change the plotting symbol, right? And so I can then do shape equals 21. Very good. We're going to have our open circles on top of our line plot and that looks pretty nice. Of course, we could go ahead and let's try the theme light to get the white background with the grid lines. That gives us our grid lines with a white background looking pretty light, if you will. So good. The next thing that I want to add to this is the geom smooth. You'll notice from this version of the figure that there's a black line that goes through the line to fit it all. And so what we could do is a geom smooth and let's start there. And so this gives us a smooth line through the data. One thing I notice is that we've got the cloud around the line for the smooth line. Another thing I notice is that the line is blue. It's also a little bit thicker than the background line of the actual data. And the other thing I notice is that it's not as wiggly, if you will, as we found with the original version of the figure. We have a couple of things to change here in geom smooth. So let's start with SE equals false. That will get rid of that cloud. We'll do color equals black. And let's do then size equals one. Let's try that. And then up here in geom one, we'll also make that size equals one. You know what? I'm going to make it 0.5 because I think one is actually pretty thick. I can also use an argument called span, which determines the wiggleness or the wigglyness of that fitted line. And so the default is 0.75. So let's go to 0.25 and see what it looks like and we'll adjust from there. Good. So we now have a black line that's the same as the gray line behind it. It doesn't have that cloud for the standard error. It's a little bit more wiggly, but you know what? I think it could still be a little bit more wiggly. So let's go ahead and drop this down and I'll try 0.15. And so that looks a suitable level of wigglyness, right? Good. I think we're gaining on it, right? And so we can see already the similarity between what we have and what they had in the original figure. At this point, I'm going to go ahead and output the figure to a file so I can get the dimensions to more or less match what they had in the web page. And so I'll use gg save and I'll put this into my figures directory and I'll then call this temperature indexplot.png and let's go for a width of 6 and a height of 4. So the next thing that I want to do is go ahead and modify my y and x axes. On the y axis, the original version goes from negative 0.5 up to 1.5 and on the x it goes from 1880 to 220 plus a little bit, right? So we can set that by using scale x continuous and then I can put in my breaks going as a sequence going from 1880 to 2023 and we'll go by 20 year increments. Then we'll do scale y continuous and we'll do limits going from negative 0.5 up to 1.5. And so we've got our limits set right. One thing I noticed though is that there's a bit of a margin say between the limit on the y and x axis and the other axis, right? So there's a bit of space here between the negative 0.5 and the x axis whereas on the web page version there's no space there. We can get rid of that space by adding an argument called expand. So we can do expand equals c0 comma 0 and we can do the same thing that we did for the x for the y. So we can now see the values on the axes go right to the edge. One thing I see that we have that the web page doesn't have are the tick marks. So let's go ahead and remove those using the theme function. So we can do theme and we can then do access.tix equals element blank. That of course gets rid of all of those tick marks and we're in pretty good shape. We can now go ahead and let's modify our labels. We need an x and y axis label. We also need a title to match what we had on this original version. So I'll come back in here and we'll do labs and then on the x axis I believe it was all cap year and then the y, temperature, anomaly, and then I had c in parentheses. And then the title, I'm going to go ahead and copy this from the web page. I'll grab that also go ahead and grab the subtitle and we'll plop that in there and we'll put that in quotes, put a comma there. We then want this to be subtitle and we wrap that in quotes and we go all the way out to the right to put that in quotes and this credit was on a second line. So I'm going to go ahead and put in a line break. So we're gaining on it. A couple of things that I notice about this that are a little different from what's on the web page. Again, we don't need to be, you know, just strict adherence to what they have on the website, but I find that by forcing myself to copy what I see on other versions of a figure I'm trying to generate, it forces me to go into parts of R that I'm maybe a little bit uncomfortable with and helps me to learn better. So anyway, a couple of things I want to fix. The title is black on the web page. It's red. There's a bit of a spacing that needs to be inserted between the title and the subtitle. Also, my title here is justified on the y axis, whereas on the web page, it's more to the left, justified more on the overall plotting of the plot, right? So let's go ahead and see if we can fix that in the theme function. And so back here again, we can do plot.title.position, and we can then say plot. That will get everything over to the left. I can then also do plot.title, and I can do element text. And I can then give it a margin. And then I can give that the margin function. And the margin I want to put is on the bottom. So I'll say b equals let's do 15. I can also change the color here. So I can do color equals red. And I can say face equals bold to make it bolded. And then plot.subtitle, I can also do element text. And I'm going to make it maybe a little bit smaller. Let's do size equals eight and see what that looks like. I think I'm missing a comma over here. So that looks good. Maybe the margin here is a little bit too big. And I also would like a margin below my subtitle. So let's come back here and let's make that maybe 10. And then for my subtitle, I'll make a bottom margin. So I'll do margin equals margin, b equals, let's try there 10 as well. So I think that looks pretty good. At this point, the main difference I see between my version and their version is this legend, right? And so they have a legend indicating that the gray is the annual mean and the black is the lowest smoothing. One of the problems that we have with our code is that we haven't been mapping one of the variables to the color aesthetic. And so what I'm going to do is to force that, right? And so I can come back up here and where I have say color equals gray, I'm gonna instead say AES color equals, and let's make it one, okay? And so we'll put that in comma in parentheses. And we'll also do that down here for geom point. And so again, what this is doing is it's creating a variable, a dummy variable that I'm calling one that I'm mapping to color, right? And that way I can now come down to geom smooth and I can do the same thing, except instead of giving it one, I can give it the value two. And so now when we generate this figure, we're gonna have different colors for the data line with the points from the smooth line. And sure enough, we now have our salmon and teal lines here. And so hopefully you can see that we're gaining on something here, right? What we need to do is we need to change the color of our legend and we also need to move it into the upper right corner. So let's take this in stages. First things first, let's go ahead and change the color of our legend. And we can do that back here. I'm gonna put this with my other scales and do scale, color, manual. And I'll do name equals null. And then I will do breaks equals one and two. And then I will do values.  So I'll do gray for one, which was the background data. And then black for the foreground smooth fit. And then my labels. I'm gonna go ahead and copy from the webpage and paste that in. So annual mean and then lowest smoothing. And I think in R, they don't have that W, but I'm gonna leave it in there because what do I know? Anyway, so let's go ahead and run that. And so now we have our gray and our black. I again wanna move this up into the upper left corner of my plot. The other thing I'm noticing is that I'm getting this circle from geom point. So I wanna get rid of that. So I can get rid of that circle from geom point by coming up to geom point here. Show dot legend equals false. Good, that circle goes away. Let's move it now. We can come up into theme and do legend dot position equals. And we give it a vector. So the two positions in the vector are the relative position on the x-axis and the y-axis. So let's do like 0.2 and then on the y, let's do say 0.9. And so that gives us more real estate now for our plot to the right because we moved the legend out of the way and it put our legend kind of in the upper left but we wanna move things around a bit. So let's start out by moving it to the left. And so let's try to say 0.15. I think that looks good. One of the things you'll notice though is that there is, the legend seems to be a bit bigger than these two lines. And that's because there's a title in here that we set to null. But for whatever reason, it's still is leaving space for the title. So a trick that I have found to work in this situation is to make the font size of the title of my legend to be zero. And again, we can come down here and do legend dot title element text. And then we can do size equals zero. The other thing I can do to kind of squish things together a bit is legend dot key size, key height, let's say. And that's gonna take a unit. So we'll say unit and let's say eight and that's gonna be in units of points. And that puts it together a bit. One other thing I see around this is that there's a margin around it all. So let's go ahead and remove the margin. We'll do legend dot margin. And again, we'll give that the margin function with all zeros. And so that you can kind of see the grid lines are a bit tighter around those labels. I feel like now those lines are a bit too close. So let's go ahead and make the legend key height just a little bit bigger. Let's make that 10. And I think that gives it a bit more breathing room. One final thing that still bugs me a little bit about this is that we have a line here in the legend rather than the square. Again, if we look at the legend in the plot, they have a square rather than a line. So how would we go about fixing that? So to fix the legend, let's remember that we actually have three geomes for plotting. We've got the geom line, the geom point and the geom smooth, right? So I think the easiest way to get that square is to turn off the legend actually for the line and the smooth line and to turn back on the geom point and then we can override what shape is shown in the legend, okay? So it's okay, we can do this. So again, back here we had show legend false for geom point. So let's change that to true. I'll then go ahead and put show.legend equals false here and I'll copy this down as well for geom smooth. So now we've gotten rid of the line in the legend and we now have that circle plotting symbol but we don't want the circle, we want a square. So we'll come back in here and where we had our scale color manual so we can come back in here and do guide equals guide legend. And we'll then do override AES equals list. And so what we're gonna do here is we're gonna say take the guide legend, take the legend for color and we're gonna override one of the factors or one of the aesthetics that's in there. And so what we're gonna change is shape. And so if we do change shape equals 15 that should give us a square plotting symbol. Sure enough, we get a square plotting symbol. It's kind of small. So let's see if we can make it bigger. And again, we can come right back up to where we gave it this list and then I'll do size equals five. And here we go. We now have our large squares in the legend. And I think that does a pretty good job of approximating what was in the web version. Yeah. I mean, there's had kind of a weird border around it. I'm not gonna go through all the trouble of trying to figure out how to make an outer ring and middle ring and an inner core color. I don't think that's necessary. I don't think they intentionally did that either. I kind of like this version of our figure. And I think it works really well. I think it does a pretty nice job of displaying the data. Again, this is showing the average annual temperature that is normalized between 1951 and 1980 global temperatures. And I believe includes the land surfaces and ocean surfaces as well. So you could see right between 1951 and 1980 is right in round in here. And that is right about the zero line. And so then the temperature index is basically how far are we from that normalized, that average temperature? And as you can see, we're quite a bit above that. And I'm here in Michigan, it's in May, and it's been 85 degrees this week, which I think is, I realize that's weather and not climate, but I think that indicates something is off. Well, in the next episode, we'll look at another way of visualizing global climate change so that you don't miss that episode. Please be sure that you've subscribed to the channel. You've clicked the bell icon and you've given me a thumbs up, as always. Tell your friends about what we're doing here. Try your hands with this code and see if you can take some of these principles back to whatever it is you're working on in your day-to-day work. We'll see you next time for another episode of Code Club.


Neuroinflammation is a complex process involving the activation of microglial cells, which are responsible for clearing away dead or dying cells in the brain. When these cells become overly activated, they can cause damage to healthy tissue, resulting in the destruction of neurons and other cells in the brain. This process has been linked to the development of Parkinson's disease, and researchers are investigating potential treatments to reduce the effects of this inflammation. This article was authored by Sandeep Voss and Moore, Heymond Kumar, in Sue Kim and others.


Guru Nanak was traveling by foot, walking from village to village, giving his… offering his teachings to people. A very compassionate and courageous man, both ways, and quite… we like him because he is not one of those all the time smiling, gentle things. He knows when to be hard, when to be soft, real thing. So one day he happened to be a guest in a home of a… a very rich man in the area. So when he was… he was a guest in this house for a few days, when he is leaving, he gave this man a needle, a sewing needle. He gave this needle and said, you keep this with you. Sometime when you see me, you can give it back to me. Till then, please keep it with you. A needle, not a golden one. Just a simple needle. That man took it and kept it with him. Then after the guru left, he told his wife, the guru gave me a needle and I am supposed to keep it in safekeeping and give it to him later.  If you take something from a man like him and suppose he is a old man and if he dies and you don't get to give back this needle, what will you do? You will be in debt forever. Taking a needle from a guru, why did you take it? You should not receive anything from a man like him. What we offer is fine, never take anything from a man like him. And if he dies and goes away, you can't carry this needle to heaven and give it there. It is not possible to take the needle to heaven and return it there. So you will be in debt forever and ever and ever and you will not be able to wash off that one karma and it may mean a thousand lifetimes. This is not a good thing. Just somehow find him and return it to him immediately. So the man started trekking behind the guru. The guru walks fast.  So Guru Nanak said, so you know that you can't carry this needle to heaven. You know that, right? He said yes. Then when you know this that you can't carry a needle, what are all these things that you are accumulating? You will not be able to carry any of that. If you can't carry a needle, definitely you can't carry anything else. Then the man got the message. He fell at his feet and he went back home, sold everything that he can sell, just kept what is needed for his family, for him and his family and the rest because the whole society was poverty stricken. So he went about building whatever was needed for the well-being of the people around. All these days people were living in poverty, he was going on accumulating. The world is a limited space, this planet is a limited resource. If each individual goes about accumulating endlessly, all that can happen is strife, all that can happen is pain. Unless every individual somewhere fixes it within himself, look at this is my deal, beyond this I will not go. Rest of my capabilities I will use it for everybody's well-being.  The disaster on this planet is not earthquake, not volcano, not a tsunami. The true disaster is human ignorance. This is the only disaster. Ignorance is the only disaster, enlightenment is the only solution. There's really no other solution you can see. So spiritual process, if it has to become alive, this is not about renunciation, this is just about living sensibly. Wrong words have been put by external scholars. There is no such word as renunciation in any of the Indian languages, if you don't know this. Yes? There is no such word as renunciation in Sanskrit language. It is the outside scholars who come and say, oh this man is renounced. No, he's embraced the whole universe and you think he's renounced. That is your understanding because you cannot think of life without processing this, this, this one part of the planet is mine, without that you cannot live. Somebody has embraced the whole universe, so he did not think he has to gather it because all the stars belong to him. The whole galaxy belongs to him. He did not think it is necessary for him to gather something and keep it in his bag or in his bank. It did not arise, it did not occur to him. This is not renunciation. So understanding life from an inner perspective, not from an objective sense, because objectively whatever you perceive is only good enough for survival. You need a subjective perception of life.


Hopefully you can understand me. I've came over a flu on the flight over. I'm not there right now, and I was earlier there. So web application debug toolbars exist for various web frameworks. Solutions exist for frameworks input in Python, as well as Ruby, PHP, and pool. Now I have no idea where that idea first originated, but for Python at least the first example I know is the Django debug toolbar. Although I'm sure if we have some sort of thematic in here, he'll jump up and down and say, no, no, you're wrong. We had it years earlier. But in my research, I could only find Plome, and that was only from a more recent time. So I'll say Django wins. As to what they are, the actual web application debug toolbar is a piece of code which is embedded within your web application. Once enabled, when you then access your web application from a browser, a toolbar or sidebar will be presented along with the normal page response for your web application for the URL which was visited. Through this toolbar, you can then access information about the specific web request which was just made. A range of information about the request may be presented, generally within separate panels selectable from the toolbar. This can include performance data such as how long the request took to execute, the CPU or resources consumed, or other operating system parameters. The request headers received by the web application from the browser, as well as the response headers that were returned by the web application would also generally be available. As with details of any request parameters and cookies, a range of web framework specific information could also be available. This may include session information derived from cookies, the URL route matched, and the name of the actual handler function which processed the request. Even more detailed information about work done within the context of a request for database queries and template rendering might also be available. For the case of the Django Debug toolbar, as I've been showing, it provides a set of quick setup instructions. First, you need to get the Django static files feature working. After having done that, add the Django Debug toolbar itself to the list of installed applications in the Django settings module. You'll also need to ensure that Django is running a debug mode. It's now just a simple matter of running up the Django development server and you're all ready to go, or at least you hope so. In the quick setup instructions for Django Debug toolbar, you'll find this very nice, very nice and cheery message warning you of possible impending dune. So your luck may vary, but this obviously raises the question of what is Django Debug toolbar actually doing on startup that could cause such a mess, including the possibility of circular imports and errors telling you that you've configured things incorrectly. The answer to this lies in the note in the documentation preceding this warning, and that is that Django Debug toolbar is using an evil little hack to bootstrap itself. Specifically, Django Debug toolbar wants to monkey patch additional configuration into the Django settings module and URL views. To do this, it is hijacking the validating of database models when using the development server to run code, which has nothing to do with the actual database. Now I have got windows of some changes in Django 1.7 related to application initialization, so it is possible this may no longer apply in Django 1.7. What do you do if the server does blow up on you because of this? Also, since this evil workaround is dependent on using the Django development server, how can you use the Django Debug toolbar with an alternate web server such as ModWizky? For this eventuality, Django's Debug toolbar provides you with additional explicit setup instructions as well. The first step in that is that you need to tell it in the Django settings module to not do its evil monkey patching. Now we already added the Django Debug toolbar to the list of installed applications. This is still required, otherwise Django will not know where to find the static file assets and template files that Django Debug toolbar view handlers require. Leave it out and you will immediately get a template that does not exist exception from your web application when accessed, and we don't want that. Next, we need to change the Django URL's configuration. This is to insert special Django Debug toolbar view handlers to process any request which received under the underscore debug sub URL of the Django application. Wisdom is that Django Debug toolbar should never be used on a production system, so this is also gated by checking the Django Debug flag. This is of course assuming you know why you should not be running Django in production with the debug flag, and I was a bit worried about the talks and comment on the security talk, suggesting that a lot of people do, which is a bit awkward. So after adding in the URLs for the Django Debug toolbar, we need to add in a middleware class. This is a quite important part of the Django Debug toolbar code, and its placement in the middleware classes list is also very important. It must be placed as close to the start of the middleware class list as possible, but after any middleware that encodes the response, such as gzip middleware. Finally, although you should only be running the Django Debug toolbar in the development environment, you still need to protect who can access it. The last thing you want is someone being able to access it over the conference network while you're watching my talk here. Now the documentation does say that if you don't set this, it will default to <IP_ADDRESS>.0.1 and column, column one, which is the IPv6. But on macOS at least, I found I've also needed to add in FE80 column, column one style of address.  I think I have to do it when I've got my VPN going or something. If someone can tell me, please do. So back to the Django development server, and we should be all good again. The evil hack of bootstrapping via Django database model verification is gone, as should those risks warned about of module import cycles and strange exceptions. What if you want to use a real production-grade whiskey server, such as modWiskey? In this example, I will make use of modWiskey express. You start off by installing modWiskey by running pip install modWiskey. If using macOS, it should all install with no issues. If you're on Linux, then you may find you first have to install the Apache development package for your specific variant of Linux, because that isn't generally installed by default. As long as you've got your package package in, that should just default, and you've got modWiskey then install. So once we install, we can now test that the package was installed correctly, and that Apache can start up properly. For this, we run modWiskey express command and give it the start server command. Normally, we would provide an additional argument with the whiskey script file, but we leave that off here because I just want to test the installation work. So in the second window, we can then open up the browser on the URL for the instance of Apache modWiskey. We've just started. What we should get is a helpful splash screen so you know it's working okay. As I already mentioned, to run it with an actual whiskey application, at this point, you can supply the path to the whiskey script file. You can also use the minus minus help option to get information on all of the command line options in case you want to change the listener port or specify a directory full of static assets. If you want some high-level information on modWiskey express, which you've never seen before, go look at PyPy, PyPI, sorry, get killed if I say PyPy, PyPI and look at modWiskey there and you'll find some information there. Now, because we're using Django though, rather than pointing modWiskey express direct at a whiskey script file, it's better to integrate modWiskey with Django itself. That way, when we run modWiskey express, it also know about the Django specific requirements for static files. What we therefore do is add modWiskey.server into the Django installed applications list of the Django settings file. Django does these days have the static files application. However, if using a whiskey server integrated with a real web server, such as the case with modWiskey, it's really much better to use that real web server. We therefore set up a location for the static files to reside and run the Django collect static management commands to collect together all the static files from the different installed applications specified in the Django settings module, including Django debug toolbar. Whatever you do though, do not remove Django contru static files from installed apps. This is because the Django debug toolbar code doesn't want to trust and I know what I'm doing and will cause everything to fail if it doesn't think that static files app will be serving up those files. So we're going to trick it a little bit, just not take it away. Now finally, here's the cool part. To actually run modWiskey with Django, and this is going to run up a full Apache, we simply run the run modWiskey management command. So this will automatically generate an Apache configuration for you on the fly dynamically for this instance. This will include mounting the Django application, setting up static files and so on. Because we're in development environment, we can even enable automated code reloading for good measure and modWiskey express will worry about all the details of getting that to work as well. So here's a bonus for this talk. You get to learn about modWiskey express, but that's not what we're here for. So the app will be running, invoking the one modWiskey command will give you the URL to then access the site as well as location of the Apache configuration which was generated in case you do want to poke around and learn from what I've done in generating it. And the Apache error log in case something does go wrong and you need to look at the application long to track down any details and exceptions that were logged in. Most important to what this talk is about, the Django debug toolbar will now also work. And that's because we followed those explicit and set up instructions. So what we learned from the explicit configuration steps requires that Django debug toolbar is dependent on a number of key things in order to work.  It registers a series of view handlers which are used to produce data for each toolbar panel, which in turn potentially require page templates to render responses. Finally, it requires a Django middleware to be installed. Is this last thing, the Django debug middleware which is the key to Django debug toolbar working, is the middleware which allows it to hook into the different phases of handling a request in Django. For the Django debug toolbar, it hooks into the process view and process response phases for Django request handling. This allows it to perform actions at the start of the request, prior to the target view handler being invoked to handle a request, and finally allows it to perform actions at the end of the request as well as actually manipulate the response return from a request. Note that this is for any request, not just requests made against the Django debug toolbar's own view handlers. The part which is initially of most interest in the middleware occurs in the process response phase It is in this phase where the toolbar itself is injected into the response that comes back for a request. Before they can be done though, it is necessary to first determine whether the page is in fact HTML, and that it makes sense to insert it. There is no point trying to insert the toolbar into images or a plain text file. We're only interested in HTML. We also want to avoid compressed data or stream responses. And this is where it was important where the placement this was. If we put it after compression has been done, then this won't actually do anything. If it is okay to be modifying the response, then the rendered HTML corresponding to the toolbar itself will be injected into the original HTML response for the request. This injection of the toolbar HTML is done just prior to the existing closing body tag. The combination of that HTML as well as the style sheets and JavaScript code, which it in turn loads, when rendered in the browser results in the sidebar appearing alongside the content of the original request. As shown before, the sidebar under the time category will show how long the request took to be handled, or at least up until the time that the toolbar HTML was inserted into the response. When we click on the time category in the sidebar though, only then will the debug toolbar panel be displayed with more detailed timing information related to the request. Although the sidebar itself came back with the original request, the panel displayed as the result of a separate AJAX request made as a result of clicking in that category in the toolbar. Given it is a separate request to get the additional data, where is the data stored and how is it identified? The answer is that any JLA generator from request is saved away at the time of the request. In the toolbar HTML that comes back with the response, it has a storage ID field which identifies the item in the cache for the original request. When drilling down, a request is made with that storage ID along with the ID of the panel, corresponding to the category selected on the sidebar, which should then display the full data from the original request. Now we can't say the full details on every request ever made, so any data stored in the cache must have a finite lifetime. By default, the number of requests for which data is retained is 10. This is actually quite a big limitation as what it means is that the debug toolbar is not very useful when you're trying to use it on an application, which is any traffic beyond just that which you are manually creating with your browser. This is because any data on the request you're interested in would have been thrown away by the time you drilled down to it otherwise. As well as potentially using data, if there are other users concurrently using the same web application, the data can be purged if you are working on a page which is a heavy JavaScript component, which makes additional Ajax requests after the initial page response has been returned. These Ajax requests are a problem in themselves, and this is because Django Debug toolbar only provides you the ability to debug the primary HTML request. There is no ability to get details of any of those subsequent Ajax requests made from that page. The limitation on Ajax requests is that the toolbar is displayed in line with the current request only. To better understand what I mean by this is it actually helps to look at how the debug toolbar for the Pyramid web framework works in comparison to that for Django. In the Pyramid debug toolbar, you do not get a sidebar for the current request. Instead, you only get an icon indicating that the debug toolbar is operating. When the icon is clicked on it, it then goes off to a completely separate window. So what the Pyramid debug toolbar does is not show any details in line to the current request. Instead, you always access details of requests from a separate window, which shows a list of the last 20 requests. When clicking on the inline icon within the initial page response, it will push you across to the details of that specific request in the separate window. Important is that since you now see all recent requests, you can also see any separate Ajax requests served by the web application for other assets associated with the page. Having jumped a look at Pyramid, let's look at the history of debug toolbar for Python. As I already said, as far as I know, it started out with the Django debug toolbar. This was summarily copied in creating the Flask Debug toolbar. From the Flask Debug toolbar, then came further copies tailored for Bottle, Web.py and Pyramid. As far as I know, with the exception of Pyramid, they all simply copied the inline style of the debug toolbar as originally implemented by Django. Only Pyramid branched out and tried to address tracking of Ajax requests. So Pyramid Debug toolbar was therefore an improvement, but in my mind, they all have one big failing. That is that they are all distinct implementations. That is that the Django implementation is intrinsically wedded to the Django middleware infrastructure, with implementations of panels implemented as Django view handlers using Django templates. Flask uses its own middleware in Ginger 2, and so on for the others. We've each been ported to their specific way of doing things. The opportunity missed here as far as I'm concerned is that all these different frameworks at their lowest levels implement the whiskey specification. Yes, the debug toolbars do offer some panels which are framework specific, but the core functionality can be implemented as a whiskey middleware. There's therefore been quite a lot of effort wasting creating these separate implementations. Whereas if it was done at the whiskey level, there could be one debug toolbar to rule them all, which works everywhere. So imagine it for a moment, one debug toolbar that was best to breed when someone enhanced it due to what they found when using a specific web framework. All other web framework could benefit as well. And wouldn't that be wonderful? Unfortunately, Python web communities have a history of not cooperating, each believing their framework is the only true way. And Django unfortunately is no different. So what eventually happens therefore is that they build things which will only work with their specific framework. Someone annoying. So I think I believe we can do better. So since I think it was such a great idea, let's have a look at implementing the basic mechanisms of the debug toolbar code at the whiskey level, using a whiskey middleware. In particular, let's look at how we can manage to inject the toolbar HTML code into the response for a request. We can work on how to do that than we will on our way. This is where we can learn from the Django middleware code I showed earlier. It may not be obvious, but there are a couple of key things which are going on here. The first is that the HTML code is being inserted just prior to the closing body tag. And the second is that the content link for the response is being updated. In other words, it needs to operate on a complete response. This presents us with a bit of a problem. And that is that in whiskey applications, the response doesn't need to come back as one byte string, but as a sequence of byte strings. As far as inserting something at the end of the body, we could just look at each separate byte string until we find the closing tag for the body and then insert it. The issue is though that we also need to update the content link. And if we can't know the length of what is being inserted until it is inserted, we can't adjust the content link at the point the headers are sent and still stream the response. Now, we could buffer all the response content in the middleware and then operate on the complete response content. Then send it on after adjusting the content link. Technically though, you're not meant to do this in whiskey middleware according to the whispies specification. Plus it would cause applications which slowly stream data over time to break as nothing would be sent until all the content was generated. The actual size of the response content could also be a problem if for example one was streaming a very large file and you couldn't actually fit into memory. If having to insert at the end of the body is such a problem, why are we inserting at that point anyway? The reason is that part of what is being inserted consists of JavaScript code. And reason is that this should always be inserted at the end of body so as not to delay page loading by doing it earlier in the page. That may well have been the case once upon a time but are there now better ways of doing it which would allow us to instead insert it at the start of the response content instead. With the modern browsers we use today rather than needing to defer things to the end of the body, we can instead load the JavaScript from the head element of the page marking that it should be loaded asynchronously rather than inline to the request. By being asynchronous, it will not delay the loading of the remainder of the page. When the JavaScript is loaded, we then need to trigger an action to go back and modify the DOM for the loaded page to insert what we wanted there in the first place. We have to be careful in doing this though as we likely need to ensure that the page is actually being completely loaded. What we can do therefore is triggering the action to modify the DOM off the document being ready in the JavaScript code we are loading. How does this help though? The reason is that we no longer have to buffer up the complete response in order to be able to insert into the end of the body. At worst, we have to buffer up to the start of the body, but the amount we have to buffer up is a lot less and so doesn't present an issue with memory. It is also highly unlikely, even with the streaming response, that the head element would be sent slowly in parts. Instead, the head would be sent in one go upfront and it would only be the body which was sent out slowly. We can handle insertion but what about the UI itself? The problem with the existing toolbars is that the UI is intrinsically linked to the URL routing request handler and page template systems of those specific frameworks. My suggested solution for this is only to have a REST API served up via the Whiskey middleware for accessing any data stored about requests. Excuse me. The UI would then be a JavaScript interface rendered in the client by using a REST API in the Whiskey middleware to get access to data. We're then separated from the specifics of particular web framework's way of doing things. So if you thought I'm coming to this talk that you would learn about how debug toolbars work, hopefully you have in part but what I really want to pitch is the idea that our current debug toolbar implementations could do a big overhaul. In particular, there is a great opportunity to come up with a debug toolbar which could work with any Whiskey framework. I think we could build a better ecosystem and make our job of debugging Python web vacations a lot easier. And more importantly, diverse sets of people from different web frameworks can contribute to this so that we all get benefit from it. So one thing I personally like to do is integrate into the debug toolbar features to allow you to view additional performance monitoring data. This is where I'm coming from. So as an example, I implemented monitoring for a modWiskey but which used a New Relic platform plugin system to do visualization. It was free to use that feature in New Relic but when I announced it on the modWiskey mailing list I got zero users. Not very successful. People objected to it not being able to be self-hosted. What I don't want to have to do though is develop a separate UI for half a dozen different framework-specific debug toolbars to provide the visualization. I've also been working on a side project related to the New Relic Python agent project I work on as my day job. And New Relic is a wonderful tool for web application performance monitoring and you really all should be using it. But what I would like to do is bring some aspects of what we do with New Relic into a local developer mode integrated into a debug toolbar environment because we have a production capable way of monitoring your web application. So why not try and make use of it in a development environment as well. So in continuing this idea though there is actually in continuing this idea there's actually a bit of a twist and the problem of how to insert hasty mel into responses is something that is already solved by the New Relic Python agent across frameworks as we use that exact technique in order to implement and use a monitoring. The fault therefore is that since we do not do that already if having a local developer mode for the New Relic Python agent why not use it as the base for a debug toolbar as well. We can even have a variant of the debug toolbar you could use when using New Relic in production. So there are no other third party tools which can be brought under the same umbrella. So Simon Wilson of Eventbrite demonstrated a PyCon AU this year a debug toolbar like tool called TikiBar. This actually embodies many of the same qualities I want to achieve in pursuing this whole idea. This includes the idea I have that one could come up with a limited toolbar which works for production systems. TikiBar is though again bound specifically to Django and currently Eventbrite's own software which is exactly what I don't want to see. So I don't know yet if I'll be allowed to make it available but what I'm pursuing is a local developer mode for the New Relic Python agent that will give you a subset of its functionality for use in the development environment using its mechanism for HTML injection to implement a debug toolbar. Panels for this debug toolbar system can then provide access to the New Relic data as well as other data that debug toolbars presently provide which are framework specific. On top of that I want a mini toolbar which can deliver up safe information in the production environment. So my reason for doing all this is because I hate to see all that wasted effort be done by different developers for each different web framework or in-house system. This doesn't make a great deal of sense to me. So hopefully you're all very altruistic but I do have to admit there is a bit of a selfish aspect to this as well. And that is what I think that what New Relic does is awesome and the debug toolbar provides possibly a way for me of putting New Relic in front of you in a local environment as well so you get an idea of what we can do and how it can then be useful in your productions. Hopefully you won't concentrate too much on that stuff and you'll say, hey, this is a great idea anyway. So certainly I'd love if you go and try New Relic but if you aren't interested in that at least but you are interested in improving on the existing web application debug toolbars available then come and talk to me. Tell me what your own thoughts and ideas and features are that you want to see in this sort of thing. I'll be around for the sprints and we'll be working on this or on modWiskey. So if you come and talk to me about it then. And also finally, if you are looking for an actual paid job and you know a bit about New Relic and you're interested in that sort of stuff we are actually looking for someone who is strong in Python testing. So also come and talk to me if you're interested in that as well. The job for that would be in Portland. No remote, sorry. And that is all.


This is stock number 10193A. 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 2017 Jeep Wrangler Rubicon Recon Edition. From this HD video you will be able to tell that this Jeep is extremely clean all the way around inside and out. Rhino clear coat is the color we shoot all of our videos in 1080p so if you have HD capabilities on the computer tablet or smartphone turn them on right now because it's like you're right here looking at the vehicle with me and definitely your best way to check out the vehicle before seeing it in person. See the door hinges are in great shape it has the heavy-duty metal rock rails with the step pads comes with the granite crystal painted alloy rims BF Goodrich All Terrain LT28570R17 tires with I'd say 80 to 90 percent of the tread left on them has Rubicon shocks on there frame and under bodies in really nice condition. Driver's side front fenders in excellent shape so the Recon package gives you this heavy-duty decal right here it's a really thick decal and then you get the Recon Edition logo right there as well the painted alloy rims you get the metal front bumpers the red toe hooks factory fog lights this one has the LED lighting group so you get the LED headlamps and running lights and fog lamps it's kind of the matte flat grille here you get the red outline Jeep logo the sport hood passenger side rim no scuffs or scrapes on that and as you go down this side of the vehicle you can see just how clean the body is how reflective and mirror like that paint is we take these HD videos so you can really see the overall quality of the vehicle and get a really good idea of the overall condition before you make the trip here you saw a lot of vehicles over the internet so this is how we do it want to make sure you know everything about the vehicle before you even step foot in the door so you can make a smart buying decision from the comfort of your own home back rim is an excellent condition as well no scuffs or scrapes in the back tires have just as much tread as those front tires I didn't see any dents or dings down that side coming to the back of the vehicle you'll notice the you'll notice the red toe hooks back here as well this one does have a receiver hitch and four pin wiring you got the guards on the rear lights that's a brand new tire so you can see how much tread that is compared to one that's on the vehicle look pretty close and uh back rim matches the rest this one has the alpine sound system in it so you get the factory subwoofer in the floor then there's spots for your door hinge roof bolts right there your jack tools are underneath there this is the soft top the soft top itself is in really nice condition I didn't see any rips or tears on it it's that newer fabric that they started using I believe in like 2016 for full disclosure this back rim is in excellent shape no scuffs or scrapes and down the rest of this side of the vehicle very very clean you get the heated power mirrors inside the rubicon recon package gives you the black leather interior with the red stitching you do get the red seat belts part of that recon package as well no rips or tears on those seats driver's seat height adjust factory all-weather floor mats you get the red Jeep logo part of the recon package as well as sway bar disconnect and the axle lock buttons and then you get the red mesh right there inside you can see that this Jeep has 29,976 miles you get the special uh spinometer cluster right there outside temp and compass display and mileage leather wrapped steering wheel cruise controls on the right bluetooth and information center controls on the left and then of course as always on the back audio controls this one has the 8.4 I'm sorry the 430n radio so you get navigation system on it am fm and serious xm radio capabilities this one also has a hard drive that you can save music and pictures to and you can save up to 28 gigs worth of data on this radio has an aux and a usb jack you have your climate controls down here your heated seats stability control downhill assist control automatic transmission five speed and your four by four shifter on the floor passenger side seat and floor mat are in excellent condition as well and this vehicle has never been smoked in smells very clean and this one does come with a uniden pro 510 xl cb radio and we got the coax whip antenna right there take a quick look at the back seats no rips or tears back here very nice and clean and those seats do come out so you can remove those for extra storage and we'll take a quick look under the hood I would personally like to thank you for checking out the video today we try our best to give you the most accurate representation of the vehicle and hopefully from this hd video that will have done that so you can make a smart buying decision from the comfort of your own home I'd highly recommend this vehicle from a quality and condition standpoint under the hood we have the award-winning 3.6 liter pentastar v6 motor engine bay is very clean runs very smooth this jeep 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 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 mini vans wranglers half tons three quarter tons one tons you name what we got to 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 in a second you will see a 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 check us out and we really look forward to helping with this super clean 2017 jeep wrangler rubicon recon edition thanks again


Archaeologists have discovered yet another ancient anomaly, which has linked a now lost but once clearly advanced global civilization, pertaining to a wall relief in Peru, belonging to the oldest civilization in the Americas. The wall, although dated to approximately 3,800 years ago, depicts what many now believe is an illustrated narrative of the difficulties they experienced prior to a cataclysm caused by an ancient climate change. One meter high and 2.8 meters long, the wall relief was discovered in the seaside archaeological site of Vichama, 110 km north of Peru's capital Lima. The Vichama side is part of the recently discovered yet now lost Karal civilization, also known as Narte Chico. Dated at over 5,000 years ago, this dating alone makes it the oldest civilization known to have dwelled within the Americas, now claimed as purely coincidental. This civilization flourished around the same time as that of the thriving civilization of Mesopotamia, ancient Egypt, and also Chinese civilizations. The Karal civilization was located in the Supe Valley, along the north-central coast of Peru. Made of adobe, a clay-like material, the wall seemingly documents climate change, one which could not have been contributed to by human activities. Archaeologist Ruth Chandy, who oversaw the excavations at the site, hypothesized that the serpents within represented a water deity that irrigated the earth and made seeds grow. She believes the relief was likely done towards the end of a drought and famine, that the Karal civilization, among others we have covered in the past, once experienced with other reliefs displaying emaciated humans. Many self-funded archaeologists now believe, like we have postulated, that the discovery reinforces the notion that these early humans were depicting the difficulties they faced due to climate change and a depletion in available water for irrigation, which had a large impact on their agricultural production. The excavation has to date unearthed the ruins of 22 buildings in a 25 square hectare space. It would appear that just like that of the site of Tikal, and the now lost plaque which once depicted the dramatic scene of a cataclysm, a great flood, along with erupting volcanoes, with a boat seemingly attempting to escape this event, surrounded by many of the population drowning, a cooperating artifact fortunately photographed before its mysterious disappearance. Was there indeed a great flood? One which seemingly followed a great famine. It would seem the evidence for such an event is mounting, thanks to not only the evidential sediments which once drenched many of the still unexplained ancient sites of the world, but also by its depiction by those who lived through it. It is indeed a highly compelling mystery. Here at Mystery History, we cover the unexplained areas of antiquity, either ignored, avoided, dismissed, or simply given an incomplete or often illogical historical lifeline of existence by mainstream academia, particularly those which we have covered of significant size, quarried from many miles away, now often immovable and once transported and either erected or placed atop one another seemingly effortlessly. We were, in a past series of investigations, looking into an interesting quarry within the Basda cave system on the edge of Turkey, a place with particularly good granite and a proven source of stone for numerous megalithic sites many miles around. Later proven by us via the preserved linkages in tool marks to have been used by more than one group as if they had coalesced at this particular site. Yet as mentioned, we have long argued that not just one advanced civilization capable of moving and cutting these incredibly monumental megalithic stones have been and gone, and we feel we have and continue to provide sufficient proof of these claims. The Colossae of Memnod, said to have once sang at sunrise, are both made of stones thousands of tons in weight, yet are eroding to dust along with countless others, yet clearly once precisely cut, just like all the other stone ruins we cover worldwide. Yet sites like Petra and the polygonal casing stones found in some most curious of places such as the Pyramids of Egypt, preserving stones in a similar condition to the Colossae. Certain stone monuments of gigantic size found and stored in near perfect condition are found in these same areas, as if somehow spared catastrophe. Does this prove a sudden great flood? They regardless, we claim, prove several cycles of activity at stone cutting creation. Were some monuments submerged and therefore preserved under the sediments, like those secretly removed from the Pyramids and Sphinx during initial investigations? Were they attacked by a geological event? The perfect preservation of some of these statues must eliminate sandware as a possibility. The pursuit to the answers to these questions become closer, and we feel highly compelling. The Dytan Rock, a 40-ton boulder in Massachusetts, USA, is a mysterious relic indeed. Not only does it not fit in with the surrounding environment, but the incredibly ancient inscriptions found upon it could unlock highly controversial truths regarding the reach of ancient civilization that would fly in the face of current academic theory. What is interesting regarding this enormous rock is that it was not only placed where it now lay by natural geologic activities many millennia ago, dropped where it lay on the shores of the Taunton River by the melting of an ancient glacier during the end of the last Ice Age, measuring 5 feet high, 9.5 feet wide, and 11 feet long, made of gray-brown, crystalline sandstone. But no one has been able to say with certainty who first rode upon the rock, what they wanted to communicate, or why they created these mysterious markings, with it now known to have been the inspiration for over 1,000 books and articles and the basis for over 35 hypotheses. The mystery, and indeed debate, regarding the writings on the Dayton Rock continue to this day. And a possible motivation for the mystery to remain unsolved is to protect the currently attested academic theories regarding the past of man, thus they could quite possibly be markings left by a past now lost civilization, or one that has long been claimed to have been unable to have had such far-reaching settlements. The antiquity of the writings is undoubtable, as many scientific investigations have proved that they are indeed very old. Yet what is hotly debated is the origins, and indeed the civilization responsible for creating them. Although predictably, since 1680, when Reverend John Danforth visited the rock, a mainstream academically-approved theory regarding the stone has been put forward and popularized by said institutions. However, the fact that the glyphs, or possible language etched upon the rock, has never been deciphered remains. After seeing it, he decided that the carvings on it were made by Native Americans, specifically the Wampanoag Indians, after being told the tale of a ship arriving, and a battle between the locals and mysterious newcomers were told to him, from long ago in the distant past. Danforth drew the symbols visible on the top half of the petroglyph, and then wrote, quote, It is reported from the tradition of the old Indians that there came a wooden house, with men of another country in it, swimming up the river Asanet, that fought the Indians and slew their sachin. Such interpreted the figures to be hieroglyphical, the first figure representing a ship without mast, and mere rack cast upon the shoals, the second representing a head of land, possibly a cape with a peninsula, end quote. Danforth's drawings were requested by the Royal Society of London in 1732, and are now preserved in the British Museum, this not only proof of their acceptance by mainstream academia, possibly due to its lack of any controversial claims, just a simple mention of newcomers, and no further mention of their possible identity. Yet the fact that these inscriptions remain undecipherable makes the possibility of the newcomers being from a locality nearby illogical, and suggests that they were, instead, created by a group who came from a now lost, or possibly concealed, advanced civilization. Another hypothesis put forward by Isra Stiles in 1767, while he was the president of Yale College, claimed that the famous seafarers, the Phoenicians, had made their way all the way to North America on at least one voyage. Stiles believed that the writings were left by them to simply show that they were once there. Stiles' idea was a popular one in Europe for some time, and were embraced by Antoine Court de Gebelien, a French scholar, as a possible answer to the identity of their creators. He said that the carvings on the rock should be split into three sections, the past, present, and future. Some of the images he identified were an oracle and butterfly, representing the future, a horse and a beaver meeting, symbolical representations of the two contents interacting in the present, and the divine figures or symbols of Minerva, Tullisfor, and Priapus, representative of the past. Yet the mystery of who created the carvings remains to this day. Additionally, the original location of the carvings also remains a mystery. The fact that the boulder has landed where it now lay due to geological activities means it could have originated in a location far away from where it now lay. Was it made by a now-lost civilization? Or possibly one that academia continues to claim was not able to travel such vast distances? The mystery surrounding the Dytan Rock continues, and it is undoubtedly one that is highly compelling.


I've been making a lot of stainless steel tools lately, as I live by the ocean and everything rusts. I think it's time to make some pliers. They don't need to be perfect, but good enough to be decent pair of pliers that I can accidentally drop in the ocean or get splashed with sea water, and don't worry about it. Now what style do I start with? I don't have time to whip up a forge right now, so I'm going to see what I can do. A couple steel rods and an angle grinder. Stainless steel rods. Start by carving a chunk out of each one. I'm going to be honest, I'm not doing the best job ever here, so I just want to see if it'll work. Sometimes when I'm doing stuff like this, I basically pretend this is the first pair of pliers that's ever been invented and I'm just going to make the most basic thing. And then I end up going through the evolution of pliers, just naturally. And I do that because I end up learning a lot of things along the way, as opposed to just copying something that's been made now, following some blueprints or something. Alright, so now I need to carve off enough material that this can twist like that. So that means taking off a section here, here, and the same thing on this one.  I can't start in the middle. I have to start all the way over there and take off that much. Because this part's going to have some of this missing. Yuck! God. It'll make sense in a minute, or ten. Unless, of course, my brain is lying to me, in which case they also make. No sense! Alright, getting there. The back's done. The back will slide together if the front's not in the way. Now the front, I have to cut off some of that and a little bit of that. I could just cut this all the way down. But I think I want to, yeah. So a little bit of trimming in there. That's not bad. Obviously I can use some, you know, prettiness increases. Tapering these down, curving some handles a little. Anyway, let's get them functional now. I just need to drill a hole through the pivot point and get a bolt in there. Phew! I had to sharpen my bit about twenty times to do it, but I got through that thing. Alright, that's a good sign. It means the steel is strong. It should be good for a tool. Alright, let's see what I've got here. Man, those are functional already. Not on there. I think I'll trim these down. It doesn't matter. It's just aesthetic stuff. Although I might want a needle nose them so I can get into things. And then the handles. I don't know. We curve them, carve some of this out. A little bit. Oh, right now they work. Well, I'll have to put a nut on there. Yeah, a nut. Tighten that on. I've only had some pliers. Ah! Ah! I'm not entirely sure what I want to do with these yet. I'm just going to stuff. I don't know. That's kind of cool. Get some lines in there for some grip in action. Space in here for grabbing nuts. Don't grab my nuts! Those are pretty good. I'm kind of presuming at some point I'm going to want to carve more off here and more off there and kind of whittle these down. But I'm just going to see how it goes. I don't really care that my pliers are heavy. I'm going to squeeze them mighty hard and they don't break! Which puts them already ahead of any modern pliers. Modern pliers, I squeeze them and they break. These suckers. I've had this metal out here outside for like two years. Not a speck of rust. That's a good sign. I guess I'll just keep these around. Make them my go-to pliers for a while and see how it goes. I'll probably want to shave this off at some point. Cut that off. I don't know. I'm just going to start using them. Make adjustments as I feel the need. Oh, it is kind of nice. Not having to worry about getting them wet. Oh, that is great.


Hey, so remember last week when my voice wasn't that well Yeah, it turns out that turn into a cough a sore throat and a fever and I sound like I'm going through puberty for once Even though I believe I haven't even gone through that but I'm sick So I don't really want to talk so much so today you're gonna get a different video don't take it seriously It's much fuckery and I hope you guys like it and leave a comment down below If you think these videos are better than my old ones because I think talking in a bedroom for like a good Hour is not healthy and this video actually move around I go places I don't stay inside this bedroom, so you're not gonna get this layout. Oh, and don't pay attention to the background This you'll see why in 30 seconds. All right, let's get started 100 I win. I'm so dead inside.


Oof, this was a hard one, but we made it. Dialogic 1.4 is out. This is the last big 1.0 update. From now on, the team and I will start working on Dialogic 2.0. Patches to bugs present on 1.4 will happen, but no new big features will be added. At least that's what we have planned. Before talking more about Dialogic 2, let's see what version 1.4 brings to the editor. The first thing you'll notice is how different the timeline editor looks like. I wasn't a fan of the blocky events, and they filled the screen too much, and they had too little information, so they had to go. The new simplified events are there to help you understand the flow of the branches better. The speech bubbles are used for the Dialogic, so it's easier to parse with your eyes and see where the content is. Many of the already existing events got improvements, but the biggest one is the character event. Previously, you had two different events, character join and character leave. They are now merged in the same event with an addition of the update option. You now have better control of the animations for your portraits, and we know this is something important for your games, so I hope this helps you improve your scenes. Join, leave or update have different animations, and if you want to add new ones, you can create them and add them to Dialogic using Animus Animation System. The text event has new commands. Signal, Pulse, Play and Envy. And if you want to randomize some repetitive conversations, you can make a list of words like this, and Dialogic will pick a random one each time. There are two new events that you can use to jump to specific parts of the timeline, the label event and the go-to event. The colon of the event now sends arguments instead of single arrays. If you were using it in one of your timelines, you will need to update the functions that you're calling. So if the function that you were calling was something like this, now it should be something like this, with as many arguments as you have in the event settings. We know how to display Timeline Button at the top of your Timeline Editor, which will create a scene with your timeline, so you can preview it without having to launch your entire game, so you can test independently and quicker. Outside of the timeline, you can set themes per character, specify hot kicks for choices, a new feature was added to enable a history love, and a few more quality of life improvements are in the settings menu and in the character editor. The change log is bigger, and you have a link in the description if you want to check the full list of updates. But now let's talk about the future and Dialogic too. The biggest problems on the last two updates were keeping backwards compatibility, and we believe that now is a good moment to start a new page in the Dialogic history and break everything that needs to be fixed. That means that you won't be able to update your projects from Dialogic 1 to Dialogic 2 that easily, but I believe it will be worth it. We can now rethink many aspects of how to structure the internal code of the plugin, now we have a better idea of what works and what doesn't, so moving forward we are not improvising anymore, we are building a tool that, if we get it right, you won't know this is there. Thank you very much for all your donations, support, pull requests, and general feedback with the project, it really means a lot to me and the team. See you soon!


Red Hat OpenShift Container Platform. Live from Boston, Massachusetts, it's theCUBE, covering Red Hat Summit 2017, brought to you by Red Hat. Welcome back to theCUBE's coverage. I'm Rebecca Knight, your host here with Stu Miniman. Our guest now is Andreas Benokratis. He is the Principal Product Manager at Ansible Red Hat Network Automation. Thanks so much, Andreas, for- Thanks for having me, appreciate it. This is your first time on the program. First time. We're going to- We're going to- Start a little bit with, you know, you're new to the company, relatively- Relatively. Networking guy by background. Give us a little bit about your background. Sure, I mean, I actually started at Red Hat in 2003, and I did about four or five jobs there for about 11 years, and then jumped, went to a startup named Cumulus Networks for about two years. Great crew, and then now I've been, now I'm at Ansible. Been there since about December. So working on the Network Automation use case for Ansible. All right, so networking has a little bit of coverage here. I mean, I remember, you know, it says something like the open daylight stuff I had. There were actually a couple of Red Hatters that I interviewed at one show, ended up forming a company that got bought by Docker. So, you know, there's definitely networking people, but maybe give us kind of a broad view of, you know, where networking fits and the stuff that you're working on specifically. Sure thing, I think it's interesting to point out that as everything started in the compute side and everything started getting disaggregated, the networking side has come along for the ride, per se. It's been a little bit behind, but when we talk about networking, a lot of people just think automatically of SDN. And we're actually trying to think a little bit lower level, so layer one, layer two, layer three, so switching, routing, firewalls, load balancers, all those things are still required in the data center. And when people started using Ansible, it started five years ago on the compute side, a lot of the people started saying, well, I need to run the whole rack. So, and I'm not a CCIE and I really don't know what to do there, but I've been thrown in to do something. I'm a cloud admin, you know the new title, right? So, I have to run the network, so what do I do? Like, I don't know anything about networking, I'm just trying to be good enough. Well, I know Ansible, so why don't I just treat switches like servers and just treat them like, like what I know? They just have a lot more interfaces, but they just treat it that way. So, a lot of the expertise came from the ground up from the open source model and say, this is the new use case. Yeah, well, JR River's the founder of Cumulus, it's like, well, networking could just be a Linux operating model, you know, extended to the network, which is always it's like, wait, it sounds like a company like Red Hat should be doing that kind of stuff. Exactly, it's interesting to see a bash prompt in the networking, right? So, it's familiar to a lot of people in the DevOps space, absolutely. So, it's a very rapidly changing time, as we know in the digital computing age. The theme of this conference is the power of the individual, celebrating that individual, the developer, empowering the developers to take risks, be able to fail, make changes, modify.  How do you work on creating that context that Jim Whitehurst talked about today? Yeah, I think it starts with the true empowerment. You have, the majority of the networking platforms are still proprietary and walled off gardens. They're black boxes, you can't really do much with them, but you still have the ability to SSH into them. You can still, you're familiar terms and concepts from the server side in the networking side. So, as long as you have SSH to the box and you know your CLI commands to make changes, you can utilize that in part of Ansible to generate larger abstractions to use the playbooks in order to build out your data center into, with the terms and the lexicon of YAML, like the language of Ansible, things that you already know and utilizing that and going further. All right, could you speak to us a little bit about the customers, you know, what's holding them back? How are you guys moving them forward to kind of the more agile development space? Yeah, our customers are mostly brownfield. They're trying to extend what they already have. They have all their gear, they have everything that they need, but they're trying to do things better. I don't find greenfield customers when it comes to the network side of the house. I mean, we've all got what I have and it's, you know, IT is always additive. So, I mean, that's got to be a challenge. It's a huge challenge. It's a huge challenge. I think from the network operators and the network engineers, a lot of them are saying, again, they're looking at their friends in the compute side and they can spin up VMs and provision hardware on instantaneously. But why does it have to take four to six weeks to provision to VLAN or get a VLAN added to a network switch?  So, a lot of the network engineers and operators saying, well, I think I could be as agile as you, so we can actually work together using a common framework, common language with Ansible and we can get things done and we can get all of this stuff I hate doing and we don't have to do that anymore. We can worry about more important things in our network, like designing the next big thing. If you want to do BGP, design your BGP infrastructure. You want to move from a layer two to a layer three or an SDN solution. So, I just love that.  You don't have to exactly. No, this is completely, we're not taking your job. We are augmenting what you already have. We're giving you more tools in your tool belt to do better at your job. And that's truly it. People can be smarter. So, if you want to add a VLAN, that can be a code snippet created by the Sysadmin. It can be in Git and then the network engineer can say, oh yeah, that looks good. And then I just say, no, submit. So, what we see today with some of the customers is, yeah, I want to automate. I really want to automate. And you say, great, let's automate. But then you start getting, you feel back the onion and you start seeing that, well, how are you managing your inventory? How are you managing your endpoints? And they're like, I have a spreadsheet.  But that working is scary for a lot. It's super scary. So, how do you break that down? You do what you can. You do it in small pieces. We're not trying to change the world. We're not trying to say, you're going to go 100% DevOps in the network. Do, start small.  If you want to change something really low risk, things you hate doing, just start small, low risk things. And then you could propagate that. And as you start getting confidence and you start getting the knowledge and the teams and everyone starts, everyone has to be bought in, by the way. This is not something you just go in and say, go do it. It has to, you have to have everyone on board. The entire organization. It can't be bottom up. It can't be top down. Everyone has to be on board. So when I talk to people in the networking space, risk is the number one thing they're worried about. They buy on risk, they build on risk. And the problem we have in the network, there are too many things that are manual. So if I'm typing in some 16 digit hexadecimal code, manually from a spreadsheet, copy and pasting, or gosh, yeah, things like that, there is the room for error is too high. So there's the things that we need to be able to automate so that we don't have somebody that's tired or just, wait, was that a one or an L or an I? You know, I don't know. So we understand that it actually should be able to, you know, reduce risk, increase security, all the things that the business is telling you. All of these networking vendors have virtual instances. You can do all your testing and deployment.  You can have your whole data center in virtual environment, if you want. So if you talk about lowering risk, instead of just copying and pasting, and oh, is that a slash 24 or a slash 16? Whoops, I mean, it looked right, but it was wrong. But did it go through test? It probably didn't.  So enabling the full DevOps cycle of continuous integration, so bringing in the same concepts that you have on the compute side, testing changes in a full cycle and then doing that. You talked about the importance of buy-in and also the difficulties of getting buy-in. How much of that is an impediment to the innovation process? But one of the things we've been talking about is can big companies innovate? What are the challenges that you see and how do you overcome them? That is the number one, that is the biggest issue right now in the networking space is getting buy-in. Whether it's someone who has done it on their own, someone can get in, someone can just install Ansible and do something and then deploy a switch. But if they leave the company and there's no remediation, if it's not in the MOP, if it's not in the method procedure, no one knows about it. So it has to be part of your, you want to keep all the things that you have, all the good things that you have today with your checks and balances in the networking and the CIOs and the people at the top have to understand you can keep all that stuff but you have to buy-in to the automation framework and everyone has to be on board to understand how it fits in in order to go from where you are today to where you want to be.  Well, I think the one thing is they're not used to seeing, they think it's black magic, they think it's just magic. They're like, I can use the same things for everything? I said, yeah, you can. The development processes, I think the innovation in the community, for example, if you wanted a Cisco ACI module, it's in GitHub, right, it's in Cisco's GitHub, you can just go ahead and do that and now we're starting to migrate those things into core. So the more that we get innovation in the community and that we have the vendors and the partners driving it and you're seeing that today, so we have F5 here, we have Cisco, we have Juniper, we have Avi, all those people, they have certified platforms with Ansible and Ansible Core which is going to be integrated with Ansible Tower. They have full buy-in from them. They want to meet with us and say, how can we do better? How can we innovate with you to drive the next-gen data centers with our products? You talked about yourself as a boomerang employee. I mean, what is the value in that? And are you seeing a lot of colleagues who are bouncing around and then coming back from? Absolutely, I think pre-acquisition Ansible, the vast majority of the people, I believe were X-ray headers that went to Ansible. So it's really nice to kind of come back home and understand the people that left that came back to understand already what the- And people feel that way, it's a coming home? It's a coming home, it really is. They understand, they came back, they understood the values of open source and the culture. Again, I started Redhead in 2003. I see the great things, I see new people getting hired and I see the same things I saw when I was in, back then, 2003, 2004, all the great things that people are doing in the culture. Jim's done a great job at keeping the culture, how it is, even way back then when it was only 400 people when I started. Anderson, to extend that culture, I think about the network community and open source and you talk about there's risk there and I grew up with enterprise infrastructure mentality. It's like, don't touch it, don't play with it. We always joked, it's like, I got everything there, really don't walk by it and definitely, some zip tie or duct tape's going to come apart. Are we getting better? Is networking embracing this? Yes, for sure. I think the nice thing is you start seeing these communities pop up. You're starting to see network operators and engineers, they've been, historically, if they don't know the answer, they won't go find it. They're kind of maybe shy, shy to ask for help, per se. If it wasn't on their certification, they didn't need to know it. Exactly, if it wasn't there, I'm not going to know. We're bringing them into, so we have, there's a Slack instance, there's, there are networking communities, networking automation communities just for network automation. And there's one, there's an Ansible channel on the network to code, Slack channel that has almost 800 people on it. So they're coming and now they have a place, they have a safe place to ask questions. They don't have to kind of guess or say, you know what, I'm not going to do that. Now they have a safe place for network engineers, for network engineers to get into the net DevOps space. Another one of the sort of the sub themes of this summit is people's data strategy and customers and vendors, how they're dealing with the massive amounts of data that their customers are generating. What is your data strategy and how are you using data? So, there's two aspects here, so the data can be the actual playbooks themselves, the actual, the golden master images, so you can pull configs from switches and you can store them and you can use them for continuous compliance. You can say, you know, someone, a rogue engineer might make a change, you know, configuration drift happens, but you need to be able to make those comparisons to the other versions. So we're utilizing things like Git, so your data strategy can be in the cloud, it can be similar on your side, you can do stash locally, so to actually, for part of the operations piece, you can use that. The second piece is log aggregation is a big piece of the Ansible, so when you actually want to make sure that a change happens, that it's been successful and that you want to ensure continuous compliance, all that data has to go somewhere, right? So you can utilize Ansible Tower as an aggregator, you can go off using integrations like Splunk and some other log aggregation connectors with Ansible Tower to help utilize your data strategy with the partners that are really the driving, the people that know data and data structures, so we can use them. And one of the other issues is the, building the confidence to make decisions with all the data. Are you working on that too with your team? Yes, we are working with that and that's part of the larger tower organization, so it goes beyond networking, so whatever networking gets, everyone else gets. So when we start developing Ansible Core in the community and Ansible Tower in-house, we think about networking and we think about Windows, that's a huge opportunity there. We're talking about AWS and the cloud, so cloud instances, these are all endpoints that Ansible can manage and it's not just networking, so we have to make sure that all of the pieces, all the endpoints can be managed directly, but everyone benefits from that, so. Andrea, thank you so much for your time, we appreciate it. Thanks again for having me. I'm Rebecca Knight for Stu Miniman, thank you very much for joining us, we'll be back after this.