Jouni Kantola. Web developer.

Power to the reader

2021-04-02T00:00:00.000Z

Let me ask you a question. How do your readers prefer to read? All I know about people visiting, are based on what pages have most visits. That information gives me clues about who are reading, but nothing about their preferences.

More and more, I've come to read blogs with my browser's Reader View. I've been driven to it. Half the joy of reading is killed by trying to dismiss cookie consent banners and recommendations to download apps. Honestly, all I want to do is to read the text you've put hard effort into writing.

Kindle

For over a year, I've been pixel pushing, trying to improve readability. I've spent hours on end, comparing font sizes, margin widths and letter spacing. I'll probably never be satisfied. Even if I would, it would be for my own reading experience.

I've had a Kindle for years, and I love reading on it. The power to decide how to consume text has been handed over to me. I, the user, get to pick what font, line height and text size best suits my needs. I get to control my own user experience.

Here, you pick

I've got a hypothesis, that if you have the option to, you'd like to choose how content you read is presented. That's why I've given you some choices. The formatting alternatives I've started with are based on what I fiddle with mostly on my Kindle.

If you have the time, I'd be happy to hear from you. I want to get your improvement ideas and share your reactions about being able to choose how text is presented. My personal hopes are that others pick up on this. I don't want to use my browser's Reader View, I want to read your blogs!

Permalinks for Eleventy headings

2021-02-05T00:00:00.000Z

Quite often I share URLs to a specific section of a web page. For code snippets, on the other hand, I tend to copy & paste. On mobile, the chore of selecting, copying and pasting text is a pain. For a recipient, snippet sharing also results in loss of context. A link would've been more helpful.

I'll describe how I use Eleventy, to handle links to sections and code snippets here on the site.

GitHub style headings #

The backstory for my choice of in-page permalink design, is inspiration from GitHub's direct links to README sections. I wanted to automate generation of IDs for headings and couple them with <a> tags. For blogs in Markdown, Eleventy can be extended with markdown-it-anchor. I however, have blogs using both HTML and Markdown templates.

I created a feature request issue for Eleventy, to find a source agnostic solution. The following discussion, provided guidance towards the approach I've taken.

Text and snippet headings #

11ty provides reusable functions for generating page content via shortcodes. Shortcodes can be tweaked to fit site specifics, and are usable in both Markdown and HTML templates. I aimed at creating headings for blog sections and code snippets, mimicking how headings are generated by markdown-it-anchor.

Eleventy shortcode #

module.exports = eleventyConfig => {
  // direct link's text
  const symbol = "#"
  const slug = eleventyConfig.getFilter("slug");
  eleventyConfig.addShortcode("h", (level, text, classList = "") => {
    const tag = `h${level}`;
    // URL safe heading IDs
    const id = slug(text).replace(/[^\w-]/g, "");
    return `
<${tag} id="${id}"${classList && ` class="${classList}"`}>
  <span class="heading">${text}</span>
  <a class="direct-link" href="#${id}">${symbol}</a>
</${tag}>`;
  });
};

The shortcode h declares parameters for heading level (e.g. <h2>) and text. The heading's text is used to generate IDs and associated anchor tags. Optionally, the shortcode also supports specifying additional CSS classes to style headings contextually.

Shortcode in action #

Regardless if a blog's template is HTML or Markdown, the shortcode is used the same way. Below follows an example for how the shortcode is called.

Use heading shortcode #

html

<div class="code-snippet__description">
  {% h 4 "Eleventy shortcode" "code-snippet__comment" %}
  <abbr title="JavaScript" class="code-snippet__lang">js</abbr>
</div>

I specify page headings to use flexbox, to enable styling based on page layout. The advantage of doing this, is that the heading's direct link's can be repositioned. To render the direct link before the heading text, the following CSS can be used.

Reverse heading and link order #

css

/* reverse heading's element order */
h2 {
  display: flex;
  flex-direction: row-reverse;
  justify-content: flex-end;
}

Low-key, discoverable links #

Permalinks don't add any value if they aren't used. After all, the use case is navigation and sharing. Poorly chosen additional elements are noise. In contrast, without visible elements in-page navigation is hard to discover. In my opinion, (subtle) hints should always be visible for touch device users. For desktop users, the sweet spot is to show the links as the user tracks the page with their mouse or keyboard.

Heading and link CSS #

css

.direct-link:active,
.direct-link:hover,
.direct-link:focus {
  text-decoration: underline;
  opacity: 1;
}

:is(h2, h3, h4) > .direct-link {
  display: inline;
  opacity: 1;
  text-decoration: none;
  font-size: inherit;
  margin-left: 0.5rem;
}

:is(h2, h3, h4):active > .direct-link,
:is(h2, h3, h4):hover > .direct-link,
:is(h2, h3, h4):focus > .direct-link {
  display: inline;
  opacity: 1;
  text-decoration: none;
  font-size: inherit;
  margin-left: 0.5rem;
}

@media (hover: hover) {
  :is(h2, h3, h4) > .direct-link {
    display: none;
  }
}

In this blog, I've intentionally included direct links for all sections. Often, that's likely over the top. Keep your reader's experience top of mind, but do help them share your legwork.

Call Google Cloud Functions with C#

2021-01-15T00:00:00.000Z

When using C# and .NET to consume IAM protected cloud functions in Google Cloud Platform (GCP), a lot of information unpacking is needed. In particular, when calls are made from outside of GCP. I hope I can provide a little guidance.

Authentication

Cloud function invocation is secured by IAM (acronym of Cloud Identity and Access Management). Callers of HTTP Functions need the IAM role roles/cloudfunctions.invoker.

Function requests should carry a resource specific access token, a bearer token. The resource's identifier is called audience. For HTTP functions the resource identifier/audience is the endpoint's URL. In C#, authentication is provided by the Google.Apis.Auth NuGet package.

Once the bearer token is acquired, the cloud function request can be sent, with the token included in the Authorization HTTP header. AuthenticationHeaderValue in namespace System.Net.Http.Headers, provide functionality for formatting the HTTP request header.

Cloud function request

The below example fetches an access token and then invokes a HTTP Function. Authentication credentials are catered by a service account key.

Post file to cloud function #

using Google.Apis.Auth.OAuth2;

async Task PostFile(FileInfo file)
{
  var functionUrl = "https://[REGION].cloudfunctions.net/my-function";
  var credentialsPath = Environment.GetEnvironmentVariable("GOOGLE_APPLICATION_CREDENTIALS");

  var oidcToken = await GoogleCredential
    .FromFile(credentialsPath)
    .GetOidcTokenAsync(OidcTokenOptions.FromTargetAudience(functionUrl));

  var token = await oidcToken.GetAccessTokenAsync();

  using var stream = File.OpenRead(file.FullName);
  var formData = new MultipartFormDataContent(Guid.NewGuid().ToString("N"));
  formData.Add(new StreamContent(stream), "file", file.Name);

  using var client = new HttpClient();
  client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token);
  await client.PostAsync(functionUrl, formData);
}

