Stuart Halloway

Robert Stevenson interviews Stuart Halloway at eRubyCon in Ohio.

Interviewed by Robert Stevenson

Transcript

Geoffrey Grosenbach: It’s the “Ruby on Rails” podcast, I’m Geoffrey Grosenbach. Episode number 60, November 2007.

I have a bunch of interviews recorded, and this is one of the older ones that I’ve been sitting on, but it’s about time that I get it out there. Done by Robert Stevenson at “eRubyCon” back last summer with Stuart Halloway. I met Stuart Halloway briefly at “RubyConf” last week and wanted to get this out there so you can all hear it and enjoy it.

Robert Stevenson: Hi, this is Rob Stevenson from the “Columbus Ruby Brigade”, here at the third day of “eRubyCon”. With me today is Stuart Halloway. How are you doing, Sir?

Stuart Halloway: Very well, thanks. Thanks for inviting me, Rob.

Robert: My pleasure. Today we’re going to be talking about topics that have been hit upon at the Enterprise Ruby Conference – “eRubyCon” – here, in Columbus, Ohio. We had a ‘fishbowl’ Monday night where a lot of the discussion came to the point of how to break “Ruby on Rails” into the enterprise. What are some of the things that you were able to talk about?

Stuart: Well, a lot of this, for me – and we’ve been doing “Ruby in the Enterprise” for a couple of years now – centered more around issues of productivity and quality than really around “Ruby on Rails” directly, because developers love to argue about programming languages and tools or what have you, and they’ll do that endlessly. Now, from the perspective of a business it’s really more about “I have a problem that I need to solve, ” and then you find yourself led to certain technologies that help solve it.

We have pushed 100 percent code coverage in conjunction with various other quality measures, and we’ve found that getting that kind of quality is easier to do in “Ruby on Rails” than on other platforms. So, rather than selling business people, who don’t know the technology, on sort of brand recognition of different technologies that developers are excited about, we are much more about showing them how our agile process produces reliable, repeatable software; that we’re going to achieve a certain velocity and knock down a certain number of story points per two-week agile iteration, and that “Ruby on Rails” are a very good technology for supporting that.

Robert: Now, when you say “show them” I’m assuming you’re going to go in and talk to CTOs, CIOs, even managers. But for a CTO of a big enterprise that thinks: “OK, all my people know Java.” – how do you come in and try to convince them that “You know, your people are not stupid; they can learn something new”?

Stuart: Well, the word “stupid” and things like that come up sometimes, although a lot of times people will say things more along the lines of: “We want to commoditize development.”; or just that: “Look, we’re doing work in a lot of cities that don’t have huge IT communities.” So the managers will say to us: “It doesn’t matter to me what you do, as much as it matters to me that there’s a life-cycle behind that and we have to continue to support and maintain that through the end of that process.”

And… there are a couple of things that feed into that. One is: we’ve done several projects where we have enabled very junior developers to take over at the end of the project. And we’ve actually, sort of jokingly, found that it’s actually easier to have the most junior developers, people who are coming straight out of college, because there are not as many bad cultural influences to undo. We have one project right now, where one of the developers is actually a sophomore in college, and so there’s very little broken there at this point, and there’s an opportunity to start.

And we’re not seeing an enormous difference between programming languages in terms of people’s ability to get up to speed. We’ve been joking at the conference that people say: “Maybe this or that (or some other feature) of Ruby or Groovy (or some of the other languages that are popular right now) is difficult, because their development team isn’t willing to climb that hill.”

The bottom line is: building this stuff is difficult. The abstractions themselves in the domain are usually more difficult than the abstractions we attack them with in the programming language. So, development in Java is hard; development in Ruby is hard – that’s why people get paid to do it.

