Herzlich willkommen auf dem Blog der exensio GmbH

exensio ist ein unabhängiges Software-Unternehmen von erfahrenen IT Beratern und Architekten. Zu unseren Kunden zählen namhafte deutsche Großunternehmen.

exensio verbessert das Kommunikations- und Informationsmanagement von Unternehmen. Auf Basis sinnvoller und zweckmäßiger Technologien erarbeiten wir flexible und übergreifende Lösungen für webbasierte Informationssysteme. Abhängig von den Kundenanforderungen realisieren wir Web Applikationen sowie Lösungen auf Basis von Web Content Management- und Portalsystemen. Integrativ, wirtschaftlich und anwenderfreundlich!

Hier gelangen Sie zur exensio GmbH.

Freitag, 22. Mai 2015

Entwicklertag Karlsruhe

Der Entwicklertag in Karlsruhe feierte sein 10-jähriges Jubiläum und es wurde wie jedes Jahr sowohl am Conference Day als auch beim Agile Day ein abwechslungsreiches Programm geboten.

Ich möchte hier lediglich auf einen Vortrag kurz eingehen: Agile Jukebox mit Holger Koschek und Rolf Dräther. Beide sind nicht nur im agilen Umfeld als Berater tätig, sondern besitzen auch bemerkenswerte musikalische Fähigkeiten. In ihrem Beitrag berichteten Sie in mehreren Songs über den Projektalltag mit all seinen Hürden im Rahmen des agilen Umfelds. Auch wenn die Vortragsweise sehr amüsant war, fühlte sich jeder Zuhörer in manchen Situationen an das reale Projektleben erinnert.

Beim Track der Java User Group durfte ich am Conference Day mit Ralf Müller einen Talk mit dem Thema „Spock und Geb: Übersichtlich und nachvollziehbar Testen für alle!“ geben. Für weitere Informationen möchte ich auf die Folien verweisen:

Freitag, 15. Mai 2015

JAX 2015

Am 21.04.2015 und 22.04.2015 waren wir für exensio zu zweit auf der JAX 2015 in Mainz. Die Konferenz bot viele gute Vorträge zu einem breiten Themen-Spektrum. Besonders im Mittelpunkt standen in diesem Jahr die Themen Microservices, die Neuerungen in Java 8, JavaFX, sowie die Integration von Java EE 7 mit modernen HTML5-Frontends. Hier folgt ein kurzer Überblick, über einige der Vorträge, die wir angehört haben


Java-EE-7-Architekturen auf Java 8 werden zu Microservices

Der erste Vortrag, den wir uns angeschaut haben, war von Adam Bien zum Theme Microservices. Neben einer Einführung zu Microservices mit allerlei Beispielen war seine Kernaussage: Microservices sollten nicht eingesetzt werden, wenn es nicht unbedingt nötig ist. Es gibt Beispiele wo es Sinn machen kann, in vielen Fällen wird jedoch nur die Komplexität erhöht ohne eine echten Vorteil zu bringen.
Ganz im Stil vieler seiner Vorträge hat er auch diesen mit einer kleinen aber sehr unterhaltsamen Live-Coding-Session abgeschlossen.

Java-Concurrency für Fortgeschrittene

Arno Haase hat einen hervorragenden Einblick in das Thema Concurrency mit Java gegeben. Dabei hat er das Thema eher von einer High-Level-Perspektive beleuchtet und auf häufige Fehler und Probleme hingewiesen. So sollte man etwa bei der Verwendung von synchronized-Blöcken auf Deadlocks gefasst sein, oder den common ForkJoinPool nicht mit wartenden IO-Aufgaben blockieren, da dadurch alle anderen Tätigkeiten in diesem Pool zum Erliegen kommen. Einen möglichen Lösungsansatz, um generell seiteneffektfrei und damit threadsicher zu programmieren, sieht Arno darin, auf funktionale Programmierung zu setzen.
Für Performance-Tuning im Allgemeinen gilt außerdem: erst genau Testen, dann sehr selektiv optimieren. Dabei hilft auch ein sauberes Design mit eher kurzen Methoden.

Typensysteme für JavaScript

Oliver Zeigermann hat eine Übersicht zu Typensystemen für Javascript gegeben. Der Trend ist hier eindeutig zu Typensystem hin. So wird z.B. AngularJS 2 auf Microsoft's TypeScript aufbauen und die JavaScript Engine V8 von Chrome bekommt einen experimentellen Modus für typisiertes JavaScript. TypeScript scheint inzwischen das Typensystem der Wahl zu sein. Wobei der Newcomer Flow von Facebook einige Interessante Funktionen bietet, die inzwischen sogar von TypeScript übernommen wurde.

