Okay guys, today we are very pleased to have Michael Chang with the senior software engineer Singapore Power Limited. He has a lot of experience in more than 10 years in dynamic websites like using PHP. Right now he also does Ruby and he runs a Singapore PHP user group. He co-founded iOS Dev Scouts and is the organizer of PHP Contest here. So he also runs a lot of passion projects like engineers.sg which is a non-profit community initiative to document and achieve the take and start-up skills in Singapore. So please welcome him to give this wonderful lecture. So he will talk about software development in practice. So I will hand it over to you. Yeah, okay. Hey guys. Hi, my name is Michael. So that's me. You can get at me on Twitter if you're so inclined, you know. If you don't want to add me on Twitter, it's fine. I won't get offended. That's my email address. If you have any questions, you can always drop me an email. I'll be glad to answer some of your questions. A little bit more about me. I majored in History and Political Science. I did not major in Computer Science. I was in Social Sciences and stuff. I kind of like history. So I was from NUS and I've been doing PHP for about 10 years. The Singapore PHP User Group is just celebrating its 10th anniversary. So we've kind of been around for a while. The first startup I joined was basically a few back in 2011. It was a small little startup called Found. So it's kind of like the first startup I ever joined. And from there, it really brought my career to the next level.  I really wanted to focus on the craft, basically be better at writing software, which is why I joined this company. I really felt I really learned a lot. From there, I also joined the last startup called MIG33. Of course, this company has now changed, they're rebranded and now they're called MIGMe. They have a social network. They're pretty big in Indonesia and Iran and some other third world countries. Yeah, they're really big on those countries. When I left the company, MIGMe was basically PHP only. When I joined Neo Innovation, I basically decided I needed to change the environment. I wanted to learn other stuff. I don't want to be just boxed into just PHP alone. When I joined Neo Innovation, this is a consultancy. They're really big agile shop. They do Ruby on Rails and all sorts of stuff. From there, I really learned a lot. Of course, Neo got sold and basically now they're called pivotal labs. If you guys are looking for a job, you can also look there as well or Singapore Power. That's where I am now, Singapore Power. Today, we'll be talking about modern software development practices. Why modern? Because personally, I feel that it's not just about the buzzwords. Building a building software nowadays is not just about, oh, it has to be agile, it has to be scrum, it has to be TDD, it has to be what? No, for me, it's become a way of life. It's become very natural to me to build software in this way, which is why it's pretty much like, which is why I say it's pretty much about, it's kind of a natural way of building software and it's about doing what works. Agility in practice, basically, have you guys heard of the agile manifesto? Yeah, you have, right?  See, so many fancy things. Anyway, agile manifesto talks about individual and interaction over processes, working software over giant stacks of documentation, customer collaboration over contract negotiation. You just basically get things done and you collaborate with the customer directly and about responding to change over following a plan. Did I do the wrong thing? Right, sorry. So, the agile manifesto is pretty much like a bunch of principles and guidelines. It's not very prescriptive to your situation right now. What you're building, building a writing software, it doesn't really tell you how you should go about doing it. It's more like a bunch of principles that you should follow that they feel that could probably help you build better software. But they're not very prescriptive. So, how do we put this into practice? So, for many of us, people in my company and many of my peers, we don't care about bus words, we just care about getting things done. And it's not just about that. We care about getting the right things done and we care about getting the right things done the right way. It's not just about building right and building the right thing and building it the right way, right? So, that's pretty much about building software in the modern era. Oh man, okay. This is embarrassing. I'm an IT professional. I don't know how to operate this thing. Apologies. So, anyway, we talk about building the right thing. We also talk about building things right. So, it's in the right way. When we talk about building things, getting the right things to build, we talk about building lean. Okay, it is a bus word. Yes, building lean is a bus word. Yes, unfortunately. So, you find my slides are full of bus words, but I don't really care about them. What I care about is what we actually do. So, building lean is about the process of figuring out what is the right thing to build. So, it's pretty much like a hypothesis. The first time a hypothesis is basically about what customers, for example, we have a hypothesis about, say, customers at Starbucks, they would like to pay with Bitcoin. So, from the hypothesis, we look at building something. So, as a startup entrepreneur, or maybe you working for a startup entrepreneur, we kind of help them through this process of what you want to build, but why do you want to build it? Why do you want to build it is your hypothesis. Basically, I believe customers want to do something. In this case, it's about them. Customers, you feel your CEO or your co-founder, or even yourself, you may feel that, oh, there's a certain customer need. There's something that customers want. In this example, it's about we think customers at Starbucks really want to pay with Bitcoin. So, what we do next is we basically do some simple building. How do we validate that idea? We build something, we validate it, we process it. So, in this case, in this example, we build some really low-fidelity screenshots. So, before even writing a single line of code, you have to validate that idea. So, basically, we start by drawing some simple screenshots, show them to customers. So, a bunch of people at Starbucks, it's just valid, it's just invalid. This is about validating the idea. Before you write a single line of code, so it's about checking whether customers really do want this. After that, once you realize whether it's a valid hypothesis or invalid hypothesis, you go back and repeat by creating higher-fidelity screenshots until you come up with a proper working product. MVP, do you guys know what MVP is? No, MVP. MVP, yeah, basketball MVP, yes. But MVP also stands for minimum viable product. The minimum features that you have in a product for users to fully experience your application or your software, right? So, that's what a minimum viable product is. So, in Lean Startup, it's about not building out the whole shebang of features, the whole kitchen sink of stuff, but it's about finding out what is the minimum set of features that will help users experience your application, they'll delight them, and maybe get them to buy more things on your website or even use your application more often, right? So, building Lean is basically about pretty much about asking the right questions, asking questions, being willing to ask questions, not just of yourself, but also of your colleagues, of customers and everyone around you, even your employer eventually. Why are you building this? What hypothesis are we trying to prove here? Is this really what customers really want, right? You will, to people that you talk to may not always be responsive. So, a lot of this is about finding out, getting data and showing evidence that whether this is the right thing to do or not, right? So, building Lean is pretty much about gathering information to support your ideas. So, in Single Power, we also believe in building Lean. So, we also want to do customer surveys, find out whether what we're building is really what users want. When we're building, for example, an application we're building right now, instead of releasing it to the entire Singapore population, we decided to just start releasing it only to the people in our office. So, we built a mobile app that does some transactional things, and instead of releasing it to the entire world, we're releasing it just to people in our company. From there, we slowly get feedback before we look at and then we get feedback and find out what are the right things to build, what's the next step that we need to do. For example, in our original hypothesis, we think that customers probably don't want to change the password once they're logged in. They don't need to, right? But we feel that there may still be a need. So, we built the password-changing interface as a web application rather than being in the app. So, we have an administrator, which will sit with the customer and say, oh, you want to change the password? Yes, I'll change the password for you right now. But once we release the app, the people in our office start coming to us, hey, I came the wrong password. Can I change it right now? And it feels like there's a lot of them having the same problem. So, we realized, hey, actually, we do need that feature in the app, right? So, had we released this to the entire world, we'd probably get one-star or zero-star rating on the App Store, which would have a great experience for us, right? So, slowly validating your idea and slowly expanding and making a more sophisticated product. That's pretty much what Building Lean is about. So, having an idea, build it, write the code, measure, getting measurements about what users are actually using this product. Users are actually using this feature. So, in the feature that I wrote for MakeMe, we were kind of, okay, for a registration page that I built for MakeMe, we wanted to break down the sign-up form into either one page or two pages. Basically, the first page, we asked them to keep their email address, then the second page, we asked them to keep their password. So, we did an A-B testing. Is it true that users, to reduce sign-up friction, sign-up friction is about how fast you want to get into the app, how fast you want to sign-up into the app and experience your application. So, we wanted to reduce sign-up friction. So, basically, the hypothesis was if a user see four or five views on the same screen, do you feel paralyzed? Oh, my God. Do I have to give you my email address? I will give you this thing and that thing? We feel that maybe that could be a problem. Let's try to break it down into two pages. That was our hypothesis. So, we wrote the code and we did A-B testing. So, basically, we have, based on 50% of the user population signing up, we gave them a one-screen page which has four views there. Email address, mobile phone, and password and verified password. On the B side, we did one page where we just had their email address and mobile, and then the password was actually in the second screen. So, it released it and we started getting data. Basically, we had a log file, basically. Very simple. We had a log file that was accounting. How many of you were hitting page one? How many of you were using page two? And you were completing the sign-up process. And the feedback we found was that users prefer a single-page sign-up rather than a two-page sign-up. And for us, we were puzzled. We thought having two pages would reduce the sign-up friction. But the truth was, users were actually logging into our website on a mobile device. So, for me, it was actually mainly in third-world countries where the network was really slow. And a lot of them were still using no-care phones. No-care phones and logging in. The network was really slow. So, for them to load one page after another was a hassle. And then because on a no-care phone, navigating using a keyboard and the joystick wasn't a very pleasant experience. So, from there, we drew the hypothesis and our hypothesis that users prefer two screens was invalidated. So, we switched back to one single form. So, having data will help us measure and realize what are the right things to build and whether it is... Data will help reinforce what our hypothesis is true or false, right? So, I talk about building things, building the right things. But we also want to make sure our process is in line with how our process is set up in a way that helps us build software effectively. It's not just being effective, but also being sustainable. If you realize that if you're in a startup working long hours, you may end up getting burnt out. So, we really want a process which is sustainable which helps you retain and maintain your passion for coding and to continuously improve yourself and to continuously find strength in getting things done. So, first of all, building it right. Building software is a team sport. I'm sure you guys are working on projects right now. Is it a team project or is it an individual project? It's a team project, right? Cool. So, building software, in a way, it's not like one person doing a brilliant 10x engineer can probably do it himself if he wants to, but you probably don't have enough sleep and drink a lot of caffeinated drinks and probably burn out after two months. But being in a team helps us spread out the burden and basically the stress levels. So, building software is a team sport. It's not just about you as a developer but also there are other stakeholders as well, like business owners, product owners, customers, other developers, even investors and so on and so forth. There are Forbes people, people who buy you coffee and stuff. No, wait, that's not... That's also true. But still, do you understand the difference between a business owner and a product owner? No? Yes? No? Okay. So, in a company, the business owner is usually the CEO, the person who owns the company so that he owns the business, right? But a company may not have just one product, right? So, they may have like a utilities app, they may have a web application that has the same features, you may have a payment app somewhere, right? You may have other things that is going on. So, a business owner owns a business. The product owner is basically the guy who is in charge of that particular product that's going out, right? A mobile product that's going out here and stuff like that. So, a product owner is closer to the team, working closer to the team and he is like the man or person that has the final say about what goes into the next iteration of the application, right? So, that's the product owner. In this situation where as a team, communication is really key, we want to make sure that everyone understands and understands why and what we are building. And sometimes, as a team, we also have to agree on your practices. What time are we meeting? How often do we meet? How do we agree on the priorities of stories, user stories and features that needs to be built? Stuff like that. So, communication is really key. And in this case, working as a team is much better than working on your own. And I will share with you four practices that I felt that has worked for us as Singapore Power, even myself as working as a consultant in other companies. These are the four practices that I felt that has worked in helping us build things the right way. First of all, it's about building, design and build just for right now, having automated tests, YAKNI, I'll tell you what that is later, clear public issues early and get faster feedback on features. So, number one, about design, design and build for right now. So, engineers, being engineers, have tendency to over-engineer things. Do you guys do that too? Yes, yeah. Oh, I got to think about this feature. Why do users do it this way? Why do users do it one that particular feature? What if? Why if? But the truth is, future-proofing and considering all the possible use cases is actually wasteful. Because you're just thinking about how users may use the product without actually validating that really to answer what the users want. So, basically what we want to do is build for right now. What you feel will be the easiest way to get things done and get users experiencing your application or your software. In a way, we also have this problem of the unholy trinity of better, faster, cheaper. IPI-TIO. Right? So, sometimes your customer wants things better, but they're not willing to pay for it. And they want it faster. Not going to happen. So, let me show you a little graph here. So, for clients who want it all, they want better or good, they want it cheap, they want it fast. So, if it's built fast and cheap, it's probably a low-quality product. If they want it good and cheap, it's probably going to take some time. It will be good, but it will take some time. And usually, if you want things to be done faster, it's usually more expensive. So, usually we want to keep ourselves within this zone or this zone. So, this one is a little bit not possible. Those are unicorns. You can find those companies that will give you time, give all the money, and make sure you build stuff well. Those are unicorn companies that you stick with them. I've not found one yet. So, basically, as a consultant, back in Pivotal Labs, Pivotal Labs is known for not being cheap. We're not the cheapest consultancy around, but we build good software. And we build it fairly fast. So, basically, Pivotal Labs and even new innovation was in this zone. When customers come to us and tell you, you've got to pay this amount first, then we'll talk about this. But sometimes working in a company like Singapore Power, it's really not just about... We want to build things well. Fast is sometimes a negotiable concept. We do have milestones to reach. And then being cheap, I don't think we're cheap. Well, internet, I don't know. Anyway, you understand what I'm saying? Yeah, anyway. So, better, faster, cheaper. So, it's about finding out where your customers are most comfortable with. Yeah. So, if the situation is that you are as a startup, because I've worked in quite a few startups in the past, I'll just give you an example of a startup. In a startup, when you just first get funding, you have a limited runway.  Like, say, a company gets half a million dollars. And that will last you for about a year. You talk about renting an office, paying for a couple of engineers and marketing people and sales and whatnot. When you want to get funding, that money will probably last you an X amount of days, depending on how frugal you are and how well you pay your engineers and how much you invest in hardware and all that stuff. So, when you have a limited runway, which means you have a limited budget, and you really want to get as much traction as possible in your application, basically get as many people using your app. So, once you have users using your app, you can then get to the next level, which is to get more funding, tell more investors, invest more money in us, or you move the other way, which is to start charging your customers and get some money from them. So, essentially, in a startup, your timeline is very compressed because you really want to deliver value at the shortest possible time. So, you really want things to be done fast. Cost-wise, there's a limited budget that's X dollars, and you have to get it done anyway. So, the concept of being better is sometimes... how good you want it. It's sometimes a negotiable concept that you can talk with amongst your team and say, how much do we need to have all these features right now? No, let's pare it down. I remember when we were in Fountain, we did the first pitch to get our first half million dollars for Fountain.  He had a kitchen sink of ideas, all users can do this, can do that, can do this. But when he realized that, look, we need to make a pitch and we need to get investors for our first seed fund. And we need to show them some slides. For him, there was a very clarifying moment where he said, look, I think we need to just start shaving away stuff. What is the core user experience? What is the core set of features that will help users experience the application the best way that we can? So from then, he just started throwing away features. I don't need this right now. I don't need this right now. Let's just focus on what needs to be done right now. And he came up with a very beautiful set of slides. He just shows the core features. And with that PowerPoint slides, he basically got $500 million in funding, which is kind of cool. Yeah. So, right, building for right now is... So you have to build also... not just focus on building it for right now, but also as a software engineer, we also want to make sure that it's easy for us to make changes in the past, in the future. We have to build it in such a way that it doesn't make it too expensive to make changes. Think about legacy code. Code has been written a long time ago. It's going to be harder to change. Why? Because maybe it was written in such a way that it wasn't easy to make changes. It was built for a certain purpose, but it wasn't built in such a way that it makes it easy to make changes in the future. Object-oriented programming helps you think about code in a way that is composable. Design patterns that you will learn in this course eventually will probably help you in designing a code in a way that will make it extendable and make your code cheaper to change. And that's important in your startup, right? Because you want to build in such a way that it's not... like, make me, for example, I'll give you a sort of example of make me. Make me, it was a chat application, and it relies on a bunch of Java servlets in the background just to make sure that we can do chat and it's super reliable. But it was built in such a way that it was very inflexible to make changes and whenever we need to add a new feature, it takes months for the guys to just roll out that feature, which is terrible. If you're in a startup which only has one year of worth of money, three months is a long time, right? So yeah, building it in such a way that it's easy to make changes in the future, that's crucial, right? Of course, don't overthink it because overthink it means oh, we should cater for these future possibilities, these future possibilities. Well, it's balanced. Finding out how much to do that, how much to work on is balanced. So that's about designing for a building for right now. Only testing. How many of you guys actually write unit tests? Do you even know what a unit test is? Okay. Sorry. Preview. So how do you test an application right now when you write your code? How do you test it? How do you check that it actually works? Very simply. Test cases. Test cases, okay. So yeah, those test cases being what? Just users should be able to do this, users should be able to do that and you just manually click through. Yeah, okay. So that's manual testing. So in agile, we actually value rapid feedback. Yeah, agile is... Jesus Christ. Okay, let's talk about this. Okay, agile movement. There's a whole thing. When I talk about agile manifesto, there's a bunch of guys that just felt that there has to be a better way to write software. And the whole movement is called agile movement. Again, it's a buzzword. I don't really care about it, but it's more like, this is pretty much how we feel is the best way to write software right now. With agile being quick, being responsive to change in the business world, because you want to make sure that your code is written in such a way that it can respond quickly when a user or a customer has a certain need. In the traditional SDLC software, Diverm Life Cycle, as we always talk about, it has a waterfall methodology which asks you to come up with a specification early and a giant manual of software specifications that you take years to write the software before that software actually sees a lot of data. A lot of government applications right now, what you see on the website, any of the government websites takes years to build. Even applications in Singapore Power takes years to build because they follow the old way of doing things. But what we want to do is, we want to make sure, but the problem with writing software that way is that by the time your software is released to the public or the customers, the customers may already have changed their mind. I don't really want this feature at all. So being responsive, being able to change quickly to respond to market changes, customer changes, and customer requirements, that's crucial. So that's the whole agile movement, how it came about because we want to write software that is more responsive and more useful and we want to validate ideas quickly. But in doing that, we also want rapid feedback. Basically, we want to make sure that when we write a piece of code, for example, we want to make sure that code is actually working. We can always test it manually but sometimes it's not possible to test that code manually because you have not built that web interface yet. You have a piece of code that's here, very far away, talking to your database and your web interface is over here or your mobile app is over here, which you have not written, your API is here, your mobile app is here, your mobile app is not ready yet. How do you test that API? So you can use tools that could poke your API server or you can go even lower by writing unit tests. Unit tests are basically programming code, code that will actually verify your production code. I think next week, you guys will go into that. So preview. Anyway, we also hate repetitive tasks.  Oh, no, there's a bug in this piece of code. And then you write your code and go back and open the browser again. And it's very manual. So that's manual testing. So we don't like that. I don't like that. So what automated testing is about, really about is about writing code and having software that runs that will actually verify your production code.  And it would do it such a way that you would run, you can either run an individual test or you can run an entire suite of tests. So basically, give an example. You were building a web application and you want users to sign up. So you want to be able to, users should be able to go to the homepage, click on register, fill up the registration form, click submit, receive an email, and have my account created. And I should find myself on the landing page saying, welcome Michael Cheng. So this entire sequence of events has to happen. If you're writing that software, you're writing that software, you want to do the testing manually, means you have to open a browser, do this, do that, do this, do that. And then before you actually, and you have checked your database, is this record there? And there was a bug somewhere in between. You got to go back and repeat the process again. So that's about repetitive tests. And all that can be automated because there's software that can actually open a browser in the background, do all that clicking, and then the software can even check your database and say, is this record in the database right now? Is this the easier email address in the database? The same as what you're keyed in in the registration form. So automated testing is basically about, is basically having software that verifies your code and it runs in a automated fashion.  Yes? So by automation you mean that this process is automated but the scripts are still written by a human? Of course, of course. That's not written by a robot. That's not written by a bot. It's written by you as a developer. So in writing automated tests you also have to write your test yourself, right? Because you know this is the code that you're going to write and this is the code and this is how I want the code to be tested. Something that also... And when we do this, the whole process of writing tests, writing the production code and it's what we call test-driven development, TDD. Where is it? Is it here? No, I didn't put it here. Okay, fine. So it's about test-driven development. So you use your tests to drive the design of your code, right? So for example, my first example of user registration and user sign up. So the first step is to actually launch the browser. Go to the home page. So if I go to the home page, what should I see? The home page I should see the button called register. So you write your test. Your test will say, visit http example.com. I expect the word register to be on that page. Once that assumption is true, that goes to the next step. Click on register, which will actually automate the browser. The browser will actually open up, find the text, click on it, and go to the next screen. And then you can write the next step in the test will be, I should now reach register.php, right? And from the register.php, I should find the fields. First name, last name, password, email, and you fill all those in as well. So you're writing code that actually describes the behavior, how your code should behave. And then you run your tests, you will fail, because you have not written the production code yet, right? So what happens next, then you start writing your code. So you first write the test, which would then fail, because your production code is not written yet. The page is not there yet, right? So once you write the code, you write the simple page, you load the index.html, you include the hyperlink that says register, then you create a new page called register.php, where you have a form field there and all that stuff. That's when your code starts to go green, because it's now passing, your code is behaving in a way that you expected to, right? But it doesn't stop there. Why does it not stop there? Why does it not stop there? You can write more tests, yes. But there's another step that you could take, and that is to refactoring your code. Do you guys understand what, do you guys know what refactoring is? Okay, good, I see one not linked here. So refactoring the code is basically about going into the, going back into it. Okay, so when you wrote the production code, we have this belief in agile that we just write the minimum amount of code to get things to work, right? We don't have to, it's in line with not overthinking things, not over-engineering things. Just focus on writing the minimum piece of code to get your test to pass. So you just write four lines of code here, four lines of code here, run your test. It's passing, hooray! But there are some situations you have not taken care of yet, for example.  You have copied a bunch of functions from another shared library into this, just to make sure it works. So you may have taken a lot of shortcuts in between, right?  Have I been copying and pasting stuff? Or could this function be broken down into smaller functions? Because I want code to be more readable. Once I look at the function name, I can understand what this function does, right? It's about revisiting your code and finding out what are the ways that I can make this code better, right? So that's refactoring. So this whole cycle of red-green refactor is basically what TDD is about, using your tests to drive your code. So when you have tests, like say, for example, about the registration form, right? Once you have the test there, right, it gives you a lot more confidence when I go back to my code and basically move things around. I throw away this piece of code here because that function is available in another file and it's loaded in the header, right? Throw away this piece. Okay, I can use this one, but I should refactor this to break it down into a small function here. I should add one variable here and stuff like that. The biggest fear for any software engineer is that when you make some changes and your entire software breaks, right? It was working before. Why is it not working now? So how do you verify it? How do you protect yourself from this test? Because you have code that checks your behavior of your application. So when you make a lot of changes, when your test is passing, good. You will make a lot of changes and something broke.  I've introduced a bug somewhere. Let's see what have I done. Oh, okay, it was this line of code. I forgot to put at the semicolon at the end. Simple stuff, right? Yeah. So, and you use your tests. Your test is basically your safety net that helps you make sure that your code actually works the way that it is supposed to work. So your test is there. You write your code, you refactor, basically revisiting your code and finding out how to make it better. And then you repeat the process by writing the next step in the test, right? So test also helps us clean up, refactor our code with more confidence. You also guard against regression bugs. Regression bugs are basically, I make some changes here. And then some other feature down in another part of the application is breaking.  Because you have tests that protects you, that checks that piece of code. Your changes here may have introduced a bug. If you did not have tests, you would not have known that the other file would have been broken, right? So everything tests helps you protect your whole application and also makes your customer a bit more confident in your capabilities, right? I've had this experience working on some code during a hackathon.  And I'm working on a piece of code at 2 o'clock in the morning. I was so tired. But because I have tests, I don't need to think so much. I don't need to worry about writing code that could have broken something. So I was like, oh wait, I introduced a bug. Oh, the test told me where which line was broken. Right, I can fix that right now. And I can focus my energies on writing the feature. For even very simple things, when you're tired, having tests that says, oh, my function takes in this input. It should give me this output, right? And when you're tired, you don't want to worry about, oh, how should I organize this? No, you have tests that tells you your code should behave this way. You just, in whatever capacity you have left in your awareness, you can just write your code in a way that, at least your test will help you verify that your code is working. Does it make sense? Okay. Have I lost anyone yet? Are we all okay? Okay. So this again is the cycle. The rate, which means your test is failing. We are not reading your code yet. It goes green when you make the code work. And refracting is about things like eliminating redundancy, polishing up the design of a code, and so forth. Making your variables sound more understandable, and not just A, B, C, but user name, email, rather. Okay. So that's about rate green refactor. So when you learn about TDD next week, you probably will know more about this. A bit more about automated testing. So how much testing should I write? So I talk about having a lot of tests will help you have a safe, have peace of mind over your code. We have this concept called test coverage. How many percentage of your production code, in terms of lines of code, is being covered by your test? So you have a piece of code that exercises function A and function B, but there's an if-else statement there. Your code only tests the if part and not the else part. Means there is a piece of code, there's a few lines of code in your production code that's not tested. So what do you do? You could actually write another test, then you could check the elf segment. So that could be it.  But 100% test coverage is not a very nice thing. It's not a desirable concept. It's good to have 100%. It looks nice. It's a vanity matrix. A vanity matrix means it looks pretty. 100% looks pretty. High score looks pretty. But it can be a pain to maintain because you need to write more tests. It can be a pain to maintain. And again, 100% test coverage doesn't mean your code is bug-free. Even though you have actually exercised every single line of code in your production code through your test, it does not mean your application is bug-free. Why? Another discover bug is actually a test you have not written yet. Because your application is an object-oriented application, based on different inputs, you may have different behaviours. Right? And when your application reaches what we call user-land, when users start using your application, you use it in certain way. I was not expecting you to key in exclamation mark in the comments field because I have a wide list of all of text. Only alphabets numbers are allowed. Exclamation mark is not allowed at all in my comment field, which actually did happen. In the application I'm working on now. So I was like, oh, nicely, I can write a comment there. I put exclamation mark. Oh, it doesn't work. In another application that we have with SP, it doesn't take emojis. You key in an emoji, it crashes the server, unfortunately. But yeah, so a bug is basically a test you have not written yet, right? So even if you have to present text coverage, it doesn't mean that you have no bug. So how do you guard against this? To guard against this is as a team, you do what we call code reviews. Basically, you help each other look at each other's code. There are also other things called code scanners. Can you guys help with this website called Code Climate? You can open your browser, go to the website, codeclimate.com. This is actually a website that actually scans your code by doing stuff like running your unit tests, doing code standard checks on your code. It tells you that, oh, wait, you've done a lot of copy pasting in your code. It even highlights you, the lines of code that you have copy pasted from other parts of your application.  I think even Java has code scanners. Static file analysis, which could help you check all these things. So Bombline is investing time in preparing a test suite. It's actually good. I'm not saying it's easy to write tests because as a person who is not used to writing tests, your productivity will drop by up to 70% even when you write tests. In the first few weeks, because you're not used to writing tests at all, but once you get a hang of it, it will become second nature to you. So once you've gotten that muscle memory into your... For me right now, when I look at a piece of code and it's not tested, I get jitters.   You have to automate testing in some way to help you a lot. And in testing, we also have this concept of a test pyramid. So I talk about how unit tests are automated testing and TDD can help you in designing your code. I've talked about code coverage as in test coverage, how much or how many percent of your lines of code are being tested and exercised. But here, the code, the test pyramid talks about the type of tests that you should have in your test suite. So early on, I talked about the browser, opening the browser, clicking on the button, going to some place and all that stuff. That's a UI test. In other places, they call this an integration test. So it basically integrates an entire piece of your application from end to end. And those unit tests are actually quite slow. Or rather, those UI tests are actually quite slow because it has to open up a browser, it has to load a web server, it has to load this other thing and this other thing. So those takes a long time. Those are very effective, but it takes a long time to run. And in agile, we value rapid feedback. If basically we want as fast as we can, know whether our code is actually working or not. So we basically go all the way down to the unit tests.  Does it actually behave in a certain way? If I give in 1 plus 1, does it give me 2? It's as simple as that. A functional unit test is as simple as that.  And those tests usually run really fast. And leave your UI tests to keep your UI tests an integration test to the minimum. Basically, automation testing of a browser and all that stuff. Keep it minimum because those things take a long time to run. Third, Yagney. What does Yagney mean? You ain't gonna need it right now. So it comes back to that whole concept of building for right now. Sometimes building lean means you have to make some compromises on your grand vision until it's validated. So you may have the idea of, oh, my application should do this, do that, do this. But you may not be ready for that yet. Your users may not be ready for that yet. So sometimes I keep asking myself, or even ask the product owner, do we actually need this? Will the product suffer from the lack of this feature? Will the user experience be any less delightful? If the answer is no, you probably don't need that feature. Let's build that. We saw that not build that feature. It's more like we don't need that feature right now. Let's keep that idea somewhere. When we come back to that idea, maybe when we have more users or when we have more time. So we limited time and limited runway in terms of funds. This is, again, a start-up situation. You want to build traction of your software, but you have to prioritize. Priority of how much time you want to invest in this. Am I almost out of time? Oh, dear.  Next one, we have clear plumbing issues. Basically, try to remove blockers for rapid feedback. Basically, make sure you've got your project management tool set up properly, version control, continuous integration, all that stuff. All bus routes again. But you will understand what they are. They're pretty cool. OK. Make sure these things are done before you even start writing a single line of code. That will help you in making it really, really smooth and easy to get things done. So I talk about building things, building the right things, building the right things, and building things right. We also want to talk about how you should do it in a sustainable manner. Because the last thing we want is always for our engineers to burn out. So basically, it's about reflecting, evaluating, and growing together. So keep learning from each other. Don't be shy about learning from each other. And keep sharing and building knowledge as a team. So here's what we actually do at Signal Power. We do a flavor of agile code extreme programming. So we can Google this later and find out what it is. So in Signal Power, what we usually do when we start a project, we have a project kickoff and scoping session where we get everyone on the same page. So an example would be this. Everyone would be putting up stickies on the board and say, what is our product goal? What is our business goal? What are the things that we don't care about? Right. And then we come up with user stories. Basically, user stories are basically in a single card. It describes what a user should be able to do. A single task that the user can do on the website. So we have a whole bunch of this that we've put together. This is for an actual project we're working on right now. So once we have that scoping, we do what we call iteration planning meeting. So on a weekly basis, we check in with each other. We check in with the product owner and say, are we on the track? Are we building the things the right way? The right things that we need to do right now. And we use a tool called Pivotal Tracker. So if you have not seen this before, it's basically agile tool that lets you manage your projects. So all the cards you see are there on. All those cards here. Each card will translate into one story like this. So iOS open account to include a message of SD, whatever. App crashes. This is a bug, for example. This is a feature, email. As a user, I should receive a payment, receive as a text-based email. So this is a story, right? So we have a bunch of all these stories here in the current and the backlog. The backlog will be things that will happen the next week. And we have this thing called Icebox. This is where we talk about Yagney. You ain't going to need it now. Why are we going to put this inside here? It's called the Icebox. If we put it there, we kind of revisit it later on. And we have daily set ups where every day we will have, we'll basically talk about, we'll have a daily check-in with each other as a team. We'll talk about progress. We'll talk about blockers. So this is what we do. And once the code is done, we release it. And we use continuous integration and continuous deployment to get things out into production. And every few weeks, we'll do this thing called Retrospective. Retrospective is basically a time where we come together as a team and talk about what went right, what went wrong. So this is how what we usually do. We have a smart way of a retrospective board where we talk about what we have a smart way of talking about all the happy things that happened and a sad face talk about all the sad things that happened in the past few weeks. And the stuff in the middle, I'm kind of like, eh, I'm not too sure whether it's good or bad. But yeah. Of course, writing code is important. As developers, we pick up a story on Pivotal Tracker, which I've shown you earlier. We do TDD. We do pair programming. I'll show you a photo of that later. There are many ways to do pair programming. One is called a navigator, driver navigator, tester coder or pilot co-pilot. I don't have much time to go into this, but go figure it out. Comet and Push, we do Comet and Push to GitHub. It triggers a continuous integration on Jenkins which will test our code, integrate all the code of everyone's code. And we also do pull requests. Have you guys heard of know what pull request is? Okay. And once a pull request is accepted, it triggers a deployment into production or rather into the QA environment. This is an example of us doing pair programming. This is an example of us doing what we call mob programming as a mob. So four sets of keyboard are writing stuff on one person's screen, pretty cool. Different team roles. We have developers, coders and devops, team lead product owner. In a larger team, we also have other things like business analysts and so on and so forth. So yeah, this is usually how it is on a bigger team. So what's next for you? I hope you guys get involved in the community. Nikil and I were kind of like involved in the community as well. Go check out meetup.com, Facebook groups. There's this website called We Build the SG. I want you guys to check it out. There's a whole bunch of stuff there. Meet your peers. It's a place where you can share knowledge. You can participate in open source projects. You know, We Build the SG. Check this out. There's a whole bunch of events there. Engineers at SG is a website I run. So basically we have videos of all the tech talks happening around Singapore. Check it out. CopyJS, you won't be so sure. This is where you come to meet people and have coffee and talk about stuff. I also want you guys to hang out with us. Meet your peers. Meet your future colleagues. Meet your future employers and all that stuff. This is something I run every six months. It's called Geekbrunch SG. So basically we hang out in this place called Willers Yard. And we have coffee and we meet a lot of people. The last one we had, this is the photo of all the attendees, about 100 people. All engineers, most of engineers. So you read a lot of cool folks. Questions? No? Okay. Yeah. So you want to revisit my slide? Sorry, I went to the last few slides quite fast. You can download it at Speaker Deck. That's me again. And yeah, we're hiring. Okay. That's it. Anyway, you can email me if you have any questions or add mention me on Twitter. Yeah, if you have any questions.


