DEV Community: Taiwrash

I Added Langfuse to My RAG App and It Immediately Caught Two Bugs

Taiwrash — Mon, 23 Mar 2026 23:19:39 +0000

I want to tell you something that did not make it into the README.

I built zey-ollama-rag-lab to show off ZeroEntropy's retrieval quality against a base LLM, side by side in a web UI. The demo worked. I was happy with it.

Then I added Langfuse. Within five minutes of looking at real traces, I found two bugs I had no idea were there.

One was embarrassing. One was silent and dangerous. Both would have stayed hidden without observability on the pipeline.

Let me show you what I found and exactly how everything is set up.

What the project does

The app compares two paths for answering a question:

Base LLM path: the question goes straight to TinyLlama via Ollama. No context, no retrieval.
RAG path: ZeroEntropy retrieves relevant chunks from your indexed documents, reranks them using zerank-2, then TinyLlama generates an answer using that context.

Both answers appear side by side in a web UI. The whole thing runs locally. Your documents never leave your machine.

The claim the project makes is that the RAG path produces better answers. Langfuse is how you find out if that claim is actually true.

Running the project

The cleanest way to run this is by cloning the repo and using Docker. The Dockerfile handles everything: it installs Ollama inside the container, pulls TinyLlama, installs the Python dependencies, and starts the FastAPI server. You do not need Python installed locally or Ollama set up separately.

git clone https://github.com/Taiwrash/zey-ollama-rag-lab.git
cd zey-ollama-rag-lab

Create your .env file using the provided example:

cp .env-example .env

Open .env and fill in your keys:

ZEROENTROPY_API_KEY=your_zeroentropy_key
LANGFUSE_PUBLIC_KEY=pk-lf-...
LANGFUSE_SECRET_KEY=sk-lf-...
LANGFUSE_HOST=https://cloud.langfuse.com

Then build and run:

docker build -t zey-rag-lab .
docker run --env-file .env -p 8000:8000 zey-rag-lab

The app is at http://localhost:8000. That is it. One clone, one build, one run.

The Dockerfile installs Ollama directly inside the container, exposes both port 8000 for FastAPI and 11434 for Ollama, and sets OLLAMA_HOST=http://localhost:11434 so both services find each other. The entrypoint.sh script handles starting Ollama and the FastAPI app in the right order. You do not need to think about any of that, it just works.

Setting up Langfuse Cloud

For the observability side, I used Langfuse Cloud. Go to cloud.langfuse.com, create an account, create a project (mine is called rag-ranker-comp), and grab your public and secret keys from the Settings page.

Those three lines in your .env are all you need:

LANGFUSE_PUBLIC_KEY=pk-lf-...
LANGFUSE_SECRET_KEY=sk-lf-...
LANGFUSE_HOST=https://cloud.langfuse.com

The SDK is already in requirements.txt, so it gets installed when Docker builds the image. No extra steps.

How the Langfuse integration works in the code

The integration is already in app.py. Here is how the three key pieces work.

The observe decorator

from langfuse import Langfuse, observe

lf = Langfuse()

Langfuse() reads your keys from environment variables automatically. Then @observe wraps any function to create a span in Langfuse:

@observe(name="base-llm-generation", as_type="generation")
def _base_generation(query: str) -> str:
    response = ollama_client.chat(
        model=MODEL,
        messages=[{"role": "user", "content": query}],
    )
    text = response["message"]["content"]

    lf.update_current_generation(
        metadata={"mode": "base"},
        usage_details={"total": response.get("eval_count", 0)},
    )
    return text

Note usage_details instead of usage. That is the Langfuse v4 SDK pattern. The token count from Ollama gets attached to the generation span.

Tracing ZeroEntropy retrieval

@observe(name="zeroentropy-retrieval")
def _retrieve_context(query: str, collection: str, k: int = 3):
    snippets = zclient.queries.top_snippets(
        collection_name=collection,
        query=query,
        k=k,
        reranker="zerank-2",
    )
    chunks = [{"content": s.content, "score": getattr(s, "score", None)}
              for s in snippets.results]

    lf.update_current_span(
        metadata={
            "collection": collection,
            "reranker": "zerank-2",
            "num_chunks": len(chunks),
            "top_score": chunks[0]["score"] if chunks else None,
        },
    )
    return "\n\n".join(c["content"] for c in chunks), chunks

Every retrieval call logs the collection name, how many chunks came back, the reranker used, and the top relevance score. When retrieval fails silently, you see exactly why.

