DEV Community: Dominika Zając (she/her) 🇵🇱

AI, please stop guessing a.k.a. Chrome DevTools MCP

Dominika Zając (she/her) 🇵🇱 — Sun, 12 Apr 2026 18:51:50 +0000

Intro

We used to think coding was the most difficult part of an engineer’s job. Almost every engineer I know enjoys sharing tales of spending hours debugging, wrestling with stubborn syntax, or churning out countless lines of code to meet a deadline. However, our field has changed drastically in recent months.

Coding is no longer the main challenge. With AI tools like Cursor, Copilot, or ChatGPT, generating code is fast — sometimes too fast. The true bottleneck has shifted elsewhere: to understanding what the application is actually doing, reviewing code, and debugging code generated by AI agents.

Let’s be honest: most of us aren’t working on shiny, clean greenfield demos. We work on real systems used by millions of people. We can’t simply rewrite the entire system overnight, our documentation is rarely perfect, and sometimes we have to maintain that one module built a decade ago. There is always something more pressing on the roadmap than finally replacing legacy components.

This fact remains unchanged by AI: programmers spend significantly more time reading, extending, and fixing existing code than they do generating brand new code. Can AI assist with this, too? Yes, but…

Context is a key

AI is great at generating code but struggles with accurately interpreting reality. Without specific context, it often offers generalized, sometimes irrelevant, advice, similar to an uncle at family dinner who knows everything about politics, economy and every other aspect of life. For instance, when asked about performance issues, AI correctly suggests theoretical fixes like caching or checking slow requests, but often what engineers actually need is detailed, actionable data — such as which specific request is slow or which image is oversized, not general knowledge we all typically have.

To make AI truly valuable in daily engineering work, it must be grounded in reality by having access to real-time data:

The view from the browser.
The actual network responses.
Errors reported in the console.
Real-world user application behavior.

Fortunately, a solution exists: the Chrome DevTools MCP, which is designed to help.

Definitions

The Model Context Protocol (MCP) acts as a “universal connector,” similar to a USB-C for AI. It allows AI agents to “plug into” actual tools and retrieve structured data. This represents a significant transformation: instead of speculating, “hallucinating,” or requiring numerous follow-up questions, the AI can fetch concrete data, inspect systems, and validate its own assumptions by themselves, shortening the feedback loop.

Chrome DevTools is a well-known set of programming tools available in the Chrome browser. It’s totally free and developed by Google engineers. And what’s great — since September 2025 it has MCP, which means you can connect your AI agent to those powerful features and provide a way for AI to get real data about your app. All you have to do, is to add below snippet to your mcp.json file:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

What can it actually do?

The whole list of tools is available on the github repository but tools can be grouped into below sections:

Input automation
Navigation automation
Emulation
Performance
Network
Debugging

So it can click over the page, fill some forms, emulate different color scheme, cpu throttling, network conditions, different viewport sizes, run performance analyzes (including lighthouse audits), take memory snapshots, list all network requests, get console errors, take screenshots, accessibility snapshots and much much more!

Here are a few practical examples (aka: things that save your sanity):

Take screenshots — AI can capture the current UI state. Why does it matter? No more “it looks broken” descriptions, easier debugging of visual issues, and it is useful for regression checks. Especially helpful when something is misaligned, invisible, or “just slightly off” (the worst kind of bug).
Navigate the app — AI can open pages, click things, and simulate user flows. You don’t have to manually reproduce every bug; you can test user journeys faster or even speed up your testing by asking an AI agent to check all user flows without needing to specify all possible paths.
Inspect network requests — AI can analyze real status codes, payloads, and timing of API calls to, for example, instantly spot failed requests, detect slow endpoints, or debug CORS issues without guessing. As Chrome DevTools can also read console messages and take snapshots, it’s really useful when something is not visible in the UI or it’s presented incorrectly.
Analyze performance — AI can look into performance traces of slow renders, blocking scripts, and heavy components, so you can easily find real bottlenecks and improve performance based on real data, not theoretical assumptions. It can also start a Lighthouse audit before and after a fix to ensure that the proposed change really helped. Personally, it’s my favorite feature from Chrome DevTools — playing with performance is always tricky, and allowing AI agents self-healing based on immediate feedback is much more efficient and less annoying than checking things manually and providing those data back to the agent chat.
Connect to a running Chrome instance — What’s more, you can also connect it to a running Chrome instance (by default it’s opening a new one), so e.g. you can check some tricky case you started to debug manually or avoid problems with trying to automate login. You can find instructions on how to do it here: https://github.com/ChromeDevTools/chrome-devtools-mcp/?tab=readme-ov-file#connecting-to-a-running-chrome-instance

Of course there are many many more cases where it’s useful. But the pattern and idea are always the same. By connecting AI to DevTools via MCP, we give it eyes, so it can see what’s happening and hands, so it can interact with the app. And that changes everything.

Why do we need it?

Instead of playing ping-pong with an agent manually verifying their changes, you can delegate the problem to the agent, let them automatically check if the problem was solved, and auto-heal if needed. This provides much shorter feedback loops and much better results. What’s nice is that it also reduces the problem of starting the agent, going for a coffee, and… discovering an hour later that nothing happened as the agent asked for additional data and I forgot about the request (which, unfortunately, is often the case for me).

So what changes for us? Thanks to having smarter and less needy agents, we can reduce time spent on chasing typos, manually debugging requests, reproducing bugs or switching between tools. And we can have more time for things which are really important like architecture decisions, improving user experience and solving real users’ problems.

Or in simpler terms:

Let AI take our jobs (but only the boring parts). So we have time for things that really matter.

Is your repo ready for the AI Agents revolution? Checklist

Dominika Zając (she/her) 🇵🇱 — Mon, 30 Mar 2026 06:59:10 +0000

Intro

AI is probably the biggest buzzword around this year and last — it’s not just developers talking about it, it’s everyone! We’re seeing huge shifts in the programming world thanks to personal assistants packed with knowledge, tools that help us code, and autonomous agents. This whole thing is a mix of risks and cool opportunities. On one side, you’ve got the AI fans who are super excited about boosted productivity, getting more creative, and having millions of agents handle all the boring stuff for us. On the other, the cautious folks are raising valid concerns about data privacy, accuracy, and how this all affects our mental health. But here’s the deal: this change is happening, and we can’t hit the brakes. The best way to get ready is to jump in and be a part of it. So, I really recommend you try out, practice, and just play around with these new technologies. Keep an open mind, but also stay smart about the risks. That’s definitely what I’m aiming for!

For some time now, I’ve been exploring various AI tools, frameworks, models, and approaches, primarily focusing on existing (brownfield) codebases rather than entirely new experiments. My goal is straightforward: to find ways to make my work easier and more enjoyable. I don’t expect AI to write all my code or solve complex architectural challenges. Instead, I want it to handle the tedious, repetitive tasks, such as writing tests, fixing minor issues, or migrating outdated technologies. I ran experiments across different projects — in PHP, Node, React, and Java, encompassing both legacy and newer systems. Some were successful; others were not, and I plan to share more about these experiences in future articles. However, through this process, I recognized a critical omission in all the courses, tutorials, and articles I encountered: a simple, practical checklist for preparing a codebase to work effectively with AI agents. This checklist is what I’m sharing today. While you can just check the checklist below, I highly recommend reading the full article to fully understand the context and customize it to your specific requirements.

Disclaimer: Please note that I am a software engineer, not an AI specialist. The AI landscape is evolving rapidly, and I acknowledge that I may have missed certain developments or information. My focus is primarily on integrations with GitHub, Cursor, and Copilot, as these are the tools I use most often. While this checklist should be generally applicable, users of different toolchains may need to make minor adaptations. This article and the following tips are based on my personal experiences and may not universally apply. I encourage discussion and feedback — if you disagree with any points or feel something is missing, my DMs are open. I anticipate that this article will require updates over time, but I believe it offers immediate value in its current form.

The high-level goal

This checklist serves as an initial roadmap, not a definitive final product. You are encouraged to customize it to fit your project’s specific needs and development practices. However, it offers a simple guide to immediate steps for making AI agents more effective in your project. The structure is outlined below (in markdown so you can easily reuse for your projects):

# AI Readiness checklist

## Repository Hygiene

### Source Control & Ignore Rules
- [ ] Repository is integrated with Git (GitHub / GitLab / Bitbucket)
- [ ] `.gitignore` is added
- [ ] `.cursorignore` is added
- [ ] No secrets are hardcoded
- [ ] `.env` file is used and secrets are injected securely

### Automatic Linting & Formatting
- [ ] One formatter is configured and enabled
- [ ] Auto-format on save is enabled
- [ ] One linter is configured and added to the repository
- [ ] Linter runs in the CI pipeline

### IDE Setup & Extensions
- [ ] Modern IDE is used (Cursor / Antigravity / IntelliJ + Windsurf, etc.)
- [ ] Common shortcuts are configured (open chat, select lines, inject files, etc.)

### Standard Repository Commands
The repository provides a **single obvious command** for each action:
- [ ] Start the application
- [ ] Run all tests
- [ ] Run unit tests only
- [ ] Run e2e tests only
- [ ] Run the linter

## Testing Safety Net

### Unit and e2e rules
- [ ] Unit tests cover core functionality
- [ ] Test coverage is at least ~70%
- [ ] E2E tests cover critical user flows

### CI / CD & Code Review
- [ ] CI runs before every merge
- [ ] Linting, tests, and formatting are enforced in CI
- [ ] Code review is required before merge
- [ ] Merge Request (MR) template with a manual checklist exists (e.g. accessibility)
- [ ] (Optional) Automated AI-based code reviews are enabled (e.g. Copilot)
- [ ] (Optional) Automated repo checks are enabled (e.g. Jules agents)


## Grounding Documents

### Requirements & Intent
- [ ] High-level product specification exists in `.ai/requirements`
- [ ] Each new feature has a PRD in `.ai/requirements`
- [ ] (Optional) Out-of-scope features are documented in `.ai/requirements`

### High-Level Technical Documentation
- [ ] `architecture.md` exists in `.ai/docs`
- [ ] `tech-stack.md` exists in `.ai/docs`

### AI Rules & Guardrails
- [ ] `agents.md` with high-level AI rules exists in `.cursor/rules`
- [ ] Each framework/technology has its own rules file in `.cursor/rules`
- [ ] Cognitive-load reduction rules (e.g. 3x3 rule) are documented in `.cursor/rules`


## MCP Integrations

- [ ] Task management MCP (Jira / Asana, etc.) is added to `mcp.json`
- [ ] Design tooling MCP (Figma / Subframe, etc.) is added to `mcp.json`
- [ ] Database tooling MCP is added to `mcp.json`
- [ ] Browser tooling MCP (e.g. Chrome DevTools) is added to `mcp.json`

Let’s talk about those sections and rules in more detail.

Repository hygiene

Source control & ignore rules

Before you start throwing new AI tools at your codebase, you’ve gotta make sure your repository has the right basic setup. The name of the game is safety and making sure you can easily track and roll back any changes. Seriously, these simple points are crucial:

Your Version Control Setup:
- Git is Key: Your code needs to be fully hooked up with Git. Also, make sure your setup (whether it’s your terminal, your IDE plugin, or whatever else) is super comfortable and efficient for you to use.
- Hosting Platform: You need a platform like GitHub, GitLab, or Bitbucket. Personally, I highly recommend GitHub — in the last months it’s got some great features and integrations not available in other platforms, especially when you start bringing AI agents into the mix.
Essential “Don’t Look Here” Files:
- .gitignore: Non-negotiable. Use this to stop tracking files that are unnecessary or sensitive, like your .env file with all your credentials.
- .cursorignore (or similar): Add this file to tell tools like semantic search, code completion (like Tab), agents, and inline edits to totally ignore certain content. Files already in .gitignore are automatically skipped, but you can:
- Overrule It: Use the ! symbol if you do need an agent to see a file that Git is ignoring.
- Speed Things Up: Add extra rules to cut out irrelevant parts of the repo. It helps the indexing go faster.

