Financial maths for modelling sport
April 2nd 2010
I'm currently studying for an investment exam so I couldn't help but think about some of the maths I'm learning when listening to Jenson Button talking about the joy of winning when you are driving a car that isn't the fastest.
One of these equations is the Information Ratio. This measures the extent to which a portfolio manager has added performance, measured against a set benchmark, as a ratio of the risk (volatility of returns) when compared to the benchmark.
To put it in simpler terms, if the benchmark performance is 7% year on year, then the amount by which the portfolio's results differ from 7% is the risk (called tracking error), and the net result of those differences is the return.
Result - Benchmark Result / Tracking Error
If you aren't mathematically inclined this might seem complicated so I'll get to the Formula 1 bit quickly.
First we need to establish a benchmark. It is a little quick and dirty but if we take as a benchmark the average fast lap time (excluding in and out) performed by a Mclaren for each 10 competive laps. So we are measuring the average every 10 laps irrespective of who set those laps.
Now we need to establish how the drivers differ from that. Some laps will be better, some worse, so we'll take all their lap times, find out how they differ from the mean expected lap time and calculate the standard difference (Standard deviation). This is the tracking error, but we'll call it Dv - Driver variability.
Finally, we need to take the best lap time out of all the practice sessions. We'll call that Td - The driver lap time, and the best average lap time, we'll call that the Tm - The McLarent lap time and measure the difference.
The final formula looks like:
Td - Tm / Dv
Of course all of this is off the top of my head, full of a massive number of problems* and assumptions, and about as water-tight as a collander, but, just possibly, this kind of calculation might give some kind of insight into the amount of benefit a driver gets given the amount of mucking about he does with set-up over the course of a weekend.
That might be interesting, right?
Other ratios might be more relevant of course. Points over a season compared to variance in a drivers racing lap perhaps? Whether these are relavant or not, I'm sure there are metrics out there that can help put a number on and compare drivers with their team mates, their competitors, or even their historical idols.
These I would like to see.
*Problems: data sharing between team mates, fuel loads, tyre performance, temperature, rain, etc ad nauseum.
0 Comments
Alternative User Interfaces
January 30th 2010
In my opinion the most important change in blogging software in the near future is going to be driven by the potential for new content types. It isn't the content type itself that makes the difference though, but the need to create an infrastructure around that content type to properly deal with it.
As content types go the humble blog post is pretty flexible. You get a date, some taxonomy and a big space to put HTML into and with that you can do pretty much anything you want. That, however, is the same as saying that HTML is flexible: You can make it to do whatever you want but you are going to need some scafolding to do it.
Despite that flexibility a blog post is generally not suited for use as, say, a photoblog post, for one main reason: the UI. The UI assumes HTML content with media as an insert instead of what you really need which is a single attached photograph front and centre and some text as a footnote. You can quite easily create a photoblog post by inserting a photograph into the HTML content but really the experience could be so much more.
If however you install a plugin that creates a photoblog post content type then that plugin is also going to need to create a UI for managing these posts and it is here that the potential really gets going. Even if the underlying data is the same, the alternative UI can give you options to make the end result so much richer.
As a photoblogger myself I can't wait to see a complete photoblog solution for WordPress or Habari that gets rid of the standard blog post admin and replaces it with something custom designed for selecting photographs. I've seen photoblog plugins before but none that really sorted out the UI.
This particular example is however a prelude to a wider topic and that is whether the entire admin area of a system should be removed to a selection of plugins.
As publishing systems become less specific in their focus, for example, by adding the ability to create new types, you have to ask whether it would be better to create only the most basic admin page, and move all the controls to plugins so that the software can be downloaded as 'editions'.
A photographers edition where the administration area enforces a workflow based around media might operate very differently from controls designed for designers, bloggers, static sites, etc.
There's nothing stopping plugins from removing content and replacing it, but I can't help but think that putting most admin controls into plugins sends a message that alternative admin areas are expected, and that might kickstart the desire for developers to actually create them, instead of trying to optimise what is already there to a particular need without really changing it.
0 Comments
Why the iPad is the first Apple device I've cared about
January 28th 2010
I find it really interesting to see how many forward thinking techies are disapointed at the new Apple iPad. Stephen Fry suggests this is because they haven't tried it yet and one play with it will instantly transform their opinion but I don't think that's the issue.
Look at all the criticism and it has a lot in common. For the most part, that I've seen, the problem is that it is too big to replace the iPod touch, too restricted to replace a real Mac, won't let me do X or Y, etc. All of which, in my opinion, completely misses the point.
What I love about the iPad is that this is a genuine consumer device. It is a lifestyle device. This is what all those science fiction devices were about. If you know what CSS is, this isn't for you.
The fact that this is coming in with iBook is no coincidence as its method of use is exactly like a book, newspaper or magazine.
In my mind is a family; A real family in their sitting room, and they are all there. No one is sitting alone in a cramped back bedroom checking e-mail, shouting down the stairs every-so-often to ask what date such-and-such is happening or whether we are still speaking to cousin Millie after the you-know-what. They are all sitting watching TV.
From time to time someone asks "what else has he been in?" and the iPad is picked up from its position leaning against the side of the sofa, a quick search is done, a list found, perhaps the iPad is passed to the person who asked or the Pad Hog just reads out the list (why is it that men always have to have the iPad).
A presenter mentions some news event and "that reminds me, John e-mailed some photos of his new place"...and so on.
This device is a game changer. It is the fire and forget, ubiqutous computing, device for the masses that we've always imagined.
The fact that it is basic is exactly the point and plays a part in why this will succeed where Microsoft et. al. failed. People don't want small computers; computers are difficult and complicated and go wrong and give you confusing messages; they want information to be on hand like an encyclopedia in the book case in the corner or the TV guide lying on the nested tables.
This is everything that techies don't care for. It is easy, friendly, basic, and does its job. No sk1llz required. It doesn't need tweaking, it isn't supposed to have POWER, it isn't sexy, hell, it probably won't be cool, but it will do its job and change the world.
What I love about the iPad is that it is mean't to be anonymous, not cool.
0 Comments
Mulling on themes in a variable content-type environment
January 27th 2010
A couple of posts ago I asked what the difference was between themes and plugins. Here's why:
To my mind, a theme is a collection of web pages (or template files) which may have some extra functionality bundled with it and a plugin is extra functionality which may have web pages (or template files) attached.
The key difference in real terms is that it is assumed that most template pages will exist in the same place (for a particular theme) and have certain pre-defined file names because, in a system with pre-defined content types, you can pre-judge what pages will be needed to display that content.
Taking WordPress as the example we know a home page will be needed, a page page, a single page, a category page, etc.
In a system which starts without any content types or a system that actively encourages new content types there may however be different needs that suggest alternative ways of dealing with themes. For example, even though you might not know what kind of content will be used you can still pre-define item.php, item.{type}.php, item.{type}.multiple.php, taxonomy.{type}.{name}.php and so on, but the chances of these being able to deal with even the simplest content type are remote.
The question is, in this kind of environment should themers just try their best to cope with the most likely scenario: pages, posts, images, etc, or are there ways for the system to organise theme content to make it easier for plugins that create new content?
A follow up to this is, if there are ways to organise content, would any of these things be useful in existing platforms such as WordPress?
The first step is probably to remove responsibility from the theme for assembling the actual page. There seems to be little reason for a themer to need to create any content that sits outside the body of the page. CSS and Javascript files can be registered for inclusion by the code, page titles can be set in code, you could if you wanted provide options to choose the doctype and encoding, although I think standardising these might be preferable.
Another possible option is to try and standardise as much of the HTML as possible; for example, the HTML for most menus tends to be the same. If the themer doesn't have to worry about creating a menu, instead just inserting one where he wants, then all menus can have consistent skeletons that themers can add skin to. The same might be true of the html for creating columns and other variable features.
This is not radically different from the way child themes operate, although it would have to be more flexible. In addition, WordPress already does this in a few areas such as the comment form, and some HTML that originated in the Kubrick theme.
Finally, if plugins add the ability to use new content types they should probably also specify a default HTML template and layout, using mostly standardised class names, for that type. Ideally a theme should be able to call $item->output() or similar and be presented with the appropriate HTML and CSS. Standardising on HTML 5 would make the styling issues much simpler as well as a themer would not need to worry about which level header was used for the title etc.
Whether or not these specific ideas, none of which are new, are the best way of dealing with it is one question; however, they are all generally a variation on standardisation of content with a view to removing the amount of actual HTML a themer produces. Ideally they would produce none, although in the real world it is almost certain some would be required.
This leads back to the original question about the difference between plugins and themes. If a theme can be produced without writing any HTML (or writing only a few layout pages which components slot into) and it can be skinned using the equivalent of a child theme containing nothing but CSS, then the difference between themes and plugins disapears and presentation becomes just one more thing you can write a plugin for.
0 Comments
WordPress coders have no class
January 25th 2010
A few days ago a brief Twitter conversation amongst some of the WordPress folks I follow pondered the question of whether WordPress plugin and theme authors have a tendency to use object-based techniques in their code primarily to show off the fact that they can. This started with a comment that the code was often quite difficult to decypher.
This is an interesting question as it contains a number of assumptions about the necessity of using object oriented code in a non-object oriented environment.
What do I mean by a non-object oriented environment? Well, firstly WordPress still does not require PHP5 for core code so there are limits to how many of the techniques it can use anyway. Secondly, WordPress has been around for a long time and has been developed by many contributers looking to achieve specific things with each patch without having a particular architecture imposed, except by committee.
WordPress developers tend to start as users who learn PHP in fits-and-starts when they need to acomplish something. They move from echo statements in themes, to functions, to classes, picking up ‘best practices’ as they go.
This is certainly true for me. Only recently have I graduated from using objects to organise code a little better to considering how I can use design patterns and good design to really improve the quality of testing, encapsulation, reuse, etc.
The thing is though that this transition has happened as a result of two processes: The first was learning how to develop for Habari and the second was beginning to develop my own content management system.
Habari has been developed using established and recongisable design patterns (once you know what to look for), and requires some object oriented techniques, such as extending base classes to build even simple plugins. Once you start needing to delve a little deeper into the code you have little choice but to learn what is going on.
My understanding of Habari itself was significantly improved once I started to trying to built my own system. I soon found out that what seemed like a nice way of making things work in Habari was actually something that had long existed in other languages, for example, an Active Record pattern, or a variation thereof.
What is important about these steps is that I needed to step away from WordPress to learn them. Which is another way of saying that when using WordPress I just didn't need to know. The same is probably true of almost all WordPress developers.
So, should those WordPress developers who are familiar with these techniques hold off on using them in their plugins or themes to make sure that other developers can more easily adapt their code?
If these techniques become more prevalent in themes and plugins they will certainly lead to more uninformed use of classes and object-based techniques by people who see the benefits but haven't yet learned the academics. The question is whether it is better to push developers toward this kind of thing, and deal with the intermediate steps, or to try and focus energy on other matters and keep code as understandable as possible, if that is even possible?
I am not intending to try and answer that question, but I think it takes me back to the original question about objects and classes being used as an act of self-congratulation instead of for sound architectural reasons.
I don't think classes and object-based techniques are used because they can be, or because they appear clever (on the whole), but because once you start to learn about using objects there is a certain elegance that becomes apparent. The fact that the coder may know and understand only a small fraction of those practices and the reasons for them doesn't take away from that.
It is enthusiasm for better code and better practices that leads people to use them, rightly or wrongly, and I don't think we should complain too much about that.
17 Comments
A question about blog platforms
January 20th 2010
A thought occured to me today. I was going to write it up (and still will) but I first I thought I would ask the question on which the thought is based:
What's the difference between a theme and a plugin?
1 Comment
What's the bare minimum a web publishing tool must have?
December 28th 2009
For a long time I have been arguing that WordPress should be removing features and providing them as core plugins instead of loading up the core code. That's the way I like things; however, I understand that WordPress is a tool for the masses, and so more (as opposed to less) is indeed more in this case. If it did happen though, what would be the absolute minimum feature set that the core should be left with?
I've been trying to think around this for a few days now and it isn't a simple answer. Obviously you need to be able to type in a URL and get content, but must that content contain 'pages' or 'blog' functionality or both? You can have a website without a blog but can you have a blog without any 'pages' at all?
What about media management? Is that something that every web publishing tool must have, without exception?
How about the admin interface itself? User management probably needs to be built in to the underlying API but is a visual user interface necessary when you may choose to control any number of blogs from a central point and therefore never need an indiviual admin tool?
The admin area is a good example of functionality that you might want to separate from the core so you can switch it out for something else. With a plugin admin area you can choose the most feature laden and complex setup or a simple three button fisher price version depending on your intended use.
Keep in mind now that I am not actually suggesting that any functionality would be unavailable, simply that you would need to use a plugin to get it. Anything over and above the core would be optional.
So what features and functionality should be always on because it simply cannot be done without?
10 Comments
Not Another Content Management System
December 26th 2009
When I started this website I did so because I was in need of a project. I was coming to the end of 365 days of photography and needed something else to focus on. So, instead of throwing up a WordPress or Habari install and spending my time theming I decided to build the system myself.
As it wasn't intended for public consumption it didn't need to be all signing or dancing, or even particularly extendable, it just needed to do what I though I would need it to. The basics.
So I put together a basic request handler, a way to save content and produce different types of content, some taxonomy controls and I was ready to publish.
With this site live I moved on to the next project, rebuilding photospots, and it made sense to use the same platform. I was already familiar with it and with some extra user management, flickr integration and geolocation classes I could quite easily turn it to running a membership driven site.
In doing that though I found I needed to update a lot of the original code. It didn't need to change, just handle some extra situations. So I went ahead and updated it.
So what do you do when you have two different versions of the same basic platform running? I figured my next project should be to combine the two and produce something that was a little more extensible. And that's where I'm at now.
Writing your content management system
Writing your own content management system (using the plain English definition) is a fascinating business. When you work with WordPress or Habari most of the work has been done for you; you just need to figure out how to extend it for your needs and invariably you come up with cool things that the software could do.
You also find your own gripes. Not OOP enough, too bloated, too complicated, It doesn't matter what the gripes are, there are people with opinions on both sides, they are invariably based on your own view and uses of the software.
When you start to build your own you start to think on an entirely new level. You need to start thinking about architecture, about consistency, about speed, practicality, extensibility and so much more.
One of the most interesting aspects is that there are so many ways to achieve the same thing and lots of reasons for doing things one way or another. Here's a good example:
A thread on WP Hackers last week was discussing methods for dealing with metadata for content items. As my system was built to use multiple content types by default this got me thinking about whether the way I had gone about implementing this feature was the most effective.
The model I used for storing the data was this one:
The gist of this model is that the standardised information about each item (type, name, created date, etc) is stored in one table, and all the data fields that are type specific (e.g. an image for photoblog posts) are stored in the details table in key / value fields.
This is easiy to implement and, as it doesn't require any changes to the database structure to deal with new types, is also easy to maintain.
It does however have its problems. First, it stores far more data than is needed because, instead of a single column of values it stores the name of the key every time a value is saved. This also makes it slower to query. It also means you have no control over the data types stored. They will always be stored as a string.
The key issue with it though is that it can make it hard to do even fairly simply queries. Take the situation where you want to return all the records where value A is less than X and more than Y and value B is less than Z. It is a simple enough query normally, but I couldn't say quite how to do it with SQL using this model.
So what are the alternatives?
The first is to modify the database in one direction; i.e. to add columns. When a new post type is added, new columns are added to the post (or the details table). Any columns not used by a particular type will contain null values when not used.
I don't like this option as it adds columns that may be entirely unnecessary for most of the content, and makes column changes to all of the data each time one type is changed. It feels as though it might have performance issues as well, but I'm not sure on that.
The next option is to add a new table for each post type.
This option feels much neater, but is likely to involve more code to manage it. The first option makes adding extra content a trivial matter which anyone can do. Not dissimilar to the custom fields option in WordPress. If you need a new option just add it. Adding a new column to a table to do that is a much bigger deal, so you may end up not only with a table for each type but also a generic details table as well.
The option you choose depends on what you want the system to do, or not do, whether speed or extensibility is more important, how much control you want to leave to the users, and so on.
It is these sorts of questions and decisions which using WordPress or Habari takes out of your consciousness and is exactly why writing your own CMS is so interesting. Right now I am leaning toward the third option, rather than the first but there are always reasons to change my mind.
There is also something very satisfying about typing in a URL and seeing a plugin serve up custom pages when you started with a blank file and a head full of ideas.
I don't know whether my system will or should ever be ready for public consumption; I will make it open source, and it will almost certainly be stored in a public respository; but that isn't really the point. There was something that didn't work for me when I was using WordPress. I can't say or sure what it was, but it seems to have been resolved by using something I've written myself. Long may that continue.
3 Comments
Programmatic Themes
December 12th 2009
For some time now I've been thinking about programmatic themes. That is, themes that are produced entirely in PHP and as a result can be modified entirely by code.
The concept of using objects within code which are directly representative of HTML elements is not a new one, ASP.Net uses this extensively as does Habari for form handling; however, I have yet to see a full theme handling framework produced for WordPress and the idea intrigues me a lot.
Before I go on to consider the advantages and disadvantages of this let me explain a little bit about what I mean.
WordPress themes are really just normal PHP files. Everything WordPress loads in the background is aimed at preparing the data that will be needed when the webpages that make up the theme are loaded. Once this point is reached WordPress chooses which file should be used and it runs with very little intervention, as if it had been called directly.
Some other systems use a more involved process whereby the HTML and some special codes are included within template files. The content system loads this template into a variable and replaces the special codes with content before echoing to the browser. These can be quite complex with markup for insertion, formatting and even repeating regions. Despite this complexity and control these template files are still essentially hand crafted html which is off limits to the code.
What I am interested in is a process without any template files at all. Instead of template files the theme contains a library of PHP objects that represent HTML structures. For example, you might have a menu object into which you add details of the items you want to include. When called the PHP object will output a div tag that contains an unordered list which in turn contains all of the menu items you created within your PHP script.
The concept might be difficult to imagine so let me provide a slightly more involved example using some code.
In WordPress, the functions.php file contains:
//create the page object//this handles all the doctype, header, etc.$page = new page();$page->title = the_title();//create a header object$header = new htmlcontainer();$header->width = '100%';$header->height = '200px';//create the content for the main body//use a container object which is a DIV or series of DIVs$contentContainer = new container();$contentContainer->width = '100%';//we went this container to have 2 columns, main and sidebar$contentContainer->columns = 2;$contentContainer->columns[1]->width = '70%';$contentContainer->columns[2]->width = '30%';//we want the first column to contain the post content only//so create a generic container for the content$content = new genericHTML();$content->content = the_content();//add the generic content object into the first column$contentContainer->columns[1]->add( $content );//add the content into the page$page->add( $header );$page->add( $content );
There is only one other template file, the index.php file. This file contains one line:
$page->display();
This triggers every item that has been added to the page to output its HTML in order. This creates the page.
So Why is this an interesting concept?
There are a few reasons why this concept interests me. Firstly it puts almost every aspect of the layout into the control of the coders, so you can not only create the layout with code, but easily modify it as well.
Taking the above example, converting this from a two column layout to a three column layout is a matter of modifying a couple of lines of code, or using a plugin to alter it before it is output. Similarly, if you need an extra class, or an extra DIV inserted somewhere you can modify the output of the object so that it is produced.
This concept also makes it possible to create a user interface to modify most parts of the layout instead of selecting from one of several pre-designed layouts. While it is true that a small selection of layouts is generally suitable for most users greater control is an attractive concept.
Finally, the object library can be extended to include objects that do not directly mirror HTML structures, for example, an object that outputs microformat based elements or mapping.
It isn't all good, of course.
Firstly, the additional control comes only where there is additional development to provide interfaces for it so by default this leaves, potentially, quite complex code which new users may find difficult to get a handle on.
Secondly, plugin authors are unlikely to specialise on themes that use this concept when everything else is produced in the usual style. This style is also likely to put much of the layout CSS inline, or at the top of the page, which might make it difficult for plugins that aren't written for this style to override it.
Third, all this object processing creates significant overheards. These can be managed with appropriate use of caching but this will never be as efficient as simply including a text file, which is effectively what normal templates do.
This is entirely theoretical, the amount of work involved in putting something like toghether is significant and not something I would do on a whim, but I am interested to know what people think of the idea, or if they know of somewhere that this is already a reality.
1 Comment
Privacy for Web Apps
December 12th 2009
A post currently going on (and on and on...) in the WPTavern forums illustrates the way that some people don't really get the whole privacy thing. That isn't a criticism, they just don't see what the fuss is about. This post is to explain my general position.
I think a big part of people's failure to understand privacy concerns is the point where they start their logic; their default position.
My default is this: Information that relates to me, in any way, is mine.
The only exceptions to this statement involve an abuse of my rights. It is a common occurance and given the abusers I have little choice but to accept it. Nonetheless, they are in the wrong.
If I use a piece of software that you have produced, if you want to know something about me then you must ask. Whatever it is. Even if that data is in the public domain. Even if that data is printed on my website.
Note the difference here between ask for and notify about taking.
The issue being discussed about WordPress is trivial and not one I really care about, but the arguments being made do matter, a lot. You see, a lot of those arguments are of the sort that ask those concerned with privacy why they want to restrict the data. They ask what harm could come from them having that data, what evil could possibly be done with information that is already in the public domain in most cases anyway? These are entirely the wrong questions and really miss the point that any privacy advocate is trying to get across.
So here is the key point of this whole thing. The basic concept that you need to understand. By default the data is mine. I don't have to have a good reason to deny you access, you need to have a good reason for me to provide you with access. The burden of justification is always on you, the person that wants the data, in all circumstances, so you need to convince me that I should give it to you.
It doesn't matter what the data is, it matters that it is mine.
2 Comments