Da es in der Community Diskussionen um die Komplexität der Default Templates von ASP.NET MVC gab, haben einige Leute um Jeffrey Palermo, u.a. Autor von ASP.NET MVC in Action, unter http://mvcforasp.net schlankere Templates veröffentlicht.

Gründe für die Migration von Berkeley DB (BDB) basierten Repositories in FSFS Repositories gibt es viele - einer ist, dass ein Subversion-Repository nicht mehr unter Apache sondern unter SVNServe betrieben werden soll.

Möchte man nun auf das Repository zugreifen, erhält man die Fehlermeldung

Der Grund hierfür ist, dass SVNServe wie auch VisualSVN Server BDB nicht unterstützen. Die Migration erfolgt prinzipiell, indem das BDB-Repository mittels

zunächst in eine Datei exportiert wird und danach mittels

in ein neues FSFS-basiertes Repository importiert wird.

Die Migration wird allerdings dadurch erschwert, dass für die Erstellung des dump-Files eine Subversion-Version benötigt wird, die das gleiche BDB-Schema besitzt, wie die Version, mit der das Repository erstellt wurde.

Andernfalls erhält man Fehlermeldungen wie diese:

Falls man die ehemals verwendete Subversion-Version nicht mehr besitzt, kann man im Subversion Windows Archive die benötigte Version herunterladen.

Diese sollte man in einen eigenen Ordner installieren, der nicht dem Pfad der aktuellen Installation entspricht.

In der Kommandozeile sollte man nun die PATH-Variable so anpassen, dass sie auf den Installationspfad der Subversion-Version für die BDB-Repositories zeigt.

Danach kann man mit

das Repository exportieren.

Nun ändert man in der Kommandozeile die PATH-Variable wieder auf den Eintrag der aktuellen Subversion-Version und führt

aus.

Hiermit ist die Konvertierung abgeschlossen.

Aufgrund technischer Probleme musste das heutige ALT.NET DE Online Meeting leider abgebrochen werden.

Neuer Termin ist Montag, 02.03.2009, also heute in einer Woche, ebenfalls um 20:00 Uhr.

Weitere Infos dazu auf der ALT.NET DE Online Meeting Seite.

Meine Statistiken gehören mir

Heutzutage ist es gängige Praxis, Google Analytics für die kostenlose Erzeugung aussagekräftiger Website-Statistiken zu verwenden.

Eine ebenfalls kostenlose Alternative, die bereits seit vielen Jahren verfügbar ist, ist AwStats.

Die Installation in Verbindung mit IIS6 hat Christoph Wille hier gezeigt (Glengamoi-Registrierung notwendig) – dieser Beitrag ist daran angelehnt.

Inzwischen ist IIS7 stand der Technik und auch dort lässt sich AwStats verwenden - wie, das zeigt die folgende Anleitung.

Download first

Bevor AwStats verwendet werden kann, muss es bei SourceForge.NET heruntergeladen werden.

Da zur Ausführung von AwStats Perl benötigt wird, muss außerdem auch ein Perl-Interpreter installiert werden.

Auch hier gibt es kostenlose Varianten – zum Einsatz kommt in diesem Fall ActivePerl von ActiveState.

Installation

Nach der Installation von ActivePerl befindet sich selbiges in

Die “Installation” von AwStats besteht darin, dass das entsprechende ZIP-File (in diesem Fall die awstats-6.8.zip) in einen Ordner entpackt wird, unter dem später auch das Root für die Statistik-Website liegt, in meinem Fall

Danach sollten folgende Ordner und Dateien existieren:

In docs befindet sich erwartungsgemäßg die Dokumentation von AwStats, in tools die Perl-, xml- und xslt-Dateien und in wwwroot das bereits erwähnte Root für die Statistik-Website.

IIS-Konfiguration – der erste Streich

Die Grundlage für die Generierung von Website-Statistiken mit AwStats sind die Logfiles des IIS. Allerdings können die vom IIS per default erzeugten Logfiles nicht von AwStats gelesen werden, da diese andere Felder beinhalten als von AwStats erwartet wird.

