> If your application also runs NFKC normalization (which it should — ENS, GitHub, and Unicode IDNA all require it)
That's not right. Most of the web requires NFC normalization, not NFKC. NFC doesn't lose information in the original string. It reorders and combines code points into equivalent code point sequences, e.g. to simplify equality tests.
In NFKC, the K for "Compatibility" means some characters are replaced with similar, simpler code points. I've found NFKC useful for making text search indexes where you want matches to be forgiving, but it would be both obvious and wrong to use it in most of the web because it would dramatically change what the user has entered. See the examples in https://www.unicode.org/reports/tr15/.
Is the goal to make good ORM queries easier or to prevent bad queries? It's not clear there's really a compiler solution to the latter. If you're inside a loop in which a database cursor is in scope, then further database queries are prohibited? It's hard to see how that could be enforced other than something like What Color Is Your Function (https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...) with some functions marked as making queries and others as not.
To solve this, maybe instead best practice would be to ensure the database connection is not in a global variable and must be passed down. That would make it more obvious when a database is improperly used within a loop.
The same problem exists for any expensive operation within a loop (say, a database query while parsing the results of an API call, or vice versa).
Congress.gov, originally THOMAS.gov, was a product of the Republican Contract with America take-over of Congress in the mid 1990s. Republicans in Congress, including Rep. Issa for example, were helpful in expanding the information that Congress publishes publicly. In the last 15 years, efforts to make Congress publish more and better-structured information have been relatively bipartisan and, mostly, led by nonpolitical staff. I would not describe Democrats as having been the ones to have exclusively created the access to congressional information that we have today, although Democrats in recent years have led on government transparency and accountability issues generally, beyond the Legislative Branch.
Changes that have required legislation have, as far as I'm aware, not really been influenced by the President, other than being signed into law, since they are Legislative Branch concerns and not Executive Branch concerns.
We automatically add links to U.S. Code and other citations. In this case Congress.gov is missing rich formatting which we have (I'm not sure why they are missing it for this bill, normally they have it). GovTrack also allows making diff-like comparisons between bill versions and between bills (for example, you can see the last-minute changes made ahead of the vote on this bill).
Source code is available on GitHub if anyone wants to try making GovTrack better, although it's quite complicated because Congressional information is complicated and there's no real money behind this: https://github.com/govtrack/govtrack.us-web/
If anyone has particular thoughts on what would be helpful when viewing bill text --- within the realm of the information that is actually freely available --- I am all ears.
Totally agree with you that pride is important, but there's definitely more. Being a good engineer is frequently a problem of design --- whether it's user experience or code abstractions. Design is partly art, and that makes us artisans at least some of the time. The code that I've written that has endured the longest --- decades --- has been code that was designed well.
That's not right. Most of the web requires NFC normalization, not NFKC. NFC doesn't lose information in the original string. It reorders and combines code points into equivalent code point sequences, e.g. to simplify equality tests.
In NFKC, the K for "Compatibility" means some characters are replaced with similar, simpler code points. I've found NFKC useful for making text search indexes where you want matches to be forgiving, but it would be both obvious and wrong to use it in most of the web because it would dramatically change what the user has entered. See the examples in https://www.unicode.org/reports/tr15/.