Michael Banzon

About Calendars in Apps

We all use calendars - but I fear we don't use them enough, and that we use them for the wrong things!

I imagine that most of us use a calendar to guide our daily activitites. It might be a calendar on our computer/phone, on paper, or even in our mind.

What is a calendar?

In my opinion a calendar should be used to mark events that are locked in time. That means that if I have an event in my calendar on Saturday between 13:30 and 15:00 I am (somewhat) busy in the period of time, doing whatever that event is.

That also means that events that are not locked in time should not go in my calendar.

If I have to make a shopping list today, for picking up groceries tomorrow, it doesn't matter when I do it, as long as it is done today.

Error number one: Put it in the calendar at a specific time. Error numebr two: Put it in the calendar, as an all-day event.

Both of these are wrong. In the first case you indicate this needs to happen at this time. and if that is not your intent, then don't. The second one indicates this is something that is covering all of my day, which (I hope!) is also wrong.

Tasks like these belong on a to do list instead.

Bring in the apps

A lot of apps (for phones, mainly) now hold calendars.

The app for communicating with the kids school. The app for the older kids lesson plan. The Formula 1 app, YouTube and other streaming services like Twitch etc.. The app for my gym classes. All of them have some kind of calendar or reminder function designed to let me know at a specific time, that now I have to do this thing.

Funny enough, the reason for installing these apps in the first place - instead of simply using a website for booking etc. - is to have the notifications for events.

But I already have a calendar!

The problem with all apps and services having a calendar, is that now all the stuff I need to do at certain times ends up either not being in my main calendar, which is now useless OR it has to be duplicated in a manual process maintained by me.

No matter how I look at this, it is bad!

I could allow notifications from these apps, but that means it only works if a cary my phone around and actively look at it. Also, these notifications does not come alone - they bring a lot of other notifications with them from the very same apps.

The solution should be simple

Actually, my calendar can help solve this problem.

The solution is built in!

Import/export of events.

If I sign up for a yoga class: Import into calendar!

Easy! And for stuff that is more ongoing we have the option to have calendar invites. We all know them from work. They do what we need! You can even accept/decline to indicate if you are actually going to participate in that informative meeting at your kids school.

Bonus, about messages

Many years ago GitHub nailed the issue-conversations!

I get an email, I can reply to that email. Easy! The email is parsed and put into the issue thread.

I wish we had that for all apps that include messaging.

Just a test...

If all goes well this post will be live on (from) Feb. 2nd, 2025 at 18:00 (GMT?).

This should also be the publishing time in the header of the post.

How to gracefully shut down a Go server

When doing an HTTP server in Go the call to http.ListenAndServe(...) will block until the server stops. But it shouldn't stop. Ever.

That leaves us with a problem - we might want to stop the server!

There might be various reasons. Maybe we want to replace the binary with an updated version. Maybe we just want it to not run.

Fortunately instead of using the default .ListenAndServe(...) we can create our own http.Server like this:

server := &http.Server{
    Addr: ":8080",
    Handler: http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        time.Sleep(5 * time.Second)
        w.Write([]byte("Slept 5 seconds! Hello, World!"))
    }),
}

This server, for the purpose of illustration, has only one simple handler that waits for five seconds and then returns the string.

After creating a server like this, we can shut it down gracefully:

err := server.Shutdown(context.Background())

Please notice that we pass a context.Context to the .Shutdown(...) function. That gives us the flexibility to control the shutdown process in greater details if needed (but for now we just use ).

Handling program shutdown

If we then setup a handler for signals (from the OS) to handle some events of interrest, for example syscall.SIGINT and syscall.SIGTERM we start a goroutine that will listen for any of these signals and that will then cal the .Shutdown(...) function on the server.

Like this:

// setup signal handler to gracefully shutdown the program
sig := make(chan os.Signal, 1)
signal.Notify(sig, syscall.SIGINT, syscall.SIGTERM)

go func() {
    <-sig
    fmt.Println("Shutting down server...")
    err := server.Shutdown(context.Background())
    if err != nil {
        // handle the error
    }
}()

The signals from the OS will be sent to allow the program to gracefully shut down.

Putting it all together

I have put everything here together with a lot of helper functions and signals to keep all the parts working.

There is a channel done meant to signal that the program should exit. There is also a channel errCh that is used for sending errors.

The full code is in the repository on Github.

Hello world!

New blog, first post!