Abschied von blogspot.com

Wir haben unsere Seite oregami.org technisch auf eine neue Basis gestellt und dabei auch das Blog nicht vergessen, das nun nicht mehr über Google (blogspot.com) gefüttert wird.

Dies ist also der letzte Blogpost hier, die weiteren findet Ihr nur noch direkt auf oregami.org.

Spieledatenbanken-News 01/2017

Werfen wir einen weiteren Blick auf neue Entwicklungen in der Welt der Videospiel-Datenbanken.

(Die Neuigkeiten in dieser Ausgabe sind etwas veraltet, da das hier die vorerst letzten Spieledatenbank-News sind, und ich mich nicht eher dazu bringen konnte, sie zu veröffentlichen. Die letzten News deshalb, weil ich mich in Zukunft mehr auf Facharbeit in Richtung unseres Ziels, Oregami endlich online zu bringen, konzentrieren möchte.)

IGDB.com hat mittlerweile die Version 2 ihres APIs veröffentlicht. Ich kann zwar die Unterschiede zur ersten Version nicht konkret benennen, aber die Version 2 soll schneller, stabiler und fertig für große Benutzerzahlen sein. Der interessanteste Aspekt hier ist zweifelsohne die Bepreisung, die die freie Benutzung des APIs auf 7.000 Anfragen pro Tag begrenzt, was nicht sehr viel ist. Außerdem wurde die erweiterte Suchfunktion der IGDB neu geschrieben und gehört nun mit Sicherheit zu den besten da draußen. Eine weitere Funktion, die normalerweise sehr schön die Schwächen der derzeitigen Genre-Definitionen aufzeigt, ist die automatische Anzeige von ähnlichen Spielen. Die IGDB-Entwickler haben trotzdem so etwas programmiert, dabei aber auch die Möglichkeit für die Benutzer vorgesehen, eigene Empfehlungen einzubauen. Beispielhaft sei hier die Empfehlungsseite für das 1990er Spiel Apprentice verlinkt.

Gedanken zur Internationalisierung (i18n)

Oregami möchte irgendwann mal der umfassende und freie Datenpool der weltweiten Videospielgemeinschaft werden. Da überrascht es wenig, dass wir uns früher oder später mit Problemen der Internationalisierung (engl. Abkürzung: i18n) beschäftigen müssen. Englisch mag eine sehr gute Wahl für die Hauptsprache eines internationalen Projekts sein, Deutsch als unsere Muttersprache eine sehr gute Wahl für die zweite, die komplette Dokumentation der weltweiten Videospiel-Historie erfordert jedoch Arbeit und Expertise in weiteren Sprachen.

Domain Driven Design, CQRS, Event Sourcing, Hexagonale Architektur & mehr

Der Weg zur richtigen Software-Architektur kann manchmal lang sein. Oder sogar sehr lang. Insbesondere, wenn man nicht gerade hauptberuflich Software-Architekt ist und dabei quasi jeden Tag bei seinen Kunden die Entwicklung komplexer Software betreibt.

Wie kann Oregami nun den Weg zu einer guten Software-Architektur finden? Wer unser Projekt von Beginn an beobachtet hat, der weiß, dass wir schon mehrmals die bis dato ausgewählte Technik "über den Haufen geworfen" haben. Anfangs hatte ich eine klassische Schichtenarchitektur im Sinn und machte mir hauptsächlich Gedanken darüber, mit welchem Java-Framework wir unsere fachlichen Objekte speichern könnten und welche Datenbank-Software wir einsetzen würden. Bis zum heutigen Tag hat sich in meinem Kopf allerdings viel getan.

Spieledatenbanken-News 01/2016

Auch im Jahr 2016 wollen wir unsere kleine Serie von Blogeinträgen über neue Entwicklungen im Markt für Videospieldatenbanken fortsetzen.

Die Top-Neuigkeiten kamen dieses Mal wieder von der IGDB. Das Kernteam hinter dem Projekt hat nämlich offensichtlich Investoren gefunden, die an den zukünftigen Erfolg der Seite glauben, und kann deshalb nun Vollzeit daran arbeiten. Außerdem wurden eine Reihe von "Insight"-Videos veröffentlicht, in deren erster Episode man sich zum Beispiel IGDBs Hauptquartier und das Kernteam anschauen kann. Außerdem hat der leitende Entwickler des Projekts ein 46-minütiges Video veröffentlicht, in dem er, ein Novum in der Geschichte der Spieledatenbanken, detailliert auf die technischen Hintergründe der IGDB eingeht.