Subpar docs

Put politely, the .NET API docs for Google Cloud Platform has improvement potential. Often, to understand what APIs and NuGet packages to use and how, involves tying together code samples from other programming languages and documentation from multiple sources. Exploration can be confusing, but the docs site for Google Cloud Libraries for .NET seems to be a decent starting point.

I hope I've now assisted somewhat, if nothing else than by showing how to call secured cloud functions.

Generate selfie favicons

2021-01-12T00:00:00.000Z

Just over 10 years ago, in the green sea off the west coast of Malaysia, I shot an underwater selfie. That image has since become part of my online presence. Now also as favicons, a set generated with Node.js.

Face blowing a kiss

Until recently, I used an emoji as favicon. The icon set was generated from the Unicode character 😘 with an online favicon generator. I'm pro emoji, but I wanted a more personal touch for my web site. Like an underwater selfie.

Source photo

Once I decided to generate selfie favicons, I had to dig through my photo archive to find the source photo. The images I used on Twitter, GitHub and Gravatar were all of poor quality. Once I found the original, I cropped it to a quadratic (high resolution) image.

Node.js module

Instead of the online favicon generator, I wanted more control of which platforms to create images for. I found the Node.js module Favicons. Not only does the module generate favicons, it also scaffolds a web app manifest.

Generate favicons

After a couple of test runs, I opted for an icon set targeting web, iOS and Android. The favicon module supports other platforms and legacy formats than the ones I cherry picked.

Favicons setup #

const fs = require("fs").promises;
const favicons = require("favicons");
const config = {
  path: "/",
  appName:
    "Jouni Kantola. Web developer.",
  appShortName: "Jouni Kantola",
  appDescription:
    "I'm Jouni. I do web.",
  dir: "ltr",
  lang: "en",
  background: "#222",
  theme_color: "#222",
  display: "standalone",
  orientation: "any",
  scope: "/",
  start_url:
    "https://jouni.kantola.se/",
  icons: {
    favicons: true,
    android: true,
    appleIcon: true,
    appleStartup: false,
    coast: false,
    firefox: false,
    windows: false,
    yandex: false,
  },
};

async function generateFavicons() {
  try {
    const selfie =
      "selfie-2728x2728.png";
    const outputPath = `${__dirname}/favicons`;
    await fs.mkdir(outputPath);

    const {
      images,
      files,
      html,
    } = await favicons(selfie, config);

    const out = [
      ...files,
      ...images,
    ].map(({ name, contents }) =>
      fs.writeFile(
        `${outputPath}/${name}`,
        contents
      )
    );
    out.push(
      fs.writeFile(
        `${outputPath}/meta-tags.html`,
        html.join("\n")
      )
    );

    await Promise.all(out);
  } catch (err) {
    console.error(err);
  }
}

generateFavicons();

Currently I use seven favicons (View Source is your friend). Them and my image for social shares are all generated with the above code snippet. Now go personalize your web site! 😘

No fuzz development with EcmaScript modules

2020-12-20T00:00:00.000Z

Browser support for EcmaScript modules (ESM) is good. In my opinion, widespread enough to take advantage of to reduce complexity in your development workflow.

Let me describe a bundler free approach for developing, unit testing and shipping JavaScript. We'll unit test our code in Node.js and then serve the code unchanged to the browser.

Unit testing ES modules

By using file extension .mjs with your JavaScript files, you'll get out of the box Node.js support (as of v13.2.0) for EcmaScript modules, and have import and export statements available to you.

Let's build a module, for which we'll add unit tests and then ship to the browser.

First install the test runner AVA and thereafter create test-convert-temp-units.mjs for our unit tests.

Prepare unit testing #

# Install ava with npm
> npm install ava --save-dev

# Create folder and unit tests script
> mkdir test
> touch test/test-convert-temp-units.mjs

As the filename hints, we'll be converting units of temperature, between Celsius to/from Fahrenheit.

Unit tests #

// test/test-convert-temp-units.mjs
import test from "ava";
import { cToF, fToC } from "../src/convert-temp-units.mjs";

test("celsius to fahrenheit", t => {
  t.is(cToF(10), 50);
});

test("fahrenheit to celsius", t => {
  t.is(fToC(95), 35);
});

test("same °F as °C", t => {
  t.is(cToF(-40), fToC(-40));
});

If we execute the tests with npx test, we'll get an error explaining Cannot find module [...]/src/convert-temp-units.mjs. Let's create our application code module.

Code for temperature conversion #

// src/convert-temp-units.mjs
export const cToF = celsius =>
  celsius * 9/5 + 32;

export const fToC = fahrenheit =>
  (fahrenheit - 32) * 5/9;

Another run with AVA should now show us 3 passing tests.

Run unit tests #

> npx ava --verbose

  ✔ celsius to fahrenheit
  ✔ fahrenheit to celsius
  ✔ same °F as °C

  3 tests passed

ES modules in the browser

To consume our code in the browser, we'll have to declare that the script is an EcmaScript module. This is achieved with <script type="module">. Let's create a web page for converting temperature units, where we import the file convert-temp-units.mjs.

Import ES module in browser #

html

<!DOCTYPE html>
<html lang="en">

<head>
  <title>°C to °F</title>
</head>

<body>
  <main>
    <h1>Temperature unit conversion</h1>
    <form>
      <label for="celsius">°C</label>
      <input type="number" id="celsius" name="celsius">
      <output data-unit="fahrenheit"></output>
    </form>

    <form>
      <label for="fahrenheit">°F</label>
      <input type="number" id="fahrenheit" name="fahrenheit">
      <output data-unit="celsius"></output>
    </form>
  </main>

  <script type="module">
    // import functions from .mjs
    import { cToF, fToC } from "./convert-temp-units.mjs";

    const asFahrenheit = document.querySelector("*[data-unit='fahrenheit']");
    const asCelsius = document.querySelector("*[data-unit='celsius']");

    celsius.addEventListener("input", (e) => {
        const { value } = e.target;
        asFahrenheit.textContent = cToF(value);
    });

    fahrenheit.addEventListener("input", (e) => {
        const { value } = e.target;
        asCelsius.textContent = fToC(value);
    });
  </script>
</body>
</html>

Notice how the the conversion functions are imported and called the same way as in Node.js.

No bundler

If you know your target audience, you can make life easier for yourself by developing interactive web pages like in the good ol' days. Choose your development stack to match your user's needs. Make deliberate decisions. Ask yourself if you can serve your application without using a bundler. I'll bet, quite often you can improve your development experience by not adding unnecessary tooling.

The unpragmatic programmer

2020-05-09T00:00:00.000Z

I have a DIARY.md for logging progress at the gym. It's a long file, partly because I've been consistently going since late 2018. For that, I pat myself on the shoulder. It's also long, because I early on decided to build a web app for logging my sessions. While at it, I figured I'd take on the challenge to build a UI framework.

Choosing problem

From the get-go, I knew I'd end up with a ton of problems to solve. I was, and am fine with that. What I've done miserably wrong is to not turn back, and start solving one problem at the time. I could've solved data storage for my sessions. That would be an isolated problem. I could've opted for static HTML pages. That would suffice for complete user flows. Here I am, 1.5 years later, still committing training logs to a Markdown file. Point being, even with opportunities for self-improvement, problems shouldn’t be conflated into unnecessary complexity.

Project fatigue

Every software undertaking comes with constraints. Likely, these constraints exist to not over-consume scarce resources. Time being one of them, which is of particular importance in side-projects. I'm balancing side-project efforts with family time or sleep. If I overstep, I hurt my family and/or myself. Clear checkpoints are an energy source. Once I reach one, I can enjoy the result. Too vague goals opens up for ineffective drifting. Drifting is mentally taxing for me, sometimes enough to negatively affect the constraints I move within. When I'm out of bounds, I drain myself for unclear reasons. Here my interest starts to fade. I stagnate and I tire.

Stop-and-go

I'm driven by learning. In this, I have one side of me that is keen on experimenting to understand topics at depth. I also have an impatient side, which constantly has me looking for new input. Both of these tend to barge in when I myself is the sole stakeholder. When I let any of these traits take too much mental space, I often find myself doing something unplanned. Over time, I've tried to find patterns to look out for, to manage myself. The success rate of steering myself back on track is varied, but I'm getting better at it. Key for me is to stop starting new things.

Make it work, make it better

I tend to overthink things. Thinking alone doesn't result in any code. On the contrary, it opens up a Pandora's Box of possible solutions. Possibilities, by definition are things that may happen. Better are solutions in the hands of users. Interactions enable feedback. In this case, for my own benefit. In my training, I have a range of about 10 exercises. To list these, I do not need a unidirectional data flow architecture. Yet, it's that architectural problem space I keep finding myself in. In part the reason is interest, but the main offender is probably procrastination. At the point where a hack enables shipping, that is what I should choose. Code is meant to be run and used. Naive implementations pave the way for better things. The learning opportunity I’ve enabled for myself should be scoped as improvements, not a requirement.

Focus on outcome

I strive to be deliberate in the choices I make. If I’m not deliberate, I’m annoyed with myself. That’s why this side project has become something of a thorn in my side. At work I’m outcome focused. I have colleagues for whom pragmatism comes naturally, who are a great inspiration for me. They complement my weaker sides. We prioritize usefulness. I cannot even recall when I last could guilt my work I for taking me off balance. I’ve noticed this makes me feel better overall.

As usefulness is what makes me tick, the next time I feel an urge for reusability, it’s a hardcoding I’ll type.

Audit web performance in development environment

2020-04-05T00:00:00.000Z

I've listed this site into the Eleventy Performance Leaderboard. When doing so, I figured it'd be good to tighten the feedback loop for tracking effect of changes. Shipping to production and then measuring, is a long roundtrip to find a change made performance worse.

Production-like performance audits #

With a static site generator, like Eleventy, serving its output with a web server enables running local performance audits. Eleventy's built-in development server doesn't quite cut it, as it includes assets you don't want to account for in an analysis. Another hurdle to achieve production-like audits, is that tools like Lighthouse expect your assets to be served with HTTP/2.

Serving your static site with HTTP/2 can be achieved with simplehttp2server. Via npm script you can run the web server with Eleventy's output in an easy way.

Run simplehttp2server #

json

"scripts": {
  "build": "eleventy --input=./src/ --output=_site",
  "start": "eleventy --input=./src/ --serve",
  "serve": "yarn build && cd ./_site && simplehttp2server"
},

After executing yarn serve, you'll likely get a warning about the certificate not being trusted when browsing your site. Instead of getting your browser to trust simplehttp2server's self-signed certificate, I recommend generating a development certificate with mkcert. Use mkcert to configure a local certificate authority. Once done, replace simplehttp2server's with a trusted development certificate.

Replace certificate #

# Static site root
> cd ./_site

# Generate development certificate
> mkcert localhost

# Replace certificate
> mv localhost.pem cert.pem

# Replace public key
> mv localhost-key.pem key.pem

Now run yarn serve again. If you browse to your site, you'll notice it's served with HTTP/2 with a valid mkcert development certificate issued by mkcert development CA. With that, run a Lighthouse audit to see what it recommends for you to adjust.

Development vs Production #

As we now have production-like audits close at hand, we can track how changes affect performance. To further extend this capability, install Node.js module performance-leaderboard. Create a perf-test.js module in your repository, with specification for what sites to test. I'm running tests against development and production to determine optimization efficacy.

Automated Lighthouse audit #

// perf-test.js
const leaderboard =
require("performance-leaderboard");

(async function() {
  let urls = [
    "https://localhost:5000",
    "https://jouni.kantola.se"
  ];

  console.dir(await leaderboard(urls));
})();

In practice, I run automated tests in two terminal windows; one with yarn serve and another running yarn perf-test. The audit provides you with a comparison between development and production. performance-leaderboard also keeps history of executed runs in a ./log folder.

Perform audit #

json

"scripts": {
  "build": "eleventy --input=./src/ --output=_site",
  "start": "eleventy --input=./src/ --serve",
  "serve": "yarn build && cd ./_site && simplehttp2server",
  "perf-test": "node ./perf-test"
},

Worth noting, comparisons against production are tricky. Infrastructure, like hosting static assets on CDNs, affect performance a lot. With logs you can detect what patterns works and which don't.

Once you've covered common well-known practices, you'll have to adapt performance optimizations with your site's specific setup and UX top of mind. This is when your web performance audits will really shine.

Inline PostCSS generated CSS with Eleventy

2020-03-15T00:00:00.000Z

Inlining CSS is a common practice for optimizing the critical rendering path. Once you've analyzed and factored out styles blocking rendering, you'll likely want build time enhancements provided by tooling like PostCSS, before inlining.

Eleventy shortcode #

