And so it's on to you, Ms. Julia. Great, thank you everyone for joining. I will be sharing my screen and starting the slides. Yes, so thank you for joining our presentation. We'll be talking about OER awareness and adoption trends in the US higher education through the COVID-19 pandemic. My name is Julia Seaman. I'm a director of research at Baby Analysts, as well in the room we have Jeff Seaman, who will be helping out with the chat and any Q&A at the end as well. So feel free to ask questions during the presentation that he can maybe answer or we'll get to at the end. So then this presentation, we'll go through an introduction both to Baby Analysts as well as a survey that we've been performing. Talked about the pre-pandemic growth of OER. Specifically, we'll look at the COVID-19 impact that we were able to measure with our survey last year and then take some steps and looking at the future of OER. There will be some poll questions as well as time for Q&A at the end. For the poll questions, we'll just be using either the Zoom chat or you can feel free to just to think your answer and see how it compares to the correct answer for a few of them or like the general population. So jumping in, my name, as I mentioned, is Julia Seaman. I'm a director of research at Baby Analysts. Baby Analysts is a consulting firm that focuses on survey design and statistical research. And as I mentioned, Jeff Seaman, who's also director of Baby Analysts, is in this room as well. We'll be monitoring the chat throughout. Relevant for this project is our long decade worth of research, specifically on OER. So we have been conducting higher education surveys for over a decade. For our higher education group, you can see the years that we performed the surveys in this slide, as well as the fact that we do have three additional surveys planned over the next three years. And in fact, we're about to roll out our survey for this year. And so this survey researcher that I'll be showing today incorporates over 26,000 respondents across 10 surveys. This work specifically today is on higher education, but we also have a corresponding survey in K-12. And so all of these reports that we have done are available on our website, which is babyoanalytics.com slash OER. So some of the background of the survey, so this survey was designed and given out with the goal to understand the role of OER in higher education, as well as to quantify perceptions and awareness of OER. And so in order to do this, we sent our survey out to higher education admins, faculty and chief academic officers. So those are our main respondents. And then the survey was sent out first by mail in the early years. And now we just do it digitally through email and links. But every year that we do this, we do make sure that it is a nationally represented group of respondents. And that includes both for overall geography around the US, as well as the type of institution that people are teaching at. And that way we can be sure that the responses that we're getting in aggregate are very good representative sample. And of course, we wouldn't be able to do the survey without the support of our sponsors. And first and foremost, our sponsor, the William and Flora Hewlett Foundation, who has sponsored the survey through this entire time, as well as our report sponsors, the OLC Pearson Alpha Peace Loan, as well as Kaplan. So one important thing for this survey and survey design is that we went into it with the goal to be able to track year over year changes. And in order to do that, we had to make sure that the questions that we use were very similar and standardized every year. And that means, and what I'll be showing in this presentation, is from the last seven years, we've asked a very similar question around OER awareness. And so that allows us to compare our responses year over year, and therefore be able to track these trends and have confidence in the trends that we are showing. And so for the technical work, we also as well make sure that we use the same definitions in the surveys and reports, specifically around what we're defining as OER, which you can see the full definition list of here, as well as what is important related to OER are the licensing types, specifically public domain and creative comments. So jumping to the first poll question, how much do you think OER awareness has changed since the 2014-2015 academic year? So if you want, you can put in chat which letter you think the answer is otherwise. Feel free to just guess and we'll get to the answers soon. I'm seeing D's and E's, a few C's coming up. Looks like most people, no one's really saying declined, but slightly leaning towards the increased 20 to 30%. All right, so we'll jump in. And so jumping in for our last report, for the fall 2020, we specifically asked the faculty, how aware are you of OER? And you can see from our results that the majority of faculty claims some level of awareness for OER. And so that is asking them and having them self-report, are they very aware, aware, somewhat aware or not aware? And we like to use these three different variations of awareness in order to really distinguish between people who we feel are truly aware can be like understand what OER are. And that is the very aware and aware category as well as give people who do have some name recognition, maybe not understand what the concept is or how to use it, a way to answer the question, which is that somewhat aware category. But overall here, we see that over a majority of the faculty are somewhat aware of OER and that in fact, almost one in five can be very aware of OER. However, now that I've shown you this graph, I'm gonna ask, can we actually trust it? And so what we've actually found out through our research is that strictly asking faculty, are you aware of OER? It's not actually a very good measurement of OER awareness. We can't trust those numbers exactly. And that is because OER awareness is still growing and therefore there's a lot of faculty who may actually be confusing OER with things that are free or things that are open source. And therefore the answers that we're getting to this question alone may be imprecise. So what will we come up with is an improved measurement for OER awareness, which requires the combination of both OER awareness as well as the Creative Commons licensing awareness. And so therefore we count people who are aware of OER if they are aware of both Creative Commons as well as OER. And so this creates a stricter index of OER awareness. And so when we show this change, we can see the original graph on the left and then when we adjust it, we actually lose roughly 9% of the people from the aware categories. So using the stricter definition, just under half of the faculty are aware of OER at any level. And so you can see it goes from just over half to just under half. And so this means with the stricter definition that two in five faculty are very aware or aware of OER from the last year. So as I mentioned, we've been doing this question for multiple years. And so on this graph, I'm showing you that same stricter definition of OER awareness, Incorporate and Creative Commons awareness and the growth that we have seen year over year. So for our poll question, the correct answer is increased 20%. The exact answer was 23%. And so what has actually been great to see is that this increase, there is a increasing every year. But we see both an increase in the total number. So the whole bar gets bigger as well as the number who are actually growing aware and the level of awareness is increasing. And so you can see that because the number who are very aware keeps growing as well. And so one thing we will note is that when we are looking at people who are aware of OER, we do see that cost is a commonly cited factor for why they are aware or why they're using OER. So as well as tracking OER awareness, we do also look at OER use. What you can see is that OER use overall is a bit less than OER awareness. And we also see that there are some differences between the type of use depending on the courses that the faculty teach. But overall there is growth year over year between the use of OER as a required course material and as a supplemental material. Though the growth in required materials much greater, though was slowed in the last report that we did. We also note that faculty teaching introductory courses are more likely to use OER as a required material. That may just reflect the types of material that are well-known and available in OER. Because that disparity is also much less when we look at any type of material, such as any supplementary material between the faculty. So in conclusion for this section, I've shown you that OER awareness and use has grown year over year, but there does remain a big confusion about what OER is and how it can be found. Not explicitly shown, but what we've seen in the comments that OER is a tool aligned with current efforts to reduce costs, improve opportunities for marginalized students and provide materials that follow new teaching standards offering adaptable educational materials. And so I pulled out a few quotes here which are sort of emblematic of some of the issues facing OER right now. And this first poll is around the support that while there is vague system-wide statement in favor of OERs, there does not seem to be actual teeth or real support for it. And so this sort of helps explain why there's a higher level of awareness than there may be of use or implementation of OER. And then the next quote is really around that confusion when it comes down to OER and the licensing. And this is a faculty who mentioned, I'm not entirely clear as to how OER and educational fair use overlap. And while I'm well aware of both concepts, I suspect that most of my colleagues are quite unaware of them. So this is really speaking to that there needs to be a lot more education within and to faculty to help them understand the different licensing and different types of materials that are available to them and how they're able to use them. And then finally, this last quote should have references that I mentioned to improving opportunities for marginalized students and helping students receive the best materials that they can and diversified materials to help improve student learning. All right. So then we'll move to the COVID-19 impact. And so this is really focused on some of our questions in our last report about how the pandemic has impacted faculty use and faculty textbooks and OER awareness. So going to our second poll question, what proportion of faculty talk face to face in fall 2020? I'm seeing these season Ds come up. Not sure, full consensus, but okay. This one will jump right in. And so as you may expect, the fall pandemic shifted a ton of faculty to online instruction. And so from this graph, you can see that compared to 2019 where we see 96% of faculty reporting teaching face to face, only 14% were teaching face to face. So that was B for our poll. And so what we saw obviously the fall term was a major shift away from face to face to online classrooms. And so online, including both fully online as well as blended. And then we also saw, and we'll be showing that this change in teaching status had a large impact on the type and use of classroom materials that were used by these faculty. So starting in, we see that the pandemic drove course changes. And so we specifically asked faculty, how does the version of the courses they're teaching at that moment in fall 2020 compare the previous terms? And so we can see that two thirds of the faculty stated that their courses were moderately or considerably different. And then when we asked what was the reason for the changes to the course, 97% said the changes were fully or partly due to the pandemic. And so this is a major shift in courses. We generally do not see this year over year. So we went in a little further to figure out so can we quantify what some of these changes were specifically related to OER and textbook use? And so when we looked at the textbooks we asked what were the changes? And so what came up for the fall 2020 were actually a few options around the digital materials. And so while they weren't a majority, it was quite interesting how many faculty did some digital component to their textbook, either adding an option, switching to all digital or moving to an inclusive access arrangement. We also see that a lot of faculty over half did use a new edition of the textbook, but that is often a normal change year over year for faculty to do. When we look specifically at what the changes to the required textbook, we actually see that while the courses were markedly different, the faculty were actually using the same textbook than they were through the previous year's courses. And so we see only one in 10 faculty reported a change to their textbook. So this sort of indicates that some of the changes for the courses may have been outside the textbook itself. And we saw some of that come up with the number of materials that we looked for faculty requiring in their courses. And so while the number of textbooks was the same from the prior year to fall 2020, we do see that there's a larger uptake in other supplementary materials such as article case studies and homework, online homework systems. And so those sort of show that there's a growth of supplemental materials over the COVID-19 pandemic teaching. We also were interested in to know how institutions may have been helping the faculty when it comes to options and initiatives updating their course materials. And so we specifically asked the faculty if their institutions took steps to provide course materials. And so on here, you can see that while the largest number reported was for the institution's buying open educational resources, it was only for 18% of the faculty reporting that. So overall institutions we saw were largely hands off when it came off to updating course materials. Interestingly, we did see a slight difference when we looked at institutions that were minority serving versus the other institutions. And so those institutions were much more likely to provide information on OER and much less likely to provide information on publisher agreements. So it was an interesting change between those types of institutions. We also asked faculty, not just their awareness of OER itself, but their awareness of OER initiatives. And so in fall 2020, where we might have expected greater awareness of initiatives to grow because of the push to online materials that we might expect them to have become sorry, institutions were pushing OER and the OER textbooks and things might be growing and trying to get their attention as the shift to pandemic teaching. We actually see very little change year over year for the faculty awareness of OER initiatives. And so that's at multiple levels, the institution system line department. But this may also be related to the fact that faculty were incredibly busy and so may not have been able to pick up even if the actual output and sort of noise coming from the initiatives may have grown. And so further section wanted to show you that the COVID-19 pandemic had forced many classrooms to shift to online instruction quickly. We also saw that the majority of faculty adapted by changing their existing courses and supplementing with digital materials to the same textbooks as prior years. We note that the institutions mostly took a hands off approach with some providing information on alternatives but faculty either acting alone or as a committee made the final decisions. And then overall, we did see and this is going back to the prior section as well that there was a limited impact to OER awareness and use. And so this is a quote here that I really liked which is coming up that nobody likes changes and most people only change when forced to and that's what the pandemic has done. And so some things, activities, assignments, interactions were rendered difficult and possible or dangerous by the pandemic but some new ways of teaching have arisen from necessity, some of which will be continued even after all online teaching is a little bit required. This is perhaps the one silver lining in the very dark clouds of pandemic disease. And so moving on, really, this is where are we going? What is the future role of OER? And this is actually a much bigger question than it ever has been for our past years. And so looking at this, we actually were interested in what factors are like the biggest impact to drive OER adoption. And so when we look at our past surveys and what type of factors are correlated to OER adoption and then what sort of compares to what happened in the pandemic in the last year, we actually see that the major factors are sort of split evenly between things that might really help OER adoption or might actually hinder OER adoption. And so specifically for things that might help, we see that faculty with online teaching experience were more likely to adopt OER, faculty with experience using digital materials were more likely to adopt OER, faculty is making changes to their courses were more likely to adopt OER. And all of these things definitely grew in the due to the pandemic, especially with the added experience to online teaching and using digital materials. And so all three of those might indicate that OER adoption might be growing. However, if we look, two factors related to the faculty might actually decrease OER adoption. And that specifically the faculty really who tend to adopt OER use a luxury of time to be able to search and evaluate the options. And then faculty who do not value supplemental resources are also more likely to adopt OER. And so we saw during the pandemic that a lot of these course changes were very quick and chaotic. And so that sort of rushed to continue and adopt the best digital materials may actually be a negative for OER as well as the fact that many faculty as I showed started using supplemental materials and digital materials which has historically been slightly a negative for adopting OER. And then outside of the faculty themselves, we also know that cost is a very big driving factor for OER adoption. But due to the pandemic and the force shift to digital a lot of the commercial publishers are really caught up to OER and what they can offer and how they're describing the materials. And sort of the commercial publishers have become much more competitive at the OER level. And that also includes commercial publishers really pushing discounts on inclusive access types of options for campuses that definitely cut back to the OER at least on the surface level. And so we do see that there's sort of this push and pull of different trends coming out and we're really interested in measuring what factors are really the most driving factors for OER adoption. And so really what we're looking at and what we're excited to research is what will the next survey show. And coming out of this, we definitely do not expect to know the full impact of the pandemic for the next few years. So we're very lucky to be able to have this project ongoing for plan three more surveys. So hopefully we'll be back every few years to let you know how these trends are continuing. So we're coming to our last poll question and then after this we'll move to the Q&A. So really what is your expectation for the level of OER adoption next year? Seeing A's and B's. So generally positive. Looks like A is winning out a little bit. Great. Yes, we are hopeful and optimistic as well. So yes, we can move to the Q&A. I think feel free to type in the chat or if you want specifically maybe raise your hand and we can unmute. As I mentioned, I'm Julia from Bayview Analytics. Our email is info at bayviewanalytics.com and our full reports are available on our website, not just for this higher ed but as I mentioned, we have a similar report for K-12 and then we do do a lot of other research within the educational fields too. So feel free to ask us questions on this and then go through our website and reach out to us if you have questions across any of our research. So yes, yes. And then of course, thank everyone for joining and we hope you have a great conference. This is the very beginning of a very full conference schedule. So one question. Did you gather any data? Find any correlations on faculty who have time to evaluate OER? So we do ask, touch upon what drives OER adoption but not specifically looking into like what time and what exactly they're looking for. I think part of that we definitely are interested in learning more about the factors that they're looking for during their evaluation and what specifically might take more time. Though partly we believe it might just be because it's a new thing and that requires both there for them to learn the understanding of it as well as teach others within their department or group or even full institution before adoption. This is a nut of human and I'll let you know that one of the things we did check on this and it's a normal question is what faculty listed as barriers to their adoption over the missed upon new equipment and lack of time was highly cited from many faculty that's the component letting them move to material they were not already aware of OER or anything else but in particular OER. And then another question, is there any data on whether library assisting with finding OER and how that affects the increased decrease of views? There's indirect data we have for that which is if a faculty member is aware of and this is typically from the library but not always some level of incentive or just a publicity program about OER they are three to four times as likely to adopt than if they're not aware of such a program. So any top down incentives or and it doesn't even have to be incentives but just publicity awareness pieces that say you talk about the value of OER tends to among faculty who are aware that their level of adoption goes up three to four times. We'll wait a few moments in case there's any other questions but yes, everyone, thank you so much. And yeah, we also are very interested these type of questions or anything you'd wanna see on servers, please let us know. We're always building out and reaching out to faculty admin at the higher ed and K-12 level. And as I mentioned, our presentation is on in the sketch description as well as on our website. Yes, all of our reports are published with Creative Commons licenses and the most recent report are online. Okay, well, thank you everyone for coming. I'll let you out. I think we're a little early. Oh, there might be one. Anything being added on open pedagogy to the reports? Not strictly for this project, I would say but that is something we do touch upon for a few of our other projects and reports. We have been testing some questions in that area. Yes, but like OER, part of that is also educating the respondents so we get a standardized response for it because open pedagogy can mean a lot of different things to different people. Great, okay, so I'll let everyone go. Thank you all for joining. Hope you have a great conference. And thank you, Beatrice, for monitoring and setting this up. Thank you very much. I will stop the recording. I actually can't. Yeah, so Beatrice is having some technical difficulties, but we'll come back in. Actually, you guys can stop the recording, can't you? Let's go.


