Suche: ARIA

Quartal mit C# ermitteln 👍 👎

Leider bietet die DateTime-Struktur standardmäßig keine eingebaute Funktionalität zur Ermittlung des Quartals einer Instanz. Wir werden diese daher als praktische Erweiterungsmethode ergänzen:
Erweiterungsmethode implementieren
0102030405
public static class DateTimeExtensions {    public static int GetQuarter(this DateTime dateTime) {        return ((dateTime.Month + 2) / 3);    }}
Durch die vorherige Addition von 2 wird die (ganzzahlige) Teilbarkeit bei richtigem Ergebnis sichergestellt. Indem die Teilung variabel gestaltet wird, beispielsweise mit Hilfe eines zu übergebenden Aufzählungswertes mit passenden ganzzahligen Werten, können auch andere Jahresteile (z. B. Halbjahre) sehr einfach ermittelt werden:
Erweiterungsmethode implementieren (erweitert)
010203040506070809101112
public static class DateTimeExtensions {    public static int GetYearDivisionPart(this DateTime dateTime, YearDivision yearDivision) {        int monthsPerDivision = (int) yearDivision;
return ((dateTime.Month + (monthsPerDivision – 1)) / monthsPerDivision); }
public enum YearDivision { Half = 6, Quarter = (Half / 2) }}
Die Verwendung gestaltet sich in beiden Fällen naheliegend einfach:
Erweiterungsmethode verwenden
0102030405
DateTime birthday = new DateTime(1988, 1, 29);
int quarter = birthday.GetQuarter(); // 1 /* bzw. */quarter = birthday.GetYearDivisionPart(YearDivision.Quarter); // 1

CCC-Fahrplan 👍 👎

Pünktlich zum aktuellen Chaos Communication Congress des CCC möchte ich ein kleines Projekt vorstellen.

Meine Variante des CCC-Fahrplans greift auf die XML- und JSON-Dateien des offiziellen Zeitplans zurück, stellt dadurch alle Veranstaltungen (seit 2006) und Sprecher (seit 2013) einheitlich dar und enthält einige Querverweise. Darüber hinaus ermöglichen die Flaggen eine besonders schnelle Sprachzuordnung direkt auf der Startseite.

Zur Schonung der Infrastruktur des CCC werden die Daten zwischengespeichert, sodass die angezeigten Informationen u. U. veraltet sein können. Bitte informiere dich für verbindliche Informationen direkt beim CCC.

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.

Bezeichner eines Members mit C# ermitteln 👍 👎

Bei C# kommt man beispielsweise bei der Fehlerbehandlung (z. B. per ArgumentException und abgeleiteten Klassen), Logging (im Sinne von "Methode MethodName betreten/verlassen") oder auch beim Routing im Rahmen des ASP.NET MVC-Frameworks in die Notwendigkeit, Programmbezeichner als Zeichenketten anzugeben.

Etwas ärgerlich ist hier jedoch immer, was man bei grundsätzlich statisch typisierten Sprachen wie C# für gewöhnlich vermeiden möchte: Derartige Zeichenketten sind literal hinterlegt und dementsprechend einer Refaktorierung nicht ohne Weiteres zugänglich. Dieses Problem löst nun das relativ neue Konstrukt nameof, indem es die (einfachen) Bezeichner von Variablen, Typen und Membern als Zeichenkette liefert:
Beispiel-Klasse definieren und Member-Bezeichner ermitteln
01020304050607080910111213141516171819202122
public class Person {    public string FirstName {        get;        set;    }
public string LastName { get; set; }

public void Marry(Person person) { /* … */ }}

Debug.WriteLine(nameof(Person)); // "Person"Debug.WriteLine(nameof(Person.FirstName)); // "FirstName"Debug.WriteLine(nameof(Person.LastName)); // "LastName"Debug.WriteLine(nameof(Person.Marry)); // "Marry"
Praktisch ist nun, dass bei der Umbenennung einer Eigenschaft oder Methode, sich dieser Vorgang auch auf die entsprechende Verwendung innerhalb von nameof auswirkt und somit für Konsistenz sorgt.

