Obligatory legal stuff: the file comes “as is” with no warranty whatsoever. The downloaded files are from John Harrison and licensed under the Creative Commons Attribution-Share-Alike Generic 1.0 License. The script itself is hereby released as beer-ware.

The script is brittle: if Wikipedia decides to change their link styles, all hell breaks loose. It may or may not work for you – YMMV. But here goes:

#!/usr/bin/env ruby
 
require 'rubygems'
require 'open-uri'
require 'nokogiri'
require 'net/http'
 
user_agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
url = "http://en.wikipedia.org/wiki/The_Four_Seasons_%28Vivaldi%29"
fourseasonspage = Nokogiri::HTML(open(url, "User-Agent" => user_agent))
 
@destdir = ENV['DESTDIR'] || 'vivaldi'
FileUtils.mkdir_p(@destdir) unless File.exists?(@destdir)
 
@uri = URI.parse(url)
 
# Aquiring the Four Seasons
puts "\e[1mGetting Files...\e[0m"
puts
 
fourseasonspage.css("div.medialist a").each do |ogg_link|
  url = "http://"+ @uri.host + ogg_link[:href]
  ogg_page = Nokogiri::HTML(open(url, "User-Agent" => user_agent))
 
  ogg_page.css("div.fullMedia a.internal").each do |link|
      puts "Downloading: " + link[:href]
      filename = File.basename(link[:href])
      uri = URI.parse(link[:href])
      Net::HTTP.start(uri.host) do |http|
        resp = http.get(uri.path)
        open(File.join(@destdir, filename), "wb") do |file|
          file.write(resp.body)
        end
      end
  end if /File:/.match(ogg_link[:href])
end
 
# Now comes cmd line file converting
puts "\e[1mStarting conversion...\e[0m"
puts
 
`for file in #{@destdir}/*.ogg ; do \
  echo > id3.tag; \
  vorbiscomment -l -e $file |awk -F= '{print $1"=""'\''" $2 "'\''" }' > id3.tag ; \
  source id3.tag; \
  ogg123 -d wav -f - $file \
  | lame -h -v -m s -b 192 --tt "$title" --tn "$tracknumber" --ta "$artist" --tg "$genre" --tc "$comment" --tl "$album" --id3v2-only - #{@destdir}/$(basename "$file" .ogg).mp3; \
done; rm id3.tag`
 
puts "\e[1mAll done.\e[0m"
puts "(You may wish to delete #{@destdir}/*.ogg)"

Getting started:

DESTDIR=path/to/dir ruby vivaldi.rb

There is a nice and short article by Erik Ostrom that explains how to do that without the response object you’ll normally have when using it to check views. However, it lacked support for nested nodes which can be remedied by adding yield @selected if block_given?.

The modified code snippet to put in test/test_helper.rb is:

class ActiveSupport::TestCase
  def assert_select_from(text, *args)
    @selected = HTML::Document.new(text).root.children
    assert_select(*args)
    yield @selected if block_given?
  end
end

Usage:

def test_hreview_aggregate_item
  output = hreview_aggregate(:fn => "John Doe's Pawn Shop")
  assert_select_from output, "span.hreview-aggregate" do
    assert_select "span.item" do
      # nb: it's assert_select within the block
      assert_select "span.fn", :text => "John Doe's Pawn Shop"
    end
  end
end

We use HAProxy as the frontend to forward incoming requests to Apache+Passenger instances on our webservers at berlin.kauperts.de.

Problems arose on the HAProxy machine itself which was also (intentionally) forwarding requests to a locally running Apache: despite using the forward_for option for the configured backend, Rails considered all incoming requests local as they were indeed coming from the local machine. The result was exposed exceptions, even on something as trivial as RoutingError which should trigger a normal 404.

Wesley Moxam described this problem in a blog post, but our setup is slightly different: HAProxy sends requests directly to Passenger/mod_rails within Apache vhosts without Apache-side (double)proxying involved. Removing the option forwardfor as described in said post was no viable way to go for us as it confused the non-local nodes in the setup.

Additionally, the Rails applications on each node behind HAProxy would never get the true client’s IP address: Request#remote_ip was always that of the HAProxy instance.

Heaving the formally locally running instance onto the external interface and treating it just as any other node rid us of the first problem and adding your HAProxy to the list of TRUSTED_PROXIES fixes the second. Add the following line as an initializer to your Rails 2.3.x app. The HAProxy backend uses option httpclose and option forward_for.

# config/initializers/trusted_proxies.rb
# If your HAProxy is running at 209.85.149.104, set:
ActionController::Request.const_set("TRUSTED_PROXIES", /^209\.85\.149\.104$|^127\.0\.0\.1$|^(10|172\.(1[6-9]|2[0-9]|30|31)|192\.168)\./i)

Granted, I don’t feel overly comfortable with coding that bit of network architecture into my Rails application. Moving servers and switching IPs is pain enough as it stands and thus I don’t like adding another dependency. It works, though, and here’s to hoping that our loadbalancer does not have to be exchanged anytime soon.

/var/lib/gems/1.8/gems/amatch-0.2.5/lib/amatch.so: wrong ELF class: ELFCLASS32 - /var/lib/gems/1.8/gems/amatch-0.2.5/lib/amatch.so

As the “ELFCLASS32″ bit in the error message suggests, it’s an architecture issue:

$ file /var/lib/gems/1.8/gems/amatch-0.2.5/lib/amatch.so
/var/lib/gems/1.8/gems/amatch-0.2.5/lib/amatch.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

It can be remedied easily by supplying the target arch like this:

$ ARCHFLAGS="-arch x86_64" gem install amatch

$ ruby script/plugin install git://github.com/carpodaster/ar_sitemapper.git

A simple usage example to create a gzip’ed xml sitemap for a fictious model “Post”:

Post.build_sitemap :all, :filename => "sitemap_posts.xml.gz" do |post, xml|
  xml.loc post_url(post)
  xml.changefreq 'weekly'
  xml.lastmod content.updated_at
  xml.priority 0.5
end

For a more detailed description, see the Readme on my project page on GitHub.

Preparation

Since I am too lazy to properly fork vestal_versions (might do that at some point in time though), here is a bit of code that adds the desired feature as a monkey patch (ie. without touching the gem itself):

First and foremost, we need to migrate the existing versions table (yes, I know… a tad bit ugly, but the migration will do you no harm)

  def self.up
    change_table :versions do |t|
      t.integer  :confirmer_id
      t.string   :confirmer_type
      t.datetime :confirmed_at
    end
    add_index :versions, [:confirmer_id, :confirmer_type]
  end
 
  def self.down
    remove_column :versions, :confirmer_id
    remove_column :versions, :confirmer_type
    remove_column :versions, :confirmed_at
  end

Next, the monkey patch. Place this somewhere in your load path, ./lib/kauperts/versions.rb worked for me. The module name is of course up to you.

# lib/kauperts/versions.rb
module Kauperts # :nodoc:
  module Versions # :nodoc:
    # Custom extension of stock VestalVersions::Version to support a polymorphic
    # reviewer object. Note: the versions table has to be modified for this.
    def self.included(base)
      base.class_eval do |klass|
        klass.belongs_to :confirmer, :polymorphic => true
        def confirmed?; !!self.confirmed_at?; end
        def confirm!
          self.confirmed_at = Time.now
          self.save!
        end
      end
    end
  end
end

We also need the following line in an initializer or just at the bottom of your environment.rb (for some reason putting it outside the module definition above wouldn’t work for me, anyone got an idea why?)

# In config/environment.rb
VestalVersions::Version.class_eval { include Kauperts::Versions }

Usage