What happens when you combine the region's best network with a plan that requires no money down on the phone you choose, but also allows you to upgrade to the latest and greatest phone quicker than the traditional contract? You get the Appalachian Advantage, better service and bigger savings. Full payment plan requires historical details. Advantage requires no money down, taxes do a time of sale. The Pied County Board of Education has decided with the funds that we raise through the Facebook fundraiser and through the insorted donations that they're going to give out college scholarships to students that have two different amounts of $250 scholarship, they're wanting to encourage people once you've graduated high school to continue your education. And so that's what scholarship is supposed to fund. My late father was Russell Johnson Jr. and he was a Pied County School Board member of District 1 years ago. And I guess back then that's what got me I guess involved because my dad was always into community service. And I think having this scholarship really touches my heart because my dad and his involvement in the school system and for the kids. So yeah, it's really something that was unexpected that I didn't know anything about until the representative from the Pied County School Board approached me with it and I mean it's just a complete honor. And I couldn't do it without the help of the community and all the people who contributed and we're doing it. It's going to be a year-round thing just something to help these kids give them something money to help with education they probably couldn't have had before.


Ready to have some fun day 15 and still symptom-free which means when I started this little project. I did not have the rona That's right. I've been at this for two weeks to my tens of subscribers. Thank you for being here And speaking of the rona my forced unemployment has been extended until April 30th. Yay More tales from the liquor wall.  This is a bottle of benedictine I got at a liquor store that was going out of business in Glendale Benedictine is an herbal French liqueur and this bottle was hiding in the back covered in dust It does not have a barcode, but after asking around I don't think it's super old Even though it looks like it was recovered from a sunken ship. It's probably from the 90s Maybe the 80s if I'm wrong light me up in the comments They don't make them like they used to I couldn't get the foil off the cap of that bottle So instead I'll be pouring from this bottle which I got from the same shop that isn't quite as old What's this called again Bob? That's right. I have had benedictine before it's sweet and herbaceous, so I have a baseline of what this might taste like Benedictine second attempt cheers Herbs come through sweetness comes through Let's try this out. I actually like this more than Benedictine I've had recently. This is way more herbaceous. This is a lot closer to a proper bitter Benedictine now This tastes like honey macerated with herbs. This is actually quite funky. I don't know how much of that is attributed to the age I know that light and oxygen can wreak havoc on old liqueurs, and it does have burn Apologies for the other bottle not working out. I don't always plan these videos ahead Anyway, if you enjoyed it, please share with your friends stay safe all the vice professionals, and I will see you tomorrow. Cheers


