jamougha

Namespaces are horrible in Python because the Python XML libraries are deficient. They're generally fine in e.g. Java. (Unless you're trying to represent QName typed data, but that's very niche.)

Kubernetes used to be hard to set up from scratch. Recently we had to set up a new cluster and it just worked with very little faff.

I can read Scala fine but I'd like fast compilation and good IDE support.

The tests are ineffective. That's because, as the article notes, unit tests - tests of single functions, with dependencies mocked - give very little confidence that code actually works. Problems usually appear in the relationships between parts.

And because they're tightly bound to the internal implementation of the code they test the tests often have to be rewritten when the code is rewritten.

Does this mean unit tests are bad? No. They way they're frequently used I believe they are bad, but you're correct that that wasn't the point I was making. I'm really commenting on the way that common wisdom pushes gimmicky methodologies but doesn't talk about the fundamentals of how to make code changes in an effective way.

We have a new guy at work who loves unit tests. Yammers about them constantly.

If he's working on a feature that needs changes to classes A, B and C then his workflow is: make all the changes to class A, along with lots of unit tests. Then do the same for class B. Finally, do the same for class C. And then, after days of work during which the application doesn't even compile, he runs the integration tests and discovers that the application is broken.

Then someone comes over and rewrites his code so it works.

My company tried using Swarm 2-3 years ago and ran into the problem that it didn't actually work. Containers would just go missing from the network. Consequently we switched to Kubernetes. I imagine it does work now but it seems to be too late.

I've recently started using Kompose to autogenerate Helm charts from docker compose files and I've found that pretty satisfactory.

CO2 emissions from international flights will be capped at 2020 levels by international agreement so supersonic flight will have no net effect on emissions.

https://www.icao.int/environmental-protection/Pages/A39_CORS...

Ocaml has a GIL. I've worked with people trying to build a distributed system in a language with a GIL and do not recommend it.

In principle yes, it was intended for general business reporting.

Essentially each filing (called an instance) consists of a series of 'facts', each of which reports a single value and some metadata, and footnotes, which are XHTML content attached to facts. Fact metadata includes dimensions, which can specify arbitrary properties of a fact. So a fact might be e.g. 'profit' with metadata declaring it's in 2018, in the UK, and on beer, but all of those aspects would be defined by a specific set of rules called a taxonomy. You can create a taxonomy for any form of reporting you want.

There's also a language, XBRL Formula, which allows taxonomies to define validation. It allows something semantically similar to SQL queries over the facts in an instance, with the resulting rows being fed into arbitrary XPath expressions.

Unfortunately the tools for working with XBRL are mostly quite expensive, which probably limits its application outside finance. Arelle is a free and fairly standards compliant tool that will parse, validate and render XBRL and even push the data into an SQL database, but it's written in Python and isn't very performant. (Although it's probably good enough for most uses since it's used as the backend for US XBRL filing.) I'm not sure if there are any open source tools to help with creating instances.

Also creating a taxonomy itself is quite challenging. There are (expensive) tools to help, and using them it's still quite challenging. For real-world taxonomies it usually involves a six or seven figure payment to one of the few companies with the right expertise.

Storing large objects in database rows impacts performance and scalability but this shouldn't be a problem unless your files are extraordinarily large.

There's a fairly large ecosystem of tools for creating and processing financial data in XBRL which doesn't exist for SQLite. All the Big 4 handle XBRL already - I know because I write the software they use. It's quite straightforward to take a Word document, for example, and turn it into XBRL; we even use machine learning to automatically tag the tables.

I can easily imagine how painful it is for you to process XBRL from scratch, but it's not crazy to exploit the existing infrastructure.

Of course if you give a project to IBM I wouldn't be surprised if it costs a billion dollars, especially given they know roughly nothing about XBRL...