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, 24. Juni 2016

Warum sich Responsive Design für Intranet Applikationen lohnt

Responsive Design ist eines der Buzzwords in Bezug auf die Gestaltung von Internet Webseiten. Was steckt dahinter? Die Webseite wird so implementiert, dass sich das Layout flexibel dem Ausgabegerät und dessen Auflösung anpasst. Damit kann man mit einer Implementierung alles von PC bis Smartphone abdecken.

Natürlich gibt es Vor- und Nachteile dieses Ansatzes. Insbesondere wenn es um mobile Geräte geht, stellt sich die Frage, ob nicht doch besser eine native App – also eine Implementierung für ein spezielles Endgerät – Sinn macht. Eine native App ist generell dann vorteilhaft, wenn Hardware-nahe Funktionen genutzt werden müssen. Diese lassen sich bei einer Geräte-unabhängigen Implementierung nicht oder erheblich schwieriger umsetzen. Auf der anderen Seite muss dann für verschiedene Endgeräte jeweils eine neue Version der App, meist von Grund auf, umgesetzt werden. Und die eigentliche Web Applikation benötigt man ja auch noch.

exensio entwickelt viele Web Lösungen, die im Intranet der Unternehmen eingesetzt werden. Auch hier stellt sich immer häufiger die Frage, mit welchen Endgeräten auf die Applikation zugegriffen werden soll. Ein klassischer Fall sind unsere Portal-Lösungen, die beispielsweise von Marketing und Vertrieb genutzt werden. Während etliche Marketing Kollegen vor allem im Innendienst aktiv sind und Desktop PCs oder Laptops verwenden, arbeiten die Vertriebsmitarbeiter mit mobilen Varianten, d.h. hier kommen verstärkt Tablets zum Einsatz.

Bei einem unserer Kunden gab es das Szenario, dass für unsere Portal Lösung eine native App implementiert wurde. Auf Portal Seite haben wir entsprechende REST/JSON Schnittstellen entwickelt, ein anderer Dienstleister die App.

Schon die erste Version der App hatte trotz vorhandener Portal Schnittstellen bei weitem nicht den Funktionsumfang des Portals. Zudem gab es nicht zu vernachlässigende Aufwände, um die Mitarbeiter für die App zu schulen, da diese im Vergleich zum Portal einen anderen Aufbau hatte und komplett anders zu bedienen war.

Weiterhin stellte sich bei allen neu entwickelten Erweiterungen für das Portal die Frage, ob dies in der Schnittstelle für die App abzubilden ist und wann das neue Feature dann auch auf der App verfügbar ist. Die Konstellation mit 2 Dienstleistern tat ihr Übriges dazu. So wurde die funktionale Lücke zwischen Portal und App immer größer und die Akzeptanz der App schwand.

Letztlich konnten wir unseren Kunden davon überzeugen, das Portal auf ein Responsive Design umzustellen. Die Vorteile waren klar:
  • Keine Trennung in der Entwicklung einer Desktop Version und einer App.
  • Ein durchgängiges Design Konzept für Desktop Version und Zugriff über die Tablets.
  • Eine Umsetzung mit HTML5, die auf allen Endgeräten lauffähig ist.

Für Entscheider ist insbesondere der Blick auf die Kosten relevant:
  • Reduzierung der Entwicklungskosten: keine extra Entwicklungen für Portal, Schnittstelle und App
  • Reduzierung von Schulungs- und Trainingsaufwand: intuitives Design auf allen Geräten ähnlich
  • Reduzierung der Wartungskosten: kein Installations- und Updateaufwand von Endgeräten
  • Keine Migrationskosten: HTML5 ist auf allen Plattformen (iOS, Android, Windows, …) lauffähig

Die beispielhaften Vergleichsrechnungen bei den Investitionskosten konnten auch überzeugen. Faktor 2 beim Vergleich, das Portal auf Responsive Design umzustellen gegenüber der Angleichung zwischen Portal und App. Beim Vergleich der Kosten für die Entwicklung einer neuen Funktion kamen wir sogar auf einen Faktor 3 zwischen der Responsive Lösung und der Variante mit Portal und nativer App.

