On Bicycles, and.... what else is there?

On only page 18 of Flanagan and Matsumoto's excellent "The Ruby Programming Language" a relatively complex example is presented: a Sudoku puzzle solver. I've had a decades-long interest in maze solvers, and this tied in nicely with that. I resolved to give the code a close look when I'd finished the book. And surprising myself, I soon did. I read it cover-to-cover, frequently even re-reading sections I'd already covered when a lack of mastery of specific material became evident later. The language is a nice alternative to Perl, which had been my scripting language of choice since 1998. Ruby has a lot of cool characteristics, even if it sometimes falls weakness to Perl's desire to appease too much diversity in coding styles. I personally think being able to do things effectively two different ways is inferior to being able to do things as effectively only one, as the latter makes multi-author code easier to follow and coherently maintain. But as usu...

I've embraced Ruby for my coding project. Ruby has been great: I really like it's object-oriented nature: it's inherently object-oriented, with that built in to the core of the language, rather than some sort of kludge built onto what is essentially a sequential language. Actually, I'm not sure whether "object" versus "sequential" is correct, here, since Ruby is still highly sequential, it just heavily uses objects. You can still write Ruby code which looks much like Perl code, with notable exceptions. But I don't want to write Ruby code which looks Perlish. I want it to look Rubyish. So therein is what makes for slow going: I write stuff, check it, re-read the on-line documentation to make sure I'm not reinventing any wheels (there are a lot of standard methods in Ruby), make adjustments, run, and track down the inevitable bugs. Slow going, but it's what it takes to build aptitude in a language. So my end-of-Feb deadline for t...

Last time I posted what I called a "SmoothData" class for Ruby. But even as I was hitting "publish" on Blogger I realized I wasn't being honest. There wasn't much "class" about it: it was a single static method which was similar to what one would write for any sequential procedural language. Indeed, since it was essentially ported from Perl, this shouldn't be a surprise. Initially my attitude was "this function doesn't need to preserve any local state. There doesn't need to be multiple instances of it. It's just an algorithm an nothing more. Why make life too complicated just for a dogmatic adherence to the object oriented cult?" But then I tried to use it and I realized... hmm... maybe I should reconsider. The plan was to, for various measured Strava parameters (altitude, speed, power) to have both measured values and smoothed values. So, for example, for altitude, I'd have an altitude array and a smoothed al...

Ruby self-teach continues, so I put together a data smoothing class for Ruby. Nothing new here: another in a series of codes I've used for comparing Java to Perl to Ruby. Data smoothing is an important part of anything I do with cycling data. So this is a critical component for me on any sort of project I might want to accomplish. For example, suppose I wanted to write a code to identify and rate climbs in an activity. I know -- Strava already does this, but I've got my own ideas about algorithms. Well, if I were to take altitude data raw, a small glitch yielding a 50% grade between two closely-spaced points might generate a huge spike in the climb rating for just those two points. Instead it would be important to smooth the altitude out, for example with a 50 meter characteristic smoothing distance. 50 meters is a fairly good number on climbs this length and shorter you can generally use momentum to blunt the blow. It also covers up small errors in position and altitu...

StravaToCSV has become my "test app" for various programming languages ( Perl , Java , and now Ruby). And for that it works fairly well: I need to process command line arguments, open an HTTP connection to Strava, download JSON data, convert it, then then output it as CSV. So there's a decent amount there. This project went much smoother than my Java implementation. It was fairly quick, taking a bit longer when I wanted to avoid the program imploding when it was fed a bad activity specification. This version takes as its only command line arguments activity numbers (for full activities) or activity-segment pairs, where the activity number is separated from the matched segment by a "#". It will sequentially load each of these, outputting a CSV stream with the header determined by what fields it finds in the first non-empty activity. It adds the activity number as the first column of the CSV stream. At first I expected the JSON library to have some sort ...

Well, I realized the Pine Flat Road Race was tomorrow (Sunday) not today (Saturday) and so, had I rested today, I probably could have gone. Ah, well. I have a rule that I need to do a hard group ride before I even think about racing, and I haven't yet done so this year, or even towards the end of last year. No, the Friday Noon Ride is not a "hard group ride".... nor is Wednesday. Only Tue and Thu come close to qualifying. So it probably wouldn't have been prudent trying to mix it up at Pine Flat, anyway. But on the positive side, that's 6-7 hours I will not be spending in a car, and more time I won't spend in a smelly motel room, more time to devote to my coding project. On Facebook, it was recommended I look at Ruby. This was an obvious thing to do, since it is what Strava uses for its API example . However, I had gravitated towards Java because with Java I knew I could generate an Android app. All it takes is a bit of Googling to note that Android a...