Luckily, RubyGems allows to set default options in a file called .gemrc which should be placed in your home directory. The syntax is in YAML format, therefore straightforward for a Ruby programmer. Just add this line to .gemrc and you are golden.

    gem: --no-rdoc --no-ri
  

A list of all options can be found here.

It was fun and sometimes painful to learn how to achieve things with Objective-C and Cocoa in particular. And of course, learn how to automate packaging and deployment of new releases including automatic updates. Ironically, I ended up doing most of those tasks with Ruby. I will write a few blog posts covering my endeavors.

The source is available on github and the application itself can be downloaded here.

qlmanage -p file

So if you wanted to preview the file image.png you would type:

qlmanage -p image.png

If you want to see the thumbnail preview of a file instead, just use -t instead of -p.
To close the window either click the cross on the upper right corner or hit control-c to cancel the process. Happy previewing!

    dscacheutil -flushcache
  

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.

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:

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

The gem is still a little bit rough around the edges and doesn’t do much more than sending http post requests. So you still have to know the payone API. There is a lot of room for improvement, I am thinking about an API similar to ActiveMerchant or even an integration.

For the impatient here is how you install it:

gem install gemcutter
gem tumble

gem install payone_connect


And here is how you use it:

require 'payone_connect'
payone = PayoneConnect.new(api_key,params_hash)
puts payone.request[:status]


Enough said, here you can find the code: http://github.com/phuesler/payone_connect

globalize2 creates a has many association on a translated model that points to a proxy class. This proxy class holds the model translation for any given language. So if I tell it to translate a model called Tag, it will create a class called TagTranslation on the fly.

I needed to add behavior to TagTranslation. I wanted to add a before save hook that makes transformations on an attribute before it gets saved. Therefore, I created an active record model called TagTranslation and added the hook. This worked wonderfully in test environment but not in the development environment. For some reason, the transformations weren’t made.

A short debugging session in script/console revealed that there was no before save hook on TagTranslation in development mode. More precisely, the class never got loaded. So I dug into the globalize2 code and found out that it just overrides an existing class with the same name.

So what happened? In that particular case, this happened when config.cache_classes was set to false in the rails config. This is the default in the development environment. What is difference then? When config.cache_classes is set to true (Default in production and test) then Rails eager loads the classes at startup. The class Tag gets loaded before TagTranslation and therefore globalize has already created a proxy class. So when our TagTranslation gets loaded it just reopens an existing class and adds stuff to it. What happens in development mode? Rails only loads models when triggered through Object.const_missing. When the constant Tag is referenced somewhere in the code, the class Tag is loaded and globalize creates a proxy class called TagTranslation as well as a has many association. The association normally triggers the associated class to be loaded (our TagTranslation model) but in this case, the class already exists and therefore our TagTranslation model never gets loaded.

How to fix it? I have a fork on github with a failing test and a fix: http://github.com/phuesler/globalize2. Alternatively you can make sure that your class gets loaded explicitly. You have to do this after you call globalize’s translate method. Here is how you could do it for the aforementioned Tag model: