Free to a Good Home: The Ruby Programming Shop

About a year ago, I started a project called The Ruby Programming Shop (or the RPS). Our intent was to adopt languishing Ruby libraries and give them some extra loving — add or update documentation, fill out unit test suites, refactor, update, and add features. We intended to take each project on for two or three months, so that we could cycle through four to six of them each year.

I'd envisioned the RPS as a way to help polish some of the resources available to the Ruby community, while giving less experienced Ruby hackers a chance to learn more about the Ruby way of doing things.

We made several attempts, but were only mildly successful with one of our projects, r43. I think this would be a great project for an active Ruby Brigade to jump on, with members working on it during hacking nights as well as at other times. An individual who wanted to head up the RPS could also do a good job if she's able to recruit, organize, and motivate a group of Ruby hackers to work with her.

If you're interested in taking the RPS over, please leave a message here with some ideas about what you'd want to do with it over the next year.

Why Ping is not an Acceptable Ping

Ruby has a ping in the Standard Library, but it's not a very good one. I really think it should be replaced, and there are a couple of options. Let me tell you what's wrong with the current ping. Then I'll lay out a plan for replacing it.

First, it's in the wrong place. Instead of being nestled in with net/http, net/smtp, and the rest of the net friends, ping is off in its own little world. This could be fixed if it weren't for a bigger problem.

Second, ping isn't even an implementation of the real (ICMP) ping. It only does TCP pings (by default on the echo port). And it's not called in a standard way. The documents recommend the following:

rb(main):001:0> require 'ping'
=> true
irb(main):002:0> Ping.pingecho("localhost")
=> true
irb(main):003:0>

There are timeout and service parameter, but no number of ping attempts and you only get back a boolean value.

We can do better than that. In fact, we already have. There are at least three implementations of ping floating around that could be merged to provide a sensible interface; the full range of TCP, UDP, and ICMP pings; and could live happily in net/ping. Is that too much to ask?

---

UPDATE: I wrote this on Friday, intending to post it this morning. In the meantime, Peter Szinek posted a message to ruby-talk asking if there were any way to get ping stats from Ruby. This is exactly the kind of functionality that we need to include in netping. I guess I was being more timely than I thought.

Wanted: Good Home For Ruby Projects

I'm involved in four different Ruby projects, and while I'm interested in all of them, I need to give them up. I'm in the middle of some changes (work related and taking on a bigger writing project) that are going to suck up any free time that my family doesn't already have claim on. Since these four projects have been languishing anyway, I feel the time has come to find new maintainers for them.

Over the next week, I'll post a separate announcement about each of them. I'll try to describe their current state and some suggested next steps. I'd love to stay around and might even make some minor contributions, but I can't promise anything. (Otherwise, I wouldn't be giving them up.)

Testing Advice?

Sean and I are both used to unit testing libraries, but now we need to broaden our reach a bit and work on an executable for CheckR. Since we really want to work test first, we need to figure out how to test it. This is something neither of us has really done. Anyone have some advice to share?

Catching Wrox Doing the Right Thing

A bit ago, I blogged about Apress doing the write thing at the MindCamp in St Louis. This time it's Wrox's turn to be praised — Jim Minatel wrote about the Atlanta CodeCamp on his blog. On thing that caught my eye (and I think reinforces my point about community being important) was that not only did they have authors speaking at it, but "[they]'ve actually got a pretty exciting project [they] worked on with code camp to unveil on wrox.com in a week or two."

That's the way it oughta be. Congrats to Jim and all the folks at Wrox who made it happen.

Red and Green for Ruby

One of my hacking partners dislikes it when I talk about my unit tests being green or red. Since running Test::Unit tests from the command line return "Plain Old Text", he's got a point. Since I don't think I'll change the way I talk, I decided to write a quick wrapper for Test::Unit to make things work. About 15 minutes later, I had RedGreen.

pate $ ruby test_good.rb | Redgreen Loaded suite test_good Started . Finished in 0.000485 seconds. 1 tests, 1 assertions, 0 failures, 0 errors pate $ ruby test_bad.rb | Redgreen Loaded suite test_bad Started F Finished in 0.001635 seconds. 1) Failure: test_char2num(TestCipher) [test_bad.rb:6]: Flunked. 1 tests, 1 assertions, 1 failures, 0 errors pate $

