So my name is Dinah. You can find me at Dinah Shea on Twitter and GitHub. I'm a student at the University of Waterloo where I study software engineering, but as of Tuesday I'm 99.9% of the way through my undergraduate degree. Yay, thank you. Last year I had this incredible opportunity to attend RailsConf 2017 in Phoenix as a scholar in the guide program, which was great. And I think that was the first time that I really realized Rails is built by actual people. Like conceptually I knew this. Rails didn't just appear in the world, but I don't think I really believed it until I saw a lot of the maintainers and contributors speaking. I met all of these really passionate Rails developers. And somewhere around the third day I distinctly remember saying to myself that I was going to contribute to Rails. I didn't know how I was going to do that. I didn't know what I was going to work on, but I made that promise to myself. And I'm happy to report that two months later my first pull request was merged. So this is where I admit that I was really nervous about this talk slot when I first saw the conference schedule released because it's the third day, it's right after lunch. I was afraid that people would be tired, they would be tuned out by then. But obviously that's not the case. I really tried to come to see this as a gift because reflecting upon my own journey from RailsConf last year, what I know is that you've all had two full days to marinate in the incredible conference atmosphere and all of the energy in just the environment here. So you've heard about new releases, you've heard about the future of Rails, you've heard the ideologies of some of the people moving this project forward.  So let's get you there. My vision for this talk is not necessarily to present completely novel ideas because I think there are a ton of great resources online about not only contributing to open source for the first time, but even contributing to Rails. So really my goal is to set you up for success by sharing some of the resources that I found really helpful and things that I wish I had discovered earlier. So it's not going to be a super technical talk, I'm not going to have any code examples, but I will share a lot of links and just general best practices I guess. So that's what a link share will look like when I eventually release these slides, everything will actually be clickable, but if you want to see them earlier for any reason, if you Google the words that are on this slide, it'll probably be the first hit. And the first resource I want to share is definitely the Rails Guide for Contributing to Ruby on Rails. It's really well written, it helps a lot. I'm pretty sure I had this tab open for the full two months that I worked on my first issue, so it's really great. In fact, some sections of it are so good that I'm not even going to talk about those topics. Things like setting up your dev environment and running tests, I think it's better if you just look at it and try things out.  Actually, I want to redefine what a contribution is because the Rails community is vastly brilliant and there are many different aspects that go into how we define this community, not only amongst ourselves but also to outsiders, newcomers. How do we interact and talk about newcomers? How do we interact with each other? How do we learn from and teach each other? And because there are so many different multifaceted ways that we define our community, there are so many different ways to contribute to the community. So you can do something like keep a technical blog. These are great for sharing what you know with others but also keeping a record for yourself so that in a few weeks or months, you can look back on all that you've learned, how much you've grown. If you want to blog but you're not sure what to blog about, you can always try problems that you've recently solved because they're still kind of fresh in your mind. You can think about what you want to learn in a few weeks to a few months time and the process of writing this blog post will really help deepen your learning. Remember that you don't have to necessarily write something entirely new in the realm of knowledge. If you can take a topic that's been discussed and blogged about over and over but present it in a new light or make it funny or make it really clear and approachable for newcomers, that's still a really valuable contribution to the community. If you do want to blog about something that's a little bit on the newer side, one of the things I would recommend is watching the newer features that come into Rails. For example, I think systems tests are about a year old now and active storage was officially released just over a week ago. There's not a ton of adoption on some of those newer features which means there are fewer experts and fewer experts means fewer blog posts. If you commit to learning that feature really well and you can share your learnings in a blog post or things that you found really surprising, that'll be really helpful for a large number of people. In general, you just want to think about this idea of sharing knowledge, sharing what you've learned with others so that they don't have to go through the same pains that you went through. You don't necessarily have to do that in a blog post form. You can answer questions on mailing lists, on Reddit, and of course on Stack Overflow. There's a Rails tag on questions. If you're feeling particularly generous one day, you can just browse those questions. If you know how to answer any of them, you can really make someone's day by unblocking them. I just picked a random question here. I haven't actually even read through all of it, but it's been viewed over 150,000 times in the last eight years. So I don't think it's a contentious statement at all to say that this is a really valuable contribution to the community. Being at Rails Conference, of course I have to talk about the importance of events. Whether you're working on an international conference or a smaller meetup in your hometown, organizing events is a really important aspect of online communities, especially. It just makes this all feel a little bit more homey. Meeting each other, putting a face to a name, kind of talking about things that aren't necessarily technical and understanding each other as people. That all goes into building a persona around the Rails community, and I would even go so far as to say it builds a persona around what a Rails developer is. Because I want people to think that Rails developers are intelligent and productive, but I also want people to think that Rails developers are kind and welcoming. If you're interested in more stuff like this, there's a great talk from a few years ago called Building an OSS Centric Company, and Leah talks about her work on the jQuery and EmberJS teams and how she likes to focus on these underserved areas, which are typically areas of non-technical work. Because so much has to go right in a project for it to really take off and continue to grow, and many of those things are not technical at all. Another great resource for this is the GitHub open source guides. There's a page called How to Contribute, and there's a section in that page called What It Means to Contribute, and there's just a plethora of really unique creative contribution ideas, and all of those contributions play a vital role in keeping this ecosystem going. I actually didn't find this resource until I was preparing for this talk, but I really wish I had. I definitely recommend reading it. It really expanded my thinking of what a contribution is. So now that we've done the important work of appreciating other forms of contribution, let's talk about your first patch. Just to make sure we're on the same page, I'm going to define a patch as some change that you want to make to an open source project. For Rails, that's usually going to come in the form of a pull request on the GitHub repository, and it will be one of a bug fix, a feature, or a documentation change. I originally thought about sharing my first patch, so how I found it, how I worked on it, how I debugged it, but I realized that one story isn't really enough to pull trends out of. So I ended up asking a bunch of maintainers and contributors about their first patches and how they grew in the community, and I'm going to try to share some of the learnings that I took away from that. Pretty unanimous, pretty unanimously, excuse me. People said that a good first patch is a documentation patch, so they're the humble but mighty documentation patch, of course. So there's a way lower barrier to entry for these, because you don't necessarily have to set up your development environment, and you don't have to get the tests running. But it is a great opportunity for you to learn the flow of open source. So if you've never really worked in open source before, things like forking a repository, pulling down from a remote, making a pull request, fetching from upstream, all of those can seem kind of confusing. And when you do it enough, it'll become second nature, but if you've never worked in an open source project before, then I really recommend starting with a smaller scope issue just to give yourself the space to learn the tooling. And finally, I think what people forget about documentation is that as a new contributor, you are the best person to write it. I'm sure you know this from other projects when you get really deep into a project and you're working in the nitty gritty details, it can be kind of hard to pull yourself up out of the weeds and explain that project to someone else. You might forget that things that you know to be true are not necessarily obvious to outsiders. You might have difficulty identifying the key points that you need to get across for someone who's consuming the project or the product, or in this case developers using rails. But you can't have that problem if you don't know the internals. So bringing fresh eyes to a project can often bring a lot of clarity to documentation and messaging. If you want to work on a documentation change, you should know that there are two main bodies of documentation in the rails project. The one on the left is rails guides, which is like this web view, very friendly tutorial like tone. It's very prosy. Wait, actually, I guess like all documentation is prosy, no one's writing documentation in iambic pentameter. But if you did want to, I think that would be really cool, probably not for the dogs. But if you write like a haiku and you tweet me, that would be cool. And then the one on the right are the API docs, which are a little bit more granular. They're at the method level. The best way to find something to work on is just to use the docs. And when you notice something wrong, whether that's a typo, a grammatical error, or something's not clear, just plain wrong, you can make a note of it and fix it later. Out of the two bodies of documentation, I definitely think the guides get a little bit more love. So show the API docs some love. You could try just clicking around and you might find things that may be need a little bit more work. In general, kind of similar to the idea of blog posts, you can check coverage for newer features. There's fewer people, there could be fewer people using these features, which would mean fewer people test driving the documentation. In a similar train of thought, you can watch the pull requests. So this is like, this is like almost even faster news, if that makes any sense. If you notice that someone has submitted a pull request that changes the behavior of a publicly exposed method, or they've added something, but they haven't added documentation, that's a great opportunity for you to write that in a new pull request, and you can tag the original implementer as a reviewer. Because they probably know the, I guess, internals and the details of that method the best. Most of the time, you're going to be doing them a huge favor. Not everyone likes writing documentation. Some people don't have English as a first language. So they'll really appreciate the help. If you do want to move to a code patch, this is where it gets a little bit tricky. Usually when you step into an open source project, people will tell you to fix bugs that you come across, or just look at the issues on GitHub. But that's really hard for mature projects. And it's especially hard for mature projects with lots of contributors like Rails, because the low hanging fruit gets snatched up pretty quickly. And a lot of what's left tends to have dependencies on external factors, or is blocked on something, or is just really difficult to implement. So the first place that you should check is the good first patch label. When a maintainer comes across an issue that's a little smaller in scope, or they think is beginner friendly, they'll try to tag it good first patch. And we actually, the maintainers tried to pull together some good first patch issues in time for RailsConf because it's, you know, a lot of people might be really interested in contributing right after this. So if you take a look maybe tonight, you should be able to find a few newer issues. The difficulty thing with this, or the difficult thing with this rather, is similar to lower hanging fruit. They do tend to get snatched up pretty quickly. I remember that when I was looking at the good first patch label when I first started, there were maybe one or two issues. They were kind of stale and a lot of people had already worked on them, so I didn't really want to fight people. Unfortunately, if that doesn't work out for you, I don't really have a method that guarantees that you'll find an issue to work on that's interesting. But there are a lot of best practices that you can do that do help yourself and the project. So the first thing that you should definitely do is watch the repository. On the GitHub project page, there's a little button. It says watch. Click that. In your GitHub notifications, you'll kind of see all of the new things happening in Rails on a particular day. You can also try something like CodeTriage, where you sign up with your GitHub account and they have multiple open source projects. Rails is just one of them. Based on whatever preferences you set, you'll get maybe a daily email with a few pull requests or a few issues that you could potentially work on or help review. Even if you don't want to use any of these tools, if you just want to log in every week and read up on the new issues, you can help a lot by verifying bugs. If you can reproduce the bug and you let people know by adding a comment or something, that helps, I guess that helps maintainers know that the bug is kind of not just a one-off case and maybe it means that it needs a little bit higher priority. If you want to go another step, you can clarify the reproduction steps and if you want to help even more, you can help write a bug report script if one doesn't already exist. So on the Rails repository and also linked on a bunch of Rails guides pages, there are these bug report templates, which are kind of like standalone scripts that you can run to reproduce the bug. So it's kind of like a distilled version, like the simplest models that you can put in to see the bug happening. And those are really helpful, obviously, because they strip away the domain logic and it also can be helpful if someone's running a give-by section or something like that. So you're helping yourself by making sure that this project is actually something you're interested in working on. You want to see what the community is like. Maybe you thought contributing to Rails would be fun and exciting, but after watching the repository for a while, you realize it's really not for you. That's fine. But you also help the project a lot by triaging issues, by reviewing pull requests, and maybe the bigger part of doing things like watching the repository and helping triage is you're building trust. Build trust and establish rapport. So this is a really important thing. I think trust is one of the things that's hard to talk about in open source because it's really hard to quantify. I can say that I have X number of commits and Y number of open pull requests, but I can't say that people trust me with 83.7% confidence or whatever. But it's really important in open source, especially because often we don't personally know the people that we're working with, and we might never get an opportunity to know them beyond our online interactions. So it's really important to build trust. And the way that you do that is by establishing rapport. Even if you don't commit code, but you're consistently showing up and clarifying issues, leaving great feedback on reviews, then you start to see which names come up. And these will probably be maintainers, and you'll understand how they like to work, how they like to communicate. And in turn, others will notice your name come up a lot. They'll see that you're really interested, you're really passionate about Rails, and they'll kind of get to know how you like to work as well. They'll see that you work well in the community, and if you're consistently leaving great feedback, that you probably have similar preferences as the team in terms of code style and organization. And that's actually really difficult to find. I actually googled the definition of rapport to make sure I was A, spelling it right, and B, saying it right. And the definition is really great. A close and harmonious relationship in which the people or groups concerned understand each other's feelings or ideas and communicate well. I love that. I'm going to start using this word more. You want to get a feel for the community. You want to see how people interact with each other, how people communicate, how others interact with you. And it's way easier for you to make a code contribution when you've established rapport, when you understand kind of what the feel of the community is. And when you show up consistently, people are way more likely to want to help you to spend a little time, spend a little bit more time on whatever it is you need from them if you've demonstrated that commitment and if they trust you. Another way to find issues that I personally don't, I've never actually done this, so I can't really endorse it, but is to try using the Rails core mailing list. So feature requests are not usually created as issues in the Rails repository and some people will discuss them on the core mailing list here, but proceed with caution. You really want to see some buy-in, ideally from a maintainer, but at least from a number of users, because you want to make sure that you're building something people actually want, not just one person wants. And even if you do see a little bit of buy-in, you do risk building something that the core team doesn't actually envision for the future of Rails, which means even if it works, it might not get merged.  So hopefully from one of those tips you found something to work on, crossing my fingers for you. Unfortunately, I can't guarantee it, like I said, but I think if you consistently show up and watch enough that you will find something interesting to work on. I think this is actually the part that's almost a little easier for people, because this is something we're more familiar with. So a few resources that you should check out if you're working in Rails internals for the first time. This great talk from last year's Rails conference, Perusing the Rails Source Code by Alex Kitchens. I actually got to see this talk live and it was really, really helpful. It really made me think that it was actually feasible for me to contribute to Rails. In the beginning of the talk he goes over how modules fit together, which is really helpful if you're working on an issue, but you don't even know where to start. Like you're not even sure which module is responsible for whatever behavior is going wrong. And then he goes through an example of digging through source code with introspection methods. So definitely check that out. There's also this great, I think this was a workshop, called Breaking Down the Barrier Demystifying Contributing to Rails. This was a few years ago, but it's still very relevant, still very helpful. I think Eileen created a repository so that you can actually kind of interact with some of the things that she talks about. It's workshopping, introspection, tracepoint, ctegs, as well as some git methods. And there's a bunch of really great resources coming out of this year's conference as well, so I don't have photos for those, but you should definitely check them out when they are uploaded online. I've heard great things about Sean Griffin's talk on day one, debugging with in Rails, that's probably going to be really helpful and the entire how it works track is probably going to be a safe bet, because if you're working on one of those features that someone talks about, it helps to know how it works. It helps to know what's going on. But sometimes you need a little bit more help. Don't feel like you're working in a bubble and you can't ask for it. There are people that you can talk to and here's where you'll find them. The first place you should probably check is the git history. Who is the last person to touch this file or a particular line of code? That person's going to be probably the most familiar with it. You can also check, you can also ask a regular contributor. How do you find a regular contributor? You ask by watching the repository. You can always ask a core team member. I've heard they're kind of helpful. These people might not necessarily have all the answers for you, or even if they have all the answers, they might not necessarily have the time to sit down with you and really try to debug your issues, but they'll usually be able to point you in a direction so that you can unblock yourself. And hopefully after some debugging, you're ready to submit a poll request. So a few things to keep in mind. Tone is really, really important. Remember that most of the people who work in open source do it in their spare time. So don't ever be entitled.  I hope that goes without saying. I actually learned a lot about working in a distributed team when I started, when I submitted my first poll request. I had never worked in a truly decentralized team before and seeing how people communicate with one another on these poll requests really taught me that it's generally better to over explain than to under explain. Because if you're talking too much, people can always just stop reading, but it's way harder to read in between the lines. And in general, it's better to be too nice. If you have a misunderstanding with someone that you sit across from at work, you can always take that discussion offline and resolve it. You can remind each other that you're working on the same team or that you have the same goals, but you don't necessarily have that luxury in open source. So try to preempt some of those problems by being extra nice. I've seen some of the best PRs or sorry, that sense didn't make sense. Some of the best PRs that I've seen are for features that I'm completely unfamiliar with in modules that I've never worked with, but reading that poll request allows me to learn the intention why certain decisions were made and how whoever the implementer is came to those decisions. So remember that your poll request isn't actually just for you. It's not just for the reviewer. In an open source community, it's usually for everyone. So there's a ton of people watching the repository that would really appreciate it if you maybe over explained or gave a lot of context, so that just by reading that poll request, they can learn what it is you're trying to do. Patience is a virtue. Again, remember that most people who work on open source do it in their spare time. So you're probably going to have slower turnaround times than you do at work. If you have a poll request or something that's been sitting for a few weeks to a few months and no one's really been working on it, you could maybe ping someone, but be nice about it. Always watch your tone. Don't say anything like, like, why has this still not been reviewed or merged? Whatever. And finally, if you're going to work in open source, one of the things that you have to accept is that your poll request that you worked so hard on might never get accepted. And that's okay. Some of the reasons that might not get accepted are differences of opinion. Maybe something that you think should be in Rails, other people don't necessarily think as a Rails concern, or maybe the way that you implemented something doesn't fit with what the Rails core team or maintainers had envisioned for that feature. And you just have to be willing to accept that. But remember that it's not all wasted. You probably helped a maintainer at least discover a path that they're maybe not so interested in taking for the next feature or whatever. And at the very least, you've grown a lot as a developer because you've learned about internals, you've learned about writing something in Rails, and that's going to help you a lot whenever it comes to you using Rails as a consumer of the API. But hopefully it does get merged, in which case you would have your first PR, you can call yourself a contributor, definitely celebrate, definitely share on Twitter or with your friends on whatever it is that people use. That was awkward. Yeah, I definitely shared. I remember all of my friends who worked in tech were like, oh my gosh, that's so cool. And all of my friends who didn't work in tech were like, what? So that was great. I haven't actually really shared my story of how I found my first issue because it wasn't really on one of these paths. I watched the repository. I looked at pull requests a lot. I had even gone through kind of the yak shaving of setting up my dev environment. I had tests running, but I didn't really find anything that I felt like I could contribute to a lot or, I don't know, maybe I was just really unlucky. So I ended up reaching out to Eileen and I said something like, I saw your talk at RailsConf and I was really inspired. I want to contribute to Rails. These are the things that I've done, but I'm not really sure where to go next. I'm not really sure how to find that first issue. So I really tried to make sure that I showed I had made an effort. At the time, she was working on some cleanup tasks around systems tests and she was really nice. She ended up sending me, I think, a few bugs and features and I ended up working on building systems tests for the RailsGenerate scaffold command, which you saw earlier in the presentation. So I want to take this time to talk about mentorship in open source communities. I was pretty surprised when I started talking to people to find that the last two additions to the core team both started in the project with some sort of mentorship. So Casper, who's the second latest addition, came into Rails through Google Summer of Code Program, which is this program that Google runs every summer to encourage students to work on open source projects. And there, there's a pretty formal structure from what I've gathered. I think there's a formal mentor title and his mentor was Rafael, who was on the core team at the time. And Eileen, who's spoken about this in a few talks, started in Rails when she found a bug an active record and she paired with Erin Patterson, who was also on the core team at the time and they worked through a few issues after that. So clearly in the case of these two individuals that time investment in mentorship has really paid off for the community because both of them are on the core team now and they mentor a lot of people and they do a lot of great work. But by no means is this strictly necessary. There are lots of maintainers who manage to make their start without a mentor who kind of just watch the repository and are really consistent and manage to find issues on their own. But clearly in some cases it does help. So I want to go over some of the pros and cons. When you work with a mentor especially if they're on the core team your change is way more likely to be merged. If you're working with someone on the core team you're probably working with a feature that the Rails team has decided they want or need in the framework. And the implementation that you choose will probably be something that the core team is willing to go with as well. You also have a go to question go to question you have a go to person for questions which is always nice. I've also noticed that for especially first time contributors who have a guide that mentor will usually be like the guide through their first PR. So when you make your first pull request you'll notice that like a lot of strangers may start to comment and that can be a little bit overwhelming at first. So I've noticed that sometimes the more experienced contributor will answer some of the comments and say like we chose this implementation because of so and so and these are the other things we consider. So that's really great. And all of these work together to ensure that your first patch experience is just really great which means you're that much more likely to come back for a second patch a third to become a core team member if you so choose. But the cons are that mentorship is pretty hard just in general not even only an open source. You have to find a good match between two people in terms of their working styles their working hours maybe their communication styles and mentorship generally takes a long time which means that it absolutely does not scale. I think well okay I've never really been great at that game where you look at a jar of jelly beans and you try to guess how many are in it but I'm pretty sure there's more people in this room than there are maintainers. So even if we each got paired with a maintainer it wouldn't really work out. Not to mention that maintainers usually have a lot of other things going on in their lives whether that's a responsibility to the open source project or a personal life God forbid. So if you do decide that you want to reach out to someone maybe you think that it would be a really good experience for you maybe you think that you've really tried all of the other things and it's really not working out and you're getting really frustrated keep in mind that what you're trying to answer when you reach out to that individual is why is this worth their time? And the way that you answer that is by showing that you've really made an effort do your homework check out all of the resources that I've linked look at resources that I haven't even linked that you've actually tried all of the alternatives and it's way easier if you approach someone with a bug that you're not sure how to fix or a feature that you're not sure how to implement a specific direct request is way easier to answer than something big so they're way more likely to respond to you and it also saves them the trouble of figuring out what you're interested in what would be a good fit for you your skills and there's this great line that Katrina Owen says in a talk balance the size and scope of the request with the amount of trust that you've built up so if it's your first day in the project and you haven't really done anything it's way more likely that if you make a large size request that it probably won't happen but if you've consistently showed up if people recognize your handle on github if they recognize your name then it's way more likely that they want to try to help you here's that talk it's called incognito mentorship it's really great whether or not you're interested in open source even if you have nothing to do with rails this is still a really great talk about mentorship and another great line she says is mentorships usually happen by accident are informal and are between people with an existing relationship so maybe you build that relationship online or maybe if you're lucky enough to be at I think this is the largest rails conference in the world you can meet some of those people right now because amongst you are a bunch of contributors a bunch of maintainers I'm not going to point people out so that you don't just go attack them later but you can start building some of those relationships in person keep in mind if you are reaching out to someone it doesn't have to be a core team member in fact that might not actually be the best idea because core team members are some of the busiest people in a project because of all of their other responsibilities you can try reaching out to another maintainer or someone that's just a frequent contributor these people will know enough to kind of help you cross that first chasm of your first pull request plus if they don't usually get a ton of requests like this they might actually be flattered rather than annoyed second you don't have to call it mentorship I use the word mentorship because it's the word that I figured would get us all on the same page the fastest but I don't recommend you using this word in your communication or even really thinking of it as a mentorship because mentorships kind of imply like that's a really loaded word it implies a lot of time investment a lot of being personally invested in the growth of another person's career or programming or whatever it might be but short finite bursts of time are a way easier commitment and often that's all you really need so I hesitate to give this piece of advice because while it worked for me really well it doesn't scale it's not for everyone and it certainly shouldn't be your default let's talk about what happens after the first pull request because I think a lot of people like really like that milestone but then aren't really sure where to go next that's certainly what I found I was like okay great now what now what is you ask yourself what do you want out of this experience why did you start contributing to open source if it's just kind of scratching an itch if you were really curious about it and you were kind of content after that first contribution and you don't really want to do it anymore that's fine power to you if you enjoyed it and you kind of want to take on maybe smaller issues when you do have a little bit of spare time from work or from your personal life that's also fine you should really use kind of the same methods in terms of finding those things like watching the repository code triage check recently updated issues all of those still work if you really really enjoyed it and you want to grow and you want to see where this can take you then you might actually start you might want to start working on larger features and in this case I would try syncing up with a maintainer or a core team member but definitely try to get some of those first patches first to make sure that it's something that you like doing and also to show whoever it is that you end up reaching out to that you are really committed that you've already shown that you can do this to give you an idea of who you're reaching out to as well as understanding maybe what you could potentially work towards if you so please the Rails maintainers team is kind of divided into three sub teams the issues team is capable of committing documentation which means that if you make a pull request that's documentation only they can merge those they can accept those pull requests as the name implies they are also responsible for triaging issues which means closing pull requests applying labels to issues the committers team has kind of those capabilities and they can also commit code which again means if you have a pull request but it's code not just documentation they can accept that the core team can do all of those things and they also have release permissions they're responsible for determining the future of Rails and frequently I think they're also responsible for implementing some of the larger features in upcoming releases so if you're interested in who's on these teams you can take a look at the community page if you just google like community Ruby on Rails it's definitely the first hit all of these teams are invite only via the core team which means that you don't have to do anything special it's just a matter of working on Rails consistently showing up showing good judgment in your reviews in your own code showing respect for other members of the community and people will notice that was the end of that thought okay so I'm gonna close with kind of the most important thing that you probably need to hear as someone who's thinking about contributing to Rails which is that you are ready I think there's this notion that you have to really know the ins and outs of Rails that you have to have been working on Rails for a certain number of years to contribute to it and that's just not true I didn't know the scaffold command existed before I added systems test to it which I'm not really sure what that says about my ability to read documentation if someone gave it to me in a haiku or a sonnet maybe that would work better and earlier this week you heard David say that no one knows every corner of Rails so no one expects you to know every corner of Rails you with everything that you know and everything you've yet to learn with all of your strengths and all of your weaknesses if this is something you want to do you got this I believe in you thank you


