Scott recently posted about the theft property-based testing library in C. Theft is very similar to Haskell’s QuickCheck. Theft tends to have a little less magic than Quick Check for generating random input and for failure case reduction. Theft makes them more manual, but also gives you better control of how they work. The theft ruby gem is a direct port to allow the same kind of testing in Ruby. Let’s take a look at the value in property-based testing and walk through a contrived example in Ruby.
Testing complicated algorithms can be, well, complicated. Typically, a developer will try to reason about their code and come up with a representative set of test cases to exercise the normal flow of the algorithm as well as all of the edge cases. This approach can leave holes in test coverage and brittle tests to maintain. That leads us to property-based testing. Basically, generate valid, randomly generated input and validate that a particular property is true.
Scott’s post does a good job of showing a real world example on the heatshrink compression library. I’ll use a contrived example to show how the theft gem can be used in Ruby. Read more on QuickCheck in Ruby…
Phase one GardenPi has been running well for a while now (aside from some wifi connectivity issues). I can legitimately say that my garden waters itself everyday, unless the forecast calls for rain.
However, there are definitely improvements to be made. Let’s take a look at how to add analog sensor to the Raspberry Pi for soil moisture and light. Read more on GardenPi: Sensing with the Pi…
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…
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…