Would I need to dive to actually experience a fatal amount of radiation? How long can I stay safely at the surface, and so on? There's some interesting working here. Basically, the kinds of radiation we're talking about, the amount of radiation halves per seven centimeters of water. So actually, you're pretty safe. And you might actually get less radiation exposure sort of just below the surface in the pool outside. And it gets bad if you get really close. So there's that. However, I think the most amusing observation is the one at the end. Just to be sure, I got in touch with a friend of mine who works at a research reactor and asked him, what he thought would happen to you if you tried to swim in their radiation containment pool? In our reactor, you'd dive pretty quickly before reaching the water from gunshot wounds. So think laterally. However, curious enough, that's not the reason I'm here to talk. I'd like to talk about this question, a craftsmanship. What is our motivation for it? What do we mean by it? What perhaps don't we mean by it? What is it antagonistic to? What is it sympathetic with? Just out of interest, just so I know, the degree to which I can reuse things. Who was at my keynote yesterday? OK, I can recycle a few jokes. And a couple of themes. There'll be about two slides that are the same. There's an overlap. But I'll start off with a very similar theme. A few years ago, I co-authored this book, Pattern-Oriented Software Architecture, Volume 5. This book was on patterns and pattern languages, as the title actually suggests. It is very much a theory book. I'd love to say, this is the book you should buy if you're interested in patterns. No, this is the book you read after you've read other books you're interested in patterns. You say, you know, I really want to get inside this idea. I want to know the theory. Frank and I, we kicked this off. Our motivation for writing this was, we keep getting asked the same questions. And we thought, there's no one place that has the answers. And now there is. So it's a response to that. But there's something relevant about the patterns that I'm going to come back to. Relevant about patterns and the ethos of patterns community. I guess this is kind of relevant because Guru Plop is kicking off tomorrow. There were two forwards. One was by Dick Gaver, or the other was by Wayne Kool. Wayne Kool made this observation right at the beginning. Art, craft, engineering, science. These are the swirling muses of design patterns. Art and science are stories. Craft and engineering are actions. It sort of creates this spectrum, where he positions each one of these concepts. And it is a fairly grand claim that in software development we produce art. So one of the themes I'm going to borrow from my keynote yesterday is, as software developers, we do produce art. Installation art. This is Madrid, terminal one. And it's quite a large error message. I had to take two shots to get the whole message. For a lot of people, they're going to be wandering through, kind of ignoring it. A few people are going to look up and wonder, for the non-technical people, the non-technical people are going to focus in because, culturally, we are tuned to do this. We find the word free. Five free packets. Where do I claim my five free packets? I don't know what they are, but if they're free, I'm having them. So this is a nice, large piece of installation art that we accidentally put out there. Now, there's something else that's interesting about this. We can work out what's going on. If when this visualization, when this screen is working, you don't know what operating system it's running. Here, you can tell it's a Linux distro, simply because of the language. I don't know which distro it is, but the language used, it's a Linux distro. So when it fails, we reveal something about the overall structure. We see this as well here, one of my favorite little examples. We get into people's homes and we give them art. This is the Dutch Rail website, NS.nl. Now, I took the screenshot a few years ago. In fact, definitely a few years ago, because this, for me, is many browser generations ago. After Mozilla, I used Firefox, and then I used Chrome. So this is way back. And I was going to see a friend. I was in the Netherlands, and I was going to go see a friend. And I thought, how do I get from Amsterdam to Davenrecht? And so I looked, and I got some times. And I thought, I'm going to see him and his family, and the Dutch eat really early in the evening. So I'm unaccustomed to this. So I thought, I'd better go and see JC a little bit earlier, because last time I turned up, his children were crawling the walls, starving. So I thought, I'll turn up at 5.30, and we'll eat then. So I clicked for an earlier time. Apparently, there is no earlier time. There is only Java dot line dot null pointer exception. Now, this is interesting, because have we not already figured out the technologies involved? I don't understand. Why do people insist on telling you their technology? You don't have to do this, because it says, servler, I can hide all of this. It's like all those pages out there. They've got .php and .sp. It's like the default ringtone on your phone.  That shows you have mastered your technology. What's funny is that many of the .php, .jsp, and .asp pages out there are not what they claim to be. There's Ruby sites that are replacing PHP sites, but they have to be link compatible. So they're masquerading as .php sites. You don't have to publish all of those lessons about encapsulation. People sort of say, yeah, we do encapsulation, except when it really matters, we tell the world the technology. We reveal everything. But had we not already figured this out, we now know. This failure reveals something about the software. Now, this is interesting, because it also raises questions in our mind. It's kind of practically an article of faith in UI design that you never, ever let the user see a low level error like this. You kind of come back with, I'm sorry, this doesn't seem to be working right now. And you can do that in English. You can do it in Dutch. You just don't do it in Java. And that's kind of, so the question is, how did this get through? What caused or permitted the team to create the software? Now, it is entirely possible they were unaware, a lack of knowledge. But although we regard it as a common piece of knowledge, one of the things we've discovered about common pieces of knowledge is that they are surprisingly uncommon. So maybe they don't know. Maybe we're dealing with new developers who are not connected to a larger culture where this is seen as obvious, and they've not picked that up through immersion and exposure to conversation. So that's a possibility. Maybe it's to do with their testing regime. Maybe this doesn't get through. Maybe it's to do with code reviewing, that this isn't spotted, that people aren't really kind of tuned to that. There's lots of possibilities. So I don't know the answer, but I now have some very good questions. So this is what I'm now equipped with. However, the thing that I find most revealing is that it actually also tells us something about the development process and the organization that surrounds the website. Because I used this slide a few years ago in the Netherlands, about a year and a half to two years after I'd taken the screenshot. And I got the usual laughs. And a guy came up to me afterwards and he said, you know they still have that bug. So now he wasn't originally one of the developers. So what we're saying here is that people across the Netherlands, random people on the street, will know of this bug. Maybe it's valuable. Maybe it's culturally significant to the Dutch people. You can't change the website. This is part of our identity. We like to be tall and we like this bug. But people knew about it and it had not been fixed. We're talking about a really long bug-fix cycle. So what does that tell us about the organization and how it prioritizes and responds to defects? Again, I don't have an exact answer, but I now am equipped with a very particular set of questions that I would like to find out. So it turns out that this kind of in-context failure raises a number of questions that allow us to question and hopefully improve. This is what I didn't take this photograph. This is the Ariane 5 Launcher. It's one of the most powerful and most reliable launchers on the planet. And this is what it looked like on its maiden voyage on the 4th of June 1996, being qualified as Europe's most expensive firework. It scattered parts of the cluster mission over the forests of French Guyana, which I'm sure didn't need the extra pollution. Now, this is a very telling tale because we can actually reveal many things about it. I love this as a worked example because some software failures are either very, very simple or quite tortured and difficult to work through. But just before we explore the details, I want to equip you with appropriate jargon. You don't say the rocket exploded. You say, it experienced a Rudd event. Rapid unscheduled disassembly. You might want to try that next time the server crashes. Did the server just crash? No, it's a Rudd event. And people will not want to admit they have no idea what you're talking about. They're, yeah, yeah, that's what it was. Just try that. So I found it fascinating because the example was very well worked through. There was a study, there was a report on the causes of the failure, came out in late 1996. And I read that. But my interest was peaked recently. A couple of years ago, my co-author, Frank Bushman, sort of said, oh, Kevin, you know about the Ariane thing. And I said, yeah. And he said, yeah, I've got the code. I put it in the slide because he got interested in this. I put it in the slide. And I looked at the code. And I said, that's not the code. He says, how do you know? I said, I can read it. It's too clean. This is the sanitized version of the code. In other words, it's like what happened, but it isn't actually the code. However, relatively recently, so I started trawling the web to see if I could find the original code. And there was a presentation. And there it is. June 96. There it is. There is the code. And there is the offending code down there. Now, the whole presentation is in French, but you don't have to understand French to get a sense of the title. And putty-boog, and grand-boom. You kind of get the gist of what they're talking about. And it works through the issues. Now, so I want to do a quick code review here. Let's see if we can spot some things. First of all, language. Pascal, that's not bad. Warm? No, no. They don't program rockets in Delphi. They program Airbus A320s in Delphi, which worries me. It looks like Fortran, doesn't it? Ada, you're both kind of right. Because it is actually Ada. But it is a sub-dialect of Ada, known as AdaTrend. In the sense that it's not really a dialect of it. It's just what happens when you give Fortran program as an Ada compiler. I was unaware of this term. It doesn't surprise me at all, because I programmed Fortran in two jobs a long time ago. And I remember when I learned C in the first job, I thought I'd mastered it. I thought I knew what I was doing. I was getting it past the compiler, but it was C-Trend. It was C, spoken with a very heavy Fortran accent. And we have the same kind of issue here. AdaTrend. So Linda Rising made me familiar with this term that she has worked in the aerospace industry. Oh yeah, that's AdaTrend. Now, what happens when you give this kind of stuff to Fortran programmers? Well, let's see here. What do you notice about this code? Magic numbers. And they are truly magic in the sense that 32767, I'm glad I'm a geek, because that number means something to me. I played a game of doubling with my 10-year-old the other week. He said, dad, I can double numbers. I said, so can I? I had to do that all the time. And so we did this. And I said, the difference, and eventually it was taking longer and longer to add this stuff. And I said, see, they're hard coded in there. When I'm seeing Ireland and Suffering Dementia, I'll still be able to do the powers of two. I don't remember who I am, but the powers of two will be still in there. So we see 32767. We see minus 32768. Oh, OK. So we're talking about 16-bit side. And of course, because we have Fortran programs, we do not trust the compiler. We do not trust the abstractions that Ada gives us. Ada actually allows you to do stuff like interrogate the type. You can do it as a compile time constant. So a small int, dash, and you can put the property in. I want the max size. I want the min.  You put it in yourself. This is what people mean by heavily typed code. You just type it in. And then you type it in again. Because that way you can be sure it's right. But eventually you'll get bored. And for a bit of fun, you'll put it in hex as well. I mean, why stick to one base? Not only do we have magic numbers, but we decided to flip between bases, either because we're bored or we're trying to show how conversant we are. I mean, I haven't seen the rest of the code. Who knows? There might be base 17 lurking in there. You can go up to base 32 in Ada if I recall correctly. So we've got a lot of repetition. There's a sort of hypnotic trance-like quality to this code. The same kind of structure. Notice the similarity of everything. It's just like, is this an artifact of the Ada language? No, the Ada language is one of the first languages to actually standardize the concept of inline pragmas. I could sit there and say, you know what? We're going to have this is a thresholding piece of logic. If it's above this, threshold it. It's below that, threshold it. Otherwise, use the raw value. So it's a value conversion. Why write that in one line when you can look like you're doing real work, which we know is copy and pasting, and extend it over a larger scope? So what we've got here is an overflow issue. Just out of interest, I want you to use your intuition. What do you think these kind of v, this v might mean? Vertical, yes, because h is horizontal. This is actually components of the horizontal and vertical velocity. We now join the story where I knew about it. What do you think 32 represents? 32 bits, floating point number, all so close. It's actually a 64 bit number. But because we've decided to encode the type in the name, and because this lives within a process where every minor change has to be signed off, no matter how bad the code is, when you realize you wanted a 64 bit, well, we'll just leave the name as it was. So the code is lying to us. And we'll see that all of these values are thresholded, basically. And it turns out that this piece of code is the bit that caused the explosion. Because at 37 seconds into the flight, the horizontal velocity overflowed, the 16-bit boundary. But it wasn't checked. You'll notice there's no guards around it. And at this point, this piece of code went crump. Because in other languages, when you do this kind of conversion, it kind of says, oh, and I'll give you some number. But this is Ada. I'm going to give you an exception. I'm hardcore about this. I'm going to give you an exception. But because we know that this could never, ever happen, never, ever happen in Ariane 4, I'll come back to that. You might notice a diff. This could never happen in Ariane 4. We never put an exception guard. So this part of the guidance system failed, and fed garbage guidance data, and started the rocket spinning. At 39 seconds into flight, the self-destruct mechanism successfully went off. Now, you see, up until this point, I thought that self-destruct mechanisms, that's the stuff of science fiction movies. But actually, no. This is legit. It's installed on rockets. You really don't want a rocket to be going too far in the wrong direction when you've lost control of it. Kill it now. But I do always wonder about that from a job satisfaction point of view. So what code do you write? I write the self-destruct mechanism. How does that work out? Well, hopefully, I've never actually had a call to use it. But we do know that that worked. That was a very profound, whoever wrote that piece of code must have been sitting there going, uh-huh, yeah, that worked. Here's the issue. This is a subtle thing. I just said this was Ariane 4 code. But that rocket which blew up was Ariane 5. Ladies and gentlemen, welcome to reuse. They left the code in Ariane 5. The funny thing is, it wasn't actually needed. All the functionality for that part of the guidance had been taken over by ground control. Had this not overflow, it would have hit the 42nd mark and shut down, and everything would have been plain sailing. But that's the key thing. Ariane 5 is a much more powerful launcher, as I said before. People have this mistaken idea that the purpose of a rocket is to go up. It turns out that space technically starts 100 kilometers up there at the Karman line. It turns out that what you want to be doing is going along really, really fast.  That's 100k. You want to be traveling horizontally 11 kilometers per second. That's non-trivial. So your booster should go horizontal, much faster. And Ariane 5 does this five times faster. It goes horizontal five times faster than Ariane 4. And hence, it overflows. So we have here unquestioned reuse of a component that was never actually required. So next time, by the way, somebody says, I'll leave that code in. We don't need it. It's fine. It's benign. Refer them to this. And the testing and management culture, there's a whole load of stuff that went on there. So yeah, an interesting case study. And we can even start. So some of its management, some of its culture, some of its testing, some of it, we can even start questioning the quality of the code. Because if I had a simple function, threshold this. I'd have been done with all of this in just a few lines. I'd have been able to see that. It would have been trivial. So there's a certain sense of skill. And we want to question here, as well as the larger picture. I use this quote yesterday in my Driven to Test talk. As I said at the time, this is from Kirk Papadine. Functionality is an asset code as a liability. Now, I think this is interesting and provocative for the simple reason that I've maintained the opposite for most of my career. Well, I'm not exactly the opposite. I've maintained the idea that code is an asset. But curiously enough, by phrasing it in this opposite sense, it turns out that it does reveal the fact that we really, really want to care about the code. Because if you have a liability, you watch it like a hawk. You try and make sure you don't have the wrong stuff that gets in your way. What people want is the functionality. If you have lots of dead code, if you have lots of technical debt, if you have lots of issues with the code itself, what you've done is increase the liability. You haven't managed it at all. You haven't controlled it. You've let it run away. You are losing hold of your asset, the asset being the functionality. Your ability to add new functionality is being compromised. So opposite as this initially sounds, it actually tells you why code quality matters. I used this example yesterday as an example of a bit of fun, a bit of art in software. It's called the Clobe, in Suki Endo. Here we see somebody who has had a great deal of fun writing a piece of code. It's OK. You can enjoy this stuff. It's all right. This, when executed, this is Ruby code. It's wrote in 2010. When you execute this, it rotates through 45 degrees. When you execute that, it rotates another 45 degrees. And so on. It's a multi-quine. It's really cool. You can even run it with a specified number of degrees. It does that. This is very, very cool. Now, it doesn't drive rockets. But at the same time, it shows us something else. There is skill involved in coming up with this. There are all kinds of competitions of this kind of thing. It's kind of all the crazy stuff that people occasionally do. And it's OK. I think we need a little bit more fun. But it also shows something you're looking at and going, wow, you sense a greater mastery of code in the Clobe than you do in the Adatran for Ariane 5 or Ariane 4. And yet, this was done with frivolous fun. So clearly, the skills are out. They're just unevenly balanced. When we talk about the idea of software and code, code is art, one of the things that we also want to do is break out of our usual rut. You get used to looking at code in a particular way the same way all the time it becomes. So mind-numbingly familiar that when people do introduce differences, you don't notice them. Sometimes I don't think we appreciate how complex software development is. So can I just get a sense? People who are working on projects, they should involve more than 100,000 lines of code. 100,000 lines of code, that's a lot, isn't it? Anything higher than 500,000? OK, we're going, OK, so we're thresholding. So we're talking about a body of code. Well, let's just rewind a moment. How does that work? How can that work? This is one of the most ridiculously complex things human beings have ever undertaken. The problem is it doesn't look physical. We appreciate things by their physicality. If you've ever stood at the bottom of a very large structure, such as Skyscraper, or a few years ago, I went to the south of Brazil and sort of looked at the Taipu Dam from the bottom. It's a huge dam. Regardless of any environmental impact, you're standing there, and as a small, insignificant human being, you cannot help but feel impressed by this physical structure. And yet, the Taipu Dam is simpler than most large software systems, because it's the same piece as a concrete again and again and again. The calculations were done. They are far simpler than what we were undertaking. This was brought home to me in the late 90s. There was an issue of Scientific American that was focused on mega-engineering projects. And they had three gorges down in China. They had, I think, the bridge across the Orison between Denmark and Sweden. And they had a whole load of others. And they had Windows 2000 development team, which initially seems kind of really funny.  These guys producing the order of 20 to 25 million lines of code individually put together in a way that has to work. It is technically complex. You're talking about a team of a couple hundred people. And they are not laborers. They are all designers. In other words, they are all technically skilled.  They are all at that elevated level. They are all technically adept. That's really quite challenging. It just doesn't look very impressive when you compare it with large structures that the human senses are tuned to. Oh, yes, damn, very big, very impressive. Code, not so impressive, it fits in the little box. And the boxes get smaller. It doesn't look impressive, and yet it is. A modern, long novel is about 100,000 words. I want you to think about that for a moment. It's 100,000 words placed one after the other using a simple concept called the sentence. It only has to make sense when red from front to back, unless you're getting a bit post-modern. It only has to make sense in one linear execution. That would be fantastic if we wrote code like that. This code is a one-shot. It only does one thing. There's no ifs. But our code is like a choose-your-own-adventure gone crazy. Everything is a branch point. Everything is a decision point. It is one of the hardest things that we do. And we don't appreciate it, which is why it's very difficult to look at code and to extract everything from it. The best we can do in a large system is sample it and surprise ourselves. This is one of the techniques I think is most interesting. It comes from Philippe Calçadeau. He blogged this about three years ago. This idea of take a system, take a code base, strip out the comments, take out the string literals, and put it into a tank cloud generator, used Wordle. And that will show you the frequency of, it will show you the most frequently used words. And we see immediately that this is Java. Import. So there's a lot of language plumbing here. Once you get below the language plumbing, what do we see in the system? String. String is the new int. String is the universal data type. And we see, oh, there are ints. Can we play anything? Yeah, we've got a list. Brilliant. So yeah, I'll come back to that one. It's a little bit. It's missing its domain. It's been compiled into the code. In other words, developers have sat there, and effectively they have built up a mental model of what the system is supposed to do. And they keep that model privately within their heads. They're not sharing that model. Because what they've ended up doing is they have said, it's like this, and you can do that with lists. It's like this, and you can express that in strings. So what they've done is they've already pre-compiled. This is what I call object-oriented assembler. It's probably filled with a lot of get-and-set stuff. It's object-oriented assembler. We have failed to take advantage of a language feature that allows us to express the domain in a way that is comprehensible. I mean, yeah, string's kind of popular. But nonetheless, we have an image problem as it stands.  You end up with this scenario. What do you do? I'm software development. And you can sense immediately they're looking for the door. They're trying to figure out how to escape. They kind of hold on. There's some little hope in there. There is a possibility that you do something really interesting and cool. Maybe you're actually a games developer. Maybe you've got some funky startup. And so what kind of systems do you produce? I produce systems that have lists of strings. OK, that's it. Conversation over. Come on, we can do better than that. Here's another one. We'll take ourselves and apply the same thing to another system. Now, I can't tell you exactly what this does. But once we get beneath the language plumbing, I'm already getting a sense that the domain is shining through the code. Printing device, picture, product, paper. I'm getting a very different story from this. It does turn out, and you're stutely spotted in the previous one. There you go, car ID. There. There's class, looking kind of small and embarrassed. And then we look around. Class is looking a little happier here. People are defining classes. You know this idea I have? Which idea? You know, like a code. Oh, you can hold that in a string. Yes, but the code itself is not a string. Code has a rule. So the one I often use, I use it as a coding carter, is ISBN validation, ISBN 13, international standard book number, 12 digits, and a 13th digit based on a check sum. And you can also have spaces and dashes in the middle. And it's a really interesting problem, because people try to get all algorithmic, and they kind of break out of any TDD stuff. And now you can do it in a perfectly TDD style. But what is interesting is that a number of people will just do, in a larger problem, are doing a book catalog. They won't just do the ISBN validation. They will generally pass it around as a string, rather than creating an ISBN type. In other words, it's not a string. A string can be used to hold it. But itself, it is not a string. I see this in systems where you end up with a code being passed around, and it gets validated here, and validated again just to be sure. Because you can never trust that code over there. Because it was either written last week, or by somebody else, or you just want to be sure to be sure. Whereas a type provides a constraint, regardless of whether you're dealing with a dynamic or a static language. The purpose of a type is to say, look, this is one of these. It's not anything else. You'll know if it's something else. You can express the concept very directly. So we have this idea of being able to, also, there's a meta-skiller, being able to try and choose unorthodox approaches to looking at your code. This is one of the more interesting ones. There's a whole load of other ones. One of the ones I quite like doing, which I discovered partly by accident, is zooming out. So you can't actually, so all the code is in, like, one or two point font. And, well, you can't read it, then, if it's one or two point font. No, you can't. But it's like flying over a landscape. You see things from the air that you don't see at ground level. You see these vast sweeping structures that repeat across the code. I actually started it when I was looking at some code many years ago. I was scrolling down the screen, and then the screen went white. Because the code was indented outside the window frame. So much indentation. 1,500 line method. It's just like out here. It's just like having that beautiful blank screen. It's elegant in its minimalism, but not, perhaps, that practical. So we have this question of skill and care. And where does that come from? How do we develop such expertise? Now, this is a quote I used the other day, and I want to revisit this one. Because I find it concerning. Christopher Walken, actor, if you want to learn how to build a house, build a house. Don't ask anybody to just build a house. Part of the reason I put it up here is because I remember the Agile Community actually posted this on Twitter to try and make a point about learning. And they were saying, it's a positive thing. You've got to do it yourself. And I said, that's the worst pedagogical advice you could ever offer anybody. Because what you're doing here is, first of all, sure, people have to do stuff themselves. One of the things, if you learn to swim, you can go and read all the pages on Wikipedia. But until you get in the water, you haven't learned to swim. You do have to do something yourself. And there is a way of doing this. First of all, you don't overexpose yourself to too much information. But you take advantage of what other people can offer. Because software development is one of the hardest things we do. We know how to do stuff. To deny yourself that community, that hard-won knowledge, doesn't seem to be particularly practical, particularly with a house. Self-build houses, that seems dangerous, especially if they're anything more than one floor high. And people have a very particular quirky way of doing things. The point that I often make with this is that when people are self-taught, they often become attached to the accidental way they discovered how to do something. Because that's my style. That's how I do this. Oh, yeah, I see other people doing that. But the way I do it is this. Regardless of how dysfunctional it is, they own that. That is part of who they are. You can help them. You can give guidance. You don't just let, you know, it takes a really long time. If you imagine how to build a house incorrectly, list off all the ways, get back to me when you're done. And all the ways to build it correctly, you'll find the second list is much shorter than the first list. There are lots of ways to build structures incorrectly. And there are lots of ways to build code incorrectly and software systems in a way that does not serve the team, the customer, and so on. So it turns out there's more ways of doing things wrong than there are of doing it right. And you can let somebody wander this barren landscape and accidentally, you know, hope that they'll accidentally one day stumble across the perfect technique. But the odds are against them. It's not that it can't happen. It's just it's not likely to. So we want to help people. We have the knowledge. We want them to do stuff themselves. Until they've done it, they haven't done it. But that's not the same as ignore the knowledge that's out there. What happens when people do it themselves? You know this story. Eke Homo. This is in a church in Spain. It was painted in the 1930s. It's not a major, major piece of art. But it's deteriorated over the years. And one little old lady, Cecilia Jimenez, decided she was a local artist in her late 70s. And she decided that she would restore it herself. Now this is one of those things that when you learn and yourself talk, you are particularly susceptible to the Dunning-Kruger effect. Dunning-Kruger effect is where you don't know how bad you are at something. You don't know enough to appreciate that you're not good at something. And this is what she restored it to. It's been variously called Potato Jesus and other things. It is actually now a tourist attraction. People pay to go and see this. The original family of the artist are absolutely up in arms. They want to sue her, whereas she's currently trying to sue the church to get a percentage of the proceeds that they're getting from the people paying to see this. And does this look like code that we have seen? Yes, it does. That's unfortunate, because we have the knowledge to produce stuff like that. Doug Rockford noted in JavaScript the good parts. Programming is difficult business. It should never be undertaken in ignorance. Whilst you have to let people explore a little, you need to give them enough, and you need to be on hand to help. You need to offer certain advice. I'm very, very wary of trying to transfer my own personal interest to my children. I'm very careful of this. But they're kind of getting a little bit interested in programming. We've done some stuff with Python. We used a couple of other tools, Scratch and that. And one of the things that is really interesting is the way to do it is a little bit of guidance, help, and then stand back, let them experiment. One of the reasons I use Python and not Ruby is because Python uses arbitrarily large integers. The first thing I noticed is that when kids are using the command line, when you tell them you can add numbers together and you can multiply numbers, both of my boys independently put really, really large numbers in, like really, really large, like cover four lines, large, and then add it to another number like that. Dad, what's the name of this number? I don't think it has a name, some. Because I'll show you what a Google is, which sounds much more impressive when you tell them it's one followed by 100 zeros. Oh, wow. And then you look at it on the Python screen, and it just gets passed a line, and it doesn't look very impressive. So they want to know the name of the next number up. And yeah, there isn't one. So they experiment in a particular way. So all this brings us to what is hopefully a familiar document, a manifesto, saying we are uncovering better ways of developing software by doing it and helping others do it. Yeah, that value is right in there. We can do this. We know stuff. We're uncovering, and it's a continuous present tense. We are continuing to do so, although it's written 12 years ago. The idea is that this is always going to be true. And the way you get the knowledge out there is by doing it and helping others do it. Now, one of the interesting observations that we encounter that kind of runs counter-attuitive is there's a question. When people, particularly when they get business process consultants involved, of how should we improve our team? And this was forwarded to me, it's the MIT Sloan Management Review. It's forwarded to me by Alan Kelly, because he said there's a really interesting observation here. A large study of over 600 companies with an IT function within them was taken. You can be highly aligned or weakly aligned. And then there is effectiveness. How good is the IT? Not necessarily how good are the developers, but how good are their skills, because it turns out, bizarrely enough, who knew, people learn. But are they given an environment in which they are invited to improve, encouraged to improve? Are they given that environment or not? Now, the good news is exactly as people would expect. Look, highly effective IT, highly aligned with the organization. This is fantastic. IT, the growth that we get from this, great. The expenditure goes down. Most organizations, three-quarters of organizations, are down here in the maintenance zone. Yeah, not particularly aligned, not particularly effective. It turns out that's not as bad as it sounds. Look how close to zero these values are. The problem is when you want to move. A lot of business consultants will tell you, your goal is to become more aligned. And with that, your practices will follow. What happens in reality is disastrous.  It shrinks. Because what you now have is trying to take a group of people who are not up to matching the pace and the style of the organization and its priority, because they don't think like that. They don't work like that. And they are not necessarily good and effective, in terms of their IT. It now means that they are constantly getting interrupted, constant barrage of problems. And they don't know how to deal with them. Because they're being subject to a very different schedule. And they're not in a position to be able to do that. On the other hand, if you try to improve the practices, whilst perhaps, you know, control the practices, but don't change your relationship to the rest of the organization, of course, you can't run a control experiment like that. Your relationship will change. But if you emphasize the practices, it turns out that you get better. Now, point here, please don't walk away thinking, yeah, we should do the wrong thing better. That's definitely not the take-home message. What we're saying is, be no worse. What we're saying is, as you get good at doing the IT thing, it turns out your ability to respond, whether we're talking about build, test, code, whatever it is, your ability to do this is improving. And when somebody comes back and says, you know what, this isn't quite what we wanted, you can change it easily because you're doing, that's become part of what you can do. You become effective at being able to do that. It becomes easier to take this route than that route. So it turns out that alignment first is actually a dangerous strategy. Whereas you want to emphasize the practices. In other words, you end up with an effective team. You could throw anything at them, and they will respond.  You have to learn to be a team. You have to learn skills. And to do so is relatively irresponsible in a lot of organizational environments. Now, it's kind of led to the adoption of not specifically that, but all of these interests ultimately led to a reawakened interest in the craftsmanship idea. Because it was felt after around 2005 approximately that agile had shifted to a space that was less technical, that the majority of the focus of agile work had been triggered. I won't say it started. It has a long prehistory. But the interest in what we recognize as agile was triggered by extreme programming, KBEC's extreme programming. That was the provocative approach that came along. And it was a very polarizing concept. It was very radical. And this whole idea of it was provocative. So people suddenly notice. And then they notice these other approaches that were similar in their ethos, and perhaps a little different in their technical outlook. But that triggered that interest. But following the agile manifesto over the next few years, there was a sense that agile have lost some of its technical grounding. People wanted to reclaim that. So the craftsmanship movement has, in one sense, stepped in there. And the manifesto of software craftsmanship sort of acts as a response. Now, let's just go back. I'm kind of interested in the way that people write things. One of the things I do as a hobby is I write short fiction. So I care very much about words. So I'm very interested in the power of words. And so some key keynotes here, the use of continuous present tense, the collective first person plural, a very clear idea. Through this work, we have come to value. And this sort of simple statement of four values, a simple comparative individuals and interactions over processes and tools, blah, blah, blah. And a clarification. That is, while those value the items on the left, on the right, sorry, we value the items on the left more. And actually, this is a really nice piece of writing. And it's created a lot of follow-ons. I think the Sower manifesto is probably the least effective of more. The problem here is that this is well-meaning words. As aspiring software craftsmen, we are raising the bar of professional software developed by practicing it and helping others learn the craft. Through this work, we have come to value not only working software, but also well-crafted software, not only responding to change, but also steadily adding value, not only individuals and interactions, but also community professionals, not only customer collaboration, but also product partnerships. That is, in pursuit of the items on the left, we have found the items on the right to be indispensable. You can stay awake to the end of that. I don't want to diss the idea, but the presentation is very, very neutral. The manifesto should be slightly more provocative. Really, do I get excited by steadily adding value? Where's the fun? I get excited by other things. Where's the fun? There's the joy. Where's the provocative? Who's saying something really radical here? Nobody's saying, the other one was documentation. You know what? We value software more. Wow, for a lot of organizations, that's a real wake-up call. You can walk in and say, you can observe their activities. And you can see, well, you see you value documentation more than working software, because your whole process is engineered to produce documentation. And we can actually see this. There's actually a litmus test. You can apply to a company at that level. So although it's not a statement to process, it's still surprisingly durable. It's a nice piece of writing. Is this not so much? So let's look at the history of manifestos. So the Marinetti's Futurist Manifesto, 1909, was quite provocative. Futurism is a little bit dodgy in places. And it has a very, very poor view of women. So I'm not going to advocate it, but as its language, it's very, very clear. Because the purpose of a manifesto is to say, guess what? We believe this. If you don't believe that, that's entirely fine. It's not necessarily polemical. Its goal is to say, here's a strong statement of values, just so you're totally clear about what we mean. And we don't couch it in neutral business terminology. So here's a translation. We have been up all night, my friends and I. We've been discussing right up to the limits of logic and sprawling the paper with demented writing. Curiously, I think they were software developers. Our hearts were filled with an immense pride at feeling ourselves standing quite alone. Okay, we have passion. There's passion here. This is interesting. Suddenly you're engaged. You want to know what they're going to say. You want to know if you want to agree with it or disagree with it because they've engaged you. They haven't put you to sleep with business language. We want to sing the love of danger, the habit of energy and rationalism. Whoa, okay. The essential elements of our poetry are courage, audacity and revolt. Wow, okay.  But you know that. There's no ambiguity. There's no we're going to synergize with the population and leverage the facilities and society and say, no, there's none of that. It's direct. It's straight out. Artists do this a lot, by the way. I found this book a couple of years ago. That's only a hundred. There's more. Artists do this every few years. So they've been doing it for far longer than the software people. So it starts with Futurists. Here's one that caused a bit of an upset. I think we know which one this one is. Luther, yes. Martin Luther, 16th century, had a few issues with the Catholic church. So he wrote 95 of them up and nailed it to church doors, taking advantage of the new social networking phenomena that was printing. And 95 theses against the church. This clearly caused a bit of an issue. That one also caused a bit of an issue as well. Again, if you read through that, it's just like, okay, we know where you stand. It's very, very clear exactly what they're saying. There's no ambiguity. So I chose this one rather than my own personal copy. I do have copies of all these things because it's the same color as the previous thing. Do we have anything like this in software? Well, here's notes on Postmodern Program. My James and I have a Robert Biddle. 16 bits starting at zero, which I think is very clear too. And zero is manifesto. This is worth a read. For me, this is one of the most important.  We have a Postmodern architecture.  It's kind of a bit of a mashup. And who knows what we've got? We've got technical debt. No, it's Postmodern. Oh, okay, that's all right though. So although I take a very, I have a negative outlook on that. In many cases, this is one of the best papers ever written in software development, as far as I can say. And I also saw the live performance of it. Let me think, 2003 at UPSLA. Mary Poppendick went on after James Noble and Robert Biddle who basically did performance art for an hour. And I really felt sorry for Mary because she just stood up there and told us all kinds of really good stuff about lean. But it was a really different. Here's one. Structure like this. We have the left-hand side. We have the right-hand side. And this is very provocative, exciting language. People of Earth, the sky's open to the stars. Clouds roll over us night and day. Oceans rise and fall. We're getting a sense of scale here. Whatever you may have heard, this is our world, our place to be. Whatever you've been told, our flags fly free. Our heart goes on. Forever, people of Earth remember. Wow! Does anybody know the manifesto? It's the Clue Train Manifesto. It was published in the late 1990s. It was 95 theses, based on Luther, 95 theses against business as usual. It was the observations of how consumerism and the ability to buy stuff and also business-to-business interactions was fundamentally changing. Never has shopping online sounded so exciting. I mean, man, these guys took the whole idea, online commerce, and here it is. It's gonna be revolutionary. It's gonna change. And funnily enough, in the heart of this manifesto, in the heart of the published book version of this, there is also a lovely little paragraph that actually comes much closer to capturing the passions and ideals of technical people. People in high tech take pride in their work. There are individuals who see the details of the things they produce and the light of the trials and triumphs they experience while creating products. In the carriage of creation, they find a place to hang their individuality. Programmers and technotypes appreciate elegant spare code and the occasional well-turned architectural hack. It's a beautiful balance. It's exciting. It's passionate. It speaks far more strongly to me than say the craftsmanship manifesto in terms of craft. It does turn out, actually, that we look back, we go back to some of the original XP writings. This is from Ron Jeffries in 1997, 1998. This is before the Extreme Programming White Book came out. And there's a little bit of a change from some of the stuff that Kent says. But he describes simplicity, communication, testing and aggressiveness. Aggressiveness eventually becomes not fearlessness, but courage. There's a very different take on that. But also notice the style of this. This is actually quite a good manifesto. Simplicity, we strive always to do the simplest thing that could possibly work. We're quite serious about this. We have found that with the right architecture and correctly fact code, we can rapidly extend our software when the need arises. Use of the first person plural, collective. You can go through the whole thing and you can agree or disagree, but you know precisely where the XP folks stand. It's a very clear statement. Not simply of values, but of practices. It's just like, okay, and you can choose to agree or disagree, but you know where they stand. There's a no lack of ambiguity and this inspires some people and will repel others. But nonetheless, it's very clear. This is sometimes cited as a kind of key book in the founding of the modern software craftsmanship movement. I'm not so wild about it. I have to admit, Pete McBreen, he wrote this 2001 and I read it. And it's a good manifesto because I disagreed with most of what he said, but I knew precisely where he stood. He, for practical reasons, he caricatures the history of software engineering into something that I don't recognize as the history of software engineering and characterizes, in other words, he sets up sort of straw men to knock down, which kind of, I found a little bit annoying. But he does make a couple of good points. Craftsmanship has been used for centuries for the successful transmittal of skills and the development of communities of practice. He does make this point that there is this notion and this extends out to ideas of apprenticeship. Again, it is worth understanding that there are many professions that follow sort of an idea of an apprenticeship and a mentoring model. My father-in-law is a civil engineer. He does airport, he does airports, runways in particular. In the previous house that I was in, we have the only patio in Bristol that you could actually land a 747 on. I'm pretty sure it's that over-engineered because we got him to help us, and he's sitting there over-engineering and says, I'm sure it's just a patio, but he's sitting there thinking, oh, but why are the plane touches down? Yeah, but it's only a few square meters. He can't get a plane on this, but he can't help it. It's one of the most over-engineered. If the people who moved in after us wanted to get rid of it, they would struggle. They'd have to carpet bomb it to be able to get stuff out. So, there is this idea, but we have to be very careful. When we look at practices of the past centuries, we have to be very careful not to get caught up in certain caricatures. Crasponship movement of the past was based on the guild system. It was a near necessity. And we appreciate that. We have to be very careful not to take it literally. We have to take the lessons learned. Now, do we have a more useful approach to thinking about this stuff? Well, here is back to the Tank Clouds. This is a Tank Cloud created by Olaf Jonsson. It's about three years ago. It was on the software craftsmanship list, and what he asked people to do was to send him three words of what software craftsmanship meant to them. But not to do it on the list. Do it privately, otherwise you prime other people. And he collected this together. And it's really interesting what we end up with. Quality, professionalism, pride, passion, passion. There's passion. Kind of important if you're gonna get excited about something. It's if you wanna do something well, you need to get excited. Care, respect, experience, practice, professionalism, learning, all of these things. We see this going round and round. This is a very good representation. In many ways, it's almost a better representation than many of the other ways we might describe craftsmanship. It's a much better representative. So, an observation of mine, software development can only be considered immature because of how we use our experience, not because we lack it. We actually have, collectively, across all software developers, we know how to do this well. But it's a little bit like the William Gibson quote. William Gibson science fiction author who is basically credited with our current delight in putting words cyber in front of everything. He observes that the future is already here. It's just unevenly distributed. And that way of thinking about it tells us we know this stuff. We just have to try and get other people. How do we create and move that knowledge around? So I think it's time for another manifesto. This was around the time of service-oriented architecture manifesto. And I was running a patents money. I was at a company in Norway and we were basically mining their patents. We were running a fairly intensive workshop going through their systems and discovering their designs and documenting those in patent form. And I seem to remember my response when I sort of showed the, when I was showing this new seller manifesto, having sakes, patents clearly needs one. So pissed off, I went and wrote it out. Patents, we are uncovering better ways of developing software by seeing how others have already done it. That's it. We're done. This is the value. Cause it turns out that we haven't solved everything, but most projects, 90% of any project, wild generalization is standard stuff. You really don't want to get caught in the standard stuff. You want to do the interesting bit, it's different. You don't want to be bogged down in reinventing the wheel and figuring out, should it be blue, should it be red? Should it be round? No, round is an option. Yeah, the wheel's been done. We know the wheel. Let's move on. Let's spread this knowledge. This is an ethos of the patents community. It's not about the gang of four book. It's not about particular books. It's not about particular patents. It's very much this idea. And so, and this actually is the point. This is the very workshop itself. We had a lot of whiteboards available, which was great, because people, if you tell people to write a document, they kind of go into document writing mode and they produce rubbish. Because sadly, software developers are not taught to write. Here you are at a conference on agile development. It's about how we can develop software better. I presume next week you're going to a conference on how to write better, perhaps? No? No? No? Your company's not going to send you an effective writing course? Yeah. It's curious, because sometimes we do this. We sort of say, well, here's the stuff that really matters, and we're going to pay you for it. What's the stuff that really matters? We expect you to write lots. We expect you to present. Okay, and you're going to improve my skills how? We're not. We're just going to assume that you picked up everything you need to know at school. That turns out, I think I'm in my 40s. I think I can finally write, but I'll let you know in another five years' time. I think I've got to the point I can write, but I'm not entirely sure. The point here is that what we have is a lovely environment where people are just thinking, oh, I'm just writing on a whiteboard. I'm just writing on post-its. You de-formalize it. I actually did this with a friend a few years ago. I ran a user group, and I wanted an article, and he had a mental block about writing the article. So he described to me what he wanted to write. So that sounds great. Why don't you just email me what you just said? And I took the email, because you know one thing, software developers are great at writing emails. If you say write me an email, they'll send you thousands upon thousands of words. Let me just tell you about this text in the description. In fact, I'm in the middle of doing it at the moment. I'm writing some code to respond to somebody with an email. Now, have you said, Kevin, could you write some code and do a formal presentation on it, or something like that, or could you put it in a spec? My mindset would be different, but it's just for an email. We will write loads of stuff in an email. So I took what he wrote, turned it into an article. We have to find a way of bringing out that knowledge and getting that flow going. And this happens to be a really good way of doing it. So it turns out that this idea of craftsmanship is entirely understood. I'm gonna let Jason Gorman have the last word on this one. He's based in London. He runs a software craftsmanship conference in the UK. As I said, I'm a little wary sometimes of some of the metaphors used in the software craftsmanship community. I generally consider my area of interest is, I have a set of things I'm interested in. Some of the things I'd like to help people with. A set of things I think can be improved. And if that's what we're calling it this year, I'm all for it. And in five years time, whatever we're calling it, I'm all for that as well. As Jason notes, software craftsmanship is not the next big thing. It's the attempt to articulate what the thing always was. Thank you very much.


