Mae'r ddweud hynny yn ddechrau ein mynd i'r ffordd yma, os nid yw'r ddweud yn gwneud. Mae'r ddweud yn ddweud ar y Ffartfysgol. Rwy'n gofio eich bod yn ddweud o'r ddweud o adeil y ffartfysgol yn ddweud. Rwy'n ddweud o ddweud o'r ddweud o'r ddweud o adeil y ffartfysgol. Mae'n gwybod i'n rhan i ddim yn y ddweud o ddweud o adeil y ffartfysgol, Een number of different stages and that's what we gonna do today. What we're going to asked you to do. Is to be involved in this in some way of. So we're being to try and treat you like a product owner. Now normally in the week feiful we'd hope to have together one product owner. Logusly we've got quite a few there today. I think that's gonna make it a bit difficult. The first thing say, is we probably won't be able to get through all that stuff. First thing we need you to do is we need you to prioritise those things, so the things that you're most interested in hearing about first of those things we'll do first, we'll get time, we'll do everything and if we don't then there will be some things that we miss out. So there's two things that I need you to do, first of all I need you to come up and express your interest in these topics, we'll just say a sentence about each one so you know what they are. I also need you to take one each of these cards which we use for voting and also for feedback, so I'll just talk through what these are about and then I need everybody to come up and vote. The way that we'll vote is take a sharpie and put a dot on a card if you want. You get three dots each, you can use them as you wish, so you can put all three dots on one thing if that's the anything you're interested in or you can spread them about and then we'll do the things that people are most interested in first. I'll just say what these things are, so these are the things we'll get to talk about, there are ones and two so two talks are slightly longer than one talks, so in terms of the topics that I'm going to talk about, the cardboard which is basically how this system here works, incremental design which is about how we then try and design everything before we start on a project, test food and development which is our approach to writing tests before we start writing code. The burn-up chart which is the thing that you see over there which we shall be using, track our progress, also about testing, in particular automated testing, how you organise automated testing, why you do things in that way, why you need to do the idea and a little bit of that air programming. The first one, HTML, CSS and JavaScript is about some best practice for that. Feedback loops and everything is about incorporating feedback into agile processes. Web design is about aesthetics of height and usability. Protociting is a quick and inexpensive way of getting feedback from people whether you're building the right thing and user stories are a way that we break down development into smaller tasks that can be given to different people in a team and having us a motivation at work because I'm a big believer in it and so that's going to be talking about some of the frameworks for building a big culture. Okay, so we need you to vote now and we need you to do it fairly quickly, otherwise we're not going to get through the rest of the talks. So I need everybody to come up and start with Sharpie, you've got three dots and on your way back if you could grab on each of these cards. And we need you to do it now and pass your Sharpie on to someone else because we've got eight of them. Three dots each, then pass it on to someone else because they read them however you like to have the cards. You've got three on one or one on each. And we like the Sharpie package yet as well. We're going to see about 12 minutes and we'll get it in at the end of the break. It's going to do the test. It's going to do the test. So it's just approximately looking at the dots that we have to talk about these two things in the first iteration. So we estimate that we get through about 16 points, so four iterations of that four points. So we've got to talk about these two things to begin with and then we'll call the most important things through so we can get started with that. So HTML, CSS and JavaScript, is everyone familiar with them? Is everyone using them? There's a quick show of hands like if you're using. So I'm not going to talk about the structure of HTML, CSS and JavaScript, like show you loads of code or anything like that. I'm just going to talk about ways that you might want to separate them out into different areas and things like that. So HTML is about your content and giving semantics to your content. So the important thing to remember is that HTML is a way of taking images, text and giving it semantics. For example, if you put a strong tag around a piece of text, then it means that that thing is more important. So the same way like emphasis is to emphasise a piece of text. So by wrapping it in something like that, you give more meaning to that thing. So for example a screen reader would be able to tell that a piece of text with emphasis is of more interest and therefore it would speak it louder perhaps. Presentation, the CSS is for the structure of the page. So you wouldn't want to try and insert your CSS into the HTML of the page. You want to include it in as a file from outside. The reason you want to do that is because if you put it all into one big mess, then it's going to get really difficult to maintain. And JavaScript, you should split all your behaviour into the JavaScript area of your code. So in separate files, which you include again, because if you don't do that, then you'll have a lot of mungs again all in one HTML file giant thing. So what I'm talking about is separation of concerns. Some people write HTML and they'll put style tags into it and they'll kind of write stuff like the font size in the actual HTML itself. And that's going to cause you a lot of problems when it comes to maintaining your code because you can't see where the things that are related to presentation are and where the things that are related to the meaning, the semantics of your pages. Mixing them together is not a good idea. It's going to cause you lots of long-term problems. It might seem like a short-term thing that you can do, but it's going to be very difficult in the long term. Other ways that your content might be consumed might be consumed by mobile browsers. So if you've separated out your CSS into a separate file, you can serve a separate file for mobile devices, which adjusts to the form factor of it, for example. Or you can serve a separate file for print styles so that when people print, they don't end up getting too much colour information, for example, maybe, or whatever it happens to you. So you can do a nice layout for different formats. In terms of semantics, HTML5 now offers you a bit more control than HTML4 over semantics. You can mark up your content in a much more semantic way, which means that search engines are going to rank it higher. They'll be able to provide more information of things like browser plugins, for example. There's a browser plugin called Readability, for example, which gives you a little button in your browser and you click on it, and it will strip out all the extra content, extra stuff like adverts and images and stuff, and allow you to focus on a kind of article style when reading the content. So, if you mark up your content in a nice structured way with the new HTML5 elements where they make sense, then that will really help people out when they browse through all the content in different ways. Not everyone uses the same browser that you use. Okay, I've already said that. So, I think I've covered a lot of this. So, some more benefits of structuring your code into separate files for front-end code, like the CSS in one file, the JavaScript in other files, and your HTML in separate files again. You're really separating out so you can modularise it and you can look at the particular parts that you're interested in at the time and not have to deal with a lot of content all at once. So, it also allows you to do progressive enhancement, which means that you can layer on, so you can have HTML at the base layer, an Australian example of this at the end, CSS layered on top of that and JavaScript layered on top of it further. So, if you turn one of those technologies off, the page still falls back to other content which can be consumed on a BlackBerry, for example, an old BlackBerry that doesn't have JavaScript in the browser. So, it talks about cross-browser support, mobile device support. It also makes your pages load faster and helps with search optimisation. Make sure that you check that browsers are supported before you start using new technologies like CSS3, CSS4 will be coming eventually when they're started on the specification, and HTML5 technologies aren't supported by all browsers, so use a new response solution. Okay, questions? You've done the silence? You mentioned something about points, what was that? Sorry, you said you have 16 points. Okay, so we've estimated these stories in terms of points, which is an abstract measure of how big things are. As we go through the talks, we'll see how many points we can actually cover in iteration, and we will chart that on the graph, and this will give us a good idea about how much stuff here we can get through in iteration. Okay, we'll see that grow as the iterations. That's about 10 minutes in iteration. Okay, so just a very, very quick QA. We'll thank you to give us some feedback. So, you have three cards. If you like something, hold up the blue card, if you don't, hold up the red card. So, just in terms of this, can you just vote on this presentation, and then I think we'll finish on this presentation. So, blue or red, please just hold up the card. Okay, so done in production. We can chart those points, I think, or we can do it in iteration. Okay, so just by some miracle, it comes to be the first in the slide deck. What is test driven development? Test driven development is the practice of writing your tests. Your tests are written in code using the unit testing framework. Is there any people familiar with the unit testing framework? Yeah, like Daniel. Yeah, like James. Exactly. Okay, so it's the practice of writing your J unit test, or whatever, X unit test before you actually write the code. Why do we do this? Well, primarily because the test allows us to capture intent. It allows us to say, this is what I expect the code to do. If you program a lot, what you find is that you spend more time reading other people's code than you do actually writing new code. One of the hardest things is to understand why somebody did what they did. You can look at the code and you can see what the code is doing, but you never understand why they did it. So the thing about the test is this says, I want this piece of code to do this. It provides a neat way. We usually write a piece of code and we have some requirements. It's a neat way of expressing those requirements and moving from the requirements into code. One of the great things about test-trim development is it stops you from doing stuff that you don't need to do. Everybody across this? Yeah. Agile kind of homily. You ain't going to need it. So one of the things that people do a lot is they develop stuff because they think they're going to need it in the future, and you don't. Okay, that is the end of the iteration. I will carry on with this talk in the next iteration, but we should just do the stuff that we need to do at the end of the iteration. So we've got, we've completed two points in the iteration. Quite often we do some other things around the iteration about thinking about what we need for the next iteration and maybe having a chat with the product owners about what the most important thing is to do now. So we keep a track of how much we've actually managed to achieve in the iteration and we see whether we're actually going to look at our scope line at the top, the red line at the end of the talk, which I think at the moment is not looking good. Okay, so I'm going to keep this presentation in play, and I think we're probably going to pull through one more thing into the next iteration. If we do well, we can pull something else into the iteration. Okay, that was quick. I'm very scared. All right, so yes, Test Room Development. It's a way of guiding how you develop software. The other great thing about Test Room Development is that you are writing tests as you are developing software, and these tests are amenable to automation. So you've been a test that you write in a testing framework. You can also run automatically from your continuous integration server. So one of the things that you're doing is you're building up a whole suite of tests which you can run against your software. And the great thing about that is when later on you're going to change something, you can run all of the tests inside whether you're doing something or not. So one of the real values of the Test Room Development is you get this version suite. You don't have to go away, and there's a separate activity, write regression tests. That's one of the things that you do during Test Room Development. Okay? It's a very simple activity. So what you do is you write the test that fails to start off with. Because we're writing the test first, there's no working software. So we write the test. If you're writing in a compiled environment, you need to write enough so that the software will compile, otherwise you can't run the test. But you just do enough so you write against an empty method that doesn't work for instance. So you write the test that fails, then you make it pass any possible way you can. Don't worry about trying to do things in the most elegant way. You just get the test to work. Try and do the simplest thing just to get the test to work because that's what you want the software to do. And then once you've got the test green, you have a look at where you are. So what you do is you have a look at a piece of software you're working on, try and think about, has it got any duplication in there? Is there a more elegant way I can do this? So you write those changes and make sure that we're running the test again, but we haven't written anything. So the rhythm, red, green, refactor. So red, test fails, green, the test pass. We need to think about what's taking the codes in. Move things around, extract methods, create other objects that still keep the test passing. So you define the test before you start the code. I'm delighted to catch and take new requirements and build up regression tests.  Questions? Yeah. How do you test user interface before you design it? How do you test user interface with a test first approach? Well, you can do a certain amount of TDD with user interfaces in terms of checking that the right things are on the screen. So you can use tools like Selenium, for example, which checks, you can ask it to check, oh, is this headline present, or can I click through this button and this other page loads or stuff like that. But you can't, at the moment, there's not really a very easy way of testing CSS. Like a presentation information. You can also do your testing JavaScript as well. So that was the answer. So you could, I mean, I have worked in situations where you start from the very top for behaviour-driven development, and you look at the user requirements and you express those in a functional test, which requires some things on the work page. That obviously doesn't happen. When you go down to your test level, as in it says, there's nothing about layout, CSS. Okay, so any questions? So in this process, you don't use the main modeling tool, but you go straight from English to violence to code. We use the stories that express a small amount of business functionality. Am I doing a project? Or am I doing a project? Yeah, some projects are very large. A large is very large. A train? The largest one is Payline, which is something I like for 200 years. That's another typical project. A typical project is six to 12 months, maybe between six and 20 years. We do tend to favour smaller teams for agile development, because generally tend to find as the team gets larger, it becomes very, very difficult to communicate with everybody. Perhaps that's why documentation becomes such a big thing in large projects, but generally a smaller team can work much faster than a larger team because of sharing.org knowledge. I mean, we'll talk a little bit about what we've done to incremental design with the sort of approach to building up the system. But do you think that sometimes it's just a waste of time? Because if I know, my code works. Never. Well, sometimes, but if you are planning on maintaining your code in the long run with a team, then no, you shouldn't ever forego your testing. Okay, that's not my spirit. There's some things that I wouldn't test. The presence of a particular string on page, it's very, very straightforward. Some things I wouldn't test. One thing is that I wouldn't necessarily put all of the tests that I developed into CI. So you help the test to help you develop, but you need to be more careful about managing your automated test suite because over time, the automated test suite just grows and grows. So you need to be a bit more certain. That's the point that was awesome. For example, the presentation I just gave was written in code. I didn't write tests for it because it was one-off. I'm not going to maintain that. I'm going to throw it away. The thing is that I had the course of the job in the first semester. I wrote an application, and after that, Victor said to me, you should write tests. I just wrote a test for the application just to say, yes, I wrote the test. If you've written the app, well, it depends what you're doing with the app. It's much harder to retrofit the tests. What we do is we use the test so the testing is not an additional effort after you've got work with software. In that situation, actually, I would say that you're not in a very good place because when you come back to that software and it's time you need to change it, then how do you know you haven't broken it? The answer is well, I'd have to do loads of manual testing or I'm going to have to write some automated tests at that point. I'm not being able to understand the software very well. So, try not to get into that situation. Are there questions? Yeah, compared to traditional workforce model, how does it cost and the development time for this test to one development? That's such a... We're very biased. That's a huge question. I've experienced a lot of projects where we're helping clients to transition to an agile model and that's because they've had multiple failures of projects in the past. So they want a new style of working that actually delivers software. But I'm very biased. There's such a different set of activities. It's very hard to compare how this will compare to that. What I would say is that we have a lot of experience with agile projects and we're able to deliver software successfully. I think maybe we deliver less software but we try very hard to deliver the software. What do you really project the benefit in our return of investment? If it is more, the cost is more. Giving you more of what you want giving you much better quality doing stuff on time because we flex the amount of stuff we do depending on how much we're getting to them. We can actually say yes, but you won't necessarily deliver anything that you ask for. I can tell you now you're not going to get all this. Some expectations. So we just need to QA this. So red and green cards please. That is the end of iteration 2. So we can see a pattern emerging here. We have five minutes now to review what's happening. So we were hoping to get four points of iteration. Actually what we're getting is two. So we can see here's our project deadline. We're not going to make it. This is quite often the point of projects where everything is that. What we need to do is we need to cut our clock. Obviously this is a talk. It's quite like some projects. There's a hard deadline. You have choices. So we could extend the talk for another hour. We'd have a good chance of making quite a lot of material. Or we need to reduce the scope to the point where we think we're going to actually finish. Or we can do low quality and just rush everything and then you'll get no learning out. So I suggest that we reduce the scope to eight points. And then hopefully we'll get somewhere near. We might do a little bit better than that. So at this point obviously that's a very difficult conversation to have with you, the product owners. Because you're not going to actually. Yes, sorry. I started removing things. I started removing things which you put the low priority earlier. So what I am going to do obviously it takes time to do prioritisation and with such a big group it's going to take a very long time. So we're going to have to pick a select group of people just to re-prioritise the stories that we have so that we make sure that we get them in the right order. So I'm going to pick these eight people here. Your responsibility. Same thing again. Three dots. We need to do it really quickly because we don't have any time. Put your three dots on the blue stickers or do things in that order. You need to come up now. Sorry. I should say this point that usually what we consider once the story is in play that's it. It will go through the pipeline. We don't usually put stories out of play because it's wasted that way. Unless we really know that this story is in play. So once it's in play it goes through. If you need to chase up or introduce another story that changes whatever we're doing. I haven't really started this one but if I got halfway through then it would be probably a waste to take it out. That's Smashy. Thank you very much. Okay. So so we'll get to this. So I'm going to talk a little bit about the ways we tormented people in the 90s with web design and then see if we can go a little bit further beyond that. Flashy animations, confusing pages, all this kind of thing. Where am I?  There's so much stuff in my face. AdWords everywhere. It's not very aesthetic. And you don't know where you should go first. So people scan on the web. They don't read everything. They don't dogmatically read the whole page from start to finish. So they need to be able to scan and see the important things very quickly and prioritise where they're going to click next. And that's really important. And we didn't used to do that in the 90s. We just make things really ugly basically. I think we're just going for a period where people haven't really figured out aesthetic designs yet. We do things like this. How do you use this button? It is actually a sign up button but it's not really styled to look like a button.  When you click on it, it should compress the light effects on it, it should change a little bit. One of this stuff comes really easily now with CSX. We'd also make things really small. Tiny little buttons that you can't click on. You just have to go around with your trap pad maybe trying to find the thing. So, yeah, that's a painful thing to do as well. And weird things happen. You get pop-ups all over the place. And the content inside perform, you know, doesn't seem to make sense as marketing materials. Maybe the labels for the fields don't actually relate to the fields that they're positioned or over the place not in the right place for the field itself. What's that stuff we don't even use from? What's that label connected to? For my first one it was connected to this but if you put it in the wrong place it's really confusing. Just make everything blend into one thing, doing on from that.  We want contrast in our designs to make things interesting. We want repetition of elements so that we tie the whole design together. We want alignment of everything so that you can see, okay, this thing is aligned with that thing so it's probably related to that thing. And also positioning of those things as well. So, yeah, contrast is really, really important in design. If you don't make the things which are important stand out from the kind of general information and people are going to find it really difficult to get stuck into the content of your pages. If you repeat things, like say you get a and use beautiful typography to really make a difference to the way your pages feel, there's just some attributions or open source resources I use. So, do you have reviews in your meta-process sort of review by the way somebody? Yeah, I mean, it's the responsibility of the entire team to build a good product. So, it's not down to say developers develop something, they know it's a bit crap, but they just chuck it over the wall to the QAs and the QAs to go, oh no guys, that looks really ugly. I mean, that might happen by mistake, but like, you would hope that, you know, the whole team takes responsibility for trying to make a nice product. We also have experts on design experience designers and we'll have people on the team who have that knowledge and we try and encourage everyone to be poly-skilled to learn a little bit about design, a little bit about accessibility, a little bit about, you know, coding, so that people can switch and also understand the mindset of building a great product from lots of different perspectives. I have a question actually, but what's the typefaces on the map? Well, there's... I mean, native support typefaces has been a real issue for a long time. It's getting a lot better at the moment because there's things like tools which will progressively enhance the page with JavaScript, for example, to give better type, or things like Typekit, which, you know, and Google hosts a load of type web fonts which will be downloaded in the background onto your machine in order to use them in the web page because the problem is in the past we've been restricted to just the typefaces which were available on your operating system and the different operating systems or different devices like phones, there might not be the same number of typefaces available so you're not falling back to a really ugly one. How do you understand what's different in the Agile team? For example, there is a web designer that does web design and programmers or everybody that should be able to do it. Yeah, I mean, teams, the whole point of Agile is that you adjust the process to what works for you but in general what I think works well is when people have sort of shallow but broad knowledge in a lot of different areas so they know a little about design as well as coding and then perhaps you have some individuals on the team who have deep expert knowledge in particular areas and they can be drawn on asked questions of at the appropriate time brings me back to why it's good to have small teams so you can communicate, you know who the expert on that thing is and you can get quick feedback from them on whether you've built the right thing. Okay, QA Can you use to the drill? Can't you please? Design. Do you want to just grab yourself some seeds there? This is the pieces on the white one. Okay, so how do you design how do you design the web application? All right, let's just imagine the architecture is to be there. You've got a blank sheet of paper so let's say oh, we're going to need a web server and this is a dynamic application so we're going to need a database I think it's going to be a big website so we're probably going to need a web farm we're going to need some we're going to need some front-side caching oh, we've got this web server that we need to communicate with so we're going to need some kind of a web service framework we've got this other corporate story over here that we want to communicate with well, we seem to be having a few things so I think probably we need to introduce a great big enterprise service bus we can connect all these things together and this is fantastic because already we've got a very complicated diagram brilliant we've got months of work there to go away and investigate all of these different things which technologies we want to we want to choose for each one of these things compare them, go ahead and have these great sort of whatever they're called from they're called so the big tendering process what suppliers come to present to us and say we think we should buy our enterprise service bus from and soon you know oh, that's end of iteration okay, so how did we do that time another two points okay, so one of the things one of the interesting things that you find with agile projects is after a while you'll find that the velocity stabilizes so you will get a more or less as long as there's no major sort of roadblocks you'll get a more or less constant thing so I think we know where we're going with this one now okay so this thing it can easily be six months before we start writing a line because we've got all of this stuff that we need to be to relax and to brush so we would say writing by application okay and that's fine and usually the clients will have particularly you know they'll be a dotnet shop or they'll be a minute space shop or probably they'll be something like the next thing so there'll be this may be a conversation but quite often it's fixed by the context all of our servers are Linux so we need to understand and that's fine and maybe you have a conversation about programming language so you might be going to Java or I guess if you're really familiar to you might be writing in Scala or I know not so much in this country but in the States so you have that conversation and then we would get going okay so we have some requirements we can start building the software okay so when you pull in the stories and typically the stories at the beginning of the project are very simple you know we just need to get a web page up and running you know we want to do this we need to do that and gradually build our software okay and there will come points at which during this development that we start so for instance there will be a point probably fairly young where we go oh okay we need to assist some data so now at this point here we need to introduce the data store and again that's a conversation but probably there may be corporate standards about that they may be open to doing something a bit more interesting of activity and interest around those secret databases that's another conversation and so you introduce each piece of technology at the point that we need it and the point about that is that there's a number of ways one is this thing again a lot of this stuff you just do not need it doesn't help you get the way you want to go in a way, thanks forever it means that you need 47 more boxes to host all this stuff on and at the end of the day it does you absolutely no good whatsoever so if you drive out the architecture from the requirements as they come in sometimes as we've seen requirements never make it so you have this big requirement to do something to access the corporate data store but actually as you go on the project they're going oh it's not that important we'll leave it for a minute it's not that important and at the end of the project you've never done the integration in terms of what they actually want you from the website they never needed it so you could have stood up all of this architecture to integrate with this thing that actually at the end of the project you discovered that you didn't need so you need to so incremental design is all about pulling stuff in now that sounds very simple doesn't it? yes? no it's really hard it's really hard because it's really hard not to fact yourself into the corner to go down a blind alley where the next thing that you need to do suddenly becomes really really hard so you go so far everything's going swimming you're producing loads of stuff and then suddenly we need to do this thing and the entire architecture of the system doesn't allow it and we fact ourselves into the corner so really this is about experience and I'm not the best person to talk about experience because I'm not one of the most senior people I've thought of the really senior technical people have the experience to understand so there's a couple of things that you need to know you need to know approximately where you're going alright? it's a very hard balance between we know we've got these things coming up we know what the biggest shape of the project is so we're not going to go down an alley where we can see that the things coming up in the project are going to stuff us but we don't want to introduce anything into the actual architecture so we need it there's an agile phrase for everything there's this agile phrase which you can look up on the way of them and stuff about it called the last responsible moment so that is you make your decision at the last responsible moment that is the point at which if you don't make the decision you're going to get trouble so we try and put stuff off as long as possible but at some point you'll say the web service framework we absolutely know that we need it if we carry on without it it's going to cost us in the long term and that is obviously a judgment call when is the last responsible moment deciding on the web service programming language the last responsible moment is the point at which to begin the project because you can't begin the project without it making the judgments further on down the project is really quite hard so you need to know where you're going and you need to make the decisions at the last responsible moment and the great thing is that if you can do it then what you end up with is the simplest architecture that will satisfy the requirements you don't end up with all of this stuff that you didn't actually need and what you find in a lot of ThoughtWorks projects isn't enough I think is that there's a couple of things that happen one is there's a lot less stuff you have the stuff that you need and you don't have all of this other stuff and the other thing is that there's a strong preference towards certain sorts of technology the kind of technology that don't tie you down, restrict you restrict the ways that you can flex things in the future so there's a real strong bias because we're always thinking about things change we can't necessarily predict how they're going to change there's a very strong bias towards developing the software and using components that we can flex that are flexible that we can use to fit a number of possible things that are going to happen in the future because even if you have a roadmap you won't necessarily be able to anticipate everything that's coming up and that change happens we try and accommodate change as much as possible except when it's a factor why but if big change can there are certain levels of change which you cannot accommodate we didn't see it coming it's a huge change there's nothing we can do about it or the other thing the other thing that you absolutely must have is one of the things that we're very, very, very keen on the automated regression suite test different development test the different levels we'll maybe get on to talking about it maybe we won't, get on to talking about testing the different levels but the great thing about having one of these is that you can flex the system and know that you haven't screwed it up that you can change things you can change things quite significantly under the hood introduce a big new piece of architecture if you've got a good automated regression suite that will tell you whether you screwed it up questions can you be able to measure the quality of the code? the quality, yes you have to be careful there's things like there's loads of them so the code metrics there's some basic stuff but yes in a lot of, in a mature language there will be stuff to measure the quality of your code you can also measure your code coverage they're quite interesting stats but you have to learn not to rely on them because there's much more to quality than the things that you can measure automatically the thing about measuring stuff is if you measure if you measure something quite the right measurement then you end up performing to a metric which ties you down to doing something say you measure the number of lines of code that people write you're going to get weird behaviours because people will start introducing lines of code which actually do nothing or are unnecessary so you'll have an unmaintainable test suite because you're measuring the number of lines of code a great example is the NHS they keep measuring the government has the number of measures about the NHS you measure the NHS in a certain way like waiting lists and then everything is focused towards reducing waiting lists the fact that that may not actually give you the best quality healthcare service is lost in the fact that you're measuring something and everybody's looking at the figures we get the same thing all the time you have measures from infield sorry you have measures from infield you mean production metrics we do use a lot of that kind of thing analytics is obviously an easy way of introducing that kind of thing but there's a lot of stuff you can do around metrics in production to learn especially things like A, B testing learning from your users what they do I've seen the sales funnel on sales forms where you work out based on metrics infield has a 50% drop-out rate we really need to improve the usability of filling in this field otherwise we'll lose all our customers that's why I've gone on and said all the delay is not going to happen I didn't say delay we're done now okay um we didn't hope QA QA so we didn't do what we said we'd do but we did we were able to track our progress and make a reasonable guess at the first of the midway point as to how much we could actually achieve in the time we went and that's one of the reasons that we're working on this one so there's one final thing that we'd like you to do and I'm just jumping where to put it we just want you to leave one of your cards behind just do it on this table here so either if you liked it


