[RailsConf]
by Jackie Hadley, Communications Associate  May 27, 2009  

Sebastopol, CA, May 26, 2009 — RailsConf 2009, the annual event for the Ruby on Rails community held May 4-7 in Las Vegas, gave new and experienced Rails users practical tools for staying agile and competitive in an industry being transformed by fast-paced innovation. For four intense days, developers engaged directly with more than 100 expert speakers, learning how to exploit the popular framework’s newest features to solve problems and build businesses.

RailsConf, co-presented by Ruby Central, Inc. and O’Reilly Media, Inc., is the largest official conference dedicated to everything Rails. More than 1,300 web developers, IT managers, web-based business entrepreneurs, and others gathered to learn the basics, catch up on the latest developments, and sharpen their expertise, through a variety of presentations and events arranged by Program Chair Chad Fowler and Associate Chairs David Black and Rich Kilmer. At CabooseConf, a free, parallel unconference, skilled Rails coders from all over the world met in one room to work on their Rails projects.

Read the full press release.

read more

[Loud Thinking by David Heinemeier Hansson]
May 11, 2009  

Uncle Bob delivered a compelling keynote at RailsConf last week that put forth the argument that what we need most in programming is more professionalism. I loved the delivery, but I disagree with the conclusion.

I originally never wanted to be a programmer exactly because I thought the only type of programmers that existed where the kind that Bob talked about: The engineers with the proud professional practices that never wavered under pressure.

While I deeply respected that stature, it just never felt like a place that I belonged. I didn't identify with the engineering man or the seriousness of the efforts he pursued. Before I discovered Ruby, I felt in large parts that I was just faking my way along in this world. Here at a brief time for rent.

But that all changed when I found Ruby and a community consisting as much of artists as engineers. People waxing lyrically about beautiful code and its sensibilities. People willing to trade the hard scientific measurements such as memory footprint and runtime speed for something so ephemeral as programmer happiness.

That's where I found an identity that I could finally relate to directly. That's when I finally got really passionate about what I do for a living and started to blossom my own participation.

Now the wonderful thing about this new age of programming is that we need and prosper from both types of programmers. I believe Ruby is such a fantastic community and platform exactly because both types are coming together and sharing with each other. The bazaar is so much richer when the cultural backgrounds of the participants are diverse.

So while I love the idea of Bob's green wristband that reminds him always to do test-first development and his own personal professional oath, that level of adherence has never worked for me. I never had the discipline it takes to fulfill such a lofty goal of professionalism.

Now Bob may think that there's no place for people like me in programming (I sure know plenty of people who do!), I obviously think that would be a mistake. Not just because I've grown rather fond of what I do, but because I've seen so many other unprofessionals just like me come in and add those delicious twists that can really change things.

We aren't perfect. We often swear, act unresponsively, and can certainly be characterized as unprofessional a lot of the time. But I think that together with professionals like Bob, we stand a good chance leaving the world of programming in a better condition than we found it.

read more

[Loud Thinking by David Heinemeier Hansson]
May 01, 2009  

Now that the internet hysteria is dying down, I'd love to explore some of the more concrete things that we could do to actually get more women involved. As I've stated earlier, I doubt simply refraining from having saucy pictures of pole dancers is going to do the trick. If that was all it'd take, it'd be easy beans.

There's going to be a session called Women in Rails at RailsConf next Tuesday, which is bound to be focused a lot of this, but there'll undoubtedly be a lot of good ideas outside of that group as well that we shouldn't wait to get going on. Here are a few ideas to get started with:

Share your discovery story
For the women already in Rails, it'd be great to hear what in particular attracted you to the platform. Highlighting areas of the ecosystem that could get even more support. Perhaps there was an especially well-written introduction that just made everything click. Perhaps a screencast or an interview or something else.

Highlight local communities with women
There are a bunch of local Rails user groups all over the place. If women could get an idea of which groups already had other women present there, it'd probably be a less daunting thought to attend. Knowing that there's at least going to be one other woman in attendance could help a bunch.

Can we pair up with other communities?
Programming communities may indeed often be awfully short on women, but programmers interact with plenty of other professions that are not. I wonder if there are ways where we could get women from, for example, the design community to intermingle on projects like Rails Rumble day. Sorta how the police academy and the nurses in training always throw joint parties in Denmark.

I'd love to hear more and would be more than happy to help promote and push it. Despite the spasm over that one talk and the underlying differences of opinion exposed by it, there's no reason we can't use this as a jumping point to do something about the actual, core issue.

So either email, tweet, or blog your suggestions and stories and I'll use this space to help point it out. Let's treat the low number of women in the community as a bug, cut-out most of the needless bluster, and work on some actual patches. Onward and upwards!

read more

[Loud Thinking by David Heinemeier Hansson]
May 11, 2009  

Uncle Bob delivered a compelling keynote at RailsConf last week that put forth the argument that what we need most in programming is more professionalism. I loved the delivery, but I disagree with the conclusion.

I originally never wanted to be a programmer exactly because I thought the only type of programmers that existed where the kind that Bob talked about: The engineers with the proud professional practices that never wavered under pressure.

While I deeply respected that stature, it just never felt like a place that I belonged. I didn't identify with the engineering man or the seriousness of the efforts he pursued. Before I discovered Ruby, I felt in large parts that I was just faking my way along in this world. Here at a brief time for rent.

But that all changed when I found Ruby and a community consisting as much of artists as engineers. People waxing lyrically about beautiful code and its sensibilities. People willing to trade the hard scientific measurements such as memory footprint and runtime speed for something so ephemeral as programmer happiness.

That's where I found an identity that I could finally relate to directly. That's when I finally got really passionate about what I do for a living and started to blossom my own participation.

Now the wonderful thing about this new age of programming is that we need and prosper from both types of programmers. I believe Ruby is such a fantastic community and platform exactly because both types are coming together and sharing with each other. The bazaar is so much richer when the cultural backgrounds of the participants are diverse.

