Fit to Parent in JavaFx

Versucht man mit JavaFx und SceneBuilder UIs zu zeichnen und die einzelnen Fragmente per Code zusammen zuführen, funktioniert das mit den Anchor nicht outofthebox. Die Anchor Attribute müssen beim einzufügenden Fragment händisch ergänzt werden.

1
2
3
<AnchorPane AnchorPane.bottomAnchor="0.0" AnchorPane.leftAnchor="0.0" AnchorPane.rightAnchor="0.0" AnchorPane.topAnchor="0.0" xmlns:fx="http://javafx.com/fxml" fx:controller="at.freelenzer.dagobert.fx.accounts.AccountsPresenter">

leftSide.getChildren().add(accountsView.getView());

Java Enum#parseFrom

How the parse an enum from an constant?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
import java.util.HashMap;
import java.util.Map;

@SuppressWarnings("boxing")
public enum IndexStrategy {
DEFAULT(0), FASTINDEX(1), FINEGRAINED(2);
private final int value;
private IndexStrategy(int value) {
this.value = value;
}
public int getValue() {
return value;
}
private static final Map<Integer, IndexStrategy> intToEnum = new HashMap<Integer, IndexStrategy>();
static { // Initialize map from constant int to enum constant
for (IndexStrategy op : values())
intToEnum.put(op.getValue(), op);
}
// Returns Operation for int, or null if int is invalid
public static IndexStrategy fromInt(int value) {
return intToEnum.get(value);
}
}

Fast ArrayList or HashMap initialisation

Everyone knows how to initialize String Arrays.

But how can we do this with ArrayLists or with HashMaps?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
private static String[] array = new String[]{"Test", "Test"};

private static List<String> arraylist = new ArrayList<String>() {
{
add("Test");
add("Test");
}
};
private static Map<String,String> map = new HashMap<String,String>() {
{
put("one","Test");
put("two","Test");
}
};

Java DeepCopy via Serialization

Sometimes you need a way to make a deepcopy of all your objects. May be not the fastest :-). You have to ensure, that all of your objects are serializeable.

1
2
3
4
5
6
public static <T> T deepCopy(T o) throws Exception {  
ByteArrayOutputStream baos = new ByteArrayOutputStream();
new ObjectOutputStream(baos).writeObject(o);
ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
return (T) new ObjectInputStream(bais).readObject();
}

Mockito: Mock a JspWriter

How to Mock a JspWriter to move the appended text to a StringBuilder?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
StringBuilder buffer = new StringBuilder();
JspWriter jspWriterMock = mock(JspWriter.class);
Answer<JspWriter> answer = new Answer<JspWriter>() {
@Override
public JspWriter answer(final InvocationOnMock theInvocation) throws Throwable {
Method method = theInvocation.getMethod();
Method methodImpl = StringBuilder.class.getMethod(method.getName(), method.getParameterTypes());
methodImpl.invoke(buffer, theInvocation.getArguments());
return (JspWriter) theInvocation.getMock();
}
};
Answer<Void> answerB = new Answer<Void>() {
@Override
public Void answer(final InvocationOnMock theInvocation) throws Throwable {
buffer.append(theInvocation.getArguments()[0]);
return null;
}
};
when(jspWriterMock.append(Matchers.anyChar())).thenAnswer(answer);
when(jspWriterMock.append(Matchers.anyString())).thenAnswer(answer);
when(jspWriterMock.append(Matchers.anyString(),Matchers.anyInt(),Matchers.anyInt())).thenAnswer(answer);
doAnswer(answerB).when(jspWriterMock).write(Matchers.anyString());
doAnswer(answerB).when(jspWriterMock).write((char[])Matchers.anyVararg());
doAnswer(answerB).when(jspWriterMock).write(Matchers.anyInt());

Here we are :-)

Taskfokusiertes arbeiten oder Wie wir die Zeit anhalten

Wer kennt das Problem nicht. Man sitzt im Büro, eigentlich hätte man ja genug Arbeit, aber irgendwie kommt man mit der zu erledigenden Arbeit nicht weiter.

