g1nn13 fork changes: * added buffer() method to get image buffer for writing (to Amazon S3) * added fit_within() method to resize an image to fit within a specified height and width without changing the image's aspect ratio * added resize_with_crop() to resize and crop images where the target aspect ratio differs from the original aspect ratio. This is for converting portrait to landscape and landscape to portrait. ImageScience is a clean and happy Ruby library that generates thumbnails -- and kicks the living crap out of RMagick. Oh, and it doesn't leak memory like a sieve. :) For more information including build steps, see http://seattlerb.rubyforge.org/

Adds gemcutter release automation to Hoe.

Adds support for generation of gemspec files to Hoe. By default, excludes the signing key and certificate chain. Use <tt>rake gemspec:full</tt> to include the signing key and certificate chain.

A set of Hoe plugins for tighter Git integration. Provides tasks to automate release tagging and pushing and changelog generation. I expect it'll learn a few more tricks in the future. This is an evolution of +hoe-git+ by John Barnette, which has been archived at <http://github.com/jbarnette/hoe-git>.

Hoe plugin providing tasks used by hotelicopter, currently just the email plugin from the seattlerb plugin by Ryan Davis

kinetic_cafe_error provides an API-smart error base class and a DSL for defining errors. Under Rails, it also provides a controller concern (KineticCafe::ErrorHandler) that has a useful implementation of +rescue_from+ to handle KineticCafe::Error types. Exceptions in a hierarchy can be handled in a uniform manner, including getting an I18n translation message with parameters, standard status values, and meaningful JSON representations that can be used to establish a standard error representations across both clients and servers.

RubyPython is a bridge between the Ruby and Python interpreters. It embeds a running Python interpreter in the Ruby application's process using FFI and provides a means for wrapping, converting, and calling Python objects and methods. RubyPython uses FFI to marshal the data between the Ruby and Python VMs and make Python calls. You can: * Inherit from Python classes. * Configure callbacks from Python. * Run Python generators (on Ruby 1.9.2 or later).

MarketoAPI (marketo-api-ruby) provides a native Ruby interface to the {Marketo SOAP API}[http://developers.marketo.com/documentation/soap/], using {savon}[https://github.com/savonrb/savon]. While understanding the Marketo SOAP API is necessary for using marketo-api-ruby, it is an explicit goal that working with MarketoAPI not feel like working with a hinky Java port. This is release 0.9.1, targeting Marketo API version {2.3}[http://app.marketo.com/soap/mktows/2_3?WSDL], fixing a +syncLead+ problem where +Id+, +Email+, and +ForeignSysPersonId+ are inconsistent with other +syncLead+ parameters. This fixes an issue with Marketo campaign methods. Please note that Ruby 1.9.2 is not officially supported, but MarketoAPI will install on any version of Ruby 1.9.2 or later.

Bonus assertions for {Minitest}[https://github.com/seattlerb/minitest], providing assertions I use frequently, supporting only Ruby 2.0 or better.

helper.

Stockpile is a simple key-value store connection manager framework. Stockpile itself does not implement a connection manager, but places expectations for implemented connection managers. So far, only Redis has been implemented (stockpile-redis). Stockpile also provides an adapter so that its functionality can be accessed from within a module. Release 2.0 fixes an issue when Stockpile options are provided with an OpenStruct, originally reported as {stockpile-redis#1}[https://github.com/halostatue/stockpile-redis/issues/1]. Support for Ruby 1.9 has been dropped.

stockpile-redis is a connection manager for Redis to be used with {Stockpile}[https://github.com/halostatue/stockpile].

A handy dandy autoload / require / load helper for your rubies. Similar to using[1], but with a few differences of opinion, and a bit shorter. Basically, expand path is fine, up until a point. Sometimes there's no point (i.e. when the load path already contains most of the path you're trying to open). When you're writing libs that users might require sub parts with 'libname/sub_part', then expand_path combined with say, rubygems, can lead to double requires. Lets not do that. :-) [1] http://github.com/smtlaissezfaire/using/