Siteswap in Sinatra

I started the day by working on some CSS animations that would use JavaScript to set class values and create an animated juggling pattern in the browser. But after I set up Jasmine and started working on the JavaScript portion of the project, I realized that it would make more sense for me to develop the Sinatra app first and focus on the JS once I have a stable application.

In other words, Patrick and Myles warned me against the dangers of creating stuff I don't need, and I listened.

Instead, I spent a good chunk of my day transforming my command line app into a Sinatra app. This required remembering how to use Sinatra, which was a lot easier today than it was two months ago. Most of the time I feel frustrated by not knowing or understanding as much as I'd like. But sometimes my progress hits me over the head and I actually feel like I've accomplished a lot in my time as an apprentice. Today is one of those days.

I still have to do some work to refactor my code and separate my application logic from the app display and the command line runner. But that's the small stuff. For now, I'm choosing to focus on the fact that it's working and it does what it's supposed to do.

Refactoring Siteswap

One of the coolest things about my apprenticeship at 8th Light is that I have the opportunity to pick lots of brains and learn how different craftsmen approach problems. Last Friday, I explained my siteswap problem to Li-Hsuan and we worked on the problem of efficiently removing arrays with repeating patterns. For example...

• 1234512345 shouldn't exist. 12345 is fine.
• 123123123 should just be 123
• 121212 should be 12
• 333 should be 3

You get the idea. He pointed out that you could get away with fewer calculations if you start with an array that's cut in half and then check the two halves, rather than starting with the smaller divisor and working your way up. For example, 123123123123 could be checked by a sub-string length of [1], then checked by [12], then checked by [123] (which would then return true because it's a repeating pattern)...or it could be checked once by [123123][123123]. Checking the larger divisor first will usually be more efficient.

Then I asked Colin to help me figure out why it takes so long to calculate longer sequences. I initially thought that it had something to do with my correct_timing method, but we soon discovered that it was actually Ruby's repeated_permutation function that was taking so much time to run. We talked about the potential of making a lazy method to return a smaller number of values, but I'm not sure if it's possible in this scenario. If I decide to turn this into a web app, I might need to pre-generate the values and then have the app run checks against an already-established list of possible throw sequences for different throw heights, number of juggling props, and number of throws in a sequence.

In the meantime, I implemented inclusion and exclusion functionality so that users have greater control over what types of values are returned.

And yes, I'm still pushing changes to GitHub.

Coding Siteswap

Jugglers have a notation called siteswap to explain different sequences of throws according to throw height. Thinking through the possible patterns for a given number of objects is an interesting math problem—a problem that I decided to attack in Ruby.

To determine the different throw patterns, I used Ruby's repeated_permutation method to find all of the possible throw sequences for throw heights 1-6. Then I added some filters:

def is_valid?  
 correct_number? && # number of objects thrown
 good_first_throw && # first throw must be high enough
 correct_timing == true && # you can only catch one thing at a time
 does_not_repeat # don't return 313131 when 31 will suffice
end

At the moment, I'm looking into this nifty JavaScript siteswap animator and seeing what it will take to make my Ruby code generate some sweet animations. I'm thinking that jQuery + an HTML5 canvas element would be pretty cool.

Here's the siteswap repo on GitHub.

Readings and Musings

Lately I've been reading a lot about different methods and theories for effective software development. I started with eXtreme Programming and I'm now in the middle of Software Craftsmanship by Pete McBreen. McBreen is unabashedly opinionated about the subject; his frank writing style makes me chuckle, but his thoughts are on point. There are a ton of great quotes and ideas from the book, but here's one of my favorites:

"After all, things rarely change just because of an idea; instead, they change because we act on the idea and make decisions based on it." -- Pete McBreen, Software Craftsmanship

I appreciate his fervent belief that craftsmen should build their reputation on beautiful work, and never settle for a mediocre delivery.

On other notes, I've been cranking away on my Rails application, looking into adding some JavaScript to the mix, and beginning to work on a juggling notation application. More on that later.