For the sake of over charging me £0.25, this year alone Orange have now just lost at least a guaranteed £150 (£15*10 months) from me (pay as you go) and £350 (£35*10 months) from my fiancée (contract).
What's more is that I'm now making around 50% savings and my other half 67% savings for the same service elsewhere* - that's better than I could have hoped! They'll also be losing out from extended family members switching long term.
"The future's bright" - it certainly is.
* Footnote: I chose to go with 3 Telecommuications because of free Skype and Windows Messenger calls.
Three like Orange are also owned by Hutchison-Whampoa but I don't have a "beef" with the parent company just Orange's poor marketing and customer service.
Update 8/11/09:
Well my parents are now on 3 and Asda, another loss of of about £240/year, excellent.
Total loss to Orange: £840/year
Saturday, March 07, 2009
Monday, March 02, 2009
The Fruit Machine Vampire Castle Ramp Up
Last weekend I spent Sunday rewriting the The Fruit Machine - Vampire Castle "event model", to put this simply, the existing system couldn't handle the combinations of clicks and options available on the fruit machine without some major code ugliness and risk of bugs.
The code is now in a state to progress it further feature wise. I particularly want to make it easier (not easy - because it isn't) for other developers to develop similar fruit machines using a shared fruit machine framework.
Two key parts of the framework are:
- An abstract fruit machine component "model" (a fruit machine consists of boards, which consists types of components such as buttons, lights etc), these have common features and functions that are exposed by the API
- A "pull" event framework. Instead of a central monolithic piece of code making decisions based on lot of variables (e.g. has start been pressed, are we spinning a reel, are we on the top board etc) and having button clicks setting off this behaviour ("pushing the data") there are now individual pieces of code "event handlers" to do the work. The event handlers are told to work out whether they individually in turn need to do anything and can ask the abstract fruit machine ("pulling the data") to return the states of components to find out whether anything should be done.
I'm thinking of GPL for the licence, however I may make additional modifications to the licence to ensure Silent Software remains as an acknowledgement on any splash screens.
The code is now in a state to progress it further feature wise. I particularly want to make it easier (not easy - because it isn't) for other developers to develop similar fruit machines using a shared fruit machine framework.
Two key parts of the framework are:
- An abstract fruit machine component "model" (a fruit machine consists of boards, which consists types of components such as buttons, lights etc), these have common features and functions that are exposed by the API
- A "pull" event framework. Instead of a central monolithic piece of code making decisions based on lot of variables (e.g. has start been pressed, are we spinning a reel, are we on the top board etc) and having button clicks setting off this behaviour ("pushing the data") there are now individual pieces of code "event handlers" to do the work. The event handlers are told to work out whether they individually in turn need to do anything and can ask the abstract fruit machine ("pulling the data") to return the states of components to find out whether anything should be done.
I'm thinking of GPL for the licence, however I may make additional modifications to the licence to ensure Silent Software remains as an acknowledgement on any splash screens.
Subscribe to:
Posts (Atom)