Portraitfoto pimpen

In der aktuellen c’T lag unter anderem eine Vollversion des Programms Portrait Professional in der Version 6 bei. Da ich ein paar Minuten Zeit hatte, habe ich einfach mal ausprobiert, was das Programm mit meinem Gesicht anstellt:)
paul_verschoenern1
Zuerst einmal muss man die genaue Position von Augen, Nase, Mund und Kinn festlegen. In der vorliegenden Version ist das Programm nicht in der Lage, das selbst zu erkennen. Es können dann verschiedene Profile gewählt oder die einzelnen Parameter detailliert selbst gesetzt werden. Den Rest übernimmt die Software – manuelles Retouchieren ist hier nicht nötig oder vorgesehen.
vorher_nachher_dramatisch
Links das Original, rechts das bearbeitete Bild

Ergebnisse

Voreinstellung Aussehen männnlich
aussehen_m
Voreinstellung Glamour
dramatisch
Manuell, insbesondere starke Korrektur im Augenbereich.
manuell

Hautunreinheiten werden ganz gut weggebügelt, aber irgendwie bekommt man doch einen ganz schönen Plastik-Look durch die Filter. Mir gefällt das Original ehrlich gesagt besser:D

EADD 2009

Der Eclipse Application Developer Day fand gestern in Ettlingen bei Karlsruhe statt. Gastgeber war die Softwarefirma Silverstroke, die in einem architektonisch modernen und sehr offenen Gebäude residiert.
Silverstroke Office
Arne, Teamkollege bei der FTG und seit Anfang Juli Praktikant bei meinem Arbeitgeber HighQ-IT, und ich sind morgens um 6 Uhr 50 vom Hauptbahnhof Frankfurt losgefahren, um pünktlich bei der Veranstaltung anzukommen.

Paul-Gabriel Müller and Arne
Insgesamt haben wir uns 7 Vorträge und eine Panel-Diskussion angehört, bevor wir die Heimreise angetreten haben. Im Nachhinein denke ich, wir hätten vielleicht etwas länger bleiben sollen, um nach den Vorträgen noch ein paar Kontakte zu anderen Eclipse-Entwicklern zu knüpfen. Beim nächsten Mal 😉

