Autor: Firma punkt.de

1_Forge: Drei Agenturen, ein Schulterschluss – für starke TYPO3-Projekte auf Augenhöhe

1_Forge: Drei Agenturen, ein Schulterschluss – für starke TYPO3-Projekte auf Augenhöhe

In der digitalen Agenturwelt ist oft von Zusammenschlüssen die Rede. Von Synergien, Skalierung und neuen Allianzen. Klingt erstmal nach Business-Bingo, aber was, wenn da wirklich etwas Neues entsteht? Etwas Echtes. Kein Übernahmeprojekt, keine Holdingkonstruktion, sondern ein ehrlicher Schulterschluss auf Augenhöhe. 

Genau das ist 1_Forge. 

Ein Zusammenschluss von drei Agenturen, die seit vielen Jahren fest im TYPO3-Kosmos verankert sind: dkd aus Frankfurt, sitegeist aus Hamburg – und wir, punkt.de aus Karlsruhe.

 Was uns eint, ist kein Finanzinvestor, sondern ein gemeinsames Verständnis davon, wie gute digitale Projekte entstehen: mit technischer Tiefe, offener Kommunikation, Vertrauen – und einer Community, die wir nicht nur kennen, sondern mitgestalten.

TYPO3 und Open Source Lösungen sind unsere DNA – nicht nur unser Geschäftsmodell

In den letzten Jahren haben wir beobachtet, wie sich der TYPO3-Markt verändert. Große Projekte wandern zunehmend zu Agenturen, die nicht unbedingt tief in der Community verwurzelt sind, dafür aber durch Größe, Buzzwords und Prozesse beeindrucken.

Mit 1_Forge zeigen wir: Es geht auch anders.

Wir bringen zusammen, was zusammengehört: langjährige Projekterfahrung, zertifiziertes TYPO3-Wissen, agile Methoden, eine enge Verbindung zur Open-Source-Community – und die Fähigkeit, auch größere Projekte zuverlässig zu stemmen.

Und das Beste: Wir arbeiten nicht nebeneinanderher, sondern wirklich gemeinsam. Als eingespieltes Team, das sich aufeinander verlassen kann.

Wer ist 1_Forge? Drei Agenturen mit Substanz

dkd Internet Service GmbH (Frankfurt)

Seit über 20 Jahren als Digitalagentur am Markt, rund 60 Spezialist:innen aus Entwicklung, UX, SEO und Beratung. dkd ist TYPO3 durch und durch – mit den weltweit meisten TYPO3-Zertifizierungen, sieben TYPO3-Awards, eigenen Solr-Workshops und großem Engagement in der Community. 

Ihr Geschäftsführer Olivier Dobberkau ist nicht nur Unternehmer, sondern auch Präsident der TYPO3 Association – Community-Nähe ist hier keine Floskel, sondern gelebter Alltag.

sitegeist media solutions GmbH (Hamburg)

Inhabergeführt, rund 70 Mitarbeitende, über 25 Jahre am Markt. sitegeist ist TYPO3-Platinum-Member und Solution Partner mit über 200 realisierten TYPO3-Projekten. 

Sie gehören zu den aktivsten Contributor:innen im TYPO3-Universum und haben zahlreiche Open-Source-Extensions wie Fluid ComponentsEditor Widgets oder SMS Responsive Images initiiert und gepflegt. 

Und was man oft vergisst: sitegeist ist auch methodisch stark. Mit einem eigenen agilen Framework namens RE.A.L. bringen sie Struktur, Geschwindigkeit und Klarheit in komplexe Projekte.

punkt.de GmbH (Karlsruhe)

Wir sind seit über 20 Jahren fester Bestandteil der TYPO3-Community und seit fast 30 Jahren am Markt – als Dienstleister, Event-Organisator:innen, Contributor:innen. 

Wir entwickeln sichere, wartbare und skalierbare digitale Plattformen – von Identity Management über Single Sign-On bis zu Portalen mit tief integrierten Prozessen. Und wir glauben an Open Source: Wir gestalten mit, wir sponsern, wir zeigen Präsenz. 

Unter anderem mit den TYPO3 Developer Days, die wir seit Jahren aktiv organisieren – weil wir daran glauben, dass gelebte Community echten Mehrwert schafft

Zusammen mehr als die Summe unserer Teile

Mit mehr als 160 Kolleg:innen, einem gemeinsamen Jahresumsatz von über 15 Mio. € und einer Projektkultur, die auf Vertrauen, Verantwortung und Qualität setzt, ist 1_Forge eine echte Alternative im Markt:

  • Stark genug für große, komplexe Projekte
  • Schnell genug für agile MVPs
  • Eng genug verbunden, um als echtes Team aufzutreten

Und: Wir kennen unsere Stärken – und die unserer Partner. 

