Okay. Oh am I rolling? You're rolling baby. Okay. Hey YouTube shiver 1,000 here. All we're going to do today Got a couple Coca-Cola cans here Might come in handy for you guys down here in Florida.  So the first thing we're going to do is I got a two before here That's it two before here. I got that rat and foil because I had a pan on there trying this out earlier, but What I'm going to do is I'm going to use that as a guide and I got I've got a needle here the needle What you can use as a push pin, you know like you you know put papers on a bulletin board with you can use that or Attack or small mail. I don't have a push pin. So We got this needle. So that's what I'm going to do. So what I'm going to do It's two before so it's actually about an inch and three quarters So I'm going to put Can you see this thing? Let me move this foil back here We look like this so they can see I'm going to put this pin here And I'm going to put right up against this can All right And I'm going to hold the pin up against the can And I'm going to score that can all the way across there Is that picking it up? I'm going to go all the way around You can use a marker if you want, but we couldn't find a marker either. So Now I don't know if you can see that or not. Can you see it that score line do that on both these This is for people Because I understand people's got grills and stuff like that, but if it's storming out and it's windy and Try not to dent the can like I just did If it's windy out and storming and raining Well, you're not really going to be able to build a fire You know, you might be able to cook out with your grill in the uh in your garage or something like that, but This is For inside the house Because we've got all electric we've got electric stove and uh Just kind of straighten it out there see another score line now on the bottom here What you're going to do is take a penny And it's got to be 19 It's got to be older than 1983 So 82 and older will work because the in 83 they started putting more zinc in the pennies And these and the pennies will melt so you don't want it melting because this is going to be like a little valve Okay, what we're what I do Is just take you a pencil or something or Guess it whatever, but I'm just going to mark it here See that Just mark it that way you got an idea where you got to go with this There's a million of these youtube videos on here, but i'm i'm doing it to try to help people And you want to poke some holes now what what i'm doing because this is a needle It's hard to hold a pair of ice grips here. I'm just going to use them And you're going to put one in the center like this Now center when you want to make a little bigger Like maybe use a foul Maybe use a fork or something And then you're going to want to put four more holes in it. So you're going to want to have five all together two three and four Now now that that's done like I said make that that that center one a little bigger Will help now what you want to do I got a little pencil here But wherever these four holes are Like right from here to there Try to space them as evenly as you can if you got time you ain't got nothing to do your board I mean after all we're wherever i'm in a hurricane um The the better the spacing or you know the the closer you get the spacing apart on distance The better it'll work now. I'll poke those Put those in there In these four holes Just like this Okay, now what you're going to want to do is four holes you're going to want 16 all together So now in between those four holes there and so on Like I say the better you space them Now we have eight holes We want 16 that we go in between now in between every hole 16 holes Like I said if you measure them You get them pretty much dead on see those aren't evenly spaced, but it's okay It still will work fine Just a lot better if you space them evenly There you go. That's what you're going. Want 16 holes there Around the edge and five in the center there Okay Shit battery's gonna dead already. All right. I'll try to hurry. Does that have a pause on it? Okay.  I'm back. Now what we have here is we have this That we put the holes in the weapon And we have this one with no holes Now what I'm going to do is You just take your pair of pliers. I marked it on here with the pencil We kind of wondered about even take your pair of pliers Just kind of go like this all the way around it. It don't have to be perfect or anything This is going to be covered up And there's a reason for this is because the other part has to go on top of this So you want it to look like that Now what we're going to do One of these cotton balls Just grab a few of them And put them in there. You don't need a lot It just I find it gives you at least five more minutes of burn time Okay, so there you go. Now what you're going to want to do Take one with the holes in it And that's why I put the ridges. Can you see that? Not you the camera The That's why I put the ridges. So this goes on a lot easier. Okay So you just want to put that right over top of it If I'd have bent it more it would have been better The other one went right on.  All right. Well, the hurricane is not quite here yet No It did slow down, but they're expecting to pick back up there. Good to see. So now it's perfect. Now put it down flat Pop it down there. Now if you want Kind of take that and bend it over it will help hold it on And Like that You can roll it if you want just so it's not so short for you Like that. Now there you go It's gonna make it whole a little bit bigger in the center.  You know, that's gonna be almost Let's come over here Can you make it? I will try. All right Here we go. Now what we're gonna do I'm setting this here to clean market fuel. Now what we got That's 50% won't burn. Don't use it at least 75% Okay, but we got 91% because when he comes down to alcohol, we lock her up Really babe, that wasn't funny Now what I'm gonna do yeah fill this up That way I know when this is almost full that's gonna be almost full I remember don't go clear out because you got cotton balls in there. That's going to take up some space I'll take this Can you dump it in there? Can you see babe? Yep A little bit slower than that of course That takes a little time We should make that hole a little bit bigger right make it a little bit bigger Maybe if you got a skewer or an ale or whatever But make the center hole just a little bit bigger than the other ones Let's go Anyway Now let's keep filling Now we we did this earlier on the other one. Here's the other one.  Oh, yeah Now if you're doing this make sure you got a pan or something high pan cake pan And if you get some down in here, that's fine because when you light it, it'll help prime it And I'll show you that here in a minute too I mean you don't want to do it on your countertop, of course.  Get your parents permission. Get them to help you Because it is very dangerous. We should have a fire extinguisher here, but we don't Now let me grab the penny here Remember 1980 82 or older The penny here Couple more drops on there cover the hose up because that way you want a little pressure to build But you don't want a lot. So what that does is actually lift the penny When it has too much pressure, so it doesn't overflow Now light it That's a dog plan with Now light it. See like I said down there that'll help Prime that now I'm going to shed out the light so you can see what No Let's see Oh, you can see the light Oh, babe It's burning underneath that freaky thing Yeah All right. Well try to move that penny over Give it some air maybe But sometimes they're a little hard to start What it is is you got to get the can hot And that other one lift right up didn't you? Yeah, it is no problem You've got to get the can hot to turn the fuel that's inside here Into a gas We can do that So you know it's starting to burn once that can gets hot Like I said, it turns the fuel into a gas and it will come out them holes Oh, it's not thickening All right, you know, babe Sometimes it takes longer than other times, but be patient Keep going what I just did You'll know when it's ready Once them all the holes will have Flames coming out Now 13 minutes. We had this pan here We had this pan here very thick pan And I had two cups of water in it took 13 minutes to start for a rolling boil Right now I don't know why this keeps going out Yellow run It's not frying, huh? Use the other one see also That stuff called heat you put in cars dry gas the yellow in the yellow It's cheap. That's the best fuel for this I might not have had enough fuel. That'll be the best fuel for this Might have made that center hole too big But it need you wanted a little bit bigger. I might have went too big on the hole So I didn't mean to but it pushed in real quick on working now Yeah Like I said the center hole might have made too big on mine, but you wanted a little bit better than the other four that's around it You know, like I said, if you space them holes better and everything and also I made these They they usually go an inch maybe three quarters of an inch.  Hopefully that will help some people that need to um You know prepare for this like I said I mean, it'll work. It works good You know, there's the other one we have got Look at quite he's into his toy What did I do with the thing? I don't know. I didn't see you take it off. Is it still on there on the other side? I wonder why and that's clean burning burning inside, but plus we've got a van up here But anyway, we have got 400,000 490,000 total views on a little over 200 videos I think it's pretty good. I've been on for What I tell you seven years Yes. Oh, so anyway, what we're going to do When we hit half a million when we hit 500,000 views. Do you see me? Half a million views. We're going to have a giveaway All right Now we're just going to give away like a cheap gopro camera or something. It's fine A cheap gopro camera or something like that, but we're going to give you a little camera and What we're going to do is Write this down Shavebearer 437 At gmail.com. That's s-h-a-b-e-a-r 437 at gmail.com Send us Some information Where we can send the camera to what not And what we're going to do is everyone that we get we're going to put your names Uh and your channel name by the way too or whatever you want us to use on there Of course, we will not give out any personal information just your name or your channel name what not And we're going to put it in a fishbowl And we're going to have a little short Why to name and that will be the winner now We're not sure when that's going to happen yet, but as soon as we hit 500,000 views We'll and we're going to do this on a live feed too Um, we'll give you give you like a week in advance That way you can get your submit your your things. Uh, let me know that you're put um contest And headline so I know it's you and um, we're going to give give us something away to you And we'll get it out to you as soon as we draw the name But anyway, that's what we're going. So we're we're um having some fun here kind of I mean, it's it's not bad yet It's not going to get bad till about tomorrow So, um, but we're all we've got everything ready to go. We've got the car garage We've got the truck in front of the window to kind of help that So we've got all the outside furniture put away. So we should be ready to go. We are going to block home We've got some good hurricane straps up up in on, you know time the roof to the walls We should be good to go. I trust this roof You know about maybe 50 60 mile an hour winds Not the shingles of course, but the roof itself We should be okay. We're just mostly concerned about the trees around here now as long as the trees hold up The wind, you know We'll be blocked by some of these trees So we won't get real hit real hard with the wind We're more worried about a tree coming down if you all seen the video of the tree branch that fell through the roof of the car and It wasn't even stormy Um, but anyway, listen guys, we're going to get off here We want to upload this for you anyone that's down here with us and it's going to stick it out Be safe, man We don't want to see anyone hurt We're going to ride it out with you and Anyone else that watches us anywhere else, uh, you know Pray for us down here, you know, it's going it's going to get bad. So But we're in there. We got everything ready to go. We got power Uh inverters We've got batteries to run the inverters. So we're going to have lights We're going to have a little fan in case to get stuff in here We've got plenty of food plenty of water We're going to have several gallons of water With the water that we bought And we got a water purifier over here. I am filtering water right now as we speak So we're going to be good to go on that part if I can as long as the, uh Internet holds out Like I said, we've got the inverter if the internet's holding out. I can plug the uh the modem The internet do maybe some live feed for you But we're going to keep you guys updated and posted on what we're doing Throughout this whole thing through this all weekend. So, uh, we're going to get off here But there's how there's how you build, you know, you can cook on that like said, uh, last one mark for 20 minutes So, listen guys, thanks for watching. Again, stay safe Monkey anything I'm out You're out. Okay. With that being said, we love you guys. Shaber 1000. I'm gone


