Raspberry Pi.

For the last couple of years, a couple of parents have asked what kind of things they might do at home for their student who is interested in coding.

My reliable fallback answer is "Raspberry Pi."

This one in a yellow case was mine until I mailed it off to our oldest child (a computer science major) who had a need to do some low level work on an ARM processor.  Do NOT worry if none of that sentence made sense. :-D

I replaced it, of course, but I still miss the sticker.  I often try to have 3-4 of the zeros on hand, and give them out when I find myself around college nerds and see a project I think is cool. 


A complete - except for monitor and keyboard/mouse - setup will run between $35 (for a Pi Zero W) and about twice that for a Pi 3B+.
Microcenter usually has the base zero Ws (no accessories) on sale for $5 and there's a limit of one per customer.

They are available from Amazon,
Adafruit: https://www.adafruit.com/category/175
Microcenter - there's one near the Cincinnati Ikea - http://www.microcenter.com/search/search_results.aspx?Ntk=all&sortby=match&N=4294910344+4294819333+4294818915

And probably Fry's.   I think I've seen them at Target and Barnes and Noble in the past, but that's been quite a while.

Anyway ...

There is a ton of information at the Raspberry Pi foundation's own site: https://www.raspberrypi.org/  but here's a little overview anyway:

The 3B+ has 4 USB ports, a full size HDMI connector, 4 cores and twice the memory.
The Zero costs less and is tiny - a little bigger than a pack of chewing gum.
They both have wifi and bluetooth.

Size wise, the Pi is something like 85x23 mm, or about 3.3 x 2.2 inches if exercising your birthright to imperial measurements is a thing you're into

Oh the perils of mixing measurement systems

https://imgs.xkcd.com/comics/lightsaber.png

Anyway, the Pi was created because the boffins at some really impressive university in the UK discovered that school aged children didn't have the experience with both hardware and software that earlier students did, and in turn that made filling their computer science classes harder than it should be.   Rather than moaning about it, they created the Raspberry Pi foundation and designed their own.

They're mostly made in Wales, home to some truly astonishing town names.  The video is an hour long, so you might not want to click the link:

The Pi uses a pretty nifty Linux variant, and don't panic if you've never used it before.  The instructions for how to install it and get it working are on the foundation's page (Adafruit also has a lot of Pi info) and it's not all that complicated.  The foundation's site even has a page to help guide parents through the trauma: https://www.raspberrypi.org/learning/parents-guide/

The software packages included in the base OS change a little from time to time, so I won't go too much into that here, but they usually include some Java and Python development tools plus something like Scratch and they have included a lightweight version of Wolfram Mathematica as well.

 I have no connection to any of the links provided here, and can't make an official endorsement, but I've bought and given away several and have 2 or 3 hanging around now that I use for playing around with different OS's, ways of programming microcontrollers using the IO pins, that sort of thing.  I'm thinking about seeing how Jenkins works on one for my next experiment.

It isn't perfect by any means, but despite - or because of - its incongruous nature the whole package works a lot better than you'd think.  And like these guys from Finland, I'm actually a little thunderstruck.

"Code to Joy"

