Re: [Discuss] Testing for data analysis code

[Sam Penrose]

Somewhat in the spirit of Noam's comment, and in my personal experience:

1) General unit testing is much better than no testing for oft-repeated reasons.

2) Data code is different in kind from the code which led to unit-test
culture for three material reasons: data has enormously more state
than function parameters and variables normally do, the variance of
production data tends to exceed the variance of development data, and
finally because the job of data code is to transmit all that enormous
and varying state, the notion of a "unit" doesn't really fit data
processing / analysis pipelines.

3) Acceptance testing is good; monitoring is good; unifying them is
extremely powerful.

On Thu, May 11, 2017 at 7:00 AM, Noam Ross  wrote:
> To me (and mostly from an R perspective), the major difference between unit
> testing in packages and testing in analyses is that for the latter one tests
> objects, not functions.  That is, rather than testing that a function gives
> you a expected output for given inputs,  you are checking that objects (data
> sets, fit models, summaries) have the properties you expect given your
> analysis assumptions.  Most documentation and tutorials on testing I've seen
> focuses on functions.
>
> Object-based testing is for data sets is the approach used in the
> assertr/validate/pointblank packages (for data in R), or TDDA (for data in
> Python). I don't know of solutions tooled specifically to non-data
> components of analyses. These are tough because some of them, like model fit
> tests, can be subjective. I also don't know a great framework for separating
> tests from analysis scripts, as you need access to your objects to run
> tests.
>
> FWIW, for the upcoming rOpenSci unconf we have two potentially related
> projects: testing blocks for R markdown documents
> (https://github.com/ropensci/unconf17/issues/38), and maybe something more
> general for saving and testing objects
> (https://github.com/ropensci/unconf17/issues/5).
>
> On Wed, May 10, 2017 at 12:35 PM Pariksheet Nanda
>  wrote:
>>
>> Hi Naupaka,
>>
>> I can't speak for what would be most successful in a classroom, though.
>> For my graduate research work with R, I follow the guidelines of
>> http://r-pkgs.had.co.nz/ without changing much namely:
>>
>> 1) Create a package with devtools, then create the analysis script in
>> vignettes/ with devtools::use_vignettes("name-of-vignette").  Edit the Rmd
>> file and run code blocks with Ctrl+Enter.
>> 2) Create functions as needed in the R/ directory.
>> 3) Add dependencies directly to DESCRIPTION (one could also use use
>> devtools::use_package())
>> 4) Update NAMESPACE from Roxygen comments in R/ files with
>> devtools::document()
>> 5) Add testthat unit tests for those R functions.
>> 6) Once in a while run devtools::check()
>>
>> The book introduction suggests that this practice is somewhat typical
>> (http://r-pkgs.had.co.nz/intro.html) and am curious about others'
>> experiences.
>>
>> There is some cognitive overhead of working with packages for newer
>> programmers, so you may want to have the workflow and gotchas in a
>> cheatsheet or require some amount of prior R experience for the students to
>> value that particular way of doing things.
>>
>> Pariksheet
>>
>> ___
>> Discuss mailing list
>> Discuss@lists.software-carpentry.org
>> http://lists.software-carpentry.org/listinfo/discuss
>
>
> ___
> Discuss mailing list
> Discuss@lists.software-carpentry.org
> http://lists.software-carpentry.org/listinfo/discuss
___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/listinfo/discuss

Re: [Discuss] pulling along those behind

[Sam Penrose]

I wonder if it is helpful in effect to reverse the polarity of the
identification, to say:

Programmers spend their time getting complex systems to play nicely,
which is a process of repeatedly getting stuck, then making some
progress, then getting stuck again. If you have felt stuck or
bewildered at any point this morning, you were at that very moment
programming. You are a programmer because you have already done what
professional programmers do. Of course, we all try to work efficiently
and make progress. You don't drive a Jeep for the purpose of breaking
down in the back country, but we all recognize that the occasional
breakdown is part of the journey. When you are sitting next to your
Jeep and the big rock that broke its axle, you're not some phony
armchair traveller in your living room. Even if its your first trip,
you are a traveller. You are in the back country, with bugs and mud
and, hopefully, beauty and accomplishment. When the message from the
installer makes no sense at all, you're not a fraud. You are
programming. So get help or make do, but don't feel like an impostor
or a failure. You are a programmer doing your work, and you deserve
respect for that -- especially from yourself.

On Wed, Oct 28, 2015 at 1:24 PM, David Martin (Staff)
 wrote:
> What Karin says.
>
> Even in a less pressured environment there is no hope of someone turning up 
> to a SC workshop and coming out of it a fully functioning and competent 
> person int he areas they have been exposed to. However, what we have done, as 
> instructors, is to sketch the route map and show how the concepts link 
> together. The best students will spend 3x longer than the contact hours going 
> back over it and learning the material thoroughly as they apply it.
>
> ..d
>
> Dr David Martin
> Lecturer in Bioinformatics
> College of Life Sciences
> University of Dundee
>
>
> 
> From: Discuss  on behalf of 
> Karin Lagesen 
> Sent: 28 October 2015 20:11
> To: discuss@lists.software-carpentry.org
> Subject: Re: [Discuss] pulling along those behind
>
> One of the things that I always emphasize before and during the workshop
> is that my aim is not to teach them to be programmers, but to make it
> less scary if and when they do decide to learn things more in depth. My
> main goal is to demystify programming. That way, it becomes less about
> understanding every detail and more about finding out that it is not as
> complicated as it looks. I think that by doing that, even if I do lose
> somebody on the little things, I manage to keep them with me on the
> bigger, more conceptual things, if that makes sense.
>
> Karin
>
>
> On 27/10/15 17:38, Bill Mills wrote:
>> I stretch the skill-level bracket of all my workshops by leaning heavily
>> on tiered challenge problems; I break for problems regularly (every 30
>> minutes or so, giving those really struggling a chance to catch up), and
>> set 'baseline' problems (that everyone is expected to solve) and
>> 'stretch' goals - harder problems that the intermediates can derive
>> value from.
>>
>> On Tue, Oct 27, 2015 at 9:33 AM, Noam Ross > > wrote:
>>
>> One thing that I've found is that students who are behind sometimes
>> give up trying to type along and just read along with the lesson
>> notes.  While it's not the ideal outcome, it may be the best one for
>> some fraction of students, and this makes it easier for those
>> students to reference those notes at some later time.  So it might
>> be worthwhile to point students to each lesson's notes before
>> starting that section.
>>
>> On Tue, Oct 27, 2015 at 12:29 PM C. Titus Brown > > wrote:
>>
>> Hi Amanda et al.,
>>
>> thanks, this is a nice discussion!
>>
>> I try to distinguish between "zero entry" and more advanced
>> workshops
>> as clearly as possible, but of course problems happen in both
>> directions
>> for the advanced workshops - too advanced, and too beginner.
>>
>> One strategy that (I think) Greg suggested a long time ago was
>> to suggest
>> that the too-advanced people help out with the too-beginner
>> people when
>> a TA wasn't available.  Of course this can go wrong as well, but
>> I think
>> when it goes well it's quite nice.
>>
>> cheers,
>> --titus
>>
>> On Tue, Oct 27, 2015 at 03:46:12PM +, Amanda Charbonneau wrote:
>>  > I actually had a similar problem, but with an intro workshop
>> that I had
>>  > already pared down considerably because I knew the learners
>> were skewed
>>  > towards *very* beginners. Even with the simplified material,
>> I had a
>>  > handful of 

Re: [Discuss] Is etherpad down?

[Sam Penrose]

If the domain was "etherpad.mozilla.org" you may be able to find it at

https://old.etherpad-mozilla.org/

On Wed, Oct 21, 2015 at 8:41 AM, Erik Bray  wrote:
> Does anybody know if there is at least a static backup of the etherpad
> contents somewhere?
>
> I have one from a couple weeks ago I'd like to retrieve...
>
>
> Erik
>
> On Mon, Oct 12, 2015 at 10:02 AM, Kaitlin Thaney
>  wrote:
>> Hi all,
>>
>> The etherpad.mozilla instance was shut down due to a security issue (a
>> serious one, from what I'm told), and the public.etherpad instance linked
>> above is it's replacement. It's a version of Etherpad Lite, same as what
>> Wikimedia are using, and much more actively developed / less vulnerable.
>>
>> I know this caused a lot of pain for this community (and for us internally,
>> as we didn't have advance warning either), and that many of you have pads
>> you need to recover. I've been working with our IT group to help various
>> groups recover their private pads (despite being behind Mozilla VPN, that
>> *does not mean* we are able to see what's inside without direct
>> communication with the admin / pad owner).
>>
>> Please feel free to reach out offlist if you're still looking for help
>> recovering old pads. More than happy to help, and again - my personal
>> apologies for any disruption / pain this may have caused.
>>
>>  - KT
>>
>> --
>> Kaitlin Thaney
>> Director, Mozilla Science Lab
>> @kaythaney ; @MozillaScience
>> skype / IRC: kaythaney
>>
>> On Mon, Oct 12, 2015 at 9:24 AM, Peter Cock 
>> wrote:
>>>
>>> See
>>> https://discourse.mozilla-community.org/t/etherpad-transition-to-etherpad-lite/4529
>>>
>>> (Via @swcarpentry on Twitter)
>>>
>>> Peter
>>>
>>>
>>> On Mon, Oct 12, 2015 at 2:20 PM, Daniel Chen  wrote:
>>> > Teaching the workshop at VT, and for some reason the Etherpad site isn't
>>> > loading..
>>> >
>>> > https://swcarpentry.etherpad-mozilla.org/2015-10-12-VirginiaTech
>>> >
>>> >
>>> >
>>> > ___
>>> > Discuss mailing list
>>> > Discuss@lists.software-carpentry.org
>>> >
>>> > http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>>>
>>> ___
>>> Discuss mailing list
>>> Discuss@lists.software-carpentry.org
>>>
>>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>>
>>
>>
>> ___
>> Discuss mailing list
>> Discuss@lists.software-carpentry.org
>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>
> ___
> Discuss mailing list
> Discuss@lists.software-carpentry.org
> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org

___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org

Re: [Discuss] [Shell] Teaching grep and find before rm, mv and cp

[Sam Penrose]

In the course of remembering the real reason I hate find -- when I
mess up it destroys my scrollback -- I created an issue regarding the
preservation of scrollback:

  https://github.com/swcarpentry/shell-novice/issues/182

On Thu, May 28, 2015 at 5:47 PM, Greg Wilson
gvwil...@software-carpentry.org wrote:
 I'm -1:

 - 'rm', 'mv', and 'cp' correspond to operations they're familiar with from
 GUIs

 - the syntax of 'find' is truly awful...

 - ...and 'grep' isn't much better

 Thx,
 G


 On 2015-05-28 8:37 PM, Ivan Gonzalez wrote:

 Hmm, it may be interesting. In my experience, people don't really get the
 benefits of the command line interface with cp, rm et al, so maybe showing
 first something they can't do (easily) using the graphical interface is
 worthy.

 Ivan

 El 28/05/2015, a las 20:22, Raniere Silva rani...@ime.unicamp.br
 escribió:

 Hi all,

 what do you think of teach grep and find before rm, mv and cp?

  From my experience, students really like discovery grep and find
 but sometimes we don't cover it due time constrains.

 Cheers,
 Raniere
 ___
 Discuss mailing list
 Discuss@lists.software-carpentry.org

 http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org


 ___
 Discuss mailing list
 Discuss@lists.software-carpentry.org

 http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org


 --
 Dr. Greg Wilson| gvwil...@software-carpentry.org
 Software Carpentry | http://software-carpentry.org



 ___
 Discuss mailing list
 Discuss@lists.software-carpentry.org
 http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org

___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org

Re: [Discuss] [Shell] Teaching grep and find before rm, mv and cp

[Sam Penrose]

find's interface is truly awful; I fear it would feel hostile. (On
grep I am agnostic.)

On Thu, May 28, 2015 at 5:22 PM, Raniere Silva rani...@ime.unicamp.br wrote:
 Hi all,

 what do you think of teach grep and find before rm, mv and cp?

 From my experience, students really like discovery grep and find
 but sometimes we don't cover it due time constrains.

 Cheers,
 Raniere

 ___
 Discuss mailing list
 Discuss@lists.software-carpentry.org
 http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org

___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org

Re: [Discuss] Tools for managing future project pipeline...

[Sam Penrose]

Possibly unhelpful and definitely a time sink: an extensive discussion of 
daunting project management efforts and tools for helping, with an emphasis on 
the visual:

http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=76

The comments lack dates, but I am pretty sure the first ones are close to a 
decade old. The most recent are probably from the last year.

- Original Message -
 From: Greg Wilson gvwil...@software-carpentry.org
 To: Software Carpentry Discussion discuss@lists.software-carpentry.org
 Sent: Saturday, November 22, 2014 8:06:35 AM
 Subject: Re: [Discuss] Tools for managing future project pipeline...
 
 Dude... I'd be happy if I could just keep track of the conversation,
 never mind probabilities...  But if anyone does know, it's become very
 relevant to Software Carpentry's future as well - pointers would be very
 welcome.
 Thanks,
 Greg
 
 On 2014-11-20 10:43 AM, Hetherington, James wrote:
  Hi all,
 
  So, here in UCL Research IT, we’ve got a growing pipeline of future
  research programming collaborations, both free and paid, both research
  council funded and paid consulting,
  and both already won and waiting for peer review.
 
  Our ability to manage all of this is scaling beyond simple spreadsheets… I
  feel that we ought to be using our data-science-fu to help on the
  management side here...
 
  Does anyone on this list have any advice about tooling that can be used to
  model a pipeline of research grants and consulting projects?
 
  Ideally, with probabilistic modelling of expected and upper and lower
  bound future grant income following assignment of probabilities of success
  to proposals, and similar
  modelling of staff availability, recruitment delays etc…
 
  Ideally either a FOSS solution I can install or a subscription cloud-based
  service. I want to avoid anything with either a very Enterprise IT” or an
  old-style public sector IT feel!
 
  I’m aware that there are quite a lot of people interested in collaborative
  research support and Team Science on this list, and setting up data
  science/research software
  institutes etc, so others here have probably encountered the same problem.
 
  Happy to take this topic by direct mail off-list as it’s skirting the edge
  of on-topic-ness. Greg to decide...
 
 
 --
 Dr. Greg Wilson| gvwil...@software-carpentry.org
 Software Carpentry | http://software-carpentry.org
 
 
 ___
 Discuss mailing list
 Discuss@lists.software-carpentry.org
 http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org

___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org