As the final hours of 2019 are winding down, I want to take a moment and look back at everything that happened this year - because it was a busy one.

Work

At the beginning of 2019, I became a partner at Codista, the software studio where I’ve been working for some time now. Thomas, Luis and I now run the company as a trio, and building together has been great.

Besides working as a frontend developer on a number of challenging projects this year, I was also responsible for the rebranding of our own identity. There are some interesting new ideas in the works for our studio in 2020, and I’m excited to see them come to life.

Writing

Counting this one, I’ve written ten new posts in 2019. That’s more than last year, but I’d still like to increase that number.

The most popular posts were:

• The CSS Mindset: a collection of helpful mental models for writing CSS,
• On Simplicity: how sometimes “less is more” in tech, and
• Static Indieweb pt2: Using Webmentions: a rundown of how to implement webmentions with Eleventy.

The feedback from the web community on these posts was amazing, and it never gets old to hear that anything you’ve made actually helped people in some way.

Like in 2018, all my writing was published on my own website. I’m increasingly fond of the IndieWeb and the principles behind it, and I want to continue striving for more independence. Eleventy and Netlify both have been very valuable improvements for my personal site this year, and I really like working with them.

Speaking

I wrote two new talks in 2019 and had the chance to speak at a few community events.

First I was invited as a guest speaker to the Mozilla Developer Roadshow, where I had a really interesting “Fireside Chat” about CSS with HJ Chen. It was awesome meeting her and I’m very grateful for the opportunity to speak there.

Following my blog post about the topic, I gave a talk on the CSS Mindset at CSS-Minsk-JS in September and had a wonderful time. A big thank you to the organizers and attendees, who made me feel very much at home in Minsk.

A big part of this year was devoted to making our own Webclerks Conference happen in Vienna. It was the first time for me to be involved in the organization of such an event and I really had no idea how it would turn out, so I’m overjoyed that it went so well.

I also shared my experiences with the IndieWeb in a talk called “Rage against the Content Machine” there. I’d love to do that one again in the new year.

Traveling

I’ve been fortunate enough to see many beautiful places on this planet now. I made a little map to keep track of them here.

This year, I visited Portugal, Georgia, Belarus, the Czech Republic and the Azores. My personal favourites were the ancient city of Tbilisi and the raw nature of São Miguel island, both fascinating places in their own regard.

Personal

2019 was also a source of frustration in many ways. From the ongoing global shift to right-wing populism to increasingly dystopian technology trends to the looming threat of climate change. I’ve had some issues with worrying and stress in my personal life as well.

But I’d like to think that the new decade can be an opportunity to learn from past mistakes and change things for the better. I’m going to try and focus on that going forward.

Goals for 2020

• help to further grow Codista into a sustainable, ethical business
• write more regularly
• continue involvement in the IndieWeb community
• attend and speak at more conferences
• make more music
• read more non-tech books
• keep up with friends and enjoy life a little more

That’s all folks. See you tomorrow!

It has been three days now since I stood on stage at Urania Vienna, hearing Manuel close our very first conference. I'm still not really sure how we pulled that off.

I have been to quite a few web development conferences as an attendee, and lately even as a speaker. But the organization of such events always eluded me. I of course noticed when an event was particularly well put together, but I always assumed that the people running the show had a large team, lots of experience and were just very talented organizers.

That’s why it felt so weird to suddenly find myself in that group. Clearly we’re just a bunch of people who thought it would be cool to invite some of our heroes and heroines to Vienna, with little prior experience in creating an event at that scale.

But then it worked! We’d somehow gotten ourselves an absolutely incredible line-up of speakers and a sold out venue.

Welcome to Webclerks Conference

Fast forward to last Monday, when months of work finally resulted in that one special day. Sleep had been rare in the days before, and the tension was high.

None of us really knew how this would turn out, so we just gave it our best shot. And the feedback so far from speakers and attendees alike has been great:

It's hard to believe that the @wearewebclerks conference was the first one ever by the organisers. It was slick, welcoming, friendly, and interesting. Thanks for asking me to speak! ♥️ #webclerks

— Charlie Don't Surf (@sonniesedge) November 26, 2019

The @wearewebclerks conference today was seriously awesome! Great talks, great organization and great people! And all of that in Vienna ♥️ Looking forward to the next year #webclerks pic.twitter.com/GHOqfgzsNB

