Perspective is a wild thing. I bet most people think they have some. But then you have some big life experiences and you're like "oh. wow. that's perspective".
Be objective. Don't make decisions based on anger, fear, or pain.
Still getting issues with RSS images, thinking it could be a problem parsing colons in the urls.
I've had Open Props in here for a couple of weeks and it has been fun to simplify and rework what little CSS I had to use it.
My take is that Open Props provides a core set of custom properties mostly based around sets and scales that provide the building blocks to improve consistency of website implementation where it makes sense to have a defined set of available values. It also has some nice and sometimes whimsical presets for animations and gradients that bring a sense of fun (and usefulness) back to the web.
After working with Tailwind professionally for a year, one noticeable difference is that it is not an exhaustive set of properties for all possible attributes and being value based, there is not an entire new dsl on top of CSS to learn to use it.
I'm using the normalize bundle and it is super interesting using the :where() pseudo selector to prevent any specificity on the reset props.
It does mean you need to learn CSS (a good thing). And that all the tools and tricks to author maintainable CSS are still important.
But if there is a scale of values you need to have locked in. Or just have the choice made for you. Then Open Props is a pretty good starting place.
Still intermittent heros in Feedly. I read somewhere 1200 x 630 is a common ratio.
Worth a shot.
The time to generate the glitch hero images took 6.2 seconds after I added in the file stating yesterday.
Small win there.
Meta og images still elude most posts at least in Feedly my RSS viewer, tests in other places work.
When debugging it best practice to change one thing and test. A frustrating thing with Feedly and RSS is the refresh cycle is not consistent.
Anywhoo, I padded out the other og meta properties (probably valuable anyway). And I through in the twiter:image meta.
I try again.
I want to generate the glitch hero sans title overlay.
This will blow out the playwright test time to capture more screenshots as I've been re-capturing 2 screenshots and an svg for each post every build.
This was never going to scale but was fine while it was on localhost.
As a simple step. I've added a file stat to any image artifact generated in the glitch phase.
This post will test if it works for real.
I think I've cracked the basic open graph meta data which was sort one of the first experiments on this site but which needs more documenting.
This thought is the effort to document the generation of the hero/og art and prompt an improvement for the build and efficiency.
The current process is to:
npm run start:glitchnpx playwright test -c _glitchThe first step includes a different eleventy config that skips a bunch of plugins (probably rss) and adds a global theme glitch that modifes the CSS to render the pages glitched.
The second step runs a set of tests that screenshot the glitched thoughts/posts and feeds those into a paper js page/script to generate a unique SVG based on the content screenshot, these are exported as annotated pngs and svgs.
The pngs and svgs are stored back in the website content folder using slugified filenames so they can be resolved by the main website content build.
This works.
It's automattic in the sense of generative art. But from a dev build perspective it still needs an intermediary step to generate the art after the content has been completed.
And as it needs a dev server and a test script, it runs in two terminals often in addition to running a dev server and another terminal for git, etc.
How could I improve this so I had an npm run generate command that did the setup and teardown for the art generation.
Oh another point ... It re-generates all art by default. How might I test and skip content that has existing art and use a --force if I wanted to rebuild it (or just delete the file).
This post isn't the solution. I'm thinking a build script that:
✌️🤠
PS: This content has been written sans content dev server to also try and sequence the order and the dependency.
This is a test
I think I've got <meta property="og:image" ...> tags working.
Lots of false starts trying to figure out how to get Eleventy to to give me the tag with a url that matched the optimised glitch URLs.
I had issues with importing the correct esm Image not { Image }.
I had issues resolving paths as they are different from the ones used in the automatic transform.
I eventually figured out a modified version of eleventy-image Make your own Markup would work when I lined up the other bits I had wrong.
eleventyConfig.addShortcode("metaImage", async function (path, fileName) {
if (!path || !fileName) {
return "";
} else {
try {
const src = `content/${path}/img/banner/${fileName}.png`;
let metadata = await Image(src, {
widths: [1200],
formats: ["png"],
});
let data = metadata.png[metadata.png.length - 1];
return `<meta property="og:image" content="${data.url}" />`;
} catch (e) {
console.log("No image found for ", path, fileName);
}
}
});Playing around with really hero-ing the svgs for thoughts, I wanted to try and overlay the content on the generated image.
Having just sorted inline SVGs which are my general preference as they are highly flexible with CSS I started to play with absolute positioning as a means to to put the content on the image.
This started to work but as at least one of the els needed removing from the flow it mean more magic numbers and hacks were needed to get the content to reflow at different viewport sizes.
With all the recent learning and hacking on eleventy config it was not hard (today) to adjust a custom shortcode to output the inline SVG as base64 and use this as a background-image data uri.
Once I had the SVG as a background it was much simpler to set the desired spacing on the content and defer the flow to the browser.
Hat tip to this 2015 CSS tricks article: 09: SVG with Data URIs.
I got inline SVGs working this morning. I smashed around Eleventy as I couldn't figure out some of the more recent techniques.
I ended up with an async shortcode that just read the file off the filesystem and echoed it out.
I got around to reading the bare minimum about svg viewboxes and figured out a quick crop and reset of width and height attribs.
I could go back to the SVG generation, but I've got enough to keep moving forward.
Exploring deploying updates via ssh/scp, etc to not need a whole docker image build 😵💫
it seems the image I'm using to host the site is super lean so no ssh server. kinda great but It needs some further investigation.
One pomodoro in for the day and starting to look at CSS
I got my heading font in and I adjusted the build to use an included CSS file over inlining to each file.
Time for a break.
I'm looking for motivation to look for work.
So I finally googled Pomodoro Technique and forced myself to start a timer.
As a form of internal resistance instead of starting a rubric for my next role I used the first Pomodoro to deploy my website I've been building to production.
I wonder how Eleventy deals with sites that grow over time.
It feels like it is independent of the static site generation and is more a concern of syncing/uploading the site.
I've used sync on S3 successfully to reduce uploads for sites with minor diffs, but I'll need to look into what I'll need to do with my current fly.io setup as it will probably be a whole docker image being uploaded.
After a few false starts I've got something working that feels like it will serve the IA I've been after.
Goals I've been thinking about for this site.
Behind the scenes I've got a staging environment and a production environment, more relevant to development of the site than content updates but still nice to have.
My existing (now previous) site was an absolute place holder. Now I'm looking for something that I can post updates to and syndicate them out to social media if it makes sense.
It feels like owning your own content is more important in 2024 than any time that may have come before.
This is a base blog build using the Eleventy 3.0.0 alpha/beta/nightly what evs. I'm kinda jazzed that Zac got it to ESM.
I used to say software was done when I had confidence that all remaining work was known. Just some gaps to fill in, but we got this.
Then I said it was done when it was functionally complete on my workstation but not tested by anyone or deployed anywhere.
Then I said it was done when it met a set of criteria on a non exhaustive checklist called definition of done.
Then I said it was done when it had an automated deployment pipeline and was in production. At least at this point it was de-risked. We could welcome users without scrambling to do a build that worked in our production environment.
This was a great professional journey to go on and I needed to grow and mature through what I thought was done vs. the reality which was – if there was anything more to do it wasn't done.
Now I think as long as software is running and has users, it's not done. There is a support cost to all software and treating something as finished ignores the importance of maintenance over time. Bit rot is real and happens all the time from multiple vectors. Dependencies become incompatible, security bugs are found, platforms deprecate features and many others.
Sometimes future states can be imagined, but often they're difficult to frame or plan for ahead of time. The best thing to do is to acknowledge that while software is in use there is an obligation to feed and water it. Sometimes it might not need much attention and other times it may need what seems like an unreasonable amount.
The risk of not providing ongoing investment is always the cost of delay. And reader, with old software services ... that become critical dependencies ... for which the domain knowledge is long gone ... the dependencies are three versions behind the vendor’s current release ... and you need the latest version to fix the known memory leak. The cost will always be higher to fix than to keep something fed, watered and well managed.
So when is software done? When it is turned off, decommissioned and replaced by its successor.
By thinking about done in this way it lets us plan for decommission as a positive outcome, a natural stage in software lifecycles. Something to aspire and look forward to. Not because we've finally turned off the thing that caused us so much pain but because it did its job. It served its purpose and now we have learnt some things and built something better. That too will be done some day when we turn it off.
See all tags.