Glorf IT

Oracle hat das Prinzip der Communities offenbar noch nicht so richtig verstanden. Im Heise-Online-Artikel "LibreOffice-Macher sollen OpenOffice-Rat verlassen" kann man nachlesen, dass Oracle diejenigen los werden möchte, die auch bei LibreOffice mitmachen.

Die meisten anderen Firmen hätten hier vermutlich die Flucht nach vorne angetreten und versucht den neuen Fork zu umarmen. Oder wenigstens wichtige Mitarbeiter als Brücke zu behalten, um die Interoperabilität zu gewähren und durch den Ideenaustausch eine gegenseitige Befruchtung zu ermöglichen. Damit hätte Oracle auch gleich verlorenes Vertrauen gut machen machen können. Oracle denkt aber in Konkurrenz bzw. Wettbewerb und vergrault die Community damit noch mehr. Das verstehe ich einfach nicht.

Wer die grundsätzliche Art der Softwareentwicklung in einer Open-Source-Community verstehen will, dem empfehle ich den Klassiker auf dem Gebiet "The Cathedral and the Bazaar". Inzwischen ist man freilich schon wieder etwas weiter, aber die grundsätzlichen Regeln gelten immer noch: die (zeitweilige) Vielfalt der Entwicklungslinien ermöglicht eine breitere Akzeptanz. Die Ideen werden teilweise parallel erprobt, erhalten unmittelbares Feedback durch Beteiligung der "Kunden" während der Entwicklung, aber nicht Linien alle setzen sich durch. Das ist wie bei einem Basar bei dem alles bunt durcheinander zu gehen scheint und viele Dinge gleichzeitig und weitgehend unkoordiniert passieren. Beim Bau einer Kathedrale hingegen gibt es Architekten und genaue Pläne. Deswegen wird eine Kathedralensoftware auch irgendwann mal fertig, während Basar-Software nie fertig ist, sondern in kleineren Schritten immer weiter entwickelt wird.

Mittlerweile bauen aber immer weniger Firmen nach dem Kathedralenmodell Software. Dank agiler Vorgehensmodelle (z.B. Scrum) können einige gute Ansätze aus dem Basarmodell auch von Entwicklern in "proprietären" Softwareschmieden eingesetzt werden. Der damit einhergehende Verständniswandel von Softwareentwicklung und Beteiligten ist aber in den Köpfen der Oracle-Manager offenbar noch nicht angekommen…

Für einen Arbeitskreis dürfte ich mir letzte Woche als Krankheitsvertretung sehr kurzfristig Gedanken zum Thema "verteilte Transaktionen in einer service-orientieren Welt" machen. An dem Tag fielen satte 6 Mitarbeiterinnen und Mitarbeiter meines Teams aus. Einige hatten nur die schnelle Krankheit (1 Tag Magen-Darm), andere waren die ganze Woche (einer sogar 2 Wochen) "disabled". Jedenfalls konnte ich an dem Tag prima üben über etwas zu reden von dem ich keine Ahnung habe… Man sagte mir, dass sei für das persönliche Weiterkommen förderlich – ich hoffe das stimmt nicht. 😉

Jedenfalls habe ich bei meiner Suche zum Thema "verteilte Transaktionen mit .net" eine kleine Linksammlung angelegt, die ich hiermit der Öffenlichkeit zur Verfügung stelle. Wenn jemand weitere Artikel zu dem Thema kennt, dann bitte ich um einen Link als Kommentar.

Die ".net Enterprise Transaction Services" bieten scheinbar genau das, was man in einer service-orientieren Welt so braucht: offenbar können hier mehrere Services auf unterschiedlichen Computern an der gleichen verteilten Transaktion teilnehmen. Stimmt das? Und wenn ja, wo ist der Haken: Performance?

Den kurzen, übersichtlichen Artikel "Managing Distributed Transactions with ADO.NET 2.0 using TransactionScope" zum Thema TransactionScope fand ich auch hilfreich.

Der Artikel "Distributed Transactions in .NET 2.0" ist zwar auch weiterführend, aber tendenziell etwas mager.

Der etwas älterere Artikel "HOW TO: Perform a Distributed Transaction with a .NET Provider by Using ServicedComponent in Visual C# .NET" von Microsoft hat mir nur bedingt weitergeholfen.

