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!
We have just opened registration for RubyConf 2008! We have also published the schedule.
We have a really cool lineup this year (music, hardware, all of the major implementations, and much more). And, we’re having the conference in a really nice venue. It’s one of those places you plan to come early or stay late for. And during the conference there will be loads of space for whatever “hallway track” activities you might come up with.
Past RubyConfs have sold as quickly as 4 hours after opening registration, so if you’re interested in going you should head over to registration soon.
To keep up to date on what’s happening with RubyConf, follow the RubyConf twitter feed.
See you in Orlando!
It’s that time of year again! We’re now accepting proposals for the 8th International Ruby Conference. RubyConf will be in Orlando, FL this year on November 6-8.
We’re closing the proposal process on Aug. 21, so don’t delay too much if you’re just now seeing this. That’s 10 days from today.
While we’re on the subject, what topics would you be interested in seeing this year?
We had a great time this year at the RailsConf Community Project Code-Drive. Among other things that happened, Evan, Rich, and I created and released gitjour, which is steadily becoming standard Ruby conference must-have software.
So we thought we’d do it again in Europe. If you have an idea for something you’d like to work on, visit the signup page and list it there. If you don’t have an idea, just show up on the tutorial day with a laptop and an open mind.
Also, don’t miss Early Registration, which ends on July 15 and saves you up to €150.
We’re at Ruby Kaigi 2008 and having a great time. Yesterday Rich and I did a panel discussion with Masayoshi Takahashi and Matz on the history of Ruby communities and business outside of Japan.
Today the main conference starts with presentations by Koichi, Charlie, and Evan on YARV, JRuby, and Rubinius respectively. It’s shaping up to be an excellent conference. More later.
The one thing that strikes me so far is that it’s much easier to get here and participate than I thought it would be. If you’ve considered coming to Ruby Kaigi and have never been to Japan, I highly recommend it. Tokyo is easy to get around even without speaking Japanese and the trip wasn’t as harrowing as I expected. Hopefully next year we’ll see the non-Japanese contingent grow and the language barriers blur a little more.
We just wrapped up RailsConf 2008. A lot has been said about RailsConf elsewhere, so as the program chair I’ll just say “thank you” to the speakers, attendees, co-organizers, sponsors, and everyone else for making it the best conference I’ve ever been to.
A lot of exciting things happened. Among the most exciting to me was the public unveiling of Maglev. I’ve had a version of Maglev on my computer for about a month now, but I haven’t been able to talk about it. Now that it has been announced, most things I know are fair game.
Avi Bryant and I met at the first RubyConf. He’s been a fan and friend of Ruby ever since. He happens to be doing mostly Smalltalk these days, but he’s been following the Ruby and (more recently) Rails communities closely. After that first RubyConf, we reconnected while both attending Dick Gabriel’s pilot MFA in Software Development program at UIUC in early 2003. Avi’s been talking since then about running Ruby on a Smalltalk VM. I’ve even started my own attempt once or twice, based on Avi’s ideas of how it could be done.
Given Avi’s interest in Ruby on Smalltalk and that he also created the mind-bending Seaside web application framework, we invited him to keynote at last year’s RailsConf. It was there, in his message from the future keynote, that he made public his belief that Ruby could benefit from being hosted on a mature, dynamic (Smalltalk) VM.
It was also, as I understand it, from that talk that Gemstone got the idea to run Rails.
The conversations started just after RailsConf last year, but it was only a few short months ago that Avi started work on Maglev. That’s part of what makes it so amazing. He and the engineers at Gemstone have gotten a huge subset of the Ruby language running on the Gemstone VM in just three months.
Well, not really, but it’s fun to say.
There are a lot of things to like about what Maglev promises. By far the most interesting to me is Gemstone’s persistence engine.
What’s coolest about how Gemstone’s persistence engine works within the context of Maglev is that it doesn’t feel like a persistence engine. It’s just objects. Everything’s just objects.
If you think about it, the average Rails application is a styled set of CRUD operations on top of an object graph. That’s right, an object graph. The fact that most Rails applications are backed by a relational database is a somewhat-necessary annoyance.
So in circumstances where you don’t NEED an RDBMS, why would you want to litter your pristine Ruby objects with SQL and other RDBMS-related work-arounds? If it were possible to simply instantiate objects and not have to think about the underlying storage implementation at all, wouldn’t that be better?
That’s what Gemstone (and, therefore, Maglev) gives you.
There were questions during the demo about ActiveRecord compatibility. To me, building in ActiveRecord compatibility is worse than a waste of time. Sure, there are things in ActiveRecord which would be useful regardless of the storage mechanism. Declarative relationships and validations are examples. But, when you’re dealing with objects in memory, the idea of a :conditions clause with SQL in it is absolutely unnecessary and unappealing.
Avi and the Gemstone people knew from their understanding of how the VM works that a Ruby implementation on Gemstone would be really fast. They were right. But as I said, the speed of the implementation is secondary to the persistence engine.
That being said, it’s really really fast. On micro-benchmarks, it’s up to 100 times faster than MRI.
As has already been whined about ad nauseam, micro-benchmarks can be misleading. They test very specific parts of the implementation and don’t always give you a picture of what real-world application performance will be like. So, let’s take this approach with the Maglev benchmarks: it’s fast enough. It’s probably a lot faster than MRI. And, we’ve been using MRI for years for real applications.
Good enough. Probably awesome. But at least good enough.
Now is it going to slow down as they start implementing more of the libraries and language features? That’s the conventional wisdom. I say no.
Smalltalk and Ruby are, as Avi has said numerous times, essentially the same language. So the Gemstone VM has been tailor-made for running dynamic language code with closures, continuations, etc. and has been doing it for years. Imagine the process, then, of converting Ruby to Smalltalk. It’s in most cases a fairly straightforward language to language translation.
Where it isn’t as simple as that, Gemstone have a pretty big advantage: they own the VM and they can change it to fit what Ruby needs.
I expect Maglev to get faster as the team starts to spend time on optimization. So far, they’re in the “make it run” phase of the process. Remember, three months in.
Antonio Cangiano also had a look at Maglev recently and has a bit more to say about the specifics of Maglev performance
So what’s next for Maglev? As the Gemstone team has said, their next goal is to start running and passing the Ruby specs created by the other Ruby implementers. They hadn’t prioritized this leading up to RailsConf, because, RailsConf being a web development conference, they wanted us all to see WEBRick running.
But, hey, they have WEBRick running! Have you looked at the code for WEBRick? That’s a lot of Ruby.
I’m looking forward to a report on how well the Ruby specs run at this moment. I think everyone will be pleasantly surprised. And the specs will give the team a clear goal to work toward.
When you don’t NEED an RDBMS (more often than you think) or you need scalable Ruby servers, I think Maglev is going to be an enticing alternative. It’s not going to kill the other implementations. Each implementation has its place. This isn’t a war, after all.
Macruby, JRuby, and IronRuby are for integration. MRI/YARV and Rubinius will compete for the “standard” use cases. Maglev is for big, distributed object stores inside of fast, scalable servers. Think Rails, Adhearsion, or various coordination services running custom protocols on sockets. Don’t run scripts in Maglev. Don’t write desktop apps in Maglev. Just use Maglev to serve tons of requests against billions of objects.
Maglev is good for the Ruby ecosystem just as MRI/YARV, Macruby, JRuby, and IronRuby are good for the Ruby ecosystem. The fact that we (will) have so many alternatives is a good thing.
Congratulations to Evan and the Rubinius team. Rubinius runs Rails!
By this time next year, we’ll see production deployments of Rubinius, with Rubinius quickly becoming the defacto standard Ruby implementation after that. You won’t want to try to deploy your Rails application on it today, but it’s definitely time to give it a look if you haven’t yet.
In my previous post, I asked for examples of great Ruby code. I got emails, comments, instant messages, and twitter messages with suggestions. I’d still like more.
But one really cool suggestion came from an idea Bil Kleb and Peter Provost had. They proposed a Hot or Not -like site for code.
I thought that would be fun, so Bruce and I whipped something up in a couple of hours over the weekend: Slick or Slack?.
It’s not done yet, but we deployed it anyway. My experience helping Ze Frank with Color Wars 2008 has convinced me that deploying things that aren’t done is more often a good idea than not. If for nothing else that for mental health reasons.
What we want to do now is to start collecting potentially “Slick” code snippets. This could mean beautiful code, clever code, code which does something awesome, or whatever. You can also post code that sucks. We just need code to start the tallies running.
When you visit the site, you’ll be presented with two code samples, probably doing totally different things. They might even be in different languages. Your job is to choose the better of the two. If you can’t make up your mind, just hit refresh.
I doubt this is going to unearth great code in the same way that I doubt Hot or Not unearths great people. But I hope it will be fun to play with. It will probably be broken and we know it’s lacking some necessary features to make it more useful and/or fun. Suggestions are welcome. Just don’t take it too seriously.
Tonight, Rich, Marcel and I spoke at the DC Ruby Users Group. Instead of choosing a topic, preparing a set of slides, and droning on about something for an hour we decided to involve the group to help us answer a question. It’s a question I get a lot when I do training with The Pragmatic Studio: “Which Ruby projects should I look at to see examples of great Ruby code?”
I have my standard answers (I’m sure we all do), but two things occur to me about answering such a question. The first is that when asked a question like this, I have a gut reaction. There are names that spring immediately to mind. If I scrutinize these reflex reactions I realize that I haven’t really examined the code I’m thinking of in enough detail to call it great. So though I have some cursory knowledge that makes me pretty sure when I give my recommendations (I’m holding off on naming specifics so as to not influence your answer to this question), I’m not 100% sure which projects contain great Ruby code.
The second realization about this is that some of the names that spring to mind are based on potentially the wrong criteria. I, like all humans, am more likely to mention something popular than something obscure. There is also a Ruby community folklore. Some names are synonymous with “great”. But it’s just folklore. So the knee-jerk reactions are at risk of being heavily influenced by the Ruby popular culture. Looking at how successful popular culture is at picking great music, visual art, fiction, and other artistic mediums, it’s pretty clear that we shouldn’t trust pop culture when making decisions about which projects are composed of “great” code.
So we asked the DC RUG: “Who are the greatest Ruby programmers in the world?”
Then, all together, we looked at code written by the people they came up with.
Some of it was beautiful. Some of it was ugly.
We talked about what made some of it beautiful and some of it ugly. We talked about the importance of writing beautiful code. It was fun.
Anyway, I still don’t have a satisfactory list of great Ruby code. I’d like to build such a list. So, please leave a comment saying the name of an open source Ruby project you feel represents truly great Ruby code.
I’m out in not-so-sunny Cupertino, CA with Dave teaching an introduction to Ruby course for a big company this week. Though I’d always rather be back home with Kelly, we’re having a great time out here. In addition to a lovely dinner with Laurent, Jordan, and Luke from Apple last night, I’ve been having a blast introducing a 15-person group to Ruby for the first time.
I do a lot of advanced level courses and Rails courses, but this one is rewarding in a different way: I’m reminded of how absolutely beautiful the Ruby language is. When you use a language every day it’s easy to forget the things about it that originally roped you in. I’m finding this experience to be an excellent way to relive that through the delighted looks on the faces of the students in this class.
Dave and I are doing this course together for the Pragmatic Studio later this month in Denver. If you or someone you know have been meaning to dig into Ruby, I invite you to come share the joy with us