ä, ö and ü: if these characters look familiar too you, then you have been plagued by an encoding-problem when dumping mysql-databases. You think, you are doing something wrong? So did I, but it looks like this is just a bug in the utf8-encoder of mysql.

After all these years that utf8 has been around, it is still hard. Maybe it is because Americans do not really care that much about utf8 and seem mostly happy with ASCII, maybe it is because getting encodings right actually is really hard. Whatever the reason, more often than not, umlaute turn into garbish, typographic dashes end up in illegible mumbo-jumbo when data is passed from one database to the other.

My most common problem: Dumping data from an ut8-database using mysqldump and then importing it into another utf8-database. What can possibly go wrong with that, when you make sure that you pass –default-character-set=utf8 into every command?

Everything: It looks like mysqldump simply has a bug and double-encodes utf8-values. Many many thanks to Peter Vandenbeele for finding the bug and explaining it lengthy why it happens. Passing –default-character-set=latin1 to mysqldump and then changing the SET NAMES to utf8 from latin1 does the deal: the utf8 Values are not encoded again and although it says latin1, in fact it really is utf8. Afterwards, importing works flawless and all umlaute are properly encoded. This is not entirely rational, but hey, what is in the end?!

This is google at it’s best: The google-reader is probably the best online news reader in terms of functionality. And it is plain ugly to look at. This is where Helvetireader comes in.

Helvetireader is basically a stylesheet for the google reader. It replaces all the ugly baby-blue chrome, the bad typography and the cluttered interface with a clean theme that emphasizes readability and unclutters the UI. And best of all: replaces it’s ugly cousin Arial with Helvetica.

You can install it either using grease-monkey for firefox, or greasekit on safari. If, like me, you don’t want to depend on a port of what’s already quite a hack on firefox, there is also a Safari-Extension. You can only install it, if you have enrolled into Apple’s Safari-Developer Program and requested&installed a developer-certificate.

Make sure that you install the certificate under login (“Anmeldung”):

When you double-click the certificate, it gets installed under “System” and the Safari-Extension-Manager does not find it there.

__Now, go, say goodbye to baby-blue, install Helevtireader and enjoy your news in glorious helvetica…___

PS: or even better – come up with some new themes for the reader, maybe based on Typekit and Aktiv Grotesk which is supposed to be more legible than Helvetica…

I guess pretty much everybody is now getting ready to move to rails3: Although it is still pretty early in the lifecycle, it already looks pretty amazing. That said, there is of course the one or other issue with moving all your beloved plugins and tools to rails3

already initialized constant VERSION

You probably followed Ryan Bates Screencast on using Rails3 with rvm and are now keeping rails3 in his own rails1.9.1-sandbox – which is certainly a good idea to get a non-contaminated list of gems that actually do work with rails3. Good chance is that you will then a see a ton of warnings like these:

/Users/sfrank/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/site_ruby/1.9.1/rubygems.rb:14: warning: already initialized constant VERSION
/Users/sfrank/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/site_ruby/1.9.1/rubygems.rb:14: warning: already initialized constant RubyGemsVersion
/Users/sfrank/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/site_ruby/1.9.1/rubygems.rb:194: warning: already initialized constant MUTEX
/Users/sfrank/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/site_ruby/1.9.1/rubygems.rb:196: warning: already initialized constant RubyGemsPackageVersion
/Users/sfrank/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/site_ruby/1.9.1/rubygems.rb:202: warning: already initialized constant WIN_PATTERNS
/Users/sfrank/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/site_ruby/1.9.1/rubygems.rb:1079: warning: already initialized constant MARSHAL_SPEC_DIR
/Users/sfrank/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/site_ruby/1.9.1/rubygems.rb:1084: warning: already initialized constant YAML_SPEC_DIR
/Users/sfrank/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/site_ruby/1.9.1/rubygems/version.rb:72: warning: already initialized constant VERSION_PATTERN
/Users/sfrank/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/site_ruby/1.9.1/rubygems/requirement.rb:20: warning: already initialized constant OPS
...

That error actually has nothing to do with rails3, but is an issue with ruby-gems. Only thing I could find on these issue was the post on codedifferent – I tried the uninstall-fix with no avail, but simply updating ruby-gems to 1.3.6 (with gem update –system) also did the trick. Case solved.

shoulda/autoload_macros

There is already a rails3-branch on github for shoulda – which obviously works fine when installed as a plugin. Unfortunately, if installed using bundler (which is the preferred way of bundling things in rails3), it fails with a

/Users/sfrank/.bundle/ruby/1.9.1/bundler/gems/shoulda-b78dbf514bbce3272023d3a4742474857c2eb3c3-rails3/lib/shoulda/autoload_macros.rb:42:in `join': can't convert nil into String (TypeError)
	from /Users/sfrank/.bundle/ruby/1.9.1/bundler/gems/shoulda-b78dbf514bbce3272023d3a4742474857c2eb3c3-rails3/lib/shoulda/autoload_macros.rb:42:in `block in autoload_macros'
...

shoulda obviously already tries to autoload it’s macros when being required, which now happens in application.rb:

Bundler.require :default, Rails.env
 
module Trainingday
  class Application < Rails::Application
  ...

And it looks like Rails.root (and also the now deprecated RAILS_ROOT) are not yet initilized, therefore the autoload fails. Until this is fixed, you can just wrap the call in autoload_macros.rb with a nil-check:

  def self.autoload_macros(root, *dirs)
    unless root == nil
      dirs << File.join('test')               
      complete_dirs = dirs.map{|d| File.join(root, d, 'shoulda_macros')}
      all_files     = complete_dirs.inject([]){ |files, dir| files + Dir[File.join(dir, '*.rb')] }
      all_files.each do |file|
        require file
      end
    end
  end

and add the autoload to your test-helper:

Shoulda.autoload_macros(Rails.root, "vendor/bundler_gems/gems/*")

Not very elegant, but at least it prevents shoulda from loading macros in the require and gets rid of the error.