One has actually hi everybody My name is Dave Martins and I am the new director at the Vermont affordable housing coalition And I'm here with Liz Curry from and the common land solutions common land solutions and joining us on the phone is Sarah teal from Voices for Vermont children and so we're here tonight to talk during our our time slot tonight about Housing and how it relates to children and to early childhood development and Just to sort of say a word about how This came about is that at VAHC we've decided to Kind of roll out. I guess you call it a program a new program where we talk each month about housing in light of a particular theme and so in September we were talking about How housing impacts the recovery community because September is national recovery month and so We decided that for October we would go with children's health and the reason for that being because yesterday The day before yesterday the day before yesterday was National child's health children's health awareness day and so the end of the month of course is Halloween which is a children's day, right and and so we thought that this would be a good theme to kind of to kind of talk about and The part of the reason for that is also that I don't know if you know this I don't say I think Sarah knows this because we talked about it on the phone the other day but children's health awareness day was established by Calvin Coolidge in 1928 who is from Say not Fairfield, Vermont. That's right from Vermont and and the reason why he established the day Was because children's health care at the end of like the 19th century was disastrous It was nothing like we knew it today and children sick children were literally being just kind of left and it was really an awful situation and He wanted to really raise awareness about this But the first few hospitals that opened directed to children's health care We're not like we would imagine today like Boston's children's hospital or it was their mission Was to provide food clothing and shelter To children and I feel like at the heart of that is a concept that today we would call Housing is health care, right because they understood that These children needed a home in order To get better and to be well and so really I'd like that to kind of be our topic for discussion is Housing is health care. What does that mean in the in the lives of children? so We've already talked Sarah and I Have talked a little bit about This concept a bit and how it plays out a little bit where what what do you think about that Liz? Well, first I want to thank you for the invitation and tell you just a little bit about myself as a consultant That incorporated common land solutions. I am not charging. This is volunteer time, but I spent 20 years in the affordable housing development community in nonprofits and specifically developing a lot in Franklin County in rural Vermont and Managed a housing rehab loan program and did some other things that were all kind of grounded in Way back when I was in the university studying actually housing zoning which grew right out of health threats and health conditions, so this is a really nice tie-in and then It's nice to have voices for Vermont children on the phone because I spent seven years on the school board in Burlington and worked with people who worked for Vermont voices for Vermont children, so I Appreciate participating in this conversation. Thank you Yeah, I mean there's so much to unpack around housing How the impact of affordable safety and affordable housing for children? especially in their early formative years And you know as you mentioned like early in the century 19th century There was a recognition that children were at risk their health was at risk if they weren't a Minimum fed and sheltered and those were probably you know in the form of orphanages or something like that But that was also the same time our zoning laws came into being and that was because there was Rampant there were pandemic conditions in overcrowded housing and so people were getting really sick So that is also part of the underlying architecture of housing as health care Florence Nightingale was a big proponent, you know And also I do want to recognize that you know we as a society Were were founded on the enslavement of Africans and we you know took land from indigenous We colonized land from indigenous tribes and so you know automatically we created a Land in a real estate system that put people out and failed to provide you know their basic needs for them and so you know our real estate system itself is just You know kind of on these pillars of a caste system that never delivered What is needed to? Have a healthy quality of life And so that's that's you know, I just think important to recognize And hold ourselves responsible and accountable for that I could go on and on about housing and health care because I spent a Couple years writing a playbook for how what energy and efficiency and weatherization Improves indoor air quality and that contributes a lot to minimizing the effects of asthma and for children. That is especially Important and you know leverages huge gains and positive impacts over time. So there's also just the physical Aspects of developing affordable housing in Vermont Is accomplished through a framework of funding agencies and technical assistance that delivers Healthy housing healthy indoor air quality and you know There are studies across the nation around the health outcomes of children and families who live in housing That's been weatherized and made more energy efficient. So that's another dimension of the topic You know what I love is like just in that Just kind of in those few thoughts we touched on like Equality right, you know raise the Racial equality racial justice like weatherization climate stuff health care, right and I Think that all too often Sometimes I think when we work kind of in the nonprofit field or in some kind of advocacy work sometimes It's very easy to end up in your silo and not kind of move out of it and I think that if there's any issue that we all can come together around It's housing and I mean it crosses all political lines across is all everything that you're not going to find anybody who says You know, no, you know, no people should just not have homes like no one thinks that exactly and so That's why we're really trying to be real intentional about Bring that to light and talking about housing in light of these different themes To kind of you know Make people comfortable to step out of their silo and talk about how this fits within the bigger system, you know So I'm so glad that you're that you're with us today. So glad you were this today Thank you and Sarah. I just love the name of your organization That that in and of itself does it for me Voices for children. I love it. Why don't you kind of tell Tell the folks who are watching a bit about yourself and your work and and a bit about voices for voices for children Voices I've been around for decades and we have always worked Holistically across sectors across the whole state to really try to I really am appreciating these comments because it's so clear That all of the systems are connected and all of them impact each other and also all parts of children's lives affect the rest of their lives and Housing is an example of that that's just very salient Not only is it incredibly common sense, but it's also really researched and backed by research in terms of health, especially There is a researcher who's pretty well known in Vermont. She's become well known in Vermont Megan sandal out of Boston she's a pediatrician and researcher and all of her work has basically shown the direct connection between Housing and health to the degree that she she has a phrase where she says housing is a vaccine And it's really interesting coming out of Well, hoping to soon come out of this pandemic year and a half When it it really was immediately obvious to everybody that housing was directly protective of people's health in that moment In pandemic conditions, but really it's it's that way all the time And especially for kids the you know the highest rates of homelessness are actually in the youngest children and Not only does it have like direct effects on their health which We all can understand and their well-being But it also just has really long-term cumulative potential effects and on all sorts of things like their education But in terms of like ACEs long-term health impacts way far into adulthood Those things are hard to calculate, but I think we all know that that they're there And I'm also really appreciating your comments with about the underlying system because I think Many of us who work in various areas are just really ready to think across those silos in a really transformational way Recognizing that the system that we have right now doesn't actually at all guarantee housing for children. In fact It works on a principle of scarcity and the roots are discriminatory of so many things as we know and I think it's really a good time to To think about how we can actually make this a guarantee and actually address the correcting for Those oppressive systems Yeah, absolutely, and you know, I think that we're in in such a you know, everyone talks about Or everyone uses these days the phrase unprecedented We're living in these unprecedented times in this Unprecedented crisis and everything is unprecedented. That's very true. I think part something else that's unprecedented right now is the attention That affordable housing is getting you know at the the legislative level certainly in terms of funding in terms of I mean, there's sort of all these Positive dynamics that are coming out of the crisis that we're in that truly is unprecedented and You know, maybe something also that will come out of that will be unprecedented work to get you know, even more intentionally intentionally together You know towards towards working towards a solution to this to this whole situation, you know So what is the do you want to say a word about the kind of advocacy kind of stuff that the voices does? Sure, we work primarily on state policy Like I said across all areas Economic security and economic justice are a very Core principle for us and housing is right in there with that And we also work, you know in communities and with communities various grassroots organizing Super and was there were you guys involved with the rental rental housing safety bill stuff? Not not as a lead no Sure Yeah, but I guess we're members of the housing the housing advocacy community definitely There's a lot of conversation right now starting to happen about the rental housing safety bills. We move towards another legislative Session right and that the We know that the bill had been passed by the house in the Senate and then was vetoed kind of surprisingly and You know, I think that there's it's important. I think that we continue the conversation though about how that we need a Rental housing safety bill You know, and if we got to start over whatever we're gonna do But we can't give up and we got to see the importance behind that piece of legislation and I think that The tie so obvious, you know in with in with children I think in particular the two pieces of those it's interesting when you talk about the bill It's always interesting to me what people call it. Some people call it like the registry bills So you'll call it by its, you know by at 79 But like I feel like we have to talk about Just a rental housing safety bill because that's what it is That's what it was and that's what we still need and that's you know What's gonna the fight that has to continue or the work? Yeah, that that needs to continue, you know Yeah, and on that point actually, you know rental housing codes were an Outgrowth of zoning codes and so, you know, there's a whole body of health and safety codes That go along with housing and I mean all of our codes are related to health and safety So it's interesting that you know people are willing to tolerate zoning codes But then the minute you go to, you know, regulate Housing which and housing is incredibly regulated in many ways people don't realize Usually to the benefit of the owner But you know when we talk about regulating Multifamily building there's a you know strange reaction that is again rooted in that concept of ownership and Proprietariness that our real estate system is based on because you know We don't recognize multifamily property as a business, which it is Speaking as a multifamily property owner. It's a business and it should be expected that multifamily property owners who Don't live in the building and those who do You know have a business that needs to be regulated for health and safety reasons the same reason we have liquor control You know the same thing we want to make sure the public is safe and healthy And we're not putting that public in harm's way, but that's Not a common way of thinking about multifamily housing. We think of it as like Oh, it's just your other house and you get to control Whatever or not or put people at risk and I I think there's a lot of opportunity to educate the public about Kind of that fundamental concept that you know We also for the first time if we're not have contractor registration. So there is finally a recognition that contractors go into your home and could cause health and safety problems for you if they're not skilled and qualified and so now we have a Registration for contractors requirement and that's you know along the same lines And we have fire codes and we have energy efficiency codes when you're building new construction. So Leaving out the rental housing code is just a huge Missed opportunity and it actually puts children in particular in harm's way Vermont has one of the fire highest fire rates in the nation From the old prop from old property that hasn't been reinvested in it hasn't been kept up And it hasn't been maintained the energy burden is huge for families Which takes food out of kids mouths and other you know basic needs aren't met because we have these very old Delapidated buildings where people pay exorbitant amounts for utilities every month. So yeah, there's there's a lot to talk about there I remember I was uh, you know, I knew I'm so I'm new to Vermont and I came from Rhode Island's the Well Rhode Island via Connecticut, but really I'm a Rhode Islander by origin and I worked there in the course of my In the course of my career I worked in well in the early days of my career kind of in direct care with with youth at-risk youth and their families and you know with we call the DC YF there not DC F but DC YF and I remember Kind of upon reflection one day After I've been doing this for I think two years two or three years at the time and it just struck me how so many of these families who were just stooped in poverty and They would get sort of linked up with You know DC YF involvement Because here you had like They were caught in this in that that system that that's not a liberating system at all right and so and it's constant crisis management and and mom can never or dad or mom and dad can Can't just get ahead you know and the primary You know they're looking at their kids and thinking like well We have to sacrifice for ourselves So we get to put the kids first, but sometimes there's nothing left to sacrifice and and it really is because of this And I think a large part because of that system that instead of liberating and empowering and freeing Can instead really really drown the person You know and I think that it's sort of You know, I have a friend who Does some uber uber driving part-time and it was commenting on how the amount of money that people spend on uber Why don't they just get a car and it's like well Because that's not the way the system works Right because the system doesn't allow us to save might miss the same kind of thing or get a loan Yeah, I get alone or like credit So, you know we end up caught in these systems And I think to a certain degree all of us in in different ways and smaller ways for some than others, but that In the in that system, it's the kids who are ultimately always always the victim and always the one who struggle and We got to work together to get Out of it and I think also I want to just bring up that you know the Let's grow kids was just able to move forward a significant bill on childcare and Sarah you probably know more about this than me, but you know now that they have finally achieved a pretty heavy lift a big goal You know when you think about Actually implementing that and you have families who are constantly moving around and In and out of homelessness It's like what happens when kids try and go to school if they try and go to child care You're gonna you know create a situation where they don't get consistent care, you know, and you'll see significant academic losses and you know just brain development losses and That sets them up for failure and then we as a society will spend more and more on Meeting their needs in a disjointed fractured way because our systems are not Aligned so, you know those that that stability that affordable housing brings in addition to having safe decent healthy affordable housing Just having the stability of housing Allows a family to access subsidized child care or school in a more consistent way Which avoids costs for us as a society down the road, but that prevention concept is I think still Has a ramp to go up before people, you know really Support spending now to prevent costs later So maybe the pandemic will You know, there's just a larger societal kind of psychological Shift that would need to happen in order to really be successful like Vermont has Universal health care for children and it is possible to calculate all of the savings from that but for whatever reason That has not happened and it could be demonstrated that the same would outcome would happen if we had a more affordable housing for everyone guaranteed sure That's a great point. It really we can either Protect the investments we're making in all the other systems, which are and should be significant child care education, right? Like we really Generally commit as a state to like having those systems be strong And and dr. Dine for right so and health care for children So we spend a lot of money in those areas as you're pointing out if we don't have Stable housing we're actually undermining those very investments at the same time as we're making them It's a cause there's a cost shift there to all of these other systems And it could be calculated. You're right like how much how much of those how much money would be saved by having? stable housing for every family for sure We're coming to the end of our of our time together. So I would throw out the one last Kind of thought for maybe if we could I'd love to just get a word from both of you about it That the end of last summer at the height of the pandemic we had 2000 Vermonters living homeless Vermonters living in motels in them through the motel program 400 of which were children We know that this program is getting extended some people have to gossip it, right? We all know the you see it in the news But those numbers strike me 2000 Vermonters 400 children. We need answers because this can't go on forever, but a Thought maybe from each of you about kind of the Part of the what's part of the answer Well from the kind of housing development side like creating housing I Actually opened the first COVID hotel in Vermont for CVO EO for a Champlain Valley Office of Economic Opportunity and the transformation I Think was phenomenal in terms of people just having that privacy a place to go every day no matter what Even though there was a lot of chaos around But I do wonder about the opportunity for the medical community in the hospitals and to become more engaged in this conversation in this issue and and that is happening certainly UVM has subsidized a Motel For Champlain Housing Trust. I worked on a project Rutland Housing Authority was able to get a huge Gift around 225,000 or more from Rutland Regional Hospital So the engagement of hospitals in providing capital because it will bring their costs down They are beginning to see that and then they are they are seeing those savings and that is more data more financial data To demonstrate that that partnership Can grow and grow? Sarah one minute Yeah, I'm gonna offer us a good a good closing thought a good closing thought It's a continuum right the unstable housing is a continuum all the way from being unhoused To having unaffordable housing where you're vulnerable to sudden economic shock shock shock loss, etc and That's that's an incompletely complete thought I was just gonna say that number of unhoused people During the pandemic Was higher much higher than that count in previous years and all of the housing advocates kind of said oh We told you this was the case right like there have been all along People who are not being counted like as a as an example In the 2018-2019 school year there were a thousand students that schools counted as Qualifying for services for homeless students under the McKinney-Vento Act Some of them are doubled up some of them are living in cars some of them are in shelters And some of them are unsheltered so in any case there's this whole continuum But I think what we would like to see is a system where There's much more democratic control of housing and where it's permanently affordable and not then like subject to the market It's just way too important to be just at the whim of the broader economy or Market cost is what it is like it needs to be Rooted somewhere else You're sure Well on that note it is a continuum and so is our work all of our work together that I like the picture of a continuum because it Keeps rolling and that's what we're gonna do keep rolling keep working together. Thank you both for joining us today and everyone at home join us again for our ongoing conversation about housing from a slightly different perspective With each show and if you have any questions about the work that we do you can find out everything you want to know and more at Vt affordable housing org and thank you for joining us and Sarah and Liz once again. Thank you. Thank you, Dave Would you think Sarah? Yeah, I mean as far as I could tell With really both of you it was really wonderful to hear your thoughts and I appreciate being here And thank you for joining us and please tell Michelle I emailed her but please tell her that I hope everything Hope she's okay. I think she's she's good. Yeah, she's got she's taken and care of it, but there was a sudden sudden blip Well, thank you. Thank you. Thank you. It's our I'll talk to you soon Session yeah, because it would give you a chance to talk about the coalition's agenda, right? You still there Sarah She's been doing Is it true that some of the numbers are Well, like one day Yeah, yeah, there's no trend One day data you can't watch the news It's true Yeah, so you don't live here before no, I was run island familiar Who's your celebrity doppelganger? I Was just talking about this last night, and I don't remember if you said the name Yeah Or with names, but yeah, it struck me. Did you grow up in New York like Michael site like Michael site Our R. E. M. You know the band I've gotten that right. Yeah, that's it. That's what I thought and my joke has been that taking over for Airheart as must this must be what it was like for Patrick Stewart When he Is not only am I a bald man


