Something I really loathe about OS X, and it has been becoming worse with time, is the amount of "processes" or whatever that suddenly take 100% CPU. There's no place to find out what they are. What are they doing, are they from apple or not? You're hopeless, aside from some comments here and there from random members of the community. To this day, I have no idea what 'powerd' is, for instance.
> To this day, I have no idea what 'powerd' is, for instance. You're in luck, there's an extremely helpful and well written man page on exactly that subject. I will quote in its entirety: "NAME powerd -- Daemon that manages Energy Preferences. SYNOPSIS powerd is a launchd managed daemon. DESCRIPTION powerd is a launchd managed daemon."
The Elephant at WWDC
151–160 of 213 posts
Re: The Elephant at WWDC
#152Earlier quoted context omitted.
I've found that the higher-level docs often don't even need to be writing per se. I'd stick things like the 3-5 minute overview video, 30-60 minute presentations, and code examples in this type of category. Who maintains these? Most development teams I've met never bother checking the example code works. 99% of the time, they'll write up a presentation, once, click "record" on the video conferencing software, and eve…
Extraordinarily strongly disagree. Documentation should be first, best, and most thorough in written form. It is easily searchable, easily transferred, easily scanned for relevant sections. Do anything else you want for your audienc3, but for me personally if there is not textual documentation, I will consider your system, software, library or whatever effectively undocumented.
Re: The Elephant at WWDC
#153Earlier quoted context omitted.
Apple's issue is that unless the code is open source, the documentation is the only thing available to the "outside of Apple" audience. If the documentation for the "outside of Apple" audience is not good enough without access to the source code, then developers feel it and the overall result is that Apple suffers as a platform.
Apple's issue is it doesn't seem to care. I'm going to speculate that improving the developer experience has a low status on the management hierarchy. So even if some people do care they're clearly not being given the resources to do anything about it. And the resources required are tiny. Technical writers are cheaper than developers, and you could hire a top team for $1m a year. Doubling that would still be a roundi…
There are other factors preventing improving it, because documenting a new project is effectively adding more people to the project team (even if they're "just" writers) and they still need to learn it by talking to the developers, who might not have the time, so it's not scalable. Third-party documentation scales by not being able to talk to those people and instead reverse engineering everything, but that would lead to embarrassing incorrectness if it was the first-party approach.
Re: The Elephant at WWDC
#154I just watched https://developer.apple.com/videos/play/wwdc2021/10166/ to learn about docC, and it looks pretty much like what folks have been doing in other languages for a long time. For example R developers usually document functions, data, etc using Roxygen in-line comments and they use vignettes for tutorials and the like. An additional advantage of R is that it checks that the documented function arguments line…
> it looks pretty much like what folks have been doing in other languages for a long time. It looks pretty much like what folks have been doing in Swift for a very long time. DocC is just Apple’s own version of Jazzy / SwiftDoc / appledoc. There’s no catchup here, it’s just Apple making an “official” version of something that already exists.
Re: The Elephant at WWDC
#155Conversely, I have noticed that Microsoft has been kicking some serious ass in the documentation arena lately. If you haven't taken a look at their stuff in a while, you would probably be shocked. Here's a high level overview of GC to give you an idea of how thorough these documents are now: https://docs.microsoft.com/en-us/dotnet/standard/garbage-col... After reading through all of those sections, I will have develo…
Even back in 2019 I was suggesting everybody to read API development design patterns from the Microsoft documentation. It was clean, neutral (not .net focused) and easy to understand. Microsoft under the new management has really turned around and become a “good” tech company (relative to google and Facebook).
Re: The Elephant at WWDC
#156Something I really loathe about OS X, and it has been becoming worse with time, is the amount of "processes" or whatever that suddenly take 100% CPU. There's no place to find out what they are. What are they doing, are they from apple or not? You're hopeless, aside from some comments here and there from random members of the community. To this day, I have no idea what 'powerd' is, for instance.
Re: The Elephant at WWDC
#157Conversely, I have noticed that Microsoft has been kicking some serious ass in the documentation arena lately. If you haven't taken a look at their stuff in a while, you would probably be shocked. Here's a high level overview of GC to give you an idea of how thorough these documents are now: https://docs.microsoft.com/en-us/dotnet/standard/garbage-col... After reading through all of those sections, I will have develo…
Literally 99% of anything I search for in Microsoft documentation these days lands me in a page where the only additional English text is the function definition with spaces added between the words! Entire APIs are 100% undocumented, at least in this sense. Security-related APIs are totally undocumented. APIs critical to disaster recovery are totally undocumented. I could go on and on.
It wasn't always like this! The C# standard library documented used to be fantastic, with multiple pages of text for pretty much every function. Now? It's hot garbage.
Let me give you an example. Not a contrived example of some obscure API that nobody cares about, but a "flagship" feature of dotnet core that was heavily advertised recently as a significant step forward in its capabilities:
System.IO.Pipelines
This is a complex, difficult to use API. How is it documented, you ask? There's a couple of out-of-date videos showing an earlier version that no long matches the current names. There's some announcement blog articles. There's one overview page that almost -- but doesn't quite -- cover enough to write a useful real-world application. The rest of the documentation reads like this: // Gets the MemoryPool to use when allocating memory.
public System.Buffers.MemoryPool Pool { get; }
(From: https://docs.microsoft.com/en-us/dotnet/api/system.io.pipeli... )I am enlightened! I understand now. Before that documentation page, I could not figure out that a getter called "Pool" returning "MemoryPool" returns a memory pool to use for memory allocation. But wow, that documentation really cleared things up!
I know I'm being more than a bit snarky, but it's deserved.
Microsoft's work is not GNU. It's not truly open source. It's not made by volunteers. MSFT is not a charity. In fact, their products in general are very expensive. I pay through the nose for this! I pay through Windows licensing. I pay through Azure hosting costs. I pay through Office 365.
What do I get for this money? Function names with spaces added.
> The best thing for me is that when I click the "Edit" button on Microsoft's documentation, it takes me directly to the latest markdown source file on GitHub and I can immediately submit a PR for corrections or enhancements.
That is the worst thing about Microsoft documentation. They've realised that they no longer need to allocate any budget at all to technical writers, because people like you will happily volunteer your own time to fix something you're already paying for with your actual cash money.
Stop.
If you're going to volunteer your time, do it for a charity. Write a Wikipedia article or contribute to Linux. Don't use your precious time on this Earth to help the world's second biggest company for no compensation whatsoever!
Re: The Elephant at WWDC
#158Conversely, I have noticed that Microsoft has been kicking some serious ass in the documentation arena lately. If you haven't taken a look at their stuff in a while, you would probably be shocked. Here's a high level overview of GC to give you an idea of how thorough these documents are now: https://docs.microsoft.com/en-us/dotnet/standard/garbage-col... After reading through all of those sections, I will have develo…
Microsoft has had superb documentation for decades. They put a lot of emphasis on it and the results show. The linked article is a bit off base, I think, because clearly Apple's documentation problem isn't a tool issue. It's a philosophy of documentation. I like going to the documentation for a critical system API class and finding all of the members, examples for each, and then "related" things. Philosophically Appl…
Not to mention that the Windows help system was better in the early '90s than the Mac's is today. Help on the Mac is a disgrace, which is why a lot of applications have just started delivering a PDF or doing all Web-based doc (which sucks when you're trying to work offline) instead of bothering with it.
Re: The Elephant at WWDC
#159Earlier quoted context omitted.
Right. And this would be so easy to fix too. a) crawl your own documentation and find dead links. b) monitor 404 errors and track down the source (via referer headers, etc.). c) ask the user on the 404 page what they were hoping for or provide a search menu, record it, and have someone manually review. d) add a redirect management engine, so you can redirect links that you can't/won't ever fix.
I'll write a crawler and get this done for CGA docs (Compute, Graphics and AI). Thanks for the tip.
I didn't mean to imply it was trivial, but the concept of crawling your own documentation is quite sound and should just be part of good document maintenance.
There are some plenty good crawlers already. I'm guessing one of them has a 404 report that could hopefully be used to find dead links.
Re: The Elephant at WWDC
#160From my perspective, I was in SWE at Apple for over a decade, their documentation started going downhill as iOS development ramped up. By the time they got to the yearly release cycle for macOS and iOS documentation was an afterthought. Most was generated with doxygen from inline docstrings. The reason I think the quality and quantity dropped was the internal schedules barely (or don't) leave enough time for the engi…
Explanations of design intent might be the most underrated kind of documentation. There's so little of that nowadays in general, in any technology. Personally, I blame shortened attention spans, the death of programming books, and the rise of Stack Overflow. I'm not familiar with the Apple ecosystem, is it really worse in this regard than others?