You're up against natural forces now and you need to pay attention to the standard operating procedures or the few standard orders, the ten standard orders that give you a good basis on which to keep yourself safe in that environment. There's not very many times when it's worth people getting hurt in a situation to save a little bit of forest. And so we really need to be aware of our assignments and just, I think, evaluate once we get them to say, okay, is this worth it, basically?  You know, if someone does get hurt, a snag could fall on them or something. It's a real danger that people get too complacent and not worry about establishing communication. I don't think it's possible to safely fight a fire without having lookouts, communications, escape routes, and safety zones. Maybe if it was a smaller fire, you wouldn't really need to look out. I think every situation is a little bit different, but for the most part I think that they all for need to be at least a part of your decision-making process when you're on a fire. I think often on a fire, the helicopter pilot is not really viewed as a firefighter and I think that if that pilot is viewed as a firefighter, it's going to be that much more cohesive as far as working as a team and being able to have the same objectives. And I like to think of myself as a firefighter. I have a different tool. I have the helicopter instead of a Pulaski or a chainsaw. But first and foremost, I'm going to fly the aircraft, but I'm using the aircraft to fight fire and I do consider myself a firefighter. I think if more of our people on the ground would understand that, I think that the helicopter could be used even more effectively in the future. There was a tragedy in Southern California where an engine crew had gotten on a fire, the fire blew up and everybody escaped to safety, but some of the personnel went to a different area than was everybody supposed they were supposed to. The supervisor of course went back to check for that person and then became a fatality. And that's where my biggest concern with the shot crew is that, you know, as that safety zone moves, did everybody get the message clearly and cleanly so that when we get there we're all there? Because, you know, sometimes we are scattered about. I guess when I first started fighting fires, there was a lot of things I didn't understand. There's a lot of lingo flying around in fire that only firefighters know and that made it really hard kind of at first was, you know, I'd hear all these terms and things that I'm supposed to go do and a lot of times I didn't even know what that meant, but, you know, I felt kind of stupid to ask. So I guess along the same lines of what I, you know, if I was going to tell a new person, kind of along the same lines, don't feel dumb ever to ask questions and figure out what's going on because I don't like to not know what's going on as far as, you know, just to feel comfortable. I like to be in the loop a bit, you know, what I'm supposed to be doing and so that was actually one of the things that when I started fighting fires I wished someone would have sat me down a little bit and kind of explained the whole how things work. You tend to see plans on, like you said, or like flashy fields and stuff when you're looking at safety hazards and stuff or looking at anything even before you start a plan, you always have a plan A, a plan B and a plan C.  So when I go into the strategy I always look at, you know, two to three different plans that are going to work or if plan A doesn't work, you know, you can't go in there with the attitude that this is a plan and it's going to work. I always go in there with plan A, plan B and plan C because it comes back to, you know, you watch how situations, if the weather changes, you get a wind or you're in different fuels than you thought you'd be, you know, the fuels were drier than you thought they'd be, then you've got a plan B, you know, you back up and you look at it and you say, well, let's bump down to the next road or let's do something different that's not going to put this crew into a situation. Hi, I'm Larry Sutton, BLM Training Unit Leader at the Fire Center in Boise. We put this program together to provide you with another tool for refresher training. There's some things out there that people have seen a lot of times and we wanted to put something new out there and our concept was to have it be like a conversation among all of us, kind of like you'd have on a fire where you're talking to people, sorting through things, figuring out what's going on and maybe have that conversation a little bit earlier in the year. We all know that physical fitness is really important in firefighting and I guess we need to consider that mental fitness is just as important and that this is one way to get your head back in the game is to go through this type of program and think through what's going to happen when you're out there this summer, how you're going to do things safely and operate in the kinds of environments that we get into. A lot of times you'll hear people tell you to be safe out there but what does that really mean? What are they really getting at when they say that? Maybe they don't know but we need to as firefighters. So I think you'll get a lot more out of this program if you participate in it. We can all learn from each other. You can learn from your peers both that are in this program and that are sitting around the table with you. So I hope you enjoy the program and have a safe season and make lots of money. The Bureau of Land Management Fire Training Program presents Fireline Safety Refresher Training and now the host of your program, Ted Mason. Hello and welcome to BLM's Fireline Safety Refresher Training. In this training session we're going to explore many of the aspects of safety on the fire line. We're going to help you brush up on your basic safety awareness and take a look at some real-life examples of lessons learned out on the ground.  Your participation is key to making this training successful so please don't just sit there. But before we go any further I'd like to introduce our panel of safety experts who will be joining me as we look at some safety in fire operations. From Las Vegas, Nevada we have Nicole Halisey. She's an experienced engine captain who has some unique perspectives to share with us on fire safety. Welcome Nicole. Thanks Ted. I'm excited to be here working with you, the panel members and everyone out there. I hope I can indeed offer some unique perspectives on fire line safety and hopefully some insight into engine operations. Good and from Boise, Idaho to discuss helitack operations and what we'll need to keep in mind as we head out into this coming fire season is Brad Bolin. Brad, thanks for being here.  And also from Boise to provide the smoke jumper point of view is Hector Madrid. I believe you have a recent story you're going to share with us and involving the use of LCES. How you doing Hector? Glad to be here Ted. Hopefully today I can offer you a different twist on fire line safety from the smoke jumpers perspective and yes we'll be discussing LCES a little bit more later on. Good and completing our panel from Jackson, Mississippi to provide us with some real on the ground perspectives is a good friend of mine Lamar Lydell who is the superintendent of the Jackson hot shots. Hello Ted. I'm excited to be here and offer a perspective from a hot shot point of view. Good. Looking forward to it. In order for you to complete this refresher training you'll need to have a copy of your course workbook which your facilitator should have passed out to you. Your workbook contains our training objectives, information on the topics we'll be covering and some training exercises and then at the end also an evaluation. To help you follow along we'll be referring to pages in your workbook as we discuss the many aspects of fire line safety. And in your workbook on page 3 you can also find some biographical information on our panelists and some of the key speakers you'll see in our videos. One final word before we get started. This is called refresher training for a reason. Although you have probably heard a lot of this information many times before humans have a tendency to store or file away information that they don't use on a regular basis. The purpose of this training is to pull this information back out of that filing cabinet in your brain and make it readily available for you to use during the approaching fire season. The panelists and myself will do our best to help you retrieve this information but we realize that the best resource for this task is probably yourself and perhaps the people sitting right next to you right now. No two fires are exactly the same. Everybody has their own unique set of experiences and knowledge. I urge you to share your knowledge and experience while you participate in these exercises and discussions that will follow.  Whether you get this from the panelists or from the person sitting right next to you is really not that important. What is important is that during this training you actively seek out new information that will make you, it'll help you make sound safe decisions on the fire line. Now the first thing we're going to review is the 10 standard fire orders. They are listed in your workbook on page eight. Everyone knows that these are also in your fire line handbook and in this incident pocket guide that we all carry on the fire line I'm sure. But remember that using and understanding them is what's really important not just memorizing them. This past winter I had the privilege of sitting down with a man named John Krebs. You can read all about John in your workbook. He started his career in 1958. He spent many years as a FMO or a fire management officer on the St. Joe National Forest and he was a fire behavior analyst for 21 years. John kept me extremely entertained when we were talking about his outdoor adventures in Idaho, his apple orchards, and a black bear hunting story that I'll never forget. But when the subject turned to firefighting things got real serious. Although recently retired John still has a real passion for the 10 standard orders and he was around when they were first initiated into fire service. In your workbook on page five you'll find a reference to a letter that John wrote. In it he talks about the original sequence of the standard orders and why they were written in that order. In the tape you're about to see John will share with us the original grouping of these orders. The first three orders pertain to fire behavior. The second three orders pertain to safety and the third pertain to organizational control. The last order which is now of course listed as number one is fight fire aggressively but provide for safety first. Talking with John gave me a new perspective on utilizing the 10 standard orders as a useful tool during fire operations. Let's take a look. The 10 standard orders, the original 10 standard orders were developed as a result of the man gulch fire in 1949 and I think the chief of the forest service was responsible for assembling a team.  Well they started out with the fire weather and the first one they said was keep informed on fire weather conditions and forecasts. Now there's two parts to that. The first deals with the conditions. U is imperative in all of these orders meaning U the firefighter the lowest grunt on the ground. Keep informed on fire weather conditions. Now the forecaster doesn't give you the conditions he gives you the forecast the meteorologist gives you the forecast. The conditions are your responsibility. For instance you might have a forecaster that says you're going to have strong southwesterly winds and you're on the lee side of a ridge and you know those winds curl around over that ridge top strong winds and you get a wind out of the northwest or northeast. That's your responsibility. You've got to measure the condition. You look up and see a cumulus cloud or cumulus castellatus clouds. You know there's instability aloft. That's observations that you make on the job so you keep informed on conditions and then don't forget to ask about the forecast. Nobody has the responsibility to give you a forecast. You have a responsibility to ask for a forecast and I want to just emphasize that time and again if you review fires you'll find that this is one of the things that's often overlooked. Failure to obtain a forecast. Failure to keep in mind the weather conditions with belt weather kits and observations.  You observe personally, you use scouts, lookouts, whatever to try to keep a handle on how your fire is behaving and then you ask keep base all actions on current and expected behavior of the fire. So you've analyzed this from the weather, you've analyzed it from the topography and time of day and all this to base those actions on what you see currently and what you anticipate will happen and that also brings in fire history because what did the fire do last night for instance is very important when evaluating what the fire is going to do in the heat of the day when the humidities are much lower and the weather completely changes. Well then it goes from that Ted into the orders that deal with safety and we know orders that talk about you know maintaining a lookout when there's possible danger. It says post a lookout when there's possible danger. You post a lookout when there's possible danger. Not somebody else, of course you might not be the person in charge meaning you say hey a little problem that this snag over here is burning and I've got a big fire line I think I need a lookout if there's a limb going to fall out of the tree or if you've been falling trees that have fire in them you know you got somebody there to tap on your shoulder with a branch if there's an ember coming down from above it's going to give you some problems. So that's posting the lookout when there's possible danger. Have escape routes for everyone and make them known. The supervisor is usually the person that has escape routes making them known as his responsibility. Knowing them is your responsibility. You ask that person hey where's the escape route? Do we need it?  So you might not need that. The next one has to deal with keeping alert you know be alert keep calm think clearly act decisively. Really that's hard to do after a 24-hour shift and you're out there and you know one of the 18 situations that shot watch out if you feel like taking a nap near a fire well how do you be alert keep calm think clearly and act decisively when when the sun is just beginning to shine in on you after spending all night on the fire and you think oh man I've got to have a little nap here. Well you do this because you've analyzed this fire behavior and and so you've got an analytical way of looking at things and that helps you to put that down in writing to stay alert when you really your body is saying hey man I can't do this anymore. So those three deal with safety and I know you can elaborate on those from your experiences and then we get into organizational control and organizational control means maintaining control of your forces at all times. Now how do you do that? Well Pulaski in the 1910 fire did it with a revolver and he kept 40 some people in a cave on the fire well you don't need a revolver if you've analyzed these fire behavior orders because that helps to maintain control of your people they feel free to ask questions of the supervisor to collectively look at what the fire is going to do so maintaining control becomes a thing that's a whole lot easier and then you talk about maintaining prompt communications with your men your boss and adjoining forces something that has to be done in order to to know what's going on one way to know what's going on but it's a two way street when we talk about about maintaining prompt communications or giving clear instructions and being sure they're understood that's two ways and I give clear instructions you give clear instructions the receiver doesn't understand the thing they need to ask I need to ask if the instruction is not clear again analysis looking at the situation you're in when you take a break that's important and the instructions will become clear when you do that I think the grouping is really summarized when you talk about the first of the fire orders as compared to the last of the standard orders the 10 standard the first of the fire order said fight fire aggressively but provide for safety first now you can't fight fire aggressively until you've analyzed the fire behavior until you've looked at it and said hey I'm not going to be bitten by by this kind of action you know you can't know what kind of of escape routes lookouts what have you until you've evaluated what the fire behavior is going to be so those things follow sequentially and then when you get to the last order again fight fire aggressively having gone through this method of evaluation my thought is article is really I related to it well and the way he divided it up the the process that he goes through hits home a lot more for me and the best part of it is the is the last part where he says fight fire aggressively but providing for safety first I like that the best it's key something in my mind rather than but provide for safety first I definitely like providing for safety first I think that they're being utilized people don't consciously think about it because it becomes ingrained it becomes intuitive and in the back of their mind I think they're thinking about it it's in the decision-making process and you go through that analysis type thing then then it's being considered but but in terms of of just consciously clicking through one through ten or trying to use the new monic I don't think that happens but I think all decisions are the majority of the decisions that are made they are the foundation they are the fundamentals and I think they're being considered well we we've always had a standard to abide by a guideline to remember to protect ourselves to help each other all pretty much rolled into a heads up situation these are things to look out for and so on and so forth and more so than anything with with myself it's a matter of common sense now did I have that common sense when I was 18 no but through a period of time and a certain amount of fires I suppose you you come to grips with the the necessity and the importance of the guidelines and of the the firefighting orders it just comes about as a stark reality that all of this is is extremely important and and a number of them will probably be tested every fire in reference to the fire ten standard fire orders I believe that they are utilized on a daily basis on fires as a way to make decisions no go go no go decisions I also believe that they are the standard I believe in those standards because I came from an organization that people lost their lives and that's where these came from the El Cariso hot shots and the Cleveland hot shots both had incidents that the 10 and 18 came directly out of so I'm a firm believer in them I know I use them both to to evaluate a situation and also to brief people that I may be supervising on the fire line and as a reference point to make sure that I have covered my bases and then I'm running a safe operation when I'm out in a fire edge fire line and for using the tins it's uh oh just I don't want to say instinct but you just they use all my senses throughout the operation period of what's going on how it's going they play off each other when you're out there it's um something can happen you don't know why your decision came up but it's it'd be one of the tins something will have changed your mind without you thinking about it directly or reading it it just comes up when you're out there for a while you just you just learn and me the schooling helps don't get me wrong and learning stuff but when you're out there after a while you get common sense and that helps too and they can't teach that those are some excellent comments it certainly makes sense to me to group the standard orders in the manner that John Krebs explains but no matter how you remember them the important thing is that you understand them and that you use them when you're on the fire line making decisions next we're going to go ahead and discuss the 18 watch out situations let's talk for a second about the difference between the 10 standard orders and the 18 watch out situations I'd like to ask our panel members for their thoughts on this one Nicole what do you think is the actual difference between the 10 standard orders and the 18 situations a shout watch out you know Ted a lot of times people refer to it as the 10 and 18 like they're one entity but in actuality they are different concepts with different applications the 10 standard orders are just that they're orders they can't be bent or broken and they must be adhered to at all times the 18 situations that shout watch out or something they should be looking for on the fire line while you're out there they can be compromised if actions are taken to mitigate the risks at the time but one thing you do have to realize is the more 18 situations that you compromise you surround the greater risk of actually compromising or breaking one of your 10 standard orders so that's true good comment anybody else Lamar you got anything Brad you know Ted uh it doesn't really matter to me how you remember the fire orders or the watch out situations as long as you do understand them and apply them correctly Lamar and I agree with Brad also but you know I said you're listening to the to the discussion and field interviews and takes me all the way back to what John Chris was saying about the the order and and the way they're grouped and that's that's really important to me not to say that one's more important than the other uh the thought process is really important and it's easier for some people to remember them the way they're revised but also I think the big difference one of the differences in in the 10 and 18 is that the standard orders are are a guideline for developing our day-to-day operational plans those 18 watch out situations along with lces look up look down look around all are merely tools to help us reinforce those 10 and 18 and that takes us right back to what John Chris was saying and one order that stands out to me more than anything is fire order number six and it speaks of stay alert stay calm think clearly act decisively and I think that's something that we'll look at throughout the the rest of this field at these what we got going on today good comment and I agree with you on that if I like running through the 10 orders as a process the way that John explains it and by doing that that number six stay alert stay calm by being alert that's where you're really seeking out and looking for different watch out situations that might be present think clearly act decisively that's where you're mitigating those 18 situations so to me the 18 kind of play right into that process of running through the 10 standard orders but you know the important thing is everybody has a different way of remembering them important thing is is that you do understand them and you do use them when you're making fire line decisions well let's uh let's take a look at what some other field personnel that that we've interviewed this last winner have to say about watch out situations the 10 standard orders are rules that are there for us for us not to break not to widen the gaps and and adjust them to the way that they fit our needs they're there for a reason people have lost their lives to teach us those and it's our responsibility to honor those folks by learning these and not making the same mistake that they did they are there to help us be aware that we're getting close to breaking maybe it's one of the 10 standard orders we definitely can fight fire you know while breaking 10 or not 10 but say three watch outs that's fine as long as you're thinking about them because we do it as hot shots constantly it's just the name of the game and the job we do but they're there just to to keep our mindset to hey we're getting close to the line now and maybe it's time to open up our eyes a little bit more and really take a little bit better look at the situational awareness that we have right now think that the 10 standard orders are guidelines that keep you safe while you're on the fire line and i've always kind of looked at the 18 standard watch outs is like reality i mean it it's the nature of fire behavior i mean wildfires you're always going to have something that happens i mean you're always gonna you know have be not always but you're going to be working a line downhill or you're going to have stuff rolling out or it's going to get hotter and drier or the winds are going to pick up whatever you know that stuff just happens that's just the nature of fire it seems it seems that there's a connected series of watch outs that to me are the most often it's not that they're misunderstood that they're probably the most often unmitigated and safety zones and escape routes not identified not timed not flagged correctly not communicated not updated and then also instructions and assignments not clear that's the connection there if we're given vague assignments and instructions the escape routes and safety zones are kind of also vague we're not really sure where we're supposed to be going therefore we're not sure where we shouldn't go and then also we're uninformed on strategy tactics and hazards this seems to be the little triangle of miscommunication here that most often leads to to crews getting in trouble and by trouble i mean they get in too far they don't have time to react they don't have time to mitigate the hazards and then they're reacting to the situation rather than proactively saying since we know we're supposed to go here and do this we know our escape route to our safety zone is here and we're all comfortable and and we're proactive we're able to to be aggressive to suppress the fire because we have provided for safety yeah you know one of the things that i see um especially in that transition between say a type three incident and type two incident are kind of administrative watchouts and uh they have to do with the complexity of an organization kind of outracing um outracing people's knowledge of the situation maybe so you have a type two team maybe replacing a type three team you have a whole bunch of resources coming in yet the new management team isn't yet up to snuff on what the fire is actually doing uh it can be the same thing transitioning from initial attack to a type three incident you know you have type three structure coming in to take over yet they don't really know quite what's going on yet yet they've got all this stuff coming in and they're under you know under the gun to really get stuff rolling and to get this fire put out so i see that there should be some kind of well i wouldn't i wouldn't suggest adding it to the list but i think i do see it a lot when we transition from i to type three or type two that there's this administrative watchout that always occurs to me it's like watch out somebody else is taking over this fire and they don't really know what's going on yet there hasn't been a good briefing uh you know some of the stuff is covered in the other watchouts but to me it's the it's the management team is coming watch out and i know everybody's seen it you see it when it goes from type two to type one and every time you transition it it occurs but uh that one i see all the time those were some great comments we just heard and if you're like me you have a lot of comments uh to piggyback on top of what we just heard from those people with their feet in the fire as john would say but i'm going to open it up to the panel right now and does anybody have any comments on what we just heard on the 18? Hector? I sure do Ted um one of the people interviewed said can you break a watch out situation and it's points well taken um yes i feel in a roundabout way and not jeopardize what i'm trying to say here but yeah in their certain circumstances where a watch out probably can be broken let's take for example your station in the middle of Nevada flat rolling terrain, cheat grass, environment, what have you middle of the night your crew gets a call that there's a fire burning somewhere out in the desert in flat rolling country and your assignment when you get there is you tie in with the incident commander he says he wants you and your crew to punch the line along the certain section of the line well you can go down the watch out list and now you're going to find something there that says fire not seen seen or scouted in daylight you know in this particular circumstance the situation may not be that bad and you can proceed with your assignment on the contrary say you received assignment and you were somewhere in the middle of Idaho and a call came into the pay yet and now you're on the salmon river breaks and you know you've got rolling rocks and timber and such you can see where that watch out would now apply so i think a lot of it is going back to common sense and using it as a guide to kind of mitigate a whole lot of measures like that I agree with you it gets back to what John Krebs was talking about as far as it's your responsibility i love how he said that there's a you that's imperative there that it's your responsibility to control and monitor conditions and conditions change depending on where you're at what time of day in fact they're constantly changing whenever you're on a fire operation anybody else well let me ask the panel this when do you know you've broken a number of these watch out situations when do you know is the trigger to say hey i need to step back anybody it's a good question i don't know i think a lot of it like you were saying is common sense uh you you kind of know when you when you kind of cross that line and say well i you know i think uh me and you were talking one time you were talking about Paul Gleason and going through those doors you can't back up well sometimes you make those decisions and you can't back up and you have to keep going with it but if you can you you need to you need to say man i'm we're gonna hold up here this is it all right we've broken too many rules with we've i've seen too many watch out situations and and and we're gonna step back and let this go and i think uh most management teams will understand where you're coming from and and decide to go along with what you're saying okay we won't do this we'll wait till tomorrow Paul Gleason you were talking about that uh those are decision gates who's talking about and once you walk through a decision gate and it happens all the time on a fire line that there's certain spots where you make a decision to go or no go and at that point since you walk through that gate those gates sometimes lock behind you and you can't turn around and reverse that decision uh the watch out situations are in place so that they are to remind you that these conditions are present and we need to try our best to mitigate them and if we can't mitigate them on the spot step back reevaluate situation and look at it with common sense and all the other tools that we have available to us before we make our decisions good job now let's take a look at some recent fire situations one involving a guy named scott sugg off of the boys national forest i believe this has to do with the hilltop fire and brad you were on this fire as i recall but let's go ahead and take a look at the tape right now and see what kind of situation scott found himself in the hilltop fire was located just off of highway 21 about 10 miles from boise, idaho the fuel type was grass and brush the fire started early afternoon and our crew arrived approximately about 15 30 on september 24th we worked with another hella tech crew on the west flank of the fire as they got later in the evening the fire behavior calmed down and the crews began to mop up approximately about 100 feet at about 200 or dusk we had a shift change due to some duty limitations so our crew was headed back into boise to return first thing in the morning while some engines and the instant commander would patrol and monitor the fire throughout the night on our way back to boise we could hear radio traffic about a spot fire caused by winds changing down canyon at about 20 to 25 miles an hour so we radioed the instant commander and asked if we should return he said yes so we headed back up highway 21 to hidden valley road and tied in with him with our type 6 engine our crew was going to be responsible for the north side of the spot fire while the engines would work off a hidden valley road we also tied in with two engine crew members which brought our total to six firefighters at this time we had a briefing about some safety concerns such as spotting wind shifts and lces the spot fire across hidden valley road was headed south southeast towards some structures we anchored into the cold black and off our type 6 engine which was working back towards the road our crew proceeded west on the north flank of the spot fire across the ridge tops with the prevailing winds at our back at about 20 miles per hour which allowed us to use a direct attack method we continued west eventually we would like to tie back into the hidden valley road as we were attempting to make the corner to head south towards the road we came across drainages which the fire behavior and terrain would not allow us to use the direct attack which we have been utilizing this direct attack was not effective because we attempted to use it many times and had had to pull back into our safety zone so at this time the crew had a discussion about building fire line downhill with fire below what strategy and tactics to utilize and potential hazards some individuals wanted to keep it tempting to use the direct attack which at this time was not a real option so we pulled back to our safety zone and watched to see what the fire would do the fire was more active because of the topography and was making runs up the little drainages as we made our way uh as the fire made its way up the drainage it was burning towards lighter fields and near the ridge top where the wind would influence the fire behavior again this would allow us to go more direct or use an indirect method and and drag fire with us to black line our line as we headed south towards hidden valley road we we kept in countering drainage after drainage which presented the same problem again and again so every time we came up to a new drainage we'd have to stop evaluate and look for tactics which could be more effective and as we came up near hidden valley road to the last drainage we heard on the radio that a type 6 engine was working its way towards us and we could see that they were running a hose lay down the office side of the drainage and that's where we would anchor in together Scott made that scenario look pretty darn simple but in fact it was rather a tricky situation he did a good job of keeping that situation from becoming a disaster it's funny but the best decisions on the fire line always seem to be the ones that nobody ever hears about they never make the news but let's ask our panel what their thoughts were on this brad you were on that fire well you know what impressed me the most was the fact that next morning when I was getting the debrief from Scott doing the recon flight I noticed several potentially hazardous situations that they were faced with throughout the night while they were constructing their fire line and as Scott told me what their actions were to mitigate these hazards you know it came clear to me that they were really using a thought process they weren't just going direct or or attacking this fire without making sound judgments and you know that's why I brought this scenario to this group so we could discuss it because it was one of those instances where you know they did everything right and we averted a potentially tragic situation good any other comments Hector yeah you know I'd like to you know confirm what you said about good decisions not making six o'clock news hats off to these guys on this fire it was one of these fires we've never heard much about good sound judgment calls however on the contrary should things have gone bad someone would have been injured or fatalities occurred remember an investigation team would have been there and guarantee they would have been looking into the 10 and 18 they do use those to I mean you'll find those in every investigative report you read that's the first thing they judge your fire tactics on they'll pull those out and look at them so that's a good thing to keep in mind anybody else you know Ted getting back again to basically back to what John Krebs had said you know look at what Scott Sug did here he was updating his tactics continually what worked for him in one drainage may not have worked again so he was continually updating those he was basing everything off of the 10 standard orders in the 18 situations although I really doubt he was pulling out as a you know his handy dandy little card there and checking them out he was probably doing it all intuitively he made good sound decisions and you know we wouldn't have heard about this unless Brad brought it to us and I think more of these situations happen than we realize you know most of our fires are done right the ones that we have a problem with or something goes wrong those are the ones that end up making the news but yeah Scott did a good job I thought of evaluating as he went he didn't just make a plan and try to stick with it that was one of those situations where you dig 50 feet of fire line and you're reevaluating and thinking about the whole situation again and then doing it again every 50 feet and every ridge line he came over he was faced with different set of circumstances so he was monitoring those conditions as John Krebs puts it you know he took his time he took his time and it's exactly like what we're saying in fire over number six took his time he made good sound decisions and it's a reason why he did that Ted training background and training you know he trained under Lamar but he did a great job and I'm not surprised that he did what he did well if he trained under you then I got to give him even a double hats off if he manages to come that so he's doing pretty good anyways thanks to our panel for for those comments those were good so to conclude this section let's remember that the 10 standard orders and the 18 watch out situations are used as benchmarks for accident investigations as Hector was mentioning as well as being very useful tools in fire line operations the standard orders and the watch out situations were created to help you make sound safe decisions on the fire line but they'll only help you if you know them understand them and use them in day-to-day fire line operations and decision making this is a big subject in a matter of how long you've been working in the fire program you never really know at all one thing I do know from my own experience though is that without a break once in a while our ability to absorb information kind of gives way to a you know that need for a cold pop or a bathroom visit so let's take a 15 minute break right now before we dive into the principles of LCES


