[Discuss] Teaching Git Using GitHub Pages

Byron Smith bjsm at umich.edu
Tue May 31 14:39:42 CDT 2016


(Sorry to start this thread up again, but...)

> On Fri, May 20, 2016 at 7:44 AM, Ashwin Trikuta Srinath <
atrikut at g.clemson.edu> wrote:
> I would also be -1 to building a blog at a Software Carpentry workshop.
> There's too much extraneous cognitive load involved.

I think this is an important point, and should be kept in mind when
considering any alternative Git "storyline", including writing
Python/Shell/R scripts.

> On Fri, May 20, 2016 at 3:21 AM, Juan Nunez-Iglesias <jni.soma at gmail.com>
 wrote:
> I agree 100% that motivation is a big problem with the Planets lesson. In
the past, I've "solved"
> this by teaching git *after* Python/R and then using real code for git.
But that has its own
> problems. The motivation is clearer, but the mental burden of using code,
which they've only just
> been introduced to, is much higher. So I think setting up a GH-pages blog
is a very good idea.

I've been using a guacamole recipe as my premise—based on the git lesson
given by Ivan Gonzalez at my second workshop—with *great* success.  You can
see the resulting GitHub repo here <https://github.com/bsmith89/guacamole>
(although that particular commit history will be lost when I teach it
again.)

Why I like it:

   - humorous/light material (perfect for the afternoon of the second day)
   - low cognitive load (I say "add onion to your recipes"; learners add
   onion)
   - simple interdependence between ingredients and instructions files
   - analogy to software development
   - motivation for collaboration

Ivan, do you have a repo for your original lesson?  Besides the resulting
"example" repository, I linked above, I also have this approximate outline
<https://github.com/bsmith89/git-novice-outline> that I wrote up before the
workshop and Socrative questions (SOC-22141549) to match.

-Byron Smith

On Fri, May 20, 2016 at 1:28 PM, Jonah Duckles <
jduckles at software-carpentry.org> wrote:

> Jan,
>
> For the Bash and Python sections we work inside this data directory, once
> we move to the Git lesson, we move back to the home directory and create
> everything from scratch. mkdir planets; cd planets; git init . etc.
>
> Regards,
> ---
> Jonah Duckles
> Software Carpentry, Executive Director
> http://software-carpentry.org
>
> From: Jan Kim <jttkim at googlemail.com> <jttkim at googlemail.com>
> Reply: Jan Kim <jttkim at googlemail.com> <jttkim at googlemail.com>
> Date: May 20, 2016 at 12:20:25 PM
> To: discuss at lists.software-carpentry.org
> <discuss at lists.software-carpentry.org>
> <discuss at lists.software-carpentry.org>
> Subject:  Re: [Discuss] Teaching Git Using GitHub Pages
>
> Dear All,
>
> On Fri, May 20, 2016 at 03:32:03PM +0000, Jonah Duckles wrote:
> > I try to tie together Bash, Python/R and Git by at the very beginning of
> the very first day typing:
> >
> > git clone https://github.com/jduckles/<somedatarepo>
> >
> > This brings down all of the data that will be used for Bash/Python/R
> > lessons. I explain this as a bit like pulling down a zip file and
> > exploding it into a directory all in one command (something many people
> > are familiar with)??and that they don't need to worry too much about Git
> > right now. This ensures that they 1) have a functioning wifi connection,
> > 2) have a working copy of Git and 3) can access the Bash shell.
>
> ... and 4) that they're in the directory that now contains the top level
> "exploded" material, so `cd <somedatarepo>` will work at this stage.
> Where people use GUI based zip tools, the unzipped material may end up
> anywhere, or nowhere at all.
>
> I've previously achieved this by asking people to do something like
>
> wget http://some.where.net/~jtk/coursematerials.tar.gz
> tar -zxvf coursematerials.tgz
> cd coursematerials
>
> which does save much trouble compared to letting everyone doing the
> download and unpacking the way they're used to.
>
> One question / snag that occurs to me is: Do you also use this for
> provisioning any initial git materials, and how do you guard against
> creating a repo-in-repo situation in this case (as discussed / warned
> against at the bottom of
> http://swcarpentry.github.io/git-novice/03-create.html )?
>
> Best regards, Jan
>
>
> > Then we go on our merry way forgetting about it until we get to the Git
> lesson (late in the next day usually). I will then point out to them that
> the Git repo they cloned the day before has been watching what they're up
> to in terms of creating and/or modifying files. ??We run git status on it
> and they see all the things they've created, files from redirection
> exercises, ipynb files, etc. This hits home how you can use a special
> folder called a Git repository to watch what changes you're making. At this
> point I will launch into the planets exercise to show them how they can
> make their own "special folders" which track what they're doing.
> >
> > This in combination with the planets exercise gives them a broader sense
> of what Git is useful for.
> >
> > Recently I tried a collaboration exercise using just the GitHub
> interface and that went very well. I have users Fork a repo, edit a file on
> that fork (A markdown template to fill in with trivia about a country in
> the world)??and submit a PR back to my "upstream". Once we've done this we
> can talk about how we'd do it with an "upstream" (my repo) a "origin"
> (their fork) and "local" copy from the command line with less confusion.
> >
> > Regards,
> > ---
> > Jonah Duckles
> > Software Carpentry, Executive Director
> > http://software-carpentry.org
> >
> > From:??Shauna Gordon-McKeon <shaunagm at gmail.com>
> > Reply:??Shauna Gordon-McKeon <shaunagm at gmail.com>
> > Date:??May 20, 2016 at 9:52:37 AM
> > To:??Ashwin Trikuta Srinath <atrikut at g.clemson.edu>
> > CC:??Software Carpentry Discussion <discuss at lists.software-carpentry.org
> >
> > Subject:?? Re: [Discuss] Teaching Git Using GitHub Pages
> >
> > When I taught newcomers to use git at Open Source Comes to Campus
> workshops, we did something similar to what Bruno Grande does, and had a
> lot of success with it.?? Some of these concerns occurred to us, this is
> how we dealt with them:
> >
> > On Fri, May 20, 2016 at 7:44 AM, Ashwin Trikuta Srinath <
> atrikut at g.clemson.edu> wrote:
> > I would also be -1 to building a blog at a Software Carpentry workshop.
> > There's too much extraneous cognitive load involved.
> >
> > We did not use a Jekyll blog, but rather a very simple HTML template to
> minimize cognitive load.?? We helped students create something more
> complicated later, during the freeform section at the end of the day, if
> they were interested.
> >
> > If you have students create this in a github repository matching their
> name, they don't even have to use a gh-pages branch, so it really is
> minimal additional load.
> >
> > ??
> >
> > Git/GitHub in the context of scientific computing is exciting, because
> it solves real problems
> > like data loss, reproducibility, and maintaining correctness. Maybe some
> learners go on to
> > discover these things by themselves after our Git session, but I do feel
> it's a bit irresponsible
> > of us not to lead them to it.
> >
> >
> >
> > This seems like the strongest objection to me, but perhaps the two
> things could be combined - sharing data via github pages.
> > ??
> >
> > (1) Not everyone is comfortable with writing something at perhaps just a
> > few minutes notice and then putting it into the web-wide public.
> Personally,
> > I'd do it reluctantly, make a very strong mental note to myself to take
> > down the thing after the lesson, and dislike the lesson for having to
> > remember that. And if I managed to forget, I'd not only blame myself, but
> > apportion some blame on the lesson as well.
> >
> >
> >
> > We addressed this by giving students a template to work off of and
> suggesting they customize it with their name but making sure they knew it
> was okay to do something silly and pseudonymous.?? A blog lesson doesn't
> need to include real, serious blog posts.?? Alternatively, if it's a public
> data-sharing site, you can use clearly labelled example data so that
> students don't feel like the exercise is reflecting on them.
> >
> > ??
> > ?? ?? a) blogs are typically personal, so it's difficult to motivate a
> > ?? ?? ?? scenario where contributions from team members result in a
> conflict
> > ?? ?? b) blog posts are typically written with a time stamp and then not
> > ?? ?? ?? revised, so it's difficult to set up a plausible scenario for
> > ?? ?? ?? showing diffs and checking out earlier versions.
> >
> >
> >
> > These are good reasons for a hybrid lesson.?? We induced conflicts by
> having students make changes to the templates and push them back to master,
> but we were trying to demonstrate a typical open source
> fork-clone-change-pull-request work process, which is a bit different from
> what you're trying to do.
> >
> > (Although I will say, as someone who has kept a blog for years, that
> there are plenty of plausible scenarios in which I'd want to update a blog
> post!)
> >
> > Anyway, I'm not necessarily arguing for changing the SWC lesson - it
> sounds like there are some pretty good reasons not to.?? Just wanted to
> share how a blog-style into to git lesson worked for us.
> >
> > - Shauna
> >
> >
> >
> >
> >
> >
> >
> > ??
> >
> > Best regards, Jan
> >
> >
> > > Best,
> > >
> > >?? ?? ?? ??Lex
> >
> > > _______________________________________________
> > > Discuss mailing list
> > > Discuss at lists.software-carpentry.org
> > > http://lists.software-carpentry.org/listinfo/discuss
> >
> >
> > --
> > ??+- Jan T. Kim -------------------------------------------------------+
> > ??|?? ?? ?? ?? ?? ?? ??email: jttkim at gmail.com?? ?? ?? ?? ?? ?? ?? ??
> ?? ?? ?? ?? ?? ?? ?? ?? |
> > ??|?? ?? ?? ?? ?? ?? ??WWW:?? ??http://www.jtkim.dreamhosters.com/?? ??
> ?? ?? ?? ?? ?? |
> > ??*-----=<?? hierarchical systems are for files, not for humans??
> >=-----*
> > _______________________________________________
> > Discuss mailing list
> > Discuss at lists.software-carpentry.org
> > http://lists.software-carpentry.org/listinfo/discuss
> >
> >
> > _______________________________________________
> > Discuss mailing list
> > Discuss at lists.software-carpentry.org
> > http://lists.software-carpentry.org/listinfo/discuss
> >
> > _______________________________________________
> > Discuss mailing list
> > Discuss at lists.software-carpentry.org
> > http://lists.software-carpentry.org/listinfo/discuss
>
> > _______________________________________________
> > Discuss mailing list
> > Discuss at lists.software-carpentry.org
> > http://lists.software-carpentry.org/listinfo/discuss
>
>
> --
> +- Jan T. Kim -------------------------------------------------------+
> | email: jttkim at gmail.com |
> | WWW: http://www.jtkim.dreamhosters.com/ |
> *-----=< hierarchical systems are for files, not for humans >=-----*
> _______________________________________________
> Discuss mailing list
> Discuss at lists.software-carpentry.org
> http://lists.software-carpentry.org/listinfo/discuss
>
>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.software-carpentry.org
> http://lists.software-carpentry.org/listinfo/discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.software-carpentry.org/pipermail/discuss/attachments/20160531/364fbe75/attachment-0001.html>


More information about the Discuss mailing list