Erste Gehversuche mit Kotlin

Moved to Google+: https://plus.google.com/+StefanDiener222/posts/Srug9CvmBTm

Kotlin in Action

Moved to Google+: https://plus.google.com/+StefanDiener222/posts/aUsYYNr58fv

Lessons in App Building

Lessons in App Building (from Entrepreneur August 2012)

Android: Screen Densities, Sizes, Configurations, and Icon Sizes

1. Definitions

• resolution = number of pixels available in the display, scale-independent pixel = sp
• density = how many pixels appear within a constant area of the display, dots per inch = dpi
• size = amount of physical space available for displaying an interface, screen's diagonal, inch
• density-independent pixel = virtual pixel that is independent of the screen density, dp

2. Density Classes

Class	Name	Density	Factor	Drawable Folder	Comment
ldpi	low density	120 dpi	sp = 3/4 * dp	drawable-ldpi
mdpi	medium density	160 dpi	sp = dp	drawable-mdpi OR drawable	baseline size, example: 320x480 (sp or dp)
hdpi	high density	240 dpi	sp = 1.5 x dp	drawable-hdpi	example: 480x800 sp = 320x533 dp
xhdpi	extra high density	320 dpi	sp = 2 x dp	drawable-xhdpi
xxhdpi	extra extra high density	480 dpi	sp = 3 x dp	drawable-xxhdpi
xxxhdpi	extra extra extra high density	640 dpi	sp = 4 x dp	drawable-xxxhdpi

3. Icon Sizes (full / content)

Density	Launcher	Menu	Action Bar	Status Bar and Notification	Tab	Pop-up Dialog and List View	Small and Contextual
ldpi	36x36 px	36x36 / 24x24 px	24x24 / 18x18 px	18x18 / 16x16 px	24x24 / 22x22 px	24x24 px	12x12 / 9x9 px
mdpi	48x48 px	48x48 / 32x32 px	32x32 / 24x24 px	24x24 / 22x22 px	32x32 / 28x28 px	32x32 px	16x16 / 12x12 px
hdpi	72x72 px	72x72 / 48x48 px	48x48 / 36x36 px	36x36 / 33x33 px	48x48 / 42x42 px	48x48 px	24x24 / 18x18 px
xhdpi	96x96 px	96x96 / 64x64 px	64x64 / 48x48 px	48x48 / 44x44 px	64x64 / 56x56 px	64x64 px	32x32 / 24x24 px
xxhdpi	144x144 px	(1)	(1)	(1)	(1)	(1)	(1)
xxxhdpi	192x192 px	(1)	(1)	(1)	(1)	(1)	(1)

• (1) Google documentation says: "Applications should not generally worry about this density; relying on XHIGH graphics being scaled up to it should be sufficient for almost all cases."
• Launcher icons for Android Market: 512x512 px.

4. Screen Size Classes

Class	Size in dp	Layout Folder	Examples	Comment
small	426x320 dp	layout-small	typical phone screen (240x320 ldpi, 320x480 mdpi, etc.)
normal	470x320 dp	layout-normal OR layout	typical phone screen (480x800 hdpi)	baseline size
large	640x480 dp	layout-large	tweener tablet like the Streak (480x800 mdpi), 7" tablet (600x1024 mdpi)
xlarge	960x720 dp	layout-xlarge	10" tablet (720x1280 mdpi, 800x1280 mdpi, etc.)

• valid for Android 3.1 and older
• for Android 3.2 and newer see: Declaring Tablet Layouts for Android 3.2

5. Example Screen Configurations

Screen Size	Low density (120), ldpi	Medium density (160), mdpi	High density (240), hdpi	Extra high density (320), xhdpi
small	QVGA (240x320)		480x640
normal	WQVGA400 (240x400) WQVGA432 (240x432)	HVGA (320x480)	WVGA800 (480x800) WVGA854 (480x854) 600x1024	640x960
large	WVGA800 (480x800)(2) WVGA854 (480x854)(2)	WVGA800 (480x800)(1) WVGA854 (480x854)(1) 600x1024
xlarge	1024x600	WXGA (1280x800)(3) 1024x768 1280x768	1536x1152 1920x1152 1920x1200	2048x1536 2560x1536 2560x1600

