Page 5 of 9

Re: Developer's diary

PostPosted:07 Apr 2014, 22:03
by Sidasa

Re: Developer's diary

PostPosted:17 Apr 2014, 06:04
by gene
I found postman to be a very helpful tool during API development: it's a Chrome Browser application to send HTTP request against a REST server.
Really very helpful! (see below)

An interesting development approach is also "API first development".

Image

Re: Developer's diary

PostPosted:28 Apr 2014, 22:02
by Sidasa
gene wrote:I found postman to be a very helpful tool during API development: it's a Chrome Browser application to send HTTP request against a REST server.
Thanks for the tip. looks really cool.

Another tip: JSON Generator
http://www.json-generator.com
Create fast dummy data in json for debugging.

Re: Developer's diary

PostPosted:17 May 2014, 07:44
by gene
As you might know, we are using Dropwizard for our REST server application.

Dropwizard got a major version update (0.6.2 => 0.7.0) a few weeks ago. The migration from 0.6.2 to 0.7 needs some changes in our application.
I started with the migration to 0.7.0 and during that process, I decided to first create a brand new, generic REST server application from the scratch to get to know more about dropwizard and all the things I developed so far in our server application. It will we a classic "ToDo application" :D

Things the application will contain:
  • built on Dropwizard version 0.7.0
  • dependency injection with Google Guice
  • Hibernate / JPA 2.1 as database access framework
  • HSQLDB as database
  • "Session-per-HTTP-request" with Guice PersistentFilter
  • suport for cross-origin resource sharing
  • JPA entities with UUIDs as primary keys
  • a pattern for accessing and manipulation entities with HTTP REST calls (Resource => Service => DAO => entity)
  • a pattern for ServiceResult objects which contain ServiceErrorMessages (which can later be bound to web form fields in the client)
During the next weeks, I will publish this new "dropwizard seed" project to Github and will do a blog post about this.
I hope we can draw some attention from some REST developers out there.
It will be great to first develop new technical features (like HATEOAS support) in this general purpose project and then transfer them to the Oregami server project. This way everyone will be able to benefit from our work in the open source sense isolated from the "game data context".

I will try the same for the client application:
A ToDo client application built on AngularJS, Grunt, Bower and NodePackageManager npm.
This client app will offer the posibility to list available tasks, create new tasks or modify available taskas through REST calls with the help/usage of:
  • AngularTranslate for multi language support
  • Restangular for async HTTP calls
  • unit tests (classical and end2end)
  • a pattern for calling REST services with ServiceResult objects and tranforming them into error messages in HTML forms (is already working on the Oregami client site)
Watch this place for updates!

Re: Developer's diary

PostPosted:19 May 2014, 21:24
by MZ per X
gene wrote:It will be great to first develop new technical features (like HATEOAS support) in this general purpose project and then transfer them to the Oregami server project. This way everyone will be able to benefit from our work in the open source sense isolated from the "game data context".
So, technically, we've finally developed the bigger picture? ;) I'm curious where this is headed!

Re: Developer's diary

PostPosted:19 May 2014, 22:08
by gene
MZ per X wrote:So, technically, we've finally developed the bigger picture? ;) I'm curious where this is headed!
Nah, we are just making our technical progress so far better available to the rest of the world. :roll:

Still A LOT to do!

Re: Developer's diary

PostPosted:21 May 2014, 22:52
by gene
gene wrote:During the next weeks, I will publish this new "dropwizard seed" project to Github and will do a blog post about this.
A first version of the generic server project is online at github.
Feels good!

Re: Developer's diary

PostPosted:25 May 2014, 20:20
by gene
I just integrated a Travis CI buildjob for the new dropwizard-jpa-seed-project. Travis CI is a hosted, distributed continuous integration service used to build and test projects hosted at GitHub.

You can see the passing builds here.

Re: Developer's diary

PostPosted:29 May 2014, 07:45
by gene
In my second attempt I successfully migrated the oregami server application to the new dropwizard version 0.7.0.

Code changes are committet, application is deployed.

Re: Developer's diary

