I agree with figuerres that code like this is just asking for trouble.
Even though you can't use the third i until after it's declared, its scope is still the main method block.
Loading User Information from Channel 9
Something went wrong getting user information from Channel 9
Loading User Information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
Okay, so I like how Apple Pay is set up. It seems just as secure, if not more so, than chip-and-pin (which can't come soon enough to the U.S.). And if the chip-and-pin readers all support NFC payments by default, then it's a win-win.
My only remaining question is whether the NFC readers will also support other payment systems, or if they're locked into Apple.
Not sure how much all this brand shuffling matters anyways:
Actually, on account.live.com you can remove all trusted devices so they'll have to use a code again. So if your laptop gets stolen, simply do that and they still won't be able to get into your account. Or just change your password, for that matter, which would require them to sign in again even though you selected "remember me."
Good point, and for something like a stolen laptop, it makes sense.
I have two-factor auth enabled for my Microsoft Account, but that doesn't help me if my laptop is stolen. "I use this device often. Remember Me".
I have a set of passwords of varying complexity. Gmail gets my weakest. The worst someone with that password could do is post as me on forums and pay my retail credit card bills.
Microsoft account gets its own password. Banks/Facebook/Credit Cards get another password.
My last job stored everything in official Word documents that were printed and signed, then scanned and stored on a file server forever. No one ever looked at them.
My current job has no documents. Requirements could be gathered with some work from TFS work items.
Somewhere in the middle is probably best. I think a shared OneNote notebook for each project would be ideal.
@DeathByVisualStudio: We looked at it. It essentially stores all of the create scripts in source control and you can then deploy by running SQLCompare against those scripts instead of a live database.
We haven't decided what to do yet, so our databases are still uncontrolled.
I've looked at it a few times, but have never used it on a real project. Most of our apps access a shared database, so I'd either need to have two solutions going, or have the same database project in every solution, and that just gets messy from a source control perspective.
We use RedGate SQL Compare for moving DB changes between environments. It does a great job 99% of the time.