MilStdJunkie

Is it evil of me to say that 7.2m a year (109000000/15) is not really doing that bad?

Honestly, I think a pretty good pyramid scheme a la the Mikkelson Twins would be to start up a wholly imaginary "MIL-SPEC SCAMMER SCHOOL" that tells you all about people like this lady, and offers a course on HOW TO NOT DO SUCH BAD THINGS, while winking with every muscle in your body.

Or, even better, advise you on how to be a big time MIL-SPEC guru who can lead SIGMA or whatever other nonsense the management of the day is huffing. This advise is your key to landing BIG WORK in the Defense Industry! Everyone knows it's all nonsense, but we can teach you how to turn that nonsense into passive income.

Of course such a fabulous class would cost beaucoup buxxx....

Ah, this sounds heartbreaking. I'll leave it to those salesmen with mental sickness.

I guess it makes a sort of sense. Eyes sense photons, touch detects physical force, tongue and nose give useful attributes of chemical properties, and neuron clusters adjudicate probability, the navigation of all the possible paths for the organism. "This happens when you go there, go here instead"

Ah, I'm a dummy. Of course these would be binaries getting chucked around.

It's hard to localize. Early Postscript - PDF software was the wild west, particularly when it comes to the text streams. Something I've noticed is that they're used a LOT in things like randlists (bullet lists), tab leaders, other "space that isn't a space".

I'm reminded of how you have to use `{empty}` character refs in lightweight markup like Asciidoc to "hold your place" in a list, in case you need the first element in the list to be an admonition or block. Like so:

  . {empty}
  +
  WARNING: Don't catch yourself on fire!
  +
  Pour the gasoline.

And the equivalent XML which would be something like

  <procedure>
    <step>
      <warning> Don't catch yourself on fire!</warning>
      <para>Pour the gasoline.</para>
    </step>
  </procedure>

This is one of those rare cases where the XML is more elegant than the lightweight markup. That hack with `{empty}` bugs me.

Anyways, I'm spitballing that these old-timey nulls I'm seeing are being employed in an equivalent way, some sort of internal bespoke workaround to a format restriction.

I mentioned it in a separate parent, but null purge is - for the stuff I work with - completely non-negotiable. Nulls seem to break virtually everything, just by existing. Furthermore, old-timey PDFs are chock full of the things, for God knows what reason, and a huge amount of data I work with are old-timey PDF.

Holy smokes. I'm no programmer, but I've built out bazillions of publishing/conversion/analysis systems, and null purge is pretty much the first thing that happens, every time. x00 breaks virtually everything just by existing - like, seriously, markup with one of these damn things will make the rest of the system choke and die as soon as it looks at it. Numpy? Pytorch? XSL? Doesn't matter. cough cough cough GACK

And my systems are all halfass, and I don't really know what I'm doing. I can't imagine actual real professionals letting that moulder its way downstream. Maybe their stuff is just way more complex and amazing than I can possibly imagine.

Yeah, that's via an OTA, which is basically - comparatively - free money. It's not a PoR (Program of Record). PoRs are where (many naive people think) all the money is. All those people are incorrect. It is, however, the PoR which will ruin your goddamn business when you sign it. Congratulations, that is now all you do.

A company like Google (or Apple for that matter), with their own freewheeling project systems, would rather jump into an olympic pool filled with razor blades and used condoms before taking any amount of money from the hellish morass that is the defense procurement system. The instant you enter the MIC, kiss goodbye to any of your internal business systems - you will be re-writing the way you work every second of every day. And not for the better, I might add. I think Google looked at the costs of that, looked at the contract, and said, nah, thanks, I'm good. Then went back to feeding NSA/NRO for black money delivered by men in coats.

Of course, now, post-ZIRP, things are a wee bit different.

GitLab on-prem is way, way, way more elegant than trying to get GitHub on-prem working. One of the things that makes me go, "Gah?" is that, well, Atlassian is more or less abandoning on-prem Bitbucket going forward. Perforce is, well, Perforce. Niche VCSs like SVN are rapidly getting impossible to keep running on modern platforms. All this really does seem to leave the field of "small to midsize companies who can't cloud" entirely to GitLab.

Which, I guess, says something about how expensive it is to run support for on-prem enterprise software. But that doesn't feel like an unsolvable problem, not with a customer field this rich. On-prem focused orgs tend to have wads of cash stuck up in them.

