Did you know that you can navigate the posts by swiping left and right?

Gurock SmartInspect Version 2.3

18 Jun 2008 . Unknown . Comments

SmartInspectLogo Jedes Projekt, dass ein wenig größer wird, benötigt spätestens wenn die ersten Fehler auftreten eine Möglichkeit zum Debuggen. Bei einfacheren Programmen genügen ein paar Write-Befehle oder auch die Trace- und Debug-Möglichkeiten des System.Diagnostics Namespaces im .NET Framework. Diese Art des Loggens wird jedoch mit Zunahme der Informationsmenge immer schwerer erfassbar; und bei Multithreading-Anwendungen ist es schließlich nahezu unmöglich die Aktionen eines bestimmten Threads jederzeit im Auge zu behalten. Will man in das fertige Produkt ebenfalls eine Logging-Möglichkeit einbauen, um bei evtl. Fehlern das Verhalten des Anwenders das zu selbigen führte nachzuvollziehen, ist man mit den einfachen Methoden schnell an seine Grenzen gestoßen. Die Firma Gurock Software GmbH mit Sitz in Paderborn hat sich mit ihrem Produkt SmartInspect diesem Problem angenommen.

Für diesen Test kam die Trial-Version von SmartInspect Professional v2.3.4.7144 zum Einsatz. Als IDE wurde die englische Version von Microsoft Visual Studio 2008 unter Vista SP1 und Windows XP SP3 eingesetzt. Die Beispiele sind allesamt in C# geschrieben und basieren auf der Version 3.5 des .NET-Frameworks.

dotnet-forum

Den folgenden Artikel habe ich auch in der Knowledge Base auf www.dotnet-forum.de im Rahmen eines Erfahrungsberichtes veröffentlicht. Hier findet der geneigte Leser auch noch zahlreiche Artikel von anderen Entwicklern und ein gut besuchtes Support-Forum für alle Aspekte der Programmierung mit dem .NET-Framework. Ein Besuch lohnt sich hier also auf jeden Fall!

[more]


Download und Installation

Auf der Seite des Herstellers findet man leicht den Link zur Testversion von SmartInspect. Diese hat keine Einschränkungen im Funktionsumfang und funktioniert 30 Tage. Sollte ein längerer Zeitraum für einen ausführlichen Test notwendig sein kann man sich auch mit dem Support von Gurock in Verbindung setzen um eine Lizenz zu erhalten, die den Testzeitraum verlängert. Die Lizenz für einen Benutzer kostet 229 Euro (Upgrade von Version 1.x: 119 Euro) und darf auf bis zu drei PCs installiert werden, bsp. Zuhause, im Büro und auf einem Notebook. Die Preise für weitere Lizenzen sind entsprechend gestaffelt. Der Download ist nur 7.25 MB schlank und somit schnell auf dem eigenen Rechner. Die Installation verläuft ebenfalls schnell und unproblematisch und benötigt, wie mir die UAC von Vista mitteilt, administrative Rechte. Das sollte auf einem Entwicklungsrechner aber in der Regel kein Problem sein.

Eine große Hilfe bei der Arbeit sind auch die Snippets, die Gurock Software mitliefert. Man findet sie für Visual Studio 2008 und C# im Unterverzeichnis /templates/vs/2008/csharp/ des Installationsordners. Es werden aber auch Snippets für die 2005er Version und VB.NET mitgeliefert sowie für CodeGear, Borland Developer Studio, Eclipse, und den Borland JBuilder. Ich werde in diesem Artikel mehrfach auf diese Snippets zurückkommen und sie zusätzlich orange in Klammern erwähnen.

Eine Dokumentation liefert der Hersteller zum einen in Form einer PDF-Datei mit, die eine gute Einführung bietet einschließlich der auch online verfügbaren Tutorials für die unterstützten Programmiersprachen und einen Überblick über die wichtigsten Funktionen der SmartInspect Konsole. Zusätzlich wird noch eine ausführliche Dokumentation der SmartInspect-Bibliothek im CHM-Format mitgeliefert. Beides ist nur in englischer Sprache verfügbar.

„Debug World“