Meanwhile, Govno Agucarefals of Terrapa State has expressed the readiness of his administration to support and partner with the legion and family of fallen soldiers to enable them to live meaningfully. They discussed the East and Monday rather jolly, near their stadium in Jalingo, while speaking of the 2024 Amphos' celebration and remembrance day. He said the history of the state is interwoven with the bravery of the Amphos' as they have stood tall in the face of adversity defending the borders and ensuring the safety of the communities in the state. So, we are in a very important ceremony to the Amphos' or the Federal Republic of Nigeria, which the President is the Commander-in-Chief, so by implication it is a very important national celebration and remembrance day. Unless there is a policy of moving forward, I am making sure that the Nigerian region enjoy the benefits of their service to the nation and also specifically the widows, the wives of our departed ones and even those who are unable to do things to survive, we will give them all the support they need so that they will forget the pains and the wounds that the dead of their husband, their loved ones, have caused them. Some of the service men and women retiring, Terabasaid have a large number of service men and women retiring, which some of them become Babawu, so-called soldier, but some are very healthy to do other jobs in state capital and local government areas, especially on security matters. Terabasaid Legion office is a standard concrete building, but due to perforated and the leaking zinc damage the ceiling all. The office needs renovation and electrical machine to work in. Get notified about fresh news updates.