So while I love the idea of Bob's green wristband that reminds him always to do test-first development and his own personal professional oath, that level of adherence has never worked for me. I never had the discipline it takes to fulfill such a lofty goal of professionalism.

Now Bob may think that there's no place for people like me in programming (I sure know plenty of people who do!), I obviously think that would be a mistake. Not just because I've grown rather fond of what I do, but because I've seen so many other unprofessionals just like me come in and add those delicious twists that can really change things.

We aren't perfect. We often swear, act unresponsively, and can certainly be characterized as unprofessional a lot of the time. But I think that together with professionals like Bob, we stand a good chance leaving the world of programming in a better condition than we found it.

read more

[Loud Thinking by David Heinemeier Hansson]
May 01, 2009  

Now that the internet hysteria is dying down, I'd love to explore some of the more concrete things that we could do to actually get more women involved. As I've stated earlier, I doubt simply refraining from having saucy pictures of pole dancers is going to do the trick. If that was all it'd take, it'd be easy beans.

There's going to be a session called Women in Rails at RailsConf next Tuesday, which is bound to be focused a lot of this, but there'll undoubtedly be a lot of good ideas outside of that group as well that we shouldn't wait to get going on. Here are a few ideas to get started with:

Share your discovery story
For the women already in Rails, it'd be great to hear what in particular attracted you to the platform. Highlighting areas of the ecosystem that could get even more support. Perhaps there was an especially well-written introduction that just made everything click. Perhaps a screencast or an interview or something else.

Highlight local communities with women
There are a bunch of local Rails user groups all over the place. If women could get an idea of which groups already had other women present there, it'd probably be a less daunting thought to attend. Knowing that there's at least going to be one other woman in attendance could help a bunch.

Can we pair up with other communities?
Programming communities may indeed often be awfully short on women, but programmers interact with plenty of other professions that are not. I wonder if there are ways where we could get women from, for example, the design community to intermingle on projects like Rails Rumble day. Sorta how the police academy and the nurses in training always throw joint parties in Denmark.

I'd love to hear more and would be more than happy to help promote and push it. Despite the spasm over that one talk and the underlying differences of opinion exposed by it, there's no reason we can't use this as a jumping point to do something about the actual, core issue.

So either email, tweet, or blog your suggestions and stories and I'll use this space to help point it out. Let's treat the low number of women in the community as a bug, cut-out most of the needless bluster, and work on some actual patches. Onward and upwards!

read more

[Loud Thinking by David Heinemeier Hansson]
May 01, 2009  

Now that the internet hysteria is dying down, I'd love to explore some of the more concrete things that we could do to actually get more women involved. As I've stated earlier, I doubt simply refraining from having saucy pictures of pole dancers is going to do the trick. If that was all it'd take, it'd be easy beans.

There's going to be a session called Women in Rails at RailsConf next Tuesday, which is bound to be focused a lot of this, but there'll undoubtedly be a lot of good ideas outside of that group as well that we shouldn't wait to get going on. Here are a few ideas to get started with:

Share your discovery story
For the women already in Rails, it'd be great to hear what in particular attracted you to the platform. Highlighting areas of the ecosystem that could get even more support. Perhaps there was an especially well-written introduction that just made everything click. Perhaps a screencast or an interview or something else.

Highlight local communities with women
There are a bunch of local Rails user groups all over the place. If women could get an idea of which groups already had other women present there, it'd probably be a less daunting thought to attend. Knowing that there's at least going to be one other woman in attendance could help a bunch.

Can we pair up with other communities?
Programming communities may indeed often be awfully short on women, but programmers interact with plenty of other professions that are not. I wonder if there are ways where we could get women from, for example, the design community to intermingle on projects like Rails Rumble day. Sorta how the police academy and the nurses in training always throw joint parties in Denmark.

I'd love to hear more and would be more than happy to help promote and push it. Despite the spasm over that one talk and the underlying differences of opinion exposed by it, there's no reason we can't use this as a jumping point to do something about the actual, core issue.

So either email, tweet, or blog your suggestions and stories and I'll use this space to help point it out. Let's treat the low number of women in the community as a bug, cut-out most of the needless bluster, and work on some actual patches. Onward and upwards!

read more

[Loud Thinking by David Heinemeier Hansson]
May 01, 2009  

Now that the internet hysteria is dying down, I'd love to explore some of the more concrete things that we could do to actually get more women involved. As I've stated earlier, I doubt simply refraining from having saucy pictures of pole dancers is going to do the trick. If that was all it'd take, it'd be easy beans.

There's going to be a session called Women in Rails at RailsConf next Tuesday, which is bound to be focused a lot of this, but there'll undoubtedly be a lot of good ideas outside of that group as well that we shouldn't wait to get going on. Here are a few ideas to get started with:

Share your discovery story
For the women already in Rails, it'd be great to hear what in particular attracted you to the platform. Highlighting areas of the ecosystem that could get even more support. Perhaps there was an especially well-written introduction that just made everything click. Perhaps a screencast or an interview or something else.

Highlight local communities with women
There are a bunch of local Rails user groups all over the place. If women could get an idea of which groups already had other women present there, it'd probably be a less daunting thought to attend. Knowing that there's at least going to be one other woman in attendance could help a bunch.

Can we pair up with other communities?
Programming communities may indeed often be awfully short on women, but programmers interact with plenty of other professions that are not. I wonder if there are ways where we could get women from, for example, the design community to intermingle on projects like Rails Rumble day. Sorta how the police academy and the nurses in training always throw joint parties in Denmark.

I'd love to hear more and would be more than happy to help promote and push it. Despite the spasm over that one talk and the underlying differences of opinion exposed by it, there's no reason we can't use this as a jumping point to do something about the actual, core issue.

So either email, tweet, or blog your suggestions and stories and I'll use this space to help point it out. Let's treat the low number of women in the community as a bug, cut-out most of the needless bluster, and work on some actual patches. Onward and upwards!

read more

