Comment by ChuckMcM
2 years ago
From a hardware standpoint third party fitness trackers with full integration into iHealth and third party ear buds with the same (or better) features than airpods.
Part of the IBM settlement required them to document interoperability. That was used by the DoJ to force Microsoft to document their CIFS (distributed storage) and Active Directory (naming/policy) protocols.
The latter might be particularly instructive as my experience with CIFS when I worked at NetApp was the different ways that Microsoft worked to be "precisely" within the lines but to work against the intent. Documentation like "this bit of this word must always be '1'" Which as any engineer knows, if it really was always '1' then that bit didn't have to be in the protocol, so what did it do when it wasn't '1'?
> From a hardware standpoint third party fitness trackers with full integration into iHealth and third party ear buds with the same (or better) features than airpods.
As someone who makes apps in the health space, I couldn’t care less if other tracker data was integrated into HealthKit. HealthKit honestly sucks - it's some bastard of objc naming schemes and methods jammed into Swift. The async is horrible to debug, too. No one has a good time in HK.
The issue with other trackers is that they are more locked down than Apple. You can't just get HR from Oura for instance - and that's not a health kit issue either.
The reason you can't get heart rate data from Oura is that they don't want people looking at it except in aggregate, because then they would notice the accuracy problems and data gaps.
[dead]
I had a similar experience with MSFT docs when working at Sun. The docs were not very good, and though they seemed somewhat redacted, it felt like in fact their internal docs probably weren't much better.
Don't tall into that trap of thinking.
Many years ago I knew an ex-microsoft engineer. Microsoft had poor interoperability with something, and I speculated that engineers in microsoft didn't know what 3rd parties were doing and accidentally broke things.
He told me, "don't be naive - microsoft would have meetings saying 'how can we own this?'"
Not to cast doubt on your friend's story, I worked on both the SQL Server team and later on the Windows kernel team in the early 2000s (the bad years). I came from "outside" meaning I had already had a career at non-Microsoft-related companies (mostly startups using linux on the server). I was continually shocked at how _little_ the MSFT employees seemed to know about the industry, or how their customers used their own products.
As an example, this was the era of the J2EE App Server. Almost none of the people I worked with knew what an App Server was, despite the #1 database in use by App Server customers being MSFT SQL Server.
8 replies →
Microsoft's documentation for Microsoft's own technologies (as in, the C# libraries they provide) is terrible. What's the competitive advantage there?
3 replies →
>Documentation like "this bit of this word must always be '1'" Which as any engineer knows, if it really was always '1' then that bit didn't have to be in the protocol, so what did it do when it wasn't '1'?
Maybe it was a deprecated part of the protocol, and setting it would cause an error or do nothing.
Or it could be a placeholder for future expansion and while it would do nothing now, in the future it might break things if you've ignored the documentation.
If you design a protocol without at least one field reserved for future expansion you are a bad engineer. Generally I would call this the protocol version number field, but there are other options. The important thing is there is some field that currently has a defined range, but can get an a larger range in the future and you check that field and abort if it is out of range.
I also recommend a second field called protocol ID which is set to a known random value (your wife's birthday) so that if someone gets an unknown message if they see that value they can guess what the protocol is.
Maybe it's there to prevent desyncing errors that occur for long strings of zeroes. Information theory isn't the only possible consideration.
I'm not a developer in this space myself, but my impression is that HealthKit is one area where 3rd party apps have access to the same data as 1st party apps.
Reminds me of Bob Colwell's talk, although it's not from the same angle: https://youtu.be/jwzpk__O7uI?si=NZmfU6av_2D-uPgk (around 1:04:10)