DEV Community: Pavel Polívka

Building a Multi-Agent Content Management System with AI

Pavel Polívka — Mon, 13 Apr 2026 21:03:59 +0000

I recently built something that would have sounded like science fiction a year ago: an AI system that helps manage parts of my content workflow—from discovery to publishing—across LinkedIn, BlueSky, and DEV.to.

Not a chatbot. Not a simple automation script. A multi-agent orchestration system where different AI agents coordinate to handle different parts of the content pipeline.

Here's what I learned building it.

The Problem: Context Switching is Killing Productivity

Before this system, my content workflow looked like this:

Manually browse Hacker News, Reddit, and tech blogs for topics
Take notes in a doc somewhere
Write drafts when I find time
Edit and format for each platform separately
Remember to actually post them
Track what performed well

Each step required context switching. Each context switch killed momentum. And worst of all, the coordination overhead meant I was spending more time managing content than creating it.

Sound familiar?

The Solution: Agents That Actually Coordinate

Instead of building one monolithic AI assistant, I built a team of specialized agents:

Discovery Agent: Scans web sources, identifies trending topics relevant to my audience
Content Writer: Takes approved topics and drafts initial content (which I then refine and personalize)
Content Manager: Orchestrates publishing schedules, handles cross-platform posting
Brand Strategist: Reviews content for brand voice and decides what's worth publishing

Each agent has a specific job. Each agent can create tasks, update status, escalate when blocked, and hand off work to other agents.

The key insight: agents don't just execute tasks—they coordinate around tasks.

Important note: The AI agents handle the boring coordination work—scheduling, formatting, API calls. The creative work, strategic decisions, and final writing? That's still me. Think of this as automation for the parts of content creation that don't require human creativity.

Architecture: Tasks as the Coordination Primitive

The core of the system is a task queue, but not like you're thinking.

┌─────────────────────────────────────────────────┐
│           Task Management Layer                 │
│  (Issues, Status, Assignments, Dependencies)    │
└─────────────────────────────────────────────────┘
         ↑              ↑              ↑
         │              │              │
    ┌────┴───┐     ┌───┴────┐    ┌───┴─────┐
    │Discovery│     │Content │    │Content  │
    │ Agent   │────>│Writer  │───>│Manager  │
    └─────────┘     └────────┘    └─────────┘
         │              │              │
         ↓              ↓              ↓
    ┌─────────────────────────────────────────┐
    │       External APIs (Web, LLM, Social)  │
    └─────────────────────────────────────────┘

Every piece of work is an issue (think GitHub issue, JIRA ticket, Linear task). Issues have:

Status: todo, in_progress, in_review, done, blocked
Assignee: which agent owns this work right now
Parent/child relationships: for breaking down complex work
Dependencies: explicit "blocked by" relationships between tasks

When an agent picks up work:

It checks out the issue (atomic lock, prevents conflicts)
Does the work
Updates status and adds a comment explaining what changed
Either marks it done or reassigns to another agent

This isn't novel in human project management. What's novel is that AI agents can now participate in the same workflow.

Real Code: Publishing to BlueSky

Here's what the Content Manager agent actually does when asked to publish a post:

# 1. Authenticate with BlueSky
AUTH=$(curl -s -X POST "https://bsky.social/xrpc/com.atproto.server.createSession" \
  -H "Content-Type: application/json" \
  -d "{\"identifier\": \"$BSKY_IDENTIFIER\", \"password\": \"$BSKY_APP_PASSWORD\"}")

ACCESS_JWT=$(echo "$AUTH" | python3 -c "import sys,json; print(json.load(sys.stdin)['accessJwt'])")
DID=$(echo "$AUTH" | python3 -c "import sys,json; print(json.load(sys.stdin)['did'])")

# 2. Create the post
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%S.000Z")

curl -s -X POST "https://bsky.social/xrpc/com.atproto.repo.createRecord" \
  -H "Authorization: Bearer $ACCESS_JWT" \
  -H "Content-Type: application/json" \
  -d "{
    \"repo\": \"$DID\",
    \"collection\": \"app.bsky.feed.post\",
    \"record\": {
      \"\\$type\": \"app.bsky.feed.post\",
      \"text\": \"$POST_TEXT\",
      \"createdAt\": \"$TIMESTAMP\"
    }
  }"

Nothing fancy. Standard REST API calls. The magic isn't in the API integration—it's in the orchestration layer that knows:

When to post
What content to use
How to handle failures
Who to notify when done

Real Code: The Heartbeat Pattern

Agents don't run continuously. They run in heartbeats—short execution windows triggered by events.

Each heartbeat follows this pattern:

# 1. Check what's assigned to me
INBOX=$(curl -s -H "Authorization: Bearer $API_KEY" \
  "$API_URL/api/agents/me/inbox-lite")

# 2. Pick highest priority work (in_progress → todo → blocked if I can unblock)
ISSUE_ID=$(echo "$INBOX" | jq -r '.[0].id')

# 3. Checkout (atomic lock)
curl -s -X POST -H "Authorization: Bearer $API_KEY" \
  -H "X-Run-Id: $RUN_ID" \
  "$API_URL/api/issues/$ISSUE_ID/checkout"

# 4. Do the work
# ... agent-specific logic here ...

# 5. Update status
curl -s -X PATCH -H "Authorization: Bearer $API_KEY" \
  -H "X-Run-Id: $RUN_ID" \
  -d '{"status": "done", "comment": "Published to BlueSky: https://..."}' \
  "$API_URL/api/issues/$ISSUE_ID"

This heartbeat pattern means:

Agents don't fight over the same work (checkout is atomic)
Every action is traced (run ID links actions to heartbeat executions)
Failures are isolated (one agent crashing doesn't affect others)
The system is naturally resumable (agents pick up where they left off)

The Hard Parts Nobody Talks About

1. Error Recovery

LLMs fail. APIs rate-limit. Networks drop. Your agents will encounter errors.

The first version of my system would just retry infinitely or silently fail. Neither is acceptable.

Now, agents follow this escalation pattern:

Transient errors (network, rate limit): retry with exponential backoff
Validation errors (bad input): mark issue blocked, comment with specific error, reassign to creator
Permanent errors (auth expired): mark blocked, escalate to me

if [ $HTTP_STATUS -eq 401 ]; then
  curl -X PATCH -d '{
    "status": "blocked",
    "comment": "Authentication expired. Please refresh access token"
  }' "$API_URL/issues/$ISSUE_ID"
  exit 0
fi

2. Content Length Limits

BlueSky has a 300 grapheme limit (not characters, not bytes—graphemes). An emoji counts as one grapheme, but é might count as one or two depending on normalization.

I learned this the hard way when a post with 280 characters got rejected for being 340 graphemes.

Solution: validate before posting.

import unicodedata
text = "your post text"
grapheme_count = len(list(text))  # Simplified; use grapheme library for production
if grapheme_count > 300:
    # Truncate or split into thread

3. Daily Routines That Don't Spam

I wanted daily publishing reminders, but I didn't want 7 separate tasks clogging my inbox.

Solution: routines with concurrency policies.

{
  "title": "Daily content reminder",
  "cronExpression": "30 8 * * *",
  "concurrencyPolicy": "skip_if_active"
}

skip_if_active means: if yesterday's reminder is still open, don't create today's. This prevents reminder spam while ensuring I don't lose track.

What This Enables

With this system running:

Discovery Agent scans Hacker News daily, creates issues for trending topics
Brand Strategist reviews those issues, approves the ones worth writing about
Content Writer drafts initial content based on approved topics (I refine and add my personal insights)
Content Manager schedules and publishes across BlueSky, LinkedIn, DEV.to

My involvement: strategic decisions, creative refinement, and final approval. The boring coordination work runs autonomously.

Time saved per week: ~10 hours of coordination overhead.

Key Lessons

1. Agents Are APIs for Work

Just like you wouldn't build an API that accepts ambiguous parameters, don't give agents ambiguous tasks.

Bad: "Handle the deployment"
Good: "Deploy branch release/v2.3 to production, run smoke tests, rollback if health checks fail after 5 min"

2. Visibility > Autonomy

Early on, I optimized for "how much can agents do without me?"

Wrong question.

Better question: "how quickly can I understand what agents did and why?"

Now every agent action includes:

What changed
Why it changed
What happens next
Links to relevant resources

3. Start With Boring Tech

The orchestration layer is PostgreSQL + REST APIs. No vector DB, no RAG, no fancy AI frameworks.

Why? Because the hard part isn't the AI—it's the coordination. And coordination is a solved problem in distributed systems.

Use LLMs for what they're good at (writing, reasoning, API calls). Use boring databases for what they're good at (consistency, transactions, queries).

Try It Yourself

You don't need to build the whole system at once. Start small:

Pick one recurring task (e.g., posting to social media)
Create a simple task queue (even a JSON file works)
Build one agent that reads from the queue, does the work, updates status
Add a second agent that creates tasks for the first agent

Once you see two agents coordinating, you'll understand why this pattern scales.

What's Next

I'm working on:

Approval workflows: some tasks need human review before publishing
Budget controls: LLM costs add up fast; agents need spending limits
Analytics integration: track what content performs, feed that back to the Discovery Agent

The goal isn't to remove humans from the loop—it's to remove humans from the boring parts of the loop. The creative thinking, strategic decisions, and personal touch? That's still all human.

