Autor Beitrag
dgurock
Hält's aus hier
Beiträge: 8



BeitragVerfasst: So 06.05.07 18:23 
Hallo zusammen,

Nach der Einladung von Tino freue ich mich, unser Logging Tool SmartInspect hier im Forum vorstellen zu dürfen. Erst einmal kurz ein paar Worte über mein Unternehmen und mich. Zusammen mit meinem Bruder Tobias Gurock habe ich Gurock Software Ende 2004 gegründet und Anfang 2005 mit SmartInspect unser erstes Produkt herausgebracht. Seitdem haben wir unter anderem ein Blog gestartet, DelphiFeeds.com gegründet und SmartInspect 2.0 veröffentlicht.

Über SmartInspect
Was genau ist SmartInspect? SmartInspect ist ein Logging Tool für .NET, Java und Delphi und erlaubt es Entwicklern, Probleme in ihren Applikationen zu finden, Produktionssysteme zu überwachen und bei Kundenproblemen schnell reagieren zu können und eine Lösung zu finden. Wie funktioniert das ganze? Es ist eigentlich ganz einfach: als Entwickler bindet man eine der drei SmartInspect Bibliotheken für .NET, Java und Delphi in seine Applikation ein und fügt Logging Aufrufe an alle Stellen bzw. in alle Teile der Applikation ein, die überwacht werden sollen. Dabei können neben einfachen Nachrichten auch Exceptions, Objekte, Dateien, Screenshots, Prozesse und Threads geloggt werden (und noch einiges mehr).

Für die verschiedenen Anwendungsfälle können die Logging Informationen über verschiedene Protokolle geloggt werden. Das wohl am meisten benutzte Protokoll ist hierbei das File Protokoll, mit dem Log Dateien in einem eigenen optimierten Binärformat gespeichert werden. Wie bei den anderen unterstützten Protokollen gibt es auch beim File Protokoll verschiedene Optionen um zum Beispiel die Größe der Log Dateien zu begrenzen oder auch stündlich/täglich etc. zu rotieren. Neben Log Dateien gibt es auch Protokolle für die live Übertragung per TCP/IP, Log Dateien im Textformat und ein Protokoll das die Informationen im RAM speichert und für die Zusammenarbeit mit Exception Reporting Tools wie EurekaLog konzipiert wurde.

ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
{ Enable SmartInspect logging }
Si.Connections := 'file(filename=c:\log.sil)';
Si.Enabled := True;

{ Log simple messages, warnings and exceptions }
SiMain.LogMessage('Processing Order 48843');
SiMain.LogError('Connection refused while trying to connect!');
SiMain.LogException(E);

{ Generate call stack information }
SiMain.EnterMethod(Self, 'Button1_Click');
SiMain.LeaveMethod(Self, 'Button1_Click');

{ Log variables values, datasets or any other object }
SiMain.LogInteger('Index', Index);
SiMain.LogObject('Order', Order);
SiMain.LogDataSet('DataSet', DataSet);

Wie werden die Logging Informationen ausgewertet? Zum Analysieren, Filtern und Durchsuchen von Log Dateien und zum live Überwachen von Applikationen gibt es die SmartInspect Console. Die SmartInspect Console bietet allerhand an Möglichkeiten die Daten auszuwerten. So gibt es zum Beispiel die Möglichkeit, eigene Views anzulegen die nur bestimmte Teile des Logs anzeigen. Über AutoView Rules ist es sogar möglich, automatisch neue Views für verschiedene Threads erstellen zu lassen. Dadurch kann einfach analysiert werden, was welcher Thread genau macht und es können so zum Beispiel Synchronisierungsfehler einfacher gefunden werden.

user defined image

Mit der Console können neben den Log Entries selbst auch angehängte Informationen ausgewertet werden. So können zum Beispiel die Eigenschaften eines Objektes, Texte, Screenshots oder auch Speicherbereiche in einem HEX Viewer angezeigt werden.

Entwicklung des Produktes
Für viele Forumsteilnehmer ist es sicherlich interessant, wie wir SmartInspect entwickelt haben. Die einzelnen Logging Bibliotheken sind jeweils in den Sprachen für das jeweilige Entwicklungstool bzw. für die jeweilige Plattform entwickelt worden. Dies bedeutet, dass die Java Bibliothek in Java, die Delphi Bibliothek in Delphi und die .NET Bibliothek in C# entwickelt wurden. Da wir auch den Quelltext der Bibliotheken mitliefern und Kunden so weniger Deploy Probleme haben, war es auf jeden Fall die richtige Entscheidung die Bibliotheken in den jeweiligen Sprachen zu entwickeln, auch wenn es durchaus mehr Arbeit war und ist.

