I have no problems paying a bit more for quality apps, but either it’s pay upfront, or it’s highly unlikely I’ll subscribe to an app. Sorry, devs.
I don't believe this or the two comments on this story for a second. You're telling me nobody would pay $1-$2 a year for an app that costs $5? If you don't use it often, it's cheaper to have a full year to try it out [before putting it down].
Many apps are charging too much for their subscriptions. It's the "Cup of Starbucks Pricing Metaphor Fallacy" reversed. "Netflix charges $10 a month. so my subscription price should be in the ballpark. $4 a month is a steal for a subscription!"
No. $4 a month is insane for your app. Price accordingly. Microsubscriptions are the proverbial future.
And for expensive apps, well, MS Office and Adobe Photoshop have already shown the market doesn't mind subscriptions. And businesses have been paying for yearly subscriptions for years.
You can thank me for the MacBook Pro update, since I bought an Air on June 14th. It was too difficult to keep waiting, and most of my “if only” excuses were essentially removed during the Air’s 2017 update. The entry level got a slightly faster processor and 8 gigs of RAM on the bottom end, just enough to get by. And look at all the ways it’s better than a MacBook Pro…
SDXC card for cameras
A reliable keyboard
The last sticking point for me was the price. At $1000, it’s too steep. But Best Buy had a sale June 14th for the bottom of the line Air for $700 plus tax. You can’t beat that. That’s competitive.
You might recall my comparison of bottom of the line MacBook processors. Even after last month’s update, nothing’s changed there, at the low end. The MacBook Pro “Escape” 13“ still has a crappy i5–7360U, with a top-end only about 80% higher than the Air. The 12” MacBook is only 6% faster. None of these are speed demons. You’ve got to pay $1799 to get to the new processors in the latest refresh.
Neither step up from the Air are worth the price. The calculus said that I’m much better off spending $770 after tax on an Air, and putting the difference between the Air and Pro, even when the Escape was on sale at B&H for $1200 (which was tempting), towards a new desktop or a future MacBook. In a sense, I can get an Air now, and bank over $400 towards my next MacBook.
Heard a lot of my reasoning coming out of Marco Arment’s mouth on the most recent episode of The Talk Show. He basically said that laptops are optimized to run [predominantly] at a nice, low clock speed that sips power. You can get this low-power mode from an Air or the most powerful 15" Pro. Your compilations will suffer, but as I said when I talked about my $100 Lenovo S100, small computers with great battery life are a lot more useful than you’d think. Work on headless tasks in console apps (rather, make your tasks into many headless programming tasks), and you’ll be surprised how much you can get done.
Laptops – all laptops – are made for low power tasks. If you want as much power as you can carry, sure, max something out. But unless you’re okay with a “tall” gamer laptop (Marco actually talks about this) with the requisite fans and sorry battery life (hello, Lenovo Y700!), you’re not going to be able to cool your proc, no matter who you are.
At some point, I’d settle for a quality mini upgrade, which sounds like it could happen soon, but I’m hopeful the new Mac Pro will have an entry level that’s worth a look.
But you get the point. If I want portable macOS, the answer was and, I think, remains the Air on sale. It’s cheap, convenient, and reliable. Even after the update, it’s not worth paying $1000 more for a 8250U i5 and a Retina screen. Instead, I’ll pocket that cash and hope for something that makes sense later.
To date, the only thing I really dislike is that HDMI out is limited to 1920x1080. You have to use DisplayPort if you want higher resolution. This has been a Mac hardware limitation for a while that I’ve never really understood.
I'm kind of tired hearing that Apple is all about detail. Is their hardware impressive? Traditionally, yes -- even now, yes, minus one exceptionally depressive fail with their laptop keyboards & their inability to adapt with headless pro machines.
But here's a good example of where design simply isn't done in iOS, specifically the Contacts app.
Enter a new contact.
Enter a Company name, rather than a First and Last
Click + for adding a new phone number
Expected behavior: Since we filled in Company name, I'd expect "work' to be the default phone type.
Actual behavior: "home" is the default phone type.
That's a huge fail. We're in iOS 11, folks. How could someone not have added this by now? How many Contacts entries around the world have just a company name and just a "home" phone?
This reminds me of another Apple design fail I ran into (har har… keep reading to get the pun) recently... I went running one morning, but didn't have my Apple watch, so I carried my phone.
Later, I looked at my proverbial rings, and though exercise is closed at 32, my red ring is stuck at 147.
I realize the "Move Ring" keys off of stuff like heartbeats, which my phone won't capture, but believe me, once you're over, let's conservatively say, 6 miles per hour, it's clear you're moving, okay?
[Falling back to the runtime to bullheadedly access properties from objects out of any context from our code] is an absolutely valid way to implement property lookup, however it has one significant problem: if we pit our property lookup implementation against those used in modern JS VMs we will discover that it is far too slow.
Our interpreter isamnesiac: every time it does a property lookup it has to execute a generic property lookup algorithm, it does not learn anything from the previous attempts and has to pay full price again and again. That’s why performance oriented VMs implement property lookup in a different way.
What if each property access in our program was capable of learning from objects that it saw before and apply this knowledge to similar objects? Potentially that would allow us to save a lot of time by avoiding costly generic lookup algorithm and instead use a quicker one that only applies to objects of certain shape.
It's worth a full read. And once you've got how hidden classes, polymorphism, and megamorphism works, you could probably fall into exactly the same compiler optimization steps Angular's Tobias Bosch does in his video, above.
Here's a quick bit on poly/mega/morphism from the same source, as I once again save you from googling, one resource at a time.
If we continue callingfwith objects of different shapes its degree of polymorphism will continue to grow until it reaches a predefined threshold - maximum possible capacity for the inline cache (e.g.4for property loads in V8) - at that point [the] cache will transition to amegamorphicstate.
... In V8 megamorphic ICs can still continue to cache things but instead of doing it locally they will put what they want to cache into a global hashtable. This hashtable has a fixed size and entries are simply overwritten on collisions.
It's duck typing, all the way down, until you have too many ducks, at which point we default to a home-rolled bird almanac.
So this is impressively stand-up… I bought an SD copy of Killing Eve on the iTunes store for $2, just to see if I’d like it. It’s pretty good, and I might like to watch it all.
One of the reasons I like using iTunes for this sort of series checking is that I can pull a Complete My Season, putting the price of individual episodes towards buying a discounted whole season later, if I want. It encourages trying before you buy, which, ultimately, encourages buying.
But what if I want HD? Turns out Complete My Season has me covered. That $1.99 I spent on an SD episode unexpectedly can also be applied to an HD season purchase! The HD was originally $19.99, now $18 after a $1.99 purchase. SD was $13.99, now $12.
I mean, I guess that makes some sense. You can download the SD version when you buy the HD package, so the SD:HD::SD purchase::HD purchase syllogism works, but it’s still impressive to see.
I keep piling up TONS of stuff in Instapaper with the up-until-now mostly unfulfilled plan to catch up on these "important" articles that deserve some consideration later.
I never get there. I found myself wishing I could print out all my Instapaper articles as a [real, bound, paper] book.
Did you know Instapaper lets you export your stuff as ebooks and even a printable pdf (though the last keeps timing out on me)? The only thing I don't like so far is that the ebooks it creates only go back a little ways in my history. I guess I should catch up, archive things, then make another book. Or make a book, archive its contents, then make another.
But this is the killer feature for Instapaper. Put the content I want to read closely into a format conducive to close reading.
Now many of my articles are cut off, but that's a general issue with Instapaper. When it works, it works well.
(Not saying I'd recommend using Edge to read ebooks; just what was close at hand. Time to OneDrive them over to the iPhone, I suppose.)
At work this past quarter, wepainstakinglystarted three new projects at work. I say “painstakingly” becauseeveryproject required decisions to be made around tooling depending on the scope & needs.
Ultimately, the problem is thatby choosing React (and inherently JSX), you’ve unwittingly opted into a confusing nest of build tools, boilerplate, linters, & time-sinks to deal with before you ever get tocreateanything.