Slashdot Mirror
Collaborative Software For Pair Programming?
DavidMatuszek writes "I will be teaching Java again this Fall. Students work in pairs, but unfortunately (after the first hour) typically not physically together. I would like to find collaborative software that is (1) dead simple to use, because that's not what the course is about, and (2) free. Google Docs would do, but students will be sharing code — plain text — not RTF or HTML or Word files. Is there such software for plain text?"
Please don't make them work in pairs, it's a horrible way to learn programming. I'm assuming you have enough computers, why not?
Sure--learning to work on a program with others is a necessary skill, but you should already know the basics first.
If you're willing and able to release the source code, why not encourage them to use a free account on sourceforge or github?
Don't hold your brighter students back because you want the class to learn together! You have to accommodate all minds, not just the slower ones. I went through this, and quite simply I didn't learn anything but how to pretend to be interested.
If the course is about Java, why do you expect them to do pair programming? (I assume you mean Pair Programming, not just cooperating to solve the tasks. If you mean the latter, it's just a matter of revision control using SVN or whatever, which they should do anyway.)
Anyway, one free tool that comes to mind is screen(1) (aka Gnu Screen) in multiuser mode. That makes two or more users share a bunch of Unix terminals in real time.
IMHO, writing software, in Java or any language, is a creative effort. There are many fields of creative endeavor - artists, musicians, developers, etc. Pair programming is just plain stupid and nuts IMO. Do you ever hear of pair painting (canvas not houses), pair sculpture, pair composing, pair solo singing - no you don't. I had hoped this pair programming nonsense had faded into oblivion - I guess not, but let's try to push it over the cliff and into the abyss of poor ideas.
Cancel the pair programming. All that happens is one student in the pair writes all the code. They might swap back and forth, or more likely one will end up doing it all.
Please don't dumb them down.
I'm sorry--the solutions out there aren't that complicated--it's just that students have very real experience on 'interesting' projects. Don't introduce them to some 'dumbed down' VCS... my last crop of interns from the local university thought CVS was something that came with eclipse and didn't understand they could just use the CLI to work with it (they also don't understand what classpath is, and think it's something you edit in eclipse...why would you use apache ant?)
On top of that--they didn't *want* to learn how to type "cvs update" and ...actually use the different abilities of it. If they couldn't figure it out in eclipse, they couldn't do it even with the manual.
As it is, they were basically helpless when confronted with "make a branch for your ticket, and merge back onto the head when you're done."--even after walking some through it two or three times--they just didn't understand *why* you would use a branch. It never occurred to them there might be multiple versions, releases, or even an "always stable" portion of an application--much less that there could be a tool to help with it. Version control to them was just a sort of abstract filesystem.
And that's just CVS--I wonder what would happen if they encountered GIT or mercurial...
By simplifying the interface, you're not doing anybody any favors. Get them on a real, commonly used tool--I don't care if it's CVS, SVN, or even source safe--just get them using the real thing.
Etherpad for real-time text file collaboration
Yuugu for sharing desktops
Ventrilo for voice communication
Whatever source control solution you wish (TFS, Subversion, Perforce) for non-real-time collaboration with text documents (programs)
Yahoo IM or the chat/IM client of your choice for casual low-bandwith and non-time-critical conversations and sharing of information, links, etc
Email for everything else
- Spryguy
There are three kinds of people in this world: those that can count and those that can't
I think that you're answering a different question than what the submitter asked. Subversion is great for people working on files, but has no collaborative/teamwork aspect to it (with respect to encouraging pair programming, anyway). A program that would allow multiple people to use voice or text chat while editing a document, etc, would be more along the lines of what David is looking for.
Um, he's doesn't appear to be talking about a repository, but rather, software to enable pair-programming, only with the pair not sitting next to each other (or in the same room). Say, some software like SubEthaEdit on MacOS X, where two people can simultaneously edit the same document, along with say, Skype or some other voice/video service where the two people can view/interact with each other.
At least that's what I gathered from reading TFS.
Sleep your way to a whiter smile...date a dentist!
Hmm. It seems they've made great strides since I last played with the thing. I really hope Sobby is easier to set up than it used to be. Last time I tried to get anybody to use this with me, they objected to its difficulty in use and poor user interface. I'll need to look into this again. (I don't remember it having syntax highlighting; I'm really glad it does now.)
Also, watch for Google Wave later this year. (Somebody's bound to write a plugin for syntax highlighting.)
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
I vote for the central server. And for having it in the hands of the teacher.
That way he can far better check whether one student does all the work while the other is doing the homework for another class for both of them. Yes, it's also a way to share the burden, but not the way it's meant to be. The server could be made tamper proof and if something's suspicious he could always check the versions and see what was done by what student. Even if they're smart enough to hand both logins to one person and that person fakes doing work as his partner, the IP addresses would give it away if they cheated.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
-m
My guess is that, no matter how neat of a collaborative program you introduce to your students, they're going to give up on it after a couple of minutes, and decide to just meet in the lab on Thursday, at like 5 or something. A good deal of your students live on campus, and the rest of them are there most of the time anyway. Meeting in person is the quick-and-easy solution.
Emacs in screen -x. Or vim. But they'll freak out with modal editing, I promise. :P
The World Wide Web is dying. Soon, we shall have only the Internet.
. . . to do some research, and choose for themselves whatever suits their needs best.
Chances are the students don't have the necessary permissions to install new software packages on the school's computers, so this would be a non-starter.
Nothing beats screen. One student starts programming within a scren session; the other student joins that screen session (screen -x) and now they're both in the same environment at the same time, and both are in control.