Facebook Trumps

I'm finding the idea of fixing everything before moving on a little tedious, but really its the right thing to do. Fixed Windows at present include:

• The stylesheet on this site: why was it orange? It is now blue.
• The link on this page now goes to "add application" rather than "play game".
• Upgraded host to Tomcat 6 (this was very involved).
• I can now view the Tomcat logs from the web.
• The logfile output location no longer throws an error everytime the game is started.
• The game is properly deployed and working.

Still more to do before I dabble with the next iteration!

• Complete "Finish Screen", displaying winner and option to restart.
• Present "Return to Game" button on Browse Trumps screen.
• Change last few "orange" links on this page.

So work to do ... the good thing is any of the 39 million people on Facebook can click the link on the right and actually play the game!

Labels: approach, facebook api, java, tomcat

I was randomly reading the website for Tapestry, which is a Java web application framework. I make no use of Tapestry on this but I like their principles:

• Simplicity - web applications shouldn't be rocket science!
• Consistency -what works in small applications should work in large applications. Different developers should find similar solutions to similar problems.
• Efficiency - applications should be performant and scalable
  
• Overall: The simplest choice should be the correct choice.

Sounds good to me.

Labels: approach

I read the following from a book on Safari (http://safari.oreilly.com/):

One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment- a sense that the powers that be don't care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner's desire to fix it, and the sense of abandonment becomes reality.

Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.

This seems like wisdom to me and at this point in the project I need to focus on this implications of it. Before I start on adding the new features I need to deploy and iron all the creases out of the current version.

Labels: approach, guice, gwt, java

I need to put the conclusions of the past two posts together- I need to decompose the application structure implied by my flow diagram into a set of HMVC triads as described below.

The top level triad will have responsibility for moving the application from one phase, i.e. the game creation stage or the end game stage, to the next, and also for providing RPC functionality - I don't want that kind of code just spotted round the place. The Root/Container Triad:

• Model: Contains RPC methods and global state.
• View: Practically none - contains "Loading..." view.
• Controller: Co-ordinates transistions from one Triad to another.

After the Root triad has obtained the stack of Trumps for that appropriate player, it creates a child Triad to "setup" the game: The Create Game Triad:

• Model: Instantiate Game, Set players, Shuffle cards, Deal Cards, Toss Coin.
• View: Welcome and display outcome of game initialisation.

Next the Create Game Triad signals it is finished and the Root controller destroys that entire triad, replacing it with the Game Triad, which again is a child of the root controller. Due to the complexities of this view it is decomposed into further HMVC triads which are orchestrated by the Game Triad Controller:

• Player Turn VC Triad
• Opponent Turn VC Triad
• Show Result VC Triad

These are "cut-d0wn" HMVC triads, consisting only a view and a controller. All of the model code however is contained within the higher level Play Game Triad. Messages are passed between components and the Play Game Controller will create and destroy the alternate child Triads as required. Therefore the Play Game Triad looks like this:

• Model: Evaluate winner of turn functionality, Determine if game has been won functionality.
• View- Several View/Controller Triads as above.
• Controller: Manage interactions between all these! Create/Destroy child Triads.

Finally there is a End Game Triad to display the winner of the game and offer the oppotunity to return to the beginning of the game.

• Model: Send result via RPC (I will actually leave this until the next iteration of the game).
• View: Show End Result.
• Controller: Allow to go back to the start.

The structure described above will allow me to decompose my code into disgestible modular chunks and also due to the separation of functionality and standardisation of messaging will allow easy modification and improvement later. It won't be a matt of spaghetti.

Labels: approach, facebook api, gwt, hmvc, java

The model view controller pattern is the classic pattern adopted for GUI and client applications (http://en.wikipedia.org/wiki/Model-view-controller). MVC however, is quite a broad pattern, and so I went in search of further detailed recommendations and architectural guidance. Luckily, Java seems to be a language which is adopted by people with an interest in software engineering principles, therefore a great many resources are available.

The client component needs to obtain a stack of trumps via RPC, compute the various outcomes in the game, communicate rich perspective on the game state to the user and accept interactions from the user. The most appropriate framework I could find is the HMVC (Hierarchical MVC) which is treated at length here: http://www.javaworld.com/javaworld/jw-07-2000/jw-0721-hmvc.html.

Following MVC principles the view (GWT Widgets) are delineated from the controller (flow logic) and the model (rpc, game logic). HMVC however fills in some of the gaps with respect to how these elements are composed and structured, and how these elements can communicate amongst one another. The heirarchical aspect allows a root controller encapsulating global concerns (such as the game and the trump stack) to control various children, such as turn screens, scoreboards or outcome views.

A concrete and usable example of HMVC is availible here, tp://www.thecentric.com/wiki/index.php/HMVC_Tutorial, which can easily be adapted to work with GWT.

Labels: approach, facebook api, gwt, java

So far I have:

1. Created a foundation capable of authenticating to the Facebook API, and making extracted data availible to a GWT application.
2. Written a routine to, given a set of Facebook friend profiles, return a set of Trump cards - which is to say a set of statistics determined by the underlying profiles for each friend.
3. Developed/Stolen/Borrowed a UI framework sufficient for the Facebook Trumps game.
4. Created a module which displays a user's Facebook friends, the representation approximating a real playing card.
5. Deployed the above to a "live" host rather than a "developmental" one (i.e. webhost rather than my laptop).

All of the above is pretty solid, and was so before I started this site. In addition I also have the following:

• Working but buggy and incomplete Game component.

Progress on this component has been stalled by a lack of clarity on my own behalf with respect to the two subjects taken up in previous posts. The rules of Trumps and my desire to allow you to play "against" someone, right away.

Having thought that through, the further steps are as follows:

1. Develop module to allow players to play a game of Trumps with a set of cards representing their own friends, vs. a CPU opponent.
2. Allow game to post back win/lose to server when done (and persist).
3. Deploy to webhost and ensure compatiblity with major browsers.
4. Invite people to use and deal with inevitable issues.

At this point I can start to entertain some of the diversionary thoughts about the future:

1. Multiplayer (who's set of cards?)
2. Scoreboard.
3. Integrate into profile (challenge me! button).

Labels: approach

I'm not a professional programmer, I did some programming at university and am exposed to the consequences of other people's code at work. Making a Trumps game from Facebook friends is not the most complex or difficult thing to do - however I want to do it right; as simple and as sensible as I can.

This is for two purposes - First in order that I can finish it, that it does not become lumpen and unmanageable and lead me just to give up - Second to learn, to spend sometime absorbing other people's experiences and hopefully improve my own skills. I want to become a professional programmer, and perhaps this can help.

My sources of wisdom, in other words what I have studied, are books blogs and articles from the Internet. O'Reilly have a service called Safari (http://safari.oreilly.com/) which I have been able to join. There are masses of software engineering and coding books on there. I have alse been able to follow discussions on usenet (via http://groups.google.com/) and application programming discussion websites (such as http://www.theserverside.com/). Other sources of information include developer blogs and API documents.

Labels: approach, developerworks, o'reilly, safari, serverside