Blogging - here we go again!

Nach einer langen und sehr arbeitsintensiven Blogging-Pause möchte ich mich nun wieder vermehrt dem Bloggen widmen. Und möchte hier in kürze über einige Themen berichten die mich im Moment bewegen und beschäftigen:

• Domain Driven Design
• Clean Code (Developer)
• CAF
• Application Space

Ich freue mich darauf. Bis bald.

Mehr Paralellität mit PLINQ und TPL

Mit der nächsten Generation für die Parallelverarbeitung mit dem .NET Framework PFX unterstützt Microsoft den Trend der Paralellverarbeitung. Da aktuelle Prozessoren mit immer mehr Kernen ausgestattet sind muss, um die Performancevorteile mehrerer Prozessorkernen auszunutzen, mehr parallel verarbeitet werden.
Das .NET Framework hat das mit dem Threading-Model und dem ThreadPool schon angenehm einfach gemacht. Aber nicht einfach genug! Mehr Abstraktion muss her. Bestechende Ansätze Microsofts sind dabei PLINQ und die Task Paralell Library. So einfach war Paralellverarbeitung noch nie:

Ein kleines Beispiel eines ersten experiments mit der TPL:
Parallel.For(0, 100, delegate(int i) { a[i] = a[i]*a[i]; });

Das ist nicht nur unglaublich einfach, sondern auch noch schneller als mit der ThreadPool-Klasse. Die TPL optimiert und steuert die Arbeitthreads nämlich besser. Ein empfehlenswerter Artikel dazu ist Optimieren von verwaltetem Code für Mehrkerncomputer. Anschauen lohnt sich!

Gleiches gilt für PLINQ:

Abstraktion vom feinsten - PLINQ's AsParallel:
IEnumerable data = ...;var q = data.AsParallel().Where(x => p(x)).Orderby(x => k(x)).Select(x => f(x));foreach (var e in q) a(e);

So gehört sich paralelle Verarbeitung und die Zukunft gehört ihr. Und hier auch noch ein Artikel über das Ausführen von Abfragen auf Mehrkernprozessoren.

Anschauen lohnt sich auf jedenfall. Endlich kann ich mich auf die Problemlösung - die Logik - konzentrieren und muss mich nicht mit technischen Infrastukturdetails herumschlagen. Übrigens lohnt sich im Zusammenhang mit Multithreading auch einen Blick auf Ralfs NSTM Implementation.

Blog des PFX Teams: http://blogs.msdn.com/pfxteam/

Visual Studio 08 und .NET 2.0

Letzte Woche habe ich das Release von Visual Studio 2008 installiert.
Es war jetzt nicht super neu, da ich die Betas schon kannte. Trotzdem - irgendwie cool, die IDE hat definitiv nochmals einen Schritt nach vorne gemacht.
Neben den ganzen neuen Features in der CLR gefallen mir am neuen VS08 vorallem die neuen Compiler, welche es ermöglichen die neuen Sprachfeatures von C# und VB.NET auch für eine .NET 2.0 Anwendung zu verwenden.
D.h. ich kann:

• Auto-Implemented Properties
• Lambda Expresssions
• Collection Intializiers
• Object Initializers
• Anonymous Types
• Implicit Typed Variables
• Extension Methods
• Partial Methods
• Query Words

trotzdem verwenden! Das ist doch echt mal ein Fortschritt: Ein neues Visual Studio das mit alten Framework Versionen arbeitet und aber einen tollen neuen Compiler mitbringt. Wenn man jetzt die grossen technologischen Brocken wie WF,WPF und WCF aussen vor lässt kann man abgesehen von ein, zwei Dingen wie Suite-B Support, ADO.NET Entity Framework oder der neuen Klassen HashSet, ObservableCollection, Package, NamedPipe und dem Namespace System.AddIn viele Neuerungen auch unter .NET 2.0 verwenden. So soll es sein. Und achja - Unit Testing kann ich jetzt auch ohne zusätzliche Software betreiben.

Übrigens habe ich bis heute noch nicht herausgefunden wie ich in diesem Blog ein syntax highlight aktiviere - komisch das google das nicht von haus aus drin hat.