Well, one of our key relationships is with the Air Force of Columbia, but also all of the armed forces, very good partner, our best partner, and our most capable partner in the region. So, Relompego is an example of that relationship and highlights the efforts that we undertake together. I want to thank all of our airmen and women who've come down to carry out the exercise and work with our Colombian partners. It's a great way to show our friendship, especially as we approach 200 years of diplomatic relations. So every one of our pilots, our support personnel are really representatives of the United States in this relationship. So your ambassadors as well. In 2022 will be 200 years of diplomatic relations between our two countries. Our relationship has been most intense in the last 20 to 30 years and especially in the last 20 years when we started our assistance to plan Columbia, which was the overall program to help Columbia recover much of its national territory to go against illegal groups, terrorist organizations, drug trafficking organizations. And so our support and our friendship has been very, very close, especially for the last 20 years. And we look forward to 2022 when we'll celebrate that 200th anniversary.


I've got I got these red light panels. I use them every day and I put g-coals in front of them so I'm and I'm using my g-coals in front of me I'm playing the regenerate frequency and I use red light panels behind me so I'm getting red light paratherapy and the PMF therapy and abundance frequencies and then I feel so energized and I feel so much relaxed I used to have to take hot tubs like bats because I train quite a lot with boxing so I get lots of aches and lots of soreness and I have to do hot tub in order to kind of make my joints and my muscles recover but now I don't do that anymore because I use the red light there the red light panels and they actually heat up my muscles increased circulation the red light goes their infrared actually goes deep into my muscles I don't get soreness I recover a lot of


