Blog | Holger Stehle

Wissen(schaft)spodcasts 👍 👎

In früheren Beiträgen hatte ich bereits ein paar Podcast-Empfehlungen ausgesprochen und auf mein Feedreader-Projekt hingewiesen, welches ebenfalls einige Podcasts aus verschiedenen Themenbereichen bereithält.

Mit diesem Beitrag möchte ich darüber hinaus gerne auf Wissenschaftspodcasts hinweisen. Diese Seite wurde von einigen Podcastern aus dem Bereich der Wissenschafts- und Wissensvermittlung ins Leben gerufen. Zu den Gründern gehören u. a. auch Nicolas Wöhrl von methodisch inkorrekt und Markus Völter von omega tau – beides Podcasts, die ich schon seit sehr langer Zeit verfolge und auch hier bereits beworben habe.

Die von den genannten und weiteren Personen eröffnete Seite bietet nun eine Sammlung verschiedenster Podcasts aus den Bereichen Wissen und Wissenschaft. Das Themenspektrum ist breit abgedeckt und reicht von Archäologie, Geschichte und Technik über Astronomie, Forschung im Allgemeinen und Speziellen bis hin zu Mathematik und Naturwissenschaften. Ich gehe also davon aus, dass für (fast) alle meiner – sicherlich hauptsächlich technisch interessierten – Besucher etwas dabei sein dürfte. Ihr könnt darüber hinaus auch neue Vorschläge einreichen.

Da mir die Vermittlung von Wissen und das Gespräch über wissenschaftliche Erkenntnisse persönlich äußerst wichtige Angelegenheiten sind, würde ich mich sehr freuen, wenn ihr etwas Passendes findet und die Seite(n) weiterempfehlt. Der Vollständigkeit wegen möchte ich abschließend noch kurz darauf hinweisen, dass ich mit den genannten Seiten in keiner weiteren Verbindung außer als Zuhörer einiger Podcasts stehe.

Hintergrundaufgaben unter ASP.NET ausführen 👍 👎

Im Vergleich zu manch anderen Laufzeitumgebungen für Web-Anwendungen ist es bei ASP.NET auch hier recht einfach, Aufgaben im Hintergrund (beispielsweise über separate Threads) auszuführen. Obwohl das grundsätzlich jederzeit sehr einfach – abgesehen von den inhärenten Schwierigkeiten, die Nebenläufigkeit mit sich bringen kann – möglich ist, ist das einfache Vorgehen, wie man es aus dem Desktop-Bereich kennt, fehleranfällig.

Im einfachsten Fall würde man asynchron per Task.Run(…) (als mit häufig genutzten Standardwerten vorbelegte Abkürzung für Task.Factory.StartNew(…)) zur Verwendung des Standard-Thread-Pools oder manuell per Thread-Klasse arbeiten. Dies ist jedoch insofern problematisch, als dass die ASP.NET-Anwendungsdomäne davon nicht benachrichtigt wird und daher beispielsweise einerseits auf die Beendigung des Vorgangs nicht gewartet und andererseits auf das Herunterfahren des Arbeitsprozesses nicht reagiert werden kann.

Bereits seit längerer Zeit werden daher u. a. die beiden Methoden RegisterObject und UnregisterObject der HostingEnvironment-Klasse zur Verfügung gestellt, deren Verwendung jedoch etwas umständlich ist und auf Grund neuerer Möglichkeiten, die gleich im Anschluss vorgestellt werden, an dieser Stelle nicht weiter ausgeführt werden soll. Wir verwenden stattdessen die seit .NET 4.5.2 verfügbare QueueBackgroundWorkItem-Methode:

Hintergrundaufgabe hinzufügen

HostingEnvironment.QueueBackgroundWorkItem(cT => {    /* Implementierung der Aufgabe */});

Etwas ungeschickt ist es jedoch, wenn dies beispielsweise in einem separaten Projekt ausgelagert werden soll, um jeweils von einer Desktop- und Web-Anwendung darauf zuzugreifen – außerhalb der ASP.NET-Laufzeitumgebung ist die Verwendung dieser Methode nämlich nicht möglich. Daher stellen wir für diesen Fall eine Alternative zur Verfügung, um zumindest ähnliches Verhalten für alle Anwendungsfälle zur Verfügung zu stellen:

Hilfsmethode (inkl. Fallback) implementieren

010203040506070809101112

public static class TaskUtility {    public static void DoBackgroundWork(        Action<CancellationToken> action,        CancellationToken cancellationToken = default(CancellationToken)    ) {        if(HostingEnvironment.IsHosted) {            HostingEnvironment.QueueBackgroundWorkItem(action);        } else {            Task.Run(() => action(cancellationToken), cancellationToken);        }    }}

Hilfsmethode verwenden

TaskUtility.DoBackgroundWork(cT => {    /* Implementierung der Aufgabe */});

Alternativ wäre es natürlich auch möglich, nur die eigentliche Aufgabe auszulagern und dann anwendungsspezifisch zu starten. Weiterführende Informationen zur Verwendung des CancellationToken stellt das MSDN insbesondere über die Struktur CancellationToken und die Klasse CancellationTokenSource zur Verfügung.

ZIP-Archive mit C# (ent-)packen 👍 👎

In einem früheren Beitrag zur (De-)Kompression mit C# hatte ich bereits einen Beitrag zu ZIP-Archiven in Aussicht gestellt. Diese sind praktisch, um Dateien und Verzeichnisstrukturen komprimiert und zusammenhängend speichern und austauschen zu können und werden außerdem auf praktisch jeder Plattform unterstützt. Daher möchte ich mit diesem Beitrag zeigen, wie sich mit C# entsprechende Archive automatisch erstellen lassen.

Das .NET-Framework liefert im Namensraum System.IO.Compression grundlegende Funktionalität zur Arbeit mit entsprechenden Archiven, auf die wir in diesem Beitrag setzen werden. Darüber hinaus gibt es jedoch eine Vielzahl weiterer Implementierungen (z. B. DotNetZip oder SharpZipLib), welche beispielsweise die Erstellung von passwortgeschützten Archiven ermöglichen und weitere Konfigurationsmöglichkeiten bieten.

Zuerst möchte ich ein paar Möglichkeiten aufzeigen, um ZIP-Archive zu erstellen:

Archiv aus bestehendem Verzeichnis erstellen

ZipFile.CreateFromDirectory("data", "data.zip");

Archiv aus bestehenden Dateien erstellen

010203040506

using(FileStream fileStream = File.OpenWrite("data.zip")) {    using(ZipArchive zipArchive = new ZipArchive(fileStream, ZipArchiveMode.Create)) {        zipArchive.CreateEntryFromFile("data/a.txt", "a.txt");        zipArchive.CreateEntryFromFile("data/b.txt", "b.txt");    }}

Archiv manuell zusammenstellen

010203040506070809

using(FileStream fileStream = File.OpenWrite("data.zip")) {    using(ZipArchive zipArchive = new ZipArchive(fileStream, ZipArchiveMode.Create)) {        ZipArchiveEntry zipArchiveEntry = zipArchive.CreateEntry("README");
        using(StreamWriter streamWriter = new StreamWriter(zipArchiveEntry.Open())) {            streamWriter.Write("Hallo Welt!");        }    }}

Abschließend möchten wir auf bestehende Archive zugreifen:

Archiv vollständig entpacken

ZipFile.ExtractToDirectory("data.zip", "data");

Archiv einlesen und verarbeiten

01020304050607080910111213141516