Unsere Kunden profitieren davon, dass sie nicht drei Dienstleister managen müssen, sondern mit einem eingespielten Team arbeiten, das ihnen Lösungen bietet – abgestimmt, durchdacht, langfristig.

TYPO3 braucht Haltung – und Menschen, die Verantwortung übernehmen

Dass wir diesen Schritt gehen, ist kein Zufall. Es ist auch eine bewusste, wirtschaftlich fundierte Entscheidung: Wir glauben an TYPO3. Und an Open Source. Und wir glauben, dass wir damit langfristig bessere Projekte realisieren – für öffentliche Auftraggeber, für Unternehmen, für Organisationen mit Verantwortung.

Wir sind überzeugt: Die Zukunft gehört den Netzwerken, nicht den Einzelkämpfern. Und den Teams, die sich nicht nur kennen, sondern vertrauen.

Deshalb ist 1_Forge kein kurzfristiger Pitch-Verbund, sondern ein Commitment.

Lust, uns kennenzulernen?

Wir sind auf der T3CON mit einem gemeinsamen Stand vor Ort. Komm vorbei, sprich mit uns, lerne die Menschen hinter 1_Forge kennen.

Oder schau mal auf 1forge.de vorbei – da erfährst du mehr über uns, unsere Projekte, unser Miteinander.

Wenn du gerade auf der Suche nach einer Agentur bist, die nicht nur Buzzwords liefert, sondern Verantwortung übernimmt – dann lass uns reden

Wir freuen uns auf den Austausch.

Zur 1_Forge Website

Über die punkt.de GmbH

Das Karlsruher Unternehmen punkt.de entwickelt mit über 35 Mitarbeiter:innen kundenspezifische digitale Software-Lösungen im Enterprise-Bereich und bietet maßgeschneiderte Hosting-Infrastruktur-Lösungen für jene Anwendungen an. Hierdurch zählt sie zu den führenden Agenturen für Webprojekte mit TYPO3 und Neos in Deutschland. Zu den Kunden von punkt.de gehören namhafte Unternehmen wie die CompuGroup Medical, die BIKAR Metals GmbH oder die Karlsruher Hilfsorganisation nph deutschland e. V.

Firmenkontakt und Herausgeber der Meldung:

punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de

Ansprechpartner:
Fabian Stein
Geschäftsführer
Telefon: +49 (721) 9109-124
E-Mail: stein@punkt.de
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Digitale Souveränität: bewusste Entscheidungen statt Dogma

Digitale Souveränität: bewusste Entscheidungen statt Dogma

Digitale Souveränität wird im Alltag oft falsch verstanden. Für viele bedeutet sie Verzicht: auf bekannte Tools, auf Komfort, auf Geschwindigkeit. In unserer täglichen Arbeit sehen wir das anders.

Wenn ich an digitale Souveränität denke, dann denke ich oft zuerst daran, was ich nicht möchte: den reflexhaften Einsatz von Werkzeugen wie der Google Suite, die ich bei vielen Organisationen sehe. Für mich ist das ein Symbol dafür, wie schnell sich Unternehmen in Abhängigkeiten begeben, ohne sich die Konsequenzen klarzumachen. 

Das zeigt zugleich ein typisches Missverständnis: Digitale Souveränität wird oft über Verzicht oder Dogma definiert. Manchmal wirkt es fast wie ein „digitales Vegan-Sein“ – viele wissen, dass es gesellschaftlich besser wäre, aber es erscheint unbequem, man muss sich rechtfertigen, und man hat das Gefühl, nicht mehr so einfach überall mitzumachen. 

Dabei geht es gar nicht darum, alles strikt Open Source zu betreiben oder jeden DNS-Record selbst in der Hand zu halten. Für mich und für uns bei punkt.de bedeutet digitale Souveränität etwas anderes: bewusst Entscheidungen zu treffen. Zu verstehen, welche Daten wie verarbeitet werden, welche man besonders schützen will – und wo es völlig ausreicht, auf Standards oder etablierte Systeme zu setzen.

Digitale Souveränität im Mittelstand: Risiko und Chance

Fehlende digitale Souveränität bedeutet für mittelständische Unternehmen vor allem eines: Abhängigkeit. Und diese zeigt sich oft erst dann, wenn es eigentlich schon zu spät ist.

Ein Beispiel aus unserem eigenen Alltag ist das Thema Jira und Confluence. Schon 2012 haben wir uns bei punkt.de entschieden, von Redmine auf Atlassian-Produkte zu wechseln. Wir waren damals begeistert von den Möglichkeiten – und nutzen sie bis heute intensiv. Doch inzwischen zwingt Atlassian seine Kunden in die Cloud. Das bedeutet: deutliche Preissteigerungen, keine Wahlfreiheit mehr und die Pflicht, sensible Daten in einer amerikanischen Cloud abzulegen.