JavaScript-Webframeworks

Zu JavaScript-Webframeworks hat Oliver Zeigermann ebenfalls einen unterhaltsamen Vortrag gehalten. An kurzen Codebeispielen hat er JQuery, Backbone.js, AngularJS und React verglichen. Da AngularJS 2 völlig neu entwickelt wird und zu AngularJS 1 inkompatibel ist, ist hier Vorsicht geboten bei Einsatz der alten Version. Da immer mehr Logik vom Backend in den Browser wandert,  Sein eigenes nächstes Projekt würde @djcordhose am liebsten mit React umsetzen, dem er einige glorreiche Jahre voraus sagt.

Na klar muss alles "gestern" fertig sein, wann denn sonst?

Der letzte Vortrag des Tages war von Matthias Bohlen. Der Einstieg war mit einigen Star Trek Referenzen direkt gut gelungen. Die Hauptthese war, dass man versuchen soll, die Zeiten zu messen, die für Tickets benötigt werden und auf diesen Daten dann Schätzungen abgeben und dabei eine Wahrscheinlichkeit angeben, mit der diese Schätzung stimmt. Das könnte sich zum Beispiel so anhören: "Wir sind zu 87% in 30 Tagen mit diesem Feature fertig." Eine weitere Empfehlung war der Einsatz von Kanban Boards mit strengen Limits, so dass keine Bottelnecks entstehen, weil ein Team viele Tickets abarbeitet, ein anderes aber nicht hinterher kommt. Generell gilt es Stress zu vermeiden. Bei der Umsetzung dieser Vorschläge kommt es, wie vermutlich überall, auf die jeweilige Situation in einer Firma an.

Vom Wiegen allein wird die Sau nicht fett - von Qualitätsanalyse zu wirksamer Qualitätsverbesserung

Elmar Jürgens von der CQSE GmbH gab Tipps und Tricks zum Thema Verbesserung der Code-Qualität. Die Grundaussage aus dem Titel ist natürlich, vom Erfassen von Qualitätsmetriken wird der Code nicht besser. Aber wie dann? Elmar schlägt vor, dass man „Findings“, also Meldungen von Qualitätsanalyse-Werkzeugen, wie Findbugs, Teamscale, oder SonarQube, zunächst nach Alter sortiert. Dann können sich Entwickler um die Neuesten kümmern, bei denen das Gedächtnis an den Code noch relativ frisch ist. Alternativ oder zusätzlich kann man nur die gravierendsten Meldungen aktivieren, damit die Entwickler nicht von der Zahl erschlagen werden. Elmar und seine Kollegen haben festgestellt, dass es im Projektalltag nicht möglich ist, in einem gewachsenen Projekt im Nachhinein tausende von Findings zu beheben. Darum postulieren sie zwei alternative Vorgehensweisen:

  1. Keine neuen Probleme. Die Zahl der Probleme stagniert also, aber es dürfen keine neuen eingeführt werden. 
  2. Keine Findings in geändertem Code. Der Entwickler der eine Änderung an bestehendem Code vornimmt, muss diesen gleich mit von bestehenden Defiziten befreien. Dabei ist es wichtig, den Scope richtig zu definieren. Wenn man diesen zu groß wählt, führt es eher dazu, dass niemand mehr bestehenden Code anfasst und stattdessen Workarounds programmiert. In Projekten mit kleinen Klassen, kann der Scope daher ruhig auf Klassenebene liegen. Bei vielen tausende Zeilen langen Klassen, sollte man diesen eher auf Methoden einschränken.
Zum Thema Code-Reviews meint Elmar: manuelle Reviews ohne vorherige maschinelle statische Analyse sind vertane Zeit und vergleicht es mit einem Autor, der dem Redakteur einen Text gibt, ohne eine Rechtschreibprüfung auszuführen

Reaktive Geschäftsanwendungen

Der zweite Vortrag von Arno Haase, den wir uns angeschaut haben, behandelte Möglichkeiten, wie man reaktive Geschäftsanwendungen umsetzen kann. Einzelne, von Anfang bis Ende transaktionale Anfragen können in asynchronen Aufrufen umgewandelt werden um eine schneller Reaktion an der Benutzeroberfläche zu ermöglichen. Wenn eine Anfrage mehrere Berechnungsschritte benötigt, können diese dann parallelisiert werden.
Besonders beachtet werden muss die Fehlerbehandlung. Es sollten immer Timouts definiert werden um einen Absturz oder ähnliches zu erkennen.
Es wurde außerdem auf das "Reactive Manifesto" hingewiesen, dass die wesentlichen Eigenschaften eines reaktiven Systems beschreibt.
Das Fazit des Vortrags war: Es gibt viele Fälle, wo reaktive System glänzen können, aber man erhält die Vorteile nicht ohne, dass man sich Nachteile wie höhere Komplexität einfängt.

