Organizing your programming
 

Hi all. I was wondering now that the Stronghold season is over how all of your organize your team's programming. I'm putting together teaching tools for my team for c++ and I want to organize an official document for my team to follow when organizing their programs. My team has attempted GitHub, nobody really liked it on my team. I see the value in it, but it did mess up some things and I don't see it as very reliable when not many know how to use it properly. Do any of you use a different way?

Right now my plan is basically to use Google Drive to store archives of different versions of a programming project so that we can backtrack if necessary and have the programmers of the team fill out forms for the lead programmer to read and approve of changed to the programming project being worked on.

I would love to hear your method though.

Re: Organizing your programming
 

Using version control is the way to go. You don't need to use GitHub specifically, but Git can be used offline or with some other server such as BitBucket. SVN is also an option.

Seriously, version control is what is used in the professional world. Git is one of the most widespread VCSs out there. Our team uses it. It's very convenient to be able to go home and code with the most up to date version. It becomes even simpler to use if you have a UI for it (EGit for Eclipse). It's worth spending a day or two to go over how it works.

Re: Organizing your programming
 

That sounds really annoying and is exactly what something like git is designed to solve for you, good luck with that.

I agree that git is a bit annoying to deal with at first, but once you get over the hump it's really quite delightful. What about the workflow did your team have trouble with (and did you use pull requests? they're really the best thing about github).

Re: Organizing your programming
 

Git is terrible; use git.

The learning curve may be steep, but there is not much that you really need to know to use git effectively. Once you start using git for a bit, it becomes really useful. We started using git to organize all of our programs while I was a student on our and we have since been able to move a manage a lot of different projects using git. Our website is updated using git; our branding files are all managed by git; our robots are all version controlled in git. Git may not be perfect, but it works really well in facilitating collaborative development.

Re: Organizing your programming
 

This is a perfect summary of version control, right here.

The rest are worse than Git by a mile. SVN and other CVS is awful (we tried; it's slow, poor support, no offline commits which will kill you at competitions). We have not tried Mercurial, but that is due to how (relatively) unsupported it is. To paraphrase Linus Torvalds (inventor of Git and Linux), everyone uses Git, even Microsoft. It is worth learning because of the preparation for the professional world that it provides.

Re: Organizing your programming
 

I know this thread is a few days old, but...

NO. PLEASE DO NOT DO THIS.

This could work if there's like two people working on the code, and if your code is super simple. But honestly, if anyone plans to work in the software development world, you're going to need to learn how to use version control. Now is as good a time as any.

I agree with others - git and github are not the easiest thing to wrap your head around. If nobody really gets what's going on, it can be even more frustrating. Trust me, I've been there. What you need to do is find someone who understands this stuff and get them to work with you until you understand it too. Even if this takes a few days or a few weeks, this is absolutely worth the time investment.

There are different ways to use git and github. The easiest is to have one repository on github for your projects, add your students as contributors, and let them each develop code in their own branches. (No forking.) Use a variation on the Git Flow software development model.

Re: Organizing your programming
 

Use git.

https://try.github.io/

We'll be doing some workshops in the fall for NC teams and one of them will be about using git.

Re: Organizing your programming
 

You don't organize programmers.
You object(ive) orient them :)

Re: Organizing your programming
 

100%. It's a total pain both to teach new programmers, and for the programmers themselves. But it must be done.

Requirement: At least one person reachable by your team must be actually comfortable with git. That sounds like a good job for you!

relevant: xkcd.com/1597/

From experience, I can tell you the most helpful thing you can do now is make sure your programmers are programming OUTSIDE of robotics. Team teaching tools are nice when you need to onboard somebody during the 6 weeks, but you're going to end up reteaching the same material to the same people every year when they forget it all over summer.

It doesn't matter what they're programming. Games are a nice standby, python + pygame is well documented for newbies. But teaching basic programming only during robotics time is an endless battle.

Re: Organizing your programming
 

Here's a video that helps explain how git works, to make it easier to understand.


Git For Ages 4 And Up

Re: Organizing your programming
 

FWIW: The speaker says right up front that the target audience is "one step beyond" people who have never used git before.

Re: Organizing your programming
 

