Categories
maintenance

Question for RSS readers: replacement for Feedburner?

Hey, guys, I need some help!

Feedburner will be removed from the internet in 20 days time, which means I will no longer have an RSS feed.

Because of the way Google works (they do not allow multiple Google accounts to be simultaneously signed-in on the same computer), it will be physically impossible for me to use the “replacement” service from Google (I believe google thought this out very carefully indeed, and is very well aware of the consequences, but I won’t hit you with the conspiracy theory today :) ).

(and, in case you hadn’t noticed, Google has forcibly removed some of the features from Feedburner in the process, including the single most valuable one – the count of how many people are accessing your site through RSS)

Worst case scenario, I’ll go back to wordpress-managed feed, but someone with a misconfigured feed reader killed wordpress the last time I had that on, so I’m not sure how long it will stay up. I could install a cache server purely to cover the RSS feed, but that’s going to be a bunch of hassle I could do without (and I might well get it wrong, it’s been a while since I’ve configured Squid). I’ve looked at the WordPress Cache plugins, but they all have major incompatibilities / conflicts with other common plugins.

So … if I can’t find a replacement before 28 February 2009, the RSS feed may well magically disappear. Suggestions greatly appreciated!

Categories
bitching iphone Web 0.1 web 2.0

Web 0.1: Apple: please hire some web developers

I can no longer develop iPhone Apps. I am on my eighth attempt to download the 1.75Gb 2.2.1 SDK – without which, XCode refuses to even talk to my iPhone any more, because I allowed the iPhone to upgrade.

EDIT: I have it! I HAVE IT! YES! NO MORE PRAYING TO THE GODS OF ****ING APPLE’S CRAPPY WEB SERVER! (it’s probably a corrupted download)

The problem?

Sheer mind-numbing incompetence by Apple’s web team, it would seem (NB: I may be wrong; I haven’t tried packet-sniffing the HTTP traffic to prove this beyond all doubt, but my experiments with different browsers and different ISP’s strongly indicate it is the case). They’ve (mis)configured the webserver over at developer.apple.com to kill partial downloads of this monstrous file.

If you cannot download the whole thing before Apple automatically logs you out of their website (which they do every half an hour or so if you don’t actively surf the site), then your download is cancelled, server-side. You cannot resume from where you left off (their web server refuses to honour the HTTP command that tells it to resume a partial download).

What did they do wrong?

It’s a session-management problem – you CAN pause and resume a minute or two later. Just not half an hour later.

The other major bugs in the Apple websites (including that force logout!) suggest that some novice web programmer made a half-assed Session-management system that, well, sucks. (am I sounding angry? Hell yes; Apple’s website is behaving like some naive bricks-and-mortar company from 1999, not 2009). Or maybe they picked up a 3rd party one … that sucked. Whatever. It seems the session-manager is overriding Apache’s built-in support for this core element of HTTP, and saying “no”. For no reason other than bad web coding.

In passing, I noticed that they are *still* (allegedly – it’s easy to fake) running the same version of the Apache webserver that they’ve been shipping by default with OS X Server for some years now – a version that is more than 4 years old, 8 versions behind the current “maintenance” release, and 1 major version behind the “mainstream” release. Personally, I wouldn’t run Apache 1.x if you paid me, not with 2.x out there and running a “proper” webserver arch (apache 1.x is not a real webserver, it’s a hack using forks that makes it unnecessarily slow under heavy load).

</rant>

Categories
entrepreneurship games industry startup advice

A game dev studio made of Graduates

Someone emailed me recently to say he’s setting up a new game development studio, and that (for various reasons specific to his situation) the company will consist of around 90% recent university graduates. Without asking for details, I can make a pretty good guess that there’s government funding involved – I’ve previously seen grants aimed at game studios with similar constraints everywhere from the UK to Singapore. Probably this one is tied to a local University (that’s another classic government thing, especially in the EU: grants that have to go to “industry/academia equal partnerships”).

As he says, it’s an “interesting” challenge. Oh, yes. He invited me to blog about it (yes, I know – it’s a way of avoiding paying consultancy fees, but what the heck), so here’s some thoughts. At least this way I can record/archive some of what its like to be a recent Graduate before I get so old that I completely forget where they’re coming from.

(I’m not a recent grad, but I’m not yet old enough to have forgotten being one)

Where do you start?

In the past, I’ve seen people start with the management team. Then move on to the senior staff (hey, he’s got 10% of the company to play with), decide who’s needed, fit them to potential projects, etc. And finally – working with all of those people in place – finding and hiring all the Grads.

But … my first inclination would be to play to the strengths and weaknesses of the majority of your staff. In a brand-new startup with a team that don’t know each other the influence of each individual on the overall success/failure is disproportionately strong. Over time, as things become more settled, influence starts to becom proportional to seniority, experience, and knowledge. But not initially.

i.e. in this case the graduates.

Graduates

In my experience, graduates everywhere (including at least some parts of Asia, although I’ve mostly experienced Koreans not Chinese) are young, naive, eager, foolish, and fearless.

Specific universities mould their grads into having a very different set of characteristics, but assuming you’re picking bright, interested people, then those 5 are always present no matter where they schooled.

Personal Projects

They thrive on being given their own little projects that are their total responsibility. I think this is driven by two things, certainly in tech. Firstly, a fear of becoming the invisible cog in a giant machine that all adults have appeared to be to them, at a time when they’ve only recently found themselves and found their own uniqueness.

Secondly, I think most grads find University is the first time they start to experience personal responsbility, a move away from the family, no longer entirely dependent upon (and sheltered by) their parents. Some people become very independent during uni, others only just dip their toes in the water while there. In most countries, uni straddles the age of majority, and grads find themselves starting to be treated as adults by their society – one of the biggest parts of which is the expectation that they will take personal responsibility.

Clone Wars