Das hat natürlich unterschiedliche Gründe:

  • Arbeit muss immer wieder unterbrochen werden
  • Ständig kommen neue Anforderungen dazu
  • Wir können uns schwer auf eine Sache konzentrieren
    Oft liegt es aber auch daran wie unsere Arbeit an uns heran getragen wird. Die Arbeiten sind geprägt von verschiedensten Daten, die Arbeit muss da begonnen werden und da muss sie fertig sein. In den seltensten Fällen geht es dabei um Einzelaufgaben, vielmehr geht es um eine ganze Menge von Aufgaben, die dann als ein gesamtes zu einem Termin fertig sein muss.

Zu alle dem gibt es auch noch Routine-aufgaben die auch zu erledigen sind. Diese Aufgaben sind oft nicht klar aufgelistet und dennoch müssen wir diese Aufgaben erledigen, und selbstverständlich haben auch diese einen Fertigstellungstermin.

Auf jeden Fall scheint alles Zeit getrieben. Somit muss es einen nicht verwundern wenn einige die Ansicht vertreten, sie hätten zu wenig Zeit.

Jedoch hängt die Sichtweise auf das offensichtliche Problem immer vom Blickwinkel des Betrachters ab. Wir sollten unsere Ansicht zu dem Thema gründlich überdenken.

Halten wir doch einfach einmal die Zeit an!

Nicht das wie es am Ende aussieht sollte uns im Moment wichtig sein, sondern die nächste Aufgabe welche wir erledigen müssen um das Endergebnis zu erreichen.

Die Umstellung von dem zeit getriebenen Arbeiten auf Aufgaben fokussiertes Arbeiten hilft uns hierbei.

Machen sie sich frei, schnappen sie sich eine Aufgabe und arbeiten sie diese ab. Haben sie die Aufgabe erledigt haben sie sich eine Pause verdient. Dann geht es wieder weiter.

Es gibt verschiedene Techniken wie man einen konstanten Durchsatz beim Aufgaben fokussierten Arbeiten erreicht.

Auch gibt es unterschiedlichste Techniken wie Aufgaben priorisiert und somit auf die Reise geschickt werden können. Denn am idealsten ist es natürlich wenn sich jemand anderer Gedanken macht welche Aufgabe als nächstes zu erledigen ist.

Technologischer Sex-Appeal

In der Entwicklung arbeiten wohl immer unterschiedlichste Charaktere, und so sagte mir unlängst ein Kollege, er hätte sich in einer Firma als Java Entwickler beworben, nun ist er jedoch Cobol Entwickler geworden. Er ist froh, dass er dort gelandet sei.

Gerade Unternehmen müssen bei Ihren Produkten den Fokus auf die Nachhaltigkeit ihrer Produkte legen. Nachhaltigkeit ist jedoch in der Softwareentwicklung ein dehnbarer Begriff. Oft mach es hier einen Unterschied in welcher Brache man sich bewegt. Schreibt man Software für mobile Endgeräte, kann es schon vorkommen, dass man die Software nicht nur einmal implementiert. Dabei würde man die Nachhaltigkeit in den Konzepten und in Programmiersprachen unabhängigen Algorythmen suchen. Bei Legacy Anwendungen würde man die Nachhaltigkeit dann wohl eher in der Änderbarkeit oder Wartbarkeit vermuten.

Aber gerade bei Legacysystemen kann es vorkommen, dass ein und das selbe Stück Code während seiner Lebensdauer von verschiedensten Personen angegriffen werden muss. Wie kann man dann Mitarbeiter dazu motivieren sich immer wieder in ältere Codeartefakte einzuarbeiten und diese zu verändern.

Es zeigt sich, dass diese Bereitschaft mit der Zeit einfach sinkt. Es werden immer wieder neue Technologien entwickelt, Sprachen werdern vereinfacht bzw. wieterentwickelt, auch die Entwicklungsprozesse entwickeln sich weiter. Es fängt schon bei so banalen Dingen wie einem Sourcerepository an, wo auch schon der Zahn der Zeit nagt.

Potentielle Bewerber suchen sich Ihren Job nicht mehr nur nach den Sozialen- und Intrinsischen- Merkmalen eines Unternehmens aus, nein es spielt mittlerweilen auch schon viel mehr der Technologischesexappeal des Unternehmens eine Rolle.

Wie siehts mit Ihrem Sex-Appeal aus?

Groovy: Analyse Accesslogs

