I think Bent is good goal scorer, with a proven record. But i don't think he's worth £18 million quid. Thats not an insult, i'm just old school and think that's a lot of money. (I don't think Chris Smalling is worth £7 million either, that is an insult ... to man utd ^_^, thanks Sir Alex we really like Dembele) It's a good question don't you think. I'm no accountant, but lets try and work this out. I'm always amazed at how a football clubs legal people arrive at these figures.and have felt that while they are crazy there has to be some kind of reasoning and logic to them.
It is slightly hard to do this as few things are actually official, but as Rafa says lets work with the facts (that are mostly rumours).
Darren Bent is rumoured to earn £50k a per week, and had 2 years left on his contract at sunderland.
That means that his contract excluding any bonuses or commercial rights is worth about £2.6 million a year or £5.2 million. I believe this should be his 'book value', and the value that would stated on Sunderlands accounts.
Next Darren's move to Sunderland from Tottenham cost £16 million, with a cash component of £10 and the additional £6 million to be paid in various (i assume) performance related bonuses. Now i would guess that a club like sunderland structured the majority of these payments to be done over a period of time, being that Bent only left a year and half ago, they probably haven't paid this total sum yet.
Lastly as reported, a cause in the deal with Tottenham, was that Sunderland had to pay them 10% of his next transfer fee, something they would also need to take into consideration when negotiating with Aston Villa.
So lets do some basic addition with the numbers above
£5.2m (contract)
£10m (purchase price from spurs)
£15.2m
Now lets say that Sunderland have a policy of trying to maintain a profit margin of around 10% margin on player sales, that puts us in a range of £16.72 million.
Now we are missing one thing, Spurs cut. Thats 10% right?
10% of 16.72 million is £1.72 million
Which i assume sunderland passes on to Villa, so we get £18.39 million. If if they can't legally do this £16.72 still isn't far off the headline £18 million figure that we see in the press.
In fact depending on how much sunderland and already paid tottenham in bonus related payments, they might not have even made a profit. Also i dont know if Darren's 50k p/w wage is before or after tax, because if it is after tax, the value of his contract to the club is effectively doubled. due to the 50% tax rate.
Not accurate, not throughly researched, but certainly interesting.
Next, how the hell did they work out 'CR7' was worth north of £70million?
If you got any insight for me please share either on twitter @veritech or in the comments.
The musing and sometimes not so wise words of Jonathan Dalrymple, Global Traveller, Programmer, Financial Rocket Scientist, Conspiracy Theorist, Part-time comedian, full-time funny man and whatever else i randomly decide to do.
Wednesday, January 19, 2011
Friday, January 14, 2011
Tuesday, January 04, 2011
NSNotificationQueue, Coalescing and SIGABRT
So it's one of those days, your steaming along adding a feature and then bam, you hit a road block. Well here was mine.
I've come to love many cocoa API's over the last year. One i've been late to embrace is NSNotificationQueue. What can i say that hasn't already been made clear ... it's a queue for notification objects ... well almost it has one particular feature that makes it totally awesome, Coalescing.
Coalescing is useful for when you want to call a method multiple times but only have it execute it's action once every so often. Since i've started coding for iOS i've been a fan of simply calling [UITableView reloadData] to refresh my table views, it's simple concise and i don't have to worry about index paths etc. However if you are drawing complex cells, and you need to call this method while you process some data you really don't want to happen every single time, the user isn't playing COD, they just want to see their data, and not have it flick around. So in my UITableViewDataSource classes i do this ...
With the handler to the reloadNotification calling the actual reload method. This means that in one area of my app, where i am listening for NSManagedObjectContextObjectsDidChangeNotification (gotta love cocoa conciseness )the reload method gets called just once instead of 10+ times.
Awesome right ....
Well there is a problem, you might have noticed that enqueueNotification: takes a postingStyle. This calculates when in the duration of the run loop the queue will attempt to deliver your notification. Because i want my Run loop to be a free spirit and not care about what my crazy background threads were doing i would usually choose NSPostWhenIdle. Well i did till today.
The problem is the UITableView that this data source is assigned to can be dealloc'd at anytime, and while my dataSource is a good cocoa citizen and removes it's self as an observer before it is dealloc'd the notification has already been assigned it's target and is waiting till the run loop is idle ... read waiting till after my object has been dealloc'd. This of course means the the objective-c runtime attempts to call the reload method on dealloc'd object, and we all know what happens when that happens ... Well i thought i did. I code with NSZombieEnabled on, so in such a situation i expect to see a nice friendly message saying i've sent a message to an invalid object ... I got that message ... sometimes. Instead 9/10 times i got a big, fat, bold SIGABRT.
Oh, but you have stack traces ... um no. When crap happens in the objective-c runtime, you close your eyes and pray that they will go away, well thats what i do.
Anyways the solution was to ensure that notification was dispatched as quickly as possible, so NSPostNow was a much better fit. My professional($_$) opinion is that unless you have a long running object (ie the app delegate) or a singleton, never use the NSPostWhenIdle.
Conclusion
NSPostNow > NSPostWhenIdle
(9 out of 10 times)
I've come to love many cocoa API's over the last year. One i've been late to embrace is NSNotificationQueue. What can i say that hasn't already been made clear ... it's a queue for notification objects ... well almost it has one particular feature that makes it totally awesome, Coalescing.
Coalescing is useful for when you want to call a method multiple times but only have it execute it's action once every so often. Since i've started coding for iOS i've been a fan of simply calling [UITableView reloadData] to refresh my table views, it's simple concise and i don't have to worry about index paths etc. However if you are drawing complex cells, and you need to call this method while you process some data you really don't want to happen every single time, the user isn't playing COD, they just want to see their data, and not have it flick around. So in my UITableViewDataSource classes i do this ...
With the handler to the reloadNotification calling the actual reload method. This means that in one area of my app, where i am listening for NSManagedObjectContextObjectsDidChangeNotification (gotta love cocoa conciseness )the reload method gets called just once instead of 10+ times.
Awesome right ....
Well there is a problem, you might have noticed that enqueueNotification: takes a postingStyle. This calculates when in the duration of the run loop the queue will attempt to deliver your notification. Because i want my Run loop to be a free spirit and not care about what my crazy background threads were doing i would usually choose NSPostWhenIdle. Well i did till today.
The problem is the UITableView that this data source is assigned to can be dealloc'd at anytime, and while my dataSource is a good cocoa citizen and removes it's self as an observer before it is dealloc'd the notification has already been assigned it's target and is waiting till the run loop is idle ... read waiting till after my object has been dealloc'd. This of course means the the objective-c runtime attempts to call the reload method on dealloc'd object, and we all know what happens when that happens ... Well i thought i did. I code with NSZombieEnabled on, so in such a situation i expect to see a nice friendly message saying i've sent a message to an invalid object ... I got that message ... sometimes. Instead 9/10 times i got a big, fat, bold SIGABRT.
Oh, but you have stack traces ... um no. When crap happens in the objective-c runtime, you close your eyes and pray that they will go away, well thats what i do.
Anyways the solution was to ensure that notification was dispatched as quickly as possible, so NSPostNow was a much better fit. My professional($_$) opinion is that unless you have a long running object (ie the app delegate) or a singleton, never use the NSPostWhenIdle.
Conclusion
NSPostNow > NSPostWhenIdle
(9 out of 10 times)
Subscribe to:
Posts (Atom)