DEV Community: Dmitry Drepin

Spring AI: An Engineer’s Answer to the HR Black Hole

Dmitry Drepin — Mon, 15 Sep 2025 00:05:16 +0000

Building a local AI candidate agent with RAG, Spring AI, and Ollama

When you’re a candidate flooded with dozens of offers and messages every week, it’s nearly impossible to filter, prioritize, and respond smartly. Some opportunities deserve attention, but many don’t match your skills, goals, or expectations. Without a tool to manage this flow, your voice gets lost in the noise — and you risk missing the right role.
That’s why I built a prototype of local-first AI assistant: not to replace interviews or negotiations, but to help candidates filter irrelevant offers early, highlight what matters, and keep control of their data.
It was built to represent a candidate during pre-screening: automate repetitive Q&A (availability, salary range, basic skills), surface relevant opportunities, and schedule interviews — all while keeping candidate data local. This tool is explicitly for prescreening automation, not for replacing human interviews or “cheating.” Below I explain how the system is built, why the design choices matter, how components connect, and what consequences those choices have.

1. High-level goal & motivation

I needed a way to rapidly filter and respond to dozens/hundreds of inquiries (think LinkedIn volume) without manually replying to each. The prototype’s aims were:
• Give the candidate a consistent, privacy-preserving voice for pre-screening.
• Automate repetitive tasks so HR and candidates get to real interviews faster.
• Keep all sensitive data local (no third-party cloud inference by default).
• Build something runnable and useful in a week — a practical POC, not a product.
That constraint (local, fast, privacy-first) shaped every technical decision below.

2. System architecture (five layers)

I designed the prototype as a modular stack with clear separation of concerns:

+---------------------------------------------------------------+
|                        Candidate Frontend                     |
|  (web app, chat, CLI)                                         |
+------+------------------+-----------------+-------------------+
       |                  |                 |                   
       v                  v                 v                   
+-------------------+  +---------------------------+     
|  Spring Boot REST |  |   Streaming WebSocket     |     
|  (Spring AI App)  |  |      (Optional)          |     
+-------------------+  +--------------------------+      
       |                                              
       v                                              
+---------------------+         +-------------------+
|   Spring AI Layer   +-------->|   Tool/Advisor    |
|      (ChatClient,   |         |    Pattern        |
|   Advisors, RAG,    |         +-------------------+
|   Memory, Tooling)  |                 |
+---------------------+                 |
       |                (tool calls)    |
       v                 -------------- +---------------+
+-------------------+       +-------------------------+
|   Ollama Server   | <---> |     Vector Store/RAG    |
|   (Local LLM API) |       |  (ChromaDB/Pinecone/...)|
+-------------------+       +-------------------------+

Backend — Java 21+, Spring Boot, Spring REST, Spring Data/Hibernate.
Frontend — React + Vite with Zustand; SSE (Server-Sent Events) for streaming responses.
Ollama (Local LLM runtime) — hosts embedding and generative models locally and defines compute usage (CPU/GPU).
Data layer — PostgreSQL with pgvector for embeddings and PostgresChatMemory for chat context.
Infrastructure / Postgres ops — Docker / Docker Compose (Kubernetes-ready), Nginx reverse proxy, pgvector tuning and backups.

Each part represents a responsibility; the system is designed so each piece can be replaced or scaled independently.

The overall request path is:

3. Core design pattern: advisors (Chain of Responsibility)

Spring AI provides an advisors mechanism effectively — a Chain of Responsibility. In my app, AdvisorsProvider is the single place where the chain is assembled and configured (system prompts, model configuration, chat memory, and each advisor tuning).

Why use this? Because pre-screening conversation requires multiple small, ordered steps: expand the query, attach history, fetch facts, rerank, log, and finally generate. The chain makes that sequence explicit and easy to extend and manage.
Each advisor:
• Receives the request and context,
• May read or write to the context (this is MCP-ready behavior),
• May call out to external services (vector store, reranker),
• Passes a modified request to the next advisor.
This modularity makes it safe to add compliance checks, sentiment analysis, or anything else without changing the core ChatClient logic.

4. End-to-end workflow (concrete example)

I'll follow one HR question end-to-end to make the flow concrete.
HR:

What is your salary expectations?

Flow:
A. UI → Spring REST

HR types the question; frontend opens an SSE connection to the backend endpoint /chat/stream?question=....

B. ChatService wraps a ChatClientRequest:

contains the original question,
pulls recent session context from PostgresChatMemory (max N messages),
sets up a response SSE emitter.

