blinkin blue leds with ruby

#!/usr/bin/env ruby

require 'rpi_gpio'

def init
    RPi::GPIO.set_numbering :bcm

    [17,18,27,22].each do |pin|
        RPi::GPIO.setup pin, :as => :output
        RPi::GPIO.set_low pin

def cycle
    [17,18,27,22,27,18].each do |pin|
        RPi::GPIO.set_high pin
        sleep (0.25)
        RPi::GPIO.set_low pin

(1..9).each{ cycle }


This is the Ruby version of my Cylon LED test cycler that I’ve written in various languages on Arch Linux and the Raspberry Pi. This time it was Ruby’s turn to see if I could use it to manipulate the various I/O subsystems on the Pi. Since setting output pins to drive LEDs is the easiest place for me to start, I wrote the code you see above. Before I could make it work I had to install the rpi_gpio gem. To get some idea of how to use it I looked at the GitHub repository for rpi_gpio. The reason for this is to be able to bridge between the Ruby on Rails work I started earlier this week with both input and output I/O. The only other comment I will make is to make sure that the udev rules have been set up to manipulate the I/O as a regular user. Trying to run the code shown above as root will fail, as the installation of rpi_gpio was local to a regular account, not globally installed.

My only comment on rpi_gpio so far is this: I discovered I had to code a set_low immediately after every enabling of a pin as an output, as the pin was enabled high. I consider this a bug, and as it stands it may not be suitable for what I need. If even a microsecond pulse goes out from those pins after being enabled by Ruby then that’s enough to cause a false start on that pin. The Ruby code isn’t something to write home about, just something to do some very basic testing.

running rails + ruby + arch linux arm on raspberry pi 3


I’ve been asked to create a web monitoring application running on a Raspberry Pi (in this case the 3). The requirements are very modest; run a low-traffic web page to monitor another machine next to it, and provide a simple web report on demand across local WiFi. For this particular project I’ve elected to go back in time, as it were, and install Ruby and Rails as the web foundation. And when I say back in time, I’m talking 2007, when I created another embedded system using a milliwatt CMOS 486 clone chip running a custom built Linux kernel with µclib and BusyBox running Ruby and Rails.

This small post documents the steps, in order, for installing Ruby and Rails peculiar to Arch Linux ARM and the Raspberry Pi 3.

First, make sure that Ruby is installed. That’s as simple as ‘sudo pacman -S ruby’, and for the documentation, ‘sudo pacman -S ruby-docs’. Ruby Gems are a part of Ruby, and you can look to see if they’ve been installed with either a ‘gem -v’ or by looking down /usr/lib/ruby.

Second, add the following line to your .bashrc:

  • export PATH=”$(ruby -e ‘print Gem.user_dir’)/bin:$PATH”

Log out, then log back in. Make sure to do all this before you install Rails, or else Very Bad Things will happen when you do install Rails. It took two attempts to install Rails, all because I failed to add that line to my bashrc file before the first attempt. You can read all about RubyGems setup here.

Third, install Rails with ‘gem install rails’. This will install an account local copy of Rails under ~/.gem, specifically ~/.gem/ruby/2.3.0/gems with this version of Gems. Installing a local account copy is no different than what happens with Node.js installations. There’s always a debate about local vs global installation; due to security and my personal paranoia I always prefer local (non-root) account installation to minimize any unintended consequences a global installation might engender.

Fourth, to be able to reach the Ruby instance outside the Raspberry Pi, I modified the file ~/[project]/config/boot.rb and added the following lines of code at the end of the file:

require 'rails/commands/server'

module Rails
    class Server
        def default_options
            super.merge({Port: 8081, Host: ''})

The merge binds the web server to whatever IP address DNS assigns to the Raspberry Pi (‘’) instead of using localhost as the defult, and changes the port from the default of 3000 to 8081.

Finally, and this is just extra, I made a tiny modification to the default index file at ~/.gem/ruby/2.3.0/gems/railties- to add the text “Raspberry Pi 3” in order to drive home that the default web page was in fact coming from the Raspberry Pi 3.

Now on to doing something more useful…

happy birthday gingersnaps

It was on this day, one year ago, that the Gingersnaps came into this world. Tiny, eyes closed, ears barely visible, no teeth, they were totally defenseless and totally dependent upon their mother, Sunshine. The photo below is one (I have no idea which one) of them taken four days after their birth.

where is my mom????

Now, a year later, they’re officially Not Kittens, but Male Cats at around twelve pounds each. It’s sad to say that their mom, Sunshine, passed earlier this year due to feline cardiac arrest. But while she was alive she loved all five of the kittens she delivered into this world (the two boys, plus three females) and they’ve all turned out quite sweet and loving.

I would have create an appropriate photo for their birthday, but I had to fly back from Kansas and spend the rest of the day getting ready for hurricane Matthew, which is chewing up the Atlantic coast of Florida as  I write this.

And speaking of Mom, here’s Sunshine will all the litter.

momma guarding

golang considered harmful to simple-minded coders

golangIn spite of my advanced years (I turn 63 in December) I do try to stay reasonably current while at the same time encouraging and supporting the younger generation. There are times, however, where I have to call bullshit on what is written by the youngsters.

I recently came across a BS article via the Hacker News app on my fabulous iPhone 6S+ titled “Golang landmines.” Hacker News is the Slashdot for the ADHD segment of today’s contemporary young white male twenty-something code slingers. HN is essentially a lot of links “curated” and presented in a very simplistic list on your device. I put the word “curated” in quotes because this article, like so many others I’ve encountered via HN, has weird error messages in the body of the article; when you see that, you know you have to follow the link to the original at the top of the article. Thus it was with this article.