Die SmartInspect Console selbst haben wir in Delphi entwickelt. Die ersten Jahre haben wir dabei Delphi 7 verwendet. Wir haben die Console jedoch vor ca. einem Jahr auf Delphi 2006 portiert und wechseln zurzeit auf Delphi 2007. Für die Console haben wir einige Third-Party Komponenten verwendet, ohne die die Entwicklung deutlich aufwendiger gewesen wäre. Einige dieser Komponenten möchte ich nachfolgend auflisten, auch wenn sie vermutlich hier schon sehr gut bekannt sind:
  • Die wichtigste Komponente für die Console ist vermutlich der VirtualTreeView. Wir verwenden diese Komponente wirklich für alles mögliche und gerade die Flexibilität, Geschwindigkeit und Unicode Unterstützung sind für uns sehr wichtig
  • Für das Docking und die Toolbars nutzen wir die DevExpress ExpressBars. Da diese Komponenten leider weder den neuen Visual Studio Style noch Unicode unterstützen, mussten wir diese Komponenten stark umschreiben und erweitern, um Sie einsetzen zu können.
  • Für den Binary Viewer benutzen wir die TMPHexEditor Komponente um die Binärinformationen in einer Hex Ansicht anzuzeigen. Ich kann die Komponente nur empfehlen, da sie uns einiges an Arbeit bzw. Zeit gespart hat
  • Für den TCP/IP Server innerhalb der SmartInspect Console verwenden wir Indy. In der Delphi Bibliothek benutzen wir Indy zwar nicht (aus Deploy Gründen), aber für die Console war Indy genau die richtige Wahl und wir sind mit der Qualität der Indy Bibliothek sehr zufrieden
Wir haben noch einige weitere Third-Party Komponenten und Bibliotheken in der Console verwendet, aber diese alle hier aufzulisten würde zu weit führen. :-)

Mehr Informationen
Für mehr Informationen über SmartInspect könnt ihr natürlich unsere Webseite besuchen, die Trial herunterladen, uns eine E-Mail schreiben oder direkt hier fragen. Ich freue mich über euer Feedback!
Vera
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 82

WinXP Home
Delphi 2005 Personal
BeitragVerfasst: Mo 07.05.07 11:41 
Hallo Dennis!

Da ich in der Firma u. a. für das Erstellen der Dokumentation verantwortlich bin würde ich gerne erfahren wie Ihr die Dokumentation erstellt und ob und wie Ihr diese in Eurem (wenn vorhanden) Buildprozess integriert habt. :-)

Würde mich freuen wenn Du darüber kurz ein paar Sätze schreiben würdest. Zum Beispiel welches Programm ihr dafür benutzt. Sind die Doku-Projektdateien normale Txt Dateien? Können diese also gut mit einem Versionskontrollsystem verarbeitet und mit einem Diff-Tool ordentlich verglichen werden? Welche Exportmöglichkeiten verwendet Ihr wann und wofür (PDF, CHM, HMLT?) ???

Lg, Vera
dgurock Threadstarter
Hält's aus hier
Beiträge: 8



BeitragVerfasst: Mo 07.05.07 23:34 
Hallo Vera,

user profile iconVera hat folgendes geschrieben:
Da ich in der Firma u. a. für das Erstellen der Dokumentation verantwortlich bin würde ich gerne erfahren wie Ihr die Dokumentation erstellt und ob und wie Ihr diese in Eurem (wenn vorhanden) Buildprozess integriert habt. :-)

Da wir ja ein paar spezielle Anforderungen haben (wir brauchen eine richtige API Dokumentation, mit Unterstützung für .NET, Java und Delphi), brauchten wir auch ein spezielles Dokumentationstool. Wir haben mit Doc-o-matic ein Tool gefunden, mit dem wir ganz gut arbeiten können. Doc-o-matic ist für API Dokumentation optimiert. Dies bedeutet, dass wir unseren Quelltext mit XML Doc Kommentaren dokumentieren (zum Beispiel ein Block vor jeder Methode usw) und Doc-o-matic generiert daraus eine komplette API Dokumentation.