C. Advisors Chain (in order):

ExpansionQueryAdvisor: expands the question into a richer search query:

salary range expected compensation benefits negotiation developer role Europe Austria 5+ years experience Quarkus experience must

Purpose: increase RAG recall for position-specific facts.

MessageChatMemoryAdvisor: consider last messages; ensures multi-turn context.
SimpleLoggerAdvisor: logs query for observability (and metrics: RAG hits/misses).
RagAdvisor: core retrieval logic:
- Use expanded query for pgvector similarity search (vector store).
- BM25 rerank to boost short, high-precision documents.
- Neural cross-encoder rerank (optional) for top-N results.
- Cache top results in a ConcurrentHashMap to avoid repeated expensive retrieval.
- FinalLoggerAdvisor: logs final documents passed to the model.

D. Generative model (Spring AI ChatClient → Ollama):

The ChatClient submits prompt + retrieved context to the local Ollama model with configured options (temperature, topK, topP, repeatPenalty, model).
Model returns text incrementally; ChatClient streams tokens back over SSE.

E. UI: HR gets a streamed, polished candidate reply:

Based on my experience and location, my expected salary range is 80–90k EUR. RECOMMENDATION: YES — aligns with the role.

F. Memory update:
PostgresChatMemory persists the turn (question, expanded query, final response, RAG references). If MCP exists, it will version this turn and store document references.

5. The `RAGAdvisor` internals and consequences

What RAG does here, in details:

Vector Search (pgvector): I precompute embeddings for each candidate artifact (CV, cover letter, past notes, detailed candidate description, etc) at startup. A similarity search returns a candidate set for the expanded query.

Consequence: Pre-embedding speeds retrieval, but embedding model choice (and embedding dimensionality) affects disk and RAM usage.

BM25 Rerank: BM25 provides keyword-based reweighting with tunable parameters: k (saturation) — how term frequency saturates, b (document length normalization), delta — a small boost to favor short documents.

Consequence: Good for short snippets (e.g., "expected: 80k"), BM25 is fast and cheap.

Neural rerank (cross-encoder): Reorders top candidates by scoring query-document pairs jointly with a transformer.

Consequence: Much higher CPU/GPU cost but increases precision when top N is noisy.

Caching: If a query repeats (session-level), cache saves the reranked docs.

Consequence: Faster responses and lower cost on repeated interactions; careful TTL and invalidation policies are required for correctness.

How it affects the model output
The generative model receives a compact “context bundle” (top-K documents + system prompt + conversation history). If the RAG stack is precise and recall is high, the model produces factual answers grounded in candidate data. If RAG returns weak or unrelated documents, the model may hallucinate or produce vague responses — hence the importance of thresholds and reranking.

6. Embeddings layer and Postgres (`pgvector`) considerations

I use mxbai-embed-large to encode candidate documents into vector embeddings and store them in PostgreSQL with pgvector.
At startup, documents are converted and indexed; updates are supported (new CV versions/writes flush and re-embed).
Similarity threshold filters irrelevant docs.

Embeddings & Postgres (pgvector) — Why They Matter

When HR asks a question like “Do you have 5 years of Kubernetes experience?”, the system can’t just do a text search across your CV. Plain SQL queries or LIKE %Kubernetes% are too literal — they miss meaning, synonyms, and context.
That’s where embeddings come in.
Think of an embedding as a mathematical fingerprint of a sentence or paragraph. Instead of storing words, we convert the text into a long vector of numbers — usually hundreds of dimensions. Texts that “mean” the same thing will have fingerprints that are close to each other in vector space.

“5 years of Kubernetes”
“Half a decade running K8s clusters in production”

These two sentences look very different in raw text but sit right next to each other when turned into embeddings.

Why pgvector?

Postgres is our database backbone, and pgvector is just an extension that lets Postgres understand and store these big vectors. More importantly, it can do vector similarity search — i.e., “find me the top 3 paragraphs in my CV that are closest in meaning to this recruiter’s question.”
So instead of string-matching, we ask:
“Which stored embeddings are nearest neighbors to the embedding of this recruiter’s question?”
That gives us the right chunk of context to feed into the LLM, so the response is grounded in truth instead of hallucination.

Practical considerations