What a loss. Killer Elite was one of my favorite modern pieces of war reporting. Wright didn't let the hilariously dystopic "embedded" rules muzzle him or intimidate him - no, he went to play bullet dodger with Marine Recon. A lot of other press, the embedding worked like it was supposed to and kept them well to the rear.

His true crime is a similar round of WTFs, like when you learn about weird CIA crap for the first time, but over and over again.

Mental note to watch the TV series - that somehow passed me by.

Seat? I would have blown out a whole new access panel in the belly of that flivver with the sheer force of my terror.

The few times I've been in bush flights over terrain, it's always felt like the man upstairs is punching my dance card. When I'm feeling brave I'll sometimes ask pilots about it, and sometimes they're like, yep, feels that way flying too - that's why I love it!

> And most documentation systems are far easier adopted by people other than engineers.

Whew, gonna have to have a hard disagree with you there. DaC is several times - nay, orders of magnitude - less complicated than standing up a S1000D, a DITA, or even a DocBook publishing system. For anyone.

Count the layers of configuration.

S1000D, you have to worry about issue (which has zero compatibility, and the Technical Steering says they have zero intention of releasing any guide to matching the different issues up), you have to worry about BREX, then you have to worry about bespoke DMC schemes, and then you have all the many ways the PDF or IETM build can get built out to Custom Solution X, since the TS/SGs offer absolutely bupkiss for guidance in that department (it's a publication specification that doesn't specify the publication, what can I say?). The DITA side's not a lot better: you have multiple DITA schemas, DTD customization, specialization, and you have a very very very diverse batch of DITA-OT versions to pick from, then on top of that you have the wide wide world of XSL interpreters, again with very little interplay. DocBook is probably the sanest of the bunch, here, but we're still going to be wrestling with external entities, profiles, XSL, and whether we're doing 4.X or 5 or whatever is in DBNG.

Not to mention all of this stuff costs money. Sometimes a whole lot of it. Last time I shopped round, just the reviewer per seat licenses for the S1000D system were 13k per seat per year, the writer seats were over 50k per year.

DaC, on the other hand, I want to get re-use and conditionals, so I get Visual Studio Code. I get Asciidoc. I get some extensions. I get gitlab, set up whatever actions I want to use, set up the build machine if I want one, and if I'm feeling adventurous, Antora. I'm literally writing an hour later. I'll probably spend more time explaining to the reviewers what a Pull Request is.

As a pretty die-hard enthusiast for this approach - even for legacy, hard industries - let's take a close look at some of the limitations of this approach.

First, code is formal language, and docs are natural language. That's a lot of jargon; what does it mean? It means that the chunks inside of a piece of code are consistently significant; a method is a method, a function is a function. Chunks in a document are, woo boy, good luck with that one. XML doesn't even have line breaks normalized. Again, no matter what the XML priesthood natters about, it's natural language.

A consequence of this is that the units of change are much, much smaller in a repo of code vs a corpus of documents. This, well, is can be ok, but it also means that a PR in a docs as code arrangement can be frickin' terrifying. What this means, is that you have to have a pretty good handle on controlling the scope of change. Don't branch based on doc revisions, but rather on much more incremental change, like an engineering change order or a ticket number.

Your third problem is that the review format will never - can never - be completely equivalent to the deliverable. The build process will always stand in the way, because doing a full doc build for every read is too much overhead for basically any previewer or system on the planet. This is a hard stop for a lot of DaC adopters, as many crusty managers insist that the review format has to be IDENTICAL to the format as it's delivered. Of course, that means when you use things like CIRs (common information repositories) that you end up reviewing hundreds of thousands of books because an acronym changed....but I call 'em "crusty" for a reason. They're idiots.

Also a market for putting a more doc-focused UI on git, integrating that too[1]. Pull Requests are basically gold for doc review, but the process of getting to the PR is something that always seems to need a bit of training. Nothing like the training that's needed to grok the basic graph-based change model, and how it's going to work for natural language (ish) documents, but that's a whole other kettle of fish.

[1] GitLens comes pretty close to this, however.

Lots of DaC shops use feature flags for their conditional content. "Conditional Content" is a huge hobbyhorse in component content, because you need conditionals to re-use chunks. How else could the chunk be made applicable to multiple people? In doculandia, it's more common to run into conditional handling that's inline with the document markup - ifdef/ifeval/ifndef in Asciidoc, some stuff in Jekyll, S1000D applic, DocBook profiles, DITA class/ditaval - but I'm not one hundred percent sold that's a solid practice. Moving conditionals into the document layer might have been a mistake. I dunno! I'd love to kick off a conversation.