using(FileStream fileStream = File.OpenRead("data.zip")) {    using(ZipArchive zipArchive = new ZipArchive(fileStream, ZipArchiveMode.Read)) {        foreach(ZipArchiveEntry zipArchiveEntry in zipArchive.Entries) {              // "README" separat berücksichtigen            if(zipArchiveEntry.Name == "README") {                using(StreamReader streamReader = new StreamReader(zipArchiveEntry.Open())) {                      // Inhalt einlesen und auf Konsole ausgeben                    Console.WriteLine(streamReader.ReadToEnd());                }            } else {                  // Eintrag als Datei speichern                zipArchiveEntry.ExtractToFile(zipArchiveEntry.Name);            }        }    }}

Sehr viel mehr Möglichkeiten stehen leider tatsächlich nicht zur Verfügung; für weitergehende Einstellungen gibt es jedoch beispielsweise die bereits erwähnten externen Bibliotheken. Durch die Verwendung von Datenströmen besteht aber grundsätzlich die Möglichkeit, nahezu beliebige Quellen (und Ziele) für Archiv-Einträge heranzuziehen.

Versionierung (Ergänzung: Alpha und Beta) 👍 👎

Ergänzend zu meinem älteren Beitrag zur Versionierung erreichte mich die Frage, wie ich es mit Alpha- und Beta-Versionen (und ggf. weiteren Unterscheidungen) bei den Entwicklungsstadien von Anwendungen halte.

Sofern ich unfertige (Haupt-)Versionen vorab veröffentliche, verwende ich lediglich die beiden bereits genannten Merkmale. Mit separaten Freigabekandidaten arbeite ich üblicherweise nicht und unterscheide wie folgt:

Alpha: 1, 2, …
Dieses Merkmal bedeutet für die Version ein weitestgehend vollständig lauffähiges Programm, von dem es mir sinnvoll erscheint, dass es von vielen Personen getestet wird. Bei diesem Stand steht die wichtigste Funktionalität bereits zur Verfügung; es kann jedoch zu Erweiterungen der Funktionalität kommen, sofern diese von einer gewissen Anzahl der Anwender und mir selbst als sinnvoll erachtet wird und keiner einschneidenden Änderungen bedarf. Fehler können hin und wieder in seltenen Situationen auftreten.
Beta: 1, 2, …
Dieses Merkmal bedeutet für die aktuelle Version grundsätzlich das Ende funktionaler Erweiterungen. Die Anwendung läuft in den meisten Situationen möglichst fehlerfrei, sodass bereits von einer weitestgehend stabilen Anwendung zu sprechen ist. Durch die weiteren Rückmeldungen sollen nun beispielsweise noch Details der Oberfläche verbessert, Performanzoptimierungen durchgeführt und ggf. verbliebene Probleme sehr spezieller Anwendungsfälle korrigiert werden.

In allen Fällen ist mir jedoch wichtig darauf hinzuweisen, dass weder Alpha- noch Beta-Versionen aus meiner Sicht für einen sinnvollen Einsatz unbedarfter Anwender gedacht sind, sondern explizit für Experten zur Verfügung gestellt werden, die mit auftretenden Problemen professionell umzugehen wissen, um wertvolle Rückmeldung zur Entwicklung geben zu können (und nicht etwa Frust zu erzeugen). Natürlich dürfen gerne auch weniger versierte Benutzer Rückmeldungen – beispielsweise zur Benutzerführung – geben.

Ich bin also durchaus dafür, potentielle Anwender in den Entwicklungsprozess einzubeziehen, halte aber nicht viel davon, Kunden als Qualitätssicherung zu missbrauchen. Das konkrete Vorgehen kann sich natürlich bei einzelnen Projekten unterscheiden. Web-Anwendungen, die ich selbst pflege und kein Benutzer ernsthaften Schaden befürchten muss, gebe ich sehr gerne etwas früher frei (ganz zu Beginn beispielsweise auch nur für Bekannte), als Anwendungen, die der Benutzer auf eigenen Systemen einrichten und ggf. pflegen muss.

Kontakt für Domain-Missbrauch mit C# von abuse.net ermitteln 👍 👎

In meinem vorherigen Beitrag habe ich bereits ein paar allgemeine Gedanken und Lösungsansätze zum – leidigen – Thema Spam niedergeschrieben. In diesem Beitrag soll es, wie bereits angekündigt, darum gehen, den bereits kurz beschriebenen Dienst von abuse.net automatisiert (mit C#) anzusprechen.

Der Anbieter stellt alle wesentlichen Informationen zur Umsetzung zur Verfügung. Dort wird der Zugriff per DNS oder Whois beschrieben. Das Herunterladen der (Roh-)Daten ist jedoch nicht möglich. Beachtet bitte außerdem die Nutzungsbedingungen, so ist der kommerzielle Einsatz beispielsweise nicht ohne Weiteres gestattet.

Es werden bei den folgenden beispielhaften Implementierungen lediglich die ermittelten eMail-Adressen an sich zurückgeliefert und keine – ebenfalls verfügbaren – Kommentare, welche insbesondere Angaben zur Quelle enthalten. Des Weiteren findet keine Reduzierung von Duplikaten statt. Beides kann bei Bedarf aber selbstverständlich noch angepasst bzw. ergänzt werden. Die Methoden sind darüber hinaus variadisch und können daher mit mehreren Argumenten (oder einem Feld) aufgerufen werden.

Zugriff per Whois

Eine – auch mit .NET-Bordmitteln – sehr einfache Möglichkeit der Abfrage des für Missbrauch zuständigen Kontakts zu einer Domain ist das Whois-Protokoll. Die Abfrage erfolgt per TCP bei whois.abuse.net:43.

Zugriff per Whois

01020304050607080910111213141516171819202122

public static IEnumerable<string> GetAbuseContactList(params string[] domainList) {    using(TcpClient client = new TcpClient("whois.abuse.net", 43)) {        using(NetworkStream stream = client.GetStream()) {            byte[] request = Encoding.UTF8.GetBytes(String.Join(" ", domainList) + "\r\n");            stream.Write(request, 0, request.Length);
            using(StreamReader streamReader = new StreamReader(stream)) {                while(!streamReader.EndOfStream) {                    string response = streamReader.ReadLine();
                    if(response.Contains("(")) {                        response = response.Substring(0, response.IndexOf('('));                    }
                    if(!String.IsNullOrWhiteSpace(response)) {                        yield return response.Trim();                    }                }            }        }    }}

Es sei jedoch darauf hingewiesen, dass diese Methode vom Anbieter nicht (mehr) empfohlen und möglicherweise eingestellt wird. Darüber hinaus ist das Abfragen im Vergleich zu DNS um den Faktor 2-3 langsamer.

Zugriff per DNS

Eine sehr effiziente Möglichkeit der Abfrage stellt das DNS durch Auflösung des Bezeichners {domain}.contacts.abuse.net dar; die Rückgabe der Adressen erfolgt in Form von TXT-Records.

Leider stellt das .NET-Framework jedoch nur einfache Aufgaben der Adress- und Namensauflösung per DNS-Klasse zur Verfügung. Da die Details der Kommunikation – zumindest in diesem Beitrag – nicht weiter vertieft werden sollen, greifen wir auf eine externe Laufzeitbibliothek zu, die wir mit NuGet bequem per Visual Studio beziehen können. Für das folgende Beispiel verwende ich ARSoft.Tools.Net, welche sich bereits in einigen meiner Entwicklungen im Produktiveinsatz bewährt hat und zudem auch relativ einfach zu verwenden ist.

Zugriff per DNS

010203040506070809101112

public static IEnumerable<string> GetAbuseContactList(params string[] domainList) {    foreach(string domain in domainList) {        DnsMessage response = DnsClient.Default.Resolve(            DomainName.Parse(domain + ".contacts.abuse.net"),            RecordType.Txt        );
        foreach(TxtRecord record in response.AnswerRecords) {            yield return record.TextData;        }    }}

Unabhängig davon, welche der beiden Methoden ihr verwendet, gestaltet sich die Verwendung sehr einfach:

Verwendung der Methode(n)

0102030405060708

  // ["abuse@coders-online.net"]IEnumerable<string> abuseContactList = GetAbuseContactList("coders-online.net");
  // ["abuse@google.com", "abuse@microsoft.de"]abuseContactList = GetAbuseContactList("google.com", "microsoft.de");
  // ["abuse@facebook.com", "spamreport@spamreport.facebook.com"]abuseContactList = GetAbuseContactList("facebook.com");

Auf eine angemessene Fehlerbehandlung habe ich wie üblich zur besseren Verdeutlichung des eigentlichen Anliegens verzichtet, sollte von euch bei der Verwendung aber nicht vernachlässigt werden.