The other thing that’s amazing to me is that I find the way the CSS stylesheet rules interact to be harder than meta-programming in Ruby or class-loading in Java. So, web developers – people who sometimes in a sort of humble way say: “Well, I couldn’t be a server-side developer” – are actually doing something which, to my mind, is cognitively more difficult than some of this supposedly scary stuff that we’re doing in Java or Ruby. So I don’t buy the difficulty argument or the “my team can’t switch to this” argument.

Another thing is that people are unwilling to invest in retraining – both as individuals and as organizations. And if you do the return-on-investment, it makes no sense at all. If you could make your development team 10 percent more productive over a big project, it would be worth taking almost a month of the year out just to train to get that. That investment would pay itself back within a year – not to mention how happy a development team is to feel that they are investing in themselves and that their company is investing in them. So it is an education issue, but once you’re at the table and solving problems it’s not an insurmountable one.

Robert: With Java you have Sun behind it – which can be questionable at times, and with.NET, of course, you’ve got Microsoft. But there’s really… because Ruby and Rails are open-source driven and kind of community driven in a loose sense, you’ll find that managers aren’t apt to take on something like “Ruby on Rails” because if something goes wrong they can’t point a finger to a corporation; they can’t buy a support contract for a lot of money. How do you try to educate managers that don’t want to take the risk of using a new technology?

Stuart: Certainly the risk counts as a valuable item when you tote up the plusses and minuses, and it should be assigned a weight if an organization already has a stack and already has support contracts and so forth. But the weight isn’t infinite. So I encourage them to put a dollar value on that, and factor that into the equation, and do that: allow me to participate in that conversation.

There is a need for more commercial support for “Ruby on Rails”. Companies like ThoughtWorks are stepping up and doing that. At Relevance, we are willing to do that; and we don’t sort of formally market that at this point but we’re certainly willing to engage with customers we’re developing for – or even ones we’re not – about support, because we see that that issue is out there.

I would love to see a sort of different model for that in the “Ruby on Rails” community than has come into existence around other technology stacks. So that rather than having large vendors – not that they’re bad – but rather than having large vendors, something that tapped into the sort of micro-nature of the dozens of beautiful wild flower Ruby projects that are blooming out there.

I talked to Jim Wirick, the creator of Rake and Flexmock yesterday about this. About having some sort of blanket umbrella organization that wasn’t trying to achieve some IPO or something like that, but that just was able to tie together various key people in the Ruby community and pay them for the work they’ve done, reward them for the work they’ve done to support the community and then turn around and present a face to businesses that want to have that service and support.

I think there’s room for improvement there. Individually, at Relevance, we’ve solved this problem with customers by saying: “Show us how you do it today and we will match that. Not just the development piece, but the support piece. We will match that going forward.” But it needs to be built out. It’s a new technology, so it’s an ongoing issue.

Robert: Let’s talk about one of the sessions you did yesterday. You named it: “This Week in Refactoring.” – that’s up on your blog that you’ve blogged about for the past couple of days. It was interesting because you…there are now charity drives, but, in addition to charity, you’re trying to push unit-testing.

At our ‘fishbowl’ – it was actually being held at the Microsoft building (or, not really building, but their offices here) – we had a Microsoft person in attendance that said (which was quite interesting at the end): “It is really interesting that this is a Ruby group, but the main focus that was talked about generally revolved around unit-testing and had nothing to do with Ruby. So, talk about your idea for “This Week in Refactoring.”

Stuart: I have to first say that I give a lot of talks and a lot of conferences and that very few things excited me as much as the possibility of this talk before doing it this week. After having done it, I’m even more excited.

Basically what I did was, I picked an open source project in the “Ruby on Rails” community. This time it’s the type of blogging engine. I showed the conference attendees how to pull that code down, how to look at the code, look at it’s uni-test, do a code review, look at coverage tools, analyze the project, and find a way to make a small contribution.

In my case, I didn’t know I would do this up front, but having gone through the experience once, I time-boxed the investment in that to four hours. So I said: “I’m going to take four hours, find a project, and make a concrete improvement to the project and take notes on the process as I was doing it.”