Keine Ahnung warum, aber in den letzten Tagen kamen mir gleich mehrere Online-Quellen für C# unter. Für mich als C#-Hobby-Nutzer (ich mache dienstlich eigentlich nur SQL) ist das genau richtig. Für den echten Crack dürften die nicht viel bieten…

"C# – Die neue Sprache für Microsofts .NET-Plattform" von Eric Gunnerson, bei Galileo-Computing als "Open Book"
Gute Einführung, leider schon etwas ältlich (aus dem Jahre 2000), daher sind die schicken neuen Sachen von .Net 2.0 vermutlich nicht drin…

Das ".Net BlogBook" enthält hingegen jede Menge aktuelle Tipps aus der Praxis.

Ein gutes Vorlesungsskript der FH-Regensburg. Ich wünschte wir hätten so nett zu lesende Skripte bekommen. Ist natürlich etwas theorielastig…

Mein Kollege Milos machte mich heute auf den Artikel "C++: Einblicke in die nächste Generation von Visual C++ aus dem "MSDN Magazine, June 2007" aufmerksam. Das finde ich echt prima, dass er jetzt schon kostenlos zugänglich ist.

Mittlerweile hat es sich herumgesprochen, dass Microsoft mit dem Visual Studio 2005 auch ein ReportViewer-Control bereitstellt, dass man einfach so in seinen Anwendungen einsetzen kann. Damit kann drei Dinge, eines davon wird von Microsoft aber nicht groß beschrieben…

• Man kann Berichte ansehen, die in einem Reporting-Service aufbereitet wurden.
  Diese Nutzung beschreibt Microsoft super ausführlich. Immerhin wird der Reporting-Service inzwischen sogar mit der Express-Edition ausgeliefert.
• Man kann in seinem Projekt einen Bericht erstellen und ihn in seine Anwendung reinkompilieren. Das wird von Microsoft leidlich beschrieben. Man kann damit einen Bericht am erstellen und aufbereiten (mit allen schicken Features der Reporting-Services ohne ihn installieren zu müssen). Leider kann man damit nur genau einen Bericht pro Control ansehen.
• Außerdem kann man den Control dazu nutzen viele verschiedene Berichte anzuzeigen. Im Prinzip kann man sogar beliebige Berichte anzeigen, wenn man bereit ist, den Aufwand zu erbringen. Damit kann man aus den Reporting-Services das schickste nutzen, die Anzeige und das Rendering der Berichte (inkl. Export nach PDF, Excel usw.), ohne eine Server-Anwendung installieren und konfigurieren zu müssen. Warum das von Microsoft nicht an die große Glocke gehangen wird, ist klar, oder? Sie erwähnen zwar mal die Möglichkeit, aber eine Anleitung fand ich nicht…

Zum letzteren fand ich lediglich einen brauchbaren Artikel, der in Visual-Basic kurz skizziert, wie man das anstellen muss: "Take Control of Your Reports with ReportViewer, Part 2". Er ist kostenpfichtig, die Code-Fragmente sind frei zugänglich. Leider wird darin alles in Visual-Basic gemacht. Es hat eine Weile gedauert bis ich das Prinzip verstanden habe. Ich habe folgende Erkenntnisse gewonnen:

Das ReportViewer-Control übernimmt nur die Anzeige des Berichts: also das Rendering und die Aufbereitung der Daten. Alles andere muss die eigene Anwendung erledigen:

• Zusammenstellen des SQL-Statements, mit dem die Daten gelesen werden. Die Query kann man eigentlich auch aus dem Bericht rauslesen, wenn man sich nicht scheut, sie aus dem XML-File zu entnehmen.
• Die Übergabe der im Bericht enthaltenen Parameter. In dem Beispiel wird gezeigt, wie man dem Bericht-Objekt die Parameter entlocken kann.
• Bereitstellen einer Datasource, die dynamisch erstellt werden kann. Nur der Name muss so sein, wie im Bericht angegeben.

Im ersten Schritt kann man so eine Hülle für das ReportViewer-Control schreiben, die dem Entwickler anhand von bestimmten Namens-Konventionen das Leben leicht macht, z.B. DataSource1 oder Param01.
Andererseits ist die Struktur der Berichte (XML-Datei) sehr einsichtig, deswegen kann man sie auch im ersten Schritt auswerten und die Query, deren Parameter und den Namen der Data-Source ermitteln. Im zweiten Schritt muss man das Control lediglich initialisieren und schon hat man ein Universal-ReportViewer-Control.