imageWer wie ich kein Freund von Bedienungsanleitungen ist und lieber direkt versucht loszulegen wird bei SmartInspect auf keine größeren Schwierigkeiten stoßen. Es empfiehlt sich aber  zumindest das Tutorial auf der Website des Anbieters einmal zu überfliegen. Für eine erste kleine Beispielanwendung erstellen wir ein Windows Forms-Projekt in Visual Studio und fügen die SmartInspect-Library als Referenz hinzu (Bild 1). Im Unterordner /lib/ des Installationsverzeichnis finden sich die Bibliotheken für die Programmiersprachen Delphi (Version 6, 7, 2005, 2006, 2007), .NET (v1.x, v2.x, v3.x) und Java. Die Bibliothek hat sich für das .NET 3.0/3.5 Framework nicht verändert und man findet lediglich eine Readme.txt im entsprechenden Verzeichnis welche auf die v2.x Version verweist. Anschließend fehlt nur noch die entsprechende Anweisung um die Bibliotheken von SmartInspect auch einzubinden:

using Gurock.SmartInspect;

Um unserer Testanwendung nun zu Debuggen öffnen wir die Datei Program.cs und aktivieren dies dort in der Methode Main() mit folgender Anweisung („sien“):

SiAuto.Si.Enabled = true;

Das war im Prinzip alles, um die Logging-Funktionalität für eine Anwendung zu aktivieren. Die Eigenschaft Enabled lässt sich dabei jederzeit innerhalb des Programms aktivieren oder deaktivieren, beispielsweise auch über einen Menüpunkt. imageBisher sendet unsere kleine Anwendung allerdings noch keinerlei Informationen an unser Logfile. Zeit das zu ändern!

Wir erstellen einen einfachen Button auf unserer Form und klicken diesen doppelt an. Im automatisch erstellten Click-Event schreiben wir nun folgende Anweisung („simsg“):

SiAuto.Main.LogMessage( "Hello World!" );

Um unsere Anwendung zu testen starten wir zunächst noch die SmartInspect Konsole und anschließend unser Testprojekt. Wenn wir dann auf den Button drücken sehen wir unsere Nachricht in der Konsole von SmartInspect (Bild 2).

Standartmäßig verwendet SmartInspect TCP um die Logfile der Anwendung direkt an den TCP-Server der SmartInspect Konsole zu senden. Dies ist für das Debuggen auf dem Entwicklungsrechner oder im internen Firmennetz durchaus praktikabel. Soll die Anwendung hingegen eine Datei auf der Festplatte mit den Daten ablegen ist lediglich eine weitere Zeile Code vor dem Setzen der Eigenschaft enabled  auf true notwendig („siconn“):

SiAuto.Si.Connections = "file(filename="c:myLogfile.sil")";

Ist die Datei bereits vorhanden wird sie standartmäßig überschrieben und ansonsten neu erstellt. Es ist auch möglich mehrere Verbindungen gleichzeitig zu nutzen:

SiAuto.Si.Connections = "file(filename="c:myLogfile.sil"), tcp(host="localhost")";

Was ich an dieser Stelle ein wenig vermisst habe ist ein reiner Logging-Server, der unabhängig der SmartInspect Konsole läuft und der zentral von verschiedenen Anwendungen die Logfiles entgegen nehmen kann. In den Ankündigungen auf der Website des Herstellers habe ich aber gelesen, dass ein solches Zusatzprogramm bereits in Arbeit ist. Vielleicht wird es also mit Veröffentlichung der Version 3 von SmartInspect ein solches Tool auch geben.

Logging-Level

Im ersten Beispiel war noch kein großer Vorteil gegenüber dem Namespace System.Diagnostics zu erkennen. Ein ähnliches Resultat hätte man hier auch wie folgt erzeugen können:

Trace.WriteLine( "Hello World!" );

SmartInspect bietet jedoch noch viele weitere Funktionen, die eine weitaus detailliertere Protokollierung ermöglichen und es dem Entwickler erleichtern den Ablauf des Programms zu überwachen. Hier nehmen einem die vorgefertigten Snippets einige Schreibarbeit ab und zeigen gleichzeitig wie man diverse Methoden sinnvoll integriert.

debug
verbose
message
warning
error
fatal

Andererseits möchte man während dem Debuggen vielleicht weitaus mehr Informationen protokollieren und auswerten als in der fertigen Anwendung. Oder für eine reine Live-Zustandsüberwachung benötigt man ausschliesslich Fehlermeldungen und nicht die vollständige, mögliche Informationsflut. Hier helfen einem verschiedene Level, die man für die meisten Logging-Befehle festlegen kann. Im einzelnen sind dies sechs bzw. sieben verschiedene Level (siehe Kasten links). Der siebste Level control wird nur von der Klasse ControlCommand verwendet und sollte deshalb nicht vom Anwender manuell vergeben werden.