Eleventy can extend the static site generation with definitions for reusable content. You can utilize this capability to generate your web's critical path CSS. Configure 11ty with an universal template shortcode for processing render blocking styles.

PostCSS shortcode #

eleventyConfig.addPairedShortcode("postcss",
  async code => {

  // for relative path CSS imports
  const filepath = path.join(
    __dirname,
    "src/_includes/critical-path.css");

  return await postcss([
    // PostCSS plugins
    require("postcss-import"),
    require("precss"),
    require("autoprefixer"),
    require("cssnano")
  ]).process(
    code,
    { from: filepath })
  .then(result => result.css);
});

The above shortcode configures PostCSS to process files imported to an entry point, for which vendor prefix are generated, and finally minified.

Inline styles #

The shortcode is available to be referenced in a page layout, and fed the critical rendering path CSS. An entry file is specified, which in turn enables inlining of required component styles with the @import directive.

Shortcode in page layout #

liquid

<html>
  <head>
    <!-- ... -->
    <style>
      {% postcss %}
        {% include critical-path.css %}
      {% endpostcss %}
    </style>
  </head>
  <!-- ... -->
</html>

Template shortcodes can be used for definitions of styles for specific pages or for inlining all CSS. What granularity you aim for, mostly becomes a matter of prioritizing maintainability or performance requirements.

webpack assets in ASP.NET

2020-03-10T00:00:00.000Z

As webpack continues to grow in popularity, more tooling evolves for a smooth development experience. This is true for a story with webpack and ASP.NET together as well, at least if you're running .NET Core. I want to share a framework-neutral setup with a satisfactory experience independent of ASP.NET version.

I'll describe how to:

Integrate webpack 4 with ASP.NET MVC 5
Use webpack's development server
Get started with Hot Module Replacement (HMR)

Getting started

The first thing to do, in the root of your web project, is to install webpack and its CLI. Run npm install webpack webpack-cli --save-dev. Once installed, I recommend adding a convenience task in package.json for executing webpack.

Build task #

json

"scripts": {
  "test": "echo \"Error: no test specified\" && exit 1",
  "build": "webpack"
}

If you try npm run build, you'll likely get an error stating Can't resolve './src'. To fix this, a configuration file for webpack will come in handy. In the root of your project, add a webpack.config.js file with the following content:

Initial webpack configuration #

module.exports = {
  // point this path to your entry,
  // your non-minified start file
  entry: "./Scripts/main.js"
};

Once saved, webpack is now configured to build your JavaScript application and output in into the folder ./dist. For now, ASP.NET has no understanding of webpack's output. Let's start integrating.

webpack 💝 ASP.NET

To be able to reference webpack's output in ASP.NET, use npm to install razor-partial-views-webpack-plugin. The plugin extends webpack's build with capability to generate Razor views for webpack assets. Which assets to create views for are configurable.

Generate Razor views with webpack #

const RazorPartialViewsWebpackPlugin = require("razor-partial-views-webpack-plugin");

module.exports = {
  entry: "./Scripts/main.js",
  output: {
    // runtime asset location
    publicPath: "/dist/"
  },
  plugins: [
    new RazorPartialViewsWebpackPlugin({
      rules: [{
        // view for default chunk
        name: "main",
        template: {
          // Razor directive
          header: "@inherits System.Web.Mvc.WebViewPage"
        }
      }]
    })
  ]
};

With the plugin for generating Razor views configured, a webpack build outputs a main.cshtml. The partial view's content is a script tag referencing webpack's built JavaScript file.

Partial view for webpack asset #

cshtml

@inherits System.Web.Mvc.WebViewPage

<script type="text/javascript"
  src="/dist/main.js"></script>

Now reference the generated view in ASP.NET MVC's _Layout.cshtml.

Partial view in layout #

cshtml

<body>
  <!-- ... -->
  @Html.Partial("~/dist/main.cshtml")
</body>

That's it for using webpack's output in ASP.NET.

Improving development experience

With webpack integrated with ASP.NET, let's build on that to enhance the development experience. webpack-dev-server provides automatic page refresh and hot swapping of modules, which saves you from restarting the whole application after code updates. Install the development server with npm and extend package.json to run it for serving webpack's assets.

Run webpack development server #

json

"scripts": {
  "test": "echo \"Error: no test specified\" && exit 1",
  "start": "webpack-dev-server --hot",
  "build": "webpack"
}

Update webpack.config.js to include devServer and signal that assets no longer are served from ./dist folder. These configuration updates also function as scaffolding for partial views used in ASP.NET.

Serve assets with development server #

output: {
  // assets served by webpack-dev-server
  publicPath: "https://localhost:8080/"
},
devServer: {
  // output assets to disk for ASP.NET
  writeToDisk: true,
  // clearly display errors
  overlay: true,
  // include CORS headers
  headers: {
    "Access-Control-Allow-Origin": "*"
  },
  // use self-signed certificate
  https: true
}

Run npm start and start your ASP.NET web application. Open your browser's development tools and take notice of Loading failed for the <script> with source "https://localhost:8080/main.js". The reason for the error, is the browser not trusting the development server's self-signed certificate. For now, browse to https://localhost:8080/ to accept the certificate. We'll get to a proper fix shortly.

Browse back to the web application and see your JavaScript code running. Now we reap rewards of our work. In the development console you should have webpack's development server signaling Hot Module Replacement enabled and Live Reloading enabled. Make a JavaScript update and notice the browser refresh. Happy times!

Trusted development certificate

I recommend generating a trusted development certificate for webpack-dev-server. That'll smoothen cross-browser testing, without having to hack about with getting your browser to trust a self-signed certificate. mkcert provides the feature to create an ample certificate. Install the tool, and run the setup of a local certificate authority. Thereafter, generate a development certificate in your web project root.

Generate development certificate #

# Install local certificate authority
> mkcert -install

# Generate development certificate
> mkcert localhost

Once the certificate is generated, update webpack's devServer configuration to start using it. Afterwards, your browser will consider the connection to the development server as secure.

Certificate for webpack-dev-server #

const fs = require("fs");

module.exports = {
  /*...*/
  devServer: {
    writeToDisk: true,
    overlay: true,
    headers: {
     "Access-Control-Allow-Origin": "*"
    },
    // use development certificate
    https: {
      cert: fs.readFileSync("./localhost.pem"),
      key: fs.readFileSync("./localhost-key.pem")
    }
  }
}

Hot Module Replacement

So far, you've gained automatic page refresh when updating JavaScript. This alone is an improvement compared to full recycle via Visual Studio's Start Debugging. With Hot Module Replacement (HMR) the feedback loop is tightened even more.

HMR enables swapping updated modules without reloading the page. When you update front-end code, take notice of the message [HMR] Aborted because [module] is not accepted.