Hello my name is Jackie and welcome back to my channel. If you're new here I'm an aspiring fiction author and in this video I want to talk about plotting and more specifically the one big mistake I seem to make when I attempt to plot. Now to give you some background I'm currently working on my second new project since university so I did one new project for NaNoWriMo last year and I started another one in Camp NaNoWriMo this year and before I started each of these projects I did a plotting experiment where I tried three different plotting methods for a couple of different ideas and then worked on the one that had the most information at the end of the process. So last year I did take off your pants, save the cat and story engineering and this year I did story grid, snowflake method and the story clock and both experiences got me to the stage where I had a list of scenes for my book. I had the overall structure mapped out and I had I think last year I had maybe 18-20 scenes for the book that I was working on and before I started my current work in progress I had around 33 scenes so not complete I expected with both of them I would need a couple of scenes but I felt like I had a pretty good starting point until I started writing and would get to a scene where I had a post-it note or a line in the spreadsheet which had a one sentence description of the scene and I'd realize that beyond that sentence I had no idea what was going to happen in this scene so if I use my current project as an example the codename is reciprocal stalking and it's about a woman who becomes obsessed with another woman and tries to orchestrate an all-consuming relationship and I knew there was going to be a scene where she was sitting on a fire escape across the road from her beloved apartment and she was going to be spying on her through the window and I had that written down as a scene like sitting on fire escape spying on Kara and it wasn't until I started writing that I went wait a minute so I know that she's sitting there spying but what's she actually seeing and I realized I had these huge holes in what I thought was a fairly good overview of my book I knew Cecily was watching Kara but I had no idea what Kara was doing when Cecily was watching her and this has happened several times so I'm at another point now where she is luring Kara's boyfriend into an abandoned apartment where she's going to lock him up for a while just to get him out of the way and that's fine I've got him lured there but then I don't actually know what she does with him while he's there like did they talk and if so about what and it's really frustrating to feel like I did all of this work and I still feel completely clearless about how this book is going to go and there's still so much work to do in fact I did a video I think earlier this year about how do you know when you're done and the more I do this the more I'm realizing that I'm not actually done in fact I don't think I'll ever be done until the book is in print another example of this was with my book last year where it was an action book it was Superheroes meets the Russian mafia and I knew that there would be an epic battle scene for the climax and on my post-it when I was planning I just wrote like epic battle and obviously I knew I'd need to figure out what would happen in the battle but I sort of thought oh I'll figure that out when I get to that part of the book and then I got to that part of the book and I had no idea what was going to happen in this battle and I needed to map it out using like pepper grinders and vitamin bottles and so on so I think I have a couple of questions here one is how much should you expect to have done before you start writing the book assuming you're not going to completely pants it and if you're going to have like every single scene mapped out do you run the risk of burning yourself out before you start writing the book or do you run the risk of draining all of the joy from the writing process because you've essentially already done the writing process and you're just stringing it together and fleshing it out and finally what do you do when you start fleshing things out and you realize that the more you add the less the plot you'd mapped out works and you end up in this indecisive limbo because you're like well I need to figure out this scene but if this scene goes in the way I think it's going to go then everything after this in the book completely falls apart and I basically need to start again which could potentially happen to me at the moment because I'm thinking maybe I just get rid of this character in this sequence entirely but then there's a bit later when someone catches her burying the body which is important and if she doesn't capture him and if he's not a thing then there's no body to bury so it's complicated and it's actually defeated the purpose of me plotting because my goal with plotting was to have a complete outline of the book so that when I sat down to write I would know what to write I'd have something to guide me and hopefully that would make the writing process easier and smoother and I wouldn't be going down these dead end paths only to have to step back and unravel everything I've done to get back on track again. It's all very frustrating. So what do you think? If you've had a similar experience in plotting please let me know in the comments. I'd also be curious for if you've found a way to address this that doesn't involve me starting my book again so please let me know and if you like this video please give me big thumbs up and I will see you next time. Bye!