Das Problem dabei ist nicht allein die Cloud. Das eigentliche Problem ist der Vendor Lock-in. Ein Wechsel zurück oder zu einem anderen System ist möglich, aber nur unter extrem hohen Aufwänden und mit hohen Kosten. Unsere Datensouveränität ist hier massiv eingeschränkt. 

Ganz anders verhält es sich in einem anderen Bereich: Mail und Kalender. Auch hier setzen wir auf Microsoft 365 – aber mit einem entscheidenden Unterschied. Mail und Kalender basieren auf langjährig erprobten offenen Standards (IMAP, CalDAV etc.). Das bedeutet: Sollten wir eines Tages entscheiden, dass Microsoft nicht mehr zu uns passt, können wir vergleichsweise einfach zurück zu Open-Source-Lösungen oder in andere Systeme wechseln. Unsere Daten sind portabel, die Hoheit bleibt bei uns.

Diese beiden Beispiele zeigen sehr deutlich, worum es bei digitaler Souveränität geht: nicht Dogma, sondern Handlungsfähigkeit.

Unser Ansatz bei punkt.de – ein anderer Default

Was uns bei punkt.de unterscheidet, ist die Haltung, mit der wir an Probleme herangehen. Unser Default sieht so aus:

  1. Zuerst prüfen wir: Gibt es eine gute Open-Source-Lösung?
  2. Dann prüfen wir: Gibt es eine starke europäische Lösung?
  3. Erst dann greifen wir auf internationale Player zurück.

Das bedeutet nicht, dass wir dogmatisch jede Funktion oder jedes Projekt unter die Maxime der Datensouveränität stellen. Sondern dass wir bewusst abwägen: Welche Daten sind kritisch, wo brauchen wir maximale Hoheit – und wo genügt pragmatische Integration?

Begeisterung für Open Source

Unsere erste Liebe gehört nach wie vor Open Source. Warum? Weil Open Source Unabhängigkeit und Sicherheit bedeutet. Freiheit, Systeme zu verstehen, anzupassen und – wenn es hart auf hart kommt –selbst weiterzubetreiben. Für uns begann diese Geschichte früh: In den 2000ern stellte ein Hersteller das CMS ein, das wir damals einsetzten. Wir mussten für unsere Kunden kostenfreie Migrationen stemmen. Eine schmerzhafte Erfahrung – und der Beginn unserer Reise mit TYPO3.

TYPO3 war ein Augenöffner: Egal, was mit der Community passiert, wir behalten Zugriff auf die Daten. Wir können das System selbst betreiben, erweitern, anpassen. Diese Erfahrung prägt uns bis heute. Open Source ist für uns deshalb nicht nur ein Geschäftsmodell, sondern eine Überzeugung. Nicht, weil es „kostenlos“ ist oder weil man es ideologisch „muss“ – sondern weil es Unternehmen die Freiheit gibt, souveräne Entscheidungen zu treffen.

Und es begeistert uns immer wieder, wie leistungsfähig Open-Source-Produkte geworden sind. Ob Content-Management, Automatisierung oder Kollaboration: Für viele Probleme gibt es heute Open-Source-Lösungen, die es locker mit den großen internationalen Playern aufnehmen können.

Wo wir abwägen: Praxisbeispiele

Die Realität ist nie schwarz-weiß. Zwei Beispiele aus unserer Arbeit verdeutlichen das:

  • Fegime Extranet: Ein Extranet, in dem hochkritische Marktdaten zwischen verschiedenen Playern ausgetauscht werden. Ein SharePoint-Setup wäre technisch möglich gewesen – aber zu unflexibel, zu wenig souverän. Hier war ein individuelles Open-Source-Extranet die richtige Wahl.
  • Marketing Automation: Ganz anders die Welt der Marketing-Automatisierung. Wenn ein Unternehmen bereits Salesforce einsetzt, ist die Marketing Cloud oft sinnvoller als Mautic – einfach, weil die Integration nahtlos ist. Mautic ist gut, aber in diesem Szenario nicht die optimale Wahl.

Das Entscheidende ist: Wir wägen ab. Wir schauen, welche Datenströme kritisch sind, welche Freiheitsgrade notwendig sind und wo Pragmatismus wichtiger ist als Ideologie.

Typische Missverständnisse im Mittelstand

In Gesprächen mit Entscheidern begegnen uns zwei Irrtümer besonders häufig:

  1. Alles oder nichts: Entweder totale Kontrolle oder totale Abhängigkeit. Doch die Realität ist ein Kontinuum, und genau dort liegt die Chance.
  2. Souveränität als Verhinderer: Viele denken, digitale Souveränität heißt Einschränkung – „das Tool dürfen wir nicht nutzen“. In Wahrheit ist es umgekehrt: Souveränität eröffnet neue Möglichkeiten, macht Datenströme flexibler und schafft mehr Handlungsspielraum.

Warum punkt.de der richtige Partner ist

