Herausfinden, wo eine Methode definiert wurde

In manchen Situationen ist es alles andere als offensichtlich, welche Klasse oder welches Modul eine Methode bereitstellt. Wer implementiert die Get-Methode für Rspec-Controller-Tests? Gerade in solch zusammengewürfelten Umgebungen ist das nur schwer nachvollziehbar. Ruby hilft hierbei: Die Metamethode method gibt Auskunft, woher eine Methodendefinition stammt:

require "rails_helper"

RSpec.describe MyController do
  it do
    puts method(:get)
  end
end

# => #<Method: RSpec::ExampleGroups::MyController(ActionController::TestCase::Behavior)#get>

Das Beispiel zeigt nicht nur die Klasse, sondern auch das includete Modul, welches für die Methode verantwortlich ist. Dies hilft beim Googeln oder man verwendet Ri:

ri ActionController::TestCase::Behavior#get

 

Rails-Konfiguration in Engine auslagern

Für die meisten Rails-Projekte verwende ich die gleichen Gems mit ähnlichen Konfigurationen. Um den Projektstart und den Update-Prozess zu vereinheitlichen, möchte ich eine Engine, die diese Abhängigkeiten und Konfigurationen übernimmt.

Für den einfacheren Einstieg erzeuge ich innerhalb einer bestehenden Rails-App eine neue Engine:

rails plugin new m3 --full

Diese wird zu Testzwecken im Gemfile des Elternprojekts verlinkt:

gem 'm3', path: 'm3'

weiterlesen

Bundler überspringt Gems mit Todo-Beschreibung

Komisches Verhalten von Bundler, welches bei mir vorher nie aufkam:

$ bundle install
...
Source does not contain any versions of 'gem (>= 0) ruby'

Das Problem scheint hier tatsächlich zu sein, dass die Gem-Spezifikation noch Todos enthält:

Gem::Specification.new do |s|
 # ...
 s.summary = "TODO: Summary of Gem."
 s.description = "TODO: Description of Gem."
end

Entferne ich diese, so läuft die Installation durch.

Ironischerweise warnt Bundler sogar, dass das Gem Todos oder Fixmes in der Spezifikation enthält. Dass es das Verzeichnis deshalb nicht ordnungsgemäß ausliest erschließt sich aber nicht. Hier wäre eine Fehlermeldung statt der Warnung geeigneter. Möglicherweise ist es auch nur ein Bug, eine fehlende Beschreibung rechtfertigt kein Ignorieren eines Gems.

Ubuntu-Update kränkelt nach Owncloud-Installation

Nach der Installation des Owncloud-Clients über eine zusätzliche Paketquelle erhalte ich vom Ubuntu-Update-Manager Fehlermeldungen. Ein Update in der Konsole jammert:

sudo apt-get update
...
Paketlisten werden gelesen... Fertig
W: GPG-Fehler: http://download.opensuse.org Release: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 977C43A8BA684223

Das Problem wurde bereits auf Ubuntuusers diskutiert und die vorgeschlagene Lösung funktioniert problemlos:

wget -q http://download.opensuse.org/repositories/isv:/ownCloud:/community/xUbuntu_14.04/Release.key -O- | sudo apt-key add -

Die Updates laufen wieder durch.

ActiveRecord: Klasse einer Model-Instanz ändern

ActiveRecord erlaubt das direkte Ändern der Klasse einer Model-Instanz mittels #becomes. Dies kann zum Beispiel hilfreich sein, wenn man für einen Spezialfall weitere Funktionen oder Validierungen zu einem Model hinzufügen will:

> company = Company.last
> company.persisted?
 => true
> company.valid?
 => true 
> company = company.becomes(RestrictedCompany)
> company.is_a?(RestrictedCompany)
 => true 
> company.is_a?(Company)
 => true 
> company.persisted?
 => true
> company.valid?
 => false

Ähnliches ließe sich zwar auch mit bedingten Validierungen erreichen, würde aber ab einem gewissen Umfang schlicht nicht mehr skalieren.

Ein weiterer, oft gesehener Ansatz wäre RestrictedCompany.find(company.id). Dieser ist jedoch von der Datenbank abhängig und somit vermutlich weniger performant. Zudem benötigt er wirklich persistierte Instanzen. Dies ist vor allem nervig, wenn man in Tests gerne Stubbing nutzt.

Zum Speichern der Klassenänderung kann man #becomes! verwenden. Dies passt auch die STI-Vererbungsspalte (in aller Regel type) an.

Action-Mailer-Previews im Spec-Verzeichnis

Die Mailer-Previews in Rails 4 sind ein Segen. Wer Rspec statt der üblichen Testsuite verwendet kann das Verzeichnis von test in spec ändern, so dass alle Testdateien zusammen bleiben:

# config/application.rb

# ...
config.action_mailer.preview_path = "#{Rails.root}/spec/mailers/previews"

Nach einem Serverneustart sollten die Previews gefunden werden:

# spec/mailers/previews/user_mailer_preview.rb

class UserMailerPreview < ActionMailer::Preview
  def send_invitation
    UserMailer.send_invitation(Invitation.first!)
  end
end

Die Vorschau kann man dann unter den üblichen URLs betrachten, z.B.:

http://localhost:3000/rails/mailers/user_mailer/send_invitation

Suchstatus in ActiveAdmin deaktivieren

Der Suchstatus des Active-Admin-Masters funktioniert momentan fehlerhaft. Weder Scope-Namen noch Ransack-Suchen werden korrekt übersetzt.

Suchstatus in ActiveAdmin

Da ich das Konzept ohnehin nicht sonderlich gewinnbringend finde, schalte ich es zentral im Active-Admin-Initializer ab:

Wer das Konzept, wie ich, nicht sonderlich gewinnbringend und eines umständlichen Workarounds wert findet, kann es zentral im Initializer von ActiveAdmin abschalten:

# config/initializers/active_admin.rb

ActiveAdmin.setup do |config|
  # ...
  config.current_filters = false
end

ActiveAdmin: Authentifizierung für Browser und API

Eine einfache API-Authentifizierung lässt sich in ActiveAdmin durch Wiederverwendung des Standard-Admin-Users im Initializer erreichen:

 # config/initializers/active_admin.rb
 ActiveAdmin.setup do |config|
   config.prepend_before_filter do
     if active_admin_config.namespace.name == :api
       authenticate_or_request_with_http_basic('API') do |name, password|
         user = AdminUser.find_by_email!(name)
         sign_in(:admin_user, user) if user.valid_password?(password)
       end
     end
   end

Dies erlaubt die Angabe des Benutzernamens und Passworts im Browser als Popup (HTTP-Basic-Authentication) und als Header für APIs:

curl -u admin@example.com:password http://localhost:3000/api/my_resources.json

weiterlesen

API-Namespace für ActiveAdmin

In ActiveAdmin kann man neben dem Standard weitere Namespaces definieren. Hierfür wird bei der Ressourcen-Registrierung die entsprechende Option angegeben:

# app/admin/api/my_resource.rb

ActiveAdmin.register MyResource, namespace: :api do
 # ...

Das Namespace-Verzeichnis kann unter app/admin abgelegt werden, ohne das „admin“ Teil der URL, des Controller-Namens o. ä. wird:

rake routes
# ...
api_my_resources GET  /api/my_resources(.:format)  api/my_resources#index
# ...