huesler informatik

As part of the automated deployment process for a cocoa application, I needed to access a .plist file to change some values before the application gets bundled and uploaded.

Since plist files are plain XML files, I could have used something like libxml to get the job done but since this script runs on a Mac, I have access to RubyCocoa. That spares me the XML parsing and writing and gives me a simple persistent dictionary instead. This is what I ended up with:

I think that is pretty neat. However, I ran into a small pitfall when I tried to compare an NSString with a regular expression. I got this warning:

'NSString#=~' doesn't work correctly. Because it returns byte indexes.
    Please use 'String#=~' instead.

The solution is pretty simple, just call to_s on the dictionary values.

Rails handles exceptions that occur in production mode by rendering the file public/500.html or one of the other two (404.html and 422.html) if appropriate. Generally this is a good default, but in some cases it is a requirement to redirect the user to, or render specific pages for different types of exceptions. For instance, when an application provides a JSON API, it would be bad to return a 500.html to the caller when something goes wrong.

There are generally two ways do this in Rails. Either overwrite rescue_action_in_public in your controller or use the newer rescue_from to map exceptions to a handler. Ryan Daigle wrote a short but comprehensive blog post on this topic.

However, testing this is a bit tricky. config.consider_all_requests_local needs to be set to false and local_request? should be set to false as well. Testing this manually in the browser is cumbersome and error prone, so I needed a way to verify the behavior with a controller test. A quick ack –ruby rescue_action_in_public actionpack-2.3.4 turned up /actionpack-2.3.4/test/controller/rescue_test.rb exactly what I needed.

As it turns out, this is actually quiet easy to test. Basically, there are four things to consider and you are good to go:

1. Simulate the production environment in a setup method

2. Create a dummy controller with actions that reproduce the errors you want to test

3. Generate a route for your dummy controller if you have deleted the default routes in routes.rb

4. Call those methods in your test cases

With these four steps we got most uses cases covered. I ran into a problem, where I wanted to test an error that occurred during template rendering and required some special exception handling code. This is what worked for me:

Having a convenient way to store an applications configuration is something I want in every Ruby project. There are plenty of solutions for Ruby on Rails but none of them did really match my taste, because they did way too much. I wanted something simple that does not depend on Ruby on Rails and does not try to be too clever.

Here are my requirements for a configuration lib:

• Nesting and namespaces
• Simple string interpolation
• Support for environments e.g testing, production, debug
• Defaults for each environment

And this is what I came up with:

• Use YAML (defaults, namespaces, scopes)
• Parse the YAML file with ERB
• Return an OpenStruct object for easy method accessors

The code and and information on how to install and use the lib can be found here: http://github.com/phuesler/simple_app_config