Ein Schritt zurück - zwei Schritte nach vorne?

Wer das Projekt Oregami beobachtet, der wird bemerkt haben, dass es seit ein paar Monaten etwas ruhiger geworden ist in der Oregami-Welt. Der Grund dafür? Das restliche Leben!  Aber genau dafür entwickeln wir ja Alles offen: Datenmodell, Ideensammlung, Programmcode. Nichts geht verloren, jedermann kann jederzeit mit aufspringen auf den Zug der ersten komplett offenen Spieledatenbank!

Der Anlass für diesen Blogbeitrag ist meine schon länger vorhandene Aufmerksamkeit gegenüber dem Projekt Spring Boot. Spring Boot unterstützt die Entwicklung eigenständig lauffähiger Spring-Anwendungen per Konvention vor Konfiguration, die ohne XML-Konfiguration auskommen und alle nötigen Klassenbibliotheken mitbringen. Als ich vor ca. zwei Jahren die Oregami-Entwicklung (der REST-Server-Anwendung) auf Dropwizard umstellte, stand Dropwizard mit seinen Fähigkeiten noch ziemlich alleine da. Ein Java-Framework, dass seinen Server "eingebettet" mitbringt und so die Entwicklung von Webanwendungen erheblich vereinfacht: genau das suchte ich. Nie wieder einen sperrigen Application Server "deployen" oder "publishen".

Mittlerweile ist Spring Boot auf der Spielfläche erschienen. Im April 2014 erschien V 1.0, heute ist Version 1.3 die aktuellste Fassung. Was wäre nun, wenn ich versuchen würde, den bisherigen Stand neu mit Spring Boot zu realisieren? Dazu möchte ich aber erstmal aufführen, was wir bislang alles "lauffähig" haben:

• REST-Anwendung mit Fachobjekten wie "Game", "PublicationFranchise", "GamingEnvironment" und mehr
• HTTP-Anfragen für GET (Lesen), POST (Anlegen) und PUT (Ändern) von Fachobjekten
• Anlegen und Editieren von Fachobjekten über den Browser
• Authentifizierung mit JSON Web Tokens
• "Session-per-HTTP-request": eine Datenbank-Transaktion pro HTTP-Request
• HSQLDB für die Entwicklung, MySQL für den "deployten" Stand
• JPA entities mit UUIDs als Primary Key
  
• Liquibase für einfache Datenbank-Schema-Updates
• Versionierung von Fachobjekten mit Hibernate Envers
• Integrationstests mit rest-assured

Diese Dinge müssten natürlich so oder in ähnlicher Form auch in einer Neu-Implementierung mit Spring Boot vorhanden sein.

Aber es stellt sich außerdem noch die Frage: Bleiben wir bei der bisher gewählten Anwendungsarchitektur REST-Server + JavaScript Single Page Application?

In meinem Kopf spielt sich seit einigen Jahren ein Kampf der Architekturen ab. Eine REST-Schnittstelle nach außen ist für mich ein Muss, also entwickelten wir bisher die Oregami-Spieledatenbank als REST-Anwendung mit einem Web-Client in Form einer "Single Page Application". Das ist in gewisser Weise elegant und macht bei der Entwicklung Spaß. Aber ist es wirklich die beste Lösung? Das fragen sich auch Andere:

• Are Single Page Apps bad?
• Reimagining Single-Page Applications With Progressive Enhancement
• Why I hate your Single Page App