Die Vorträge wurden fast alle auf deutsch gehalten, während die Folien auf englisch waren. Diese Kombination ist nicht ungewöhnlich und habe ich schon zu seligen Studien-Zeiten kennengelernt.
Als kleine Gedächtnisstütze für mich selbst und evtl. meine Kollegen werde ich zu jedem der Vorträge einen kurzen Satz schreiben.

  • Jochen Krause, EclipseSource / Harald Mueller, SAP: Keynote – Eclipse Runtime: Business Ready Open Source
    Besprochen wurde die zunehmende Verbreitung von OSGi auf Servern, die es ermöglicht, die Eclipse-Plattform nicht nur in GUI-Applikationen auf dem Client, sondern auch für Server-Anwendungen („Headless“ = ohne UI) einzusetzen. Darüber hinaus wurde ein grober Überblick über verschiedene Themen wie Equinox als „Kernel“ von Eclipse und Projekte wie Jetty oder RAP gegeben.
  • Leif Frenzel, andrena objects / Stefan Schürle, andrena objects: Gekonnt tranchieren, ansprechend garnieren und maßvoll würzen …
    In diesem Vortrag ging es um die Organisation von Plugins bei größeren Projekten. Hängen geblieben sind neben den vielen Fotos von Nahrungsmitteln auf den Vorlesungsfolien bei mir, dass man möglichst „Extension Points“ nutzen sollte, seine Plugins besser nach Funktionalität als nach technischen Gesichtspunkten trennen sollte (Gutes Beispiel: Ein Plugin für Versionskontrolle und eins für Java-Entwicklung. Schlechtes Beispiel: Ein Plugin für Views und eins für Actions). Außerdem wurde empfohlen, lieber mehrere ViewParts und EditorParts mit klar abgesteckten Aufgaben zu erstellen, statt alles in einer komplexen Mega-View zu behandeln. Zur Kommunikation zwischen den Views sollten SelectionServices eingesetzt werden. Abschließend wurde über die „innere Softwarequalität“ und das Tool ISIS gesprochen. Ein sehr gelungener Vortrag.
  • Jens Kübler, aquintos: Automatisierte GUI Tests mit SWTBot :
    Mit SWTBot lassen sich in Eclipse grafische Oberflächen (UI = User Interface) automatisch testen. Hervorgehoben wurde, dass es sich nicht um aufgezeichnete Tests handelt, die von Testexperten wegen ihrer geringen Flexibilität abgelehnt werden, sondern um welche, die programatisch erzeugt werden. SWTBot bietet eine große Auswahl von Methoden an, um Interaktionen wie das Anklicken eines Menüpunkts zu modellieren und die Ergebnisse zu testen. Das Projekt befindet sich noch in der „Incubator“-Phase, ist also für den Produktiveinsatz noch nicht unbedingt reif.
  • Dr. Frank Gerhardt, Gerhardt Informatics Kft.: Eclipse Data Binding — updating RCP Mail 2.0 (PDF)
    RCP Mail ist das Standard-Tutorial zum Lernen der RCP-Entwicklung. Frank Gerhardt hat die neue Version vorgestellt. Hervorgehoben wurde, dass es sich um eine Art Copy&Paste-Vorlage handelt, und deswegen sehr darauf geachtet wurde, es „richtig“ zu machen.
  • Benjamin Muskalla, EclipseSource: „Single Sourcing RCP and RAP“ – Desktop and web clients from a single code base
    Sehr beeindruckend fand ich diesen Vortrag:

    Chris Aniszczyk:
    “Cool, one runtime to rule them all”

    RAP (Rich Ajax Platform) erlaubt es, mit einigen Anpassungen, RCP-Applikationen in Web-Anwendungen in HTML und Javascript umzuwandeln. Dabei wird die gesamte Arbeit am Server gemacht, der Client braucht nur noch einen Webbrowser, um die Anwendung nutzen zu können.

  • Hans-Joachim Brede, BREDEX: Automated functional testing with keywords
    Der zweite Vortrag zum Thema „Tests“ beschäftigt sich ausdrücklich mit funktionalen Tests, bei denen es im Gegensatz zu Unit Tests nicht darum geht zu testen, ob ein kleines Stück Code so funktioniert, wie der Programmierer es erwartet, sondern darum, ob das Gesamtprogramm sich gemäß der Spezifikation verhält. Hans-Joachim Brede verfolgt dabei einen pragmatischen Ansatz und sagt, dass zuerst einmal der „Happy Path“ getestet werden muss, also dass das Programm bei korrekter Benutzung funktioniert, und das Testfälle explizit nicht von Entwicklern, sondern von den Testern geschrieben werden sollten. Im Prinzip kann das von ihm vorgestellte „Keyword-driven Testing“ also den Testern manuelle Arbeit abnehmen, wenn sie in der Lage sind, ein wenig Code zu schreiben.
  • vortrag_e4
    Thomas Schindl, BestSolution.at: The Modeled UI in Eclipse e4
    In breitem Schwytzerdeutsch referierte Thomas Schindl über e4, bei dem es sich mehr oder weniger um ein Rewrite der Eclipse-Plattform (Aktuelle Version: 3.5, Codename Galileo) handelt. Lästiger und im Regelfall überflüssiger Legacy Code kann hier endlich über Bord geworfen werden, und einige umständliche Konventionen, z.B. die Notwendigkeit, selbst bei simplen Applikationen eine Perspektive definieren zu müssen, können durch einfacherere Vorgehensweisen ersetzt werden. Außerdem wird statt der teilweise sehr komplexen Vererbungsstruktur in Eclipse mehr mit Injection gearbeitet, um Funktionalität wiederzuverwenden.

Die Verpflegung während der Veranstaltung war reichlich, und die leeren Teller mit leckerem Kuchen wurden ständig durch volle ersetzt. Glücklicherweise konnte ich meinen Appetit noch halbwegs im Zaum halten:) Insgesamt war es eine sehr gelungene Veranstaltung, die ich auf jeden Fall wieder besuchen würde.

Das Buffet in den Vortragsräumen wurde ständig wieder aufgefüllt

Das Buffet in den Vortragsräumen wurde ständig wieder aufgefüllt

Der Bahnhof von Karlsruhe, übrigens Bahnhof des Jahres 2008, wurde von mir auch noch fotografiert:
karlsruhe_bahnhof
karlsruhe_bahnhof2
Abschließend noch ein Foto von der „S-Bahn“ in Karlsruhe. Sieht eher aus wie eine Straßenbahn, und fährt auch auf der Straße. Und es gibt gar keine Türen links in diesen Bahnen, was ja auch eher ungewöhnlich ist.
s-bahn_karlsruhe
So sieht übrigens der Fußboden in den Bahnen aus (Ooh-Kay, ich bin einfach aus Versehen auf den Auslöser gekommen^^)
fuesse

Profiling & Performance – Tuning bei RCP-Anwendungen

eclipse
Die RCP-Anwendung, an der ich auf der Arbeit programmiere, reagiert bei größeren Dateien mit einer gewissen Behäbigkeit auf Tastatureingaben. Und wenn der Rechner langsam genug und die Dateien groß genug sind, verlieren auch weniger ungeduldige Leute als ich ihre Nerven. Es war also nach sieben Monaten mal nötig, sich intensiver mit der Performance unserer Applikation zu beschäftigen. Warum wir das nicht schon viel früher gemacht haben?