Okay, we're now going to solve an example problem involving a control volume moving at a constant velocity. So, I'll begin by drawing out the problem itself. Okay, so what we have here is we have a water jet and the jet of water is flowing from the left to the right in this direction here and it is impinging upon a blade and that blade is on rollers and consequently it is free to move to the right due to the fact that this jet or water jet is impinging upon the blade and so what we are told to solve for in this program in this problem we're told to find the force so we're told to find the force on the vein in order to keep you constant so essentially what we're told is what is the force required on the vein so this is our vein here there will have to be some force and we don't know exactly which direction is going to be moving in but a force something like that let me clean it up a little bit that's not the nicest vector but we have some force that we're looking for and the purpose is to find it for you to be constant and constant consequently that would be a case of a control volume moving at constant velocity because you can probably figure out we're going to put the control volume around the vein things that are given we're told that the velocity of the cart to begin with is 10 meters per second and that's the velocity that we want to maintain and the jet is coming in at a higher velocity it's coming in at 30 meters per second so this is a case where we will be doing analysis using a control volume moving at constant velocity so let's take a look at the solution okay so what we have here this is what our problem looks like we have the cart is moving at velocity you and I'll draw that as a vector going in that direction the jet is coming in from the left now what we're going to do we need to specify the control volume and for this problem what we're going to want to do is have the fluid crossing the control volume perpendicular to the control volume itself so we will draw the control volume like that so that it is perpendicular to the fluid streams and then I'll come over here the control volume I'll bring it right down to the ground but it's not going to go to the ground exactly and then I will bring it up so this is our control volume that we will define and what I'm going to do given that we have fluid crossing this boundary and this boundary I'm going to call this control surface one and this will be control surface two and then the last thing well another thing that will do remember this is a control volume that is moving and so it's moving we have a moving reference frame will give that a little action a little why and what we're going to do just that you can picture what's going on we're going to draw a little person on here because that person is moving with the control volume and then finally we're going to look for a force in order to maintain the velocity you to constant value and we will have a reaction force in the y direction and a reaction force in the x and I've just drawn them in that way positive x positive y we'll have to see by the sign that we get when we're done which direction they actually go in which is kind of a typical thing always doing statics so we have the fluid coming in the basic equations that we have the basic equations that we'll be using will be a conservation of mass or continuity and the momentum equation and so those will be the two basic equations a few assumptions let me write out the assumptions before we jump into the equations okay so a few assumptions that we have we have steady flow so even though the control volume is moving it's not accelerating because the force is holding it so that it only moves at a constant velocity and the conditions coming out of the jet itself from here we're not told anything is changing there so as far as we're concerned we can assume that to be steady flow coming in uniform flow so what does that mean what that means is that we're going to assume that this is kind of a fixed velocity profile if you're to look at the velocity profile coming in it is uniform it it's not a velocity profile that would have some sort of parabolic or or different type of shape like that we're going to assume it to be a uniform velocity profile sometimes we call that the top hat profile because it would be flat neglect body forces next thing density is constant so incompressible flow is what we're dealing with and the final assumption is the v1 is equal to v2 and so what that is implying the magnitude of v1 is equal to v2 so that would be the velocity of the fluid coming in at control surface one and the velocity or the magnitude of the velocity of fluid leaving control surface two okay so those are the assumptions what we're now going to do let's move ahead and start working with our basic equations okay so we have linear momentum and we have continuity so those are the basic equations continuity basic equations we have let's start with continuity and applying the assumptions that we wrote out we can eliminate some of the terms so okay so to begin with we have steady flow so this guy is gone and what we're left with is an integral across the two control surfaces if we look back here we have control surface one and control surface two so we apply the continuity equation across those two control surfaces and let's expand that out and I'm going to write the velocity vector with XYZ so that's in our with respect to the control volume reference frame I'm going to put it with a little subscript one and then for control surface two we have that now writing out the velocity vector or the yeah that'll be the velocity vector at control surface one what we have looking back and remember we have to we have to deal with velocity with respect to the control volume so we have a situation where we have V coming in and the control volume itself is moving at U so the velocity coming across here with respect to the control volume is going to be the difference between those two so we will have V minus U and then we can express that on inlet both components are moving in the X direction and so we get this I can write it out in the I component then for the velocity leaving this is for one of the assumptions we had we said that the magnitude of the velocities were the same so looking back at our drawing we know the angle here is 60 degrees so we can use trigonometry to figure out what the velocity component would be leaving so that would be the X component and the Y component and there we've made use of the fact that the magnitude of V one is equal to magnitude of V two one of our assumptions so what we can do is we can put this together and what we get for continuity and remember we need to be careful with the sign here so for control surface one let me just sketch this out because this is sometimes an area where students have difficulty so for control surface one let me draw the area remember the area vector is always going to be going outward from your control surface so that's the control surface but we have a velocity that is moving in this direction actually it's the V minus U and and so with that this is going to be a negative and then for control surface two what we have we had a control surface that was angled again the area vector is moving in that direction and then we have the well I'll just draw it as a vector but our velocity vector is going to be going in the same direction and so that will be a positive so consequently what we get from the continuity equation is the following and from this density cancels out because we're dealing with incompressible flow and we don't know anything about area two so I'll just leave that as area two but we get the magnitude of XYZ at interface one control surface one times area one is equal to the magnitude of velocity at control surface two times area two so that's what continuity gives us we're going to park that and then move on to take a look at the linear momentum equation in the next segment