Vor einigen Monaten habe ich mir das Buch "Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement (2nd Edition)" von Aaron Gustafson zugelegt. Die Idee, eine Webseite im ersten Schritt mit Standard-Technologien nutzbar zu machen, sie danach schrittweise zu verbessern und dadurch dafür zu sorgen, dass die Webseite mit jeglicher Web-Software auf jeden Fall benutzbar ist, gefällt mir immer besser. Mit diesen Gedanken im Hinterkopf habe ich vor einigen Monaten damit begonnen, meine (andere) Webseite Kultpower.de komplett neu zu entwickeln. Neben dem "Progressive Enhancement" verfolgte ich auch gleich den Ansatz "Mobile First": Die Webseite wird erstmal für kleine Bildschirme (z.B. Smartphones) entwickelt, anschließend werden - in der gleichen Code-Basis - Verbesserungen für größere Bildschirme eingebaut. Das bisherige Ergebnis ist zu finden unter www.Kultpower.org (unbedingt auch mal mit dem Smartphone ausprobieren), ich bin damit sehr zufrieden!

Unter dem Synonym "Roca-Style" (Resource Oriented Client Architecture) wird eine Sammlung von Empfehlungen beschrieben, die man bei der Entwicklung von Webseiten berücksichtigen kann. Nach diesen Empfehlungen möchte ich den bisherigen Stand der Oregami-Spieledatenbank neu entwickeln. Ich werde viel Programmcode (das Fachliche bezüglich Games, Publications usw.) wiederverwenden können und meine Erfahrungen aus dem Kultpower.org-Projekt einfließen lassen. Unser bisheriger JavaScript-Client wird dann abgelöst werden durch serverseitiges Rendern der Seiten mit der Template-Engine Thymeleaf.

Es gilt also wie immer bei Oregami: stay tuned! 

Spieledatenbanken-News 02/2015

Wir wollen einen erneuten Blick auf aktuelle Entwicklungen innerhalb der Datenbanklandschaft für Videospiele werfen.

Die wichtigsten Neuigkeiten in dieser Ausgabe kommen von der IGDB, die die erste Version Ihres API's veröffentlicht hat. Ein sogenanntes API ermöglicht den standardisierten Zugriff auf eine Datenbank von außerhalb, um alle möglichen Daten aus ihr auszulesen, und ist deshalb eine wichtige Funktion für die allgemeine Nutzbarkeit der Daten. Die erste Version des IGDB-API's erlaubt den Zugriff auf Spieledaten, Firmen, Personen, Franchises und Plattformen, und ist damit bereits ziemlich umfangreich geraten. Weiterhin gibt es die Möglichkeit für Spieleshops, ihre Angebote in die Preisvergleichsfunktionalität der IGDB zu integrieren.

Sprung ins Plattform-Chaos

 

Einleitung

Ein Geheimnis ist es sicher nicht, dass jedes Computerspiel irgendwelche Computer-Hardware (HW) braucht, um gespielt werden zu können. Die meisten Spiele benötigen darüber hinaus auch noch eine gewisse Basis-Software (SW) wie ein Betriebssystem (BS), dass auf dieser HW oder ihrem Medium vorinstalliert ist. Und dennoch besteht das traditionelle Plattform-Modell nahezu aller Videospiel-Webseiten da draußen aus einem wilden Mix von HW und SW. Man kann Konsolen wie die PlayStation direkt neben BSen wie Linux oder Windows finden, Seite an Seite mit "plattformunabhängiger" SW wie einem Browser oder gar Arcade-Boards, alle zusammengeführt zu einer einzigen Ebene von Plattformdaten. Diese Zusammenkunft der verschiedenen technischen Ansätze an einer Stelle bringt eine Reihe von Problemen mit sich, wenn es an die Dokumentation von Spieleveröffentlichungen geht.

Spieledatenbanken-News 01/2015

Dieser Blogbeitrag ist der erste in einer neuen Serie von News-Einträgen, die kurz und knackig die aktuellen Entwicklungen in der Datenbanklandschaft für Videospiele zusammenfassen sollen. Wir beobachten einige Projekte da draußen, und da erscheint es nur logisch, die ganzen Neuigkeiten an einer Stelle zu sammeln.

In den letzten Monaten haben gleich drei Datenbanken neue Meilensteine bei den "Spieleeinträgen" vermeldet: MobyGames hat 50.000 "unique games" erreicht, das taufrische Projekt IGDB vermeldete 10.000 Spiele in seiner Datenbank und die italienische Seite UVL feierte sogar 100.000 Spieleinträge mit einer kurzen Notiz. Aber bedeutet das jetzt, dass MobyGames fünfmal so erfolgreich ist wie die IGDB, und dass die UVL dafür doppelt so gut ist wie MobyGames? Natürlich nicht.