Not to mention the added confusion of writing robot code that is event-driven, sort of, by way of the Iterative or Command based patterns.

Our software students wanted to work together on a little video game, and some of them have also worked on our vision code and Android scouting app, and there will probably be other small projects to come. It's good to get used to the idea that different projects can be very different from each other, but have similar underlying fundamentals.

Re: Organizing your programming
 

Free section of 'Mastering Git' book:
http://cdn.oreillystatic.com/oreilly...754_Sample.pdf

BTW:
PacktPub gives away a free e-book a day.
Look for 'Free Learning' on their website.
I have several hundred from them.
You don't get to pick the topics like that, and the quality may vary, but free as in you click the button and they are yours.

Re: Organizing your programming
 

Yes, for people that haven't used version control, it will be a little more complex. But if a team has every done a git commit, then they should be able to follow along. They might not know all the commands, but his explanation, I found, was very easy to understand.

Re: Organizing your programming
 

I personally am not a fan of Git either. We have been using SVN for 8 years and it works great. We originally had a local respository, but last year we decided to store the repository online using SourceForge. This makes it easier for each programmer to access the updates individually.

As the programming mentor, I am the only one who can commit new code. This allows me to review all the code before it is shared. This also allows me to keep track of the progress being made and if someone needs additional help or support... or is going off on a tangent.

At competitions where we have no internet access I make a backup copy on a flash drive each time our lead programmer loads new code onto the robot. This is my role at competitions... just like during build season, I am the source code control system integrator. This backup provides a trail of what has changed between each download if something unexpected is affected. This is very helpful when something suddenly works differently on the robot... it helps the programmers be able to validate with certainty what changed and what did not change in the software. Each backup sub-directory is labeled with what was changed and when, eg. CMP-1b-MoreAutoAngle would be the code from Championship, day 1, version b (or 2nd change of the day), and change was adding more rotation driving to autonomous mode. This reminds me at a glance the types of changes that were made and when. After competition, the final version is committed to SVN and marked as a revision.

If you have questions or would like help setting something like this up, please feel free to pm me.

Re: Organizing your programming
 

Github has support for SVN clients: https://help.github.com/articles/sup...rsion-clients/

Use git.

Re: Organizing your programming
 

Yeah, disconnected operations as you describe sounds really annoying and is exactly why we don't use SVN. Here's our workflow at competitions:

• I create a bare git repo on a flash drive (cd /path/to/drive; git init --bare NAME)
• We set up remotes on each students computer to push to the flash drive (git remote add usb /path/to/drive/NAME)
• They do their normal development stuff, commits, branches, stash, etc
• When one of them wants to push code, they plug in the flash drive and do "git push usb BRANCH"
• When someone wants to pull from the flash drive, they do "git pull usb BRANCH"
• At the end of the day, I bring the flash drive home and push the commits up to git -- it's great, keeps history, no folders to keep track of -- and if someone screws something up, a 'git reset --hard HASH' allows us to go back to a known working state

Sure, git has a learning curve. But its advantages are numerous -- particularly in a disconnected environment.

Re: Organizing your programming
 

The advantage of our operations at competition (the "disconnected" operations as you describe them) is that I can view the files on any computer... and we have an automatic backup if something should happen to our programming laptop. This gives us the ability to quickly recreate our environment and software on another system if it becomes necessary. And I don't need specialized tools to access the files. Sorry, I'm old-fashioned and I don't really trust the cloud as my sole backup.

Re: Organizing your programming
 

Not to have a VCS war here but... :yikes:

When checked out at rest on a computer, all the files are there just like SVN and can be seen without special tools. I can copy directories too if I wanted to, but don't need to. :)

We do one better -- since git's local repo is a complete copy of the repository + history, each repo on each student's computer has complete history, and the flash drive does too. And development at the competition is almost exactly how we do development at home -- just pushing to a flash drive instead of to github.

Also, I can use git diff to figure out exactly what changes were made.

Well, if you had a completely raw system with no development tools on it, you would need to install Eclipse+compile tools or LabView. So from that perspective, it's just an extra piece of software you need to have installed. So we're still even. :)

