The R class R programming for biologists

Final project presentations

Some guidelines for the final project presentations:

  • Time: about 15 min total. Leave time for some questions.
  • Presentation format: you can choose to use whatever presentation you think is best, but I recommend you use RMarkdown.
  • Project format: in addition to the presentation, you need to create a repository that will contain a RMarkdown document that summarizes your project. Given the breadth of topics the exact format/content will vary. However, your repository should contain at least some functional pieces of R code that are documented, if possible a graph generated with R, and some narrative about what your project is about. Once your project is ready (at the latest by class time on April 24th), you will post the link to your GitHub repository if the issue with your name in the logistics repository. I will provide feedback, comments and pull requests soon after the presentations.

If you need help or need feedback before the deadline, let me know.

Package presentations, groups, schedule and guidelines

Guidelines for the package presentations

  1. The presentations should last about 15 minutes.
  2. The support for the presentation is flexible. You can use powerpoint or keynote, or something else, but I strongly suggest you use an R presentation. If you prefer, you can do live coding (like I do during class) without relying on a slideshow.
  3. The type of presentation is also flexible (lecture style vs. live coding), but I would suggest you make it interactive with people following along by having to type the commands you are presenting.
  4. In addition of your presentation (you can use the same file as for your presentation if you choose an R presentation), you need to create an Rmarkdown file that should contain:
    • the general purpose of the package;
    • pieces of code that demonstrate how to use it. In other words, it should look like a vignette for a package. Here is an example for the package lubridate and this is the source code that was used to generate it, you can also click on the “Raw” button to see the exact source code.
  5. This Rmarkdown file should be posted on GitHub in the package-presentations repository. (I recommend you fork the repository, prepare the presentation in your own fork, and create a pull request when you would like me to review it).
  6. Ideally, you should have a draft of your Rmarkdown file on GitHub at least 3 days before you are scheduled to give the presentation. If you do so, I guarantee that I will provide feedback. If you post your notes less than 3 days before I can’t guarantee that I will provide feedback. The easiest way to let me know that your Rmarkdown file is ready for review is to create a pull request.
    • Note that you don’t need to commit the html file to your repository, only the .Rmd file.
  7. If you have any questions, about the presentation, please open an issue on GitHub in the package-presentations repository.
  8. Don’t worry too much about the formatting of your notes at this stage. Focus on content first, and we can work together on fixing potential issues that hinders the rendering of your file later.

Resources

  1. The GitHub workflow for forking a repository, commiting and pushing changes to it, and creating a pull request is listed at the bottom of this page.
  2. The RStudio website lists some good references on how to write RMarkdown, in particular look under the “Authoring” tab after reading through the “Quick tour”.

Week 7 -- February 20th, 2015

The agenda for class this week:

I would like your feedback on the sea cucumber challenge so that I can tailor future challenges better. Please fill out the survey by 10am tomorrow (Friday, February 20th).

Week 6 -- February 13th, 2015

The notes from last week are available here. We’ll cover the section “Statistics across factor levels” this week.

A few people mentioned on their post-it that they are still a little uncomfortable with the use of the square brackets. I added three challenges at the top of last week’s lesson so that you can practice your square bracket skills.

I also posted a bigger challenge nicknamed “the sea cucumber challenge”. Don’t feel demoralized if you find it difficult: it is. No matter your level of expertise, when your code works you feel like you have super powers, when you fiddle around to try to find the answer you feel like you have no idea of what is going on. This second state is the manifestation of the learning process.

The two states of every programmer

If you are stuck, don’t hesitate to open an issue on GitHub and ask for help. Remember to read again seeking help before posting your question. If you think you can help someone stuck, please do!

Before you start on the challenge, if you use a Mac, follow these instructions so you don’t have to enter your user name and password for github everytime you push to your repository.

Remember to comment your code so other people will know what you are doing.

See you Friday!

Week 4 -- January 30th, 2015

Given that the pitches last week went really well, I think it will be more productive if I sit down with each of you for a few minutes to make sure you will be able to get started to work on your own next week.

If you had posted the notes of your pitches on GitHub last week, I provided comments and indicated what you had to bring for tomorrow’s class. If it’s not the case, send me an email before class tomorrow.

For tomorrow, I encourage you to:

  • review the notes from last week
  • bring your datasets (or whatever else I requested) in my GitHub comments

For the lecture, we will continue to explore data.frame and hopefully have enough time to get started writing our own functions.

See you tomorrow!