.NET Blog   ·   .NET Casts   ·   .NET GUI Foren   ·   .NET BlogBook   ·   WPF Blogger   ·   visual studio one   ·   ASP.NET professional

  • ACHTUNG - NEUES BLOG

    Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen Einträgen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.
Download .NET Essentials Installer
Trickkiste

Docking wie Visual Studio

19.12.08 - .NET, WPF
Beitrag von Norbert Eder
 Wer ein richtiges Docking abseits des DockPanels benötigt, der sei auf AvalonDock hingewiesen. Damit lassen sich innerhalb kürzester Zeit Docking-Szenarien á la Visual Studio realisieren.

Hier ein XAML-Markup zur Demonstration: 
<Grid>
    <ad:DockingManager x:Name="dockManager">
        <ad:ResizingPanel Orientation="Vertical">
            <ad:ResizingPanel Orientation="Horizontal" >
                <ad:DockablePane>
                    <ad:DockableContent Title="Beschreibung">
                        <TextBox />
                    </ad:DockableContent>
                </ad:DockablePane>
                <ad:DocumentPane x:Name="documentsHost">
                    <ad:DockableContent Title="Dokument 1">
                        <RichTextBox/>
                    </ad:DockableContent>
                    <ad:DockableContent Title="Dokument 2">
                        <RichTextBox/>
                    </ad:DockableContent>
                </ad:DocumentPane>
            </ad:ResizingPanel>
            <ad:DockablePane>
                <ad:DockableContent Title="Ausgabe">
                    <TextBox />
                </ad:DockableContent>
            </ad:DockablePane>
        </ad:ResizingPanel>
    </ad:DockingManager>
</Grid>

Das Ergebnis läßt sich sehen:



Und hier nun im Docking-Modus:



AvalonDock kann unter anderem auch per MSI-Paket installiert werden. In der Toolbox finden sich anschließend alle bereitgestellten Steuerelemente. Eine sehr nette und hilfreiche Sache. Es empfiehlt sich, einen genaueren Blick auf dieses Projekt zu werfen.

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Ich werde beklaut!

18.12.08 - .NET, WPF
Beitrag von Norbert Eder
 Das trifft wohl nicht oft zu. Aber sehr viele Softwareunternehmen haben Angst, beklaut zu werden. Beklaut hinsichtlich Ideen, Sourcecode oder Ähnlichem.

Fast täglich werde ich von unterschiedlichsten Personen darauf angesprochen - meist hinsichtlich WPF - wie man sich effektiv davor schützen kann. Sind erst mal die grundlegenden Informationen bezogen, stellt sich schnell heraus, dass in den meisten Fällen bereits Tools (Obfuscator etc.) eingesetzt werden und das eigentliche Problem ganz wo anders liegt - nämlich in der immerwährenden Angst.

Natürlich, seit es Software gibt, wurde von der Konkurrenz abgekupfert und geklaut. Das wird wohl auch noch so bleiben und kann wohl nie gänzlich ausgeschlossen werden.

Die mir gestellten Fragen bezogen sich meist auf einfache Dinge: Styles, Templates. Und ja, diese Informationen können sehr einfach aus einer Assembly bezogen werden. Alles was man dazu braucht ist der .NET Reflector und das Add-In Baml-Viewer.

Sehen wir uns dies anhand eines Beispiels an. Gegeben sei eine kleine Anwendung, die einen einzigen Button enthält. In der App.xaml wird global für alle Buttons ein Style definiert: 
<Style TargetType="Button">
    <Setter Property="FontFamily" Value="Arial"/>
    <Setter Property="FontSize" Value="22"/>
    <Setter Property="BorderThickness" Value="2"/>
    <Setter Property="Background">
        <Setter.Value>
            <LinearGradientBrush StartPoint="0,0" EndPoint="1,1">
                <GradientStop Color="Yellow" Offset="0.0"/>
                <GradientStop Color="Orange" Offset="1.0"/>
            </LinearGradientBrush>
        </Setter.Value>
    </Setter>
</Style>

