Was ist ein Coding-Dojo?

Ein Coding-Dojo ist ein Treffen, bei dem eine Reihe von Programmierern zusammenkommen, um an einer Programmieraufgabe zu arbeiten. Dabei geht es hauptsächlich darum, in einer lockeren Atmosphäre die Aufgabe gemeinsam zu lösen und dabei Neues zu lernen. Ein Dojo ist kein Wettbewerb, sondern der Lerneffekt steht im Vordergrund.

Das Konzept der Coding-Dojos gibt es bereits länger. In den letzten Jahren wurden Coding-Dojos immer beliebter, was unter anderem auch daran liegt, dass sich jeder Teilnehmer einbringen kann.

Mehr Informationen gibt es auf http://codingdojo.org.

with self.assertRaises(SomeException):
    do_something()

Bisher dachte ich, dass das with-Statement wie das using-Statement in C# funktioniert. Das Äquivalent in C# wäre dann:

using (this.AssertRaises(typeof(SomeException)))
  DoSomething();

In C# kann das nicht funktionieren, weil die Dispose-Methode des IDisposable-Objekts, das von AssertRaises zurückgegeben würde, keine Referenz auf die Exception, die von DoSomething geworfen wurde, erhält.
Wenn man außerdem weitere Eigenschaften der Exception überprüfen will, kann man in Python Folgendes schreiben:

with self.assertRaises(SomeException) as cm:
    do_something()
 
the_exception = cm.exception
self.assertEquals(the_exception.error_code, 3)

Für mich war das einmal ein Grund, mich einmal mit dem with-Statement zu beschäftigen, das es erst seit Python 2.5 gibt.

Das with-Statement

Das with-Statement wird verwendet, um vor und nach der Ausführung eines Codeblocks Methoden auf einem Context-Manager auszuführen. Auf diese Art und Weise kann man in Python Ähnliches erreichen wie in C# mit dem using-Muster, z.B.:

filename = “hello.txt”
 
with open(filename, ‘w’) as file:
    file.writelines([“first line\n”, “second line\n”])
 
with open(filename, ‘r’) as f:
    for line in f:
        print line.strip()

In älteren Python-Versionen (älter als 2.5) musste man mit try...finally das File-Objekt selbst schließen:

filename = “hello.txt”
 
file = open(filename, ‘w’)
try:
    file.writelines([“first line\n”, “second line\n”])
finally:
    file.close()
 
f = open(filename, ‘r’)
try:
    for line in f:
        print line.strip()
finally:
    f.close()

Aber wie funktioniert with eigentlich?

Über Pythons und Enten

Das using-Statement in C# erwartet sich ein Objekt, das die IDisposable-Schnittstelle implementiert. Wenn der dem using-Statement folgende Codeblock verlassen wird, wird die Dispose-Methode auf dem IDisposable-Objekt aufgerufen. Dabei ist es egal, ob im Codeblock eine Exception geworfen wird oder der Codeblock auf normalem Weg verlassen wird.
Interfaces gibt es in Python nicht, aber es gibt Duck-Typing:

“Wenn es wie eine Ente läuft, wie eine Ente schwimmt und wie eine Ente schnattert,
dann ist es eine Ente.”

Das bedeutet, dass der Typ eines Objekts nicht durch die Klasse bestimmt wird, sondern durch die Methoden, die es implementiert. Eine Menge an Methoden, die ein Objekt für ein bestimmtes Feature implementieren muss, heißt Protokoll. Es entspricht somit einem Interface, nur dass man bei einem Protokoll nicht angeben muss, das eine Klasse es implementiert. Solange alle Methoden des Protokolls vorhanden sind, ist alles in Ordnung.

Das with-Statement erwartet sich ein Objekt, das das Context-Management-Protokoll implementiert.

Der Context-Manager

Dieses Objekt wird Context-Manager genannt. Das Context-Management-Protokoll besteht aus zwei Methoden:

• contextmanager.__enter__()
• contextmanager.__exit__(exc_type, exc_value, exc_tb)

Methoden, die dafür bestimmt sind, von der Python-Runtime selbst aufgerufen zu werden, haben einen Namen, der mit zwei Unterstrichen (__) beginnt und mit zwei Unterstrichen endet.

Die Methode __enter__ wird aufgerufen, bevor der Codeblock aufgerufen wird, die Methode __exit__ danach.

Ein Beispiel:

class HelloContext:
    def __init__(self, text):
        self._text = text
 
    def __enter__(self):
        print “Enter”
        return self
 
    def __exit__(self, exc_type, exc_val, exc_tb):
        print “Exit”
        return False
 
    def show(self):
        print self._text
 
 
with HelloContext(“Hello, world!”) as hc:
    hc.show()

Zugegeben, ein wenig viel Code für “Hello, world!”, aber es geht ja hier um den Context-Manager. Das, was die Methode __enter__ zurückgibt, wird im with-Statement der Variable zugewiesen, die nach der Instanzierung des Context-Managers mit as angegeben ist. In unserem Beispiel ist das hc, das auf den Context-Manager verweist, weil __enter__ den Context-Manager (self) zurückgibt. Das kann anders sein:

class Hello:
    def __init__(self, name):
        self._name = name
 
    def show(self):
        print “Hello, %s!” % self._name
 
 
class HelloContext:
    def __init__(self, name):
        self._name = name
 
    def __enter__(self):
        print “Enter”
        return Hello(self._name)
 
    def __exit__(self, exc_type, exc_value, exc_tb):
        print “Exit”
        return False
 
 
with HelloContext(“world”) as hc:
    hc.show()

Die Variable hc verweist auf eine Instanz der Klasse Hello, die von der Methode __enter__ des Context-Managers erzeugt und zurückgegeben wird. Das with-Statement ruft trotzdem __enter__ und __exit__ am Context-Manager auf.

Die Behandlung von Exceptions

In den bisherigen Beispielen gibt die Methode __exit__ False zurück. Was bedeutet das? Und was sind das für Argumente, die an __exit__ übergeben werden?
Wenn alles gut geht und der ausgeführte Codeblock keine Exception wirft, wird an __exit__ für alle Argumente (außer self natürlich) None übergeben und der Rückgabewert ignoriert. Wurde eine Exception geworfen, wird an __exit__ der Typ, der Wert und die Traceback-Informationen (entspricht in .NET dem Stacktrace) übergeben.

class HelloContext:
    def __enter__(self):
        print “Enter”
        return self
 
    def __exit__(self, exc_type, exc_value, exc_tb):
        print “Exit”
        if exc_type != None:
            print exc_type
            print str(exc_value)
            print exc_tb
        return True
 
 
class MyError(Exception):
    def __init__(self, message, item):
        self.message = message
        self.item = item
 
    def __str__(self):
        return self.message + ‘ ‘ + str(self.item)
 
 
with HelloContext():
    print “Hello, world!”
    raise MyError(“Exception!”, 42)
 
print “But life goes on...”

Wenn man diesen Code ausführt, wird folgendes ausgegeben:

Enter
Hello, world!
Exit
<class ‘__main__.MyError’>
Exception! 42
<traceback object at 0x1e45320>
But life goes on...

Der Rückgabewert von __exit__ gibt an, ob die Exception unterdrückt werden soll. Deshalb wird in unserem Beispiel der Text “But life goes on…” ausgegeben. Würde __exit__ False zurückgeben, käme stattdessen der normale Python-Traceback und das Programm würde unterbrochen.

Verschachtelte Context-Manager

Das with-Statement kann mit mehr als einem Context-Manager aufgerufen werden:

with open(‘a.txt’, ‘r’) as a, open(‘b.txt’, ‘w’) as b:
    b.writelines(a.readlines())

Dieser Code ist gleichbedeutend mit Folgendem:

with open(‘a.txt’, ‘r’) as a:
    with open(‘b.txt’, ‘w’) as b:
        b.writelines(a.readlines())

Context-Manager in der Standardbibliothek

Neben dem bereits erwähnten unittest.TestCase.assertRaises und io.open gibt es noch weitere Beispiele für Context-Manager in der Python-Standardbibliothek, z.B. im Modul threading. Objekte vom Typ Lock, RLock, Condition, Semaphore und BoundedSemaphore können mit dem with-Statement benutzt werden.

Ein weiteres Modul mit einem Context-Manager ist das Modul decimal, das bei der Fließkommaarithmetik unterstützt. Mit decimalcontext kann man einen Bereich mit anderer Genauigkeit definieren als der umgebende Code.

Das Modul contextlib der Standardbibliothek

Die Python-Standardbibliothek kennt das Modul contextlib. Es enthält einige Hilfsmittel für allgemeine Aufgaben, die mit dem with-Statement zu tun haben.

Der contextmanager-Decorator

Eines dieser Hilfsmittel ist ein Decorator, der die Implementierung eines Context-Managers vereinfacht. Wir können unser obiges Beispiel auch so schreiben:

from contextlib import contextmanager
import sys
 
@contextmanager
def hello():
    print “Enter”
    try:
        yield
        print “Exit”
    except:
        exc_type, exc_value, exc_tb = sys.exc_info()
        print exc_type
        print str(exc_value)
        print exc_tb
 
 
class MyError(Exception):
    def __init__(self, message, item):
        self.message = message
        self.item = item
 
    def __str__(self):
        return self.message + ‘ ‘ + str(self.item)
 
 
with hello():
    print “Hello, world!”
    raise MyError(“Exception!”, 42)
 
print “But life goes on...”

Ein früheres Beispiel würde so aussehen:

from contextlib import contextmanager
 
class Hello:
    def __init__(self, name):
        self._name = name
 
    def show(self):
        print “Hello, %s!” % self._name
 
 
@contextmanager
def hello(name):
    print “Enter”
    try:
        yield Hello(name)
    finally:
        print “Exit”
 
 
with hello(“world”) as h:
    h.show()

Wenn bei yield ein Argument angegeben wird, kann dieses beim with-Statement mit as referenziert werden.

Der Context-Manager closing

Ein weiteres wichtiges Hilfsmittel aus dem contextlib-Modul ist die Klasse closing. Damit kann man Klassen wrappen, die zwar eine Methode mit dem Namen close haben, aber selbst kein Context-Manager sind und daher die Methoden __enter__ und __exit__ nicht implementieren. In der Methode __exit__ wird die close-Methode des gewrappten Objekts aufgerufen.

Zum Beispiel:

from contextlib import closing
import urllib
 
with closing(urllib.urlopen(‘http://www.python.org’)) as page:
    for line in page:
        print line

Der nested-Decorator

Der nested-Decorator verbindet mehrere Context-Manager zu einem und ermöglicht somit verschachtelte Context-Manager. Seit Version 2.7 bzw. 3.1 unterstützt das with-Statement verschachtelte Context-Manager und dieser Decorator wurde damals als deprecated markiert und sollte daher nicht mehr verwendet werden. Wenn man ältere Python-Versionen unterstützen muss, kann man den nested-Decorator z.B. so anwenden:

from contextlib import nested
 
with nested(open(‘a.txt’, ‘r’), open(‘b.txt’, ‘w’)) as cms:
    cms[1].writelines(cms[0].readlines())

Ein Vorteil des nested-Decorators gegenüber dem with-Statement ist, dass man eine Liste von Context-Manager angegeben kann:

from contextlib import nested
 
cms = [open(‘a.txt’, ‘r’), open(‘b.txt’, ‘w’)]
 
with nested(*cms):
    cms[1].writelines(cms[0].readlines())

Der Stern bei nested ist notwendig, damit an nested die Elemente der Liste als Argumente übergeben werden und nicht die Liste als einzelnes Argument.

Mehr über das Modul contextlib findet man in der Referenzdokumentation oder im Source-Code.

Python 3

In Python 3 hat sich bei der Funktionsweise der Context-Manager nichts geändert. Die Beispiele in diesem Artikel wurden mit Python 2.7 getestet und müssten für Python 3 angepasst werden, weil nicht alle benutzten Module und Statements mit Python 3 kompatibel sind.

Zusammenfassung

Obwohl es auf dem ersten Blick so aussieht wie das using-Statement in .NET, ist Pythons with-Statement wesentlich mächtiger. Die IDisposable-Schnittstelle ermöglicht nur das Aufräumen von Ressourcen, wenn ein Codeblock verlassen wird. Ein Context-Manager kann schon am Anfang eines Codeblocks aktiv werden. Außerdem kann ein Context-Manager beim Verlassen eines Codeblocks eine eventuell aufgetretene Exception behandeln und unterdrücken. So ist auch klar, warum man in Unit-Tests mit dem with-Statement Exceptions testen kann.

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.

Was ist ein Coding-Dojo?

Ein Coding-Dojo ist ein Treffen, bei dem eine Reihe von Programmierern zusammenkommen, um an einer Programmieraufgabe zu arbeiten. Dabei geht es hauptsächlich darum, in einer lockeren Atmosphäre die Aufgabe gemeinsam zu lösen und dabei Neues zu lernen. Ein Dojo ist kein Wettbewerb, sondern der Lerneffekt steht im Vordergrund.

Das Konzept der Coding-Dojos gibt es bereits länger. In den letzten Jahren wurden Coding-Dojos immer beliebter, was unter anderem auch daran liegt, dass sich jeder Teilnehmer einbringen kann.

Mehr Informationen gibt es auf http://codingdojo.org.

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.