The president's budget proposal eliminates public media funding. Learn how you can help at lptv.org slash action. But for as good as the last 24 hours have been for women's hockey as a whole, the last 12 have been just as bad for the University of North Dakota women's hockey team. Earlier today, UND athletic director Brian Faison announced that the UND women's hockey program as well as men's and women's swimming would be eliminated. The cuts are part of a school-wide effort to trim budgets because of an anticipated drop in state funding.  You're disrupting the path that they had set for themselves. It's not a decision we take lightly. It was a very, very difficult situation because it's a unique circumstance for us to have this program. Again, I think Brian's done a really good job. I mean, we've gotten the WCHA frozen face, I think seven years in a row or whatever it is. I mean, you know, so there's a level of quality of play and everything else that's there. So that's a hard thing and I can't replace it. All three programs will be eliminated effective at the end of this 2016-17 academic year. And the announcement of the program's elimination came as a shock to many, including Bemidji State who played UND in the WCHA. Tremendously sad days. It's just a, you know, to have that great, you know, we take a huge step as a sport one day. You know, it's like two big steps backward today with the announcement that North Dakota's not going to feel the team anymore. It's just it's really hard to fathom. We've always considered ourselves to, those of us in the league, to be the toughest league and they're one of the reasons why. UND has always been one of my favorite games to play. One of my favorite arenas to go to. I have a good friend on the team and it's just so disappointing that that team has to get cut for whatever reasons it is and they're a good team. And the fact that we're losing a good competition, that's only someone that would make us better. Playing against those skilled players and not having that opportunity now, that's detrimental to us and the league. League Commissioner Katie Millian released a statement earlier this afternoon which read in part, today's developments are excruciatingly sad for the University of North Dakota, the WCHA and the sport of women's hockey. While we understand the significant state mandated budget cuts faced by the entire university and respect the decision-making process of the UND administration, there is no denying the impact of losing a program that has produced Olympians, advanced to NCAA tournaments and is a perennial fixture in the national rankings. Our collective hearts ache for North Dakota's current and incoming student athletes for the school's alumni and fans, for head coach Brian Idolsky and his entire staff and all involved with the program. You can see the full statement on our website. She also said the league will be evaluating appropriate actions needed to remedy the impacts of this decision for the coming season and beyond. But just a shock to everybody, right? Nobody saw this coming. Nobody really saw this coming. They knew something was going to happen. They didn't know what programs were going to be cut and ultimately ended up being women's hockey, men's and men's and women's swimming. And women's hockey, they were even out on the ice still when most of this news was breaking online earlier today. Wow, all right, well too bad, okay. If you've enjoyed this segment of Lakeland News, please consider making a tax deductible contribution to Lakeland Public Television.