Software bei Oregami

Wir beim Oregami-Projekt setzen eine Menge Software-Produkte ein - klassische Open-Source-Tools genauso wie kommerzielle, die für Open-Source-Projekte wie uns kostenlos verfügbar sind. Dieser Blogbeitrag zeigt euch, was wir einsetzen!

Software für die Entwicklung

 

IntelliJ IDEA

Du programmierst mit Java? Dann kennst du natürlich die Eclipse IDE, die unter einer freien Lizenz verfügbar ist. Ich nutze Eclipse nun schon seit mehreren Jahren und habe mich ganz gut daran gewöhnt.

Aber irgendwie stieß ich auf IntelliJ IDEA von der Firma Jetbrains, was dort als "Die intelligenteste Java IDE" bezeichnet wird, und bin dabei hängen geblieben. Diese Entwicklungsumgebung ist zunächst nicht wirklich kostenlos erhältlich, es gibt zwar eine kostenlose "Community Edition", aber sehr viele nützliche Features sind nur in der "Ultimate Edition" verfügbar. Wer jedoch wie wir ein Open-Source-Projekt betreibt, der bekommt die Ultimate Edition kostenlos! IntelliJ IDEA gibt es für Mac, Linux und Windows.

Open Source REST Server-Anwendung (Dropwizard - Google Guice - JPA Hibernate)

Vor ziemlich genau einem Jahr habe ich mich dazu entschieden, das Java-Webframework Dropwizard für unsere Server-Anwendung einzusetzen. Seitdem habe ich viel gelesen, viel gelernt und auch Einiges in unserer Server-Anwendung implementiert. Nun stand eine Umstellung auf die neueste Dropwizard-Version an. Diese Gelegenheit habe ich dafür genutzt, Alles nochmal "von vorne" zu entwickeln, um meine Erkenntnisse über die Anwendung zu festigen. Ich möchte die komplette Implementierung dauerhaft überblicken, verstehen und gescheit dokumentieren. Das wird anderen dabei helfen, in die Entwicklung mit einzusteigen und den Code langfristig wartbar zu halten.

Um die ganzen technischen Features der Server-Anwendung für die Allgemeinheit zur Verfügung zu stellen, habe ich eine neue Anwendung erstellt, die alleinstehend und außerhalb des Oregami-Kontextes lauffähig und sinnvoll ist und eine klassische "ToDo-Applikation" darstellt. Ihr wisst schon: eine Liste von Dingen (Name, Beschreibung, Status, ...), die man noch erledigen muss.

Die Anwendung enthält momentan die folgenden technischen Features:

• REST-Anwendung basierend auf Dropwizard Version 0.7.0
• Dependency Injection mit Google Guice
• Hibernate / JPA 2.1 als Persistenz-Framework
• HSQLDB als (In-Memory-)Datenbank
• "Transaction-per-HTTP-request" mit Guice PersistentFilter
• Unterstützung für cross-origin resource sharing
• JPA Entitäten mit UUIDs als Identifikator
• Ein Muster für den Zugriff und die Manipulation von Entitäten über REST Aufrufe
  (Ressource => Service => DataAccessObject)
• Ein Muster für Service-Aufruf-Ergebnisse, welche Fehlermeldungen enthalten können, inkl. der Information, bei welchem Feld der Anwendung der Fehler aufgetreten ist. Auf diese Weise kann später in der Weboberfläche die Fehlermeldung an der richtigen Stelle eingeblendet werden.
• Durchgehende JUnit-Tests zur Absicherung der korrekten Funktionalität

In möglichst naher Zukunft sollen die folgende Dinge noch hinzugefügt werden:

• Authentifizierung
• Hypermedia mit HATEOAS
• komplexere Entitäten (1-zu-n-Beziehungen)

Der Sourcecode steht bei Github unter dem Namen dropwizard-guice-jpa-seed für jedermann zur Verfügung.

Disclaimer: Es kann natürlich sein, dass ihr Dinge findet, die man besser machen kann. In diesem Fall helft gerne mit, die Anwendung zu verbessern! Geht bei Github über die üblichen Pull-Requests. Das gilt natürlich auch für neue, noch fehlende Features!

