Organizing your programming

[MamaSpoldi]

Originally Posted by SamcFuchs

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.

First, I'm always there... just ask our programmers.
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.

Originally Posted by SamcFuchs

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

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.

Originally Posted by SamcFuchs

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.

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.

Originally Posted by SamcFuchs

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

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.

Originally Posted by SamcFuchs

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.

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.

Originally Posted by SamcFuchs

I'm curious, what don't you like about git?

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.

Originally Posted by SamcFuchs

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!

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

[techhelpbb]

Originally Posted by MamaSpoldi

Of course, I'm not a big fan of the cloud either... I don't trust it yet.

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

[GreyingJay]

Originally Posted by MamaSpoldi

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'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.

[MamaSpoldi]

Originally Posted by GreyingJay

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! 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.

Originally Posted by GreyingJay

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!)

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.

Originally Posted by GreyingJay

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.

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!

[gerthworm]

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

[astronautlevel]

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.

[nickdavis]

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.

[euhlmann]

Originally Posted by nickdavis

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.

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