With Typo, I was able to find six small improvements: some of them were code-coverage improvements, some of them were refactorings for understandability of the code, and some of them were bug fixes.

In four hours, find these six things, write test-driven test to show they were in fact improvements and not back-sliding in the code base, make the improvements, create the patch, document everything I had done, create a keynote presentation showing everything I had done, and then submit that. In this case, I believe, it was the track issue 1131 in the code base – so if you want to go and take a look at that in Typo, you can look at the code that was done.

My idea is to now take this talk to different languages and platforms in different communities and give it at a series of conferences and events like the eRubyCon over the rest of the year. At each event, not only show people how to contribute to open source, in this particular room was a pretty good density of contributors already – about a third to 40 percent of the people there had already done this. I challenged everybody else who was there to go and take four hours and make a contribution to the Typo project.

So what I’d like to do for the rest of the year is, repeat this exercise with a variety of different open source projects and actually let this build up some steam – ideally to the point, where projects would actually get in touch with me and say: “Yes, we’d like to participate in this free service of four hours of refactoring from you followed by whatever enthusiasm that is generated at the conference.” So, I’m going to check back in on the Typo track and see if there are other people who are inspired.

I basically told the attendees: “If this is your first night of fight club, you have to fight.” So hopefully the 60 percent who had never contributed to an open source project before, will do that after the talk. There were a lot of different things, all rolled together there. It’s improving the community and improving our approach to testing all rolled up together.

Robert: Right…In this audience, I sat in on the talk. You had: Jim Wirick, Neal Ford, Glen Vandenburg and a lot of other people – let’s face it, I’m no Stuart Holloway, and I can’t go into this code and say: “Ah gosh, they’re doing this wrong.” That’s why I love reading the “Rails Way” that Jamis Buck and Michael Koziarski does, because it does that refactoring; that ‘coming from Java’. Trying to do it the Ruby way is just a different way of thinking.

How does someone – a Joe Coder, who is interested in Ruby and has done a little bit at home – how could they get in there and how would you suggest they get into, say, Typo? Some of the code that you showed, where they misspelled the word ‘cache’ (they miss-spelled it as ‘cackle’) – something like that I’m like: “Oh, OK, I can fix that!”, but other ways of…OK, there were multiple points where refactoring could take place and…Of course, in your talk, there were disagreements between you and Jim Wirick and some others on how to do things. How do you suggest someone more of a ‘Joe-Coder-kind-of-a-guy’ go in and fix and submit patches?

Stuart: You’re absolutely right. I often discuss in my personal life – my wife and I always joke about ‘the great big – the enemy of the good’. In everything we do in life, we’re both ‘big bite’ kind of people in the way we approach life, and so we often look back at the end of a week, a month, or a year and say: “We did these things in our lives that we’re excited about, but there were these other things that were great but got in the way of being good enough.”

The fact of the matter is, most of the open source projects out there, “Ruby on Rails” or otherwise, are not running at 100 percent code coverage with dense elegant poetic code. At one level that’s intimidating, because you watch somebody who’s playing at that level do demos at a conference or whatever and you say: “I’m not writing a 100 percent test-covered, dense, elegant, poetic code either – so I can’t play.”

And the matter of fact is: people can play. Several people came away from the talk thinking: “You know, I hadn’t seen all the various tools used together; I hadn’t gone through the process of SVN download, rake, building out the test task, running the ‘rcov’ test.” And then you actually find – you go and click on one of those red lines, and you actually find that some of the problems are really simple; that we’re not close to giving code the amount of refactoring attention it deserves.

Maybe at some point five years from now, what I’m trying to do with “This Week in Refactoring” wouldn’t be accessible to novice programmers or people who are getting started in a language or a platform right now, but at this point, the fact of the matter is: it is accessible. There is so much that needs to be done! And, with a little bit of just knowing how to run a rake task and run an ‘rcov’ report, and go and find a couple of lines of code that aren’t covered.

