Dies ist die Heimat der Java User Group Nürnberg.


Sonntag, 13. Januar 2008

Hex and the City: Versionsaktualisierung

Hier meine erste Kolumne im dem kostenlosen Magazin KaffeeKlatsch. Wer die Zeitung noch nicht abboniert hat, kann hier lesen:

Hex and the City: Versionsaktualisierung

Zum Start möchte ich uns die Antwort auf alle Fragen, die in Zusammenhang mit dieser Kolumne auftreten, geben. 42. Diese Antwort ist natürlich nicht von mir. Aber ich denke (und hoffe), ich muss nicht erklären woher sie stammt.1 Nachdem wir uns jetzt auf den Umgang mit Fragen geeinigt haben, können wir beginnen. Immerhin ist der Fortschritt der Zeit zu konstant um Pausen einzulegen. Was gerade wir in unserer täglichen Arbeit stets beobachten. Kaum beenden wir ein Projekt – erfolgreich versteht sich2 - um in Produktion zu gehen mit der API ABC in Version 1.2.3 und dem Framework XYZ in Version 4.5.6, müssen wir feststellen (meist in einem kaffeebegleitenden Gespräch oder in einem Artikel), dass es ABC jetzt in Version 1.3.7 und XYZ in Version 5.0.b8 gibt. Außerdem heißt XYZ jetzt Xyzoon. Oder so ähnlich. Und alles andere zu benutzen gilt als nostalgisch. Nun gut, in manchen Bereichen bezeichne ich mich gern als klassisch, also nein, dass abgeschlossene Projekt wird nicht mehr geändert. Oder doch? Wie sollen wir mit Neuerungen umgehen? Entwicklung3 ist die große Herausforderung, der wir uns jeden Tag stellen müssen. Wir könnten vorpreschen und immer das Neueste benutzen oder immer vorsichtig sein und eine Version erst dann einsetzen, wenn andere sie jahrelang in Benutzung haben. Die Erfahrung zeigt, dass Extreme selten die besten Lösungen bieten. Welche Aspekte sind wichtig, wenn wir über die Einführung von Neuerungen nachdenken?

Mitarbeitermotivation: Hoffentlich kein Fremdwort. Wenn man Mitarbeitern stets verbietet mit neuen Technologien zu arbeiten, bleibt nicht nur die Technologie auf einem Stand stehen, sondern auch unser wertvollstes Gut. Stürzen wir sie hingehen ständig in neue Welten, kann sich ebenso Frustration breit machen. Ziel sollte eine ausgewogene und koordinierte Einführung neuer Technologien in jedem Projekt sein. Daher zu Beginn eines jeden Projektes die verfügbaren und in Frage kommenden Technologien kurz evaluieren und die Risiken bewerten. Mindestens eine Neuerung sollte in ein Projekt einfließen, Arbeit am Fließband macht immerhin niemand gern.4 Aber ein bestehendes Projekt? Wir sind auch froh, wenn wir einmal etwas abschließen können. Also ein Projekt nicht künstlich offen halten, dass motiviert sicher nicht.

Beseitigung von Fehlern/Stabilität: Ich würde Technologien in einem laufenden Projekt nur anpassen, wenn die neuen Versionen Fehler beheben, auf die wir stoßen oder für das weitere Projekt benötigte Features liefern, die uns das Leben erleichtern. Allerdings muss hier unbedingt das Risiko abgewogen werden, zum Beispiel was Kreuzanforderungen an andere Technologien betrifft. Muss man vielleicht deutlich mehr auf neueren Stand bringen, wenn man „nur" eine API austauscht? Fast immer ist die Antwort darauf ja (oder 42, wie wir ja gelernt haben), daher beim Aktualisieren niemals leichtfertig handeln. Und die Entwicklungsdauer ist hier ebenso entscheidend. Ein Projekt, das bald in Produktion geht, tut sich schwerer mit Änderungen, als ein Projekt, dass noch ein Jahr laufen wird. Ganz entscheidend sind hier die Tests: wir müssen anhand von ausreichenden Tests unbedingt verifizieren, dass sich an der Funktionalität und Lauffähigkeit unseres Projektes nichts verändert hat. Lediglich wer eine umfangreiche Testsuite besitzt, kann meines Erachtens Versionsupdates überhaupt in Betracht ziehen. Und mit umfangreich ist wirklich umfangreich gemeint. Das schließt also Blackbox- wie Whitebox-Unittest ein, Integrationstest und viel wichtiger als Basis für alle diese Tests ausgeklügelte Testszenarien.

