Developer's diary

[hydr0x]

Hi hydr0x, great you are still around!

Are you storing the tokens on the server or are they created and compared on-the-fly on the server each time a request with a token comes in?

Of course the token ist not stored on the server. That's exactly what you don't want when you create a RESTful application: state on the server. Just as you said.

Check out my wiki page about our REST authentication mechanism for some details.

Great Somehow missed the diagram on the Wiki before

[gene]

I continued the work an server side authentication.
For this, I developed some integration tests which check if everything works fine. These tests use rest-assured from google, which is a great library to programatically request URLs from the server application, GET or POST, with or without HEADER. So these tests check if authentication is working, and all this without a browser. Great!

[gene]

I restarted with the work on the oregami client application.
While the running app looks exactly like before, the underlying build system has been renewed: I switched from Grunt to Gulp, which is more stable and better maintainable. The build works much better than before.
During this refactoring I also changed the logical file structure: Before I had all JavaScript controllers in one directory, all services in one directory. Now I have a directory for every "feature":

Much better!

Now I can continue to integrate more features like (the client part of) authentication.

[hydr0x]

That's an unusual structure. The one you had before (putting models/view/controllers etc together into folders) is the one you always see in projects. Does the routing engine handle this structure easily?

Can I suggest to somehow distinguish between resources and everything else? What I mean is, I would have expected each folder in such a structure basically matching one resource URI. E.g. folder games matches oregami.org/database/game/ and persons matches oregami.org/database/person/ etc. Right now it seems to a mix of features, functions and resources.

[gene]

That's an unusual structure. The one you had before (putting models/view/controllers etc together into folders) is the one you always see in projects. Does the routing engine handle this structure easily?

You may not have seen this structure often, but I see some advantages from this structure. And I am not the only one (e.g. see here, here, here, here or here). So perhaps unusual, but perhaps nevertheless better!?

Can I suggest to somehow distinguish between resources and everything else?

Yes, I noticed that as well and I am not 100% satisfied with it as it is now. I will probably create another folder next to the "app" folder, there is one called "components". In one of the above mentioned articles somebody hat a folder named "shared". That sounds reasonable to me. Give me a few days

[gene]

I realised the client side authentication in the oregami client.

Take a look at these screenshots:




Use "user1" / "password1" to login.

Up to now the only thing you need to authenticate to is to edit a publication: when you are not authenticated the "edit" button is disabled, when you are authenticated the button is enabled. Of course the authentication is not only on the client side, as everybody could bypass this easily. The server side (PUT request to /publicationFranchise) needs a valid authentication token.

It works!

[gene]

I achieved great progress with the logging of data changes:
In the generic ToDo application I added a "RevisionEntity" (Hibernate framework, documentation here) to record which user did which database change.

See it in reality here or in this screenshot:


Take a look at the source code here (server part).

[gene]

Now we have a list of "revisions", which shows the latest changes of all data in the database.
Check it out here!
The revision info is also shown when you look at a single task/language.

(login as user1/password1 or user2/password2 and change a task or a language to see new revision entries).



On the server side that required some lines of code and some deep investigation of Hibernate auditing mechanisms. But now it works!

[gene]

I reworked a great part of the Oregami server code (move duplicated code to a single place).
All entities for games (Game, ReleaseGroup etc) are now also audited as you can see here.

The Games-view in the client application also gains from this rework, as you can see here.

All in all very good progress to keep the code clean and simple!

[gene]

Dropwizard, the REST Web framework we are using for development, supports the usage of Hibernate, our chosen persistency engine. But not together with the Google Guice, the dependency injection framework which we are using also. So I had to do something about this, because internally Hibernate needs a file "persistence.xml" with the database configuration (username, password etc). This is not good because the persistence.xml file is included in the application JAR file and we cannot differ environments like "developement", "test" or (later) "production".

I managed to implement some kind of workaround (here is the big commit) and now the database configuration can be put in the (external) YAML configuration for the dropwizard app. So I can keep use a different file for "production" than I use for development etc.