I think a lot of people in this situation feel tempted to embark on a clone of a known game. The idea is that this will make up for the lack of experience by obviating the need for decisions on key game design and implementation issues: you don’t have to think, you just just play game X an extra time and “do whatever they did”.

That can work. As a recent example: so far as I can tell, it’s what a lot of the early F2P Chinese developers did – cloned Korean F2P games and just tweaked the “shallow” content (story, plot, theme, geographical location, etc – all the non-programmatic stuff). They’ve all done very well out of this.

However … as soon as market expectations ramp up, cloning becomes extremely difficult. You cannot afford to get “stuck” because you can’t figure out “how” the original game achieved something. With a team of veterans, you have an encyclopaedia of knowledge of techniques in their heads, and usually for each trick the original developer used at least one person on your time already knows that one. Where that doesn’t work, all your veterans each have a bag of tricks and hacks and band-aids that they can use to fudge it; nothing will slow them down for long.

(incidentally, China is probably well into the secand wave of MMO development by now, meaning that new studios there have no chance of doing the “clone + make lots of money” route; the developers that did that are now worth billions of dollars, and they’re already pushing the minimum quality bar up very, very high)

In the end, I think cloning is a bad fit for a bunch of grauates. If you get the timing just right, they’re a very cheap workforce to do it with, and they have too little self-esteem to object (see below). But at any other time, it plays on their weaknesses, and invalidates a lot of their strengths.

What graduates are good at

Grads are great for churning out large amounts of repetitive content. To them, everything still has a newness and freshness that makes even boring tasks interesting (up to a limit). This is partly why they get so “abused” by companies “eating them, chewing them up, and spitting them out”: they’re a cheap but skilled labour force. The mistake a lot of companies make is that grads are also smart enough that they see what’s happening. They’ll eat dirt for a while, having decided that it’s a fair exchange for the work experience and the knowledge they’ll gain both immediately and later.

I think a lot of companies are surprised that despite being more willing to eat dirt than other workers, grads also tend to rebel much sooner. In their minds, it’s a contract, and if the company doesn’t hold up its side of the bargain, they can easily go elsewhere and try again. Older workers have ties (families, fear of finding an equal new job, etc), but grads are both too young and too inexperienced to have picked those up; they can leave easily (or believe they can).

(IIRC South Korea has an interesting take on this: the grads can’t leave, by law, at least in the game development companies. Many of them are avoiding doing their National Service by working at a “critical industry” company instead – if they quit, they’d have to take up their NS place and run around in the freezing cold shooting at each other. Although it only buys the companies 2 years of immunity per grad, I’m sure that has been a huge boon to the SK tech industry)

Grads are also great at innovating, especially in stupid ways. They don’t have wisdom, so they don’t know that stuff won’t work, and will happily do it. Older/maturer grads start to develop suspicions that things might not work, and still charge ahead, but with some doubt; younger ones don’t even realise there’s a possibility of failure.

It’s a bit like an early hand-made gunpowder cannon. It can be a total disaster. And it can rarely be channelled, certainly it can’t be aimed with precision (by definition, the grads ignore the channelling efforts of their managers). But it can be pointed in vaguely the right direction…

Grads also don’t mind having their feel pulled out from under them so much. Upheaval and U-turns by management can give more senior staff cause for fear, especially those that have experienced incompetent management in the past. Where your management is strong, and gifted, and making a difficult decision to U-turn early in response to new realisations / better understanding of the situation, you can end up having to put a lot of work into allaying the fears of panicked workers. (of course, many good management teams underestimate the need for this, blindly expect their staff to trust them implicitly (ha!), and cause an even greater panic, and/or catalyse individuals into becoming the worst of themselves. Then they fire some of their best people, naively thinking they’re getting rid of the worst).

I’m not saying Grads enjoy this, just that they handle it much more easily (although some love it – it’s giving them *even more* of that all-important “real-life work experience” and the coveted “industry knowledge”).

Middle Management

A little story: when I was the CTO at one startup, the majority of our first fifteen or so employees were doing their first or second ever full time job. If I’d had the choice, I wouldn’t have done it that way. Not because of complaints about the people (people are great or terrible largely independent of their level of experience), but because the *collective* lack of experience made the overall team a lot less effective and a lot more fragile than it should have been.

(by the way, this story doesn’t reflect well on me :). I’m sharing it in the spirit of “let’s all try to avoid making mistakes like this in future, shall we?”)

One recurring issue was that the CEO would complain at length of the pointless waste-of-time crap his staff were getting upset about. He’d bemoan that these were tiny issues, that happened all the time, in all companies, and why were we obsessing over them so much? I objected greatly to this attitude w.r.t to our staff, that it was their fault and that they were weak and stupid to get upset – and that their distress was an irrelevance, and to be publically belittled and privately ignored. With hindsight I think that incited me to overreact on plenty of occasions, but … leaving aside the sentimental aspects, he had a good point.

This went on for many months, and at the time I could think of lots of things that could explain why these issues came up – and pointed to ways of solving or avoiding them – but the recurring thought was always: we wouldn’t even see these issues if more of our team had had more real-life working experience. I think we both agreed on that, too. In the darkest hours, he even muttered about considering firing the entire company and hiring an entirely new staff, of similar size, but of “better, more mature” people. If I remember correctly, we’d fallen way short of targets so he was under a lot of stress and just wanted all these organizational problems to “go away” so he could focus on the stuff he loved, the product design and the marketing.

I don’t think that company ever really managed to sort it out, at least not for several more years, just going by the quantity and quality of people that resigned or were “let go” (whether that means redundancies, firings, or whatever) over the years.

