Moving away from blogspot.com

We updated our site oregami.org to a new technical base, and didn't forget our blog in the process. It is now fed elsewhere, not via Google (blogspot.com) any more.

Thus, this is the last post at this space, further blog posts are to be found only at oregami.org.

GameDB News Roundup 01/2017

Let's take another look at some developments within the video game database landscape.

(The content in this update is a bit outdated, as this will be the last GameDB News Roundup for the time being, because I want to concentrate more on subject matter work to finally bring Oregami online, and couldn't beat myself to publishing this earlier. If you want to continue writing these contents, please get in touch at our forums.)

IGDB.com released version 2 of their API this summer. And while I cannot tell the differences to version 1, version 2 is claimed to be faster, more stable and ready for heavy-weight usage. The interesting thing here is the pricing, which reveals that free use of the API is limited to 7,000 requests per day, which is rather not much. Also, IGDB's advanced search feature has been rewritten, and is now an even more powerful tool that is among the leaders of the pack. A feature that usually perfectly showcases the weaknesses embedded into the current models of genre definition, is an automated similar games search. The IGDB developers introduced this nonetheless, but also added the possibility for the users to add their own recommendations. Take a look at the recommendations page for the 1990's game Apprentice for an example.

Thoughts about internationalization (i18n)

It comes to no surprise for Oregami to face internationalization (i18n) issues sooner or later, since we are a project that wants to become the authoritative and free data pool for the global video gaming community. While English is a good choice for the first language of the project, and German as our native language a good choice for the second, a complete documentation of video games requires spreading the work and expertise to more languages.

Domain Driven Design, CQRS, Event Sourcing, Hexagonal Architecture & more

The road to the right software architecture can be very long. Especially when you're not a professional software architect who helps his customers with developing complex applications day by day.

What will be the Oregami way to the right software architecture? If you've been monitoring our project from the beginning, you know that we threw over the chosen technologies one ore two times already. In the beginning I only had the classical multi-tier architecture in mind and mainly thought about which Java framework to use for persisting our game objects and which database software to use for that. Until today my mind changed in many ways.

One step back - two steps forward?

If you are watching the Oregami project you may have noticed that it got rather silent during the last months. What could be the reasoning for that? Real life!  But exactly due to RL we create everything in the open: data model, ideas, source code. Nothing gets lost, everybody can jump on the Oregami bandwagon at any time to support the first real open game database!

The cause for this blog post is my attention towards the project Spring Boot. Spring Boot was designed "to simplify the bootstrapping and development of a new Spring application. The framework takes an opinionated approach to configuration, freeing developers from the need to define boilerplate configuration" (source). When I switched to Dropwizard with the Oregami server application two years ago, there was no other Java framework with these capabilities: making web development easier with an embedded server. It was exactly what I was looking for, no more "deploying" or "publishing" fat server applications.

In the mean time Spring Boot entered the stage. In April 2014 version 1.0 was released, today the latest release is version 1.3. What if I would try to move the current development state of the Oregami web application to Spring Boot? Before I answer that let me first give you an overview of what we have running so far:

• REST-Application with domain objects like "Game", "PublicationFranchise", "GamingEnvironment" and more
• HTTP-Calls for GET (read), POST (create) and PUT (update) of  these objects
• creation and editing of domain objects in the web browser
  
• Cross-Origin Resource Sharing
• "Session-per-HTTP-request": one database transaction per HTTP-Request
  
• HSQLDB for development, MySQL for the deployed application
• JPA entities with UUIDs as Primary Key
  
• Liquibase for easy database schema updates
• Auditing of saved objects with Hibernate Envers
• integration tests with rest-assured

Of course all these things would have to be implemented in the refactoring with Spring Boot.

But there is another important question: will we stay with the current architecture which is a REST-Server + a JavaScript Single Page Application?

During the last years there's been a war of architectures going on in my mind: a REST-API is a must, so we developed the Oregami game database as a pure REST application with a web client as JavaScript single page application. That's kind of elegant and makes fun during development. But is it the best choice? I am not the only one who thinks about this:

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

A few months ago I bought the book "Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement (2nd Edition)" by Aaron Gustafson. The idea of making a website available with basic web technologies at first, enhancing it afterwards step by step and therefore making sure that the website is usable with every web software on the planet, becomes more and more attractive to me. With this in mind I started to refactor my (other) website Kultpower.de. In addition to "Progressive Enhancement" I made use of  a technique called "Mobile First": concentrate on devices with small screen (smartphones) primarily and then, using the same code base, enhance for bigger screens. The result so far can be seen at Kultpower.org, and I must say that I am really satisfied with it! (don't forget to try it on your smartphone)

The concept of the so-called "Roca-Style" (Resource Oriented Client Architecture) describes a collection of simple recommendations for decent Web application frontends. I will use these recommendations for a complete refactoring of the Oregami application. I will be able to reuse much of the source code (e.g. for Games, Publications etc.) and make use of the knowledge I gathered with Kultpower.org. Our current JavaScript-Client will be replaced with server side rendered HTML pages created by the template engine Thymeleaf.

So you may have already guessed it: Stay tuned! 

GameDB News Roundup 01/2016

In 2016, we want to continue our little series of blog entries about new developments within the video game database landscape.

The biggest news this cycle, again, came from the team of the IGDB.The core team of the site obviously found investors to believe in their success, and thus the developers are now working full time on the code. You can check out their headquarters and core people in their first episode of "Insight" videos. Also, in a turn of events unseen before, the lead developer of IGDB shared the technical base of the site in a 46 minute video.

GameDB News Roundup 02/2015

Let's take another look at new developments within the video game database landscape.

The biggest news this cycle made IGDB, who launched the first version of their API. An API offers standardized access for fetching all kinds of data from a database, so they can be used elsewhere, and is therefore an important thing to have. This first IGDB API offers access to game data, companies, people, franchises, and platforms, which seems quite comprehensive so far. There's also the possibility for game shops to integrate their game products to the price comparison feature of IGDB.