Hot Module Replacement is activated by signaling to webpack if and when changes are accepted by using the module.hot API. Pay attention to side-effects (like appending elements to DOM), as they likely have to be accounted for before modules are reapplied.

Allow swapping modules #

import { create } from "./state-picker";

const statePicker = create();
document.body.prepend(statePicker);

// is HMR activated?
// don't activate in production
if (module.hot) {
  // accept changes
  // for this module and dependencies
  module.hot.accept();

  module.hot.dispose(() => {
    // prevent multiple
    statePicker.remove();
  });
}

Include module.hot.accept() in your JavaScript code. You'll notice how the page doesn't refresh on every update. Instead webpack knows what modules have been updated. Great success!

Build for production

webpack comes with decent defaults for managing development and production builds. Over time, you'll likely need to adapt your configuration more granular according to target environment. For now, adapt webpack's output configuration to match your production environment (e.g. use of CDN). Ensure paths and cache busting are properly configured.

To run a production build, execute npm run build -- --mode=production (yes, that's four hyphens, so consider another npm script).

Production output #

// export webpack.config.js as function
module.exports = (env, argv) => ({
  /*...*/
  output: {
    filename: argv.mode !== "production"
      ? "[name].js"
      : "[name].[contenthash].min.js",
    publicPath: argv.mode !== "production"
      ? "https://localhost:8080/"
      : "/dist/"
  }
});

Run a production build and peek into the generated main.cshtml. It now references a minifed asset. Ship it! 📦

Production script minified #

cshtml

@inherits System.Web.Mvc.WebViewPage

<script type="text/javascript"
  src="/dist/main.66ca108e268.min.js"></script>

webpack is a powerful toolbox to utilize for delivering front-end assets. One use case I thoroughly recommend using it for, is to evolve legacy applications. webpack comes with support for multiple module systems, which enables migration scenarios, like updating from AMD to ES modules.

Plugins like razor-partial-views-webpack-plugin takes the webpack ecosystem closer to ASP.NET's. Try it out! Adopt the habit of running webpack in a terminal on the side. I hope you'll appreciate it as much as I do.

Dark mode toggle

2020-02-29T00:00:00.000Z

Dark mode for everyone, right? If you're about to add it to your web site, there are a few things to consider:

How do you toggle between dark and light mode; by time of day, satisfy operating system settings or user activation?
How do you persist the user's choice?
How do you reactivate the user's preference on return?

Automagic toggle

Lately color schemes, especially dark mode, have become inherent features in devices people use. When rendering color scheme, automatically setting mode can be achieved both in CSS and JavaScript. You have the options to base mode on operating system settings or time of day.

Background by preference #

css

@media (prefers-color-scheme: dark) {
  --background-color: #222;
}

@media (prefers-color-scheme: light) {
  --background-color: #fafafa;
}

body {
  background-color: var(--background-color);
}

When using media queries, be thoughtful of feature detection and to fall back to a default color scheme.

Append class based on preference #

if (
  window.matchMedia &&
  window.matchMedia(
    "(prefers-color-scheme: dark)"
  ).matches
) {
  document.documentElement
    .classList.add("dark-mode");
} else {
  // fallback
  document.documentElement
    .classList.add("light-mode");
}

A friendly gesture to your user could be to switch on dark mode in the evening. It's common that I adjust screen brightness when I browse web sites with light colors in the evening.

Nighttime dark mode #

const hour = +new Date()
  .toLocaleTimeString(
    [],
    { hour: '2-digit', hour12: false });

if (7 <= hour && hour < 19) {
  document.documentElement
    .classList.add("light-mode");
} else {
  document.documentElement
    .classList.add("dark-mode");
}

Persist preference

It's a frequent sighting nowadays to have a dark and light switch, allowing users to chose preferred mode. Quite plausible, the user would favor the same choice on return. To persist the user's preference, it's key to consider how and when to react to the stored value.

Cookies enables server-side scaffolding the page to reflect the user's preference. The advantage of considering dark or light mode server-side, is that it enables the right mode prior to applying styles.

Another route is to save the user's choice in localStorage. The Web Storage API is only accessible in the browser, and therefor confines you to toggle accordingly client-side.

Store user's choice #

html

<style>
  :root {
    --background-color: #222;
    --text-color: #fafafa;
  }

  input[name='color-scheme'],
  input[name='color-scheme']:checked + label {
    display: none;
  }
  
  #light-mode:checked ~ .content {
    --background-color: #fafafa;
    --text-color: #222;
  }

  .content {
    background-color: var(--background-color);
    color: var(--text-color);
  }
</style>

<input type="radio" id="light-mode"
 value="light-mode" name="color-scheme">
<label for="light-mode">Light</label>
<input type="radio" id="dark-mode"
 value="dark-mode" name="color-scheme"
 checked>
<label for="dark-mode">Dark</label>

<article class="content">
  <h1>One ring</h1>
  <p>In the darkness bind them</p>
</article>

<script>
  const modes = Array.from(
    document.querySelectorAll(
      "input[name='color-scheme']"));
  
  modes.forEach(
    el => el.addEventListener(
      "click",
      event => localStorage.setItem(
        "color-scheme",
        event.target.id)));
</script>

Preference activation

Don't welcome your visitors with a flash. Leaking a default color scheme, even for a brief moment, will result in an unpleasant user experience. Consider color scheme activation without flashing when choosing toggling strategy.

CSS media queries enables rendering the page without flash, but depends on modern capabilities to exist in the user environment.

For predictable dark or light mode activation in JavaScript, first bear in mind whether the user even has JavaScript enabled. You'll also briefly be blocking rendering as the page initial state is required to be determined prior to rendering a color scheme.

Activate dark or light mode #

html

<head>
  <script>
    const colorScheme = localStorage.getItem("color-scheme") || "light-mode";
  </script>
</head>

<body>
  <input type="radio" id="dark-mode"
   value="dark-mode" name="color-scheme">
  <label for="dark-mode"
   class="color-scheme">Light</label>
  <input type="radio" id="light-mode"
   value="light-mode" name="color-scheme"
   checked>
  <label for="light-mode"
   class="color-scheme">Dark</label>

  <script type="text/javascript">
    // use preferred color scheme
    const useDark =
      colorScheme === "dark-mode";

    document.getElementById(
      "dark-mode"
    ).checked = useDark;
    
    document.getElementById(
      "light-mode"
    ).checked = !useDark;
  </script>
  <!-- ... -->
</body>

I hope I've provided some insights about things to consider when creating a dark mode toggle. Carefully consider your UI to be predictable.

For inspiration, check the following examples. Try them out with or without JavaScript enabled. For implementation details, View Page Source is your friend.

