Ruby Blog

Zur NAB 2013 präsentiert FlavourSys das neue Produkt „Mint“ und stellt eine neue Version von „Strawberry“ vor. Mint bietet Project Sharing im Editing für 4 bzw. 8 Arbeitsplätze in einem Paket. Mint kann auf fast allen vernetzten Storage-Systemen installiert werden. Eine dedizierte Hardware ist nicht notwendig.

Read the rest of this entry »

IMSI/Design, führender Entwickler und Republisher von Grafik- und CAD-Software, und GK-Planungssoftware GmbH kündigen TurboCAD LTE Pro V.5 an. TurboCAD LTE Pro V.5 erscheint im deutschsprachigen Raum unter Lizenz der GK-PS GmbH und ist ab sofort im Handel erhältlich!

Read the rest of this entry »

Bald gibt es an dieser Stelle wieder ein paar News zu Ruby und Ruby on Rails. Schaut also bald mal wieder vorbei, es bleibt auf alle Fälle spannend.

Gedauert hats; zum Ende war ich schon fast verzweifelt. Aber heute konnte ich endlich eine erste Preview-Version von RSpactor.app veröffentlichen.

RSpactor ist eine Mac OS X Leopard Anwendung die kontinuierlich über Änderungen im Dateisystem wacht und ggf. Specs laufen lässt. Die Funktionalität orientiert sich bislang sehr an Autotest.

Ich suche nun also mutige Entwickler, die RSpactor ausprobieren wollen und mir helfen Fehler zu finden. Wenn jemand Lust hat schaut einfach mal hier: http://rubyphunk.com/2008/4/28/ann-rspactor-0-9-10-some-people-call-it-beta

Wusstet du schon? Git bringt von Haus aus nette kleine Tools für die Shell mit. So gibts z.B. Autovervollständigung und Anzeige des aktuellen Branches im Prompt. Das Setup is denkbar einfach und nachfolgend beschrieben.

Die nötige Datei liegt im Git Source Paket:

1
2

wget http://kernel.org/pub/software/scm/git/git-1.5.5.tar.gz
tar zxf git-1.5.5.tar.gz

Nun kopiere die Datei contrib/completion/git-completion.bash in dein Homeverzeichnis:

1

cp git-1.5.5/contrib/completion/git-completion.bash ~/.git_completion.sh

Um das Script zu aktiveren muss es noch in ~/.profile verlinkt werden. Öffne dazu die Datei ~/.profile in einem Editor deiner Wahl und füge folgende Zeile ein:

source ~/.git_completion.sh

Nach einem Reload des Terminals ist die Git-Autovervollständigung aktiv:

1
2
3
4
5
6
7
8

localhost:~/ruby/rspactor :: git a<tab><tab>
add   am   annotate   apply   archive

localhost:~/ruby/rspactor :: git b<tab><tab>
ba   bisect   blame   branch   bundle   

localhost:~/ruby/rspactor :: git branch <tab><tab>
HEAD   master   origin/master   prefpane   sparkle         

Als kleines Schmankerl steht nun auch eine nette kleine Funktion für den Prompt zur Verfügung, die es erlaubt den aktuellen Branch eines Repositories anzuzeigen (falls verfügbar):

$(__git_ps1 " (%s)")

In meiner ~/.profile sieht die Promptdefinition z.B. so aus:

export PS1='\h:\w$(__git_ps1 " (%s)") :: '

Ich war doch ziemlich überrascht, als ich heute festgestellt habe, dass RSpactor im aktuellen Rails Envy Podcast vorgestellt wird 🙂

Reinhören!

Ich war fleißig und hab gestern Abend mein erstes eigenes Gem veröffentlicht. Es trägt den Namen RSpactor und ist ein Spec-Runner wie Autotest. Im Unterschied zu Autotest arbeitet RSpactor jedoch mit FileSystem Events (FSEvent) und benötigt daher kein Prozessor-intensives Polling aller Projektdateien. Das spart Zeit und Energie und macht RSpactor schnell.

Aufgrund dieser Architektur funktioniert RSpactor bislang nur auf Mac OS X 10.5 (Defected by Design quasi..). In einer der nächsten Versionen wird allerdings auch Linux unterstützt werden.

Mehr Informationen

Projektseite

Mit Thin präsentiert sich ein neues Projekt auf der Bühne der Webserver / Stacks für Railsanwendungen, dass in den letzter Zeit für Aufsehen sorgte, da es laut Benchmarking schneller ist als Mongrel und sich damit an die Spitze der Webserver für Ruby / Rails Apps katapultiert.