Neue Projekte: Was bei neuen Projekten? Alles rein was es an Neuem gibt? Bereits unter dem Punkt Mitarbeitermotivation erwähnte ich die Risikobewertung. Selbst bei einem neuen Projekt können wir uns nicht immer leisten, auf Bewährtes zu verzichten. Neue Technologien bedeuten neue Fehlerquellen, nicht intensiv eingearbeitete Teammitglieder, kaum Erfahrungen in der weiten Welt des Internets. Wir sollten gut prüfen, welche Features wir brauchen, ob die enthaltenen Bugfixes vonnöten sein werden, und wie viele Risiken wir auf uns nehmen wollen. Bloß nicht jeden Hype mitmachen. Und wenn, dann Technologien nur in der Umgebung einsetzen, für die sie gedacht sind. Neues ist gut und wichtig, aber wir dürfen nicht die Kontrolle über ein Projekt verlieren. Daher die Bereiche identifizieren, in denen wir uns Neuerungen erlauben können und eventuell Berater ins Team holen, die uns mit Rat und Tat zur Seite stehen und ihr Wissen an das Team weitergeben.

Freigabe von Software: In einigen Unternehmen existieren Bollwerke, welche die Einfuhr neuer Software erschweren. Hier muss man Freigaben erhalten, um etwas produktiv nutzen zu können. Gerade unter solchen Bedingungen müssen wir darauf achten, dass es den Sinn des Schutzes einer konsistenten Softwarelandschaft nicht verliert und zu einer reinen Blockade wird, die uns zu langsam fortschreiten lässt. Wer hier Aktualisierungen durchführt, sollte die Freigaben rechtzeitig prüfen, bzw. beantragen. Der Sinn eines solchen Bollwerkes soll an dieser Stelle natürlich nicht in Frage gestellt werden. Es ist eine weitere Instanz zur Kontrolle von Neuerungen, die projektübergreifend handelt. Gemeinsames planen zu Beginn des Projektes, bzw. der Releasephasen kann spätere Probleme minimieren und ein gemeinsames Verständnis für die Zukunft in der Softwarelandschaft und in der Entwicklung fördern.

Neue Wege statt neuer Software: Manchmal sind es keine Softwareaktualisierungen oder neue Tools, die Mitarbeiter vorschlagen und gern einsetzen würden. Oft geht es lediglich um neue Arten mit Problemen bei der täglichen Programmierung umzugehen. Wir stoßen auf Fragen wie : „Warum benutzen wir hier keine Factory-Klassen", oder Bemerkungen derart „Es wäre viel schöner, wenn wir da Aspektorientierte Programmierung einsetzen" und ebenfalls „Das kann man auch gut in einer Zeile schreiben". Teilweise legitime Vorschläge, wobei mir gerade bei letzterem einige Szenarios einfallen, bei dem man dem Entwickler getrost sagen kann, dass es bezüglich Wartung, Lesbarkeit und Verständnis eine nicht ganz ausgereifte5 Idee ist. Wenn es sich nicht gerade um ein Konstrukt wie

if (result != true) {

return false;

} else {

return true;

}