• (1) To emulate this configuration, specify a custom density of 160 when creating an Android Virtual Device that uses a WVGA800 or WVGA854 skin.
• (2) To emulate this configuration, specify a custom density of 120 when creating an Android Virtual Device that uses a WVGA800 or WVGA854 skin.
• (3) This skin is available with the Android 3.0 platform.

6. Screen Orientation

Orientation	Name	Layout Folder, Example
port	portrait	layout-port-large
land	landscape	layout-land-normal OR layout-land

7. Best Practices

1. Use wrap_content, match_parent, or dp units when specifying dimensions in an XML layout file.
   • except for defining text sizes: sp (scaling depends on user setting)
   • Note: fill_parent is deprecated since API level 8.
2. Do not use hard coded pixel values in your application code.
3. Do not use AbsoluteLayout.
   • deprecated since Android 1.5
   • alternative: RelativeLayout
4. Supply alternative bitmap drawables for different screen densities.
5. Provide a launcher icon for xxhdpi, but no other icons.

8. References

• New Tools For Managing Screen Sizes, Android Developers Blog
• Supporting Multiple Screens, Android Developers Guide
• Declaring Tablet Layouts for Android 3.2, Android Developers Guide
• Providing Alternative Resources, Android Developers Guide
• How Android Finds the Best-matching Resource, Android Developers Guide
• Android Design
• Iconography, Android Design
• Designing for Multiple Screens, Android Developers Training
• Platform Versions, Android Developers Device Dashboard
• Nick Butcher: Nexus 10 launcher icons
• List of Android Devices with pixel density buckets

Google Retail Store

The Google Retail Store is located on the Google Campus in Mountain View at 2000 Charleston Road. The store is NOT open to the public, it's for Googlers and their guests only. No tailgating. No cash accepted, credit cards and Google Wallet only.

WGS84 coordinates: N37.422722 W122.088223

If you cannot find a Googler to invite you, watch the video instead (thanks to asypta):
http://www.youtube.com/watch?v=17VHr6rsPAw

Some more pictures of the store: http://mithun.com/projects/project_detail/technologycompany_store/

When you visit the Google Campus, don't miss the Android sculptures in front of Building 44, at 1625 Charleston Road.

Google Building 44

Android Lint und Jenkins / Hudson

Um die Warnungen von Android Lint in Jenkins (oder Hudson, wenn man mag) anzuzeigen, ist ein wenig Konfigurationsaufwand notwendig, siehe hier:
http://stackoverflow.com/questions/8745949/display-android-lint-results-in-jenkins

Probleme beim Bauen von Android-Projekten unter Ubuntu?

Dann könnte dieser Artikel sehr hilfreich sein:
http://polywogsys.livejournal.com/286952.html

Clean Code Developer: 3. Gelber Grad - Zusammenfassung

Also, dann auf zum dritten Grad...

1. Prinzipien

1.1 Interface Segregation Principle

Warum? Leistungsbeschreibungen, die unabhängig von einer konkreten Erfüllung sind, machen unabhängig.

• Interfaces sollten möglichst klein sein, um unnötige Kopplung zu vermeiden.
• Interfaces sollten nur Dinge enthalten, die wirklich eng zusammen gehören (hohe Kohäsion).
• Ziel: möglichst geringe Kopplung ziwschen den Komponenten

1.2 Dependency Inversion Principle

Warum? Punktgenaues Testen setzt Isolation von Klassen voraus. Isolation entsteht, wenn Klassen keine Abhängigkeiten von Implementationen mehr enthalten – weder zur Laufzeit, noch zur Übersetzungszeit. Konkrete Abhängigkeiten sollten deshalb so spät wie möglich entschieden werden. Am besten zur Laufzeit.

• High-Level Klassen sollen nicht von Low-Level Klassen abhängig sein, sondern beide von Interfaces.
• Interfaces sollen nicht von Details abhängig sein, sondern Details von Interfaces.
• Mindestanforderung im 3. Grad: Abhängigkeiten über Konstruktoren injizieren

1.3 Liskov Substitution Principle

Warum? Wer mit Erben zu tun hat, möchte keine Überraschungen erleben, wenn er mit Erblassern vertraut ist.

• Kernaussage: Subtypen müssen sich so verhalten wie ihr Basistyp
• allgemeiner: ein Subtyp darf die Funktionalität eines Basistyps lediglich erweitern, aber nicht einschänken
• Empfehlung: über Vererbung genau nachdenken
  
  • siehe Favor Composition over Inheritance (FCoI), roter Grad
  • bei Vererbung über Verhalten nachdenken, nicht nur über Struktur