Hello, this is Demetrius Rump, the Director of Safety and Risk Management for the City of Columbia. This is your monthly safety message for the City of Columbia employees and the public. Today I'm going to talk about July the 4th, Safety and Fireworks. Summer is synonymous with barbecues, grays, and firework displays, but along with that, sometimes employees and the public make multiple visits to the emergency room for firework-related injuries. In 2017, eight people died and about 12,900 people were treated at the emergency room for firework-related emergencies. Never allow yourself to discharge fireworks after you've been under any kind of influence of any alcohol. Never let small children count the fireworks. Also, make sure that you never light fireworks indoors. And if all is possible, make sure you keep a bucket of water nearby so you can extinguish a firework or if it malfunctions. And never try to pick up a firework to have malfunctions because you don't know if it's live or not. But better yet, why don't you just grab a blanket or patch a grass and go to a firework display and leave it up to the experts. The City of Columbia would like for you to enjoy your new out-of-float with a big bang. But remember, safety starts with an S, but it begins with you. Thank you.


It's one of those habits you can build that really is a primer to resetting your nervous system and your metabolism. And I think we're just beginning to understand all the benefits. You mentioned that you did it for athletics. A lot of people start there. I think the biggest conversations are going to be around the mental space. I don't really think there's anything like the cold that can help somebody completely reframe their perceptions around their hardships, around trauma, around the difficulty, even of the day ahead.