Mut zur Fachlichkeit – Second Season

Lars Röwekamp ging in diesem Vortrag auf das Problem ein, dass Code heute häufig "unfachlich" ist. Er meint damit, dass z.B. in Domain-Klassen nur Attribute, getter und setter sind, aber fachlich eigentlich setNachname keinen Sinn macht. Der Nachname kann sich z.B. nur ändern, also müsste es hier changeNachname heißen. Außerdem kann der Nachname sich nur bei einer Heirat ändern, also müsste es hier keinen Setter geben, sondern eine Methode "married". Weiter Punkte waren, dass das Domain-Model selbst dafür sorgen soll, dass es immer in einem validen Zustand ist. Nicht nur beim Speichern in der Datenbank. Hier kann das Builder-Pattern eingesetzt werden um nicht-valide Zustände im Domain-Model zu vermeiden. Weitere Maßnahmen zu mehr Fachlichkeit, die vorgestellt wurden, sind Rich Entities, Aggregates und Bounded Context.
Die Erkenntnis des Tags, die man mitnehmen sollte ist:
Muss ich denn den Code ändern, wenn sich die! Fachlichkeit ändert? 
Zur Hölle, ja! Wann denn ! bitte sonst?


Montag, 11. Mai 2015

Wir backen unsere Mittags-Pizza selbst ...

Diesmal ein Blog-Post zu einem nichttechnischen, aber noch wichtigeren Thema: Essen. Wir haben angefangen, einmal die Woche Pizza - die artgerechte Nahrung für Computer-Nerds :-) - selbst zu backen. Selbstverständlich mit Bio-Zutaten :-). Auf den Fotos unten sieht man unsere Kochkünste.

Mittwoch, 6. Mai 2015

Liferay Performance im Zusammenhang mit dem Liferay-Asset-Publisher

In diesem Blog-Post möchte ich über ein aktuelles Projekt berichten, in dem wir die ungenügende Performance eines Liferay Portals für einen Kunden untersuchten. Die Geschwindigkeit einer Web-Page muss immer auf der Client- sowie Server-Seite betrachtet werden.

Aspekte auf der Client-Seite:

Im Browser sind hierbei folgende Punkte zu untersuchen:
  • Wird GZIP benutzt?
  • Sind die JavaScript und CSS-Dateien minifiziert?
  • Werden riesige Fotos benutzt? Viele Bilder lassen sich durch den Gebrauch eines professionellen Tools, wie PhotoShop beträchtlich komprimieren. Auch ist es sinnvoll zu überprüfen, ob Bilder in der passenden Größe übertragen werden. Ein Bild, das eine Auflösung von 4000 Pixeln hat, von dem aber mittels img-Tag nur 100 Pixel gebraucht werden, ist Verschwendung
  • Wie viele Files sind herunterzuladen? Der Einsatz von Sprite-Grafiken oder durch das Zusammenfügen mehrerer kleiner Dateien, in eine umfassende, reduziert die Anzahl der Dateien, die zu laden sind.
  • Wo sind die JavaScript Dateien eingefügt? Es gilt zu überprüfen, welche JavaScript-Dateien am Ende der HTML-Seite platziert werden können, damit Sie erst, wenn die Seite aufgebaut ist, geparst und somit verarbeitet werden.  
  • Nützliche Tools für die Analyse im Browser:
    • Google Chrome Developer Tools
    • Google Chrome PageSpeed Plug-in

Vorgehen auf der Server-Seite:

Wir führen generell einen Lasttest durch, um serverseitige Geschwindigkeitsprobleme zu finden. Hierfür benutzen wir Apache JMeter, eine Open Source Alternative, die aus unserer Sicht vollkommen ausreicht. Für die Durchführung eines Last-Tests ist Erfahrung nötig. So ist bspw. vielfach zu sehen, dass vergessen wird, eine Thinking-Time (darf reduziert werden, um den Punkt zu ermitteln, an dem der Server kollabiert) zu setzen. Erst diese ermöglicht es dem System, zuvor allokierte Ressourcen freizugeben.