I had some vague ideas for solutions at the time – I could see that the problems were catalysed by the attitudes of the most senior people in the company, starting with the CEO, flowing through (and added to by) myself and the rest of the management team, and then down through everyone’s social and professional relationships to encompass the whole company. It was clear that even the best of people couldn’t always refrain from “putting the boot in” when crap flowed to them, making a bigger ball of crap for the next person along. It was subtle and pervasive – no one individual felt that he or she was responsible for what was happening, because their contribution was so small. But that’s the beauty of a team, isn’t it? The whole is more than the sum of the parts… In the end, I decided (amongst other things) that if we couldn’t reform from the very top down, we’d never be able to break out of the vicious cycle. I tried different ways to get the CEO to change, and tried to change myself, and worked hand in hand with some of the other C-level staff that felt similarly about the need for a top-down change, but I just wasn’t good enough to make it all stick. So in the end, I quit, just before the next funding round closed. Wherever the company was going to go with this new money, I no longer felt I could be part of it.

Over the years since, having seen other situations both earlier and later in companies’ and teams’ lifecycles, I’ve come to suspect that the solution might have been less diffcult than I’d thought. That all it needed was one simple thing: Respect. Easy to say, not so easy to visualize and enact, of course. In a company – a startup especially – that means: Complete transparency, Trust, Faith, and (this one was a killer at that particular startup) self-doubt whenever you find yourself disagreeing with your peers.

At that startup, I saw over and over again people with huge amounts of experience – in some cases decades’ worth – being laughed at and ignored by people with none. In the other direction, and no less forgivably, I saw people assume up front that their colleagues were “too stupid” to understand the task at hand and so go out of their way to hide the very existence of it from them. Plus plenty of other activities that ranged between those extremes. At the time, I objected to these things on a general professional level (and sometimes on a personal one); I even managed to fire someone who was a particularly strong offender – but I did it too late, and too slowly. What I didn’t fully appreciate, I think, is quite how *directly* critical it was to the overall wellbeing of the studio itself; I thought it was just one (particularly emotive) aspect amongst many.

And it was lead by the CEO. It got so bad that the management team ended up having two weekly meetings: one official one with all the C-level staff, and another, secret one preceding that one, with the same people – but without the CEO. It was an open secret. All the staff knew about it, except for the CEO, of course. It was a combination of damage limitation on our part, and playing him at his own game (he liked to play us all off against each other, whether deliberately or accidentally, drawing attention away from himself). So, we’d share critical info that we needed but he was refusing to disseminate. We’d prep each other so we could provide a united front on difficult company issues that we knew he’d try and twist into an emotional issue and wriggle out of, or belittle. We’d even occasionally select a fall-guy from among ourselves, someone to put up a strawman argument on new issues, because we’d found it was one of the most effective ways for him to accept suggestions and solutions that weren’t his idea: if he had the opportunity to first demonstrate his own authority by putting someone else down. I still don’t know if anyone ever told him about those meetings, although I’m sure someone must have sooner or later.

Obviously, there’s more, but that’s where this story ends. Any new company of Graduates is (I sincerely hope!) going to have a much more clued-up CEO. But, tempting as it may be to read the story and think it was all the CEO’s fault, it’s dumb to think that one man could control a whole company so completely: there was a collective problem as well. And IMHO it mostly came from the inexperience and insecurities and uncertainties of many of the staff. If so, then the tendency will be there for similar problems to develop, and fester, with any large body of inexperienced staff. The middle management for the new company need to read this story as a parable of an extreme situation they must never get anywhere close to (just to be clear: I’m not singling out non-managers as the problematic ones here – the senior management at that startup included people who were doing their first job too).

They need to not only rise above it (that’s enough to be effective as a company, but not enough to stop the rot setting in, as I think we found out) but also have to step in early and often to prevent bad habits and bad cycles forming. I think we were all too hopeful and happy in our jobs early on to feel enough fear and forsee how much “the little things” were in danger of snowballing; sure, we might have got lucky, it might not have happened – but the risk was big enough, and the outcome severe enough – that we should have snuffed it out right at the start.

That’s going to be a tough job. You have to act a lot more like parents and a lot less like colleagues some of the time. Again, with hindsight, I guess this makes a lot of sense – didn’t I just say at the start that recent Grads are still only half stepped away from their parents, or perhaps even less? Why should it be a surprise that they’re going to need more parent-like support than people in their thirties, forties, and fifties?

And, in contrast to the startup I described, I would hazard that I’ve seen at least one company where the most senior management were more than capable of it, but their middle management were not. It took longer for things to go wrong, it was a gentler slide, but a similar set of problems eventually engulfed them. So it’s going to be doubly hard for the guys running the show: it’s not just “can you do it?” but “can you be sure that the people who are reporting to you are themselves doing it, every day?”.

Projects

Go for the stuff that allows open-ended innovation, and large amounts of creative content. That’s what Grads are great for, in the abscence of anything else.

Make sure – above all – that you have a thriving “internal incubation” system, where everyone – and I mean “everyone” – gets to work on purely explorative internal game designs at least one month per quarter. Perhaps have 50% of your staff at any one time working on non-milestone-driven pre-production experimentation. Kidnap a Google software engineer and bribe them into telling you in detail exactly how the infamous 20% time works (and doesn’t) – don’t rely on the rumours – and work out how you too can afford to sacrifice so much of your time to apparently “pointless” work.

Because until you’ve got your company established, and some of your grads have found their natural places both professionally and within your specific company, you need to do everything you can to keep from killing their spirit and optimism. If you lose that, especially for a new company, you’re screwed. With such inexperienced staff you have very little else to stack the odds of success in your favour. You’ll produce unimaginative, weak games, and the way this industry works, everywhere, your first game is more important to your future than any other single game you do.

Wrap up

That’s enough free consultancy for now. I haven’t said anything about team leaders (lead coder, lead artist, art director, etc), nor about the mix of skills to look for in hiring the Grads themselves. But I think there’s more than enough meat in what I have said to keep you all going, and to give me new things to think about for the next few years.

