Veröffentlicht am
von

Nach dem Upgrade der PHP-Version läuft die hier installierte PHPGedView Version meines Online-Stammbaums nicht mehr korrekt. Ich hatte schon seit einiger Zeit mit dem Umstieg auf webtrees geliebäugelt, weil es im Gegensatz zu PHPGedView aktiv weiterentwickelt wird. Hier ist also die webtrees-Variante meines Online-Stammbaumes. Die Installation und die Übernahme der Daten aus PHPGedView war problemlos.

Die Integration von Google-Maps ist ganz nett, auch wenn ich noch nicht verstehe, wann Orte auf der Karte dargestellt werden, z. B. für Johann Dobrynski, der in die USA ausgewandert ist. Hier wird die Position des westpreußischen Taufortes angegeben (Google kennt also den „alten“ deutschen Namen), aber die US-amerikanischen Orte werden nicht angezeigt.

Ein Privatsphären-Merkmal hat mich zunächst stutzig gemacht. Beispielsweise sieht man bei meinem Großvater Ernst Karl Pischel als anonymer Besucher nicht, ob und mit wem er verheiratet war (z.B. rechte Seitenleiste), auch die „eigene Familie“ (also die mit seiner Frau) wird nicht angezeigt. Dies liegt daran, dass es in der Familie lebende Kinder gibt, schreiben die Entwickler. Sie begründen dieses Verhalten damit, dass bei der einfachen „Verdeckung“ noch lebender Person (z.B. Anzeige als „vertrauliche Person“ o.ä.) doch Rückschlüsse gezogen werden können, z.B. zum Geburtsort, zur Legimität etc. Auch auf Fotos könnten lebende Person abgebildet werden. Das ist konsequent, macht die Präsentation für den Besucher jedoch auch nicht nachvollziehbarer.

Veröffentlicht am
von

The Oracle DB function „add_months“ adds a given number of months to a given date:

SQL> select add_months(to_date('04.03.14','dd.mm.yy'),1) as result from dual;

RESULT
--------
04.04.14

Nice. But what about 2014-02-28 plus 1 month?

SQL> select add_months(to_date('28.02.14','dd.mm.yy'),1) as result from dual;

RESULT
--------
31.03.14

Ups. It turns out that (quote from documentation)

If date is the last day of the month or if the resulting month has fewer days than the day component of date, then the result is the last day of the resulting month.

The day component of the result can even be greater than the day component of the argument date:

SQL> select add_months(to_date('28.02.14','dd.mm.yy'),120) as result from dual;

RESULT
--------
29.02.24

This was the root cause of defect in a partner system. Of course, there is already a discussion on Stackoverflow over this issue.

As an alternative, you can use interval arithmetic:

SQL> select to_date('28.02.14','dd.mm.yy') + INTERVAL '10' YEAR as result from dual;

RESULT
--------
28.02.24

Nice. But interval arithmetic is not of much help because it does not work with days that does not exist in every month.

SQL> select to_date('28.02.14','dd.mm.yy') + INTERVAL '10' YEAR as result from dual;
select to_date('28.02.14','dd.mm.yy') + INTERVAL '10' YEAR as result from dual
                                      *
ERROR in Zeile 1:
ORA-01839: date not valid for month specified

Date arithmetic is not trivial, I guess.

Veröffentlicht am
von
This entry is part 5 of 7 in the series OOP 2014 Report

In dem gut besuchten Vortrag „Gehirnwäsche für Führungskräfte“ auf der OOP2014 hob Bernd Oesterreich zunächst darauf ab, dass „heutzutage“ viele Unternehmen eher im „komplex“-Bereich als im „kompliziert“-Bereich des Cynefin-Frameworks agieren, d.h. das „einfaches Ursache-Wirkung-Denken“ nicht mehr weiter hilft. (Das erste Mal habe ich über Cynefin aus der Präsentation „Management Brainfucks“ gelernt – ich kann nur empfehlen, die Folien – inkl. Anmerkungen – durchzublättern. Cynefin beginnt ca. ab Folie 50).