Indexing: pgvector supports indexes like IVFFlat that make similarity search fast even if you store millions of vectors. For my prototype (CVs, notes, prior chats), it’s small scale, but the same design scales to enterprise data.
Chunking strategy: documents must be split into sensible paragraphs or sections before embedding. Too big = expensive + fuzzy. Too small = loses context.
Cost & performance tradeoff: Every embedding call is extra compute. A local embedding model (like from Ollama) keeps it cheap, while API-based embeddings cost more but can be higher quality.
So the embeddings layer is essentially the search engine brain of this system. Postgres + pgvector is the memory warehouse, embeddings are the fingerprints, and similarity search is how we fetch the right memories before answering HR.

7. Ollama & model parameter math (inline, practical + intuition)

I run both embedding and generative models via Ollama locally. When configuring Ollama in the Spring AI ChatClient, a few parameters completely change how the model behaves.

ChatClient.builder(chatModel)
    .defaultOptions(OllamaOptions.builder()
        .temperature(expansionQueryTemperature)
        .topK(expansionQueryTopK)
        .topP(expansionQueryTopP)
        .repeatPenalty(expansionQueryRepeatPenalty)
        .model(modelName)
        .build())
    .build()

Now, here’s the thing: each of these parameters shapes the model’s behavior in a very tangible way.

temperature is like the creativity dial. With a low value the model always picks the “safest” word, so responses sound factual and consistent. Push it higher and the model starts getting creative, even a bit unpredictable. For prescreening, I keep it low so the agent doesn’t invent benefits or experience.

topK controls how many tokens the model can even look at. If you set it to 1, it’s basically locked to one possible choice every time. If you open it up (say 20–40), it can still vary phrasing without going off track.

topP works a bit differently: instead of counting words, it says “include just enough words until you cover, for example, 90% of the probability mass.” It makes responses more natural than just topK alone. I usually pair it with topK for balance.

repeatPenalty is the guardrail against loops. Without it, the model might say “I have 5 years, 5 years, 5 years…” forever. A gentle penalty (around 1.1) is enough to keep things fresh but still natural.

model is the biggest decision. Small ones (4B-7B) run on CPUs or modest GPUs but don’t go very deep. Larger ones (13B, 30B, 70B) give better answers but eat memory and VRAM quickly. For local-first HR prescreening, I’ve found 4B–13B hits the right balance between speed and quality.

Together, these knobs give you fine-grained control over the “voice” of your candidate AI: factual and concise vs. more conversational and human-like.

8. AdvisorsProvider — annotated core code (key excerpts)

Below I include the essential, annotated pieces (edited for clarity). This is the class that configures the ChatClient with advisors and system prompts.
Initialization & properties

@Value("${spring.ai.ollama.chat.max-messages}")
public int MAX_MESSAGES_MEMORY;
@Value("${spring.ai.ollama.chat.model}")
private String modelName;
// expansion query config
@Value("${spring.ai.ollama.expansion-query-temperature}")
private Double expansionQueryTemperature;
@Value("${spring.ai.ollama.expansion-query-top-k}")
private int expansionQueryTopK;
@Value("${spring.ai.ollama.expansion-query-top-p}")
private Double expansionQueryTopP;
@Value("${spring.ai.ollama.expansion-query-repeat-penalty}")
private Double expansionQueryRepeatPenalty;
// chat client defaults
@Value("${spring.ai.ollama.chatclient-query-temperature}")
private Double chatclientQueryTemperature;
@Value("${spring.ai.ollama.chatclient-query-top-k}")
private int chatclientQueryTopK;

// ...
Values are loaded from application.properties/yaml. Profiles can override them (factual / creative / summarization), but I left profiles optional.
System prompt & expansion prompt (two critical templates)

public static final PromptTemplate CV_SCREENING_EXPANSION_PROMPT = PromptTemplate.builder()
    .template("""...Question: {question} Expanded query:""").build();

public static final PromptTemplate SYSTEM_PROMPT = new PromptTemplate("""
system: |
You are %Your Name% a %your role%... Answer in first person, brief, and to the point.
... Strategy: Context fact → question → answer → position assessment
""");

System prompt encodes identity, tone, and rules.

System Prompt

The system prompt is the foundation of the assistant’s behavior. It’s not about answering one question but about setting the overall role and rules of engagement. Imagine it as the constitution of the candidate’s AI voice: it defines tone, boundaries, and what the assistant will never do.
For example, my assistant is always reminded:
“You help filter and manage inbound offers. You never exaggerate, you never invent skills, you only prescreen and keep conversations polite but firm.”
With this in place, no matter how many advisors or steps are involved later in the chain, the assistant always stays within these guardrails. That’s how I make sure it doesn’t accidentally oversell me or leak context it shouldn’t.

