jacques_chester

Also Gomponents, a similar project for Go: https://www.gomponents.com

> There were create/read/update/delete service functions that clients used instead.

Oh! I haven't seen this pattern in a long time - not since I worked on Oracle Application Express apps. In a cousin comment I noted that the bulk of app developers don't think about how to use the database to their advantage.

You're correct, I overlooked triggers. Though that may be a bridge too far for some folks, triggers are only really comfortable for folks who are deep on RDBMSes. For lots of app developers the ORM is the limit of the world.

This description isn't too far from bitemporal tables, which are one of my favorite obscure technologies.

I think though that one distinction is that immutability in this case requires cooperation from the client, a commitment not to modify existing records. As compare to the database enforcing it.

Trademarks are namespaced by subject matter.

> It is a clean abstraction

Ah, that must be why I see FooMethod and FooMethodAsync side-by-side in C# all the time.

> If you have the hardware resources, why not just scale up from the beginning on?

For most workloads it's wasteful to have max capacity provisioned at all times if you can instead provision on-demand.

This is true in general. For example, electricity supply is a mix of baseload power (cheap but only if left running constantly) and peaking (expensive but easy to turn on and off). It wouldn't be economical to have baseload capacity equal to maximum demand. Instead it is aimed at minimum demand and other sources make up the difference depending on demand.

Please no.

"Infrastructure", which includes z mainframes (called out by name) and I assume iSeries also (though not called out), is the smallest segment of IBM's revenue.

See page 17: https://www.ibm.com/annualreport/assets/downloads/IBM_Annual...

The lawsuit hasn't been brought precisely because IBM fought tooth and nail to cut off access to the courts.

Not the sort of thing you do for the hell of it.

I think the parent comment may be a reference to IBM being caught in the past deliberately firing older workers.

No need to hypothesize about how it would work. Australia uses pen and paper for elections. It works fine.

GitHub has the advantage of a low barrier to entry for their tools. A lot of their features are inferior to special-purpose tools, but they can expect high usage because a lot of users shrug and live with it.

His point was they'd only done a small set in Excel as a POC. It's plausible that with an O(2ⁿ) algorithm you'd be looking at this kind of thing.

Pivotal Tracker does something like this with release markers. You can set markers between any two stories and, optionally, set a date. Tracker does a very simple moving average projection and if the stories before the marker will take too long, it turns bright red.

I found it remarkably effective at getting business folks to actually prioritize. They don't believe you, but they'll believe the computer.

I find that economics is drenched in maths, depending on the school. Take Chicago's undergraduate program, for example[0]. It requires calculus classes before you even get to the starting line for the economics classes, and they encourage students to go further: "Students who have an interest in the major should take calculus at the highest level for which they qualify."

[0] http://collegecatalog.uchicago.edu/thecollege/economics/#Fun...

> the Don't Repeat Yourself principle

I think this is meant mostly to apply to code. For data, redundancy is a very common strategy for assuring accuracy and durability.

> If you say the same thing in two different places, one of them is always going to be wrong.

Yes! This is the exact point. The mismatch flags that there is an error that needs to be investigated and added to the ledger as a correcting transaction.

Speaking of history, I learned that the word "control" comes from contra rotulus -- roughly "checking against the wheel", which was apparently from an early medieval device for keeping tallies. The second meaning of "domination" came later.

Interestingly I sort of went in the other direction at one point -- converting what was obviously a graph (build pipelines) into a from-to / credit-debit representation. On reflection it's just an edge list.

My main problem with adapting the representation was in the incommensurability of different kinds of asset moving through the pipeline. How does one credit source code and debit a blob store? I thought about learning more about multi-currency accounting as a source for ideas but never followed it up.

That effort inspired my thinking about a "Universal Asset Graph" for software[0] -- keeping track of not just containment but also movement and transformation of software. It's a partial but not complete inspiration for GUAC, which aims to capture software part relations for easy querying.

[0] https://theoryof.predictable.software/articles/some-requirem...

[1] https://guac.sh

> Several informants described great software engineers as hardworking: willing to work more than 8 hours days to deliver the product. This typically meant working longer days, during weekends, and/or during other free time in order to accomplish goals. Informants believed that, at a minimum, software engineers needed to be willing to work beyond normal hours immediately prior to ship dates in order for the team to successfully deliver the product

What I'm getting from this is that Microsoft is a terrible place to work.

Schedule failure is a management fuckup. Expecting the line engineers to fix it is completely backwards.

I think you're thinking of the Builder pattern. That's a bit different, because you return the same type and same object on every chained call.

A possible match would be the Typestate aka Type State pattern.

For some reason I only see Rustaceans talking about it, though it's perfectly applicable in any language with static typing.

I'm an atheist, for what it's worth.

If it helps, substitute "Darmok and Jalad at Tanagra" instead.

It doesn't eliminate all toil, but it eliminates a lot. At least their customers think so.

He might have pinched it from Watts Humphrey, who pointed out that the earliest estimate is the most valuable, but the last estimate is the most accurate.

Bent Flyvbjerg calls (2) the "sublime". He points out that disastrous megaprojects get authorized because folks with the money and authority simply ignore the haters.

https://en.wikipedia.org/wiki/Bent_Flyvbjerg#Megaproject_pla...

Not at Chainguard but I've watched their growth.

I think this comes down to audience. To a lot of engineers it's just like ... "OK, that's nice. What else?"

But for security teams in large enterprises, Chainguard is like manna from heaven. They immediately understand what is really being sold: the elimination of enormous amounts of compulsory toil due to upgrading vulnerable software -- or having to nag other teams to do it.

It's a bit like visiting the site of a medical devices manufacturer. I probably don't know what the device does, but the target audience sure do.

Chainguard is proof that modern CI/CD is still a luxury product for most of the industry. They have a fantastic amount of automation behind image production, including some tools they rolled themselves (like apko).

Disclosure: I am friends with / have worked with some Chainguard folks.

The example of performance is interesting because as you say, there are often multiple jostling distributions under the surface (GC is one, but another doozy is CPU frequency scaling).

One possible way out is to look for measurements that contribute to running time but which are not affected by other factors. I remember the YJIT folks talking about using CPU instruction counters, but I can't find it on the benchmark website.

I have enjoyed a different experience of software development: the team breaks down stories into units of roughly equal complexity. Bugs get fixed first and do not contribute to velocity.

Over a medium time frame I've seen this approach produce remarkable stability in velocity measurement.

Note that this works by allowing product priorities to fluctuate, but not allowing quality to be a dial that can be turned. A distressingly rare configuration of power.