in DevOps track. Our next speaker is Michael Bright. He is a developer evangelist at Containers and he's going to be talking to us today about serverless computing. So without further ado, Michael. Thank you. Okay. Good afternoon. So I'm going to talk to you about serverless computing. I can't change slides. Okay. Okay. So about myself briefly, I'm British. I live in Grenoble in the French Alps and I recently joined a company called Containers who are developers of traffic. It's a fairly well-known widely deployed reverse proxy load balancer which you will see a bit later. I'm also a Docker community lead and I run a Python user group in Grenoble and I'm crazy about open source and cloud technologies, serverless, unicernals, orchestration, all that stuff. I don't know what my slides are advancing. Okay. So just a word about traffic which you will see a bit later. So I say it's a reverse proxy load balancer. It has an advantage in that it was designed for the beginning for doing hot reloads of its configuration. So interfaces with various back ends, so things like Docker swarm, Kubernetes and so on. It can pull out the information about the services running these systems and it also massively configures itself to front-end those systems. It has let's encrypt support with automated renewal of certificates. It's a pretty nice feature. As I mentioned, it's very widely deployed and it can act as a Kubernetes ingress controller, something I demonstrated in Kubernetes tutorial on Friday. Okay. Anyway, we're here to talk about serverless computing. So what I want to do is give an overview of the space of serverless. So that means, well, what is serverless? By guess you generally have an idea about that. A review of a different cloud provider offerings. I mean, very brief say that they exist. It's important to see. The fact that the cloud native computing foundation is also working on this. They have a working group to tie in and encourage standards in the space. Very briefly, open source tools. And then they look at various open source platforms which exist, which would allow you to do on-premise deployment of serverless, for example. On-premise, for example, or on a yes cloud provider. And then I'll do a demonstration of OpenFast, one of the main platforms integrated with traffic. Okay. So what is serverless? Well, first of all, does it mean no more servers? Well, of course not. Our software still has to run on somewhere. It's going to be physical machines. But it's about taking away the responsibility of maintenance of servers for the developer. The developer now is just involved in writing the business logic, the main functional code. I see it as the ultimate cloud native if you see that we've moved from bare metal to virtual machines, containers, getting lighter and lighter. And the developer has less and less responsibility for the overall infrastructure. And serverless is the next step on that journey. Serverless also is not just about the functions. It's actually functions as a service and back end as a service. So functions as a service is really the developer just providing his functions, his business logic. In practice, running in the cloud in particular makes sense to use a lot of back end services via their APIs. They may be APIs running in the same service provider or elsewhere. And so serverless is about writing glue code as well to glue those pieces together. This does mean that there's a risk of having lock in, but actually no one's forcing you down that route. If you want to develop for AWS Lambda, which is one of the leaders in this space, quite likely you will choose to use some of their back end services like DynamoDB or the messaging system. But you could use other services or not. And so on. You've chosen that lock in. Okay. Otherwise, a lot of people don't like the term serverless. I do. It's the paradigm, which is both function as service and back end as a service. But it's also a company and a tool that I don't like. But, okay. Okay. Just another look at it from another angle. So as I say, it's developer focusing on his apps. And then it's the platform provider who is responsible for provisioning the platforms, auto-scaling them if needed, generally maintaining when there are problems like meltdown and spectre. It's the platform provider who will be responsible for upgrading the systems. And you might not even see any downtime given the way that these things will be load balanced transparently. It's very much a pay-as-you-go platform, in principle at least, with several of the cloud platforms. You typically get one million requests a month free, which of course is a huge number if you're just developing. Once you're deploying, then you'll start paying. But it's still not too expensive. Though I say in theory, in practice, you will be wanting to use back-end services. And one of those is something called the API gateway, which can have costs. There's no initial investment. You can just open an account on AWS starting using Lambda. If you're not using the back-end functions, then you can just use your free tier. So it means there's no capital expenditure buying any servers and no operating expenditure either for the actual server installation. You get high availability for free if the cloud provider is doing his job of just doing the scaling out as needed. And you can deploy the same functions across regions in the cloud. So in that way, you will get high availability free, and you won't be paying more as long as you're not using the back-end services. It allows short time to market, enables innovation. You can create a new service extremely quickly if all you have to worry about is just the functions of your code. And this can scale massively. So the overall architecture is like this. You'll have a developer who's going to develop his code and load it up into the platform, that be a cloud provider or not. The functions, nothing's running until events start arriving. So events is a completely event-driven architecture. Events could be coming from some of your back-end services, maybe a trigger in your database. Files being uploaded. So with Amazon, for example, a user might upload an image file to S3, and you might have a trigger configured to do some processing on that image and maybe store it back in S3. Or you might have messages coming in from different sources, including SMS, why not, an external provider. And then, of course, web requests coming in over an API gateway. So these could be just standard browser requests or maybe jit webhooks or Docker hub or whatever. So your functions are responding to things happening externally. If we look at the use cases for serverless, so obviously event-driven, and that could be regular events that represent a real peak, like a monthly payroll or processing end of day accounting or something. The important thing is where serverless becomes interesting is where these are real peaks of load. So you're getting a better utilization rate of, because there is hardware somewhere, you want to be having efficient usage of that hardware. So if you're using serverless for just peaks, then you're getting to be effective. If you've got a fairly constant load, well, you should maybe be looking at other technologies like platform as a service or just straight containers. It's something that's applicable to quite a few domains. There will be DevOps, CI CD, banking, IoT. What's important is that we have certain characteristics. So as I mentioned, some sort of peak processing. Your application has to be latency tolerant. I think we're typically looking at like 100 milliseconds response time. And those treatments should be relatively short-lived. In Amazon Lambda, for example, I think the Cull services functions after about five minutes. Okay, let's look very briefly at some different cloud providers. There are more, but we can see these are fairly standard cloud providers. AWS Lambda, I've got another slide on them, so I'm talking more detail, but they were the first in this space. Since then, the last two years or so, we've seen Microsoft with Azure functions, Google Cloud and IBM Cloud. Azure is pretty nice platform with a nice user interface. Of course, they understand developer tools. I think we can expect interesting things from Azure functions. Google Cloud, I don't find very clear where Google are going with serverless. I'm not convinced that they're convinced. IBM Cloud Functions is quite interesting. They started an open source project called OpenWisk, which they then donated to the Apache Software Foundation. And so their IBM Cloud Functions use now Apache OpenWisk, which is something that you too can use. You can deploy that yourself on premises. So if you look at AWS Lambda, just an example, there's a certain number. They launched it in beta at the end of 2014. It wasn't till about the end of 2015 that it was stable. But there's been a huge developer uptake on that. And they did this because they realized that more and more functionality that developers were using on top of Amazon EC2 was sending to be a lot more glue code of the back-end services that they have. So suddenly having this sort of low-cost function as a service model isn't so low-cost after all. It's actually very interesting for them as a gateway through to the higher-paying back-end services. There are probably a number of language choices. Typically, these platforms are based on container technology that we don't necessarily know how Lambda is implemented exactly. Some platforms tend to allow you to bring any container to them, or others are more limited in language choices, maybe because of the need to have bindings to back-end APIs as well. And recently, there were some new features announced, which is Go. As a new language, though, this is Go as a static binary. So this is very effective. It's quite performant, but on the hand, you don't have the same integration of the IDE currently. And they also provide some tool for offline debugging, which is something that was missing before. Okay. And there are potentially huge cost savings for service. There are some real examples where services have been implemented at like 5% of the cost. And there have been other examples where the promises looked good at the end of the day, like the API gateway, which is built differently on some platforms was quite costly. So in this slide, sorry, it's a bit small, but the bottom line in that table is showing that the API gateway is free on IBM Cloud and Azure Functions, but it's paying on Lambda and Google Cloud. So I mean, just to say there are characteristics you need to be aware of that could bring in unexpected costs. I mentioned that the Cloud Native Computing Foundation has created a working group, so they're creating a lot of materials around this space. They're trying to get to the point where there's common terminology and hopefully common definitions of maybe events or this sort of thing. Tooling, so very briefly. Actually, there are hundreds of open source tools. And if you search on JTub for awesome serverless, you'll find a very impressive list. And there are some particular tools that are worthy of note. So serverless, which is the company, serverless.com, provide a tool that interfaces with various Cloud provider platforms. So it gives you a tool where you have a framework. You can easily deploy code to the different platforms using the same deployment commands. Maybe the code won't be exactly the same because you will have to adapt. All these systems are quite homogeneous, but at least at the deployment level, you can have the same processes to roll out across these different platforms. There are others, Apex in particular. There's also Chalice from AWS themselves, which is open source, which is specifically Python for Lambda. But if you look at the open source platforms, so Lambda is proprietary, as is Azure Functions, Google Cloud Functions. IBM is the only one using an extended version of an open source platform. But there are these open source platforms that you can deploy on-premises on a YAS platform yourself. So let me see. Kubler, some fission, a couple that run on Kubernetes specifically. It's Apache OpenWisk, originally from IBM. One detail about OpenWisk is it's bring your own container model as is OpenFast, which is quite nice. That allows a lot of innovation, as you will see. The FN project from Oracle and Nucleo, which is quickly suited to high-speed data stream processing. So they're focusing on the latency issue. But I'll look at just one of those and I'll demonstrate OpenFast. OpenFast comes from the Docker community. It's bring your own container. And that's really nice. It means there's been a lot of innovation using this tool. It has a portal and now with a function store integrated into that portal, which is quite nice. A command-line tool, as most of these platforms have. It also has a flavor that will run on Kubernetes. And it's quite easy to get started. There are a lot of guides available. One example was a colorizing project from Fidian Anderson. He did a blog post on colorizing video with OpenFast. It wasn't a real-time thing. This is actually frame-by-frame conversion of images. And I actually have a demo of that natural colorization of images. Okay. So time to have a quick demo. Let me just introduce very briefly. So I'm going to combine OpenFast with traffic. Basically, traffic allows you to front-end your set of services. It's an environment where you have a lot of microservices running within some orchestrator and the Docker swarm, Mizzas or Kubernetes. Traffic allows you to do several things to root domain names or paths or even ports or some combination, basically URLs, through to back-end services. It allows you to control how those appear when you connect to them from the Internet so you're not exposing your internal infrastructure. I mentioned earlier, it can also do lead-syncrypt certificate renewal. And it's a load balance, of course. So for this demo, I've integrated it with OpenFast. With OpenFast, we'll actually have a set of functions. In this case, I've configured just my local host to correspond to each of these functions. And traffic, then based on the host name to which we're querying, can feed through to the appropriate function running in our serverless platform. And this is running on Docker swarm. So I'll go to the command line to show this. In fact, basically just how I integrate traffic itself into the Docker compose and then how I integrate one of the functions with the traffic-specific characteristics. Okay, so this gets tricky with the microphone. So this is the Docker compose for OpenFast into which I've integrated traffic itself. See how to do that, I'd remove that earlier. And basically, we're configuring to access the dashboard of traffic itself to connect to the Docker socket to... We connect to the Docker socket to be able to interrogate Docker swarm and discover the services already running in our platform. We're going to have a web interface. We're using the functions network. Basically, OpenFast itself creates a network apart for all the functions. And I'll show the dashboard of traffic now. Okay. So traffic provides basically two tabs at the top here, providers. And so we have Docker as a provider. And traffic has automatically discovered the services running in our platform. So in fact, we have a front end for each of the services, which of the functions we have. We can see here, there's things, base 64, colorize, echo it, all of these functions. And then we have a pointer to the back end, which is actually service we're going to root to. We also have a health tab where we can see actual request statistics have been going on. Okay. So this is the portal of OpenFast. So some just fairly simple functions included to start with. If I just do a hello world, if I can type my left hand, then we have a simple word count. Zero lines, I didn't do a carriage return. Two words, 11 characters. And OpenFast has a deploy new function where we can manually define a function or we can take it from the store. And one of those is this colorization application. I'm not going to install that one. I've actually already installed it here. I'll just show you now accessing platform from the command line. Oh, dear. Getting out of VI, just left handed. Okay. So let me just show an example of... One of the functions is markdown. I've scripted it just because I want to send just multi-line import into the curl command I'm going to use. It's easier that way. So I'm... Okay. Just sending some simple markdown via a curl command to my server. And we can see that it's generated some HTML. Okay. So just look at the curl command itself. The minus user demo is some basic authorization, authentication that traffic has performed. We could configure that to go out to some backend authentication server. But here it's just basic authentication. We're doing a post request against the functions. Remember on the initial slide, I showed that traffic is translating from some domain name. It's actually mapped onto local host, in my et cetera, hosts. But traffic will detect that host name and then forward that to the backend markdown function. And then the minus T is just passing in the post data, the markdown that we saw there. Okay. So I'm just going to do a display of an image. Okay, a black and white image, which I'm pulling just from a local web server on my machine. And I'm going to do a curl again with the user login, posting this to colorize.fn.fast, sending that same URL of an image. And so that's now going to be processed by the OpenFast. I've redirected the standard out to a file face. Okay. And so we now have a colorized version of that image. And so I didn't say much about that application, but that was basically a container someone has created which is actually using machine learning inside it. So I think it's quite powerful. You can see several things put together here, we can easily have a machine learning function available just like that. We can also route through to services in our infrastructure through the use of traffic. If I come back, my presentation. Okay, so serverless is still a young technology. We see it evolving rapidly. There's a lot of uptake with Lambda, but there are other platforms that are very interesting, including open source platforms. I think we'll see a lot of evolution in capabilities, performance and pricing models. There's a lot of promise from any workloads that there are constraints on latency requirements, this sort of thing. There are real cost savings providing these services, some sort of unpredictable peak traffic. All the major cloud providers are investing in this technology. There are many deployment choices, and so we need an open cloud. Today, there's not a lot of homogeneity across the platforms for the moment. So thank you. If you have any questions, please take them. So we don't have any time for questions right now, but I'm sure Michael will be around and willing to field anyone's questions. If the next speaker, Hector Martinez is here, please come up and we'll be starting as soon as he shows up. Thanks.


