Java Restlet api rocks

I have been using the java Restlet api for network topology stuff and it is quite nice. Seldom do you come across cleanly designed APIs these days it seems. It avoids a lot of the common pit falls java apis seem to enjoy:

Factory diarrhea == teh sux

Everyone who has used java has probably experienced this. If you are writing api realize that most people don't give a crap about a configurable factory. Give people concrete instances of things that default to a particular implementation. Configurablity is good but I should not need to enter a deep philosophical debate with my compiler just to determine how it should parse XML.

Fixed verbosity

Most libraries have a fixed way something must be done. More than likely the level of verbosity required to do it inappropriate for what the user is doing. Design your classes so they can function with out extra functions calls and other pointless boiler plate code if you can. When the user needs more control they can specify it when needed. People can learn your library faster and programming with it will be much more pleasurable.

Documentation

People seem to have strange ideas about what appropriate levels of documentation is. Hint: you need more than just javadocs/doxygen output. Your software should be the sum of its parts. Documenting the individual pieces in isolation with out providing more detail makes learning how to use your code orders of magnitude more difficult.

Use standard abstractions

If the language provides a standard library with things like iterators and structures use them! If programs are essentially language recognition and translation (which they are) then using common concepts is essential. If you don't do this you are failing at communicating with the people reading your code and also doing a poor job communicating with the machine which you are instructing.

There is a billion more tips but these are the major ones.

• API: Design Matters
• Programmers are People, Too

Rolling your own CSS

Having an easily data driven method for customizing style information can be invaluable for building nice user interfaces. For special purpose user interfaces like games it is even more important. Designers need to be able to easily skin and customize different UI elements with out having to alter source code.

UI Elements as Properties

To control the look of user interface elements a simple flat set of properties can be used such as "background-color" or "font". A style sheet is simply a class that you can get and set properties from: class Style { public object GetValue(IStyleable target, string propertyName); public void SetValue(StyleSelecter selecter, string propertyName, object value); } Just like in CSS a common way to refer to elements is needed. I used StyleID, a set of Classes and a Type to replicate the familiar id,class,elementType trio. This is formulated in a simple interface: interface IStyleable { string StyleID { get; } ICollection<string> { get; } string StyleType { get; } } A predicate for if a certain property definition applies is needed: abstract class StyleSelector { public abstract bool Matches(IStyleable target); }

Finding a Property

Every selector must at the very least support the ability to find a property by an O(n) search--this is what the Matches method is all about. Finding a property consists of a search over a list property definitions (StyleSelector,name,value). If a definition's name matches and StyleSelector.Matches is true then the search is terminated and value is returned as the value for that property.

In order for the cascading part to make any sense an ordering of property definitions needs to be defined. CSS solves this problem with the notion of specificity. Properties with more stringent criteria for being applied are allowed to float to the top and are used over the more generic definitions.

For my purposes I organize things simply by id > classes > type > *. So selectors that specify the id of its target are examined first. This conveniently allows for property searches to be culled to smaller sets that must be visited. Hashtables for each of these categories can be constructed to speed up search times so that for example (id,name) is indexed. This reduces linear searching only to custom and other miscellaneous selectors.

Combining Selectors

Aggregated selectors can be formulated based the AND logical operator. Since AND is commutative the selector can be rummaged through for any sub-selectors that are indexable. This can then be used as criteria for which index the aggregation should be inserted into. For example #myButton:hover can be inserted into the id indexing table since it contains an id selector.

I will probably post the code to this and the rest of my GUI toolkit when I am done / bored with it.

Game Rules 1

I mentioned I would talk about a domain specific language for game rules so I will but first a rant on why the term DSL is silly and some discussion on what a game rule itself will be.

The term DSL is kind of stupid

Like any good acronym one day you wake up and it is as if while you were sleeping everyone got together and decided to surprise you the next day. Suddenly people realized they could make their own languages to solve specific problems and that this was now the neatest thing since sliced bread and other suitably neat cliches.

It is not that I am opposed to them. I just find it appallingly annoying how computer science and the software industry is often reduced to fads. It is as if all the people who slept through their compilers courses (really when else are you going to get a nap?) suddenly realized that this information was actually useful. DSLs don't solve all of your problems--but being smart and knowing the theory behind them will transform them into useful tools. I suggest picking up the dragon book and books on automata and language theory.

What is a game rule?

When playing games generally there is a set of rules to play by. These usually follow as consequences for some action the player does. These rules can also be the consequences of actions by other rules. Such as a player moves his piece on a board game and receives 5 points. He already has 10 and it only takes 15 to win lets say. The rule for winning was based off an action from another rule (gaining 5 points).

A game rule is action and then a consequence or more formally a predicate and some function that changes the course of game play somehow. R = (P(s),F(s)) So to apply a rule P(s) must be satisfied. Then s := F(s). Of course fashioning this into an actual usable system will require more work which I will save for next time.

Game rule DSL maybe?

I am cooking up an idea for a game rule DSL and will probably post more when I actually start working on it. I am also kind of sleepy right now but think of something db triggers except not awful and crazy.

Reading Wizards First Rule

Started reading the Wizards First Rule by Terry Goodkind after a friend recommended it. Seems pretty entertaining so far! Time to go read more.