Re: [discuss] How can we scale up Carpentries training at universities?

[April Wright via discuss]

Hi Lex,

Can you say more on this point?:

>⁃How to keep the quality of instruction, and instructor motivation,
> high, if workshops become organized like regular courses?
>

*If the concern is new instructors not being experienced:* What about
offering a "course" section and an "instructor" section? I'm teaching a
Natural History Museum Studies course, in which undergraduates are paired
with a museum graduate student mentor to do hands-on collections research,
and some Data Carpentry stuff with the collected data. I have a separate
section for the graduate students. The graduate section is taught as a
seminar course, in which we cover skills like keeping undergraduates on
task, navigating the student-mentor relationship, implicit bias, and
working with diverse students. At the point where I get them, they already
have taken a "How to TA course", but it's now clear to me that I need to
cover some of that again. The problem here is that I'm faculty at a
primarily undergrad institution, and my expected number of contact hours is
high. Others types of appointments might not be so flexible.

*If the concern is "Ho hum, I need to teach swc-git again; I'll just wing
it": *The volunteerism about the Carpentries is simultaneously the best and
worst thing about this community. The best because people who do this labor
do it because they love it.  The worst because we inherently select out
people who have commitments that preclude travel or giving up chunks of the
day and just make up their "real" work over nights/weekends. Could
instructor boredom be solved by coming up with a rotation? Rotating
instructors between types of courses is really great, since different
people will approach the material differently. Maybe there could be a
semester where the "expert" teaches the material, then a semester where a
competent practitioner and/or someone in a different discipline teaches it.
At the end of the year, they sit down and make improvements to the
material. Basically, a system where the same person isn't going numb
teaching the same thing over and over, and you're building in a regimen of
iterative improvement via diverse instructors.

Just a couple thoughts.

--a
-
Assistant Professor, Southeastern Louisiana University
Biology Department
403 Biology Building
2400 N. Oak St
Hammond, LA. 70402
512.940.5761
https://paleantology.com/the-wright-lab/



On Wed, Oct 3, 2018 at 11:18 AM Hoyt, Peter 
wrote:

> Hi Lex,
> 
> Let me agree first that this is a difficult issue. The Carpentries lessons
> and the Carpentries organizations are all about open science, open access,
> and community.
> 
> I very recently had a student take a Carpentries workshop, and then wanted
> to be awarded course credit. My personal feelings about that are irrelevant
> because Universities need tuition dollars and so they aren't going to give
> away credits for free. Our University also wants to create Carpentries
> lessons where college credit hours can be earned (and, by extension,
> tuition dollars pulled in).
> 
> My opinion on mitigating the downsides is to only offer lessons fully or
> mostly online (flipped or otherwise). This is enabling for learners who
> might otherwise not be able to get to campus. It also costs less per credit
> hour. AND, our Carpentries group will continue to offer the workshops on
> campus for free.
> 
> In this structure, if students just want the knowledge they can get it for
> free. If they need the credits they can get them for a reduced cost. If
> they desperately want to learn the material but can't come to a campus
> workshop this is the best alternative. As a bonus, the answers to almost
> all the challenges are online (which seems motivating to students when
> taking courses).
> 
> The Carpentries community atmosphere combined with freedom to adjust
> lessons based on learner feedback (and using pre-course polling) are the
> best tools we have to keep students engaged. It would be the instructor's
> responsibility to keep the material updated and fresh. Even if offered in a
> traditional classroom, the pedagogy of active instructor participation is
> much better than death by powerpoint, and will help prevent unmotivated
> instructors (hopefully).
> 
> my $0.02,
> Peter Hoyt
> Oklahoma State University
> 
> On 10/03/2018 2:55 AM, Lex Nederbragt wrote:
> 
> Hi community,
> 
> At the University of Oslo (UiO), we have an ongoing process that will result 
> in a Masterplan for IT at the university. I am part of the task force 
> responsible for writing this plan, and have been tasked to contribute to a 
> section on skills training. We have a large Carpentries effort at UiO, 
> regularly teaching one-day workshops with one lesson of the Software 
> Carpentry stack each (including make and testing/continuous integration), 
> very popular two-day R (tidyverse), and occasionally Data or Library 
> Carpentry lessons or full two-day workshops. Many 

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[April Wright via discuss]

