I wish I’d retired before the industrial revolution of computer programming happened, but I have not and cannot. So I must come to grips with the fact that in many cases, AI-powered tools can do a perfectly fine job of writing code. The following is a brief pursuit of the facts as I see them and I just can’t see how in any professional workplace, it makes sense to write code by hand any more.
Beginning a job search, it’s clear that to stay in technology means to be in the orbit of AI and AI-generated code, and I need to come to terms with this and figure out how to navigate it. As such, I’m going to start writing more about AI. I process information via writing, so here we are.
I joined Jared again on the Dead Code Podcast to go a bit deeper on my post, The Death of a Software Craftsman. The outlook is kinda bleak, but plenty of digs at agile software practices :)
Almost a year ago, I returned to the Linux Desktop after almost 20 years. I abandoned it a month or so later out of frustration with a surprising lack of configurability and general exhaustion of addressing the myriad papercuts that come with trying to change computing platforms.
In the last few weeks, I’ve revisited it and had a lot more success.
I created pwa.support as a way to both examine any website to see if it can be installed as a progressive web app, but also to capture in some detail the depressing state of support for this concept across major browsers and operating systems.
The death of a software craftsman
Well, it happens a lot ‘round here
You think quality is a common goal
That goes to show how little you know
Developers work hard over the years to cultivate tools and techniques to improve the quality of the construction of their software. These tools and techniques are slowly becoming even more useless than they may already be. We must adapt by either going all-in, totally opting-out, or finding a middle ground by tracking the AI code-generation craze to fill the gap as a hand-coding artisan.
I recently got to chat with Jared Norman on the Dead Code Podcast. We talked mostly about Brut, but also a bit about hardware synthesizers and looptober.
If you want to know about more about why Brut exists or its philisophical underpinnings, check it out!
I’ve thought deeply about building CLIs and built a
lot of them over the years. I’ve used Rake, Thor, my own gem GLI and many others. After all that, the venerable OptionParser—part of
Ruby’s standard library—is the best choice for scripting and sub-command (git-like) CLIs. I want to show you how.
I created a short (8 minute) screencast on adding a confirmation dialog to form submissions using BrutRB’s bundled Web Components. You don’t have to write any JavaScript, and you can completely control the look and feel with CSS.
There’s also a tutorial that does the same thing or, if you are super pressed for time:
<form>
<brut-confirm-submit message="Are you sure?">
<button>Save</button>
</brut-confirm-submit>
</form>
<brut-confirmation-dialog>
<dialog>
<h1></h1>
<button value="ok"></button>
<button value="cancel">Nevermind</button>
</dialog>
</brut-confirmation-dialog>
Progressive enhancement, and no magic attributes on existing elements.
When a system isn’t working, it’s far easier to debug the problem when that system produces good error messages as well as useful diagnostics. Silent failures are sadly the norm, because they are just easier to implement. Systems based on conventions or automatic configuration exacerbate this problem, as they tend to just do nothing and produce no error message. Let’s see how to fix this.