Hinweise für Enwtickler

Die Anwendung kann gestartet werden über die Klasse "ToDoApplication" mit den Parametern "server todo.yml".

Auflisten der aktuell gespeicherten Tasks über:
GET => http://localhost:8080/task

Hinzufügen eines neuen Tasks über:
POST => http://localhost:8080/task
Header:
Content-Type:application/json
JSON-Body z.B. :
{"name" : "task 1", "description" : "This is a description"}

Modifizieren eines Tasks über:
PUT => http://localhost:8080/task/[id]
Header:
Content-Type:application/json
Accept:application/json
JSON-Body z.B.:
{
    "id": "402880944687600101468760d9ea0000",
    "version": "0",
    "name": "task 1 with new name",
    "description": "This is an updated description",
    "finished": "false"
}

Ich empfehle die Chrome-Erweiterung Postman, um solche HTTP-Aufrufe durchzuführen!

Nomen est omen: Spielenamen sind viel mehr als Schall und Rauch

Einer der regelmäßig wiederkehrenden Kritikpunkte an MobyGames - und das erstaunlicherweise  trotz all der anderen ernsthaften Schwächen des dortigen Datenmodells - ist die Bezeichnung der Spieleinträge. MobyGames ist und war natürlich auch immer schon ein US-Projekt, weswegen jedes Spiel nur mit dem Titel seiner US-Veröffentlichung als "Haupttitel" in die Datenbank aufgenommen wird. Falls es keine US-Veröffentlichung des Spieles gab, wird der Titel eines Releases in einem anderen englischsprachigen Land herangezogen. Sollte es auch eine solche Veröffentlichung nicht gegeben haben, wird schlussendlich der Originaltitel benutzt, wobei dann dessen Herkunft nicht mehr von Belang ist. Ist ein Haupttitel für das Spiel gefunden, wird jeder andere Name nur als "alternativ" in die Datenbank aufgenommen.

Es gibt ein großes Problem mit diesem Ansatz: Es könnte nämlich durchaus sein, dass der Rest der Welt sich ganz und gar nicht für den US-Veröffentlichungstitel eines Spieles interessiert. Man stelle sich beispielsweise einen japanischen MobyGames-Besucher vor, der irritiert feststellen muss, dass der vierte Teil der Final-Fantasy-Reihe dort als "Final Fantasy II" geführt wird, weil er schlicht das zweite FF-Spiel war, das in den USA veröffentlicht wurde. Bei näherem Nachdenken muss es doch einen besseren Weg der Spielbezeichnung geben, weshalb ich im folgenden Beitrag untersuchen möchte, wie andere Videospieldatenbanken dieses Problem angehen, um dann die geplante Oregami-Lösung vorzustellen. Zu Referenzzwecken werde ich immer Final Fantasy IV als Beispiel verlinken.

Englisch ist jetzt Standard

Es war schon traurig, den kürzlichen Exodus der MobyGames-Community mitansehen zu müssen, aber er hat auch viele enttäuschte Videospiel-Liebhaber auf der Suche nach einer neuen Heimat in das Oregami-Forum gespült. Wir haben nach bestem Wissen und Gewissen versucht, alle Fragen zu beantworten und alle Bedenken zu zerstreuen, die von diesen Leuten an uns herangetragen wurden. Dabei haben wir auch bemerkt, dass die Zeit für die weitere Internationalisierung von Oregami reif ist.

Vereinsgründung in Sicht

Man mag es kaum glauben, aber die ersten konkreten Überlegungen zu unserer Vereinsgründung haben wir bereits im Januar 2012 begonnen, also vor fast 20 Monaten. Und gegründet ist unser Verein immer noch nicht! Was also haben wir getrieben all diese Zeit? Und warum wollen wir eigentlich einen Verein? Ein kleiner Rückblick soll darüber Auskunft geben, außerdem wollen wir einen Ausblick auf die Zukunft wagen.

