Yet another reason not to use Solr. The discussion in this Jira issue is interesting.

The reason for this as I understand is to enable viewing the json response as as text in the browser.

Is there perhaps a more general feature we could turn this into? An expert level ability or parameter to set a custom content-type?

The problem right now is in the current class hierarchy of the response writers.

the NamedList is a weird datastructure for those who are not so used to Solr. You don’t know what is included in that unless you do an instanceof. Most of the users are happy to write out the documents

to handle this problem I would use ‘wt=json&wt.mime-type=application/json’

The idea is to take a phrase and analyze it for use in Information Retrieval. We need to tokenize it into words, possibly transmute some of the tokens, possibly expand some tokens into subphrases. This class lets you register lambdas to perform transformations, substitutions, and expansions. Expansions can take a numerical value representing the cost of the operation; this is intended for raising or lowering the scores of matches in the theoretical IR application.

Given the phrase “joe’s sushi & bait-shop shack”, assume I want to tokenize on whitespace, replace the ampersand with the word “and”, and create word variants for the hyphenized and apostrophized words. See the last spec for an example of the Ruby data structure this class generates.

Very simplistic rudiments of a spell checker in Ruby. Based on Norvig’s article.

Sometimes, when forced to work with Java, you just want to copy and paste some code and fiddle with it. A real project build system is overkill. Try Instant.rake:

New in JRuby 1.4 is JRuby Embed, which lets you eval Ruby from Java classes. It works, appears to be well-written, and needs some sugar. Here’s a class that limits your options in a helpful way.

Any software project not written in Java will clearly state on its homepage the implementation language.

“In our initial sketches for compositions, when memory has to take the place of the living model, we rely to a great extent on our anatomical knowledge for the suggestion of action and form generally. And again it adds materially to our faculties for self-criticism, which, like a sense of humour, is often, nearly always, our salvation.”
Solomon J. Solomon, The practice of oil painting and of drawing as associated with it

Knowledge of your tools is necessary, but not sufficient. The choices you make when planning the structure of software depend on your knowledge of the problem domain. A project is limited (sometimes crippled) by your comprehension of the form and motion and constraints of the body before you.

“It looks like it was made with, you know… longing. Made by a person really longed to see a swan”
Kaylee, Firefly

Self-criticism and a sense of humor are ineluctably linked, I find. Those who have not the capacity to criticize their own efforts lack most of the capacity to laugh at their own failings. If you don’t think it’s funny when you spend two hours failing to find a mindless bug in a simple depth-first traversal function, then you’re not me.

Jamis Buck is abandoning development of SQLite/Ruby, SQLite3/Ruby, Net::SSH and Capistrano. I do not say this derogatorily; Jamis owes us Capistrano like George R. R. Martin owes us A Dance with Dragons.

In the comments to that post, Dr Nic asked,

… were there ever “core contributors” who could be all added to the rubyforge project’s admin so they can start releasing new versions? Or did you ask all of them and no one said they’d take over the project?

Jamis replied:

“[T]here are no other core contributors. I tried once to create something like that, but no one else seemed to have the “passion” or “vision”. Lots of people submitting patches (many of them quite good!), but no one demonstrating a real, general desire to dig into the internals. That’s kind of why I left it like I did—there really wasn’t any heir-apparent that the keys could be left to.

“That said, if someone steps forward and seems to be getting community support (for any of the projects) behind them, I’ll be happy to give them admin access to the appropriate rubyforge pages.”

Rubyforge served a purpose for several years, and served it well. But Rubyforge is a bottleneck in the distribution of code, and this is exacerbated by the Ruby community’s reliance not only on RubyGems, but on the idea of the canonical, official version of a project. The increased popularity of distributed version control releases some of the pressue. GitHub has substantially reduced the friction involved in collaboration. Even so, the idea still holds that once a line of work is ready, you release it on Rubyforge, so that it’s official.

Good coders, even those not afflicted with a love of novelty, will eventually grow bored with their projects. The distribution model represented by Rubyforge cannot, or at least should not, long survive this human tendency.