So the myogenic stretch reflects to control GFR or to regulate GFR and keep it within 180 liters per day. No matter what the blood pressure is, that is no small feat and it's just one strategy. So there's another whole strategy and this one is called tubular glomerular control. And tubular makes you think of the nephron tubule. Glomerular makes you think of the blood supply. So this is working together a strategy that the nephron and the blood supply are going to work together to utilize. Okay, and it involves somebody called the juxtaglomerular apparatus, but of course. So the juxtaglomerular apparatus. And who is this juxtaglomerular apparatus you speak of? Well, let me tell you. The juxtaglomerular has to do with a... Well, maybe I'm just going to do it. It has to do with the glomerulus. So we'll draw my glomerulus with my afferent arterial coming in and my efferent arterial going out. And remember how... Yeah, this is the glomerulus. Sorry about that. Remember how I drew my Bowman's capsule was like a, like a this, right?  Oh, dear, whatever. We ended up going down this way and then we came back around. And remember how I had a sending loop of Henley come up through this space right here? Do you remember that? Please say, of course I do. Of course you do. This is an anatomical reality that there is this location and I'm drawing the cells that actually line the tubule. This is most likely distal convoluted tubule. And distal convoluted tubule comes in contact with the cells lining the afferent and efferent arterials. Now, we've got some names to do. These guys are called juxtaglomerular cells and those are cells of the afferent and efferent arterial. These guys are called maculadensa cells. Maculadensa cells are part of the tubule and here's the scoop. Maculadensa cells are magic. Okay, they're not magic, they're just physiologically phenomenal because they monitor the filtrate. This is distal convoluted tubule. This is the filtrate that started out in Bowman's capsule, went through proximal convoluted tubule, was sending lupopenly, us sending lupopenly and is now in the distal convoluted tubule. A lot of stuff has happened to it. In the next lecture, we're going to look at all the stuff that can happen to it in that time. Maculadensa cells monitor that fluid and if they detect characteristics of the fluid that indicate low blood pressure, they are going to send a message to the juxtaglomerular cells in the afferent and efferent arterials. Did you follow what I just said? Stimulus, low blood pressure. So I already put the one right here. Message gets sent from maculadensa cells to juxtaglomerular cells. Juxtaglomerular cells are going to do something amazing. They produce a substance called renin. Renin is dumped into the blood. Here's renin. Juxtaglomerular cells busted it out, embuffed it into the blood. Renin is an enzyme and it is going to come into contact with a substance that's already in the blood, it's hanging out. It's a protein and I'm going to make my protein purple because you know all proteins like to be purple and it's called angiotensinogen, angiotensinogen. Angiotensinogen is a plasma protein that already is just floating in your blood. So out there in the body, you have angiotensinogen floating out there, but only if renin gets produced will angiotensinogen get changed into something else. If renin is produced, then renin is going to take angiotensinogen when it comes in contact with it and turn it into a substance called angiotensin 1. Did you follow that? Renin is the enzyme. It gets produced because of low blood pressure. It's produced in the nephron. It gets produced in the glomerulus. Gets dumped into the blood. Renin goes out and finds angiotensinogen which is just a plasma protein already floating in the blood. Angiotensinogen when in contact with renin it's turned into angiotensin 1. Angiotensin 1 does nothing. It floats around. It continues to float around in the blood until it comes in contact. Oops, the number six comes after the number five. It's going to come in contact with an enzyme called ACE. It's another enzyme. And this is awesome. ACE turns angiotensin 1 into angiotensin 2. Angiotensin 2. Angiotensin 2, doggies, is the action-packed dude of ever. Go ahead and speculate. If you wanted to increase blood pressure, what are some strategies you might employ to do that? Angiotensin 2 probably does it. Number one, angiotensin 2 is a power-packed, power-packed vasoconstrictor. What's that going to do to blood pressure? It will increase blood pressure. It is going to also, it's going to make you thirsty. What's that going to do to blood pressure? If you drink fluid, that's going to increase blood volume, which is going to increase your blood pressure. It is also going to increase cardiac output. So it's going to increase the stroke volume and heart rate, which is going to pump blood more effectively through your body and increase blood pressure. Angiotensin 2 will increase your blood pressure. Okay. How about drugs called ACE inhibitors? Yeah. Think about that one for a phenomenal exam type question. What is an ACE inhibitor? What will the outcome be for a drug whose mechanism is to inhibit the ACE enzyme? What will happen? I will let you contemplate that. And hopefully, we will talk about it in class. All right. Rock stars. See you for part two of kidneys later. Bye-bye.


Hello friends, I am P. P. Mitramutri, Associate Professor, Department of Mechanical Engineering at Valchand Institute of Technology, Solapur. In today's session, we are going to study part two of design of a progressive dye for a given component. In earlier session, we have already studied design procedure for a progressive dye for a given component up to strip layout. Learning outcome of this session will be, students will be able to design a proper dye set for a given component. Now, in this case, after strip layout has been decided, next part is a calculation of utilization of strip stock. Now, for calculation of utilization of strip stock, we have to calculate area of the blank to be cut. Now, our component is having size of 80 mm by 80 mm square. So, area of the blank to be cut is 80 into 80 is equal to 6400 square millimeter or millimeter square. Now, area of strip required for one blank is width of the strip is 84 mm. So, 84 into 84 mm will be the area of the strip required for one blank, which comes out to be 7056 square millimeter. So, percentage utilization of the strip is calculated as area of the blank to be cut divided by area of strip required for one blank into 100 that is 6400 divided by 7056 which comes out to be 0.9, 0.9 into 100 is 90 percent. It is a very good utilization, very little scrap loss is there. So, our strip layout is very good. Next thing that we have to calculate is press capacity. For calculation of press capacity, we have to decide certain things that is force required for piercing and blanking operation. For calculation of force required for piercing and blanking operation, perimeter for piercing of two hole plus perimeter of blanking has to be decided. Then it is to be multiplied with sheet thickness and shear stress of our component, shear stress of our sheet. Now, before deciding force required, first of all we will decide perimeter for piercing operation. Now, hole to be pierced, one hole is to be pierced has having diameter equal to 8 mm. So, perimeter for one hole will be pi d that is 25.12 mm into two holes is equal to 50.24 mm. Similarly, perimeter for blanking is our blank is square blank having 80 mm sides. So, 80 plus 80 plus 80 plus 80 is equal to 320 mm. Now, for calculation of press capacity, we are already given with shear stress of our sheet metal is 840 Newton per mm square. Sheet thickness given is 1.2 mm. So, force required can be calculated as perimeter for piercing plus perimeter for blanking that is 50.24 plus 320 into this is into bracket into sheet thickness that is 1.2 into shear stress 840 mm which comes out to be 377.23 kilo Newton per mm square which means approximately 37 tons by considering factor of safety and other thing press of 40 ton capacity which is available at our end has to be selected. Now, before considering further part I will pose a question before you that is will you be able to produce this component using a press of 35 ton capacity please presume that 40 ton capacity press is not available with you. So, think over it now next is calculation of punch and die sizes for piercing. Now, for piercing operation hole is to be pierced. So, punch is going to pierce the hole into the strip. So, our size of the punch has to be equal to size of the hole to be pierced. So, punch is of correct size that is 8.00 mm, but size of the die opening has to be greater than the punch size so that we cannot have ragged edges. So, punch size of die has to be greater by punch size plus 2 into clearance. Now, what is clearance? Clearance is assumed to be 10 percent of sheet thickness. So, clearance on one side is equal to 1.2 into 0.1 that is 0.12 mm. So, therefore, size of die opening will be 8 into 2 into 8 plus 2 into 0.2 that is 8.24 mm is the size of the die.  Another size of the blank is 80 by 80 mm so size of the die opening shall be square of 80 by 80 while size of the punch has to be smaller than the die opening by amount equal to 2 times clearance. So, size of the punch is given by the formula die opening size minus 2 into clearance now clearance is 10 percent of the sheet thickness as already stated. Therefore, punch size will be a square of 79.76 mm size punch size will be square die opening size will also be square.   Now inner square shows you a punch size of 79.76 square all sides of the punch will have dimension equal to 79.76 mm and pink square will show us die opening size that is it is a square of 80 mm side. Now this is the sketch showing the front view of progressive die set now you can observe here there is a punch holder on punch holder you can observe piercing punch and blanking punch. Now as this is a front view you can observe only one piercing punch because another piercing punch is on the back side of this piercing punch so it is not observable in the front view and distance between center distance between piercing punch and blanking punch has to be equal to pitch up advancement as my strip is advancing from right to left so first of all two piercing operations are taking place then the blank which is having piercing operation will come under blanking die and punch set and will get blanked now you can observe that die block in which there are two openings one for piercing another for blanking and below both the die blocks I have shown the angular clearance so that during punching operation scrap will fall down very easily due to angular clearance given to the die block and our product will fall very easily as because of the angular clearance given to the punching die now next is the schematic sketch showing top view of the progressive die set now in this set also you can observe distress between both die sets and punch set is equal to 82 mm that is pitch up advancement in this case you can observe punch size of 8 mm and die opening size of 8.24 mm and center distance between two punches is equal to 40 mm piercing punches is equal to 40 mm then this will complete our design and for further reading I will ask you to refer a textbook of production engineering by PC Sharma tool designed by Donaldson and prestool designed by Indo-German tool Rome Aurangabad thank you


After a few years of price spikes, health insurers in Minnesota's individual markets are proposing mostly decreased premium rates for 2019. The average decrease could range anywhere from 3 percent to more than 12 percent for consumers. This is according to data released today by Minnesota Department of Commerce. The proposed rates are preliminary and will be reviewed by the Commerce Department and finalized later this year. The rate proposals reflect the newfound profitability for insurance in the market and the impact of state-funded reinsurance programs that offset the costs for consumers with high medical expenses. The Commerce Department said the actual change in rates for individual consumers could vary based on health plan specifics, age and geography.