Unsere Haltung zur digitalen Souveränität ist nicht aus der Mode geboren, sondern aus Erfahrung. Schon vor über 20 Jahren haben wir gelernt, was passiert, wenn man sich zu sehr auf proprietäre Anbieter verlässt.

Seitdem begleiten wir Unternehmen dabei, souverän mit ihren Daten zu bleiben – mit Open Source, mit europäischen Lösungen, aber auch mit internationalen Tools, wenn es die beste Entscheidung ist. Entscheidend ist nicht die Ideologie, sondern die Freiheit des Unternehmens, jederzeit handlungsfähig zu sein.

Blick in die Zukunft

Ich bin überzeugt: In den nächsten fünf bis zehn Jahren wird digitale Souveränität noch relevanter werden. Regulatorische Anforderungen werden steigen, Märkte werden strengere Vorgaben machen, und spätestens beim Einsatz von KI wird klar: Nur wer seine Daten souverän beherrscht, kann innovativ bleiben.

Für den Mittelstand bedeutet das: Digitale Souveränität ist kein Nischenthema. Sie ist eine strategische Aufgabe.

Fazit

Digitale Souveränität ist kein Dogma, kein Verzichtsprojekt und kein Trend. Sie ist die Fähigkeit, bewusst Entscheidungen zu treffen und Daten so zu behandeln, dass man heute und in Zukunft handlungsfähig bleibt.

Bei punkt.de leben wir diese Haltung seit über 20 Jahren. Wir denken zuerst in Open Source, dann europäisch, und wir greifen zu internationalen Lösungen, wenn es sinnvoll ist. Immer mit einem Ziel: unseren Kunden die Freiheit zu geben, ihre Daten im Griff zu behalten – und damit souverän in die digitale Zukunft zu gehen.

Firmenkontakt und Herausgeber der Meldung:

punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de

Ansprechpartner:
Fabian Stein
Geschäftsführer
Telefon: +49 (721) 9109-124
E-Mail: stein@punkt.de
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

FEGIME Extranet – Open Source im Mittelstand

FEGIME Extranet – Open Source im Mittelstand

 

Der Kunde

