Das halbe Jahr ist fast rum, höchste Zeit einmal die Tabelle mit meinen Workshop-Terminen für dieses Jahr zu aktualisieren. Ganze zehn Workshops wird es dieses Jahr noch geben!
Archiv der Kategorie: Allgemein
Digitaltag 2024
Auch dieses Jahr wird es zum bundesweiten Digitaltag am 7. Juni wieder den beliebten Workshop „Kleine Roboter bauen mit LEGO WeDo“ geben. Veranstaltungsort ist die Bücherhalle Hamburg Volksdorf. Anmelden könnt ihr eure Kids im Alter zwischen 8 und 10 Jahren direkt vor Ort oder telefonisch unter 040 / 609 122 90.
Lego-Roboter Workshop für Mädchen
Am 16.03.2024 wird es in der Bücherhalle Hamburg Volksdorf den ersten Lego-Roboter Workshop geben, der sich ausschließlich an junge Ingenieurinnen und Programmiererinnen wendet.
Aus Lego-Steinen bauen wir zunächst gemeinsam einen Roboter und programmieren diesen mithilfe einer einfachen, grafischen Programmiersprache auf einem Tablet. Diesen erweitern wir um einen Sensor, um mit der Umwelt zu interagieren. Anschließend habt ihr noch viel Zeit, andere Modelle zu bauen oder auch eureren eigenen Kreativität freien Lauf zu lassen.
Anmeldungen bitte über die Bücherhalle, entweder direkt vor Ort oder telefonisch unter 040 60912290.
JavaLand4Kidults – Das große Rennen!
Auf der diesjährigen JavaLand wird es, passend zum Veranstaltungsort am Nürburgring, eine JavaLand4Kidults geben, bei der sich alles um das Thema Motorsport drehen wird.
Findet euch in Teams von maximal drei Personen zusammen und baut aus Klemmbausteinen einen Rennwagen. Im großen Finale am Mittwoch wird dann das Gewinnerteam ermittelt. Zum Bau stehen euch die auf der JavaLand4Kids eingesetzten Sets Lego WeDo 2.0 und Lego EV3 Mindstorms sowie der Apitor Robot X vom alternativen Hersteller OpenBricks. Zur Programmierung könnt ihr die Apps der Hersteller verwenden – oder für die Kracks unter euch, auch die eigene Lieblingsapp.
Lediglich Tablets stehen nur in begrenzter Zahl und auch nur für die Wedo und Apitor zur Verfügung. Bitte bringt eurer eigenes Tablet oder euren eigenen Laptop mit.
Ihr könnt euch ab Montag Abend und am Dienstag zusammenfinden, und dann euren Boliden bauen, testen und optimieren.
Und zu Gewinnen wird es selbstverständlich auch etwas geben:
Komm machen! Kids4IT auf der CodeWeek!
Vom 7. bis 22. Oktober findet dieses Jahr die CodeWeek statt. Besucht mich am Stand der Kids4IT während der Auftaktveranstaltung in der Zentralbibliothek am Hühnerposten.
Wir zeigen euch, wie man mit Neuronalen Netzen Lego-Roboter steuern kann.
Geschützt: Tag 1 (noch 188)
Bits, Kids & Karusselle: JavaLand4Kids 2023
Mein Beitrag „Bits, Kids und Karusselle“ über die JavaLand4Kids im Frühjahr im Phantasialand ist in der aktuellen Ausgabe 05/23 der „Java aktuell“ erschienen.
Viel Spaß beim Lesen und vielen Dank an alle, die mich bei der Erstellung dieses Beitrags unterstützt haben.
Ein Weihnachtsgedicht
Das Christkind kommt zur Nacht
in stiller, heil’ger Pracht.
Es bringt uns Geschenke und Freud‘,
die Herzen leuchten hell und heut.
Es klopft an jedes Fensterlein,
die Augen leuchten fein und rein.
Es flüstert leise, sanft und mild:
„Frohe Weihnacht, liebes Kind!“
Es schenkt uns Glück und Frieden ein,
die Welt erscheint in heller Schein.
Es wünscht uns allen fröhliches Beisammensein,
in dieser heiligen, stillen Zeit.
Okay, ist nicht von mir, sondern von ChatGPT. Das Gedicht ist das Ergebnis meiner allerersten Anfrage bei der KI:
„Vom Christkind“ von Anna Richter ist mein Lieblingsgedicht. Kannst du ein ähnliches schreiben?
Faszinierende Technik. Für Weihnachtsgrußkarten ausreichend, oder? Mir fehlte aber der Wald:
Hmm, mir fehlt da was mit Wald im Gedicht.
Daraufhin wurde folgendes Gedicht generiert:
Im tiefen, dunklen Walde
ist es still und kalt.
Doch wenn das Christkind kommt,
leuchtet alles golden.
Die Bäume sind geschmückt,
die Luft ist voller Duft.
Es flüstert durch die Zweige:
„Frohe Weihnacht, liebes Volk!“
Der Schnee bedeckt den Boden,
die Sterne funkeln oben.
Es wird ein Fest gefeiert,
an diesem heiligen Ort.
Das Christkind bringt uns Freude,
in dieser stillen Nacht.
Es schenkt uns Liebe, Glück und Frieden,
in diesem wunderschönen Wald.
Okay, ist halt eine KI oder kein Dichter noch Denker…
From Hamburg to Hannover and back to Jorvik
Die letzten Wochen waren mit reichlich Workshops gespickt. Los ging es am 6. Oktober mit einem tollen Workshop auf dem Java Forum Nord. Vierzehn Schüler:innen der Montessori-Schule Hannover konnten dort gut drei Stunden lang kleine Roboter aus Legosteinen bauen und programmieren. Das kam so gut an, dass sich die Schule überlegt, das LEGO Education WeDo 2.0 Set auch anzuschaffen!
Kurze Luft schnappen und weiter ging es am 8. Oktober mit der Auftaktveranstaltung der Code Week in der Zentralbibliothek in Hamburg. Dort unterstützte ich zusammen mit Jens Blömer unseren Kids4IT-Mastermind Oliver Hook bei seinen beiden Sonic-Pi Workshops. Hier können Jugendliche Musik „programmieren“. Obwohl sich ältere Kinder eher weniger für MINT-Workshops begeistern lassen, waren beide Kurse bereits einige Tage zuvor ausgebucht. Der Weg über die Musik – viele der Teilnehmer:innen spielen selbst ein Musikinstrument – bietet hier einen alternativen Zugang zur Informatik.
Weiter ging es mit meinen eigenen Workshops im Rahmen der Code Week in der Bücherhalle Hamburg Volksdorf. Dort bot ich in diesem Jahr zwei Kurse an: Einen für ältere Kinder (Apitor Robot X) und den sehr beliebten, wieder lange im vorraus ausgebuchten Workshop für jüngere Kinder (siehe Hannover). Aber bei beiden Veranstaltungen verliessen Kinder mit strahlenden Gesichtern die jeweils drei-stündigen („Was, jetzt schon vorbei? Ich möchte noch weiter bauen…“) Workshops.
Das Finale war gestern auf dem PLAYfestifal im Jupiter. Auf dem Code Week Familiy Dinner habe ich Matthias Löwe kennengelernt; wir sprachen über unsere Tätigkeiten und Matthias berichtete von seinen aktuellen Vorbereitungen zum Festitival unter dem Motto „Take a Breath“. Ich erwähnte, das meine Tochter Star Stable Online spiele, ein Multiplayer-Pferdespiel, bei dem nicht die Quests im Spiel, sondern eigentlich die Interaktionen der Spieler untereinander im Vordergrund stehen. Zur meiner Überrauschung stimmte meine Tochter dem Vorschlag von Matthias und Heiko zu, auf der Speaker’s Corner etwas über das Spiel zu erzählen. Gut zwei Dutzend Zuschauer vor Ort und mehrere hundert online auf Twitch hörten sich den Vortrag an.
Tja, wird wohl Zeit, das Papa auch einen Vortrag auf einer Konferenz hält…
Migration Kickstart-GraphlQL zu Spring Boot GraphQL
Seit Spring Boot 2.7.0 unterstützt das Framework GraphQL mit einer „nativen“ Integration, die auf GraphQL Java basiert. Wer zuvor die Kickstart-Variante genutzt hat, erfährt hier in knappen Zeilen, wie man seine Anwendung migriert.
Konfiguration
Der einfachste Teil. Die Konfigurationsparameter sind nun Teil des Spring-Namensraums. Die beiden wichtigsten Parameter am Besipiel:
Kickstart | Spring Boot |
graphql.servlet.mapping | spring.graphql.path |
graphiql.mapping | spring.graphql.graphiql.path |
QueryResolver
In Spring Boot läuft alles über @Controller
statt über Resolver und es kommen vermehrt Annotationen zum Einsatz. Hier ein einfaches Beispiel:
// Kickstart
@Component
public class Query implements GraphQLQueryResolver {
private final EntityManager entityManager;
public Marktpartner marktpartner(Long id) {
return entityManager.find(Marktpartner.class, id);
}
}
// Spring Boot
@Controller
public class Query {
private final EntityManager entityManager;
@QueryMapping
public Marktpartner marktpartner(@Argument Long id) {
return entityManager.find(Marktpartner.class, id);
}
}
Wenn im GraphQL-Schema weitere Attribute definiert waren, die nicht im zurückgegebenen Objekt enthalten waren, oder um Assoziationen aufzulösen, wurden weitere Resolver-Klassen geschrieben. In Spring Boot gibt es hierfür das @SchemaMapping
:
// Kickstart
@Component
public class MarktpartnerResolver implements GraphQLResolver<Marktpartner> {
public String getUri(Marktpartner marktpartner) {
return String.format(URL_VISITENKARTE, marktpartner.getId());
}
public Set<Marktfunktion> getMarktrollen(Marktpartner marktpartner, MarktrollenFilter filter) {
return repository.find...
}
}
@Controller
public class MarktpartnerResolver {
@SchemaMapping(typeName = "Marktpartner", field = "uri")
public String getUri(Marktpartner marktpartner) {
return String.format(URL_VISITENKARTE, marktpartner.getId());
}
@SchemaMapping(typeName = "Marktpartner", field = "marktrollen")
public Set<Marktfunktion> getMarktrollen(Marktpartner marktpartner, @Argument MarktrollenFilter filter) {
return repository.find...
}
}
Wichtig ist hierbei, das nur in @Controller
-annotierten Klassen nach @QueryMapping
oder @SchemaMapping
gesucht wird.
Relay-Unterstützung
In Spring Boot gibt es noch keine Unterstützung für Relay. Deshalb ist es notwendig, das Schema anzupassen. Dies führt nach meinem jetzigen Kenntnisstand leider auch dazu, dass Clients angepasst werden müssen, jedenfalls, wenn man erst einmal den einfachsten Weg geht.
// Kickstart
type Query {
marktpartner(id: ID!) : Marktpartner!
marktpartners(first: Int, after: String, last: Int, before: String, filter: MarktpartnerFilter) : MarktpartnerConnection @connection(for: "Marktpartner")
}
# Relay.js types:
# ---------------
interface Node {
id: ID
}
type PageInfo {
hasNextPage: Boolean!
hasPreviousPage: Boolean!
startCursor: String
endCursor: String
}
type Marktpartner implements Node {
id: ID!
name: String!
// ...
}
// Spring Boot
type Query {
marktpartner(id: ID!) : Marktpartner!
marktpartners(first: Int, after: String, last: Int, before: String, filter: MarktpartnerFilter) : Connection
}
# Relay.js types:
# ---------------
interface Node {
id: ID
}
type PageInfo {
hasNextPage: Boolean!
hasPreviousPage: Boolean!
startCursor: String
endCursor: String
}
type Connection {
edges: [Edge]
pageInfo: PageInfo
}
type Edge {
cursor: String!
node: Node!
}
type Marktpartner implements Node {
id: ID!
name: String!
// ...
}
Hinzu gekommen sind also die expliziten Typ-Definitionen für Connection und Edge.
Die obige Lösung führt jedoch dazu, dass Anfragen des Clients angepasst werden müssen:
// Kickstart
query Marktpartner($first: Int, $filter: MarktpartnerFilter, $marktrollen: MarktrollenFilter) {
marktpartners(first: $first, filter: $filter) {
edges {
cursor
node {
id
name
}
}
}
}
// Spring Boot
query Marktpartner($first: Int, $filter: MarktpartnerFilter, $marktrollen: MarktrollenFilter) {
marktpartners(first: $first, filter: $filter) {
edges {
cursor
node {
id
... on Marktpartner {
name
}
}
}
}
}
Außerdem wird noch eine TypeResolver
-Implementierung benötigt:
// Spring Boot
public class NodeTypeResolver implements TypeResolver {
@Override
public GraphQLObjectType getType(TypeResolutionEnvironment env) {
Object object = env.getObject();
if (object instanceof Marktpartner) {
return env.getSchema().getObjectType("Marktpartner");
}
throw new UnsupportedOperationException("NodeTypeResolver unvollständig für das Objekt " + object);
}
}
Testing
Am längsten hat die Umstellung der integrativen Tests gedauert, da ich dazu bisher nur wenige Beispiele gefunden hatte. Das wichtigste dabei: Es wird spring-webflux benötigt, auch wenn die Anwendung selbst gar nicht fluxig ist:
pom.xml (Spring Boot)
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-graphql</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.graphql</groupId>
<artifactId>spring-graphql-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-webflux</artifactId>
<scope>test</scope>
</dependency>
Für Tests gibt es in Spring Boot die Klasse GraphQlTester
und davon diverse Unterklassen für verschiedene Einsatzszenarien. Mein integrativer Test sieht nach der Umstellung wie folgt aus::
@Transactional
@SpringBootTest
class QueryIT {
private WebGraphQlTester tester;
@Autowired
private ObjectMapper objectMapper;
// ...
@Autowired
private WebApplicationContext context;
@BeforeEach
void before() {
WebTestClient webTestClient = MockMvcWebTestClient.bindToApplicationContext(context)
.configureClient()
.baseUrl("/api/graphql")
.defaultHeaders(headers -> headers.setBasicAuth("test", "test"))
.build();
tester = HttpGraphQlTester.create(webTestClient);
// Testdaten anlegen ...
}
@Test
void findetMarktpartnerUeberNameUndMarktrolle() {
MarktpartnerFilter filter = MarktpartnerFilter.builder().namensteil("acme").build();
MarktrollenFilter marktrollenFilter = MarktrollenFilter.builder()
.marktrollen(List.of(MarktfunktionRolle.LIEFERANT))
.build();
ObjectNode variables = objectMapper.createObjectNode();
variables.set("filter", objectMapper.convertValue(filter, ObjectNode.class));
variables.set("marktrollen", objectMapper.convertValue(marktrollenFilter, ObjectNode.class));
variables.put("first", 10L);
tester.documentName("marktpartners")
.variable("filter", variables.get("filter"))
.variable("marktrollen", variables.get("marktrollen"))
.variable("first", variables.get("first"))
.execute()
.path("marktpartners.edges").entityList(EdgeDummy.class).hasSize(1)
.path("marktpartners.edges[0].node.name").entity(String.class).isEqualTo("ACME Energie GmbH")
;
}
}
Zunächst wird also ein WebTestClient
erzeugt und konfiguriert und anschließend ein HttpGraphQlTester
. Dieser wird dann im eigentlich Test verwendet, um einen GraphQL-Aufruf durchzuführen. Wird wie oben eine documentName("marktpartners")
angegeben, dann sucht das System die Datei resources/graphql-test/marktpartners.graphql
. Alternativ kann mit der Methode document
die GraphQL-Anfrage als String übergeben werden.
Mit execute
wird die Anfrage gesendet und anschließend das Ergebnis geprüft. Hier kommen die path
-Aufrufe zum Einsatz und Standardvergleichsmethoden wie hasSize
oder isEqualTo
.
Stolperfallen und andere Anomalitäten
Kleine Sammlung von Inkompatibilitäten zum Verhalten von Kickstart-GraphQL:
- Verwende
List
stattSet
(beiSet<Enumtyp>
gab es Exeptions, dass auf ein Property nicht zugegriffen werden kann) - Bean-Standard für Rückgabe-DTOs einhalten, also Methoden nicht
edges()
benennen sonderngetEdges()