weaving the rainbow, understanding color modes in p5

TLDR summary/spoiler: colorMode(HSB) is an easy way to generate rainbow colors.

ChatGPT, even the vaunted 4 version, was surprisingly bad at helping me make a heart shape in P5, so I found this nice little example by "Mithru". But beyond the decent little heart bezier:

function heart(x, y, size) {
  beginShape();
  vertex(x, y);
  bezierVertex(x - size / 2, y - size / 2, x - size, y + size / 3, x, y + size);
  bezierVertex(x + size, y + size / 3, x + size / 2, y - size / 2, x, y);
  endShape(CLOSE);
}

I was trying to figure out how this code made a rainbow array of hearts:

function draw() {
  background(0);
  for (x = 0; x < width; x += s) {
    for (y = 0; y < height; y += s) {
      fill(310*x/width, 127, 255);
      heart(x+s/2, y+s/2, s/2);

    }
  }
}

The first fill value is essentially mapped from 0 to 310 going across the screen,  and then 127 and 255 are locked in.

So how the heck would changing red (presumably with those out out range values) make a rainbow? Well, it doesn't, I missed the colorMode call:

  colorMode(HSB);

Aha - the first value is the "Hue" (0-360 like a circle), second is saturation, third is brightness. I made a simple toy to see it even more in action, mapping mouseY and mouseX to the other values..

Definitely handy to know when you're thinking in rainbow-y ways! And having one value that roughly maps to "color"- it seems simpler than thinking about R and G and B playing together.

humans as the right hemisphere for chatGPT's left hemisphere

Thinking about ChatGPT, its ability to communicate, its wide range of knowledge and its tendency to confabulate and fall right off the edge of what it actually knows about.

I just noticed these are all factors of the human left hemisphere ... a very similar mix of fluent language use that is informed by but not confined to reality. In split-brain experiments and some stroke cases, people with a lack of inter-hemisphere communication will gladly make up explanations for what their silent right hemispheres decide to do - it makes me wonder if the left hemisphere uses a similar process to ChatGPT's probabilistic "yeah, this sounds plausible as the next thing to say!" methodology. (Also in humans, I suspect this post-facto justification for what the organism decided to do is how we live all the time, but we tend to mistake the justifications for 'consciousness' and being the 'real' 'me')

So for now maybe that's the role humans have to play for ChatGPT: acting as the wiser, big-picture reserved holistic right hemisphere for the NLP's left hemisphere zoomed-in enthusiastic but reductionist model.

accessibility checklist

MagentaA11y is T-Mobile's accessibility checklist. 

I like the approach. Over time, more of these checks should be automatable, but sometimes things just need a human using various devices so that you get the full experience in context, in various contexts.

we're doing it live

Systems these days aren't monolithic, and your frontends needs to accept (and verify) JSON and other data from systems you might not have control over - here's a good piece on  3 runtime validation libraries for Typescript.

The front end industry is leaning more towards stronger build time assurances - unit test coverage and strong typing. Those approaches improve reliability and more clearly communicate the proper usage of code, but I'm sometimes surprised there's not more emphasis on testing and checking in more realistic, richer contexts - integration testing and runtime checks like these libraries provide.

small games

 http://farawaytimes.blogspot.com/2023/02/how-to-make-good-small-games.html
I used to be more into making small games - especially at https://www.glorioustrainwrecks.com/ and their 2-hour-game-jams. Small games often hearken back to the early days of video games where games tended to lean on novel physics and other mechanics, often on a single screen, instead of world-building and lore.Processing (Java) and then P5 were my platforms of choice. You had to do everything from scratch, but you had absolute flexibility. And skills I learned in small game making have come in useful in small projects for work and the interactive greeting cards I still enjoy making.https://games.alienbill.com/advent/ is probably the high point of my small-game hobby, where I gathered 25 of the most interesting things I had made into an advent calendar.

 

thoughts on the programmer's present and future with ChatGPT

 An extensive example of prompts for programming via ChatGPT...

(deeper than the day-of-week-for-date web widget I wrote about earlier )

For people who have made their living typing and generally bridging the gap between people and computers, it's certainly eye-opening. The prospect that we might all just be "PMs and QA for AI" is disheartening!

