Segment7

mechanize 2.3

2012-02-20T17:18:20-08:00

The Mechanize library is used for automating interaction with websites. Mechanize automatically stores and sends cookies, follows redirects, and 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.

2.3 / 2012-02-20

Minor enhancement
- Add support for the Max-Age attribute in the Set-Cookie header.
- Added Mechanize::Download#body for compatibility with Mechanize::File when using Mechanize#get_file with Mechanize::Image or other Download-based pluggable parser. Issue #202 by angas
- Mechanize#max_file_buffer may be set to nil to disable creation of Tempfiles.
Bug fixes
- Applied Mechanize#max_file_buffer to the Content-Encoding handlers as well to prevent extra Tempfiles for small gzip or deflate response
- Increased the default Mechanize#max_file_buffer to 100,000 bytes. This gives ~5MB of response bodies in memory with the default history setting of 50 pages (depending on GC behavior).
- Ignore empty path/domain attributes.
- Cookies with an empty Expires attribute value were stored as session cookies but cookies without the Expires attribute were not. Issue #78

Ten Years of Seattle.rb

2012-02-16T13:39:01-08:00

We're throwing a part for the tenth anniversary of the Seattle Ruby Brigade‼

The party will be on February 28th from 7PM to 10PM at Substantial's offices. You can get your ticket for the low, low price of just $10 right here‼

If you would like to learn more about the history of Seattle.rb, check out Aaron's presentation from RubyConf 2008.

mechanize 2.2

2012-02-13T16:00:22-08:00

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.

2.2 / 2012-02-12

API changes
- MetaRefresh#href is not normalized to an absolute URL, but set to the original value and resolved later. It is even set to nil when the Refresh URL is unspecified or empty.
Minor enhancements
- Expose ssl_version from net-http-persistent. Patch by astera.
- SSL parameters and proxy may now be set at any time. Issue #194 by dsisnero.
- Improved Mechanize::Page with #image_with and #images_with and Mechanize::Page::Image various img element attribute accessors, #caption, #extname, #mime_type and #fetch. Pull request #173 by kitamomonga
- Added MIME type parsing for content-types in Mechanize::PluggableParser for fine-grained parser choices. Parsers will be chosen based on exact match, simplified type or media type in that order. See Mechanize::PluggableParser#[]=.
- Added Mechanize#download which downloads a response body to an IO-like or filename.
- Added Mechanize::DirectorySaver which saves responses in a single directory. Issue #187 by yoshie902a.
- Added Mechanize::Page::Link#noreferrer?
- The documentation for Mechanize::Page#search and #at now show that both XPath and CSS expressions are allowed. Issue #199 by Shane Becker.
Bug fixes
- Fixed handling of a HEAD request with Accept-Encoding: gzip. Issue #198 by Oleg Dashevskii
- Use #resolve for resolving a Location header value. fixes #197
- A Refresh value can have whitespaces around the semicolon and equal sign.
- MetaRefresh#click no longer sends out Referer.
- A link with an empty href is now resolved correctly where previously the query part was dropped.

net-http-persistent 2.5

2012-02-07T15:47:19-08:00

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.

2.5 / 2012-02-07

Minor enhancements
- The proxy may be changed at any time.
- The allowed SSL version may now be set via #ssl_version. Issue #16 by astera
- Added Net::HTTP::Persistent#override_headers which allows overriding
- Net::HTTP default headers like User-Agent. See Net::HTTP::Persistent@Headers for details. Issue #17 by andkerosine
Bug fixes
- The ruby 1.8 speed monkeypatch now handles EAGAIN for windows users. Issue #12 by Alwyn Schoeman
- Fixed POST example in README. Submitted by injekt.
- Fixed various bugs in the shutdown of connections especially cross-thread (which you shouldn’t be doing anyways).

mechanize 2.1.1

2012-02-03T17:57:15-08:00

mechanize version 2.1.1 has been released!

2.1.1 / 2010-02-03

