You often hear that authenticity in music is what helps connect a song to a listener, but what does that mean? And why can no one explain that in a way that doesn't sound like the opening speech to a yoga class? In this video, I'm going to explain how authenticity works in making people love the songs you make yourself. Hi, I'm Jesse Canada. This is Museformation. Authenticity has always been what draws listeners into songs, but today it's even more important. As I make this video, we see reality TV stars, YouTube stars all on the rise, plus musicians who show their authentic vulnerable emotions were less scripted and polished than the musicians we used to see major labels promoting of yesteryear. The badly acted and plausible scenarios of TV have gone by the wayside to more realistic things. The public has responded to politicians who are perceived as authentic while those who are scripted are regularly derided for it.  The veil of covering how we feel with contrived polite PG rated versions of ourselves has been lifted back and there's no going back. Those in the public eye can no longer hide behind press releases or sanctioned interviews if they want to connect with an audience instead they need to go to social media and be honest and make real connections through relatability each day. The audience has grown callous to the fake facades of the past through the mass democratization of celebrity that's occurred throughout the world where gatekeepers have been thwarted by avenues such as YouTube that elevate authentic expression. Today authenticity is currency and you're able to spend it when you know how to communicate and the more you expose the more you're often rewarded. Music is pulling back that veil each year and the evidence is seen as lyrics get more and more honest. Instead of obscuring depression and drug use and lyrical code the nuance has been stripped away leaving no cover for songwriters to deny what everyone can see in plain sight. When Billie Eilish sings about underage sex or everybody's talking about drugs and cheating this was never able to be done ten years ago. Talk of drug use and depression graced the red carpet of the MTV VMAs instead of the everything's fine poses of yesteryear which would then be proved to be untrue just as our instincts told us when TMZ would show us what was really happening in the artist's life. What used to leak out in Rare Behind the Scenes expose is now front and center as the basis of what artists share to the world. We've all experienced a friend wearing clothes that don't fit who they are and they're trying to be something they're not. We sense that lack of authenticity as we stare with a questioning eye. Just the same when a song lacks authenticity in some ways pretending to be something they're not our bullshit meters have been honed to react poorly to the frauds that litter our world. When we hear an imitation of the elements of another song and we were like hey that rips that off it confirms a lack of authenticity in the artist we sensed innately. It clues us as listeners into that that act isn't expressing their own emotions by trying to gain fame through imitating something else that worked for someone else which was an authentic expression of their own emotions and now this person's trying to gain that for their own advantage. Since we're making the music we want to hear ourselves it's important to understand that when you hold back from your authentic expression it's less resonant inside of you as well. We have to remember you're your own first audience member which is why finding new ways to make music resonant within you is the only way it'll connect with others. A lack of authenticity is heard when a singer delivers a stale performance lacking resonance. One of the reasons we need to write from a place of vulnerability is because without it the singer won't have an emotion to express when they sing they'll just be hitting notes kind of wiflessly. By imitating someone else or trying to be like someone else that inauthenticity isn't focusing on translating what you feel in an emotion in music you're focused on copying someone else which has no emotional resonance except for the stale cringe that we all do when we see that. Callous artists I've heard including like jake bug talk about having to revisit the emotions they felt when they perform a song to give it resonance. This practice gets confusing though since singers can be singing in others writers lyrics and you're like hey is that authentic? We have to remember the only way a song is delivered with resonance is when the singer can find a way to connect with those lyrics and oftentimes the biggest singers in pop talk about how they felt a connection when they read the lyrics and all of a sudden they saw how they could express that song which is why oftentimes cover songs can work so much better when somebody else delivers in a different way than the artist initially thought of it. Vulnerability is what allows us to connect with others. There's a great Leo Christopher quote that I like to cite.  An important part of this equation is the importance of vulnerability. When we inaccurately portray our emotions we hinder our abilities to connect with others. Being able to say what you truly feel its full uncensored feeling allows that connection. Just as listeners can perceive when you're inauthentic, when you lack the ability to be vulnerable and say your actual truth it can be sense that you're not saying what you're really feeling in its entirety. You know when we talk about Prince it's often said that he was never able to be close with other people but he expressed what he was actually feeling in those songs and that's why they've affected the world so much. Writing about an emotion that's safe to express or not telling the whole truth of your feeling out of fear of others reactions hinders the ability to connect with others we're feeling the same as you. When we become vulnerable by sharing our truth without fear there's more to connect with by expressing the very real emotions that we're scared to communicate. For those who don't understand the power of vulnerability it's how we form deep connections with one another. When you talk with someone and hold back the truth it usually leads to small talk and a bullshit conversation that you forget in days but when you allow yourself to be vulnerable by saying the deeper truth with someone else that understands it that leads to great conversations that we remember our entire life and connections with people that really form and the same thing happens when you do that in a song.  To connect with listeners they must be able to empathize with the emotion you are expressing. The only way to make a listener feel emotional resonance and feel the song you've made is connecting with them and this connection is only made deeper when you bring vulnerability into your music. We can only connect with emotions we've had ourselves and the joy of connection is this understanding of each other. With vulnerability we allow ourselves to say an emotion that's relatable. How often have we heard a song and found the way someone expresses a really familiar emotion? With a new genius twist that emotionally just hits us so powerfully because the way they said it is so amazing and bulls us over. If you sing a song where you're hiding what you feel how is that going to resonate with anyone? This connection is why some songs don't resonate with some people yet resonate highly with others. The connection to a song is only formed if the listener understands the emotion that's conveyed. Friends can be puzzled when they love a song at their best friend who they connect with on so many levels doesn't understand that song. Most of the time that answer lies and that the person who doesn't feel it doesn't experience the emotion the way the song is conveying it. The tools the musician uses to express that emotion may not be the way a friend feels that emotion and that's what makes music. Since we don't all have the same experiences of feeling different colors of emotions as our friends our connections to the emotions expressed in songs won't always be the same. This is why being authentic and showing vulnerability by talking about your great deep truths is what has always been the greatest currency in music. When you really think about the artists you love and who have affected you and whose songs stay with you I guarantee you will find that they were being themselves and expressing the scariest truths and the biggest truths they had. They were finding the most deep emotions that they have and putting them into a song that feels the way those emotions do inside them. They were listening for sounds that made them feel the way they felt in that moment and that's what you need to do too. That's it. I hope if you enjoyed this video you click on my channel subscribe like this video and look at the playlist this is in since there's tons more videos like this. I also need to know your questions about what no one else is telling you. Since in future videos I'm going to answer it so please leave your questions in the comments. I hope you stay tuned to future videos and subscribe since I'm going to be breaking down concepts like this and how to promote your music and make music that you're happy with in future videos. As well I have a Facebook group that's linked below that is only helpful information. No one trying to sell you anything no playlist or con artists only artists having helpful discussions allowed. If you want to learn more about me make a record with me or check out any of my books podcasts or anything else I do please go to jessecanon.com or head to at jessecanon.com on all the socials see you in the next video