Monthly dividends What's up money geeks mr. V here welcome to another video guys so in today's video when you take a look at five Reads that pay a monthly dividends I do like talking a lot about dividend paying stocks But then when you go from just not just paying quarterly dividends to paying a monthly dividends That's where you're talking about that passive income So one group of stocks Really really like a rate and the reason why I love them is because they are required by law to actually distribute at least 90% of your taxable income back to their shareholders annually so when you put your money in there invest and if those Companies are doing the stocks are doing great, you know for sure that you're gonna be getting that monthly dividends back to you So that's why I like them so before we get started guys If you're new to the channel will talk about how to earn money how to save money how to invest and build Worth if that's something that really interests you go ahead and hit that subscribe button any notification bell to you don't miss out on New content and also just hitting the like button does help us here on YouTube rank Because that's what YouTube wants. So let's jump on the computer and go through my top five reads that pay a monthly dividends Come on. So here we go top five reads that pay monthly dividends again I love me some dividends So first one on the list is ticker symbol. Oh So this is a company that pays monthly dividends And if you look at most people that invest in dividends Paying stocks from a real estate standpoint most people would have all in your portfolio. So As to when I was doing this video dividend heel is five point three two percent The share price was about forty nine dollars and sixty eight cents in annual dividends It was about two dollars and seventy nine cents. So again, like I said, oh is one of those Dividend paying stocks that most people that are looking for maybe a position in real estate Would probably jump in and input in their portfolio. So let's move over to number two Number two here a ticket symbol CLDT Dividend heel of about twenty point five nine percent share price is About six dollars and sixty one cents as to when I was making this video an annual dividend is about a dollar 32 so I mean the share price is not super high. So for people that are on low income If you cannot afford to get into oh, this would be a good one to get in case of just the share price itself, which is great Number three on my list here is ticket symbol EPR Dividend heel of sixteen point four zero share price is twenty nine point two eight as to when I was doing this video And then annual dividends is four dollars and fifty nine cents So, yeah, but just another one and just for for transparency guys I do have all in my portfolio and EPR in my portfolio as well. So This is another one and again if you look at the dividend heels for most of these Just read is really high because those guys are they are required by a lot to actually distribute at least 90% of the taxable income back to your Shareholders, so let's move to number four number four ticket symbol LTC LTC property ink Dividend heel of a six point four one Share prices when I was recording this video was thirty five dollars and eight cents an annual dividend of two dollars and twenty eight cents So another great candidate again LTC would make the list of most people that are looking to get into the real estate dividend portfolio, so definitely check them out and finally is ticket symbol ST AG Stacked in industry or so dividend yield of five point seven four percent share prices when I was doing this video is twenty five dollars and 23 cents and annual dividend is a dollar or forty four I did have stacked in my portfolio prior to the crash but I've since then Sold them because before the crash I had it had gone up So I sold them and then when the crash happened. I actually load up on some other stuff. So Just a transparency again guys. I currently don't have ST AG in my portfolio. So So there you go guys these are these are there dividend paying stocks Reads that I have and again the beauty about this guys is that you make your monthly No, you get your monthly dividends from the stocks others companies do pay quarterly dividends It could be had sitting around waiting for those dividends to roll in quarterly So if you can make a monthly it makes it even better So definitely check them out and just let me know what you think about the list If you have some other ones that are even better Don't hesitate to drop them in the comment section and just kind of share with the community because again I'm not gonna sit here and pretend that I know everything I can do as much research at one But I'm not sure be able to to know every single one that there is out there So those are my top five that you pay monthly dividends. So as you can see guys Having a monthly dividend come in is a very good way of Endings on passive income and again, you can look at it from this perspective when you invest in these companies What you get is hopefully you bought at a very low price You get growth as those companies continue to do good and then and on the flip side You're getting this passive income for most people what you do is you follow the drip methodology Which is that you reinvest those dividends so that it keeps growing and then you if you plan on stat We're drawing that money. Maybe when you retire, that would be a good place to be So those are my top five again if you have any questions regarding what I have on my list Don't hesitate to drop them in the comment section If you have any recommendation as well, hey always share with us in the comment section If you're new to the channel, we talk about how to earn money how to save money how to invest and build wealth So if that's something that really interests you don't hesitate to hit that subscribe button And the notification bell and that's always guys Stay motivated


