software suggestion for next year

[jonv]

This thread about upgrading to a new software version:

http://ftcforum.usfirst.org/showthread.php?6502-Our-process-for-upgrading-to-a-new-SDK-Code-and-phones

highlights a problem with the way the FTC code is being distributed in the first place.

The Qualcomm code should not be in a project that you check out and edit. It seems very clunky to be putting team code in someone else's project, especially when it comes time to upgrade. The first post in the referenced thread (that shows what people go through to pick up the new code) sort of proves my point.

The low level hardware code should be a library component that teams can download and then just add to the library folder of their own projects.

This would greatly simplify trying out upgrades. Just download the new libraries, add them to you lib folder, and try them out. If you don't like the result, just go back to the previous version of the library. Teams then could maintain their own code repositories that don't depend on the FTC-provided repository. Then there is no need ever to merge code in from other branches. Merging branches from different development trees is only easy after you have climbed a very steep learning curve, as Philbot and others pointed out.

This would also require a new way to add op modes through some kind of registration mechanism instead of editing classes from the core library.

There could still be a "reference implementation" project that shows how to set up Android Studio to use the libraries, but teams would not edit this project, just look at it or use the examples as starting points for their own code in their own project.

JonV

[mikets]

From my understanding, here are the components in the project that we care about:
- Qualcomm library: ftcrobotcontroller\libs
- Sample code sources: ftcrobotcontroller\src
- Javadoc
- Build environment files (e.g. build.xml and gradle files etc)
- Our team code

Ideally, I would like to clone their tree and keep it unmodified so I can pull from time to time to get the updates. Then we duplicate this tree to another tree where we add our team code (possibly deleting all the sample code). Now the trick is to organize the tree such that when there is an update, all I need to do is to pull the update to the original tree and copy a few consolidated folders from the original tree over to our tree. These few consolidated folders would be explicitly laid out in their update instructions.
Today we are already doing that with their current tree. I can identify all the components mentioned above except for the build environment files which got scattered around different folders. Since Android Studio is new to us this year, I am not certain what files are important that need to be copied over unchanged, what files I should change to customize for the team. So if these files are listed in the instructions explicitly. That will be great.

[FTC0417]

We experimented with some amount of improved separation of team code from SDK code in the Swerve Library; you might want to have a look (see the YourCodeHere module, in particular).

[dmssargent]

Any of the major library maintainer's for the FTC SDK try to make the library upgrading process as easy as possible, each of us tries to abstract the app aspect of the controller library in different ways. Both Xtensible and Swerve provide annotation based OpMode loading, mine was based off the original code from Maths222 who found a magically way to acquire a context, then I expanded how the loading works, Swerve then adopted my code into their library after doing a considerable amount of refactoring.

Still people like me need to here complaints in order to help us improve life for the average FTC developer (which is hard if you really can't take a random sample of their opinions)

[skatefriday]

Any of the major library maintainer's for the FTC SDK try to make the library upgrading process as easy as possible, each of us tries to abstract the app aspect of the controller library in different ways. Both Xtensible and Swerve provide annotation based OpMode loading, mine was based off the original code from Maths222 who found a magically way to acquire a context, then I expanded how the loading works, Swerve then adopted my code into their library after doing a considerable amount of refactoring.

Still people like me need to here complaints in order to help us improve life for the average FTC developer (which is hard if you really can't take a random sample of their opinions)

We separate the SDK from team software by dropping
relative paths into the grade script for the robot controller.

e.g. In the android block in build.gradle for FtcRobotController

sourceSets {
        main.java.srcDirs += '<path to your local team source>'
    }

If you maintain a fork of the official SDK you can commit this to
your fork and updates become relatively painless.

BTW, the annotation based opmode selection is completely and utterly awesome.

[Robert Van Hoose]

This thread about upgrading to a new software version:

http://ftcforum.usfirst.org/showthread.php?6502-Our-process-for-upgrading-to-a-new-SDK-Code-and-phones

highlights a problem with the way the FTC code is being distributed in the first place.

The Qualcomm code should not be in a project that you check out and edit.

JonV

This a thousand times. I can barely get kids to commit their code at all. Branching/merging is not going to happen. Merging the latest SDK changes is always a huge pain. I have no idea how a mentor with no software experience would manage it.

[skatefriday]

I can barely get kids to commit their code at all.

I can relate, and we've used git/github since 2012, but I've really stepped up the
software management training this year. Emphasizing repeatedly that it's a required
part of producing software in a collaborative environment, that companies spend
huge sums of money managing their software, and that it can't be an oversight.

Commits, branches, syncs, and pull requests are all well understood. Merges I still
usually have to help with the ensure they are done correctly, but that's also partly an
unwillingness by the young kids to invest in learning vi (the default editor supplied with
the Git for Windows package).

Yes, it's often a battle, but ultimately, for those that decide to make software
a career, they are getting valuable experience that they'll thank me for later. I
just remember that when they are groaning at me yet again.

[dmssargent]

Make vim fun for the kids, try having them play http://vim-adventures.com/, use the builtin Git integration in Android Studio (it can help resolve conflicts like a dream), force the kids to use Git in their collaboration and have them figure out their own workflow in Git. If they still refuse to use it have them work on a fairly large, but simple task collaborating (meaning at least two of them are coding on different computers together), they may figure out that Git is going to be more efficient than what refusing to use it is.

[mikets]

To make it less painful to use Git, we organized our project such that each student programmer owns some number of files exclusively. This means we use object classes heavily (i.e. the entire robot project is objectized with subsystems and autonomous strategies). Each student is assigned some subsystems and autonomous strategies to write. Since every class in Java resides in a separate file, a student who writes code for a class exclusively owns that file. Nobody else should touch a file that he/she doesn't own. However, we do have common files that all students shared. For example, we have a class that stores all robot constants and parameters. For these, I asked the students to define the constants private in their own class during development. Every week, all programmers get together to do code reviews of each other's code and at which time, all these constants are merged into the common shared file. This drastically reduced the need to merge conflicting check-ins. We also enforce the rule that you should never check-in codes that don't compile causing build breaks. It's okay to comment out unfinished code when checking in but it must at least compile without error.