DBF is a small fast library for reading dBase, xBase, Clipper and FoxPro database files. It is written completely in Ruby and has no external dependencies.

Changes in version 1.0.5:

• Strip non-ascii characters from column names

DBF is a small fast library for reading dBase, xBase, Clipper and FoxPro database files. It is written completely in Ruby and has no external dependencies.

Changes in version 1.0.2:

• Fixes a bug when reading Visual Foxpro memo files.

Today my son Dylan is 1 week old today. It’s been an amazing experience so far and I’m sure it will only get better as he become more interactive. This is the first time I’ve had any time to sit down and catch up on email, blogs, programming, etc. He’s in my lap now, and I’ve been working with him in the crook of my arm for the last two hours. It’s surprisingly easy to do while he’s still small and sleeps most of the time!

Dylan at 1 day old:

A lot of work has gone into this release of the DBF gem. The basic reader code is stable now. I’m in the process of moving the test suite from Test::Unit to Rspec. When I’m done with that I’ll add a couple of additional features, polish the documentation and christen it 1.0.0.

• New find method
• Full compatibility with the two flavors of memo file
• Two modes of operation:
  • In memory (default): All records are loaded into memory on the first
    request. Records are retrieved from memory for all subsequent requests.
  • File I/O: All records are retrieved from disk on every request
• Improved documentation and more usage examples

When using Rails’ verify method to protect your ActionController actions, you should return a list of the allowed HTTP methods in the response headers.

Let’s say you have an action called update that you want to protect from anything but a POST. I like to do it like this:

Now if someone tries to hit the update action with anything other than a POST, an error message will be displayed and the response headers will contain (among other things):

In my opinion, this is a better way to go than redirecting to another action because the use of an improper HTTP method is most likely the result of either programmer error or malicious intent. By redirecting to another page, you are making it much easier to for somebody to take your site down with a denial of service attack and if it’s a programming error, you’ll locate the problem faster.

You should also make sure that you have a functional test for this behavior:

def test_invalid_update_methods
  [:get, :put, :delete].each do |http_method|
    send http_method, :update
    assert_response 405
    assert_equal ‘POST’, @response.headers['Allow']
    assert_equal ‘405 HTTP POST required’, @response.body
  end
end

Additional Resources

• HTTP 1.1: Status Code Definitions
• HTTP 1.1: Header Field Definitions
• Rails API Documentation: Verification