handelt (ist schon traurig, aber tritt immer wieder auf). Aber zu dem generellem Umgang mit solchen Vorschlägen. Ich denke sie sollten jeweils durchaus auf den Prüfstand gestellt und im Einzelfall darüber entschieden werden. Und in keiner Form sollte jemals eine Antwort wie „Nein, dass haben wir noch nie so gemacht", oder „Das machen wir aber immer so" geäußert werden. Leider muss ich selbst manchmal solche Antworten weiterreichen, wenn ich lediglich Zwischenstation in der Entscheidung bin. Mir liegt dann immer direkt eine Entschuldigung an den Vorschlagseinreicher auf den Lippen, denn solche Willkür ohne echte Begründung lässt mich auch bloß den Kopf schütteln. Anders, wenn der Vorschlag selbst nicht ausreichend begründet ist: „Aber in einem Projekt hat das damals prima geklappt". Hier können wir gern sagen: „Das Risiko ist uns zu groß. Nur weil es einmal geklappt hat, muss es bei uns nicht funktionieren". Es ist wie in der großen kulinarischen Welt. Es gibt einen Grund, warum lokale Spezialitäten die regionalen Grenzen nicht überschritten haben.

Die Neue Welt: Und ein letzter Punkt, den man meines Erachtens auch nicht aus den Augen verlieren darf: der Zahn der Zeit nagt an allem, wir dürfen den Anschluss nicht verpassen. Wer sich jahrelang auf das bestehende verlässt und den Fortschritt um sich ignoriert, den wird irgendwann dieses Versäumnis einholen. Dann besitzt man nur noch Mitarbeiter, die sich mit dem Neuen nicht auskennen, und wenn der Tag kommt, an dem man tatsächlich umrüsten muss, sieht man sich mit großen Problemen konfrontiert. Wissensbeschaffung ist eines davon. Und jahrelanges Wissen und Erfahrung kann sich selbst der beste Mitarbeiter nicht kurzfristig aneignen. Dazu kommt, welche Mitarbeiter unter solchen Voraussetzungen überhaupt die letzten Jahre treu geblieben sind – vielleicht nicht unbedingt die, welche sich in Neues gern einarbeiten.



Nicht zu viel und nicht zu wenig. Nicht jedes Gewürz beim Kochen ausprobieren, sondern Ausgewogenheit schaffen. Nichts ist so konstant wie die Lageänderung6. Daher müssen wir flexibel mit ihr umgehen.

1Falls doch sei dem Leser nahe gelegt, diese Kolumne in Zukunft erst recht aufmerksam zu verfolgen.*

* Und sie nicht zu ernst zu nehmen.**

** Sowie vielleicht einmal den "Hitchhiker's Guide to the Galaxy" von Douglas Adams zu lesen. Und wer bereitwillig diese Fußnoten liest, dem seien die Scheibenwelt Romane von Terry Pratchett ans Herz gelegt. Ehre wem Ehre gebührt.

2Man merkt, mit welcher Erwartungshaltung der Autor den Leser betrachtet

3Hier Fortschritt, nicht das stumpfsinnige Schreiben von (teils) logischen Befehlen in kryptischen Sprachen

4Oder mag hier jemand die Hand heben?

5Um nicht zu sagen dumme

6Vermutlich ein Zitat, wie ich dumpf im Hinterkopf habe - vielleicht sogar von mir. Leider kann ich die Quelle nicht auftreiben.

Donnerstag, 10. Januar 2008

Kontakt

Gern können uns alle Interessierten der Java User Group Nürnberg per Mail an mail@jug-nbg.de kontaktieren. Da wir die Java User Group privat in unserer Freizeit organisieren bitten wir evtl. Verspätungen bei der Antwort zu entschuldigen.

Mittwoch, 2. Januar 2008

Gründer


Oliver Szymanski ist als Dipl. Inform. (Univ.) als selbstständiger Architekt, Berater und Trainer weltweit tätig und im Vorstand des Interessenverbund der Java User Groups e.V. (iJUG).

Seine Themenschwerpunkte umfassen technologisch die Java Enterprise Edition und das .NET-Umfeld. Seit neuestem liegen seine Interessen auch im Mobile Development.