Hello, and welcome to yet another developer diary. So to this point, I've shown prototypes and explained a little bit of theory. But finally, finally, but finally, we actually get on to talking about what's been going on in the actual application code. And in this entry, I think I'm going to mostly concentrate on the server side. So firstly, I suppose I need to acknowledge that a lot of this code really came from Serma. If you've not seen our supercharged episode where he talked about server side rendering, definitely watch that. It was a live stream where he took about an hour or so and built a relatively straightforward handlebars based, express based, with caching headers, server side rendering thingy setup. And I guess, yeah, a lot of this is sort of the ideas anyway have been picked up from there about how to do some of the cachings and so on. And it was also Serma who told me about express sub apps or express apps that you can actually have lots of them. But more of that in a moment because, well, there's code to look at. So let's have a dive in and see what's there. So this is actually the server as it runs today, which largely involves getting a copy of Express, making an app to kind of wrap everything else. And I'm running all my stuff on the Flex containers in Google's App Engine. So what you can do there is you can boot up a container which runs Node. It's great. It's like that. And then it wraps it in the auto scaling, load balancing stuff. It's really, really quite handy for all of this. But it passes in the port as part of the environment variable. So we basically pick that up. And that's what we run on, whatever it tells us to run on. Beyond that, there's some middleware. And I'll come back to some of this in a moment. I have also got Passport enabled, which is a way to do a wharf if you need to do it. And I'm not sure if I'm going to or not, whether I'll have an admin area or whether I'll have a place where people can actually log in so they can see their own what they've rated or whatever. I'm not sure yet, but I've put it in here just for now in case I need it. But the interesting ones actually kick in below. So there is an app here for static. So anything that begins slash static, I hand off to this app, which is under apps statics. Let me have a quick look under there. And this is actually relatively straightforward, this one. It's basically going to call express dot static with a path and the ops. And the ops is that we want anything that comes from slash static to have an age of one year on it. So it will expire in one year, not a moment sooner, apparently. But that's the idea. We're going to say anything that begins slash static, grab it from there. In this case, it actually goes to the client folder, which is up here, and grabs it from there. Come back to that, I suspect, in a little bit. So anything that begins slash static, which is like images, the manifest, so on and so forth, go and grab those from there. The authentication one, I'm not going to get into that right now. That's the stuff that would use passport because I'm not sure if it's actually going to survive if I actually need it or not. There isn't a lot of point in me just showing that just yet. If I do do anything that requires it, I'll come back and explain that. It's mostly placeholder, which is the same with the admin. It's just me kind of testing the auth stuff. I'll tell you what, we'll jump over the service worker one and we'll come back to it in a bit. Most of the app is actually served through this dynamic one, this dynamic app. So let me show you around that a little bit. So this is not dissimilar to the static one, except it's way, way bigger. It's its own Express app, which I call dynamic. I'm using Adaro, Adaro. This is the problem with reading names online.   Glad we had this chat. Anyway, I'm using, I'm going to say Adaro, I think. And if it's wrong, oh well. And what that does is it wraps DustJS. So DustJS is an alternative to handlebars or .js, any of those, really. I wanted to give it a go because it supports promises and streams, as I understand it. So that you can, in theory at least, if you want to make your templates build an async. So if you need to do something which requires a little bit of async work, then you're not blocking forever while that happens. All the same, it seemed like an interesting thing to go and play with, so that's what I'm doing. In order to make it work in Node though, you need a wrapper around DustJS, and that's what Adaro is. Then we have a bunch of kind of setup stuff, really, which gets me things that I need about reading my video library, information about the videos that I've got, information about the actual package itself because I use things like the version number in the package, Jason, to stamp certain files to make sure that that all works. I have a bunch of helpers, which again, we can come back to, which are, they're helpers to help me with the templates that DustJS is gonna create. Finally, we have a little bit of setup here for the actual default view, like what the title is gonna be the page, what scripts we need, and so on. Then we step into the actual config of the engine where we can say, right, create a DustEngine, set up the views to use the view path, and also anything that comes from the dynamic side is gonna be HTML, and therefore, I don't want it to cache at all. So if you remember the stuff in slash static had a one-year expiry, stuff from dynamic, I want it to expire immediately. I never want it to be cached, because what we're gonna do, I call it cache and hash. You could do caching, grab, hashing, grab, caching, hashing, grab, any of the above, whatever you like, but I call it caching and hashing, and this is something that I definitely got from Surma, so we'll talk about that more in a moment, but the idea is, first of all, anything that's HTML, don't cache that. Anything that is from slash static, definitely cache that and cache it for a year. Right, so anything that's, let's talk about, well, this is one of the roots in it, the home page. We grab the default view options, we add in the things that we need to add specifically for that view, which is the featured video, which are the newest video, any things that we want in lines, like the JavaScript and the CSS, any particular scripts that we want to add to that, and then we finally just call dot render against it with the template that we've got, which is home, and that's it, it will basically render that out and send that back to the client. Works just great. Okay, let's talk more about the cache and hash stuff. The idea is that if you have an HTML file with paths to say the manifest or the JavaScript or the CSS, and any of those change, you need to flag that to the browser, because you've said anything that comes from slash static like your JavaScript, like your CSS, like your manifest, they should be cached for a year. So what you need to do is you need to do something probably to the file name, that's what most of us do. We put a revision into the file name so that you can cache that revision for a year, but if I change the HTML, or if I change the files, the HTML will get a new revision in there for that particular file. So let me show you what I actually mean. Let me bring up the browser, wrong browser. Let me switch across to the correct browser. So I'm running the site on 8080 at the moment. Ta-da. And let me show you, here's a great one here. Yeah, this is ideal, the manifest here. You can see that we've got this manifest. And then this long string here.json. Well, how are we doing that? Let me show you here. This is one of the middlewares that I mentioned earlier. Or is it a helper? Or is it a helper? It's a helper. Sorry, it's one of the helpers, which we've registered up here. This one here, a hash helper. What it does is it gets handed a path. And what it does, it opens up that file. You can see here, load the file contents, and then it creates a hash from the file contents, by making a shell 256, writing the file data in there and asking for a hex dump out the other side, which is 64 hexadecimal digits long. And we use that, and we replace the file name. So if it was, you can see here, let me actually bring, let me grab, let me show you this. La, la, la. In the header, there we are. This is what it actually looks like. So I said, look, get the dist client manifest.json. And it will grab that file, look at the file contents, create the hash for that. And then it will spit back out an updated path that looks like this. Blah, all that, there we are. Now that's good and it's bad. It's good because that means this is unique. So when the manifest changes, this hash will also change, brilliant. But it's also on slash static, which means that it'll be cached for a year. So that's all good. The only thing now is when we actually make the request, this file doesn't actually exist in slash static. I mean slash static manifest.json exists, but manifest.blah, all that.json doesn't exist. So what we have on the other side is a little bit of middleware that just simply removes the hash. If it gets given a request that has 64 hexadecimal characters right next to one another A to F, 0 to 9, then it replaces those with an empty string and then passes straight through. So it's a completely silent bit of middleware that just says if you get a URL with that long hexadecimal string, remove it. And we'll now ask for slash static slash manifest.json, which means we come back to the server, we've asked the file, we're gonna get whatever the server has as the most recent value. So that's a way of keeping that all up to date. Last little bit that I'm gonna show you on the server side today is around what I've been thinking and what I've been doing to do with the service worker. There was a service worker app that was dedicated just to the service worker. Fairly similar in some ways to the dynamic one, but all it does is it totally controls the service worker only. That's the only thing that it's actually interested in. So not dissimilar in terms of setup, we've got all the kind of Adaro stuff and we've got default dust options here and so on. But what we do is you see that I've got this package reader.get version and all that's doing is it's opening up the package.json, which is, it's currently set to 1.0.0. And inside here, inside, oh, I lost it. There it is. Inside here, you can see that I render this service worker template and I pass through version. So when we look over here at, I believe it's over here, no, that's the built version, I think. Oh, no, it's here. You can see that we have the curly braces version. So that means that if I want to bump the version of the whole site and I want to invalidate my service worker, I can do that just fine, because what I'll do is I'll bump the version in the package.json and I'll deploy a new version and then on the server side, we'll generate a new, well, that version number will be passed through to the service worker. So when we next request the service worker, we'll get 1.0.1, for example, that'll be byte different to 1.0.0 and then we'll run the whole install activate process. My means, I've used it before a bunch of times now, did it in Chrome Dev Summit, done it in, I think it was voice memos I did it in, possibly even guitar tuner as well. A bunch of the stuff that I've built is really convenient to just go bump the package version and then send that out and that will cause your service worker stuff to be updated. And the other thing that it also does, or it should do, yes it does, is it makes sure that my service worker is never cached. This is a super important thing. Even though technically, I guess this might, no it doesn't live in static. But even if Express wanted to cache the service worker for a day or a week, we really don't want that. Service workers, you really want them to cache for no amount of time. And the reason is we want to be sure that if we update our service worker, that we definitely come back, the people who are connecting to us, definitely come back and get it. As it happens, even if you set the service worker to cache for more than a day, the browser will always come back after one day. I believe that's in the spec. It does mean though that if you set the caching headers to be like a year, you're gonna have to wait at least a day before any changes you make to the service worker get passed down to anybody who's already got it installed. So strong recommendation for you there. Make sure that your service worker has some kind of no caching headers, very much like the HTML. So if you make a change, it can get deployed instantly as soon as somebody hits your site, they'll go, oh, I need to get a new service worker. And if they can, they'll download, activate and install and all the rest of it, your new service worker. So there you go. All the code, as I mentioned previously, is up on GitHub. I will link to it in the notes below. So that's the server side of things. Next up, I think we should have a little bit of a chat about maybe more video stuff because that is what we're building. Don't forget you can subscribe to the channel. Don't forget you can leave comments below. Loving reading all the comments. Thank you so much for all of those. It really does make all this worthwhile because it's so nice to kind of see what you think and also to get your questions as well. So if you've got questions, definitely pop those in and I'll try and either respond to them in line or in the next video that I record. Toodle-oo! Hey, folks, thanks for watching. Don't forget that there is more content that you can find kind of over here-ish. And if you want to subscribe, there's probably a button, oh, maybe there, maybe somewhere around there. Click that if you've not done that. Brilliant!


