15 Matching Annotations
  1. Last 7 days
    1. Foreshadowing. File paths actually work a bit differently in Rmarkdown files than they do in R scripts, but this is something we will talk about much later in the course. If you don’t know what RMarkdown is at the moment, don’t worry about it

      I would remove this, it's quite advance and such piles on the already huge load of new information they are getting here

    2. Importing .xlsx files

      I still feel strongly about this. I think we should stick to simple, conventional importing with .csv and move the .xlsx import/export into it's own dedicated satellite - happy to hear what people think here. I agree the current session is not so long so .xlsx would fit in there but it's more for organisation purpose. especially because we will probably have a satellite regarding satellites, there are a lot to be said so better not duplicate.

    3. Add the code to create an object called path_data_raw

      I would suggest we remove the object here for the variable name. I hear that it makes them practice object, but I feel it's confusing to introduce here("data", "raw") and then suddenly ask them to do here(path_data_raw, "msf_linelist_moissala_2023-09-24.xlsx"). The variable does not add much here and is only truly important with long automated scripts ...

    4. OneDrive doesn’t play well with R as it will attempt to constantly synchronize certain project files in a way that can cause errors or memory problems.

      I think side notes are distracting, I have not even noticed them until now. I would suggest we move this type of information (definitions/deeper concept) to the tooltips

    5. The principles you learned in the Data Management module will apply here as well: we should do our best to ensure that our projects won’t just work today but can also be reused and shared in the future. While doing this is not always easy, there are several best practices that can help us, and one of the most important is to start with a good, organized code base.

      Test of a comment here - what happens if I render ?

    Annotators

    1. OneDrive doesn’t play well with R as it will attempt to constantly synchronize certain project files in a way that can cause errors or memory problems.

      As discussed, I think side notes are distracting and are actually hard to spot. This is basically the type of stuff (explore a concept/definition ) I would put in the tooltip.

    Annotators

    1. Published December 18, 2024

      shall we show the date of last updates rather than publication ?

    2. Resources

      Really good idea to have a Resources sections

    3. If you want to learn about importing several sheets in one go, or several similar files from a folder, go to the satellite on multiple imports.

      I would send them to the full list of satellites rather than one specific one. The point is that they choose based on their specific needs

    4. Importing .xlsx files

      As discussed before, I think .xlsx import/export deserve their own satellites. It's a whole topic in itself, and I feel like we will make this satellites anyways so better to prevent duplication + I would stick to very simple and basics stuff at that stage, let's remember it's probably their first few hours using R. A lot has already been covered until now.

      I would show import with .csv only, and them have a satellite that deals with working with .xlsx in R.

    5. This type of function, providing an unified interface to other specific functions is known as a wrapper

      I am really not a big fan of the side notes, I find them distracing and actually haven't notice them until now. I would suggest we stick to the three "tasks" callouts, and the three "informational" callout to convey information. Actually such a note, whoch is more of a deepening of a topi/concept should become a tooltip

    6. Create a new section in your code called File Paths Add the code to create an object called path_data_raw that contains the path to your raw data folder using the function here(). We can now pass our new variable path_data_raw back into here() in order to create a full path to a specific data file.

      Can we not simplify and use just here::here() without saving to a new variable ?

    7. The first is to use the base R function file.path(), which will accept a set of the relevant parts (folders) in your desired path and combine them into a file path using the syntax of your local operating system, whichever it is: file.path("data", "raw", "exemple_linelist.xlsx") [1] "data/raw/exemple_linelist.xlsx" Note that the path is relative, here to the current working directory While file.path() works fine

      Not sure we need to mention file.path actually - here::here() is now pretty common so I don't think it matters to know the base solution

    8. Foreshadowing. File paths actually work a bit differently in Rmarkdown files than they do in R scripts, but this is something we will talk about much later in the course. If you don’t know what RMarkdown is at the moment, don’t worry about it.

      I would remove this, seems a bit out of scope and let's try not to overload them with informations

    Annotators

    1. interval distribution

      here is a comment

    Annotators