To answer the original OP's question: At the end of the day, one needs to have a process that works for your team so you can do development at home and at the competition. For teams using text-based languages and more than one team member -- there are a lot of different ways to do it -- but use a version control system of some kind, and don't try to roll your own. There are a lot of opinions on which one is best -- but there's a good reason why distributed VCS such as git and mercurial have been hugely popular since their introduction.

Re: Organizing your programming
 

Wow this thread has exploded in the last few hours. Yes, I'm going back to GitHub. We already having an organizational account that we created back in December/January and we used GitHub along with the Windows desktop client up until mid-March, which is when we switched from LabView to C++. I cleaned up the GitHub account yesterday and since I'm about to teach some programming to members of my team, I'm going to have each of them who have not already create a personal GitHub account and add to the organization.

So basically we will be using Git/GitHub rather than the stupid idea I had in the beginning.

Also I went into the organization setting and downgraded everybody's permissions so that they must make pull requests and I must approve them. (Good idea MamaSpoldi)

BrianAtlanta, I'll make sure to distribute that video to everyone.

remulasce, definitely a relevant XKCD. We had to do that a few times. Will include that in tutorials for teaching Git/GitHub.

My plan is to teach programming (C/C++) which I still putting together material for. When teaching I think I'm going to require the entire group I'm teaching (about ten people) to all use GitHub for a final group project, and they vote on a single person to be the master of the repository (accepting reviewing pull requests.) This way I'm teaching programming and they have to use GitHub if they want me to review their work. Any suggestions beyond this or to add to this idea?

I'm currently writing up a document on what GitHub is and how to use it. If anybody would like to help me with it, PM me and I'll give your Google account access.

One last question. I'm currently using the Windows GUI client to work with repositories on GitHub, is there any opposition to that?

Re: Organizing your programming
 

Oh, missed that one. One more comment and then I'll shut up...

TL;DR: With SVN, you rely more on the cloud than when using git.

With SVN, to do any operation you *must* have a server involved (eg, the cloud -- even if it's your own personal cloud!). Otherwise if you have no connection to the server, you cannot use any of the normal SVN tools -- they all require a connection to the server. svn log? need a server. svn commit? need a server. svn update? need a server. And if the server isn't available, then you have to go back to the old way of copying files around by hand until the server is available.

With git, I can do all of the normal operations without a server ever getting involved, ever. commit, push, pull, diff, whatever. No cloud required. 100% local.

Re: Organizing your programming
 

Not stupid. Naive. :)

Yes, this is a great way to do it. I also give the more experienced students permission to merge pull requests, that way they can work independently.

Once it's done, this would be a great document for FIRSTwiki.... :)

There are a lot of ways to use git. I personally find the command line easiest -- but at the end of the day it's all what works best for you.

Re: Organizing your programming
 

Version control gets reinvented quite often. Normally by accident, or by someone trying to "make it easier" ;)

We use Git and Gerrit. Gerrit lets us integrate code reviews into the development process and control the quality of code that goes on the robot. Learn how to do code reviews with github and pull requests, and make that part of your development process. Software is really hard, and the more eyes, the better.

Re: Organizing your programming
 

I am a big fan of SourceTree as a Git client.

Re: Organizing your programming
 

Yay! Common sense prevails!

Re: Organizing your programming
 

Im the one programmer on our entire team, and I just use github desktop on my macbook air, works perfectly. I also don't make mistakes so that helps to :cool:

https://github.com/FRC-5752/FRC-5752-2016

Re: Organizing your programming
 

Love source tree. We switched to git at work about a year ago and selected source tree for looking at the branches. I still like command line for basic commits.

We use gitflow for our branching strategy. Master is competition. One thing I'm trying to get drive team to buy off on is that they control master. So using the git flow we create a release branch and deploy to a bot for acceptance testing by drive team. If they give thumbs up, it's merged into master. Nothing goes into to master with out drives approval.

Re: Organizing your programming
 

My team uses LabVIEW, and we use tortoiseSVN for version controlling. Is there is an advantage to using git for a LabVIEW team?

Re: Organizing your programming
 

No. The process is more important than the tool. If you had an IDE that would integrate the version control. That would make the process easier.

Re: Organizing your programming
 

I'm so sorry.

Isn't SourceForge the guys that started bundling malware into installers they were hosting? And besides, I think their primary missive is distribution, not FOSS.

