anderScore Kontakt

Frankenwerft 35
50667 Köln
Deutschland
E-mail:info@anderScore.com
Telefon:+49dieser span dient dazu, dass skype die telefonnummer nicht als solche erkennen kann 221 3558 3530
Fax:+49 221 3558 3531

Image

Willkommen auf der Seite der Goldschmiede - Kodieren auf (mit) Kölsch.

Unsere Idee

  • Regelmäßiges gemeinsames Entwickler-Treffen
  • Erfahrungsaustausch zu technischen Fragestellungen oder Projektsituationen
  • Gemeinsames Arbeiten in Projekten und persönliche Weiterentwicklung im Team
Sie sind herzlich eingeladen, sich in unserer Mailingliste zu registrieren und an einem
unserer nächsten Treffen teilzunehmen.

In der Goldschmiede Mailingliste eintragen

anmelden abmelden
Ihre e-Mail:  

Nächstes Treffen

Der nächste Termin wird in Kürze an dieser Stelle und über die Mailingliste bekannt gegeben.

Goldschmiede - Archiv

12.10.2018 um 17:30 Uhr - JHipster [mehr Information] [Material]

Grüne Wiese. Es soll eine neue Webanwendung entwickelt werden. Klingt erst mal gut, denn so kann man problemlos auf aktuellen Technologien aufbauen, ohne Altlasten mit herum zu schleppen. Doch schnell stellt man fest - eine moderne Webanwendung aus dem Boden zu stampfen ist eine ganze Menge Aufwand! Konfigurationen, Test Setup, Buildmanagement, Deployment - Und wir wollten doch eigentlich nur die Features umsetzen?

Es gibt bereits einige Werkzeuge, die beim Grundaufbau (Scaffholding) der Anwendung helfen, wie z.B. Spring Initializr, Spring Boot oder die Angular CLI. Allerdings beziehen sich diese Tools nur auf Teile der Anwendung. An dieser Stelle setzt JHipster an. JHipster ist ein Werkzeug, um Anwendungen und Microservices mit Spring Boot + Angular / React zu generieren. Die generierte Anwendung besteht aus:

  • Einem hochperformanten Java Stack mit Spring Boot auf der Serverseite und einer Auswahl aus modernen DB-Technologien.
  • Einer schicken, modernen, responsiven UI mit Angular oder React und Bootstrap.
  • Einer robusten Microservice Architektur mit der JHipster Registry, dem Netflix OSS Stack, dem ELK Stack und Docker.
  • Einem mächtigen Buildmangement Workflow mit Yeoman, Webpack und Maven oder Gradle.

In der dazugehörigen Goldschmiede stellte uns unser Kollege Max Johenneken die Konzepte von JHipster vor und welche Möglichkeiten wir bei der Generierung der Anwendung haben. Dazu gab es eine Livedemo in der wir eine Anwendung mit JHipster aufsetzten und sie auf ein Kubernetes Cluster deployten. Als Abschluss gab es eine rege Diskusion darüber wann sich JHipster im produktiven Einsatz lohnt und welche Vor- und Nachteile sich daraus ergeben.

 

31.08.2018 um 17:30 Uhr - Apache Kafka [mehr Information] [Material]

Bei unserer letzten Goldschmiede  hat unser Kollege Jan Lühr einen Kafka-Workshop abgehalten. Wir begannen mit einem Hands-On: Mit kurzen Übungen zur Installation sowie zur Integration in Java und Spring stiegen wir in Apache Kafka ein.  Im zweiten Teil analysierten wir Eigenschaften, Vor- und Nachteile und hatten einen Blick auf das Kafka-Ökosystem.