Um die Logfiles des IIS so zu erzeugen, dass sie von AwStats geparsed werden können, sind deshalb in den Logging-Einstellungen der entsprechenden Website einige Feld-Anpassungen nötig:

IIS-Konfiguration – der zweite folgt sogleich

Im nächsten Schritt legen wir die Website stats.sharperp.net im IIS-Manager an:

Der physikalische Pfad zeigt auf

Dies ist der Pfad, in dem sich das wwwroot-Verzeichnis von AwStats befindet.

Verwendet man die x64-Variante von Windows Server 2008, muss der Application-Pool der Statistik-Website außerdem so konfiguriert werden, dass auch 32-Bit Applikationen ausgeführt werden (ActiveState Perl läuft nur als 32-Bit Applikation):

Damit Perl nun am IIS7 ausgeführt wird, müssen zwei Script Maps erstellt werden.

Dies geschieht im Bereich Handler Mappings für die Websites, indem man auf “Add Script Map” klickt und folgende Daten eingibt:

Die nachfolgende ISAPI-Meldung bestätigen wir mit “yes”:

Das gleiche führen wir nun noch für die CGI Script Map durch:

Auch hier wird die ISAPI-Meldung bestätigt:

Danach muss der IIS (=World Wide Web Publishing Service)  neu gestartet werden.

AwStats-Konfiguration

Nachdem der IIS nun bereit ist,  AwStats auszuführen, müssen wir dieses zunächst konfigurieren.

Im Ordner

liegt die Datei

Hierbei handelt es sich um eine Vorlage für AwStats-Website-Konfigurationen.

Um die Datei für eine eigene Website zu verwenden, muss diese kopiert werden und “model” durch den Namen der Website ersetzt werden, für die eine Statistik erstellt werden soll, also z.B.

Im nächsten Schritt muss die Datei editiert und mindestens folgende Anpassungen vorgenommen werden:

LogFile="/var/log/httpd/mylog.log"

muss ersetzt werden durch den Pfad zu den Logfiles:

LogFile="D:\LogFiles\W3SVC8\u_ex%YY-24%MM-24%DD-24.log"

Danach wird

LogFormat=1

geändert in

LogFormat=2

Außerdem muss

SiteDomain=""

durch

SiteDomain="sharperp.net"

ersetzt werden.

Die nächste Änderung ist besonders wichtig, da sie auch sicherheitsrelevant ist.

DirData="."

muss ersetzt werden durch

DirData="D:\Websites\SharpERP.NET\stats.sharperp.net\DataDir"

Die Sicherheitsrelevanz liegt darin, dass “.” das Verzeichnis darstellt, in dem die .conf-Datei liegt, also cgi-bin.

Dieses ist von außen logischerweise erreichbar, d.h. jemand, der den Aufbau von AwStats kennt, kann die von AwStats aufbereiteten Statistiken herunterladen.

Die o.g. Änderung verhindert dies, da das DataDir nun außerhalb der Reichweite von Web Usern liegt.

Damit sind die notwendigen Anpassungen an der Konfiguration erledigt und die awstats.sharperp.net.conf kann gespeichert werden.

Ruf. Mich. Auf.

Damit nun die Statistiken aus den Logfiles des IIS 7 generiert werden, müssen wir die Datei

im Verzeichnis

mit den entsprechenden Parametern ausführen.

Da dies immer geschehen muss, wenn wir die Statistiken aktualisieren wollen, erstellen wir uns hierfür ein Batchfile, das wir einfach aufrufen können – ebenfalls im soeben genannten Ordner, z.B.

Der Inhalt der Datei ist folgender:

D:\Websites\SharpERP.NET\stats.sharperp.net\tools\awstats_updateall.pl now -awstatsprog="D:\Websites\SharpERP.NET\stats.sharperp.net\wwwroot\cgi-bin\awstats.pl" -configdir="D:\Websites\SharpERP.NET\stats.sharperp.net\wwwroot\cgi-bin" update

