Andy Bargh:
If we dive into a bit more of the detail behind assertions in Swift, we find that the Swift language actually supports five, different types of assertion. These are:
– assert()
– precondition()
– assertionFailure()
– preconditionFailure()
– fatalError()
Each of these assertions behave slightly differently and in the majority of cases the optimisation level that the code is compiled with has a direct effect on whether they are evaluated or not.
Update (2017-03-15): Previously: precondition vs. assert in Swift.
Language Design Programming Swift Programming Language
Ben Chatelain:
Currying helps to simplify these outlet and action test functions so that the view controller doesn’t have to be passed in every function call. Just like the sumA function holds onto the value of the first parameter, these test functions hold onto a reference to the view controller being tested. There’s also the benefit of being able to give the returned function a very readable name.
[…]
So, what is that hasButtonOutlet magic? It’s a partially-applied function saved in a local variable.
[…]
Shortly after @allonsykraken posted Hipster Swift, I learned that the super-clean syntactic sugar version of curried functions is going away in Swift 3 and it made me sad.
Cocoa iOS Mac Programming Swift Programming Language Testing
Alastair Houghton:
Having searched the Internet several times to find out how to get coverage
information out of clang, I ended up feeling rather confused. I’m sure I’m
not the only one. The reason for the confusion is fairly simple; clang
supports two different coverage tools, one of which uses a tool with a name
that used to be used by the other one!
[…]
In both cases, you need to pass the coverage options to the clang or
clang++ driver when you are linking as well as when you are compiling.
This will cause clang to link with any libraries required by the profiling
system. You do not need to explicitly link with a profiling library when
using clang.
C++ Programming Language Clang iOS Mac Objective-C Programming Testing
Benjamin Pollack:
I want to do two things in this blog post: convince you that Embrace, Extend, Extinguish is a grossly invalid understanding of Microsoft’s strategy; and convince you that an alternative strategy of Separate, Support, Serve provides a much better lens to view the modern Microsoft.
[…]
First, Microsoft has to enable me to even use Microsoft technology in the first place. If Microsoft keeps tying all Microsoft technology to Windows, then they lose. If I have to use Windows to use SQL Server, then I’ll go with PostgreSQL. If I have to use Windows to have a sane .NET server environment, then I’ll pick Java. To fix that, Microsoft needs to let me make those decisions separately.
That’s indeed the first phase of their strategy: separating Windows from the rest of their technologies. SQL Server is available on Linux not to encourage lock-in, but because they need you to be able to chose SQL Server even though you’ve got a Docker-based deployment infrastructure running on RedHat. .NET is getting great runtimes and development environments (Visual Studio Code) for Unix so that I can more reasonably look at Azure’s .NET offerings without also forcing my entire dev team to work on Windows. This strategy dramatically increases the chance of me paying Microsoft money, even though it won’t increase the chance I’ll use Windows.
Business History Linux Microsoft Windows
