> 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.

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.

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.

This was before that, early to mid 90's era

I still don't know what an app server is. Isn't that one of those things from the enterprise programming era where they'd get "architects" to design an "enterprise system" and it would come with twenty different things with names like "message bus" and "dependency injection" that no program in history has ever actually needed?

In case you are honestly interested--although your hyperbole suggests otherwise--an app server then was what the docker daemon (or podman or other container launcher) would be now. The two most common in my career were JBoss and Tomcat. Since Java packaged applications into Jars which could be run anywhere (up to environmental assumptions made by developers), you could simply scale up by sending these jars to the app servers to run. Actually, the Alibaba group was quite annoyed in the JCP that western members had given up on these aspects of the Java platform and were moving to support containerization. Arguably, CGI servers for php/python etc. were also a type of app server, although I rarely heard them referred to as such. App servers standardize what it means to start an application which makes operating many applications much easier.

Message buses were generally in memory or in process streaming brokers. Most of these have moved externally today via Kafka, RabbitMQ or cloud proprietary versions like SQS. Some people may lean on ZeroMQ to build similar behaviors when doing multiprocessing and some people may even do it in process if they like the api. Definitely very much part of large scale application development today although the terms of art have changed.

Dependency injection is just a fancy name for polymorphism via fields in your struct, although if you have too much exposure to spring you will associate it with that plus an inversion of control on the actual injection part: that is, you will associate it with heavy use of annotations. If you have polymorphism with a switch (or chained ifs) on a parameter, you don't have dependency injection but if you have polymorphism by having different inplementations of a field of your struct then you are doing dependency injection. Very much part of good software design today, the annotation driven wiring possibly not so common outside of Java + Spring.

I think of dependency injection as a generalization of LD_PRELOAD, the point being that the "injection" is done via configuration that is external to the application's code.

That's a good take, I hadn't really thought of that one before and I had certainly used LD_PRELOAD or some incarnation thereof (forgive my memory is was more than a decade ago) to swap out different implementations of the same API.

> In case you are honestly interested--although your hyperbole suggests otherwise--an app server then was what the docker daemon (or podman or other container launcher) would be now.

Sure. I have worked on JVMs before, but not server side, and I never had to touch anything sold by IBM.

> Arguably, CGI servers for php/python etc. were also a type of app server, although I rarely heard them referred to as such.

No, I think there's a difference. The deployment story for PHP was that you copied it to the web server and that was that. The mandatory part was a webserver you had anyway. There is FastCGI, but in PHP's case it can be thought of as purely a cache and is not necessary.

> App servers standardize what it means to start an application which makes operating many applications much easier.

A PHP web app does have some moving parts like needing to start nginx/fastcgi/mysql, so in that sense it still needs a container.

But the difference between the PHP source itself and Java is that PHP is 1. stateless and 2. doesn't take nearly as long to start up.

The first one is the big one and means you don't need to restart anything to update the app. This part of PHP is so well designed it practically makes up for how bad the rest of it is.

The second one was more of a Java flaw; the runtime is undercooked (which is why it had all that other super complex stuff on top of it) and everything has to go on the heap, instead of having more of a concept of constant data that could just be mapped in from the binary/jar file. That's what they got for not adding value types I guess.

The Kubernetes of the 90s and early aughts

During the Ballmer era MSFT was famous for the lack of cooperation between and within teams. That's what you get when you use stack ranking to decide compensation.

Microsoft's documentation for Microsoft's own technologies (as in, the C# libraries they provide) is terrible. What's the competitive advantage there?

That is not true in my experience, Windows API is superbly documented and C# docs are of far higher quality than Java's

The C# documentation was, at least in its initial years, very good. It even had working examples that demonstrated functions. Compare that to typical javadoc of its time.

MS documentation used to be amazing back when I programmed for Windows. It was one of the hardest parts of moving to Java for me.

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)

>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.

Maybe it's there to prevent desyncing errors that occur for long strings of zeroes. Information theory isn't the only possible consideration.

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.