PostPosted:12 Jul 2014, 19:16
by gene
gene wrote:
gene wrote:During the next weeks, I will publish this new "dropwizard seed" project to Github and will do a blog post about this.
A first version of the generic server project is online at github.
Feels good!
Today I published a new feature to the generic server aplication - and will try to add this also to the Oregami server application soon!

I added the support for basic version control with Hibernate Envers.
So if you change an existing entity, Envers automatically saves the old state of that entity. Then you can e.g. ask the database for the revisions of a single entity or you can load the concrete older revisions.
Some general information about Hibernate Envers can be found here, the full developer documentation is here.

The most annoying thing I encountered was that I got some weird ClassCastExceptions when I asked Envers for the revisions of an entity. It turned out that dropwizard included an older version of Javassist than the version that Hibernate Envers needs.
So I had to do this in the pom.xml:
Code: Select all
        <dependency>
            <groupId>com.hubspot.dropwizard</groupId>
            <artifactId>dropwizard-guice</artifactId>
            <version>${dropwizard.version}</version>
            <exclusions>
                <!-- javassist used here is too old and must be excluded!
                See http://stackoverflow.com/questions/23215917/javassist-classcastexception-in-hibernate-and-netbeans
                -->
                <exclusion>
                    <artifactId>javassist</artifactId>
                    <groupId>javassist</groupId>
                </exclusion>
            </exclusions>
        </dependency>
Ugly! :-(


Another more interesting question was how to expose older revisions of an entity via the REST API.
I decided to do it this way:

Show a single task with:
Code: Select all
    GET => http://localhost:8080/task/[id]
List all revision numbers of a task with:
Code: Select all
    GET => http://localhost:8080/task/[id]/revisions
Returns [1,2] if an entity has the two revisions 1 and 2.

Show a special revision of a single task with:
Code: Select all
    GET => http://localhost:8080/task/[id]/revisions/[revisionNumber]
What do you think about this?

Re: Developer's diary

PostPosted:18 Jul 2014, 20:09
by MZ per X
gene wrote: Show a single task with:
Code: Select all
    GET => http://localhost:8080/task/[id]
What is a task, by the way?

Re: Developer's diary

PostPosted:20 Jul 2014, 15:44
by gene
MZ per X wrote:
gene wrote: Show a single task with:
Code: Select all
    GET => http://localhost:8080/task/[id]
What is a task, by the way?
:lol:
I was thinking of something like this.
This update was "only" for the generic, game independent server application I am developing for learning purposes and to make my insights available to the rest of the world that does not watch Oregami's progress.

I hope that I will soon find the time to transfer the auditing mechanics for entities to the Oregami server application.

Re: Developer's diary

PostPosted:23 Jul 2014, 21:26
by gene
I added a new entity "SubTask" to the generic ToDo server application.
It's interesting to find out how older versions of the now a bit more complex data model are saved and can be queried!

Re: Developer's diary

PostPosted:27 Jul 2014, 20:19
by MZ per X
Great progress, please keep going! :D

Re: Developer's diary

PostPosted:18 Aug 2014, 18:12
by gene
So, holidays are over! :mrgreen:

The next thing I will approach is the following:
In our data model (you better zoom out) we have multiple "top leven objects" (TLO). These TLOs can exist on their own, without a relation to any other object. Examples for TLOs are Language, Region, Game, GameTitle ans so on (all classes drawn in yellow in the UML diagram).
If such an object is changed, we will save the old state next to the new one, so that we will be able to show the differences that were made during the change. This does not only apply to "attributes", but also to "relations". Let's say that we connect a Game to an existing GameTitle. This connection is new, and we will be able to detect that in the state before the change this relation did not exist: The Game "did not have the GameTitle connected" before. So this makes a new state for the Game object.
But if someone changes the GameTitle object afterwards, this does not imply or require an update of the Game object. In other words: If a Game object is connected to a GameTitle object, it is always connected to the latest state of that GameTitle.

I will try to implement this at first for our generic server application and then do it for our bigger Oregami data model.

Stay tuned!