Hello and welcome to the session. In this session we will discuss how to graph square root and cube root functions. First of all we shall discuss graph of square root functions a function of the type f of x is equal to square root of x is called square root function the domain of this function is set of all positive real numbers and zero because square root of a negative number is not a real number. Now let's discuss graph of square root functions. For this we consider an example. Here we have to graph the function f of x is equal to square root of x minus 2. First of all let us find the domain of the square root function such that expression under the square root must be positive or zero. So x minus 2 should be greater than or equal to zero which implies that x is greater than or equal to 2. So we say that domain is the set of all x greater than or equal to 2 where x belongs to the set of real numbers. Now we make table of values for the given function. We put x values greater than or equal to 2. In this table in the first column we have taken x values which are greater than or equal to 2. So we have taken 2, 3, 6 and 11. Now we shall find the values for f of x for the corresponding values of x. For x is equal to 2 f of x that is f of 2 will be equal to square root of 2 minus 2 that is equal to square root of 0 which is equal to 0. So for x is equal to 2 f of x is equal to 0. Similarly for x is equal to 3 f of x that is f of 3 will be equal to square root of 3 minus 2 that is equal to square root of 1 which is equal to 1. So for x is equal to 3 f of x is equal to 1. Similarly for x is equal to 6 f of x that is f of 6 will be equal to square root of 6 minus 2 that is equal to square root of 4 which is equal to 2. So for x is equal to 6 f of x is equal to 2. Similarly for x is equal to 11 f of x that is f of 11 will be equal to square root of 11 minus 2 that is equal to square root of 9 which is equal to 3. So for x is equal to 11 f of x is equal to 3. Now let us draw its graph. Here we have taken the x values along horizontal axis and the values of f of x along vertical axis. Now this is the graph of the function f of x is equal to square root of x minus 2. From the graph we can see that y takes values greater than or equal to 0. So range of the function will be equal to the semi-closed interval 0 to infinity. This is the required graph of the function f of x is equal to square root of x minus 2 where range is given by the semi-closed interval 0 to infinity and domain is the set of all x greater than or equal to 2 where x belongs to the set of real numbers. Now we shall discuss about graph of cube root functions. Cube root function f is defined by f of x is equal to cube root of x. The domain of this function is set of all real numbers and ranges set of all real numbers. Let us consider an example. We have to grab the function f of x is equal to cube root of x minus 3. Now we know that since it is a cube root function so its domain is set of all real numbers. Let us make its table of values. Now here in this table in the first column we have randomly taken values of x that is minus 5, 2, 3, 4 and 11. Now in the second and third column we shall find the values of x minus 3 and f of x for these corresponding values of x. So for x is equal to minus 5 x minus 3 will be minus 5 minus 3. That is minus 8. For x is equal to 2 x minus 3 is 2 minus 3 that is equal to minus 1. For x is equal to 3 x minus 3 will be 3 minus 3 that is equal to 0. For x is equal to 4 x minus 3 is equal to 4 minus 3 that is 1 and for x x is equal to 11, x minus 3 that is 11 minus 3 will be equal to 8. Now we shall calculate the values of f of x or y. Now for x minus 3 is equal to minus 8, y is equal to cube root of minus 8 which implies that y is equal to minus 2. Similarly for x minus 3 is equal to minus 1, y is equal to cube root of minus 1 which implies that y is equal to minus 1. Similarly we shall find the remaining values of y for the corresponding values of x minus 3 and we have found that for x minus 3 is equal to 0, y is equal to 0, for x minus 3 is equal to 1, y is equal to 1, for x minus 3 is equal to 8 the value of y is 2. So we say that for x is equal to minus 5, y is equal to minus 2, for x is equal to 2, y is equal to minus 1, for x is equal to 3, y is equal to 0, for x is equal to 4, y is equal to 1, and for x is equal to 11, y is equal to 2. Now we shall plot x and y values on the graph. Now we have plotted these values on the graph and then we have joined these points to form this curve and this is the required graph of the function f of x is equal to cube root of x minus 3 and from this graph we can see that range of this function is set of all real numbers. Thus in this session we have discussed how to graph square root and cube root functions. This completes our session. Hope you enjoyed this session.