[Chad Fowler's Conference Blog]
by chad  Apr 22, 2009  

Next up in my series of RailsConf speaker interviews is Mike Subelsky, co-founder of OtherInbox and avid SproutCore developer. (SproutCore was used, among other things, to develop Apple’s MobileMe UI and presents a Cocoa-like environment for developing Rich browser-based user interfaces.)

Mike will be presenting both a tutorial on SproutCore development and a session on cloud computing gotchas at RailsConf in a couple of weeks.

How did OtherInbox get started? Was this your first startup? What were the hurdles in moving from consulting to product development?

We wanted to solve our own email overload problem—many people receive heavy volumes of “gray mail” or “bacn” and increasing volumes of more important email like receipts, social networking notifications, confirmations, etc. The other founder of the company, Joshua Baer, had the idea to build a product that would elegantly organize and make sense of this kind of mail, something we would use ourselves that would also help the average person.

This was my first startup; I knew Josh from a project class we had taken together at Carnegie Mellon and was lucky that he invited me to be the cofounder. I had been dabbling and freelancing as a Rails developer for the previous 18 months, and had always been hacking on side projects for my whole career.

Coming from a consulting background, there have been two big hurdles:

1. I didn’t expect product development to have such a different tempo than consulting projects. You live with your code much longer (so you end up maintaining your own legacy code, and don’t have the next greenfield to look forward to), you have to deal more directly with the consequences of mistakes (there’s no one to bail you out), and the risks are higher (because you don’t know when or if your labors will pay off). Thus there are many peaks and valleys of happiness, and it’s not always easy to tell if you are being successful.

1. When time and resources are so constrained, the development team has to become disciplined without sacrificing too much agility. You can’t rely on individual programming heroics to carry the day – otherwise you’re guaranteed to burn out and get sloppy. I haven’t completely overcome this hurdle yet, but I’m reading everything about software development processes that I can get my hands on. I’ve become a huge fan of Eric Ries’ lean startup blog Lessons Learned.

What makes SproutCore interesting and special to you?

SproutCore lets you build real client-server applications, delegating a lot of GUI work to the client that servers currently perform (like rendering HTML views or serving up cached HTML pages). The framework takes concepts that desktop developers have used for a long time and reimagines them for use in web applications. For example, key-value observation and bindings help you eliminate a lot of buggy, ugly glue code, saving a lot of time and aggravation).

It’s special to me because I think this technology has the potential to dramatically change application development in general. The core team has a strong point of view about how Internet clients should be built, and how to make JavaScript and web browsers perform. Writing SproutCore code reminds me of the feeling I got the first time I picked up a book about Rails—“using these tools is making me a better programmer”.

Also, I’ve never liked the feel of Flash, and I love how SproutCore uses only web-native technologies to do amazing things in the browser. PaperCube and MobileMe are examples of SproutCore apps that feel like desktop apps, but don’t require any plugins whatsoever.

Are SproutCore and Rails particularly well suited to one another? If so, how?

I think so—you can point a SproutCore client at any kind of server you want, but I think there’s probably a sweet spot for these two frameworks. Rails makes it easy to write a robust, easily extensible REST API, which makes it really easy to write web clients. SproutCore makes it easy to write robust, easily extensible web clients.

In OtherInbox, our Rails app has to worry about doing is sending back JSON as quickly as possible. The SproutCore app handles most of the user interaction (except for things like the signin page, which we’re keeping server-based for now) and focuses on making the browser experience as fast and fluid as possible. We don’t need to run as many web servers to keep up with our recent growth, because the servers aren’t bogged down generating HTML or RJS updates.

As a happy side-effect, since we built our app this way, someone has reverse engineered our JSON API to make an Android app.

Rails developers will also find many cultural similarities such as emphasis on unit testing and use of generators.

SproutCore’s model marks an extreme departure from the way we traditionally do JavaScript/AJAX applications on Rails. Do you think SproutCore or its patterns will catch on generally or is it bettered toward to a specific niche?

I think if you’re building an app where you need to add just a little dynamic behavior here and there, SproutCore is too much. Toolkits like Prototype and jQuery are much more appropriate. But if you’re making something like MobileMe, PaperCube, or OtherInbox, where the users expect desktop-like fluidity or where the client software can’t always rely on the server for everything, SproutCore will be a big win.

One thing that could help SproutCore catch on generally will be its support for multiple platforms. The 1.0 release candidate includes preliminary mobile support, so we should eventually be able to take the same code base and build it for web browsers, iPhones, Androids, etc., without having to change much. I think that will really turn some heads.

SproutCore’s learning curve appears to be pretty steep. What’s the best way to get into it on day one?

That’s tough, because there aren’t yet a lot of blogs or books to guide you. One of my goals for 2009 is to start contributing more tutorials, because I was lucky to be mentored by Erich Ocean. My best advice would be to get some familiarity with Cocoa because that will illuminate the parts of desktop development that are really different from web development. If you understand key-value observation, key-value coding, and bindings, it will be much easier to learn SproutCore.

Also, the #sproutcore IRC channel and Google group are really friendly places to get guidance.

read more

[RailsConf]
by Suzanne Axtell  Apr 15, 2009  

RailsConf program chair Chad Fowler is conducting a series of speaker interviews in the run-up to the event, which is happening very soon, May 4-7 in Las Vegas. Mosey on over to ChadFowler.com to read more about Neal Ford and Paul Gross of ThoughtWorks, Michael Bleigh, who is Creative Director and Open-Source Activist at Intridea, JRuby and Rubinius leaders Charlie Nutter and Evan Phoenix, as well as Chad’s musing on Rails, Ruby, and open source.

read more