Good morning. Good morning. Good morning. Is it okay? Yeah. So we have like a minute more, about a minute, a minute longer, so I'm going to take that minute. Before I start, there is a talk in the Upper Room Digest Shop. It's a talk I intended to go to. So if you're interested, this would be a good time to switch. If you go there and tell Mark you're representing me also. Didn't convince anyone? Right.  And I didn't have time to submit it properly because I was told about it about 15 minutes ago. So the idea is that we have a lot of things that we do, a lot of technologies that we use and I wanted to make a list of recommended ones. Which one to favor over the other? And this is a talk I gave at Kluge PM in Romania a little while ago. Please do come in. Do come in. Faster. Faster. Alright. So, of course we all love parole. That's why we're here. It's fantastic. It's a great language. We enjoy it. We enjoy the community we build around it. It's our jobs. It's our toys. It's our fun and games and all the stuff that we do. And we really, really, really like TifffuckingToty, which is our slogan if there's more than what we do. Because with TifffuckingToty, basically we promote the idea of having multiple solutions to a single problem. And this is really good because different solutions provide different benefits. And this is, I think parole is one of the few languages that actually really promotes and is very proud of the idea of having more than one way to solve a problem. We really like that concept. We promote that concept heavily. And it's fantastic. We absolutely love it. But not always. And you probably know what I mean. See, sometimes when we have too many solutions to a given problem, having so many can lead to anger, frustration, financial damage, and in rare cases See, the problem with having multiple solutions other than their grade is that some of them are wrong. They're absolutely 100% wrong. Some of them are brilliant. They're amazing. They're the exact one that we should use. And the problem is that we need to know which one to pick. Right? Using them sometimes can be hard. Sometimes it's not they're all equal. Sometimes some of them are dead wrong.  But sometimes there is one that is exactly right and everything else is wrong. And we need to decide. And this is where the community comes in. Right? And probably count on conventions generated by the community to know which solutions we should pick. So let's start with some stuff. I'm going to start with Cpan.  Hosting code. Comprehensive pro-archive network. So it's a network of mirrors. And we want to search stuff on those mirrors and install things. To search we would usually use search Cpan or. Search Cpan or however is closed source. Which means that we can't really access it. It has very little integration with other services. And it's more of a memory muscle. When we're very much accustomed to go into search Cpan. It's not even a pretty new website. We're just really used to it. On the other hand we have Meta-Cpan. Meta-Cpan is open source. It is community based. It is community developed. And it has a lot of integration with various utilities and various tools and other services and other websites. Like where we host our code. Where we develop it versus where we upload it. And it has a lot of really nice tools to help us on our daily work with with our code. For example it allows us to see reverse dependencies. In the website itself. So if we search for a module we can see how many people actually use this module rather than what modules does it use. And then we can see oh a lot of people use it and some really serious things so I can count on it. And that's a very useful utility. There is a talk later on on the API of Meta-Cpan. It's going to be about Meta-Cpan API and Meta-Cpan client. Miki is giving that talk over there. So you should definitely attend that talk if you want to know more about what we can do with Meta-Cpan. Inheritance. So when it comes to inheritance how we build objects and link two classes together. So there's use-base. Everyone's used to use-base. It is old, unnecessarily complex. On the other hand we have use-parent. Use-parent is new. It's good. It's so new it's actually core since 510. How many people here use parent? How many people here use base over parent? Alright good. So hey check this out. You can just switch base for parent and it will work and it will be better. If you're using 510 and on you don't even have to install your inheritance. Objects. The thing with Objects in Pro and this is something that is hard to explain to someone until I found the right words for it. The thing with Objects in Pro is that well Pro 5 specifically is that Pro 05 really takes into account the underlying tenants of building a system. So we don't really have objects but it's something we need to build a system for Objects. And this is the weird part. People say there is no not exactly. We have what we need to build though. Because Pro always says I should at least give you the tools to build something yourself if not the exact product itself ready or ready. So Moose is the best way to write Objects in Pro. It is fantastic. It used to have much and you should definitely use it. However sometimes we can use Moose Moose is fantastic for processes that have to start and stop and start and stop often. Where you just have a very short life for the process and you want the loading to be as quick as you can. So you can use Moose. And Moose implements the majority of Moose except the middle layer. So it's two thirds. It's almost always all you need. Moose was created before Moose was written and the idea was to make it much faster which is why it's written in excess. The problem is that there's no interoperability at all between Moose and Mouse. If you have a role written in one and a class written in the other and you want to merge them, all help breaks loose. Moose on the other hand Moose on the other hand fakes everything that is required in order for Moose to think it's Moose as well. So they actually cooperate very nicely. So you can write a role in Moose and everything in Moose can use that too and it will work seamlessly. It's fantastic. So if you're using Mouse, stop it. Before we had that faking in Moose and we got the breakage of Mouse and Moose, someone wrote Any Moose. And Any Moose the idea was very simple. When the class loads instead of using Moose or using Mouse, use Any Moose and they can see Moose available in the memory. I'm just going to use Moose for your class. If I don't, I'm going to use Mouse and it's going to be very fast. But then you get, can someone point out the problem with this? Does anyone want to try? Has anyone used Any Moose? Just a quick question. Am I the only one? Seriously? Okay. So we have a race condition of loading order. So which module was loaded sooner? Did you by half instance load a module that Moose? Because now Moose is in the memory and now it's going to use Moose. You didn't oh, so it loaded Mouse. Now you're using it? That is still Moose now with classes. It's insane. Don't ever use that.  So don't like don't ever use that. It's not don't ever.  Is it most supposed to be compatible with Moose? Supposed to be is a really big term. Very big term. Enter YAML. That's all I'm going to say. Alright. Serialization. So when do we use serialization? Quickly XML. Never. If you ever have a choice, let it never be XML.  Okay. XML is the Java of serialization formats. Conversely, Java is the XML programming languages. The problem with XML is that it's written for a very specific purpose. Validation. No one does it. Except banks. No one ever. When's the last time you validated an XML schema? When was the last time you did this? About a year ago. About a year ago. Very very case. Usually it's not even then. It's insane.  And never programming XML. There's JSON. JSON is it's really built for the web. It's text-based. It's really good for configuration. It is your best default. It is very fast, easy to implement in serialization format. It's schema-less and it's fantastic. And then you have YAML. YAML is text-based. Also, it's very user-friendly until you actually get to a point where you have multiple layers and then spacing matters and throw Python. However, it's very useful for debugging. So if for example you want to debug a session that's going on, you can just print out the session data in YAML. It's very easy to read even though it's like just serialized in its function. So it's very useful for debugging. It can be used when you want to use it for user-friendly, for user fronting user-facing interfaces when it becomes too bloated and too big for YAML. And of course, if you're using binary, if you're working in binary, you should definitely know storeable. Storeable is our basic binary format. It is incompatible with pro versions, with storeable with itself, with the moon. It's horrible. There is, however, serial. Serial was written by Booking. It is insanely, insanely, insanely optimized and fast. It is compatible with different versions, different bits. It's fantastic. There's some really good bits to check out.  And it is so awesome that it's being moved to other languages. It's being ported. There is implementation in Go and I think other languages are working on it, too, because it is really, really good to really perform it. Moving on to user agents. So user agents, if anyone is familiar with that, basically allows you to have a browser without an actual browser. So you can make all the requests, you can understand all of it, and then you can work with that and you can scan websites to see if you can do that. The basic one is WP user agent. Who knows WP user agent? You can raise your hands. Fantastic. It's fantastic. It is very predictable. It is very stable. It's very useful. It's really, really, really good. And you should go ahead and keep using it. I should add mechanize. WP mechanize is a lot of nice wrapper around user agent. WP user agent. It gives you all the complexities of actually having a browser, like moving forward and back. It understands links, images, has objects for each one. It's really, really nice. You can just submit the third form with this user data. It's really nice and you don't have to do a post on it. It just does all that. So it's very good. It should be tiny. It should have as much as overhead. And it has fewer features, but it is mostly suitable for the tasks that we have. Or I should say it is suitable for most tasks that we have. So if you're striking websites, definitely use WP mechanize. If you're making htp requests, usually you should try htp tiny. Anywhere in between for other user agent doesn't use that much. But if you're using it, it's not that bad. Templates. Because, oh my god, templates. Who here has written their own template engine? Stop it. I did. Who here has written and then deprecated it? Right. So that's our templates. Let's start. HTML template. No. No. No.  Don't use it. Ever. Can it get an amen? Confirmed. Approved. HTML template sucks for a lot of things.   Don't use it. Mason.  It is php, but on acid. Which is not better. It's just, it's really bad, but it's much faster. It gets from zero to sucks way quicker. Mason basically says, I'm going to put the controller, the dispatcher, the model, the view. I'm going to put everything into the view.   So don't ever use Mason. Mason 2 was an attempt to fix it, but no one actually used it. Because people who use Mason usually are just stuck with it. That's why they use Mason 2. So they don't move to Mason 2. And it's not that big of a change in my view. There's some toolkit. It's a fantastic template system. It is really fast. It is comfortable. It is very useful for users. It's just simple to use. If you're giving it to a designer, HTML person, whatever, they can do it really easily. If you want to go nuts, you can use X-Lite. It is written in XS.  It is however batched crazy.  It's fantastic. Web, which is where passion goes to die. Web programming, there's so much to say about Web programming. So, so much. And I am going to talk later about our status with it. The thing with Web programming, really, there is only one thing I want to say. Are you still using CGI? Don't answer. I don't want to know. If you are still using CGI, this is the only thing I want to say. You should use PSGI. You really, really, really, really, really should use PSGI instead of CGI. There's a multitude of reasons, and I explained that very well in different talks. You can talk to me afterwards about this. And seriously, this really is the only thing I want to say about Web right now. Just use PSGI. And people sometimes say, really? Seriously? Seriously? I can't use CGI? Seriously? I go like, seriously? Don't. And of course, for the last few minutes I'm going to talk about threat signals, CPU, parallel execution. However, we don't have the time for it. So we are going to do it next time. Thank you. There is a moment for one question. I think you're giving a talk right now, aren't you? No. Still five minutes? Five minutes. Okay. That guy! What is PSGI? PSGI is doing the Web correctly. Basically, it's a different protocol that allows you to separate your application logic from your server in a really nice way and then allows some nice features like mounting different applications, different paths, multilevels of dispatching, middle of the web, and so on. There are many levels of dispatching, middleware to wrap your code in it. Ruby has RAP and Python has WSGI. We have PSGI. It's really fantastic. There's an entire protocol in this and your time limitation for this and most of the web frameworks, including actually Mason 2, support PSGI. So if you're looking at the answer, Modulicious, Catalyst, Amon 2, and so on, wrap them in whatever code you want. And it just works. It's fantastic. It's amazing. Yes? How do we tackle all those legacy, all same providers and so on? I mean, they need to move on in order that we can get... For what? Any of the things I said or just PSGI or just CGI? No, based on CGI, PSGI just wants some of those shadows and providers. You can wrap PSGI on CGI. So that means that you can take parts of your code and slowly transform it. We should have raised that migration path. That's what I'm trying to say. What is the migration path? It really depends on what situation you're in. It can take me longer to cover. I'm not asking for that. Conceptual version. Conceptual version? Everything that is deprecated or that you don't have to continue developing, you keep it fully layered underneath PSGI and new developments are done in PSGI. Anything that is a hot path that is very important you can rewrite in PSGI. That is... That would be my approach. I think that's more practical. I'm trying to get it. Perhaps. That sounds like a talk. May I... May I just take a talk at the next workshop? Actually, I've been trying to do that and I want... I can get it done with a complex application. Well, the complex application is not a very good application. Well, complex applications require complex solutions. And I don't know if in a minute I'll have a complex answer. Is that better? Well, you might consider refactoring me. Refactoring requires a lot of profit. And... last one. How many years will it take before you have consigned to PSGI? How many? How many years will it take before you have consigned to PSGI? It remains to be seen. But I'll run that by you as soon as I'm ready.


