 Good afternoon, everyone. This is the second series of the our insurance webinar series for 2024 by the consortium delivered to you. By Benedict's hamburger and myself from Switzerland. In in this series, we are going to cover four topics. Last week, we talked about how we can move our workflow from Excel to programming in our Today's topic is about how we can move our scripts into production and then the next two webinars, they will be delivered by my colleague Benedict on the our performance culture. As I said before, my name is George's Baku Lukas and actually working for three three and over the last seven, eight years I discovered programming which I wasn't It wasn't something I used to do and it transformed my my workflow from Excel into our and now for the last five, six years, I will be working with I've been working with Benedict and other colleagues within Swiss three For our group chief actually, Phillip Long, who supports the Atelier program that helps people adopt programming all our day to day. I will briefly pass on to Benedict also to use himself and we will then Continue with the webinar. Yeah, hello everyone. Nice to meet you. I'm happy that you chose to listen to our webinar today. I'm Benedict. I somewhat recently joined George's team and also supporting and I guess spreading the joy of our within our company, maybe in contrast to George's background. I've already started using our in doing my studies and a sort of statistics kind of focused degree or mathematics background and have also start kept on using it to my professional career. So I think what George is going to show today some relevant examples of what people are doing. So I handed back over to him. Thank you. Thank you, Benedict. So we got we covered already a bit of a background within Swiss three. We have around 2000 Community 1000 people working on trying to improve ourselves on communication and programming practices. We now have 500 and regular coders and some of the examples will show you today and some of the subsequent webinars are coming from. The experience that we face by trying to help each other. The running example for the last week's webinar and this webinar is about a case where and actually had to price a product which was the credit balance insurance of a loan or in case of the death or disability. And the insurer who us as insurers, we had to provide some quote for had around 300,000 policies. They provided the loan amount, the loan duration and interest rate for each policy. And the first task are actually how to do is to calculate the profile of the summer suit. And this problem is quite familiar to people in the banking sector, perhaps or companies that issue loans because it's essentially the amortization of the loan. So last year, last, last week, we looked at what we could do in Excel, how that translates into our and today we'll focus more about how we put this, this are work into production. So this is what it looked like last time we had early the runoff of a balance over time by someone paying a specified amount, we put you call it the equivalent monthly installment based on the loan amount determined there and the other percentage percentage rate. And this is the solution of the one case in Excel. And we also talked about things that this kind of appear on the interface is even external. It's not like a complex problem to solve but it's quite convenient to have a solution. So it's a good as a running example. And where we ended up in last week's webinar is that we replicated what this president is using this amortized function essentially picking up this amortize this script that in 39s of quarter of lines of code where we applied the inputs with to perform some intermediate calculations will calculate the amortization the equivalent of premium and we create an amortization function that solves the profile and we apply it for for each of the time periods from from the start the long at the end and then we have the load the balance in the end of the with the loan. So what we're going to do today five things that quite complex things and quite deserving a webinar on their own so we will go through them quite quickly. I hope this is a taste of what you could do to production lies your work in our so first we will talk about building functions. And that way will allow us to reuse the logic that we have created an abstract away the complexity we this script has created for us. Secondly, we will look how we will iterate over the 300,000 records that we may have in a function programming approach we will allow us to avoid writing explicit loops. And then we will look at how we could put these functions into packages to share our work with other programmers. How we can expose those functions into shiny apps to share the insights with non programmers like the interface that you saw a minute ago, or how we can expose those functions into web APIs to offer our work as a service to other applications. So, starting on with the functions. This is almost the same code that you saw at the few slides earlier where we had written a script the difference is that we have wrapped this into three functions, and then we have created this structure with three parts. The first part is the body of the function which is essentially what we, we had we copy pasted it. The second is the, the name of the function so we can call that function using a name and then the third is the, the arguments of the function and now you can actually see here three functions. How we calculate the EMI, how we have a helper for calculate the amortization, and then the amortize function which also calls upon these two functions essentially. So, the experience the user the programmer experience would then be amortize this. And that is the, the concept of abstracting away the, the, the, the complexity. So, imagine, if you put your work into functions. It might make your code easier to understand imagine that you have other things that you're doing with the code. And then the amortize is just one thing. So, you can say, okay, so what amortize is, let's move on. If some of the approach change you can update it only once and then reuse it where you applied. You avoid copy pasting, because we are using the same. You have copy pasting only potentially one item rather than the whole script. And it's easier to reuse on your work with other projects. If you want to learn more about functions, I would recommend the functions chapter of from the alpha data science books that will be booked that I will be referring to in, in a few other places. Now, I will move to the second topic which is the iteration with functional essentially we have created one function. How can we apply this function to 300,000 policies. But first, let's create some sample data. So I've used basic script here to create a sample of 1000 policies that can use for the example. I will skip through that quickly put it there for some reproducibility if someone wants to to run the examples. So the data set that have created looks like this we have a customer ID, a loan amount, a policy term and interest rate. Now the functionals what we may functionals imagine we have a vector of values, and we want to apply a function iteratively of this number of values, the functionals are doing exactly that. So you're creating a mapping between this input to another input where these functions is applied iteratively for each element. It just helps us not to write explicitly a for loop. It does that for us this map function functional is a concept we discovered in the iteration chapter of the alpha data science. It's a simple case of a functional which has only one vector as input, but we could have two vectors as inputs, and in this case the two vectors are two individual vectors you see them all standing on their own. So we can have a slight different version of that which is called parallel map where these two vectors are part of a data frame and I'm showing this because this is the case that we have here. We have a data frame with columns that we want to use the loan amount, the interest rate in the term. So the function will have applied we will apply it on to using this P map. So if I take this random data set we created at the beginning and I just create just one record of it. And to try to see it when I created the the data set by the way I intentionally put first the sample example I'm using to make sure that the numbers. It's always good practice to make sure that you test your, your code as you go through. Now that was a little bit complicated, I will just step into explain a little bit. So we start with the data set, we take only one record, and then we want to create a new column. And this new column that we create will appear here which is called amortized loan. In this column, in this cell we will host a vector of 36 values, and that makes it a list column. Essentially what we're saying is that apply the amortized function on three different columns, first to be the loan amount, the second the policy term, and the third the interest rate. And then the result into this cell and because the result is not just a single value but as you see the 36 values one for each month. It's, it's, it's hosted as a list as an entry in this list column. If you want to know more about list columns and a nesting which is the next step we will do in the next slide. This is a hierarchical data chapter in Afro data science. So now that I have created that what I need to do is unnested. Before I unnested, I tend into a data frame I added the projection month essentially, which is 123 for the month of the that we apply and now I'm unnesting it so instead of having one row of 36 rows. The other rows are those that are repeated because they apply the same but this row has the principal beginning of the period values as we amortize the loan. Now that I have solved this for one loan I need to solve it for all the records. And the way I will show all the records would be to remove the slice. Actually, this has a bug here I had to copy paste a value here that groups is groups their values by by row so we'll update this slide after that, and essentially we run it. And then we have 200,000 records that we, we have created from the 1000 from the 1000 values that we had in the beginning. We can even review it. So this will need to be updated once we update the data set. I will, I will move on to the package section, which is the third section that we, we cover today. And so why do we need to, why is a good idea to package our work. The package is quite familiar concert for people working in our, it's the principal way of sharing our code with others. And even if we are not sharing, having a package created for our work is still good enough reason because the package approach in Switzerland in in our colleges are it makes it easy for us to document our code and test our code and we will spend next few minutes talking a bit more about the documentation and the testing frameworks in our it's even more valuable when we share with others of course. So, but let's see how quick it is to create a package when I first started learning our, I was quite scared to to in the notion I will be creating a package because sounds like a very complicated software engineering task. But it's, it's not really that difficult and most of the workflow has been automated away if you want with a couple of helpful packages which are the deaf tools and they use this. In the next few slides I will be utilizing the work of one of my colleagues did Tom Bowling who presented on this topic internally a few months ago, and I've borrowed the slides from from from them. So, first, you can create a package by using the create package function, and then it comes in with some automated populated metadata which we will step into discuss a little bit more. The more important are the description in the namespace. So, on the description we put on what the name of the package, what is the version who authored it see Tom's name here, and some other metadata which I will capture in the in the bit. One of them is quite important is the license so we will share our work with others under what license are we are we sharing the work when we are sharing internally within organization it might be something quite simple don't share outside. But when you decide to share without side organization this quite big topic that you will need to consider. The, once we update that we see that the file has changed. So the other elements on the description file is if other packages that you use need to be called for for your functions then this is the place to put them and are is a collection of packages. And then people will utilize in the work of others, and it's important to have a robust framework of identify which other dependencies are using your package. And the workflow is quite safe forward by using this use this helper packet with use packet and this is the pair is contains the accumulate function I use previously. The other question that comes next is how do you put your code. Where do you put your code so typically each function will sit on its own script. You can use this use this user and the name of the function that you want to name the name of the script that you want to name and then the script will be created the name is script, and then you can call the base the function there, which this is familiar function that we saw previously. So, the development workflow is that you add we change some code, you load some of the changes using this load also the package is updated and then you perform some checks with using this check function. And that would test whether the package in good shape or any any errors might come up. Now, moving on to the documentation topic. We, when we create a function or some script we're all invested in this we remember everything but we look at the pack six months later we might not even understand what we did. Or when we share with others, others might not have the same idea about how to use our function. So it's quite important that we document it. There are some frameworks that make documentation of the functions easy. One, which one of them is the one of them is their oxygen framework and essentially by applying a shortcut. The script we have created before okay, obdense a header with some prepopulated parameter values which invite us to add descriptions and to add some examples. If I move on on this example here, I have added a brief description about what this function does and some values that I'm expecting and some example. So by typing that I'm putting the function documentation with the function in the same script. And then when I apply the document function, this being recorded in my file system that I have for this project for the package. And then I have people using our would be familiar that if you add the question mark and the name of the function you will get the documentation so I get all this, this page that has the documentation I remember the first time I did that. I felt so happy because I used to see all these help functions published by the packages that I have been using and when I create one it makes you feel we have accomplished something I think. I hope you would experience the same the same feeling I had. Now I will move to testing now. So testing is something that we might be familiar from the Excel, from the Excel world where you need to put some tests to make sure that the values are correct. This becomes a bit more prominent in programming because quite often we try to correct the bug, but we have to update our code. We need to make sure that when we update our future code, nothing breaks because it's quite easy to test everything on day one. And then you're happy with your product but then after six months a year you might inadvertently break something by trying to fix something else. So writing tests of your code, once we go along to put them into packages, it's a good practice. So in our we use this test that framework again that in similar function you would use this function package makes it easy to test. You initiate it by you by having to use test that that creates some appropriate files and which invite you to start copying and to start writing your your tests. So then the code that you created creates this function which is pretty empty and then we will start this script which is pretty empty but then we'll start adding elements there. So the the basic text would be whether you expect something to be equal or not. More complicated text could could expect how what's the length of the of the value, whether it's the numeric type. I'm rushing through a little bit to make sure that we cover all the topics, but please from the Q&A if you have more questions on a specific topic please. Please voice their question. Generally, the checklist that it's good to apply is that do I get the expected output if I get an expected input. And if I receive an unaccepted input, do I get an error handling message that they can actually address. And this last error handling message comes into the defensive programming concept quite often actually is working on our own on a small team. We might not need to put a lot of effort into safeguarding our code like everyone knows that, let's say, ages are positive or some other item like this. But when we ship our code to someone else to use, then we have to apply much more defensive and that's why quite often you hear from programmers saying that, oh, you can only write 10 lines of code every day. Because what the mean is code that can be shipped. So things that don't break because someone puts a negative age on something right. Where's usually when we are in an environment of the home team, we might be a bit more relaxed about how many things we test and essentially what we try to achieve here is a continuum between working by yourself or sending something to thousands of others and where do we apply the testing. So the test exactly now if we write those defensive programming, this one line of code became 10 lines of code and you see most of the code is tests. And we might get the warning and we might have something that someone can follow up. We can expect the input and the output. So here are some examples. And we can also use the cover our cover our packets that we can check how much of our code is checked. It's a code is covered with tests. Now, the final bit we want to move to the shiny is how you share the package you have created. One way is within your organization to use a package manager like the post package manager that we use with industry. And typically you have to build it and then share it and also adhere to any digital governance framework that you have within your organization. If you want to share outside your organization, it becomes much more complicated for for various reasons outside the scope of today, but we can cover it at some other point. And this is something that other industries like the pharmaceutical industries is quite further ahead from the financial services industry. And we hope with this consortium in the future insurance companies and other financial services companies could potentially collaborate more on this topic. But we also have a lot of issues to solve about license about intellectual property and maintenance and liability essentially so at the moment sharing your package with the organization is something that it's it's good thing to do because it has a number of and user application Excel spreadsheets are might be sprawling in some teams. Now, sharing your package with another actually who knows how to go this one thing it's a good thing because they can use it, but most often, or quite often we have to share with people that are not coders or they are not interested in coding or they don't have the shiny framework is something that we can apply here and I will I will skim through some of these slides but what I want to show you is that the equivalent page that creates a basic shiny up it's that long is not that big. And it separated with from a user interface code where essentially we say set of typing the numbers you are clicking at a numeric inputs and outputs, and some layout, a panel layout and sidebar panel layout and main panel, main panel layout. A server mode where essentially you have the functions and a function that creates a graph and you link the server with the with the user interface. And then you might get something like this which is basic, but similar to what you would expect to see in such application. You can publish it again here we use a positive workbench and we publish it on positive connect internally within our organization, but the options to publish it externally as well. Usually either clicking on the button or something more complicated. And as an example here this is not available outside three someone will follow the link and have the application. Now, the final part is. Okay, we share it with someone who is not coding. And we said with someone with coding how can we share it with a co other computer application and this is where the web API is coming. It's a new area for for actuaries that are exploring but generally, it's, it's new area generally within the not very new area as a concept but like the web APIs have proliferated the last 510 years. And it's good opportunity for actuaries to, to utilize them because quite often you have to interact with big it systems, but you have your domain knowledge, you can pick the solution how do you latch it into the big it system. And here you'll see the familiar example of the script. And by using the plumber framework essentially you add a couple of lines of code that takes this function and expose it as a web API. And then when you publish it, you are using a familiar, familiar and popular web API framework, which is called swagger, and then you expose it to another to another application and the person from the other application will pick up the equivalent interface that they need to pick up and then they will be almost like typing in a value to get the result but instead of having a graph to interface this like the application interface that does that. So if you, if you if you here is an example from a script if you run a script and you get the input you receive the output. And then again, you can publish the web API with one click from positive documents if you want but also the professional continuous integration continuous delivery framework like Azure DevOps that you can use to have a more a more automatic way of pushing through some changes. And then again this, this is published. And you can test it here from the terminal with someone using so it's different application to use the web API framework to send the request and then get the result. That was from three perspectives link. So just to summarize, we can put our code into functions. We can avoid explicitly writing loops using functionals. We can package our code to send it to others and improve our robustness and we can share further with web APIs and web apps and that concludes my presentation. We have, we're on the 30 minutes back but we are we can stay back for for Q&A's before I forget. If you think that your organization could benefit by joining their consortium please consider doing so. I'll just invite my colleague Benedict to join for the Q&A and potentially read them out and and decide on the order. Okay, sounds very good. Thank you very much for the presentation George and I guess while other people may be busy writing their questions in the Q&A box. I think we already received one which I found very good. So we had an anonymous question about whether we have the code that is being discussed today available in a repository. And I think very good question. I don't think that we had considered it yet. I guess from my perspective, the slides are available and the recordings available and the slides include all I think the code as far as I'm aware. But I can understand that particular with today's presentation could be a bit burdensome to try to copy paste out the necessary codes and write it yourself. So it's something that we should consider until we inform you in one of the following webinars if and when we can make it possible. I'm not sure whether George had anything to add there. I agree. I think we should try to find a way to share it either via the consortium or some other means, but we'll get back to you. Thank you for the question. Okay, I think we have another another question coming from Ahmed or Ahmed. Thank you for your time. What do you recommend for error or handling errors, practical tips as this is one area I'm working on. I think the main thing I recommend is that you write the test as you're writing your code. What happens quite quickly quite often is someone is writing the code, which is the exciting part. And then they hand over to a most junior colleague or some other person to say, okay, write some test now. And that reminds me a little bit of you, you go to some styling stylist salons to have your salons to have your haircut and then people are preparing then the, the head stylist comes in, does the haircut and then they leave you for someone else and that doesn't work for coding because what if the person comes in for error handling and testing, they have to change the whole concept afterwards or if they are not very good, very experienced, they might not apply the proper checks. I think I think that that's the biggest one, but Benedict, I think you please share. I think a very good question also good demonstration there from the, maybe it is, if it's meant from the very practical our perspective, then I think something like the Arling or Arling, so our language Arling package, and it quite helpful. So that has some advanced error handling features with different levels of warnings, errors and so on and with you, which is very capable of giving users some helpful messages on where the error may lie and I think that's heavily used across the tidyverse so if you're using like the player, you're likely making an error, which I think happens to all of us, and you're already seeing languages from the Arling package or framework, so that may be a good area also to investigate. Thank you, Benedict. I think we had a comment from Jill, which is just very good. So I think that's very nice to hear, but maybe a question that is more on the organizational side from Carmen, they kind of find this lights from the seminar last week. Is that something that we've already up. I don't think we have already shared it, the video is going through some editing and I believe will be available on the, on YouTube but also on the side of the consortium. And also the slides will be there as well. I believe, as soon as this happens, there will be a LinkedIn or some other social network platform message that if you're following our consortium, you will get the notification. I don't believe we have shared it already. I can help answer that. It's actually in the art consortium's website and under the webinar page, if you're school all the way down, you should see the our insurance series if you click on that the recording is already available there and it's also on YouTube in the art consortium's YouTube channel. Okay, excellent. I realize we already there. Thank you. Thank you very much. Okay. Then I think we had another question coming from Miguel. What package do we recommend for data quality assessment. Quite sure whether you want to take it. Yeah. I think it's a quite challenging question and to be honest, I wouldn't be exactly aware about a particular particular package that helps you with that beyond, let's say the broader tidy verse or let's say general tools and techniques like using glimpse or looking at the particular columns of data and what values you get and so on. I can imagine that one broad challenge with data quality is that it's normally quite specific to your use case. So in some cases, like missing values can be completely appropriate because sometimes you know this value is supposed to be missing. And in other cases, it's not and maybe should have been a zero instead because you want to fill all missing values with zero for some downstream process modeling or whatever you do. That's it. So maybe that is the reason why I guess from my practical experience I've most often seen people using existing data manipulation tools or data assessment tools again like the tidy verse like the player and tidy are to go through their data and check for their specific use cases. And if I had, I think from my experience from using after the last few years, most of the time spent on actually data quality in the end. I've always written some scripts, put them into functions create some plots that I can then essentially assemble my own solution using these packages as building blocks. Thank you very much. And of course, we only had another comment from Carmen. Thank you for. Oh, I think there's another one just coming up. So if Federica had a question and comments so I'm interested in the API API usage for sharing and downloading data. Do you have some resources you can suggest besides plumber package to explore this API is in particular related to actual work. And if you have web API he said earlier which is quite new to me. But if you have any experience. Yeah, so broadly I think there are probably two, two sites to it. I think on the one hand, as George kindly highlighted today is the, let's say more deploying or doing the data generation part of the API. So you are the person who is doing the calculation like the amortization schedule or something and deploy it somewhere. And you're probably very well served with on the space there for the moment. I guess the other side is then assuming you know someone else has already deployed this API somewhere and you just want to call it to get some calculation done and get the results. I think there there's the HDR or heater and particular nowadays it's a two packages that are very helpful and they have quite extensive vignettes on how you can use these packages to interact with existing API's. So these, like examples of internally deployed ones or some public other API's that you may want to use. For particular actual API's that is a good question. But I've personally seen this only let's say like particular actual pages that supply information like let's say mortality tables or so. And I think that would then be cases where you can use, again, a package or framework like HDR or heater to to create these API's and get the data you need. Okay, I guess you some idea other than that now I don't quite remember the exact source I'm not sure whether it was advanced are or data science but to look it up one of these, at least one of these books also had very good tips on how you can use API's and your data science for flow or your actual workflow. And I think that was the last question we had for now. Thank you very much. And I think I'll just wanted to to express that I hope that some of you might be more motivated to start coding or if you have already started coding to putting your code into production. I would like to thank Elenia from our consortium and my colleague Benedict for joining me today, and we hope we'll see you next week or the next couple weeks that Benedict will provide the performance webinars to continue with the series. And if you have any feedback, please share with us and or any ideas about future topics for webinars for our insurance. I would like to bring the webinar to a close and so thank you very much for my side. Thank you all. Bye-bye everyone.