Forem: Kate

It depends! Exploring my favourite Renovate features for dependency updates

Kate — Sun, 18 Jun 2023 13:06:56 +0000

I learned about Renovate a couple of years ago when I was trying to group automated updates in Dependabot. It's 2023, and Dependabot is still figuring out how to implement grouping. Not blaming them; dependency updates are challenging. Regardless of the approach you take, a fair amount of work is required to set up tools and processes for dependency management. In this post, I have collected a few of my favourite features and tricks when working with Renovate. Have I missed anything? Of course! Renovate is highly configurable (and well-documented), so if you need the full guide, please consult the official docs.

How Renovate works

Before delving into the details, let's ask ChatGPT for a quick summary of how Renovate works:

Renovate is an open-source tool designed to automate the process of updating dependencies in a project. It works by identifying relevant package files within a codebase (including monorepos), then generating and scheduling pull requests to update those dependencies and their associated lock files. Users have the ability to customise the behaviour of the Renovate bot through configuration files and share configurations using ESLint-like presets.

The easiest way to get started with Renovate is to install it in your repo as a GitHub App:

Renovate will automatically open a "Configure Renovate" PR with meaningful defaults. Once the config file is merged, Renovate will start opening regular pull requests with dependency updates. In theory, that's it. In practice, you'll likely want to tweak the configuration and fine-tune it to suit your specific needs and preferences.

Feature 1: config presets

Renovate supports hundreds of configuration options, or at least it feels that way. The resulting configuration file, even for a simple app, can end up being huge and cryptic. Fortunately, Renovate provides config presets that allow you to abstract away the details and share config pieces across multiple projects.

One crucial config preset to be aware of is config:base. It enables core Renovate features such as the Dependency Dashboard and monorepo grouping (more on this later in the article). It's a good idea to base your configuration on config:base or, in the case of JavaScript projects, on the config:js-app or config:js-lib presets.

Here is an example configuration for my personal blog powered by Gatsby:

{
  $schema: "https://docs.renovatebot.com/renovate-schema.json", // up to date schema with all supported properties
  extends: [
    "config:js-app",       // base on the recommended config for JS applications
    "schedule:monthly",    // can be schedule:weekly, schedule:weekends, etc
    "npm:unpublishSafe",   // the release must be at least 3 days old
    ":approveMajorUpdates",// require explicit update approval on the dashboard before opening PR
    ":maintainLockFilesWeekly" // regenerates lock file to update all indirect deps

  ],
  transitiveRemediation: true // apply security updates for indirect (transitive) NPM dependencies 
}

As it's a JavaScript project, I used the config:js-app preset. I configured the update schedule, enabled the minimum release days restriction, disabled automatic PRs for major updates, and enabled weekly lock file maintenance. All using the default config presets. Thanks to JSON5 support, I can add comments to my config!

If I have multiple projects similar to this one, I can convert my new configuration into a preset and refer to it in the config of the other projects:

{
  $schema: "https://docs.renovatebot.com/renovate-schema.json",
  extends: [
    "github>kalabro/kalabro.tech//renovate/js-app", // loads my base config from another repo
  ],
  // Further extending config for this specific project
  postUpdateOptions: ["yarnDedupeHighest"],
}

It assumes that my shareable config is available at https://github.com/kalabro/kalabro.tech/renovate/js-app.json. As you probably guessed, you can keep customising the final config using other presets or configuration options. For example, you may need to group (or exclude) certain dependencies to reduce update noise.

Feature 2: grouping related updates