1.4 Principle of Least Astonishment

Warum? Wenn sich eine Komponente überraschenderweise anders verhält als erwartet, wird ihre Anwendung unnötig kompliziert und fehleranfällig.

• Software sollte überraschungsarm implementiert sein. Jede Überraschung stellt eine Unterbrechung dar und stört den kreativen Prozess der Softwareentwicklung.
• Die testgetriebene Entwicklung fördert überraschungsarme Schnittstellen.

1.5 Information Hiding Principle

Warum? Durch das Verbergen von Details in einer Schnittstelle werden die Abhängigkeiten reduziert.

• Je mehr Details von außen sichtbar sind, desto höher ist die Kopplung zwischen der Klasse und ihren Verwendern.
• Benutzen die Verwender einer Klasse erstmal ein Detail, wird es schwerer, dieses Detail zu verändern.

2. Praktiken

2.1 Automatisierte Unit-Tests

Warum? Nur automatisierte Tests werden auch wirklich konsequent ausgeführt. Je punktgenauer sie Code testen, desto besser.

• Regressionstests, um Korrektheit von Änderungen sicherzustellen und Angst vor Änderungen zu nehmen
• Automatisierung notwendig, da händisch nicht praktikabel
• Automatisierte Tests sparen Zeit und nehmen Angst.

2.2 Mockups (Testattrappen)

Warum? Ohne Attrappen keine einfach kontrollierbaren Tests.

• Will man eine Komponente isoliert testen, müssen die Abhängigkeiten zu anderen Komponenten abgetrennt werden.
• Beim Isolieren werden sogenannte Mockups anstelle der echten Komponenten verwendet.
• andere Bezeichnungen für Attrappen: Stub, Dummy, Fake (teilweise mit unterschiedlichen Funktionsweisen)

2.3 Code Coverage Analyse

Warum? Traue nur Tests, von denen du weißt, dass sie auch wirklich das Testareal abdecken.

• Unit Tests sollten nach Möglichkeit alle Pfade durch unseren Code abdecken.
• Die Code Coverage Analyse dient dazu, Bereiche im Code aufzudecken, die noch nicht während der automatisierten Tests ausgeführt werden.
• Mögliche Metriken:
  
  • C0-Überdeckung = Anweisungsüberdeckung
  • C1-Überdeckung = Entscheidungs- / Zweigüberdeckung
• Ziel: theoretisch 100% Überdeckung, praktisch mehr als 90% Überdeckung

2.4 Teilnahme an Fachveranstaltungen

Warum? Am besten lernen wir von anderen und in Gemeinschaft.

• Gedankenaustausch, Diskussionen, Erfahrungen austauschen, "über den Tellerrand blicken"
• z.B. regionale User Groups, überregionale Entwicklerkonferenzen

2.5 Komplexe Refaktorisierungen

Warum? Es ist nicht möglich, Code direkt in der ultimativen Form zu schreiben.

• Erweiterung zum roten Grad
• unbedingte Voraussetzung: automatisierte Tests

Clean Code Developer: 2. Oranger Grad - Erfahrungen

Puhhh, der orange Grad hat sich sehr in die Länge gezogen. Nicht etwa weil ich ständig das Armband auf die andere Seite hätte wechseln müssen, sondern eher weil ich so wenig zum Programmieren gekommen bin. Zum Jahresende 2010 war's dann endlich geschafft und schon Anfang Februar 2011 komme ich dazu, den Blog nachzuziehen. Eine Zusammenfassung der Prinzipien und Praktiken sind in meinem Post vom 07. Juni 2010 zu finden. Hier meine Erfahrungen und Meinungen...

3. Ergebnisse
3.1 Single Level of Abstraction (SLA)

• Status: gelb
• Meine Meinung: Beachte ich meist "aus dem Gefühl heraus". Dieses Prinzip muss ich in Zukunft noch mehr verinnerlichen.
• Erkenntnisse:
  
  • Eine manuelle Überprüfung, ob dieses Prinzip eingehalten wurde, ist sehr mühselig. Eine automatische Überprüfung ist unmöglich.
  • Man sollte beim Lesen einer Methode auf sein Bauchgefühl hören und bei Bedarf dann genauer hinsehen, ob SLA eingehalten wurde.
    

