First of all, I'd like to thank Lita and the organizers for inviting me here to talk to you. And we're going to talk about the microbiome and infectious and non-infectious colitis in 20 minutes and cover both fields. So hang on. But what I'm going to do is I want to summarize the field, and I'm going to summarize the field using some examples from the literature that I've chosen. And not because they are the only examples, and I know looking around the room I'm going to be talking about some people's work from people who are in the room, and I will apologize ahead of time. If I misquote your work, you can come up to me during lunch and set me straight. But to me, these are examples that helped me raise some of the gaps and challenges, because that's what we want to address. We understand this idea that we have this balance with our microbes, and when this balance is lost, something can go wrong. And in the gut, the manifestation of something going wrong is often the development of inflammation. If you look at a medical textbook, if you think about colitis or enteritis, they'll divide it into infectious and non-infectious. You go through infectious, they'll come down a whole long laundry list of the various organisms that might cause an infectious colitis. And then there are these non-infectious, which inflammatory bowel disease is one that we've already heard about, and I will talk about a little bit here. But let me start at the end. Let me bring up some of the gaps, needs, and challenges that we'll talk about. And this is kind of a wordy slide. I've bolded some things. You will see this slide several times during the talk. And we've already heard about some of these gaps, needs, and challenges. We have to move away from these surveys. Surveys are great in the beginning, because we get signals. We get an idea that there's biology there. But we have to move from those associations and those signals of potential something going on to actually finding out what the functional consequences are of any changes in the microbial community. Because if we're thinking about functional consequences, that's moving us closer to mechanism away from hypothesis generating and actually having testable hypotheses. We've already heard from Gary and others that we need to actually have model microbial communities. We can't always work in the human. Or if we work in the human, we'd like to be able to back it up with work in a model system where perhaps we can do more hypothesis testing, go back, observe in the humans and move back and forth in that translational scheme. We've already heard about the ability to handle and analyze large multi-omic data sets as an important need and a gap and a challenge for us to be able to do that. And then finally, at least as a physician, which I am, the idea is that somewhere in the back of my mind, the reason that my mom wasn't able to come visit me in my office where my nurse was able to set her in a chair, and instead I'm in the lab is that I want to get someday two novel therapeutics that will be broadly distributed. And how do we get there? And we've heard about using microbes as therapies. In some cases, there's something that we need to think about. One of the challenges is we actually have to get this microbe. We have to be able to propagate it. And even though we have a lot of great molecular techniques, the first way we studied a lot of microbes, i.e. cultivation is actually important if we're going to try to get certain types of therapies. So let's start talking about IBD. And we've heard enough about IBD, this formerly idiopathic condition that's basically characterized by uncontrolled gut inflammation. And there's been a lot of evidence that there's a role for the intestinal microbiota in the pathogenesis of IBD. And we've already heard this. There's been a lot of association between so-called dysbiosis. You take a patient with IBD. You take a matched control. You do some sort of analysis of microbiome. It could be 16S clone libraries, DGGE, pyrocytesine, pyrocytesine metagenomics, metaproteomics. They're different somehow. And I'm going to talk about two studies. And these are somewhat older studies. And when I think about my grad students and postdocs, I guess these are older studies because they were in elementary school, middle school, and high school for some of them when these came out. I remember these like, oh yeah, they just came out. But you talk to your students and they go, oh wow, those are your old papers. So we'll do Dan Frank's paper first. And he was doing a study with clone libraries. And he was kind of looking at patients with inflammatory bowel disease versus controls. And they sort of fell into two different groups. Now, interestingly enough, the controls with no colitis kind of all grouped into one group. But mixed in with that group were also patients with colitis. However, the other group that sort of came out were patients that were basically with the exception of this one individual was only patients who had colitis. And when they did looking to see who was there, characterizing it clearly, the ones in this IBD subset over here, the communities were quite different than those in the control subset. And I could probably spend the next 50 minutes. I won't. I could spend the next 50 minutes going over many, many different studies like this that show patients with IBD. Many of them are different from controls. Now, there are other ways to look at the communities. We actually haven't talked about actually, again, sort of an older thing. Tyler Jackson used to say, it's amazing what you can do in science when you look. And those are the people who go to the microscopes. And here is comparing now patients with inflammatory bowel disease versus those without colitis or those with an intermediate phenotype of colitis. And they're staining the bacteria to actually look spatially. When we actually get a biopsy, when we get a fecal specimen and we mash it up in our bead beater and we get the DNA out, we destroy any sort of spatial heterogeneity and all the information of where the bugs actually are. And so in this study from Alexander Swenzinski and his colleagues, in no colitis, you can actually get this idea that there is diversity. They stain for ones that will stain the B. fragilist group, the u-bacterium rectally group, or if you didn't stain with either of those, you'll stain with sort of a broad range bacterial probe. And you have quite a mix in no colitis. And interestingly enough, you have this sort of void zone where the mucus layer is. Contrast that with patients with Crohn's disease, active colitis. First of all, you sort of shift the community again. Once again, there's sort of a dysbiosis. The most predominant probe is this B. fragilist probe. And these organisms are forming what they termed as a biofilm, right on the surface of the epithelium. And in sort of the intermediate case, a self-limited colitis, there is some of loss of bacteria encroachment into this mucosal area. But perhaps you could have some suggestions that the community more resembles the control community. So we have these great associative studies. So now one of the first needs, one of the major needs is how, and a challenge is how do we move from these associations between disease states and something about the microbiota, say, if be it community structure or whatever, to some sort of functional consequence of these changes. Couple of recent papers came out. I'm just picking one. There's many. Here's one where the title sort of says it all. They want to connect dysbiosis, bile acid, dysmetabolism. There's a function. Gut inflammation, there's a host response in inflammatory bowel diseases, okay? So in order to go over this paper, we have to go over one of my favorite topics a little bit and that's biometabolism. So most people realize that bile is important in the digestion of lipids. And these are produced by the liver and when they're produced by humans, they're usually conjugated to glycine or torene and then excreted into the bile duct, sometimes hanging out in the gallbladder and eventually making it into the gut where they can basically solubilize, act as detergents, solubilize lipids and allowing them to be absorbed. But that's not the end of the story. So these are the so-called primary bile acids, the ones that are produced by humans. The microbiota has a lot of activity, including bile salt, hydrolyse activity and 7D hydroxylase activity that changes these primary bile acids into so-called secondary bile acids. They remove the conjugations, they remove hydroxyl groups so they create a whole different set of so-called secondary bile acids. Now, both the host and the microbiota also can do things like add or remove sulfate groups, actually the host does sulfation in some ways to quote unquote detoxify and also allow them to move out of the gut and not cause any damage.  So the host has ways to try to detoxify them after they've been used for lipid metabolism. So if that's normal bile acid metabolism and in this paper was published in Gut and Gut, they have a nice box that basically you don't read anything, my students just read the gray box. What are the new findings? It's even shorter than the abstract because they bulletize it. They found that there's this metabolism of bile acids. So they took the patients with IBD and now they're looking for a functional difference. Well, gee, the bile acids are different and we'll go over what those are a little bit. And somehow this is associated, well not somehow, this is associated with changes in the microbial communities, all right? And one of these changes that they find in the bile acids besides changing the ratio of primary and secondary, they also saw increases in sulfated bile acids and they begin to speculate that this may actually change with this inflammatory loop that we see over and over in IBD. And so what do they find? Well, they found that because you have less enzymatic activity, so you're not having as much deconjugation, you're not having seven dehydroxylation, you actually have an increase in the primary bile acids and a corresponding decrease in the secondary. And they also observed this changed in the sulfated bile acids. There was an increase in the sulfate bile acids. And they brought up the fact that this actually may contribute to the inflammatory loop. They didn't talk so much about the sulfated, but there's a lot known about how secondary bile acids can actually change gut inflammatory state. And this is through signaling through a G-coupled protein receptor known as TGR5. Interestingly enough, at the same time this paper came out, there was another paper came out that caught my eye and basically they were looking at TGR5 signaling in patients with Crohn's disease. So what's interesting about this TGR5 G-coupled protein bile acid receptor is that normally when it's engaged, it actually decreases the inflammatory response. If you take macrophages that express TGR5, you treat them with an agonist, either the primary bile acids themselves or sorry, the secondary bile acids themselves or an agonist, you'll actually have decreases in TNF-alpha expression. They also took, in this particular case, after doing a bunch of in vitro studies, they took laminopropyl mononuclear cells from patients with inflammatory bowel disease. And what did they find? They actually saw that there were increases in TGR5 expression. And they saw that actually that they saw increases in TNF-alpha expression when they treated them with an agonist. Now I'm saying it wrong. I hope these authors and I actually said it backwards that the TGR5 agonist will actually increase the expression of TNF-alpha. But basically, to cut a long story short, they're showing how a change in the microbiota can cause a change in the function of that microbiota. That is changing bile acid metabolism and switching that bile acid metabolism such that it interacts with the host through a known receptor and actually increase inflammatory tones. So people are trying to do those kinds of links. Again, this is not so much the take-home message of exactly what they found, but the idea that you can link changes in the structure and function of the microbial community, have it influence the host, have it influence the entire system, which in this particular case is the gut. Gene Chang said, I'm gonna tell you more about our particular study and he lied. You will go see Marius's poster and he will tell you, so I'm passing the buck even further. He'll tell you more about our pouchitis study, but I wanna pause on this for just a second to address one more challenge. And this is sort of related to Gary's discussion and even though we're both at the University of Michigan, we weren't kind of in cahoots in bringing this up. But our particular study involved people from five different institutions. And if you look at these institutions, we have a marine biology lab, two different medical centers, a land grant university and a national lab, people with expertise in soil microbiology, ocean microbiology, infectious disease, gastroenterology, computation, technology. In the current way that we have to put together grants and get them reviewed, how do you keep and form such interdisciplinary teams to address these types of problems? These kinds of teams that we think are essential for addressing these interdisciplinary and I don't have an answer for that, but that's something to think about as a challenge. So let's in the last kind of third of the talk, let's jump a little bit to my favorite topic now, which is infectious colitis. And Ralph Frater has already been brought up in terms of the Frater and nutrient niche hypothesis. And Ralph Frater, when he was a postdoc, was already speculating in the 50s that the normal microbiota might be a factor in influencing human resistance to enteric disease. And he's talking in infectious diseases. And so let me give you an example that I always give on how this can come up. So you can have people who have a lung disease, they're one of Gary's subjects, they have chronic obstructive pulmonary disease, they have an exacerbation of their COPD, get treated with broad-spectrum antibiotics, do well from the pulmonary standpoint, but then develop severe abdominal pain, diarrhea, and hypertension. And what have they developed? They've developed an infection. They've been infected with clostridium difficile. But what does this have to do with the microbiota? That's coax postulates, you have the pathogen, it's clostridium difficile. Well, normally, with a normal microbiota, clostridium difficile, if you get exposed to it, it doesn't cause any disease. You have to alter the microbiota, for example, by giving antibiotics. Somehow you lose colonization resistance against clostridium difficile, which you generally encounter in the form of spores. These spores then germinate, bile acids are actually a good germinate, getting to my favorite topic again. The vegetative cells begin to grow, they can begin to compete against this altered microbiota. They'll produce the toxin, that's what causes disease. So we know that this happens in people. 25 years ago, when I was a med student, he says, yeah, there's something about the flora, the flora's all messed up by the antibiotics, that's what comes in. But we couldn't study it, because at that time, we didn't really have great model microbial communities with which to study these processes. And we also didn't have the technology to look at the microbiota. I was told when I was a med student, I was an MD-PhD student, don't try to study it, that's impossible to study these complex microbial communities. So just kind of go ahead and study your favorite pathogen, put it in cell culture, watch how it interacts with an individual cell, and you'll get your PhD. Well, now we do have model microbial communities in microbial systems. And remember that for 90 plus percent of the HMP, remember H stands for human. And so the four genome centers, the major studies were all on humans, and there wasn't much work that was done on model systems. And so actually, when I started working on CDIF, I thought I wanted to work in humans, but I also wanted a model system. And generally our favorite model systems are rodents. Koch's postulates were fulfilled with hamsters, but mice for a lot of reasons are good to work with. Initially it was found that only germ-free mice could be made ill with CDIF-facil. If you gave them antibiotics, clindamycin was the classic, they wouldn't get any disease. Karen Kelly in his group published one of the more recent mouse models. We've also modified the mouse models to the point that we can use a single antibiotic, give it to mice, and then challenge them with clostridium difficile, both spores and vegetative cells. And we will get disease. And the disease is relatively rapid. We can judge this by looking at the weights of the mice. Basically after treating them with antibiotics and then infecting them with CDIF-facil, animals that are gonna get sick within two to four days will drop 80% of their body weight, they'll become morbid and they'll stop eating and they'll have to be sacrificed. And instead of having a normal looking gut like this, they'll have a lot of edema, they'll have a lot of epithelial destruction. If you look closer, you see the characteristic pseudomembrane that you see in people. This is fibrin, this is blood, this is an inflammatory exudate that you see there. And so this model's pretty good at capitulating a lot about the human disease. So we now need to be able to look at the microbiota. We've published a few papers on that. But if you have a model, can you use that model for therapeutics? And as I said, when you have therapeutics, you have to go after particular members of the microbiota, and then understand how to grow these out, how to propagate them, and then how to administer them to patients. I said we did a number of surveys in this particular mouse model, and I'll summarize it by saying one of our results that we got early on that one group of organisms, the lactosporaceae, members of the Fermiqutes, you heard about some of these, were associated with protection or minimum disease in this model. You can adjust the model, so some animals get less severe disease, and also you can find certain antibiotics that can change the community without having disease. And basically, the simple-minded conclusion is lactosporaceae, good. You can also get a lot of E. coli. We've heard about the blooms of E. coli already. Gary just talked about them. And if you have a lot of E. coli in your mouse and you have a lot of E. coli in your gut, that's associated with susceptibility disease and development of severe disease. So it's great, we can do these 16S surveys. But how do you move from a 68S survey to actually a cultivated organism? Tom Schmidt, my friend and collaborator, now joining us at the University of Michigan, along with John Bresnick at MSU, published ways that you can actually use molecular probes to guide complex cultivation efforts. And I'll point you to this particular paper that's almost 10 years old now. So again, back when my grad students were on swings. But they can use 16S probes as ways to guide the cultivation efforts and say, okay, I'm going the right way. I'm varying the culture conditions such that I'm beginning to get what I want. So we did basically that. We designed probes so that we can look at lagnosporaceae and, well, E. coli was relatively easy to grow in selective media. And we got a handful of these from the mice and several E. coli's from our mice, mono-associated germ-free mice and tested on a one-on-one against C. difficile what happens? Well, what happened? If you take a germ-free mouse, and as I said, if you take a germ-free mouse, give it C. difficile, drop its weight and die within two days. Now, if you pre-colonize them with E. coli, and this E. coli which is about 10 to the 10th per gram in the gut, it doesn't protect them at all. In fact, they die even faster probably because they get endotoxymic once the seed of starts growing and damaging the gut. But this one particular strain that we had tried, this lagnosporaceae strain, some of the animals lost weight, but on the whole at the end of two days, and we've extended it much further than that, they'll survive. And when we looked at what was going on, this one organism, this lagnosporaceae strain, could decrease the levels to which C. diff would grow in the gut and it produces toxin, the toxin levels go down. If by stochastic reasons, you know, you were one of the unlucky mice that still had relatively high, but somewhat lower colonization levels in toxins, you'd actually die. And those were the three mice out of the 14 in this experiment that died. So we're gonna hear about fecal transplantation. We are gonna hear about some of these defined communities that can be used both in mice and people to try to treat it, and I won't try to steal anybody's thunder, but we are getting to the point that we can use cultivation to guide therapies, okay? I'm gonna point you to one more poster. This has already went yesterday, but she'll be back at the poster on Friday. You don't always have to even have a host. Rob Britton and his group has been using bioreactors to look at complex communities outside of the host, and they're doing great work at looking to see how antibiotics can change this and how these communities can interact with C. diff. We've already heard about multi-omic data sets and the challenges there. We've already heard from Janet about her work, and my final job is to send you to yet one more poster from my postdoc, Casey Terria, who will be presenting right after lunch today. We're basically, we're looking to see making that leap. All right, we have these organisms. What do they actually do? What do they do to the metabolism in terms of carbohydrates and bile acids? So I just want us to think about these gaps, needs, and challenges. Yes, this is specific to infectious and non-infectious colitis, but I think a lot of the things that are coming up in terms of model systems, getting away from association to function, multi-omics data sets, all of that. I think that applies to all of our work when we're looking at complex communities. Finally, I'd like to acknowledge that, this is fun to stand up here, but I'm up here speaking for a lot of people. There were six of us last night who were all the PIs of that multi-disciplinary group that I told you about. We all managed to gather in Bethesda, and we were trying to figure out how do we keep something like this going? The places that we all gotten funded before were quite diverse. We've taught each other so much about each other's science, and I think back, this is now four years down the road from the HMP when we first gathered to try to put together our project. We communicate so much better with each other. Our people who work with us understand so much more about fields that they never thought they would understand about, and I hope we can try to keep what we've started with the HMP moving forward. And of course I'd like to thank the NIH who has found it interesting, not just within NIH, NHGRI, can never keep the alphabet soup together, but many of the other institutes and centers that have been interested in microbiome research. And thanks for your attention, and you guys can get to lunch even a tiny bit early. Thank you. A couple of questions? It's okay? There was very little data for my group, so there were no questions, I'm sure. Okay. Okay, so now we're moving on to lunch and the poster session, and we come back here at 1.45, so we'll see you then.