One of the questions I get a lot is George. How do I stand out in a crowded online marketplace? How do I become unique for my audience so that they'll want to keep watching my videos or reading my content, etc? Well, let me use the analogy of how would you stand out in a physical crowd?  I watch you. I enjoy what you say. Remember I said it's like a friend looking for you in a crowd Well in the online space, we're not trying to please everybody right in marketing.  You are already unique because nobody has lived Exactly your life. Nobody has exactly had the same experiences the same challenges the same Learnings the same conversations you've had for many years.  The more you become unique to her because the more she learns about you and vice versa So the takeaway message if you show up consistently Based on repetition and familiarity and based on exposure to your ideas and your personality You will become unique by doing that so care enough about your audience about your topic about the process of improving your your Connection with your audience by showing up love them enough to show up consistently. I hope this is helpful I'm George cow authentic business coach I love talking about creating authentic content and doing authentic marketing to grow your business and stabilize your income If you like this video, you'll probably like my other ones too, so I'll see you in the next video. Take care


the Huawei Watch 2 with LTE. So when you open it up, you take off the strap and then you can see there's an LTE SIM card slot. Whoa, that's cool. That has the longest battery life for an LTE smartwatch and the idea here is that you can use the same SIM card for two different devices. You can have the same phone number, same phone number on your phone and on your watch, sharing the same contract. I'm not sure how they're going to do that with the carriers, but that's the idea of this one. So you can be always connected. You don't need to have your phone. You can actually do everything only with the watch, potentially. So it has a LTE mode on. That's crazy. 21 days in this mode with the screen on. But not this bright, no? 21 days like bright like this? No, lower brightness. How to connect? When you change your wrist a little bit. 21 days standby. That's really long. Nice. You go in watch mode. That's very cool. LTE for 379 euros. You can add a SIM card in your watch and be always connected, go out for running. Is it waterproof? You can go in the water a little bit. It's splash proof at least. Resistance. But not for swimming. And the AMOLED 399, 390 x 390 AMOLED display is a Qualcomm CPU. It's not a high silicon chip. Qualcomm, I guess. Is it the same as before? It's a new one. So this quad core Qualcomm with LTE. Very cool. And there's many other functions with the Android Wear 2.0, right? They also added two buttons. So top button for something, this button button for back home. And this one is in menu. So you can choose whatever shortcut you like. If you want heart rate, if you want something else. And if you're on this one. And the apps are. The apps are smart.


