A meandering post about the joys of Scheme and working harder to do simple things.

Table of Contents Overview In the Beginning Final Totals Writing in Chicken Scheme Delusions of Sharability Crystal Lang Final Totals Writing in Crystal Fast-Forward… And then Raku Final Totals Writing in Raku Reflecting on the rewrites If you liked that… P.S. What about the email app with the same name? Overview “Hey!” started as an Interruption Tracker, and now supports Time Tracking too. It has been through 3 iterations: Chicken Scheme, Crystal, and now Raku.

Table of Contents Quick Summary It started as a joke… The work Begins… Generating images Prepping images RedBubble The site Know Thyself That Sweet Marketing Copy Final Thoughts Will I share my code? What’s my favorite? So Many Images Quick Summary I used Midjourney to generate art that I threw on t-shirts, coasters, and almost everything else RedBubble offers. Then I used OpenAI to generate copy for it, and combined that with a handful of custom scripts to generate a product site called Bed Bath & The Beyond.

Summary While leaving "private comments" on a repo can be incredibly useful, it can get you into trouble if the wrong person sees them and disagrees with what they see. This post goes into the problems, consequences, and things that tools that provide this functionality need to do to protect their users from accidental harm. Some Context A while ago I wrote a tool called "Private Comments", which allows you to leave "private comments" on a codebase that aren't actually in the codebase.

This post describes how to make high quality recordings of terminal sessions that can be replayed in the terminal, or shared on the web. I'm defining high quality as recordings with zero typos, and relatively controlled timing between commands. Jump to the end to see an example of the type of output I'm talking about. Why? Videos and gifs take up a lot of disk space, don't age well as display technology improves, and are problematic for folks low vision requirements.

A quick post to help future Raku geeks understand a couple of confusing error messages: expected Positional[Array] but got Array and expected Associative[Hash] but got Hash These are conceptually the same problem. If you've received one of these errors it means you've double-specified your parameter by using the @ or % and Array or Hash. A parameter of Hash %foo says "I would like to be passed something that implements Associative and has a Hash in it.

Table of Contents Overview The Goal The Process The Learnings Overview Following on the heels of my last post on why you should (not) self host your git repos, I went ahead and used Gitea to set up a local mirror of all my repositories, and all the repositories I don’t want to loose access to. The results were surprising, and after reading this, you might want to do the same.

Table of Contents Why You Should Self-Host ➠What about GitLab and other Competitors? Why You Shouldn’t Self-Host So what’s a geek to do? What am I going to do? Once upon a time, GitHub was a successful geek enterprise. Then Microsoft bought it, and folks started arguing that you should abandon ship. You should self-host your repos they say. I 100% agree, and 100% disagree. Let me explain. GitHub’s been a benevolent host.

The Problem For the past decade or so, I’ve noticed a trend amongst my coworkers. When they need to look at the contents of a file that they’re not currently editing, they will go to GitHub, and click their way down through the folder structure until they eventually find the file they want to see the contents of. On a related note, I believe that most of my coworkers don’t know how to take a relative path in a repo, and tell their text editors to open it.

In 1981 Robert Cox came up with a slogan for Ford; “Quality is Job 1”. It has always stuck with me. In the software industry there are few slogans could be further from the truth. C-level’s and other customer facing types frequently proclaim the “quality” of their products, but they aren’t the ones making the product. They’re frequently not even the ones using the product. In software there are two viable ways to release quality software.

Writing code is a lot like maintaining a Bonsai Tree. If you stop pruning it it’ll stop being a Bonsai and turn into a bush. Little tweaks, frequently aesthetic ones, will help to keep it beautiful and under control. It will still grow in unexpected directions, as other developers make changes, but careful pruning will keep it balanced, and healthy. What is “careful pruning” then? Each file is a branch on our tree.

Testing as a process of discovery The other day a coworker said, Some times you get situations where the specification for the unit or module you are writing just are not available. The code writing is a discovery process as much as anything else. Moreover, some of the packages and methods being called don’t have predictable or documented behavior. That’s ugly and horrible, and I don’t know how that’s allowed, but nonetheless, from the perspective of someone who wants to do unit testing in such an environment, can you give any tips?

Code Underwriters Lloyds of London is able to do what they do thanks to the concept of underwriters. The simplistic version is that a risk is spread amongst a group of underwriters. If nothing goes wrong they get a cut of the profits relative the the percentage of the risk they took on. If things go wrong they take pay for whatever portion of the risk they agreed to take on.

Defensive Programming 101 For any given programmer the following statement should always be treated as truth: My code sucks, but your code sucks more - Dave Astels [deleted post] Good version control habits and test coverage will get you out of most jams related to your own code but we rarely write apps that are comprised of just our code. There are almost always libraries from other people code that you’ll include to save yourself from having to re-invent the wheel.

99 lines of code on the wall. 99 lines of code. You look around, refactor it down… 98 lines of code on the wall. 98 lines of code on the wall. 98 lines of code. You look around, refactor it down… 97 lines of code on the wall. Or, alternately function singVerse(numLines){ if (numLines \> 0){ document.write("" + numLines + " lines of code on the wall.\\n"); document.write("" + numLines + " lines of code.

If you’re reading this blog there’s a fair chance you’re a programmer and that means that from time to time you’ll encounter people who want advice on leaning how to program. Unfortunately, it’s hard to point them in the right direction because we generally don’t want to spend the time to teach them ourselves and even if we did most of the learning to program books just plain suck. So, I’d like to recommend two books.

Another graph for another friend who asked for a flow chart of the branching and merging described in Best Practices for Web Development html pdf. Update: Michael says: I’m a little unsure, from you diagram, how, if your trunk contains two completed and merged features that aren’t yet live (video upload and REST API, say) you put one feature live without putting the other live. It looks like code only gets to the live branch via the trunk, but it seems from your diagram that the trunk could contain all manner of complete and semi-complete features.