Categories
agile dev-process programming web 2.0

PHP: Looking for some Best Practices

PHP is weak, crappy, and encourages people to write terrible code. But … if you know what you’re doing, all of those might actually be really really good things.

(by the way, if you haven’t already, you should read Eric Ries thoughts on PHP…)

“Best Practices” are one of the best guides you can get for sailing between the Scylla and Charybdis of “crap code” and “over-engineering”.

So I’d like some, please.

Perfection

Anyone with zero computer science education can write crap code; that’s easy. At the other end of the spectrum we have the people who write Perfect code.

Anyone who writes perfect code is either:

  1. a liar
  2. too rich to work for money
  3. works in an industry that is immune to marketing

…because marketing is always a cheaper and more effective way of making more money, compared to writing “perfect” code.

(disclaimer: in the past, I’ve been the first, and lusted after the third, but never quite managed the second)

The skill that marks out the difference between a competent programmer and a good (or great) one is knowing which of the language’s strengths to play up, and which to play down. Sometimes, the fact that a language allows extremely sloppy code is a very good thing. e.g. most scripting languages – especially any that run on an “intelligent” runtime like the truly Awesome JavaVM – where being grossly inefficient is not only “OK” but in fact “doesn’t happen”, because once it notices what stupid thing you did, the runtime silently recompiles everything into decent C code while you’re not looking.

So … how the heck do you win?

You look for Best Practices, language-specific (and domain-specific, but that’s obviously of more niche value).

I recently did two moderate sized PHP projects. I figured: OK, so PHP is very easy to hack code together knowing very little about the platform (and I’d been using my Perl experience most of the time when writing PHP) – but Perl showed us that Best Practices are damn useful and not too hard to stick to. There must be lots that the PHP community has worked out by now!

(as Quake3 would say, in a bass rumbling voice:) Denied!

Um, no. Apparently not. Google – with *considerable massaging* – threw out a few dozen attempts from different people.

There was some interesting stuff in there. I found some obscure bits of standard and near-standard extensions I hadn’t noticed previously when reading the manuals.

But, to be honest, nearly all of it was a waste of time – it simply wasn’t PHP specific. Telling people that they should “document function headers” is meaningless as a “PHP Best Practice”. It’s not a PHP Best Practice, it’s a general programming practice. You can find it in *any* textbook (and if you don’t know stuff like that, I suggest you go read a few key books like Code Complete, for starters).

There’s also – and this quite upset me – a lot of BAD practice out there being passed on from PHP programmer to PHP programmer and hailed as if it were “a good thing”, when often it’s about as wise and valuable as staring down the barrel of a loaded gun so you can see better while you clean the inside.

What is PHP good for? Why?

I have recently realised that the majority of PHP programmers cannot answer these questions, and that many of the rest aren’t great at answering them either. If you can’t answer them, you can probably never be a great PHP programmer, and it’s debatable exactly how “good” you are. (/me ducks and runs for cover)

I’ve not done enough PHP to know what it does from the inside.

But I’ve done tonnes of code in “languages that are not PHP”, and I have a really really good idea what it does from the outside. And most of the Best Practices I saw for PHP were stolen from other languages (especially C derivatives) and are totally inappropriate for PHP. Because PHP is not C, and PHP programmers will never be decent C programmers, no matter how big their inferiority complex, and no matter how hard they slave to try and write “high quality code”.

Some things PHP is good at: (in no particular order!)

  1. It’s a Scripting Language (like JavaScript, and ActionScript, and Perl. But not like C, and not like C++, and not like Java)
    • It’s intended to be trivial to read and write code; the core language is “easy for a non-programmer to grasp”
    • There’s no feature in the language that requires thinking to understand what’s going on, by design (unfortunately, some of the libraries broke this. c.f. the great Register Globals disaster too)
    • idiots can code effectively…
    • …which means that highly intelligent individuals who were never trained as programmers can ALSO code effectively, with minimal pain and suffering
    • …and that changing (modifying, fixing, extending) other people’s PHP code is trivially easy
    • There’s no compiler. No cached builds. What you see is what you executed, literally.
  2. It’s very easy to grasp two of the three most important structures of a web application (the third one is “data flow” – PHP sucks at that one). The two it does great are “program logic” and “program inputs + outputs”; together these sum to “execution structure”
    • One page == one source file : you read an output (FORM or A link) to an HREF? Or a page is crashing in the browser? You know exactly which file to find it in
    • One source file == one page : all the logic (PHP tags) and the input/output parts of the user-interface (HTML tags) are in one file. So you can’t make assumptions and the resulting mistakes
  3. It’s a context-free language. This is a by-product of being so tightly integrated with HTTP/HTML. It is one of the things that “real” programmers sneer at PHP for – how can you have a context-free language that isn’t Functional and expect it to be any good? That’s some kind of mutant offspring of Fn and Imp that ought to be strangled at birth. Or … maybe … just maybe … it’s one of PHP’s greatest strengths (although admittedly it is a mutant offspring too)
    • When a single source file is executing *there cannot be any other context* (except for the Session, sadly – but this is a strange piece of context-that-is-not-context because of all the rules about what can and cannot be in a session)
    • Oh, OK: there cannot be any context from other threads, other users, other simultaneously executing code. This is one of the hardest, nastiest parts of all systems languages, the multi-threading stuff. And PHP completely wipes it out as a problem. Nice.
    • All source files – hence all user-interaction points – are (semi-)atomic by definition: either they execute, or they don’t (by default, if they start, they dont stop, not even if a crash-level event happens; more on that later)
  4. Code is mingled with presentation, but is “together but apart” because it’s guarded (in the computer science meaning of that word, sort-of) by enclosing magic PHP tags
    • You can copy/paste move around code without the risk of it becoming part of the presentation code (this problem happens A LOT (and causes some awful security holes and application crashes) in some languages, especially in templating languages, even though it seems like such a simple thing. I kid you not.)
    • Any decent IDE (/wave at Eclipse (download PDT to add PHP to it)) can do a lot better at second-guessing what the programmer wants to type next, thanks to the explicit context of being either “in code” or “in presentation”. Saves a lot of time, in very small pieces many times a day.
  5. It’s a mainstream scripting language: very very fast to write code, code is very very fast to read + understand (it CANNOT DO complex things like STL or Operator Overloading), and you can “make it up as you go along” when writing a program – it doesn’t expect you to plan ANYTHING in advance
    • No declarations : you don’t have to plan your variables in advance
    • No declarations = faster “flow of mental programming” : you can aribtrarily change your mind “mid sentence” when writing code, and not have to move backwards in the source file to fix a declaration as a result
    • No memory management : you don’t have to plan the LIFECYCLES of your variables in advance
  6. Writing basic imperative code. Fast. (Imperative == “not Functional”; if you don’t know what that means, look it up – Fn programming is awesome)
  7. Templates for pages.
    • If you’re going to use a template method (or, god forbid, “library”) in PHP, make sure that its source code looks *exactly like PHP*. Because PHP is an excellent templating language.
    • This begs the question of “why aren’t you just using PHP in the first place, fool?”. The answer to which is usually “I didn’t read Adam’s Best Practices on this website and wrote long waffling PHP source that no-one could understand”, or “I have some truly stupid accomplices who will overwrite the PHP tags whenever they see them, just for fun” (anyone using DreamWeaver has almost certainly done this at some point, without even realising it; in that case, it’s not the human’s fault, it’s the fault of their editing software – DW – but the PHP programmer can’t really tell the difference, it’s the same net effect)

