It's not a "deep dive" of the power adapter - it's part of a "deep dive" series of the laptop model, writing an article each about individual components.
51 karma · joined September 22, 2013
If all you do is use it for login and will never need to send a message, then fair enough, the email is just essentially a random string you can prove ownership of, and your ability to send messages that will be delivered to the corresponding mailbox is incidental. But that's not a general enough conclusion to hold for why "we" (all cases) should do it that way.
The two-axis diagram on diataxis is a great way to categorize documentation and all of them have different needs and indeed call for different voices. I have seen a number of projects where the only documentation produced is tutorials or itch-scratching posts for this one thing, and then when a feature changes somewhere you have a mountain of out-of-date information because everything was hard-wired to this combination of dependencies, versions and circumstances (whereas a manual could have been updated quickly and that would be that). And on the flip side, plenty of projects where there is a dense compendium for every detail and it's hard amid all the implementation details of the clustering gossip protocol versioning to find the little list of items you want to know to set the thing up to begin with - linked to the particular sections to read more about installation, configuration, backup, etc.
The strongest the README gets is saying "The LumoSQL and SQLite projects are cooperating", which is closer than any other effort I've seen, and welcome if the SQLite project ever wants to swap out the underlying storage engine, but doesn't really mean that the SQLite team "works on LumoSQL" or vice versa. Certainly it looks like LumoSQL has put significant work into the cooperation by using Fossil and by "not forking" which may have made the cooperation palatable.
Also, the SQLite project has been consistent on wanting to write all the code for SQLite themselves and not merge in patches (https://sqlite.org/copyright.html). Them working on another exploratory project would be a way for them to absorb those changes back into SQLite in a way that wouldn't be incompatible, but it would have to be the same team doing the changes for that to be consistent.
We are living in a world where it is more based in fact to assume that companies will help themselves to this kind of information under a variety of pretenses than that they won't. The only reason people will assume differently is if they trust the company, the product and the people behind it. The policy seems to be doing its part, but trust needs to be built by every conversation with a potential future customer. If the question that pops up is "how can I be anonymous if I pay you each month", the resulting argumentation should not be able to be construed as "we're sorry, but we're not going to help be your burner phone", which the comment I'm replying to is toeing dangerously close to.
People search for many things and it could detail their interests, their current location, their financial troubles. The commitment needs to be "we will never, never, never, ever, do anything like this", and not just "it doesn't make sense for us to do this". Because if someone wanted to build in that sort of tracking, it could "make sense" from a business standpoint to do this in that the data, if collected, has a lot of value on the market.
Even if the incentives are indeed aligned to keep the paying customer pleased, we also need to know that if we do walk away, that at that point there will not possibly be anything left as an artifact that a future buyer could do anything with. This assurance will be most effective if it's rooted in trust and values rather than in practical concerns; the practical concerns are valid, but only if they are restraints that have been applied in search of an objective by yourself, instead of "it is not currently in our business plan". (As an extreme example, consider a bank saying "we'd never pick items out of our customers' safe deposit boxes and sell them; it would simply be too much work".)
Basically, the facts seem reasonable enough. But you need to work on not coming off like the parent saying "well I'm sorry you want to hide things from me", which is what unprompted bringing up the covering up of criminal activity in response to questions of anonymity and privacy does. I understand that those concerns do come up in thinking responsibly about a product like this from all angles, but making it a part of a discussion with a potential customer disrespects and denigrates their fundamental needs enormously, the same needs that would make them attracted to the product in the first place.
Ken Kocienda's book Creative Selection has a very good chapter on the algorithm being built piece by piece, but finding out words being created by surrounding keys was part of collecting all the candidates.
They even used this in marketing. One of the pre-original-iPhone-launch videos was focused just on the on-screen keyboard (probably because almost everyone thought it was a really kooky idea at the time), and used the example of explicitly pressing "O-U-Z-Z-A" but still getting "pizza" as the autocomplete because it was the closest recommendation.
One of the iOS versions a few years ago became incredibly fond of including the space bar and considering alternatives with slightly off key presses near the space bar split into two or more words. When you're using a language with a lot of compound words like Swedish, this yielded some almost postmodern corrections with one or more words often completely different (but close on the keyboard, of course). I don't know if this was a tweak to the manual algorithm going off the rails or an AI version that wasn't quite tuned well yet.
No amount of work will make the inherently complex less complex, but doesn't have to be more complicated than it has to be. That's what "as simple as possible" means. If you have to peel down a strange interpretation of a problem or a misguided attempt to "dumb it down" before you get to the complexity, it's definitely more complicated. Over-simplification is pretending the complex doesn't exist, or chipping away at some parts until it looks simple, or straight-up disbelieving that there are complex needs and forgoing them.
I haven't read "Don't make me think", but I have read other books by the same author and his general message is that everything should be clear and approachable such that you can tell what things are and spend your energy actually solving the problem or accomplishing what you want to accomplish.
> The author of this piece (and perhaps the author of "Don't make me think", which I haven't read) respects only the simple desires of the majority of users. S/he does not respect the complex desires and needs of minorities of users, nor the potential for the majority-user to refine and develop their needs and desires.
This reading pairs poorly with this quote from the article: "And I’ve found that good products, ones that respect their users, give them more control." If the author really was out to knee-cap software, that's an odd sentiment to hold. I think you're in agreement with the author, but somehow take offense at the word "simple", maybe taking it as meaning "stripped down in function". There are certainly a lot of products, services, companies and people who take it to mean that.
I did not predict ARC. I'm not a genius, oracle, memory management expert or compiler writer.
I made a separate bet, saying that "they're working on a new language with these characteristics". For four years, this was an insane idea, they're not going to go all that trouble just to chuck Objective-C, I was mad and should be ignored. This week, that line of dismissal argument changed into "in hindsight, he was only stating the painfully obvious and anyone could have done that", which is nice and weird and a reversal fit for Steve Jobs.
That said, both Siracusa and I completely missed ARC, which is basically probably what made Swift worthwhile.
Regardless of that, a lot of details match (opt into it, side-by-side with C and Objective-C, compiler based on LLVM, not based on C, modern language, specifically made to match the frameworks).
I can't find a use case for telling the Mona Lisa that you have a dentist appointment or a pending call. You will probably have to pair with the device to get ANCS to start relaying notifications; iBeacons couldn't work if they had to require pairing.
With iOS in the Car, whatever they're using - probably AirPlay or something riding the various MFi (made-for-iWhatever) protocols - is already transmitting screen images. If they have a notification protocol like ANCS, they will probably not reinvent it, but iOS in the Car already involves several of their own protocols, so why use yet another connection - and if they do, why invent a new protocol and publicly document it for this use case?
Maybe it's about roaming notifications to OS X Mavericks, but there are no (revealed) commands for getting i.e. app icons.
Actually, whether they make a watch or not, it's very curious to see them introduce a new binary protocol in the open. If this is a turn towards being more open, I welcome it. It's far from enough, but it's a start.