code it

Martins Tech Blog

Nachlese zum Treffen der .NET Usergroup Dresden vom 17.03.2011

Gestern gab es gleich zwei Premieren bei der .NET Usergroup Dresden.

Premiere 1: Wir haben das erste Mal ein Coding Dojo durchgeführt. 18:00 Uhr ging es los. Nachdem beim letzten Usergroup-Treffen die ein oder anderen Fragen auch in Richtung testgetriebene Entwicklung und die Sinnhaftigkeit gingen bin ich in ein paar einleitenden Worten darauf eingegangen, was testdriven eigentlich bedeutet und wie man dabei vorgeht.

Ausgehend davon wurde der Rahmen für den Abend gesteckt. Ich erklärte die Grundbegriffe von Coding Dojos und weil es für viele das erste Dojo war, begannen wir mit der recht einfachen Kata FizzBuzz. Im Vordergrund für diesen Abend stand einfach nur, allen ein Gefühl für TDD zu geben und die Angst vor dem Unbekannten "Coding Dojo" zu nehmen. Zweite Kata des Abends sollte nach einer Abstimmung Kata Potter sein, die aber nach unterschiedlichen Lösungsvorschlägen und Herangehensweisen irgendwann dann abgebrochen wurde.

Für mich war es das erste mal als Sensei und ich habe ein paar wertvolle Schlüsse ziehen können. Zunächst habe ich mich sehr gefreut, dass sich auch Usergroup-Teilnehmer, die eigentlich als Muttersprache VB.NET sprechen (wie sie es selbst genannt haben) in einem C#-Projekt mitgearbeitet haben, auch wenn "dieses komische Semikolon immer" gestört hat. Mir hat es sehr gut gefallen, dass eben nicht nur ein Vorturner da war, sondern dass wir die Gelegenheit hatten, vom Wissen aller zu profitieren, die sich freiwillig gemeldet haben, an der Kata mitzumachen. Und hier hat sich wieder gezeigt, dass es wichtig ist, nicht vorn still vor sich hin zu programmieren, sondern alle an den Gedanken teilhaben zu lassen.

Es gab aber auch ein paar Lehren für mich: Bei einer Gruppengröße von 20 Teilnehmern ist es recht kompliziert alle bei der Sache zu halten. Und, es hat sich herausgestellt, dass es wichtig ist, auch im Dojo die Schritte Red-Green-Refactor alle durchzuführen und es nicht auf Red-Green-Vielleicht-Refactor zu beschränken. Dem resultierenden Code merkt man nämlich an, dass er dringend ein Refactoring benötigt. Und zu guter Letzt ist es wichtig, nicht blind drauf los zu programmieren, sondern sich auch zu Beginn schon mal Gedanken darüber zu machen, in welche Richtung es gehen soll. Denn was nutzen 7 grüne Tests, wenn man der Lösung noch nicht wirklich näher gekommen ist und erst dann überlegt, wie man das Problem denn lösen könnte.

Zusammenfassend: Es war ein gelungener erster Dojo-Abend. Ich denke, wir werden das auch weiter fortführen und gelegentlich Dojo-Abende einstreuen und die Schlüsse die ich und auch die anderen aus diesem Abend ziehen konnten werden dann sicher auch Eingang finden. Die Resonanz war zumindest eindeutig positiv. Und nicht zuletzt habe ich mich auch sehr darüber gefreut, neben den vielen bekannten Gesichtern wieder mal ein paar neue Teilnehmer begrüßen zu dürfen. Ach ja - Premiere 2: Das Treffen fand das erste Mal bei Saxonia Systems statt und es war ein guter Einstand. Offenbar können Softwareentwickler aber mit Gemüse nicht allzu viel anfangen, denn obwohl die freundlicherweise gesponserten belegten Brötchen im wahrsten Sinne weggingen wie warme Semmeln, war die Gemüseplatte fast unberührt.

Mein Blog auf SQLServerBlogs.de

Ende letzten Jahres hatte Constantin die Idee, dass auch für die deutschsprachige SQL Server Community eine Plattform ähnlich den DotNetGermanBloggers gut und sinnvoll wäre. Und diese Idee unterstütze ich.

Dank der Verwendung von von O/R-Mappern verschwindet der direkte Datenbankzugriff inzwischen mehr und mehr in der klassischen .NET-Entwicklung. Trotzdem gibt es auch immer wieder Fälle, in denen das Was-passiert-da-eigentlich oder das Warum-geht-das-jetzt-nicht Probleme bereitet. Und genau dann ist es gut, wenn man auch im deutschsprachigen Raum Hilfe findet.

Deshalb: Ab sofort finden sich meine Blogposts zum Thema SQL Server auch auf SQLServerBlogs.de.

Verwaiste Logins in SQL-Server-Datenbanken neu zuordnen

In meinen Blogpost Verwaiste SQL-Logins auf einem SQL-Server ermitteln hab ich gezeigt, wie man mit Hilfe eines Skriptes ermitteln kann, welchen Logins gar keine Datenbanken mehr zugewiesen sind.

Aber das Thema der verwaisten Logins gibt es auch in umgekehrter Richtung: Jeder der bereits versucht hat, eine Datenbank von einem anderen Server wiederherzustellen und diese Datenbank verfügte über SQL-Benutzer, wird das Problem kennen: In der Datenbank gibt es unter dem Punkt Datenbank -> Security -> Users bereits mehrere Benutzer und diese sind unter Umständen auch mit Berechtigungen versehen, man möchte diese also nicht löschen. Die Benutzer existieren jedoch nicht als Logins unter Security -> Logins. Legt man dann gleichnamige Logins im SQL-Server an, so ist das auch noch recht unproblematisch - zumindest so lange bis man versucht, den neu angelegten Login auf der besagten Datenbank zuzulassen. Diesen Versuch quittiert der SQL-Server mit der Meldung, dass ein Benutzer mit diesem Namen in der Datenbank schon vorhanden ist - womit er ja grundsätzlich auch Recht hat.

 