Nach dem Kompilieren der Anwendung, wird die erstellte Assembly (in diesem Fall die die ausführbare Anwendung) im Reflector geöffnet. Innerhalb der Ressourcen finden sich die generierten Ressourcen für unsere Anwendung. In <i>AssemblyName</i>.g.resources auch die zu BAML kompilierten XAML-Dateien:



Mit installiertem BamlViewer kann nun über das Tools-Menü eben dieser aufgerufen werden. Als Ergebnis werden zwei zusätzliche Bereiche angezeigt. Im ersten werden die enthaltenen Baml-Dateien gezeigt. Bei Klick auf eine dieser Dateien wird das XAML im zweiten Bereich gezeigt:



Damit ist es nun ein Leichtes, um an fremde Styles, Templates und dergleichen heran zu kommen. Dies ändert sich auch nicht, wenn beispielsweise ein Tool á la den Dotfuscator verwendet wird. Das XAML bleibt vor diversen Änderungen unberührt. Zudem sollte mit Obfuscatoren und XAML besonders vorsichtig umgegangen werden. Typen, die von XAML aus benötigt werden, sollten beispielsweise nicht umbenannt werden, da diese anschließend nicht mehr gefunden werden können. Lediglich {smartassembly} bietet kleine Unterstützungen in diese Richtung an.

Generell ist anzumerken, dass es zwar sicherlich einige geben wird, die sich hart erarbeitete Styles von anderen "besorgen" werden. Der Punkt ist aber weiterhin die Businesslogik. Diese entsteht oft in Mannmonaten bzw. -jahren und kann nicht so einfach analysiert werden. Im der dafür notwendigen Zeit ist der Hersteller ein gutes Stück weiter und der Erfolg des Reengineerings hält sich somit in Grenzen.

Es verhält sich also ähnlich zu Websites: Auch hier können Styles und die notwendigen Images sehr schnell bezogen werden - die rechtlichen Konsequenzen inklusive. Das Layout macht aber noch keine Anwendung ...

  2 Kommentare - 408 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


UPDATE: WPF-Blogger

17.12.08 - .NET, WPF
Beitrag von Norbert Eder
  Wie bereits angekündigt wird WPF-Blogger in der nächsten Zeit um zusätzliche Features erweitert.

Seit gestern Abend steht die RSS-Feed-Funktionalität zur Verfügung. Je nach Geschmack kann der gesamte Feed bezogen werden (dieser inkludiert die Feeds aus allen Sprachen) und/oder die jeweiligen Sprach-Feeds.

Weitere Features und Verbesserungen folgen demnächst!
  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Neues Service für WPF- und Silverlight-Entwickler

15.12.08 - Blog-Intern, .NET, WPF, Internet, Community
Beitrag von Norbert Eder
  Die erste Phase ist geschafft. WPF-Blogger.com ist online.

Dabei handelt es sich im ersten Schritt um ein Aggregat aus bekannten Blogs mit den Themenschwerpunkten WPF und Silverlight.

Sinn und Zweck ist es, allen WPF- und Silverlight-Entwicklern und -Interessieren eine Anlaufstelle zur Informationsbeschaffung und zum Zugang zu Experten auf diesen Gebieten zu verschaffen.

In den kommenden Phasen sind weitere Funktionen geplant, die weit mehr bieten, als ein reiner Feed-Aggregator.

Das Service ist international ausgelegt. Dies bedeutet, dass zum aktuellen Zeitpunkt deutsche, englische und französische Blogs aggregiert werden.

Aktuell befindet sich das Service in einem Demolauf, daher sind Anregungen, Wünsche und Beschwerden natürlich erwünscht. Diese können sowohl hier als Kommentar, als auch direkt auf WPF-Blogger.com deponiert werden.

Ich freue mich auf jegliche Rückmeldungen konstruktiver Art.


  2 Kommentare - 358 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Playstation 3: Home in wenigen Stunden für alle verfügbar

10.12.08 - Internet, Kunterbunt
Beitrag von Norbert Eder
 Laut Sony Entertainment ist Home in wenigen Stunden (11.12.2008) für weltweit verfügbar. Zwar bleibt Home noch immer im Beta-Stadium, nichts desto trotz kann es nun von jedem Playstation3-Benutzer verwendet werden.