Questions? Drop them in the comments. I'm especially curious if you've built similar multi-agent systems and what patterns worked (or didn't) for you.

AI #Automation #Agents #ContentStrategy #Productivity

The Review Revolution: Why Code Review Is Now the Most Important Skill You Have

Pavel Polívka — Thu, 09 Apr 2026 10:54:23 +0000

The PR came in on a Tuesday. Clean diff. All CI checks green. GitLab Duo had already run its pass — no obvious security anti-patterns, no style violations. The author was a solid mid-level developer, two years on the team.

Then I asked: "Why did you choose this approach for the concurrency handling here?"

Pause.

"I think Claude Code suggested it and it seemed right."

That was not the author lying or cutting corners. They had reviewed the output, it looked correct, and they shipped it. The code was correct — at least for the happy path. What neither of us could answer in that moment: what happens when the lock acquisition times out? What is the failure mode if the downstream call is slow? Why this implementation over the simpler one?

That is not a junior developer problem. That is a 2026 code review problem. And most teams are running their last checkpoint with 2019-era habits.

What Changed

Before AI coding tools, the reviewer's job was well-defined: check the logic, catch edge cases, flag style violations, enforce team conventions. It was a hard job, but it had a reasonable assumption built in — the author understood what they wrote, because they wrote it.

That assumption is gone.

With Claude Code, GitHub Copilot, and similar tools in daily use, the reviewer now does two jobs:

Check the code itself
Check whether the author understands the code

These are different skills. The second is harder. And most review processes were not designed for it.

The failure mode looks like this: a developer gets a requirement, pastes it into Claude Code, gets working code, reviews the output for obvious issues, and ships it. The PR reviewer checks the diff, finds nothing wrong, approves it. Neither person can articulate the performance characteristics, the failure modes, or the security implications of what was just merged.

The data confirms this is not edge-case behavior. Veracode's 2026 analysis found that AI-generated code introduces security vulnerabilities in 45% of cases — in Java specifically, 72% of AI-generated code has at least one CWE hit. The Harness 2026 report found that organizations that adopted AI coding tools without updating their review processes saw a 34% increase in production incidents in 2025.

This is not an argument against AI tools. It is an argument that the bar for code review just moved, and most teams have not moved with it.

What Good Review Looks Like Now

1. The New PR Description Standard

The fastest way to know if a developer understood what they shipped is to make them explain it — in their own words, before anyone reviews the code.

Add this to your team's PR template:

## What does this do?
[Explain the intent — not the code, the problem being solved]

## How was this implemented?
[Explain the approach. If AI-generated, say so and explain why you accepted it.]

## Edge cases considered
- [ ] [At least 3. Be specific.]

## How was this tested?
[If AI-generated tests were included, note which assertions were written by hand]

When a developer cannot fill in "edge cases considered," they do not understand what they shipped. That is the signal — and it surfaces before the reviewer has read a single line of code.

The best-performing engineering teams in 2026 are now requiring AI-generated PRs to include this explicitly: what the approach is, what edge cases were considered, and at least one self-generated test per non-trivial function. Not as bureaucracy — as a forcing function for comprehension.

2. The Three Review Questions for AI-Generated Code

When reviewing a PR that includes AI-generated sections — Claude Code output, GitLab Duo suggestions, Copilot completions — ask these three questions. Direct them at the code, not the author.

Question 1: What is this code optimizing for?

AI-generated code is optimized for "solves the stated problem" and "compiles." It is not optimized for your specific performance SLAs, your team's error-handling conventions, or your domain's threat model.

Look at the implementation choices. Is this optimized for throughput? For readability? For minimal memory allocation? Often the answer is: it's optimized for none of those, because the prompt didn't specify any of them. That is where the mismatch lives.

Ask the author: "What constraint was this generated to solve?" If they cannot answer, the review should not proceed.

Question 2: What happens when this fails?

AI tends to generate happy-path code. Exception handling, circuit breakers, timeouts, and retry logic are frequently omitted or wrong.

Look specifically at: what exceptions are caught and swallowed? What happens if the external call is slow or returns a 503? Is the failure mode recoverable or catastrophic? If a pod restarts mid-operation, what is the state of in-flight transactions?

These are not exotic scenarios. These are Tuesday morning incidents. And they are the exact kind of thing AI code generation consistently misses, because the prompt that generated the code did not mention them.

Question 3: Would a junior on this team be able to maintain this in 18 months?

AI-generated code can be locally clever and globally incomprehensible. If the implementation relies on a pattern that is not in your team's standard vocabulary — and the PR description does not explain it — that is a code smell, even if the code is technically correct.

Maintainability is not just about readability. It's about whether the next developer who touches this file will understand the intent well enough to make safe changes. AI-generated code often optimizes for correctness at the cost of clarity.

3. GitLab Duo in the Review Flow

GitLab Duo Code Review integrates at the merge request level and is genuinely useful — it catches style violations, obvious logic errors, and common security anti-patterns quickly.

The key is using it correctly: treat Duo's pass as the mechanical layer, not the full review. It handles the things a linter and a static analyzer would catch, at the speed of a bot.

The human reviewer's job starts where Duo's ends: does the author understand what they shipped? Is the failure handling correct for this domain? Does the implementation reflect team conventions that are not captured in any linter rule?

Duo is not a substitute for the three questions above. It is a first pass that frees you to ask better questions.

Code Review as a Career Signal

AI coding tools have done something unexpected to engineering career ladders: they made junior and mid-level code syntactically indistinguishable from senior code.

A developer with 18 months of experience can now generate a working microservice — clean, organized, passing all automated checks — that looks like something a staff engineer would write. The output is impressive. The signal it sends about the developer's ability is... unclear.

What AI cannot do is teach you to catch what it missed.

Recognizing silent exception swallowing that will cause a service to fail silently under load — that requires having seen it happen. Noticing a data access pattern that will cause N+1 queries as the dataset grows — that requires understanding how your ORM generates SQL. Catching retry logic with no jitter that will thundering-herd your downstream service at exactly the moment you least want it to — that requires having been on-call when it happened to someone else.

These instincts come from production experience. They come from reading incident reviews. They come from having opinions that are more specific than "this looks right."

In 2026, the clearest seniority signal is not what you can generate — it is what you can review.

If you are a mid-level developer trying to reach senior: become exceptional at code review. Not just at finding bugs, but at teaching through review. The comment that explains why a pattern is dangerous, not just that it is. The question that forces the author to reason through failure modes they had not considered. That is senior engineering. AI cannot fake it.

The Checklist

Before approving any PR that includes AI-generated code:

Comprehension checks:

[ ] Author can explain the approach in their own words
[ ] PR description lists at least 3 edge cases, with specifics
[ ] Implementation choice is justified (why this approach over alternatives)

Failure mode checks:

[ ] Exception handling is explicit — no empty catch blocks, no silent swallowing
[ ] External calls have timeout and retry logic appropriate for the failure profile
[ ] Failure modes are recoverable (or the PR explicitly notes they are not)

Quality checks:

[ ] At least one non-trivial test was written by the author, not generated
[ ] Logging is present at failure points, not just on the happy path
[ ] Any new DB query has been analyzed for N+1 risk

Red flags that should pause approval:

"I'm not sure why this works, but it does"
100% test coverage where all tests are generated and assert the obvious
An exception handler that logs and swallows without alerting
An implementation that is clever in a way that is not explained anywhere

The code review is the last checkpoint before production. For most of engineering history, it was also a reasonable proxy for whether the author understood what they wrote.

That proxy is gone. The checkpoint remains.

The teams that figure out how to update their review process — not abandon AI tools, not pretend nothing changed, but update the actual process — will have fewer incidents, faster onboarding, and a clearer signal for who is actually senior.

The code review did not get less important. It got harder. And that is exactly the kind of harder that separates good engineers from the rest.

What does your team's current process look like for reviewing AI-generated code? I'm curious what's working — share it in the comments.

How to create simple email form in your NodeJS website

Pavel Polívka — Sun, 10 Jul 2022 18:30:22 +0000

Most webpages have some contact form, usually not very fancy and the backend behind it can be SalesForce, any other variation of lead generation software but usually it just sends email.

Sending emails is not trivial, you need to have an SMTP server and that alone will add to your costs. Fortunately, we live in an age where everything is a service and API. There are tons of services that can send emails to you. My goal was to do it as cheaply as possible (preferably for free). I was expecting at most about 5 emails per day.

After some research, I decided to use Send In Blue. Their free plan has 300 emails per day (more than enough for me), you do not need a credit card to sign up, no DNS shenanigans and their API is very straightforward.

API endpoint in NextJS

NextJS offers a friendly and easy way to create API endpoints from where you can call any external APIs without actually exposing your secret keys to the browser.

I got the API key from Send in Blue with the help of this awesome help page, and add the key into my .env.local file.

NEXT_PUBLIC_SEND_IN_BLUE_KEY=xxxxapikeyxxxx

I also put the key into the Vercel Environment variables manager with the same name.

I created a new file api/email.js from where I will send the email via Send In Blue API.

const sendInBlueKey = process.env.NEXT_PUBLIC_SEND_IN_BLUE_KEY

export default async function handler(req, res) {

    const body = req.body

    const resp = await fetch('https://api.sendinblue.com/v3/smtp/email', {
        method: 'POST',
        headers: {
          'Accept': 'application/json',
          'Content-Type': 'application/json',
          'api-key': sendInBlueKey
        },
        body: JSON.stringify({
            "sender":{  
                "name": body.name,
                "email": body.email
             },
             "to":[  
                {  
                   "email": "myemail@ppolivka.com",
                   "name": "Pavel Polivka"
                }
             ],
             "subject":`Contact Form Eamil From ${body.name}`,
             "htmlContent":`
                <html>
                    <head></head>
                    <body>
                        From: ${body.name} <br/>
                        Message: ${body.message} <br/>
                    </body>
                </html>
            `
        })
    });

    res.status(200).end()
}

From the form, I am getting the name and email of the sender and a message. I am sending that (the sender is the email from the form) to my email address so that I can reply to my email client.

Contact Form

Then I created a contact form component. It's a simple form with three fields and the submit button. All the sending magic is happening in the handleSubmit function.

import TextField from '@mui/material/TextField';
import Button from '@mui/material/Button';
import {useState} from 'react';

export default function Contact() {

    const [send, setSend] = useState(false);

    async function handleSubmit(event) {
        event.preventDefault()
        const data = {
            email: event.target.email.value,
            name: event.target.name.value,
            message: event.target.message.value,
        }

        const JSONdata = JSON.stringify(data)

        const endpoint = '/api/email'

        const options = {
            method: 'POST',
            headers: {
              'Content-Type': 'application/json',
            },
            body: JSONdata,
        }

        const response = await fetch(endpoint, options)

        setSend(true)
    }

    let content;

    if (send) {
        content = <>
            <p>Thank you for contacting me!</p>
        </>
    } else {
        content = <>
            <form onSubmit={handleSubmit}>
                <TextField id="email" label="Email" variant="outlined" required />
                <TextField id="name" label="Name" variant="outlined" required />
                <TextField id="message" label="Message" variant="outlined" required multiline rows={4} />

                <Button variant="contained" type="submit">Send</Button>
            </form>
        </>
    }

    return (
        <>
            {content}
        </>
        );
}

I am using React Material UI, but you can use any UI or just normal inputs.

This is all you need. Simple and elegant. It was done in an hour.

Good luck coding.

Do you really need fancy productivity apps?

Pavel Polívka — Thu, 23 Jun 2022 19:40:09 +0000

If you look at Medium, Twitter, or any other platform where many developers hang out you will see an obsession with productivity tools, apps, etc... Everybody is praising the latest shiny apps that will make you a productivity god.

Did we ever stop and asked do we really need all of these apps? I have a busy work schedule and trying to manage that and still have some quality time with my family. So I naturally tried to be as much productive as I can. I downloaded almost all the apps that are in the talks. Tried them in the belief that they will help me with all my issues with time management, not enough time, and joggling all the tasks I need to complete.

Well, I am here to report that it does not work. You actually lose a lot of time trying to use the tools.

Take Obsidian for example. In theory, it's a very cool idea. Have all the notes in one place, interconnected with links between each other. Your second digital brain. Did somebody actually manage to keep a decent size library of all their notes with the links in all the places? When I am writing down a note I actually need to know what are my other existing notes to create a link to them. That seems stupid. Like really, really stupid. The chart showing the relationship between the notes looks impressive in the demos and videos but is it useful? What do you actually gain with it? Maybe just maybe, it's all just a bunch of fluff that will get you nothing.

For me, the best solution for note-taking is basically a bunch of text files and an easy solution in full-text search in those. Wau, that sounds great and useful. What app does that? That is the beauty of this. You do not really need an app for this. It's part of your OS. You just put a bunch of text files in a folder and use Windows search or Apple Spotlight.

Sure it's low tech. Sure it does not really work on phones. Do you really need all your work notes on the go? What is all the obsession with having everything synced and on the go? Do you really need your notes on how to restart a production server when you are grocery shopping? Do you need them on your phone at all? For productivity's sake, you should not really look at your phone when you work anyway. For the notes you need to have on the go you can use your phone notes app. What kind of notes do you need on the go? Maybe a list for your shopping, some measurements, etc... The notes app on your phone is more than capable of doing that.

Another productivity giant is Notion. I never figured out what people really see on it. It's a bunch of templates for markdown files and kanban boards. Plus it's really sluggish and slow to use. Not to mention finicky. It's the most over-engineered solution for your notes and todos. What is the real need for kanban outside of some specific work use cases (and even there it's more or less questionable)? Do you really need to know that your window cleaning is not in progress? What is wrong with just a normal to-do list? If you have that many to-dos that you need to have them organized in some other way than just a plain list, you have a problem with delivering or overcommitting, not with the organization of your tasks.