Als positiven Nebeneffekt konnten wir die generelle Überarbeitung des Designs des Portals in einen frischeren und modernen Look nutzen und damit auch alle Anwender zusätzlich erfreuen.

Fazit: Auch bei internen Web Applikationen, die im Intranet von Unternehmen zum Einsatz kommen, kann sich die Umsetzung eines Responsive Designs lohnen.

Mittwoch, 22. Juni 2016

HTML als HTML in Grails anzeigen

HTML als HTML in Grails anzeigen ist natürlich keine Rocket-Science. Aber da ich aktuell eine Weile suchen musste, möchte ich hier kurz mein Wissen teilen :-)
In Solr Highlighting bekommt man die markierten Texte automatisch mit <em> bzw. </em> markiert. Und eben diese wollte ich in eine GSP in Grails anzeigen.
Eigentlich sollte folgendes funktionieren:
  • ${doc.content} wird automatisch encoded, wenn in Config.groovy grails.views.default.codec="html" gesetzt ist, müsste man auf "none" setzen. Man kann dies auch auf nur einer Seite mittels <%@page defaultCodec="none" %> setzen.
  • Oder man benutzt die JSP Notation, <%=doc.content%> benutzen.
Hat beides nicht funktioniert. In Grails 2.5.4 hat schließlich nur folgendes funktioniert: ${raw(doc.content)}.
Happy Coding!

Donnerstag, 16. Juni 2016

Requirements Engineering nach IREB

Nach dem Wunsch von 2 Kollegen, sich mit dem Thema „Anforderungen“ näher beschäftigen zu wollen, haben wir kurzerhand eine interne Fortbildung für alle Mitarbeiter veranstaltet. Neben dem Gedanken, dass alle Mitarbeiter Grundkenntnisse im Requirements Engineering besitzen sollten, hatten wir auch ein weiteres Ziel: ein gemeinsames Verständnis für die Anforderungsanalyse zu entwickeln und das Zusammenspiel zwischen den Kollegen, die mehr beim Kunden vor Ort sind und täglich sich mit Anforderungen beschäftigen und jenen, die ihren Schwerpunkt auf der Entwicklung haben, zu fördern.