Some of it is busy work – but you do that busy work three or four times, and then you start to pull out observations about how to make it not busy work. And because Ruby is such a dynamic language you can say: “You know what? I’ve just done the same thing four times. I can make that go away.”; or: “I don’t quite know how to make that go away yet, but at least I’ve improved the code coverage or improved a bit of documentation.”

Some of the attendees at the conference said: “You know, I just went up and I made… I read a piece of the code and I didn’t understand it. I figured it out, and I made a documentation patch.”

There are a lot of levels at which people can jump in and commit. One of the things if you go and download – if you go and look at that patch 1131 or track issue 1131 in Typo – you’ll see that some of the changes are extremely modest. So there is a curve that people can go up, that’s smooth – instead of just hitting the brick wall.

The most complicated of the six refactorings, was identifying an opportunity for doing a little bit of meta-programming in how Typo deals with depricated things. There were several places where there were methods that looked very similar, and I pulled that out into a more declarative style.

At the beginning a Ruby programmer won’t do that on day one, although I would argue that they might do it on day five. They might finish it, under the wire, in the ‘21-days-for-dummies’ learning curve – even the more elaborate things, if you’ve seen an exemplar for how to do it. But there’s absolutely tons of little things just sitting out there that are easy to spot, so I would encourage people to go and give it a shot.

Now, let me shout out to all the open source library providers, and the people who run projects: make it possible for someone to, at least, download and run the Rake test tasks on your project, because the absolute buzzkill is to go and grab an interesting project and not even be able to run the tests; because at that point, a lot more knowledge is going to be called on and a couple of the projects that I tried before settling on Typo, I wasn’t able to, trivially, get started. So I knew that I wasn’t going to meet my four-hour time box. Those projects, by the way, I will be emailing you privately and helping out. There’s a bigger project there, showing how to get a project from ‘not community friendly’ to ‘community friendly’.

Robert: You pointed out six issues and, of course, we had some laughs at the misspelling, stuff like that. But you did compliment the Typo folks that you were able to download the code, run our code and get started very quickly.

There was a comment that: “Well, it was good that you didn’t try to tackle Rails”. Because that’s probably something that would be a little more difficult for someone to get into in four hours and be able to…

Stuart: Actually, it’s interesting that you mention that. Patching Rails itself is something that you can bite off in four hours. Basically, in order to patch active record, you need to know how to set up MySQL maybe a little more manually, a little bit past database MLO, but not much as I recollect. So, I will refactor Rails at a future installment of this, in an environment where that’s appropriate.

The issue there is that most people have been exposed to a Rails application – fewer people have been exposed to the underlying Rails code base. There are tons of places in there, where the developers on the Rails core team were learning Ruby themselves as they did it, and that could go back and stand to have some love applied retroactively. So I think that’s a perfectly good area. It’s not the project that I would recommend somebody pick as their first one, but it’s more approachable than you might think.

Robert: Good to hear. You also had a talk on refactoring, which, of course, we’ve been talking about. How does someone learn, like I said, more of the ‘Ruby way’? How does someone coming from another language learn how to create beautiful code in Ruby?

Stuart: Obviously, there’s the ‘Pickaxe’ book that I would recommend anybody who hasn’t started – read that. I also very much like ‘The Ruby Way’, Hal Fulton’s book, since you mentioned that phrase in the question. There are the books that are out there and there are the open-source projects to read.

Now, as I said, meta-programming in Ruby is powerful and beautiful, it’s also that there are many choices. Ruby is a ‘there’re five ways to do it or 10 ways to do any given thing’ kind of language. And that’s frightening to people who are just getting started, because you want to have that sort of: “OK, show me ‘A way’ to do it, or even tell me there’s ‘THE way’ to do it, for now. Allow me to feel that sort of initial sense of success and then later say that there’re actually 20 different ways that you could do it; and give the developer the empowerment to start choosing the one that is most appropriate for that circumstance.”