A widely supported example that use the Radio Button Hack to pick mode.
As of Safari 15.4 or later (example added 2022-04-29), you can test the :has selector, which enable better structured HTML.

Decentraliserat lagarbete

2018-11-25T00:00:00.000Z

Sedan jag nämnde konceptet remote-first lagarbete för min fru så har hon återkommit med jämna mellanrum om att hon inte gillar benämningen. Jag medger att begreppet klingar "hellre än bra". Jag uppskattar hennes engagemang, och tolkar det som positivt att kritiken snabbt istället övergår till att prata om arbetsformen. Enligt mig handlar arbetssättet i huvudsak om att arbetet är där du är.

Arbetssätt är ett aggregat

Summan av det du och dina lagmedlemmar gör under arbetsdagen är för mig ert arbetssätt. Om du och dina kollegor jobbar på distans, remote eller hemifrån, vad uttrycker det om ert samarbete? För mig är tankar kring lagarbete viktigare än eventuell distans. Fokus bör inte vara avlägset arbete. Ni förändrar tillsammans era förutsättningar för att samarbete blir mindre platsberoende. Jag föreslår att vi framgent istället pratar om decentraliserat lagarbete.

Eftersom att jag anser det viktigt att beskriva arbetsformen på ett objektivt sätt så har jag hittills inte sökt efter nya begrepp. Det jag vill understryka med arbetssättet är:

Lagarbete
Samarbete kring arbetsuppgifter
Fysisk plats är sekundärt
Vilja att minska avstånd

Där jag upplever att begreppet "remote-first" haltar är att det inbyggt har en underton som fokuserar på distans, att arbetet genomförs någon annanstans. Jag vill fokusera på lagarbetet. Lägg till komponenten att beslutsfattande ska vara oberoende av plats, så tycker jag att ordet "remote" inte räcker till.

Vilja lyckas

Samarbete där plats ska ha liten betydelse ändrar förutsättningarna för hur arbetet genomförs. Jag hävdar att det inte behöver innebära försämrade förutsättningar. Lagarbete i sig kräver mycket omsorg och ständiga förbättringar för att förfinas. Respektera hindren och omfamna möjligheterna med decentraliserat lagarbete.

Allt lagarbete kräver förtroende för varandra och en vilja att lyckas för att bli mer effektiva. För decentraliserat lagarbete kräver det även att dina kollegor omkring laget vill lyckas med samarbetet. Tålamod, gemensamt ansvar och nyfikenhet är nyckelfaktorer för att tillsammans komma framåt när fysisk plats ska vara sekundärt. Att decentralisera lagarbete är att flytta fokus från fysiska begränsningar till förtroende för laget. Effekten av förtroendet speglas i utfall och kvalitet.

Jag har arbetat inom IT-branschen sedan 2006. De senaste fem åren har jag arbetat i företag där iterativ utveckling och snabba releaser är vardag. I dessa organisationer är förbättringsarbete kring samarbete centralt. Hur arbetet uppmuntras och går till ser däremot olika ut. Nu arbetar jag som webbutvecklare för Nepa Sweden AB, i ett team med lagmedlemmarna utspridda på flera svenska orter. Jag berättar gärna mer i detalj om hur vår vardag ser ut och mina erfarenheter av remote/distribuerat/decentraliserat lagarbete.

Hellre övertydlig, än otydlig

2018-10-31T00:00:00.000Z

Föreställ dig själv som deltagare i en gruppövning. Mötesrummet har frostade glasväggar. Dörren till rummet står på glänt. Ljudet smiter ut, av och till tydligt, varvat med nästan ohörbart. Du deltar ståendes utanför. "Jämför dessa med de här" säger en av personerna och pekar på whiteboarden i rummet. Förflytta dig i tanken till ditt hemmakontor, fortfarande deltagare i samma övning med instruktionerna "dessa" och "de här". Efter övningen känns deltagarna i mötesrummet nöjda med resultatet. Du känner dig utanför. Ganska ofta så känns möten som de situationer då distansarbete provtrycks som mest.

Föreställ dig själv som deltagare i en gruppövning. Det finns inget mötesrum bokat. Alla i övningen arbetar i samma Trello-tavla. Digitala versioner av post-its poppar upp i ett organiserat kaos. Efter sju tysta minuter så frågar en av deltagarna "Är alla klara, för att gå igenom idéerna?". En efter en förtydligas de brainstormade idéerna. Förslagen sorteras under "Behöver mer information", "Inget behov" eller "Att göra". Flera av idéerna är snarlika varandra och kan sorteras ut. Innan gruppövningen är klar väljer gruppen tillsammans ut de idéer som verkar mest intressanta att börja arbeta med. Efter övningen känner sig deltagarna nöjda med resultatet. Du också.

Båda scenarierna ovan är upplevda under min resa till remote-first. Jag har lärt mig att tydlighet är viktigt. Det är viktigt att presentera, dela med sig av och efterfråga information på ett tydligt sätt. Hellre övertydlig, än otydlig.

Lär dig krypa innan du går

Arbete remote ställer krav på att minska upplevda avstånd och vara lyhörd gentemot dina kollegor. De upplevda avstånden förändras i takt med vanan av remote samarbete. Det är viktigt att pejla in känslorna i teamet, där vana personer behöver betydligt mindre signaler om aktivitet, medan ovana kan känna obehagskänslor av detaljer som att kommunicera med en avatar. Om ni har lyxen att organisera så att ert team kan träffas fysiskt under en period innan ni påbörjar ett remote lagarbete, så rekommenderar jag er att göra det. Det är lättare att lära känna varandra under samma tak. Ett överkomligt andra steg är att förflytta någon eller några av lagmedlemmarna till andra rum, för att börja öva på remote lagarbete och kommunikation genom headsets.

Oavsett vana av remote samarbete är kontinuerliga reflektioner viktiga. Gör medvetna val. Var tydlig med vad teamet bör fortsätta med och förändra ovanor som påverkar arbetet negativt. Retrospektiv är om möjligt ännu viktigare i remote-first samarbete. Ta tid i anspråk för att stärka lagkänsla och att individer ska få uttrycka frustrationer. För många är kafferaster en möjlighet för att behandla skavande förhållanden. I team som arbetar remote är mötet kring kaffemaskinen i bästa fall ersatt av en gemensam paus från arbetet. Var proaktiv för att skapa miljöer för att andas ut. För att understryka medvetna val, när en förändring genomförs så planera också in en utvärdering.

Teknik (inte) en förutsättning