3.2 Single Responsibility Principle (SRP)

• Status: grün
• Meine Meinung: Im Tagesgeschäft beachte ich diese Regel. Immer, wenn ich neue Funktionalität zu einer Klasse hinzufüge, frage ich mich vorher, ob dies noch zur Aufgabe der Klasse gehört oder nicht.
• Erkenntnisse:
  
  • Natürlich ist man manchmal versucht, noch eine "Kleinigkeit" zu einer Klasse hinzuzufügen, aber hier muss man Disziplin wahren...

3.3 Separation of Concerns (SoC)

• Status: gelb
• Meine Meinung: Ich achte insgesamt stärker auf die Einhaltung von SoC. Manchmal ist es nicht einfach, die verschiedenen Belange sauber zu trennen, so dass ich in berechtigten Fällen durchaus der pragmatischeren Lösung den Vorzug gebe.
• Erkenntnisse:
  
  • Die Aspektorientierte Programmierung scheint hier das Mittel der Wahl zu sein.
  • Meine persönlichen Erfahrungen mit der AOP waren bisher allerdings eher ernüchternd bis frustrierend. Die Integration in die Eclipse IDE funktionierte nicht richtig und das Zusammenspiel mit RCP bzw. OSGi ist ein einziger Alptraum. Natürlich gibt's da haufenweise tolle Präsentationen von smarten Consultants zu dem Thema, aber ich halte die Kombination RCP / OSGi / AOP im Moment nicht für praxistauglich.

3.4 Source Code Konventionen

• Status: grün
• Meine Meinung: Code-Konventionen sind vorhanden und werden seit längerer Zeit schon angewendet. Es existiert ein schriftliches Regelwerk plus Konfigurationen für Checkstyle und PMD. Beide Tools werden sowohl in der Eclipse IDE, als auch im Nightly Build ausgeführt.

3.5 Issue Tracking

• Status: grün
• Meine Meinung: Wird seit längerem bereits eingesetzt und hat sich ohne Frage bewährt.
• Tools:
  
  • früher Mantis, http://www.mantisbt.org/
  • aktuell Trac, http://trac.edgewall.org/
  • und die Tracker der SourceForge-Projekte

3.6 Automatisierte Integrationstests

• Status: gelb
• Meine Meinung: Automatisierte Integrationstest sind nur wenige vorhanden. Die Integrations- und Unit-Tests werden aktuell in den Nightly Build integriert.
• Tools:
  
  • Hudson, http://hudson-ci.org/
  • JUnit, http://www.junit.org/
  • Ant, http://ant.apache.org/
  • Eclipse Test Framework (ETF), http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.test/testframework.html?view=co
  • PDE Test Utilities, http://www.eclipse.org/articles/Article-PDEJUnitAntAutomation/index.html#PDE_Test_Utilities
• Erkenntnisse:
  
  • Seit Eclipse Helios wird JUnit 4 vom automatischen PDE-Build unterstützt.

3.7 Lesen, Lesen, Lesen

• Status: gelb
• Meine Meinung: Vom Java-Magazin und Eclipse-Magazin lese ich jede Ausgabe, Blogs nur bei Bedarf und Fachbücher max. 2 pro Jahr. Mehr ist zeitlich leider nicht drin.

3.8 Reviews

• Status: gelb
• Meine Meinung: Pair-Reviews sind bei mir nicht möglich. Direkt vor jedem Commit führe ich immer einen Review meines eigenen Codes durch, was sich sehr bewährt hat.

Zurück von der OOP 2011

Wow, nun ist sie leider schon wieder vorbei, die OOP 2011. Es wurde diesmal ein tolles Programm geboten, inklusive einige lebender Legenden, wie z.B. Erich Gamma, Martin Fowler, Tom DeMarco und Gunter Dueck. Spitze!

Clean Code Developer: 2. Oranger Grad - Zusammenfassung

Also, dann auf zum zweiten Grad...

1. Prinzipien
1.1 Single Level of Abstraction (SLA)

Warum? Die Einhaltung eines Abstraktionsniveaus fördert die Lesbarkeit.