I tried a lot of different to-do list apps. Some better some worse. I always came back to just writing my todos down on paper. It forces you to keep the list small and manageable. Plus you know, it feels fancy.

In the end, you use what you are comfortable with I will stick with my pile of text files, simple notes app, and paper.

What is in your bag?

Pavel Polívka — Thu, 06 Jan 2022 19:25:40 +0000

As a new year article, I decided to write up some words about what are the daily drivers I have in my bag.

Bag

I use a top-loaded HP bag for 15-inch laptops. My 17 inch Mac Book fits it well and it's pretty nice. But nothing special.

Laptops

I have multiple laptops. For my work, I mostly use Macbook Pro 17" - 16GB RAM, 2019 model. I also have Macbook Air 13" M1 model I use for my personal projects. I also got a few Windows and Linux machines but those are rarely used.

Other electronics

I carry Kindle Whitepaper 4 with me almost everywhere. I love reading.
I also carry Jabra Evolve 75 I use it for work meetings. It's a really great headset. I also have Marshall Mode II true wireless for music and or audiobooks on the go. I love the Marshall sound.

I also have some USB/USB-C cables and some USB-C dongles. Fully embracing that Mac dongle life.

Drug store

I have deodorant in spray, hand sanitizer, mouth deodorant, and glass cleaning gel. Nothing special.