With the release of the first developer diary for a leak dangerous odyssey We finally have our first tentative looks at what the expansion will look like and what we can expect In this video We're going to break down what the video tells us and what details we can glean from what was shown In the four and a half minute video We see snippets of interviews with some of the frontier design and development staff as well as some pre alpha in-engine Footage. We are also shown concept art and renders of the space-suited Commanders of the type that we saw in the odyssey announcement trailer However game director Piers Jackson also makes mention that as part of wearing the space suit You'll hear your own breathing whilst inside it Fantastic audio design has always been part and parcel of the design of elite dangerous And it'll be fascinating once we see actual gameplay to hear that design work Extended to the on-foot experience as the team continued to describe the experience of finally being able to stand on the surface of an alien world We are shown a space-suited commander looking up from the surface of an airless world Whilst standing in front of an SRV This is actually quite a significant shot whilst we'd always assumed that the odyssey on-foot experience would extend to the airless worlds of horizons. It's never been explicitly stated as As part of the diary it was great to hear and see that exploration in odyssey was very much front and center throughout Some of the major concerns we'd heard voiced after the launch trailers release Revolved around its emphasis on weapons and guns and there were fears in certain quarters of the community that odyssey Was nothing more than a first-person shooter add-on whilst we didn't hear believe that to be the case It's nice to see frontier addressing it perhaps as a response to the community reactions to the trailer Exploration is a massive component in the overall elite experience Arguably one of the largest parts of the community in fact and it makes absolute sense that odyssey would extend elite's already Existing exploration gameplay down to the on-foot level To further underline the exploration slant of the whole diary frontier showed off concept art for new flora That will be discoverable on planets with tenuous atmospheres and the exploration angle was again further underlined With a look at the new handheld sampling tool that will allow players to take genetic data from flora add it to their codex and Also exchange the data for rewards in the game. What those rewards are we have yet of course to find out The video contained a number of scenes showing off the new planetary surface rendering technology That is being developed for odyssey and this footage did provide the most visually impressive revelations of the diary Both from orbit and down at ground level the new planet and atmospheric tech looks seriously impressive by way of comparison We visited the planets that were shown in the dev diary in the current live game And the two different versions are if you'll excuse the pun worlds apart The current versions are fairly bland featureless and frankly fairly uninteresting to look at in odyssey They really come alive with detail and we're promised ice and rock specific features Accurate to what you'd expect to find in the real environment in true elite style This first dev diary was a small peak at some of what we can expect from odyssey and as such it does that job Just fine. Will it persuade any of the current odyssey naysayers? No, I don't think it will to even begin that process We really need to see and hear actual gameplay and I'd argue that that's not what this initial dev diary Pupports to be showing what we do have here is a very good graphic demonstration of the new planetary and Atmospheric rendering technology and some hints at where the gameplay for explorers and wanderers in the black might be headed What will start to ease some community fears are actually smaller details like how will atmospheric entry be handled? How does your commander get from the chair to the foot of the stairs outside the ship? Can you move around inside your ship? How will the handling of ships weapons and SRVs be affected by the presence of an atmosphere? These are all very valid questions And I'm sure answers to them are coming and we are still at least five months away from the release of odyssey What we have in this diary is a solid start the planetary tech in particular is looking stunning And it's left me very keen to see and hear more Thanks very much for watching if you've enjoyed this video remember to subscribe to the channel And we very much look forward to seeing you next time


Folks, this one is just bizarre. More so than just the typical confused incoherent Joe Biden clip. Here we have a clip of Joe Biden apparently answering questions about Afghanistan when the damn Easter Bunny shows up and directs him away from the press. Why is an Easter Bunny stopping the president from asking questions and directing him away? It's like the Easter Bunny is taking care of one of the kids. He looked legitimately frightened by that rabbit.


But we're going to make an incision right on the border of the dark and the light. We're going to open that up, and I'm going to take out the gland right here. And I'll show you that in just a second. See how it's releasing right there? So we took out the gland. You can see inside there's no gland. That's the muscle in there with a little bit of fat. You need a little bit of fat. You can see it's nice and thin. So I check, make sure there's no gland left. It's all nice and clear, and we're done with it. Ready? So we're done with it. We took it out. Now we're doing a running suture. As you can see, the scar is going to be hidden between the dark and the brown. Eventually, there won't be any mark. You can see it's perfectly around the areola.


