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 isntalled 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.
This is a whirlwind tour of the basics of Brut, where I build a blog from scratch in a bit over 15 minutes. The app is fully tested and even has basic observability as a bonus. The only software you need to install is Docker.
Brut aims to be a simple, yet fully-featured web framework for Ruby. It's different than other Ruby web frameworks. Brut has no controllers, verbs, or resources. You build pages, forms, and single-action handlers. You write HTML, which is generated on the server. You can write all the JavaScript and CSS you want.