Various

I have my Moleskin notebook, Parker pen, FFP2 respirator, chopsticks, and set of lockpicks. I have lockpicking as one of my hobbies I rarely use those but saved me calling locksmith more than once.

If you like this article you can follow me on Twitter.

React Componenets in Markdown articles

Pavel Polívka — Wed, 15 Dec 2021 19:51:27 +0000

As I decided to create my blog I choose Next.js as my framework of choice, as a backend I use markdown files stored in a git repo.

To render my files I use React Markdown. It's an awesome component that can render markdown files without any config.

After a few posts, I figured out that I need some custom components rendered with my posts. One was for images, to make them zoomable for phones and the second one was a syntax highlighter for code snippets.

React has a huge amount of components that can help us with both of these. I decided to use react-zoom-pan-pinch for image zoom and react-syntax-highlighter for syntax highlight.

Ok. I have my components, not how to render them from our markdown files. Fortunately, React Markdown has us covered. It allows us to do a custom rendering of some tags.

We can do something like this:

import ReactMarkdown from 'react-markdown';
import { Prism as SyntaxHighlighter } from "react-syntax-highlighter";
import { materialDark } from "react-syntax-highlighter/dist/cjs/styles/prism";
import { TransformWrapper, TransformComponent } from "react-zoom-pan-pinch";

<ReactMarkdown
    components={{
        p: ({ node, children }) => {
            if (node.children[0].tagName === "img") {
                const image = node.children[0];
                return (
                    <TransformWrapper>
                        <TransformComponent>
                            <img
                                alt={image.properties.alt}
                                src={`${image.properties.src}`}
                            />
                        </TransformComponent>
                    </TransformWrapper>
                );
            }
            // Return default child if it's not an image
            return <p>{children}</p>;
        },
        code({ className, children }) {
            // Removing "language-" because React-Markdown already added "language-"
            let language = "";
            if (className) {
                language = className.replace("language-", "");
            }
            return (
                <SyntaxHighlighter
                    style={materialDark}
                    language={language}
                    children={children[0]}
                />
            );
        },
    }}
>
    {postData.contentMarkdown}
</ReactMarkdown>

For images, we must hook into

tag, as ReactMarkdown is wrapping images in paragraphs. So with a simple if we decide if the first child of the paragraph is an image. If so we replace the whole thing.

For code, we are just replacing the whole code tag.

If you like this article you can follow me on Twitter.

Making dynamic Twitter header

Pavel Polívka — Fri, 10 Dec 2021 11:54:33 +0000

Recently I saw a Twitter header that displayed images of new followers dynamically. I fell in love with this idea so I decided to create my own.

It should be simple, I will just write a simple script that will take a background image, via Twitter API downloads list of followers, their profile images and puts them into that background image. After that, via the same API, it will upload the image as a new header.

As a true developer I decided to Google how to do this and I found this amazing article by Thobias Schimdt. I shamelessly copied most of his code. I decided to deploy it differently (not on AWS). In this article, I will go over my changes.

In the end, my code looks like this.

const { TwitterClient } = require('twitter-api-client')
const axios = require('axios')
const sharp = require('sharp')
const Feed = require('rss-to-json')
const Jimp = require('jimp')
const fs = require('fs')

const numberOfFollowers = 3
const widthHeightFollowerImage = 90

function getVariable(name) {

    if (fs.existsSync(`${__dirname}/creds.json`)) {
        return require(`${__dirname}/creds.json`)[name]
    }
    return process.env[name]
}

async function uploadBanner() {
    console.log(`Uploading to twitter...`)
    const base64 = await fs.readFileSync('/tmp/1500x500_final.png', { encoding: 'base64' });
    await twitterClient.accountsAndUsers
        .accountUpdateProfileBanner({ banner: base64 })
}