Allerdings bedeutet das nicht, dass das eben neu angelegte Login aufgrund dieser Tatsache auch automatisch mit Zugriffsrechten auf der wiederhergestellten Datenbank ausgestattet ist.

Die Ursache liegt darin begründet, dass der SQL-Server den Benutzern intern eine SID zuweist. Die SID des Benutzers in der wiederhergestellten Datenbank und die SID des eben erstellten Logins unterscheiden sich.

Abhilfe schafft hier die Systemprozedur sp_change_users_login. Mit dem Parameter 'report' aufgerufen erhält man zunächst eine Auflistung aller Benutzer, die über keine Zuordnung zu Logins verfügen.

 

Nun steht also fest, dass es in der Datenbank fünf ungemappte Benutzer gibt. Mit Hilfe der gleichen Prozedur kann man nun auch gleich das Mapping vornehmen. Dazu übergibt man einfach als ersten Parameter 'update_one' und als zweiten bzw. dritten Parameter Benutzer und Login.

Prüft man nun die verwaisten Logins erneut, wird man feststellen, dass dieser Benutzer hier nicht mehr erscheint und versucht man ein Login auf der Datenbank, wird man merken, dass das nun funktioniert.

Remote Desktop Connection Manager

Wer oft mit vielen Remote-Desktop-Verbindungen arbeitet kennt das Problem: Für jede Verbindung wird eine eigene *.rdp-Datei angelegt und diese Dateien schwirren dann irgendwo auf dem System herum. Nun bin ich letzte Woche dank eines Tipps über ein sehr nützliches Tool gestolpert, das es seit etwa 10 Monaten gibt und das auch schon öfter in diversen Blogs vorgestellt wurde (z.B. auch im Code-Inside Blog) - der Remote Desktop Connection Manager.

Hier lassen sich mehrere Remote Desktop Connections zu Gruppen zusammenfassen. Diesen Gruppen kann man gemeinsame Einstellungen verpassen, so dass beispielsweise alle Verbindungen der gleichen Gruppe mit identischen Credentials geöffnet werden, die man dann nur in den Gruppeneigenschaften pflegen muss. Diese Vererbung beschränkt sich aber nicht nur auf Credentials, sondern auch auf andere Eigenschaften wie Bildschirmauflösung, Audioeinstellungen usw. Natürlich lassen sich die Einstellungen auch pro Verbindung einzeln konfigurieren.

Im Gegensatz zu den *.rdp-Dateien können hier innerhalb der Datenstruktur auch Credentials gespeichert werden, was ebenfalls ein Vorteil ist. Die Import-Schnittstelle aus Textdateien ist inzwischen als deprecated gekennzeichnet, aber *.rdg-Dateien sind relativ selbsterklärende XML-Strukturen. Ist das Kennwort verschlüsselt abgelegt, so lässt es sich auf einem anderen Rechner nicht entschlüsseln, was aber aus meiner Sicht auch nicht weiter schlimm ist. Wenn man dieses Tool wirklich braucht, so ist man vermutlich häufig mit Admin-Rechten auf irgendwelchen Rechnern unterwegs und dann wäre es fatal, wenn man durch einfaches Kopieren der *.rdg-Datei die vollen Berechtigungen hätte, ohne Kenntnis vom Kennwort zu haben. Wie es aussieht, kann man das umgehen, indem man das Kennwort im Klartext speichert und dann sollte es problemlos möglich sein, eine *.rdg-Datei auch an Kollegen zu geben.

Einladung zum Treffen der .NET Usergroup Dresden am 17.03.2011

Am 17.03.2011 wird das nächste Treffen der Usergroup stattfinden. Dieses Mal kommen wir so denke ich allen Teilnehmern von der Altstadt-Seite etwas entgegen, denn das Treffen findet bei Saxonia Systems statt und beginnt um 18:00 Uhr. Wie beim letzten Treffen mit großer Mehrheit beschlossen wurde, wollen wir dieses Mal ein Coding Dojo durchführen.

Damit alle einen groben Einblick haben, wohin die Reise geht, werde ich die Gelegenheit nutzen und zu Beginn anhand eines einfachen Beispiels die grundlegende Herangehensweise an testgetriebene Entwicklung erklären. Das Beispiel wird wohl jedem bekannt sein und daher können wir uns hier auf das Wie und nicht so sehr auf das Was konzentrieren. Im Anschluss daran werden wir zunächst eine einfache Kata gemeinsam durchführen und so das eben gelernte Vertiefen. Ich werde noch ein paar schwierigere Übungen mitbringen, so dass wir dann darunter eine aussuchen können, die wir bearbeiten.

Der Abend soll den Auftakt dazu geben, zukünftig ab und zu das ein oder andere Dojo durchzuführen. Wer sein eigenes Notebook mitbringen möchte, um selbst an der Lösung der Aufgaben zu arbeiten, ist herzlich dazu eingeladen. Das Dojo selbst wird an einem zentralen Notebook durchgeführt, so dass alle Beteiligten an den Gedanken von Driver und Copilote teilhaben können. Ich bin schon sehr gespannt auf diesen Abend.

Damit wir besser planen können, bitte ich alle potenziellen Teilnehmer um Eintragung in die Teilnehmerliste.