So… it’s not easy, and…I think the best thing to do is work within the boundaries of a particular domain, where somebody else has already worked to give you elegance and beauty. Rails is the perfect example, right? Start by building a Rails application and go through the process of seeing how easy it is to stitch things together, with active record, for example, where so much of the code that you write is declarative: declarative relationships, declarative validations, and so forth.

The other thing that you can do in sufficiently dynamic languages – I would say, languages that are seven-plus on Paul Graham’s nine-point scale – is you should always be telling yourself: “If I can think it in one thought, I can write it in one line.” And, in Ruby, that’s almost always true. If you can’t write it in one line yet, don’t give up; write it in five lines, write a test that shows that it works; and know that you’re going to come back and shorten that to one, more expressive line, once you better understand the code.

Actually, one of the methods that we refactored in the Typo code base, was a very simple method that was extracting the ‘ping-back URL’ from a response. The method in the Typo code base was, maybe, nine lines long and it had three branches, and we demonstrated that it actually only needed two branches. Then, as we were sitting there, I had refactored it from ‘un-tested’ and ‘hard-to-read’ with three branches, down to ‘tested’ and ‘easier-to-read’ with two branches, and Glen Vanderburg – who was sitting in the audience – refactored it down to a single line.

So it is an iterative process. But the fact that you could take it from seven lines and ‘hard-to-understand’ to five lines and a ‘little-bit-easier-to-understand’ – that’s great. Someone later is going to take it down to one line – even better!

One of the things that I said in the talk was that I try to write my code as thousands of little isolated boxes of stupidity. I’d rather have them be isolated little boxes of intelligence, but I acknowledge the fact that none of them are perfect. But with testing and with good object-oriented design we’ve at least isolated them in little boxes. So that method lives in the right place; it’s hung on the right class. Yes, it can be improved in the future, but it’s already known to work. It’s five lines that aren’t so great and in the future it’s going to be one line that’s even better, but that change will be totally isolated from the rest of the code base. And Glen Vanderburg, or somebody like that, can come along and make that change.

Robert: Let’s talk about a project that Relevance brought out two years ago, called Streamline. Can you explain what Streamline is and what’s the status of the project?

Stuart: Streamline has been many things to many people. Many of the things that it was at the beginning of its’ life, it isn’t anymore. So history is important here.

Streamline started as a quick and dirty generator-based approach to pull out or to extract some commonality, in doing admin interfaces on various Rails projects that we were building. After we had done that for a while, we realized that several things that we had done, we didn’t like. We have given Streamline version numbers, like 0.0.5, to indicate to people that we’re putting this out there to get feedback, but: “Here, there’ll be dragons – pretty much all across the code base.”

We are going to release an 0.9 or an RC, sometime in the next month. That’s going to represent a commitment: ‘a’ – to rapidly come into closure and going 1.0; and ‘b’ – not pulling the rug out from people in terms of API end approach.

We have abandoned being generator-based. Streamline is currently a plug-in. As appropriate, we may make it a Gem as well, at some point. It’s much easier to pull into your project. It’s much less intrusive in how it adds services to your project.

In terms of what it does, it’s not really an admin back-end piece anymore. It’s more about trying to make view code and controller code as declarative and as active record-code is. To some degree, it’s comparable to things like Jango in the Python world, or Active Scaffold in the Rails world, but not so much. I would argue that the thing it’s most comparable to, or the thing that we are gradually taking it towards, would be Eitan Suez’s JMatter framework, where the objective is that 90% of the UI of an application could be inferred from the model.

For a while, in the Java world, people called this Naked Objects. That name seems to be a poison pill for folks. I don’t know if that gets a PG-13 or an R rating [laughter] in some people’s minds.

Robert: Try printing out the Naked Objects documentation at work. You hit the printer button and you run to the printer real quick because you’ll get some looks.