Heute habe ich zum dritten mal in den letzten Tagen Kollegen von meine Erfahrungen mit den Unit-Tests für Datenbank-Objekte erzählt. Dazu benutze ich die "Visual Studio Team Edition for Database Professionals", die ich eigentlich wegen anderer Dinge angeschaut habe.
Das interessant daran ist, dass ich mittlerweile zwar schon recht deutlich ein paar Nachteile sehe, aber schon denke, dass es sich schon fast alleine wegen der Units-Tests lohnt die sehr teure Lizenz anzuschaffen.

Es wird einem echt viel Arbeit abgenommen und man muss sich nur um wenige Dinge selber kümmern. Man kann alles Testen, das sich mit SQL ausdrücken lässt: Prozeduren, Funktionen, Views, Trigger, sogar Assemblies.
Ich denke, es eignet sich besonders gut für entwicklungsbegleitendes Testen.

Hier ein paar Schattenseiten, die ich schon fand:

• Für Negativ-Tests muss man gewünschte Fehlermeldungen in einem Catch-Block auffangen und schauen, ob der gewünschte Fehler auftrat. Wenn nicht, muss man einen Fehler werfen. Das geht schon, ist aber unnötig aufwändig: Es wäre schön, wenn man eine Test-Bedingung "Fehler xy tritt auf" angeben könnte.
• Es gibt keine Test-Bedingung, die ein ResultSet mit einer Datei vergleicht. Allerdings war es nur ein geringer Aufwand so eine Erweiterung selber zu schreiben.
• Man kann nicht automatisch die gleichen Tests mit verschiedenen Datenbanken (z.B. mit verschiedenen Datenmengen oder Konstellationen) hintereinander ausführen. Mann muss dazu selber etwas außen rum machen, dass die DBs "austauscht" und die Tests dann neu startet. Dazu hatte ich noch keine Lust, äh Zeit, wird mir aber vermutlich nicht erspart bleiben.

Ich glaube, dass ich langsam aus dem Hype rauskomme und in die Phase "get real" reinrutsche… 😉

Ich bin derzeit total begeistert von den neuen Möglichkeiten der Unit-Tests für Datenbank-Objekte mit der neuen "Visual Studio Team Edition for Database Professionals" (DB-Pro). Einfach unglaublich, wie einfach und komfortabel das geht. Man kann für alle Datenbank-Objekte Unit-Tests erstellen. Ich mache aktuell welche für Stored-Procedures und Functions, aber man kann genauso gut Views automatisch testen.

Für "meine" etwa 50 Prozeduren habe ich schon etwa 180 Unit-Tests geschrieben. Bei Ausdenken der neuen Tests bzw. Umschreiben der alten (ich testete bislang mit einem eigenen Werkzeug) stoße ich immr wiedre auf kleinere Macken, die nach der Umstellung auf SQL-Server-2005 viel eleganter zu machen sind. Mit den Unit-Tests ist das kein Problem: Vorher Tests laufen lassen, Änderung durchführen und wieder die Tests laufen lassen. Wenn dann kein Fehler kommt, dann kann ich sicher sein, dass die Änderung klar ging.

Mit dem sehr guten Artikel "Database Unit Testing with Team Edition for Database Professionals" fiel mir der Einstieg in die Thematik sehr leicht.

Auf dem Weblog des Autors findet sich übrigens ein Beispiel, wie eigene Testbedingungen anlegen kann. Das klappt ganz gut, nachdem ich aus der Datei "SachTestConditions.extensions.xml" das Attribut "xsi:schemaLocation" vom Element "extensions" entfernt hatte.

Ein Beispiel bei SQL-Server-Central (kostenlose Anmeldung erforderlich), dass jedoch leider einige Patzer enthält, z.B fehlt in der Extension-Xml die Angabe des Attributs xmlns, ist der Artikel "Putting Unit Tests to Work".

Alleine schon wegen dieser tollen Möglichkeit rund um Unit-Tests zu SQL-Server-Datenbankobjekten würde ich jedem Datenbank-Entwickler dazu raten sich diese Edition anzuschaffen. Der Preis ist schon ganz schön hoch, aber der Zugewinn in der QS sollte dem Chef die Ausgabe wert sein…