Quick Tip: If you use Cursor, you can set up global ignore patterns in your user settings so you don’t have to configure it for every single project.

Secret Management (Seriously, Stop Hardcoding):

No Hardcoded Secrets: This is a basic security rule, but it’s even more vital now that Large Language Models (LLMs) are learning from and analyzing our code. Back in the day, early LLMs like Copilot were sometimes proposing actual secret values just based on common variable names — a huge security risk! You must stop your secrets from being suggested to anyone else.

Automatic linting and formatting

Setting up the right tools isn’t strictly required, but man, does it make a difference for the developers! It seriously improves the quality of life and saves a ton of time arguing during code reviews or when new folks join the team (you know, like that never-ending tabs vs. spaces war). You totally need a formatter. Just make sure it’s set up to match your project’s style. If it auto-formats when you save, developers won’t even have to think about it — it just happens! For trickier style and quality issues, a Linter is a must-have. Get it configured, and make sure there’s one simple command to run it. And the last piece? Your CI/CD pipeline needs to lock these rules down. Any pull requests that mess up the formatting or fail the linting checks should be stopped dead before they can merge into the main branch.

IDE setup + extensions

Investing time in mastering your IDE is a crucial, yet often overlooked, step — much like familiarizing yourself with a new phone/car or air-fryer. While coding in a Notepad is technically possible (I still remember when teachers taught us to code this way back at school), it’s not an efficient use of your time. Utilize a modern IDE specifically designed for AI-tooling. Tools like Cursor IDE and Antigravity are excellent options that offer significant functionality right out of the box with minimal setup. If you prefer your existing IDE (such as IntelliJ), at least install and learn a contemporary, AI-focused plugin like Windsurf.

Knowing the most common shortcuts will drastically improve your efficiency. For example, in Cursor:

Cmd r then Cmd s: Opens the command palette
Cmd i: Toggles the side panel
Cmd e: Toggles the agent layout
Cmd Shift L (with code selected): Selects the highlighted code as context for the chat
@: Selects a file as input
/: Runs a shortcut command within the chat

Sharpen Your Axe: Think of preparing your workspace as a reasonable investment to maximize productivity.

The repository provides a single obvious command for each action

Having too many options, like when you’re shopping or picking a restaurant, can actually freeze you up, turning simple decisions into a major time sink. You see the same problem in a ton of software projects: too many settings and options. They’re great for the “power users,” sure, but they’re a total headache for the average person who just needs the standard setup. To make sure your code repository is easy for an AI Agent to use and welcoming to new developers, you’ve got to keep it from getting crazy complicated. It’s fine to keep the deep configuration options for the advanced folks, but you absolutely must provide a simple, single-command way to run the most common, basic stuff. This straightforward approach will be a huge win for both Large Language Models (LLMs) and junior engineers just getting started with your code.

The Must-Have One-Command Tasks:

Start the whole app
Run every test
Run just the unit tests
Run only the end-to-end (e2e) tests
Run the linter

These commands should be front-and-center in your README and included in the usual spots — like the scripts section in the package.json for any TypeScript/JavaScript project. Cutting down on confusion is key to a smooth start for everyone: new engineers and AI tools.

Testing safety net

To get your repository ready for AI agents, after the initial setup, you should really focus on building a solid testing safety net so you don’t accidentally break your application’s logic. Trust me, you really want to throw down comprehensive tests before you dive into any major refactoring or logic changes to guard your code. This safety net keeps unexpected failures from popping up, especially those caused by “improvements” or changes from your shiny new AI agents. Don’t just cross your fingers; never assume code is too simple to fail, or that developers will manually check things after every agent run. Make sure you get super-fast feedback — tests are the shortest loop you can get, letting the agent quickly fix itself if it slips up and introduces a bug. Keep that code quality high by running these tests in your CI/CD pipeline. This is a must-do to stop buggy code from sneaking into production. Plus, well-written test cases are actually awesome documentation for both your human engineers and the LLMs.

While automating is key, let’s be real — you can’t automate everything. For those tricky bits, set up a clear manual process instead of just relying on “everyone knows this” or a gut feeling. Make code reviews mandatory by requiring approval from another team member (you can set this up in Github). Give them review templates with checklists for things you can’t automate (like more advanced accessibility checks). Automate all the grunt work you can to maximize efficiency so your human reviewers can focus their brainpower on the critical, nuanced stuff, not nitpicking a missing comma. Oh, and definitely use AI pre-checks! Tools like Copilot’s automatic code review or Jules’ scheduled regular checks are an easy, cheap way to get an extra set of eyes, which is super helpful, especially for smaller teams.

Grounding documents

AI agents are quickly moving past their initial “junior engineer” phase — they’re getting way smarter and more capable. The thing is, their training is based on tons of global data, so they don’t know the ins and outs of your specific app or tech stack yet. To connect their general expertise with your specific world, you need to introduce grounding documents.

Requirements & Intent

If you’re wondering where to put documents about your product’s logic, the .ai/requirements folder, usually right at the top of your repository, is a great spot. It’s not a super-official standard, but it works well for keeping a high-level product spec. This spec should clearly explain what the app can do, and just as important, what’s definitely not going to be included (out-of-scope). Seriously, listing those excluded things, especially when you have to cut scope because of time or resources, has been super helpful.

For those of you into spec-driven development, this is also the perfect home for your Product Requirement Documents (PRDs). PRDs should get into the nitty-gritty of every feature and function. They basically turn the product manager’s big-picture idea into actual code and keep the documentation handy. PRDs shine brightest in “greenfield” projects (brand new repositories). But if you’re dealing with an existing, “brownfield” project, a mixed approach is the way to go: keep a high-level doc for all the stuff that’s already solid, then use good PRD practices for new things, like fresh features or big code migrations to ditch old systems. This hybrid strategy works pretty well for me (at least for now 😛).

High-level tech documentation

These two files I propose you to add in the repo are basically the high-level, technical rundown of what the project is all about.

architecture.md

First up is architecture.md. Keep this one short, like max two pages. It sketches out the project’s architecture, and you can toss in links to more detailed stuff if needed. Right now, I stick it in the .ai/docs folder at the root of the repo, but honestly, I don’t know if that’s standard practice or not. Why architecture.md is useful? It’s the main reference point for AI agents when they’re tackling huge jobs, like moving everything over to a new technology. It’s super helpful for getting new engineers up to speed fast. It’s essential for showing exactly how data moves through the whole application.

tech-stack.md

The second document I think we should have is tech-stack.md. This is just a list of all the tools and frameworks the app uses. It stops AI agents from “hallucinating” or randomly adding stuff we don’t need (like bringing in a new unit testing library) by nudging them to use what’s already there. It helps make sure new code follows our chosen solutions, especially during migrations, although we can also manage this with those cursor rules files (more on those later).

AI rules and guardrails

While previous sections can be useful also in standard development, this one is strictly connected with AI. There are special techniques to improve accuracy, reduce time needed for changes, help with context window problems and ensure that AI-generated code fits your best practices and conventions.

agents.md

First of them is an AGENTS.md file, which serves as a readme specifically for AI agents. This is an open, simple format designed to guide coding agents, with various examples available on their dedicated webpage. You should place this file in the root directory of your repository. For monorepos, it should also be included in the root of subfolders. The AGENTS.md file should contain essential information such as:

Build and test commands.
Code style guidelines.
Testing instructions.
A high-level overview of the project. My additional tip is to not overfocus on creating this file perfect at the first run. Start with a working version and improve it gradually — you can always update the file later.

Cursor rules

I understand that not everyone finds “Cursor rules” appealing, but I personally consider them quite valuable. Cursor rules are concise markdown files, ideally under 500 lines, located in the .cursor/rules folder. They serve to provide agents with additional context about specific frameworks, technologies, or areas, you can also add some good and bad examples of given rule there. For example, a rule could mandate the use of functional components in React or enforce your internal design system. Another rule might define what should typically be covered in unit tests and what mocking strategies to employ. You should continuously refine these files. After extended sessions with an agent, prompt it to improve the rules, adding more context relevant to your objectives. The agent finds and uses these rules automatically, so you don’t need to add them specifically.

Cognitive load rules

This section was added to my personal workflows after completing the 10xDevs course by Przeprogramowani (hello, Przemek and Marcin!). I realized that while I was focused on improving AI performance, I neglected the importance of managing my own cognitive load, overfocusing on helping machines instead. Dealing with detailed change tracking, debugging, or reviewing hundreds of lines of code is exhausting. You can significantly ease this burden by establishing rules for the AI agent on when it should pause and ask for your review. This approach allows you to understand changes and adjust the code more frequently. A practical example is the 3x3 approach: instruct the agent to implement a maximum of three steps from the plan, briefly summarize the work done, and then propose the next three steps. While Cursor’s built-in agents have recently started doing something similar, it lacks predictability (yet?). To tailor this interaction to your needs, you should define a specific rule for it. These rule files can contain various other tips for collaboration. Simply consider your preferred way of communicating with the agent and ask them to follow those preferences in the rules.

MCPs

The Model Context Protocol (MCP) is an open-source standard designed to connect AI applications with external systems, often likened to the simplicity of a USB-C connection — a “one-fits-all” solution that eliminates the need for special converters. You can learn more here: https://modelcontextprotocol.io/docs/getting-started/intro. Its primary benefit is enabling AI applications to connect to data sources and perform tasks, essentially giving the Large Language Model (LLM) “hands.” This means the AI can move beyond just suggesting or proposing actions to actually carrying them out and learning from the results. This capability leads to:

Improved accuracy due to better context for the LLM.
Reduced development time.
Simplified workflows, especially when multiple tools are involved.
Getting started is very easy, typically requiring only a few lines of code in your mcp.json file.

While this area is rapidly evolving, a general approach is recommended. In my view, you will likely need MCP integration for:

Task management tools
Design tooling
Database tooling
Browser tooling

Your specific needs may vary — you might require fewer or different tools, especially if you specialize in a certain area. How to find good MCP candidates? Validate your existing working flows. Ask yourself: which tools do you use most often? What common tasks do you perform? What actions currently require you to stop the agent’s work, perform an action manually, and then paste the results back into the agent window to continue? These manual steps are excellent candidates for MCP integration. Given current trends, it’s highly likely that “there should be an MCP for that!”

Summary

This article is long, personal and opinionated. However, I hope it will help you build a “framework” to maximalize benefits from using AI-agents in your project. You absolutely don’t have to agree with everything here, so feel free to read through, think critically, and adjust these ideas to fit what your project actually needs.

“Plans are worthless, but planning is everything.”
~Dwight D. Eisenhower

Remember that famous Eisenhower quote, “Plans are worthless, but planning is everything.” Take some time to prep before you jump into “vibe-coding” and just throw random changes into the repo. A little foresight goes a long way toward avoiding huge messes, bad changes, and flat-out wrong calls. Your code, your teammates, and future-you will seriously appreciate the effort.

P.S. If you got something good out of this, please think about sharing it or dropping a clap/comment below to help other people find it. Thanks!

P.S.2 All pictures used in the article were generated using ChatGPT.

Can AI debug my AI-built web app? AI tools in Chrome DevTools

Dominika Zając (she/her) 🇵🇱 — Tue, 12 Aug 2025 05:20:01 +0000

Intro

AI is undoubtedly transforming our industry, and the words "artificial intelligence" have been on everyone's lips over the last year. Thanks to tools like Claude, ChatGPT, and Firebase Studio, not only programmers, but also people not directly involved in programming, such as my English teacher friend, a hairdresser, or a musician, can create applications. What happens, however, when an application doesn't quite work as we'd like, and our favorite AI assistant throws its hands up and refuses to help, despite being fed with more tokens? That's when a human with debugging skills must step in. In my personal opinion, these skills will be the most useful and indispensable in the future. The more code AI writes for us, the more important it becomes to have skills in reading comprehension, tracking changes, debugging, and fixing problems. Interestingly, even here, AI can prove to be useful!