async function createBanner(headline) {
    const banner = await Jimp.read(`${__dirname}/assets/banner.png`)
    const mask = await Jimp.read(`${__dirname}/assets/mask.png`)
    const font = await Jimp.loadFont(Jimp.FONT_SANS_32_WHITE)
    // build banner
    console.log(`Adding followers...`)
    await Promise.all([...Array(numberOfFollowers)].map((_, i) => {
        return new Promise(async resolve => {
            const image = await Jimp.read(`/tmp/${i}.png`)
            const x = 600 + i * (widthHeightFollowerImage + 10);
            console.log(`Appending image ${i} with x=${x}`)
            banner.composite(image, x, 360);
            resolve()
        })
    }))
    console.log(`Adding headline...`)
    banner.print(font, 380, 250, headline);
    await banner.writeAsync('/tmp/1500x500_final.png');
}

async function getLatestArticleHeadline() {
    console.log(`Retrieving headline...`)
    const rss = await Feed.parse(`${getVariable('RSS_FEED')}`)
    const title = rss.items[0].title
    console.log(`Retrieved headline: ${title}`)
    // add padding left & right to align it properly
    const padding = ' '.repeat(Math.ceil((60 - title.length) / 2))
    return `${padding}${title}${padding}`;
}

async function saveAvatar(user, path) {
    console.log(`Retrieving avatar...`)
    const response = await axios({
        url: user.profile_image_url_https,
        responseType: 'arraybuffer'
    })
    await sharp(response.data)
        .resize(widthHeightFollowerImage, widthHeightFollowerImage)
        .toFile(path)
}

async function getImagesOfLatestFollowers() {
    console.log(`Retrieving followers...`)
    try {
        const data = await twitterClient
        .accountsAndUsers
        .followersList({
            screen_name: getVariable('TWITTER_HANDLE'),
            count: numberOfFollowers
        })
        await Promise.all(data.users
            .map((user, index) => saveAvatar(user, `/tmp/${index}.png`)))
      } catch (err) {
        console.log(err)
      }

}

const twitterClient = new TwitterClient({
    apiKey: getVariable('TWITTER_API_KEY'),
    apiSecret: getVariable('TWITTER_API_SECRET_KEY'),
    accessToken: getVariable('TWITTER_API_ACCESS_TOKEN'),
    accessTokenSecret: getVariable('TWITTER_API_ACCESS_SECRET'),
});

exports.handler = async () => {
    await getImagesOfLatestFollowers()
    const title = await getLatestArticleHeadline()
    await createBanner(title)
    await uploadBanner()
    return {
        statusCode: 200,
        body: JSON.stringify({ status: 'ok' }),
      };
}

The background image I use is created by Canva Twitter Header Tool you can create an amazing header even without being good at designing things.

For Twitter API to let you download your follower info, you need to have something called Elevated API level access. More about it here.

I decided to deploy it as Netlify function. So my code is saved in the netlify/function/header.js file.

To launch this locally you can do

npm run-func netlify/functions/header.js handler

You can add this into your package.json file like this:

{
    "scripts": {
        "generate": "run-func netlify/functions/header.js handler"
    },
    "dependencies": {
        "axios": "^0.24.0",
        "jimp": "^0.16.1",
        "rss-to-json": "^2.0.2",
        "run-func": "^1.0.5",
        "sharp": "^0.29.3",
        "twitter-api-client": "^1.4.0"
    }
}

I store my assets in the netlify/functions/assets folder. For Netlify to deploy those files with your function you need to tell it so. You can do it with netlify.toml file in the root of your project.

[functions]
  included_files = ["netlify/functions/**"]

To deploy to Netlify, just push all your code to GitHub. Login/signup to Netlify and choose your GitHub repo. Netlify will do all the magic for you. In a few seconds they will provide you with a URL you can call to trigger your function.

Great. Now we need to run this regularly so that we can catch all the new followers and articles. To do so I decided to use EasyCron. It's a super easy-to-use platform where you can say. OK call this URL every minute. For our use case, this is will be enough and will be free.

Now we have it all. We can enjoy our awesome free dynamic Twitter header.

If you like this article you can follow me on Twitter.

Reusing Promises in JavaScript

Pavel Polívka — Wed, 01 Dec 2021 20:34:52 +0000

Lately, we started a project to improve the performance of our main app. We identified a few API calls we were calling a lot. Results of these calls can change but not very very often so it's not an issue to cache the result for a minute or so.

So I implemented a very easy cache that will reuse active promises and returns already resolved results for a minute after an initial resolution.

This article will go over the code in detail.
Let's start by simulating a parametrized API call.

function getData(key){
    return new Promise(function(resolve, reject) {
    console.log('starting get ' + key)

    setTimeout(() => {
        console.log('ending get ' + key)
        resolve(key);
    }, 1000);
  })
}

Easy enough.

Now we need a few variables where we store our promises, results, and resolution times. We will also create a new function that we will be calling to get the cached results.

const _cacheValues = new Map();
const _cacheResolvedTime = new Map();
const _cachePromises = new Map();

const getDataCached = function (key) {
}

The _cacheValues will hold already resolved values, _cachePromises will hold Promises in progress and _cacheResolvedTime will hold a time when the promise for the key was resolved last.

Now we will add a simple if statement that will be the basic stone of our cache.

if (_cacheValues.has(key)) {
  return Promise.resolve(_cacheValues.get(key));
} else if (_cachePromises.has(key)) {
        return _cachePromises.get(key);
} else {
  const promise = new Promise(function (resolve, reject) {
    return getData(key).then(data => {
      _cacheValues.set(key, data);
      _cachePromises.delete(key);
      const now = new Date().getTime();
      _cacheResolvedTime.set(key, now);
      resolve(data);
    });
  });
  _cachePromises.set(key, promise);
  return promise;
}