That's right. Today we're going to be talking about the feud between James Charles and T-Spill. And we're going to use a unique blend of philosophy and psychology. So make sure that you stay tuned until the end of this video because I guarantee you'll leave a little bit smarter than you would with any other video about YouTube drama. What is up everybody? This is Chris from the Rewired Soul where we talk about the problem but focus on the solution. And if you're new to my channel, what I try to do is take different topics going on in the YouTube community, try to see what lessons we can learn from them to improve our own mental and emotional well-being. And some things that I really love are philosophy and psychology and just expanding my mind. So if you're into that stuff too, make sure you subscribe and ring that notification bell. And while you're at it, follow me on Instagram and Twitter at the Rewired Soul. All right. So yeah, some of y'all wondering what's going down. If you're not in the know, here's a quick recap. All right. So James Charles, as many people do know, he was recently in New York for New York Fashion Week. All right. And I guess Emma Chamberlain was in town too, and those two, you know, their buddies. And James Charles, I think like on a live stream, he just like slightly mentioned, just barely mentioned that he wasn't going to be hanging out with Emma Chamberlain. But when that happened, the drama channels jumped on it. They took this very tiny, tiny, seemingly insignificant thing and they made videos about it because that's what drama channels do. All right. So anyways, drama channel T Spill and James Charles, they ended up having this back and forth on Twitter. T Spill shares the video. Did James Charles really shade Emma Chamberlain? James Charles responds. No, he didn't, but he was shading someone else and realized in the moment that it was unnecessary, which is why he cleared it up, took responsibility and asked that drama channels didn't blow it out of proportion. Thanks for respecting that. T Spill replies. Sorry, I forgot I needed your permission before reporting on a story. James Charles says, you don't. It's not a story if it was already cleared up. And would it be that hard to respect someone's wishes for once? T Spill replies, for once, I've respected your wishes many times. There was nothing wrong with my video. I don't see you going in on anyone else who covered the story. So in this situation, who's right and who's wrong? Before we discuss that, we got to do a quick little crash course when it comes to philosophy and psychology.  It is different from person to person. It is different from culture to culture. It changes. So I'm reading this amazing book called The Righteous Mind and it's all about moral psychology and oh my god, it's probably my new favorite book. All right, so I'm going to link it down in the description below if you want to check it out. But anyways, it talks a lot about what's right and what's wrong. So in order to discuss this situation between T Spill and James Charles, and I'm also going to discuss some other drama channels later in this video, we're going to be talking about different kind of ethical philosophies. All right, specifically, we're going to be talking about deontology and utilitarianism. All right, so utilitarianism is pretty much a philosophy that was brought about by a man named Jeremy Betham. All right, so basically what utilitarianism is is when you're looking at your morals, when you're choosing between right and wrong, utilitarianism is you're looking at the greater good. All right, so they did some research and although they'll never know because Jeremy Betham died like in the 1800s, they've looked back at a lot of his notebooks and everything like that. And they actually believe that he may have been on the autism spectrum. So what you're looking at right now, this is a grid, it actually came from that book, The Righteous Mind. But most people, they lie on this spectrum of being an empathizer and a systemizer. All right, people who are empathetic, they're obviously, you know, thinking about other people's feelings and everything like that. Systemizers, they're more looking at numbers. Okay, so people believe that Jeremy Betham was on the autism spectrum because he was a very low empathizer but high systemizer. All right, and if you know anybody on the autism spectrum, many of them will also fall somewhere on the grid around this area, but many people who believe in utilitarianism, you know, ethics and morals and stuff like that, they'll be further along the lines of a systemizer as well. All right, so you may have heard of the trolley, the runaway trolley thought experiment. All right, there's a few different versions of it and things like that. But basically, let's say you have a switch, all right, and there's a runaway trolley, it is about to run over five people. All right, but if you pull that switch, it will run over one person. Those who have a utilitarian point of view, they're going to pull that switch, hit the one person because they're looking at net positive, the greater good. All right, one life to five lives. So now let's talk about deontological ethics. All right, so this is an excerpt from a post from Penn State and the Liberal Arts Department. All right, so it says deontological ethics is an ethics system that judges whether an action is right or wrong based on a moral code. Consequences of those actions are not taken into consideration. The ethics system is intended to be precise and by the book. Doing the right thing means to follow proper rules or behavior and by doing so promoting fairness and equality. All right, so to give you an example of this, you've probably heard, you know, that thing like would you steal or is it okay to steal a loaf of bread to feed your starving family? All right, somebody with deontological ethics would say no, it is never okay to steal. All right, regardless of the consequences like your family starving, it is never okay to steal. You never lie, you never steal, you never do anything like that, right? But those of us who are utilitarian, we will look at that and say, yeah, steal the bread, feed your family.  And like during the the trolley thought experiment, I don't know what somebody with deontological ethics would do. I think they just kind of throw their hands up and say it's never right to do anything that's going to harm another person. You know what I mean? But, but there's a problem with deontological ethics and another excerpt from that same post from Penn State, I think summarizes it quite well. It says, deontology works great in theory, but in the real world, it is challenging to comply with it. What happens when you have to choose between two evils? What happens when we can't be objective? What happens when the situation is not black and white? So in my opinion, having deontological ethics, it leaves you open to being a hypocrite more often than not, all right? Because it's based on your moral code. And where does our moral code come from? Some of them, some of us, it was taught to us by our parents. But what happens if our parents weren't good people, all right? So we have this strict code, but we might be doing more bad than good, all right? Or, for many of us, our morals are based on emotions.  So many people with deontological ethics are running off of emotion. So that allows them to be kind of wavering and a little hypocritical at times. So although I try to stay out of black and white thinking, utilitarianism is pretty black and white. But it varies from situation to situation. Because in one situation, the greater good might be this, in another situation, the greater good might be that. So who was right when it came to James Charles and Teaseville? Now, by now, you know that I have more of a utilitarian point of view. I'm hoping that you are deciding which one, which category you fall into. I believe Teaseville was correct, all right? Utilitarianism. She was looking at the greater good. She reports on stories regardless of one influencer getting upset about it. She is serving her audience, the greater good. But in this video, I actually want to discuss the bias and hypocrisy that's been getting called out a lot in the drama community lately. See, although Teaseville took the utilitarian stance on this one, many drama and commentary channels really have deontological points of view. So they switch their views all the time and it makes them look like hypocrites. For example, we can all pretty much agree that James Charles not hanging out with Emma Chamberlain and how small that clip was, it was pretty insignificant, all right? But many of the channels made videos that were X amount of minutes long. Some were even 10 minutes long, like the ones from Nick Snyder at the viewer's voice. So although James Charles did not want videos made about this subject, they were still made. So you would think that people like Teaseville or Nick Snyder were having more of a utilitarian point of view. But that's not the case. See, two weeks ago, on August 30th, something much different happened. And I want you to go check out the channel Australian commentary drama channel or Australian drama commentary channel, whatever it is, I'm going to link her channel down below. But anyways, she DM me and I saw this video and I thought this was really interesting. So those of you who missed it, Christie tweeted out, I always get told I look similar to at Jeffree Star. What do we think? I think we could be sisters. And Jeffree Star ended up replying and saying, I don't see any similarities to exclamation points. So somebody else tagged all of the drama channel saying, Hey, people turning over a new leaf and giving all the drama channels a clean slate. Can y'all pretty please link me to where, you know, one of these people covered the Jeffree Star drama from yesterday since they're not biased. And then they talk about, you know, this one where Jeffree Star kind of sassed that woman for saying she looked like him. All right. Well, anyways, Nick Snyder took it upon himself to retweet this person and say, can't make a video about our boss. Duh. Obviously a joke because there's an inside joke that the drama channels were being paid off by Jeffree Star and other influencers. Well, tea spill ends up replying and saying, wait, we're supposed to make a video because Jeffree replied to someone and said he didn't see any similarities in their appearance. How is that rude? And then Nick Snyder says the effing nerve. And then Dustin daily comes in, he says, I'm blocked, but I seen it. That dumb A has the most to say, like, I'm going to make a whole video about him saying he didn't see any similarities and then deleting it. This one here can true my draws. So going back, are they more utilitarian or do they have deontological ethics? I'd say more deontological because you can see they have a clear moral code, but it's not the one that you would think. See, they only serve the greater good when it aligns with their moral code, no matter how small the story is, kind of like James Charles and Emma Chamberlain, that whole situation. All right. But if they like the person, then that aligns with their moral code. So that story is too small for them to cover. Lastly, to point out the deontological ethics and hypocrisy, let's go back to this screenshot that we talked about in the beginning where James Charles says you don't. It's not a story if it was already cleared up and would it be that hard to respect someone's wishes? So if any of you have been around for a bit, you know, I got canceled earlier this year, or maybe you read my brand new book canceled inside YouTube cancel culture where I kind of discussed that situation in detail. But one of the biggest criticisms of me is that people have asked me not to make videos about them, but I did. Now, as you know, I have more of a utilitarian point of view. So if it's okay to make videos on one person who's in the public spotlight, it's okay to make videos on all people in the public spotlight, which I would imagine most commentary and drama channels are doing.  They only care about videos being made when it's about someone they like. But since most of them dislike James Charles, they have no problem making all the videos on earth about him. And as our good buddy Danny Gonzalez would say, like I said, I hope you're leaving this video just a little bit smarter, knowing a little bit more about moral psychology and philosophy. Again, check out that book, The Righteous Mind. It is amazing. If you like these types of videos where I like kind of take these drama situations and dive a little bit deeper and blend it in with psychology and philosophy, let me know down in the comments below, baby. All right. Anyways, that's all I got for this video. If you liked this video, please give it a thumbs up. If you're new, make sure you subscribe and ring that notification bell. And a huge, huge thank you to everybody supporting the channel over on Patreon. You are all amazing and a huge thank you to everybody who buys my merch and books and supports the channel in those ways. You're awesome too. All right. Thanks again for watching. I'll see you next time.