Zum einen kann man den Standart-Level festlegen mit der folgenden Anweisung:

SiAuto.Si.DefaultLevel = Level.Verbose;

Alle Logging-Anweisungen ohne eine explizite Levelangabe erhalten den hier zugeordneten Wert. Wenn man einzelne Anweisungen davon ausnehmen möchte, muss man also entweder einen bestimmten Befehl verwenden oder den gewünschten Level als weiteren Parameter übergeben. Letzteres geht bei fast allen Befehlen außer dem Protokollieren von einfachen Nachrichten. Bei diesen gibt es jeweils eigene Befehle wie LogError() oder LogDebug(). Welches von beiden einfacher zu lesen ist, ein extra Befehl oder die Übergabe des Levels als Parameter, ist vielleicht Geschmackssache. Ich persönlich bevorzuge jedoch die Parameterübergabe und finde diese Inkonsistenz etwas mühsam.

Unabhängig davon welchen Logging-Level eine einzelne Anweisung hat lässt sich festlegen, welche Meldungen überhaupt den Weg bis in das Logfile schaffen und welche bei der Ausführung nicht weiter beachtet werden:

Edit-viewSiAuto.Si.Level = Level.Warning;

Stelle ich diese Anweisung an den Anfang meiner zu testenden Applikation werden alle Logging-Anweisungen verworfen, die einen kleineren Level besitzen, hier also debug, verbose und message. Eine zweite Methode des Filterns besteht darin alle Nachrichten in das Logfile schreiben zu lassen, was dadurch natürlich unter Umständen bedeutend größer wird, und das Filtern der SmartInspect Konsole zu überlassen. Hier kann man in den so genannten Views auch Filter etc. anwenden, die nur Nachrichten eines bestimmten Typs oder Levels durchlassen (Bild 3). Das ist für ausgelieferte Anwendungen aber sicher nicht sehr praktikabel, da die Größe einer Logfile so schon mal schnell auf ein Vielfaches ansteigen kann.

Thread-Protokollierung

Einer der großen Vorteile von SmartInspect ist die Möglichkeit auch Anwendungen mit mehreren Threads sauber mitprotokollieren zu können. Damit das funktioniert muss man in den aufgerufenen Thread entsprechende Funktionen von SmartInspect einbinden („sitr“):

SiAuto.Main.EnterThread( "Threadname" );
try {
...

}
finally {
  SiAuto.Main.LeaveThread( "Threadname" );
}

Das Snippet bindet automatisch das try/finally-Konstrukt mit ein, damit der Aufruf der LeaveThread() Methode in jedem Fall gesichert ist. Als Name lässt sich jeder beliebige Name eingeben, es bietet sich hier jedoch der Methodenname des Threads an. Alternativ kann man auch noch einen Logging-Level festlegen der für den Thread-Aufruf entsprechend gespeichert wird:

SiAuto.Main.EnterThread( Level.Debug, "Threadname" );

threads Wenn man dieses Konstrukt bei jedem Threadaufruf sauber verwendet kann man in der SmartInspect Konsole mehrere Eigenschaften dieser Threads mitverfolgen wie beispielsweise die ID, Startzeit und die Laufzeit (Bild 4). Zusätzlich wird auch mitverfolgt, in welchem Thread sich eine Logging-Funktion bei ihrem Aufruf befunden hat. So kann man in der SmartInspect Konsole sich beispielsweise nur die Logmessages eines bestimmten Threads anzeigen lassen. Auch bietet das Programm die Möglichkeit an anhand bestimmter Regeln automatisch neue Views zu erstellen. So ist es beispielsweise möglich, dass für jeden neu gestarteten Thread die SmartInspect Konsole automatisch eine neue View anlegt, so dass man auf einen Blick nur die von diesem Thread benutzten Methoden sehen kann.

Analog zu den Methoden EnterThread() und LeaveThread() gibt es noch weitere die analog eingesetzt werden können für eigene Methoden (EnterMethod() / LeaveMethod(), „sime“) und Prozesse (EnterProcess() / LeaveProcess(), „sipr“). Um den Hauptprozess eigens zu benennen kann man also die Datei program.cs wie folgt ergänzen:

SiAuto.Main.EnterProcess( "My Program" );
try {
  Application.Run( new Form1() );
} finally {
  SiAuto.Main.LeaveProcess( "My Program" );
}