Die Abkürzung „FEGIME” steht für „Fédération Européenne des Grossistes Indépendants en matériel électrique” (Europäischer Verband der unabhängigen Elektrogroßhändler). In der FEGIME Deutschland GmbH & Co. KG (FEGIME) sind ca. 45 Familienunternehmen des Elektrogroßhandels organisiert. Die FEGIME Deutschland ist über Jahrzehnte durch Fusionen von mittelständischen Marktgemeinschaften entstanden. Die Gesellschafter:innen setzen ca. 2,4 Milliarden Euro (2023) in Deutschland um und sind an über 160 Standorten vertreten (Details: https://www.fegime.de/…)

Das Problem – 15 Jahre Techdebt

Für die FEGIME als Marktgemeinschaft ist es sehr wichtig, die Abstimmung und Kommunikation ihrer Gesellschaften an einem Ort zu bündeln. Dabei setzte sie auf ein selbst entwickeltes Extranet, das über 15 Jahre hinweg gute Dienste geleistet hat. Das Extranet wurde intern betrieben und weiterentwickelt, allerdings beruhte es auf einer monolithischen Architektur und stieß nach dieser langen Zeit in vielen Bereichen an seine Grenzen.

Einerseits gab es viele Probleme im Bereich Design, UI und UX sowie Performance, andererseits gab es technische Probleme bei der Entwicklung neuer Funktionen. Die alltägliche Nutzung des Extranets gestaltete sich auf FEGIME- und Gesellschafterseite zunehmend schwierig und mühselig. Auch der Betrieb und die Wartung des Systems wurden durch einen Generationswechsel in der internen IT immer schwieriger.

Unser Auftrag war es, ein neues Extranet zu entwickeln, das folgende Ziele erfüllen musste:

  • Zentrales Informationsmanagement
  • Effiziente Kommunikation (intern, extern)
  • Striktes Rechtesystem um regulatorische Anforderungen zu erfüllen (Kartellrecht)
  • Die Kernwerte der FEGIME sollten sich im neuen Extranet wiederfinden
  • Strukturiertes Dokumentenmanagement
  • Kostenreduktion durch einfachere Prozesse und Skalierung
  • Ein intuitives Design mit optimierter UI und UX, das die Arbeit mit dem Extranet vereinfacht

Ein neues Extranet

Schon im ersten Workshop für das neue Extranet wurde schnell klar, dass vor einer Entwicklung viel grundlegende Konzeptarbeit nötig war. Das alte Extranet war über einen Zeitraum von 15 Jahren gewachsen. Es musste Komplexität aus dem System genommen werden, ohne dabei entscheidende Prozesse zu verlieren, während gleichzeitig neue Funktionen umgesetzt wurden. Da im Extranet sensible und wirtschaftlich kritische Informationen für die Gesellschafter zu finden sind, war auch das Thema Datenhoheit bei der Konzeption zu berücksichtigen.

Neben dieser Konzeptarbeit mussten auch diverse Schnittstellen, beispielsweise zu Shops und Datenbanken, eingeplant werden, um die vier Millionen Artikel der Gemeinschaft zu verwalten.

All dies sollte selbstverständlich extrem performant und für die Nutzer auf FEGIME- und Gesellschafterseite, die das Extranet täglich nutzen, attraktiv gestaltet sein.

Zudem sollte das neue Extranet auf einem modernen Kern aufbauen, der sich auch in Zukunft leicht weiterentwickeln lässt und die strengen Vorgaben an ein striktes und robustes Rechtesystem erfüllt. Die Bildung von Techdebt sowie die Bindung an einen Anbieter sollten vermieden werden.

Warum Open Source?

Zusammengefasst laufen die Anforderungen an das neue Extranet auf eine Anwendung hinaus, die sicher, performant, flexibel und unabhängig sein muss. Open-Source-Lösungen bringen all diese Eigenschaften (und noch mehr) mit sich.

Sicherheit

Der Kern der Anwendung ist TYPO3. Als quelloffenes CMS mit einer großen Community hat es sich in den letzten Jahrzehnten etabliert und liefert ein extrem gutes und robustes Berechtigungssystem. Zudem dient es als Data-Provider. Eine sehr aktive Community überwacht die Sicherheit des CMS und reagiert schnell auf aktuelle Bedrohungen. 

Performance

Durch den Einsatz von TYPO3 als Kern und einem selbst entwickelten React-Frontend waren wir in der Lage, die Reaktionszeiten zu optimieren. Für die Suche setzen wir auf Solr mit eigenen Indizes, was für die Nutzer zu spürbaren Verbesserungen bei der Suche nach Informationen im Extranet geführt hat und somit die Akzeptanz der neuen Anwendung fördert.

Flexibel

In der Konzeptionsphase wurden Workshops mit den verschiedenen Fachbereichen (Lieferanten, Einkauf, Marketing, IT etc.) durchgeführt. Dadurch war es möglich, individuell auf die Anforderungen der einzelnen Bereiche einzugehen und die entsprechenden Funktionen passgenau zu entwickeln. Zusammen mit einer guten Dokumentation und offenem Code ist es ein Leichtes, die Anwendung weiterzuentwickeln und auch in Zukunft zu betreiben.

Unabhängigkeit

Die Themen „Datensouveränität” und „Vendor-Lock-in” sind aktueller denn je. Auch in diesem Projekt war es der FEGIME wichtig, Herr über die eigenen Daten zu sein. Da im Extranet sensible und auch wirtschaftlich kritische Informationen für die Gesellschafter ausgetauscht werden, müssen sowohl die Sicherheit als auch die Souveränität gewährleistet sein. Doch was bedeutet das?

Diese Anforderung bezieht sich sowohl auf das Hosting der Anwendung als auch auf den Code. Ein großer Vorteil von Open-Source-Lösungen ist, dass der Code nicht der Agentur, sondern dem Kunden (in diesem Fall der FEGIME) gehört. Der entwickelte Code ist offen und kann von der IT des Kunden eingesehen und verwaltet werden. Sollten sich die Rahmenbedingungen für die Anwendung oder die Zusammenarbeit mit der Agentur in Zukunft ändern, gehören der Code und alle Daten dem Auftraggeber. Das ist ein wesentlicher Unterschied zu Anbietern proprietärer Software.

Open Source für den Mittelstand

Unser FEGIME-Projekt ist ein sehr gutes Beispiel dafür, wie Open Source dem Mittelstand dabei hilft, sich zu modernisieren, ohne sich einem Anbieter auszuliefern. Dabei müssen keine Kompromisse in Bezug auf Sicherheit, Features oder Performance der Anwendung gemacht werden. Auch eine Skalierung der Anwendung ist problemlos möglich.

Mit einer Open-Source-Lösung können mittelständische und auch Großunternehmen Herr über die eigenen Daten bleiben und eine Anwendung entwickeln lassen, die sich genau an ihre Bedürfnisse anpasst. Und das Ganze ist auch noch frei von Lizenzkosten.

Firmenkontakt und Herausgeber der Meldung:

punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de

Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Was Videospiel-Speedruns und Frontend-Entwicklung miteinander zu tun haben

Was Videospiel-Speedruns und Frontend-Entwicklung miteinander zu tun haben

Es gibt Werkzeuge, welche fertigen Code untersuchen können, und Fehler und Sicherheitslücken hervorheben können. Es gibt Listen, welchen man als Entwickler folgen kann.

Aber – wo bleibt denn da der Spaß?

Als begeisterter Computerspieler bin ich ungefähr 2017 auf die Speedrunning-Szene gestoßen, in der es darum geht, ein Videospiel (oder Teile davon) so schnell wie möglich durchzuspielen, wofür Glitches ausgenutzt werden.

"Glitches? Das ist doch nichts anderes als ein Programmierfehler!"

Als Entwickler dachte ich "Glitches? Das ist doch nichts anderes als ein Programmierfehler!" Und damit begann ich, die Speedruns nicht nur mit den Augen eines Spielers, sonder mit den Augen eines Entwicklers zu sehen. Eines meiner Erkenntnisse – Spieleentwicklung und Frontendentwicklung teilen sich gewisse Konzepte und Gedanken – genug, dass es Frontend-Javascript-Frameworks gibt, mit denen Videospiele entwickelt werden können.

Beide Entwicklungs-Umgebungen besitzen Stores zur Datenhaltung und verwenden Events, um Benutzereingaben zu verarbeiten, und bei beiden gibt es ähnliche Fallstricke, wenn ein Benutzer zum falschen Zeitpunkt bestimmte Events auslöst. Bei beiden sollte der Store zentral verwaltet sein und nur definierte, klare Zustände annehmen können.

Als Beispiel für einen Glitch, der sich auf Frontend-Anwendungen abbilden lässt, gibt es zum Beispiel einen der bekanntesten Glitches aller Zeiten – der Backwards Longjump (kurz BLJ) aus Super Mario 64. 

In diesem Spiel ist die Geschwindigkeit, welche Mario aufbauen kann, nach oben hin begrenzt – Rückwärts kann man jedoch beliebig schnell werden, wenn man die korrekten Tasten am Controller drückt. Dadurch kann man so schnell werden, dass Mario sich rückwärts durch eine unsichtbare Wand durchmogeln kann, welche ihn eigentlich immer wieder an den Anfang einer Treppe setzen soll. 

Durch die Geschwindigkeit befindet man sich in einem Frame vor der Wand und im nächsten Frame dahinter, die Kollision an sich findet nie statt. Durch solche Beispiele werde ich als Programmierer gerne daran erinnert, dass ich beim Validieren von User-Eingaben keine Abkürzungen nutzen sollte, und auch nicht davon ausgehen sollte, dass der User nur Daten sendet, die ich auch erwarte, sondern theoretisch jeder beliebige Wert gesendet werden könnte. 

Features, die man "nur noch schnell" einbaut

Weitere Probleme beim Entwickeln sind oft Features, die man "nur noch schnell" einbaut, welche gut gemeint sind, aber vielleicht nicht hundertprozentig notwendig oder nach dem üblichen Qualitätsstandard. Da kann es dann gerne passieren, dass der neue Code Nebenwirkungen hat, welche man als Entwickler nicht erwartet hat. Als Beispiel dafür sehe ich das Spiel The Legend of Zelda – Link’s Awakening, welches voll von derartigen Features ist. Ursprünglich sollte das Spiel ein "Demake" eines Zelda-Spieles auf dem Super Nintendo sein, doch die Entwickler haben ein paar Features implementiert, damit es sich vom Original abhebt. 

Eines dieser Features ist der Bombenpfeil – wenn man eine Bombe innerhalb ein paar Frames nach einem Pfeil einsetzt, wird die Bombe an den Pfeil angehängt und explodiert bei Kontakt. Der Fehler dabei – schafft man es, zwei Bomben hintereinander in diesem kurzen Zeitraum zu legen (beispielsweise durch ein Loch im Boden oder einen Bildschirm-Wechsel), dann weiß das Spiel nicht, wo die zweite Bombe angehängt werden soll, und löst eine Zwischensequenz eines Spiel-Objektes an einer bestimmten Stelle im Code aus. Im Falle von einsammelbaren Gegenständen bedeutet dies, dass man diese aus beliebiger Distanz und durch Wände einsammeln kann. An anderen Stellen im Spiel kann man damit Wege freischalten, die erst später oder durch andere, länger dauernde Methoden geöffnet werden sollten.

Solche Beispiele zeigen mir, dass "nur mal schnell" ein Satz ist, über den man sehr genau nachdenken sollte.

Egal, ob Backend oder Frontend – alle kochen mit Wasser

Außerdem sollten Frontend-Entwickler immer daran denken, dass man im Browser jederzeit auf den ausgeführten Code schauen kann, und dass die diversen Build-Tools wie WebPack, Rollup und Vite oft von den Entwicklern selbst so eingestellt werden, dass Sourcemaps erzeugt werden, welche den Code explizit lesbar machen. Dies bedeutet natürlich, dass jede noch so gute Sicherheitsmaßnahme im Code jederzeit nachvollziehbar ist, und man sich lieber doch auf die Security im Backend-Code verlassen sollte.

Bei Videospielen zeigt sich dies auf zweierlei Arten. Zum einen gibt es die Möglichkeit, auf den Arbeitsspeicher des ausgeführten Spieles zu schauen, um nachvollziehen zu können, welcher Wert z.B. für die Lebenspunkte steht, die Munition oder ähnliches. Wenn man diese Werte versteht und bestenfalls sogar noch manipulieren kann, kann man "perfekte" Speedruns gestalten. Zum Anderen gibt es Projekte, welchen den kompilierten Code von Spielen analysieren und die Abläufe erklären. Dadurch werden z.B. internas wie der verwendete Zufallsgenerator oder auch das Verhalten von Gegnern und anderen Spielmechaniken bekannt gemacht, wodurch neue Glitches und Strategien entwickelt werden können. 

Alles in Allem lässt sich feststellen, dass alle Programmierer – sei es Backend, Frontend, Spiele, Desktop-Anwendungen, … – auch nur mit Wasser kochen, und auf ziemlich ähnliche Probleme achten müssen. Wieso also nicht mal mit Spiel, Spaß und Speed? 

Firmenkontakt und Herausgeber der Meldung:

punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de

Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Mit Cursor zur eigenen App

Mit Cursor zur eigenen App

Ich bin kein Vollzeit-Entwickler, ehrlich gesagt war ich das auch nie. Seit Jahren bin ich als technischer Product Owner unterwegs und habe ein gewisses Verständnis für unsere Setups, aber Programmieren ist definitiv nicht mein Tagesgeschäft. Genau deshalb wollte ich herausfinden, wie weit man mit einem Tool wie Cursor kommt, wenn man einfach mal selbst ein kleines internes Tool baut – ohne den Anspruch, ein „richtiger“ Entwickler zu sein.

1) Stack wählen: Zwischen Anspruch und Realität