Expansion Prompt

The expansion prompt works very differently — instead of defining rules, it takes a short, vague question and expands it into a rich, structured query. Recruiters often ask something minimal like:
“What’s your salary range?”
On its own, that’s too little for smart retrieval. The expansion prompt reformulates it into something much broader:
“Salary range, expected compensation, benefits, negotiation, backend developer role, Europe, Austria, 5+ years experience required, Quarkus experience required.”

Now the advisors can actually dig into my CV, prior negotiations, or stored context and find the right pieces to answer. Without this step, retrieval would miss half of the relevant details.

So, in short: the system prompt keeps the assistant grounded and consistent, while the expansion prompt makes the conversation intelligent enough to find context in the first place. One sets the rules, the other makes the search smarter — together they form the backbone of the pipeline.

ChatClient bean (default options + advisors)

@Bean
public ChatClient chatClient(ChatClient.Builder builder) {
    return builder.defaultAdvisors(getAdvisors())
            .defaultOptions(OllamaOptions.builder()
                    .temperature(chatclientQueryTemperature)
                    .topP(chatclientQueryTopP)
                    .topK(chatclientQueryTopK)
                    .repeatPenalty(chatclientQueryRepeatPenalty)
                    .model(modelName)
                    .build())
            .defaultSystem(SYSTEM_PROMPT.render())
            .build();
}

This binds the advisor chain and default model options to the ChatClient.

Advisors list (core)

private List<Advisor> getAdvisors(){
    return List.of(
        ExpansionQueryAdvisor.builder(
            ChatClient.builder(chatModel)
                .defaultOptions(OllamaOptions.builder()
                    .temperature(expansionQueryTemperature)
                    .topK(expansionQueryTopK)
                    .topP(expansionQueryTopP)
                    .repeatPenalty(expansionQueryRepeatPenalty)
                    .model(modelName).build())
                .build(), CV_SCREENING_EXPANSION_PROMPT).build(),

        MessageChatMemoryAdvisor.builder(getChatMemory()).order(AdvisorType.HISTORY.getOrder()).build(),

        SimpleLoggerAdvisor.builder().order(AdvisorType.LOGGER.getOrder()).build(),

        RagAdvisor.build(vectorStore, ChatClient.builder(chatModel)
                .defaultOptions(OllamaOptions.builder()
                    .temperature(expansionQueryTemperature).topK(expansionQueryTopK)
                    .topP(expansionQueryTopP).repeatPenalty(expansionQueryRepeatPenalty)
                    .model(modelName).build()).build())
            .bm25Engine(BM25RerankEngine.builder()
                .defaultK(bm25K).defaultB(bm25B).defaultDelta(bm25Delta).build())
            .searchRequest(SearchRequest.builder()
                .topK(searchRequestTopK)
                .similarityThreshold(searchRequestSimilarityThreshold).build())
            .build(),

        SimpleLoggerAdvisor.builder().order(AdvisorType.FINAL_LOGGER.getOrder()).build()
    );
}

This exact ordering (expansion → memory → logger → rag → final logger) is key: expansion helps retrieval; memory provides multi-turn context; BM25/NN rerank ensure quality.

9. Mock SSE snippet & annotated memory flow (compact)

Backend SSE endpoint:

@GetMapping(value = "/chat/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<ServerSentEvent<String>> streamChat(@RequestParam String question) {
    return chatService.streamAnswer(question).map(ans -> ServerSentEvent.builder(ans).build());
}

Frontend (React):

const es = new EventSource(`/chat/stream?question=${encodeURIComponent(q)}`);
es.onmessage = e => appendMessage(e.data);

Annotated flow (memory/cache):
ChatService writes HR question to PostgresChatMemory. ExpansionQueryAdvisor generates expanded query; expanded query stored in context.
RagAdvisor checks session cache: if miss → pgvector similarity search → BM25 → optional neural rerank → put result into cache.
ChatClient generates text using retrieved docs; stream chunks to SSE.
PostgresChatMemory persists the final turn (with references to RAG docs).

10. MCP: technical integration and effects (how & why)

MCP (Model Context Protocol) is on my roadmap — here’s how I’d integrate it and why it matters.

How advisors would use MCP

Read/Write API: each advisor would be given an MCP client to read the latest context fragment and write updates atomically.
Document references: RAGAdvisor writes pointers (document id, offset) to MCP rather than full text, enabling traceability.
Versioning: each context update is versioned; ChatClient can request a specific version snapshot to reproduce past outputs.
Per-request metadata: MCP can store overrides (profile=“factual”), flags (sensitive=true), or QA checks.