[Chad Fowler's Conference Blog]
by chad  Apr 02, 2009  

Continuing my series of RailsConf Speaker Interviews we have Neal Ford and Paul Gross of ThoughtWorks.

Neal and Paul have been working on some huge Rails applications at ThoughtWorks and will be talking about how they do it in the session, Rails in the Large:How We’re Developing the Largest Rails Project in the World, at RailsConf.

The conventional wisdom these days among the Rails community is that for small projects, Rails beats established technologies such as Java Enterprise Edition whereas for large projects that need to scale, the established technologies scale better in most ways. How different are the problems you face on a massive project in Java versus Rails?

Neal: I think the opposite is true: Java is good for small applications and Ruby is better for large, strategic projects. For small Java projects, there are tons of libraries and frameworks available to kick-start the project. The inherent limitations of Java don’t bite you as much because you’re building a small, simple thing. For large projects, you need a powerful language that doesn’t get in your way at every turn, and you need a framework that allows graceful extension. In fact, for large projects like this, the purposefully leaky abstraction of AciveRecord allows for smarter tuning.

If you pull the string on the back of my neck, I’ll say “Scaling is hard”—no matter what technology you choose. For our current project, we would be able to get better raw execution speed from using Java, but that’s only a small part of what needs to happen to build scalable systems. Lots of things go into building scalable systems, they are just different things depending on technology.

Paul: I actually think Rails is better for both small and large projects. It is incredibly easy to spin up a small Rails project and get going. We have had teams release Rails sites into production in only a couple of weeks. On the other end of the spectrum, the flexibility of Ruby and Rails means that the framework stays out of your way. When Rails is doing something that we don’t want, we can easily extend to get new behavior. For example, we work around ActiveRecord to write better SQL, we work around the MVC pattern to write Presenters when the display logic is sufficiently complex, and we even wrote our test runner to distribute work to make our test suites faster.

In general, however, many of the problems are the same on a massive project, regardless of Java or Rails. For example, we have to constantly strive to keep build times low, database performance high, and consistent patterns throughout the codebase with 20 developers hacking away.

Thoughtworks has been doing Rails consulting for just about as long as Rails consulting has been an option. How has the landscape changed? Are the sorts of companies that are interested in Rails changing from what they were back then? Are the types of projects changing?

Neal: When we first started recommending Rails to clients, we had to bring it up. Now, we have companies that ask us to do Rails projects. As for the types of companies, it’s all over the map: trading firms, auction sites, insurance, even a touch-screen jukebox! I don’t think that the type of company makes any difference, it’s their attitude about their software development. Companies that view software as an important strategic advantage tend to be closer to the cutting edge, and are more tolerant of innovative solutions. Companies that view software as purely overhead always stick with the status quo.

As an example of this, we have one client who created a “standard” Java-based stack for all their software. After spending 1.1 million dollars building a huge Portlet, EJB, Spring, Hibernate, Cocoon, XSLT, etc. application to service 5 users, they realized the unsustainability of that model. That company has since changed their “standard”: all applications must be written in Rails unless suitable justification exists for a different solution.

Paul: Ditto Neal.

What sorts of Web projects would you not want to do in Rails?

Neal:It depends (hey, I’m a consultant!). Really crazily scalable sites (ala Amazon) would be difficult to build in Rails; a lot of attention would have to be paid to lots of things to get it right. We have chosen not to use Rails on some projects where it was on the table, but it was for sites like media sites, with huge numbers of concurrent users, streaming media, and other characteristics. We try hard to ThoughtWorks to not become religious about tools. Some tools are better suited to some jobs.

However, having said this, based on my experience on multiple Rails projects, I have expanded my ideas on where it would be suitable. I’m quite impressed at how linearly Rails can scale up to large-scale projects, as long as you have technical leadership that knows that they are doing.

Paul: For me, the biggest factor against Rails would be the corporate environment. If the company has a policy that everything must be deployed on IIS and use MS SQL Server, perhaps Rails isn’t the best choice. If the company has teams of Java developers who aren’t willing to learn a new language, it is probably best to stick with Java.

How important is testing on a huge project?

Neal: Beyond measure. The only way our code base maintains sanity is through rigorous testing. In fact, this project has spawned several open source testing tools in the Rails community: dust, Selenium Grid, and deep test. Testing is ultra important, and the tech leads on this project have created a really nice workflow around tests. We want unit tests to run really fast, so we use dust and forbid database access during unit tests (we use mocks instead). For functional tests, we enforce the rule that tests do hit the database and you can’t mock anything. For a long time, all the pairs on this project were using Mac Minis, which are underpowered for running lots of tests, which spawned the birth of Deep Test. Deep Test allows you to spawn multiple remote threads to run functional tests. Because our functional tests run inside of a transaction, all our tests are completely orthogonal to one another. When the functional tests start, it spawns multiple processes on several BAMs (Bad-ass Machines) to run the tests. Recently, the whole project was upgraded to 8-core Mac Pros, and we switched Deep Test to use the local processors. Instead of taxing one processor, it pegs all 8, running the entire suite of tests in about 6 minutes.

You have to have testing on all code bases. Period. But it’s even more important in dynamic languages, and especially as you scale up the size of the code base. Insanity would ensue if this code base had no tests; it would collapse in a matter of weeks of trying to maintain it.

Paul: In addition to what Neal said, we use tests to enforce processes that would be forgotten otherwise. For example, if someone forgets to add a translation to a set of files, we have a test that will fail. If someone accidentally creates some bad HTML, we have a test that will fail. Furthermore, on a large team with a large codebase, developers come across code on a daily basis that they know nothing about. Tests act a description of what the code should do and why. It’s a living piece of documentation.

Rails is built on the strong foundation of Convention over Configuration. That to me is the real innovation of Rails. We know it works for small to medium sized projects. Do the opinions of Rails scale?

Neal: Convention over configuration is one of the “obvious in hindsight” features in Rails that has really impacted the whole industry. How many frameworks now brag about this feature? In the Java world, we went down kind of a bad path for a while, where we came just short of building configuration entries for what planet the code was written on. We still use convention over configuration heavily, and not just the Rails version. As much as possible, we try to create everything with sensible, overridable defaults. I don’t really see any end to how much this particular aspect of Rails will scale.

Paul: The obvious answer is sometimes :). One of the great things about Rails is that when the opinions do not scale, they are easily worked around. We can use plugins and gems to radically alter the behavior of Rails, or just do it ourselves.

