I’m interested in starting a daily log, similar to what Dave Winer and a few others I follow on Micro.blog are doing. I’ve tried starting one using Little Outliner a few months ago, but I never got around to keeping it up to date. I’m hoping for something that is a bit more fit for purpose: as much as outliners are useful — I use them for keeping notes for work — I’m not sure it’s the best tool for me for daily logging. There are a few other features that I’m looking for: such as the ability to record private entries, and maybe some very to-do base features.

So, I spent some time today kicking off a new Buffalo project to build something that I think might work for me. I managed to get something running privately, although it’s pretty bare bones at the moment. We’ll see down the line if I’ll actually use it.

I subscribe to a few blogs that are well known for posting daily. Today, one of them is late. “Why haven’t you posted today?”, I imagined asking them, slightly perturbed.

Then, I imagined them smiling and answering back: “Why haven’t you?”

I took the plunge and purchased Logic Pro today. Although the purchase itself is not super interesting, the fact that I’m putting that much money into a piece of software that’s only available for macOS is an indication that I’m now all in on Apple’s desktop platform.

This is something that I’ve been quite tentative about for a while. I first came to macOS in 2017 after using Linux for my home setup. Linux was great for software development but I wanted to get back into music production, something that Linux is not known for. I’ve never really used the Mac at this stage but I knew that macOS was a decent platform for both activities, so moving to it was enticing. It also helped that I learnt about the user experience of the macOS from all the Apple tech podcasts that I listen to, like ATP and The Talk Show.

But I tend to hedge these sort of moves, so even though I started using a Mac Mini, I didn’t commit to purchasing any expensive software (say, anything more than $30-50) that only runs on Apple’s platforms. I had my doubts that I’ll actually go back to Linux (I knew I wasn’t going to Windows though); and after using a Linux laptop for a couple of months, I remembered how Linux has still got some way to go to provide a great user experience. Nevertheless, I always felt that I needed an exit.

Well, that door is now closed. Purchasing the Nova text editor last month was probably the first indication that I’m intending to stay, and the purchase of Logic Pro today seems to have solidified it.

So I guess now I’m officially a committed Mac user.

Today is the last day of work for the year, and although I haven’t got much planned for the break, it would be good to have some time off.

I wonder if Tim Berners-Lee ever imagined that we would be using the web as a replacement for things like phones, radios, and televisions.

There are growing concerns, in the circles that I travel in, about the use of “free” email services like Gmail, that lock you into a service that may not have your whole interest in mind. The remedy for this is to use an email address with a domain that you control. Setting one up can seem a little daunting for those have haven’t done this: thanks to the wild west that is email, a hodgepodge of technologies have grown up in an attempt to stop the occurrences of spam and impersonations. The result is a series of DNS records that have to be set up for each email domain; each one that needs to be done correctly, lest your emails get rejected or your domain gets blacklisted.

I say this as someone that has experienced this myself: not only for my own domain, but also for a bunch of other domains that I was responsible for. As such, I had to have some understanding as to what each of these record types actually were. After a bit of experience doing this a few times, along with reading up on what these records are actually for, it felt right to put together this tour for anyone else looking to do the same.

This is by no means a complete how-to for setting up a new email domain, but rather a guide of the types of domain records that you will be dealing with. It is assumed that you, dear reader, are setting up a new email domain for use with an online email service, such as FastMail, Protomail or Hey.com. These services should have the tools and documentation detailing the specifics on how to setup a domain for their service. Each service might have slightly different requirements, so it’s always a good idea to read their instructions carefully, and give it a test before sharing your new email address around. Those setting up their own mail server fall beyond the scope of this post, although the general aspects will probably be applicable here as well.

So, without further ado, here are the domain records you’ll need for email.

MX: What Servers Should Email For Me Be Sent To?

The MX, or Mail Exchange record, is the simplest record to understand. It identifies the mail server that should be used to receive email that is addressed to you. Sending an email to someone@example.com, for example, will trigger the mail client to open a connection to one of the hosts listed in the MX for the example.com domain, in order to transmit the message.

