Like any good “lazy programmer,” I’m always looking for ways to automate. This spring’s project: monitoring and watering my garden. I had a wifi-enabled Raspberry Pi laying around and decided to put it to good use. For this project I wanted to do better than just a glorified timer. The goal: An automated watering system that can use the weather forecast, soil, light, and temperature sensors to keep my garden looking great all summer.
Phase 1: Timer and Forecast-Based Watering
I’ve written a simple script that wakes up at 10PM, determines the likelihood of rain, and waters accordingly. The script looks up the forecast using the Forecast.io API. If there is less than a 50% chance of rain, the GardenPi will water for a short duration. Read more on GardenPi: Garden Care with Raspberry Pi…
I recently was asked to teach a workshop at Hope College on Git. I am jealous of the students that attended. Their curriculum includes things like unit testing and version control. Having the importance of source control shown to them so early is a major boon. Giving this talk got me thinking about why I prefer Git over other version control systems like SVN, Mercurial, Perforce, etc. Read more on Why Use Git?…
Last weekend, I lead a workshop on game development at the 12th installment of the Southern California Linux Expo (SCaLE) — a community-run, open-source, free software conference held annually in Los Angeles. SCaLE has grown to 2500 attendees, 100 exhibitors, and 80 sessions and tutorials.
Having attended SCaLE in the past, I had high expectations. This year definitely exceeded them. Being a Linux / general open source conference, SCaLE has a wider variety of technologies and people than most. I met Ubuntu experts from Canonical, engineers from Disney, and even a recruiter at the Apple booth! Read more on Learning & Presenting at SCaLE 12x…
I recently found myself trying to answer the question “Is there a quick way to talk to a USB HID device from Windows via Ruby?”. The short answer is “yes, via HID API and FFI,” but that’s much too short a story. Let’s look at the long answer:
I consulted my trusty friends Github, Rubygems, and Google. After looking around for a bit, nothing met my needs. There were libraries that did USB via libusb. There were even one or two that had a nice clean HID interface, but they hadn’t been touched in four years and no longer worked in modern versions of Ruby.
Along the way I was guided to a C library called HID API. The interface looked clean and simple. Only one problem, no Ruby. Then I remembered how easy Ruby’s foreign function interface (FFI) was to use. I’ve used it in the past and John Croisant wrote a great introduction to it last year. Here’s the code I needed to finish up my quick spike: Read more on Ruby FFI for Quick Prototyping…
If you’re developing WPF applications and do not have Snoop installed; install it now. I’ll wait. Installed? Good.
Snoop is an open source tool for spying and debugging a running WPF application. It can be used to inspect your running application and make changes while your app is still running. I’ve found it to be very useful for finding missing bindings and tweaking layout parameters when you can’t use Designer. (don’t ask, that’s a blog post for another day.)
Here are a few tips to get you started:
Selecting Your App
After installing and launching Snoop, drag the cross-hairs from the Snoop window to your WPF application. You’ll see your application tree on the left and a property editor on the right for whatever component you have selected.
Read more on Spying on Your WPF Applications with Snoop…
Opal has been under development for a couple of years now by Adam Beynon. There is an active community of people working to improve Opal and build extension libraries like opal-jquery, opal-sprockets, and vienna. I’ve started my own little Opal project while writing this blog post. I ported a basic Pixi.js example to Ruby via Opal.
Read more on Opal.rb: Ruby in the Browser…
A preview of Ruby 2.1 was released a couple of days ago with these release notes:
VM (method cache)
Frozen String Literal
def’s return value
I found myself scratching my head for a minute. I don’t know what most of these are! So let’s dig into them and dive into some of the details.
Read more on Kicking the Tires on Ruby 2.1 Preview…
Posted in Ruby Tagged ruby
Documentation is a crucial part of any good API or framework. Despite this importance, it often gets neglected and treated as an afterthought.
I recently asked another developer how he always managed to put together such well-thought-out and complete documentation. His response was: “Documentation Driven Design (DDD): if your API feels clunky to document, it’s probably a bad design.” This reminded me of my first introduction to Test Driven Development (TDD). By breaking your code into smaller chunks and testing them first, you were immediately placed on a road traveling toward better design. Given how useful TDD has been for me, DDD seems worthwhile.
One of the main considerations that determines whether I use a framework is how complete and easy to understand the documentation is. But in my own hypocritical way, I’ve neglected good documentation principles on my own hobby projects and frameworks. Read more on Framework Docs Are a First-Class Citizen…
I am a to-do list junky. If I want to get anything done, I need it written in a list somewhere. I used to go through a lot of index cards to keep this obsession satisfied, until I switched to Trello.
Trello is a digital task list with a twist. You organize your tasks by placing them in lists on a board. Cards can be quickly assigned or dragged to another list, making Trello ideal for a Kanban board. Read more on Organize Your Life with Trello…
Acceptance testing is hard. It requires thinking through your entire problem and nailing down the expected outputs for a list of inputs. When working on games, acceptance testing becomes even more difficult.
There are certain aspects that cannot be tested: “Is it fun?” “Is it too hard?” Other aspects are just difficult to setup and too brittle to maintain. You don’t want your tests to break on small tweaks, like player walking speed or jump height, but you want to enforce that the core game mechanics are working: “Can I shoot another player?” “Can I jump up on that ledge?” This is the area where tests can be incredibly useful.
Is the bullet traveling perfectly parallel to the players feet? It’s hard to tell, even when playing.
Read more on Acceptance Testing Your Games to Fix Bugs and Provide Regression…