Kategorie: software

Was die Zukunft bringt

Effizienz und Produktivität ist für die Roboter. (Kevin Kelly)

Ich kenne Kevin Kelly von Tim Ferriss‘ Podcast. Er beschäftigt sich mit Trends und Technologien und ist als Mitgründer von „Wired Magazin“ hierfür kein schlechter Ansprechpartner. In seinem 1994 erschienenen Buch hat er sich bereits mit Dezentralisierung und Selbstorganisation (Schwarmintelligenz) beschäftigt. Dieser TED Talk ist sehr zu empfehlen:

Agiles Schätzen mit Storypoints – Agile Estimating with Story Points

English Version below

Agiles Schätzen mit Storypoints

Komplexität, Aufwand, Zeit – was soll mit den Storypoints eigentlich geschätzt werden?

Wenn alle Userstories von ein und derselben Person bearbeitet werden würden, dann sollte am Ende gelten: Je größer die geschätzten Storypoints, desto länger hat es gedauert (Investierte Arbeitszeit = Aufwand).

Nun arbeiten wir aber im Team und wir alle wissen, dass es unterschiedliche Arbeitsgeschwindigkeiten gibt. Deshalb schätzen wir ja nicht in Zeit sondern Storypoints. Und Storypoints funktionieren immer im Vergleich mit anderen Aufgaben (relatives Schätzen), also „größer, kleiner, gleich“. Deshalb stellt euch folgende Frage beim Schätzen:

„Wenn ich die Story allein lösen müsste und ich alle Tools benutzen dürfte die im Team zur Verfügung stehen, würde ich dann länger, kürzer oder gleichlang für diese Story brauchen als für die andere Story?“

Jetzt kommt sofort der Einwand „Aber ich kann ja gar nicht alle Tools bedienen, bzw. mir fehlt Vorgehens-/Fachwissen etc.“ Das stimmt. Aber das fehlt euch bei allen Stories gleichermaßen und kürzt sich weg. Um „größer, kleiner, gleich“ abschätzen zu können reicht es also die Teammitglieder zu befragen, welche tatsächlich Ahnung von den anderen Aufgaben haben. Wenn die sagen „weniger als bei der anderen Story“, dann gilt das für euch bezüglich dieses Aufgabenteils wahrscheinlich auch.

Abschließend noch ein Wort zu Unwägbarkeiten und Risiko. Schneller darf die Bearbeitung immer gehen. Probleme gibt es eher dann, wenn wir Risiken unterschätzen. Deshalb überlegt euch, wie der realistische Worst-Case aussehen könnte und wie aufwändig dieser im Vergleich zur Vergleichsstory ausfällt.

Agile Estimating with Story Points

Complexity, effort, time – what do we estimate when we use story points?

If all user stories are estimated and implemented by the very same person, than the rule should apply: The higher the story points, the more time had been invested (effort).

But we work in teams and as we know, we all have different working speeds. This is the reason why we use story points instead of time estimates. And story points work always in relation to other stories (relative estimation), means „smaller, same or bigger as the other story“. Thus, next time when you estimate ask yourself this question:

„If I had to implement this story all by myself, but I could use all the tools that are available to my team, would it take longer, shorter or as long as the reference story?“

But immediately you will say „But I can not use those tools“ or „I lack the process/domain knowledge etc.“. True – BUT this is true for all stories and therefore (because we estimate by comparing stories) cancels out of the estimation. To estimate „smaller, same or bigger“ you only need to ask those team members who know how to use the tools or have the knowledge. If they say „its less than the other story“ than this holds true if you would do the job.

One final word regarding risk or beeing unsure. It is always good to finish stuff faster. Problems arise (for the PO) if we under estimate tasks. Thus if you feel unsure, it is a good idea to think about the realistic worst case scenario and compare that with the reference story.

 

Vortrag zu Responsive Design by Kent Beck

Ich schaue gerade Kent Becks Vortrag zu Responsive Design an und versuche hier mal meine Gedanken zu den Thema nieder zu schreiben. Hier der Link:

http://www.infoq.com/presentations/responsive-design

Die Seite sieht etwas unübersichtlich aus. Nicht sofort zu erkennen war, dass das Video links nicht alles ist, sondern rechts daneben die Vortragsfolien parallel zum Video umschalten. Also nicht einfach (wie gewohnt) das Video in den Vollbildmodus schalten.

Retrospektive mit Karteikarten

