Evan Wallace:
I remember being very surprised when I first encountered modern vector editing tools. Many of the interactions felt broken. Why couldn’t you just manipulate things directly? Why did connecting and disconnecting stuff only sometimes work? Is this the best we can do?
The pen tool as we know it today was originally introduced in 1987 and has remained largely unchanged since then. We decided to try something new when we set out to build the vector editing toolset for Figma. Instead of using paths like other tools, Figma is built on something we’re calling vector networks which are backwards-compatible with paths but which offer much more flexibility and control[…]
[…]
A vector network improves on the path model by allowing lines and curves between any two points instead of requiring that they all join up to form a single chain. This helps provide the best of both worlds; it combines the ease with which points can be connected on paper and the ease with which geometry can be manipulated once it’s drawn. Splitting and recombining geometry is much more natural with vector networks. Delete anything, anywhere. Connect anything to anything else.
[…]
In addition to dragging the control handles, Figma’s bend tool (the command key on OS X) lets you drag the curve around directly.
Via John Gruber:
I have never been able to make heads or tails out of Illustrator’s vector design tools. (R.I.P. Freehand.) The Figma designers have come up with something truly novel — looking forward to trying this.
Figma Graphics Mac Mac App
Mark Bernstein:
But, back before they invented railroads, there were no time zones. And OS X knows this! So, before time zones were introduced, the local time doesn’t get shifted to the time zone. And, if your local time is one a different calendar date than Greenwich, you’re off by one day!
[…]
No one is going to anticipate bugs like this, bugs that depend on the invention of the railroad. TDD is great, but Coplien is right; you’re never going to get everything through testing.
Apple’s documentation policy attempts to tell you what you need to know, and no more. This gives Apple flexibility to improve OS X in small ways without breaking its implicit contract with developers, and keeps the documentation small. Here, though, the time zone behavior is completely undocumented.
Bug Documentation Mac Mac App Programming Time Tinderbox
John Martellaro (via Katie Floyd):
Apple’s Time Machine backup system was born in a time (2006) when Apple realized that customers weren’t routinely backing up their Macs. So a simple, stopgap system, with some novel features, was devised for the novice user. Unfortunately, over the years, the app hasn’t progressed and kept pace with modern user needs. Today, most every tech writer says: Use it, but don’t trust it completely. This is an unfortunate situation.
[…]
For example, Time Machine doesn’t, in normal operation, create a bootable backup of the internal drive. It can only restore a damaged (or new) internal drive from the Time Machine archive.
[…]
Next, there is no easily digestible, user accessible log file available for inspection within the Time Machine System Preference.
[…]
Finally, there is very little in the way of diagnostics or feedback to the user about the integrity of each backup. In other words, the user has no usable tools within Time Machine. that can be used to verify the integrity of the current backup other than a casual visual inspection. If a Time Machine backup gets hung up or mangled, most users are left in the dark and find themselves forced to start all over, regretting that a possible valuable archive needs to be overwritten.
Backup Mac Mac OS X 10.11 El Capitan Time Machine
Florian Kugler:
Now to answer the ultimate question, how do I get best performance with Core Data? Is the question that I can un-answer in the abstract. I think that your best bet is to look at the architecture, to understand this architecture, to really see how do these different layers work. How are their performance characteristics of these layers and then reason about your app’s behavior with this background knowledge. When you do that you can make the right choice for your specific project.
[…]
The advantages of the [nested contexts] set up are that if you save stuff from the main context, for example, the scenario I mentioned before, you copy in tons of data into your app, just copy paste and then you save. Now the save doesn’t block the main thread any more. Because the save of your UI context, only pushes all this stuff down into this private context that’s below. The private context can save this later. It’s one of the major advantages, and one of the major reasons nested contexts were introduced with iOS 5, where there’s iCloud syncing stuff.
[…]
Another disadvantage is that saving a child context pushes all changes down into the parent context. So before I said when you merge change, merge save notifications, Core Data can discard stuff because it knows it is not of interest to the other context. Now, with nested context, Core Data has to channel all this data down to the store, so it has to push all of this in. So if you insert 10,000 objects in the child context, Core Data has to instantiate 10,000 objects in the parent context, even if you don’t care about them there.
[…]
Another disadvantage is that you have no merge policies. When you work with nested context, you save the child context and all the changes are pushed down into the parent context with brute force. There is no consideration about conflict resolution, this is just a brute force push down into the previous context. It just overrides. Another pretty esoteric issue is that once you work with nested contexts you have to be aware there are weird things going on with temporary and permanent object IDs, and you can run into weird situations where you can break stuff like the uniquing guarantees that Core Data usually has.
Concurrency Core Data iOS iOS 9 Mac Mac OS X 10.11 El Capitan Optimization Programming
