Ich kenne Python seit Version 1.5.2, also schon seit über 10 Jahren. Ich habe mich aber in den letzten Jahren nicht damit beschäftigt. Vor ca. 1 Jahr habe ich beschlossen, mich wieder mehr mit Python zu beschäftigen.

Am letzten Montag, dem 22. August 2011, hielt Rainer Schuster im Rahmen der .NET Online User Group einen Online-Vortrag über Python. Einen Tag darauf reagierte Hans-Peter Schelian mit einem Blogartikel, nachdem er sich einen Tag lang mit Python beschäftigt hat, “um den Hype um diese Sprache besser verstehen zu können”.

Python ist kein Hype

Python 1.0 wurde lange vor .NET 1.0 veröffentlicht, nämlich im Jänner 1994 (siehe Wikipedia). Python wird seit vielen Jahren von namhaften Organisationen verwendet, darunter Google, Yahoo!, NASA und CERN (siehe Wikipedia). Daher glaube ich nicht dass Python ein Hype ist, der bald wieder abflaut. Python ist eine bewährte Technologie, die ihre Tauglichkeit bereits vielfach bewiesen hat.
Python ist leicht zu durchschauen

Es wird immer wieder behauptet, dass Python-Code für Programmieranfänger leicht zu durchschauen und zu lesen sei. Ich glaube, dass das auch stimmt. Möglicherweise sieht man das anders, wenn man die Syntax von C-basierten Programmiersprachen wie C#, C/C++ oder Java gewöhnt ist. Auch der Unterschied von Hello-World-Programmien in Python und in C# zeigen, dass C# sehr viel unnötiges Rauschen enthält.

Hier ein bekanntes Programm in Python:

#!/usr/bin/env python
print “Hello, world!”

Und hier in C#:

public class Hello
{
  public static void Main(string[] args)
  {
    System.Console.WriteLine (“Hello, world!”);
  }
}

Natürlich wächst der “Signalanteil” bei größeren Programmen. Aber als Programmieranfänger muss man bei C# für einfache Programme wesentlich mehr wissen als bei Python.

Python wird vielseitig eingesetzt

Jeder, der sich ein Video auf Youtube.com ansieht, verwendet Software, die zumindest teilweise in Python geschrieben ist. Jeder, der in diesem Blog einen Kommentar schreiben möchte, verwendet Disqus, das das Python-Webframework Django verwendet. Jeder, der Ubuntu Linux installiert hat, hat Python-Software verwendet. Die verteilten Versionsverwaltungssysteme Mercurial und Bazaar sind in Python geschrieben. Die Windows-GUIs dafür, TortoiseHG und TortoiseBzr, sind ebenfalls in Python geschrieben. Seit Jahren verwenden Hersteller von 3D-Animationssoftware Python als eingebettete Skriptsprache.

Es gibt einen Mailserver in Python. Es gibt Klassen in der Python-Standardbibliothek, die die Implementierung eines SMTP-Servers vereinfachen.

Und wenn wir schon bei E-Mails sind: Mailman ist ein beliebter Mailinglistenmanager, der sogar vom Mono-Team verwendet wird (z.B. Mono-list). Und wenn man Android-Apps mit C# entwickeln will und sich an die MonoDroid-Mailingliste anmeldet, wird man ebenfalls Mailman verwenden.

Kann man Python für größere Projekte verwenden?

Ja, man kann. Es ist aber nicht jedermanns Sache. Wer lieber eine statische Programmiersprache verwendet, wird keine Freude mit Python haben.

Ein Compiler ersetzt keine Unit- und Integrationstests. Auch wenn der Code ohne Fehler compiliert werden kann und daher keine syntaktischen Fehler enthalten sind, können noch immer semantische Fehler enthalten sein. Daher sind für größere Projekte automatisierte Unit-Tests in der professionellen Software-Entwicklung Pflicht. In einer dynamischen Programmiersprache tut man sich da in einigen Fällen leichter. Dafür braucht man aber erfahrene Software-Entwickler, die sich damit auskennen.

Übrigens, in der Python-Standardbibliothek gibt es zwei Testframeworks für die Automatisierung von Tests.

Fazit

Also Python ist kein Hype, dafür ist es schon zu lange in Verwendung. Python hat möglicherweise für Programmieranfänger eine einfachere Syntax und es wird in vielen Projekten verwendet. Außerdem lassen sich damit auch größere Programme realisieren.

Am 16. September spricht Greg Young auf der Community-Konferenz “Professional .Net 2011″ in Wien über Domain Driven Design (DDD) und wie man dieses in Projekten mit der von ihm beschriebenen Softwarearchitektur Command and Query Responsibility Segregation (CQRS) erfolgreich umsetzen kann.

Aus Wikipedia:

“Domain-Driven Design ist nicht nur eine Technik oder Methode. Es ist viel mehr eine Denkweise und Priorisierung zur Steigerung der Produktivität von Softwareprojekten im Umfeld komplexer fachlicher Zusammenhänge.”

In DDD möchte man nicht nur Daten manipulieren (CRUD), sondern auch in einer gemeinsamen Sprache festhalten aus welchem Grund sich Daten geändert haben und welches Verhalten das System hat. Die Intention der Benutzeraktion soll erfasst werden. So sind beispielsweise die Aktionen “Kunde eröffnet ein Konto” und “Geld wird abgehoben” wesentliche Aktionen eines Bankensystems. Mit DDD kann das System und dessen Verhalten (Behavior) modelliert werden.

Hinter diesen Aktionen stecken allerdings oftmals auch Business-Regeln wie etwa, dass nur max. 3.000 Euro pro Tag über Automaten von einem Konto behoben werden können. CQRS bietet eine elegante und skalierbare Lösung um dies in Software umzusetzen. Die Business Regeln enden nicht im Client, sondern werden zentral in der Domäne (dort wo der meiste Business Nutzen entsteht) gehalten.

Greg zeigt auch, wie dadurch das automatisierte Testen mit Unit Tests vereinfacht und expliziter wird. Weiters wird auch aufgezeigt, wie durch das Speichern der durchgeführten Aktionen zu einem späteren Zeitpunkt Auswertungen die im Vorhinein nicht definiert wurden, einfach umgesetzt werden können.

Beispiel: der Bankdirektor möchte eine Auswertung wie viele Kunden ihr Bankkonto schließen, nachdem sie umgezogen sind um durch Werbemaßnahmen dem gegenzusteuern. Dabei handelt es sich um einen wesentlichen Business-Vorteil.

CQRS wird nicht nur in sehr großen Softwareprojekte eingesetzt, die enorme Skalierbarkeit benötigen. Es hilft bereits bei Projekten die nicht nur “Create, Read, Update, Delete” Befehle haben, sondern bei denen auch Validierung und Business Regeln umgesetzt werden sollen.

Ganz treu dem Motto der heurigen Professional .Net: Einfach bessere Software entwickeln!

Mehr Infos zur Professional .Net 2011 findet ihr unter www.dotnet-austria.at.

Web Development, HTML5 und JavaScript

• CoffeeScript Basics (RailsCasts)
• 10 CoffeeScript One Liners to Impress Your Friends (Ricardo Tomasi)
• Tools For jQuery Application Architecture (Extended Slides) (Addy Osmani)
• Javascript – How Prototypal Inheritance really works (Christopher Chedeau)
• A Prototypal Discussion (Dion Almaer)
• Chrome Developer Tools: Put JavaScript memory under control (Mikhail Naganov)
• Episode 0.6.2 – IronJS with Fredrik Holmström (The Changelog, Wynn Netherland)
• Responsive Web Design: A Visual Guide (Andrew Gormley)
• A Basic HTML5 Template (Louis Lazaris)

F# und Funktionale Programmierung

• F# Snippets
• Nice F# Syntax for Rx (Reactive Extensions) (Don Syme)

ASP.NET

• What ASP.NET MVC Could Learn From Rails (Justin Etheredge)
• Referencing Routes in ASP.NET MVC The Rails Way (Rob Conery)

.NET-Community Wien

• Professional .NET 2011–Die .NET Community Konferenz in Wien (Mario Meir-Huber)
• Wien, 14. Juni 2011, 18h: Usergroup treffen jQuery (Mario Meir-Huber)

Methodology

• Return of the Horizontal Slice (Joshua Kerievsky)
• Breaking Team Silos With Kanban (Sami Honkonen)
• Quantifying Technical Debt (Arlo Belshee)

Dieses Mal findet das Treffen bei meinem Arbeitgeber, der Firma rubicon informationstechnologie gmbh statt.

Details gibt es wie immer auf der NING-Seite der Gruppe.

Das Treffen findet bei der Unisys im Andromedatower statt.

Details gibt es wie immer auf der NING-Seite der Gruppe.

Das Treffen findet bei Microsoft Österreich GmbH statt.

Details gibt es wie immer auf der NING-Seite der Gruppe und auf der Codefest-Seite.

Foto: Nasmac

IronRuby verwendete schon länger ein Repository auf Github für die Quellcodeverwaltung. Darin befindet sich auch die DLR (Dynamic Language Runtime), die von beiden Projekten benötigt wird. Das IronPython-Team entschied daher, dieses Repository mitzubenutzen. Das Issue-Tracking bleibt aber auf Codeplex.