Die mit diesen Methoden protokollierten Aufrufe lassen sich wie auch schon bei den Threads in SmartInspect gefiltert anzeigen. So kann man auch unabhängig vom Logging-Level beispielsweise alle Methodenaufrufe in der Konsole ausblenden. Innerhalb der SmartInspect Konsole werden sämtliche Aufrufe außerdem hierarchisch dargestellt, d.h. innerhalb einer Baumstruktur ist auf einen Blick ersichtlich in welcher Methode beispielsweise eine bestimmte Logging-Nachricht erzeugt wurde. Die einzelnen Äste lassen sich entsprechend auf mit dem gewohnten Plus- und Minuszeichen auf- und einklappen um eine schnelle Übersicht zu gewinnen. Hierbei ist mir jedoch negativ aufgefallen, dass die Konsole nach jeder Änderung, beispielsweise dem Einfügen eines Kommentares oder dem Einfärben einer Zeile, wieder sämtliche Äste einblendet selbst wenn diese zuvor geschlossen wurden. Das ist leider auf Dauer doch ziemlich nervig und kostet unnötig Zeit.

Weitere Logging-Möglichkeiten

Natürlich kann man mit SmartInspect nicht nur einfache Textnachrichten oder das Starten und Beenden von Threads, Methoden und Prozessen protokollieren. In der umfangreichen Bibliothek warten noch zahlreiche weitere Methoden, mit denen man beinahe jedes Objekt in das Logfile schreiben kann beispielsweise Bilder, Icons, SQL-Querys, Streams, Dateien, Exceptions, HTML-Text, Textreader oder auch ganz allgemein Object. Wem die vielfältigen Möglichkeiten der mitgelieferten Bibliothek nicht ausreichen kann diese auch einfach um eigene Methoden erweitern um beispielsweise eine eigene Logging-Methode zu schreiben. Um die protokollierten Objekte betrachten zu können besitzt die SmartInspect Konsole verschiedene sogenannte Viewer, die die unterschiedlichsten Daten aufbereiten und entsprechend darstellen. Hierzu gehört die einfache Textanzeige, der Objekt-Viewer, die Binäranzeige, der Sourcecode-Viewer (mit Syntax-Highlighting für XML, T-SQL, HTML, …) und für protokollierten HTML-Text einen integrierten Webbrowser.

exception Gerade das Protokollieren von Exceptions bietet sich bei try/catch-Blöcken an. Selbst wenn man eine eigene, eventuell sogar transparent im Hintergrund stattfindende, Fehlerbehandlung verwendet kann man so leicht feststellen, welche Methode / Thread / Prozess bei welchem Aufruf eine Ausnahme ausgelöst hat und auch die vorangegangenen Aktionen mit berücksichtigen (sofern sie protokolliert wurden). Aber auch andere Fehler und dabei beteiligte Objekte lassen sich mit den entsprechenden Methoden in das Logfile zur (späteren) Analyse schreiben. Gerade am Anfang neigt man dazu hauptsächlich die gewohnten reinen Textnachrichten zum protokollieren zu verwenden. Man sollte sich aber möglichst frühzeitig auch mit den anderen Methoden auseinander setzen, da sie einem die Debug-Arbeit teilweise deutlich erleichtern können.

watches Eine sehr nützliche Erweiterung stellen die so genannten „Watches“ dar. Statt beispielsweise in einer Schleife oder ähnlichem die Anzahl von Durchläufen mit der Methode LogInt() auszugeben kann man hierfür auch die Methode Watch() verwenden („siw“):

SiAuto.Main.Watch("Name", value);

Der Wert value wird dabei ebenfalls protokolliert mit dem angegebenen Namen, allerdings wird dieser nicht innerhalb des Protokoll-Trees angezeigt sondern in einem speziellen Bereich der Konsole. Dort sind alle überwachten Werte zusammengefasst mit ihrem jeweils gerade aktuellem Wert. Die Änderung dieses Wertes lässt sich bei Bedarf auch grafisch in einem Graphen darstellen um den zeitlichen Verlauf des Wertes zu visualisieren (Bild 6). Sowohl die Aktualisierung des angezeigten Wertes als auch des Graphen geschehen hierbei in Echtzeit sofern die Logging-Daten der Anwendung per TCP an die Konsole übertragen werden.

Team-Work