Prompt versioning for the RAG system prompt

This part is easy to miss but genuinely useful:

@observe(name="rag-llm-generation", as_type="generation")
def _rag_generation(query: str, context_text: str) -> str:
    try:
        remote_prompt = lf.get_prompt("rag-system-prompt")
        system_prompt = remote_prompt.compile(context=context_text)
        lf.update_current_generation(prompt=remote_prompt)
    except Exception:
        system_prompt = (
            "You are a head of developer experience at ZeroEntropy. "
            "Use the following retrieved context to answer accurately. "
            "If the answer is not in the context, say you don't know.\n\n"
            f"Context:\n{context_text}"
        )

The app first tries to fetch a versioned prompt called "rag-system-prompt" from Langfuse. If you have created one in the Langfuse UI, it uses that. If not, it falls back to the hardcoded version. Either way, the trace records which prompt version generated which output. You can iterate on your system prompt from the Langfuse UI without touching code or rebuilding the container.

Human feedback endpoint

@app.post("/api/feedback")
async def feedback(data: FeedbackRequest):
    lf.score(
        trace_id=data.trace_id,
        name="user-preference",
        value=float(data.value),
        comment=f"preferred: {data.mode}",
    )

The /api/ask endpoint returns a trace_id with every response. When the user clicks a preference in the UI, that score gets attached to the exact trace it came from. Over many queries you start building real data on when RAG wins and when it does not.

What the traces actually showed me

I ran the container and asked "what is k8s?" a few times. Then I opened cloud.langfuse.com and looked at the traces.

Here is the raw export:

Traces 1 and 2, base-llm-generation:

{
  "name": "base-llm-generation",
  "input": "{\"args\": [\"what is k8s?\"], \"kwargs\": {}}",
  "output": null
}

Output is null. Twice. The trace captured the input arriving and the function running, but nothing coming back out. Without Langfuse I would have seen an empty box in the UI and assumed it was a frontend rendering bug. With the trace I knew immediately: the generation itself is returning nothing. That pointed straight at the Ollama response parsing.

Trace 3, base-llm-generation, after I dug into the code:

{
  "output": "Kubernetes (kurz für Kubernetes Engine oder K8s) ist ein Containerorchestrator..."
}

It answered. In German. For an English question. TinyLlama just decided to respond in German, confidently and fluently. In the UI this looks like text appeared so you think it worked. In the trace you can read the exact output and know it did not.

Trace 4, zeroentropy-retrieval:

{
  "name": "zeroentropy-retrieval",
  "input": "{\"args\": [\"what is k8s?\", \"demo_collection\"], \"kwargs\": {}}",
  "output": null
}

Retrieval ran and returned nothing. The reason showed up in the next trace.

Trace 5, rag-llm-generation:

{
  "input": "{\"args\": [\"what is k8s?\", \"[Retrieval error: Error code: 401 - {'detail': 'API Key Invalid'}]\"]}",
  "output": "Kubernetes (also known as K8s) is a cloud-native platform..."
}

The ZeroEntropy API key was invalid. Retrieval failed with a 401. But the app caught the exception, passed the error string as context, and TinyLlama just ignored it and answered from its own weights.

So the RAG path was silently running as a base LLM with extra steps. No crash. No visible error in the UI. The user sees a correct-looking answer and has no idea retrieval never happened. That is the kind of bug that erodes trust in a system slowly, because the answers look fine until someone checks carefully.

Langfuse caught both bugs in the first five minutes.

What the Langfuse dashboard shows

The home view after that first session showed five total traces in the past day. base-llm-generation appeared three times (I was debugging the base path). rag-llm-generation once. zeroentropy-retrieval once. Model costs at $0.00 because TinyLlama runs locally and free. Scores at zero because the feedback buttons in the UI are the next thing to wire up.

The trace breakdown in the bar chart already tells you something about what is happening in the app. Three base LLM traces to one RAG trace means the base path was the thing failing. If this were a production app with real users, that ratio would tell you which path people are actually using and whether the distribution matches what you expected.

The latency dashboard is where this becomes genuinely useful at scale. How long does zeroentropy-retrieval take on average compared to ollama-generation? If your RAG path is slower than the base path, is the retrieval or the generation the bottleneck? You get answers to those questions without adding any logging code.

What I fixed

The null outputs: the issue was in how I was reading the Ollama chat response. The message key was not always present on the response object in the way I expected. Seeing output: null in two consecutive traces made this obvious in a way that a missing text box in the UI never would have.