Okay, let's start another talk. The topic of this talk is HPC VOD transcoding on OpenShift. This talk describes setup for publishing subscribe application, deployment model usage of Gluster for persistent volumes and challenges for such non-standard scenario. Presented by Frederiko Naibolo and Alessandro Arcello. Sorry. Quite good. Hi everyone. This will be a talk quite after the course because it is not a developer talk. It is the transposition of a demonstration. We run to a customer for a real use case of implementation of OpenShift and Gluster storage. I will ask you to leave for a while the head of developer and think about the implementation of Gluster or OpenShift from an enterprise perspective which is quite challenging on the social part, mostly on the social part. The agenda is quite simple because we will analyze the five WAs who were, what we did and when and why we did it as an enterprise customer experience. The first thing, the first W is who. He is Eric Alessandro. Yeah, I'm a platform consultant. I'm actually switching to solution architect team. I basically work on configuration management at customer side with for example PAP at Foreman Ansible Technologies and now I'm focusing on OpenShift, OpenStack, CloudForms and so on. So basically with Frederiko we are at customer side letting work also configuring our technologies for customer purposes. Yeah, and I'm here for that and I'm working on, I've been working for distributed calculus at CERN and INFM and now I'm working on OpenShift, OpenStack and Gluster architectures where this project was built. It was built in one of the, in the Italian branch of one of the largest European broadcasters, which has about 21 million subscribers and is expanding, it's online streaming and on demand market with 10 million connected customers. So it was quite a huge architecture. Just to say, just to look at which kind of data we are running through, this is a Gluster storage console and for example they have that sort of media content on Gluster, which is quite a huge size. So for example if you think about issues that can arise, that can rise in, on Gluster and you have a failure on some of the bricks and you're moving something like happened a couple of months ago. You have to move, you have to recover after a failure 40 terabyte of storage. Assuming the hypothetical 10 gigabit network you will take about nine hours to move the data from one place to another. So it is and you cannot use of course the 10 gigabit at all because the environment is on production itself. And in the meantime the customer is complaining about it. Yeah, that's a side effect of working on that data. So this is the target size. But what we are talking about in this talk is about an OpenShift application which is used for customer encoding workflow. Summarizing that application in a few lines as I reported in the slide. The broadcasting content coming from broadcasting signal requires encoding activities to encode the content for all the different devices and size and frame rate in order to be dispatched to the customers. And this is an application developed by external system integrators. So the integration of OpenShift in that environment as you will see briefly was not so simple. The workflow itself for encoding resemble a traditional job scheduler. So we will see in the next slide there's this patcher that takes segments which are media content from the broadcasting signal and transformed it and encoded it with standard FFMPEG or similar programs. So the job scheduler is something like a traditional master agent architect or maybe some of you work with some of those technologies. Those are the technologies I've been working with in the high energy physics calculus. And those are the standard schedulers used in the last years. For example, MOAB, Torque, which was formerly known as OpenPBS, which was an open source fork from PBS or LSF if you use the IBM commercial product or HTConder if you use the one developed by the California University. So this is a traditional job scheduler software installed on a single machine where there's a concept of a master. And the concept is that the job is run by a small portion of the application which is run on an agent. The agent waits for comments from the master, executes the jobs, which in our case is an encoding activity and then returns the exit code back to the master. This is another graph showing you, you can't see the number, but this is a graph taken from the Kibana interface of the job, of the encoding job running per hour. Each segment is a media content that has to be transcoded. And as you can see, the lines are quite similar in the input and in the output. Job are quite unpredictable because they're coming from the broadcasting signal, so we have no control on the sort of jobs that are coming and the rate. The overall workflow summarized in a graph is that broadcasting, broadcasting publishes a content signal acquired by a traditional graphic card. Then there's a legacy Microsoft app because the driver for this card is, it exists only for Microsoft, which is called WFM, which realizes streaming segment, which is usually an MP4 content. Then this content is transferred to the hyper dispatcher, which is a legacy Java application, which was out of the scope of our port into OpenShift, and this was one of the challenges we have to cope with, because we cannot move this part of the application itself. Usually when you work in OpenShift, you're putting most of the workflow inside OpenShift. This was not the case, and we'll see soon how we did it. That the dispatcher split the encoding jobs, put the content on storage, and send it to the hyper agent, which encoded the segment, and most importantly is profite-based so that there's a JSON which loads the profiles for the frame rate, and the dimension, and all the other parameters for the encoding. So we had some challenges to work on, because the dispatcher was not in scope of the porting of this application. We have to first demonstrate to the broadcast that OpenShift scale better than traditional VMs or traditional physical hardware, and we have to work with legacy physical nodes still working, and they are working still now, because we have to work in parallel. We could not port the whole application to OpenShift. On the other side, the advantages of this, well, the factor that simplified this application, this porting was that the node agent is quite simple. It's a Node.js application which publishes a REST API, and that the performance improvements were immediately tangible. So as soon as we deployed the first containers or the first pods, the performance increase was of an order of magnitude with respect to the traditional VMs. So this is just another focus, another slide focusing on the workflow just for the dispatcher. I think we can skip it. Okay, and now we have the architecture. We have to work in order to have a legacy application running within OpenShift and communicating both with single pods and with external entities like VMs. Yeah, as you can see, we have a list of OpenShift nodes. Basically, all the nodes you see on this slide can be scheduled by OpenShift for running containers. The last one is the one containing the broker that actually is the legacy application, and this node is part of the OpenShift cluster so it can actually access to OpenShift network and run the legacy application. With this trick, the legacy application can contact the internal container that actually when loads up, contact back the broker, and the broker itself will schedule new encoding on the registered client. Yeah, the main reason is that in a published subscriber architecture, the dispatcher has to contact every single pod as itself, and usually in OpenShift, you mask the pod under a router or a load balancer or something else, while in a published dispatcher activity, you cannot rely on this, and the dispatcher has to contact every single pod asking for idleness, asking for job status, et cetera. So it has to be part of the network of the agent themselves, and at the same time part of the other network for the traditional VMs. This is another representation of the nodes in our environment, so we have seven Apollo nodes, so with tons of gigabytes, gigabytes of thumbs, there's a graph in a success slide. Another important thing is actually the customer agreed to use physical nodes to unlock the real power for the encoding jobs. So unlike the standard way of putting OpenShift over another virtualized infrastructure, in this case, customer wanted to run it on bare metal. Yeah. Then we have a simple, this is mostly customer-based, we have to explain to the operation team how to work with OpenShift, which is usually goes on the other way as a developer usually works, because on OpenShift you usually run from build, build configs, then you build images on top of that, and then you can see at the end the final pods for the operation team, which usually is not involved into the build part, into the deployment part, but one just to see the running environment and see the logs and access to the traditional chest have to work on the other way around. So we started with them from the single pods where they can log in with OCE remote shell, they could see the logs, and then we explained later that they can run a deployment, which represents all the pods running, and they can scale the deployment adding and loading pods at will. And then as a successive step, we explained them that these pods, this deployment are run on image streams, which are provided with the agent software and the standard Node.js framework with all the libraries included, and then at the end we explained them how to build this image stream, this image and the image stream related running from the source code coming from the developer, so we have to treat the topics the other way around. We have the encoder agent deployment with the memory defined by system integrator, this was another successful ship because we were able to demonstrate that they are over-sizing their requirements for the memory needed, and they can do the manual scaling adding and variables, and you can see again that there are mainly, those are the most important environment variables because the single pod has to announce itself to the dispatcher when it starts, so that the dispatcher now knows that there is one more pod and can schedule jobs on it, and this announcement is done on the agent dispatch URL, and then there's the profile git from which the profile JSON is loaded, so that the developer can modify the profile, the encoding, the frame rate, et cetera, and this is loaded when the pod starts, then we have the image stream coming from Node.js application with the IP version git code, we deployed it on top of Opyshift which is quite common, and then there's a build and how we run the build with a standard source to image workflow. This is another of the five W's, so when we did it, we were able to run the whole process in just a little more than a month, which is quite short timeframe for an enterprise and for a project like that because if you think of all the MIDI contents that have to be streamed and the constraint for a production environment, and then we are constantly upgrading the environment, managing it, and the next step, for example, would be to put the dispatcher inside Opyshift itself, which was a thing we couldn't do at the first time because of the constraint for the system integrator and on the fact that it did not exist concept like Petset or Demonset in order to have a single instance of a pod running, or another thing we missed for example was the egress router in order for the dispatcher to contact from the same source IP address the agents which are not inside Opyshift. This is a summary of why we did it, and we see that now we have OpenShift with a lot of resources available and they are present as working, they reduce their development cycle. If you think that previously they have to dispatch a single VM on the month and this action lasts at least one day or two, now they can just scale the pods quite easily. We augmented the physical hardware density and so they are running more pods than VMs, and then they also avoid the technology lock in management because now with environment variables the customer can modify profile by himself while before it was bound to the system integrator to modify those values. The project involved also Glaster as I told you, and for example this is an extract of the export Glaster as a storage was an external project already in place, and here you can see that, yeah, where is the last line? In this case Glaster is exported as an external endpoint and all the agents can write the media content directly on the Glaster FS, on the Glaster FS, on the Glaster FS cluster so that the content is available to be presented by external origin server, which are mostly NGINX web servers. So thank you. Sorry, when? Okay, we run just the production building of the image with standard OC build config as you saw, and somewhere like. With the S2I? Yeah, it is an S2I source, we take the code from the system integrator and we provided the Node.js version which they required with all the libraries included. We also deployed a Git server on OpenShift itself, Gox. Yeah, we took the occasion for them to deploy also an internal Git, which I just closed, because I clicked on, I don't know, reopen, because remember that the system integrator is providing us obfuscated code, which of course they do not want to show us all the internals of the application, so we have an already parsed artifact to be deployed on the image itself, so we deployed that on Git and provide the ImageStream Node.js which is version 6.2, which the system integrator required, and the build config is run through OpenShift itself from the UI or from CommonLiner. Yeah, more or less, we're still trying to collect data correctly, because we have a Kibana, we have an elastic search environment, which is an external one managed by another team, and they're not providing correctly all the data to us, but the customer told us that the project could continue because they saw a huge improvement in their performance, but we still do not have physical data to provide you. Yeah, because for example, you see that now we are running 84 plots, which was a requirement by the system integrator, and they had less than 84 VMs before starting to show, so we translated the physical hardware, and we replaced that from VMware, we uninstalled it, we formatted it, and put that into OpenShift. Yeah, they have more, they have half of virtual machines. But now, just to answer, we just saw that the memory they require is quite huge for tasks, so now we can downsize the single plots and increase the size, the number of them, which was not possible with standard VMs. Okay, thank you very much, and as well do not forget to post your feedback and rating of this talk, and who would like to sign up for tomorrow lighting talks, please do that at the white table right behind this wall.