Some things PHP is bad at: (in no particular order!)

  1. NOTE: just because PHP is “bad” at something does not imply that this is a bad thing about PHP!
  2. OOP. PHP is poor at OOP. It’s not as bad as Objective C (which is terrible) nor Perl (which is horrifically awful at OOP), but it’s not part of the core language, and it shows.
    • Actually, I don’t even know what to say here. Go on a long rant about how it should look like C++? Hmm. Not really helpful. I’ll just leave it at that. If you *really* need to ask why PHP’s OOP is bad, it’s going to take more than a couple of bullet points to explain it to you.
  3. It’s an “old fashioned” scripting language; it lacks some so-called modern features (many of them are older than the microchip but took a few decades to make it into mainstream programming)
    • Closures? Where are my closures? : without this, it’s much harder to write self-adapting code, and much harder to write code “for other programmers to extend and alter without needing to change my source code”
    • No OOP scripting : without this, OOP is a pain in the ass, taking a lot more typing, and standing out like a sore thumb inside any PHP file
    • No modern Array derefence syntax : (you have to do: “${arr[‘var’]}” instead of: “$arr.var”) this makes getting data out of arrays so hard that people go out of their way not to use arrays in PHP.
  4. Data flow (the third prong of three mentioned in the Good bits section)
    • SQL in PHP is not fun : it’s all manual SQL statements, with practically zero language-level support (check out Perl::DBI for an example of how funktastic language support for SQL can get; I didn’t say “good”, I said “funktastic”. There’s a difference)
  5. Distribution
    • There isn’t any. PEAR doesn’t count – and if it did, well … PEAR has one of the most appalling distribution systems I’ve seen in about 10 years. The fact that I had to hack PEAR’s installer – in 2008 – just to “not crash” let alone to get it to “start installing” says it all, really.
    • No package management. No bundling. No metadata. No repository (PEAR or CPAN? take your pick. I find both fine as manual systems, and frequent failures as automated systems).
    • (if you still don’t believe me, find yourself a Debian sysadmin and ask them to show you Aptitude, a worn-out decade-old text-based front-end to apt. And marvel at how fantastic it is despite all that!)
  6. Register Globals fiasco : the maintainers killed some core features of the language in an attempt to fix a security hole, instead of just fixing the security hole
    • Sadly, the core libraries now force you to use Arrays for evertying, because the language maintainers panicked over Register Globals and destroyed the whole input-sampling system.
    • …which is bad because of the lack of Array-de-ref syntax in the language (see above)

A quick retrospective

If you’re a PHP programmer, I hope you’ve already noticed the implications of some of the good/bad points I hilighted.

There are things that a lot of the PHP community loves with a lack of reasoning that sometimes borders on obsession/fetishism, but which – from the above analysis – are inappropriate for PHP. I’ve tried some of these, and confirmed: whoever thought this was a good idea was either smoking crack or didn’t understand how to build web applications.

Some quick examples:

  • Page Caching. You gotta be kidding me. There’s are plenty of reasons that all other languages push this OUT of the language, and OUT of the application, and most of them apply equally to PHP. Use Memcached instead, and learn to use it properly – that is, externally, not internally.
  • Separating Code from Data. As a gross generalization, if you do this, you should stop writing PHP, because you just threw away most of the benefits of PHP, and you’d be better off writing J2EE from this point on – you’d get the benefits of J2EE and of the Java language AND of the Java standard libs (which kick the living daylights out of PHP’s weak set of “Extensions”) – and you’d hardly lose anything in the transfer.
  • M/V/C architectures. If you do it the way we do it in other languages, then it’s equally stupid as the above point. It *can* be done, conceptually, in ways that fit with PHP – but the majority of PHP systems I’ve poked inside didn’t get that clever, they just tried to do it the traditional ways.

By The Way: I’m probably wrong on some of this. I haven’t spent much time thinking about it. Unfortunately, I’m not sure at this point which points are where I’m Totally Right, Dude, and which ones are where I’m Smoking Something Funky.

Sorry.

Too many words! Argh

I keep being told off (nicely) for writing blog posts that are too long.

In petty revenge, after making you read through the rant-tastic introductory bits (I have my Asbestos suit at the ready…), I’m splitting the rest into a separate post. I almost feel bad about doing this. Almost.

So, on to … PART 2: Best Practice for PHP Programming!

Categories
bitching iphone

Apple & a study in frustration

Half way through the insane 1.75 gigabyte download of iPhone SDK 2.2.1 (which, lets be honest, has precisely 200 megabytes of content, and 1,500 megabytes of STUFF I ALREADY HAVE; Apple’s engineers apparently have never heard of the 30-year-old concept of a “patch file”), Apple refuses the download.

I “no longer have read permssions to that URL” according to Safari. This is despite being logged-in to Apple’s developer.apple.com website. The same website that FORCE logs out everyone *at least* once an hour (because Apple’s web developer team have miserable lives, and want to share their pain with everyone else).

The same website that has given me “error: this page requires you to be logged in”-type errors trying to load … the login page (I’m not kidding, it’s 100% reproducible in Safari and in Firefox, quite easy to trigger. Seriously weak web-server code going on there).

So, let’s start that 1.75Gb download *again*. Apple: I detest you. Especially because you know the problems you cause, and build it into your marketing campaigns; it’s not cool, it’s not funny, it’s pathetic. Why can’t you employ some competent web developers? Why, when you like to call yourselves paragons of UI design, do you make the iPhone App Store have a GUI that would look “weak”, “poor”, “stupid” and “ugly” in 1999, let alone 2009? What happened?

Sigh.

Categories
amusing computer games design games design

Tabula Rasa: A Plot Summary

Ironically enough, from the LotRO forums:

“You know the only analogue I can come up for this is to imagine a WWII FPS where the opening cinematic tells you that the Nazis have destroyed Great Britain with a giant laser and you’re one of the few English to escape via a magic portal to Russia at Stone Henge which was planted by ancient mystics from China. However the rest of the game takes place in relatively normal WWII FPS style while the Nazis throw paltry attacks into the steppes, and yet most of the people you meet are also British and no one seems to care that Jolly Ol’ England is smouldering black glass. Occasionally you stumble across more ancient Stone Henges to learn Mandarin to gain super powers. The Nazi country-destorying laser is never brought up.”

ROFLMAO. And … excellent plot-summary there.

(remembering that I did actually *like* TR. But the OP has a point)

Categories
games industry

I need your vote (for IGDA elections. Starting now.)

(IGDA == International Game Developers Association)

I’m standing for the IGDA Elections. Right now. If you’re a member, you should have received a vote-by-email slip today. Please vote – you don’t even have to login, it takes just a few seconds.

I want to be elected to the IGDA board because I want to make the organization less reactive and more proactive. Today, we under-sell/under-use the good we do. We can make it more effective, and at the same time make it reach more people.

Categories
amusing bitching games industry recruiting

Open Letter to Recruitment Agencies (video games industry)

Hi!

My name is “Adam” (first name) “Martin” (surname); you might need to check the spelling. You might want to check which is the first name, which the surname – funny how many recruiters get it wrong!

You’ve probably cold-emailed me because you got my email address somewhere – maybe as much as 10 years ago – and yet, bizarrely, I haven’t been coming to you looking for jobs. You’re probably really hoping I’ll write back with a CV/Resume that you can send out.

Instead, I suggest you save us both some time: have a look at my LinkedIn profile, and see what I’ve done – http://www.linkedin.com/in/adammartin – it’s shorter and clearer than a CV/Resume, too.

Hey, if you’ve got a few minutes, why not have a look right now? Take your time – I’ll wait! You can learn a bit about me, find out what I might be interested in (hint: it’s there, in several paragraphs of text, right at the top of the page).

Now, maybe you think you’ve got a perfect job for me. But hold on, my friend! Don’t hit that “Send” button yet! There’s some things you should know before you email me a second time…

You see, each time you email me, blind, cold-calling, un-solicited … it’s not just you. All your competitors are doing it. Even some of your colleagues (it’s funny how many agencies accidentally compete with themselves). And a whole bunch of your clients, the companies you recruit for, are doing it too. And each one of those emails takes me time to read.

My time is precious, I’ve got a lot to give, and I usually go well beyond what’s asked; if it weren’t, there’d be fewer companies that wanted to hire me, and willing to pay the salaries I’ve been paid. And hence willing to give YOU that big, fat, commission you’re hoping for…

“What’s there to lose?”, you may be thinking to yourself, “if you don’t like it, we’re cool, I’m friendly, we’ve got a bit of a relationship going here – I emailed you, you emailed me, it could be the start of a great partnership, propelling your future career gradually up the corporate ladder!”

Well, here’s the thing: I’m a technology guy. I have a degree in Computer Science from one of the world’s top Universities. I’ve been trained and employed as a SysAdmin. I’ve been an entrepreneur, and built my company’s computers myself, to save money. Although I don’t program for money any more, I’m still fluent in many programming languages. And, you know what, I’m a bit of an expert at all that “mailserver stuff”.

So … if you piss me off; if you waste my time with meaningless, unsolicited drivel; if you nag me with “this is an amazing opportunity you will love” when we both know it isn’t vaguely true … I’m going to nuke your ass (figuratively speaking): I will never see an email from you again, they’ll die before they reach me.

And when I say “you”, I don’t just mean “you, at the company you currently work for”. Nope. You really piss me off, and I won’t be seeing an email from you no matter which agency you move on to. I hope you grok the seriousness of that? (this may suprise you, but those of us in the industry DO actually notice when you guys change roles, change agencies, etc)

I simply do not have time for time-wasting muppets who are too damn lazy to bother even doing a simple LinkedIn/Google/Gamasutra/etc search on their “targets” to find out who and what these people are.