What if you're not there? As a lead programmer, I would want more security, so that if the mentor was missing or busy, I would still have control. I don't know how many programmers you have, but this system doesn't seem very scalable - I would be concerned about kinks in collaboration.

So every revision goes on that drive? Sounds risky. I like that I don't need an internet connection to git commit. And besides, if you need a mentor, how can you deploy in queue? /s

Like git diff?

I guess this works if you don't make too many changes at competitions. Personally, I've been known to make anywhere between 10 and 20 revisions at competitions, with I think a high of 30. Those would be very specific file names.

Kind of like a commit title?

So after all the work at a competition, you have to summarize that all into one revision?

Anyways, I realize that this came off as kind of an attack, and I didn't mean it as one. I'm just considering potential drawbacks of this workflow. I do like that everything gets summed up into one version for each competition. I guess what it comes down to is whether it works, and it sounds like it does for you.

Personally, I will promote git and GitHub for as long as they are the status quo of the professional programming world. I think it's important to learn those skills if you want to succeed in the workforce, and learning new skills that are applicable to the real world is what FIRST is all about. Our GitHub is at GitHub.com/Team236/ and in my signature.

At the same time, I recognize that it is difficult to teach git and learning it requires a level of dedication that is not commonly found on an average robotics team. After all, our team has pretty much one programmer. I'm curious, what don't you like about git?

By the way, thanks for your help at Waterbury. Thanks in part to your help that day, 236 went 11/11 successful autos at CMP. I'm working on motion profiling and vision for the offseason, and maybe we'll something new next year to show off. Hope to see you at CT state champs!

Re: Organizing your programming
 

First, I'm always there... just ask our programmers. :yikes:
Also because of our development methodology there is somewhat less interaction between the coding being done by individual programmers than for some other teams. In general, no 2 students are working on the same source files. Each programmer works on a class that is related to their own robot mechanism. The exceptions to this are related to button assignments (and their implementation in the main code loop) and the autonomous mode coding which are generally handled by the lead programmer. Although the autonomous code generally resides in the main robot class it is isolated in separate function which is simple to merge with other changes if needed.


We never deploy in queue. That is a very dangerous idea... mistakes happen when you are rushing. We always do a basic system test after deploying code to verify the robot operates correctly.


We generally have more changes at early competitions than at later ones. Even so, the naming-system we use gives us 26 revs per day of competition which seems more than sufficient even based on your estimate. :D

Each deployed version can be checked in separately, and in fact that is often done for early competitions when there are more changes made. We mark the final versions of each file as a tagged revision, ie. this is the code from event X.

I strongly agree that the goal of FIRST is providing skills that will help students in the real world. But I think that you may be overestimating the universality of Git. I realize that it is a big part of the online, shareware community and it is great that it is being used by FIRST teams as well. But I have been a software engineer for over 30 years and have only seen it used on one commercial project that I have been part of. I do not want to imply that it is not used commercially but to point out the commercial world is vast and does not always reflect what you see/hear on the net.

I don't care for the paradigm used by Git and some other recently developed source code control systems. Like I said, maybe I'm a bit old fashioned. I prefer the straight forward use of check-in and check-out (or commit and update if you will) rather than commit/update/push/pull. I just find it unnecessarily complicated and redundant. Of course, I'm not a big fan of the cloud either... I don't trust it yet.

Always happy to help a fellow programmer. See you Saturday!

Re: Organizing your programming
 

It's better at 30,000 feet:
https://cloud.google.com/actual-cloud/

Re: Organizing your programming
 

I'm into year 10 of my current career path and this project I'm on now is the first time I've seen and used git. Coincidentally I was learning to use git for the first time right around build season in 2015, so I was learning it at the same time my programming students were! That led to some fun times.

Yes, the bottom line is that students need to get used to the idea that they don't work in isolation - that there is version control, team collaboration, and the concept of risk management (don't deploy new code until it has been tested!) (One of my proudest moments this year was actually when our most "enthusiastic" programming student said "I think we should just leave it for now. It works, and the drive team is doing well with what we've got. We can fix [the remaining issues] in between now and our next competition." YES!)

Git is a good system but it is not the only system and it is not the best system. There is some thinly-veiled "git is best" attitude in this thread.