But it's not clear if the curve we're on (especially for the current set of language models) is at the elbow of a hockeystick, or somewhere near the top of an "S"-shape. Stephen Wolfram wrote the best description I've seen of what's going on and it's amazing how ultimately these are high-powered Markov Chains, where you the AI is just guessing what sounds likely to say next. Now I think there's real intelligence there - the ability to group concepts so that the AI is thinking laterally is a critical piece of the slippery thinking of true intelligence - but there are times where the way the system just isn't properly modeling the world will limit what it can do - there seem to be some fundamental scaling limits.

But like the first link indicates, right now "jr partner" is a solid role for these programs. Most coders are various levels of dependent on Google and Stack Overflow, and this is another valuable repository for the nuts and bolts of coding, so long as you "trust but verify".

the house red of typography

Mike Mai's Fun brief Codepen on Typography.

There's always a tension and balance to be found. Designing for the web isn't quite like designing for a poster; you're wrestling with other constraints of resolutions, widths, color balances, overall download speeds, page flash, etc - so there may be some places where being too precious about typography isn't good value for money.

Conversely, the old webdev joke "`font-family: sans-serif;` - it's like ordering the 'House Red' at a nice restaurant!" - probably indicates a lean too far the other direction.

 

back to basics

 As I gear up for a job search it's good for me to review topics, even ones I know very well.

