The circle of FRC and the importance of outreach

Yesterday, Stuyvesant Robotics did a demo at the Winter Garden in Lower Manhattan from 4-7pm. This was very special to me because I found out that FIRST robotics existed at a demo from the same team and the same location. It was many years ago, in fact some of the students doing the demo weren’t even born yet!

Me standing in front of a robot at the winter garden

I’m not exactly sure when the last demo there was but I think it was 2006 or 2007. I remember attending one competition as a spectator and another as a volunteer before volunteering as a mentor starting the 2009-2010 season. Either way, that’s a long time ago.

It’s a lot of fun at an outreach event because you get to share with others what makes this cool. And you get to see excited little kids learn about the robot. The pictures also shows driving a smaller FTC (FIRST Tech Challenge) robot and rolling the ball to the big FRC (FIRST Robotics Competition) robot to acquire it.

You never know who you will reach at an outreach event. They got me all these years ago. Coming full circle and seeing the event in the same place as a team member was great. Hopefully it won’t be well over another decade before the next demo in this location!

Teenagers showing two young children a robot
Young child driving a robot
young child rolling a ball to a robot

the value of a “talking stick”

Last weekend was the FRC (FIRST Robotics Challenge) kickoff where they announce the game for the season. Our team uses the time after kickoff on Saturday to discuss the rules and strategies in small groups followed up by one large group. (we have a lot of people; this is a very large group). And we use the day after kickoff to brainstorm in a large group all day to come up with a priority list and things to prototype. In past years, we’ve done this an atrium. Some years sitting on the floor and some dragging high school chairs/desks out.

And every year without fail, we have the problem of “sidebar” discussions. This has two impacts. One is that it becomes hard to hear the “main” thread of conversation. The other is that the conversation tends to split off and people don’t hear what others are saying so we can’t move forward as a group.

We try to enforce having to raise your hand and get called on before speaking. But people get excited and… well, lots of people talking.

This year, we used the cafeteria instead of the atrium. Saturday went as expected. When we got to the large group, there were numerous sidebars and it was hard to hear. It’s a long day and some of the kids were getting restless. Which meant more sidebars. Sunday started worse. We used a different part of the cafeteria and the vent was interfering. Forget sidebars, it was hard to hear the person speaking to the group from the other side of the group even when it was the teacher (who projects well) and nobody else was speaking.

We solved this problem by using two microphones.Then we could hear! The mic had a second advantage. Everyone had to raise their hand or we couldn’t hear them. Which meant we didn’t have a big problem with sidebars. There might have been some, but you couldn’t hear them so no problem there.

The mic was like a talking stick. You needed it to speak and it went great. One of the mentors started talking while holding the mic but not into it. (I couldn’t hear him.) I commented “you need to speak into the mic; it’s not a talking stick.”

I was wrong. It was a mic AND a talking stick.

Switching your Gradle builds from JCenter to Maven Central

JCenter is being decommissioned on May 1st, 2021. Since many Gradle builds use JCenter by default, this means your Gradle build file is likely to have jcenter() in it. This means you have a few months to switch to Maven Central. Don’t worry, it’s easy.

Note: If you work for a company, you are hopefully using an internal binary repository proxy. (ex: Nexus, Artifactory, etc)

What’s the difference between JCenter and Maven Central?

The main benefits of JCenter are:

  • Some artifacts are in JCenter and not Maven Central – their authors are working on moving them to Maven Central. This is unlikely to affect FRC teams, but might affect people using an artifact that is more specialized.
  • It’s easier to publish to JCenter – Sonatype has been working on making it easier for Maven Central. Some of that is intrinsic though because Sonatype does a lot of verification.
  • JCenter is faster – Remember that artifacts are cached on your machine. So once you’ve downloaded the artifacts, your build performance is the same.

How do I find the affected files in GitHub?

Searching on github for either of these does not do what you might expect

  • jcenter user:boyarsky filename:build.gradle- the code tab returns 0 results
  • jcenter org:stuypulse filename:build.gradle – the code tab returns 2 results

That’s because github search only looks in files that have been updated or returned in search results in the past year. Unfortunately, the last year has not been particularly representative of a normal year. And people edit/search the contents of build.gradle files way less frequently than other file types.

I recommend just searching for the filename. That returns all your build.gradle files so you can edit them. (And since you are probably consistent in your choice of binary repository, you can sample a few matches to see if you have to change.

  • user:boyarsky filename:build.gradle – the code tab returns 5 results
  • org:stuypulse filename:build.gradle – the code tab returns 24 results

Tip: You may also have a reference to jcenter in your settings.gradle so I recommend searching that as well.

How do I edit the file?

GitHub has good Rest APIs so you can script this if you have a lot. If you don’t have a ton, either of the following is viable. (I had 5 build.gradle files in my personal repo and 3 of them were already using Maven)

Option 1 – Use the browser

  1. Open each link from the code tab of the search
  2. Choose the default branch (ex: main/master) from the pull down – search often returns a specific commit
  3. Drill down to the build.gradle file if not already there.
  4. Click the edit/pencil icon in the top right (just above the code)
  5. Change jcenter() to mavenCentral()
  6. Enter a commit comment and save
  7. If you want to make sure your build still works, run it (ex: Travis)

Option 2 – Clone the repos

(Tested on Mac; I don’t have Git Bash on my home computer so don’t know if it works exactly the same. I have used find on Git Bash though so I think it does)

  1. Clone the affected repos (if you don’t already have them)
  2. Go to a parent directory of the github repos (ex: <userHome>/git
  3. Run a UNIX command to update the list files find . -name build.gradle
  4. Run a UNIX command to update the affected files: find . -name build.gradle -exec sed -i ” -e ‘s/jcenter/mavenCentral/g’ {} \;
  5. Commit/push the affected repos (listed in step 3)
  6. If you want to make sure your build still works, run it (ex: ./gradlew build)