NDC London 2016 - Lightning Talks
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Simons, David
McLoughlin, Mathew
Cummings, Harry
Matskas, Christos
- Talk 1: What Software can learn from Reality TV, David Simons: A very light-hearted talk with a serious message at the middle: reality TV is watched by billions of people worldwide, so it must be doing something right. And Software has a duty to do that right thing too. The main body of this talk will focused on UX patterns and anti-patterns, such as how we can tap into human behaviour using iconography or colours, and examines case studies of them being successfully employed to evoke user response in the big examples of reality television. - Talk 2: The Value in Value Objects, Mathew McLoughlin: So it turns out you don’t have to limit yourself to using strings, ints and doubles. It turns out you are allowed to create your own types and there is a lot of value in doing so. Value objects help you encapsulate logic, enforce immutability and generally help tidy up your domain. In this talk I’ll show you how to create a value object, when to use them and why they are so powerful. - Talk 3: Designing an Orbital Laser Battery, Harry Cummings: REST, Hypermedia, HATEOAS, are terms that we come across often, but there is often confusion about how to apply them in real life. Taking a somewhat larger-than-life example, we'll work through designing an API, to demonstrate what sets REST apart from other architectural styles and really understand what it means beyond just stateless services or well-designed URI schemes. - Talk 4: Getting Started With Open Source, Christos Matskas: Are you a developer that wants to give back to the open source community? Perhaps you want to built some experience by working on open source? Or you want to join the open source movement because, well, OSS is the future? Just look at all the cool tech built with OSS: Node.js, BootStrap, ASP.NET etc. Join Christos Matskas to learn about the many ways to contribute, key development tools, communication in OSS projects and what it takes to become a successful first time contributor and collaborator in this welcoming and open community. Each presentation is 10 minutes.
 So if I quickly begin, I want to talk to you today about one of my passions, one of my absolute passions, and that's the X Factor. Just before I leap too far into that, if I quickly introduce myself, I'm a tech lead at Softwire. We are a company that do development across the whole software lifecycle. And as I said, one of my absolute passions in life is the X Factor. And that's not because the X Factor is good. By any means of, by any stretch of the imagination, the X Factor is an awful piece of art and an awful piece of entertainment. The people on there can barely sing. It is a total, totally ridiculous puppet show. If you haven't heard about it, it's a place where singers such as Leona Lewis, Little Mix and One Direction have come from. And it's a massive cultural institution in the UK. And that's because of all of the work that Psycho, that's Simon Cowell's production company put into it. It's not because Simon Cowell doesn't care about the X Factor because of the 20, 30 million pounds worth of voting revenue he gets each year. He doesn't care about it because of the 80 million pounds worth of advertising revenue he gets from it. He cares about it because of the approximately 300 million pounds worth of voting revenue that he would get if an act, a winner, went on to become the next Leona Lewis or One Direction. And so because of that, Simon Cowell is very invested in who is going to win the X Factor. And therefore he's very inclined to, I'm not going to accuse him of fixing the X Factor, that is very much illegal, I'm not going to slander him. But look at that face. He wants to manipulate. He wants to massage the X Factor. He wants to try and work out how he can get you to do exactly what he wants you to do. And that is exactly the same thing that good UX designers do. So I want to tell you today Simon Cowell's three top tips for compelling user experiences. And the first one is taking advantage of associations. So I want you to cast your mind back to 2013 and Sam Bailey who won the X Factor that year. We're going to be using this graph. So the important thing on this graph is this blue line. This blue line represents Sam Bailey's vote proportion. So as the number of contestants in the X Factor decreases, he'll naturally expect a tendency back towards, you know, 50% of the votes. But as you can see, she's doing fairly well over the weeks. I want you to look at this performance. Sam Bailey is performing in front of an hourglass. The sands of time in this hourglass are nearly running out. Just like Sam Bailey's time nearly run out in week two, the week she had the biggest dip in her vote during the whole competition. Here is Sam Bailey performing in front of a winners podium, which corresponds to the week she's had the biggest upturn in her vote. By utilizing these pictures, this sands of time nearly running out and Sam Bailey in the middle of a winners podium, the X Factor are able to manipulate you into thinking of her as out of date and winning respectively. These are because of the associations that you already have in your mind about the pictures that you're seeing. So when you see Jake Quickenden performing in front of shattered mirrors, it's no surprise that he was eliminated far earlier in the competition, the Lauren Platt performing in front of an almost messianic halo. What does this have to do with software? Well, as I said, you want to make sure that you're taking advantage of the associations that users already have about pictures in their mind. You want to use what's already established in a user's mind. If you look at every single one of these seven icons, you know what they mean. And the average user on the street will, too. You don't need to bother about redefining how to show more options on your web application. You don't need to worry about how to show a shopping cart. Users already know what they mean and you are able to take advantage of this knowledge. Using what other sites and other applications of a similar kind do is not stealing. I promise, if you go and use images and you go and use a vocabulary, it's fine. It's not stealing. It's a convention. A convention that genuinely agreed, ignored a consent part, accepted usage, especially as a standard of procedure. These are the sorts of things that, if an application does, you are strengthening the association by using it and improving their site. You're not stealing it. The same way that every social media site will use at to mean I want to mention this person. And every social media site will use a hashtag to do that I'm talking about this vague topic. And every social media site has a single word or a single action you can take to mean I am engaging in this content in a really banal way. Every social media site has this. And they strengthen each other by all using the same convention as rather than weakening or stealing or impinging from the other people. The X Factor also knows how to use the power of words very well. So when you're writing an application, when you're writing a user experience, you want to be thinking about your end goal. And at the end of the day, your end goal is to communicate with other users. You want to be getting your message across. And there's a lot of places out there that will give you very high-level guidance as to the sorts of things that you definitely should not do where you obfuscate your message or prevent your user from actually learning that information. I'm not here today to talk to you about how to use your words. I'm just here to try and talk to you about once you've used the correct words, is there a possibility to upsell? Is there a possibility to not just send a message across but actually maybe influence our user into doing something a little bit more? Now, this isn't just about sales. I'm not just talking about the words that we can use to encourage a user to buy an additional thing, that's what marketing departments are for. But it's actually quite often that as a developer, as technical people, we want users to be doing what we want them to do. So if they get an error, we don't want them to immediately phone up a support desk, we would like them to take a couple of simple actions themselves to try and diagnose the issue. And if we can get them to do that, just by changing the words we use in our application, we've just cut down the cost of our help desk or support and have to fix less trivial issues. Simon Carl also knows about the power of words. And I want to talk to you today about Wagner. Wagner, if you don't know, was a novelty act of 2010 X Factor. So if you're unfamiliar with the novelty act, the novelty act's job is to come in and give fun, colorful, flamboyant performances and increase the fun factor of the show whilst they're in there. At some point, they'll actually start doing quite well or appear to do quite well and caught controversy and get headlines for the X Factor. And then when the novelty act is no longer suiting Simon Carl, he will just get rid of them. So how did Simon Carl get rid of Wagner? Well, first of all, he got them to sing the song, I'm a creep, I'm a weirdo, what the hell am I doing here? I don't belong here. Those were the words sung by Wagner on the episode of the X Factor that he left. Danny Monogh said he really connected with those lyrics. So there is a small lesson here, which is people don't realize exactly how much they're being manipulated. Somebody was told very specifically that this person doesn't belong here and they just totally towed the line. That's a question more about kind of human, how gullible humans are. But the lesson here is in a different case study, because Louis Walsh said we could be on our way to the final. So Louis Walsh was talking about how Wagner was just getting the votes anyway. People didn't need to do anything because they could already be on the votes. In contrast to that with a different contestant, which is a different line said about a different contestant, if you believe in Ella, now's the time to vote. Now, it's a subtle difference between the two, but the difference is there. This line, which went on to get Ella Henderson the top vote that year, includes a call to action. It says you have to do something. Now is the time to vote. Because if you include a call to arms, if you include a very specific direction to a user to do something, then they are much more likely to do it. So do this. Take this action. Do it now. And, well, where can we use that in our application? As I said, if you get an error, we should actually be trying to get users to act on these errors themselves. So rather than just giving them a generic, something's not really working, we tell them to do something, and they have to do something, they're much more likely to do it. I want to really quickly touch on one last point, which is talking about why, what UX is, and how we can actually start thinking about it beyond knowing about our users. And that's by looking at the power of colors. So if we look at UPS, they've got a logo, it's brown. A lot of studies have been put in to actually try and work out why colors bring up certain associations in users, but actually it's true that they do. Even if a user is totally, even if a brand is totally not standing for the colors that the logo purports to represent, people can be tricked into thinking about it. And if you're a market leader, you get to define the market that you're going for by coloring your logo in a certain way. And the X factor knows this, because if they put out an act with a red or a black background, then they're going to get significantly lower votes than an act with a blue or a gold background. And that's just because of associations that are already in people's minds. And Andrew Myers has got a brilliant article about this. He's a UX designer. He's got a brilliant article about how color is helping users perceive information, and how people may not know that this color is actually influencing them, but it's important to always be thinking about it. So we can develop a large variety of techniques to try and actually get to the bottom of subconscious biases or subconscious influences in the user's brain. And so we actually have a duty to know our users better than they know themselves, because people do have subconscious biases. And if we can actually utilize and understand them, then we can be as powerful a manipulator as Simon Cowell. Thank you. Thank you. Thank you. Okay. All right, so lightning talks. What's cooler than lightning? Obviously lasers. So I thought I'd do a talk about designing an orbital laser battery, which is obviously relevant to our day-to-day lives. I've only got 10 minutes, though, so I'm going to focus on the most interesting part of this, which is, of course, the API. Now there are several ways that you can go about designing an API, and I'm going to kind of classify these as sort of what I'm going to call classic RPC-like APIs and what I'm going to call rest-ish APIs and what I'm going to describe as hypermedia APIs. I'm going to go through what I mean by each of those. So the classic RPC-like APIs, so obviously examples X and RPC, and I feel like SOAP APIs fall into this category as well. So this approach is where you start with thinking about the actions so one can do essentially method calls. You are defining your APIs a bunch of operations you can do, and a bunch of, and the documentation for your API is going to be something like a big Wuzdel file. Even if it's not SOAP, the documentation for this kind of API is going to be, here's a bunch of methods you can call, here are the things that get passed into them that come back out. And there's a few implications of this kind of API. You've got, your clients are going to be, although you've got all these different methods they can call, they're not really, and you might be grouping them together into services or you might be trying to make them consistent. They're not really, there's nothing really telling the client when it's appropriate to call each method or how to use them. And because you have to be very specific about the kind of signatures of these essentially remote procedures, and you have to be very specific in tying down exactly what actions the client can take, you're coupling your client and your service quite closely together and you have issues then if you want to expand your API and you want to change it, you've got these very closely coupled client and server and versioning becomes an issue. So the next popular trend in APIs is the kind of what I'm describing, describe as rest-ish APIs. So these are the kind of things you see if you, that come out of frameworks like Ruby on Rails and this sort of thing. So these are APIs that are trying to pick up on at least some of the ideas of rest and some of the sort of Roy Fielding's dissertation stuff. So these are thinking about resources. So they start thinking about nouns. They're like, well, what are the things we want to expose? These should be resources. And maybe they're getting rid of some of the nasties from SOAP, things like WSDL, these huge, you know, specification files, and maybe they're doing, again, maybe they're using JSON instead of XML or maybe they're even using content negotiation and maybe they're doing nice things like using the appropriate HTTP verb. So you might have a resource that's a list of things that you can post to create a new one and you can put to update it, which is very exciting that you get to use a different verb that's kind of the right thing and you can delete to delete it. And this is all fine. And there's nothing wrong with this. And actually, if the main thing that your clients need to do is kind of crud, if the main thing they need to do is just get it all the objects and update them and create new ones, then this is actually quite a good thing. This is actually quite a good API design. But the problem is because it's quite focused on now, it's quite focused on the objects, if you want to do something other than these kind of four verbs of creating and updating and deleting, you then start to get a little bit stuck because your options are either to sort of start adding new endpoints that are just some action that you can post to to make something else happen. Or your client has to be a lot more clever. Your client's got access to all the data. This kind of API is essentially just exposing the data layer of your application over whatever protocol you're using. And so clients can, they've got access to all the data. They can do whatever they want. The downside is that clients have access to all the data and can do whatever they want. So again, you're kind of exposing really the implementation of your application. You're not really, you're coupling your client and server together again. So, and this is like a very easy thing to build. There are lots of things like Rails and other frameworks and libraries and rapid application development things that make it very easy to, once you define your data model, your entity model, your active record models, to sort of click a few buttons and get this kind of API. But it's not necessarily the best thing to be doing to just find the nouns and then expose them over the wire. So, and these APIs are sometimes referred to as RESTful APIs because they have some of these principles in them. They seem to be using HTTP in kind of the right way. And they're talking about resources and this sort of thing. And they make the proper use of status codes and verbs and accept headers and that sort of thing. But I think there are a few principles that they're sort of missing. So how do we capture those principles? Well, that's the third type I want to talk about, which are hypermedia APIs. And this slightly controversial and ridiculous acronym, HATOAS, which is Hypertext as the engine of application state. But the point of this is that, so, we say that we want APIs to be stateless, which is obviously a good idea and HTTP is inherently stateless by design. But your application itself will have some state. You're going to be doing things. And the approach here is not to start by thinking about what actions or what operations you do and not to start by thinking about nouns, but to think about workflows. As long as you're using your application and using your API, they're going to be trying to achieve something. So they're going to be going through and the actions that they can do will depend at what state they're in in that workflow. So we don't need to give them all to them in advance. What we want is for the response from our API to say, this is where you are. These are the things you can do now. And that gives us a few advantages. So it means that it's a bit less overwhelming for the client. And when we come to document our API, what things can I do now are included in the responses we're sending to the client. So our documentation, rather than being this enormous list of operations or actions, the documentation just needs to be, how can I work out from a response? What things can I do at this point in the workflow? So we need to document a much smaller surface area. We just need to document the media type of the responses we're sending to the client. And this also means that we can then decouple our client and server a little bit. They can evolve a little bit more independently. And we can add new options and new workflows into our API without necessarily breaking our clients. So let's go back to our motivating example. So we've got our orbital laser battery, which is certainly stateful. And if someone wants to use it, well, what are they going to do? So they need some way to, they need a sort of landing point into our API, but they haven't done anything yet. And they need to know what they can do at that point. So obviously they can order an orbital laser bombardment. And then at that point, it will be in progress. Things will be happening. Satellites moving into position, whatever. So we've got some state going on there. We've got changes happening. So they may want to be updated on the progress. So they may call back to us again to say what's happening now. And eventually, the operation they asked for would have been carried out. So it would have moved on to another state. So this is the kind of progress that someone's going through. This is the workflow that the user of our API is going through. So how do we represent that in our API? What would that look like? So we start with just a landing point of our free open orbital laser system. And we can just get the root of the API. And this tells us what we can do at this point. And the first thing we have here is a link to the documentation for our media type. So this would contain the definition of how to interpret this response. So this is just Jason with some additional semantics about links to allow us to define verbs within our API without them having to be in the API documentation itself. And this says if you want to create a bombardment, you're going to need to tell me your last student longitude. You're going to need to send them to this URL. So I can do that and make a post to that URL. And then I get redirected. I say, oh, there's a new resource you're going to be interested in now. Go and get that. So I can go and get that resource. And now I get told about the status of my bombardment and it's in progress. And I want to get it updated on that. And I've got another link here where I can find out how to get it updated on it, which in this case is just linking back to itself to just pull this endpoint and get an update so I can keep on and get, and eventually I'll find out that it's completed. Excellent. So obviously that's a very simple example. And it feels like all this stuff about media types and about embedding links and documents and things, maybe this is just a little bit overengineered. Are we going to give it too far just to allow people to do something quite straightforward? But it starts to come into its own when you get more complicated workflows involved. So if you are an evil genius and you're building an orbital laser battery and you're holding the world's governments to ransom, obviously you're going to need an evil payment provider. And PayPal actually have one of the best examples of a real, a restful API in the world. So you can do all the things you might expect to do with a payment provider. You can create payments and so on. And when you create a payment, you get at the bottom the links of things you can do with it. So once you create a transaction, you can actually execute that transaction to cause a payment to happen. And once you cause the payment to happen, you then get more links you can do. You can go and find out about related payments. You can, there's another action you might want to take to refund this. So this API is quite self-explanatory about what you can do next and telling you where you are in the workflow. And to talk a little bit more about sort of media types rather than workflows, a good example there. JSON-LD is about defining, putting additional semantics on top of JSON to allow you to interlink things in more interesting ways and to allow you to be, allow your machines to be a little bit more clever about understanding what's in the document and the actual semantics around the data in there. And of course, the perfect canonical example of this is the web, which is the archetypal hypermedia API. And it's an excellent example of how it decouples the clients and the servers. So the applications, you know, if you look at the web as one enormous application, you don't need to, there's no kind of coupling between clients, web browsers, and websites. If Facebook want to add new features to their website, we don't need to all go and install a new version of Chrome or Firefox. Because the agreed contract, the defined documentation for the web, isn't these are all the different websites you can call and all the different things you can do on them. The defined contract is this is HTML and how it works. These are the semantics about links and forms and what they mean. So you can present a page and then say these are the things you can do from this page. So that's what I have to say. Lasers are awesome. My name is Harry. You can find me on Twitter and email me if you like. And thank you very much. Thank you. Hello everyone. My name is Christos. You know what? Forget it. I can't even get it right. If you want to get something out of me today, it's just I am the open source guy. If you have any questions about open source, come and find me. I'm not an expert, but I've been involved with that. So open source and why should we get involved with open source? I had a junior guy the other day talking at junior dev, talking at work and he said, why do you do it? Why do you spend all this time doing open source? What's the benefit? And I turn around and say, right, how much open source do you currently use at the project that you work on? It takes a couple of seconds to think about it and then he smiles back at me. Open source, it's everywhere. It's what makes the world go around. As a development process, it's amazing because it gets new developers and all developers working together to create something amazing. It's all about getting the community to work together. And on top of that, it creates software that we rely on on a day-to-day basis. If you are about to start a project, there's a very good chance that one of your tools or one of your libraries will be open source. Open source is everywhere. Now getting started with open source, it's a daunting process. So my talk today will discuss about three things. One is the benefits of doing open source work and what's the benefit to you and the community. How to get started if you've never done it before and why you should be paying attention to. And the third one is if you're already contributing and you're doing amazing work, how can you become even better at that? So three points. First of all, getting started. Sorry. First of all, it's about the benefits. First of all, it's cool. Everybody's doing it. Microsoft is doing it. Apple is doing it. Google is doing it. So many people around us doing it. For me, open source, it's all about, you know, there's an element of coolness and, you know, mystery over there. I feel almost like a hacker every time I do a PR, even though I've done so many pull requests. It still feels majestic doing that. And it's not like I'm hacking anything, but, you know, it's all about that. Second is that you're going to learn. You're going to learn through the process. You're going to become a better developer. By putting your code out in the open domain, you're about to get feedback. You're going to get slush. You're going to get comments. And the idea for that is for you to grow and learn. You have some really clever people out there doing open source, and you can always benefit from that. The third benefit is that you are going to make friends. The first thing that you need to do when you get into an open source project is to open the channel of communication. You need to say, I'm going to work on this issue, or I would like to help you with that. So automatically that gets you started. Eventually through one or two projects that you might work, you'll get an involvement, and then you'll meet people. And for example, for me today, I'm here, and I've met Matt and all the other cool guys that are doing open source work. And I just wanted to go and shake their hand and say, look, you're doing amazing work. And hopefully at some point, I will work with you. The fourth benefit is that you're going to get an amazing CV. If you do open source work, you'll find out a lot. Companies these days, more and more companies are looking into your engagement with open source. And some of them just go straight into GitHub and see what you can do. So imagine if you contribute to a big project, a project with a big profile, ASP.net, Omnisar, whatever, you name it. So these projects get onto your GitHub page, companies go and see that you do some really important work. That almost becomes a way or a ticket into getting your dream job. The final thing and the most important one is about the community. It's about building software that other people can use. And you'll be surprised that something that you put out in the public domain might be used by millions of people. And for me, it's all about standing on the shoulders of giants. That's what open source is all about. One extra bonus one is that you get free stuff. There's a lot of companies out there that will gladly give you software, that will give you their tools if you can prove that you do open source work. So we have JetBrains, you have Redgate, you have Microsoft. All these companies will be more than happy to give you stuff for free just because you're doing open source work. So now that you know the benefits, let's see how you can get started. If you've never done it before, I know it's quite strange and odd. So for me, for example, it was an accidental one contributing to NuGet, which was a Microsoft product. And that got me hooked. I was already in there. That was my first pull request, and that was the door to open source. But it doesn't have to be code. There's so many ways for you to get contributing. So you can start with documentation if you're not confident with code. You can write unit tests and get to know the code base better. And obviously, if you're confident you want to add a feature or fix a bug, then you can do the code fix. So if you've never done it before, how do you get started? First of all, you need to find a project that you're really passionate or you want to work on. And then if that's not something you can do or you can't find anything, there are lots of sites out there. One of them is up for grabs, for example, that allows you to go in and find projects that have been tagged for new developers to come and help out. Also on GitHub, you get projects that also tag their projects with appropriate tags and issues. So again, you can find lots of work around that is available for you. Once you get that point, you start communicating. You have to let them know that you want to contribute somehow. So make sure that you speak to the person that maintains the project and say, I want to work on this issue. Do you have any advice? Learn how to use Git. That's another invaluable tool. Not just for open source, but many companies use it right now. But having good knowledge about Git and the whole workflow of open source, it's very important. There are also a few things that you need to be very, very careful when you do open source or where you contribute. There's an etiquette that you need to abide by. And these are things that will guarantee that your first or your second or your third PR will be accepted. So one of the things that you need to pay very close attention to are the instructions. Most of the projects out there today have contributing pages where they have full instructions about how to go about contributing. Read that thoroughly, and if you have any questions, make sure you ask them. Another thing that you need to be very careful about is the coding standards. Every project has its own coding standards. Some people like underscore, some people like comments, some people don't like comments. Don't go in changing the whole project just because you don't like the structure. Make sure that you abide to that. Things like space and tabs. There's a whole war out there. And make sure that you don't change the structure. And if you have any question, if you ever get stuck, don't be shy about asking. Don't take over an issue and try to work it out and then you get stuck and never resolve it. If you get stuck, ask for help. So these are my guidelines. If you've never done before, I think this would give you a good idea about how to get started. Do documentation, do unit tests, help out in any way you feel appropriate for you and as you build your confidence, move into meet your staff. Now if you're already contributing, you're a rock star. You're doing an amazing job. You are writing software on your spare time. You're not getting paid for it. And you're setting it with us. That's fantastic. To my eyes, that's amazing. But there are ways that you might not know that you can become better. So there are a few things that the maintainers of projects need to be aware of. To have a successful project, of course. So the first one for me would be to lay down the groundwork. Build the documentation. Write the contribution instructions for your users. Because that sets the expectations both for them and for you. If your contributors don't abide to them, it's very easy for you to point them to your contributing page. But if there's nothing out there for them to watch, then things are going to become quite hairy. The second one is all about supporting them in any way. If you get questions and you are going to get a lot of questions, please make the time to help out. Because it's very important to provide the support that it's needed. Another thing is adding a license. It's not just enough to put your project onto the public domain and making it available. There are companies that won't be able to use your software and teams that won't be able to use your software just because you're missing the license. That's one of the important keys that a lot of people miss out out there. Make sure you also include a code of contact. Unfortunately, lately there's a lot of projects. There are a lot of projects out there that things go wrong. Users become nasty and there are bad comments. So if you want to be inclusive and supportive and keep a civil state around your project, make sure you include a code of contact and make sure you employ that. One last thing is that things can go wrong. If you are a maintainer of a project, then your life circumstances will change. Eventually, you might have kids. You might have a lot of work to do. You might be ill. You don't have enough time to contribute. Then that's fine. Don't feel guilty about it. The idea is that you can always go and ask for help. Also, if you start getting bad comments or if you start getting bad issues and people start complaining about them, then feel free to don't push back. Just take some time off and try to relax. There's also a new thing that came out a couple of days ago that you can now tag your projects and say, this project is not maintained. This library is not maintained by me anymore. That tells your users that it's okay to use it, but just be aware that I'm not currently maintaining it. It's not an active project, but you're all welcome and free to take over if you wish so. In conclusion, doing open source work, it's an amazing feat. It will help you and the community to become better and grow. I hope today, after listening to me, you've been inspired to go out and be awesome as well. Thank you very much, guys. Thank you. Okay. Good week. Yeah, okay, great. It's got information overload. Yeah, pretty much everyone, right? Okay. So the good news is that my mic is not breaking. This is a pretty simple subject to finish a week off with. It's not going to tax your brain too much. So that's good. It's Friday. Everybody's tired. My name is Matt McLaughlin. I want to speak to you about the value of the value of objects. Now, this is a subject that's kind of prevailing within domain-driven design, but I kind of like it and I want to speak about it outside of the context of DDD. So I think it's useful as well. So what's this? This is postcode, right? You know, it's a string. We've called it postcode. We've signed a string to it, which is postcode. Obviously, postcode. If you're from the UK, you'll notice that. What about this? Is this postcode? No, it's not a postcode. Okay? We've called it a postcode, but it's not a postcode. This can happen within a system. People can send information to your system. You need to validate it to make sure it's correct. So you'll probably end up writing a method, something like this. Insert a postcode. You validate the postcode. If the postcode is valid, you save it. If it's not, you throw an exception or return true or false or something similar, which is great. However, somebody might come along and do something like this. You might write another method. It makes use of a postcode. There's no validation in it. Okay? It's great. So this is opening you up to the possibility of invalid data. There's also a possibility with a previous method, but after the validation has taken place, somebody can change the value of the postcode. There's nobody stopping you from doing this. So this is where the value object comes in. Okay? It's a very simple concept. It really is. And this is about as simple as you can get. So rather than having your postcode assigned to a string, you create a new class, a new type, and you create it with an instance of a postcode. You can see here it's got a very simple public string on it with a private set. So once you create a postcode object, you can't change the value of a postcode. So it can't be changed. So that means you can start to put some validation on it. You can check if the postcode is valid. If it isn't, again, throw the exception. But if it is, assign the value and all of a sudden you've got a postcode there, but it can't be changed. It can't be modified with a system and it will stay valid throughout the entire system. You'll notice the regular expression here for validating postcode goes off the screen a little bit. That's a regular expression for a postcode. So yeah, good luck with that. Somebody wrote that. Yeah, the mind boggles. So once that happens, all of a sudden you can get rid of validation logic within your system. Rather than passing a string into this method, we're passing a postcode object into it. Looking at a previous postcode example, there's no way of being able to create an invalid postcode. You can save it. People can't change the value without it being validated again. It makes your system more secure, safe, and less prone to invalid data. A value object doesn't have to just be a simple primitive, though. It can also be something more complex. So let's take, for example, a person's name. Everybody's got a first name and surname, maybe not Prince, but most people have. And you'll see code like this within your system. Check with first name is both first name and last name and blank, and then you're going to go do something with it. So you could create a value object for this. The same principles before, just business logic contained within the class where you can assign to a first name, the last name, both private, can't be changed after it's been created. It's really mutable and is safe to use within your entire system. And that's really all there is to a value object. It's quite a simple concept. You can take it a step further, though. So attempt to show this. This is a more complicated value object. It's supposed to go to GAN. And it's got the logic in there to be able to validate to make sure that the postcode is valid before you create it. But you can also add additional methods in here. So if you go down a bit further, you can see we've added a try pass method in here, which will give the user the ability to check to see if the postcode is valid and if it isn't returned to a false can. It's similar to a date time. A date time is kind of a value object in itself. Further down, we've got an implicit operator to convert to a string. We've also got equality methods down here. So we can call it and pair one postcode to another. I mean, it's a string, so it's not particularly complicated to do the comparison, but in a more complicated value object, it could be. I mean, other great examples of value objects is, say, for example, money. How many people use decimal to store the money within their system? You know, it's common, right? But that's not money. What money is, is it's a value and it's a currency. So store them together, make sure they're valid, and it's quite a nice way to pass things between your system. Okay. So, what are the advantages of value objects? I've shown you a few. Protects business logic. As I say, the main thing is it allows you to create an object that is going to be valid for the entire process of your system of saving it. It can't be changed. There's also a few other advantages. Testability. Once you start to pull out your business logic out of your actual process of saving an object or whatever, you can start testing it on its own. So this makes the test of your business logic very, very simple. So here, again, just a couple of inline data is to test various different post-goes to see if they return to a false. It's really simple. You don't have to mock out any persistence layer or anything like that. It's quite nice. Readability. It's a lot more obvious that this method requires a postcode. Now, it doesn't happen often, but there's been scenarios, situations in the past where I've had a method that takes two strings and I've got them the wrong way around when I've called a method. Yeah. And that's going to introduce a bug. It happens. And if you start making use of value objects for simple things like post-goes, I mean, you really can take it to the F degree. Some systems you'll find where they don't use primitives at all. Every single object in the system is a value object. And it prevents you. There's no way you can pass the wrong string. You can only pass a postcode into it. You only know the postcode is going to be valid. And readability. Again, it's just once you start containing your business logic within these individual classes, you can reuse them throughout the system and the integrity is there. And again, as I said, accidentally passing the wrong value. So it really is a pretty simple concept. And you do see it a lot in domain-driven designs of a domain model. But I genuinely think it's something that you can take outside of a domain model. You can use it with just an entire application. And it makes sense to use. And that's really all there is to it. So I hope that wasn't too complicated. And I hope you make use of it. Thank you. Thank you.
 So if I quickly begin, I want to talk to you today about one of my passions, one of my  absolute passions, and that's the X Factor.  Just before I leap too far into that, if I quickly introduce myself, I'm a tech lead  at Softwire.  We are a company that do development across the whole software lifecycle.  And as I said, one of my absolute passions in life is the X Factor.  And that's not because the X Factor is good.  By any means of, by any stretch of the imagination, the X Factor is an awful piece of art and  an awful piece of entertainment.  The people on there can barely sing.  It is a total, totally ridiculous puppet show.  If you haven't heard about it, it's a place where singers such as Leona Lewis, Little  Mix and One Direction have come from.  And it's a massive cultural institution in the UK.  And that's because of all of the work that Psycho, that's Simon Cowell's production  company put into it.  It's not because Simon Cowell doesn't care about the X Factor because of the 20, 30 million  pounds worth of voting revenue he gets each year.  He doesn't care about it because of the 80 million pounds worth of advertising revenue  he gets from it.  He cares about it because of the approximately 300 million pounds worth of voting revenue  that he would get if an act, a winner, went on to become the next Leona Lewis or One Direction.  And so because of that, Simon Cowell is very invested in who is going to win the X Factor.  And therefore he's very inclined to, I'm not going to accuse him of fixing the X Factor,  that is very much illegal, I'm not going to slander him.  But look at that face.  He wants to manipulate.  He wants to massage the X Factor.  He wants to try and work out how he can get you to do exactly what he wants you to do.  And that is exactly the same thing that good UX designers do.  So I want to tell you today Simon Cowell's three top tips for compelling user experiences.  And the first one is taking advantage of associations.  So I want you to cast your mind back to 2013 and Sam Bailey who won the X Factor that year.  We're going to be using this graph.  So the important thing on this graph is this blue line.  This blue line represents Sam Bailey's vote proportion.  So as the number of contestants in the X Factor decreases, he'll naturally expect a tendency  back towards, you know, 50% of the votes.  But as you can see, she's doing fairly well over the weeks.  I want you to look at this performance.  Sam Bailey is performing in front of an hourglass.  The sands of time in this hourglass are nearly running out.  Just like Sam Bailey's time nearly run out in week two, the week she had the biggest  dip in her vote during the whole competition.  Here is Sam Bailey performing in front of a winners podium, which corresponds to the  week she's had the biggest upturn in her vote.  By utilizing these pictures, this sands of time nearly running out and Sam Bailey in  the middle of a winners podium, the X Factor are able to manipulate you into thinking of  her as out of date and winning respectively.  These are because of the associations that you already have in your mind about the pictures  that you're seeing.  So when you see Jake Quickenden performing in front of shattered mirrors, it's no surprise  that he was eliminated far earlier in the competition, the Lauren Platt performing in front of an  almost messianic halo.  What does this have to do with software?  Well, as I said, you want to make sure that you're taking advantage of the associations  that users already have about pictures in their mind.  You want to use what's already established in a user's mind.  If you look at every single one of these seven icons, you know what they mean.  And the average user on the street will, too.  You don't need to bother about redefining how to show more options on your web application.  You don't need to worry about how to show a shopping cart.  Users already know what they mean and you are able to take advantage of this knowledge.  Using what other sites and other applications of a similar kind do is not stealing.  I promise, if you go and use images and you go and use a vocabulary, it's fine.  It's not stealing.  It's a convention.  A convention that genuinely agreed, ignored a consent part, accepted usage, especially  as a standard of procedure.  These are the sorts of things that, if an application does, you are strengthening the association  by using it and improving their site.  You're not stealing it.  The same way that every social media site will use at to mean I want to mention this  person.  And every social media site will use a hashtag to do that I'm talking about this vague topic.  And every social media site has a single word or a single action you can take to mean I  am engaging in this content in a really banal way.  Every social media site has this.  And they strengthen each other by all using the same convention as rather than weakening  or stealing or impinging from the other people.  The X Factor also knows how to use the power of words very well.  So when you're writing an application, when you're writing a user experience, you want  to be thinking about your end goal.  And at the end of the day, your end goal is to communicate with other users.  You want to be getting your message across.  And there's a lot of places out there that will give you very high-level guidance as  to the sorts of things that you definitely should not do where you obfuscate your message  or prevent your user from actually learning that information.  I'm not here today to talk to you about how to use your words.  I'm just here to try and talk to you about once you've used the correct words, is there  a possibility to upsell?  Is there a possibility to not just send a message across but actually maybe influence  our user into doing something a little bit more?  Now, this isn't just about sales.  I'm not just talking about the words that we can use to encourage a user to buy an additional  thing, that's what marketing departments are for.  But it's actually quite often that as a developer, as technical people, we want users to be doing  what we want them to do.  So if they get an error, we don't want them to immediately phone up a support desk, we  would like them to take a couple of simple actions themselves to try and diagnose the  issue.  And if we can get them to do that, just by changing the words we use in our application,  we've just cut down the cost of our help desk or support and have to fix less trivial  issues.  Simon Carl also knows about the power of words.  And I want to talk to you today about Wagner.  Wagner, if you don't know, was a novelty act of 2010 X Factor.  So if you're unfamiliar with the novelty act, the novelty act's job is to come in and give  fun, colorful, flamboyant performances and increase the fun factor of the show whilst  they're in there.  At some point, they'll actually start doing quite well or appear to do quite well and  caught controversy and get headlines for the X Factor.  And then when the novelty act is no longer suiting Simon Carl, he will just get rid of  them.  So how did Simon Carl get rid of Wagner?  Well, first of all, he got them to sing the song, I'm a creep, I'm a weirdo, what the  hell am I doing here?  I don't belong here.  Those were the words sung by Wagner on the episode of the X Factor that he left.  Danny Monogh said he really connected with those lyrics.  So there is a small lesson here, which is people don't realize exactly how much they're  being manipulated.  Somebody was told very specifically that this person doesn't belong here and they just totally  towed the line.  That's a question more about kind of human, how gullible humans are.  But the lesson here is in a different case study, because Louis Walsh said we could be  on our way to the final.  So Louis Walsh was talking about how Wagner was just getting the votes anyway.  People didn't need to do anything because they could already be on the votes.  In contrast to that with a different contestant, which is a different line said about a different  contestant, if you believe in Ella, now's the time to vote.  Now, it's a subtle difference between the two, but the difference is there.  This line, which went on to get Ella Henderson the top vote that year, includes a call to  action.  It says you have to do something.  Now is the time to vote.  Because if you include a call to arms, if you include a very specific direction to a user  to do something, then they are much more likely to do it.  So do this.  Take this action.  Do it now.  And, well, where can we use that in our application?  As I said, if you get an error, we should actually be trying to get users to act on these  errors themselves.  So rather than just giving them a generic, something's not really working, we tell them  to do something, and they have to do something, they're much more likely to do it.  I want to really quickly touch on one last point, which is talking about why, what UX  is, and how we can actually start thinking about it beyond knowing about our users.  And that's by looking at the power of colors.  So if we look at UPS, they've got a logo, it's brown.  A lot of studies have been put in to actually try and work out why colors bring up certain  associations in users, but actually it's true that they do.  Even if a user is totally, even if a brand is totally not standing for the colors that  the logo purports to represent, people can be tricked into thinking about it.  And if you're a market leader, you get to define the market that you're going for by  coloring your logo in a certain way.  And the X factor knows this, because if they put out an act with a red or a black background,  then they're going to get significantly lower votes than an act with a blue or a gold background.  And that's just because of associations that are already in people's minds.  And Andrew Myers has got a brilliant article about this.  He's a UX designer.  He's got a brilliant article about how color is helping users perceive information, and  how people may not know that this color is actually influencing them, but it's important  to always be thinking about it.  So we can develop a large variety of techniques to try and actually get to the bottom of subconscious  biases or subconscious influences in the user's brain.  And so we actually have a duty to know our users better than they know themselves, because  people do have subconscious biases.  And if we can actually utilize and understand them, then we can be as powerful a manipulator  as Simon Cowell.  Thank you.  Thank you.  Thank you.  Okay.  All right, so lightning talks.  What's cooler than lightning?  Obviously lasers.  So I thought I'd do a talk about designing an orbital laser battery, which is obviously  relevant to our day-to-day lives.  I've only got 10 minutes, though, so I'm going to focus on the most interesting part  of this, which is, of course, the API.  Now there are several ways that you can go about designing an API, and I'm going to kind  of classify these as sort of what I'm going to call classic RPC-like APIs and what I'm  going to call rest-ish APIs and what I'm going to describe as hypermedia APIs.  I'm going to go through what I mean by each of those.  So the classic RPC-like APIs, so obviously examples X and RPC, and I feel like SOAP APIs  fall into this category as well.  So this approach is where you start with thinking about the actions so one can do essentially  method calls.  You are defining your APIs a bunch of operations you can do, and a bunch of, and the documentation  for your API is going to be something like a big Wuzdel file.  Even if it's not SOAP, the documentation for this kind of API is going to be, here's a  bunch of methods you can call, here are the things that get passed into them that come  back out.  And there's a few implications of this kind of API.  You've got, your clients are going to be, although you've got all these different methods  they can call, they're not really, and you might be grouping them together into services  or you might be trying to make them consistent.  They're not really, there's nothing really telling the client when it's appropriate to  call each method or how to use them.  And because you have to be very specific about the kind of signatures of these essentially  remote procedures, and you have to be very specific in tying down exactly what actions  the client can take, you're coupling your client and your service quite closely together  and you have issues then if you want to expand your API and you want to change it, you've  got these very closely coupled client and server and versioning becomes an issue.  So the next popular trend in APIs is the kind of what I'm describing, describe as rest-ish  APIs.  So these are the kind of things you see if you, that come out of frameworks like Ruby  on Rails and this sort of thing.  So these are APIs that are trying to pick up on at least some of the ideas of rest and  some of the sort of Roy Fielding's dissertation stuff.  So these are thinking about resources.  So they start thinking about nouns.  They're like, well, what are the things we want to expose?  These should be resources.  And maybe they're getting rid of some of the nasties from SOAP, things like WSDL, these  huge, you know, specification files, and maybe they're doing, again, maybe they're using  JSON instead of XML or maybe they're even using content negotiation and maybe they're  doing nice things like using the appropriate HTTP verb.  So you might have a resource that's a list of things that you can post to create a new  one and you can put to update it, which is very exciting that you get to use a different  verb that's kind of the right thing and you can delete to delete it.  And this is all fine.  And there's nothing wrong with this.  And actually, if the main thing that your clients need to do is kind of crud, if the  main thing they need to do is just get it all the objects and update them and create  new ones, then this is actually quite a good thing.  This is actually quite a good API design.  But the problem is because it's quite focused on now, it's quite focused on the objects,  if you want to do something other than these kind of four verbs of creating and updating  and deleting, you then start to get a little bit stuck because your options are either  to sort of start adding new endpoints that are just some action that you can post to  to make something else happen.  Or your client has to be a lot more clever.  Your client's got access to all the data.  This kind of API is essentially just exposing the data layer of your application over whatever  protocol you're using.  And so clients can, they've got access to all the data.  They can do whatever they want.  The downside is that clients have access to all the data and can do whatever they want.  So again, you're kind of exposing really the implementation of your application.  You're not really, you're coupling your client and server together again.  So, and this is like a very easy thing to build.  There are lots of things like Rails and other frameworks and libraries and rapid application  development things that make it very easy to, once you define your data model, your  entity model, your active record models, to sort of click a few buttons and get this kind  of API.  But it's not necessarily the best thing to be doing to just find the nouns and then  expose them over the wire.  So, and these APIs are sometimes referred to as RESTful APIs because they have some of  these principles in them.  They seem to be using HTTP in kind of the right way.  And they're talking about resources and this sort of thing.  And they make the proper use of status codes and verbs and accept headers and that sort  of thing.  But I think there are a few principles that they're sort of missing.  So how do we capture those principles?  Well, that's the third type I want to talk about, which are hypermedia APIs.  And this slightly controversial and ridiculous acronym, HATOAS, which is Hypertext as the  engine of application state.  But the point of this is that, so, we say that we want APIs to be stateless, which is  obviously a good idea and HTTP is inherently stateless by design.  But your application itself will have some state.  You're going to be doing things.  And the approach here is not to start by thinking about what actions or what operations you  do and not to start by thinking about nouns, but to think about workflows.  As long as you're using your application and using your API, they're going to be trying  to achieve something.  So they're going to be going through and the actions that they can do will depend at what  state they're in in that workflow.  So we don't need to give them all to them in advance.  What we want is for the response from our API to say, this is where you are.  These are the things you can do now.  And that gives us a few advantages.  So it means that it's a bit less overwhelming for the client.  And when we come to document our API, what things can I do now are included in the responses  we're sending to the client.  So our documentation, rather than being this enormous list of operations or actions, the  documentation just needs to be, how can I work out from a response?  What things can I do at this point in the workflow?  So we need to document a much smaller surface area.  We just need to document the media type of the responses we're sending to the client.  And this also means that we can then decouple our client and server a little bit.  They can evolve a little bit more independently.  And we can add new options and new workflows into our API without necessarily breaking  our clients.  So let's go back to our motivating example.  So we've got our orbital laser battery, which is certainly stateful.  And if someone wants to use it, well, what are they going to do?  So they need some way to, they need a sort of landing point into our API, but they haven't  done anything yet.  And they need to know what they can do at that point.  So obviously they can order an orbital laser bombardment.  And then at that point, it will be in progress.  Things will be happening.  Satellites moving into position, whatever.  So we've got some state going on there.  We've got changes happening.  So they may want to be updated on the progress.  So they may call back to us again to say what's happening now.  And eventually, the operation they asked for would have been carried out.  So it would have moved on to another state.  So this is the kind of progress that someone's going through.  This is the workflow that the user of our API is going through.  So how do we represent that in our API?  What would that look like?  So we start with just a landing point of our free open orbital laser system.  And we can just get the root of the API.  And this tells us what we can do at this point.  And the first thing we have here is a link to the documentation for our media type.  So this would contain the definition of how to interpret this response.  So this is just Jason with some additional semantics about links to allow us to define  verbs within our API without them having to be in the API documentation itself.  And this says if you want to create a bombardment, you're going to need to tell me your last  student longitude.  You're going to need to send them to this URL.  So I can do that and make a post to that URL.  And then I get redirected.  I say, oh, there's a new resource you're going to be interested in now.  Go and get that.  So I can go and get that resource.  And now I get told about the status of my bombardment and it's in progress.  And I want to get it updated on that.  And I've got another link here where I can find out how to get it updated on it, which  in this case is just linking back to itself to just pull this endpoint and get an update  so I can keep on and get, and eventually I'll find out that it's completed.  Excellent.  So obviously that's a very simple example.  And it feels like all this stuff about media types and about embedding links and documents  and things, maybe this is just a little bit overengineered.  Are we going to give it too far just to allow people to do something quite straightforward?  But it starts to come into its own when you get more complicated workflows involved.  So if you are an evil genius and you're building an orbital laser battery and you're holding  the world's governments to ransom, obviously you're going to need an evil payment provider.  And PayPal actually have one of the best examples of a real, a restful API in the world.  So you can do all the things you might expect to do with a payment provider.  You can create payments and so on.  And when you create a payment, you get at the bottom the links of things you can do  with it.  So once you create a transaction, you can actually execute that transaction to cause  a payment to happen.  And once you cause the payment to happen, you then get more links you can do.  You can go and find out about related payments.  You can, there's another action you might want to take to refund this.  So this API is quite self-explanatory about what you can do next and telling you where  you are in the workflow.  And to talk a little bit more about sort of media types rather than workflows, a good  example there.  JSON-LD is about defining, putting additional semantics on top of JSON to allow you to  interlink things in more interesting ways and to allow you to be, allow your machines  to be a little bit more clever about understanding what's in the document and the actual semantics  around the data in there.  And of course, the perfect canonical example of this is the web, which is the archetypal  hypermedia API.  And it's an excellent example of how it decouples the clients and the servers.  So the applications, you know, if you look at the web as one enormous application, you  don't need to, there's no kind of coupling between clients, web browsers, and websites.  If Facebook want to add new features to their website, we don't need to all go and install  a new version of Chrome or Firefox.  Because the agreed contract, the defined documentation for the web, isn't these are all the different  websites you can call and all the different things you can do on them.  The defined contract is this is HTML and how it works.  These are the semantics about links and forms and what they mean.  So you can present a page and then say these are the things you can do from this page.  So that's what I have to say.  Lasers are awesome.  My name is Harry.  You can find me on Twitter and email me if you like.  And thank you very much.  Thank you.  Hello everyone.  My name is Christos.  You know what?  Forget it.  I can't even get it right.  If you want to get something out of me today, it's just I am the open source guy.  If you have any questions about open source, come and find me.  I'm not an expert, but I've been involved with that.  So open source and why should we get involved with open source?  I had a junior guy the other day talking at junior dev, talking at work and he said, why  do you do it?  Why do you spend all this time doing open source?  What's the benefit?  And I turn around and say, right, how much open source do you currently use at the project  that you work on?  It takes a couple of seconds to think about it and then he smiles back at me.  Open source, it's everywhere.  It's what makes the world go around.  As a development process, it's amazing because it gets new developers and all developers  working together to create something amazing.  It's all about getting the community to work together.  And on top of that, it creates software that we rely on on a day-to-day basis.  If you are about to start a project, there's a very good chance that one of your tools  or one of your libraries will be open source.  Open source is everywhere.  Now getting started with open source, it's a daunting process.  So my talk today will discuss about three things.  One is the benefits of doing open source work and what's the benefit to you and the community.  How to get started if you've never done it before and why you should be paying attention  to.  And the third one is if you're already contributing and you're doing amazing work, how can you  become even better at that?  So three points.  First of all, getting started.  Sorry.  First of all, it's about the benefits.  First of all, it's cool.  Everybody's doing it.  Microsoft is doing it.  Apple is doing it.  Google is doing it.  So many people around us doing it.  For me, open source, it's all about, you know, there's an element of coolness and, you know,  mystery over there.  I feel almost like a hacker every time I do a PR, even though I've done so many pull requests.  It still feels majestic doing that.  And it's not like I'm hacking anything, but, you know, it's all about that.  Second is that you're going to learn.  You're going to learn through the process.  You're going to become a better developer.  By putting your code out in the open domain, you're about to get feedback.  You're going to get slush.  You're going to get comments.  And the idea for that is for you to grow and learn.  You have some really clever people out there doing open source, and you can always benefit  from that.  The third benefit is that you are going to make friends.  The first thing that you need to do when you get into an open source project is to open  the channel of communication.  You need to say, I'm going to work on this issue, or I would like to help you with that.  So automatically that gets you started.  Eventually through one or two projects that you might work, you'll get an involvement,  and then you'll meet people.  And for example, for me today, I'm here, and I've met Matt and all the other cool guys  that are doing open source work.  And I just wanted to go and shake their hand and say, look, you're doing amazing work.  And hopefully at some point, I will work with you.  The fourth benefit is that you're going to get an amazing CV.  If you do open source work, you'll find out a lot.  Companies these days, more and more companies are looking into your engagement with open  source.  And some of them just go straight into GitHub and see what you can do.  So imagine if you contribute to a big project, a project with a big profile, ASP.net, Omnisar,  whatever, you name it.  So these projects get onto your GitHub page, companies go and see that you do some really  important work.  That almost becomes a way or a ticket into getting your dream job.  The final thing and the most important one is about the community.  It's about building software that other people can use.  And you'll be surprised that something that you put out in the public domain might be  used by millions of people.  And for me, it's all about standing on the shoulders of giants.  That's what open source is all about.  One extra bonus one is that you get free stuff.  There's a lot of companies out there that will gladly give you software, that will give  you their tools if you can prove that you do open source work.  So we have JetBrains, you have Redgate, you have Microsoft.  All these companies will be more than happy to give you stuff for free just because you're  doing open source work.  So now that you know the benefits, let's see how you can get started.  If you've never done it before, I know it's quite strange and odd.  So for me, for example, it was an accidental one contributing to NuGet, which was a Microsoft  product.  And that got me hooked.  I was already in there.  That was my first pull request, and that was the door to open source.  But it doesn't have to be code.  There's so many ways for you to get contributing.  So you can start with documentation if you're not confident with code.  You can write unit tests and get to know the code base better.  And obviously, if you're confident you want to add a feature or fix a bug, then you can  do the code fix.  So if you've never done it before, how do you get started?  First of all, you need to find a project that you're really passionate or you want to work  on.  And then if that's not something you can do or you can't find anything, there are lots  of sites out there.  One of them is up for grabs, for example, that allows you to go in and find projects  that have been tagged for new developers to come and help out.  Also on GitHub, you get projects that also tag their projects with appropriate tags  and issues.  So again, you can find lots of work around that is available for you.  Once you get that point, you start communicating.  You have to let them know that you want to contribute somehow.  So make sure that you speak to the person that maintains the project and say, I want  to work on this issue.  Do you have any advice?  Learn how to use Git.  That's another invaluable tool.  Not just for open source, but many companies use it right now.  But having good knowledge about Git and the whole workflow of open source, it's very important.  There are also a few things that you need to be very, very careful when you do open source  or where you contribute.  There's an etiquette that you need to abide by.  And these are things that will guarantee that your first or your second or your third PR  will be accepted.  So one of the things that you need to pay very close attention to are the instructions.  Most of the projects out there today have contributing pages where they have full instructions  about how to go about contributing.  Read that thoroughly, and if you have any questions, make sure you ask them.  Another thing that you need to be very careful about is the coding standards.  Every project has its own coding standards.  Some people like underscore, some people like comments, some people don't like comments.  Don't go in changing the whole project just because you don't like the structure.  Make sure that you abide to that.  Things like space and tabs.  There's a whole war out there.  And make sure that you don't change the structure.  And if you have any question, if you ever get stuck, don't be shy about asking.  Don't take over an issue and try to work it out and then you get stuck and never resolve  it.  If you get stuck, ask for help.  So these are my guidelines.  If you've never done before, I think this would give you a good idea about how to get  started.  Do documentation, do unit tests, help out in any way you feel appropriate for you and  as you build your confidence, move into meet your staff.  Now if you're already contributing, you're a rock star.  You're doing an amazing job.  You are writing software on your spare time.  You're not getting paid for it.  And you're setting it with us.  That's fantastic.  To my eyes, that's amazing.  But there are ways that you might not know that you can become better.  So there are a few things that the maintainers of projects need to be aware of.  To have a successful project, of course.  So the first one for me would be to lay down the groundwork.  Build the documentation.  Write the contribution instructions for your users.  Because that sets the expectations both for them and for you.  If your contributors don't abide to them, it's very easy for you to point them to your  contributing page.  But if there's nothing out there for them to watch, then things are going to become  quite hairy.  The second one is all about supporting them in any way.  If you get questions and you are going to get a lot of questions, please make the time  to help out.  Because it's very important to provide the support that it's needed.  Another thing is adding a license.  It's not just enough to put your project onto the public domain and making it available.  There are companies that won't be able to use your software and teams that won't be  able to use your software just because you're missing the license.  That's one of the important keys that a lot of people miss out out there.  Make sure you also include a code of contact.  Unfortunately, lately there's a lot of projects.  There are a lot of projects out there that things go wrong.  Users become nasty and there are bad comments.  So if you want to be inclusive and supportive and keep a civil state around your project,  make sure you include a code of contact and make sure you employ that.  One last thing is that things can go wrong.  If you are a maintainer of a project, then your life circumstances will change.  Eventually, you might have kids.  You might have a lot of work to do.  You might be ill.  You don't have enough time to contribute.  Then that's fine.  Don't feel guilty about it.  The idea is that you can always go and ask for help.  Also, if you start getting bad comments or if you start getting bad issues and people  start complaining about them, then feel free to don't push back.  Just take some time off and try to relax.  There's also a new thing that came out a couple of days ago that you can now tag your projects  and say, this project is not maintained.  This library is not maintained by me anymore.  That tells your users that it's okay to use it, but just be aware that I'm not currently  maintaining it.  It's not an active project, but you're all welcome and free to take over if you wish so.  In conclusion, doing open source work, it's an amazing feat.  It will help you and the community to become better and grow.  I hope today, after listening to me, you've been inspired to go out and be awesome as  well.  Thank you very much, guys.  Thank you.  Okay.  Good week.  Yeah, okay, great.  It's got information overload.  Yeah, pretty much everyone, right?  Okay.  So the good news is that my mic is not breaking.  This is a pretty simple subject to finish a week off with.  It's not going to tax your brain too much.  So that's good.  It's Friday.  Everybody's tired.  My name is Matt McLaughlin.  I want to speak to you about the value of the value of objects.  Now, this is a subject that's kind of prevailing within domain-driven design, but I kind of  like it and I want to speak about it outside of the context of DDD.  So I think it's useful as well.  So what's this?  This is postcode, right?  You know, it's a string.  We've called it postcode.  We've signed a string to it, which is postcode.  Obviously, postcode.  If you're from the UK, you'll notice that.  What about this?  Is this postcode?  No, it's not a postcode.  Okay?  We've called it a postcode, but it's not a postcode.  This can happen within a system.  People can send information to your system.  You need to validate it to make sure it's correct.  So you'll probably end up writing a method, something like this.  Insert a postcode.  You validate the postcode.  If the postcode is valid, you save it.  If it's not, you throw an exception or return true or false or something similar, which  is great.  However, somebody might come along and do something like this.  You might write another method.  It makes use of a postcode.  There's no validation in it.  Okay?  It's great.  So this is opening you up to the possibility of invalid data.  There's also a possibility with a previous method, but after the validation has taken  place, somebody can change the value of the postcode.  There's nobody stopping you from doing this.  So this is where the value object comes in.  Okay?  It's a very simple concept.  It really is.  And this is about as simple as you can get.  So rather than having your postcode assigned to a string, you create a new class, a new  type, and you create it with an instance of a postcode.  You can see here it's got a very simple public string on it with a private set.  So once you create a postcode object, you can't change the value of a postcode.  So it can't be changed.  So that means you can start to put some validation on it.  You can check if the postcode is valid.  If it isn't, again, throw the exception.  But if it is, assign the value and all of a sudden you've got a postcode there, but it  can't be changed.  It can't be modified with a system and it will stay valid throughout the entire system.  You'll notice the regular expression here for validating postcode goes off the screen  a little bit.  That's a regular expression for a postcode.  So yeah, good luck with that.  Somebody wrote that.  Yeah, the mind boggles.  So once that happens, all of a sudden you can get rid of validation logic within your  system.  Rather than passing a string into this method, we're passing a postcode object into it.  Looking at a previous postcode example, there's no way of being able to create an invalid  postcode.  You can save it.  People can't change the value without it being validated again.  It makes your system more secure, safe, and less prone to invalid data.  A value object doesn't have to just be a simple primitive, though.  It can also be something more complex.  So let's take, for example, a person's name.  Everybody's got a first name and surname, maybe not Prince, but most people have.  And you'll see code like this within your system.  Check with first name is both first name and last name and blank, and then you're going  to go do something with it.  So you could create a value object for this.  The same principles before, just business logic contained within the class where you  can assign to a first name, the last name, both private, can't be changed after it's  been created.  It's really mutable and is safe to use within your entire system.  And that's really all there is to a value object.  It's quite a simple concept.  You can take it a step further, though.  So attempt to show this.  This is a more complicated value object.  It's supposed to go to GAN.  And it's got the logic in there to be able to validate to make sure that the postcode  is valid before you create it.  But you can also add additional methods in here.  So if you go down a bit further, you can see we've added a try pass method in here, which  will give the user the ability to check to see if the postcode is valid and if it isn't  returned to a false can.  It's similar to a date time.  A date time is kind of a value object in itself.  Further down, we've got an implicit operator to convert to a string.  We've also got equality methods down here.  So we can call it and pair one postcode to another.  I mean, it's a string, so it's not particularly complicated to do the comparison, but in a  more complicated value object, it could be.  I mean, other great examples of value objects is, say, for example, money.  How many people use decimal to store the money within their system?  You know, it's common, right?  But that's not money.  What money is, is it's a value and it's a currency.  So store them together, make sure they're valid, and it's quite a nice way to pass things  between your system.  Okay.  So, what are the advantages of value objects?  I've shown you a few.  Protects business logic.  As I say, the main thing is it allows you to create an object that is going to be valid  for the entire process of your system of saving it.  It can't be changed.  There's also a few other advantages.  Testability.  Once you start to pull out your business logic out of your actual process of saving  an object or whatever, you can start testing it on its own.  So this makes the test of your business logic very, very simple.  So here, again, just a couple of inline data is to test various different post-goes to  see if they return to a false.  It's really simple.  You don't have to mock out any persistence layer or anything like that.  It's quite nice.  Readability.  It's a lot more obvious that this method requires a postcode.  Now, it doesn't happen often, but there's been scenarios, situations in the past where  I've had a method that takes two strings and I've got them the wrong way around when I've  called a method.  Yeah.  And that's going to introduce a bug.  It happens.  And if you start making use of value objects for simple things like post-goes, I mean,  you really can take it to the F degree.  Some systems you'll find where they don't use primitives at all.  Every single object in the system is a value object.  And it prevents you.  There's no way you can pass the wrong string.  You can only pass a postcode into it.  You only know the postcode is going to be valid.  And readability.  Again, it's just once you start containing your business logic within these individual  classes, you can reuse them throughout the system and the integrity is there.  And again, as I said, accidentally passing the wrong value.  So it really is a pretty simple concept.  And you do see it a lot in domain-driven designs of a domain model.  But I genuinely think it's something that you can take outside of a domain model.  You can use it with just an entire application.  And it makes sense to use.  And that's really all there is to it.  So I hope that wasn't too complicated.  And I hope you make use of it.  Thank you.  Thank you.