Das Warten hat also ein Ende (zumindest für diejenigen, die nicht an der closed Beta teilnehmen konnten).

Infos, Screenshots und Videos gibt es hier.
  2 Kommentare - 487 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Alt, aber gut!

10.12.08 - Blog-Intern
Beitrag von Norbert Eder
  Die Zeit vergeht! Voriges Jahr hatte ich den Geburtstag übersehen und auch dieses Jahr erging es mir nicht anders (mit zunehmendem Alter werden Geburtstage wohl zunehmend verdrängt). Unabhängig dessen, es gilt zu feiern! Mein Blog Living .NET ist nun bereits drei Jahre alt.

Wie alles begann und vor allem, wann denn nun wirklich, ist den wenigsten bekannt (den meisten wohl auch egal), dennoch möchte ich dazu ein paar Worte verkünden, auch wenn ich mich dabei selbst in eine Krise stürze, aber lest selbst:

Wann begann es wirklich


Mein Blog in der jetzigen Form enthält Informationen seit November 2005. Das ist auch der Zeitpunkt, ab dem ich offiziell rechne. Gestartet hatte ich mein Blog jedoch schon im Juni 2003. Damals noch weitaus dezenter als dies Heute der Fall ist und mit eigener Lösung:



Das Themengebiet waren damals eher alternativ: Linux. Inzwischen hat sich dies bekanntlich geändert. Auch wenn ich mir manchmal einen Blick über den Tellerrand nicht verkneifen kann.

2005 entstand dann dieses Blog, ähnlich wie es nun auch ist. Die Themengebiete haben sich ebenso geändert, wie sich auch das Layout im Laufe der Zeit angepasst hat. Hier ein Screenshot, wie es noch 2007 ausgesehen hat:



Das vergangene Jahr


Zwar hielten sich die im letzten Jahr durchgeführten Änderungen in Grenzen, so hat sich dann doch etwas getan - und das nicht nur am Layout:

.NET GUI. Eine neue Community erblickte im Juni 2008 die Welt. Mit http://dotnet-gui.com rief ich eine Community für all diejenigen ins Leben, die sich mit der Entwicklung von grafischen Oberflächen unter .NET beschäftigen. Darunter fallen natürlich auch die aktuellen Technologien WPF und Silverlight.

Microsoft Most Valuable Professional. Im Juli diesen Jahres wurde ich zum MVP für Client App Dev ernannt. Das hat mich wirklich sehr gefreut und stellte für mich eine Belohnung für meine Tätigkeiten in der Community dar.

Hochzeit. Insgesamt zwei Jahre hatte dieses Projekt für mich gedauert. Im August ging es dann über die Bühne. Es wurde geheiratet. Wohl der größte Meilenstein im letzten Jahr.

Zusätzlich konnten auch noch Veröffentlichungen des .NET BlogBook durchgeführt werden, die Trickkiste wurde runderneuert (Silverlight) und natürlich weitere Projekte und Arbeiten.

Dankesworte


Ich für meinen Teil kann das verganene Jahr aus Sicht dieses Blogs als erfolgreich betrachten. Das wäre jedoch alles nicht möglich ohne den zahlreichen Lesern, Kommentierern, Mail-Schreibern, Unterstützern, Gedankenstützen, Helfern und Freunden. Danke!

  1 Kommentar - 333 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Silverlight Toolkit Dezember 2008 veröffentlicht

10.12.08 - .NET, ASP.NET, Silverlight
Beitrag von Norbert Eder
 Gestern wurde das Silverlight Toolkit December 2008 veröffentlicht.

Hier ein Auszug, was sich verändert hat:
  • More than 80 improvements and bug fixes
  • AutoCompleteBox and NumericUpDown have been moved into the Stable Quality Band.
  • Three new themes have been added: Bureau Black, Bureau Blue and Whistler Blue.
  • The sample application has been given a make-over and is now more polished and easier to navigate.
  • More tests added.
  • Better design-time support in both Visual Studio 2008 and Expression Blend, including icons, property tooltips and better property organization in the property editor.
  • AutomationPeer support added for AutoCompleteBox, Expander and NumericUpDown (as well as UpDownBase).
  • Charting improvements galore!