The German response: I added "Answer in English." to the base prompt. TinyLlama needs the explicit instruction. The traces now show consistent English output.

The 401 error: I updated .env-example in the repo to make it clearer that ZEROENTROPY_API_KEY has to be set before anything works. The silent failure was the real problem. The app should surface the retrieval error visibly in the UI rather than passing it as context to the LLM and pretending everything worked.

What is still left to do

The dashboard shows zero scores tracked. The /api/feedback endpoint is already in the backend code and working. I just have not added the thumbs up and thumbs down buttons to the UI yet.

Once those are wired up, every user preference flows into Langfuse as a score attached to a trace. Over enough queries you can actually answer the question this whole project is built around: how often does RAG beat the base model, on what kinds of questions, and what happens to that number when retrieval fails?

That is what turns a demo into a system you can measure and improve over time.

The full running setup

Clone, configure, build, run:

git clone https://github.com/Taiwrash/zey-ollama-rag-lab.git
cd zey-ollama-rag-lab
cp .env-example .env
# fill in ZEROENTROPY_API_KEY, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY
docker build -t zey-rag-lab .
docker run --env-file .env -p 8000:8000 zey-rag-lab

App at http://localhost:8000. Langfuse dashboard at cloud.langfuse.com. Traces start flowing from the first query.

The Langfuse integration is already in the code. You just need the keys.

Find me on Twitter at @Taiwrash if you find something interesting in your traces.

Langfuse is open source. Cloud hosted at cloud.langfuse.com. Self-hostable if you need everything on-prem. Docs at langfuse.com/docs.

Jenkins on Google Kubernetes Engine

Taiwrash — Thu, 27 Mar 2025 11:49:43 +0000

Our goal is simple: It is just to create K8s with GKE, create a Jenkins deployment and services then connect the two.

Technology: Kubernetes, Google Cloud Kubernetes, Jenkins, Helms, GitHub

Follow the below steps after verifying your user through the Google cloud console.

Step 1: Create the Kubernetes cluster on the Kubernetes engine using the command below on the gcloud environment.

gcloud container clusters create jenkins-cd \
--num-nodes 2 \
--scopes "https://www.googleapis.com/auth/projecthosting,cloud-platform"

The command specified the cluster name and the scope to access the Jenkins access to the necessary artifacts.

After the command successfully completed, run the command gcloud container clusters list to see the output that look like below that contain the information about the newly created cluster.

b. Let's find out the credential of the cluster by running the command

gcloud container clusters get-credentials jenkins-cd

c. Confirm the connection with the command

kubectl cluster-info

Output:

Step 2: Helm Installation and Configuration

what is helm? Helm is a package manager that makes it easy to configure and deploy Kubernetes applications. a. After successful installation of Helm from helm documentation guide. The next is adding the Jenkins chart repo with the command

helm repo add jenkins https://charts.jenkins.io

For every installation, it is advisable to update to newer version. this can be done by running.

helm repo update

b. Let's run helm package manager against the yaml configuration files that can be found in this repository under the Jenkins folder. Execute the below command against the config files. The values config file add the Google Cloud specific plugin necessary to use service account credentials to reach Source Repository

helm upgrade --install -f jenkins/values.yaml myjenkins jenkins/jenkins

c. Display the running pods with the command

kubectl get pods

Output:

d. Let's port forward the Jenkins UI from the cloud shell with the command

echo http://127.0.0.1:8080
kubectl --namespace default port-forward svc/myjenkins 8080:8080 >> /dev/null &

Output:

Step 3: Connecting the Jenkins

a. Access the Jenkins UI admin login credentials with the command.

kubectl exec --namespace default -it svc/myjenkins -c jenkins -- /bin/cat /run/secrets/additional/chart-admin-password && echo

And the deployed Jenkins running will produce a page like this.

Congratulations, you've successfully deployed Jenkins on a Kubernetes environment using the GKE.

Deploy Backend API to Google Kubernetes Engine

Taiwrash — Thu, 20 Mar 2025 16:50:12 +0000

The goal is simply to write a NodeJS API and turn it into a replicated application running on Kubernetes, which is running on Google Kubernetes Engine.

Important Note: This article uses Google Cloud Console, gcloud shell, Compute Engine, Google Container Registry, Google Kubernetes Engine.

System Architecuture

What is Kubernetes

Kubernetes, also abbreviated as K8s (with '8' representing the number of letters between 'K' and 's'), is an open-source project originally developed by Google. It is now managed by the Cloud Native Computing Foundation (CNCF). Kubernetes provides a robust way to run scalable and highly available applications.