This took me quite some days, and I even thought about trying Spring Boot, which is another new web development framework. But it's Spring (of course), and I don't really like Spring: works like magic the most time but if it does not work you are potentially fu**** up. But I finally managed it and now I'm glad that we still have a more lightweight approach with Dropwizard and Google Guice. Yeah!

[gene]

You can now edit publications !

(as usual, log in first with user1/password1 to enable the edit button)

[gene]

We are getting there step by step...

You can now create new publications:

(and again: you must be logged in to use the button, try user1/password1 or user2/password2)

Check out the latest version of our demo site.

Well, now up to the "deletion" of publications:
Is this generally allowed? Sure, in this demo system it would not really matter, but later on in production?
We weill have to think about this... Perhaps a marker like "should be deleted" is better, and only with the right authorization someone can then really delete it.

[MZ per X]

First of all:
Go, gene!

Well, now up to the "deletion" of publications:
Is this generally allowed? Sure, in this demo system it would not really matter, but later on in production?
We weill have to think about this... Perhaps a marker like "should be deleted" is better, and only with the right authorization someone can then really delete it.

At MobyGames, there's no deleting, but bad contributions are "sent back" to the original contributor, i. e. the state of the submission is changed to draft again with a comment explaining why. If the contributor doesn't do anything with this data set any more, the system auto-deletes it after some time.

[gene]

I started working on platforms or let's better call them Gaming Environments.
One new thing needed here is a "Transliterated String". That's a text attribute which can be entered in different languages and different scripts.

So every object of the class HardwarePlatform has a (collection of) field(s) of the type TransliteratedString, which finally contains the real text but is also assigned a Language and a Script.

At the end a HardwarePlatform can look like this (live/real URL):
(Sony Playstation in latin/english and japanese/japanese)

Code: Select all

[
  {
    "id": "ff8081814d3549ac014d3549b155003e",
    "version": 0,
    "validationId": null,
    "title": [
      {
        "id": "ff8081814d3549ac014d3549b14d003c",
        "version": 0,
        "validationId": null,
        "text": "Sony Playstation",
        "language": {
          "id": "ff8081814d3549ac014d3549b0e40024",
          "version": 0,
          "validationId": null,
          "name": "ENGLISH"
        },
        "script": {
          "id": "ff8081814d3549ac014d3549b07c0017",
          "version": 0,
          "validationId": null,
          "value": "LATIN"
        }
      },
      {
        "id": "ff8081814d3549ac014d3549b152003d",
        "version": 0,
        "validationId": null,
        "text": "プレイステーション",
        "language": {
          "id": "ff8081814d3549ac014d3549b0f4002a",
          "version": 0,
          "validationId": null,
          "name": "JAPANESE"
        },
        "script": {
          "id": "ff8081814d3549ac014d3549b07e001d",
          "version": 0,
          "validationId": null,
          "value": "JAPANESE"
        }
      }
    ],
    "platformType": null
  }
]

Next up is a nice web frontend to display and add/edit (!) this kind of objects.
And of course continue the work on the GamingEnvironment data model implementation!

[MZ per X]

I started working on platforms or let's better call them Gaming Environments.

Need to hurry with my blog post, or you will have coded it faster than me describing it, right?

So every object of the class HardwarePlatform has a (collection of) field(s) of the type TransliteratedString, which finally contains the real text but is also assigned a Language and a Script.

Ah, the goodness. We're getting there, thumbs up!

Two things still missing from the data model is regional naming, i.e. Super NES in North America and Super Famicon in Japan, and abbreviations like SNES. This should be a little like our title connection for the games, just not this complex.

And of course continue the work on the GamingEnvironment data model implementation!

For the data import from TL we would need only the GE level, I think. I would like the GEG to be added on top, too, because this is the lowest level of the model. But this whole compatibility and sub-platform thing can be added later.