Weitere Informationen zum Toolkit finden sich auf der Codeplex Release-Seite.

Was ist das Silverlight Toolkit?


Dabei handelt es sich um eine Sammlung von hilfreichen Komponenten, die die Entwicklung unter Silverlight massiv erleichtern sollen.

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Perfektion als Maßstab?

05.12.08 - Entwicklung, Diskussionen, Software Testing, Projektmgmt., Qualitätsmgmt.
Beitrag von Norbert Eder
 Schön langsam wird es schwierig, alle Themen unter einen Hut zu bekommen. Ich versuche daher hiermit auf einige Punkte aus den unterschiedlichen Themenbereichen einzugehen, um hoffentlich alles ein wenig zu kanalisieren.

Alex hat ja bereits meine Aussagen zum Thema Der perfekte Softwareentwickler kommentiert. Nun hat sich auch noch Sven zu Wort gemeldet und das Thema Perfekte Software ins Spiel gebracht. Plausible und legitime Fragestellungen bzw. Aussagen können daraus erlesen werden.

Wenn ich mir darüber nun so meine Gedanken mache, dann stellt sich für mich die Frage, ob Perfektion überhaupt der Maßstab sein kann?

Qualität als Hürde


Software wird bekanntlich von sehr vielen nicht als qualitativ hochwertig angesehen, unabhängig der Bereiche, in denen seit jeher getestet wird, was das Zeug hält. In Business-Anwendungen und im Individual-Bereich zählen oft andere Anforderungen: schnelle Umsetzungszeit, möglichst hohe Funktionsdichte, möglichst hoher Gewinn. Legitime und nachvollziehbare Punkte, die sich offensichtlich mit erhöhtem Zeitaufwand durch Qualitätssicherung, Einführung neuer Methoden und Praktiken oft nicht vereinbaren lassen. Oder doch?

Aus Sicht der Nicht-Entwickler, fallen zum Zeitpunkt der Einführung derartiger Prozesse höhere Aufwände (zeitlich, monitär, etc.) an. Diese wollen oder können nicht getragen werden.

Der springende Punkte daran (und hier können sich weder Kunde, noch der Vorgesetzte, noch die Entwickler ausnehmen) ist, dass jeder seinen Teil dazu beitragen muss. Eine Gruppe alleine kann den großen Umschwung nicht bringen. Prozesse müssen optimiert, Methoden eingesetzt und beides gelebt werden. Nur dann kann es funktionieren.

Im Zuge dessen fällt immer wieder der Return on Investment (ROI). Ich gehe nicht so weit zu sagen, dass ihn niemand erkennt. Vielmehr wird oft nur der vermeintlich steinige Weg gesehen, den es zu gehen gilt. Dass dieser Weg gar nicht so steinig ist und mit kleinen, eingestreuten, Änderungen sehr schnell gegangen werden kann, wird oft nicht korrekt vermittelt (vom Entwickler, von Magazinen, von Online-Artikeln, etc.) oder vom Vorgesetzten dem Kunden gegenüber. Letztlich ist es dem Kunden egal, er will ein funktionierendes Produkt haben. Wie dies erreicht wird, Sache des Herstellers.

(Bewusst aussen vor lasse ich hierbei die Themen wie mit Features etc. umgegangen wird.)

Verantwortung übernehmen


Wohl einer der wichtigsten Punkte: Wer Verantwortung übernimmt, kann Veränderung bringen. Ein qualitätsbewußter Entwickler wird Verantwortung übernehmen, indem er einfach mal eben eine Build-Umgebung einrichtet, oder unabhängig der Unterstützung von oben seine Tests schreibt. Er wird eine geeignete Möglichkeit finden, seine Aufgaben zu analysieren, zu planen, umzusetzen und zu testen. Mit ein wenig Glück kann er diesen Gedanken auf Kollegen und Vorgesetzte transportieren.

Der Vorgesetzte muss Verantwortung üernehmen, indem dieser Entwickler gefördert wird. Natürlich muss nicht nur der qualitative Output passend sein, auch der quantitive. Ganz klar. Er muss einsehen, dass eine qualitative Verbesserung natürlich eine Auswirkung auf den gesamten Output des Unternehmens und somit auch auf das Branding des Unternehmens hat. Der Kunde wird es danken und eventuell weitere Kunden heranschaffen.

