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. This post is a high-level developer’s diary of what I wrote, why I rewrote it, and what I learned along the way.

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.

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. This post will be a qick overview of how I did it, some tips that’ll help, and what I learned as a result.

Table of Contents

1. Why You Should Self-Host
2. ➠What about GitLab and other Competitors?
3. Why You Shouldn’t Self-Host
4. So what’s a geek to do?
5. 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. When they bought NPM they went from being a de facto piece of internet infrastructure to an actual piece of critical infrastructure. At this point you may as well argue that we should sever our connection to the electric company.

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. You can release it when everything you want done is done, or you can release what you happen to have done at a specific date. You can’t combine the two, although almost every software company tries to.

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. The methods, are leaves. We come in to work and start examining one of the branches. Some days we need to encourage it to grow a specific way by adding a feature. Some days we make little snips to correct a bug. But what happens if, upon examining your branch for other reasons, you discover that it’s grown into spirals and knots. You can’t reach your clippers in to snip the leaves you need. You can’t do much of anything without difficulty and frustration, and frankly, it looks like crap. The unexpected spirals and knots need to go.

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? I mean, do you mock up approximations to what you think these external things should be doing if you really don’t know what they are doing? Do you do your best, updating mocks and tests, “in the face of adversity”?

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. Obviously you don’t want to start writing unit tests for code from other projects (you’d never finish) but there are some basic steps you can take to minimize your chances of failure.\

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.\\n");
            document.write("You look around, refactor it down...\\n");
            numLines -= 1;
            document.write("" + numLines + " lines of code on the wall.\\n");
            singVerse(numLines);
        } else if (numLines == 0) {
            document.write("Totally bug free code on the wall\\n");
        } else {
            document.write("Need more tests for the code on the wall.\\n");
        }
    }
    singVerse(99);

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. The first is Learn to Program by Chris Pine.This is the best intro to programming that I’ve ever seen. It’s not concerned so much with how to do things in a specific language as it is with teaching people the basic principles of programming although it uses Ruby to do so. It’s based on a series of tutorials that are still online but have been improved on, and expanded upon greatly in the book.

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.