DEV Community: Maxim Salnikov

A practitioner's guide to getting more value out of AI coding: agent quality & token optimization

Maxim Salnikov — Mon, 25 May 2026 20:15:13 +0000

Introduction: The Wrong Question

GitHub's shift from premium requests to usage-based billing has triggered a wave of anxiety across engineering teams. The question echoing through Slack channels and leadership meetings is some variation of: "How do we reduce our token spend?"

It's the wrong question.

Focusing purely on cost diminishes the value you get from agents. A better framing is: "How do we get the most out of the tokens we spend?" That subtle reframing changes everything — from how you write prompts, to which model you reach for, to how you architect your codebase, to how you organize your team's workflows.

This article walks through the full case for quality-first token optimization, the foundational mental models you need to reason about it, and the concrete controls and techniques that move the needle.

Part 1: Why Agent Quality Is the Better Lens

Agent Gambling Is No Longer Sustainable

When tokens were effectively free, agent accuracy didn't really matter. The dominant pattern became what's best described as "agent gambling": throw together a lazy prompt with minimal context, fire off an agent, and if it fails, fire off another one. Think of it as the NASA Artemis problem in reverse — if rockets were cheap, you'd send 20 in the general direction of the moon and hope one lands.

That worked when each developer ran a handful of agents per day. It stops working the moment developers — and especially AI engineers orchestrating fleets — are running dozens or hundreds of agents per day. The economics invert. The cost of misfires dwarfs the cost of doing the work properly.

The fix isn't to send fewer rockets blindly. It's to make sure each rocket actually lands. Higher per-agent quality means fewer retries, fewer wasted tokens, and better ROI on every dollar of usage.

The ROI Mental Model

The guiding equation for thinking about agent economics:

Agent ROI = (Value of Agent Output − Token Cost) / Token Cost × 100%

You can't calculate this precisely, but it's a directionally useful lens. Two things follow immediately:

Optimizing cost when value is zero is meaningless. Cutting your spend by 50% on outputs that don't ship anything useful is just losing money more slowly.
Increasing value often means decreasing tokens. Developers routinely stuff irrelevant text into prompts, let conversations compound with stale context, and pile on documentation the model doesn't need. Trimming that context usually improves both quality and cost simultaneously. They're the same lever.

The Compound Error Problem

Here's the math that should haunt anyone running multi-step agent workflows: errors compound multiplicatively.

At 99% accuracy per step, a 50-step workflow lands at ~60% overall success.
At 95% accuracy per step, the same workflow drops to ~8%.

LLMs are non-deterministic. Every step in an inner agent loop, every hop in an orchestrated workflow, every tool call — they all multiply against each other. This means every percentage point of per-step quality buys you a disproportionate improvement in overall reliability. And every miss isn't just a wasted token call — it triggers fix cycles, review overhead, reruns, debugging sessions, and burned human attention.

The takeaway: apply the same "shift-left" mindset to agents that you apply to quality, testing, and security in traditional engineering.

The Mantra

The whole philosophy collapses into one line worth pinning to your monitor:

Instead of counting tokens, make every token count.

Reduce token usage as a consequence of pursuing quality — not as a goal in itself. Send fewer, better-targeted rockets. The fuel savings follow automatically.

Part 2: Foundations — LLMs, Agents, and Context Windows

Before you can optimize anything, you need to internalize a few mechanical truths about how this technology actually works.

LLMs Are Pure Word Probability Machines

Strip away the marketing and what you have is a text-in, text-out system that predicts the next word given an input plus the patterns from its training data. When you type "GitHub Copilot is the world's most widely…" the model assigns probabilities to candidate next words — used, adopted, deployed, and so on — and picks one. In a coding context, it's predicting the next instruction.

Models have gotten dramatically better, but the underlying mechanism hasn't changed. This matters because the math doesn't distinguish hallucination from fact. A made-up function name and a real one occupy the same probability space. The model isn't "lying" when it hallucinates — it's just doing what it always does with insufficient signal.

The Core Principle of Context

Which leads to the single most important principle in this entire discipline:

Provide as little context as possible, but as much as required.

Two failure modes flank this principle:

Too much context biases the model toward irrelevant patterns and dilutes the signal. Stuffing in five files when one is relevant makes the model worse, not better.
Too little context forces the model to hallucinate to fill gaps. It has to predict something, and without grounding, it guesses.

Context engineering — the discipline of finding that sweet spot — is the fundamental skill of working with agents.

What an Agent Actually Is

An agent is not magic. It's an app — code that sits between you and the LLM. The architecture is simple:

You and your project ↔ The agent (harness) ↔ The LLM

Harnesses are things like VS Code Chat, Copilot CLI, Copilot Cloud Agent, Claude Code, OpenAI Codex. Models are things like GPT 5.5, Claude Opus 4.7, Gemini Pro. The harness is the orchestrator; the model is the inference engine.

Two things are crucial to understand here:

The LLM is stateless. What feels like a "conversation" is actually the harness re-sending every prior input and output on every turn. There's no memory inside the model — only an ever-growing transcript being shipped back and forth.
Tokens compound. Every loop drags the previous loops along with it. Your levers are the things that go into the context: your prompt, the files you reference, and the agent configs (instructions, skills, MCPs) the harness injects.

Context Window Mechanics

A token is roughly ¾ of an English word. Smaller models offer 50K–200K token windows; larger ones like Opus and GPT-5.5 push toward 1M tokens. For scale: 1M tokens is roughly the entire Lord of the Rings trilogy plus The Hobbit.

Don't obsess over token counting at the character level. Think at the level of prompts, files, and responses — those are the units that compound on each loop.

Context Rot: The Hidden Failure Mode

Even with a huge window, models don't treat all positions equally. Two well-documented effects govern how attention is distributed:

Lost in the Middle (below ~50% window fill): Models bias toward content at the beginning and the end of the context. Middle content gets less weight.
Recency Bias (above ~50% window fill): As the window fills up, attention skews heavily toward the end. System prompts and custom instructions sitting at the beginning start getting effectively ignored.

The practical implications are significant:

The beginning of context is prime real estate for instructions and goals.
The end is where current work lives.
The middle is where past work decays in influence.
Just because you can fill the context window doesn't mean you should. Try to keep it under 60–70%.
If you switch tasks mid-session, the model may revert to the original task, because that's where the strongest signal still lives.
Above 50% fill, you start losing your own guardrails to recency bias.

The fix isn't compaction (which trades tokens for potential information loss). It's a new context window per task — /clear liberally, divide work into discrete sessions, and don't let conversations sprawl.

Part 3: Quality and Token Controls — The Practical Playbook

Now to the controls themselves, ordered roughly by leverage.

Where You Are on the Maturity Curve Matters

Two archetypes exist on the agent maturity spectrum:

AI-assisted engineers work mostly synchronously with one agent at a time. If you're sending ten agents per day and spending $20/month, saving 50% on tokens just gets you to $10. The juice isn't worth the squeeze.
AI engineers orchestrate fleets of asynchronous agents. Every percentage point compounds across hundreds of runs. The compound error problem hits hardest here, and optimization pays back enormously.

Calibrate effort accordingly.

The Two Biggest Levers

Two controls vastly outweigh everything else: model choice and relevant context.

Model choice is the single highest-leverage decision. The cost gap between top-tier reasoning models (Claude Opus 4.7) and small models (GPT-5.4 mini) is roughly 24x. Match the model to the task:

Reasoning models (Opus, GPT-5.5) for synchronous planning, architecture, debugging, and any work involving large context.
Mid-tier models (Sonnet, GPT-5.4) for asynchronous implementation work.
Low-tier models (Haiku, GPT-mini) for small refactors, repetitive tasks, and documentation updates.

A reasoning model on a trivial task isn't just expensive — it can actively make things worse, second-guessing tight specifications and "going rogue." Conversely, a small model on a planning task will produce shallow, brittle output.

Auto Mode (rolling out from June) detects task intent and selects the model for you. It's the lazy default for anyone who doesn't want to think about it — and it's usually right.

Relevant context is the other half of the equation. Don't stuff prompts with "might need" information. Let the agent discover what it needs. Compacting sessions trades tokens for potential info loss — use it cautiously. And use /clear often — tokens don't carry across sessions, so a clean slate is free.

Your Prompt

The prompt is always-on. It sits at the beginning of the context window and has outsized influence due to lost-in-middle effects.

A few rules:

Don't optimize prompts for fewer tokens. Optimize them to steer correctly.
Be precise and descriptive. "Fix the bug" is useless. "Issue #45 describes a bug where X happens — fix it" actually goes somewhere.
Add stop signals. Phrases like "Stop after you've written the fix. Do not commit or push." prevent agents from running past your intent.
Add known context upfront. Relevant file paths, doc URLs, skills to invoke. Don't make the agent rediscover what you already know.