Ein weiterer theoretischer Anwendungsfall ergibt sich im Rahmen einer INotifyPropertyChanged-Implementierung, jedoch lässt sich dieses Problem auch ganz ohne manuelle Angabe per CallerMemberName-Attribut lösen, wie ich in einem früheren Beitrag bereits beschrieben habe.

Typisierung 👍 👎

Ein "beliebtes" (Streit-)Thema in der Softwareentwicklung sind die verschiedenen Typsysteme von Programmiersprachen. Grundsätzlich dienen diese hauptsächlich dazu, den Wertebereich von Variablen sinnvoll einzuschränken – idealerweise, um mögliche Fehler zu vermeiden. Vorteilhaft ist meist auch eine deutlich umfassendere Hilfestellung der Entwicklungsumgebung.

Nun gibt es verschiedene Möglichkeiten, ein solches System konkret zu implementieren. Dieser Beitrag soll explizit nicht dazu dienen, das eine System zu verteufeln und das jeweils andere hochzuloben. Dennoch haben die meisten Entwickler – so auch ich – eine gewisse Präferenz, sofern die Situation kein besonderes Vorgehen erfordert und man in der Wahl somit weitestgehend frei ist. Natürlich haben jeweils "beide Welten" ihre Vor- und Nachteile.

Dazu möchte ich einige Gegenüberstellungen mit Beispielen präsentieren, deren Definitionen jedoch nicht unbedingt als allgemeingültige Aussage zu verstehen sind, sondern vielmehr vom Kontext abhängig sein können:

Dynamisch vs. Statisch

Bei der statischen Typprüfung sind die Typen bereits zum Zeitpunkt der Entwicklung bekannt und werden entweder explizit vom Entwickler angegeben, oder aber implizit vom System abgeleitet (mehr dazu im nächsten Abschnitt). Bei der dynamischen Typprüfung findet die Prüfung der Typen erst zur Laufzeit statt.

  • Dynamisch: z. B. C++ (optional), C# (optional), JavaScript, Lua, PHP, Prolog, Python, Ruby, Scheme
    Beispiele in C# und PHP
    01020304050607
      // C#dynamic age = 27;              // zur Laufzeit als "int" erkanntdynamic firstName = "Holger";  // zur Laufzeit als "string" erkannt
    // PHP$age = 27; // zur Laufzeit als "int" erkannt$firstName = "Holger"; // zur Laufzeit als "string" erkannt
  • Statisch: z. B. Ada, C++ (standardmäßig), C# (standardmäßig), Haskell, Java
    Beispiele in C++ und C#
    01020304050607
      // C++int age = 27;                      // Ganzzahlstd::string firstName = "Holger";  // Zeichenkette
    // C#int age = 27; // Ganzzahlstring firstName = "Holger"; // Zeichenkette

Ich bevorzuge hier, sofern die Umstände nicht dagegen sprechen, die statische Typisierung. Für mich überwiegt hier der Vorteil der Typprüfung zur Entwicklungs- bzw. Kompilierzeit. Viele Fehler, die oftmals erst während der Laufzeit auffallen, können so effektiv vermieden werden. Durch Konzepte wie die generische Programmierung kann hier der notwendige Mehraufwand zwar deutlich reduziert werden, dennoch erfordert eine statische Typisierung in der Regel (minimal) mehr Aufwand bei der Entwicklung und kann mitunter umständliche Konstrukte bei sehr dynamischer Datenverarbeitung – beispielsweise im Web-Bereich – erforderlich machen; s. Dynamische Typisierung in C#.

Explizit vs. Implizit

Bei der expliziten Angabe der Typen trägt man als Entwickler Verantwortung dafür, den zum angedachten Inhalt einer Variablen (oder Rückgabe einer Methode) passenden Typen auszuwählen. Bei impliziter Ableitung erledigt dies das Typsystem, indem es den passenden Datentyp zum Inhalt annimmt.

  • Explizit: z. B. Ada, C++, C# (standardmäßig), Java
    Beispiele in C++ und C#
    01020304050607
      // C++int age = 27;                      // Ganzzahlstd::string firstName = "Holger";  // Zeichenkette
    // C#int age = 27; // Ganzzahlstring firstName = "Holger"; // Zeichenkette
  • Implizit: z. B. C# (optional), Haskell, JavaScript, Lua, Prolog, Python, Ruby, PHP, Scheme
    Beispiele in C# und PHP
    01020304050607
      // C#var age = 27;              // Ganzzahlvar firstName = "Holger";  // Zeichenkette
    // PHP$age = 27; // Ganzzahl$firstName = "Holger"; // Zeichenkette