For example, one opinion of Rails is that all tests hit the database. This opinion does not scale well to the size of our test suite, so we use gems like UnitRecord to cut off the database for unit testing. Another opinion of Rails is to split up tests by models/controllers/etc. We wanted a further split of test type (unit/functional/externals/acceptance). To accomplish this, we simply made our own test folder hierarchy and reworked the standard rake tasks. It was not difficult.

read more

[Chad Fowler's Conference Blog]
by chad  Mar 19, 2009  

Next up in my series of RailsConf speaker interviews is Michael Bleigh, who is Creative Director and Open-Source Activist at Intridea in Washington D.C.

Michael will be presenting Twitter on Rails at RailsConf this year, highlighting a small but growing trend of applications using Twitter as a communication platform.

You work on Present.ly and you’re giving a talk on Twitter apps at RailsConf. Micro-update services is obviously a topic that has you excited. Why is that?

I wasn’t a super-early adopter of Twitter; I honestly think it’s something that takes some time to “get.” Then one day I woke up and realized that without even trying I was getting all kinds of news and information that I might not even have heard otherwise. The beauty of Twitter (and Present.ly for teams and organizations) is that it’s a fast, passive medium: you don’t have to make an effort to keep up to date, it just sort of happens. It works with two-way communication, too; on our team if I have a quick syntax or sanity check question about my code, I post it up on Present.ly and get five responses within three minutes. Micro-updates excite me because I feel like I’m getting smarter just by glancing at growl notifications for a few seconds every couple of minutes while I’m working. It’s effortless.

What are the coolest Twitter applications you’ve seen?

It’s hard to pick out just a few; from a client perspective I’ve been using EventBox lately. It’s integrated Twitter search feeds are really useful for keeping an eye on all of Intridea’s brands (as well as my plugins and open-source projects). While I don’t think anyone has nailed it perfectly yet, aggregators like TweetMeme are interesting in their attempts to bubble up content from the noise. Honestly, I don’t think there are just a couple cool apps; I think that Twitter’s true strength is this really energetic ecosystem around creating cool stuff with the API. That’s what my talk is all about: lowering the barriers to people making cool stuff with Twitter. With the hundreds of apps currently available I still think we’ve only scratched the surface of the utility that Twitter-based applications can provide.

What does it mean to be “Open Source Activist” for a company? Should other companies fill this role?

As the “Open Source Activist” I’m basically just trying to push people to package up what they’re doing and share it with the community, whether it’s through a Ruby gem, a plugin, or just a blog post. My colleagues are making cool stuff all of the time, and sharing that cool stuff with the community is absolutely beneficial for the company, the individual, and everyone who finds it useful. We’ve had clients come to us and when they’re vetting our work it’ll be “Oh yeah, I’ve used that plugin! You guys wrote that?”

I think that every company needs someone who is pushing for that community involvement. Pushing for us to blog more often and release more open source doesn’t just yield intangible reputation benefits: I’ve learned really cool techniques from other people at Intridea that they used for a project on which I’m not currently working. I’m always excited to foster that kind of sharing environment because the rewards are just great. I could go on for hours and I strongly encourage that every company working with Ruby or Rails try to release at least a few open-source libraries and write some blog posts to share your knowledge and expertise with the world at large.

We really believe in putting our money where our mouth is on the open-source front. When we wrote mobile applications for Present.ly on five different platforms it was a no-brainer to me to release them all as open-source. Open source, open APIs and open communication foster innovation in amazing ways, and anything I can do to make that happen more often I will.

Why is Twitter Search special and/or interesting?

Twitter Search is special because it’s intrinsically a different beast than Google and other search engines. It’s not indexing information, it’s indexing conversation, and it does it in real time. If I’m trying to find information about something that happened in the last 24 hours (like who was that old woman on Lost?, I don’t use Google anymore; I turn to Twitter because it will have up-to-the-second information that just isn’t available anywhere else. Obviously it doesn’t replace the usefulness of other search engines, but it opens up whole new channels of information discovery. Honestly search and Twitter are such a natural and amazing fit that it’s surprising that it took a third party (Summize) to come along and realize that potential. I really look forward to where they (and third parties) are going to take the technology in the next year or two.

As I understand it, Intridea started as a consulting group but has quickly developed a set of products that have gotten some positive press. How do you balance consulting and product development? Do they support and feed off of each other?

The balance actually works really well. We have a few people full time on products and then we rotate in services people either part-time or full-time depending on our client engagements at the time. I think it’s been great for both sides of the company to have both services and products: we can try really bleeding edge and experimental things on the products and then bring that knowledge to the client work we do. Likewise, everyone at Intridea on the services side has an almost inhuman work ethic and an ability to juggle several projects at once so when they come on to the products they can pick it up fast and get things done. Consulting has also allowed us to try a number of products without ever having to accept outside funding.

A number of our products also grew out of needs that clients would have again and again. For instance Scalr is a great piece of software (don’t ask me about how it works, it’s over my head!) that gives us the ability to provide amazing scalable cloud hosting to our clients. MediaPlug similarly provides an easy infrastructure that saves our clients time and money. We scratch our own itches with our products and that usually means that there are benefits for the consulting side of our business with every product we make. I’m honored and privileged to work with so many brilliant people and be allowed to pursue so many amazing ideas.

read more

[Chad Fowler's Conference Blog]
by chad  Mar 16, 2009  

Continuing my series of RailsConf speaker interviews, next up is Obie Fernandez

Obie started and runs the Rails consultancy Hashrocket and is the author of the best selling The Rails Way.

At RailsConf, Obie will be presenting a Blood, Sweat, and Rails, which if it’s anything like his talk at last year’s Rails Summit Latin America will no doubt be educational, thought provoking and entertaining. It might even include some Def Leppard music if we’re lucky.

I’ve had dreams of starting my own business and doing my own thing. I’ve learned over time that fear is the biggest thing getting in my way. Is that something you encountered to? How do you overcome it?

I started at least half-a-dozen real businesses between the ages of 15 and 21. Those experiences taught me that I didn’t know enough, either about business or just in terms of plain ole life experience to successfully run a business. So I waited, and waited, almost 15 years until trying again in earnest. All the while wishing I was my own boss, but not feeling ready to make the leap. Fear of failure was a big part of that, as well as many other fears, like not being able to pay my child support obligations.

As for overcoming the fear, I’m guessing that everyone is going to have different tipping points. One commonality though, is probably to give yourself distance from the culture of fear that permeates our world. I did away with my “normal” television watching habits a long time ago—nowadays our television goes weeks without being turned on —most commercials prey on pervasive fear culture of our society. Fear of death, fear of getting sick, fear of accidents, of not being successful enough. Get rid of it!

If you really want to succeed, you have to distance yourself from whiners and low-achievers too. We all have toxic people in our lives, you gotta put space between you and them if you want to overcome the fear and negativity that they breed.

My tipping point to success was building a solid reputation online via my blog and getting so good at what I was doing that I didn’t have to particularly worry about going back to fulltime employment if I happened to fall flat on my face as an independent.

Is there a place for fixed bid projects in the world of Rails consulting? What would you say are the pros and cons? I’ve had very bad experience with fixed bid projects in large companies. I’m wondering if there’s a way to do it right.

I think fixed-bid contracting for custom web applications is a horrible idea, overall. I slept on this question for a few days and dug back in my memory over the last dozen years of consulting: I’ve never heard of anyone being happy with the outcome of a fixed-bid project.

The fundamental problem with fixed-bid is the fluid and living nature of all but the tiniest single-purpose webapps. Once you start development, there are going to be changes necessary. A lot of those will feel “easy” and/or “logical” as if they should have been included in the requirements to begin with. Pressure will be on to include those changes in the original budget, especially if you’re focused on customer service and keeping that client happy. Doubly so if the client is on a tight budget and simply doesn’t have more money to pay. Your hands are tied and odds are you’re going to suffer the consequences.

I don’t think there’s a “right” way to do fixed-bid. You’d have to have a really awesome and understanding client and implement a very rigorous change-control policy that I suspect would encumber the whole development process to a large and unenjoyable degree.

If possible, invest the time in helping your client to understand the nature of variable scope and why it’s in their best interest.

(Note: Obie recently covered this topic on his own weblog here)

Hashrocket currently focuses on Rails projects. Do you see any technologies coming up that you might focus some or all of the team on?

No, not right now. I’m very focused on being the best of the best in one particular niche: large-scale, custom web application development. And I don’t think that there’s any technology that even comes close to what you get with Rails for that. There’s always lots of cool and exciting new things going on, the latest craze seems to be iPhone development. We have a number of people interested in that, but I will not take the company in that direction. It would be detrimental to lose focus from what we do best.

What if I’m a developer who has no dreams of becoming an entrepreneur…what does it buy me to understand sales, marketing, managing client relationships and what-not?

Unless you’re independently wealthy, when it comes to landing a good job and keeping it, you’re always going to have to hustle to promote yourself. Lessons in sales and marketing apply whether you’re selling a product, a company’s services or your own services. What are you doing when you prepare a resume? When you go on an interview? Selling! Get good at it, or suffer the crappy jobs and work environments that you will get otherwise.

As for client relationships, if someone is paying you, they’re your client. Doesn’t matter if you answer to another company or to a manager. The skills of maintaining a healthy relationship and knowing how to properly set expectations apply to everyone.

Agile processes are obviously a cornerstone of your company. How do you draw the line between passion and dogma?

That’s an interesting distinction. Passion is undeniably necessary for success. Without passion, without the ability to inspire others, via your words and/or actions, you’re not going to get very far in life. I believe that Agile software development “just is” and I’m very passionate about that. It just is the way that you do quality software. Not doing quality software? That’s fine, but I won’t work with you. Nowadays Agile is far enough along in mindshare that I don’t feel I have to sell it very much or get anywhere near dogmatic about it. As in everything, I try to keep an open mind and if a better philosophy evolves, maybe it’s “Lean Sofware” or maybe it’s something else, I’ll go with the flow. Until then, I stick to my principles. Passionately.

What’s got you excited these days outside of your programming and entrepreneurial life?

I guess I’d have to say travel, more than anything else. Last year I was blessed to be able to take my kids on a few good vacations, including a fancy three-week trip around the world with stops in South Africa and Far East. This year it’s looking like I’m going to be spending a lot of time in Europe and South America, so I’m definitely excited about that. It’s a big world out there. Get out and see it while you still can!

read more

[Chad Fowler's Conference Blog]
by chad  Mar 10, 2009  

As I did for last year’s RubyConf, I’m starting a series of interviews of speakers at this year’s RailsConf to be held May 4-7 in Las Vegas.

First up are two of my Ruby heroes: Charlie Nutter and Evan Phoenix, leaders of the JRuby and Rubinius projects respectively. Whenever two people with the brains and determination to create a working Ruby implementation get together and want to impart some hard-earned wisdom, it’s well worth listening.

Charlie and Evan will be jointly presenting a session called What Makes Ruby Go: An Implementation Primer at RailsConf. Probably one of the nerdier sessions at the conference, but as you’ll see there are big practical benefits to learning how Ruby implementations work, even for those of us who don’t have the time, skill, or interest to create our own.

This being a Rails conference, what’s the benefit for the average attendee in learning how to make a Ruby implementation? How can learning how to program Ruby itself help us become better Ruby (and Rails) programmers?

Evan: One thing we’re going to focus is not just how to build a ruby implementation, but rather helping people understand how certain things have to be implemented and how they effect you. A great example is the method cache and how Object#extend effects it. This helps educate people on how using Object#extend in their code effects their application.

Charlie: Ruby does a really good job of hiding implementation details and hardware details and platform details. Unfortunately sometimes those are the details that mean the difference between a good application and a great one. My hope with this talk is that Ruby and Rails developers will not only learn how their favorite language is implemented, but how to make better use of its features.

I think it will also be important for Rubyists to understand Ruby implementation details in the future, since there are very real limitations on how many features and how much performance you can squeeze out of Ruby. It’s often too easy for Ruby users to say “just make it faster” when they don’t understand how difficult it may be to do so.

Did you both get into this language/vm implementation thing as a hobby? How do you go from zero to leading a dynamic language implementation?

Evan: Yep, just something fun to work on in my spare time. Following in others footsteps certainly helped the project along. Reading a lot of papers and such on early Smalltalk systems helped give me a good perspective.

Charlie: I got into JRuby after attending RubyConf 2004, where I was amazed that without knowing Ruby I understood every presentation. Since I was firmly rooted in the Java world, and since the JRuby project existed and was being managed by an old friend, I thought I’d try to help out.

Since then, we’ve almost completely rewritten JRuby. We’ve taken it from being the slowest Ruby impl to one of the fastest. Where we could barely run any 1.8 code before, we now have dozens of production users. And we’re not even done yet; we have a great start on 1.9 support, and we have plans that could double performance again over the next couple months. It’s been a wild ride; Ruby and JRuby have changed my life.

How long do you think it will be before we start seeing Ruby 1.9 as the mainstream version everyone (developers and language implementors) is targeting?

Evan: Honestly, I’ve got no idea. Implementors will likely not put too much energy into 1.9 compatibility until a lot of developers start calling for it. Because of all the changes to the APIs, my guess is that people will only start using 1.9 on new projects. So once 1.9 has been established as ‘stable enough’, people will consider using it when they’re getting started on something new.

I think the biggest issue is not new applications, but rather libraries. Today’s rails apps probably use at least 10 gems. Those 10 developers that have to be aware of 1.9 compatibility. If they’re not, it’s likely that those gems will have issues under 1.9. How gem users and gem authors decided to sort out 1.9 compatibility will be something interesting to watch for.

Charlie: Ruby 1.9 is a great step forward for the C implementation, both in its improved performance and and its new features. But Ruby has reached a point in its lifecycle Java reached some years ago: getting people to move to a new version is like pulling teeth. We deal with people on a regular basis still running Java 1.4, even though it’s no longer a supported platform and was first released over six years ago. I don’t think it will be that bad for Ruby 1.9, but it’s a very similar situation.

Ruby has matured, and is being used for mission-critical applications around the world. And along with that maturity comes a need for stability, not just stability in the implementations but stability of features and stability of development processes. Ruby 1.9.1, by most measures the first reasonably “stable” 1.9 release, has been out for less than two months, and it’s unclear how much more its features will change in 1.9.2 and beyond. It’s not battle-tested. It’s unfamiliar. And it will take time for people to start depending on 1.9 to help pay their bills…certainly more than a couple months.

If you had to quit using and developing for Ruby today, what do you think you would focus on?

Evan: Hm. Lately I’ve been interested in Cocoa programming, both desktop and iPhone, so it’s likely I’d play with that to a certain extent.

Knowing me, I’d probably start work on a brand new language and VM for fun. :)

Charlie: I don’t intend to work on JRuby forever, so this is a question often on my mind.

In general, I hope to spend the rest of my life helping open platforms like the JVM “win” against closed, proprietary alternatives. My work on JRuby has been a lot of fun, but I’ve also been trying to prove a point: that the JVM is the best hope for language implementations in the future. Yes, it has its warts, and there’s some work needed to better support dynamic and functional languages. But it’s an amazing piece of technology, already one of the fastest (if not the fastest) managed runtimes in existence. With implementations like JRuby stretching it and nudging it forward, we’ll all benefit…and we’ll be able to use any language we choose.

So if I didn’t work on or with Ruby anymore…I’d probably be doing the same thing for other languages on the JVM. But I like Ruby best so far :)

Creating an implementation of Ruby takes countless hours of work. How do you avoid burning out, and what are you passionate about outside of programming?

Evan: This takes work for me, to avoid burnout. I’ve grown good at telling when I’m starting to go down that road and take action. One of the first things I do is a change of scenery, typically this means working in a coffee shop for the day. I also head up to San Francisco usually once a month to work in the EY office, which helps.

Getting outside for some exercise helps clear my head and reduce stress levels, which also stave off burnout.

I also try and switch gears within Rubinius. Usually my burnout is associated with frustration with one particular aspect of the project, for instance debugging a garbage collector. The project is big enough that I can set that aside for a bit and switch to something more exciting. This helps me keep my brain engaged in the project as a whole, but avoid that frustration.

Charlie: For me, programming is not what leads to burnout. I’ve done this stuff my whole life, and it’s hard for me to not be hacking at any hour of the day. It’s more than my job, it’s my vocation. My risk of burnout comes from the constant arms race with other Ruby implementations, other JVM language implementations, other managed platforms, and so on.

While I’m proud of what we’ve accomplished with JRuby, I feel like I need to keep working at a breakneck pace to continue proving my point. Whenever someone posts a benchmark showing we’re slower, I feel obligated to fix the problem. Whenever someone talks about a new JVM dynamic language or Ruby implementation performing better, I feel like I am personally under attack. I’ve poured my heart and soul into JRuby, and there’s a lot of my spirit in there. If JRuby fails, I fail, so I work hard (maybe too hard) to ensure that doesn’t happen.

Of course, it could be I need to get out more. :)

read more

[Chad Fowler's Conference Blog]
by chad  Feb 08, 2009  

We’re closing the RailsConf call for proposals in just over a week, so if you’ve been procrastinating (certainly my M.O.), now’s the time to start putting something together.

We’re keeping the CFP open longer this year than we have in years past, which is great for the content (Rails 3!!) and hard for the logistics. I think it’s a good trade-off.

If you’re tracking and/or working on Rails 3, we’d especially love to see a proposal. If you don’t have anything solid yet but have a good idea you’d like to try to slot in later, I’d love to hear from you.

We already have a number of talks and tutorials selected, as well as keynotes by Bob Martin, the Rails Core team, and of course DHH.

Both CabooseConf and our code drive were popular hacking sessions last year, so we’re excited about the fact that this year CabooseConf will be run in conjunction with RailsConf this year, providing a free group hacking area (but you have to contribute to an open source project for admission). With the economy sucking the way it is now, hopefully this will give some people an affordable way to join the fun without spending as much money. Thanks to Courtenay and the caboosers for making that happen.

Ron Evans will be organizing a music session this year. If all goes well, we’ll have more equipment than last year (sound system—maybe drums?), so if you’re a musician watch for it and come by to make some noise.

I’m looking forward to holding RailsConf in Vegas this year. The venue is awesome, and Vegas is an easy location to get in and out of. All in all, things are shaping up for this to be yet another in a string of better-than-last-year RailsConfs.

read more

[RailsConf]
by Jackie Hadley, Communications Associate  Jan 29, 2009  

Sebastopol, CA, January 26, 2009 - Want to see Rails 3 roll out? O’Reilly Media and Ruby Central have opened registration for RailsConf 2009, happening May 4-7, 2009, at the Las Vegas Hilton. RailsConf, the official event for the Ruby on Rails community, will showcase the latest developments in the merger of Rails and Merb into Rails 3.

RailsConf, co-presented by Ruby Central, Inc. and O’Reilly Media, Inc., is the largest official conference dedicated to everything Rails. Innovative and successful Rails experts and companies interact at RailsConf through keynotes, sessions, tutorials, panels, and events. The conference provides attendees with examples of business models, development paradigms, and design strategies which enable new arrivals to the Web and Rails to take advantage of this new generation of services and opportunities.

Read the full press release.

read more

[RailsConf]
by Suzanne Axtell, Communications Gal  Jan 07, 2009  

One particularly sweet and surprising piece of tech news happened just before Christmas, traditionally a pretty slow time of year for most important announcements: Rails and Merb will be merged into Rails 3.

Judging from the wealth of comments on both David Heinemeier Hansson’s and Yehuda Katz’s blog posts about it, the news was enthusiastically received by both communities. As one of the nearly 200 commenters on DHH’s blog post announcing the merger wrote, “Rails 3 FTW!”

Over on the Eden Development blog, Chris wrote

Now, the best bits of merb will become Rails 3, and some of the best ruby coders in the business will be working on the framework we use every day. That’s a great thing for Rails users everywhere. Despite the claims of some, it’s not about one set of people ‘winning’ and one ‘losing’. Ultimately the combined codebase is the real winner, and therefore the people that use it, such as companies like ourselves. We’ll certainly do all we can to support the move here.

While tentatively scheduled to release during RailsConf May 4-7 in Las Vegas (an admittedly ambitious timeframe), DHH recently noted that the flow of Merb ideas into Rails 3 is already under way.

The Call for Participation for RailsConf is open until February 17–a much longer period than usual, precisely to accommodate new developments like this.

read more

[RailsConf]
by Suzanne Axtell, Communications Gal  Jan 07, 2009  

One particularly sweet and surprising piece of tech news happened just before Christmas, traditionally a pretty slow time of year for most important announcements: Rails and Merb will be merged into Rails 3.

Judging from the wealth of comments on both David Heinemeier Hansson’s and Yehuda Katz’s blog posts about it, the news was enthusiastically received by both communities. As one of the nearly 200 commenters on DHH’s blog post announcing the merger wrote, “Rails 3 FTW!”

Over on the Eden Development blog, Chris wrote

Now, the best bits of merb will become Rails 3, and some of the best ruby coders in the business will be working on the framework we use every day. That’s a great thing for Rails users everywhere. Despite the claims of some, it’s not about one set of people ‘winning’ and one ‘losing’. Ultimately the combined codebase is the real winner, and therefore the people that use it, such as companies like ourselves. We’ll certainly do all we can to support the move here.

While tentatively scheduled to release during RailsConf May 4-7 in Las Vegas (an admittedly ambitious timeframe), DHH recently noted that the flow of Merb ideas into Rails 3 is already under way.

The Call for Participation for RailsConf is open until February 17–a much longer period than usual, precisely to accommodate new developments like this.

read more

[RailsConf]
by Jackie Hadley, Communications Associate  Oct 17, 2008  

Sebastopol, CA, October 14, 2008–RailsConf 2009 will gather the Ruby on Rails community in Las Vegas May 4-7, 2009, at the Las Vegas Hilton. Ruby Central, Inc. and O’Reilly Media, Inc. have opened the Call for Participation, which will remain open an extra three months in order to accommodate the most up-to-the minute Rails topics. Program Chair Chad Fowler invites proposals for conference sessions, workshops, and panels from Rubyists, hackers, web developers, system administrators, and anyone else with a passion for Rails.

RailsConf, co-presented by Ruby Central, Inc. and O’Reilly Media, Inc., is the largest official conference dedicated to everything Rails. Through keynotes, sessions, tutorials, panels, and events, RailsConf is an interactive meeting ground for the most innovative and successful Rails experts and companies. The conference provides attendees with examples of business models, development paradigms, and design strategies to enable mainstream businesses and new arrivals to the Web and Rails to take advantage of this new generation of services and opportunities.

Read the full release.

read more

[RailsConf]
by Suzanne Axtell, Communications Gal  Oct 14, 2008  

Head to Vegas, baby! Ruby Central and O’Reilly Media have just opened the call for speakers for the 2009 edition of RailsConf. If you’re a hacker, Rubyist, trainer, web developer, Rails system administrator, and/or entrepreneur, submit a proposal to speak at RailsConf 2009. Help make the next RailsConf the best ever!

read more

[Chad Fowler's Conference Blog]
by chad  Sep 12, 2008  

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.

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:

http://www.kuro5hin.org/story/2008/9/5/154535/3669

or his Ruby + Auduino Midi Beat Box Demo:

http://www.vimeo.com/1650051

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:

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.

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!

read more