AI features in Chrome DevTools

I don't think I'll surprise anyone who has ever worked with me, listened to my presentations, or read my articles by saying that I'm a big fan of Chrome DevTools – free developer tools built into the Chrome browser. You don't need to install them, they offer many possibilities, and they help me in my daily work almost every day. In previous articles, I wrote about lesser-known features like emulating vision deficiencies, generating CSS Overview, recording and replaying flows or things related to improving performance. In this article, I would like to focus on something else – AI features.

Overview

For some time now, Gemini has been integrated and built into Chrome DevTools. It's currently available in the Console, Styles, Performance, and Network tabs, but I wouldn't be surprised if they add more. In a nutshell, the new capabilities allow you to chat with Gemini, analyze the page, and suggest improvements. This is turned off by default because, like any AI solution, it can of course suggest incorrect things. Importantly, the data we enter can be used to train the model, so it's worth thinking before sharing personal or sensitive data.

How to setup your toolbox

To enable AI features in Chrome DevTools, you must manually activate them as they are not enabled by default. Users need to be at least 18 years old, located in a supported country, and use Chrome DevTools in English. A stable version of Chrome is sufficient - the Canary version is not required. Navigate to Chrome DevTools > Settings > AI Innovations. Here, you'll find 3 options: to enable Console Insights, AI Assistance and Auto annotations. Simply enable the option you want to use (I recommend all of them).

Console Insights

It’s a simple but powerful feature. When an error appears in the Console, AI can help understand it and suggest corrections. Just hover over the error and click the lightbulb icon, which expands into an “Understand this error” button. After a few seconds of analyzing the error and the page's code, Gemini will explain the problem, suggest ways to check it, and offer a solution. There’s also a TLDR option for those who prefer the short version. At the bottom, you’ll find a summary of the data used for the analysis. A useful feature is also the Google search button, for when AI can't find a solution. Even if the tool doesn't always provide an ideal solution, in my experience it's almost always a good first step to summarize the problem, understand what's wrong, and what debugging options are available. It's also helpful when there are junior developers on the team – they can quickly learn stuff. I definitely recommend trying it next time you see a scary red message in the Console.

AI Styling assistant

Who hasn't struggled with CSS? Even a small change can often cause a cascade of problems. And it's even worse when an AI assistant wrote the CSS, and now you have to guess what it was thinking! Luckily, AI features in Chrome DevTools can help. You can right-click on any element in the Elements tab and find the "Ask AI" option. Interestingly, once the conversation opens, you can also add a screenshot using the "Take screenshot" option (the camera icon). This lets you start a conversation with Gemini and ask for help – even with tough things like centering an image. Gemini is helpful with layout and positioning issues, element visibility, styling, box model problems, CSS cascade, and much more. It can even override your styles in Chrome to preview changes, so you can easily test them. If you have a workspace folder connected, changes will also be saved there after using the "Apply to workspace" option. It has context of the webpage, so it's great for finding and fixing problematic spots.

AI in Network tab

Sometimes we hit snags with specific requests – maybe it's taking too long, or it's returning some weird code we don't recognize. The cool thing is, when you spot it in the network tab, you can just right-click and hit "ask AI." That opens up a chat with Gemini, and it already knows all about that particular request. Since you're the one giving it prompts, you can get pretty creative with how you use it. A super common scenario would be asking how to make that request more efficient. It's really handy for getting a quick initial look at what might be going wrong and figuring out next steps.

This yellow button close to the request name is another entry point to open AI assistance

AI in Performance tab

Performance is a huge topic, and there's almost always something you can improve. So it's worth checking out what AI has to say, even if you're quite happy with your site's results. In Chrome DevTools, you should first create a profile – either automatically on reload or by recording it yourself – and then chat about what was recorded in that profile. Personally, I usually ask about specific entries in the performance trace to better understand the details of a given item, but of course, we can also ask about the whole trace view and, for example, ask for an initial selection of areas for deeper analysis. We can also go to AI from the Insights tab as well if we want to learn more about them or expand on the suggestions made there. Very generic entries like "how to improve performance" might give you some pointers, but the magic happens when you want to work on a deeper level.

There is also a small but nice AI feature useful when debugging requests - generating labels for events in Performance tab. If you struggle with finding good naming (which is the one of the most difficult things in programming, right?), you can double-click on given item in Main view in Perfomance report and autogenerate it. Small but nice improvement!

AI in Sources tab

Honestly, I don't use this mode much, but it's still worth mentioning. In Sources, you can right-click and select "Ask AI" to prompt within the context of a given file. You can ask it to analyze the file, change logic, generate a snippet, etc. Personally, I prefer to do these things from my IDE, but I believe it could be useful if, for example, an extra package gives you a weird file and you want to understand it better, you need to check something quickly, or for some reason you don't have direct access to the source code. It's not a game-changer for me, but maybe you'll find some cool use for it – if so, let me know!

Summary

This article shows off how much easier debugging can be when you use AI tools. These tools are super handy already and are only going to get better. The AI in the Styling tab, for example, has been a huge help for me with tricky problems. Adding these AI-powered tools to your set of skills is a smart move, because debugging is only going to get more complex. By letting AI take care of annoying stuff like finding typos or double-checking syntax, we can focus on what's really important: providing value to our users.

Jules - The AI Agent I'd Happily Delegate My Least Favorite Tasks To

Dominika Zając (she/her) 🇵🇱 — Tue, 15 Jul 2025 07:30:18 +0000

Intro

Will AI take my job? I hear this question really often recently. But my reaction may be surprising for some people because typically my first reaction is… “Yes, please!”. But it’s not for everything – it’s about the repetitive, boring, not-creative parts like writing unit tests, documentation, patching vulnerabilities (where Dependabot/Renovatebot is not enough), etc. Fortunately (for me), AI is revolutionizing how we work, and I really hope it will do the job I don’t like to allow me to focus on things I love + delivering real value for the clients.

So… to achieve my goal of delegating “stupid” work to AI, I am really interested in background agents and was happy when I learned that Jules from Google is available. Jules is an async development agent that is integrated with GitHub and can fix bugs, add documentation, build new features, etc. Right now, it’s limited to GitHub, which is a problem in my case since the majority of my projects are in GitLab, but I really hope it will change soon. This async part is important for me, so I can, e.g., delegate tasks to write tests, go for my dancing lessons, and check results when ready, without looking at my computer. Also, multiple tasks can be run simultaneously (up to 5 tasks at the same time and 60 total tasks per day). For now, this tool is in beta, so you can try it for free, but it will be paid in the future - we don’t know the final prizes yet. Jules claims not to train on private repositories' data. What’s nice, we can add some configuration per project - e.g. to show initial setup and add repo commands (e.g. adding we prefer npm over yarn etc).

