Mike just reminded me that the Early Bird discount is soon to expire for our January Rails Studio in Denver. If you’ve been thinking about attending a Rails Studio and work for a big company, here’s a tip I learned the hard way: corporations usually budget for training and then when it’s time to “save some dollars” in later quarters, they cut the training budget first. In my big corporate days, that bit me more than once, stopping me from going to conferences (OOPSLA) and training (XP Immersion, which I later eventually made it to).
So if you’re interested in doing any training this year, I’d recommend that you do it in the first quarter before the budget is pulled out from under you. Unless you work for an enlightened company with a healthy revenue stream.
The Rails Studio has the added advantage (for me) of being held at a beautiful, resort-like hotel with a bunch of really nice fitness facilities and excellent food. Last time we taught there, I was actually sad to go back to our full service gym at home.
If you’re coming and either into getting in shape or music, let me know. Maybe we can arrange some after-hours activities.
So… Rails and Merb are going to be merged into Rails 3. (link)
Has hell frozen over?
(it has in Portland the last week)
I’m curious about how the revised core team will incorporate the library-agnostic view points into Rails without increasing the complexity for configuration. For example, being able to use a different ORM is great, but at the same time, one of the things that I have really liked about Ruby on Rails was that it did make decisions ahead of time for you. Conventions over Configuration and all that jazz. While they intend to keep these defaults, I really wonder how much more configuration will be involved. Be that as it may, Rails and Merb are run by some of the best developers I’ve ever known… so I am sure these decisions will not be made without some deep consideration.
Rails application don’t all look and smell the same, but it’s nice to know that there is consistency across all of our client applications. What I’m concerned about (from an efficiency standpoint) is that this could lead to project-diversity at the cost of experimenting. Pre-Rails, the development teams that I was a part of was constantly trying out new libraries from client project to project, but this came at a huge cost. We weren’t able to leverage our experience with previous projects like our team does with Ruby on Rails currently. (hell, I even helped write two different ORMs in the two years before Rails for PHP… and still wasn’t satisfied)
But, this isn’t so much a technical problem as much as a people problem. The thing is… is that Rails helped solve a people problem with a technical answer. Having testing, consistency, and other best practices built-in did the world a huge favor. ...and all it took was someone like DHH to throw his opinion out there and stick to it. It took me nearly a full year to really embrace a lot of these conventions, but in the end.. it paid off.
While I do feel that it’s in developers best interests to try out new approaches, I just don’t think it should be on your clients dime. This was part of the reason why I quit my last job to start Planet Argon full-time. I really wanted to get away from that cycle.
Since we (Planet Argon) adopted Ruby on Rails four years ago, we’ve been able to build off of every project we had worked on before. We since adopted things like RSpec and JQuery, but our team decided on these changes after someone took the initiative to experiment with these on internal and personal projects. Having this foundation has freed up a lot of our time to focus on other issues as a team, like Interaction Design, Usability, and client collaboration.
As far as Merb itself, I honestly haven’t tried to do anything with it since about 0.2/0.3. I gave up quickly though because the documentation didn’t help me get anywhere and my time is valuable. I’ve since seen that documentation has improved drastically, but I haven’t been able to prioritize the time needed to really play with it. With Merb being merged into Rails 3, it means that I really should spend more time exploring it as we might be able to leverage some of it’s benefits without as much of an investment.
Much of the lack of great interest in Merb was because I felt Rails had consistently provided our team with a solid foundation for a majority of our internal and client applications. The old saying, “if it ain’t broke, don’t fix it.” Not to say that others haven’t expressed a lot of excitement about Merb and it’s benefits, I just didn’t see there being enough of a productivity gain to warrant the time investment required to really learn and use a new framework… and the one thing that I have had trouble with was that it didn’t sound like Merb encouraged a default set of libraries. I could be totally wrong, but that’s been the perception I’ve had based on how it was branded.
But… the best part about this for you, me, and the Rails community? Is that I don’t need to register robbyonmerb.com anytime soon. ;-)
I hope that you’re all having a great end to 2008 and am excited to see all the energy in the Ruby/Rails/Merb community. I suspect that between these two (now-merged) teams, we’ll have an even better platform to develop web applications on. I believe this is great news and I’m all in favor of seeing the Ruby community conquer these challenges that lay ahead.
Anyhow, I’m just thinking out loud. What are your thoughts?
Bob Zurek, the Chief Technology Officer at EnterpriseDB interviewed me a few months ago for their new Database Radio podcast. It finally was published last week. Bob and I had a nice conversation about PostgreSQL and it’s community, our use of PostgreSQL with Ruby, Ruby on Rails, and development tools/methods.
After releasing the new RubyURL API, I decided that it was time to look around at libraries to interact with it. I came across a new Ruby gem from John Nunemaker named, HTTParty, which aims to make it easy to talk to XML and JSON-based web services. Be sure to read John’s announcement of HTTParty.
So, I decided it might be fun to introduce more people to the gem by showing you all how to use it to talk to the new RubyURL API.
Install HTTParty
Before we get started, you’ll need to install the HTTParty gem with the following command:
~ : sudo gem install httparty
Password:
When you HTTParty, you must party hard!
Successfully installed httparty-0.1.6
1 gem installed
Installing ri documentation for httparty-0.1.6...
Installing RDoc documentation for httparty-0.1.6...
Great! Now that we’re ready to party hard, let’s build something.
Talking to the RubyURL API
The RubyURL API currently supports both XML and JSON, which are each supported by HTTParty. The great thing about HTTParty is that all you need to do is include it in a class and you’re able to quickly talk to remote services.
In this following example, we’re going to create a new class called Rubyurl.
class Rubyurlend
What we’ll want to do now is include the HTTParty library. (note: you’ll need to require both rubygems and httparty gems and I’ll skip those lines in following code samples)
class RubyurlincludeHTTPartyend
The HTTParty provides a few class methods, which we can use to configure our library. We’ll go ahead and specify the base_uri, which we’ll set to rubyurl.com.
class RubyurlincludeHTTPartybase_uri'rubyurl.com'end
Now that our class is setup to talk to the Rubyurl.com site, we’ll want to add a new method which we can use to communicate with the RubyURL API. We’ll call this shorten as we’re using RubyURL to shorten long URLs… right?
class RubyurlincludeHTTPartybase_uri'localhost:3000'def self.shorten(website_url)endend
Our new shorten method will expect us to provide it with a website url, which we’ll want RubyURL to return a shortened URL for. The PATH for the API that we’ll want to talk to is: /api/links, which we’re expected to pass XML or JSON to.
Here are two examples of using the RubyURL API with HTTParty.
RubyURL via JSON w/HTTParty
We’re going to use the post method that is provided with HTTParty to send a request to /api/links.json. As you can see, we’re providing the original website url to the web service.
class RubyurlincludeHTTPartybase_uri'rubyurl.com'def self.shorten(website_url)post('/api/links.json',:query=>{:link=>{:website_url=>website_url}})endend
The great thing about HTTParty is that you can use XML without changing much.
class RubyurlincludeHTTPartybase_uri'rubyurl.com'def self.shorten(website_url)post('/api/links.xml',:query=>{:link=>{:website_url=>website_url}})endend
So… there you have it. HTTParty makes it extremely easy to interact with various web services that work over HTTP. I’d encourage you all to take a few minutes to experiment with it and see what crazy ideas that come to mind during the process. :-)
As I’ve mentioned here before, when working on web applications built with PHP, whether custom-rolled or drupal-driven, I often find myself missing various tools from the ruby kit. I’ve talked before about using capistrano with non-ruby code, but lately it’s been rspec and its stories that I’ve been craving.
I’m aware of PHPSpec and have played [...]
As you are no doubt aware, mad scientist Giles Bowkett’s has a rad drum machine/crazy MIDI thing called Archaeopteryx. A common complaint with Archaeopteryx (hereafter “arkx”) is that it only runs on OSX.
The cool thing is that Giles used Topher Cyll’s code from Practical Ruby Projects. You may recall that I recently published a little library called MIDIator that also uses Topher’s code to provide easy access to MIDI on the major operating systems.
I’ve never really said this in public, but the real reason I wrote MIDIator in the first place was to become e-famous by making arkx work on Windows and Linux. So, it is with extreme hope for e-fame pleasure that I have pushed my branch of arkx that converts it to use MIDIator for MIDI interaction.
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.
You spoke about Ruby and electronics last year. How did you get into electronics? What got you excited about it?
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.
Being into electronics, have you ever tried to build your own electronic instrument or have the computer play a real instrument with motors?
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.
Can computers generate beautiful music? Dance beats seem easy. What about jazz improvisations? Classical music? Pop songs?
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!
Ruby, electronics, and music is a lot of ground to cover. Are you passionate and excited about anything else in particular outside of these?
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.
I was just looking at my FeedBurner statistics and noticed that my feed readership has gone up by approximately 100 in the past year. Then I looked at my blog and realized I hadn’t posted anything Ruby-related in 2008. Then I remembered that I’m a Ruby programmer and decided to release some software for the express purpose of blogging an announcement.
Okay, not really. Well. The last part is mostly a lie. I guess. On to the point.
Background
Earlier this year a small publishing concern called Apress (that you may have heard of!) published a most interesting book. It was Practical Ruby Projects, by the lovely and talented Topher Cyll. There’s a link on his page if you want to get it.
Practical Ruby Projects is the book that I have always wanted to write. I would have called it Stupid Ruby Tricks myself, but that’s neither here nor there. The subtitle is “Ideas for the Eclectic Programmer”, and that really gives you an idea of the flavor of what’s inside.
The second chapter is entitled “Making Music with Ruby”, and is a gentle introduction into writing code that can play music. The chapter is based around building an app that can play songs written in simple notation. One of the really awesome things that Topher did, though, was to supply code to interface with the MIDI subsystems on Windows, Linux, and OSX.
Around this same time, Giles Bowkett’s sweet project Archaeopteryx was starting to take off. Giles had also taken both code and inspiration from Practical Ruby Projects, but he had only grabbed the OSX parts. That’s fine, I thought, because I’m on a mac and it works for me.
Then, people started complaining. Not really complaining, but definitely whinging about wanting to play with Archaeopteryx but being stuck on inferior platforms. There was also an issue with the fact that Giles demos Archaeopteryx hooked up to Reason, and Reason costs like $500. You don’t have to use Reason, though, as Shay Arnett so deftly demonstrated at the Hoedown. I have more to say about this, but you’re going to have to wait for RubyConf.
Aaaaaanyway, I decided that I was going to take Topher’s code and bundle it up for you, the masses, to consume. This was made possible in large part by Apress’s total awesomeness in releasing all the code from Practical Ruby Projects under the MIT license. I took his code, refactored it a little bit, wrote some specs and examples, and published it as MIDIator.
Thanks to Tobi Reif for pointing out the error in the above example!
You should hear a half-second of middle C. Now, to be fair, I’m leaving out all the information about how to get a working MIDI setup on your machine. I’ll be blogging about that later, though, so if you don’t know how just keep your eyes peeled.
Where Can I…
You can get MIDIator at GitHub or RubyForge, or install it via gems as shown above.
Future blog posts about MIDIator will be tagged, so you can use this link to get all the news that’s fit to blag.
There’s more coming. In the next few days I’ll be showing you how to get MIDI working on your system. Then I’ll be speaking at RubyConf with Giles and Yossef Mendelssohn. I’ll definitely post some stuff related to my talk around the conference, but you’re going to have to wait for the really fun stuff.
The Ruby HTTP libraries used by Rails do not perform any santization of the values of their HTTP Headers. This can lead to Response Splitting and Header Injection attacks in certain circumstances where user-provided values are written into response headers. These malformed values can be used to set custom cookies, and forge fake responses to users if your application uses any of the user submitted parameters to construct HTTP headers without sanitizing.
A common scenario where this can be exploited is where your application takes a URL from the query string, and redirects the user to it. To mitigate this common scenario new versions of Rails will be released which sanitize the values passed to redirect_to. However you will still need to take care when writing other values to response headers.
The new versions which will contain the fixes are:
2.0.5
2.1.2
2.2.0
These releases are not available immediately, so in the event that it’s infeasible or inconvenient for your application to sanitize the user-supplied values it passes to redirect_to, patches are available at the following locations.
This time is Glenn Vanderburg. Glenn is a long time Rubyist and dynamic languages fan. He’s also Chief Scientist at Relevance.
There was a time when Java was cool and new like Ruby is now. I remember drawing criticism for thinking it was “ready for the Enterprise”. You wrote one of the first books about Java. How does the current state of affairs with Ruby and dynamic language adoption differ from what was happening with Java back then?
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.
What would you say are the top 2 or 3 features the Ruby world could steal from existing VMs?
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.
What do you think about Google’s new V8 VM? Do you think there’s much to learn from it? Will we see a serious Ruby implementation on it?
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.
Do you think any of the in-progress Ruby implementations is poised to be the big one that takes over the Ruby world? Why or why not?
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.
What are you passionate about outside of computer programming?
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.
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.
You’ve spoken at 7 out of 7 RubyConfs and you’re about to speak at your 8th. I’ve noticed your topics are veering farther and farther away from programming in Ruby. Is this because you’re afraid?
The primary impetus behind my talk this year is my discovery of two things:
I get lethargic/depressed/unproductive/unhappy when I’m not spending
a significant portion of my time creating.
I often don’t create because I’m afraid to start.
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…
At the first Ruby conference, you spoke about Lapidary, which became Test::Unit. Are you as zealous about testing as you were when you created Lapidary? Why or why not?
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.
How does it feel having your first Ruby project in ruby’s standard library? As one of the creators of RubyGems, I’m no stranger to harsh criticism of my Open Source code. Have you encountered a lot of this? Is it worth it?
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.
How can I be more productive? I would love to be one of these people who churns out useful libraries once every few weeks and keeps them maintained.
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.
What are you passionate about outside of computer programming?
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!
You’re speaking about exercises to improve your coding skills. From what I know about the ideas you will present, they are very tactical and performance-oriented in nature. We don’t usually think of programming as a performance activity. Is it?
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.
Dave Thomas did a series of “code kata” many years ago. Is the kata portion of your talk a continuation of those same ideas?
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.
Everyone who calls his- or herself a musician knows that practice is essential. The same with sports and other disciplines. Why don’t many programmers practice?
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.
Some call programming engineering. Others call it art. Still others call it craft. You’re using a fighting metaphor. What’s your take on the subject?
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.
What are you passionate about outside of computer programming?
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.
So first you do Hello World, then you write your own framework? Is this why there are so many Ruby web frameworks popping up?
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.
You seem to spend most of your working time in Rails. Has writing your own framework affected how you understand Rails? Has it made you more appreciative? Or critical?
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).
Why do you think we’re still stuck doing faux MVC web development? Is it time for something new?
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.
You have a degree in Linguistics or something, right? Is this why you like to deconstruct things and put them back together? How has your nontraditional training and education affected the way you learn and approach your job?
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.
What are you passionate about outside of computer programming?
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.
You’re working on RAD (Ruby Arduino Development). How did you get into electronics in the first place? I’ve never had training myself and always been interested but intimidated. Was it hard?
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.
Can you explain architecturally how RAD works? How do you get Ruby code to “compile” to code that can run on an Arduino microprocessor?
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++.
What’s the coolest thing you’ve done or seen done with RAD?
Right now, the answer to that is probably one of JD Barnhart’s recent projects. Either his Ruby on Bells:
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.
Where do you see yourself taking RAD next?
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:
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.
What are you passionate about outside of computer programming and electronics?
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 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.
Consistent hashing is a scheme that provides hash table functionality in a way that the addition or removal of one slot does not significantly change the mapping of keys to slots. In contrast, in most traditional hash tables, a change in the number of array slots causes nearly all keys to be remapped. By using consistent hashing, only K/n keys need to be remapped on average, where K is the number of keys, and n is the number of slots.
We’ve just deployed the initial version of an API for RubyURL. It makes it really easy to create RubyURLs and is now open to the public. Should it end up being abused, we’ll consider introducing an API KEY for authenticating and tracking abuse.
In the meantime, you can now start to use the RubyURL API.
I’ll be updating the ShortURL gem in the coming days (unless someone else wants to patch it first wink) to take advantage of new API, versus how it’s currently creating RubyURLs.
I took a little time today to update the API and extend it to support JSON. So… you can now use the RubyURL API to generate RubyURLs via JSON. (see commits)
Enjoy! If you’re using RubyURL via the new API, I’d love to hear about it. :-)
Do you find yourself copying and pasting the same code from Rails application-to-application as new projects start? Our team has a handful of projects in development right now and we notice that some of these reusable components tend to get out of sync when we bounce between projects. So, we’re making an effort to spot these and are creating a handful of plugins so that we can keep them updated between projects. (I’m sure that a lot of you do this as well)
In an effort to share some of our patterns, we’ll try to release them into the wild for others to use and perhaps if you have better patterns to offer, we’re always interested in improving our approach.
Introducing Flash Message Conductor
Over the years, our designers and developers have approached the management of flash messages several different ways. In Rails, the default way to add something to a flash message is to do something like this in your controller.
flash[:message]="You have successfully signed in to your account."
What we began doing a while back is to create a few controller helper methods:
add_message("You have successfully signed in to your account.")add_notice("You've Got Mail!")add_error("Oops! Something got fucked up!")
Really, nothing too crazy here, just a pattern that our developers have preferred to managing our application’s flash messages.
Okay, so now for the part of the puzzle that we aimed to make consistent across our projects. Rendering flash messages would usually result in several lines of conditionals in our application layout to check if the flash had any values assigned to it. As we worked with our HTML/CSS designers to define a consistent pattern, we moved our code into a helper for rendering flash messages.
With Flash Message Conductor, we just need to pop in the following into our application layout.
<%= render_flash_messages %>
If we had called add_message, it’d render the following:
<divid="flash_messages"><pclass="message">You have successfully done XYZ...p>div>
Or, should you have called add_error, it’d render the following:
<divid="flash_messages"><pclass="error">Oops! Something went bonkers!p>div>
What we’ve done here is defined a consistent pattern for our designers and developers to follow. We’ll always have a div container that will use a p tag to display the flash messages with a CSS class value that maps to the type of flash message that we’re displaying. This makes it easier for us to reuse the same flash message styling (and tweak if necessary), but we know that it’ll produce the same HTML across our applications.
Installing Flash Message Conductor
Like most modern Rails applications, you can install with:
Then all of our helper methods will be available to your application. We’ve also included an example CSS file, which you’ll find in the plugin directory.
Anyhow, we’ve posted the plugin up on GitHub for you all to use, if you’d like to adopt a similar approach. If you have any alternative patterns that has helped your team, do share and I’m looking forward to sharing some more of ours in the near future.
If anything, hopefully this will inspire those of you who find yourself copying/pasting artifacts from application-to-application to extract that code into it’s own reusable plugin. :-)
The ruby-security team have published an advisory about a DoS bug affecting REXML users. Almost all rails applications will be affected by this vulnerability and you’re strongly advised to take the mitigating steps recommended in the advisory. If you’re not sure whether your application could be affected, you should upgrade.
The announcement contains details describing the monkeypatch solution, but to summarise:
Require the file from environment.rb
require ‘rexml-expansion-fix’
Versions 2.0.0 and later
Copy the fix file into RAILS_ROOT/config/initializers, it will be required automatically.
This fix is also available as a gem, to install it run:
gem install rexml-expansion-fix
Then add require ‘rexml-expansion-fix’ to your environment.rb file. The manual fix and the gem are identical, if you have applied one you do not need to apply the other.
I was going through an older project of ours and cleaning up some specs and noticed how often we were doing the same thing in several places. When we started the project, we didn’t get the benefits of shared groups. Now that we have some time to go through and update some of our older specs, I’ve been trying to take advantage of the features currently available in RSpec. One feature that I haven’t seen a lot of mention of by people is shared groups, so I thought I’d take a few minutes to write up a quick intro to using it.
To pick some low-hanging fruit, let’s take an all-too-familiar method, which you might be familiar with… login_required. Sound familiar? Have you found yourself stubbinglogin_required over and over throughout your specs?
If you’re requiring that a user should be logged in when interacting with most of the application (as in the case of an administration section/namespace), you might want to consolidate some of your work into one shared specification group. The basic premise behind this is that you can write a typical describe block and load it into any other spec groups that you need. For example, in our case, we’ll need to stub login_required in several places. We can set this up in one shared group and reference it wherever necessary.
For example, here is what we’ll start off with.
describe"an admin user is signed in"dobefore(:each)docontroller.stub!(:login_required)endenddescribeAdmin::DohickiesController,'index'do...
However, the new describe block isn’t accessible from the block at the bottom of the example… yet. To do this, we just need to pass the option: :shared => true as you’ll see in the following example.
describe"an admin user is signed in",:shared=>truedobefore(:each)docontroller.stub!(:login_required)endend
Great, now we can reference it by referring to it with: it_should_behave_like SharedGroupName. In our example above, this would look like:
describe"an admin user is signed in"dobefore(:each)docontroller.stub!(:login_required)endenddescribeAdmin::DohickiesController,'index'doit_should_behave_like"an admin user is signed in"before(:each)doDohicky.should_receive(:paginate).and_return(Array.new)get:indexend...enddescribeAdmin::DohickiesController,'new'doit_should_behave_like"an admin user is signed in"before(:each)do@dohicky=mock_model(Dohicky)Dohicky.should_receive(:new).and_return(@dohicky)get:newend...
That’s it! Pretty simple, eh? We can now reference this shared group in any describe blocks that we want to. A benefit to this approach is that we can make change the authentication system (say, we decide to switch it entirely and/or even just change method names, set any other prerequisites necessary when an admin is signed in), we’ll have a single place to change in our specs. (tip: you can put these in your spec_helper file)
You can learn more about it_should_behave_like and other helpful features on the RSpec documentation site.
If you have any suggestions on better ways of handling things like this, please follow up and share your solutions. I’m always looking to sharpen my tools. :-)
Update
In response, Bryan Helmkamp suggests that a better solution is to define a method in our specs like, for example: build_mock_user_and_login. then calling it in our before(:each). So, maybe the approach above isn’t the most ideal method but I did wantt o draw some attention to it_should_behave_like. I suppose that I need a better example.. another post, perhaps? :-)
I recently packed up everything I own and moved. I'd lived in my old place for about nine years and I have the packrat gene on both sides of the family tree, so I had a lot of crap to sort through to figure out what to move and what to trash, as well as which box what should go in. Now that I'm here in the new place, I've had to sort through the remaining stuff to figure out where it all goes. So you might appreciate that sorting has been on my mind a lot lately. (See? It's a topical tie-in. I don't do those often, so I hope it wasn't too awkward.)
I've also been working on an application that does a lot of sorting to prioritize tasks in a workflow. These items often need to be sorted based on multiple criteria, such as how long an application has been waiting for approval, how many times a customer has been called recently, etc. We also have to sort names that have anywhere from two to four components (Hispanic names can have both paternal and maternal names instead of just a surname).