righty. So today was the Q2 stockholders call for Cedar Fair. And ultimately, there was a little bit of pretty good information in the stockholders call. It started off really bland and kind of boring, and they were very basic answers, like all the parks are doing well, blah, blah, blah. But the best part about Cedar Fair stockholders call is when you get to the question period. So a lot of the stockholders and the big businesses that are investing in Cedar Fair will, like Wells Fargo, will ask them more in-depth questions. So I'm going to go over a lot of information. There's some really good news for parks like Nottsbury Farm, Cedar Point, Kings Island, and Canada's Wonderland. So those are the four parks that keep getting honorable mentions in the stockholders call for 2019 season. And I have an actual dollar value that Cedar Fair is investing in the parks for 2019, or sorry, 2020. And that's going to tell a lot. So there's going to be a lot of videos that are going to come out from this stockholders call because a lot of juicy information. So to begin, I'm going to start off with my home park, Canada's Wonderland, because I'm biased. I'm kidding. But let's go over it quickly. I'm not going to go too in-depth because it's boring and no one cares about a hotel. Canada's Wonderland hotel has finally been green-lighted. It is going to start being constructed very shortly. They had a very difficult process in terms of getting the actual building process approved, the design and everything. I think they've had to go back and forth in redesigning the hotel here and there. It is one of Cedar Fair's biggest hotel projects. It's bigger than the Carolins one, but it's smaller than the Cedar Point one. But nonetheless, it's finally approved. It will begin construction almost right away. They said very shortly, Canada's Wonderland has had a really strong season. They're very excited for the Winterfest event, and it should contribute to about 25 extra calendar days for Cedar Fair in terms of boosting revenue. Outside of that, the parks that they're going to be focusing on in terms of 2020 investments mainly are the California parks and the East Coast parks. That tells you a lot. The big, big, big information from the stockholder's call is $140 million approximately is going to be invested into the 2020 season. $140 million was spent in 2019 that is excluding hotels, sport venues, and all those things. That is literally just enhancements, restaurants, attractions, and so forth. That was spent in 2019 and they said a very similar number would be invested in the 2020 season. That tells you a lot. In all honesty, that tells me another coaster outside of King's Island is coming. We're starting to hear that there might be an announcement at Canada's Wonderland before King's Island. I can't confirm that yet. We're hearing rumblings of an August 14 announcement for Canada's Wonderland, and again, it is not going to be a coaster. I'm not saying that at all. It is impossible for it to be a coaster. To be honest, I'm that confident it's not going to be a coaster. Any Wonderland fans in here who got excited there, I'm sorry. I'm expecting something like one of the smaller parks. I think one of the smaller parks is going to make an announcement. I think Cedar Point's got a really big expansion because $140 million is a lot and the King's Island gig is probably going to take up $30 million max if you're including epic theming. We'll see how that goes. I want to hear from you guys. Comment down below what you think. What do you think could honestly be coming for the 2020 season? I know that was a really quick wrap up of the stockholders call, but I thought I'd let you guys know because it was juicy information. Again, they're saying they're top four big parks. Canada's Wonderland, Notzbury Farm, Cedar Point, and King's Island were the top growth parks for 2019. That's really exciting. Hope you enjoyed this really quick update. I wanted to make it short because I know some people don't enjoy the stockholders call of things. I'll be making separate videos on the $140 million and what I think that could mean. Again, that does tell us a lot in terms of what Cedar Fair is looking to invest. It helps us figure out that there are more coasters coming to Cedar Fair in 2020. I would say there's probably one or maybe third smaller coaster for one of the smaller parks coming. We're starting to get some announcement dates for those parks as well. That's super exciting. I can't wait. It looks like it's going to be a great 2020 season. Six Flags looks like they're investing a lot of money too. You have those other parks in Europe and other parks outside of Cedar Fair and Six Flags that are announcing some pretty awesome stuff. I'm super excited for 2020 and it's looking really great. Again, hopefully you enjoyed this. Don't forget to hit the like button, subscribe if you haven't, and share this video for others to enjoy. Thanks so much for watching guys. Have a good one. Bye.