Hi, I'm Zor. Welcome to a new Zor education. Let's talk about inequalities. Well, this is an introduction to inequalities. Not too many problems will be solved. Just we will talk about what inequality is about. Well, let me just start with something relatively simple. X minus 5 greater than 0. This is an inequality. Let's just consider what actually we have written here. Well, on the left we have certain function. The argument is X. On the right we have certain constant. So, basically when we are talking about inequality, we are talking about some condition which we usually put on some function. It's a condition on a function that the value of this function are supposed to be, well, in this case, greater it might be actually less than or less than or equal or greater than equal. And some constant on the right. Well, first of all, let's think about what the function is. Function, as we know, is some kind of a rule which connects the elements of the domain with elements of core domain and somewhere inside the core domain we have range of all the values this particular function takes for all the different arguments from the domain. Now, core domain sometimes can be greater than the range. Sometimes it can be equal. For instance, function X square which is basically a function which converts let's say real argument to real value. Well, the real values, real numbers are domains and real numbers are the core domain. The range is, however, all the non-negative numbers. So it can be less, but it doesn't really matter. What does matter is that this particular constant A must be here. It can be either inside the range or it can be outside of the range. Again, X square we can consider this particular inequality when one belongs to the range or we can consider this particular inequality. One minus one actually doesn't belong to the range, but it still makes sense. So element A supposed to belong to the core domain that's fine. Now we are talking about the value of the function to be greater. In this case, it's greater, but again, you can always substitute any other inequality sign less than etc. So the value of the function f-attacks is supposed to be greater than the constant A which is an element of the core domain. Now, what does it actually mean? Well, it means that inside the core domain we have to have a relationship greater. So the core domain cannot be just some abstract set. It should be a set of ordered elements. So ordered means that forever to element I can always say which one is greater, which one is less. That's very, very important. And obvious example of this type of code domain is real numbers. Among real numbers we very easily establish, I mean it's already established basically, this order. We know which one is greater than which. So for two numbers from the set of real numbers, we can always say which one is greater. So if we will have a somewhere here, then we are interested in those values of the argument which are transformed into anything which is greater than a. So my direction of growth is this. So if this is a we are interested in those values from from the domain, which are reflected to this. So these are called solutions. So the values from the domain which satisfy this particular inequality are solutions to this inequality. And this is not a solution because it goes lower than a. So from the abstract standpoint, we are requiring that this particular set, the code domain, must be ordered. So for any two values from the code domain, we have to really find what exactly is the relationship between them, which one is greater than another. Now, how about the domain? Should domain be ordered? Well, not necessarily. And here, which is unusual, but that's actually true. Let's consider a completely different example of a function. Okay, the function is color, light, frequency. Now, you know that every color, red, blue, yellow has certain frequency of light expressed in some basically real number. Now, we can compare frequencies, but we cannot compare colors, which color is greater than another. But what we can have is, if I have a specific interval of frequencies, let's say we're talking about frequency from, I know, don't remember the frequencies of different colors, but from some value to some value, we are interested here. And it happens that red goes here. Red has a frequency which is in this interval. And let's say blue is outside of this. So what does it mean that if I want to solve the equation frequency of the light is supposed to be from this to this, then I can solve this equation by pointing to colors red and some other colors, which also have the frequency mapped into this particular interval and say these colors are solution to our inequality. And this color, blue, for instance, is not a solution. So I can basically from maybe finite, if you wish, set of different colors. I can always pick a subset which would correspond to an inequality, which I have basically conditioned on the frequency of this light. So the codomain must be ordered. Domain, not necessarily. However, in mathematics, usually these type of functions are not really considered. And what we do consider is obviously, usually, let's put it this way, the function of real argument, which has real values. And basically these are the functions we will that we will consider. Now, in this case, the expression, which is actually a solution to our inequality, also can be established in the terms of equal, not equal, greater, less than, etc. For instance, solution to something like this x square, let's say greater than 4. Solution to this are x less than minus 2 and x greater than 2. Because everything, which is less than minus 2, like minus 3, minus 4, etc. Being squared will give you correspondingly the value, which is greater than 4. And everything greater than 2, like 3, 4, etc. will also, being squared, will give you the value of greater than 4. So if this is an equality, this is the solution to this inequality. All right, so we understand what inequality is. It's a condition on some function which has values in a set, which is called codomain, where we can establish some kind of a condition, like greater than or less than, and some constant, which is an element of that codomain. That's the inequality. Now the solution to this inequality is a set of all x which, if applied the function f to them, will give the answer, which is greater than a. And the greater is established in the codomain, that's why we can't say. Now, obviously the relationship between greater than and less than, etc., are obvious. First of all, we all know what equal relationship is, right? So if we know the relationship, which is called greater than between two elements of the codomain, we can always establish all other equations, like what? For instance, less or equal is not greater. Less is not greater and not equal. What else we have? Greater or equal is greater or equal. So all possible relationships here, greater, less than equal, less and greater than equal, are defined using only one inequality sign. And obviously we also understand that the equality sign is also determined and is defined in any set. All right, so basically in my examples, I will use only one of those signs, like greater for instance. Everything else is basically assumed as a combination of some other logical conditions on this sign. So we have defined the inequality. We have defined a solution to this inequality. It's a set of such elements, which are greater than a. And all I would like to say is, well, basically the open question is how to solve equations. How to find these values of the argument, which would result in this particular condition on the value of the function. Well, there are different methods. And if you remember, if we were talking about equations, we had some transformations of the equations. We had invariant transformations, which do not actually change solutions. We had non-invarian transformations, which really had to be approached very carefully, because we might lose some solutions or we might gain some solutions. So we were talking about this. Well, similar approach can be basically used with with inequalities to solve inequalities. The only thing is, before doing this, which basically will be a subject of the next lecture, I would like to mention one other method, which is based on the graphics. And it's always related to a real function of real arguments, which is basically the most of the cases, which you will consider. So how can graphics be used to solve equations like this? And you know what, it's actually sometimes, whenever you can do it, it's really a good practice to do it. So you will see why. So let's consider a concrete example of the inequality, which I will solve using this graphics methodology. Inequality is x square minus 4x greater than minus 3. All right. Now, what we know is that this is a polynomial of the second degree, which has a graph of parabola. Now, let's think about what kind of parabola this is. Well, you remember that if you have roots of this parabola, so where the parabola is equal to 0 are the points where it intersects the x-axis, right? So if x is equal to this, y is equal to 0 and if x is equal to this, y is equal to 0. Now, looking at this, what are the roots of this? What are the solutions of the equation x square minus 4x equals to 0? Well, obviously x times x minus 4, right, is equal to 0. So one is x equals to 0, another is x equals to 4, right? So let me write, let me draw this particular parabola. So wipe out my example and draw a parabola, which is exactly corresponding to this one. So this is 4, this is 2, this is 1, this is 3 and my parabola in the middle point at 2 is equal to 2 times minus 2, which is minus 4, right? So it looks like this. It goes, now it's upwards, directed with its horns, as I call them, because the coefficient at x square is positive 1, in this case. So it goes up and the roots are 0 and 4, so that's why I draw it this way. So this is a parabola, which represents the function on the left. Now on the right, we have a constant minus 3 and we have to find those values of the argument, when the function would be greater than minus 3. Well, let's draw a line, y is equal to minus 3, which is here. Now, we see quite clearly that for x on this side, the parabola would be higher than minus 3 and x on this side would be higher than minus 3. Okay, what x are they? Well, I can basically draw this. Now, it looks like it's like 1 and 3. Well, let's do it exactly, not looks like, how to do it exactly. So my question is, when the parabola is exactly equal to minus 3? This is minus 3. So when the parabola is exactly equal to minus 3, at what x? Well, let's just solve the equation. x square minus 4x equals to minus 3 or x square minus 4x plus 3 equals to 0 and the solutions are x is equal to 1 and x is equal to 3. Product is 3, sum is 4 with minus sign equal to minus 4. So I'm just checking. And obviously, I chose the example with easy solutions. Right. So yes, exactly. It actually 1 and 3 exactly projecting down to these points of intersection between this line, y is equal to minus 3 and parabola. So what are the solutions to our inequality? It's all x's which are here and all x's which are here. So the solution is x less than 1 and x greater than 3. So these two areas are solutions to this particular inequality. Now, why did I choose to use the graphics in this particular introduction to inequalities? Because it actually helps you to see how exactly it looks like when something is greater or less than something else. Graphical representation always helps to feel better how this is all done. And yes, obviously, we can solve this particular inequality using certain methodology which will be presented in the next lecture, transformations of inequality. But still, even in that case, the graphics are sometimes utilized and very helpful. This is a simple case when all I have to do is draw initial graph of the function f of x, draw the graph of function y equals to this constant which is on the right, and basically graphically establish which areas are supposed to be the solution. And then another equation, now it's an equation which I have to solve would help to find exactly these two numbers one and three which are boundaries for these two areas. This is the right boundary for this area and this is the left boundary for this area of x. Well, that's it for introduction. As I was mentioning before, next lecture will be about transformations of the inequalities. And well, everything is, as you know, on Unisor.com and I do suggest you to register as a student, have somebody else as a supervisor or a parent maybe who will enroll you in certain classes that would allow you to go through exams and check yourself basically how you deal with all these issues. And that's it for today. Thank you very much.