Apache Kafka (Link zu: https://kafka.apache.org/) ist eine Distributed Streaming Platform. Wie bei Messaging Systemen üblich, greifen Producer und Consumer via Publish/Subscribe auf Streams zu. Mit Kafka Streams können Events in Echtzeit verarbeitet werden. Dabei werden die Streams dauerhaft und verteilt gespeichert.

Die Teilnehmer der Goldschmiede konnten sowohl vor Ort wie auch remote mitentwickeln.

 

 

27.04.2018 um 17:30 Uhr - Strukturelle Architektur mit Dessert, open source [mehr Information] [Material]

In der Designphase sieht ein neues Softwareprodukt noch so schön aus: Da gibt es klar abgegrenzte Funktionsblöcke mit klar definierten Zuständigkeiten und sauberen Schnittstellen. Das fertige Produkt sieht in der Dokumentation meistens noch genauso aus, die Wirklichkeit ist aber häufig eine andere. Da gibt es Funktionalität, die in keine der definierten Blöcke passt. Oder es gibt Abhängigkeiten, die nicht beschrieben sind, weil einfach vorhandener Code genutzt wurde, ohne zu berücksichtigen welchen Rattenschwanz an Abhängigkeiten das nach sich zieht. Wie sehr sich die tatsächliche Architektur Richtung Wollknäuel bewegt hat, erkennt man daran, wie komplex es wird, einzelne Teile zu testen oder wie schwierig es ist, Funktionalität in wiederverwertbare Komponenten auszulagern. Die Testbibliothek ‚dessert‘ - das ist eine Abkürzung für ‚dependency assert‘ - soll helfen, Abweichungen von der definierten Architektur frühzeitig zu erkennen um dem Wollknäuel gegenzusteuern. 

Unser Kollege Hans Jörg Heßmann hat darüber berichtet, wie er zu dem Thema „Strukturelle Architektur“ gekommen ist und was ihn dazu bewegt hat, eine eigene Bibliothek zur Abhängigkeitsprüfung (https://github.com/hajo70/dessert) zu implementieren. Des Weiteren ist er auf typische Fehler eingegangen, die die Wiederverwendung von Code verhindern oder die Testbarkeit erschweren und hat verschiedene Werkzeuge vorgestellt, die dabei helfen, diese Probleme zu analysieren. Anhand konkreter Anwendungsbeispiele hat er gezeigt, wie man frühzeitig Abweichungen von der Soll-Architektur erkennt oder was man tun kann, um ein bereits vorhandenes Wollknäuel zu durchdringen und zu entflechten.

Die Materialien zu der Präsentation finden Sie wie immer unter dem folgendem Github Link.


02.02.2018 um 17:30 Uhr - Legacy Software wieder testbar machen! [mehr Information] [Material]

Bei unserem letzten Treffen ging es einmal nicht um schöne neue Technologien, sondern es wurde sich dem potentiell Hässlichen zugewendet.

In einer idealen Welt wird Software von Beginn an durchdacht entwickelt und bei jeder Komponente auf eine gute Testbarkeit geachtet. Der Alltag eines Softwareentwicklers sieht freilich anders aus: Monolithischer, schwer verständlicher, unzureichend dokumentierter und fehleranfälliger Code aus vergangenen Tagen muss gefixt oder um neue Funktionalitäten erweitert werden – und das am besten gestern. Gleichzeitig darf bestehende Funktionalität jedoch unter gar keinen Umständen angefasst werden, was zu einer Art "Fear Driven Development" führt, das jegliche Bemühungen zur Verbesserung der Code-Qualität im Keim erstickt. Um die Wartbarkeit von Altanwendungen langfristig zu erhalten und gleichzeitig sicherzustellen, dass sich gewünschtes Verhalten nicht unbeabsichtigt verändert, werden strukturelle oder gar semantische Refactorings zur Verbesserung des automatisierten Testens aber unabdingbar.

Im Rahmen dieser Goldschmiede haben wir uns nicht nur geeignete Refactoring-Techniken aus dem praktischen Alltag angeschaut, sondern uns auch über die Organisation des Refactorings selbst unterhalten.

Die Materialien zu der Präsentation finden Sie wie immer unter dem folgenden Github Link.

01.12.17 um 17:30 Uhr - Java 9 ist da! Doch was bringt es? [mehr Information] [Material]

Goldschmiede vom 1.12.2017: Java 9

Am 21. September 2017 erblickte die 9 Version 9 des Java Development Kits (JDK) die Welt. Dabei mischen sich wie immer kleine (aber feine!) Änderungen an der Sprache munter mit größeren, grundlegenderen Neuigkeiten des Java Ökosystems.

Doch welche Features aus der neuen lange Liste der umgesetzten Java Enhancement Proposals (JEP) sind interessant und wichtig? Was sind die entscheidenden "Quality of Life" Features und Tools die uns das Entwicklerleben versüßen? Von welchen entscheidenden Neuerungen sollte man als Java-Entwickler gehört haben um mitreden zu können beim Fachsimpeln unter Kollegen oder beim Vorstellungsgespräch mit dem künftigen Chef...? 

Alle Teilnehmer der Goldschmiede wurden dazu eingeladen, genau dies zu ergründen! Zu diesem Zwecke wurde passenderweise gleich intensiv Gebrauch von einem der interessantesten und coolsten neuen Features des JDK 9 gemacht: Der JShell.

Mit diesem Tool liefert das JDK erstmalig eine interaktive Shell zum Auswerten und Ausgeben von Java Sprachanweisungen. Es macht sehr viel Spaß ohne lästigen Boiler-Plate Code direkt neue Features und Anweisungen auszuprobieren und sofort das Ergebnis zu sehen. Dies konnten wir dann natürlich auch nutzen, um weitere Java 9 Sprachfeatures - wie z.B. die Erweiterung der Stream-API - live am "lebenden Object" zu testen. Getreu dem Motto: Kodieren auf (mit) Kölsch!

Die Materialien zu der Präsentation finden Sie wie immer unter dem folgenden Github Link.

03.11.17 um 17:30 Uhr - Cryptoparty [mehr Information] [Material]

Goldschmiede vom 3.11.2017: Cryptoparty

Egal, ob man nicht will, dass Geheimdienste private Mails mitlesen oder verhindern möchte, dass die eigene Konto-PIN in falsche Hände gerät - Computersicherheit betrifft alle, ob Laien oder Profis. Perfekte Sicherheit kann es nicht geben, aber wenigstens gibt es Programme, die das digitale Leben erheblich sicherer gestalten - und es gibt die Cryptoparty:

Auf einer Cryptoparty gibt es nicht viel Theorie, sondern praktische Hilfe. Nach einem kurzen Einführungsvortrag bekommen die Teilnehmerinnen und Teilnehmer Gelegenheit, in Arbeitsgruppen die vorgestellten Programme auf ihren mitgebrachten Geräten zu installieren und auszuprobieren:

  • Mailverschlüsselung mit Enigmal (Thunderbird)
  • Anonymes Surfen mit Tails (tor)
  • Sicheres Messaging mit XMPP / omemo (gajim / conversations)
  • Passwort-Verwaltung (keepass)
  • Datenträger-Verschlüsselung (veracrypt)

Die Materialien zu der Präsentation finden Sie wie immer unter dem folgenden Github Link.

01.09.17 um 17:30 Uhr - Eine Tour durch Kubernetes [mehr Information] [Material]

Bei der Goldschmiede mit Jan Lühr ging es um Kubernetes:

2015 von Google veröffentlicht, entwickelt sich Kubernetes zu einer Standardplattform für Deployment und Betrieb von Container-Anwendungen (z.B. Docker, rkt) - Cluster-Basiert.

 

Auf der Goldschmiede am 1.9.2017 ging es um folgende Fragen zum Thema Kubernetes:

  • Welche Vorteile bietet Kubernetes -  Welche Eigenschaften machen es populär?
  • Wie grenzt es sich von anderen Plattformen ab (z.B. libvirt?)
  • Wie greifen Spring-boot, Jenkins, Docker und Kubernetes zusammen?

 

Die Materialien finden Sie wie immer unter dem folgenden Github Link.

02.06.2017 - Ausführbare Architekturen Teil 2 [mehr Information] [Material]

Am 2. Juni gab es das Follow-Up zu "Ausführbare Architekturen".

Es folgte ein hands-on workshop, wo wir ein paar Szenarien in kleinen Gruppen gemeinsam attackierten.

Uwe Wardenbach brachte ein Beispiel mit, (Simulation von Infrastrukturausfällen, um zu prüfen, ob das Failover-Konzept funktioniert).

Als Nebeneffekt fiel praktische Übung mit Groovy und Spock mit ein paar (hoffentlich coolen) Tips an.

Eventuell kam auch eine Demo hinzu, wie man mit AST-Transformationen Richtung Doku/Grafik-Generator gehen kann.

Material vom 1. und 2. Termin findet Ihr unter: https://github.com/goldschmiede/2017-03-31-ausfuehrbare-Architekturen

 

 

31.03.2017 - "ausführbare Architekturen" [mehr Information] [Material]

 

Bei der Goldschmiede mit Uwe Wardenbach ging es um "ausführbare Architekturen" mit einfachen (etwa Groovy-) Mitteln im DDD-Kontext (domain-driven-design).

Was ist ein Architekturmodell? Habt Ihr eins?

Auf diese Frage wird meistens (entweder stolz oder peinlich berührt) ein Diagramm hervorgekramt.
Diagramm, richtig, Kästchen, Linien und Beschriftungen.

Im Prinzip gut, aber

  • sind alle benötigten Konnektoren als Linien vorhanden?
  • sind alle benötigten Komponenten als Kästchen vorhanden?
  • sind die Beschriftungen alle korrekt?
  • und was bedeutet das alles?

Markus Völter hat schon vor Jahren auf den wichtigen Unterschied zwischen Modell und Diagramm hingewiesen. Modell ist besser.

Ok, dann nehmen wir ein Modell. UML, nicht wahr, da war doch was.
Wir benutzen ein UML-Tool, dann bedeuten die Linien und Kästchen auch was (über das Metamodell).

Im Prinzip gut, aber

  • ist das Modell syntaktisch korrekt?
  • ist das Modell semantisch vollständig?
  • und wie finde ich heraus, ob was fehlt?

Damit schlagen sich alle herum, die aus irgendeinem Grund meinen, Architektur ist mehr, als die Source-Code-Struktur aus 15 m Entfernung.

Geht´s auch anders? Besser? Vielleicht sogar testbar?

Dann hätten wir doch am liebsten eine Architektur, die man ausführen und testen kann. Klingt spannend, oder?

Uwe Wardenbach zeigte ein ausführliches Beispiel aus einem realen Projekt, woraufhin wir alle gemeinsam ein bisschen experimentieren wollten. 

 

 

 

 

 

02.12.2016 - Continuous Integration follow up [mehr Information] [Material]

16 Jahre nach dem Erscheinen des Artikels "Continuous Integration" von Martin Fowler und 9 Jahre nach dem Erscheinen des Buches "Continuous Integration: Improving Software Quality and Reducing Risk" von Paul M. Duvall, Steve Matyas, Andrew Glover, sind zahlreiche Werkzeuge rund um diese Thematik entstanden. Das sind Werkzeuge nicht nur für automatisierte Builds, sondern auch für die Bereiche wie "Continuous Database Integration", "Continuous Inspection" und " Continuous Deployment".

Bereits bei unserem ersten Treffen zu diesem Thema vor 2 Monaten gab es eine rege Diskussion über zugehörige Tools, so dass aus Zeitgründen nicht alle Aspekte angesprochen werden konnten. Auch um uns noch ausführlicher mit Ansätzen zur Unterstützung der täglichen Arbeit beschäftigen zu können, hatten wir nun diesen follow-up Termin angesetzt. Schwerpunkt war diesmal die Automatisierung von Konfiguration und Orchestrierung mit Ansible sowie die Versionierung von Datenbankschemata mit Flyway.

Die Veranstaltung fand wie immer in den Räumlichkeiten der anderScore, Frankenwerft 35, 50667 Köln statt. 

 

Wir haben uns gefreut, dass Ihr dabei wart!