Mein erster Reflex: „Wenn schon, denn schon.“ Früher (so um 2010) habe ich lokal mit MAMP gearbeitet; heute weiß ich: wir fahren Docker/Podman, Services sauber getrennt, alles Container. Also habe ich mich an unseren Projekten orientiert und Cursor eine „erwachsene“ Kombi vorgeschlagen: Postgres als DB, Next.js für den API-/Backend-Layer, React fürs Frontend.

Cursor hat das auch prompt auf die Straße gesetzt – nur leider ist die Straße dabei ständig weggebrochen. Mal startete ein Container nicht, mal war das Routing im Eimer, mal blockierte irgendein Nebencontainer den Rest. Und während unsere Dev-Maschinen mit 64 GB RAM darüber müde lächeln, lief meine brave Management-Büchse heiß: fünf parallele Container, um … eine Startseite zu rendern. Ernsthaft?

Warum es sich lohnt, als Geschäftsführer selbst mal zu (vibe-)codenEine völlig neue Möglichkeit für Nicht-Entwickler, die Herausforderungen zu verstehen.Warum ich das überhaupt versuche

Erstes Learning: „Architektur abspecken“ per Prompt klingt gut, funktioniert aber selten. Cursor behauptet, er könne das; wenn ein Projekt aber einmal in die falsche Richtung losgerannt ist, ist wegwerfen und neu starten fast immer schneller und sauberer. Meine Budget-App habe ich fünfmal komplett blank neu aufgesetzt. Das Wissen bleibt ja im Kopf – der Code darf weg. Die Idee war, eine App zu entwickeln, die automatisch einen Überblick über alle Budgets im Unternehmen liefert, indem sie Daten aus unserer Zeiterfassung und den verschiedenen Angeboten nutzt. So kann ich auf alle relevanten Informationen zugreifen, ohne die einzelnen Projekte manuell durchsuchen zu müssen.  