Das sollte man auf Arbeit mal unseren Vordenkern vorschlagen. Hier wendete Kent das „Continuos Improvement“ Pattern auf sich selbst an. Wer macht das eigentlich sonst noch. Häufig wird herzlich gestritten, eine Lösung gefunden und schnell wieder an die Arbeit gegangen. Aber zu dokumentieren warum gestritten/um eine Lösung gerungen wurde und wie und warum das Ergebnis ist wie es ist, das passiert sehr selten. Wahrscheinlich einer der Gründe wieso Kent Beck ein so gefragter Entwickler ist. Er macht nicht nur, sondern er denkt auch darüber nach wieso er es so macht.

Designprinzipien

Kent erwähnt Designprinzipien als Leitfaden für die Entwicklung eines Softwaresystems. Ich kann das nur bestätigen und merke leider immer wieder, dass genau diese bei der Arbeit zwar allen bekannt sind, jedoch häufig nicht dokumentiert werden. Wenn dann Jahre später die ursprünglichen Programmierer weg sind und andere an dem System arbeiten (und andere Prinzipien anwenden) entsteht schnell schlecht wartbarer Code, da Entscheidungen nicht konsistent weiter geführt werden.

Problemlösungs- / Refactoringstrategien

Leap – Sprung

So wie ich Kent verstehe ist der Leap der gefährlichste, jedoch auch schnellste Weg eine Änderung zu erreichen. Solange ich glaube(!) es schaffen zu können sollte ich den Leap versuchen. Sobald ich aber (unterwegs) unsicher werde und das System nicht mehr läuft, gehe ich zurück zum Startpunkt und versuche eine alternative Methode. Kent bringt als Beispiel eine Anwendung wo er sein Designprinzip „Streams statt Filenames“ verletzt hatte. Er wollte nun die Filenames durch Streams ersetzen. Da er 4-5 Klassen anpassen musste ging er davon aus, dass er das so hinbekommt, und wagte den Sprung (Leap). Als er merkte, dass es zu undurchsichtig wurde, änderte er alles wieder zurück und versuchte einen anderen Ansatz.
Interessant war, dass Kent Beck, Author von JUnit, hier zugegeben hat, dass auch bei ihm hin und wieder keine gute Testabdeckung vorkommt. Um überhaupt zu wissen, ob ein Leap erfolgreich war, braucht man Testabdeckung. „Refactoring nur unter Testcoverage“ sollte jedem als Prinzip bekannt sein.

Parallel – Redundanz

Bei Parallel wird ein „zweiter Weg“ ein Problem zu lösen neben den aktuellen (nicht mehr gewollten) gestellt.
Kent bringt wieder das Beispiel „Ersetzen von Filenames durch Streams“. Hier kann man sich vorstellen, dass solch eine Änderung an diversen Stellen in einem SW System schnell unübersichtlich wird.
Kent sagt nun, dass die Parallel-Entwicklung ein sichererer Weg ist. Das kann man so hinnehmen, ich frage mich aber „An welchem Ende des Systems sollte man mit der Umstellung auf Streams beginnen“?

Ich glaube das man vom Ende her beginnen sollte. Also dort wo aktuell die Filenames aufgelöst und die Inhalte gelesen werden, schreibt man eine zweite Methode, welche einen Stream benutzt und zieht die Business-Logik dahin um. Man weiß, dass die Logik funktioniert. Einzig neuer Punkt ist nun, dass Streams statt File-Operationen genutzt werden. Tritt ein Fehler auf weiß man genau, wo man suchen muss. Alle anderen Klassen arbeiten weiter mit Filenames und rufen auch an meiner Klasse die alte Methode mit Filename auf. Die Alte Methode ist aktuell quasi leer. Statt dessen schreibe ich nun dort den Code zum umwandeln eines Filenames in einen Stream hinein und rufe meine neue Methode. Nachdem das alles funktioniert gehe ich zur der Klasse welche meine alte Methode aufruft und schreibe dort eine alternative Methode mit Streams. Diese kann jedoch sofort die neue Methode nutzen. Damit ist die alte Methode an der ersten Klasse nun nutzlos geworden und kann entfernt werden. So gehe ich schritt für Schritt voran und stelle den Code um.

Stepping Stones – Zwischenschritte

Wirklich klar wird das Prinzip durch die Phrase „Wenn ich XYZ hätte, wäre das nicht so schwer“. In so einem Fall baut man sich ein XYZ und macht dann weiter. Notfalls stellt man das XYZ erstmal neben (Parallel) den restlichen Code.
Stepping Stones können leicht overdesigned werden. Also KISS anwenden.

