When I moved to the UK some years ago, I developed a strange new fear that I was unfamiliar with. Despite living alone for many years at that point, it was the first time I was living abroad. For the first time, I realised that I was hundreds and hundreds of miles away from my parents. I suddenly became afraid of being far from my parents should something happen to them. This new anxiety took over my life. I was finding myself crying over things that hadn’t happened yet. I was also saving money if I needed to buy a last-minute flight. It was one of the reasons why I did therapy some years ago. I needed to let go of things I couldn’t control.

Then the pandemic happened. Something I didn’t even think could happen: flights were grounded. I was terrified that my parents would become seriously ill and I couldn’t see them, just like it happened to loads of people. I was not seeing my parents in person for nearly two years, but we made it.

Three months ago, my biggest fear happened. My dad passed away suddenly, and no money in the world and no amount of anxiety helped me be prepared for it. I got a phone call from my uncle informing me that my dad was suddenly in terrible shape and that it didn’t look good. He told me I should arrange to fly as soon as possible. It was evening, so I only had flights the next day. When I finished booking a flight, I got a phone call telling me my dad had passed away. I wasn’t on time. My biggest fear happened.

In this blog post, and in no particular order, I will share some of my favourite memories with my dad.

My dad used to call me whenever “In the Shadows” played on the radio and put his phone down for me to listen. He knew it was my favourite band and was excited for me every time they played on the radio.

My dad took me to see The Rasmus live in 2005. I was there for hours, queuing to be in the front row. My dad and mum went out for dinner and returned to the venue when the opening act started, and all the fans were already inside. My dad met the band and scored himself row 0 tickets and a free drink! Incredible!

I remember when he taught me how to ride a bicycle.

When I was tiny, we were walking somewhere, and I kept finding money on the floor, and I was over the moon! Turns out my dad was pranking me by throwing money on the floor without me noticing.

Almost every Christmas, there would be fun and complicated wrapped presents, surprises and pranks.

He would play with me and my little friends at my birthday parties when I was little.

His reaction when I shared that I was pregnant.

Our last Christmas together, the first with his granddaughter.

I miss you every day, dad.

We can't trust browsers because they are designed to execute arbitrary code from website publishers. One of the biggest protections we have is Cross-Origin Request Sharing (CORS), which prevents JavaScript from making HTTP requests to different domains than the one the page is running under.

<Mimi> Cross-Origin Request Sharing (CORS) is a mechanism that allows web browsers to make requests to servers on different origins than the current web page. An origin is defined by the scheme, host, and port of a URL. For example, https://example.com and https://example.org are different origins, even though they have the same scheme and port.

The browser implements a CORS policy that determines which requests are allowed and which are blocked. The browser sends an HTTP header called Origin with every request, indicating the origin of the web page that initiated the request. The server can then check the Origin header and decide whether to allow or deny the request. The server can also send back an HTTP header called Access-Control-Allow-Origin, which specifies which origins are allowed to access the server's resources. If the server does not send this header, or if the header does not match the origin of the request, the browser will block the response.

Fresh is a web framework for Deno that enables rapid development and is the thing that I am rapidly reaching to when developing web applications. One of the big pain points is making HTTP requests to a different origin (such as making an HTTP request to api.example.com when your application is on example.com). The Fresh documentation doesn't have any examples of enabling CORS.

In order to customize the CORS settings for a Fresh app, copy the following middleware into routes/_middleware.ts:

// routes/_middleware.ts

import { MiddlewareHandlerContext } from "$fresh/server.ts";

export async function handler(
  req: Request,
  ctx: MiddlewareHandlerContext<State>,
) {
  const resp = await ctx.next();
  resp.headers.set("Access-Control-Allow-Origin", "*");
  return resp;
}

If you need to customize the CORS settings, here's the HTTP headers you should take a look at:

This should fix your issues.

A few years ago I gave a short talk (slides) about myths that discourage people from blogging. I was chatting with a friend about blogging the other day and it made me want to write up that talk as a blog post.

here are the myths:

• myth: you need to be original
• myth: you need to be an expert
• myth: posts need to be 100% correct
• myth: writing boring posts is bad
• myth: you need to explain every concept
• myth: page views matter
• myth: more material is always better
• myth: everyone should blog

myth: you need to be original

This is probably the one I hear the most often – “Someone has written about this before! Who’s going to care about what I have to say?“.

The main way I think about this personally is:

1. identify something I personally have found confusing or interesting
2. write about it

The idea is that if I found it confusing, lots of other people probably did too, even though the information might theoretically be out there on the internet somewhere. Just because there is information on the internet, it doesn’t get magically teleported into people’s brains!

I sometimes store up things that I find confusing for many months or years – for example right now I’m confused about some specific details of how Docker networking works on Mac, but I haven’t figured it out enough to be able to write about it. If I ever figure it out to my satisfaction I’ll probably write a blog post.

Sometimes when I write a blog post, someone will link me to a great existing explanation of the thing that I hadn’t seen. I try to think of this as a good thing – it means that I get a new resource that I couldn’t find, and maybe other people find out about it too. Often I’ll update the blog post to link to it.

A couple of other notes about this one:

• technology changes, and the details matter. Maybe the exact details about how to do something have changed in the last 5 years, and there isn’t much written about the situation in 2023!
• personal stories are really valuable. For example I love my friend Mikkel’s Git is my buddy post about how he uses Git. It’s not the same way that I use it, and I like seeing his approach.

a bit more about my love for personal stories

I think the reason I keep writing these blog posts encouraging people to blog is that I love reading people’s personal stories about how they do stuff with computers, and I want more of them. For example, I started using a Mac recently, and I’ve been very annoyed by the lack of tracing tools like strace.

So I would love to read a story about how someone is using tracing tools to debug on their Mac in 2023! I found one from 2016, but I think the situation with system integrity protection has changed since then and the instructions don’t work for me.

That’s just one example, but there are a million other things on computers that I do not know how to do, where I would love to read 1 person’s story of exactly how they did it in 2023.

myth: you need to be an expert

The second myth is that you need to be an expert in the thing you’re writing about. If you’ve been reading this blog, you probably know that I’ve written a lot of “hey, I just learned this!” posts over the years, where I:

1. Learn an interesting thing (“hey, I didn’t know how gdb works, that’s cool!”)
2. Write a short blog post about what I learned (how does gdb work?)

You actually just need to know 1-2 interesting things that the reader doesn’t. And if you just learned the thing yesterday, it’s certain that lots of other people don’t know it either.

myth: posts need to be 100% correct

I try to my make my posts mostly correct, and I’ve gotten a bit better at that over time.

My main strategy here is to just add qualifiers like “My understanding is..” or “I think..” before statements that I’m not totally sure of. This saves a lot of time fact checking statements that I’m honestly not sure how to fact check most of the time.

Some examples of “I think…s” from my past blog posts:

I think people are replacing “how many golf balls can fit in the Empire State Building” with more concrete [interview] questions about estimating program runtime and space requirements.

I think the most important thing with bridges is to set up the route tables correctly. So far my understanding is that there are 2 route table entries you need to set: …

Etsy uses PHP, which I think means they can’t have long-lived persistent TCP connections

I think the MTU on my local network is 1500 bytes.

I still don’t know if all of those statements are true (is it true that PHP programs can’t have long-lived persistent TCP connections? maybe not!), so the qualifiers are useful. I don’t really know anything about PHP so I don’t have much interest in fact checking that PHP statement – I’m happy to leave it as an “I think” and potentially correct later it if someone tells me it’s wrong.

I do tend to overdo the “I think that…” statements a bit (bad habit!) and sometimes I need to edit them out when actually it’s something I’m 100% sure of.

myth: writing boring posts is bad

The reality of publishing things on the internet is that interesting things get boosted, and boring things get ignored. So people are basically guaranteed to think your posts are much more interesting that they actually are, because they’re more likely to see your interesting posts.

Also it’s hard to guess in advance what people will think is interesting, so I try to not worry too much about predicting that in advance. I really Darius Kazemi’s How I Won The Lottery talk on this topic about how putting things on the internet is like buying lots of lottery tickets, and the best way to “win” is to make a lot of stuff.