December 1st, do I have all of the scripts? No. I have nine scripts right now but I need to film this so I'm hoping that door number one will have the scene I have already printed because I have five printed eight or nine chosen. Holiday in Santa Fe. This movie is a movie I actually just watched, a Hallmark movie. We're starting off strong with the Hallmark movie but it is a scene. I only have one monologue in there so far so I need to find a reader for this. I might actually have less than 15 minutes today to get ready for this because I don't have a reader here at my house and so I had to go onto an app. I've used this before as a reader but I don't know that I've used it to get a reader. Anyways it's called actor trade and the person that's available to help me is available at two and it's 156 so I'm sending her the slides. I mean the sides. Oh my gosh, hold on. I need to concentrate. Yeah this is a pretty I think cheesy scene where the magic of like Santa Fe is supposed to, she's supposed to like be taking it in but maybe not quite convinced yet. Like in the whole movie she starts off, no she starts off pretty positive like wanting to like buy this shop so I think just like a little bit magical and just reacting to the mom, like mom-daughter relationship because there's definitely a lot of those in hallmark movies. Some of my doors keep opening up. It's a good thing this scene is very very short. It's about 20-30 seconds and I only have a few lines so I'm going to try my best to memorize it because I don't have this printed and I don't really have time to write it down either so. One will be I love my mom. I'm here to buy the shop and make the shop better and then the other one will be I'm annoyed by my mom. I don't even want to go home for Christmas and I just want to buy the shop to make it more corporate. Those are two strong positions that I can take and I can make each one a bit different. It's 202, I'm already late but we're messaging to figure out how to do this. We might just do it on my laptop which would be fine. I think we might just do it through Facebook because for this app you can message on Facebook to find different readers and then you can move into the app or zoom or whatever you want. Of course the app is recommended so that it can all be more streamlined but I think we're going to do a video on here. Hello oh let me see okay I need to give it permission okay hi then can I put this here without breaking anything yeah and I'm doing this like I'm I'm doing this self-tape practice because in this um oh in this one I need a prop phone and I'm filming with this phone so let me go grab a dead phone. So all of the practices I'm doing are um Christmas movies and this one's Holiday in Santa Fe have you watched it before? The business girl so that's essentially what I am. I'm like the business girl who's coming into town to buy a small shop.   That felt good yeah a nice couple of different takes thank you so much bye I did my first self-tape okay she was really sweet super nice and because it was such a short scene me typing it this morning plus reading it a couple of times and I had I had the script on the laptop I would just like glance over but I did my two takes I like really really really need to find my other scripts because who knows what's in number two it could be a really long scene and then I couldn't do this I'm gonna see if I can get a friend to be a reader or at least plan these out a little bit better so like every day at blank o'clock I can go on to the app and be like hey does anybody want to help me at this time this can be a little bit more organized and I actually have 15 minutes to prepare because today it was like seconds to prepare minutes minutes I'm being exaggerating but here are my two takes let me show you the two takes since they're pretty short honey are you gonna make it back for Christmas? yes I'll only be a couple days you know Ruben from next door he's retired and he's going all out he's seen his life to Christmas music and then his father is trying to outdo him how can dad compete with that? Belinda he is going 12 days of Christmas every day he has more long decorations where are you again? Stan and Fay okay sweetie bye bye mom see you on Christmas honey are you gonna make it back for Christmas? yes I'll only be a couple days you know Ruben from next door he's retired and he's going all out he's seen his life to Christmas music and now his father is trying to outdo him how can dad compete with that? Belinda he's going 12 days of Christmas every day he has more long decorations where are you again? Stan and Fay okay sweetie bye bye mom see you on Christmas I had to move the advent calendar so that I could prop up the laptop um here and like look at her a little bit closer but please keep opening up um I am going actually tonight to a dinner with brave maker maybe you guys should you want to come you should come along you want to come with me before I go get ready I want to tell you this if you have an old phone that like you're not going to sell doesn't work or whatever keep it keep the old phone because you're going to need it for software auditions


