Kategorie: Software-Entwicklung

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

Ich habe die Notizen und Anmerkungen zu den Vorträgen, die ich an meinem zweiten Tag auf der OOP 2014 besucht habe, bereits in eigenen Blog-Posts verarbeitet:

  1. Software-Evolution mit aim42 – Architecture Improvement Method
  2. How to improve Estimates for Software: The #NoEstimates view
  3. Imposing Rule-Based Architecture on Legacy Systems
  4. Gehirnwäsche für Führungskräfte

Zu den Vorträgen am dritten Tag:

Value Validated Architecture: Discover Your Architecture sans BDUF (Steve Holyer)

Steve Hoyler fragt, ob der Build/Measure/Learn Zyklus auch für Architektur funktionieren kann. Er stellt ein Vorgehen vor, dass versucht, die Architektur bzw. Architekturentscheidungen mit business value zu untersetzen.

Der Anfang klang ganz vielversprechend: brainstorming darüber, was überhaupt zur Architektur gehört. Dies erzeugt einen offenen Dialog und ein geteiltes Verständnis der Beteiligten. Er sprach über Constraints vs. Options und die Frage, welche Constraints Commitments und welche Options sind.

Dann verlor sich Steve etwas in seinem Vortrag. Das muss er noch ausbauen. Insofern am Schluß etwas enttäuschend. Folien gibt es online.

Architekt zu werden scheint nicht schwer, Architekt zu sein dagegen sehr (Michael Stal)

Hier ging es vornehmlich um eine Art Ausbildung zum Software-Architekten mit Beispielen von der Firma Siemens, die da anscheinden sehr viel Zeit und Kapital investieren.

Wie sieht der Weg aus?

  1. Profiling: welches Wissen brauche ich?
  2. Reflection: welche Lücken habe ich?
  3. Doing: Lücken schließen

Architecture 201x (Stefan Tilkov)

Mit dem Untertitel „Lessons learned from modern web-based systems for Enterprise IT“ (Slides).

Stefan Tilkov hinterfragt alte Annahmen und stellt drei Thesen für eine Architecture 201x auf:

  1. Dinge klein schneiden
    • kleine, fokussierte Apps, siehe auch z.B. 12factor app
    • Isolation + Unabhängigkeit
    • Polyglote Programmierung möglich
  2. Teile integrieren, um ein Ganzes zu formen
    • Robuste System auf unzuverlässigen Netzwerken
    • Referenz auf „Circuit Braker„-Pattern aus dem „Release It!“ Buch mit Hinweis Hysterix und Finagle-Frameworks
  3. Effizienter Betrieb
    • Virtualisiertes OS als Container
    • automatisches Deployment
    • „You build it, you run it“

Wie immer von Stefan Tilkov ein guter Vortrag.

Keynote: Software Design in the 21st Century (Martin Fowler)

Siehe separaten Beitrag.

Komplexität oder Unffähigkeit (Gunter Dueck)

Ich kannte Dueck noch nicht. Ex-Querdenker bei IBM, jetzt im Ruhestand und Vortragsredner. Einfach mal auf Youtube schauen. Zum Beispiel das hier, ab ca. Stunde 1. (den Vortrag von der OOP2014 gibts anscheinend nicht online, war recht lustig).

Veröffentlicht am
von

The outstanding Emacs Org-mode enables you to include source code blocks our text. Org-Babel then enables you to execute that code.
Yesterday I came across the Orgmode cookbook. In a section it shows how to write a SQL statement and execute it agains a postgresql database. Very nice I thought, but what about Oracle DB? Because that what I use at work.

No official support

Oracle DB is not supported as of now. There is a proposed patch. It adds the call to sqlplus, Oracle DBs command line client. But on the mailing list there was no discussion about it. 🙁 One trick it applies is to add the „.sql“ suffix to the input file to sqlplus.

< View plain text >
code

  1. (in-file (org-babel-temp-file "sql-in-" ".sql"))

So now I got the following code that is an additional branch in the org-babel-execute:sql function:

< View plain text >
code

  1. ('oracle (format
  2.                               "sqlplus -s %s"
  3.                   (cond ( (and dbuser dbhost dbpassword)
  4.                       (format "%s/%s@%s @%s > %s"
  5.                           dbuser dbpassword dbhost
  6.                           (org-babel-process-file-name in-file)
  7.                           (org-babel-process-file-name out-file)
  8.                           )
  9.                       )
  10.                     ;; user specified dbuser, dbpassword, & dbhost
  11.                     ( (or dbuser dbhost dbpassword)
  12.                       (error (format "Must specify dbuser/dbpassword@dbhost, missing %s %s %s"
  13.                              (if dbuser "" ":dbuser")
  14.                              (if dbpassword "" ":dbpassword")
  15.                              (if dbhost "" ":dbhost")
  16.                              )
  17.                          )
  18.                       ) ;; if one specified, they all must be
  19.                     ( t
  20.                       (format "%s @%s > %s"
  21.                           (or cmdline "")
  22.                           (org-babel-process-file-name in-file)
  23.                           (org-babel-process-file-name out-file)
  24.                           )
  25.                       ))))

Formating the result

Now I got the SQL executing against my db. The output was a bit weired. I experimented with sqlplus formatting with mixed results.

I consulted the elisp source. The result is converted into an orgmode table using TAB as a delimiter. In an example that had two rather long columns with short column names, sqlplus used several tabs between the two column names and so screwed the output quite a bit.

I don’t have a good solution for that. My workaround is to use comma as a column seperator (set colsep ',') and let orgmode guess that. For that I had to touch one line:

< View plain text >
code

  1. (org-table-import out-file (if (eq (intern engine) 'oracle) nil '(16)))

Also I deleted the first empty line using an oracle-branch in org-babel-result-cond/with-temp-buffer:

< View plain text >
code

  1. ((eq (intern engine) 'oracle)
  2.        (with-temp-buffer
  3.            (insert-file-contents out-file)
  4.            (goto-char (point-min))
  5.            (kill-line)
  6.            (write-file out-file)))

Conclusion

In principle, it works. How nice formatted the output it is, depends on your query. When just documenting a query, as an alternative to orgmode I use SQL-Mode and format the result myself.

Veröffentlicht am
von

At work our application reads email from a number of POP3 servers using JavaMail. If you trigger the POP3 server’s timeout the session is closed silently und JavaMail does not complain on session.close. In the result, the message is not deleted and will be processed again on the next turn of the background processing task. To fix this, you need to check the state of the POP3 folder after processing each message. Read on for more details on this issue.

Problem

Some of the mails our application is getting are not only „messages“ meant to be read by humans but contain structured information that is processed. This means DB operations. Processing takes not more than a few seconds – unless the Oracle DB optimizer chooses to take a bad SQL execution plan. At least this is what happened to us last week: the processing of a structured message took like 20 minutes.

The symptom then was that after the application was finished processing the email, it did not deleted the message from the server. It then started processing the mail in the next turn. As we found out the POP3 server (qpopper) has configured a timeout of five minutes. After that it answers with an „-ERR“ status code to the next client command. The code we used to process the mail was roughly this:

< View plain text >
java

  1. try {
  2.   mail = pop3Folder.getMessage(mailIndex + 1);
  3.   // ... do something with mail ...
  4. } finally {
  5.   mail.setFlag(Flags.Flag.DELETED, true);
  6. }
  7. folder.close();

When setting the delete flag, JavaMail sends the DELE command. That was answered with „-ERR“ (from POP3 protocol exchange):

C: STAT
S: +OK 1 1866
C: RETR 1
S: ...
C: DELE 1
S: -ERR POP timeout from some.host
C: QUIT
S: +OK Pop server at some.host signing off.

and the session is gone. Using session.close did not complain. So no exception occured. In fact, if an exception had occured we already had an compensation mechanism that would have prevented processing the same mail again. Also it would have pointed us to the problem more directly.

Solution

The solution is to check the protocol state using folder.isOpen after processing a mail.

If that folder is not open, the mails you have so far processed have not been deleted because in POP3, mails are deleted when closing a folder. So open the folder again and delete all messages (messageRead) that you have processed before. Then carry on, i.e. close the folder.

< View plain text >
java

  1. boolean isOpen = folder.isOpen();
  2. if (!isOpen) {
  3.   folder.open(Folder.READ_WRITE);
  4.   final int mailCount = folder.getMessageCount();
  5.   for(int i = 1; i &lt;= Math.min(messageRead, mailCount); i++) {
  6.     Message mail = folder.getMessage(i);
  7.     mail.setFlag(Flags.Flag.DELETED, true);
  8.   }
  9. }
  10. // folder.close in "normal" code flow

The folder.isOpen sends a NOOP command and evaluates the response, so the „-ERR“ server code is not gone unnoticed.

Doing it right

POP3 was designed to download mails rather quickly. A better solution is to fetch emails from POP3, store it somewhere and only then process them („offline“).

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.