SmartInspect ist grundsätzlich mit einigen Funktionen ausgestattet, die es auch Entwickler-Teams ermöglichen gemeinsam die erstellten Logfiles auszuwerten. So kann man zu den Einträgen im Logfile Kommentare hinzufügen, einzelne Zeilen manuell oder automatisiert einfärben und das Logfile direkt aus der Konsole heraus an andere Mitarbeiter per E-Mail oder dem integriertem TCP-Dienst versenden. Bei letzterem muss der Empfänger des Logfiles in seiner SmartInspect Konsole den TCP-Server aktivieren. Anschließend kann der Kollege durch Eingabe des Hostnames und des entsprechenden Ports seine aktuelle Logfile direkt auf die andere Konsole übertragen ohne die Dateien von Hand austauschen zu müssen. Wie bereits weiter oben erwähnt fehlt mir hier im Augenblick noch die Möglichkeit eines zentralen Servers.

Um die protokollierten Daten auch in anderen Anwendungen verwenden zu können gibt es auch diverse Export-Möglichkeiten. Hier bietet SmartInspect das Exportieren aller Daten sowohl in das CSV- als auch das XML-Format an. Beide Formate ermöglichen es die enthaltenen Daten leicht zu ändern oder auch in anderen Applikationen zu verwenden. Zusätzlich gibt es noch einen Export in das HTML-Format. Das Ergebnis ist eine webfähige Darstellung des Logfiles inklusive der Icons, Einrückungen und farblichen Markierungen. Auch eine Zusammenfassung aller Watches und Threads wird an das Ende hinzugefügt. Erfreulich ist, dass der erzeugte Quellcode valide nach HTML 4.01 Transitional ist.

 

Grab-Bag

Über eine Anwendung wie SmartInspect kann man vermutlich ein ganzes Buch füllen. Neben den bereits erwähnten Funktionen gibt es deshalb noch zahlreiche andere Möglichkeiten, die ich hier entweder aus Platzmangel nicht ausführlich beschrieben habe oder die ich aus Zeitmangel selber noch nicht im Detail getestet habe. Einige, meiner Meinung nach nützliche, sollen deshalb hier noch eine kurze Erwähnung finden.s

Fehlerbehandlung

Die Bibliothek von SmartInspect wirft selber eigentlich keine Fehler um den Ablauf des Hauptprogramms nicht zu beeinflussen. Eine Ausnahme ist die Verwendung eines ungültigen Wertes beim Erstellen der Verbindung. Um auf Fehler der Bibliothek innerhalb der Anwendung reagieren zu können wurde jedoch ein Event bereitgestellt das man abonieren kann:

SiAuto.Si.Error += new ErrorEventHandler( Si_Error );

...

static void Si_Error( object sender, ErrorEventArgs e ) {
  Console.WriteLine( e.Exception );
}

Protokolle

Das Speichern der Daten in eine Datei oder das Versenden über TCP sind vermutlich am häufigsten eingesetzten Protokolle. Zusätzlich bietet SmartInspect aber noch weitere Möglichkeiten:

  • File Protocol“ – Wie bereits erwähnt werden die Daten hier im SmartInspect-Binärformat abgespeichert
  • TCP Protocol“ – Die Anwendung versucht eine Verbindung zur SmartInspect Konsole aufzubauen und überträgt die Daten dann direkt
  • Memory Protocol“ – Die Daten werden im Speicher vorgehalten und auf Anforderung in einen Stream gespeichert
  • Text Protocol“ – Die Daten werden in einer Textdatei gespeichert und man kann selber entscheiden wie die Meldungen hier formatiert werden

Konfigurationsdatei

Statt alle notwendigen Einstellungen direkt in den Quellcode der Anwendung zu schreiben kann man auch eine Konfigurationsdatei bereitstellen die dann von der SmartInspect-Bibliothek zur Laufzeit der Anwendung geladen wird. Um eine solche Konfigurationsdatei zu erstellen liefert Gurock Software auch gleich ein passendes Tool mit: „SmartInspect Configuration Builder“. Der Vorteil hierbei ist, dass man beispielsweise den Standart-Loglevel jederzeit ändern kann sowie die Art und Weise des Loggings (siehe „Protokolle) ohne am eigentlichen Quellcode etwas zu verändern.

Eigene Erweiterungen

Wem die mitgelieferten Funktionen von SmartInspect  nicht ausreichen der kann einfach selber Hand anlegen: Sowohl der vollständige Quellcode der Bibliothek steht zur Verfügung als auch umfangreiche Möglichkeiten beispielsweise eigene Log-Events innerhalb der eigenen Anwendung zu erstellen.

Selbsterstellte Objekte