2) Prompting-Aha: Weniger ist manchmal mehr

Nach dem Big-Bang-Fehlschlag kam die nächste (falsche) Idee: „Ist doch KI – wenn ich ihr noch mehr Kontext gebe, wählt sie schon eine kluge Architektur.“ Tat sie auch. Formal korrekt. Praktisch unbrauchbar. Cursor baute engagiert los, fügte Schicht um Schicht hinzu, und nach zwei Stunden war das Einfangen aufwendiger als neu anfangen.

Also habe ich die Richtung gedreht: Schritt für Schritt statt Masterplan. Meine erste wirklich funktionierende Cursor-App war deshalb nicht die Budget-App, sondern ein kleines Monitoring-Dashboard fürs Team.

Klar, unsere Teams brauchen so einen Monitor eigentlich nicht. Wir sind schon vor Jahren auf sinnvolle Alarmierungsstrategien umgestiegen – gerade beim mobilen Arbeiten ist ein Bildschirm im Büro, der rot blinkt, nicht das praktikabelste Mittel. Aber zum Einstieg ins Cursor-Prompting braucht man einen Use Case, der überschaubar ist und trotzdem Nutzen bringt. Und ehrlich: Es hat was Beruhigendes, durchs Teamzimmer zu gehen und grüne Statusanzeigen zu sehen – auch wenn ich weiß, dass bei Fehlern sowieso alle anders benachrichtigt werden.