It's an embarassingly small amount of code. There are actually as many lines in the shebang and leading comments (name, description, copyright, license and version number) as there are of actual code. Nonetheless, it seems like a potentially useful little toy (at least to keep my friend happy when I tell him my tests are green).

If you'd like to use it, you can install a gem (it'll be in the repository shortly. Just do:
gem install --remote Redgreen

The Big-Box Publisher

The "big three" publishers, share a variety of traits once you abstract differences based on communities and approach. I'd like to look at some common benefits and drawbacks, then offer some advice for anyone in (or wanting to be in) this space.

Benefits of Being a Big-Box Publisher

I see three primary benefits to being the big box stores of the technical publishing world: economy of scale, a bigger set of resources to work with, and access to book stores.

Because these publishers are bigger, they can push for and get better pricing from their vendors (materials, printing, binding, and distributing, thus increasing their margin, allowing them to lower prices, or both.

Selling more books with a higher margin means more money is available to strengthen their position in the marketplace. This money might be used to provide books to Users Groups or to regional Conferences. It might be used to support less popular, but still important books. It might be used to fund other activities, like a conference.

Finally, because a publisher is well established, it is easier for them to place their books in a bookstore. Store owners are more likely to buy a new book from an established publisher than a new book from an unknown (there are certainly some exceptions, but I think they're rare enough to ignore).

Drawbacks to Being a Big-Box Publisher

I see three significant drawbacks: loss of connection to community, loss of agility and cost of reputation management.

Once a publisher reaches a certain size, I believe that they begin to lose there connection with the community — they become a provider to the community and not a part of it. Once this starts to happen, it's easy to become arrogant and lose sight of what the community really wants.

Being larger also means that it's harder to make changes in process or positioning. When things are going well this isn't such a big deal, but when there's an opportunity you need to act on now it can be a really big deal.

Finally, there's the cost of keeping your reputation up. Once you've made it big, it takes a lot of money and resources to stay there. You have to keep producing great books or suddenly you're "slipping". It's a treadmill that just keeps getting faster with each new success.

My Advice To Big-Box Publishers

If you're one of the big guys, and you want my advice, you're in luck because that's just what I'm going to give you. This may not be the game I'd like to be playing, but that doesn't mean that no one should. If you're happy here (or want to get onto the field), here are three things you should do.

First, be selective in which communities you join. Don't try to be all things to all people. I don't mean stick to one or two (or five or six) communities. Watch for new communities to form and when they match your goals, get involved.

Second, look to your chosen communities for guidance. Just because you're big doesn't mean you know what the community wants or needs. You might have been a driving force behind Perl, Java, or C#, but that doesn't mean the same things will work with Lua, Haskell, or IO. Get on the mailing lists, irc channels, wikis, and whatever else the community uses to communicate — and once you're there, listen and act on what you hear.

Third, foster growth in your chosen communities. As the community grows, so will your opportunities. Because you're involved in just a couple of communities, and because you're paying attention to them, you'll be able to make things happen. Will it be sponsoring user groups? (If it is, don't ship Perl books to the Ruby guys.) How about running a booth, a bofh, or an after hours bash at a conference? What about sponsoring a programmer working on some important tool or library in the community? (If you play your cards right, you'll also have the inside track on the best book about the new development.)

Wrapping Up

Okay, so you've read this far. Hopefully you've found some ideas worth your time. Do you agree with what I wrote? Have I missed something? Let me know.

Join me next time, when I talk about the Mom & Pop publishers.

---

This post is part of a collection of articles about Publishing, Growing Markets, and Books.

More writing about Ruby

Well, O'Reilly finally published my interview with Zed Shaw. You can read it here.

Apress did the right thing

Cory Foy just posted this little note about Apress providing goodies to the code camp in St Louis (where, I understand Cory made a great Ruby presentation). Kudos to Apress for supporting the community.

Wresponding to Wrox

Over on my post about the technical publishing market on Apress' Ablog, Jim Minatel was kind enough to chime in with his thoughts. I'm responding to them here because I think Jim makes some good points, and they fit in well with my ongoing series of posts about Wal-Mart and the Publisher.

---

Jim: Great comments. If I can chime in with what I think Wrox has already been doing in some of these areas:

Thanks for responding, and especially for being so open with your thoughts. I'm still a bit surprised at the openness you, Gary, and Tim have shown. I think it's a great sign of your honest interest in improving your chosen communities.

Jim:1. It's not just books:
our p2p.wrox.com discussion forums are a massive and popular developer destination, not just to ask book questions but to have great "how do I do this" or "why won't this work" or "what's the best way to" coding questions and actually get answers from other very good coders.

Discussion groups can be suboptimal if not well executed, though they are a great way to get involved in the community. They can fragment the user community, resulting in multiple isolated groups that are harder to search and confusing for newcomers ("Which one(s) should I join?"). They can be very low traffic, frustrating the users that frequent them. They can dilute your brand, hurting you worse than not having them.

It sounds like you're happy with the results you're getting from p2p.wrox.com, but I see some places you could improve.

• Some of your forums look very healthy (e.g., the XML pages), others are pretty anemic (e.g., the Ruby pages). Choose your communities carefully, and nurture them.
• URLs like p2p.wrox.com/forum.asp?FORUM_ID=195 aren't meaningful. Provide meaningful urls, they're more useful and more memorable.
• The individual forums aren't well branded to the communities they serve, while they all look like Wrox, you can't tell the Ruby from the Java at a glance. Establishing Wrox Foo branding for the communities you want to be a part of helps make Wrox a part of the community instead of a provider to the community.

Jim: We're in the infancy, taking baby steps, of posting more article length content online, both short nugget size book excerpts and original articles. The links to these are currently featured at the bottom of our home page. As this grows in success, look for more prominent placement and more sophisticated organization of the archives.

That's great news. I'd be interested to learn how your sales are affected as you become more sophisticated in placement. I believe you'll see improvements in sales and in community presence as you have greater cross linking between book pages, online content, and your forums.

Jim: conferences and magazines: I'll happily admit I've got a predisposition against investing in Wrox-run conferences or a Wrox magazine. I know from a couple of year stint working at a company that was a magazine and conference leader how hard it is to do those well and profitably and how easy it would be for a new comer to lose money. However, we are doing small things along these lines like sponsoring more user groups and small conferences like code camp. which brings me to:

I'd meant to throw online content, conferences and magazines up as examples, not as a standard to comply to. I think that each publisher should look for ways to become a part of their communities. For example, the Pragmatic Programmers are very active in the Ruby community mailing lists, irc channels, and even development.

You're right though that magazines and big conferences are an easy way to fail both spectacularly and expensively. It's good to hear that you're involved with user groups and regional conferences. I think these will provide a lot of value to both local groups and the larger community — and to you.

Jim: 2. Community.
I think the areas where we're having the most success, mostly MSFT dev topics, reflect where we've been able to be the most involved in the community too. "Get the best and the brightest to write for you." we've been real lucky in ASP.NET and the rest of the MSFT dev topics to really be building the community relationships and networks to make this possible.

Bravo! I don't have any visibility into this space (I'm a Ruby and Open Source guy), but it sounds like you're spot on to really succeed.

Anyway, I love that this discussion is happening. I'll have to go back and read some of the other posts. I'm a bit slow blog reading the last few days and must have missed the barbs.

I love it too. Thanks again for responding, and good luck with making Wrox a thriving publisher and community member.

You might want to read An Author's Story: a Cautionary Tale

---

This post is part of a collection of articles about Publishing, Growing Markets, and Books.

Back to Checkr and RSpec

In my last post on RSpec, I talked about cleaning up the stacktrace and exception thrown by the specification that I'd written. It turns out that this is all according to the design of RSpec, and the only way I'm going to get things cleaned up is to write some code to make things work — fortunately this is pretty easy to do. All we'll need to do is add a baz method to our Foo class, like so:

  def baz
   false
  end

Once we've done this, we're able to rerun our spec file, and everything looks good:

spec rspec_foo.rb
..
Finished in 0.000429 seconds
1 context, 2 specifications, 0 failures

None of this really feels like I'm testing behavior though, it's all pretty much normal TDD style test code. I'm going to junk the whole thing, and see if I can't make a better go of it. Before I start though, it probably makes sense to understand why I'm looking at RSpec for checkr.

When Sean and I talked about BDD, he identified three things that he felt were more in line with his thinking:

• We're specifying behavior instead of state.
• Creating smaller units of specification increases the cohesion of tests while decreasing coupling between them.
• There's no link between program and test structure.

If I go to work with these three things as my goals I should be able to get to an rspec file that does what we want. My new plan is to grab each test in test_check.rb, determine what behavior it's trying to test, and write a specification for that. I should be able to start that on Monday.

Walmart and the Publisher

After talking with a publisher about my last post about the technical publishing market, I have some additional thoughts

Brick and mortar retailers come in four varieties — big box stores, mom & pops, boutique stores, and farmers markets.

• Big box stores (like Wal-Mart) leverage their size to reduce costs and provide wide range of products of a consistent (and presumed lower level of) quality with a consistent level of service to their customers at a (presumed) low price.
• Mom & pop stores are a part of the community and rely on that relationship to provide the variety and quality of products and services that the community wants at a price the community will bear.
• Boutique shops provide high end or hard-to-find products to a community, often at a (perceived) premium price.
• Farmers markets provide a meeting place where community members buy and sell the goods that they've produced to one another.

Publishers can be broadly lumped into four similar classes:

• There are larger publishers who cater to a broad range of technical areas, specializing on getting a broad selection of titles to market quickly and keeping their prices down. This group is similar to the big box stores. The "big three" from my last post (Apress, O'Reilly, and Wrox) fit into this group — and no, I'm not calling anyone the Wal-Mart of the tech publishing world.
• There are smaller publishers who work hard to be a part of the communities they cater to, and are similar to the mom & pop stores above. The Pragmatic Programmers are the best example of this category.
• There are specialty presses that trade on their reputation to sell their product, often with some additional cachet because of the name. This class corresponds to boutique stores. 37 Signals seems fit into this group.
• The last group are the self-publishing authors and companies who sell (or sometimes give away) their materials to other members of the communities they belong to, these are like the people behind the tables at your local farmers market. This blog (among others, cafe press stores, etc.) is an example of this model.

What does all of this mean? I think that the class a publisher belongs to has a lot to do with the way it perceives a community (and is perceived by that community). That perception colors the decisions the publisher makes about what to publish, how to market, and how to approach the community. Over the next week or so I'm going to write about each of the four kinds of publishers.

In the meantime, this leaves me with some questions that I don't have answers to:

• How does the class of publisher affect its sales?
• Can a publisher straddle classes?
• If you're a publisher and can only pick one class, which one do you shoot for?
• If you're a consumer, what kind of publisher do you want to support?

Let me know what you think. I'm pretty sure there is another post or two hiding in there.

---

This post is part of a collection of articles about Publishing, Growing Markets, and Books.

A Rising Tide Lifts All Ships

Okay, back to some Ruby stuff. The other day, I mentioned that our hacking night had worked on a couple of bugs and that matz was committing one of our fixes. The problem was in syck, which is also used (albeit, not in the standard library) by Python and a bunch of other projects including: Perl 5, Pugs (Perl 6), Lua, Cocoa, and Haskell. The real win here is that the work done by urug/utahvalley.rb just fixed problems for YAML users in a bunch of other languages. Hooray for library sharing!

The Technical Publishing Market — a whole 'nother look at things

Gary Cornell, Jim Minatel and Tim O'Reilly have been trading statistics, insights and barbs over the technical publishing market recently. I've been reading them with a great deal of interest because what they have to say strongly affects me as both a producer and a consumer of technical materials. I think each of them is looking at the whole somewhat myopically though (bold words for someone without nearly as much time or effort invested as any of them). Here's my take.

The technical publishing market is about more than just books. In fact it's more than just a market — it's a community, and the publishers who misunderstand that do so at their peril. It's about more than the "big three" (Apress, O'Reilly, and Wrox) — there are a lot of "little guys" too (the Pragmatic Programmers, Manning, No Starch Press, etc.), some of these have distribution or other agreements with the "big three" but they're still out there. Let me touch on each of these ideas briefly.

It's about more than just books. O'Reilly seems to grok this. They produce on-line content, a magazine, and conferences — this helps make them a destination (and, I'm sure, bolsters book sales). Apress seems to be making steps in this direction (with this blog, for example), but could make some changes and really make up some ground here. I don't follow Wrox as closely, but it seems like they would benefit from moving beyond books too.

It's a comunity, not a market. In some ways, this ties to the last point. It's important to be involved in the general tech community and the specific communities around the fields you want to publish around. If you want to hit a home run in the Ruby space, get on the mailing lists, contribute code, and get the best and brightest to write for you. This is where doing more than books will help. Apress has a lot of Java and ASP titles but this blog doesn't even feature a specific Java or ASP page. There is no reason there couldn't be an ablog.apress.com/java/ page with its own Apress Java branding, some featured content and cross links to and from Apress Java titles. This would draw eyes and make Apress a bigger part of the Java community — ablog.apress.com/?cat=6 just doesn't cut it.

It's more than just the "big three". Smaller publishers like the Pragmatic Programmers are revolutionizing the technical publishing market. The Pragmatic 'Beta Book' program showed everyone what beta books done right can be. Smaller publishers can also maintain a higher quality image, making new books by some publishers a must have sight unseen. Recognizing the value these publishers bring to the community and gleaning the best they have to offer can only help the market as a whole.

---

This post is part of a collection of articles about Publishing, Growing Markets, and Books.

Hacking Night — May 2, 2006

We had a small group last night (only three people), but we still had a productive hacking night. Kevin, Devlin, and I decided to work on Ruby. Since we've got access to the Coverity scan data, we thought it would be worthwhile to look at some of the defects to see if there were reasonable ways to fix them.

We looked at four problems, identified one of them as a likely false positive, and provided patches for the other three. All of the patches ended up being one or two lines of code changes, little things that are easy to lose in a big pile of code. All of our changes have been posted back to the ruby-core mailing list, and hopefuly will be applied soon.

They may have to wait a bit though, as matz posted a message saying that he was in the middle of a large set of changes and it might be a couple of weeks before he applies incoming patches. Hopefully ours are small and simple enough that they can be snuck in quickly, without disrupting matz' work.

---

postscript — Today, as I sat on the bus in to Salt Lake, someone sat down next to me and opened up a copy of Agile Web Development with Rails. We started talking about Ruby, and it turns out that he works with the guys who are driving the urug/slc.rb. Since he lives down close to me though, I invited him to come out to our urug/utahvalley.rb meetings/hacking nights. Hopefully we'll have a new member to help bolster the ranks.