0 RAII kontrollierte Flags in Qt

Flags sind ein beliebtes Werkzeug, um das Ausführungsverhalten eines Algorithmus zu beeinflussen. Das Steuern der Wertbelegung von Flags ist jedoch fehleranfällig. Durch Anwendung des in C++ bewerten RAII1-Konzepts kann die Fehleranfälligkeit reduziert werden.

RAII bedeutet, dass das Instanziieren einer Klasse gleichzeitig die Klassenressourcen initialisiert. Das Zerstören der Instanz gibt die Klassenressourcen frei. Dieser Umstand wird z.B. durch SmartPointer2 ausgenutzt.

1 Ressourcenbelegung ist Initialisierung

2 SmartPointer

weiterlesen→

0 Windows 8 Store Apps zwingend auf C:\

Bei der Entwicklung von Windows 8 Store Apps sollte man beachten, dass diese nur starten, wenn Sie auf dem Laufwerk C:\ erstellt wurden.

Alle Versuche ein TrueCrypt Laufwerk, USB-Stick oder Ram-Disk zu nutzen, resultieren beim Testen in einer im Launch-Screen hängenden Anwendung. Die Quell-Dateien können durchaus auf jedem beliebigen Laufwerk liegen. Der “Build”-“Output path” muss aber auf dem primären Laufwerk C:\ liegen, damit die Anwendung startet.

kommentieren→

0 Unit-Tests von Modellen mit Tabellennamen in Rails

Will man in Rails seine Modelle mittels Unit-Tests verifizieren, bieten die von Rails automatisch generierten Gerüste eine solide Grundlage. Allerdings stoßen diese Vorlagen an ihre Grenzen, sobald der Modellname von dem seiner zugehörigen Tabelle abweicht. Betrachten wir also folgendes Beispiel, in welchem sich der Klassenname und der Tabellenname voneinander unterscheiden.

class TestMe < ActiveRecord::Base
  self.table_name = 'my_special_table'
  #<class-definition here>
end

Beim Erzeugen eines neuen Railsprojektes werden automatisch Testklassen und zu jeder Klasse gehörende Fixtures angelegt. Dabei bekommt jede Fixture-Datei den Namen der zu testenden Klasse in pluralisierter Form. Im Beispielfall wäre das also TestMes.yml. Führt man den Test nun aus, bekommt man prompt die Fehlermeldung Could not find table 'TestMes' zurück. Interessanterweise lässt sich die Anwendung jedoch im Development- als auch im Production-Umgebung starten.

Was ist passiert?

Bei der Ausführung des Tests greift Rails auf die Testdaten — welche in den Fixtures definiert wurden — zurück. Dabei nutzt Rails wie gewohnt die in der database.yml spezifizierte Datenbank. In Vorbereitung auf den Test werden die Daten aus den Fixtures in die entsprechende Datenbank gespeichert. Unglücklicherweise nutzt Rails ausschließlich den Dateinamen der Fixtures, um den entsprechenden Tabellennamen zu spezifizieren und ignoriert an dieser Stelle einfach den Befehl self.table_name = 'my_special_table' aus der Klassendefinition1. Da aber keine Tabelle mit dem entsprechenden Namen existiert, schlägt der Zugriff auf die Tabelle und in Folge dessen der Test fehl.

Lösung

Die Lösung für das Problem liegt auf der Hand, da wir die Ursache lokalisieren konnten. Die Fixture-Datei muss lediglich den Namen der entsprechenden Tabelle bekommen, anstatt den der zu testenden Klasse. In unserem Beispielfall also my_special_table.yml und der Test funktioniert.

Achtung

Leider birgt diese Variante eine potentielle Fehlerquelle. Sollte sich der Tabellenname im Zuge der Entwicklung verändern, muss diese Änderung sowohl in der Klassendefinition vorgenommen werden als auch die Fixture-Datei den neuen Namen erhalten, um die Tests weiterhin lauffähig zu halten.

1 Rails Guides — The Low-Down on Fixtures

kommentieren→

0 Mehrere simultane Datenbankverbindungen mit ActiveRecord

Die Aufgabe klang zunächst trivial:

Mehrere Server sammeln Daten und speichern diese in einer lokalen Datenbank. Es ist eine Rails Anwendung zu schreiben, die die Zustände aller Datenbanken auf einer Website darstellt.

Für diese Aufgabe ist ActiveRecord nicht vorgesehen. Wie es dennoch recht elegant geklappt hat…

weiterlesen→

2 Lösung für langsamen CDB und QtCreator

Das Debuggen einer Qt (v4.8.2) Windows-Anwendung mit dem CDB im QtCreator (v2.6.0) kann sehr zeit- und nervenraubend sein. Oft kommt es vor, dass Minuten vergehen ehe die zu testenden Software bedient werden kann. Ursache ist der langsame Start der Debug-Umgebung.
weiterlesen→

© 2012 – 2017 HicknHack Software GmbH | Impressum | Datenschutzerklärung