Thank you guys for dealing with the delay of game. Thank you very, very much here. They've given me a clicker and a microphone. You guys are in lots of trouble. This talk's called Fearless DevOps, Committing to Code here, or we've all done it. We've all done it. Raise your hands if you haven't done it.   So I've worked at a few places, associated content, Yahoo, Pearson, Ping Identity. Currently, I work at GitHub. I'm a senior database infrastructure engineer there. Deal mainly with Elasticsearch, MySQL. A few more things about me. If you're wondering why I look like a Super Butch 35-year-old, I have a really rare disorder called XXXY chimerism. I'm totally aware of this. I'm also a functional chocoholic chatbot therapist, and I have a love for high-commitment activities. That's actually me on the top there, completely botching that exit. Skydiving's a high-commitment activity when we talk about committing to code, right?  Gravity is a constant as far as I've found. I have tested this hundreds of times. Gravity is definitely a constant. So when we talk about committing to code, what are we talking about, right? DevOps, there's a mantra. What's the mantra, right? Automate everything, everything as code. Everything is code. And that's a commitment we strive for. And it's this great idea. It's this really great theory.  It has real problems in implementation. Of course it has problems in implementation, right? Eating ice cream on the weekends is comfortable, really comfortable. Exercising and dumping carbs is super scary and annoying. Running things the way they are now is comfortable. Trusting your system to a bunch of code you communicate to through an erratic chatbot that takes things way, way too literally is scary. When we're trying to make everything code, there's a lot of rules to follow and there are many ways to break them. Don't get fired. That's a rule, right? Does that go through anyone's mind when they're doing a new project? Yeah? Don't get sued if you own your own business. If I lose all this data, I may have to talk to a lot of lawyers and not all of them will be mine. Don't get a bad rep as the person that doesn't complete their project or makes the wrong calls.  And the list goes on. There's a lot of pressure in our professional lives and people think that I have it easy sometimes in my personal life and my recreational life but there's really only like one rule. And it's easy. I mean, it's kind of past fail, right? So bad things can happen in our professional life. Bad things happen to this guy. Don't worry, he's still alive. He has both shoes on. That's how we know. No, seriously, if you lose a shoe, you're totally screwed. So the weight of all these things in these pending disasters lead to fear of commitment, fear of commitment to our project, fear of commitment to our code. And we've all been there with that fear of commitment. These zombie projects that you start that you had the best of intentions and things went horribly awry. So when we think of implementing something new, our breathing quickens a little, our jaw sets, do we really wanna get involved in this thing again? And this becomes our default answer, right? No, I'm good. Got burned on the last one, right? Fear of new, fear of committing to a code-based infrastructure. This holds us back. We have our runbooks, we have our procedures. Some of it's automated, but not all. The stuff that's automated, maybe it's tested. Some of it, maybe there's enough tests so we can believe that it's tested, but we know in our heart of hearts, it's just not. And some of us has found this out, or maybe all of us. Sometimes that's worse than not even trying in the first place, right? And you're right, I'm not helping here. Now you're all afraid. This is actually the end of the speech. Go forth and do nothing. Live in fear. So how do we commit to our code? How do we control this fear of the unknown that stops us from fully committing to this code-based infrastructure that we're all dreaming of? So we're gonna break it down here, step by step, how to get to this DevOps promise land. However, first let's address this key foundational problem, us people. People are horrible. You will hear this in every one of my speeches. I'm horrible, you're horrible.  We get stressed out and we make bad decisions.  I have to do something right now. When the answer is, you should probably do nothing.  There's feature creep, there's foundational stuff. There's this political battle. There's this person that always says that everything I do is wrong even though I don't know, maybe it is wrong. People are afraid. We get really afraid starting these kind of projects. But the problem is, everything we want is on the other side of that fear. It's on the other side of that chasm. We just gotta step off, right? And this isn't only true in DevOps, it's true in life. Who here is afraid of something in their professional life? Hands, hands, more hands. I sense lying. All right, no, no, keep those hands up. Hands up, hands up, hold your hands. There you go, show and tell. All right, no, no, you put your hand to get up. I saw that, take a glass, take a glass. All right, drink fear, what's your fear? Microphones? Yeah, human interactions, awful. Human interaction, I think that's a pretty common one in this crowd, right? Human interaction?  Very bad at following directions. More hands, more hands, more hands.  There you go, I'm gonna come find you.  Van Gogh, Star Trek Van Gogh. Failure. Failure, failure is a really common one. Oh my gosh, what if I screw this up? Everyone will hate me. What if this project that's going to cost $3 million that I'm leading a group of people and I've hired four people goes down in flames? This will look bad. What if I fall into my friends at 120 miles per hour at 12,000 feet and hurt them? Actually, I do that all the time and they don't care. So, right, so everyone's afraid. I mean, I have a confession. I'm horribly afraid of heights. I cannot get on a two-story ladder to paint my house and I know this is very much like rain on your wedding day, ironic, but I truly am. So, how do I deal with my fear of heights? How do I deal with being afraid of this new project, of this new endeavor, of this new job? How do we get past our fear of rolling out this infrastructure when we think, I mean, we overthink it, right? This could define my career or at the very least, my current job. I mean, first day on my job, this job, I'm gonna deploy this chatbot script to list the size of the databases.  I'm so gonna be judged on this and they're gonna ask themselves, why are they actually paying me money? Maybe I should subscribe to LinkedIn, JobSeekerPro again, because I'm gonna need that, right? So, there's a little bit of a secret to getting past this fear. And the secret is one that like adrenaline junkies and professionals in life-threatening situations use before stepping into the void. It works really well when jumping out of airplanes. Works good when jumping off of antennas.  It works in more extreme situations as well, like potentially start-up killing database migrations. We can't possibly restore this backup in less than 10 hours. I wish I'd made that safehold box.  So there's three steps to controlling fear. Relax. When we get fearful, we get stressed. And I know that's like the worst thing that someone can say. It's like when you say chill out to somebody, it's 100% guaranteed someone will not chill out. And when you say relax to somebody, just relax. They will get more tense. Never works. But when we get fearful, we get stressed. When we get stressed, our heart rate goes up. Our neurochemistry changes. We make really, really bad decisions. I have personally seen people make stress-induced decisions that have been life-ending in front of me, because they did not control their fear and they panicked. We can't control our heart rate. We can't control our neurochemistry unless someone is a Buddhist monk that wants to give me enlightenment here. We can only really control one thing when we're stressed, our breathing. And it's super cliche, but it works. Hit the pause button, breathe. Changes our neurochemistry, we calm down. Controls our heart rate. Our heart rate and our breathing are linked. Especially if we're not undergoing strenuous exercise. And it gives us two things, time and space. Time and space is everything. It's everything in sports, it's everything in extreme sports, it's everything in devops, it's everything in life. The more time and space you have, the better decision you can make. And you always have time to breathe. You always have time to breathe. Does anyone think they don't have time to take a break? They've been on that, come on, yeah? Okay, you always have time to take a break. I can guarantee you that you have time to take a break. Every weekend I have about 25 seconds left to live and I go, and I save my own life. Before I make a large crater in the earth and my fiance becomes very, very rich.  So I'm certain you can take a breath when you're really stressed in the meeting, when you're coding, when you're project planning. Make some time and space for yourself. It's your time and space. Play a game, take a walk. Do whatever you need to do. Take it when you need it. The second thing is focus. Pay attention to what's actually happening right now. Not what you want to happen or what could happen or what could go wrong. When people focus, they're usually focusing on what they want to happen or what can go wrong. Not what's actually happening now and what the immediate action is to take. Pay attention to the reality of the situation and deal with it. Seriously, when you're focused, don't overthink it. Overthinking the problem creates worry and fear. And worrying is praying for bad stuff to happen in the future. It is even worse than not doing anything. It is actually like the black hole of productivity. Nothing happens when you worry. The third step is to flow. Be in the moment. Now that we have a workflow and had to handle fear and perform, these guys are performing. Arizona Airspeed, best four-way team in the world. They're not thinking about anything else. Mikhail's a good guy there, but they're flowing. And we need to flow. We need to think about exactly what we're doing and eliminate all the distractions. So we've got this workflow on how to handle fear and perform. So this doesn't sound like a self-help seminar and it has something to do with DevOps because I think that's why we're here. Let's go into what steps we need to take to actually committing to our code. It's also becoming really apparent that two cups of coffee was a little overkill up here. So don't overthink it, right? We need a few basic ingredients to commit to our code. We need a way to store the code. That'd be nice. A place to store the code. A method to know that the code works. A method to deploy our code. Code to actually deploy that does something. You notice how far this was down the list? Everyone starts with the code and then moves on.  And a method to coerce people into actually using the code we've written, which sounds terrible, but we'll get to that later. And most of all, we need not to overthink it. So first, we need a method to store the code, right? Alexa, show me a version control system. No, wrong, also wrong.  There we go. Yeah. Place to store the code. Maybe if you Google around, you can find a place to store code and work collaboratively.  There's lots of places to store your code. They're all good. All ASs that you use get, please, please, please don't use CVS. If you're using CVS, there's an intervention at the bar afterwards. We will help you. It's 2017. Now that we have a place to store our code that everyone can access, now that we have this playground to experiment, we can commit, merge, we can work with people. That's awesome, right? Next, we need to check in our code. We need to check our code, actually. Continuous integration. And we don't want a bike shed, right? Jump into chat ops. You should be using chat ops. It is also 2017, please. Ask everyone what CI systems they know. Whichever one pops up the most often, use it. Don't debate this for three weeks. It's not rocket science. It's probably Jenkins or Travis. So the goal is to get here, automatic merge, empower anyone to create a merge, a PR, get our review, and ship it. Frictionless, easy. So we've got that, right? We've got code, we've got a place to store the code. We've got a way to check the code. Now we just need a method to deploy the code, right? People are thinking like, sweet, I got this. Wrong. This is not the way. We need to talk to more than one server at a time. We also need to do something super important, right? We need to leave a record of what we did so that our team knows what's going on. Eliminate tribal knowledge and embrace scroll back. Use Slack, use Hip Chat, use IRC, I don't really care. Scroll back should be definitive for what has happened in your environment. I have documentation that's written in markdown, but 90% of the time I search in Slack to see what someone else did, and I look at their workflow. If you're thinking it, it should be in chat so people can go back and see what your thought process is, which is kind of scary, especially at 2 a.m. in the morning. But scroll back should be definitive for what has happened in your environment. So set up a chat bot. I'm really partial to HuBot, but there's others out there. You can roll your own if you want. Don't overthink it, just do it. Something is always better than nothing. If you don't have Hip Chat, Slack, et cetera, again the intervention is at the bar. We will help you, we will help you. Now we just need to ship it. Empower people to ship code so that you can ship your code right after CI runs, and maybe get a review depending on how important it is. Once CI completes, if it takes anything more than this in chat ops to deploy your code, I'm really sorry, but I have to say this. Your system is broken and your process is broken. That's all it should take if it doesn't happen automatically. If you can't trust your CI, it's broken. If you can't roll back quickly, it's broken. If you can't trust your engineers to deploy to production, we have a more foundational problem. It's a different talk or a consult. Now that we can ship something, we need to ship something, right? And here's where things go horribly wrong every last time, every time. Oh, I'm going to find you. Oh, I see you, I see you right now. The person nervously smiling. You're wearing blue Colorado shirt. I got you. Pick a language. Russian. No, no, pick a program language. Python. Python, okay. Anyone agree with that for the coding project we're going to do? No? No, anyone disagree with that? Everyone loves Python here. Ruby, okay, there we go.  Actually, what framework are we going to write the project in? That's not a framework. You can make a repo though and make it a framework. What framework are we going to use? Let's do Rails. Rails. Anyone disagree with this? Anyone hate Rails? 500 people and there are no Rails haters. Liars. There are at least 10 of you out there. Okay, there we go. There we go. Brave man there. Brave, brave man, right? So let me tell you a secret, like, this is a huge debate. You start a big project, you're going to like turn this monolith into microservices. You debate over three months, what language it's going to take, what framework are you going to use, and it just becomes this huge nightmare. So here's the secret. No one cares. Two years from now, no matter what language you use, no matter what coding framework, people are going to be huddled around a monitor. They're going to be huddled around a monitor and they're going to say stuff like this, I guarantee you. Hey, look at this project. No wonder this person doesn't work here anymore. They wrote it in Ruby. Oh my God, we need to completely rewrite this, right? Right. And if you're there, we're going to do this.  Why did we do this? We don't know. I know, I don't know either. I was drunk at the time. We made this decision. Um, we need to rewrite this and hide our shame, right? Correct. All right, I'm going to order some pad tie and let's get to this. This happens, I've done it. A lot of people here have done this. No one cares. Jump into chat ops. Hey, what language does everyone know? Oh, Ruby? The project's now in Ruby. What language does everyone know? Oh, most of you know Python? It's now in Python. Congratulations. That's how we pick it. That really is that simple. Don't let someone write it in Scala when you're the only person that knows Scala.  Because you're the only one that knows the language and no one can attribute. So that's it. Pick something then. Automate it. Something super small. Like listing your databases. This is a piece of redacted code that I've done. Thor. What language is this? Really? It's Bash. It's just Bash. But it works, right? Everyone can read it. Everyone can contribute. No one really cares. No one's griping to me and saying this is in Bash. I need to rewrite it in Spring. It took 10 minutes. Lather, rinse, repeat. Pretty soon we have hundreds of tools we can use in chat ops. Now we just need to get people to use them. How do we get people to use them? This is the bad part. Remember we talked about coercion, which is probably in the employee handbook under something you should never ever do. Coherse. Coherse them. Brow beat them. But Jess, this isn't very nice and it'll make people feel bad. And you know what, yeah?  It makes me feel bad when you SSH into a server that you don't need to. Cause I don't have any scroll back on that. I don't know what you did. And when that crucial production database disappeared and you didn't notice and you went to sleep, I have to do some archeology and I don't like to do archeology at 3 a.m. in the morning, especially after Friday night. So at GitHub we have this really robust implementation of chat ops. It also means if you shell in a machine, everyone gets an awesome Slack message saying, Jess Breckner, it's shelled into my SQL server. Then everyone says, hey Jess, why'd you shell into my SQL server? And I go, well, I wanted to list the databases. And they go, you know I have a tool for that. You can just go like, dot my SQL databases cluster. And I go, well, well, that would have given everyone a history and let them know what I was doing. I should have used that. And if the tool doesn't do what I want, which is a frequent excuse, it doesn't do exactly what I want. If it's in a shared collaborative infrastructure, the next statement is, well, that's great Jess. So we'll see a PR in an hour or two to reject those databases, right? Oh yes, absolutely. And then the tool gets better. One second, lost my train of thought here. So, and this is very empowering, right? If you have stuff in a repository up there in a language that everyone knows, they can contribute. They can contribute to that and they're empowered to contribute. So here's a really awesome story. Yeah, that I can share. I went to work at GitHub and you know you go to work at a new company and there's always something wrong with like HR, there's little things that don't work or some documentation that's out of date. And six months later, you're staring at this documentation getting really mad and you're like, I still don't know how to sign up for healthcare benefits because this was three portals ago and I forgot how they said to do it. And I really don't know how to get credentials in these servers either. Shove everything in a repository somewhere so people can edit it. I just went and checked out the repo, forked a branch, updated the instructions and got in. And at the end of that, I'm like, wow, I'm super empowered. I can fix all this stuff. It's like not only is dev ops version controlled, everything's version controlled. This is way awesome. So people use these tools and people get empowered once we have this whole scaffolding. Does that sound cool? Yeah, I guess not. So I think it works pretty well in my experience. So we now have a place, we now have a way to store code, right? We picked a version control system. Everyone picked CVS, yeah. Perforce, great choice, great choice. We have a place to store code. We picked one of the online services out there or we've gotten like an on-prem solution if we work for a three-letter agency or a bank. We have a method to see the code works. We've picked like Travis or Jenkins, which is really awesome. We don't have to manually go, I hope it works. That's just so 2003. We have a method to deploy the code where we're using a chat button, it just goes out. Or we have continuous deployment and it just goes out. That's another talk on whether that's good or not or right for your organization. We have code that actually does something out there. And we also have a stick to prod people to say, please use the code, please use the code. And leave it in scroll bag and leave it in chat ops. So everyone's got that, right? And before we take on this project of devopsing all of the things, we can control that fear that we have. We can relax, we can breathe. We can focus on the immediate issue that we're solving and not pray for that bad stuff to happen in the future that we like to do. Because we love to do it, I love to do it. I'm a worrier and it's so hard to stop. And we can flow. We can be there for the moment, we can be there for the task and not for anything else that we're doing. We can just eliminate all those distractions. Now let's go forth. Let's sprinkle some devops on it and just chat ops all of the things. Let's move beyond this. It doesn't mean we're not afraid. It just means we move beyond the fear. And we use that simple scaffolding method to avoid bike shedding and all the other pitfalls that we've looked at. And it's awesome. So that's all folks. How much time do I have? Yeah, as much as I want. Awesome. Yeah, I have a microphone. This is where it gets dangerous. So I'm gonna open the floor to like a general discussion for the remaining time. This prezzo is usually pretty quick so we should have 10 minutes or so. On anything? I have an opinion on everything, so ask. I am required by the legal team to let you know that GitHub disavows any of my opinions that are controversial. Yeah, come up here. I don't have a second microphone unless they have a second microphone somewhere.  But does that not get to be a lot of overhead after time, especially as you have more and more scripts and some of them end up just a little bit different or lots of flags or whatever that ends up looking like? You need to organize it decently, make a directory and make the shell script small. Don't create like this monolith service that has every chat command like list-databases.sh, list databases. You can also create separate rooms. Like we'll have a room for databases or for Puppet and then we'll have a room for database bots and all the database bot chat goes into database bots or operations or whatever. And then it's segregated there. You can also call that bot from within the main room if you need to really get people's eyes on something but otherwise it's just in the bot room, so. And then you can scroll back and see what the bots have done, especially as automated bots. Like I committed to our operations management system and it comes back and says, oh, your CI totally failed. Well, everyone can go in the bots room and go, yeah, your CI failed. Click, why? So it knows. No, no more questions, 500 people. I will find people and make you ask questions. No. All right, thank you very much. I'm Jess Breckenridge and this has been great. Thank you.


But I just wanted to show you that I've done it again, got part way through it, but oh maybe I could make a little video out of this, but to be fair it's not that great of a thing, basically it's just like a share. I got one of these things, look, and of course I built it up, it all works now and then of course I made it for a while. I've given it a power switch all the way into the side and I was quite chuffing myself, I actually managed to make a nice clean cut, because all I had was a very hacksaw to do it with. And a little bit of sandpaper, using the, wasn't actually that piece was it? No, no, it was this piece. The user had a sandpaper just to sand off the edges of both sides, straighten this edge out. You get a nice edge there. And so in the back, I know I should have put some heat shrink here, I'm heating up the soldering iron so I think I'm going to do that. And I found myself a, oh what, I think it's one amp. 12 volt, 20 VA, that's what it's like. It's about this, a little over an amp, isn't it? It's not quite two amps, but it's got enough use anyway. This thing only needs a few hundred milliwatts at 15 volt. This is 12 volts, so I was home over rectified it, times it by 1.414. I should have pretty much just the right amount, just the right amount. I'm building a little board here, a little bridge rectifier there. I just soldered it up. Just like, snip those off, find myself a nice capacitor. I don't know, 220 mic or something. 2200 mic or something. Pop that on there, smooth that out. And then I was just going to put a, I was going to put a 5 volt regulator on there and just stick a couple of resistors on. 120 R and a, I don't know, 3, 2 something to 3 something, I need to get that 15 volts. So I'll have to have a little play around with that. And then just stick another capacitor in, of course, and let me set up a little bit of 15 volts. Most of what I would, stick a hole in it. There, it's going to go something like this. That's going to sit on there. Now connecting down here, of course. And there we go. And I've tripped all those little project boxes. The same sort of box as what this is in. So it's got a handle. And yeah. So what I'll do is I will, when I've finished putting the rest on, I'm not going to have a video of myself doing that because I go off and do other things. You know, I can't, I can just sit and do, but I tend to go off and do other things and have a beer and have a bit of a laugh at the TV. Because I've always got the comedy on going off, switched off now, so I can do this. But I'll switch it back on in a minute. I feel like there's some glaces, some of the glaces. There's really funny Mexican geyser. Or a Mexican fellow, man, whatever, geyser. Yeah, so this is as far as I've got. When I've sorted this out, I'll do the catch-up with it. I thought I'd just give this a quick power-up and we'll see what it does. And the reason why I'm going to do it now, and we're going to see what it does, is because I had one of these little, I think it's like an ionizer on an early run. And I'm not the voltage control on the power supply. And it exploded. So I thought, while I'm having so much fun, or while I'm having so much fun with things exploding, let's see if I can get this power supply. Because to be fair, this is the first home I've built onto a Perth board. And I'm not sure, this is the first home I've built a full-bridge rectifier in this order, you know, side by side of each other. Like this. Yeah, and I'm not sure I've done it right. I mean, I'm sort of pretty convinced I have. I'm not quite sure. I've put a 9 volt regulator in there. I've put a 140 ohm and a 220 ohm resistor on that. And I've come off with a 22 mic, I think, capacitor. I don't want to pull it around, so in which case I'll break all the bloody wires. So what we're going to do is I've not got it connected to my... I've not got it connected to the TEA, just in case it does do anything crazy. But I'm pretty safe. I've got a fuse here, so that's good, you know, for this little transformer. We've got a power switch. I've stuck some heat shrink. No, heat shrink, heat shrink. What's that stuff called? Heat shrink. Heat shrink tube. Yep, that'll do. And I'll put that over there, the live terminals there. So we're pretty isolated here. It's pretty good. It's quite safe, like I said, we've got a fuse built in here as well, so... Yeah. So, we're still onto DC. I hope I'm getting a DC out of this. And I'm going to get some power. Oh, I've got myself an inline RCD, so I'm just going to put some power into this box. And it's not switched on here on the switch yet, so I can't put that down. So it's all going to be what happens now. And what happened now is nothing that I thought was going to happen. I actually thought that was going to do something like work. And so I've maybe got something wrong. That's chunked out of that. These are all connected out of there yet. That's on DC. These are all the ones that is definitely connected there. That's connected into there. Come on. Come on, come on. That's not very good. I suppose I need to know where I haven't got voltage. So let's just try that one more time. My voltage, we've got 12.9 volts. 12.9 volts. Ha. That's not good for me really. I needed 13 volts. I needed 15 volts. So I need to change these resistors, don't I? I need to swap one of these resistors out. Okay. Okay, well that's good. That's good. Nothing's blown up. 12.8 there. Let's call it 13 volts. That's rising a little bit. That'll do, yeah. So 12.9 volts there. No flames. Obviously we're rectified so that works. Okay. Okay. Now I'm just going to adjust those resistors. I'm going to see if I can get a little bit more voltage. I just want two more volts. One and a half more volts. That will do. I can work as low as... I could try actually. Come on. I could just hook on to that and see if that actually works. Yeah, let's go back and see if it works. 13 volts. I just want to pre-regulate it.