Stuart: Right. So, I think maybe the Naked Objects name is unfortunate, but the goal of saying that a huge amount of UI work – especially in Rails, where you come out from a web-app framework – a lot of people are now using Rails to build internal, within a company, applications that are going to be used by a small user base, to basically replace things that people were doing in Microsoft Access or in an Excel spreadsheet or, usually, in some hodgepodge of: “Well, we’ve got this piece in Lotus Notes over here; and this is an Excel spreadsheet over here; and we manage this via email over here. It’s kind of evolved over time, and we want to clean that up and have that be simple. We want to get all those productivity gains, that people talk about, building it in “Ruby on Rails”.”

The good of it is, you can really quickly get started. The bad of it – and we’ve seen this on projects that we’ve developed – is that you can end up being very webby in how you approach that. So you can write a ton of View code, and you can discover, after a while, that there’s a lot of repetition in the View code; that the Active Record piece, as it plays out, is very elegant, but the View and Controller pieces are very repetitive. And so we’re trying to dry up View and Controller.

The current Edge of Streamlined – and if anyone’s going to go download this, make sure you go and grab Edge, not the 0.0.7 release, because that’s ancient at this point – if you go and grab the Edge release, you’ll see that there’s actually a CRUD controller. And if you have CRUD – you’re done, if you’re basically just doing Create, Read, Update, and Delete.

The problem that we have with Streamlined, and the reason that we haven’t taken it to 1.0, is that once you say that you’re going to infer UI from relationships, then you need to support all the different relationship types. And it takes a fair amount of work to do each one of those.

You’ve got basic editing for the different kinds of data types that are likely to show up in a Rails app, but you don’t yet have all the different relationship types that are in Rails. And so, what you’ll see, when you build your app, is that maybe the ‘has-one’ relationship will automatically generate an appropriate UI for how you select that one, but the ‘has-many-through’ will generate a UI that says TBD.

Robert: [laughs]

Stuart: Literally, it’ll just drop TBD in the UI, and then you still have to write View code. I mean, in my view, that represents us incrementally moving towards a goal. In the open source world, people have come to have high expectations, and they want a complete solution – we’re not there yet; we know that there are various UI pieces that aren’t written yet. And probably some of the relationship types in Rails, and some of the more esoteric options, won’t be supported, even in the 1.0 release.

You’re no worse off – you still have to go write those; you’d have had to write them anyway. For the relationship types that are supported, essentially, you declare your relationships in active record and you’re done.

Robert: Very cool. The blog is relevancellc.com/blog…

Stuart: And Streamlined is at streamlinedframework.org

Robert: OK.

Stuart:...so the Relevance blog is us spouting off about software development, and then the Streamlined development stuff is at streamlinedframework.org.

Robert: Where can people attend the “This Week in Refactoring” summer tour?

Stuart: I have proposed, and will be proposing, the “This Week in Refactoring” talk at all the various places that I normally speak at. So, I hope to be giving a similar talk at the “Rails Edge”, when that comes up in Chicago. I’m begging to switch my current proposal to that today, so I hope to hear back about that.

I’ll be asking Jay Zimmerman, at the “No Fluff Just Stuff” Java symposium, to have me do that talk there. That venue is not hugely Ruby-oriented at this point, so it will probably be refactoring at the intersection of the Java and Ruby worlds.

So, I’m a committer on the JRuby Extras project. We may do some refactoring of some of the JRuby Extras pieces, or of the JRuby platform itself. There’s a lot of Java code in there that could stand to have some refactoring love. And most of the things that I did in the talk yesterday were not really Ruby or Rails-specific. They were more about good object-oriented design and having a tool set in place that lets you look around in the code and hunt for things that you could make better.

Robert: All right. Well, I’d like to thank you for sitting down with me today. And… thank you very much!

Stuart: Thank you very much, Rob. It’s been a pleasure being here in Columbus and being at the “eRubyCon”.

Robert: Thanks.

Geoffrey: Sponsored by PeepCode Screencasts. Current content on Rails 2.0 the Git source code control system, RSpec, and now with closed-captioning on the Rails from Scratch series.