Practical consequences for RAG/model responses

Better grounding: the generative model receives not just raw retrieved text, but MCP-provided provenance links and context snapshots.
Auditability: every generated answer can be traced to the documents and the context version that produced it.
Dynamic updates: advisors can add facts mid-request (e.g., calendar availability) and MCP will ensure the generative model sees them.

Example (calendar integration)
Availability check: RAGAdvisor queries MCP for candidate calendar references (or calls calendar service); MCP writes back confirmed time slots; the ChatClient uses that to respond with precise start dates.

11. Resource trade-offs & operational notes

Embeddings vs Generative models:
Embeddings storage (pgvector) consumes disk and RAM for indexes; vector search is I/O and CPU bound depending on index type.
Generative models (esp. >7B) need GPU or lots of RAM for responsive inference.
Local-first reality: choose quantized or smaller generative models if you must run on constrained hardware, or provision GPU for heavier models.
Scaling: containerized architecture is Kubernetes-ready; for enterprise you’ll move to orchestrated pods, GPU node pools, and autoscaling.
Caching policy: tune cache TTLs to allow fresh context while avoiding repeated expensive reranks.

12. Use-case boundaries and ethical guardrails

• This prototype is for prescreening automation. It’s designed to answer routine recruiter questions, schedule interviews, and filter irrelevant offers.
• It does not replace human interviews or decisions. Final evaluation, negotiation, and cultural fit are human tasks.
• Privacy-first: Candidate data is processed locally; nothing is sent to external services by default. If you integrate cloud models, document that risk explicitly and get consent.

13. Practical advice (what I’d tell engineers when they clone this repo)

System prompt is critical. Think of it as your policy and persona. Test and iterate it. Use it to enforce rules (e.g., “don’t invent facts; say ‘I don’t know’”).
Tune retrieval first. RAG quality dictates factuality. Get embeddings, similarity thresholds, and BM25 right before trying to tune temperature.
Start small with models. Use a quantized 4B model locally; if you need better reasoning, move to GPU-backed 7B–13B models.
Make memory explicit. Use PostgresChatMemory and design your advisors to depend on versioned context (MCP-ready).
Monitor metrics. Track RAG cache hits/misses, BM25 rerank times, and token latency to find bottlenecks.

14. Conclusion — succinct

I built a local, modular AI agent that represents a candidate during prescreening: it expands HR queries, retrieves relevant facts via RAG, refines those facts with BM25 and optional neural rerank, and uses a local Ollama model to generate concise replies. The system is privacy-first, extensible via advisors, and MCP-ready for future context/versioning/auditability. It speeds early-stage hiring workflows while preserving the human role in final decisions.
P.S.
Here are some resources to help you dive into the world of AI agents and RAG:
My local, modular AI agent POC
“Spring AI” course by Evgeny Borisov: If you want to repeat the experiments and understand how to build AI applications, get a 50% discount with the coupon:
Spring AI RAG
Spring AI Pro
Book on RAG: For those who want to study the topic in more depth, I recommend Denis Rothman’s book “RAG and Generative AI” with a 25% discount using the coupon RAG.
RAG and Generative AI (Piter)
Free MCP courses or MCP Bootcamp: If you want to learn the principles of building systems like our Model Context Protocol, I suggest starting with this free course on working with vector databases.

Cool readme on your github profile page with github actions.

Dmitry Drepin — Sat, 30 Sep 2023 10:42:14 +0000

In the world of coding, there's one task many of us dread - writing documentation. Yet, when you start a new project or set up a fresh GitHub repository, those all-important markdown files beckon. Enter the GitHub profile README, a clever feature that lets you infuse your personal touch into your GitHub page. And when you combine this with the power of GitHub Actions, something magical happens: you craft a captivating portfolio-CV page that paints a vivid picture of who you are as a coder.

Creating an engaging GitHub profile with the help of GitHub Actions can be a game-changer for showcasing your skills and personality. While crafting a README for your profile might not be the most thrilling task, it's essential to present yourself effectively in the developer community. Combining GitHub Actions with your profile README allows you to create a dynamic portfolio-CV page that represents you authentically. In today's competitive job market, your CV is only part of the equation; your portfolio and interests matter too.