The G20 Central Bank Governors and Finance Ministers met in Cairns this week to discuss how to reach 2% growth targets by 2020, but my question is what if the answer to increased sustainable and balanced growth in the global economy was women and investing in women and investing in gender equality measures. So I've been joined today by 68 world experts on gender equality and gender and economic governance and we have had the most fascinating discussion. We had Minister Cash this morning explaining the employment minister's meeting outcome of 25% of the global gender gap being closed by 2025 and we've also got members of the business community and academia. So it's been a fascinating day and I'm confident we're going to come up with one page of recommendations to give to the Sherpas that's going to help them meet their growth targets but also help us to protect women's rights at the same time. So gender equality doesn't necessarily mean that all women should work or no women should stay home and look after children nor elderly parents. What gender equality at work means is that women should have the same range of choices as men. It doesn't mean that they make the same choices as men but they have an equal range of choices in terms of the types of jobs, the career paths and opportunities to balance work and other pursuits. And the G20 agenda was to deal with the problems of the financial crisis that started in 2008 and I think if you want to look at the most vulnerable you have to look at women and children. So looking at the vulnerable groups that were devastated by the financial crisis you have to deal with women because women are the faces of poverty and problems that came from the financial crisis so I think that's a very important group. Secondly, the G20 agenda wants to now include economic resilience, economic growth so that countries do not fall back into this crisis mode and even if they are faced with crisis they're resilient enough to withstand it and so for both reasons women are very important and if we don't take care of women in the economic resilience and growth sector we won't have the kind of resilient growth that we want to see in the G20. I think the G20 is important not only because economically it's a critical group of economies in the world but also because of the diversity that we have among the best and indeed the worst performance in terms of gender equality and I think showing both the importance of concrete political commitment and political leadership for example through the 25 by 25 target which has been discussed among the employment and labour ministers showing how that can be done indicators to ensure accountability and monitoring is very important I think to show the world that progress is indeed possible. If you look at Korea's history we've seen a tremendous economic development and we have seen large numbers of women come into the labour force and be educated but they're not empowered so women's pay is only a 64 cents to a man's dollar women's participation in the national assembly is less than 15 percent so unless you have concerted efforts for education employment and empowerment together women will really cannot be active player in the country's economic development with the increasing interest in gender equality around the world there's a whole range of experimentation innovation underway but I think a good example in a challenging context like Liberia which is a post-conflict very poor country is a program targeted at adolescent girls and seeking to bridge the transition from school to work by providing skills not only traditional vocational skills like for example craft skills but also metalwork welding and combining that with life skills so life skills in terms of reproductive and sexual health in terms of building up confidence in making life decisions and that's been shown to have important impacts not only in terms of income which is clearly very important particularly for poor girls and women but also in terms of expanding their horizons increasing their confidence and their aspirations. I come here as a practitioner I'm now Queen's Council so I have achieved so I'm a little example to people out there that you can do it I just want it to be easier for people in the future than easier than it was for me and I'm very grateful to my mentors I think the agenda across the world in any sort of business political economic financial legal sector is dominated by men and really what will achieve change is to put women in those places at the top to make sure that we are part of the conversation at top level I'm not suggesting all the women move in and all the men move out and if you like a lovely happy family is a mum and dad and all the children coming along the way if you can think of it in that way the table needs to have mum dad and all the young people having a conversation about where they're going and what they're doing it's a bit of an easy way of looking at it but that's really what global governance is about is having is governing everybody so everybody ought to be part of the conversation in my opinion