Started here, we're still filtering in a little bit. So, I'm talking a little bit about sort of reducing deployment friction, how the release process works to make that happen. My name's Andy Delcombe, it's not phonetic, it does rhyme with welcome. This might be one of the few cities that that's not necessary to say, but probably still is. I'm a Delcombe on Twitter, on GitHub, on Flickr, et cetera, most places on the internet. You can find me there. And I work for Engine Yard, so I work on the Engine Yard cloud products. We host mostly Ruby and Rails applications on EC2, on the cloud, and we also have a managed hosting offering as well. I work on the cloud team, but I also work largely on internal projects, so things for sales, finance, support, et cetera, but also the engineering team, and this is a lot about what I've been working on with regards to the engineering team tooling. I live and work in San Francisco. It's a beautiful city.  This is from near my apartment. So the subtitle of my talk that I submitted is reducing deployment friction, and as I was sort of developing this talk, I was realizing that the deployment bit is not, is only part of the story. It's not really just about deployment friction. It's about development friction as a whole. It's not just about the final step of deploying the code, but it's about how you get there from all the way from writing the code to merging it, to getting it out, to testing it, et cetera, all of these things. So the whole process, to reduce friction in that to ease the transition or to ease getting code into production, basically. So again, like I said, I work at engineered, and this is basically how we do it at engineered, and the point of this talk isn't so much that you should do it like this. It's more about defining the process, discovering the process that you have, and then automating it that way. However you do it can be done faster and better with less friction. So the first thing that you might do when you're sort of ready to start working on a task is file a ticket, at least an engineering yard. Everything has to have a ticket to be able to be worked on. There's a few exceptions, but in general, you have to have a ticket before you start working on things. We use a ticketing system called U-Track. How many of you guys have even heard of U-Track? I really like it. I had never heard of it until I started investigating ticketing systems. It's pretty good, it's very flexible. It's kind of enterprisey, it's a big Java thing, but it's really snappy, it has a good search interface. If you are looking for a ticketing system, I would recommend looking at it. So this is a sample ticket that you can kind of track through this process. The important things to note here are on that left side there, all of those columns are all of those fields. Every single one of those is customizable, completely customizable, you can add more custom ones, you can remove any ones you don't like, you can customize all of the states in those fields, the options in those fields. It's very flexible. And the other thing to note is that there's that links section there. It says this one is required for another ticket. We use this really heavily to associate tickets together. So there's both bi-directional links like relates to where just things are related. Things like this where it's one directional. So this is required for another one. If you look at the other ticket it would say it depends on this ticket. And we use this a lot for what we call roadmap tickets. So we have a high level roadmap ticket that we schedule as far as bigger features and then all of the other tickets are related to that one. So you can look at that roadmap ticket and see what all the tickets that are associated with it are and how many of them are complete or whatever. So when you're starting a ticket, the first thing you do is just assign it to yourself. Nothing else needs to happen. You don't need to change the state or anything like that, just assign it to yourself. So then, now that we have the ticket assigned to ourselves and we're ready to start working on the ticket, we use get, of course. And we always check out the branch name and the branch name is the same as the ticket ID. So this allows us to see what's being worked on very easily. So when commits come in on a branch or when you're looking in CI and you see a list of the branches that are in there, you can always see which tickets are being worked on. Similarly, when you commit code, we always tag the commit with the ticket ID. So this allows you to, when you're looking through get history or if you do get blame, something like that, you can see both the commit that was related to that and see sort of what you fixed and also go back and look at the ticket and see why it was a problem in the first place. A lot of times it's not very clear from the commit message. So another thing that we do at Engineering almost exclusively is we pair. We try and aim for 100% of the time. We usually get about 80% coverage of pairing, maybe a little bit more. We use this so-called TET on TET pairing setup that Josh Schuster sort of came up with and blogged about at Pivotal. This is Josh on the front there, back to you. It's really good. We've been using it pretty frequently. Pretty much all of our pairing setups are like this now. So the two displays are mirrored and so both people are looking at the same thing but you're sort of square in front of a computer. It's easier to avoid distractions and you can also look at the person that you're pairing with in the face. You can have more conversations about it and still be focused on the computer.  It's more fluid. It works really well. We liked it a lot. So we don't do very much, we don't really do any formal code review because we do almost all pairing. There's a handful of things that we kind of do code reviews on if somebody's not pairing for a little while but we kind of do that ad hoc. We don't actually have a system set up for that. So the other thing we do, obviously, everyone here should probably know this, we always test drive our code. Probably don't need to sell anyone on this but the point here I'm trying to make is that we run just the focus specs locally. So when we're developing we'll write new specs, run those specs, make sure they're red and then write the code, watch them go green, normal test driving stuff but we don't ever run the full suite locally and we always depend on CI for that. The full suite takes too long to run locally for it to be efficient to do so typically we're just running cycles around the one file or one set of specs that we're running on locally, push the whole thing to CI. So we push to CI for the full run, we push to the branch. This is our CI system. It's something we wrote in-house. It's called Ensemble. And this is sort of an example of how this might work. Kind of ignore that first one where something went wrong but that second one I pushed code, it was, I fixed a few specs before I pushed but I knew that there would be more. I pushed up to CI, let's CI run. I found all the failures that had happened in CI and I fixed them and then I pushed again and then it was green and I was ready to merge. So all of the, all branches are automatically built. Happens via GitHub Post Receive as a sort of typical for a CI system. They all get brought in there automatically. We have a bunch of different views where you can look at just a single branch or a single application or all the builds total. The other interesting thing here is that we shard our test set up in CI. So there's all those little dots, each one of those is a shard. We shard by file, each set of files goes to one shard and there's currently I think 28 units. And this makes our test suite take between about 12 and 20 minutes depending on how many things are currently running. So it's not too bad right now. If we didn't have it sharded, I don't actually know how long it would take but it would take a long time. So we have a pretty good test suite though. So it covers a lot of things. And I would much rather have a slightly slower test suite that was actually testing stuff than fast tests that didn't do anything. We also have a rebalancer. So we try and keep each unit to be the same length. So it runs all the spec files individually, calculates the length of them and then spreads them out across the files or across the shards. The last thing to note here is that you'll notice that the red lines or the red builds have striked through and the little dots are X's when they're red and circles when they're green. This is because my boss, Tamar, is colorblind and you can't tell the difference between the red and the green which is not something you might think about. And so when you're writing the CI system, if you're ever writing a UI for it, you should probably keep in mind that red and green are really poor choices to use for colorblind people. So now he can see when we break the code. So this UI is almost entirely read only. There's a few sort of settings that you can change on the left there but all of the CI system and all the actions you might take, none of that happens here and we have this whole other user interface that we use for our CI system that's all via Campfire. So this is our bots channel. It's not, you're not supposed to read it all, but this is basically, we have a robots channel that all the notifications come into and then we can talk to the bot in to have it do things for us. So all real interaction of Ensemble is through Campfire. We get notifications in there and then we can take some actions. So here, the black text kind of at the top, it's Larry, one of my coworkers rebuilding one of our apps master branch because it had gone red for some mysterious reason or another. So he was able to rebuild that branch. Rebuilding is interesting because it only rebuilds the red unit. So if something goes wrong just in one of the units or something, you don't have to rebuild all 28 which is really handy sometimes. It doesn't happen very often but it does happen. You can also deploy from this which we'll talk about more later. So we have this bot and it's a pretty good framework. It's called the UI Bot, it's not very creative. So the core piece of the bot itself is actually really simple. It's just this event driven chat thing that basically talks to Campfire and IRC and proxies the messages back and forth. And all of the logic that happens that for the bot to do all happens via webhooks. So when a message comes in to UI bot it sends it out to all the webhooks on the backend and they can take actions based on that. So things like rebuild and then if you wanna talk back to it there's an API that you can hit on the bot that will actually send the message to ensemble as well or to Campfire as well. So ensemble it doesn't really talk to the bot. It has this bot component in it that talks back and forth with the Campfire and IRC stuff. So it works pretty well. We have a bunch of these endpoints. This is kind of an example when we have this library. So this is an entire bot endpoint. Basically if you wrote this code, ran it somewhere and then pointed that config to point to it as one of the backends you would basically be able to see UI bot ping and it would respond with hello world. So it's just a rack app. You run it as a rack app. Every time it gets a new message it creates this message object which has multiple methods on it. Body and from into what channel it was in and things like that. And then you can also have respond with the message.say command. So we do this fairly frequently. This is sort of our normal setup where we case on the message body for different actions. Each app usually handles multiple commands. Sometimes it's only one but most of the time it's multiple and then we take actions in each of the apps to do that. It works really well for us. So some of the, we have a bunch of endpoints like I said and many of those endpoints handle multiple things. So we hear sort of a handful of the endpoints that we use. This is the notifications that come from Ensembl. This is a code push and then the build notification that it started building and then the build notification that it was green. These all come directly from Ensembl. This is an alert that happened for one of our customers. Something went strange, crossed on threshold for one of our customers. This happens in the support channel. Film Prague is Tyler. He's one of our support guys and I was telling him to go look at the admin interface for the alerts to see what was actually wrong. This is one that we have for U-Track. So every time a new triage ticket comes in, we have a bucket called triage that all tickets from the company come into so that way we can kind of look at them as engineers and put them in the right place. So every time a new one comes in, we have this go into our fireman channel so people can look at it and know where to put it. We also have some more fun things. You might have seen some of these and if you've seen a GitHub presentation before about their bot. So we have image me, of course, they have image me. You basically tell it to look for something and it'll do a Google image search and return you a random image. And we also have Instagram integration. So if anybody sort of in the company posts an Instagram and it'll go directly into Campfire, which is actually really fun for sort of community building, team building stuff. So after that aside about UI bot, we were talking about continuous integration. So I kind of talked a little bit about our CI system abstractly, but I didn't really talk about how we actually build the code. So a CI system is kind of, it's really simple. There's not very much to it to me personally. There's a lot of projects out there and we wrote our own. So a CI system is really just a job runner. All it's doing is basically executing code, storing the output and returning the result to that command. That's all it does. All the other interesting stuff is kind of the integration around that and what you do with that information once you have it. So it's not really very hard. It's not, even if you write it from scratch, we wrote it from scratch, the actual piece that builds the code and returns the results is the really simple part of that. It's not really interesting. You can't really do anything with it unless you write the code around it to do all of the integrations with it. But those integrations are interesting. So things like the stuff that we have with Ensembl where we get those building units and keep track of it all, show the red and green status. All that stuff's interesting. Most CI systems provide that. But there's also other interesting things. So this is one example. So this is trying to deploy to production our main code base. And it says we can't because the branch is not green. So this can be common. You could do this in your deploy system to prevent this. But this is all integrated, right? So it's all one system and it just won't let you, that there's only one system. It basically looks at the latest branch when it tries to tag it and says, oh, this is not green because it knows it's already in there. Our CI system is called NISM. Or the CI system, the job ringer, really. It's not the CI system. CI system is sort of the whole thing. But it's just built on top of rescue. It's basically one endpoint, one rack endpoint. You post to it. Ensembl gives it a callback URL. NISM builds the job, runs the command, gets the output, returns the status, hits that callback URL. And Ensembl then knows about it. It's really, really simple. Ensembl keeps track of everything. Mason doesn't know anything about whether what kind of job this is, whether it's a building in it or not. Yeah. Ensembl keeps track of all that stuff. Mason just runs the jobs. So now that our branch is green, we push it to CI. Now what do we do? The obvious answer is we merge it to master, right? So merge to master. If this matte merge ends up being a fast forward merge, like if you've rebased, then if the SHA is the same, basically, Ensembl knows to not rebuild that. It knows that it's the same code and so it won't rebuild it and it'll just mark it as green already. Second, you mark the ticket as merged. This is the important piece for the integration steps. Automation will use this later in the process. So it's important to mark it as merged for the release notes and things like that. Finally, when we push to master, we have what we call edge. It's always running whatever's green on top of master. So we basically do continuous deployment to our staging server or our edge server. It's really handy for testing. So if you're pushing something out that maybe you want to give one last pair of eyes on in before pushing it to actually production, just something that, yeah. You know it works, but you want to make sure that in production it'll look right. You can let it deploy to edge, check it and then before you deploy to production. So finally, now that we have it merged, the obvious answer is we ship it, right? We always get code out fast. Nothing sits on master. We always deploy code as soon as we merge it. We don't ever wait for someone else to deploy. There's no deployed day or anything like that. We want, this is sort of the whole point of this talk is that we want to make it as frictionless as possible so that way at all times, as soon as you merge it, whenever you merge it, you deploy it immediately. So, it's not quite continuous deployment. We still do have that manual step involved. It doesn't automatically deploy when it's screen because it allows you to do the things I was saying with edge. You can give it one final check before it goes to production, which is actually useful to be able to test the code, the exact branch that you're going to deploy before you deploy it. So like I said, master's always deployable. We always deploy immediately after merge. So what did this lead to? We had 404 deploys so far in September as of yesterday when I took these stats. Thought that was a funny number, but. This is across all of our apps. It's pretty good. I'd like it to be better. It ends up being about 20 per weekday so far. And that's across all environments. So we have between two and nine production deploys per day. We tend more to be on the low end of that scale. And I'd really like to be more on the high end of that scale in general. But, and that's kind of what we're working towards with these lower friction deploys. Definitely want it to be better. So, how do we actually do this deploy? Well, there's only one command. You just run, again, through UI bot, talk to the bot. It's just one command. It does the entire process, everything, all the automation. So the steps that it takes are this. First, shares master's green. We talked about this earlier. You can't deploy code this red. Some environments are forcible where you can force red code to go out. This is useful for things like a staging cloud where you want to check to see on a real deploy what is actually wrong with the code maybe. Something like that might happen. We don't do it very often, but it does happen. But production is definitely not forcible. You can't force a red build out to production. Then we tag the release using a get tag and bump the version number, things like that. We have this version of our deploys. We create a version field in U-Track and then assign all of the tickets that are merged into that field. This is why it's important to mark tickets merged earlier in the process. If you don't mark it merged, it won't end up in the bucket. Then we push that tag that we created a second ago into the deploy branch. So this always allows us to deploy from the deploy branch every time. We don't have to deploy from a different shot every time. So we're always just deploying from the deploy branch. We use a branch where the tag is changing, the tag is bad, you shouldn't do that and get, your peers won't get the new tag when they pull automatically. And then we basically do continuous deployment from that deploy branch. So whenever we push the deploy branch, it'll automatically kick off a production deploy. So we have this continuous deployment sort of infrastructure built into Ensemble. And so that's what we just use to get this deploy going. We used to do this manually and we discovered that it didn't ever really come up. Like you could test on edge before you ship the code. So there wasn't really a need to have that pause and wait and then ship it there. So we just do it automatically. Again, removing friction. So then all those tickets that you put into the version bucket in the beginning of this process, you mark them as resolved now. So you mark them as deployed at the end. So that way, basically we used to have a race condition here where we would mark tickets deployed at the beginning of the process and it was people would ping us and say, hey, this ticket got marked deployed. Is it not yet? It doesn't seem fixed. And it's like, well, that deploy hasn't actually finished yet. So now we don't mark them as deployed until they're actually deployed. And on the other hand, if we did it all at the end, then if somebody pushed code and then merged or market tickets merged between the beginning of the point and the end of the deploy, things would get marked as deployed even though they hadn't actually been in that release. So this kind of solved that race condition there. So finally, we send notifications. And there's a bunch of notifications that we do for this, for every deploy. First, we send to Airbreak. So we can see all the exceptions since the most recent deploy. We send to New Relic so we can get those nice deployment lines in our stats. We can see if they change anything. And finally, we send out an email with release notes. This is kind of a big deal for us. This is really useful inside the company. So every time we deploy, we send an email out like this. We link to the ticket view for all of the track tickets that got merged or got deployed. We link to the GitHub compare view between so we can see what code changed. And then we put all the tickets directly in the email as well. So this is the one from yesterday. I don't know if you heard it. We took JGV out of beta, now fully available. So this was the deploy that did it. This is the email that went out to the whole company. And lots of people in the company really like seeing these emails. People that are non-technical in sales and support and things like that look at these emails to sort of see what's changing in the product. So this whole process that I just described, it happens via Mason because it's just a job runner, right? So there's no difference in this process as opposed to a CI process. We still run the job, capture the output and return the status. That's it. So we have this generic job runner tool that we can use for these different pieces which works really well for us. I guess you probably could use a CI system for that and kind of pretend it's a build or something like that. I'm not really sure how that would work, but it seems sane to me. So the step I kind of skipped in that previous section there, I didn't actually talk about the actual deploy process. I kind of skipped that step. So it's kind of because it's not very interesting. We have a fairly standard deploy process. We use Capistrano for now. We might change that soon, hopefully, but we use a current releases and share directory. We don't do a GitHub style moving around the Git tree. We just use the regular currents and link. We use Unicorn, which allows us to do zero downtime deploys. This is another big deal for even friction of the deploy process. You don't want an engineer to have to say, oh, this is going to cause a few seconds of downtime. Do I want to do it now when it's a high traffic time or do I want to wait? So now we always just, it's always zero downtime deploys and we always can deploy basically whenever. That's the whole point, removing the friction. So I don't know if you know how the zero downtime deploys in Unicorn work, but basically you put the new code in place. You move the current SEM link and you trigger the deploy in Unicorn all without ever putting up a maintenance page and then the deploy in Unicorn spins up new workers that start serving requests on the new directory. It lets the current workers finish handling the request of the old directory and then those die. So then everything moves over, all requests are served. Nothing, yeah, it just works. Works really well actually. We use Bundler for our deploys, for our gem management in general. I think this is probably an obvious thing for most people here, but you should definitely use Bundler. It's basically solve the gem management headaches, the gem hell that we used to get into with versions on production. We deploy, we defer to Bundler for sort of the deployment best practices. There's this dash dash deployment flag in Bundler that does a couple of switches that are kind of the best practices for deployment. Kind of handles the lock file and things like that. So yeah, that's really good. And then finally, even if we have migrations, we still don't take downtime. This isn't really a magic technique, or it's not really magic, we don't do anything special, it's just the technique that we use. Again, because we don't want to prevent people from shipping code that, we don't want to prevent people from shipping code just because there's a migration. We don't want them to say, oh, this feature needs a migration, so therefore I'll have to wait until the weekend to do this, because we're gonna take 10 minutes of downtime or whatever. So this technique, for example, if you want to add a column, it's pretty simple, really. You add a migration to add the column, and then you ship that code. That's it. You don't add any code that deals with that column yet, so that this code, this deploy can go out with no downtime, right, because there's no code that depends on that migration being run. You deploy the code, migration runs, it gets the column added, no downtime, nothing needed, right, it just goes. Then, later, you finish writing all the code, depends on the new column, you deploy again, this time there's no migration, the column's already there, and you just deploy the code again, no need for downtime, the column's already there. So this means that we actually run migrations last. So we deploy all the code, get all bundler stuff set up, restart the app servers, then run migrations. So this allows us to speed up the time until the new code is live on the server earlier in the process. So the migrations run at the very end after everything's already done. It's a little bit counterintuitive, but it works really well for us. We like it a lot. So, a few more examples. This kind of gets a little bit hairy at times. Things like removing a column are pretty simple. It's kind of the same thing, but opposite. You deploy the code change that removes the need for that column, and then you deploy the migration second, right? So by the time the migration runs, all the code that needs that column is gone already. Something like renaming the column gets much more complicated. So this is something where maybe you would add the new column in one release, then ship code that uses the new column, but also syncs everything. So maybe it reads from the old column and writes the new column, and then you can migrate all the data over while that code is out there. So now all the data's in the new column, and then you ship code that reads and writes from the new column. So you're not using the old column anymore, and then you can drop the old column. And every single one of those steps doesn't need to take any downtime. And this is where taking downtime might not be the worst thing. It's kind of a trade-off at this point. Do you want to take on that additional complexity to prevent yourself from having to worry about when you deploy, or do you want to just maybe write the code normally? This might not be too bad, but we've definitely had situations where it was pretty complex to do it with zero downtime, and we opted to just take a few minutes of downtime a weekend, have somebody do a deploy on Saturday or something like that. And we also have done deploys where if we want to add an index to a really big table or something like that, that clearly needs a downtime. That's not, it's not really possible to have a table walk for five minutes and have it keep working. There's no way to do that without downtime. So this has been a really good technique for us. We use it pretty much all the time. Anytime we were on our migration, I think the last time we had to take downtime was one of those admin index things, and that was a few months ago. I don't think, I can't think of any recently that we've had to take downtime for migration. So it works really well. So again, this is all about just reducing friction to ship code. You don't want to, by using this technique, you don't have to worry about when you deploy anymore, and that's kind of the whole point. So all of this is a work in progress, sort of everything I've just talked about. It all started as a side project. We didn't ever decide that we were gonna build this thing, and there's still a lot more that we want to do. We started with integrity as a CI system, and it wasn't working well for us, and we basically decided we wanted more of the style of integration, and we couldn't get it with integrity, and we had a discussion about whether we should patch integrity to make it work, or write something ourselves, and it was a huge win to write it ourselves, because now the code and the project is basically exactly tied to our particular development practices, and it all works exactly how we want it to without having to hack into the system. I'm sure that it's easier, that it has been easier to work on the ensemble system than it would have been to try and get integrity to do what we wanted it to. We want to be able to get to faster deploys, or deploys are still relatively slow, partially because we do all those migration stuff at the end. We want to get some more integration. We want more pieces to basically happen on deploys. We want more interactions to happen via automation. So right now, like I showed, we have the manually merge code, and mark all the tickets as merged. There's no reason why we couldn't have a merge command in ensemble that basically took that branch, merged it to master, and then marked all the tickets merged that are associated with that. And again, like I said at the beginning of the talk, this is all the workflow that we use in EngineYard, and my suggestion isn't that you use this workflow, although you are welcome to. I like it a lot, but I'm not saying that this is a one-size-fits-all workflow. It's more about defining the processes that you use and how you tie them together and automate them so that way you can reduce friction in your deployment infrastructure. So that's pretty much all I have. Thanks. Again, I'm Adelcom on Twitter. I work for EngineYard. That's our website if you haven't looked at us before, and we are hiring, so if you want to work on stuff like this, you should come and talk to me or anybody else here. And if there are any questions, please feel free. Call us when you're not. Go for it.


