vanderwal.net

Vibe Markets Don’t Always Rhyme with Good Product

My recent Four Cornerstones of Development post (which I found the initial blog mention on a March 2001 archive page - Off the Top :: March 2001 and later on mention I’m working on an essay on it, which I somewhat remember having a publication ask me to write it for them, but no longer exists) was surfacing in discussion a bit lately when talking with those building quick things for themselves that they had used LLM for coding (as well as much of the interaction and visual design), which is viable for personal use for a stretch and then you hit the reliable, maintainable, repeatable thresholds of pain.

Ooh! This Looks Interesting

But, I’ve looked at a quite a few of these projects (not those that aren’t really products) as they initially seem like they would solve a use case gap I have. But, I saw a video for an app that was pitched and it hit a long-standing need I had that has heavy friction. It was an app that linked to Glaze, which is a product / service from Raycast. I read through the information about Glaze and thought this could be “interesting”. I had trouble finding the app that caught my interest as the Glaze app marketplace is a mess. I finally found the app, looked at the descriptions and images and figured I’d give it a go. I found I had to download the Glaze app to seemingly run the app I wanted within Glaze. This was less than optimal putting a silo wrapper around apps, that has never worked well and there is a long and abundant history of attempts at this poor model. (An app with scripts and workflows that can be added through a marketplace / gallery like Raycast or Alfred is a good model, but full apps that is a very different story).

The Needed Perspective Framing (Likely to be skipped to preserve a rant)

I’m not adverse to people using coding assistance, but there is a lot more to building an app or script than just code (and often being a developer or engineer helps keep the AI coding assistance in check as they can resurface long gone poor practices that are abundant in the training material). Not having background in development nor product management nor design creates a lot of gaps and little depth to know if something is actually good or not.

I’ve Seen this Movie Before and …

I opened Glaze and got the app I had interest in set up, and it was slow, not well considered with limited functionality that would be helpful for a basic app in the genre it sat in. The hope I had was shot, I was rather disappointed (it happens a lot) with the level of a “proof of concept” build that only examines is something possible to let you then you interrogate the hell out of it to figure out what is wrong and how to improve it before you get to the prototype or alpha version. I shut the app and won’t open it again.

I looked at other apps in Glaze. All I looked at had the same level of quality (or I should say lack of quality and basic understanding of what an app is, let alone what a product is).

I jumped to the four cornerstones, as I would on something I was building or running a product group that is creating and developing. Things were sort of usable, but half a cornerstone doesn’t get you very far. There is a lot to know and understand beside an interface that does something and I haven’t found AI services that fill much of this ground that needs to be covered in a solid manner. They can help code decently on small-ish projects (and slightly larger) and get okay (yet often problematic) interfaces. But, the other considerations and forward-looking needs to plan for or at a minimum consider so to account for future adaptation are missing or not supported well. The person building has to bring that understanding with them to drive this to a decent outcome.

Creating an app seems easy but there is a lot that should be considered and accounted for in the process, even for something simple. Putting out what will soon be abandoned ware with a “developer” / creator that didn’t quite ship something solid and left it at that, and not to return.

It May be an Idea Farm

There are a lot of great ideas in Glaze, but the lack of quality has me deleting the Glaze and adding a reminder to not go back. The deletion of Glaze took around 2 hours as the thorough app deletion tools I have were getting errors from many components claiming deletion was not permitted. This often happens when an app is running, but the app had been quit. It has been a long time since I’ve had to go through rounds of rebooting my Mac to rip out stubborn poor app remnants.

Know What You are Getting In To

There are people who have been building good niche products that have used AI to help fill gaps. Most of them have a lot of experience with UI, UX, product, and/or development to know what needs to be done at least at a basic level. Not all of them have worked through all four cornerstones, but they have considered them, and have lived through the hell from not considering and/or working through the cornerstones.

Four Cornerstones of Development

In the late 1990s through 2010s when working with development and product teams the four cornerstones of development were always at the tip of the tongue or as a small poster on a wall somewhere. I know I wrote this up somewhere before and likely presented it in the late 1990s and/or early 2000s. Working in enterprise environments where people would get involved in product and development, but don’t have background these cornerstones were essential to bring up as basics.

The last few weeks and months I’ve been thinking of this a lot and wanting to point to it, but realized it isn’t really on line other than a quick mention in a 2003 post of mine – Needs When Running a Service. Actually, it is something I am always wanting to point to. With the increase of vibe coding and people creating products for “unique” purposes, but then people are sharing these more widely than personal use, the need for understanding and considering what they are getting into is really needed.

The Four Cornerstones of Development

These four cornerstones were initially called out for information application development, but applied to all user-centered development and product management. If a team building didn’t focus on all four of the elements from the beginning to make the right decisions early (or have them framed and adaptable) the product was really going to struggle.

