Hello im Gepardec Blog

Für uns hat sich die KI (Künstliche Intelligenz) als ein neues, aber sehr mächtiges Tool erwiesen, das bei fast allen Aufgaben in unserem Beruf behilflich sein und uns viel Zeit sparen kann. Denn bei bestimmten Aufgaben ist es schneller und weniger fehleranfällig. Außerdem macht es viel Spaß, gemeinsam mit KI Probleme zu lösen.

Im Rückblick auf ein viertel Jahrhundert Softwareentwicklung im Enterprise Umfeld fällt mir auf, dass Softwaresysteme, an denen ich vor 20 – 25 Jahren mitgearbeitet habe, zunehmend in einen traurigen Zustand geraten sind. Ist Altern und Sterben von Software ein Naturgesetz, mit dem wir uns abfinden müssen, oder gibt es Gründe dafür, denen wir entgegentreten können?

Observability ist eines der zentralen Themen auf dem Weg zum Applikationsbetrieb in Cloud Infrastrukturen. In diesem Blog skizzieren wir eine gesamtheitliche Sicht auf das Thema, die gemeinsam mit dem Betrieb auch Entwicklung und Fachbereich umfasst.

Hallo! Mein Name ist Wolfgang Felkel. Als UI/UX-Designer bei Gepardec bin ich für verschiedene Kunden an der Entwicklung von B2B-Software beteiligt. Mit diesem Blogpost möchte ich den Nutzen von gutem Design aufzeigen und häufige Missverständnisse aufklären. Eventuellen Zweiflern unter Euch möchte ich vorausschicken, dass professionelle Designer:innen weitaus mehr leisten als nette Grafiken anzufertigen.

Seit der Gründung von Gepardec Ende 2014 sind wir Red Hat Middleware Partner, persönliche Erfahrungen mit JBoss Applicationserver reichen aber etliche Jahre vor dem Kauf von JBoss Inc. durch Red Hat zurück. JBoss Applikationsserver waren und sind das Rückgrat vieler unserer Applikationsentwicklungen.

Uns ist wichtig, dass sich das Team ein gemeinsames Verständnis für den Code erarbeitet. Dafür verwenden wir unterschiedliche Techniken.

When connecting applications to backing services (e.g. databases, message queues) on Kubernetes, supplying the correct credentials and connection information to the workload requires knowledge of both sides of the transaction. Classically, the data has to be known beforehand and is provided for the application through a mounted Secret or some other sort of configuration. The way in which secrets are exposed by services and the mounted locations expected by applications to consume them can differ greatly, often necessitating manual configuration. 

Die W-Jax in München ist eine Konferenzen für Java, Architektur- und Software-Innovation und findet einmal jährlich statt. Wir waren wieder mit dabei und haben unsere Eindrücke hier zusammengefasst.

How we migrated our Learning Friday Project Hogarama to WildFly 26 and struggled with Keycloak security.

Nach der erfolgreichen Space Shuttle Mission 41B im Februar 1984 wurde festgestellt, dass ein O-Ring der Brennstoffraketen wesentliche Schäden aufwies. Die NASA beschloss, dass, solange der zweite O-Ring der Komponente stabil ist, die Sicherheit gewährleistet sei. Später wurde festgelegt, dass der zweite O-Ring den ersten nicht ersetzen kann und dass der erste O-Ring wesentlich für die Sicherheit des Shuttles ist. Nach der Mission 51C am 24. Januar 1985 wurden wesentliche Schäden am ersten und zweiten O-Ring festgestellt. Es wurde ein Zusammenhang zwischen niedrigen Temperaturen und Schäden am O-Ring festgestellt. Bei einer weiteren Mission 51B wurde ein Versagen des ersten O-Rings festgestellt. Der zweite hielt gerade noch durch.

In der Nacht vor dem Start von Mission 51L am 28. Januar 1986 fielen die Temperaturen auf -13°C. Die Techniker der Herstellerfirma der Brennstoffraketen rieten von einem Start ab, das Management beschloss dennoch zu starten. Die Challenger startete, die O-Ringe brannten durch, bei der Explosion und dem folgenden Absturz starben fünf Astronauten und zwei Astronautinnen. Details dazu sind in Missed Warnings: The Fatal Flaws Which Doomed Challenger beschrieben.

Hogarama hat schon einige Veränderungen hinter sich. Gelingt es den Geparden Hogarama mithilfe von Apache Kafka in einen schönen Schmetterling zu verwandeln oder wird es doch ein furchterregender Käfer?

Wir alle kennen es, lieben oder hassen es. Können manchmal besser damit umgehen und manchmal stört uns jeder Atemzug. Richtig! Homeoffice

The following article gives a short overview of the main concepts of Apache Camel-K as well as basic and advanced integration examples including tests. Challenged by taking a look into Apache Camel-K as a possible replacement for our Apache Camel based Red Hat Fuse integration platform, the members of our project team analyzed whether or not Apache Camel-K would fit our “real-world” scenarios and how it could contribute to speeding up development and deployment.

