17 Apr 2015
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.
13 Mar 2015
Guidelines for the package presentations
- The presentations should last about 15 minutes.
- 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.
- 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.
- 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.
- 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).
- 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.
- If you have any questions, about the presentation, please
open an issue on GitHub in
the
package-presentations repository.
- 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
- 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.
- 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”.
20 Feb 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).
13 Feb 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.
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!
30 Jan 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!