The four elements are: Usable; Reliable; Maintainable; and Repeatable.

In the current state of quick development by non-developers using LLM coding tools the only one of these cornerstones that is known or partly handled is the first cornerstone, usable. What is made may be usable, or mostly usable, but that won’t really last and when selling it, sharing it widely, or having others rely on it. The reality means the person developing and shipping has unintentionally signed up for things they don’t have background in and often the LLMs aren’t that helpful with. Much of what is coming out as apps are proof-of-concept level of completion, which doesn’t get into any consideration of the other three cornerstones.

Usable

Usable is the first hurdle and focusing on the user and their needs. If things aren’t usable the offering doesn’t really have much. The other cornerstones don’t really matter, if the offering isn’t usable. But, usable and not having the other cornerstones will be problematic.

To be usable, even if it is a single simple use case, how adjacent use cases that aren’t supported are handled or avoided should be as clear as possible. The capabilities and limitations being clear help with the ease of use and understanding something when someone hasn’t touched it in months.

Reliable

The reliable cornerstone is what starts making the offering stable, secure, and enduring. The bugs have been remediated and it works as intended continually. Security and levels of privacy considerations have been put in place and consistently work as intended. But, so do the core myriad of use cases that were intended to work and also be supported, continue to work.

Lacking reliability you have something that breaks at various stress levels and use cases (core uses cases or edge cases). Building and shipping requires setting bounds for what is supported and how, but also how well the edges of what is supported are handled.

Maintainable

Maintainable gets to the reality that products and shipping them doesn’t mean something is done when shipped, it is the beginning. When planning out what is being built how it will be maintained over time and supported is essential. How will the product be updated to support changes to the coding language and/or operating system, and device updates. How do the regular changes in languages and operating systems get handled where security patches are made and break apps and services for users that use apps and services that aren’t updated.

User / customer support and how this is handled also falls into the maintainable cornerstone. Planning for maintainability and how that will be handled needs to include support as the two are often tightly related. When something breaks or doesn’t work as expected, that becomes support work. The support work is often related to considerations and steps (or not making them) the area of the maintainable cornerstone.

Repeatable

Repeatable is one that often gets left of consideration and one that is essential if what you built gets popular and scale. It is often thought of as something that may happen in the future, but understanding early on how to handle repeatability means it should be easier when the time arrives. Repeatability is needed when a server or service built on crashes and is not available or you need to replicate server backends for supporting the service as it scales (there are a lot of needs for repeatability, including building sandboxes to test and develop).

Everything changes as it scales and understanding that at the start of everything (product, organization creation, shared simple scripting project, etc.), gives a decent foothold to when growing and scaling hits. Planning not to scale is also an option, but often that can take just as much work as scaling and you need to be prepared for not scaling when others really want what you’ve made.

Not planning for this early and accounting for how to design the development of the app and/or services for this will lead to painful issues with growth or the reality of moving from one supporting backend server / service to another as things change (often more quickly than we expect).

Wrapping the Cornerstones to Help Make Decisions

The cornerstones were really helpful 20 to almost 30 years ago for a quick reality check for early early-stage planning and building something to ship. Building something and shipping it is the start, not the end. All four cornerstones will provide stability once things are shipped if you have planned understanding and using the cornerstones.

Today, much like early-ish web thinking of how far you want to open something up for use by others comes from considering the cornerstones. If all that is considered is just use and there is no interest in the other corner stones or just partial interest or capacity, it is likely good to keep the use of it limited to friends and or family, similar, or perhaps tighter.

Ross Has a Great HTML Tasting Menu

HTML tasting menu - Yesterday in the Homebrew Website Club - IndieWeb, Ross A. Baker shared a gem, which is an HTML Testing Menu that is a naked (no CSS nor JavaScript) HTML listing of all HTML elements with an example of its use. I have long wanted something like this for two reasons: 1) Seeing HTML with no JavaScript nor CSS and how an element displays natively before anything is added; 2) Have a base HTML to then link to a CSS style sheet to test it to see how it reacts with bare HTML and see what is missed or what isn’t displaying as expected.

In the early 2000s I had a basic HTML file that was similar to this, but I don’t think it had all the elements and mostly used it for the second use case, to test CSS that I or the teams I was working on or with were designing and building out. In the early 2000s it was relatively common to run into sites that were mostly straight up HTML with no or little CSS. Some of these pages used HTML to its fullest extent and did it incredibly well. I have a deep appreciation of others who use <dl>, <dt>, and <dd> properly and well.

I’ve picked up Ross’s page for my use to throw my CSS into to test, I as I haven’t had that in a long while. A tool like this with all the elements is really helpful. The Tasting Menu is also a really good run through to test yourself on some of the newer and more obscure HTML elements.