So I just got here because I've had a cold and I still have a cold and I'm like Half groggy from having a cold and half from the drugs that I took so I could do this So we'll see how it goes Luckily, I'm talking about vulnerability and stuff. So it's probably good appropriate, right? Yeah, I didn't expect to be sick and I'm also not allowed to cover the mic or turn off the mic when I cough So be it warned So what should we talk about? Rainbows Unicorns farting rainbows. That's what people expect me to talk about most of the time Marty said maybe you want to come and talk about love and software and I'm like, can you even do that? Like is that allowed? So but I will tell you There's a present later on. There's a little bit of code. So so the topic is love and love to me is Kind of uncomfortable to talk about and Like I talk about it all the time. That's what I do. And so I imagine you guys find it even more uncomfortable But also it feels like hubris I'm about to say, you know, this is what love is. This is what kind of love software needs and that's That's hubris. I don't want to tell you what love is for you. So Take what works don't take what doesn't work, right? So soft skills There's one conference that says, you know, no fluff No soft skills and I think Really? Why are you scared? When the quietest person on the team speaks up, even though they're terrified, even though they're trembling Because they know that something really bad is going to happen if they don't That doesn't seem soft to me. That seems kind of badass actually I'm terrifying. Like how many of us avoid times when we could do that? We could speak up, but we don't because it's too scary When a parent sits and holds their kids hand and tells them stories while they sit through their 97th medical treatment That's not soft, right? It's difficult stuff and it takes courage to face it So I'm going to talk about what they call soft skills And hopefully it won't seem all that soft When I talk about love I'm talking about Something it's sort of a technical term for me If you If you think about somebody that you care about Or maybe a kid or a pet, a sweetie And you take a second to really try to picture them in your mind You feel something in here, right? There's a little spark something lights up that thing that lights up is a is a clue We have this built-in sensor that tells us what brings us joy and what's amazing And so I'm talking about that when I talk about a heart smile I'm talking about that sense that you have of the things that bring you joy And in fact like a lot of different psychologists have talked about universal human needs or fundamental human needs You all know about Maslow And there were some other people Max Neath Rosenberg a whole bunch of them have talked about what it is that people need to thrive and And these are things that set off our heart smile they set off our sense of what love is These are some of those things creativity. We like creating things. We like being cared for and caring for other people Learning when I look at learning it seems kind of dry to me But when I think about what I've discovered about quantum physics Then it comes back then I get the spark right Entangled particles Frickin amazing stuff when I think about discovering an algorithm that I hadn't understood before that kind of learning That lights me up Choice we all like choice. It's something that about what it means to be human, right? And all these other things we'd like energy and we like calm at different times in different places And there's one down here at the bottom profluence profluence That I learned from my friend and mentor cheapo Hill And it means progress toward a goal. It's forward movement It's opposite is when you're sort of on a project. That's not going anywhere Or you have nobody to tell you what features are valuable or your code never gets implemented or never gets deployed Profluence is when we're making progress or moving forward with what matters to us and all these things kind of Point to this this thing that I called geek joy and When I say geek joy, I'm talking about What is it that made you become a programmer? I Imagine that everybody here remembers their first program. Yeah I'm not seeing anybody. Does anybody remember their first program cool. Okay, I Can't really see um So I think this might have been my first program you guys recognize this. Are you all too young? Although actually I think probably it was just the first line that was my first program and the second line came later And look it gets better When I first when I first read the slide I had name as input name and My friend was like We didn't have multi-character variables at the time and I had forgotten this I had completely forgotten and then I remember the dollar sign I was like dang. Okay, so So when I think about what it felt like the day I wrote this the day I got to see You know, I typed something and the computer did something. I just like Blown away. That's like the most amazing thing, right? So that brings us into like how we became this like you know You don't become a programmer because somebody says it would be a good career choice. I mean not usually not for very long Right you have to love it But then complexity Dang it So we end up in these giant messes Which I think I heard I missed Sandy talking about messes, which is bumming me out really badly, but um We end up with this being mired in legacy code with a company that won't let us write what we think we should be writing and it's like So the geek joy starts disappearing and we're like, why am I doing this and then does anybody know who these quotes are from? Just based on one word I'll bet you can name them. That's right. Uncle Bob. Dang So Uncle Bob blesses heart. I love the man and I love what he thinks of code You know, we have the same view of what beautiful code is except that he thinks that it's driven by fear And that really breaks my heart Because I don't think fear works like it's fear that makes us not refactor Oh, but I have to get this out or like, yeah, the customer is gonna yell at me or whatever, right? It's fear that makes us not write clean code So as much as I love him, I really wish you would stop with that So to me clean code Is about these things. It's about profluence.  I deserve joy So this is my theory And it's not that it doesn't also help us You know be more pleasant to work with for other people as well But I'm not motivated by Fear of being irresponsible or fear of being unprofessional I'm motivated by This is why I code Right. I code because I love to work with systems that make sense. For example There's this thing I say Why are their shoes in the refrigerator because I'm looking at some object Set up that has these ridiculous inheritances and these ridiculous like it I remember as I'm learning this I'm learning by the way, I started out as an apprentice two years ago I was coding back in the day and then I quit For like 20 years. So I came back and I'm asking my pair How is how is a customer a car or maybe it's a car a customer This makes no sense to me and I asked him like five times when we go back and forth and he's like, oh You mean why does it make sense? it doesn't and it's because It's because I was working in code that was written out of fear Like people were not doing the thing that we have this We have these options for beautiful code that makes total sense and that's what we came here for Right. We didn't come here to write like crap and not clean it up and live with it That's not why we're here. We could go like build bridges or something So there's all that complexity and there are a lot of people here to tell you how to deal with complexity But what I want to tell you is why it's worth it All right, that's like Well, let's start with this So recently human beings have discovered that we can learn from nature how to deal with complexity Nature knows how to do that nature does these amazing things that we can't even begin to imagine right? We have brains and like ecosystems So we're modeling nature now and we're trying to understand and embrace emergence When we tdd We teach our code little tiny bits of knowledge behavior that we want right The tiniest we can come up with and then we let the code Tell us what it wants to look like Assuming we're doing the rest of it and the refactoring and JB Reinsberger, I don't know if you know him. He's one of my favorite coaches because he loves code That's beautiful and he says If you do these two things remove duplication and fix bad names You'll get to Like the four rules of simple design or whatever you'll get to clean object oriented code Not that those are easy to do They take lots of study They take lots of reading sandy mess's book And listening to Justin Searles and whatnot but We do this because um We can't hold it all in our heads When we try to hold it all in our heads It gets ugly and unpleasant and icky And my heart doesn't smile And if you try to hold it all in your head The best you can come up with is the best that you can come up with and Emergence tells us we can do better than that nothing a slide. That's a sex and I get nothing Okay, there's a reason Sexual reproduction it occurred to me As I was thinking about this that sexual reproduction is collaboration Right And I don't I don't mean collaboration between people I mean, it's the way that this This world nature right that the expert at emergence that we have all around us has figured out to Not try to have it all figured out Well, I'll throw these two things together and see how that works So I think that's kind of cool Emergence is when something Bigger than the sum of its parts comes out Right Like when we cooperate with each other we both contribute or we all contribute when we collaborate with each other We keep bouncing things back and forth until new things emerge that we've never even thought of either one of us I was told if you're going to make a slide with a bunch of text you should either read it literally or Don't say anything while people read it What do you think? So that moment when you're looking at code with another developer and you're puzzling over it and you can't come to an agreement Well, they see they told me not to do that not to the paraphernalia And then something happens that neither of you could have predicted That's what emergence is It's a freaking beautiful thing It's amazing how many of you have paraprogrammed And how many of you have had an awesome experience pair programming at least once Yeah Those of you who haven't should meet up with one of those who have and pair Because it's really amazing This is actually the slide where I'm supposed to say that cooperation has two people doing their own thing And collaboration is when something new comes of it. So I'll say it again Which brings us back to geek joy And to the idea that collaboration is love Or it's part of it. It's not all of it right holding a newborn baby Standing on top of a mountain all those things are also amazing But collaboration is one of them Collaboration gets me these things So how do you get to collaboration? How do you get to those kind of art smiles? I just made that phrase up and it's really a weird one, but I like it You get there by letting go of keeping it all on your head Because knowledge needs room to grow it needs criticism and it needs things to bounce up against Right it needs to change develop It means letting go of getting it right the first time That means letting go of your need to be right Letting go of your need to have it figured out Being able to guess Change your mind This is a big part of pair programming Is the ability to be To go down a path that you don't think is the perfect path and see what happens discover what comes of it And it means letting go of holding back as you Bring unique things to the To the collaboration right you bring Your own curiosities Your own confusions your own questions and if you're holding back trying to look smart or trying to avoid conflict Then beautiful stuff doesn't emerge We don't get the same kind of beautiful code that we get if we're all in Sorry Seriously have a cold it's bad Um So confident humility Is Something i talk about when i'm talking about pair programming a lot And it's something that i think is involved in being able to code with love The reason i say confident is because You come in knowing that you have something to offer And you bring all of who you are to the work you're doing And know that emergence doesn't happen without your participation Right like ideas have to flow And so you have to bring everything that you have And i bring this up because you know a lot of us are Noobs at something a lot of us feel like we don't know anything You know that that first couple weeks on the job on a project When you spend most of your time trying to not look stupid Is it just me I think that's a thing so Confidence means you're willing to be there fully and not hide in a corner and not try to look You know not try to not draw attention But humility means knowing that you're fallible Knowing that every single idea we have is a little bit wrong Right Like they improve because of that We have ideas about how physics works and then somebody comes up with something new and we go Oh, there's more to it than we thought So we're always wrong But we're always getting closer As long as we're keeping to do this work It means being curious and investigating It means listening to the people you're working with Listening to your pair listening to your team And then showing up with all you've got Because confident humility leads us to joyful geekery which Leads us to these things And code that's infused with love Excuse me So that is all I've got and I'm noticing that I have 12 minutes left for which I apologize Um, but I'm glad I showed up with my cold anyway So do you guys have comments or questions? Hard to have questions about love and software, isn't it? Yeah My first program experience um Probably my first real pair program programming experience was um With a guy who knew a lot and was setting out to correct me Without doing a very good job of it without explaining where he was coming from And I think I went in the bathroom and cried Actually, if I'm thinking of the right one as the first one I would say I went in the bathroom and cried I'm glad you brought that up No, I really am though because like I have had some Really interesting pair program experiences and some that were really awesome and some that were just horrific That's why I said that the people who've had good ones should pair with people who haven't because It makes a huge difference And the first team I was on I walk into the room and the super agile Super stars who were supposed to be coaching the team were off on their own sort of Coding because they were experts and so that's what they had to do And there was one of the coaches who was sitting next to a woman who was working on the team And he's on his laptop and she's on the big monitor And I say I thought you guys were pairing and he said We're doing what I like to call side-by-side pairing And he knows who he is and he constantly berates me for bringing this up but That is what he actually said and when he explained to me what that meant It was that she writes the code and asks questions occasionally and he Checks his email or whatever or does something else entirely So that's not collaboration It doesn't create the new stuff All you get is whatever code she can write by herself, right?  Yeah Say again What did I do? Oh I um I raised children Um, and I did it Thank you I uh didn't send them to school Because I came to see that as a suboptimal way for them to grow So they stayed home and did what they wanted And they all turned out marvelously by the way I can tell you firsthand that you do not have to teach children to read. They will learn it by themselves Um, especially if they have lots of video games so then It's true. So so then five years ago. I dropped everything I was doing freelance work and stuff and I dropped everything to study spirituality That's actually true I went to azendo every day and I'm like, I got to figure this out. So that's what I did And two years ago, I came back to code Which I love Anybody else? Yeah Yeah You know, he is often a good pairing partner and now I have learned My part of the deal which I didn't know at the time Which is to grab the keyboard and say listen Dude, sit on your hands and talk to me like that's one of the things that Confident humility is about is being willing to take your To take your position to stand and and say I'm part of this right So now when I'm pairing with someone and they're like going off and I'm lost I say wait, I'm lost And I feel inside. I'm terrified that I'm slowing everybody down But it actually turns out always that I'm contributing Anybody else? Yeah Is uncle Bob what? Only about here, you know Um he's like Okay, just to me He's like, um That's how he loves Right, he wants to encourage you to be as good as you can And I think he doesn't trust that you can do that by striving for love He wants to make sure that you get discipline And uh, it's not my approach, but it's his approach Yeah, I don't think I don't think anybody is all about fear. I think we're all about love except we get scared Hmm Challenging for what? Oh, he's trying to be challenging. Yeah That's probably true I know that people love him Thank you for asking How can we learn to be more courageous and less afraid Part of it's talking to yourself right and there's So in a half an hour, I wasn't able to talk about this very much, but I actually think that um loving yourself the way you love other people Is the answer to that And that involves sitting with yourself and saying Okay, if my best friend did what I just did what would I say to them?  Or would I say hey, you know, you did the best you could it's all right Right befriend yourself Somebody so the shambhala center is right around the corner, right? You could go there Seriously pay my children studied there. I think I don't know how to pronounce her last name But she writes books about that stuff and she's a very wise person about befriending yourself You pretty much have to befriend yourself before you can befriend the world you want to walk through the world loving It's got it. You've got to love yourself And that's like there's all these calendars with attitudes on them that Sound great, but kind of make no sense. That's one of them, but it does make sense. It's just you have to dig and dig anybody else Yeah, do you guys need me to repeat the question or was that he asked about pairs with different skill sets Yeah, I do. Um, if you're the senior person sit on your hands and talk And talk and if you're the junior person if you're junior enough Be humble enough to let them tell you every move to make if that's what needs to happen And then when you're ready to make moves of your own then say that out loud But the other thing is you have to I mean you have to be brave You have to say give me the freaking keyboard Like after the fourth time you've asked nicely You have to say look i'm falling asleep either. I'm here pairing with you or I will go do something else, but we got to We got to figure this out. This is why it's not unicorns farting rainbows, right? It's like saying hey dude, are you not listening or what?   It's your job Okay, I'm good. Any other questions? Thanks