Good morning all. Welcome to the MSF Scientific Day. Sorry for the abrupt start, but I just wanted to remind you that actually this is not about a day where there's a few people in one centre in Europe talking about a few studies with a little bit of results, but this is a chance for MSF and a wider global community to talk about where we've done well and where we've fallen far short of what we should do in our programs. This is a day where we get to look at evidence that we've gathered within our programs and debate what it means for improving the work that we do and how we can bring more attention to the people and populations who have such great needs that continue to not be met, both medically and politically. We are going to be keeping quite strictly to time but there will be a lot of opportunity for debate. That debate will happen both in the auditorium but also with questions coming in from the online audience. We already had a photo sent in from Monash in Melbourne, Australia, where actually a group of people is sitting watching the event but they've gone to the effort of printing out all of the posters so that they can have their own experience of this day. But it's not just there we've had tweets coming in from the team in Pakistan. We also have this year not just one day but it's four days around innovation and research. So tomorrow's day you'll hear more about is the innovation day. Today is focused more on MSF scientific research but there's also our regional events happening in the next couple of weeks in southern African region and also in India because what we're looking for is a conference without borders where the results get debated and have an impact where they are most needed. I have a couple of housekeeping points. Firstly, if there happens to be a fire alarm I have to mention this for those in the auditorium it means heading out turning left and turning left as you come out here and gathering at Cavendish Square and we'll then be able to work out whether it's a real alert or what we need to do from there. For those on the online audience that's a chance perhaps to gather a coffee and follow the Twitter stream to see what's going on. Hopefully that won't happen. The toilets for those in the auditorium are in the central atrium down the stairs. Can I ask you during the day please to come back slightly early in the breaks. You'll have plenty of time for breaks and discussion but it's important that you come back on time so that we can stay on time. Last year we managed to have people watching from 115 countries. There was at least 5,200 unique logins to watch this event but that in and of itself those numbers don't mean anything if the research we do doesn't lead to impact and change and improvement and that's where I want us to be debating what we do today. For the first time this year we're trying live French translation so for those who prefer to follow online in French that will be available as well. It's now my great pleasure to hand over to Vicky Hawkins who's the Executive Director for Metres en Son Frontier in the UK office. Thank you Vicky. Thanks Phil and good morning everybody so I'm very happy to welcome you back here to the Royal Society of Medicine for the 2016 Scientific Day both to those in the auditorium and to our big online audience that Phil has already referred to. We've got a very stimulating agenda ahead and the format of the Scientific Day continues to develop in a really exciting way with forthcoming events in Delhi and Johannesburg over the next couple of weeks. I'm very pleased today that on the agenda we've also got colleagues from the IRC and from Alima and a big welcome to them and to those colleagues that are joining us from the academic community. Together we'll all be talking to you about our work and our research in Haiti, in Niger in Nigeria and in Europe to name just a few of the countries that we'll be referenced. We'll be learning lessons and applying those lessons to our ongoing medical work. But before we start today I'd like to focus your minds on a different list of countries. Syria, Yemen, Afghanistan Ukraine and South Sudan these are all countries that in the last 15 months MSF Run and MSF supported medical facilities have been either bombed or attacked. Over 80 staff, patients and caretakers have lost their lives in these attacks and there have been many more wounded and hundreds of thousands have lost access to medical care as a result. But these attacks of course are just the tip of the iceberg and I'm really looking forward to the keynote speech this afternoon from the head of the Syrian American Medical Society and we will hear him bear witness to the targeted attacks that are taking place again and again on medical facilities in Syria and the incredibly brave medics that continue their work at enormous cost. The attacks on these MSF facilities and the ones that we support not only represent the tip of the iceberg on attacks on medical facilities but they represent the tip of the iceberg in terms of attacks on civilian infrastructure. Marketplaces, schools refugee camps, there is no restraint. This complete lack of restraint makes it very difficult for organizations like mine to work directly in many of today's conflicts. So we're having to reinvent ourselves. I don't know how many of you were here three years ago and you heard Jennifer Leaning from Harvard University exhort us to rethink the way that we work in many of today's conflicts and we're having to do that particularly in Syria. It's not without its challenges though. So we also rely on people being able to reach us. We work on the periphery of conflicts and we wait for them to come to us but that also is becoming increasingly difficult. From the shores of the UK to the borders of Turkey and Jordan with Syria, borders are closed and millions of Syrians are trapped. We see boats being pushed away from the shores of Malaysia and Thailand and just recently an announcement that the oldest refugee camp in the world, Dadaab, is scheduled for closure, home to 250,000 Somalis. What voice can Europe raise in protest? A couple of weeks ago I stood in front of a group of 40 tech entrepreneurs who were all very excited about the innovation, the way that technology is being applied to help refugees in Europe and elsewhere. But the single thing I told them that they could do that had the most impact would be to raise their voice. The apps are great but we need them to speak out. They are a constituency that the government here in the UK that other European governments and around the world they're a constituency that government cares about. MSF is managing to work in one way or another and bring medical care to many of the places that I've just been talking about. But to do so we rely on two legal frameworks, that of international humanitarian law and the refugee convention. These legal frameworks are the cornerstone of humanitarian action, but they are under attack. We are speaking out about that but we need you to raise your voice as well. We cannot do this alone. In this room today there are constituencies that governments also care about. So please join us and speak up and speak out. Starting with today and we look forward to your lively participation in the debates to come. Enjoy it.