In the last 10 to 15 years I’ve worked with designers and developers on projects that have been using JavaScript frameworks and a quick fix isn’t available as they don’t quite understand HTML, nor CSS, nor the DOM (document object model) as it is natively and the structures available to make a one line modification aren’t available as they only understand the framework and can’t add proper structure to make the fix that should be quick. Often the change that should be 5 minutes is many hours and rebuilding. The, “my framework doesn’t have a module for that” is really tiresome, but the answer isn’t switching frameworks to get the modules it it is actually understand the digital environment you are working on.

To learn HTML elements, Ross’s Tasting Menu is a great place to start, as he also links out to MDN Web Docs, which is the best resource for HTML and CSS documentation that I know of.

Joy Filled Email about Poem1 Shipping

This weekend started with an email about something shipping that I’ve anticipated for nearly 2.5 years. In January 2024 Matt Webb posted about a hardware clock what shows AI created poems for all the times of a day on an e-ink screen. This was something that caught my interest, less for the AI and more for the whimsey. But, the other part of it was hardware and the adventure that brings.

Not Matt’s First Hardware Experience

Matt had been part of Webb and Schulze, which turned into BERG London that was highly innovative playing with ideas at the edges. One of their creations was little printer. Part of watching that journey was some of the creation and manufacturing of the hardware that Berg shared out.

With this poem clock that Matt named “Poem1”, he turned it into a kickstarter project, and that brought along with it a look into the creation of a hardware product as it really is for things not at the scale of tens of thousands, if not orders of magnitude higher. Hardware is hard for electronics with getting all the parts approved, and then lined up to run through production it is a painstaking process and incredibly long.

So Excited by the Email

When I saw the email I was excited, like one is for people finishing an around the globe sailing adventure or some other long arduous feat. Getting the device will bring enjoyment, but watching from the blog about the inception of the idea, through turning it into a Kickstarter project and the emails about progress and the long waits between emails when approval waits were happening (or looking for plan B or Q for dealing with a part change needed).

I am so happy for Matt and having his device out into the world in people’s hands shortly.

2025 Vanderwal.net Backend Modernization is Done

A couple years ago I thought I would update the backend code from PHP 5.6 to PHP 7 and initial progress on it was hindered by time available.

Planning the Modernization Work

A few weeks back I started looking at it again and mapped it out properly like a project. I realized PHP 7 was deprecated and I should really head to PHP 8, so that target was set. I was planning on keeping things relatively simple using a database connection quite similar to what I had used, but digging through PHP 8 books and resources on O’Reilly Learning Platform everything was using a newer more flexible method. After digging further I took the route that would take a bit more work modifying existing code (some going back to 2000 and 2001). But, as I dug into the work I realized I was only needing to modify and modernize about 20% to 30% of code on the pages and templates.

In doing this I also realized my old method of security around the system management backend was no longer working, so it had to be rewritten as well. That meant rebuilding the backend screens. Those updates went live two days ago on the 19th.

With that done it was back to the last third or so of the pages and templates that are public facing. I had already reworked the category output pages and adding pagination to them. No longer will all 121 Folksonomy categorized posts show up on one screen, only 15 at a time will. The “Personal” category has 369 posts (it is a blog so it is about me, you see, but just not all of it).

The RSS feed received a very minor update to RSS 0.92 to keep in line with many of the OG methods that remain.

The Actual Homepage has been Restructured

The homepage for vanderwal.net has been restructured to make it easier to find information that isn’t directly in the blog and I get emails and DMs about somewhat regularly. Moving it to two columns helped this. I do need to modify this to flex or grid CSS model as tweaking the layout was rather tedious.

This Modernization was like Changing the Plumbing and Wiring in a Building

This modernization was like bringing the plumbing and wiring of a building up to new building code. The walls and structure are all pretty much the same. The top layer stays the same for now.

This modernization does allow me to hopefully finish setting up webmentions, which I’ve had partly wired since around 2021 or so. I just need the last piece to that to work. There are also other IndieWeb related updates I’m planning on making and have been waiting to get this code updated before modifying and adding them into place. By the way, if you are running your own site and/or blog, the IndieWeb community has a gem. There are a lot of resources in their wiki and pages helping anybody with their own site.

The pagination for the blog is likely going to change from a date with month focussed pagination to a page model with the oldest selection being page 1. The archive page will get a long over due update so it doesn’t stop at 2003 (looks at calendar, yep it is out of date). I’m hoping to have an archive page that shows activity, but also addresses the different post types (essay, journal, and weblog) that only lasted the first few years, but also around the 2014 code update and site move the entry type template went missing.

The category listings pages will also likely get an update and the category page may likely get some ease of moving through the posts over time, beyond general pagination.

Assistance with the Update