My blog has 20 Gatsby-related dependencies (what a mess, but it's a topic for another blog post 😄). Updating them one by one is distracting and also likely to cause issues. What if we could ask Renovate to group all gatsby-* dependencies in one PR? No problem at all:

{
  "packageRules": [
    {
      "matchPackagePatterns": ["^gatsby"],
      "groupName": "Gatsby packages"
    }
  ]
}

packageRules is a cool and flexible config option for grouping Renovate updates. However, in my case, it's not even necessary! My default config already has built-in knowledge on how to group Gatsby dependencies, thanks to Renovate's base preset. It encompasses a wide range of curated package rules, especially for the Javascript ecosystem. Whether it's Angular, Vue, or anything in between, Renovate has you covered.

A few typical use cases for the packageRules configuration:

Separating dependencies and devDependencies. The latter is easier to automerge.
Modifying the update schedule for specific types or groups of updates.
Restricting updates for certain packages.

A word of caution. Although it may seem counterintuitive, I have found that smaller and more frequent updates tend to be more effective than large grouped PRs.

Feature 3: lock file updates

Renovate performs update checks for your direct dependencies, which are the ones listed in the package.json file. These direct dependencies can themselves have their own dependencies, which are known as indirect or transitive dependencies. Typical web projects often have much more transitive dependencies than direct ones. The easiest way to keep these dependencies up to date is by regularly refreshing the lock file. When you combine this approach with dependency pinning, lock file updates can be safely automated.

{
  $schema: "https://docs.renovatebot.com/renovate-schema.json",
  extends: [
    "config:js-app",  // pins dependencies in package.json file
    ":maintainLockFilesWeekly", // regenerates lock file to update all transitive deps 
  ]
}

If you prefer ranges ("^1.2.3") to pinning ("1.2.3"), lock file maintenance will update everything according to the ranges specified in your package.json. If this is what you are looking for, take a look at config:semverAllMonthly preset for inspiration.

Feature 4: Dependabot integration

Wait, what?

Yes, Renovate delegates vulnerability checks to Dependabot. When running on GitHub, Renovate checks Dependabot security alerts and immediately triggers the corresponding updates. To utilise this feature, you need to enable Dependabot alerts in your project settings.

A vulnerability remediation PR may appear as follows:

Of course, this feature is configurable via the vulnerabilityAlerts setting.

You can also override the prBodyTemplate setting to remove the Renovate banner at the top.

Feature 5: Dependency Dashboard

For quite a while, I thought Renovate was a typical CI tool without UI. Luckily, I was mistaken. Renovate comes with a Dependency Dashboard where you can find a summary of all opened and pending updates, as well as any configuration issues. Below is a screenshot of the Dependency Dashboard for this blog (don't worry about all the security issues, it's a static website):

Instead of jumping back and forth between different PRs and Renovate app logs, I can view and manage everything from one place. It's even more helpful when you're maintaining multiple repositories.

To summarise

If you're seeking an automated dependency management tool, I can confidently recommend Renovate. It's well-designed, flexible, and open source. After using it for over a year, I particularly enjoy some of its features, such as shareable configs and the Dependency Dashboard. However, be aware that the initial learning curve can be steep, especially if can't use the preconfigured GitHub app.

Are you using Renovate or any other dependency management tool? I'd love to know about your experience in the comments!

Budgeting my communication capacity

Kate — Sat, 03 Jun 2023 18:43:25 +0000

Spring 2023 was fun. After 7 years in one company, I started a new role in a very different type of business, with a very different tech stack. Bold move for me! The entire process from interviewing to signing an offer to opening my first PR in a new team took almost a year. Landing a job in tech is hard. "The system is broken" is a common phrase to hear when engineers of all seniority levels share their hiring experiences. Funny enough, my new job is to build products for recruiters. Let's see if I can help to "fix the system." I'll start by sharing some learnings from my recent job change project. And the first one is all about networking.

I'm an introvert. I enjoy the comfort and solitude of remote work with async communication. When I'm in the flow, I can solve a wide range of technical problems from backend to frontend, from planning to shipping, from enterprise to greenfield.

Out of 100%, 80% of my capacity is technical, and the remaining 20% is communication skills. However, those 20% were barely enough to support all of my technical work, especially when I started taking on more management responsibilities. I had ambition, and growing often meant management.

Introverts on the other side of the screen will understand that once you've spent all your communication budget, it's a hard stop. I had been working like this for years, not leaving any of my "extrovert" budget for the outer IT space.

As a result, when it was time to move on, I had very few useful connections and an outdated understanding of the IT recruitment market. I had to go through cold interviews with their live coding sessions, algorithmic problems, personality tests, and other humiliating experiences. Not fun at all.

The most popular advice I received during that period was to keep interviewing. I was told to schedule as many interviews as possible until I became comfortable with them. I was advised to stretch my 20% even further.

Today, I have a better advice for myself: budget your communication capacity to stay in sync with the IT reality.
This means reserving 5% of my extravert capacity for external activities and spending that 5% wisely. Booking every morning for yet another interview call is not wise at all.

While 5% may seem like a small number, there are many activities in IT that bring a lot of value with just a bit of communication effort. Let me share some concrete examples that have worked for me:

Meetups and conferences

I found my current employer on meetup.com. I have also built strong connections with people I met at meetups and conferences. For me, the best way to network at a conference is to give a talk. This way, people come to me with specific questions, and I don't need to worry about how to start a conversation. I can also build good relationships with other speakers by giving feedback and asking follow-up questions. Even if I don't create any meaningful connections, I go home inspired and motivated. Good enough for me.

Mentorship and coaching

I feel much more comfortable in deeper 1:1 conversations than in group activities with strangers. Mentorship sessions were the main source of energy for me in 2022. I spoke to engineers and leaders from various organisations, and everyone was very helpful and supportive. Today, I have a couple of trusted mentors, and offer engineering mentorships myself on ADPList. If you are new to mentorship read my post "Where to find a mentor" to get started.

Blogging

I created this little blog five years ago when I was playing with Gatsby during Christmas. Even with my occasional writing, it has become a great foundation for my public profile. As a bonus, it makes a positive first impression on recruiters. Writing skills are important in tech, as a lot of communication and knowledge sharing happens asynchronously.

Reading

Surprisingly, reading can be a decent networking tool. Writing a book review, giving a recommendation or participating in a book club - all of these activities can bring interesting people and ideas into my life. My "Learning Domain-Driven Design" book review is the most popular post on this blog to date.

Working from the office

To reserve some communication capacity for the activities mentioned above, I left behind my Tech Lead role and started as an individual contributor. However, as a Senior Engineer, I still have a lot of meetings to plan the work, pair on implementation, and stay up to date with the business in general. I was surprised to find out that all those activities drain me much less when I work from the office. Also, drawing on the whiteboard is a lot of fun!

Things that didn't work for me

I'm not the first to discover the difficulties with networking for less outgoing engineers, and I know there are many other ways to show up in the global IT community. Some of them didn't work for me (but they may work for you):

Dale Carnegie tricks
Not my thing, but I agree that learning some "tricks" can help in common situations, like starting a conversation with a stranger or having an argument with a colleague.

Online communities
There are many topic-specific channels in Slack, Reddit, Discord, Twitch, etc.

Open Source contributions
Early in my career, I was lucky to meet great people from the Drupal open-source community. They influenced my career more than anyone else. Participating in open source requires time and effort, and at some point I disengaged in favor of client work.

Freelance gigs
I know some very well-connected freelancers, but I'm not sure if my 5% communication budget will be enough to satisfy any client.

Building side projects
Building something public can be a great starting point for building connections with very interesting, well-connected people. Pretty much every indie developer I met was a very interesting person with multiple talents.

To summarise

As an introvert, I have a limited communication capacity that I refer to as my "extravert budget". In the past, I used to spend all of it at work, leaving nothing for other activities. My recent job change experience has made it clear to me that I need to budget my communication capacity wisely. Otherwise, I'm at risk of alienating from the global IT community.

Firstly, I gave up some of my management responsibilities and made it a habit to come to the office twice a week. Surprisingly, in-person meetings drain me much less compared to Zoom calls. Additionally, I began working with a mentor to enhance the efficiency of my communication.

By making these changes, I am now able to engage more with the global IT community and naturally expand my professional network. I have found several activities that work well for me, such as meetups, mentorship, and blogging.

I'd love to know what works for you, especially if you consider yourself a less outgoing person. Please, share your experience in comments below or contact me directly. Let's connect! 😄

Fast by default with Next.js

Kate — Tue, 21 Feb 2023 08:58:06 +0000

There is a famous quote from Donald Knuth that premature performance optimisation is the root of all evil. As usually happens with quotes, it was often taken out of context and amplified.

It’s 2023, and despite all the efforts, the web remains slow. Developers tend to blame frameworks, programming languages, browsers, and even customers who constantly change requirements. Every new library or tool states that it’s blazing fast, yet we keep building slow sites with it.

If we compare React bundle size throughout the years, it hasn’t significantly grown. What has grown is the amount of our own code written on top of React. It has grown so much that React itself started shifting its parts to the server (Server Components), which sounds insane for a frontend library!

In this article, we will see how the Next.js framework encourages performance-first development by offering or even enforcing several web optimisations out of the box. None of them are specific to Next.js. We can (and should) implement them using any other web development tools.

JavaScript Code Splitting
Preload JavaScript on link visibility
Dynamic import
Third-party scripts
Fonts
Images
Static optimisation
Edge Middleware
React Server Components and streaming SSR

JavaScript Code Splitting

From the very beginning, Next.js provided a page-based routing system. To make your app available at example.com/about you had to create pages/about.js file in Next.js. Many developers found this structure intuitive and easy to use.

Under the hood, it allowed Next.js to implement Route-based Splitting, which was further optimised in version 9.2 to benefit from HTTP/2.

Preload JavaScript on link visibility

Once we break our JS into multiple chunks, we must ensure they are loaded at the right time. Link component form Next.js prefetches corresponding page code using Import on Visibility or Import On Interaction patterns.

As you scroll down the notion.so website, you can notice some extra scripts are being loaded. If you then decide to go to another page, all necessary JavaScript will be already in place.

Dynamic import

Heavy code that is only used under certain circumstances can be lazy-loaded using Dynamic Import. This technique requires developers first to identify candidates for lazy loading and then implement a smooth loading experience for the user.

For many years, Next.js has been offering next/dynamic function for this purpose. Under the hood, it’s just a wrapper around React.lazy and Suspense that you can use in any React project.

Third-party scripts

As you may know, <script> tag behaviour is very complex. An external script can completely ruin your Web Vitals regardless of how well you optimise your code. Below is a quote from a brilliant tutorial by the Google team “Optimise your loading sequence”:

Scripts get different priorities based on where they are in the document and whether they are async, defer, or blocking. Blocking scripts requested before the first image ( or an image early in the document) are given higher priority over blocking scripts requested after the first image is fetched. Async/defer/injected scripts, regardless of where they are in the document, have the lowest priority. Thus we can prioritise different scripts by using the appropriate attributes for async and defer.

The main takeaway is that there is no one right way to include scripts on the site. We need to consider the entire loading sequence, versions of frameworks and browsers, the target audience of the site and a handful of other factors.

Back to Next.js, its <Script> component provides a simplified interface for HTML <script> tag:

<Script src="https://example.com/script.js" />

This code can be put anywhere in the app, and Next.js will load it at the most appropriate time (after the page becomes interactive). It’s best for most scripts, such as Google Tag Manager or Google Analytics.

If you need to load the script much earlier (or much later), you can use the strategy property.

Fonts

The easiest way to optimise Largest Contentful Paint (LCP) metric is to place a large text block at the top of your page. For example, Next.js homepage uses <h1> as LCP element:

Commonly, web designs are based on non-standard fonts aka web fonts. Loading them from Google Fonts or similar services takes precious time and creates other issues like Cumulative Layout Shift (CLS).

Next.js team has been working on fonts optimisation since version 10. They started with inlining font CSS and adding <link preconnect> hint for the browsers and by version 13 ended up with built-in self-hosting and optimisation for any font file.

Font optimisation is hard, and I’m incredibly grateful to the Next.js team for handling it for me.

Images

On many websites, the main contributor to performance issues is media. When I work on performance, I always start with images. They are usually easy to fix and bring an immediate, noticeable boost.

Thanks to WebP and AVIF, lazy loading and aspect-ratio, srcset and picture tag, we can deliver the most appropriate images to our users. Next.js offers a smart wrapper around <img> tag that utilises all mentioned techniques (and probably more) to reduce the amount of development work required to render an image in 2023.

Below is a screenshot with the resulting markup generated by Next.js Image component from this example:

As with any opinionated solution, next/image has its limitations, but it’s a great starting point that sets the bar high.

Static optimisation

A few years ago, the industry became obsessed with Static Site Generation (SSG). Good old static HTML was back under a fancy name. This very site was built using an early GatsbyJS version.

Indeed, static sites are more secure, faster, and cheaper. In 2020, Next.js announced Automatic Static Optimisation: a simple API that uses SSG for static parts of the app while serving the rest of the app dynamically.

Most dynamic sites couldn’t benefit from SSG at that time. First of all, it would require a massive rewrite. But the main problem was to trigger rebuilds every time you needed to update your static pages. We at SystemSeed overcame this issue by using Cloudflare CDN cache. You can learn more about this approach in my article “Let Cloudflare CDN speed up your classic website like it’s static”. Guillermo Rauch, Vercel’s CEO, later contacted me about that article:

Messages like this are the greatest reward for the author! 💚

These days Next.js provides a built-in way to regenerate static pages. It’s called Incremental Static Regeneration (ISR).

Edge Middleware

Next.js is funded by Vercel, a hosting platform that’s primary focus is speed. While most Next.js performance features are hosting-neutral, some are harder to self-host. Edge Middleware is a good example. It’s inspired by (and based on) Cloudflare Workers. If you are a Vercel customer, you can immediately benefit from blazing-fast edge computing without leaving your favourite framework codebase. Amazing!

But even if we are not on Vercel, their setup inspires us to build something similar with the tools available to us.

Vercel deploys the middleware code to edge functions, which are invoked before the request reaches the CDN. This allows static pages can be cached, as the middleware is called before the CDN sends back a cached response

The quote above is from the OpenNext project, which aims to port Vercel setup to other serverless platforms.

React Server Components and streaming SSR

From React 18 release notes:

In React 18, you can start using Suspense for data fetching in opinionated frameworks like Relay, Next.js, Hydrogen, or Remix. Ad hoc data fetching with Suspense is technically possible, but still not recommended as a general strategy.

React is getting more complicated. It took several years to release Suspense, and it will take another few years to adopt it. Given the level of complexity, it’s wise to delegate implementation details to experienced frameworks’ maintainers.

Next.js 13, the latest release to date, introduces a new routing system that supports streaming SSR, Server Components, and Suspense for data fetching. By pushing more code to the server, we can reduce the client-side JavaScript and speed up hydration.

If you are new to React Server Components, I recommend to start with Rendering Fundamentals documentation. Welcome to the new Next.js!

I’m sure the old pages routing will keep working for a while, but the new things will all go to the app directory.

To summarise

I welcome you to rethink Knuth’s words about premature performance optimisation and embrace the “Fast by default” mindset when building websites. Not all optimisations are evil. Some of them have become common sense and should be applied by default.

Next.js is an excellent example of the “fast by default” mindset. It popularises web performance best practices by making them easy to use (or even enforcing on ESLint level). I like this approach and apply it to other tools.

Similar to mobile-first or security-first development cultures, it takes time to establish “fast by default” mindset, and I’m grateful to Next.js for helping me with it.

🔭 Three tricks to get in focus mode

Kate — Sun, 05 Feb 2023 16:43:56 +0000

I find myself very lucky to be a software engineer. I enjoy solving problems with code, and it usually doesn't require any effort to go into "focus mode". Quite the opposite - it's sometimes hard to stop thinking about that tricky bug and close my laptop.

Still, there are situations when distractions and multitasking prevent me from achieving what I want. I have a few tricks in my toolkit to restore focus and attack the problem, even if it's a tough one.

What is the focus mode

Focus mode is a tool to handle certain types of work. Like a hammer or a needle, it's helpful in some situations and harmful in others. Focus mode is never the end goal. Before trying to focus, I need to figure out what and why I want to achieve with its help.

To focus means to keep our full attention on one thing for a long enough period of time. I haven't met any person who doesn't know how to do it. We all constantly go in and out of focus, naturally guided by our interests and curiosity.

Beyond focus, we can sometimes fall into the flow state, a highly intense and rewarding experience of full immersion in a particular activity. Mihaly Csikszentmihalyi studied the flow state his whole life and wrote a comprehensive book on the subject. What's crucial for this article is that the flow state usually requires focus as a prerequisite.

Mental state in terms of challenge level and skill level, according to Csikszentmihalyi's flow model, Wikipedia

Below I share three tricks that help me get into focus mode, but it's important to remember that they are merely techniques for occasional use. If I regularly experience difficulties with focus, I know it's time to revisit my plans. Are they aligned with my north star? Are they achievable?

This post was inspired by a question from one of my mentorship sessions at ADPList. Mentorship is a great way to explore deeper reasons behind the lack of focus. Read "Where to find a mentor" if you are interested in this route.

Trick 1: "Is it technically possible?"

6 am. My alarm throws me into a dark and cold Monday morning. Even my cat, who is supposed to be a nocturnal animal, is against this idea. Before I even notice it, I start looking for reasons to stay in bed.

In such moments I ask myself: is it technically possible?
Can someone like me get up at 6 am? Is it doable for a woman who went to bed at 10 pm and has scheduled some writing work before her regular working hours?

In 99% of situations, the answer is yes. It's not that cold in the kitchen for me to freeze. And if it's dark, I can turn on the lights 💡

Trick 2: Microtask

It's common practice to break work into small achievable chunks of work. Yet, even a well-scoped task can be hard to start. In this situation, I create a microtask - the first ridiculously small step.

For example, if I need to build a new project, a microtask can be "initialise git repository" or "print hello world on the screen". It helps to write the microtask down even if typing it will take longer than actually doing it!

If it's impossible to extract a meaningful microtask, I use the "Do X for 30 min" template.
Let's say I want to get better at solving algorithms problems, but I don't know where to start. I put the microtask "Work on leetcode for 30 min" in the Centered app and stare at the screen for 30 min. Half an hour later, I will understand my current level much better and can create more meaningful microtasks.

Microtask is similar to micromanagement. Only apply it to your own tasks when you are stuck.

Trick 3: Add flavour

If I don't have control over what I do, I can at least control how I do it. I call it flavour. Example:

What: review and update legacy documentation
How (adds interest flavour): generate images from your documentation using AI tool
How (adds challenge flavour): make resulting documentation shorter, not longer
How (adds value flavour): pair on it with a more junior developer
How (adds fun flavour): work on it from your favourite café

Deciding how I will do my work sparks motivation and increases self-accountability even when I don't feel deeply connected to the end goal of the task.

And many more

While writing this post, I discovered a good list of things that help me focus. Most of them are common sense rather than tricks:

🌅 Early mornings
🕰️ Sticking to schedule
🔏 Working in solitude
🧘‍♀️ Keeping mind clear (journaling, meditation, exercises)
🤝 External deadline / commitment
👯‍♀️ Involving other people
🎧 Music for concentration
🧗‍♂️ Embracing a healthy dose of discomfort

To summarise

We often find ourselves fully focused and dedicated when we work on interesting and challenging problems. It feels great, and we want more of that flow state.

Over the years, I learned a few tricks to restore my focus. I'm sure you have your own tricks, too. Please share in comments. I'd love to learn from you!

The road to Software Architecture (frontend edition)

Kate — Wed, 01 Feb 2023 08:30:43 +0000

According to the State of JS report, the “Code Architecture” problem was the main pain point for JavaScript developers in 2022.

In this post, I argue that folders are better than microservices, disagree with Uncle Bob, and cite Martin Fowler’s advice against the Gang Of Four book. This is my road to Software Architecture. Let’s go!

My background

As a Full-Stack Developer, I’ve been involved in the software design process since very early in my career.

Even before I realised it, I started making everyday architectural decisions such as:

where to put my code
what & how to test
which framework to use
how to spread the work between multiple developers, and so on

It turned out these little decisions matter in the long run. Some pieces of PHP code that I wrote eight years ago are still in use in production.

The oldest React app that is currently in use was started by my team at SystemSeed in 2017 from the Create React App template. We’ve managed to stay on un-ejected CRA all these years and recently upgraded the codebase to React 18.

Another long-living project was built with Next.js 2. Today it runs on top of Next.js 13 and serves thousands of users around the globe.

Working on such projects brings a lot of problems that I can classify as “Code Architecture” from the State of JS report. Let me elaborate on what I understand by that.

Software Architecture (as I understand it)

There are many clever definitions of software architecture. In this article, I lean towards the term “software architecture” to avoid any confusion between “software design” and “UI design”.

Philosophically speaking, software architecture work is about finding optimal answers to questions that don’t have one correct answer. I mean those questions with zero answers on StackOverflow (apart from the famous “It depends”).

Architectural problems often appear at the worst possible moment, disturbing our coding flow and making us feel annoyed and uncertain. That’s why software architecture can feel like a pain point, but in fact, it’s an essential part of our jobs, and Copilots can’t do it yet!

Traditionally, software architecture decisions have been part of more senior roles’ responsibilities. Some companies even have a dedicated Software Architect role. That person, though, wouldn’t be able to decide on every little detail. They likely came from the backend background to oversee the systems on a very high level. So in practice, developers who actually implement frontend applications are the main contributors to the resulting code architecture.

That’s suddenly a lot of pressure on us! Let’s see how we can reduce our anxiety around code architecture and become better at it.

Learn your tools

“Clean Architecture”, the famous book by Uncle Bob, states that we should design framework-agnostic architectures:

Good architectures are centered on use cases so that architects can safely describe the structures that support those use cases without committing to frameworks, tools, and environments.

Really? Well, I’m hired as a framework specialist; how can I put it aside?

The answer turned out to be simple. Before you can put the frameworks aside, you need to learn a few of them on a very good level. Once you become fluent in a couple of frameworks, you start to see patterns and trade-offs. At that point, recommendations from Uncle Bob will start to make sense.

For example, these days, I focus on improving my React skills. For me, learning advanced React patterns is a valuable time investment and a good step towards understanding modern frontend in general.

My decision to focus on one established technology means saying no to many other tools and frameworks highlighted in the State of JS report. It's uncomfortable to feel "left behind," but I am confident that it will pay off.

As Nathaniel Schutta says in "Thinking Architecturally":

I thought I’d “missed the wave” of some technology or another. What I didn’t appreciate at the time is that new technologies are a lot like buses — one comes every 15 minutes or so.

Once I understand the tool deeply, I start making more informed architectural decisions.

Embrace folders

Many of us jumped into microservices way too soon. There is a much safer (and cheaper) option — folders!

Folders are logical boundaries of our modules, features, components, etc. Well-organised file structure makes project architecture readable and extendable.

React community has a couple of suggestions to start with (1, 2). The official site says:

If you’re just starting a project, don’t spend more than five minutes on choosing a file structure.

It’s not because file structure is not important. It’s because it should change as your project evolves. Let’s say you had to touch files from ten different folders to ship a new feature. It’s a sign that you need to review your folder structure (and your logical boundaries).

Testable code

Most people write tests because they want to be confident that the app works as expected after code changes. As a nice bonus, testable code results in better code architecture!

For a long time, I was only using end-to-end tests that treated the resulting app as a black box. It allowed me to write mediocre code with spaghetti from dependencies, inconsistencies and workarounds. Everything changed when I started to imagine how I would write other types of tests for my code:

Visual regression test (e.g. component look & feel with dummy content)
Unit test (e.g. how the utility function calculates the fee based on ordered products)
Integration test (e.g. how the Basket component responds to user interactions such as hover and click)
End-to-end test (finally, how the entire shopping flow works in the browser)

Even if I don’t write all these types of tests, thinking about them helps me structure my code better.

What about design patterns?

Design patterns in software are similar to the chords in music. Someone discovered them many years ago, but people keep combining the chords in many different ways to compose new songs.

Just like learning chords by the book may be difficult at the beginning, classic design patterns books may not make any sense for a frontend developer.

A quote from Martin Fowler’s review of the famous Design Patterns book:

Despite my praise, this is not an easy book to read. I don’t recommend it until you’re pretty comfortable with the basic principles of OO design. Even then it takes a fair investment of effort to really appreciate the book. Unlike most books, however, it amply pays that investment.

Luckily, we can learn about modern JavaScript and React design patterns from a free book Patterns.dev. It describes all common patterns in a frontend-friendly language with practical examples and animations.

Observer Pattern animation from patterns.dev (video)

The Community Patterns section lists some framework-specific resources to dig deeper.

Business logic

The pieces of UI logic we write for the frontend may be trivial, but their large volume and constant changes become a challenge as the projects grow. The most coherent approach to business logic that I have found so far is Domain-Driven Design (DDD).

DDD places a strong emphasis on building a shared understanding of the problem domain and focuses team efforts on the most important parts (“Core” subdomain).

Domain-Driven Design is about letting your business domain drive your design decisions.

Vlad Knononov, "Learning Domain-Driven Design"

In other words, development teams should understand and stay focused on the problem the business is trying to solve for its users.

If it sounds too abstract, I recommend the “Learning Domain-Driven Design” book (read my review here).
I’m currently exploring ways to apply DDD principles to frontend architecture problems. Stay tuned for more articles on the topic.

To summarise

Some questions about software development don’t have one correct answer apart from “It depends”. We face them every day, and our answers contribute to the architecture of the projects we work on.

Developers who know their tools and cover their code with tests tend to make better architectural decisions. That’s why I suggest starting by mastering essential frontend tooling.

Once we feel comfortable with the tooling, we can zoom out and think in terms of design patterns and business problems. It’s a whole new world! I made several attempts to enter it, and I found the following resources most helpful so far:

Patterns.dev - frontend-friendly book on design patterns
“A Philosophy of Software Design” - my favourite software engineering book
Learning Domain-Driven Design - good introduction to DDD (my review)

That’s how far I went on my road to Software Architecture.

Follow me on here on dev.to or on Twitter to stay updated on my next adventures.

Flutter guide for React developers

Kate — Tue, 24 Jan 2023 08:06:39 +0000

Flutter is a popular framework for building cross-platform mobile apps. I had a chance to play with Flutter and found quite a few similarities with React. In this guide, I map common Flutter concepts to their equivalents in web development. If you are a React developer interested in Flutter, it will help you find your fit in the new territory.

This article doesn’t question whether you should use Flutter, React Native, PWA or a native app approach. There are good use cases for each of them. Today we will focus on Flutter for mobile app development. Let’s dive in!

VS Code → VS Code
Chrome Dev Tools → Flutter Dev tools
TypeScript → Dart
ESlint → Dart lint
div → Widget
CSS → Widget
Accessibility → Widget (again!)
@mui → Material Components (MDC)
Render → Build
State → State
npm → pub.dev
Redux + React Query → Riverpod
React Router → Go Router
Backend → Firebase
React Testing Library → flutter_test
React Docs → docs.flutter.dev
What’s next

VS Code → VS Code

Most Flutter developers write code with the same tools as web developers.

VS Code with Flutter extension is the most popular option.

Android Studio has first-class Flutter support if you are more comfortable with IntelliJ IDEA. I picked this option and was quite happy with it.

Like any other mobile dev setup, it takes time to prepare everything for cross-platform development. To help developers troubleshoot their local setup, Flutter comes with a handy utility flutter doctor:

💡 Get started with the local development environment:

Carefully follow official installation instructions. Don’t skip steps!
If you are not ready to install Flutter locally, you can also use DartPad, an online Dart & Flutter playground

I personally found the initial installation process more straightforward than for React Native.

Chrome Dev Tools → Flutter Dev tools

It’s hard to imagine web development without the powerful dev tools we have in our browsers.

Surprisingly, Flutter isn’t far behind. I started using Flutter widget inspector from day 1 to debug my widgets styling issues. Just like in Chrome, Flutter Inspector has multiple tabs, from Networking to Performance. It was interesting to explore my app from different angles there.

Last, you can debug Flutter code from your IDE using breakpoints. For some reason, I still prefer console.log() in JavaScript!

💡 Get started with Flutter Dev tools:

DevTools - official documentation

TypeScript → Dart

Flutter uses the Dart programming language. Dart is similar to JavaScript but with types and some nice syntax sugar on top of it.
For example, Dart has an async functionality, but Promises are called Futures there.

If we need an array in the JavaScript sense, in Dart, we use a List:

var nav = ['Home', 'Furniture', 'Plants', if (promoActive) 'Outlet'];

The example above is a List of Strings. The last item is only added if promoActive is true. Neat!

💡 Get started with Dart:

Learning Dart as a JavaScript developer - half an hour, and you are ready to go!

My experience with Dart was only positive so far. You don’t need to spend time configuring TypeScript or Webpack. With Dart, everything is built-in and ready to use.

ESlint → Dart lint

Dart & Flutter have built-in code analysing and formatting tools. It makes it easy to learn framework best practices. I was happy with the default linters setup, but it’s possible to customise it too.

💡 Get started with linters:

When you start a new Flutter project, the linters should be preconfigured for you
For customisation check Dart linter rules and Flutter linter rules

div → Widget

Everything in Flutter is a widget.

If you compare them to HTML tags, Flutter widgets are usually much more specialised.

For example, “to center a div” in Flutter, you use the specialised Center widget:

Center(
    child: const Text("I’m centered!")
),

It takes time to get familiar with all built-in Flutter widgets. I don’t think I explored even half of them.

💡 Get started with Widgets:

Scan through the Widget catalog to learn what’s available
Regularly watch short “Widget of the Week” videos from the official Flutter team.

I didn’t quite enjoy Flutter’s way of passing children as properties. Personally, I find JSX syntax easier to work with.

CSS → Widget

Everything is a widget, remember?

Flutter doesn’t support CSS. Instead, all styling is handled by widgets and their properties.

Let’s say I want to add some padding to my Center widget. In Flutter, I need to wrap my widget with another one, specialised in padding, and pass my original widget via child property:

Padding(
   padding: EdgeInsets.all(16),
   child: Center(child: Text("I’m centered!")),
);

EdgeInsets.all(16) means padding: 16px.

Flutter operates in logical pixels and takes care of translating our values into physical pixels for each device and screen type.

Now let’s add a black border with border radius around the previous widget:

DecoratedBox(
      decoration: BoxDecoration(
        border: Border.all(
          color: Colors.black,
          width: 1,
        ),
        borderRadius: BorderRadius.circular(12),
      ),
      child: const Padding(
        padding: EdgeInsets.all(16),
        child: Center(child: Text("I’m centered!")),
      ),
)

In Flutter, all properties are granularly typed, and for each aspect of styling, you need to create a value of the appropriate type. Because of that, the resulting code is much more verbose.

💡 Get started with Widgets:

Scan through the Widget catalog to learn what’s available
Regularly watch short “Widget of the Week” videos from the official Flutter team.
How to choose which Flutter Animation Widget is right for you? - great overview of Flutter animations.

Accessibility → Widget (again!)

Accessibly is a first-class citizen in Flutter. For example, images and icons have the semanticLabel property for screen readers. For more advanced cases, there is a special widget Semantics which has more than 50 properties to describe the meaning of your widgets.

The Flutter team made it easy for developers to debug accessibility by providing the showSemanticsDebugger property. It replaces the original widgets with the corresponding semantic labels that the screen readers would read:

💡 Get started with accessibility:

Accessibility widgets - official documentation

@mui → Material Components (MDC)

@mui is Material Design implementation for React. When using @mui as your component library, you first create a top-level theme, expose it via React Context, and then enjoy consistent styling across all your components.

Below is how you would print a heading with @mui:

<Typography variant="h4">Heading 4</Typography>

Flutter comes with Material Components (MDC) out of the box. Technically you can opt-out and go your own way, but I haven’t explored that route yet.

Similar to React implementation, various aspects of the theme are first configured at the top level of the app and then reused in individual widgets like this:

Text(
    'Heading 4',
    style: Theme.of(context).textTheme.headline4,
)

💡 Get started with Material:

MDC codelabs (small practical lessons) from the official Flutter team
Material Theme Builder supports export in Flutter
Material 3 for Flutter by Eilidh Southren
Flutter Theming Guide by Mike Rydstrom

Be prepared for a steep learning curve: hundreds of widgets and properties, sophisticated Material theme configuration, and of course, mobile device specifics that don’t exist on the web.

Render → Build

Flutter widgets are classes that must implement the build method. It’s similar to the render method in React class components.

Let’s implement the build method for our “centered div” example from the beginning of this guide:

class CenteredText extends StatelessWidget {
  const CenteredText({super.key, required this.text});
  // Props are class members in Flutter.
  final String text;

  // Widget must implement the build method.
  @override
  Widget build(BuildContext context) {
    return Center(child: Text(text));
  }
}

If you had a negative experience with class components in React, put it aside for a moment. Flutter is based on Dart, and its class implementation is much more robust and well-thought than in JavaScript.

💡 Get started with building custom widgets:

How to Create Stateless Widgets from Flutter in Focus video series

State → State

Quote from Flutter documentation:

Flutter widgets are built using a modern framework that takes inspiration from React. The central idea is that you build your UI out of widgets. Widgets describe what their view should look like given their current configuration and state. When a widget’s state changes, the widget rebuilds its description, which the framework diffs against the previous description in order to determine the minimal changes needed in the underlying render tree to transition from one state to the next.

The actual implementation of stateful widgets differs from how we build stateful components in React. Instead of adding one line of code with the useState hook, you need to create two (!) separate objects: one for the stateful widget and another for its state. Wonder why? Check out the links below for details.

Luckily, both VS Code and Android Studio have shortcuts to scaffold Flutter widgets. In practice, I can create Flutter widgets as fast as I create new React components.

💡 Get started with stateful widgets:

How Stateful Widgets Are Used Best from Flutter in Focus video series
Flutter’s setState() might not be what you think it is - Flutter is inspired by React, but under the hood, it works differently.

npm → pub.dev

pub.dev is the official package repository for Dart and Flutter apps. I found it very clean and developer-friendly.
Pub.dev promotes high-quality packages via the Flutter Favorite program and Package of the Week YouTube show.

There are two files in the Flutter app directory that are related to pub.dev: pubspec.yaml and pubspec.lock (equivalents of package.json and package.lock).

💡 Get started with pub.dev:

Head to pub.dev and explore the packages

Redux + React Query → Riverpod

Like with React, the Flutter ecosystem has born a dozen competing state managers.

Some seasoned Flutter developers lean towards Riverpod (#5 in the chart above) when building real, complex applications. I trust their choice.

💡 Get started with Riverpod:

Flutter Riverpod 2.0: The Ultimate Guide by Andrea Bizzotto
Time Tracking app with Flutter & Firebase - an example app by Andrea Bizzotto

React Router → Go Router

Mobile app navigation is quite different from the web. The built-in Flutter Navigation API is so complex that the Flutter team decided to build an official third-party package with a simpler API: Go Router.

Similar to React Router, you declare your routes (and their sub-routes) and map them to the screens of your app.

Get started with Go Router:

Flutter Navigation with GoRouter: Go vs Push by Andrea Bizzotto
Deep linking - official Flutter documentation

Backend → Firebase

Mobile/desktop apps are rarely static landing pages. Almost always they require some backend for authentication, data synchronisation, analytics and more. Yet most apps will never become popular, and developers don’t want to spend months building sophisticated backends. That’s why Firebase is so popular in mobile dev, Flutter included. It offers a set of APIs for all common features you may need as a mobile developer, all free until a certain threshold.

Google supports both Flutter and Firebase so you can expect an excellent integration between the two. If you don’t want to store your data with Google, several open source alternatives provide similar developer experience.

💡 Get started with Firebase:

Add Firebase to your Flutter app - official documentation
One-file Firebase chat app - official DartPad example
I tried 5 Firebase alternatives - video by Jeff Delaney

React Testing Library → flutter_test

A robust testing ecosystem is another sign of a serious approach to the framework quality.

Developers can test Flutter apps with the following types of tests:

Unit — verifies the behaviour of a method or class
Widget — verifies the behaviour of Flutter widgets without running the app itself
Golden — verifies visual output of Flutter widgets without running the app itself
UI integration — verifies the full app UI works by running the app on a device (some network services can be mocked)
End-to-end — same as above, but without any mocking

Example of a widget test:

testWidgets('Testing MyWidget', (WidgetTester tester) async {
  await tester.pumpWidget(MyWidget());
  await tester.tap(find.text('Save'));
  await tester.pump();
  expect(find.text('Success'), findsOneWidget);
});

WidgetTester provides an API to manipulate widgets programmatically; for example, tester.tap(find.text('Save')) will simulate tapping on the “Save” button.

It was pretty unexpected for me to find visual regression testing tools (Golden image tests) in the standard testing library. In addition to the standard tools, there are several external packages that help to further advance Flutter testing.

💡 Get started:

Testing Flutter apps - official documentation
Golden Toolkit - UI regression tests on top of Flutter’s Golden test functionality

React Docs → docs.flutter.dev

Official Flutter and Dart documentation are exceptionally good. Apart from detailed written documentation, the Flutter team provides interactive examples, videos, and codelabs.

You may not need any paid external resources at all to become a Flutter dev.

What’s next

I hope this guide will help you navigate the Flutter world as a React developer. If you are at the very beginning, start with “Your first Flutter app” codelab. Feel free to bookmark this guide and return to it as you progress through your journey!

My approach to the command line

Kate — Mon, 10 May 2021 14:31:58 +0000

There is an idea that every developer should master tons of sophisticated tools and keyboard shortcuts to be truly professional and efficient.

My experience doesn't confirm it. As an example, let me show you my command line setup. I'm not a sysadmin, but as a full stack developer with 10+ years of experience I use the terminal on a daily basis yet I've got a very basic setup:

No tmux
No aliases
No special .dotfile configs
No shell preference. I'm fine with zsh, bash, ksh, etc
No jokes on how to quit vim 🔫

My favourite terminal shortcuts

Ctrl+R to explore the history
Ctrl+C to cancel / cleanup current command
Ctrl+L to clean the screen
Ctrl+A / Ctrl+E to jump to the beginning / end of the command string

My top-used commands

git
j (smart cd)
make
ls
rm
cat
grep
vi
yarn, npm, npx, composer, docker-compose and other project-specific CLI tools

You can grab your most used commands too: How do I see what my most used linux command are?

Why I stick to defaults

Apart from autojump, everything else in my setup is quite basic. I try to stick to defaults as much as possible. This is why:

Common use cases are easy to google.
StackOverflow is full of advice on how to do X, Y, Z in the terminal. In 99% of the cases the solution will use standard tools that are already available on my machine: ls, rm, cat, find, grep, awk, sort, sed, curl, chmod, etc.

Non-standard tools require installation.
If I make rg or ag my default search tool, I'll have to install it on the remote servers, in the CI environments, in the cloud IDEs, on my colleagues' machines. It's not always possible.

Customisation requires more learning and memorising.
Now I need to learn how to use both the new tool (let's say ag) and the standard pre-installed tool (usually grep). Otherwise, I won't be able to work in remote environments, help a teammate (or receive help from them), debug a CI script, etc.

Updates and troubleshooting.
Custom setup can become outdated, can introduce bugs or security issues. I can simply forget that I installed a tricky git helper a year ago and it will cost me a day of troubleshooting at some point.

Learn the basics and have fun!

Most of the modern development stacks assume basic command line knowledge. The keyword is basic: you don't need to make Vim your default text editor or master tmux to become a better developer. If you normally spend 30% of your time in, let's say, Chrome DevTools and another 30% in VS Code, then you'd better master Chrome DevTools and VS Code first.

As a developer and Tech Lead, I think of the terminal mastering as something extra that I'm free to do if I want. After all, it can be a lot of fun! But I don't have to be a command line geek, and you don't have to either.

Question for you

What is your favourite CLI command or shortcut?

Mine is Ctrl+R to search through my command line history. This is how it works:

Hit Ctrl+R
Start typing any part of the previous command you want to run again, e.g. exec
You command line will be prepopulated with the most recent command that contained exec
If it's not the right one, hit Ctrl+R again to cycle through older commands.

3 simple management tricks I learned as a Tech Lead

Kate — Thu, 08 Apr 2021 07:39:42 +0000

Developers often blame "bad management" when something goes wrong. I've been there too, I remember the pain.

For me, it was useful to sit on both chairs for a while acting as a Tech Lead. In this article, I share three dead simple tricks everyone can start using now to become better managers for themselves. No MBA required 🤓

1. Repeat (say it again)

Yes, the tricks will be very simple, even stupid, but they work! One of my favourites is repeating. It's a very powerful yet underestimated technique.

Finding the courage to say something once is hard, especially when the topic is important to you. But don't stop there! People forget, deprioritise and misunderstand all the time.

Internet is full of advice on how to say No, which implies that everything has to be said at least twice. Camille Fournier actually suggests you need to say it three times:

Finally, never underestimate how many times and how many ways something needs to be said before it sinks in. Communication in a large organization is hard. In my experience, most people need to hear something at least three times before it really sinks in.
The Manager's Path, Camille Fournier

Some examples where repeating is useful:

Remind about an ongoing problem if it was deprioritised.
Talk to someone else if the first contacted person wasn't helpful.
Insist on prioritising some refactoring or housekeeping work.
Rephrase technical concept in plain English.
Keep pointing out the agreed coding practices until they are being followed.
Thank teammates for their help, again and again, in different ways.

Some channels may overuse repetition (e.g. TV series or popular non-fiction). It annoys us and we may think that saying the same thing multiple times is rude or dull. From my experience, if you are respectful and creative, everyone will appreciate your persistence.

2. Write full sentences (overcommunicate)

Remote work involves a lot of written communication via email and chat apps. Make your written communication explicit and straight to the point so that people don't have to read 50 chat messages and two different Jira tickets to understand your last "@channel" message in Slack.

Two ways of saying "No update yet" about the hosting incident:

✅
No update yet. I'm checking with Mike from DevOps team about the issue with www.example.com deployment. I will come back to you in 15 min.

❌
No update yet. I'll check with Mike about that issue.

(Who is Mike? Which issue? When will you check? When will my site go up!?)

Again, over-communication isn't rude, it's really the opposite. If something is obvious to you (e.g. there is an ongoing issue with www.example.com ), it doesn't mean it's obvious to everyone else. Give them the necessary context as part of your text message, and you'll get meaningful responses faster.

3. Take care of yourself

If I would need to limit this article to only one piece of advice, I would keep this one.

You know better than anyone else when you are stuck or bored or confused. It's very normal and it happens to all of us from time to time. Take action to get yourself out of it. If we all as individuals will take care of ourselves, many problems will be resolved much quicker and easier. Uncommunicated problems create more problems.

Your manager may catch some signals of your burnout when it's too late. Help them and ask for a break sooner.

Your boss may have no idea that you want to leave the company because you hate DevOps work. Help them and ask for more frontend work in the upcoming project.

Your client has no idea that you are a morning person. Help them and ask to move late meetings earlier in the day. Repeat if it didn't work from the first time 😃

There is no point in struggling at work. Happy people deliver better results, but what is more important, they make other people happier.

Hopefully, these simple tricks will make you a bit happier at work too!

“Just for fun” coding resources / ideas?

Kate — Fri, 14 Aug 2020 21:00:03 +0000

Cover photo by Ryan Quintal on Unsplash

Hi DEV!

Could you recommend any ideas/frameworks/games for “Just for fun” coding?

In my normal Tech Lead role, I miss coding a lot, so I decided to spend some time next week coding just for fun. Not reading too much, not configuring servers too much, not promoting or selling the product — just good old code stuff! 💻🥳

I mainly worked with Next.js and PHP (it was the main tech for building web sites when I started 👵), but have touched a bit of everything.

What would be your advice?

Let Cloudflare CDN speed up your classic website like it's static

Kate — Sat, 08 Aug 2020 15:29:23 +0000

One obvious strength of static sites is their performance. The pages aren't generated by the server but instead pre-built into HTML & CSS files.

Many of us developers have already played with the technology, built their own static site generator and learned the pros & cons of this approach. I won't discuss all of that in this article. Instead, I will remind ourselves of something else that's been there for years — CDN.

These days CDN setup should not necessarily be very complicated and enterprisy. In fact, I will be using free Cloudflare tier in my examples. Other CDNs have the same or similar setup.

How it works

When your web server returns a page, let's say "https://www.mozilla.org/en-GB/", it also returns Cache-Control header explaining to the external world how to cache this specific page. For example, it can say "do not cache me at all" or "cache me for an hour", please.

Browsers and CDNs respect Cache-Control header when they serve web pages. If the page can be cached, they save it in their cache storage and next time serve cached version without ever touching your web server. That's how a dynamic WordPress site can behave like static for the entirety of anonymous users.

Let's have a look at https://www.mozilla.org/en-GB/:

HTTP status of the page is 200 meaning that this page was not cached in user's browser yet.
Mozilla.org server returned cache-control: max-age=600, which means "Hey, browsers and CDNs: cache this page for 10 min max."
Cloudflare CDN indeed has already cached this page (HIT)
I've got a cached version which is 96 seconds old.

If within those 96 seconds something has changed on that page, e.g. a typo has been fixed, then I will still see the outdated version for the next 504 seconds.
To avoid the page with typo to be served from CDN cache, developers from Mozilla can either flush CDN cache from Cloudflare admin UI or by using their API.

Now let's dig into the details.

Enabling cache beyond static files in Cloudflare

This step will vary for each CDN service. In Cloudflare, you need
to create so-called "Page Rule" that will enable "Cache Everything" mode for specified page pattern. Example below:

Apply this rule to the entire domain
(Optional) Switch off "Always Online" feature in favour of stale-if-error (will be discussed below)
Cache everything (as opposed to caching only certain file extensions)
(My favourite one) Respect "Cache-Control" header from my web server (also known as "Origin").

Note that I asked Cloudflare to follow Cache-Control directives returned by my web server.
It gives me unlimited flexibility in configuring caching TTL for different pages.
In the following section, we will discuss it further. For now, I have to add that in addition to item 4 you need to configure "Browser Cache TTL" setting in Cloudflare to "Respect Existing Headers".

If you don't want to mess with Cache-Control in your codebase, you can ignore item 4 and "Browser Cache TTL" setting completely. Cloudflare will add Cache-Control header for you anyway and you will be able to fine-tune it by "Page Rules".

Adding Cache-Control header to your dynamic content

In my experience different site pages and query params may have different cacheability opportunities.
Think of it as if parts of your site are completely static and others are very dynamic.
With Cache-Control you can achieve this behaviour.

    server.get('*', (req, res) => {
      if (
        // Allow to bypass CDN cache by adding ?bypass=cdn to URL.
        req.query.bypass === 'cdn'
      ) {
        res.setHeader(
          'Cache-Control', 'no-store, must-revalidate'
        );
      } else {
        res.setHeader(
          'Cache-Control',
          'public, max-age=0, s-maxage=3600, stale-if-error=3600, stale-while-revalidate=30',
        );
      }
      return handler(req, res, app);
    });

The example above is a simplified Express handler to vary caching behaviour based on the incoming request.
You can achieve something similar in any popular web framework.

Note that Cache-Control directive is a bit more advanced in my example:

max-age=0 - do NOT cache on a browser level
s-maxage=3600 - cache on CDN (shared cache) for an hour
stale-if-error=3600 - serve stale cached version for one hour more if the origin server is not available (supported by some CDNs)
stale-while-revalidate=30 - serve stale version while the new version is being fetched from the origin server (supported by some CDNs)

You can build your version of Cache-Control that will serve your needs.

Invalidating cache

In the case of a static site, you need to re-build and re-upload assets to your server.
Some services automate this process so that content editors don't have to deal with it.

We have a similar situation with CDN cache: if you want the newer version of the page to become available to the rest of the world right now, then you need to invalidate the existing cache.
Cloudflare users can do it either in admin UI or via API.

If you use CMS e.g. Wordpress or Drupal, they may have plugins for automated cache invalidation.

Otherwise, you can call Cloudflare API directly in the appropriate place of your codebase.
The most used API endpoint is POST zones/:identifier/purge_cache - purges cache for specific URLs.

Note that Cloudflare doesn't offer cache purging by wildcard. There is "Cache Tags" feature on Enterprise tier but I have never used it.

Other CDNs offer cache purging via API too. For example, Fastly has soft purging in addition to hard purging. This is something I miss in Cloudflare API. Let's say I updated content page in my CMS and it automatically purged cache for some URLs that were affected by my update. If I managed to break the site with my update, then purged URLs will be down for all anonymous users.
With soft purge + stale-if-error you could stay always online.

Alternately to automated cache purging, you can just keep cache TTL very short (10 mins like in Mozilla example) instead of triggering automated cache invalidation on every content change.

stale-if-error or Always Online

As you may remember, I suggested to switch off Cloudflare's "Always Online" feature (which is often enabled by default) in favour of stale-if-error. stale-if-error isn't noticeable for the end users while "Always Online" adds Cloudflare banner at the top of your web page informing your users that the site isn't working at the moment.

stale-if-error is a standard Cache-Control directive that is supported by other CDNs as well.
It asks CDNs and browsers to serve stale cache if the page isn't available on the origin web server. Different CDNs can understand page availability differently. For example, Cloudflare will respond with stale content only to the specific error codes:

500 or 503 error codes trigger neither Always Online nor stale-if-error.

To summarize

Modern CDNs (and HTTP) provide a simple and elegant way to make parts of your site behave like they are static. CDN cache protects the site from traffic spikes and makes some of the site errors and instabilities invisible for end users. It's not just for heavy
enterprises. A mid-size website can save computing costs of their hosting by enabling CDN cache for the most popular site pages.

Of course, you should still work on the performance of the original site but CDN cache can be nice low-hanging fruit in your journey 🍒

How to investigate technical solutions

Kate — Sat, 23 May 2020 19:30:00 +0000

In my previous post on the subject I suggested the long term approach to the learning problem: focus on general knowledge rather than on specific tools and implementations. But what if you need to investigate a new technical field right now, let's say this week, to proceed with the project at hand? Tech leads do this kind of work regularly in order to prepare high-level estimates and architect new systems.

In this article, I will share my approach to a quick technical investigation. I apply it to new technologies and any other unknowns as they appear in my daily tasks. I mapped the steps to the days of the week, but the timeline can be scaled up or down based on the size of the problem. So, let's get started:

Part 1: Monday

😍 You are great

It's totally fine to not know something. Don't treat it as your “fault” or a lack of talent/education/seniority. You are going to figure it out and you are great!

🔍 Be specific

Narrow down the area of investigation as much as possible. In practice, it means that technical investigation starts with business investigation. When the problem is defined, ensure you can't solve it without further investigation. Sometimes people ask for AI, but their problem can be solved with a regular expression. Stop thinking that your solution isn't “cool” enough. It's super cool as long as it solves the problem.

🙋‍♀️ Ask people

If you need to proceed with further investigation, then first ask your colleagues and friends who were working on something similar in the past (don't confuse friends and colleagues with random strangers on the internet!). There is no point in learning something the hard way if you can just ask your teammate for help. An extreme variant of this option is to hire a person who has the necessary experience and learn from them.

📝 Pick 10 random articles

Google your problem definition using different wording and pick 10 random articles and videos (it also can be one short book). List them in your notes and start reading them all from top to the bottom. Don't try to figure out your final solution, don't make any decisions just yet, don't try code snippets suggested in the articles. Just read them.

Keep reading and taking quick notes. It can be a simple bullet list, a drawing or a mind map. Stop when you finished with your 10 articles. Sleep on it.

Part 2: Tuesday

🏁 Fill in the gaps

Review your notes and compare with the problem definition. You'll notice some gaps in your notes. Google them again, find 2-3 extra resources and add them to your list. Finish the notes and stop gathering information. Most likely you have already learned just enough to proceed to the next step.

👯‍♀️ Show it to a teammate

Now it's time to present your notes to someone else. Explaining the topic to another person will help you understand what you learned.

While presenting, reflect the fact that the information is not yet verified. For example, don't say “The best A/B testing tool is X”. Instead, say “I found several authors who really enjoyed X”. Pay extra attention to the remaining unknowns (instead of leaving them out of the discussion).

Together, narrow down potential solutions to a minimum. For example, if you have five A/B testing services in your notes, pick two most promising based on what you learned so far and on the problem definition. Don't worry that you may occasionally exclude the “right” solution from your shortlist. There is no one right way to solving any technical problem.

Part 3: Wednesday, Thursday, Friday

🏖 Try it in a sandbox

Finally, we are in the famous practice step. I remember times when I was putting together something new that I barely understood only to push it to production faster. This approach was fast at the beginning, but in some cases, it slowed down further development dramatically.

Before starting to write any code, prepare a list of outstanding questions that you want to clarify through practice. When the problem is small enough, you can start implementing the real solution without properly finishing the investigation. But in the general case, proofs of concepts should not go straight to production to avoid unnecessary risks.

✍️ Write a summary

Finish with a concise report that you wish had been written by someone else before you
started your investigation. Don't put too much effort in it - such reports usually become outdated in 6-9 months. Share the report with the team and agree on the next steps. Switch to something else for a little while to clear your mind.

To summarise

My quick investigation process includes the following parts:

Gathering & structuring information on a very narrow topic (X time)
Sharing with someone else and filtering out (X time)
Building proofs of concept to figure out some crucial details (3X time)
Putting together a summary for discussion and further actions.
Iterating.

This process is very intense because you consume and analyse a lot of new information within a short period of time. It also can be uncomfortable to touch something completely new and to feel stupid after being “an expert” in your field. As Josh Kaufman explained in “The first 20 hours” talk, the main barrier to learning something new is emotional. It's often hard to start and even harder to finish. I hope that my article will help you to overcome those issues when you next time will be investigating a new technical problem.

Remember, you are great!

The Tech Lead rule: Management first, coding second

Kate — Sun, 05 Apr 2020 14:36:56 +0000

I opened my previous post about 1:1 meetings with the following paragraph:

Every new Tech Lead will struggle to find time for coding in their busy day. That's very normal because when you step into Tech Lead shoes you suddenly need to learn all those management tools from planning and prioritisation to decision making to conflict solving.
You never know what you will need first, so you will have a fun time learning a bit of everything in parallel (and trying to meet your coding hours quota at the same time).

I now realised that the idea of that paragraph is not very obvious, especially if you are just about to start as a Tech Lead.

Tech Lead is a manager

It seems to be clear that we, Tech Leads, are developers, and we should write some code, should stay current and keep our hard skills sharp.

What is often forgotten or put at lower priority is that a Tech Lead is a manager and our management skills are the key to our success in the role.

It's true that as Tech Leads we don't usually have full-time management responsibilities (and often have no authority), but it doesn't change the priority: management first, coding second.

Even if you've got a very small team and management bit takes just 20% of your time, that 20% is still the most important part of your job. If you deprioritise it or do it poorly, then your small team is in danger: they may miss the deadline, spend time on the wrong task, get stuck or blocked by another team, overengineer the solution, overpromise to the stakeholders, fail at their performance quotas without understanding what they did wrong. Tech Lead as a manager can prevent or notice such issues sooner. Tech Lead as a developer can only try to write the entire codebase alone (and fail at that).

Management first, coding second - once you start to see it in this order, it will become clearer what's next.

Tech Lead is a developer

Usually, we learn the basics of management by watching how other Tech Leads and managers work. Some of us are good leaders naturally, and it helps too. Still, most of us grow into Tech Leads from Senior Developer role and we don't have a degree in management. Furthermore, you may be affected by a bias that management isn't that important and only creates problems for the dev teams.

It's important to recognise that you are now supposed to do a new type of work, that you have never done professionally before. It's time for opening your mind for learning and practising new skills. It's not a good time for full-day coding tasks.

Management tasks

Now, when we have the priorities cleared, let's review major areas of your management efforts.

📆 Invest in team planning

Help each team member to create a plan for their working week. It doesn't mean that you need to assign tasks to everyone (sometimes you need, but it's an edge case). Your goal is to create and maintain an environment where each team member can figure out what they will be doing tomorrow without checking with you/your manager/stakeholders every day.

You'll need to have a plan for your week, too, and it should reflect the "management first" rule.

One common piece of advice to novice Tech Leads is to get better at time management. I think that you should first get better at mid-term planning (monthly and weekly). Then it will become easier to manage your time within each day.

📚Invest in knowledge sharing

Make sure documentation is treated seriously by the team. Lead by example: document things that are often asked by the clients and other team members.

Make yourself available for questions during the day. If you put yourself in DND mode for an entire day, you won't be able to create an environment where people are willing to help each other. In such an environment, you'll be able to step back from time to time, and nobody will notice.

🌀Invest in workflows and processes

Meet your new best friends: company workflows and processes. They are "reusable libraries" of management. They can help many developers stay productive and creative, just like software libraries and frameworks help us build projects quickly and consistently.

To elaborate further on this metaphor, software libraries should be carefully chosen and maintained by the technical team. The same applies to the workflows and processes in the company. No one software library works for all development projects, and no one workflow fits every software engineering team.

As a first step, make sure you understand and follow the existing organisational workflows yourself. As an individual contributor, you could sometimes think that they were an unnecessary bureaucracy. As a new Tech Lead, make sure it's not the case, or initiate the change. Workflows should serve the teams, not the other way around.

Give extra focus to workflows that put you in a gatekeeper position (for example, pull requests can't be deployed without Tech Lead approval). In rare cases, it may be a reasonable requirement, but usually, it indicates a problem.

👯‍♀️ Regularly check in with your manager

So now you keep an eye on the team. Start sharing your observations with your direct manager early, partly to let the problems bubble up. It can be a summary of what went well, what had to be fixed by you, and what requires senior management attention. One of the most important management rules is "No surprises". If you share the team status regularly, then senior management will be prepared to step in when necessary.

Funny enough, they may see your problems from various unexpected angles. Be open to that. Sharing your vision helps to align the priorities in both ways.

Example 1

You: I have to manually perform project deployments and take database backups. It's not a big deal for me, but I think it can be improved to follow best practices.

Manager: the project is growing fast, and the dev team should be prepared for frequent and safe deployments. Make DevOps initiative the main priority starting from next week.

Example 2

You: I have to manually perform project deployments and take database backups. I think it's a major team blocker (and this is just not a fun job for me).

Manager: there will be no more deployments for that project starting from next month. It will be replaced with the new development project which should be the main priority starting from next week.

You may say that the manager should have shared the details about the future of your current project sooner. Of course, they would share at some point or they might have already shared it but you missed the point.

From my practice misalignments happen all the time because everything keeps on changing. Sharing your successes and problems with your manager regularly will help both of you to have "no surprises", or at keep them at a minimum.

A final note that you should not be focused on problems only, otherwise your manager will start escaping from you.

Developer tasks

So, your team know the priorities, help each other when they have questions, and follow workflows to perform common tasks. You manager is aware of some problems that you faced and helps to fix them. Not everything is going so well, but you have a plan in place to improve things in the long run.

You still feel very busy and unproductive because you spend less time coding and more time planning and communicating.

🐌 Reduce your expectations

Some organisations explicitly set coding expectations for Tech Lead role. Others don't do that because it may depend on the team and the project at hand.

In either way, you'll have significantly less time for coding because:

You are expected to do some management
You are not good at management, and you need to learn how to do it well
You are performing technical oversight and switching context between several different tasks per day

Accepting this change was very hard for me. It took almost a year for me to understand that investing in my management skills will free up some time for technical tasks in the long term.

🥎 Pick small, not urgent tasks

When you include yourself in a sprint as a developer, prefer smaller tasks that don't block other team members. If it's not possible, then prefer pair programming or very close collaboration on a task so that someone else will be able to finish it without you.

🛩 Block time for coding sessions

This is a very common recommendation: book a time for coding in DND (Do not disturb / in airplane) mode, and everything will be fine. From my experience, it will indeed, if you follow all the other recommendations listed above.

I personally enjoy having 3-4hr focus slots at the beginning of the day, but we have our daily standup meetings in the middle of that slot. They immediately kill my focus as we start to discuss different aspects of the project, some problems and blockers that require my attention, and the new surprises that should be communicated up.

I accept this distraction because I find our daily standups very valuable from the management perspective. I could also skip, postpone or make them asynchronous. As a Tech Lead, when you make choices like this, you have to keep the organisation and the team as your priorities.

👏 Take off your Tech Lead hat

Normal Tech Lead schedule will not allow you to grow as a software developer at the same pace as it used to be. However, your technical expertise is crucial for running a technical team. Yes, you can learn from your teammates while reviewing the code. Yes, you can experiment with the code while you are working on your smaller tech tasks during your focus hours. Yes, you can read some blog posts in your spare time. Yes, you can build a pet project. It's great, but not enough for staying current in the modern IT world.

Tech Lead role isn't the final career destination for most of us. First of all, it's very challenging because you are a manager and a developer at the same time, and you are kind of okay at both. That's why folks often move on to full management or full development roles from this point. Your Tech Lead experience will help you succeed in either route.

Some companies periodically rotate Tech Leads in their teams. Others try to spread the management burden across the whole team ("🦄 No-Managers teams"). Finally, you can simply ask your manager to put you on another project for a couple of months. It may be enough to get refreshed and upskilled.

To summarise

It took me two years to realise that “How to find time to code?” is the wrong question for a Tech Lead. You should focus on getting better at management, and ask your boss to give you “management holidays” if you need to invest more time in your hard skills.

Tech Lead is a very challenging role, partially because we put a lot of pressure on ourselves and hesitate to ask our senior colleagues for advice. This experience is "unforgettable" as it changes your understanding of software development process. With this new understanding, you can do more either as a developer or as a manager.

Good luck!

Forem: Kate

It depends! Exploring my favourite Renovate features for dependency updates

How Renovate works

Feature 1: config presets

Feature 2: grouping related updates

Feature 3: lock file updates

Feature 4: Dependabot integration

Feature 5: Dependency Dashboard

To summarise

Budgeting my communication capacity

Meetups and conferences

Mentorship and coaching

Blogging

Reading

Working from the office

Things that didn't work for me

To summarise

Fast by default with Next.js

Table Of Contents

JavaScript Code Splitting

Preload JavaScript on link visibility

Dynamic import

Third-party scripts

Fonts

Images

Static optimisation

Edge Middleware

React Server Components and streaming SSR

To summarise

🔭 Three tricks to get in focus mode

What is the focus mode

Trick 1: "Is it technically possible?"

Trick 2: Microtask

Trick 3: Add flavour

And many more

To summarise

The road to Software Architecture (frontend edition)

My background

Software Architecture (as I understand it)

Learn your tools

Embrace folders

Testable code

What about design patterns?

Business logic

To summarise

Flutter guide for React developers

Table Of Contents

VS Code → VS Code

💡 Get started with the local development environment:

Chrome Dev Tools → Flutter Dev tools

💡 Get started with Flutter Dev tools:

TypeScript → Dart

💡 Get started with Dart:

ESlint → Dart lint

💡 Get started with linters:

div → Widget

💡 Get started with Widgets:

CSS → Widget

💡 Get started with Widgets:

Accessibility → Widget (again!)

💡 Get started with accessibility:

@mui → Material Components (MDC)

💡 Get started with Material:

Render → Build

💡 Get started with building custom widgets:

State → State

💡 Get started with stateful widgets:

npm → pub.dev

💡 Get started with pub.dev:

Redux + React Query → Riverpod

💡 Get started with Riverpod:

React Router → Go Router

Backend → Firebase

💡 Get started with Firebase:

React Testing Library → flutter_test

💡 Get started:

React Docs → docs.flutter.dev

What’s next

My approach to the command line

My favourite terminal shortcuts