• Variablenzuweisung = niedrigstes Abstraktionsniveau, Methodenaufrufe = höhere Abstraktionsniveaus, API-Aufrufe = sehr hohes Level
• Innerhalb einer Methode sollte nur ein Abstraktionsniveau verwendet werden, damit der Code gut lesbar und leicht zu verstehen ist.

1.2 Single Responsibility Principle (SRP)

Warum? Fokus erleichtert das Verständnis. Eine Klasse mit genau einer Aufgabe ist verständlicher als ein Gemischtwarenladen.

• Eine Klasse sollte nur einen Grund für Änderungen haben. Folglich übernimmt eine Klasse genau eine Aufgabe.
• Verletzung des Single Responsibility Principles führt zu Kopplung und erhöhter Komplexität

1.3 Separation of Concerns (SoC)

Warum? Wenn eine Codeeinheit keine klare Aufgabe hat ist es schwer sie zu verstehen, sie anzuwenden und sie ggf. zu korrigieren oder zu erweitern.

• Concerns (Belange) stehen orthogonal zueinander und zur Hauptfunktionalität, z.B. Tracing, Logging, Transaktionalität, Caching
• Concerns in verschiedene Code-Einheiten trennen, im Einklang mit dem Single Responsibility Principle, z.B. DB-Zugriffe von Geschäftslogik trennen
• SoC führt zu loser Kopplung, hoher Kohäsion und gut testbaren Komponenten

1.4 Source Code Konventionen

Warum? Code wird häufiger gelesen als geschrieben. Daher sind Konventionen wichtig die ein schnelles Lesen und Erfassen des Codes unterstützen.

• Namensregeln: Warum? Ohne Namensregeln muss man sich wieder und wieder auf den Stil einzelner Entwickler einstimmen.
• Richtig kommentieren: Warum? Unnötige oder gar falsche Kommentare halten beim Lesen auf. Der Code sollte so klar und deutlich sein dass er möglichst ohne Kommentare auskommt.

2. Praktiken
2.1 Issue Tracking

Warum? Nur, was man aufschreibt, vergisst man nicht und kann man effektiv delegieren und verfolgen.

• Nichts geht verloren, alle Punkte können priorisiert und sortiert werden.
• Tools:
  
  • Mantis, http://www.mantisbt.org/
  • Trac, http://trac.edgewall.org/
  • Bugzilla, http://www.bugzilla.org/
  • JIRA, http://www.atlassian.com/software/jira/
  • weitere...
    

2.2 Automatisierte Integrationstests

Warum? Integrationstests stellen sicher dass der Code tut was er soll. Diese wiederkehrende Tätigkeit nicht zu automatisieren wäre Zeitverschwendung.

• Regressionstests, um Korrektheit von Änderungen sicherzustellen und Angst vor Änderungen zu nehmen
• Automatisierung notwendig, da händisch nicht praktikabel
• Integrationstests oder noch besser Unit Tests durchführen (fernes Ziel: Test Driven Development)

2.3 Lesen, Lesen, Lesen

Warum? Lesen bildet!

• Ziel: immer den neuesten Stand der Entwicklung und der Techniken beobachten
• Vorschlag: mindestens 6 Fachbücher pro Jahr plus Fachzeitschriften und Blogs regelmäßig lesen

2.4 Reviews

Warum? Vier Augen sehen mehr als zwei. Wenn der eine Entwickler dem anderen seinen Code erklärt, tauchen meist Details auf, die bislang nicht bedacht wurden.

• als kontinuierlicher Prozess beim Pair Programming und/oder
• als eigenständiger Prozessschritt beim Code Review

Clean Code Developer: 1. Roter Grad - Erfahrungen

Meine 21 Tage im roten Grad sind heute zu Ende gegangen. Eine Zusammenfassung der Prinzipien und Praktiken sind in meinem Post vom 13. April 2010 zu finden. Hier meine Erfahrungen und Meinungen...

3. Ergebnisse
3.1. Don't Repeat Yourself (DRY)

• Status: grün
• Meine Meinung: Ich achte insgesamt stärker auf Copy&Paste. Wenn ich Code-Passagen kopieren möchte, überlege ich immer erst, ob sich das Kopieren nicht sinnvoll vermeiden lässt. Alternativen:
  
  • Code in gemeinsam benutzte Methode einpacken,
  • Code in gemeinsam benutzte Hilfsklasse extrahieren,
  • beide Code-Abschnitte zusammenfassen (Original und Kopie-Ziel).