We keep an introduction to the notebook in the 00 lesson of the Data
Carpentry python materials (spider also covered, courtesy of Katrin Tirol).
There’s also a more comprehensive intro to notebooks, contributed by Maxim
Belkin, in the extras for that repo. I know other workshops (Like SWC
python) do sometimes use those two resources to get up and running in the
more novice-oriented workshops. Always happy for use and input!

Regardless of what toolset is being used, I agree with Dave that learners
need to be taught how to use it effectively.



On Wed, Aug 29, 2018 at 7:57 AM David Nicholson via discuss <
discuss@lists.carpentries.org> wrote:

> +1 for what Juan said.
>
> I think most of the cognitive load of notebooks can be addressed by giving
> people a crash course in Jupyter, and by narrating what you do, just like
> SWC suggests that instructors narrate what they do at the command line or
> in a REPL, e.g. "so I'm going to type print parentheses hello close
> parentheses in this cell and then execute it by hitting control enter", etc.
>
> I've seen Jupyter-heavy tutorials for example at SciPy that give these
> sorts of quickie intros to notebooks.
> I can't find an example but here's something similar I've done:
> https://github.com/NickleDave/EWIN-coding-bootcamp/blob/master/Python/bootcamp%20day%201%20%2B%20Python%20preliminaries.ipynb
> Seems like a good opportunity to explain that the most common use cases
> are presenting results/methods, teaching, and scratch coding, **not**
> writing production code / large code bases.
> Maybe that will help prevent people getting the wrong impression (and then
> giving a talk about it)   
>
> David Nicholson, Ph.D.
> nickledave.github.io
> https://github.com/NickleDave
> Prinz lab , Emory
> University, Atlanta, GA, USA
>
> On Wed, Aug 29, 2018 at 8:54 AM, Maxime Boissonneault <
> maxime.boissonnea...@calculquebec.ca> wrote:
>
>> Hi Carol,
>> I don't think this is where the subthread about Conda is heading. Jupyter
>> notbooks is orthogonal to Anaconda. You can definitely have Jupyter without
>> Conda. From a teaching perspective, both Conda and Jupyter notebooks do a
>> fine job. But just as it would be beneficial to warn users about notebook
>> caveats (hidden states and such), it would also be good to do the same for
>> conda caveats (performance).
>>
>> Cheers,
>>
>> Maxime
>>
>>
>>
>>
>>
>> On 2018-08-28 6:29 PM, Carol Willing wrote:
>>
>>> Hi all,
>>>
>>> There's positive discussion that has been started by Joel's talk. While
>>> I liked his talk and there are some good points re: improving support for
>>> software engineering best practices in Jupyter and JupyterLab notebooks,
>>> I'm a bit concerned about the direction that this conversation is going.
>>>
>>> While all are entitled to their personal opinions and the Carpentries
>>> will use notebooks when and if needed, I believe that the Carpentries would
>>> be doing its students a disservice by warning people not to use the
>>> notebooks or conda.
>>>
>>> The notebooks are a popular and effective tool for scientists and data
>>> scientists to have in their toolbox. Project Jupyter won the ACM Software
>>> System Award recently, and the ACM stated "These tools, which include
>>> IPython, the Jupyter Notebook and JupyterHub, have become a de facto
>>> standard for data analysis in research, education, journalism and
>>> industry." https://awards.acm.org/software-system
>>>
>>> While it's great for folks to have different personal perspectives, I
>>> want to make sure that the Carpentries and its lessons do not recommend
>>> that the Jupyter Notebooks, IPython, and JupyterHub should be avoided by
>>> scientists and data scientists.
>>>
>>> Thanks,
>>>
>>> Carol Willing
>>>
>>>
>>> On 28 Aug 2018, at 11:38, Maxime Boissonneault <
 maxime.boissonnea...@calculquebec.ca> wrote:

 These kinds of things are rather hard to track in time, because
 everything is a moving target (conda and other package managers constantly
 get updated, but also version of packages changes), but here is a bit more
 details :

 - The 10x performance difference was with a user code, which I
 unfortunately can't share (nor do I still have a copy of it). It was about
 numpy, which may or may not have changed since MKL can now be shipped with
 Anaconda.

 - FFTW, 2x performance gain : These slides compare between
 Conda-provided (and those provided by other package managers) FFTW, and one
 which was built on an avx2 cluster, the performance gain is 2x (see slides
 28 and 29 :

 https://archive.fosdem.org/2018/schedule/event/installing_software_for_scientists/attachments/slides/2437/export/events/attachments/installing_software_for_scientists/slides/2437/20180204_installing_software_for_scientists.pdf


 - Tensorflow, 7x gain for CPU version, slide 28 of this talk :
 

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[April Wright via discuss]

Hi all-

I agree with what Christina said. Someone upthread asked if the notebook
was meant to compete with MatLab. But with novices, our competition isn't
MatLab - it's Excel. You can open Excel, subset data, and plot it. Most of
the learners I work with have experience doing that. They know those little
moments of wonder and excitement of plotting data for the first time, and
having it tell a cool story. My job is to convince low programming
knowledge/awareness audiences that reproducible computational analyses
aren't here to steal the joy from working with data, but to enable deeper
and more exciting ways to interact with data. Jupyter Notebooks, as
Christina & Adam noted, are great for that. The output looks nice, and
provides immediate visual feedback. The interface is much less abstract,
and is more familiar to learners I work with.

Qualitatively, I definitely notice that the conversations students have in
workshops/class are very different when teaching with the notebook than
without. No matter what I did teaching with a text editor and interpreter,
for novices, switching always seems like too much. The pace at which the
interpreter fills up, copy + paste when it works, copy + paste when you
have typos - all that stuff has always seemed to be a little too much for
someone who is just opening the interpreter for the first time. But when
the notebook is used, the content rather than the content delivery seems to
be where the discussion goes. You have to structure your lessons to promote
discussion, but there's no technology that can remove the burden on the
instructor to use it well.

Lastly, I don't know another technology that is doing as much for
accessibility as Jupyter. All my undergraduates work more than 20 hours
weekly. Some are renting computers from the school, and need to renew those
rentals, and might not get the same computer after renewal. If there's a
serious hurricane on the coast, my reservist students can get called up on
deployment. It's hard to express the value of things like JupyterHub and
Binder for in-browser click execution for this population. Maybe there's an
in-browser click execute terminal emulator apart from Jupyter, and I don't
know about it. But it strikes me that if we're serious about meeting
students where they are, then we're serious about this particular
technology.

I was pretty skeptical about notebooks for a long time, but I'm basically
all in now for novice training.

--a



On Tue, Aug 28, 2018 at 10:59 PM Christina Koch via discuss <
discuss@lists.carpentries.org> wrote:

> Hi all,
>
> I was envisioning using a text editor for teaching Python, and keep coming
> back to the idea that I (and my learners) want to be creating a record in a
> file of some kind (script or notebook) but we also want to be able to run
> bits of that file, not the whole thing at once (as it will grow over the
> course of the lesson).  I'd shy away from a simple editor + command line
> combination for an entire lesson, as I'd end up creating a lot of noise as
> I keep re-running the script. For R, developing a script in Rstudio allows
> you to run pieces at a time.  Is Spyder a Python equivalent that would
> allow me to add to my ("notes") script without executing the whole thing as
> I add pieces to it?
>
> I'll second Adam's comment about "prettiness" -- esp. if you're doing
> anything with tables, I think the notebook interface is a lot less jarring,
> especially to novice programmers.
>
> Christina
>
> On Tue, Aug 28, 2018 at 11:28 AM Brian Stucky 
> wrote:
>
>> I agree both with Joel's broader criticisms of notebooks and Kevin's
>> SWC-specific comments.  As with Kevin, I have mostly been keeping this to
>> myself, so I am happy to see this discussion.  Regarding SWC specifically,
>> I have also thought it odd that the early parts of a workshop spend
>> considerable effort trying to convince learners of the value of the CLI as
>> a general tool for patching together scripts, commands, and data flow
>> pipelines, only to seemingly abandon this when it comes time to learn
>> Python.
>>
>> -Brian
>>
>>
>>
>> On 08/28/2018 12:15 AM, Kevin Vilbig via discuss wrote:
>>
>> All,
>>
>> I do not like Jupyter notebooks for teaching, either and I have been
>> thinking this privately for a while. They carry a lot of cognitive load
>> compared to a straightforward CLI REPL, which we actually tout as the best
>> way to start learning in our materials. I have taught a few SWC workshops
>> and mostly stuck to the CLI and git lessons for that reason. I have taught
>> some DC as well, but those are a different beast and are actually flow a
>> lot more tightly compared to the SWC workshops. I suspect Jupyter notebooks
>> as being the culprit. The notebooks seem good for people who learned to
>> code from MATLAB or Mathematica because they superficially resemble those
>> systems, but that is not most people that we teach nor even necessarily
>> most of our teachers.
>>
>> I think it would be best