After you have migrated your database and restarted the application, you have a polymorphic belongs_to association confimer on your VestalVersion::Version model. A confim! method sets the confirmed_at attribute to Time.now and calls save! on itself. The method confirmed? returns true if the confirmed_at attribute is not nil.
Setting the confirmer object is your controller’s duty. You may want to have a dedicated VersionsController to review/confirm past edits and access the recent versions directly (as opposed to the VersionedModel#versions association). I set up a confirm action:

# config/routes.rb
    map.resources :versions, :only => [:index, :show], :member => {:confirm => :put}

# app/controllers/versions_controller.rb
  # (CRUD actions)
 
  def confirm
    # change this to adapt to your role settings
    # or shield this behind a before_filter.
    if current_user.editor?
      current_object.confirmer = current_user
      current_object.confirm!
      flash[:notice]  = "Version confirmed."
    else
      flash[:warning] = "Access denied."
    end
    redirect_to version_path(current_object)
  end

Testing

Naturally, I wrote tests. There doesn’t seem to be much potential for things to go wrong, but here you have it anyway (if only to prove that it’s working ):

# test/unit/vestal_versions_extension_test.rb
require File.dirname(__FILE__) + '/../test_helper'
class VestalVersionsExtensionTest < ActiveSupport::TestCase
  def setup
    # Using factory_girl here to create and return an instance of
    # ServiceProvider which is versioned with vestal_versions
    @versioned = Factory(:service_provider)
  end
 
  test "should respond_to confirmed?" do
    obj = Factory.build(:version)
    assert obj.respond_to? :confirmed?
  end
 
  test "should respond_to confirmer" do
    obj = Factory.build(:version)
    assert obj.respond_to? :confirmer
  end
 
  test "should set confirmed_at and confirm!" do
    @versioned.update_attributes(:name => "Foo Bar #{rand}")
    obj = @versioned.versions(true).last
    assert obj.respond_to? :confirm!
    assert !obj.confirmed?
    obj.confirm!
    assert obj.confirmed?
  end
 
end

# test/functional/versions_controller_test.rb
require File.dirname(__FILE__) + '/../test_helper'
 
class VersionsControllerTest < ActionController::TestCase
 
  def setup
    # A vanilla User is an unprivileged dude
    @user = Factory(:user)
    login_as_user(@user)
    @versioned = Factory(:service_provider)
  end
 
  test "should not confirm as normal user" do
    obj = Factory(:version)
    assert !@user.editor?
    put :confirm, :id => obj.to_param
    assert_response :redirect
    assert_redirected_to version_path(obj)
    assert_not_nil flash[:warning]
    assert !assigns(:current_object).confirmed?
  end
 
  test "should confirm" do
    obj = Factory(:version)
    @user.toggle!(:editor)
    put :confirm, :id => obj.to_param
    assert_response :redirect
    assert_redirected_to version_path(obj)
    assert assigns(:current_object).confirmed?
    assert_not_nil flash[:notice]
    assert_equal @user, assigns(:current_object).confirmer
  end
end

Have fun! Comments and suggestions are of course welcome.

Selbstredend würden das auch regelmäßig andere Druckerzeugnisse tun, aber wer sich selbst einmal beim Lesen des sich hinter dem vorangehenden Link befindlichen Blattes erwischt hat, mag einen Eindruck davon gewinnen, was der Kerl hier mit fehlendem journalistischem Wohlgefühl meint. Was man der BILD immerhin zugute halten muss: sie verfügen über ein Lektorat. Klar lässt dieses höchst absonderliche Neologismen (Volks-Verdummung?) durchwinken, aber nun…

Es mag ein Armutszeugnis im wörtlichen Sinn sein, will heißen, die Mannschaft kann sich ein Lektorat schlichtweg nicht leisten, aber für mich transportieren 2-3 Rechtschreibfehler auf der Titelseite oder im Leitartikel eine ganz andere Botschaft: hier hat man keine Zeit, sein Geschreibsel vor dem Druck nochmal durchzulesen. Und weitergesponnen: hatte man denn eigentlich Zeit, um für seinen Beitrag richtig zu recherchieren? Ein aktuelles Beispiel mag da der Artikel „Revisionismus nicht mit uns” ein, wo ein unter einer CC-Lizenz stehendes Photo als Titelbild verwendet wird, das aber mit dem Inhalt ungefähr gar nichts zu tun hat. Also höchstens so viel, wie ein nicht weiter kommentiertes Bild vom VW-Vorstand in einem Artikel über General Motos & Co. sinnvoll wäre. Zu dumm nur, dass durch die Aufführung im Kontext des Artikels die auf dem Photo gezeigte Gruppe der CPD (und damit der gesamte Verein) implizit in Miskredit gezogen wird. Aber mal soll ja auch nicht sofort alles glauben, was in der Zeitung steht.

Ich habe immer nur unregelmäßig Kontakt mit diesem Fachblatt für Stammtisch-Linke gehabt. Aber sie schaffen es immer wieder, sich selbst zu unterbieten und meinen Eindruck zu festigen: die taz ist nunmal die BILD für Genau!-Sager links der Mitte, schlechter Journalismus und Linkspopulismus at its best.

Thawte’s email certificate services are based on S/MIME, a standard for secure email communication that is supported by all common MUAs. Although S/MIME is inferior to the PGP/GPG mechanism which allows encryption / signing of arbitrary data instead of just email contents, the aforementioned fact was what made me shift to S/MIME some months ago: it is accessible, whereas PGP/GPG requires not only the installation of plugins on the sender’s side, but also for everyone who might want to benefit from it (ie. your recipients). As virtually every MUA out there already provides the mechanics for S/MIME, everything gets reduced to your own initiative: to apply for an email certificate. Unfortunately, the way x.509 certificates work, you would need a Certificate Authority (CA)  which attests that you are, well, yourself. Thawte/Verisign is such a CA. The CA itself is listed in your MUA’s or system-wide catalogue of “trustworthy” root CAs and all certificates signed by those CAs inherit their status (ie. considered trustful if not configured otherwise).

The concept of giving trust to only one authority which earned their status by undergoing a more or less complex process (which, in case of Microsoft putting them into their certificate root, revolves around paying insane amounts of money), if at all, has flaws by it’s own right, of course. Without going into details: Thawte had a rather unique approach of mixing the x.509 certificate system with the Web of Trust system, prominently used by PGP/GPG, easing the paranoia-struck people’s tension a bit.

Security is always about trade-offs: the most secure computer system is probably one cast into concrete, six stories beyond the ground and naturally without any input or output device whatsoever. It’s a trade-off between ease of use and maximum security and the trick is to find a balance that suits your own needs and standards, a role which S/MIME plays quite well.

I am not aware of other free x.509 email certificates that will work for common mail clients. As a security zealot, I might very well pay the yearly fee for the new paid services, but others may not. And there arises the problem: with the relative ease of setting up S/MIME based email security there were little “excuses” for the average user not to make use of it, even less so if you as an evangelist were aiding him/her in the setup process (which, truth be told, still wasn’t as self-explanatory as it should have been). However, the average user certainly won’t invest 15 € p.a. into a technology completely unknown to them and which in addition will only add more complexity to their life. I can imagine it to be quite difficult to convince them otherwise: after all, the most common approach to (email) security is “I have nothing to hide“.

Of course I would still be able to digitally sign my emails, assuring the recipient that I was indeed the sender and that the email got to him/her untainted, but that is only half of it: I would not be able to encrypt emails when no one has access to a personal certificate / key. Thawte’s notice on discontinuing their service thus practically marks the death of S/MIME to me which worked conveniently over many years. Or will we pay for it? Are we ready to spend money on “postage for (secure) emails”?