• Tools: Zur automatischen Prüfung von DRY kommen zwei Tools in Frage:
  
  • CPD als Teil von PMD, http://pmd.sourceforge.net/cpd.html
  • Checkstyle, Regel "StrictDuplicateCode", http://checkstyle.sourceforge.net/
• Erkenntnisse:
  
  • Checkstyle-Regel "StrictDuplicateCode": Das Limit muss auf mindestens 24 Zeilen hochgesetzt werden (Default: 12 Zeilen), um keine Warnungen wegen des Copyright-Headers im Projekt LunaRCP zu bekommen. Folgende Dinge schränken jedoch die Benutzbarkeit stark ein:
    
    • Javadoc-Zeilen werden nicht ignoriert.
    • Es sind keine definierten Ausschlüsse möglich, wie z.B. bei PMD.
    • Die Prüfung ist nicht zuverlässig. Teilweise werden Code-Passagen auch nach Änderungen noch als dupliziert angezeigt. "Rebuild All" konnte das Problem nicht lösen.
  • Die Checkstyle-Regel "StrictDuplicateCode" wurde nach der Durchführung einiger Code-Verbesserungen wieder deaktiviert. Aber auch CPD bringt hier keine besseren (brauchbareren) Ergebnisse. Der automatisierte Einsatz im Nightly Build macht aus meiner Sicht derzeit keinen Sinn.

3.2. Keep it simple, stupid (KISS)

• Status: grün
• Meine Meinung: Ich liebe KISS! Und ich halte nicht viel von Lösungen, die unnötig kompliziert sind und z.B. Erweiterungspunkte auf Vorrat vorsehen, nur weil man sie ja vielleicht irgendwann in ferner Zukunft mal brauchen könnte.

3.3. Vorsicht vor Optimierungen!

• Status: grün
• Meine Meinung: Optimierungen führe ich grundsätzlich nur durch, wenn offensichtlich Bedarf besteht. Ich mag keine "Optimierung auf Vorrat". Zu jeder Optimierungsaktion gehört ein vorheriges CPU- und/oder Memory-Profiling.

3.4. Favour Composition over Inheritance (FCoI)

• Status: gelb
• Meine Meinung: Dieses Prinzip habe ich während des roten Grades nur selten angewandt, was aber sehr an den bearbeiteten Aufgabenstellungen lag (sehr wenig Neuentwicklungen). Dieses Prinzip muss ich in Zukunft noch mehr verinnerlichen.

3.5. Die Pfadfinderregel beachten

• Status: grün
• Meine Meinung: Im Tagesgeschäft beachte ich die Pfadfinderregel. Immer, wenn eine Code-Passage "komisch" aussieht, d.h. einen "smell" hat, verbessere ich den Code. Im roten Grad habe ich verstärkt auf DRY, KISS und FCoI geachtet.

3.6. Root cause analysis

• Status: grün
• Meine Meinung: Diese Regel beachte ich im Normalfall. Die Suche nach der wirklichen Ursache kostet langfristig gesehen viel weniger Zeit als die andauernden Workarounds.

3.7. Ein Versionskontrollsystem einsetzen

• Status: grün
• Meine Meinung: Subversion ist seit längerem im Einsatz, inkl. der Verwendung von Tags und Branches.

3.8. Erste Refaktorisierungsmuster anwenden

• Status: grün
• Meine Meinung: Verwende ich seit Ewigkeiten. Die am meisten verwendeten Refaktorisierungen der Eclipse IDE sind bei mir: "Methode extrahieren", "Klasse extrahieren", "Umbenennen", "Verschieben", "Konstante extrahieren", "Methoden-Signatur verändern".

3.9. Täglich reflektieren

• Status: grün
• Meine Meinung: Die tägliche Reflektion über die getane Arbeit musste ich mir erst angewöhnen. Ich sehe sie mittlerweile als ein gutes Mittel an, um sich direkt vor dem Feierabend nochmal zu fragen, was man heute alles erledigt hat und welche Punkte eventuell noch offen sind. Die offenen Punkte trage ich in meine persönliche To-Do-Liste für den nächsten Tag ein, damit ich mir die Dinge nicht merken muss (d.h. nicht in den Feierabend mit nach Hause nehme) und nichts vergesse.

10+1 things they never teach in college about programming

10+1 Dinge, die man nicht an der Uni oder FH lernt: http://www.dzone.com/links/r/101_things_they_never_teach_in_college_about_prog.html

Ja, so isses...

Neuer Artikel im Eclipse-Magazin

Im aktuellen Eclipse-Magazin (4.2010) ist mein zweiter Artikel zum Projekt LunaRCP erschienen: "Baumkunde für Einsteiger. Navigationsbäume mit LunaRCP erstellen".

BTW, den ersten Artikel hatte ich in Zusammenarbeit mit Manfred Novotny geschrieben. Er war bereits im Eclipse-Magazin 1.2010 erschienen: "Persistenzlego. Hibernate-Integration mit Eclipse RCP".

Clean Code Developer: Armbänder

Super, jetzt sind sie endlich da, die CCD-Armbänder. Bestellt am 1. April (kein Scherz!) und schon geliefert am 23. April.

Clean Code Developer: 1. Roter Grad - Zusammenfasung

"Mit dem roten Grad beginnt der Weg des Clean Code Developers. Ab hier gilt es, einen ersten Teil des CCD Wertesystems in die tägliche Arbeit einzubringen und immer wieder zu üben." Dann wollen wir mal starten...

1. Prinzipien
1.1. Don't Repeat Yourself (DRY)

"Warum? Jede Doppelung von Code oder auch nur Handgriffen leistet Inkonsistenzen und Fehlern Vorschub."

• Copy&Paste ist ein weit verbreitetes Anti-Pattern.
• Ziel: doppelten Code und andere Artefakte erkennen und
• Wiederholungen durch Refaktorisierungen entfernen (sofern nichts dagegen spricht).
• Tools:
• CPD als Teil von PMD, http://pmd.sourceforge.net/cpd.html
• Checkstyle, Regel "StrictDuplicateCode", http://checkstyle.sourceforge.net/
  

1.2. Keep it simple, stupid (KISS)

"Warum? Wer mehr tut als das Einfachste, lässt den Kunden warten und macht die Lösung unnötig kompliziert."

• Einstein: "Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher."
• Eine einfache, klare, leicht verständliche Lösung sollte immer bevorzugt werden.
• Praxis: Reviews und Pair Programming.
  

1.3. Vorsicht vor Optimierungen!

"Warum? Optimierungen kosten immer viel Aufwand. Wer Vorsicht walten lässt, spart oft wertvolle Ressourcen für das, was dem Kunden wirklich nützt."

• M.A. Jackson: Rules of Optimization:
• Rule 1: Don't do it.
• Rule 2 (for experts only): Don't do it yet.
• Verständlichkeit und Evolvierbarkeit vor (minimalen) Performance-Optimierungen.
• Optimierungen nur, wenn vom Kunden gefordert, vom Entwickler zweimal überlegt und mit Profiler-Analyse
  

1.4. Favour Composition over Inheritance (FCoI)

"Warum? Komposition fördert die lose Kopplung und die Testbarkeit eines Systems und ist oft flexibler."

• Gang of Four: "Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'."
• Vererbung: white box, Subklasse abhängig von Elternklasse
• Komposition: black box, klare Schnittstelle, bessere Entkopplung, leichtere Austauschbarkeit
  

2. Praktiken
2.1. Die Pfadfinderregel beachten

"Warum? Jede Beschäftigung mit einem Gegenstand macht ihn zumindest ein kleinwenig besser. Ganz ohne bürokratische Planung. Fundament und Graswurzelansatz für mehr Qualität."

• Pfadfinderregel: "Hinterlasse einen Ort immer in einem besseren Zustand als du ihn vorgefunden hast."
• Nach getaner Arbeit stimmt der Code mit dem Clean Code Development Wertesystem mehr überein als vorher.
• Anti-Pattern: Broken-Windows-Theorie (eine zerbrochene Fensterscheibe führt später zu völliger Verwahrlosung)
  

2.2. Root cause analysis

"Warum? Symptome behandeln bringt vielleicht schnell eine Linderung - langfristig kostet es aber mehr Aufwand. Wer stattdessen unter die Oberfläche von Problemen schaut, arbeitet am Ende effktiver."

• Immer nach der Ursache eines Problems suchen.
• Bei Kenntnis des Wurzelproblems ist die Bereinigung meist weniger aufwändig als eine Symptomkur.
  