Somit wird also die awstats_updateall.pl sofort (now) ausgeführt und das enstprechende awstats + config verwendet und die Statistiken aktualisiert.

Wenn wir unser Batchfile nun speichern und ausführen, sollten wir ein Resultat ähnlich dem hier gezeigten erhalten:

Wenn wir nun die Statistikseite im Browser mit der Url

http://stats.sharperp.net/cgi-bin/awstats.pl?config=sharperp.net

aufrufen, erhalten wir das folgende Resultat:

Somit haben wir für das Logfile des vorangegangenen Tages eine Statistik erzeugt.

Und täglich grüsst das Murmeltier

Damit die Statistiken nun täglich automatisch aktualisiert werden, muss der Aufruf von

über einen Scheduled Task einmal täglich ausgeführt werden (es empfiehlt sich, dies Nachts z.B. um 3:30 zu tun).

Altlasten aufarbeiten

Will man alte Logfiles nachträglich in die Statistik aufnehmen, so kann man dies mit folgendem Kommando:

Dieses Kommando parst ein altes LogFile vom 17.09.2008 nach und fügt es in die Statistik mit ein.

Voraussetzung ist natürlich, dass das Format des Logfiles passt.

Das wars – sicher?

Zum Schluss noch ein Hinweis bezgl. Sicherheit: Will man vermeiden, dass die Statistiken von Dritten eingesehen werden, sollte man die Seite z.B. per Windows Authentication absichern.

Denn ein kurzer Klick auf einen der Referrer in den Statistiken liefert diesem einen gezielten Hinweis die Adresse der Statistik-Website.

Am 23.02.2009 findet um 20:00 Uhr das 4. ALT.NET DE Online Meeting statt.

Thema

Test Driven Development & Behavior Driven Development

Details

Wie können wir Code schreiben, der möglichst fehlerfrei, robust, und leicht änderbar ist und es auch bleibt? Wie implementieren wir nur wirklich benötigte Funktionalität und sind von allem Anfang an auf zu erwartende Änderungswünsche des Kunden vorbereitet? Die Antwort auf diese Fragen lautet Test-getriebene Entwicklung (TDD).

Wie erreichen wir, dass Entwickler und Fachexperten oder allgemein Stakeholder dieselbe Sprache sprechen? Behavior driven development (BDD) liefert uns eine mögliche Antwort darauf.

Über den Sprecher

Gabriel Schenker ist Softwareentwickler, Blogger bei Los Techies und Betreiber des NHibernate FAQ Blogs.

Teilnahme

Teilnehmen kann jeder, der sich für das Thema interessiert.

Die Registierung erfolgt auf der ALT.NET DE Website für das Online-Meeting.

Um zu gewährleisten, dass wir pünktlich starten können, kann die LiveMeeting-Installation hier vorher getestet werden.

Die Lobby ist ab 19:45 Uhr geöffnet.

Auch wenn ca. 90% der Zugriffe auf http://blogs.dotnetgerman.com via RSS erfolgen, habe ich drei CSS-Klassen eingerichtet, die häufig verwendete Elemente in Blogpostings auf http://blogs.dotnetgerman.com einheitlich formatiert darstellt.

Hierbei handelt es sich um folgende CSS-Klassen:

• .error
• .commandline
• .quote

Die Darstellung ist folgende:

.error:

.commandline

.quote

Alles was, Blogger, deren Blog bei http://blogs.dotnetgerman.com gelistet ist, tun müssen, ist die Zuweisung der entsprechenden CSS-Klassen an die gewünchten Stellen im eigenen Blog. Lokal im jeweiligen Blog können die Klassen natürlich anders oder undefiniert sein.

Außerdem ist bereits seit längerem der SyntaxHighlighter von Alex Gorbatchev integriert, so dass auch Code-Schnipsel einheitlich und optisch ansprechend formatiert dargestellt werden können:

Wenn man z.B. das Logfile-Verzeichnis einer Website unter IIS7 verschieben möchte, muss man wissen, welche ID die Website hat, da das Logfile in der Form W3SVC<SiteID> vorliegt, also z.B. W3SVC25.