Beer brewed with yeast flown in space might not be super vintage, but it is really interesting. So that's what we're talking about today on The Vintage Space. The beer in question is called the ground control and it comes from the Nincasi Brewery in Eugene, Oregon. And what makes the beer interesting is the yeast. Yeast is a single-celled organism. It's a fungus and it metabolizes, grows and lives off of the ingredients that make up beer. It's also the most important ingredient in fermentation. Yeast metabolizes the sugar in beer and the bioproducts are alcohol and carbon dioxide. So it's the yeast that gives the beer its carbonation as well as its alcohol content. And the yeast can also seriously impact the flavor of a beer. So if you're gonna launch this living organism into space with the idea of using it to ferment your beer afterwards, you have to keep it safe. And that was a challenge facing Nincasi Brewing founder Jamie Floyd when he had the chance to launch yeast on a rocket. The opportunity came about socially. When Jamie crossed paths with Hybridine, an amateur rocket group seeking sponsorship to get one of their rockets off the ground. Nincasi became a sponsor and, in exchange for the funding, was granted some space on the rocket. Jamie decided that it would be more fun to actually launch something on that rocket as opposed to just watch it fly. And so he set out on yeast. But even a suborbital launch like the one Hybridine was proposing presents a lot of problems for living organisms. Even something as simple as yeast. There's a build-up of positive and negative G-forces, cold of the upper atmosphere and the scorching heat of re-entry, exposure to cosmic and solar radiation, and the pressure of changing altitudes. Add to that the fact that when you have a living payload you have a very short window in which to actually recover it before you can put it to use. To keep the yeast alive Nincasi developed a cube that held 16 vials of yeast surrounded by dry ice to protect it from the heat of re-entry. This payload was mounted in a rocket in July of 2014 and while it launched fine, it didn't land fine. The yeast casing was designed to protect it for about 8 to 12 hours but it took 27 days to actually recover the payload after it landed. Needless to say the yeast strains were dead. But Nincasi got a second try in October. This time the setup was a little bit simpler and only held 6 vials of yeast. The payload was also installed in the rocket at different points so it would be exposed to less of a big build-up of G-forces. This launch was a success. The 6 vials of yeast reached a peak altitude of 77.5 miles, well above the 50 mile marker where space formally begins. And the payload was easily recovered this time thanks to better tracking. The team was able to recover it, return it to Oregon, do lab tests to make sure it was safe before using it in ground control. Nincasi's idea is that eventually people will want to be drinking beer in space. I mean, after a long hard day of plowing the fields on Mars wouldn't you like to relax and unwind with a beer? For more about the beer brewed with yeast that has flown in space, check out the links below. And as always, leave your questions, comments, and any topics you'd like to see covered on future episodes in the comments below. For daily space-type content, a lot of it vintage, be sure to follow me on Twitter as AST Vintage Space. And with new episodes going up every single Tuesday and Friday, be sure to subscribe right here so you never miss an episode.


Formal minister of transportation Rotimi Ameichi, former chief of army staff, Lieutenant-General Tiku Buratai, Attorney-General of the Federation and Minister of Justice, Abubaka Malami, a senior advocate of Nigeria, among others, have declared support for the governorship candidate of the APC in Bochi state, Air Marshal Sadik Abubaka, who is retired now, and that's ahead of the March 11 governorship election in the state. The trial disclosed this at a fundraising dinner and the unveiling of the manifesto of the Bochi state APC governorship candidate in Abuja. Describing Abubaka as a visionary leader, Ameichi said that there was no other better choice for the people of Bochi state other than what the APC has presented to them. He called on the people to vote for the candidate that has proven integrity and transparency, particularly as it regards public funds. Vote for somebody who is disciplined enough to leave your money at home, at your purchase in your warehouse, who is contented with providing you with service, who realizes that Nigerians in every 10 Nigerians, 8 to 9 of them are poor, who thinks that the public office is for the people, who understands that if there are no people you will not govern. God has provided us somebody and that person is who? Sadik. When you have in place a person that supports the possibility of you going to bed in the night when you are too eyes closed, what else do you need? I believe the only justice that the people of Bochi can do unto themselves is to vote and vote massively. Vote was an exception. Sadik Abubaka and Sadik Abubaka. To protect your oil, you have the right person to protect the air machine, Sadik Kama Abubaka, is very fundamental. Just after the commissioning of the oil well, we had the story of bandits, criminals surrounding that area. Airbus, my share and my humble self, they fought the militants, the oil thieves and so on, the pirates on the high seas as well as in the creeks. Hello, hope you enjoyed the news. Please do subscribe to our YouTube channel and don't forget to hit the notification button so you get notified about fresh news updates.


I'm just going to move a little bit down the stage. I feel after all of those beautiful 30-second talks, a little bit superfluous. But I love the idea that Remy talked about Queen and the gentleman who's now, I don't know, talked about Creativity. Lyle Chan further talked about Creativity. We had the lady talk about the Joy Button. And I want to use all of those things because as we've been listening this afternoon to my wonderful colleagues in the first half, what keeps coming back time and time again is this idea of Creativity. And I believe I have the answer. I need you to listen. What do I need you to do? Listen. I often say that to children at the beginning of a concert. What is the most important thing we're going to do today? The goody-two shoes say we mustn't talk or others say we mustn't misbehave. But I keep going until I get the child who will say, we need to listen. Then I say, why do we need to listen? Finally, we'll get an answer so we can hear the music. I did a concert recently with a grade five, six, and seven class. And I started this concert by saying, so tell me what you might expect today. And this boy in the front row stood up and said, well, sir, we were here last year. You asked us a lot of questions about the music. We listened to the music and we answered the questions. I expect today we'll be the same. Thank you. And I could hear the orchestra laughing behind me. So I turned and I said, I hope the orchestra will be listening. Music for me occupies the top of the food chain in the arts. I have it on good authority, namely my own, but that's true. I know there are people who disagree with me, the dancers, the visual artists, the sculptors, the painters, the dramatists, but they are allowed to be in error. And the reason I believe it to be so is in the womb we can hear. When we are born, we respond to sound, the sound of the father, the sound of the mother, and so on. Then as we start to move, our listening becomes imperative. When we have music as a young child, things change with our focus. I want to treat you, if I may, like a preschool class. I'm going to clap a pattern.  You'll be surprised to know that that was wrong. I don't want to be discouraging, but I want you to listen. Here's my pattern, nearly. You're doing this, but I'm doing, I'm going to extend that, well done, Gindi. No, we're going to use knees, feet, and a bit of go-ya. I'm a quick learner, thank you, go-ya. Knees, feet, hands. Here we go, listen in. When we do that, we're remembering, we're remembering, concentrating, focusing, listening, and repeating, imitation. Imitation is a great way to learn music. Here's a text. My friend William is my friend William. And my friend William is my friend Bill. Don't look for meaning. And may I sit down, thank you, Richard. This is Richard, give Richard a clap. Here is the song of my friend William. Would you like to sing that song? Go, my friend William. Now, we had knees and feet. So how about we go, my friend William is my friend William, my friend William is my friend Bill and my friend William. Now, earlier today, I met a gentleman called Brian. Would you stand up, Brian?  And as I released him from the neck hold, he said, I agree. So we're going to see the song, my friend William, and when we're finished, Brian is going to improvise a clapping pattern which we will remember and repeat. Here we go. My and my friend is my friend William and my friend William is my friend Bill. Can you do that again, Brian? Stand and we repeat Brian's improvisation. And my friend William is my friend William, my friend William is my friend Bill. Have a seat. While this is going on, our brain is saying, thank you, thank you. I love the repetition. Wouldn't be wonderful if every child aided by the United Nations had access to music. Thank you.