If we already have a value for a key let's return that.
If we have a Promise in progress return that.
If we have no data for that key, we will trigger the original method. This trigger will be wrapping its promise so that we fill our cache on resolve.

Now we will add the time to the live feature. At the start of our new method, we will add.

const now = new Date().getTime();

if (_cacheResolvedTime.has(key)) {
  if ((now - _cacheResolvedTime.get(key)) > 60000) {
  _cacheResolvedTime.delete(param);
  _cacheValues.delete(key);
  _cachePromises.delete(key);
  }
}

If we have it resolved and the resolution time is more than 60 seconds, we will remove it from our caches and continues to witch the rest of our logic.

Now we are done, we can test our code.

getDataCached('a').then(result => { console.log('first call outer: ' + result);
    getDataCached('a').then(result => { console.log('first call inner: ' + result); });
});

getDataCached('b').then(result => { console.log('first call outer: ' + result);
    getDataCached('b').then(result => { console.log('first call inner: ' + result); });
});

getDataCached('a').then(result => { console.log('second call outer: ' + result);
    getDataCached('a').then(result => { console.log('second call inner: ' + result); });
});

setTimeout(() => {
    getDataCached('a').then(result => { console.log('later call outer: ' + result);
    getDataCached('a').then(result => { console.log('later call inner: ' + result); });
});
}, 70000);

You can see the console result and this whole code in this Fiddle.

If you like this article you can follow me on Twitter.

Adding reading time stat in your Next.js blog

Pavel Polívka — Wed, 17 Nov 2021 13:03:53 +0000

I recently started my journey to improve my frontend/javascript skills. So the obvious way is by adding a bunch of new features into my blog.

The latest thing I added is this little info on how long the article will take you to read. This is on pretty much every blogging platform and I always wanted it.

The theory behind this number is that people on average read around 225 words per minute. So we need to count the words in the article and divide it by 225.

So the basic code for this would be something like this:

const wordsPerMinute = 225

export function readingTime(text) {
    return Math.ceil(wordCounter(text) / wordsPerMinute)
}

Now we need to count the words. I started by naively splitting by white space and counting. I was not happy with this result as I have a lot of code in my articles and it counted a lot of syntax as words.

So I decided to split by whitespace and check if each token is a word. This is done by checking if it contains some alphanumeric token.

My implementation:

function wordCounter(input) {
    const text = input.split(/\s+/)
    let wordCount = 0
    for (let i = 0; i < text.length; i++) {
        if (text[i] !== ' ' && isWord(text[i])) {
            wordCount++
        }
    }
    return wordCount
}

function isWord(str) {
    let alphaNumericFound = false
    for (let i = 0; i < str.length; i++) {
        const code = str.charCodeAt(i)
        if ((code > 47 && code < 58) || // numeric (0-9)
            (code > 64 && code < 91) || // upper alpha (A-Z)
            (code > 96 && code < 123)) { // lower alpha (a-z)
            alphaNumericFound = true
            return alphaNumericFound
        }
    }
    return alphaNumericFound
}

I am very happy with my results. I crosspost most of my articles on Medium and my result times are pretty much the same as their results. In some cases, I have a minute difference but I can live with that.

If you like this article you can follow me on Twitter.

Adding pagination into Next.js blog

Pavel Polívka — Thu, 11 Nov 2021 20:14:57 +0000

I recently redid my blog with Next.js. I used the amazing Next.js tutorial and I was very happy with it. But as time went on and I wrote more and more articles it became apparent that I need to add paging. I am not an expert on Next and it turns out that adding paging will not be that easy. I used static generation for my listing page and generating all the pages is not an option. I decided to switch to server-side rendering for SEO reasons but also I wanted to switch pages on the fly.

Adding API

First thing I needed to add an API call that would provide paging info and list posts.
I created a posts directory in a root api folder and in there I created a [page].js file. This file will be my api handler.

// api/posts/[page].js

import {getSortedPostsData} from "../../lib/posts";


export default function (req, res) {
    const { page } = req.query
    const allPostsData = getSortedPostsData()
    const perPage = 9
    const totalPosts = allPostsData.length
    const totalPages = totalPosts / perPage
    const start = (page - 1) * perPage
    let end = start + perPage
    if (end > totalPosts) {
        end = totalPosts
    }

    res.status(200).json({
        currentPage: page,
        perPage: perPage,
        totalCount: totalPosts,
        pageCount: totalPages,
        start: start,
        end: end,
        posts: allPostsData.slice(start, end)
    })
}

This is pretty straightforward code. It's doing some stats from an array of all posts.
Side note here, if you are deploying to Vercel, your api calls are deployed as serverless functions and you need to tell Vercel to add your markdown files to the serverless deploy. This is done via root vercel.json file.

{
  "functions": {
    "api/posts/[page].js": {
      "includeFiles": "posts/**"
    }
  }
}

The root posts directory is the place where I have all the markdown files.

Modifying blog listing page

I used the blog listing page pretty much out of the next.js tutorial. I was using static page generation. So the first thing I have done was to change it to server-side rendering.

Blog.getInitialProps = async ({ query }) => {
    const page = query.page || 1; //if page empty we request the first page
    const response = await fetch(`${server}/api/posts/${page}`)
    const posts = await response.json()
    return {
        totalCount: posts.totalCount,
        pageCount: posts.pageCount,
        currentPage: posts.currentPage,
        perPage: posts.perPage,
        posts: posts.posts,
    }
}

It fetches our new api call and returns it as our component properties.
The server variable is different for localhost and for prod. We need to specify the full path as this will be called from the server.

