Crowd sourced morality on automated cars handling collisions: http://www.technologyreview.com/view/542626/why-self-driving-cars-must-be-programmed-to-kill/ … 3 laws is thin API over Amzn Mechanical Turk service.
Considering replacing my very aged home WAPs & router. Recommendations? This looks
enticing: http://arstechnica.com/gadgets/2015/10/review-ubiquiti-unifi-made-me-realize-how-terrible-consumer-wi-fi-gear-is/ …
Interview with director & hackers wrt Hackers 20th anniversary http://passcode.csmonitor.com/hackers
Thought final line of Sparks was weird joke then heard post TAH show. Do I need to
re-review all Ginny West material now? @ThrillingAdv
Difficulties of props in entertainment: matching viewer expectations not reality, HD,
trademarks, and currency. http://www.bloomberg.com/graphics/2015-property-master/ …
Tesla's April fools headline fooled stock trading algorithms causing $1.50 jump:
http://www.bloombergview.com/articles/2015-04-02/tesla-stockholders-can-t-take-a-joke …
Xpath in #EdgeHTML using CSS selectors and WGX (Wicked Good XPath) http://blogs.msdn.com/b/ie/archive/2015/03/19/improving-interoperability-with-dom-l3-xpath.aspx … The tech here is amazing. #ICodeReviewedThat
After visiting a page then immediately wanting to take back my page view and
associated ad revenue: REGRET http://clicbait HTTP/1.1 ...
David Risney
@David_Risney :
Jacob Rossi
@jacobrossi : David Risney
@David_Risney :As the title suggests, spoilers for The Interview follow.
Towards the end of the movie, after Dave Skylark is shot, he miraculously has a bullet proof vest, blows up Kim Jong-un, finds a random tunnel and is picked up by Seal Team Six. These are the same details of the unbelievable scenario that Dave Skylark describes to Agent Lacey at the beginning of the movie.
This isn't a coincidence. Everything after Dave is shot is his fantasizing about how things should have gone as he dies in the interview chair. Unsurprisingly his fantasy closely matches his original ridiculous thoughts about how he would assassinate and escape.
This is similar to movies like Brazil in which the later fourth of the movie is the main character’s romantic fantasy as he is tortured and killed in real life. Or Total Recall where the end of the movie matches the description of the memories that the main character will have implanted at the beginning.
Its safe to assume that after Dave is killed, Aaron and Sook are captured and also killed.
Some time back while I was working on getting the Javascript Windows Store app platform running on Windows Phone (now available on the last Windows Phone release!) I had an interesting bug that in retrospect is amusing.
I had just finished a work item to get accessibility working for JS WinPhone apps when I got a new bug: With some set of JS apps, accessibility appeared to be totally broken. At that time in development the only mechanism we had to test accessibility was a test tool that runs on the PC, connects to the phone, and dumps out the accessibility tree of whatever app is running on the phone. In this bug, the tool would spin for a while and then timeout with an error and no accessibility information.
My first thought was this was an issue in my new accessibility code. However, debugging with breakpoints on my code I could see none of my code was run nor the code that should call it. The code that called that code was a more generic messaging system that hit my breakpoints constantly.
Rather than trying to work backward from the failure point, I decided to try and narrow down the repro and work forwards from there. One thing all the apps with the bug had in common was their usage of WinJS, but not all WinJS apps demonstrated the issue. Using a binary search approach on one such app I removed unrelated app code until all that was left was the app's usage of the WinJS AppBar and the bug still occurred. I replaced the WinJS AppBar usage with direct usage of the underlying AppBar WinRT APIs and continued.
Only some calls to the AppBar WinRT object produced the issue:
var appBar = Windows.UI.WebUI.Core.WebUICommandBar.getForCurrentView();
// appBar.opacity = 1;
// appBar.closeDisplayMode = Windows.UI.WebUI.Core.WebUICommandBarClosedDisplayMode.default;
appBar.backgroundColor = Windows.UI.Colors.white; // Bug!
I eventually realized that predefined WinRT color values like Windows.UI.Colors.aqua would cause the issue while JS literal based colors didn't cause the issue (Windows.UI.Color is a WinRT struct which projects in JS as a JS literal object with the struct members as JS
object properties so its easy to write something like {r: 0, g: 0, b: 0, a: 0} to make a color) and I had been mixing both in my tests without realizing there would be a difference.
I debugged into the backgroundColor property setter that consumed the WinRT color struct to see what was different between Windows.UI.Colors.black and {a: 1, r: 0, g: 0, b: 0} and
found the two structs to be byte wise exactly the same.
On a hunch I tried my test app with only a reference to the color and otherwise no interaction with the AppBar and not doing anything with the actual reference to the color:
Windows.UI.Colors.black;. This too caused the issue. I knew that the implementation for these WinRT const values live in a DLL and guessed that something in the code to create these
predefined colors was causing the issue. I debugged in and no luck. Now I also have experienced crusty code that would do exciting things in its DllMain, the function that's called when a DLL is loaded into the process so I tried modifying my
C++ code to simply LoadLibrary the DLL containing the WinRT color definition, windows.ui.xaml.dll and found the bug still occurred! A short lived moment of relief as the world seemed to make
sense again.
Debugging into DllMain nothing interesting happened. There were interesting calls in there to be sure, but all of them behind conditions that were false. I was again stumped. On another hunch I tried renaming the DLL and only LoadLibrary'ing it and the bug went away. I took a different DLL renamed it windows.ui.xaml.dll and tried LoadLibrary'ing that and the bug came back. Just the name of the DLL was causing the issue.
I searched for the DLL name in our source code index and found hits in the accessibility tool. Grinning I opened the source to find that the accessibility tool's phone side service was trying to determine if a process belonged to a XAML app or not because XAML apps had a different accessibility contract. It did this by checking to see if windows.ui.xaml.dll was loaded in the target process.
At this point I got to fix my main issue and open several new bugs for the variety of problems I had just run into. This is a how to on writing software that is difficult to debug.
Adds the yield keyword enabling you to write JS code that sort of looks like C# await.
Overview
First-class coroutines, represented as objects encapsulating suspended execution contexts (i.e., function activations). Prior art: Python, Icon, Lua, Scheme, Smalltalk.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"Fitbit Connect.exe"=dword:000022b8
In IE10 and other new browsers one may create MessageChannel objects that have two MessagePorts each connected (w3c spec calls it entangled) to one another such that postMessage on one port results in the message event firing on the other. You can pass an array of ports as the last parameter to postMessage and they show up in the ports property of the message event arg.
The postMessage here is like the worker postMessage and unlike the window and iframe postMessage in that it applies no origin checking:
Unfortunately the origin isn't an optional parameter at the end to make the two postMessages have the same signature.
On the event handler side, the event arg always has an origin property. But in the no origin case it is always the empty string.
There is also a source property on the message event arg which if set is an object that has a postMessage property allowing you to post back to your caller. It is set for the origin case, however, in the no origin case this property is null. This is somewhat reasonable because in the case of MessagePort and Workers there are only two endpoints so you always know the source of a message implicitly. Unlike the origin case in which any iframe or window can be calling postMessage on any other iframe or window and the caller is unknown. So not unreasonable but it would be nice if the source property was always set for consistency.
When a MessageChannel is created it has two MessagePorts, but until those ports are started they will queue up any messages they receive. Once started they will dispatch all queued messages. Ports don't have to be started to send messages.
A port may be started in two ways, either by explicitly calling the start method on the port, or by setting the onmessage callback property on the port. However, adding an event listener via addEventListener("message", does not start the port. It works this way in IE and Chrome and the spec states this as well.
The justification is that since you can have only one callback via onmessage that once set you must implicitly be ready to receive messages and its fine to start the port. As opposed to the addEventListener in which case the user agent cannot start implicitly because it doesn't know how many event listeners will be added. I found Hixie stating this justification in geoloc meeting notes.
My third completed Windows Store app is Percent Clock which displays portions of a time span like the time of the day or time until your next birthday, as a percentage. This was a small project I had previously started as a webpage and converted and finished as an HTML JavaScript Windows Store app.
The only somewhat interesting aspect of this app is that its the first app for which I tried charging. I picked the minimum amount for price 1.49 USD as it is a simple app and unsurprisingly it has sold very poorly. I'm considering releasing new instances of the app for specific scenarios:
What It All Means: All Your Communications are Belong to U.S. In sum, if you use encryption they’ll keep your data forever. If you use Tor, they’ll keep your data for at least five years. If an American talks with someone outside the US, they’ll keep your data for five years. If you’re talking to your attorney, you don’t have any sense of privacy. And the NSA can hand over you information to the FBI for evidence of any crime, not just terrorism. All without a warrant or even a specific FISA order.
Not sure if this is saying all Tor data is collected or saying if someone uses Tor then start collecting that someone’s communication.
Some rights reserved