We are repeating the module session, if you have any doubts you can ask, I am quickly going through. So, this is our module website, the site is www.it.itb.ac.in slash module. So, make sure before you are going to log in, the cookies should be enabled otherwise it will not allow to log in. The second is if somebody forgot the password, somebody forgot the password then you click on the lost password button, either you want to give your username, otherwise you want to give your email address, so I am giving an email address, then search, if you log into your email then you can see the module admin message, so you can see a message from module admin. So, this is only a confirmation message because anyone can try with your email address, so this is a confirmation message, once you click on this link then only module will generate automatically on user ID and password for you, that is temporary. Using that ID you can log in only once, so I am again clicking in this link, continue, if you go to your mailbox you can again see one more mail I receive, you can see the username with the temporary password, you can see that. Using this email, this password you can log in now, when you log in using that password immediately it will, you want to change that password otherwise you cannot, now I successfully change my password, now I can log into my courses, these are the courses why not. Somebody forgot the password then only you want to use this option, so one more option is there for the convenience of the remote center coordinator, we have already made one more link, so please note down the link because when you are going to your places you want to handle with 50 to 100 participant and above, so it is little bit difficult because that time may be the server is too busy then for getting the mail it will take some time. For avoiding that we are created one link that is also www.it.itb.ac.in-model-rm, so then it will come like this, if at least somebody forgot the username put their email address here and submit, it will immediately show the username, so it is very easy for you people to solve the issues, next one is how to download assignments, sorry how to download the pdf's and all the things, you can see the schedule and introduction to module, so if you go to introduction to module all the topics we are covered here is available with the screenshot, maybe it is very useful for you, second one is how to submit an assignment, so for submitting assignments we will create a link here assignment submission link, when you click on that link it will exploit, so click on the assignment submission link then you can submit the assignment, but the file size should be 1 MB, if it is built above 1 MB then module will not accept, then you will get an error y naught 2 something like that, so make sure the file size should be 1 MB, next one is attending the queues, the queues is available during the workshop, so the faculty will say today there is a queues up to 4 to 5 something, the link is open only on that time only, if you click on that link then that time you can attend, click on his then read the instructions carefully, saying queues 1 the time limit is 20 minute, total question is 10, maximum marks 20, total page is 5, means per page 2 question is appearing, when you start the queues you can see the counter is started here, it is 20 minutes that is why this counter is started here, now you can attend the queues, you can click anything and randomly attend, once you attend all the questions it will show like that, what are the questions you answered everything, if you want to submit you can submit, if you want to go back then click on this button, it will go to the question number 5, it will go to question number 5 then you can attend, second when everyone can see there is a flag, there is a flag, you are attend this queues you already answered, but still you have some doubt, then you can just press here, when you are completing that time it will show that question is flagged, if you want to remove that flag you can remove that type, so you can see question number 5 I have a flag, flag means you are already answered the, already answered the question, but still you have doubt is the answer is correct or not, then you want to cross check, so just flag that question, now I am only 10 questions, but during the work show maybe it is 30, 40 something like that, then quickly you want to go back now this is very easy, I am finishing, will again ask are you sure, you can see my grade, so in the main workshop when you are attending the queues, after submitting you can only see the marks, you can review that queues, means if you want to know what are the answers are correct, what are the answers are wrong, that is not possible during the queues, once the queues is finished, means the time duration, 4 to 5 means after 5 o'clock only you can review, so this is the way you want to attend the queues, I will show you the live queues, then forum, forum if you want to pose some questions in the forum, then go to forum, add new discussion topic, then you can add here, so please do not add same questions again and again. See one thing we find is participants start using the forum as a chat thing, just go there whatever you have put something in the discussion topic and start a new topic, that is not a good idea, what you should do is first you should review and read what others have asked and what is the reply and then go to the reply mode, why do not you go to the chat, sorry discussion forum, there is already some discussion going on, so there is something about your airport confusion, read what it said here and follow it up out there, do not ask another question about airport confusion or airport somewhere else, why do not you go to fluid mechanics, see in fluid dynamics main workshop, you will see that the coordinators have already put up part 1 BPP, any discussion on this topic should be posted here only, otherwise you know there will be one question on second coefficient of viscosity, after a few hours there will be another similar question on second coefficient of viscosity and the whole list just goes on increasing, this is supposed to be a tree structure, a hierarchical structure, so somebody has asked a question, a related question should be asked within that, so that in one single topic all the questions, related questions, answers, comments on answers, supplementary questions they are all found together, just follow that discipline, it is good for you and it is also good for the coordinators. Going yesterday we conducted, day before yesterday we conducted a quiz for this CFD, you can see that CFD main workshop it is already attended around 1170 participants, so you can see the graph, once the quiz is closed then you can review, review means it is come like this, you go then you can answer what is the correct answer, what is the wrong answer, everything you can see here, everything it is recording, when you are pressed with a button, everything it is recording, yes, not all the coordinates in your sender, then you want to select it from here, if I am a coordinator of Amal Jyoti, you just select it from here, we will get only the Amal Jyoti, it is recommended that after you go back, log on to Moodle, two important things, at a personal level even from your home, log on to Moodle and be comfortable with the discussion forum and other stuff in the Moodle, particularly the new coordinators. And second thing is, take the A-view connection seriously, Sajjan Dixit will send you a timetable, strictly follow that timetable and do keep in touch with him, because that is the lifeline, if A-view connection or internet connection does not work, it is as good as not having the workshop at your sender.