So, hi everybody and welcome to the Gold Dev Room of FOSDEM 2018. We have the same room that last time, which is too small and it's still pretty small. So thank you so much for lining up and like being patient and being nice to the people at the door. We're trying to be nice to you too, which is hard sometimes. Anyway, so we're going to start the Dev Room with the State of Gold, which I've given a bunch of times. And we're going to be talking about where we are today. Which is almost, almost releasing Go 1.10. We're still not there. So I'm Francesca, I'm probably by the way. I used to be a developer at Bucketagoo Cloud Platform and the Go team. And now I work as a VP of Developer Relations at Source, which are the ones doing these t-shirts and all the cool stuff and we are hiring. Now that I've said that. So Go 1.8 was released one year ago here at FOSDEM basically.  And if you don't know what it's new in Go 1.9, there's a lot of cool stuff that I will not cover here. Because there's already enough stuff in Go 1.10. So we're going to be talking about Go 1.10, which is already out, kind of. There's a release candidate one that was released in January 25. And you should check it out. It's very easy to download. Also, you can try it with Docker directly if you want to try it. And we're going to be talking about all of the things that we released in Go 1.10, which is not much, but there's actually a lot. You will see why. And yeah, Go 1.10 will release soon. We don't know when. The slides are online if you want to check them out. It's campodocad slash L slash SOG, state of go, 110, 110.  So some of the examples will not work. Do not file issues. It's expected. That is what happens when you do these kind of talks. So the agenda, we're going to be talking about the language. All the changes to the language. All the changes to ports, so all the architectures that we support. The tooling, the standard library, performance, and the community. So changes to the language, nothing. That's it. There's some small changes in the, like, basically changing the specification for some ambiguities that we had. But that's it. There's nothing new, absolutely nothing. So that's easy. Cool. And then the second section, ports. What other architectures are we supporting that we didn't support before? None. But here there's some changes. So for all the BSDs, we are limiting to what version we're supporting. So if you're using one of the BSDs, please check the constraints that we're adding. Basically you need to use something slightly newer. Also for OSX, we're going to need to require also your submitting. So the next version will require just sanity. So this is basically a warning. Go on dot 11 will not support your sanity, so you'll need to upgrade. But being how aggressive Apple is at upgrading, I'm sure you will. Also Windows will not support Windows XP or Vista. So if you're using those, yeah, sorry. There was a really good burn on that bug basically saying if you're using Windows Vista, you should not be worried about security upgrades on go because it's Windows Vista.  So it said, I will not say who said these. I'll just leave it this way. You can find it. It says you won't get secure fixes. But if you're running XP, you're not worried about that. So that's pretty funny. Okay, changes to the tooling. And here there's way more stuff. All of the changes can be divided into two sections. It's easier to use and also everything is faster. So what is easier to use? If you remember, go path became optional in go on the date. Now go route is also optional. And it's basically reduced from the binary location. So that means that if you download go and you run it, it works. That's it. You don't need to set up go route, go path or anything like that, which is pretty useful. So we added a variable to check where you want to create your temporary directories. It's called gotemdir. You can also control it with temdir in most OSes. But it's being created if you think it's useful for you. Other than that, everything is faster. This is actually really cool. So when you do go build and go install, all of the things that have been compiled that are in our binaries, because all the binaries end up in the bin directory, all the packages that you compile end up in the package directory. That is not true anymore. Now what happens is that those compile packages are cached. And only the ones that you actually ask to compile, so if you say compile, I don't know, trying to find one, let's say OS. And OS requires IO. OS will end up OS.A will be in the compile somewhere. But IO will be implicitly compiled. So you will not see it. The important thing is that these caches are now kept, which means that if you compile again, you don't need to recompile all of the code. That's what go build-i used to do. If you use cgo, Paul, you've used that before, you don't need to do it. It's already implicit, and it works faster all the time. Similarly, you get caches for testing, so not only for the building, but also for the execution of tests. And these are actually done in a quite smart way. So the tests are cached as long as the old environment variables that the code checks did not change, that the file system did not change, and things like this. So your test will actually run when necessary. If you want to force it to run, you can say dash count equal ones equals one, and that will force to run the test once, which means no cache. Also, we added vet. So when you do go test, if you have something that, for instance, is, let's say, a printf with a format that has more parameters than the parameters you're passing, your test will fail, which is new, which means that some files will test, but your code was wrong. So that's not breaking all that one comparability. What else? Cover profile supports now many packages at the same time, which is cool, because it means that you can run your tests faster, too. You can create one single profile coverage for all of your libraries, which is pretty nice. Also, fail fast to stop all the tests when one fails, and dash JSON, so you don't need to parse the output of tests anymore. You can just read JSON, which is nice. And that's pretty much it. So a small detail. How many of you know what a three index slice is? Not that many. Cool. So that's why I'm going to explain it, because it's actually something interesting. So when you write code, you have some text here, which is a slice of bytes that says hello for them. If you call desk, I'm just printing the value of the capacity and the length. And you get from 0 to 5. And you get the capacity and the length. You're going to see that you get the length is 5, because it says hello, but the capacity is 16. That capacity means that from this slice, hello, I can access the rest of the slice. So if I append something, I'm actually overriding the original slice. And that's something that it's not something you want to do many times. If you're sharing pieces of slice, you might want to say, this is your piece of slice. You cannot overwrite outside this. In order to do this, you just add this 5 here. That 5, what it does is to says, I'm getting the elements from 0 to 5, and the capacity also goes up to the element 5. Now if you do that, when you append, you're actually appending on that slice that is already full, so you reallocate somewhere else. And you do not overwrite the previous slice. There you go. So now, hello, FOSDM did not change. Now that we all know this, changes that have happened. So GoFont has changed the way it formats this expression. I do not think that many of you use it, but if you use that expression and you're checking for GoFont in your integration tests, it will fail. It has failed for me. It's just one test. So it's not huge. It's only one repo fail. But it might happen to you. There's some explanations on why you should not be doing the GoFont, making sure that the output matches, and stuff like this. I think that, well, it's kind of painful, but that's how it is. Also, it's better now. It makes way more beautiful. I think you're OK. There you go. Now we're going to talk about the changes to the ThunderLibrary. There's nothing really big. There is no new packages. How many of you remember what was the last package added to the ThunderLibrary? Yes. Bits. There you go. So yeah, you get a t-shirt.  We have not added any more packages. There's nothing in there. But all of the packages we have, we have added some stuff, and actually some things that might be very useful for code that you're writing today. So let's go back to the same example as before. So now, instead of saying from 0 to 5, what I'm doing is I'm getting fields, which is give me the first word, basically. In Go1.9, the slides you were getting had the capacity to override the previous one.    So that's a change that might be kind of tricky. So if you're using fields, fieldsfung, split or split after, and you're trusting this capacity of being able to override outside of the slides, which is kind of weird, it will break. So take that into account. Also, there's a minor change to flag that makes me really happy. It's incredibly minor. Nobody cares about it, except for me, probably. But I do care. In Go1.9, when you had a description that had, thank you, that had a line break, it would print it like this. Really ugly. That line is not with a line. Now it's well aligned. Thank you. It's really important. Also, there's changes to Godoc. These are changes that is in between the standard library and also tooling. It's a little bit on both sides. Basically, until now, you know that in the documentation, when you have a new foo that returns that point to foo, when you look at the documentation, you see it tied to the foo type. You see foo and new foo. But if you are returning a slice of foos, that was not tied to it. Now it is. So in the documentation in Godoc, you will see it slightly differently, which I think makes more sense. But also, if you're using the Godoc package, you will see that those functions, rather appearing at the package level, will appear at the type level. So if you're depending on that, that might break. But again, I think the change that totally makes sense. So yeah, before you would see func many things, which is completely related to the type thing, now you will see the type thing has two constructors. One is many things and one is new thing. So it makes a little bit more sense. Changes to text and plate. And this one is interesting. So you've all used range or a for loop, I'm sure. And you have continue and break. Now you can also use those in text and plate, not on HTML template. And I do not know why. But that's how it is. If you try to run this on HTML template, you will get an error saying, this has not been implemented. I don't know if it is because they don't want to implement it or because they're like, we don't have time to implement it. That's it. Sheep it. So this I'm ranging from 1 to 10. And what I'm saying is, if it's even, print even and continue, which means that it will not print odd. Otherwise, it will print odd. And when we get to five, we'll break and finish the loop. So if we print this. We can add odd, even, odd, and we're done. Is there any water? No. There's a bucket of water, thank you. That is very useful. Very useful people. That's OK. OK, this is the change that I care about the most, I'd say, in all of Go 1.10. I'm sure you've all used bytes buffer as a way to create strings. Basically, you create it and it has the write method. It's a writer. And then you can use fprint or fprintf or fprintlend to write stuff into the bytes, into the bytes buffer. And then at the end, get the string. So you get the bytes buffer.  And then buff.string will print it. When you print this, you will see that I actually also added how many bytes we allocated. We allocated 856 bytes to do all of these things, which is a lot, but who cares? It's mostly the string. So now you have the strings builder. And the strings builder basically is a specific solution for the case of building strings. So it does not have all of the power of bytes, but in exchange, it has more guarantees. So one of the guarantees that it has is that it doesn't need to do a copy of the string every single time you try to get the string from the bytes. From a slice of bytes to a string, you need to do a copy because a slice of bytes, you can change it. A string is immutable. So you need to do a copy to ensure that that happens. With the strings builder, that bytes buffer is not accessible. Therefore, you don't need to do those copies. You know that those strings will never change, because you don't have access to those. So when is this good? So if you're doing something like this where you're adding emoji or anything, you're adding a piece of string to a bytes buffer, and you keep on adding more and more, and every single time you convert that to a string, you're actually forcing a copy and allocation of that string over and over and over, which means that if you get a benchmark, you're going to see that that's allocating 10,317 bytes. If you change that to instead being a bytes buffer to be a strings builder, you go to 22 bytes, which means that also it's way faster. It's like 30 times faster, something like that, which is awesome. Now, if you're not doing that, it is a little bit worse than bytes buffer. But this is the case where you're just adding more stuff and basically doing that allocation at the end only once. So it really depends on what you're doing, but I'd say take it out and do benchmarks and make sure that it might be better for your code, in some cases. So do not say, oh, Frances said we should just use it. No, but check it out. Unicode, we have all of these beautiful emoji. So there's 56 new emoji. I know, thank you. It's not me, it's Unicode. I think it's Unicode 10 or something like that. It has 56 emoji, you cannot see them, but I prepared the top, my favorite ones. So you have Chinese food, which I love. So you have takeout and fortune cookie, and also, I forgot the name of the thing. Gyoza, sure, Gyoza. Also Argentinian people say it's empanada, sure. Curling, because it is really important. At T-Rex, it is, I think it's very cool, to be honest. Mind blown. And the most important one, which is not emoji, but it's a UTF-A character that we didn't have before and everybody was dying to have it, was Bitcoin. Yes, you can now write Bitcoin as a character in Unicode and Go 1.10 supports it. My Mac doesn't, though, so. Yeah, it's a pity. Okay, performance changes. This is fun, because I should have prepared this top with way more time, but I did not. So I ended up doing this yesterday. And by yesterday, it might be this morning. So I checked the benchmarks between Go 1.9 and Go 1.10 on runtime, and they're pretty much the same. To the point that I removed all of the benchmarks that had actually significant changes, and all were gone. So either I'm totally wrong, which is a possibility, or they're actually basically the same speed, which is not shocking, because I don't think there's been that much work on performance for these pieces. For the compiler, though, I was completely mistaken. I thought that this was the runtime, if it was like this way slower. But these actually, if you don't know how to read it, it's not important. The important thing is the last number, is how long it takes for the Go compiler to compile the standard library and all the commands. I go from, go vet, and all of those. And it takes 10% less, so it's 10% faster than before, which is cool. It's not huge, but if you get in 10% performance boost on all of your compilations, not running, but compilations, that's pretty good.  Every single time I've done this talk since Go 1.5, I've added the same tweet, the same tweets, actually. Brian Hadfield has this thing from Go 1.5, when he's been tweeting the pause in the garbage collection of his servers every single time he was going to the Neo version. It went from 300 milliseconds, which is crazy bad, to around 100 or something, no, around 30 or something. That was from Go 1.4 to Go 1.5. That was when we actually gave a talk about it, because like, look at this. Then from Go 1.5 to Go 1.6, we went from 40 milliseconds to four milliseconds, which is pretty amazing. From Go 1.6 to 1.7, we went from around three to around one millisecond. Then to definitely under one millisecond all the time, with Go 1.8, with Go 1.9, it stayed pretty much the same. And then with Go 1.10, I was like, hey, Brian, you have not done it, I'll give my talk tomorrow. Uh, this is yesterday, by the way. It was like, could you please do this?  And it was like, oh, if you can do it. And then I said, can I use this screenshot? Because you know, I'm a good person. And he said, yes, and he says, hi. And then I went to bed. And then this morning, he actually tweeted. And he said, yeah, cool. So he said, it looks basically the same. It's not, you know, amazing story, but he tweeted. So he's a very nice guy, so thank you, Brian. He'll be in the video. So thank you, Brian, for this. There's a couple more changes. You can read those. You can go to the Go 1.8, no, 10. Go 1.10 release notes, they're already public, just not on goland.org, they're on beta.goland.org, or tipgoland.org, same thing. So changes to the community. This is Women Who Go. They have now 26 chapters, which is amazing. They had 16 last year. I redo this slide every time. And this time I actually made the map so I can reuse it, which is nice, for the first time ever. I'm not just using paint. I was using paint. So this is really good. They're all around the world, which is amazing.  Also, they have a new board of management. I don't know how you call yourselves. New C-suite, I don't know what that means. But oh yeah, because they have C's, there you go. Yes, so March, she's here and she's one of the organizers of the room. She is the CEO of Women Who Go. Veronica Lopez, that she's still not here, but she'll be speaking later, is the CEO, no, the CFO. And then we also have Daniela Petrosak and Carolina Athletic that are also helping with new chapters and the head of support. So that's amazing. So congratulations to the four of them.   They're really cool. There's one in the middle of Russia. I was invited once, but I couldn't make it. But if you wanna go somewhere random, go in the middle of Asia. There's one Go Meetup there. Then this slide still fits in one slide, but it's getting really crazy.  So we have Go Devroom Fosden, which is today and here. Congratulations, you're here. Gophergon India, which is in March. Russia in March two. Go SF in March two. So if you wanna travel, March is a good month to travel. Then April in New York, May in Singapore, junior Reykjavik. The organizer is somewhere there. There you go. And August in Denver, September in Florianopolis, October in Florence, and then Doug Go has moved a little bit farther away. So there will not be 2018, there will be 2019 in, not the other way around. 2019, I'm mistaken with the years. That's 2019 next year. And also we have a bunch of talks today. At the end of all of these talks, we'll have a lightning talks. So Marja was working on, we'll give the link to a forum where you can apply to give talks.  We're definitely interested in listening about it. And that's it. Enjoy the rest of the day. And thank you very much. And.


