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?
Today we opened the RailsConf Call For Proposals. So we soon begin the several-month process of putting together the program for RailsConf 2010 (in Baltimore!).
I’m particularly excited to start the process this year, because we’ve made a very positive change to the team. We’re bringing on Ben Scofield as program co-chair this year. In case you don’t know Ben, he’s the author of Practical REST on Rails 2 Projects, Technology Director at Viget Labs, organizer of the roving Developer Day conferences, and a fantastic speaker (he helped created speakerrate.com too).
So please join us in welcoming Ben, and start working on those RailsConf proposals!
See you in Baltimore!
I gave myself a little break this spring and early summer, but the pace is about to pick up again. The rest of the year is looking pretty busy. Here’s what the rest of this year looks like so far. If you’re a reader of this weblog, consider stopping by to say hello.
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.
If you only have the budget to travel to one regional Rails conference this year, this might be a good choice:
...for obvious reasons.
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.
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.
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.
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.
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.
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.
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.
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 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.
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)
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.
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.
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.
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!
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.
Being an organizers of Ruby conferences myself, I always enjoy going to the regional conferences. I’ve been to the Mountain West RubyConf, Ruby Hoedown and Rails Summit Latin America. Each was excellent in its own unique way. It’s also a great pleasure for me to attend a conference I’m not organizing.
So I’m looking forward to the upcoming Scotland on Rails in March. Marcel and I will be presenting a tutorial for charity at this year’s conference.
I’ve heard great things about last year’s Scotland on Rails, and I trust my friends in Scotland to put on an excellent show. If you haven’t been to Edinburgh, you owe yourself a trip. It’s an incredibly beautiful city.
What better way to explore new lands than to do it by invitation as a speaker? Scotland on Rails has opened its Call for Proposals (it’s been open for a while, but I’m slow). The CFP closes in 2 weeks (December 1st), so if you’re interested in speaking don’t be late. From what Alan tells me, they are especially interested in hearing how to do BIG projects with Ruby and Rails.
Hope to see you there.
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.