Alexander S. Kunz:
And then I found the blog of Bruce Percy, who says “Good edits come from improved visual awareness”, in his “Good printing means good editing“ blog post. He also writes: “You can’t make a good print from a badly edited image, and likewise, you can’t make a good edit without printing it to evaluate it.“ – I concur!
[…]
I also noticed that most of my photos were developed too bright. The “expose to the right” technique mislead me (I try to expose as bright as possible without blowing the highlights, and as a result, some of my photos are very bright when I first import them into Lightroom). I’ve learned to consider more consciously what and where the individual tones are, based on the histogram. Lightroom’s separation into Blacks, Shadows, Exposure (midtones), Highlights, Whites helps with that. If an area that should be entirely in the midtones responds to moving the Highlights slider, then perhaps something is a bit off, and it’s “Exposure” that needs an adjustment.
[…]
Resolution isn’t that important either. With the 18×12″ (45x30cm) prints that I can produce at home, even a good 6 megapixel photo will print fine (it’s still ~160 pixels per inch).
[…]
I would have started this much, much sooner in my photographic career.
Adobe Lightroom Mac Photography Printing
joely:
When I began using PDFKit, in the the days of Tiger and Leopard, there were a number of sample apps which helped me learn the framework: PDFKitViewer / PDFKitLinker2 / Link Snoop / PDF Calendar / PDFViewSubclasser / PDFAnnotationEditor
But through the accumulation of deprecated APIs over nine builds and, especially, the pervasive breakage in the macOS 10.13 High Sierra rewrite, they broke and faded into obscurity.
These samples showed interesting aspects of PDFKit. Beyond PDFKit, they highlighted significant aspects of Cocoa. And they’re incredibly well-written – readable and well factored! I just felt it would’ve been a shame to let them fade away!
However the port to iOS – “PDFKit reloaded” (sorry Keneau) – has brought PDFKit into its own! And macOS will be a direct beneficiary of that! This gives me confidence that the framework, which had been allowed to stagnate, will now receive true support! So I thought it would be propitious to make those “lost PDFKit samples” usable once again. And as an exercise, I’ve updated their projects from Tiger and Leopard to build and run in High Sierra.
Mac macOS 10.13 High Sierra Open Source Programming PSPDFKit
Philip Walton (via Hacker News):
Modern browsers today will sometimes suspend pages or discard them entirely when
system resources are constrained. In the future, browsers want to do this
proactively, so they consume less power and memory. The Page Lifecycle
API, shipping in Chrome 68,
provides lifecycle hooks so your pages can safely handle these browser
interventions without affecting the user experience.
Philip Walton:
As I was doing my research for the article, I found a lot of things that really surprised me. And I feel pretty confident in saying that most web developers aren’t aware of these things either.
Here are my top four:
- We shouldn’t use the unload event. Ever.
- The unload event often doesn’t fire when closing tabs/app on mobile
- The pagehide/pageshow events even exist (virtually no one I’ve talked to knows what they do; most people think they’re about page visibility).
- In browsers that implement a page navigation cache, you can click a link to navigate away and then navigate back with the back button, and all your JS code is exactly as it was before you navigated.
Google Chrome iOS JavaScript Mac Optimization Web
Benjamin Mayo:
On iOS 11, pressing share meant waiting several seconds for the activity view controller to start rising up from the bottom of the screen. On iOS 12, the sheet displays instantly. Or at least, the appearance transition is instantaneous. The share sheet lazily loads the contents of its rows, so the OS feels responsive even if it hasn’t quite finished gathering all the third-party extension information that it needs. Occasionally, the sheet pops up and both the bottom rows are just displaying loading spinners. A beat later, the app icons and actions pop in. I assume this happens more often on slower hardware. Regardless, the difference is night and day.
I hope this focus on performance continues in iOS 13 and beyond.
Update (2018-07-31): scott:
I was pretty surprised at the performance gains had by iOS 12 Developer Beta 1, but every beta since has gotten slower, and buggier, and significantly so. Apple must have been cheating somewhere with the first beta, because at this point performance is just as bad as iOS 11.
Dan Masters:
Yep. I’m having the low RAM issues again
Update (2018-08-03): Matt Birchler:
Guys…iOS 12…
It freaking rocks! Seriously, I’m using it on my iPhone and iPad and they just feel like they’re lightning fast and the feature additions to the platform extends its lead over Android IMO.
iOS iOS 12 Optimization
Mitchel Broussard:
Five months after performing a test that put the smart speakers of multiple companies in the spotlight to determine how well they performed in various categories, Loup Ventures is back today with an IQ test focused entirely on digital AI assistants. To get the necessary results, the researchers asked Siri, Google Assistant, Alexa, and Cortana 800 questions each on a smartphone, and compared their findings to a previous AI test held in April 2017.
[…]
In total, Google Assistant answered 85.5 percent of the 800 questions asked correctly and understood all of them, compared to Siri’s 78.5 percent answered correctly and 11 misunderstood. Alexa correctly answered 61.4 percent and misunderstood 13, while Cortana was the “laggard” and correctly answered 52.4 percent and misunderstood 19.
They found that Siri has improved a lot. However, I don’t think that accuracy is necessarily the most important metric. The main problems I have with Siri are its (lack of) availability and slow speed.
Alexa Cortana Google Assistant iOS iOS 11 Siri
