 We're going to get started in about two minutes, so as you're coming in, please grab your seat. We'll get started in about two minutes. Mic check six. Mic check six. Mic check five. Mic check five. Mic check five. Yeah, we're getting ready to go. Ready to go? I think we're good. And then that's the speaker mic. This is your microphone. Do you want anything on the podium right now? Okay, got it. You look like you had a handful of things, so... No, I'm... You changed your... Oh, I just had the longest... Is that good? Yeah. You're second. Second. Second. All right. Good evening, upscalers. How's it going? That's not bad after a long Saturday. That's impressive. Well, welcome, everyone. My name's Jason Hibbins. I'm a community moderator... community moderator. Oh my gosh. It has been a long day. I'm a community manager over at opensource.com. We partnered with upscaled this year to hopefully put on a good show for you tonight. This is Hannah, say hi. I'm Hannah. I help run publicity here at scale. Keep in, Jason, in check. So this is the first time we've done this. First ever. And so hopefully we curated some amazing content for you. We've got, I think, nine speakers tonight. So for those of you not familiar with the format, the speakers have five minutes. Most of them have 20 slides. Some of them have 13. Someone has 15. And someone has 17. We like to follow rules. So we're really good at math. And we're going to divide by 300. Anyway, so they basically have five minutes to get their message across to you. And then we have a timer up here that will start beeping when their time is up. That's your cue to clap. So I'll be a buzzer. There's no orchestra that will play me off. Nope. Too soon. Just kidding. Moonlight. So both Hannah and I will be kind of co-hosting and emceeing this evening. And we'll be introducing the speakers. Is there anything else that we need to know? Oh. We told them you're a friendly audience. So be friendly. Don't heckle that much. There's no empty beer bottles so they can't throw them at you. Are we ready to go? Anything else? The next speaker is Kasky. And he's going to be talking about operations lessons from a 17th century samurai. And as soon as you start talking, I'm going to press your timer button. As soon as I start talking? Yeah, like right now. Well, you can't start until my slides show up. Patrick, slides please. Hopefully there's some slides. Maybe. Hey, okay, great. My name's Kasky. I'm here to talk about operations lessons from samurai. I was reading this guy's book a few years ago and I discovered a lot of parallels between the wisdom of being a samurai and the wisdom of being in operations. The guy's name is Miyamoto Musashi. He's one of the most storied samurai in Japanese history. Whether it's real history or not, is open to debate. But he is a master samurai. He achieved a peak death rate of 143 nanokills per second during his career. And there are basically five rings or five levels of reality. Everything from the earth to the ether, just like in our jobs, just like in our systems. And so these basically organized his view on how the world works. The earthy of the practical and the concrete in the middle of a whole bunch of different techniques like the stab him in the face technique which probably was pretty successful. And at the top of the theory, the idea is about what's good in life and so on. So his first lesson is don't get hung up on implementations. It's outcomes that matter. Now in his time it was whether the long sword or the short sword was the best. In our day it's EMAX VI. It's push versus pull architecture. It doesn't matter. Outcomes are what matter. Then he gets a little bit full of himself. He was the world's first full stack samurai. He said you have to know everything in combat to be a good samurai even though you're only a samurai. So he was the world's first full stack samurai being a samurai. Know your KPIs. There's always some number which implies everything about what your service is and how it's behaving. Know that number, be able to find it and that will imply everything else about how your day is going. Next, scale. He understood scale. If you knew how to stab one guy in the face you knew how to stab 100 guys in the face. You could stab a thousand people in the face. So he knew that being able to replicate your service you deploy it. One time you can deploy it 100 times. Containerize your kills. He also knew that latency was key. Latency was the most important thing in the world. Your network, your back end, your database it all adds up. Timing and tempo is essential in combat and it's essential in online services as well. Avoid self deception. This is the big thing. Hope is not a strategy. Know your services up. Know why they're working. It just means your monitoring system is down. Right? So you need to practice. Practice, practice, practice. Operations is a muscle. If you don't exercise the procedure you don't know that it works. If you've never tried to restore a backup you don't know the backup works. We've seen evidence of that both in GitHub and Amazon recently. They discovered that restarting things are hard. Know all of your service dependencies. Be familiar with how they fail in soft ways. Soft failures are often the most difficult thing to diagnose because something's just slow and your service now behaves in a different way. Next, the way of professions. This was his metaphor for life cycle. A junior developer, a junior engineer has a different mind than a senior engineer but leverage that wisdom. Leverage the wisdom of the knowledgeable and leverage the naivete of the new guy to find information that is useful. Not all nines are of equal value. Know the business metrics that apply to your company. There's meaning in numbers but also whether your service is up or not isn't necessarily the only thing. Sometimes actually staying in business is important. Develop your intuition. Know when you see something that says that's not going to work and you get that feeling like this is clearly a bad idea but you don't know exactly why unpack that intuition and get learning from it that you can actually make use of. There are always blind spots in your system. Know are changing that are changing. There's no such thing as a static system in deployment. Either your users are changing or your dependencies are changing. Change is happening. You must always be moving. It's a treadmill. There's no way off of it. There's no such thing as a small service. There's no such thing as a thing that is so irrelevant that it doesn't matter and it can fail and we don't care about. Everything is important. There's no small services. They're only small engineers. Microservices, yeah. Microservices are smaller I only got five minutes. Automate your toil. Do not fall into the trap that there is any process which is so simple it doesn't warrant automation. If it's easy enough to, if it's so simple it doesn't warrant automation, it's easy to automate. If it's so complex you can't automate it. It's too complex for a human to do it, so automate it. So don't do anything which is of no use and always drive automation. Finally, the most important thing that Miyamoto Masashi has to say is instill vigor in your hairline. Vigorous hair. Miyamoto Masashi was so vigorous in his hair his hair had to be buried 200 miles away in a different grave. We're going to start our timer again and as a quick reminder that we want to support our speakers on Twitter, Facebook, other social media platforms maybe IRC, I know we really love that platform in this community, yeah. There is a social media, what? Is that like Slack? Ooh, should we boo? Anyway, before we get totally off track there is a social media cheat sheet guide that was posted on the scale blog on the front page. It has everyone's Twitter, Facebook contact info. You can also find it on SoCalLinuxExpo's Twitter feed. So check that out, make sure you tweet send photos, we'd love to hear from you. And on that note I like to introduce our next speaker. Some of you might know who he is but if you don't know who he is because he just gave a talk about being a celebrity at scale but this talk is a little bit different. Corey Quinn is going to be talking about his new app idea at twitterforpets.com walk through. So with that note, give it up for Corey and I'm going to start his timer. Thank you. Do I get slides too? Maybe, if you're lucky. Luck isn't always good. Alright, thank you all for listening to me. My name is Corey Quinn and by day I run a consultancy that helps companies with their horrifying AWS bills. It's fun, but it's not really enough to consume all of my energies. So I figured I was time for me to start a side project. Like my hero, Jack Dorsey, who runs Twitter and Square at the same time. Two amazing companies that are doing very well in the marketplace. No trouble at all there. But the question was what do I find up building a company to do? This is my dog, Ethel. She has a number of different hobbies that I want to support including stealing food, sleeping on furniture, she's not supposed to be sleeping on, yelling at other animals, biting people, and her personal favorite hobby, shitposting on social media. The trouble is, is that lately social media has not been the same. Nothing has happened to it. Specifically, people who are very highly placed are basically doing the same types of unwanted behaviors again and again and again. You see the same phrasing like a dog, like a dog, like a dog. That is a goddamn slur. And frankly, we don't have to take that anymore. That's why I decided it was time to stop complaining and do something about it. Hence, I'm launching twitterforpets.com. Because it's been such a runaway success, we've had to do some interesting things to scale it. And I wanted to tell you what we've done, how we've done it, and why. We started off by hosting it in Amazon's GovCloud, the region where you go if you need to do government contract work and FedRAMP clients. It seems like that might be something of increasing relevance in the months to come. But you don't want to be single region. So we have our other leg replicating to China. It seemed like a smart idea at the time. Why not? But now we have a problem with only two legs. If that link breaks, you have split brain. Each one thinks it's in charge. Now, someone on twitter after the Amazon outage was talking about their own custom S3 approach. So we decided to put all our product assets there, too. We think it's somewhere in Appalachia, but none of us are brave to go there and find out ourselves. We hope for the best. Now, managing secrets, things like passwords, API credentials to get these things started back up again, like our database, for example, we keep them in the safest place we could find. Safely in another city in a safe deposit box. Now, how do we use that to start our system? Great question. Like so many other secret solutions, it starts with a Jenkins job. Someone clicks a button or somebody makes a commit and it launches. It's great. Jenkins then decides it's going to reach out through the API to task grab it. We send someone to the post office box to retrieve the secret. But that's great. There are many cities away. How do they get it to us? Excellent question. Thanks to the power forever stamps, we can keep costs under control here. They take it down to the postal service and in somewhere between one to 12 business days, it winds up showing up at our office ready to start the database. At which point we then read it into Alexa, because typing it in just seems not quite as secure. Plus, it makes us feel like we're on the bleeding edge of technology. From there, the Alexa skill winds up piping that password to the database, which is listening via a net cat process. And unlike everything else in this ridiculous bullshit pipeline, I actually saw this at a previous job and it's how we did secrets. I want to die. So let's talk about databases. Our VCs have put a tremendous amount of money into our company and we feel obligated to waste absolutely all of it. So we selected Oracle as our database engine of choice. But under load, it gets very difficult to scale. Now there's this concept known as sentiment analysis, where we look at the tweets or the barks and figure out, are they positive? Are they negative? And that's how we've decided to begin sharding it. Just like real Twitter, we shard based upon racism. Unfortunately, the hold my beer I'm running for president shard is getting a lot more traffic than we thought. It's a hell of a hotspot and it's turning into a bit of a problem. If you'd like to join us, you can apply or download these and other of my talks at twitterforpets.com. Thanks. That was awesome. Look at that. You keep that. Hand that to the next speaker. Good job. Stop. Well, Kasky Corey, thanks for getting us to a great start. We're going to maybe go a little more technical on the next talk. So we've got Eduardo coming up and we're going to talk about scaling your log management. And we'll start your timer when the slides come up. Sorry, I didn't prepare something not technical this time. So let's get started and try to do some talking. Let's go ahead. We got some extra time. Awkward. Yeah. Honestly, I feel comfortable but it's not like I'm going to make a stand-up comedy. So the presentation is about making painless logging at scale. Everybody agrees that logging is not something fun. It's mostly boring but at some point you had to deal with it. Either in your life of troubleshooting for monitoring or whatever. So my goal here is to explain how to make it a little bit painless with some tools that we have built. We're not trying to sell something but give you some content about it. Oh, there's a delay. So before you do your own logs in the past, you have your application writing to logs and your analysis. But when your application scales, you got a big problem because you had to analyze different scenarios. If you're talking about Kubernetes, you had to analyze different logs from different ports or different nodes. So it's quite complex. And now if you add the complexity about having some nodes where each application has its own database, they're having their own log volume and you would like to aggregate those logs it becomes harder and even a pain. At this time this is not painless. Wait. So how is this complexity? So how do you deal with different log sources of information with unstructured logs? Because you have Apache logs we just don't have an instructor. You have NGINX logs or MySQL logs there's no JSON, there's nothing like that. We just have it right now. And you would like to aggregate those logs because you want to do some analysis over that. So if we look at the logging pipeline we have a few phases. You need to understand what's going on inside logging. So we have log messages, parts, filter, buffer, routing and destinations. And right now we're going to introduce each one in 20 seconds. When we have log messages we have different input source of data. Most of them are log files. When we tell, for example, some container staff, we're contelling log files which has some JSON format on it or maybe we're consuming data from the journal D. What that means the logging can happen from any kind of input source of data but this is part of the logging pipeline and sadly we need to deal with it. And after we get the information we need to try to give it some structure because at some point I want to collect everything, I want to discard some information or I want to enrich this information with something. So we need some parts phase. So logging it's still complex. We need to collect data and parse the data and then we jump to filter the data. We were in a session like minutes ago and they said hey I have like 20 nodes fetching data from syslog but I'm paying a bunch of money on the elastic search service and I don't want to do that. So we would like to discard some message. We would like to filter that or maybe in Kubernetes environment to add some metadata. And then when we filter the data then we would like to make some buffering. Nobody wants to lose data in this scenario. If you try to collect the data, filter and parse and you're trying to send that information to a database and your database is down you're going to lose data. So buffering is a special capability in logging that you need to have it that it's a mass in your pipeline and then when you have your buffering you will like to write this data to some destination. And writing is important. Some people said I want to write the data to my real-time engine which is called elastic search and others says I want to do my own map reduce with Hadoop. So writing allows you to take this buffer of data which collected parser filtered and send it to multiple destination for your own needs. But this login pipeline at the end means that you are collecting something and delivering some data to some backend like a Lata base elastic search, Redis or Amazon web services between others. But having implemented this in the old fashion way with old Chrome scripts with bash is quite expensive in terms of memory and CPU consumption. That's why we need some kind of specialized tools that can help on this. That's why we introduced two concepts which are called log forwarder and also the log aggregator and each one with its own tool to try to separate the logic about the problem that you need to solve. Fluent bit is a log forwarder, it's pretty lightweight, it's made in C and Fluent D, it's made in a mix with Ruby and C. Both projects are fully open source integrated with Kubernetes and you can start using it from right now. Thank you. We'll reset our timer here. Up next, we have Bob and he's going to give us a talk about one minute guide to making great technical documentation which I know most open source projects probably need some help on. So let's give it up for Bob. Is this working? Oh good. You're about to get two stories at once. One is up there, read closely and then one's down here. But I need you to do something pay very close attention with your account open. R-E-S-E-L-B-O-B that's me at R-E-S-E-L-B-O-B space R-O-C-K-S Okay? Please, I have a poor sense of self. I go to this thing every 10 seconds to make sure I exist. Alright, so if you don't, the talk Okay, so here's the deal. Pay attention up there because this is going to tell you everything you know and I'm going to tell you a story down here. So I used to work for a gateway, born gateway 2000 and every month we printed millions of user manuals. This was actually before the internet and then we went online. And we're talking millions of dollars millions of dollars every month. We were a cost center. We didn't make money we're an expense. We did a study. I worked in the usability department for two years and what I discovered we discovered, the group of us discovered was that people don't read. That was like a 40 million dollar lesson that people don't read. But they do look at pictures. So when I went to work for MacMillan and I wrote my four books which are now out of print and completely useless I did get a $6,000 check last month. Wow. I like that and I am bragging. So here's the deal. Here's what I was taught at MacMillan. You always write to a well-formed outline always, no exception. The second thing I learned we're still on the outline part and see me afterwards if you want to know how to write a well-formed outline. The second thing I learned is you drop your pictures your tables and your listings R-E-S-E-L-B-O-B space R-O-C-K-S I got five minutes. Then after you drop your pictures I am getting your attention right? That's your pictures and your listings. After you do that you write your captions. You write your captions and here's a trick I learned at MacMillan. You do what's called a value-add caption. In other words if it's a dog don't say this is a dog say the dog is walking down the aisles at upscale. They're cool. Say that. Alright? So you drop because the eyeball goes to the picture and the outline will create the cognitive framework you need in order to have the document make sense. The eyeball goes to the picture and then proximity dictates from the picture it will go to the caption. That's how the world works. $40 million lesson. You got it for free. R-E-S-E-L-B-O-B space rocks. Keep doing it. It's good. Now you can see you drop your figures and notice those are value-add captions. Okay? After you drop your captions and this was enforced to me by my editors when there were a thing called editors in technical publishing now everybody's an expert so what do we need editors for? Right? After you drop your captions the next thing you do is you write your copy around the illustration. And make sure you do not and when you do your copy make sure any time you bring up a concept it refers directly to the caption number. The mind does not like interruptions. Do not abuse the reader. In other words if you're saying look at the figure below go to figure one below that will describe how to do asynchronous communication in a distributed environment. You cannot confuse the cognitive strain. R-E-S-E-L-B-O-B-R-O-C-K-S and the reason I am doing this over and over again is because what I learned is it takes repetition to get the concept to stick. Some people only need three repetitions the rest of you will need eleven. Okay? Thank you. B-O-B-O... Caught up in that. Fun fact we had a little trouble importing Bob's slides so what 45 minutes ago Patrick and I were sitting in the back I exported each of his ODT pages to a PNG cropped them in GIMP imported them to the open presentation office and then we exported it so we could use them today. That was a fun time. Too many. Our next speaker we're going to see if we can do some case study here. The Oracle versus Google case on fair use of APIs in five minutes. So come up to the stage Jeff and I'm really excited to see this. Little feedback? Okay. So my name is Jeff Kaufman. I'm an open source attorney for Red Hat and I'm also an adjunct law professor at the Thomas Jefferson School of Law in San Diego. The subject of my lightning talk today is on the recent Oracle v. Google case. So in this case Oracle complained that approximately 6,000 method declarations were copied verbatim from Oracle's Java standard edition platform known as Java SE. And they further complained that in the process of copying those declarations they copied the API structure and organization, the taxonomy which I show graphically on the next slide. So here's a graphic depicting in part the API elements that were copied by Google and on the right side are the method declarations in green. And then we have the overall structure of how all these method declarations were organized in the various classes and packages. This case is not about copying any implementing code for the specific method declarations. That was not in dispute generally. So we have a complex set of events in trial history. So let's try to summarize. Starting in 2012, the jury found that Google infringed the copyrights in the API to the extent the API is actually protected by copyright. However, the judge then held that the API was not copyrightable. So Google won this round because you can't be liable for infringing a copyright when none exists. Oracle then appeals, the appellate court reversed finding that the API is copyrightable. So Google's way out of this was to prevail on an argument that their use of the API was a fair use under the law. And the big news last year is that Google succeeded on that fair use argument. It's important to know that the appellate court still stands. Oracle's API code is still copyrightable. And this ruling was not reversed in spite of Google's successful fair use argument. And I want to talk about the appellate court called the Court of Appeals of the Federal Circuit, CAFC. It's a nationwide court that hears lots of cases but generally not copyright cases. And for a number of different reasons this case may not become significant legal precedent for other U.S. courts, but that remains to be seen. With that background behind us I will now explain fair use and some of the factors and arguments that Google may have advanced to convince the jury that their use of the API was a fair use under the law. Please note that Google's arguments in this case are highly fact specific. And what Google argued may not be applicable to other situations involving APIs and fair use. To start, the jury was instructed that a fair use argument is a factor test involving a combination of four statutory factors and one non-statutory factor. Unfortunately I don't have time to go through all of them but what we're going to do is discuss purpose and character of use, the green box. And we're going to go into that in a little bit more detail. So one aspect of that factor is bad faith. Naturally bad faith doesn't support fair use. Here Oracle may have argued that Google chose to copy the APIs in bad faith after early negotiations with Sun and the commercial licensing aspect of Java dissolved. To counter, Google may have argued that they did not work in bad faith since it's common developer practice to duplicate method declarations. The character and purpose use factor also includes the idea that using a work for commercial purposes weighs strongly against a finding of fair use. This is one of the key elements of fair use I learned in law school, which frankly until I studied this case in detail why I was initially surprised that Google succeeded on its fair use argument because Android was such a huge commercial success. So for Google to mitigate this factor Google could have argued that their actions were significantly non-commercial since they were making Android available under open source terms to the community. And then there's another powerful argument to mitigate commercial purpose. But we first need to discuss the concept of transforming a work. Google may have argued that they transform Oracle's work from a desktop solution to a mobile solution, right, for Android. And it turns out that under fair use law when you transform a work that way the fact that there's commercial purpose actually recedes an importance. I wish I had time to talk about other factors but I don't, but the one I will talk about briefly is other factors and this allows the jury to consider other circumstances that bear on the ultimate purpose of the copyright act including promoting the progress of science. So did Android promote the progress of science? So this is a copy of the form provided to the jury to record their decision on whether Google's use of the API was a fair use. So based on this discussion and thinking about this and other factors on the previous slide what would your answer be? Thanks for your five minutes. Good luck out there. Alright, so for some lightning talk trivia there is an event that happens in multiple locations around the world called Ignite and that's what mostly popularized this talk type series. And so earlier in this week on Thursday there was a workshop done about how to write your very first Ignite talk. And so our next presenter actually went through that experience and was nominated as one of the best to present. So we included him in our upscale presentation so give him an extra friendly audience as it's his first Ignite talk. So Mike, well let's welcome Michael to the stage and he's going to be talking about an open source community of successful learnings. Sorry, cut off. Maybe I messed it up. Thank you very much. Thank you. In 2009 I heard this rumor that no matter what you think, you can't take it with you when you die. So I thought, well why spend all my time working on enriching myself when I could be enriching the world. And so I looked around and see some of the biggest problems that we had and one of them as an engineer we're problem solvers so how can I solve the biggest problem I looked around and I couldn't find something and then I realized student debt. The cost of college everybody was complaining about it in the media but nobody was doing a scam thing about it. So 44 million of you Americans have this debt. They can't buy a house many of them. They actually have to live without. So I started free education bringing in all the open core square from MIT, Stanford, UC Berkeley and an open community LMS and $250 a month sound like a good idea. So I started off and this is where I camp every day for years. Started world mentoring academy free education leading to college degrees. Utilizing the open core square from MIT and Stanford I aligned them with college boards, APs, CLEPS DSSTs, TECEs the ISSS and all the other acronyms. And students can learn from free from my free school mobile education using courses from MIT Harvard, UC Berkeley, UCLA and all the other fine institutions. Now with mobile education it allows you to do a lot of things that you would not normally do if you were online or distance. You can use these particular courses at Thomas Edison State University and Charter Oaks both regionally accredited state universities they're not fly by night for profits. Some students are getting their bachelors from as little as $5,000 in fact including we have a program for bachelors in computer science utilizing your A pluses, your N pluses, your LPI's and all the others for your course and you can hack your damn education for less than $5,000. You can also use mobile education to do sabbaticals, gap years, bridge years and experimental learning, your learning languages and being part of NGOs and things of that nature between your high school and your college going out and learning things. So picture this you're 17 years old and you're my child and I say you know what you've been in school for 12 to 14 years you're burned out. If you go to college you likely get alcohol poisoning. So you decide to go to Lyon France, the French cooking capital of the world you study with a three star rate Michelin chef as a dishwasher. During your breaks you're doing Julianne cuts with the three year program that we have and calling the arts. After a while chef notices and he goes hey Mona me France so guess what you got learned French. So on your day off you catch a train to go to Paris, you go to Louvre, you study art history, art appreciation. You're not looking at the pitch of the mullies, you're experiencing it. After two years abroad you come back in the brick and mortar. Your friends brag about doing bong heads in fraternity, you talk about parting ass off, getting drunk in the vineyards having a prescient life. Better yet you decide to go work with doctors without borders. You do all of your work with the medicine, you have the first two years of Harvard Medical School on your terabyte drive, your raspberry pie, whatever flavor you like. Or you decide, you learn all about it, you decide to go work as a Deccan and a marine research vessel with a two terabyte drive, lab just blow deck, you also discover what marine biology is like and whether or not you get seasick or not. So this is a far better richer way to learn things as well including taking your education and going into creative spaces and do project based and design based learning. We retain much more by when we learn by doing instead of stage on the stage like me. You're probably going to only remember 5 to 10 percent of whatever I say. So anyway, what I do with all my students is I get them going out to maker spaces in biological labs and do project based learning and I started a second project where I cataloged all that in BadgeMap where you have hacker spaces, bio labs, creative spaces YouTube collaborations, filmmaking, robot FRC teams and then I leave that on layers in Google Maps and attach that to the education so that you can then do things. So what is it going to be the future of education? Well, come over and choose some fat with me. It's booth 7-11 tomorrow and we'll talk about what may happen in the future. I also like to ask if you guys might participate with me because $250 a month is in a solid plan. Although I've been doing it for 8 years I do enjoy it, but I need your help. Professor Clayton Christensen of Harvard Business School said 15 years, 50 percent of the universities will be gone. Let's be a part of that. Thanks a lot. Alright, is Dwayne O'Brien here? Hey, so Dwayne ran the workshop on Thursday so he wants to run it again so if you're interested in doing this talk to Dwayne and give him some feedback. So thanks for helping us out on Thursday. Let's give Dwayne a hand for that really quick. Okay. Alright, quick poll. How many people have been to a job interview here? Okay. How many people have been on the other side and interviewed people for the job? How many people think both of those experiences sucked? Okay. Well, we're going to hopefully solve that problem in 5 minutes. We've got Kais here to talk about interviewing and how we can better. Thank you. Should I wait for a minute? I can take a selfie. I can do a selfie with you guys. Alright, crowd. Can we see you all? Thanks all. Okay. My name is Kais Punawala and I'm a developer. I really think, or actually I know, technical interviewing sucks. How do I know that it sucks? Well, just like taxes, there's an entire industry built around it. When the next slide comes up, you'll see what I mean. There are things like books that you can purchase. Cracking the interview is one of them. There are schools that actually teach you how to go through the entire interview process. There are many different ways you can waste hours and hours studying something that will never actually help you on the job. What makes it suck the most? I think would be the whiteboards. So you might have seen this recently on Twitter trending. I've been posting including the creators of Ruby on Rails and the creator behind Homebrew on Mac. They can't actually pass these coding interviews. And it's because of the whiteboards. Whiteboard questions suck. They ask you to develop something that you did in college or if you didn't go to college it's even worse. What if you could actually work with your candidate? Gauge them for TeamFit. Avoid bias shortcuts like universities, degrees, previous companies not stress them the f out. You know, actually treat the candidate like they're an employee. So here's our process we've been using for the past two years. We do a phone screen, followed by a take home. That take home we actually interact with the candidate on. It's a real project. We work with them. And then after that we do a code review with them in person. So we get to interact directly with them as a team. And then we have one-on-one conversations where we just gauge TeamFit. Yes, I did say take home. There's a lot of hate and love for it online. Some people love it and they think that they don't want to do whiteboards anymore. But other people say that it's a waste of their time. We're having them do some type of coding test. Well, I don't see it that way. I see it as a valuable thing. The reason for that is the way our prompts are designed. Our work-related. Explicitly allow the use of any resources. Import everything. Google anything. They're ambiguous. They can be both quick and in-depth. They encourage questions. You want to work with the candidate. So here's a sample that I came up with. I want you to build me a restful API that works with files. Okay. Well, what do you want to use? Local file system, HDFS library, Azure, blob? Do you want the methods to be get, post, put, delete? Do you want all of these to do something? Well, after they ask these questions, you want to answer them. You want to work with this candidate. And if you didn't ask a question, I'm going to choose the one you didn't choose. I want to tell you about any bugs that I found. I'm going to help you with that. I'll give you stack traces. I might guide you along the way to fix that. If their code smells, I'll let you know. And then after that, we do a code review prep. Internally, as our team, once we decide that we want to bring you in, we actually have a code review with the entire team where we all look at your code and we comment on it, look at your design, comment on your quality, documentation, and come up with questions to ask you in person. Then you come in in person. And we want to make sure that we have a good team. We want the candidate to walk us through their code and give us an overview of what they were thinking. We want to ask them questions and allow them to ask us questions. You really are a gauging team fit at this point. Both sides. Then we score them. We look at whether they met the requirements and if they asked clarifying questions. Did they handle errors? What patterns do they use? Was it a pain in the butt to work with them? Did they actually use Git and work on packaging, documentation? Did they wow us? I'll get into wow in a moment. We've been using the same question for a year and a half. You might think that that'll lead to a lot of the same answers but we get variety. We've never seen a duplicated answer. We've seen things in the case of 10 lines of bash and pearl or NLP thrown in for good measure. Sometimes a fault-tolerant, scalable, distributed system, they got an offer. And we've gotten all of that and a gooey on top. We've seen variety. It's possible. In review, interviewing sucks, especially technical ones, but this can apply to many industries. We solve it with a take-home project, iteration with the candidate, code reviews, and then one-on-one discussions with the person. I'd like to take the last slide to thank everyone on my team, especially my manager Greg Radic who has had blog posts on this and has been thinking about this for many years at different companies. All of my team. Yes, we're hiring also. Thank you. We learned how to make interviews better but before we get to the interview we need to know how to do stuff they might ask us in an interview. If only we had someone talking about that. Wait, we do. It's Emily. She's next. She's going to be talking about the CS they don't teach you in school, which we read as the BS they don't teach you in school, which we weren't sure how that was going to last five minutes. Anyway, let's welcome Emily up. Okay. It is on. Excellent. A good start. So, hi there. I'm Edunham and this is a crash course on some skills that you can use to turn technical expertise into personal and professional success. First off, it may seem counter-intuitive, but one of the most important skills for working with computers is actually working with people. All code is communication between someone and someone else. If you're being consumed by a program, that program was in turn written by a person. So, learning to communicate is just essential. You don't have to take my word for it. I asked a bunch of fantastic humans on the internet what they wish they'd known earlier in their careers, and you'll see some of their answers throughout this talk. So, in my opinion, one of the more important communication skills is to be able to identify what the other person needs and figure out where that overlaps with what you need. Maybe you have to just go ask them nicely. Maybe you can use empathy to figure it out. Do what it takes to determine their needs because that's the basis of successful negotiation. Negotiation is just that process where you work with somebody to figure out how you can come up with some solution that's good for both of you. That solution might be a job description or a salary given just a project deadline but never be afraid to negotiate. And also, this is your daily reminder it is okay to ask for help. Your time is valuable and you shouldn't waste it. Reinventing a solution that could be easily gained by asking someone or doing a quick search. Remember that there's practically infinite facts out there that you could know so there is no shame in missing one or two of them. Just once you realize that you need a particular piece of knowledge go get it and you'll be fine. So you also need to stand up for yourself in the tech community. There's a lot of people out there who can help you but ultimately your well-being is your own responsibility. If you're burnt out from overworking yourself or if you're exhausted and depressed from tolerating a toxic environment you're not going to be much good at accomplishing your own goals or your companies. And it's not your bosses or your company's job to take care of you. They're out to meet their own goals which are probably team success or profit or whatever that might be. And all of this plays by the rules of physics and sociology and economics and none of it is easy. Those rules don't let everybody win all the time. So get used to things that don't always work. So while school work is often about getting the same result as the answer key had innovation is about trying new things. Trying all kinds of different solutions until you find the one that you're looking for. And when you try to implement a bunch of solutions that seemed promising you will find out that most of them aren't actually all that great. So that's okay. Your job and your way of dealing with that should be to get better at searching through them quickly and efficiently to find what you are looking for. And to succeed at that you need good tools. Find the text editor that works for you and customize it to meet your needs. Get in the habit of using version control. If you don't yet I'd recommend get. Get comfortable learning new programming languages and try to use the best one for each job. Another part of using good tools is to kick the habit of insulting the tools that others choose. If someone's using something, if someone's using the tool that you like to hate on that means that tool won the competition for their time and attention. If you'd rather they used something else ask them why their tool won and learn from and listen to that answer. Now another essential skill is delegation. If you don't want to do the same year of work 20 times in a row you've got to stop doing a task once it becomes easy for you. But somebody else or some other computer has got to do that task. And when you're working at the very edge of your abilities when you're trying things that nobody has necessarily solved before you can't always just ask for help. It might be something where nobody knows. So try to combine knowledge from other fields. Say how would they do this in that art or that sport or that game. And I would say that a discipline that's especially important to mix with computer science is psychology. Because psychology is as close as we have to a manual for your own brain. So learn about the cognitive biases that you're working with. Learn about how to customize your environment to make you the most successful. As you go out and approach these problems that nobody might have solved in quite the same way before. So as you get these solutions perhaps the most important thing to do with them is share them. Teach them, tweet them, blog about them, come speak about them because if the rest of the industry can learn from your successes and failures we will all be in a better place. So thank you very much to everybody on Twitter who answered my question earlier and thanks to the mentors who've helped my career get to where it is today. All y'all are killing it tonight. This is fantastic. Oh, I haven't gone yet. Welcome to the stage my good friend Thomas Cameron. Thomas is going to talk about why it's important to be upstream and all the benefits of that. So as soon as the slides come up we will start the timer. And while we're waiting I just want to thank all of you for spending your evening with us. We've got five more minutes to go. And then game night with you and beer. I get it. Here we go. Okay, so my name is Thomas Cameron. I work at Red Hat and I've been with Red Hat for about, coming up on 12 years now. My contact information is up there. I'd love it if you followed me on Twitter. I absolutely love being able to interact with the folks that I meet at scale. So I'm tickled to death to have that up there and I do hope that you will reach out. I want to talk about Red Hat and open source communities and why we take an open source first attitude. So I want to talk a little bit about who Red Hat is because I'm sure that you guys probably are like most folks and you think of Red Hat and you think of Red Hat Enterprise Lennox or maybe Fedora, right? I want to talk about how we have acquired some technologies and made those technologies open source and actually formed communities out of those technologies. How much we contribute to those and the reason behind it. Why Red Hat is so driven to have an open source first attitude. So some of the reasoning. Red Hat, first and foremost, is a 100% open source focused company. We do not develop or sell any technologies that are not open source. I've heard folks say, oh, you know, Red Hat's proprietary. It's not. We've been an open source company since 1993. We have over 80 offices in about 40 countries around the world and we have over 10,000 open source developers, documentation folks, support folks, and then the supporting staff who, you know, do the business operations and sales and things like that. Now Red Hat has bought a ton of proprietary enclosed source and open source organizations, Cygnus Solutions for software porting, Sustina for HA clustering which I presented on earlier, Jboss, the application server company and middleware company, Kumranet, the company behind KVM, if anyone's done any virtualization with OpenStack, you probably used Red Hat stuff in there and Makara for platform as a service and now today container management. These are all companies that Red Hat acquired turned around and made open source projects out of. Fuse source, messaging and integration in 2012. Anyone use Ceph in their cloud computing environment. Ceph is an ink tank product and Red Hat bought ink tank. Feed Henry for mobile computing. Ansible in 2015. Ansible is now a Red Hat company and a three scale in 2016. These are all commercial entities that Red Hat saw value in and saw that it made a lot of sense for us to support these organizations to give them financial support and employment and turn around and either make that technology open source or continue to allow it to be open source. We've spent two billion dollars in software acquisitions and turned around and said okay, let's give that to the world. Let's make communities around that and make sure that these technologies stay available and this eye chart up here is actually one of the things that makes me incredibly proud to be at Red Hat. You've got the Fedora project. You've got Overt, RDO, Atomic, Gluster, Manage IQ, Feed Henry. All of these are communities to which Red Hat contributes code. We do everything in the upstream. You can see every commercial product that we are doing in development and not in a beta way by looking at these upstream communities. So we commit code to all of these projects. Linux, Kernel, G-Lib C and GCC, the OpenStack project through RDO, KVM, JBoss.org, GNOME.org, X.org, etc. A lot of things outside of just Linux, which you probably think about. Because we see the value in making these vibrant strong communities and we see, we absolutely know about the value of participation. So I'm not up here to thump my chest and say, oh, Red Hat's awesome because we do all this kind of good stuff. I'm here to say that we recognize that we have that responsibility to the greater Open Source communities, not just the Linux community, to be good stewards of the code and also to contribute the best code that we can. Because the reality is we wouldn't be where we are without you, without the various communities that Red Hat is a part of. So, you know, we understand that we owe a debt of gratitude to these communities. We are beholden to these communities and we have, in our DNA, the push to make sure that we are always pushing code out into the community. We are always making sure that we are being good members of these various communities that we sponsor and we're grateful that you let us be part of your community. So, we do a lot of things outside of just core Linux. We're grateful to be here and we are very grateful that you guys are members of the community as well. Thank you. Alright, thanks everyone for coming and listening to all of our up-stale talks. How about a final round of applause for all of our speakers? And thank you so much to Jason and his team at OpenSource.com for partnering with us at this event this year and hopefully it was a good succession and so thanks so much to your team and working with you guys has been a pleasure. No problem. Yeah, if you would like to be on the upscale stage next year be on the lookout for the call for papers when we call for speakers, papers whatever we call it for the upscale presentations and we're happy to look at your submissions and hopefully again we gave you a diverse group of topics, diverse group of people and something to think about. And we'll see you at game night coming up next. Game nights rider on the corner. Have a great night everyone.