Mail exchange hosts are specific by adding a domain record with the MX type¹. The value will consist if a number which indicates a priority, followed by a hostname or an IP address, e.g. 10 smtp1.mailserver.example.com. It’s possible to list multiple MX records for a single domain, with each one having a different priority. In general, a MX record with a lower priority will take precedence over one with a higher one.

SPF: What Servers Are Allowed To Send Your Emails?

SPF, or Sender Policy Framework, is a mechanism for declaring whether a specific mail server is permitted to send emails for a particular domain. It is used by remote mail servers receiving emails from your domain to confirm that they are coming from a mail server that you know about and have authorised to send emails on your behalf. The policy part are the rules governing this, and it’s up to the domain owner to specify what these are. The rules themselves are are quite expansive; and can include things like how to handle email that did not come from a server that you control – as would be the case for email sent from spambots pretending to be from you — along with referencing policies defined in another domain.

A SPF policy is declared for a domain using a TXT record type². The value will be something that starts with v=spf1, followed by the actual policy specific in a simple domain specific language. The mail service that will usually indicate what you should use for an SPF policy, and there will usually be one SPF record for each email address domain.

SPF itself does not given total protection over those attempting to impersonate a sender from your domain. It will only verify that the email “envelope” is from the domain that you can control. But a single email may be transmitted via multiple servers, with each of these “hops” using a new envelope and thereby being subjected to a different SPF policy. We need one more thing to verify the original message end-to-end.

DKIM: Is The Email Really From You?

DKIM, or DomainKeys Identified Mail, verifies that the actual message itself is really from you. Once the email reaches the final destination, the receiving mail server can confirm that the message is from you using the DKIM records that are stored against that domain. The specifics on how this is done is beyond the scope of this post, but the short version is that a cryptographic signature is created when the mail is sent, and the receiving mail service can use the public keys stored in the DKIM records to verify that the signature is correct.

DKIM records can either be TXT or CNAME records. They will usually have names like <something>._domainkey; and either a large value beginning with v=DKIM1 if they are a TXT record, or a reference to another domain if they’re a CNAME records. You may get two or three DKIM records for each domain that you register, each one with a slightly different names.

It should be noted that this is not the complete list of domain records that are available for dealing with email. This is also DMARC which extends these two policies, and is available if required. I personally have not had to set up a DMARC record for the domains that I had to deal with, so there is not much I can say about it.

I hope you found this post useful. General information about the various technologies required to setup a domain for email delivery was hard to come by, and I’d wish a post like this was available to me when I was first learning how to do this.

Follow up from yesterday’s post about my non-reading habits, a colleague of mine shared this article about the topic. It looks like the condition I have is tsundoku, which is “a Japanese term used to describe a person who owns a lot of unread literature.”

There’s a lot to like about Go, and I’ll happily admit being a huge fan of the language. But it will be dishonest of me not to acknowledge that some aspects of programming in Go results in more code than the equivalent in another language. My guess is that the best example of this is how Go programs deal with errors.

For those unfamiliar with how errors work in Go, the short version is that they are just like any other type that you deal with — like strings and integers — and they have no special control structure to handle them in any specific way. This means that, unlike languages that have exceptions, there is nothing like try/catch blocks; you are left with the standard control statements that are available.

The result; you will fall into the practice of having a lot of code that looks like this:

func doStuff() error {
	firstResult, err := doFirstThing()
	if err != nil {
		return err
	}
	
	secondResult, err := doSecondThing(firstResult)
	if err != nil {
		return err
	}
	
	lastResult, err := doOneLastThing(secondResult)
	if err != nil {
		return err
	}
	
	return processResult(lastResult)
}

This is not bad in-and-of-itself, but it does have some shortcomings over the equivalent in languages that use exceptions. The use of an if block after every call to a “do function”¹ adds a bit of noise making it harder to separate the happy path from the error handling. And although the code is technically correct — whereby the errors are being handled appropriately — you may come to wonder whether this could be done in a nicer way.

This post explores some alternatives for dealing with Go errors. It is by no means exhaustive; it’s just a few patterns I’ve found works for me. It is also by no means suggestive that you even should use one of the alternatives. Each use case is different; and one alternative might be a better solution in a particular case, but dramatically worse in another. Everything in coding, much like life itself, is a tradeoff, and I would suggest being mindful of the potential costs of adopting any one of these options alongside the benefits they may bring.

