Wednesday, March 15, 2023

javascripts sans build systems

Great (and by great I mean good and agrees with my biases) article Writing Javascript without a build system - Julia Evans writes

I make a lot of small simple websites, I have approximately 0 maintenance energy for any of them, and I change them very infrequently.

My goal is that if I have a site that I made 3 or 5 years ago, I’d like to be able to, in 20 minutes:

  • get the source from github on a new computer
  • make some changes
  • put it on the internet

But my experience with build systems (not just Javascript build systems!), is that if you have a 5-year-old site, often it’s a huge pain to get the site built again.

And because most of my websites are pretty small, the advantage of using a build system is pretty small – I don’t really need Typescript or JSX. I can just have one 400-line script.js file and call it a day.

That meets my workflow (though "ashamedly" I often skip the git step and just adjust things on the server).

Someone one said (and I wish I could find the quote, this is a very rough paraphrase) that the Internet just has one big trick, getting information onto and off of someone else's server, and you really can do that with conceptually lightweight technologies! 

(Also see her list of things that used to be hard and are now easy - thank heavens for Let's Encrypt)    

---

Other unlrelated JS articles I'm catching up on:

use maps moreand objects less seems like a good idea though - like with typescript - I think many coders don't get how important syntactic sugar can be.

A personal history with React is interesting...  thinking about how Contexts now solve the props drilling problem.

JS/TS changes of the last 3 years

 ----
FOLLOWUP:
Here is a reddit discussion about that first link. I like fzammetti's approach, even though I tend to get by without even the npm file juggling. (I think essentially the serverside stuff, the PHP, takes care of that for me.)


Tuesday, March 14, 2023

tweaking vs code and some plugins I like

 So first, a disclaimer: I have no idea who or what vets VS Code plugins-  like it feels like the wild west a bit, and you have to have the same kind of trust you have for npm packages...

(Tangent to the disclaimer... does anyone else pronounce it "versus code"? No? Just me? Must be the early Nintendo influence)

Anyway, "Error Lens" seems like a nicer form of error display (and honestly it's the errors that make TypeScript such a slog... allegedly it makes up for the time spent early on in the long run, but I have my doubts.)

Like here is the inline warning: 


 GitLens seems to be a popular way of doing "git blame" and the like.

"Peacock" lets you "subtly" change the color of your worksplace - like mostly the frame, so you don't have to adjust your eyes to new colors for code.

Finally, here's a guide to change the VS code app icon. Frankly, that weird "fish in a tank" icon, with its default mid-blue on white, looks too much like half a dozen other icons, and the lack of connection of the icon to"V" or "S" or "Code" is just bizarre, and was providing my brain with no hooks for it. 

(The VS Code icon - here's its history, which only touches on the "fish" look that has (allegedly) offended at least one person as Christian imagery...)

For what it's worth I think I like the icon shown on the left here: I use a lighter background so I don't want the black icon, and some how googly eyes (making it look a bit like Clippy I guess?) provide the mental hook I was craving to quickly find the icon on the dock or cmd-tab list.


Thursday, March 9, 2023

the propped up web

A friend pointed out this mastodon post: https://jawns.club/@lou/109973651127997348

 Which talks about a Denis Pushkarev, maintainer of core-js, trying to make things work financially

He makes a great case that core-js (used to transpile code and make sure even older browsers can run code written in the new paradigms) is used ALL OVER the place, in much the same way jQuery was back in the day.

The obvious model is this famous xkcd comic:

It reminds me of "You are not buying from a supplier, you are a raccoon digging through dumpsters for free code." So many place I've worked - everywhere that's not a Microsoft house, really - you just start using stuff because it's cool and useful, everyone else is using it, and you don't have to setup budget approval.  (And then coders start getting massively entitled. "Software should be free!" and they mean "as in beer" not just as in speech)

Also for UI folks - the tendency to just have these mammoth piles of code npm'd in for every little task - it's a lot of trust! Or even the plethora of VS Code plugins. They tend to have a lot of access to your filesystem... I'm reminded of Dietzler's Law, how all these abstractions allow things to flow so much more easily, but you can still caught if you need to change something the abstraction doesn't allow for.

I've definitely grown a preference for systems where trust is just a few organizations. On my OS, I try to minimize clever plugins that I would miss if sitting down to a "fresh" install (though I do like SizeUp and HyperSwitch) - for my light server stuff, I like PHP's monolithic set of "here are all the fiddly functions you probably need" vs NPM's giant library... and for my own projects I still gravitate to not needing a build system and just trusting what ECMAScript the browser supplies...

Wednesday, March 8, 2023

iphone tip on alarms

 iPhone tip: if you have a giant pile of old one time use alarms set up on an iPhone it's easier to ask Siri to "delete all my alarms" than remove them one by one in the UI...

Sunday, March 5, 2023

trivial php directory of images to image gallery

 I feel like I must have written this already half a dozen times, but I couldn't find quite the equivalent posted here: a trivial script to dump every file that looks like an image based on extension into an img tag, with a link/filename before it.


<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<style>
body {
    font-family: sans-serif;    
    margin: 80px;
    font-size:24px;
}
img {
 width: 100%;   
}

</style>
</head>
<body>

<? $files = array_values(array_diff(scandir('.'), array('.', '..')));

$imageendings = array(".jpg",".jpeg",".png",".gif",".webp", ".svg");
foreach ($files as $file) {
        $lowercaseFile = strtolower($file);
       if(endsWithOneOf($lowercaseFile,$imageendings)) {
            print "<p>";
            print "<a href='$file'>$file</a><br>";
            print "<img src='$file'>";
            print "</p>";
       } 
}
function endsWithOneOf($haystack, $needles){
    foreach($needles as $needle) {
        if(endsWith($haystack, $needle)) return true;   
    }
    return false;
}

function endsWith($haystack, $needle) {
    $length = strlen($needle);
    return $length === 0 || 
    (substr($haystack, -$length) === $needle);
}


?>
</body>
</html>

Friday, March 3, 2023

programmers and musicians

Heh, just had a thought that seems so blatantly obvious in retrospect.  

Like I'd long heard of the overlap between programmers and musicians.

And with programmers, there are coders who are very into precision and isolation: unit tests and formal typing. And there are other coders who are more interested in context and are comfortable with duck-typing.

And with musicians, there are many players who love the precision, and aren't comfortable without sheet music in front of them. And there are group musicians who, while usually following forms (not talking jam bands, more like street bands) are comfortable doing more by ear, and emphasize interaction.

It's probably not a coincidence that I'm in the latter category of both, and I think the spectrums tend to run parallel. 

As always, the best answers are somewhere between, but probably more on one side than the other.

Thursday, March 2, 2023

debugger beware! objects in console.log() are dynamic

TL/DR: if you blast an object to console.log(), like an array or map, that is likely to be a "live" display of the value of the array, not what was present at the moment you called console.log. One work around is to use console.log(JSON.stringify(thingy, null, ' '));

One of the silver linings of being an old gray beard is this kind of problem just made me stumble for a minute, but then the "wait-a-minute" factor kicked in and I came up with a workaround...

So at work I'm doing a project that's a wrapper for google chart - there was some code here that read values from a table, and I console.log() the results.

this.sourceData = this.parseData(sourceTable,calculateAsPercentage);
console.log(this.sourceData);
let data = google.visualization.arrayToDataTable(this.sourceData);

The thing is when I did some further log() of what was becoming the return value of parseData() inside that function, it looked like the "header" data was being generated and pushed onto the array, but then it disappeared. 

But then I figured out something in Google chart (or maybe processing we do, I dunno) was consuming the first entry with the header data, probably array.pop().) But console.log was always showing me the final version, not the snapshot of what it was at the moment the function was called.

So I realized JSON.stringify() (with the usual (thing, null, ' ') to format it properly ... how many times have I typed that null, ' ' ...) would give me the snapshot in time" I was actually thinking of:

this.sourceData = this.parseData(sourceTable,calculateAsPercentage);
console.log(JSON.stringify(this.sourceData, null,' '));
let data = google.visualization.arrayToDataTable(this.sourceData);

BONUS: remember if you are dumping a regular variable to console and want to see it labeled with its name you can stuff it in a map-like object, just two characters more:
console.log({variableName});