Fine, so all of us talk about scaling up growing up How many of you have heard of snap deal? show of hands good How many of you have heard about MongoDB? good How many of you have heard about problems? good How many of you have not heard about aero spike? good So yeah, you haven't heard about aero spike. You have heard about snap deal go to Google do aero spike snap deal or Do snap deal no sequel. You'll get the results that I'm talking about So snap deal was using MongoDB servers. They they were using 10 MongoDB servers I don't remember the exact configurations, but yeah, they were using 10 MongoDB servers They were hitting about 10k TPS that is 10,000 transactions per second They were having problems in growing up. I mean MongoDB. It was a pain So they started benchmarking with 20k TPS They benchmark lots of stuff lots of stuff being Say Cassandra say Redis say Any no sequel thing that you can think about they try to try them all none of them worked Then they started using or other trying out aero spike. They didn't come to us. I work for the company They just went to the website. They downloaded the free community edition The community edition supports two nodes 200 GB no restrictions on features or performance they started using it and What they found that they did not need two servers They just needed one But still they went for to why simple reason redundancy one node goes down application is fine The physical machine goes down. They need to that's a reason they went in for two They were benchmarking for 20k TPS all of a sudden. I think around New Year's Yeah, they hit about 50 to 70 K transactions per second They were worried had they been on MongoDB. They would have gone down They were on aero spike Can anyone make a guess how many nodes they added immediately? I Mean 20 K TPS two nodes. So say 70 K TPS. How many nodes quick math five seven Okay, what of hands for five? Actually, they added no servers two nodes for more than enough to handle their peak or rather the sharp rise of 50 K Okay, so Unfortunately everything is Okay, so this is like a press release that we did you can go and read up about it and Yeah, another press release somewhere snap deal and I'm sorry. I'm like trying to figure out on this low resolution where things but okay So basically, let's go to the reason why I as a DevOps love aero spike I Used to work for Yahoo before joining aero spike I mean out there things things are good things scale up for me a large scale Installation was anything between say I mean it had to be a three digit number of servers for it to count as a large digit number when I came to aero spike I was talking to the lead out here and he's he told us he told me that The biggest installation aero spike had was about 24 nodes in a cluster. I was like, okay, is that large like yes How many transactions are they handling? Uh per node about 70 to 80 K transactions per second in production So yeah, that's the kind of number But then again, these are production numbers. We went to benchmarking recently We launched aero spike three and they are the kind of numbers we are dealing with a quick guess on How many numbers we are doing in say in labs just in memory database So 50 to 70 K transactions in production in labs. How many 120 500 700 We do a million transactions per second just in memory in labs in and that's in memory Just in memory not persistent with persistent storage. We use SSD as raw devices directly. There are no added file system on top of it So if you do just hundred percent writes, we do about 120 to 170 K writes Okay, I'm running short of time. So quickly saying why I love aero spike as a DevOps guy Installation simple RPM minus I start RPM as an in the folder or DPKG, whatever works on CentOS Debbie and Ubuntu red hat blah blah blah Configuration as a base package, you just want to try it out. You don't have to do anything You just do a start service start aero spike start. It's it comes up. You need to add a note What do you do nothing you just make ensure that all your notes have the exact same configuration by default you Views multicast and they just join the cluster and they work if you're trying it out on Amazon You have to add the mesh Configuration and yeah, that's a bit of manual work, but yeah again. It works So next time your dev team is trying out a no-sequel solution Or if you are already using a no-sequel solution and have problems go to aero spike comm try out the free community edition Some of your companies might have You know they want open source. So expect some news there and coming days Sure. Thank you


