DEV Community: Ajisafe Victor Oluwapelumi

The recipe you cannot test yourself

Ajisafe Victor Oluwapelumi — Wed, 30 Sep 2026 09:51:54 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

What I Built

A recipe review queue in Sanity Studio where publishing is gated on somebody other than the author having actually cooked the thing.

Recipe sites publish recipes nobody made. "Approved" usually means one person clicked a button on their own work. I wanted a workflow where that is structurally impossible rather than discouraged by policy.

A recipe moves Drafting to Testing to Approval to Published. The author writes it and submits. Then a different person has to claim the test, cook it, and write up what happened before it can move on. A failed test sends it back to drafting. An approver sending it back wipes the previous test result, because that pass described a different version of the recipe.

The whole constraint is one filter in the workflow definition:

filter: '!defined($fields.tester) && $fields.author.id != $actor.id'

That line is the product. Everything else is scaffolding around it.

Demo

Two accounts, side by side. The author submits, tries to test their own recipe, and the action is refused. A second person picks it up, cooks it, reports back, and it publishes.

Code

ajipelumi / recipe-review-queue

Recipe Review Queue

A Sanity Studio where a recipe cannot be published until somebody other than its author has actually cooked it.

Built for the DEV x Sanity Challenge, Path Two.

The idea

Recipe sites publish recipes nobody made. "Approved" usually means one person clicked a button on their own work. This makes that structurally impossible rather than discouraged by policy.

A recipe moves through four stages:

Drafting -> Testing -> Approval -> Published

with a rejection at either Testing or Approval looping back to Drafting.

The constraint that matters is one filter in workflows/recipeReview.ts:

filter: '!defined($fields.tester) && $fields.author.id != $actor.id'

The author is excluded from claiming the test. A recipe only reaches Approval once a second person has cooked it and written up what happened, so "approved" is a claim backed by evidence rather than a status someone set on their own work.

Two supporting decisions:

A…

View on GitHub

My Build Process

I used Claude Code in the terminal, not an IDE-embedded assistant. The whole thing is a Sanity Studio plus one workflow definition file, so there was very little UI to write and a lot of API surface to get right.

What worked: pointing it at the cookbook instead of describing the goal

The prompt that moved fastest was not a description of what I wanted. It was telling it to fetch Sanity's own Editorial review cookbook
and adapt it. Workflows is early access, so the model's training data does not contain defineWorkflow, defineStage, or the shape of an ops array. Asking it to invent that API from a description produced plausible nonsense. Asking it to read the real page first produced working code.

Same for the Studio plugin. Rather than guess at the config, it read the type definitions out of node_modules:

export declare interface WorkflowPluginConfig {
  readonly tag: string;
  readonly workflowDataset?: string;
  readonly mappings?: readonly WorkflowMapping[];
  ...

tag is the only required field and bindings auto-discover from the deployed definition. That is two minutes of reading that replaced an afternoon of guessing.

What did not work: three separate environment failures

The documented CLI does not exist. The cookbook says to deploy with
sanity-workflows deploy. That package is not on npm. Neither is
@sanity/workflows-cli. The docs describe a tool that has not shipped. The programmatic path in the same doc does work, so deployment goes through a script instead:

await engine.deployDefinitions({
  expectedMinReaderModel: 10,
  definitions: [recipeReview],
})

Node 20 silently half-installs Sanity 6. npm install kept "succeeding" while leaving package.json untouched and node_modules/.bin empty. I went looking for a corrupted install, a bad npm config, a Windows symlink permissions problem. The actual cause was that sanity@6 requires Node 22.12+ and this machine had 20.19.5. Running the binary directly said so in one line:

ERROR: Node.js version >=22.12 required. You are running v20.19.5

The EBADENGINE warnings had been scrolling past the whole time. I had
dismissed them as the usual noise. Worth checking whether a package requires a newer runtime before assuming the install is broken.

sanity deploy refuses on a permission I appear to have. It fails with User is missing required grant sanity.project.deployStudio. I ruled out the obvious causes in order: the robot token in .env shadowing my login (re-ran with it unset, same error), my account role (administrator on the project), and the plan (the Manage UI shows an enabled "Add studio" button). Still refused. I stopped there and demoed from npm run dev instead. The brief asks for a video walkthrough or a link, not specifically a hosted Studio, and honestly the constraint demos better with two browsers side by side than it would on a static URL.

Where I nearly fooled myself

I wrote a script to drive an instance through the stages and prove the rule fires. It printed exactly what I wanted:

submit     -> testing
claim test -> REFUSED: action filter returned false

Then I opened the Studio and looked at the instance. The author field said g-n9iPHYh2CdfV -- the API token's robot user. The script authenticates with a token, so the engine saw the robot as author, and the filter had correctly blocked the robot. I could have cheerfully tested my own recipe on camera and the demo would have proved nothing.

The engine takes its actor from the token and fireAction has no actor
override, which means one token is always one person. That is not a limitation to work around. It is the rule doing its job. Demonstrating a two-person constraint genuinely requires two people, so the video uses two real accounts and the script now says so in a comment rather than pretending otherwise.

What I would do differently

Check runtime requirements before debugging an install. Read the vendor's own docs into context before asking for code against a pre-release API. And verify who an automated test is acting as, not just what it printed.

Sanity Project Details

Project ID: qomqzwv7
Dataset: production (public)
Workflow definition: recipe-review v1

The dataset holds three recipes and the workflow instances. One instance is left at published, from the run recorded in the video, so the completed path is inspectable rather than just described.

I tried to catch Next.js contradicting itself. It never did.

Ajisafe Victor Oluwapelumi — Fri, 25 Sep 2026 08:24:51 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

Next.js has two routers. The Pages Router and the App Router answer the same questions in incompatible ways, and both sets of documentation are live, indexed, and correct. Neither page carries a banner saying "this is the old way." Search does not tell you which one you landed on.

So an AI assistant or an old tutorial hands you getServerSideProps, you paste it into an App Router project, and Next.js rejects it. The answer was not wrong. It was for the other router.

Router Rosetta takes a snippet or a question, identifies which router it belongs to, and gives you the equivalent in the other one. Every claim carries the documentation entry it came from, and every equivalence carries a citation to the official migration guide.

It also refuses. If the knowledge base does not cover something, it says so rather than filling the gap from the model's memory of Next.js.

Demo

Live: https://router-rosetta.vercel.app

Paste code, or use one of the four examples on the page.

It translates, with receipts

Given this:

export async function getServerSideProps() {
  const res = await fetch('https://api.example.com/posts')
  return {props: {posts: await res.json()}}
}

It answers:

This code uses Pages Router, as identified by the use of getServerSideProps [data_fetching/pages_static].

In the App Router, getServerSideProps is replaced by fetching data directly inside an async Server Component page [migration, data_fetching/app_router]. In the App Router, fetch calls inside Server Components run on the server during rendering [data_fetching/app_router], mapping to getServerSideProps dynamic request behavior [migration].

Then it writes the App Router version, citing the target entry and the migration
guide for the equivalence.

It refuses, with partial credit

Ask it something out of scope:

How do I configure Redis session storage with a custom Kubernetes ingress in Next.js?

The knowledge base does not contain information on configuring Redis session storage or custom Kubernetes ingress routing in Next.js.

The only Kubernetes and deployment details supported by the knowledge base are:

Next.js supports deployment to Docker-compatible providers, including Kubernetes, using either a Node.js server or Docker container build [setup/configuration].

For Docker and containerized environments like Kubernetes, Next.js provides an output: "standalone" configuration mode in next.config.js to create a minimal production image containing only the required runtime files [setup/configuration].

Because Redis session storage and custom Kubernetes ingress configurations are not covered in the knowledge base, no router-specific mapping or implementation code can be provided.

Code

ajipelumi / router-rosetta

Router Rosetta

Translates Next.js code and questions between the Pages Router and the App Router, citing a knowledge base entry for every claim.

Paste getServerSideProps and it tells you this is Pages Router code, gives you the async Server Component equivalent, and cites the docs entry behind each statement. Ask "how do I read search params in each router?" and it answers for both. Every factual claim carries a citation chip — the point is that you can check the answer rather than trust it.

The model is instructed not to answer from its own memory of Next.js. If the knowledge base does not cover a mapping, it says so instead of guessing.

Getting started

npm install
cp .env.local.example .env.local   # then fill in the values below
npm run dev

Open http://localhost:3000.

Environment

The two Sanity variables are required. At least one model provider key is also required…

View on GitHub

How I Used Sanity

What I pointed Context at

Three website sources, all on nextjs.org:

Source	Pages	Role
`/docs/pages/building-your-application`	21	The superseded way
`/docs/app/getting-started`	20	The current way
`/docs/app/guides/migrating/app-router-migration`	1	The arbiter

42 pages, no dataset or uploaded files.

One setting mattered more than everything else: Max depth. Left empty, the crawler reads the seed URL and follows nothing. My first build pulled 7 pages out of a 38 page target and I spent a while blaming my include patterns. Setting Max depth to 3 took it to 42.

What the build produced

Context turned those 42 pages into 16 entries, and it organised them into pairs:

Topic	Pages Router	App Router
Data fetching	`data_fetching/pages_static`	`data_fetching/app_router`
Routing	`routing/pages_router`	`routing/app_router`
Rendering	`rendering/pages_router_modes`	`caching`

Plus migration, holding the deprecated-to-current API mapping.

Each entry also carries an excludes: line pointing at its counterpart:

data_fetching/app_router [peripheral]
  App Router data fetching: Server Components with fetch API or ORM/database...
  excludes: Pages Router methods (getStaticProps, getStaticPaths,
            getServerSideProps); cache/revalidation config.

That line is the whole product: the knowledge base records where the other half of each answer lives, and I did not model that pairing myself. The build wrote it from the source material.

Which tools the agent uses

The endpoint serves Knowledge Base mode, so two tools:

initial_context for the outline, which is small enough to hold for a whole conversation
knowledge_base_read for the entries themselves, several paths at a time

The system prompt forces the pairing to be used rather than hoped for:

Read the entry for that router AND its paired entry for the other router. Read
the migration entry whenever you assert an equivalence.

Without that line, the model answers from whichever entry it reads first and produces a confident, one-sided answer.

Why this needs structured content

Keyword search for getServerSideProps returns the Pages Router documentation. It is the right page, current and accurate, and it will not tell you that a newer router replaced it or what the replacement looks like. The answer requires knowing which of two parallel systems a claim belongs to and what it maps onto, a relation between sources rather than a string inside any one of them.

What did not work

I started by trying to surface contradictions between the two routers, because the Sanity docs describe conflict detection and it sounded like a strong demo.

The first build, the starved one with 7 pages, raised a real conflict about getStaticPaths fallback values.

Then I fixed the crawl, rebuilt with all 42 pages, and got zero conflicts.

That result is correct. With the full picture, including the migration guide explaining that one router supersedes the other, Context concluded these are two coherent systems rather than one system contradicting itself. More context produced better reconciliation. The conflict I had been excited about was an artifact of an incomplete index.

Next.js does not contradict itself, it documents two things in parallel, and that only became visible once the crawl was complete. I kept the same 42 pages and the same paired structure, and changed the product from adjudication to
translation.

Build notes

Stack: Next.js 16, Vercel AI SDK v7, @ai-sdk/mcp connecting to Context MCP, Groq as the model with Gemini as a fallback.

The agent is provider-agnostic, and that is the point. All the domain knowledge lives in the knowledge base rather than in the model. Neither provider knows anything about Next.js routing beyond what it reads through MCP.

Free tiers forced real engineering, not just a config swap. Gemini's free tier caps at 20 requests per day per model, which a demo exhausts in minutes, so Groq is the primary and Gemini is the fallback. Three things make that survivable in production: the client mirrors the limit with a sliding window so you aretold before a request is wasted, first-turn answers are cached for a day so the example buttons do not re-derive the same output, and a failed request actually switches provider mid-run rather than just erroring, using the AI SDK's prepareStep so the swap sticks for the rest of the agent's steps.

Errors were invisible until I made them loud. The AI SDK's default failure message is "An error occurred," identical for every cause. Wiring onError to report the real cause was one of the first things worth doing, well before therate limits above ever came up.

Sanity Project Details

Project ID: 3bpjqog6
Dataset: production (public)
Knowledge Base ID: kbm133o2qNEI

The project is deliberately empty. The knowledge base is built entirely from website sources, so no dataset content was needed. The structure worth looking at is in the Knowledge Base entries, not in the Content Lake.

The Metric You Report Is Not the Work You Did

Ajisafe Victor Oluwapelumi — Fri, 18 Sep 2026 14:51:13 +0000

A North Star Metric is one number that represents value delivered. That is the whole definition.

The difficulty is never understanding it. The difficulty is that when you pick one honestly for something you actually do, it is almost never the number you have been keeping.

Try it on a job search

Suppose you are looking for work, and you want one number to tell you whether the search is going well.

The first candidate that comes to mind is applications sent. It is easy to count, it goes up every week, and it feels like effort. Most people searching for a job are tracking it whether they call it a metric or not.

It is also close to useless. Fifty applications sent tells you nothing about whether any of them were read. It is perfectly possible to send fifty and be no closer to a job than when you started, and the number will still look like a productive month.

So try the next one: hours spent job searching. This is worse. It measures input rather than output, and it rewards inefficiency directly. Spending six hours rewriting a cover letter for a role you were never going to get scores higher than spending twenty minutes on one you were.

Try again: responses received. Better, because it requires someone on the other side to have done something. But it still counts rejections, and a rejection is not value delivered to anyone.

What you are actually after is something like interviews earned from roles you would genuinely accept. That number only moves when a real employer, for a job you actually want, has decided you are worth their time.

Candidate metric	What it measures	Why it fails
Applications sent	Effort	Says nothing about whether anyone read them
Hours spent searching	Input	Rewards inefficiency
Responses received	Someone reacted	Counts rejections too
Interviews earned (roles you'd accept)	Value delivered	—

Notice what happened across those four attempts. Each one moved further from what you did and closer to what resulted. That direction of travel is the whole idea.

Why the wrong metric is so tempting

Activity is easy to count. Applications sent is a number you already have. Interviews earned requires you to define what counts as a role you would accept, then wait, then attribute the outcome to something you did weeks ago.

Activity also rises reliably. Send ten applications, the number goes up by ten. Outcome metrics sit still for long stretches and then move in steps, and a flat week on a number you care about feels much worse than a rising week on a number you do not.

That asymmetry is the reason people pick badly, and it has nothing to do with not understanding the concept. Choosing the honest metric means accepting a number that will often refuse to move while you are working hard. Most people, reasonably, would rather watch the one that rewards them daily.

The same trade shows up at work. Tickets closed, commits pushed, messages answered, items reviewed. All real work. None of them say whether anything was better afterwards. Compare what each one could be instead:

Tickets closed → problems that stayed fixed
Commits pushed → features users actually used
Items reviewed → items usable afterwards

One number is not enough

A North Star on its own is gameable, usually without anyone intending to game it.

Optimise interviews earned and the obvious move is to apply only to roles where your odds are highest, which over a few months quietly narrows your search to jobs slightly below what you could get. The metric rises. The search gets worse.

So it needs a counterweight (often called a guardrail metric), and one is normally enough. Here it might be the share of applications going to roles that would be a genuine step up. That number stops you buying interviews with ambition.

The pairing is the point.

One metric tells you how to grow, the other tells you what growth is not allowed to cost.

Counting your own work honestly

Once you have tried to pick an honest metric for one mundane thing, it becomes hard not to do it for everything else.

It changes what you report about your own work most of all. It is easy to say you reviewed two hundred items last week, and much harder to say how many were usable afterwards. The first number is always available and always flattering. The second one is the one that was worth doing.

The question that gets you there is short:

If this number goes up and nothing else changes, has anything actually improved?

If the answer is no, you are counting activity.

From Aiven to Railway: Our Database Migration

Ajisafe Victor Oluwapelumi — Tue, 28 Apr 2026 12:08:53 +0000

I didn't plan a migration. I just noticed we were paying for two databases.

This whole thing started with a very unglamorous realization:

We were paying for Aiven Postgres…
and also paying for Railway.

At some point I opened the Railway dashboard properly and thought:

"Wait — why aren't we using this for the database too?"

No incident. No outage. No scaling crisis.

Just mild financial confusion.

The decision wasn't really "should we migrate?"

It was more like:

"We're already using Railway for everything else. Why is the database emotionally living somewhere else?"

So I did what any developer does when something feels inconsistent: I turned it into a migration project.

The migration itself was weirdly easy

I expected:

scripts
downtime planning
CSV exports
at least one regretful late-night rollback

Instead, Railway just pointed me to their Postgres migrator:

Railway Postgres Migrator

The setup was:

Source: Aiven Postgres URL
Destination: Railway Postgres
Action: Deploy

That's it. I didn't trust it at first.

The one thing that actually tripped me up

Before the migrator worked, I hit a version mismatch. Railway's Postgres was running v18 — and the migrator requires source and destination to be on the same major version. Aiven was v17, so I had to upgrade it first before anything else would proceed.

Once versions matched, there was another quiet gotcha: two optional environment variables — NO_ACL and NO_OWNER — had to be set to true for the migration to complete cleanly.

Variable	What it does
`NO_ACL`	Skips restoring access privileges (GRANT/REVOKE commands)
`NO_OWNER`	Skips restoring object ownership (ALTER OWNER commands)

The Railway docs show their default as true, but in practice they were false — meaning the migrator was trying to restore ACLs and ownership from Aiven, hitting permission errors, and failing silently enough that it wasn't immediately obvious why.

Setting both to true explicitly is what actually made it work.

I kept waiting for something to break. Nothing did.

No data loss.
No partial sync weirdness.
No "why is production dead" moment.

Just a working database in a new place, which is almost more stressful than failure — because you keep checking if you missed something.

Railway vs Aiven (honest experience, not a benchmark)

Aiven Postgres:

Solid and reliable
More manual setup
External to your deployment ecosystem
SSL and config overhead you have to manage

Railway Postgres:

Lives inside your deployment environment
Internal networking by default
Less cognitive overhead on config
Everything in one dashboard

The biggest difference wasn't performance. It was mental overhead. Fewer places to check. Fewer credentials to rotate. One less tab permanently open.

Would I recommend this?

If you're already on Railway and running an external Postgres for no strong reason — probably yes. The migrator genuinely works, the internal networking is a real quality-of-life upgrade, and the consolidation is worth it just to stop context-switching between dashboards.

If you have a strong reason for keeping the database external (compliance, specific Aiven features, multi-cloud setups) — that calculus changes. But "we started there and never questioned it" isn't a strong reason.

Sometimes the migration is just noticing you forgot to consolidate.

Understanding Value and Pointer Receivers in Go: Building a Crypto Tracker

Ajisafe Victor Oluwapelumi — Thu, 06 Nov 2025 00:56:05 +0000

I picked up Go recently while building the backend of a crypto tracker. This tracker allows users to manage their cryptocurrency holdings and calculate their wallet value in real-time. One of my favorite learnings so far is value receivers and pointer receivers, and how everything works under the hood.

How Go Passes Arguments

Go passes arguments by value, not by reference. This means it creates a copy of the argument and passes that copy to the function. Understanding this is crucial to writing efficient Go code.

Value Receivers: Working with Copies

When you use a value receiver, Go creates a copy of the struct. Any modifications you make inside the function only affect the copy, not the original.

type Wallet struct {
    User       string
    TotalValue float64
}

// Value receiver - receives a copy
func (w Wallet) UpdateValue(newValue float64) {
    w.TotalValue = newValue  // Only modifies the copy
    fmt.Println("Inside function:", w.TotalValue)
}

func main() {
    wallet := Wallet{User: "pelumi", TotalValue: 1000.0}
    wallet.UpdateValue(5000.0)

    fmt.Println("Outside function:", wallet.TotalValue)
}

Output:

Inside function: 5000
Outside function: 1000

The original wallet.TotalValue remains 1000 because we modified a copy. When the function returns, the copy is discarded (removed from the stack), and our changes are lost.

Pointer Receivers: Modifying the Original

Pointer receivers solve this by passing the memory address of the struct instead of a copy. When you pass an address, Go still passes it by value, but now you have an address that points to the original data.

// Pointer receiver - receives a pointer (address)
func (w *Wallet) UpdateValue(newValue float64) {
    w.TotalValue = newValue  // Modifies the original
    fmt.Println("Inside function:", w.TotalValue)
}

func main() {
    wallet := Wallet{User: "pelumi", TotalValue: 1000.0}
    wallet.UpdateValue(5000.0)  // Go automatically passes &wallet

    fmt.Println("Outside function:", wallet.TotalValue)
}

Output:

Inside function: 5000
Outside function: 5000

Now both print 5000 because we modified the original through its address. Go automatically handles the dereferencing (you don't need to write (*w).TotalValue), making the syntax clean.

Real-World Example: My Crypto Tracker

In my crypto tracker, I use pointer receivers when updating wallet data:

type Wallet struct {
    ID         string
    User       string
    TotalValue float64
    Holdings   []Holding
    UpdatedAt  time.Time
}

// Pointer receiver because we need to modify the wallet
func (w *Wallet) CalculateTotalValue(priceService *PriceService) error {
    total := 0.0

    for _, holding := range w.Holdings {
        price, err := priceService.FetchCoinPrice(holding.Coin)
        if err != nil {
            return err
        }
        total += price * holding.Amount
    }

    w.TotalValue = total      // Modifies the original wallet
    w.UpdatedAt = time.Now()  // Updates timestamp
    return nil
}

If I used a value receiver here, the calculated TotalValue and UpdatedAt would never be saved to the original wallet.

The Stack vs Heap Trade-off

Here's where it gets interesting. Value receivers are faster because they use the stack, but pointer receivers can be slower because they may require the heap.

Stack (Fast)

When you use value receivers, Go allocates the copy on the stack. The stack is fast because:

Memory is automatically managed (allocated and freed when functions return)
Memory is local and cache-friendly
No garbage collector involvement

func (w Wallet) GetUser() string {
    return w.User  // Fast: uses stack memory
}

Heap (Slower, but Necessary)

When you use pointer receivers, Go might allocate the variable on the heap if it "escapes" the function scope. This happens because the address could be referenced later in the program, so Go can't safely discard it when the function returns.

func (w *Wallet) UpdateAndReturn() *Wallet {
    w.TotalValue = 10000
    return w  // Address escapes, so w lives on the heap
}

The heap is slower because:

The garbage collector must track and clean up these allocations
Memory access is less cache-friendly
Allocation and deallocation take more time

However, this trade-off is usually worth it when you need to modify large structs or avoid expensive copies.

When to Use Each

Use Value Receivers When:

You don't need to modify the struct
The struct is small (a few fields)
You want maximum performance for read-only operations

func (w Wallet) IsEmpty() bool {
    return len(w.Holdings) == 0  // Just reading, no modifications
}

func (w Wallet) GetUserInfo() string {
    return fmt.Sprintf("User: %s, Value: $%.2f", w.User, w.TotalValue)
}

Use Pointer Receivers When:

You need to modify the struct
The struct is large (copying would be expensive)
You want consistency (if some methods use pointers, use them everywhere)

func (w *Wallet) AddHolding(holding Holding) {
    w.Holdings = append(w.Holdings, holding)  // Modifies original
}

func (w *Wallet) ClearHoldings() {
    w.Holdings = []Holding{}  // Modifies original
}

A Common Pattern: Mixing Both

In practice, if you have any pointer receiver methods, it's best to use pointer receivers for all methods on that type for consistency:

type Wallet struct {
    User       string
    TotalValue float64
}

// Even though this doesn't modify, use pointer for consistency
func (w *Wallet) GetUser() string {
    return w.User
}

// This modifies, so it needs a pointer
func (w *Wallet) SetUser(user string) {
    w.User = user
}

What I've Learned

Coming from C, I understood pointers conceptually, but Go's implementation adds an interesting layer. The automatic dereferencing makes pointer receivers feel natural to use, and the compiler's escape analysis intelligently decides when to use the heap vs stack.

The key insight: value receivers are best when you don't intend to modify the argument, while pointer receivers are perfect when you want to modify a passed argument or when you want to avoid copying large values.

Virtual Environments: My "Aha!" Moment

Ajisafe Victor Oluwapelumi — Tue, 25 Feb 2025 14:34:43 +0000

This is going to seem weird, but I have seen "virtual environments" flying around since I started coding in 2022. Yet, I only just got the hang of them. For the longest time, they looked like some overly complex sorcery, and I would shy away every time someone mentioned them.

Fast forward to now, I am sitting here wondering how I have been surviving without them all this time.

Do not get me wrong, I had used virtual environments before. I knew how to spin one up when following tutorials, but it was always just one of those "do this because they said so" moments. I never really understood the power they wielded. But recently? Oh boy, things changed! I finally hacked how powerful they can be when properly integrated into a project, and now I cannot imagine coding without them.

So, here is how I have been rolling with virtual environments lately.

What Even Is a Virtual Environment?

If you are like how I used to be, you might have nodded along when people talked about virtual environments without actually knowing what they were. A virtual environment is basically a self-contained workspace where you can install project-specific dependencies without messing up your system-wide Python setup.

Think of it like a bubble for your project, everything it needs stays inside, away from global Python, keeping things clean and conflict-free. No more worrying about breaking other projects because some library decided to update itself to an incompatible version.

How To Setup Virtual Environments

1. Create a virtual environment

python -m venv my_env

This creates a new directory my_env, which holds all the virtual environment goodies.

2. Activate it

On Windows:

  my_env\Scripts\activate

On macOS/Linux:

  source my_env/bin/activate

Once activated, your terminal will show (my_env), meaning you are now inside the isolated environment.

3. Install Dependencies

pip install requests flask

Boom! These packages are now installed only inside my_env, not system-wide.

4. Deactivate When Done

deactivate

This takes you back to normal, global Python.

Why You Should Use Virtual Environments

No More "It Works on My Machine" Nightmares - With a virtual environment, dependencies are locked to specific versions, so no more "why does it work for you but not for me?"
Easy Project Switching - One can now hop between projects without dependency conflicts.
Better Collaboration - When sharing code, others can recreate exact environment using a requirements.txt file:

  pip install -r requirements.txt

Now that I have finally embraced virtual environments, I cannot believe I was coding without them for so long. If you are like I was, seeing people talk about them but never really using them, trust me, it is worth the 5 minutes to set up. Your projects (and future self) will thank you!

How Dictionary Lookup Operations Are O(1)

Ajisafe Victor Oluwapelumi — Thu, 05 Sep 2024 18:16:38 +0000

Imagine you have a magical book that lets you look up any word instantly. You don’t need to flip through pages or search for the right letter section. You just say the word, and poof, the meaning appears immediately.

In programming, we have something very similar to this magical book: dictionaries (also called hashmaps). They are special data structures where you can store things in a way that makes finding them super fast, no matter how much you’ve stored.

But how does this work?

What’s a Dictionary in Programming?

A dictionary in programming is like a real-life dictionary, but instead of words and meanings, it stores keys and values. You give it a key (something unique like a number, a name, or a word), and it will give you back its value (like a description, number, or some other information related to the key).

For example:

fruit_colors = {
    "Apple": "Red",
    "Banana": "Yellow",
    "Grapes": "Purple"
}

Key: "Apple"
Value: "Red"

The Magic Behind O(1) Lookup

So, how does the dictionary give you answers so quickly? The secret is something called hashing.

Let’s think about it this way: if you had a huge pile of toys and someone said, "Find me the red car" you would have to look through the whole pile one by one, that would take time, especially if there are lots of toys.

Now, imagine if every toy had a magical sticker with an exact spot where it should go on a shelf. Every time you put a toy away, it goes straight to its specific spot. So, if you wanted the red car, you would know exactly where it is without looking through everything.

This is exactly how a hashmap works. When you add something to a dictionary, a special function (called a hash function) creates a magical "sticker" (called a hash), which tells the dictionary where to store the value.

When you ask for that value later using its key, the dictionary uses the same "sticker" to go straight to the spot and grab the value in one step. This quick access, no matter how much stuff you have, is called constant time or O(1) in Big O notation. It means the lookup time doesn’t grow even if you have millions of items stored.

Checking If a Key Exists in a Dictionary

When working with dictionaries, one common task is checking if a specific key exists. For example, in our magical toy shelf, one might want to know if a red car is already on the shelf before adding another one.

There are two ways you might write this check in Python:

if key in dictionary
if key in dictionary.keys()

At first glance, both seem to do the same thing however, there is a big difference in efficiency, and here is why.

if key in dictionary – The Fast, Direct Way
When you write if key in dictionary, Python automatically looks for the key in the dictionary’s "shelf" of keys. It knows exactly where to check, thanks to the hashing system we talked about earlier. This lookup is done in O(1) time, meaning it is super fast.

if key in dictionary.keys() – The Slower, Extra Work Way
On the other hand, if you write if key in dictionary.keys(), you are explicitly asking Python to first pull out all the keys from the dictionary and store them in a special "view" object. Then, Python checks if the key is in that view. While this still works, it is slower because you are adding an extra step: creating the view of all the keys.

Always use if key in dictionary. It is the faster, more efficient way to check if a key exists in a dictionary.

Dictionaries in programming are powerful tools, allowing you to store and retrieve data quickly, thanks to the magic of hashing. With constant-time lookups (O(1)), they enable you to efficiently manage large amounts of data without worrying about performance issues. Whether you are checking if a key exists or retrieving a value, dictionaries are your go-to structure for fast and effective operations.

Have any experiences with using dictionaries? Share your thoughts and tips in the comments below!

Goroutines and sync.WaitGroup in Golang

Ajisafe Victor Oluwapelumi — Thu, 11 Jan 2024 16:13:37 +0000

Creating a booking app with Golang has been a thrilling experience, filled with challenges and chances to learn. I came across something interesting while working on managing Goroutines using sync.WaitGroup. It reminded me of the asynchronous and await functionality in Node.js, providing a strong way to handle multiple tasks at the same time in Golang. However, when I initially tried to add sync.WaitGroup to my code, I encountered an unexpected error, I found out that it was crucial to create an instance of sync.WaitGroup for it to work smoothly.

The Importance of Goroutines

Goroutines are a key feature in Golang that allow functions to run concurrently. They are lightweight, making them great for handling many tasks simultaneously without affecting performance. To make Goroutines even more efficient, I explored using sync.WaitGroup.

Understanding Sync.WaitGroup

In Golang, sync.WaitGroup is designed to coordinate Goroutines. It keeps track of the number of active Goroutines, making it useful in situations where you want to make sure all concurrent tasks are completed before moving on.

The Learning Experience

While trying to add sync.WaitGroup to my booking app, I faced an error that made me realize that creating an instance of sync.WaitGroup is necessary before using its methods. The three main methods - Add(), Wait(), and Done() - are crucial for synchronization. If we try to call sync.WaitGroup.Add(1), the Go compiler will give an error because Add is not a function of the sync.WaitGroup type that can be called directly. It's a method that needs an instance of sync.WaitGroup to be called upon.

package main

import (
    "fmt"
    "sync"
)

func main() {
    // Create an instance of sync.WaitGroup
    var wg sync.WaitGroup

    // Example Goroutine
    wg.Add(1)
    go func() {
        // Your concurrent task logic here
        fmt.Println("Hello World!")
        wg.Done()
    }()

    // Wait for all Goroutines to finish
    wg.Wait()
}

By creating an instance of sync.WaitGroup and using its methods in the right context, I seamlessly integrated it into my booking app. This ensured smooth coordination between Goroutines.

If you have any stories about using sync.WaitGroup, feel free to share them in the comments below. I would love to hear about your experiences!

The Journey to Becoming a Software Engineer: My Year at ALX

Ajisafe Victor Oluwapelumi — Fri, 20 Oct 2023 22:58:55 +0000

On August 15, 2022, I began a journey that changed my life's course. The ALX Software Engineering program was my choice. At first, I was both excited and uncertain about what lay ahead. I'd been self-taught, but I longed for structured learning and a community of like-minded individuals. ALX was my answer.

Today, on October 20, 2023, as I graduate from this transformative program, I'm brimming with excitement and a profound sense of achievement. The past year has been a remarkable journey of self-discovery and growth, one I'm eager to share with you in this post. It's been a time of refining my skills and broadening my horizons, and I can't wait to see where this newfound knowledge will lead me.

My year at ALX was like an exciting journey where I not only became a better coder but also honed my problem-solving skills. The challenging curriculum and unwavering support from my fellow learners and mentors transformed everyday problems into chances for personal growth. My ability to think critically, debug, and solve complex problems all improved significantly, giving me the confidence to handle challenges with ease.

Yet, one big realization during this year was the strength of community. The program created an atmosphere where working together was key. It wasn't only about standing out individually but also about supporting each other. The feeling of togetherness and sharing knowledge with my peers meant a lot. It taught me that the journey becomes more special when you're alongside others who have the same passion.

While at ALX, I discovered a knack for explaining complex technical stuff in simple terms. This newfound passion for making the complicated seem easy has become a vital part of my journey. Feel free to check out my articles here for a deeper dive into topics that pique my interest.

As I gaze ahead, I see a world filled with opportunities. In the next 5-10 years, I imagine using my Software Engineering skills to make a positive impact on communities in Africa and beyond. My time at ALX has armed me with not just technical skills, but also the mindset and determination to effect change. I'm thrilled to apply my knowledge to tackle real-world issues and devise solutions that can benefit society.

In summary, my year at ALX Africa has been an exceptional chapter in my software engineering journey. It transformed me, broadening my horizons, honing my skills, and instilling a deep sense of purpose. I found my community, uncovered a passion for technical writing, and gained the confidence to tackle complex challenges. The future holds abundant promise, and I can't wait to seize its opportunities.

I invite you to dive into my articles here and reach out to me. If you're on a similar path or have a story to share, I'd be thrilled to connect with you. Together, let's keep learning, growing, and inspiring one another.

Composition and Inheritance: From Cars to Cars

Ajisafe Victor Oluwapelumi — Mon, 28 Aug 2023 23:35:44 +0000

Hello and welcome! A while back, I tackled a real-world problem through Forage, and the company at the center was Lyft. While much of the material covered wasn't entirely new, what intrigued me were the concepts of composition and inheritance. These concepts played a central role in shaping Lyft's backend infrastructure and I thought to share my newfound knowledge with you. Stay tuned.

Composition: Assembling a Car

Let's say we are putting together a car. A car is made up of lots of different parts, and instead of making the whole car all at once, we start by making smaller pieces. Then, we fit these pieces together to build the complete car. This way of building things is called composition. It's a helpful approach because it gives our car flexibility. We can easily add or remove pieces as needed. This makes our finished car more versatile.

Let's see an example:

class Engine:
    def start(self):
        pass

class Wheels:
    def rotate(self):
        pass

class Car:
    def __init__(self, brand):
        self.brand = brand
        self.engine = Engine()
        self.wheels = Wheels()

Here, we are defining three classes: Engine, Wheels, and Car. Engine and Wheels represent parts of a car while the Car class brings together an engine and wheels to construct a complete car.

We see that each part has its own functionality with specific responsibilities. The engine starts, the wheels rotate and the car cars (I thought that would come out right).

Inheritance: Family Traits Passed On

Inheritance is in the name, we inherit traits from our parents. Same applies here as our classes inherit characteristics from their base class. We can create new things based on existing things and pass down their characteristics. This approach makes us more efficient as we do not need to create things from the start.

Let's see an example:

class Vehicle:
    def __init__(self, brand):
        self.brand = brand

class Car(Vehicle):
    pass

# Creating an instance of Car
my_car = Car("Toyota")
print(f"My car's brand is {my_car.brand}")

The Car class inherits the brand attribute from the Vehicle class without needing to redefine the __init__ method. The Car class inherits all attributes and methods from the Vehicle class while also retaining the ability to redefine and implement its own variations.

You could use both composition and inheritance together to get the best out of your application. If you'd like to explore how I employed both to address the Lyft challenge, you can find the code here.

If you've got stories about using composition and inheritance, I would love to hear them. Drop a comment below and share your experiences!

Exploring the Magic of async/await in JavaScript!

Ajisafe Victor Oluwapelumi — Thu, 10 Aug 2023 20:20:14 +0000

Today, we're going to uncover async and await. In JavaScript, there are some tasks that can take some time, like asking for information from the internet or reading special files. Instead of making the whole computer wait for these tasks to finish, JavaScript allows other tasks to be handled at the same time while it waits for the response from time-taking tasks. Sometimes, we want to wait for the response before starting other tasks, and that's where async and await comes in.

async

In simple words, async is a special word we put in front of a function to tell our computer, "Hey, inside this function, there might be things that take a bit of time to finish."

async function getData() {
  // Asynchronous operation
}

await

We use the await keyword inside an async function and it's a way to tell our computer, "Hey, take a break and pause execution here until this thing is done."

async function main() {
  const result = await getData(); // Pauses until getData() is resolved
  console.log(result);
}

Let's explore the use of async and await with some examples.

Example 1: Without async/await

// Imagine fetching a cat fact from an API using Promises

function main() {
  const url = 'https://catfact.ninja/fact';
  const response = fetch(url);
  console.log(response.fact); // Oops! This won't work as expected
  console.log('Cat Fact Ninja!');
}

function fetch(url) {
  return new Promise((resolve, reject) => {
    // Fetch the cat fact from the API
  });
}

main();

In this example, we have two functions: main() and fetch(url).

The fetch(url) function takes a URL as input and returns a Promise (a Promise ensures that our request is completed). Inside this Promise, we request a cat fact from the internet.

The main() function starts by setting a URL for a cat fact API. Then it calls the fetch(url) function to get the cat fact data. Since fetch(url) returns data from the internet, it doesn't immediately provide the result, the function takes time. Therefore, when we try to log response.fact, it won't work correctly. The next console.log() statement and 'Cat Fact Ninja!' will be printed before the fetch(url) is resolved and this is not what we want. We can fix this in the next example.

Example 2: With async/await

// Now let's fetch a cat fact using async/await

async function main() {
  const url = 'https://catfact.ninja/fact';
  const response = await fetch(url); // We await the promise to finish
  console.log(response.fact); // This works perfectly now!
  console.log('Cat Fact Ninja!');
}

function fetch(url) {
  return new Promise((resolve, reject) => {
    // Fetch the cat fact from the API
  });
}

main();

In this example, we've made a slight change by using the async keyword in the main() function.

The main() function is now marked as async, which means we can use the await keyword inside it. When await is used before calling fetch(url), it pauses the execution of the main() function until we get the result we want. This way, the cat fact data is fetched and assigned to the response variable before moving on. Now, when we log response.fact, it will correctly show the cat fact fetched from the API because we were waiting for the function to return using await.

async and await help us do cool things with our code, even if those things take time. If you've got thoughts or stories about using them, I'd love to hear them. Drop a comment below and share your experiences, your feedback means a lot!

Navigating One-To-Many Relationship in MySQL

Ajisafe Victor Oluwapelumi — Thu, 03 Aug 2023 18:20:44 +0000

While developing the backend for Vim Quizzer, I encountered a challenge in handling a list of incorrect questions for our question class due to MySQL's lack of direct support for list structures. To address this, I created an Incorrect Question class and established a One-to-Many relationship between the Question class and the Incorrect Question class, successfully implementing a list structure. In this post, I will explain how I achieved that and also shed light on how the One-to-Many relationship works.

Before we dive into the technicalities, let me give a brief overview of the project that kick started this adventure. Vim Quizzer is an engaging platform designed to help users learn Vim commands through a series of multiple-choice questions that test their knowledge of this command-line text editor, commonly used on Linux machines. If you're eager to put your Vim skills to the test, you can try the quiz here, the source code is also available here.

The Challenge

MySQL serves as the relational database management system, where we store the questions for our web application. As depicted above, our database structure includes a table named questions with 4 columns: question_id, question, correct_answer, and incorrect_answers. The question_id column holds the question id while the question column accepts a string to store the question itself, the correct_answer column also takes a string to store the accurate response for the question. On the other hand, the incorrect_answers column requires a list of strings to store the various incorrect responses for the question.

However, MySQL lacks built-in support for list structures so we can't have an incorrect_answers column. To address this, we had to devise an alternative approach, and that's where One-to-Many relationship came into play.

One-To-Many Relationship

As illustrated above, we have established an incorrect answers table, which comprises the incorrect_answer_id column, the question_id column, and the incorrect_answer itself. It is evident that the question_id serves as a shared column between the question table and the incorrect_answer table. The incorrect answers to the question in our first illustration are now stored accordingly.

Here, all 3 incorrect answers possess the same question_id, signifying that they correspond to one particular question in our database. This linkage ensures that each incorrect answer is appropriately associated with its corresponding question.

To enable the incorrect_answers attribute to return the list of all incorrect answers associated with a question, we implemented the following code in our Question class.

 # Create list of incorrect answers
 incorrect_answers = relationship("IncorrectAnswer", backref="question", cascade="all, delete-orphan")

In our implementation, we take advantage of SQLAlchemy's relationship method to establish a seamless link between incorrect_answers and the Incorrect Answer class. Thanks to the backref parameter, accessing incorrect answers from a given question becomes a breeze, eliminating the need for complex queries or tangled joins. See snippet below.

>>> type(question1)
<class '__main__.Question'>
>>> question1.question
'What is the Vim command to save and exit a file?'
>>> question1.correct_answer
':wq'
>>> question1.incorrect_answers
[":w", ":q!", ":s"]

Furthermore, the cascade parameter works wonders in ensuring data integrity. When we remove a question, all its associated incorrect answers are gracefully deleted as well. This intelligent handling of cascading deletes prevents any orphaned records from cluttering up the database, maintaining a tidy and organized data structure. This solution brings simplicity and efficiency to the management of question and incorrect answer relationship, streamlining the entire process for optimal performance.

As mentioned earlier, this implementation is at the core of our backend, making it the backbone of our entire application. Witnessing this implementation work in real-time was truly refreshing. The One-To-Many relationship unlocks the true power and practicality in our application, allowing us to seamlessly manage questions and their corresponding incorrect answers with utmost efficiency.

I hope this explanation provided a clear understanding of the One-To-Many relationship. Feel free to share your thoughts and experiences in the comments. Whether you have explored this concept before or are eager to delve into it, your insights and feedback are appreciated.