Bug fixes
- Set missing idle_timeout default. Issue #196
- Meta refresh URIs are now escaped (excluding %). Issue #177
- Fix charset name extraction. Issue #180
- A Referer URI sent on request no longer includes user information or fragment part.
- Tempfiles for storing response bodies are unlinked upon creation to avoid possible lack of finalization. Issue #183
- The default maximum history size is now 50 pages to avoid filling up a disk with tempfiles accidentally. Related to Issue #183
- Errors in bodies with deflate and gzip responses now result in a Mechanize::Error instead of silently being ignored and causing future errors. Issue #185
- Mechanize now raises an UnauthorizedError instead of crashing when a 403 response does not contain a www-authenticate header. Issue #181
- Mechanize gives a useful exception when attempting to click buttons across pages. Issue #186
- Added note to Mechanize#cert_store describing how to add certificates in case your system does not come with a default set. Issue #179
- Invalid content-disposition headers are now ignored. Issue #191
- Fix NTLM by recognizing the “Negotiation” challenge instead of endlessly looping. Issue #192
- Allow specification of the NTLM domain through Mechanize#auth. Issue #193
- Documented how to convert a Mechanize::ResponseReadError into a File or Page, along with a new method #force_parse. Issue #176

net-http-persistent 2.4.1

2012-02-03T17:55:59-08:00

Manages persistent connections using Net::HTTP plus a speed fix for Ruby 1.8. It’s thread-safe too!

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.

2.4.1 / 2012-02-03

Bug fixes
- When FakeWeb or WebMock are loaded SSL sessions will not be reused to prevent breakage of testing frameworks. Issue #13 by Matt Brictson, pull request #14 by Zachary Scott
- SSL connections are reset when the SSL parameters change. Mechanize issue #194 by dsisnero
- Last-use times are now cleaned up in #shutdown.

net-http-persistent 2.4

2012-01-31T15:58:10-08:00

net-http-persistent version 2.4 has been released!

Manages persistent connections using Net::HTTP plus a speed fix for Ruby 1.8. It’s thread-safe too!

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.

2.4 / 2012-01-31

Minor Enhancement
- net-http-persistent now complains if OpenSSL::SSL::VERIFY_PEER is equal to OpenSSL::SSL::VERIFY_NONE. If you have a platform that is broken this way you must define the constant:
```
I_KNOW_THAT_OPENSSL_VERIFY_PEER_EQUALS_VERIFY_NONE_IS_WRONG = nil
```
  at the top level of your application to disable the warning.
Bug fix
- Fix persisting SSL sessions through HTTP proxies. Mechanize issue #178 by Robert Poor, net-http-persistent issues #10, #11.

Forever-valid SSL certificates

2012-01-11T14:04:16-08:00

If your library uses X509 cryptography, naturally your tests will need a key and valid certificate to test against. Creating a key and certificate frequently can quickly drain your entropy pool which slows down your tests.

Instead of creating the key for every test startup you can create it once and load it off the disk like this:

class TestMyGem < MyGem::TestCase
  private_key = File.expand_path '../../../test/private_key.pem', __FILE__
  private_key = File.read private_key
  PRIVATE_KEY = OpenSSL::PKey::RSA.new private_key

  # …

Sure, you can rebuild the certificate every time with a validity time of an hour, but why not create a forever-valid certificate to go with it? No reasonable person would ever use a key shipped with an open project anyhow. Here's how to generate such a key and certificate:

require 'openssl'

# purposefully short key length
key = OpenSSL::PKey::RSA.new 512

# bogus subject and issuer
name = OpenSSL::X509::Name.parse 'CN=nobody/DC=example'
cert = OpenSSL::X509::Certificate.new
cert.subject = name
cert.issuer = name
cert.version = 2
cert.serial = 1
cert.not_before = Time.now

# lasts as long as X509 allows
cert.not_after = Time.gm 9999, 12, 31, 23, 59, 59
cert.public_key = key.public_key

cert.sign key, OpenSSL::Digest::SHA1.new

open 'private_key.pem', 'w' do |io| io.write key.to_pem end
open 'public_cert.pem', 'w' do |io| io.write cert.to_pem end

