What are some great ways to program collaboratively?
May 27, 2009 6:46 PM Subscribe
Some friends and I are starting out in the computer science / technology world and we would like to start working on projects together, mostly focusing on web based applications. Bespin looks like one really cool technology developing to aid online collaboration, though it's still very beta. What other technologies work great for managing a project between a small group of people, especially at a distance, preferably on a shoestring? By all means, please include any tools that can smooth the process--not strictly programming platforms.
You absolutely need good version control. All the cool kids are using git, but subversion or one of the many others will work fine too.
posted by chrisamiller at 8:24 PM on May 27, 2009
posted by chrisamiller at 8:24 PM on May 27, 2009
Alfresco is an open source document management system. Trac does project management and bug tracking. JIRA is nice but it's not open source although it incorporates a number of open source components.
posted by XMLicious at 8:27 PM on May 27, 2009
posted by XMLicious at 8:27 PM on May 27, 2009
Beanstalk will give you free, easy-to-set-up SVN hosting.
Google Docs works just fine for most document and spreadsheet sharing.
Dropbox is great for sharing big files.
posted by ignignokt at 9:53 PM on May 27, 2009
Google Docs works just fine for most document and spreadsheet sharing.
Dropbox is great for sharing big files.
posted by ignignokt at 9:53 PM on May 27, 2009
Dont' forget something like skype (with voice and/or video) for free real-time conversations.
posted by philomathoholic at 12:50 AM on May 28, 2009
posted by philomathoholic at 12:50 AM on May 28, 2009
And tightvnc for sharing a desktop across platforms.
I've done a fair amount of remote pair-coding using tightvnc + skype and it's quite pleasant.
posted by gmarceau at 6:51 AM on May 28, 2009
I've done a fair amount of remote pair-coding using tightvnc + skype and it's quite pleasant.
posted by gmarceau at 6:51 AM on May 28, 2009
The company I work for (Pivotal Labs) makes a product called Tracker. It's oriented towards agile product management, but many of our users have adapted it to non-agile workflows. The concept is pretty simple: you
1) create a story that describes a feature, bug, or chore (something that has do be done, but doesn't fix a bug or add a feature -- like setting up a server). Feature and bug stories should typically describe something that can be verified by a (often non-technical) product manager (the "customer").
2) organize these stories by priority into the backlog.
3) either collectively or individually estimate these stories on a point scale (points are a little mysterious outside of the agile world, but essentially, on a 4 point scale, you could say 1 point is something that won't take too long -- maybe one uninterrupted programming session, 2 points is something that will take maybe two sessions, and 4 points is something that's really too big to know how long it will take).
4) someone 'takes' the story by starting it. When they're complete, they finish it. When it's in a place where the "customer" can review it (ie, on the server, compiled into a demo), then it's delivered, and the customer can accept or reject it.
Source control is a must. git is much more flexible for distributed work than svn is, although there's often less fancy tools to work with it. if you're using git, github.com is absolutely awesome, although it is only free for open source projects.
I've drunk the agile/XP kool-aid, so I believe that a good test-suite (preferably a TDD test suite) and continuous integration (an automated build process that runs your tests every time someone checks something into source control -- we largely use CCRB) is absolutely essential to prevent regressions and mystery bugs -- it's even more important when you have a bunch of people working on code simultaneously and remotely.
posted by ragaskar at 7:03 AM on May 28, 2009
1) create a story that describes a feature, bug, or chore (something that has do be done, but doesn't fix a bug or add a feature -- like setting up a server). Feature and bug stories should typically describe something that can be verified by a (often non-technical) product manager (the "customer").
2) organize these stories by priority into the backlog.
3) either collectively or individually estimate these stories on a point scale (points are a little mysterious outside of the agile world, but essentially, on a 4 point scale, you could say 1 point is something that won't take too long -- maybe one uninterrupted programming session, 2 points is something that will take maybe two sessions, and 4 points is something that's really too big to know how long it will take).
4) someone 'takes' the story by starting it. When they're complete, they finish it. When it's in a place where the "customer" can review it (ie, on the server, compiled into a demo), then it's delivered, and the customer can accept or reject it.
Source control is a must. git is much more flexible for distributed work than svn is, although there's often less fancy tools to work with it. if you're using git, github.com is absolutely awesome, although it is only free for open source projects.
I've drunk the agile/XP kool-aid, so I believe that a good test-suite (preferably a TDD test suite) and continuous integration (an automated build process that runs your tests every time someone checks something into source control -- we largely use CCRB) is absolutely essential to prevent regressions and mystery bugs -- it's even more important when you have a bunch of people working on code simultaneously and remotely.
posted by ragaskar at 7:03 AM on May 28, 2009
It's hard to give an answer to this that everyone doesn't already know (or hasn't posted above). You can't live without source control (SVN, Mercurial); wikis are great for documentation; I like Confluence if you can track down a license, JIRA is awesome for ticketing of course.
If you're going to work with any of the supported languages, Google App Engine enforces a lot of good project management practices which otherwise can be frustrating. Versions of your application are tagged when uploaded, you can track who deployed which change, and easily roll back to any version. There's also a complete local testing environment so people don't have to stomp all over each other to test their changes.
posted by doteatop at 7:16 AM on May 28, 2009
If you're going to work with any of the supported languages, Google App Engine enforces a lot of good project management practices which otherwise can be frustrating. Versions of your application are tagged when uploaded, you can track who deployed which change, and easily roll back to any version. There's also a complete local testing environment so people don't have to stomp all over each other to test their changes.
posted by doteatop at 7:16 AM on May 28, 2009
Subethaedit is a great collaborative editor. (Mac only though)
posted by wongcorgi at 10:53 AM on May 28, 2009
posted by wongcorgi at 10:53 AM on May 28, 2009
This thread is closed to new comments.
posted by avex at 7:05 PM on May 27, 2009