Anlässlich unseres Unternehmenswachstums gewann das Handlungsfeld der Organisationsentwicklung zunehmend an Bedeutung. Die steigende Zahl an Mitarbeiter:innen erforderte die Auseinandersetzung mit Rollen, Prozessen, Organisationseinheiten, Formaten und letztendlich auch mit Entscheidungskompetenzen. Letztere werden in diesem Beitrag näher betrachtet.

Der Test von Software in der Entwicklung nimmt immer mehr an Bedeutung zu. Für jede Teststufe der Testpyramide gibt es Frameworks, wie zum Beispiel Mockito für den Komponententest oder RestAssured und Karate zum Testen von Web-Schnittstellen. Diese Frameworks leisten allesamt gute Arbeit, jedoch haben wir eine Schwachstelle bei Integrationstests, insbesondere für Backend-Services, erkannt: Die meisten Frameworks sind hier sehr schwergewichtig. Hier kommt unser Open-Source Projekt “CheetUnit” ins Spiel, welches wir im Rahmen unseres Learning-Fridays umgesetzt haben.

Mit diesem Artikel möchte ich meine Erfahrungen im Bereich Troubleshooting von Java Applikationen teilen. Ich habe versucht den Artikel so wenig technisch wie möglich zu gestalten und richte mich gleichermaßen an Entwicklung, Betrieb und Management.

Wir beschäftigen uns viel mit Themen wie Organisation, Weiterentwicklung und dem Lernen. Innerhalb und außerhalb von gepardec. Dafür wollten wir ein Modell schaffen, das den Austausch quer über alle Projekte und Standorte hinweg fördert.

So sind wir auf das Spotify-Modell gestoßen und haben einen für uns passenden Weg gefunden, wie wir Gilden im Unternehmen verstehen und mit ihnen arbeiten wollen. Es mag sein, dass diese Form der Zusammenarbeit in manchen Unternehmen anders oder gar nicht funktioniert. Hier beschreibe ich, wie wir es für uns aufgesetzt haben und damit arbeiten.

Im Rahmen des Learning Friday entwickeln wir ein Open Source Projekt. Eines der Dinge, die wir dabei lernen wollen ist, wie man Open Source richtig entwickelt, oder anders gesagt: Was ist wichtig, wenn man Open Source entwickeln will?

Hogarama steht für “Home and Garden Automation” und ist eines unserer Projekte anhand dem wir an den Learning Fridays neue Technologien ausprobieren. Eigentlich ist Hogarama eher eine Plattform für Projekte wie z.B. “Hogarama auf AWS”, “OpenShift Operators für Hogarama” oder “Prometheus Metriken in Hogarama”. Hier möchte ich unsere Erfahrungen mit dem Projekt “Hogarama goes IoT” beschreiben, einem Learning Friday Projekt, das durchaus als gescheitert bezeichnet werden kann.

Just watch the first 2.5 minutes of the following video on youtube and see if you can relate to the story Yevgeniy Brikman from Gruntwork presents.

Wir haben den Anspruch neuen Mitarbeiter*innen den bestmöglichen Einstieg ins Unternehmen zu bieten. Neben einem geregelten Onboarding-Prozess und einem Buddy-Programm haben wir unterstützend dazu den “Alignment Day” ins Leben gerufen.

In dem Artikel Bootcamp 5×5 – Code Ready Workspaces wurde die Idee zu diesem Learning Friday Projekt beschrieben. Nun hat das Bootcamp 5×5 stattgefunden und möchte hier kurz auf die einzelnen Tage eingehen und wie das Bootcamp in Summe für uns gelaufen ist.

Unser “Haupt” Learning Friday Projekt Hogarama ist brav gewachsen und bietet für neue Mitarbeiter*innen einen Einstieg in die Firma. Sei es nun, um andere Mitarbeiter*innen kennenzulernen oder einen Überblick über Technologien, mit denen wir arbeiten, zu erhalten. Tja… die Hürde, um eine Zeile Code für Hogarama schreiben zu können ist hoch (sehr hoch). Die Dokumentationen (ja, es gibt mehrere :-)) sind teilweise veraltet oder benötigen einiges an Know-how, um den Laptop / die Entwicklungsumgebung so einzurichten, dass alles läuft. Probleme durch unterschiedliche Betriebssysteme, Container Runtimes, Versionen von Java und Maven uvm. machen aus einer Setup Session schnell eine Troubleshooting Session 😀

Die Container & Cloud-Native Roadshow 2020 fand in Zusammenarbeit mit Red Hat® am 5.3.2020 in der Factory 300 in Linz statt. Für uns als „Presenter“ war es eine Premiere ein solches Event auf die Beine zu stellen. Das Format der Roadshow stammt von Red Hat® und wird weltweit mit lokalen Partnern durchgeführt. Als Premium Partner in Österreich durften wir erstmals die Roadshow in Linz präsentieren.

