 because we still have some slides to go through actually we still have the majority of slides to go through so I should stop talking in detail and just rush through them but I think it will be fine so first off integration testing so integration testing is defined as an individual software module are combined and tested as a group so hey integration testing is something that you do when you have like software which depends on multiple modules right I have a website this website has for example a database and it has the ability to call out to other websites and head there's different ways of doing integration testing the way people usually do it is big bang so they compile the software and then they see if it works this is not the best way of doing integration testing but it is a form of integration testing right just compile your your website or just put the software of the website somewhere and then just hope that it works you click around a little bit and if everything does what it's supposed to do then you say well it works so integration test complete there's a there's a different approach to that and that is bottom up so you test the smallest components first and then test the combination of them and this would be when you for example have a website which has a database and then you first test if the database is working and then you test if the website connection to the database is working and then you test the other parts there's also the top-down testing and top-down testing is going the other way around so you integrate integrated modules are tested and the branch of the modules are tested step-by-step until the end of the related module and so you view software more or less as a tree and so at the bottom you have the you have the smallest modules which then combine into bigger modules which then combine into the whole software package and so big bang just compile it see if it runs bottom up test the leaves first and then work up the tree while top-down testing is kind of do a big bang compilation test and then look at the individual components and test if they are working unit testing is the is the tests which often are written and are kind of the best way of testing had a goal of the unit test is to isolate each part of the program and show that individuals parts are correct and so that means that a unit test provides a strict written contract that the piece of code must satisfy and so this is usually done on the level of a function or an object or a class and so if I write a function in R then I generally write a a couple of tests to see if the function does what I expected to do right if I give a certain function 10 as an input and the goal of the function is to kind of multiply the input with 50 then of course when I tested I give it 10 and then I expect the output to be 500 if I give it 20 I expect the output to be a thousand and so you just write like 5 or 10 of these tests to make sure that the software that you have written is correct and then of course once I have all of these tests in place then I can muddle inside of my function as much as I want but these tests are there to help me to make sure that when I change code that when I input 10 it will still give 500 as a result so it gives you very it gives you a very high level of confidence that the software that you are looking at and working with is actually correct and this is very important especially in like academic software that at least the individual functions that are provided by a programmer are tested in a way that you get some confidence that when the next version comes out that this version will kind of behave the same way as the old version right if originally you did your correlation and the correlation turned out to be 0.9 right then if you update the version of the software to the newer version and all of a sudden your correlation changes from 0.9 to 0.7 then you know that they didn't have any unit tests in place and of course this doesn't give you very much confidence that the software will be stable across different versions of the software and ideally each test case is independent from the other tests but of course this is this is not something that you can always guarantee but it is it is the best if you can guarantee that so unit testing has a lot of advantages it finds problems early hey you write a thorough set of tests and it forces the programmer to think about which inputs there are which outputs there are which errors can occur and thus more crisply define the unit test behavior had to make sure that if I write a function and then in some cases you would even write the tests first and then you would write the software implementing the test it is it is one of the massive advantage of unit testing and I've run into this multiple multiple times during my career is that it facilitates change if you don't have unit tests then changing a single line of code could change the output of the program completely and that's not something that you generally want because these things only kind of show up when people start using the code and complaining like I calculated it using version 1.1 and I had a very significant effect and I'm using version 1.2 and all my significant effects are gone what's going on and so by having this kind of harness around your code which says no if this is the input then this should be the output and this kind of allows you to change the code change the working of the code very easily one of the other advantages is that it simplifies integration and by testing the parts of a program first and then testing the sum of its part had the integration tests that you are running are becoming much much easier and the test itself so when you write a good number of unit tests then they provide a kind of living documentation of your code that you are writing so the test will kind of tell you well if I have this input I expect this output so the relationship between input and output is more or less caught in the test without having to write a lot of documentation for it of course there are some disadvantages to unit testing and there's the decision problem you cannot evaluate every possible input and every possible output so you have to limit yourself to to what you can test it is not an integration test right so for example if you have a piece of software which functions together with a webcam or scanner or some other input device for which the input can change had there is this this problem that it could work for your webcam but someone else's webcam might not work with your software because of the fact that it speaks a different dialect and there there's this another problem is this combinatorical problem that for every line of code you write you have to write like three or five lines of unit tests and that is of course very expensive and very prohibitive in a real-life situation and there's the problem with realism and you have to come up with realistics and useful tests has so just having a function which multiplies things by 50 of course you could write a whole bunch of unit tests but these things are not really realistic and of course it platform differences are really hard to put into unit test because if you are unit testing your software under Windows and then someone else uses your software on the Linux it might be that the unit test starts failing on their Linux because of differences between the operating system so to kind of prevent that is something called regression tests so regression tests verified that the software previously balanced and tested still performs correctly even after it was changed or interfaced with other software as a regression tests are in essence a kind of unit test had because they specify with this input I want to have this output and this is so as an example during my PhD I wrote multiple QTL mapping software routine and this multiple QTL mapping software routine was originally written by my professor who wrote the code in the 1990s so the first thing that I did when I got his code was run his code on all kinds of different inputs to see what the outputs were and I then wrote tests that said if this is the input this should be the output and only then do you feel confident enough to start changing the code especially when you're dealing with code like C or C++ have where a single change like adding a star somewhere or changing a line of code can have like massive consequences to the whole algorithm but by having regression tests you are certain that the software is fundamentally the same as the old version so that you're not introducing bugs one of the reasons why people are so happy about regression tests is that if you find a bug in your code you fix the bug and then you write a test that exposes the bug so that next time that you're changing the code you are less likely to reintroduce that bug because this bug is being kind of tested for so every time that I compile my code I run the test and the test will tell me well the bug that you had in version 3 did not reoccur so it's kind of putting a harness around the whole software and so unit test is generally based on a single function or a single module or a class while a regression test is based on the performance of the whole software right so if I run this software using this input I should get that output and this this is the correct output and it should never change no matter what I change in the code alright so all of these tests boil down to something which is called test-driven development head so test-driven development is a software development process had the requirements are turned into specific tests then the software is improved to pass the new test so the way that test-driven development works is that you add a test right so you're saying that well when I give this input to the program it should output that I run all the test and then I expect a new test that I added to fail right because I did not put this functionality in the software yet then I write code which implements the desired behavior I run my test again and then I refactor the code as until it passes the test and then I start off from one so I add a new test I run the test I expect the new test to fail I write code implementing this test I run the test again and then if it passes the test I continue back at one and so this is this is called test-driven development and it's very different from things like agile development or other development strategies in in computer science but test-driven development is a very good way of developing software because it it builds up the test suite alongside the code that you are writing alright so documentation is one of these things which is often forgotten in scientific software so I just wanted to kind of highlight it that it's very important to do documentation so documentation is text or illustrations that you get with computer software it explains how to operate it or how to use software and there are many different types of documentation so the first type of documentation that you get is the requirement document so the requirement documentation it states the identified attributes capabilities characteristics or qualities of a system for example a requirement might be my piece of code should provide a p-value showing the significance when I provided with two groups so if there is a significant differences or no and of course this is just a requirement so it's written upfront before any software is written and then next to the requirements you generally have an architecture document or a design document or documentation document which which specifies the relations of the environment and the construction principles to use in the design of the software component for example a requirement document might state that it it should be able to connect to a database but then the architecture document will state that the database being used is progress QL version 7.1 or it is my SQL version 6.3 you have the technical documentation which is the documentation of the code the algorithms the interfaces so every function that you write and normally you write okay so the first input parameter to this function is a vector which contains at most a hundred thousand numbers and the second parameter is then a scaling factor which is applied so it it very fine grained and usually is written into the code or above the code what the code more or less does and what the different parameters of a function do or what an API does and for example the Twitter API has somewhere a technical document saying that well when you call the add friend function in Twitter and then what should happen is that the friend get added to your friends list meaning that you can now send direct messages to and from then you have the end user documentation which is generally the manual that you get with your software so that's something that if you are writing code for other people is more or less the PDF file that people will read through and will tell them how to use your software and then in academic science there's not something like a marketing document but in in if you are programming for a company then there will be also a market marketing documentation and this tells the marketing department how they should sell the product and it contains an analysis of the demand so if you're developing for example a website which sells stuff and then of course there will be a marketing document saying that well how do I sell my my software that sells products and what is the demand for having a software package like that and so different types of documentation and the most important one is generally the technical documentation combined with the requirements and of course if you are planning on outsourcing your entire programming job to India you will just be writing requirements because you will be communicating with someone in India who does your work more or less but you will say well I want to have a function which does this and this and this and then hey you specify in the requirements what it should exactly do and then the guy from India will send you a piece of code which generally has some technical documentation and then you have to write the user manual so that's something that people do so our packages to all of this so an R package that you install have provides you with a type of encapsulation so it defines what your software will do and what your software will not do the R package because of the way that the R package structure will have examples and tests in there and so had the examples will for example be at the bottom of the of the documentation but these examples are also tests for the software and so the documentation that the R package provides is generally technical and end user documentation there are examples in the documentation itself and these examples are used as tests when you run your package or when you when you compile your package so when you make your package from code it will run all of the different tests and it will tell you that or it will run all of the different examples and then if the examples work and then this is kind of a guarantee that the software that you wrote will work all right so last section of this lecture is going to be how do you create an R package so if you are programming in R then you generally want to at a certain point have other people use your software right you can create software for yourself which is really nice but in the end you want to write a publication saying I have this piece of software for bioinformatics and I want to submit it to a journal and then the journal requires you to make your document or your your code available to other people and so here I will create very quickly a package and this package is called your package name right so for example we saw the pre-process core library so had this package is called pre-process core but here we will make a package which is called your package name which is of course not the best name for package but it's a very clear package so if you are ever needing to make an R package then you do have to change your package name by the name of your package and so in my career I've now written like four or five different R packages so one of the R packages that I collaborated on is the RQTL package I've written a CTL package for my PhD so you can install it by just doing install the packages CTL and I've written also a package called Fino2Geno which allows you to estimate genetic makeup based on phenotypic characteristics but here we will create a new package this package is your package name and everywhere where you read this just read okay this is the name of the package that I want to make so first when you do an R package the thing that you have to install is the R compiler because you're going to create a package R itself the interpreter is not enough you need the compiler because you are going to create a piece of software which is more or less a binary bundle which you then give to the repository and the repository will then distribute this binary bundle to all of the other users of your package so hey you have to install the R tools package which you can do from here when you are under Windows and this is just a a package that you download you have to make sure that the version you download of R tools is matching your version so I am currently using R version 4 so that would mean that I need to use the R tools 4.0 it's not on the list because this is an old slide but if I would be using R 3.1 then of course I needed to use R tools 3.1 so when you when you go and click on this link make sure that you first check which R version you have installed and if you want to look at the PDF files so if you want to create the PDF files that the end user will see you also need to install mixtex when you are under Windows if you are under Linux then you have to install a latech compiler but if you're using Linux and then I'm assuming that you know how to install the latech compiler for Linux which is generally just sudo upget latech or something like that but under Windows you need mixtex and this is a big thing mixtex is like two or three gigs big so it's a big download but you install it once and then you can do all kinds of funny stuff with PDF files and the R thing needs it because it builds the end user documentation during your compilation all right so when you have all of done all of that then the first thing that you do to create a R package is create a new directory on your desktop so this directory on your desktop or wherever you want to put it this will hold your entire package and the package that you are making needs to follow the official guidelines of the R structure right so you can click on this link and let me click on the link for you guys can I show you guys this do I have a window yeah I have a window so Firefox there it goes so what I'm going to summarize in the next 30 minutes is this whole document which is around 600 pages if you would download it in PDF so all of this stuff which is written in here I'm just gonna very quickly summarize for you guys into like a 30-minute thing so I'm hoping that you get the gist of it and but there's a lot of guidelines that you have to adhere to but the basic guidelines are relatively simple of course so we created a new directory and of course this directory that we create is called your package name right because that's the name of the package so the name of the folder that I create should adhere to the name of the package that I'm creating all right so then the next step is to execute the command line so if you're under Windows you just press the Windows button on your keyboard and then you type CMD and then you see CMD.exe and this is Windows 7 so you might have a slightly different view but when you type CMD you can get the Windows command prompt and then you just press enter and then it looks more or less like this or at least in my version of Windows it looks like that so you can see here that I'm at the C drive in users then user2 which used to be my username nowadays my username is just denny but so this is what more or less what it looks like all right so because I've created my package on the desktop in the CMD window I have to type cd desktop and then it will go into the desktop directory that I have and then the first thing that we're going to do is check if the package that I just created just this empty folder called your package name if this is a valid R package so to check if your if your package is a valid R package you can do RCMD check your package name so when I execute this command in the command line it will look like this right so I'm here in C users user2 I go into the desktop folder and then I check my package so I do RCMD check your package name right so and then it says I'm using this log directory I'm using R version 3.1 and then the platform is 64-bit windows and I'm using the char set E-cell and then it will say checking for a file your package name description no and then it will quit right so there's an error within your package files and folder structure need to match the official guidelines and the official guidelines are that if you have a package there has to be a file called description without any extension so it's not description.txt no it's just a file called description and it this has to be a text file and so I'm going to create that so I'm going to create a new empty file called description no txt at the end and inside this file I have to add the following so I have to add package double point space your package name version double point and then I have to give a version according to official sem for coding which means that zero point zero point zero minus one is the official version when did I make it well the first time that I did this for 16th of January 2017 the title is just the human readable title right so it's called my package I have to specify who the author of the package is which is me so name of the author and then the email address between the larger smaller than greater than quotes then I have a maintainer in this case the maintainer is me as well and then I have to add the depends so the depends tells the compiler that I need are and I need to have are at least at a version which is higher than or greater than three point zero and then there's the description so the description line is my first our package and I have to add a license and the license you can choose from a list so in this case I choose GPL 3 but you can also use the MIT license or the BSD license or whatever license you want to use to kind of give your code to other people alright so we've now created this file right so we again check the package so again we execute the command our CMD check your package name and it will then say that I found this description file right so it will say okay so that's there and then it will just go through and it will check all of these things and then it will say there was one note right packages without our code can be installed without a namespace file but it is cleaner to add an empty one alright so creating an our package is relatively easy like it's just creating a folder with the name of the package adding this description file and then it is already a perfectly valid our package except for the fact that there's a single note and that says that it's cleaner to create an empty file called namespace well so let's create the namespace file so the namespace file again is the same as the description file it is not allowed to have a dot txt at the end so there's no file extension to this file and the function of this file is to load external dynamic libraries so it's there to link to other DLLs that you might need or under Windows or under Linux this these files are called .so files and under Mac OS X they are called dilips so it the function of this file is to load external libraries for example my package is going to use OpenGL or my package is going to use some other package that I want to give it the other thing that this file contains it is it contains a list of all the functions that you are going to provide to the user right so the thing that we're going to do is we are going to create a new empty file called namespace and inside this file we're going to add the following so we're going to say export my first package function right so now I'm I'm I'm I'm promising the R compiler that within my package there will be one function for the user to call and this function is called my first package function okay so let's create this file and of course I can run RCMD check and then RCMD check will give me an error saying that there is no function called my first package function and that is true so I skipped the step of checking it and then giving you the error but if you would check it then you would get an error and the error would say well you need to provide this function that you just promised to provide to the user and so inside the folder that I had so the your package name folder I create a folder and this folder is called R with a capital letter and so this will hold all the R code file all code in these files should be function so you're not allowed to just have like set working directory in there no every every line of code in these R files should be encapsulated by a function statement yes so in the way that I do it normally is I have one file and this one file contains one function which the user of my package can use so this is the way that it looks so and of course I have to create this R code file so I'm going to create a file called my first package function dot R and this is my first package so I add a header which I always do yes I add a copyright statement when was it written have when when who wrote it and who owns the copyright and then within this funk and within this file I'm just going to create an empty function so it's a my first package function which is a function which does not do anything it doesn't take any parameters and then I save it and then that should be good enough right empty function should work why not so let's R CMD check the package again and now you see that there is a an error right so there is an undocumented code object I hope you can read this by the way so it says all user level objects in a package should have a documentation entry see the chapter writing our documentation files and the writing our extension manual so then you have to pick up this like 600 page manual you have to go through the chapter that they are describing and then you have to figure out what they mean but here we see that R does not allow you to write a function for a user without providing documentation and of course this is very good not all programming languages force you to do that but R really forces you to write documentation you have to write documentation otherwise you cannot distribute your code to other people alright so where does documentation live in an R package it's lives in a folder called man for manuals and so I have to create this folder this folder is called man and this man is written with all small letters again here I normally have one file one documentation of a function so inside the man folder I create something called my first package function rd and the rd file extension stands for our documentation file so the the package now looks like this I have a description I have a namespace file I have a folder which is called our where I have my first package function r and I have a manual folder where it says my first package function rd so this is an empty documentation file so I open up the documentation file and then I just copy paste this in right so this is more or less the template which allows you to document a function so the function has of course a name a function can have different aliases because you can have the same function live under multiple names and then it has a title so it has my first package function minus and then the short description of what the function does it then has a description field which contains the long description and then it has a usage section and the usage section is just how to call the function and in this case it's my first package function and it doesn't have any arguments so no parameters then you have to specify all of the arguments but since there are no arguments I just have a little to-do here saying that add the details and then in details you have a to-do saying add the details of the details so normally the arguments describe all of the arguments that go into the function one by one and then the details tell what happens and the value here so the value section is for the return value so if your function returns something then you can describe what it returns in this field and then it has to have an example section so the example section of course here the example is just executing the function and since the function has no parameters and doesn't return anything it's kind of silly but the example needs to be there and then at the bottom I have to tell that this is a method so a function so I say slash keyword methods all right so now let's see so our CMD check your package and then it will do the same thing again so it will run all the checks and it's okay so that is the minimal our package that you need so the minimal our package contains two folders four files description file namespace file at least one our file containing a function at least one manual file documenting the function that you have and that's about it so that's that's what the 600 page manual describes of course there's a lot of other things that you can do so but this is more or less what you want to do so step one is learn how to build an RF package step two no one knows what it is but step three is profit because now you can sell your software to other people or you can give it away for free if you want of course you still need to install your package right so you have to install it in your version of our and make sure that it does what you want to do so you can do that using the RCMD install command so you say RCMD install your package name and of course this needs to be capitalized the second and but then it will install the package in our and then you can open up our and of course you have to test it right so I open up our then I do library your package name and then I call the function and then I look at the help file and then this is how the help file looks when I open it up in our so that's that's that's how to create our packages so this allows you to well give like hundreds of our functions to users and hey you could ask money for it and this actually got me a lot of publications a lot of people do not know how to create our packages so a lot of people in academia they write our code I'm specific for their little project but then at a certain point they're they're ready and then they know don't know what to do with this code and of course when you have code and then of course the analysis that they do is something that they publish in a paper but then they are looking for someone like me and they give their code to me and I make a package out of it and then we write a paper saying that oh we have this wonderful new algorithm which allows you to do X see our paper that we published and now here is the code that you can do this so I literally have like hundreds of citations for doing nothing else than taking other people's code well not taking it but collaborating with people helping them put their code into an R package and that is a very valid way of finding publications and so things like BMC bioinformatics and they have this really nice format where you can kind of write like a little paper usually three to four pages here where you just describe okay so we have this new new algorithm does X see the see the see this nice paper that we wrote about our analysis and this is the software that belongs to it and so we're publishing the software independently and this as a scientist can can bring you a lot of a lot of citations because if people use your software they also cite your software and so you can write like a very small paper which will rack up if you're lucky hundreds to thousands of citations all right of course when you create a package you also want to generally provide some example data right like just creating a package which has a single function which doesn't do anything that generally doesn't fly because generally you want to have an example in there so that people can run the example and see what happens so generally you would not do a random data matrix in your package but you would provide something like a little piece of data which you've measured on your fish or on your mice or on some other animal or just the analysis or the soft or the data which is underlying the analysis of the nice publication that you wrote first so data lives in a folder called data all small letters and so for example if I want to save data from our then here I'm just making a random matrix so I have a hundred rows ten columns filled with random uniform numbers and that I want to save this and I say save random matrix the file that I want to save it to is in the data folder and it is called random matrix dot our data and here you have to be careful because they are and the D need to be capitalized the other three letters need to be small so this is very strict if you if you don't adhere to the exact guidelines it will throw errors again everything that you provide to the user needs to have a documentation file so if I am providing some data into the data folder like random matrix dot our data I have to provide a random matrix dot our defile right because there has to be documentation of everything that you give to the user so let's create a documentation file so in the manual folder I create random matrix rd the name of the data set is called random matrix the alias is also random matrix the doc type in this case is data because you have to tell our that this page of the PDF document needs to be generated a little bit differently than functions and then you just say well the title the description the usage is always the same it's just data random matrix then the format describes the format for example this is a matrix which has 100 rows 10 columns and it's filled with random data the details it was generated by me on January 1st or something like that and then the references so of course when you have data which it was generated or collected by other people you want to cite their paper and then again you need to have an example the examples are tests so had this example will be run every time that you check your package and it just loads in the data in this case so data random matrix and then the keyword here you have to provide a keyword and the keyword here is data sets so you have two different keyword types and in our documentation file one of them is methods the other one is data sets all right that's how you provide data with your our package of course and the examples in your manual files are run every time that you compile your package but we can have more tests we can add additional tests to our package if we want to make sure that we test every function that we provide to the user and make sure that every function that we have functions in a way that we want and so we can call create a folder called tests and then all of the our files in this folder will be executed automatically during the building of the package and so I create a folder called tests and then for example I add a file called test underscore 0 0 0 1 dot r and this file will contain a test and so for example it could load the random data matrix it could then call the function that you provide to the user and then test if the result after running the function on this data is for example five right that could be one possible and so the test folder can contain additional tests so how do the test files look so again test 0 0 1 dot r copyright statement and here I made a test which fails around 20% of the times and so it's not a good test since it randomly fails but had the thing is is that a test is done like this so you could have if the random number Jedi generate is higher than 0.8 then I just call stop and so this is the way to test so tests have stop functions if a test fails so when a test fails it should call the stop function with a certain error message and of course the error message would be better if it would be unsuccessful test 0 0 0 1 dot r right because that that makes more sense in a way and of course tests should be meaningful so you should test that your function does something on the data that you provide all right so some common mistakes when you are building our packages make sure that r is not running when installing a package because your code might not update so if you have your R window open close your R window when you do our CMD check and when you do our CMD install always check your packages before installing so if you do an RCM the install your package name you should first do an RCM the check your package name and you have to add enough testing so use the documentation for quick and simple test and a test directory for more thorough testing right so if I have a test which runs a little bit longer than it goes into the testing folder if I have a very basic test just making a little plot which is very quick and then I will put that into the documentation and of course the documentation is also there to help the user understand how to use your package all right that's it for today so I told you about files about different types of files about the structure of files naming conventions like file names headers and variables no I didn't tell you about the naming conventions why didn't I tell you I think I was working on the so I might have removed the naming conventions from the from the lecture so I should test the exam make sure that it's not in the exam either and then I told you about code like what is the structure of code what are what is the difference between the unit test the regression test what is test-driven development I talked to you about documentation different types of documentation and I told you how to create your own R package and make lots of money or at least get a couple of publications for helping other people make an R package and of course other people could make their R package themselves but since you have to read through this 600 page document not a lot of people find that attractive and they say well now I'm I'm more of a biologist so hey I do write some code to do my own analysis but I'm not a bioinformatician so I'm not going to publish my code or anything but hey you can get a lot of citations for publishing code and helping other people make a good R package and this will will help you rack up citations in the end alright so that's it for today are there any questions or other things chat has been pretty quiet the last 50 minutes so I think most people are sleeping which is okay but if you have a question ask now or could you upload a PDF with the naming convention slides um yeah I could do you want to have questions about it on the on the exam then as well I think I I think I dropped a couple of slides because I was worried about running out of time because the the R the R package is it's just a very brief snippet of what we do during the R course so during the R course there is how to add C code or for trunk code to your R package and how to optimize and how to call C code from R and these kinds of things Jan gets bonus questions well I think Commander you get a bonus question as well but yeah no I will I will upload the naming convention slides I have to look to the old version about the homework from last week yeah well the homework is part of the lecture so there might be questions about that so I did just be aware you can upload it after the exam interesting we did not cover yeah well there's there's like it's just like I have this whole lecture series which I made and I kind of pick and match and that also based on what you guys want right so if you guys say well we really want to have a lecture about topic X then that is always something that we do it's the same as with the R lecture I generally try to keep two of the of the time slots free so that people can come with their own data we had a really good our lecture being billed around someone who did field experiments so there wasn't anything about field experiments in the R lecture originally but then people wanted to know how do you analyze field experiments when you have different blocks and different like ways of doing that hey if you have different field designs and what is the best design and these so we just added a lecture about that and hey so if you guys have a topic and I think I said that during one of the first lectures as well if you have a topic that you really want to know more about then just let me know and I can just make a lecture about it and then it just goes into the lecture slide folder and next year depending on who attends the lecture or if there's more of people from PQM or if there's more people from fish or IRRM then then we can do that so let me quickly tell the people on the phone that I don't have time all right so they're not no one on the phone yeah yeah so if you have a topic that you think that that's something that I really really want to learn and like I totally missed it during the lecture series then just let me know we still have like until a week before so we probably still have like four or five time slots let me quickly count it on the calendar so next week let me also look at the lectures that we have so this is documents PPTX biofematics so next week we will have literature literature and literature management so how to use the computer to go through literature and do like tests based on literature and stuff and then we have the summary lecture afterwards and I am still hoping to hear back from Misha to that he can give you a short introduction into his topic right I told you last time or the time before that I asked him to make a short kind of overview lecture of what he's doing using raspberry pies and measuring water quality and all of these things but I have to ask him if he's done with that so next next week will be literature management and then the 14th lecture will be the summary which is on the 25th and then the 4th of March is the exam I think right let me see 4th of March I think so yeah yeah so if you want to have a lecture then send it to me this week because then we will have to change the lecture for next week I think the literature management lecture is actually quite short let me quickly look at that oh the literature management actually has 115 slides so that's a really long lecture for some way oh no no it also comes with the with the summary so if I don't count the summary then it is only only only only 62 slides meta barcoding or the field stuff would be cool yeah sure we can discuss a little bit about meta barcoding so I have 62 slides which is one and a half hours I would say so that means that we have 30 minutes left so then I have to scooch a little bit but that's possible and the the overview lecture is is relatively short because I just go through all the lectures and just say well this is important that's important and I'm definitely going to ask about this about the exam but the literature management lecture is yeah it's not the most important one I think so it just talks about like literature and journal impact factors and web of science and Google scholar and put math and all of these things but yeah if you're interested in like the field research then yeah we can talk about field examples and talk about like what is the difference between a Latin square design or an interwoven loop design and how does this relate to these things are to the analysis that that's perfectly fine all right I will at least stop the recording so everyone a little thank you for listening and we will see each other next week