Über seine Tätigkeit hinaus ist er manchmal als Speaker auf Konferenzen wie der Jazoon, Java Forum Stuttgart, JAX, Basta, DOAG-Konferenz unterwegs. Parallel dazu arbeitet er als Schriftsteller und hat bereits mehrere Romane veröffentlich. Auch schreibt er die IT-Kolumne Hex and the City in dem Magazin Entwickler.

 
Oliver Szymanski is an independent Freelancer/Java Enterprise consultant. He is also member of the boards of directors of the Association of Java User Groups (ijug.eu), author in IT-magazines like "S&S Entwickler" and speaker at several conferences like Jazoon, Java Forum Stuttgart, JAX, Basta, DOAG-conference.

Siehe auch:


Kolumne Hex and the City

Seit Januar 2008 schreibe ich die Kolumne Hex and the City, die sich mit Themen aus den Bereichen Informatik und Gesellschaft beschäftigt.

Die Kolumne erscheint einmal monatlich in dem kostenlosen elektronischen IT-Magazin KaffeeKlatsch. Der KaffeeKlatsch erscheint monatlich als PDF und wird an Abonnenten per eMail gesendet. Es gibt ihn auch in gedruckter Form.

Die Beiträge finden sich im KaffeeKlatsch-Magazin oder hier.

Links

Dienstleistungen & Technologien

Source Knights vereint wertvolles Fachwissen und Erfahrung sowohl im Entwurf sowie in der Umsetzung verteilter Systeme, Komponenten- und Service-orientierten Architekturen.

Spezialwissen in den Gebieten rund um die Java Standard und Enterprise Technologie und .Net und bei der Entwicklung und Anbindung mobiler Geräte können Ihnen erfolgreich im Projekt helfen.

Dies schließt insbesondere folgende Technologien ein:

Java:
  • Java Enterprise Edition (JEE)
  • Enterprise JavaBeans (EJB 3) und weitere Komponentenmodelle
  • Java Messaging Service, Message Oriented Middleware
  • Webservices
  • JSF/Wicket/Struts
  • Spring
  • JBoss, Borland
  • Hibernate
  • JDBC, div. O/R-Mapper
  • Service Oriented Architecture (SOA)
  • Multithreading
  • Transaktionssteuerung
  • Java Swing / AWT
  • Eclipse RCP / SWT