From the Beginning

Let's build the API

Create your app file e.g app.js
Put the code below

var http = require('http');
var handleRequest = function(request, response) {
  response.writeHead(200);
  response.end("Hello World!\n");
}
var www = http.createServer(handleRequest);
www.listen(8080);

Execute it by running "node

we chose the file name to be app.js, therefore we will run node app.js and we can find the app running on port 8080

Output:

Supercharge with Docker.

Kubernetes can run Docker containers; therefore, we need to containerize our app. To run a containarize application we need a Dockerfile.

Simple container lifecycle: Dockerfile > Docker Image > Docker Container. A built dockerfile produces a docker image and a running docker image produces a docker container. In this article, the container will be running on cloud and managed by kubernetes.

Create Docker file with: a file with name Dockerfile and put the below code.

FROM node:6.9.2
EXPOSE 8080
COPY server.js .
CMD node server.js

Build the docker file to get a docker image
Run the docker image to get a docker container to test out locally.

Output on the cloudshell:

Output on the browser:

Pushing the image to the registry

Authenticate your registry be it GCR,ECR, Dockerhub or ACR

gcloud auth configure-docker

Push to the registry

docker push gcr.io/PROJECT_ID/hello-node:v1

Output on the cloudshell:

The image pushed to the registry can be confirmed by checking the registry via the Google cloud console.

Output on th cloud console registry:

Creating the Kubernetes cluster

Confirm project ID config

gcloud config set project PROJECT_ID

Creating the nodes

gcloud container clusters create hello-world \
                --num-nodes 2 \
                --machine-type e2-medium \
                --zone "us-central1-c"

2 nodes with machine type to be e2-medium and the us-central1-c zone
Output:

this will take 2-3 minutes to complete depending on my factors, so be patient.

Creating a pod

Running nodejs image stored in the registry serving content at port 8080. We need away to bring the docker image stored in the registry into the kubernetes cluster created and this can be done by creating a pod and run the docker image inside of it.

kubectl command to create a deployment pod

kubectl create deployment hello-node \
    --image=gcr.io/PROJECT_ID/hello-node:v1

the command create a deployment in the cluster referencing the docker image stored in the registry.

Output:

show the pod created

kubectl get pods

Output:

Let's allow external traffic from customers and internet

In order to make the hello-node container accessible from outside the Kubernetes virtual network, we need to expose the pod as a Kubernetes service.

Add a load balancer to add an external IP

kubectl expose deployment hello-node --type="LoadBalancer" --port=8080

Output:

Finding the IP address accessible everywhere

kubectl get svc

Output with a focus on the external IP on the hello-node:

Check the browser with the IP. > If you put the IP address in the browser, you will get something like below which is the response from the API we are deploying

Output:

Scale up the services easily

Suppose you suddenly need more capacity. You can tell the replication controller to manage a new number of replicas for your pod with the kubectl scale command.

Increase the number of pods to 4

kubectl scale deployment hello-node --replicas=4

Output:

Confirm the number of replicas

kubectl get deployment

Output:

See the running pods managed by the deployment

kubectl get pods

Output:

Where we are Everything we've done so far is replicated in the diagram below for easy understand and a help to build the right mental model.

Roll out an upgrade to your service

This is done without impacting users, that's the power of kubernetes

Add the feature: we added another endpoint return
Rebuild the docker image
push new version to docker registry

a. To interact with running cluster, you edit the k8s

kubectl edit deployment hello-node

Point the spec.template.spec.containers.image to the new version of the image just pushed to the registry.

While this is happening, the users using the services wouldn't see any interruption. After a little while they'll start accessing the new version of the application i.e the API responding with Hello Kubernetes World!.
These deployment, scaling, and updated features, are managed by K8s once Kubernetes Engine cluster is set up, It'll be clear that Kubernetes will help you focus on the application rather than the infrastructure.

This is a part of a series. take note!

KubeActions - N0.1 Kubernetes Deployment Tool

Taiwrash — Sat, 20 May 2023 20:55:45 +0000

Continuous Deployment Action for Kubernetes Environments [dev, test, staging, prod]

Category Submission:

DIY Deployments: Improve the deployment process for open-source projects.

App Release Link

Release Kubernete

Description:

The Continuous Deployment Action for Kubernetes Environments is a GitHub Action that automates the deployment process for Go applications to multiple Kubernetes environments. It simplifies the CI/CD pipeline by providing a reusable and customisable workflow to deploy your application to different environments such as test, stage, and production.

