Sometimes our build process take a minute, so I had Co-Pilot help build me a script to use the mac's text to speech to announce when it looks like we were ready to go:
#!/bin/bash
# Check if at least one argument is provided
if [ $# -lt 1 ]; then
echo "Usage: $0 <nx_command> [args...]"
exit 1
fi
# Build the nx command from the provided arguments
nx_command="$@"
log_file="nx_command.log"
# Run the command in the background and capture its PID
$nx_command &> $log_file &
pid=$!
# Monitor the log file for the specific line
tail -f $log_file | while read line; do
echo "$line"
if [[ "$line" == *"All remotes started"* ]]; then
say "ready"
break
fi
done
# Wait for the nx command to finish
wait $pid
Tuesday, April 8, 2025
if you see something (build finished) say something
Tuesday, April 1, 2025
print design in browser via PHP
It's funny in how so many ways I can use a little coding mojo and not have to fiddle with Word/Google Doc, Excel/Sheets - or Wordpress for that matter, but that's a longer story.
But yeah, helping my sweetie run together some tiny bits of campaign material via PHP:
<!DOCTYPE html>
<html>
<head>
<title>Lynette Table</title>
<style>
body { font-family: sans-serif; }
table { border-collapse: collapse; font-size:1.5em;}
td { border: 0px solid black; padding: 10px; text-align: center;
padding:24px;
}
.bigger{
font-size:1.4em;
}
</style>
</head>
<body>
<table>
<?php
for ($row = 0; $row < 5; $row++) {
echo "<tr>";
for ($col = 0; $col < 3; $col++) {
echo <<<HTML
<td>
Vote this Sat April 5!<br>
<b class="bigger">Lynette Martyn</b> <br>
Town Meeting Member, Precinct 12<br>
A progressive voice for your neighborhood<br>
<b>www.LynetteMartyn.com</b>
</td>
HTML;
}
echo "</tr>";
}
?>
</table>
</body>
</html>
slapped on this webpage gave me
Monday, March 31, 2025
on not upgrading
Tim Boudreau:
Some time in the early 2000s I was doing some work with the real-time Java team at Sun, and there was a huge defense contractor with a peculiar query: Could we document how much memory an instance of every object type in the JDK uses? And could we guarantee that that number would never change, and definitely never grow, in any future Java version?I remember discussing this with a few colleagues in a pub after work, and talking it through, and we all arrived at the conclusion that the only appropriate answer to this question as "Hell no." and that it was actually kind of idiotic.Say you've written the code, in Java 5 or whatever, that launches nuclear missiles. You've tested it thoroughly, it's been reviewed six ways to Sunday because you do that with code like this (or you really, really, really should). It launches missiles and it works.A new version of Java comes out. Do you upgrade? No, of course you don't upgrade. It works. Upgrading buys you nothing but risk. Why on earth would you? Because you could blow up the world 10 milliseconds sooner after someone pushes the button?It launches fucking missiles. Of COURSE you don't do that.There is zero reason to ever do that, and to anyone managing such a project who's a grownup, that's obvious. You don't fuck with things that work just to be one of the cool kids. Especially not when the thing that works is life-or-death (well, in this case, just death).Another case: In the mid 2000s I trained some developers at Boeing. They had all this Fortran materials analysis code from the 70s - really fussy stuff, so you could do calculations like, if you have a sheet of composite material that is 2mm of this grade of aluminum bonded to that variety of fiberglass with this type of resin, and you drill a 1/2" hole in it, what is the effect on the strength of that airplane wing part when this amount of torque is applied at this angle. Really fussy, hard-to-do but when-it's-right-it's-right-forever stuff.They were taking a very sane, smart approach to it: Leave the Fortran code as-is - it works, don't fuck with it - just build a nice, friendly graphical UI in Java on top of it that *calls* the code as-is.We are used to broken software. The public has been trained to expect low quality as a fact of life - and the industry is rife with "agile" methodologies *designed* to churn out crappy software, because crappy guarantees a permanent ongoing revenue stream. It's an article of faith that everything is buggy (and if it isn't, we've got a process or two to sell you that will make it that way).It's ironic. Every other form of engineering involves moving parts and things that wear and decay and break. Software has no moving parts. Done well, it should need *vastly* less maintenance than your car or the bridges it drives on. Software can actually be *finished* - it is heresy to say it, but given a well-defined problem, it is possible to actually *solve* it and move on, and not need to babysit or revisit it. In fact, most of our modern technological world is possible because of such solved problems. But we're trained to ignore that.Yeah, COBOL is really long-in-the-tooth, and few people on earth want to code in it. But they have a working system with decades invested in addressing bugs and corner-cases.Rewriting stuff - especially things that are life-and-death - in a fit of pique, or because of an emotional reaction to the technology used, or because you want to use the toys all the cool kids use - is idiotic. It's immaturity on display to the world.Doing it with AI that's going to read COBOL code and churn something out in another language - so now you have code no human has read, written and understands - is simply insane. And the best software translators plus AI out there, is going to get things wrong - grievously wrong. And the odds of anyone figuring out what or where before it leads to disaster are low, never mind tracing that back to the original code and figuring out what that was supposed to do.They probably should find their way off COBOL simply because people who know it and want to endure using it are hard to find and expensive. But you do that gradually, walling off parts of the system that work already and calling them from your language-du-jour, not building any new parts of the system in COBOL, and when you do need to make a change in one of those walled off sections, you migrate just that part.We're basically talking about something like replacing the engine of a plane while it's flying. Now, do you do that a part-at-a-time with the ability to put back any piece where the new version fails? Or does it sound like a fine idea to vaporize the existing engine and beam in an object which a next-word-prediction software *says* is a contraption that does all the things the old engine did, and hope you don't crash?The people involved in this have ZERO technical judgement.
Now Social Security isn't as life and death as nuclear missiles, and the challenge in getting people who can make any changes with COBOL is real. But I have zero confidence the DOGE bros are the ones to get it anywhere near right.
Friday, March 21, 2025
AgGrid note
Just a quick note, AgGrid is pretty serious about its breaking changes in 33. Like if it detects the old ag-grid.css, it aggressively unstyles itself and you can't use the new theming.
"If I press these keys in the right order, I can do anything!"
At work, Corey G mentioned how sometimes he'll do a demo for a client and make sure EVERYTHING is a single file (like include Base64'ig images if need be) That vibe reminded me of how I like "everything in one file" for p5.js, and how it harkens back to the old days of computer magazine type-in programs, and this comic.
windows taskbars through the ages
I switched to Mac about a decade ago. For a while I thought Windows' "one task bar item per window" was smarter than Mac's "one Dock item per application". Now I'm not sure (and I noticed Windows has drifted to Mac's approach) but I do know I tend to have too many windows open.
Wednesday, March 19, 2025
Subscribe to:
Posts (Atom)