Während JMeter seine Arbeit verrichtet, können Thread-Dumps erzeugt werden. In der Produktiv-Umgebung – in der kein Profiler aus Performance-Gründen zur Verfügung steht – kann man mit den Thread-Dumps Performance-Probleme identifizieren. Bei Linux wird für die Erzeugung eines Thread-Dumps ein „kill -3“ an den Prozess geschickt. Unter Windows sollte man hierzu den Java Befehl „jstack > threaddump.log“ benutzen. In dem File threaddump.log findet sich der Thread-Dump. Dieser zeigt für jeden Thread den Stack-Trace an und die Methode, die bei der Erstellung des Thread-Dumps ausgeführt wurde.
Anhand des Methodennamens kann das Problem lokalisiert werden. In diesem Projekt sahen wir, dass es viele Datenbankaufrufe gab. Ich möchte die Beschreibung hier etwas kürzen, es ist aber notwendig, alle serverseitigen Systeme in die Betrachtung miteinzubeziehen. So betrachteten wir natürlich auch den Tomcat und passten beispielsweise  die Memory-Einstellungen an. In unserem Fall hatten wir eine MySQL Datenbank. Bei dieser stimmten wir hauptsächlich die Parameter max_connections und innodb_buffer_pool_size ab. An diesem Punkt möchte ich anmerken, dass man oft sieht, dass der DB-Connection-Pool erheblich groß (bspw. 800) gewählt wird - hier ist ein Wert größer als 200 fraglich.

Liferay Einstellungen

Liferay ist über die Jahre um eine Vielzahl an Funktionen erweitert worden. Der Nachteil hierbei ist, dass viele dieser nicht benötigt werden und somit abgeschaltet werden können, was die Geschwingikeit einer Liferay-Installation verbessert.
Bei den Filtern gilt es folgende zu überprüfen:
com.liferay.portal.servlet.filters.gzip.GZipFilter=true
com.liferay.portal.servlet.filters.strip.StripFilter=false
com.liferay.portal.servlet.filters.sso.cas.CASFilter=false
com.liferay.portal.servlet.filters.sso.ntlm.NtlmFilter=false
com.liferay.portal.servlet.filters.sso.ntlm.NtlmPostFilter=false
com.liferay.portal.servlet.filters.sso.opensso.OpenSSOFilter=false
com.liferay.portal.servlet.filters.validhtml.ValidHtmlFilter=false
com.liferay.portal.servlet.filters.audit.AuditFilter=false
com.liferay.portal.servlet.filters.virtualhost.VirtualHostFilter=false
com.liferay.portal.sharepoint.SharepointFilter=false

Wir stellten nach wie vor eine schlechte Performance fest, selbst nachdem wir auch alle Datenbank-Caches (Hibernate und im Connection-Pool auf Tomcat-Seite) überprüft hatten. Wir installierten schließlich doch noch einen Profiler und schalteten bei der Datenbank das SQL-Log ein, um die Thematik exakter analysieren zu können. Wir fanden sehr viele Abfragen, die die Tabelle AssetEntry betrafen.

Bei genauerer Betrachtung stellten wir fest, dass sich die AssetEntry Queries nicht cachen ließen, da diese den aktuellen Zeitpunkt der Anfrage in den Attributen publishDate und expiration an das SQL-Select-Statement übergaben. Wir fanden weitere Abfragen, die die Tabelle Role betrafen und mehrfach ausgeführt wurden, obwohl man diese hätte zusammenfassen können. Im Peak hatten wir bis zu 729 Queries / Sekunde bei nur 10 Concurrent Usern!

Asset Publisher Portlet und das Thema Performance

Jetzt hatten wir das Asset-Publisher-Portlet in Verdacht. Dieses wurde von unserem Kunden überaus oft und sehr generisch benutzt, um Produktdokumente verschiedenen Produktlinien, gewissen Benutzern und Sprachen zuzuordnen.

Mit folgenden Einstellungen haben wir nochmals überprüft, ob das Asset-Publisher-Portlet die wirkliche Ursache für die Performance-Probleme ist:
  • Dieses Property wurde gesetzt, um Update Statements zu unterbinden: asset.entry.increment.view.counter.enabled=false
  • Validierung, ob Asset Publisher die schlechte Performance verursacht:
    • Liferay sehr schnell aber ohne Assets in der Ergebnisliste
      • asset.categories.search.hierarchical=false
    • 30% - 40% schneller
      • asset.filter.search.limit=10
Somit war für uns bewiesen, dass das Asset-Publisher-Portlet das Performance-Problem erzeugt.

Fazit