Ludwig von Beethoven “The thing that gets lost,” he says, “and which I think is important to know, is that programming is never easy. You’re never doing the same thing twice, because code is infinitely reproducible and if you’ve already solved a problem and you encounter it again, you just use your old solution. So by definition you’re kind of always on this frontier where you’re out of your depth. And one of the things you have to learn is to accept that feeling – of being constantly wrong.” - Quincy Larson, quoted by Andrew Smith in https://www.1843magazine.com/features/code-to-joy Information is where you find it, and if you go looking for articles that require a little thinking they have a way of finding you.  Case in point: I'm not a regular Economist reader (1843 is a cultural offshoot of the Economist), but this article by a journalist who decided to learn to code bubbled up on my news feed one day. I read it, and I'm glad I did.   Ode To Joy is also the fourth movement of Beethoven's Ninth (which is why he gets a cameo), and the Code to Joy title seems to me to reflect the way that dedicated and skilled professionals feel about their life's work.  It may play into the interfaces necessary for making a symphony work, but I didn't read that much into it. Anyway, this sentence really stood out to me "...you’re kind of always on this frontier where you’re out of your depth. And one of the things you have to learn is to accept that feeling – of being constantly wrong.”  It sounds kind of sporting, doesn't it?  It is, but that's why we love it.  There's always that little hit of adrenaline that kicks in because we don't absolutely know what's going to happen next. Let's pull back a few klicks and challenge a word we've gotten too comfortable with.  Mathematics is no more just arithmetic and geometry than "Life" is last night's leftovers and mowing the lawn.    Computer science, it may surprise you to hear, is applied mathematics.  I usually say "an applied mathematic" but that's just to emphasize the point, because the real experts like to fight over whether "applied" or "pure" mathematics is better.  I think it's kind of a dumb argument. https://xkcd.com/435/ Math is funny stuff for both the pure and applied mathematicians with lots of ties to music, language, philosophy, and logic.   In fact, a big chunk of a math degree (especially pure math) once someone finishes the calculus series is how to use that logic to prove things called theorems. Here's one: "if group A includes all the pasta types, and group B includes all marinara sauces, then every pasta meal has marinara sauce."  A Skyline chili just blows that away, and the disproof - the proving it false, is both tasty and trivial. The point being that some things are easier to prove than others, and most of them depend on some sort of assumptions and definitions we make along the way. Parts of CS (Computer Science) are a really peculiar fusion of the pure and the applied - the code must do something, so it is "Applied Math," but it is subject to theoretical constraints and proofs, so it elbows into "Pure Math" too.  Consequently neither type of mathematician totally trusts CS, at least until they need a job.  (My background is a mix of applied math and CS, so I catch shade from everybody.  :-D   ) You might have guessed that proving things about code is where we're headed, and you'd be right.  You can just whale on the code until it's bludgeoned into something like cooperation, but this is horrifying.  Yes, you get this wobbling object that trots itself partway across the field (yay! the robot works!!) but then it disgorges its bits and bytes in a public and appalling display of the perils of illogic (wow, what went wrong with the robot and can you fix it in 5 minutes?!).  That's no fun at all. If you'll indulge me the source, once upon a time a Roman named Paul wrote "all things are legal; not all things are profitable" and the blunt force method is ... unprofitable.   You see, after you put down the clubs, hammers, and open flame that method relies on, someone else is going to have to make a change to that dented and quivering carcass of logic, and they will either break it, or break it and soundly curse you and three generations of your heirs as "the reason we can't have nice things." There are better ways. I've been doing this for money off and on since Reagan was president, and in between waiting for Windows, waiting for compilers, waiting for ... you get the idea, I've had some time to contemplate and some time to read the evolving theory of this science.  I'll be darned if we don't agree - 1) the fastest, cheapest way to make code is to do it correctly. 2) it's called the correct way because it is the fastest, cheapest way to make code. 3) if you want it to stagger to a collapse right when you need it most, do it the blunt instrument way. I've posted earlier that the hard part of making software is not the little pieces of logic that make the individual things happen.  The hard part is figuring out which little bits you need, how to make them play nicely with the other little bits, how to write as little code as possible, and how to reuse as much of what you do write as you can. Another hard part is how to get to where you believe what you have might work.  There's a difference between actually believing it will work and saying "if anything's going to happen, it's gonna happen out there."  We're supposed to be training the students, after all. If you can sniff out a bug before you ever compile or download it, you've saved some time.  Do this enough, and you get some freed up practice sessions where you can work on other, more interesting problems. A good lint tool can help with both of these.  Here's a picture of some team code that's been linted:

Notice on the right side there aren't may little yellow lines.  Most of our code files have 20-50 or more lines of various colors - every one of which is a Lego on the floor of our code, just waiting for us to step on it in the middle of the night. Could be a piece of data that's defined in the wrong place, an improperly defined class, or a variable that is never read, only set because it's name is really close to the one we meant to use, could be one of a hundred different things.

So for the mentors, we really do have to resist the temptation to start slashing and burning our way through the jungle of this year's competition, we really do need to help the students start thinking about the design early and how they're going to communicate it among themselves, and just as importantly, how serious we're going to be about driving out those endless annoyances of "incorrectly scoped variable," "variable declared but not used," and "code never reached."

I'm hoping "Very Serious."

In the last post I discussed using Sonarlint - which I still like for a couple of reasons. I spent a day last holiday break going over 3.5 of our team code and actually learned quite a bit about Java conventions and was able to deduce why they exist.  Sure I questioned the wisdom sometimes while I was doing this, but when I finished I looked it over and it really was tighter, easier to read, with less wasteful code.  And if it looks like that to me, it's going to look a million times more like that when we shove it into the microprocessor to run "hot."

 To install it in Android Studio select the leftmost pulldown, then from File -> Settings -> Plugins -> "From Repositories" then scroll down to find SonarLint.  Here's a picture of my menu screens for this job:

Here's a link to my github of our team code set up for the 3.5 FIRST release.  We'll probably have to make some small changes to connect our team code to the FTC code for 3.7 or 3.8, but the team code wouldn't need to change much.  https://github.com/50N40W/KP35-Bravo

To close out in a full circle kind of way, here's another take on "Ode to Joy"