Prior to git, I've used ClearCase/ClearQuest, a stupidly obtuse one called Continuus, and CVS.

I do like gitflow and I'm getting used to Github, but I'm told that coming from a ClearCase mindset is actually making it harder for me to wrap my head around git concepts. So I totally understand if students are confused.

The YouTube link posted earlier is a great presentation.

Re: Organizing your programming
 

Yes! I have been there before too... especially when the cRIO was first brought in. That was a big paradigm change for FRC... and then again but to a much lesser degree with the roboRIO introduction. But I must say it is a great experience to learn things along side the students. It helps them to see that we continue learning throughout our lives. Regardless of the level of experience we have there are always new things to learn and figure out.

Awesome! I applaud that realization. It shows a level of maturity and experience. I think that too many times changes are made when they are not needed and often have unintended consequences. You should be proud that you have instilled this level of consideration into your students. This is possibly the biggest lesson that they can learn from our experience. Think things through before you make a change... and review the change (preferably with another set of eyes looking over your shoulder) before you deploy it.

I definitely will check out that link. I'm interested to see what it has to offer by way of process and explanations.

Never too old to learn new tricks... but old enough to be skeptical that new tricks are always better than the old ones. ;)
Thanks!

Re: Organizing your programming
 

Well, as others have said, version control is your answer. Although the team didn't like git as a tool this year, git will solve the problem you have proposed. In fact, saving copies of your code at crucial points, as you have suggested, is pretty much what git is doing under the hood.

Using the tool properly requires team discipline to follow a workflow. When everyone does their own thing, it's pretty much guaranteed to fall apart. Here is one workflow suggestion that has worked well for us:

One student or mentor is the lead ("architect"). Other students are developers. The lead creates the initial project in the repo. This should be on a special branch (call it "master", maybe). By process, you must guarantee that the latest work on master represents the latest version of working software for the robot.

After this, developers are assigned specific tasks to work on. Each task should be done by creating a brand new branch at the latest commit on master. ALL of the work for the task should ONLY be done on that task's branch, nowhere else. If another task is started, start a new branch. In this way, once a task is completed, there is a 1-to-1 relationship between "this task was completed on this branch".

Once a task is completed, the developer should review the changes made with the architect, and possibly other developers. Look for bugs. Try the software out on a robot, if possible.

Once the architect and developer are satisfied the code is as correct as it can be, the architect should merge the latest on that development branch back to master. If multiple tasks are being merged, the developers and the architect may have to work together to resolve merge conflicts (where two developers made different changes to the same line of code). Note by carefully ordering tasks and merges, you can avoid most merge conflicts.

Finally, after content has been merged to master and tested on a robot, you may put down a tag to establish a milestone in software production. Use some simple numbering system (ex: v1, v3, v46, etc.) to indicate the progression through time. These are helpful in understanding which points in time functionality was added/removed and tested.

The most important part here is properly using branches. Minimize changes made directly on master - none if possible. All tasks should be done on their own branch. No re-using branches for multiple tasks. No putting tags wherever you want - tags indicate a set of proven functionality.

Not to say you couldn't ever deviate from this workflow, but having the standard up front is crucial to the success of a version control system

Re: Organizing your programming
 

Not going to get into the version control system argument here, other than to use Git.

Now, a couple of other things -

GitKraken is my GUI client of choice when I use a GUI client, but the git command line program is fantastic and actually extremely easy to use. Eclipse also has built in support for Git through E-Git, though it's not great it's helpful if you already have eclipse and don't want to install anything extra.

Another hosting alternative is GitLab, which besides providing servers also provides a community edition, which lets you install GitLab and self-host it on any machine/VPS. We used it last year and it was incredibly powerful.

Re: Organizing your programming
 

For anyone starting out in version control, Git is the predominant option in industry today which is easily shown through this Google Trends search. There is no need to get into a VCS war when clear data is available.

For those new to Git, try the following tutorials:

• http://www.codecademy.com/learn/learn-git
• http://try.github.io
• http://learngitbranching.js.org/

I generally use the command line, but when I need an IDE I use SourceTree: it's fully-featured, stable, and free.

Re: Organizing your programming
 

Ironically, that's the type of attitude that actually starts flame wars.