Zed Shaw cut a new release of Mongrel today (0.3.13.3). In addition to a couple of bug fixes, it also features new licensing, being released under the same terms as Ruby instead of the LGPL. Zed says this is a first step along the path to getting Mongrel into Ruby.
Go Zed!
PS Zed's also settled on a mascot for Mongrel bugs ... sadly, it's a dog, not a flea. You just no convincing some people.
The current lawsuit by FireStar Software (Bad litigant, no link for you.) against Red Hat over the use of Object Relational Mapping (ORM , or the ActiveRecord Pattern could spell trouble for Ruby on Rails.
The gist of the matter is that FireStar claims to have invented this technology, and holds a patent on it (Patent 6,101,502.). While their patent dates back to 1998, there is some significant question about prior art and obviousness. If this suit is upheld, the heart of Rails would become vulnerable to a similar suit by FireStar.
Even if the suit against Red Hat fails, how many other patent infringement lawsuits are lurking beneath the surface? The danger of software patents has been understood by many developers in the Free Software world, but it's time to work harder at getting the message out and pushing for a change.
If you haven't gotten involved already because you thought it wasn't worth the effort, it's time to ask yourself "How much is Rails worth to me?"
After a hugely successful RailsConf this year, I've seen an interesting note about next year's. O'Reilly will be co-producing it with Ruby Central (according to gnat).
I wonder if this will bleed over into RailsConfEurope and RubyConf as well, and if it does how that will affect those conferences. This year's RubyConf is still going to be capped at 240 attendees according to my sources (I'm gussing there will be a registration stampede). This should keep it a nice cozy event, but might force some adaptions. I'm really hopeful that it will push more Ruby Brigades (or groups of them) to host local Ruby Conferences.
We enjoyed a pretty good meetig last night. Lots of talk about RubyConf:
We worked through the current RubyQuiz, going test first. It was pretty fun, and everyone got involved. I shot a video of the whole thing. Tonight, I plan on checking the quality to see if it's worth pushing up to Google.
Summer can be a hard time for Ruby Brigades, since there's so much else going on. Hopefully having fun meetings every month, even if they're lightly attended, will help us recapture our momentum when Fall comes and the students all come back.
I posted about RailsConf 2006 over at Linux Journal this morning. One thing I forgot to mention over there is that there's a new release of Mongrel out — 0.3.13.2. According to the announcement, it sports:
From the reports that I've read, Mongrel seems to have gotten a lot of positive notes at RailsConf. Good for you Zed, keep up the good work.
What are your plans around copyright survivorship? (I.e., if developer.* goes under in 5 years, what will happen to the book(s) in your catalog at that point?)
Daniel: This is a great question, and an important one for authors to consider when hooking up with a small pubisher. We try to cover this base in two primary ways: First, from a legal standpoint, our book contract stipulates that if developer.* Books is not keeping the book in print and available for sale, then the author can take the publication rights back and find another publisher.
And second, as I mentioned, we try to do business in such a way that we can keep this going. For example, we would not be doing our authors, collectively, a good service if we were to take on a high-risk title that requires me to take out a second mortgage on my house and quit my full time job to make it happen. Part of the strategy behind our choice to use digital printing technology is to ensure that we can keep a title in print indefinitely. With offset printing and traditional distribution, you have to spend real money to print and store large numbers of books. Even if at some point we decide to not produce any new titles, we want to be sure no authors whose books we have published are left out to dry.
I just finished reading Software Conflict 2.0 by Robert L. Glass (published by DeveloperDotStar). It's not really a Ruby book, but I think it's worth a read by most of the Ruby hackers I know. (I'v already recommended it to several in person — and now I'm recommending it to you.) The back cover calls this a neglected classic, a commment I agree with. I'm sad to say that I'd never heard of this book before I got it, but it certainly reads like a classic and belongs on my shelf with other books of its class.
Software Conflict 2.0 might be a new edition of a twenty-five fifteen (written in 1991) year old book about the state of software engineering, but its focus is on the ideas behind technology have helped it withstand the test of time. It's made up of six groups of essays (sixty in all) about timeless topics. Instead of updating the individual essays, Robert Glass has written a retrospective for each section. This approach works quite well. I was surprised at how often I would read an essay and think "Wow, that really foreshadows Agile programming" (or Open Source Software, or whatever), and then found the retrospective echoing my thoughts.
This might not be a book that sits on your desk, ready to guide you through your day to day work. It should be on your reading list though, ready to guide you on an engaging journey through the foundations of software development. It'll make you a better Ruby programmer, not because it will improve your Ruby skills, but because it improves your programming.
Updated Daniel Read of DeveloperDotStar was kind enough to point out that I completely botched the age of the original edition. I've updated it above. Thanks Daniel.
This evening, I sat down to check my email and saw a real beauty from someone I'll call Jim. Jim's not a native English speaker, so I'm willing to forgive murky grammar. I'm not so forgiving of the lack of effort on Jim's part before asking for help. Here's what Jim wrote, my comments are inline:
Hi
I am a Jim,a php programmer I am interested to learn ruby and I tried to install it on my system ,ruby(1.8.3) is working now but I want to install rails too ,
Okay, so if you're looking at Rails at all, you should probably know that it's best to use ruby 1.8.4, and version 1.8.3 is right out. At least read the docs before you ask for help.
for that I installed ruby gems 0.8.11 and installed I think .After that I have supplied a command to install rails " gem install rails --include-dependencies". shows Local installation error and trying to remote installation
Have you tried installing anything else? Did that work? Can you show me the actual error you got? This really isn't the kind of bug report/help request that's going to make someone want to help you.
I expect you immediate reply
I hope this is just an English as a second language problem, otherwise it's awfully rude.
thsnks in Advance
The worst part of the whole thing is that Jim emailed me directly, he did not try the Rails list, he did not pass go, he should not collect $200. I'm not even that much of a Rails guy. How did Jim pick my name out of the hat?
If you're having problems with Ruby or Rails, there's a community full of people wou would love to help you — if you'll follow a couple of rules:
Yesterday, I made my first Linux Journal Blog post about the .Net Ruby announcement and I asked about how this and other similar projects could help each other instead of duplicating each others work. Two Jruby core developers (Charles O. Nutter and Thomas E Enebo) gave me some pretty good feedback.
Charles' feedback went further than he thought though. He's currently got a post up on his blog about getting Mongrel ported to JRuby (it needs to be ported because there are ~1400 lines of C that will need to reimplemented in Java). Zed Shaw, the author of Mongrel, has dropped some comments there.
It looks like there's a good interchange of ideas flowing between the developers from the two projects. We need more cooperation like this.
I originally wrote this material for IBM. It was previously published as part of an IBM DeveloperWorks Tutorial located here. IBM has been gracious enough to let me republish it here.
To find RDoc in use, you only have to look as far as the standard library. Abbrev.rb (the first library, in asciibetical order) includes a number of good examples. The block of comments shown in Listing 1 forms the documentation for the Abbrev module. Using RDoc, you can convert these comments into an HTML document fit for serving via a Web server or for browsing from the command line. Listing 2 shows the RDoc generation as viewed through ri. See the HTML output (notice that the HTML provides a link to the source code for the method(s) being described).
|
|
In Listing 1, you can see several kinds of markup. First, because this block of comments immediately precedes the line module Abbrev, it's treated as the documentation for the module as a whole. Second, the indented lines are treated as sample code and are displayed in a typewriter style font in HTML (no special treatment in ri, though). Third, <i>Generates</i> puts the word Generates in italics (at least, in HTML; in ri, it's shown with leading and trailing underscores). Last are the + symbols surrounding the terms abbrev and Array; these words are also treated as code. And because Array matches the format for a module or class, it's turned into a link to the Array method documentation for abbrev (in HTML).
RDoc isn't confined to comments in Ruby code; you can use it to comment C code, as well. Listings 3 and 4 show a portion of range.c and the ri output created from it. You can see more markup here: the :call-seq: keyword and the <code></code> tag. The tag is easy to understand. :call-seq: identifies the following lines (up to a blank line) as the calling sequence for the method.
|
|
In addition to using RDoc to comment your code, you can use it to mark up README files and the like. The markup is sparse enough that it doesn't hurt readability when unprocessed, while allowing the creation of HTML files that can be used with online documentation -- a method used by many Ruby libraries and applications, including r43 and Rake.
If you want to document your Ruby code and use RDoc to do it, you need to know a few things. The following three sections discuss block commands, markup, and directives.
You can create blocks of documentation in two ways: with # characters on successive lines of code, or with =begin and =end markers. You've seen the former already; the latter is shown in Listing 5. This listing also shows an additional pair of block commands: #++ and #--. These turn off RDoc processing and turn it back on again, respectively.
|
You can use a number of symbols (they're not tags, for the most part) to mark up your documentation. You can put words into italics with _ or <em> (the former for single words, like _this_, and the latter for <em>groups of words</em>). Bold text is created with * or <b> and typewriter font with + or <tt> (all of which follow the same convention as the italic markup for single words vs. groups of words).
To create bulleted lists, begin indented lines with an * or a -. Indented lines starting with digits create numbered lists, and an indented line starting with a letter followed by a period creates an alphabetical list. You create dictionary lists, also known as description lists or labeled lists, by putting the label in square brackets or following it with a double colon. The definition (or description) can be placed on the same line as the label or on the following line.
Rules are created with three or more consecutive hyphens (---). Headings are created with one or more consecutive equals signs (=, ==, and so on) -- the more equals signs you use, the higher the level of the heading.
You can also create hyperlinks by adding the URL in square brackets after the term to use as the link: term[url]. If the link is more than one word long, it needs to be surrounded with curly braces: {multi word term}[url].
RDoc allows for a number of processing directives. Directives are words surrounded with colons, like this: :directive:. :call-seq: (seen in Listing 1) is a good example. Some of the most used are :yield:, :title:, :nodoc:, :include:, and :enddoc:.
:yield: is used to override the name of yielded objects. For example, Listing 6 shows two snippets of code. The first produces documentation like this: foo() {|first, second| ... }. The second produces this: foo() {|bar, baz| ... }.
|
:title: sets the title for the document. You use it like this: :title: The Document Title.
:nodoc: specifies that the current element won't be documented. You can give it the optional argument all, which turns off processing for all subordinate elements.
:include: inserts the contents of a file at this point in the documentation. Files are searched for in the directories listed in the --include option and in the current directory. You specify the filename like this: :include: file.
:enddoc: turns off processing for the remainder of the current element. Subordinate elements are still processed.
I originally wrote this material for IBM. It was previously published as part of an IBM DeveloperWorks Tutorial located here. IBM has been gracious enough to let me republish it here.
What better example to show you dRuby in action than an ASCII duck image server? Why_ wrote it to show off a number of ASCII art ducks created on the ruby-talk mailing list.
The server code is simple:
|
Only a few things are going on here. First, Why_ uses $SAFE and untaint to help control access to just the files to distribute. Setting $SAFE to 1 turns off the ability to process tainted data (data is considered tainted when it comes from outside the program). Because the file names used in the next step are tainted, Why_ uses untaint to regain access to that data. This is a good example of an important concept for anyone writing code that will be executed by untrusted users.
The next couple of things occur in the Duck class (notice that this class doesn't need to know about dRuby). Why_ starts with meta-programming, creating a method for each duck image file that displays the contents of that file. Then a method prints a listing of all the available images.
Now, Why_ uses dRb (the dRuby library). It just takes one line to start a dRb server that serves up an instance of the Duck class (which creates a separate thread behind the scenes). Finally, Why_ joins the thread to ensure that dRb is finished before the process exits.
A client for this server is also simple. You can run it from the command line: ruby -rdrb -e
"DRb.start_service;duck=DRbObject.new(nil,
'druby://whytheluckystiff.net:6503');puts duck.list".
Running Ruby from the command line is a different idiom from what many people are used to, but it's not too hard to grok. The -r switch requires the dRb library, and the -e switch says to run the command(s) that follow. In this case, the command does three things: It starts a dRuby service, instantiates a Duck object from the dRb server, then does a puts of the output of the list method.
If you want to use dRuby yourself, Why's duck image server has shown you the two things you need: DRb::start_service and DRb::thread.join. Using just these two methods, you can create a simple server of your own, as shown in Listing 2.
|
You probably want to do a bit more than this, though. A good first step is to add some security. Again, dRuby makes it easy. DRb#start_service accepts ACL objects (which can also be defined separately), allowing you to lock your new service. The simplest ACLs (although not the most secure) are IP address-based. If you're running the Morse code service shown in Listing 11 on a machine in the 192.168.1.0/24 network, and you want to limit access to only those hosts on your local network, you can define an ACL as shown in Listing 3.
|
You should do all you can to write safe and secure code. Use $SAFE, and think about using undef to get rid of unsafe methods. Don't forget, you're potentially opening up your code and your server to unknown users.
Lately I've been trading email with Daniel Read of Developer.*. Our conversation has given me some great insights into the working of a 'Boutique Publisher (see Walmart and the Publisher for more details' He's given me permission to excerpt some of our conversation here. I hope you enjoy these snatches of conversation.
How do you know what to write about?
Daniel: An individual title emphasis arises naturally out of what we're doing because of a variety of factors, including the fact that we are very small and only able to produce a certain number of titles. (developer.* is a business to be sure, but also a hobby since I have a full time software development consulting job that's first priority.) Perhaps more importantly, though, our titles will tend to be unique, harder to categorize, and not so much competing head-to-head with other similar titles. Our primary competition is simply the diversity of reading options available to people, and with the perception that only "technical" reading is important.
I've never been a professional programmer. I hack in my off time and occasionally do some programming in support of my day job. I've worked with a lot of programmers though, and I often pick up ideas from them, or see them exercising skills in ways I want to emulate. Recently, I've seen something else I want to do.
We just hired a programmer here at work. He's a bit new to Ruby, but he's already hard at work turning out some system monitoring and recovery scripts or us. One of the things He's doing is memorizing the Ruby core classes. Both what classes are available and the methods and their signatures.
I've never worked like that. I just use the language, looking up what I need to, until parts of it become second nature to me. That leaves me with some pretty incomplete coverage. To make matters worse, If I don't keep using the knowledge I've gained, I'll forget it.
Memorizing these classes and methods doesn't seem like a bg investment, but I can already see the dividends it's paying off for him. I guess it's time to whip up some flash cards and get to work.
I've noticed a lot of German readers, so I thought I'd put this up here. My family and I are going to Germany for a short trip in early August. We'll be in Berlin, Heidelberg, and Frankfurt. I'd love to meet up with Rubyists if anyone is interested. Feel free to drop a comment below if you're up for something linke this.
This should have been a weekend in which I got a lot of Ruby stuff done. I was motivated (read on for why) and I thought I'd have time (read on for why I didn't). Somehow, the fates conspired against me — I just hope next weekend works out better.
I've written a little about RedGreen — a little hack I tossed together recently. I've gotten a lot of positive feedback about it, including a complete rewrite that turned it into a test runner (and set up colorizing the intermediate results; the 'E's, 'F's, and '.'s). I've also been talking with Eric Hodel about moving it into ZenTest. Needless to say, I was pretty excited about working on incorporating the test runner, and getting the whole thing up to Eric's and zenspider's coding standards.
The only things on my docket for Saturday (the day I'd planned on hacking) was a party for the boys that are joining the Boy Scout Troop I work with. I was going to grill hamburgers and hotdogs, and go over some basic scout skills (knot tying; fire safety, flag etiquette; and reveiwing the Oath, Law, Motto, and Slogan). It turned out that the boys needed a lot more help than I'd thought (and we needed to clear up some requirements for their current Cub Scout advancement before the "bridged" into my troop). My one hour commitment turned into a three hour marathon. I also ended up needing to buy a new video camera for our upcoming vacation and a school assignment my daughter needs to finish by Tuesday — the basic research, comparison shopping, and then picking up needed accessories sucked up most of the rest of the day.
There is a silver lining to my cloud of gloom though. I'm going to be in Seattle next weekend, and I'll be hacking with the Seattle.rb while I'm there. Maybe Eric, zenspider, and I can get several cool new features into RedGreen, then move the whole thing into ZenTest. At least, that's my plan at this point.
I'm finishing up an interview with James Edward Gray II. As in a lot of interviews, there are some things that won't make it into the final article. One of them was some advice about starting a Ruby Brigade.
If someone wanted to start a Ruby Brigade, what advice would you give them?
James: Put the feelers out and see if you get any bites. If even two others respond, that's a group! Pick a meeting time and get the word out. I was pretty sure I could get three people to the first meeting, and we had over 10. "If you build it, they will come..."
Sean, the hacking partner mentioned in my announcement for RedGreen, seems to like it. This morning, he whipped up an 10 line patch (5 new lines, and 5 changed lines) to add RedGreen to autotest (part of the ZenTest package).
I originally wrote RedGreen in a fit of humor, but it looks like I may need to give it some more respect. I've gotten comments telling me how to add Win32 support and making a suggestion for improving it's ability to work better from within Rake. I've seen it on del.icio.us and ozmm.org. I've even seen google searches for it in my logs. I'll try to take an hour or two this weekend to do something nice for/to it, and send out a release on Monday.
Who'd have thought a silly little snippet of code would be so worthwhile? Next time, I'll try to take my little jokes more seriously.
I recently interviewed Luis Lavena (a Ruby hacker from Argentina), during that interview he talked about the lack of Ruby information in Spanish and what a problem that was for Spanish speaking Ruby hackers. I suffered through 'Japanese Ruby envy' when I first started working with Ruby, and I know that the same situation exists in other languages today.
As the interview progressed, I felt a growing urge to do something about the lack of materials in other languages. Now, I understand enough Spanish to muddle through some simple text and speak enough German to be able to get around Germany without too much trouble, but I'm not a translator. I do know people who can translate though. Thus an idea was born.
Starting with my interview with Luis, I'm going to try to get translations of as much of my writing as I can. Luis and his friend Pedro Visintin will be helping with Spanish. Andreas Wolff will be working on German translations. Ladislav Martincik has volunteered to try translating into Czech (starting after this interview). I'd love to see other bloggers/authors and translators join us. If you're interested, send an email to pat dot eyler at gmail dot com and let me know. I'll try to coordinate things.
By the way, You can read my interview with Luis at:
Lately I've been trading email with Daniel Read of Developer.*. Our conversation has given me some great insights into the working of a 'Boutique Publisher (see Walmart and the Publisher for more details' He's given me permission to excerpt some of our conversation here. I hope you enjoy these snatches of conversation.
Who are you writing for and how does this affect your marketing?
Daniel: Certainly the same person who is looking for a good Java reference might also really enjoy our book Software Conflict 2.0, but it's more difficult for us to catch that person at the right moment. This hypothetical programmer/reader spends a great deal of time in a state where it's important have a good Java reference at hand, but a much smaller amount of time during which he or she is in a more contemplative state, ready to invest time in something that's not obviously applicable to today's programming tasks, ready to be challenged, seeking to be surprised, to learn something unexpected.
Not only do we as publisher have this "smaller slice of the day" challenge with our target readers, but we also have to contend with the fact that a huge percentage of our *potential* readers are not tuned in at all. Partly this is because a large number of software professionals, in their entire careers, simply never seek out reading material beyond straight how-to/reference that's directly applicable to their jobs.
Also, however, I think many people will not start seeking out "general interest" books like The Mythical Man-Month, Peopleware, or The Parnas Papers until later in their careers. When I was a younger programmer, I was intensely interested in learning everything there was to learn about the new tools coming out (and I still keep up with this kind of reading a good deal), but over time my interests expanded, especially as I realized that the technical stuff is often the easy part.
So our challenge is to find the readers who have already developed an appetite for a diversity of reading material, and to entice a few of the pure-technical readers to make a little time for a different kind of book.
This is the most convoluted of the projects I need to give away. I'm really not the owner of it, but I had agreed to work with Christian Gross on a Ruby implementation of Jaxson (his Ajax Pattern Framework). If you're up on Java or C# and want to help to help port this framework to Ruby too, get in touch with me. I'd be happy to introduce the right hacker to Christian.
r43 is the most stable of the projects that I need to give up. It implements nearly all of the 43 Things API (it doesn't handle the posting related methods), and has a comprehensive test suite (98.2% of the code is covered by the test suite according to rcov) — although I sometimes run into problems with methods in the API breaking on the server side.
A good first step for the new maintainer of r43 would be to audit the package against the 43 Things servers, and cut a 1.0 release. This could be followed with development of the posting functionality, and/or some general refactoring and the development of user level docs. At one point, we were going to develop some Rails tools to use r43, this could be a good project too.
Are you interested in taking on r43? Add a comment below telling me what you'd like to do with it. This could be a great introduction to managing a Free Software project for the right developer.
rwb (the Ruby Web Bench) is a great idea that needs some work. This is probably not a project for a first timer, as it's going to need some time and effort to really shine.
rwb is intended to provide a tool for performing capacity or functional tests against a website. It differs from existing tools (like ab or httperf) in that it's extremely configurable. You can write testing scripts that define weighted lists of URLs and view the results in a number of ways.
The current implementation has some problems though, which will need to be cleaned up:
I think that pulling in the http client implementation from httperf would solve two of the problems above (it's GPLed, so it's available). The others will require some Ruby hacking.
If you're interested in taking over rwb, post a comment below. Tell me about your thoughts, and let me know why you think you're the right person for the job. In the right hands, I think rwb can really become something special.
Make no mistake, the Mom & Pop operation is the publishing/community sweet spot as far as I'm concerned. It's the place where the needs of the community get the most play in the decisions and direction of the company — and, if ignored (or misread), will spell the doom of the publisher. This level of dependence ensures that the Mom & Pop publisher will stay close to the community.
When I was twelve years old, my friend and I raised money the traditional way, mowing lawns and running a paper route. Then we spent it the traditional way (for twelve year olds), at the corner candy and comic shops. The workers at these shops knew us by name, they knew what we liked, and they took the time to talk to us. That meant that they could upsell and cross-sell pretty effectively. It also meant that they knew what kinds of things to stock. There was no corporate headquarters telling them not to stock chocolate-covered raisins, they knew Marty and I would be there to buy them every Wednesday. even if there had been a near-by big-box store back then, our stores had won our loyalty by treating us like friends, not nameless customers.
The Mom & Pop publisher is going to be the same way. They're involved enough in the community to know what books are needed/wanted, and who the best people are to write them. Even better, they have the trust of the community to produce the right thing. Because they tend to be smaller shops, with less history behind them, they can be more flexible about what they do and how they do it, they can respond to their community — to borrow a phrase, they can be agile. Finally, because they're in the community, they have a very short feedback loop. If they're doing something wrong, they hear about it while they still have time to recover.
This isn't to say that the life of a Mom & Pop publisher is all roses. They have plenty of problems of their own. It can be hard for them to manage there supply chain (witness Manning's underestimation of Ruby for Rails sales. They sold through their initial printing before they even got their first run back from the printer). In some cases, it can be difficult to get books placed in traditional book stores — and once you're in, it can be hard to get the premium locations. Being small can work against you in the cost department too, you don't get the printing, binding, shipping, and other discounts that someone doing ten or one-hundred times your business will.
What can the Mom & Pop do? I've got four ideas to share:
Hopefully, these posts are worthwhile. I know they've helped me work through my thinking about publishing and writing. They've also helped me discover some new publishers. I'd like to hear your thoughts about this. Please post a comment below to let me know what you think about Mom & Pop publishing, or tech publishing in general.
This post is part of a collection of articles about Publishing, Growing Markets, and Books.
