Hi all - Following up on one of Pat's points, I think one of the biggest selling points when teaching git (or other version control) to novices is how much easier it makes working on remote machines. I've taught SWC workshops with iPlant/CyVerse several times now, and the capstone exercise is using knitr and rmarkdown to create an analysis of the gapminder dataset. The kicker is that all of the coding happens on Atmosphere (i.e. EC2) instances via RStudio server.
Since (basic) git integration works quite nicely in RStudio with projects, and they have existing projects on GitHub already (created during the shell, R, and git portions of the workshop), all they have to do is `git clone` and now they have their whole project in the cloud. Make some edits, maybe generate a PDF, then commit and push, and now they can shut off the instance if they like. Students (both those that have worked with servers/clusters before and those that haven't) find this workflow very compelling (need a faster computer? one with more memory? you can use one in the cloud for free! here's how to do that easily...), and as Pat mentions it's difficult to do remote work with something like Dropbox. My sense is that the strength of many of the tools SWC teaches comes when analyses are scaled up in complexity or size; for beginners starting from scratch, they may not have a vision of what's possible yet and so don't see the point. So it's pretty critical in my opinion to get them to the stage where they see that value-add during the two-day workshop. For people working locally, and not collaborating, the strengths of git are much more evident once students are comfortable enough coding to know how hard keeping versions of code organized is, and my experience is that it's more challenging to get a class of novice learners to that point in two days than it is to sell the cloud/GitHub benefits. One other thought related to teaching git. I've seen Aron Ahmadia teach the intermediate git material in a lesson format where students start with an existing GitHub remote, fork, clone, and then explore the repo locally before eventually making commits of their own and pushing back up and submitting a small PR. I thought the approach was especially effective for intermediate level learners (albeit many who had never used git before), but I wonder if it also might be effective for novices with a little tweaking. This approach is pretty different from the model used for the current git novice lessons, but perhaps makes it an easier sell because you can talk about the benefits of GitHub and collaboration even before they touch git on the command line. Best, Naupaka > On Mar 1, 2016, at 6:53 AM, Pat Schloss <[email protected]> wrote: > > As I’m in the midst of teaching git, this has been a really important > conversation for me since many of my learners are wondering about how to put > word/excel/etc under version control and why something like dropbox wouldn’t > work. While they think git is interesting, they also appear somewhat > skeptical that it is worth learning. > > I agree with the idea that dropbox is likely a good first step. In light of > this conversation and the overall push for something like dropbox from some > quarters, one of the strengths that I feel formal version control wins with > vs. dropbox is that I can rm -rf my_project and do a pull from github and get > my project back. Not sure how easy that is to pull off in dropbox, but that > it’s baked into git/github for me is a selling point. > > Another thing that I’ve found frustrating with dropbox when collaborators > want a file is that there doesn’t seem to be an *easy* way to put a file up > there from our cluster. So i have to ftp it to my laptop and the put it up on > to dropbox. Collaborating with myself, it’s not so easy to access and > manipulate code from dropbox when I’m on our cluster. I’m sure there’s a hack > out there to make this work, but that it’s baked into GitHub is a strength > for me over dropbox. Also, having multiple files for the same code is one of > those practices we’re trying to avoid. > > Perhaps in thinking about how to motivate the use of things like version > control, we could think about good/better/best and say dropbox is good (or > perhaps better), but formal version control (pick your tool) would be better > and here is why. > > Pat > > >> On Mar 1, 2016, at 8:34 AM, David Martin (Staff) <[email protected]> >> wrote: >> >> 1. What's LD50 [1] for version control, i.e., how long would people have to >> use it (or watch someone else use) for half of them to be convinced it's >> worth adopting? I think LD50 for the Unix shell is less than an hour, >> because that's how long it takes us to introduce pipes and loops, which most >> workshop participants find compelling. At what point do at least half of >> workshop participants find Git compelling enough to actually adopt it? >> >> In my case, about 30 seconds after I tell them that they will be assessed on >> the code in their last git commit prior to the submission deadline (or a >> tagged commit detailed in their report) :) Actually the compelling argument >> is the lose/restore, or the commit/retrieve elsewhere/sync with colleagues. >> >> 2. What should we say to someone like Arjun? It's clear from his post that >> he knows the arguments in favor of version control, and has actually tried >> it. It's also clear that he cares about doing things well - what can we do >> to convince someone like that? >> >> It's always too much trouble until just after you needed it most. >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org >> >> The University of Dundee is a registered Scottish Charity, No: SC015096 >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org > > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
