Chris Hanson:
Swift 2 introduced a new error handling mechanism that, for completeness, needs to be accommodated by our testing frameworks. Right now, to write tests that involve methods that may throw an error, a developer needs to incorporate significant boilerplate into their test. We should move this into the framework in several ways, so tests of code that interacts with Swift error handling is concise and intention-revealing.
[…]
One other downside of the above is that a failure caught this way will be reported as an expected failure, which would normally be a failure for which XCTest is explicitly testing via an assertion. This failure should ideally be treated as an unexpected failure, as it’s not one that’s anticipated in the execution of the test.
[…]
I propose several related solutions to this issue:
- Allow test methods to throw errors.
- Allow test assertion expressions to throw errors.
- Add an assertion for checking errors.
Drew Crawford:
This proposal IMO addresses an important problem, but I am not convinced it actually solves it. #2 & #3 are basically sound API designs. It is a mystery to me why #3 “generated some debate” as this is a feature I already implement manually, but I can’t address unknown concerns. I can tell you I implement this, and nothing terrible has happened to me so far.
[…]
When the test function throws we no longer even find out a line number in the test case anymore, because the error is passed into XCTest and the information is lost. We have just the name of the test case (I assume; the proposal is silent on this issue, but that’s the only way I can think of to implement it), and some of my tests are pretty long. So, that makes it even harder to track down.
This sounds like a small thing but my test coverage is so thorough on mature projects that mostly what I turn up are heisenbugs that reproduce with 2% probability. So getting the report from the CI that has the most possible detail is critical, because if the report is not thorough enough for you to guess the bug, too bad, because that’s all the information you get and the bug is not reproducible.
For that reason, I won’t use #1.
Indeed, Swift and XCTest don’t currently work together very smoothly. I suspect that many developers have implemented their own versions of #2 and #3 already.
The lack of support for tracing the flow of errors is a more general problem that goes beyond testing. With exceptions, you would get a stack trace. In Objective-C, it’s easy to use macros to add tracing information to errors when propagating them. In Swift, I’ve seen this tip for tracking the source of errors that you create, but that isn’t most errors.
Language Design Macros NSError Programming Swift Programming Language Testing Xcode
Brian Krebs (via @SwiftOnSecurity):
My PayPal account was hacked on Christmas Eve. The perpetrator tried to further stir up trouble by sending my PayPal funds to a hacker gang tied to the jihadist militant group ISIS. Although the intruder failed to siphon any funds, the successful takeover of the account speaks volumes about why most organizations — including many financial institutions — remain woefully behind the times in authenticating their customers and staying ahead of identity thieves.
[…]
But by the time I got back home to a computer, my email address had been removed and my password had been changed. So much for PayPal’s supposed “monitoring;” the company couldn’t even spot the same fraudulent email address when it was added a second time.
[…]
In my second call to PayPal, I insisted on speaking with a supervisor. That person was able to tell me that, as I suspected, my (very long and complex) password was never really compromised. The attacker had merely called in to PayPal’s customer support, pretended to be me and was able to reset my password by providing nothing more than the last four digits of my Social Security number and the last four numbers of an old credit card account.
[…]
PayPal does offer additional security protections — including a PayPal Security Key fob that periodically generates a new one-time password which needs to be entered at login in addition to a username and password. I’ve used this solution since shortly after the company began offering it almost a decade ago, but a fat lot of good it does if PayPal is going to continue letting users reset their passwords by regurgitating static data that is trivial to purchase from the cybercrime underground.
Dave Mark:
Last night we got an email from a PayPal spokesperson with this official response:
The safety and security of our customers’ accounts, data and money is PayPal’s highest priority. Due to our privacy policies that protect our customers, PayPal does not publicly disclose details about our customers’ accounts or their specific cases. However, it appears that our standard procedures were not followed in this case. While the funds remained secure, we are sorry that this unacceptable situation arose and we are reviewing the matter in order to prevent it from happening again.
Breach PayPal Security Web
Kirk McElhearn:
Jobs then introduced iTunes, arguably the most important software Apple ever released, other than its operating systems. iTunes set the tune for the company’s next decade and its rise from a “beleaguered” hardware and software company to the industry leader we know today. Admitting that Apple was playing catch-up, Jobs said, “We’re late to this party and we’re about to do a leapfrog.”
And they sure did.
[…]
In my writings about iTunes—notably my Ask the iTunes Guy column—I field questions from users perplexed by the quirks of this app. I used to get questions asking how to do something more efficiently, and I was able to help people organize and manage their music creatively. Now, most of the questions I get are about trying to work around things that are broken, or how to find features that were once easily accessible. More and more users long for a simple music player that sheds much of the cruft that has built up over the years.
When he started the column, I totally underestimated how much material there would be for it.
Update (2016-01-12): Nick Heer:
For my use, iTunes has become steadily worse over the years, as I’m regularly pushed to purchase more from the iTunes Store and place all my music in iCloud. Neither of those things appeals to me. Yet, I’m compelled to continue using iTunes partly because I sync my iPhone in the old-fashioned way, and partly because I’ve never found a compelling replacement for it.
Anniversary History iTunes Mac Mac App Music Steve Jobs
Ron de Bruin:
In Windows Excel 97-2016 and in Mac Excel 2011 you can open files or save files where you want in almost every folder on your system without warnings or requests for permission. But in Mac Office 2016 Microsoft have to deal with Apple’s sandbox requirements. When you use VBA in Mac Excel 2016 that Save or Open files you will notice that it is possible that it will ask you permission to access the file or folder (Grant File Access Prompt), this is because of Apple’s sandbox requirements. This means that when you want to save/open files or check if it exists with VBA code the first time you will be prompted to allow access on the first attempt to access such a folder or file.
He recommends putting your documents in the Library folder:
There are a few places on your Mac that you can use to avoid the prompts and let your code do what it needs to do without user interaction. But these folders are not in a place that a user can easily find so below are some steps that I hope to make it easier for you to access the folder manual if you want.
Mac Mac OS X 10.11 El Capitan Microsoft Excel Microsoft Office Programming Sandboxing Visual Basic for Applications (VBA)
