I’ve decided to travel less this year. Since my job involves a lot of travel, this mostly translates into going to less conferences.
So for 2010 I so far have only one conference on the agenda (other than those I’m co-organizing): RubyConf India.
I’m speaking at the event and also helping out on the proposal committee along with Pratik Naik and Ola Bini. So far the program is shaping up well, and I’m excited about the conference.
If you’re looking for a combined technical and cultural education experience, I highly recommend going to RubyConf India. Kelly and I lived in Bangalore several years ago and absolutely loved it there. We can’t wait to get back to our second home. Bangalore was a culture shock at first, but that’s another strong reason to go. For us, it went from culture shock to comfort. Bangalore certainly didn’t change to make that happen—we did.
So, while it’s hectic, noisy, and sometimes shocking, Bangalore is a beautiful place which had a profound effect on me. When I was there, I couldn’t find any other Ruby programmers. It will be really exciting to go back to an entire conference devoted to Rubyists.
Registration will be opening in the next couple of weeks. Follow RubyConfIndia on twitter for announcements. Bangalore men milenge?
My friend and fellow Rails developer John Lannon, lead developer at http://resonantvibes.com, was mugged last night while picking up dinner for his wife. He didn’t have anything on him to give to the robbers and they shot him point blank in the chest.
His friends and teammates at Resonant Vibes are raising money to help with his recovery. Please consider helping a fellow developer and a remarkable individual who (not that anyone does) really does not deserve to be in the predicament he’s in now.
Thanks
Yesterday I asked on Twitter whether anyone was successfully using is_paranoid in a Rails application, because I had confused myself into thinking it couldn’t possibly work.
The problem I was having wasn’t is_paranoid’s fault, but it turns out it actually can’t do what I wanted it to do in its native state. The explanation of why is something I thought a number of Rubyists might benefit from hearing, so here it is.
Briefly, an explanation of is_paranoid: if you declare an ActiveRecord model to be paranoid, whenever you attempt to delete that model, is_paranoid will instead set a flag which indicates that the record is deleted. is_paranoid uses default_scope to filter out soft-deleted records in your queries. So you can act as if records are deleted without actually removing the rows. If is_paranoid is new to you but sounds familiar, you might be thinking of acts_as_paranoid, which is Rick Olson’s original implementation of this idea.
What I wanted to do for the specific application I’m working on is to declare that every model should inherit the is_paranoid behavior. Easy enough, I thought, given the way these things typically work in Rails’ inheritable accessor setup:
But when I tried to destroy an instance of (for example) Person, the regular ActiveRecord destroy code was invoked and the records were being actually destroyed. Bummer.
So I cracked open the code to is_paranoid and found this perfectly reasonable idiom:
At this point, after pretending I was an idiot for a few minutes, I realized that this code was indeed incapable of doing what I wanted it to do.
Some of you already know why. For the rest of you, let’s talk about how Ruby’s mixins fit into its inheritance mechanism.
Maybe it’s just me, but when I think of something getting “mixed in” to something else, I imagine the two things becoming intertwined. So, the natural assumption when mixing a module into a Ruby class would be that the methods of the module get intertwined with the Ruby class. And for the HelloWorld of mixins, that indeed appears to be the case:
But if you start mixing modules that implement methods the class also implements in, things don’t go quite as smoothly:
Instead of “Overridden do_something” as some might expect, this code prints “Doing something in Thing”.
Why?
Because when we mix a module into a Ruby class, we’re not actually intermingling the methods of the module and the class. Instead we’re inserting the module into the class’s inheritance hierarchy. A good way to see how this works is by using the “ancestors” method:
When a method is called on an instance of SubThing, you can see that it is looked up first in SubThing’s class, then Thing’s class, then in IneffectiveOverride, and so on.
(I used yuml to generate this. Cool site!)
To further demonstrate that mixins don’t really get “mixed in”, notice what happens when you try to include a module at multiple points in the inheritance hierarchy:
If a module is already present at a higher point in the hierarchy, it won’t be mixed in again.
So is_paranoid was apparently built without the goal of being able to mix it into ActiveRecord::Base. Sounds reasonable to me.
I had a great time at Ruby Nation this weekend. After my presentation I got a number of questions asking about things I referenced during the talk. Here’s an attempt to point to some of them. If you weren’t there, you won’t have any context but feel free to follow the links anyway You might find something interesting.
Bureau of Labor Statistics Time Use Survey
Karlheinz Stockhausen whose name I accidentally used when trying to refer to Stockholm Syndrome.
Pat Metheny – “Whenever young guys ask me what they should do to get better, I always say try to be the worst guy in whatever band you’re in. That’s the secret.”
Drepung Gomang Institute (for whom we translated Hindi)
What Would You Rather Be Doing?
Ask Sunday – the company I mentioned that helped me with research
Arduino – I used this to create the interface to my exercise bike
Gosu – The game library I used to write my exercise bike “game”
Building Games with Ruby – Andrea O.K. Wright’s presentation on game development in Ruby
You and Your Research – Richard Hamming at Bell Labs
Fixing Broken Windows: Restoring Order And Reducing Crime In Our Communities
Discussion Panel: Women in Rails
14 Worst Health Mistakes Even Smart Women Make – Referenced Harvard and University of Texas studies on the effect of the company you keep
How to Call Attention to Your Music – Derek Sivers free ebook
15 Things Kurt Vonnegut Said Better Than Anyone Else Ever Has Or Will
Next month, I’ll be presenting at Ruby Nation in my home away from home, Northern Virginia (I seem to spend almost as much time there as I do in Colorado). The presentation will be something like this:
What should the career path of a programmer be? How do you know what you’re aiming for? What defines success?
Many of us started out assuming the answers to these questions included slowly climbing a corporate promotion structure, ultimately becoming a people or project manager and no longer a programmer.
But we didn’t get into software development so we could fill out spreadsheets and attend status meetings. We got into software development because we were excited about it. We wanted to be creative and to build great things.
From the author of The Passionate Programmer, this session will walk through how a software developer can not only succeed but work toward building a remarkable career. We’ll draw examples from business, the arts, music, and sports. By the end of the presentation, we will have laid out a structured framework for radically succeeding in the software industry.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Yesterday, I asked Twitter:
Rails programmers: what's an example of one thing you find in other people's Rails
code that you (almost) always consider to be wrong?Quite a few people responded, and several asked if I’d post the aggregated answers. Here’s an attempt. I don’t necessarily agree with everything here. I’d love to hear more of these in the comments.
@briandoll’s response was particularly interesting:
extensive logic in views. If the erb would be ugly and harder to pull off in
haml, it's likely a code smellThis is something I always liked in Java about XMLC:http://www.enhydra.org/tech/xmlc/index.html. It was really hard to end up with a mess of co-mingling code and views, because you would have to work harder in XMLC to even make that possible. Amrita used to have that same characteristic, but I’m not sure it still does (or if it is even maintained).
I’ve been resistant to HAML but maybe it’s time to give it another look.
Also, as @mbleigh points out, any code in views is suspect. CSS should be in CSS files. Javascript should be in Javascript files.
Enough said.
@seancribbs singles out auto-generated tests. I’ll have to agree with him.
@alancfrancis says simply “rspec”. Certainly not a religious topic. I’m sure if you could somehow see in the code which editor someone used, we’d see a lot of TextMate, vi, and emacs in the responses.
@brendanbaldwin says “I’ve seen Polymorphic Associations and Single Table Inheritance abused to absurdity.”
As have I. I’ve also abused them to absurdity myself. The storage of a column called “type” which holds a class name is a pretty good indicator that something fishy is going on. It’s fishy but not always bad. I think, though, that any time you use it you should ask yourself more than once if it’s the right solution. Databases don’t do what they do best as well when you have lots of STI and polymorphic associations.
I once had to debug a problem with a commercial, Java-based portal product. The mail module was failing, saying it couldn’t connect to the mail server. In fact, what was happening was my login credentials were incorrect. Guess what the offending JSP looked like (pseudo-code)?
try {
// do everything here
} catch (Exception e) {
out.println("Unable to connect to the mail server") ;
}Exceptions are one of the only places in Ruby where you rely on checking the classes of objects to do useful and interesting things. Never rescue Exception unless it’s at the end of a stanza in which you’ve already handled one or more other exception types.
UPDATE: from the comments, Phil didn’t mean what I typed here:
That’s not actually what I meant. Never rescue Exception unless you’re working with code that abuses the
exception hierarchy. In normal circumstances you should be rescuing StandardError instead. If you rescue
Exception, you won’t even be able to ctrl-c your way out of your code(!) among other problemsMore info on his weblog here
class Potato
attr_accessor :size
end
potato = Potato.new
potato.instance_eval do
size = 123
end
p potato.size
# => nil
Ruby’s assignment to method-call syntax sugar only works when there’s an explicit receiver (such as self.size = 123)
Always run with -w. Fix any warnings you see. A good place to see them is when running your application’s comprehensive test suite.
RJS, render, nested named routes, and ERb are the targets of these criticisms.
validates_uniqueness_of is a strange critter. It’s so easy to use, that it’s tempting to slap it into your code and consider it good enough. But even the documentation for it warns you:
Using this validation method in conjunction with ActiveRecord::Base#save
does not guarantee the absence of duplicate record insertions, because
uniqueness checks on the application level are inherently prone to race
conditions.Here are some rules of thumb:
If you create your own configuration file and have to check RAILS_ENV, you’re not using a built-in facility of Rails.
OK, so this isn’t really what he meant. But it’s a good thing to think about. If you find yourself writing a lot of code to do something simple, you might be missing something Rails (or a plugin) provides. I’ve seen a whole lot of wheels re-invented inside models, controllers, and helpers. Part of Rails mastery is learning to ask yourself, “Shouldn’t somebody have already done this for me by now?”
Seems like if you find yourself manipulating Ruby’s load path in your Rails code, you’re doing something strange. If you don’t know you’re doing something strange, then you’re probably doing something wrong.
As Dave Thomas likes to say “Don’t not use positive logic” (or something like that).
Can someone tell me where the use of ”!!true” crept into the Ruby vernacular? Sure, it’s syntactically valid to do:
!!!!!!!!!!!!!!!!!!ok?
But why?
It’s April 1st, so my mind wanders to the hypothesis that someone introduced this and started spreading it as an elaborate joke. If so, well played. Is there a good use of this idiom I’m missing?
ActiveRecord migrations define a simple API/DSL for doing schema manipulation. But when they run, they’re just Ruby classes and methods executing within the Rails environment. So you can do anything you like in that context.
Sometimes people use migrations to load seed data. Pratik doesn’t like this.
I’m on the fence on this one. In small doses it doesn’t strike me as a horrible practice. That being said, I don’t tend to do it. I’d be interested in hearing opinions.
I guess it depends on what you’re doing with the parameters. Sometimes long parameter lists on GET requests are a sign that there are two actions’ worth of work happening in a single action. Or that you’re doing something that belongs behind a POST or PUT. This one doesn’t bother me as much as it does @Adkron.
if foo.save && bar.save
if bar fails to save, foo doesn’t. Oops. I’ve seen this more than once in the wild.
Obtrusive Javascript and RJS are the themes here.
What’s the worst use of RJS you’ve seen? I love RJS. I may be one of the offenders. Doesn’t feel like it (usually) though.
Smalltalk people, as a collective culture, seem to get this right. Kent Beck documents a simple pattern in his Smalltalk Best Practice Patterns called “Compose Method”. He says that one way to determine whether a new method is required is whether all of the code in a given method operates at the same level of abstraction. That’s a simple but powerful rule. Think about it next time you’re coding and I think you’ll agree.
I agree with Mike on this one. I don’t tend to write any comments, so I may be on the anti-comment side to a fault. My goal is always to write code that is clear enough that comments don’t add anything. If you name everything well and keep your classes, modules, and methods short, you’re already going to make comments redundant in a lot of cases.
Whenever I see a comment inside a method definition, I consider it a bad sign. In most cases, whenever you encounter a comment inside a method, it’s a marker for where code should be extracted into a new method.
If you’re writing a framework, the rules are different. But most of the time as a Rails developer, you shouldn’t be writing a framework.
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.
RubyConf is only a little over 2 weeks away. Time flies!
I’ve been doing a series of interviews with speakers leading up to the conference.
This time is Ben Bleything. Ben is going to be speaking at RubyConf about Ruby and Music
This is going to be a recurring theme, so I’ll get it out of the way here. I think of myself more as a toolsmith than an actual creator. I’m not doing anything with Ruby and music per se… I’m trying to create tools for other people to use.
My creativity manifests in such a way that I’m actually pretty bad at creating “art”. I’m a semi-failed musician, and I don’t have any illusions about programming being the path to making sweet, sweet music. I just think it’s an interesting problem to solve.
I have this vision of showing up at RubyConf in 2010 and having people using the stuff that Giles and Yossef and myself and others create to make some rad music.
I’ve been into electronics since I was 12 or 13. I was the kid who always took stuff apart. I started frequenting my neighborhood Radio Shack around 14, building little lighty-uppy things and noisemakers and the like. I grew bored of that pretty quickly, but I got back into it after college around the time that the Arduino came out.
One of the things that draws me to programming in general is the feeling of empowerment. It’s really cool to be able to make a computer do your nefarious bidding. Now apply that feeling to a physical device and you’re talking about a whole different level of that empowerment.
I’ve said before that I feel like I was born 40 years too late… that I should have been hacking in the ‘60s. Programming for microcontrollers is, in a lot of ways, as close as I can get to that. Starting with bare metal and building an application, even if it’s as simple as blinking a light (the hello world of electronics) is deeply satisfying.
Not yet, no. Both are interesting ideas but getting close to requiring actual musical knowledge, and that’s where I start to get scared :)
I am playing around with hooking up video game instruments (think Rock Band and Guitar Hero) to a computer. This sounds pretty mundane, and I guess that it is… but the trick is that I’ll be passing those through Ruby in order to provide the instruments with a bit more intelligence.
I guess the bottom line is that I’m much more interested in building systems (hardware or software) that more experienced musicians can use as tools… which brings us back to the toolsmith point above.
I’m sure that a computer can generate beautiful music, but I think it would be mostly coincidental. I’m still undecided on whether you can program a computer to always generate beautiful music. It surely happens by chance sometimes, though.
I suspect that there’s interesting results waiting down the path of doing things like markov chaining with music instead of text. Analyzing and chaining music is a significantly more complex problem than doing it with words, but my gut says with the right corpus, you could get some pretty interesting stuff.
Fundamentally, though, I think music has to have soul to be truly great. I want everyone to try to prove me wrong, though!
I’m passionate and excited about everything that catches my interest, honestly. I’ve just chosen not to focus any energy on anything else right now. I want to find ways to share my experience with others… to get people excited about doing the things they thought were too hard.
My electronics presentation last year is a prime example of that. This stuff isn’t difficult, it’s just intimidating. If I can lower the barrier to entry, either by educating or providing tools, then I feel like I’ve done my job. I’m really hoping that my talk this year will do the same for the people interested in music.
RubyConf is coming soon! We’re sold out but you can still get on the waiting list.
I’ve been doing a series of interviews with speakers leading up to the conference.
This time is Glenn Vanderburg. Glenn is a long time Rubyist and dynamic languages fan. He’s also Chief Scientist at Relevance.
The objections to Ruby seem a bit more mature than the objections to Java were. I remember a lot of misunderstanding about Java being “interpreted”, and about GC being “inherently slow”. I also remember people who were outraged that they couldn’t turn the safety features off, like array bounds checking. Those are all rather ridiculous arguments, but many people clung to them for years.
I’m pleased that almost nobody objects to Ruby being open-source. It’s also great that so many people understand that “fast enough” is fast enough, and that you get a lot more benefit from architectural choices than you do from raw language speed. Finally, the Ruby language itself is more mature and stable than Java was then, and that helps a lot.
Nevertheless, there’s one big problem Ruby has now that Java had in 1997: the language implementation is too simplistic, and there’s a lot of room for improvement.
Two of them are already widely understood: bytecode interpretation (which all the new VM projects use) and top-notch garbage collection. But the really big win will come from dynamic optimization based on type feedback, including heavy use of method inlining. JRuby is already getting some of that benefit from the JVM, and I suspect GemStone is using the same techniques to make MagLev fast.
Saying “Ruby is slow, but it’s fast enough” is true for a lot of the things we’re doing today, but it’s also a bit of a cop out. There are definitely tasks for which we’d love to use Ruby, but it isn’t fast enough. The primary motivation for my talk is to spread knowledge about type feedback into the Ruby community. It’s always been a little hard to get information about how the JVM and Strongtalk work, and they have a reputation for being extremely complicated black magic. Many of the details are quite complex, but the basic principles are actually rather simple. My hope is that a few people with good C and assembly language skills will have their eyes opened to the possibilities and start making contributions to the Ruby VM projects.
It’s fascinating technology, but (from what I’ve seen so far) not quite as nice a fit for Ruby as I was hoping for. The v8 team kept a tight focus on exactly what JavaScript needed. The result is that it will be harder to implement Ruby on it than I hoped, and the benefits will be less than I was expecting. It’s a great JavaScript VM, though.
What’s actually more interesting to me is that 2008 seems to be the year of JavaScript VMs. SquirrelFish, TraceMonkey, and v8 are all making big advances in JavaScript performance, using different techniques. And they seem to have begun a competition similar to the WebKit/Opera Acid3 race from earlier this year. That kind of thing might seem like a sideshow, but it highlights core technical issues that are usually hidden from view, and that kind of competition ends up raising standards across the board. JavaScript will certainly benefit from this competition, but it won’t stop there. In the process, previously obscure technical details (not least of which is the fact that a language can be as dynamic as JavaScript and still be fast) will become widely known, and new tricks may be discovered. Ruby and other dynamic languages will certainly benefit from that.
First of all, I don’t think we have to have a “big one that takes over.” Having multiple VMs with different tradeoffs seems to me to be a tremendous advantage for our community, as long as they all pass the same, thorough spec suite. JRuby fills a very important niche and does it really well. There’s some fantastic work in YARV. I fully expect IronRuby to be a big success among people with an investment in the .NET platform. And all the signs are that MagLev will be an awesome option for those who need either commercial support, lots of raw speed, and/or a terrific, scalable persistence system.
That said, I’m watching Rubinius with great interest. I was initially skeptical of the project; it seemed so risky to try to build everything from scratch, from the bottom all the way up through the core libraries. All of the state-of-the-art dynamic language VMs in existence were done by heavily funded large teams of experts. I’m more optimistic today. For one thing, Rubinius has more funding than I realized. Also, I see now that Evan Phoenix has two advantages those earlier teams didn’t have: TDD (which he’s using even on the C++ part of Rubinius) and LLVM, which already has code generation and optimization support for many different machine architectures.
Evan likes to say that because most of Rubinius is written in Ruby, making Rubinius acceptably fast will have to be done in the low-level VM mechanisms, which will benefit all Ruby code, not just the core libraries. That’s exactly what drove the advances we see today in the Self, Java, and various Smalltalk VMs—the core libraries (and in some cases most of the languages themselves) were written in the target language, so the VM became the only avenue for really speeding things up.
But there’s a third advantage Rubinius could have, but doesn’t, at least not yet. Most of the Rubinius contributors are working in the Ruby parts of the system, which is probably where the priority needs to be right now. But soon, the focus will need to shift to the C++ VM. I’m hopeful that others will chip in at that level before too long, and if my talk gets some people started on that, I’ll be thrilled.
The most truthful answer is rather common, and most people won’t find it too interesting: my family and my faith.
I’m constantly reading and enjoying music—in both cases, from many genres. I read a broad mix of science, history, theology, and literature. My favorite author is John McPhee, because he explores topics that seem dull and mundane on the surface, and reveals the fascination within. That’s a great match for me, because I’ve learned that anything is interesting once you begin to understand it.
In preparation for this year’s RubyConf, I’m doing a series of interviews of some of the speakers.
Today’s interview is with Nathaniel Talbott, creator of Ruby’s built-in Test::Unit framework and long time Rubyist. At RubyConf, Nathaniel will be presenting Fear of Programming.
The primary impetus behind my talk this year is my discovery of two things:
These realizations grew out of my being the “business guy” for Terralien for going on three years now, and thus not billing myself out for development work. While doing sales, marketing, project management, etc., is creating in some sense, I’m still a developer at heart and to create I need to code. When I don’t, everything in my life (including all the business stuff) suffers. And the primary hurdle to writing code has been fear.
So to answer your question, yes and no. Yes, a large part of the reason I’ve trended away from talking about code has been because fear kept me from writing code to talk about. No for this year, because I’ve written more Ruby in the past year than I have in a while, and have more to talk about, but I think talking about the fear is more important this year.
And if one made the assumption there won’t be any code in my talk, they might be in for a surprise…
This is actually a big part of my talk, so I don’t want to give away too much. Suffice it to say that my perspective on testing has changed significantly over the past six years, and a lot of that change has to do with fighting fear.
To answer the last question first, it is very worth it. I don’t think test/unit has drawn the ire that RubyGems has, since a testing framework doesn’t have quite the entrenchment that a packaging system does. This has allowed various competitors and add-ons to spring up, giving would-be critics an outlet for their “I could do it better” ideas, and the cool thing is that they often can do it better and we all benefit.
As far as getting test/unit in to the standard library, it was great for me but mostly bad for test/unit. It’s a big plus to tell potential clients that you wrote something in the Ruby stdlib, and it does great things for your Google juice. At the same time, I was already struggling with motivation and productivity when working on test/unit at the time, and what I discovered is that getting a library in the stdlib is a huge demotivator for working on it, at least for me. It becomes much easier to stick with the status quo than to change it.
So if getting “standardized” was good for me and bad for test/unit, how was it for the Ruby community? I think in general it was a good thing. We needed a testing library in the stdlib, and test/unit might not be brilliant but it is solid and fairly simple. Having it there really helped the testing culture in Ruby, and that continues through today. I like to think that Ruby shipping with testing built-in influenced David to ship Rails with testing built-in, and I think that’s fantastic.
I’ll have lots to say about this in my talk, but for now I’ll give two conflicting points of advice: first, you have to defocus. There’s a real tendency to get tunnel vision about the things we “need” and to stop playing with the things we want. Stop worrying about useful and instead explore fun and interesting.
The second piece of advice is to focus. There are so many projects and activities that we can spend time on, we have to choose. Review your list of projects: are they all things you’re excited about working on and that you’re one of the best people to work on? I handed off maintainer-ship of test/unit for exactly this reason: it was distracting me from other things I was more passionate about.
Confused and intrigued? Great, now you’re motivated to come listen to Fear of Programming at RubyConf!
Well, I have four amazing kids (ages 5, 3, 2 and 1) who I love watching grow and learn. We’ll be homeschooling all of them when the times comes, so I have lots of years of learning with them to look forward to. I’m also really passionate about entrepreneurship, and have a few things cooking in that sphere, not the least of which is http://spreedly.com. I also enjoy studying the Bible, and enjoy teaching at our church every few months. So, life is pretty busy, but I’m loving every minute of it!
In preparation for this year’s RubyConf, I’m doing a series of interviews of some of the speakers.
Today’s interview is with author, speaker, and software craftsman, Micah Martin of 8th Light and formerly of Object Mentor. At RubyConf, Micah will be presenting Ruby Kata and Sparring.
Sure it is. When a novelist writes a novel, or a poet writes a poem, aren’t they performing? Their work, their words, have to entertain. They have to communicate ideas, and inspire their audience of readers. When we write code, we have two audiences; the computer and our peers. The computer is not a very demanding audience. But our fellow programmers, they can be very harsh critics. The code we write, if it’s good, will easily communicate ideas to our peers. It will inspire understanding of our intent. And if it’s really good, it will entertain.
Yeah, for the most part. Unclebob did some as well. It’s a great idea that hasn’t seemed to gain much traction. It’s lack of popularity is understandable. A skeptic might describe code kata as “writing useless code by yourself in your free time”. Sounds fun eh?
It’s the same in martial arts. For the lower belt ranks, kata is rarely the activity of choice. Most students would rather kick bags, break boards, and spar with other students. Fortunately in martial arts, instructors influence students to practice kata over and over. With time and experience, students learn to appreciate kata. And once they catch the bug, you’ll find martial artists practicing kata outside of class whenever they get the chance.
Code kata requires discipline, but it offers a deep well of knowledge about our craft. More than most groups, I feel that Ruby programmers understand the need for good coding form, and are more likely to embrace kata.
I don’t know. Maybe it’s because many programmers are programmers because it’s a good career yet they don’t really enjoy programming. It’s hard for me to imagine any musicians who don’t enjoy music or athletes who don’t enjoy their sport.
Having devoted 5 years of my life to martial arts and more than that to software, I can’t help but to compare and contrast the two. What I’ve found is that they’re not so unalike. They both have a scientific foundation yet require copious practice to become proficient. This is my definition of a craft.
Sparring is one facet of martial arts that doesn’t seem to have a counterpart in software. Sparring is great. After all the devotion and practice you invest in your craft, you get to pit your skills against those of your peers and see who comes out on top. It’s a tool to measure your progress and learn your weaknesses. It’s also fun. I hope to see more of this in software.
Besides my family and software, my passions tend to jump around. Martial arts has been a significant passion of mine. I really enjoy playing the guitar. Recently I’ve been playing around with basic electronic components, building little robots. Basketball and soccer keep me active. And as soon as I can spare the time, I’ll learn to fly airplanes.
RubyConf registration is open (and nearly sold out), and I am so excited by the program this year that I thought it would be fun to ask some of the speakers some questions before the conference. So I’m starting a series of informal interviews with RubyConf speakers.
The first one was Greg Borenstein, creator of RAD.
Next up is Ben Scofield, author of Practical REST on Rails 2 Projects and developer at Viget Labs.
At RubyConf, Ben will be presenting All I Really Need to Know* I Learned by Writing My Own Web Framework.
Obviously, there are at least a couple steps between Hello World and writing your own web framework. For me, though, these two practices are (like creating a blog in a new web framework) learning experiences. Hello World introduces the basic syntax of a language; blogs demonstrate how ORM and other techniques are implemented in a given framework. Similarly, custom web frameworks provide a path into still more complicated functionality (network requests and responses, templating, etc.). Building a framework requires a certain level of knowledge of both the programming language and of how the web works, and that knowledge makes other tasks on the web and/or in that language easier.
I do not think that this general point explains the plethora of Ruby web frameworks, however. That, instead, is due to two factors: Rack and Rails. Rack has made it astoundingly easy to try out a new idea for handling web requests (as I’ll talk about in my session), lowering the barrier to entry dramatically. Rails, on the other hand, has motivated the development of new frameworks by both its success and its opinionated nature. Merb was originally developed as a very lightweight alternative to RoR and has since grown into a much less opinionated framework. Waves, on the other hand, is a reaction to a perceived lack of focus on resources in Rails. Most of the new frameworks are reactions to Rails, and to the specific opinions it internalizes. That’s not to say that any of these frameworks are intrinsically worse (or better) than Rails—their genesis is entirely separate from their value, and I think that each of the frameworks out there has lessons to provide.
Definitely; I think that building any software in a given domain is bound to affect how you perceive others’ software written for that same domain, and web frameworks are no exception. Decisions that seem unfathomable at first glance take on an entirely new aspect when you’ve struggled with and addressed the same problems on your own.
The immediate cause of my setting out to write Athena was a disagreement with Rails’ implementation of REST (over collection and singleton resource being handled together, more specifically). That said, I wouldn’t say that I’m terribly critical of Rails; I love using it, and I don’t foresee abandoning it soon. Of course, I think of Athena first as a learning experience, not a viable competitor to Rails (unlike Merb or Ramaze, for instance); if that were not the case, I might have a differerent opinion. For now, however, I’m content to continue to learn from my experiences and hopefully bring them back to Rails when I can (through patches, plugins, and gems).
I think the main reason we’re still building sites this way is that it works pretty darn well. Right now, we can build effective sites quickly, and we’re happy doing it—at the various least, we’re on a peak in the web framework landscape, and there’s a real risk in moving from a satisfactory (if potentially suboptimal) approach to an alternative, in that if you don’t know precisely where that next, higher peak is, you end up trudging through enormous valleys of unpleasant and unproductive work. Many of us made the move from frameworkless PHP or configuration-heavy Java because we used DHH’s fifteen minute blog video as a roadmap to the better place, already well-defined and waiting for us. For the next move, we’ll need something at least as comparable, and until then we’ll stay in this general region (which, all things considered, still has a lot of room for improvement, as Rails gets better and other frameworks adopt these lessons).
With that in mind, however, I do sometimes fear that we’re building our local maximum of joy and productivity to height such that the next thing will have to be even more amazing before it pulls in an audience large enough to really compete with Rails. Of course, that makes the existing alternatives (with their communities) even more important, even if none of them are currently at the point of being the Coming Thing.
Yep—philosophy, actually. I don’t know that I’d describe myself as breaking things down and reconstructing them, though given that my training was in analytical philosophy that does make sense. I prefer to look at my graduate work for inspriation; it was all about integrating distinct fields (cognitive science, philosophy of mind, animal behavior, biological psychology, evolutionary theory) into a cohesive whole. All of that has given me a perspective that’s somewhat different from the standard computer science point of view, I think, and while that can cause problems (since I’m missing some of the fundamental education a CS course of study provides), it more often than not helps me to see and make use of the underlying patterns.
That’s a question that gets a different answer depending on when you ask. At various times over the past few years, I’ve been passionate about dogs, analytic philosophy, comic books, squash, MMORPGs, mythology, cooking, politics, young adult literature, writing, various musical genres, Chinese martial arts, anime, volleyball…. I’m both obsessive and mercurial, which means I get powerfully drawn into subjects for a time, then move on to another fascination. At the moment, I’m holding steady with a few topics: comics and speculative fiction, with a dash of volleyball and philosophy, and I’m continually surprised and enchanted by what my six-month-old daughter does from day to day.
RubyConf registration is open, and I am so excited by the program this year that I thought it would be fun to ask some of the speakers some questions before the conference. So I’m starting a series of informal interviews with RubyConf speakers.
The first one is Greg Borenstein, creator of RAD. Greg also ran the lightning talks at RailsConf 2008.
I had electronics twice, in high school and again in college, as part of general physics classes. I was incredibly bored by the subject and quite bad at it both times. Neither of those experiences had much in the way of hands-on tinkering time. Instead, they were electronics as Science: dry equations, proofs, and word problems, and I never absorbed much of it.
In college I majored in art and wrote my thesis in art history, but what I was really trying to study was how to make things. I’d met there, for the first time, people who were budding engineers and I kind of got infected by their mindset: the constant pull to understand how things worked, not necessarily to reveal the grand truths of the universe, but just to dive beneath the surface of things to learn how they operated enough to change them and make them your own and make new ones. I took classes in painting, printmaking, music theory, book making, anything that I thought would teach me how to build something new—even my run of math classes and my written thesis, I approached as varieties of making. A group of us got money from the school to try to build our own atomic force microscope. We got pretty far designing and constructing it, finally running out of school year while still hung up on the control software.
Also, the summer before my senior year, I interned at the Museum of Jurassic Technology (http://mjt.org). The Museum is like a cross between an pre-renaissance cabinet of curiosities, a contemporary art installation, and a Disneyland ride. It’s filled with amazing exhibits that move and buzz and talk and glow; exhibits on micro-miniature sculpture, folk cures, Athanasius Kircher, Soviet cosmonaut dogs, Innuit string art, stereographic x-rays of flowers, etc. The museum’s founder, David Wilson, used to work in optical effects in Hollywood and is this genius of museum craft: optics, dioramas, lighting, etc. The summer I was there, there was an intern from the Getty cleaning the exhibits so their insides were open, relays and gears, projectors and wires, all spilling out.
All through this, I’d say I didn’t really know electronics and, mostly, I still don’t. These experiences, rather than teaching me much of practical use about electronics really just served to infect me with the bug to learn more. They showed me that electronics could be more than dry Science, it could be magic and it could be a key into how things really worked. Magic that you could make.
After college I wound my way through a series of professions and avocations and eventually wound up in programming. After awhile, the Arduino came along. I started to hear about it from mostly media-oriented friends as something they wanted to get into. Eventually, a group of us got together, ordered a handful of them from Sparkfun and set out to meet once a week to try to teach ourselves to use them. We were very quickly confronted with the fact that we barely knew any electronics. Getting a resistor on the right side of an LED to do the classic Arduino hello world was a challenged for us.
So, I started digging through my old physics textbooks and looking for new ones that were better. We’d set ourselves little projects like playing a melody on a tiny speaker or checking for a pattern on a series of buttons. For the first time, I was learning electronics the way I learned printmaking and Ruby: out of the need to see something I was making actually work.
Finally, the last few years, I’ve been really making progress, but it’s a challenge because the resources are really amazingly poor. Compared with the tools available for learning programming languages (from books to blogs to users’ groups), the hardware story is just brutally bad in this regard for beginners. All the documentation is tied up in data sheets from hardware vendors meant to be used by professional electrical engineers to design projects for mass production. Most of the tutorials, magazines, and books meant for regular people are based around one-off projects that, even if you do gather all the resources together to actually build, will teach you little about the actual underlying principles that you could actually grasp or re-use.
My most successful strategy has usually been getting my hands on real people that actual know this stuff and just asking stupid questions repeatedly until they actually give me an answer that starts at the beginning. That plus a few amazing books (that I’ve been beginning to catalog here: http://github.com/atduskgreg/rad/wikis/books) has really been all that’s helped.
RAD works by translating some Ruby code into C which can then be linked against the full Arduino software library and handed off to avr-gcc for compilation down into the hex that can be uploaded to an Arduino. The Arduino software library is built around two main functions: setup and loop; setup runs once when the Arduino starts up and after that, loop runs repeatedly. RAD takes a different translation strategy for each of these.
For setup, RAD provides a base class ArduinoSketch. Much like Rails’ ActiveRecord::Base, classes that inherit from ArduinoSketch gain a bunch of class methods for doing a lot of the configuration and setup necessary for programming the Arduino: declaring pins as input or output, setting up helpers for working with various pieces of hardware such as LCDs and Servos, etc.. RAD uses some metaprogramming magic and some seriously lo-fi string concatenation to use these class methods that you call in your sketch to generate a big chunk of C code: a lot of function signatures, library includes, and other boilerplate as well as the setup function itself
Now, the loop function is another story. RAD looks for a method on your subclass of ArduinoSketch called loop. It takes that method and hands it off to a library called RubyToC, which spits back the C equivalent. RubyToC was written by Ryan Davis and Eric Hodel and probably some of the other Seattle.rb geniuses as part of the Metaruby Project whose goal was to rewrite Ruby entirely in Ruby. I think that project might be some form of dead at this point since all of those guys now work for Engine Yard on Rubinius. Anyway, from RAD’s point of view, RubyToC is mostly magic alien technology that does exactly what we need (though we have made our own extensions by subclassing some pieces of the RubyToC machinery in order to implement some additional features (such as times blocks) in ways that might not be satisfactory for the general project of converting Ruby to C, but work great for us with our constrained compiler targeting).
We do the same thing with any other additional helper methods you’ve written on your class, glue the whole thing together and send it off for compilation.
The Arduino is obviously highly resource constrained (it only has 16k of flash program memory) and so a lot of people ask about the bloat that’s caused by the inefficient C we generate. We work had to keep that down (I can’t find the current stat for it, but I’ll get back to you with that) and I think that it’s worth it for the great increase in ease of use that Ruby provides over C++.
Right now, the answer to that is probably one of JD Barnhart’s recent projects. Either his Ruby on Bells:
or his Ruby + Auduino Midi Beat Box Demo:
JD came along like manna from open source heaven this summer: I hadn’t had much time to work on RAD for awhile and had accumulated a laundry list of requested features, both my own and from other users. As soon as I put RAD up on GitHub, JD forked it and added nearly all of them. He announced his work by putting a great screencast up with that Bells demo and a tour of his improvements. He makes great screencasts! I’ve since brought him on as part of the RAD core team and he has, along with Bryan Riley from wulfden.org, been a big part of the fast rate of improvement RAD’s been seeing lately.
Right now, we’re in the middle of doing a few desperately needed refactorings on the RAD code base, mostly consolidating things so we can clean up some of the fallout of all the recent improvements and make things more flexible and easier to improve.
After that I have two main directions I want to take the project: the educational route and the ‘modern software tools’ route.
I mentioned in response to you first question how much Arduino helped make it possible for me to learn electronics in the first place by giving me a fun environment where I could experiment and build things rapidly and easily. The whole purpose of RAD is to take this project even further: to let you program the Arduino in Ruby instead of C because it’s even faster and more fun. I think RAD can be a great tool for lowering the barrier to learning hardware hacking. Ruby’s expressiveness makes RAD code examples extremely readable. I’m trying to foster a culture around RAD of really good documentation: not just of RAD itself, but of exactly the hardware that is usually only explained through arcane data sheets. The RAD wiki is already starting to house some good material like this:
http://github.com/atduskgreg/rad/wikis
and I’m hoping to see (and write) more and more as the project progresses. Just as some of the great books that helped me learn Ruby (the Pickaxe book, _why’s Poignant Guide, Chris Pine’s Learn to Program) also taught me the basics of good programming itself, I’m hoping that RAD can be an entry point into creating some documentation for the wider world of hardware hacking.
The other big direction I want to take the project is to build all the ‘modern software tools’: we’ve become used to in Rubyland, but are still extreme luxuries in embedded C++ such as testing, simulation, code stats, etc. One of the great things about having written a program for your Arduino in Ruby instead of C++ is that once you’ve done so, we can use Ruby’s metaprogamming power to interpret that program in different contexts to accomplish different goals. So, just through writing a different implementation of ArduinoSketch, we can run your sketch in a test framework that will help you make sure that it actually does what you want it to or in a graphical simulator that lets you play with different hardware connections and code combinations to see what will happen before having to actually build out circuits or connect your real Arduino at all. Both of these projects (the testing framework and the simulation app) are in extremely nascent stages right now, but I hope to pour more time into them as soon as we finish up our current refactor.
Music has been a passion for me for a long time. I play in an indie rock band called At Dusk (http://atduskmusic.com) that’s been together for almost 10 years. We’ve toured around the country and put out 3 albums (with a fourth and final one on the way). I also run a local Portland music non-profit called PDX Pop Now! that puts on a free local all-ages music festival every year, produces an annual compilation of all local music, and helps do advocacy for kids’ access to music.
I’m also passionate about art—I think part of my energy for electronics comes from surplus created from drawing less the last couple of years. Artists like Jennifer and Kevin McCoy (http://flickr.com/photos/mccoyspace/), Joseph Cornell, Thomas Demand (http://www.thomasdemand.de/), Chandra Bocci, and David Hockney, et al inspire my interest in physical computing stuff as much as anything on the technical side does.
This year, I’ve discovered a passion for cooking. I’ve been working from Alice Waters’ books which are all about simple preparations of the best seasonal local produce so that’s lead me to start learning about gardening as well. That, combined with my adoption of biking as my main form of transportation starting a few months back, as made me feel like I’ve finally become the typical northwesterner, which must mean that it’s time to shake things up!