Lightning_Talks_ORIGINAL_DOWNLOAD_0_323.png Lightning_Talks_ORIGINAL_DOWNLOAD_324_719.png Lightning_Talks_ORIGINAL_DOWNLOAD_720_1271.png Lightning_Talks_ORIGINAL_DOWNLOAD_1272_2579.png Lightning_Talks_ORIGINAL_DOWNLOAD_2580_2963.png Lightning_Talks_ORIGINAL_DOWNLOAD_2964_3299.png Lightning_Talks_ORIGINAL_DOWNLOAD_3300_3899.png Lightning_Talks_ORIGINAL_DOWNLOAD_3900_4931.png Lightning_Talks_ORIGINAL_DOWNLOAD_4932_5135.png Lightning_Talks_ORIGINAL_DOWNLOAD_5136_5315.png Lightning_Talks_ORIGINAL_DOWNLOAD_5316_5447.png Lightning_Talks_ORIGINAL_DOWNLOAD_5448_5759.png Lightning_Talks_ORIGINAL_DOWNLOAD_5760_6419.png Lightning_Talks_ORIGINAL_DOWNLOAD_6420_7055.png Lightning_Talks_ORIGINAL_DOWNLOAD_7056_7979.png Lightning_Talks_ORIGINAL_DOWNLOAD_7980_8219.png Lightning_Talks_ORIGINAL_DOWNLOAD_8220_8747.png Lightning_Talks_ORIGINAL_DOWNLOAD_8748_8987.png Lightning_Talks_ORIGINAL_DOWNLOAD_8988_10439.png Lightning_Talks_ORIGINAL_DOWNLOAD_10440_10919.png Lightning_Talks_ORIGINAL_DOWNLOAD_10920_11399.png Lightning_Talks_ORIGINAL_DOWNLOAD_11400_11915.png Lightning_Talks_ORIGINAL_DOWNLOAD_11916_12935.png Lightning_Talks_ORIGINAL_DOWNLOAD_12936_14099.png Lightning_Talks_ORIGINAL_DOWNLOAD_14100_15047.png Lightning_Talks_ORIGINAL_DOWNLOAD_15048_15383.png Lightning_Talks_ORIGINAL_DOWNLOAD_15384_15767.png Lightning_Talks_ORIGINAL_DOWNLOAD_15768_16019.png Lightning_Talks_ORIGINAL_DOWNLOAD_16020_16139.png Lightning_Talks_ORIGINAL_DOWNLOAD_16140_16487.png Lightning_Talks_ORIGINAL_DOWNLOAD_16488_17579.png Lightning_Talks_ORIGINAL_DOWNLOAD_17580_17843.png Lightning_Talks_ORIGINAL_DOWNLOAD_17844_18179.png Lightning_Talks_ORIGINAL_DOWNLOAD_18180_20447.png Lightning_Talks_ORIGINAL_DOWNLOAD_20448_24587.png Lightning_Talks_ORIGINAL_DOWNLOAD_24588_27143.png Lightning_Talks_ORIGINAL_DOWNLOAD_27144_28475.png Lightning_Talks_ORIGINAL_DOWNLOAD_28476_28571.png Lightning_Talks_ORIGINAL_DOWNLOAD_28572_29471.png Lightning_Talks_ORIGINAL_DOWNLOAD_29472_29531.png Lightning_Talks_ORIGINAL_DOWNLOAD_29532_29675.png Lightning_Talks_ORIGINAL_DOWNLOAD_29676_30551.png Lightning_Talks_ORIGINAL_DOWNLOAD_30552_30827.png Lightning_Talks_ORIGINAL_DOWNLOAD_30828_31019.png Lightning_Talks_ORIGINAL_DOWNLOAD_31020_31343.png Lightning_Talks_ORIGINAL_DOWNLOAD_31344_31415.png Lightning_Talks_ORIGINAL_DOWNLOAD_31416_32183.png Lightning_Talks_ORIGINAL_DOWNLOAD_32184_33923.png Lightning_Talks_ORIGINAL_DOWNLOAD_33924_54971.png Lightning_Talks_ORIGINAL_DOWNLOAD_54972_56147.png Lightning_Talks_ORIGINAL_DOWNLOAD_56148_56315.png Lightning_Talks_ORIGINAL_DOWNLOAD_56316_56855.png Lightning_Talks_ORIGINAL_DOWNLOAD_56856_58079.png Lightning_Talks_ORIGINAL_DOWNLOAD_58080_60203.png Lightning_Talks_ORIGINAL_DOWNLOAD_60204_60503.png Lightning_Talks_ORIGINAL_DOWNLOAD_60504_60839.png Lightning_Talks_ORIGINAL_DOWNLOAD_60840_61199.png Lightning_Talks_ORIGINAL_DOWNLOAD_61200_61415.png Lightning_Talks_ORIGINAL_DOWNLOAD_61416_62231.png Lightning_Talks_ORIGINAL_DOWNLOAD_62232_63323.png Lightning_Talks_ORIGINAL_DOWNLOAD_63324_64499.png Lightning_Talks_ORIGINAL_DOWNLOAD_64500_65926.png