Hello everyone. Welcome to this talk, Kubernetes Cloud Provider Project for IBM Cloud. My name is Sadez Zala. I am a senior software engineer and open source developer at IBM. I contribute to Kubernetes. I'm one of the maintainer for the XD project and I am one of the co-lead for the Provider IBM Cloud project. I have a pleasure of having Richard Thais with me today for recording of this talk. Richard, would you like to introduce yourself, please? Yes, thank you. I'm Richard Thais. I work for IBM as a software engineer on the IBM Cloud Kubernetes Service and Red Hat OpenShift and IBM Cloud Managed Services as the release lead for delivering OpenShift and Kubernetes releases to our platform. With Sadez I'm co-chair for the Cloud Provider Project for IBM Cloud. Thank you. Thank you, Richard. Hello again. For the agenda, we will provide an overview of C Cloud Provider and this Subproject Provider IBM Cloud. This is part of the maintenance track, so we'll definitely give some introduction here of the project. We'll briefly cover activities and then we'll talk about cluster API provider for IBM Cloud and the IBM Cloud Provider, which Richard will give a deep dive. I might already know about the Special Interest Group Cloud Provider. It owns Kubernetes Cloud Provider interface, the code and related work, which is responsible for running all the Cloud Provider-specific control loops.  For example, load balancer, that's one of the examples there. You can learn more about the code there in the Kitabripo for the Cloud Provider. I have put a link here. The SIG also ensures that the Kubernetes ecosystem evolves in a way that is neutral to all the Cloud Providers. There is no favor given to one Cloud Provider or other that kind of things. It also ensures a consistent and high-quality user experience across different Cloud Providers. The SIG also owns the subprojects from various Cloud Providers. For example, the project we will be talking today, the IBM Cloud Provider, it's one of the subprojects and some other examples are like Provider AWS, Provider Azure. You can learn more about all the subprojects in the link that I have provided here. The Provider IBM Cloud, as I said, it's a subproject of Cloud Provider. You would be interested in the project, especially if you're interested in building, deploying, maintaining, supporting, and using Kubernetes on IBM Cloud Platform. The project also owns the cluster API code of IBM Cloud. We will talk about it and then I will own the code from IBM Cloud Provider once we have that open sourced. As you can imagine, as part of this subproject, we have IBM Cloud Teams developers, leaders, they're talking through the open discussions about what's happening there, sharing with the community, working with the community, so that folks can follow the evolution of IBM Cloud Platforms with respect to Kubernetes and other CNCF projects. One thing I would mention here is the subproject is, it's for the open source-related discussions for Kubernetes and other projects. It's not for any sort of commercial kind of discussions, so we totally discussed that kind of discussions. A bit about the structure. We have three different leads for the project. From the different areas of IBM Cloud side, we have Khalid Ahmed, who is an IBM Distinguished Engineer, working on multi-cloud management. We have Richard Thys, who is a speaker here as well, from the IBM Cloud Kubernetes Service, and with that OpenShift Kubernetes Service myself from the open source side, from the community side. I have given a link for the mailing list here, so please join the distribution list there. We would love to have you. Part of that, we have a provider IBM Cloud Slack channel on Kubernetes.slack.com. We would love to have discussions there, questions, any kind of other thoughts, and then you can learn more about the subproject in the link provided here. The subproject team, the folks who are interested in the project contributions, the leads, we meet every last Wednesday of the month, so once a month, unless there are things like holidays or no agenda kind of things. Again, we would love to be part of these meetings, provide your inputs, contribute to the betterment of the subproject, and take a leadership role. If you miss meetings and interested to see what's going on, we have recorded all these meetings. We do record as we have meetings and upload the videos on the Kubernetes Slack channel. Again, the link is provided here. You can take a look and watch the videos. We also participate in the general activities of C Cloud provider through their bi-weekly meetings, during face-to-face conferences. We meet in person and brainstorming about the ongoing things, about strategy. As I mentioned, the IBM Cloud provider owns a couple of things here. The cluster API provider IBM Cloud, excuse me, it's a GitHub repo that I'll be sharing in the next slide, and then the IBM Cloud provider, which we will talk about. The cluster API provider IBM Cloud, before I talk about it, let me briefly mention about the cluster API project. As you might already know, it's a community project from Kubernetes community. It was created sometime back with the goal of managing the life cycle of Kubernetes cluster, creating, scaling, and destroying, cleaning up kind of things. Through declaratory APIs, which are basically Kubernetes style APIs, you can read more about the cluster API project, a lot of good documentations. There's actually a whole book there. It's a good reading to learn about cluster API. As I said, it's a similar style declaratory APIs like Kubernetes, also the CLI. As you can see here, cluster CTL, similar to Kube CTL, to work with the management of cluster, it's there. Different cloud providers, they typically extend the cluster API project. They extend it to meet their own requirements, to provide the support for a specific cloud provider. From IBM Cloud side, the cluster API provider IBM Cloud, the KITUB repo we have. Again, the link is provided here. We basically extend the cluster API project for IBM Cloud for the different infrastructure of IBM Cloud. We already have a stable support for classic infrastructure, what we call, but as you might know that lately the VPC Gen2 was announced, we have a power virtual system, a virtual server, right? We have a work going on. There are a few PRs out there for review. There are some issues out there. So we'd love to have you take a look, provide your review comments towards the work. That's like in progress right now to support different types of infrastructure. That involves some refactoring as well. So as I said, we would like to have you review those things, provide your feedback, contribute as much as you can. With that, let me have Richard to talk about IKS and then IBM Cloud provider. Richard, would you like to take over from here, please? Yeah, definitely. Thank you. So yeah, we'll continue the conversation here into the Cloud provider project here. I will set the stage a little bit talking about IKS and ROX first, and then go into the details under the covers there. So we'll start with IKS, which is IBM Cloud Kubernetes Service, which is the managed offering that we provide to create clusters, good clusters on IBM Cloud. One of many Cloud providers out there that provide such a service. So it's a starting point for where our Cloud provider is used. As you can imagine, IBM Cloud provider running in this service. If you want more information on the service, feel free to check out the link I provided there. Key thing here is it's a certified Kubernetes offering from the CNC app. So this is a really important piece for the Kubernetes ecosystem to provide certifications, whether it be a managed service or a distribution, that you can say with confidence if you're running your applications on this particular thing that it's certified Kubernetes to run the Kubernetes APIs. So with that, we'll jump to the next slide. And we'll go over some of the release processes for IKS and how they relate to the community. So this year, 2021, we've released 1.20 release of Kubernetes. Last year, we had three releases in the 2020 time frame, 17, 18, 19. And we've found from our users and internal and external that maintaining currency with Kubernetes and the entire ecosystem of CNC app can be rather difficult because of the speed at which they move. So looking into the more details, we've seen not only us, but it's really a lot of industry-wide, a lot of folks seeing the similar thing. So it's not just unique to folks running Kube on IBM Cloud. It seems to be very pervasive. A lot of discussions on the topic. And there's a new cap, SIG release, cap to add release cadence for Kubernetes. And this is a really, assuming it gets approved and merged, this cap would have some key impacts to the project and to all those consuming the project downstream. So proposals to go to three rather than four releases of Kubernetes every year, believing that a lot of background investigation that's gone into it, feedback surveys and such. So that I think have a good direction for the community to pursue. And so if you're interested in following that and how that's going to play out, certainly a lot of the ecosystem will be impacted by the result of this. And I think for the better. I think for the better. In as far as patch releases are concerned, so this lays out the high level of the major minor release updates. She usually have been for a year coming down to three potentially. They also could release his patch updates every month. And we've done the same for IKS. So very good cadence there on delivering patches. And for the most part, very good quality coming out of Kubernetes community. All right. Next slide, please. Rocks, which is Red Hat OpenShift on IBM Cloud. We call it the Red Hat OpenShift Kubernetes Service Internally here. It's another managed offering this time allowing you to create OpenShift clusters on IBM Cloud. So we're all about, you know, in a cloud provider being able to provide both Kube and OpenShift through our cloud provider, same cloud providers used for both. If you want more information on OpenShift in service here, check out the link. Again, certified Kubernetes. So under the covers, same stuff. All right. Next slide, please. Just like IKS, Rocks has a very similar release cycle. Okay. And it's again, based on OpenShift and OpenShift based on Kubernetes. So you can see the cascade. This is one of many examples in the Kubernetes community with respect to applications running on top of Kubernetes and how a lot of them have a similar release pattern to underlying Kubernetes. So for Rocks, we've had one release this year, four, six OpenShift on top of 119 Kubernetes, that is, and three releases last year. You can see them listed out dates and so on. Again, both for Kubernetes users, but also OpenShift users, they see the same pattern of adoption and issues and concerns, which is can certainly be alleviated through vendors, supporting things longer, but it makes it more difficult, especially when the underlying support is not there from the community. So again, this cap will have impact, like I mentioned for CUBE, but also for OpenShift going forward. And I suspect we might see some changes potentially coming from these downstream providers as well. All right. Next slide, please. All right. So how does this all tie together? So as, as I said, we're, we always love talking about community stuff, Kubernetes, on IBM cloud, right? And most people deploy it through the managed services, but certainly they could deploy it other ways as well. And so supporting those in whether, however, they want to run it, usually an important piece of that is the cloud provider and then the cloud controller manager in particular. So Rewind a few years ago and how the community used to manage and work with cloud providers within the Kubernetes code base, they were actually statically linked into the binaries built for Kubernetes. And so they were very tightly coupled, both from the control plan and in the worker nodes. So now the new architecture, which the community has done a great job moving forward on and getting really close to the end game here is to be running a cloud controller loop, controller manager, if you will, in the control plane that handles the connection to the cloud. And that's, that's the end game we have gotten there, especially in 120. We've communities completed a lot of the extraction and migration work. There's still a few more things to go, but a lot of groundwork has been laid for that. So the architecture here in the diagram showed comes from the Kubernetes documentation detailing where the cloud controller manager usually sets within a cluster similar to the Kube controller manager, but it is responsible for cloud loops and delivering those reconciliation loops within Kubernetes to deliver your load balancers and other main pieces of the cloud. Some cloud providers can run their cloud controller managers. They don't have to be in the control plane. They can actually run the data plane within the workers as well, like in a demon set. That's also seen as well. All right. Next slide, please. So if we dig under the covers a little further, look at the cloud controller or the cloud provider, the interfaces, what do those specifically mean in the context of Kubernetes? So the first main interface is load balancers. Every cloud provider has some type of load balancer service they'll provide. And then different implementations of that and different options for it. We're no different on IBM cloud. We have a set of options here for load balancers that you can run, whether it be on the classic infrastructure that we provide, which would be your network load balancers, version one and two, they run in cluster. And then if you're on the VPC infrastructure, you have a VPC layer seven load balancer or VPC network load balancer, and we continue to work on providing, you know, enhancements, new feature function for load balancers. So that's the main interface. Then you've got another main interface here, the instances interface, which is also the nodes interface, if you will, along with that is the zones interface. So these are really important pieces needed to bring up your cluster. Of course, you got the load balancers, you've got the nodes on the infrastructure that you need to manage. So the instances has two versions of the interface, for instance, is V1 and V2. V1, the V1 interface, if you will, is like the interface of the old architecture. It works on the new one, but they wanted to enhance it. So I believe in 119, they started working on a new V2 interface. I think it's beta now in 120. So we're going to look at pulling in and using the new interface a little bit more efficient for the new architecture, the cloud provider. So that's more of an implementation detail. But nonetheless, you can see the moves forward in the community on improving the interaction with the cloud. So that's the nodes interface, and then zones is similar. But from our standpoint on IBM Cloud, we rely on node bootstrapping process to help set things up to implement this interface. Another interface is the clusters. We don't implement that. And then lastly, we have routes, again, not implemented for our cloud provider, because we rely on Calico to provide the routing necessary. But now these interfaces all being available have their own controller loops to go along with them. The nice thing with the new design from the community is that we're able to now turn on and off interfaces that are interesting to us for our interface to turn on and off the control loops that are of interest. So if we're not using a control loop, we can shut it off now in the new version 120 from Kubernetes. So we'll go to the next slide. We'll look at some of the enhancements and activities that we've been working on for the cloud provider. So some of the big things here in 120, which is really awesome, is that the community has made great strides forward again on extracting the cloud specific code from Kubernetes. So the cloud provider code, if you will, to make it more cloud agnostic so that you can have some base controllers there that folks can leverage. And then we have a little set of build tests, examples to build cloud providers, a release process guide that helps cloud providers have some consistency across that, not necessarily a binding requirement, but at least a good process going forward. And so these have all been very beneficial, allowing us to instead of what we always had to do is vendor or have Kubernetes, the core Kubernetes be a dependency of our cloud provider. No longer has to be the case anymore. So we can build a cloud provider much smaller, less dependencies, less conflicts, if you will, that can go into all the large set of vendor that Kubernetes has today. So that's a real benefit of 120 that we were able to take advantage of, much cleaner build process. We were able to move to Go modules for dependency management, also a nice move forward. And we're looking towards the future here, like I mentioned, we're looking at V2 interfaces, implementing that for instances. Looking at open source for the cloud provider definitely makes things a lot easier as the community has made the extraction and migration much smoother, improving our documentation. And as always, adding more feature function, of course, in the area of load balance is one of the big ones. All right. Next slide, please. So that kind of takes us through the ecosystem of Kubernetes and how we leverage it in the IBM cloud space and a cloud provider and how it's used within that. And now let's talk a little bit more about Kubernetes and OpenShift and how they're similar in difference. So from our standpoint, running OpenShift on IBM cloud is like running Kubernetes on IBM cloud. A lot of similarities are both certified. And from Red Hat's perspective, it talks about their documentation. Red Hat OpenShift is a Kubernetes distribution. So it contains additional features beyond Kubernetes. And this is not uncommon. There's many, many providers out there that have a distribution or managed service. You take Kubernetes open source and you provide a little bit more of how you add to that. And so this is no different. You have a few interfaces that you work with on Kubernetes and OpenShift that are very similar, but yet have a few differences. OC is the CLI for OpenShift and kubectl is the CLI for Kubernetes as you are well aware. Very similar. You can effectively run very similar commands and in fact, just replace kubectl with OC and usually the same command and work is right after that. There's UI for OpenShift, console, administration, operations. In Kubernetes, the community provides a dashboard. Your distribution or your managed service may or may not provide it with you, but there is a community dashboard for Kubernetes that you can do a lot of similar things there. Tooling for image creation and deployment. One of the really nice things, and I think a lot of the ecosystem around Kubernetes takes advantage of it. It's like kubectl is a really good building block, but it's not the end solution in the end for your business. So a lot of times people want to build on top of that, so it can be day two operations. So OpenShift has some of that as well, automated installs, updates, and so on. A catalog of operators and applications provided by both Red Hat but also the community at large. There's a lot of benefits there. And then if you go back to the earlier conversation, you're talking about the releases and the release cadence of Kubernetes changing that certainly has a broad range of impacts to OpenShift, but also all those operators' applications that are running on it on top of it to make sure that they stay current with those releases coming out. And the last thing I wanted to touch on is security. Obviously Kubernetes and security is huge, and a lot of effort has been put on that in the community to securing Kubernetes by default and addressing potential weaknesses. And OpenShift's no different. A lot of focus is on that as well, keeping your images clean of CVEs and so on. One of the key differences that most folks may be not aware of off the bat is that pod security in particular is a little bit different on OpenShift than in its Kubernetes. And in particular, OpenShift provides security context constraints to help manage what pods can and can't run and what they can and can't do. In Kubernetes, you have pod security policies. They're very similar, but there's a lot of significant differences in how they're used. Yeah, how they're used and how they work and to achieve the end goal, which is basically that pod level security and security of the entire cluster container level. So the thing with pod security policies being provided by Kubernetes is that there's now active conversation about actually deprecating pod security policies and looking at what's the next thing to replace it. So an important conversation, I think, for the entire community, ecosystem around Kubernetes is that security aspect. So I'm looking forward to seeing where that goes because it certainly will have a broad range of impacts to our community, both in the Kubernetes and OpenShift space and the applications running on top of that. So I look forward to that in the coming years to talk about this. If folks have interest in discussing these topics, these are very good topics for our project group. With that, we'll jump over to the next slide, which I think takes us to the end. And thank you to all for attending and wrapping it up from here. So back to you. All right. Hey, Richard, that was great. Thank you. Thanks everyone again. If you have any questions, please reach out to us. Otherwise, we'll see you during the playing of this recording at the KubeCon and we will take questions at that time. Well, thanks again. Thank you. Bye.