With that said, let’s look at some alternatives.

Option 0: Keep It As It Is

This is probably not an option that you’d like to hear, but it is one worth considering if the function is small enough, and you don’t have the ability to change the functions you are calling. As ugly as the code looks, it does have some advantages:

• It makes the erroneous path crystal clear: it indicates that any one of these operations can fail with an error, and that it is the job of the function to handle it in some way, even if it is simply returning it as it’s error.
• It makes it reasonably easy to move things around or change how the error is to be handled: if doSecondThing returns an error that no longer blocks the call to doOneLastThing, you only need to adjust one if statements. This is harder to do in any generic solution you may adapt.
• It provides an incentive to keep functions small: for example, if there is a need to expand the number of operations from 4 to 30, and each operation returns an error that needs to be handled, then that would impart a large enough pressure to refactor the code, and break it up across multiple functions.

So I’d recommend considering this as a viable option first, if only briefly. Spending effort on a solution that may look neater can actually have the opposite effect of making the code less understandable, while also making it harder to maintain.

Option 1: Don’t Handle The Error

No, don’t go. Let me explain.

This is not a viable option if you are writing code intended for a production setting. Arguably, if something can fail in some way, you should handle it. But I’m listing this option here as it is an alternative to the if statements above if one of the following scenarios is true:

• The functions don’t return errors: they may be required to implement a type that does, but if it is clear within the public documentation that they never do, then there is no real need to handle the error. Some care will need to be observed in this case though: public documentation is not the the same as an API, and depending on who’s maintaining these functions, it is very possible that, down the line, the implementor takes advantage of the error return type, and starts returning them.
• The error can be safely ignored: this might be test code, or code that is written once, then thrown away. In these case, it may not be worth your while adding support for error handling if it provides no real value.

Adopting this option may make the function look like the following. It may not be possible to simplify further unless you can actually change the return type of the “do functions”; in which case, there are no errors that need handling.

func doStuff() error {
	firstResult, _ := doFirstThing()
	secondResult, _ := doSecondThing(firstResult)
	lastResult, _ := doOneLastThing(secondResult)
	
	// You can probably ignore this error as well, but it's simpler to just return it
	return processResult(lastResult)
}

Option 2: Use Panic

The second option is to use panic to throw the error, and handle it in a single defer and recover handler.

A first draft of this solution may look something like the following:

func doStuff() (err error) {
	defer func() {
		if e, isErr := recover().(error); isErr {
			err = e
		} else {
			panic(e)
		}
	}()
	
	firstResult, err := doFirstThing()
	if err != nil {
		panic(err)
	}
	
	secondResult, err := doSecondThing(firstResult)
	if err != nil {
		panic(err)
	}
	
	lastResult, err := doOneLastThing(secondResult)
	if err != nil {
		panic(err)
	}
	
	return processResult(lastResult)	
}

which is not much better than what we had to begin with. However, if we can modify the “do functions” themselves, we can replace them with versions that panic instead of return an error. These new “must do functions” — so named as the must prefix is used to indicate that they will panic if things go wrong — can bring out the happy path quite clearly:

func doStuff() (err error) {
	defer func() {
		if e, isErr := recover().(error); isErr {
			err = e
		} else {
			panic(e)
		}
	}()
	
	firstResult := mustDoFirstThing()
	secondResult := mustDoSecondThing(firstResult)
	lastResult := mustDoOneLastThing(secondResult)
	mustProcessResult(lastResult)
		
	return 
}

This can be improved further if the “do functions” actually return values of the same type. For that, we don’t actually need to replace the function. Instead, we can build a function that simply takes the result and error, and either return the result or panic depending on whether an error was returned²:

type doResult struct { ... }

func must(res doResult, err error) doResult {
	if err != nil {
		panic(err)
	}
	
	return doResult
}

