[FRC Blog] Event Results and API Data
 

Posted on the FRC Blog, 2/28/15: http://www.usfirst.org/roboticsprogr...s-and-API-Data

Re: [FRC Blog] Event Results and API Data
 

Very, very, very frustrating, but at least glad FIRST still has all the data...

Re: [FRC Blog] Event Results and API Data
 

Do they?
http://www.chiefdelphi.com/forums/sh...4&postcount=23

Re: [FRC Blog] Event Results and API Data
 

If it is stored locally (which it clearly is, as the event needs to data to generate rankings and such), then there is no reason it has to be lost.

Re: [FRC Blog] Event Results and API Data
 

Yes, it is stored locally. I volunteered as a scorekeeper for an off season event last October, and the match data (and settings) were backed up automatically after each match. There are also means of exporting it as well.

Re: [FRC Blog] Event Results and API Data
 

New software this year, though. If we were running last year's software and API, we wouldn't be having these problems.

Also, even if the data is stored locally, that's no guarantee it's going to be pushed out and made available via the API after these events are over.

Re: [FRC Blog] Event Results and API Data
 

Yes, it is a different FMS software this year. However, each version of FMS seems to be based off of the previous season's version (with improvements and game specific updates). I don't think they would have eliminated the backup system, since that is a pretty important feature.

It is true that there is no guarantee that the data will become publicly available, but at the very least the district results need to be available. This data is vital to calculating the district rankings for each district team that competed this year.

Re: [FRC Blog] Event Results and API Data
 

This is based on my recollection of last year's FMS software...

I think that getting the data off would have to be a manual task. The database backups will definitely exist on each scorpion case, but I don't know if the functionality exists to automatically upload old data (or if you can even do it at all, once the event wizard is complete). The solution might be to remote into each field (ugh) and copy of the backup files. Or, have the Scorekeeper at each week 2 event export a bunch of csv reports, which can be imported. Doesn't seem like very good options, especially when the blog post didn't give a time frame for a fix. I wouldn't be surprised if it's not up for Week 2, either...

Re: [FRC Blog] Event Results and API Data
 

To my knowledge, FMS has been completely rewritten since last year.



I'd be surprised if there were any FTA across the country that wasn't aware that these problems were occurring. I would hope that they'd have the presence of mind to throw the data on a flash drive and/or send it manually to FIRST for reporting/archival.

Re: [FRC Blog] Event Results and API Data
 

The software is "new" in the sense that it has been updated since last year, but the core functionality is mostly the same as last year. They started with last year's code and updated it for this year.

I'm not sure about your comment about last year's API- The only "API" available last year from FIRST was a webpage that third parties could scrape (which isn't really an API). This is the first year a true API has existed.

I'm not sure what the plan is for data that wasn't already posted, but I wouldn't be surprised if FIRST put in the effort to upload it.

Re: [FRC Blog] Event Results and API Data
 

First opensourcing all the code they own would increase the quality of a lot of things.

Re: [FRC Blog] Event Results and API Data
 

That's a mighty bold statement. Pretty much totally wrong, but mighty bold.

Open source is essentially useless in an environment with forced deadlines.

Re: [FRC Blog] Event Results and API Data
 

Please tell us more about how allowing more about how the code getting more scrutiny ahead of time would make it worse. Can I sign up for your newletter?

Re: [FRC Blog] Event Results and API Data
 

There is a difference between open for scrutiny and open source.

If I put a document in a PDF and send it to you for you to review, that is open for scrutiny. If, however, I simply put the same document in GDocs and send you the link--with full editing permissions--that is open source.


In code, open source could be pretty bad, DEPENDING on a number of factors. Particularly, comments and other documentation, work breakup, and even "code styles".

But having the code open for scrutiny--that might help.

Re: [FRC Blog] Event Results and API Data
 

Pretty much this. Because the FMS has to be built and fixed on a deadline, an open source model, where you are depending on people who have no reason to meet an arbitrary schedule or work on "uninteresting" bugs to work to a schedule and fix the uninteresting bugs.