“The First Rule of Program Optimization: Don’t do it. The Second Rule of Program Optimization (for experts only!): Don’t do it yet.” – Michael A. Jackson (Nein, nicht der Thriller-MJ. RIP :-()

oder auch

„We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.“ (Donald Knuth)

Aber nun war es doch mal nötig, sich damit zu beschäftigen. Einfach drauflos zu optimieren hat natürlich keinen Sinn, man muss zuerst einmal wissen, welche Abschnitte wirklich Zeit kosten. Dabei können einem Profiler-Tools helfen. Wir haben TPTP eingesetzt, um einen Eindruck davon zu bekommen, in welchen Methoden unser Programm einen Großteil seiner Zeit verbringt.
tptp_options
Standardmäßig ignoriert TPTP dabei unter anderem alle Pakete, die mit „org“ beginnen, was in unserem Fall nicht so erwünscht war. Eine zusätzliche Regel, die Pakete unter „org.eclipse.jst.pagedesigner“ explizit miteinzubeziehen, hat dieses Problem für uns gelöst. Da der Overhead für diese Analysen zur Laufzeit enorm ist, ist es allerdings schon sinnvoll, nur innerhalb der Klassen zu testen, an die man wirklich heran kommt. So konnten wir herausfinden, dass der Großteil der Laufzeit beim Einfügen von Zeichen für Code draufgeht, der sich um das Synchronisieren der grafischen Darstellung und die Validierung der Eingabeposition kümmert. Bei der weiteren Entwicklung hat es sich dann als nützlich erwiesen, mit folgendem Code zu prüfen, welche Methoden innerhalb einer offenbar aufwändigen Methode den Großteil der Arbeitszeit in Anspruch nehmen. Denn nur an diesen Stellen möchte man überhaupt etwas ändern. Schließlich bringt jede Änderung das Risiko mit sich, irgendetwas kaputt zu machen;-)


long time = System.currentTimeMillis();
doSomething();
System.out.println("doSomething: "+(time-System.currentTimeMillis()));
time = System.currentTimeMillis();
doSomethingElse();
System.out.println("doSomethingElse: "+(time-System.currentTimeMillis()));

Ein weiteres nettes Tool zum profilen von Java-Applikationen ist visualVM, dass von Sun mit dem JDK mitgeliefert wird. Damit kann man bereits laufende Java-Anwendungen unter die Lupe nehmen. Leider lief es in unserem speziellen Fall nicht schnell genug und lieferte keine relevanten Ergebnisse, aber für viele einfacher aufgebaute Java-Anwendungen ist das eine gute Option.visualvm

Mit Hilfe der Werkzeuge und einigen Aussparung von vermeintlich überflüssigem Code konnten wir die Eingabegeschwindigkeit vielfach erhöhen. Bevor wir diese Änderungen ausliefern, werden wir aber lieber testen, ob wir wirklich nichts kaputt gemacht haben…

Frankfurt-Fotos

Ich war am Wochenende wieder viel mit dem Rad in Frankfurt und Umgebung unterwegs. Am Samstag bin ich nach Offenbach gefahren, und am Sonntag nach Eschborn. Dabei habe ich ein paar Fotos gemacht, die eine Seite von Frankfurt zeigen, die man so nicht auf jeder Postkarte finden würde.
Der Fluss im ersten Bild ist übrigens die Nidda, nicht etwa der Main. Wie der Bach auf dem einen Bild heißt, weiß ich allerdings nicht zu sagen…

an_der_nidda
natur_frankfurt
wald_ffm

Die folgenden drei Photos sind alle in Offenbach entstanden.
wald_offenbach
wald_offenbach3
wald_offenbach2

C++ in Visual Studio

Joel Spolsky, den ich wohl als einen meiner Vorbilder bezeichnen würde, hat mehr als einmal geschrieben, dass er das Sich-Herumplagen mit Pointern und Speicherverwaltung und dem ganzen Low-Level Zeug, mit dem ich mich als verwöhntes Java-Kid nicht wirklich beschäftigen muss, für eine gute Methode hält, Computer besser zu verstehen. Wer will das nicht? 😉

Also habe ich mich mit dem Kerningham-Ritchie-Klassiker The C Programming Language beschäftigt, so wie ich es meistens tue: Voller Ungeduld die Seiten überfliegend, alle Übungsaufgaben auslassen und dann in der Mitte des Buches ganz die Motivation verlieren und nur noch die ersten Zeilen jedes Kapitels lesen. Weil es so schön war, und ich noch ein paar weitere komplizierte Konzepte oberflächlich ankratzen wollte, habe ich die gleiche Strategie bei Bruce Eckels „Thinking in C++“ angewandt. Ich glaube schon, dass ein paar Fetzen hängengeblieben sind, aber noch mehr ist sicherlich an mir vorbeigerauscht.

