On Community Funding of Open Source
drbrain |
The other day Yehuda Katz announced a kickstarter for creating Rails.app, an OS X application that makes it easy to bring new programmers to Rails and Ruby.
I think the idea is fantastic. When I first started learning Ruby I had to do battle with compilers, RubyGems didn't exist, the RAA had but a handful of libraries, and there weren't really even any tutorials for learning Ruby around. I had either fortitude or stubbornness on my side to get through the much steeper learning curve than many of you had to deal with to get where I am today, and it sucked.
I think the idea of soliciting community for funding is fantastic. It's not the first time a Rubyist has solicited money to work on open source. I funded Gregory Brown's work on Prawn a few years ago and was happy to do so even though I've never used Prawn (although I'd like to someday) I was incredibly happy to support it. I'll probably never use Rails.app, either, but that doesn't mean I'm not happy to support it, nor that Rubyists are wrong to support it.
Now, to get to my point, I don't understand why I keep seeing such negative feedback around Yehuda's choice of soliciting money to bring us Rails.app. Sure, it may just be a few of you, but if you don't want to give Yehuda money, fine, just don't. If you think Yehuda is asking for too much money, fine, just don't donate. If you just don't like Yehuda, fine, just don't donate.
But stop with the personal attacks, even the snarky ones and the jokes at Yehuda's expense.
You would not find it so funny if people were ganging up on you.
This is a fantastic idea Yehuda has presented and if he had the ability he would bring it to us for free. Right now he doesn't have that ability so he's asking for our help.
Being a major contributor to open source is incredibly difficult. While thousands or even millions of people may be happily using your software, you mostly hear from the people who are having problems with it, especially after they're extremely frustrated. Throwing insults atop this is incredibly demotivating and depressing, so cut it out.
If want to continue to complain, whinge or make cruel jokes, towards Yehuda or any other Rubyist, why not take that effort and put it towards something positive. Do something that is welcoming to new Rubyists like improving some ruby documentation, submitting a bug report or submitting a patch to fix a bug.
Stop making our community look like a bunch of jerks. It's fine if you disagree with another Rubyist, especially one who has contributed so heavily to Ruby, but you should have enough respect for them to be polite.
net-http-persistent 2.6
drbrain |
Manages persistent connections using Net::HTTP plus a speed fix for Ruby 1.8. It’s thread-safe too!
Using persistent HTTP connections can dramatically increase the speed of HTTP. Creating a new HTTP connection for every request involves an extra TCP round-trip and causes TCP congestion avoidance negotiation to start over.
Net::HTTP supports persistent connections with some API methods but does not handle reconnection gracefully. Net::HTTP::Persistent supports reconnection and retry according to RFC 2616.
Changes:
-
Minor enhancement
-
Net::HTTP::Persistent#idle_timeout may be set to nil to disable expiration of connections. Pull Request #21 by Aaron Stone
-
A use of Enumerable#chunk
drbrain |
In Ruby 1.9, Enumerable has a few new methods including Enumerable#chunk (which was added for 1.9.2). The #chunk method walks your Enumerable and divides it into chunks based on a selecting block. Unlike Enumerable#partition, the chunks are returned in-order. Here's an example from the documentation:
[3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5].chunk { |n|
n.even?
}.each { |even, ary|
p [even, ary]
}
#=> [false, [3, 1]]
# [true, [4]]
# [false, [1, 5, 9]]
# [true, [2, 6]]
# [false, [5, 3, 5]]When I first saw this method I thought, "this looks like a useful method… but how?"
I'm working on bringing Markdown support to RDoc and the last remaining base Markdown feature I need to support is a hard break due to two spaces at the end of a line in a paragraph.
For background, RDoc parses various formats into a common syntax tree which is can then be transformed for any supported output (such as HTML, colored ANSI text, etc.). In this syntax tree a paragraph can contain one or more strings which are joined at output time into the paragraph you see.
To add hard line breaks, I decided to create a new HardBreak object and inject it into the paragraph where two trailing spaces are encountered in the source document. The formatters can then be updated to insert the appropriate line break character when emitting a paragraph.
Enumerable#chunk comes in because the Markdown parser doesn't join strings as it's parsing (since the grammar rules get re-used) and is instead performed as a post-processing step. (String joining as a post-processing step also makes the parser cleaner by hiding the ugliness in one spot rather than spreading it across multiple grammar rules.) Before inserting HardBreak objects this was sufficient:
parts = paragraph.parts.join.rstrip
paragraph.parts.replace [parts]But now I need to join String chunks and include HardBreaks as-is which is a perfect use of Enumerable#chunk:
parts = paragraph.parts.chunk do |part|
String === part
end.map do |string, chunk|
string ? chunk.join.rstrip : chunk
end.flatten
paragraph.parts.replace partsThe 1.8-compatible implementation is much uglier since I have to track whether I'm in a String chunk or not in addition to performing the processing. I'm too embarrassed to post it, but you'll be able to find it in the rdoc source once I commit and push it.
hoe-travis
drbrain |
hoe-travis is a Hoe plugin that allows your gem to gain maximum benefit
from travis-ci.org. The plugin contains
a .travis.yml generator and a pre-defined rake task which runs
the tests and ensures your manifest file is correct.
With hoe-travis it is easy to add additional checks. Custom checks can be easily verified locally by simply running a rake task instead of committing and pushing a change, waiting for travis to run your tests, then trying a new commit if you didn’t fix the problem.
Features
-
.travis.yml generation task
-
Pre-defined rake tasks which are run by travis-ci
-
Easy to hook up rake tasks for additional travis-ci setup or checks
Getting Started
If you’re not already using Hoe with your project, see: docs.seattlerb.org/hoe/Hoe.pdf
To get started with hoe-travis, first install it:
sudo gem install hoe-travis
Then add hoe-travis as a plugin to your Rakefile:
Hoe.plugin :travis
Then generate a .travis.yml
$ rake travis:generate
This will bring up your EDITOR with your travis.yml for any desired tweaks. Save the file when you’re done, then check in your .travis.yml. For further details of how the configuration is generated see Setup at Hoe::Travis and Configuration at Hoe::Travis.
(If you don’t have the EDITOR environment variable set to your favorite
editor, please do so. Note that some editors may need extra flags to wait
for files to be edited. For MacVIM, export EDITOR="mvim
--remote-wait" will wait for the file to be closed before
returning.)
If you would like to make future changes to your .travis.yml you can run:
$ rake travis:edit
Which, like travis:generate, will bring up your EDITOR with
your .travis.yml. When you’ve saved the file the changes will be checked
by travis-lint before writing back to .travis.yml and give you a chance to
correct them.
If you’ve edited your .travis.yml by hand you can run:
$ rake travis:check
to check it.
Testing your travis-ci setup is easy with hoe-travis. You can run:
$ rake travis
to run the same checks travis-ci will. By default this includes running the tests and ensuring the Manifest.txt file is complete. There is also the before script:
$ rake travis:before
Which will run the setup tasks needed for your project.
You can also enable and disable travis-ci using rake
travis:enable and rake travis:disable. See
Setup at Hoe::Travis for details.