Ich bevorzuge hier, sofern die Umstände nicht dagegen sprechen, die explizite Typangabe. Diese bedeutet üblicherweise zwar etwas mehr Schreibaufwand, erhöht aus meiner Sicht jedoch die Verständlichkeit des Quelltextes, da ich die Bezeichner von Variablen ungerne mit Präfixen oder Suffixen versehe, sondern mich bei der Benennung auf den Inhalt bzw. Zweck konzentrieren möchte. Um eine Kleinigkeit zu testen oder für ansonsten sehr umständliche Konstrukte (vgl. generische Programmierung) empfinde ich implizite Typableitung jedoch durchaus komfortabel. Teilweise kann dies sogar notwendig sein; s. Implizite Typisierung in C#.

Stark vs. Schwach

Dieser Aspekt behandelt im erweiterten Sinne die Typsicherheit des Typsystems. Stark typisierte Programmiersprachen erlauben für gewöhnlich – wenn überhaupt – nur implizite Typumwandlungen, sofern kein Datenverlust auftritt (beispielsweise von einem ganzzahligen Datentyp kleineren Wertebereiches zu einem mit größerem Wertebereich). Schwächer typisierte Programmiersprachen sind hier für gewöhnlich "großzügiger".

  • Stark: z. B. Ada, C++, C#, Haskell, Java, Python, Scheme
    Beispiele in C#
    01020304050607
    int pi = 3.14;    // Kompilierungsfehler!pi = (int) 3.14;  // 3
    int tmp = 27;
    if(tmp) { // Kompilierungsfehler! Debug.WriteLine("klappt!");}
  • Schwach: z. B. JavaScript, Lua, Prolog, Ruby, PHP
    Beispiel in PHP
    0102030405
    $tmp = 27;
    if($tmp) { // implizite Auswertung als "true" echo 'klappt!';} // Ausgabe von "klappt!", da Zahlen ungleich "0" als "true" ausgewertet werden

Ich bevorzuge hier, sofern die Umstände nicht dagegen sprechen, die starke Typisierung. Der Grund ist schlicht der, dass so weitestgehend sichergestellt ist, dass keine unerwarteten oder gar fehlerhaften Konvertierungen vom System vorgenommen werden – sofern ich dem nicht explizit zustimme, wozu die meisten Programmiersprachen entsprechende Typumwandlungen vorsehen. Auch hier ist jedoch zugegebenermaßen üblicherweise ein etwas höherer Aufwand notwendig, als bei eher schwächer typisierten Programmiersprachen.

Meine persönliche Präferenz statischer, expliziter und starker Typsysteme ist tatsächlich auch als eben solche zu verstehen. Ich erkenne durchaus den Vorteil eher "dynamischerer" Sprachen an und nutze diesen ebenfalls in einigen Projekten. Ich habe jedoch für mich festgestellt, mit o. g. Verhalten produktiver zu arbeiten und halte mich daher soweit sinnvoll an solche Sprachen. Insbesondere in C# – was wohl kaum eine Überraschung sein dürfte – finde ich hier eine sehr gute Kombination dieser Aspekte umgesetzt. Wem bisher nur die eine Seite geläufig ist, empfehle ich auf jeden Fall, sich auch einmal eine Sprache mit anderem Typsystem genauer anzusehen.

Insgesamt ist dies eine sehr grobe Einteilung, von der viele Programmiersprachen eine etwas differenziertere vornehmen und tlw. auch Kombinationen erlauben. Dennoch eignet sich dies durchaus für einen ersten Überblick der Möglichkeiten; einige Aspekte hängen auch bis zu einem gewissen Grad voneinander ab. Interessierte sollten sich definitiv beispielsweise einmal vom entsprechenden Wikipedia-Artikel ausgehend weiter informieren.

Projektverweise

Kategorien / Archiv  |  Übersicht RSS-Feed

Schlagworte

Suche