(Sorry to start this thread up again, but...) > On Fri, May 20, 2016 at 7:44 AM, Ashwin Trikuta Srinath < [email protected]> 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 <[email protected]> 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 < [email protected]> 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 <[email protected]> <[email protected]> > Reply: Jan Kim <[email protected]> <[email protected]> > Date: May 20, 2016 at 12:20:25 PM > To: [email protected] > <[email protected]> > <[email protected]> > 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 <[email protected]> > > Reply:??Shauna Gordon-McKeon <[email protected]> > > Date:??May 20, 2016 at 9:52:37 AM > > To:??Ashwin Trikuta Srinath <[email protected]> > > CC:??Software Carpentry Discussion <[email protected] > > > > 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 < > [email protected]> 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 > > > [email protected] > > > http://lists.software-carpentry.org/listinfo/discuss > > > > > > -- > > ??+- Jan T. Kim -------------------------------------------------------+ > > ??|?? ?? ?? ?? ?? ?? ??email: [email protected]?? ?? ?? ?? ?? ?? ?? ?? > ?? ?? ?? ?? ?? ?? ?? ?? | > > ??|?? ?? ?? ?? ?? ?? ??WWW:?? ??http://www.jtkim.dreamhosters.com/?? ?? > ?? ?? ?? ?? ?? | > > ??*-----=<?? hierarchical systems are for files, not for humans?? > >=-----* > > _______________________________________________ > > 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 > > > -- > +- Jan T. Kim -------------------------------------------------------+ > | email: [email protected] | > | WWW: http://www.jtkim.dreamhosters.com/ | > *-----=< hierarchical systems are for files, not for humans >=-----* > _______________________________________________ > 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