const dev = process.env.NODE_ENV !== 'production';
export const server = dev ? 'http://localhost:3000' : 'https://ppolivka.com';

I am using next/router to navigate between pages. And to make all the things more user-friendly I added a loading animation on route changes.

const [isLoading, setLoading] = useState(false);
const startLoading = () => setLoading(true);
const stopLoading = () => setLoading(false);

useEffect(() => {
    Router.events.on('routeChangeStart', startLoading);
    Router.events.on('routeChangeComplete', stopLoading);

    return () => {
        Router.events.off('routeChangeStart', startLoading);
        Router.events.off('routeChangeComplete', stopLoading);
    }
}, [])

To render the posts or the loading I have a if in this style.

let content;
if (isLoading) {
    content = (
        <div className={styles.loadWrapper}>
            <Spinner animation="border" role="status">
                <span className="visually-hidden">Loading...</span>
            </Spinner>
        </div>
    )
} else {
    //Generating posts list
    content = (
        <>
            {props.posts.map(({ id, date, title, image, description }) => (
                <Card className={styles.item}>
                    <Card.Img variant="top" src={image} width={360} height={215} />
                    <Card.Body>
                        <Card.Title>
                            <Link href={`/posts/${id}`}>
                                <a>
                                    {title}
                                </a>
                            </Link>
                        </Card.Title>
                        <Card.Subtitle className="mb-2 text-muted"><Date dateString={date} /></Card.Subtitle>
                        <Card.Text>
                            {description}
                        </Card.Text>
                    </Card.Body>
                </Card>
            ))}
        </>
    );
}

For the actual pagination navigation I used awesome component react-paginate.

<ReactPaginate
    previousLabel={'<'}
    nextLabel={'>'}
    breakLabel={'...'}
    breakClassName={'break-me'}
    activeClassName={'active'}
    containerClassName={'pagination'}
    subContainerClassName={'pages pagination'}
    initialPage={props.currentPage - 1}
    pageCount={props.pageCount}
    marginPagesDisplayed={2}
    pageRangeDisplayed={5}
    onPageChange={paginationHandler}
/>

It's referring the pagination handler function, that has the actual navigation logic.

const paginationHandler = (page) => {
    const currentPath = props.router.pathname;
    const currentQuery = props.router.query;
    currentQuery.page = page.selected + 1;

    props.router.push({
        pathname: currentPath,
        query: currentQuery,
    })

}

You can see the whole blog page in this Gist.

If you like this article you can follow me on Twitter.

What to expect from Java interview in 2021

Pavel Polívka — Mon, 08 Nov 2021 18:05:35 +0000

In my previous job, I did a lot of interviews for our Java developer positions. We had a typical modern Java stack based on Spring framework and relational database. We usually hired junior devs right after school so our interview process was designed to find talented people with potential, not encyclopedical knowledge.

We had one in-person round and take a home coding assignment. This article will try to cover both.

In-person round

This was the more important round of our process. Basically usually a team lead of the team that was hiring and one senior dev was conducting it. The goal was to determine if the person would be a good fit for a team, had some technical thinking capabilities and the most important could communicate.

In the first part, we had a small talk portion, that was around previous experiences, either their current job or a school project.

Typical questions here would be:

What was the last project you worked on?
What have you learned recently?
What would be your dream project?

In the second part we did few technical questions. Around some basic Java or Spring things.

Typical questions here:

Explain static keyword.
Explain how to compare objects in Java. Equals and hasCode.
Inversion of control and dependency injection.

In the third part, we had a technical challenge to solve. It was a simplified real problem we had to solve during last year (we were changing this to keep it interesting). It did not have one solution. Involved designing a simple alghoritm that strongly suggested use of recursion, but could be solved numerous ways.

The ultimate goal was to for the candidate to design a data structructure and use it in the simple alghoritm. We wanted candidate to communicate what they are doing and we usually helped them talk through everything. We never looked at the syntax or cared what language they used. We wnated to see the capabilities to design the structure to store the data and some basic thinking to see of they at least were able to talk through what should be done.

In the last part we gave space for any questions.

Take a home coding challenge

We had a very easy take a home coding challenge that was basically to implement CSV parser. Parse data in the CSV we provided and print it as HTML table and excel file.

We looked at theese concepts in the final code:

Polymorphism
Logging
Library usage
Comments
Unit testing

We did not require a perfect solution, we even did recomend to implement as much as they are feel like and then just write comments explainging how to finish it. We did not had a time constrain and ultimate goal here was to see if the candidate would be able to write code at our standards.

Hope this article helped you can always ask me about anytihng on my Twitter.

Debugging Maven tests in IntelliJ IDEA

Pavel Polívka — Fri, 24 Sep 2021 12:56:00 +0000

We all know it. You write the test, it works when you click the Run button in IntelliJ but it fails when run with mvn clean test.

It can be all sorts of issues, related to jar packaging, etc... You add the breakpoint into your test, but how to convince Maven's Surefire plugin to debug mode?
How to use awesome power set of IntelliJ debugging tools?

Remote debug to the rescue.

IntelliJ IDEA

Setting up remote debug for your Tomcats, etc can be very cumbersome, but doing it for Maven Surefire plugin tests is actually very easy.

In IntelliJ we create new run Configuration.

We can just add new one and leave the defaults in.

Maven

Now we execute the maven run in debug mode.

mvn test -Dmaven.surefire.debug

This will start the tests in debug mode. Read the terminal text and when there is line that the debug mode started, start the IntelliJ run config.
It will attach itself to the executing test, and you can use all the tools IntelliJ provides.

If you want to execute just one concrete test, you can do it like so:

mvn test -Dtest=TestClass.java#testMethod -Dmaven.surefire.debug

If you like this article you can follow me on Twitter.