Posts Tagged Math
Making it easy to work with performance
Posted by Morten in Uncategorized on June 13, 2011
We’ve been working with performance in our REST API a while back. We’ve been considering different options for measuring our API in production, but we had an idea to use the design of the API itself to handle the measuring.
Part of the inspiration came from the Changlelog’s coverage of CodeConf and Coda Hale’s Metrics talk. (Slides).
Using our pipeline approach to constructing a REST-API with conventions, we added a pipe that starts a stopwatch and stops it when the request is finished. Then we can log statistics for each individual part of the API, closely coupled with the code that is executed for that particular request. I pitched the idea to my good colleague Johan Andersson, and he did a fantastic job at implementing the solution!
The output looks something like this:
This allows us to see how our API is performing in production, and where we need to focus our optimization efforts to make the API go faster. We can even add some flags to the request to get more detailed output.
The guessing user interface
Posted by Morten in Uncategorized on January 13, 2010
My girlfriend has downloaded a solitaire application to her HTC Tattoo. While solitaire isn’t anything revolutionary it has an interface feature which got me thinking.
Se what the interface does is move those cards that it is sure that the next step is to move. So if I for example get an Ace, it moves it to it’s correct place at the top four card stacks.
This feature got me thinking about mobile phone interfaces. In applications in general, but even more so in the mobile context, you want to reduce the amount of interaction done with the user interface.
What if we can “guess” the input of the users input in the interface even in business applications?
We have hints in the domain, such as if you select this type of project you cannot register this type of time on it. You don’t register vacation time on a customer’s bill if your a consultant. Well, at least not that often.
These hints are common constraints, you might not want to enforce them by disabling the alternatives available. But you can check them and see if for a given input if there are any “assumptions” you can make about the next input to be made.
To take this one level further. We have the application data. We can order things in the UI according to a statistical analysis. Given this value in a combo box, this other value has more than 80% chance to be set in the other combo box. In such a case we can “guess” that this is the input the user would want to enter, and worst case is that he has to change it.
The cost of changing a value in a combo box is equal to setting one in the first place.
Now statistical analysis of data can often be costly, and typically not something you would want to do in a UI scenario. But what you can do instead is to calculate the statistical values into a decision graph (I think of it as similar to a Markov process for those whom have studied them). We can calculate this graph every evening and have a graph available for all input for the next day. Traversing the graph is now a simple algorithmic exercise.