Simplification

Kernidee hier ist: Auf welche primitive Form kann ich das Problem eindampfen? Wenn ich z.B. die Aufgabe habe einen Differentialgleichungs-Löser zu schreiben, der mit bis zu 20 unbekannten arbeiten kann, dann wäre es eine gute Idee mit einem zu beginnen wo keine unbekannte enthalten ist. Und dann einen mit einer Unbekannten. Und dann einen mit zwei. Und dann fällt dabei fast schon von alleine der mit n Unbekannten hinten ab.

Successions – Abfolgen

Die restlichen Folien werden sehr schnell abgehandelt. Von Interesse fand ich die Idee der Successions. Kent vermutet, dass es bei der Arbeit immer wieder Schritte gibt die man nach und nach durchführt um erfolgreich zu sein. Eine dieser Abfolgen ist das bei Simplification erwähnte Prinzip erst „Eine Lösung für 1 Element herzustellen und dieses dann auf mehrere Elemente zu erweitern“ (First One – Than Many). Kent vermutet, dass es noch weitere solcher allgemeinen Abfolgen gibt.

Schlussfolgerung

Ein Vortrag den man sich durchaus mal anschauen sollte.

How to use JPA (and DBs) correctly

Today was a day of greater insights at work. We (Java guys and our DBA) have been discussing how to optimize database access from our Java application. Of course we use JPA (by OpenJPA).

We came to the conclusion, that we all are great fans of interfaces and separation of concerns, but we failed to apply it when we designed our persistence layer.

In our application, the jpa entities are exact copies of the tables in the database. Currently we do a refactoring of our database design, and this hits the application code hard.

The following steps to enlightenment we climbed today:

  1. When you access the db by scenario/use case dependent views, you decouple the db design from the java entity design and vice versa. Whenever you change your db design, this goes with 0 effort for the java team.
  2. JPA is capable of integrating values from several tables in one entity, thus JPA entities work like RW-views. Whenever the db design changes, you (should) only have to adjust the JPA annotations to get it working again.
  3. Use good old component architecture for your Java/Application layer. Each component owns its own private JPA entities and some specific public transfer objects to send and receive information to and from a component.
  4. Your private JPA entities hold only necessary information. This holds especially true for relations between entities. If you don’t need a relation in your component, just load it as an ID field instead. This will automatically cut unnecessary eager fetches.

If you have considered this points, also read this article on optimizing the use of JPA by

  • eager fetching if you need all members of a collection instead of N+1 selects (you can do this with JQL fetch queries, too!)
  • lazy loading if you don’t need related objects.
  • JPA pagination instead of java pagination for big result sets.
  • load specific columns if you don’t need the whole object.

Why to only use immutable variables for Java hashCode()

There are lots of websites which explain to Java coders, that whenever you override equals() you also have to override hashCode(). You need to override those methods especially when you use JPA. Eclipse is a nice tool, that helps you with generating those „custom implementations“.

But beware of the such generated hashCode() methods. It will ruine your day when you use HashSet or HashTable containers and expect them to work like they did with the standard implementation.

The rule of thumb is:

„Only include those variables in the hashCode generation, which will not change during the usage time of the object.“

Why? Just think about a simple class „Foo“ that has a mutable (means normal) property named „value“ and a Eclipse generated hashCode() method implementation (which will use the field value to calculate the hash). Given this class, what will this little test print out?:

    public static void main(String[] args) {
    
        Foo f = new Foo();
        
        f.value = 100;
        
        HashSet<Foo> set = new HashSet<Foo>();
        
        set.add(f);
        
        f.value = 101;
        
        if (set.contains(f)){
            System.out.println("All fine!");
        } else {
            System.err.println("WTF!?");
        }
        
    }

The right answer is: „WTF!?“

Believe it or not, the HashSet will not recognise the instance f anymore, because HashSet and HashTable will use the hashCode() method before the equals() method will be used to identify if an object is included in the container.

So only use immutable variables like ids that will not change during the usage of the class. Such a hashCode() method will still comply to the contract that

Equal objects must produce the same hash code as long as they are equal, however unequal objects need not produce distinct hash codes.

SDHC Support auf Lenovo ThinkPad W500 aktivieren

For english readers, please go directly to this side and follow the instructions there.