myth: you need to explain every concept

It’s common for people writing advanced posts (like “how malloc works”) to try to include very basic definitions for beginners.

The problem is that you end up writing something that feels like it wasn’t written for anyone: beginners will get confused (it’s very hard to bring someone from “I have no idea what memory allocation is” to “in depth notes about the internals of malloc” in a single blog post), and more advanced readers will be bored and put off by the overly basic explanations.

I found that the easiest way to start was to pick one person and write for them.

You can pick a friend, a coworker, or just a past version of yourself. Writing for just 1 person might feel insufficiently general (“what about all the other people??“) but writing that’s easy to understand for 1 person (other than you!) has a good chance of being easy to understand for many other people as well.

writing has gotten harder as I get more experienced

Someone who read this mentioned that they feel like writing has gotten harder as they get more experienced, and I feel the same way.

I think this is because the gap between me and who I’m writing for has gotten a bigger over time, and so it gets a little harder for me to relate to people who know less about the topic. I think on the balance having more experience makes my writing better (I have more perspective!), but it feels harder.

I don’t have any advice to give about this right now. I just want to acknowledge that it’s hard because someone who read a draft of this mentioned it.

myth: page views matter

I’ve looked at page view analytics a lot in my life, and I’ve never really gotten anything out of it. Comments like this one mean a lot more to me:

Hey, @b0rk. Just wanted to let you know that this post really helped me to improve my skill of understanding a complex concept. Thanks! :)

If it helps one person, I figure I’ve won. And probably it helped 10 other people who didn’t say anything too!

myth: more material is always better

I appreciate the work that goes into extremely deep dive blog posts, but honestly they’re not really my thing. I’d rather read something short, learn a couple of new things, and move on.

So that’s how I approach writing as well. I’ll share a couple of interesting things and then leave anything extra for another post. For me this works well because short posts take less time to write.

This one is obviously a personal preference: short posts aren’t “better” either, I just like them more.

But I often see people get tripped up by wanting to include EVERYTHING in their blog post and then never publishing anything and I think it’s worth considering just making the post shorter and publishing it.

some notes on pedantic/annoying comments

Someone who read a draft of this mentioned struggling with comments that are pedantic or annoying or mean or argumentative. That one’s definitely not a myth, I’ve read a lot of comments like that about my work. (as well as a lot more comments where people are being constructive, but those ones aren’t the problem)

A few notes on how I deal with it:

• The “don’t read the comments” advice has never worked for me, for better or for worse. I read all of them.
• I don’t reply to them. Even if they’re wrong. I dislike arguing on the internet and I’m extremely bad at it, so it’s not a good use of my time.
• Sometimes I can learn something new from the comment, and I try to take that as a win, even if the thing is kind of minor or the comment is phrased in a way that I find annoying.
• Sometimes I’ll update the post to fix mistakes.
• I’ve sometimes found it helpful to reinterpret people being mad as people being confused or curious. I wrote a toy DNS resolver once and some of the commenters were upset that I didn’t handle parsing the DNS packet. At the time I thought this was silly (I thought DNS parsing was really straightforward and that it was obvious how to do it) but I realized that maybe the commenters didn’t think it was easy or obvious, and wanted to know how do it. Which makes sense! It’s not obvious! Those comments partly inspired implement DNS in a weekend, which focuses much more heavily on the parsing aspects.

As with everything I don’t think this is the “best” way to deal with pedantic/annoying comments, it’s just what I do.

myth: everyone should blog

I sometimes see advice to the effect of “blogging is great! public speaking is great! everyone should do it! build your Personal Brand!“.

Blogging isn’t for everyone. Tons of amazing developers don’t have blogs or personal websites at all. I write because it’s fun for me and it helps me organize my thoughts.

that’s all for now!

Probably I’ll write another meta post about blogging in a couple of years since apparently that’s what I do :)

Thanks to Ed, Jeff, Brian, Hazem, Zachary, and Miccah for reading a draft of this