.NET (hauptsächlich C#):
  • ASP.NET
  • Windows Communication Foundation (WCF)
  • Webservices
  • Windows Presentation Foundation (WPF)
  • Windows Forms
  • Workflow Foundation
  • Service Oriented Architecture (SOA)
  • Mono als alternative .NET-Umgebung
  • Multithreading
  • Interprozeß-Kommunikation
  • Serviced Components (COM-Komponenten)
  • Transaktionssteuerung
Mobile Bereich:

  • iPhone-Entwicklung
  • Java Micro Edition
  • .NET Compact Framework


Datenbanken:
  • Oracle
  • DB/2
  • Relationale Datenbanken im Allgemeinen
  • SQL-Server
Architektur/Design:
  • Objektorientierte Analyse und Design
  • Architekturmuster / Entwurfsmuster (Design Patterns)
  • Rechnernetze und verteilte Systeme, Client/Server Modelle, Cluster, Redudante System
  • Unified Modelling Language

Dienstag, 1. Januar 2008

Impressum

Diese Seite ist rein privat und dient lediglich dazu alle Interessierten an der Programmiersprache und Technologie Java aus der Region Nürnberg und Umgebung mit Informationen zu versorgen und Treffen zu organisieren.
Java ist eine objektorientierte Programmiersprache und eine eingetragene Marke des Unternehmens Sun Microsystems (2010 von Oracle aufgekauft). Mehr Informationen dazu kann man unter http://www.java.com einholen.

Gepflegt wird diese Webseite von Dirk Dittert, André Sept und Oliver Szymanski.

(c) 2015 Oliver Szymanski, alle Rechte vorbehalten
Soweit nicht anders angegeben haben wir die Rechte an den Inhalten

Kontaktadresse:
jug-nbg.de
Oliver Szymanski
Lindenstr. 31
49751 Sögel

eMail: mail@jug-nbg.de


Haftung und Copyright

Mit Urteil vom 12. Mai 1998 - 312 O 85/98 - "Haftung für Links" hat das Landgericht (LG) Hamburg entschieden, dass man durch die Anbringung eines Links, die Inhalte der gelinkten Seite ggf. mit zu verantworten hat. Dies kann - so das LG - nur dadurch verhindert werden, dass man sich ausdrücklich von diesen Inhalten distanziert. Hiermit distanzieren wir uns ausdrücklich von allen Inhalten aller gelinkten Seiten auf unserer Homepage und machen uns diese Inhalte nicht zu eigen.


Bevor Sie versuchen uns abzumahnen, nehmen Sie Kontakt mit uns auf. Sollte auf unserer Homepage ein Inhalt oder ein Foto fremde Rechte dritter verletzen oder wettbewerbsrechtliche Probleme beinhalten, so bitten wir um Nachricht ohne Kostennote nach §8 Abs 4 UWG.  Wir werden diese von Ihnen beanstandeten Probleme kurzfristig entfernen ohne Ihrerseits die Einschaltung eines Rechtsbeistandes.  Würde ein Anwalt oder Verein uns eine Kostenpflichtige Abmahnung zukommen lassen, würde es (der) gegen § 13 Abs.5 UWG verstoßen. 

Die bereitgestellten Informationen auf dieser Website wurden sorgfältig geprüft und werden regelmäßig aktualisiert. Jedoch kann keine Garantie dafür übernommen werden, dass alle Angaben zu jeder Zeit vollständig, richtig und in letzter Aktualität dargestellt sind. Dies gilt insbesondere für alle Verbindungen ("Links") zu anderen Web Sites, auf die direkt oder indirekt verwiesen wird. Alle Angaben können ohne vorherige Ankündigung ergänzt, entfernt oder geändert werden. 


Die Inhalte unserer Seiten wurden mit größter Sorgfalt erstellt.  Für die Richtigkeit, Vollständigkeit und Aktualität der Inhalte kšnnen wir jedoch keine Gewähr übernehmen.  Wir sind gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich.  Nach § 8 bis 10 TMG sind wir jedoch nicht verpflichtet,  übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt.  Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich.  Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.


Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen.  Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich.  Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft.  Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Keine Abmahnung ohne vorherigen Kontakt Sollte der Inhalt oder die Aufmachung dieser Seiten fremde Rechte Dritter oder gesetzliche Bestimmungen verletzen,  so bitten wir um eine entsprechende Nachricht ohne Kostennote.  Die Beseitigung einer möglicherweise von diesen Seiten ausgehenden Schutzrecht-Verletzung durch Schutzrecht-InhaberInnen selbst  darf nicht ohne unsere Zustimmung stattfinden.  Wir garantieren, dass die zu Recht beanstandeten Passagen unverzüglich entfernt werden,  ohne dass von Ihrer Seite die Einschaltung eines Rechtsbeistandes erforderlich ist.  Dennoch von Ihnen ohne vorherige Kontaktaufnahme ausgelöste Kosten werden wir vollumfänglich zurückweisen  und gegebenenfalls Gegenklage wegen Verletzung vorgenannter Bestimmungen einreichen.

Copyright:
Achtung! Diese Webseiten und deren Inhalte unterliegen dem Urheberrechtsschutz. Das Downloaden, die Nutzung und die Weiterverbreitung dieser Webseiten und ihres Inhalts oder Teilen hiervon ist nur innerhalb der engen Grenzen der §§ 53, 54 UrhG zulässig. Verstöße gegen das Urheberrecht sind strafbar gemäß §§ 106 ff. UrhG und begründen Schadenersatzansprüche gegen den Verletzer. Im Falle der Zuwiderhandlung wird Strafanzeige gestellt!