So, hi, my name is Hari Gopal. I'm the engineering lead at a small team that works out here in Bengaluru called Startup Village. And I have been working on a personal project for about a year now, a password manager for Teams. So why a password manager? A password manager is a tool that I have used throughout my career. And there was always something about them that were features that I didn't like, something about them that ticked me off, everything that I use, some feature that I didn't like, something that I just plain hated. So I thought, well, why shouldn't I make one? I have been working on web applications for well over 10 years now. So why shouldn't I build one? So that's exactly what I did. About a year ago, I decided to build one. I really wanted to build an application that would run on the desktop and something that would run offline. So I picked framework and tooling that I was familiar with. I chose React for the front end, React and Electron for the front end, and Ruby and Rails for the back end. And I got started. But after a few months, I started running into a few issues, especially because I had chosen to build a proof of concept and I had made the decision to not write tests. So that sort of came back to bite me. What I should have done probably in hindsight was write test from the scratch. But now that I was where I was, I had a few choices. I could either start writing tests and do TDD going forward, or I could try something out that I had been hearing about from what seemed like every direction, and that was to introduce static typing. Now, I didn't really have any experience with static typing till that point of time. So... But it looked cool. I mean, there were features that I thought made sense, and I thought, well, why shouldn't I try this out? I might as well learn something new while I'm doing this. So I shopped around. I looked at what my options were at that point of time. And there were four that stood out. There was TypeScript and Flow if I wanted to keep my code base intact, and I wanted to gradually introduce static typing to my code base. And then there was ReasonML and Elm if I wanted to completely convert my code base to a static-type language. And I ended up choosing Reason because of a couple of things. First, ReasonML looks a lot like JavaScript. It's syntax is very familiar. I liked that. I liked that I didn't have to learn something completely new. But it also had features that I had never seen before, and that was exciting. Two, ReasonML is created by Jordan Woke, who you probably know is the creator of React, and I love React. So there's a lot of intellectual powerhouse behind Reason. Third and most importantly, I have two friends who have been working with ReasonML, who had been working with ReasonML for over a year at that point of time. And I knew that since I didn't have any prior experience with static-typing languages, I would need help and I was sort of looking forward to bugging them for help. So what is Reason? ReasonML is actually not even a true language. It's a new syntax for OCaml, a 20-year-old systems language, which itself is derived from a 45-year-old meta language, which means that it's part of the ML family of languages. Which is a smart people language. And what's special about OCaml is that there is a project tenant called BuckleScript, written by some fine folks over at Bloomberg. And what BuckleScript does is it takes OCaml and converts it to JavaScript. And what's special about the JavaScript that BuckleScript creates is that it is very clean, very readable, and it is also quite performant. So Reason, toolchain, it takes ReasonML code, passes it through the toolchain, converts it to OCaml, then uses BuckleScript, and then converts it to JavaScript, which seems kind of complicated. And it only seems that way because the toolchain works so well that all of these shenanigans are hidden behind the scene. So we don't really get to know all the different steps that it goes through. We just see Reason code and the output JavaScript. How hard is it to get started? Well, I can safely assume that most of you are JavaScript developers here, which means you probably have node installed on your system, which means there are only two steps. You install VS Platform, and then you install recent CLI for your particular platform. And assuming that you have VS code installed on your system, which is, again, very likely, there is a plugin that gives you excellent editor integration. So that really is it. All right, so let's look at some code. But before, just before that, let me point out that ReasonML is statically typed again. And it also has something called sound typing. What it means is that if some Reason code compiles, then it is guaranteed to, then the compiler is guaranteed to know the type for every single binding that you have written. And this is true even if you have not specified what the type for any particular thing is.  It has a very good type inference mechanism called the Hindley-Milner type system. That was introduced back in the original Metal language 45 years ago. So it's gone through quite a few iterations. Works very well. And the best way for me to characterize the type system is to say that it feels like a human is sitting there and trying to figure out the types for the code that you have written. And we'll see this in the examples. So this is how we're gonna look at Reason code today. So on the left in black, I'm showing you Reason code. And on the right in white, I'll show you the corresponding JavaScript code that is generated by BuckleScript. So here, I'm simply saying that car is equal to bloom out of the 800 and that compiles to something extremely similar on the JavaScript side. I think particularly interesting going on here. But you'll note that if it compiles, reason knows that car is a string. I'm not saying that it is a string anyway. I don't need to. When I look at it, I know that it's a string. So what is Reason? That's how the type inference mechanism works. Let's look at something a bit more complicated. I'm adding two strings. I'm saying that car plus plus sold out. Plus plus for, is just the string concatenation operator in Reason. So Reason has different operators for different types. It's just a little quirk that you get used to pretty quickly. But if I try to do something like car plus one, that obviously generates a compiler. Why? Because this has type string and your editor would point out that with some squiggly lines at the bottom of car, saying that car is type string, but somewhere wanted int. And by somewhere it means that you're trying to do a plus one. That is not okay. You have to change that. Now Reason also has something that looks very much like JavaScript's objects. In fact, in this example, it looks exactly like an object, but it doesn't compile. And that is because in Reason, these are called records and records must have an explicit type definition.  We can say that type car has three properties, color, make and model. All three are strings. And now it compiles. You'll note that I'm not actually saying that my first car is a car. When we look at it, we can tell that my first car looks like a type car. So that's how Reason works. It compiles. And on the JavaScript side, you'll also notice that instead of being an object, it's actually an array of strings. But BuckleScript leaves helpful comments in line because it wants the code to be readable, just in case you need to go in and make changes, some sort of production issue or something. But this is still quite readable. Now there's something in Reason that blew my mind when I saw it for the first time. And that is variance. Variance gives us a way to model different possibilities in code in a way that I have never seen before. So type color is a variant. And I'm saying that it's either red, blue, white or pink. And those are the variance constructors. So you can read this as color is either red or blue or white or pink. Only one of those things. So I'm gonna use variance to change our previous example. I'm gonna say that there is a make manufacturer who is either Maruti or Hindustan Motors. Model is either 800 or Zen or an ambassador. Color is either red or blue or white or pink. And now instead of the type car being having string values, I'm gonna say that make is of type make. Model is of type model. Color is of type color. And with this, we can change our previous record to say make is Maruti. I'm gonna use the constructor. Model is 800. Color is blue. That reads pretty well, I guess. It should not be confusing. And on the JavaScript side, you'll notice that instead of it being a string, those constructors are being converted to integers. Now this is something that a compiler can do with extremely, I mean, perfect accuracy. Machines can do this sort of translation. So we can't, even if we wanted to. But because SpockerScript wants this code to be readable, it still leaves helpful comments in line in the JavaScript output. The truly mind-blowing part about variants is when you try to do something called pattern matching on them. What I've written here is a function production run, which takes a car and then returns the years during which the car was produced as a string. So I'm gonna use the switch statement to pattern match on the cars model. So you can read this as switch on cars model. If it is an 800, give 1983 to 2013. Now you'll notice that there is no explicit return statement in this function because like a lot of languages that you might have seen, the final expression in a function is what is returned from it. So this particular function in reason looks quite simple. If you're a JavaScript developer, it should be pretty readable. But on the JavaScript side, the output is quite complicated. It's requiring something called camel built-in exceptions. And it says in the function, if the match is not equal to zero, throw a match failure. But otherwise return 1983 to 2013. And why is this happening? Why is there so much? Why is it even throwing a failure? Well, it's because we are ignoring a warning from the compiler. It's telling us, you forgot to handle a possible value here. For example, send an ambassador. The thing is the compiler knows that a car's model is one of three things. It's either an 800 or a model, or a send or an ambassador. And it's reminding us that we have forgotten to handle these values. So let's fill the function in, do what we were supposed to do to begin with. So let's fill in the values for ambassador and send. Now on the JavaScript side, you'll notice that it is much cleaner. It's just got converted to a switch statement. And that's it. And the thing to notice, reason knows that this function cannot fail. It is impossible for this function to ever fail because it knows that the car's model is only one of three properties. So it will always return a type string and it'll always satisfy all of the possible inputs. So this is how the compiler works. So assuming that we use variants to model all of the possibilities in our code, how do you say this? It removes a lot of overhead in terms of what we as developers need to keep in mind to remember when we make changes. You are shifting the responsibility for remembering to a machine. And machines are much better at it than we are. So these types that we have written are already useful. It allows us to not have to remember everything that every possibility that our code handles, we shifted that responsibility to the compiler. That's great, it's useful. But this has an issue. It lets me write something like this. Now I have never seen an ambassador in pink on the road. It's a odd thing. Now you could presumably purchase an ambassador and then paint it pink. I would question your taste, but it is something that you can do. So it is within the realm of possibility, but you certainly couldn't purchase a pink ambassador from Hindustan Motors. It was never one of the factory approved colors. Similarly, you could never purchase a pink 800. It just wasn't available in pink. You can, however, purchase a pink Zen. That is one of the approved colors. Huh. However, this is something that you will never see on the road. A Maruti ambassador. What is that? And yet it compiles. It gives you a valid record. There's something wrong here. Why is that? Well, it's because we've defined car as having three properties, make, model, and color, and they are apparently separate, but they're not really separate, are they? In reality, a make, a manufacturer, would have a certain set of models. Is it working? Great. So in reality, a manufacturer would have a certain set of models, and that model would be available in a certain set of colors. And often it's like some, they give it fancy names. These models have fancy named colors. So what really exists in the real world is a nested relationship. Manufacturers have models, models have colors. And there is a way to model this in ReasonML. So the next slide that we're gonna look at has a large chunk of code. Don't be frightened. We will take it from the top down.  These are some of the colors, the actual colors that the ambassador was offered in. Similarly, I'm gonna write zen colors. You'll notice that there's a fusion pink in there and then 800 colors. You'll notice there's a blue blaze in there. Now the interesting stuff happens in the second block of lines. I'll write that there's a Maruti model, a set of Maruti models. It's either an 800 or a zen, but the constructor is taking an argument. I'm saying that if it is an 800 color, 800 model, then it needs an 800 color. If it's a zen, then it needs a zen color. Similarly, Hindustan Motors, we're really concerned with one particular model here. So it's an ambassador. It has an ambassador color, an ambicolor. Now, your make is either a Maruti or a Hindustan Motors, but if it's a Maruti, it must be a Maruti model. If it's a Hindustan Motors, then it's a Hindustan Motors model. And now we only really have one property left in car, which is make. And because there's only one property, I can actually roll that up and say car is either a Maruti with a Maruti model or a Hindustan Motors with a Hindustan Motors model. Now with these types in place, can we write the cars that we wrote earlier? So we can write a blue Maruti. We can say blue Maruti is a Maruti 800 in blue blaze. This is a nested relationship. From the JavaScript side, you'll notice that it compiles with by requiring a block and then saying, and then representing the nested relationship with blocks. So the values for the particular constructors as integers are still the same, but instead of it being an array, it is now nested. So this compiles, it's valid. How about a pink ambassador? This doesn't compile. What's the error? Constructor fusion pink does not belong to type ambicolor. This is something that the compiler knows. It knows that if it's an ambassador, the constructor only accepts an ambicolor. Fusion pink is not the Zen color. So it doesn't compile. How about a Maruti ambassador? Constructor ambassador does not belong to type Maruti model, same as before. Knows that Maruti only accepts a Maruti model. Ambassador is not. So what we have done here, we've pushed business logic into the type. And this is a pattern that you'll find applied again and again when you're using a functional programming language. And we call this make illegal states unrepresentable. So when types are written correctly, it can prevent you, the developer, from even writing an invalid data structure. In a lot of cases, our applications go into a error state. They have bugs because our state, our data structure tends to contain incorrect data. So if compilers make this impossible by writing correct types, then it can potentially prevent a very large class of errors. But so far, we've only discussed data that exists inside of our code. So far, I have been the one defining the data in my code. What about data that comes from the outside? I definitely have no control over it. For example, you could have some data coming in from an API or you could have a UI, for example. Let's imagine that there's a UI that looks like this. For some reason, it hasn't been designed very well. And the user has been allowed to accept to select Maruti Ambassador in Fusion Think. Now the question of why the UI was designed this way is not relevant, let's just ignore it. Assuming that this form gets submitted, we can assume, we can imagine that our application would have to deal with some values that look like this. Three strings, Maruti, Ambassador, and Fusion Think coming from somewhere outside of our code. Now that it has landed here, what can we do with it? We have to remember that functions in your code, they use the type car. For example, you could have a production run function like we saw earlier. It takes car, returns production run as a string. Or perhaps you have an in-stock, it takes a car, returns a Boolean indicating whether or not the car is in stock. The piece only acts that type car and what you have are these strings. Again, have to remember that we wrote this complex type system just to make it impossible to represent something that is invalid. You can think about it in this way. You can think about the compiler like a child who is trying to fit puzzle pieces together. We've told it that there are rules which let it fit together Maruti 800 and Blue Blaze as a valid car. Or a Maruti Zen in Fusion Think or a Hindustan Motors Ambassador in Jet Black. But if you just randomly take three pieces and ask the compiler to fit them together, that is never going to happen. That is actually a mathematical impossibility. You simply cannot do it. What do we do when you get data like this from the outside? Let's not answer this question right now. Let's do a short recap of what we've done so far. So we've written a type with the explicit purpose of making illegal states unrepresentable. And we did this by using two reasonable language features. We used variants to represent the possibilities for our values and we are relying on the compiler to ensure that those requirements are satisfied. Now, because we did this, we can't just naively assume that data that comes from outside of our code is going to fit into our types. We really need, what we really need is some way to pass the incoming data. Make sure that only valid things are processed as our types and that invalid things are handled properly. And I can call this another pattern. I'm gonna say pass all external data and then force boundaries. I'm not gonna go into much detail on how this particular pattern is implemented. Simply gonna say that we can use pattern matching which we briefly saw in one of the examples and that we can write parser functions that use pattern matching to make sure that data coming from outside is passed correctly and that only valid things become the type of car everything else is handled as it should be. But these are just two patterns. There are more patterns. And this is not even a complete list. This is just a few things that I am aware of. All of these patterns are enabled by features that are present in functional programming languages like ReasonML. Now, when someone, when a developer talks about learning a language, a functional programming language, they don't really mean picking up the languages syntax, learning the language syntax, or even picking up how to use the languages features. What they really mean is learning those patterns. So if you can think of a languages features as the tools that you use to build your application, to do your work, then you can think of patterns as techniques that you learn to do your work properly, to do your work better. I believe that learning patterns makes us better developers. It improves our craft and it improves the quality of the applications that we create. I also believe that ReasonML is a kinder language than JavaScript. It is a strict language to be sure. It doesn't really let us make mistakes. But it does provide really great advice for when you do make mistakes because we will make mistakes. We are after all human. In fact, that warning on the top, on the right side, that large paragraph is what finally taught me how to properly use optional parameters in ReasonML functions. Once again, what you want to be focused on, if and when you choose to learn a functional programming language are the patterns that I just mentioned, not the features. And I have personally discovered that ReasonML is a kind and forgiving companion in that journey. So I hope you guys try ReasonML out for the reasons that I mentioned. And if you ever have any trouble, I'd like to point out that the community is extremely welcoming. There are some really great people in it. You can reach out to the community at ReasonML.chat, which is a forum. If you need immediate help for whatever reason, people are also available on discourse at discourse.gg. ReasonML. Or if you want to reach out to me, I'm on Twitter or on email. Oh, and the password manager for teams that I mentioned at the beginning, it's completely open source. You can find that at morocco.com. And that's there. If you want to take a look at a slice, a very large slice of completely working ReasonML code. So it's a Reason React application with a Ruby on Rails backend that uses GraphQL to connect the two. So that's it from me. Bye-bye. Any questions, please? Hi. So when you were building your application, did you stumble upon things like leaf and nodes in Reason? Because a couple of months ago- Do you speak a bit louder? Am I fine? Yeah. So when you were building your application, did you stumble upon things like leaves and nodes in Reason? Because a couple of months ago, when I checked it out, I looked at the documentation into one and it was as simple as Angular 1's documentation. I am fine. I'm sorry. I'm really sorry, but I'm finding it very difficult to understand. Have you- Did you stumble upon things like leaves and nodes in Reason? Leaves and nodes. Yeah. No, I can't say so. Okay. I'll be perfectly honest. Okay. Because I just had a couple of doubts with that. I couldn't understand that. Okay. So I'd like to point out one thing. If it's a functional programming concept that you would like to learn, Ritesh has a talk next. He has been working on functional programming languages for much longer than I have. He would be an excellent person to ask these specific questions about functional programming concepts. Because he has worked on Haskell and now is working with Elm. So he has quite a bit of experience. Okay. Okay. Hi. Yeah. So like for what kind of applications is like Reason suited for? Like if I have an application, I want to decide between using Reason and JS. So like this is obvious factor key. If I want to enforce some kind of data, structure on the data, then I should use Reason. But what other factors should drive my decision in choosing Reason or not? So for JavaScript developers, it's actually a very easy choice because Reason, you are not going to use Reason in production. You're actually going to use JavaScript. Reason compiles to JavaScript, which means that if you have Reason code base, Reason code inside your code base, what the most common use case would be to have the compiler create JavaScript files and keep that alongside the Reason code. So you have no change in your build process, absolutely no change. So that question is a bit invalid. You can use Reason wherever you are using JavaScript right now. It, one of the design decisions, and I believe one of the reason it is created this way is to increase the ease with which you can adopt Reason. Reason is JavaScript for all practical purposes. Of course, because Reason also compiles to OCaml in the middle, you can also choose to compile to native, but that is a different story and that has a different purpose. Hello. Hey, yeah, the last question maybe. You said that you started working the FJS and then you moved to Reason ML. So what problem do you face working the FJS? Then you chosen Reason ML on top of the FJS, I mean. So it was a complexity that was introduced through a mistake that I made. So as I mentioned, I didn't write tests. So once the code base got to a point, it became large, it became complicated. Adding things, making changes was, I wasn't sure if I made a certain change whether a thing would break. The thing about Staticly-type programming languages is that you have the option of having the compiler make these checks for you. So I'm not saying, do not think that I'm saying that you don't need tests, you still do, but types can do a lot of the work that you would generally give to tests. You're shifting the responsibility to the type system. Still use tests, but with Reason ML in place. So I'll illustrate this with an example. So at one point of time, after during the point of time when I switched from React to Reason React on Turku, the personal manager, I worked on a single commit over a period of two days during which I changed the basic structure of the root state. And because I changed the basic structure, I had to go through the entire code base and make massive amounts of changes in code. And during that point of time, because of his making changes, the compiler was always complaining that something was broken. So the process I followed was, look at what is broken, fix that. Look at what is broken, fix that. And at the end, when it compiled after two days, the entire application worked. There were no mistakes. I have never experienced anything like that while using dynamic languages where you make sweeping changes across your code base and when it compiles, it works. This is an experience that truly needs to be, you need to experience it to believe that it can actually work. You can make massive changes and rely on the type system. You can trust the type system that when it says that these types line up, they do. That is why I switched. That is my primary takeaway. Hi, first of all, great talk. I just have a question that, the function that you mentioned, they, yeah, sorry. So the functions that you mentioned in the slides, I see that they don't have a return types or the arguments were not typed. So why is that? I mean, it's a type language. Once again, reason ML has a type inference mechanism. So when you look at that particular type, can you tell what it is? We can infer, right? So there's something called the type inference mechanism where you don't need to specify a type specifically. You don't need to say that something is a string and it looks like a string. It behaves like a string. It is a string. There's a mechanism called the Hindley-Mendler type system. So that's like a mathematical notation. It's a bit complicated and over the top for this particular talk. But what that system allows the compiler to do is to guess with very good accuracy what the type could be. So it infers a type. Usually it infers a type from how you use it. For example, if you were to have a value coming in from outside and you were to going to treat it like a string, then the compiler infers that it is a string. And then for all future use cases, it treats it as a string and there didn't much to be a string. But what I'm saying is probably incorrect, but that's sort of how it works like. Is that, does that answer your question in some way? Hey, great talk. So here, so what I wanted to know was, if you're, are you using reason ML in your production apps right now? Yes, we are using reason ML as we talk to you. Right. So most likely there will be some parts of the code that still you can't really convert totally to reason ML. Right? So there must be some interrupt going on between the two. So what I want to know is like some, like there are things that I still can't formulate in my head how to do it in reason ML. Right? For example, animation request, animation frame, observables or advancing kind of things, generators. That sort of things. Like, have you ever run into troubles like that and what's your relative percentage to reason ML in your code base right now? The relative percentage is very small right now. So we are actually gradually adopting reason ML. We're not trying to like completely change the code base. So the new things we're building, we're building with reason ML. And reason ML does have extremely good interop with JavaScript. So it's formalized. There is lots of documentation on how to connect your existing JavaScript code to reason ML, how to communicate between the two.  And the interop is very good. It's a bit awkward. The syntax for it is probably the most awkward thing you will encounter about reason ML. Writing interop can be, the first time I looked at it, it didn't look quite pretty, but the rules are very simple. So once you learn it, it's pretty easy on how to write the interop bits. Hi. So this talk was extremely brilliant and thank you for that. So one thing I wanted to ask was, do you see soundness of the language as a big advantage of reasonable over alternatives like TypeScript? And like if in the application, there are a lot of interop scenarios involved where you are having interop with vanilla JavaScript, does soundness still remain a large advantage in these cases? Like if the application is entirely written and reasonable, then I can understand that the soundness of the type system prevents a lot of errors. But if you have a lot of interop scenarios, like is this still an advantage as such? So, correct me if I'm wrong. TypeScript, I haven't used TypeScript all that extensively, but you can still have nil in TypeScript, right? Yes. So like the security talk we had a little bit earlier, it's always best to have a sane default. Nil is not sane. In my 10 years of experience as a web developer, I have had more trouble rising from the damned nil or null for you JavaScript developers than anything else. No metadata is on nils, some nil being passed there or here. Nil is not a thing when you think about it. When you have a sound type system, everything has a guaranteed type. It is always known. So yes, I do think soundness matters. When you eliminate nil from the equation, it's, you can think about it from a security perspective. It is a weakness. I don't think that is any particular value to having nil because everywhere where you use nil, it's actually a standard for something else. So if you were to use something like nil in reason and in elm, you'd have something called the option type where you say something, where a thing is some value or none. So it's again a variant.  So my question is not really get towards reasonable but just around the ecosystems. So let's say I am a package developer. I want to develop a node package. So it doesn't like the community is fragmented towards like typescript, flow, reasonable. So whenever I want to create a new package, I have to write my type definitions for all these three things. And that is a kind of an overhead for us. If I'm a single developer. By writing types, do you mean like writing definitions on the, there are other sites that provide definitions. Is that what you mean? Yeah, so if I'm exporting a library, so I would provide my own type definitions for it. Would you be writing in JavaScript or in one of the type languages? So in typescript, we have .d.ts files which we typically ship with every node package. But then if my consumers are using flow, then I need to write flow types. And I think reasonable must also be having some similar kind of thing to export its library definitions. So isn't it like an overhead to write for all this? Isn't the community fragmented to write to type definitions in all these different languages? A fragmentation in the community is like a huge topic. One that we could have like our long conversations about. But in this respect, again, interop between JavaScript things that's solved for TypeScript and Flow, I think. The interop works quite well. You can have interop between Flow and TypeScript because fundamentally they come down to JS. So it's always JS at the end of the day. So it is possible in the interop is there. The story is there. Similarly, if you're writing reason, again, interop with JS is possible. Flow has interop with JS. TypeScript has interop with JS. So they all have interop with each other through JS. I think that's sort of the answer to your question, but it's not complete. I admit that it's not complete. That's done with time. Thank you guys. Bye.