In diesem kurzen Erfahrungsbericht habe ich der Einfachheithalber ausschließlich die von SmartInspect automatisch erzeugten Objekte verwendet, die man über SiAuto ansprechen kann. Allerdings besteht auch die Möglichkeit sich selber um diese Objekte zu kümmern, was einem einen flexibleren Umgang mit diesen ermöglicht. Es ist hierfür notwendig sowohl ein SmartInspect-Objekt als auch ein Session-Objekt zu erzeugen wobei letztere einem SmartInspect-Objekt zugeordnet sein müssen. So können dann beispielsweise unterschiedliche Session-Objekte ihre Meldungen in verschiedenen Farben an die SmartInspect Konsole senden um die einzelnen Sessions leichter auseinander halten zu können.

Automatische Views und Marker

Wie bereits beim Punkt „Thread-Protokollierung“ erwähnt besitzt die SmartInspect Konsole die Möglichkeit anhand von bestimmten Regeln automatisch weitere Views zu erstellen. Eine View ist dabei ein Anzeigefenster für die protokollierten Daten dessen Inhalt man anhand verschiedenster Kriterien und Regeln filtern kann. Zur weiteren Erleichterung bietet die Konsole auch die Möglichkeit Marker automatisch zu erzeugen. Ein Marker ist hierbei eine farbliche Hervorhebung einer Zeile (Bild 5). Man kann also beispielsweise alle Nachrichten, die den Level „Error“ haben rot oder Nachrichten die eine bestimmte Zeichenkette enthalten gelb hinterlegen. Hierbei können auch reguläre Ausdrücke verwendet werden, was die Möglichkeiten für diesen Automatismus potenziert.

Fazit

Ich war zunächst ein wenig skeptisch ob eine Anwendung die „nur“ für das Logging Verwendung findet über 200 Euro wert sein kann. Ein paar write-Befehle in eine Textdatei kann ich auch mit Bordmitteln realisieren und Visual Studio bringt auch einen brauchbaren Debugger mit. Was ich dann aber beim Testen und Ausprobieren der vielen Möglichkeiten von SmartInspect erlebt habe war ein regelrechtes „Wow“-Erlebnis: Das ansonsten recht unangenehme Debuggen von Programmen (wer beschäftigt sich schon gerne mit Fehlern die er dazu noch selbst zu verantworten hat!) wird mit diesem Tool deutlich vereinfacht und lässt die Fehlersuche deutlich effizienter werden. Gerade das Debuggen von Web-Applikationen ist selbst im Livebetrieb mit SmartInspect kein Problem mehr. Natürlich ist es ein wenig aufwändig eine bereits (zum Teil) fertige Anwendung nachträglich mit der SmartInspect-Bibliothek nachzurüsten; doch diese Zeitinvestition rechnet sich später eindeutig bei der Fehlersuche. Spätestens wenn man Fehler in bereits ausgelieferten / im Produktiveinsatz befindlichen Anwendungen in einer erzeugten Logfile nachvollziehen will spart einem das Produkt von Gurock Software wertvolle Arbeitszeit die man dann sinnvoller für die Fehlerbeseitigung nutzen kann.

Ein paar kleine Abzüge in der B-Note gibt es nur für ein paar Ungereimtheiten im Handling (bsp. das Aufklappen aller Äste beim Ändern eines Eintrages in der View) und die nur in englisch verfügbaren Handbücher und Hilfen. Letztere sind aber dennoch sehr ausführlich und gut geschrieben und machen bei soliden Englischkenntnissen keine großen Schwierigkeiten. Etwas ausführlicher könnte die Dokumentation lediglich bei Themen wie die Erweiterung mit eigenen Log-Events usw. sein, hier ist man zum Teil leider auf „Try’n’Error“ oder das Suchen im Support-Forum auf der Website angewiesen.

Insgesamt bekommt SmartInspect von mir 4 von 5 Punkten; ich kann jedem ernsthaften Entwickler nur empfehlen sich die kostenlose Testversion einmal anzusehen und eine Weile damit zu arbeiten. Auf der anderen Seite ist die Anwendung sicher auch für den Hobby-Programmierer und für eher kleine Projekte interessant, hier dürften die Kosten den Nutzen jedoch überwiegen. Es wäre deshalb noch wünschenswert, wenn Gurock Software für beispielsweise Studenten und OpenSource-Entwickler eine kostenlose oder zumindest stark vergünstigte Variante anbieten würde.

Questions/Suggestions
As always, for questions or feedback, contact me or leave a comment.

Octocat by GitHubEdit this page on GitHub