Tea consumption is associated with a reduced risk of heart disease, stroke, and premature death in general, with each additional cup of green tea a day associated with a 4% lower mortality risk. So maybe drinking several cups of tea daily can keep the doctor away, as well as the mortician. But what about cancer? There is growing evidence from laboratory population and human interventional studies that tea can exert beneficial disease-preventive effects, and further may actually slow cancer progression. Let's review some of that evidence.  These are in Japanese tea cups, which only contain half a cup, so the highest category here is greater than or equal to five full cups of tea, not ten. The women who did get cancer appeared to get it seven years later if they'd been drinking lots of tea compared to those who consumed less, whereas men had a three-year delay, the difference male versus female potentially due to smoking habits. Green tea may be able to interfere with each of the stages of cancer formation, the initiation of the first cancer cell, promotion into a tumor, and then the subsequent progression and spread. Drinks often initiated when a free radical oxidizes our DNA, causing a mutation, but within 40 minutes of drinking green tea, you can get a nice spike in the antioxidant power of your bloodstream. This increase, in turn, made lower oxidative damage to DNA and so decreased the risk of cancer. Furthermore, in terms of genome-protective effects protecting our genes, pre-existing oxidation-induced DNA damage was lower after drinking green tea, suggesting that it can boost DNA repair as well. But we didn't know for sure until now. There's a DNA repair enzyme in our body called OGG1, and within one hour of drinking a single cup of green tea, we can boost its activity. Though after a week of tea drinking, we can boost it even higher, so regular intake of green tea may have additional benefits in the prevention and or repair of DNA damage. Tea is so DNA protective, it can be used for sperm storage, for fresh samples, until it can be properly refrigerated. And so anti-inflammatory, it can be used for pain control as a mouthwash after wisdom tooth surgery. And in terms of controlling cancer growth at a dose of green tea compounds that would make it into someone's organs after drinking six cups of tea, it can cause cancer cells to commit suicide. Apoptosis, programmed cell death while leaving normal cells alone. There's lots of chemo agents that can kill cancer through brute force, but that can make normal cells vulnerable too. So green tea appears to be potentially an ideal agent for cancer prevention. Little or no adverse side effects, efficacious for multiple cancers at achievable dose levels, can be taken orally. We have a sense of how it works by stopping cancer cells from growing, causing them to off themselves. It's cheap and has a history of safe acceptable use. But this was all based on in vitro studies in a test tube. It needs to be evaluated in human trials, give people with cancer green tea to see if it helps. Which we'll explore next.


Welcome to the 19th meeting of session 6 of the Delegated Powers and Law Reform Committee. Before we move to the first item on the agenda, I would like to remind everyone present to switch their mobile phones into silent. The first item of business is a declaration of interests. In accordance with section 3 of the Court of Conduct, I invite Jeremy Balfour MSP to declare any interests relevant to the remit of the committee. No interest, convener. Thank you very much, Jeremy, and welcome to the committee. The next item of business is to decide whether to take items 4 and 5 in private as a committee content to take these items in private. Under agenda item number 3, we're considering instruments subject to the negative procedure. No points have been raised on SSIs 2022, 179, 181, 182, 183, 184, 185, 190, 192, 193 and 194 as a committee content with these instruments. Thank you, and with that, I'll move the committee into private.


Ahead of the 2019 polls, election fever has gripped key states in India. Madhya Pradesh being one of them. The state is set to go to polls on the 28th of November and there are some legitimate questions that are facing the three-time Chief Minister Shivraj Singh Chauhan. What are the three factors that are causing a major headache for the BJP government in the state? We break it down for you. Madhya Pradesh has a population of 7.26 crore and is ruled by the Bharatiya Janata Party since 2003. BJP won 165 seats with 44.88% vote share in the last election in 2013 while the Congress managed to back 58 seats with a vote share of 36.38%. The BSP won 4 seats while independent candidates managed to clinch 3 seats. A study by the Centre for Monitoring Indian Economy shows that unemployment is the top issue on voters' minds in Madhya Pradesh. As per the data, 30% youth aged between 20-29 years in the state is unemployed. Among this, 8% youth is graduate. The state economic survey done in 2017 shows educated jobless youth registering with unemployment exchange has shot up from 15.6 lakh in 2015 to 23.7 lakh in 2017. The same report states that only 129 people had got employment in 2016. And it's not only about the youth, the farmers in the state are also not very pleased with the BJP government. In the last 5 years, procurement programs have floundered under the BJP regime. Less procurement means fewer farmers are actually getting the rates of the MSP. Farmers in the state are no longer selling their produce to the government agencies which are the only ones offering them MSP. Between 2001 to 2015, according to the National Crime Records Bureau report, 18,000 farmers have committed suicide in the state, while in 2016, over 1,695 farmers had committed suicide. In 2017, in farmers' protests in the state, especially in the region of Mansor, over 6 farmers were killed only because they were demanding for fair share of prices for their crops. The protests put Shivraj Singh Chauhan government on its toes. On top of these statistics, in 2016, Narendra Modi decided to award the state chief minister Shivraj Singh Chauhan and agricultural minister Gauri Shankar Bisain with the Krishikarman award to recognize the increased crop reduction in the state. Now let's talk about the Madhya Pradesh government's stand on the SCSD Act. In the 230 member assembly in Madhya Pradesh, 35 seats are reserved for the SCs, while 47 seats are reserved for the scheduled tribes. In April this year, Madhya Pradesh witnessed a spate of violent incidents after SCSD groups called for a Bharat Pant to protest against the ruling of the Supreme Court which diluted the prevention of atrocities amendment bill 2018. This sparked a massive reaction from the Dalit and the Aadivasi groups across the country, followed by which were violent clashes between the SCSDs and the upper caste groups. Six people were killed and several others were injured. Later on, in the same month, to appease the upper caste groups, Shivraj Singh Chauhan in a tweet said this. The anger of the upper caste against the BJP government grew fresh troubles for the chief minister. While the BJP government continued to enjoy the support of Aadivasis until 2017, this has changed since then. Successive rounds of mood of the nation survey conducted by Lokneeti and CSDS show the decline in the support among Aadivasis could be because of the changes in the scheduled castes and the scheduled tribe prevention of atrocities act. The non-implementation of the Forest Right Act is also one of the major factors causing discontent among the Aadivasis in the state. With as many as 20 ongoing power projects in the Narmada region, the state is currently witnessing multiple smaller agitations in different parts, such as Chindwara, Mandawala, among others. The large-scale displacement has angered tribals in the region, which has brought with it a series of political mobilization efforts in the state. For the first time, tribal-based Jaya Adivas-Yua Shakti Party came into existence causing a major headache for Shivraj Singh Chauhan. So the major question is, will the BJP government be able to rise above these factors to win Madhya Pradesh back for the fourth time?