Good day! I would like to extend my sincere gratitude to Purdue University for adding me to the list of distinguished engineers, alumni, and for taking a note of my career and giving me this recognition. Although I joined the university over 54 years ago in 1967 as a 22-year-old wanting to learn and be challenged, this occasion has allowed me to time travel and relive my years at the university as it were yesterday. Coming to the US from India in 1967 with a borrowed $3,000 debt with hardly speaking English and joining Purdue's MSME course was a major milestone in my life. As a kid born in a struggling lower middle-class family, ninth of nine children in a house with no running water or electricity, it was quite a task to survive and win over daily challenges instead of designing career goals and preparing five-year vision plans for my future. Lending up Purdue was game-changer for me as it put me right at the front seat of the upcoming Tech Revolution in America. For that and for opening up more possibility than I had expected. I thank the university and my professors for helping me succeed as a student in preparing me to be an efficient professional. Memories from Purdue mind-boggling and it still reminds me almost every day my journey at Purdue. Let me tell you more about the Missouri story with you about my time when I graduated from a mechanical engineering program at Purdue University doing my master. I was able to complete my courses in 11 months as opposed to the regular course duration of 1.5 years. I was lucky to receive three job offers from some of the biggest companies in America. 1968 was a race to put men on moon and Vietnam War was in full swing.  Engineers America was struggling to get available talent for the industry. One of the three companies was IBM. Now IBM was and still is one of the most prestigious companies to work with at that time. However giving into my aversion to be one of the thousands of engineers at IBM and rather joining a smaller team expecting a steeper learning curve. I declined IBM. My foreign student advisor was not happy that I did that. I guess I had to bring out my true boiler maker spirit in pursuit of a hands-on job. In so time I learned computer programming, admiration for high-tech work, hard work, ask questions and ability to learn from many while respecting all. I also understood many of the culture of Midwest of America. Getting to America was biggest risk and acquired ability to take risks. After working for 15 years in Cleveland and Portwine I joined rapidly growing export import companies started by my wife MSI in our basement with two growing sons. Today after 46 years over Indiana Corporation, MSI is a family-owned privately held enterprise headquarter in Southern California with over 2,000 employees in America supporting 180,000 jobs in 34 countries or forced 40 facilities in many metro areas of USA Canada over 6 million square foot print for distribution of our product and geographic reach to 90% population in 90 mile radius of each facility. We'll celebrate this year basement to two billion dollar revenue. I use my engineering knowledge every day to guide and coach 100 plus leaders at MSI. If I have to sum up one word of advice to all engineers be adaptable. Word is changing fast and rate of change is accelerating. Use technology for leapfrogging processes and procedures. Thank you and good day.