Den Briefkasten zuschweissen

Kürzlich überflog ein Kollege meinen Quelltext (es handelte sich um eine Implementierung die wir ziemlich eng zusammen ausgearbeitet haben).
"Was ist das denn?", er zeigte auf eine private Property.
Ein weiterer Bürobewohner eilte herbei um sich das Kunstwerk anzuschauen.
Nicht genug, dass sie private Properties nicht kannten, zogen sie anschliessend auch noch gemeinsam darüber her.
Das sei schlechter Stil, Properties seien Schnittstellenelemente und nicht für interne Zwecke, usw.

Ich bin da anderer Meinung - und verwende Properties auch gerne mal privat, internal oder protected. Nützlich ist das z.B. bei interner Lazy initialization:

Public Class frmEditor

Private m_CardSets As List(Of DataModel.CardSet)

Private Property CurrentCardSets() As List(Of DataModel.CardSet)
Get
If (Me.m_CardSets Is Nothing) Then
Me.m_CardSets = New List(Of DataModel.CardSet)
End If

Return Me.m_CardSets
End Get
End Property
End Class

Ist doch ganz nett oder? Lazy initialization krieg ich sonst nicht so schön - auch nicht mit einer Methode wie z.B. GetCurrentCardSets() wie ein Kollege vorschlug. Die Syntax ist wesentlicher unschöner: GetCurrentCardSets().Add(...) muss sich echt nicht mit CurrentCardSets.Add(...) messen wollen.

Wie verhindert man jetzt aber, dass der Programmierer diese lazy initialization nicht einfach umgeht und auf das backing field zugreift? Eine schöne Lösung dafür ist in VB.NET das Schlüsselwort static:

Public Class MyLazyPrivate
Private Property Cards() As List(Of Card)
Get
Static lazyList As List(Of Card)
If (lazyList Is Nothing) Then
lazyList = New List(Of Card)
End If
Return lazyList
End Get
End Property
End Class

Perfekt, so mag ichs, jetzt ist das Backingfield auch noch schön lokal. Ich verstehe sowieso nicht wieso Microsoft nicht schon lange eine Möglichkeit eingeführt hat das Backingfield auf den Scope der Property zu begrenzen. Wäre doch wesentlich sauberer, oder? Ok, zugegeben mit den automated Properties in VS08 macht Microsoft das ja ein wenig...

Achja, zum Titel:

Ausser, das Propertys eigenlich als Schnittstelle für die Auswelt gedacht
war.Das ist wie wenn ich an mein Briefkasten den Schlitz zuschweise.Ich kann
zwar jetzt Briefe dort sicher aufbewaren, das ist aber nicht im sinne des
Erfinders.....

ActiveVB Thread zum Thema.

Testmatrix - Keine Tests in Assembly

In Visual Studio 2005 arbeite ich gerne mit dem Tool TestMatrix von http://www.exactmagic.com/
Ein gescheites Testing muss ja sein und dieses Tool integriert mir NUnit komfortabel in Visual Studio - zu einem akzeptablen Preis.

Heute hat mich das Tool aber der Verzweiflung nahe gebracht. Meine Solution kompilierte korrekt, aber TestMatrix konnte keine Tests finden. Nach langem suchen bin ich auf die Lösung gestossen. Der Output-Pfad war länger als 256 Zeichen. Beim Laden der Tests hat TestMatrix intern einen Fehler geworfen und desshalb das Laden der Tests abgebrochen.

Ich hoffe ich konnte damit jemandem helfen.

Welcome Blogging

So nun ists so weit. Lange habe ich mir Zeit gelassen.

Seit Jahren lese und lerne ich aus/in Blogs und habe schon manche Problemlösung gefunden. Ich habe nicht das Bedürfnis mich im Internet zu verewigen, nein - viel mehr möchte ich von dem gesammelten Erfahrungsschatz, unter anderem aus anderen Blogs, weitergeben. Nach Jahrelangem nehmen also nun auch mal geben. Ich hoffe ich finde genug Zeit um regelmässig neue Blogs zu schreiben - mache mir da aber keine falschen Hoffnungen.

Anyway... enjoy my postings... :)