True Games

Portal Architecture

Although this architecture was never realized in full, some of the pieces were assembled before UTV Ignition closed down its studio and its publishing effort.
Furthermore, it was our intention to deploy this to a public cloud infrastructure (likely Amazon). Our hope was that it would be completely compatible with Amazon's Elastic Beanstalk.

SSO Solution (with multiple user-agents)

A gamer is playing one of UTV's games, running a local client. (So, he's logged in once already). From a menu in-game, he clicks a button which minimizes the client and launches a browser, taking him to the web store. Now, he has to authenticate again.
That was the problem to solve. But note that it's not a simple SSO problem. It involves more than one user-agent (the game client and the browser).
The solution we settled on was: The game client would invoke the browser, passing the TGT previously acquired from the first authentication to the browser, and it would be held in memory by javascript. The local html file includes a javascript file on the server. That javascript redirects the client to another server-side file (along with the TGT) with more javascript which directs the browser to set the TGT into a cookie (TGC). With the TGC set, the normal CAS flow can take it from there, and, aside from a couple quick redirects, the user is unaware.

REST Service - as a Client

While a simple REST service class is not a tremendously sophisticated thing, this class does include the use of Java's concurrency package, along with a timeout (waiting for Gamigo to resond). I try to make the layout and organization of the code as informative as the code itself. GamigoAuthServiceImpl

LDAP user migration

There were over a hundred thousand users from previous Beta tests that needed to be moved to a new LDAP instance. The conversion wasn't straightforward, of course. The users had to be shoe-horned into a new schema.
A standalone spring app using Spring's LDAP library would suffice here. Please note the use of JUnit, and know that I wrote the tests first :). The Migration Manager is just a grind through LDAP entries. But the Migration Test is kind of interesting. To handle testing each line, I created an inner class hierarchy:
    private static interface LineHandler {
        void handleLine(String line, int lineCount);
        void allDone(int totalLines);
        void asserts();
        void startGroupEntry(String line, int lineCount);
Note that each line handler is capable of making its own assertions about each line.
See Migration Manager and Migration Test

Client-side artifacts build and deploy pipeline

The build and deployment for the client-side products (patches, installer) of Faxion was in a simply unmanageable state. While I have a rule-of-thumb that says,
"Don't finish your 10th line of code before you have a complete, end-to-end, automated build and deployment system,"
the Faxion client-side products were still being built by hand using a GUI application from the patch-solution vendor.
I was given full autonomy to completely architect and implement the build and deployment for these products. While I wasn't hired for that work, it was a critical need, it was acknowledged that I was best suited, and I volunteered to make it functional.
Click the images for full-sized diagrams.

The build file itself is of special note: See: build.xml.