— Lisa Gringl (@kringal) November 25, 2019

✅ brilliant speakers
✅ surprise acts
✅ live captions
✅ tasty food from "Speisen ohne Grenzen"
✅ water bottles to reduce waste

Congratulations to the organizers of a great #webclerks community conference pic.twitter.com/sOflfHkA1F

— Harald Atteneder (@urbantrout) November 25, 2019

This conference was a great example of getting it right from the beginning. Amazing speakers, inclusive, accessible and with all details taken care of. Congratulations to the team! I'm really looking forward to next year's event #webclerks pic.twitter.com/YlRfzyt5kD

— Magdalena Adrover (@madrovergaya) November 25, 2019

Lessons Learned

Here are some of my personal takeaways from the experience:

• It really pays off to have a good tech team. We could not have asked for a better crew than ALC, they handled the event flawlessly by themselves. A huge thing to get off your shoulders as an organizer.

• If you want to livestream an event on youtube, that apparently requires a “brand account”. These take 24 hours to approve, so it’s best to not discover this the night before the conference. (Thankfully Joschi from a11yclub helped us out there!)

• The glass water bottles we put into everyone’s goodie bag were a big hit. People liked that they could refill anytime. Less waste, more hydration!

• You can make your own rules! Not all tech confs have to follow the same recipe. In fact some of the little differences are what makes you stand out.

• We’re not a faceless recruiting event, but a community of humans, and we wanted to be as inclusive as possible. That thought went into a lot of aspects of our conference from ticket pricing to info emails to food choices. Definitely something to keep.

Roll Credits

I really have to highlight the insane amount of work that Manuel and Claudi have put into this event. There’s an internal Trello board with about a gazillion tasks on it, and most of those had their names on them. It is beyond me how they did it.

Daniel has been an absolute beast as well - he did all the designs, printed badges, flags, shirts, stickers - you name it. If you thought webclerks looked like a professional brand, it’s because of him.

We also had lots of help from awesome volunteers who dedicated their time and energy to our event. Jeannine, Kerstin, Michel, Anne and Gregor have been incredibly helpful and I’m so glad they joined our team.

Community Matters

I honestly can’t think of many industries where it would have been possible to put an event like this together from scratch. I believe the reason this worked at all is the incredible openness displayed in the web community.

Where international speakers come to a small local conference to share their knowledge. Where companies like mozilla support a relatively unknown event and fund inclusiveness. Where attendees pay it forward to enable underrepresented others to join.

I’m happy and proud to be a part of that community.

Thank you! 🎉

There's a small town that needs a new road. The old road is pretty worn and full of potholes, so it's time for a change.

First plans look promising. It’s really nice and modern. The old road had sidewalks and a bike lane, but these don’t really fit in with the new design and take too much time to build. Nobody on the planning committee knows any pedestrians or cyclists anyway, so the project doesn’t really focus on that.

Soon people get to work. Instead of regular concrete though, the construction crew decides to use a new cutting-edge synthetic asphalt. It was developed by a big construction company from the city that uses it to build a 12-lane highway in the nation’s capital - but they say anyone can use it.

Everyone in construction is very excited to work with this new material. You can do amazing stuff with it, and the team needs less time to get things done. They say this process will make the new road a lot better than the old one, and every modern construction crew does it this way now.

The friction point of the new asphalt is quite high though, so people will need a bit more horse power to drive on it - and it also takes about five times more fuel than usual. Luckily everybody on the construction team earns a very nice salary and drives a big BMW, so that isn’t really an issue. They do a couple of test drives and it all works fine.

The road is almost finished and everybody is really happy with it. But it was expensive to build, and the town wants to get that money back in some way. They don’t really like to put up toll booths, as these tend to scare drivers off. Instead they make a deal with some of the bigger advertising companies to put up some cameras.

Every car that drives on the new road will be photographed and analysed, and the ad firms can then decide to put up billboards in the middle of the road that are perfectly tailored to each driver. That is a bit distracting and slows the cars down somewhat, but it will generate revenue for the town. Plus, all these photos of drivers will tell the planners more about how it is working.

Finally, the road is finished.
There are fewer people using it now. That’s ok though, the new road isn’t for everyone.

Some might even feel that the old road was better in a way, potholes and all. It didn’t have all the fancy new features, but it got them where they wanted to go.
But that’s the nature of progress - just how these things are done today.

