However, I tried on several arXiv papers, and on all of them when clicking on references I get a "Sorry! We couldn't find the references for this paper. This paper might have been posted recently. Try again later."
Yeah, I added one of the add-ons for a video adapter, so I think my order will be shipped much later. But, I'm excited to play with it, and see what other people can do with it.
I used it to teach my class as well. But I have to be honest, it wasn't obvious at first how to use it - especially how would I manage the course website there (which needed to accommodate different semesters). Eventually, I figured out that I don't really need an HTML website, but using Markdown files would get the job done (and would be better, as it makes it easy for students to commit PR with corrections and suggestions to the course website and material). I really love our setup now, but it took some figuring out the best way to do it. BTW, if anyone is interested here the course website (just as our example):
I am definitely feeling that: I've already had to do some reorganizing as I discover that some of my initial decisions weren't perfect, as to organizing the class repo.
By the way, your article has encouraged me to get the students using issues for eg. homework questions they'd normally email, thanks for that.
Sure. Basically, we go through the first half or so of Stevens' Advanced Programming in the UNIX Environment fairly sequentially. My first take was to group the example code by topic, but I've realized that it might make more sense to group it by book chapter. So that's my current reorganization plan. The thought is, with lots of topics, it will help orient people better if they have an explicit cue for what chapter to review if they are confused.
That's pretty specific to the more or less sequential approach with the book, though. It's a good book, so it can support that kind of thing.
I think it will also help with presenting the supplemental material that is linked with each chapter/section. Again, that might be specific since in the Stevens book, there is always a manpage or Single UNIX Specification reference to give for almost any section.
Yes, you're probably right. I didn't want it to include any HTML (to make it easy for anyone to contribute to course website), but perhaps there is a way to use a simple Markdown for GitHub pages.
Well, I use Octopress (similar to this) for my own blog. But, for the course, where I wanted all the students and other staff members to be involved, I wanted something much more simple. More specifically - nothing that would require building. Perhaps that could be just me and my preference.
This might be a good solution if people want something a bit more fancy as a course website. Thanks for sharing.
In fact, the blog post doesn't include all the details, but some of the educators we interviewed were not from CS. You can see a table describing all the participants in our research paper (the link is provided at the end of the blog post).
Just like you, I believe it is completely possible to use this for non CS classes, and still gain all the benefits. However, like you said, there should be a basic understanding of Git.
One of the hardest things to overcome (even in a programming class) is the why of doing things in Git. Many of the things we do seem arbitrary to students who are just learning. Why do you make multiple commits? Why use branches if you're the only one using it? Why make decent commit messages? I just want to turn in my work!
Many of git's capabilities seem esoteric to students, and for someone just starting indeed they are (students aren't managing a huge FOSS project, just their homework).
Maybe you don't need to do some of those things for assignments? They are all intended as aids in maintaining a long-running software project with many contributors, which is a very different use case than personal homework.
Oh very very true. They start becoming more useful for group projects.
We taught what what needed, but students (in learning to be self resourceful) will often google things, try tutorials, read on stack overflow, etc... and sometimes get themselves turned around. Git is a big piece of software to understand completely I guess, and even if you only show someone a small bit, they are likely to get confused at some point when they are trying to go deeper.
As an interesting and certainly unintentional thing, we discovered at one point that the words git uses to describe commands are often daunting to students. Commit and blame in particular. At one point we found many students weren't making enough commits, or sometimes none and were reluctant to turn in their homework. Through meeting in some 1:1's, we discovered that some of the students felt that if their work wasn't perfect, they didn't want to "commit" to it and that the word held too much power seemingly- they thought maybe there was something deeper to it.
This probably sounds silly, but when teaching people who are new to programming there are all sorts of preconceived notions that can really hold people back, and this was one of them.
That doesn't sound silly at all. In fact what sounds silly is taking techniques designed for large professional software projects and applying them to things that aren't anything of the sort.
It reminds me of the problem with teaching Java as a first language – you must start with `public class Foo` in a file called `Foo.java`, containing a method declared as `public static void main(String[] args)`, which means you must either explain tons of concepts (what "class" means, what "public" means, what "static" means, etc.) long before you can motivate any of them, which makes everything seem complicated and hard, or hand-wave them away as incantations that you'll learn about in due time, which makes programming seem magical and mysterious.
None of which is to say that Java isn't a great language for doing professional work, just that it isn't great to start with. Git seems quite similar to me.
On the other hand, I get that it is valuable to teach techniques that will actually be useful to students in their professional life, even if they are clumsy in a non-professional setting. There's a real tension here.
Apropos of nothing else I wrote: I've always enjoyed seeing people alias `blame` as `praise` or something similarly positive (although `annotate` is the built-in neutral option, which is also pretty good).
You're 100% right across the board. The tension between 'real job skills' and 'things that are good for the sake of learning' are very difficult to balance in a program where an overwhelming majority of students are looking for jobs immediately after the program. This was something I thought about every single day.
Yeah, it makes me feel like a curmudgeon, or like a job-protectionist, but I think it's a shame that so much of the "learn to code" movement is focused on training for professional software jobs, rather than on learning how programming works so that it can be used as a base tool, more akin to writing or arithmetic. Teaching all these professional techniques up front seems to me like training people for statistics or accounting jobs before they've taken middle school math.
That focus comes largely from the students. They want/need a job asap. Unlike a college freshman who has 4+ years to learn, and has set aside that space in their lives, it isn't uncommon for a student leaving these programs to be down to their last 30-60 days of savings after this program and need a job immediately.
Anything you teach them that is simply theoretical, you have to fight them to get them interested in. This isn't to say I didn't do it. I taught students basic C, binary conversion, arduino, basic electronics, game programming, noSQL databases, computer science, etc... in various classes. But there was always a group of students who wanted nothing outside of what they would need on the job, immediately.
However, I tried on several arXiv papers, and on all of them when clicking on references I get a "Sorry! We couldn't find the references for this paper. This paper might have been posted recently. Try again later."
(on chrome 59.0.3071.115)