SiteOS AG

In diesem Artikel berichten wir über die Erfahrungen beim Aufsetzen einer Tape Backup Lösung im Rahmen einer D2D2T Strategie. Da fragen sich natürlich einzelne, welche Relevanz das in Zeiten der Cloud hat oder ob Tapes das richtige Mittel für die Speicherung der Daten sind. Daher vorab ein paar einleitende Gedanken zu den Anforderungen und Rahmenbedingungen in diesem Beispiel Projekt.

This short article serves as a Java quickstart for getting Vert.x metrics monitored with Prometheus.

SiteOS hat im Rahmen des RZ Betriebs den Einsatz von Distributed Shared Storage Lösungen erprobt. Eine der Technologien könnte nach den Erfahrungen aus der Validierung für einfache Anwendungsszenarien produktiv eingesetzt werden. Allerdings sind wir auf eine extreme Reduzierung der I/O Operationen gestoßen – vergleichbare Effekte sind auch bei der Verwendung von SAN Lösungen zu erwarten. Da wir zunehmend Projekte im Fast - und Big Data Umfeld bearbeiten, ist aus unserer Sicht der Einsatz von Shared Storages und SAN Lösungen dadurch nur in wenigen Szenarien möglich bzw sinnvoll.

Im Rahmen einer internen Schulung habe ich einen Vortrag über die moderne Flux Implementierung Redux gehalten. Die Folien des Vortrags stelle ich hier zur Verfügung.

Im Rahmen einer internen Schulung habe ich einen 2-teiligen Vortrag über moderne JavaScript Entwicklung und Benutzeroberflächen mit React gehalten. Die Folien des Vortrags stelle ich hier zur Verfügung.

The first part of this post describes how you can get a JAX-RS endpoint running with an AngularJS2 app and afterwards made some changes to get it running with basic authentication and CORS.

Recently i needed a cache for a JavaEE project with the following requirements almost zero rampup time, throughput >250000 ops/s and kind of big data (>4g) and since I am a big fan of Chronicle-Map and it covers the requirements i tried to use it right away. This post describes a failure at deploy time if you use ChronicleMap right away and provides a solution to overcome this issue.

After it was mentioned out (thx Fabian Lange) that my benchmark was flawed i have done some additional research on that matter and corrected my benchmark. I also add another method to calculate which is mentioned here.
As lesson learned: Use constant data for all benchmarks and use blackholes or method returns to prevent JIT optimizations like dead code elimination.

Heutzutage dreht es sich in IT-Systemen nur noch um Daten. Wo kommen Sie her, wie und wo werden sie gespeichert, wo angezeigt und welche nachgelagerten Prozessschritte existieren? Früher oder später werden sie jedoch exportiert und an dieser Stelle kann die Protokollierung und Nachvollziehbarkeit eine große Rolle spielen (z.B. hinsichtlich Datenschutz). Dabei ist zu meist weniger relevant wer den Export durchgeführt hat, sondern eher In welchen Exporten war ein bestimmter Datensatz drin bzw. nicht drin?.
Dieser Artikel zeigt einen einfachen und meiner Meinung nach eleganten Weg, wie das mittels Git und Java/JGit (hier JGit) erreicht werden kann.

In Teil 1 dieses Artikels wurde gezeigt, wie mit der Earned Value Analyse der aktuelle IST-Stand eines Projekts hinsichtlich Kosten- und Terminplanung ermittelt werden kann. In einem nächsten Schritt zeige ich nun, wie sich mit Hilfe der EVA Prognosen über den weiteren Projektverlauf stellen lassen.

Vor kurzem las ich im Java Magazin 11/2015 den Artikel Fundierte Entscheidungen treffen können, in dem beschrieben wird, worauf man bei analysierbaren Systemen achten kann/sollte. Dabei ist ein wichtiger Bestandteil und Treiber immer auch die Architektur, die sich im Service Layer zumeist in Backend- und Integration-Layer unterteilen lässt, wie in Abbildung 1 aufgezeigt wird.

Der Backend-Layer und der Application Error Catalogue werden dabei oft mit Unit und Integrationstest abgetestet, was sich im Java/JavaEE Umfeld durch z.B. JUnit und Arquillian manifestiert. Auch der Integration-Layer ist in vielen Projekten fachlich gut durch z.B. Akzeptanztests abgetestet. Aber was macht man eigentlich mit dem dazugehörigen Service Error Catalogue?
Meiner Erfahrung nach ist er in vielen Projekten gar nicht vorhanden, was z.T. aber auch daran liegt, dass dieser technologieabhängig ist. Zum Beispiel wird dieser bei einer EJB-Remote Schnittstelle deutlich anders aussehen, als bei einem ReST-Service. Aber schaut man z.B. auf Webservices, so ist vielen auch gar nicht bewusst, was zwischen einem HTTP-Client und einem -Server alles schiefgehen kann. Dass das aus Komplexitätsgründen z.T. für die Entwicklung gewollt ist, sollte jedem klar sein. Möchte man sein System jedoch richtig kennen, wird man um das Vorhandensein und das Testen eines Service Error Catalogues nicht herumkommen. Wie das mittels Hamms im Java-Umfeld erfolgen kann, wird im weiteren Artikel gezeigt.

Bei der Devoxx4Kids handelt es sich um eine weltweite Veranstaltungsreihe (in über 80 Ländern), bei der Kinder im Alter von 7-14 Jahren einen kreativen Umgang mit Computern, Robotern und Elektronik erlernen. Dazu wird den jungen Teilnehmern in speziell entwickelten Workshops das Programmieren mit z.B. objekt-orientierten Programmiersprachen oder algorithmischen Konzepten spielerisch näher gebracht. Doch dabei beschränkt sich das Lernen nicht nur auf die Konferenz. Durch die Bereitstellung eines öffentlichen Repositories können die Kinder auch zu Hause weitermachen. Wir als SiteOS freuen uns, die Kinder dabei unterstützen zu können und wünschen allen Kindern am Wochenende viel Spaß.

SiteOS hat bei mehreren Bestandsanwendungen (Projekte und Produkten) eine Migration von „JBoss AS FINAL 7.1.1 Community Edition“ nach WildFly 8.2.0.Final durchgeführt. Dieser Artikel ist keine HowTo-Anleitung für eine Migration, sondern beschreibt die konkreten aufgetretenen „Herausforderungen“ und deren mögliche Lösungen oder Workarounds.

Stellen Sie sich vor, Ihr einjähriges Projekt läuft bereits seit sechs Monaten, 50% der Aufgaben sind erledigt und erst 40% des Budgets sind verbraucht. Sie freuen sich zunächst über die guten Zahlen - aber drei Monate später ist das Budget fast aufgebraucht und es stehen noch zahlreiche Aufgaben an.

SiteOS hat im Rahmen eines Großprojektes eine Technologieauswahl für eine neue Applikation bei einem Kunden durchgeführt. Ziele dabei waren, eine Technologie zu finden, welche sich in die bestehende IT-Infrastruktur und Applikationslandschaft nahtlos integrieren lässt und mit der die Anforderungen an die neue Applikation möglichst einfach umzusetzen sind.

Höherer Durchsatz bei größeren Datenmengen Im Rahmen einer größeren Softwareumstellung bei einem Kunden wurde auch der von der verteilten Datenbank verwendete Replikationsmechanismus erfolgreich von Oracle Streams Replication auf Oracle GoldenGate umgestellt. Dabei handelt es sich um eine sternförmige, unidirektionale Verteilung, d.h. die Änderungen werden in einer zentralen Datenbank eingesteuert und von da an die anderen Datenbanken übertragen.