Ich lerne wahrscheinlich besser, wenn ich selber machen kann. Herumspielen mit dem Compiler ohne klares Ziel will ich aber auch nicht, schließlich will ich ja total produktiv sein. Also habe ich mir ein winziges Projekt vorgenommen habe, um ein bisschen zu üben. Und um nachher sagen zu können, eine Anwendung in C++ geschrieben zu haben. Dazu später mehr.

Als Entwicklungsumgebung habe ich mich für Microssofts Visual Studio Express entschieden. Es ist natürlich ungerecht, weil ich Eclipse schon seit Jahren benutze und ich damit mittlerweile wirklich gut umgehen kann, aber Eclipse ist IMO einfach die bessere IDE. Und Java mag ich definitiv lieber als C++. Alleine das man beim C/C++-Entwickeln ständig manuell den Compiler anschmeißen muss, um simpelste Syntax-Fehler zu entdecken, nervt schon etwas. Und ich mache (noch) wahnsinnig viele Syntax-Fehler;)

Auch wenn es also wahrscheinlich nicht die große Liebe wird, möchte ich doch zumindest ein paar weitere oberflächliche Eindrücke sammeln und darüber schreiben, bevor ich mich wieder in das warme Java-Nest lege;)

Namen von Member-Variablen

Wenn man mal über einige Coding-Konventionen nachdenkt, die sich in den letzten 40 Jahren so etabliert haben, wird man feststellen, dass einige davon sich in Zeiten leistungsfähiger IDEs wie Eclipse wohl einfach überlebt haben. Zum Beispiel ist es in der OOP(Objekt-oprientierten Programmierung) in C++ wohl üblich, Member-Variablen (Also Variablen, die einer Instanz einer Klasse „gehören“, und folglich nicht nur innerhalb einer Methode, sondern in allen Methoden der Klasse genutzt werden können) mit einem führenden Unterstrich oder m_ zu beginnen.

private String _name;

In Java gibt es diese Coding-Convention nicht. Dort wird von der Verwendung von Underscores in Namen mit Ausnahme von Konstanten, die ja ganz in Großbuchstaben geschrieben werden sollten und wo camelCase deswegen nicht möglich ist, eher abgeraten. Und dem Programmierer gehen trotzdem keine Informationen verloren, da die Variablen in Eclipse einfach durch die farbliche Hervorhebung zugeordnet werden können. Ähnlich ist es bei den typischenZeilenFüllendenJavaVariablenNamensBezeichnernMitHoffentlich-DesktiptivemNamenKommaDieManSoWohlEherVermeidenWuerde-WennEsKeinCodeCompletionUndStaendigeCompileChecksGaebe. Gibt es aber. Also warum sollte man sich mit kryptischen Abkürzungen abgeben. Wer weiß schon wirklich, was tzfjvnbmhdnkdmswevwwekccusccg bedeuten soll?

Die Möglichkeit guten IDE-Support zu ermöglichen, ist meiner Meinung nach eines der wichtigsten Charakteristika von Programmiersprachen. Und hier steht Java im Vergleich zu fast allen anderen Sprachen sehr gut da, was meiner Meinung nach ein unterschätzter Grund für die Popularität der Sprache ist.

Zurück zum Thema: Ich werde jedenfalls in Zukunft solche Namenspräfixe nur nutzen, wenn es durch Guidelines im Projekt vorgeschrieben wird. Am Wichtigsten ist in der Hinsicht natürlich Konsistenz. Lieber ein schlechter Coding-Standard als gar keiner. Und wenn wir schon dabei sind: Lieber kein Coding-Standard als kein lauffähiges Programm;)

Was für wirres, unverständliches Zeug. Naja über sowelche Themen denke ich dann nach, lasse alle Zwischenschritte zum Verständnis weg und übrig bleiben wirre, zusammenhanglose Statements. Aber es kommt auch wieder leichtere Kost 😉

SWT Widgets

Um GUIs mit SWT zu bauen, muss man die einzelnen Widgets kennen. Unter eclipse.org/swt/widgets/ habe ich eine praktische Übersicht der vorhandenen Widgets gefunden. Zusammen mit der Javadoc-Referenz zu Eclipse hat man bereits eine Menge an Informationen.

Übrigens: Wenn man ein Layout wie etwa GridLayout zur Ausrichtung der einzelnen Objekte nutzt, funktioniert setSize() für einzelne Widgets nicht. Sollte man besser wissen…