Oh, and by the way – I’ve done recruitment, many times, myself. I’ve had to get creative with reaching people, trying to tempt them out of their jobs and into working for my own employers. So I know how hard the hard stuff can be. But I also know how little – how VERY little – time it takes to do the easy stuff. And when you DON’T do even that, it tells me a lot about you. It tells me a lot about the crap you’re sending to your clients. It tells me a lot about how (un)impressed they’re going to be with the drivel you send them. Above all, it tells me that if I *do*, somehow, find the role interesting, then it’s worth my time using my own contacts to get a direct invitation from the company, and bilking you out of your commission.

Actually, I could bilk you anyway, whoever it is. The industry is *that* incestuous that everyone above Junior level “knows someone” (who knows someone, who knows someone else … until you hit the Hiring Manager). So, your whole business is based on the assumption that you make it so much easier for me to work with you that I don’t bother to test my extended network. You’re living on borrowed time from the moment your email hits my inbox. Humour me.

But on the other hand, if you take a genuine interest, and make the effort to find stuff that would actually interest me, you could save me a lot of time and hassle. And then I’d love to work with you on finding and evaluating roles. And (modulo all the above) I’m a pretty forgiving guy, if you give me just a little bit of mutual respect. So you CAN send me random crap that you think might tickle my interest, and I won’t hate you for screwing up. You can even get it wrong every time – so long as it’s clear you are, in fact, *trying*.

So, you know … take the time. It’s for your own good. Really.

HAVE A NICE DAY!

Categories
Uncategorized

iPhone OS updated; developers let down by Apple (a little)

What’s in it?

Nobody knows – Apple didn’t bother with release notes for this 1.75GB monster. Allegedly, there aren’t even release notes inside the download itself.

What apps will it break?

Nobody knows – Apple didn’t allow developers to test it before they put it live.

What does Apple have to say about it?

I don’t know – the official developer site has zero coverage other than the download link itself and a short note to say it is “mandatory” and that it might break your phone if wrongly installed.

More to come once I’ve got it working…

Categories
alternate reality games computer games entrepreneurship

The Secret of Viral Marketing

The secret of Viral Marketing (VM) is that it’s all about popularity. Which is to say … sooner or later, it’s all about sex.

When we made Perplex City, the Alternate Reality Game, I learnt a lot of basics about VM just from going out there and trying so much new stuff on a week-to-week basis. It was a small startup, so (at least at first) everyone got involved in everything, and you got to see the things that crashed and burned in as much detail as the ones that shone like gold (this was before the company grew enough that people started covering-up the failures).

Categories
conferences games industry GDC 2008 GDC 2009

GDC2009 Session Confirmed: Sell Social Networking to your Publisher

My GDC 2009 talk is up on the site – How to sell social-networking pitches/concepts to your Boss … and to your Publisher.

Now that the submission / selection process for GDC 09 is coming to an end, here’s a few thoughts on the new process (CMP / Think Services substantially reformed the conference-submission process this year):
(if you haven’t been following, I periodically write something about ways we can improve the games industry conferences)

  1. About this time of year I would normally be thinking “I really need to start on the details of my talk now. Given how busy I am, I’ll need 3 weeks to practice it, and do one final re-write before the conf”. Instead? I’m thinking: “my talk is already written. I have nothing left to do!”. Cool! It’s great to have one less big thing to do…
  2. …except, of course, there is something left to do: I need to add all the graphics and do a run through to make sure it all makes sense and flows. I hope the new process hasn’t lulled me into a false sense of security.
  3. …AND: usually when I get to a conference, I only got the final polish on the presentation 1-3 weeks earlier (depends how busy I was; sometimes I get fed up with it the night before, and I do some big changes a mere 3 hours before the talk. Especially true if I’m jetlagged and I wake up on the morning of the talk at 4 am anyway) – so it’s all fresh in my mind; I know this is common for a lot of speakers (we’re all busy people, and we don’t get paid for this, so have to fit it in around our day jobs). I have a semi-photographic memory, so I can usually give a talk even if I lost all the slides. This gets offset by the jetlag from flying 6,000 miles to California, and the inevitable hangovers from the GDC parties. In the end it all works out as “OK”; I wonder if it’ll be harder this year? (I wrote the whole talk 6 months before the conference!)
  4. CMP’s organization didn’t quite work this year – they missed their own deadlines for reviewing talks and getting back to speakers by 1-2 months. I’ve asked around among friends who are speaking too, from really niche talks to keynoters, and although there is some variation by “importance” of talk (the bigger name, the sooner you heard back, *mostly*), everyone got their responses much later than we were told we would. Shrug. We’re used to this :) – and this is a new way of handling the organization, so I’m sure there were lots of teething problems and unexpected holdups. We’ll just have to see if it goes closer-to-schedule next year, when they’ve debugged it a bit.
  5. The accidents that lead to CMP exposing on their website the earliest talks as they were confirmed made for a really interesting lead-up (for other speakers, who could briefly see what was appearing). I’ve already had 3 or 4 mass emails from CMP this year “announcing” batches of new talks that were “just confirmed”. This is standard marketing practice (and they do it each year). But it’s so 1990.
    • Howabout an RSS feed that shows each *individual* talk the moment it goes on the system? That would be awesome and … here’s a headsup to CMP: I would actually bother to read it!
    • These mass-emails of hilighted talks bore the tits off me: with 300+ talks, and one of your marketing dept picking 5-10 they “think” we’d all be interested in, for me as an individual, they get it wrong nearly every time … with all 10 of their picks. It’s statistically practically guaranteed! Theirs is a hopeless task, one I don’t envy. Give us an RSS feed! :)
    • BONUS: if you RSS feed it, you’ll *allow* the chance of news outlets picking up on each and every interesting talk as and when it’s announced. IMHO, you’d actually get overall more exposure. Since you wouldn’t need to “pick and choose”, you’d also be more likely to big-up the interesting talks by accident, since at the moment you just kill the news on them, instead of supporting it.

