Speaking to various folks at NSConference, I realised that there are quite a few regular developer meetings around the country, in addition to the one that I used to organise in London (which still exists but has mutated into the NSCoder london night).
I figured that it would be handy to list them all in one place, for anyone who might find themselves in a strange town for a while in need of geek-based social contact…
I’ve updated my uk-mac-dev-meeting page accordingly, so that it now lists all of the ones I’ve heard about.
If you know of one I’ve missed, please let me know.
]]>I figured that it would be handy to list them all in one place, for anyone who might find themselves in a strange town for a while in need of geek-based social contact…
I’ve updated my uk-mac-dev-meeting page accordingly, so that it now lists all of the ones I’ve heard about.
If you know of one I’ve missed, please let me know.
]]>Day two started with an illuminating session by Jeff LaMarche about the Objective-C runtime, and some of the nice dynamic and introspective things you can do with it, such as iterating through your own properties, methods, etc. A couple of days ago in Drew’s concurrency workshop I was thinking about the need for some good Objective-C wrappers for OpenCL, as there’s a lot of boiler plate setup code that you have to do. It’s there for flexibility, but probably you do the same thing for most apps, so why not wrap it in some simpler objects. Some wrappers probably already exist somewhere, but it struck me that one of the techniques Jeff was describing would be perfect for supporting OpenCL kernel parameters.
]]>Next up was Andy Finnell, giving a session that was supposed to be about Core Image, but was actually more about OpenCL. Everyone reported that this was an interesting session, but I sort of got distracted because I was starting to hack together the OpenCL wrapper classes that I’d thought of in the previous session (I’ll post them up when I’ve done them). Having said that, if there’d been more actual OpenCL in Andy’s presentation I would probably have been drawn back in to it, but actually he mentioned himself that he’d wrapped the calls in a class hierarchy, and went on to focus on the physics, which whilst interesting wasn’t really of much general use. In the end, from what I heard, it was more about the physics of watercolour pigments and their interaction with paper - which whilst interesting, wasn’t really what I was there for!
Next up were two half-length sessions thrown together at short notice because one of the other speakers had to drop out.
First a quick overview of some source control systems by Dave Dribin. This was a tough job in such a short time, and I felt that it was a bit light on the right details. He spent too long on the purpose and history of version control, and not enough time on a discussion of the idioms that we use in the real world, and how they do or don’t fit into the models provided by Svn, Git, Mercurial or Perforce. Not that the history and purpose isn’t interesting, but in half an hour you can’t really do it justice on its own, so it was probably better to focus on telling people who understand version control and use one every day how the one they use compares to the other major options. I found this frustrating because I use a very large Perforce system at work (it’s pricey, but excellent, and I’m not convinced that the other systems could do what we do with it), and run a Subversion server at home (which is simple, but I want to change to something else, probably git or mercurial). What I really wanted was answers to some fairly complex situations that happen in the real world - like “how well can you manage multiple concurrent release branches”, “how does it cope when you have twelve devs continuously hacking on a branch”, “how well does it deal with large amounts of data - e.g. graphics assets”, and “how does system XYZ recommend managing your own shared library modules that are used by more than one project that you also have under source control?”. None of which were really answered.
This was followed by a very whistle stop tour of code signing from Graham Lee. Although brief, this was actually useful as he told me how to do something that I didn’t know how to do before. He delivered it with his customary humour, and the session was most notable for re-christening Wolf Rentzsch as “The Dog Spanner”.
After another excellent lunch we had our final “proper” session, from Aaron Hillegass, on data persistence. He started with an excellent set up, posing some interesting questions about how relevant the file system is any more, and whether “the file” is actually dead, to be replaced largely by the data cloud. Quite possibly, he suggested, our local machine hard drives are just local caches from here on in. I think this is a great topic which could have been explored further - for example, if files on our local hard drive are just caches, shouldn’t we be trying to find ways to structure them better so that they can be synchronised with the cloud in a non-monolithic way. One big fat 10Mb file is a bit hard to sync unless you’ve got a detailed schema describing the internal structure, and permission to mess with it. Anyway, I think that side could have been explored further, but Aaron switched tack somewhat to talk about the BNRPersistence framework that he’s created. Which was an interesting topic in it’s own right.
Finally, we had the “Cocoa Rumble”, which was a light hearted competition between three teams composed jointly of the session presenters and volunteers from the crowd. I didn’t really feel that it worked that well this year, despite generating some good presentations at the end. Somehow I don’t think we’ve yet managed to find a way to end NSConference which matches the old “Stump The Experts” sessions at WWDC (which were kind of cool back in 1993 when I first went, and still good fun back in about 2002 when I last went!).
So there you have it - two days of great Mac related sessions. I’ve learnt a fair amount, met some nice people along the way, and had a splendid time. I’ve eaten far too much, and drunk lots of bad beer and bad cider. And tomorrow, there’s another whole day of iPhone stuff. Phew…
]]>Day 1 of the conference was excellent, though I spent the second half of it feeling absolutely shattered, having had less sleep over the last week than I would have liked through a combination of illness, early morning starts, and perhaps a tad more beer than was wise. Which is why I’m writing this now in my room, when by rights I should be in the bar.
We started in a refreshingly human manner, with talks by Scotty and then Mike Lee, focussing on the big picture rather than the nitty gritty details. Of course the details are our meat and drink, and we’ll get plenty of them this week, but it’s good to have our eyes dragged off the floor and onto the horizon every now and then.
]]>We started in a refreshingly human manner, with talks by Scotty and then Mike Lee, focussing on the big picture rather than the nitty gritty details. Of course the details are our meat and drink, and we’ll get plenty of them this week, but it’s good to have our eyes dragged off the floor and onto the horizon every now and then.
I particularly liked Mike’s talk, as much for the effect that it had on the room by confounding our expectations. It was emotional, and personal, and reminded us that there’s more to life than programming, but also that the skills that we love to use in our programming can be applied to life.
I think it wrong-footed a few of us introverted programmer types, who were expecting nerdery and got philosophy instead. “What is this emotion of which you speak, human? I have no time for this frippery. Take me to your loader (sic)”…
Perhaps it was also just a bit too heartfelt for us cynical Europeans, who get a bit confused when someone is open and honest with us. There’s usually a little voice in the back of our head wondering if we’re having the piss taken out of us in some way which is so fiendishly subtle that we haven’t worked it out yet. Not so in this case. Anyway, good on you Mike, nice job.
Luckily for those in the room teetering on the edge of an existential crisis, this was session was followed by a full on geek fest from Wolf Rentzsch, who gave us a whistle stop tour of the tools and techniques needed to rummage around on the internals of OS X and applications written for it. Hurrah for insanely micro-focussed detail. Now were back on familiar ground. There were some excellent pointers, particularly tantalising for me since there are any number of really irritating things about XCode that I could probably sort out now given sufficient time. Like why the fuck my Data Formatter plug-in only works when there’s a full moon.
Rentzsch’s talk was followed by a session from Dave Dribin on clean code, which I’ve already blogged about (http://www.elegantchaos.com/node/405), so enough said here.
After which was another good lunch, including another far too nice pudding. May have to hire a people carrier to haul me back to the station at the end of the week…
One thing I definitely think that they’ve got right this year is the amount and length of breaks between the sessions, and the overall pacing, with just two sessions in the afternoon. Today these were a talk by Drew McCormack on data presentation, and a brief overview of Core Animation from Marcus Zarra.
Drew’s talk started with an overview of some existing ways to present data, but was interesting to me mostly as an introduction to a framework he’s been involved in creating for graphing and plotting. This looked like a great resource when you’ve got any set of data that you want to display as something better than a big table of numbers.
Marcus’ talk was tantalising, as I felt I knew a bit more about what Core Animation was than he assumed, and was hoping for a little more in the way of code examples or teccy stuff.
To be fair though, it was late by then, and he probably pitched it perfectly for the level of fatigue we were all experiencing at that point. And I guess if I want the details I can buy his book :)
All in all it was an excellent first day. The speakers and the general conversation was of the highest quality - something that came as no surprise after last year, but which still takes a great deal of effort to sustain.
So many thanks to the organisers one and all. I can’t wait for tomorrow.
]]>Dave Dribin was preaching to at least one of the converted (me), in his “Clean Code” session at NSConference today - but then I have to wrestle with very large bodies of C++ code every day, much of which was written by other people not following any of his guidelines!
Most of the stuff he said was uncontroversial, but it was amusing to see a few people in the audience bristling at one or two of the suggestions that Dave made - you could hear the cogs turning in their brains as they thought “but I do that all the time, and I’m smart, so he must be wrong”.
]]>Most of the stuff he said was uncontroversial, but it was amusing to see a few people in the audience bristling at one or two of the suggestions that Dave made - you could hear the cogs turning in their brains as they thought “but I do that all the time, and I’m smart, so he must be wrong”.
I can’t really offer an opinion on KVO vs Delegates, not having done enough Cocoa work, although I think it’s all a storm in a teacup anyway as he was simply offering a personal order of precedence. Having had to debug very complex systems I can see where he was coming from though. KVO sounds like a lovely way to decouple systems, but it can get scary when just “setting values” can cause a rich ripple of side effects that extends way beyond the object you thought you were playing with.
I do think Dave’s right about singletons - at the end of the day they are globals, but somehow we’ve ended up with design pattern books telling us about them, and people like Scott Meyers telling us how to implement them efficiently, and it’s blinded us to the fact.
The point that some people seemed to be missing was not that they aren’t useful (they can be), or even that they aren’t the right or pragmatic solution to some problems (they can be). It’s just that they often aren’t the best solution, and yet it is dangerously easy to fall into the trap of making them when you don’t need to - I know, I do it all the time, with the best of intentions. And Dave was right - using a singleton you can easily end up with annoying hidden dependencies and inflexibilities which you can avoid if you instead use a pattern where you pass in the services/resources that you need. And it does make life particularly hard if you want to do test driven development and unit test the hell out of everything.
I never felt that Dave’s tone was in any way preachy, but maybe some people wondered why he was telling them stuff that “we already know”. Perhaps it’s also just a very healthy skepticism in the audience towards received wisdom, which is fair enough - I’m all for that. But just because it’s received wisdom, it doesn’t always make it wrong, any more than it makes it right!
In any case I’m not at all convinced that everyone in the room does know all that stuff. There were plenty of indy developers in the room, who are working on there own a fair amount of the time, many of whom are 25 or younger. I’ve also met plenty of developers in my life who’ve been doing coding professionally for years and still haven’t got a clue!
When I was 21 and just out of college I was lucky enough to get a great job working in an university research department, writing educational software in Hypercard (with plenty of lovely XCMDs that I wrote too). It was a brilliant job and a fantastic environment in many ways, with loads of freedom for someone just out of college. At the tender age of 21 though, I was the only full-time developer and with the benefit of hindsight I realise that I missed out on a great deal of stuff that was going on at the time in the wider software engineering world, because there was nobody at work to point me in the right direction. I was totally focussed on what I was trying to make, and not on the process of how it got made. Things are a lot better now than they were in 1992 of course, and it’s a lot easier to stay in touch with the current trends in computer science through the sort of social networking that we now have. But you still occasionally need people to tell you stuff, even stuff that you’re supposed to already know.
There’s definitely no harm in being reminded of some of the basics from time to time, and having some of your assumptions challenged - whether you’ve been doing programming for 1 year or 5 years or 30.
]]>I posted last week about running Doxygen from XCode using a custom build step.
I originally found a nice article on the Apple website here which describes how to do this, but it needed a little bit of tweaking, and wasn’t great, so I’ve improved the process a little bit.
First of all, I moved the bulk of the work into a script file, so that I can reuse it in multiple projects. This seems more sensible than cutting & pasting into every project. DRY principle!
I also decided to use a standard layout, relative to the project file, which meant that I could cut down on the number of variables that needed defining per-project.
]]>I originally found a nice article on the Apple website here which describes how to do this, but it needed a little bit of tweaking, and wasn’t great, so I’ve improved the process a little bit.
First of all, I moved the bulk of the work into a script file, so that I can reuse it in multiple projects. This seems more sensible than cutting & pasting into every project. DRY principle!
I also decided to use a standard layout, relative to the project file, which meant that I could cut down on the number of variables that needed defining per-project.
My custom build step now just has to define a couple of variables and call on to the script.
You can find my version of the script here:
http://guest:guest@source.elegantchaos.com/scripts/xcode/build-doxygen.s...
It could be cleaned up a lot more - it’s basically copied from Apple’s script then hacked a bit - I didn’t write it with public review in mind! One thing I fixed in the script was support for projects that have a space in their name or the name of a containing folder. Bloody unix programmers!
Second, I was annoyed by the output of the script, so I piped it into a file.
Finally, I was also annoyed at having to wait for the script to complete. Rebuilding the documentation each time is useful, but it’s not like you actually want to go and use it immediately.
So, I tweaked the build step to run it in the background.
Now my build step looks like this:
${WORKROOT}/scripts/xcode/build-doxygen.sh > “$TEMPDIR/doxygen.output.log” 2> “$TEMPDIR/doxygen.log” &
$WORKROOT is a variable that points to the root of my development folder - you can just replace it with the path to the build-doxygen.sh script file.
The script file itself relies on one extra variable - $DOXYGEN_ID - which I define in the project settings. It uses this to name the documentation bundle - so you should set it to something appropriate for the product - like com.yourcompany.yourproduct.
If you want to see the output of the script, you can add a second line:
open “$TEMP_DIR/doxygen.output.log”
This will launch Console and open the log file. Console is smart enough to update as the log file gets filled in, so it works even though the script may not have finished running by the time you open the log.
Update: one more thing…
By default XCode runs the build step every time. You can tell it to be a bit smarter by telling it what the input files and output files are for the step; it will then dependency check them.
I set the inputs to:
And the output to:
Now, if you do something that doesn’t change the source code, the documentation shouldn’t rebuild.
]]>For a couple of weeks the Console application on my laptop has been crashing every time I started it up. This was a bit weird, and also very annoying, since I use it from time to time whilst developing, and to check that the system isn’t doing anything particularly heinous.
The stack for the crash log appeared to be in a call to the file system, so I figured that the problem was file related in some way. I tried removing the Console preferences, to no avail.
After a bit of thought, I realised that I could probably use Instruments (part of Apple’s Developer Tools suite) to work it out.
So I launched it, chose the “File Activity” template, and set it up to run Console. This is a great way to see what an application is doing with files.
]]>The stack for the crash log appeared to be in a call to the file system, so I figured that the problem was file related in some way. I tried removing the Console preferences, to no avail.
After a bit of thought, I realised that I could probably use Instruments (part of Apple’s Developer Tools suite) to work it out.
So I launched it, chose the “File Activity” template, and set it up to run Console. This is a great way to see what an application is doing with files.
Lo and behold, the last thing Instruments did was open a file in /var/log/, then repeatedly try to open some file in /.vol/.
Doing a quick ls of /var/log/ revealed a symbolic link to something that I thought that I had removed (some crappy VPN software called SecureClient that I used to rely on but don’t any more as it doesn’t work on 10.6 anyway). Further investigation revealed that the symbolic link pointed to another symbolic link, which pointed… to itself. That would do it!
All in all it took about 5 minutes to find and fix this crash once I realised that using Instruments was more sensible than just sitting around guessing what might be causing Console to crash…
]]>The BBC report for the QPR match last night said “there were plenty of positives for Paul Hart to take from this game”.
I’m not sure what match they were watching, but the only positive that I could think of was that he’ll probably not be in the job long enough to have to worry too much about what’s going wrong.
Not that it is entirely his fault - the situation off the pitch at QPR is a complete joke - but unfortunately one has to say that Hart has had no discernible positive impact since coming in, and in fact we seem to be going backwards.
The progression of the team over this season might be described as follows:
Under Magilton: - first: playing nice football but losing - next: playing amazing football and winning by lots
]]>I’m not sure what match they were watching, but the only positive that I could think of was that he’ll probably not be in the job long enough to have to worry too much about what’s going wrong.
Not that it is entirely his fault - the situation off the pitch at QPR is a complete joke - but unfortunately one has to say that Hart has had no discernible positive impact since coming in, and in fact we seem to be going backwards.
The progression of the team over this season might be described as follows:
Under Magilton: - first: playing nice football but losing - next: playing amazing football and winning by lots - then: playing nice football but often failing to win
Under Hart: - playing unattractive percentage football, and losing badly
Under Magilton we appeared to have the basis of a plan. We were distributing the ball from keeper to fullbacks, to midfield. We were generally solid and well marshalled at the back (until Fitz Hall got fit and returned to the side, at which point everything went tits up). Our holding midfielders did a good job of protecting the back four. Our main downfall was Faurlin’s over-eager passing (he has a bad tendency to hit blind first-time passes), plus a large dose of over-elaboration by our creative players. That was serious, but could have been fixed with some coaching.
Now, the keeper and defenders are back to hoofing the ball up front, and look to be playing to no plan at all. The central midfield seem to have lost their composure, and the creative players are either not getting picked, not getting the ball, or appear to have lost their touch (or possibly the will to live).
Dire stuff.
]]>I was wondering whether to use HeaderDoc or Doxygen for Objective-C project, and after a bit of googling I get the impression that HeaderDoc is on its way out.
I found a nice article on the Apple website here which describes how to get XCode to run Doxygen for you as part of your build, and turn the results into a DocSet which XCode knows about.
It works rather well, and the documentation for my test iPhone project now shows up in XCode along with the standard Apple sets.
]]>I found a nice article on the Apple website here which describes how to get XCode to run Doxygen for you as part of your build, and turn the results into a DocSet which XCode knows about.
It works rather well, and the documentation for my test iPhone project now shows up in XCode along with the standard Apple sets.
One slight issue - I had to edit the script a bit to cope with having a space in the path to your project. It also has rather verbose output - adding —silent to the make command helps a bit, as does altering the doxygen.config to run quietly. Unfortunately the commands in the make file that Doxygen generates still seem to spit out a fair amount of crap even if everything is working.
One other problem - XCode can’t seem to find the documentation for a type when I option-click on it, in the way that it would do for an Apple type. This may just be a question of needing to rebuild my indexes though…
]]>Over the holidays I’ve been messing about with the iPhone SDK, just for the hell of it.
I always prefer to have a project in mind when learning new tools, but I didn’t have much time, so I fairly randomly decided to do a little countdown application - something that tells you how long you’ve got before Christmas (for some reason this topic was on my mind).
The app itself was pretty simple to get going (less than a day), and doing the UI for the preferences has proved to be far more time consuming than the actual functionality! Once again I’ve been reminded how much fun it is to work with Objective-C / Cocoa.
]]>I always prefer to have a project in mind when learning new tools, but I didn’t have much time, so I fairly randomly decided to do a little countdown application - something that tells you how long you’ve got before Christmas (for some reason this topic was on my mind).
The app itself was pretty simple to get going (less than a day), and doing the UI for the preferences has proved to be far more time consuming than the actual functionality! Once again I’ve been reminded how much fun it is to work with Objective-C / Cocoa.
If this had actually been intended as a commercial prospect, I’d have checked the iPhone store first, but luckily I always viewed it as a made-up project for test purposes only. Having said that I thought that I might conceivably post it to the store, just for the hell of it, so I went to have a look at the competition.
I figured that it was a totally unoriginal idea, so there’d probably be a few up there already. I wasn’t prepared, however, for there to be about forty! What’s more, I’d say that over half of them are paid apps (though costing only a dollar in all cases).
This is quite boggling, and it makes one wonder. Does anyone ever pay for these apps? Some of them have reviews, in some cases quite positive reviews, which suggests that they do. There are supposed to be more iPhones out there than Xbox 360s and PS3s put together. That’s quite a big market, but is it really big enough for 40 applications competing for a tiny and almost pointless niche? I’d love to know if anyone has sold more than 100 copies.
I guess the moral of the story is to check the store before you put any serious time into an application. Although, perhaps not. Perhaps the moral is to check the store, rip off the good features of your competition, then do the app anyway because it’s a big, big, market. Or maybe not!
]]>(absolutely quite a bit, actually, say it again)
James at work said yesterday that often he finds, paradoxically, the code that is best documented is also the code that needs documentation the least, since it tends to be well designed and written in the first place.
I know what he meant, and it rang a little bell with me (although whether my code falls into that category is for others to judge :) ).
In lots of the places I’ve worked I’ve tended to be one of the few people who writes documentation, and I often wonder whether anyone else reads it. Is it, perhaps, all a monumental waste of time?
That said (and when I’m not having a bad day), I believe that to worry too much about whether it gets used would be to miss the fundamental point.
]]>James at work said yesterday that often he finds, paradoxically, the code that is best documented is also the code that needs documentation the least, since it tends to be well designed and written in the first place.
I know what he meant, and it rang a little bell with me (although whether my code falls into that category is for others to judge :) ).
In lots of the places I’ve worked I’ve tended to be one of the few people who writes documentation, and I often wonder whether anyone else reads it. Is it, perhaps, all a monumental waste of time?
That said (and when I’m not having a bad day), I believe that to worry too much about whether it gets used would be to miss the fundamental point.
The reasons that I write documentation, in order of importance, are:
If anything, the “why?” is even more important that the “what?”. Spend a bit of thought on that one, and the rest may turn out to be irrelevant.
In any case, having other people use the documentation as a reference comes pretty far down the list of priorities.
Which doesn’t mean that I don’t want people to do that (it would really help, frankly, if more people would RTFM!). It does mean though that I’m not going to lose too much sleep if I feel that I’m the only one reading what I write.
At the end of the day, writing documentation, for me, is an essential part of the process of writing software, especially when working with others. How can you code a system that you can’t describe in words or pictures?
Having other people read it is just a bonus.
]]>The last link I gave for my QPR calendar was a bit wonky.
If you want to subscribe to the calendar with iCal, choose “Subscribe…” from the “Calendar” menu and enter the following URL:
Don’t just follow this link in your browser. Doing that would download the calendar events and import them into your iCal calendar. That’s not as good as subscribing, as you won’t automatically receive any updates.
You can also view it on the web here.
]]>If you want to subscribe to the calendar with iCal, choose “Subscribe…” from the “Calendar” menu and enter the following URL:
Don’t just follow this link in your browser. Doing that would download the calendar events and import them into your iCal calendar. That’s not as good as subscribing, as you won’t automatically receive any updates.
You can also view it on the web here.
]]>I’ve updated my public iCal calendar with next season’s QPR fixtures.
The calendar can be found here: http://bit.ly/RsycM.
No doubt there will be a few changes due to televised games and so on - I’ll try to keep it updated as & when these occur.
]]>The calendar can be found here: http://bit.ly/RsycM.
No doubt there will be a few changes due to televised games and so on - I’ll try to keep it updated as & when these occur.
]]>Last night, with a bit of trepidation, I let my eee 901 hackintosh upgrade itself to MacOS 10.5.7. I’d been putting it off for fear that I might end up with a non-bootable machine (I could have recovered from it, but it would have been a pain).
As luck would have it, it mostly worked ok.
]]>As luck would have it, it mostly worked ok.
After reboot, the main problem that I had was that the monitor settings had reverted to 1024 x 768, causing the top & bottom of the screen to be cut off. Since the Mac menubar is at the top, this was a bit of a snag, but luckily I know the layout of everything pretty well, and I also had the advantage of Spotlight. Hitting Cmd-Space brings up the spotlight search box (in the right place, interestingly, even though the menubar was in the wrong place), and typing the name of an application allows you to launch it.
After a bit of experimenting, I ended up just re-installed the kexts from the EEE-Utilities package put together by Gregory Cohen. This seems to have sorted everything out.
]]>Ah well, eventually I crumbled and renewed my season ticket… so here’s to another year of fun and frolics at QPR.
I can’t help feeling a little underwhelmed at the appointment of Jim Magilton. Not that I have anything against him at all, and Ipswich have played some attractive football in the last few years.
However, he does appear to have been sacked by the Ipswich chairman having only got them to roughly the same league position that we were in when Iain Dowie and Paulo Sousa both, ahem, departed, from QPR. Which makes one wonder what exactly the QPR board are looking for in a manager.
]]>I can’t help feeling a little underwhelmed at the appointment of Jim Magilton. Not that I have anything against him at all, and Ipswich have played some attractive football in the last few years.
However, he does appear to have been sacked by the Ipswich chairman having only got them to roughly the same league position that we were in when Iain Dowie and Paulo Sousa both, ahem, departed, from QPR. Which makes one wonder what exactly the QPR board are looking for in a manager.
My fear is that they are looking for a yes man who will put up with the high levels of interference from the board that the previous three or four managers are alleged to have had. My fear is also that the fact that they met with Magilton four times has more to say about the number of other managers who were also interviewed, and who quite possibly rejected QPR (rather than the other way round). There are a lot of managers unemployed at the moment who have a better pedigree on paper - one wonders how many of them have said “QPR? You’d be mad to even contemplate it.”.
Hope springs eternal, however - so I’m going to do my best to trust the board, get behind the new manager, and behave like a loyal customer fan… and only put a modest bet on him being gone by Christmas.
This open letter to QPR from James Higgs echoes my sentiments about QPR at the moment.
Like him, I’m seriously considering not bothering to renew my season ticket.
]]>Like him, I’m seriously considering not bothering to renew my season ticket.
]]>