func doStuff() (err error) {
	defer func() {
		if e, isErr := recover().(error); isErr {
			err = e
		} else {
			panic(e)
		}
	}()
	
	firstResult := must(doFirstThing())
	secondResult := must(doSecondThing(firstResult))
	lastResult := must(doOneLastThing(secondResult))
	
	if err := processResult(lastResult); err != nil {
		panic(err)
	}
		
	return 
}

This will work, but I’d argue it’s not the best use of panic. Go panics should be reserved for unexpected errors, instead of as a poor substitute for exceptions. Instead, I suggest the following option, which provides a nicer API while maintaining the principal of errors as values.

Option 3: Encapsulate The Error Handling Using A Dedicated Type

This is probably my preferred option of the three. Basically, the idea to track the state of the error using a dedicated type, and wrapping the functions that return errors within methods that don’t. The methods will be defined on the type that is maintaining the error state, and each one will check whether an error has been raised before invoking the wrapped function. Finally, the struct will offer a way to get the error, so that it can be logged or returned.

The way this looks in code would be the following:

type DoOperations struct {
	err  error
}

func (d *doOperations) DoFirstThing() (res doResult) {
	if d.err != nil {
		return doResult{}
	}
	
	res, d.err = doFirstThing()
	return
}

func (d *doOperations) DoSecondThing(op doResult) (res doResult) {
	if d.err != nil {
		return doResult{}
	}
	
	res, d.err = doSecondThing(op)
	return
}

// Likewise for doOneLastThing and processResult

func (d *doOperations) Err() error {
	return d.err
}

Then, the our new function will simply become:

func doStuff() error {
	ops := new(doOperations)
	
	firstResult := ops.DoFirstThing()
	secondResult := ops.DoSecondThing(firstResult)
	lastResult := ops.DoOneLastThing(secondResult)
	ops.ProcessResult(lastResult)
	
	return ops.Err()
}

This gives us the ability to write a function with the happy-path clearly shown while still maintaining best practices around error handling.

As nice as this is, the one downside is that this type is specific to the set of operations that we need to deal with. If this is the only function that needs to perform these operations, then the additional maintenance overhead might not offset the nicer API that this gives you. But if you find yourself writing out this sequence of operations in a variety of different ways, it may be worth your while to consider this approach.

To Be Continued

It’s very likely that this topic may be revisited as the Go language evolves. With the design of type parameters imminent, and discussions around adding language features to make error handling nicer in general, additional options may become possible down the line. But for now, these are the options that seem like current viable alternatives to the function-call-then-if-block pattern seen in a lot of Go code.

I don’t know if it’s just me, but I’ve got this annoying habit of seeing an article that looks interesting, and I decide to… just not read it. Instead I “save it for later”. The result: I end up never reading the article at all.

It’s a shame that more and more bloggers are moving to email newsletters in leau of RSS. Even for bloggers that don’t charge for their content, I’m seeing more blogs that are encouraging readers to sign up to an email newsletter, instead of providing a link to an RSS feed.

I can see why they do this. Email addresses are valuable, and sites like Stratechery and services like Substack show that it’s possible to have a viable business writing a daily newsletter to people willing to pay for it. But one thing Ben Thompson offers that Substack doesn’t is a private RSS feed for subscribers, so they can read the daily updates within a feed reader. This is how I use to consume Stratechery, before the release of the daily update podcast.

So email subscriptions makes sense for those writing for a living, but I’m not sure it makes sense for those maintaining a free blog. If your content is available without charge, then it makes sense to me to offer an RSS feed to those that prefer to read your content within a feed reader. The reading experience in NetNewsWire is preferable to the one offered by my email client, and I don’t need to see all the emails that I’m trying to avoid. By all means offer email subscriptions as well, but don’t require one just so that I can see your latest updates.

I love the idea of events like Microblogvember to help reinforce the act of writing frequently. I will admit it was difficult at times, but I definitely find it beneficial participating in these events when they come around. #mbnov

It’s interesting how the activities that would have seen quite pedestrian before the lock-down, like going to a cafe, are quite novel after the lock-down. #mbnov

It’s surprising how quickly you can get use to a mask outside when you’re required to wear one, and then get use to not wearing one outside when you’re not. #mbnov