It’s the future.

A pain point of the IndieWeb is that it's sometimes not as convenient to share content as it is on the common social media platforms.

Posting a new short “note” on my site currently requires me to commit a new markdown file to the repository on Github. That’s doable (for a developer), but not really convenient, especially when you’re on the go and just want to share a quick link. Twitter and other social media platforms literally make this as easy as clicking a single button, which makes it tempting to just post stuff straight to them. That’s why I wanted to improve this process for my site.

A quick Google search revealed that smarter people have already solved that problem. I came across this blog post by Tim Kadlec who describes adapting someone else’s link sharing technique for his (Hugo-powered) blog. That just left me the task of adapting it for my setup (Eleventy, Netlify) and customizing a few details.

The new link sharing basically has three main parts:

• a small Javascript bookmarklet to act as a “share button”
• a form that collects and sends the shared link data, and
• a serverless function to process it and create a new file.

Here’s how they work together:

The Bookmarklet

The button to kick things off is just a small bit of Javascript that takes the current page’s title, URL and optionally a piece of selected text you may want to quote along with the link.

It then sends these things as GET parameters to mxb.dev/share by opening a new window to it.

function(){
    // get link title
    var title = document.getElementsByTagName('title')[0].innerHTML;
    title = encodeURIComponent(title);

    // get optional text selection
    var selection = '';
    if (window.getSelection) {
        selection = window.getSelection().toString();
    } else if (document.selection && document.selection.type != 'Control') {
        selection = document.selection.createRange().text;
    }
    selection = encodeURIComponent(selection);

    // generate share URL
    var url = 'https://mxb.dev/share/?title='+title+'&body='+selection+'&url='+encodeURIComponent(document.location.href);

    // open popup window to sharing form
    var opts = 'resizable,scrollbars,status=0,toolbar=0,menubar=0,titlebar=0,width=680,height=700,location=0';
    window.open(url,'Sharer',opts);
})()

The bookmarklet looks like this:
Share on MXB

…and can then be dragged to the bookmarks bar for quick access.

The Sharing Form

At mxb.dev/share, I’ve created a small preact app. It will take the GET params passed in via the URL and generate a live preview of the resulting note, so I know what the end product will look like.

There’s also a form that will be pre-populated with the values, which lets me include additional information and edit everything before posting.

The form also has fields for the Github username and security token, necessary for authentification. My password manager will fill those in automatically.

The Handler Script

When I hit the submit button, the form will send the data along to another endpoint. I’ve built a serverless function to handle the processing, so I could theoretically send data from other sources there too and keep the posting logic in one place. Netlify Functions seemed to be a nice fit for this.

Here’s the full script if you’re interested. It reads the posted data and generates a new markdown file from it, called something like 2019-08-11-amphora-ethan-marcotte.md:

---
title: "Amphora - Ethan Marcotte"
date: "2019-08-11T16:57:13.104Z"
syndicate: false
tags: link
---