Everybody forced here being 2023 pristine baseball four box number six random teams find their results on your screen any time I'll eat in sports cards.com. We'll go ahead and get started now Shane, I don't have a guess. They're just gonna have to tell us what you asked him Did you get in the sign your track list?  I think you get like cards and stuff too or something I don't even know me to get a lot you asked him if he could he could uh If you wished you could have faced or any Johnson or if he was glad he didn't have to I Could see but I could see I like them either way. Maybe he's competitive enough to want to do it Maybe he's smart enough to know that He'd be made a fool of all right trout refractor in a gold Kyle Schwerber going to the Phillies here and L It's out of 50 God Harper. Oh snap Phillies a Kunya refractor with a gold jersey auto each euro Oh Goodness gracious the hot case continues 43 a 50 for Seattle one in a mag for you. That's a gorgeous card Paraza fresh faces That's a good answer. I'm sure JR is pretty well-spoken. He's been a top prospect for Was a top prospect for like three years and he's rookie of the year. So they will sound those tricky refractor pirates purple bednar pirates out of 99 Thank you for the goat and thumbnail. Yeah, Steve Smith. It's pretty awesome. Yeah, Jake Oh, sorry, who is Jake born in 03? No, that can't be right. He turned 21 this year Luis Robert refractor he likes number three because of uh, eva Longoria If you get an eva Longoria, I think Blue refractor is 75 willy mage giants Corbin Carroll base Have you seen Kyle schtick on the the Corbin Carroll? So he's holding the side of his helmet and it looks like he's talking on the phone. Kyle will go. Hello Hello, I know dude, it's I have to I have to scream into my pillow every time I every time I see someone say that red baby rickie refractor mets Am I right Jake? That's what I I was like, why would Jake put three? Hmm? All right encased cards here Out of a oh snap auto gold Oh snap Earned out of 50 for the astros Got a Rivera refractor Trevino blue refractor to 75 Yankees rookie auto jeter downs for the nationals Judge refractor angels and a josh nailer to 75 for the guardians Jake did you play a new season of fortnight yet? Sean and I played like a handful of games earlier. It's uh Very different It's pretty funny though Fractor of j rod mariners or inch of 25 Carlton Phillies Oh snap Julio Rodriguez All right, I'm just gonna pull these cards out and set that down Alejandro Kirk refractor with a game used jersey auto for the Brewers freddy perelda around the diamond I'll have to play with Jake tomorrow night and see how see how he does Gold rookie josh win kowski redsox It's number 20 of 50 All you got to know a new season though is get that get the the ramp the ramp Or what is it called rocket ramp ramp rocket or something? I don't know what it is, dude, but you got to get it It's it's chaotic, but Yeah, do the turrets got alvarez God to carry the turrets set it up somewhere. No one knows it's there especially endgame stuff. Yeah, that's what I'm saying I'm gonna couple rows pinned up two places Let's go alvarez going going going on for the Mets. Give you some cover man These blue refractor wilson contraris is 75 I believe that goes cardinals because it's The all the last year all-star. I'm gonna check the checklist on this one I'm gonna drop a link for I guess whatever I guess primarily choice would be the one Where's the cardboard connection one? Uh wilson contraris He is what card number is this? Card number 284 Is okay cubs. Yep, it'll go cubs On that one tag that cubs He does have cardinals and cubs, but since that one's and also our last year to be cubs guard Also on the checklist. That's how we look. We look some of those up if we need to alvarez base Change up a day fresh faces Is that what you got in the that's what you got in the swag bag? That's awesome, man Xander rookie refractor markapel Kyle you're gonna be awake for the uh for the Bournemouth match in the morning 7 30 a.m. Start time. No, he ain't gonna be awake at 7 30 He breaks in the morning. So he probably should be awake that early. Yeah He starts at 10. So 7 30 is probably the The right time to wake up there. Luis robert.  Yeah Yo white socks to grom pager martinez is 75 blue refractor red socks Christopher morrell fresh faces rookie auto cubs Encarnacion rookie refractor and a good yell gold to 50 for the astros Boxing museum sever silver transcended VIP packs on all with all one-on-ones. Yeah, it sounds about right, man The same in uh in fortnight It's the same layout. Yeah, but there's like three locations that are just totally different I don't think it's a bad change I don't think it's a bad change. It's just a change We all got it would just that rocker am is gonna I'm like all like half weapons are silenced. Yeah, it's just kind of interesting I My uh, my next appointment is in like a month. Yeah, October October 3rd my next appointment Gotta go to Worcester, dude Harper refractor rookie DL hall refractor to 75 orials the blue refractor there Through the years 50 card flight agent yourself. That's kind of cool. Shane. Dan. You got a lot of stuff Raphael Devers with a game use bat relic auto scott rolling cardinals One of the newest members of the hall of fame We'll just have rich fly carl down and we'll all get tattoos here It'll give we'll give we'll give Carl some product and guest breaker purple rookie pasquantino Out of 99 on top of paying him obviously, but But since he's coral, you know Blue refractor going going on albert poohol's that's out of 75 with the cardinals You stayed in my house Raider at Sean's place Fractor david er giants rookie I'm gonna go to transcend and the ip party now. I do too barter system Ink for cardboard the clan of handy got purple rookie tow bar. Here we go. Rockies Cool color match to 99 Yeah, I gotta get that guy to boss in tova Von grissom fresh faces Where are you? Where are you gonna? What are you gonna tailgate? Where are you tailgating at? How many Bournemouth fans are in Orlando? I think it might be just us too, Kyle I've been wondering that for so long now That's been on my mind for so long Sean someone send him help Have the oh snap rookie Orioles. He needs it Where's jk? He also needs it. Yeah, there's no help Rookie refractor auto james outman Dodgers nice hit Dodgers 99 of 99 bookends By as pink refractor mets david right to 15 13 of 15 with a rookie autopadres matthew batten Nolan ryan refractor and a gold rookie jeter downs to 50 nationals 530 the tailgate Bournemouth. Oh my god Guys been a fan for two weeks now. He's just ridiculous. He's crazy. He's rabid Last box of the break All we have is a little bit of basketball some soccer and some football tonight guys baseball is all sold out Flawless basketball is sold out Um divisions nt is almost full. There's a maccovey refractor gold. D. L. Hall rookie to 50 baltimore Gunner Henderson rookie base. You got a kunya. Oh snap at lana called gold schmitz Bat relic rookie auto corbin carol diamond backs Big hit Super happy for you zona So fun. Congrats diamond backs. We'll get that one mag. That's awesome This case was really good overall the last four boxes and this four boxes Blue refractor going going gone hammer in hank air and 75 58 of 75 and a griffy as well What a mat pull Got k-line purple and pasco mattino to 99 rookie royals Bonneting the patriots hang 50 on the uh Were they playing the night doesn't matter kodaisenka Fresh faces To the pats would hang 50 on the 85 bears tonight Going down preseason week three biggest week of the year so far Biggest week of the year so far Swings of summer short print wan soto padres About a case hit on these i think I think it's a little under a case hit so kind of like a case hit But nice one padres got clemente purple rookie ohape angel said 99 Plans to titan's titan's defense is solid So hopefully it's a decent test for the offense Not gonna test the defense much though. You got jordan walker base uh rama sramirez and rookie refractor buddy kennedy diamond backs And a bret baby fresh faces He pulled the same thing as i did gameron rookie auto blue refractor francisco alvarez Metz color match now nine of 75 Geez man.  Thanks y'all moving on to some more pristine