Über die Technische Akademie Esslingen TAE (https://www.tae.de/) haben wir Kontakt zu Frau Dr. Andrea Herrmann (http://herrmannehrlich.twoday.net/) aufgenommen, die für uns ein 2-tägiges Programm mit dem Titel „Requirements Engineering nach IREB“ zusammengestellt hat.

IREB ist das „International Requirements Engineering Board“, eine non-profit Organisation, die sich zum Ziel gesetzt hat, Aus- und Weiterbildung im Requirements Engineering zu fördern und einen entsprechenden Standard entwickelt hat.

In intensiven Sessions haben wir uns in 2 Tagen mit einer Fallstudie auseinandergesetzt und dabei alle wesentlichen Themen des Requirements Engineering vermittelt bekommen und in Übungen angewendet. Beginnend mit der Definition des Systems und dessen Kontext haben wir die verschiedenen Erhebungsmethoden kennen gelernt und darauf aufbauend die Anforderungen an das System in Form von Use Cases beschrieben.

Intensive Diskussionen gab es beim Thema Qualitätsanforderungen, da hier insbesondere die praktischen Erfahrungen die Bedeutung dieser Art von Anforderungen relativiert: Aspekte wie beispielsweise Wartbarkeit und Sicherheit will jeder Kunden haben, aber es soll am besten nichts kosten… Auf der anderen Seite ist es nicht einfach, Anforderungen dieser Art messbar und damit nachprüfbar zu machen.

Frau Dr. Herrmann hat auch auf unseren Wunsch hin Aspekte des GMP (Good Manufacturing Practice) beleuchtet, da wir durch unsere Tätigkeiten für die Pharma Industrie uns mit diesem Thema beschäftigen müssen.

In verschiedenen Übungen haben wir die diversen Diagrammtypen der UML angewendet (wie Use Case-, Aktivitäts- und Zustands- und Klassendiagramm) und dafür das freie UML Werkzeug StarUML (http://staruml.io/) eingesetzt. Über unsere (auch bereits vor der Schulung vorhandenen) Erfahrungen mit dem Tool berichten wir in einem späteren Blog-Beitrag. Die aktuelle Verwendung verschiedener Diagrammtypen in unseren bisherigen Projekten haben wir auch beleuchtet. Nicht alles, was die UML bietet, kann man auch dem Endkunden zur Abstimmung der Anforderungen vorlegen. So setzen wir bereits heute sehr gezielt nur eine Auswahl von Diagrammtypen ein. Zudem stellt sich auch immer die Frage des Kosten-Nutzen-Verhältnisses.

Schließlich haben wir uns noch mit dem Management der Anforderungen im Projektverlauf beschäftigt (Requirements Management) und uns mit dem (für uns üblichen) iterativen Vorgehen und Change Request Verfahren auseinander gesetzt.

Das Ziel, eine gemeinsame Basis beim Thema Requirements Engineering für alle Mitarbeiter der exensio zu schaffen, ist erreicht. Nun gilt es, die ein oder andere Anregung aus den beiden Tagen näher zu betrachten und in den Projektalltag zu integrieren.

Einen herzlichen Dank nochmals an Frau Dr. Herrmann, die uns in der Kürze der Zeit sehr fundiert das Requirements Engineering nach IREB vermittelt hat und auf unsere Spezialthemen eingegangen ist.

Dienstag, 7. Juni 2016

Artikel von exensio im aktuellen JavaSPKETRUM // Schweizer Taschenmesser für Daten - Serverlose Suchmaschinen

In der aktuellen Ausgabe des JavaSPEKTRUM ist von mir ein Artikel mit dem Titel »Schweizer Taschenmesser für Daten - Serverlose Suchmaschinen« erschienen. In diesem zeige ich auf, dass sich Suchtechnologie noch für mehr, als nur Volltextsuche eignet. Als weitere Einsatzgebiete kommen hier:

  • Query-Turbo für SQL-Datenbanken 
  • Verarbeitung von GEO-Daten 
  • Business Intelligence 
  • Internet of Things (IoT) 
in Frage.

Der Artikel kann von hier geladen werden.

Montag, 6. Juni 2016

Rückblick auf die GR8Conf in Kopenhagen

Dieses Jahr durfte ich drei Tage auf der gr8conf zu Gast sein und mein Wissen hinsichtlich des Groovy- und Grails-Ökosystems erweitern. Um die Open-Source Aktivitäten rund um diese Technologien zu fördern waren wir von der Firma exensio auch einer der Sponsoren dieser Konferenz.


Tag 1

Über den gesamten ersten Tag wurden jeweils 2 parallele Workshops angeboten.
Ich hatte zunächst den Workshop zu gradle besucht, der viele Best Practices zum Build-System geboten hat.
Mein zweiter Workshop befasste sich mit Grails und AngularJS. Mit dem AngularJS-Profile wird eine Integration des Javascript-Frameworks innerhalb von Grails ermöglicht. Durch die direkte Integration können allerdings die beiden Komponenten nicht mehr einfach voneinander physikalisch getrennt werden, sprich der Javascript-Code wird auf einem anderen Server wie die Grails-Code installiert.
Am Abend fand der traditionelle Hackergarten statt, dessen Ziel es ist innerhalb eines Abends etwas zur Open-Source-Community beizutragen. Ich arbeitete mit anderen Teilnehmern an der Aktualisierung des Elasticsearch-Plugins für Grails.

Tag 2

Mit der Keynote von Ken Kousen startete der zweite Tag. Er ging insbesondere auf den aktuellen Status von Groovy ein. Die Ankündigung von gradle vor wenigen Wochen, dass zukünftig neben Groovy die Programmiersprache Kotlin unterstützt wird, sorgte für einiges an Diskussionen in der Groovy-Community. Aus seiner Sicht sollte sich Groovy davon aber nicht beunruhigen lassen, da Groovy weiterhin von gradle unterstützt wird und außerdem in vielen anderen Systemen, wie bspw. Jenkins, verwendet wird.

Den interessantesten Vortrag an diesem Tag hielt aus meiner Sicht Michael Ploed zum Thema Reactive Applikations mit Grails 3. Er zeigte auf, wie einfach die Modularisierung von Grails-Applikationen mit Hilfe des in Grails 3 integrierten Reactor-Frameworks erfolgen kann.
In der Präsentation »Monitoring and Metrics with Grails 3« stellte Jeff Scott Brown das neue dropwizard-metric Plugin vor. Hiermit können zukünftig elegant Laufzeiten und die Anzahl von Methodenaufrufen gemessen werden.
Das Thema »Dockerize you Grails App« war meine Abschluss-Session an diesem Tag. Hier wurde auf Docker Basics eingegangen und aufgezeigt, wie einfach Grails-Applikationen darauf aufsetzen können.

Tag 3

Am dritten Tag standen für mich zwei Sessions zum Thema Plugins auf dem Programm. Neben einem generellen Überblick im Vortrag »Mastering Grails 3 plugins« ging der zweite Vortrag auf die Migrationsmöglichkeiten von Plugins von der Version 2 auf 3 ein.
Am spannendsten waren die Präsentationen von Graeme Rocher zur weiteren Entwicklung von Grails. Hier ist insbesondere das mit Grails 3.2 kommende Thema RxGORM, das nicht blockierende Datenbankzugriffe bietet sehr interessant.

Fazit

Neben vielen wissenswerten Informationen zu den verschiedenen Groovy- und Grails-Technologien ist Kopenhagen nicht nur wegen der gr8conf eine Reise wert. Die Stadt ist wunderschön und bietet im Vergleich zu den meisten Städten in Deutschland vielfältige und interessante Gebäudearchitekturen.

Dienstag, 17. Mai 2016

Query Turbo für SQL : Elasticsearch, Apache Lucene bzw. Apache Solr vs. SQL Queries

In diesem Blogpost möchte ich aufzeigen, dass sich Suchmaschinen (in diesem Blogpost gehe ich auf Elasticsearch ein, das wie Apache Solr auf Apache Lucene basiert) auch ausgesprochen effektiv als Turbo für SQL-Queries verwenden lassen. SQL-Queries neigen ab einer gewissen Komplexität (hierarchisch, viele Aggregationen bzw. Joins) dazu, langsam zu werden. So entstehen beispielsweise in Portalen komplexe SQL Statements bei der Abfrage von Personalisierungsregeln (wer darf was sehen). Als prominentes Beispiel kann man hier das Liferay Portal erwähnen. Seit der Liferay-Version 6.2 [1] wird beim Asset Publisher ein Lucene Index anstelle von Datenbankabfragen eingesetzt.

Mein Vergleich verwendet hingegen die 1,5 Millionen Zeilen, die ich in meinem Blogpost mit dem Thema »Olap Cube vs. Elasticsearch« [2] benutzte. Ich habe hierzu in MySQL eine flache Tabelle (keine Joins) angelegt, auf die entsprechenden Spalten einen Index gesetzt und im Anschluss daran befüllt. Anschließend ermittle ich mit Hilfe einer SQL-Abfrage dieselbe Pivot-Tabelle, die ich in meinem vorigen Blogpost mit Elasticsearch erzeugte. Das Retrieval und das Aufbereiten der Daten für die Pivot-Tabelle erfolgt mit folgendem Python-Skript.


Die Tabelle unten zeigt das Resultat, die Sortierung habe ich noch der Elasticsearch-Query meines letzten Blog-Posts hinzugefügt. Damit ist das von MySQL und Elasticsearch zurückgelieferte Ergebnis gleich und muss nicht innerhalb von Python sortiert werden.
+-----------+------------------------------------+-------------+-------------+-------------+
| Land      | Kunde                              | Umsatz 1994 | Umsatz 1995 | Umsatz 1996 |
+-----------+------------------------------------+-------------+-------------+-------------+
| Argentina |                                    |             |             |             |
|           | Cactus Comidas para llevar         |       0.00  |   32339.16  |  104296.86  |
|           | Océano Atlántico Ltda.             |       0.00  |   71270.10  |  504599.82  |
|           | Rancho grande                      |       0.00  |  115290.42  |  296329.62  |
| Brazil    |                                    |             |             |             |
|           | Comércio Mineiro                   |  149676.60  |  146333.76  |   56055.82  |
|           | Familia Arquibaldo                 |    5821.80  |  431282.70  |       0.00  |
|           | Gourmet Lanchonetes                |       0.00  |  521745.96  |   83500.20  |
|           | Hanari Carnes                      |  232872.00  |  181903.08  |  944863.26  |
|           | Que Delícia                        |   17747.10  |  491754.30  |  105637.50  |
|           | Queen Cozinha                      |       0.00  | 2704507.80  | 1017204.30  |
|           | Ricardo Adocicados                 |   79852.56  |  485725.92  |  621214.02  |
|           | Tradição Hipermercados             |    2535.30  |  236947.26  |  276141.12  |
|           | Wellington Importadora             |   26235.66  |  108304.26  |  231125.46  |
| Mexico    |                                    |             |             |             |
|           | Ana Trujillo Emparedados y helados |    3023.58  |  104961.42  |   74969.76  |
|           | Antonio Moreno Taquería            |   41316.00  |  353233.02  |  109731.54  |
|           | Centro comercial Moctezuma         |    6103.50  |       0.00  |       0.00  |
|           | Pericles Comidas clásicas          |  101787.60  |  286977.18  |  132695.20  |
|           | Tortuga Restaurante                |  306696.18  |  448316.16  |  137876.06  |
| Venezuela |                                    |             |             |             |
|           | GROSELLA-Restaurante               |  124492.62  |       0.00  |    2835.78  |
|           | HILARIÓN-Abastos                   |  153826.98  | 1487469.90  |  720745.36  |
|           | LILA-Supermercado                  |  248947.68  |  576151.62  |  553818.20  |
|           | LINO-Delicateses                   |       0.00  |  834376.62  |  431038.56  |
+-----------+------------------------------------+-------------+-------------+-------------+
Time taken: 10.31 seconds

Die gemessene Zeit liegt immer bei ca. 10 Sekunden (MySQL cached nicht) auf meinem Notebook. Vergleiche ich die Zeitdauer mit Elasticsearch, so ergibt sich folgendes Bild. Initial (Caches nicht aktiv) benötigt die Abfrage mit Nested Objects 1,2 Sekunden ohne nur noch 1 Sekunde. Elasticsearch cached bei den nächsten Aufrufen und wir erhalten schließlich Zeiten von ca. 200ms. Hierbei sei zusätzlich erwähnt, dass ich sowohl MySQL als auch Elasticsearch nicht getuned habe.

Fazit

Sollte man bei der Entwicklung auf komplexe SQL-Queries stoßen, die nicht performant laufen, so kann es eine Überlegung wert sein, eine Suchmaschine wie Elasticsearch zu involvieren. Elasticsearch unterstützt Relationen, mit Nested Objects bzw. Parent-Child. Mein kleiner Test hat gezeigt, dass Nested Objects initial ca. 20 % langsamer sind. Parent-Child-Abfragen sind laut Dokumentation [3] 5-10 mal behäbiger als eine Nested Query. Im Vergleich zu MySQL ist in meinem Testaufbau zu sehen, dass Elasticsearch ca. 10-mal performanter ist.

Links

[1] https://web.liferay.com/en/documentation/liferay-portal/6.2/release-notes
[2] http://blog.exensio.de/2016/04/olap-cube-vs-elasticsearch.html
[3] https://www.elastic.co/guide/en/elasticsearch/guide/current/parent-child-performance.html