This being 2025 the question pops up if and how I was using generative AI as part of this. I was using Claude.ai from Anthropic with some initial questions, then I’d head to O’Reilly’s resources to validate them and learn what I needed to know (it had been about 10 years since I was knee deep into PHP). When coding and modernizing the pages and templates I’d and hit defects I’d run those past Claude to sort out what the issue may be (sometimes missing “;”, others the new query wrapper and parsing method caused me to miss something, or I had deprecated code I hadn’t converted). Claude would point out my errors and instruct me how to correct it. Sometimes it would offer a few options for approaches (some were not quite right and others were good and I needed to select a path - after verifying and learning about them further). It also would crank out code. I gave Claude instructions not to bother with large chunks of my pages and code, which it left alone.

I use Claude stand alone and used is Project function to keep things focussed. I fed it the outlines and high level task areas I have in GitHub and Obsidian and it was keeping track of what was accomplished and how the work met the goals. The most impressive thing, compared to other generative AI options is it was very strict with identifying things not viable in PHP 8 (and its iterative versions) as nothing else did this well. Claude also had the code of pages and templates I had worked on and would point out I was using a structure and method in other page and ask if I shouldn’t use that practice on the page I just fed it to sort out some defect I was working through. My code has had four or more iterations over the 25 years and my early coding wasn’t so hot and still remained. Claude helped my code get more consistent, not by it fixing it, but pointing out I had something good and modern and I should keep consistent with that. By the last couple of templates I didn’t need to have Claude check them as they worked with my own editing, but I still fed them in as it seems to help improve suggestions and catching lack of consistency of my own doing.

A year ago I tried this with OpenAI and its ChatGPT and it was a hot mess. It couldn’t keep PHP versions correct. I try it with every update and I find it really problematic and what it outputs (code and other attempts) as nothing better than mediocre and often not correct.

IDE Use

In the last 10 to 15 years the IDE I’ve used to code and work on vanderwal.net has been from Panic and either Coda or now Nova, which have worked well. I have kept a good firewall between AI assistance and the IDE. I don’t mind type ahead suggestions. But, finding deprecated code to address was something I was going to need. Some friends suggested I try PhpStorm by JetBrains, which seemed good as I’ve used PyCharm a few times in the past and really enjoyed it. I knew I didn’t want VS Code near this, as I’ve pretty much had it with VS Code (I mostly use it with Python for data analytics) due to plug-in issues and lack of ease keeping projects separated.

I picked-up a trial of PHPStorm and after a day or so I had the hang of a good portion of what I needed to do. My favorite part is the setting the exact version of PHP you are working with. It highlights where there are errors and problems. In the last couple of days as I finally was getting the hang of PHP 8 and the methods I was regularly using PHPStorm was helping with type ahead suggestions (there were a few times where I accidentally triggered them when I didn’t want them and nearly turned of that functionality - control Z is your friend). PHPStorm also can make use of GitHub CoPilot, which I don’t find helpful with OpenAI connected to it, but is better with Claude Sonnet. The downside with CoPilot is it doesn’t have access to the Project space in Claude I’ve been working with and therefore its suggestions are less on target - CoPilot with Claude is light years better for PHP than OpenAI offerings). Essentially I didn’t use the incorporated genAI functionality and I was very happy with that setup.

Posting Ease

One of the things I’m looking forward to are slightly better methods for posting to this site and managing posts. Many of the steps beyond creating and posting are manual steps, like kicking off creation of the RSS feed (I do that after a quick review of the created post as it is live, I kick the RSS feed after that review). The alerting the media, or the alerts beyond basic RSS, is also a manual step done after that review. I may automate the combination of those two kicks after a review.

Link Like Bin 13 December 2014

Another week of cleaning up, organizing, and working out partly broken identity and still working to get that resolved. Just the second time in 14 years with a Mac that I have had something this bothersome, which is much better than the nearly monthly with prior OS and same “corporate” OS when working on client sites.

• Simplicity is Bliss “Omnifocus Perspectives Redux: Miscellaneous”
• Code of Ages
• How I Made — Instead of Spent — 26 Cents With a Mobile App - Interesting take on turning entertainment cycles into pay cycles with similar activities
• And a Child’s Robot Shall Lead Them
• Simon St. Laurent’s “Web by default”
• Joe Nocera “The New Republic’s Rebellion”
• Dana Milbank in Washington Post Opinions “The New Republic is dead, thanks to its owner, Chris Hughes”
• Andy Baio teaches his son video games historically
• Anil Dash on “How ThinkUp is doing as a business”
• Kevin Anderson “Strengthening communities and strengthening journalism”
• When A Branch Becomes The Root - This was the stand out of the week. I did light summary of it over at Personal InfoCloud “Design Fiction Futures for NYC Libraries”.
• Jessamyn West “Things That Make the Librarian Angry”