Der Prompt war radikal simpel: „Nimm diese API und zeig mir das Ergebnis auf einem Dashboard an.“ Kein Architekturessay, keine Datenbankdiskussion. Und plötzlich lief es: Node.js im Backend, React im Frontend, Datenspeicherung erstmal ganz pragmatisch in JSON, weil ich noch keine persistente Ablage brauchte. Nicht hübsch, nicht final – aber das erste echte Erfolgserlebnis.

3) Wenn’s ernst wird: API-Keys und der Umgang mit echten Daten

Nachdem das Dashboard stand und die ersten grünen Anzeigen liefen, kam natürlich die Frage: „Okay, was mache ich jetzt damit?“ Der nächste Schritt war der Zugriff auf echte Systeme – bei mir GitLab und Uptime Kuma – also brauchte ich API-Keys.

Und da wird es für jemanden wie mich, der kein erfahrener Entwickler ist, plötzlich spannend: Zugriffe und Berechtigungen sind kein Nebenthema. Klar, als Geschäftsführer habe ich relativ umfassende Accounts, aber ich bin nicht geübt darin, sensible Daten über APIs oder Datenbanken zu handhaben. Genau hier hilft Austausch mit erfahrenen Entwickler:innen enorm – damit man nicht aus Versehen zu großzügige Zugänge vergibt oder etwas baut, das man später bereut.

Mein persönlicher Guardrail: nur lesende Schnittstellen. Ich habe Cursor ausdrücklich immer wieder gesagt, er solle keine schreibenden Endpunkte generieren. Noch besser: API-Keys, die serverseitig nur Lesezugriff haben. So kann ich gar nicht erst versehentlich Live-Daten verändern.

4) Deployment: Wenn’s ans Team geht – und die KI spooky wird

Lokal lief die App, und ja, ich war stolz wie Bolle. Aber klar: Nur auf meinem Rechner bringt das niemandem etwas. Also musste das Ding „ins Teamzimmer“, sprich: auf einen Server.

Hier hat KI dann wirklich daneben gelegen. Ich habe versucht, das Projekt mit Cursor direkt auf einen unserer proServer zu bringen. Was dann passierte, war, freundlich gesagt, spooky: Cursor bediente sich ziemlich ungefragt meiner SSH-Keys, las in der Server-Doku nach und schien sogar zu erkennen, welcher Pro-Server sudo hat und welcher User nur normaler Anwender ist – und hat dann mit den „richtigen“ Usern angefangen, auf dem Server rumzuschrauben. Zum Glück war das ein leerer Server, den ich nur für diesen Zweck genommen habe.

Das Ergebnis? Irgendwie war die App da, irgendwie lief auch etwas – aber im Browser kam nichts Gescheites an. Richtig stabil wurde es nicht.

Am Ende bin ich zu unseren DevOps-Kollegen gegangen. Die haben das sauber hinter einen Reverse Proxy gestellt, auf Sicherheit geachtet und generell mal geschaut, was die App eigentlich treibtFazit: Produktiv-Deployment nur mit Cursor war ein Schuss in den Ofen – das mache ich so nicht wieder. Gerade beim Ausrollen gilt: Sicherheit > Geschwindigkeit.

Genau an der Stelle wurde uns klar: Wenn Menschen, die nicht täglich entwickeln, mit solchen Tools arbeiten, brauchen wir klare, management-kompatible Leitplanken zusätzlich zu den bestehenden Engineering-Standards. Also haben mein Geschäftsführungskollege – der wirklich ein sehr guter Entwickler ist – und ich uns hingesetzt und intensiv ausdiskutiertwas muss sein, was kann sein, wie gehen wir damit um. Das ist dann Stoff für einen separaten Blogpost.

Wenn du herausfinden möchtest, wie du in deinem Unternehmen Räume für solche Experimente schaffst – mit klaren Services im Hintergrund und sicheren Leitplanken – dann sprich uns gerne an.

Und wenn du Lust hast, dich direkt mit mir über Cursor, AI-Coding und den praktischen Nutzen für Projektmanager:innen auszutauschen, melde dich ebenfalls gern – ich teile meine Erfahrungen und freue mich auf den Austausch.

Firmenkontakt und Herausgeber der Meldung:

punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de

Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Für die oben stehenden Pressemitteilungen, das angezeigte Event bzw. das Stellenangebot sowie für das angezeigte Bild- und Tonmaterial ist allein der jeweils angegebene Herausgeber verantwortlich. Dieser ist in der Regel auch Urheber der Pressetexte sowie der angehängten Bild-, Ton- und Informationsmaterialien. Die Nutzung von hier veröffentlichten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber.