You're missing the point of the article/announcement completely. The point there is that the session is still associated with the browser when the user visits another page. So that page, even though it's on a different server, can make the browser retrieve, say, all your emails from your gmail account, and then send them wherever it wants.
Sorry, I was writing this in a rush. I meant site A executes the code that was injected, retrieves the resulting data from site A, and then sends that data over to site B (or some other location). Typically this "data" is stuff like login information...
I think the very subtle difference is that this time the calls are made using site A's public Ajax API, using site A's authentication token, but are made from a script sitting on site B. The javascript calls return with data from site A, which can then be handled by site B. XSS/JS Injection is more about injecting alien javascript onto site A to make site A call site B with the info it wants.
A "database pro" would look for unoptimized queries and missing indexes and speed up the database on the current hardware. As a matter of fact, most "database pros" work in environments where commissioning new hardware takes 6 months or so and goes through some ridiculous approval processes, so that's actually the hard option.
That doesn't actually seem like a step in the right direction. Reading "dumb" voltages is a million miles away from reading thoughts - no breakthrough at all. In fact, they've been doing this for decades through EEGs - plugging it into a computer interface doesn't make it a breakthrough. It's a very clumsy and slow way of designing a brain interface.
I'm much more interested in the invasive procedures which actually read body movement intentions - those are much more versatile than just reading "whether the user is concentrating"...
Won't lag time be a major issue for a co-hosted radio show? I would imagine much of the dynamics of a co-hosted show, and what makes it so much more interesting, come from the immediate, zero-delay interactions between the two hosts. A large part of their ability to interact so quickly is, I would imagine, driven by the "high bandwidth" of communication between them - ie textual (5%), tonal (45%), AND body-language (50%) content... From the sound of it you've done something similar already - wasn't that an issue?
Absolutely. Get your ass off your chair, walk over to the users, and talk to them about what they need. Then write yourself a detailed spec if you feel you need it. Then turn that spec into some paper-based mockups and walk the users through it. Then make any corrections needed. Then write the software.
And count your lucky stars that your company is incapable of writing proper specs - if they were, they would have outsourced your job to India or Brazil a long time ago.
No, the bird flu aspect is the least important. Flocks of RC pigeons can do all sort of nasty stuff - most obvious (which I actually had in my story submission but which the/. eds removed) being to take down a plane or attack groups of people with lots of small explosive charges.
a) it's not a problem, it's a solution (to reduce the risk of releasing a product no one wants to buy)
b) hardware is affected as well. Most major electronics companies, for instance, come up with an "early adopters" product that isn't quite there yet which they manufacture in smaller numbers and don't advertise as much. They then get the customer feedback on that and use it to ensure the next version is much more customer-friendly.
Who was it who said "Release Early and Often"? Oh yes, Eric S Raymond, in the seminal The Cathedral and the Bazaar.
Not to mention the plethora of literature about product development in other, non-software environments. All major product companies nowadays release products as fast as they can and let the customers do the "paying beta". Once the features are ironed out, they release a more polished mass-market product that has benefited from all the customer feedback.
Game development has been totally ass-backwards in terms of its development approach since forever. Games are effectively developed in giant waterfall projects which either crash and burn or do extremely well - but you only find out at the end. Unlike the poster of the original article I think it's great to see the games development processes maturing in this way towards what is the de-facto model of choice for product development in the real world. Well done Vanguard!
The results that can be expected from this shift of approach are:
People who are keen to try stuff early can do so
The costs of development of a game will be reduced (and hopefully the sales price too)
The risks of developing a game will be reduced (since you'll know earlier whether the game is viable)
Game quality will simply become better! Customer feedback will play a bigger part in shaping the game from much earlier on.
More development shops will open as the hurdle to entry lowers
Games which are fundamentally shit will be canned earlier
More risk can be taken by trying something different if you're only going to invest 3 months of dev time rather than 3 years! Plus you get immediate customer feedback so you can quickly find out whether your new idea is brilliant or a dog.
There are many others... ultimately this is an extremely good move for the industry and we should be very glad of it. Perhaps with this the games industry will finally move towards the "software as a service/continuously updated product" model that is spreading far and wide in the rest of the software and meatspace industry.
Because we're a race of dreamers and we get excited by the idea of spreading beyond the confines of our planet, our solar system, and even our galaxy?
By your argument, why bother crawling out of the ocean? Why bother crawling out of bed for that matter? You'll be dead sometime anyway, and everything you've done in your life won't have mattered one bit.
Totally agree with all the comments about TD and CQ. They are existing options however. I was just mentioning them, not supporting or even condoning them.
On the enterprise level there's of course the infamous TestDirector from Mercury Interactive, and the equally infamous ClearQuest from Rational/IBM, but these are probably not adequate for a 5-person organisation (more for organisations with thousands of developers, dozens of projects). I too would be interested in finding out what solution can be implemented simply and reliably outside of the corporate world, for smaller companies.
Extra bonus points go to a system that is clear enough that it is possible to integrate it into a customer support system (e.g. easily tie into it programmatically to insert new issues when they're raised by users...
I was thinking exactly that, when I first heard of these ads...
I think the Apple marketing team has missed one essential point:
Both of the main characters of Peep Show are wankers!
That's one of the things that dawns on you as you watch the show is that the two characters are equally worthless human beings. You start off siding with Jeremy because he's cooler, but then realise he's a wanker, so then Mark appears slightly better because he's on the surface a bit more kind... but then he turns out to be a prick as well.
Which I guess is spot on. Computers are a pain no matter which one you use!
No, that's a completely ridiculous suggestion, for several reasons.
1) Artists build upon other artists. Some of the best pieces of art are composites of other pieces of art (Shakespeare being the classic example). This super-DRM'ed world would contradict that fact and make it much harder for artists to do their work. It would also make it impossible to create such art forms as satire, abbreviation, etc.
2) This system would contradict one of the basic realities of this universe: ideas are infinitely duplicable at no cost other than the medium to store them. You can have all the DRM systems in the world - if your poem appears on my screen and I memorize it or write it down, I've made a copy. I can then repost it if I feel so inclined. Trying to control the technological gateways (enforcing DRM'ed hardware, etc) is ultimately a losing battle, like fighting the ocean with a broom.
3) Such a system, to work perfectly, would by definition require real-time, detailed monitoring of everyone's activities that have anything to do with so-called "intellectual property". Apart from the huge technical challenge that this would represent (can you even imagine any IT company implementing this when they can't even create a centralised system of patient records without screwing up - see NHS PfIT), this would be a huge infringement on everyone's privacy. Or rather, it would be a complete eradication of the very concept of privacy.
Agreed... factoring the "lines of code" into a function without thinking about some sort of higher purpose reason why that function needs to exist is a bit similar to thinking "I need a music in all the rooms of my house, and i already have a car radio, so i'll just copy that and reuse it in all the rooms"... it might make sense at first but it's a maintenance nightmare waiting to happen.
One of the most effective techniques I've used to encourage adoption of change is to get the people who will need to change to own the new process. How do you do that? You heavily involve them in designing the process, expose them to the reasons why the process is good, get them engaged in discussions about how to resolve the problems that you're trying to resolve. Sure, you're bright and everything and you know the solution already, but that doesn't mean everyone will do as you say.
Best way to do this is for you to create an imperfect solution then have one-on-ones with all the key stakeholders and get them to contribute to it. Expose them to the business requirements (expose them to the business if need be) so that they understand perfectly well why this is happening, and get them to own this process and thus commit to it. Then once everyone's agreed that this is the way to go, you can set up some sort of regular measurements to track the adoption of the processes. Make those measurements visible and the key stakeholders will get these processes adopted by their teams.
One of the main things I look for in a technical CV is evidence of technical work *outside* of the office. I've found that someone more junior but who plays with techhnology as a hobby will be significantly more performant than someone who is apparently more experienced but only does it as a day job.
Slashdot Mirror
The defendant shall henceforth be required to contribute one third out of every Banana to the welfare of the state.
- By order of: The Supreme Court of Kangaroos
You're missing the point of the article/announcement completely. The point there is that the session is still associated with the browser when the user visits another page. So that page, even though it's on a different server, can make the browser retrieve, say, all your emails from your gmail account, and then send them wherever it wants.
Daniel
Sorry, I was writing this in a rush. I meant site A executes the code that was injected, retrieves the resulting data from site A, and then sends that data over to site B (or some other location). Typically this "data" is stuff like login information...
Daniel
I think the very subtle difference is that this time the calls are made using site A's public Ajax API, using site A's authentication token, but are made from a script sitting on site B. The javascript calls return with data from site A, which can then be handled by site B. XSS/JS Injection is more about injecting alien javascript onto site A to make site A call site B with the info it wants.
Daniel
*Dzing* Incorrect answer. Thank you for playing
A "database pro" would look for unoptimized queries and missing indexes and speed up the database on the current hardware. As a matter of fact, most "database pros" work in environments where commissioning new hardware takes 6 months or so and goes through some ridiculous approval processes, so that's actually the hard option.
Daniel
That doesn't actually seem like a step in the right direction. Reading "dumb" voltages is a million miles away from reading thoughts - no breakthrough at all. In fact, they've been doing this for decades through EEGs - plugging it into a computer interface doesn't make it a breakthrough. It's a very clumsy and slow way of designing a brain interface.
I'm much more interested in the invasive procedures which actually read body movement intentions - those are much more versatile than just reading "whether the user is concentrating"...
Daniel
That's all fine and dandy, but have you considered the possibility of mass extinction from diseases spread by dirty telephone handsets?
Daniel
Won't lag time be a major issue for a co-hosted radio show? I would imagine much of the dynamics of a co-hosted show, and what makes it so much more interesting, come from the immediate, zero-delay interactions between the two hosts. A large part of their ability to interact so quickly is, I would imagine, driven by the "high bandwidth" of communication between them - ie textual (5%), tonal (45%), AND body-language (50%) content... From the sound of it you've done something similar already - wasn't that an issue?
Daniel
Absolutely. Get your ass off your chair, walk over to the users, and talk to them about what they need. Then write yourself a detailed spec if you feel you need it. Then turn that spec into some paper-based mockups and walk the users through it. Then make any corrections needed. Then write the software.
And count your lucky stars that your company is incapable of writing proper specs - if they were, they would have outsourced your job to India or Brazil a long time ago.
Daniel
No, the bird flu aspect is the least important. Flocks of RC pigeons can do all sort of nasty stuff - most obvious (which I actually had in my story submission but which the /. eds removed) being to take down a plane or attack groups of people with lots of small explosive charges.
Daniel
a) it's not a problem, it's a solution (to reduce the risk of releasing a product no one wants to buy)
b) hardware is affected as well. Most major electronics companies, for instance, come up with an "early adopters" product that isn't quite there yet which they manufacture in smaller numbers and don't advertise as much. They then get the customer feedback on that and use it to ensure the next version is much more customer-friendly.
Daniel
Who was it who said "Release Early and Often"? Oh yes, Eric S Raymond, in the seminal The Cathedral and the Bazaar.
Not to mention the plethora of literature about product development in other, non-software environments. All major product companies nowadays release products as fast as they can and let the customers do the "paying beta". Once the features are ironed out, they release a more polished mass-market product that has benefited from all the customer feedback.
Game development has been totally ass-backwards in terms of its development approach since forever. Games are effectively developed in giant waterfall projects which either crash and burn or do extremely well - but you only find out at the end. Unlike the poster of the original article I think it's great to see the games development processes maturing in this way towards what is the de-facto model of choice for product development in the real world. Well done Vanguard!
The results that can be expected from this shift of approach are:
- People who are keen to try stuff early can do so
- The costs of development of a game will be reduced (and hopefully the sales price too)
- The risks of developing a game will be reduced (since you'll know earlier whether the game is viable)
- Game quality will simply become better! Customer feedback will play a bigger part in shaping the game from much earlier on.
- More development shops will open as the hurdle to entry lowers
- Games which are fundamentally shit will be canned earlier
- More risk can be taken by trying something different if you're only going to invest 3 months of dev time rather than 3 years! Plus you get immediate customer feedback so you can quickly find out whether your new idea is brilliant or a dog.
There are many others... ultimately this is an extremely good move for the industry and we should be very glad of it. Perhaps with this the games industry will finally move towards the "software as a service/continuously updated product" model that is spreading far and wide in the rest of the software and meatspace industry.Daniel
Because we're a race of dreamers and we get excited by the idea of spreading beyond the confines of our planet, our solar system, and even our galaxy?
By your argument, why bother crawling out of the ocean? Why bother crawling out of bed for that matter? You'll be dead sometime anyway, and everything you've done in your life won't have mattered one bit.
Daniel
Wtf is wrong with y'all? Haven't you heard of W3Schools? There's your answer:
W3Schools Browser Stats
Full breakdown, data going back to 2002, good selection of sources... what more do you want???
Daniel
Totally agree with all the comments about TD and CQ. They are existing options however. I was just mentioning them, not supporting or even condoning them.
Daniel
On the enterprise level there's of course the infamous TestDirector from Mercury Interactive, and the equally infamous ClearQuest from Rational/IBM, but these are probably not adequate for a 5-person organisation (more for organisations with thousands of developers, dozens of projects). I too would be interested in finding out what solution can be implemented simply and reliably outside of the corporate world, for smaller companies.
Extra bonus points go to a system that is clear enough that it is possible to integrate it into a customer support system (e.g. easily tie into it programmatically to insert new issues when they're raised by users...
Daniel
I was thinking exactly that, when I first heard of these ads...
I think the Apple marketing team has missed one essential point:
Both of the main characters of Peep Show are wankers!
That's one of the things that dawns on you as you watch the show is that the two characters are equally worthless human beings. You start off siding with Jeremy because he's cooler, but then realise he's a wanker, so then Mark appears slightly better because he's on the surface a bit more kind... but then he turns out to be a prick as well.
Which I guess is spot on. Computers are a pain no matter which one you use!
Daniel
BDSM and Virtual Sex...
Daniel
Mod parent +1! Would it really cause *physical pain* to the original poster to define WTF "VT" stands for somewhere in his posting???
Daniel
No, that's a completely ridiculous suggestion, for several reasons.
1) Artists build upon other artists. Some of the best pieces of art are composites of other pieces of art (Shakespeare being the classic example). This super-DRM'ed world would contradict that fact and make it much harder for artists to do their work. It would also make it impossible to create such art forms as satire, abbreviation, etc.
2) This system would contradict one of the basic realities of this universe: ideas are infinitely duplicable at no cost other than the medium to store them. You can have all the DRM systems in the world - if your poem appears on my screen and I memorize it or write it down, I've made a copy. I can then repost it if I feel so inclined. Trying to control the technological gateways (enforcing DRM'ed hardware, etc) is ultimately a losing battle, like fighting the ocean with a broom.
3) Such a system, to work perfectly, would by definition require real-time, detailed monitoring of everyone's activities that have anything to do with so-called "intellectual property". Apart from the huge technical challenge that this would represent (can you even imagine any IT company implementing this when they can't even create a centralised system of patient records without screwing up - see NHS PfIT), this would be a huge infringement on everyone's privacy. Or rather, it would be a complete eradication of the very concept of privacy.
Daniel
Agreed... factoring the "lines of code" into a function without thinking about some sort of higher purpose reason why that function needs to exist is a bit similar to thinking "I need a music in all the rooms of my house, and i already have a car radio, so i'll just copy that and reuse it in all the rooms"... it might make sense at first but it's a maintenance nightmare waiting to happen.
Daniel
One of the most effective techniques I've used to encourage adoption of change is to get the people who will need to change to own the new process. How do you do that? You heavily involve them in designing the process, expose them to the reasons why the process is good, get them engaged in discussions about how to resolve the problems that you're trying to resolve. Sure, you're bright and everything and you know the solution already, but that doesn't mean everyone will do as you say.
Best way to do this is for you to create an imperfect solution then have one-on-ones with all the key stakeholders and get them to contribute to it. Expose them to the business requirements (expose them to the business if need be) so that they understand perfectly well why this is happening, and get them to own this process and thus commit to it. Then once everyone's agreed that this is the way to go, you can set up some sort of regular measurements to track the adoption of the processes. Make those measurements visible and the key stakeholders will get these processes adopted by their teams.
Daniel
One of the main things I look for in a technical CV is evidence of technical work *outside* of the office. I've found that someone more junior but who plays with techhnology as a hobby will be significantly more performant than someone who is apparently more experienced but only does it as a day job.
Daniel
Mod parent up!... +1 insightful.
Daniel
Actually, I would imagine they're paid pretty badly, like most people in the publishing industry.
Daniel