Hi everyone, Sean with jaspyscasebreaks.com here doing 2020 leaf flash baseball three box break Number four where every spot gets you two random hits Nine spots will open up all three boxes type in all 18 hits double the customer's name each box gets two autos and tonight only Top three names at the end of the break will do another randomizer each spot gets $50 in break credit So not too bad Here is the list of customers from Omar down to Tom and since each spot gets you two We need to double up the list So Tom judge and Tom judge the last spot mojo twice here is And then here's the list that will type in all the hits as we pull them out or at the end Once we pull them all out then we'll randomize them both lists pair them up right here And whatever you're paired up with is what you get then we'll do a separate dice roll at the Ran and randomizer at the end to give away that break credit as well Here are our last three boxes Ed Howard's really good to Kevin Ed Howard is Their brand-new draft pick from Illinois. So local high school kid that they drafted so He should be good too, but friend of Davis Sneaky sneaky. So here he is box number one Justin Fosquay Red or sorry blue flash foundations autograph starts us off 28 out of 50 big prospect for the Rangers Diego Cartaya. I want to say Dodgers Jordan Westberg that is Orioles purple seven out of 35 Tyler saw this from big prospect for the A's green flash foundations autograph 22 out of 25 Connor Phillips non-numbered and Zach mean Big ol one for the Rockies Four overall pick five over a pick something like that this year Actually, no, but yes very big prospect My sale Urbina I Was trying to figure out. I gotta look it up. I'm not sure if this is Oogeth Urbina relation kid or something like that orange auto five out of ten Sammy in Fante auto Non-numbered Cole Wilcox auto non-numbered Marco Luciano for the Giants flash of brilliance auto Carmen Ladzinski for the Pirates seven out of ten orange auto and Pete Crow Armstrong Mets prospect PCA one out of ten His mom and dad are both actors and our last box Mason win 49 out of 50 blue Dylan Carlson Cardinals non-numbered Bryce elder purple 17 out of 35 Risky Ricky Venasco blue 42 out of 50 Wilder patino 27 out of 50 and Jordan Walker Big ol guy for the Cardinals as well Non-numbered So there you go That was all three boxes. We're gonna pause the video type in the hits and randomize them. We'll be back Okay, we're back everything is typed in here from Justin Fosquay first auto From the first box down to Jordan Walker and the last auto from the third box Here is the original list again customers from Omar down to Tom judge last spot mojo Remember, we doubled up the list for 18 spots dice roll two and a six eight times eighth and final time from Kevin Eicher down to Omar Eight times on the dice or eight times on the randomizer eight times on the dice And now eight times on the hits eighth and final time from Marco Luciano Down to Ricky Venasco eight times and eight on the dice And there you go. Let's take a look and see how it took out Kevin Eicher with the Marco Luciano Tom judge with the Sammian Fonte Omar with the Mason win to 50 Jason Siebert with Diogo Cartaya Omar with the Carmen Blodzinski orange to 10 and the Dylan Carlson Anthony Chan with my cell Urbina orange out of 10 Kevin Eicher with the Connor Phillips Omar with the Jordan Westberg purple out of 35 Tom judge with the Wilderd Patino blue out of 50 Jason Siebert with the Pete Crow Armstrong orange out of 10. Congrats Raymond de Jesus with the Zach vene and the Jordan Walker Congrats Raymond. Omar with the Tyler Saunders from green out of 25 Anthony Chan with the Justin Fosquay blue out of 50 Tom judge with the Bryce elder out of 35 and the Cole Wilcox and Omar with the Ricky Venasco blue out of 50 And there you go guys, that's the randomizer itself Congrats guys There is your full list of your hits next to each other Yeah, congrats Raymond very nice dude So last thing we got to do give away $150 Omar down to Tom top three names after One of the three four times And fourth and final time congrats Omar Jason and Anthony Each one of you guys is to get $50 in break credit sent to your email right now four times on the randomizer four times on the dice and there you go That was 2020 leaf flash baseball three box break two random hits each number four from jaspyscasebreaks.com I'm Sean jaspyscasebreaks.com. Thanks for hanging out. We'll see you next time