Divide and Conquer: Research → Plan → Implement

A single context window doing research, planning, and implementation drags irrelevant files and stale reasoning through every phase. Quality degrades.

The pattern that works:

Research (e.g., Gemini 2.5 Pro): "I want to change X. What files are relevant?"
Plan (e.g., Opus 4.7): Take the research output and produce a precise specification.
Implement (e.g., GPT-5.4, often in parallel): Multiple agents split by architecture layer (frontend, backend, database) with clearly defined contracts between them.

Each phase gets a fresh context window. The spec is the artifact that carries information across the boundary — clean, distilled, free of noise. This saves both time and tokens, and produces far higher-quality output than one monolithic session.

Deterministic Controls: The Compound Error Antidote

Tests, linters, security scanners, type checkers — anything code-enforced and deterministic — are essential context engineering tools. A test either fails or passes. There's no probability. Every passing test resets the compounding error rate to zero for the property it covers.

The contrast is stark:

With tests: buggy change → failing test → correction → passing test. Done.
Without tests: buggy change → buggy change on top of it → another one → incident → debugging session → burned CI/CD minutes, review cycles, human time.

The Copilot CLI team ships roughly 500 PRs per week. Roughly 53% of their codebase is tests. That's not overhead — that's the moat that lets them move that fast without burning down the production system.

Cheap in the short term means expensive in the medium term. Guardrails pay back many times over.

Agent Configs: The Context Engineering Surface

Modern agent harnesses pick up a stack of markdown files automatically. These are the surface you work with as a context engineer:

Persistent instructions — copilot-instructions.md. Always loaded.
Custom agents — ./github/agents/*.agent.md. Role-based, manually invoked.
Skills — ./github/skills/*/skill.md. Conditionally loaded.
MCPs — external tool integrations.
Subagents — separate context windows spawned by the main session.
Scoped instructions — ./github/instructions/*.instructions.md. Path-pattern based.
Prompt files — ./.github/prompts/*.prompt.md. Manual starting points.
Copilot Memory — small always-on instructions learned from behavior.

Each has a place. Let's go through the high-leverage ones.

Persistent Instructions

These are your always-on guidance, the proactive human-in-the-loop signal. Three things belong in them:

Project non-negotiables (architecture rules, conventions that can't be inferred).
A log of recurring agent misses (wrong test framework? wrong build command? Write it down.).
Output-trimming statements ("be concise"). Output tokens are the most expensive — trim them aggressively.

Critical rules: keep them small, don't use AI to generate them, and recreate them often. Research shows that "be concise" performs nearly as well as a 50-line "caveman" skill. AI-generated instructions bloat. Write them yourself, iterate, throw them away. The Copilot CLI team rewrites their entire instructions file every three months as a living document.

Custom Agents

A custom agent forces the model into a specific role or workflow — for example, a /tdd-red agent that only writes failing tests. The harness retrieves the agent file, injects the definition, restricts the available tools, and appends your prompt.

The token savings are modest (input is cached). The real win is preventing wrong paths. Restricting an agent to read-only access on GitHub issues, for instance, eliminates an entire class of mistakes.

Skills

Skills are conditionally loaded markdown. The harness puts the description of every skill into context; the LLM tells the harness when it needs the full skill loaded.

Two pitfalls:

Don't overdo it. Hundreds of skill descriptions bloat context for marginal benefit.
Avoid redundant skills. A "React skill" is wasted if the model already knows React fluently. Skills should add capabilities the agent wouldn't otherwise have. And maintain them as models evolve — what was needed last year may be built-in now.

MCPs

MCPs add external tools and API calls. The harness offers tool descriptions to the LLM, which invokes them when needed.

Be rigorous. MCPs bloat tool descriptions and can lead to undesired tool calls. Deactivate MCPs you don't always need, or wrap them inside custom agents that scope when they're active.

The Playwright MCP is the canonical example: powerful for frontend work, but expensive (screenshots, page reads, full DOM parsing). If always-on, it triggers unnecessary work for trivial CSS changes. Pair it with a custom agent that only activates it when you're doing real UI work.

Subagents

A subagent opens a second context window for a specific task — research, document summarization, etc. — and returns a compact summary to the main session. This keeps the main context clean.

The trade-off: more tokens are spent inside the subagent. It's a conditional optimization. Use it when the alternative is polluting your main session with hundreds of irrelevant files.

The Rest

Scoped instructions are useful in monoliths with distinct sections (e.g., one set of rules for the auth module, another for billing). Start with static persistent instructions first; reach for scoped only when needed.
Prompt files are manually invoked, can trim the toolset, and serve as good standardized starting points. (Not supported in Copilot CLI at the moment.)
Copilot Memory learns from your behavior automatically. Check it periodically to make sure it's learned the right things.

Power User Techniques

For orchestrators running hundreds or thousands of agents, additional levers exist — though they trade quality for token savings and require careful testing:

Think in code. Prefer scripts to analyze files over feeding them to the LLM. A 200-line file analyzed by a Python script consumes near-zero tokens versus thousands in context.
CLI over MCP. Models already know how to use tools like gh. A CLI invocation can be leaner than the equivalent MCP, because the model doesn't need static tool descriptions injected.
Trim shell outputs. Tools like rtk strip CLI output down to agent-relevant information.
Run /chronicle tip regularly in Copilot CLI to surface optimization opportunities from your actual session logs.
Collapse tool calls. Plugins like copilot-codeact-plugin batch multiple calls into single operations.
Model-specific context tweaks. Only worth it for fleet orchestrators with thousands of runs. Risky given how fast models change.

Part 4: Long-Term Guidance — The Skills That Will Matter

Zooming out from the tactical playbook, three durable traits separate developers who'll thrive in the agent era from those who won't.

Build Analytical Skills

Coding itself was never the true source of developer value. Analytical thinking and deep domain proficiency were. Agents can write code; they can't decide what should be built, in what domain language, with what trade-offs. The ability to tell an agent precisely what to do, in the language of the domain, is the most valuable skill. Invest there.

Apply Good Architecture

Domain-Driven Design, Hexagonal Architecture, CQRS, Event-Driven Design — these matter more now, not less. Good architecture:

Makes agent discovery faster (clear file organization, predictable patterns).
Provides guardrails that prevent agents from putting code in the wrong place.
Reduces the fix/debug cycles that come from architectural drift.

The old debates — five-line functions versus ten, semicolons, comment style — are noise. Architecture is signal.

Iterate on Prompts and Agent Configs

Treat this with an engineering mindset. Keep configs fresh. Treat every agent miss like an incident — log it, fix the underlying instruction or skill, prevent recurrence. Use /chronicle regularly in the CLI to surface patterns. This is continuous engineering work, not a one-time setup.

You are now a context engineer. That's the job.

Part 5: Five Things to Start Doing Today

If you take nothing else from this, take these five:

Choose the right model for the right task. Reasoning models for planning and debugging; mid-tier for implementation; small models for trivial work. Let Auto Mode pick when in doubt.
Provide clear guidance in your prompts. Be precise. Add stop signals. Provide known context upfront. Don't be terse for the sake of saving tokens.
Research → Plan → Implement. Separate context windows per phase. Distill a precise spec between them. Parallelize implementation across architecture layers.
Provide deterministic guardrails. Tests, linters, security scans — anything code-enforced. These reset the compound error rate.
Maintain a concise, human-written copilot-instructions.md. Use it as an agent-miss log and to trim outputs. Keep it small. Rewrite it often. Don't let AI generate it.

Summary

The whole discipline reduces to one principle:

Write as little context as required, and as much as necessary.

Token cost optimization isn't really about tokens. It's about quality, precision, and engineering rigor applied to a new substrate. The teams that internalize this — that stop counting tokens and start making every token count — will out-ship, out-quality, and out-economize everyone still gambling with cheap agents.

I'm happy to answer your questions, and to help your team or organization with agent quality and token optimizations techniques - send me a message on LinkedIn.

Leveraging GitHub Copilot Chat syntax: chat participants, chat variables, slash commands

Maxim Salnikov — Sun, 23 Jun 2024 14:44:42 +0000

GitHub Copilot Chat is an incredibly powerful and useful feature that allows you to chat with or about your code. Even though it’s 100% natural language-friendly (i.e., you can send your messages without using any specific syntax), leveraging some special chat capabilities can unlock new AI-assisted development scenarios and significantly boost your productivity.

These powerful features, which you can use by applying special syntax, include chat participants, slash commands, and context variables. Note that the described features are available in VS Code and might not be fully supported in other IDEs where GitHub Copilot Chat is available.

Target your question or request by messaging one of the available chat participants

In GitHub Copilot Chat, you can reference one of the AI-powered “domain experts” using conventional chat syntax—by prepending @ to the participant name. The currently available chat participants are:

@workspace: Knows everything about the code in your currently open workspace. This is the chat participant you will most likely communicate with frequently.
@terminal: Knows all about the integrated terminal shell, its contents, and its buffer.
@vscode: Knows about the VS Code editor, its commands, and features.

Example: Let’s get information about the backend part of the project we’ve just been assigned to by asking the @workspace chat participant right after we open the project folder in VS Code.

In this particular case, you don’t even need to have files open in your editor. Compare this with the response you get without tagging @workspace:

The @workspace chat participant is instrumental for all solution-wide queries where you want all code to be considered for the chat response. However, this doesn't mean that all code will be used and sent as part of the prompt. The GitHub Copilot Chat extension in VS Code does its best to determine relevant files and parts of these files using local knowledge and intelligence first. You can check which files and code lines were used for the prompt by expanding the “Used references” line:

Productivity hint: Use Ctrl-Enter (Cmd-Enter) instead of just Enter after typing your message, and the @workspace string will be inserted into your message automatically before sending.

Be precise in setting the context using chat variables

In many cases, considering the full solution as the context for your question or request (by using @workspace) is overkill. You might want to point to specific files or even parts of the files in your message. Chat variables can help! Use # to call one from this list:

#file: Points to a specific file in your workspace.
#codebase: All content of the open workspace. It’s similar to using @workspace and might be useful when you chat with another agent (like @terminal) but still want to reference the full solution.
#editor: Source code in the editor’s viewport (visible part).
#git: Current git repository: branch, remotes, path, etc.
#selection: The currently selected code.
#terminalLastCommand: Last run command in the editor’s terminal.
#terminalSelection: Selection in the editor's terminal.

Example: Let’s get help on improving method names in a specific file (and we want to ensure that the whole content of the file is taken into consideration).

Productivity hint: Use the up and down keyboard arrows to pick the chat variable you need after typing #. In the case of #file, use keyboard navigation again to pick one of the suggested files.

Call the most often used actions quickly with slash commands

Chatting with your code using natural language is fun, but having the option to call often-used actions using handy shortcuts is even better. Compare typing the full message “Explain how selected code works” versus typing “/”, then using keyboard arrows to pick /explain from the popup overlay. Another benefit of using the predefined syntax for commands is the confidence that GitHub Copilot understands our intent 100% correctly (natural language might have some ambiguity). There are a bunch of slash commands available. You can use them in conjunction with referencing the chat participant to provide the desired scope. Some of the commands are:

/help: Help about available slash commands, chat participants, chat variables, and more.
/doc: Generate documentation for the code.
/explain: Explain how the code works (or get help with terminal commands if you prepend @terminal).
/fix: Optimize and/or fix issues in the code.
/tests: Create unit tests for the code.
/new: Scaffold a new workspace.

Example: Let’s get an explanation for one of the regular expressions in our code. Select the code line and use the slash command “
/explain.

Productivity hint: Try GitHub Copilot Chat in inline mode instead of having the chat always open in the side pane. Press Ctrl-I (Cmd-I) and type your message in the small overlay dialog that appears right above the line where your cursor is in the code window.

Summary

Use chat participants, chat variables, and slash commands to maintain full control over the conversation context, ensure correct and consistent understanding of your intentions, and ultimately chat and code faster!
Start your free GitHub Copilot trial here: https://aka.ms/try-github-copilot

References

Building oEmbeddr using Azure Static Web Apps with Svelte, Bootstrap 5, and TikTok!

Maxim Salnikov — Tue, 03 Nov 2020 21:57:01 +0000

Let's build a simple web application that uses posts embedding code generation API exposed by the social networks.

TL;DR: In this chapter, you will learn about:

Scaffolding a Svelte 3 app which performs a fetch request
Adding Bootstrap 5 UI with using modern frontend techniques
oEmbed format
The very first step to build, deploy, and host your webapp on Azure Static Web Apps service
The app will look like this: oEmbeddr v1

To find the app idea, I explored a couple of quite extensive unofficial TikTok API projects but decided to keep things simple and go for the only web-focused official one dedicated to embedding videos using oEmbed format. I've never heard about oEmbed before but it seems like it's an industry-standard in sharing the content from social networks: there are 248 providers available so far including all the major players.

This format and corresponding API is too simple - a single GET endpoint. So I decided to add some extra complications to challenge myself a bit: for the frontend I will use the Svelte framework I've never tried before, and for the UI, I will use Bootstrap. Well, it's hard to find a frontender who built websites in the early 10s (pre-frameworks golden era) and never used Bootstrap. I personally actively used versions 2 and 3 of it before switching to framework-connected UI tools. But after a long break, I decided to check what's going on with this legendary UI library and discovered a Bootstrap 5 Alpha 1 version announced in mid-June 2020. As blog post states, it's the first version without dependency on jQuery, including enhanced grid system, extensive usage of CSS variables, rearchitected form controls, and tons of other new features. It's hard to find a better opportunity to explore it and share my findings.

Also, TikTok video embedding API will be just a starting point for us - the app I called oEmbeddr will eventually support all the providers mentioned in the oEmbed repo. But let's keep this for the next articles. What do I want to achieve today:

A SPA with only one section (so far) where we have the input for the social network post URL to share
Sending a request to the corresponding API endpoint
Displaying an HTML code we received, having "Copy to clipboard" feature, and a preview
Responsive, accessible, satisfactory looking UI
Zero configuration CI/CD workflow
Globally distributed hosting

Let's go!

What is oEmbed and how to use it in TikTok

Many if not all social networks have the functionality to get an HTML code to embed a particular post in some external resource like a blogpost. And all of them build this feature using oEmbed format co-created by Cal Henderson, current Slack CTO, and co-founder.

From the UX perspective, some of the networks (like TikTok) have the corresponding button explicitly visible and getting the code is just a click away, other (like Facebook) redirect you to the developer portal and you have to learn about SDK, configuration, etc. before getting the code, thirds (like Twitter) just hide this feature from UI but support it.

You can read the full oEmbed format specification here but for our project, we'll use the simplest scenario: we call an API endpoint (GET method) where we pass a required parameter url. In return, we receive a JSON with the HTML code in the html field to embed. A page called Embed videos of the TikTok Developer portal informs us about supporting exactly this option.

And... we are lucky with selecting TikTok as a very first provider for our demo: it's the only service from the social networks I tried which has the Cross-origin resource sharing (CORS) configured the way we can call this API endpoint straight from the browser. So we can keep building backend of oEmbeddr for the next articles.

Scaffolding a Svelte app

Why did I ever decide to use Svelte? First, I wanted to try it for a long time. And second, I'm not a big fan of the direct DOM manipulation. So I'm fine with having some code overhead and getting a nice developer experience in return.

If you use the VS Code I strongly recommend installing Svelte extension. It provides syntax highlighting and rich intellisense for Svelte components in VS Code.

After reading the "Getting started" page I created a "hello world" template using degit - a utility for the straightforward project scaffolding, also by Rich Harris, creator of Svelte.

npx degit sveltejs/template oembeddr
cd oembeddr
npm install
npm run dev

Just a few moments and a ready-to-go dev environment created. Opening http://localhost:5000/ in the browser works fine. Running npm run build generates a production code to be deployed in the public folder (let's remember this name for later).

After quick learning on how to bind data from the input value (to pass the URL user provides to my fetch method) and handling DOM events (form submission in my case), I was ready to fetch the data from TikTok API.

So, we have to send an HTTP request and update UI based on the response. This is where Svelte's reactivity and DX shine! I just followed this async/await example from the tutorial to have a resulting code and markup in the core (and only for now) app component in the file App.svelte like this:

And it works! Hereafter, I will use my first ever TikTok video as an example. Please feel free to watch the magic transition of my cat to Octocat, and follow me :)

I send a request, get results, display it in UI. All reactively, declaratively, without manual DOM manipulation. Svelte just works and the bundle.js size after I run npm run build is 6K. I find it acceptable.

But we can't deploy a page with such a minimalistic design and poor UX. Let's use a UI library!

Adding Bootstrap 5

Let's live on the edge and install a very first (and only to the moment) Alpha of this version: npm install bootstrap@5.0.0-alpha1

Disclaimer. I'm aware of the awesome Sveltestrap library with some really "Svelte-native" components based on Bootstrap. It might be a better technical decision for real-life projects. But my strong intention was to try Bootstrap 5 (Sveltestrap uses v4) in a "modern frontend" mode: with compiling Sass for theming, with importing only JS components we use, with outsourcing the build to Svelte dev environment. Also, I understand that by direct usage of Bootstrap JS components I partially lost the app code's reactivity and declarativity.

Styles

The package contains both built/complied assets and source code. I want to have full control over resulting CSS both in terms of components I include and theme I use, so let's find a way to compile Sass during the Svelte app build.

Bootstrap uses PostCSS and Autoprefixer for Sass compilation and we can have these tools injected into the overall build flow by the magic of svelte-preprocess package that "acts as a facilitator to use other languages with Svelte, providing multiple features, sensible defaults, and less noisy development experience". To get this configured I follow this thread:
1) Installing the packages:

npm install -D svelte-preprocess node-sass autoprefixer

2) Adding to the Rollup configuration file rollup.config.js following lines:

import autoPreprocess from 'svelte-preprocess';

const preprocessOptions = {
    scss: {
      includePaths: [
        'node_modules',
        'src'
      ]
    },
    postcss: {
      plugins: [
        require('autoprefixer'),
      ]
    }
  }

export default {
    ...
    plugins: [
        svelte({
            ...
            },
            preprocess: autoPreprocess(preprocessOptions)
        }),
        ...
    ],
    ...
};

It gives us possibility to use Sass syntax in the source code:

<style type="text/scss">
  $body-bg: #eeeeee;
  @import "bootstrap/scss/bootstrap";
  // and other Sass awesome features
</style>

I also recommend to set up Svelte for VS Code extension to have better Sass support in IDE.

It's good to know that specifying node_modules in includePaths gives us the possibility to skip adding ../node_modules/ part of the import path which makes our source code look way cleaner.

Then, I create src/styles.scss file and follow the customization guide of Bootstrap. I import only the core configuration files and the files with the styles of components I will use: Nav, Navbar, Toast, Alert, etc. On top of the same file, I will override some color variables to give my app a unique style. The result (shortened a bit):

I reference this file in App.svelte:

<style type="text/scss">
  @import 'styles';
</style>

Now, after the build, I see some Bootstrap classes in bundle.css - a good sign! But the file size is too good to be true - 2 to 7K (depending on the amount of HTML markup you have so far). Bootstrap CSS with the number of components we specified can't be so lean. When we try to apply some Bootstrap classes to HTML markup the CSS bundle file size grows but the result looks somehow broken. What's wrong? Nothing. In addition to styles scoping, Svelte's compiler is removing unused (in this particular component) classes from the resulting CSS. But in case of the UI library (like Bootstrap or others), we have some classes applied to outer parts of this particular component even if it's the root one (for example, for <body> tag) and we want all classes to be available for all other components without scoping. I.e. we take a technical decision to plug in the whole UI library CSS file to Svelte's root component (App.svelte in our example) "as is".

And there is a solution for that! We can make the styles in the <style> block fully or partially untouched by Svelte's scoping and optimizing engines by using a global modifier like explained here. So I added it to the code:

<style global type="text/scss">
  @import 'styles';
</style>

and everything related to Bootstrap styling started to work as intended.

The obvious downsides of this:

Svelte can't optimize CSS by removing unused styles. We take care of it ourselves by importing only the parts of the UI library we need.
Svelte can't prevent styles "leakage" from this component to all others. But in for the UI library, this behavior is exactly what we want.

All clear with the styles now, we are ready to use Bootstrap classes in our markup!

Adding some layout helpers, classes, extra attributes to the form...

...and the look & feel is completely different:

JavaScript plugins

Let's stop with the styles for now and have a look at Bootstrap's JavaScript plugins. For oEmbeddr, I decided to use:

Tabbed content component (In the Bootstrap, it's called "Nav" in the component library, plus "Tab" in JavaScript plugins) to separate UI of the embed code (we'll place this code into an textarea) and preview (we'll load this code into an iframe using srcdoc attribute)
Floating message box ("Toast" in the Bootstrap) to show the success message after clicking the "Copy code to clipboard" button.

Setting up Nav/Tab is straightforward: just use the provided HTML code sample from the documentation with correct data attributes binding the "tab" and content it shows. For our scenario, there is no need in any JavaScript code except the module import:

import Tab from 'bootstrap/js/src/tab';

In the modern browsers, we can use this import without any extra processing in <script type="module"> tag but let's ask Svelte to do bundling for us, just put this import into <script> section of App.svelte.

The component works fine:

Let's cook a toast now. First, import:

import Toast from 'bootstrap/js/src/toast';

Then, adding HTML (I simplified this sample):

<div class="toast" role="alert" id="copySuccessToast" data-delay="2000">
      <div class="toast-header">
        <strong>oEmbeddr</strong>
      </div>
      <div class="toast-body">The code was copied to the clipboard</div>
</div>

Finally, we initialize and show (here is the API docs) this message box (after successful copying code from textarea to the clipboard):

let copySuccessToast = new Toast(document.getElementById("copySuccessToast"));
copySuccessToast.show();

Let's give it a try:
1) Open https://kind-sea-08852d11e.azurestaticapps.net/
2) Paste https://www.tiktok.com/@webmaxru/video/6858249402683886854 into the input, click "Get code"
3) Click "Copy to clipboard" and you will see this toast:

That was a journey! But now we know how to plug in Bootstrap 5 in its the most natural and flexible form to Svelte application.

Time to push our project to GitHub - here is my repo with the full source code, please, feel free to clone it - and proceed to the next step.

Hosting

Let's present our application to the whole world! With the global distribution and dynamic scale provided by Azure Static Web Apps service, we are fully covered!

This will be the shortest section of our story because setting up a frontend application on Azure Static Web Apps takes only a few clicks and less than 5 minutes.

Log in to Azure cloud portal (if you don't have an account please register a free trial), search for Static Web Apps in the top search field, and click "Add".

On the first screen, you enter your app name, resource group (or create new), and region. Also, you will be asked to log in to your GitHub account and to select an organization/repo/branch where the app located:

On the next screen, you need to specify some details about your project. In our case, we only need to type public in the App artifact location field (do you remember I asked you to remember where Svelte outputs the build artifacts?)

After clicking on "Create" and a few seconds, you will get a test public URL of your application available (for my project - https://kind-sea-08852d11e.azurestaticapps.net/). But while Azure Static Web Apps fetches your source code from GitHub, builds & deploys it (all automatically) you might want to have a look at the workflow for GitHub Actions file (my one) which was just created and added to your repo.

We are not going into the details of the Workflow file format, I just want to mention that since now, every push/merge to your master branch will invoke the CI/CD flow and you will be able to see an updated version of your app in a few moments (on the same URL). You can track the build progress in the corresponding GitHub Actions section.

Summary and what's next

We covered the application scaffolding using Svelte, adding Bootstrap 5 library, and hosted this simple page on the Azure Static Web Apps service. In the next article we:

Check how the staging works in Azure Static Web Apps when we want to preview a next version of the application without touching the "production URL"
Add more social network providers. To do it we'll build a backend using API part of the Azure Static Web Apps solution. Serverless for the win!

Let's stay connected on Twitter @webmaxru. And I'll be happy to see your feedback in the comments.

Maxim Salnikov
Developer Engagement Lead in Microsoft Norway

You are an Azure Hero. What's next?

Maxim Salnikov — Fri, 09 Oct 2020 16:19:43 +0000

Disclaimer: if you are not a lucky owner of an Azure Hero badge yet, please, learn more about this program and how to join.

Congratulations! You are one of the Azure Heroes. That means you have a mobile app called Enjin Wallet, created by our partners, which contains one or multiple badges. What's next? You decide! You could just secretly keep this collection for your eyes only and grow it. Or you could explore some interesting opportunities for you to contribute back to the tech community using your Azure Heroes status.

1. Share your award with the developer community

Every badge you have in your Enjin Wallet has a convenient way to publish it on social media. Just use the well-known "Share" icon on the badge details screen or use the "Share" menu item (click the three dots menu to get to it). You will get a quick post template for sharing on Twitter, LinkedIn, and others. Or you can just copy-paste the link to the badge from this template and write your own text. As a result, you will receive a nicely formatted social media post.

You are welcome to share every new badge you receive this way!

Also, on LinkedIn, there is a cool way to have the badges in your profile like this:

Just go to Edit profile -> Featured -> Add link

2. Reserve your spot on the Azure Heroes Community map

By default, your badge is completely anonymous and it's up to you to publicize it to the global developer community. And we have a solution for this!

Just go to the Azure Heroes Community website and associate your Twitter or LinkedIn profile with your badges (these is a simple and quick process for it). Once you've completed this, your name will appear on this website, linked to your country of residence.

Of course, you can remove this connection, and thus remove your profile from the Azure Community website, at any time.

3. Ask your employer if your company participates in the "Azure Heroes for Enterprise" program

For company-internal skilling and educational events related to Azure, we have a special offering called "Azure Heroes for Enterprise" with a special Azure Polymath badger. Do you want to delight your colleagues by providing them with Azure Heroes badges? Just ask the person who drives this internal motion to contact us at ahhelp@microsoft.com, and we'll come to your company's internal events to share the badges.

4. Collect more badges & badges of different types...

...and follow the updates on the Azure Heroes Twitter account or updates from your employer if your company is a part of "Azure Heroes for Enterprise". Soon we will start sharing some cool giveaways that you can get in exchange for some of your digital badges (exact rules are defined on a case-by-case basis). It's always great to have something "real" in addition to the digital badge, isn't it?

5. Received a badge as a student and your university has some courses about cloud technology?

We have a program called "Azure Heroes for University" where we distribute digital badges for the students attending these courses. Please, introduce your teacher to us by sending an email to ahhelp@microsoft.com, and we'll pick up the conversation.

Do you know more ways to benefit from Azure Heroes badges?

Please, share your ideas with us! We are eager to hear from you and reward the best suggestions :)

--
Yours, Azure Heroes team (Sherry, Maxim, Nick)

We celebrate Hacktoberfest by introducing OpenSourcer badge of Azure Heroes program

Maxim Salnikov — Thu, 01 Oct 2020 14:44:52 +0000

Today, at CONTRIBUTING.md, we announced the new addition to our #azureheroes family: The OpenSourcer badge!

👉 OpenSourcer badgers recognize those who help build a robust OSS environment, with impactful technology and a collaborative, engaged community. OpenSourcers build, maintain, and make meaningful contributions to open source projects, while inspiring others to be part of the OSS movement.

To qualify, you must:

Be a creator, maintainer or contributor to an impactful (in your own definition) open-source software project.
And react to contributors' questions and requests in Issues and Pull Requests, in a way that people with all levels of the technical experise feel welcomed in your code repository.
Optionally, introduce OSS by speaking, blogging and other public activities.

💻 Are you all about contributing to #OSS success? This is the right badge for you then! Nominate yourself or your colleague or friend!

Meet a new Green Contributor badge!

Maxim Salnikov — Wed, 30 Sep 2020 20:30:16 +0000

Today, at GreenConf 💚, we announced the new addition to our #azureheroes family: The Green Contributor 🌱

👉 Green developers contribute to the growth of the sustainable software engineering field. Recipients of this badge drive innovation by building sustainable software and help educate the community by creating content and resources related to sustainable software engineering.

To qualify, you must verify at least one of the impacts in any of the bullets below.

Creator or maintainer or core contributor to an open-source software project with a focus on sustainable software.
Created several pieces of content for blogs, webinars, podcasts, or talks related to sustainable software.
Created tutorials, how-to guides, or sample code related to the field of sustainable software engineering.

💻 Are you all about #sustainable software engineering? This is the right badge for you then! Nominate yourself or your colleague or friend!

My developer journey, and today's aspirations. Interview for Kode24.

Maxim Salnikov — Thu, 25 Jun 2020 07:51:09 +0000

I'm proud to be featured as a Week's Coder of the Norwegian online-magazine for the developers Kode24. Here is the English version of the interview I gave to Ole Petter Baugerød Stokke (Editor at Kode24) for the publication.

Quick facts

Name: Maxim Salnikov
Age: 40
Education: Master's degree in Software of computing technique and automated systems at Volga State University of Telecommunications and Informatics
Location: Oslo, Norway
Job title and employer: Developer Engagement Lead at Microsoft Norway
Experience as a professional developer: 20+ years
Your setup (what kind of machine, OS, editor, etc. you are using): Microsoft Surface Book 2 + VS Code + Visual Studio Codespaces
Favorite music right now: Røyksopp
Favorite TV-series right now: Discovery Channel

Social media

Twitter: https://twitter.com/webmaxru
LinkedIn: https://linkedin.com/in/webmax
Speaker profile: https://sessionize.com/maxim-salnikov

Me attending CES expo in Las Vegas

How did you get started with coding? (for example, what is the first thing you remember developing, and where did the road go?)

I believe it's a classic story of the computer geek. I understood that programming is "my thing" during the first lessons of Basic in the school - I was especially excited by the programmatic drawing of the objects. Then I was deeply engaged with Pascal/Delphi (C++ to a lesser extent) in the University (again, in different v-teams I was always responsible for the visual and UI parts of the project). So it was natural for me to immediately become a "webmaster" in the late 90s when I discovered Internet: HTML, CSS, and obligatory JS-powered animated mouse pointer tail :) Approximately at the same time, I built my first commercial projects driven by Apache+PHP+MySQL (LAMP stack).

My developer career was always connected with the Internet and UI: I spent many years by developing SaaS e-commerce solutions as a Frontend Lead, then migrated legacy Win32 solution to the web stack using Angular as a Senior Developer, and ended up as a Fullstack Developer for the digital identity company by building end-to-end PoCs where IoT sensors sent data to the web UIs in the realtime.

After moving to Norway in 2011, I discovered a meetups scene. I started to visit the events, then to help organizers, then to build userg roups and run events myself. A bit later, I started my technical speaker journey and now I deliver around 30 technical sessions per year. Then, based on the experience I gathered by running meetups and attending events as a speaker, after finding soulmates to build the teams, I co-founded two full-scale developer conferences: Mobile Era (HQ: Norway, topics: mobile development in the broadest sense) and ngVikings (HQ: Nordics, topics: Angular framework). With all these community-focused activities gradually appeared in my life...

What are you working on normally, and what are you working on right now? (what product with which technologies, etc.)

...In March 2019, I naturally shifted my career gearbox to the Developer Relations with the focus on Azure cloud (before that official move, running developer communities and conferences, technical speaking and blogging were my fulltime hobby). So when the time comes to write the code, I mainly do it for the different web and cloud use cases to support my technical demos, talks, training.

For example, an Angular app to showcase Azure Static Web App service during my live demo at NDC Oslo 2020. Or my blog to show cloud deployment of a statically generated Angular/Scully app. By the way, the English version of this interview is hosted on this blog and there is a new automatic build on every push of the corresponding markdown file.

Also, I traditionally build and support the websites for the conferences I mentioned: Mobile Era 2016-2020, ngVikings 2017-2020. For the recent editions of these, I use Hugo static site generator. Another recent mini-project: I built an Azure Function using NodeJS to generate a digital badge for every attendee of ngVikings 2020 (I believe I suddenly invented such a thing as badges for the online conferences!) and put it on the webhook of our ticketing system. Folks loved to get a badge right after the ticket registration! On the day of the event, Twitter was full of these pictures shared :)

Right now, I work on the demo of the background services of Progressive Web Apps for my next technical talk.

Delivering a technical session from home

What does a typical workday look like to you “these days”? (are you at the home office, how do regular meetings, work tasks, etc. work)

My work is all about building the strategy and communication. So only the target channel and media changed but not the core. Now, I have meetings with my colleagues, with the local and global community organizers, with the developers who want to learn more about the cloud - from my kitchen or terrace. From the same places, I speak at the conferences worldwide these days - I think the number of my speaker appearances has only increased last months!

What would you like to learn more about in the future? (for example, new technologies you are curious about, languages you want to try, new disciplines you want to test, etc.)

My developer's passion is Web and Progressive Web Apps in particular. I scrupulously follow all the updates in this area, and there are always many things I want to learn and experiment with, for example, early drafts and Trial Origins of Web Capabilities APIs. Also, after Flutter for Web release, I want to try this framework and Dart language which drives it.

What specific tools can't you do without? (for example, specific programs and editors, editor plugins, build tools, database solutions, hosting services, etc.)

VS Code + Azure cloud extensions + "must-have" developer extensions like Prettier, Live Server, Import Cost, Peacock.

In the studio: recording videoshow for the developers

What is the worst thing you can be asked about at work? (for example, tasks you think are tedious, systems you don't like to work on, technologies you think are bad / difficult / tedious, etc.)

Not at work, but from my conference co-organizers: "the website shows older version, we need to fix it asap!" (that means I made something wrong again in my "genius" but quite an experimental Service Worker and have to revert it back, which is a challenge in this scenario :)

What do you think Norwegian developers should be better at?

Developers in Norway are very strong professionals, and I'd like them to share their knowledge and experience more often at the community events. As a meetup organizer, I always look for the speakers, and sometimes it's a challenge to find local folks. Now, with all the gatherings went online, it became simpler to invite speakers from other countries but I want to grow vivid technical speaker community in Norway.

What do you like to do when you're not working? (do you develop something in your spare time, also? hobbies?)

Besides running community meetups and developer conferences in my free time, I love traveling (now within Norway), alpine skiing, and producing music using my synth.

Let's stay connected

I'll be happy to hear from you. Feel free to send me a couple of lines if you:

Want to know more about the developer community in Norway
Need advice on your technical speaker or community organizer journey
Have technical questions about PWA, Angular, Azure
Want to invite me to speak at your technical event
Wish to learn more about cloud technologies from Microsoft

The easiest way to reach out to me is to send a direct message on Twitter or LinkedIn.

Inspiring Stories: Benedicte Raae

Maxim Salnikov — Wed, 15 Apr 2020 13:12:54 +0000

As a society, we tend to focus on titles and roles, and we forget that behind each title there is a person who has a story to tell. And truly every person’s story is unique.
In honor of International Women's day, we interview inspiring women from the community on the story of how they got into Tech, and where they are today.

In this post, I interview Benedicte Raae, who is based in Oslo, Norway.

Meet Benedicte

I’m Benedicte of Lilly Labs. I’m a computer scientist living in Oslo, Norway and have been an independent software engineer for almost a decade. I have clients in both the private and public sector in Norway and also a few international clients.

I love to create robust, user-friendly tools using web technology. My current favorite is Gatsby, a React framework.

Right now, I’m developing a privacy-first period tracker called POW! launched March 8th. The level of detail I found in existing apps made me less inclined to use them; it felt creepy, a little invasive even. And last year, the feeling was backed up by reports that several of the most popular tracker apps were selling or sharing data they collected with third parties such as Facebook.

So I spent 2019 answering the question: “A privacy first-period tracker? Is it even possible?” It led me to learn about encryption in web applications and to share my new-found knowledge at JavaZone, Mobile Era, JSConf Budapest, and RuhrJS. 

I also realized I just had to make a pass at making one. In addition to keeping your privacy safe, I hope to also give the control back to the user. POW! leverages hashtags to let you track the things you are interested in using a language you are familiar with.

Twitter: @raae
Instagram: @raae.codes

When did you first become interested in technology and what sparked this interest?

My mother is a mechanical engineer but worked as a developer for most of her career, before transitioning to a managerial role. This gave me early access to computers. I remember us connecting to the Internet over a noisy modem, while I was still in elementary school, only to check vg.no and waiting forever for it to appear. I was not very impressed.

However, at 13, my Norwegian teacher introduced me to HTML and CSS. Also, the Internet had become a lot more fun. At 16, I was responsible for Foss revyen’s first website and needed JavaScript to create an image carousel. I have never spelled height wrong again after spending hours debugging the code.

I am more interested in what we can create with technology than the technology itself. And lately I've been even more interested in what we probably should not make, even though we could.

What education do you have?

Master of Technology, Computer Science, from NTNU (Norwegian University of Science and Technology).

Describe your way towards your first job in tech; how did you land this job?

I was a summer intern at Iterate and after finishing that and graduating in 2009, they offered me a job. At that time, this situation was typical for most of my class.

Do you have any role models that influenced you?

My mother, and the other ladies working with her. They normalized the whole “women in tech thing” to such a degree that it took me years to realize others had questioned their right to be here much more than I've ever had.

My grandmother, co-founder of Kronborg Leverpostei and women’s rightist activist who was a force to be reckoned with until the end. Both my daughter (Lillian) and my company (Lilly Labs) are named after her.

David Heinemeier Hansson, founder of Basecamp, who has created a thriving tech business focusing on paying customers and is taking a stand against surveillance marketing.

And many, many more.

Who were/are the biggest supporters in your career?

My partner Ola and my good friend and cheerleader Marit Letnes!

I also find support in the Slow Business Community (led by Torill Bye Wilhelmsen), where the focus is on building businesses we enjoy, while running them. This as opposed to the hustle, hustle, hustle, and then flip mentality prevalent in tech.

Tell us more about your current job – e.g. what do you like most about your role?

I really enjoy and need the freedom of being an independent developer!

At the moment, I split my time between POW! and an engagement creating a web application, in React, for a Scandinavian defense force. 

I often work long term, but not full time for my clients. It’s a win-win; I keep the outside perspective that clients often need, while being a stable resource on their projects.

What does your typical day look like?

I take our daughter to kindergarten, then head to a coffee shop to work remotely or go to the city center to work at my current client’s office. I try to, and most often do, get several hours of uninterrupted time to code, giving me that sweet flow feeling.

What do you do in your free time?

Being independent, there is not as hard a line between work and free time. 

I love to code, and you can find me spending an evening at the local café coding on something fun, like POW! while enjoying a glass of wine. But you can also find me mid-week taking a break from everything just reading a book.

However, I have started horseback riding again after 20 years, and it’s a blast: “Hest er fortsatt best.” 

What advice will you give to women and girls who dream about a career in tech?

Do it, join me, you belong!  

Inspiring Stories: Monica Beate Tvedt

Maxim Salnikov — Sun, 15 Mar 2020 10:56:29 +0000

In this post, I interview Monica Beate Tvedt, who is based in Oslo, Norway.

Meet Monica

My name is Monica Beate Tvedt, Head of .NET Development at Sopra Steria, entering a new role as Partner & Director of Technology. I'm also the owner of the Scandinavian Microsoft Developer Community at Sopra Steria and organizer of Oslo Xamarin Meetup. 

I was a keynote speaker at this year's Women in Tech Summit, where I talked about my journey from being a single mom with no education, to where I am today, a hands-on technology director, doing what I love - trying to encourage more women into tech.

As programming is my greatest passion, I strive to contribute back to the development community by giving tech talks and hands-on workshops. Next up is the Global AI on Tour 2020 the 4th of April at Microsoft Oslo, where we will teach you more about Azure's AI and Machine learning services.

Twitter: @monicatvedt
Facebook: Monica Beate Tvedt
LinkedIn: Monica Beate Tvedt

When did you first become interested in technology and what sparked this interest?

I’ve always been very visual. Growing up, I loved solving number-, pattern- and logical problems, at the same time spending a lot of time drawing cartoon characters, as I was fascinated by Walt Disney and how they drew each frame to animate a given gesture.

Being a kid from the 80s, I also play a lot of video games (Atari, Nintendo), again fascinated by the animation, the logic, and graphics used. When we then got our first computer it was only a matter of time before I created my first website showcasing my drawing and animation skills. Programming enabled me to do what I loved the most, solving both logical problems and being creative in designing user interfaces. There’s really nothing quite like it...

What education do you have?

Computer Engineering - Software development.

Describe your way towards your first job in tech; how did you land this job?

I started out as a freelancer in 2001 before I took my engineering degree. I created websites for family and friends, and asked local companies if they needed help going digital. It was literally a door-to-door job, often being rejected, but every time I didn't, I made sure my work was added to my online portfolio, building my brand.

I then started volunteering as a teacher assistant in multiple engineering subjects and one day I was asked to do an interview for a school paper where I talked about my passion for software development. I did the interview and later I got a phone call from a company who had read my story, asking if I would come work for them. Which I did.

This is why I cannot stress enough the importance of showcasing your work and your passions, as this has been the recipe for almost every one of my job offers ever since.

Do you have any role models that influenced you?

Bill Gates and Warren Buffet. I loved them when I was growing up - their mindset, their business acumen and what they achieved. I was, and still am, in absolute awe of their accomplishments...

Who were/are the biggest supporters in your career?

It has been a somewhat lonely journey, being a woman in the tech industry. But time has changed and today I’m very thankful for the enormous support I get from the Oslo tech community, and the people I work with day to day. 

I would especially like to mention Eirik Lie, Kjetil Kværne, and Hilde Solberg Holm, who have all made their impact and let their support be known, each in their own way. They're hard-working and talented individuals, bringing out the best in others - it really is all about having the right mindset!

My two beautiful children have also been a huge motivation, making me work even harder trying to achieve my goals.

What does your typical day look like?

Lately, I’ve been working on a project for Kværner, where we developed a new mobile app at the same time as running our .NET departments at Sopra Steria. 

A typical day running our .NET departments will start with me checking our department's current productive billable rate, noting any planned deviations preparing for next month's business review, going through our department's profit and loss.

Then off to meetings about the relocation of resources, bids, and new leads. Throughout the day I follow up with my consultants, making sure they thrive at work, answering any questions they may have. Depending on my main focus of the day, I’m spending the rest of the day either planning our next community meetup with our community leads, preparing slides for a department meeting, taking actions on my department's current strategy, interviewing .NET developers or advising our customers on what to do next. 

When working as a developer at Kværner, the day is quite different, starting with us fetching a cup of coffee or opening a can of Monster Energy, catching up during our daily stand-up and then just enjoying ourselves coding all day, making awesome apps. Working Lean in autonomous teams using Azure DevOps, building our apps using .NET Core, Xamarin and Azure, all while getting continuous feedback from our pilot users.

What do you do in your free time?

I’ll proudly admit I’m mostly at my computer: programming, learning new things or playing chess at chess.com, often simultaneously while watching a movie. There is no shortcut in this business, so you need to put in the hours and most importantly not feel guilty for doing so or feel the need to apologize for it. Do what you love and do more of it. When my laptop finally runs out of battery - it may happen - I enjoy playing tennis, eating out or going skiing.

What advice will you give to women and girls who dream about a career in tech?

Start building your brand today. Document your journey both for your own motivation and for future employers to see. Do more volunteering work for the Tech community and say yes more often, but only if it will add real value to your CV. If you get an opportunity but you’re not sure how or if you can do it, say yes. You will learn as you go, but the opportunity may not come again.

Remember that you have all the cards, so try to play them well. There are too few software developers out there so the world is yours if you take the time and effort to become really good at it. 

There are not that many women in Tech, so if you are ever in the need of advice, are stuck programming a school assignment or at work, just give me a shout on SoMe and we’ll try to solve it together. I would love to help in any way I can, so do not hesitate to reach out! 

Inspiring Stories: Kristina Simakova

Maxim Salnikov — Tue, 10 Mar 2020 10:03:21 +0000

As a society we tend to focus on titles and roles, and we forget that behind each title there is a person who has a story to tell. And truly every person’s story is unique.
In honor of International Women's day, we interview inspiring women from the community on the story of how they got into Tech, and where they are today.

In this post, I interview Kristina Simakova who is based in Oslo, Norway.

Meet Kristina

Kristina is an independent IT consultant based in Norway. She is a Google Developer Expert for Android & Maps and has a keen interest in AR, ML and computer graphics. By day, she writes Android native code in Kotlin and by night, she blogs at creativetech.blog about AR and helps organise GDG Oslo events and support the Women in Tech Oslo community.

Twitter: @KristiSimakova
Facebook: Kristina Simakova

When did you first become interested in technology and what sparked this interest?

I was always interested in technology in general and I got interested in programming during my bachelor study in a computer graphics course.

What education do you have?

Master of Science - Computer Engineering

Describe your way towards your first job in tech; how did you land this job?

I have a major in Computer Graphics and after finishing my masters I was looking forward to working in this field. I applied for a few positions and there was one that I really liked where I would work with creating ship and crane simulators for training. Fortunately, the company gave me the offer.

Do you have any role models that influenced you?

There are a lot of people that influenced me throughout my life: from my math teacher to the founder of my previous company. From the people everyone knows, I want to mention Richard Branson. His spirit and adventures inspire me.

Who were/are your biggest supporters in your career?

My mother is my biggest supporter of all.

Tell us more about your current job– e.g. what do you like most about your role?

I am an independent consultant focusing mainly on Android development. I usually join an existing team of developers for 6 months or a longer period of time. I am currently working for a Norwegian mobile payment company.

What does your typical day look like?

On a typical day I would be at my customer's office. As a part of the project, I help develop Android applications. In the morning, we have a short team meeting and occasionally other meetings during the day. I use most of my time writing code in Kotlin.

What do you do in your free time?

I enjoy traveling and walking around in a new city. I like cooking Asian cuisine and making gluten-free desserts, which helps me clear my thoughts.

What advice will you give to women and girls who dream about a career in tech?

Start with building small projects that you would use yourself and keep learning.

Inspiring Stories: Victoria Bergquist

Maxim Salnikov — Sun, 08 Mar 2020 13:31:39 +0000

In this post, I interview Victoria Bergquist who is based in Oslo, Norway.

Meet Victoria

My name is Victoria and I'm a Frontend Engineer at Sanity.io. I'm from Oslo, Norway, but only recently moved back to Norway after living abroad for almost 8 years. Alongside work I enjoy being a part of the developer community through Twitter, meetups, events, and conferences. While I'm actually an introvert and often prefer to spend time at home, I find it very rewarding to organise events and spend time helping others around me. That is why I started two meetups in Frankfurt, organise and speak at events and conferences, and volunteer as a Chapter Leader for Vue Vixens, an organisation dedicated to helping women and those who identify as women learn Vue.js.

GitHub: @vicbergquist
Twitter: @vicbergquist
CodePen: @vicbergquist

When did you first become interested in technology and what sparked this interest?

In high school I chose to do vocational studies in media and communication, with classes in design history, advertisement, journalism, photography, and more. We had to keep a blog/portfolio for a lot of our assignments and homework, and that's how I was first introduced to web technology. I struggled a lot to find a theme for my portfolio and blog, so I started looking into the code just for fun. HTML and CSS weren’t completely new to me, because my friend was taking a web design class and had been showing me what they were doing. However, I thought it sounded kind of boring, and instead learned a little about HTML and CSS on my own to customise the theme for my blog/portfolio. I had so much fun doing this and was at it for hours several times a week, but after spending a year in Japan and switching to general studies when I was back in high school in Norway, I went on to study languages and linguistics at university in Australia. I completely stopped coding and didn't touch or think about it for almost 7 years, before I got back to it after finishing university and needed to figure out what to do next!

What education do you have?

I have a Bachelor of Arts with majors in Japanese and German, and electives in linguistics, neuroscience and psychology from The University of Queensland in Brisbane, Australia.

Describe your way towards your first job in tech; how did you land this job?

I was very happy with my studies and had a great time at university, but had no idea what to do after I graduated, so I tried a few different things. I went to Design School, but dropped out because it was too expensive. Then, because of my interest in coding from high school and languages, I started a Master's Degree in Linguistics and Web Technology. However, I dropped out before the first semester ended. The university just wasn't the right fit for me, so instead I decided to continue learning how to code on my own. I started spending all my time learning web development by completing various projects on freeCodeCamp and getting really into CSS. Eventually I also joined Twitter and began the #100DaysOfCode challenge to accelerate my progress, and began to code every day.

During this time, I was putting in a lot of hard work and applied to various junior roles, but kept getting rejected because of my lack of experience and untraditional background. This was very discouraging, but then out of the blue a company contacted me about a frontend developer role they were hiring for. Apparently they had found me on Stack Overflow and had seen my CSS work on CodePen! I managed to find the job ad they contacted me about and it said that they were looking for a JavaScript developer, which was disappointing. I didn’t want to do JavaScript, so I emailed them back and said I wasn’t interested. I was having so much fun with CSS and instead wanted a job where I could do that. Lucky for me, they told me to disregard the job ad and simply wanted to talk to get to know me.

I ended up meeting them a week or two later, and the interview lasted quite a while. They wanted me to share my story and what I was passionate about, and said they wanted to hire their first frontend developer with a passion for the craft. Despite my lack of experience, they admired the progress I had made in such a short amount of time and how excited I got when talking about CSS. The day after, on day 87 of #100DaysOfCode, they called me back and offered me the job. Despite having no professional experience, they said they knew I would learn what I needed to learn on the job and thought I'd be a great addition to the team! So I become their first frontend developer, a junior and a lead!

Tell us more about your current job– e.g. what do you like most about your role?

Where to start! I'm really excited about all the things I get to do at Sanity, like building APIs, tooling and working on Sanity Studio, an open-source content editing environment. I also love the fact that I’m able to continuously learn and explore new technologies. Sanity is used as a content backend for so many fun and interesting projects both by us internally and the community, like real-time quizzes and voice assistants, so seeing these things that people make with the product that I'm working on everyday is incredibly motivating and inspiring. It makes it so much fun to go to work!

What does your typical day look like?

My cat usually wakes me up by walking all over my face between 4 and 7 AM, and if that doesn't happen, my other cat wakes me up around the same time singing the song of her people, until someone goes to cuddle her. I quite enjoy being at the office around 8, but I often only go in around lunch in order to spend time with my cats before a day at the office. When at work I enjoy spending time talking with my colleagues. Everyone enjoys sharing what they are working on and the challenges they are facing, which almost makes you feel a part of all the projects at once, and that inspires me every day. In between work, we also play foosball to relax and have fun. I'm currently losing a lot, so I'm playing less than normal these days!

On a typical day I also do a lot of pair-programming with my project partners. Parts of our code base are still very unfamiliar to me, so working closely with someone who knows it better may be the favourite part of my day. Other than that, I also have a few meetings, often with people in San Francisco, before I head home for the day around 4 or 5 PM. But I also often forget to go home when I should, because I'm having such a good time at the office!

What do you do in your free time?

I code more than I should! I enjoy my job, so I struggle to put it away. To distract myself I like to watch TV shows, cook or bake, hang out with my cats, and play board games. Right now I'm doing clicker training with one of my cats, and try my best to stay away from coding and social media for my health and to do things I enjoy. I also organise meetups, however due to moving and health reasons, I haven't been able to do it as much as I'd like, but I'm really excited about starting it again soon!

What advice will you give to women and girls who dream about a career in tech?

There are so many ways into this industry. Don't let anyone tell you that you need to follow one specific one, or that you can't do it with the background you have. Your are what the industry needs in order to be the best it can be, whether that's with a CS degree, or not.
There's no doubt that being a woman in tech is hard, but women from your area and all around the world are there to help you on your journey. To find them, join communities for women in tech, local ones or online. I've met so many incredible women this way, and they have helped me get to where I am today.

Workbox 4: Implementing refresh-to-update-version flow using the workbox-window module

Maxim Salnikov — Thu, 28 Feb 2019 01:21:48 +0000

The next major version of the very popular PWA helper library was just released. Workbox 4 brings many interesting additions to the existing modules and only a few minor breaking changes. Also, it ships one totally new module called workbox-window, to fulfil the need of developers in a simple and powerful way to register the service worker, to hook into its lifecycle, and to provide a bi-directional communication channel with the app. This is the first module of Workbox to be used in the window context, i.e. in our application’s (not service worker’s) code.

Let’s explore this new module to check what will it take to build the well-known “refresh-to-update-version” technique — one of the UX best practice for PWA. As we use this flow often while building our applications, and Workbox exposes the corresponding tooling now, we just need to find a simple and robust code to build that flow. This article is my try to find that code: minimal and stable. But first, what is this flow I’m talking about?

Refresh-to-update-version 101

You open some website. And after a couple of seconds, it shows you some prompt/dialogue saying “A new version of this website is available. [Refresh the page to get it]”. In most cases that means:

This is a service worker-driven origin (if it also has Web App Manifest we can call it PWA), and the UI you see was not fetched from the network but was taken from the Cache Storage of your browser
You visited this website using this browser some time ago
Between the previous and current visit, the deployed version was updated

The dialogue you see is a sort of trade-off between the possibility to show app UI immediately, without fetching it from the network (using precached version) and the need to deliver the actual version of the app to the user after all. Where is the compromise then? It’s in the fact that we still load the precached (“old”) version of the app from Cache Storage, but if the service worker knows that there is a new version available, it fetches the updated resources, updates cache and sends a message (using Broadcast Channel API or postMessage) to the app. Where we catch this message and show the notorious “The app was updated. Click refresh to upload” message to the user. Next page load — and we serve the “new” version from Cache Storage (of course, if our service worker performed all the listed above operations in a proper way).

Another variation of this technique — we do not send any signal from service worker but listen to the changes of its lifecycle in our app. For our case, the combination of onupdatefound and onstatechange events caused by the fetching of byte-different service worker could mean the change of hash sums of the resource(s) mentioned in “to precache” list injected in service worker. Which, in its turn, means that the new version of the app was built — so we can safely show “The app was updated” message.

Workbox v3 options to have refresh-to-update-version flow

First, let’s say thanks to the Workbox maintainers for the magic precacheAndRoute() method we could use in our own service worker. This method takes care of all the complexity of precaching, version maintaining, fetching updated resources, updating the cache etc. We just pass the object with resources and their hash sums (built by another helper from Workbox family — workbox-build module) and it works. Furthermore, another line of code in the service worker:

…and we can receive the signals about the precached resources were updated in our app code — exactly what we need to show the message to our user:

We can even add the same plugin to the resources we cache during runtime to follow their updates if needed.

Why do I tell about the option we use in Workbox 3 in the article about Workbox 4? Because it still works fine — your code from v3 related to this flow will not break.

What about the second option — when we rely on the service worker lifecycle events? In v3 we don’t have any helpers to actually register our Workbox-driven service worker in our app code and subscribe to its events. Of course, we always can write this ourselves or use the really nice register-service-worker library by Evan You, then the code in our app could look like:

But now we have way more powerful, flexible and truly Workbox-native way to achieve it: workbox-window module. As stated in the documentation, The key features/goals of this module are:

To simplify the process of service worker registration and updates by helping developers identify the most critical moments in the service worker lifecycle, and making it easier to respond to those moments.

To help prevent developers from making the most common mistakes.

To enable easier communication between code running in the service worker and code running in the window.

Let’s implement the above UX trick using this module.

The refresh-to-update-version flow powered by workbox-build

Let’s start at the very beginning. To demo the flow, we need to implement a service worker with precaching and serving the resources forming our application shell.

The minimalistic version of the Workbox-powered service worker source file could look like:

Lines 8 and 9 are important in the context of this article. You will read later why do we need them

Why is this “source file”? Because we have to process it after every build of our application. To be precise — we have to inject the list of resources to precache and their hash sums as a parameter for precacheAndRoute() method (instead of this empty array). To save us from this boring task Workbox has 3 options to choose from: Workbox CLI, Webpack plugin, and Node module. The last one is my choice: it needs neither globally installed CLI nor Webpack configuration file exposed. Installing the workbox-build module:

npm install workbox-build --save-dev

Now the service worker build script:

And the final part — is to add the npm run script combining the build of our app and service worker, one after another:

As you might notice, I use an Angular app in my example (ng build --prod is a build command for it) but everything I describe in that article about Workbox modules and PWA techniques is applicable to any JavaScript application.

After I do npm run build-pwa I see something like

Generated dist/angular-pwa/service-worker.js, which will precache 6 files, totaling 735289 bytes.

And the service worker in the distribution folder now contains all the info Workbox needs to know about our app:

It would be the same in Workbox 3. But now the difference starts: let’s register this service worker in our app using workbox-window. Installing the module first:

npm install workbox-window

Hint: there are different scenarios of importing/using/bundling this module available.

Now in our application code:

Some important things to notice:

There is no service worker feature detection in register() method, so don’t forget to have this in your code (line 3). At the same time, the delaying of the registration until the window.onload event is included, so we don’t have to add this extra wrapper.
Where exactly to put this code in your app? The later — the better. Have it after your app was fully rendered for service worker not to compete with the main thread for the network and CPU resources. For Angular apps, the best place will be in then() block after bootstrapModule() call in main.ts file.

Time to run our app in any static http server. I use serve:

Running the PWA

This is exactly what we expect: the service worker was registered, some files were precached. Now if you shut down the server or check Offline checkbox in DevTools — the app will still be available. Thanks to our Workbox-powered service worker serving the resources from the Cache Storage.

Hint: to have much more detailed log just set the corresponding logging level in DevTools — see the Default levels dropdown in the right bottom corner of the screenshot.

It’s time to update something in our app. Let’s change the title to Angular PWA 6. Build/deploy/serve/refresh the page: you still see Angular PWA 5. Hit browser’s refresh button once again — now you see the new title. This was expected and our goal is to give the user a hint that the app was actually updated while they see the older version. One of the listeners exposed by workbox-window called installed will help!

Now on every application update, we’ll see the prompt:

Refresh-to-update-version

Some notices:

We have an extra condition in the code — event.isUpdate. It’s there because we don’t want to show this message on the very first service worker installation, only on the updated. The inversion of this condition is a good option to show a message like “This app is now ready for the offline usage”
The described approach works ONLY if we are good with modifying the service worker lifecycle by skipping the waiting phase (see lines 8 and 9 in our service worker code). Without this modification the new service worker will not be activated until the user closes all the open tabs with this app — as a result, they will see the old version until that. If for some reason skipping activation step is not an option for your project — please use more general (and more complex) option mentioned in the documentation.
Please, don’t use JavaScript’s confirm() method in production :) It’s in the sample code only for simplicity. Use the less obtrusive and non-blocking toast/snackbar from the UI library you use for your application.

Awesome! Now we have pretty laconic code helping us to register service worker and catch the proper moment when to show the message about a new version is available.

Of course, workbox-window has lots of other useful events helping us to have full control over the service workers: both “internal” (registered by workbox-window) and “external” — all others, for example from some 3rd party services providing Push-notifications. Also, it gives a convenient option to communicate with the service worker which will be extended and standardized by the release of the workbox-messages module.

To sum up:

Workbox 4 was released — production-ready library for the PWA’s main network tasks automation
The new module workbox-window gives developers a convenient way to register service worker and listen to the events of its lifecycle
We discovered the proper event to react on for showing the message to the user for the refresh-to-update-version flow

So, let’s try the brand new Workbox 4 and its workbox-window module! If you find any issues, please report. If you wish to know all the latest news about Workbox and PWA in general, please follow me on Twitter webmaxru and join PWA Slack team. My direct messages are always open for your technical questions and invitations to speak about PWA/Workbox at your conference or hold a PWA workshop for your conference/company.