Analyse access logs with groovy. Compare a special behaviour on two different files.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
pattern = ~/.*\\/(.*\.jsp).*/  
data = new HashMap()
calculate("c:/P7_ARCTIS_access_log.2012_01_31%2336[1]", 0);
calculate("c:/P7_ARCTIS_access_log.2012_03_23%2336[1]", 1);
def calculate(filename, i) {
def file = new File(filename);
file.eachLine{line -&gt;
if(line.contains(".jsp")) {
m = line=~pattern
def jsp = m[0][1]
if(!data.containsKey(jsp)) {
data.put(jsp, [0,0]);
}
int[] werte = data.get(jsp);
werte[i] = werte[i]+1;
data.put(jsp, werte);
}
}
}
println data

Here we are!

escalation of commitment

Wer mich kennt weiß, dass ich mich nicht nur gern mit Software beschäftige, sondern auch mit Bergsteigen und Klettern. Darin bin ich zwar nicht richtig gut, aber man muss sich ja mit irgendwas in seiner Freizeit beschäftigen :-).
Beim Bergsteigen beschäftigt man sich sehr viel mit Risikomanagement. Bei jeder Tour die man plant versucht man natürlich das Risiko zu minimieren. Jedoch weiß man auch, dass man es nicht vollständig eliminieren kann. Denkt man darüber mal genauer nach spielt man vielleicht des öfteren mit seinem Leben, und wenn einem das bewusst ist, ist dies ja auch ok.

Vor längerem bin ich über den Ausspruch "escalation of commitment" gestoßen, und er lässt mich nicht mehr los. Ich finde einfach so viele parallelen von dem Risikomanagement am Berg zum Risikomanagement beim Software Entwickeln. Und nicht nur das, ich lerne damit auch Leute und deren Reaktionen auf Kritik besser zu verstehen.

Aber nun zuerst einmal zu dem Zitat:

Je mehr wir in eine Entscheidung investiert haben (zB in Form von Geld, Aufstiegsmühen, Vorbereitungszeit, usw.), desto stärker fühlen wir uns dieser Entscheidung verbunden bzw. verpflichtet. Wir sind auch dann noch bereit, weitere Energien, Mühen und erhebliche Risiken in die getroffene Entscheidung zu stecken, wenn für einen neutralen Beobachter längst erkennbar ist, dass die Entscheidung unsinnig bzw. hoch riskant ist. entscheidungsfindung aus bergundsteigen 3/04

Ich selber konnte diese Reaktionen auch öfters bei Softwareprojekten erkennen, welche nicht ganz rund liefen. Die beteiligten Personen gehen oft in Tauchmodus und sind für Veränderungen nur sehr schwer zu motivieren. Änderungen werden dann oft als negativ bzw. als Zugeständnis von Fehlverhalten gesehen. Etablierte und oft bewährte Techniken, Vorgehensweisen oder auch Tools werden dann in Frage gestellt.

Verinnerlicht man sich das Zitat und denkt genauer darüber nach, kann man das auch verstehen. Umso mehr Respekt muss man dann doch jenen Menschen schenken, welche in solchen Momenten im wahrsten Sinne des Wortes die "Kurve kriegen" bzw. umdrehen.

Die Softwareentwicklung hat sich in den letzten Jahren extrem weiter entwickelt. Wir sind im Zeitalter der objektorientierten Sprachen, Skript-Sprachen versuchen gerade mal den Markt zu erobern. Was wir nun brauchen sind Projektmanager die jahrelang oder jahrzehntelang aufgebaute Weisheiten über Bord werfen und neue (agile) Techniken versuchen. Oder Entwickler die bereit sind sich neue Problemlösungsstrategien anzueignen und neue (agile) Vorgehensweisen umsetzen.

Charlie Poole meinte in seinem Vortrag immer wieder: Separation of concern is one of the main principle from object oriented programming. Was für mich ein synonym dafür ist, dass man sich einem Paradigmen wechsel unterziehen muss, wenn man von einer prozeduralen auf eine objektorientierte Sprache umsteigt.

Die Einführung von Agilen Methoden in ein Unternehmen kann oft einem Kulturschock gleich kommen. Das selbige kann einem auch passieren wenn man direkt von der Uni in einem konservativ geführtem Unternehmen Fuß fasst.

escalation of commitment hat im Agilen eigentlich keinen Platz. Dort wird versucht Entscheidungen so spät wie möglich zu treffen, also mit dem Maximum an Wissen.