Last election, Party C got a large enough share of the popular vote to get into a coalition government. Party D would likely do the same if they could get more than half of the didn't-vote crowd to vote for them next time.

No one outside of his constituency voted for him, that's now how it works in a parliamentary system (he's a Prime Minister, not a President). His party received 36.1% of the popular vote, 23.5% of the votes of those eligible to vote. Non-voters were the largest bloc in the last election. Perhaps this time they'll realise and exert some influence...

Because that happens at a particular time when the operating system can special case it. Most desktop and mobile operating systems will now, before exposing the network interface, check whether an outgoing HTTP connection is hijacked and pop up a browser if it is. This prevents damage to sites and apps that poll HTTP in the background and expect well-formed replies in a particular format. Doing it randomly bypasses this protection.

You're assuming that the connection that they redirect is a web browser. You might want to look at how many other apps poll things over HTTP periodically, and what they do if they don't understand the response (e.g. they expect a simple JSON response and they get a big blob of HTML). Even if it is a web page, what happens when the HTTP request that they hijack is a background AJAX request and not the main page fetch?

I've never seen it done, and it would be a spectacularly bad idea. It might have been fine 10 years ago, when most HTTP traffic was to a web browser, but now a load of other apps use HTTP as the transport. Intercepting and redirecting one can cause problems locally and sounds like a violation of the computer misuse act.

When I've had this kind of rejection, it typically means that the paper is not well presented. Part of the reason that papers that are rejected one or more times before publication tend to be more widely cited is that the rejection and editing phase forces you to make your arguments in a clearer and more structured manner.

While that's more or less true, it's worth noting that EPSRC doesn't require any accountability on the spent funds, they just use previous research output when judging the next application. That means that if you want to do something groundbreaking then you can apply for a grant to do something a bit incremental (ideally something that you've mostly done but not published), then use the money to do the groundbreaking thing. Then, when you apply for the next grant, the groundbreaking things that you want to do are easier to fund.

Citations are a terrible way of measuring paper quality. One of the most recent citations of a paper of mine was from some guys I know at MIT, who basically said 'and this is exactly the wrong way of doing it'. A lot of the things we cite with the biggest citation counts are benchmark suites. There's a reason that the REF[1] explicitly didn't include bibliometrics when evaluating impact (at least in computer science, not sure about other fields).

[1] The 'Research Excellence Framework', which assesses and ranks the research output of UK university departments.

When I was freelancing, I got quite a few jobs from helping people out in IRC and mailing lists. When someone comes in with fairly naive technical questions, it turns out it can mean that they're considering adopting the project internally and will want to start hiring both full-time workers and consultants who have experience with it.

True, but unless your project is very successful already, don't expect to get a job working on that project and don't expect the company that hires you to adopt it. Think of it as a portfolio: it's evidence of a category of work that you can do well. When a company interviews you, they're not trying to judge whether the project that you've worked on is useful to them, they're trying to judge whether working on that project (and other things) has given you skills that are useful to them.

It is hard. Producing a new creative work, be it a film, piece of software, book, or whatever, is hard and often expensive. Copying a creative work is cheap to the point that it's barely worth measuring the cost. Lots of influential companies have business models that revolve around doing the difficult thing for free and then charging for the easy thing to make up for it. They're eventually going to be displaced by companies that realise that it makes more sense to charge for the difficult thing - we're seeing this in software already, with open source companies giving away code that's already written for free and charging for writing new features or customisation (or, in some cases, entirely new programs).

In 100 years, people are going to look back on DRM and restrictive copyright in much the same way that we look back at the laws that required motor cars to have someone walk in front of them with a red flag. Regulations that can't possibly work in the long term, designed to prop up an industry that's suddenly found itself obsoleted by new technology.

Uh, yes? Because that's how you write code that handles errors correctly. Exceptions come from three sources:

• Runtime exceptions. These don't need to be caught or declared by Java code, but you can generally avoid them by making sure you have null reference checks and using iterators for collections.
• Exceptions that you throw yourself. You know you're throwing these and the odds are that you want the caller to handle them (if you're using exceptions for intraprocedural flow control, then you're an idiot). So advertise them on your method. Done.
• Exceptions thrown by methods that you call. These are all advertised by those methods and checked by the compiler (or your IDE), so there's no excuse for not knowing that they're expected.

This stuff isn't hard. You know at every call site what the possible exceptions are, and you know this because the compiler won't let you explicitly throw or fail to handle any exceptions in your methods. The exceptions that a method can throw are in the JavaDoc and are checked at compile time, so you'll get a compile error if you don't either handle or advertise the exception.

Good error handling is one of the key things that differentiates good developers from bad. If it's something that you find hard, in a language that goes out of its way to make it easy, then you might want to consider other careers.

Actually that's not true. India and China did very well out of being a cheap place to manufacture things because of the low labour cost. Now, factories that are almost entirely automated are replacing those staffed by unskilled workers. This means that no one is building them in developing countries and creating jobs there. The only reason that companies like Foxconn have for picking places in Africa for manufacturing now is the the lack of environmental regulation: a few politicians get paid off, but the local economy doesn't benefit and the local environment gets polluted. The path Japan took, of cheaply copying things, being a cheap place to build factories, developing local skills, and then competing internationally with original products, doesn't exist anymore.

Exactly. Few workers would complain about automation if they owned a share in the company proportionate to their contribution to the profits. If a robot means that the company can produce more without their going to work then their income would go up and so would their leisure time. Instead, they become redundant in a shrinking job market and the owners get richer.

Java doesn't require you to catch every exception, it requires that, for every exception that cam be generated in a method, you must either catch it or advertise that your method can throw it. This makes static analysis and reasoning about exception much easier, because you know exactly what exceptions a particular method can throw. Handling exceptions at the wrong place is a problem with the programmers, not with the language or VM.