defstr converts text to a C string literal that parses (by a C compiler) to the original text, and creates a C macro that defines it as a constant. The liternal preserves the original text's structure (line breaks, paragraphs, etc). defstr can be used as a tool for C/C++ code generation.

Demeter is back with a vengeance. Prevent your models from violating his sacred law and you shall be spared.

Open Drug Database for Germany. Live at http://de.oddb.org

YAML based deployment framework for your code.

Deprecatable is a library to help you, as a developer, deprecate your API and be proactive about helping people who use your library find where they need to update. When using Deprecatable, you mark methods as 'deperecated' and then the users of your API will receive a helpful alert showing the exact line of code where they called the deprecated API, and what they need to do to fix it (although you need to supply this piece of information). Users will receive, by default, a single alert for each unique location a deprecated API method is invoked. They will also receive a final report detailing all the locations where deprecated APIs were invoked. The "noisiness" of the alerting and the final report is all configurable, via both code, and environment variables. See Deprecatable::Options.

The dep_walker is small utility gem that checks dependencies for native extensions used by installed gems on Windows. If you are {RubyInstaller}[http://www.rubyinstaller.org] user and have seen message box: <em>"This application has failed to start because <name_of_dll>.dll was not found. Re-installing the application may fix this problem"</em> when you tried to use gem that has pre-built binariy extension, you've faced common problem on Windows systems - missing dependency dll. Same error might occur even if extension library was built during gem installation if all header files and libraries are available to the build tools, but runtime dependencies are not present. With dep_walker you can simply check all installed gems. Even more, if log is turned on, gem will print out information where dependency is found on the system, so you can check whether Ruby extension really uses correct version of required dll.

Derailer is a small program built out of a peculiar need. It started as a script to publish content generated using a Ruby on Rails application without actually running the application on the server. An over-enthusiastic Rails developer once made a quick site for a friend using a database and Rails simply because it was easier than hand-coding anything else, but didn't really think about the number of resources it would consume. Thus, derailer was born.

Spam detection plugin for Rails 2 & ActiveRecord 2. Uses all the standard Rails conventions and my Despamilator gem. Use the main (non rails2) version for Rails 3.

The DevCreek gem enables programmers to collect and transmit metrics from their Ruby Test::Unit and RSpec test suites to a DevCreek server. Please visit the DevCreek site (http://devcreek.com/index.html) for more info. == FEATURES/PROBLEMS: Supported frameworks include Test::Unit and RSpec (&gt; 1.10). == SYNOPSIS: The DevCreek Ruby Gem is library that, when loaded, will automatically listen to and collect metrics from your Test::Unit/RSpec unit tests. All you have to do is load the DevCreek library in your code and give it your DevCreek account info so that it can transmit the metrics to the server. Here is the simplest example of how to load DevCreek: -------- #Load the devcreek gem require 'rubygems' require 'devcreek' #set your account info DevCreek::Core.instance().load_from_yaml(&quot;#{ENV['HOME']}/.yoursettingsfile.devcreek.yml&quot;) -------- There are two ways to provide DevCreek with your account settings. The first (as shown above) is to point DevCreek to a settings file. The 'enabled' attribute tells devcreek whether or not it should actually transmit the metrics that it collects. The yaml file would like this: -------- user: your_devcreek_username password: your_devcreek_password project: your_devcreek_project enabled: true -------- The other way to provide DevCreek with your settings is via a hash. So, instead of loading a yaml file, you could do this: -------- #Load the devcreek gem require 'rubygems' require 'devcreek' #set your account info DevCreek::Core.instance().load( :user =&gt; 'your_devcreek_username', :password =&gt; 'your_devcreek_password', :project =&gt; 'your_devcreek_project', :enabled =&gt; true ) -------- The first method is preferrable because it allows you to keep your account settings outside of your project (and therefore your source control tool). If you only have 1 test file, you can place the code to load devcreek in the test file and your done. However, most projects will have many test files. In this case, you need to make sure that the Ruby interpreter loads devcreek before running the test classes. This can be done via the Ruby '-r' option. For example, assuming your code to load devcreek is in a file called foo.rb, you would run your tests from the command line like this: ruby -r foo.rb test/test_* If you run your tests from a Rakefile, then you need to tell rake to include the -r option when it runs the tests (rake runs it's tests in a separate Ruby process). You can do this pretty easily in your Rakefile, like so; -------- require 'rake/testtask' Rake::TestTask.new('all_tests') do |t| t.ruby_opts = ['-r foo.rb'] t.test_files = ['test/test_*.rb'] end --------

Ruby implementation of null file (like /dev/null on Un*x, NUL on Windows)

ruby wrapper for digg api

== DESCRIPTION: Need makes ruby relative requires just work. Simply need a file with a relative path and the file will always be required correctly, regardless of what file your application is being launched through. Typically, ruby projects would unshift lib onto $PATH or use the File.dirname(__FILE__) trick. Using need means you don't have to worry about either of these. Assume you have two files, one directly in lib and the other in lib/extensions. Let's assume that file_a in lib requires file_b, in lib/extensions. Previously, you would doing some crazy load path unshifting or use the __FILE__ trick to make these requires flexible enough to work when your app is being accessed by rake, through a test suite, or required as a gem. Now, just use need. In file_a: need{"extensions/file_b"} need "extensions/file_b"

tending allows you to add pending tests to your Test::Unit test cases

The Mechanize library is used for automating interaction with websites. Mechanize automatically stores and sends cookies, follows redirects, can follow links, and submit forms. Form fields can be populated and submitted. Mechanize also keeps track of the sites that you have visited as a history.

The Diff Match and Patch libraries offer robust algorithms to perform the operations required for synchronizing plain text.

Diggr is a ruby wrapper for the Digg API. Diggr strives to remain consistent with the Digg API endpoints listed here: http://apidoc.digg.com/CompleteList. Endpoints are created in Diggr with method calls. Each node in an endpoint becomes a method call and each node which is an argument becomes an argument to the previous method. As an example, the following endpoint /user/{user name} in which the user name is &quot;johndoe&quot; would be created with this Diggr call: diggr.user(&quot;johndoe&quot;) To send the request to the Digg API and retrieve the results of the call, Diggr requests are terminated in one of two ways. 1. Using the fetch method. By ending your request with the fetch method, your result will be returned to you. If the request is singular, you will receive a single object as a response. If the request is plural, you will receive a collection of objects stored in an array. 2. Using any Enumerable method. This works only on plural requests. In this case, it is unnecessary to use the fetch method. See the synopsis for examples of each of these types of calls. Options such as count or offset can be set using the options method and providing a hash of arguments. See synopsis for more information. Note: In an effort to remain consistent with the Digg API, some method names do not follow the ruby idiom of underscores. Although somewhat ugly, this allows a user to read the Digg API and understand the exact methods to call in Diggr to achieve their desired results.

See Plugin README: http://juggernaut.rubyforge.org/svn/trunk/juggernaut/README

Simple recursive walk through a directory, yielding the directory, filename and if the entry is a symbolic link.

API Wrapper for discogs.org http://www.discogs.com/help/api

Ditz is a simple, light-weight distributed issue tracker designed to work with distributed version control systems like git, darcs, Mercurial, and Bazaar. It can also be used with centralized systems like SVN. Ditz maintains an issue database directory on disk, with files written in a line-based and human-editable format. This directory can be kept under version control, alongside project code. Ditz provides a simple, console-based interface for creating and updating the issue database files, and some basic static HTML generation capabilities for producing world-readable status pages (for a demo, see the ditz ditz page). Ditz includes a robust plugin system for adding commands, model fields, and modifying output. See PLUGINS.txt for documentation on the pre-shipped plugins. Ditz currently offers no central public method of bug submission. == USING DITZ There are several different ways to use Ditz: 1. Treat issue change the same as code change: include it as part of commits, and merge it with changes from other developers, resolving conflicts in the usual manner. 2. Keep the issue database in the repository but in a separate branch. Issue changes can be managed by your VCS, but is not tied directly to code commits. 3. Keep the issue database separate and not under VCS at all.