Ich bin noch nicht mal dazu gekommen mich in LINQ einzuarbeiten, da schiebt Microsoft schon das nächste Datenzugriffs-Api nach: Jasper

"Jasper" ist der Codename für "Dynamic ADO.NET 3.0" und bietet angeblich:

• dynamische Klassengenerierung (ohne Konfiguration)
• umfangreiches O/R-Mapping
• automatisches Binding für ASP.NET, WinForms und WPF

Die ersten beiden Punkte lassen aufhorchen und könnten begeistern, immerhin fehlt es hier bisher immer noch ein Stückchen. Der Letzte macht es aber auch ein wenig suspekt, womöglich werden hier die Oberflächen auch wieder so stark an die Datenzugriffsklassen drangeklebt?

Warten wir es ab, interessant wird es auf jeden Fall. Infos aus ersten Hand findet man im Ado-Net-Blog.

Eine ganz hübsche Sammlung zu allen Jasper- Informationen findet man im OakLeaf-Blog: ""Jasper" to Deliver Dynamic ADO.NET 3.0"

Der Download des CTP steht seit zwei Tagen bereit. Als Vorausetzung benötigt man aber das Visual Studio (Codename "Orcas") Beta1…

Auf der Seite "Spec# for Visual Studio 2005" findet man jetzt Spec# zum Download. Gesprochen wird das "Speck-Sharp".

Auf obiger Seite wird kurz zusammengefasst, was Spec# ist:

Spec# is an experimental language that extends C# with several design-by-contract features. The new features of Spec# include a non-null type system, method pre- and post-conditions, loop invariants, and object invariants. The Spec# Programming System provides design-time checking, run-time checking, and a static verifier. This version of Spec# runs on .NET Framework version 2.

Wer mehr Infos haben will, der wird auf der Homepage von Spec# fündig. Dort ist auch ein Link zum Download für Visual Studio 2003, aber der ist derzeit tot.

Falls auch Andere gerade überlegen, wie man das Visual-Studio noch besser auf die eigenen Bedürfnisse zuschnitzen kann:

Learning by example

Für codeproject.com schrieb Jon Rista eine ganz gute Anleitung, wenn man selber ein AddIn für das Visual-Studio-2005 schreiben will. Es wird anhand eines konkreten Beispiels erklärt: "Line Counter – Writing a Visual Studio 2005 Add-In"

Das ist zwar schon 11 Monate alt, aber sehr gut erklärt und noch aktuell.

Grundlagen in deutsch

Wer es lieber in deutsch mag oder ein Fan von Mirko Matytschak ist, der sollte unbedingt seinen Artikle lesen, der auch in dr MSDN zu finden ist: "Unbegrenzte Möglichkeiten mit Visual Studio Add-ins". Das gesagte bezieht sich aber auf das Visual-Studio-2003 und könnte sich daher im Detail überholt haben.

Ein Blick auf die aktuellen Features des März CTP von Orcas zeigt mir, wo demnächst die Musik spielt. Ich denke für alle, die .Net-Software mit Datenbank-Zugriffen schreiben, mich eingeschlossen, wird höchste Zeit sich mit diesem Release des Visual Studio und allen seinen schönen Features zu beschäftigen. Ich frage mich ob sich dann nicht so manche Grundsatz-Diskussion, die wir gerade führen, von selber erledigt: Machen wir es lieber so oder so? Vielleicht kann man einfach nehmen, was Microsoft bietet…

Details finden sich auch in dem Artikel "New Data Tools Features in Visual Studio Orcas" auf dem VB-Team-Blog. Hier wurde ich überhaupt erst auf das März-CTP aufmerksam.

Glossar:

CTP – Früher nannte man solche Vorabversionen erst Alpha dann Beta, je nach Reifegrad. Zusätzlich dazu verteilt Microsoft jetzt immer wieder auch "Customer Technical Previews" (CTP), um die Kunden während der langen Entwicklungsphasen bei der Stange zu halten.

ORCA – Das ist der Codename für die nächste Version des Visual Studio.

In dem Artikel "Tipps und Tricks für die Visual Studio 2005-IDE" finden sich viele interessante Bedienungshinweise für das Visual Studio.

Etliche Tipps gelten auch für das SQL Server Management Studio, wie z.B. "Strg+K, Strg+C" und "Strg+K, Strg+U" zum kommentieren und auskommentieren.