(The interview environment is so different than the work environment; for better or worse very little work is the kind of "greenfield" stuff you tend to see in interviews; there's almost always a little code handy to copy and paste, and best practice decisions have almost always been made for you.)

Anyway, the TypeScript documentation is famously very good. 

Also this document running through the implementations of React Contexts.

php is dead

I really mean to get to doing more side projects in Next.js and reduce the distance between both my own front end code and the backend, as well as what I do for work and for fun, but I liked this comic:

via Lunduke  - I'm impress that their series of "Funny Progamming Pictures" aren't just the same recycled memes.

GPT DOOM

An attempt to counter some of the worst of the fearmongering about how "GPT will replace all us devs!"

With the usual caveats of no one knows just where we are on the S curve for this tech, this jives with my experience. It's a great supplemental tool, especially for coding small variations of well-trod territory or for pulling the same load that Stack Overflow does, but the conceptual-markov-chain model seems to have a lot of problems where the fact that it is not really mentally modelling (so to speak) the problem and solution shines through. So it doesn't really iterate and check its own work automatically, because it's just coasting on how likely its response was.

(that said, my own foray into having ChatGPT write me a widget to show "what day of the week a date is across years" was eye opening -  )

The whole idea of "prompt engineering" is so weird. On the one hand it's like you're a highly skilled "bot whisperer" with almost magical understanding. On the other hand, you're a bit like that guy in "Office Space" who brings the specifications from the customers down the software engineers... "I DEAL WITH THE BOTS SO THE CUSTOMERS DONT HAVE TO!" I HAVE BOT SKILLS!"

RELATED: (at least for current generation):



 

a fun graph-paper font

 A while back I wrote about some graphpaper font logotype work.

I decided I wanted to do more of that for my new portfolio site but when I dug up the old code, I was bummed how hacky and incomplete character-wise it was. Here's the output of the program I came up with at p5js editor:

My old format was very stupid, I had to specify each segment and each "shadow line" individually. With my new format, I just list each segment (orthogonal or 45 degrees) and if it should be shadowed (i.e. was on the left edge) and I made a heuristic to place the shadow lines on correct intervals. Its not perfect, for letters where the shadow goes behind the front of the letter (Like with "L" or "Z") you have to draw each segment by hand, but overall it worked well with my brain.

Still, specifying all 26 letters by hand would have been a pain, so I made a simple editor as well.

It was a good exercise in not going to crazy with perfectionism (like with editor features, or for generating the final output graphics for my page) but still making some clever code to save myself a lot of work. Plus I just love this typeface, I would play with it and its near cousins on graph paper in high school. (This one is pretty formal, everything is on the whole, half, or quarter graph step, and all angles are 45 degrees.)

xml: the bad parts

Excellent transcribed interview with Douglas Crockford from the  Corecursive Podcast.

I first heard about Crockford in the early Atari 8 Bit computer scene, especially his lovely physics-and-sound software toy Jane's Program. Later he achieved fame with JavaScript: The Good Parts and for championing JSON which indeed supplanted XML.    

Here's what he says about it:

 So there is an intellectual trap in XML, that it's really complicated. It doesn't look like it should be complicated. It's just angle brackets, but the semantics of XML can be really complicated, and they assumed it was complicated for a reason. This problem of data interchange is so complex that there's a conservation of complexity, that your format has to be complex, and the tools supporting that format have to be complex, so that the applications are manageable. And that's a false assumption, there is no such thing as conservation of complexity.

That generally, if you push on simplicity anywhere, you can get it everywhere eventually. So simplicity is the thing you should be driving, not complexity, but they didn't know that. And I think if you have bought into that, you have emotional connection now to this format, and you've been telling people that it's complicated for a reason, and it's good that it's complicated. And then this little piece of syntactic fluff shows up, which is solving the same problems without any complexity at all. You look stupid. And also, you have invested a lot of time and energy into learning this thing, which turns out is becoming irrelevant. And that's a tough thing. And if you're a consultant, it's even harder, because you've established a standing in the community that you have clients because this stuff and this stuff is no longer the thing. And so, a lot of them took this really, really hard.

My unpopular opinion is this: TypeScript has a lot of the same disadvantages as XML, and for similar reasons. Both are an attempt to make data formats more rigid and specified, and both lack the syntactic elegance of their competition (Plain old JS and JSON, respectively.) 

Despite needing a guide to avoiding the bad parts of JavaScript, Crockford realized there's a power there that even mighty Java lacked - first class function, just as one example! (And I would say modern ECMAscript has really made it easy to move away from most of the pitfalls, with properly scoped variables, rarely any need to use "this", etc.) People who aren't comfortable with duck type languages love mocking the edge cases but honestly most of the examples are really contrived.

Interestingly, he doesn't mention TypeScript as the new XML, but rather JS frameworks in general. Here's what he says in favor of plain Vanilla JS (at least these days)

Adam: What do you think is the XML of today?

Douglas: I don't know. It's probably the JavaScript frameworks.

They have gotten so big and so weird. People seem to love them. I don't understand why.

For a long time I was a big advocate of using some kind of JavaScript library, because the browsers were so unreliable, and the web interfaces were so incompetent, and make someone else do that work for you. But since then, the browsers have actually gotten pretty good. The web standards thing have finally worked, and the web API is stable pretty much. Some of it's still pretty stupid, but it works and it's reliable.

And so, when I'm writing interactive stuff in browsers now, I'm just using plain old JavaScript. I'm not using any kind of library, and it's working for me.

And I think it could work for everybody.

(That said - I DO like React, but you actually don't need that to do declarative programming - with template strings even JSX loses some of its specialness! I mean I wouldn't want to do a whole SPA in Vanilla, but if you have some technology that's more about SSR than pushing everything to client, it's not such a bad world.)

don't forget about color-blindness

 Don't forget to design for color-blindness

reminder to self: if testing media queries in chrome, you really need to set the viewport

 Was going a little nuts trying to figure out why my media query wasn't working in chrome, 
stackoverflow was still better than ChatGTP - this is needed in the <head>:

<meta name="viewport" content="width=device-width, initial-scale=1">


I was thinking about the evolution of Programmers looking for help... in the 90s your best bet was an O'Reilly book (I especially liked the "cookbook" format that put stuff in a little more context than the more text-book-y kinds.) 

Then there was a site called "experts-exchange.com" (the dash in the url was important!) where you could post a question and having a good shot at getting a decent answer.

Eventually, that was supplanted by Google and Stack Overflow. Stack Overflow wasn't that different than Experts-Exchange, but handled its gatekeeping and community and reputation-score stuff a bit better.

For a while that was as good as it got, but now frankly for many things ChatGPT provides a more direct answer.

And it's funny, I feel back in the day I used to "know more" about the languages I was using. Like PHP is my goto for light server stuff on independent projects, and I hardly remember any of its wonky API commands. (True but to a much lesser extent for js... like I always forget whether the loop I'm thinking of is for, each, or foreach...) But I got sick of looking stuff in Perl, or maybe I was younger and smarter then... I guess this new style reduces cognitive load - I know about what functions are around to get what I want done, so there's less need to rely on memory for the specifics - it's like the difference between being wise and being smart. Or at least that's what I'm telling myself.

a podcast on design, and thoughts on detail-orientation

My former coworker Katie Langerman and fellow designer Anthony Hobday have cofounded a podcast Complementary, "A podcast about the principles and practices of interface design." 

Their most recent episode (05) was about "Improving Your Visual Design Skills". One point both emphasized was the knack of "obsessing over details" - both emphasized the importance of doing so, but both seemed doubtful that it was something that could be taught, it seems to be more of a personality trait.

