You can indeed. It's on the Privacy tab in Safari preferences on the Mac, and the Privacy section of Safari preferences on iOS.

Personally, I've no objection as long as I'm *asked* to opt-in. If I'm not, the default should be opt-out.

John Battelle's main thrust seems to be that Apple shouldn't be blocking advertisers from tracking users. Further, that he angry that Apple opted him out by default, rather than forcing him to opt-in to privacy.

Regardless of your views on the evil of (Apple|Google|whoever) this seems an odd argument. Unless you're an advertiser, of course.

On the employment law, there's nothing concrete I'm aware of. But there are two reasons we want to avoid the issue anyway - one is that we've had some great people before who don't do a lot outside of work, but are excellent here. And there's the cover-one's-arse thing ofc :-)

I should add, mind, that this only relates to having such work as an entry gate. I'm definitely all in favour of candidates with such things on the side and love nothing more than to hear about them.

I'm a bit confused here, so I'll labour the point as you may be right and our candidates may be also confused, which would indeed defeat the purpose. So I'll try explaining it in a similar manner to how to give it to candidates and if you still see it as a complex task then we may need to do some work on our framing.

Bear in mind this is a similar question to the one we give, not the same. But we use a game board for the chosen game to demonstrate the rules, especially given many of our candidates aren't British.

Given the rules of Battleships, implement fireAt(x: Int, y: Int): Boolean so that, when given board x, the method when called alternately by each player will return true if a hit was made and false if a miss was the result.

Hence a game would go along the lines of:

Player 1 - fireAt(3, 3) = false
Player 2 - fireAt(4, 5) = true
Player 1 - fireAt(2, 3) = false

And so on.

So this problem can really be solved with an array check + update. Plus it's nicely extendable - if people nail it immediately, you could work on a win condition for instance. And it really has nothing whatsoever to do with actually playing the game.

Sorry, I obviously didn't state this clearly enough. We're interested in an impl for the method, not a client. We're not interested in a game-playing algorithm. We're aiming for something so simple it can be implemented using an array.

There are two puzzles we actually use, and we chose them via brainstorming and then getting a few people here to try them themselves. We're very definitely not trying to solve something seen before - rather, we aim for a simple game because we can demonstrate the mechanics on a game board during the interview. As mentioned below, we timebox it and try to remove as much pressure as possible. This isn't a Google style logic puzzle, but array manipulation.

As for filtering prior, we tried it. It didn't really work. Firstly, we had the fraud problem (only caught them once, but that was worrying enough). Secondly, there's the ownership problem - many employers aren't happy with their property being used in future interviews. And finally, if you ask for open-source or private projects theirs an entire kettle of fish with regards to discrimination (i.e. does this discriminate against those with family responsibilities etc.).

Add to this that we're a very small team, with no HR support. It's often a better use of our time to spend 30-60m with someone than to spend time bouncing (often worthless) CVs around, liaising over tasks etc.

Sorry, I perhaps didn't state clearly enough. We're interested in an implementation of the method, not a technique for playing the game. At it's simplest, it's an array storage and lookup problem.

I should also note we timebox it to 40m, and we tell them that we don't mind if they sit and think for 35m before writing anything. We give them the option of ignoring us or using us as a pair. And we offer feedback during the process, e.g. if they look stuck or headed off on a tangent. Of course any problem feels an order of magnitude in an interview, so we try to minimise it.

If you're interested in work in London, you've got a reasonable grasp of Java and you love web development drop me a line ( j s h i e l l at yazino com). We're a small company so we can't currently manage people entirely sans experience, but a couple of years + passion may well do the trick and we're happy to train to fill in the gaps.

And we're desperate for good, passionate web developers.

Not a chance, as I hope some of my interviewees read Slashdot :-)

However, similar problems would be something like the game of Battleships - I'd provide a simple interface for the game logic (e.g. fireAt(x: Int, y: Int): Boolean) and ask them to go about solving it. So no worrying on graphics or such niceties, just simple data structure manipulation. And as previously mentioned, most don't even run - we're much more interested in the approach than a working solution.

Whoops, wasn't logged in. Abuse to this username, please.

You're not going to find out whether taboos exist for a good reason without discussing them.

So your customers think salespeople are there only to sell them things they may not need, and your sales people live and die by commission?

Surely there's your problem.

If you're paying for sales, surely whoever makes the sale should make the money. And if you're paying people to sell, who then cannot sell because they have no neutrality, why not rethink your compensation structure?

EVE is a sandbox game that provides an environment and a permissive attitude as to what goes on within the sandbox. If people choose to be ruthless, great. If they choose to co-operate, great. But CCP have long been pretty clear that exploiting the game engine is out of bounds, despite all the Band of Developers history the old Goons like to rant about over the space-campfire.

If someone can play the metagame and infiltrate Goonswarm and disband them, good luck to them! But when CVA was disbanded via an exploit recently, CCP rolled it back.

I'm only a foot-solider, so don't take this as gospel, but my understanding is that the intention was not to exploit by crashing the server. It was acknowledged over TS however that a crash was a real possibility - they had a real large fleet, as did we. But admitting we were pushing the boundaries of the capacity and preparing for it is a very different kettle of fish to actively setting out to attack CCP's infrastructure.

I still don't get your analogy, mind - I lost a group of pixels. It hurt me no more, nor anyone else on either side, than losing a pawn, or an evening of wiping in WoW. The only participant with a potentially broken nose is CCP, as they're the ones who'll suffer if people in 0.0 get bored with pre-emptive blobbing as a tactic and stop paying their monthly subscriptions.

You can only reinforce a node at downtime. Hence, the problem here: no one knew there would be a fight until after downtime had passed.

Because we didn't get lag, we got a failure of the game system. We stared at a black screen for 2 and a half hours. My killmail is dated 30 minutes after I logged off.

Lag is expected in a fleet fight of any size. You expect to be able to see that someone is present though, even if you're not sure if they're shooting you or not.

Whether you like the Goons or not, that's not a fun game to play for either side. Hell, when IT and the Goons agree things are broken and need fixing you know there's either a problem or it's the end times.

Used to be true. Not recently though.

On Snow Leopard: 1.6.0_15
Currently in testing: 1.6.0_17

For my part, I've been using my Mac for enterprise development for about 18 months now. Slow as Apple used to be at providing JVM updates, they still move faster than most enterprise deployments (where tested stability > version number). Not that this is any defence of their previous abyssmal record at JVM updates.