The action utilises the power of Kubernetes and GitHub Actions to streamline the deployment process. It includes the necessary scripts and configuration files to deploy the application to the desired Kubernetes clusters and namespaces.

Link to Source Code:

GitHub Repository

Permissive License:

MIT License

Background

The motivation behind building this action was to enhance the deployment process for Go applications in Kubernetes environments. As a developer, I found myself spending significant time configuring and managing deployment scripts for different environments. This action aims to simplify and automate the deployment workflow, enabling developers to focus more on writing code and less on manual deployment tasks.

How I Built It

I leveraged GitHub Actions, Go programming language, and Kubernetes to build this action. The action is written in Go and utilises the power of the Kubernetes command-line tool (kubectl) to interact with the Kubernetes clusters.

Here are the key components of the action:

GitHub Actions Workflow: The main entry point of the action is the workflow defined in the .github/workflows/<name_of_your_choice.yml> file. It triggers pushes to the main branch and sets up the environment for the deployment.
Go Application: The Go application contains the deployment logic specific to each environment. It uses environment variables to determine the target environment and executes the necessary Kubernetes commands to deploy the application.
Deployment Scripts: The deployment scripts, located in the scripts directory, provide the necessary commands to deploy the application to different environments. Each script interacts with the Go application, passing the target environment and triggering the deployment process.
Kubernetes Manifests: The Kubernetes directory includes the Kubernetes manifests (test. yaml, stage. yaml, production. yaml) required for deploying the application to the respective environments. These manifests can be customised to match the specific requirements of the application.

I learned how to integrate Go with GitHub Actions and Kubernetes during the development process. I also gained a deeper understanding of CI/CD processes and best practices for deploying applications to Kubernetes environments.

Additional Resources/Info

This article summarises the Continuous Deployment Action for Kubernetes Environments, a GitHub Action designed to simplify and automate the deployment process for Go applications in Kubernetes clusters. The action streamlines the deployment workflow, allowing developers to focus on writing code rather than managing complex deployment scripts.

The source code, deployment scripts, and Kubernetes manifests are available in the GitHub repository. Feel free to explore, customise, and contribute to the project.

By leveraging the power of GitHub Actions and Kubernetes, this action empowers developers to achieve efficient and reliable deployments across multiple environments. Let's embrace automation and enhance our deployment processes!

Please feel free to reach out if you have any questions or suggestions. Happy deploying!

The Three Fundamentals of Learning Cloud Computing and DevOps Engineering

Taiwrash — Thu, 19 May 2022 17:43:43 +0000

Getting into cloud computing or the DevOps world is made easy by various cloud providers. For instance, Amazon Web Services provides access to AWS Educate to learn both the fundamentals of the cloud and AWS cloud services specifics, and Google provides access to Qwiklabs to learn all about the cloud and Google Cloud Platform cloud services specifics. Microsoft provides access to Microsoft Learn to do the same as others provided. The Linux Foundation has courses and training on cloud native paths and so on. There are other learning platforms outside the provider platforms. KodeCloud, ACloud, and others are also a place to leverage cloud technology knowledge.
Diving into all of the above-mentioned platforms may be very tedious and difficult without the knowledge of the basics. To find the cloud journey more interesting, one needs to have in their toolkits the basics to be discussed in this article. Don’t misunderstand this, jumping this will not hinder you from learning on those platforms. But it's worth knowing that all these platforms are like an ocean to learn on and an ocean that can easily drone beginners and starters without the full knowledge of basics and fundamentals. My exploration of those platforms made it a choice for me to support people like me to learn the right way and show them what it is necessary to have as a pre-requisite.
The following are the basics you need to have as a person planning to start a cloud engineering journey.

Linux Skills
According to the 2020 StackOverflow survey, Linux is the most popular platform used by developers and for servers related jobs but overtook by Windows in the 2022 survey because of the ability of WSL (Windows Subsystem for Linux) introduced by Windows developers, just provide access to Linux capabilities on Windows 10 and later. According to a survey by w3techs, over 77% of online servers run Linux, 90% of public clouds run Linux, and practically all the best cloud hosts use it, 96.3% of the world’s top 1 million servers run on Linux. There are more reasons why Linux is used for servers and other related jobs, but that is not the focus of the article.
When getting started, learning Linux commands will come in handy as you progress in your cloud journey. This article is not a tutorial on Linux commands but a heads-up on what needs to be learned before deep diving in. Learning the basics ls – list command, just to list the content of a folder, mkdir – make directory command, which is used to create folders, touch – command to create a file, chmod – change mode command, which changes the mode of a file. curl, ping, IP, rm, mv, cp, cat, and other simple commands are very important to know beforehand.
Another important thing to note is the environment provided by Linux Distros to run the aforementioned and other commands. This is called a "SHELL." There are four popular shells known to run various commands as listed below.
Bourne Shell (SH Shell)
C Shell (csh or tcsh)
Z Shell (zsh)
Bourne Again Shell (BASH)
All of these provide an environment to execute Linux commands with a little difference among them. Some did not support tab for autocomplete, backspace to delete the last character and many other variations. You can run ls $SHELL to know the particular shell that is available to you in your terminal.

