View Single Post
  #15   Spotlight this post!  
Unread 07-10-2016, 12:46
plnyyanks's Avatar
plnyyanks plnyyanks is offline
Data wins arguments.
AKA: Phil Lopreiato
FRC #1124 (The ÜberBots), FRC #2900 (The Mighty Penguins)
Team Role: College Student
 
Join Date: Apr 2010
Rookie Year: 2010
Location: NYC/Washington, DC
Posts: 1,113
plnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond repute
Re: [FRC Blog] Regional Registration Issues

Quote:
Originally Posted by JesseK View Post
Meh. Sure, there's more they could have done. Here's the thing about "software", coming from someone who's done "it" and only "it" for 14 years professionally.

snip
I can't agree more with this post. It reminds me of a good article I saw last week about the idea of "<thing> is nowhere near that hard, I could do it myself!": http://danluu.com/sounds-easy/

Scalability problems also are rarely solved by throwing more resources at it. In fact, often, application performance can often decreases when more cores are added due to the increased need for synchronization and hammering of shared cache lines in a write heavy workload (plus added network latency in distributed systems). There is a huge amount of coordination required to make sure the database status stays in sync across all the machines involved. If people are interested, PM me and I can link you to some papers on the subject. These kinds of challenges take lots of time and engineering effort and like Peter said above, FIRST has limited engineering resources available (including writing all the software for next year's game).

There are also a couple of comparisons to TBA in the thread and I'd like to point out it's not an apt comparison to make in this case. TBA, as a system, has the benefit of an almost exclusively read-based workload and can do all writes asynchronously. TBA is cached very heavily, but that means latency of updates is scarified (that's why it's often a little out of date in the offseason). These assumptions would fail miserably in a registration environment, since you need up to the second information about event status (whereas a TBA page can be from anywhere between 1 minute and 1 day old).

At the end of the day, FIRST just realized they have to iterate their system. They employ engineers just like the rest of us who work incredibly hard to build and maintain their tools. Sure, not everything will work 100% of the time, but that's why we iterate and make things better. And it seems like a priority-based approach will make the entire process a lot less stressful for everyone involved.
__________________
Phil Lopreiato - "It's a hardware problem"
Team 1124 (2010 - 2013), Team 1418 (2014), Team 2900 (2016)
FRC Notebook The Blue Alliance for Android
Reply With Quote