Das Gefühl, wenn man Theorie in der Praxis verwirklicht und dabei Konzepte – die man zwar schon kennt, aber noch nie angewendet hat – wirklich verstehen lernt, begleitete mich in meinem ersten Jahr als Softwareentwickler fast durchgehend. Von technischen Themen, wie CI/CD und Microservices, bis hin zu Projektmanagement-Methoden, wie Scrum oder User-Story Mapping, man kommt mit allem einmal in Berührung.

Eine schnelle Methode, um vom Quellcode zu einer fertigen Anwendung in einem Container zu gelangen, ist der “source to image” (S2I) Build. Dabei wird der Code aus einem Git Repository geholt, kompiliert und die Anwendung in einem Container Image installiert.

Wir entwickeln individuelle Softwarelösungen für Kunden. Dabei arbeiten wir meist mit unseren Kunden in gemeinsamen Projekten. Unser bevorzugter Verrechnungsmodus ist eine Abrechnung der geleisteten Zeiten pro Monat (T&M – Time and Material). Das bedeutet, die Zeiterfassung der Stunden unserer Mitarbeiter ist eine sehr wichtige Basis für die Fakturierung / Rechnungserstellung an unsere Kunden. Schon seit Beginn unseres Unternehmens (Dez. 2014) verwenden wir dazu ZEP (Zeiterfassung für Projekte, https://www.zep.de/). ZEP ist eine Cloud-Lösung, wir konsumieren diese Software also als SaaS (Software-as-a–Service) und zahlen je Benutzer einen monatlichen Betrag. Dafür bekommen wir eine hochverfügbare, sichere und auch flexible Lösung zur Verfügung gestellt. 

Johannes, Patrick und Robin haben die W-JAX 2019 Anfang November in München besucht. Die großen Themen der Konferenz waren Domain-Driven-Design und Microservices. Zusätzlich wurden Angular, IT-Security sowie allgemeine Bereiche und Neuerungen aus der Java-Welt besprochen.

On October 17th Michael Kremmer and I, Klemens Wimmer met at the World Usability Congress in Graz to get some new UX-spirit and to update our knowledge of the state of the art in UX and usability issues.

In diesem Artikel soll professionelle Softwareentwicklung keine Wertung implizieren. Meine verwendete Definition ist einfach: „Wir machen es für Geld“. Das heißt nicht, dass professionell entwickelte Software besser oder schlechter ist als privat geschriebene. Die Entwickler sind ja auch oft dieselben, sie programmieren eben nur mit oder ohne finanzielle Gegenleistung. Dennoch bedingt „Programmieren für Geld“ oft eine Änderung im Entwicklungsprozess, oder sollte es zumindest.

Beim diesjährigen Breakout versuchten wir wieder eine gute Mischung aus Action, Gemütlichkeit und inhaltlicher Arbeit zu finden. Untergebracht waren wir im Hotel Leithana in Bruck an der Leitha.

Eines unserer letzten Learning-Friday Projekte hatte Prometheus als Inhalt. Der mythologische Prometheus ist ein Titan, Beschützer der Menschen und Bringer des Feuers. Für uns als Entwickler:in ist Prometheus der neue Titan im Bereich des metrik-basierten Monitorings. Prometheus ist “Built for the Cloud”. Wir erwarten demnächst eine enge Integration in OpenShift, wodurch Prometheus-Kenntnisse ein “Muss” für Systemadministratoren im Bereich Red Hat Clouds werden. Interessant auch, dass sich der neue Eclipse Microprofile Metrics Standard am Format von Prometheus anlehnen wird. Grund genug also, sich das mal anzusehen.

Die von Red Hat gesponserte Konferenz fand heuer bereits zum 11. Mal in Brünn statt und war Anlaufstelle u.a. für Entwickler, DevOps Engineer, Tester etc.. Wir waren Vorort dabei.

Gepardec investiert jährlich rund EUR 3000,- pro Mitarbeiter:in für externe Aus- und Weiterbildungen – immer individuell abgestimmt auf den Wissensstand und das Potential des jeweiligen Mitarbeiters. Damit sich dieses Wissen sowie die Erfahrungen eines jeden einzelnen Mitarbeiter und jeder Mitarbeiterin auch auf das gesamte Team übertragen, wurde abseits von Kundenprojekten das wöchentliche Format Learning Friday für Linz & Wien ins Leben gerufen.

Bei Gepardec hat die Aus- und Weiterbildung für die MitarbeiterInnen seit Beginn einen sehr hohen Stellenwert. Ebenso für Menschen, die sich noch in Ausbildung befinden. Hier bietet Gepardec entsprechende Rahmenbedingungen für ein Berufspraktikum an. Es werden Einblicke in relevante Projekte gegeben, inhaltlich anspruchsvolle Rollen ermöglicht und eine fachliche sowie soziale Betreuung über den gesamten Zeitraum gewährleistet. Darüber hinaus können Studenten bei Gepardec das gesamte Ökosystem und alle Benefits in Anspruch nehmen.