Want to run it yourself? A runnable desktop version

After cleaning up a bunch of the build warnings, I ported it to Eclipse and wrote some stubs and a driver (called "Driver") so I could run it free of Android Studio or the phone.
https://github.com/50N40W/java4ftc/tree/master/ftc

Here it is in Eclipse - I like how, when you hover over a class, the descriptive comment pops up.  IDE's rock.



But why do the port to begin with?

Partly I was curious to see what it would take and with a cold snap happening around New Years Day, I didn't feel like watching football or a Jimmy Neutron, Guy Fieri, or Tiny House marathon.  But the real reason is more complicated.  Keep reading if you want to know.

 --------------------------------------------------------------------------------------------------------

The Real Story 

Candidly, it probably would have been a better idea to integrate JUnit testing into Android Studio (https://developer.android.com/training/testing/unit-testing/local-unit-tests.html ) but I also wanted to play around with Eclipse.   No doubt we'll get to JUnit or something like it eventually, just not this week.

Anyway ...

A lot of times you don't get access to the hardware until ... well, until someone hands you a still warm from the oven metal cookie and says "is the software ready?"  You get to download and give the code it's inaugural run with everyone standing around looking expectantly.

It's a little like, "here's a newly delivered baby, has it graduated medical school yet?"

That's just reality, and after a while you get a tiny little buzz if you can pull it off, even if it has a couple of bugs.  In fact, having a couple of small bugs may even be a good thing, as it keeps things believable.  If you make it look too easy, nobody's going to respect you.    ;-) 

So how to bump the odds?   The obvious answer is to cheat.  I don't mean to do anything unethical, and while the Experimentalist's Motto[1] is true enough, you'll learn more about how the thing behaves when you run it even once than if you stare at it for a week and try to prove its correctness.

One "cheat" is to run sections of the code on non-target hardware and THAT's what we're on about with this post.

There are a couple of things that we ABSOLUTELY have to remember.
1) This is a simulation, not reality.  That is, there will be a couple of differences, but all (or nearly all) of these will be at pretty abstract levels.  That is, the most complicated interactions between all of the hardware are not going to give up their secrets this way.  Keep those interfaces simple and clean, however, and your odds go back up a little.
2) The stubs will take some work to develop, and a little to maintain.  Sometimes you may want to reverse engineer some things from the FTC code or write something similar (look at the "Range" class in the linked files for an example).
3) You can stack the odds in your favor by how you design the code.  That is, the more modular the code, the easier it is to run this way.   The operative words here are functional cohesion and functional decomposition.  I'm not going post a link to those, just think of them as some sort of metaphor for a happy place.  It really is true that if you plan out the code, it takes lots less time to write, and hugely less to debug.  The trick is in making that time you spend planning productive.
4) You have to be really careful, because it gets real easy to get your code out of sync.
5) Understanding the numbers, how the outputs relate to the inputs, is the only way you're really going to understand what you're seeing.

But if you're careful, if you've designed things OK to begin with, and if you understand and can live with the risks, this is kind of a fun way to get a jump on the hardware.


[1] "A week in the lab is worth an hour in the library"