...we've reached a point where AMP may "solve" the web's 
performance issues by supercharging the web’s accessibility problem. 
(via [@beep](https://twitter.com/beep))

[ethanmarcotte.com/wrote/amphora](https://ethanmarcotte.com/wrote/amphora/)

It will then use the Github API to post that file as a base64-encoded string to a predetermined location in the site’s repository (in my case the folder where I keep all my notes).

Here’s the core function responsible for that:

const postFile = async data => {
    const { title, token } = data
    const fileName = getFileName(title)
    const fileContent = getFileContent(data)
    const url = API_FILE_TARGET + fileName

    const payload = {
        message: 'new shared link',
        content: Buffer.from(fileContent).toString('base64'),
        committer: {
            name: 'Max Böck',
            email: 'hello@mxb.dev'
        }
    }

    const options = {
        method: 'PUT',
        body: JSON.stringify(payload),
        headers: {
            'Content-Type': 'application/vnd.github.v3+json',
            Authorization: `token ${token}`
        }
    }

    return await fetch(url, options)
}

That’s pretty much it! After the file is committed, Netlify will kick in and re-build the static site with the new content. If I have marked the “syndicate to Twitter” flag, another script will then cross-post the link there. (More on that in Static Indieweb pt1: Syndicating Content).

Mobile Share Target

A caveat of this technique is the use on mobile. Javascript bookmarklets are not as easily available in mobile browsers, which complicates the process again.

Thankfully Aaron Gustafson recently pointed out that it’s possible to define a “Share Target” for Progressive Web Apps. That means if your site is a PWA (it probably should be), you can add an entry like this to its manifest file:

// site.webmanifest
{
    ...,
    "share_target": {
        "action": "/share/",
        "method": "GET",
        "enctype": "application/x-www-form-urlencoded",
        "params": {
            "title": "title",
            "text": "text",
            "url": "url"
        }
    }
}

That little bit of JSON registers your site as an application that can share things, just like Twitter, WhatsApp and the others. So after I “install” my PWA (read: create a shortcut link on my device home screen), it shows up as an option in the native Android “share” dialog:

I’m quite happy with how this turned out, as it feels really simple and straightforward. One step closer to IndieWeb bliss!

There is a thing that happens to me while writing. I start with a fresh idea, excited to shape it into words. But as time passes, I lose confidence.

The original concept starts to look shallow or irrelevant, and the phrases sound awkward and repetitive. It just doesn’t feel good anymore.

I don’t think that’s unique to me - In fact I guess one of the reasons why many people would rather write a series of tweets than a longform blog post is that the expectations we set for ourselves are much higher with the latter. Posts need to be “done right” - there’s a greater risk of falling into the trap of perfectionism.

I know the anxiety of sharing something with the world. I know there is a pressure to match the quality we see elsewhere on the web. But maybe we should stop trying to live up to somebody else’s standards and focus on just getting stuff out there instead. Maybe our “imperfect” things are already helpful to someone. Maybe this shouldn’t be so hard.

Perfect is the Enemy of Done

Don’t get me wrong, I don’t mean we should all half-ass our writing. There are a lot of details to get right, and going the extra mile certainly pays off as it makes for better articles.

However at least for me, there is a point where a post is about 80% done, and I start to get in my own head:

“Maybe this isn’t as good as I thought it would be.”

“Seems like everyone already knows that.”

“This is missing something new and exciting.”

“I’m sure somebody already covered this way better.”

This is where posts die.
They get swallowed by these voices of doubt and end up collecting dust in a drafts folder as “maybe I’ll come back and finish this later” pieces. I’ve got about six of these currently, and it seems like I’m not the only one.

Just Publish It

So now I’m trying a new approach to avoid this:

I’ll publish something as soon as I feel confident that all the important points I want to get across are there. I try to ignore the voice screaming “it’s not ready” just for long enough to push it online. Then I share the link on Twitter.

Right away, the act of making a post public forces me to read it again. And of course the minute it’s out there I’ll immediately notice a bunch of errors I didn’t spot before. It’s a law of nature or something. That’s ok though, I can just push a couple of fixes.

Doing a thing now were I publish stuff early to avoid "It's-not-ready-anxiety" and get it out there. Fixing shit later, sorry 🙃 pic.twitter.com/MYCY382Pn9

— Max Böck (@mxbck) June 6, 2019

Then there’s the feedback aspect. Publishing might either go largely ignored, or the post might get shared or commented on.

If it’s ignored, well - no harm done. It’s out there, that’s all that matters. But if it gains traction, that’s not only a sign that the post is interesting to people, it’s also a motivation boost to get me over that last 20%.

Most importantly though, publishing early is an exercise for my brain. It’s ignoring the feelings of self-doubt. It’s forcing myself to actively decide that something is good enough.

Fix it in Post

One of the benefits of writing on your own site is that you can always go back and edit stuff later.

Maybe you have a good idea for an additional paragraph that makes a certain point clearer. Maybe you find a better way to write a piece of code. Maybe somebody points out a thing you haven’t considered yet, and you want to include it. Well, why wouldn’t you? Nobody says blog posts should be set in stone. Improve it for the next reader who comes along.

You can even retroactively change the way your post is displayed on social media. For example, if you add an open graph image to your post after publishing it, you can use Twitter’s Card Validator to scrape the URL again, and all the links people may have already shared will update.

I know of some people doing this in web development, for example in open redesigns of their personal sites. I don’t know if anyone tried it with writing yet though. Maybe it’s a bad idea.

But for now, I like it.

Further Reading

• Just write by Sara Soueidan
• Out there by Matthias Ott
• My Blog Post Workflow by Ali Spittel