We were trying to raise 30,000, really we need 70, but we said we needed 30,000. And we did almost 400,000. Like it just, first it was all friends and family, but then it just started taking life of its own. And that was the start. What do you think was one of the main levers that took it to 400,000? Specifically for the crowdfunding campaign. There are so many. And I did a Reddit post about all the things that I did that were like, I guess unique. Like I lead on all the great blog posts that I could find out there and work from the tactics. But if there was one that really stands out, we did Indiegogo and they have a thing that if you get to 30% of your campaign goal, you can do a deal with them. They'll put you in their newsletter marketing, which is like a lot of people buy from it. So that's why we said we need only 30,000 because I'm like, I bet you I could wrangle up $10,000. Also if you get 30% of the 30,000 that put you in the newsletter. Yeah, so I need to get like 10,000. So if I made it 70,000, which was really needed, I'd have to go get, how can we get, we need to get 20,000 plus for in the first 48 hours. So we just hacked, just game the system a little bit. I mean, it's not, they don't really care how you do it. Within the first 48 hours, you have to do it or? First 48 hours, you need to get 30%. Got you. So I, for a month leading up to it was just knocking on, I was messaging everyone on my face, but I wasn't just messaging. Yeah. Because if you mass message people, they know that they can tell that it's a mass message and they can just close it and like not reply. What we did is, first I asked them all, I said, hey, can I ask a favor of you? And I asked, I said, I'm gonna be launching a clothing company in like a month or an hour, whatever the time was. And I'm really trying to get this thing off the ground. It's been a labor of love for a year and a half. And I just need support. If you're okay and don't feel any pressure, but if you feel like you could buy a shirt off us and they're a bit expensive, you know, the early bird price was gonna be like $45 or $50 US for a t-shirt. It would mean so much to me, but it's an unbelievable shirt. And this is the best price that you're ever gonna get because it's an early bird price. Are you willing to? And most people said, yeah. Some people said, you know what? I just can't be spending any money right now. Some people didn't reply. But when the day came that we were launched, instead of asking again, I created a video one for each person that I wanted to ask. So it would be like, I just turned the webcam on and be like, Amir, how are you? Stan, remember I told you I was running that? Well, we just launched it. It just launched today and was so proud of how it turned out, but we're really nervous. We're really hoping to get your support if and whatever I asked.  Yeah, you do the things that don't scale. Yeah, yeah. I made it personable one time. And we stayed up all night for nights building out this library of videos.  So something got like, we were hammered and something got nuts. But people watched it and they felt like, okay, that was for me, it was very personal and they are asking for, I can do it. So it was very easy for us to get that first $10,000 in sales. So if we did it in like a couple of hours or something, it was all friends and family. And I remember seeing it's like Brian Demsky, my brother, Sandy, my business partner's cousin. I remember these names coming in with all these orders, just people I know, people I know, people I know. And then once you got to 10,000, the crowdfunding algorithm sort of like, use you as a trending campaign. There's all this traffic. And then you start seeing like Johannes and Berlin. Who's that guy? You know, I started seeing these other names and it just kept coming, coming, coming, coming. Then we started buying ads so that we could keep the traffic high. And it had this illusion of being a very successful campaign very fast. So it took a life of its own.   Okay? I was a little unhappy before and now I have this thing that I really believe in. It's so authentically me. So I had to make the decision. Do I continue with this and leave everything behind? And that's what I did.


Hello to all of you! This unit exhibits the options of examining the student's knowledge and performance, ranging from diagnostic to summative. Furthermore, the unit will define various types of exams used and the possible degrees of automation. As usual, you should start with a virtual session where you can find all possible types of assessment as well as the options of integrating assessments into degree programs, courses or individual e-learning units. Don't forget the question seat as default guidance through the virtual sessions. The unit's mastery worksheet is a dynamic choice task about assessment, but it should be easy to solve after the virtual session. Well, and this unit's practical once more involves collaborative teamwork. We want you to find assessments on the web and to search for ways of integrating assessment into degree programs and courses. Try on your own first. The model's suggestions will be given once the next unit comes into focus. So, that sounds like a lot, but it's manageable, I'm sure.