Editors
Familiarity with one Linux based text editor is very important as it will always come in handy going forward in the journey. There are tons of these editors on the internet, e.g.

Vim, GNU nano, Emacs, VI, geddit

, and others. Convenient in one is sufficient for the start but may require levelling up moving forward. These tools are used to edit file contents and also the content of a file. This requires a bit of knowledge to be more comfortable using them. VI, for instance, usually comes with almost all kinds of Linux distros. You can type vi commands into the terminal and you will be provided with the content of the file in command mode. To edit contents, one needs to enter the insert mode. Below are some of the commands that can be used in the command mode.
I – To enter insert mode
Esc – to enter commands mode
< ^ > - four arrow keys on the keyboard to move left, down, up and right, (HJLK) can also be used respectively.
:q - to quit the VI
:w – save the file
:wq – save and quit the VI
/ - to search for a letter or word
There are other commands, but I will advise you to stick with the basics for a start to have smooth learning ahead.

Labs Setup
Some of the above-mentioned courses may introduce the students to lab setup, but having the basic knowledge of these techniques will go a long way. Virtualization, or Hypervisor in Windows terms, is a very important thing to know as it will form a large part of learning DevOps. Familiarization with TYPE-2 virtualization is very important to have. The TYPE-2 is when using a virtual box like Oracle virtual box to create virtual machines and perform connectivity and other networking setups to establish communication between more than one device. Leom has a link to the right virtualbox for you here.

Finally, there is more to learn, but learning the above-mentioned concepts will be a plus for learning more advanced and difficult concepts. I am planning in-depth and simple tutorials for beginners in the three mentioned basics. You can let me know your thoughts on it.

Simple and Easy Open Source Project for Contributors to contribute during HACKTOBERFEST - DEV-RESUME as Case study

Taiwrash — Wed, 30 Sep 2020 06:08:33 +0000

Terms used

a. Open-source software is a type of computer software in which source code is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software to anyone and for any purpose.

b. Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub.

Hacking in October (hacktoberfest) ❤️

It is the month of October when developers and tech enthusiasts around the globe gather remotely and in person to celebrate open source. The experience has always been a big bang. The big bang is called HACKTOBERFEST. This is an annual event which runs through out the month of October. For this reason, I am inviting you to a beginner-friendly and easy-to-contribute project titled DEV_RESUME.

Benefits of contributing

The following are the rewards and benefits for every contributors of this project.

Get recognised on GitHub with a contributor's badge issued by our GitHub contributor's bot
A merged PR (Pull Request) get featured on our live project at https://dev-resume.herokuapp.com which is aimed at showcasing open source contributors around the world.

Aims of the project

To be No.1 point for recruiters to confirm developers contributions to open source.

Below are the simple and straight forward steps to contribute to the project.

Step 1: Sign in to github.
Step 2: Search Dev-resume or follow this https://github.com/Taiwrash/dev-resume.

Step 3: Fork the repo using the fork button on GitHub
Step 4: after successfully forked, clone the repo by using the clone button with your system terminal

Step 5: Open the folder and navigate to public, then images, and move your desired image into it(note the name and extension of the image) i.e dev-resume/public/images

Step 6: leave the public folder
Step 7: Go to data.json file.

Step 8: Copy a complete object in the array starting with { and end with } put a comma as the last character and paste.
Step 9: Paste and edit the data to your personal data, then save.

You are almost there!💪

Step 10: Commit your changes and push to the GitHub.
Step 11: Navigate to GitHub and the forked repo should be begging for PR.

Step 12: Create a PR and you are done!

Great work👍

Do this and you are 3 steps away from getting your tree planted by hacktoberfest team and your tee are waiting for more 3 PRs.

This is how simple it is and you are done!

Let's hack together in this October period with the HACKTOBERFEST tag!