At one point Anthony almost seemed to admit a designer could go too far, after they were talking about the joy of collaborating with fellow detail-oriented types:

Katie: But if somebody doesn't see the details, it can feel like you are nitpicking at their designs, or they don't understand the point: 'Why is that important? We're just trying to ship this thing.'

Anthony: I think a lot of people have experienced that with developers as well, especially if you spend hours obsessing over details, and then you work with a developer who is not as obsessed with details, it can feel like a big slog to get them to notice those details?

Katie: Right.

Anthony: It could be - I'm not saying that they're always important details, it could be that the designer has spent TOO long on that and that the developer is in a better place in terms of how much effort SHOULD we spending on this thing. But yeah, I've definitely felt that divide before, and it can be frustrating, because it's not just a switch that people can flip. You know: 'I'll care about details today.'

Now, I have to admit, there have been times when I've struggled with specific kinds of visual detail, I'm a bit face blind and maybe a touch of dyslexia... or maybe it's just a weird synesthesia where I mistype up "b" for "m" and "r" for "4" if I'm going fast - also my reading and writing subsystem lean heavily on the sounds of words, so I suspect it's even easier to make, say, "their/they're" swaps for me than it is for people with a more directly visual form of cognition.

But Katie and Anthony are touching on a more profound split than "perfectionists" vs "sloppy folks who don't give a damn" (or more politely, MAYBE "pragmatists"). The kind of attention a designer like that pays to details represents one side in the great holism/reductionism split that I think is one of the most critical Yin/Yang-ish dualisms - how the quantitative (these tiny details) at some point rise up and merge to become the qualitative (the feel of 'this is good quality' that the final result carries.)

(Also, having worked with many great designers - their tools are often really having to play catch-up when it comes to responsive design and other pieces of the final user experience out of the designer's control. Sometimes, finessing a margin to the last few pixels might be all for nought at a weird screensize - or that precise border might be distorted at a funky resolution - maybe that heading for the section just won't fit with the German translation - or choosing JUST the right shade of magenta that is then viewd on a Mac in ''Night Shift" mode! That's even worse than a poster designer having to sweat CMYK vs RGB or what not! So often tools like Sketch and Figma are used to explore "sunny path" scenarios on the designer's super high quality screen. I guess, good design looks great from the get-go, but great design keeps its looks with different contexts and contents - but with a flexible design the tools aren't always terrific at indicating which details are invariant and which have more "give")

But back to the quantitative details vs qualitative end results... like all great bits of thesis / antithesis=>synthesis, you can't have one without the other, you're not likely to get a good forest if your trees are bad. But sometimes I find myself having to be defensive. The opposite of the "detail oriented" point of view isn't always "lazy and not giving a damn", sometimes the difference is how that kind of perfectionist is zooming in in a context-free way, (according to psychiatrist Iain McGilchrist, a highly left-hemisphere activity) while people who are less attuned to that might be more sensitive to how things are working in context. (Akin to the evolutionary older right-hemisphere, which McGilchrist sometimes sees as being shouted down.)

I definitely see rhyming parallels in these splits: 

"detail-oriented"	"eh-whatever-works"
Reductionism	Holism
Isolated	Context-Sensitive
Nouns	Verbs
Essence	Surface
Unyielding Strength	Flexibility
Compile-Time Assurance	Runtime Robustness

(That last one is related to my new attempts to explain why I wish the industry was less concerned about unit tests vs higher level tests with less-artificial contexts and more comfortable with duck typing than sacrificing concise readability in trying to get JS to behave more like Java or C# via TypeScript.)

Oh and the podcast mentioned some great links I should add into my usual rotation and/or knowledge base:

    •    https://www.lapa.ninja/
    •    https://land-book.com/
    •    https://godly.website/
    •    https://saaslandingpage.com/
    •    https://www.siteinspire.com/
    •    https://twitter.com/awesome_saas
    •    https://twitter.com/saasshots
Other links mentioned:
    •    https://open-props.style/⁠
    •    https://tailwindcss.com/

more readable typescript errors in storybook via chatGPT

 PROTIP: "Subtle" Typescript errors (like stuff that might have been hidden at best in VS Code) often show up loudly in storybook (sub-PROTIP -the "real" errors is often listed at the top, even if its mupltiplied later) but they are often flattened. ChatGPT can help though:

could you indent Type '{ idle: { alignItems: string; display: string; flexDirection: string; padding: string; border: string; backgroundColor: string; }; hover: { alignItems: string; display: string; flexDirection: string; padding: string; border: string; backgroundColor: string; }; focusVisible: { ...; }; }' is missing the following properties from type '{ idle: CardStyles; hover: CardStyles; disabled: CardStyles; active: CardStyles; focusVisible: CardStyles; }': disabled, active in a logical way

Certainly! Here's a more readable version of the error message with proper indentation:

Type '{ 
  idle: { 
    alignItems: string; 
    display: string; 
    flexDirection: string; 
    padding: string; 
    border: string; 
    backgroundColor: string; 
  }; 
  hover: { 
    alignItems: string; 
    display: string; 
    flexDirection: string; 
    padding: string; 
    border: string; 
    backgroundColor: string; 
  }; 
  focusVisible: { 
    ...; 
  }; 
}' 
is missing the following properties from type '{ 
  idle: CardStyles; 
  hover: CardStyles; 
  disabled: CardStyles; 
  active: CardStyles; 
  focusVisible: CardStyles; 
}': 
  disabled, 
  active

 