MobyGames hat sie, TheLegacy hat sie, thematisch andere Seiten haben sie auch - stets die gleichen Probleme. Aufgrund dieser Erfahrungen mit anderen Datenbankprojekten hatten wir uns relativ früh auf ein zentrales Grundprinzip für das Oregami-Projekt festgelegt: die größtmögliche Unabhängigkeit von einzelnen Personen. Dieses Prinzip sollte unbedingt auch auf die Gestaltung der rechtlichen Grundlagen angewendet werden. Die bisher üblichen rechtlichen Erscheinungsformen von Spieledatenbanken (privat, halbkommerziell, kommerziell) hatten in unseren Augen einen entscheidenden Nachteil: alle diese Projekte wurden rein rechtlich von einer Person oder Firma, höchstens von zweien betrieben, was große Fragezeichen hinter der Zukunftssicherheit der Daten zurückließ. Was würde passieren, wenn diese eine Person das Interesse verlor, wenn diese eine Firma verkauft würde oder insolvent wäre? Was geschähe dann mit diesen Projekten?

Retrobörse in Oberhausen am 11. Mai 2013

Die nächste Retrobörse in NRW steht kurz bevor: am kommenden Samstag, den 11. Mai, findet sie im Zentrum Altenverg in Oberhausen statt.

Ich werde an meinem Verkaufsstand wieder alte Zeitschriften der 80er und 90er Jahre zum Verkauf anbieten: Power Play, Video Games, ASM, PC Joker, Maniac und mehr. Das gewohnt kultige Programm also.

Natürlich stehe ich wieder für nette Gespräche aller Art zur Verfügung - her mit euren Fragen und Ideen zu Oregami oder Kultpower.de !

Oregami im Podcast der "Drei Vogonen"

Einer der bekanntesten Tech-Nerd-Podcasts ist der von den Drei Vogonen.

Vor einigen Monaten bekam ich eine Anfrage, ob ich als Gast in deren Podcast auftreten wolle. Nun, was sollte ich sagen, JA !

Jetzt ist die neue Podcast-Folge online!

In bester Tradition der Drei Vogonen dauert der Podcast knapp 6 (!) Stunden. Im Abschnitt "Deep Thought" (ab 1 Stunde 29) komme ich dann zur Sprache, und zwar für knapp eine Stunde. Themen: Inhalt und Historie von Kultpower.de, aber auch Ziele unseres Projektes Oregami.org, der (hoffentlich bald gemeinnützigen) Online-Spiele-Datenbank. Die Jungs haben echt mal intelligente Fragen gestellt. Ich hoffe meine Antworten machen einen ähnlichen Eindruck :-)

Reinhören! Und dann am besten mithelfen bei Oregami oder Kultpower. Oder bei beidem :-)

Die verflixte X-Wing-Serie oder Wieso eigentlich Datenmodellierung?

Intro

Oregami soll eine Mitmach-Datenbank für Computer- und Videospiele werden, fachlich ähnlich komplex wie die Internet Movie Database für Film und Fernsehen. Wenn wir also über Oregami sprechen, dann ist schnell von unserem Datenmodell - oder fachlichen Modell - die Rede, und dass dieses ominöse Modell besser sein soll als bei anderen, bereits existierenden Spieledatenbanken. Aber wieso eigentlich? Was ist eigentlich ein Datenmodell und warum ist eigentlich das, was MobyGames und TheLegacy anbieten, nicht ausreichend für uns?

Nun bringt unser aller liebstes Spielzeug einen ganzen Berg an Daten mit: Computer- und Videospiele haben einen Namen, gehören einem Genre an, werden auf verschiedenen Systemen in verschiedenen Versionen zu verschiedenen Zeitpunkten veröffentlicht, das auch noch in verschiedenen Ländern, und so weiter und so fort. All diese Daten sollen in unsere Datenbank eingegeben werden können, aber das alleine reicht natürlich noch nicht aus. Schaut sich der Benutzer ein Spiel an, so möchte er zum Beispiel wissen, auf welchen Systemen dieses Spiel erschienen ist und wann. Schaut er sich eine Spielesammlung an, so sollte erscheinen, welche Spiele sie enthält, und diese Spiele sollten mit einem weiteren Klick für mehr Informationen erreichbar sein. Oder welche Spiele eines bestimmten Genres sind in einem bestimmten Jahr auf einem bestimmten System erschienen?