Ziel soll es sein, dass sich alle Bereiche (Entwickler, Vorgesetzer, Kunde) gegenseitig unterstützen und sich gegenseitig motivieren sich zu verbessern. Das muss nicht in Einklang mit Verzögerung, weniger Gewinn etc. gehen. Wohl aber geht es in die positive Richtung - mit dieser Einstellung.

Suchen, Sehen, Lernen, Verstehen, Vermitteln


Was Sven festgestellt hat, kann ich nur unterstreichen. Niemand weiß alles. Perfektion kann es also in diesem Sinne nicht geben. Was es aber geben kann und sollte, ist eine permanente Annäherung. Die Entwicklung von Software geht heute kaum schneller voran, als dies vor einigen Jahrzehnten der Fall war. Lediglich die Mittel, Werkzeuge haben sich geändert. Aus einem einfachen Programmierer ist ein Entwickler geworfen. Mit höheren Anforderungen, höhrerer Eigenständigkeit und mehr Verantwortung.

In diesem Zusammenhang fällt mir spontan der Begriff des Paradigmenwechsels ein. Ein Paradigmenwechsel wird notwendig, wenn Anomalien zunehmen und erkannt wird, dass ein anderer Weg doch der bessere wäre. Bis das Spiel wieder von vorne beginnt. In unserer schnelllebigen Branche verändert sich zwar vieles, Paradigmenwechsel halten sich - aus meiner Sicht - jedoch in Grenzen. Es gibt zwar hier Neues, dort Neues, aber wirklich wichtige Praktiken werden nur sehr sehr langsam angenommen.

Woran scheitert das?

Nicht weil wir so schlecht sind, es ist die Fülle an Information, an Werkzeugen, an Methoden. Haben sich darüber früher eine Handvoll Personen Gedanken gemacht, ist in der heutigen Zeit an allen Ecken und Enden ein neuer Aspekt zu lesen. Schwierig, alles unter einen Hut zu bekommen.

Wie war das? Sprich mit fünf Leuten und du erhältst 6 Meinungen. Der einzig wahre Weg ist nicht zu finden. Aber führen nicht alle Wege nach Rom? Die impliziert, das Rom das Ziel aller Ziele wäre. Dies bedeutet, dass auch alle Wege an Ziel führen. Ist das so?

Wie viele (Software)Projekte werden nicht abgeschlossen? Wieviele werden nicht mit vollständiger Funktionalität rechtzeitig ausgeliefert? Die Antwort kann sich jeder selbst geben.

Der Punkt ist, dass eben nicht alle Wege ans Ziel führen. Unterschiedliche Zeiten erfordern unterschiedliche Aktionen.

Gibt es eine Lösung?


Wohl nicht. Man kann wohl niemanden bekehren den richtigen Weg zu gehen, weil es ihn einfach nicht gibt. Aber man kann durchaus einen richtigeren Weg vorschlagen und versuchen zu unterstützen. Eigeninitiative und Verantwortung sind sie Schlagwörter von Wichtigkeit.

Es ist schön perfekt zu sein. Niemand wird jemals perfekt sein. Weder der Mensch, noch seine erschaffenen Produkte. In ist, wer nicht perfekt sein will, sich und seine Umgebung jedoch beständig zu verbessern versucht.

In diesem Sinne:
Keine Perfektion, aber kontinuierliche Verbesserung!

  Kommentar hinzufügen   |  1 Trackbacks   |  Permalink  |  Trackback-URL


Gedanken zum perfekten Softwareentwickler

04.12.08 - Entwicklung, Diskussionen, Software Testing, Qualitätsmgmt.
Beitrag von Norbert Eder
 Nach meiner Antwort zu Peter, hat sich nun auch Alex zu Wort gemeldet. Dem kann ich mich inhaltlich auch voll und ganz anschließen (ein Hoch auf mein Notizbuch).