Offtop but... each time I schedule some agents to do my work I feel like Snow White from this picture (originally from Disney movie, here posting after https://kulturadobra.pl/krolewna-sniezka-i-siedmiu-krasnoludkow/)

Experiment assumptions

To assess Jules's capabilities, I focused on common development tasks I find challenging or repetitive:

Documentation: Adding comprehensive documentation.
Testing: Implementing unit and integration tests.
Dependency Management: Upgrading outdated dependencies.
Security & Accessibility: Identifying and resolving security and accessibility issues.
Feature Development: Integrating new features (a task I enjoy, but essential for a complete comparison).

I applied these criteria to three distinct projects:

Small Legacy Project: A hybrid mobile application built with Ionic and Angular, approximately three years outdated, featuring two simple views.
Medium-Sized Personal Webpage: A personal website developed using Scully and Angular.
Medium-Sized Full-Stack Application: A full-stack application leveraging React, Next.js, and Firebase.

While these projects may not be entirely representative of all development scenarios, my choice was influenced by GitHub's limitations and my familiarity with each codebase.

Additional assumptions for testing:

Use the same prompt for each project.
Use metaprompting before putting a prompt to ensure it’s OK.
Ask in the context of the whole project, not specific files (asking for files should probably be better).
Judged subjectively by me + automated review by Copilot.
Each category scored between 1 and 5 points.

Disclaimer:

There are so many new approaches and tools each week that it’s impossible to stay up-to-date with everything. Having a full-time job, a personal life, and a new hobby (Lindy Hop is amazing!), I experienced huge FOMO recently, and I know that this article may not cover everything. But I decided to write it anyhow in case someone else is looking for ideas to remove legacy/KTLO/improve engineering quality of life using AI. (My professional goal for the next few months is to focus on those aspects, so you may expect more thoughts in this direction). If you see that something is outdated or you know something that can be better than the approach described here - let me know! Add a comment here or write to me on X or LinkedIn.

Let’s start testing!

Onboarding is well-described in the docs, so I won’t repeat it.
You can start a task from the UI or from a GitHub issue by adding the label 'jules'. You need to describe what changes you want to apply, choose which repository it should apply to, and what the main branch is. You can give Jules permissions for all repositories or only for selected ones. After a few seconds, it will create a plan of action for you, which you can approve or change, and then start working on the changes. In the end, it will create a PR with proposed changes.

Results of my testing

What are the results?

Autogenerate documentation - 4.5 stars
Add unit tests - 3 stars
Upgrade dependencies and remove unused ones - 4 stars
Check for security/accessibility problems and fix them - 3 stars
Add a new feature - 5 stars

While the results weren't perfect, they were promising. The webpage experienced slowdowns when running five simultaneous tasks, and occasionally, loaders incorrectly indicated task completion. However, these issues were not blockers as a simple page reload resolved them. Let's deep dive into the specifics of each area.

Autogenerate documentation - 4.5 stars

I asked Jules to generate all documentation without specifying what exactly was needed. It added/adjusted readme.md, added CONTRIBUTING.md with rules about collaboration, and DEPLOYMENT.md with rules about deploying, plus some super high-level architecture with diagrams. In cases where a readme was present in a scrappy form before, it was great – it could reorganize it, add additional info, etc. When a readme was not present at all, it was super generic – e.g., it had a git pull command with example links like git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY instead of a real address. It also added a typo in one of the addresses – "httpss" instead of "https" even if in the original code it was correct. The architecture was too generic and verbose for me, but maybe that was because those projects were really simple, and it’s hard to write a lot of interesting stuff. Still, it could have written a concise, short note instead of an elaborate one. What positively surprised me was that the tool rejected generating Swagger documentation where it was useless – even if I followed up with a specific question to do so. Jules explained that it’s not needed for a frontend application, asked what I wanted to achieve, and proposed to improve the documentation of existing code instead. General score? 4.5 points on a 5-point scale. It’s not perfect and requires review, but it certainly simplifies my work and helps me save time. I will use it for sure in my projects.

Add unit tests - 3 stars

This was a difficult task, as testing frontend/mobile is more challenging than backend APIs, and my repositories are mostly frontend-focused. In my legacy project, Jules was unable to get tests running (it’s really old code with a hybrid mobile app with no test setup, so I can totally understand it ☺️). It tried multiple different approaches, checked Chrome and Firefox before failing and asking for human help. It’s good that it could stop itself instead of running out of tokens or costing me a lot of money if it were a paid feature. To be honest, it’s the same result I would expect from a junior engineer, so I’m not really surprised. All in all, the old truth about AI is still valid: the more cases you have to train your model, the better the output. And who writes unit tests in legacy projects? 😂

For the two remaining repositories, the results were much better. In the repository without any tests at all, Jules created a base setup and simple test cases. Sometimes it over-mocked in my opinion, but it wasn't super bad. I achieved the best results for the repository with existing tests and setup - Jules was able to follow existing conventions and add tests to achieve the expected complexity. It also provided tips to improve existing ones. It’s worth mentioning that this aspect took longer than other tests - Jules tried many approaches before the final result and often needed to change something to make tests run. However, it happened in the background, so I didn’t have to approve each change or ask it directly to re-test. Final score? 3 - good for modern codebases, especially with an existing setup, but not recommended for old ones. Probably adding initial setup + some documentation on how to run tests should be on the human side, while Jules can add test cases to an existing setup.

Upgrade dependencies and remove unused ones - 4 stars

I know that tools like Renovatebot are excellent for updating dependencies, but I was curious how Jules would handle this task, especially when breaking changes were introduced – would it be able to fix problems? It’s not surprising that it was much easier in modern repositories than in legacy ones – not only because of more data to be trained on, but also simply a lower number of vulnerabilities to address. In the legacy repo, it tried to bump a few major versions at once, and you can imagine how that ended... But let’s be honest, the prompt “upgrade all dependencies” is too generic. I received much better results when I asked to bump packages one by one and only one major version at a time (which should be part of the initial prompt). And the poor testing suite didn’t help in this scenario as well. For newer repositories results were OK - packages were updated, tests are still running, some changes to adjust to major bumps were done. Would I just release those changes to production? Of course not, but it was a solid work - Jules receives 4 stars from me in this area.

Check for security/accessibility problems and fix them - 3 stars

What to do when we don’t know what to do? Audit! And asking about security/accessibility problems we might overlook is something I do very often with different tools. Jules recognized many small problems within the code: missing aria tags, using divs instead of correct elements, places vulnerable to XSS injection, and… Not only was a committed (for test purposes) token not removed, but it was even shared between files! That really made me laugh and confirmed we can’t blindly trust AI. Or we should verify one model with another, as Copilot correctly highlighted that. Some of errors were also skipped - e.g. Jules replaced divs functioning as buttons to correct format but skipped those behaving as images. To be honest, I have a problem with the score in this case. I should give a 1 because of such a crucial problem with the token, but on the other hand, it was a solid 4 in other areas. I finally decided on a 3, but hope that Jules will remember in the future not to expose tokens (should I force it to write it on the blackboard 100 times to recall?).

Add a new feature - 5 stars

This category definitely showcased the power of Jules. I asked for adding small, funny features like additional confetti animation after performing a given action. Jules added new code, tests, and documentation, mostly keeping patterns from the existing codebase. At first, I provided specific input, mentioning in which file I wanted to add changes, which package to use, etc. But Jules was able to successfully finish the task even if only super generic commands were provided. While I don’t want AI to take my joy of programming, I have in mind some tasks from Jira I could just delegate to AI to save my time :P I will use this option for sure!

I didn't fix this image by purpose cause it's good visualisation of AI capabilities. It's really good but... not perfect - made it working after few additional attempts

Summary

After those subjective tests driven by domi-thinking-metodology (professors from studies please forgive me for my non-scientific approach!) I still believe and Jules is a nice tool and I want to include it into my toolkit, especially for delegating tasks I dislike. I'm not looking for it to create new features, but rather to handle the DevOps and operational work I'd rather avoid. While not yet perfect—it lacks GitLab support, struggles with areas like adding tests to legacy codebases or doing stupid stuff like sharing a token instead of redacting that—it still saves me time, allowing me to focus on delivering value. I'll definitely keep an eye on its progress. Currently, I view it as a junior engineer: full of theoretical knowledge and eager to explore different methods, but benefits a lot from more specific guidance and always needing additional code review before applying their changes.

I sincerely hope this AI trend will extend beyond generating new features in entirely new codebases (a rare occurrence in mature enterprise organizations) and instead prioritize tools for enhancing existing code and augmenting current workspaces. Ultimately, I hope it will take on more of the tedious work, freeing me to concentrate on delivering genuine value to users and, of course, pursuing my passions! Let's delegate the boring stuff to AI and have some fun!

PS: All images used in the article were generated using Gemini

Trusted Web Tester certification — what is it and is it worth your time?

Dominika Zając (she/her) 🇵🇱 — Sun, 05 May 2024 11:25:14 +0000

Photo by Christin Hume (https://unsplash.com/@christinhumephoto) on Unsplash (https://unsplash.com)

Introduction

From February you can find a new accessibility certificate on my LinkedIn profile — the DHS Trusted Tester certification. It proves I finished and passed the final exam of the accessibility course conducted by the Department of Homeland Security (DHS)’s Customer Experience Directorate. And since then many people have reached out to me to ask about it, an exam, learning materials, etc. That’s why I decided to write an article and summarize my experiences with it. Hope it will help you decide if you also want to go this path.

What DHS Trusted Tester Process is?

Section 508 Trusted Conformance program was created by the American Department of Homeland Security (DHS)’s Customer Experience Directorate (CXD), formerly known as the Office of Accessible Systems & Technology (OAST). It’s a try to introduce a standardized process of testing web pages according to Section 508 — accessibility law based on WCAG. From the future Trusted Tester side, the process is combined training, a mock exam, and the final exam. What is worth mentioning — the training and certification are:

free — which is not so common in the tech world,
remote — all you need is a stable internet connection,
flexible — you can start it whenever you want and you have unlimited time to finish the training.

To start, you must visit the official page and register for the program. You don’t need prior knowledge about accessibility before joining the program, however, it requires basic knowledge of HTML, CSS, and JavaScript.

Sometimes we use shortcut a11y when talking about accessibility — here you can see why!

Training

That’s the longest part of the course. You start with some theory about web accessibility, legal requirements, and the reasoning behind why it’s so important. Each lesson includes a short quiz at the end, which you must pass to proceed to the next chapter. Following that, you continue into more practical lessons, which are the most beneficial part of the course. Here, you’ll receive concise information about each aspect to test, the process of what and how to test, and how to report findings. Additionally, you’ll encounter examples of non-compliant, compliant, and failing webpages in this regard. To advance to the next chapter, you must test the demo page against a given aspect (test cases are randomized to prevent simple guessing).

Exam

Let’s be honest — no one enjoys exams. And I hoped that after completing my Masters, I wouldn’t have to stress again 😅 However, this exam isn’t so bad — you can take it from the comfort of your home, wrapped in your lucky blanket with your favorite tea in hand. It’s an open-book exam, so you can use any notes and materials you want (though without assistance from others, of course). The exam is practical, and this format makes a lot of sense — you’re given a webpage and tasked with conducting an audit of it. To receive the link for the real exam, you must first pass a mock exam, which is very similar to the final one but on a different webpage. Once you pass the mock exam, you should send an email and await the link for the actual exam. Upon accessing the exam page, you have three days and three attempts to complete it. You need to score at least 90%, but with subsequent attempts, you only need to review the criteria you marked incorrectly in previous attempts. The page is randomized for each attempt, so even if it appears the same or similar, you must evaluate it carefully each time. What surprised me the most was the time I needed to prepare — official instructions recommend allocating six hours for the first pass 😲 I managed it in about three hours, but it took much longer than I expected. So it’s good to be prepared for that. All in all, I think this format is quite good — it focuses on practical aspects and doesn’t require memorizing useless information (yes, I like open-book exams). Since the course and certificate are free, you can try it without consequences.

Certificate

When you complete the entire process, there’s one more thing to do — receive your certificate and share it with the world (including potential employers). In my case, this part unfortunately took quite some time — contacting the certification organizers was quite challenging. Fortunately, after a few emails and phone calls, I managed to obtain it.

Each DHS Trusted Tester receives a certificate similar to mine

The certificate you receive is valid with no expiration date. You’ll receive it in online form via email with a unique number — you can use it to verify that you are a Trusted Tester and to sign test reports conducted by you (validating that they were conducted by a person with the mentioned certification). Of course, you can also print it and hang it on the fridge — to remind yourself that you did a great job during the 70+ hours of training and the challenging exam! After receiving this diploma, you should be proud of yourself!

Do I recommend it?

After all that information there is still one question that needs to be answered — do I recommend passing this certification? The answer is not simple — it depends. If you are a QA specialist, accessibility passionate, or looking for a way to improve your skills in this area, then definitely can recommend it to you. The same if you are a front-end developer looking for a way to enhance your CV or want to understand accessibility certifications. However, this course is not the best if you are looking for info not only on what to test but also how to implement it correctly. We still don’t have clear and solid standards in web accessibility and this course does not define coding standards either (as it’s a program for testers). On the other hand, even if I am really interested in accessibility it helped me organize my thoughts and knowledge so I found it useful and will return to testing materials when in doubt. So, the decision is yours but if you have some spare time — give it a try!

Let’s make the Internet a better, more accessible world where everyone feels welcome!

PS. If you like this article or found it useful, please, leave some comments below or share it with your friends. Thanks in advance!

Can it work faster? Aka how to use Chrome DevTools to improve your webpage performance

Dominika Zając (she/her) 🇵🇱 — Sun, 20 Aug 2023 10:55:25 +0000

When you are a doggie you don’t have to worry about performance and e.g. take a nap when you are waiting for something. Unfortunately, as a developer, you have to think about impatient people and the performance of your website. Source of the photo: https://www.instagram.com/basenji_ginger/

Can it work faster? Almost every front-end developer has heard this question at least once. And let’s be honest — in a majority of cases, it’s a good question. Our web apps are more interesting, more complex, more powerful but also… slow! And when I recently spent one week in a place with super poor internet I painfully experienced that… Fortunately, there are many tools that can help you identify and fix performance problems on your webpage. In this article, I wanna show you those which are available for free and without installing anything inside one of my favorite tools — Chrome DevTools.

Chrome DevTools Overview

Let’s start with a super short Chrome DevTools overview. It’s a set of developer tools built into the Chrome browser, available completely for free. To start using it you just need to open the page to test in Chrome browser and open Chrome DevTools. You can do it in many ways:

Right-click on any element on the page and choose Inspect option from menu
Use 3 dots menu in the top right side of the browser -> Choose More tools and later -> Developer tools option Use the shortcut (ctrl + shift + I on Linux/Windows or cmd + shift + I on Mac) After that, you’ll see a panel similar to the one visible in the screenshot below:

A screenshot of Chrome DevTools opened on the Elements tab

Some time ago I wrote about using it for debugging HTML and styling on your webpage and less known features hidden in this tool, so if you want to check some basics look at those links. Today we’ll focus only on features connected with performance.

Lighthouse Audit

Let’s start with something simple. What is your first action when you had to improve something? For me it’s always understanding the starting point — a good audit in the beginning help me understand:

the whole picture (are we in a critical condition? or maybe we just need some small fixes?)
the biggest pain points (what annoys my user/me the most?)
low-hanging fruits (are there easy-to-perform fixes that can significantly improve the situation?)

There are many tools available on the market which provide performance audits but here we’ll use the Lighthouse option from DevTools. To perform an audit you need to:

open your webpage in the Chrome browser
open Chrome DevTools (as described in the first section)
Go to Lighthouse tab
Choose Mode, Device, and Categories options (of course, including Performance option)
Click Analyze page load button.

Note: It’s recommended to perform this audit in incognito mode to avoid the influence of e.g. cache to your test.

Generating a Lighthouse performance report

After a few seconds, you’ll receive a report similar to what is visible below. At the top, there is a summary with a score and the overall result.

Example of performance report created by Chrome DevTools

The widget is presenting the overall performance score. The scale is 0–100 where a result below 50 is bad, 50–89 is average and you want to achieve 90 or more points. I won’t go into details about how this score is calculated (you can read more about it in the “How the Performance score is weighted” article on the official Chrome blog) but what I recommend is taking a look at Lighthouse Scoring Calculator — the link to it is just below widget with your score.

Lighthouse Scoring Calculator shows you the weighting of different metrics and gives you an opportunity to simulate how improving metrics given metrics may influence your total score.

As you can see on the screenshot above you can play with different values and scores for metrics and simulates how it will impact your score. It may be useful to determine which metric should be improved first (as let’s be honest, in real life we rarely have time to fix everything). But there are also some other parts in the report which may help you with that. Let’s go back to the report.

Metrics are great indicators of your’s page performance

The second section shows a summary of the most important metrics: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, and Speed Index. As you may guess the green color of the value means it’s good, orange suggests it should be improved and red shows serious problems. What do they mean?

First Contentful Paint (FCP) — this indicator checks how long it takes to render the first DOM element on the page.
Largest Contentful Paint (LCP) — this one measures how long it takes to render the largest text block or image on the page.
Total Blocking Time (TBT) — measures how long a page is blocked after user action (click, keyboard press, etc). The sum is calculated from all tasks over 50ms between First Contentful Paint and Time to Interactive (only excess over 50 is taken into account)
Cumulative Layout Shift (CLS) — measures unexpected shifts of visible page elements
Speed Index (SI) — measures how long it takes to display text and images on your webpage during load

Of course, also here DevTools can help you understand metrics. Click the “Expand view” button and you’ll see short summary of metrics and links to articles explaining in detail how they are calculated, why they are important, and how to fix them.

An extended view is helpful, especially for beginners.

A lot of data, don’t you think? Let’s add even more: below metrics you have buttons to see Treemap and Original Trace. The first one visualizes your JavaScript bundles (helping to e.g. discover unused bytes), and the second opens the timeframe of load in the Performance section of Chrome DevTools (we’ll talk more about this section later in this article).

Treemap view visualizes the size of Javascript bundles and helps find e.g. unused bytes.

OK, we have a lot of data but the question is — what can we do with them? Information is powerful only when we can use them. Let’s take a look at the next section in the report: Opportunities and Diagnostics.

Don’t know where to start improving the performance of your page? Take a look at the Opportunities and Diagnostics sections in the Lighthouse report.

Each item in those sections can be extended to show more details and link to the article explaining why it’s important. Sometimes it’s also displaying a list of elements that are influencing a given metric.

An extended view of the element in the Diagnostics section shows much more data needed to fix the problem

Note: remember that suggestions from Opportunities and Diagnostics can help load the page faster but don’t directly affect the Performance score.

Notice there is also a filter helping you see items only connected with a given metric. If you are a beginner you can additionally take a look at the Passed Audits section to understand which factors are also important for the performance of the page. And that’s all from the Lighthouse audit. But that’s not the only tool in Chrome DevTools that can be used to improve performance. Let’s take a look at the next of them: Performance Insights.

Performance Insights

Performance Insights is a still preview feature but I strongly believe it should stay in Chrome DevTools. Why? Because it significantly simplifies work with performance for developers. You don’t have to fully understand all metrics described in the previous section (even if that’s helpful) to start work. Just:

open Chrome DevTools
click the 3 dots button in the top right corner
Select More tools and Performance insights

I recommend checking this “More tools” section from time to time — you may be positively surprised!

After that, you’ll see the interface below.

Have you seen this view before? If not, you should definitely take a look!

Here you can parameterize the audit. You can choose Network and/or CPU throttle, and disable cache.

You can also choose if you want to focus on page load or custom scenarios by clicking the dropdown close to the “Measure page load” blue button.

After running the audit, you’ll see a report with a timeline of the most important events.

Report generated from Performance Insights tool

You can replay that (at a different speed), show/hide screenshots or click on a given task to show its details. There is also a small gear icon in the top right corner helping you adjust settings. But what I like the most is the Insights/Details section on the right. You can see a list of the most important events there and with visual marks for e.g. First Contentful Paint, Largest Contentful Paint, etc. When you want to investigate e.g. given long task found before First Contentful Paint you can click on that to preview Details (the given item will be also highlighted in the timeframe on the right so you can easily localize that). Tips on how to fix the problem are super useful!

You can also use Import/Export icons at the top to save the report for later.

Performance tab

In the article describing improving performance with Chrome DevTools, I cannot forget about Performance tab as it was created especially for that! But to be honest I see this view as very complex and don’t recommend starting with that — unless you are an experienced developer and you know what you are doing. Personally, I use it only when need details not visible in previously described sections. This tab is providing a sophisticated overview of all events on your webpage. To start recording:

open Chrome DevTools
go to Performance tab
Click the recording icon in the top left corner to start recording your custom script or the reload button to record loading the page Note: It’s best to perform the audit in incognito mode.

The view of the Performance tab may be a little overwhelming for beginners but when you understand the basics it’s an awesome tool to dig into performance details.

As you can see, there are many details visible on this page. You can decide if you want to record a custom scenario or page load, you can also import/export profile from the disc. Clicking the gear icon in the top right corner you can also set additional settings — like throttling, enabling advanced paint instrumentation, etc. What’s nice, in network throttling you can not only choose one of the predefined options but also create a custom profile. There is even a small trash icon forcing garbage collection during recording a page!

When the report is ready, you can use selectors from the left or/and right side to narrow down the time range you want to focus on (you can take a look at the time at the top or screenshots of the visible content). The donut chart at the bottom in the Summary section will show you a breakdown of the activity, so you can see how big percentage of events was connected with Loading, Scripting, Rendering, etc. You can also switch tab to e.g. Bottom-Up to see which task took the most of the time (and see its subtasks).

Talking about tasks — when you expand the Main section in the chart you’ll see a call tree of all tasks. The red rectangle in the top right corner of the most parent task informs you that this task was marked as a long one and probably needs some improvements. You can read more about optimizing long tasks in the great article written by Jeremy Wagner.

When you are looking for some specific task you can use a search box visible after clicking Ctrl+F or Cmd+F keyboard shortcut. You can even use regexes there.

There are much more data visible in the chart — you may be interested in looking at the Frames row (for detecting e.g. frame drops), the Timings (showing important metrics like Largest Contentful Paint, First Paint, DOMContentLoaded Event, etc), and the self-explaining GPU section. I won’t describe all information visible in the Performance tab here (as this article should be 5 times longer then) but strongly recommend using this tab when debugging performance issues on your webpage!

Performance Monitor

Now, time for the Performance monitor tab. It’s a feature that allows you to receive a real-time view of different performance aspects like CPI usage, JS heap size, DOM Nodes, JS event listeners, and more. You can open it via a few steps:

open Chrome DevTools
Click the 3 dots menu in the top right corner
Click More tools and Performance monitor

After that, you should see a view similar to the one below.

Screenshot of performance monitor tool — there are few metrics and timeline displaying state of each of them in real-time

You can interact with your page and check how your actions will influence the scores. You can also click on the names of metrics to hide/show them in the chart on the right side. Unfortunately, it won’t give you any recommendations on which values are OK and which are not so it’s up to you to figure out what’s happening and if is it right. It’s why I recommend this view only for more advanced programmers.

Extras

All the things I presented till now are big features having their own tabs. But there are also smaller ones worth mentioning here! Here I’ll describe 2 of them: Paint flashing and Scrolling Performance Issues.

Paint flashing

Paint flashing is a great mechanism to visually check if only the required elements are repainted on the page (and helps to detect during debugging e.g. which component is constantly re-rendering). When it’s turned on, you can use your page or navigate through it and repainted elements are marked in green.

To enable this option:

Open Chrome DevTools
Click the 3 dots menu in the top right corner
Choose More tools and Rendering
Check the tooltip close to Paint flashing option

Thanks to Paint flashing loader is marked in green and it’s easy to understand which components are repainted. This example is simple but it makes a huge difference on complex webpages, especially when re-render is unexpected.

Scrolling Performance Issues

In the same Rendering tab you can find also another interesting option called Scrolling Performance Issues. When enabled, it marks elements that can slow down scrolling. It’s a small but interesting feature — I don’t use it super often but helped me a lot while investigating more difficult problems.

Thanks to enabling the Scrolling Performance Issues option we can see that this search box is repainted on scroll and may slow down scrolling.

Summary

I know this article is long — but it’s because the topic of performance is so interesting and difficult! There are definitely much more features in Chrome DevTools and tips you can take to improve your webpage. But I hope that those described in this article we’ll help you. If so — leave some comments or share it with friends. Thanks in advance!

How to use Chrome DevTools to debug HTML/CSS on your webpage — intro for beginners

Dominika Zając (she/her) 🇵🇱 — Sat, 25 Mar 2023 17:50:15 +0000

Today’s article is addressed mainly to those who are starting their journey in IT. Recently, I work a lot with people who are learning their first programming language or want to switch careers to tech and I noticed that many tutorials are showing how to build stuff but almost never how to read existing code, debug mistakes or find a way to fix a bug. And it’s surprising as in “real life” we often work with existing codebase (adding a new feature, fixing bugs, changing business logic, etc) than writing the code from the scratch. Also, it’s super important to know ways to find a problem in your code — not only go step by step from the tutorial. In this article, I want to show you some features available for free in your Chrome browser which can help you address those problems. I hope it will inspire you to experiment more with programming and become a better developer!

What Chrome DevTools are

Let’s start with a short intro about Chrome DevTools. It’s a set of developer tools built into the Chrome browser and available completely for free. To start using them you just need to open the page to test in Chrome browser and open Chrome DevTools. You can do it in many ways:

Right-click on any element on the page and choose Inspect option from menu
Use 3 dots menu in the top right side of the browser -> Choose More tools and later -> Developer tools option
Use shortcut (ctrl + shift + I on Linux/Windows or cmd + shift + I on Mac)
After that, you’ll see a panel similar to the one visible in the screenshot below.

Tip: Your panel can be visible as a separate window or on the right/left/bottom side of the page. If you want to change that, find the 3 dots menu in the top right part of the Chrome DevTools panel and click the preferred mode in Dock side option.

There are many tabs and options available but in today's article, we'll focus on the most basic one - Elements. It is mostly used to preview the HTML structure and styling of the page. What can we do here?

Preview the HTML structure of the whole page

Yes, I said it before but let's extend this topic a little. As you can see in the Elements tab you can preview all HTML nodes visible on the page. Why it's important? You can e.g. check if all components are displayed correctly (it's a super popular mistake among beginners to create a separate component for some widgets and forget to use them on the page). You can also check the order of elements on the page and nest (which element is inside which). To extend/collapse the node, just use the arrow at the beginning of the line.

Preview of a specific node

When you see some problems on your webpage, you may want to focus on a specific area/node instead of looking at the whole page. There are several ways to do so: you can just right-click on the element on the page and choose the Inspect option from the menu (it works even if Chrome DevTools are not opened on the page), you can find the element in the Elements preview by extending sections, or you can click the selector icon in the Chrome DevTools (on the top left side of the panel) and select the node on the page.

After selecting the given node will be highlighted in the Elements preview in the DevTools panel, so you can see which exact HTML tag is responsible for displaying the given part. This element will be also highlighted on the page with additional info - the margin part will be marked in orange, padding in green and a small popup will show a preview of styling applied on the element. You can see it in the screenshot below

What we can see here? "How to start programming in 2022" is a header element marked with an h1 tag with id="32bb" and many styling classes applied (don't worry about their naming - it's the effect of Javascript uglification and minification on the page making source code smaller, loading faster and more difficult to steal by other developers :) ). The popup is showing us a summary of styling - color, font, margins, and contrast of the element. The orange area is showing the top margin applied to this element (notice that in DevTools there is a colorful box visible on the right side - from this, we can read that the top margin has 19.2px). There is also a section with info about all styles applied to this element. I'll write a little more about styling in the section below but don't be afraid to play a little with all those options. You can't break anything with that - I promise (all your changes will be removed after reloading the page).

Hide/edit/delete/duplicate given element

When you want to quickly preview some changes on the page, you can modify elements directly on the page using Chrome DevTools. Just select the node you are interested in and right-click on it in the Elements tab or click the 3 dots menu at the beginning on the line with the element. After that, you'll see a menu with many options e.g. to hide/edit/delete or duplicate a given element, add an attribute, edit as HTML, etc. Select the one you are interested in and see the visual changes on the page.

Important: it's only a preview, your changes won't be saved after reloading the page.

Change the styling of the element

It's one of my favorite options here - previewing styling changes to the element. You don't have to do changes locally and wait to reload the page each time you change one property. Or you can preview how the page you have no access to will look e.g. with different font colors. Just select the given node as I described in previous sections and look at the Styles tab close to the HTML tree. In the first view, you can see all CSS classes applied to the element, you can change their values (just double-click on the value), add new properties, etc. You can also uncheck the checkbox close to the attribute to disable the given rule. When some rule is crossed out it means some other properties override it.

When it's possible, autosuggestion will propose available values for given property (sometimes with visual tips on what they mean), so it's an easy way to find e.g. correct option when you don't remember the exact name of the property's value!

In one of the recent releases, Chrome added also information when some rule cannot be applied to a given element. You can recognize it by greyed letters and the 'i' icon close to the value. When you hover over the 'i' icon, you'll see a popup with an explanation of why a given rule cannot be applied.

Important: remember that those changes are not saved and will be removed after reloading the page!
There are many, many other options available for styling here (so strongly recommend just playing with it), but I want you to focus on one more thing - close to the 'Styles' tab there is also the 'Computed' tab. You can use it to easily preview all rules applied to the element without splitting them into CSS classes.

Toggle element state

Sometimes elements on the page look differently depending on their state - e.g. visited link looks differently than an unvisited one, the button may have different background color on mouse hover, etc. Fortunately, you can easily play with the styling of different element states too. Just select the given node, find the :hov button in the Styles tab, and toggle the checkbox on the state you want to force. Thanks to that, even if you stop e.g. hovering over the element, you can still preview and edit styles applied in this state.

Reorder elements on the page

Sometimes you may want to rearrange elements on your webpage but you are not sure which order is the best. Fortunately, you can easily preview it! Just select the element you want to move in the Elements tab in Chrome DevTools, drag it, and drop it in the correct place. That's it! A new order will be visible in the UI until you reload the page.

Previewing mobile/responsive mode

Modern web development is not easy - we have to ensure our webpages will look good not only on laptops but also on mobile, tablets, big screens, etc. And Chrome DevTools may be useful also in case of checking the responsiveness of our webpage. Just click the mobile preview button close to the selector icon (the second icon from the left in the top menu) and later choose the device, width, height, and device orientation in the menu visible above the page preview. Play with different dimensions - thanks to that you can notice some problems with your webpage behavior on different devices!
A webpage preview on Pixel 5 phone. Notice the icon to enable responsive mode - it's marked in blue with a tooltip below it.

Summary

Of course, the options described in this article are not the only ones available in Chrome DevTools - you may be surprised how many awesome features are available here (I wrote about the less-known ones in my preview article). Feel free to experiment and play with this tool a little - I'm sure it will help you to better understand and easier debug your projects.

How to find the topic of the technical presentation

Dominika Zając (she/her) 🇵🇱 — Thu, 01 Sep 2022 13:32:41 +0000

A few subjective tips that will help you choose the topic of the next workshop or presentation quickly and without pain.

Photo from ngGirls workshop in Warsaw.

Why is it worth it?

When I started my career in IT, I asked one of my mentors why he devotes his time to conducting workshops and lectures and sharing knowledge with others. The answer I heard inspires me to this day:

“What separates good programmers from the great ones is that the first ones are well-versed in technical issues, can solve problems and take care of their development. Others also share their knowledge and help others to develop”.

I strongly believe that the free flow of knowledge, helping each other and sharing experiences are the things that make IT such a wonderful and unique industry. I also learned a lot from various presentations and I would like to “give” some good to the world. Therefore, I strongly encourage you to share your knowledge with others - e.g. by conducting interesting presentations and workshops. What's more - attending all sorts of events can help you grow your personal brand, get a promotion at work, expand your network of contacts, and even travel more (after all, tech conferences are held all over the world).

Choosing a topic

If the arguments in the previous paragraph have convinced you (and I hope so), you are probably wondering how to start. Contrary to public opinion, it is not that difficult! For most of the people I have spoken to and mentored, the problem is finding the right topic for a speech. What criteria should a good topic meet? It should be:

interesting - to attract the attention of the audience,
precise - to convey knowledge despite time constraints and to focus on a small area of knowledge so as not to overload the audience with excess knowledge,
matched to the audience - we will speak differently to a group of professionals from the same industry and differently to children. From the very beginning, it is worth considering who is the recipient of our message and choose a topic appropriate for a given group.

Once we know what a good topic means, it's time to generate ideas. Personally, I recommend a one-person brainstorming session on this topic. Book 30 minutes in your calendar, during which no one will disturb you. Then get a pen and paper or a computer with your favorite word processor. Start the timer for 20 minutes. Think about 3 areas: things you are interested in, things you have been working on recently and things you want to know more about (I will describe them in more detail in the following paragraphs). For each of them, write down as many ideas and associations as possible. Don't limit yourself and don't scratch any idea at this stage - even if it looks strange at first glance. When the time runs out, start analyzing your saved ideas, taking into account the criteria for a good topic outlined above. Do any of them speak exceptionally to your heart? This is most likely the topic of your next presentation!

Generating ideas

The most important step in coming up with a presentation topic is generating ideas. As I wrote above, I most often use 3 predefined areas here: passion, current work and plans. What exactly do I mean by them? Let's go through each of these areas in turn.

As you can see in the picture attached, me and my teddy Android are big fans of using sticky notes to generate ideas, but of course the digital version is also OK.

Things you are fascinated by

Each of us has our own interests. And there is nothing better than true enthusiasts who tell others about their hobbies. Is there something that really fascinates you? Something you love telling your friends about and what you can talk about for hours? What was your last "after hours" project that you couldn't tear yourself away from? What subject on your studies /bootcamp do you remember so much that you would like more people to hear about it? It doesn't have to be purely technical either - think about how you can combine your passion with technology. Maybe you can create your own dance mat and program it in your favorite language? Or to use the passion for yoga to tell programmers what to do to make your back hurt less after a whole day of work? I'm sure you already have some interesting ideas - use them! An additional bonus: the easiest way to talk about things we love, is that preparation and presentation will be a pleasure for you.

Something you have been working on recently

Another area worth focusing on is the things you are currently working on or have recently worked on. Perhaps it is not something as interesting as the things you thought about in the previous paragraph, but most likely you have already done the initial research and implementation of the solution. You also have a good base for a presentation in which you will tell about your specific example: the business goal you want to achieve, the problems you encountered on your way and the ways in which you addressed them, analyzed approaches - their advantages and disadvantages. What would you do differently if you started this project from scratch? What would you like to know beforehand? Help others by answering these questions. In my subjective opinion, presentations describing a specific use case in the real world are one of those presentations with the most listeners. Think of recent interesting examples from work or additional projects and share them with others.

A photo from my presentation for the Success University about what a programmer's job looks like. Our experiences from everyday work can interest many people.

Something you want to know more about

The last category of ideas is the least intuitive and requires the most work on your part. I'm sure you have in your head suggestions for things you want to learn more about, frameworks that you intend to learn or tools that you plan to test. A presentation on these topics can be an additional motivation to turn these plans into reality. In addition, there is a good chance that others would like to learn about these topics as well. Thanks to your presentation, they will learn how to start and save some time needed for researching a given tool. I think many great presentations were created thanks to interesting conversations over beer, interesting meetings at meetups or conferences. Take a look at the list of things you want to learn, look at inspirations and notes from recent times. Perhaps that's where the topic of your presentation hid. However, there is one very big risk with this approach - remember that getting to know new things is a long process, and your final conclusions may be different than those planned at the very beginning. In addition, it is important to select the recipients of such content - your topic will most likely be appropriate for a local meetup or meeting at work among people who do not know anything about the topic but definitely do not fit the conference gathering specialists in a given area. Personally, I advise you not to attend any conference or meetup until you have a specific abstract and general plan. Remember that each presentation should be well thought out and properly prepared. However, if you are not chased by deadlines and you can spend some time on research, combine business with pleasure - learn something new, and when you get to know it, share your knowledge with others!

Photo from my presentation about accessibility at InfoShare F3 conference in Gdańsk.

Summary

Choosing a good presentation topic is not an easy task, but you will certainly be able to handle it. What to do?

Take a piece of paper and a pen in your hand.
List things in which you are very interested.
List the things you have been working on recently.
List things you would like to know more about.
Analyse all your saved ideas and think about which one you like best. I am sure that thanks to this simple exercise you will be able to choose the topic of your next presentation!

I keep my fingers crossed for you and for your presentation!

Jak znaleźć temat prezentacji technicznej

Dominika Zając (she/her) 🇵🇱 — Wed, 24 Aug 2022 09:03:36 +0000

Kilka subiektywnych wskazówek, które pomogą Ci szybko i bez bólu wybrać temat kolejnych warsztatów czy prezentacji.

Zdjęcie z warsztatów ngGirls w Warszawie.

Dlaczego warto?

Gdy rozpoczynałam swoją karierę w IT, spytałam jednego ze swoich mentorów dlaczego poświęca swój czas na prowadzenie warsztatów i wykładów oraz dzielenie się wiedzą z innymi. Odpowiedź, którą usłyszałam inspiruje mnie do dziś:

“Dobrych programistów od tych wybitnych dzieli to, że pierwsi doskonale orientują się w kwestiach technicznych, potrafią rozwiązywać problemy i dbają o swój rozwój. Drudzy oprócz tego dzielą się wiedzą i pomagają rozwijać się innym”.

Bardzo mocno wierzę w to, że swobodny przepływ wiedzy, pomaganie sobie nawzajem i wymiana doświadczeń to rzeczy, dzięki którym IT jest tak wspaniałą i wyjątkową branżą. Sama też wiele nauczyłam się dzięki różnym prezentacjom i chciałabym “oddać” trochę dobra dla świata. Dlatego bardzo mocno zachęcam Cię do dzielenia się swoją wiedzą z innymi — m.in. prowadząc ciekawe prezentacje i warsztaty. Co więcej — udział w różnego rodzaju wydarzeniach może pomóc Ci rozwinąć markę osobistą, zdobyć awans w pracy, rozwinąć sieć kontaktów, a nawet więcej podróżować (w końcu konferencje techniczne odbywają się na całym świecie).

Wybieranie tematu

Jeżeli argumenty z poprzedniego akapitu Cię przekonały (a mam nadzieję, że tak właśnie było), zastanawiasz się pewnie jak zacząć. Wbrew pozorom, nie jest to takie trudne! Dla większości osób, z którymi rozmawiałam i które mentoruję, problemem jest znalezienie odpowiedniego tematu wystąpienia. Jakie kryteria powinien spełniać dobry temat? Powinien on być:

interesujący — by przyciągnąć uwagę słuchaczy,
precyzyjny — by przekazać wiedzę mimo ograniczeń czasowych i koncentrować się na małym obszarze wiedzy tak aby nie zarzucić słuchaczy nadmiarem wiedzy,
dobrany do widowni — inaczej będziemy w końcu mówić do grupy profesjonalistów z tej samej branży, a inaczej do dzieci. Warto od samego początku zastanowić się kto jest odbiorcą naszego przekazu i wybrać temat odpowiedni dla danej grupy.

Kiedy już wiemy, co oznacza dobry temat, przychodzi czas na generowanie pomysłów. Osobiście polecam w tym temacie jednoosobową burzę mózgów. Zarezerwuj w swoim kalendarzu 30min, w czasie których nikt nie będzie Ci przeszkadzał. Następnie zaopatrz się w kartkę i długopis lub też komputer z ulubionym edytorem tekstu. Włącz stoper na 20 min. Pomyśl o 3 obszarach: rzeczach, którymi się interesujesz, rzeczach nad którymi pracowałeś/pracowałaś w ostatnim czasie i rzeczach, o których chcesz się dowiedzieć więcej (opiszę je dokładniej w kolejnych akapitach). Do każdego z nich wypisz jak najwięcej pomysłów i skojarzeń. Nie ograniczaj się i nie wykreślaj na tym etapie żadnego pomysłu — nawet jeżeli na pierwszy rzut oka wygląda dziwnie. Kiedy skończy się czas, rozpocznij analizę zapisanych pomysłów, biorąc pod uwagę kryteria dobrego tematu opisane wyżej. Czy któryś z nich wyjątkowo przemawia do Twojego serca? Najprawdopodobniej to temat Twojej kolejnej prezentacji!

Generowanie pomysłów

Najważniejszym etapem wymyślania tematu prezentacji jest generowanie pomysłów. Tak jak pisałam wyżej, najczęściej korzystam tutaj z 3 wcześniej określonych obszarów: pasji, aktualnej pracy i planów. Co dokładnie przez nie rozumiem? Przejdźmy przez każdy z tych obszarów po kolei.

Jak widać na załączonym obrazku, ja i mój pluszowy Android jesteśmy wielkimi fanami wykorzystywania karteczek do generowania pomysłów ale oczywiście wersja cyfrowa jest również OK.

Rzeczy, którymi się fascynujesz

Każdy z nas ma swoje własne zainteresowania. I nie ma nic lepszego niż prawdziwi pasjonaci, którzy opowiadają innym o swoich “konikach”. Czy jest coś co Cię naprawdę fascynuje? Coś o czym uwielbiasz opowiadać swoim znajomym i o czym możesz rozmawiać godzinami? Jaki był Twój ostatni projekt “po godzinach”, od którego nie mogłaś/nie mogłeś się oderwać? Jaki przedmiot na studiach/kursie zapadł Ci tak bardzo w pamięć, że chciałbyś by więcej osób o tym usłyszało? To nie musi być również rzecz czysto techniczna — pomyśl jak możesz połączyć swoją pasję z technologią. Może uda Ci się stworzyć własną matę do tańczenia i zaprogramować ją w ulubionym języku? Albo wykorzystać pasję do jogi, by podpowiedzieć programistom co zrobić, by plecy po całym dniu pracy bolały mniej? Jestem pewna, że w Twojej głowie zrodziło się już kilka ciekawych pomysłów — wykorzystaj je! Dodatkowy bonus: najłatwiej mówi nam się o rzeczach, które uwielbiamy, stąd przygotowanie i prezentacja będą dla Ciebie zapewne przyjemnością.

Coś nad czym pracujesz w ostatnim czasie

Kolejny obszar, nad którym warto się pochylić to rzeczy, nad którymi aktualnie pracujesz lub pracowałaś/pracowałeś w ostatnim czasie. Być może nie jest to coś aż tak interesującego jak rzeczy, o których pomyślałeś/pomyślałaś w poprzednim akapicie, jednak najprawdopodobniej masz już za sobą wstępny research, a także implementację rozwiązania. Masz też dobrą bazę na prezentację, w której opowiesz o swoim konkretnym przykładzie: celu biznesowym, który chcesz osiągnąć, problemach, które napotkałeś/napotkałaś na swojej drodze i sposobach w jaki je zaadresowałaś/zaadresowałeś, przenalizowanych podejściach — ich zaletach i wadach. Co zrobiłabyś/zrobiłbyś inaczej gdybyś zaczynała/zaczynał ten projekt od zera? Co chciałabyś/chciałbyś wiedzieć wcześniej? Pomóż innym odpowiadając na te pytania. W mojej subiektywnej ocenie, prezentacje opisujące konkretny przypadek użycia w rzeczywistym świecie są jednymi z tych wystąpień, z których słuchacze wynoszą najwięcej. Pomyśl o ciekawych przykładach z pracy lub projektów dodatkowych w ostatnim czasie i opowiedz o nich innym.

Zdjęcie z mojej prezentacji dla Uniwersytetu Sukcesu o tym jak wygląda praca programistki. Nasze doświadczenia z codziennej pracy mogą być podstawą prezentacji, która zaciekawi wiele osób.

Coś o czym chcesz dowiedzieć się więcej

Ostatnia kategoria pomysłów jest najmniej intuicyjna i wymaga największego nakładu pracy z Twojej strony. Z pewnością masz w swojej głowie propozycje rzeczy, o których chcesz dowiedzieć się więcej, frameworki, których zamierzasz się nauczyć czy też narzędzia, które planujesz przetestować. Prezentacja dotycząca tych tematów może być dodatkową motywacją, by te plany zamienić w rzeczywistość. Ponadto, istnieje wielka szansa, że inni również chcieliby poznać te tematy. Dzięki Twojej prezentacji dowiedzą się jak zacząć i zaoszczędzą trochę czasu potrzebnego na research danego narzędzia. Myślę, że wiele świetnych prezentacji powstało dzięki ciekawym rozmowom przy piwie, ciekawym spotkaniom na meetupie czy konferencji. Zerknij na listę rzeczy, których chcesz się nauczyć, popatrz na inspiracje i notatki z ostatniego czasu. Być może właśnie tam ukrył się temat Twojej prezentacji. Z tym podejściem wiąże się jednak jedno bardzo duże ryzyko — pamiętaj, że poznawanie nowych rzeczy jest długotrwałym procesem, a Twoje ostateczne wnioski mogą być inne niż te zaplanowane na samym początku. Dodatkowo, ważne jest odpowiednie dobranie odbiorców takich treści — Twój temat będzie najprawdopodobniej odpowiedni na lokalny meetup czy spotkanie w pracy wśród osób, które nic nie wiedzą w temacie ale stanowczo nie pasuje na konferencję gromadzącą specjalistów w danym obszarze. Osobiście odradzam też zgłaszanie się na jakąkolwiek konferencję czy meetup zanim nie będziesz mieć określonego abstraktu oraz planu ogólnego. Pamiętaj, że każda prezentacja powinna być przemyślana i odpowiednio przygotowana. Jeżeli jednak nie gonią Cię żadne terminy i możesz poświęcić trochę czasu na research, połącz przyjemne z pożytecznym — naucz się czegoś nowego, a gdy już to poznasz podziel się wiedzą z innymi!

Zdjęcie z mojej prezentacji o dostępności na InfoShare F3 w Gdańsku.

Podsumowanie

Wybór dobrego tematu prezentacji nie jest zadaniem prostym ale z pewnością sobie z nim poradzisz. Co zrobić?

Weź w rękę kartkę papieru i długopis.
Wynotuj rzeczy, którymi się bardzo interesujesz.
Wynotuj rzeczy, nad którymi ostatnio pracowałaś/pracowałeś.
Wynotuj rzeczy, o których chciałbyś dowiedzieć się więcej.
Przeanalizuj wszystkie zapisane pomysły i zastanów się, który z nich najbardziej Ci się podoba. Jestem pewna, że dzięki temu prostemu ćwiczeniu uda Ci się wybrać temat kolejnej prezentacji!

Bonus

Przygotowanie swoich pierwszych prezentacji, wybieranie tematu, tworzenie struktury prezentacji czy poszukiwanie miejsca, w którym można się zaprezentować może wydawać Ci się nieco przytłaczającym zadaniem — spokojnie, wiele osób ma podobne obawy. Aby pomóc początkującym, razem z Jarkiem Michalikiem (świetnym programistą i prelegentem opowiadającym głownie o testach w Kotlinie) tworzymy kurs, w którym będziemy pomagać początkującym stworzyć swoją pierwszą prezentację. Brzmi dobrze? Wypełnij ankietę, by pomóc nam zrozumieć czego oczekujesz od takiego kursu, a my damy Ci znać gdy wystartujemy z projektem.

Trzymam bardzo mocno kciuki za Ciebie i za Twoją prezentację!

5 tips to improve your Code Reviews on GitHub

Dominika Zając (she/her) 🇵🇱 — Mon, 15 Aug 2022 18:52:09 +0000

Code review is one of the simplest but at the same time the most powerful mechanisms for programmers. Unfortunately, very often it is also the most underestimated one. In my previous work, I went with my teammates through a journey from zero to quite a good organized and well-working process. Was it worth our time and effort? Definitely, yes! Below you can find some thoughts and tips based on our experiences.

Cat sitting in front of computer with open code editor.

Let's start from the beginning - what is Code Review?

If you are a programmer you probably heard that phrase before. But for tech newbies let's start with a short definition. Code Review (CR in short) is a practice when the second engineer audits your changes before merging them to the main codebase. That super easy behavior improves code quality and accelerates knowledge sharing among the team. Moreover, it helps to avoid mistakes (especially complex ones like architecture problems). All the most popular version controlling platforms like GitHub or GitLab prepared special tools to support CR in their environments. And the majority of companies and teams have special standards defining how the CR should look like and how many approvals you need before merging the code to the main branch. Below you can find 5 tips that in my opinion are super useful when defining your standards.

1. Protected branches

First of all - protect your main branch against unexpected changes. It doesn't matter if someone will call git push locally on a wrong branch or someone from another team who doesn't know your standards is trying to add something to your codebase. Pushing something directly to the main branch should not be possible. Fortunately, GitHub is offering a great mechanism for that called protected branches. You can create special rules for a branch or set of branches (e.g. based on name pattern) defining that e.g. pull request and approval from at least one reviewer are required to merge your code to the main branch.

Screenshot of the section responsible for defining branch protection rules.

How to configure that?

Go to github.com and navigate to your repository
Click Settings tab
In the left-side menu click Branches option
Click Add branch protection rule button
Put branch name or regex for name patter in Branch name pattern input
Choose one of the items available in the checklist below
Save your changes

2. Labels

It's a super small but extremely useful feature for me. Especially in big, open-source repositories. Labels are nothing else but additional, easy-to-see and filter pieces of information visible on pull request lists. You can use them to e.g. differentiate internal and external changes. MRs connected with particular features of your app, type of changes, or size. Using labels makes managing merge requests much easier for me! How to create a label?

Creating a new label is really easy!

Go to github.com and navigate to your repository
Go to the Pull request section
Click Labels close to the filtering input
Click the green New label button
Fulfil all fields in the form and click Create labels button

Now you can assign this label to any of your new or existing merge requests in the pull request creation form or menu in the pull requests section.

3. Automated Checks

Not everything can be tested automatically. But many things like syntax or running tests can be. Don't waste your and your colleagues' time checking things that can be tested by the computer. You can use Jenkins/Github Actions/CircleCI or any other tool of your choice to start automated tests on each merge request creation. Add a rule to disable merge until all required checks pass. It may save your production someday! Small tip: add also a way to easily re-trigger those tests manually - e.g. sending a special message in a comment on GitHub. It's very useful in debugging problems.

One of the biggest benefits of using a code review mechanism is that everyone has a different view, background, and priorities. E.g. one person loves may love stickers on the laptop and the second hates them. But our software should work for everyone! So the second person can see things you accidentally missed in your code.

4. Template Pull Request message with a checklist

Each merge request should have a good, short, and self-explaining title and some description. In big teams, it's also useful to add additional information like links to tasks/issues from your task-tracking system like Jira or Trello. Some things cannot be tested manually - like accessibility or fulfilling business requirements. Unfortunately, when your team and projects are growing it's more and more difficult to remember all of those things to put in the merge request message as an author and things to check as a reviewer. You can easily address those problems using templates for merge requests. Thanks to that you'll see a predefined draft of a message with a checklist of things to manually check when you create a merge request and it's enough to fulfill the form with needed information and mark all items in the checklist as done.

Example of merge request template (yes, the screenshot was taken before IE depreciation).

How to do so?

Open your repository in your favorite code editor
Add file pull_request_template.md in the root of your repository or the docs folder placed in the root.
Put your template inside of the file (You can use markdown syntax there to create headings, checklists, etc).
Merge the change to the main branch.

Note: If you want to have more than 1 template of the message create the PULL_REQUEST_TEMPLATE directory (also in the root or in the docs folder) and keep your markdown files there. In this setup, a user can choose one of the templates using the dropdown menu during creating the MR.

5. Always be open-minded and empathic

// Detect dark theme var iframe = document.getElementById('tweet-1412481733396602883-45'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1412481733396602883&theme=dark" }

Please, don't be like the people from this tweet. Source: https://twitter.com/pareekhjain/status/1412481733396602883

My last tip is not technical but extremely important (inspired by the tweet above presenting 4 people beating the 5th people with the description "4 of 5 developers enjoy code review"). When you do a code review always keep an open mind and be emphatic. Code review is not about roasting someone of their skills. It's not a place to show your superiority or greater experience. It's a mechanism to let us all grow, learn and keep high quality. So, don't only criticize. If someone is doing a great job - let them know about it! If someone is solving something differently than you, try to understand their approach before pushing them to code your way. If someone made a mistake - let them know but in a supportive, not hating way. Each of us has learned once, and we all make mistakes sometimes. Write only the messages you would like to get - to help you develop your skills but not to be depressing. Despite stereotypes empathy is a crucial skill in software engineering - don't forget that! All in all, programming is a team sport nowadays.

Summary

The tips described below do not exhaust all possibilities of improving your code review but are in my opinion a good start to creating a good code review process and defining some standards. I hope, you found this article useful. If so, clap the button below or share it with your friends. Thanks in advance and happy coding!

6 tips to make your JS/TS repository more new-joiners friendly

Dominika Zając (she/her) 🇵🇱 — Sun, 31 Jul 2022 10:36:17 +0000

Have you ever wondered how to make your repository more readable and lower the entry-level for new joiners in your team? How to decrease the time needed for onboarding new people and limit questions asked by external people who want to use your solutions or contribute to them? Or how to make it easier just for yourself to recreate the developing ecosystem after reimaging/changing your laptop? Recently, I analyzed many repositories (private and open source) and discovered that some of them are much more friendly to new joiners than others. What makes them so special? Several small things you can implement in your project with really low time and effort costs. Below, you can find 6— in my opinion — the most useful tips to improve your code repository just today.

#1 Readme

Probably that point is obvious to many of you. But at the same time it’s so important I can’t miss that point in my article. Readme is a file in the root of your git project where you should describe the most essential info about it. What kind of information should be placed there? Definitely, the main purpose of the repository — why it was created, what is the purpose of it, who is responsible for that project. Personally, I am also a huge fan of adding a section with specific info on how to install, develop, and deploy code in the repo. Yeah, I know that majority of times in the beginning it will be sth like:

git clone <repository-address>
npm install
npm run start

but remember that our projects are not always so simple! When your repository is growing and you start using subrepositories, monorepos, micro-frontends, complex dependencies, dockers, or advanced logic to deploy, the first run of the app may become a nightmare for a new joiner — especially if that’s a person with a different technical background than yours. Adding specific info in the readme about that process (especially formed as a chain of commands to call in a terminal) not only lowers an entry-level to contribute to your repository but also decreases the time needed for onboarding a new person or answering questions from other teams in your company. And it should take less than 5 minutes (in the most basic way you can just copy-paste commands you use each time to start a project from terminal to readme file). Completely, worth it — don’t you think? If you need some inspiration, check e.g. github-changelog-generator — really nice example of a good readme file!

#2 Scripts in package.json

Package.json is the next, super-essential file in almost every JS/typescript-based project. It’s a file where you can define the version, name, and dependencies for the project. Thanks to that you can just call npm install or yarn to install all dependencies required for your project (in the correct versions!). As a frontend developer, you probably use that all the time. But there is also a section which is, unfortunately, less popular — and I’m writing here about scripts. It’s nothing more than a key-value list where you can define your own names for some commands. When you are using e.g. Angular, some of them will be generated during the init of the project — like start or test. Although, I strongly encourage you to add your custom ones. If you have a special command to start unit tests, add it to scripts. If you are using some tools to check code styling, add it in that section. If you are using docker, add a script to run it locally there as well. To be honest, almost every command you use in the terminal should be placed here. Benefits are at least two: all useful commands are documented, so a new person in the team can easily check what actions are possible and you receive short, easy-to-remember, and type alias to call in the terminal.

#3 Swagger

Defining and documenting API can be a challenging task. Fortunately, we have something called a swagger — a set of open-source tools built around the OpenAPI Specification that can help you design, build, document, and consume REST APIs. Thanks to them, you can create a webpage with all endpoints defined with their query params, body params, schemas of the expected response, etc. What’s more, you can also test calls directly from that page. You don’t have to dig into source code to understand APIs. And using or changing your service is much easier, don’t you think? Let’s say some words about how to implement them in our project lifecycles. There are two main approaches to defining swagger: as a contract before development or autogenerating that based on created service code. Both of them have their own cons and pros. Defining swagger file as an API contract before touching a code allows us to parallel work between different teams dependent on that service and create typescript types based on that (useful when your backend is written in Node and you want to share types between repositories). But also requires more effort— all endpoints have to be defined manually and some later changes in service may be missed (developers have to remember about changes in two places). On the other hand, you can use annotations to generating swagger files automatically, based on source code — using libraries available for almost all languages. Thanks to that you don’t have to worry about updating documentation, but all consumers have to wait for a working version of API to start their work and some comments. Nevertheless, no matter which option is better in your case, using swagger definitely can take your API documentation to a completely new level.

Note: Very often your swagger contract will be defined in a separate repository. If so, remember to add a swagger link to the Readme file in the main project. Be nice to others, don’t make them search for that (or worse, miss knowledge it exists)!

#4 Tests

Probably, the most surprising point here. But well-written tests may be a much better source of knowledge about the repository than traditional documentation. Docs can lie — code never! When I have a problem with understanding some part of a system, I’m always taking a look at a unit or functional tests for that. It simple way to check which use cases were predicted by the code author and how it should work. And good tests increase also the quality of your project. Double win!

#5 .nvmrc

A little thing, but makes me happy! A .nvmrc file allows you to define and document the node version used in the project. It’s only one line, but whoever was struggling with a broken installation and had no clue what’s wrong, will appreciate it. Especially, because errors printed in the terminal are not suggesting the wrong node version at all! Using .nvmrc it’s enough to call nvm use before npm install and the correct node version will be used. So small, so nice!

#6 Code styling rules & automation

Please, don’t waste your and others' time on manually checking indents or formatting rules. And write them down instead of saying “We always do it that way” during code review. I know that “spaces vs tabs” is a holy war in programming but you have to decide that battle for your team. Add tools like eslint or prettier and a set of rules to your repository. Automate that checks. Test your formatting on pre-commit or creating merge requests. Define rules in a transparent way — not only in your head. And let a computer do that simple checks — it is the best at that!

Summary

Of course, the list presented above is not exhausted and there are many more ways to improve your codebase to make it more new-joiners friendly. But all tips presented by me are easy to implement and — in my personal opinion — have a huge impact on people who want to start work with your repository. I hope, you will find that article useful! If so, click the “clap” button or leave a comment below. Happy coding!

A short comment on comments in the code

Dominika Zając (she/her) 🇵🇱 — Wed, 20 Jul 2022 17:09:38 +0000

My short comment on why you should stop using comments in your code (unless in special cases)

Tl;dr

Please, think twice before adding comments to your code. Probably, there are no needed and will just confuse people who will read your code later on. Write a clean, readable code instead. Thanks in advance!

Intro

I was thinking about this article for a very long time. As I often help young developers I see how many of them love adding comments to their code. And I still remember lecturers from my studies who tried to convince us that the good code should be commented to be readable for other developers. However, the last straw that breaks the camel’s back was the tweet you can see below.

Source: Programmers Memes Twitter

This photo is the best comment on adding comments to the code ever. I wish I could say it’s an exaggeration. But what is the difference between the above and the comment in the function below?

// function to count the perimeter of the triangle
// input: 3 numbers, output: number
const countTrianglePertimeter = (a: number, b: number, c: number)
: number => {
    return a + b + c;
}

Unfortunately, we can still find a lot of snippets like that in the code. And I strongly encourage you to avoid them! Why? There are many reasons to stop adding useless comments to your code.

Reasons to stop adding comments to your code

Comments are just redundant to the code

Very often comments do not provide any additional information to the user. They describe exactly the same things as the code does. So why duplicate the info for the reader? Use meaningful names instead. Extract logic to separate functions if needed. Extract const values to the well-named const variables. Simplify code e.g. using fast returning and avoiding multiple nesting if needed. Well-written code is even easier to read by non-native English speakers than long descriptions in plain language!

Comments are often out-to-date

The code in live projects changes. There are always some bug fixes or new functionalities which require not only adding the code but also editing the existing source. And as long as code is always up-to-date, hardly anyone remembers about updating the comments. So, comments are often out-to-date and present the old logic of the code. Remember, comments can lie — the code never does!

Comments can be misleading

Programmers very often want to keep comments short and write them after writing the code. Because of that, the text can contain some mental shortcuts and simplifications. What is hidden between the words may be obvious to the author, but not to the reader. Using the wrong word may make the whole meaning completely different. And when you make a mistake in the code — tests will catch it. Unfortunately, there is no automated way to test if your comment is not misleading. So just skip it — as long as it’s possible.

Comments make the source code longer

It’s quite obvious — each comment’s line makes your code file longer. And our brains don’t like long walls of text. Opening a file with many comments makes it difficult to find really important lines and see all the code on the screen. When you can’t see all functions on one screen it’s easier to make mistakes or create some inconsistency. Also, computers have to handle it, so it may have an impact on performance. For many years, fans of the minimalist approach to life have been saying that fewer things mean less chaos. And I agree with them — at least when it comes to programming.

Everyone is afraid of removing or uncommenting commented code

Sometimes we leave the code commented in case it will be useful in the future. But let’s be honest — there are no more scary things than code that is commented on and no one knows why. Can we just remove it? Why it’s not working? What happens if we uncomment it? Leaving unfinished or “almost working” snippets commented in the code could be useful many years ago. But now we have great code versioning systems like git — removing the code with meaningful and descriptive commit message (and eventually adding a tag to make it easier to find later on) is much more convenient, clear, and easy to revert. Also, almost no one starts the implementation of a new feature by looking for some commented code in the codebase. So chances that someone will use your currently unnecessary code are really low.

Special cases when comments can be useful

In the previous section, I described many reasons for removing comments from your code. However, there are some special cases where comments can be useful — even in the production code! They are described below — but remember: I don’t call them special cases by accident :)

Regexes

There is an old saying “If you have a problem and use regex to solve it then you have two problems”. Regular expressions are great and useful but unfortunately not very readable. It’s why adding comments explaining what a given regex is checking is not the worst idea.

Specific business logic

Sometimes business requirements are tricky and not intuitive. Theoretically, the logic should be covered in some tech documentation but let’s be honest — no one likes reading tons of docs when need to fix one small thing. It’s why adding a short comment explaining the reasons behind some not obvious decisions may be OK. Just check if it’s a confusing logic that cannot be well explained in the code.

TODO comments

The developing process is split into steps. And it’s OK to not include all changes in one commit but leave them for the following ones. When your project is small and you don’t use any tool to track tasks (like Jira or Github Issues), having TODO comments saying what should be changed and where can be useful. Especially because code editors have special mechanisms to support them. The problem here is that this solution is not scaling and can be inefficient for big projects.

Tips on comments and avoiding them

Some tips may help you decide if comments are needed or how to use them correctly. First of all, before writing a comment thing if you can provide the same content in the code. Why do you need free text to express your intention? Why code cannot speak itself? Very often the need of writing a comment is just a symptom of a refactoring need. Also, if you have to write a comment (because of one of the reasons described in the previous section), keep a comment as close to the code which it describes as possible. If you add your thoughts at the beginning of the file, a person reading the code probably won’t notice it or not update it while implementing some changes. And talking about changes — don’t track them in the source code. Git is definitely a better place to track changes and their authors. Also, git (or any other versioning system) is your friend if you want to remove some functionality but have a chance to revert it. Don’t comment on the source code — create a commit with a meaningful name instead and programmers will find it in history if needed. Thanks to all of those tips your code will be cleaner, up-to-date, and more readable for everyone.

Summary

Of course, there are no strict rules about adding comments to the code. Each case is a little different and your role as a developer is to determine if comments can be useful in your case or distract/mislead the person who will read your code. I encourage you to think twice before you will add a new comment to your code and consider their props and cons. Remember: comments can lie — code never does!