Your CV is just the tip of the iceberg. Hiring managers are casting a wider net, scrutinizing your portfolio and even your interests. They rely on tools to pluck out pertinent information from resumes, but let's face it – most CVs are stubbornly resistant to easy parsing. Whether it's an ancient PDF or a beautifully designed but enigmatic image, it often doesn't cut it. The consequence? Even brilliant developers find themselves at the bottom of the hiring pile. That's where the profile README steps in. It's not just a CV; it's a user-friendly, easily indexed powerhouse of a developer's journey.It should include not just your CV but also links to your social profiles, blog articles, skills, certifications, GitHub stats, preferred repositories, and even a touch of personal flair to engage the reader.

In my opinion, a README page should have:

Social and contact links.
Blog articles on tech and ideas.
Skills and certifications.
GitHub stats and favorite repositories (if desired).
An auto-generated CV.
A relaxed section.
Contact details.

Here in the article, I will try to describe my own path to create GitHub readme file. So, how do you create a GitHub README that shines? Start by establishing a profile repository bearing your GitHub username. My username is dzmdre, so I created a repository with the name dzmdre. I initialized the repository with README and .gitignore files. I cloned it down and opened it in my favorite editor. In this repository, introduce a "readme.template" file, the secret sauce that fuels your dynamic README.

Create a README Template

Create a new “readme.template” at the root level of my repository. This is the file I will be editing manually, and readme will be auto-generated based on “readme.template” and data received through the rest calls.

Banner Image

Your README's visual appeal often starts with a banner image at the top. You can create a banner featuring a photo from a conference, along with your contact details. I haven’t found something suitable and have chosen some simple picture from Canva site. I added some necessary contacts data and my banner was ready. Back in my repository, I created a new root-level directory named assets, placed the image in the folder and added it in the “readme.template” file.