Es ist mit Doc-o-matic aber genauso gut möglich, eine "normale" Hilfe zu bauen. Für die SmartInspect Console brauchten wir auch eine normale Online Hilfe. Doc-o-matic verwaltet die Texte für die Hilfe in Text Dateien mit einfachem Markup (einfacher als HTML, eher wie bei Wikis) und eignet sich sehr gut für Versionskontrolle und Diffs. Die Doku selbst wird wie gesagt entweder im Quelltext gepflegt (für APIs) oder in einem recht komfortablen visuellen Editor für normale Hilfen. In unserem Build Prozess konnten wir Doc-o-matic auch recht einfach integrieren, da wir die CHM und PDF Dateien direkt per Kommandozeile von Doc-o-matic generieren lassen können.

Für normale Dokumentation, die PDF, HTML und CHMs etc unterstützen sollen, wäre Help&Manual aber wohl besser geeignet. Nur für API Dokumentationen ist die manuelle Pflege aller Methoden und Properties, Übersichten, Links etc einfach viel zu aufwendig. Ich hoffe ich konnte Deine Fragen beantworten. :-)
C#Master
Hält's aus hier
Beiträge: 13



BeitragVerfasst: Di 08.05.07 10:28 
hi gurock´s :-)

Ein wirklich interessantes Tool habt ihr da programmiert! Respekt. :zustimm: Ich werde es mir heute Abend downloaden und genauer anschauen.

Da wir bei uns in der Firma gerade über das Thema Unit Test diskutieren würde es mich interessieren ob ihr auch Unit Tests durchführt und - wenn ja - was für eine Motivation dahinter steckt um auch wirklich immer diese Tests zu erweitern und auszuführen. Zur Zeit sehe ich bei mir persönlich einfach das Problem die Motivation zu entdecken. ;-)

Was mich ebenfalls interessieren würde ist welches VCS ihr benutzt und welche Clients Ihr verwendet.
dgurock Threadstarter
Hält's aus hier
Beiträge: 8



BeitragVerfasst: Mi 09.05.07 19:57 
Hallo,

user profile iconC#Master hat folgendes geschrieben:
Ein wirklich interessantes Tool habt ihr da programmiert! Respekt. :zustimm: Ich werde es mir heute Abend downloaden und genauer anschauen.

Vielen Dank! Falls es Fragen gibt, einfach hier stellen oder eine email an Support schicken.

user profile iconC#Master hat folgendes geschrieben:
Da wir bei uns in der Firma gerade über das Thema Unit Test diskutieren würde es mich interessieren ob ihr auch Unit Tests durchführt und - wenn ja - was für eine Motivation dahinter steckt um auch wirklich immer diese Tests zu erweitern und auszuführen. Zur Zeit sehe ich bei mir persönlich einfach das Problem die Motivation zu entdecken. ;-)

Wir benutzen Unit Tests recht intensiv für SmartInspect. Dabei nutzen wir die Unit Tests ausschließlich für die Logging Bibliotheken, nicht aber für die Console. Momentan haben wir ca. 5000 Tests die sicherstellen, dass die Bibliotheken genau das tun, was sie auch tun sollen. :-) Die Motivation ist bei uns recht einfach: unsere Kunden bauen die Bibliotheken in ihre eigenen Applikationen ein und wir müssen sicherstellen, dass die Bibliotheken die bestmögliche Qualität haben. In der Console benutzen wir Unit Tests nicht, da sich GUI Programme nicht wirklich sinnvoll mit Unit Tests testen lassen (meine Meinung). Es ist auf jeden Fall eine Menge Arbeit und man sollte schon genau abwägen, ob es sich lohnt. Sinnvoll kann es aber definitiv sein.

user profile iconC#Master hat folgendes geschrieben:
Was mich ebenfalls interessieren würde ist welches VCS ihr benutzt und welche Clients Ihr verwendet.

Am Anfang haben wir CSV benutzt, sind dann aber relativ schnell auf Subversion umgestiegen. Ich benutze hauptsächlich TortoiseSVN (eine Subversion Integration für den Windows Explorer), mein Kollege den Kommandozeilen Client. Wir sind mit Subversion sehr zufrieden und ich finde es besser als viele kommerzielle Lösungen.
werner m
Hält's aus hier
Beiträge: 2



BeitragVerfasst: Mo 09.07.07 12:11 
Hallo Dennis!