Was ich jedoch aussagen wollte, war etwas anderes. Wir sprechen hier von Themenbereichen, die für manche täglich Brot sind und worüber oft nicht mehr nachgedacht werden muss. Bei vielen Entwicklern verhält sich das anders.

So erlebe ich fast täglich, das Begriffe wie Test-Driven-Development (TDD) oder Domain-Driven-Design (DDD) nicht allgemein hin bekannt sind. Teilweise noch nicht einmal im Ansatz.

Verweigerung: Nein! Doch!


In der Praxis wird Software oft nicht entsprechend dieser Methoden entwickelt. Dies hat unterschiedlichste Gründe:
  • Unzureichende Motivation, sich weiter zu bilden
  • Probleme mit dem Programmier-Werkzeug
  • Ausrede: Zeitdruck
  • Verweigerung dem Testing gegenüber
  • Lieber diskutieren anstatt es zu tun
  • Faulheit
  • Nicht wissen, wo beginnen

Diese Liste könnte wohl noch um zahlreiche Punkte verlängert werden.

Es gibt Entwickler, die als Leitkuh fungieren und versuchen, andere mit auf diesen Zug zu bringen. Das ist teilweise nicht so einfach. Wie bewegt man jemanden dazu, sich diesen Methoden anzuschließen, wenn jegliche Motivation, dies zu tun, fehlt?

Vorschriften. Schön und gut. Aber kann ein Softwareentwickler zu Qualität gezwungen werden? Wohl nicht. Daher ist es angesagt, Best Practices aufzuzeigen und der Einfachheit halber den Weg langsam zu beschreiten. Nicht jeder kann und will seinen über Jahre antrainierten Wasserfall-Stil von Heute auf Morgen aufgeben und sich um 180° wenden.

Streben nach Perfektion


Der Entwickler ist faul - wird immer behauptet. Daraus ließe sich ableiten, dass er von Haus aus versucht den idealen Weg zu finden, seine Arbeit zu lösen. Lieber einmal kurz und knackig implementieren, als ständig Fehler beheben zu müssen. Lieber mit Testing arbeiten und sich so absichern. Lieber Tools verwenden, die sich aktuelle Paradigmen zu Nutze machen und die Arbeit erleichtern. Alles logische und nachvollziehbare Punkte. Was aber, wenn die Faulheit in die andere Richtung ausschlägt?

Verbesserungsmöglichkeiten?


Eine fehlende Grund-Motivation kann man keinem Entwickler einpflanzen. Aber dem Gewillten kann man den Weg ebnen. Vielleicht wäre es also ganz gut, sich darüber Gedanken zu machen, wie man denn unbedarfte Software-Entwickler erfolgreich, ohne allzu große Hürden auf diesen Weg bringt. Der von Alex aufgezeigte Weg ist sicherlich einer, den doch einige von uns gegangen sind. Aber ist er nicht zu steinig?

Daher meine abschließende Frage: Gibt es überhaupt einen einfachen Weg, das Verständnis und die Bereitschaft zu agilem Denken zu schaffen, oder kann dieser Weg nur vom Entwickler selbst eingeschlagen werden?

  2 Kommentare - 424 mal angesehen   |  2 Trackbacks   |  Permalink  |  Trackback-URL


Prozessoptimierung par excellence

03.12.08 - Kunterbunt
Beitrag von Norbert Eder
 Nahezu jeder Prozess kann optimiert werden. Was aber passiert, wenn einer absolut getuned wurde?

Mir gerade passiert:
  • Ich gehe in mein "Spiel-Zimmer".
  • Schalte die PS3 ein
  • Schalte den Fernseher ein
  • Nehme den Stromverteiler
  • Stecke den Verteiler an
  • Setze mich auf die Couch
  • *wart*
  • *wart*

Tja, da ist man ein wenig umweltbewußt und steckt schön brav alles aus, vergisst aber, dass man den Geräten zuerst Strom geben sollte, bevor man sie einschalten kann und wundert sich dann, warum sie zwar alle auf Standby gehen, aber nicht vor Freude losstarten.

Der Prozess wurde wohl zu sehr optimiert ... also doch wieder ein, zwei Schritte mehr machen.

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL



Zurück Weiter