Wedge

I should just add, I'm using Chrome 29 and I got sent a block of XML in a PM. Trouble is, not only was the indentation screwed up, half the line breaks were also missing. It made a real mess out of the file I was sent :(

Note the key point that the author makes, more than once, that some of this stuff is relevant for developers and that alternatives should exist for developers, e.g. in the dev tools area. But not in the main options. Perhaps not in a UI at all, just in the about:settings area, or exposed via a plugin for developers.

Turning off cache... funny you should say that. How many times have we asked people to hard refresh Wedge? Yet there are semi regular CSS changes... answer: we generally don't because we have a system that pushes a different 'filename' to the browser so it won't be cached. As a rule you should assume that a user will have a given thing cached and if that's a problem, rename the thing. One suggestion I've seen was to have files include the date of release in them.

Telling users to turn off cache is generally a really silly thing to do because it's not a per site cache. It's browser-wide meaning that everything everywhere has to be redownloaded. Which for a per-site exception is ridiculous. And the fact that the site owner has control over how they send you things means they're the ones who should be responsible for dealing with it - if you routinely have to tell users to empty their cache, you're doing it wrong. (I'm not even sure why we had to ask users to hard refresh with the smileys, actually... it certainly surprised me that we had to)

As far as turning off SSL/TLS goes, that's a classic example of the point the author is trying to make... who would legitimately turn it off? Anyone who is smart enough to know to turn off SSL or TLS should know how to do so via an about:settings type page. There is no reason I can see for having it as a UI item, especially not a fairly prominent one.

Or the server was hacked into. Or someone brute forced your password. There are many exciting and interesting ways that this stuff can happen.

But yeah, anything that changes without good reason is a sign that something is up.

I don't know how the password changing would work.

For the basic case of forcing a user's password to change is easy enough: flag it as expired and force the user to change password when they next sign in.

The problem is if a user hasn't changed it in a period of time (e.g. a week after it was force-expired), it needs to be changed automatically but there are security issues with that, e.g. if the user's email is outdated, but also emailing a new password out is inherently insecure too. There's not really a truly great way to solve that aspect.

Interesting that youtube-nocookie doesn't work in Chrome, especially as they work fine in Mobile Safari - so it's pretty much a Chrome/Android thing?

The video content for the first two is a collection of interesting random trivia about DW, like the fact that the BBC obtained the trademark to the police box from the Metropolitan police in 2002 even though none of the outer designs ever exactly matched it. Or that the whole chameleon circuit failure was an easy way to avoid having a different huge prop every four episodes (back in the early days)

Camelot! Camelot!

Eh, it's only a model...

Well, yes, it is a silly place...

Here endeth today's Monty Python reference.

Nice summary, Kindred, covers everything that's been going on ;)

Yeah, the whole writable-files thing is an issue and it's been an issue since forever. Part of the reason I guess I'm more hardline about it is because I deliberately spent time making that a non-issue in Wedge; every step in Wedge's plugin chain is about not having files be modified, specifically to ensure permissions never get elevated. But the price, of course, is flexibility, and I've not exactly lost sleep over that decision.

I'm interesting in the concept of a double layer security protocol, essentially forcing admin access to be either IP bound (or at least white listed) and/or two-factor authentication. Unfortunately it's not something we can easily adopt as standard beyond IP whitelisting for the obvious reason that both SMF and Wedge typically get deployed on shared hosts and shared hosts typically are the lowest hanging fruit.

Yes, making a game in Unity.Yes. The company was formed last year. Up until now it's been largely doing SQL database stuff, which I've only been involved in sporadically. The plan was always to break out and do other stuff. Part of this trip was to get into writing with Unity so that we could go make some of the many games we've discussed.A little of both. I've never considered Wedge on its own as viable revenue for a full time job; I just don't believe - as I've said - that the market is big enough to support another paid project to support full time development. There are also questions I've raised as to quality (not that I consider there to be a quality problem, because there isn't, but in the minds of customers there could be because of somewhat misguided views on how things 'should' be)

As I've said elsewhere too, my own plan for plugin monetising, the plan from my perspective ultimately was to have it be able to cover server costs and anything extra would be nice pocket money.I hadn't forgotten your 3D programming experience at all. However... Unity doesn't expose the normal 3D interface. It's heavily abstracted such that you never touch OpenGL or DirectX directly - remember that the same project cross compiles to Windows, OS X, Linux, iOS (with a Unity plugin), Android (with a Unity plugin), and if you have the appropriate licences even for PS3, XBox 360 and Wii. That's how abstracted it is.

For example, here's the core of the stuff I'm doing right now, in terms of procedurally generating meshes - http://docs.unity3d.com/Documentation/ScriptReference/Mesh.html

It really doesn't help that Unity supports 3 separate languages, Boo, JavaScript and C#... JS is run at runtime through a mostly-JIT compiler, while C# is compiled ahead of time which means you have an advantage in terms of speed... and you can intermix the two quite happily provided the order of compilation isn't a problem (i.e. you're not trying to call code that hasn't been compiled yet)

And once you get into Unity itself, there's an awful lot of architecture around which to implement things. Most developers in Unity will never even procedurally generate meshes but simply use models. A surprising number of Unity devs use it for easy cross-platform 2D development, too.

Honestly, it was simply the fact that it's a long way away from the world of 3D programming you've done before and there's a huge learning curve to deal with. As I've said, C# is a largely different world to PHP and especially inside Unity... it's pretty nice in the way it's prompted me to rethink about programming. Honestly, I'd love to be able to architect Wedge plugins the way I can add components to things in Unity but that isn't ever going to happen (each GameObject has one or more components that can all interact with the GameObject, or indeed any object currently in the scene). Then of course you start to realise you can do things like having multiple cameras, and even rendering a camera's view to a texture so you can do things like the huge video displays in a sports game.

In all the stuff I've done with Unity to date, the only reason I'm not using modelling for these objects is because I'm creating mathematically accurate models (the platonic solids) and then plugging in an expansion I have to create vector-like lines around the edges, to represent something in the display in the game. If it were anything else we'd have broken out the modelling tools and imported meshes/textures/rigging/whatever rather than doing it programmatically.