RubyConf is only a little over 2 weeks away. Time flies!
I’ve been doing a series of interviews with speakers leading up to the conference.
This time is Ben Bleything. Ben is going to be speaking at RubyConf about Ruby and Music
This is going to be a recurring theme, so I’ll get it out of the way here. I think of myself more as a toolsmith than an actual creator. I’m not doing anything with Ruby and music per se… I’m trying to create tools for other people to use.
My creativity manifests in such a way that I’m actually pretty bad at creating “art”. I’m a semi-failed musician, and I don’t have any illusions about programming being the path to making sweet, sweet music. I just think it’s an interesting problem to solve.
I have this vision of showing up at RubyConf in 2010 and having people using the stuff that Giles and Yossef and myself and others create to make some rad music.
I’ve been into electronics since I was 12 or 13. I was the kid who always took stuff apart. I started frequenting my neighborhood Radio Shack around 14, building little lighty-uppy things and noisemakers and the like. I grew bored of that pretty quickly, but I got back into it after college around the time that the Arduino came out.
One of the things that draws me to programming in general is the feeling of empowerment. It’s really cool to be able to make a computer do your nefarious bidding. Now apply that feeling to a physical device and you’re talking about a whole different level of that empowerment.
I’ve said before that I feel like I was born 40 years too late… that I should have been hacking in the ‘60s. Programming for microcontrollers is, in a lot of ways, as close as I can get to that. Starting with bare metal and building an application, even if it’s as simple as blinking a light (the hello world of electronics) is deeply satisfying.
Not yet, no. Both are interesting ideas but getting close to requiring actual musical knowledge, and that’s where I start to get scared :)
I am playing around with hooking up video game instruments (think Rock Band and Guitar Hero) to a computer. This sounds pretty mundane, and I guess that it is… but the trick is that I’ll be passing those through Ruby in order to provide the instruments with a bit more intelligence.
I guess the bottom line is that I’m much more interested in building systems (hardware or software) that more experienced musicians can use as tools… which brings us back to the toolsmith point above.
I’m sure that a computer can generate beautiful music, but I think it would be mostly coincidental. I’m still undecided on whether you can program a computer to always generate beautiful music. It surely happens by chance sometimes, though.
I suspect that there’s interesting results waiting down the path of doing things like markov chaining with music instead of text. Analyzing and chaining music is a significantly more complex problem than doing it with words, but my gut says with the right corpus, you could get some pretty interesting stuff.
Fundamentally, though, I think music has to have soul to be truly great. I want everyone to try to prove me wrong, though!
I’m passionate and excited about everything that catches my interest, honestly. I’ve just chosen not to focus any energy on anything else right now. I want to find ways to share my experience with others… to get people excited about doing the things they thought were too hard.
My electronics presentation last year is a prime example of that. This stuff isn’t difficult, it’s just intimidating. If I can lower the barrier to entry, either by educating or providing tools, then I feel like I’ve done my job. I’m really hoping that my talk this year will do the same for the people interested in music.
RubyConf is coming soon! We’re sold out but you can still get on the waiting list.
I’ve been doing a series of interviews with speakers leading up to the conference.
This time is Glenn Vanderburg. Glenn is a long time Rubyist and dynamic languages fan. He’s also Chief Scientist at Relevance.
The objections to Ruby seem a bit more mature than the objections to Java were. I remember a lot of misunderstanding about Java being “interpreted”, and about GC being “inherently slow”. I also remember people who were outraged that they couldn’t turn the safety features off, like array bounds checking. Those are all rather ridiculous arguments, but many people clung to them for years.
I’m pleased that almost nobody objects to Ruby being open-source. It’s also great that so many people understand that “fast enough” is fast enough, and that you get a lot more benefit from architectural choices than you do from raw language speed. Finally, the Ruby language itself is more mature and stable than Java was then, and that helps a lot.
Nevertheless, there’s one big problem Ruby has now that Java had in 1997: the language implementation is too simplistic, and there’s a lot of room for improvement.
Two of them are already widely understood: bytecode interpretation (which all the new VM projects use) and top-notch garbage collection. But the really big win will come from dynamic optimization based on type feedback, including heavy use of method inlining. JRuby is already getting some of that benefit from the JVM, and I suspect GemStone is using the same techniques to make MagLev fast.
Saying “Ruby is slow, but it’s fast enough” is true for a lot of the things we’re doing today, but it’s also a bit of a cop out. There are definitely tasks for which we’d love to use Ruby, but it isn’t fast enough. The primary motivation for my talk is to spread knowledge about type feedback into the Ruby community. It’s always been a little hard to get information about how the JVM and Strongtalk work, and they have a reputation for being extremely complicated black magic. Many of the details are quite complex, but the basic principles are actually rather simple. My hope is that a few people with good C and assembly language skills will have their eyes opened to the possibilities and start making contributions to the Ruby VM projects.
It’s fascinating technology, but (from what I’ve seen so far) not quite as nice a fit for Ruby as I was hoping for. The v8 team kept a tight focus on exactly what JavaScript needed. The result is that it will be harder to implement Ruby on it than I hoped, and the benefits will be less than I was expecting. It’s a great JavaScript VM, though.
What’s actually more interesting to me is that 2008 seems to be the year of JavaScript VMs. SquirrelFish, TraceMonkey, and v8 are all making big advances in JavaScript performance, using different techniques. And they seem to have begun a competition similar to the WebKit/Opera Acid3 race from earlier this year. That kind of thing might seem like a sideshow, but it highlights core technical issues that are usually hidden from view, and that kind of competition ends up raising standards across the board. JavaScript will certainly benefit from this competition, but it won’t stop there. In the process, previously obscure technical details (not least of which is the fact that a language can be as dynamic as JavaScript and still be fast) will become widely known, and new tricks may be discovered. Ruby and other dynamic languages will certainly benefit from that.
First of all, I don’t think we have to have a “big one that takes over.” Having multiple VMs with different tradeoffs seems to me to be a tremendous advantage for our community, as long as they all pass the same, thorough spec suite. JRuby fills a very important niche and does it really well. There’s some fantastic work in YARV. I fully expect IronRuby to be a big success among people with an investment in the .NET platform. And all the signs are that MagLev will be an awesome option for those who need either commercial support, lots of raw speed, and/or a terrific, scalable persistence system.
That said, I’m watching Rubinius with great interest. I was initially skeptical of the project; it seemed so risky to try to build everything from scratch, from the bottom all the way up through the core libraries. All of the state-of-the-art dynamic language VMs in existence were done by heavily funded large teams of experts. I’m more optimistic today. For one thing, Rubinius has more funding than I realized. Also, I see now that Evan Phoenix has two advantages those earlier teams didn’t have: TDD (which he’s using even on the C++ part of Rubinius) and LLVM, which already has code generation and optimization support for many different machine architectures.
Evan likes to say that because most of Rubinius is written in Ruby, making Rubinius acceptably fast will have to be done in the low-level VM mechanisms, which will benefit all Ruby code, not just the core libraries. That’s exactly what drove the advances we see today in the Self, Java, and various Smalltalk VMs—the core libraries (and in some cases most of the languages themselves) were written in the target language, so the VM became the only avenue for really speeding things up.
But there’s a third advantage Rubinius could have, but doesn’t, at least not yet. Most of the Rubinius contributors are working in the Ruby parts of the system, which is probably where the priority needs to be right now. But soon, the focus will need to shift to the C++ VM. I’m hopeful that others will chip in at that level before too long, and if my talk gets some people started on that, I’ll be thrilled.
The most truthful answer is rather common, and most people won’t find it too interesting: my family and my faith.
I’m constantly reading and enjoying music—in both cases, from many genres. I read a broad mix of science, history, theology, and literature. My favorite author is John McPhee, because he explores topics that seem dull and mundane on the surface, and reveals the fascination within. That’s a great match for me, because I’ve learned that anything is interesting once you begin to understand it.
In preparation for this year’s RubyConf, I’m doing a series of interviews of some of the speakers.
Today’s interview is with Nathaniel Talbott, creator of Ruby’s built-in Test::Unit framework and long time Rubyist. At RubyConf, Nathaniel will be presenting Fear of Programming.
The primary impetus behind my talk this year is my discovery of two things:
These realizations grew out of my being the “business guy” for Terralien for going on three years now, and thus not billing myself out for development work. While doing sales, marketing, project management, etc., is creating in some sense, I’m still a developer at heart and to create I need to code. When I don’t, everything in my life (including all the business stuff) suffers. And the primary hurdle to writing code has been fear.
So to answer your question, yes and no. Yes, a large part of the reason I’ve trended away from talking about code has been because fear kept me from writing code to talk about. No for this year, because I’ve written more Ruby in the past year than I have in a while, and have more to talk about, but I think talking about the fear is more important this year.
And if one made the assumption there won’t be any code in my talk, they might be in for a surprise…
This is actually a big part of my talk, so I don’t want to give away too much. Suffice it to say that my perspective on testing has changed significantly over the past six years, and a lot of that change has to do with fighting fear.
To answer the last question first, it is very worth it. I don’t think test/unit has drawn the ire that RubyGems has, since a testing framework doesn’t have quite the entrenchment that a packaging system does. This has allowed various competitors and add-ons to spring up, giving would-be critics an outlet for their “I could do it better” ideas, and the cool thing is that they often can do it better and we all benefit.
As far as getting test/unit in to the standard library, it was great for me but mostly bad for test/unit. It’s a big plus to tell potential clients that you wrote something in the Ruby stdlib, and it does great things for your Google juice. At the same time, I was already struggling with motivation and productivity when working on test/unit at the time, and what I discovered is that getting a library in the stdlib is a huge demotivator for working on it, at least for me. It becomes much easier to stick with the status quo than to change it.
So if getting “standardized” was good for me and bad for test/unit, how was it for the Ruby community? I think in general it was a good thing. We needed a testing library in the stdlib, and test/unit might not be brilliant but it is solid and fairly simple. Having it there really helped the testing culture in Ruby, and that continues through today. I like to think that Ruby shipping with testing built-in influenced David to ship Rails with testing built-in, and I think that’s fantastic.
I’ll have lots to say about this in my talk, but for now I’ll give two conflicting points of advice: first, you have to defocus. There’s a real tendency to get tunnel vision about the things we “need” and to stop playing with the things we want. Stop worrying about useful and instead explore fun and interesting.
The second piece of advice is to focus. There are so many projects and activities that we can spend time on, we have to choose. Review your list of projects: are they all things you’re excited about working on and that you’re one of the best people to work on? I handed off maintainer-ship of test/unit for exactly this reason: it was distracting me from other things I was more passionate about.
Confused and intrigued? Great, now you’re motivated to come listen to Fear of Programming at RubyConf!
Well, I have four amazing kids (ages 5, 3, 2 and 1) who I love watching grow and learn. We’ll be homeschooling all of them when the times comes, so I have lots of years of learning with them to look forward to. I’m also really passionate about entrepreneurship, and have a few things cooking in that sphere, not the least of which is http://spreedly.com. I also enjoy studying the Bible, and enjoy teaching at our church every few months. So, life is pretty busy, but I’m loving every minute of it!
In preparation for this year’s RubyConf, I’m doing a series of interviews of some of the speakers.
Today’s interview is with author, speaker, and software craftsman, Micah Martin of 8th Light and formerly of Object Mentor. At RubyConf, Micah will be presenting Ruby Kata and Sparring.
Sure it is. When a novelist writes a novel, or a poet writes a poem, aren’t they performing? Their work, their words, have to entertain. They have to communicate ideas, and inspire their audience of readers. When we write code, we have two audiences; the computer and our peers. The computer is not a very demanding audience. But our fellow programmers, they can be very harsh critics. The code we write, if it’s good, will easily communicate ideas to our peers. It will inspire understanding of our intent. And if it’s really good, it will entertain.
Yeah, for the most part. Unclebob did some as well. It’s a great idea that hasn’t seemed to gain much traction. It’s lack of popularity is understandable. A skeptic might describe code kata as “writing useless code by yourself in your free time”. Sounds fun eh?
It’s the same in martial arts. For the lower belt ranks, kata is rarely the activity of choice. Most students would rather kick bags, break boards, and spar with other students. Fortunately in martial arts, instructors influence students to practice kata over and over. With time and experience, students learn to appreciate kata. And once they catch the bug, you’ll find martial artists practicing kata outside of class whenever they get the chance.
Code kata requires discipline, but it offers a deep well of knowledge about our craft. More than most groups, I feel that Ruby programmers understand the need for good coding form, and are more likely to embrace kata.
I don’t know. Maybe it’s because many programmers are programmers because it’s a good career yet they don’t really enjoy programming. It’s hard for me to imagine any musicians who don’t enjoy music or athletes who don’t enjoy their sport.
Having devoted 5 years of my life to martial arts and more than that to software, I can’t help but to compare and contrast the two. What I’ve found is that they’re not so unalike. They both have a scientific foundation yet require copious practice to become proficient. This is my definition of a craft.
Sparring is one facet of martial arts that doesn’t seem to have a counterpart in software. Sparring is great. After all the devotion and practice you invest in your craft, you get to pit your skills against those of your peers and see who comes out on top. It’s a tool to measure your progress and learn your weaknesses. It’s also fun. I hope to see more of this in software.
Besides my family and software, my passions tend to jump around. Martial arts has been a significant passion of mine. I really enjoy playing the guitar. Recently I’ve been playing around with basic electronic components, building little robots. Basketball and soccer keep me active. And as soon as I can spare the time, I’ll learn to fly airplanes.
RubyConf registration is open (and nearly sold out), and I am so excited by the program this year that I thought it would be fun to ask some of the speakers some questions before the conference. So I’m starting a series of informal interviews with RubyConf speakers.
The first one was Greg Borenstein, creator of RAD.
Next up is Ben Scofield, author of Practical REST on Rails 2 Projects and developer at Viget Labs.
At RubyConf, Ben will be presenting All I Really Need to Know* I Learned by Writing My Own Web Framework.
Obviously, there are at least a couple steps between Hello World and writing your own web framework. For me, though, these two practices are (like creating a blog in a new web framework) learning experiences. Hello World introduces the basic syntax of a language; blogs demonstrate how ORM and other techniques are implemented in a given framework. Similarly, custom web frameworks provide a path into still more complicated functionality (network requests and responses, templating, etc.). Building a framework requires a certain level of knowledge of both the programming language and of how the web works, and that knowledge makes other tasks on the web and/or in that language easier.
I do not think that this general point explains the plethora of Ruby web frameworks, however. That, instead, is due to two factors: Rack and Rails. Rack has made it astoundingly easy to try out a new idea for handling web requests (as I’ll talk about in my session), lowering the barrier to entry dramatically. Rails, on the other hand, has motivated the development of new frameworks by both its success and its opinionated nature. Merb was originally developed as a very lightweight alternative to RoR and has since grown into a much less opinionated framework. Waves, on the other hand, is a reaction to a perceived lack of focus on resources in Rails. Most of the new frameworks are reactions to Rails, and to the specific opinions it internalizes. That’s not to say that any of these frameworks are intrinsically worse (or better) than Rails—their genesis is entirely separate from their value, and I think that each of the frameworks out there has lessons to provide.
Definitely; I think that building any software in a given domain is bound to affect how you perceive others’ software written for that same domain, and web frameworks are no exception. Decisions that seem unfathomable at first glance take on an entirely new aspect when you’ve struggled with and addressed the same problems on your own.
The immediate cause of my setting out to write Athena was a disagreement with Rails’ implementation of REST (over collection and singleton resource being handled together, more specifically). That said, I wouldn’t say that I’m terribly critical of Rails; I love using it, and I don’t foresee abandoning it soon. Of course, I think of Athena first as a learning experience, not a viable competitor to Rails (unlike Merb or Ramaze, for instance); if that were not the case, I might have a differerent opinion. For now, however, I’m content to continue to learn from my experiences and hopefully bring them back to Rails when I can (through patches, plugins, and gems).
I think the main reason we’re still building sites this way is that it works pretty darn well. Right now, we can build effective sites quickly, and we’re happy doing it—at the various least, we’re on a peak in the web framework landscape, and there’s a real risk in moving from a satisfactory (if potentially suboptimal) approach to an alternative, in that if you don’t know precisely where that next, higher peak is, you end up trudging through enormous valleys of unpleasant and unproductive work. Many of us made the move from frameworkless PHP or configuration-heavy Java because we used DHH’s fifteen minute blog video as a roadmap to the better place, already well-defined and waiting for us. For the next move, we’ll need something at least as comparable, and until then we’ll stay in this general region (which, all things considered, still has a lot of room for improvement, as Rails gets better and other frameworks adopt these lessons).
With that in mind, however, I do sometimes fear that we’re building our local maximum of joy and productivity to height such that the next thing will have to be even more amazing before it pulls in an audience large enough to really compete with Rails. Of course, that makes the existing alternatives (with their communities) even more important, even if none of them are currently at the point of being the Coming Thing.
Yep—philosophy, actually. I don’t know that I’d describe myself as breaking things down and reconstructing them, though given that my training was in analytical philosophy that does make sense. I prefer to look at my graduate work for inspriation; it was all about integrating distinct fields (cognitive science, philosophy of mind, animal behavior, biological psychology, evolutionary theory) into a cohesive whole. All of that has given me a perspective that’s somewhat different from the standard computer science point of view, I think, and while that can cause problems (since I’m missing some of the fundamental education a CS course of study provides), it more often than not helps me to see and make use of the underlying patterns.
That’s a question that gets a different answer depending on when you ask. At various times over the past few years, I’ve been passionate about dogs, analytic philosophy, comic books, squash, MMORPGs, mythology, cooking, politics, young adult literature, writing, various musical genres, Chinese martial arts, anime, volleyball…. I’m both obsessive and mercurial, which means I get powerfully drawn into subjects for a time, then move on to another fascination. At the moment, I’m holding steady with a few topics: comics and speculative fiction, with a dash of volleyball and philosophy, and I’m continually surprised and enchanted by what my six-month-old daughter does from day to day.
RubyConf registration is open, and I am so excited by the program this year that I thought it would be fun to ask some of the speakers some questions before the conference. So I’m starting a series of informal interviews with RubyConf speakers.
The first one is Greg Borenstein, creator of RAD. Greg also ran the lightning talks at RailsConf 2008.
I had electronics twice, in high school and again in college, as part of general physics classes. I was incredibly bored by the subject and quite bad at it both times. Neither of those experiences had much in the way of hands-on tinkering time. Instead, they were electronics as Science: dry equations, proofs, and word problems, and I never absorbed much of it.
In college I majored in art and wrote my thesis in art history, but what I was really trying to study was how to make things. I’d met there, for the first time, people who were budding engineers and I kind of got infected by their mindset: the constant pull to understand how things worked, not necessarily to reveal the grand truths of the universe, but just to dive beneath the surface of things to learn how they operated enough to change them and make them your own and make new ones. I took classes in painting, printmaking, music theory, book making, anything that I thought would teach me how to build something new—even my run of math classes and my written thesis, I approached as varieties of making. A group of us got money from the school to try to build our own atomic force microscope. We got pretty far designing and constructing it, finally running out of school year while still hung up on the control software.
Also, the summer before my senior year, I interned at the Museum of Jurassic Technology (http://mjt.org). The Museum is like a cross between an pre-renaissance cabinet of curiosities, a contemporary art installation, and a Disneyland ride. It’s filled with amazing exhibits that move and buzz and talk and glow; exhibits on micro-miniature sculpture, folk cures, Athanasius Kircher, Soviet cosmonaut dogs, Innuit string art, stereographic x-rays of flowers, etc. The museum’s founder, David Wilson, used to work in optical effects in Hollywood and is this genius of museum craft: optics, dioramas, lighting, etc. The summer I was there, there was an intern from the Getty cleaning the exhibits so their insides were open, relays and gears, projectors and wires, all spilling out.
All through this, I’d say I didn’t really know electronics and, mostly, I still don’t. These experiences, rather than teaching me much of practical use about electronics really just served to infect me with the bug to learn more. They showed me that electronics could be more than dry Science, it could be magic and it could be a key into how things really worked. Magic that you could make.
After college I wound my way through a series of professions and avocations and eventually wound up in programming. After awhile, the Arduino came along. I started to hear about it from mostly media-oriented friends as something they wanted to get into. Eventually, a group of us got together, ordered a handful of them from Sparkfun and set out to meet once a week to try to teach ourselves to use them. We were very quickly confronted with the fact that we barely knew any electronics. Getting a resistor on the right side of an LED to do the classic Arduino hello world was a challenged for us.
So, I started digging through my old physics textbooks and looking for new ones that were better. We’d set ourselves little projects like playing a melody on a tiny speaker or checking for a pattern on a series of buttons. For the first time, I was learning electronics the way I learned printmaking and Ruby: out of the need to see something I was making actually work.
Finally, the last few years, I’ve been really making progress, but it’s a challenge because the resources are really amazingly poor. Compared with the tools available for learning programming languages (from books to blogs to users’ groups), the hardware story is just brutally bad in this regard for beginners. All the documentation is tied up in data sheets from hardware vendors meant to be used by professional electrical engineers to design projects for mass production. Most of the tutorials, magazines, and books meant for regular people are based around one-off projects that, even if you do gather all the resources together to actually build, will teach you little about the actual underlying principles that you could actually grasp or re-use.
My most successful strategy has usually been getting my hands on real people that actual know this stuff and just asking stupid questions repeatedly until they actually give me an answer that starts at the beginning. That plus a few amazing books (that I’ve been beginning to catalog here: http://github.com/atduskgreg/rad/wikis/books) has really been all that’s helped.
RAD works by translating some Ruby code into C which can then be linked against the full Arduino software library and handed off to avr-gcc for compilation down into the hex that can be uploaded to an Arduino. The Arduino software library is built around two main functions: setup and loop; setup runs once when the Arduino starts up and after that, loop runs repeatedly. RAD takes a different translation strategy for each of these.
For setup, RAD provides a base class ArduinoSketch. Much like Rails’ ActiveRecord::Base, classes that inherit from ArduinoSketch gain a bunch of class methods for doing a lot of the configuration and setup necessary for programming the Arduino: declaring pins as input or output, setting up helpers for working with various pieces of hardware such as LCDs and Servos, etc.. RAD uses some metaprogramming magic and some seriously lo-fi string concatenation to use these class methods that you call in your sketch to generate a big chunk of C code: a lot of function signatures, library includes, and other boilerplate as well as the setup function itself
Now, the loop function is another story. RAD looks for a method on your subclass of ArduinoSketch called loop. It takes that method and hands it off to a library called RubyToC, which spits back the C equivalent. RubyToC was written by Ryan Davis and Eric Hodel and probably some of the other Seattle.rb geniuses as part of the Metaruby Project whose goal was to rewrite Ruby entirely in Ruby. I think that project might be some form of dead at this point since all of those guys now work for Engine Yard on Rubinius. Anyway, from RAD’s point of view, RubyToC is mostly magic alien technology that does exactly what we need (though we have made our own extensions by subclassing some pieces of the RubyToC machinery in order to implement some additional features (such as times blocks) in ways that might not be satisfactory for the general project of converting Ruby to C, but work great for us with our constrained compiler targeting).
We do the same thing with any other additional helper methods you’ve written on your class, glue the whole thing together and send it off for compilation.
The Arduino is obviously highly resource constrained (it only has 16k of flash program memory) and so a lot of people ask about the bloat that’s caused by the inefficient C we generate. We work had to keep that down (I can’t find the current stat for it, but I’ll get back to you with that) and I think that it’s worth it for the great increase in ease of use that Ruby provides over C++.
Right now, the answer to that is probably one of JD Barnhart’s recent projects. Either his Ruby on Bells:
or his Ruby + Auduino Midi Beat Box Demo:
JD came along like manna from open source heaven this summer: I hadn’t had much time to work on RAD for awhile and had accumulated a laundry list of requested features, both my own and from other users. As soon as I put RAD up on GitHub, JD forked it and added nearly all of them. He announced his work by putting a great screencast up with that Bells demo and a tour of his improvements. He makes great screencasts! I’ve since brought him on as part of the RAD core team and he has, along with Bryan Riley from wulfden.org, been a big part of the fast rate of improvement RAD’s been seeing lately.
Right now, we’re in the middle of doing a few desperately needed refactorings on the RAD code base, mostly consolidating things so we can clean up some of the fallout of all the recent improvements and make things more flexible and easier to improve.
After that I have two main directions I want to take the project: the educational route and the ‘modern software tools’ route.
I mentioned in response to you first question how much Arduino helped make it possible for me to learn electronics in the first place by giving me a fun environment where I could experiment and build things rapidly and easily. The whole purpose of RAD is to take this project even further: to let you program the Arduino in Ruby instead of C because it’s even faster and more fun. I think RAD can be a great tool for lowering the barrier to learning hardware hacking. Ruby’s expressiveness makes RAD code examples extremely readable. I’m trying to foster a culture around RAD of really good documentation: not just of RAD itself, but of exactly the hardware that is usually only explained through arcane data sheets. The RAD wiki is already starting to house some good material like this:
http://github.com/atduskgreg/rad/wikis
and I’m hoping to see (and write) more and more as the project progresses. Just as some of the great books that helped me learn Ruby (the Pickaxe book, _why’s Poignant Guide, Chris Pine’s Learn to Program) also taught me the basics of good programming itself, I’m hoping that RAD can be an entry point into creating some documentation for the wider world of hardware hacking.
The other big direction I want to take the project is to build all the ‘modern software tools’: we’ve become used to in Rubyland, but are still extreme luxuries in embedded C++ such as testing, simulation, code stats, etc. One of the great things about having written a program for your Arduino in Ruby instead of C++ is that once you’ve done so, we can use Ruby’s metaprogamming power to interpret that program in different contexts to accomplish different goals. So, just through writing a different implementation of ArduinoSketch, we can run your sketch in a test framework that will help you make sure that it actually does what you want it to or in a graphical simulator that lets you play with different hardware connections and code combinations to see what will happen before having to actually build out circuits or connect your real Arduino at all. Both of these projects (the testing framework and the simulation app) are in extremely nascent stages right now, but I hope to pour more time into them as soon as we finish up our current refactor.
Music has been a passion for me for a long time. I play in an indie rock band called At Dusk (http://atduskmusic.com) that’s been together for almost 10 years. We’ve toured around the country and put out 3 albums (with a fourth and final one on the way). I also run a local Portland music non-profit called PDX Pop Now! that puts on a free local all-ages music festival every year, produces an annual compilation of all local music, and helps do advocacy for kids’ access to music.
I’m also passionate about art—I think part of my energy for electronics comes from surplus created from drawing less the last couple of years. Artists like Jennifer and Kevin McCoy (http://flickr.com/photos/mccoyspace/), Joseph Cornell, Thomas Demand (http://www.thomasdemand.de/), Chandra Bocci, and David Hockney, et al inspire my interest in physical computing stuff as much as anything on the technical side does.
This year, I’ve discovered a passion for cooking. I’ve been working from Alice Waters’ books which are all about simple preparations of the best seasonal local produce so that’s lead me to start learning about gardening as well. That, combined with my adoption of biking as my main form of transportation starting a few months back, as made me feel like I’ve finally become the typical northwesterner, which must mean that it’s time to shake things up!