Also, this year I will once again be mobilizing every industry-insider I can to blog their own detailed writeups of every session they go to, via the Games Industry Conglomerate RSS Feed Of Awesomeness (feed will be updated nearer the time).

(FYI: we’re fed up of non-professionals reviewing conference talks, and either reporting what they’re told without realising when a developer is bullshitting them, or adding their own interesting but often uninformed opinions. We do love them for reporting it, and doing their best – but if you’ve never developed or published a game, there’s *so much* you can’t help but fail to appreciate about what you’re listening to. Sorry. This is not a marketing conference, its a development conference; we need developers reporting it (in addition to the journalists).

For a long period recently they didn’t even bother writing up transcripts of the sessions – so all the world was left with was a summary through the mind of someone who didn’t know what they were looking at. For some talks that’s fine, but at the world’s biggest game-conference for Professionals, with tons of detailed talks and subtle acts of brilliance, it’s just Not Enough.

No more! We transcript, and we comment, and some of us even like to bitch (and praise) quite openly about what’s being put out by the speaker.)

Categories
Uncategorized

Thunderbird Beta (Firefox-related email client) finally available

If you’re still muddling along with Outlook, or suffering under the curse of some hopeless rubbish like Apple’s OS X Mail, salvation may well be on the horizon… ThunderBird version 3 is now in beta (and looks like it will be the first version of TB that will be usable as a general email client; IME the previous releases never really worked properly). Try it out!

Categories
computer games design dev-process games design games industry massively multiplayer

We need to talk about Tabula Rasa; when will we talk about Tabula Rasa?

In the online games industry, if we keep quiet about the causes, the hopes, the fears, the successes, and the failures of the best part of $100million burnt on a single project, then what hope is there for us to avoid making the same mistakes again?

Categories
computer games education games industry massively multiplayer

Online Games cause Students to drop out of US Universities. Maybe.

In the best tradition of ignoring 100 years of the Scientific Method and the concept of a Control Group, the FCC Commissioner has been talking about American students dropping out because of computer games, MMOs especially.

Categories
dev-process entrepreneurship games design games industry startup advice

Ptiching to Game Publishers – some thoughts

Thomas and Diane have posted a short guide to Pitching to Game Publishers over at the blog for their game consultancy. Apart from giving them some link love (they’re not even on Technorati yet), it’s an excuse for me to tack-on some quick thoughts of my own.

(NB: my experience on the publisher side is pretty short, just a year spent working with Thomas and Diane as one of the people doing due-diligence for them on the incoming pitches, and doing milestone-reviews on the signed projects that were in-development.)

Categories
community games design massively multiplayer mmo signup processes web 2.0

Customer Relationships and Support for Online Games and MMOs

Here’s a question about increasing the profitability and decreasing the development cost of any MMO, although probably no-one except the web-people will recognise it as such (and even some of them won’t get it):

How do you improve the customer support for an existing MMO?
[where do you start, and what do you target?]

Categories
programming server admin

How to install PEAR on OS X 10.5

The simple guide I found here doesn’t actually work, although it “mostly” works. Several bits are out of date. Even then it only *partly* works, because it leaves all PEAR commands as requiring root to run. That may be what you want, but I doubt it. Not what I wanted.

Categories
server admin

Small Fixes for phpMyFAQ

phpMyFAQ is a nice idea, and mostly it’s well done, but with a few basic mistakes in how it’s been implemented that were so annoying I couldn’t live with them. There’s no Debian package for this app, sadly, so things like “using a better version of TinyMCE” require you to manually fix them all (no package-management based solution here, unless you want to maintain it yourself?).

Categories
dev-process iphone programming

iPhone Development FAQ

In my joyous travels developing a fun little iPhone game recently, I kept track of all the many tips and tricks and gotchas I came across. There are a fair few bugs in Apple’s IDE (including at least one critical one that bit me), some stunningly bad flaws in the Objective-C language (it’s *horrible*), and some slightly surprising lack of docs from Apple in key areas (like: how/when do I get paid?)

There was too much to blog it all, so instead I installed a free FAQ software and I’m gradually transferring my notes over to this FAQ (only got a few questions in there at the moment, just fresh installed):

http://iphonefaq.t-machine.org/index.php?action=show

(the one you probably want to start with is: How to make applications for the iPhone?)

There’s an awesome feature to this FAQ too (not that I’ve tested it): anyone can go to the site and click “Ask a Question” and it gets added to a list for admins to answer and post. You can even answer your own question at the same time as asking it.

If you’ve been developing iPhone apps yourself and have some burning questions or neat tips of your own, feel free to go to the FAQ and add them in. Any problems, email me (email address is on the About link at the top of this page)

Categories
alternate reality games conferences games design

Dan Hon rips into ARGs

Dan’s put up the slides from his talk at the Let’s Change the Game Conference – but more importantly he’s done a long writeup with the slides embedded in the text, so you can get the flavour of the talk he gave even though you missed it.

He set out to be mean and nasty and ranty, but I think Dan is far too nice and friendly a person with too little viciousness in him to be like that in person. IMHO, on the day he was much more genteel, and so in some ways I think the written version of the talk is even better than the talk itself.

Anyway, well worth reading if you have any interest in making better ARGs. Don’t expect to get any concrete advice, this is a talk aimed at prodding you to re-think objectively just how often you give in to temptation and use weak devices and shortcuts that if you saw someone else doing you’d berate them for. Although it may not seem like it, I think Dan’s talk is an excellent intro for beginners to ARGs, since it will likely warn you off the big temptations that experienced ARG makers avoid or use with care, but newbies these days may find it easy to go overboard on. Don’t take it too literally, if you know all about ARGs already.