Remote-first står inte och faller med tekniska förutsättningar, trots att det ofta är teknik som anges som anledning till att samarbete remote är för besvärligt för att satsa på. Enligt mig, är det största hindret för remote samarbete att inte vara proaktiv då information är otydlig, både då den delges och tillgodoses. Många av de situationer som sker på kontor för att få klarhet handlar om att intressenter ställer frågor, medan det på distans oftare handlar om det omvända, att aktivt visa för att få feedback. Som remote-first, våga kräva att inte bli utelämnad.

Teknik underlättar kommunikationen mellan lagmedlemmar om de har ändamålsenliga headsets som aktivt kopplar bort omkringliggande brus. Det är också behagligare för kollegor om så många som möjligt har en lugn omgivning. Sunt förnuft, respekt för varandra och att aktivt använda mute-knappen räcker långt. Var proaktiva och inbjudande under remote samarbete, och eftersträva att hålla den kommunikativa bandbredden så bred som möjligt. Minska distansen till varandra lite extra genom att aktivera video, i synnerhet då personen bakom tangentbordet bör framträda lite extra, exempelvis under retrospektiv.

Strö remote frön

Med tiden kommer du och dina remote-first teammedlemmar känna er mer bekväma än era kollegor under remote samarbete. Hitta tillfällen för att coacha andra och etablera nätverk till andra team. Några rekommendationer jag har för att börja vänja andra med remote-first är:

Du gör dig troligen en björntjänst om du utgår från att alla kan och vill förbättra sättet de kommunicerar remote. Det underlättar om mer vana personer är proaktiva och framhåller vikten av inte göra skillnad på kollegor som arbetar remote. Gör medvetna val för att gemensamt träna på att arbeta remote.
Avboka mötesrum för stående möte(n). Efter några försök kommer förutsättningarna klarna för vad som bör förberedas för att få till ett produktivt möte och hur kommunikationen underlättas. Onlinemöten har med fördel en tydlig agenda och beslut när mötet avrundas.
I retrospektiv, ta gärna hjälp av personer utanför teamet för att facilitera mötet. Utöver att alla lagmedlemmar kan delta aktivt, så medför detta den positiva effekten att öka andra kollegors förståelse för remote-first.
Håll kommunikation öppet i publika forum. Styr aktivt kommunikation från privata möten, chat eller korrespondens via epost till publika forum och/eller chatkanaler. Reagera på signaler om att "vi på kontoret har diskuterat". Desto fler som har tillgång till information, ju färre beroenden finns till att vara på rätt plats vid rätt tidpunkt.

Förtroende trumfar fysisk närhet

Respektera hindren med att arbeta remote-first, och omfamna möjligheterna. Jobba från ett kontor, en sommarstuga, om du hellre trivs på landet eller i ett tyst hörn av ett café. Det som är viktigt är att du aktivt jobbar för ett respektfullt samarbete och gror förtroendet, där fysisk närhet är sekundärt. Tillåt inte laget att stagnera, utan var nyfikna för att hitta förbättringsområden eller bättre tekniska verktyg, men låt vanor stabiliseras för att inte spendera för mycket tid på omlärning. Låt utfall och kvalitet vara ett bevis för ett gott samarbete. Personberoenden ska hållas tillbaka genom att täppa hål som synliggörs extra mycket de gånger det inte finns en kollega tillgänglig. Ta ett gemensamt ansvar för att bygga förtroende och vilja dela med sig av remote-first resan.

Jag har arbetat inom IT-branschen sedan 2006. De senaste fem åren har jag arbetat i företag där iterativ utveckling och snabba releaser är vardag. I dessa organisationer är förbättringsarbete kring samarbete centralt. Hur arbetet uppmuntras och går till, ser däremot olika ut. Nu arbetar jag som webbutvecklare för Nepa Sweden AB, i ett Remote-First team. Jag berättar gärna mer i detalj om hur vår vardag ser ut och mina erfarenheter av distribuerade team och/eller Remote-First.

Närhet är relativt

2018-10-09T00:00:00.000Z

Med laptopen i knät och solen gassandes över dig, så att du får kisa för att urskilja texten på skärmen. Är det den romantiska bilden du ser framför dig när du tänker på remote-first? Eller är det kanske att få komma undan från öppna kontorslandskap, där du inte får flyt för att du blir störd av frågor och hög ljudnivå? Distansjobb kan ge dig både palmer och sinnesro, men för mig är det främst möjligheten att vara tillgänglig och nära familjen som är viktigt. Jag vill att arbetet ska vara en pusselbit i livspusslet, inte ramen för det.

Jag tycker att människors självkänsla, egenvärde och personliga frihet alltför länge har fått stå tillbaka för att samarbete arrangerats med begränsningen att fysisk närhet är ett krav. Vi behöver fler företag som ser nytta i att medarbetare har en chans att få arbete och privatliv att funka tillsammans. Istället för att optimera för kontroll, våga främja medarbetarnas välmående. Om hållbart samarbete anses viktigt, att medarbetare får växa som lag, så tänk om fysisk närhet är ett lokalt optimum. Jag tror att vi istället ska få människor att känna egenvärde och växa med förtroende, och genom det främja företaget.

Jag, inte längre pendlare

Jag är webbutvecklare i ett remote-first team där medlemmarna är utspridda i Sverige. Vi på Nepa har startat ett teknikkontor i Uppsala, varifrån jag oftast väljer att arbeta. Perioden inför att kontorsdörrarna skulle öppnas, så arbetade jag från hemmet eller caféer. Jag föredrar nuvarande lösning eftersom att jag anser att lagarbete på distans underlättas av en lugn arbetsmiljö. Flexibiliteten med att kunna jobba oberoende av plats, med närhet till familjen, har gjort att jag upplever ett större andrum i livet nu jämfört med tiden som pendlare (som jag berättade om i förra delen). Det är inte förrän nu, med pendelstressen bakom mig, som jag inser att jag åsidosatte privatlivet. Jag känner mig allmänt mer välmående, men i synnerhet:

Jag sover bättre. Jag har tvillingar som är drygt ett år, ändå upplever jag min sömn nu som bättre än åren innan. Delvis har jag bestämt mig för att prioritera sömn, men jag tolkar det framförallt som ett tecken på att jag kan varva ner på kvällarna.
Jag har tid och ork att umgås med min fru och mina barn både före och efter arbetsdagen. Jobbet stannar oftast på jobbet, så att jag är hemma både kroppsligt och mentalt. På morgonen är promenaden till skolan med mina barn en trevlig pratstund istället för ett måste på vägen till jobbet.

Remote först, inte också

Jag hör ofta kompisar förklara att det är "skönt att jobba hemifrån", att få komma ifrån kontoret för att få ro att tänka. Samma personer förklarar också att dagarna hemma helst ska vara mötesfria, eftersom att distansmöten medför frustration på grund av teknikstrul. Hur ofta är inte en telefon på högtalarläge lösningen för att få åsikter från personer som inte är i mötesrummet? Att jobba remote-first ska ge samma förutsättningar oavsett var du än väljer att (sam)arbeta från.

Mitt teams (och andra på Nepa också) ständiga förbättringsresa kring remote lagarbete, till skillnad från att också ha kollegor på distans, handlar mycket om att minska upplevda avstånd. Närhet är relativt, har jag med tiden lärt mig. I grund och botten handlar lagarbete om förtroende och att lära av misstag, inte varifrån personer sammanstrålar. Ett exempel på en förändring som jag upplever gör skillnad direkt, är att avstå konferensrum för möten eller workshops. Detta ger alla samma möjlighet att dela med sig av, tillgodose sig och efterfråga information.

Som annat i livet som inte är helt bekvämt, så kräver remote-first träning. Var beredd på att i många situationer krypa igen, innan du lär dig gå. I synnerhet, glöm inte att du jobbar med människor, trots att de inte är i din direkta närhet. Gör medvetna val om vilka vanor som funkar för ditt team, och ni därför ska fortsätta med. Lär dig respektera begränsningarna som remote-first medför, men omfamna möjligheterna. När distans inte längre är ett hinder, så är remote-first lysande! I nästa del skriver jag mer om att komma igång med remote-first lagarbete.

Jag har arbetat inom IT-branschen sedan 2006. De senaste fem åren har jag arbetat i företag där iterativ utveckling och snabba releaser är vardag. I dessa organisationer är förbättringsarbete kring samarbete centralt. Hur arbetet uppmuntras och går till, ser däremot olika ut. Nu arbetar jag som webbutvecklare för Nepa Sweden AB, i ett Remote-First team. Jag berättar gärna mer i detalj om hur vår vardag ser ut och mina erfarenheter av distribuerade team och/eller Remote-First.

Arbete ekar i huvudet

2018-10-02T00:00:00.000Z

Har du hört ledmotivet till den tecknade serien En cell-sam historia?

"Livet, livet, livet livet, se vad livet ger, ger oss av tiden sin egen rytm, i den värld vi lever, andas lyssnar och ser".

Fundera en stund på vad det stycket betyder för dig. Jämför din känsla med när du precis har satt dig på tåget, efter morgonens bestyr och lämning av barn, och får höra att det är ett signalfel som gör att du missar det inbokade morgonmötet.

För ungefär ett år sedan började en ny resa för mig, början på slutet av en över tio år lång resa. En grov överslagsräkning berättar att jag har spenderat nästan ett kalenderår pendlande till och från jobbet. Under den tiden har jag hunnit med att byta arbetsgivare fyra gånger, varav lejonparten av tiden som konsult. Jag har också gift mig och fått fyra barn. Med tiden gick det upp för mig att jag under vardagarna spenderade mer tid på resa än med mina barn.

Jag, pendlare #

En typisk dag för mig som pendlare börjar med att jag stiger upp för trött, eftersom att nedvarvningen börjat för sent dagen innan. Därefter dags att slänga i sig frukost under konstant tjat på barnen att mata sig själva. Tjatet tycks nödvändigt eftersom att de inte har någon tågtid att passa. Däremot påpekar de mer än gärna hur rörigt det är varenda morgon för att pappa har så bråttom. Efter att halvsprungit och lämnat på (för)skola så tar jag cykeln för att nätt och jämnt hinna till tåget. Så här ser det ut nästan varje dag.

Jag reser med tåg och alltid med brusreducerande hörlurar. När väl pulsen lagt sig en aning, så tar jag skydd i en värld där övriga pendlare inte kan nå mig. Jag avskärmar mig så mycket jag kan med datorn uppslagen i knät och med musik i hörlurarna. Jag upplever resan, i min egen lilla värld, som en av höjdpunkterna under dagen. Det är min egentid. Vad jag som pendlare inte tycks begripa, är att det jag egentligen vill åt är möjligheten att andas ut.

När jag kommer fram till kontoret så börjar ofta kontorsarbetet med att ta vid där skärmen slogs igen på tåget. Det är inte ovanligt att jag medvetet har lämnat en tydlig brytpunkt, som att programmet inte kompilerar eller ett enhetstest som inte går igenom. Egentligen har alltså arbetsdagen redan börjat på tåget. Pendlingen är ett utrymme och marginaler för att minska stressen under resterande arbetsdag på kontoret. Det resulterar också i att en arbetsdag ofta är längre än åtta timmar.

Jag använder sällan brusreducerande hörlurar på kontoret, trots att jag upplever att höga diskussioner påverkar mig kognitivt negativt. Den huvudsakliga anledningen till att jag inte avskärmar mig är för att jag trivs med att jobba tillsammans med andra för att förstå och lösa problem. Jag tycker om att kunna ställa mig vid en whiteboard tillsammans med kollegor för att få en gemensam, tydlig bild av ett problem och därifrån forma en plan att utgå från. Priset för att ständigt vara en del av en obruten ström av information, mer eller mindre frivilligt, är att arbete ekar i huvudet även utanför arbetstid.

Efter att ha stressat till tåget, där jag försöker avsluta några arbetsuppgifter, så kommer jag äntligen hem. Väl hemma upptäcker jag att jag har missat middagen med familjen och att det snart är dags för läggning av barnen. Jag försöker hinna med lite lek och bus innan det blir tjafs med barnen om att äta ordentlig middag istället för ett extra kvällsmål. Därefter är det läsning av böcker, följt av rännande i och ur sängen. När barnen väl somnar är jag helt slut.

Jag, remote #

När jag började arbeta för min nuvarande arbetsgivare fick jag möjlighet att jobba på distans från hemort, att jobba remote. Nu efter ett år vill jag dela med mig av mina erfarenheter och hur jag idag förespråkar att fördelarna för arbete remote övertrumfar nackdelarna, som välmående och personlig frihet. I nästa del berättar jag om min upplevelse av att jobba på distans, i synnerhet om samarbetsformen som kallas Remote-First.

Jag har arbetat inom IT-branschen sedan 2006. De senaste fem åren har jag arbetat i företag där iterativ utveckling och snabba releaser är vardag. I dessa organisationer är förbättringsarbete kring samarbete centralt. Hur arbetet uppmuntras och går till, ser däremot olika ut. Nu arbetar jag som webbutvecklare för Nepa Sweden AB, i ett Remote-First team. Jag berättar gärna mer i detalj om hur vår vardag ser ut och mina erfarenheter av distribuerade team och/eller Remote-First.