The reporting requirements in H2020 funded projects are way less. Even with late FP7 projects, our POs already told us that deliverables >120pages were somewhat frowned upon as they also realized that no one reads them anyway.

The license is required to make sure dancers receive proper training and are pleasing to the eye! Imagine walking into a strip bar only to see some naked guy wobbling around his man breasts.

Yes I did, and I posted a correction like 10s later - sorry about that.

If only I could read numbers ..

That's like what? Two consulting firms for a year? This is peanuts and gives you an indication of the scope they are aiming for. Let alone that the sheer fact that this is news ought to tell you something about the BND in Germany. Somewhen last year, the SCHUFA and the Hasso-Plattner institute tried to get funding to derive your credit score from your social network activity, the public outcry was deafening. Similarly, this will go nowhere or be so limited in scope as to be useless. We'll just rely on the five-eyes consortium to clue us in in the case of an emergency.

Germany introduced minimum wage of 8.5EUR like two weeks ago. There are some exemptions for minors and elderly though.

That's funny, you see I have Windows 7 in VM here on my MacBook Pro and can't stop cussing about text navigation on windows. On a Mac every text entry behaves the same: arrow keys move the cursor one character, option + arrow key moves one word, cmd + arrow key moves to the start and end of a line. It's pretty much hard-coded into my muscle memory by now and I can rely upon every text-entry behaving this way. Same with text selection via mouse: click once & keep pressed places cursor and selects characters, double click & keep pressed selects word under mouse and whole words after that, triple click for paragraphs.

It's not so much the actual interface combo but consistency that drives me mad on Windows, e.g. triple clicking in Visual Studio deselects the text-selection rather than to select the whole paragraph or line and it's different with every other application - you just cannot rely upon it!

Guess he was just unlucky then.

If there are, they are breaking the law. The cheapest drink available in a restaurant has to be non-alcoholic: http://de.wikipedia.org/wiki/Apfelsaft-Paragraph

Meant to say SISR, not SSML.

It would be perfectly reasonable to send the SRGS grammar along with the voice data. It would even help Google with speech recognition as the search graph (assuming HMMs here), would be way smaller as opposed to those employing a full-blown dictionary grammar. Not accepting a grammar and only returning an N-Best list makes it pretty much unusable for anything non-trivial. What happened to all those concepts developed as part of EMMA/VoiceXML? It seems like the Web Speech API ignores everything that came before and went for the most naive approach.

I don't know whether this has been mentioned before, but the big problem with Google's approach is that it won't allow me to define a formal grammar as the "set of things the user might reasonably say". Dictionary recognition, as is employed here and on the Android phones, has the big disadvantage that I would need some kind of natural language understanding on the (already error-prone result) for anything but dictating text.

It is in essence a projection of voice to an N-Best list of recognition results. No if I could specify a grammar (e.g. per SRGS), I could have semantic annotation per SSML and use voice to actually control an application.

They hardly contribute to the creation of new energy sources. There has been a documentary on WiSo, here is the gist of it (german sorry): http://www.dailygreen.de/2011/11/03/wiso-okostrom-anbieter-fordern-kaum-die-energiewende-in-deutschland-28318.html

I too can't get myself to follow practices such as test-first, but I found a method that is not as ambitious, yet guarantees robust code and only few errors. Whenever I write a method, I think about what I am assuming at runtime and codify these assumptions as pre- and post-conditions at the beginning and the end of a method. These assumptions can be quite complete and I learned that I implicitly make them when writing code anyway, all I do is to write them out as assert statements. Then I devise a set of component tests that trigger different call-flows, hoping to cover a wide variety of states.

It really provides a great sense of certainty and I learned that I can skip a lot of error handling in the method by just asserting a fact. When I am confident that a function does what it is supposed to do, I recompile without debugging and the preprocessor will drop the asserts. I have made good experiences with this approach and certainty that a method does what I think it does far outweighs the additional overhead of writing the post- and pre-conditions and provides the means to keep your internal model and the actual model of the code aligned.