G'day, Thanks Raniere. Adding on to David's, Marianne's, Luke's Naupaka's, Raniere's and Bennet's contributions. Making contribution on SwC generally - I am not an experienced R instructor. I ran a SwC with R (using R for Reproducible Scientific Analysis) workshop last week. The participants were drawn from a variety of fields of research (Psychology, Agricultural Engineering, Linguistics, Economics, Crop Health) roles (academics and altacs) and levels (students, early, mid and late career researchers). The majority had no CLI, Git/GitHub or R experience and a few had some CLI or R experience.
The following approach was taken: 1. Work with a cohesive story line using the Gapminder data set as population data is fairly neutral and concepts accessible regardless of discipline background). The same data set was used for Unix Shell (automating tasks for reproducible research), Git (version control for reproducible research) and R lessons (reproducible analysis). 2. Using the same data set showed how Unix, Git and R can be applied to a research project from start to finish and helps with linkages and associating learned concepts. Using the same data set with different operations and commands avoids the challenge and distraction/confusion of dealing with disparate data (current Unix Shell session uses quite a variety [proteins, creatures, elements, molecules, planets, haiku text) that creates unnecessary complexity for most beginners). 3. Each module was delivered to build up into a capstone and all modules aimed at ultimately delivering a reproducible research project. For example: Intro to Shell >> Navigating files & directories >> Working with files and directories >> Finding things >> Pipes and filters >> Loops >> Shell Scripts lesson capstone). Here is a google doc with the Unix Shell lesson plan http://bit.ly/2cOQJoP happy to get comments, feedback, edits. 4. The Git and R section focused on using Git and R to make the research reproducible. Used Zoob toys and GitX-dev to assist participants with visualising and making concepts of modify-add-commit cycle. Remotes in Github provided link into the R lesson interacting with the Git from RStudio. The R lesson for beginners covered Intro to R&Rstudio>>Using Git from RStudio >> Seeking help >> Data Structures >> Exploring Data Frames >> Writing Data >> Graphics (Capstone). Lessons learnt: 1. Moved the finding things from earlier to the end and kept automating with shell scripts as the lesson capstone. 2.The timings on the lessons are not realistic for participants with little or no experience - double the time is required to go through the content. What worked well: Participants appreciated having a sense of purpose for each thing they were doing could see the value of application on a research project. Less is more, especially for beginners who attend the session because of the tag line - "teaching basic lab skills for research computing". Cheers, Francis -----Original Message----- From: Discuss [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, 3 October 2016 3:00 AM To: [email protected] Subject: Discuss Digest, Vol 39, Issue 2 Send Discuss mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://lists.software-carpentry.org/listinfo/discuss or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Discuss digest..." Today's Topics: 1. Re: Defensive Programming with R (Marianne Corvellec) 2. Prerequisites and outcomes (Bennet Fauber) 3. Re: Defensive Programming with R (Raniere Silva) ---------------------------------------------------------------------- Message: 1 Date: Sat, 1 Oct 2016 14:23:12 -0400 From: Marianne Corvellec <[email protected]> To: DVD PS <[email protected]> Cc: Software Carpentry Discuss list <[email protected]> Subject: Re: [Discuss] Defensive Programming with R Message-ID: <caoq8wi88cbuaczp_jx_uifwb8jzcpae8fbrgsvvkaqbazqr...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Hi David, I'll look into it next weekend, which is a long weekend. :) I'll get back to you then. Cheers, Marianne On Fri, Sep 30, 2016 at 3:54 PM, DVD PS <[email protected]> wrote: > I like the idea of keeping the lessons closer together as asked by > Raniere, and in fact I think software carpentry workshops is aimed to > teach good practices than data and statistically analysis (even though > it may be what drives the people to join the workshop). Last week we > did our first workshop with R - after many doing with Python. I didn't > feel they were there because the data analysis but just because that > was the tool used in their departments/groups. In the feedback there > was nobody asking that missed the statistically analysis. > > I do agree with Luke that the material is already quite long for the > time we have, but if I'm instructing a lesson and see that some bits > are known then I can move forward to the new concepts. And in the case > that we don't get to certain lessons I always point to them to the > material, so they can follow up. If thestthat offers similar tools > for defensive programming, then I would suggest we use them in such > lessons and then is something the students have learnt for whenever they want > to write their unit-tests. > > I would be up for helping with it, not that I'm an expert on R though. > Raniere? Marianne? anyone who wants to lead it? > > David > > > > On 30 September 2016 at 20:32, Marianne Corvellec > <[email protected]> wrote: >> >> Hello, >> >> My approach is quite opposite to Luke's. >> >> I mostly do exploratory "data analysis at an individual >> researcher/team level" precisely. I use knitr/R Markdown dynamic >> reports (think Jupyter notebooks, for all the Pythonistas out there). >> >> At this (exploratory) stage, I don't do testing per se. But I *need* >> to have some sanity checks along the way! So I have a few >> `expect_true()`, `expect_that()`, etc. (from the `testthat` package) >> here and there. It's not testing, it doesn't really cover much, but >> I need to be a little defensive so that I can trust what's being >> computed... >> >> I know that `testthat` is intended for unit testing but, you know, I >> live in the Hadleyverse. :) >> >> Cheers, >> Marianne >> >> On Fri, Sep 30, 2016 at 1:50 PM, Luke Johnston <[email protected]> wrote: >> > I agree with Naupaka that it is a bit advanced. However, the >> > package `testthat` is not for defensive programming per se, but for unit >> > tests. >> > For >> > defensive programming specifically there is the `assertive` and >> > `assertr` packages. However, unlike Python, the facilities for >> > defensive programming are not as well developed in R and are a bit >> > unwieldy. Considering programming is not often done in R for a >> > larger user base but rather for data analysis at a individual >> > researcher/team level, I don't think it is worthwhile to add too >> > much/anything to the defensive programming for R. >> > The >> > lessons are packed enough as it is. >> > >> > In addition to that, most people coming to the R workshops are >> > looking to learn about data and statistical analysis. Defensive >> > programming is something they would likely never use. I've used R >> > for several years and develop a few packages and even I very rarely >> > use these defensive facilities. >> > >> > Just my two cents. >> > >> > Luke >> > >> > >> > On 2016-09-30 12:52 PM, Naupaka Zimmerman wrote: >> > >> > Hi Raniere - >> > >> > I think it isn't a part of the materials because it's a bit >> > advanced for the usual audience level. But that's not to say it >> > wouldn't be nice to have. >> > I >> > imagine such a lesson could intro the base assertion functions like >> > stopifnot() and also Hadley's testthat package. PRs welcome! >> > >> > Best, >> > Naupaka >> > >> > On 30 Sep 2016, at 8:19, Raniere Silva wrote: >> > >> > Hi all, >> > on our Programming with Python, >> > http://swcarpentry.github.io/python-novice-inflammation/08-defensiv >> > e/, we have a "Defensive Programming" section. >> > This section is missing on the R lesson. >> > Any experience R instructor can let me know why? >> > And if you have your "translation" of that lesson in R could you >> > send me a copy of it? >> > Cheers, >> > Raniere >> > _______________________________________________ >> > Discuss mailing list >> > [email protected] >> > >> > http://lists.software-carpentry.org/listinfo/discuss >> > >> > >> > >> > _______________________________________________ >> > Discuss mailing list >> > [email protected] >> > http://lists.software-carpentry.org/listinfo/discuss >> > >> > >> > >> > _______________________________________________ >> > Discuss mailing list >> > [email protected] >> > http://lists.software-carpentry.org/listinfo/discuss >> _______________________________________________ >> Discuss mailing list >> [email protected] >> http://lists.software-carpentry.org/listinfo/discuss > > ------------------------------ Message: 2 Date: Sat, 1 Oct 2016 15:54:28 -0400 From: Bennet Fauber <[email protected]> To: Software Carpentry Discuss list <[email protected]> Subject: [Discuss] Prerequisites and outcomes Message-ID: <cab2ovotpw15w+qgpj59_jxq9dx1dx34ktqu_cmy5-zejrbx...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 The last post I read to this list had something in it again about how 1) the lessons had more than could be covered but 2) that was good because then if the participants seemed to know something, there were additional topics from which to choose. That seems to me to make the outcome of workshops indeterminate. If some workshops cover topics A, B, C, and D, but others cover B, D, E, and F, what does that do to the perception of 'what an SWC workshop' really is? Does that have ramifications when, for example, someone with a budget is evaluating whether to pay for a workshop or not? Does that limit the possibility that SWC might create a set of Intermediate workshops that are explicitly designed to follow on from the basic workshops that are in the current lineup? Should the lessons be trimmed to essential/required material that _all_ SWC branded lessons must cover, in the same way the topics currently are, and then there is a separate library of add-on topics? Should the current collection of topics be kept within the lessons, but some are starred as _required_ material that can't be skipped? Yes, I know that the skill level of participants is widely variable, between workshops and within the same workshop. I wonder whether we are considering where we should start, and try to build workshops on the fly from there, or whether we are aiming to bring everyone in a workshop up to some minimum level of competence? In trying to design an intermediate workshop, or a workshop that is basic for its topic but would want to use skills or techniques from another basic workshop, I would be more comfortable, I think, if I were more certain what might have been covered by the other workshops. It would also make me more comfortable saying to someone: If you took an SWC workshop on <blah>, that should be sufficient training to start this topic. Is this my own idiosyncracy, and others are comfortable with what I'm calling the indeterminacy? -- bennet ------------------------------ Message: 3 Date: Sun, 02 Oct 2016 11:20:02 +0100 From: Raniere Silva <[email protected]> To: DVD PS <[email protected]> Cc: Software Carpentry Discuss list <[email protected]> Subject: Re: [Discuss] Defensive Programming with R Message-ID: <[email protected]> Content-Type: text/plain Hi, Thanks for all the replies so far. I understand that the userbase of Python and R normally do different tasks but the request for defensive programming/unittest with R come from a possible host who as looking to best practices. > I would be up for helping with it, not that I'm an expert on R though. > Raniere? Marianne? anyone who wants to lead it? I can't lead but I'm happy to review any draft. Cheers, Raniere ------------------------------ Subject: Digest Footer _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss ------------------------------ End of Discuss Digest, Vol 39, Issue 2 ************************************** _____________________________________________________________ This email (including any attached files) is confidential and is for the intended recipient(s) only. If you received this email by mistake, please, as a courtesy, tell the sender, then delete this email. The views and opinions are the originator's and do not necessarily reflect those of the University of Southern Queensland. Although all reasonable precautions were taken to ensure that this email contained no viruses at the time it was sent we accept no liability for any losses arising from its receipt. The University of Southern Queensland is a registered provider of education with the Australian Government. (CRICOS Institution Code QLD 00244B / NSW 02225M, TEQSA PRV12081 ) _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