Dann zeigte er die sog. „Taylorwanne“. (ruhig mal nach „Taylorwanne“ googlen, da kommt gar nicht so viel). Die Message auch hier ist, dass die Komplexität im Geschäftsleben im Vergleich zum 20. Jahrhundert zunimmt. Etwas ausführlicher steht es im oose-Blog.

Die „alte“ Führungskraft sei gekennzeichnet als „rationale Entscheidungsinstanz“ und dem Motto „Wissen ist Macht“. Aber „Können“ sei das neue  „Wissen“ und die heutige Mitarbeiter sind viel selbständiger als früher.

Zielvereinbarung (uagh!) sieht Oesterreich als Versuch, das Verhalten der Mitarbeiter zu beeinflußen. „Noch mehr Management“ sei das Problem, nicht die Lösung.

Gefragt sei Management von Stabilität und Management von Instabilität.

Einige Beispiele für neue Managementformen von Bernd Oesterreich, nach der Idee, gemeinsam am und im System zu arbeiten:

  • Führungskraft vs. Führungsarbeit: sie ist Bestandteil der Arbeit eines jeden und wird kontextspezifisch ausgeführt
  • Abteilung vs. Kreis: Führungskreis und Arbeitskreise. Mitarbeiter arbeiten in allen Kreisen mit, in denen es sinnvoll ist. Die Kreise koordinieren die Arbeit untereinander.
  • Pfirsichmodell nach Wohland: Peripherie (alle, die mit den Kunden zu tun haben) und Kern (Mitglieder arbeiten der Peripherie zu)

Schließlich erwähnt er noch den „T-Shaped Employer„, also die neue Sorte Mitarbeiter, die sowohl Wissen in der Breite als auch Wissen in der Tiefe (Spezialwissen) hat.

Da ich selbst bisher immer in Matrix-Organisationen gearbeitet habe, kenne ich die „strenge Führung von oben“ nicht persönlich. Unsere Teammitglieder sind kompetent, daher sehe ich bereits „selbständige Mitarbeiter“, die nicht vieler Anleitung bedürfen. Ob die obigen Vorschläge praxistauglich sind, kann ich jedoch beurteilen. Auf jeden Fall hat der Vortrag zum Denken angeregt.

Veröffentlicht am
von
This entry is part 4 of 7 in the series OOP 2014 Report

This was the title of a talk by Michael Feathers (@mfeathers) at the OOP 2014 conference. I was looking forward to his talk because I like his book „Working effectively with Legacy Code“. In his talk he said that this book is about „bringing automated test in place“. I think that is a good summary.

After looking at various definitions of software architecture, he cited Kent Beck: „If you can’t explain your system using four objects you don’t have an architecture.“ This means you have a small set of things to think about and it makes a system understandable. Michael suggests a practice to tell the story of a system using four (or so) objects. I think I’ll make a blog post explaining the system I am working on in about four objects.

As an example of an architectural rule Michael mentioned the seperation of business logic and persistence.

He presented the following rule-based techniques.

Build checks. At build time check certain rules, can be as simple as grepping source code, i.e. using database code in web modules and failing the build. The problem is that people will find ways around these checks when in a hurry.

Dealing with corruption

Local tagging. (aka „TODO“) code comments that are grep-able

Component tender. someone who (temporary) „takes care“ of a component, i.e. watches and fights architecture or design degradation.

Silent alarms. like build checks but will not break the build

Progress

For making progress you can either fix things („Active Reduction Work“) or just stop making things worse („Thresholded Practice change“).Either way, things will get better.

As a direction for „better“: make the system simple.

His advice do not depend on a particular product. He mentioned „grep“ which is rather low level. In the Java ecosystem, I would mention SonarQube as a monitoring tool for architectural measurements. You can use JDepend with JUnit for implementing build checks.