Thin verknüpft 3 Bibliotheken zu einer Anwendung. Es verwendet Mongrels, in C geschriebenen, HTTP Parser, EventMachine und Rack. Die Kombination dieser Bibliotheken liefert Thin eine sehr hohe Geschwindigkeit und Stabilität.

Showdown: Mongrel vs. Thin

Um das ganze zu demonstrieren, habe ich Mongrel und Thin in einem direkten Vergleich gegeneinander antreten lassen. Der Wettkampf: Wie lange dauert ein Request bei 10, 50 und 100 gleichzeitigen Zugriffen.

Das Benchmarking wurde mit OpenWebLoad ausgeführt.

Das Standardverhalten einer Rails-Applikation ist, alle Models über die gleiche Verbindung an eine Datenbank zu knüpfen. In seltenen Fällen, und gerade in Legacy oder nicht homogenen Umgebungen kann es jedoch vorkommen, dass eine Anwendung mehr als eine Datenbank verwendet. D.h. konkret: Mehrere Models mit mehreren eigenständigen Datenbankverbindungen. Ab hier wirds schwierig, da RSpec von Haus aus nicht mit verschiedenen Datenbankverbindungen umgehen kann.

Ein Beispiel: Ich habe 3 Models die jeweils von verschiedenen ‘Master’-Klassen erben:

1
2
3

class Google < Search::Google; end
class Live < Search::Live; end
class Yahoo < Search::Yahoo; end

Jede ‘Master’ Klasse baut zwangsläufig eine eigene Datenbankverbindung zu den jeweiligen Services auf, um seine Daten abzufragen. Der Kern des Problems befindet sich nun in der Natur von RSpec, wie es die einzelnen Examples ausführt: Vor jedem Spec initialisiert (Begin) RSpec eine Datenbanktransaktion und bricht diese (Rollback) nach dem Spec wieder ab. Es verwendet dazu die Verbindung von ActiveRecord::Base, die wiederum während der Initialisierung der Test-Environment aufgebaut wird. Verwendet nun ein Model eine andere Verbindung als diese, kann die erstellte DB-Transaktion von RSpec nicht mehr greifen und es bleiben Test-Daten in den jeweiligen anderen Datenbanken zurück. Führt man die Specs erneut aus, brichts.

Um das Problem zu lösen, muss man RSpec dazu bringen, nicht nur die Standardverbindung (AR::Base) in eine Transaktion einzuhüllen, sondern alle Datenbankverbindungen.

Der Code dazu sieht folgendermaßen aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

module Spec
  module Example
    module ExampleMethods
      
      MASTER_MODELS = [Search::Google, Search::Live, Search::Yahoo]
      
      protected
      
      def before_example_with_multi_db_transactions
        MASTER_MODELS.each { |cls| cls.connection.begin_db_transaction }
        before_example_without_multi_db_transactions
      end
      alias_method_chain :before_example, :multi_db_transactions
      
      def after_example_with_multi_db_transactions
        after_example_without_multi_db_transactions
        MASTER_MODELS.each { |cls| cls.connection.rollback_db_transaction }
      end
      alias_method_chain :after_example, :multi_db_transactions      
      
    end
  end
end

Im Grunde ganz einfach, nicht wahr? Vor jedem Example, wird für jedes ‘Master’-Model eine Transaktion gestartet die nach dem Speclauf wieder zurückgerollt wird.

Ich entdecke immer mal wieder kleine Helferlein, die mir bis dato noch nicht untergekommen waren. In der heutigen Episode: alias_method_chain

Die Methode wurde mit Revision 4276 in Rails eingeführt und dient dazu eine oft benutze Kombination von alias Aufrufen zu vereinfachen.

1
2
3
4
5
6
7
8
9
10
11

  def example
  end

  def example_with_put
    puts 'ping'
    example_without_put
  end

  alias_method :example_without_put, :example
  alias_method :example, :example_with_put

Was passiert hier?

Wir erstellen ein Alias meiner alten Methode example und leiten alle Aufrufe an example_with_put weiter. Diese Methode wiederum tut was Sinnvolles und ruf dann meine originale example Methode via _example_without_put auf. Eigentlich nichts besonderes..

Da dieser Trick recht oft verwendet wird, erhielt Rails mit der Rev 4276 die Methode alias_method_chain, die dieses “Doppel-Aliasing” übernimmt. Ich kann die beiden alias_method Aufrufe auch folgendermaßen erstellen:

1
2

  alias_method_chain :example, :put

Mehr Information finden sich im Code von Rails.