the 3 pillars of modern CSS

 Modern CSS in a nutshell mentions flexbox, CSS Grid, and newest to me, CSS Custom Properties that seem like they can do variables ala SASS... but even better they are dynamic.

ctrl-s or cmd-s listeners to save in vanilla js

 I'm rewriting my blog's homebrew content management pages.

One idiosyncratic feature I like for my own use: my brain sometimes assumes "cmd-s" (ctrl-s in windows speak) should save the current entry, just like I saving a file in a local editor, the fact that I'm working in a browser be damned.

Here is the code I came up with. (I wrote similar stuff a long while back, but it was tied into JQuery, and now I'm all about the Vanilla baby!)

First, adding a listener when the page is loaded:

document.addEventListener('DOMContentLoaded', setupCmdSListeners, false);

Now on my page I have different fields that submit to different forms, so I'll just have it so the main textarea for each content type fakes a click on the submit button for that page:

function setupCmdSListeners(){
    setupCmdSListener('rawguts','submitraw');
    setupCmdSListener('quickguts','submitquick');    
}

We have to curry a function so that each listener knows which submit button is relevant

function setupCmdSListener(textareaid, submitid){
    document.getElementById(textareaid).addEventListener('keydown', 
                (event) => {cmdSListener(event,submitid) });   
}

And here's the actual listener:

function cmdSListener(event,submitid){
    if((event.ctrlKey || event.metaKey) && event.which == 83) {
        document.getElementById(submitid).click();
        event.preventDefault();
        return false;
    }
}

Pretty simple! A page could also just set up the listener for the whole page, and avoid the currying. Sometimes it's easier to write some code than train my brain and hands not to expect something like ctrl-S/cmd-S to work.

quick note to self: php mkdir has recursive mode

I was all set to make a half-assed (like, Unix slashes only, choking on filenames that had escaped slashes, etc) recursive directory maker (i.e. for /foo/bar/something , make foo if it doesn't exist, then foo/bar if that doesn't exist, etc) but realized it's built into PHP mkdir:

mkdir($finaldir,0755,true);

The final param is whether to do it recursively.

It's stuff like this that make me appreciate PHP a bit... like more so Perl or a lot of other languages / toolkits, thoughtful useful stuff is built in...

quick note: download files via curl, with redirects

To download a file via curl:

 curl -L https://someurl/somefile --output somefile

The -L is useful if there are redirects. 

defending php with the importance of context

I found a pretty good article discussing Why developers hate PHP. (Spoiler: it starts seeming to support the negative vibe, but then comes around to a more balanced position.)

You can tell I'm getting defensive about PHP when I link to Taking PHP Seriously, but it has been interesting exploring why it is sometimes hated with such vehemence. (That last article, it reminds me of the old old rant Object Oriented Programming Oversold! , except OOPO is punching up and the anti-PHP stuff is generally punching down.)

(That said... some of PHP's stickiness has to do with WordPress, and... I do not enjoy configuring or making up custom widgets for WordPress...)

As I ponder on it... yeah, there's much I can't disagree with - the API is a mess, and I am completely reliant on Google to relookup every function - some of that is my age/learning style and some of that is the style of the times, but still. (On the other hand, so many of the edge-case-y "how can you live like this" parallel critique of javascript, like when equality and null/undefined and implied type conversion get weird... and this drives some people nuts but I am unconvinced it causes that many problems in real environments.)

But I still think that developers who hate it SO MUCH... well, it reminds me of my friend Jon, who recently dabbled with a toy project to learn TypeScript a bit. He didn't like TypeScript, and when I looked at his code, I saw he was trying to bring over the same OO principles from his other work, and I agreed that was a terrible fit for the language. (I didn't try to convince him that OO was indeed oversold, but as I think about it... the idea of bundling data and operations kind of goes against the grain of functional programming, and its love of immutability?) Basically, it's the wrong tool for the job, or at least for the mindset.

Anyway. My current lens for looking at the world, especially the world of tech, is "Holism vs Reductionism". Reductionism as a term has a bit of a stigma, but it's absolutely a critical half of programming- taking a complex problem and breaking it into steps is the bread and butter of programming, and functional programming and avoiding side effects - isolating - are all critical bits. 

But Holism is important too, because it is understanding how all the parts come together. ("Bugs are an emergent property" is my current thinking, so if you're not looking at things how and where they connect, you do not understand the system.) And I think a lot of the classic developer type discounts the need for the holistic and context sensitive understanding.

So, it's all about context. And I think that applies to PHP - deployment is acknowledged as its sweet spot. And I wouldn't want to do big engineering with it, but man... keeping simple things simple is so critical, that it makes up for the sometimes glaring flaws in the language. That wonky API... I mean it sometimes seems aggressively and gratuitously inconsistent, but having so many functions handy compares favorably to, say, bad old days of Perl (where everything was a install from CPAN) or even modern React (where create-react-app pulls down gigs and gigs of libraries, just in case, each having its own set of documentation if it IS the part of the kitchen sink you've learned about and want to use.)

Of course it's a mix of language and API/toolkit. I mean, it's weird that PHP is a language per se... that's where its immaturity most shines through. 

I mean, maybe if Rust or some other language was quite as easy to deploy, and had outputting DOM bits so baked into it, it would be worth checking out, but I'm not sure if such a thing exists, or would have enough of an audience to be worth learning (and figuring out how to install on my cheap rented webspace, which honestly is a big part of my loyalty to PHP...)

Heh, besides refactoring my blog's backend editor from - gak- ancient Perl CGI to PHP, the other thing that got me going here was working up a quick and easy page to display a pile of memes I had collected: kirk.is/memes/ - I feel like this one would might have been useful a full times as i read through the PHP hate pages...

edge is the new sleaze

Man, Microsoft's Edge browser has gotten really sleazy. It's one thing to know that Google, FB, et al are tracking you - depending on how uptight you are about privacy you might not care that much - but to ally with a "buy now pay later" company is downright bizarre, and then when you try to leave you get hit with slogans like 

“Microsoft Edge runs on the same technology as Chrome, with the added trust of Microsoft.”

“That browser is so 2008! Do you know what’s new? Microsoft Edge.”

“I hate saving money,” said no one ever. Microsoft Edge is the best browser for online shopping.

Yikes. 

storybook: consider changing your default viewport (mobile view to default)

 Just a quick note... Storybook defaults with a way of quickly switching between viewports, good for bouncing between Desktop-ish vs more mobile or tablet sizes:

The trouble is it resets when the page is reloaded, so since I'm working on a mobile-scale problem, I'd prefer to (at least temporarily) change the default.

Easy enough according to the storybook docs - I didn't really want to modify the menu item, just figure out what the defaults were named, so the only code I needed to add to our preview.tsx was

export const parameters = {
  viewport: {
    defaultViewport: 'mobile2',
  },

I suppose a team should figure out if responsive, full-width is the best starting default always, or if they want to lean into being more "mobile-first" by changing the default. It's all too easy for developers to get into a mode of "well it looks good on my large laptop in chrome, so it's probably fine." (of course narrowing the viewport is just one factor of proper mobile testing - but an important one.)

(Of course, I could have gotten similar results by using Devtools' device toolbar, but then there are other complications in terms of the rest of the Storybook trimmings around the content.)