more unix command line fun, grepping through apache error logs

 So I'm on a kick of trying to improve my site hygiene.

My Apache error_log is over 400Mb. I think mostly it's PHP warnings, especially " PHP Notice:  Undefined index: key" where I'm doing $_GET["propname"] without checking for isset. Guess that adds up for popular pages (and maybe running things in a loop?)

So I constructed this unix line:

grep -o "in \/home.*\.php.*" error_log | sort | uniq -c | sort -n -k1

So that says, pick out all the lines of form "in /home [blah blah] .php" and the -o means it just returns the match part (since other information like time stamp would be different)... I then "sort" (since the next command "uniq" only removes immediate duplicate lines, and "uniq -c" has an argument to count # of currences. Finally ChatGPT tells me "sort -n -k1" sorts numerically by the first field.

10240 in /home/kisrael/data/porchfest/COMMON/php_admin/db_view.php on line 156, referer: https://jpporchfest.org/adminstaff/db_view.php?datatype=band
19893 in /home/kisrael/data/porchfest/COMMON/php/formhelper.php on line 78
23958 in /home/kisrael/data/porchfest/COMMON/php/formhelper.php on line 79
24537 in /home/kisrael/data/porchfest/COMMON/php/formhelper.php on line 56
25107 in /home/kisrael/data/porchfest/COMMON/php/formhelper.php on line 73
25398 in /home/kisrael/data/porchfest/COMMON/php/formhelper.php on line 80
29532 in /home/kisrael/data/porchfest/COMMON/php_admin/db_view.php on line 85, referer: https://jpporchfest.org/adminstaff/
32909 in /home/kisrael/data/porchfest/COMMON/php_admin/db_viewCSV.php on line 46, referer: https://jpporchfest.org/adminstaff/
45156 in /home/kisrael/data/porchfest/COMMON/php_admin/db_view.php on line 156, referer: https://jpporchfest.org/adminstaff/edit.php?datatype=band
240618 in /home/kisrael/data/porchfest/COMMON/php_admin/db_view.php on line 156, referer: https://jpporchfest.org/adminstaff/

guess I got some work cut out for me!

rsync using old ssh protocol

So, after I upgraded my Mac, I lost the ability to easily ssh into my old server, which I guess only supports ssh-rsa and ssh-dss (The server is overdue for an update but is still getting security patches so my admins recommend putting off the inevitably painful upgrade)

ssh -oHostKeyAlgorithms=+ssh-rsa

works as a replacement for my ssh command as does its equivalent for sftp, but I guess rsync is more something that piggybacks on ssh? So the equivalent command (well the alias I'm using for it) is

alias rsyncfix="rsync -e 'ssh -oHostKeyAlgorithms=+ssh-rsa'"

Sigh. I really am old school with so much. I just like folders of folders with my files that I can backup manually, and that goes for my personal data as well as what I have going on my server. I just like seeing bits and bytes on hardware that I control, not somewhere out there in cloudspace though I know there are advantages...

And while we're talking old unix command, here's my old favorite disk-usage du command:

du -hs * | sort -hr

Just shows you the summary of each top level folder (or file), with human readable labels (ie. M, G etc not just bytes) and sorted biggest to least.