What New FIRST Programmers should be taught

[StevenB]

Teach them version control. It doesn't matter what tool you use, but getting into the habit of documenting your work is essential.

For most teams, all of the software fits inside one person's head, and they do most of the work. They know what things they've changed, and how their code works. Because of the intensity of build season, they can even keep track of things without putting in any comments. I know, because I've been that person before.

If you're fortunate enough to actually have several people working on the software, keeping track of what you've done and what has changed is essential, even if all of your code is in one place. You don't ever want to be stuck in a situation where "Johnny changed the code, and I don't know what he did, but now it doesn't work...".

[EricH]

Originally Posted by StevenB

Teach them version control. It doesn't matter what tool you use, but getting into the habit of documenting your work is essential.

...

If you're fortunate enough to actually have several people working on the software, keeping track of what you've done and what has changed is essential, even if all of your code is in one place. You don't ever want to be stuck in a situation where "Johnny changed the code, and I don't know what he did, but now it doesn't work...".

And version control programs can also keep a copy of the last version of the code known to work handy, for when the above situation happens 5 minutes before a match. Not that that will ever happen...

[Radical Pi]

Originally Posted by EricH

And version control programs can also keep a copy of the last version of the code known to work handy, for when the above situation happens 5 minutes before a match. Not that that will ever happen...

If only we were able to do that. For some reason our subversion server doesn't play nice with regionals.

[Tanner]

Originally Posted by Radical Pi

If only we were able to do that. For some reason our subversion server doesn't play nice with regionals.

Not to just sound pro-git or anything, but git (and some other VCS) work distributed so they don't need a server. Sure it's a tiny bit more work to do it, but no server.

-Tanner

[byteit101]

Originally Posted by EricH

And version control programs can also keep a copy of the last version of the code known to work handy, for when the above situation happens 5 minutes before a match. Not that that will ever happen...

We were lucky we did VC this year, at Pittsburgh, in the practice matches we were going to enable our ball recognition, but wanted to test it, so we sent it to our dashboard. But it had major bugs, and caused the robot to at some point stop recieving commands, and drive forward full speed (and its a fast one!) for a second or two, then start twitching. Back at the pit, I quickly diffed the previous version to the new version, there were two differences, vision code to zomb (dashboard), and a number tweak so our robot would be bit more managable. since another match was about to start (3 or 4 matches apart), I restored the previous version, downloaded it, and no problems! (later I figured out it was the vision code, somehow it was effecting the motors)

Originally Posted by Tanner

Not to just sound pro-git or anything, but git (and some other VCS) work distributed so they don't need a server. Sure it's a tiny bit more work to do it, but no server.

-Tanner

Subversion doesn't need a dedicated hardware server, just a computer that can have apache or svnserve installed on it. We have a "Code Master" computer that has apache and svn installed, and is the main dev computer, and the others just hook up to it if necessary (switches are nice at competitions, no wireless to worry about).

[demosthenes2k8]

I agree with Andrew Schreiber. A problem that I had this year with training was that I focused too much on the language and not enough on reasoning and problem solving. I would suggest learning about the people you're training, and see how they learn best.

I agree, source control is immensely important. When I joined the team three years ago, "version control" meant "datestamped folders". Last year I was in charge of setting up SVN on googlecode, which wasn't used as much as it should have been. This year, we used it a lot more. (There are quite a few people on software in 166) Unfortunately, we had some issues with the internet, and so over the summer we're converting to Mercurial, which is also better because it supports branching, and unlike Git, is built for Windows by the HG team. It saved us big time at Battlecry, when our robot stopped working right before a match and we had to go back through the revisions to find a stable one. With SVN, it would have been harder because it's not distributed.

[Tanner]

Originally Posted by byteit101

Subversion doesn't need a dedicated hardware server, just a computer that can have apache or svnserve installed on it. We have a "Code Master" computer that has apache and svn installed, and is the main dev computer, and the others just hook up to it if necessary (switches are nice at competitions, no wireless to worry about).

Git does require servers for sharing and what not, but I think Git would be easier in case I don't have a server, which may not be often, but it's just something else that I have to do. It'd be just easier.

-Tanner

[Robototes2412]

guys, if you want to argue about VCS's please make a != thread

would the following game help explain programming theory?
http://www.kongregate.com/games/Plea...s/manufactoria

[SavtaKenneth]

For robotics programming teaching I last year gave the people I was supposed to teach the following game

http://www.kongregate.com/games/Coolio_Niato/light-bot

A pretty good algorithmic game.

Apart from that we started from the basics of good programming, proper code writing, OOP and such. Than we moved on to showing them the libraries and intorducing them to how they work and how to use them.

[Ryan O]

If you're team is planning to use or considering using WPILibJ, there is a coding game called robocode at http://robocode.sourceforge.net/

It actually uses templates (Simple and Iterative robots) very similar to the WPI Libraries, and there robots and standardized and virtual - and if you have 4 students you could have them program bots to compete against each other (the robots are basically mini tanks) without having to build a kit-bot or something for them to play with.

[Andrew Schreiber]

Originally Posted by StevenB

Teach them version control. It doesn't matter what tool you use, but getting into the habit of documenting your work is essential.

For most teams, all of the software fits inside one person's head, and they do most of the work. They know what things they've changed, and how their code works. Because of the intensity of build season, they can even keep track of things without putting in any comments. I know, because I've been that person before.

If you're fortunate enough to actually have several people working on the software, keeping track of what you've done and what has changed is essential, even if all of your code is in one place. You don't ever want to be stuck in a situation where "Johnny changed the code, and I don't know what he did, but now it doesn't work...".

2337 is currently looking into using Dropbox for CAD and Programming version control. So far the hardest part has been setting two instances of Dropbox up on the local server (Ubuntu Server).

[StevenB]

Originally Posted by Andrew Schreiber

2337 is currently looking into using Dropbox for CAD and Programming version control. So far the hardest part has been setting two instances of Dropbox up on the local server (Ubuntu Server).

Maybe I should retract or qualify my statement that "it doesn't matter what tool you use." Dropbox is probably a decent solution for CAD, but in my opinion, it's a poor choice for code. Unless you're using Pack-Rat, it doesn't indefinitely keep track of old versions or allow you to compare them. At best, you'll still end doing things like zipping up a copy of the code each day and giving it a datestamp. Having a solid understanding of the diff and merge tools associated with VCS software has helped me a lot both at school and at work.
A real version control system is somewhat harder to set up and requires more conscious effort to use, but it's a move you won't regret.

Sorry for hijacking the thread...

[Andrew Schreiber]

Originally Posted by StevenB

Maybe I should retract or qualify my statement that "it doesn't matter what tool you use." Dropbox is probably a decent solution for CAD, but in my opinion, it's a poor choice for code. Unless you're using Pack-Rat, it doesn't indefinitely keep track of old versions or allow you to compare them. At best, you'll still end doing things like zipping up a copy of the code each day and giving it a datestamp. Having a solid understanding of the diff and merge tools associated with VCS software has helped me a lot both at school and at work.
A real version control system is somewhat harder to set up and requires more conscious effort to use, but it's a move you won't regret.

Sorry for hijacking the thread...

Thank you for the information. We are currently evaluating it and haven't decided on it yet. I'll probably suggest we go with a Google Code type repo for our code. I used it for FRCFeed and liked it.