Wie ich sehen benutzt Ihr die DevExpress ExpressBars in Eurer Anwendung. Wir sind auf der Suche nach genau so einer Komponente und ich muss entscheiden ob wir nun die Komponenten von DevExpress oder die von TMS Software in unserer Software verwenden sollen.

Jetzt meine Frage an Euch: ;-) Stand bei Euch die TMS Komponenten auch auf der Liste der möglichen Kandidaten und wenn ja wieso habt Ihr Euch dann letztendlich für die DevExpress Komponenten entschieden?

über eine kurze antwort von Dir/Euch freue ich mich!!!

Werner!
dgurock Threadstarter
Hält's aus hier
Beiträge: 8



BeitragVerfasst: Mo 09.07.07 22:42 
Hallo Werner,

user profile iconwerner m hat folgendes geschrieben:
Jetzt meine Frage an Euch: ;-) Stand bei Euch die TMS Komponenten auch auf der Liste der möglichen Kandidaten und wenn ja wieso habt Ihr Euch dann letztendlich für die DevExpress Komponenten entschieden?


Puh, gute Frage! :-) Da wir die ExpressBars seit der ersten Version benutzen, ist die Entscheidung für eine bestimmte Menu/Toolbar Bibliothek schon etwas länger her. Ich kann aber auf jeden Fall sagen, dass die ExpressBars eine gute Qualität haben, relativ flexibel sind und dass DevExpress regelmäßige Bug Fixes veröffentlicht (man darf solche Bibliotheken nicht unterschätzen - sie sind relativ komplex und deswegen fehleranfällig). Ein großer Vorteil von ExpressBars war die enthaltene Docking Bibliothek die wir für die gesamte Oberfläche verwenden.

Du weißt ja sicherlich, dass es von DevExpress keine Delphi Trials gibt. Ich würde die Komponente eventuell einfach kaufen, testen und mit TMS Trials vergleichen und im Notfall einfach wieder zurückzugeben. Das haben wir bei DevExpress auch schon bei anderen Komponenten gemacht.
werner m
Hält's aus hier
Beiträge: 2



BeitragVerfasst: Mi 11.07.07 08:47 
Guten Morgen Dennis!

Vielen dank für die Antwort. Ich werde mir noch mal beide Sammlungen genau anschauen und versuchen mir auch über die Hilfe ein Bild zu verschaffen.

Ein nicht ganz soooo unwichtiger Punkte wäre auch noch der Preis der jeweiligen Komponente. Da liegt TMS recht weit vorn... aber das ist nicht der wichtigste Punkte. ;-)

Vielen dank noch mal.

Werner!
Ronnie
Hält's aus hier
Beiträge: 9



BeitragVerfasst: Do 27.09.07 13:00 
Hallo!!!

Plant ihr/du bereits euer Produkt in weiteren Sprachen anzubieten? Wenn ja würde mich intressieren wie ihr die Umsetzung plant. Habt ihr vor fertige Komponenten bzw. Lösungen dafür zu verwenden? Z.B. GNU GetText, Sisulizer, TsiLang. Oder würdet ihr das komplett selbst programmieren?

danke für eine antwort. ;-) ronnie
dgurock Threadstarter
Hält's aus hier
Beiträge: 8



BeitragVerfasst: Di 18.12.07 20:22 
Hallo Ronnie,

sorry dass ich jetzt erst antworte, ich hatte die Frage vorher nicht gesehen.

user profile iconRonnie hat folgendes geschrieben:
Plant ihr/du bereits euer Produkt in weiteren Sprachen anzubieten? Wenn ja würde mich intressieren wie ihr die Umsetzung plant. Habt ihr vor fertige Komponenten bzw. Lösungen dafür zu verwenden?


Momentan planen wir keine Mehrsprachenversion von SmartInspect. Wenn wir solch eine Version allerdings entwickeln würden, würde wir dies vermutlich ohne die Hilfe von Drittkomponenten machen (außer eventuell so etwas wie die von dir angesprochene GNU GetText Lösung).

Die ganzen Tools die es erlauben direkt die Ressourcen und Forms zu übersetzen sehen für mich persönlich alle ein wenig, naja, unkalkulierbar aus. Das Beste ist vermutlich direkt eine eigene Lösung mit dem Beginn eines Projektes zu entwickeln, wenn eine Mehrsprachigkeit abzusehen ist. Dies ist aber nur meine persönliche Meinung und stützt sich nicht auf Erfahrungen mit SmartInspect. :-)