Interviewed by Geoffrey Grosenbach
Geoffrey Grosenbach: So, this is the Ruby on Rails podcast, Geoffrey Grosenbach speaking with Ryan Daigle. This is a little bit of promotion of the first author to write a PDF mini-book for PeepCode Press.
But of course, Ryan Daigle is known in the community for his blog at ryandaigle.com, where he outlines and details many of the new features of the Rails code base as they go in. We’re going to talk about some freelancing that he has started on his own.
So, good morning!
Ryan Daigle: Hey Geoffrey, how you doing?
Geoffrey: Doing good! So, over a year you’ve been blogging about the new features of Rails. What kind of things are you looking forward to, or what do you think of the astounding new features of Rails 2.0 coming up now?
Ryan: Well, the good thing about Rails 2.0 is that there aren’t a lot of astounding features. I guess that’s considered good in some circles and bad in others.
But, you know, 2.0 is really more of a housecleaning incremental release. I think the reason it’s a 2.0 release is only that there are a few incompatibilities, or it’s not backwards compatible. But really, it doesn’t have any new paradigms or any big chunks of functionality that are different from Rails 1-2. Instead it focuses on some tightening, some cleaning up, some small improvements, and some things to address real world issues with the framework.
So, yeah, some of the things that I like about Rails 2.0 – or let me say, things that I tend to miss when I’m working in Rails Edge project versus a Rails 1-2 project – are like the sexy migrations, which was a plugin at one point in time. Most of that functionality has been pulled in to Rails 2.0. A lot of that syntactic sugar in migrations I tend to miss when I don’t have it.
And also, one of the really useful things – convenient things – I’ve found, are some of the rake tasks. Like db reset and rollback, and things like that. So, you know, those are not huge bits of functionality, but they certainly make the everyday tasks of a Rails developer much easier. It’s just nice to have that out of the box, instead of having to include a plugin or write your own rake task. Those are kind of some of the things that are up and coming in Rails 2.0.
Geoffrey: I was using one of those just the other day. I think it was rake db:create, and it will actually go through and build a, you know – make the MySQL or postgreSQL database matching up to what you have in your database yml file. I thought that was useful.
Ryan: Yeah, absolutely. Instead of having to go to command mod and having to do MySQL, create db, and actually do it manually, all you do is set up your database yml file, as you would when you’re creating a Rails project anyway, and run db:create, and boom, it goes and actually creates the databases for you.
So, it’s stuff like that; that on its own may sound like a 30 second time saver, but that’s a task that a lot of Rails developers do many times over the course of a project, so they really do come in handy.
Geoffrey: So, I was surprised that a lot of the new features were already available as plugin, and I haven’t been watching it as close as you have, but things like Foxy features, or sexy migrations, or even the asset splitting – that you can have assets on different servers to speed up the client side download time.
Did people submit patches for that, or do you think the core team went out and said, “Hey, this is something really great. Let’s pull this in”?
Ryan: You know, I’m not sure about sexy migrations. I’m going to go out on a limb and say that the core team saw the kind of mimicked the functionality of sexy migrations because it’s not the full functionality of the Sexy Migrations plugin that made it in the core. There are a few differences, and it’s kind of their own implementation of that functionality, so for that plugin I would say, I would make an educated guess that it wasn’t a patch by the plugin authors.
With Foxy Fixtures, however, I’m pretty sure that it was a patch by the person who wrote the Foxy Fixtures plugin that was eventually accepted. I remember when I was researching the Foxy Fixtures functionality for the blog and for the Rails two B code that I did with you, that I ran across several threads on the Rails list about the patch, and the author was discussing about the implementation details and so forth. So I think that was a direct patch to Rails.
But it’s definitely good to see the involvement and the vibrancy of the Rails community really kind of driving the Rails framework forward, and really contributing some pretty important pieces of functionality to the framework.
Geoffrey: Now, I went through and I did some statistics here. The very first tag in Subversion was point one, and that was about 32 thousand lines of implementation code. Went up to about 54 thousand for Rails 1.0, a little but up to 59 thousand in 1.1. Big jump in 1.2 up to almost 90 thousand lines, and then Rails two is just a small increase over that to about 94 thousand lines of code. That’s still a lot of code for a framework, but it seems to be slowing down.
My question is, with a lot of these features being plugins, I almost wonder, what about the strategy of instead of actually wrapping this stuff into the framework; when you make a new Rails project it would just drop a bunch of these plugins in your plugin directory. If you want Sexy Migrations, you leave it in there. If you don’t, you delete it and you’re a couple lines leaner as far as the framework you’re running. Do you think that has any weight, or is it important for all these things to actually be in the core framework that people can count on having there a hundred percent of the time?
Ryan: You know, I think there’s merit to your point, and I don’t know what the core team’s strategy is as far as to determining what goes in and what’s best left as a plugin. I mean, it certainly increases the visibility of the functionality or of the plugin to actually have it within the framework of course. You know, having it available at your fingertips from the just the default install. So, I would say that a lot of plugins that you and I may take for granted, some people may not have heard of yet. Certainly from a publicity standpoint, it does help to have features that the core team deems core or central or essential to the framework itself, to be there instead of still kept out in a plugin.
And also, I think there’s a question of when differences of opinion come into play, when the authors of a plugin may want to take the plugin in a different direction than the core team might agree with. Then you may have a split and what you do, you’ve already got a stable release out there, how do you bring that plugin under the Rails umbrella? I think there are a few somewhat sticky issues as far as maintaining plugins versus pulling it into the Rails core, and I certainly don’t have a good answer for that, as I don’t have some secret insight into the core team’s operating, or how they make decisions.
Geoffrey: Now, one new feature that people are really excited about, Active Resource, and is that like that, have you used that, do you feel like it’s ready for prime time, or is that going to be a new features that’s going to need a little bit of tweaking as people start to use it more and more in actual projects?
Ryan: I would say it’s pretty close to prime time. I mean, as a framework it’s actually quite simple. I mean, for the most part all it’s doing is kind of crafting your H & B calls, your URI’s, and parsing a response. Parsing an X & L response, or actually recently adjacent response as well. So the framework’s responsibilities are pretty minimal, and because of that it’s a pretty simple framework, and deep limitation is pretty straight forward.
You know, when I first started looking at Active Resource, probably, I don’t know, at the beginning of this year, it was definitely very raw, and I would say would not have been ready for prime time then. But I’ve been working on a few projects, actually two so far that have used and are using Active Resource. And I’ve been pretty happy with the framework. And it’s been easy to, it’s pretty pliable. It’s been easy to work with the framework and go around it, or dig deeper into it when I needed to. It didn’t really prohibit me from doing anything.
So I’d say it may not be everything you want right out of the box for a framework for, you know, a client framework, but it’s getting there. And I certainly wouldn’t let that stop you from trying to use it within your system.
Geoffrey: I think building applications around that kind of idea is nothing new. We’ve, you know, had the restful idea. But a lot of these new things like Google gears its, the whole idea there is you’re building around an API. Maybe you’re getting JSON back or whatever, and so it seems like changing kind of the mindset of building an application, and having the API be a real core part of it is going to real big in the future.
Ryan: I mean, it’s definitely is going to be real big in the future, although you do kind of have to temper that with the fact that people have been saying for years that these sort of web services will be real big in the future. But I think, kind of boiling it down to the very simple and easy consumed format as [indecipherable] the rest, I guess, methodology combined with JSON XML, makes it very easy to piece together a functionality of an application, and have some, a core service running in the background that feeds different UI’s, different clients.
Definitely kind of capitalizing on that goal the people in the industry have had for a long time period. Kind of pick and choose from a la carte to form your functionality.
Geoffrey: Stepping back here a little bit, little bit of a Meta question about your blog itself. You, I think, had a brilliant idea, which was just reading the rails, change log-in, and writing blog articles about that, which solves have the problem of the blogging, which is trying to think of what to blog about. Where do I get the idea of doing that?
Ryan: You know, it’s been so long since I started it. Certainly Internet [indecipherable] has been up for, I’d say close to two years. I was blogging before that, you know, when I was kind of stuck in JAVA land. And, you know, I can’t really remember when I had the epiphany of, you know, hey this would be a great idea to kind of consume the SEN change log from rails and put it in somewhat of a readable form.
I think I initially did it as maybe one or two features that I happened to see coming across the wire. And I thought, you know what, I think people might like to see this, because I knew not many people were reading the change stats at the time. So I think I put it up there, and I think the response was pretty good initially, and I think that kind of motivated me to keep this process going.
And at this point now, it’s got a pretty decent readership base, and it’s kind of a, I thought the community kind of holds me accountable for keeping on top of the latest thing. So it’s kind of been a self-motivating cycle at this point.
Geoffrey: It seems a big thing about that too is that you don’t blog about every single change set that comes down the line. You pick and choose a few different ones, which to me is a huge value. On the Internet there’s so much information. You can subscribe to a ton of RSS feeds, and yet you want somebody to come out and kind of give you a summary and tell you what the important things are.
Ryan: Yeah, I mean there’s so much coming across the wire that it would be both limiting on my side as far as time goes to try to keep track of every single feature, and also if somebody wanted to really to see every single feature and bug fix and whatnot I come across, they could just pull down the RSS for the subversion themselves.
So, I try to provide two services. One is to filter out some of the noise. I won’t call it noise, but some of the extraneous things. Things that may not be central to a Rails developer. And then also to put it in more of an explanatory form. So that, it can kind of serve as tutorials for these new features, if you don’t want to sit there and look at the code and try to understand what’s going on. Although, for the most part, the commit messages do a pretty good job of at least pointing in the right directions.
So, I kind of had to make a conscious decision at some point to… On what features to focus on, and to filter out some of the other stuff. I don’t do… There are a lot of changes that come across from prototype, and I have made a decision not to focus, or not to document prototype changes at all. Not because I don’t think it’s worthy, just from a constraint point of view.
So, it’s definitely up to my discretion as far as what gets in and not, and sometimes that comes back to bite me. I’ve had occasions where pretty important features come across… I think the most recent one might have been a change in how the named roots were ordered, by parent/child path instead of child/parent path. Something like that was a recent change in Rails 2.0.
When it came across the wire, I looked at it and thought nothing of it. I don’t know if I didn’t understand the functionality just by looking at the code, or if it just totally skipped my mind, but I missed that one and it bit a lot of people, so the community was definitely there to let me know that hey, I missed one, and luckily some other people picked it up.
It does have its drawbacks, having to choose on my own, but hopefully, for the most part, I try to get it right.
Geoffrey: Yeah, there’s a bit of trust there. People expect that if there’s something important, then you’re going to talk about it. Well, it does…
Ryan: Yeah, and that’s definitely my responsibility, but it’s enjoyable for the most part. I really enjoy staying on top of it, and having people hold me accountable. It kind of pushes me to really stay on top of things.
Geoffrey: Now, I think you brought up a couple good openings there for other people. If somebody wants to blog about weekly… About the change set in prototype. For me, I could use something… Let’s see… The change set of lets say R-Spec or Capistrano, although those aren’t as frequent as the Rails core. Or even a summary of the mailing list. I think people have been doing that off and on. Weekly summaries of different mailing lists.
Ryan: Yeah, I think people in general tend to… If they have a post they’re involved in, or they’ve contributed to, or see something they’re really interested in, I think people do take the initiative to pull that out and put it on their blog, just as almost another publicity mechanism.
I think people do tend to pick and choose and write about it, although I would agree that some of these bigger frameworks… This would be a valuable service for somebody else to step in and try to translate the code to readable line formats for new functionality and new features.
Geoffrey: A couple of months ago you’ve taken that and you’ve gone off on your own. You’re now running a consulting business called yfactorial. I love the fact that you put a lot of effort into making a really professional looking site. As far as I know, you’re not a graphic designer, but you hired a great firm. You made a good looking site. You have a matching blog.
Why did you feel like that was an important thing when you were starting out on your own?
Ryan: I’m definitely a big believer in the aesthetics of the sites. I have no innate or learned ability at all to be creative or to design these good sites, but I definitely appreciate them. I knew when I started out it was important to present at least a decent looking front to the business. I think that it kind of sets the tone for your business, of being professional, being aware of how you’re perceived, and taking the time and effort to do it right and put a good foot forward.
I think the design of the site really sets the tone for your business, so that’s why it’s important to me. When I started going out on my own to have this site that at least I felt proud of and felt confident in. That’s not to say it’s the best thing ever, but it accomplishes the design goals that I laid out for the design company that I used, which is a company out of Texas called Unit Interactive. I really enjoyed working with them. They did a great job for me. I’m glad that you seem to agree.
Geoffrey: Now, I also had looked at the name before I mixed it up, but yfactorial sounds a lot like Y Combinator Programs, a venture capital firm. In talking a couple of years ago to 43 Things, a website here in Seattle. They said they intentionally chose a name that was pretty similar to Merlin Mann’s “43 Folders, ” or even could be confused with “37 Signals, ” and they felt like that kind of gave them a little leg up on people wanting to find out about it or seeing what was happening.
Did you intentionally choose that name, or was it just kind of a name that was in your mind and it happened to be similar?
Ryan: You know, that name confusion was purely unintentional. I actually wanted the name to be nFactorial, because from my somewhat limited math background, when I remember talking about factorials, it was always N factorial. The letter N instead of Y, but somebody already took nFactorials, so I had to go down my list of variable names and yFactorial was next.
Although I have heard of Y Combinator and certainly know what they do and am aware of their stuff, I certainly don’t think that played a part in the naming. I have heard of them, but it was not intentional. So, Y Combinator, I’m not out to get you. You can rest easy.
Geoffrey: [laughs] Still, it gives a nice technical name. It’s, “Hey, I’m here to do hardcore coding and that’s what I’m about.”
Ryan: Yeah. I guess I wanted a slightly geeky but not limiting name, so I think it serves the purpose pretty well.
Geoffrey: When did you decide to go solo? What kind of things were factors in that decision?
Ryan: I decided to go solo earlier this year. Towards the beginning… Actually, beginning to middle of this year. It was kind of a combination of factors. I think it was personal confidence, if you will. My skills. That I was ready for the responsibility of going out on my own and putting food on the table myself, as well as just feeling that the environment, the climate was right in the industry for freelancing and for Ruby in general. And also for my desire to be focused full time in Rubyspace.
So, those three things came together around the same time. I also got married this summer, so I started yFactorial one week after getting married.
Geoffrey: Wow, that’s brave.
Ryan: If I’m changing one thing in my life, I might as well change everything. So, that’s kind of how the timing came about.
Geoffrey: Now it seems like Rails developers, and even just web developers in general, right now have so many options. People could go try to get hired at a firm, at a consulting firm, at a start up. They could find a partner and start a business. They could go freelance. What would you advise to people who are trying to choose between all those things, and why did you choose to go solo instead of maybe one of the other options?
Ryan: Well I think going solo is it’s really being an entrepreneur. It’s you really have to have the passion for starting a business and feeling both the pains and the joys that come with starting a business. You know, if you are just interested in the technology, you just want to work with Ruby, and that’s your reason for wanting to go solo, or try to branch off from where you are now, I would say really think about that.
It’s a big responsibility to be on your own, to do your finances, marketing, things like that. That’s a lot of responsibility that falls on your shoulders. So, if you just want to play with a certain technology or a certain language, try to find a shop a good shop, one that lets you have a little freedom but a shop that lets you focus on that technology.
If, however, you’re really interested in setting your own future up and deciding for yourself where your career goes, and really having in your mind the idea that you want to create something more than technology, you want to create a business, a culture. If you have that kind of burning passion, I would say definitely go out on your own or look for somebody who has similar experience and similar desires, and maybe partner up with them. I think there is some security in having a partner. You can lean on each other and motivate each other in tough times. So that’s a little smorgasbord of what I think on that topic.
Geoffrey: Personally, I have to say it’s great that there are so many other people and services out there. This is nothing new, but I, personally, I have a CPA that I pay to do a lot of my tax and accounting stuff. I have a lawyer that I pay hourly for some things. I have a business advisor that I go talk to once or twice a month and yes, I’m it’s just me running the business, but I have all these other people that I can pull from and strengths. I don’t have to hire full time people, but I can take advantage of their resources and buy a couple time a couple hours of their time a month. That’s been a huge benefit for me.
Ryan: Yeah. It’s great how many parts of a business you can outsource, and not outsource as in to a foreign country, but just local source, I think is what it’s called. I tend to like to feel the pain of something, like know that it’s hard to do QuickBooks, or know what a pain it is to do QuickBooks before I farm it out to somebody. That way I know the value I’m getting from that person. But in general, it is great to have those resources that can set you straight, can get you set up, can prevent you from making stupid mistakes that first timers would normally or would otherwise make. Then, also, completely take that responsibility away from you so you can focus on the core of your business. You’re right. It’s great to have those resources out there.
Geoffrey: Well thanks for the conversation and for those who haven’t already, you can go buy Ryan’s book from PeepCode, only nine bucks, less if you buy a subscription, and that’s been updated a few times just to cover a few things. And PeepCode even recently; Obie Fernandez felt like it was a really well written mini-book. He’s going to be talking about that at the Rails conference in Spain coming up at the end of this week.
Ryan: Yeah, that was cool to hear. I’m all for the Rails doctrine getting out there and being publicized and all the much more better if it’s our book too. So go Obie.
Geoffrey: Well thanks for the conversation. Keep it up.
Ryan: Well thank you, Geoffrey.