Arbeitsbedingt habe ich hier einen Lenovo ThinkPad W500 der mir eigentlich ganz gut gefällt. Er läuft nur leider nicht gänzlich Problemfrei: Neben sporadischen ATI verursachten Bluescreens ist die nicht verfügbare SDHC Unterstützung bei meinem Modell sehr ärgerlich (einige andere Rechner der selben Serie haben wohl aber standardmäßig SDHC aktiv).

SDHC ist die „High Capacity“ Version der SD Karten Spezifikation. Heißt: Ohne SDHC können keine SD Karten mit mehr als 2GB benutzt werden.

Eine Lösung fand ich in einem Forum wo erst erfolglos eine Treiberaktualisierung vorgeschlagen wurde und danach dieser entscheidende Link gepostet wurde:
http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-70881

Der Link befasst sich eigentlich nicht mit W500 Modellen, aber trotzdem hat dies bei mir funktioniert.

Meine Quelle war dieser Thread im Lenovo-Forum.

Die Medienkompetenz der Amokläufer

Dieser Beitrag wurde von mir bei Zeit.de veröffentlicht als Antwort auf den Komentar „4. Lobby der Amoklaufförderer von „gw-hh“.

Als ich den Beitrag Nr. 4 gelesen habe quoll mir regelrecht die Ignoranz gegenüber den neuen nicht verstandenen Medien entgegen.
Computerspiele, vor Allem welche wo’s um Gewalt geht gabs in meiner Jugend nicht. Das muss schlecht sein! Verbieten!! Sofort!

Meiner Meinung nach handelt es sich bei der gesamten Killerspielediskussion um ein Scheingefecht. Es gibt nämlich eine Korrelation zwischen den Spielen und den Amokläufen, aber diese ist zeitlich nicht inhaltlich.

Was das heißt will ich gern erklären.
-Computerspiele sind, dass wurde richtig bemerkt, ein Phänomen der letzten beiden Jahrzehnte. Personen die unter 30 sind, sind damit mehrheitlich aufgewachsen. Personen die unter 20J sind und nicht Computer gespielt haben sind absolute Minderheiten.
-Amokläufe an Schulen sind
, und hier haben wir die Korrelation, ein Phänomen der letzten beiden Jahrzehnte.
Littleton 1999 war die erste Tat dieser Art, und vor allem die erste die so ein großes Medienfeedback in Deutschland erhalten hat.

Für die Personen, welche in die Sündenbocksuche verwickelt sind (und überwiegend dieser Generation nicht angehören), bietet sich dieser Zusammenhang nun wunderbar an um das Medium Computerspiele (was sie aus ihrer Jugend nicht kannten) als den Grund für Taten zu sehen, die es in ihrer Jugend nicht gab.
Übersehen wird dabei, dass die Jugendlichen von heute noch etwas von denen vor 20 Jahren unterscheidet.

Medienkompetenz
Medienkompetenz, so wie ich sie verstehe, ist die Fähigkeit
1) Inhalte von Medien auf ihre Relevanz für die eigene Situation zu bewerten und
2) das passende Medium für den gewünschten Zweck zu nutzen.

Was 1) bedeutet kann man sich denken. 2) bedeutet, dass wenn ich Nachrichten will ich weiß welches Medium mir diese liefert, und wenn ich Unterhaltung will, ebenfalls das passende Medium bekannt ist.

Amokläufer beweisen reproduzierbar ihre Medienkompetenz. Sie wissen genau, dass sie die Aufmerksamkeit die sie wollen, nur durch eine öffentliche Tat diesen Ausmaßes erreichen läßt.

Ich behaupte: Nicht Computerspiele machen Amokläufer, sondern die Berichterstattung über Amokläufe. Denn sie bestätigen immer wieder aufs neue, welche Aufmerksamkeit einem Täter zu kommt, wenn er sich ebenso verhält.

Unsere Lebensart des aktiven Gestaltens von Medien macht den Unterschied zu Früher. Heutige Jugendliche nutzen Medien nicht nur passiv(konsumierent) sondern sie nutzen sie aktiv(gestaltent).

Was ich abschließend nicht verschleiern möchte: Es kann durchaus auch eine Gefährdung von „Killerspielen“ ausgehen. Doch dies hat nichts mit „Point&Click“ zu tun, sondern mit Technologien, welche aus dem Filmgeschäft (Visual FX) stammen und in Zukunft in Spielen eingebaut werden. Darüber habe ich in meinem Block einen Artikel verfasst.