As befits its contemporary hipness, this article is hosted on Github. It’s part of a Github conversation which I find rather amusing. I guess anywhere that will host content is a decent platform for publishing and the direct consumption of said publishing, even Github. Whatever… The “author” writes about three “easy to make mistakes” in Go. The problem is that those mistakes can be avoided by the Go tools if you’re half aware and actually pay attention to the warnings and error messages the Go compiler/interpreter emit with your code. For example, consider the following Go example.

package main

import "fmt"

func DoSomething(doit bool) (result string) {
    if doit {
        result := "doit is true"

    return result

func main() {
    fmt.Printf(DoSomething(true) + "\n")

This code snippet is a refinement of the “shadowing considered harmful to your sanity” example at the bottom of the article. The issue is the use of “:=” in line 7 instead of the regular assignment operator “=”. If you read the on-line documentation for Go (Short variable declarations) you’ll discover that “:=” is “shorthand for a regular variable declaration with initializer expressions but no types.” Further reading shows that:

Unlike regular variable declarations, a short variable declaration may redeclare variables provided they were originally declared earlier in the same block (or the parameter lists if the block is the function body) with the same type, and at least one of the non-blank variables is new. As a consequence, redeclaration can only appear in a multi-variable short declaration. Redeclaration does not introduce a new variable; it just assigns a new value to the original.

It isn’t like you haven’t been warned. With that in mind I don’t understand how that so-called code example worked in the first place. If you take my example above and save it in a file named “shadow.go” and either run it directly (go run …) or build it (go build …) you get the following error message:

./shadow.go:7: result declared and not used

at which point everything stops. Granted, it’s not the most helpful error message in the world, and the example from Github surely isn’t helpful in illustrating what’s wrong and where, but Go does attempt to keep you from doing The Wrong Thing, if obscurely. So my question stills stands; how did that code example in the Github article build or run to start with?

And my comment to the Go compiler team is; why in heaven’s name can’t you people come up with clearer error messages that reference the specific language violation you’re complaining about? A clear error message with a reference to the specification would be so much more helpful, especially to those starting to learn the language. I mean, Go is a fairly new language written by Google engineers who should know better.

That’s why the coding youngsters don’t want us old farts around. We point out their errors and in the process cause crippling embarrassment to the little snowflakes.


I’ve been rather rudely asked what I would consider an “appropriate” Go error message. Here’s what my version of Go would emit with such an error:

./shadow.go:7: Use of short variable declaration hides 'result' first declared on line 5.

The error message is now more succinct as to where as well as why, tying directly back to the language specification. This helps aspiring Go programmers learn.

the duke is back, or i find i can’t do without java

1000px-wave-svgBack on 14 July I wrote a post titled “no more java“, in which I swore off the use of Java for everything new and to “walk away from any Java programming opportunity.”

It turns out that there is, practically speaking, no way for me to do that. As much as I despise Oracle, the use of the language throughout the last 21+ years of my software engineering career (Java officially turned 20 in 2015) isn’t something I can just blithely walk away from. As I came to discover over the last 60 days, while there are a lot of very good programming languages besides Java, there are some things for which Java is the better fit, warts and all.

That’s not to say I didn’t find the other languages I looked at as less than Java. I found them all quite compelling in their own rights. The languages I did go back and look into included Python, C-Ruby, JavaScript (via node.js), the latest stable version of C++ (C++14 via gcc and clang), Google Go (up to 1.7) , and Rust (up to 1.11). Notable by its absence is Swift. I chose not to dive into Swift because it’s still only on one platform (OS X, soon to be called macOS) and because it’s still in a state of flux as it transitions to Swift 3.

All those languages I did look deeply into were quite compelling in their own rights and offered powerful solutions for different classes of problems. And while they tended to overlap some features and capabilities of Java, they could never replace Java for the types of software problems I like to work on. And please note, when I speak of the languages I also speak of the development, build, test, and deployment tools that wrap a language and help make it a powerful problem solver.

I don’t consider my two months looking elsewhere a waste of time; far from it. It was an eye-opening trek into languages I would have never taken otherwise, as well as a deeper dive into some languages I’d had considerable experience with before, such as Python and Ruby (in fact, working with Python 3.5 was almost like re-learning the language, as the last version I’d touched was 2.4). With Java I’d grown a bit stale in my thinking, which is never a good thing. Looking at other programming languages fosters opportunities to expand perspectives and offers alternative solutions to tough problems for which Java might not be the best fit. It also illustrate ways to weave these “new-ish” solutions back into new and existing Java solutions.

And finally, by taking two months away from my Java work, I discovered when I came back that tough problems I couldn’t quite solve before were suddenly solvable, some of them quite easily so. I really needed a break away from Java.

So it’s back to Java, or more precisely, the Java Virtual Machine (JVM). For with the JVM I also have Scala, Groovy, Gradle, and JRuby, not just Java 8. I’m using the Actor pattern Futures and Promises and the Parallel Collections Library supported by Scala for modeling and simulation, while using Groovy and JRuby to solve unique problems while calling down into the Java libraries, especially for UI bits. And finally I’m getting the hang of using Gradle as my primary build, test, and deployment framework. I am so tired of Ant and I’m no fan of Maven either.

I need to do this again, at least once/year, to maintain a clear mindset and fresh perspective. I look forward to my next walk-about through the programming language landscape.