Good morning traders Patrick Munley here with another Tickman Charter. I want to draw your attention today to a potential opportunity in the Dollar Yen. We are about to approach some an area of confluence here versus these bigger structures we have an ABCD pattern 104.13 we then have an internal ABCD pattern 104.27 so we've got confluence there we've got the 78.6% retracement of the move up from from the March lows coming at 103.50 so anywhere in this area from 104.30 to 103.50 look for bullish reversal patterns opportunity to set long positions at least targeting a move back to test this prior support area of 106 now potentially as resistance as always traders plan the trade trade the plan and most importantly manage your risk until next time. Thanks very much.


Okay, so here we begin, this is lecture 31, okay, alright so we have been seeing linear equalizers and decision feedback, decision feedback equalizers with no constraint on implementation complexity in the sense that no constraint on number of tabs, okay, and no constraint and no concerns about being AIR anti-costal, so you can approximate it and that is the kind of thing we've been doing and so some lessons were hopefully learned from there as to how the receiver structure should look, right, should have a precursor filter and then the slicer, there should be a feedback loop around the slicer, should be a post-cursor equalizer in the slicer, you kind of assume that the slicer decisions are accurate in the design of your filters, okay, and the design for criteria are two types of criteria, one is the zero-forcing criteria, the other is the main square error criteria and we found the main square error criteria to be uniformly better than the corresponding zero-forcing criteria, okay, so in fact the, like I've been always saying the minimum main square error DFE, right, and a certain version of that minimum means, mean square error DFE which I'll call the unbiased DFE has been shown to be capacity approaching for some, some range, so there's something canonically good about the MMSE DFE structure, okay, so I'm going to talk now briefly about this mean square error and probability of error, particularly for the mean square error DFE equalizer structure, okay, so I've been always making this point that just because you minimize mean square error, if your noise is non Gaussian, it doesn't mean that you're necessarily minimizing probability of error, okay, so mean square error makes perfect sense optimally only for Gaussian, purely Gaussian ones, okay, so when you expect some symbols to be part of your noise just because you have lower mean square error does not necessarily mean you might have low probability of error, okay, so you'll see what the MSE DFE does in its quest to minimize mean square error, it'll do something which is not very optimal in terms of probability of error, first thing I want to do is to show you that then suggest a correction for that and then we'll just leave it at that, I won't do it very rigorously, just a notion of why it works, okay, so let's begin with this, so this title is basically called unbiased MMSE DFE, okay, so let's look once again at this model, SK going through H of Z then noise gets added, okay, I'm going to say the PSD of noise is SN which factors is gamma square MN, MN star, okay, and then you obtain ZK, right, and for the MMSE DFE, the optimal MMSE DFE, the precursor equalizer will work out to ES by gamma Z squared, right, H star MN inverse divided by MZ star, okay, so this was the structure and these corresponding quantities, well SC factors as gamma Z squared MZ, MZ star, okay, and then what is this ES? ES is expected value of mod SK squared, okay, so those are the various definitions and then you have the post cursor part which consists of a slicer and a feedback loop rounded and post cursor equalizer works out to MZ MN inverse minus 1, so it's hat K, I'm going to say this is approximately SK, okay, and I'll call this guy at the input of the slicer as XK, okay, so this is just the structure and so hopefully people saw the assignment that was posted, it was posted on Friday, I think, okay, so hopefully people saw that, it's got a whole bunch of problems on finding what the precursor equalizer is, post cursor equalizer is for simple single pole single zero systems and I think maybe even two zeros is there, just to get a feel for how it will work out in the positions of the poles and zeros change and all that, okay, so that's a good thing to work out, hopefully you get some intuition from that, okay, alright, so let's see, so before I proceed with the unbiased MMSE, I want to ask a few questions about some characteristics of these filters, okay, so look at the precursor filter, okay, what can you say about its impulse response, okay, in terms of causality, two-sidedness, one-sidedness, what can you say, making some canonical assumptions about H, okay, for instance, H won't have any poles outside the unit circle, right, so if you make such assumptions, what can you say about the impulse response of the precursor, so suppose it's white noise, okay, so MN inverse doesn't exist, forget about MN inverse, okay, it's not there, what can you say about the, see H star of 1 by Z star is going to have Z terms, right, so only Z terms will be in the numerator, what about MZ star, once again, just Z terms, so if you now expand it out and do the partial fraction expansion, you will see it will become IIR anti-causal, okay, so it will be one-sided in the sense that on the anti-causal side, it will go off to infinity, on the causal side, it will stop after a while, you see that, okay, stop after a while, okay, and if you do MN inverse, what happens? MN you expect to be causal, right, so in general, the precursor is going to roughly look like a lot of, both sided, okay, that's the main story, okay, so it's going to be two-sided, it's not going to be single-sided, definitely not, okay, what about the post-cursor, the precursor is going to be two-sided, what about the post-cursor, yeah, so you can expect it to be causal, for instance if you say MN inverse is not there, noise is white, and clearly it will be strictly causal in the sense that the first term won't be there, right, M of Z minus 1, it will go away, okay, even if MN inverse is there, it will go away, so it's the first term will not be there, okay, so it's strictly anti-causal in that sense, okay, so these are nice things to keep in mind, so when we go to constrain complexity and we want to limit the tabs, you should limit it suitably, you shouldn't say my precursor will not have a two-sided response, for instance, okay, so how will you implement a two-sided response in practice? You delay, okay, so as long as it's finite, you delay and then adjust for the delay in the latest section you can do, so that's the thing to keep in mind, anyway, so that's that comment, okay, the thing I want to do is try to get an expression for the slicer error, okay, what is the slicer error, okay, I'll call it E prime K, which is XK minus SK, okay, so this is the slicer error, what is the assumption I've already made once I say slicer error is, yeah, SAT is approximately S, okay, so I've made that assumption just to make my analysis simpler, if you don't make that, it just will go round and round with some non-linear processing, you'll never get to a quick answer, okay, to get a nice feel for it, I'm going to say SAT is approximately SK, so the slicer error becomes XK minus SK, okay, so now let's write XK, okay, so remember XK has is a difference of two signals, okay, one signal is what's coming from the channel and the other is from the feedback, okay, so you have to account for both, so if you write that very carefully, you'll see this will become, what do I write it, okay, so XK now I'm going to expand, I'm going to say it is SK convolved with, did I get that right, it seemed to be, okay, so I should be careful there, I should be careful there, so I want to say XK is the, okay, so let me be careful, so XK will have a noise component as well as a signal component, right, so I don't want to be worried about the noise component, okay, so I'm going to say, let me write down what XK is, so let me erase this part, this is not XK, let me be careful, okay, so let me do that, I'm going to say XK is SK convolved with HK, convolved with the impulse response of the precursor equalizer, okay, so I'll call it H pre-K, okay, the precursor equalizer, okay, minus what, SK convolved with the impulse response of the post-cursor equalizer, okay, so this is the signal component at the input of the slicer, okay, so I'm going to subtract this, from this I'm going to subtract SK to get the slicer symbol component error, okay, so I'm not worried about the noise, no, there'll be a noise term, let me just add to this, not worried about the noise, so this error E pre-K is just the slicer symbol error, as in the ISI, okay, ISI at the slicer, not, there's no noise, okay, so of course there's a minus SK, that's along here, is that clear, so this E pre-K does not include noise, only the ISI part, just for simplicity in the computation, okay, so of course I can now combine the two negative terms, okay, let me just do that real quick, HK convolved with H pre-K, we'll quickly move to the frequency domain, it'll become easier, but before that I just want to make sure I get the right part, okay, SK convolved with, how do you bring that in? You have to say H post K plus what? Delta K, okay, that's how you bring in that constant term, okay, so now let's move to the frequency domain, you do transforms, your favorite transform, DTFT or Z transform, you'll get E prime to be equal to, okay, okay, capital S, so capital S is the transform of SK, okay, so I'm going to call that capital S, okay, times what? H times, okay, the pre-equalizer, pre-KZ equalizer, the pre-KZ equalizer, the response I've been calling D times W, right, okay, so D was something, D times W, just to be consistent I'm doing that, minus, okay, the post-KZ equalizer plus Delta, so it will be simply W, okay, so you go in and substitute it, you will get E prime by S to be, to be H times, okay, so I'll do the substitution, you can go back and verify this, this is quite simple, gamma Z squared H star divided by MZ star, it's just the same substitution that I had before, M and inverse, so this is the pre-KZ equalizer, right, so this is the channel, this is the channel, this is the pre-KZ, from this I have to subtract the post-KZ plus 1, okay, which becomes MZ, M and inverse, okay, so what do we want to do now, okay, so the next thing to do is to look at this term, what is this? E S times mod H squared, so you can relate this to SZ, right, SZ is what? E S times mod H squared plus SN, okay, so you make that substitution in, play around with it, do some cancellations, finally you will get this very, very interesting expression, which becomes minus gamma N squared by gamma Z squared MN star divided by MZ star, okay, so you can play around with this, this is very simple, it's not too difficult to do this, this is E prime by capital S, remember what is capital S? Z transform with ZK, SK, I'm sorry, okay, and E prime, okay, once again capital E prime is Z transform with E prime K, which is the symbol component error in the slicer error, okay, so alright, okay, yeah, I'm going to come to it slowly, yes, I'm going to subtract that, okay, so now if you move back, so first thing is, what type of a filter is this? MN star divided by MZ star, okay, so it might have a lot of components, we don't care about it, but what will be the Z power zero term, okay, it will be one, okay, so you can, you can see that, so it will be monic, okay, so this will be monic filter divided by monic filter, so this is going to be monic, okay, so that's crucial, okay, so the Z power zero term is going to be monic, okay, so that's the only thing we'll use, we won't care about the other terms, okay, so Z power zero term is one, it's monic, so now if you go back to the time domain, you can write E prime K as a lot of other terms plus what will be the multiplying factor for SK minus gamma N squared by gamma Z squared times SK, right, so all the other terms will give you other multiplications, okay, but I don't care about it, but SK will have minus gamma N squared by gamma Z squared plus some other terms, okay, so this is what it's going to work out to, okay, so now if you look at the slicer input, okay, it's what, E prime K is XK, the slicer symbol component minus the slicer output, now if I want to look at the symbol component at the input of the slicer, I have to add SK to this, okay, so if I add SK to this, I get that my symbol component at slicer input is going to be other terms plus, which don't involve SK, plus SK minus gamma N squared by gamma Z squared times SK plus some other terms which don't involve SK, okay, so if you look at this carefully, it's going to be scaled by 1 minus gamma N squared by gamma Z squared, okay, all right, so when I slice or when I try to find S hat of K from the symbol component, my SK is not coming through without a bias, I'm multiplying the SK by some some number, okay, and then I'm slicing this, okay, so you first question to ask is how can, so this has to have a bad effect on the probability of it, okay, so that's the first observation, it's kind of loose, I'm not going to make it more rigorous than that, I'm going to say because of this multiplication, probability of error is going to be a little bit effect, okay, so it won't be as good as slicing just with SK, okay, all right, so basically, so the first question is, first point to make is slicer input is biased about SK, okay, so the slicer input you don't have SK plus something, you have constant times SK plus something, okay, and how are you going to slice? You're going to assume it's SK and slice, so if you slice assuming it's just K, then your probability of error will be poorer than assuming that you have a multiplication factor and then you slice, okay, so you have to adjust your receive constellation accordingly before you slice, okay, but remember only if you slice according to the original constellation, you get minimum mean square error, if you do this adjustment in the slicer, then your asset will change and you don't get necessarily minimum mean square error anymore, okay, because noise will also get multiplied by a suitable thing and you will get into trouble, okay, so while mean square error is a good quantity, it doesn't necessarily give you the lowest probability of error, in fact, if you adjust for this bias in your receiver before you slice, you will get a lower probability of error than the MMSE DFE, okay, but your mean square error will be larger, because while your symbol component is also being adjusted, your noise is also getting adjusted, so you have to be very careful about how the trade-off is going, if you just minimize your mean square error, you might get something which is not necessarily optimal with respect to noise, okay, well the trade-off, I'm not doing an exact analysis first of all, sir, so roughly, so what you should do, so, okay, so let me repeat what you should do, okay, so this is, so basically the MMSE DFE is biased, okay, that is the first observation, okay, so it's a good idea to unbiased it before you slice, okay, so an unbiased version would be something like this, okay, so you have, so you have SK coming in, H of Z, you add noise to it, then you have the same precursor as before, okay, so I'll call it the MMSE precursor, no change there, but before you slice, you multiply by gamma Z squared by gamma Z squared minus gamma N squared, okay, and then you slice, this is the same as adjusting your slicer also, you know, I mean, it's the same thing, whether you multiply before or you adjust the slicer suitably, you get the same thing, and then your feedback with the same MMSE post cursor, no problem there, okay, oh sorry, feedback goes to the plus and not to the multiplication, you do this, okay, you can verify for various examples if you want and even in other cases that such a structure will give you a lower probability of symbol error than the MMSE DFE, okay, it's likely to give and you can see the intuition for why it would give you a lower probability of error, because you're slicing properly, you're not doing slicing according to some other constellation, because you multiply it by something, right, however, if you compute the mean square error in this version, you will get a larger mean square error than the MMSE DFE, of course you have to, right, the MMSE was defined by minimizing the mean square error, okay, so this is an important lesson to learn when you minimize mean square error blindly, okay, when your error terms have non Gaussian components and you're just generally minimizing mean square error, you're never guaranteed naturally to get a minimum probability of symbol error also, okay, so these kind of things are called unbiased DFE's, okay, so if you learn an area called estimation detection theory, unbiased estimators are a very important class of estimators to see, okay, so the expected value of the estimator should be equal to the expected value before, if there is a scaling term then you don't necessarily have a good estimator in certain sense, okay, so all these things are interesting things to learn and unbiased estimators are always good to have, so the DFE that we had before is a biased estimator, it's not an unbiased estimator, so when you go to the unbiased estimator, things might improve and they tend to improve naturally, okay, so you can show out of all the unbiased estimators you have for such a channel, this estimator is the lowest MMSE unbiased estimator, you can show that also, okay, so this is a very good estimator, it's got some several canonical structures and you can show canonically its capacity achieving in some sense, okay, so you can read chapter 8 from Barry Lee and Mr. Smith to get more idea on this, I'm sorry, among the unbiased estimators, that's the lowest MMSE, if you bias it, you might get a lower MMSE, okay, but that doesn't mean you necessarily gain in terms of probability of some variable, so you have to be, so these are all some slightly advanced concepts in estimation theory, I don't want to just generally throw it at you, but I want to just point out that bias of the estimator is an important thing to keep track of, particularly when you slice at different points, okay, so since I've been mentioning about this mean square error, you shouldn't think that the mean square error is the best thing to do, okay, so because the calculations tend to imply that, you should also keep in mind that mean square error is only a rough indicator of what the actual problem is, particularly when the noise is non Gaussian, when you expect some signal components to be, okay, so bias is also important, okay, all right, so with this, we'll close the unconstrained complexity part, we'll move on to the constraint complexity, so if you have any questions on any of these things, now is a good time to ask, did you have a question, you seem to be not very happy with this, what? Which is better is unbiased MMSE DFE, if probability of symbol error is what you're looking at, right, it's better, any questions? So the assignment is already up, hopefully some of you saw it, there's a whole bunch of practice exercises and do it and make sure you stare at the final answer you get for the different situations and try to get some intuition out of it, okay, so that's the point of the assignment, it's got lots of questions, might sound repetitive to you, but don't just do it and forget the answer, okay, so look at the answer for a while, it'll give you some ideas, if your channel has a pole and if your noise also has a pole in the same part, same point, then some interesting things happen, if your channel has a zero and the noise also has a zero at the same point, some interesting things happen, lots of interesting things can happen with respect to noise being non-white, okay, and if noise is white, what happens when you have a pole in the channel, what happens when you have a zero in the channel, all that is also important, okay, so before I close, I just want to make a comment about Viterbi when you have in the general model, okay, so how do you run Viterbi when you have a pole or something in the channel is a question that's always complicated, so what you do is, after the precursor, what kind of a channel do you have, after the precursor you have a, usually you have a causal channel, right, so look if you think of after the precursor, you have a causal channel and it's also minimum phase in the sense that you equalize minimum phase, right, so you can approximate that and run a Viterbi at that point, so that's a structure is sometimes used, so you do a precursor equalizer to get your response to an approximate causal finite type version and then run a Viterbi on it, it's possible to do that also, okay, so I'm not talking about it because it's a point analyzing that, it's just a simulation based thing, so that's something you can try, after the precursor, your response actually becomes causal and minimum phase and nice, so you might want to run a Viterbi there, okay, so that's something that's done, okay, all right, so we'll stop there and move on to constraint complexity equalizes, okay, so we've been seeing a lot of things in this class and I've assumed a lot of background, right, so I've assumed that you know probability quite well, that you know DSP quite well, that you know the network systems part quite well, right, I don't know for those of you who are at least following the class or you feel scared of all the terms I'm using, you must surely know that all these things are being used in this course, everything is coming together in this course, right, only thing that I'm not using is probably Laplace transforms, okay, other than that everything else that you have learned has been extensively used in this course, okay, so now this constraint complexity equalizes, we're going to use one more area which you should have learned by now, okay, and that is fair amount of linear algebra, okay, so if you thought everything is not quite coming together, there are some things that you learned which are not being used in this course, if there is one final missing piece, okay, so if you're not, so one thing I'm going to urge you to do is I'll do it as you, as you, as I, as I keep going through the course, you'll probably notice a lot of things happening, so are enough, many of you doing the 515 course math methods, nobody's doing it, you're doing it, okay, so if you're doing that then you won't have any trouble, but if you've forgotten eigenvalues, eigenvectors, what is a positive definite matrix, what properties it has, all those things, it might be a good idea to go take a basic book in linear algebra and quickly refresh, okay, so I know a lot of people do basic matrices in your high school and for your JEE and after that you think linear algebra has nothing else, okay, and you happily sit back, relax and enjoy, okay, believe me, it's way more complicated than that, okay, so there are some very innocent looking problems in linear algebra which require a lot of theory to be solved, okay, so and we'll use some part of it here, fair amount we'll use, but this is a good opportunity for you to go back and revise linear algebra, okay, so it's a very useful tool, all right, so here's how our structure is going to look, okay, so I'm going to have SK which is my signal symbol, just going through a channel HC, okay, once again I'll assume a symbol rate sampled equivalent, okay, so that's a, so I'm going to have a front end which is like a low pass filter or something and I'm going to sample at symbol rate, so equivalently I would have a H of Z in the symbol rate world, okay, so that's my model for H of Z and then I have complex noise, okay, all these things are complex also, adding to it, okay, so I get my input ZK, symbol rate input ZK, okay, so to this I'm going to apply first a precursor filter C of Z which is of course going to be a finite type filter because I want to constrain my complexity, okay, and then I have a slicer, okay, so all these things are inspired by the previous constructions, okay, I have a slicer and then I have a post-cursor equalizer, okay, again finite type post-cursor equalizer, okay, so hopefully I get an estimate of SK at the output of the slicer, okay, so this is going to be my model, I'll call this the precursor equalizer, I'll call this the post-cursor equalizer, okay, so if I have, if I want to think of a linear equalizer, okay, what would I do? I would set the post-cursor to 0, okay, it doesn't exist, d of Z would be 0, so that would go away, okay, so both of them, both the DFE and the linear equalizer can be nicely modeled with just this one structure, okay, so if you want a linear equalizer only without a DFE, simply make d of Z non-existent, okay, so that goes away, all right, so again once again inspired by the previous constructions, we will select these tabs of C of Z carefully, okay, so I'll say C of Z has this form minus L to L Cm Z power minus M, okay, so I'm going to pick a two-sided response for C of Z, precursor as I expect, okay, and d of Z I'm going to pick as a strictly causal m equals 1 to L dm C, is that fine, okay, so that's how I'm going to pick, oh I had L for some other notation, really, I thought I always used size X or something, no, size X I took as L, oh L number of L, okay, okay, no, no, no, so maybe I need a different notation for it, I forgot about that, okay, so SK we said L, right, so this is not L, so I need another notation, so what can I use, capital M, is that, no, M we've been using all over the place, P is okay, okay, so minus P to P, seems like a safe, safe thing, I know I can do that, I know I can do that, so L doesn't really make sense, I might as well have L here, but since you're objected we'll have P, we also find it, okay, okay, so once again d of Z will be 0 for DFE, okay, so for linear equalizer I'm sorry, a linear equalizer and for the DFE it will be non-zero, so that's how we'll pick our Gaussian complexity equalizes, okay, any questions on the structure, the structure is fine, okay, so we'll pick, okay, so now, okay, so all right, so I said, so we're going to use linear algebra of course, right, so you'll see suddenly things will become vectors and matrices, that's the whole point in linear algebra, right, so I don't know if you're familiar with this convolution with the finite-tap filter can be conveniently represented as a matrix multiplication, okay, so that's useful and various things we'll see as we go along that that's useful, so that's the basic trick we'll use to move from signal domain to matrix domain, right, so we'll represent signals as vectors then convolution as matrix multiplication, so that's what I'm going to do next, okay, so keeping that in mind, the first thing I define is a vector zk which is a column vector which goes from zk plus l down to zk down to zk minus l, okay, okay p, so now there'll be trouble with me having to replace l with p everywhere, okay, so remember this is not a constant vector, the vector keeps changing with k for different k you have a different vector, okay, so how will you modify what is zk plus 1, push it down and then add the next k in the top, okay, so this vector one can imagine is useful for someone who's trying to implement the receiver, okay, if you're trying to actually implement the receiver you'll be getting this zk's, after your front end you'll be getting this zk's, so you put them in a in a register which is probably rotating or shifting that way, okay, and then you process only this vector, okay, the reason why you process only this vector is the output of the precursor is what? Output of precursor is you write typically zk convolved with ck, right, and then if you write it properly m equals minus l to l cm z k minus m, so you notice the kth output of the precursor depends on what? Depends on c of course on all values of c, but for z it depends only on zk, okay, on this vector zk, okay, so in fact you can write this very conveniently as c transpose zk, what would my c transpose be? c minus l c 0 c l, do you agree? So c in fact is a column vector, okay, c transpose is a row vector like this, okay, so the output of the precursor has this very convenient form, okay, so that's what the precursor is doing, okay, so you might have traditionally thought of it as a filter, the filter does nothing but multiplication by a row vector, finite type case, okay, so this is how we implement it, so this is a nice way of visualizing how to implement filters and practice, okay, so that's see remember all these things are complex, every one of these entries are complex in these vectors, okay, so it's not it's not scalar, it's not real, okay, okay, so what we're going to do now is first see linear equalizers, okay, so if I see linear equalizer then there's no feedback from the slicer, right, so d doesn't exist, okay, everything I want to optimize with respect to, is with respect to only c, okay, so I have to pick only c of z, so I'm going to look at linear equalizers first and now for linear equalizers there are several possible criteria, okay, there are two possible criteria that we saw, the first one is the zero forcing criteria, the second one was the mean square error criteria, okay, the zero forcing criteria is, we saw it's not as good as the mean square error criteria typically, so I'll do the mean square error criteria, okay, so that's what I'm going to do, okay, so we're going to see the mean square error linear equalizer, okay, so of course moment I say mean square error, you need to worry about the error itself, okay, so I'm going to define the error, okay, so let's see, let me just draw a picture before I proceed, okay, I'll call the output of the precursor as x and this is going to go through the slicer, there is no other filtering and you get this hat which is a cell, okay, that's fine, okay, so my error signal is going to be defined as xk minus sk, okay, so xk I know now can be written as c transpose zk, okay, well you have a minus sk, okay, so to move towards the mean square error, we're going to do expectation of mod e k square, okay, so now I have to think of everything as random process, okay, so first of all sk is going to be a random process, usually you assume sk to be the iid uniform random process over the alphabet x, okay, so maybe something else is also possible but we'll assume that to be random process, okay, so likewise here c is going to be a deterministic vector, okay, so there is no there's no randomness here, this is going to be constant, zk is going to be what, it's going to be a random process as well but it's a vector valued random process, okay, so it's slightly complicated, okay, so don't think of zk itself as a random thing but basically you think of this as a vector from the random process, what, zk, okay, so that's the best way to think about zk, the vector zk is basically a vector from the random process zk, how do you, how do you find zk, zk is nothing but sk convolved with hk plus nk, okay, so assuming I know hk and the statistics of nk, I can quite easily find the statistics for zk, okay, so but I have to know hk, if I don't know hk, I cannot find the statistics for zk, okay, so for now when we do the computation we'll assume we know hk and nk so that we can find the statistics of zk, so what are the statistics I might be interested in, typically you always make the white sense stationary assumption, so once you make the white sense stationary assumption out of filtering and computing mean square error the only statistic you'll need are first and second order, okay, so you'll need mean and auto correlation but be careful about auto correlation, these are complex valued processes, so auto correlation value is slightly defined slightly differently, I'll write it down as we go along, okay, so I'll assume white sense stationarity in fact jointly white sense stationarity, joint white sense stationarity of zk and sk and all that, okay, so all these things we'll assume sk and k are jointly white sense stationary, so that it's meaningful to define auto correlation and cross correlation etc, okay, so that's the thing, those are the things we'll be interested in, okay, so let me just quickly write down the expression for the mean square error and then we'll probably stop there is the expected value of mod ek squared, okay, so you're writing it in terms of vectors, so a lot of char is required, okay, so I'm going to write the conjugate term first, okay, so look at the first term, the first term is actually a real number, right, it's a product of two vectors but it's a real number, so when I conjugate and all that I can be happy, there's no problem, so I'll write c conjugate transpose zk conjugate minus sk conjugate, okay, so notice my notation here, star means conjugate, transpose means transpose, star transpose means what? Conjugate transpose, okay, so there's all kinds of notations possible here, different people use different notation, just to emphasize all of that I'm going to put this, okay, so remember that, okay, and then I'm going to do c transpose ck minus sk, all right, so that's the first step, we've written the mean square error in terms of these vectors, okay, so now you see what the modus operandi is going to be, okay, so you've written the mean square error in terms of c and you know the statistics for everything else, so when you pull the expectation inside, c will kind of nicely come out and you're going to optimize the mean square error with respect to c and find the best possible c, so that's the flow here, that's what I'm going to do, okay, so from here on it's just simple plain linear algebra, okay, there's nothing more to do, okay, so the intuition is from the channel and signal world has given us a nice simple linear algebra problem which we have to solve and find the best possible, okay, so but to do that it's algebra, okay, so you have to manipulate, play around with the terms, see what comes out, try to get some more intuition about the problem and then finally try to solve it, okay, so let's do the first step of simplification, okay, so the first product that I'm going to write down is the easiest term you can write down, expected value of mod sk squared, right, so that comes from the last, the two terms, the second terms multiplying, okay, and then you'll have a bunch of cross terms, okay, so I'll come to the cross terms later but before that I'll write the other square term, okay, so what is this, this product, c conjugate transpose zk star multiplied by c transpose zk, okay, so when you write product of several matrices you have to be very careful with brackets, okay, so you know this is a real, this is a number scalar, that is a number, so if you put brackets around each of these you can multiply but if I want to remove the brackets I have to be very, very careful, okay, for instance if I just write all the four matrices together it may not make much sense, okay, you have to be careful, okay, the way you write it, okay, so you should make sure that things are compatible and you write it nicely so that expressions become easy to evaluate, okay, so the way to write that very nicely is to pull c star conjugate out, keep the expectation inside and write zk star and zk transpose, okay, so remember this term is also equal to zk transpose c, okay, so the way I write it I do that and then I would get a c out here and then there would be cross terms, okay, cross terms I'll write in the next page, okay, there are cross terms so you have not written here, all right, at least the first two terms are easy to see and the cross terms will come in and we'll simplify, I think this is a good point to stop and pick up from here in the next class, okay, so we'll start simplifying things in the future, okay.


So, let's meet some of Mr. Verloc's friends. There's Michaelus, or Michaelus, I'm not certain how to pronounce that, speaking in an even voice, a voice that weathed as if deadened and oppressed by a layer of fat on his chest. He had come out of a highly hygienic prison, round as a tub, with an enormous stomach and distended cheeks of pale, semi-transparent complexion, as though for 15 years the servants of an outraged society had made a point of stuffing him with fattening foods. That's the great oppression for which these guys are trying to destroy society. This chapter actually opens with Michaelus reading, and the little passage that he reads reminds me of another criticism of Marxism by Ludwig von Mises. He says that Marx had no rebuttal to the economists of his time. He was kind of able to corrupt and adopt like Smith and Ricardo a little bit, but they were already in their graves. The economists of his time had many objections to Marx, and so according to this Mises criticism, I believe it's in the book, Theory and History, or is it called Philosophy and History? I think it's called Theory and History. Mises makes the case, the very strong case in my opinion, that Marx invented dialectical materialism so he could dismiss the economists saying that all human thought is the result of your material conditions. He never reconciled this with his own undeniably bourgeois background, but he said all thoughts and all words and everything is the result of material conditions. Therefore, if an economist is criticizing this, he's just an agent of his social class and doesn't even deserve to be dealt with. And there was a sort of anti-economics that Ludwig von Mises writes about just this insistence on just not addressing economics and not trying to envision or explain how a socialist society would work. Instead, there was just criticism of the status quo and almost nothing else. So here, this little passage of Michaelis kind of reminded me of that. Capitalism has made socialism and the laws made by the capitalism, it says the capitalism, for the protection of property are responsible for anarchism. No one can tell from what, no one can tell what form the social organization may take in the future than why indulge in prophetic fantasies. At best, they can only interpret the mind of the prophet. I guess they're referring to Marx although they don't do so explicitly. There's another page in here and I didn't find it as I was preparing, but without any sense of irony, Michaelis, who is so fat that he runs out of breath just talking to people, he makes a reference to the well-fed rich having to protect themselves against the starving proletariat without any sense of irony. Anyway, the next friend of Mr. Verlox we meet in this little circle is Mr. Carl Yund, Carl Yund, hears him talking. I have always dreamed, he mouth fiercely, of a band of men absolute in their resolve to discard all scruples in the choice of means strong enough to give themselves frankly the name of destroyers and free from the taint of that resigned pessimism which rots the world. No pity for anything on earth including themselves and death enlisted for good and all in the service of humanity. That's what I would have liked to see. Then he argues with Michaelis on whether they should be pessimistic or optimistic or logical. Mr. Yund's nickname is the terrorist. The famous terrorist had never in his life raised personally as much as a little finger against the social edifice. He was no man of action. He was not even an orator of torrential eloquence. With a more subtle intention he took the foam or he took the part of an insolent and venomous evoker of sinister impulses.  Beautiful writing. There's a comrade Alexander Ossipon. His nickname is the doctor because he had once been a medical student, but he dropped out. Here Michaelis, this goes back to the absurdity of dialectical materialism at least as criticized by Ludwig von Mises the idea that everything is the result of material conditions. There's a very small contradiction in this paragraph which I think demonstrates the contradiction that Mises was pointing to in his criticism of Marx. Michaelis is talking, revolutionary propaganda is a delicate work of high conscious. It is the education of the masters of the world. It should be as careful as the education given to kings, one of the classes they're trying to overthrow, but nevertheless. And then he says, for history is made with tools, not with ideas.


Deadpool is not an SCP, but if it were, how would the SCP Foundation contain it? Hello, I'm Dr. Theron Sherman and in this series we construct hypothetical containment procedures for non-SCP popular culture entities and objects. Let's begin. Ah, Deadpool. The merc with the mouth. The regenerating degenerate.  Deadpool has quite the arsenal of powers, skills, weapons, and gadgets. Powers-wise, we're looking at regeneration, enhanced strength, enhanced speed, resistance to psychic assault, and some toxins, and of course, fourth wall awareness. For skills, the mercenary boasts knowledge of multiple martial arts, enhanced athletic prowess, and is an expert marksman and swordsman. The subject is always armed with its signature weapons, swords, guns, knives, and grenades. It also uses gadgets such as holographic projectors and a variety of teleportation devices. The first step in standard containment would be an overdose of tranquilizers to sedate the subject, possibly hidden in a chimichanga. This will give our agents ample opportunity to disarm and bind the subject, Hannibal Lecter-style. Can't have any of those fancy martial arts being used on our researchers, can we? Our focus of study would be Deadpool's healing factor. Using a combination of the mutant inhibitor collar featured in Deadpool 2, along with different healing-centric SCPs, we could learn much from our new guinea pig without accidentally letting its cancer cause it to shuffle off its mortal coil to its waiting girlfriend's arms. One last thorn in our side we need to worry about is Deadpool's quote, Insanity, that allows it to realize that it is a fictional character. Well, I should say, thorn that we don't need to worry about at all, because Deadpool isn't the only one who can play the fourth wall breaking game. In one of the many SCP-001 proposals, specifically S. Andrew Swann's proposal, the Foundation collates the data from all SCP documents into a single extra-universal server that realizes that articles are being added, updated, and deleted with no rhyme nor reason. Or no rhyme nor reason until they realize the truth. They are fictional characters in a universe created by SCP-001. Us, the SCP authors. Beyond that, we have the Pathophysics Department, which is a fictional department created by the Foundation for the containment of metafictional entities. So, the fictional foundation created a fictional department, and that fictional department deconstructed an intrafictional character into a depressed shell of its author using an unfinished version of its character manuscript that they straight up made up in order to contain it, and now I've gone cross-eyed from confusion. Sure, it nearly figured out the game and got away, and also nearly deconstructed the Pathophysics Department itself in the process, but you know what? Deadpool's best fourth wall breaks are information gathering, not bending the universe around its will. So we're gonna be fine, I hope. Make sure to like and share this video, comment any creatures you would like to see containment procedures implemented for, and if you want to help us make bigger and better SCP projects, become a patron at the link in the description. Secure, Contain, Protect.


Did you know that scientists have been digging up dirt on soil for centuries? From Vasily Dokutayev, the father of soil science in the 19th century, to Hans Yenny in the 20th, and numerous mines at the frontier of soil science in the 21st century and today, researchers have been studying how soils form and build up organic matter. Most recently, they've been building big data models that predict how soil carbon and essential component of soil organic matter will respond to Earth's rising temperatures. With the introduction of large-scale data collection programs like the National Ecological Observatory Network, scientists are now better prepared to answer long-term questions about soil health, the fate of soil organic carbon, and CO2 exchange between the atmosphere and soil. Soil is made up of air, water, minerals, organisms, and organic materials. Within soil, most concentrated near the surface lies soil organic matter, or SOME, which consists of plant, animal, and microbial tissues in various stages of decomposition. Living organisms like worms, bacteria, and fungi are key to turning this dead matter into stable SOME. SOME plays a key role in many soil functions. It promotes infiltration and increases water holding capacity and soil fertility and reduces erosion. Although SOME only makes up less than 15% of the mass of many soils, at the global scale it contributes a huge volume of carbon. When added up across all terrestrial ecosystems on Earth, soils are currently storing an estimated 2,500 billion tons of carbon, almost twice the amount that is found in our atmosphere. Roughly 50% of SOME is actually carbon, that if decomposed will create carbon dioxide. Along with carbon, nitrogen, phosphorus, and sulfur are also stored in soil organic matter, and are eventually released to be made available for plants to take up when SOME is decomposed. In a healthy, undisturbed, or mature ecosystem, there is a general balance of CO2 uptake by plants, and the CO2 created in soils from decomposition. This is called a steady state. However, the degradation of many ecosystems through climate change, land usage, agricultural practices, and other human activity and disturbance has led to the decreased ability of soils to store carbon, compared to the increasing CO2 that is released by our ecosystems. In this case, the steady state is unbalanced. Why are healthy soils good at storing carbon, and how does it get locked away in soil organic matter? There are several ways carbon can be protected from decay. It may be prevented from decomposing in wet and cold environments, or interactions with soil minerals. It can be stored away inside soil aggregates, or it might remain because the organisms that typically break down SOME might be absent. With new, advanced measurement techniques, we are able to get an exciting look into carbon cycling and storage in soils. Open data and samples from the National Ecological Observatory Network can contribute to this understanding. N-C2 measurements can observe carbon cycling in place. For instance, eddy covariant systems continuously measure CO2 exchanged between soils, plants, and the atmosphere, while below-ground sensors constantly measure the amount of carbon dioxide in the spaces between soil particles. In addition to these instrument measurements, we can make high-resolution molecular measurements of the composition of SOME and the organisms that break it down. NEON collects soil samples throughout the U.S. at regular intervals for scientific research. These samples are collected, processed, and shipped to the main NEON biorepository in Arizona for storage, where they can be freely requested by researchers. Methods such as radiocarbon dating can help us understand how long different kinds of organic material persist in soils, and advanced spectroscopy techniques reveal the exact chemistry of soil-organic carbon, which helps us understand how it forms. Combining these measurements with microbial community analyses can give insight into how soil organism shapes SOME dynamics. Scientists learn more every day about the fine-scale dynamics of carbon cycling within soil-organic matter, and how stored carbon can have broad implications on overall soil health and the carbon cycle. Measuring these carbon stores and exchanges is critical in providing data that better-informed scientific models develop to predict future soil-carbon concentrations. It's important that we, as a society, better understand why and how carbon concentrations in soils are changing, so that we might learn how to mitigate rising CO2 levels in our atmosphere that contribute to climate change. Can you dig it? To learn more, visit neonscience.org


Hello there, this is Bhavya Kaushal and here are 4 news that rock the tech world this week. Whether it is a car bursting into flames or Elon Musk facing flak for missing deadlines, tough times seem to be far from over for Tesla as yet again the company reported a wider than expected loss of $702 million at the end of the quarter. On one hand there is Tesla facing grave losses and on the other hand there is tech giant Microsoft Corp which briefly topped $1 trillion in value after strong earnings in the quarter. Facebook and Instagram face a ban in Sri Lanka. The government announced that after the horrific Easter bomb blast the government has decided to ban social media sites to curb false news. If you think that older workforce is a burden on the company then you must take McDonald's


My name is Andrea with Foodimentary Adventures in Food.  On our channel, you'll find simple and tasty dinners using everyday ingredients. So today is Valentine's Day and Howard went and picked up dinner for us. We both got the same exact thing, Hibachi chicken. So let me show you what came with that meal. So it came with a side salad. And then we ordered two appetizers. We ordered a Korean pork belly. It doesn't look like what we thought it was going to look like. We thought it was gonna have sauce on it and so forth. So anyway, we got that. It's a new place for us. And then we also got an order of spring rolls. The dinner came with an onion soup, which is right here. And then you can pick fried rice or plain rice. We both got fried rice. And then here is the chicken. Get it open. So here's what the chicken looks like. And then it came with a bunch of different types of sauces. So this is what we are having for dinner tonight and we will see y'all next time. So for dinner tonight, we are having beef short ribs. So in my pantry, I had two packages of this Korean barbecue seasoning mix and each package seasoned one pound of short ribs. So that's what I did. Howard actually grilled out these short ribs. So I didn't feel like the seasoning by itself had a lot of flavor. So I added this Korean barbecue sauce in as well and Howard and I tasted the short ribs and they are very good. Along with the short ribs, I stir fried some fresh broccoli and the seasoning that I used is this and also some onion salt. And then I had some leftover white rice in the fridge so I decided to make some fried rice and this is a seasoning mix that I used. I've talked about it a lot on our channel and I just added in some green onions and shredded carrots as well. So this is what we are having for dinner tonight and we will see y'all next time. So for dinner tonight, we are having orzo pasta with spinach and Parmesan. This is a recipe that I have made on our channel before we really like it a lot. I'll make sure to link that recipe in the description box. The only difference is that this time I added in some fresh mushrooms. I sliced them up and sauteed them right along with the spinach and then on the side, we are having panko shrimp from Costco. It is really good. I have talked about this shrimp before on our channel. We just tried it recently but it is really, really good. I just cooked it in the air fryer. It's probably my favorite panko shrimp on the market. So this is what we are having for dinner tonight and we will see y'all next time. So I am making taco salads for dinner tonight and this is a taco seasoning mix that I used. I have had this forever and I finally just finished the last of it.  But anyway, I just prepared the taco meat according to package directions and it may seem simple but all I do is just add a couple of heaping tablespoons of salsa and I am using the Aldi restaurant style salsa. It just adds a lot of flavor especially if you don't add onions and peppers and things like that to your taco meat. I've been doing that for a while and it just makes such a difference. So you just stir in a little bit and just let it continue to heat and it is de-lish. Okay, so here's our taco salads. This is Howard's plate. He has lettuce, ground beef, cheese. The cheese is actually a white cheddar cheese and he also has sour cream. Here is mine. I have the same thing except I do not have sour cream on mine. And if you've been with this for a while you know how much I love these taco salad shells. Here's what they look like. They're kind of hard to find in my area.  I've never had a problem with freezing them at all but I don't think I've ever opened up the package to let you all see what they look like. I don't think, I can't remember. But anyway, they come with formers, four formers and then four shells. Now it says that they are flour tortilla shells. I just wanna show you the texture because they don't exactly look like, sorry, here it is. They don't exactly look like a traditional flour tortilla.  So that's what they look like.  I have a bunch of different like baking mixes and my pantry that I needed to use. And so this is a small one that fits an eight by eight pan. And so I decided to make them in muffin tins because I prefer the corners of a brownie. And from my stash, I use these candy pecans. I chopped up some and put them on the bottom of the muffin tin. And then I also had some mini peanut butter cups that I added in as well. So this is what we are having for dinner tonight and we will see you all next time. So today I'm trying out a new recipe for creamy cabbage soup in my pot here. I have some chicken broth and some onions. I'm adding in some cabbage. And by the way, of course, I'll make sure to link the recipe in the description box. And I am adding in some carrots and some celery. And I'm just going to let this come to a boil and let the vegetables get nice and tender. In the pan right next to me, I have some butter melting. As soon as that is melted out, I'm going to get started on a roux. Okay, so I have my flour and butter mixture right here. I added in some salt and pepper. I did accidentally let my roux get a little bit too browns, not what I was planning on doing. But to that, I'm getting ready to add some half and half in milk. And I'm just going to let this come to a simmer and thicken up just a little bit. Okay, so I've got my vegetables boiling and they've gotten tender. Now I'm just adding in my cooked ham. And I am going to add in that cream and milk mixture. And I am just going to let this continue to cook for about 20 to 30 minutes. I'm just gonna let it simmer. So here's the soup. I tasted it. It is really good. I like it a lot. I will definitely make this soup again. It's creamy and rich and hearty. So this is what we are having for dinner tonight and we will see y'all next time.