Unter IIS6 konnte man dies in den Protokollierungseigenschaften direkt anzeigen lassen:

Beim IIS7 ist dies leider nicht mehr der Fall:

Um nun dennoch an den Namen des Logfile-Verzeichnisses zu kommen, muss man die Informationen mit einem WMI-Script abfragen:

Set oIIS = GetObject("winmgmts:root\WebAdministration")
Set oSite = oIIS.Get("Site.Name='blog.alexonasp.net'")
WScript.Echo "Retrieved an instance of Site "
WScript.Echo "Name: " & oSite.Name
WScript.Echo "ID:   " & oSite.ID

Nach dem Start des Scripts erhält man folgende Ausgabe:

Der Name des Logfle-Verzeichnisses ist somit

Danke, Thomas

Ein Wertesystem für Softwareentwickler

Dass Ralf Westphal und Stefan Lieser zum Jahreswechsel die Initiative Clean Code Developer (CCD) gestartet haben, war bereits Gegenstand mehrerer Blogposts, z.B. hier, hier und hier.

Außerdem hat Ralf Clean Code Developer ausführlich in der DotNetPro vorgestellt und bereits am 09.02.2009 fand ein ALT.NET DE Online Meeting statt, in dem Ralf und Stefan Fragen rund um das Thema CCD ausführlich beantwortet haben.

CCD-Werte immer dabei

Ich war von der Idee von Clean Code Developer sofort begeistert, da es mir als Softwareentwickler die Möglichkeit gibt, mit handfesten Fakten meinen Code auf Mängel hinsichtlich Korrektheit, Evolvierbarkeit, Produktionseffizienz und Reflexion zu durchsuchen und diese zu korrigieren.

Was mich allerdings etwas störte, war die Tatsache, dass ich gerade zu Beginn eines Grades die Werte (Prinzipien/Werte/Praktiken) immer wieder auf der Website nachlesen musste.

Nach einigen Überlegungen entstand die Idee, die CCD-Werte als Add-In für Visual Studio bereitzustellen, so dass diese jederzeit in der IDE sichtbar und somit allgegenwärtig sind.

Das Resultat ist das CcdAddIn, das hier heruntergeladen werden kann und sich in Visual Studio wie hier zu sehen, integriert:

Für die nächsten Releases ist geplant, das Add-In so zu erweitern, dass die tägliche Reflexion mit dem Add-In erledigt werden kann.

Weitere Ideen können gerne hier diskutiert werden.

Fehler können hier gemeldet werden.

Wenn man den SyntaxHighlighter von Alex Gorbatchev mit BlogEngine.NET verwenden möchte, sind einige Anpassungen nötig:

Der einfachste Weg, den SyntaxHighlighter in BlogEngine.NET zu integrieren, ist, die SyntaxHighlighter Extension von Chris Blankenship gemäß Anleitung zu installieren.

Danach muss noch die Konfiguration von BlogEngine.NET, genauer von Tiny_MCE, dem Editor, der bei BlogEngine.NET zum Einsatz kommt, angepasst werden.

Zunächst muss im admin-Verzeichnis die tinyMCE.ascx angepasst werden:

Die Zeile

<script src="/admin/Pages/<%=Utils.RelativeWebRoot%>/editors/tiny_mce/tiny_mce.js" type="text/javascript">

muss geändert werden in

<script src="/admin/Pages/<%=Utils.RelativeWebRoot%>/editors/tiny_mce/tiny_mce_src.js" type="text/javascript">

In der Datei editors\tiny_mce\tiny_mce_src.js muss nun der Eintrag

pre[class|align|style]

in

pre[class|align|style|name]

geändert werden.

Außerdem muss die Zeile

h = h.replace(new RegExp('\\n\\s+', 'gi'), '\n'); // Remove previous formatting

auskommentiert oder gelöscht werden:

// h = h.replace(new RegExp('\\n\\s+', 'gi'), '\n'); // Remove previous formatting