Generische Implementierungen haben oft den Nachteil, dass sie nicht sehr performant sind. Gerade SQL-Quereis müssen aus Performancegründen optimiert werden. Eine Alternative bieten hier Suchmaschinen, wie Apache Lucene, Solr oder elasticsearch.
Für das Asset-Publisher-Portlet gibt es folgende Möglichkeiten, um die Performance zu verbessern:

Die vielen Datenbank-Abfragen des Asset Publisher Portlets bedingen – wie oben beschrieben – die schlechte Performance des Liferay-Portals in der Version 6.1. Folgende Links zeigen auf, dass diese Problematik öffentlich bekannt ist: [1] [2]
Der zweite Link beschreibt die Option, in Liferay 6.1 die Datenbank-Abfragen durch Lucene-Abfragen zu ersetzen. Suchmaschinen können beispielsweise sehr viel schneller komplexe Abfragen abarbeiten, wie das mit einer SQL Datenbank möglich ist. Diese Architektur wurde auch in Liferay 6.2 umgesetzt. Ab 6.2 wird ein Lucene Index anstatt DB-Queries für das Asset Publisher Portlet verwendet [3].

„The Asset Publisher has received numerous improvements. Its performance has been improved significantly, as now it uses the search index (rather than database queries) to return entries. Users can subscribe to any list of content, and its UI has been simplified.”

Demzufolge ist eine Migration auf eine Liferay Version >= 6.2 in Erwägung zu ziehen und als einfacher anzusehen, als den Lucene Index in der Version 6.1 einzubauen.

Links

[1] https://liferaycms.wordpress.com/2011/10/11/one-of-bottleneck-in-liferay-6-1/
[2] http://www.liferay.com/de/community/forums/-/message_boards/message/14740401
[3] https://www.liferay.com/de/documentation/liferay-portal/6.2/release-notes

Dienstag, 28. April 2015

Service Portale für Smart Services mit Claretportal

"Die Digitalisierung stellt die technologische Souveränität Deutschlands und Europas in Frage. Große Internetfirmen drängen mit internetbasierten und personalisierten Diensten in immer mehr Industriebranchen vor. Gelingt es ihnen, als Anbieter von Smart Services den Zugang zum Kunden zu monopolisieren, dann könnten etablierte Produzenten und Dienstleister zu Zulieferern degradiert werden ..." schreibt das Bundesministerium für Wirtschaft und Energie überaus trefflich auf seiner Homepage [1].

Als Beispiel kann man hier einen Dienstleister - der selbst keine einzige Maschine besitzt, aber Zugriff auf unzählige Maschinen-Daten hat und über fundiertes Know-how für deren Analyse verfügt - anbringen. Auf dieser Basis kann er einen Auswertungs-Dienst für die Kunden des Maschinenbauers anbieten. Ohne eigene Produkte, ausschließlich durch Informationen lassen sich datengetriebene Geschäftsmodelle - wie Smart Services - aufbauen.

Für diese neuartigen Geschäftsideen wird auch eine Benutzeroberfläche benötigt, in der unterschiedlichste Daten personalisiert visualisiert werden können. Und hier kommt die Portal-Lösung Claretportal von exensio ins Spiel. Aufgrund der Tatsache, dass diese auf Open-Source basiert, fallen keine Lizenzkosten und jährliche Wartungskosten an, des Weiteren besticht Claretportal durch eine schlanke Basis, die man nach dem Lego-Prinzip individuell erweitern kann.

Gerne stellen wir Ihnen Lösungen vor, die wir für Kunden aus dem Mittelstand im Kontext von Industrie 4.0 entwickelt haben.

Links:
[1] http://www.bmwi.de/DE/Themen/digitale-welt,did=696090.html

Donnerstag, 16. April 2015

"Umsetzung von BI-Lösungen mit Unterstützung einer Suchmaschine" beim TDWI Roundtable Stuttgart

Nachdem ich bereits beim 6. OSBI Workshop in Offenburg einen Vortrag zur Umsetzung von BI-Lösungen mit Unterstützung einer Suchmaschine gab, wurde ich vom TDWI eingeladen einen erweiterten Vortrag hierzu zu halten. Nach einer kurzen Vorstellung des TDWI durch den Vorstand Marcus Pilz konnte ich vor ca. 30 Teilnehmern die Nutzung von Elasticsearch für Analyse-Szenarien näher bringen. Ein Live-Demo mit Kibana rundete den Vortrag ab.



Ambiente

Besonders erwähnenswert ist das Ambiente des Roundtable in der obersten Etage des Bahnhofsturm in Stuttgart. Neben einer spektakulären Aussicht über die gesamte Innenstadt versorgte das TDWI die Teilnehmer rundum mit einem kalten Buffet.