Felly yn ymddi David Howells. Felly mae'n gweithio'r byd? Felly yn ymddi David Howells. Mae'n ymddi'r Gweithgared Hat yn y 18 o'r ffordd sydd, yr ymddi'r ffordd sydd, yn cwp ymddi'r archi-tekty, ymddi'r cyffredinol ar gyfer amser. one of the things I've done is created a key management system inside the kernel. It was initially for managing tokens for the FFASFAL system I was writing. To make sure the code isn't too wasted, I tried to spread it around to all sorts of different things. Otherwise, it's just a big hunk of core memory that's not doing anything. Mynd i gael chiwyddiad i'r gael chi ddelchau o'r pryddedig gyda'r gael. Dwi'n cael ei ddau ar gyfer ar gyfer arbennodd, ac mae'n ddod o'r eu cynnigodd. Mae'r gael ar y brif, gallwch chi'n ei bod'r cyfrif, a'r cyfrif meddwl agor reall, I'll get that to you more than that later. So they used to manage the access control, so they manage access to this data inside of it, because they have ownership group and permissions masks that beyond the usual thing you expect of Unix, like user group and other, they also have a possessor permissions. So each process has a keyring, it has keyrings attached. If the key is in that keyring, you're allowed to use it using the possessor permissions instead of user and other stuff, which means you can have keys that only your process can see. Nobody outside that can see. It also manages the lifetime, so when the last reference goes, the key is automatically deleted and also keys expire after a while, and when they expire, they're automatically removed from the system, and the storage they occupy is reset before it's returned to the system to make sure there's no leakage. And also, there are user space interfaces that allow you to manipulate these things in various ways. For instance, changing the permissions, changing the ownership, moving them between keyrings, granting other people access. And there's also an upcall service, so you say, give me a key for... One of the things you can use for is you can DNS. You can give me a DNS token for... grandotcentral.org, and it will upcall to the kernel. So it will upcall to user space. User space will actually do the DNS lookup because I really don't want to put a DNS thing in the kernel. Let's do it. And then that will instantiate the key, and then when you get the key back, you can just read out the contents, assuming you have permission to do so. So the types of payloads you can put in these keys, you have authentication tokens for network file systems, cryptographic tokens, asymmetric keys, file system encryption, a variety of other things. You put passwords in, so there's a key type called logon key. You can put a password in... create a key, stick a password in there, in user space. User space cannot then get the password back out. You can use the key as a token to pass to, like, the sys mount, or whatever. So the key ID to use space then stands for the password, and it's just not extractable without cracking the kernel. So you can be used for DNS results. Now, you also use it for ID mapping in NFS and SIFs. So you use the up call to say to your space, I have this name or this ID. Please go and map it for this file system. And there's also a user defined key type, which you can store arbitrary data in, and Kerberus makes use of this. Unfortunately, I can't see how I can get my shell. I was going to show you some of this stuff, but I can't make it come up. Can you read that? Does it need to be bigger? So I can do things like add a key. So what this would do is add a user type, user defined payload key, which basically just takes a blob. The key is called foo, and the bob will be bar, and if you add it to my session key ring, that's what the attest stands for. So it gives me a key serial number back. So if I view my session key ring, in there you can see I've got a thing called invocation ID, which is from System D user manager, I believe, and the key I added. So there's a special type called the key ring type that is just a container for the keys, and it is just a key. So you can put key rings inside key rings, you can move key rings about using the same interface as any other thing. So I can then show you what's in the key, but I can just get it out. And then I can... So doing that, I've taken away all permissions on the key, so now I can't do that. And all permissions includes changing the... Actually, that should be fear, fear, fear, fear. Includes changing the mask, so I can't actually put the permissions back on again. So one thing you can do, you can set the permissions to, that person can read, and nobody can change things, so that person can read it, but I can still theoretically get rid of it because unlink doesn't require permissions on the thing you're unlinking, only the key ring it's in. So you should see that it's gone. And there are other things we can do. Once it's actually done, so what this should have done is gone and done an upcall. So it created a key, asked to upcall to the DNS resolver code, which then went and looked up an AFSDB record for grandupcentral.org. The upcall then put that back in the key and returned. And now the key got in a standard with that, and I can just print that out from the key. So those are the IP addresses that belong to grandupcentral.org. So I said that there are things, concepts called key rings, which are just collections of keys. Every process has access to, or pins, three key rings. The key rings are optional, so they may, if they don't exist, they're not pinned. You've got a per thread key ring, which only belongs to a particular thread, so if you've got a process of multiple threads, each one has its own key ring, and the other processes don't necessarily seem to... The other threads in the process don't necessarily seem to that key ring. There's a process key ring, which all the threads in the process can see. There's a procession key ring, which is inherited... Well, when you create a process, all processes of that forks also inherit that session key ring. And then there's a per user key ring, which processes don't inherit, but PAM sticks when you create a new session. So when you log in and create a new login session, PAM, PAM creates your session key ring and sticks a link in there to your per user key ring. Oh, you used to. But I've a feeling someone has changed PAM, so we didn't do this anymore, because I should see it there and it's not there. I'm not sure why that is. I can add my user key ring to my session key ring like that. There is also a persistent per user key ring, which lasts for a certain amount of time at once you've logged out. As I said, key rings have expiry times on them. And when the keys and key rings have expiry times on them, when they expire, the kernel garbage collector just goes and removes them. This is used by Kerberus to store keys and they persist for, say, up to three days beyond your last logout, which means if you leave a demon running whilst you've logged out, it still has access to your Kerberus keys until Kerberus keys have expired. So there's my persistent key ring. And then I can go on the list. What's in there? One mistake I did make was that if you look in the Proc keys file, all the numbers in hex are on decimal, which means that the interface requires the hex numbers to be prefixed with 0x. And you can see in there there's a key ring column that's called KRB. That's from Kerberus. I think it's empty at the moment. So the user space API is three system calls and a Proc file. So add key adds a key and instantiates it all in one go. Request key creates a key, then up calls to go. First of all, it searches for a matching key. If it doesn't find that, it creates a key and up calls to use a space to instantiate the key. And keycuttle is a range of other functions like unlink, link, change the permissions, change the expiry time, things like that. And Proc keys is all the keys on the system that you can see if I do this. So you can see roots can see a whole lot more keys, including some DNS resolvers, blacklist keys from a loader from the UFI database. And there's an asymmetric key at the bottom, which is the module signing key for this kernel, I think. And you'll get into that later. And there are two user space utilities that I provided. One is key control, which I've just been using. And the other one is a PAM library, which should be in the PAM configuration. So there. So that says to run the PAM key in it thing and to revert that creates a session key when you log in. And so that's inherited by all the children of the session. And the revoke argument says revoke the key ring on the way out, which means anyone that accesses it thereafter gets E key revoked as an error. So I said there's an upcall. The upcall runs the Espin request key program and there's a master config file and a place where you can put other configuration files that tell request key what to actually run. So it's just a program switch. It will look up the key parameters and find something to run. So it looks like that. So the operation create, for example, a type.  And you can see at the end the programs that you can run. Well, the program that gets run if the parameters match. Waiting for the current merger window is a patch to make this more specific. At the moment it just goes to the file first match, runs that program. This isn't actually a good way of doing it. Now it goes through all the lines, finds the best match either on with the, where the stars, the wildcalls match the least number of characters and runs that one. So current usages in the kernel include authentication tokens for the FS file system, doing caching in Slocups, doing NFS user to ID mapping and SIFS user to ID mapping. FS crypts, which is started with AXT4 to do encrypted files. And ecryptifes, which is something you mount over another file system. And it encrypts and decrypts GPGs encrypted files in the lower file system. There's an asymmetric key type, so you can see the number of keys. The second one down the Fedora kernel signing key, that's the one generated by the kernel build process. What it does, it creates a public key, the third RSA public key during the build process, signs all the modules and then deletes the private key, and the public key is compiled into the kernel. And then all the modules are signed with that, and so when the modules are loaded, it can check the signatures on the modules. There are a bunch of other keys loaded from the UF5, which erases some Microsoft ones and things in there. And these end.  I'm not sure built-in rich DB keys. I think that may be for firmware, resolver, blacklist. The blacklist keys, which when we do a signature check, checks the... We look up the digest in the blacklist key if it matches. We say you're not allowed to load that module. Or firmware, or Kexec. IMA also uses the keys for similar sort of thing, but under the IMA, by the rodent directly. So the key-kill interface also offers a Diffie-Hellman operation, but what you do, you have to put a number of keys in... the parameters into logon keys and give them to the Diffie-Hellman algorithm, which can then go and do hardware. To do this through hardware. The provided... is TPMAX, some TPMAXS, available using the trusted key type. The trusted key type uses the TPM to unwrap, to seal and unwrap symmetric keys and then retains them inside the kernel. You can see the keys and can use the keys, but they're not exposed user space. You have a handle, which is the key serial number, but the actual key, the crypto-material you can't get at. The encrypted key uses a trusted key to unwrap further symmetric key. If I understand that right. There's a... Kerberos makes use of this. If I do... You can see a bunch of keys in that region. There. Added by Kerberos. Kerberos is here using the key ring as a... credential cache rather than using something in slash temp. OpenAir first uses it to do pag emulation. We don't like the mucking around of the group. The group ID lists inside the kernel. They now stick a key in your key ring. It's used to use a defined key with a pag number in it that the kernel can look up. The main thing about this is the kernel can access these keys. User space can use this to provide stuff to the kernel to use. Upcoming changes in this merger window. There are... a number of public key operations being added. Encrypt. Encrypt, decrypt, sign and verify. These will appear as key kettle commands. They will be available through the key kettle program. We've added two new parsers to the asymmetric key type. One is you can give it a pkcs8 blob. It will parse it and stick the key data contained therein. That's actually the asymmetric key, which you can then pass to these operations. You can't get the key data back out again. Once it's in there, it's in there. The other one is TPM wrapped asymmetric key. You create an asymmetric key somewhere, you wrap it so you get the TPM to seal it to wrap it in some encryption. You can then pass it to the asymmetric key using ADD key. It will be passed to the TPM to unwrap. But then the unwrapped stuff is retained inside the kernel. You can't get it back out. But you can use it through the new key kettle interface. Onto the future. Future developments I want to do. One is I want to make the permissions finer grained. I want to move join. One thing you can do is you can join a key ring and make your session key ring. This is generally a bad idea. It's one of the things I shouldn't have added in the first place, but it seemed like a good idea at the time. I want to make it so this is a separate control. You have to grant someone the ability to join a key ring. So that someone can't just go and randomly join a key ring. If they join a key ring, they get access to all the keys in that key ring. So I want to be able to you can say now you're not joining that key ring. Any other one is I want to make it possible to invalidate invalidation of a key without requiring right access to the key. Because at the moment I think you can do it with right access so you can do it with set access. And I want to make it so it's a separate one. So I don't have to give you the ability to modify the key. I don't have to give you the ability to change the permissions mask on the key. You can invalidate the key. What invalidate does is says the garbage collector get rid of that immediately. And then it's gone. Next time someone does a request for it it will then call again if that's the way they do it. I want to add more flexibility to the subjects. So at the moment you can do it you've got a user ID and a group ID. And whether you possess it or not. I want to be able to say that container can access it. Or that program can access it. Possibly I could do this with an explicit ACL. I have patches to do this. But it might be better to actually have a key kettle where you say a database grant grant this access to that entity. And then have the ACL built inside the kernel. Possibly so you can't get the ACL back out again. It just says yes you have this access and no you don't have this access. Notifications. I want to make it so you can find out, you can monitor a key ring or a key or key ring and find out if it changes. I have this mostly working. I've done it since it's a general interface and it can be used for watching super blocks mounts, apology changes, key rings anything. But as I said I've got it able to watch key rings at the moment. I'd like to demo that but I've got to compile the patches into my testing for the kernel on this thing. But another thing I want to be able to do is effectively use a key ring as an event collector. So you say watch that key ring any key that gets added to that key ring initially to that key ring is a watch put on it that comes back to this key ring. So you don't have to monitor every single key you add to that key ring because it could be quite a lot. And if a key is deleted or removed from that key ring the watch goes away on that particular key. Because all these watches take up memory to actually record. All I want to do is make it provide refresh notification. So notification this key is going to expire in 10 seconds or 10 minutes or whatever. So if it's your Kerberos key ring it says by the way your Kerberos key ring is about to expire. Your file system token is about to expire. Go and do something about it. And another thing I want to add is just a key change counter that you can read. One of the problems with the event notification mechanism is that you've got a fixed size buffer. And when the buffer is full something happened. Possibly something happened in this particular class. So put a counter on the key that says how how many times it's changed. So you can just go poll a lot. Namespacing got problems with namespaces in that keys may exist and be used across different namespaces. Does the up calls currently done in the root namespace shouldn't it be done in appropriate namespace for a container. And there are special key rings that are currently global but should be per namespace. For instance those three there should be per network namespace. Containers I want to be able to put a key ring inside a container that the container manager can use to provide authenticated access to the root file system and the component file systems inside a container. Without this thing inside a container having to do the maintenance of these. And also I want to be able to grant access to that container for that key. So you can put authenticated AFS or authenticated NFS root file system inside your container. But the person, the program inside the container doesn't need to do anything about keeping the token live because it can be done from outside. NFS wants you to use request keys to look up credentials. We've got some agreements on doing this. This is for the container thing as well. And you can find some further information. There's files in the kernel documentation new man of key rings and there's a get tree for the key utils. And that's it. So we can take a couple of quick questions. Thank you very much for this presentation. It's very good. I have one question. When we are using the trust platform module to store the keys it's stored in the hardware, yes? When we are using the TPM to store the keys it is stored in the hardware. So if you talk about the trusted keys and also the new upcoming stuff that's coming in this module you give it a key blob which the TPM then unwraps using a key stored in the TPM. So the key you're actually extracting isn't stored in the TPM. You give it a blob that's a wrapped key. The TPM unwraps it and then attaches that to a key which you can then use. Okay, thank you. But the unwrapped key data is stored inside the kernel not our direct access. Okay, thank you. Cai Engad, hello. Are there any intentions for key persistence across reboots? Explicitly no. Okay, thanks. Except for the TPM sort of thing. More questions? Thank you for the talk. I had a question about UFI keys. When you use secure boot public keys from the secure boot variables are automatically added to the key ring? In Fedora and Rail, yes. So it's something which needs to be done manually but by the distribution? We have patches but trying to get them upstream invokes a lot of argument, shall we say. An incriminations of security people hate it. Okay, unfortunately James isn't here. Otherwise you could ask him why. James bottomly. Okay, thank you. And Mimi hates it as well. Right. So we're going to be discussing the UEFI keys in Naina and Tiago. We'll be discussing it later in their talk as to what we're proposing instead of adding them to the secondary key ring at the moment. They're not on the built-in key ring. The built-in key ring is just for those keys that are built in and it's more than Red Hat that's using these keys. Other distros such as SUSE I believe is using these out of stream patches as well. One other thing I wanted to add when I talked about improving access controls one of the things I wanted to add in that is also what are the keys I would say you can use this key for that as well as this person can use this key. So you can say this key can only be useful for module checking. This key can only be useful for my checking. Right. Okay, so one questions. There's one over there. Remember I'll minimise running so I'll take this one. Hi. Any thoughts on integrating this with the crypto API for example have a crypto API set key variant that you give not a key but a reference to something in a key ring? It has been mentioned before. At the moment apart from trusting encrypted keys there is no session key support really in management in the key key ring stuff. And the crypto API is almost all about session keys rather than symmetric keys rather than symmetric keys. So at the moment the more or less orthogonal though I would like to add a general symmetric key handle basically that you could then pass through crypto routines if or whatever. It's just time. Okay, thank you. There was a question over here. And I think that's going to be our last question because I have to move to the next speaker. My question goes into the same direction. Not only passing a reference to the key ring from the key ring to the crypto API but also keeping the key in some hardware device on some stocks and then passing a reference to the crypto engine so that the crypto engine or the crypto API can make use of the hardware engine so that the key never has to leave the hardware. We talked about the internal crypto stuff. That's one of the things I would like to do at some point somewhere on my list. Do you want to make a mark? Okay. Even better. Okay, but let's move. Let's thank First David for a very good talk.


జజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజజ скоро will be showing up We will surely take on future positions in India yes we will like share an already and I would be touched by my other video


Digitalisation is making us think very differently about how we connect to our consumers and connect all the way back through our supply chain right to our suppliers. So really having an opportunity to come together with a group of industry peers and talk through some of the ideas and some of the solutions that are potentially out there and how we apply them more broadly is a real huge opportunity that's just too big to miss.