Veröffentlicht am
von
This entry is part 3 of 7 in the series OOP 2014 Report

At the OOP 2014 conference, Vasco Duarte (@duarte_vasco) gave a talk on #NoEstimates. I heard the term before and I was curious. So I went to the talk.

He said the question is „How can you predict the release date of your project without estimates?“. Vasco argues that to commit to an estimate is to commit to a plan. But with #NoEstimates, one would commit to customer value rather than to following a plan. Another aspect is that estimates are often political and that they often encourage to push „for more“.

One precondition for applying #NoEstimates is to have a stable software development process. That means that for the last 3 or 5 sprints, the number of delivered stories are within certain limits (= velocity stability). This implies that you have rather short sprints. If your „sprints“ are actually mid-range runs (like 2 months), you only know after about half a year whether your velocity is stable.

With #NoEstimates apply the following steps:

  1. Select most important piece of work
  2. Break it down into risk neutral chunks of work (chunks are small, like one person day)
  3. Develope each piece of work
  4. Iterate and refactor

So how do you answer the question for the release date? If you know the number of stories that are needed to implement and you assume that your process remains stable then you can simply extrapolate how many sprints you are going need and hence when you are going to release. Take the average of your historical data and project it into the future.

To me, this is a no-brainer. If you have historical data and a stable process then you don’t have to estimate, you can simple extrapolate from historical data.

To me, #NoEstimates has a number of important preconditions:

  • sprints are short
  • velocity is stable and is likely to remain stable
  • probably, stories should be about the same size

One interesting aspect was that the number of stories seems to be a better indicator for release date than story points. Vasco showed data from several projects to support that.

As I said, if the preconditions are met, this is a no-brainer. It is like driving on the highway at about 130 km/h for the last 15 minutes (stable process). Then we will arrive at our destination that is 130 km away in 1 hour. No need to estimate, simply extrapolate.

Vasco picked on Steve McConnells book „Software Estimation: Demystifying the Black Art“ because McConnell would show that estimates are often poor and he’d recommend „better estimates“ (instead of „NoEstimates“). Having read that book myself I think this was unfair but I will leave this for another blog post.

The talk was interesting and now I know what #NoEstimates is about.

On a side note, I was reminded of the talk „Predictability and Measurement in Kanban“ by David Anderson. If I remember correctly, predictability in Andersons talk relates to system stability in Vascos talk.

Veröffentlicht am
von
This entry is part 2 of 7 in the series OOP 2014 Report

Auf der OOP2014 starteten Stefan Tilkov und Gernot Starke „aim42“ – die Architecture Improvement Method.

Viele Teams, die eine Software über einen längeren Zeitraum, sehen den Bedarf für (technische) Verbesserungen, um die Qualität und die Wartbarkeit der Software zu erhöhen. Das Problem dabei ist, das Management davon zu überzeugen, die nötigen Aufwände zu investieren. Die Nachricht hier ist, dass Änderungen am System durch Geld motiviert sind, d. h. man nicht mit Qualitätsverbesserung oder Professionalität argumentieren sollte.

aim42 soll helfen, die nötigen Verbesserungen zu finden, zu bewerten (möglichst in Geld) und umzusetzen. Dabei soll die „42“ an „arc42“ erinnern, eine Plattform für freie Resourcen für Software-Architekten. Aim42 ist ein offener, Community getriebener Ansatz.

Die drei Phasen von aim42 sind (Zitat):

Die drei Phasen von aim42

  • analyze – find problems, risks, deficiencies and technical debt within your system and your development process
  • evaluate – understand root-causes of problems, determine „value“ of
    problems, issues and their remedies, prioritize
  • improve – systematically improve code and structures, reduce technical debt, remove waste and optimize