2.3. Ein Versionskontrollsystem einsetzen

"Warum? Angst vor Beschädigung eines 'running system' lähmt die Softwareentwicklung. Mit einer Versionsverwaltung ist solche Angst unbegründet. Die Entwicklung kann schnell und mutig voranschreiten."

• Kein Kommentar!
• Tools:
• Subversion, http://subversion.apache.org/
• TortoiseSVN, http://tortoisesvn.tigris.org/
  

2.4. Erste Refaktorisierungsmuster anwenden

"Warum? Code verbessern ist leichter, wenn man typische Verbesserungshandgriffe kennt. Ihre Anwendungsszenarien machen sensibel für Schwachpunkte im eigenen Code. Als anerkannte Muster stärken sie den Mut, sie anzuwenden."

• vgl. Buch von Martin Fowler
• Refaktorisierungen für roten Grad: "Methode extrahieren" und "Umbenennen"
• Tool: Eclipse for RCP/Plug-in Developers, http://www.eclipse.org/
  

2.5. Täglich reflektieren

"Warum? Keine Verbesserung, kein Fortschritt, kein Lernen ohne Reflexion. Aber nur wenn Reflexion auch eingeplant wird, findet sie unter dem Druck des Tagesgeschäftes auch statt."

• Persönliche Entwicklung durch kleinschrittige Planung und Reflexion nach jedem Schritt.
• Die Arbeit so einteilen, dass sie aus Aufgaben besteht, die an einem Arbeitstag zu bewältigen sind.
• Die Arbeit nicht mit in den Feierabend tragen.

Clean Code Developer: 0. Schwarzer Grad

Manfred Novotny hatte mich im Januar auf diese tolle Homepage aufmerksam gemacht: Clean Code Developer. Ich kann nur sagen: eine Offenbarung! Endlich eine klare Ansage, was Professionalität in der Software-Entwicklung bedeutet / bedeuten kann / bedeuten könnte (je nach persönlichem Standpunkt). Ein nachvollziehbares und praktisch anwendbares Wertesystem für jeden Software-Entwickler. Obendrein wird eine Sammlung von Prinzipien und Praktiken angeboten, die in verschiedenen Stufen ("Graden") der Entwicklung zum "Clean Code Developer" erlernt und verinnerlicht werden können.

Ich finde das Ganze eine echt tolle Sache und habe deshalb beschlossen, mich ebenfalls auf den Weg zum "Clean Code Developer" zu machen. Gemäß den CCD-Graden befinde ich mich nun also im "Schwarzen Grad". Derzeit stehen dem Übergang zum "Roten Grad" noch einige administrative Aufgaben im Weg, die meine Zeit beanspruchen. Ich werde dann später für jeden CCD-Grad meine persönlichen Erfahrungen hier im Blog festhalten.

How to convert a Maven pom.xml into an Ivy ivy.xml file

If you're using Maven just for resolving dependencies, Ivy might be a good alternative for you. You may convert your pom.xml into an ivy.xml file using the following Ant script:

<project name="convertPomToIvy" basedir="." default="convert"
 xmlns:ivy="antlib:fr.jayasoft.ivy.ant"
 xmlns:ac="antlib:net.sf.antcontrib">

   <path id="antlib.classpath">
       <fileset dir="C:/Program Files/apache-ivy-2.1.0" includes="*.jar"/>
       <fileset dir="C:/Program Files/apache-ivy-2.1.0/lib" includes="*.jar"/>
   </path>

   <taskdef uri="antlib:fr.jayasoft.ivy.ant"
       resource="fr/jayasoft/ivy/ant/antlib.xml"
       classpathref="antlib.classpath"
       loaderref="antlib.classpath.loader"/>

   <target name="convert">
       <ivy:convertpom pomFile="pom.xml" ivyFile="ivy.xml" />
   </target>
</project>

Please note that you may want to adjust the paths to the Ivy JAR files.

Ranking: Popularität von Programmiersprachen

Ein sehr bekanntes Ranking zur Popularität von Programmiersprachen wird von der Firma Tiobe erstellt: http://www.tiobe.com/index.php/tiobe_index

Zurück von der W-JAX 2009

Die W-JAX 2009 in München war wirklich toll! Vielen Dank an die Organisatoren, Speaker und alle Besucher! Bis zum nächsten Jahr...