Retrobörse in Bochum am 10. November 2012

Am 10. November 2012 ist es wieder so weit: In Bochum findet die traditionelle Retrobörse statt! Es handelt sich - wie der Name es schon vermuten lässt - dabei um eine Art Riesenflohmarkt mit Retro-Sachen: Computer, Konsolen, Spiele, Fan-Artikel und Vieles mehr.

Ein einziger Verkaufsstand wird mal wieder auschließlich alte Spiele-Zeitschriften anbieten - und das ist meiner. Wie gewohnt werdet ihr an meinem Tisch aus hunderten alter Magazine (Powerplay, ASM, Video Games, Maniac, PcXtreme, 64er und mehr) die besten und/oder euch noch fehlenden Exemplare rauspicken können.

Natürlich - deswegen schreibe ich überhaupt hier - kann man mich auch zu unserer Online-Spiele-Datenbank Oregami befragen: Was haltet ihr von unserem Projekt? Welche Ideen oder Wünsche habt ihr? Wie könntet ihr mithelfen, die beste Online-Datenbank "ever" zu erschaffen?
Lobeshymnen oder andere Dinge zu meiner "anderen" Webseite Kultpower.de sind natürlich auch zugelassen :-)

Also: auf nach Bochum und rein in die Retro-Welt!

Besuch bei den Spieleveteranen

Vor einigen Tagen durfte ich in der neuesten Ausgabe des Spieleveteranen-Podcasts mitmachen und mich mit den "alten Hasen" des Spiele-Journalismus unterhalten: Heinrich Lenhardt, Anatol Locker, Winnie Forster und Jörg Langer sind bestimmt vielen von euch noch ein Begriff. In den letzten Jahren hatte ich des öfteren Kontakt mit ihnen durch meine Webseite Kultpower.de: wirklich nette Jungs, deren Erfahrung und Kompetenzen in der Games-Branche einen einfach jedesmal wieder umhauen.

Nun konnte ich ihnen und allen Zuhörern Einiges über unser Projekt OREGAMI erzählen.

Die Kurzfassung:

• wir wollen eine neue, offene und umfassende Online-Datenbank für Alles aus der Welt der Computer- und Videospiele erschaffen
• wir möchten einen gemeinnützigen Verein gründen, der das Projekt organisatorisch und finanziell anführ. Alle Details zur Vereinsgründung findet ihr hier.
• wir suchen aktiv weitere Mitstreiter, um unseren selbst entworfenen Zeitplan einhalten zu können
• zu sofort werden gesucht: Java-Programmierer. Mehr Infos für Entwickler gibt's hier.
• zu möglichst bald werden gesucht: Rechts-Experten, z.B. für Lizenzfragen bezüglich der Datenbank-Inhalte, Screenshots etc. Die aktuelle Diskussion zu diesem Thema findet ihr hier im Forum.
• zu demnächst: Designer für eine toll aussehende Webseite. Interessenten können sich natürlich auch gerne jetzt schon melden :-)

Also, hört euch den Podcast an, schaut euch unser Forum an, registriert euch, macht mit! Nur mit euch zusammen können wir so ein großes Projekt bewältigen.

Flotter Dreier mit Jenkins, Git und Tomcat

Das Ziel war klar: Unser Java-Programmcode soll von unserem Jenkins-Build-Server regelmäßig kompiliert und dann auf unseren Tomcat-Server deployt werden. So weit, so gut. Doch dafür mussten einige Hindernisse überwunden werden.

In Bezug auf Versionierungs-Systeme hatte ich in meiner Programmierer-Vergangenheit bislang hauptsächlich Kontakt mit CVS und Subversion. Beide sind heute nicht mehr zeitgemäß, also wird unser Programmcode mit Git verwaltet. Als Hoster habe ich Github ausgewählt, so viele bekannte Projekte können da nicht falsch liegen.

Zudem bin ich es beruflich mittlerweile gewohnt, dass der Programmcode mindestens einmal am Tag "gebaut" wird, der Griff zum Jenkins-Buildserver lag da sehr nah. Und der Tomcat-Server für unsere Java-Webanwendung sollte da leicht angebunden werden können - dachte ich zumindest.