All right, the fifth exercise in our progression, the fifth and final exercise in this progression for fixing an asymmetrical pull-up doesn't look like a pull-up at all. Doesn't even look like an upper body exercise. This is single leg exercise. And I think single leg exercise is probably the best and most underutilized tool, unless you're me, it's probably the most overutilized tool for fixing asymmetrical problems. That is because we walk around and we have normal motions and doing things on one leg help us find those normal motions easier. In the case of the asymmetrical pull-up, we talked about the problem. The problem's the rib cage. I mean, it could be something, you could have like an osteophyte in your actual shoulder joint.  And you would be a special case, right? But for most people who have this little shrugging thing going on, you have an asymmetrical rib cage. And we needed to find a way to flex it down. We needed to find a way to side bend it in. And we needed to find a way to turn it back to the left. Remember, we talked about that over the last, what, eight videos? Now what I'm trying to get you to do is find it really, really quickly when you're doing your lower body exercise. So the trunk, the torso is designed just to transfer force. It needs to be as fluid as possible so that I can breathe in a bunch of different positions and so that I can take that force from the ground that my feet make and transfer it up to my arm. So if I'm throwing a baseball, right? All the force comes from my feet. It's not like my arm muscles are really strong and that makes me throw a ball really fast. There's an element of that for transferring the force so that I don't lose any of it in this midsection. But the biggest thing is, one, I need to be able to push into the ground with my foot. And two, I need to be kind of floppy in the midsection so that all of that force in the ground can make it all the way up to the ball. And it's the same idea with all this other stuff. So my trunk, my rib cage, my torso is designed to be loosey-goosey. And we gotta teach it to be that way. And we've, if you've done, you haven't just skipped ahead and you did all of the exercises that I wanted you to do, then you should have the ability to achieve those positions. All we need to do now is give them to you in harder and harder scenarios. And one of the hardest or two of the hardest scenarios that I can think of is a step up, a single leg step up or a single leg Romanian deadlift. Both of these exercises have like this flight phase where you're only balancing yourself on one leg. And what that affords us is the ability to kind of manipulate the rest of our body. So the theme that we've been talking about is scrunching the air out of the left side. And you gotta be really diligent about that. And that's why I'm giving you so many different exercises for doing it. But I can do that when I do my step ups as well. So if I am, let's start on the right foot. So if I'm on my right foot, no, let's say I'm on my left foot I'm stepping onto a box with my right foot. That's what I meant to say. Before I go, I, well, not even before I go, let's just say I step up and at the top I can do two things. One, I can try to stay still or two, I can try to hike my opposite hip up. In this case, the left hip up. I've stepped with my right foot. I hike up my left hip. And what that does is it looks a lot like that third exercise we talked about where you're laying on your right side and you scrunch up your left side. Yeah, I'm scrunching it up now, but I'm standing. So it's more difficult to do effectively, correctly, but it will last a lot longer just because it's so much more complicated. So what I like to do with these people is after you've learned how to do all of this different positioning stuff, after you've demonstrated to me that you're gonna hold that scrunched up position and you can breathe, which is sometimes really, really hard. Sometimes you need to take really shallow breaths to hold that position and that's okay. Eventually it will loosen up, but once you've gotten it and now you can take big breaths and all of those other places like that right side will expand when you breathe in. Well, then I can start to say, okay, now can I do it under more load?  So I'm not just listing over to the side, I let my left shoulder sink down. Now I might feel a killer right glute like I feel right now. I better stop before I start trembling on camera. So the step up is really good for that. If I'm doing it with my right leg I might just before I step I might keep my left foot on the box and I might just try to get that scrunch on the left side just so I have the right position. It's a lot easier to do because you got two legs down but it's the same idea, right? I'm trying to teach myself how to scrunch. Eventually you wanna make both sides look the same. You wanna hike the right hip up when you step with your left but until you can demonstrate that you can do a symmetrical pull-up then I'm not as worried about it, right? The other exercise I wanna talk about is a single leg Romanian deadlift, single leg like stiff leg deadlift. It's the same idea. So as I get to the top if I'm doing my right leg if I get to the top I come up to the top here and all I have to do is hike that left hip up sink that left shoulder down and I'm sorry I hit that mic and then I'm good, you know? It's same kind of scrunching motion and with the left side before I even go I wanna scrunch up that side. I wanna, we're not gonna talk about gait, I'm kidding. So we're just gonna try to scrunch up that side and then we're gonna do the exercise and we're gonna try to make sure that we don't lose it on the way up. We don't unscrunch that left side because it's gonna be really easy to lose that. I think that's it. That's all I wanted to talk about on those single leg exercises. So that hopefully it makes sense to you why we're doing lower body exercises to fix an upper body pull up. You know, it's the rib cage. We have to, all of these things impact the rib cage. They impact the hip flexor. They help you get in the right position so that your shoulder doesn't have to do all that weird stuff just to get you up to the bar.


So, hello everyone, today I'm going to talk about writing docs and in particular how writing docs may let us not only contribute to the project that we're writing docs for but also it can be a great opportunity for you to learn about the project and if not advancing your seniority as a developer. My name is Wei, I work at Sharpie which is an e-commerce platform here in Singapore. Our team is with the React ecosystem now but I prefer to identify myself as a web developer in general. The story I'm sharing today is not as exciting as shipping to a billion people but it's about writing docs for a couple of projects throughout the past year and hopefully I can share something you can use on your own. So because I'm also talking about learning today, I want to first give you a bit more context about where I am with respect to my own career. So I've recently passed my fourth year as a front-end developer so I can say I'm probably not a junior developer anymore but I'm also not one of those who are super talented but perhaps that makes me a better person to talk about learning because I know exactly how I got better. In my first year, I enjoyed the job as if I was playing Lego, it's like assembling pages from PRD, API documentations and design specs, it was very playful and I had a lot of fun. I joined my current team in the second year where nearly all my teammates had a CS degree and they were good to the level I could not evaluate myself so it was like meeting my peers of my major but feeling a bit under qualified. And then in my third year I got a little lost in building features, I built a lot of features but only features. So having in mind to gain some more inspirations about what other developers are doing in this world, I was looking for a conference to go. So I ended up going to Ria Rally where I learned about this project to write docs for Ria Redux which I'll talk a little about today. Then in my fourth year, I spent a lot of time organizing a podium for my team where we talk about things we found interesting as a React developer. I myself gave a lot of talks there as well and I said that speaking and writing, they share a lot of spirits in teaching and by teaching you'll gain a better understanding. So the bulls have been a significant boost to my learning and writing in particular is my favorite and is what I'm sharing with you today. And speaking of RK, since we're here in Singapore and we're at junior depth today, I think it's also a great context for me to tell you a little bit more about RIA knowledgeable. This podium is now also publicly run as a meetup. It happens the first or second Thursday of every month and the spirit of RK is that when you learn something, the best way for you to learn it is to teach it to someone else. So Inel has a very small core consisting of a few very cool React developer, I believe. And last month, we talked about binary heap which is an implementation optimization for React's scheduler. And then last month, we had a developer who talked about dancing. She built a little dancer with React hooks and the time she talked about this, we were live tweeting it and Dan Abramov saw it and he hit liked and so that was like the React core team is looking at us, this thing cannot be bad. So that's a little bit sorry about RK. So today I'd like to first talk about what I am learning by writing docs and why it's such a powerful tool in learning. And then I'd like to talk about the most critical challenges of writing docs for myself, namely it is about understanding and explaining complex technical concepts. We'll talk about how we can integrate some of the practices we can do on a daily basis. And then I'd like to talk a little bit about the value of how docs contributions can be a unique chance to create great impact. And then finally, I want to share with you a few tips that I picked up and can get to start it and get to practicing. So let's go back to a day of React Rally 2018. It was my first conference trip. I was very shy and I didn't speak to a lot of developers at all. And it was the day after the conference, I was sitting at a table where a group of developers and speakers, it was very relaxing because the conference was over and they would have some casual conversation. And that's where I met Mark. He is a maintainer of Redux. He was also there. And at some point of time, he mentioned that he was looking for people to work on the project to rewrite docs for Redux and React Redux. And that's if people were interested to help. What would your answer be? I normally would have a yes or no answer to things I'd like to do or not. But this time, it wasn't that clear for me because I was apparently attempted, but I also felt more uncertain about how much I could actually do. Am I senior enough to write documentations for such a popular project? And do I know much enough about Redux or React Redux in order to write a complete set of documentations? And writing is hard. I think I am a person, like words aren't really my thing. I was more comfortable writing JavaScript than coming up with human words. And not to mention that I'm actually a non-native speaker of English. I constantly struggle with grammar, and I find it really hard having to explain technical terms in English as a second language. But maybe it's because I kept wondering about all of those questions. It's like, can I do this or not? And on the other side, you actually have this chance to pick this up. So after two weeks, I was back home. And I reached out again. And Mark, in fact, had already had the projects planned out in two GitHub issues where he listed out the outline of the docs and the topics he wanted to cover, how to organize them. And he also included a list of resources we can use as reference. So I picked Redux because it seemed a bit easier. And I did the simplest thing you do in college when you study, for example. I read everything. And it was also the moment when I scared myself by realizing that I do not really know Redux. In case you're not familiar with Redux or maybe you're not with the ecosystem, let me quickly walk you through and overview what it looks like. So Redux is a state management library that maintains all the data of your app in a big object, commonly referred to as a store, and you reduce the store states by dispatching actions. And then you provide the reducer functions, which specify how your store should update according to those actions. And then Redux is then the connector to make your app work with Redux. So with a lot of details omitted, here's what your code would roughly look like. You create the store with Redux, and then you provide that store in your app room. Then you can write your components as if they already have the data they need from the store, but they don't until you connect them to the store. There are two tongue-twisting functions that are related. One for you to get the data from the store. The other one for you to dispatch actions from the store. What I want to tell you about here is that you can see that the APIs are very declarative.  They do exactly what they do. So I've had no trouble writing code like this since day one when I copy the code from somebody else. And for two years, I never really bothered to care for what was really going on under the hood. Now, it seems to me that this is the perfect example of me knowing the name of something without knowing it at all. Anybody know Dr. Richard Feynman? He's a, I see a few hand-living here. He's a physics professor, a Nobel Laureate, and his action notes were actually what helped me pass my college physics courses. And so people also collected some of his lectures into a few essays, books of essays. And in one of the books called The Pleasure of Finding Things Out, and in one of the chapters Feynman mentions that when he was a kid, his father has once told him about the kind of bird. He told him the name of the bird. And in fact, he told him the names of the bird in multiple languages. And then he showed him that that is not the same as knowing what the bird is. You can know all the names of the bird in all the languages in this world without understanding what this bird is at all. Isn't this exactly the same as us knowing how to call a function but without understanding the API at all? This scares me to be honest, because nowadays our libraries and toolings are built towards better developer experience. They encapsulate all the heavy liftings inside the library so that we don't have to worry about them. I think it's a good thing most of the time. We can happily build our features and maybe go home early every day. Have you noticed the fact that now we can actually get away with doing our job quite all right without understanding anything about the underlying structures at all? So as a developer, if our day-to-day job does not require that we understand the library we use or the under-the-hood implementations, when and where do we learn about them? While we're clocking in a lot of features and implementations, when is our chance to go into the other direction to go deep into our understanding about our field? So let's consider an example. For those of you who use React Redux, have you ever wondered when will MapState to props functions run? So it turns out that whenever our store state changes, each of the connected components will have to figure out whether the part of the data they need have updated or not. So they all will run their MapState to props functions if you've never wondered about that. So since our pages may not contain just one or two connected components, in fact, sometimes we can have a lot of them on a single page, that means our MapState to props function better be very fast. It better be as fast as possible. Maybe we should memoize them if needed. And no asynchronous calls. Plus, they should probably return only the relevant data that is connected components care about, because it matters to whether their components will call their render functions or not. So as a college math major, I've learned a lot of obscure facts that aren't really useful to my career as a developer. But this time, however, I think for the first time, I became the person in my team who seems to understand why 120 item cards were calling their render functions whenever the user clicks login. It's an action that is completely irrelevant with item cards. So whether the excessive renderings or excessive rendering calls are causing performance issue or not, that is another question. But have you noticed that this is probably some under the hood mechanisms that we should at least understand? And we are not getting told by only knowing the names of the function. So that had a subtle impact in me. I became slightly more confident and much more interested in all the things about React Redux. So let's pause here a little bit. I think I wouldn't have done my talk if I do not tell you how exactly the learning happened. And you may have heard the suggestions from a lot of senior developers who encourage you to work on documentations. But they may not have time to justify the reasons for you. And in fact, I am giving the suggestion for our new joiners now. And today it comes my chance to elaborate. So first, Redux provides you a ground for thorough research. If we are only to, for example, figure out a problem, we encountered the other day, chances are our learning would end at the point where our problem is resolved. Now, since we're working on documentations, I would say that this is the exact situation where we should go in full capacity to learn about everything we can about the subject. For React Redux in particular, Mark has a red poll containing a handful of good links in the subject. Before I was writing the docs, I've read maybe one or two of those. As I was doing the research for the documentations, I tried to read as many as possible from that red poll. And actually soon enough, a lot of the plot polls are saying roughly the same idea over and over again. And that is when you know that you're reading the kind of material that everybody is saying about React Redux. And here's our favorite physics professor again. So Feynman has been advocating a method called the Feynman technique. Namely, when you learn a subject, after you pick the subject, what you do is you teach it to a toddler. And then in the third step, you find the gaps within your understanding. And then finally, you refine and simplify your language. And then you repeat, you do this over and over again. So writing docs for me is like this process going over and over again until our documentations are well written. And if we are writing a doc for popular open source projects, people will come and review our work. Not just to fix our typos or mistakes, and not only normal users. In fact, domain experts, maintainers, the people who created the libraries, they will come review our work. Because they care about how the community is understanding the libraries. They care about what we teach to newcomers. And they care about what is being said on the official documentations. But then for us, junior developers, right, or someone who is learning a new library, isn't this the best mentoring we can get? So the day that my first piece of doc was merged, I thought everyone should be doing this, right? But no, very few people are doing it. Well, I think these are something I figure out over the years. I think it is indeed very, it takes a lot of time and commitment. It might not take you too much time to fix typos or add some minor information to the docs. But writing more complete set of docs, it takes a lot of time and commitment and collaboration with the maintainers. Maybe multiple rounds of revisions on the draft if the maintainers will help you. And then we all know that writing is frustratingly hard. Even Pulitzer winning authors will tell you that writing is hard. It's hard for everybody. It's just that we have different takes on the challenges and different ways to tackle it. And then I think for me, the challenges are centered around understanding and explaining complex technical terms. We're talking about writing projects that we didn't write ourselves. Although I think even for projects that we do write and maintain ourselves, we still need to understand the actual use cases, which are equivalently, if not more challenging, and both situations we need to explain them in human languages. So this brings us to the second part of my talk. Let's now take the challenges as a given and see how we can get better at them. So it turns out that I think understanding and explaining a complex technical ideas, these are two sides of the same problem. I haven't come up with a name for that problem yet, but maybe I will sometime later. But what I want to tell you is I feel they go hand in hand. They help each other. Don't be too certain that you understand something until you can explain it to another person. And after you've done it, you've done explaining it to another person. Maybe after you've done it for so many times, you'll get a refined understanding of the subject. So throughout the past year, I've been picking up on little techniques here and there on a very small scales, but on a very regular basis. That allows me to practice those two together and hopefully, getting me towards becoming a better developer. So let me ask you this. What do you do when you have read an interesting technical article? Or maybe you have watched a good talk? Or maybe you've run into a problem and you're Googling it and you've found the solutions to a problem you're tackling with in a GitHub issue. So try this. If you've read something valuable, this applies to not just one of those, but most content that you consume. Don't just stop bookmarking it. Instead, try to summarize the content in a few words of your own and share it with someone else. I think it works best if you have a coding partner who you can conduct one-to-one sharing with on a regular basis. For me, what happens is more often than not, the first time I explain it, it always goes worse than what was in my brain. So I also often realize that I'm missing point from here and there on the spot, it doesn't feel great. But it tells me where my mind gaps were very effectively. So one-to-one sharing is something that I currently have the luxury to exercise with because recently I have a very great coding partner, also a great mentor who we spend like half an hour every day and we talk about what our progresses were for the past day. And I'll take this chance to explain to him what problems I have solved and step by step how I managed to solve this. And I also get to define the problems to the person so that I can verify whether he is getting my explanation or not. And if you do not have a regular coding partner, there are still some other choices you can go with. You can tweet it and once again, don't just retweet it. Put a few lines of summaries that your readers can have a heads up of its key points and if you've landed there because you're solving a problem in your code then just don't just toss back the link. Write a few lines of explanations such that the people who need to understand the situation can save some time. And then create a short note section in your writing. The key is to try to fit this into a regular routine if not a daily routine. So if you're doing the short note thing on your block, make the layout of your block make sense for smaller notes. Don't block yourself with really long block posts that you can't finish in like two weeks, do this on smaller scale. Small block posts that you can finish within maybe a reasonable like a half an hour of a time. If you do this as a daily exercise, chances are you'll have clusters of those little notes and maybe in two weeks, you can write a longer post that connect all those smaller notes that become a better idea of a block post. So coming back to docs, how does writing smaller notes help you with writing docs, right? So this can apply to the docs you write when you try to understand the source code for each part of your source code. You can just put out a few lines describing what this part of the program is doing. And then before long, you'll have a bunch of those notes like these and there are good grounds for you to start writing the documentation so that when you actually start, you won't have like a blank page. Then I want to give you an example of what I mean by being intuitive rather than imperative. So for me, docs is something that connect the language that a machine can understand with a language that human beings can understand. So the example is factorial function that we all kind of know from high school. So a factorial function is a function where you take an integer n and you multiply that n with n minus 1 until 1. It is also a relatively expensive to compute function so we will memorize them. So this is the function that we write. But for today's context, let's look at the comments. So the first version of this comment is very imperative. It nearly says exactly what the code is saying. So on the first line, it says create cache if there is none and then you read the actual code. Because if factorial cache is non-existent or falsely, then factorial cache is you set that to an empty object. And then on the second, wait, oops, sorry, my... And then on the second comment is saying if n is in cache, then return it. And then the code is saying the exact same thing. So I'm going to read the third and the fourth line because they're all very... They're all just the sounding board of what the code is doing. Let's try another one. So try to read this as a user. As a reader to begin with, you read initialized cache. And in your brain, you'll comprehend that the task that we're doing is to initialize. And you will actually know what you want to do when you initialize something. And then we say short circuit. And now you know that what we're doing here is to return early. And then on the actual computation step, it first tells us what the definition is, hinting to us that we can treat that as a given. And then it tells us that it is possible to recursively compute factorials with existing results by doing this. And then if we understand the definition of the factorial, this should not be too hard to understand. And then it tells us about the initial case, which is what we do when we write a recursive function. And then eventually it tells us that we're going... In order to reduce computations, we're caching them. And then before it returns, it tells us why we're guaranteed for a return. So I think the trick is to always look at the intention and the motivations of the thing you're trying to explain. And if people understand your intention and motivation, they can plan out the imperative step by themselves. And even if they do not yet know what the imperative steps are, they can probably read your code and understand what exactly you're doing. And then the same drill applies to docs writing. This is my magic line. The goal of this piece of doc is to do this. Whenever I work on docs, I always put this line on the first line. You don't have to think it's permanent. You're free to remove this once you are done. But for me, it serves two purposes. One, it gives me a lead in my thoughts, because I know what exactly I want to achieve with this little piece of doc. And then two, it starts conversation mode. So once I say this line, the goal of this piece of doc is to do this, it feels like I'm starting to talk to somebody. So that makes the language more natural. If we're starting with something more like speaking to a machine, and that will get us really nervous and cannot write something very eloquently. How many of us here are non-native speakers of English? Oh wow, that's a lot. Well, regarding this topic, I want to first let you know that there are more people on the web who can fix your grammar issues than those who will take the non-trivial efforts to write documentations. So please don't let this restrict you before you even start trying. And then I have a short list of tips. Improving English is a huge topic that I cannot finish within the given block of time. So please allow me to be brief about this, and only share a very few things I repeatedly do as I write the docs. So the first one is to make use of the source. It's a cheating trick. So if you YouTube search this, there will be videos teaching you how to find the source, and there are videos saying why you shouldn't do this. But I am very beginner to English, so it works well for me. And the reason is it is harder to come up with words than to pick from a list of words. So most of the dictionaries that we have even allows us to recursively try to find our terms. And then here we are looking for sources for cool. And then I think we find elegant, I believe. And then in elegant there is another term that says neat. And then once we go in, oh wait, ingenious, sorry. And then there is actually an example saying, an example of ingenious that's like an ingenious software solution. So it's a cheating trick. Let's see, do I have my notes? So the next one is proofreading. I think most grammar issues can be resolved by proofreading. Namely, what you do is, what works for me is I connect multiple times of proofreadings. And for every single time I target only one type of errors. Because all of those are really very objective, so you can't miss them. You can just go for one proofreading of your work, just go in for typos. And then another time you can just go for punctuations. You have one single task in your mind and then you can, it's only, so for the list here it's only five times. And I don't know if you will think this is a lot, but for me reading the piece five times is still taking a lot less time than writing the piece. So that works really well for me. And I have a very short list of books that I read in order to improve my writing. Nicely said is a book on writing styles in our industry. It is a thorough intro to proper writing styles for the internet context. It's very fast and lightweight. So I think it's good to get it started. And then on writing well it's like more classy look on writing in general. Slightly opinionated, it's worth, but it's also, but it's very amusing to read. So it's highly recommended.  It's written by a pleaser winning author together with his editor. It's not as relevant as the first two, but it's very beautifully written. It's very insightful. So if you want to go deeper into writing you can read that one. And then the fourth one is like the classic English text. So after a few months, Mark asks again for help on re-reduced docs. And he asked for an FAQ entry to explain some differences and comparisons between using Context and Redux. I actually had a eureka moment when I collected all the materials. I read up on the Context a few links. Once again he had all those planned out. And came up with a take on the issue until eventually writing everything down that fits the context of an official documentation. Everything felt nearly natural. So this was me. And then in case you need a little bit of more motivations, you may wonder if something is already talked about in multiple places. It may seem redundant for you to say that again in official docs. But chances are if something is already said multiple times elsewhere, it may exactly because it is both important and not addressed in the docs. So official docs has this unique place that it will likely be visited prior to other resources. And what's more important is that people will treat it as more sound than others. So if something that people are looking for is already in the official docs, they don't have to look elsewhere. So it saves their time. It will in turn save more time because the questions won't even to be written. And that's one fewer confusion by the whole community. And that's collectively better understanding and it's very powerful. So finally I want to share a few tips along the line. The first thing is to find docs that is suitable for yourself. It's easy to drift off. In fact, it's actually very common to drift off because writing is once again very hard. So there can be some projects that are easier than others for you to work on it. So I think it is necessary for you to work on projects that you yourself are actively using. And also try to find the projects that are actively maintained and the maintainers provide guidance on docs contributions. So I've listed actually in preparation for this talk. Originally it was a slide in my slides. And I think it would be a better idea if I collect these into a GitHub repo so that people can also pull requests. It's Hacktoberfest for requests to add the projects that you find are worse. Writing docs for things that you can learn something about. So feel free to request this repo. And then if you can find some tasks from your work related with the project that you are working on for docs or vice versa, your work tasks use something that is looking for docs contributions. I strongly urge you to do so because it benefits many parties. You can contribute to the project of the open source project. This is very rare. And then for you you will be directly speaking to the maintainers. This means that if you have any questions as you work on your work tasks you have close access to official help. Then it should not surprise you that the maintainers actually care about your use cases. Especially if they are developing new APIs and are looking for early adopters be that early adopter. And your feedback may be adopted and that makes you not only a follower but a creator of our future.  And I think that speaks about your seniority way more convincing than the time you spend in the company. Will your docs contributions always get merged? No. In fact a lot of docs PRs don't get merged. I have like a ton of PRs that never get merged or are merged like half a year later. So here are my takes. If you've taken your own notes or if you've built a demo and it doesn't take you much effort to PR this in then simply create a PR and see what we get from there. For projects that are maintained I think it is critical that you take inputs from the maintainers. I think official docs is a place where you should prioritize what the maintainers have to say over your own because the maintainers have probably seen more users than you have. And there are reasons why maintainers want certain things to be taught in certain ways. So this is a place where we should follow the advice from maintainers. Sometimes even if the maintainers didn't provide two specific requirements it doesn't mean whatever we write will be agreed upon. So in this case it is to our interest to ask in advance for maintainers inputs and the more effectively our questions can reflect the thoughts from the library maintainers the more likely our work can get merged. Well, next time when someone look for Doc contributors will this be you. So that is the end of my talk.


Hey everybody, welcome back to Madric with Oxy. My name is David and this is a follow-up. Hey, just wanted to follow up with you about the Laura London Knox from the Blue Crown. I mentioned in my review that they came in a deck stack, but there really wasn't any indication as to what the deck stack was. Laura London had dropped a hint that it had to do with a poker trick. She dropped that hint on social media. I was able to reach out to her and find out exactly what the deck stack was. Turns out it is the deck stack from the Madison gamblers. So if you were lucky enough to pick up the Madison gamblers on the DVD, Daniel Madison goes over a trick called the poker lesson. Now in the poker lesson, it's a Sam the Bellhop style effect that kind of comes out as a gambling demonstration. And what you do is you deal off all of these different poker hands to the spectator and then it's all revealed on this special gas card that's inside this deck. And so really, I think you kind of need both decks to be able to take advantage of the deck stack in the Knox.  All right, so my thanks to Daniel Madison and Laura London for helping me out with that and enlightening all of us so that we would know the answer finally. And big thanks to allusionist.com and thebluecrown.com. Talk to you later. Bye.


Autologous human-induced pluripotent stem cells, high PSCs, can be used to generate graft-retinal pigment epithelium, RPE, cell sheets that meet clinical requirements and show similar gene expression patterns, phagocytotic ability, and tight junctions as native RPE. These cell sheets have been shown to be safe for transplantation in non-human primates without immune rejection or tumor formation, suggesting their potential use in tissue replacement therapy for age-related macular degeneration, AMD.