Die Mehrheit der IronPython-Community sprach sich für BitBucket und damit Mercurial aus, das in der Python-Community beliebter ist. Für alle, die am IronPython-Quellcode interessiert sind, aber nicht auf Git umsteigen möchten, hat Jeff Hardy einen Mirror auf BitBucket eingerichtet und dessen Verwendung für die Entwicklung an IronPython dokumentiert.

Details dazu gibt es wie immer auf den Seiten der .NET-Community “.Net Open Space Austria” auf Ning.

Nächsten Freitag, also am 14. Mai 2010, um 18:00 Uhr ist es wieder so weit. Das monatliche Wiener .NET Coding Dojo findet wieder statt. Bevor wir mit dem Kata beginnen, wird uns Jörg zeigen, wie man moderne Web-Anwendungen mit ASP.NET MVC baut. Nach einer Pause werden wir uns diesmal dem KataBowling widmen.

Nähere Informationen findet ihr hier: http://dotnetopenspace.ning.com/events/aspnet-mvc-anwendung-1.

Ich freue mich auf euer Kommen.

Beim letzten Mal hatten wir die Statuszeile noch so definiert:

        ...
        <StatusBar DockPanel.Dock="Bottom">
            <TextBlock Text="Col 1, Ln 1" />
        </StatusBar>
        ...

Das sieht so aus:

Ein TextBlock-Element befindet sich in der Statuszeile, das links angezeigt wird. Doch wie bekommen wir den Text an die gewünschte Position?

Die StatusBar stellt ihre Steuerelemente normalerweise mit einem DockPanel dar. Allerdings werden alle Steuerelemente, die nicht vom Typ StatusBarItem sind, in einem StatusBarItem-Element eingehüllt, d.h. wir müssen selbst das StatusBarItem-Element angeben, damit wir die DockPanel-Eigenschaften definieren können.

        ...
        <StatusBar DockPanel.Dock="Bottom">
            <StatusBarItem DockPanel.Dock="Right">
                <TextBlock Text="Col 1, Ln 1" />
            </StatusBarItem>
            <StatusBarItem/>
        </StatusBar>
        ...

Der Text wird jetzt zwar rechts dargestellt, aber noch nicht genau dort, wo wir ihn haben wollen. Außerdem mussten wir ein leeres StatusBarItem-Element hinzufügen, das den Hauptteil der Statuszeile ausfüllen soll. Andernfalls würde das StatusBarItem-Element mit dem TextBlock nicht rechts dargestellt. Würden wir einen zweiten Text darstellen wollen, müssten wir es zum leeren StatusBarItem hinzufügen. Somit käme der linke Teil im XAML-Code vor dem rechten. Viel lieber hätten wir an dieser Stelle ein Grid, weil wir dann die Breite der Spalten selbst bestimmen können. Aber wie erreichen wir das?

Die StatusBar gehört wie ListBox, ListView, ComboBox, Menu und einigen anderen zu den sogenannten Items-Controls. Diese stellen ihre Subelemente in einem Panel dar, das durch die Eigenschaft ItemsPanel definiert wird. Normalerweise wird darin ein StackPanel definiert, aber StatusBar hat diese Eigenschaft überschrieben und durch ein DockPanel ersetzt, wie wir oben gesehen haben. Wir können dieser Eigenschaft ein Grid zuweisen und so zu dem gewünschten Ergebnis kommen. In XAML sieht das so aus:

        <StatusBar DockPanel.Dock="Bottom">
            <StatusBar.ItemsPanel>
                <ItemsPanelTemplate>
                    <Grid>
                        <Grid.RowDefinitions>
                            <RowDefinition Height="*"/>
                        </Grid.RowDefinitions>
                        <Grid.ColumnDefinitions>
                            <ColumnDefinition Width="2*"/>
                            <ColumnDefinition Width="1*"/>
                        </Grid.ColumnDefinitions>
                    </Grid>
                </ItemsPanelTemplate>
            </StatusBar.ItemsPanel>
            <StatusBarItem Grid.Column="1" Grid.Row="0">
                <TextBlock Text="Col 1, Ln 1" />
            </StatusBarItem>
        </StatusBar>

Die Eigenschaft bekommt ein ItemsPanelTemplate, in dem wir mit einem Grid ein Layoutgitter definieren, das aus einer Zeile und zwei Spalten besteht. Die Spalten teilen sich den verfügbaren Platz im Verhältnis 2:1 auf. Die rechte Spalte umfasst also das rechte Drittel der Statuszeile. Den TextBlock geben wir in das StatusBarItem, das wir der rechten Spalte zuweisen. Damit befindet sich der Text immer im rechten Drittel der Statuszeile.

Die WPF-Statuszeile kann auch andere Steuerelemente darstellen, z.B. Bilder, Fortschrittsbalken und viele andere mehr. Wenn man dann mehr Kontrolle über das Layout der Statuszeile braucht, kann das DockPanel jederzeit durch etwas anderes ersetzt werden.