I only had one birthday party in my life and I never went to birthday party so and when I came home from my 11th birthday party I was so excited I had a nosebleed. So I'm hoping this birthday party goes better. I'm gonna read some poems honoring some people who have helped shaped my life and I think it's important to write about them because we don't learn about our ancestors in school. We hardly ever learn about them just hanging out with our pals so I figure if I put them in a poem you'll get curious and then you'll try to find out more about them. The first person I'm going to to read about I mean read a poem for is Angelina Weld Grimke. She's the niece biracial niece of the abolitionist Grimke sisters who were notorious for their abolitionist views and activism and Angelina was a poet she moved to New York was kind of part of the Harlem Renaissance but she really suffered a lot because as a lesbian she felt like she had to be closeted all the time and I think some of her writing just never blossomed the way it could so I'm going to read a poem that I wrote kind of honoring the one poem I had first read of hers in which if you read the poem you could see she was talking about a woman because most of her work did not kind of reveal that she was very alluring looking as you can see so this poem is called the kiss 1930 and I use some of the language that she used in a poem and one of her lines is who will ever find me under the days Angelina was lived 1880 to 1958 there is no darkness like a closed door ornate panels thick with filigree soundproof denying time your fair pen finds its mark in the coal black circle of Boston society sheaves of paper thin custom threatened to bury you fashion father negritude slips steadily from the pile of demands to land on your breast to press you more firmly into their muting foals behind the door you dare to leave whispers of your precious stolen breath desire for her of the cruel lips a fragment revealed evidence of unruly passion and wild sadness in the strain to press your mouth to the hem of her skirt who decides which mouth speaks truth whose lips deserve to sense the yield of another's it is 1920 uptown bands are playing women are dancing in starched shirt fronts and top hats laughing out loud with painted faces abolition the obsession of your family has come home to Harlem every shape and shade builds to cacophony in the newness of freedom many are reborn into the singing glorious hints of redress and burnished futures you imprint your legacy crying want in muted tones saffron and lilac evocation of crimson secrets the soft rustle of days passing like crisp fiery leaves tumbling around our feet evoke the final soil dropping darkly onto sturdy pine still you do not write of your heart pounding except in solitude the soft scratch of pen on paper is your earth cracking open pages feet filled become a lock turning light falls on dark dark bodies you under those days primrose and dusk demure glistening with hunger the dewy orchid taste of your full lips a thick scent in the air a look of surprise mouths finally touch for all to see I like to give people happy endings Audrey Audrey Lord most of you probably already know her lived and taught in New York I took her writing classes she was a wonderful mentor for me she's the one who told me that the Gilda stories weren't just a collection of short stories but really was a novel and and she was so kind because she read them even though she told me she did not like short stories and she didn't care for vampires so I've been eternally grateful to her and she both as a mentor in my writing but as an example of how to be a lesbian feminist activist and she always insisted that all of her identities came together lesbian feminist poet activist mother Audrey when she passed away was the poet laureate of the state of New York she lived from 1934 to 1992 she wrote a book called Cole and the poem Cole I read when I was young I had no idea what it was about it was really intense and it was so dense I just I hadn't a clue but it kept me it kept me going so this is Cole for Audrey Lord I think of you as a diamond emerging from the compression of carbon shining and sharp both dark and light it's a stone that has come to mean both delight and death making it difficult to enjoy this gift from earth it's not possible to see the gleam of adorning it's not possible to see the gleam adorning soft skin without thinking of sweat glistening on black backs scarred for someone else's pleasure apartheid and murder cling to the stones as tightly as a necklace yet it is transubstantiation more important than that of myth earth's fiber wrapped tightly around itself friction and time until it shines like the sun so to our words simply letters and sounds draped and packaged around each other to unexpectedly emerge with meaning often far beyond their size or taste in your mouth your words are those diamonds from the earth but you are the one who toiled sweat and shaped gifting them wrapped in a prayer a plea that you'll be heard you aimed each like a scented spear meant to pry me open make my earth fertile enough to grow more words diamond bright diamond hard sweat drenched light through a desperate time and the final this is called we are everywhere and i wrote it for astronaut sally ride on the occasion of the 44th anniversary of landing on the moon sally ride was the first woman to land on the moon and we didn't really hear about her being a lesbian until she died she lived 1951 to 2012 being first can be a drag overwhelming the accomplishment itself the talk is of firstness as if that is the secret ingredient to your success first woman first queer or first left-handed first native first black first catholic first buddhist the path that led to stepping into light is obliterated the dust of rejection the well-worn ruts repeatedly broached the slam of closed doors and skeptical glances are ignored the quality of first becomes a crown whose glitter blinds all to the toil and heartbreak the secrets and soul searching but it is those impediments which need to be highlighted that mirror you consulted before writing your bio or smiling into the camera it knows the harsh trick of light that reveals only a profile still now we now that we know something of the secret you held i want to see you in your gear again youngest woman first known lesbian in space i want you to be able to take all of yourself out there into the vacuumed silence that is the universe this time your suit will be purple there's a portrait of your lover painted on the helmet stars may still look distant from where you float in the cosmos but they are blinking and glimmering right at you thrilled they lie at the perfect perspective to see all that you've endured to rest you in their embrace where i can see you by their light thank you