[![Dmitry's GitHub Banner](./assets/GitHubHeader.png)](https://linktr.ee/drepin)

Social Badges

Then, you can add social badges to your various online profiles using badges from shields.io.
You should have something similar to this:

[![Twitter Badge](https://img.shields.io/badge/Twitter-Profile-informational?style=flat&logo=twitter&logoColor=white&color=1CA2F1)](https://twitter.com/drepindmitry) [![LinkedIn Badge](https://img.shields.io/badge/LinkedIn-Profile-informational?style=flat&logo=linkedin&logoColor=white&color=0D76A8)](https://linkedin.com/in/dmitry-drepin-77107336)

The Introduction Section

Most of the GitHub readme files include only this main part.The main template is:

Here are some ideas to get you started:
- 🔭 I’m currently working on ...
- 🌱 I’m currently learning ...
- 👯 I’m looking to collaborate on ...
- 🤔 I’m looking for help with ...
- 💬 Ask me about ...
- 📫 How to reach me: ...
- 😄 Pronouns: ...
- ⚡ Fun fact: ...

People generally prefer not to delve into extensive self-reflections; it's more effective to demonstrate skills through certifications and the portfolio section. If visitors seek additional information about me, they can explore my website or LinkedIn profile. Keep it concise and straightforward.

GitHub Stats & Wakatime plugin

You can add a lot of Anurag Hazra‘s GitHub ReadMe Stats features:

GitHub Stats Card

By default, the stats card only shows statistics like stars, commits and pull requests from public repositories. To show private statistics on the stats card, you should deploy your own instance using your own GitHub API token.

GitHub Extra Pins

GitHub extra pins allow you to pin more than 6 repositories in your profile using a GitHub readme profile.

GitHub Gist Pins

GitHub gist pins allow you to pin gists in your GitHub profile using a GitHub readme profile.

Top Languages Card

The top languages card shows a GitHub user's most frequently used languages. Top Languages does not indicate the user's skill level or anything like that; it's a GitHub metric to determine which languages have the most code on GitHub. This card shows languages usage only inside your own non-forked repositories, not depending from who is the author of the commits. It does not include your contributions into another users/organizations repositories. Currently this card shows data only about first 100 repositories. This is because GitHub API limitations which cause downtimes of public instance.

Wakatime Stats Card

WakaTime is committed to making time tracking fully automatic for every programmer. By creating opensource plugins for IDEs and text editors, it gives powerful insights about how you code. It is possible now demonstrate these statistics in your GitHub profile.
What’s next? Next up, showcase your skills, awards, and certifications.

Skills, Awards, and Certifications:

Avoid using an unordered list for this section, as it can become challenging to read. Instead, the key is to categorize and group your skills and certifications, making them more organized and easier to manage. The specific edits required for this section depend on the number of skills, certifications, and other factors. If you have an extensive list, consider utilizing small badges from shields.io where applicable and hide outdated information.

Latest Blog Posts & random quote

In today's world, having more than just an impressive CV is essential; it's equally crucial to maintain a personal IT blog, sharing your insights and opinions. For programmers, a personal IT blog serves as an invaluable platform for various reasons.
Firstly, it's a stage to showcase their expertise, skills, and profound knowledge within the tech industry. Regular blog posts allow programmers to exhibit their problem-solving abilities, coding prowess, and innovative thinking, all of which are invaluable assets in their professional journey.
Secondly, a personal IT blog keeps programmers in sync with the ever-evolving industry trends and technologies. Writing about new tools, frameworks, or programming languages compels them to thoroughly research and understand these innovations, enriching their knowledge base.
Moreover, a blog becomes a repository for their learning experiences. Programmers can document their challenges, breakthroughs, and projects, creating a valuable resource not just for themselves but for the broader developer community. This knowledge sharing fosters collaboration, networking, and the overall growth of the IT community.
Lastly, a well-maintained IT blog elevates a programmer's professional credibility and can open doors to consulting opportunities, speaking engagements, or even job offers. It acts as a digital portfolio that potential employers or clients can consult when assessing the programmer's skills and expertise.
That's precisely why having links to your blog articles on your GitHub page is of paramount importance. It's a gateway for others to tap into your knowledge, experience, and thought leadership within the tech world.
To automate the process of updating your README with blog posts and a random quote, you can create a GitHub Action workflow. The workflow will dynamically fetch data and inject it into your "readme.template" file. This keeps your profile fresh and engaging.
To inject my blog feed into the README.md file, I followed Renan Franca article Create a Github stunning profile 💫 (by dynamically listing your recent blog posts)
The hard work will eventually be delegated to separate file that the GitHub Action workflow will run, but in order for that file to know where to inject the content, it requires a certain pattern in the template.
For now, I put the following under the blog post section in the „readme.template” file:

Very much like the blog post section, a GitHub Action workflow will run a script that will look for a pattern in the „readme.template” file and inject a random quote.
I put the following pattern in the quote section:

> {quote}
>
> <p>{quote_author}</p>

To make this happen a GitHub Action workflow will run a script that will look for a pattern in the „readme.template” and inject a random quote.

You should have 4 steps to create in index.js:

The index.js File
There are four steps this file needs to complete:
· Create a variable to reference the README.template.md file

· Make the request to the rest service

· Look through the „readme.template” content and replace the static patterns ({quote} & {quote_author}) with the dynamic result of the API request

· Create/replace the contents of the README.md file with the updated „readme.template” reference variable.

Index.js file

require("isomorphic-unfetch");
const { promises: fs } = require("fs");
const path = require("path");

async function main() {
    const readmeTemplate = (
        await fs.readFile(path.join(process.cwd(), "./README.template.md"))
    ).toString("utf-8");

    const quote = await (
        await fetch("https://api.quotable.io/random")
    ).json();

    console.log(quote);

    const readme = readmeTemplate
        .replace("{quote}", quote.content)
        .replace("{quote_author}", `- ${quote.author}`)

    await fs.writeFile("README.md", readme);
}

main();

Create a workflow file dynamic-injection-workflow.yml under the .github/workflows directory:

name: Dynamic README injection
on:
  schedule: # Run workflow automatically
    # This will make it run every hour
    - cron: "0 * * * *"
    # Run workflow manually (without waiting for the cron to be called), through the Github Actions Workflow page directly
  workflow_dispatch:
permissions:
  contents: write # To write the generated contents to the readme

jobs:
  get-quotes:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
        with:
          node-version: 16.16.0
      - run: yarn
      - run: node .
      - name: Add to git repo
        run: |
          git config pull.rebase false
          git pull
          git add .
          git config --global user.name "GitHub Action"
          git config --global user.email "action@github.com"
          git commit -m "[Automated] README updated with new quote!"
      - name: Push
        uses: ad-m/github-push-action@master
        with:
          github_token: ${{secrets.GITHUB_TOKEN}}
  update-readme-with-blog:
    needs: get-quotes
    name: Update this repo's README with latest blog posts
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: gautamkrishnar/blog-post-workflow@master
        with:
          # Replace this URL with your rss feed URL/s
          feed_list: "https://dzmdre.blogspot.com/feeds/posts/default?alt=rss,https://dev.to/feed/dmitryd"

It will allow you to receive the latest blog posts from your site & update quote.
And Node execution here will trigger the index.js file to do its magic.
Once you've added a workflow in GitHub, it becomes visible under 'Actions' > 'All workflows.' If you want to manually trigger the workflow and test its functionality, simply click on the 'Run workflow' dropdown button. You can then choose to run the workflow on the main branch. However, keep in mind that the cron job you've set up will automatically execute this workflow every hour, ensuring it runs periodically.
Once the workflow successfully completes both of its designated tasks, you can view the final result on your GitHub profile. It's a seamless way to keep your profile updated and dynamic.

Publish resume in JSONResume format at the Github Page

Another essential workflow involves the automatic generation of a CV file, which is based on a resume.json file. JSON Resume stands as an open standard format, designed for crafting and sharing resumes or CVs in a structured and machine-readable manner. It harnesses the power of JSON to delineate various resume sections, encompassing personal details, educational background, work experience, skills, and more. JSON Resume empowers individuals to maintain a single source of truth for their professional history while facilitating the creation of customized resumes in diverse formats like HTML, PDF, or plain text. This versatility is bolstered by the availability of various themes and templates, ensuring a visually appealing and unique CV while preserving data in an organized format.
This format's adaptability and developer-friendly nature have made it a preferred choice among tech-savvy individuals who aim to craft compelling resumes that stand out. JSON Resume also fosters open-source collaboration, enabling users to contribute themes and tools to the community. This collaborative approach ensures ongoing enhancements and personalization of resumes in a standardized fashion.

How to do this?
Create a file publish-resume.yml under the .github/workflows/ directory with a following content:


# example GitHub workflow
name: Publish resume in JSONResume format as Github Page

on:
  push:
    branches: [ master ]
  schedule: # Run workflow automatically
    - cron: "0 1 * * *"
    # Run workflow manually (without waiting for the cron to be called), through the Github Actions Workflow page directly
  workflow_dispatch:
permissions:
  contents: write # To write the generated contents to the readme

jobs:
  check_run:
    runs-on: ubuntu-latest
    if: "! contains(github.event.head_commit.message, '[Automated]')"
    steps:
      - run: echo "${{ github.event.head_commit.message }}"

  build:
    runs-on: ubuntu-latest
    needs: check_run
    steps:
      - uses: actions/checkout@v2
      - uses: kelvintaywl/action-jsonresume-export@v1
        name: Export resume as HTML
        with:
          theme: macchiato
          resume_filepath: resume.json
          # modifies the index.html in-place
          output_filepath: docs/index.html
      - name: Commit published HTML
        id: commit
        run: |
          git config --local user.email "action@github.com"
          git config --local user.name "GitHub Action"
          if [ -n "$(git status --porcelain docs/index.html)" ]; then
            git add docs/index.html
            git commit -m "[Automated] chore(docs/index.html): update resume page"
            echo "{exit_code}={0}" >> $GITHUB_OUTPUT
          else
            echo "{exit_code}={1}" >> $GITHUB_OUTPUT
          fi
      - name: Push changes
        uses: ad-m/github-push-action@master
        if: steps.commit.outputs.exit_code == 0
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          branch: ${{ github.ref }}

The workflow should automatically generate the CV file on a daily basis or update it whenever there's a push event. If you wish to alter this behavior, you can reconfigure the cron job accordingly. To change the CV's appearance, simply adjust the "theme" property to select a different style.
The generated CV file will be stored in the "output_filepath" specified as "docs/index.html." It's advisable to create an empty "index.html" file within the directory beforehand.
Once you've executed this GitHub workflow, your CV will be automatically generated based on the content in your resume.json file. To provide a link to your CV, you can use the following prefix:

"My auto-generated <a href="https://htmlpreview.github.io/?https://raw.githubusercontent.com/dzmdre/dzmdre/main/docs/index.html">CV</a>"

If you have missed something please take a look on my Github page.

In conclusion, a well-crafted GitHub profile README with GitHub Actions can help you stand out in the developer community. It's a versatile tool for showcasing your skills, sharing your thoughts, and presenting your professional history. By following these steps, you can create an impressive and dynamic GitHub profile that represents you effectively.
Thanks for reading! If you liked this article and want more content like this, make sure to follow me on Twitter!A special thanks to @rahuldkjain and @gautamkrishnar, @renanfranca for building the awesome open source projects that I used on this post. Please, visit rahuldkjain's project repository and gautamkrishnar's project repository and give it a star 🤩