You can load this certificate just like the key as described above:

  public_cert = File.expand_path '../../../test/public_cert.pem', __FILE__
  public_cert = File.read public_cert
  PUBLIC_CERT = OpenSSL::X509::Certificate.new public_cert

Replace your test helpers with reusable API

2012-01-10T10:37:50-08:00

test/test_helper.rb is a great idea Rails brought to the Ruby world as a place for functionality that helps you write better tests. There's now a standard place for you to implement common setup/teardown, shortcuts and custom assertions. However, a test helper is not the best place to store this functionality for a Ruby library.

One of the benefits you get out of writing tests is knowing where your API is clumsy and inadequate. If you have a test helper file full of methods to make your library easy to use in a test why is that not part of your library's API? Wouldn't your users also want a bunch of methods that make your library easier to use in their applications?

For example, in RubyGems we have a test helper that does this: gem_file = Gem::Builder.new(spec).build which is a little silly. Every time you create a Gem::Builder you want to build a gem. You don't create a Gem::Builder object for fun! To help out RubyGems users I added a new method: gem_file = Gem::Builder.build spec which immediately creates and builds them gem which is much nicer for everyone (but really, you should use Gem::PackageTask when building gems).

Whether you're writing a library or a Rails app, this kind of functionality belongs in your library (or application) code, not in the test helper where only your tests can benefit from it.

Even after you improve your API by moving helpful functionality back into your library there's still going to be some things that only make sense for tests. For example, you probably don't want to type t = Some::Deeply::Namespaced::Thing.new 1, 2, 3 many, many times in your tests, so you write a short wrapper method you can call like this: t = thing 1, 2, 3. Your tests may need setup and teardown to maintain a clean environment between tests, custom assertions for readability or you may want to include a pre-built stub or mock.

While this having this functionality in a test helper is fine for a Rails app, it shouldn't go in a library's test helper. When you keep testing functionality hidden in the test directory a user who wants to write a third-party extension for your gem can't access them. Why force a happy user to re-implement (possibly poorly or incorrectly) the work you've done to have nice, clean tests that are easy to read and write?

Instead of having a private test helper I have a public test case like MyGem::TestCase that lives in lib/my_gem/test_case.rb. This gives anyone who wants to extend my libraries a documented, ready-to-go API for writing tests for their extension.

My gem-specific test case typically contains all the requires needed to load the library (ideally require 'my_gem'), proper setup and teardown to sandbox the tests, any utility methods that don't belong in the library itself and possibly some custom assertions. This makes a brand new test easy to start:

require 'my_gem/test_case'

class TestMyGemSomeClass < MyGem::TestCase
  def setup
    super

    # …
  end

  def test_something
    # …
  end
end

There is the minor downside that an extension writer must use minitest (my preferred testing library) to test their extension. Perhaps this inconvenience could be solved by a module providing setup, teardown and shortcuts that is included in the proper place for the extension writer's favorite testing library.

PS: Actually, Gem::Builder.build is Gem::Package.build since Gem::Format, Gem::Builder and Gem::Package are getting merged into one convenient class that deals with reading and writing gem files for RubyGems 2.0. This means there will only be one place to look for the API of messing with packages and it reduces the implementation of Gem::Installer a bit.

return_bang 1.0

2011-12-20T16:52:48-08:00

return_bang version 1.0 has been released!

return_bang implements non-local exits from methods. Use return_bang to exit back to a processing loop from deeply nested code, or just to confound your enemies and your friends! What could possibly go wrong?

Features

Implements non-local exits for methods
Nestable
Named and stack-based exit points, go exactly where you need to be
Ignores pesky ensure blocks for when you really, really need to return

Synopsis

require 'return_bang/everywhere'

def some_method
  deeply_nested
  # never reached
end

def deeply_nested
  return!
end

return_here do
  some_method
end
# resumes here

Testimonials

“you’ll wind up with your cock in /dev/null somehow” – slyphon

“Haha! Right! This skips ensure… SO EVIL‼‼” – drbrain

“This is so evil that 6 def test_… have turned into: 16 tests, 65 assertions, 18 failures, 7 errors” – drbrain

Install

sudo gem install return_bang