Das ganze ist natürlich ein iterativer Prozess. In der Analyse-Phase werden alle Stakeholder befragt, es können Qualitätsanalysen und statische Code Analyse zum Einsatz kommen. Erst im zweiten Schritt werden die ermittelten Probleme bewertet. Ziel dabei ist, die Stakeholder zu überzeugen, die Probleme anzugehen. Im dritten Schritt wird dann eine Auswahl an Verbesserungen angegangen. Dazu steht ein Fundus an Mustern bereit.

aim42 soll nur „Industrie erprobte“ Muster und Praktiken enthalten. Es gibt auch ein github-Repository.

Es hat mich beeindruckt, dass die beiden auf der OOP2014 diesen Ansatz gestartet haben.

Die Präsentation-Folien sind online verfügbar.

Veröffentlicht am
von
This entry is part 1 of 7 in the series OOP 2014 Report

Dieses Jahr bin ich drei Tage auf der OOP Konferenz. Hier einige Notizen zu den von mir besuchten Talks und Keynotes. (noch nicht ganz fertig)

Enterprise Application Integration War Stories

So viele Stories waren es dann doch nicht. Die beiden Vortragenden sind u.a. auf die EAI-Patterns eingegangen. Erwähnt, weil mit Erfahrung hinterlegt, wurden Apache Camel und Spring Integration.

Zitate:

Gerade bei Parallelverarbeitung ist das Testen der Fehlerfälle notwendig!

Further tips: small building blocks. No shared mutable state

Keynote „Parallel Programming Design Patterns“ von Tim Mattson (Intel)

Früher: CPU-Performance am wichtigsten, heute: Stromverbrauch. Daher wird zukünftig die Zahl der Cores zunehmen, nicht die Performances des einzelnen Cores.

Damit muss sich die Software ändern, denn die Hardware wird nicht einfach immer „schneller“ (wie früher).

Parallelisierte Software muss her. Hierzu gibt es Design Patterns in mehreren Kategorien. Die kann man anscheinend wunderbar kombinieren.

Beobachtung aus der Game-Industrie: kleine Zahl von „Effizienz“-Entwicklern (Hardware nah), große Zahl von „Anwendungsentwicklern“. Beispiel der Umsetzung: Spezielle JIT-Optimierer, die die Verwendung eines bestimmten Frameworks erkennen und den Code optimieren.

Reactive Programming

Überblick. Beispiele für Sprachen: Erlang und Elm. Hinweis auf das Reactive Manifesto. Frameworks wie Rx, Akka etc. als „Mittelweg“

Keynote: Adaptive Actions

Adaptive Action is a reflective process that guides you to take action in times of uncertainty. Siehe adaptiveaction.org

Integrationschaos

Im Integrationstest kracht es häufig – „what to do about it?“

  • Functionale und technische Specifikation erstellen, Communication contract
  • Formales Review
  • Simulatoren für die Entwicklung, ggf. auch Test
  • Test Data Management

zu letzterem Punkt hat er leider wenig gesagt, wäre interessant für mich. Ein Ansatz wäre, in der Datenbank ein „Soll“-Schema zu haben und dieses zu Beginn der Test in das eigentliche Schema zu kopieren.

Unvorhersehbares handhaben

Eine Folge von 7 Pecha Kucha Vorträgen von Bernd Österreich und sechs seiner oose-Kollegen. Manchmal fand ich den Zusammenhang zu „Unvorhersehbarem“ etwas bemüht, etwa beim Teil zu „agilem BPM“ und „Adaptive Case Management“.

Interessant fand ich, dass es für die OMG ein Austauschformat für „Case Management“ (Fallbearbeitungssysteme) definiert hat.

Veröffentlicht am
von

From the same-titled post @ Sources of Insight

Right here, right now, during my workout, I should be thinking about the feel of the muscles in my chest, squeezing tightly.

I couldn’t help but think how much more we get out of things, when we know what we should be thinking about, whether it’s an exercise routine, a task at work, or a significant performance.

Otherwise, we miss the moments that matter.

And we miss the moments that make us.

So true. #mindfullness